¿Cuántas transacciones por segundo podemos enviar de forma segura?

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

  • ¿Cómo se define "transacción no ejecutable"? Supongo que esto define transacciones que no se pueden ejecutar debido a un nonce demasiado alto
  • Si AccountSlots está establecido en 16 (y supongo que la mayoría en la red lo ha establecido), ¿eso significa que los 16 nonces de transacción más bajos irán allí?
  • ¿El número de transacciones posibles por cuenta en el grupo de tx es AccountSlots + AccountQueue o AccountQueue?
  • ¿Qué pasa si trato de enviar más que eso? ¿Ethereum abandonará silenciosamente la transacción? (ya que supongo que esto es lo que está sucediendo en este momento)?

Respuestas (2)

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 concurrencycaracterística de la Promise.mapfunció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).

¿Cómo responde esto a las preguntas?
@BadrBellaj No creo que mi respuesta sea precisa. De hecho, creo que no hay una respuesta precisa. Me gustaría que la gente respondiera/contestara/discutiera con argumentos sensatos.
Hola. ¿Tiene un enlace a donde se lee el 40 tx/s?
@RichardHorrocks (40/seg Hablando de memoria). Tenga en cuenta que este número es orientativo para proporcionar un orden de magnitud (decenas frente a miles). Tenga en cuenta también que las minas de energía en tiempo pseudoaleatorio y que la red solo garantiza un tiempo promedio. Este enlace ( reddit.com/r/ethereum/comments/3m7ley/… ) habla de decenas de txs para POW frente a decenas de miles para POS. Ese es un máximo teórico permitido para todos los usuarios. 10.000 mil usuarios diferentes realizando transacciones simultáneamente proporcionarán un promedio de 1 tx/seg por usuario.