L'avenir potentiel d'Ethereum : The Surge

La feuille de route d'Ethereum comprenait initialement deux stratégies d'extension : le sharding et les protocoles Layer2. Le sharding permet à chaque nœud de vérifier et de stocker seulement une petite partie des transactions, tandis que les protocoles Layer2 construisent des réseaux au-dessus d'Ethereum, en tirant parti de sa sécurité tout en conservant la majorité des données et des calculs en dehors de la chaîne principale. Au fur et à mesure que la recherche avançait, ces deux voies ont finalement fusionné pour former une feuille de route centrée sur les Rollups, qui reste jusqu'à ce jour la stratégie d'extension 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 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 destinée à poursuivre une ultra-rapidité et une haute efficacité, mais à 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 avancer l'humanité.

Cette année, la feuille de route centrée sur Rollup a obtenu des résultats significatifs : avec le lancement des blobs EIP-4844, la bande passante des données de l'Ethereum L1 a considérablement augmenté, plusieurs Rollup de la machine virtuelle Ethereum (EVM) ont atteint la première phase. Chaque L2 existe comme un "fragment" avec ses propres règles et logiques internes, 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 à certains défis uniques. Par conséquent, 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 propres à Ethereum L1.

The Surge: Objectif clé

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 ( de confiance, ouvertes, résistantes à la censure ) ;

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

Ce chapitre contient

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élioration de l'interopérabilité entre 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é ( un grand nombre de transactions traitées ) 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 publications qui présentent le paradoxe du triangle n'incluent pas de preuve mathématique. Il fournit en effet 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 que quelques nœuds pour réaliser une transaction malveillante, ou (ii) vos nœuds deviendront puissants, 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 briser le paradoxe ternaire, et cela nécessite dans une certaine mesure de sortir du cadre de pensée implicite de cet argument.

Depuis des années, certaines chaînes haute performance prétendent avoir résolu 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 exécuter un nœud sur ces chaînes est bien plus difficile que d'exécuter un nœud 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 d'échantillonnage de disponibilité des données et de SNARKs résout en effet 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 disponibilité des données présente un modèle de confiance subtil 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 un bloc invalide à être accepté par le réseau.

Une autre approche pour résoudre le trilemme est l'architecture Plasma, qui utilise des techniques astucieuses pour transférer la responsabilité de la disponibilité des données surveillées aux utilisateurs de manière incitative et compatible. 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 termes d'exécution sécurisée. Cependant, avec la popularité des SNARKs(, des preuves non interactives succinctes à connaissance nulle), l'architecture Plasma est devenue plus viable pour un éventail d'applications plus large que jamais.

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

Quel problème 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 d'environ 375 kB par slot. Si les données de transaction sont publiées directement sur la chaîne, un transfert ERC20 fait environ 180 octets, donc le TPS maximum pour le Rollup 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 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é à l'amélioration de la compression des données Rollup, apportera environ 58000 TPS.

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

PeerDAS est une mise en œuvre 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, où chaque part contient 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 4096 ) peut être récupéré selon les paramètres proposés actuellement : n'importe quel 64 des 128 échantillons possibles (.

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

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 en interrogeant les pairs dans le réseau p2p mondial ) pour savoir qui écoutera différents sous-réseaux ( afin de demander 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 de pairs supplémentaire. La proposition actuelle est de faire en sorte que les nœuds participant à la preuve de participation 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 grand : si nous augmentons le nombre maximal de blobs à 256) avec un objectif de 128(, alors nous pouvons atteindre l'objectif de 16 Mo, et avec un échantillonnage de disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * 512 octets par blob par échantillon = une bande passante de données de 1 Mo par slot. Cela se situe juste 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 rendra le coût de reconstruction plus élevé.

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 du blob, mais également entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous pouvons étendre l'ensemble des blobs dans un bloc par un ensemble de nouveaux blobs virtuels, ces blobs virtuels codant redondamment la même information.

Ainsi, finalement, nous souhaitons aller plus loin et effectuer un échantillonnage 2D, qui ne se limite pas à l'intérieur des blobs, mais également à un échantillonnage aléatoire entre les blobs. La propriété linéaire de l'engagement 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 des mêmes informations.

Il est crucial de noter que l'expansion 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 les blocs n'ont besoin que de posséder l'engagement KZG du blob, 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 unidimensionnel )1D DAS( est également fondamentalement amical pour la construction de blocs distribués.

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

Ensuite, il s'agit de finaliser 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 garantir la sécurité, ce qui est un processus progressif. Dans le 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 problèmes de sécurité liés aux règles de sélection des forks.

À des stades encore plus avancés dans le futur, nous devrons 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 sûre contre les quantiques et sans configuration de confiance. Pour l'instant, nous ne savons pas encore quelles solutions candidates sont amicales pour la construction de blocs distribués. Même en utilisant des techniques "brute force" coûteuses, 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 suffira pas à répondre à la demande, 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éaliste à long terme est :

1. Mettre en œuvre un DAS 2D idéal;
2. Insister sur l'utilisation de 1D DAS, sacrifiant l'efficacité de la bande passante d'échantillonnage, pour accepter une limite de données inférieure pour la simplicité et la robustesse.
3. Abandonner DA et accepter complètement Plasma comme notre principale architecture Layer2 d'intérêt.

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 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 vérifier leur validité. Par conséquent, nous devrons utiliser des technologies similaires à Rollup) comme 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 au 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 favorable à la reconstruction distribuée, cela nécessite en pratique d'être combiné avec la proposition de liste d'inclusion des paquets et son mécanisme de choix de fourche autour.

( 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 : le 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 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, 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]###https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp###

Dans la compression des zéros, chaque longue séquence de zéros est remplacée par deux octets, indiquant combien de zéros il y a. De plus, nous avons tiré parti des propriétés spécifiques des transactions :

Agrégation de signatures : nous passons de la signature ECDSA à la signature BLS