O que falta ao Bitcoin e em quem você confia para acrescentar

Curiosidade

1. Por que o Bitcoin não tem um equivalente a um token de “aprovação”?
2. O que se perde quando uma linguagem de script se torna expressiva o suficiente para compilar qualquer programa?
3. Como um mercado pode existir sem uma parte central que detenha as chaves ou estabeleça as regras?

Explorar

Parte IO que o Bitcoin já elimina e o que lhe falta

1. O Bitcoin elimina o administrador. Não existem chaves de administração, nem aprovações de tokens, nem contratos que possam ser atualizados. A emissão é limitada a 21 milhões de moedas, com um cronograma previsível, e o subsídio é reduzido pela metade a cada 210.000 blocos. As regras só mudam por meio de consenso amplo entre milhares de nós independentes. Esse design elimina um tipo de ataque encontrado em outros sistemas: se não há chave para roubar e nenhum contrato para atualizar, não há nada que um administrador possa explorar ou que uma empresa possa confiscar.
2. O modelo UTXO torna cada gasto explícito. Uma transação consome determinados outputs anteriores e cria novos. Não existem saldos de conta que um contrato possa debitar posteriormente. Essa estrutura impede as aprovações do tipo “drenador”, nas quais um usuário assina uma permissão ampla que permite a outra parte movimentar fundos ilimitados mais tarde. Com o tipo de assinatura padrão (SIGHASH_ALL), a assinatura compromete-se com esses inputs e outputs exatos; outros modos de assinatura podem deixar os outputs abertos, e golpes têm explorado isso. Se o usuário não assinar a próxima transação, nada se move.
3. O que o Bitcoin não tem é expressividade e velocidade. O script é deliberadamente limitado; ele não pode realizar cálculos arbitrários ou entrar em loops indefinidamente. Os blocos chegam aproximadamente a cada dez minutos, o que significa que o processo de liquidação é lento em comparação com cadeias que geram blocos em segundos. Não há suporte nativo para tokens ou mercados dentro do protocolo da camada básica. Essas restrições são trade-offs intencionais: limitar o que o script pode fazer impede que erros se tornem exploits capazes de quebrar o consenso, e blocos mais lentos permitem uma validação robusta por parte de uma rede descentralizada de nós completos.
4. A questão de design é como adicionar novos mercados sem reintroduzir as fraquezas que o Bitcoin evitou. A adição de uma linguagem de script complexa gera vulnerabilidades nos contratos inteligentes. A inclusão de blocos mais rápidos geralmente requer centralização ou validadores autorizados para manter a finalidade. A introdução de tokens nativos pode criar novas superfícies de ataque para inflação ou manipulação. Qualquer extensão deve preservar o fato de que nenhuma entidade única controla a emissão ou as regras do ativo, mesmo que isso signifique aceitar processamentos mais lentos ou taxas mais altas.
5. As soluções de camada 2 e os metaprotocolos tentam preencher essa lacuna. Eles adicionam funcionalidades como pagamentos rápidos ou emissão de tokens, ao mesmo tempo em que garantem a segurança com base no consenso do Bitcoin. No entanto, essas camadas introduzem novos modelos de confiança: alguns dependem de federações de signatários, outros de jogos de verificação otimistas, nos quais pelo menos um operador honesto precisa combater a fraude. Cada abordagem compromete aspectos diferentes de descentralização e velocidade. O objetivo não é transformar o Bitcoin em um computador de uso geral, mas sim ampliar sua utilidade sem comprometer o modelo de segurança que o torna resiliente.
6. Abra um explorador de blocos e procure por alguma transação recente. Examine as entradas e saídas. Observe como cada entrada faz referência a uma saída específica anterior por meio do seu ID de transação e índice. Agora compare isso com uma cadeia baseada em contas, onde os saldos são apenas números em um estado global. A diferença é estrutural: o modelo do Bitcoin obriga que todo movimento de valor seja explícito, auditável e vinculado a uma assinatura específica, não deixando espaço para substituições administrativas ocultas ou permissões amplas.

Parte IICamadas 2 do Bitcoin e seus modelos de confiança

7. Os canais da Lightning Network ampliam a capacidade de pagamento do Bitcoin sem transferir as moedas para um custodiante. O white paper de Joseph Poon e Thaddeus Dryja foi inicialmente redigido em 2015 e publicado em sua versão final em 2016; seu uso na mainnet ocorreu em 2018. Cada canal bloqueia os fundos em um estado entre duas partes; se uma delas fraudar, a outra transmite uma transação punitiva para o Bitcoin. Esse modelo minimiza a necessidade de confiança, pois nenhuma terceira parte possui as chaves, mas continua sendo ponto-a-ponto. Ele resolve o problema da finalização dos pagamentos, mas não a questão da liquidez compartilhada ou da criação de mercado.
8. Liquid, lançado pela Blockstream em 2018, funciona como uma sidechain federada. Um grupo fixo de 'funcionários' assina os blocos e gerencia o peg entre os ativos do Liquid e o Bitcoin da camada base. Os blocos são criados a cada minuto e confirmam definitivamente em cerca de dois minutos, sendo que os ativos podem ser emitidos de forma nativa. O trade-off é explícito: os usuários precisam confiar que uma supermaioria dos funcionários (o peg utiliza uma multisignature de 11 em 15) não se combinará para roubar depósitos ou interromper resgates. É rápido, mas reintroduz a necessidade de um grupo confiável.
9. O Stacks opera sua própria cadeia, ancorada ao Bitcoin por meio do registro dos hashes de seus blocos em transações do Bitcoin (Proof of Transfer). Seu peg sBTC, aberto para depósitos a partir de dezembro de 2024 e retiradas a partir de abril de 2025, emite tokens respaldados por bitcoins nativos bloqueados e gerenciados por um conjunto de signatários. Essa abordagem permite a criação de contratos inteligentes expressivos no Stacks (em Clarity, uma linguagem deliberadamente decidível), enquanto um grupo de signatários, cujo número mínimo deve aprovar as retiradas, detém os bitcoins. Os usuários trocam flexibilidade na execução pela confiança na integridade desse grupo de signatários e pela continuidade operacional da ponte.
10. O BitVM representa uma escolha arquitetônica diferente, visando levar a computação geral ao Bitcoin sem soft forks. A proposta de Robin Linus em 2023 utilizou verificação otimista entre duas partes; o BitVM2 (2024) permite que qualquer pessoa faça desafios. Projetos como Citrea, ativo desde janeiro de 2026, são baseados nesse modelo, no qual um participante honesto entre muitos pode impedir fraudes. Esse modelo de 'honestidade 1-em-n' transfere a confiança do consenso majoritário para a presença de um único desafiador vigilante, mas os operadores precisam bloquear ou disponibilizar capital próprio, e as retiradas aguardam o término das janelas de desafio.
11. Comparar esses modelos revela perfis de risco distintos. O Lightning não requer terceiros, mas oferece utilidade limitada para mercados compartilhados. O Liquid e o Stacks dependem de federações ou conjuntos de signatários, onde a colusão é a principal ameaça. Os rollups do BitVM dependem da honestidade competitiva entre os operadores. A variável crítica em todos os casos é a custódia: quem detém as chaves privadas do Bitcoin subjacente e o que acontece se essa entidade falhar, for hackeada ou decidir cometer fraude.
12. Os mecanismos de saída definem o verdadeiro modelo de confiança. No Lightning, sair significa fechar o canal on-chain; se a outra parte não responder, os fundos são devolvidos após um timelock. No Liquid ou Stacks, a saída requer um pedido de resgate processado pela federação ou pelos signatários; se eles atrasarem ou recusarem, os usuários ficam presos. Nas pontes BitVM, a saída depende de pelo menos um operador ativo para pagar o usuário; as reivindicações de reembolso dos operadores então passam por um período de desafio. Um usuário que não pode sair sem confiar em terceiros não é verdadeiramente autogestor (self-custody), independentemente de quão descentralizada pareça a rede.

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.

• S. Nakamoto, 'Bitcoin: A Peer-to-Peer Electronic Cash System' (2008)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)
• BIP-341: Taproot (activated 2021)
• J. Poon & T. Dryja, 'The Bitcoin Lightning Network' (2016)
• Blockstream Liquid Documentation
• Stacks sBTC Technical Documentation (December 2024)
• R. Linus, 'BitVM: Compute Anything on Bitcoin' (2023)