Estamos trabajando en una aplicación a gran escala que emite muchas transacciones y no estamos seguros de qué garantías exactas nos da Ethereum/Geth.
En la red de prueba de Ropsten, intentamos emitir 100 transacciones a la vez, pero solo se extrae una fracción. Parece que el grupo de transacciones descarta algunas transacciones y, por lo tanto, estropea las transacciones posteriores debido al nonce de transacción.
Miré el código aquí: https://github.com/ethereum/go-ethereum/blob/master/core/tx_pool.go#L80-L83
así es como maneja este problema de una manera práctica y comprobada.
En primer lugar, antes de planificar que su organización sea demasiado grande, familiarícese con las características de la cadena de bloques de Ethereum. Las transacciones por segundo son una mala medida, ya que la parte crítica aquí es el bloque y el tiempo que lleva minarlo. Considere también el límite de gas del bloque, que es de alrededor de 4,7 millones de gas en este momento. Dependiendo de los costos de gas de sus transacciones, e incluso ignorando a todos los demás usuarios, solo hay tantas transacciones que puede incluir en un bloque; las demás tienen que esperar. Y aquí entra en juego la técnica de la concurrencia.
Como estamos tratando con la computación asíncrona aquí, simplemente disparar cientos de transacciones hará que la mayoría de ellas falle, como notó correctamente. Por lo tanto, establece un límite para la cantidad de promesas de transacción que se generan y no crea otra hasta que al menos una se haya resuelto. Compárelo con los malabares: no más de X pelotas en el aire a la vez, o terminará en un desastre. Técnicamente, esto se está haciendo con la concurrency
característica de la Promise.map
función en Bluebird Promise Library . El número que establezca para el límite de concurrencia depende de muchos factores, prepárese para hacerlo variable y ajústelo al estado de la red.
Que te diviertas.
Me imagino que quieres trabajar con la red pública ethereum (red principal). Ignoro la respuesta exacta, pero he leído que se trata de 40 tx/seg para toda la red , incluidas sus transacciones y las transacciones de cualquier otra persona. Y como aumenta el número de usuarios que utilizan la red pública, disminuye el número de tx/seg por usuario. Según el teorema/problema CAP ( https://en.wikipedia.org/wiki/CAP_theorem) blockchain es muy bueno en consistencia y tolerancia a la partición y muy malo en disponibilidad . Es decir, solo la baja frecuencia/alto valor es adecuada para la red pública de ethereum. Las "cadenas laterales" o cualquier otro mecanismo deben usarse para otros escenarios. Para redes controladas (por ejemplo, consortium ethereum blockchain), el rendimiento se puede ajustar a voluntad ajustando el algoritmo de consenso (la paridad es mucho mejor que geth en este sentido, lo que permite diferentes sistemas de consenso conectables con diferentes algoritmos).
Badr Bellaj
oído
Richard Horrocks
oído