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 termina em poucos cliques. Obtêm o 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 para a descentralização, transparência e verificabilidade.

Por trás desse download está trabalho de engenharia de anos, concebido para responder a uma pergunta simples: “Porque é que alguém deveria confiar neste software?” A resposta é: não devia. Deve conseguir-se verificá-lo.

Numa época em que os ataques à cadeia de fornecimento de software fazem manchetes globais, desde pacotes npm comprometidos, a bibliotecas com backdoors, servidores CI criminosos, o processo de compilação do Bitcoin Core surge como um projeto silencioso de disciplina. Os seus métodos podem parecer lentos e complicados em comparação com a comodidade sem fricção de “enviar para implementar”, mas é precisamente esse o ponto. A segurança não é conveniente.

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

• A 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

A filosofia do sistema de compilação do Bitcoin Core

No que toca à descentralização do Bitcoin, a maioria das pessoas foca-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 Bitcoin é “não confiar, verificar”. Executar o seu próprio nó é um ato de verificação, ao comparar cada bloco e transação com as regras de consenso. Mas o sistema de compilação em si oferece-lhe outra oportunidade de verificar, a 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 grandes esforços para garantir que qualquer pessoa, em qualquer lugar, possa recriar de forma independente exatamente as mesmas binaries que aparecem no website 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 aparência limpa não pode ser confiável se o compilador que construiu esse software tiver sido comprometido. Os programadores do Bitcoin levaram essa lição a sério. Nas palavras do contribuinte do Bitcoin Core Michael Ford (fanquake):

“As compilações reproduzíveis são críticas, porque nenhum utilizador do nosso software deve ter de confiar em que aquilo que está contido é exatamente o que dizemos que é. Isto tem de ser sempre verificável de forma independente.”

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

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

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

O processo de produzir um lançamento (release) 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 ao software executável envolve compiladores, bibliotecas de terceiros e sistemas operativos que, por si, são vetores potenciais para adulteração, backdoors ou erros.

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

Para abordar estas preocupações, o arquiteto do Bitcoin Core concebeu um pipeline de processo de compilação usando Guix, um gestor de pacotes desenhado para criar ambientes de software reproduzíveis e determinísticos.

Quando um novo lançamento do Bitcoin Core é marcado (tag), múltiplos contribuidores independentes compilam as binaries do zero usando Guix. Cada construtor (builder) trabalha num ambiente isolado que garante toolchains idênticas, versões do compilador e bibliotecas do sistema. Se todos os construtores produzirem saídas com exatamente os mesmos bits, sabem que a compilação é determinística.

Os contribuidores assinam então criptograficamente as binaries resultantes e publicam essas assinaturas num repositório GitHub separado, ‘guix.sigs’, que lista essas atestações para cada release 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. De facto, muitos contribuidores que não fazem código contribuem regularmente com assinaturas.

Este processo é conhecido como compilações reproduzíveis e é o antídoto para o “confiar em confiar” de Thompson. Significa que qualquer pessoa pode pegar no código open source, no mesmo ambiente Guix, e confirmar de forma independente que a binary oficial corresponde àquilo 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 completos e revisão de código.

A maioria das pessoas nunca fará uma compilação completa nem verificará os manifestos do Guix ou 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 obtida.

As binaries oficiais em bitcoincore.org não são apenas “produzidas pelos mantenedores do Bitcoin Core”. São a interseção das saídas de dezenas de construtores independentes. O que acaba 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 dos lados 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 quando se executa o Bitcoin Core. O Bitcoin Core também depende de código e bibliotecas externos de terceiros para acelerar o desenvolvimento e aumentar a produtividade.

Ao longo da última década, os programadores do Bitcoin Core têm vindo, de forma constante, a remover estas dependências externas desnecessárias e por vezes problemáticas, como OpenSSL e MiniUPnP. Quer se trate de uma biblioteca ou kit de ferramentas externo, estas dependências acrescentam complexidade ou introduzem pressupostos ocultos. Projetos como Boost e Libevent, que antes eram base do código do Core, estão a ser gradualmente eliminados ou substituídos por alternativas mais simples e auto-contidas.

Porquê? Porque cada dependência que herda é um risco potencial de cadeia de fornecimento. É mais código que não escreveu, não auditou e não consegue controlar totalmente. Reduzir dependências torna o sistema de compilação 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 se trata apenas de simplicidade, mas sim de preservar a segurança e a autonomia do projeto. Cada dependência removida é uma parte externa a quem o projeto tem de confiar a menos, e um potencial a menos para um backdoor.

O objetivo final é produzir binaries totalmente estáticas: executáveis que contêm tudo o que é necessário para executar, sem dependências dinâmicas ou em tempo de execução. Esta auto-suficiência significa ausência de dependência de bibliotecas externas que poderiam diferir de um sistema operativo para outro.

Num mundo em que a maior parte do software se torna 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 são protegidos das decisões sobre para que versão do software atualizar, ou sobre se devem, ou não, atualizar o software. Instala-se uma aplicação e, silenciosa e automaticamente, ela atualiza-se para as versões mais recentes em segundo plano. Embora seja conveniente, é contrário à filosofia do Bitcoin Core.

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

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

Integração contínua: avançar devagar e corrigir as coisas

No Vale do Silício, integração contínua e implementação contínua (CI/CD) são as marcas da produção ágil de software. Enviar rápido. Iterar ainda mais rápido. Deixar que a automação faça o resto.

O Bitcoin Core adota uma abordagem diferente. Os seus sistemas de CI existem não para acelerar a implementação, mas para salvaguardar a integridade. As compilações automatizadas testam a consistência entre plataformas. O sistema de compilação do Bitcoin Core foi desenhado para ser agnóstico a hardware e sistemas operativos, tanto quanto possível. O projeto pode compilar binaries 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 assegura essa 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.

Avançar devagar e corrigir as coisas.

Adaptação contínua: Já terminá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á em constante mudança. Sistemas operativos, compiladores, bibliotecas e arquiteturas de hardware mudam. Cada novo release do macOS ou do glibc, cada descontinuação (deprecação) de uma opção de compilador, ou cada arquitetura de CPU emergente introduz incompatibilidades subtis que precisam de ser abordadas. Um sistema de compilação que permanecesse parado deixaria, com o tempo, de compilar de todo.

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

Obtenha hoje o seu exemplar de The Core Issue!

Não perca a sua oportunidade de possuir The Core Issue — com artigos escritos por muitos Core Developers que explicam os projetos nos quais trabalham!

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

[1]