¿La transacción se revirtió y se volvió a minar más tarde?

Hace unas horas, estaba probando mi dapp en ropsten y sucedió algo extraño.

Envié una transacción (A) a la cadena de bloques, se extrajo y mi servidor la sincronizó. Luego, 30 minutos después, envié otra transacción (B) y llamé a la misma función. B se extrajo con éxito y A se extrajo nuevamente en el mismo bloque que B. No hay rastro de la transacción A que envié 30 minutos antes como si hubiera sido revertida. Es como si hubiera sido extraído, luego revertido y luego recordado 30 minutos después.

¿Lo que está sucediendo? Mi dapp se basa en la sincronización en vivo y esto sería una ruptura del juego. Gracias por tu ayuda.

Respuestas (2)

Lo que teóricamente podría haber sucedido es una bifurcación efímera de la cadena y luego una reorganización de la cadena.

Esto sucede cuando parte de la red acepta un bloque que contiene su transacción como canónico, solo para descubrir que otra parte más grande de la red ha aceptado una versión diferente del mismo bloque como canónico.

La versión del bloque que contiene su transacción se marca como no válida y su transacción se vuelve a colocar en el grupo de transacciones. Si hay otras transacciones de mayor precio en el grupo, entonces su transacción tendrá que esperar hasta su lugar en el mercado.

Mi dapp se basa en la sincronización en vivo y esto sería una ruptura del juego.

No estoy seguro de cómo está definiendo "sincronización en vivo", pero hay un par de cosas en las que pensar.

En primer lugar, su transacción puede o no ser minada en un bloque en lo que usted considere un tiempo razonable, dependiendo de la carga en la red y el estado actual del mercado de precios del gas. Si su transacción tiene un precio demasiado bajo, es menos probable que se incluya en un bloque de manera oportuna.

En segundo lugar, vale la pena esperar un cierto número de confirmaciones antes de considerar válido el bloque que contiene su transacción. (Esta respuesta anterior recomienda 12. No estoy seguro de si este número sigue siendo una práctica estándar).

(Aquí hay un artículo sobre el manejo de reorganizaciones de cadenas desde la perspectiva del desarrollo de Dapp. Enlace externo).

Por sincronización en vivo quiero decir que estoy sincronizando cada evento en una base de datos centralizada para recrear el estado de la cadena de bloques y poder consultar datos. Sería inaceptable que un evento se revirtiera después de que se haya sincronizado en mi base de datos. ¿Esperar 12 confirmaciones me daría 100% de firmeza? Gracias
Está bien, entendido. Actualmente, no hay una finalidad firme y rápida en Ethereum, incluso con 12 confirmaciones. Con suficiente poder de hash, un usuario adversario podría volver a minar una cadena de longitud arbitraria a su gusto, eligiendo qué transacciones revertir. Sin embargo, es poco probable que esto suceda, dado el poder de hash requerido. A todos los efectos, 12 confirmaciones se considera probabilísticamente "segura".
(Para agregar, las garantías de finalidad más fuertes entrarán en vigor una vez que Ethereum pase a la prueba de participación. Mi comentario anterior es para el modelo de consenso de prueba de trabajo actual).

Esto es normal en el caso de una reorganización de la cadena. Los bloques se pueden revertir si aparecen bloques más nuevos con más trabajo (básicamente, si su cadena está en el bloque N y alguien transmite el bloque N + 1 con un bloque N diferente como su padre, la cadena se reorganizará y eliminará el bloque N que vio previamente).

Cuando esto sucede, todas las transacciones en los bloques revertidos se devuelven al txpool. Además, dado que la construcción de plantillas de bloques tiende a seleccionar transacciones similares en función del uso y el precio del gas, muchas de las transacciones ahora no confirmadas se extraerán de los bloques que ahora forman parte de la cadena, lo que dará como resultado que solo una pequeña parte de las transacciones regrese a la piscina de tx.

Estas transacciones luego se pueden extraer en un bloque futuro, que es lo que parece haber encontrado.

Tenga en cuenta que incluso en toda esta reorganización, la transacción A siempre estará antes que la transacción B, ya que aún se respeta el orden de nonce.

Esta es también la razón por la cual los intercambios y otros servicios esperan múltiples confirmaciones antes de acreditar una cuenta de usuario con los resultados de una transacción. En la red principal, es poco probable que vea reorganizaciones que abarquen 30 minutos, pero ciertamente no es imposible. Sin embargo, las redes de prueba tienden a ser un poco menos confiables.