O que chamou minha atenção é que a atualização Boreas da Dusk tornou mais visível a execução de contratos que falharam, e não menos.
Desde a implantação do Boreas na mainnet em 10 de junho de 2026, no bloco 4.414.095, eventos de contrato revertidos ainda podem ser mantidos nos dados de arquivo com um marcador explícito “reverted”. Ao mesmo tempo, esses eventos falhos são removidos do bloom do bloco canônico, e eventos de stake revertidos são excluídos das atualizações de estado do provisioner.
Essa distinção importa mais do que parece à primeira vista.
Uma chamada revertida não deve alterar o estado canônico. Mas, para aplicações financeiras, apagar completamente o rastro do evento pode dificultar depuração, reconciliação e análise forense. A Dusk está separando “este evento aconteceu durante a execução” de “este evento passou a fazer parte de um estado válido”.
Eu esperava que uma cadeia com foco em privacidade minimizasse detalhes de execução retidos. Em vez disso, a DuskFoundation está preservando um rastro de auditoria mais claro para atividade de contratos com falha, mantendo o indexador canônico limpo.
Minha interpretação: é um detalhe pequeno de protocolo com relevância incomumente forte para finanças onchain regulamentadas. A auditabilidade não é apenas sobre ver transferências bem-sucedidas; é também sobre provar o que falhou e garantir que isso nunca contaminou o estado.
A pergunta que estou observando: os exploradores e as ferramentas institucionais vão apresentar claramente essa metainformação de evento revertido o suficiente para os usuários se beneficiarem dela?
@Dusk $DUSK #dusk
Desde a implantação do Boreas na mainnet em 10 de junho de 2026, no bloco 4.414.095, eventos de contrato revertidos ainda podem ser mantidos nos dados de arquivo com um marcador explícito “reverted”. Ao mesmo tempo, esses eventos falhos são removidos do bloom do bloco canônico, e eventos de stake revertidos são excluídos das atualizações de estado do provisioner.
Essa distinção importa mais do que parece à primeira vista.
Uma chamada revertida não deve alterar o estado canônico. Mas, para aplicações financeiras, apagar completamente o rastro do evento pode dificultar depuração, reconciliação e análise forense. A Dusk está separando “este evento aconteceu durante a execução” de “este evento passou a fazer parte de um estado válido”.
Eu esperava que uma cadeia com foco em privacidade minimizasse detalhes de execução retidos. Em vez disso, a DuskFoundation está preservando um rastro de auditoria mais claro para atividade de contratos com falha, mantendo o indexador canônico limpo.
Minha interpretação: é um detalhe pequeno de protocolo com relevância incomumente forte para finanças onchain regulamentadas. A auditabilidade não é apenas sobre ver transferências bem-sucedidas; é também sobre provar o que falhou e garantir que isso nunca contaminou o estado.
A pergunta que estou observando: os exploradores e as ferramentas institucionais vão apresentar claramente essa metainformação de evento revertido o suficiente para os usuários se beneficiarem dela?
@Dusk $DUSK #dusk
