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 ne vérifier et de stocker qu'une petite partie des transactions, tandis que le Layer2 maintient la plupart des données et des calculs en dehors de la chaîne principale. Ces deux méthodes ont finalement fusionné 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 s'occupe d'aider l'écosystème à s'étendre. Ce modèle est courant dans la société : le système judiciaire (L1) existe pour protéger les contrats et la propriété, tandis que les entrepreneurs (L2) construisent sur cette base.

Cette année, la feuille de route centrée sur Rollup a fait des progrès significatifs : le lancement des blobs EIP-4844 a considérablement augmenté la bande passante des données d'Ethereum L1, et plusieurs Rollups EVM ont atteint la première phase. Chaque L2 existe en tant que "shard" indépendant, et la diversité des méthodes de réalisation des shards est 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 Rollup, de résoudre ces problèmes tout en maintenant la robustesse et la décentralisation d'Ethereum L1.

The Surge : Objectifs clés

1. L'avenir d'Ethereum pourrait 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, comme 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.

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

Paradoxe du triangle de la scalabilité

Le paradoxe de la triangle de la scalabilité soutient qu'il existe une contradiction entre trois caractéristiques de la blockchain : décentralisation, scalabilité et sécurité. Il présente un argument mathématique heuristique : si un nœud amical à la décentralisation peut vérifier N transactions par seconde, et que vous avez une chaîne qui traite 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( vos nœuds deviendront puissants, tandis que votre chaîne ne sera pas décentralisée.

Cependant, la combinaison d'échantillonnage de la disponibilité des données et de 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. Une autre solution est l'architecture Plasma, qui transfère la responsabilité de la surveillance de la disponibilité des données aux utilisateurs. Avec la popularité croissante des SNARKs, l'architecture Plasma devient de plus en plus viable pour des scénarios d'utilisation plus larges.

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

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

Actuellement, chaque slot d'Ethereum toutes les 12 secondes contient 3 blobs d'environ 125 kB, avec une bande passante de données disponible d'environ 375 kB. Supposons que les données de transaction soient publiées directement sur la chaîne, un transfert ERC20 étant d'environ 180 octets, donc le TPS maximal des Rollups sur Ethereum est de 173,6. Notre objectif à moyen terme est de 16 Mo par slot, et si nous combinons cela avec les améliorations de compression des données des Rollups, cela pourrait atteindre environ 58 000 TPS.

PeerDAS est une implémentation relativement simple de "1D sampling". Dans Ethereum, chaque blob est un polynôme de degré 4096 dans un corps de nombres premiers de 253 bits. Nous diffusons les parts du polynôme, où chaque part contient 16 valeurs d'évaluation provenant de 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs d'évaluation, n'importe quel ensemble de 4096 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 aux pairs du réseau p2p mondial les blobs supplémentaires dont il a besoin 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.

En théorie, nous pouvons étendre l'é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, tandis que dans l'échantillonnage de la disponibilité des données, chaque nœud doit traiter 1 Mo de bande passante par slot. Cela est à peine dans notre plage de tolérance, ce qui signifie que les clients à bande passante limitée ne peuvent pas échantillonner.

Ainsi, nous souhaitons finalement aller plus loin et effectuer un échantillonnage 2D, qui se fait non seulement à l'intérieur des blobs, mais aussi entre les blobs de manière aléatoire. Les propriétés linéaires des engagements KZG sont utilisées pour étendre un ensemble de blobs dans un bloc, qui contient une nouvelle liste de blobs virtuels codés de manière redondante sur les mêmes informations.

Il est crucial de noter que l'extension des engagements de calcul ne nécessite pas de blob, donc cette solution est fondamentalement conviviale pour la construction de blocs distribués. Les nœuds qui construisent réellement le bloc n'ont besoin de posséder que 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.

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

Ensuite, il s'agit de finaliser l'implémentation et le lancement de PeerDAS. Par la suite, augmenter 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é, c'est un processus progressif. Nous espérons également avoir davantage de travaux académiques pour normaliser PeerDAS et d'autres versions de DAS ainsi que leurs interactions avec des questions de sécurité telles que les règles de sélection de forks.

À un stade futur plus éloigné, nous devrons 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 pouvoir finalement passer de KZG à une alternative quantiquement sécurisée et sans configuration de confiance.

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 plus basse.
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 directement l'exécution 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 volumineux, et les clients souhaiteront avoir un moyen efficace de vérifier leur validité. Par conséquent, nous devrons utiliser au niveau L1 les mêmes technologies que celles des Rollup) telles que ZK-EVM et DAS(.

![Vitalik nouvel article : futur possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(

Compression de données

Chaque transaction dans un Rollup occupera 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 de disponibilité des données idéal, cela limite l'évolutivité des protocoles de couche. Chaque slot étant 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 molécules, mais aussi résoudre le problème des dénominateurs, permettant ainsi à chaque transaction dans le Rollup d'occuper moins d'octets sur la chaîne ?

Il existe plusieurs méthodes de compression des données :

• Compression zéro octet : remplace chaque longue séquence de zéros par deux octets, indiquant combien de zéros sont présents.

• Agrégation de signatures : Passer 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, laquelle peut prouver la validité de toutes les signatures originales.

• Remplacer les adresses par des pointeurs : Si une adresse a déjà été utilisée, 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 Ethereum 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.

• Différences de l'état des Rollups basé sur la preuve de validité plutôt que sur les transactions.

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

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

1. Passer à la signature BLS nécessite un grand effort et réduira la compatibilité avec les puces matérielles de confiance qui peuvent améliorer la sécurité. On peut utiliser des emballages ZK-SNARK d'autres schémas de signature comme alternative.

2. Compression dynamique ) Par exemple, remplacer les adresses par des pointeurs ( rendra le code client plus complexe.

3. Publier les différences d'état sur la chaîne plutôt que dans les transactions réduira l'auditabilité et rendra de nombreux logiciels ), tels que les explorateurs de blocs (, inopérants.

L'adoption de l'ERC-4337 et l'intégration de certaines de ses fonctionnalités dans l'EVM de niveau 2 peuvent considérablement accélérer le déploiement des technologies d'agrégation. Placer certaines fonctionnalités de l'ERC-4337 sur le niveau 1 peut accélérer son déploiement sur le niveau 2.

![Vitalik nouveau document : l'avenir potentiel de l'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp(

Plasma généralisé

Même avec un blob de 16 Mo et la compression des données, 58 000 TPS ne suffisent pas forcément à satisfaire complètement les besoins des paiements des consommateurs, des réseaux sociaux décentralisés ou d'autres domaines à forte bande passante, surtout lorsque nous commençons à prendre en compte les facteurs de confidentialité, ce qui pourrait réduire la scalabilité de 3 à 8 fois. Pour les scénarios d'application à fort volume de transactions et à faible valeur, l'une des options actuellement disponibles est d'utiliser Validium, qui conserve les données hors chaîne et adopte un modèle de sécurité intéressant : les opérateurs ne peuvent pas voler les fonds des utilisateurs, mais ils peuvent temporairement ou définitivement geler tous les fonds des utilisateurs. Mais nous pouvons faire mieux.

Plasma est une solution d'extensibilité, impliquant un opérateur qui publie des blocs hors chaîne, et place la racine Merkle de ces blocs sur la chaîne ). Contrairement aux Rollups, les Rollups placent des blocs complets sur la chaîne (. Pour chaque bloc, l'opérateur envoie un chemin Merkle à chaque utilisateur pour prouver quels changements ont eu lieu concernant les actifs de l'utilisateur, ou s'il n'y a eu aucun changement. Les utilisateurs peuvent retirer leurs actifs en fournissant le chemin Merkle. Il est important que ce chemin n'ait pas nécessairement la dernière version comme racine. Ainsi, même si des problèmes de disponibilité des données surviennent, les utilisateurs peuvent toujours récupérer leurs actifs en extrayant leur dernier état disponible. Si un utilisateur soumet un chemin invalide ), par exemple, pour retirer des actifs qu'il a déjà envoyés à d'autres, ou si l'opérateur a lui-même créé un actif de toutes pièces (, la légitimité de la propriété de l'actif peut être déterminée par le mécanisme de défi sur la chaîne.

Les premières versions de Plasma ne pouvaient traiter que des cas d'utilisation de paiement, et ne pouvaient pas être efficacement étendues. Cependant, si nous exigeons que chaque racine soit vérifiée par SNARK, alors Plasma deviendrait beaucoup plus puissant. Chaque jeu de défi peut être grandement simplifié, car nous excluons la plupart des chemins possibles de tricherie des opérateurs. En même temps, cela ouvre de nouvelles voies, permettant à la technologie Plasma de s'étendre à une plus large gamme de catégories d'actifs. Enfin, dans le cas où les opérateurs ne trichent pas, les utilisateurs peuvent retirer immédiatement des fonds, sans avoir à attendre une période de contestation d'une semaine.

Une idée clé est que le système Plasma n'a pas besoin d'être parfait. Même si vous ne pouvez protéger qu'un sous-ensemble d'actifs ), par exemple, uniquement des jetons qui n'ont pas été déplacés au cours de la dernière semaine (, vous avez déjà considérablement amélioré l'état actuel de l'EVM super extensible ), à savoir Validium (.

Une autre catégorie de structures est le Plasma/Rollup hybride, comme Intmax. Ces constructions placent une très petite quantité de données de chaque utilisateur sur la chaîne ), par exemple, 5 octets (. Cela permet d'obtenir certaines caractéristiques situées entre Plasma et Rollup : dans le cas d'Intmax, vous pouvez obtenir une évolutivité et une confidentialité très élevées, bien que même avec une capacité de 16 Mo, cela soit théoriquement limité à environ 16.