Um arquivo de “pôr do sol” pode voltar na altura de bloco certa e ainda assim falhar a única requisição que minha aplicação de blob realmente precisa: me dê o sidecar.

Transações de blob deixam um hash de blob KZG versionado na cadeia, mas a carga útil é recuperada separadamente via Rusk por hash de blob ou por compromisso. Isso significa que o registro da cadeia e o corpo do blob não vivem na mesma suposição de recuperação.

A ferramenta de arquivamento torna essa separação explícita. Objetos de blob são armazenados separadamente, a cobertura é comprovada em intervalos contíguos de blocos, e um checkpoint de arquivo só está completo quando seu estado correspondente, os dados do arquivo e a cobertura de blobs se alinham.

Então, se eu fizer backup do estado da cadeia e dos índices do arquivo, mas tratar o armazenamento de blobs como um cache descartável, a recuperação pode parecer saudável. Os blocos estão lá. Os hashes das transações estão lá. Minha aplicação pede um sidecar antigo e não recebe nada.

Essa é a falha que eu testaria antes de chamar um arquivo de Dusk como restaurado. Pegue um blob histórico finalizado, resolva o hash reportado pela cadeia, busque o sidecar e então verifique seu compromisso e prova.

Para mim, “bloco restaurado” não é “dados restaurados” quando a aplicação depende das cargas úteis de blobs do Dusk.

#dusk $DUSK @Dusk