Remarque : Ce document est la deuxième partie de la série d'articles intitulée « Futurs possibles pour le protocole Ethereum, partie 2 : La montée », récemment publiée par Vitalik, le fondateur d'Éther. La première partie a été publiée précédemment par Jinse Finance sous le titre « Quelles améliorations sont encore possibles pour le PoS d'Éther ? ». Traduit par Deng Tong de Jinse Finance, voici le texte intégral de la deuxième partie :

Au départ, le road map d'Ethereum comprenait deux stratégies d'expansion.

**L'un d'entre eux est "Sharding(sharding)" : chaque Nœud ne doit vérifier et stocker qu'une petite partie des transactions, au lieu de vérifier et stocker toutes les transactions de la chaîne. C'est également le fonctionnement de tout autre réseau pair à pair (par exemple BitTorrent), nous pouvons donc certainement faire fonctionner la blockchain de la même manière.

Un autre est le protocole de couche 2： Il s'agit d'un réseau qui fonctionne au-dessus de la chaîne Ethereum, ce qui lui permet de bénéficier pleinement de sa sécurité tout en maintenant la plupart des données et des calculs hors de la chaîne principale. Le terme "protocole de couche 2" fait référence aux canaux d'état de 2015, au Plasma de 2017 et aux rollups de 2019. Les rollups sont plus puissants que les canaux d'état ou le Plasma, mais ils nécessitent une bande passante de données hors chaîne importante.

Heureusement, d'ici 2019, la recherche sur le sharding avait résolu le problème de la validation à grande échelle de la «disponibilité des données». En conséquence, les deux voies ont été fusionnées pour donner une feuille de route centrée sur Rollup, qui reste la stratégie d'extension d'Ethereum à ce jour.

The Surge, version du plan de route 2023.

La feuille de route centrée sur Rollup propose une répartition simple : Ethereum L1 se concentre sur la création d'une couche de base puissante et décentralisée, tandis que L2 se charge d'aider à étendre l'écosystème. C'est un schéma qui se répète partout dans la société : le système judiciaire (L1) n'est pas conçu pour être ultra-rapide et efficace, mais pour protéger les contrats et les droits de propriété, tandis que les entrepreneurs (L2) doivent construire une base solide sur cette couche de base et emmener l'humanité vers Mars (au sens propre et figuré).

Cette année, la feuille de route centrée sur le Rollup a connu d’importants succès : la bande passante de données L1 d’ETH Place a été considérablement augmentée avec les blobs EIP-4844, et plusieurs Rollups EVM sont maintenant dans la première phase. L’implémentation très hétérogène et pluraliste du Sharding, dans laquelle chaque L2 agit comme un « shard » avec ses propres règles internes et sa propre logique, est désormais une réalité. Mais comme nous l’avons vu, emprunter cette voie comporte ses propres défis. Notre tâche consiste donc maintenant à compléter la feuille de route centrée sur le Rollup et à résoudre ces problèmes tout en conservant la robustesse et la décentralisation qui distinguent l’ETH Workshop L1. **

Surge: Objectif clé

L1+L2 上 100,000+ TPS

Maintenir la décentralisation et la robustesse de L1

Au moins certains L2 ont pleinement hérité des propriétés fondamentales d'Ethereum (Trustless, ouvert, résistant à la censure)

L'interopérabilité maximale entre les couches 2. Ethereum devrait se sentir comme un écosystème, pas comme 34 blockchains différentes.

Le dilemme des trois difficultés de l'évolutivité

La Trinité impie est une idée proposée en 2017 qui soutient qu'il existe une tension entre les trois attributs de la blockchain: la Décentralisation (plus précisément, le faible coût d'exécution des Nœuds), la Scalabilité (plus précisément, le traitement d'un grand nombre de transactions) et la Sécurité (plus précisément, les attaquants doivent détruire la plupart des Nœuds du réseau pour faire échouer une transaction unique).

Il est à noter que le dilemme trilemme n'est pas un théorème, et aucun message introduisant le dilemme trilemme n'est accompagné d'une preuve mathématique. Il donne une démonstration mathématique heuristique : si un nœud amical à la Décentralisation (comme un ordinateur portable de consommateur) 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 vu que par 1/k de nœuds, ce qui signifie qu'un attaquant n'a besoin que de briser quelques nœuds pour pousser des transactions malveillantes, ou (ii) vos nœuds deviendront puissants et votre chaîne ne sera pas Décentralisation. Le but de cet article n'a jamais été de montrer qu'il est impossible de briser le dilemme trilemme ; au contraire, il vise à montrer que c'est difficile de le briser - il faut sortir du cadre implicite de la démonstration pour réfléchir d'une manière ou d'une autre.

Au fil des ans, certains chaînes à haute performance ont souvent prétendu avoir résolu le trilemme sans prendre de mesures astucieuses au niveau de l'infrastructure, généralement en optimisant les nœuds grâce à des techniques d'ingénierie logicielle. Cela est toujours trompeur et l'exécution de nœuds sur de telles chaînes est toujours beaucoup plus difficile que sur Ethereum. Cet article explore de nombreux subtilités de la raison pour laquelle cela se produit (et pourquoi l'ingénierie logicielle du client L1 ne peut pas étendre Ethereum en soi).

Cependant, la combinaison de l'échantillonnage de la disponibilité des données (DAS) et de SNARK résout effectivement le dilemme des trois difficultés : elle permet à un client de vérifier si une certaine quantité de données est disponible et si un certain nombre d'étapes de calcul ont été correctement exécutées, tout en ne téléchargeant qu'une petite partie de ces données et en exécutant beaucoup moins de calculs. SNARK n'est pas digne de confiance. L'échantillonnage de la disponibilité des données présente un subtil modèle de confiance en un petit nombre de N, mais il conserve les propriétés fondamentales des chaînes non extensibles, de sorte qu'une attaque à 51 % ne peut pas forcer le réseau à accepter des blocs falsifiés.

Une autre façon de résoudre le dilemme des trois difficultés est l'architecture Plasma, qui utilise des technologies astucieuses pour déléguer la responsabilité de surveiller la disponibilité des données aux utilisateurs de manière incitative. Entre 2017 et 2019, lorsque la seule chose nécessaire pour étendre le calcul était une preuve de fraude, les fonctionnalités de sécurité de Plasma étaient très limitées, mais la popularisation de SNARK a rendu l'architecture Plasma plus adaptée à un éventail plus large de cas d'utilisation.

Progrès supplémentaires de DAS

Quel problème devons-nous résoudre?

À partir du 13 mars 2024, date à laquelle la mise à niveau de Dencun sera mise en service, la blockchain ETHFANG disposera de 3 « blobs » d’environ 125 Ko par période de 12 secondes, soit environ 375 Ko de bande passante de données par période de 12 secondes. En supposant que les données de transaction sont directement postées dans la chaîne, la transmission ERC20 est d’environ 180 octets, de sorte que le TPS maximum des cumuls sur le carré de l’ETH est de :

375000 / 12 / 180 = 173.6 TPS

Si nous ajoutons le calldata d'Ethereum (valeur maximale théorique : 30 millions de gaz par emplacement / 16 gaz par octet = 1 875 000 octets par emplacement), cela deviendra 607 TPS. Pour PeerDAS, nous prévoyons d'augmenter l'objectif de comptage du blob à 8-16, ce qui nous fournira un calldata de 463-926 TPS.

C'est une amélioration majeure par rapport à ETH L1, mais ce n'est pas suffisant. Nous voulons plus de scalabilité. Notre objectif à moyen terme est de 16 Mo par slot, ce qui nous donnera environ 58 000 TPS si combiné avec des améliorations de compression de données.

Qu'est-ce que PeerDAS et comment cela fonctionne-t-il?

PeerDAS est une mise en œuvre relativement simple de l'échantillonnage unidimensionnel. Chaque blob dans Ethereum est un polynôme de degré 4096 sur un corps de nombres premiers de 253 bits. Nous diffusons les 'parts' du polynôme, chaque part étant composée de 16 évaluations prises à 16 coordonnées adjacentes choisies parmi un ensemble total de 8192 coordonnées. N'importe quel ensemble de 4096 évaluations parmi les 8192 évaluations (en utilisant les paramètres actuellement recommandés : 64 parmi les 128 échantillons possibles) peut récupérer le blob.

PeerDAS fonctionne en demandant à chaque client d’écouter un petit nombre de sous-réseaux, où le i-ième sous-réseau diffuse le i-ième échantillon de n’importe quel blob, et demande en outre les blobs requis sur les autres sous-réseaux (qui écouteront sur différents sous-réseaux) en demandant aux homologues du réseau p2p global. Une version plus conservatrice de SubnetDAS utilise uniquement le mécanisme de sous-réseau et n’a pas de couche d’appairage de requêtes supplémentaire. **La recommandation actuelle est que les Nœuds participant à Preuve d’enjeu utilisent SubnetDAS, et que les autres Nœuds (c’est-à-dire les « clients ») utilisent PeerDAS. **

Théoriquement, nous pourrions mettre à l’échelle l’échantillonnage 1D assez loin : si nous augmentons le nombre maximum d’objets blob à 256 (d’où l’objectif de 128), alors nous atteindrons l’objectif de 16 Mo, tandis que l’échantillonnage de disponibilité des données ne coûtera que 16 échantillons par nœud * 128 blobs * 512 octets par blob par échantillon = 1 Mo de bande passante de données par emplacement. C’est exactement ce que nous tolérons : c’est faisable, mais cela signifie que les clients limités en bande passante ne peuvent pas échantillonner. Nous pouvons optimiser cela en réduisant le nombre d’objets blob et en augmentant la taille de l’objet blob, mais cela rend la reconstruction plus coûteuse.

Ainsi, finalement, nous voulons aller plus loin et effectuer un échantillonnage 2D, qui consiste non seulement à effectuer un échantillonnage aléatoire à l'intérieur du blob, mais aussi à effectuer un échantillonnage aléatoire entre les blobs. Les propriétés linéaires promises par KZG sont utilisées pour « étendre » l'ensemble de blobs dans le bloc en utilisant une nouvelle liste de « blobs virtuels » qui code la même information de manière redondante.

Échantillonnage 2D. Source: a16z

Il est crucial de noter que l'extension de l'engagement de calcul n'a pas besoin de blob, de sorte que cette solution est fondamentalement amicale pour la construction de blocs distribués. Les nœuds réels construisant des Blocs n'ont besoin que d'un engagement KZG de blob et peuvent s'appuyer sur DAS pour vérifier la disponibilité des blobs. 1D DAS est également très convivial pour la construction de blocs distribués.

Quels sont les liens avec les recherches existantes?

Article original sur la disponibilité des données (2018) :

Articles ultérieurs :

Post de l'interprète DAS, paradigme:

La disponibilité 2D promise par KZG :

PeerDAS sur ethresear.ch: et document:

EIP-7594:

SubnetDAS sur ethresear.ch:

Les subtils différences de récupérabilité dans l'échantillonnage 2D :

Que faut-il encore faire, que faut-il peser ?

La prochaine étape consiste à finaliser et à lancer l'implémentation de PeerDAS. À partir de là, l'augmentation continue du nombre de blobs sur PeerDAS est un travail progressif, tout en surveillant attentivement le réseau et en améliorant le logiciel pour assurer la sécurité. En même temps, nous espérons mener plus d'activités académiques sur l'interaction formelle de PeerDAS et d'autres versions de DAS, ainsi que sur la sécurité des règles de choix de fork.

À l’avenir, nous devons faire plus de travail pour déterminer la version idéale du DAS 2D et prouver ses fonctionnalités de sécurité. Nous voulons également migrer de KZG vers une alternative résistante au quantique et sans confiance. À l’heure actuelle, nous ne connaissons aucun candidat favorable aux constructions de blocs distribués. Même la technique « brute » coûteuse consistant à utiliser des STARK récursifs pour générer des preuves de validités qui reconstruisent des lignes et des colonnes n’est pas suffisante, car la taille de hachage du STARK est techniquement O(log(n) * log(log(n)) (avec STIR), alors qu’en fait le STARK est presque aussi grand que le blob entier.

À long terme, je pense que le chemin réel est:

• Outil 2D DAS idéal;
• Pour des raisons de simplicité et de robustesse, nous avons choisi d'utiliser le DAS 1D, sacrifiant ainsi l'efficacité de la bande passante d'échantillonnage et acceptant une limite de données plus basse.
• (axe dur) abandonner DA et adopter complètement Plasma comme notre principale couche 2 à suivre.

Nous pouvons envisager ces questions en évaluant les limites.

Veuillez noter que cette option existe toujours même si nous décidons d'étendre directement l'exécution sur L1. C'est parce que si L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux et les clients auront besoin d'un moyen efficace de les vérifier correctement, nous devons donc utiliser la même technologie (ZK-EVM et DAS) et L1 qui supporte Rollup.

Comment interagit-il avec les autres parties de la feuille de route ?

Si la compression des données est mise en œuvre (voir ci-dessous), la demande de 2D DAS sera réduite, ou du moins latence, si Plasma est largement utilisé, la demande de 2D DAS sera encore réduite. DAS pose également un défi à la construction et au protocole de blocs distribués : bien que DAS soit théoriquement convivial pour la reconstruction distribuée, dans la pratique, il doit être combiné avec des propositions de liste incluses et leur mécanisme de sélection de fork environnant.

Compression de données

Quel problème devons-nous résoudre?

Chaque transaction dans Rollup consomme beaucoup d'espace de données hors chaîne: le transfert ERC20 nécessite environ 180 octets. Même avec un échantillonnage idéal de la disponibilité des données, cela limitera la scalabilité du protocole de la deuxième couche. Chaque slot est de 16 Mo, nous obtenons donc:

16000000 / 12 / 180 = 7407 TPS

Que faire si nous pouvons résoudre non seulement le numérateur, mais aussi le dénominateur et réduire ainsi l'occupation en octets de chaque transaction dans Rollup hors de la chaîne ?

Qu'est-ce que c'est et comment ça fonctionne ?

Je pense que la meilleure explication est cette image d'il y a deux ans :

Le gain le plus simple est la compression de zéro octet : remplacer chaque séquence longue de zéro octet par deux octets représentant la quantité de zéro octet. De plus, nous exploitons les propriétés spécifiques de la transaction :

Agrégation de signatures - Nous sommes passés des signatures ECDSA aux signatures BLS, qui ont des propriétés qui peuvent combiner de nombreuses signatures pour former une seule signature qui prouve la validité de toutes les signatures originales. L1 n’en tient pas compte car le coût de calcul de la validation (même avec agrégation) est plus élevé, mais dans un environnement de données rares comme L2, ils ont du sens. Les capacités d’agrégation de l’ERC-4337 offrent un moyen d’y parvenir.

• Remplacer l'Adresse par un pointeur - Si l'Adresse a été utilisée auparavant, nous pouvons la remplacer par un pointeur de 4 octets pointant vers l'emplacement historique. Cela est nécessaire pour obtenir un rendement maximal, bien que cela nécessite des efforts pour être réalisé, car cela nécessite (au moins en partie) l'historique de la blockchain pour être efficacement intégré dans le réseau.
• Sérialisation personnalisée des valeurs de transaction - La plupart des valeurs de transaction ne comportent que quelques chiffres, par exemple 0,25 ETH est représenté par 250 000 000 000 000 000 wei. Le fonctionnement de Gas max-basefees et des frais de priorité est similaire. Nous pouvons donc utiliser un format décimal flottant personnalisé, voire un dictionnaire de valeurs particulièrement courantes, pour représenter de manière très compacte la plupart des valeurs de devise.

Quels sont les liens avec les recherches existantes?

Exploration from sequence.xyz:

Optimisation de Calldata pour les contrats L2, de ScopeLift :

Une autre stratégie - Rollup basé sur la preuve de validité (également appelé ZKRollup) qui différencie les états de publication au lieu des transactions: les empreintes de données-l2 sur.

Portefeuille BLS - Implémentation de l'agrégation BLS via ERC-4337 :

Que faut-il encore faire, que faut-il peser ?

Le principal travail restant consiste à concrétiser les plans ci-dessus. Le principal compromis est :

• Le passage à la signature BLS nécessite un effort considérable et peut entraîner une incompatibilité avec les puces matérielles de confiance qui améliorent la sécurité. Il peut être remplacé par un emballeur ZK-SNARK qui utilise d'autres schémas de signature.
• La compression dynamique (par exemple, remplacer Adresse par un pointeur) rend le code client plus complexe.
• Publier les différences d'état sur la chaîne au lieu des transactions peut garantir l'auditabilité et empêcher le bon fonctionnement de nombreux logiciels (tels que l'explorateur blockchain) si Goutte est utilisé.

Comment interagit-il avec les autres parties de la feuille de route ?

L'adoption de l'ERC-4337, ainsi que l'incorporation ultérieure d'une partie de son contenu dans le L2 EVM, peut grandement accélérer le déploiement de la technologie d'agrégation. L'incorporation d'une partie du contenu de l'ERC-4337 dans le L1 peut accélérer son déploiement sur le L2.

Plasma généralisé

Quel problème devons-nous résoudre?

Même avec un blob de 16 Mo et une compression de données, 58 000 TPS ne serait pas suffisant pour prendre en charge complètement les paiements des consommateurs, les réseaux sociaux décentralisés ou d'autres domaines à haute bande passante. Si nous commençons à prendre en compte la confidentialité, la situation devient encore plus complexe et pourrait réduire la scalabilité de 3 à 8 fois. Pour les applications à grande capacité et faible valeur, une option actuelle est le validium, qui place les données hors chaîne et dispose d'un modèle de sécurité intéressant où les opérateurs ne peuvent pas voler les fonds des utilisateurs, mais ils peuvent disparaître et geler temporairement ou définitivement les fonds de tous les utilisateurs. Mais nous pouvons faire mieux.

Qu'est-ce que c'est et comment ça fonctionne ?

Plasma est une solution d'extension qui implique que les opérateurs publient des Bloc hors de la chaîne et placent les racines de Merkle de ces Blocs off-chain (contrairement aux Rollups, qui placent tout le Bloc hors de la chaîne). Pour chaque Bloc, l'opérateur envoie une branche de Merkle à chaque utilisateur, prouvant que les actifs de cet utilisateur ont changé ou n'ont pas changé. Les utilisateurs peuvent récupérer leurs actifs en fournissant la branche de Merkle. Il est important que cette branche ne soit pas enracinée dans l'état le plus récent - ainsi, même en cas de défaillance de l'accessibilité des données, les utilisateurs peuvent récupérer leurs actifs en révoquant l'état le plus récent disponible. Si un utilisateur soumet une branche invalide (par exemple, se retirer des actifs qu'il a déjà envoyés à quelqu'un d'autre, ou l'opérateur créant des actifs à partir de rien), le mécanisme de défi off-chain peut décider à qui appartient cet actif.

Plasma Cash chaîne d'arbre. La transaction de dépense de jeton i est placée à la position i dans l'arbre. Dans cet exemple, en supposant que tous les arbres précédents sont valides, nous savons qu'Eve détient actuellement le jeton dur 1, David détient le jeton dur 4 et George détient le jeton dur 6.

Les premières versions de Plasma ne pouvaient traiter que des cas de paiement et ne pouvaient pas être efficacement promues. Cependant, si nous exigeons que chaque racine soit vérifiée à l'aide de SNARK, Plasma deviendra plus puissant. Chaque jeu de défi peut être considérablement simplifié car nous éliminons la plupart des chemins possibles de tricherie de l'opérateur. De nouveaux chemins sont également ouverts, permettant à la technologie Plasma de s'étendre à un plus large éventail de catégories d'actifs. Enfin, si l'opérateur ne triche pas, les utilisateurs peuvent retirer immédiatement des fonds sans attendre une période de défi d'une semaine.

Une méthode (non exclusive) pour créer une chaîne EVM Plasma : utiliser ZK-SNARK pour construire un arbre UTXO parallèle qui reflète les variations de solde effectuées par EVM et définir les différences uniques dans l'historique de mappage de ce qui est considéré comme "la même pièce". Ensuite, une structure Plasma peut être construite sur cette base.

Une idée importante est que le système Plasma n'a pas besoin d'être parfait. Même si vous ne pouvez protéger qu'une partie des actifs (par exemple, les Jetons qui n'ont pas été déplacés au cours de la dernière semaine), vous avez déjà grandement amélioré la situation de l'EVM super-évolutive, ce qui est une validation.

Un autre type de structure est une structure hybride Plasma/rollups, comme Intmax. Ces structures placent une quantité très faible de données hors chaîne pour chaque utilisateur (par exemple 5 octets), ce qui permet d'obtenir des propriétés intermédiaires entre Plasma et Rollup : dans le cas d'Intmax, vous pouvez obtenir un niveau très élevé de scalabilité et de confidentialité, même dans un monde de 16 Mo, la capacité théorique maximale est d'environ 16 000 000 / 12 / 5 = 266 667 TPS.

Quels sont les liens avec les recherches existantes?

Article Plasma original :

Plasma Cash:

Flux de trésorerie Plasma :

Intmax（2023）：

Que faut-il encore faire, que faut-il peser ?

La tâche principale restante est de mettre en production le système Plasma. Comme mentionné précédemment, la 'plasma vs validium' n'est pas une opposition binaire : tout validium peut au moins améliorer légèrement la sécurité en intégrant les fonctionnalités Plasma dans le mécanisme de sortie. La partie recherche vise à obtenir les meilleures propriétés de l'EVM (en termes d'exigences de confiance, de coût en gaz L1 dans le pire des cas et de vulnérabilité aux attaques DoS) ainsi qu'une structure spécifique à l'application alternative. De plus, le concept de Plasma est plus complexe que celui des rollups et nécessite une recherche et une construction directes pour mettre en place un cadre général plus solide.

Le principal inconvénient de l'utilisation de la conception Plasma est qu'elle dépend davantage des opérateurs et est plus difficile à « baser », bien que la conception mixte Plasma/rollup puisse généralement éviter ce point faible.

Comment interagit-il avec les autres parties de la feuille de route ?

Plus efficace est la solution Plasma, moins la pression sur les performances des données haute disponibilité de L1. Déplacer les activités vers L2 peut également réduire la pression MEV sur L1.

Système de preuve de L2 mature

Quel problème devons-nous résoudre?

Actuellement, la plupart des rollups ne sont pas encore trustless; il existe un conseil de sécurité capable de renverser les actions du système de preuve (optimiste ou de validité). Dans certains cas, le système de preuve peut même ne pas exister du tout, ou s'il existe, il n'a qu'une fonction de « consultation ». Les plus avancés sont (i) certains rollups spécifiques à des applications telles que FUEL, qui sont trustless, et (ii) Optimism et Arbitrum, qui sont tous deux des rollups EVM complets et qui ont atteint certains jalons trustless appelés « phase 1 » au moment de la rédaction de cet article. Les rollups ne progressent pas davantage en raison de la crainte de bugs dans le code. Nous avons besoin de rollups trustless, donc nous devons aborder ce problème de front.

Qu'est-ce que c'est et comment ça fonctionne ?

Tout d'abord, revenons sur le système "stage" présenté initialement dans cet article. Il y a des exigences plus détaillées, mais voici un résumé :

• Phase 0: Users must be able to run Nœud and synchronize the chain. If the verification is fully trusted/centralized, it will be sufficient.
• Première étape : Il doit y avoir un système de preuve (Trustless) pour s'assurer que seules les transactions valides sont acceptées. Il est permis d'avoir un comité de sécurité qui peut renverser le système de preuve, mais avec un seuil de vote de 75 % seulement. De plus, un nombre légal de membres du conseil empêchant une partie (c'est-à-dire plus de 26 %) doit être en dehors des principales entreprises construisant le Rollup. Il est permis d'utiliser un mécanisme de mise à niveau moins puissant (comme un DAO), mais avec une latence suffisamment longue pour permettre aux utilisateurs de retirer leurs fonds avant que la mise à niveau malveillante ne soit approuvée et mise en ligne. Étape 2 : Il doit y avoir un système d’attestation (sans confiance) pour s’assurer que seules les transactions valides sont acceptées. Le Conseil n’est autorisé à intervenir que s’il y a une erreur prouvable dans le code, par exemple. Si deux systèmes d’attestation redondants sont incohérents l’un avec l’autre, ou si un système d’attestation accepte deux racines post-état différentes pour le même élément (ou n’accepte rien pendant une période suffisamment longue, par exemple une semaine). Les mécaniques d’amélioration sont autorisées, mais doivent avoir de longues latences.

Notre objectif est d'atteindre la deuxième étape. Le principal défi de cette étape est d'acquérir suffisamment de confiance pour prouver que le système est réellement digne de confiance. Il existe deux principales façons d'y parvenir :

• Validation de forme : Nous pouvons utiliser les mathématiques modernes et la technologie informatique pour prouver (optimiste ou efficace) que le système de preuve ne prend en charge que les Blocs conformes à la spécification EVM. Ces technologies existent depuis des décennies, mais des progrès récents (comme Lean 4) les rendent plus pratiques, et les progrès de la preuve assistée par l'intelligence artificielle pourraient accélérer cette tendance.
• Multisignataire : Créer un système de multisignature et investir des fonds dans ces systèmes de signature multiple à 2 ou 3 (ou plus) entre les comités de sécurité (et/ou d'autres outils de confiance tels que TEE) ayant des hypothèses de confiance. Si le système de signature multiple est d'accord, le conseil de sécurité n'a pas de pouvoir. S'ils ne sont pas d'accord, le conseil de sécurité ne peut choisir qu'une seule option, et ne peut pas imposer unilatéralement sa propre réponse.

Le schéma programmé de preuve de validité combine un système de preuve d'optimisme, un système de preuve de validité et un comité de sécurité.

Quels sont les liens avec les recherches existantes?

Sémantique EVM K (travail de validation officiel depuis 2017)：

Présentation sur l'idée des preuves multiples (2022) :

Le plan Taiko utilise des preuves multiples :

Que faut-il encore faire, que faut-il peser ?

Il existe de nombreuses approches pour la vérification formelle. Nous devons créer une version de vérification formelle du prouveur SNARK de l'EVM complet. C'est un projet extrêmement complexe, bien que nous ayons déjà commencé. Il y a une astuce qui peut simplifier considérablement la tâche : nous pouvons créer un prouveur SNARK de vérification formelle pour la plus petite Machine virtuelle, par exemple RISC-V ou Cairo, puis écrire une implémentation de l'EVM dans cette plus petite VM (et prouver formellement son équivalence avec d'autres spécifications de l'EVM).

Pour les multi-signataires, il reste deux parties principales. Tout d'abord, nous devons avoir suffisamment confiance dans au moins deux systèmes de preuve différents, chacun étant assez sûr et s'effondrant pour des raisons différentes et non liées s'ils s'effondrent (de sorte qu'ils ne s'effondrent pas simultanément). Deuxièmement, nous devons obtenir une garantie de très haut niveau dans la logique sous-jacente de la combinaison des systèmes de preuve. C'est un petit bout de code. Il y a plusieurs façons de le rendre très petit - il suffit de stocker les fonds dans un contrat de sécurité multi-signature dont les signataires sont des contrats représentant des systèmes de preuve individuels - mais cela entraîne des coûts élevés en gas hors-chaîne. Il est nécessaire de trouver un équilibre entre efficacité et sécurité.

Comment interagit-il avec les autres parties de la feuille de route ?

Le déplacement de l'activité vers L2 peut réduire la pression de l'EMV sur L1.

Amélioration de l'interopérabilité entre L2 transversaux

Quel problème devons-nous résoudre?

Un grand défi de l'écosystème L2 aujourd'hui est la difficulté pour les utilisateurs de le manipuler. De plus, les méthodes les plus simples réintroduisent souvent des hypothèses de confiance : des ponts centralisés, des clients RPC, etc. Si nous prenons au sérieux l'idée que L2 fait partie de l'écosystème Ethereum, nous devons faire en sorte que l'utilisation de l'écosystème L2 soit aussi fluide que l'utilisation de l'écosystème Ethereum unifié.

Un exemple pathologiquement mauvais (voire dangereux : j'ai personnellement perdu 100 dollars en raison d'un mauvais choix de chaîne ici) de l'interopérabilité L2 - bien que ce ne soit pas la faute de Polymarket, l'interopérabilité L2 devrait être la responsabilité de la communauté Portefeuille et de l'ERC (Ethereum) standard. Dans un écosystème Ethereum fonctionnant correctement, l'envoi de jetons de L1 à L2 ou d'un L2 à un autre L2 devrait être aussi simple que l'envoi de jetons dans le même L1.

Qu'est-ce que c'est et comment ça fonctionne ?

Il existe plusieurs types d'améliorations d'interopérabilité L2. En général, la méthode pour aborder ces problèmes consiste à remarquer que théoriquement, l'ETH centré sur Rollup est similaire à l'exécution de Sharding sur L1, puis à demander dans quels domaines la version L2 actuelle de l'ETH diffère de l'idéal en pratique. Voici quelques exemples :

• Adresse spécifique à la chaîne : Pour les chaînes (L1, Optimism, Arbitrum...), l'adresse devrait faire partie de l'Adresse. Une fois cela réalisé, il suffit de placer l'adresse dans le champ « envoyer » pour effectuer le processus d'envoi inter-chaînes. Le Portefeuille peut déterminer en interne comment effectuer l'envoi (y compris l'utilisation du protocole de pontage).
• Demande de paiement spécifique à la chaîne : La création d'un message sous la forme "Envoyez-moi X Jeton de type Y off-chain" devrait être simple et normalisée. Il existe deux cas d'utilisation principaux : (i) les paiements, qu'il s'agisse de transactions entre personnes ou de services entre personnes et commerçants, et (ii) les dapps demandant des fonds, par exemple l'exemple de Polymarket mentionné ci-dessus.
• **Interaction cross-chain交换和 Gas 支付：**Il devrait y avoir un protocole ouvert standardisé pour exprimer les opérations d'interaction cross-chain, telles que "J'envoie 1 ETH sur Optimism à quelqu'un qui envoie 0,9999 ETH sur Arbitrum", et "J'envoie 0,0001 ETH sur Optimism à quiconque inclut cette transaction sur Arbitrum". ERC-7683 est une tentative pour le premier cas, tandis que RIP-7755 est une tentative pour le second, bien que les deux soient plus généraux que ces cas d'utilisation spécifiques.
• light client： Les utilisateurs devraient être en mesure de vérifier concrètement la chaîne avec laquelle ils interagissent, plutôt que de simplement faire confiance aux fournisseurs RPC. Helios de A16z Cryptomonnaie a réalisé cela pour Ethereum 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 de tête ETH d'un light client. Une fois que vous avez la chaîne de 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 préalable) pour vérifier n'importe quel objet d'état sur L2. Helios a déjà réalisé le premier. Étendre à ce dernier est un défi de normalisation.

• Portefeuille de clés secrètes: Aujourd'hui, si vous souhaitez mettre à jour la clé secrète qui contrôle le smart contracts portefeuille, vous devez effectuer cette opération sur les N copies du portefeuille sur l'off-chain. La bibliothèque de clés secrètes de portefeuille est une technologie qui permet à la clé secrète d'exister à un endroit (sur L1 ou peut-être plus tard sur L2) et d'être lue à partir de n'importe quelle copie de portefeuille L2. Cela signifie que la mise à jour n'a besoin de se produire qu'une seule fois. Pour une efficacité maximale, la bibliothèque de clés secrètes de portefeuille nécessite une manière normalisée de lire L1 sans coût sur L2 ; deux suggestions à cet effet sont L1SLOAD et REMOTESTATICCALL.

Comment fonctionne le graphique programmé de la clé secrète Portefeuille.

• Idée plus radicale de "pont Jeton partagé" : Imaginez un monde où tous les L2 sont des preuves de validité Rollup, chaque slot étant dédié à Ethereum. Même dans ce monde, le transfert d'actifs "locaux" d'un L2 à un autre nécessite toujours des retraits et des dépôts, ce qui entraîne des frais élevés de gas L1. Une façon de résoudre ce problème est de créer un Rollup partagé minimal dont la seule fonction est de maintenir l'équilibre des Jetons de différents types dans chaque L2 et de permettre la mise à jour collective de ces soldes via une série de transactions croisées initiées par n'importe quel L2. Cela permettrait des transferts inter-L2 sans avoir à payer des frais de gas L1 à chaque transaction, et sans dépendre de fournisseurs de liquidité techniques (tels que ERC-7683).
• Composabilité synchrone : permet des appels synchrones entre des L2 spécifiques et des L1 ou entre plusieurs L2. Cela peut contribuer à améliorer l'efficacité financière du protocole defi. Le premier peut être réalisé sans aucune coordination inter-L2 ; le second nécessite un partage de séquençage. Tout cela est automatiquement pris en charge par Rollup.

Quels sont les liens avec les recherches existantes?

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

ERC-7683：

RIP-7755：

Conception de la bibliothèque de clés déroulante Portefeuille :

Helios:

ERC-3668 (parfois appelé CCIP-read) :

La proposition de Justin Drake sur la "pré-confirmation basée sur le partage" :

L1SLOAD (RIP-7728):

Appels distants dans l'optimisme :

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

Que faut-il encore faire, que faut-il peser ?

De nombreux exemples ci-dessus sont confrontés à la question de la normalisation et des difficultés de normalisation à quelles couches. Si la normalisation intervient trop tôt, vous risquez de vous retrouver avec des solutions de mauvaise qualité. Si la normalisation intervient trop tard, cela peut entraîner une fragmentation inutile. Dans certains cas, il existe à la fois des solutions temporaires avec des performances plus faibles mais plus faciles à mettre en œuvre, et des solutions à long terme qui sont "correctes" mais qui prennent beaucoup de temps à mettre en place.

Ce qui rend cette section unique, c'est que ces tâches ne sont pas seulement des problèmes techniques : ce sont également (et peut-être surtout !) des problèmes sociaux. Ils nécessitent la collaboration de L2 et de Portefeuille ainsi que de L1. Notre capacité à résoudre avec succès ce problème est un test de notre capacité à rester unis en tant que communauté.

Comment interagit-il avec les autres parties de la feuille de route ?

La plupart des suggestions dans ces propositions sont des structures de niveau supérieur et n'affecteront donc pas beaucoup la considération L1. Une exception est le tri partagé, qui a un impact important sur le MEV.

Étendre l’exécution sur L1

Quel problème devons-nous résoudre?

Si L2 devient très évolutive et réussie, mais que L1 ne peut toujours traiter qu'un nombre très limité de transactions, Ethereum pourrait présenter de nombreux risques :

• La situation économique des actifs ETH devient de plus en plus dangereuse, ce qui affecte la sécurité à long terme du réseau.
• De nombreux L2 bénéficient d'une étroite connexion avec l'écosystème financier hautement développé de L1, et si cet écosystème est considérablement affaibli, la motivation pour L2 de devenir autonome (plutôt que dépendant de L1) diminuera.
• Il faut beaucoup de temps pour que L2 puisse avoir la même garantie de sécurité que L1.
• Si L2 rencontre un problème (par exemple, en raison d'une manipulation malveillante ou de la 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 puissant pour pouvoir occasionnellement gérer réellement la complexité et la confusion élevées de L2.

Pour ces raisons, l'extension continue de L1 elle-même et de s'assurer qu'elle peut continuer à s'adapter à de plus en plus d'utilisations est très précieuse.

Qu'est-ce que c'est et comment ça fonctionne ?

La méthode d'extension la plus simple consiste simplement à augmenter la limite de gaz. Cependant, cela comporte le risque de centralisation de la couche L1, ce qui affaiblit une autre caractéristique importante qui rend Ethereum L1 si puissant : sa crédibilité en tant que couche de base puissante. Il y a eu un débat constant sur la mesure dans laquelle une augmentation simple de la limite de gaz est durable, et cela évoluera également en fonction de la mise en œuvre d'autres technologies pour faciliter la vérification de blocs plus importants (par exemple, les preuves d'expiration historique, sans état, preuve de validité L1 EVM). Une autre chose importante qui doit être constamment améliorée est l'efficacité du logiciel client Ethereum, qui est aujourd'hui plus optimisé qu'il y a cinq ans. Une stratégie efficace d'augmentation de la limite de gaz L1 impliquera d'accélérer ces technologies de vérification.

Une autre stratégie d'expansion implique l'identification de fonctionnalités et de types de calcul spécifiques qui peuvent devenir moins chers sans compromettre la décentralisation du réseau ou ses propriétés de sécurité. Des exemples incluent :

• EOF - Un nouveau format de bytecode EVM, plus convivial pour l'analyse statique, permettant une mise en œuvre plus rapide. Compte tenu de cette efficacité, le bytecode EOF peut avoir un coût en gas plus faible.
• Tarification du gaz multidimensionnelle - Établir des frais de base distincts ainsi que des limites pour les calculs, les données et le stockage peut augmenter la capacité moyenne de la couche L1 d'Ethereum, sans augmenter sa capacité maximale (et donc créer de nouveaux risques de sécurité).
• OpCodes spécifiques à Goutte et coûts de gaz pré-compilés - Dans le passé, nous avons déjà augmenté les coûts en gaz pour certaines opérations sous-évaluées afin de prévenir les attaques par déni de service. Nous avons fait moins de choses mais nous pouvons en faire plus, comme réduire les coûts en gaz des opérations coûteuses de Goutte. Par exemple, l'addition est beaucoup moins chère que la multiplication, mais les opCodes ADD et MUL ont actuellement le même coût. Nous pouvons rendre ADD moins cher et même rendre les opCodes plus simples (comme PUSH) moins chers. EOF est globalement plus comparé.
• EVM-MAX et SIMD : EVM-MAX (« Extension modulaire de l'arithmétique ») est une proposition qui permet une arithmétique modulaire de grands nombres plus efficace en tant que module distinct de l'EVM. Les valeurs calculées par EVM-MAX ne peuvent être accessibles que par d'autres opcodes EVM-MAX, à moins d'être intentionnellement exportées ; cela permet d'avoir un espace plus important pour stocker ces valeurs dans un format optimisé. SIMD (« Single Instruction, Multiple Data ») est une proposition qui permet d'exécuter efficacement la même instruction sur des tableaux de valeurs. Ensemble, ils peuvent créer un puissant coprocesseur avec l'EVM, ce qui permet de réaliser des opérations de chiffrement plus efficacement. Cela est particulièrement utile pour les protocoles de confidentialité et les systèmes de preuve de L2, contribuant ainsi à l'extension des couches L1 et L2.

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

Enfin, la troisième stratégie est le Rollup natif (ou "Rollup intégré, enshrined rollups") : essentiellement, la création de nombreuses copies parallèles de l'EVM en cours d'exécution, formant ainsi un modèle équivalent au modèle que Rollup peut offrir, mais intégré de manière plus native dans le protocole.

Quels sont les liens avec les recherches existantes?

La feuille de route de Polynya pour l'expansion de la couche L1 d'Éther :

Tarification du gaz multidimensionnelle:

EIP-7706:

EOF：

EVM-MAX：

SIMD :

Rollup natif :

Interview de Max Resnick sur la valeur de l'extension L1 :

Justin Drake sur l'extension en utilisant SNARK et Rollup natif :

Que faut-il encore faire, que faut-il peser ?

L'extension L1 a trois stratégies qui peuvent être exécutées séparément ou en parallèle :

• Les améliorations techniques (telles que le code client, le client sans état, l'historique expiré) rendent la vérification de L1 plus facile, puis augmentent la limite de gas
• Augmenter le coût spécifique des opérations Goutte, sans augmenter les risques de pire des cas, pour augmenter la capacité moyenne
• Rollup natif (c'est-à-dire "création de N copies parallèles de l'EVM", bien qu'il puisse offrir une grande flexibilité aux développeurs en ce qui concerne les paramètres de déploiement des copies)

Il est important de comprendre que ce sont des technologies différentes avec des compromis différents. Par exemple, le Rollup natif a de nombreuses faiblesses similaires au Rollup classique en termes de composabilité : vous ne pouvez pas envoyer une seule transaction pour exécuter des opérations synchronisées sur plusieurs transactions, comme vous le feriez pour traiter un contrat sur le même L1 (ou L2). Augmenter la limite de Gas priverait des avantages supplémentaires, tels que l'augmentation du nombre d'utilisateurs exécutant des nœuds de vérification et l'augmentation des déposants individuels, en facilitant la vérification de L1. Rendre certaines opérations spécifiques de l'EVM moins coûteuses (selon la manière dont elles sont effectuées) pourrait augmenter la complexité globale de l'EVM.

Une grande question à laquelle tout plan d'extension L1 doit répondre est: quelle est la vision finale de L1 et L2? Il est évident que tout faire sur L1 est absurde: les cas d'utilisation potentiels impliquent des centaines de milliers de transactions par seconde, ce qui rendrait L1 incapable de les valider (à moins d'adopter la voie native du Rollup). Mais nous avons besoin de quelques principes directeurs pour nous assurer que nous ne nous retrouvons pas dans une situation où nous augmentons les limitations de gaz de 10 fois, ce qui nuirait gravement à la décentralisation de l'ETH L1, et constaterions que nous ne faisons que passer d'un monde où 99% des activités se déroulent sur L1 à un monde où 90% des activités se déroulent sur L2, ce qui donne des résultats presque identiques, à l'exception de la perte irréversible de la majeure partie de la spécificité de l'ETH L1.

Une proposition de point de vue sur la «répartition des tâches» entre L1 et L2

Comment interagit-il avec les autres parties de la feuille de route ?

Faire entrer plus d'utilisateurs dans L1 signifie non seulement améliorer l'échelle, mais aussi améliorer d'autres aspects de L1. Cela signifie que plus de MEV seront conservés dans L1 (au lieu de simplement devenir un problème de L2), il est donc plus urgent de le traiter de manière explicite. Cela augmente considérablement la valeur des slots rapides sur L1. Il dépend également largement de la fluidité de la validation sur L1 (« The Verge »).

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