L'avenir d'Ethereum : The Surge

La feuille de route d'Ethereum comprenait initialement deux stratégies d'extension : le sharding et les protocoles Layer 2. Ces deux voies ont finalement fusionné pour former une feuille de route centrée sur les Rollups, qui demeure la stratégie d'extension actuelle d'Ethereum.

La feuille de route centrée sur Rollup propose une division simple : Ethereum L1 se concentre sur le fait de devenir une couche de base puissante et décentralisée, tandis que L2 assume la tâche d'aider l'écosystème à s'étendre. Ce modèle est omniprésent dans la société : l'existence du système judiciaire (L1) n'est pas pour poursuivre une hyper vitesse et une efficacité élevée, mais pour protéger les contrats et les droits de propriété, tandis que les entrepreneurs (L2) doivent construire sur cette couche de base solide, menant l'humanité vers Mars.

Cette année, la feuille de route centrée sur Rollup a réalisé des résultats importants : avec le lancement des blobs EIP-4844, la bande passante des données de l'Ethereum L1 a considérablement augmenté, et plusieurs machines virtuelles Ethereum ( EVM ) Rollup sont entrées dans la première phase. Chaque L2 existe en tant que "fragment" avec ses propres règles et logiques internes, et la diversité et la pluralité des façons de réaliser ces fragments sont désormais une réalité. Mais comme nous l'avons vu, emprunter cette voie présente également des défis uniques. Ainsi, notre tâche actuelle est de finaliser la feuille de route centrée sur Rollup et de résoudre ces problèmes, tout en maintenant la robustesse et la décentralisation qui sont propres à l'Ethereum L1.

The Surge: Objectifs clés

1. L'avenir d'Ethereum grâce aux L2 peut atteindre plus de 100 000 TPS;

2. Maintenir la décentralisation et la robustesse de L1;

3. Au moins certains L2 héritent complètement des propriétés fondamentales d'Ethereum ( de non-confiance, d'ouverture, et de résistance à la censure );

4. Ethereum devrait se sentir comme un écosystème unifié, et non comme 34 blockchains différentes.

Contenu de ce chapitre

1. Paradoxe du triangle de la scalabilité
2. Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
3. Compression des données
4. Plasma généralisé
5. Système de preuve L2 mature
6. Améliorations de l'interopérabilité inter-L2
7. Étendre l'exécution sur L1

Paradoxe de la triangle de la scalabilité

Le paradoxe de la triangle de la scalabilité est une idée proposée en 2017, qui soutient qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation (, plus précisément : le coût d'exécution des nœuds est faible ), la scalabilité (, le nombre de transactions traitées est élevé ) et la sécurité (, les attaquants doivent compromettre une grande partie des nœuds du réseau pour faire échouer une seule transaction ).

Il convient de noter que le paradoxe du triangle n'est pas un théorème, et les articles présentant le paradoxe du triangle ne sont pas accompagnés de preuves mathématiques. Il fournit en effet un argument mathématique heuristique : si un nœud décentralisé amical (, par exemple un ordinateur portable grand public ), peut vérifier N transactions par seconde, et que vous avez une chaîne capable de traiter k*N transactions par seconde, alors chaque transaction (i) ne peut être vue que par 1/k des nœuds, ce qui signifie qu'un attaquant n'a qu'à compromettre quelques nœuds pour réaliser une transaction malveillante, ou (ii) votre nœud deviendra puissant, tandis que votre chaîne ne sera pas décentralisée. L'objectif de cet article n'est pas de prouver qu'il est impossible de briser le paradoxe du triangle ; au contraire, il vise à montrer que briser le paradoxe ternaire est difficile et qu'il faut, dans une certaine mesure, sortir du cadre de pensée implicite de cet argument.

Depuis de nombreuses années, certaines chaînes à haute performance prétendent avoir résolu le trilemme sans modifier fondamentalement l'architecture, généralement en appliquant des techniques d'ingénierie logicielle pour optimiser les nœuds. Cela est toujours trompeur, car faire fonctionner un nœud sur ces chaînes est beaucoup plus difficile que sur Ethereum. Cet article explorera pourquoi cela est le cas, et pourquoi l'ingénierie logicielle du client L1 à elle seule ne peut pas faire évoluer Ethereum.

Cependant, la combinaison de l'échantillonnage de la disponibilité des données et des SNARKs résout effectivement le paradoxe du triangle : elle permet aux clients de vérifier qu'un certain nombre de données sont disponibles et qu'un certain nombre d'étapes de calcul sont correctement exécutées, en ne téléchargeant qu'une petite quantité de données et en effectuant un nombre minimal de calculs. Les SNARKs sont sans confiance. L'échantillonnage de la disponibilité des données a un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales des chaînes qui ne peuvent pas être mises à l'échelle, à savoir que même une attaque à 51 % ne peut pas forcer de mauvais blocs à être acceptés par le réseau.

Une autre méthode pour résoudre le trilemme est l'architecture Plasma, qui utilise une technologie astucieuse pour transférer la responsabilité de la disponibilité des données à l'utilisateur de manière incitative et compatible. Entre 2017 et 2019, lorsque nous n'avions que les preuves de fraude comme moyen d'étendre la capacité de calcul, Plasma était très limité en matière d'exécution sécurisée, mais avec la popularité des SNARKs( et des preuves zéro connaissance succinctes non interactives), l'architecture Plasma est devenue plus viable pour des cas d'utilisation plus larges que jamais.

Progrès supplémentaire sur l'échantillonnage de la disponibilité des données

Quelles problèmes sommes-nous en train de résoudre ?

Le 13 mars 2024, lorsque la mise à niveau Dencun sera en ligne, la blockchain Ethereum aura 3 blobs d'environ 125 kB par slot toutes les 12 secondes, ou une bande passante de données disponible d'environ 375 kB par slot. Supposons que les données de transaction soient publiées directement sur la chaîne, alors un transfert ERC20 fait environ 180 octets, donc le TPS maximal des Rollups sur Ethereum est : 375000 / 12 / 180 = 173,6 TPS.

Si nous ajoutons la valeur maximale théorique de calldata d'Ethereum ( : chaque slot 30 millions de Gas / par octet 16 gas = chaque slot 1 875 000 octets ), cela devient 607 TPS. En utilisant PeerDAS, le nombre de blobs pourrait augmenter à 8-16, ce qui fournirait 463-926 TPS pour le calldata.

C'est une amélioration majeure pour Ethereum L1, mais ce n'est pas suffisant. Nous voulons plus de scalabilité. Notre objectif à moyen terme est de 16 Mo par slot, ce qui, combiné à l'amélioration de la compression des données Rollup, apportera ~58000 TPS.

Qu'est-ce que c'est ? Comment ça fonctionne ?

PeerDAS est une implémentation relativement simple de "1D sampling". Dans Ethereum, chaque blob est un polynôme de degré 4096 sur le champ premier 253 bits (. Nous diffusons les parts du polynôme, chaque part contenant 16 évaluations à partir de 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 évaluations, n'importe quel ensemble de 4096 ) peut être récupéré selon les paramètres proposés : n'importe quel 64 parmi 128 échantillons possibles ( peut restaurer le blob.

![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])lab.com/yijian/2024/10/17/images/5be9d7b18dd5154d181bd4c34ad8a3c4.jpg(

Le fonctionnement de PeerDAS consiste à faire en sorte que chaque client écoute un petit nombre de sous-réseaux, où le ième sous-réseau diffuse le ième échantillon de tout blob, et demande aux pairs dans le réseau p2p mondial ) qui écoutera les différents sous-réseaux ( pour obtenir les blobs nécessaires sur d'autres sous-réseaux. Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme de sous-réseau, sans requêtes supplémentaires au niveau des pairs. La proposition actuelle est de faire en sorte que les nœuds participant à la preuve d'enjeu utilisent SubnetDAS, tandis que les autres nœuds ), c'est-à-dire les clients (, utilisent PeerDAS.

En théorie, nous pouvons étendre l'échelle d'un "échantillonnage 1D" assez largement : si nous augmentons le nombre maximal de blobs à 256) avec un objectif de 128(, alors nous pouvons atteindre un objectif de 16 Mo, où chaque nœud dans l'échantillonnage de disponibilité des données a 16 échantillons * 128 blobs * 512 octets par blob et par échantillon = 1 Mo de bande passante de données par slot. Cela reste juste dans notre limite de tolérance : c'est faisable, mais cela signifie que les clients à bande passante limitée ne peuvent pas échantillonner. Nous pouvons optimiser cela dans une certaine mesure en réduisant le nombre de blobs et en augmentant la taille des blobs, mais cela augmentera le coût de reconstruction.

Par conséquent, nous voulons finalement aller plus loin et effectuer un échantillonnage 2D)2D sampling(, cette méthode effectue non seulement un échantillonnage aléatoire à l'intérieur du blob, mais aussi entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous étendons l'ensemble de blobs dans un bloc par un ensemble de nouveaux blobs virtuels qui codent de manière redondante les mêmes informations.

Ainsi, finalement, nous souhaitons aller plus loin et effectuer un échantillonnage 2D, qui effectue un échantillonnage aléatoire non seulement à l'intérieur des blobs, mais aussi entre les blobs. La propriété linéaire des engagements KZG est utilisée pour étendre un ensemble de blobs dans un bloc, qui contient une nouvelle liste de blobs virtuels avec un codage redondant de la même information.

Il est crucial de noter que l'expansion des engagements de calcul ne nécessite pas de blob, donc ce schéma est fondamentalement amical envers la construction de blocs distribués. Les nœuds qui construisent réellement les blocs n'ont besoin que de l'engagement KZG de blob, et ils peuvent compter sur l'échantillonnage de disponibilité des données )DAS( pour vérifier la disponibilité des blocs de données. L'échantillonnage de disponibilité des données unidimensionnel )1D DAS( est également fondamentalement amical envers la construction de blocs distribués.

) Que faut-il encore faire ? Quelles sont les considérations ?

La prochaine étape consiste à finaliser l'implémentation et le lancement de PeerDAS. Ensuite, nous augmenterons progressivement le nombre de blobs sur PeerDAS tout en surveillant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité, ce qui est un processus progressif. Parallèlement, nous espérons qu'il y aura davantage de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leur interaction avec des questions de sécurité telles que les règles de choix de fork.

À un stade futur plus éloigné, nous devons faire davantage de travail pour déterminer la version idéale de 2D DAS et prouver ses propriétés de sécurité. Nous espérons également pouvoir finalement passer de KZG à une alternative quantiquement sécurisée et sans configuration de confiance. Actuellement, nous ne savons pas encore quelles options candidates sont favorables à la construction de blocs distribués. Même en utilisant la technologie coûteuse de "force brute", c'est-à-dire en utilisant STARK récursif pour générer des preuves de validité pour reconstruire les lignes et les colonnes, cela ne suffit pas à répondre à la demande, car bien qu'en théorie, la taille d'un STARK soit O(log)n### * log(log(n)( hash ( utilisant STIR), en pratique, le STARK est presque aussi grand que l'ensemble du blob.

Je pense que le chemin de réalité à long terme est :

1. Mettre en œuvre un DAS 2D idéal;
2. Maintenir l'utilisation de 1D DAS, sacrifiant l'efficacité de la bande passante d'échantillonnage, pour la simplicité et la robustesse tout en acceptant une limite de données inférieure.
3. Abandonner DA et accepter entièrement Plasma comme notre principale architecture Layer2.

Veuillez noter que même si nous décidons d'étendre l'exécution directement au niveau L1, cette option existe également. Cela est dû au fait que si le niveau L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux, et les clients souhaiteront avoir une méthode efficace pour vérifier leur validité. Par conséquent, nous devrons utiliser au niveau L1 des technologies similaires à celles de Rollup) comme ZK-EVM et DAS(.

) Comment interagir avec les autres parties de la feuille de route ?

Si la compression des données est réalisée, la demande pour le DAS 2D sera réduite, ou du moins retardée, et si Plasma est largement utilisé, la demande diminuera encore davantage. Le DAS pose également des défis aux protocoles et mécanismes de construction de blocs distribués : bien que le DAS soit théoriquement amical pour la reconstruction distribuée, cela nécessite en pratique d'être combiné avec la proposition de liste d'inclusion de paquets et son mécanisme de choix de fork associé.

Compression de données

( Quels problèmes essayons-nous de résoudre ?

Chaque transaction dans un Rollup occupe beaucoup d'espace de données sur la chaîne : un transfert ERC20 nécessite environ 180 octets. Même avec un échantillonnage idéal de la disponibilité des données, cela limite l'évolutivité des protocoles de couche. Chaque slot fait 16 Mo, nous obtenons :

16000000 / 12 / 180 = 7407 TPS

Que se passerait-il si nous pouvions non seulement résoudre les problèmes des molécules, mais aussi ceux des dénominateurs, afin que chaque transaction dans un Rollup occupe moins de bytes sur la chaîne ?

Qu'est-ce que c'est, comment ça fonctionne ?

À mon avis, la meilleure explication est cette image d'il y a deux ans :

![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])