Cardano-db-sync: Bloques huérfanos no eliminados de la tabla de bloques

La solución más simple para esto es eliminar los bloques que han quedado huérfanos como este.

Como alternativa a eliminarlos, podríamos moverlos a una tabla orphaned_blocks separada, pero luego debemos decidir qué queremos hacer con los tx s adjuntos a ese bloque. Mi sensación inicial es que deberían ignorarse / eliminarse.

Tener una tabla orphaned_block puede ser útil cuando cambiamos a Praos, pero se puede implementar fácilmente incluso ahora cuando db-sync realmente solo es compatible con Byron.

Mi primer pensamiento también fue: limpie el bloque huérfano, pero guárdelo en algún lugar.

Incluso podría convertirse en una opción para el nodo almacenar todas las bifurcaciones detectadas, incluidos todos los bloques del brazo lateral abandonado en esta tabla. Purgar después de x ranuras es simple. Entonces, el diagnóstico y el seguimiento de lo sucedido es mucho más fácil.

La pregunta sobre las transmisiones perdidas es interesante. Como idea rápida, sin saber si es criptográficamente posible y 100% seguro:

Si un nodo (db-sync habilitado) detecta TX de bloques huérfanos, podría intentar reinsertarlos en su mempool. No transmitirlo más, sino procesarlo solo si es su turno de producir un bloqueo.
(la transmisión no debería ser necesaria porque muchos otros grupos detectan el bloque huérfano con sus TX y lo reinsertan en su mempool desde esa fuente)

Si, mientras tanto, el propietario de utxo (hasta que se resuelvan las bifurcaciones y se detecten los bloques huérfanos) envió un segundo intento, el TX anterior deja de ser válido. Si, en cambio, el tx sigue siendo válido, aparecerá automáticamente en un nuevo bloque válido nuevamente.

Las billeteras deben poder manejar una situación en la que pueden ver su tx en un bloque, quién luego queda huérfano, y algunos bloques más tarde el mismo tx se coloca en otro bloque, con suerte, válido.

Si un nodo (db-sync habilitado) detecta TX de bloques huérfanos, podría intentar reinsertarlos en su mempool. No transmitirlo más, sino procesarlo solo si es su turno de producir un bloqueo.

Es importante tener en cuenta que db-sync está separado de node y simplemente sigue la cadena de node .
Específicamente, db-sync no mantiene su propia copia del mempool. En el caso que detecté, las transacciones en el bloque huérfano casi con certeza se incluyeron en bloques no huérfanos posteriores, por lo que db-sync debería eliminarlos.

La billetera, por supuesto, tiene un comportamiento diferente al de db-sync .

Si los TX son casi con certeza procesados ​​por otros productores de bloques, entonces no hay necesidad de "reinyectarlos" con alguna herramienta de db a node's mempool.
La pregunta es si este es el caso en todas las variantes de batalla de ranuras / alturas. Si no, la siguiente pregunta es si es útil (previsto) permitir que uno de los nodos que detecta TX sin procesar en un bloque huérfano, los vuelva a insertar en su mempool, según la base de datos db-sync

db-sync realmente solo debería usarse para ver lo que sucedió en el pasado. El propio nodo extraerá transacciones de bloques huérfanos y las volverá a poner en su propio mempool. db-sync no pretende ser parte de eso.

Sin embargo, mantener una lista de bloques huérfanos dentro de las últimas 100 ranuras puede ser útil para la depuración.

Creo que el bloque debería eliminarse en la reversión, y deberíamos usar eliminaciones en cascada para eliminar todo lo que está lógicamente dentro de los bloques eliminados.

No tiene sentido tratar de preservar los bloques que se han revertido. Esta no es una herramienta de monitoreo para monitorear la propagación de bloques dentro de la red. Solo está observando en un lugar y como cliente de nodo, por lo que sería muy poco confiable cuando se usa en ese rol.

Estoy de acuerdo en que deberíamos mantener db-sync lo más puro posible como reflejo del estado real de la cadena.

Sin embargo, simplificaría enormemente mi vida si TODOS los bloques se convirtieran en db-sync y luego se eliminaran en las reversiones. De esa manera puedo activar la eliminación de postgres y hacer lo que quiera con los datos.

Esto es necesario para otros clientes y Sam dice que es fundamental para cualquier versión de db-sync, incluida Testnet.

Parece que las reversiones no funcionan como se esperaba. Vemos varios bloques en la base de datos con la misma altura de bloque. Aquí hay un ejemplo (en mainnet):

cexplorer = # SELECT * FROM block WHERE block_no = 4224831;
id | hash | slot_no | block_no | anterior | merkel_root | slot_leader | tamaño | epoch_no | tiempo | tx_count
--------- + ---------------------------------------- ---------------------------- + --------- + ---------- + ---------- + --------------------------------------- ----------------------------- + ------------- + ------ + ---------- + --------------------- + ----------
4225044 | \ x941a71094c7b10243845a82e53dc45959d8fde5f6d87e463efe660aa9611b965 | 4226979 | 4224831 | 4225043 | \ x95549f5fcfc370eb4b24c981a6053f909bdef6418ce896828c6be18fa31ab406 | 6 | 1731 | 195 | 2020-05-29 08:57:51 | 3
4225045 | \ x275ee8b9ae441e6e32e1f7f36290e6a048722619d91195773a07b06682418209 | 4226980 | 4224831 | 4225043 | \ x6eb04497431d77657a94b0eee70dae59e7403980d4fc9d06ba5295436b8f0f54 | 7 | 1418 | 195 | 2020-05-29 08:58:11 | 2
(2 filas)