¿Cómo manejar los depósitos de éter como lo hacen los intercambios?

Ha hecho una serie de preguntas además de su pregunta principal, que era cómo manejar los depósitos de éter.

El principal problema con lo que está tratando de lidiar es el problema del doble gasto . Si alguien deposita en su intercambio Dapp, ¿cómo se asegura de que los fondos no se gasten dos veces y cómo maneja los fondos que se depositan y luego no se gastan debido a una bifurcación?

La respuesta está algo en su cancha como desarrollador de DAPP Exchange: usted decide. Entonces, ¿por qué no elegir 24 bloques o, como hace un intercambio, 360 bloques? Lo que te dé la confianza que necesitas.

Me doy cuenta de que esta no es una respuesta técnica, pero hay un problema funcional con esto, principalmente que el usuario que envía una orden de compra o venta tendrá que esperar el mismo tiempo para que se complete o se ingrese en el libro de órdenes. Así que tienes que cambiar la estabilidad por la usabilidad.

También debe tener en cuenta que, debido a la naturaleza del proceso de creación de bloques, no podrá procesar los pedidos de forma rápida o de la misma manera que lo haría en un servicio centralizado. Esto se debe a que un nodo no puede estar al tanto de todos los pedidos (es decir, transacciones) realizados en cualquier lugar de la red en el mismo momento en que intenta procesar los pedidos que ha recibido a través de la red.

Nuevamente, esta es una gran diferencia con un servicio centralizado, y también debe considerar esto como parte de la misma solución.

No tengo conocimiento de ninguna biblioteca disponible que pueda proporcionarle una respuesta rápida, pero parece que hay una serie de proyectos por ahí.

¿Cuál es la recomendación más reciente para la cantidad de confirmaciones de tx con el lanzamiento de Homestead?

De acuerdo con las API de web3, 12 bloques son buenos para asegurarse de que no haya una bifurcación. En cuanto a las confirmaciones de tx... Diría que 5 sigue siendo la cantidad de facto que desea allí. Obviamente, eso va a cambiar con Serenity, y no estaría seguro de cómo responder a eso dado el gran cambio que Casper traerá consigo. Siga el blog de Vitalik para que pueda tener en cuenta estas cosas mientras desarrolla.

¿Existen bibliotecas o servicios que proporcionen implementaciones de muestra?

hmmm... probablemente querrías trabajar con eventos y ese manejo... no estoy seguro acerca de tu área de confirmación de tx... no parece haber ninguna herramienta prefabricada para esos propósitos... probablemente tendría que hackear algo juntos en uno de los clientes (recomendaría usar Parity para esto porque quieres algo rápido... y Parity es increíblemente rápido).

¿Cuál es la implementación aproximada del pseudocódigo para manejar esto usted mismo?

algo como esto

js:

var i = myEthereumEvents
myEthereumEvents.watchAllEvents() {
    if (eventHit)
         var boolean = contract.promisifiedCheckBalanceOfPeer()
         if (boolean)
              contract.exchangeTokenValue()
}

ahora probablemente necesitará cobrar interés en algunos de ellos y crear algún tipo de equilibrio de carga en Solidity... esto requerirá que usted piense un poco... hay toneladas de ejemplos de creación de metacoins allí, simplemente ¿Tiene que configurarlo para imitar el suministro de tokens de otras cadenas? Esto podría ayudar a asegurar la cantidad necesaria... por otro lado, es posible que esté hablando de algo completamente diferente y quiera algo puramente del lado del intercambio... una cosa que recomendaría con certeza es desactivar la sincronización rápida y monitorear la cantidad. de las transacciones entrantes y se ajusta en consecuencia a sus algoritmos.

Déjame saber si esto responde a tu pregunta.