Nouveau message de Vitalik : L'avenir possible de l'Éther, The Surge

Auteur : Vitalik Buterin

Compilation: Karen, Foresight News

Remerciements spéciaux à Justin Drake, Francesco, Hsiao-wei Wang, @antonttc et Georgios Konstantopoulos.

Au début, le plan de croissance d’Éther impliquait deux stratégies de mise à l’échelle. L’une (voir un document de recherche précoce de 2015) était le « Sharding » : chaque Nœud ne doit valider et stocker qu’une petite partie des transactions, au lieu de valider et stocker toutes les transactions de la chaîne. Tout autre réseau peer-to-peer (comme BitTorrent) fonctionne de la même manière, donc nous pouvons bien sûr faire fonctionner la blockchain de la même manière. L’autre stratégie est le protocole Layer2 : ces réseaux se situeront au-dessus d’Éther, lui permettant de bénéficier pleinement de sa sécurité tout en conservant la majeure partie des données et des calculs hors mainchain. Le protocole Layer2 fait référence aux canaux d’état de 2015, au Plasma de 2017, puis au Rollup de 2019. Le Rollup est plus puissant que les canaux d’état ou le Plasma, mais nécessite une bande passante importante pour les données hors chaîne. Heureusement, d’ici 2019, la recherche sur le Sharding a résolu le problème de la « disponibilité des données » pour la validation à grande échelle. En conséquence, ces deux voies se sont fusionnées pour donner un plan centré sur le Rollup, qui reste la stratégie d’expansion d’Éther aujourd’hui.

The Surge，2023 Roadmap Edition

Le plan centré sur Rollup propose une division simple : Ethereum L1 se concentre sur la création d’une couche de base puissante et décentralisée, tandis que L2 prend en charge l’extension de l’écosystème. Ce modèle est omniprésent dans la société : la présence du système judiciaire (L1) ne vise pas la vitesse et l’efficacité extrêmes, mais la protection des contrats et des droits de propriété, tandis que les entrepreneurs (L2) construisent sur cette base solide pour mener l’humanité vers Mars, que ce soit littéralement ou métaphoriquement.

Cette année, la feuille de route centrée sur Rollup a obtenu des résultats importants : avec le déploiement de EIP-4844 blobs, la bande passante des données de la couche L1 d’ETH a considérablement augmenté, et plusieurs Rollups EVM (Machine virtuelle Ethereum) sont entrés dans la première phase. Chaque L2 existe en tant qu’entité ‘Sharding’ avec ses propres règles et logiques internes, et la diversité et la pluralité des méthodes de mise en œuvre du Sharding sont devenues une réalité. Cependant, comme nous pouvons le constater, cette voie présente également des défis uniques. Par conséquent, notre tâche actuelle est de finaliser la feuille de route centrée sur Rollup, de résoudre ces problèmes, tout en préservant la robustesse et la décentralisation spécifiques à la couche L1 d’ETH.

The Surge: Objectif clé

1、Dans le futur, Ethereum pourra atteindre plus de 100 000 TPS via L2.

2. Maintenir la Décentralisation et la Robustesse de L1 ;

3, Au moins certains L2 héritent complètement des propriétés essentielles d’Ethereum (Trustless, ouvert, résistant à la censure) ;

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

Ce chapitre

1. Le paradoxe de la scalabilité triangulaire
2. Avancements supplémentaires de l’échantillonnage de 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é L2
7. Étendre l’exécution sur L1

Le paradoxe du triangle de scalabilité

Le paradoxe du triangle de la scalabilité est une idée proposée en 2017, qui soutient qu’il existe une contradiction entre les trois caractéristiques de la blockchain : Décentralisation (plus précisément, un coût bas pour l’exécution des Nœuds), scalabilité (traiter un grand nombre de transactions) et sécurité (un attaquant doit compromettre une grande partie des Nœuds du réseau pour faire échouer une transaction unique).

Il est à noter que le paradoxe du triangle n’est pas un théorème et aucun message introduisant le paradoxe du triangle n’est accompagné d’une preuve mathématique. Il présente en effet un argument mathématique heuristique : si un nœud amical à la Décentralisation (comme 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œud, ce qui signifie qu’un attaquant n’a besoin de compromettre qu’un petit nombre de nœuds pour passer une transaction malveillante, ou (ii) vos nœuds deviendront puissants, mais votre chaîne ne sera pas Décentralisation. Le but 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 du triangle est difficile, et cela nécessite dans une certaine mesure de sortir du cadre de pensée implicite de cet argument.

Pendant des années, certains réseaux à haute performance ont souvent prétendu avoir résolu le paradoxe tripartite sans changer fondamentalement l’architecture, généralement en optimisant les nœuds grâce à des techniques d’ingénierie logicielle. Cela est toujours trompeur, car exécuter des nœuds off-chain est bien plus difficile que sur Ethereum. Cet article explorera pourquoi c’est le cas et pourquoi l’ingénierie logicielle des clients L1 seule ne peut pas étendre Ethereum.

Cependant, la combinaison de l’échantillonnage de disponibilité des données avec les SNARKs résout effectivement la contradiction 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 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 few-of-N subtil, mais conserve les caractéristiques fondamentales de la chaîne non scalable, c’est-à-dire que même une attaque de 51% ne peut pas imposer que des blocs corrompus soient acceptés par le réseau.

Une autre méthode pour résoudre le dilemme des trois difficultés est l’architecture Plasma, qui utilise des technologies ingénieuses pour déléguer la responsabilité de la disponibilité des données de surveillance de manière incitative et compatible aux utilisateurs. Entre 2017 et 2019, lorsque nous n’avions que le moyen de fraude proof pour étendre les capacités de calcul, Plasma était très limité en termes d’exécution sécurisée, mais avec la popularisation des SNARKs (preuves succinctes non interactives de connaissance zéro), l’architecture Plasma est devenue plus viable pour des cas d’utilisation plus étendus qu’auparavant.

Des progrès supplémentaires dans l’échantillonnage de la disponibilité des données

Quel problème sommes-nous en train de résoudre ?

Le 13 mars 2024, lorsque Dencun sera mis à niveau et en ligne, chaque slot de la blockchain Ethereum aura environ 3 blobs d’environ 125 kB toutes les 12 secondes, ou une bande passante disponible d’environ 375 kB par slot. En supposant que les données de transaction soient publiées directement hors chaîne, les transferts ERC20 sont d’environ 180 octets, donc le Rollup sur Ethereum a un TPS maximal de : 375000 / 12 / 180 = 173,6 TPS.

Si nous ajoutons les calldata d’Éthereum (valeur théorique maximale : 30 millions de gaz par slot / 16 gaz par octet = 1 875 000 octets par slot), nous obtenons 607 TPS. Avec PeerDAS, le nombre de blobs pourrait augmenter à 8-16, ce qui fournirait 463-926 TPS pour les 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 d’avoir 16 Mo par slot, ce qui nous permettrait d’atteindre environ 58000 TPS en combinant les améliorations de compression des données Rollup.

Qu’est-ce que c’est? Comment ça marche?

PeerDAS est une implémentation relativement simple de “l’échantillonnage 1D”. Dans Ethereum, chaque blob est un polynôme de degré 4096 sur un corps 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 ensemble de 4096 (selon les paramètres actuellement proposés : 64 parmi un total possible de 128 échantillons) peut récupérer le blob.

Le fonctionnement de PeerDAS consiste à faire écouter à chaque client un petit sous-réseau, où le sous-réseau i diffuse tout échantillon de blob i, puis à demander à des pairs dans le réseau p2p mondial (qui écoutent différents sous-réseaux) les autres blobs dont il a besoin sur d’autres sous-réseaux. La version plus conservatrice SubnetDAS utilise uniquement le mécanisme de sous-réseau sans poser de questions supplémentaires à la couche des pairs. La proposition actuelle est que les Nœuds participant à l’attestation d’enjeu utilisent SubnetDAS, tandis que les autres Nœuds (c’est-à-dire les clients) utilisent PeerDAS.

Théoriquement, nous pouvons étendre l’échelle de l’échantillonnage 1D à une taille considérable : si nous augmentons le nombre maximal de blobs à 256 (cible : 128), nous pouvons atteindre l’objectif de 16 Mo, avec une disponibilité des données de 16 échantillons par Nœud * 128 blobs * 512 octets par échantillon par blob = une bande passante de données de 1 Mo par slot. Cela est à peine dans notre tolérance : c’est faisable, mais cela signifie que les clients à bande passante limitée ne pourront 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 un échantillonnage aléatoire entre les blobs. En utilisant les propriétés linéaires de l’engagement KZG, nous étendons un ensemble de blobs dans un Bloc à l’aide d’un nouveau groupe de blobs virtuels, ces blobs virtuels encodent de manière redondante les mêmes informations.

Nous voulons donc aller plus loin et faire de l’échantillonnage 2D, c’est-à-dire un échantillonnage aléatoire non seulement à l’intérieur du blob, mais aussi entre les blobs. La propriété linéaire de l’engagement KZG est utilisée pour étendre l’ensemble des objets blob d’un bloc avec une nouvelle liste d’objets blob virtuels qui sont codés de manière redondante avec les mêmes informations.

Échantillonnage 2D. Source: a16z crypto

Il est crucial que l’extension de l’engagement de calcul n’ait pas besoin de blob, de sorte que cette solution soit fondamentalement amicale à la construction de blocs distribués. Les nœuds construisant effectivement des blocs n’ont besoin que de l’engagement blob KZG, et ils peuvent s’appuyer sur l’échantillonnage de la disponibilité des données (DAS) pour vérifier la disponibilité des blocs de données. L’échantillonnage de la disponibilité des données unidimensionnelles (DAS 1D) est également fondamentalement amical à la construction de blocs distribués.

Quels sont les liens avec les recherches existantes ?

1. Post original sur la disponibilité des données (2018) :
2. Document de suivi:
3. Article d’explication sur DAS, paradigme :
4. Disponibilité 2D avec engagement KZG : PeerDAS sur ethresear.ch: et l’article:
5. EIP-7594:
6. SubnetDAS on ethresear.ch:
7. Subtilités récupérables dans l’échantillonnage 2D :

Qu’est-ce qui doit encore être fait ? Quels compromis faut-il encore faire ?

Ensuite, nous allons terminer la mise en œuvre et le déploiement 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 assurer la sécurité, ce qui est un processus progressif. Dans le même temps, nous espérons également avoir plus de travaux académiques pour normaliser l’interaction de PeerDAS et d’autres versions de DAS avec les règles de sélection de fork et les problèmes de sécurité.

À plus long terme, nous devrons faire plus 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 passer à terme de KZG à une alternative quantique sûre qui ne nécessite pas de configuration fiable. À l’heure actuelle, nous ne savons pas quels candidats sont favorables aux constructions de blocs distribués. Même l’utilisation de techniques coûteuses de « force brute », c’est-à-dire l’utilisation de STARK récursifs pour générer des preuves de validité pour la reconstruction de lignes et de colonnes, n’est pas suffisante, car alors qu’un STARK a techniquement la taille d’un hachage O(log(n) * log(log(n)) (en utilisant STIR), un STARK est en fait presque aussi grand qu’un blob entier.

Le chemin de réalité à long terme que je pense est:

1. Implémenter un DAS 2D idéal;
2. Maintenir l’utilisation du DAS 1D, sacrifier l’efficacité de la bande passante d’échantillonnage pour la simplicité et la robustesse, et accepter une limite de données plus basse.
3. Abandonner DA, accepter complètement Plasma comme l’architecture principale de notre Layer2 à suivre.

Veuillez noter que même si nous décidons de mettre en œuvre directement une extension sur la couche L1, cette option existe. Cela est dû au fait que si la couche L1 doit traiter un grand nombre de TPS, le bloc L1 deviendra très volumineux, et les clients souhaiteront disposer d’un moyen efficace de vérifier leur exactitude. Par conséquent, nous devrons utiliser au niveau L1 la même technologie que Rollup (comme ZK-EVM et DAS) pour la validation.

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

Si la compression des données est mise en œuvre, la demande de 2D DAS sera réduite, ou du moins la latence sera augmentée, si Plasma est largement utilisé, la demande sera encore réduite. DAS présente également des défis pour la construction de blocs distribués et le protocole : bien que DAS soit théoriquement convivial pour la reconstruction distribuée, cela nécessite en pratique une combinaison avec la proposition d’inclusion de paquets et le mécanisme de choix de fork environnant.

Compression de données

Quel problème sommes-nous en train de résoudre ?

Chaque transaction dans Rollup occupera un espace de données hors chaîne considérable : le transfert ERC20 nécessite environ 180 octets. Même avec un échantillonnage idéal de la disponibilité des données, cela limite la scalabilité du protocole de la couche. Avec chaque slot de 16 Mo, nous obtenons : 01928374656574839201

16000000 / 12 / 180 = 7407 TPS

Et si nous pouvions résoudre non seulement le problème du numérateur, mais aussi celui du dénominateur, afin que chaque transaction dans le Rollup occupe moins d’octets off-chain, que se passerait-il ?

Qu’est-ce que c’est, comment ça marche ?

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

Dans la compression de zéro octet, chaque séquence de zéro octet long est remplacée par deux octets pour indiquer combien de zéros octets il y a. De plus, nous utilisons des propriétés spécifiques de la transaction :

Agrégation de signatures : nous passons de la signature ECDSA à la signature BLS, dont la caractéristique est que plusieurs signatures peuvent être combinées en une seule, prouvant ainsi la validité de toutes les signatures originales. Au niveau L1, l’utilisation de la signature BLS n’est pas envisagée en raison du coût élevé de la vérification, même après agrégation. Cependant, dans des environnements comme le L2 où les données sont rares, l’utilisation de la signature BLS a du sens. Les caractéristiques d’agrégation de l’ERC-4337 fournissent un moyen de réaliser cette fonction.

Remplacer Adresse par des pointeurs : Si nous avons déjà utilisé une Adresse, nous pouvons remplacer les 20 octets de l’Adresse par un pointeur de 4 octets pointant vers une position dans l’historique.

La sérialisation personnalisée des valeurs de transaction - la plupart des valeurs de transaction ont un nombre limité 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.

Quels sont les liens avec les recherches existantes ?

1. Explore sequence.xyz:
2. Contrat optimisé pour les données d’appel L2 :
3. Rollups basés sur la preuve de validité (également appelés ZK rollups) diffèrent de l’état de publication des transactions :
4. Portefeuille BLS - Agrégation BLS mise en œuvre via ERC-4337 :

Que reste-t-il à faire et quels sont les compromis à faire?

La prochaine étape consiste principalement à mettre en œuvre concrètement le plan ci-dessus. Les principaux compromis comprennent :

1、La commutation vers la signature BLS nécessite un effort considérable et peut être remplacée par un emballage ZK-SNARK utilisant d’autres schémas de signature pour améliorer la sécurité, ce qui est compatible avec les puces matérielles de confiance.

2、La compression dynamique (par exemple, remplacer les pointeurs par Adresse) rendra le code client plus complexe.

3. Publier les différences d’état sur off-chain plutôt que dans les transactions réduit la vérifiabilité et empêche le bon fonctionnement de nombreux logiciels (comme les explorateurs de blockchain).

Comment interagir avec d’autres parties de la feuille de route ?

En utilisant ERC-4337 et en incorporant finalement une partie de son contenu dans L2 EVM, le déploiement de la technologie de consolidation peut être considérablement accéléré. Placer une partie du contenu de ERC-4337 sur L1 peut accélérer son déploiement sur L2.

Plasma généralisé

Quel problème sommes-nous en train de résoudre ?

Même en utilisant un blob de 16 Mo et une compression des données, 58 000 TPS ne serait peut-être pas suffisant pour répondre pleinement aux besoins des consommateurs en matière de paiement, de Décentralisation sociale ou d’autres domaines à bande passante élevée, en particulier lorsque nous commençons à considérer des facteurs de confidentialité, ce qui pourrait réduire la scalabilité de 3 à 8 fois. Pour les applications à volume élevé et à faible valeur, un choix actuel est d’utiliser le Validium, qui stocke les données off-chain 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 les fonds de tous les utilisateurs. Mais nous pouvons faire mieux.

Qu’est-ce que c’est, comment ça marche ?

Plasma est une solution de mise à l’échelle qui implique qu’un opérateur publie des blocs sur une chaîne hors chaîne et place les racines de hachage de ces blocs hors chaîne (contrairement à Rollup, qui place des blocs complets hors chaîne). Pour chaque bloc, l’opérateur envoie une branche de hachage à chaque utilisateur pour prouver les changements ou l’absence de changements de leurs avoirs. Les utilisateurs peuvent récupérer leurs avoirs en fournissant la branche de hachage. Il est important de noter que cette branche n’a pas besoin d’être enracinée dans le dernier état. Ainsi, même en cas de problème de disponibilité des données, les utilisateurs peuvent toujours récupérer leurs avoirs en extrayant le dernier état disponible. Si un utilisateur soumet une branche invalide (par exemple, récupère des avoirs qu’il a déjà envoyés à quelqu’un d’autre, ou si l’opérateur crée arbitrairement des avoirs), la légitimité des avoirs peut être déterminée grâce à un mécanisme de contestation hors chaîne.

La chaîne Plasma Cash. Les transactions dépensant la pièce i sont placées à la position i dans l’arbre. Dans cet exemple, en supposant que tous les arbres précédents sont valides, nous savons qu’Eve possède actuellement le Jeton 1, David possède le Jeton 4, George possède le Jeton 6.

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

Une méthode de création d’une chaîne EVM Plasma (mais pas la seule) : utiliser ZK-SNARK pour construire un arbre UTXO parallèle qui reflète les changements de solde effectués par l’EVM, et définit une correspondance unique pour le “même Jeton” à différents moments de l’histoire. Ensuite, la structure Plasma peut être construite dessus.

Une vision 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 des actifs (par exemple, seulement les Jeton non déplacés au cours de la dernière semaine), vous avez déjà considérablement amélioré la situation actuelle de l’EVM extrêmement évolutive (c’est-à-dire le Validium).

Une autre catégorie de structure est une combinaison de Plasma/Rollup, comme Intmax. Ces structures placent une très petite quantité de données de chaque utilisateur hors-chaîne (par exemple, 5 octets), ce qui leur permet d’obtenir certaines caractéristiques intermédiaires entre Plasma et Rollup : dans le cas d’Intmax, il est possible d’obtenir une très grande extensibilité et confidentialité, bien que même avec une capacité théorique de 16 Mo, cela reste limité à environ 16 000 000 / 12 / 5 = 266 667 TPS.

Quels sont les liens pertinents avec les recherches existantes ?

1. Document original sur Plasma :
2. Plasma Cash :
3. Plasma Cashflow:
4. Intmax (2023):

Que reste-t-il à faire ? Quels sont les compromis à faire ?

La tâche principale restante est de déployer le système Plasma dans des applications de production réelle. Comme mentionné ci-dessus, Plasma et Validium ne sont pas mutuellement exclusifs : tout Validium peut améliorer ses propriétés de sécurité dans une certaine mesure en intégrant les caractéristiques de Plasma dans son mécanisme de sortie. La recherche se concentre sur l’obtention des meilleures propriétés pour l’EVM (en tenant compte des exigences de confiance, des coûts de gaz L1 dans le pire des cas et de la capacité à résister aux attaques DoS), ainsi que sur des structures d’application spécifiques alternatives. De plus, par rapport au Rollup, Plasma est conceptuellement plus complexe, ce qui nécessite une résolution directe par la recherche et la construction d’un cadre général amélioré.

Le principal compromis de la conception de Plasma est qu’elle dépend davantage des opérateurs et qu’elle est plus difficile à baser, bien que la conception hybride Plasma/Rollup puisse généralement éviter ce point faible.

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

Plus efficace est la solution Plasma, moins de pression il y a sur L1 pour des fonctionnalités de disponibilité de données à haute performance. Déplacer les activités vers L2 peut également réduire la pression de MEV sur L1.

Système de preuve L2 mature

Quel problème sommes-nous en train de résoudre ?

Actuellement, la plupart des Rollup ne sont pas encore Trustless en réalité. Il existe un comité de sécurité qui a le pouvoir de remplacer le comportement du système de preuve (optimiste ou de validité). Dans certains cas, le système de preuve ne fonctionne même pas, ou s’il fonctionne, il n’a qu’une fonction de “consultation”. Les Rollup les plus avancés comprennent: (i) certains Rollup spécifiques à des applications Trustless, tels que FUEL; (ii) Optimism et Arbitrum, qui sont deux implémentations de la première phase d’un Rollup EVM complet sans confiance à ce jour. La raison pour laquelle les Rollup n’ont pas fait plus de progrès est la crainte de la présence de bugs dans le code. Nous avons besoin de Rollup sans confiance, nous devons donc faire face à ce problème et le résoudre.

Qu’est-ce que c’est, comment ça marche ?

Tout d’abord, revenons sur le système « stage » introduit initialement dans cet article.

Étape 0: l’utilisateur doit être en mesure d’exécuter Nœud et de synchroniser la chaîne. S’il est complètement fiable / centralisé, ce n’est pas grave non plus.

Phase 1: There must be a (trustless) proof system to ensure that only valid transactions are accepted. A security council that can overturn the proof system is allowed, but a threshold vote of 75% must be reached. In addition, the quorum-blocking portion (i.e., 26%+) of the council must be outside the main company building the Rollup. A weaker upgrade mechanism (such as a DAO) is allowed, but it must have sufficient latency so that users can withdraw their funds before they go live if the upgrade approves of malicious upgrades.

Phase 2: Il doit y avoir un système de preuve (non fiable) pour garantir que seules les transactions valides sont acceptées. Le comité de sécurité n’intervient que lorsque des erreurs prouvables existent dans le code, par exemple si deux systèmes de preuve redondants sont incohérents ou si un système de preuve accepte deux racines post-état différentes pour le même bloc (ou si aucune entrée n’est acceptée pendant une période suffisamment longue, par exemple une semaine). Les mécanismes de mise à niveau sont autorisés, mais ils doivent avoir une latence élevée.

Notre objectif est d’atteindre la phase 2. Le principal défi de la phase 2 est d’obtenir suffisamment de confiance pour prouver que le système est effectivement digne de confiance. Il existe deux méthodes principales pour y parvenir:

1. Vérification formelle : Nous pouvons utiliser les mathématiques modernes et la technologie de calcul pour prouver (optimistic et validity) que le système de preuve ne reçoit que des blocs conformes à la spécification EVM. Ces technologies existent depuis plusieurs décennies, mais les récents progrès (comme Lean 4) les rendent plus pratiques, et les progrès de la preuve assistée par l’IA pourraient accélérer davantage cette tendance.
2. Multi-provers: Create multiple proof systems and invest funds in these proof systems and the security committee (or other small tools with trust assumptions, such as TEE). If the proof systems agree, the security committee has no power; if they disagree, the security committee can only choose between them, it cannot unilaterally impose its own answer.

Le graphe programmé des multiples validateurs combine un système de preuve optimiste, un système de preuve de validité et un comité de sécurité.

Quels sont les liens avec les recherches existantes ?

1. Sémantique EVM K (travail de vérification formelle à partir de 2017):
2. Discours sur la pensée multiprofessionnelle (2022) :
3. Le projet Taiko prévoit d’utiliser une preuve multiple:

Que reste-t-il à faire ? Quels sont les compromis à faire ?

Pour la Vérification formelle, la charge de travail est importante. Nous devons créer une version de vérification formelle pour l’ensemble du prouveur SNARK de l’EVM. C’est un projet extrêmement complexe, bien que nous ayons déjà commencé. Il y a une astuce qui peut considérablement simplifier cette tâche : nous pouvons créer un prouveur SNARK vérifié formellement pour une machine virtuelle minimale (comme RISC-V ou Cairo), puis implémenter l’EVM dans cette machine virtuelle minimale (et prouver formellement son équivalence avec les autres spécifications de machine virtuelle ETH).

Pour le multi-proof, il reste encore deux parties principales à compléter. Tout d’abord, nous devons avoir suffisamment confiance en au moins deux systèmes de preuve différents pour assurer leur sécurité respective et garantir que s’ils rencontrent des problèmes, ces problèmes doivent être différents et indépendants (de sorte qu’ils ne surviennent pas simultanément). Deuxièmement, nous devons avoir une très grande confiance dans la logique sous-jacente du système de preuve combiné. Cette partie du code doit être beaucoup plus petite. Il existe des moyens de la rendre très petite en stockant les fonds dans un contrat de multi-signature sécurisé (Safe multisig) avec des contrats représentant différents systèmes de preuve en tant que signataires, mais cela augmentera le coût du gas off-chain. Nous devons trouver un équilibre entre efficacité et sécurité.

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

Déplacez l’activité vers L2 pour réduire la pression sur MEV sur L1.

Améliorations de l’interopérabilité inter-L2

Quel problème sommes-nous en train de résoudre ?

Un des principaux défis auxquels l’écosystème L2 est confronté aujourd’hui est la difficulté pour les utilisateurs de s’y orienter. De plus, les méthodes les plus simples introduisent souvent à nouveau des hypothèses de confiance : interaction cross-chain centralisée, client RPC, etc. Nous devons faire en sorte que l’utilisation de l’écosystème L2 donne l’impression d’utiliser un système unifié de l’écosystème Ethereum.

Qu’est-ce que c’est ? Comment ça marche ?

Il y a plusieurs types d’améliorations d’interopérabilité L2. En théorie, le Rollup est la même chose que l’exécution Sharding L1 centrée sur Ethereum. Cependant, l’écosystème L2 d’Ethereum actuel présente encore ces lacunes par rapport à l’état idéal :

1. Adresse de la chaîne spécifique : L’adresse devrait inclure des informations sur la chaîne (L1, Optimism, Arbitrum, etc.). Une fois cela réalisé, le processus d’envoi inter-L2 peut être réalisé en plaçant simplement l’adresse dans le champ ‘envoyer’, et le Portefeuille peut gérer en interne comment l’envoyer (y compris l’utilisation du protocole d’interaction cross-chain).

2. Demande de paiement sur une chaîne spécifique : devrait être capable de créer facilement et de manière standardisée un message du type “envoie-moi X de l’actif Y sur la chaîne Z”. Il existe principalement deux scénarios d’application : (i) paiements entre personnes ou entre personnes et services marchands ; (ii) demande de fonds pour une DApp.

3. Échange croisé d’interaction et paiement de gaz : il devrait y avoir un protocole ouvert standardisé pour exprimer les opérations d’échange croisé d’interaction, telles que “Je vais envoyer 1 ETH à la personne qui m’envoie 0,9999 ETH sur Arbitrum (sur Optimism)”, ainsi que “Je vais envoyer 0,0001 ETH à la personne incluant cette transaction sur Arbitrum (sur Optimism)”. ERC-7683 est une tentative pour le premier cas, tandis que RIP-7755 est une tentative pour le second cas, bien que leur champ d’application soit plus large que ces cas d’utilisation spécifiques.

4、light client: Les utilisateurs doivent être en mesure de vérifier effectivement la chaîne avec laquelle ils interagissent, plutôt que de faire confiance uniquement aux fournisseurs RPC. Helios de a16z crypto peut le faire (pour ETH lui-même), mais nous devons étendre cette décentralisation à la couche L2. ERC-3668 (CCIP-read) est une stratégie pour atteindre cet objectif.

Comment mettre à jour la vue de la chaîne d’en-tête Ethereum d’un light client. Une fois que vous avez la chaîne d’en-tête, vous pouvez utiliser une preuve de Merkle pour vérifier n’importe quel objet d’état. Une fois que vous avez le bon objet d’état L1, vous pouvez utiliser une preuve de Merkle (et éventuellement une signature si vous souhaitez vérifier une confirmation) pour vérifier n’importe quel objet d’état sur L2. Helios a déjà accompli la première étape. Étendre à la seconde est un défi de normalisation.

1. Portefeuille Keystore: Aujourd’hui, si vous souhaitez mettre à jour la Clé secrète de votre Portefeuille Smart Contracts, vous devez effectuer la mise à jour sur toutes les chaînes où le Portefeuille est présent. Le Portefeuille Keystore est une technologie qui permet à la Clé secrète de n’exister qu’à un seul endroit (soit sur L1, soit éventuellement sur L2) et qui peut ensuite être lue par n’importe quel L2 possédant une copie du Portefeuille. Cela signifie qu’une mise à jour n’est nécessaire qu’une seule fois. Pour améliorer l’efficacité, le Portefeuille Keystore exige que le L2 dispose d’une méthode normalisée pour lire gratuitement les informations sur L1 ; il y a deux propositions à cet effet, à savoir L1SLOAD et REMOTESTATICCALL.

Le fonctionnement de Keystore Portefeuille

2. Une vision plus radicale du pont Jeton partagé: Imaginez un monde où tous les L2 sont des Rollups de preuve de validité et chaque slot soumet à la chaîne Ethereum. Même dans un tel monde, il est toujours nécessaire de retirer et de déposer des actifs d’un L2 à un autre en état natif, ce qui entraîne des frais de gaz considérables sur la couche L1. Une solution à ce problème consiste à créer un Rollup partagé extrêmement simple, dont la seule fonction est de maintenir la propriété de chaque type de Jeton par quel L2 et le solde de chaque type de Jeton détenu par chaque L2, et de permettre ces soldes à être mis à jour par lots via une série d’opérations de transfert inter-L2 initiées par n’importe quel L2. Cela permettrait des transferts inter-L2 sans avoir à payer à chaque fois des frais de gaz L1, ni à utiliser des techniques telles que ERC-7683 basées sur les fournisseurs de liquidité.

3、Composition synchrone : permet des appels synchrones entre des L2 spécifiques et L1 ou entre plusieurs L2. Cela contribue à améliorer l’efficacité financière du protocole DeFi. Le premier peut être réalisé sans aucune coordination inter-L2, tandis que le second nécessite un partage de l’ordre. La technologie basée sur Rollup s’applique automatiquement à toutes ces techniques.

Quels sont les liens avec les recherches existantes ?

**Adresse spécifique de la chaîne : ERC-3770 :

**ERC-7683:

**RIP-7755:

**Modèle de conception de portefeuille Scroll keystore :

**Helios:

**ERC-3668 (parfois appelé CCIP Read) :

La proposition de Justin Drake sur le « pré-commitment (partagé) » :

**L1SLOAD (RIP-7728):

**REMOTESTATICCALL dans Optimism:

**AggLayer, y compris l’idée de pont de jeton partagé:

Que reste-t-il à faire ? Quels sont les compromis à faire ?

De nombreux exemples ci-dessus sont confrontés à des dilemmes de normalisation concernant le moment de la normalisation et les couches à normaliser. Une normalisation trop précoce peut ancrer une solution médiocre. Une normalisation trop tardive peut entraîner une fragmentation inutile. Dans certains cas, il existe à la fois une solution à court terme avec des attributs plus faibles mais plus faciles à mettre en œuvre, et une solution à long terme qui est la «bonne solution finale», mais qui prendra plusieurs années à réaliser.

Ces tâches ne sont pas seulement des problèmes techniques, mais aussi (voire principalement) des problèmes sociaux, nécessitant une coopération entre L2 et Portefeuille ainsi que L1.

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

La plupart de ces propositions sont des structures de niveau supérieur, donc elles n’ont pas beaucoup d’impact sur le niveau L1. Une exception est le tri partagé, qui a un impact significatif sur la valeur extractible maximale (MEV).

Étendre l’exécution sur L1

Quel problème sommes-nous en train de résoudre ?

Si L2 devient très scalable et réussi, mais L1 ne peut toujours traiter qu’un très faible volume, alors Ethereum pourrait présenter de nombreux risques :

1、L’état économique des actifs ETH deviendra encore plus instable, ce qui à son tour affectera la sécurité à long terme du réseau.

2. De nombreux L2 bénéficient d’une étroite connexion avec l’écosystème financier hautement développé de L1. Si cet écosystème est considérablement affaibli, les incitations à devenir L2 (au lieu d’être un L1 indépendant) seront réduites.

3. Il faudra encore beaucoup de temps pour que L2 atteigne le même niveau de sécurité que L1.

4. En cas de défaillance de L2 (par exemple, en raison d’un comportement malveillant ou d’une disparition de l’opérateur), les utilisateurs doivent toujours passer par L1 pour récupérer leurs actifs. Par conséquent, L1 doit être suffisamment robuste pour gérer les finitions très complexes et chaotiques de L2, au moins occasionnellement.

Pour ces raisons, il est très précieux de continuer à étendre L1 lui-même et à s’assurer qu’il peut continuer à accueillir de plus en plus de cas d’utilisation.

Qu’est-ce que c’est? Comment ça marche?

La manière la plus simple de procéder à une extension consiste à augmenter directement la limite de gas. Cependant, cela pourrait conduire à une centralisation de la L1, affaiblissant ainsi un autre aspect essentiel de l’ETHereum L1 : sa crédibilité en tant que couche fondamentale robuste. Il existe actuellement un débat sur la durabilité d’une simple augmentation de la limite de gas, et cela dépendra également des autres technologies mises en œuvre pour faciliter la validation de blocs plus importants (par exemple, l’expiration historique, l’état sans mémoire, preuve de validité L1 EVM). Un autre aspect important à améliorer en continu est l’efficacité du logiciel client ETHereum, qui est bien plus élevée aujourd’hui qu’il y a cinq ans. Une stratégie efficace d’augmentation de la limite de gas L1 impliquerait d’accélérer le développement de ces technologies de validation.

1. EOF: un nouveau format de bytecode EVM, plus convivial pour l’analyse statique, permettant une mise en œuvre plus rapide. Avec ces améliorations d’efficacité, le bytecode EOF peut obtenir des frais de gaz plus bas.
2. Tarification du gaz multidimensionnelle : des frais de base et des limites différents sont définis pour le calcul, les données et le stockage, ce qui permet d’augmenter la capacité moyenne de la couche L1 d’Ethereum (sans augmenter la capacité maximale et ainsi éviter de nouveaux risques de sécurité).
3. Certaines opérations spécifiques de Goutte et le coût pré-compilé du gas - Historiquement, pour éviter les attaques par déni de service, nous avons souvent augmenté le coût en gas de certaines opérations sous-évaluées. Une autre possibilité serait d’augmenter le coût en gas des opérations surévaluées de Goutte. Par exemple, l’addition est beaucoup moins chère que la multiplication, mais actuellement, les opérations ADD et MUL ont le même coût. Nous pourrions réduire le coût de l’ADD de Goutte, voire réduire le coût d’opérations plus simples comme PUSH. Globalement, il y a encore des optimisations à faire dans ce domaine.
4. EVM-MAX et SIMD: EVM-MAX est une proposition qui permet une arithmétique native plus efficace des grands nombres modulaires en tant que module séparé de l’EVM. Sauf intention explicite d’exporter, les valeurs calculées par EVM-MAX ne peuvent être accessibles qu’aux autres opcodes EVM-MAX. Cela permet un espace plus important pour optimiser le stockage de ces valeurs. SIMD (single instruction multiple data) est une proposition qui permet d’exécuter efficacement la même instruction sur un tableau de valeurs. Ensemble, ils peuvent créer un puissant coprocesseur à côté de l’EVM, qui peut être utilisé pour implémenter de manière plus efficace chiffrement. Cela est particulièrement utile pour les protocoles de confidentialité et les systèmes de protection L2, ce qui contribuera à l’expansion de L1 et L2.

Ces améliorations seront discutées plus en détail dans les prochains articles Splurge.

Enfin, la troisième stratégie est les Rollups natifs (ou rollups enshrined) : fondamentalement, créer de nombreuses copies parallèles de l’EVM en cours d’exécution, produisant ainsi un modèle équivalent à ce que Rollup peut offrir, mais plus intégré au protocole.

Quels sont les liens avec les recherches existantes ?

1. La feuille de route d’extension L1 ETH de Polynya :
2. Tarification du gaz multidimensionnelle :
3. EIP-7706:
4. EOF:
5. EVM-MAX:
6. SIMD:
7. Rollups natifs:
8. Max Resnick Interview sur la valeur de l’extension L1 :
9. Justin Drake parle de l’extension avec SNARK et Rollups natifs :

Que reste-t-il à faire et quels sont les compromis à faire?

Il existe trois stratégies pour la mise à l’échelle L1, qui peuvent être effectuées individuellement ou en parallèle :

1. Améliorer la technologie (comme le code client, le client sans état, l’expiration de l’historique) pour faciliter la vérification de L1, puis augmenter la limite de gas.
2. Le coût des opérations spécifiques de Goutte augmente la capacité moyenne sans augmenter le risque dans le pire des cas;
3. Rollups natifs (c’est-à-dire, créer N copies parallèles de l’EVM).

En comprenant ces différentes technologies, nous constaterons qu’elles ont chacune des compromis différents. Par exemple, les Rollups natifs ont de nombreux points faibles en termes de compositionnalité similaires à ceux des Rollups ordinaires : vous ne pouvez pas envoyer une transaction unique pour exécuter des opérations synchronisées sur plusieurs Rollups, comme vous pouvez le faire avec un contrat sur le même L1 (ou L2). Augmenter la limite de Gas affaiblira d’autres avantages qui peuvent être réalisés en simplifiant la validation L1, tels que l’augmentation du pourcentage d’utilisateurs vérifiant les nœuds et le nombre de SOLO stakers. Selon la méthode de mise en œuvre, rendre spécifiques opérations moins chères dans l’EVM (Machine virtuelle Éther) peut augmenter la complexité globale de l’EVM.

Une question importante que tout plan d’expansion L1 doit répondre est : Quel est le but ultime de L1 et L2 respectivement ? Il est évident que mettre tout sur L1 est absurde : les scénarios d’application potentiels pourraient impliquer des centaines de milliers de transactions par seconde, ce qui rendrait la vérification impossible sur L1 (à moins que nous n’adoptons une approche native de Rollup). Cependant, nous avons besoin de certaines lignes directrices pour nous assurer que nous ne nous retrouvons pas dans une situation où la limite de gaz est augmentée de 10 fois, ce qui porterait gravement atteinte à la décentralisation d’ETH sur L1.

Une perspective sur la division du travail entre L1 et L2

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

L’implication de plus d’utilisateurs sur L1 signifie non seulement améliorer l’évolutivité, mais aussi améliorer d’autres aspects de L1. Cela signifie que plus de MEV restera sur L1 (et ne sera pas seulement un problème de L2), ce qui rend la gestion explicite de MEV plus urgente. Cela augmentera considérablement la valeur du temps de slot rapide sur L1. Cela dépend également fortement du bon déroulement de la vérification L1 (the Verge).

Lecture recommandée : « Le futur possible d’ETH坊, the Merge » par Vitalik