Bitcoin Core e outras implementações

Curiosidade

1. Quem decide o que é um bloco quando duas partes de código discordam?
2. Por que um pequeno erro no banco de dados tem o poder de dividir a cadeia ao meio?
3. O que acontece com a rede se a implementação mais popular simplesmente deixar de ser mantida?

Explorar

1. O Bitcoin começou como um único cliente em C++ desenvolvido por Satoshi Nakamoto. Em 2011, a interface foi reescrita usando as bibliotecas Qt, e o software passou a ser conhecido como Bitcoin-Qt. Até 2014, a versão 0.9 abandonou completamente o sufixo, tornando-se Bitcoin Core. A mudança de nome refletiu uma alteração na identidade do projeto: ele não era mais apenas a ferramenta de Satoshi, mas sim a implementação de referência oficial para as regras da rede.
2. A liderança do código-fonte passou de Gavin Andresen, que a liderou de 2010 até se afastar em 2014, para Wladimir van der Laan. Atualmente, um pequeno grupo de mantenedores funde as alterações após uma rigorosa revisão por pares. O esquema de versionamento saltou de 0,21 para 22,0 em 2021, sinalizando maturidade. Lançamentos importantes ocorrem aproximadamente duas vezes ao ano, sendo cada um submetido a testes extensivos antes da distribuição.
3. O consenso não se trata apenas de lógica; trata-se de um comportamento idêntico, byte por byte, em dezenas de milhares de nós. Em março de 2013, a versão 0.8 introduziu o LevelDB como seu mecanismo de armazenamento. Um bloco aceito pelo novo software foi rejeitado pelas versões mais antigas que utilizavam o Berkeley DB devido a um erro no limite de bloqueios. A cadeia se dividiu até os mineradores fazerem o downgrade, demonstrando que uma diferença oculta no comportamento, nem mesmo no próprio código do consenso, pode dividir a rede.
4. Existem implementações alternativas para evitar que um único codebase se torne um ponto de falha ou alvo de captura. O btcd é escrito em Go, o bcoin em JavaScript e o libbitcoin em C++. O Bitcoin Knots, mantido por Luke Dashjr, é um conjunto de patches sobre o Core com configurações padrão diferentes, notavelmente um filtramento mais rigoroso das transações que transportam dados. O Floresta utiliza a estrutura de dados Utreexo para uma verificação eficiente. Esses projetos servem como mecanismos de controle no processo de desenvolvimento do Core.
5. O risco de reimplantar o mecanismo de consenso é alto, pois um erro que aceite blocos inválidos pode levar a perdas financeiras ou à divisão da cadeia. Para mitigar isso, o libbitcoinkernel visa isolar a lógica central de consenso em uma biblioteca reutilizável. Isso permite que outros softwares verifiquem transações sem duplicar todo o código do nó, garantindo que as regras permaneçam consistentes mesmo com mudanças na infraestrutura circundante.
6. Execute 'bitcoin-cli getnetworkinfo' em um nó para ver sua própria versão, e 'getpeerinfo' para ver o software que cada peer relata (sua string 'subver'). A rede mantém a interoperabilidade apesar de usar diferentes pilhas de software, mas a dominância do Bitcoin Core significa que ele efetivamente define o ritmo das atualizações do protocolo. Nós que não fazem upgrade continuam seguindo a cadeia por meio de soft forks, mas um nó cujo comportamento de consenso diverge pode ser separado.

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.

• Bitcoin Core release notes for version 0.9.0 (2014)
• BIP50: March 2013 Chain Fork Post-Mortem
• Bitcoin Core release notes and documentation (bitcoincore.org)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 10