Pourquoi les CORE développeurs de Bitcoin souhaitent plusieurs versions

Les débats récents sur la question de savoir si les gens devraient être autorisés à apporter leurs propres modifications au protocole Bitcoin ont mis en évidence une notion importante : peut-être que le développement de Bitcoin CORE, la version de référence du code, n'est T le seul moyen pour les gens de contribuer.

Une modification récente du code Bitcoin qui a fait son chemin dans une variante de Linux appelée Gentooa laissé certaines personnes furieuses avant que le développeur ne le désactive par défaut.

« Ceux-ci ne seront jamais fusionnés dans le référentiel Bitcoin sur Github, mais les personnes qui souhaitent les utiliser peuvent le faire », a déclaré Wladimir J van der Laan, développeur principal de Bitcoin .

Mais qu'est-ce que Github, pourquoi van der Laan a-t-il l'autorité de choisir ce qui y est placé et comment Bitcoin est-il développé en premier lieu ?

Comment le Bitcoin est développé

L'implémentation de référence du protocole Bitcoin s'appelle Bitcoin CORE. Il s'agit du code que Satoshi a initialement transmis à un groupe CORE de développeurs avant de disparaître.

Ces « disciples » maintiennent désormais ce code, avec l'aide d'une communauté plus large de développeurs. L'objectif est d'améliorer l'efficacité du code, mais avec prudence et prudence, afin d'éviter toute faille.

Bitcoin CORE est géré à l'aide d'un système de contrôle de version de logiciel appelé GitCela permet aux utilisateurs de KEEP les versions de leur code sur lesquelles ils travaillent et les modifications qu’ils ont apportées.

Les développeurs Bitcoin exécutant Git sur leurs ordinateurs se connectent à un service central afin de pouvoir travailler simultanément sur les différentes versions d'un même projet. Ce service, appelé Github, compte de nombreux projets différents, gérés par différents groupes de personnes. Bitcoin est ONEun d'eux et possède son propre Page Github.

Le code du projet est hébergé sur GitHub dans un seul et même emplacement : un dépôt. La version officielle et déployable du dépôt Bitcoin est appelée dépôt amont. Cependant, ceux qui souhaitent apporter leurs propres modifications au code peuvent créer leurs propres versions du dépôt en le copiant dans un « fork » en ligne.

Les développeurs peuvent modifier leurs forks à leur guise. Ils peuvent demander leur réintégration dans le dépôt principal en effectuant une « pull Request», ce qui ouvre leur version du dépôt aux autres membres du projet, qui peuvent la consulter et la commenter.

« L'idée est que d'autres développeurs de la communauté examinent la modification », explique van der Laan. « Ensuite, l'auteur de la modification corrige les problèmes signalés par les autres. Il peut également être nécessaire de Rally des personnes pour tester la modification, surtout si elle est complexe ou comporte une part de subjectivité (par exemple, pour les modifications d'interface utilisateur ou de RPC). »

Si suffisamment de personnes approuvent les modifications apportées à une pull Request, celle-ci est alors fusionnée dans le dépôt principal. Mais qui a réellement le droit de fusionner la pull request ?

Il s'avère qu'il existe une sorte de sacerdoce Bitcoin qui gère ce qui finit par entrer dans le code du Bitcoin CORE . Van der Laan, le scientifique en chef et ancien développeur principal Gavin Andresen, Jeff Garzik, Gregory Maxwell et Pieter Wuille forment l'équipe qui prend la décision finale, et ce n'est T une décision qui se prend par vote, comme on pourrait le voir dans une démocratie.

« Les dépôts Github uniques ne sont pas démocratiques », a expliqué van der Laan. « Ses responsables coopèrent au développement et décident de ce qui est fusionné et quand, et de ce qui ne l'est pas. Les problèmes techniques complexes ne sont pas résolus par le vote populaire. »

BIPS et demandes d'extraction

Dans la mesure du possible, le développement du Bitcoin repose généralement sur un consensus populaire. On distingue deux grandes catégories de changements.

Le CORE Bitcoin est maintenu de manière volontairement conservatrice, et la plupart des modifications sont apportées de manière « non controversée et rigoureuse », a déclaré van der Laan. Il s'agit de changements mineurs et progressifs, plutôt que de changements majeurs et révolutionnaires. Un correctif Bitcoin pourrait déplacer du code pour le rendre plus lisible, ou peut-être optimiser l'utilisation de la mémoire.

Il existe une autre catégorie de modifications apportées au Bitcoin , bien plus importantes, qui modifient les règles de consensus. Ces règles sont les règles techniques que tous les clients Bitcoin doivent respecter pour que le réseau Bitcoin fonctionne correctement.

« Ces éléments doivent être examinés de près. Ils doivent d'abord être discutés sur la liste de diffusion, et il doit y avoir un BIP. Les retraits sont généralement controversés et restent ouverts à la discussion pendant longtemps », a-t-il déclaré.

Un BIP – abréviation deProposition d'amélioration du Bitcoin– est un document suggérant une modification globale de certains aspects de Bitcoin. Il peut s'étendre à des éléments extérieurs à Bitcoin CORE, notamment les portefeuilles mobiles ou la génération de clés dans les portefeuilles matériels. Il peut également régir les processus liés à Bitcoin, comme les modifications du processus décisionnel.

N’importe qui peut créer un BIP, à condition qu’il soit écrit ence formatLa communauté en parle, et si les gens l'aiment, son statut peut être changé en « actif » ou « final ».

Les changements dans ce sens sont le changement dansBIP 62, qui était un changement portant sur ladéfaut de malléabilité des transactions en Bitcoin.

Qu'est-ce qui augmente les chances qu'une modification proposée soit implémentée dans le protocole ? Il est utile que l'auteur d'un BIP ait rédigé un exemple de code à tester et à réviser, a ajouté van der Laan.

Examen et approbation

Consultant Bitcoin et auditeur de sécurité Sergio Lernerj'aimerais voir plus de formalisation dans le processus d'approbation du code.

« Lorsqu'on voit une pull Request fusionnée, il est difficile de savoir qui l'a approuvée et dans quelle mesure le correctif a été examiné », a-t-il déclaré. « Il faut lire de nombreux commentaires et quelques « +1 » que l'on peut interpréter comme un « J'accepte la fusion », mais aussi comme un « J'aime bien, mais je n'ai T vraiment examiné le code. »

Lerner aimerait voir unmulti-signature Processus d'approbation des correctifs, au cours duquel une certaine proportion de développeurs approuvent formellement le code en signant la revue. Il s'agirait d'une version plus complète du processus actuellement utilisé dans certains portefeuilles, où plusieurs signatures sont nécessaires pour qu'une adresse Bitcoin soit utilisable.

D'autres choses que Lerner aimerait voir incluent un journal des bugs trouvés et une analyse des raisons pour lesquelles ils n'ont pas été détectés à temps, une revue de code externe axée sur la sécurité par patch, une description formelle de la documentation qui devrait accompagner un patch et une description de ce que signifie réellement la revue d'un patch.

« Est-ce que cela implique une revue du code source ligne par ligne ? Est-ce que cela implique de vérifier si la documentation du changement est suffisante ? » a demandé Lerner. « Est-ce que cela implique d'analyser le changement par rapport aux vecteurs d'attaque connus ? »

Le problème est que tout cela prend du temps et des ressources Human , a déclaré Lerner :

« Évidemment, la mise en œuvre de tout cela nécessite davantage de maintenance, un budget plus important et davantage de ressources de CORE (qui sont actuellement rares). Mais un logiciel qui gère un secteur de 6 milliards de dollars en a besoin. »

Au-delà du CORE Bitcoin

Alors que Lerner décrit certaines exigences pour les revues de code, van der Laan fait écho au discours d'ouverture de Gavin Andresen à laConférence Bitcoin 2014, où il a dit quedavantage pourrait être fait pour rationaliser l'approbation du BIP.

« Le processus BIP mériterait d'être amélioré. Je serais heureux que les développeurs d'autres implémentations de nœuds (complets) commentent plus activement les propositions (ou en formulent) », a-t-il déclaré.

Andresen propose également de déplacer les discussions sur le BIP et d'autres préoccupations liées à la mise en œuvre croisée de la liste de diffusion générale de développement de Bitcoin vers une liste de diffusion spécifique au BIP.

Tout comme pour le développement de logiciels sur un projet open source, la responsabilité de le faire aboutir incombe toujours aux utilisateurs.

« Comme il s'agit d'un processus global, distribué et désorganisé, il n'appartient pas à une seule organisation de gérer le processus BIP. La responsabilité incombe donc aux personnes et aux organisations qui souhaitent BAND et faire quelque chose », a suggéré van der Laan.

Mais la Fondation Bitcoin , principale organisation commerciale du bitcoin, ne devrait-elle T s'occuper de ces choses ? Non, affirme-t-il. Au contraire, le monde du Bitcoin va au-delà de cela, et l'équipe de développement accueille favorablement différentes implémentations du Bitcoin.

Van der Laan a déclaré :

« Discours de Gavin à Bitcoin 2014l'a clairement indiqué Il a parlé de différentes implémentations de nœuds complets, affirmant même que « plus, c'est mieux ». Même si la maintenance de Bitcoin CORE est mon métier, je suis plutôt d'accord avec lui.

Selon van der Laan, la responsabilité ne devrait plus reposer sur le développement de Bitcoin CORE.

« Au cours des premières années, Bitcoin CORE était peut-être extrêmement important, et ses développeurs devaient KEEP l'infrastructure des nœuds sous contrôle (et veiller la nuit pour corriger les bugs dès leur apparition). Mais, à l'avenir, pour que Bitcoin devienne le système distribué mondial qu'il était censé être, nous devons aller plus loin. »

Il existe peut-être un clergé bienveillant pour Bitcoin CORE, dans le sens où la décision finale sur le contenu du code revient à un petit groupe de personnes. Mais cela ne signifie T que ce groupe souhaite une approche exclusive ou élitiste, loin de là.

Au moins certains développeurs CORE encouragent activement les autres à étendre le réseau avec leurs propres implémentations, partant du principe que la majorité d'entre eux respecteront les règles de consensus. Ceux qui ne le feront T perdront leur synchronisme, ce qui mettra en évidence la minorité et les obligera à corriger le problème.

Faire évoluer le Bitcoin dans cette direction pourrait créer de la place pour les types de variations de Juridique qui certaines personnes ont demandé, tout en préservant les règles du consensus : les éléments qui font véritablement du Bitcoin ce qu'il est. Cela allégerait également la pression sur un groupe de personnes surchargées qui tentent de soutenir la Technologies qui sous-tend une entreprise en pleine croissance. Et, si elle est bien menée, elle pourrait introduire certains des nouveaux processus réclamés par des participants comme Lerner.

La question est : comment Bitcoin va-t-il faire évoluer une telle variété d’implémentations alternatives de manière propre, efficace et sans aucun drame associé ?

Diversifier l'imagevia Shutterstock