A questão central: Por baixo do binário, verificar a confiança

Quando a maioria das pessoas descarrega o Bitcoin Core, a sua interação com o sistema de construção termina em poucos cliques. Elas obtêm o binário executável do software, verificam uma assinatura (esperamos!), e começam a rodar um nó Bitcoin. O que veem imediatamente é o software em execução. O que não veem é o sistema de construção e os processos extensos que produziram esse software. Um sistema de construção que representa os princípios de descentralização, transparência e verificabilidade do Bitcoin.

Por trás desse download, estão anos de trabalho de engenharia projetados para responder a uma pergunta simples: “Por que alguém deveria confiar neste software?” A resposta é: não deveria precisar. Você deve poder verificar.

Num momento em que ataques à cadeia de suprimentos de software fazem manchetes globais, desde pacotes npm comprometidos, bibliotecas com backdoors, servidores CI ilegítimos, o processo de construção do Bitcoin Core permanece como um projeto silencioso de disciplina. Seus métodos podem parecer lentos e complicados em comparação com a conveniência sem atritos do “push to deploy”, mas esse é o ponto. Segurança não é conveniente.

Para entender o sistema de construção do Bitcoin Core, devemos compreender:

• Filosofia do Sistema de Construção do Bitcoin Core

• Builds Reprodutíveis

• Minimização de Dependências

• Sem Atualizações Automáticas

• Integração Contínua

• Adaptação Contínua

Filosofia do Sistema de Construção do Bitcoin Core

Quando se trata da descentralização do Bitcoin, a maioria das pessoas foca em mineradores, nós e desenvolvedores. Mas a descentralização não termina nos participantes do protocolo. Ela se estende à forma como o software é construído e distribuído.

Um princípio no ecossistema do Bitcoin é “não confiar, verificar”. Rodar seu próprio nó é um ato de verificação, checando cada bloco e transação de acordo com as regras de consenso. Mas o sistema de construção em si oferece outra oportunidade de verificar, ao nível do software. O Bitcoin é dinheiro sem intermediários confiáveis, e o Bitcoin Core trabalha para ser um software sem construtores confiáveis. O sistema de construção faz grandes esforços para garantir que qualquer pessoa, em qualquer lugar, possa recriar de forma independente os mesmos binários que aparecem no site bitcoincore.org.

Essa filosofia remonta ao ensaio de Ken Thompson de 1984, Reflections on Trusting Trust, que alertava que mesmo um código fonte aparentemente limpo não pode ser confiável se o compilador que construiu esse software estiver comprometido. Os desenvolvedores do Bitcoin levaram essa lição a sério. Nas palavras do colaborador do Bitcoin Core Michael Ford (fanquake):

“Builds reprodutíveis são essenciais, porque nenhum usuário do nosso software deveria precisar confiar que o que está dentro é exatamente o que dizemos que é. Isso deve sempre ser verificável de forma independente.”

Uma declaração que é tanto uma meta técnica quanto parte do ethos do Bitcoin.

No mundo da segurança, fala-se sobre “superfícies de ataque”. O sistema de construção do Bitcoin Core trata o próprio processo de construção como uma superfície de ataque a ser minimizada e defendida.

Builds Reprodutíveis: Verificação até o mais profundo

O processo de produção de uma versão do Bitcoin Core começa com o código-fonte de código aberto no GitHub. Cada alteração é pública. Cada solicitação de pull é revisada. Mas a jornada do código legível por humanos até o software binário executável envolve compiladores, bibliotecas de terceiros e sistemas operacionais, que também podem ser vetores de adulteração, backdoors ou erros.

“Terceiros confiáveis são buracos de segurança” – Nick Szabo (2001)

Para resolver essas preocupações, o arquiteto do Bitcoin Core criou um pipeline de processo de construção usando Guix, um gerenciador de pacotes projetado para criar ambientes de software reprodutíveis e determinísticos.

Quando uma nova versão do Bitcoin Core é marcada, múltiplos colaboradores independentes constroem os binários do zero usando Guix. Cada construtor trabalha em um ambiente isolado que garante ferramentas, versões de compilador e bibliotecas do sistema idênticas. Se todos os construtores produzirem saídas idênticas, eles sabem que a construção é determinística.

Depois, os colaboradores assinam criptograficamente os binários resultantes e publicam essas assinaturas em um repositório separado no GitHub, ‘guix.sigs’, que lista essas attestations para cada versão do Bitcoin Core. Alguns construtores são desenvolvedores do Bitcoin Core, mas não é obrigatório, pois o processo de attestação é aberto a qualquer pessoa do público. Na verdade, muitos não-contribuidores de código contribuem regularmente com assinaturas.

Esse processo é conhecido como builds reprodutíveis, e é o antídoto contra o “trusting trust” de Thompson. Significa que qualquer pessoa pode pegar o código-fonte aberto, o mesmo ambiente Guix, e confirmar de forma independente que o binário oficial corresponde ao que ela mesma construiu. Embora builds reprodutíveis possam verificar se o software é uma representação genuína do código fonte, a correção do software fica a cargo de processos de testes rigorosos e revisão de código.

A maioria das pessoas nunca realizará uma compilação completa ou verificará os manifests do Guix ou comparará hashes de build. Elas não precisam. A existência dessa infraestrutura, e as pessoas que a mantêm, fornecem a cada usuário uma base de confiança conquistada.

Os binários oficiais no bitcoincore.org não são apenas “produzidos pelos mantenedores do Bitcoin Core”. São o resultado de dezenas de construtores independentes. O que você eventualmente baixa é o que todos os outros construíram e verificaram como autêntico.

É verificação até o mais profundo.

Minimização de Dependências: Menos para confiar

A reprodutibilidade é uma parte da equação. A outra é minimizar o que precisa ser reproduzido. O código do Bitcoin Core não é o único que é executado ao rodar o Bitcoin Core. Ele também depende de código externo de terceiros e bibliotecas para acelerar o desenvolvimento e a produtividade.

Nos últimos dez anos, os desenvolvedores do Bitcoin Core têm removido progressivamente essas dependências externas desnecessárias e às vezes problemáticas, como OpenSSL e MiniUPnP. Seja uma biblioteca externa ou uma ferramenta, essas dependências aumentam a complexidade ou carregam suposições ocultas. Projetos como Boost e Libevent, que eram essenciais na base do código, estão sendo gradualmente eliminados ou substituídos por alternativas mais simples e autossuficientes.

Por quê? Porque toda dependência que você herda é um potencial risco na cadeia de suprimentos. É mais código que você não escreveu, não audita e não consegue controlar completamente. Reduzir dependências torna o sistema de construção mais enxuto, mais seguro e mais fácil de verificar.

Recentemente, a Brink destacou esse esforço em seu post no blog “Minimizing Dependencies”[1], observando que não se trata apenas de simplicidade, mas de preservar a segurança e autonomia do projeto. Cada dependência removida é uma menos que o projeto precisa confiar e uma menor possibilidade de backdoor.

O objetivo final é produzir binários totalmente estáticos: executáveis que contenham tudo o que precisam para rodar, sem dependências dinâmicas ou em tempo de execução. Essa autossuficiência significa que não há necessidade de bibliotecas externas que possam variar de um sistema operacional para outro.

Num mundo onde a maior parte do software fica mais pesado e mais dependente de ecossistemas de pacotes centralizados, o Bitcoin Core caminha na direção oposta: rumo ao minimalismo e à independência.

Sem Atualizações Automáticas

Na maioria do software moderno, os usuários estão protegidos das decisões sobre qual versão do software atualizar ou se devem atualizar. Você instala um aplicativo, e ele se atualiza silenciosamente e automaticamente para as versões mais recentes em segundo plano. Embora seja conveniente, isso é contrário à filosofia do Bitcoin Core.

O Bitcoin Core nunca incluiu atualizações automáticas, e os desenvolvedores disseram que nunca incluirão. Atualizações automáticas concentram poder. Criam um grupo único que pode empurrar (potencialmente malicioso) código para todos os nós da rede. Essa é exatamente a centralização que o Bitcoin foi criado para evitar. Exigindo que os usuários baixem, verifiquem e instalem manualmente novas versões, o Bitcoin Core reforça a responsabilidade individual e o consentimento verificável.

O sistema de construção e a ausência de atualizações automáticas são duas partes do mesmo princípio. Somente o operador do nó decide o que rodar e pode verificar se o software que está sendo executado é autêntico.

Integração Contínua: Vá devagar e corrija as coisas

No Vale do Silício, integração contínua e implantação contínua (CI/CD) são marcas do desenvolvimento ágil de software. Envie rápido. Faça melhorias mais rápidas. Deixe a automação cuidar do resto.

O Bitcoin Core adota uma abordagem diferente. Seus sistemas de CI existem não para acelerar a implantação, mas para proteger a integridade. Builds automatizados testam a consistência entre plataformas. O sistema de construção do Bitcoin Core é projetado para ser o mais agnóstico possível em relação ao hardware e sistemas operacionais. O projeto consegue construir binários para Linux, macOS e Windows, além de múltiplas arquiteturas, incluindo x86_64, aarch64 (ARM) e até riscv64. O sistema de integração contínua garante essa compatibilidade, bem como a integridade do software, realizando centenas de testes para cada mudança proposta.

O resultado é uma cultura onde “integração contínua” significa testes contínuos, verificação e segurança, não inovação contínua.

Vá devagar e corrija as coisas.

Adaptação Contínua: Já terminamos?

O sistema de construção não é estático. Os desenvolvedores continuam a refiná-lo, reduzindo dependências, melhorando construções multiplataforma e explorando um futuro de construção totalmente estática, com zero dependências em tempo de execução.

Embora o sistema de construção do Bitcoin Core busque determinismo, ele não pode ser estático. O mundo em que opera está em constante mudança. Sistemas operacionais, compiladores, bibliotecas e arquiteturas de hardware evoluem. Cada nova versão do macOS ou glibc, cada descontinuação de uma flag de compilador ou surgimento de uma nova arquitetura de CPU traz incompatibilidades sutis que precisam ser resolvidas. Um sistema de construção que permanecesse parado, com o tempo, deixaria de conseguir construir.

O paradoxo dos builds reprodutíveis é que eles exigem evolução contínua para permanecer reprodutíveis. Os desenvolvedores precisam constantemente ajustar, corrigir e às vezes substituir ferramentas para preservar o determinismo diante de um cenário em mudança. Manter esse equilíbrio entre estabilidade e adaptação faz parte da resiliência contínua do Bitcoin.

Adquira hoje sua cópia de The Core Issue!

Não perca a chance de possuir The Core Issue — com artigos escritos por muitos desenvolvedores do Core explicando os projetos em que trabalham!

Este artigo é a Carta do Editor, apresentada na última edição impressa da Bitcoin Magazine, The Core Issue. Compartilhamos aqui uma prévia das ideias exploradas na edição completa.

[1]