Au début, Ethereum avait deux stratégies de mise à l'échelle dans sa feuille de route. Une (par exemple, voirce premier papierà partir de 2015) était le "sharding": au lieu de vérifier et stocker l'ensemble des transactions de la chaîne, chaque nœud aurait seulement besoin de vérifier et stocker une petite fraction des transactions. C'est ainsi que fonctionne tout autre réseau pair à pair (par exemple BitTorrent), donc nous pourrions sûrement faire fonctionner les blockchains de la même manière. Un autre concept était celui des protocoles de couche 2: des réseaux qui se situeraient au-dessus d'Ethereum de manière à leur permettre de bénéficier pleinement de sa sécurité, tout en conservant la plupart des données et des calculs en dehors de la chaîne principale. Les "protocoles de couche 2" signifiaientcanaux d'étaten 2015, Plasmaen 2017, et ensuiterollupsEn 2019. Les Rollups sont plus puissants que les canaux d'état ou Plasma, mais ils nécessitent une grande quantité de bande passante de données on-chain. Heureusement, d'ici 2019, la recherche sur le sharding avait résolule problème de vérification de la « disponibilité des données » à grande échelle. En conséquence, les deux chemins ont convergé, et nous avons obtenu le Feuille de route centrée sur le cumulqui continue d'être la stratégie de mise à l'échelle d'Ethereum aujourd'hui.

La montée, édition de la feuille de route 2023.

La feuille de route centrée sur le rollup propose une simple division du travail : l'Ethereum L1 se concentre sur le fait d'être une couche de base robuste et décentralisée, tandis que les L2 prennent en charge la tâche d'aider l'écosystème à se développer. C'est un schéma qui se répète partout dans la société : le système judiciaire (L1) n'est pas là pour être ultra-rapide et efficace, il est là pour protéger les contrats et les droits de propriété, et c'est aux entrepreneurs (L2) de construire par-dessus.robustebasecoucheet emmener l'humanité vers Mars (de manière métaphorique et littérale).

Cette année, la feuille de route centrée sur le rollup a connu d'importants succès : la bande passante des données Ethereum L1 a considérablement augmenté avecblocs EIP-4844, et plusieurs rollups EVM sont maintenant à l'étape 1. Un très implémentation hétérogène et pluraliste du sharding, où chaque L2 agit comme une « shard » avec ses propres règles et sa logique interne, est maintenant une réalité. Mais comme nous l'avons vu, emprunter cette voie présente des défis uniques. Ainsi, notre tâche est maintenant de mener à bien la feuille de route centrée sur le rollup et de résoudre ces problèmes, tout en préservant la robustesse et la décentralisation qui rendent l'Ethereum L1 spécial.

L'augmentation : objectifs clés

• + de 100 000 TPS sur L1+L2
• Préserver la décentralisation et la robustesse de la L1
• Au moins certains L2 héritent pleinement des propriétés fondamentales d'Ethereum (sans confiance, ouvert, résistant à la censure)
• Une interopérabilité maximale entre les L2. Ethereum devrait se sentir comme un seul écosystème, pas 34 blockchains différentes.

Dans ce chapitre

• À part : le trilemme de la scalabilité
• Des progrès supplémentaires dans l'échantillonnage de la disponibilité des données
• Compression de données
• Plasma généralisé
• Systèmes de preuve L2 en maturation
• Interopérabilité croisée L2 et améliorations de l’expérience utilisateur
• Exécution de mise à l'échelle sur L1

À part : le trilemme de la scalabilité

Le trilemme de la scalabilité était une idée introduit en 2017, qui a fait valoir qu’il existe une tension entre trois propriétés d’une blockchain : la décentralisation (plus précisément : faible coût d’exploitation d’un nœud), l’évolutivité (plus précisément : un nombre élevé de transactions traitées) et la sécurité (plus précisément : un attaquant ayant besoin de corrompre une grande partie des nœuds de l’ensemble du réseau pour faire échouer ne serait-ce qu’une seule transaction).

Notamment, le trilemme n'est pas un théorème, et le message introduisant le trilemme n'est pas venu avec une preuve mathématique. Il a donné un argument mathématique heuristique : si un nœud favorable à la décentralisation (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 soit (i) chaque transaction n'est vue que par 1/k des nœuds, ce qui implique qu'un attaquant n'a besoin de corrompre que quelques nœuds pour faire passer une mauvaise transaction, soit (ii) vos nœuds vont être costauds et votre chaîne pas décentralisée. Le but du message n'était jamais de montrer que briser le trilemme est impossible ; plutôt, c'était de montrer que briser le trilemme est difficile - cela nécessite de penser d'une manière qui sort du cadre que l'argument implique.

Pendant de nombreuses années, il a été courant pour certaines chaînes à haute performance de prétendre résoudre le trilemme sans rien faire d'intelligent au niveau de l'architecture fondamentale, généralement en utilisant des astuces d'ingénierie logicielle pour optimiser le nœud. Cela est toujours trompeur, et exécuter un nœud dans de telles chaînes finit toujours par être beaucoup plus difficile que dans Ethereum.Ce postaborde certaines des nombreuses subtilités qui expliquent pourquoi c'est le cas (et donc, pourquoi l'ingénierie logicielle client L1 seule ne peut pas mettre à l'échelle Ethereum elle-même).

Cependant, la combinaison de l'échantillonnage de la disponibilité des données et des SNARKs résout le trilemme: elle permet à un client de vérifier qu'une certaine quantité de données est disponible, et que certains calculs ont été effectués correctement, tout en ne téléchargeant qu'une petite partie de ces données et en exécutant une quantité beaucoup plus petite de calculs. Les SNARKs sont sans confiance. L'échantillonnage de la disponibilité des données est nuancé Modèle de confiance de N parmi quelques, mais il préserve la propriété fondamentale que les chaînes non évolutives ont, à savoir qu'une attaque de 51% ne peut pas forcer l'acceptation de blocs malveillants par le réseau.

Une autre façon de résoudre le trilemme est les architectures Plasma, qui utilisent des techniques astucieuses pour pousser la responsabilité de surveiller la disponibilité des données à l'utilisateur de manière compatible avec les incitations. De 2017 à 2019, lorsque tout ce que nous avions pour mettre à l'échelle le calcul était des preuves de fraude, Plasma était très limité dans ce qu'il pouvait faire en toute sécurité, mais la popularisation des SNARKs rend les architectures Plasmabeaucoup plus viablepour un éventail plus large de cas d'utilisation qu'auparavant.

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

Quel problème résolvons-nous ?

Au 13 mars 2024, lorsque le Mise à niveau de DencunDepuis son lancement, la blockchain Ethereum dispose de trois "blobs" d'environ 125 ko par créneau de 12 secondes, soit environ 375 ko par créneau de bande passante de disponibilité de données. En supposant que les données de transaction sont publiées directement onchain, un transfert ERC20 représente environ 180 octets, et donc le TPS maximal des rollups sur Ethereum est :

375000 / 12 / 180 = 173.6 TPS

Si nous ajoutons les calldata d'Ethereum (maximum théorique : 30 millions de gaz par créneau / 16 gaz par octet = 1 875 000 octets par créneau), cela devient 607 TPS. Avec PeerDAS, le plan est d'augmenter l'objectif de décompte de blobs à 8-16, ce qui nous donnerait 463-926 TPS en calldata.

C'est une augmentation importante par rapport à l'Ethereum L1, mais ce n'est pas suffisant. Nous voulons beaucoup plus de scalabilité. Notre objectif à moyen terme est de 16 Mo par slot, ce qui, combiné à des améliorations dans la compression des données rollup, nous donnerait environ 58 000 TPS.

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

PeerDAS est une mise en œuvre relativement simple de l'échantillonnage en 1D. Chaque blob dans Ethereum est un polynôme de degré 4096 sur un corps premier de 253 bits. Nous diffusons des "parts" du polynôme, où chaque part consiste en 16 évaluations à des coordonnées adjacentes prises dans un ensemble total de 8192 coordonnées. 4096 des 8192 évaluations (avec les paramètres proposés actuels : 64 des 128 échantillons possibles) peuvent récupérer le blob.

PeerDAS fonctionne en demandant à chaque client d'écouter un petit nombre de sous-réseaux, où le i-ème sous-réseau diffuse le i-ème échantillon de n'importe quel blob, et demande également des blobs sur d'autres sous-réseaux dont il a besoin en demandant à ses pairs dans le réseau p2p global (qui écouteraient différents sous-réseaux). Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme de sous-réseau, sans la couche supplémentaire de demande aux pairs. Une proposition actuelle consiste à ce que les nœuds participant à la preuve de participation utilisent SubnetDAS, et que les autres nœuds (c'est-à-dire les « clients ») utilisent PeerDAS.

Théoriquement, nous pouvons étendre l'échantillonnage 1D assez loin : si nous augmentons le nombre maximum de blobs à 256 (donc, la cible à 128), alors nous atteindrions notre cible de 16 Mo tandis que l'échantillonnage de disponibilité des données ne coûterait que 16 échantillons à chaque nœud128 blobs512 octets par échantillon par bloc = 1 Mo de bande passante de données par emplacement. C'est à peine dans notre tolérance : c'est faisable, mais cela signifierait que les clients contraints par la bande passante ne peuvent pas échantillonner. Nous pourrions optimiser cela quelque peu en diminuant le nombre de blocs et en augmentant la taille des blocs, mais cela rendrait la reconstruction plus coûteuse.

Et donc finalement nous voulons aller plus loin, et faireÉchantillonnage 2D, qui fonctionne par échantillonnage aléatoire non seulement au sein des blobs, mais aussi entre les blobs. Les propriétés linéaires des engagements KZG sont utilisées pour « étendre » l’ensemble des objets blob d’un bloc avec une liste de nouveaux « objets blob virtuels » qui codent de manière redondante les mêmes informations.

Échantillonnage 2D. Source: a16z crypto

De manière cruciale, calculer l'extension des engagements ne nécessite pas de disposer des blobs, de sorte que le schéma est fondamentalement favorable à la construction de blocs distribués. Le nœud construisant effectivement le bloc aurait seulement besoin d'avoir les engagements de blob KZG, et peut lui-même s'appuyer sur DAS pour vérifier la disponibilité des blobs. 1D DAS est également intrinsèquement favorable à la construction de blocs distribués.

Quels sont quelques liens vers des recherches existantes?

• Publication originale présentant la disponibilité des données (2018) :https://github.com/ethereum/research/wiki/Une-note-sur-la-disponibilité-des-données-et-le-codage-d'effacement
• Document de suivi : https://arxiv.org/abs/1809.09044
• Article explicatif sur DAS, paradigme: https://www.paradigm.xyz/2022/08/das
• Disponibilité 2D avec engagements KZG : https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081
• PeerDAS sur ethresear.ch: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 , et papier: https://eprint.iacr.org/2024/1362
• Présentation sur PeerDAS par Francesco :https://www.youtube.com/watch?v=WOdpO1tH_Us
• EIP-7594: https://eips.ethereum.org/EIPS/eip-7594
• SubnetDAS sur ethresear.ch : https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169
• Subtilités de la récupérabilité dans l'échantillonnage 2D: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256

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

La prochaine étape immédiate consiste à terminer la mise en œuvre et le déploiement de PeerDAS. Ensuite, c'est un travail progressif pour continuer à augmenter le nombre de blobs sur PeerDAS tout en surveillant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité. En même temps, nous voulons davantage de travaux académiques sur la formalisation de PeerDAS et d'autres versions de DAS et leurs interactions avec des problématiques telles que la sécurité de la règle de choix de fork.

Plus loin dans le futur, nous avons besoin de beaucoup plus de travail pour trouver la version idéale de 2D DAS et prouver ses propriétés de sécurité. Nous voulons également migrer finalement loin de KZG vers une alternative résistante à la cryptanalyse quantique et sans installation de confiance. Actuellement, nous ne connaissons pas de candidats qui soient favorables à la construction de blocs distribués. Même la technique coûteuse de la "force brute" consistant à utiliser des STARKs récursifs pour générer des preuves de validité pour la reconstruction des lignes et des colonnes ne suffit pas, car techniquement un STARK est O(log(n) * log(log(n)) hachages de taille (avec STIR), en pratique, un STARK est presque aussi grand qu’un blob entier.

Les voies réalistes que je vois à long terme sont :

• Mettre en œuvre l'idéal 2D DAS
• Rester avec 1D DAS, sacrifiant l'efficacité de la largeur de bande d'échantillonnage et acceptant une limite de données inférieure pour des raisons de simplicité et de robustesse
• (Virage serré) abandonner DA, et adopter pleinement Plasma comme une architecture de couche 2 principale sur laquelle nous nous concentrons

Nous pouvons voir ceux-ci le long d'un spectre de compromis :

Notez que ce choix existe même si nous décidons de mettre à l'échelle l'exécution sur L1 directement. Cela est dû au fait que si L1 doit traiter de nombreux TPS, les blocs L1 deviendront très volumineux et les clients voudront un moyen efficace de vérifier qu'ils sont corrects, donc nous devrions utiliser la même technologie qui alimente les rollups (ZK-EVM et DAS) au niveau de L1.

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

Le besoin de DAS 2D est quelque peu diminué, ou du moins retardé, si la compression des données (voir ci-dessous) est mise en œuvre, et il est encore plus réduit si Plasma est largement utilisé. DAS pose également un défi aux protocoles et mécanismes de construction de blocs distribués: bien que DAS soit théoriquement favorable à la reconstruction distribuée, cela doit être combiné en pratique avecliste d'inclusionpropositions et leurs mécanismes de choix de fourchette environnants.

Compression de données

Quel problème résolvons-nous ?

Chaque transaction dans un rollup prend une quantité significative d'espace de données onchain : un transfert ERC20 prend environ 180 octets. Même avec un échantillonnage idéal de disponibilité des données, cela limite la scalabilité des protocoles de couche 2. Avec 16 Mo par créneau, nous obtenons :

16000000 / 12 / 180 = 7407 TPS

Et si, en plus de s'attaquer au numérateur, nous pouvions également nous attaquer au dénominateur et faire en sorte que chaque transaction dans un rollup prenne moins d'octets onchain?

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

La meilleure explication à mon avis est ce diagrammedepuis deux ans :

Les gains les plus simples ne sont que la compression de zéro-octet : remplaçant chaque longue séquence de zéros par deux octets représentant combien de zéros il y a. Pour aller plus loin, nous profitons des propriétés spécifiques des transactions :

• Aggrégation de signatures - nous passons des signatures ECDSA aux signatures BLS, qui ont la propriété que de nombreuses signatures peuvent être combinées en une seule signature qui atteste de la validité de toutes les signatures d'origine. Cela n'est pas pris en compte pour L1 car les coûts de vérification, même avec l'agrégation, sont plus élevés, mais dans un environnement où les données sont rares comme les L2, ils ont probablement du sens. La fonction d'agrégation de ERC-4337présente un chemin pour mettre en œuvre cela.
• Remplacement des adresses par des pointeurs - si une adresse a été utilisée auparavant, nous pouvons remplacer l'adresse de 20 octets par un pointeur de 4 octets vers un emplacement dans l'historique. Cela est nécessaire pour réaliser les plus grands gains, même si cela nécessite des efforts à mettre en œuvre, car cela exige que (du moins une partie de) l'historique de la blockchain devienne effectivement une partie de l'état.
• La sérialisation personnalisée des valeurs de transaction - la plupart des valeurs de transaction ont très peu de chiffres, par exemple 0,25 ETH est représenté comme 250 000 000 000 000 000 wei. Les frais maximaux de base de gaz et les frais de priorité fonctionnent de manière similaire. Nous pouvons ainsi représenter la plupart des valeurs monétaires de manière très compacte avec un format décimal flottant personnalisé, ou même un dictionnaire des valeurs particulièrement courantes.

Quels sont les liens avec les recherches existantes ?

• Exploration de sequence.xyz: https://sequence.xyz/blog/compressing-calldata
• Contrats optimisés pour les données d'appel pour L2s, de ScopeLift: https://github.com/ScopeLift/l2-optimizoooors
• Une autre stratégie : les cumuls basés sur la validité (alias cumuls ZK) publient des différences d’état au lieu de transactions : https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
• Portefeuille BLS - une implémentation de l’agrégation BLS via ERC-4337 : https://github.com/getwax/bls-wallet

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

La principale chose à faire est en fait de mettre en œuvre les schémas ci-dessus. Les principaux compromis sont :

• Passer aux signatures BLS demande des efforts considérables et réduit la compatibilité avec les puces matérielles de confiance qui peuvent renforcer la sécurité. Un wrapper ZK-SNARK autour d'autres schémas de signature pourrait être utilisé pour le remplacer.
• La compression dynamique (par exemple, le remplacement des adresses par des pointeurs) complique le code client.
• Publier des différences d'état sur la chaîne au lieu des transactions réduit l'auditabilité et rend inutilisable un grand nombre de logiciels (par exemple, les explorateurs de blocs).

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

L'adoption de ERC-4337, et éventuellement la consécration de certaines de ses parties dans les L2 EVM, peut grandement accélérer le déploiement des techniques d'agrégation. La consécration de certaines parties de ERC-4337 sur L1 peut accélérer son déploiement sur les L2.

Plasma généralisé

Quel problème résolvons-nous?

Même avec des blobs de 16 Mo et une compression de données, 58 000 TPS n'est pas nécessairement suffisant pour prendre pleinement en charge les paiements des consommateurs, les réseaux sociaux décentralisés ou d'autres secteurs à haut débit, et cela devient particulièrement vrai si nous commençons à prendre en compte la confidentialité, ce qui pourrait réduire la scalabilité de 3 à 8 fois. Pour les applications à fort volume et faible valeur, une option aujourd'hui est unevalidium, qui conserve les données hors chaîne et présente un modèle de sécurité intéressant où l'opérateur ne peut pas voler les fonds des utilisateurs, mais peut disparaître et geler temporairement ou définitivement tous les fonds des utilisateurs. Mais nous pouvons faire mieux.

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

Plasma est une solution d'évolutivité qui implique qu'un opérateur publie des blocs hors chaîne et place les racines de Merkle de ces blocs sur la chaîne (par opposition aux rollups, où le bloc complet est placé sur la chaîne). Pour chaque bloc, l'opérateur envoie à chaque utilisateur une branche de Merkle prouvant ce qui s'est passé, ou ne s'est pas passé, pour les actifs de cet utilisateur. Les utilisateurs peuvent retirer leurs actifs en fournissant une branche de Merkle. Il est important de noter que cette branche n'a pas besoin d'être enracinée dans l'état le plus récent - pour cette raison, même si la disponibilité des données échoue, l'utilisateur peut toujours récupérer ses actifs en retirant le dernier état dont il dispose. Si un utilisateur soumet une branche invalide (par exemple, en sortant un actif qu'il a déjà envoyé à quelqu'un d'autre, ou si l'opérateur crée lui-même un actif à partir de rien), un mécanisme de défi sur chaîne peut statuer sur à qui appartient légitimement l'actif.

Un schéma d'une chaîne 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 qu'Eve possède actuellement la pièce 1, David possède la pièce 4 et George possède la pièce 6.

Les premières versions de Plasma ne pouvaient gérer que le cas d'utilisation des paiements et ne pouvaient pas généraliser efficacement davantage. Si nous exigeons que chaque racine soit vérifiée avec un SNARK, cependant, Plasma devient beaucoup plus puissant. Chaque jeu de défi peut être considérablement simplifié, car nous éliminons la plupart des chemins possibles pour l'opérateur tricher. De nouveaux chemins s'ouvrent également pour permettre aux techniques de Plasma d'être étendues à une classe d'actifs beaucoup plus générale. Enfin, dans le cas où l'opérateur ne triche pas, les utilisateurs peuvent retirer leurs fonds instantanément, sans avoir besoin d'attendre une période de défi d'une semaine.

Une façon (pas la seule façon) de créer une chaîne de plasma EVM : utiliser un 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 de ce qui est “la même pièce” à différents moments de l'histoire. Une construction Plasma peut alors être construite dessus.

L’une des idées clés est que le système Plasma n’a pas besoin d’être parfait. Même si vous ne pouvez protéger qu’un sous-ensemble d’actifs (par exemple, même seulement des pièces qui n’ont pas bougé au cours de la semaine écoulée), vous avez déjà grandement amélioré le statu quo de l’EVM ultra-évolutif, qui est un validium.

Une autre classe de constructions est celle des plasma/rollups hybrides, tels que Intmax. Ces constructions mettent une très petite quantité de données par utilisateur sur la chaîne (par exemple, 5 octets), et ce faisant, obtiennent des propriétés qui se situent quelque part entre le plasma et les cumuls : dans le cas d’Intmax, vous obtenez un très haut niveau d’évolutivité et de confidentialité, bien que même dans le monde de 16 Mo, la capacité soit théoriquement plafonnée à environ 16 000 000 / 12 / 5 = 266 667 TPS.

Quels sont quelques liens vers des recherches existantes?

• Papier plasma d’origine : https://plasma.io/plasma-deprecated.pdf
• Plasma Cash : https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
• Plasma Cashflow: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#🚪-Sortie
• Intmax (2023) : https://eprint.iacr.org/2023/1082

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

La tâche principale restante est de mettre en production les systèmes Plasma. Comme mentionné ci-dessus, “plasma vs validium” n'est pas binaire : tout validium peut voir ses propriétés de sécurité améliorées au moins un peu en ajoutant des fonctionnalités Plasma dans le mécanisme de sortie. La partie recherche consiste à obtenir des propriétés optimales (en termes d'exigences de confiance, de coût en gaz L1 dans le pire des cas et de vulnérabilité aux attaques par déni de service) pour un EVM, ainsi que des constructions spécifiques d'application alternatives. De plus, la plus grande complexité conceptuelle du Plasma par rapport aux rollups doit être abordée directement, à la fois par la recherche et par la construction de cadres généralisés meilleurs.

Le principal compromis dans l'utilisation des conceptions Plasma est qu'elles dépendent davantage des opérateurs et sont plus difficiles à réaliser.basé« Bien que les conceptions hybrides plasma/rollup puissent souvent éviter cette faiblesse.

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

Plus les solutions Plasma sont efficaces, moins il y a de pression sur le L1 pour avoir une fonctionnalité de disponibilité des données haute performance. Le fait de déplacer l'activité vers le L2 réduit également la pression MEV sur le L1.

Systèmes de preuve L2 en maturation

Quel problème résolvons-nous ?

Aujourd'hui, la plupart des rollups ne sont pas encore réellement sans confiance; il existe un conseil de sécurité qui a la capacité de passer outre le comportement du (optimiste ou de la validité)système de preuve. Dans certains cas, le système de preuve n'est même pas encore en direct, ou s'il l'est, il n'a qu'une fonctionnalité "conseil". Les plus avancés sont (i) quelques rollups spécifiques à une application, tels que Fuel, qui sont sans confiance, et (ii) au moment de la rédaction du présent document, Optimism et Arbitrum, deux rollups complets de l'EVM qui ont atteint une étape partiellement sans confiance connue sous le nom de "stage 1". La raison pour laquelle les rollups n'ont pas progressé davantage est la préoccupation concernant les bugs dans le code. Nous avons besoin de rollups sans confiance, et donc nous devons affronter ce problème de front.

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

Tout d’abord, récapitulons le système de « scène », introduit à l’origine dans cette publication. Il y a des exigences plus détaillées, mais en résumé :

• Étape 0: il doit être possible pour un utilisateur d'exécuter un nœud et de synchroniser la chaîne. C'est bon si la validation est entièrement fiable/centralisée.
• Étape 1 : il doit y avoir un système de preuve (sans confiance) qui garantit que seules les transactions valides sont acceptées. Il est permis qu'il y ait un conseil de sécurité qui puisse outrepasser le système de preuve, mais seulement avec un vote seuil de 75 %. De plus, une partie du conseil bloquant le quorum (donc, 26 % ou plus) doit être en dehors du bâtiment principal de la société construisant le rollup. Un mécanisme de mise à niveau avec des fonctionnalités plus faibles (par exemple, un DAO) est autorisé, mais il doit comporter un délai suffisamment long pour que si celui-ci approuve une mise à niveau malveillante, les utilisateurs puissent retirer leurs fonds avant sa mise en ligne.
• Étape 2: il doit exister un système de preuve (sans confiance) qui garantit que seules les transactions valides sont acceptées. Les conseils de sécurité ne sont autorisés à intervenir que en cas de bogues prouvables dans le code, par exemple si deux systèmes de preuve redondants sont en désaccord l'un avec l'autre ou si un système de preuve accepte deux racines d'état postérieur différentes pour le même bloc (ou n'accepte rien pendant une période suffisamment longue, par exemple une semaine). Un mécanisme de mise à niveau est autorisé, mais il doit comporter un très long délai.

L'objectif est d'atteindre l'étape 2. Le principal défi pour atteindre l'étape 2 est d'avoir suffisamment confiance que le système de preuve est effectivement assez fiable. Il existe deux façons principales de le faire :

• Vérification formelle : nous pouvons utiliser des techniques mathématiques et computationnelles modernes pour prouver qu'un système de preuve (optimiste ou de validité) n'accepte que les blocs qui passent la spécification de l'EVM. Ces techniques existent depuis des décennies, mais des avancées récentes comme Lean 4les ont rendus beaucoup plus pratiques, et les progrès dans la preuve assistée par l'IA pourraient potentiellement accélérer davantage cette tendance.
• Multi-prouveurs : créez plusieurs systèmes de preuve, et investissez des fonds dans un multisig 2 sur 3 (ou plus) entre ces systèmes de preuve et un conseil de sécurité (et/ou un autre gadget avec des hypothèses de confiance, par exemple. TEEs). Si les systèmes de preuve sont d’accord, le Conseil de sécurité n’a aucun pouvoir ; S’ils ne sont pas d’accord, le Conseil de sécurité ne peut choisir qu’entre l’un d’entre eux, il ne peut pas imposer unilatéralement sa propre réponse.

Diagramme stylisé d'un multi-vérificateur, combinant un système de preuve optimiste, un système de preuve de validité et un conseil de sécurité.

Quels sont les liens avec les recherches existantes ?

• Sémantique de l'EVM K (travail de vérification formelle à partir de 2017) :https://github.com/runtimeverification/evm-semantics
• Présentation sur l'idée de multi-proveurs (2022) : https://www.youtube.com/watch?v=6hfVzCWT6YI
• Taiko prévoit d'utiliser des multi-preuves : https://docs.taiko.xyz/core-concepts/multi-proofs/

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

Pour la vérification formelle, beaucoup. Nous devons créer une version formellement vérifiée d'un prouveur SNARK entier d'un EVM. Il s'agit d'un projet incroyablement complexe, bien que ce soit celui qui nous avons déjà commencé. Il y a un tour qui simplifie considérablement la tâche : nous pouvons faire un prouveur SNARK formellement vérifié d'une VM minimale, par exemple. RISC-VouLe Caire, et ensuite écrire une implémentation de l'EVM dans ce VM minimal (et prouver formellement son équivalence à une autre spécification de l'EVM).

Pour les multi-éprouveurs, il reste deux éléments principaux. Tout d'abord, nous devons avoir suffisamment confiance dans au moins deux systèmes de preuve différents, à la fois qu'ils sont raisonnablement sûrs individuellement et que s'ils échouent, ils échoueraient pour des raisons différentes et non liées (et donc ils ne tomberaient pas en panne en même temps). Deuxièmement, nous devons avoir un très haut niveau d'assurance dans la logique sous-jacente qui fusionne les systèmes de preuve. Il s'agit d'un morceau de code beaucoup plus petit. Il existe des moyens de le rendre extrêmement petit - il suffit de stocker des fonds dans un Contrat multisig sécurisédont les signataires sont des contrats représentant des systèmes de preuve individuels - mais cela se fait au détriment de coûts de gaz élevés sur la chaîne. Un certain équilibre entre efficacité et sécurité devra être trouvé.

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

Déplacer l'activité vers L2 réduit la pression de l'EMV sur L1.

Améliorations de l'interopérabilité croisée entre les L2

Quel problème résolvons-nous ?

Un des principaux défis de l'écosystème L2 aujourd'hui est qu'il est difficile pour les utilisateurs de naviguer. De plus, les moyens les plus simples de le faire réintroduisent souvent des hypothèses de confiance : ponts centralisés, clients RPC, et ainsi de suite. Si nous sommes sérieux au sujet de l'idée que les L2 font partie d'Ethereum, nous devons faire en sorte que l'utilisation de l'écosystème L2 soit semblable à l'utilisation d'un écosystème Ethereum unifié.

Un exemple de mauvaise UX pathologique (et même dangereuse : j'ai personnellement perdu 100 $ à cause d'une erreur de sélection de chaîne ici) cross-L2 - même si ce n'est pas la faute de Polymarket, l'interopérabilité cross-L2 devrait être la responsabilité des portefeuilles et de la communauté des normes Ethereum (ERC). Dans un écosystème Ethereum bien fonctionnel, envoyer des pièces de L1 à L2, ou d'un L2 à un autre, devrait se sentir exactement comme envoyer des pièces dans le même L1.

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

Il existe de nombreuses catégories d'améliorations de l'interopérabilité croisée L2. En général, la manière de les élaborer est de remarquer qu'en théorie, Un Ethereum centré sur le rollup est la même chose qu'un sharding d'exécution L1, et demandez ensuite en quoi l'actuel L2-verse d'Ethereum ne répond pas à cet idéal en pratique. Voici quelques-uns :

• Adresses spécifiques à la chaîne : la chaîne (L1, Optimism, Arbitrum...) doit faire partie de l'adresse. Une fois que cela est mis en œuvre, les flux d'envoi inter-L2 peuvent être mis en œuvre en mettant simplement l'adresse dans le champ “envoyer”, à ce moment-là le portefeuille peut trouver comment effectuer l'envoi (y compris l'utilisation de protocoles de pontage) en arrière-plan.
• Demandes de paiement spécifiques à la chaîne : il devrait être facile et normalisé de créer un message de la forme "envoyez-moi X jetons de type Y sur la chaîne Z". Cela a deux cas d'utilisation principaux : (i) les paiements, qu'il s'agisse de personne à personne ou de personne à service marchand, et (ii) les dapps demandant des fonds, par exemple l'exemple de Polymarket ci-dessus.
• Échanges inter-chaînes et paiement de frais de gaz : il devrait exister un protocole ouvert et normalisé pour exprimer des opérations inter-chaînes telles que "J'envoie 1 ETH sur Optimism à quiconque m'envoie 0.9999 ETH sur Arbitrum" et "J'envoie 0.0001 ETH sur Optimism à quiconque inclut cette transaction sur Arbitrum".ERC-7683est une tentative de l'ancien, etRIP-7755est une tentative de ce dernier, bien que les deux soient également plus générales que simplement ces cas d'utilisation spécifiques.
• Clients légers : les utilisateurs devraient pouvoir vérifier réellement les chaînes avec lesquelles ils interagissent, et ne pas se contenter de faire confiance aux fournisseurs RPC. A16z crypto’s Heliosle fait pour Ethereum lui-même, mais nous devons étendre cette absence de confiance aux L2.ERC-3668 (CCIP-read)est une stratégie pour faire cela.

Comment un client léger peut mettre à jour sa vue de la chaîne d'en-têtes Ethereum. Une fois que vous avez la chaîne d'en-têtes, vous pouvez utiliser des preuves de Merkle pour valider n'importe quel objet d'état. Et une fois que vous avez les bons objets d'état L1, vous pouvez utiliser des preuves de Merkle (et éventuellement des signatures, si vous voulez vérifier les préconfirmations) pour valider n'importe quel objet d'état sur L2. Helios fait déjà le premier. Étendre au second est un défi de normalisation.

• Portefeuilles de clés : aujourd'hui, si vous souhaitez mettre à jour les clés qui contrôlent votre portefeuille de contrats intelligents, vous devez le faire sur toutes les chaînes N sur lesquelles ce portefeuille existe. Les portefeuilles de clés sont une technique qui permet aux clés d'exister en un seul endroit (soit sur L1, soit éventuellement sur un L2), puis d'être lues depuis n'importe quel L2 qui possède une copie du portefeuille. Cela signifie que les mises à jour ne doivent se produire qu'une seule fois. Pour être efficaces, les portefeuilles de clés nécessitent que les L2 aient une manière standardisée de lire gratuitement le L1 ; deux propositions à cet effet sont L1SLOADetAPPELSTATIQUEÀDISTANCE.

Un diagramme stylisé de fonctionnement des portefeuilles de keystore.

• Des idées de « pont de jeton partagé » plus radicales : imaginez un monde où tous les L2 sont des rollups de preuve de validité, qui se commettent à Ethereum à chaque créneau. Même dans ce monde, déplacer des actifs d'un L2 à un autre L2 de manière « native » nécessiterait de retirer et de déposer, ce qui nécessite de payer une quantité substantielle de gaz L1. Une façon de résoudre cela est de créer un rollup minimal partagé, dont la seule fonction serait de maintenir les soldes de combien de jetons de quel type sont détenus par quel L2, et de permettre que ces soldes soient mis à jour en masse par une série d'opérations d'envoi entre L2 initiées par l'un des L2. Cela permettrait que les transferts entre L2 se fassent sans avoir besoin de payer de gaz L1 par transfert, et sans avoir besoin de techniques basées sur des fournisseurs de liquidité comme l'ERC-7683.
• La composabilité synchrone: permettre que des appels synchrones se produisent soit entre un L2 spécifique et un L1, soit entre plusieurs L2. Cela pourrait être utile pour améliorer l'efficacité financière des protocoles de DeFi. Le premier pourrait être réalisé sans aucune coordination entre les L2; le second nécessiteraitséquençage partagé.Cumuls basés sursont automatiquement amicaux à toutes ces techniques.

Quels sont quelques liens vers des recherches existantes?

• Adresses spécifiques à la chaîne : ERC-3770 : https://eips.ethereum.org/EIPS/eip-3770
• ERC-7683: https://eips.ethereum.org/EIPS/eip-7683
• RIP-7755: https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md
• Conception de portefeuille de clés de stockage de défilement :@haichen/keystore"">https://hackmd.io/@haichen/keystore
• Helios: https://github.com/a16z/helios
• ERC-3668 (parfois appelé lecture CCIP) : https://eips.ethereum.org/EIPS/eip-3668
• Proposition de "préconfirmations basées (partagées)" par Justin Drake : https://ethresear.ch/t/based-preconfirmations/17353
• L1SLOAD (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388
• REMOTESTATICCALL dans Optimism: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
• AggLayer, qui inclut des idées de ponts de jetons partagés : https://github.com/AggLayer

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

Bon nombre des exemples ci-dessus font face à des dilemmes standards quant à la standardisation et aux couches à standardiser. Si vous standardisez trop tôt, vous risquez de consolider une solution inférieure. Si vous standardisez trop tard, vous risquez de créer une fragmentation inutile. Dans certains cas, il existe à la fois une solution à court terme qui a des propriétés plus faibles mais qui est plus facile à mettre en œuvre, et une solution à long terme qui est "finalement correcte" mais qui prendra quelques années pour y parvenir.

Une façon dont cette section est unique, c'est que ces tâches ne sont pas seulement des problèmes techniques : ce sont aussi (peut-être même principalement !) des problèmes sociaux. Elles nécessitent que les L2 et les portefeuilles et L1 coopèrent. Notre capacité à résoudre ce problème avec succès 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 de ces propositions sont des constructions de "couches supérieures", et n'affectent donc pas beaucoup les considérations de L1. Une exception est le séquençage partagé, qui a des impacts importants sur MEV.

Mise à l'échelle de l'exécution sur L1

Quel problème résolvons-nous ?

Si les L2 deviennent très évolutifs et réussis mais que le L1 reste capable de traiter seulement un très faible volume de transactions, il existe de nombreux risques pour Ethereum qui pourraient survenir:

1. La situation économique de l'ETH l'actif devient plus risquée, ce qui affecte à son tour la sécurité à long terme du réseau.
2. De nombreux L2 bénéficient d'être étroitement liés à un écosystème financier très développé sur L1, et si cet écosystème s'affaiblit considérablement, l'incitation à devenir un L2 (au lieu d'être un L1 indépendant) s'affaiblit
3. Il faudra beaucoup de temps avant que les L2 aient exactement les mêmes garanties de sécurité que les L1.
4. Si un L2 échoue (par exemple en raison d'un opérateur malveillant ou disparu), les utilisateurs devraient toujours passer par L1 afin de récupérer leurs actifs. Par conséquent, L1 doit être suffisamment puissant pour être capable de gérer au moins occasionnellement la liquidation hautement complexe et chaotique d'un L2.

Pour ces raisons, il est précieux de continuer à mettre à l'échelle L1 lui-même, et de s'assurer qu'il peut continuer à accueillir un nombre croissant d'utilisations.

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

Le moyen le plus simple d'évoluer est simplement d'augmenter la limite de gaz. Cependant, cela risque de centraliser le L1 et de affaiblir ainsi l'autre propriété importante qui rend le L1 Ethereum si puissant : sa crédibilité en tant que couche de base robuste. Un débat est en cours sur le degré d'augmentation de la limite de gaz simple qui est durable, et cela change également en fonction des autres technologies mises en œuvre pour faciliter la vérification de blocs plus importants (par exemple, l'expiration de l'historique, la sans-état, les preuves de validité L1 EVM). Une autre chose importante à améliorer est tout simplement l'efficacité du logiciel client Ethereum, qui est bien plus optimisé aujourd'hui qu'il ne l'était il y a cinq ans. Une stratégie efficace d'augmentation de la limite de gaz L1 impliquerait d'accélérer ces technologies de vérification.

Une autre stratégie de mise à l'échelle consiste à identifier des fonctionnalités spécifiques et des types de calcul qui peuvent être rendus moins coûteux sans nuire à la décentralisation du réseau ou à ses propriétés de sécurité. Des exemples incluent :

• EOF- un nouveau format de bytecode EVM qui est plus convivial pour l'analyse statique, permettant des implémentations plus rapides. Le bytecode EOF pourrait se voir attribuer des coûts en gaz plus bas pour prendre en compte ces efficacités.
• Tarification du gaz multidimensionnelle- établir des frais de base séparés et des limites pour le calcul, les données et le stockage peut augmenter la capacité moyenne de l'Ethereum L1 sans augmenter sa capacité maximale (et donc créer de nouveaux risques de sécurité).
• Réduire les coûts en gaz des opcodes spécifiques et des précompilations - historiquement, nous avons euplusieurs Toursdecroissantgascoûtspour certaines opérations qui étaient sous-évaluées afin d'éviter les attaques de déni de service. Ce que nous avons eu moins, et pourrions faire beaucoup plus, c'est réduire les coûts en gaz pour les opérations surévaluées. 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 rendre l'ADD moins cher, et même rendre des opcodes encore plus simples tels que PUSH encore moins chers.
• EVM-MAXetSIMD: EVM-MAX (« extensions arithmétiques modulaires ») est une proposition visant à permettre un calcul modulaire de grands nombres plus efficace en tant que module distinct de l'EVM. Les valeurs calculées par les calculs EVM-MAX ne seraient accessibles que par d'autres opcodes EVM-MAX, à moins d'être délibérément exportées ; cela permet de disposer de plus d'espace pour stocker ces valeurs dansformats optimisés. SIMD ("single instruction multiple data") est une proposition visant à permettre l'exécution efficace de la même instruction sur un tableau de valeurs. Les deux ensemble peuvent créer un puissant coprocesseuraux côtés de l'EVM qui pourrait être utilisé pour mettre en œuvre beaucoup plus efficacement des opérations cryptographiques. Cela serait particulièrement utile pour les protocoles de confidentialité et pour les systèmes de preuve L2, ce qui aiderait à la fois à l'évolutivité de L1 et de L2.

Ces améliorations seront discutées plus en détail dans un prochain article sur le Splurge.

Enfin, une troisième stratégie consiste en des rollups natifs (ou "rollups consacrés") : essentiellement, créer de nombreuses copies de l'EVM qui s'exécutent en parallèle, ce qui conduit à un modèle équivalent à ce que les rollups peuvent fournir, mais beaucoup plus intégré nativement dans le protocole.

Quels sont quelques liens vers des recherches existantes?

• La feuille de route de mise à l'échelle L1 d'Ethereum de Polynya : https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ
• Tarification multidimensionnelle du gaz : https://vitalik.eth.limo/general/2024/05/09/multidim.html
• EIP-7706: https://eips.ethereum.org/EIPS/eip-7706
• EOF: https://evmobjectformat.org/
• EVM-MAX: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168
• SIMD: https://eips.ethereum.org/EIPS/eip-616
• Rollups natifs : https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
• Interview avec Max Resnick sur la valeur de mise à l'échelle L1: https://x.com/BanklessHQ/status/1831319419739361321
• Justin Drake sur l'utilisation des SNARKs et des rollups natifs pour l'évolutivité : https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

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

Il existe trois stratégies pour l'évolutivité L1, qui peuvent être poursuivies individuellement ou en parallèle :

• Améliorez la technologie (par exemple, le code client, les clients sans état, l’expiration de l’historique) pour rendre le L1 plus facile à vérifier, puis augmentez la limite de gaz
• Rendre les opérations spécifiques moins chères, augmentant la capacité moyenne sans augmenter les risques dans le pire des cas
• Rollups natifs (c'est-à-dire « créer N copies parallèles de l'EVM », offrant potentiellement aux développeurs une grande flexibilité dans les paramètres des copies qu'ils déploient)

Il vaut la peine de comprendre que ce sont des techniques différentes qui ont des compromis différents. Par exemple, les rollups natifs ont de nombreuses faiblesses en termes de composabilité similaires à celles des rollups réguliers : vous ne pouvez pas envoyer une seule transaction qui effectue de manière synchrone des opérations sur beaucoup d'entre eux, comme vous le pouvez avec des contrats sur le même L1 (ou L2). Augmenter la limite de gaz diminue d'autres avantages qui peuvent être obtenus en rendant le L1 plus facile à vérifier, comme augmenter la partie des utilisateurs qui exécutent des nœuds de vérification et augmenter les stakers solo. Rendre des opérations spécifiques dans l'EVM moins chères, selon la manière dont c'est fait, peut augmenter la complexité totale de l'EVM.

Une grande question à laquelle tout plan de mise à l'échelle L1 doit répondre est la suivante : quelle est la vision ultime de ce qui doit figurer sur L1 et de ce qui doit figurer sur L2 ? De toute évidence, il est absurde que tout aille sur L1 : les cas d'utilisation potentiels se chiffrent en centaines de milliers de transactions par seconde, ce qui rendrait L1 complètement invérifiable (à moins que nous empruntions la voie native du rollup). Mais nous avons besoin d'un principe directeur, afin de nous assurer de ne pas créer une situation où nous augmentons la limite de gaz de 10 fois, endommageons considérablement la décentralisation de l'Ethereum L1, et constatons que nous n'avons atteint qu'un monde où au lieu de 99 % de l'activité se trouvant sur L2, 90 % de l'activité se situe sur L2, et donc le résultat semble presque identique, à l'exception d'une perte irréversible de ce qui rend l'Ethereum L1 spécial.

Une vue proposée d'une "division du travail" entre L1 et L2s, source.

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

Amener plus d'utilisateurs sur L1 implique non seulement d'améliorer l'échelle, mais aussi d'autres aspects de L1. Cela signifie que plus de MEV restera sur L1 (au lieu de devenir un problème uniquement pour les L2), et il sera donc encore plus urgent de le gérer explicitement. Cela augmente considérablement la valeur d'avoir des temps de slot rapides sur L1. Et cela dépend également fortement de la vérification de L1 ("la Verge") se déroulant bien.

Clause de non-responsabilité：

1. Cet article est repris de [ Vitalik Buterin], Tous les droits d'auteur appartiennent à l'auteur original [Vitalik Buterin]. If there are objections to this reprint, please contact the Porte Apprendre et ils s’en occuperont rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.