Nouveau document de Vitalik : L'avenir possible d'Éther, The Surge

Auteur original: Vitalik Buterin

Original text compiled: Karen, Foresight News

Un grand merci à Justin Drake, Francesco, Hsiao-wei Wang, @antonttc et Georgios Konstantopoulos.

Au début, le plan de Éther avait deux stratégies de mise à l’échelle. L’un (voir un document de travail précoce datant de 2015) était le « Sharding » (sharding) : chaque Nœud n’avait besoin de valider et de stocker qu’une petite partie des transactions, plutôt que de valider et de 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 il est tout à fait possible de faire fonctionner la blockchain de la même manière. L’autre était le protocole Layer 2 : ces réseaux se situeraient au-dessus de Éther, lui permettant de bénéficier pleinement de sa sécurité tout en maintenant la majorité des données et des calculs en dehors de la mainchain. Layer 2 protocole 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 large bande passante pour les données off-chain. Heureusement, d’ici 2019, la recherche sur le Sharding avait résolu le problème de « disponibilité des données » à grande échelle. En conséquence, les deux voies se sont fusionnées pour donner un plan centré sur le Rollup, qui reste aujourd’hui la stratégie d’extension de Éther.

The Surge, version de la feuille de route 2023

La feuille de route axée sur Rollup propose une répartition simple des tâches : ETH L1 se concentre sur sa mission de fournir une couche de base puissante et décentralisée, tandis que L2 assume la tâche d’aider l’écosystème à se développer. Ce modèle est omniprésent dans la société : l’existence du système judiciaire (L1) n’est pas destinée à poursuivre la vitesse et l’efficacité à tout prix, mais à protéger les contrats et les droits de propriété, tandis que les entrepreneurs (L2) doivent construire sur cette base solide pour mener l’humanité vers Mars, que cela soit au sens littéral ou métaphorique.

Cette année, la feuille de route axée sur Rollup a connu des avancées majeures : avec le déploiement des blobs EIP-4844, la bande passante des données d’ETH L1 a considérablement augmenté, et plusieurs Rollup Ethereum Virtual Machine (EVM) 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 désormais 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 axée sur Rollup, de résoudre ces problèmes tout en préservant la robustesse et la décentralisation spécifiques à l’ETH L1.

La montée en puissance: Objectif clé

1. L’avenir d’Ethereum peut atteindre plus de 100 000 TPS grâce à la couche 2.

2, maintenir la décentralisation et la résilience de L1;

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

4. Ethereum devrait se sentir comme un écosystème unifié plutôt que 34 blockchains différentes.

Contenu de ce chapitre

• Le paradoxe du triangle de scalabilité
• Avancées supplémentaires dans l’échantillonnage de la disponibilité des données
• Compression de données
• Plasma généralisé
• Système de preuve L2 mature
• Amélioration de l’interopérabilité entre les L2
• Étendre l’exécution sur L1

Le paradoxe du triangle de scalabilité

Le paradoxe triangulaire de la scalabilité est une idée proposée en 2017 qui suggère qu’il existe une contradiction entre les trois caractéristiques de la blockchain : la décentralisation (plus précisément, le faible coût de fonctionnement des nœuds), la scalabilité (le traitement d’un grand nombre de transactions) et la sécurité (les attaquants doivent détruire 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 que les articles qui présentent le paradoxe du triangle ne sont pas accompagnés d’une preuve mathématique. Il fournit en effet un argument mathématique heuristique: si un nœud décentralisé (par exemple, un ordinateur portable grand public) 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 a seulement besoin de compromettre quelques nœuds pour effectuer une transaction malveillante, ou (ii) votre nœud devient puissant tandis que votre chaîne ne se décentralise pas. 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 qu’il est difficile de briser le paradoxe du triangle, ce qui nécessite de sortir du cadre de pensée implicite de cet argument.

Au fil des ans, certains réseaux haute performance ont souvent prétendu résoudre le paradoxe ternaire sans changer fondamentalement leur architecture, en optimisant les nœuds à l’aide de techniques de génie logiciel. Cela est toujours trompeur car il est beaucoup plus difficile de faire fonctionner les nœuds off-chain que les nœuds sur la chaîne ETH. Cet article examinera pourquoi c’est le cas et pourquoi l’ingénierie logicielle du client L1 seule ne peut pas étendre ETH.

Cependant, la combinaison de l’échantillonnage de la disponibilité des données avec les SNARKs résout effectivement le paradoxe du triangle : elle permet aux clients de vérifier qu’un certain nombre de données est disponible et qu’un certain nombre d’étapes de calcul sont correctement exécutées en téléchargeant uniquement 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 few-of-N subtil, mais il conserve les caractéristiques fondamentales d’une chaîne non évolutive, c’est-à-dire qu’une attaque à 51 % ne peut pas forcer la validation d’un bloc défectueux par le réseau.

Une autre méthode pour résoudre le dilemme des trois difficultés est l’architecture Plasma, qui utilise une technologie astucieuse pour responsabiliser les utilisateurs de manière incitative en matière de disponibilité des données de surveillance. Au cours des années 2017-2019, lorsque nous n’avions que la preuve de fraude comme moyen d’étendre les capacités de calcul, Plasma était très limité en termes d’exécution sécurisée. Cependant, avec la popularisation des SNARKs (preuves succinctes non interactives à connaissance zéro), l’architecture Plasma devient plus viable pour une utilisation plus large que jamais.

Avancées supplémentaires dans l’échantillonnage de la disponibilité des données

Quel problème résolvons-nous ?

Le 13 mars 2024, lorsque Dencun sera mis à jour, chaque slot de la blockchain Ethereum aura environ 3 blobs de 125 kB, soit une bande passante disponible d’environ 375 kB par slot toutes les 12 secondes. Si les données de transaction sont publiées off-chain, les transferts ERC20 auront environ 180 octets. Par conséquent, le TPS maximum de Rollup sur Ethereum est de 173,6 TPS.

Si nous ajoutons calldata d’Ethereum (valeur maximale théorique : 30 millions de gas par slot / 16 gas par octet = 1 875 000 octets par slot), cela deviendra 607 TPS. En utilisant PeerDAS, le nombre de blobs pourrait augmenter à 8-16, ce qui fournirait 463-926 TPS pour 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 chaque slot de 16 Mo, ce qui, combiné à l’amélioration de la compression des données Rollup, donnera environ 58000 TPS.

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

PeerDAS est une implémentation relativement simple de “1 D sampling”. Dans la blockchain ETH, chaque blob est un polynôme de degré 4096 dans 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 les 128 échantillons possibles) peut récupérer le blob.

Le fonctionnement de PeerDAS consiste à faire écouter à chaque client un petit sous-réseau, où le i-ème sous-réseau diffuse tout blob de l’échantillon i et demande aux pairs du réseau P2P mondial (qui écoutent différents sous-réseaux) de lui fournir les blobs des autres sous-réseaux dont il a besoin. 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 que les Nœuds participant à l’Attestation d’enjeu utilisent SubnetDAS, tandis que les autres Nœuds (c’est-à-dire les clients) utilisent PeerDAS.

En théorie, nous pouvons étendre l’échelle de l’échantillonnage «1 D» à une taille assez grande : si nous augmentons le nombre maximal de blobs à 256 (cible : 128), alors nous pouvons atteindre l’objectif de 16 Mo, avec une disponibilité des données échantillonnées sur chaque nœud 16 échantillons * 128 blobs * 512 octets par échantillon de blob = 1 Mo de bande passante de données par slot. Cela est tout juste tolérable pour nous : 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 leur taille, mais cela augmentera le coût de reconstruction.

Par conséquent, nous voulons finalement aller plus loin et effectuer un échantillonnage 2D (échantillonnage 2D), cette méthode consiste non seulement à effectuer un échantillonnage aléatoire à l’intérieur du blob, mais également à effectuer un échantillonnage aléatoire entre les blobs. En utilisant les propriétés linéaires de l’engagement KZG, un ensemble de nouveaux blobs virtuels est utilisé pour étendre l’ensemble de blobs dans un bloc, ces blobs virtuels encodant redondamment les mêmes informations.

Ainsi, nous voulons aller plus loin en effectuant un échantillonnage 2D, non seulement à l’intérieur du blob, mais également entre les blobs, pour étendre un ensemble de blocs avec les propriétés linéaires promises par KZG, qui comprend une nouvelle liste de blobs virtuels codant de manière redondante les mêmes informations.

Échantillonnage 2D. Source de données : a16z crypto.

Il est crucial de noter que l’extension de l’engagement de calcul n’a pas besoin de blob, donc cette solution est fondamentalement conviviale pour la construction de blocs distribués. Les nœuds réels construisant des blocs n’ont besoin que de l’engagement KZG de blob et peuvent compter sur l’échantillonnage de disponibilité des données (DAS) pour vérifier la disponibilité des blocs de données. L’échantillonnage de disponibilité de données en une dimension (1 D DAS) est également essentiellement convivial pour la construction de blocs distribués.

Quels sont les liens avec les recherches existantes ?

• Post original sur la disponibilité des données (2018) :
• Follow-up paper:
• Article d’explication sur DAS, paradigme :
• Disponibilité 2D avec la promesse de KZG :
• PeerDAS on ethresear.ch: and the paper:
• EIP-7594:
• SubnetDAS sur ethresear.ch :
• Les subtils différences récupérables dans l’échantillonnage 2D :

Que reste-t-il à faire? Quelles sont les considérations à prendre en compte?

Ensuite, il s’agit de mettre en œuvre et de lancer PeerDAS. Ensuite, augmentez 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é, c’est un processus progressif. Dans le même temps, nous espérons avoir plus de travaux académiques pour réglementer l’interaction de PeerDAS et d’autres versions de DAS, ainsi que des problèmes de sécurité liés aux règles de choix de fork.

Dans les étapes ultérieures, nous devrons faire plus 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 passer finalement d’un KZG à une alternative quantique sécurisée et sans configuration de confiance. Pour l’instant, nous ne savons pas quels candidats sont favorables à la construction du Bloc distribué. Même en utilisant la technique coûteuse de la “bruteforce” et en utilisant récursivement STARK pour générer une preuve de validité pour la reconstruction des lignes et des colonnes, cela ne suffit pas à répondre à la demande, car bien que techniquement, la taille d’un STARK soit de O(log(n) * log(log(n)) hash values (utilisant STIR), en réalité, un STARK est presque aussi grand que l’ensemble du blob.

Mon chemin de réalisation à long terme est selon moi :

1. Mettre en œuvre un DAS 2D idéal;
2. En utilisant D DAS, sacrifiez l’efficacité de la largeur de bande d’échantillonnage pour la simplicité et la robustesse, et acceptez une limite de données plus basse.
3. (Pivot majeur) Abandonner DA et adopter complètement Plasma comme notre principale architecture Layer 2 à suivre.

Veuillez noter que même si nous décidons d’effectuer une expansion directe sur la couche L1, cette option est également possible. 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 voudront disposer d’une méthode efficace pour en vérifier la validité. Ainsi, nous devrons utiliser au niveau L1 la même technologie que Rollup (comme ZK-EVM et DAS) pour garantir leur validité.

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

Si la compression des données est réalisée, la demande de DAS 2D sera réduite ou du moins latente. Si Plasma est largement utilisé, la demande sera encore réduite. Le DAS pose également des défis pour la construction de blocs et de mécanismes de protocole distribués : bien que le DAS soit théoriquement favorable à 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 qui l’entoure.

Compression de données

Quel problème résolvons-nous?

Chaque transaction dans Rollup utilise beaucoup d’espace de données hors chaîne : le transfert ERC 20 prend environ 180 octets. Même avec un échantillonnage idéal de la disponibilité des données, cela limite la scalabilité du protocole de couche. Avec chaque slot de 16 Mo, nous obtenons :

16000000 / 12 / 180 = 7407 TPS

Si nous pouvions non seulement résoudre le problème du numérateur, mais aussi le problème du dénominateur, et permettre à chaque transaction dans chaque Rollup d’occuper moins de bytes off-chain, que se passerait-il ?

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

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

Lors de la compression en zéro octet, chaque séquence de zéro octet long est remplacée par deux octets pour indiquer combien de zéros sont présents. De plus, nous exploitons les propriétés spécifiques de la transaction :

Agrégation de signatures : Nous sommes passés de la signature ECDSA à la signature BLS. Les caractéristiques de la signature BLS permettent de combiner plusieurs signatures en une seule, ce qui peut prouver la validité de toutes les signatures d’origine. Au niveau L1, même en effectuant une agrégation, le coût de calcul de la vérification reste élevé, c’est pourquoi l’utilisation de la signature BLS n’est pas envisagée. Cependant, dans des environnements comme L2 où les données sont rares, l’utilisation de la signature BLS a du sens. La caractéristique d’agrégation de l’ERC-4337 offre une voie pour mettre en œuvre cette fonctionnalité.

Remplacer Adresse par des pointeurs : si nous avons utilisé précédemment une Adresse, nous pouvons la remplacer par un pointeur de 4 octets pointant vers une position dans l’historique.

La sérialisation personnalisée de la valeur 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 maximaux et les frais de priorité sont 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 ?

• Explore sequence.xyz:
• L2 Calldata Optimized Contract：
• Les Rollups basés sur la preuve de validité (également connus sous le nom de ZK rollups) diffèrent de l’état de publication, pas des transactions :
• Portefeuille BLS - Agrégation BLS réalisée via ERC-4337 :

Que reste-t-il à faire et quels compromis faut-il faire ?

La prochaine étape consiste principalement à mettre en œuvre concrètement les solutions ci-dessus. Les principaux compromis incluent :

1. Le passage à la signature BLS nécessite un effort considérable et peut réduire la compatibilité avec les puces matérielles fiables qui renforcent la sécurité. Il peut être remplacé par un encodage ZK-SNARK utilisant d’autres schémas de signature.

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

3、Publier les différences d’état hors chaîne au lieu des transactions peut réduire l’auditabilité et rendre de nombreux logiciels (comme le blockchain explorer) inutilisables.

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

Adoptant ERC-4337, et finalement l’intégrant partiellement dans L2 EVM, peut grandement accélérer le déploiement de la technologie d’agrégation. Placer une partie du contenu de l’ERC-4337 sur L1 peut accélérer son déploiement sur L2.

Plasma généralisé

Quel problème résolvons-nous ?

Même avec un blob de 16 Mo et une compression de données, 58 000 TPS ne suffisent pas nécessairement à répondre pleinement aux besoins des consommateurs en matière de paiement, de réseaux sociaux décentralisés ou d’autres domaines à haut débit, surtout lorsque nous commençons à prendre en compte la confidentialité, ce qui pourrait augmenter la scalabilité de 3 à 8 fois. Pour les applications à haut volume et à faible valeur, l’une des options actuelles est d’utiliser Validium, qui stocke 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 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 hors chaîne et place les racines de Merkle de ces Blocs hors chaîne (contrairement à Rollup, qui place les Blocs complets hors chaîne). Pour chaque Bloc, l’opérateur envoie à chaque utilisateur une branche de Merkle pour prouver les changements ou l’absence de changement dans les actifs de cet utilisateur. Les utilisateurs peuvent récupérer leurs actifs en fournissant la branche de Merkle. Il est important de noter que cette branche n’a pas besoin d’avoir la racine de l’état le plus récent. Ainsi, même en cas de problème de disponibilité des données, les utilisateurs peuvent toujours récupérer leurs actifs en extrayant l’état le plus récent disponible. Si un utilisateur soumet une branche invalide (par exemple, en récupérant des actifs qu’il a déjà envoyés à quelqu’un d’autre, ou en créant des actifs à partir de rien), la légitimité des actifs peut être déterminée grâce au mécanisme de contestation hors chaîne.

Graphique de 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 soient valides, nous savons qu’Eve possède actuellement le Jeton 1, David possède le Jeton 4 et George possède le Jeton 6.

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

Une méthode (pas la seule) pour créer une chaîne EVM Plasma : 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 insight clé est que le système Plasma n’a pas besoin d’être parfait. Même si vous ne protégez qu’un sous-ensemble des actifs (par exemple, seulement les Jetons qui n’ont pas bougé au cours de la dernière semaine), vous améliorez considérablement la situation actuelle de l’EVM super-évolutif (c’est-à-dire le Validium).

Une autre catégorie de structures est le Plasma/Rollup hybride, comme Intmax. Ces constructions placent une petite quantité de données (par exemple, 5 octets) hors chaîne pour chaque utilisateur, ce qui permet d’obtenir certaines caractéristiques intermédiaires entre Plasma et Rollup : dans le cas d’Intmax, vous pouvez obtenir une extensibilité et une confidentialité très élevées, même si théoriquement, dans une capacité de 16 Mo, la limite est d’environ 16,000,000 / 12 / 5 = 266,667 TPS.

Quels sont les liens connexes avec les recherches existantes?

• Document original Plasma :
• Plasma Cash:
• Flux de trésorerie Plasma Cashflow :
• Intmax (2023):

Que reste-t-il à faire ? Quels compromis sont nécessaires ?

La tâche principale restante est de mettre le système Plasma en production. Comme mentionné ci-dessus, Plasma et Validium ne sont pas un choix exclusif : tout Validium peut améliorer sa 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 besoins en matière 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 recherche et la construction d’un cadre général plus solide pour le résoudre directement.

Les principaux compromis de conception de l’utilisation de Plasma résident dans leur plus grande dépendance aux opérateurs et leur plus grande complexité, bien que la conception mixte 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 grande est la pression sur la fonctionnalité de disponibilité des données haute performance de L1. Déplacer les activités vers L2 permet également de réduire la pression MEV sur L1.

Système de preuve L2 mature

Quel problème résolvons-nous ?

Actuellement, la plupart des Rollup ne sont pas réellement sans confiance. Il existe un comité de sécurité qui a la capacité de modifier le comportement du système de preuve (optimiste ou valide). Dans certains cas, le système de preuve ne fonctionne même pas du tout, ou même s’il fonctionne, il n’a qu’une fonction de « conseil ». Les Rollup les plus avancés comprennent : (i) certains Rollup spécifiques à une application sans confiance, tels que FUEL ; (ii) au moment de la rédaction du présent document, Optimism et Arbitrum sont deux Rollup EVM complets sans confiance qui ont mis en œuvre une première étape de jalons sans confiance partiels. La raison pour laquelle les Rollup n’ont pas progressé davantage est la crainte de la présence de bogues dans le code. Nous avons besoin de Rollup sans confiance, nous devons donc faire face et résoudre ce problème.

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

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

Phase 0: Les utilisateurs doivent pouvoir exécuter Nœud et synchroniser la chaîne. Il n’y a pas de problème si la validation est totalement fiable / centralisée.

Étape 1 : Il doit y avoir un système de preuve (sans confiance) pour s’assurer que seules les transactions valides sont acceptées. Il est permis d’avoir un comité de sécurité capable de renverser le système de preuve, mais avec un seuil de vote de 75%. De plus, une partie du comité de quorum-blocking (soit 26% +) doit être en dehors de la société principale construisant le Rollup. Il est permis d’utiliser un mécanisme de mise à niveau moins puissant (comme un DAO), mais il doit avoir une latence suffisamment longue, de sorte que si une mise à niveau malveillante est approuvée, les utilisateurs peuvent retirer leurs fonds avant qu’ils ne soient mis en ligne.

Étape 2 : Il doit y avoir un système de preuve (sans confiance) pour garantir que seules les transactions valides seront acceptées. La Commission de sécurité n’intervient que en cas d’erreurs prouvables dans le code, par exemple. Si deux systèmes de preuve redondants sont en désaccord, ou si un système de preuve accepte deux états postérieurs différents d’un même bloc (ou n’accepte aucun contenu 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 très longue.

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

• Vérification formelle : Nous pouvons utiliser les mathématiques modernes et la technologie de calcul pour prouver (optimisme et validité) que le système de preuve n’accepte que les Bloc conformes à la spécification EVM. Ces techniques existent depuis des décennies, mais les progrès récents (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.
• Multi-provers : Créer plusieurs systèmes de preuve et investir des fonds dans ces systèmes de preuve et dans un comité de sécurité (ou d’autres outils de confiance, tels que TEE). Si les systèmes de preuve sont d’accord, le comité de sécurité n’a aucun pouvoir ; s’ils ne sont pas d’accord, le comité de sécurité ne peut choisir que l’un d’entre eux, il ne peut pas imposer sa propre réponse unilatéralement.

Le graphique de plusieurs preuves 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 ?

• Sémantique K EVM (travail de vérification formelle à partir de 2017):
• Discours sur la pensée du multi-proof (2022):
• Le projet Taiko prévoit d’utiliser une preuve multiple :

Que reste-t-il à faire ? Quels compromis sont nécessaires ?

Pour Vérification formelle, le travail est énorme. Nous devons créer une version de vérification formelle du prouveur SNARK complet de l’EVM. C’est un projet extrêmement complexe, bien que nous ayons déjà commencé. Il y a une astuce qui peut grandement 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 formellement prouver son équivalence avec d’autres spécifications de Machine virtuelle ETH).

Pour la preuve multi-système, il reste encore deux parties principales à finaliser. Tout d’abord, nous devons avoir suffisamment confiance dans au moins deux systèmes de preuve différents, en veillant à ce qu’ils soient tous deux suffisamment sécurisés et à ce que s’ils rencontrent des problèmes, ces problèmes soient différents et indépendants (de sorte qu’ils ne rencontrent pas de problèmes en même temps). Deuxièmement, nous devons avoir une très grande confiance dans la logique sous-jacente du système de preuve fusionné. Cette partie du code doit être beaucoup plus petite. Il existe des méthodes pour le rendre très petit, il suffit de stocker les fonds dans un contrat de sécurité multi-signatures (Safe multisig) avec des signataires représentant les différents systèmes de preuve, mais cela augmentera les coûts hors chaîne des Gas. Nous devons trouver un équilibre entre efficacité et sécurité.

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

Déplacer l’activité vers L2 peut réduire la pression MEV sur L1.

Amélioration de l’interopérabilité L2

Quel problème résolvons-nous ?

Un des principaux défis auxquels est confronté l’écosystème L2 aujourd’hui est la difficulté pour les utilisateurs de s’y orienter. De plus, les méthodes les plus simples réintroduisent souvent des présomptions de confiance : interopérabilité centralisée, client RPC, etc. Nous devons faire en sorte que l’utilisation de l’écosystème L2 donne l’impression d’utiliser un écosystème Ethereum unifié.

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

Il existe de nombreuses catégories d’améliorations d’interopérabilité L2. En théorie, l’ETH centré sur Rollup et l’exécution de Sharding L1 sont la même chose. Cependant, l’écosystème L2 actuel d’ETH est encore loin d’être idéal en pratique pour ces raisons :

1、Adresse de la chaîne spécifique : l’Adresse devrait inclure des informations sur la chaîne (L1, Optimism, Arbitrum…). Une fois cela réalisé, le processus d’envoi trans-L2 peut être réalisé en simplement plaçant l’Adresse dans le champ “Envoyer”, à ce moment-là, le Portefeuille peut gérer en arrière-plan comment envoyer (y compris l’utilisation du protocole de cross-chain Interaction).

2. Demande de paiement pour une chaîne spécifique : il devrait être facile et normalisé de créer un message de la forme « envoyez-moi X unités de la cryptomonnaie Y sur la chaîne Z ». Cela s’applique principalement à deux scénarios : (i) les paiements entre personnes ou entre personnes et commerçants ; (ii) les demandes de fonds des DApps.

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 éther à la personne qui m’a envoyé 0,9999 éther sur Arbitrum (sur Optimism)” et “Je vais envoyer 0,0001 éther à la personne incluse dans cette transaction sur Arbitrum (sur Optimism)”. ERC-7683 est un essai pour le premier cas, tandis que RIP-7755 est un essai pour le second, bien que leur champ d’application soit plus large que ces cas d’utilisation spécifiques.

4. client léger: les utilisateurs devraient être en mesure de vérifier réellement la chaîne avec laquelle ils interagissent, et ne pas seulement faire confiance aux fournisseurs RPC. Helios de a16z crypto peut le faire (pour ETH lui-même), mais nous devons étendre cette décentralisation à 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 client léger. 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 l’objet d’état L1 correct, vous pouvez utiliser une preuve de Merkle (et une signature si vous souhaitez vérifier la pré-confirmation) pour vérifier n’importe quel objet d’état sur L2. Helios a déjà accompli la première étape. L’extension à la seconde est un défi de normalisation.

1. Keystore Portefeuille: Maintenant, si vous voulez mettre à jour la Clé secrète de votre Portefeuille Smart ContractPortefeuille, vous devez effectuer la mise à jour sur toutes les chaînes où ce Portefeuille existe. Le Keystore Portefeuille est une technique qui permet à la Clé secrète de n’exister qu’à un seul endroit (soit sur L1, soit éventuellement sur L2 à l’avenir), puis n’importe quelle copie de Portefeuille L2 peut lire la Clé secrète à partir de là. Cela signifie que la mise à jour ne doit être effectuée qu’une seule fois. Pour améliorer l’efficacité, le Keystore Portefeuille exige que L2 dispose d’une méthode normalisée pour lire les informations sur L1 sans frais ; il existe deux propositions à cet égard, à savoir L1S LOAD et REMOTESTATICCALL.

Le fonctionnement du portefeuille Keystore

2. Un concept plus radical de « pont Jeton partagé » : Imaginez un monde où tous les L2 sont un cumul de preuves de validité et où chaque emplacement est soumis à l’ETH. Même dans un tel monde, pour transférer des actifs d’une L2 à une autre dans son état d’origine, des retraits et des dépôts sont toujours nécessaires, ce qui implique de payer un montant important de frais de gaz L1. Une façon de résoudre ce problème est de créer un cumul partagé et minimaliste dont la seule fonction est de maintenir quel L2 possède chaque type de Jeton et combien de solde chacun possède, et permet à ces soldes d’être mis à jour en masse par le biais d’une série d’opérations d’envoi croisé L2 initiées par n’importe quel L2. Cela éliminera le besoin de transferts croisés L2 pour payer les frais de gaz L1 pour chaque transfert, ainsi que l’utilisation de technologies basées sur la liquidité telles que l’ERC-7683.

3. Composabilité synchronisée: permet les appels synchronisés entre L2 spécifiques et 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 à la chaîne :

ERC-3770 ：

ERC-7683:

RIP-7755:

Modèle de conception Portefeuille Scroll keystore:

Helios:

ERC-3668 (parfois appelé CCIP Read):

La proposition de Justin Drake pour « sur la base d’une pré-confirmation (partagée) » :

L1S LOAD (RIP-7728): load-precompile/20388

REMOTESTATICCALL dans Optimism:

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

Que reste-t-il à faire ? Quels compromis sont nécessaires ?

De nombreux exemples ci-dessus sont confrontés à des dilemmes de normalisation, à savoir quand normaliser et quels niveaux normaliser. Une normalisation trop précoce pourrait enraciner une solution inférieure. Trop tardive, elle pourrait entraîner une fragmentation inutile. Dans certains cas, il existe à la fois une solution temporaire avec des caractéristiques plus faibles mais plus facile à mettre en œuvre, et une solution « correcte à long terme » qui prendrait des années à réaliser.

Ces tâches ne sont pas seulement des problèmes techniques, mais aussi (voire principalement) des problèmes sociaux qui nécessitent 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 de nature «plus haut niveau», donc elles n’ont pas beaucoup d’impact sur le niveau L1. Une exception est le partage d’ordonnancement, qui a un impact significatif sur la valeur extractible maximale (MEV).

Étendre l’exécution sur L1

Quel problème résolvons-nous ?

Si L2 devient extrêmement scalable et réussi, mais que L1 ne peut toujours traiter qu’un volume très faible, 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 (plutôt qu’une L1 indépendante) seront affaiblies.

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

4. Si L2 échoue (par exemple, en raison d’un comportement malveillant ou d’une disparition de l’opérateur), les utilisateurs doivent toujours récupérer leurs actifs via L1. Par conséquent, L1 doit être suffisamment puissant pour traiter occasionnellement les tâches complexes et chaotiques de finition de L2.

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

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

La manière la plus simple d’étendre est d’augmenter directement la limite de gas. Cependant, cela peut rendre L1 plus centralisé, affaiblissant ainsi une autre caractéristique importante qui fait de l’ETH un L1 solide et fiable : sa crédibilité en tant que couche de base robuste. Il existe encore des controverses sur la mesure dans laquelle l’augmentation simple de la limite de gas est durable, et cela dépendra également des autres technologies mises en œuvre pour faciliter la validation de blocs plus importants (par exemple, l’expiration de l’historique, l’état sans état, la preuve de validité de l’EVM L1). Une autre chose importante qui doit continuer à être améliorée est l’efficacité du logiciel client ETH, 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 impliquera d’accélérer le développement de ces techniques de validation.

• EOF: Un nouveau format de bytecode EVM, plus convivial pour l’analyse statique et permettant une exécution plus rapide. Compte tenu de ces améliorations de l’efficacité, le bytecode EOF peut être exécuté avec des frais de gas plus bas.
• Tarification du gaz multidimensionnelle : des frais et des limites de base différents sont fixés pour le calcul, les données et le stockage, ce qui permet d’augmenter la capacité moyenne d’ETH L1 sans augmenter sa capacité maximale (évitant ainsi de nouveaux risques de sécurité).
• Les coûts en gaz des opcodes spécifiques de Goutte et pré-compilés - Historiquement, pour éviter les attaques par déni de service, nous avons augmenté à plusieurs reprises les coûts en gaz de certaines opérations sous-évaluées. Il y a encore plus à faire en termes de tarification des opcodes de Goutte trop élevés en gaz. Par exemple, l’addition est beaucoup moins chère que la multiplication, mais les coûts des opcodes ADD et MUL sont actuellement les mêmes. Nous pourrions réduire les coûts de l’ADD de Goutte et même rendre moins chers les opcodes plus simples comme PUSH. EOF est globalement plus optimisé à cet égard.
• EVM-MAX et SIMD : EVM-MAX est une proposition qui permet une arithmétique des grands nombres natifs plus efficace en tant que module distinct de l’EVM. Sauf intention explicite, les valeurs calculées par EVM-MAX ne peuvent être accessibles que par d’autres opcodes EVM-MAX. Cela permet d’avoir plus d’espace 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. Les deux peuvent être combinés pour créer un coprocesseur puissant à côté de l’EVM, qui peut être utilisé pour réaliser efficacement des opérations de chiffrement. Cela est particulièrement utile pour les protocoles de confidentialité et les systèmes de protection L2, ce qui contribuera à l’extension de L1 et de 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 les rollups intégrés) : essentiellement, créer de nombreuses copies parallèles de l’EVM en cours d’exécution, ce qui permet de produire un modèle équivalent à ce que les Rollups peuvent offrir, mais intégré de manière plus native au protocole.

Quels sont les liens avec les recherches existantes ?

• Roadmap de l’extension L1 d’ETH Polynya :
• Tarification du gaz multidimensionnel :
• EIP-7706:
• EOF:
• EVM-MAX:
• SIMD:
• Rollups natifs:
• Max Resnick interview sur la valeur de l’extension L1 :
• Justin Drake parle de l’extension avec SNARK et Rollups natifs

Que reste-t-il à faire et quels compromis faut-il faire ?

Il existe trois stratégies d’extension de couche 1, qui peuvent être effectuées de manière indépendante ou parallèle :

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

En comprenant ces différentes technologies, nous découvrons qu’elles ont chacune des compromis différents. Par exemple, les Rollups natifs ont de nombreux points faibles en matière 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 gaz affaiblira les autres avantages qu’une vérification simplifiée sur L1 peut offrir, tels que l’augmentation du nombre d’utilisateurs vérifiant les nœuds et le nombre de solo-stakers. Selon la manière dont cela est mis en œuvre, rendre certaines opérations spécifiques moins chères dans l’EVM (Machine virtuelle Ethereum) pourrait augmenter la complexité globale de l’EVM.

Un point majeur que tout plan de mise à l’échelle L1 doit aborder est le suivant : quels sont les objectifs finaux de L1 et de L2 ? Il est évident qu’il est absurde de tout mettre sur L1 : les cas d’utilisation potentiels pourraient impliquer des centaines de milliers de transactions par seconde, ce qui rendrait la vérification L1 totalement impossible (à moins que nous n’adoptions une approche de Rollup native). Cependant, nous avons effectivement besoin de principes directeurs pour nous assurer de ne pas nous retrouver dans une situation où une augmentation de 10 fois de la limite de gas compromet gravement la Décentralisation d’Ethereum L1.

Un point de vue sur la division du travail entre L1 et L2

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

Amener 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 (au lieu d’être simplement un problème de L2), ce qui rendra les besoins de gestion de MEV plus urgents. Cela augmentera considérablement la valeur du temps de slot rapide sur L1. Cela dépend également largement du bon déroulement de la vérification de L1 (the Verge).