BitVM e o problema da ponte

Curiosidade

1. Como o Bitcoin pode impor o resultado de um cálculo arbitrário sem executar o código na cadeia?
2. Por que um jogo de desafio-resposta construído com scripts Taproot permite verificação quase completa de Turing sem necessidade de soft fork?
3. Qual é o trade-off de segurança quando a liveness depende de alguém observando para contestar uma reivindicação fraudulenta?

Explorar

Parte IBitVM

1. As regras de consenso do Bitcoin excluem intencionalmente a execução arbitrária de código. Esse design previne vulnerabilidades em contratos inteligentes complexos, mas limita os scripts a condições como assinaturas, multisig, timelocks e hashlocks. Em outubro de 2023, Robin Linus introduziu o BitVM, um protocolo que permite cálculos fora da blockchain, mantendo o resultado final verificável dentro dela. Ele permite que as partes bloqueiem bitcoins em uma transação, onde o gasto depende de um cálculo externo realizado fora da cadeia de blocos.
2. O mecanismo central replica um portão lógico NAND usando os códigos de operação existentes do Bitcoin: OP_BOOLAND atua como um portão AND, e OP_NOT atua como um portão NOT. Como os portões NAND são universais, circuitos construídos a partir deles podem, em princípio, realizar qualquer tipo de cálculo, tudo sem alterar as regras de consenso. Essa abordagem transfere o ônus computacional para fora da cadeia, mantendo ao mesmo tempo a segurança dentro dela.
3. Essas sequências complexas de cálculo NAND são armazenadas como folhas dentro da Árvore de Sintaxe Abstrata Merkleizada (MAST) de uma transação Taproot. Isso aproveita os ganhos em privacidade e eficiência proporcionados pelo Taproot, que foi ativado em novembro de 2021 no bloco 709.632, permitindo que scripts complexos permaneçam ocultos até serem necessários. A estrutura suporta as grandes árvores de script exigidas para jogos de verificação em várias etapas.
4. Se o provador afirmar um resultado fraudulento proveniente do cálculo fora da cadeia, o verificador pode contestá-lo dentro da cadeia. O provador deve então responder ao desafio; se algum passo for considerado inconsistente ou o provador não responder a tempo, o verificador fica com os fundos bloqueados.
5. A primeira versão funcionava entre duas partes, mas o BitVM2 (2024) permite que qualquer pessoa conteste uma reivindicação, avançando em direção à verificação sem permissões. O principal objetivo são pontes com confiança minimizada, nas quais o bitcoin bloqueado na cadeia pode ser liberado somente se um estado reivindicado de outro sistema for válido.
6. Os principais limites são a configuração complexa, as grandes exigências de dados fora da cadeia e as suposições relativas à liveness. Alguém precisa estar atentamente monitorando para contestar reivindicações fraudulentas dentro do prazo estipulado; caso ninguém o faça, um estado incorreto pode ser consolidado.

Parte IIBitVM e o problema da ponte

7. As regras de consenso do Bitcoin verificam assinaturas e a validade dos UTXOs, mas não podem executar transições de estado arbitrárias off-chain. Transferir valor para um layer two exige uma bridge que ancore o estado da cadeia externa ao Bitcoin. As bridges tradicionais dependem de federações de signatários; se a maioria coludir, os usuários perdem seus fundos. Esse modelo centralizado de confiança contradiz o design permissionless do Bitcoin, criando a necessidade de mecanismos que minimizem o risco custodial sem alterar as regras de consenso.
8. Robin Linus apresentou o BitVM em outubro de 2023, demonstrando como a computação arbitrária pode ser verificada on-chain por meio de jogos de desafio otimistas. O protocolo decompõe a lógica complexa em operações bit a bit, especificamente portas NAND, que são universais para circuitos digitais. Essas operações são codificadas dentro da estrutura MAST de uma transação Taproot. O Bitcoin não executa o programa completo; em vez disso, verifica a correção das etapas individuais apenas se uma disputa for levantada.
9. O BitVM opera com uma premissa otimista: as computações são corretas por padrão, a menos que se prove o contrário. Se um operador submeter uma transição de estado inválida, outro participante pode submeter uma contra-prova para contestá-la. Isso desloca o modelo de confiança de uma federação confiável para uma premissa de honestidade 1-de-n. Pelo menos um validador honesto deve existir para detectar fraudes. Embora isso reduza o risco de colusão em comparação com as federações, exige que alguém fique vigilante e esteja pronto para arcar com os custos de um desafio.
10. O mecanismo incorre em custos significativos. Os operadores desembolsam seu próprio capital para pagar saques e recuperá-lo posteriormente, imobilizando a liquidez. As transações de desafio são grandes devido à complexidade das provas bit a bit, consumindo espaço considerável no bloco. Além disso, muitas implementações usam valores fixos (peg) para simplificar o gerenciamento do estado, limitando a flexibilidade. Essas restrições significam que, embora o BitVM seja trust-minimized, ele não é trustless; os usuários ainda dependem dos incentivos econômicos e da correção técnica do protocolo de desafio.
11. Desenvolvimentos recentes como o BitVM2 refinam esses desafios, reduzindo o tamanho das transações e melhorando a eficiência. Projetos como o Citrea constroem rollups usando esse framework, visando garantias de segurança nas quais uma única parte honesta pode prevenir fraudes. No entanto, o problema da bridge persiste: o Bitcoin não consegue interpretar nativamente as raízes de estado de outras cadeias. A bridge é um jogo com incentivos construído sobre o Bitcoin, e não algo que o próprio Bitcoin impõe. Os usuários devem pesar o risco reduzido de colusão contra a maior complexidade e os requisitos de capital.
12. Ao inspecionar uma transação baseada em BitVM, sua estrutura é revelada. Abra um explorador de blocos e localize uma saída Taproot associada a uma bridge de rollup. O Taproot oculta os caminhos de script não utilizados, de modo que apenas o caminho realmente gasto é revelado; em caso de disputa, esse caminho carrega muito mais dados de witness do que uma assinatura simples. Essa diferença tangível no peso da transação reflete a sobrecarga computacional de manter a segurança otimista no espaço fixo de blocos do Bitcoin.

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.

• R. Linus, 'BitVM: Compute Anything on Bitcoin' (October 2023)
• R. Linus et al., 'BitVM2: Bridging Bitcoin to Second Layers' (2024)
• Bitcoin Optech, 'Accountable Computing Contracts' topic page (BitVM)
• Citrea Clementine bridge documentation
• BIP-341: Taproot