L'avenir possible 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é, formant une feuille de route centrée sur les Rollups, qui reste la stratégie d'extension actuelle d'Ethereum.

La feuille de route axée sur les Rollups 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 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) est destinée à protéger les contrats et la propriété, tandis que les entrepreneurs (L2) construisent sur cette couche de base solide pour faire avancer l'humanité.

Cette année, la feuille de route centrée sur les Rollups a réalisé des avancées significatives : avec le lancement des blobs EIP-4844, la bande passante de 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 "shard" avec ses propres règles internes et sa logique, et la diversité et la pluralité des méthodes de mise en œuvre des shards sont désormais une réalité. Mais comme nous l'avons constaté, suivre cette voie comporte également des défis uniques. Ainsi, 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 pourra atteindre plus de 100 000 TPS grâce à L2;

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 la confiance, de l'ouverture et de la 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 de données
4. Plasma généralisé
5. Système de preuve L2 mature
6. Amélioration de l'interopérabilité inter-L2
7. Étendre l'exécution sur L1

paradoxe du 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é (, c'est-à-dire 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 est important de noter que le paradoxe du triangle n'est pas un théorème, et les publications introduisant le paradoxe du triangle ne sont pas accompagnées de preuves mathématiques. Il présente effectivement un argument mathématique heuristique : si un nœud amical décentralisé (, 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 (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 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 qu'il est difficile de le briser, nécessitant d'une certaine manière de sortir du cadre de pensée implicite dans cet argument.

Depuis de nombreuses années, certaines chaînes haute performance prétendent résoudre le trilemme de manière fondamentale sans changer leur architecture, généralement en appliquant 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 sur Ethereum. Cet article explorera pourquoi c'est le cas et pourquoi l'ingénierie logicielle des clients 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'une certaine quantité de données est disponible 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 type few-of-N, mais il conserve les caractéristiques fondamentales d'une chaîne non extensible, à savoir qu'une attaque à 51 % ne peut pas forcer l'acceptation de blocs défectueux par le réseau.

Une autre méthode pour résoudre le dilemme des trois façons est l'architecture Plasma, qui utilise une technologie astucieuse pour transférer la responsabilité de la disponibilité des données de surveillance aux utilisateurs d'une manière compatible avec les incitations. Entre 2017 et 2019, lorsque nous ne disposions que de 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 succinctes non interactives à connaissance nulle), l'architecture Plasma est devenue beaucoup plus viable pour des scénarios d'utilisation plus larges qu'auparavant.

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, soit une bande passante de données utilisable d'environ 375 kB par slot. Supposons que les données de transaction soient publiées directement sur la chaîne, un transfert ERC20 faisant environ 180 octets, donc le TPS maximum du Rollup sur Ethereum est : 375000 / 12 / 180 = 173,6 TPS.

Si nous ajoutons la valeur maximale théorique des 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 fournirait 463-926 TPS pour les calldata.

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

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

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

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 à des pairs dans le réseau p2p mondial ) qui écoutera différents sous-réseaux ( pour obtenir d'autres blobs nécessaires sur ces 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 permettre aux nœuds participant à la preuve d'enjeu d'utiliser SubnetDAS, tandis que les autres nœuds ), c'est-à-dire les clients (, utilisent PeerDAS.

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

Ainsi, nous souhaitons aller plus loin en procédant à un échantillonnage 2D )2D sampling(. Cette méthode effectue non seulement des échantillonnages aléatoires au sein du blob, mais également entre les blobs. En utilisant les propriétés linéaires de l'engagement KZG, nous étendons l'ensemble des blobs d'un bloc avec un ensemble de nouveaux blobs virtuels qui codent redondamment les mêmes informations.

Ainsi, finalement, nous voulons aller plus loin et effectuer un échantillonnage 2D, qui se fait non seulement à l'intérieur des blobs, mais également entre les blobs. La propriété linéaire de l'engagement KZG est utilisée pour étendre un ensemble de blobs dans un bloc, contenant une nouvelle liste de blobs virtuels redondamment codés pour les mêmes informations.

Il est essentiel que l'extension des engagements de calcul ne nécessite pas de blob, donc cette solution est fondamentalement amicale pour la construction de blocs distribués. Les nœuds qui construisent réellement des blocs n'ont besoin que de posséder l'engagement blob KZG, et ils 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 unidimensionnelles )1D DAS( est également fondamentalement amical pour la construction de blocs distribués.

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

)# Que faut-il faire d'autre ? Quels sont les compromis ?

La prochaine étape est de terminer la mise en œuvre et le lancement de PeerDAS. Ensuite, nous augmenterons continuellement le nombre de blobs sur PeerDAS, tout en surveillant attentivement le réseau et en améliorant le logiciel pour assurer la sécurité, ce qui est un processus progressif. En même temps, nous espérons avoir plus de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leurs interactions avec la sécurité des règles de sélection de fork.

À des étapes plus éloignées dans le futur, nous devrons faire davantage de travail pour déterminer la version idéale du DAS 2D et prouver ses propriétés de sécurité. Nous espérons également pouvoir finalement passer de KZG à une alternative qui soit sécurisée quantiquement et ne nécessite pas de 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 coûteuse technique de "force brute", c'est-à-dire en utilisant des STARK récursifs pour générer des preuves de validité pour la reconstruction des lignes et des colonnes, cela ne suffit pas à répondre aux besoins, car bien que techniquement, la taille d'un STARK soit O(log)n### * log(log(n)( hachage ( utilisant STIR), en réalité, le STARK est presque aussi grand que l'ensemble du blob.

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

1. Mettre en œuvre un DAS 2D idéal;
2. Continuer à utiliser 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 sur la couche L1, cette option existe. En effet, si la couche 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 en vérifier l'exactitude, c'est pourquoi nous devrons utiliser sur la couche 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 diminuera, ou du moins sera 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 sélection de forks associé.

compression de données

(# Quel problème résolvons-nous ?

Chaque transaction dans un Rollup occupe une grande quantité 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 Layer. Chaque slot fait 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 à chaque transaction dans un Rollup d'occuper 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 :

Dans la compression des zéros, chaque longue séquence de zéros est remplacée par deux octets, représentant le nombre d'octets zéro. De plus, nous avons utilisé certaines 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, en raison du coût de calcul élevé de la vérification même en cas d'agrégation, l'utilisation de la signature BLS n'est pas envisagée. Mais dans un environnement L2 où les données sont rares, l'utilisation de la signature BLS a du sens. La fonctionnalité d'agrégation de l'ERC-4337 offre une voie pour réaliser cette fonctionnalité.

Utilisez des pointeurs pour remplacer les adresses : Si en