Covenants e cofres: CTV, OP_CAT e o debate de 2026

Curiosidade

1. Por que um script padrão do Bitcoin pode verificar quem possui as chaves, mas não para onde as moedas vão em seguida?
2. Quais restrições específicas o OP_CHECKTEMPLATEVERIFY impõe às transações futuras?
3. Por que reativar um único opcode de concatenação, por meio de soft fork, abriria as portas para acordos?

Explorar

Parte IPropostas de covenants: CTV e OP_CAT

1. O scripting padrão do Bitcoin verifica a propriedade de uma chave ou hash, mas não consegue restringir para onde as moedas vão após serem desbloqueadas. Um “covenant” muda isso ao impor condições à `scriptPubKey` das saídas descendentes. Esse mecanismo é frequentemente comparado a vales-refeição: ao contrário do dinheiro, que pode ser gasto em qualquer lugar, esses recursos são restritos a restaurantes parceiros específicos. Os usos propostos incluem cofres com processos de saque diferidos, controle de congestionamento e designs mais simples para o Lightning Network.
2. Jeremy Rubin propôs o OP_CHECKTEMPLATEVERIFY (CTV) em 2019. Esse opcode incorpora um hash de um modelo de transação futura no UTXO atual. Para gastá-lo, a própria transação de gasto precisa corresponder exatamente a esse modelo; nenhuma assinatura é necessária na etapa de verificação. Isso determina o próximo passo antes mesmo da execução do atual. Qualquer desvio em valores, destinos ou estrutura do script faz com que a validação falhe imediatamente, garantindo uma adesão rigorosa ao caminho predefinido.
3. A limitação do CTV é a rigidez: as saídas da próxima transação são fixadas quando as moedas são bloqueadas, portanto as taxas precisam ser tratadas de outra maneira, por exemplo, com uma saída âncora e o princípio “filho paga pelo pai”. Em troca, o CTV é simples de analisar e barato de validar.
4. OP_CAT, um opcode que concatena dois itens da pilha, foi desativado por Satoshi Nakamoto em 2010 como medida de precaução contra ataques de esgotamento de memória. O BIP347 propõe sua reativação especificamente dentro do tapscript. Em combinação com truques de assinatura Schnorr, o OP_CAT permite a implementação de covenants e outras lógicas complexas sem a necessidade de novas regras de consenso para cada caso de uso específico. Ele fornece um bloco construtivo primitivo que os desenvolvedores podem combinar para criar restrições personalizadas em transações futuras.
5. Propostas relacionadas incluem a OP_CHECKSIGFROMSTACK (BIP348), que verifica uma assinatura em cima de uma mensagem arbitrária fornecida na pilha, em vez de em cima da transação de gasto. Essa flexibilidade, combinada com o CTV (ou, separadamente, o ANYPREVOUT proposto), permitiria canais Lightning simétricos nos quais nenhuma das partes precisaria armazenar dados de penalização para cada estado antigo do canal.
6. Até 2026, nenhuma dessas propostas de covenants havia sido ativada, embora os esforços e argumentos para sua ativação continuem. O debate persiste sobre sua utilidade, o risco que representam para as regras de consenso e o processo de governança necessário para a ativação. A expansão das regras de consenso levanta questões sobre a complexidade da rede e a manutenibilidade a longo prazo, que permanecem sem solução na comunidade.

Parte IICovenants e vaults: o debate em 2026

7. Os scripts do Bitcoin atualmente verificam condições da transação atual, como assinaturas ou tempos de bloqueio. Eles não conseguem inspecionar os outputs da transação de gasto. Os covenants estendem esse escopo: um scriptPubKey pode impor restrições ao scriptPubKey dos outputs criados pela transação que o gasta. Isso restringe para onde as moedas podem ir em seguida, permitindo funcionalidades como listas brancas de endereços e canais de pagamento não interativos.
8. O BIP-119 propõe o OP_CHECKTEMPLATEVERIFY (CTV). Ele permite que um script incorpore um hash de modelo; a transação de gasto deve corresponder a esse modelo em seus outputs, número de inputs, sequências, locktime e versão, mas não em quais inputs serão gastos. O CTV é não recursivo, ou seja, restringe apenas o próximo passo imediato. Ele substitui o OP_NOP4 e requer um soft fork. Pode servir de base para 'vaults', que adicionam uma espera à recuperação em caso de roubo.
9. Em um vault, os saques devem passar por um período de espera (por exemplo, 12 horas), durante o qual uma chave de recuperação separada pode varrer os fundos para um local seguro. Se um invasor roubar a chave do dia a dia e iniciar um saque, o proprietário vê isso on-chain e retoma os fundos antes que a espera termine. Isso transforma o roubo da chave de uma perda irreversível em um evento recuperável, desde que a vítima monitore a cadeia.
10. Apesar das discussões desde 2013, nenhum soft fork de covenants foi ativado. O Taproot (novembro de 2021) continua sendo o último grande upgrade. Em fevereiro de 2026, um cliente de ativação para o BIP-119 foi publicado sem envolvimento do Bitcoin Core. Ele requer sinalização de 90% dos mineradores entre março de 2026 e março de 2027. Até maio de 2026, a sinalização permanecia próxima de zero, indicando ausência de consenso quanto à adoção.
11. OP_CAT (BIP-347) teve sua especificação completa definida em março de 2026, mas carece de parâmetros de ativação. Ele permite a concatenação de elementos de script, possibilitando uma lógica mais complexa do que a do CTV sozinho. O CTV costuma ser combinado com CheckSigFromStack (CSFS), que verifica uma assinatura em dados arbitrários da pilha, e não apenas na transação de gasto. Juntos, eles oferecem ganhos significativos em termos de expressividade para contratos inteligentes e no design de protocolos.
12. O debate gira em torno de trade-offs: os covenants aprimoram a segurança e permitem novos protocolos, como vaults, mas introduzem complexidade e riscos de governança. Um soft fork altera as regras de consenso, exigindo amplo acordo entre mineradores e operadores de nós. A estagnação atual reflete cautela em relação a bugs na implementação e à irreversibilidade das mudanças no estado da cadeia. Os usuários devem ponderar esses ganhos contra o risco de uma ativação fracassada ou contestada.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• J. Rubin, OP_CHECKTEMPLATEVERIFY (BIP119), 2019-2020
• BIP347: OP_CAT in Tapscript (E. Heilman & A. Sabouri, 2023)
• BIP348: CHECKSIGFROMSTACK (B. Black & J. Rubin, 2024)
• Bitcoin Optech, 'Covenants' topic guide
• J. Rubin, BIP-119: OP_CHECKTEMPLATEVERIFY (2020)
• E. Heilman & A. Sabouri, BIP-347: OP_CAT in Tapscript (2024)
• Delving Bitcoin activation discussions (2026)