Entretien avec Andrew Stone, développeur de Bitcoin Unlimited

BitcoinCours.com, le 26 Novembre 2016

Par Jamie Redman, le 25 Novembre 2016

Bitcoin.com a récemment discuté avec Andrew Stone, développeur de Bitcoin Unlimited (BU), pour parler du client alternatif et du débat
actuel sur la taille des blocs. Dernièrement, la communauté de la crypto-monnaie s'est demandée qui sont les développeurs de BU, et quelles sont leurs qualifications. Cet entretien est destiné à apporter un peu de lumière sur le développement et l'opinion de Stone sur les buts que BU tente d'accomplir.

Une discussion approfondie avec le développeur de Bitcoin Unlimited Andrew Stone

Bitcoin.com (BC): Pouvez-vous décrire à nos lecteurs une version simple de ce qu'est Bitcoin Unlimited et comment il traite de la scalabilité?

Andrew Stone (AS): Bitcoin Unlimited reconnaît que le consensus de Nakamoto (preuve de travail) est le seul mécanisme de consensus infaillible et que des accords arbitraires comme la taille des blocs à 1 Mo de Core sont un «consensus social». Bitcoin Unlimited ne croit pas que cela soit dans l'intérêt de ses utilisateurs d'être sur un fork minoritaire à moins que la raison du fork soit de protéger la fonction du Bitcoin comme monnaie.

Andrew Stone, Bitcoin Unlimited

Bitcoin Unlimited traite de la scalabilité à court terme en permettant aux mineurs de miner des blocs supérieurs à 1 Mo. À moyen et long terme, Bitcoin Unlimited soutiendra Lightning et d'autres technologies hors chaîne. Laissez le marché décider quelle technologie fonctionne le mieux pour une application!

BC: Comment avez-vous atterri sur le projet BU et qui fait partie de l'équipe des développeurs?

AS: Beaucoup des idées générales qui sont devenues Bitcoin Unlimited ont été discutées sur le fil "Gold Collapsing Bitcoin Up" du forum bitco.in. Toutes les personnes présentes sur ce forum méritent d'être remerciées pour avoir présenté des idées. J'ai participé à cette discussion et j'ai proposé l'algorithme «consensus émergent» (on ne l'appelait pas comme cela à ce moment là). J'ai ensuite écrit les articles BU de la Fédération (nos statuts) et j'ai construit la version initiale du client. À ce moment-là, j'étais essentiellement un dictateur bienveillant. J'ai alors administré les élections spécifiées dans les articles BU et cédé l'autorité aux gagnants.

Peter Tschipper et Andrea Suisani ont été les premiers développeurs, et Peter Rizun mérite une mention spéciale pour avoir aidé les premiers jours de Bitcoin Unlimited avec ses idées et ses analyses.

Avec l'adoption de BU par deux pools miniers, nous avons beaucoup de nouveaux contributeurs et donc je ne vais pas énumérer tout le monde ici.

BC: Pourquoi pensez-vous que les développeurs de Bitcoin Core sont contre les clients alternatifs comme BU?

AS: Je ne peux pas dire pourquoi certaines personnes sont contre d'autres clients. Mais je peux vous donner quelques idées sur la raison pour laquelle quelqu'un pourrait être contre d'autres clients en général.

Tout d'abord, vous pourriez souhaiter un temps plus tôt, plus simple. Comme en 2012, lorsque Bitcoin avait une capitalisation boursière de 50 millions de dollars. Certaines choses sont plus faciles dans un environnement avec un client unique, surtout si vous êtes en charge de ce client. Cependant, cette situation est passée. La situation est encore pire aujourd'hui. Nous avons même plusieurs protocoles ... le protocole P2P du client Satoshi, le réseau de diffusion Fiber, le réseau Falcon. Les dispositifs de hachage utilisent leur propre protocole personnalisé, «stratum». Mais la diversité fait finalement la force - un bug dans «le» client ne stoppera pas le réseau entier.

Deuxièmement, si vous ne pouvez pas justifier votre problème réel (blocs plus gros), vous pouvez utiliser n'importe quel argument qui soit commode.

Troisièmement, vous n'avez pas vraiment intériorisé le résultat «FLP» et pensez que tous les développeurs peuvent simplement «se réunir» et arriver à une décision d'une manière similaire à la façon dont les protocoles sont spécifiés dans l'industrie. Cependant, sans un contrôle strict sur l'adhésion et la participation, c'est un fantasme. Les protocoles ont inévitablement des concurrents et des extensions incompatibles. Un bon exemple est l'attribution des identifiants USB. Pour obtenir un identifiant USB, vous devez vous joindre au consortium USB (l'adhésion coûte plusieurs milliers de dollars). Ce modèle ne fonctionne pas dans la communauté du matériel open source où les individus créent des périphériques impressionnants mais de très petite taille. En fin de compte, les gens se sont rendus compte que l'information est libre - légalement le consortium USB ne peut pas appliquer cette restriction à moins que vous mettiez la marque déposée USB sur votre produit. Donc, les gens ont commencé à choisir des ID aléatoires.

En revanche, dans le développement de logiciels critiques, la «référence absolue» consiste à créer plusieurs implémentations complètement distinctes et à les exécuter simultanément. Cela réduit la probabilité que les bugs de mise en œuvre entraînent une défaillance de la mission.

BC: Quand Adam Back et d'autres font des déclarations au sujet de BU comme étant «semi-testé» et que les développeurs de BU sont non qualifiés, comment recevez-vous ces opinions?

AS: C'est assez navrant car ces gens sont eux-mêmes non qualifiés pour faire ces déclarations. Et je ne veux pas dire techniquement. Je veux dire qu'ils n'ont jamais montré qu'ils ont examiné le code qu'ils critiquent.

Il est clair que toute personne qui est un développeur Core ou dont la société emploie des développeurs Core bénéficie énormément d'avoir Bitcoin Core comme restant le client majoritaire. Par conséquent, ces personnes ont un énorme conflit d'intérêts non reconnu. Je demanderais donc à tous ceux qui lisent ces déclarations de les rejeter comme FUD jusqu'à ce que les données réelles soient fournies.

J'ai finalement répondu à la critique d'Adam en montrant que le code de Core a des défauts importants et en cours (récemment ajoutés). Je l'ai fait à contrecœur parce que les développeurs font des erreurs. Les bugs font malheureusement partie du développement logiciel aujourd'hui. Cependant, en faisant cela, j'ai montré que Bitcoin Unlimited a effectivement testé plus de situations que Core. Et j'avais besoin de dissiper le mythe comme quoi le code Bitcoin Core et les développeurs sont en quelque sorte qualifiés uniquement pour développer le logiciel Bitcoin. En fait, le code est pire que ce que je vois dans de nombreuses applications critiques.

BC: Pouvez-vous nous donner vos qualifications et nous dire si les membres de l'équipe sont qualifiés pour travailler sur le protocole Bitcoin?

AS: Je ne peux pas commenter les qualifications des autres membres de l'équipe de Bitcoin Unlimited (puisque je ne connais pas leur histoire), à part dire que j'ai personnellement révisé leur travail et que je le trouve généralement excellent.

J'ai travaillé en haute disponibilité et sur des applications de mission essentielle pendant toute ma carrière, donc je ne suis pas étranger aux soins nécessaires pour développer ce type de code. Mon travail avec OpenClovis, Inc signifie que mon logiciel est exécuté dans presque toutes les grandes entreprises de télécommunications à travers le monde, intégré dans d'autres appareils de télécommunications. Nous ne recevons pas le nombre d'utilisateurs dépendants du logiciel OpenClovis, cependant, en fonction des nombres que nous recevons, je suppose que c'est dans les centaines de millions de personnes. Si vous avez un téléphone cellulaire en Corée du Sud, vous utilisez le logiciel que j'ai écrit. Si vous avez un téléphone cellulaire Verizon, vous utilisez probablement mon logiciel. Si vous avez un téléphone cellulaire prolongateur de la gamme de maison, vous l'utilisez probablement. Si votre entreprise dispose de téléphones basés sur SIP, ou d'un commutateur de classe entreprise Ethernet redondant, il y a une chance que vous nous utilisez (cela dépend de la marque que votre entreprise a acheté).

BC: Dans un récent post intitulé "Un court aperçu de Bitcoin Core",  vous décrivez différents bugs trouvés dans le client Core. Pensez-vous que la communauté devrait prendre ces bugs plus au sérieux?

AS: Bien sûr. L'industrie de la haute disponibilité a le concept de «5000 ans» de bugs. Ce sont des bugs qui se produisent rarement. Cependant, si vous exécutez 5000 clients, ou si vous tombez sur une condition de fonctionnement anormale, ces bugs rares peuvent soudainement commencer à se produire plus fréquemment. Dans l'industrie des télécommunications, chaque chute ou décharge de Core est attribuée à une cause probable, même si cela signifie examiner manuellement le code pendant des heures et ajouter des instructions conditionnelles de «forçage» pour déclencher un flux de code spécifique qui n'est normalement pas possible de déclencher en utilisant une entrée externe. Nous avons besoin de soins similaires dans le code Bitcoin.

Une partie de l'objectif de cet exercice était de laisser les individus montrer leurs mérites. Rapporter des négations sans investigation réelle ou des excuses comme "cela ne fonctionne qu'en mode débogage" est un gros problème. Franchement, les réponses de certaines personnes à mon poste auraient dû vous inquiéter davantage sur la méthodologie de développement de Core que ma propre critique. Parce que chaque morceau de logiciel a des bugs, vous ne m'en voudrez pas de dire que trois d'entre eux vous aurait simplement prouvé que Bitcoin Unlimited est, en fait, compétent au développement, bien informé dans la base de code et bien testé. Il ne devrait pas vraiment refléter aussi mal que sur Core.

Mais si les contributeurs les nient sans vérifier, c'est un problème. Quels autres bugs ont été refusés de la même façon? Et l'un des pires reniements est «A ne peut pas arriver en raison de (apparemment sans rapport) X, Y et Z.» Le problème est que si cette philosophie imprègne la base de code, vous vous retrouvez avec un code qui a beaucoup de dépendances implicites, qui ne peut être développé et maintenu que par les auteurs originaux ou par des personnes qui ont été impliquées dans le projet pendant une longue période.

Et défendre un code d'exécution qui a produit un comportement indéfini en mode débogage est un vrai problème. Parce que les développeurs s'exécutent en mode débogage. Si vous avez un bug qui cause un problème en mode débogage, les développeurs peuvent "réparer" ce problème, ce qui entraîne des bugs dans le code de production. Par exemple, le manque de verrous autour du code de nettoyage de noeud est un exemple probable de ce qui se passe. Ces verrous ont peut-être été supprimés car en mode débogage, le dd_mutex peut déjà être nettoyé, ce qui entraîne un assert dans boost (mutex invalide). Mais l'effet de la suppression des verrous (que nous avons vu dans nos tests) est que vous pouvez obtenir une décharge de base, dans la situation extrêmement rare où un pair quitte la connexion au moment précis où vous arrêtez.

BC: Que fait BU pour améliorer les erreurs de programmation de Core?

AS: Trouvez-les, corrigez-les! Et bien sûr, nous avons notre propre méthodologie de développement pour décourager l'introduction de ces erreurs, et nous restructurons (dans une certaine mesure, nous voulons aussi être en mesure de rebaser) le code pour résoudre des classes entières de questions.

BC: BU a supprimé la limite de la taille du bloc et permet aux gens de choisir la taille du bloc, cette hypothèse est-elle correcte? Comment ça marche?

AS: Oui, Peter Rizun a produit un excellent document décrivant cela - l'algorithme du «consensus émergent». Cela a vraiment besoin d'un article entier, alors permettez-moi de juste vous référer à lui.

Nous avons également effectué des travaux théoriques et analytiques justifiant la proposition, que vous pouvez trouver dans le document «marché des frais» de Peter et mon article sur le «bloc de transaction unique (vide)». Pour résumer le travail en une seule phrase: «La propagation du réseau et les retards de validation des blocs créent un coût non nul pour les transactions et limitent la taille moyenne des blocs à la capacité moyenne du réseau physique sous-jacent.»

BC: En quoi BU diffère-t-il de clients tels que Bitcoin Classic et XT?

AS: BU reconnaît qu'un consensus algorithmique des parties prenantes au-dessus du consensus de Nakamoto n'est pas réellement possible. Par exemple, une critique significative de Classic et XT était «et si les mineurs signalaient faussement des blocs larges, puis quand viendrait le moment, les rejetteraient?» BU reconnaît l'impossibilité de ce consensus de couche supérieure (ou plus exactement, que le Consensus de Nakamoto est le seul - Et d'ailleurs, d'un point de vue théorique, il évite le résultat FLP parce qu'il n'atteint jamais réellement le consensus - si un alien avec une technologie impressionnante recalculait la chaîne de blocs à partir du bloc de genèse, le Consensus de Nakamoto passerait sur cette chaîne), et n'a donc pas d'algorithme de coordination qui modifie automatiquement les paramètres de consensus.

Au lieu de cela, BU retire la plupart des paramètres non-protégés-contre-la-fonction-monnaie de la couche consensus. Donc, si le reste du réseau passe soudainement à des blocs plus gros, vous le suivrez. Mais si quelqu'un dépense l'argent de quelqu'un d'autre ou se donne une récompense de bloc trop importante, vous ne le ferez pas.

Et cela exige l'intervention de l'opérateur pour générer réellement le premier grand bloc. Cela permet à un mineur de reculer rapidement s'il s'avère que d'autres mineurs signalent faussement («un faux processus» dans la terminologie FLP).

BC: La communauté Bitcoin a récemment annoncé une subvention de 1,2 million de dollars pour le développement du protocole. Quelle est votre opinion sur le message global des principes attachés à cette nouvelle subvention?

AS: C'est formidable que les gens soient prêts à financer le développement du Bitcoin! Le message est complètement sur la cible. Le «modèle Blockstream» où une société commerciale à but lucratif dirige le développement semble ne pas être dans le meilleur intérêt du bitcoin en tant que monnaie, et des détenteurs de la monnaie bitcoin.

BC: Quelle est l'opinion de l'équipe de BU sur Segregated Witness?

AS: Je ne peux pas parler pour l'équipe, ou plus important encore, je ne peux pas parler pour les membres de BU. Mon avis est que:

Segregated Witness (S.W) est une complexité inutile ajoutée à la chaîne de blocs.

S.W ne scale pas suffisamment pour intéresser les entreprises à créer des produits ou des services Bitcoin, il ne scale même pas suffisamment pour déployer de manière significative des solutions hors chaîne (off chain).

S.W a environ 1.7MB de taille éventuelle mais un passif de spam de 4MB (cela signifie-t-il qu'un simple hard fork augmentant à 2MB résulte dans un bloc total de 8 Mo? Parce qu'émotionnellement 2MB est facile sur le réseau d'aujourd'hui, mais 8MB est peut-être "le pousser"

S.W ne supprime pas les problèmes existants (comme la malléabilité) parce que vous pouvez toujours générer des transactions anciennes, cela crée beaucoup de "dette technique" qui rendra Bitcoin beaucoup plus difficile à maintenir et à prolonger à l'avenir

S.W résout certains problèmes existants si des transactions de type SegWit sont utilisées. Mais beaucoup d'autres problèmes connus n'ont pas fait la «coupure» (le fait que d'autres problèmes aient été promis, mais n'ont pas été pris en compte sur la complexité de développement de SegWit - le concept est en retard d'un semestre et a des fonctionnalités manquantes). Un format de transaction complètement nouveau peut résoudre beaucoup plus de problèmes, plus simplement et élégamment.

S.W oblige chaque portefeuille à changer leur code.

S.W semble être politique - un espace de grande signature semble encourager certains cas d'utilisation et décourager d'autres, et il confirme les développeurs comme les intendants du réseau et l'arbitre de certains "numéros magiques".

BC: Que voulez-vous dire à la communauté en ce qui concerne le fait de vous faire confiance sur le protocole Bitcoin?

AS: Vous n'avez pas besoin de faire confiance. Vous ne devriez faire confiance à personne. BU soutient et encourage la mise en œuvre de plusieurs clients, et nous vous donnons les outils pour vous appuyer sur le consensus Nakamoto.

Dans le même temps, nous sommes des détenteurs de bitcoins et nous ne sommes pas employés par des sociétés à but lucratif avec des blockchains concurrentes ...

BC: Pensez-vous que la taille des blocs se résoudra bientôt?

AS: Oui, je l'espère. Je pense que le soutien individuel et corporatif de Bitcoin Unlimited, soit publiquement, soit en parlant en privé aux gros mineurs fera une grande différence. Montrons aux mineurs que la majorité économique et commerciale veut de plus gros blocs!

Merci, Andrew, pour avoir donné à nos lecteurs un aperçu de l'environnement Bitcoin Unlimited.
------------------------------------------------------