¿Cómo manejan geth y parity la notificación de eventos a los clientes después de las reorganizaciones?

Si configura un detector de eventos con Geth (supongo que también con Parity), recibirá notificaciones cuando aparezca un evento en particular en los registros de eventos.

A veces ocurrirá una reorganización, y el bloque donde ocurrió ese evento quedará huérfano y desaparecerá de la historia principal. La misma transacción puede provocar que un evento se genere en un bloque diferente.

¿Es correcto lo siguiente?

  • Siempre se activará un evento cuando un bloque que genere ese evento entre en lo que el nodo considera la cadena principal.
  • Si hay una gran reorganización, los eventos de varios bloques de profundidad se enviarán casi simultáneamente.
  • Un evento aún se enviará nuevamente incluso si su contenido (aparte del hash de bloque, etc.) es el mismo, por lo que, por ejemplo, si escucha un contrato que genera un evento cuando se paga, puede obtener el mismo evento dos veces aunque en última instancia, solo terminaré cobrando una vez

¿Existen trampas para los desprevenidos o problemas interesantes específicos de la implementación?

Respuestas (1)

Creo que tienes razón, aunque creo que nunca lo he probado. Los filtros de eventos en web3.js son un poco extraños: si establece fromBlock en antes de 'latest', se activará en eventos históricos.

Mirando la especificación JSON-RPC real, parece que eth_getFilterChanges realmente dirá si un evento se eliminó a través de una reorganización. Si bien no creo que el web3.js actual explote esto en gran medida, un cliente que usa el RPC directamente (estremecimiento) podría saberlo mejor.

Esto es algo que no había considerado, pero si está filtrando por 'más reciente', me pregunto si aún obtiene un evento para un bloque que no está en la punta cuando ocurre la reorganización. Tomado literalmente, parece que no lo harías; No debería haber ningún punto en el que su nodo considere el bloque con su evento como el más reciente. Pero al filtrar por 'último', las personas generalmente esperan obtener todo lo que sucede en la cadena principal mientras filtran. Me pregunto cuál de estas dos intuiciones ha elegido Geth para defraudar...
¿Cómo manejan geth y parity la notificación de eventos a los clientes después de las reorganizaciones?
RespuestasAquíPolítica de privacidad1y, 0v