Eu assumi que o significado de uma transação era fixo no momento em que seus bytes existiam: decodifica uma vez, obtém a mesma resposta em todo lugar. O changelog próprio do Rusk na Dusk para a atualização do Boreas trata isso como algo que precisa ser projetado, não algo que se pode presumir.
O Boreas adicionou uma decodificação de transações com consciência de versão vinculada a um hardfork específico, além da seleção de formatos governada por hardfork para determinar como blocos antigos devem ser republicados. A base de código agora tem dois tipos explicitamente separados, CanonicalTransaction e LedgerTransaction, separando a representação em memória de uma transação do formato em que ela realmente é persistida no ledger. Há até um teste de regressão dedicado apenas para decodificar corretamente transações anteriores à era Aegis durante a serialização de blocos.
Isso só se torna necessário quando a decodificação de transações precisa considerar diferentes eras de protocolo e estágios de processamento: recém-chegada da rede, vinda de um cliente, mantida em memória como um objeto canônico, e republicada a partir de um bloco que antecede as regras atuais.
O que significa que uma atualização de protocolo não é segura apenas porque as novas transações funcionam sob as novas regras. Ela só é segura se essas novas regras não quebrarem silenciosamente a capacidade de republicar corretamente o estado antigo do ledger sob as regras que o produziram. É essa classe de falha por incompatibilidade de versão — em que a republicação histórica não corresponde — que a compatibilidade de replay e a decodificação condicionada a hardfork foram desenhadas para prevenir.
“Uma transação só é confiável se cada etapa que a toca concordar sobre o que ela significa.”
O que eu realmente gostaria de ver: um replay real de um bloco pré-Aegis em um nó atual, sem alterar como suas transações históricas são decodificadas sob as regras aplicáveis — não apenas um teste de regressão que passa de forma isolada.
#dusk $DUSK @Dusk
O Boreas adicionou uma decodificação de transações com consciência de versão vinculada a um hardfork específico, além da seleção de formatos governada por hardfork para determinar como blocos antigos devem ser republicados. A base de código agora tem dois tipos explicitamente separados, CanonicalTransaction e LedgerTransaction, separando a representação em memória de uma transação do formato em que ela realmente é persistida no ledger. Há até um teste de regressão dedicado apenas para decodificar corretamente transações anteriores à era Aegis durante a serialização de blocos.
Isso só se torna necessário quando a decodificação de transações precisa considerar diferentes eras de protocolo e estágios de processamento: recém-chegada da rede, vinda de um cliente, mantida em memória como um objeto canônico, e republicada a partir de um bloco que antecede as regras atuais.
O que significa que uma atualização de protocolo não é segura apenas porque as novas transações funcionam sob as novas regras. Ela só é segura se essas novas regras não quebrarem silenciosamente a capacidade de republicar corretamente o estado antigo do ledger sob as regras que o produziram. É essa classe de falha por incompatibilidade de versão — em que a republicação histórica não corresponde — que a compatibilidade de replay e a decodificação condicionada a hardfork foram desenhadas para prevenir.
“Uma transação só é confiável se cada etapa que a toca concordar sobre o que ela significa.”
O que eu realmente gostaria de ver: um replay real de um bloco pré-Aegis em um nó atual, sem alterar como suas transações históricas são decodificadas sob as regras aplicáveis — não apenas um teste de regressão que passa de forma isolada.
#dusk $DUSK @Dusk
