L'avenir possible d'Ethereum : The Surge

La feuille de route d'Ethereum comprenait initialement deux stratégies d'extensibilité : le sharding et les protocoles Layer 2. À mesure que la recherche avançait, ces deux voies se sont fusionnées pour former une feuille de route centrée sur le Rollup, qui reste la stratégie d'extension actuelle d'Ethereum.

La feuille de route centrée sur Rollup propose une division simple des tâches : Ethereum L1 se concentre sur le fait d'être une couche de base puissante et décentralisée, tandis que L2 prend en charge l'expansion de l'écosystème. Ce modèle est omniprésent dans la société : l'existence du système judiciaire (L1) n'est pas pour poursuivre une ultra-rapidité et une efficacité, 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 pour faire progresser l'humanité.

Cette année, la feuille de route centrée sur les Rollups 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 ont atteint la première phase. Chaque L2 existe comme un "fragment" avec ses propres règles internes et sa logique, et la diversité et la pluralité des méthodes de mise en œuvre des fragments sont désormais une réalité. Mais ce chemin fait également face à des défis uniques. Notre tâche actuelle est de finaliser la feuille de route centrée sur les Rollups et de résoudre ces problèmes, tout en maintenant la robustesse et la décentralisation propres à l'Ethereum L1.

The Surge : Objectifs clés

1. L'avenir d'Ethereum via 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, telles que la confiance, l'ouverture et la résistance à la censure (;
4. Ethereum devrait se sentir comme un écosystème unifié, et non comme 34 blockchains différentes.

Contenu de cet article

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

![Vitalik nouveau texte : L'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-6e846316491095cf7d610acb3b583d06.webp(

Paradoxe du triangle de la scalabilité

Le paradoxe des triangles de la scalabilité affirme qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation, le coût faible des nœuds opérationnels ), la scalabilité ( qui permet de traiter un grand nombre de transactions ) et la sécurité (, où un attaquant doit compromettre une grande partie des nœuds du réseau pour faire échouer une seule transaction ).

Le paradoxe du triangle n'est pas un théorème, il présente un argument mathématique heuristique : si un nœud amical décentralisé peut vérifier N transactions par seconde, et que vous avez une chaîne capable de traiter k*N transactions par seconde, alors (i) chaque transaction ne peut être vue que par 1/k nœuds, ce qui signifie qu'un attaquant n'a besoin de compromettre qu'un petit nombre de nœuds pour effectuer une transaction malveillante, ou (ii) vos nœuds deviendront puissants, tandis que votre chaîne ne sera pas décentralisée.

Depuis des années, certaines chaînes haute performance affirment qu'elles résolvent le trilemme sans changer fondamentalement l'architecture, généralement en utilisant des techniques d'ingénierie logicielle pour optimiser les nœuds. Cela est toujours trompeur, car faire fonctionner des nœuds sur ces chaînes est beaucoup plus difficile que de faire fonctionner des nœuds sur Ethereum.

Cependant, la combinaison de l'échantillonnage de la disponibilité des données et des SNARKs résout effectivement le paradoxe triangulaire : 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, tout en ne téléchargeant qu'une petite quantité de données et en effectuant très peu de calculs. Les SNARKs sont sans confiance. L'échantillonnage de la disponibilité des données a un modèle de confiance subtil de few-of-N, mais il conserve les caractéristiques fondamentales que possède une chaîne non extensible, à savoir qu'une attaque à 51 % ne peut pas forcer les blocs malveillants à être acceptés par le réseau.

Une autre méthode pour résoudre le dilemme des trois est l'architecture Plasma, qui utilise une technique astucieuse pour transférer la responsabilité de la disponibilité des données de surveillance aux utilisateurs de manière compatible avec les incitations. Entre 2017 et 2019, lorsque nous n'avions que la preuve 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 une gamme d'applications plus large que jamais.

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

( Quels problèmes résolvons-nous ?

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 d'environ 375 kB par slot. En supposant que les données de transaction sont publiées directement sur la chaîne, un transfert ERC20 fait environ 180 octets, donc le maximum TPS pour Rollup sur Ethereum est : 375000 / 12 / 180 = 173,6 TPS.

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

C'est une amélioration majeure de l'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é aux améliorations de compression des données Rollup, permettra d'atteindre ~58000 TPS.

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

PeerDAS est une implémentation relativement simple de l'"échantillonnage 1D". Dans Ethereum, chaque blob est un polynôme de degré 4096 dans un champ premier de 253 bits ). Nous diffusons les parts du polynôme, où chaque part contient 16 valeurs d'évaluation à partir de 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs d'évaluation, n'importe quel 4096 ### peut être récupéré en fonction des paramètres proposés actuellement : n'importe quel 64 parmi 128 échantillons possibles (.

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 à d'autres pairs dans le réseau p2p mondial qui écouteront différents sous-réseaux ) de lui fournir 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 interroger la couche des pairs. La proposition actuelle est de permettre aux nœuds participant au proof of stake d'utiliser SubnetDAS, tandis que les autres nœuds (, c'est-à-dire les clients ), utilisent PeerDAS.

Théoriquement, nous pouvons étendre une "échantillonnage 1D" à une taille assez grande : si nous augmentons le nombre maximal de blobs à 256( avec un objectif de 128), alors nous pourrions atteindre l'objectif de 16 Mo, et dans l'échantillonnage de disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * 512 octets par blob et par échantillon = 1 Mo de bande passante de données par slot. Cela est juste à la limite de notre 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.

Ainsi, 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 des blobs, mais aussi entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous élargissons l'ensemble des blobs d'un bloc par un ensemble de nouveaux blobs virtuels, qui codent de manière redondante la même information.

Il est crucial de noter que l'expansion des engagements de calcul ne nécessite pas de blob, donc cette approche est fondamentalement favorable à la construction de blocs distribués. Les nœuds qui construisent réellement les blocs n'ont besoin que de posséder l'engagement KZG du blob, et peuvent s'appuyer 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 pour la construction de blocs distribués.

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

La prochaine étape est la mise en œuvre et le lancement de PeerDAS. Par la suite, 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. En même temps, nous espérons qu'il y aura plus de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leurs interactions avec des questions de sécurité telles que les règles de choix de fork.

À des étapes futures plus éloignées, nous devons faire plus de travail pour déterminer la version idéale du DAS 2D et prouver ses attributs de sécurité. Nous espérons également finalement pouvoir passer de KZG à une alternative sûre contre les menaces quantiques et sans configuration de confiance. Pour l'instant, nous ne savons pas encore quelles solutions candidates sont favorables à la construction de blocs distribués. Même en utilisant la coûteuse technique de "force brute", même en utilisant des STARKs récursifs 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 que techniquement, la taille d'un STARK soit O)log(n) * log(log)n###( valeurs de hachage ( utilisant STIR), en réalité, un 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 en acceptant une limite de données inférieure.
3. Abandonner DA et accepter complètement 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. Cela est dû au fait que si le niveau L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très grands, et les clients souhaiteront avoir un moyen efficace de vérifier leur validité. Par conséquent, nous devrons utiliser des technologies similaires à celles de Rollup( telles que ZK-EVM et DAS( au niveau L1.

) 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. Si le 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 une combinaison avec la proposition de liste d'inclusion de paquets et son mécanisme de sélection de forks environnant.

![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(

Compression de données

) Quels problèmes résolvons-nous ?

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 de disponibilité des données idéal, cela limite l'évolutivité des protocoles de Layer. Chaque slot de 16 Mo, nous obtenons :

16000000 / 12 / 180 = 7407 TPS

Que se passerait-il si nous pouvions non seulement résoudre le problème des numérateurs, mais aussi celui des dénominateurs, permettant ainsi à chaque transaction dans le Rollup d'occuper moins de bytes sur la chaîne?

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

Dans la compression des zéros, nous remplaçons chaque longue séquence de zéros par deux octets, indiquant combien de zéros il y a. De plus, nous avons utilisé des propriétés spécifiques des transactions:

Agrégation de signatures : nous passons de la signature ECDSA à la signature BLS. La caractéristique de la signature BLS est que plusieurs signatures peuvent être combinées en une seule signature, qui peut prouver la validité de toutes les signatures originales. Au niveau L1, il n'est pas envisagé d'utiliser des signatures BLS, car même avec l'agrégation, le coût de calcul de la vérification est relativement élevé. Cependant, dans un environnement L2 où les données sont rares, l'utilisation de signatures BLS a du sens. La fonctionnalité d'agrégation d'ERC-4337 fournit un moyen de réaliser cela.

Remplacer l'adresse par des pointeurs : si une adresse a été utilisée auparavant, nous pouvons remplacer l'adresse de 20 octets par un pointeur de 4 octets pointant vers un emplacement dans l'historique.

Sérialisation personnalisée des valeurs de transaction------La plupart des valeurs de transaction ont peu de chiffres, par exemple, 0,25 ETH est représenté par 250 000 000 000 000 000 wei. Les frais de base maximum et les frais prioritaires sont également similaires. Par conséquent, nous pouvons utiliser un format décimal flottant personnalisé pour représenter la plupart des valeurs monétaires.

) Que faut-il encore faire, quels sont les compromis ?

Ce que nous devons faire ensuite est de mettre en œuvre concrètement le plan ci-dessus. Les principaux compromis incluent :

1. Passer à la signature BLS nécessite beaucoup d'efforts et diminuera la capacité d'améliorer la sécurité.