Estoy diseñando un servicio fuera de la cadena que maneja las solicitudes y publica una transacción en la cadena de bloques cuando se completa cada solicitud. Durante el intervalo de tiempo de un solo bloque, el servicio puede manejar muchas solicitudes para muchos usuarios. Las transacciones de finalización son funcionalmente independientes entre sí y el orden en que se ejecutan no importa. Quiero publicar de manera confiable cada transacción sin preocuparme por las interacciones que podrían causar fallas.
En Múltiples transacciones desde la misma dirección , Paul S escribe:
Si tiene dependencias de transacciones en su aplicación fuera de blockchain, debe esperar hasta que se haya extraído la transacción anterior antes de enviar la siguiente transacción.
No tengo dependencias de transacciones funcionales, pero aún así: como ejemplo del tipo de problema que me gustaría evitar, supongamos que envío simultáneamente N transacciones desde la misma dirección, incrementando correctamente el nonce para cada una. Si todas estas transacciones se van a incluir en el mismo bloque, el minero debe asegurarse de que ocurran en orden creciente para componer un bloque válido. O si solo se incluye un subconjunto de K<N transacciones, el subconjunto debe ser las primeras K transacciones, nuevamente en orden. Dada la forma en que las transacciones pendientes se transmiten probabilísticamente a través de la red, me preocupa que una ráfaga de transacciones desde la misma dirección no se extraiga de manera confiable en un bloque.
¿Es el mejor enfoque utilizar una dirección de remitente diferente para cada transacción?
Eso parece resolver el problema del grupo de transacciones y el nonce, pero complica otros aspectos de la dapp, como la gestión de claves privadas y las listas blancas de direcciones de remitentes en los contratos.
No estoy seguro de que esto sea necesario en la práctica; El consejo que cita es para una situación en la que está realizando transacciones sin procesar fuera de línea y puede descartar algunas de ellas, pero si solo envía sus transacciones a través de Geth, debería manejar la transmisión de las transacciones y el incremento de nonce, y las cosas generalmente deberían Simplemente Trabajar. Sin embargo, es cierto, al menos en teoría, que enviar las transacciones desde la misma cuenta hace que las fallas de transmisión caigan en cascada de una manera que no necesitas.
Si desea enviar sus transacciones desde diferentes cuentas, pero no desea obligar al resto de su aplicación a tratar con cientos de direcciones de cuentas diferentes, puede abstraer esa parte: use una sola clave para crear una cuenta separada. firma que usted transmite en la parte de datos de la transacción. Envíelo a un contrato intermedio que acepte transacciones provenientes de cualquier dirección y, en su lugar, verifique que la firma que se le pasó como parámetro coincida con su clave de firma única. Luego haga que el contrato intermedio haga lo que originalmente pretendía hacer. Eso aparecerá en cualquier contrato subsiguiente como proveniente del contrato intermedio, por lo que tendrá un solo común msg.sendercomo lo haría si estuviera enviando todas las transacciones desde la misma dirección.