Cardano-db-sync: Blocos órfãos não removidos da tabela de blocos

A solução mais simples para isso é remover os blocos que ficaram órfãos assim.

Como alternativa para removê-los, poderíamos movê-los para uma mesa orphaned_blocks separada, mas então precisamos decidir o que queremos fazer com os tx s anexados a esse bloco. Meu sentimento inicial é que eles deveriam ser simplesmente ignorados / removidos.

Ter uma mesa orphaned_block pode ser útil quando mudamos para Praos, mas pode ser facilmente implementado mesmo agora quando db-sync realmente suporta apenas Byron.

Meu primeiro pensamento também foi: limpe o bloco órfão, mas mantenha-o em algum lugar.

Pode se tornar até uma opção para o nó armazenar todos os garfos detectados, incluindo todos os blocos do braço lateral abandonado nesta tabela. Limpar após x slots é simples. o diagnóstico e o rastreamento do que aconteceu são muito mais fáceis então.

A questão sobre TXs perdidos é interessante. Para uma ideia rápida, sem saber se é criptograficamente possível e 100% seguro:

Se um nó (db-sync habilitado) detectar TXs de blocos órfãos, ele poderia tentar reinseri-los em seu mempool. Não difundir mais, mas apenas processá-lo se for a vez de ele produzir um bloco.
(a transmissão não deve ser necessária porque muitos outros pools detectam o bloco órfão com seus TXs e o reinserem em seu mempool a partir dessa fonte)

Se o proprietário do utxo entretanto (até que os bifurcações sejam resolvidos e os blocos órfãos sejam detectados) enviar uma segunda tentativa, o TX anterior se torna inválido. Se, em vez disso, o tx ainda for válido, ele aparecerá automaticamente em um novo bloco válido novamente.

As carteiras precisam ser capazes de lidar com uma situação então, onde eles podem ver seu tx em um bloco, que então fica órfão, e alguns blocos depois o mesmo tx é colocado em outro, então bloco válido.

Se um nó (db-sync habilitado) detectar TXs de blocos órfãos, ele poderia tentar reinseri-los em seu mempool. Não difundir mais, mas apenas processá-lo se for a vez de ele produzir um bloco.

É importante notar que db-sync é separado de node e simplesmente segue a cadeia de node .
Especificamente, db-sync não mantém sua própria cópia do mempool. No caso que detectei, as transações no bloco órfão quase certamente foram incluídas em blocos não órfãos posteriores, então db-sync deve simplesmente descartá-las.

A carteira, é claro, tem um comportamento diferente de db-sync .

Se os TXs são quase certamente processados ​​por outros produtores de bloco, então, certamente, não há necessidade de "reinjetá-los" com alguma ferramenta do banco de dados para o mempool do nó.
A questão é se este é o caso em todas as variantes de batalha de slot / altura. Se não, a próxima pergunta é se é útil (pretendido) permitir que um dos nós que detecta TXs não processados ​​em um bloco órfão, reinsira-os em seu mempool, com base no banco de dados db-sync

db-sync deve realmente ser usado apenas para ver o que aconteceu no passado. O próprio nó puxará as transações de blocos órfãos e as colocará de volta em seu próprio mempool. db-sync não pretende fazer parte disso.

No entanto, manter uma lista de blocos órfãos nos últimos 100 ou mais slots pode ser útil para depuração.

Acho que o bloco deve ser removido na reversão e devemos usar exclusões em cascata para excluir tudo o que está logicamente dentro dos blocos excluídos.

Não adianta tentar preservar os blocos que foram revertidos. Esta não é uma ferramenta de monitoramento para monitorar a propagação de blocos na rede. Ele está apenas observando em um lugar e como um cliente de nó, portanto, não seria muito confiável quando usado nessa função.

Eu concordo que devemos manter o db-sync o mais puro possível, um reflexo do estado real da cadeia.

No entanto, simplificaria muito a minha vida se TODOS os blocos chegassem ao db-sync e fossem excluídos nas reversões. Dessa forma posso acionar o delete no postgres e fazer o que quiser com os dados.

Isso é necessário para outros clientes e Sam diz que é fundamental para qualquer versão do db-sync, incluindo Testnet.

Parece que as reversões não estão funcionando conforme o esperado. Vemos vários blocos no banco de dados com a mesma altura de bloco. Aqui está um exemplo (em mainnet):

cexplorer = # SELECT * FROM block WHERE block_no = 4224831;
id | hash | slot_no | block_no | anterior | merkel_root | slot_leader | tamanho | epoch_no | tempo | 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 linhas)