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 compilação fica resolvida em poucos cliques. Pegam no ficheiro executável do software, verificam uma assinatura (esperemos!), e começam a executar um nó Bitcoin. O que veem imediatamente é software em funcionamento. O que não veem é o sistema de compilação e os processos extensivos que produziram esse software. Um sistema de compilação que representa os princípios do Bitcoin de descentralização, transparência e verificabilidade.

Por trás desse download estão anos de trabalho de engenharia concebidos para responder a uma pergunta simples: “Por que razão alguém deveria confiar neste software?” A resposta é: não deveria ser necessário. Deveria conseguir verificar.

Numa altura em que os ataques à cadeia de abastecimento de software fazem manchetes globais, desde pacotes npm comprometidos, a bibliotecas com backdoors, servidores CI desviados (rogue), o processo de compilação do Bitcoin Core surge como um projeto discreto de disciplina. Os seus métodos podem parecer lentos e complicados face à conveniência sem atrito de “fazer push para distribuir”, mas é precisamente esse o ponto. A segurança não é conveniente.

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

• Filosofia do sistema de compilação do Bitcoin Core
• Compilações reproduzíveis
• Minimizar dependências
• Sem atualizações automáticas
• Integração contínua
• Adaptação contínua

Filosofia do sistema de compilação do Bitcoin Core

Quando se trata da descentralização do Bitcoin, a maioria das pessoas concentra-se em mineradores, nós e programadores. Mas a descentralização não termina nos participantes do protocolo. Estende-se à forma como o próprio software é construído e distribuído.

Um princípio no ecossistema do Bitcoin é “não confies, verifica”. Executar o teu próprio nó é um ato de verificação, conferindo cada bloco e transação face às regras de consenso. Mas o sistema de compilação em si dá-te outra oportunidade de verificar, ao nível do software. O Bitcoin é dinheiro sem intermediários confiáveis e o Bitcoin Core trabalha para ser software sem construtores confiáveis. O sistema de compilação leva a cabo um grande esforço para garantir que qualquer pessoa, em qualquer lugar, consiga recriar de forma independente exatamente os mesmos binários que aparecem no sítio bitcoincore.org.

Esta filosofia remonta ao ensaio de 1984 de Ken Thompson Reflections on Trusting Trust, que alertava que mesmo um código-fonte com aspeto limpo não pode ser confiado se o compilador que construiu esse software tiver sido ele próprio comprometido. Os programadores do Bitcoin levaram essa lição a sério. Nas palavras de Michael Ford, colaborador do Bitcoin Core (fanquake):

“Compilações reproduzíveis são críticas, porque nenhum utilizador do nosso software deveria ter de confiar no que está lá dentro ser aquilo que dizemos que é. Isto tem de ser sempre verificável de forma independente.”

Uma declaração que é simultaneamente um objetivo técnico e parte da ética do Bitcoin.

No mundo da segurança, as pessoas falam sobre “superfícies de ataque” (attack surfaces). O sistema de compilação do Bitcoin Core trata o próprio processo de compilação como uma superfície de ataque a ser minimizada e defendida.

Compilações reproduzíveis: Verificação até ao fundo

O processo de produzir uma versão do Bitcoin Core começa com a base de código open-source no GitHub. Cada alteração é pública. Cada pedido de pull é revisto. Mas a viagem do código legível por humanos para o software binário executável envolve compiladores, bibliotecas de terceiros e sistemas operativos que, por si próprios, são vetores potenciais para adulteração, backdoors ou erros.

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

Para responder a essas preocupações, o arquiteto do Bitcoin Core desenhou um processo de compilação em pipeline usando Guix, um gestor de pacotes concebido para criar ambientes de software reproduzíveis e determinísticos.

Quando é assinalada uma nova versão do Bitcoin Core, vários contribuidores independentes compilam os binários do zero usando Guix. Cada construtor trabalha num ambiente isolado que garante toolchains idênticas, versões de compilador e bibliotecas do sistema. Se todos os construtores produzirem saídas com bits idênticos, sabem que a compilação é determinística.

Os contribuidores assinam depois criptograficamente os binários resultantes e publicam essas assinaturas num repositório GitHub separado, ‘guix.sigs’, que lista essas atestações para cada versão do Bitcoin Core. Alguns construtores são programadores do Bitcoin Core, mas não é um requisito; o processo de atestação está aberto a qualquer pessoa do público. Na verdade, muitos contribuidores não ligados ao código fornecem regularmente assinaturas.

Este processo é conhecido como compilações reproduzíveis e é o antídoto para o “trusting trust” de Thompson. Significa que qualquer pessoa pode pegar no código open-source, no mesmo ambiente Guix, e confirmar de forma independente que o binário oficial corresponde ao que construiu por si. Embora as compilações reproduzíveis possam verificar que o software é uma representação genuína do código-fonte do software, a correção do software fica a cargo de processos em torno de testes exaustivos e revisão de código.

A maioria das pessoas nunca irá fazer uma compilação completa nem verificar os manifests do Guix nem comparar hashes de compilação. Não é necessário. A existência dessa infraestrutura, e as pessoas que a mantêm, dá a cada utilizador uma base de confiança conquistada.

Os binários oficiais em bitcoincore.org não são apenas “produzidos pelos mantenedores do Bitcoin Core”. São a interseção das saídas de dezenas de construtores independentes. O que acabas por descarregar é aquilo que todos os outros construíram e verificaram como autêntico.

É verificação até ao fim.

Minimizar Dependências: Menos para Confiar

A reprodutibilidade é um lado da equação. O outro é minimizar o que precisa de ser reproduzido. O código do Bitcoin Core não é o único código executado ao executar o Bitcoin Core. O Bitcoin Core também depende de código e bibliotecas externas de terceiros para acelerar o desenvolvimento e aumentar a produtividade.

Ao longo da última década, os programadores do Bitcoin Core foram removendo de forma constante essas dependências de terceiros desnecessárias e por vezes problemáticas, como OpenSSL e MiniUPnP. Quer seja uma biblioteca externa ou um toolkit, essas dependências acrescentam complexidade ou introduzem suposições escondidas. Projetos como Boost e Libevent, que antes eram elementos base do código do Core, estão a ser gradualmente substituídos ou colocados de lado por alternativas mais simples e autónomas.

Porquê? Porque cada dependência que herdas é um potencial risco para a cadeia de abastecimento. É mais código que não escreveste, não auditaste e não consegues controlar completamente. Ao reduzir dependências, o sistema de compilação fica mais leve, mais seguro e mais fácil de verificar.

A Brink destacou recentemente este esforço no seu artigo no blogue “Minimizing Dependencies”[1], observando que não é apenas uma questão de simplicidade; é sobre preservar a segurança e a autonomia do projeto. Cada dependência removida é uma entidade externa a menos que o projeto precisa de confiar e uma oportunidade a menos para um backdoor.

O objetivo final é produzir binários totalmente estáticos: executáveis que contêm tudo o que é necessário para correr, sem dependências dinâmicas nem em tempo de execução. Essa capacidade de “autocontenção” significa ausência de dependência de bibliotecas externas que poderiam divergir de um sistema operativo para outro.

Num mundo em que a maior parte do software fica mais pesado e mais dependente de ecossistemas centralizados de pacotes, o Bitcoin Core está a mover-se no sentido oposto: rumo ao minimalismo e à independência.

Sem Atualizações Automáticas

Na maior parte do software moderno, os utilizadores ficam protegidos das decisões de para que versão do software atualizar, ou mesmo de se devem atualizar o software. Instalas uma aplicação e ela atualiza-se silenciosamente e automaticamente para as versões mais recentes em segundo plano. Embora seja conveniente, está em contradição com a filosofia do Bitcoin Core.

O Bitcoin Core nunca incluiu atualizações automáticas e os programadores disseram que nunca irá incluir. As atualizações automáticas concentram poder. Criam um único grupo que pode enviar código (potencialmente malicioso) para todos os nós da rede. Isto é exatamente o tipo de controlo centralizado que o Bitcoin foi criado para evitar. Ao exigir que os utilizadores descarreguem, verifiquem e instalem manualmente novas versões, o Bitcoin Core reforça a responsabilidade individual e o consentimento verificável.

O sistema de compilação e a ausência de atualizações automáticas são duas metades do mesmo princípio. Apenas quem executa o nó decide o que correr e pode verificar que o software executado é autêntico.

Integração Contínua: Andar devagar e corrigir as coisas

No Vale do Silício, integração contínua e entrega contínua (CI/CD) são as marcas do desenvolvimento ágil de software. Lançar rápido. Iterar ainda mais rápido. Deixar que a automação trate do resto.

O Bitcoin Core adota uma abordagem diferente. Os seus sistemas de CI existem não para acelerar a distribuição, mas para salvaguardar a integridade. As compilações automatizadas testam a consistência entre plataformas. O sistema de compilação do Bitcoin Core é desenhado para ser, tanto quanto possível, independente de hardware e sistemas operativos. O projeto pode compilar binários para Linux, macOS e Windows, bem como para múltiplas arquiteturas, incluindo x86_64, aarch64 (ARM) e até riscv64. O sistema de integração contínua garante esta compatibilidade, bem como a integridade do software, ao executar centenas de testes para cada alteração proposta.

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

Andar devagar e corrigir as coisas.

Adaptação Contínua: Já acabámos?

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

Embora o sistema de compilação do Bitcoin Core procure a determinismo, o próprio sistema de compilação não pode ser estático. O mundo em que opera está constantemente a mudar. Sistemas operativos, compiladores, bibliotecas e arquiteturas de hardware mudam. Cada nova versão do macOS ou do glibc, cada descontinuação (deprecação) de uma flag de compilador, ou cada arquitetura de CPU emergente introduz incompatibilidades subtis que têm de ser tratadas. Um sistema de compilação que ficasse parado deixaria, com o tempo, de compilar totalmente.

O paradoxo das compilações reproduzíveis é que elas exigem evolução contínua para permanecerem reproduzíveis. Os programadores têm de fixar versões, aplicar patches e, por vezes, substituir toolchains para preservar o determinismo perante um cenário em mudança. Manter este equilíbrio entre estabilidade e adaptabilidade faz parte da resiliência contínua do Bitcoin.

Obtém hoje a tua cópia do The Core Issue!

Não percas a tua oportunidade de seres dono de The Core Issue — com artigos escritos por muitos Core Developers a explicar os projetos em que trabalham por si!

Este texto é a Carta do Editor em destaque na mais recente edição Print da Bitcoin Magazine, The Core Issue. Estamos a partilhá-la aqui como uma antevisão inicial das ideias exploradas ao longo de todo o número.

[1]