Open Source vs. Source-Available : Ce que l'échec de Coldcard enseigne sur les incitations des logiciels Bitcoin

Bitcoin Magazine

Open Source vs. Source-Available : Ce que l'échec de Coldcard enseigne sur les incitations des logiciels Bitcoin

Le code fermé par rapport au code open source a divisé l'industrie Bitcoin et la crypto en général pendant plus d'une décennie. Les défenseurs de Bitcoin soutiennent depuis longtemps que l'infrastructure financière du monde devrait être construite en public. La transparence et l'auditabilité, disent-ils, sont non négociables lorsque de l'argent réel est en jeu. Pourtant, les couches d'applications et d'héritage de la finance sont souvent en désaccord.

Cependant, le récent piratage de Coldcard, un portefeuille matériel de self-custody populaire où les utilisateurs ont perdu plus de 100 millions de dollars en bitcoin (plus de 1 500 BTC), a jeté le doute sur ce que signifie réellement « Open Source ». Il a révélé que peut-être la plupart des gens, même de nombreux hardcore bitcoiners, sont mal informés sur la philosophie de développement de logiciels open source et quand elle échoue.

Les Principes et Terminologie

Le langage autour de l'Open Source peut être compliqué. Les logiciels libres et open source (FOSS) et les logiciels libres/libres et open source (FLOSS) font référence à des logiciels qui répondent à des définitions formelles de liberté utilisateur.

La Free Software Foundation (FSF) définit le logiciel libre à travers quatre libertés essentielles :

• Liberté 0: La liberté d'exécuter le programme comme vous le souhaitez, pour n'importe quel but.
• Liberté 1: La liberté d'étudier comment le programme fonctionne, et de le modifier pour qu'il fasse ce que vous souhaitez (l'accès au code source est une condition préalable à cela).
• Liberté 2: La liberté de redistribuer des copies afin de pouvoir aider les autres.
• Liberté 3: La liberté de distribuer des copies de vos versions modifiées à d'autres (l'accès au code source est une condition préalable à cela).

La FSF souligne que « libre » fait référence à la liberté, pas au prix, dans une citation courante entendue chez les défenseurs du FOSS : « ‘libre’ comme dans ‘liberté d'expression’, pas comme dans ‘bière gratuite’. »

La Définition de l'Open Source de l'Open Source Initiative ajoute dix critères pratiques. Ceux-ci incluent la redistribution gratuite sans redevances, la disponibilité du code source dans la forme préférée pour modification, le droit de créer et de distribuer des œuvres dérivées, et aucune discrimination contre des personnes, des groupes ou des domaines d'activité — y compris l'utilisation commerciale. Une licence doit répondre à tous les dix critères pour être qualifiée d'Open Source selon la norme de l'OSI.

« Source disponible » ou « source consultable » est différent. Le code peut être lisible publiquement tandis que la licence restreint le droit de le vendre. Le firmware de Coldcard, par exemple, est publié sous les termes MIT plus la Clause des Communs. La Clause supprime spécifiquement le droit de « Vendre » le logiciel — défini comme le fait de le fournir à des tiers moyennant des frais ou d'autres considérations dans un produit ou un service dont la valeur dérive entièrement ou substantiellement du logiciel lui-même. En d'autres termes, le firmware de Coldcard ne pourrait pas être utilisé commercialement.

La FAQ de la Commons Clause énonce explicitement la différence : « Est-ce que c'est de l'‘Open Source’ ? Non. » Elle note que l'application de la clause signifie que le logiciel répond à de nombreux éléments de la Définition de l'Open Source mais pas à tous, et ne devrait donc pas être appelé Open Source.

Ces distinctions sont importantes. Publier le code source crée la possibilité d'inspection. Accorder l'ensemble des droits définis par la Définition du Logiciel Libre ou la Définition de l'Open Source est ce qui rend le logiciel FOSS ou FLOSS. Mais avoir le badge d'approbation, pouvoir brandir un drapeau FOSS ou FLOSS, n'est pas le but. La liberté commerciale dans le FOSS débloque des incitations de tiers à tester et à examiner le code qui autrement pourraient ne pas exister, soutiennent les critiques.

Les quatre libertés forment le noyau philosophique de l'Open Source. En pratique, elles reposent sur une hypothèse économique : que suffisamment de personnes motivées examineront réellement le code. Lorsque cette hypothèse échoue, le système produit une tragédie classique des biens communs, une situation où une ressource partagée est surexploitée ou négligée parce que les utilisateurs individuels agissent dans leur propre intérêt à court terme plutôt que dans l'intérêt à long terme du groupe.

Chaque personne a un incitatif à prendre plus (ou à contribuer moins) que ce qui est durable, et la ressource se dégrade en conséquence. Cela se produit lorsqu'il y a un désalignement entre l'intérêt personnel à court terme de l'individu et l'intérêt à long terme du groupe. Parfois, un alignement existe ; parfois, il n'existe pas.

Un développeur de Bitcoin a exprimé le problème de manière directe : « Utiliser des mocks et des stubs de code Open Source dans les tests est irresponsable et à court terme. Le code Open Source est considéré comme sûr car tout le monde peut le vérifier. Si vous n'êtes pas prêt à faire le strict minimum de tests des fonctionnalités dont vous dépendez réellement, alors vous vous comportez comme une sangsue. »

En conséquence, l'Open Source ne crée pas de sécurité par elle-même. Elle crée la possibilité de vérification. Que cette vérification ait lieu dépend des incitations, des compétences et de l'attention. On pense que l'historique du FOSS se renforce au fil du temps à mesure que des vulnérabilités sont découvertes, divulguées et corrigées, créant des bases solides sur lesquelles d'autres construisent. Le noyau Linux est un excellent exemple de FOSS durci ; il alimente la grande majorité des serveurs du monde, des infrastructures cloud, des appareils Android et des systèmes embarqués, ce qui en fait l'un des logiciels les plus largement déployés de l'histoire.

Open Source tel que démontré par Bitcoin Core

Bitcoin Core, l'implémentation de référence de Bitcoin, est un autre exemple prémonitoire de fonctionnement pur de l'open-source à grande échelle dans la nature. Le logiciel, qui fonctionne derrière la plupart des infrastructures liées à Bitcoin, est publié sous la licence MIT. Son processus de développement est largement public par conception.

Tout le monde peut ouvrir une demande de tirage. La révision de code est le principal filtre et le point d'entrée recommandé pour les nouveaux contributeurs. Les réviseurs utilisent un vocabulaire formel—Concept ACK (reconnaissance et accord avec l'objectif), Approach ACK (accord avec l'objectif et la méthode), ACK avec un hachage de commit spécifique (testé et approuvé pour fusion), ou NACK (désaccord, qui doit être accompagné d'un raisonnement technique).

Les mainteneurs pèsent le consensus parmi les contributeurs et les mérites techniques d'un changement avant de fusionner. Les changements critiques pour le consensus font face à une barre encore plus haute et nécessitent généralement une Proposition d'Amélioration Bitcoin et des discussions extensives sur plusieurs années sur la liste de diffusion bitcoin-dev et IRC.

Il n'y a pas de caste privilégiée de « développeurs Bitcoin Core ». La confiance se gagne par une compétence démontrée au fil du temps. Les mainteneurs existent pour des raisons pratiques—auditer et fusionner du code, gérer des versions, et modérer de manière basique—mais le travail produit est du code open-source pur que tout le monde peut inspecter, construire, forker ou exécuter. Les développeurs qui obtiennent des 'commits' de code fusionnés dans Bitcoin Core sont largement appelés Contributeurs Bitcoin Core.

Calle, un développeur Bitcoin open-source de longue date, a récemment résumé la réalité : « Les gens qui pensent que le core est une sorte d'institution opaque opérant dans l'ombre sont soit trop paresseux, soit trop stupides pour aller voir par eux-mêmes. Littéralement tout ce qu'ils font est public, tout le monde peut intervenir, et le résultat de leur travail est du code Open Source pur. »

Le financement de ce travail provient en grande partie de structures à but non lucratif et de subventions telles que Brink, OpenSats, Spiral, et d'autres plutôt que d'une feuille de route produit d'entreprise traditionnelle. Les discussions et débats techniques ont lieu publiquement sur la liste de diffusion bitcoin-dev et dans le canal IRC #bitcoin-core-dev sur Libera Chat, où les propositions sont examinées avant et pendant le processus de demande de tirage. Les problèmes et demandes de tirage sur GitHub portent souvent des historiques de commentaires s'étendant sur une décennie. Le résultat est une culture de développement optimisée pour la correction et l'auditabilité plutôt que pour la vitesse ou la vélocité des fonctionnalités commerciales.

L'économie de l'open source

La plupart des utilisateurs de logiciels open source ou disponibles en source ne lisent jamais le code eux-mêmes. Ils comptent sur l'hypothèse que d'autres l'examinent. Dans le cas de Coldcard, un défaut critique d'entropie est resté dans le firmware disponible publiquement pendant environ cinq ans avant d'être exploité et ainsi découvert.

Le bug est entré dans la base de code lors d'une réécriture majeure en 2021 qui a également supprimé le code dérivé de la GPL restant de Trezor, le premier portefeuille matériel et maintenant le deuxième plus grand dans l'industrie de l'auto-garde. La bibliothèque au centre de l'échec d'entropie, qui a remplacé trezor-crypto, s'appelle libngu et a eu un minimum de contrôle externe, avec seulement 7 étoiles et moins de 20 forks en plus de 5 ans d'utilisation en production. Comparez cela aux 512 étoiles portées par la bibliothèque trezor-crypto aux côtés de 212 forks, ou aux 793 forks et 1,8k étoiles du plus moderne trezor-firmware. La seule disponibilité de la source n'a pas produit la révision qui comptait, car d'autres entreprises à but lucratif, bien financées, étaient restreintes dans leur utilisation, ou du moins c'est ce que soutiendraient les critiques.

Les enjeux sont plus élevés dans Bitcoin que dans la plupart des domaines logiciels. Un défaut critique peut être converti directement en fonds liquides sur le marché ouvert. Bien que la première moitié des fonds Coldcard volés soit toujours détenue dans une poignée d'adresses et que le hacker puisse un jour être attrapé, les hackers imitateurs qui ont suivi ont été plus prudents, et certains ont volé plus de bitcoin et l'ont blanchi avec succès, selon Galaxy Research. La résistance à la censure de Bitcoin et sa capacité de transaction immuable créent à la fois une incitation puissante pour les attaquants et un filtre darwinien ; seuls les projets qui attirent continuellement des révisions compétentes, et les utilisateurs et entreprises qui prennent des précautions sérieuses, ont tendance à survivre à long terme.

Les choix de licence façonnent ces incitations selon les défenseurs du FOSS qui ont critiqué les décisions de licence de Coinkite pendant des années. Les licences open-source pures maximisent le pool de réviseurs et de forks potentiels. Les licences « source disponible » restreintes peuvent réduire le parasitisme commercial mais aussi réduire le cercle des personnes ayant à la fois le droit légal et la motivation économique d'investir une attention approfondie. Hélas, le fardeau de la révision du code retombe sur l'entreprise sous une licence restrictive, la plaçant en quelque sorte plus près du code fermé que du code ouvert.

Comment l'IA change le développement open source et closed source

L'intelligence artificielle modifie également l'équilibre entre le FOSS et le code fermé.

Après l'incident Coldcard, un effort bénévole connu sous le nom de Bitcoin Red Team—dirigé par des développeurs tels que Calle et Rob Hamilton d'AnchorWatch, et soutenu par OpenSats—a utilisé des modèles d'IA de pointe pour scanner des centaines de dépôts Bitcoin open-source. Lors d'une période intensive, l'équipe a déposé des milliers de constatations, y compris des dizaines classées comme critiques ou de haute gravité, à travers des centaines de projets. Des divulgations responsables ont été faites aux mainteneurs avant une publication plus large. L'exercice a démontré que la révision systématique assistée par IA peut faire ressortir des problèmes à une échelle et une vitesse auparavant impraticables pour des équipes purement humaines.

À cet égard, il convient de noter que l'équipe rouge a trouvé les modèles chinois à poids ouvert beaucoup plus fiables que les modèles américains à code source fermé, qui, même avec des autorisations cybernétiques et un accès de haut niveau, ont refusé de répondre aux questions de l'équipe rouge, une tendance que les développeurs américains déplorent.

En même temps, l'afflux de code généré par l'IA a créé une nouvelle pression de déni de service sur les mainteneurs de FOSS. La révision des résultats de l'IA prend souvent plus de temps que leur génération. Certains projets open-source en dehors de Bitcoin ont restreint les trackers de problèmes ou imposé des règles strictes contre les contributions de l'IA simplement pour rester fonctionnels.

Source : BitcoinMagazine