Ninguém pode contornar uma regra escrita dentro do próprio dinheiro

Num sistema comum, a regra de negócio e o movimento de dinheiro vivem em lugares diferentes. Uma aplicação verifica se uma transferência é permitida, e só depois manda o banco de dados registrar o resultado. Entre a verificação e o registro existe uma suposição de que os dois vão continuar de acordo, mas nada na arquitetura garante isso. Alguém pode escrever direto no banco, contornando a aplicação, e a regra nunca vai saber que foi violada.

Existe uma família de modelos de ledger onde essa separação não existe. Nela, o valor não é uma linha num banco de dados que uma aplicação decide alterar. É um objeto discreto, com uma condição de gasto anexada a ele desde o momento em que é criado. Essa condição, chamada de validador, não é chamada por uma aplicação. É executada pelo próprio protocolo, como parte do processo que decide se uma transação é aceita na cadeia de blocos ou rejeitada antes de existir.

O que muda quando a regra vira parte do dado

No modelo formalizado como Extended UTXO, ou eUTxO, cada saída de uma transação anterior carrega um endereço, que aponta para um validador específico, e um dado associado, chamado datum, que guarda o contexto necessário para aquele validador decidir se um gasto futuro é legítimo ([1]). Para gastar essa saída, uma nova transação precisa fornecer um argumento, o redeemer, e o validador então examina a transação inteira que está sendo construída, não apenas o valor sendo movido, para decidir se aceita ou recusa.

Isso significa que a regra de negócio não é código que roda antes do movimento de valor. É a definição do que conta como movimento válido. Uma transação que não satisfaz o validador correspondente não é bloqueada por uma camada de aplicação. Ela nunca chega a ser uma transação aceita, no mesmo sentido em que um cheque sem assinatura nunca chega a ser um cheque válido.

Conservação por construção, não por convenção

Um dos resultados formais do modelo eUTxO é que a soma dos valores consumidos pelas entradas de uma transação precisa ser exatamente igual à soma dos valores produzidos pelas saídas, e essa igualdade é verificada pelo próprio protocolo, não por uma convenção que os participantes concordam em seguir ([1]). Valor não desaparece nem aparece no meio do caminho porque o protocolo nunca aceitaria uma transação em que isso acontecesse.

É essa propriedade, mais do que qualquer decisão de interface ou de processo, que sustenta a diferença entre um sistema em que a atomicidade é uma prática recomendada e um sistema em que ela é uma consequência inevitável da forma como as transações são validadas.

O preço dessa garantia

A ressalva é honesta: validadores mais expressivos custam mais para escrever e mais para verificar do que uma checagem simples de saldo. O modelo eUTxO existe porque, historicamente, sistemas baseados em objetos como o Bitcoin sacrificavam expressividade em troca de simplicidade, e sistemas baseados em conta como o Ethereum faziam a troca inversa ([1]). Ganhar as duas coisas ao mesmo tempo, expressividade e a garantia estrutural de conservação, é o problema técnico que esse modelo resolve, não uma vantagem que vem de graça.