O resultado mais perigoso nem sempre é nós brigando entre si; é todos os nós chamarem o mesmo conjunto de código de verificação e, em seguida, verificarem errado de forma metódica e organizada.
Comparei os white papers históricos do @Dusk com a documentação atual. Materiais antigos chamavam esse runtime Rust/WASM de Piecrust; a documentação atual usa DuskVM. O nome evoluiu, mas o design central não mudou: contratos podem delegar verificações criptográficas como PLONK, Groth16, BLS etc. para a camada de host com um ponto de entrada público, sem que cada um precise implementar tudo separadamente.
As vantagens são bem práticas. Os desenvolvedores escrevem menos um conjunto de código criptográfico fácil de errar; os nós não precisam repetir as operações subjacentes no sandbox WASM; as aplicações ficam mais leves, e as regras de verificação ficam mais fáceis de padronizar.
O custo também se concentra. Se o contrato de aplicação tiver um erro, normalmente primeiro ele prejudica a si mesmo; mas se um verificador compartilhado errar na interpretação de entradas, na seleção de versão ou em condições de contorno, todos os contratos que dependem dele podem ser afetados. Em toda a rede, isso só prova que todos executaram a mesma regra.
No upgrade Aegis de março de 2026, o Dusk habilitou o comportamento do PLONK V3 e do novo BLS; a consulta do host BLS usada pelos contratos também muda conforme a altura do bloco. Blocos históricos chamam o validador antigo; dados novos usam a nova versão. Se a altura for escolhida errado, pode-se chegar a conclusões diferentes sobre a validade das transações.
Por isso, eu não vou me limitar a contar/avaliar relatórios de auditoria; também vou observar a versão do validador, as alturas de upgrade, os vetores de teste, a invalidação de cache e os exercícios de rollback. $DUSK assume o Gas e a segurança do consenso, mas quem sustenta as aplicações financeiras também são esses pontos públicos de verificação. A velocidade determina o quanto o sistema anda rápido; o validador determina se ele vai fazer o erro andar também, ainda mais rápido.
#dusk
Comparei os white papers históricos do @Dusk com a documentação atual. Materiais antigos chamavam esse runtime Rust/WASM de Piecrust; a documentação atual usa DuskVM. O nome evoluiu, mas o design central não mudou: contratos podem delegar verificações criptográficas como PLONK, Groth16, BLS etc. para a camada de host com um ponto de entrada público, sem que cada um precise implementar tudo separadamente.
As vantagens são bem práticas. Os desenvolvedores escrevem menos um conjunto de código criptográfico fácil de errar; os nós não precisam repetir as operações subjacentes no sandbox WASM; as aplicações ficam mais leves, e as regras de verificação ficam mais fáceis de padronizar.
O custo também se concentra. Se o contrato de aplicação tiver um erro, normalmente primeiro ele prejudica a si mesmo; mas se um verificador compartilhado errar na interpretação de entradas, na seleção de versão ou em condições de contorno, todos os contratos que dependem dele podem ser afetados. Em toda a rede, isso só prova que todos executaram a mesma regra.
No upgrade Aegis de março de 2026, o Dusk habilitou o comportamento do PLONK V3 e do novo BLS; a consulta do host BLS usada pelos contratos também muda conforme a altura do bloco. Blocos históricos chamam o validador antigo; dados novos usam a nova versão. Se a altura for escolhida errado, pode-se chegar a conclusões diferentes sobre a validade das transações.
Por isso, eu não vou me limitar a contar/avaliar relatórios de auditoria; também vou observar a versão do validador, as alturas de upgrade, os vetores de teste, a invalidação de cache e os exercícios de rollback. $DUSK assume o Gas e a segurança do consenso, mas quem sustenta as aplicações financeiras também são esses pontos públicos de verificação. A velocidade determina o quanto o sistema anda rápido; o validador determina se ele vai fazer o erro andar também, ainda mais rápido.
#dusk
