Comment les développeurs Bitcoin s'assurent-ils que leurs modifications n'affectent pas les règles de consensus ou le protocole réseau en cours d'exécution?

Dec 17 2020

Je comprends que les règles de consensus Bitcoin sont appliquées individuellement par chaque nœud . Cependant, la plupart des gens utilisent la version par défaut de Bitcoin Core, ce qui rend les implémentations effectuées par les développeurs de Bitcoin de la plus haute importance.

Ma question est donc dans le titre: comment garantissent-ils que les implémentations n'affectent pas les règles de consensus ou le protocole réseau?

Bien que je comprenne également que chaque version de Bitcoin est publiée avec un soin extrême et des tests approfondis, je continue de me demander s'il existe une pratique systématique pour cela. N'importe quel pointeur serait très apprécié.

Réponses

9 MCCCS Dec 17 2020 at 16:49

"Meilleur effort". Les preuves formelles n'aident pas. Tout ce que l'on peut faire est d'écrire des tests, comme tout autre logiciel bien écrit.

Ils maintiennent également les fourchettes de certaines dépendances telles que LevelDB et ne mettent pas à jour certaines d'entre elles telles que BerkeleyDB .

Voyez ce qui n'a pas fonctionné . En particulier, la hardfork de 2013 ne se serait pas produite s'ils avaient pu garantir un protocole de consensus inchangé.

5 MichaelFolkson Dec 17 2020 at 21:17

Les contributeurs Core à long terme ont une compréhension générale des parties de la base de code Core qui touchent ou pourraient potentiellement avoir un impact sur le consensus entre les nœuds du réseau. Cependant, le consensus est «glissant» et il y a eu des exemples dans le passé où des changements ont été apportés qui n'étaient pas considérés comme un consensus critique à l'époque, mais qui se sont avérés l'être. Le MCCCS met en évidence certains de ces exemples dans la réponse ci-dessus.

Pieter Wuille a discuté des défis de définir ce qu'est le consensus et ce qui ne l'est pas sur le podcast Chaincode Labs en janvier 2020.

Une des choses que je pense apprises de cela est de préciser quelles sont vos règles de consensus est vraiment difficile. Cela ne signifie pas que vous ne pouvez pas essayer, mais qui aurait pensé qu'un paramètre de configuration dans la couche de base de données que vous utilisez a effectivement fui sémantiquement dans les règles de consensus implicitement définies de Bitcoin. Vous pouvez bien sûr attribuer cela à l'échec humain. Nous aurions dû lire la documentation et en être conscients.

Nous pouvons parler de la limite en essayant d'abstraire la partie de la base de code qui contribue intentionnellement au consensus, mais il est très difficile de dire clairement que ce code n'a aucun impact sur le code de consensus car des bogues peuvent fuir. Je pense qu'une des choses à apprendre ici est que vous voulez vraiment un logiciel destiné à être utilisé dans un système de consensus où non seulement vous avez l'exigence que si tout le monde se comporte correctement, tout le monde accepte la bonne réponse, mais aussi que tout le monde soit d'accord sur ce qu'est un morceau de données invalide dans le lockstep.