Lorsque la plupart des gens téléchargent Bitcoin Core, leur interaction avec le système de build se termine en quelques clics. Ils récupèrent le binaire exécutable du logiciel, vérifient une signature (espérons-le !) et commencent à exécuter un nœud Bitcoin. Ce qu’ils voient immédiatement, c’est un logiciel en cours d’exécution. Ce qu’ils ne voient pas, c’est le système de construction et les processus approfondis qui ont produit ce logiciel. Un système de construction qui représente les principes de décentralisation, de transparence et de vérifiabilité de Bitcoin.
Derrière ce téléchargement se cachent des années de travail d’ingénierie conçu pour répondre à une question simple : «Pourquoi devrait-on faire confiance à ce logiciel ? » La réponse est : vous ne devriez pas avoir à le faire. Vous devriez pouvoir vérifier.
À une époque où les attaques contre la chaîne d’approvisionnement logicielle font la une des journaux mondiaux, qu’il s’agisse de packages NPM compromis, de bibliothèques dérobées ou de serveurs CI malveillants, le processus de construction de Bitcoin Core se présente comme un projet discret de discipline. Ses méthodes peuvent sembler lentes et compliquées par rapport à la commodité sans friction du « push to déployer », mais c’est là le point. La sécurité n’est pas pratique.
Pour comprendre le système de construction de Bitcoin Core, nous devons comprendre :
- Philosophie du système de construction de Bitcoin Core
- Constructions reproductibles
- Minimiser les dépendances
- Aucune mise à jour automatique
- Intégration continue
- Adaptation en cours
Philosophie du système de construction de Bitcoin Core
Lorsqu’il s’agit de décentralisation de Bitcoin, la plupart des gens se concentrent sur les mineurs, les nœuds et les développeurs. Mais la décentralisation ne s’arrête pas aux participants au protocole. Cela s’étend à la manière dont le logiciel lui-même est construit et distribué.
L’un des principes de l’écosystème Bitcoin est « ne faites pas confiance, vérifiez ». Exécuter votre propre nœud est un acte de vérification, vérifiant chaque bloc et transaction par rapport aux règles de consensus. Mais le système de build lui-même vous offre une autre opportunité de vérification, au niveau logiciel. Bitcoin, c’est de l’argent sans intermédiaires de confiance et Bitcoin Core fonctionne comme un logiciel sans constructeurs de confiance. Le système de construction prend beaucoup de temps pour garantir que n’importe qui, n’importe où, puisse recréer indépendamment exactement les mêmes binaires qui apparaissent sur le site Web bitcoincore.org.
Cette philosophie remonte à l’essai de Ken Thompson de 1984 Réflexions sur la confiancequi avertissait que même un code source d’apparence épurée n’était pas fiable si le compilateur qui a construit ce logiciel était lui-même compromis. Les développeurs de Bitcoin ont pris cette leçon à cœur. Selon les mots de Michael Ford (fanquake), contributeur de Bitcoin Core :
« Les versions reproductibles sont essentielles, car aucun utilisateur de notre logiciel ne devrait avoir à croire que ce qui est contenu à l’intérieur est ce que nous prétendons être. Cela doit toujours être vérifiable de manière indépendante. »
Une déclaration qui est à la fois un objectif technique et une partie de la philosophie Bitcoin.
Dans le monde de la sécurité, on parle de « surfaces d’attaque ». Le système de construction de Bitcoin Core traite le processus de construction lui-même comme une surface d’attaque à minimiser et à défendre.
Builds reproductibles : vérification jusqu’au bout
Le processus de production d’une version Bitcoin Core commence par la base de code open source sur GitHub. Chaque changement est public. Chaque demande de tirage est examinée. Mais le voyage depuis le lisible par l’homme code au binaire exécutable logiciel implique des compilateurs, des bibliothèques tierces et des systèmes d’exploitation qui sont eux-mêmes des vecteurs potentiels de falsification, de portes dérobées ou d’erreurs.
« Les tiers de confiance sont des failles de sécurité» – Nick Szabo (2001)
Pour répondre à ces préoccupations, Bitcoin Core a architecturé un pipeline de processus de construction à l’aide de Guix, un gestionnaire de packages conçu pour créer des environnements logiciels reproductibles et déterministes.
Lorsqu’une nouvelle version de Bitcoin Core est taguée, plusieurs contributeurs indépendants créent les binaires à partir de zéro à l’aide de Guix. Chaque constructeur fonctionne dans un environnement isolé qui garantit des chaînes d’outils, des versions de compilateur et des bibliothèques système identiques. Si tous les constructeurs produisent des sorties de bits identiques, ils savent que la construction est déterministe.
Les contributeurs signent ensuite cryptographiquement les binaires résultants et publient ces signatures sur un référentiel GitHub distinct « guix.sigs » qui répertorie ces attestations pour chaque version de Bitcoin Core. Certains constructeurs sont des développeurs Bitcoin Core, mais ce n’est pas une exigence car le processus d’attestation est ouvert à toute personne du public. En fait, de nombreux contributeurs non-codeurs apportent régulièrement des signatures.
Ce processus est connu sous le nom de builds reproductibles et constitue l’antidote à la « confiance confiante » de Thompson. Cela signifie que n’importe qui peut prendre le code open source, le même environnement Guix, et confirmer indépendamment que le binaire officiel correspond à ce qu’il a lui-même construit. Bien que des versions reproductibles puissent vérifier que le logiciel est une représentation authentique du code source du logiciel, l’exactitude du logiciel est laissée à des processus de tests approfondis et de révision du code.
La plupart des gens n’effectueront jamais une compilation complète, ne vérifieront jamais les manifestes Guix ou ne compareront jamais les hachages de build. Ils n’en ont pas besoin. L’existence de cette infrastructure et les personnes qui la maintiennent donnent à chaque utilisateur une base de confiance méritée.
Les binaires officiels sur bitcoincore.org ne sont pas seulement « produits par les mainteneurs de Bitcoin Core ». Ils sont le croisement de dizaines de réalisations de constructeurs indépendants. Ce que vous téléchargez finalement est ce que tout le monde a construit et dont l’authenticité a été vérifiée.
C’est une vérification jusqu’au bout.
Minimiser les dépendances : moins de confiance
La reproductibilité est un côté de l’équation. L’autre consiste à minimiser ce qui doit être reproduit. Le code de Bitcoin Core n’est pas le seul code exécuté lors de l’exécution de Bitcoin Core. Bitcoin Core s’appuie également sur du code et des bibliothèques externes tiers pour accélérer le développement et la productivité.
Au cours de la dernière décennie, les développeurs de Bitcoin Core ont progressivement supprimé ces dépendances tierces inutiles et parfois problématiques, comme OpenSSL et MiniUPnP. Qu’il s’agisse d’une bibliothèque externe ou d’une boîte à outils, ces dépendances ajoutent de la complexité ou importent des hypothèses cachées. Des projets comme Boost et Libevent, autrefois incontournables de la base de code de Core, sont progressivement supprimés ou remplacés par des alternatives plus simples et autonomes.
Pourquoi? Parce que chaque dépendance dont vous héritez constitue un risque potentiel pour la chaîne d’approvisionnement. Il s’agit davantage de code que vous n’avez pas écrit, que vous n’auditez pas et que vous ne pouvez pas contrôler entièrement. La réduction des dépendances rend le système de build plus simple, plus sûr et plus facile à vérifier.
Brink a récemment souligné cet effort dans son article de blog « Minimiser les dépendances ».[1]précisant qu’il ne s’agit pas seulement de simplicité, il s’agit de préserver la sécurité et l’autonomie du projet. Chaque dépendance supprimée représente une partie externe de moins à laquelle le projet doit faire confiance et un potentiel de porte dérobée de moins.
L’objectif final est de produire des binaires entièrement statiques : des exécutables contenant tout ce dont ils ont besoin pour s’exécuter, sans dépendances dynamiques ou d’exécution. Cette autonomie signifie ne pas dépendre de bibliothèques externes qui pourraient différer d’un système d’exploitation à l’autre.
Dans un monde où la plupart des logiciels deviennent plus lourds et plus dépendants d’écosystèmes de packages centralisés, Bitcoin Core évolue dans la direction opposée : vers le minimalisme et l’indépendance.
Aucune mise à jour automatique
Dans la plupart des logiciels modernes, les utilisateurs ne peuvent pas décider de la version du logiciel vers laquelle mettre à jour, ni même décider de mettre à jour le logiciel. Vous installez une application et elle se met à jour silencieusement et automatiquement vers les dernières versions en arrière-plan. Bien que cela soit pratique, cela va à l’encontre de la philosophie de Bitcoin Core.
Bitcoin Core n’a jamais inclus de mises à jour automatiques et les développeurs ont déclaré que cela ne le ferait jamais. Les mises à jour automatiques concentrent la puissance. Ils créent un groupe unique qui peut transmettre du code (potentiellement malveillant) à chaque nœud du réseau. C’est exactement le genre de contrôle centralisé que Bitcoin a été conçu pour éviter. En obligeant les utilisateurs à télécharger, vérifier et installer manuellement les nouvelles versions, Bitcoin Core renforce la responsabilité individuelle et le consentement vérifiable.
Le système de build et l’absence de mises à jour automatiques sont les deux moitiés du même principe. Seul le nœud d’exécution décide quoi exécuter et peut vérifier que le logiciel exécuté est authentique.
Intégration continue : avancez lentement et réparez les choses
Dans la Silicon Valley, l’intégration continue et le déploiement continu (CI/CD) sont les caractéristiques du développement logiciel agile. Expédier rapidement. Itérez plus rapidement. Laissez l’automatisation faire le reste.
Bitcoin Core adopte une approche différente. Ses systèmes CI existent non pas pour accélérer le déploiement mais pour sauvegarder l’intégrité. Les builds automatisés testent la cohérence entre les plates-formes. Le système de construction de Bitcoin Core est conçu pour être autant que possible indépendant du matériel et des systèmes d’exploitation. Le projet peut créer des binaires pour Linux, macOS et Windows ainsi que pour plusieurs architectures, notamment x86_64, aarch64 (ARM) et même riscv64. Le système d’intégration continue garantit cette compatibilité ainsi que l’intégrité du logiciel en effectuant des centaines de tests pour chaque changement proposé.
Le résultat est une culture où « intégration continue » signifie tests, vérifications et sécurité continus, et non innovation continue.
Avancez lentement et réparez les choses.
Adaptation en cours : avons-nous déjà terminé ?
Le système de construction n’est pas statique. Les développeurs continuent de l’affiner en réduisant les dépendances, en améliorant les versions multi-architectures et en explorant un avenir de construction entièrement statique sans dépendance d’exécution.
Bien que le système de construction de Bitcoin Core s’efforce d’atteindre le déterminisme, le système de construction lui-même ne peut pas être statique. Le monde dans lequel il opère est en constante évolution. Les systèmes d’exploitation, les compilateurs, les bibliothèques et les architectures matérielles changent tous. Chaque nouvelle version de macOS ou de la glibc, chaque dépréciation d’un indicateur du compilateur ou une architecture CPU émergente introduit des incompatibilités subtiles qui doivent être résolues. Un système de construction qui restait immobile cesserait, avec le temps, de se construire.
Le paradoxe des constructions reproductibles est qu’elles nécessitent une évolution continue pour rester reproductibles. Les développeurs doivent constamment épingler, corriger et parfois remplacer les chaînes d’outils pour préserver le déterminisme dans un contexte de changement changeant. Le maintien de cet équilibre entre stabilité et adaptabilité fait partie de la résilience continue de Bitcoin.
Ne manquez pas votre chance de posséder La question centrale — présentant des articles rédigés par de nombreux développeurs principaux expliquant les projets sur lesquels ils travaillent eux-mêmes !
Cet article est la lettre de l’éditeur présentée dans la dernière édition imprimée du magazine Bitcoin, The Core Issue. Nous le partageons ici comme un premier aperçu des idées explorées tout au long du numéro complet.
[1] https://brink.dev/blog/2025/09/19/minimizing-dependencies/