Enquanto eu revisava uma atualização de testnet, encontrei dois arquivos genesis que passaram na validação, mas produziram hashes diferentes após a inicialização. A falha veio de um valor padrão de um módulo, não de transações ou saldos. Desde então, tenho tratado a migração como preservando a semântica, e não apenas mudando formatos.
A documentação do operador do Babylon indica que a migração ocorre entre o genesis de origem e o binário de destino. O comando altera o formato, o esquema e os parâmetros padrão e, em seguida, move o estado antigo da aplicação para uma nova estrutura para que possa ser lido de forma consistente. Essas três camadas mudam, mas btcstaking, checkpointing e finality não devem gerar histórico adicional.
O processo contém 7 etapas, com o ponto de parada ilustrado na altura do bloco 2000000. O Babylon interrompe a cadeia, exporta o estado final, cria um backup, executa a migração, valida o genesis, substitui o arquivo e atualiza o binário. Os validadores devem permanecer na mesma altura, porque uma diferença de um bloco deixa os estados exportados sem um ponto de partida comum.
Antes da conversão, os hashes de estado dos validadores são comparados com um hash-base. Em seguida, o Babylon verifica 3 módulos, btcstaking, checkpointing e finality, compara o chain id, a genesis time e o estado da aplicação, e então carrega o genesis por meio de uma execução em modo de simulação (dry run). A validação bem-sucedida confirma a estrutura, mas não prova que as invariantes da aplicação permanecem intactas.
Eu imagino o processo como substituir o leitor em um medidor de eletricidade. A codificação pode mudar, mas a leitura acumulada não pode voltar a zero nem pular uma unidade. O genesis é o mostrador, enquanto o estado é a quantidade de eletricidade já consumida.
Eu quero ver execuções de testnet usando dados próximos aos de produção, procedimentos de rollback ensaiados e indisponibilidade publicada. O Babylon tem um processo de controle razoável, mas um código de saída 0 não é suficiente para declarar a migração como bem-sucedida. Uma atualização muda como a rede lê os dados, não o que a rede já concordou anteriormente.
@BabylonLabs_io $BABY #baby
A documentação do operador do Babylon indica que a migração ocorre entre o genesis de origem e o binário de destino. O comando altera o formato, o esquema e os parâmetros padrão e, em seguida, move o estado antigo da aplicação para uma nova estrutura para que possa ser lido de forma consistente. Essas três camadas mudam, mas btcstaking, checkpointing e finality não devem gerar histórico adicional.
O processo contém 7 etapas, com o ponto de parada ilustrado na altura do bloco 2000000. O Babylon interrompe a cadeia, exporta o estado final, cria um backup, executa a migração, valida o genesis, substitui o arquivo e atualiza o binário. Os validadores devem permanecer na mesma altura, porque uma diferença de um bloco deixa os estados exportados sem um ponto de partida comum.
Antes da conversão, os hashes de estado dos validadores são comparados com um hash-base. Em seguida, o Babylon verifica 3 módulos, btcstaking, checkpointing e finality, compara o chain id, a genesis time e o estado da aplicação, e então carrega o genesis por meio de uma execução em modo de simulação (dry run). A validação bem-sucedida confirma a estrutura, mas não prova que as invariantes da aplicação permanecem intactas.
Eu imagino o processo como substituir o leitor em um medidor de eletricidade. A codificação pode mudar, mas a leitura acumulada não pode voltar a zero nem pular uma unidade. O genesis é o mostrador, enquanto o estado é a quantidade de eletricidade já consumida.
Eu quero ver execuções de testnet usando dados próximos aos de produção, procedimentos de rollback ensaiados e indisponibilidade publicada. O Babylon tem um processo de controle razoável, mas um código de saída 0 não é suficiente para declarar a migração como bem-sucedida. Uma atualização muda como a rede lê os dados, não o que a rede já concordou anteriormente.
@BabylonLabs_io $BABY #baby