Nouveau document de Vitalik : L'avenir potentiel d'ETH, la montée en puissance

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

Au début, le plan de route d’Ethereum comportait deux stratégies d’extension. L’un (voir un article précoce de 2015) est le « Sharding » (sharding) : chaque nœud Nœud doit uniquement vérifier et stocker une petite partie des transactions, au lieu de vérifier et stocker toutes les transactions de la chaîne. Tout autre réseau pair à pair (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 est le protocole Layer2 : ces réseaux se situeront au-dessus d’Ethereum pour lui permettre de bénéficier pleinement de sa sécurité, tout en maintenant la majeure partie des données et des calculs en dehors de la 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 large bande passante de données hors chaîne. Heureusement, d’ici 2019, la recherche sur le Sharding avait résolu le problème de la « disponibilité des données » à grande échelle. En conséquence, les deux voies se sont fusionnées et nous avons obtenu une feuille de route centrée sur le Rollup, qui reste la stratégie d’extension d’Ethereum aujourd’hui.

The Surge，2023 路线图版

La feuille de route centrée sur Rollup propose une simple répartition des tâches : 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 répandu dans la société : l’existence du système judiciaire (L1) n’est pas axée sur la vitesse et l’efficacité maximales, mais sur 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 au sens propre ou figuré.

Cette année, la feuille de route centrée sur Rollup a connu des avancées importantes : avec le déploiement de la proposition EIP-4844, la bande passante des données de la couche L1 d’ETH a considérablement augmenté, et plusieurs Rollup de Machine virtuelle Ethereum (EVM) sont maintenant dans la phase initiale. Chaque couche L2 existe en tant que « 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 le constatons, emprunter cette voie présente également des défis uniques. Par conséquent, notre mission actuelle est de finaliser la feuille de route centrée sur Rollup et de résoudre ces problèmes, tout en préservant la robustesse et la décentralisation propres à la couche L1 d’ETH.

La Surge: Objectif clé

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

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

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

4. Ethereum devrait se sentir comme un écosystème unifié et non pas comme 34 chaînes de blocs différentes.

Contenu de ce chapitre

1. Le paradoxe de la triade de scalabilité

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

3. Compression de données

4.Generalized Plasma

5. Système de preuve L2 mature

6. Amélioration de l’interopérabilité L2 croisée

7. Étendre l’exécution sur L1

Le paradoxe du triangle de la scalabilité

Le paradoxe triangulaire 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 : la Décentralisation (plus précisément, le faible coût d’exploitation des Nœuds), la scalabilité (traiter un grand nombre de transactions) et la sécurité (les attaquants doivent perturber une grande partie des Nœuds du réseau pour faire échouer une seule transaction).

Il est à noter que le paradoxe du triangle n’est pas un théorème, et les messages introduisant le paradoxe du triangle ne sont pas accompagnés d’une preuve mathématique. Il propose 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 n’a besoin de perturber qu’un petit nombre de nœuds pour effectuer une transaction malveillante, ou (ii) vos nœuds deviendront puissants, mais votre chaîne ne sera pas décentralisée. L’objectif de cet article n’est pas de prouver qu’il est impossible de briser le paradoxe du triangle ; au contraire, il vise à montrer que briser le paradoxe du triangle est difficile et nécessite de sortir partiellement du cadre de pensée implicite de cet argument.

Au fil des ans, certains réseaux à haute performance ont souvent prétendu avoir résolu le paradoxe trilemme sans modifier fondamentalement l’architecture, généralement en optimisant les nœuds grâce à des techniques de génie logiciel. Cela est toujours trompeur, car il est beaucoup plus difficile d’exécuter des nœuds off-chain que des nœuds sur la chaîne 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 et des SNARKs résout effectivement le paradoxe du triangle : 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 téléchargeant uniquement une petite quantité de données et en effectuant un nombre très limité de calculs. Les SNARKs ne nécessitent pas de confiance. L’échantillonnage de disponibilité des données a un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales de la chaîne non scalable, c’est-à-dire que même une attaque à 51% ne peut pas forcer le réseau à accepter des blocs invalides.

Une autre méthode pour résoudre le dilemme des trois difficultés est l’architecture Plasma, qui utilise une technologie astucieuse pour inciter les utilisateurs à surveiller la disponibilité des données de manière compatible. Au cours des années 2017-2019, lorsque nous n’avions que la preuve de fraude 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 à connaissance nulle), l’architecture Plasma est devenue plus viable pour des cas d’utilisation plus larges qu’avant.

Les progrès supplémentaires de 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 à jour, il y aura environ 3 blocs de 125 kB toutes les 12 secondes sur la chaîne Ethereum, soit une bande passante disponible d’environ 375 kB par bloc. En supposant que les données de transaction soient publiées directement hors chaîne, le transfert ERC20 prend environ 180 octets. Par conséquent, le maximum de TPS sur Rollup sur Ethereum est de : 375000 / 12 / 180 = 173,6 TPS.

Si nous ajoutons calldata d’ETH (valeur théorique maximale : 30 millions de gaz par slot / 16 gaz 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 avancée 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, combiné à l’amélioration de la compression des données Rollup, apportera environ ~58000 TPS.

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 champ de nombres premiers de 253 bits. Nous diffusons des parts du polynôme, chaque part contenant 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 proposés actuellement : 64 parmi les 128 échantillons possibles) peut récupérer le blob.

Le fonctionnement de PeerDAS consiste à faire en sorte que chaque client écoute un petit nombre de sous-réseaux, où le sous-réseau i diffuse tout échantillon i de blob et demande les autres blobs des sous-réseaux dont il a besoin en interrogeant les pairs dans le réseau P2P mondial qui écoutent différents sous-réseaux. Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme de sous-réseau sans l’interrogation supplémentaire de la couche de pairs. La proposition actuelle est que les Nœuds participant à l’Attestation de droits d’accès utilisent SubnetDAS, tandis que les autres Nœuds (c’est-à-dire les clients) utilisent PeerDAS.

En théorie, nous pourrions étendre l’échelle de l’échantillonnage 1D à une échelle considérable : si nous augmentons le nombre maximum de blobs à 256 (ciblant 128), nous pourrions atteindre l’objectif de 16 Mo, avec une bande passante de 1 Mo par slot pour l’échantillonnage de la disponibilité des données, soit 16 échantillons par Nœud * 128 blobs * 512 octets par échantillon de blob. Cela est à peine tolérable : c’est faisable, mais cela signifie que les clients à bande passante limitée ne peuvent pas échantillonner. Nous pourrions optimiser cela dans une certaine mesure en réduisant le nombre de blobs et en augmentant leur taille, mais cela augmenterait le coût de reconstruction.

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

Par conséquent, nous voulons aller plus loin, en effectuant un échantillonnage 2D, qui non seulement à l’intérieur de chaque bloc, mais également entre les blocs. Les propriétés linéaires promises par KZG sont utilisées pour étendre un ensemble de blocs, contenant une nouvelle liste de blocs virtuels avec un encodage redondant des mêmes informations.

2D échantillonnage. Source: 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 amicale pour la construction de blocs distribués. Les nœuds construisant réellement le bloc 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 à une dimension (1D DAS) est également essentiellement favorable à la construction de blocs distribués.

Quels sont les liens avec les recherches existantes?

1. Introduction to the original post on data availability (2018):

2. Document de suivi:

3. Explication de DAS, paradigme:

4. Disponibilité 2D avec engagement KZG :

PeerDAS sur 5.ethresear.ch : Et papier :

6.EIP-7594:

SubnetDAS sur ethresear.ch:

8.2D Les subtilités récupérables de l’échantillonnage :

Que faut-il encore faire ? Quels compromis sont encore nécessaires ?

Ensuite, nous allons terminer la mise en œuvre et le déploiement de PeerDAS. Ensuite, nous augmenterons continuellement le nombre de blobs sur PeerDAS tout en surveillant attentivement le réseau et en améliorant le logiciel pour assurer la sécurité, ce qui 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 leurs règles de choix de fork et 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.

Ma vision à long terme de la réalité est :

1. Mettre en œuvre un DAS 2D idéal ;

2. Persistez à utiliser 1D DAS, sacrifiant l’efficacité de la largeur de bande d’échantillonnage pour accepter une limite de données plus basse pour la simplicité et la robustesse.

3. (Pivot dur) Abandonner DA et adopter complètement Plasma comme notre architecture principale Layer2 à suivre.

Veuillez noter que même si nous décidons d’étendre directement l’exécution au niveau L1, cette option est également disponible. Cela est dû au fait que si le niveau L1 doit traiter un grand nombre de TPS, le bloc L1 deviendra très grand et les clients souhaiteront avoir un moyen efficace de vérifier leur véracité, nous devrons donc utiliser au niveau L1 les mêmes technologies que Rollup (comme ZK-EVM et DAS).

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

Si la compression de données est mise en œuvre, la demande de 2D DAS diminuera ou du moins sera sujette à latence, et si Plasma est largement utilisé, la demande diminuera encore plus. DAS pose également des défis à la construction de protocoles et de mécanismes de Blocs distribués : bien que DAS soit théoriquement favorable à la reconstruction distribuée, cela nécessite en pratique une combinaison avec des propositions d’inclusion de paquets et des mécanismes de sélection de fork environnants.

Compression des données

Quel problème résolvons-nous ?

Chaque transaction dans Rollup occupe un espace considérable de données hors chaîne : le transfert d’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 :

16000000 / 12 / 180 = 7407 TPS

Que se passerait-il si nous pouvions résoudre non seulement le problème du numérateur, mais également le problème du dénominateur, en réduisant le nombre de bytes utilisés hors chaîne pour chaque transaction dans Rollup ?

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

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

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

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

Remplacer Adresse par des pointeurs : si une Adresse a déjà été utilisée, 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 maximaux et les frais de priorité 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. Explorer sequence.xyz:

2. Optimisation du contrat L2 Calldata :

3. Les Rollups basés sur la preuve de validité (également appelés ZK rollups) publient des différences d’état plutôt que des transactions:

4. Portefeuille BLS - Agrégation BLS mise en œuvre via ERC-4337 :

Qu’est-ce qu’il reste à faire et quels compromis faut-il faire ?

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

1、Le passage à la signature BLS nécessite beaucoup d’efforts et peut être remplacé par un emballage ZK-SNARK utilisant d’autres schémas de signature, ce qui peut améliorer la sécurité et la compatibilité 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 hors chaîne plutôt que dans les transactions peut réduire l’auditabilité et empêcher le fonctionnement de nombreux logiciels (tels que les explorateurs de blocs).

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

En utilisant ERC-4337 et en fin de compte en incorporant une partie de son contenu dans L2 EVM, le déploiement de la technologie d’agrégation 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 avec un blob de 16 Mo et une compression de données, 58 000 TPS ne suffiront peut-être pas à répondre pleinement aux besoins des domaines à haute bande passante tels que les paiements des consommateurs, la Décentralisation sociale ou autres, en particulier lorsque nous commençons à considérer la confidentialité, ce qui pourrait améliorer la Goutte de l’évolutivité de 3 à 8 fois. Pour les applications à forte volume et faible valeur, une option actuelle est d’utiliser Validium, qui stocke les données hors chaîne et utilise un modèle de sécurité intéressant: les opérateurs ne peuvent pas voler les fonds des utilisateurs, mais ils peuvent geler temporairement ou définitivement 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 scaling, qui implique qu’un opérateur publie des blocs hors chaîne (off-chain), et place les racines de Merkle de ces blocs hors chaîne (à la différence de Rollup, qui place des blocs complets hors chaîne). Pour chaque bloc, l’opérateur envoie à chaque utilisateur une branche de Merkle pour prouver que les actifs de cet utilisateur ont subi des changements, ou n’ont pas subi de changements. 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’être basée sur l’état le plus récent. Par conséquent, même en cas de problème de disponibilité des données, les utilisateurs peuvent toujours récupérer leurs actifs en utilisant le dernier état disponible. Si un utilisateur soumet une branche invalide (par exemple, en essayant de récupérer des actifs qu’il a déjà donnés à quelqu’un d’autre, ou en créant des actifs à partir de rien), la légitimité de cette vesting peut être déterminée grâce à un mécanisme de challenge hors chaîne.

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

Les premières versions de Plasma ne pouvaient traiter que des cas d’utilisation de paiement et ne pouvaient pas être largement promues de manière efficace. Cependant, si nous demandons à chaque racine d’être vérifiée par SNARK, Plasma deviendra beaucoup plus puissant. Chaque jeu de défi peut être grandement simplifié car nous éliminons la plupart des chemins possibles de triche par l’opérateur. En même temps, de nouvelles voies sont ouvertes pour permettre à la technologie Plasma de s’étendre à une plus large gamme 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 de création d’une chaîne EVM Plasma (non exclusive) : utiliser ZK-SNARK pour construire un arbre UTXO parallèle qui reflète les variations de solde effectuées 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 des clés de l’interprétation est que le système Plasma n’a pas besoin d’être parfait. Même si vous ne protégez qu’un sous-ensemble d’actifs (par exemple, seulement 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 actuelle de l’EVM extrêmement évolutive (c’est-à-dire le Validium).

Une autre catégorie de structures est le Plasma/Rollup hybride, comme Intmax. Ces constructions placent les très petites quantités de données de chaque utilisateur hors de la chaîne (par exemple, 5 octets), ce qui leur permet d’obtenir certaines des caractéristiques situées entre Plasma et Rollup : dans le cas d’Intmax, vous pouvez obtenir une très grande évolutivité et confidentialité, même si théoriquement limitée à environ 266 667 TPS dans une capacité de 16 Mo, soit environ 16 000 000 / 12 / 5.

Quels sont les liens pertinents avec les recherches existantes?

1.Original Plasma paper:

2.Plasma Cash:

3. Plasma Cashflow:

4. Intmax (2023):

Qu’est-ce qui doit encore être fait? Quels sont les compromis?

La tâche principale restante est de mettre le système Plasma en production. Comme indiqué ci-dessus, Plasma n’est pas une alternative exclusive à Validium : 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. L’accent de la recherche est mis 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 résolution directe à travers la recherche et la construction d’un cadre général amélioré.

Le principal compromis de conception des utilisations Plasma est qu’ils dépendent davantage des opérateurs et sont plus difficiles à mettre à l’échelle, bien qu’une conception hybride Plasma/Rollup puisse généralement éviter cette faiblesse.

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

Plus la solution Plasma est efficace, moins il y a de pression sur la disponibilité des données à haute performance de L1. Déplacer les activités vers L2 peut également réduire la pression 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. 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) à l’heure où cet article est écrit, Optimism et Arbitrum sont deux Rollup EVM complets qui ont implémenté une partie du jalon Trustless appelé “phase 1”. La raison pour laquelle les Rollup n’ont pas fait de plus grands progrès est la crainte de la présence de bugs dans le code. Nous avons besoin de Rollup sans confiance, il est donc nécessaire de faire face à et de résoudre ce problème.

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

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

Phase 0: Les utilisateurs doivent être en mesure d’exécuter Nœud et de synchroniser la chaîne. Si la validation est totalement fiable / centralisée, cela n’a pas d’importance.

Étape 1: Il doit y avoir un système de preuve (sans confiance) pour garantir que seules les transactions valides seront acceptées. Il est permis d’avoir un comité de sécurité capable d’annuler le système de preuve, mais un vote de 75% est requis. De plus, une partie du comité quorum-blocking (soit 26%+) doit être en dehors de la société principale qui construit 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 puissent retirer leurs fonds avant que ces derniers 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. 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 entre eux, 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 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 ce faire :

1. Vérification formelle：nous pouvons utiliser les mathématiques modernes et la technologie informatique pour prouver (optimistic 和 validity) que le système de preuve ne accepte que les Bloc conformes à la spécification EVM. Ces technologies existent depuis des décennies, mais les progrès récents (comme Lean 4) les rendent plus pratiques, tandis que les progrès de la preuve assistée par l’IA pourraient accélérer 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 graphique programmé du multi-preuve, combinant 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 multi-preuve (2022) :

3. Utilisation de la preuve multiple prévue :

Qu’est-ce qui doit encore être fait? Quels sont les compromis?

Pour Vérification formelle, la charge de travail est importante. Nous devons créer une version de vérification formelle complète du prouveur SNARK de l’EVM. Il s’agit d’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 formellement vérifié 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 les preuves multiples, 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, en veillant à ce qu’ils soient tous deux assez sécurisés individuellement et à ce que, s’ils posent problème, ces problèmes soient différents et non liés (donc ils ne se produiront pas en même temps). Ensuite, nous devons avoir une très grande confiance dans la logique sous-jacente du système de preuve combinée. Cette partie du code doit être beaucoup plus petite. Il existe des moyens de le rendre très petit en stockant les fonds dans un contrat de multi-signature sécurisé, dont les signataires représentent les différents systèmes de preuve, mais cela augmentera le coût du gas off-chain. Nous devons trouver un équilibre entre l’efficacité et la sécurité.

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

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

Amélioration de l’interopérabilité entre les L2

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

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 finissent souvent par réintroduire des hypothèses de confiance : l’interaction cross-chain centralisée, les clients RPC, etc. Nous devons faire en sorte que l’utilisation de l’écosystème L2 soit aussi fluide que l’utilisation d’un écosystème Ethereum unifié.

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

Il existe plusieurs catégories d’améliorations de l’interopérabilité L2. En théorie, l’ETH Rollup est équivalent à l’exécution du Sharding L1. Cependant, l’écosystème actuel de l’ETH L2 présente encore quelques lacunes par rapport à l’état idéal.

1、Adresse de 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 cross L2 peut être réalisé en simplement plaçant l’Adresse dans le champ “Envoyer”, à ce moment-là, le Portefeuille peut gérer en interne comment envoyer (y compris l’utilisation du protocole de cross-chain Interaction).

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 de la forme « envoie-moi X unités de type Y sur la chaîne Z ». Cela concerne principalement deux scénarios d’application : (i) les paiements entre personnes ou entre personnes et services marchands ; (ii) la demande de fonds par une DApp.

3、Interaction cross-chain兑换和 Gas 支付：应有一个标准化的开放protocole来表达Interaction cross-chain操作，如「我将向在 Arbitrum 上向我发送 0.9999 个以太币的人发送 1 个以太币（在 Optimism 上）」，以及「我将向在 Arbitrum 上包含此交易的人发送 0.0001 个以太币（在 Optimism 上）」。ERC-7683 是对前者的尝试，而 RIP-7755 是对后者的尝试，尽管这两者的应用范围都比这些特定用例更广。

4. client léger: 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 au fournisseur RPC. Helios d’a16z crypto peut le faire (pour ETH lui-même), mais nous devons étendre cette décentralisation à la couche 2. 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 du 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 le bon objet d’état L1, vous pouvez utiliser une preuve de Merkle (et une signature si vous voulez vérifier la pré-confirmation) pour vérifier n’importe quel objet d’état sur L2. Helios a déjà réalisé la première partie. Étendre à la seconde partie est un défi de normalisation.

1、Keystore Portefeuille：如今，如果你想更新控制你的Smart ContractPortefeuille的Clé secrète ，你必须在该Portefeuille存在的所有 N 条链上都进行更新。Keystore Portefeuille是一种技术，它允许Clé secrète 只存在于一个地方（要么在 L1 上，要么以后可能在 L2 上），然后任何拥有Portefeuille副本的 L2 都可以从中读取Clé secrète 。这意味着更新只需进行一次。为了提高效率，Keystore Portefeuille要求 L2 具有一种标准化的方式来无成本地读取 L1 上的信息；对此有两个提案，分别是 L1SLOAD 和 REMOTESTATICCALL。

Le fonctionnement du Portefeuille Keystore

2. Une approche plus radicale du concept de « pont Jeton partagé » : imaginez un monde où tous les L2 sont des Rollup de preuve de validité et chaque slot est soumis à la blockchain Ethereum. Même dans un tel monde, il est toujours nécessaire de retirer et 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 les soldes correspondants, et de permettre la mise à jour de ces soldes via une série d’opérations d’envoi inter-L2 initiées par n’importe quel L2. Cela permettrait de réaliser des transferts inter-L2 sans avoir à payer des frais de gaz L1 à chaque transaction, ni à utiliser des technologies telles que ERC-7683 basées sur les fournisseurs de liquidité.

3. Composition synchronisée : permet des appels synchronisés entre des L2 spécifiques et L1 ou entre plusieurs L2. Cela contribue à améliorer l’efficacité financière du protocole de Finance décentralisée. 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 technologies.

Quels sont les liens avec les recherches existantes?

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

2. ERC-7683:

3.RIP-7755:

4. Faites de la conception du portefeuille keystore :

5.Helios:

6.ERC-3668（parfois appelé CCIP Read）：

7. La proposition de Justin Drake de baser (partager) la confirmation préalable :

8.L1SLOAD (RIP-7728):

9.REMOTESTATICCALL dans Optimism :

10.AggLayer, y compris l’idée d’un pont de jeton partagé:

Qu’est-ce qui doit encore être fait? Quels sont les compromis?

Beaucoup des exemples ci-dessus sont confrontés à la difficulté de savoir quand standardiser et quels niveaux de normalisation standardiser. Une normalisation précoce peut solidifier une solution de moindre qualité. Une normalisation tardive peut conduire à une fragmentation inutile. Dans certains cas, une solution à court terme avec une propriété plus faible mais plus facilement implémentable existe ainsi qu’une solution à long terme « correcte » mais qui peut prendre plusieurs années à être mise en place.

Ces tâches ne sont pas seulement des problèmes techniques, ce sont aussi (voire principalement) des problèmes sociaux qui nécessitent une collaboration 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 ont peu d’impact sur le niveau L1. Une exception est le partage de l’ordre, qui a un impact majeur sur la valeur extractible maximale (MEV).

Extension de l’exécution sur L1

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

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

1. La situation é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 un écosystème financier hautement développé sur L1. Si cet écosystème est considérablement affaibli, les incitations à devenir L2 (plutôt que de devenir un L1 indépendant) seront réduites.

3、L2 nécessitera beaucoup de temps pour atteindre 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), l’utilisateur devra toujours récupérer ses avoirs via L1. Par conséquent, L1 doit être suffisamment puissant pour être en mesure de traiter occasionnellement des tâches complexes et chaotiques de L2.

Pour ces raisons, continuer à étendre 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 de procéder à une extension est d’augmenter directement la limite du gas. Cependant, cela pourrait entraîner une centralisation de la L1, affaiblissant ainsi une autre caractéristique importante de l’ETH : sa crédibilité en tant que couche de base robuste. Il existe actuellement des controverses sur la durabilité d’une simple augmentation de la limite du gas, et cela dépendra également des autres technologies mises en œuvre pour faciliter la validation de blocs plus importants (par exemple, l’expiration des données historiques, l’état sans état, la preuve de validité EVM de la L1). Un autre point important qui nécessite des améliorations continues est l’efficacité du logiciel client de l’ETH, qui est bien plus élevée aujourd’hui qu’il y a cinq ans. Une stratégie efficace pour augmenter la limite du gas de la 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. Compte tenu de 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 limitations différents sont fixés pour les calculs, les données et le stockage, ce qui permet d’augmenter la capacité moyenne de l’ETH L1 sans augmenter sa capacité maximale (évitant ainsi de nouveaux risques de sécurité).

3. Les codes opérationnels spécifiques à Goutte et le coût pré-compilé de Gas - Historiquement, afin d’éviter les attaques par déni de service, nous avons souvent augmenté le coût en gas de certaines opérations sous-évaluées. Il est possible de faire plus en augmentant le coût en gas des codes opérationnels Goutte surévalués. Par exemple, l’addition est beaucoup moins chère que la multiplication, mais les codes opérationnels ADD et MUL ont actuellement le même coût. Nous pouvons réduire le coût de Goutte ADD et même rendre le coût des codes opérationnels plus simples comme PUSH encore plus bas. EOF est globalement optimisé dans ce domaine.

4.EVM-MAX et SIMD : EVM-MAX est une proposition qui permet des opérations mathématiques sur de grands nombres natifs plus efficaces en tant que module distinct de l’EVM. Sauf intention explicite d’exportation, les valeurs calculées par EVM-MAX ne peuvent être accédées que par d’autres opcodes EVM-MAX. Cela permet d’optimiser l’espace de stockage de ces valeurs. SIMD (single instruction multiple data) est une proposition permettant 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, utilisé pour implémenter de manière plus efficace le chiffrement. Cela s’avère particulièrement utile pour les protocoles de confidentialité et les systèmes de protection L2, et contribuera donc à l’expansion des couches L1 et L2.

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

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

Quels sont les liens avec les recherches existantes?

1. Roadmap d’extension L1 de Polynya pour ETH.

2. Tarification du gaz multidimensionnelle :

3.EIP-7706:

4.EOF:

5.EVM-MAX:

6.SIMD:

7. rollups natifs :

8. Entretien de Max Resnick sur la valeur de l’extension L1 :

9. Justin Drake parle de l’utilisation de SNARK et de Rollups natifs pour l’évolutivité :

Qu’est-ce qu’il reste à faire et quels compromis faut-il faire ?

L’extension de la couche L1 dispose de trois stratégies qui peuvent être mises en œuvre de manière indépendante ou simultanée :

1. Amélioration des technologies (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.

2. Coût spécifique de l’opération Goutte, augmentant 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’il existe des compromis différents. Par exemple, les Rollups natifs présentent de nombreux mêmes points faibles en termes de composition que les Rollups normaux : vous ne pouvez pas envoyer une seule transaction pour exécuter des opérations sur plusieurs Rollups, comme vous le feriez avec un contrat sur le même L1 (ou L2). Augmenter la limite de gas affaiblira d’autres avantages réalisables grâce à une vérification simplifiée sur L1, comme augmenter le nombre d’utilisateurs vérifiant les nœuds et augmenter le nombre de solo stakers. En fonction de la mise en œuvre, rendre certaines opérations spécifiques dans l’EVM (Machine virtuelle Éthéréenne) moins coûteuses pourrait augmenter la complexité globale de l’EVM.

Tout plan de mise à l’échelle L1 doit répondre à une question majeure : quelle est la vision finale de L1 et L2 ? Manifestement, il est absurde de tout mettre sur L1 : les cas d’utilisation potentiels pourraient impliquer des dizaines de milliers de transactions par seconde, ce qui rendrait L1 incapable de tout valider (à moins que nous n’adoptions la méthode Rollup native). Mais nous avons vraiment besoin de certains principes directeurs pour nous assurer de ne pas nous retrouver dans une telle situation : une augmentation de 10 fois de la limite de gas porterait sérieusement atteinte à la décentralisation d’Éthereum sur 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 resteront sur L1 (plutôt que de devenir uniquement un problème de L2), ce qui rendra la nécessité de gérer explicitement le MEV plus pressante. Cela augmentera considérablement la valeur du slot rapide sur L1. Cela dépend également fortement du bon déroulement de la vérification L1 (the Verge).

Lecture connexe : “Nouveau document de Vitalik : Quels sont les autres domaines d’amélioration de la PoS d’ETH et comment les réaliser ?”

lien vers l’article original