Vitalik répond à Musk : l'amélioration de l'évolutivité de la blockchain n'est pas simple
TechFlow SélectionTechFlow Sélection
Vitalik répond à Musk : l'amélioration de l'évolutivité de la blockchain n'est pas simple
À mesure que la capacité augmente, le nombre minimal de nœuds augmente également, tout comme le coût de la chaîne d'archivage (si personne ne prend la peine de gérer la chaîne d'archivage, le risque de perte de données augmente).
Dédié à des analyses Web3 approfondiesRédaction : Vitalik Buterin
Traduction : Alyson
Récemment, Elon Musk, fondateur de Tesla, a publié un tweet affirmant que Dogecoin pourrait, idéalement, accélérer le temps de confirmation des blocs par un facteur 10, augmenter la taille des blocs d’un facteur 10 et réduire les frais de transaction par un facteur 100, devenant ainsi facilement dominant.
Cette déclaration a suscité de nombreuses critiques de la part d’influenceurs du secteur crypto. Aujourd’hui, Vitalik Buterin, fondateur d’Ethereum, a également réagi dans un article, soulignant que simplement améliorer les paramètres d’un réseau blockchain entraîne davantage de complications. Il détaille ici les problèmes et contraintes auxquels sont confrontés les réseaux blockchain lorsqu’ils cherchent à améliorer leurs performances. TechFlow a traduit cet article, avec quelques coupes n’affectant pas le sens original.
Jusqu’où peut-on pousser l’évolutivité d’une blockchain ? Comme l’espère Musk, est-il possible de « réduire le temps de confirmation des blocs par 10, augmenter leur taille par 10 et diminuer les frais par 100 » sans provoquer une centralisation extrême qui compromettrait les propriétés fondamentales de la blockchain ? Si ce n’est pas possible, jusqu’où peut-on aller ? Et si on changeait l’algorithme de consensus ? Encore plus important, que se passerait-il si on adoptait des technologies comme les ZK-SNARK ou le sharding (fragmentation) ?
Il s’avère qu’il existe des facteurs techniques importants et subtils — avec ou sans sharding — qui limitent fortement l’évolutivité des blockchains. Dans de nombreux cas, il existe des solutions, mais même alors, il y a des limites. Cet article examine ces problèmes.
1. Les nœuds doivent rester suffisamment dispersés
À 2h35 du matin, vous recevez un appel urgent de votre associé situé à l’autre bout du monde, qui vous aide à gérer votre pool minier (ou éventuellement un pool de mise en jeu). Depuis environ 14 minutes, il vous dit que votre pool, ainsi que quelques autres, s’est séparé de la chaîne principale, portée encore par 79 % du réseau. Selon vos nœuds, les blocs de la chaîne majoritaire sont invalides. Une erreur de solde apparaît : un bloc clé semble avoir attribué illégalement 4,5 millions de jetons supplémentaires à une adresse inconnue.
Une heure plus tard, vous êtes en discussion Telegram avec deux petits pools miniers. Finalement, quelqu’un colle un lien vers un tweet contenant un message officiel. Le tweet commence par : « Annonce d’un nouveau fonds durable sur chaîne pour le développement du protocole ».
Le matin venu, les débats envahissent Twitter et les forums communautaires. Mais à ce moment-là, une grande partie de ces 4,5 millions de jetons a déjà été convertie en d’autres actifs sur chaîne, générant des milliards de dollars de transactions DeFi. Soit 79 % des nœuds de consensus, soit tous les principaux explorateurs de blocs et nœuds légers suivent désormais cette nouvelle chaîne.
Peut-être que ce nouveau fonds financera certains développements, ou peut-être que tout aura été absorbé par les principales bourses. Quoi qu’il en soit, ce fonds devient un fait accompli, contre lequel les utilisateurs ordinaires sont impuissants.
Cela pourrait-il arriver sur votre blockchain ? La communauté dirigeante de votre blockchain — pools miniers, explorateurs de blocs, nœuds hébergés — est probablement bien coordonnée. Ils sont probablement tous sur le même canal Telegram et dans les mêmes groupes WeChat. S’ils décidaient de modifier soudainement les règles du protocole pour servir leurs intérêts, ils pourraient le faire. La seule défense fiable contre une telle attaque sociale coordonnée est une défense passive : la dispersion réelle du groupe, c’est-à-dire les utilisateurs.
Imaginez que chaque utilisateur exécute un nœud vérificateur de la blockchain, refusant automatiquement les blocs qui violent les règles du protocole (même si plus de 90 % des mineurs ou des participants y consentent). Comment l’histoire aurait-elle évolué ? Si chaque utilisateur exécutait un nœud, l’attaque échouerait rapidement : certains pools et bourses seraient isolés, semblant assez ridicules.
Mais même si seulement certains utilisateurs exécutaient des nœuds, l’attaquant ne remporterait pas une victoire totale ; au contraire, cela entraînerait confusion, chaque utilisateur voyant une version différente de la blockchain. Au minimum, la panique boursière et la division persistante réduiraient fortement les gains de l’attaquant. L’idée même de devoir gérer un conflit prolongé suffirait à dissuader la plupart des attaques.
Tweet de Hasu, chercheur associé chez Paradigm
Si votre communauté compte 37 nœuds exécutant un programme et 80 000 programmes passifs vérifiant les signatures et les en-têtes de blocs, l’attaquant gagne. Si chaque membre de votre communauté exécute un nœud, l’attaquant échoue. Nous ne connaissons pas précisément le seuil critique de résilience collective contre les attaques coordonnées, mais une chose est absolument claire : plus il y a de nœuds, mieux c’est ; moins il y en a, pire c’est. Nous avons certainement besoin de dizaines, voire de centaines de nœuds.
2. Où se situent les limites du travail des nœuds ?
Pour maximiser le nombre d’utilisateurs capables d’exécuter un nœud, nous nous concentrons sur le matériel grand public ordinaire. Trois limitations clés affectent la capacité d’un nœud complet à traiter un grand volume de transactions :
-
Puissance de calcul : quel pourcentage de la puissance CPU peut être consacré en toute sécurité à la validation d’un bloc ?
-
Bande passante : compte tenu de la réalité actuelle des connexions Internet, quelle taille en octets un bloc peut-il contenir ?
-
Stockage : combien de Go de disque pouvons-nous exiger des utilisateurs ? Et à quelle vitesse doit-il être lu ? (Un disque dur classique suffit-il, ou faut-il un SSD ?)
Beaucoup pensent à tort que des techniques « simples » permettent d’étendre indéfiniment la blockchain, parce qu’ils surestiment trop optimistement ces chiffres. Examinons chaque facteur :
1) Puissance de calcul
Réponse erronée : 100 % de la puissance CPU peut être utilisée pour valider un bloc.
Réponse correcte : environ 5 à 10 % de la puissance CPU peut être allouée à la validation d’un bloc.
Quatre raisons principales expliquent ce faible ratio :
-
Nous avons besoin d’une marge de sécurité contre les attaques DoS (les transactions malveillantes exploitant des failles peuvent prendre plus de temps à traiter que les transactions normales) ;
-
Un nœud déconnecté doit pouvoir se synchroniser rapidement. Si je suis hors ligne pendant une minute, je dois pouvoir rattraper le retard en quelques secondes ;
-
Exécuter un nœud ne doit pas drainer rapidement la batterie ni ralentir toutes les autres applications ;
-
Les nœuds doivent aussi effectuer d’autres tâches non liées à la production de blocs, notamment valider et répondre aux transactions entrantes via le réseau P2P.
Notez que jusqu’à récemment, la plupart des explications à « pourquoi seulement 5-10 % ? » mettaient l’accent sur un problème différent : dans le PoW, les blocs apparaissant aléatoirement, un temps long de validation augmente le risque de création simultanée de plusieurs blocs.
Plusieurs solutions existent (Bitcoin NG ou passage à la preuve d’enjeu). Mais ces correctifs ne résolvent pas les quatre autres problèmes, donc n’apportent pas les gains d’évolutivité escomptés.
Le parallélisme n’est pas non plus une solution universelle. Même un client blockchain apparemment monothread est souvent parallélisé : une thread vérifie les signatures, une autre gère l’exécution, une troisième traite en arrière-plan la logique du mempool. En outre, plus on approche de 100 % d’utilisation de chaque thread, plus la consommation énergétique augmente et plus la marge de sécurité contre les DoS diminue.
2) Bande passante
Réponse erronée : si nous avons des blocs de 10 Mo toutes les 2-3 secondes, et que la plupart des utilisateurs ont une connexion > 10 Mo/s, ils peuvent forcément gérer.
Réponse correcte : peut-être pouvons-nous gérer des blocs de 1 à 5 Mo toutes les 12 secondes, et encore difficilement.
Aujourd’hui, on entend souvent parler de la bande passante théorique des connexions Internet : 100 Mbps ou même 1 Gbps. Mais plusieurs écarts séparent la bande passante annoncée de la réalité :
-
« Mbps » signifie « millions de bits par seconde », or un bit vaut 1/8 d’octet : divisez donc par 8 pour obtenir les octets ;
-
Comme toutes les entreprises, les FAI mentent souvent ;
-
Plusieurs applications partagent la même connexion Internet, donc un nœud ne peut pas monopoliser toute la bande passante ;
-
Le réseau P2P implique inévitablement des surcoûts : les nœuds téléchargent et retransmettent souvent plusieurs fois le même bloc (sans compter les transactions diffusées via le mempool avant inclusion).
Lorsque Starkware a mené une expérience en 2019, publiant des blocs de 500 Ko — rendus possibles par une baisse des coûts en gaz — plusieurs nœuds n’ont pas pu traiter cette taille.
Depuis, la capacité des blockchains à gérer de gros blocs s’est améliorée et continuera à progresser. Mais quoi que nous fassions, nous ne pourrons jamais naïvement convertir la bande passante moyenne en Mo/s, supposer un délai d’acceptation de 1 seconde, et imaginer supporter de tels volumes.
3) Stockage
Réponse erronée : 10 To.
Réponse correcte : 512 Go.
Comme vous pouvez l’imaginer, l’argument principal est ici aussi : différence entre théorie et pratique. Théoriquement, vous pouvez acheter un SSD de 8 To sur Amazon. En pratique, l’ordinateur utilisé pour écrire ce billet dispose de 512 Go, et beaucoup d’utilisateurs seront paresseux (ou incapables d’acheter un SSD de 800 $) et recourront à des fournisseurs centralisés.
De plus, même si vous installez un nœud sur un disque de stockage, une activité intense peut vite griller le disque, vous forçant à en racheter constamment.
En outre, la taille du stockage détermine le temps nécessaire à un nouveau nœud pour se connecter et participer au réseau. Toute donnée stockée par les nœuds existants doit être téléchargée par les nouveaux. Le temps initial de synchronisation (et la bande passante) constitue un obstacle majeur à l’exécution d’un nœud. En écrivant ce billet, synchroniser un nouveau nœud geth m’a pris environ 15 heures.
3. Les risques des blockchains fragmentées (sharding)
Aujourd’hui, exécuter un nœud Ethereum est déjà difficile pour beaucoup d’utilisateurs. Nous atteignons donc un goulot d’étranglement. La préoccupation principale des développeurs est la taille du stockage. Par conséquent, actuellement, les efforts pour résoudre les goulots de calcul et de données, ou même changer l’algorithme de consensus, ne conduiront pas à une augmentation significative de la limite de gaz. Même en corrigeant la plus grande vulnérabilité DoS d’Ethereum, la limite de gaz ne pourrait augmenter que de 20 %.
La seule solution au problème de stockage est l’« étatlessness » (absence d’état) et l’expiration de l’état. L’étatlessness permet à certains nœuds de valider la blockchain sans stockage permanent. L’expiration efface les données inutilisées récemment, obligeant les utilisateurs à fournir manuellement des preuves de renouvellement.
Ces deux voies sont explorées depuis longtemps, et des preuves de concept existent déjà. Ensemble, elles pourraient fortement atténuer ces inquiétudes et ouvrir la voie à une hausse importante de la limite de gaz. Toutefois, même après leur mise en œuvre, la limite de gaz ne pourrait probablement être augmentée en toute sécurité que d’un facteur 3 environ, car d’autres limites prendraient alors le dessus.
Le sharding contourne fondamentalement les limites ci-dessus en dissociant les données incluses dans la blockchain des données que chaque nœud doit traiter et stocker. Il utilise des techniques mathématiques et cryptographiques avancées pour valider indirectement les blocs, sans que les nœuds aient à les télécharger et exécuter eux-mêmes.
Ainsi, une blockchain fragmentée peut atteindre des niveaux de débit transactionnel inaccessibles aux blockchains non fragmentées. Cela nécessite une grande sophistication cryptographique pour créer des méthodes efficaces et simples de vérification complète, capables de rejeter les blocs invalides, mais c’est faisable : la théorie est mature, et des preuves de concept basées sur des projets de spécifications sont en cours.
Ethereum prévoit utiliser un sharding quadratique, car chaque nœud doit gérer un seul fragment et la chaîne de balise (qui exige un travail pour chaque fragment). L’évolutivité totale est donc limitée. Si les fragments sont trop gros, les nœuds ne peuvent plus les gérer ; s’il y en a trop, la chaîne de balise devient ingérable. Le produit de ces deux contraintes forme une borne supérieure.
On pourrait imaginer aller plus loin avec un sharding cubique ou exponentiel. Dans un tel design, l’échantillonnage de disponibilité des données deviendrait beaucoup plus complexe, mais reste possible. Toutefois, Ethereum n’ira pas au-delà du quadratique. Car le sharding des transactions n’apporte pas de gain d’évolutivité supplémentaire, sauf à accepter des risques très élevés.
Quels sont ces risques ?
1) Nombre minimal d’utilisateurs
On peut imaginer qu’une blockchain non fragmentée fonctionne tant qu’un utilisateur participe. Ce n’est pas le cas d’une blockchain fragmentée : aucun nœud ne peut traiter seul l’ensemble de la chaîne, donc il faut suffisamment de nœuds pour le faire collectivement. Si chaque nœud peut traiter 50 TPS et que la blockchain en requiert 10 000, elle a besoin d’au moins 200 nœuds.
Si à un moment donné, il y a moins de 200 nœuds, alors soit les nœuds ne peuvent pas suivre, soit ils ne détectent pas les blocs invalides, ou d’autres problèmes surviennent, selon la configuration logicielle.
Si la capacité d’une blockchain fragmentée augmente d’un facteur 10, le nombre minimal de nœuds croît aussi d’un facteur 10. Alors, pourquoi ne pas commencer avec peu de capacité, puis l’augmenter en cas d’afflux d’utilisateurs, et la réduire en cas de départ massif ? Ainsi, on ajusterait exactement à la demande.
Plusieurs problèmes :
-
La blockchain ne peut pas mesurer précisément le nombre de nœuds uniques, donc cela nécessiterait une gouvernance pour fixer le nombre de fragments. Dépasser la capacité deviendrait source de divisions et conflits.
-
Que faire si beaucoup d’utilisateurs quittent soudainement ?
-
Augmenter le nombre minimal de nœuds pour démarrer un fork rend plus difficile la résistance à une prise de contrôle malveillante.
Presque certainement, le nombre minimal de nœuds ne devrait pas dépasser 1000. Il est donc difficile de justifier une blockchain avec plus de quelques centaines de fragments.
2) Accessibilité historique
Une propriété précieuse des blockchains est la pérennité. Quand une entreprise fait faillite ou perd la capacité de maintenir son écosystème, les actifs numériques stockés sur ses serveurs disparaissent en dix ans. En revanche, un NFT sur Ethereum est permanent.
Oui, en 2371, on téléchargera encore et récupérera votre CryptoKitty.
Mais si la capacité de la blockchain devient trop élevée, stocker toutes ces données devient plus difficile. À un moment donné, sous risque élevé, certaines parties de l’historique n’auront plus personne pour les conserver.
Quantifier ce risque est simple. Prenez la capacité de données de la blockchain (Mo/s), multipliez par 30 : vous obtenez la quantité annuelle en To. Le plan actuel de fragmentation d’Ethereum représente environ 1,3 Mo/s, donc ~40 To/an. Multiplié par 10, cela donne 400 To/an.
Si l’on veut que les données soient non seulement accessibles, mais aisément consultables, il faut ajouter des métadonnées (ex. : décompression des rollups), donc 4 Po/an, soit 40 Po après 10 ans. C’est une borne raisonnablement sûre pour la plupart des blockchains fragmentées.
Ainsi, sur ces deux dimensions, la conception du sharding d’Ethereum semble viser des valeurs proches du maximum sécurisé raisonnable. Les paramètres peuvent légèrement augmenter, mais pas beaucoup.
4. Conclusion
Deux approches existent pour étendre une blockchain : des améliorations techniques fondamentales et une simple augmentation des paramètres. Augmenter les paramètres semble séduisant : en faisant des calculs rapides, on peut croire qu’un ordinateur portable peut traiter des milliers de transactions par seconde, sans ZK-SNARK, rollups ou sharding. Malheureusement, cette approche est fondamentalement défectueuse, pour de nombreuses raisons subtiles.
Un ordinateur exécutant un nœud blockchain ne peut pas consacrer 100 % de son CPU à la validation : il lui faut une large marge de sécurité contre les attaques DoS imprévues, et une capacité libre pour traiter d’autres tâches comme celles du mempool. Et les utilisateurs ne veulent pas que leur ordinateur soit ralenti au point d’être inutilisable pour d’autres applications.
La bande passante a aussi ses surcoûts : une connexion de 10 Mo/s ne signifie pas des blocs de 10 Mo chaque seconde, mais plutôt 1 à 5 Mo toutes les 12 secondes, comme pour le stockage. Augmenter les spécifications matérielles ou limiter l’exécution des nœuds à certains participants n’est pas la solution. Pour une blockchain décentralisée, il est crucial que les utilisateurs ordinaires puissent exécuter un nœud et qu’une culture courante de cette pratique existe.
Les améliorations techniques fondamentales fonctionnent. Actuellement, le goulot d’Ethereum est la capacité de stockage. L’étatlessness et l’expiration de l’état peuvent résoudre cela, permettant une augmentation d’environ 3 fois (mais pas 300 fois), car nous souhaitons que l’exécution d’un nœud devienne plus facile qu’aujourd’hui. Les blockchains fragmentées peuvent aller plus loin, car aucun nœud n’a besoin de traiter toutes les transactions.
Mais même là, il y a des limites : avec l’augmentation de la capacité, le nombre minimal de nœuds croît, et le coût de l’archivage (si personne ne le gère, le risque de perte de données augmente) augmente aussi.
Mais nous n’avons pas à trop nous inquiéter : ces limites sont assez hautes pour permettre de traiter plus d’un million de transactions par seconde en toute sécurité. Mais pour y parvenir sans sacrifier la décentralisation, il faudra encore beaucoup d’efforts.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@VitalikButerin
