À quoi ressemble l'examen du code Bitcoin ?

Le 19 juin, le développeur de Chaincode, John Newbery, a réuni un groupe de développeurs pour examiner une proposition de modification du code de Bitcoin.

Se déroulant via Internet Relay Chat (IRC), le sujet était de savoir si le changement, qui aiderait à empêcher un groupe de mineurs malveillants deaccélérer le rythme auquel les blocs de bitcoin sont produits, est une <a href="https://bitcoin-core-review-club.github.io/15481.html one with">ONE positive https://bitcoin-core-review-club.github.io/15481.html avec</a> des risques de sécurité ou des impacts négatifs limités.

L’objectif de Newbery est donc de transmettre ce qu’il sait sur la révision de ce type de code.

Ce stoppeur d'attaque de distorsion temporelle était-il un changement solide ?

« Le timewarp exploite cela en repoussant le bloc d'ajustement de difficulté loin dans le futur, puis le bloc suivant dans le présent », a écrit Newbery, expliquant le vecteur d'attaque.

Mais le simple fait que Newbery organise ces sessions peut être vu comme un signe de maturité de la communauté des développeurs Bitcoin, car cela illustre le travail acharné des meilleurs codeurs du projet pour le rendre plus inclusif. Le processus de révision du code n'a peut-être T été abordé de manière aussi ouverte et approfondie auparavant.

Newbery a lancé le Bitcoin CORE Review Club <a href="https://bitcoin-core-review-club.github.io/">(https://bitcoin-core-review-club.github.io/</a> ) pour donner aux codeurs des conseils sur la façon d'analyser une modification et de déterminer si elle est bénéfique pour la Cryptomonnaie. Les comptes rendus des réunions sont désormais publiés chaque semaine sur le site web.

Cela est possible parce que le code de Bitcoin est open source et résidesur GitHubPour que quiconque disposant d'une connexion Internet puisse les consulter, voire les modifier. Ce processus a permis au projet de passer d'un code autrefois appelé « ungoutte monolithique« Un logiciel plus facile à lire pour les développeurs, avec moins de bugs critiques. On s'efforce constamment de l'améliorer, avec l'objectif ambitieux d'en faire une base de code digne de l'avenir de l'argent. »

Il est donc possible de ONE au code de Bitcoin. Contrairement au code propriétaire, celui-ci est accessible à tous : il est « open source ».

ONEune des raisons pour lesquelles on l'appelle « monnaie programmable » est que, contrairement aux autres monnaies numériques, toute personne disposant des connaissances nécessaires peut essayer d'y ajouter de nouvelles fonctionnalités. ONEune des façons d' Guides le code source est d'examiner et de tester le code soumis par les programmeurs afin de s'assurer qu'il fonctionne réellement et qu'il n'introduit T de bug ou, malheureusement, ne divise pas accidentellement le réseau Bitcoin en deux.

Mais en parcourant les pages de code et les centaines de modifications proposées, il est difficile de savoir par où commencer.

« Ce club IRC hebdomadaire est destiné aux personnes qui souhaitent contribuer à l'examen des demandes d'extraction de Bitcoin CORE , mais qui trouvent le processus intimidant », explique le site Web du club, poursuivant :

« L'examen et le test des pull requests constituent le meilleur moyen de contribuer à Bitcoin CORE, mais il est difficile de savoir par où commencer. Il existe des centaines de pull requests ouvertes, dont beaucoup nécessitent une connaissance approfondie du contexte, et La rédaction et les examinateurs utilisent souvent une terminologie peu familière. »

Ainsi, même si le code de cette monnaie numérique est accessible à tous, il n'est pas toujours facile de le consulter ou de le modifier. Il faut de la pratique pour savoir quoi examiner.

Voici à quoi ressemble le processus.

Tout le monde peut le faire

Pour commencer, les utilisateurs peuvent se rendre sur GitHub, un site web qui héberge toutes sortes de projets open source. Il en existe un spécifiquement pour Bitcoin CORE, l'implémentation logicielle sous-jacente de Bitcoin utilisée par la plupart des utilisateurs.

Vous remarquerez qu'il y a beaucoup de choses sur GitHub, mais examiner le code consiste essentiellement à examiner «demandes d'extraction", une série de changements que les développeurs de l'ensemble de l'écosystème ont soumis à examen.

En d'autres termes, il y a 300 changements qui n'ont T encore été suffisamment examinés pour être officiellement ajoutés à la base de code, allant de la simplification de la lecture de la documentation décrivant le code à l'amélioration des performances de Bitcoin.

À ce stade, les développeurs tentent de décider si ces modifications doivent être approuvées. Le problème est que peu de développeurs ont suffisamment d'expérience en matière d'analyse des modifications de code pour déterminer si elles doivent être officiellement ajoutées à la base de code. C'est pourquoi un contributeur de Bitcoin CORE a un jour décrit la liste des pull requests comme « unecimetière d'idées géniales."

C'est pourquoi Newbery essaie d'aider dans ce processus.

Alors, comment ONE concrètement pour examiner un changement ? Comme le décrit Newbery sur le site web du club, il y a quelques étapes clés pour commencer, comme consulter le «contribution au guide Bitcoin CORE" et en jouant avec C++, le langage de programmation dans lequel Bitcoin CORE est écrit.

L'étape suivante consiste simplement à choisir une modification à examiner. Avec plus de 300 pull requests actives, par où ONE ? Pour quelqu'un qui ne connaît T encore le code source, les meilleures options sont les modifications de code spécifiquement étiquetées « bonnes premières issues ».

Une fois les préliminaires terminés, le développeur doit « cloner » le référentiel ou utiliser git pour faire une copie de la base de code sur son ordinateur afin de pouvoir tester que le changement fonctionne comme prévu.

Il suffit d’une simple commande pour copier l’intégralité de la base de code sur votre ordinateur.

À partir de là, vous pouvez examiner la Request d'extraction. Les développeurs concernés doivent ensuite exécuter tous les « tests » pour s'assurer que la modification de code n'affecte T accidentellement un autre morceau de code, puis passer à l'examen du reste du code.

Dans l’esprit d’un critique

À quoi les évaluateurs doivent-ils penser ?

Premièrement, il existe des préoccupations de haut niveau. Déterminer si un changement doit être apporté, en particulier un ONE critique, repose essentiellement sur un « consensus approximatif », ce qui signifie que la plupart La rédaction actifs approuveraient la nécessité d'un changement.

Lors d'une autre réunion du club, Newbery a déclaré https://bitcoin-core-review-club.github.io/16060.html :

Mon avis sur l'ouverture des pull requests : personne ne vous doit de révision. Quiconque révise votre code vous rend service. Si vous ouvrez une pull Request, vous entrez en compétition avec d'autres pull requests pour le temps de révision.

« En cas de doute sur l'utilité que d'autres personnes pensent que votre pull Request sera, n'hésitez pas à demander dans #bitcoin-core-dev, ou en demandant directement à d'autres La rédaction», a ajouté Newbery, faisant référence à un autre groupe IRC où les développeurs peuvent poser des questions liées au développement de Bitcoin CORE .

Cela dit, les développeurs ne s'accordent T toujours sur l'utilité d'une modification. Une semaine, le groupe de développeurs s'est penché sur une modification de code controversée. Certains ont estimé que les inconvénients l'emportaient sur les avantages, tandis que d'autres soutiennent qu'elle pourrait être utile.

Mais même si l'idée est globalement ONE , des préoccupations de moindre importance subsistent. Y a-t-il des bugs ? La modification du code est-elle accompagnée de tests garantissant son bon fonctionnement ? Ce sont des questions auxquelles une grande partie du temps de révision est consacrée.

Lors de la réunion du 29 mai (dont vous pouvez trouver la transcription complète ici <a href="https://bitcoin-core-review-club.github.io/15741.html">https://bitcoin-core-review-club.github.io/15741.html</a> ), par exemple, les développeurs ont examiné une amélioration des performances de la partie portefeuille du nœud Bitcoin .

Un contributeur du pseudonyme « Ariard » a animé la réunion en passant en revue le processus de révision qu'il a développé au fil du temps. « J'ai d'abord essayé d'identifier le type de PR dont il s'agissait : documentation, style de code, correction de bug, nouvelle fonctionnalité ou ajout de test. Car [à mon Analyses], connaître ce point va vous guider dans votre première lecture des commits, le temps nécessaire à la révision et le type de tests nécessaires », a déclaré le développeur.

Un autre utilisateur a souligné avoir constaté une amélioration simplement en vérifiant le temps d'exécution du code, avant et après. « Mon importation de 10 000 clés est passée de 8 minutes à 3 secondes ! » a déclaré un autre utilisateur du nom de « jb55 ».

Les transcriptions des réunions sont également riches en conseils pour simplifier ce processus et en faciliter la consultation. D'autres réunions sont prévues prochainement. Les prochaines sections seront animées par David Harding, rédacteur technique et contributeur spécialisé dans le Bitcoin .

Image d'Adam Back via les archives du Consensus