Bitcoin Core et autres implémentations

Curiosité

1. Qui décide de ce qu’est un bloc lorsque deux programmes sont en désaccord ?
2. Pourquoi une simple erreur de base de données a-t-elle le pouvoir de couper la chaîne en deux ?
3. Qu’advient-il du réseau si l’implémentation la plus utilisée cesse tout simplement d’être maintenue ?

Explorer

1. Bitcoin a débuté sous la forme d’un client C++ unique écrit par Satoshi Nakamoto. En 2011, l’interface a été réécrite avec les bibliothèques Qt et le logiciel a pris le nom de Bitcoin-Qt. En 2014, avec la version 0.9, il avait entièrement abandonné ce suffixe pour devenir Bitcoin Core. Ce changement de nom traduisait un changement d’identité : il ne s’agissait plus seulement de l’outil de Satoshi, mais de l’implémentation de référence canonique des règles du réseau.
2. La direction du code est passée de Gavin Andresen, qui l’a dirigé de 2010 jusqu’à son retrait en 2014, à Wladimir van der Laan. Aujourd’hui, un petit groupe de mainteneurs fusionne les modifications après une revue rigoureuse par les pairs. La numérotation des versions est passée de 0.21 à 22.0 en 2021, signe de maturité. Les versions majeures paraissent environ deux fois par an, chacune étant soumise à des tests approfondis avant sa diffusion.
3. Le consensus n’est pas qu’une affaire de logique : il exige un comportement identique, octet pour octet, sur des dizaines de milliers de nœuds. En mars 2013, la version 0.8 a introduit LevelDB comme moteur de stockage. Un bloc accepté par le nouveau logiciel a été rejeté par les versions plus anciennes fonctionnant sous Berkeley DB, à cause d’un bug de limite de verrous. La chaîne est restée scindée jusqu’à ce que les mineurs reviennent à une version antérieure, ce qui montre qu’une différence de comportement cachée, qui ne se trouvait même pas dans le code de consensus lui-même, peut diviser le réseau.
4. Des implémentations alternatives existent pour éviter qu’une base de code unique ne devienne un point de défaillance ou de capture. btcd est écrit en Go, bcoin en JavaScript et libbitcoin en C++. Bitcoin Knots, maintenu par Luke Dashjr, est un ensemble de correctifs appliqué à Core avec des paramètres par défaut différents, notamment un filtrage plus strict des transactions transportant des données. Floresta utilise la structure de données Utreexo pour une vérification efficace. Ces projets servent de contrepoids au processus de développement de Core.
5. Réimplémenter le consensus est très risqué, car un bug qui accepte des blocs invalides peut entraîner des pertes financières ou des scissions de la chaîne. Pour limiter ce risque, libbitcoinkernel vise à isoler la logique de consensus centrale dans une bibliothèque réutilisable. D’autres logiciels peuvent ainsi vérifier les transactions sans dupliquer tout le code du nœud, ce qui garantit que les règles restent cohérentes même lorsque l’infrastructure environnante évolue.
6. Exécutez « bitcoin-cli getnetworkinfo » sur un nœud pour voir sa propre version, et « getpeerinfo » pour voir le logiciel déclaré par chaque pair (sa chaîne « subver »). Le réseau reste interopérable malgré la diversité des logiciels, mais la domination de Bitcoin Core fait qu’il fixe en pratique le rythme des évolutions du protocole. Les nœuds qui ne se mettent pas à jour continuent de suivre la chaîne lors des soft forks, mais un nœud dont le comportement de consensus diverge peut se retrouver séparé du reste du réseau.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• 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