Na ecossistema Dusk, as transações podem ser oficialmente reconhecidas pelo sistema, sendo que a velocidade na verdade não é o fator decisivo. O verdadeiro entrave está em—se ela passou ou não pelo sistema de provas. Se a prova não passar, essa transação na cadeia é praticamente inútil.

A Dusk segue uma abordagem mais rigorosa. Assim que uma transação é iniciada, ela deve atender a múltiplos conjuntos de restrições simultaneamente. O mais importante é que essas restrições não são verificadas apenas na fase de execução de forma temporária, mas são incorporadas diretamente na lógica de prova. O estado dos ativos, as condições da conta, a coerência entre as regras—tudo isso é interceptado na fase de prova. Não há operações de "executar primeiro e reverter depois", nem oportunidades de "alterar o estado primeiro e explicar posteriormente".

A característica mais robusta dessa abordagem é que a Dusk define o "conflito de regras" também como um estado de falha que pode ser provado. Muitas regras de sistemas tradicionais só são descobertas pelos usuários após o lançamento, levando a reparos emergenciais. O mecanismo da Dusk força você a expressar claramente as regras antes que a transação ocorra. Se as regras forem ambíguas, a prova não pode ser gerada, e a transação simplesmente não entra no sistema. Em outras palavras, o sistema rejeita regras ambíguas e só aceita conjuntos de regras que possam ser provados como válidos.

Isso também explica por que a lógica de conformidade da Dusk é mais parecida com uma "restrição rígida" do que uma "promessa flexível". Conformidade não é uma frase de marketing, nem algo controlado por um interruptor no backend, mas a primeira barreira que a transação deve passar. Sem passar por essa barreira, a transação nem mesmo tem direito de avançar para a fase de mudança de estado.

O ponto crucial agora é observar se a Dusk consegue manter essa abordagem até o fim. Ou seja, se toda mudança de estado precisa passar por uma verificação de restrições de prova, e se existe alguma maneira de contornar a prova para modificar o estado diretamente. Segurar essas duas linhas é o que realmente transforma regras complexas em fatos do sistema, e não apenas em uma visão idealizada na documentação.