Encontrei um modo de falha mais desagradável no DUSK do que uma transação ser rejeitada: os mesmos bytes de transação são aceitos e, depois, interpretados de forma diferente dependendo de qual parte do Rusk os manipula.

Foi essa confusão que o Boreas teve de fechar. Transações ao vivo são decodificadas em relação à versão de protocolo ativa. Envelopes antigos do Aegis ainda podem chegar na borda da rede, mas o Rusk os normaliza antes de seguirem mais profundamente. Transações seladas localmente são canonicalizadas novamente antes de serem comprometidas com o ledger.

A parte difícil é a história. O DUSK não pode simplesmente apagar as regras antigas após um upgrade porque os nós ainda precisam reenviar (replay) blocos pré-Aegis e pré-Boreas. Então o nó atual precisa entender os formatos de ontem sem permitir que as regras de ontem vazem para a produção de blocos de hoje.

Para um operador, a consequência é brutalmente simples. Uma reinicialização, uma reconstrução do arquivo (archive) ou um replay completo precisa reconstruir o mesmo estado de cadeia que o nó ao vivo alcançou. Se o mempool lê um significado e o replay histórico lê outro, tudo pode parecer saudável até que um índice, saldo ou transição de estado discorde.

Eu me importo menos com o fato de um upgrade mudar as regras de transação do que com se o DUSK consegue mudá-las sem mudar o passado.

#dusk $DUSK @Dusk