Je me suis tenu à l’écart du débat sur la taille des blocs, mais le lancement de Bitcoin XT mérite une brève mention.
Mes raisons pour rester en dehors du débat sont assez évidentes : je ne suis pas un mineur, je ne suis pas un développeur principal, je ne gère pas de service de portefeuille, je n’ai aucune connaissance particulière des compromis techniques et, peut-être. le plus important, je suis pas fou. Si je voulais discuter avec les gens sur Internet, il y a des sujets bien plus intéressants que la taille des blocs de Bitcoin…
Mais plusieurs personnes m’ont demandé ce que j’en pensais. Et, au fond, je pense que cela pourrait se résumer à trois problèmes : 1) la peur de deux types d’échec différents, 2) un conflit de visions et 3) l’absence de processus pour concilier les deux premiers problèmes.
Peur de deux types d’échec différents
Peur d’une panne technique
Je ne contribue pas, mais je lis la liste de diffusion Bitcoin Development. Je trouve cela extrêmement utile pour suivre une grande partie du débat quotidien. Ce qui devient clair à la lecture, c’est qu’il y a (au moins !) deux cultures distinctes à l’œuvre.
Premièrement, il existe une très forte culture d’ingénierie de sécurité. Je pense parfois que l’astuce pour être un bon ingénieur en sécurité est de penser comme un testeur de logiciels (et vice versa) : « Comment pourrais-je casser ça ? »… « Comment un attaquant pourrait-il contourner cela ? »… « Qu’est-ce qui pourrait mal se passer ici ? ? »… « Comment pourrais-je forcer le fournisseur de ce service à gaspiller toutes ses ressources » Et ainsi de suite. Votre travail consiste à comprendre toutes les façons dont quelque chose pourrait échouer et à y remédier.
Ainsi, lorsqu’on vous présente quelque chose comme une taille de bloc accrue, vous vous concentrez évidemment sur tout ce qui pourrait mal tourner : les mineurs utilisant des connexions lentes pourraient se désynchroniser avec ceux de l’autre côté, l’augmentation du coût de fonctionnement d’un nœud pourrait créer une pression de centralisation et ainsi de suite. Et lorsque vous comparez cela aux avantages potentiels, vous pensez peut-être que le changement n’a pas de sens : il y a un risque technique et de sécurité accru, mais vous n’avez pas résolu le problème d’évolutivité sous-jacent au cœur du système… vous avez, d’une certaine manière, je viens de jeter la canette sur la route. On pourrait donc dire qu’un problème de conduite ici est «peur d’une panne technique »: le changement, dont les bénéfices sont incertains, pourrait causer des dommages catastrophiques. Mieux vaut ne pas le faire tout de suite.
Peur de l’échec pratique
Mais, de l’autre côté, il y a une culture quelque peu différente, qui vient d’un monde où il y a des problèmes partout où l’on regarde et où ils doivent tous être résolus. Alors vous choisissez le plus gros, vous le réparez et vous continuez. Les fonctions d’ingénierie des grandes entreprises sont souvent ainsi. Vous savez que votre changement pourrait causer des problèmes, mais si vous pensez que « ne rien faire » n’est pas une option, alors il s’agit de prendre la moins pire décision. Après tout, il n’existe généralement pas de bonnes solutions, mais seulement des compromis.
Ainsi, si vous êtes confronté à un problème tel que des blocs qui se remplissent dans un délai prévisible, il est naturel de vous demander : quel est le risque de ne rien faire ? Si vous pensez que la plupart des consommateurs ont choix et abandonnerez simplement un système qui ne peut pas garantir la confirmation des transactions dans un délai raisonnable, alors vous considérerez probablement l’échec de l’augmentation de la taille du bloc comme quelque chose qui entraînera un exode catastrophique d’utilisateurs et votre parti pris sera probablement en faveur du changement. . Pour vous, le problème est «peur de l’échec pratique »: ne pas augmenter la taille des blocs, un changement qui comporte de toute façon des risques incertains, fera fuir les utilisateurs et fera du système un échec dans tous les cas pratiques.
Bien sûr, j’exagère pour obtenir un effet et j’ai ignoré de nombreux aspects de l’argument (par exemple, le marché des frais, etc.). Et je suis sûr que certains détails sont tout simplement faux. Mais attention : même dans ce modèle simpliste, cela ne signifie pas que l’un ou l’autre côté a « tort » ou « mauvais » : il est possible d’adopter l’un ou l’autre point de vue tout à fait légitimement et de croire passionnément que l’autre côté a tort.
Un choc de visions
Là où les choses deviennent plus complexes, c’est lorsqu’il s’agit de vision : s’il y avait un accord commun sur le résultat souhaité (par exemple « x transactions par seconde sur la blockchain d’ici 2017 » ou « le système devrait prendre en charge ce nombre de portefeuilles de consommateurs ») alors le la discussion serait une pure discussion d’ingénierie : « quelle est la meilleure façon d’atteindre cet objectif ? » Mais il me semble qu’il n’y a pas d’accord sur cette vision sous-jacente.
Ainsi, les discussions techniques se perdent dans le bruit des gens qui se parlent ou, pire encore, qui ont recours à des arguments ad hominem. Si vous discutez à partir de prémisses différentes, vous n’arrivez malheureusement jamais à rien. C’est ce qui rend les discussions politiques sur Internet si fastidieuses.. !
Processus
Dans la plupart des projets, ces problèmes peuvent être résolus, en fin de compte, grâce au modèle du « dictateur bienveillant ». Linus décide simplement. Malheureusement, ce processus ne fonctionne tout simplement pas dans un système comme Bitcoin. Il ne suffit pas de contrôler quel code entre dans la distribution « principale » : les règles de réseau en vigueur sont une fonction complexe de l’adoption par les mineurs, de l’adoption des nœuds complets, de l’adoption des portefeuilles, de l’adoption des principaux commerçants/processeurs, et bien plus encore. Il s’agit d’un processus politique et intrinsèquement compliqué. Le débat sur la taille des blocs ne sera donc probablement que la première d’une longue série de controverses de ce type dans ce monde. Le lancement de Bitcoin XT est un moyen intéressant de forcer le débat vers une conclusion, mais il risque d’être compliqué.
Et j’espère que ceux qui s’intéressent aux « blockchains privées » ne se sentent pas satisfaits en lisant ceci. Gérer la maintenance et les mises à niveau des systèmes de registres partagés entre les entreprises ne sera pas non plus une promenade de santé.
Je n’ai aucune idée précise de la direction que cela prendra ni de la vision de l’avenir qui prévaudra. Mais j’espère (peut-être désespérément) que ce problème sera résolu grâce aux actions de professionnels agissant de bonne foi et qu’aucune des deux parties n’aura recours à de « sales tours ».
Share this content: