La charge de Brian Armstrong

11
385

Traduction d’un article de Brian Armstrong, CEO de Coinbase, publié hier sur medium.com  :

Le week-end dernier j’ai participé à une Table ronde avec Charlie Lee et environ 70 autres membres de la communauté Bitcoin. Je voudrais – sans divulguer les noms ou le contenu des conversations privées – partager ici ma vision personnelle de ce qui est arrivé à cette conférence.

Un certain nombre de réunions ont déjà eu lieu entre les développeurs de Bitcoin Core, les mineurs et les responsables des grandes sociétés du secteur. Comme vous le savez, le désaccord sur la façon dont Bitcoin devrait évoluer est profond. D’un côté, se trouvent les « core developers » qui s’inquiètent des conséquences qu’un changement d’échelle pourrait avoir sur la décentralisation, de l’autre vous avez la plupart des entreprises de l’écosystème qui ne souhaitent que la croissance. Les mineurs, pris entre deux feux, sont divisés.

Je pense que les organisateurs de la conférence espéraient une sorte de consensus (comme ce qui est arrivé à Hong Kong), mais il est devenu clair au final que le fossé était trop grand. Les conversations ont d’abord porté sur divers compromis qui pourraient permettre de repousser le problème du changement d’échelle à plus tard. Mais au fil les conversations, je réalisé que les solutions à court terme dont nous discutions dissimulaient un problème beaucoup plus important : le risque d’une crise systémique si l’équipe des développeurs de Bitcoin Core reste la seule à travailler sur ​​Bitcoin.

L’équipe actuelle rassemble des gens au QI très élevé, mais, après avoir passé quelque temps avec eux le week-end dernier, il y a certaines choses que je trouve très inquiétante chez ces individus :

1. Certains d’entre eux montrent des compétences de communication très pauvres ou un manque de maturité – ce qui bloque l’arrivée de nouveaux développeurs pour le protocole Bitcoin.

2. Ils préfèrent des solutions « parfaites » à « suffisamment bonnes ». Et si aucune solution parfaite n’existe, ils semblent préférer l’inaction, même si cela met bitcoin en danger.

3. Ils semblent avoir la conviction forte que Bitcoin ne sera pas capable d’évoluer à long terme, et que toute augmentation de la taille des blocs est une pente glissante vers un avenir qu’ils ne sont pas disposés à autoriser.

Même si les « core developers » affirment qu’ils ne rejettent pas l’idée d’un « hard fork » à 2Mo (ils l’ont placé sur leur propre feuille de route, très loin dans le futur), ils refusent d’en faire une priorité. Ils préfèrent privilégier des solutions provisoires parce qu’ils ne font pas confiance à la communauté pour prendre des décisions raisonnables en ce qui concerne l’avenir. Ils se considèrent comme les planificateurs centraux du réseau, et les protecteurs du peuple. Ils iront jusqu’à accepter l’échec de Bitcoin, du moment que cela ne remet pas en cause leurs principes.

Posséder un QI élevé ne suffit pas à garantir la réussite d’une équipe. Il faut également savoir faire des compromis raisonnables, être accueillant, accessible, être capable de collaborer et de communiquer. Une équipe qui ne possède pas ces qualités sera incapable d’attirer les talents à elle et aura du mal à poursuivre son travail à long terme. À mon humble avis, le plus grand péril de Bitcoin en ce moment c’est, ironiquement, ce qui a été son principal atout dans le passé : les développeurs de Bitcoin Core.

 

Problèmes à l’horizon

Lors de la conférence un scénario d’échec a été avancé. Il est pertinent, troublant et montre avec objectivité ce qui pourrait advenir :

La réduction de moitié la prochaine récompense de bloc arrivera en juillet. Admettons que les mineurs soient en mesure d’extraire un bitcoin pour 250 $ (je ne connais pas le montant exact, ceci n’est donc qu’une supposition). Après le « halving » en juillet le coût pour extraire une unité va doubler pour atteindre 500 $. Si le prix de bitcoin reste autour de 425 $, il ne sera plus rentable pour un certain nombre de mineurs de poursuivre l’exploitation minière.

La conséquence de ceci est que nous pourrions voir une réduction de la puissance de hachage à partir du halving de juillet. Peut-être dans la proportion de 10 à 50% (je ne parviens pas à estimer cela précisément, si quelqu’un en est capable, merci de me répondre).

Dans la pire hypothèse, 50% de la puissance de hachage diparaitra à ce moment-là, car ce n’est plus rentable pour les mineurs. Cela signifie que les blocs mettront 20 minutes en moyenne pour être extrait, au lieu de 10 aujourd’hui. Mais les blocs sont déjà complets à 70% à l’heure actuelle. Si le temps moyen de confirmation monte à 20 minutes, cela signifie que nous serons à 140% de la capacité sur chaque bloc, et que nous accumulerons les retards.

Bitcoin dispose d’un mécanisme pour ajuster la difficulté de la preuve de travail. Cela se produit tous les 2 016 blocs, environ deux semaines. Mais si les blocs ne sont extraits que toutes les 20 minutes, cela prendra quatre semaines.

Entre temps les choses auront empiré, et après ces quatre semaines d’attente, il faudra encore jusqu’à deux semaines pour revenir à la « normale ». Donc, il faut s’attendre à ce que les frais de transaction augmentent de façon considérable sur une période de six semaines. En outre, avec tant de transactions en attente, les « mempools » de la plupart des nœuds seront pleins, ce qui signifie qu’il est probable que la plupart des transactions ne seront même pas relayées, et beaucoup moins encore confirmées. Cela pourrait empêcher les commerçants et les processeurs de paiement d’obtenir ne serait-ce qu’une notification concernant une transaction.

Si cela provoque une chute du cours du bitcoin à l’automne, cela rendra l’exploitation minière encore moins rentable, et la spirale négative se poursuivra.

On ne sait pas quelle est la probabilité de ce scénario (j’ai décrit le pire des cas). La réduction de moitié du nombre de bitcoins mis en circulation pourrait tout aussi bien conduire à une hausse du cours. Il est difficile d’estimer quelle proportion de la puissance de hachage pourrait s’arrêter après le « halving ». Il est possible que cela soit très inférieur à 50%. Mais je pense qu’il n’y a aucune raison de prendre des risques et qu’il est totalement irresponsable de jouer ainsi avec le destin. Le réseau aujourd’hui, avec 70% des blocs pleins, connait déjà des congestions et de retards. Toute réduction de la puissance de hachage va exacerber ces problèmes.

Le fait que les « core developers » de Bitcoin ont permis au réseau d’atteindre ce point est une négligence qui en dit long, je pense, sur leurs motivations et leurs compétences. Nous n’avons pas envie de jouer l’avenir de Bitcoin aux dés et d’attendre de voir si ce scénario catastrophe va se concrétiser.

Heureusement, depuis deux ans maintenant, des voix raisonnables se lèvent dans la communauté pour appeler à une augmentation prudente des capacités de Bitcoin. Certains ont même quitté l’équipe des « core developers » pour écrire le code qui permettra d’y arriver et tracer le chemin qui permettra d’éviter de prendre tous ces risques.

 

Une voie à suivre

Je crois que nous connaissons la voie à suivre pour éviter le scénario décrit ci-dessus.

1. La première étape c’est la mise à niveau immédiate des blocs à 2Mo. C’est la solution la plus réaliste à court terme pour gagner du temps. Soit nous faisons cette mise à jour dès maintenant, quand il est encore temps, soit nous la ferons dans l’urgence. J’en ai la conviction, la question n’est plus de savoir si nous allons faire cette augmentation, mais quand est-ce que nous allons la faire. Le code pour faire cette mise à jour dès à présent est d’ores et déjà disponible. Ce code est de grande qualité, il est écrit par d’anciens « core developers », et est déjà en cours d’exécution par un certain nombre de sociétés Bitcoin (y compris Coinbase). Utiliser BitcoinClassic ne signifie pas que nous devons être fidèle à cette équipe pour toujours, c’est tout simplement la meilleure option pour atténuer les risques en ce moment. Nous pourrons utiliser le code de n’importe quelle autre équipe à l’avenir.

2. Nous avons besoin de communiquer avec les mineurs chinois au sujet de cette mise à niveau. On les a trompés en leur faisant croire qu’une équipe unique de 4 à 5 personnes peut garantir la sécurité du protocole Bitcoin, alors que c’est ce groupe précisément qui constitue la plus grande menace pour leurs entreprises. J’ai demandé à cnLedger sur Twitter de m’aider à traduire cet article. Nous devons améliorer nos relations de travail avec les mineurs chinois.

3. À long terme, nous avons besoin de former une nouvelle équipe pour travailler sur le protocole de Bitcoin. Une équipe qui accueille de nouveaux développeurs prêts à faire des compromis raisonnables, une équipe qui aidera le protocole à changer d’échelle. Nous en dirons plus à ce sujet dans un mois ou deux.

Il est intéressant de noter que la réponse des « core developers » au problème de l’évolutivité a été de proposer une solution appelée « segregated witness ». Bien qu’il s’agisse d’une solution bien conçue, je crois qu’il serait très risqué d’utiliser SegWit comme une solution unique de mise à l’échelle compte tenu de la situation mentionnée ci-dessus. Un des plus grands risques de « segregated witness » comme une solution de « scalabilité » c’est que pour obtenir le bénéfice de l’augmentation promise, il faudra non seulement un nouveau code pour Bitcoin Core mais aussi un nouveau code pour chacun des principaux fournisseurs de portefeuille. Il est peu probable que ce sera fait à temps pour éviter les problèmes de « scalabilité » auxquels nous sommes actuellement confrontés. Le nombre de lignes de code qui devront être écrites pour l’ensemble du secteur sera infiniment supérieur avec « segregated witness » que pour une simple augmentation de 1Mo à 2Mo. On l’a expliqué aux développeurs de Bitcoin Core lors de la conférence mais sans changer leurs convictions sur la meilleure solution de « scalabilité » à court terme. Puisque le halving arrive en juillet et que des retards sont déjà éprouvés par le réseau, mon avis est qu’il serait irresponsable et dangereux de suivre la feuille de route proposée lors du consensus de Hong Kong.

 

Conclusion

Mon idée générale  – que j’ai soumise lors de la table ronde du week-end dernier – est que Bitcoin aura beaucoup plus de succès si plusieurs groupes travaillent sur le développement du protocole plutôt qu’un seul, surtout avec les limitations mentionnées ci-dessus. Je pense que nous pouvons y arriver, que nous devons y arriver.

Si vous voulez assurer le succès de Bitcoin, je vous encourage à passer tout d’abord à Bitcoin classique, puis faire ce que vous pouvez pour soutenir le plan en trois étapes que j’ai indiqué ci-dessus. C’est la meilleure voie à suivre pour atténuer le péril dans lequel nous nous trouvons.

À l’avenir, nous aurons besoin de former une nouvelle équipe pour travailler sur le protocole et aider Bitcoin à devenir un système multi-partis afin d’éviter le risque systémique provoqué par l’équipe actuelle. J’espère avoir des nouvelles à ce sujet dans les prochains mois.

 

Questions / critiques habituelles

À la table ronde, voici les arguments qui m’ont été opposés :

Le marché est incertain car tout le monde est en désaccord, ce ne serait pas mieux de mettre de côté nos différences et de travailler ensemble ?

Il est assez difficile pour deux personnes de s’accorder. Trois c’est plus difficile, et quatre l’est encore davantage. Une fois qu’une communauté atteint les cinquante ou cent personnes, mettre tout le monde d’accord est un objectif irrationnel. Mais c’est comme ça et il existe des mécanismes pour résoudre les désaccords au sein d’un groupe important de personnes (comme le vote). Si on attend que tout le monde soit d’accord, autant dire tout de suite qu’on ne va rien faire.

J’ai utilisé l’analogie des élections présidentielles aux États-Unis. Mettre d’accord les supporters de Donald Trump et d’Hilary Clinton est un projet insensé. Mais les élections arrivent et quand elles seront derrière nous tout le monde devra vivre dans le même pays. Le système fonctionne. (Quelqu’un a fait remarquer que les gens pourraient migrer au Canada si Trump gagne. C’est peut-être vrai, mais cela ne représenterait au final qu’une proportion infime de la population des États-Unis, ce qui n’invalide pas la méthode).

J’ai aussi donné l’exemple des navigateurs web. Les équipes de « Chrome » et de « Safari » sont en concurrence, mais elles assistent aux mêmes conférences et collaborer avec l’IETF sur les normes. De nombreuses entreprises concurrentes étaient ainsi présentes à la conférence. Elles ne sont pas hostiles entre elles. Nous travaillons tous dans le même secteur et nous sommes amis à bien des égards. Ce serait la même chose si plusieurs équipes travaillaient sur le protocole de Bitcoin. En multipliant les choix possibles, vous obtiendrez plus de progrès, pas moins.

Le marché est incertain maintenant, car nous sommes dans la situation d’un pays qui s’apprête à effectuer sa première élection. Une fois que le premier « hard fork » se sera produit avec succès et que plusieurs équipes émergeront, cela va créer de la confiance et montrer l’efficacité du système de gouvernance de Bitcoin (le vote des mineurs).

Bitcoin est différent parce qu’il exige des règles de consensus – cela ne fonctionnera jamais avec plusieurs équipes.

Je ne pense pas que cela soit juste. Différentes équipes et les implémentations peuvent travailler sur un logiciel interopérable qui utilise le même protocole, ce qui est déjà le cas aujourd’hui dans Bitcoin. Des mises à niveau ou des améliorations peuvent être proposées par toutes les équipes, mais elles n’entreront en vigueur que lorsqu’un seuil de majorité sera atteint. Bitcoin dispose d’un mécanisme pour résoudre ces désaccords : le vote des mineurs.

Lors de la conférence, nous avons passé beaucoup de temps à discuter des améliorations du vote des mineurs, la façon d’impliquer les utilisateurs (ou les détenteurs de bitcoins) dans ces décisions. Quelques propositions pertinentes de mécanismes de vote ont été suggérées, par exemple de permettre aux utilisateurs qui génèrent des transactions de signaler un vote en faveur d’une mise à niveau. Ce sont de bonnes idées qui, je pense, devraient être explorées davantage, mais je pense que leur mise en œuvre pratique serait aussi controversée que tout autre changement majeur dans Bitcoin, il est donc irréaliste d’attendre que cela devienne une réalité dans un proche avenir étant donnée l’urgence des problèmes que nous avons à traiter. Nous avons tout d’abord besoin de passer à 2Mo afin de gagner un peu de temps avant de travailler sur ces propositions qui nécessiteront probablement une nouvelle équipe pour éviter toute discorde dans la communauté.

Un seuil de 75% ne suffit pas à déclencher une mise à niveau parce que le réseau sera divisé !

J’en ai discuté longuement ailleurs, mais cela est également faux à mon avis. La pression économique finira par convaincre la grande majorité (99% +) des mineurs, des portefeuilles, et des échanges d’adopter un « fork ». Il y a une grande différence entre le seuil de déclenchement et ce que la majorité ultime finira par adopter.


Texte intégral à lire sur medium.com