MATT e OP_CHECKCONTRACTVERIFY: como o Bitcoin pode transportar estado entre transações

Segundo o Cointelegraph, o MATT (Merkleize All The Things) é um framework de smart contract para Bitcoin que permite contratos com estado e provas de fraude escaláveis. Um contrato com estado transporta informações de uma transação para a seguinte, podendo atualizar esses dados à medida que o contrato evolui. Os scripts padrão do Bitcoin não oferecem essa capacidade, pois cada transação é avaliada de forma independente, sem memória das execuções anteriores.

Todas as propostas de covenant permitem, em certa medida, que UTXOs carreguem estado, como demonstrado por linguagens de script como Sapio, que se baseia no opcode OP_CTV. Nesse modelo, endereços representam um autômato finito e as transações funcionam como transições de estado. Contudo, a implementação elegante de lógica numérica permanece ausente, lacuna que o MATT preenche, especialmente por meio da sua implementação proposta via OP_CHECKCONTRACTVERIFY (OP_CCV).

Para compreender a proposta, é útil revisar como o Taproot incorpora dados por meio de chaves públicas. Cada saída Taproot contém uma chave pública base, chamada chave interna, que pode ser modificada criptograficamente – ou “tweaked” – para comprometer informações adicionais. Formalmente, a chave modificada é Q = P + t·G, onde P é a chave interna, G o gerador da curva secp256k1 e t um hash etiquetado da chave interna e dos dados comprometidos.

Em uma saída Taproot regular, esse compromisso costuma codificar a raiz Merkle de uma taptree que contém caminhos de gasto ocultos. O MATT aproveita esse mecanismo para também inserir o estado do contrato na chave. Em vez de codificar lógica complexa diretamente na linguagem de script do Bitcoin, o MATT representa a computação como uma sequência de compromissos de estado, e a cadeia verifica apenas se cada transição de estado é válida.

A realização prática do MATT pode usar diferentes combinações de opcodes, sendo a implementação mais direta e bem especificada baseada no OP_CHECKCONTRACTVERIFY (OP_CCV). O OP_CCV fornece a primitiva que torna viáveis UTXOs que carregam estado dentro do Taproot. Ele permite que um script verifique se a chave de entrada ou saída Taproot foi modificada para comprometer um pedaço específico de dados de estado, primeiro ajustando a chave interna com um hash do estado atual e, em seguida, aplicando o tweak padrão da taptree.

O OP_CCV também impõe qual estado será transportado para a próxima saída. Ele permite que o script examine os dados de estado fornecidos na pilha de testemunho, execute cálculos sobre eles e exija que o estado atualizado seja corretamente re-comprometido em uma saída especificada. O opcode suporta três modos para verificação de saída e um modo separado para entrada: no modo padrão, todo o valor BTC da UTXO de entrada é alocado para a saída indicada; no modo ‘deduct’, apenas uma parte igual ao valor da saída é atribuída, deixando o restante disponível para outras saídas; no modo ‘ignore’, o script e o compromisso de dados são verificados sem restringir o valor.

Como os modos padrão e deduct são projetados para preservar o valor nas saídas verificadas, as taxas de transação precisam ser pagas por meio de entradas dedicadas ao pagamento de taxas. Uma entrada de taxa e uma saída de troco podem ser adicionadas à transação sem conflitar com as restrições do covenant. Essa abordagem evita a queima acidental de fundos que pode ocorrer em implementações de covenant mais primitivas, como OP_CTV ou SIGHASH_ANYPREVOUT, e resolve a limitação dos covenants baseados em transações pré-assinadas, que normalmente definem valores antecipadamente e não acomodam ajustes dinâmicos de taxa ou desbloqueios parciais.

Quando o OP_CCV é combinado com o opcode OP_CAT, que permite concatenação de bytes no Script, o framework MATT torna-se ainda mais expressivo. O OP_CAT possibilita a construção e verificação de provas Merkle diretamente on-chain. Nesse arranjo, duas árvores Merkle distintas são associadas a uma saída Taproot: a primeira, a árvore de script familiar (taptree), cujas folhas são os scripts de gasto do contrato; a segunda, uma árvore de estado separada, cujas folhas contêm os dados do contrato, como etapas intermediárias de um cálculo.

O script OP_CCV + OP_CAT pode verificar uma prova Merkle contra a raiz atual da árvore de estado, calcular a raiz atualizada após a transição e usar o OP_CCV para forçar que a próxima saída comprometa essa nova raiz. Essa construção permite sistemas de prova de fraude com condição de slashing, nos quais um cálculo extenso é comprometido fora da cadeia e apenas o passo contestado, juntamente com seu caminho na árvore binária, precisa ser revelado e verificado on-chain.

Sistemas semelhantes existem como rollups otimistas em outras blockchains: o cálculo completo ocorre off-chain e o contrato on-chain intervém somente quando alguém levanta um desafio. As provas de fraude exigem que o cálculo seja compilado em um circuito binário ou representação passo a passo que possa ser comprometida em uma árvore Merkle. O uso conjunto de OP_CCV e OP_CAT elimina a necessidade de assinaturas de uso único de Lamport e de grafos de transações pré-assinadas que o BitVM utiliza para garantir a consistência do estado.

Além das provas de fraude, a combinação OP_CCV + OP_CAT tem implicações para cofres (vaults). O OP_CCV isoladamente já pode implementar cofres, mas ao ser combinado com OP_CAT permite cofres totalmente funcionais, essencialmente equivalentes à funcionalidade proposta pelo OP_VAULT. Como afirmou James O’Beirne, autor do OP_VAULT, “OP_CCV representa um design mais geral e robusto que supera efetivamente minha proposta anterior” (em tradução livre).

No próximo artigo da série, a atenção se voltará dos covenants gerais para opcodes específicos de aplicação, como OP_VAULT, OP_UNVAULT e OP_EVICT, cada um projetado para resolver um problema concreto em vez de oferecer programabilidade ampla.