Vitalik: Comment le protocole Ethereum devrait-il se développer au stade de surtension

Remarque: Cet article est la deuxième partie de la série d’articles récemment publiés par Vitalik, fondateur d’Ethereum, «L’avenir de l’accord Ethereum»Futures possibles pour le protocole Ethereum, partie 2: The Surge« , la première partie est montrée dans le rapport précédent de Bitchain Vision »Quoi d’autre peut être amélioré sur Ethereum pos»Compilé par Deng Tong, ce qui suit est le texte intégral de la deuxième partie:

Au début, il y avait deux stratégies de mise à l’échelle dans la feuille de route d’Ethereum.

L’un d’eux est « Sharding »: Chaque nœud n’a besoin que de vérifier et de stocker une petite partie des transactions, pas toutes les transactions dans la chaîne.C’est aussi ainsi que fonctionne tout autre réseau entre pairs (par exemple BitTorrent), nous pouvons donc certainement faire fonctionner la blockchain de la même manière.

L’autre est le protocole à 2 couches:Les réseaux seront au sommet d’Ethereum, ce qui leur permet de bénéficier pleinement de leur sécurité tout en gardant la plupart des données et l’informatique loin de la chaîne principale.Le «Protocole de couche 2» fait référence au canal d’état 2015, au plasma 2017 et aux Rollups 2019.Les rouleaux sont plus puissants que les canaux d’état ou le plasma, mais ils nécessitent beaucoup de bande passante de données sur chaîne.

Heureusement, d’ici 2019, Sharding Research a abordé la question de la vérification à grande échelle de la «disponibilité des données».En conséquence, les deux chemins ont fusionné et nous avons obtenu une feuille de route centrée sur le roulement, qui est toujours la stratégie de mise à l’échelle d’Ethereum aujourd’hui.

The Surge, 2023 Roadmap Edition.

La feuille de route centrée sur le rollup propose une division simple du travail: Ethereum L1 se concentre sur le fait de devenir une couche de fondation forte et décentralisée, tandis que L2 entreprend la tâche d’aider l’échelle de l’écosystème.Il s’agit d’un modèle récurrent dans toute la société: le système judiciaire (L1) n’est pas pour une super rapide et efficace, mais pour protéger les contrats et les droits de propriété, tandis que l’entrepreneur (L2) doit construire une couche de fondation solide sur cette base et amener les humains à (métaphoriquement et littéralement) Mars.

Cette année, la feuille de route centrée sur le rollup a connu un succès significatif: la bande passante de données Ethereum L1 a augmenté de manière significative grâce à des blobs EIP-4844, et plusieurs rollups EVM sont désormais dans la première phase.Des implémentations très hétérogènes et diversifiées d’éclats, où chaque L2 agit comme un « fragment » avec ses propres règles internes et sa logique est désormais une réalité.Mais comme nous l’avons vu, suivre cette voie a ses propres défis uniques.donc,Maintenant, notre mission est de terminer la feuille de route centrée sur le roulement et de résoudre ces problèmes tout en conservant la robustesse et la décentralisation qui distingue Ethereum L1.

Surge: objectifs clés

L1 + L2 sur 100 000+ TPS

Maintenir la décentralisation et la robustesse de L1

Au moins certains L2 héritent pleinement des attributs fondamentaux d’Ethereum (sans confiance, ouvert, résistant à la censure)

Interopérabilité maximale entre L2S.Ethereum devrait ressembler à un écosystème, pas à 34 blockchaines différentes.

La triade d’évolutivité

Le Triangle Impossible Scvancability est une idée proposée en 2017 qu’il estime qu’il existe une tension entre les trois propriétés de la blockchain: décentralisation (plus spécifiquement: faible coût de nœuds d’exécution), l’évolutivité (plus spécifiquement: gère un grand nombre de transactions) et la sécurité (Plus précisément: un attaquant doit détruire la plupart des nœuds de l’ensemble du réseau pour faire échouer une seule transaction).

Il convient de noter que le dilemme de la triade n’est pas un théorème, et les articles présentant le dilemme de la triade ne sont pas avec une preuve mathématique.Il donne un argument mathématique heuristique: si un nœud amical décentralisé (comme un ordinateur portable grand public) peut vérifier n transactions par seconde, et vous avez une chaîne qui traite les transactions par seconde, alors (i) chaque transaction ne peut être vue que par 1 / k nœuds, ce qui signifie qu’un attaquant ne peut casser que quelques nœuds pour entraîner de mauvaises transactions, ou (ii) votre nœud deviendra fort et votre chaîne n’est pas décentralisée.Le but de cet article est de ne jamais montrer que la rupture de la triade est impossible;

Au fil des ans, certaines chaînes hautes performances ont souvent affirmé qu’ils avaient résolu la triade sans prendre de mesures intelligentes au niveau de l’infrastructure, souvent en utilisant des compétences en génie logiciel pour optimiser les nœuds.Ceci est toujours trompeur, et courir les nœuds dans de telles chaînes est toujours beaucoup plus difficile que dans Ethereum.Cet article explore de nombreuses subtilités de la raison pour laquelle cela se produit (et pourquoi l’ingénierie logicielle du client L1 ne peut pas évoluer Ethereum lui-même seul).

Cependant,La combinaison de l’échantillonnage de la disponibilité des données (DAS) et du snark résout la triade: Il permet au client de vérifier qu’une certaine quantité de données est disponible et si un certain nombre d’étapes de calcul sont effectués correctement, tandis qu’une petite partie de ces données est téléchargée et la quantité de calculs exécutés est beaucoup plus faible.Le snark n’est pas crédible.L’échantillonnage de la disponibilité des données a un modèle de confiance minoritaire N subtil, mais il conserve les propriétés de base que les chaînes non échelables ont, et même 51% des attaques ne peuvent pas forcer le réseau à accepter de mauvais blocs.

Une autre façon de résoudre la triade est l’architecture du plasma, qui utilise des techniques intelligentes pour pousser la responsabilité de surveiller la disponibilité des données aux utilisateurs d’une manière compatible incitée.En 2017-2019, lorsque tout ce dont nous avions besoin pour faire évoluer l’informatique était une épreuve de fraude, les capacités de sécurité de Plasma étaient très limitées, mais le intérêt de l’architecture de plasma Snark a plus adapté à un plus large éventail de cas d’utilisation qu’auparavant.

Progrès supplémentaires dans DAS

Quels problèmes voulons-nous résoudre?

Au 13 mars 2024, lorsque la mise à niveau de Dencun a été mise en ligne, la blockchain Ethereum avait 3 « blobs » d’environ 125 kb toutes les 12 secondes, soit environ 375 Ko de bande passante disponibles par période.En supposant que les données de transaction sont directement affichées dans la chaîne, la transmission ERC20 est d’environ 180 octets, donc le TPS maximum de Rollups sur Ethereum est:

375000/12/180 = 173,6 TPS

Si nous ajoutons CallData d’Ethereum (maximum théorique: 30 millions de gaz par emplacement / 16 gaz par octet = 1 875 000 octets par emplacement), cela deviendra 607 tps.Pour Peerdas, il est prévu d’augmenter l’objectif de comptage BLOB à 8-16, ce qui nous donnera un calldata de 463-926 TPS.

Il s’agit d’une amélioration significative par rapport à Ethereum L1, mais cela ne suffit pas.Nous voulons plus d’évolutivité.Notre objectif à mi-parcours est de 16 Mo par emplacement, qui, s’il est combiné à des améliorations de la compression des données de puits, nous donnera environ 58 000 TP.

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

Peerdas est une implémentation relativement simple de « l’échantillonnage unidimensionnel ».Chaque blob dans Ethereum est un polynôme d’ordre 4096 sur le domaine Prime 253 bits.Nous diffusons les «actions» du polynôme, où chaque action se compose de 16 évaluations à 16 coordonnées adjacentes tirées d’un ensemble total de 8192 coordonnées.Le blob peut être restauré par n’importe quelle évaluation 4096 des 8192 (en utilisant les paramètres actuellement recommandés: 64 des 128 échantillons possibles).

Peerdas fonctionne en faisant en sorte que chaque client écoute un petit réseau quantique, où le premier sous-réseau diffuse le premier échantillon de tout blob et demande également ce qui est nécessaire sur d’autres sous-réseaux en demandant aux pairs du réseau mondial P2P. Écoutez différents sous-réseaux).La version plus conservatrice des sous-réseaux utilise uniquement le mécanisme de sous-réseau et n’a pas de couches de pairs de demande supplémentaires.La recommandation actuelle est que les nœuds participant à la preuve de pieu utilisent des sous-réseaux et les autres nœuds (c’est-à-dire le « client ») utilisent Peerdas.

En théorie, nous pouvons évoluer l’échantillonnage 1D assez loin: si nous augmentons le nombre de BLOB maximum à 256 (de sorte que la cible est 128), alors nous atteindrons la cible de 16 Mo, tandis que l’échantillonnage de la disponibilité des données ne coûte que 16 échantillons par nœud * 128 blobs * 512 octets par blob par échantillon = 1 Mo de bande passante de données par emplacement.Ce n’est que dans notre tolérance: c’est possible, mais cela signifie que les clients limités à la bande passante ne peuvent pas échantillonner.Nous pouvons optimiser cela en réduisant le nombre de blobs et en augmentant la taille des blobs, mais cela rend la reconstruction plus coûteuse.

Donc, en fin de compte, nous voulons aller plus loin et faire un échantillonnage 2D, qui non seulement échantillonne au hasard dans le blob, mais aussi entre les blobs.Les propriétés linéaires promises par KZG sont utilisées pour « étendre » l’ensemble Blob dans un bloc par de nouvelles listes de « blobs virtuelles » codées en cod.

Échantillonnage 2D.

Surtout, la mise à l’échelle promise par calcul ne nécessite pas de blobs, donc le programme est fondamentalement convivial pour la construction de blocs distribués.Les nœuds qui construisent réellement le bloc n’ont besoin que de faire des promesses Blob KZG et peuvent compter sur DAS pour vérifier la disponibilité des blobs.1D DAS est également essentiellement convivial pour la construction de blocs distribués.

Quelles sont les liens avec la recherche existante?

Article original Présentation de la disponibilité des données (2018):https://github.com/ethereum/research/wiki/a-note-on-data-availabilité-and-erasure-coding

Documents de suivi:https://arxiv.org/abs/1809.09044

Post interprète pour DAS, paradigme:https://www.paradigm.xyz/2022/08/das

KZG a promis la disponibilité 2D:https://ethresear.ch/t/2d-data-carabilitabilité-with-kate-commitments/8081

Peerdas sur Ethresear.ch:https://ethreear.ch/t/peerdas-a-simpler-das-approach-using-battle-testest-p2p-components/16541Et papiers:https://eprint.iacr.org/2024/1362

EIP-7594:https://eips.ethereum.org/eips/eip-7594

Sous-réseaux sur Ethresear.ch:https://ethreear.ch/t/subnetdas-an-intermediate-das-approach/17169

Différences subtiles de récupérabilité dans l’échantillonnage 2D:https://ethresear.ch/t/nuances-of-data-recoverabilité-in-data -availabilité-sampling/16256

Que faut-il faire d’autre et quels compromis doivent être pesés?

L’étape suivante consiste à terminer la mise en œuvre et le déploiement de Peerdas.Depuis lors, l’augmentation du nombre de Blob sur Peerdas est un effort progressif, tout en observant soigneusement le réseau et en améliorant le logiciel pour la sécurité.Dans le même temps, nous espérons faire plus de travaux académiques sur la formalisation des DAS et d’autres versions du DAS et son interaction avec des questions telles que la sécurité des règles de sélection des fourchettes.

À l’avenir, nous devons faire plus pour découvrir la version idéale de 2D DAS et prouver ses fonctionnalités de sécurité.Nous espérons également éventuellement migrer de KZG vers une alternative résistante au quantum sans configuration de confiance.Pour le moment, nous ne savons pas quels candidats sont amicaux pour la construction de blocs distribués.Même la technique coûteuse « forte » pour utiliser le Stark récursif pour générer des preuves de validité pour la reconstruction des lignes et des colonnes ne suffit pas, car techniquement la taille de hachage de Stark est O (log (n) * log (log (n))) (avec smor ), Stark est en fait presque aussi grand que toute la place.

À long terme, je pense que le chemin de la réalité est:

• Outil Idéal 2D DAS;

• Tenez-vous à 1D DAS, en sacrifiant l’efficacité de la bande passante d’échantillonnage pour la simplicité et la robustesse et l’acceptation des plafonds de données inférieurs;

• (Pivot dur) Abandonnez le DA et embrassez complètement le plasma comme l’architecture principale de niveau 2 sur lesquelles nous nous concentrons.

Nous pouvons les regarder en pesant la lunette:

Notez que même si nous décidons d’étendre l’exécution directement sur L1, ce choix demeure.En effet, si L1 va gérer un grand nombre de TPS, les blocs L1 deviendront très importants et le client aura besoin d’un moyen efficace de vérifier qu’ils sont corrects, nous devons donc utiliser les mêmes techniques qui prennent en charge le rouleau (ZK -Evm et das) et L1.

Comment cela interagit-il avec le reste de la feuille de route?

Si la compression des données est mise en œuvre (voir ci-dessous), la demande de DAS 2D sera réduite, ou du moins retardée, et si le plasma est largement utilisé, la demande de DAS 2D sera encore réduite.Le DAS présente également des défis aux protocoles et mécanismes distribués de construction de blocs: bien que DAS soit théoriquement amical à la reconstruction distribuée, il doit être combiné dans la pratique avec le mécanisme de sélection des fourches qui comprend les propositions de liste et leur environnement.

Compression de données

Quels problèmes voulons-nous résoudre?

Chaque transaction dans Rollup occupe beaucoup d’espace de données sur chaîne: la transmission ERC20 prend environ 180 octets.Cela limite l’évolutivité du protocole de couche 2 même lors de l’utilisation d’échantillonnage idéal de disponibilité des données.16 Mo par emplacement, nous obtenons:

16000000 / 12/180 = 7407 TPS

Et si nous pouvons résoudre le dénominateur en plus de résoudre le numérateur et de faire en sorte que chaque transaction dans Rollup occupe moins d’octets sur la chaîne?

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

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

Le gain le plus simple est la compression zéro-octet: remplacez chaque séquence long-octe-octets par deux octets représentant le nombre d’octets zéro.En allant plus loin, nous profitons des propriétés spécifiques de la transaction:

• Agrégation de signature– Nous passons de la signature ECDSA à la signature BLS, qui possède des propriétés qui peuvent combiner de nombreuses signatures ensemble pour former une seule signature qui prouve la validité de toutes les signatures d’origine.L1 ne considère pas cela car le coût de validation de la validation (même en utilisant l’agrégation) est plus élevé, mais dans des environnements rares de données comme L2, ils rendent sans doute significatif.La fonction d’agrégation de l’ERC-4337 fournit un moyen d’y parvenir.

• Remplacer l’adresse par des pointeurs– Si vous avez déjà utilisé une adresse, nous pouvons remplacer l’adresse de 20 octets par un pointeur de 4 octets vers l’emplacement historique.Ceci est nécessaire pour atteindre le gain maximal, bien qu’il nécessite des efforts pour réaliser, car il nécessite (au moins une partie de) l’histoire de la blockchain pour faire efficacement partie du pays.

• Sérialisation personnalisée des valeurs de transaction– La plupart des valeurs de transaction n’ont que très peu de nombres, par exemple.0,25 ETH est exprimé comme 250 000 000 000 000 000 000 WEI.Gas Max-BaseFees fonctionne de manière similaire aux frais de priorité.Par conséquent, nous pouvons utiliser des formats de points flottants décimaux personnalisés, ou même des dictionnaires de valeurs particulièrement courantes, représentant la plupart des valeurs de change très compactes.

Quelles sont les liens avec la recherche existante?

Exploration de Sequence.xyz:https://sequence.xyz/blog/compressing-calldata

CallData Optimization Contracts for L2, de Scopelift:https://github.com/scopelift/l2-optimizoooors

Une autre stratégie – Rollup (aka zkrollup) basé sur des preuves de validité des différences de statut de version au lieu des transactions:https://ethreear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on–l1/9975-L2-Data Footprint

Portefeuille BLS – AGLÉGATION BLS via ERC-4337:https://github.com/getwax/bls-wallet

Que faut-il faire d’autre et quels compromis doivent être pesés?

La tâche principale à faire est de mettre en œuvre le plan ci-dessus.Les principaux compromis sont:

• Le passage aux signatures BLS demande un effort énorme et réduit la compatibilité avec les puces matérielles de confiance qui améliorent la sécurité.Il peut être remplacé par l’emballage ZK-Snark d’autres schémas de signature.

• La compression dynamique (comme le remplacement de l’adresse par des pointeurs) complique le code client.

• La publication des différences d’état vers une chaîne plutôt qu’une transaction réduit l’audit et rend de nombreux logiciels (tels que les navigateurs de blocs).

Comment cela interagit-il avec le reste de la feuille de route?

L’adoption de l’ERC-4337, et l’incorporation ultime de certains de ses contenus dans L2 EVM, peuvent considérablement accélérer le déploiement de la technologie d’agrégation.L’incorporation de parties de l’ERC-4337 dans L1 peut accélérer son déploiement sur L2.

Plasma généralisé

Quels problèmes voulons-nous résoudre?

Même avec des blobs de 16 Mo et une compression de données, 58 000 TPs ne suffit pas nécessairement pour prendre complètement le contrôle des consommateurs, des zones sociales ou autres zones de bande passante élevées décentralisées, ce qui est particulièrement vrai si nous commençons à penser à la vie privée, ce qui pourrait rendre l’évolutivité moins 3 à 8x.Pour les applications à grande capacité et à faible valeur, une option aujourd’hui est Validium, qui désactive les données 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 en permanence tous les fonds d’utilisateurs .Mais nous pouvons faire mieux.

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

Le plasma est une solution d’extension qui implique que les opérateurs publient des blocs hors de la chaîne et plaçant les racines Merkle de ces blocs sur la chaîne (contrairement aux rollups, les rollups mettent tout le bloc sur la chaîne).Pour chaque bloc, l’opérateur envoie une succursale Merkle à chaque utilisateur, prouvant ce qui s’est passé ou rien est arrivé aux actifs de cet utilisateur.Les utilisateurs peuvent extraire des actifs en fournissant une branche Merkle.Surtout, la succursale ne doit pas être enracinée dans le dernier état – donc même si la disponibilité des données échoue, les utilisateurs peuvent toujours récupérer leurs actifs en révoquant le dernier état disponible.Si un utilisateur soumet une branche non valide (par exemple, la sortie d’un actif qu’il a envoyé à quelqu’un d’autre ou que l’opérateur crée un actif hors de l’air), le mécanisme de défi sur la chaîne peut déterminer à qui l’appartenance appartient correctement.

Diagramme de la chaîne de trésorerie de plasma.La transaction de la pièce de coût I est placée dans la première position de l’arbre.Dans cet exemple, en supposant que tous les arbres précédents sont valables, nous savons qu’Eve possède actuellement COIN 1, David a COIN 4 et George a COIN 6.

Les premières versions du plasma ne peuvent gérer que les cas d’utilisation de paiement et ne peuvent pas être promus efficacement.Cependant, si nous avons besoin que chaque racine soit vérifiée avec Snark, alors le plasma devient plus puissant.Chaque jeu de défi peut être grandement simplifié car nous éliminons la plupart des chemins possibles pour la tricherie de l’opérateur.De nouveaux chemins ont également été ouverts, permettant à la technologie du plasma de s’étendre à un plus large éventail de classes d’actifs.Enfin, les utilisateurs peuvent retirer des fonds immédiatement sans attendre une semaine de défi sans attendre la période de défi.

Une façon de fabriquer des chaînes plasmatiques EVM (pas la seule façon): construire un arbre UTXO parallèle à l’aide de ZK-Snark, reflétant les changements d’équilibre effectués par EVM et définir quelle est la cartographie unique de la « même pièce » dans l’histoire.Ensuite, vous pouvez construire la structure du plasma sur cette base.

Un aperçu important est que les systèmes de plasma n’ont pas besoin d’être parfaits.Même si vous ne pouvez protéger qu’une partie de vos actifs (par exemple, même si ce ne sont que des jetons qui n’ont pas bougé au cours de la semaine dernière), vous avez considérablement amélioré le statu quo des EVM hyperscalables, ce qui est une validation.

Un autre type de structure est une structure de plasma / rouleaux hybrides, comme Intmax.Ces structures mettent une très petite quantité de données sur une chaîne (par exemple 5 octets), et ce faisant, vous pouvez obtenir des propriétés entre le plasma et le rouleau: dans le cas Intmax, vous pouvez obtenir une évolutivité et une intimité de niveaux très élevés, même dans le 16 Mb dans le monde, la capacité théorique est d’environ 16 000 000 / 12/5 = 266 667 TPS.

Quelles sont les liens avec la recherche existante?

Papier à plasma d’origine:https://plasma.io/plasma-deprecated.pdf

Plasma Cash:https://ethreear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298

Flux de trésorerie de plasma:https://hackmd.io/dgzmjirjszcyvl4lujzxnq?view#-exit

Intmax (2023):https://eprint.iacr.org/2023/1082

Que faut-il faire d’autre et quels compromis doivent être pesés?

La tâche principale restante est de mettre le système de plasma en production.Comme mentionné ci-dessus, le «plasma et validium» ne sont pas des oppositions binaires: n’importe quel validium peut améliorer au moins un peu de performance de sécurité en ajoutant la fonctionnalité du plasma au mécanisme de sortie.La recherche vise en partie à obtenir les meilleurs attributs de l’EVM (en termes d’exigences de confiance, de coût de gaz L1 pire et de vulnérabilité DOS) et de structures alternatives spécifiques à l’application.De plus, le plasma a une plus grande complexité conceptuelle par rapport aux rouleaux et doit être directement résolu en étudiant et en construisant un meilleur cadre général.

L’inconvénient principal de l’utilisation de conceptions de plasma est qu’ils sont plus dépendants de l’opérateur et plus difficiles à «basés sur», bien que les conceptions de plasma / rouleaux hybrides évitent souvent cette faiblesse.

Comment cela interagit-il avec le reste de la feuille de route?

Plus la solution de plasma est efficace, moins la stress du L1 doit avoir des capacités de disponibilité des données à haute performance.Le déplacement de l’activité vers L2 réduit également la pression du MEV sur L1.

Système d’épreuve L2 mature

Quels problèmes voulons-nous résoudre?

Aujourd’hui, la plupart des Rollups ne sont pas réellement dignes de confiance;Dans certains cas, le système de preuve n’existe même pas du tout, ou même s’il existe, il n’a qu’une fonction de « consultation ».Les principaux sont (i) certains rouleaux spécifiques à l’application, tels que le carburant, qui sont sans confiance, et (ii) à ce jour, l’optimisme et l’arbitrum, deux Rolups EVM complets ont mis en œuvre une fiducie partielle. phase ».La raison pour laquelle les Rollups ne se sont pas développés davantage est de s’inquiéter des bogues dans le code.Nous devons faire confiance à Rollup, nous devons donc résoudre ce problème de front.

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

Tout d’abord, passons en revue le système « étape » qui a été initialement introduit dans cet article.Il existe des exigences plus détaillées, mais le résumé est le suivant:

• Étape 0:L’utilisateur doit être en mesure d’exécuter le nœud et de synchroniser la chaîne.Si la vérification est pleinement fiable / centralisée.

• Phase 1:Il doit y avoir un système d’épreuve (sans confiance) pour s’assurer que seules les transactions valides sont acceptées.Il existe un comité de sécurité qui peut annuler le système de preuve, mais il n’y a qu’un seuil de vote de 75%.De plus, la partie de blocage quorum du conseil (c’est-à-dire plus de 26%) doit être située à l’extérieur des principales sociétés qui ont construit Rollup.Les mécanismes de mise à niveau plus faibles (tels que DAO) sont autorisés, mais il doit y avoir un retard suffisamment long pour que si une mise à niveau malveillante est approuvée, les utilisateurs peuvent quitter les fonds avant la mise à niveau en ligne.

• Phase 2:Il doit y avoir un système d’épreuve (non fiable) pour s’assurer que seules les transactions valides sont acceptées.Le Conseil n’est autorisé à intervenir que s’il y a une erreur prouvée dans le code, par exemple.Si deux systèmes de preuve redondants sont incompatibles les uns avec les autres, ou si un système de preuve accepte deux racines post-état différentes du même bloc (ou n’accepte rien pendant assez longtemps, comme une semaine).Le mécanisme de mise à niveau est autorisé, mais il doit y avoir un long retard.

Notre objectif est d’atteindre la deuxième étape.Le principal défi pour atteindre la deuxième phase est de gagner suffisamment de confiance pour prouver que le système est réellement digne de confiance.Il existe deux façons principales de le faire:

• Vérification formelle:Nous pouvons utiliser des techniques mathématiques et informatiques modernes pour prouver (optimiste ou validité) que le système accepte uniquement les blocs qui transmettent la spécification EVM.Ces technologies existent depuis des décennies, mais les avancées récentes (comme Lean 4) les rendent plus pratiques, et les avancées dans les preuves assistées par l’IA peuvent accélérer cette tendance.

• Releurs multiples:Faire des systèmes à preuves multiples et investir des fonds dans 2 sur 3 (ou plus) multi-signatures entre ces systèmes de preuve et le Conseil de sécurité (et / ou d’autres widgets avec des hypothèses de confiance, tels que Tee).Si le système est d’accord, le Conseil n’a aucun pouvoir.S’ils ne sont pas d’accord, le Conseil ne peut en choisir qu’un et ne peut pas imposer unilatéralement sa propre réponse.

Un diagramme stylisé de multi-provenants, combinant un système de preuve optimiste, un système de preuve d’efficacité et un comité de sécurité.

Quelles sont les liens avec la recherche existante?

EVM K Sémantique (travaux de vérification formelle depuis 2017):https://github.com/runtimeverification/evm-semantics

Demo sur l’idée de personnes multiprovenées (2022):https://www.youtube.com/watch?v=6hfvzcwt6yi

Taiko prévoit d’utiliser plusieurs épreuves:https://docs.taiko.xyz/core-concepts/multi-proofts/

Que faut-il faire d’autre et quels compromis doivent être pesés?

Il y en a beaucoup pour la vérification formelle.Nous devons créer une version officielle validée de l’ensemble du realable de 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 simplifier considérablement les tâches: nous pouvons faire un prover snark officiellement validé pour la plus petite machine virtuelle, par exemple.RISC-V ou Caire, puis écrivez une implémentation de l’EVM dans ce minimum de machine virtuelle (et prouve officiellement son équivalent à certaines autres spécifications EVM).

Pour plusieurs provers, il y a deux pièces principales.Premièrement, nous devons avoir suffisamment de confiance dans au moins deux systèmes de preuve différents, dont chacun est assez sécurisé, et s’ils s’écraseront, ils s’écraseront pour des raisons différentes et non pertinentes (afin qu’ils ne s’écrasent pas en même temps).Deuxièmement, nous devons obtenir un niveau d’assurance très élevé dans la logique sous-jacente du système de preuve de fusion.Ceci est un petit morceau de code.Il existe plusieurs façons de le rendre très petit – juste des fonds de magasin dans un contrat multi-signature sécurisé dont la signature est un contrat représentant un système de preuve personnelle, mais cela a un coût élevé de gaz en chaîne.Il est nécessaire de trouver un certain équilibre entre l’efficacité et la sécurité.

Comment cela interagit-il avec le reste de la feuille de route?

L’activité mobile vers L2 réduit la pression MEV sur L1.

Améliorations d’interopérabilité cross-L2

Quels problèmes voulons-nous résoudre?

L’un des plus grands défis de l’écosystème L2 d’aujourd’hui est qu’il est difficile pour les utilisateurs de manipuler.De plus, l’approche la plus simple réintroduit souvent les hypothèses de confiance: ponts centralisés, clients RPC, etc.Si nous prenons l’idée que L2 fait partie d’Ethereum au sérieux, nous devons faire en utilisant l’écosystème L2, on comme à utiliser un écosystème Ethereum unifié.

Un exemple d’un mauvais mauvais (même dangereux: j’ai personnellement perdu 100 $ pour la mauvaise sélection de chaîne ici) à travers L2 UX – bien que ce ne soit pas la faute de PolyMarket, à travers l’interopérabilité L2 devrait être pour le portefeuille et la responsabilité des normes Ethereum (ERC).Dans un écosystème Ethereum bien géré, l’envoi de jetons de L1 à L2 ou d’un L2 à un autre devrait être comme l’envoi de jetons dans le même L1.

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

Il existe de nombreuses catégories d’améliorations d’interopérabilité Cross-L2.D’une manière générale, la façon de poser ces questions est de noter qu’en théorie, Ethereum centré sur Rollup est le même que L1 effectuant un fragment, puis demandez quels aspects de la version Ethereum L2 actuelle sont en pratique, en termes de lacunes entre les idéaux et la version Ethereum L2 actuelle.En voici quelques:

• Adresse spécifique du lien:La chaîne (L1, Optimisme, Arbitrum …) devrait faire partie de l’adresse.Une fois implémenté, vous pouvez implémenter le processus d’envoi Cross-L2 en mettant simplement l’adresse dans le champ « Envoyer », et le portefeuille peut déterminer comment envoyer en arrière-plan (y compris l’utilisation du protocole de pont).

• Demandes de paiement spécifiques à la chaîne:Faire des messages sous la forme de « Envoyez-moi un jeton Y Type X sur la chaîne Z » doit être simple et standardisé.Il existe deux principaux cas d’utilisation pour cela: (i) le paiement, qu’il s’agisse d’un individu pour un individu ou un individu à un service marchand, et (ii) un DAPP demandant des fonds, par exemple.L’exemple de polymarket ci-dessus.

• Échange croisé et paiement du gaz:Il devrait y avoir un protocole ouvert standardisé pour exprimer des opérations croisées telles que « J’envoie 1 ETH sur l’optimisme à quelqu’un qui envoie 0,9999 ETH sur Arbitrum » et « J’envoie 0,0001 ETH sur l’optimisme » N’importe qui inclut ceci sur les transactions arbitrum « . 7683 est une tentative de la première, tandis que RIP-7755 est une tentative de ce dernier, bien que les deux soient plus généraux que ces cas d’utilisation spécifiques.

• Client léger:Les utilisateurs devraient être en mesure de vérifier réellement la chaîne avec laquelle ils interagissent, plutôt que de simplement faire confiance au fournisseur RPC.Helios de la crypto-monnaie A16Z a fait cela pour Ethereum lui-même, mais nous devons étendre cette insidients à L2.ERC-3668 (CCIP-Read) est une stratégie pour y parvenir.

Comment les clients légers mettent à jour le point de vue de leur chaîne d’en-tête Ethereum.Une fois que vous avez une chaîne d’en-tête, vous pouvez utiliser Merkle Proof pour vérifier n’importe quel objet d’état.Une fois que vous avez le bon objet d’état L1, vous pouvez vérifier n’importe quel objet d’état sur L2 à l’aide de Merkle Proof (ou peut-être de signature si vous souhaitez vérifier la pré-confirmation).HéliosOnt fait le premier.S’étendre à ce dernier est un défi de standardisation.

• Portefeuille de clés:Aujourd’hui, si vous souhaitez mettre à jour la clé qui contrôle un portefeuille de contrat intelligent, vous devez le faire sur toutes les N chaînes où se trouve ce portefeuille.Un portefeuille de clés est une technique qui permet à la clé d’exister dans un emplacement (que ce soit sur L1 ou plus tard sur L2), puis à lire à partir de n’importe quel L2 qui a une copie du portefeuille.Cela signifie que la mise à jour ne doit se produire qu’une seule fois.Pour améliorer l’efficacité, le portefeuille de clés exige que L2 ait un moyen standardisé de lire L1 sans frais;

Un diagramme stylisé du fonctionnement d’un portefeuille de clés.

• Idée plus radicale de «pont de jeton partagé»:Imaginez un monde où tout L2 est un rollup éprouvé, avec chaque créneau dédié à Ethereum.Même dans ce monde, le transfert des actifs «locaux» d’un L2 à un autre nécessite un retrait et un dépôt, ce qui nécessite une grande quantité de gaz L1.Une façon de résoudre ce problème consiste à créer un rollup minimum partagé dont la seule fonction est de maintenir les soldes dont L2 a le nombre de types de jetons et de permettre à ces soldes d’être mises à jour collectivement via une série de multisegments.L2 Envoi de l’opération initiée par n’importe quel L2.Cela permettra la transmission à travers L2 sans payer pour le gaz L1 par transmission, et également sans avoir besoin de technologies basées sur les fournisseurs de liquidités (comme ERC-7683).

• Composabilité synchrone:Permet des appels synchrones entre L2 et L1 spécifiques ou entre plusieurs L2.Cela peut aider à améliorer l’efficacité financière du protocole Defi.Le premier peut être fait sans une coordination croisée-L2; ce dernier nécessite un séquençage partagé.Rollup est automatiquement amical avec toutes ces technologies.

Quelles sont les liens avec la recherche existante?

Adresse spécifique de 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 keystore de défilement:https://hackmd.io/@haichen/keystore

Helios:https://github.com/a16z/helios

ERC-3668 (parfois appelé CCIP-Read):https://eips.ethereum.org/eips/eip-3668

La proposition de Justin Drake pour « basée sur (partagée) précontenue »::https://ethreear.ch/t/based-preconfirmations/17353

L1Sload (RIP-7728):https://ethereum-magicicic.org/t/rip-7728-l1sload-precompile/20388

Appels distants optimistes:https://github.com/ethereum-optimism/ecosystem-Contributions/issues/76

Aggayer, qui comprend l’idée de partager le pont de jetons:https://github.com/agglayer

Que faut-il faire d’autre et quels compromis doivent être pesés?

De nombreux exemples ci-dessus sont confrontés au dilemme standard de quand standardiser et quelles couches de normalisation.Si la normalisation est trop tôt, vous risquez de risquer de solutions de mauvaise qualité.Si la normalisation est trop tard, elle peut provoquer une fragmentation inutile.Dans certains cas, il existe des solutions à court terme qui sont plus faibles mais plus faciles à mettre en œuvre, ainsi que des solutions à long terme qui sont «enfin correctes» mais prennent un certain temps à réaliser.

Ce qui est unique dans cette section, c’est que ces tâches ne sont pas seulement des problèmes techniques: ce sont (peut-être principalement!) Des problèmes sociaux.Ils ont besoin de L2 et de portefeuilles et L1 pour travailler ensemble.Notre capacité à traiter avec succès ce problème est un test de notre capacité à s’unir en tant que communauté.

Comment cela interagit-il avec le reste de la feuille de route?

La plupart de ces suggestions sont des structures «plus élevées» et n’ont donc pas beaucoup d’impact sur les considérations L1.Une exception est le tri partagé, qui a un grand impact sur les MEV.

Exécution étendue sur L1

Quels problèmes voulons-nous résoudre?

Si L2 devient très évolutif et réussi, mais que L1 ne peut toujours gérer que de très petites transactions, il existe de nombreux risques sur Ethereum:

• La situation économique des actifs de l’ETH devient plus dangereuse, ce qui affecte à son tour la sécurité à long terme du réseau.

• De nombreux L2 bénéficient d’un lien étroit avec l’écosystème financier très développé sur L1, et si cet écosystème est considérablement affaibli, la motivation à devenir L2 (plutôt qu’un L1 distinct) sera affaiblie.

• Il faut beaucoup de temps pour que le L2 ait exactement la même sécurité que le L1.

• Si L2 échoue (par exemple, en raison des opérations malveillantes ou des transporteurs de disparition), l’utilisateur doit encore passer par L1 pour récupérer ses actifs.Ainsi, L1 doit être suffisamment fort pour au moins être en mesure de vraiment gérer la fin du L2 très complexe et déroutant.

Pour ces raisons, il est utile de continuer à étendre le L1 lui-même et de s’assurer qu’il peut continuer à s’adapter à de plus en plus d’utilisations.

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

La façon la plus simple de se développer est d’ajouter simplement des limites de gaz.Cependant, cela a le risque de centraliser L1, affaiblissant ainsi un autre attribut important qui rend Ethereum L1 si puissant: sa crédibilité en tant que forte couche sous-jacente.Il y a eu un débat sur la façon dont les restrictions de gaz simples sont augmentées pour être durables, et cela variera également en fonction de la mise en œuvre d’autres technologies pour faciliter la vérification des blocs plus importants (par exemple, l’expiration historique, le apatride, la preuve de validité EVM L1).Une autre chose importante qui nécessite une amélioration continue est l’efficacité du logiciel client Ethereum, qui est plus optimisée aujourd’hui qu’il y a cinq ans.Une stratégie de restriction efficace du gaz L1 impliquera d’accélérer ces techniques de vérification.

Une autre stratégie de mise à l’échelle consiste à identifier des fonctionnalités spécifiques et des types informatiques qui peuvent devenir moins chers sans compromettre la dispersion du réseau ou ses propriétés de sécurité.Des exemples de cela comprennent:

• Eof– Un nouveau format Bytecode EVM qui est plus statique pour l’analyse et permet une implémentation plus rapide.Compte tenu de ces efficacités, un coût de gaz inférieur peut être donné au bytecode EOF.

• Prix ​​multidimensionnel du gaz– L’établissement de dépenses de base et de limites de base distinctes sur l’informatique, les données et le stockage peut augmenter la capacité moyenne d’Ethereum L1 sans augmenter sa capacité maximale (et ainsi créer de nouveaux risques de sécurité).

• Réduire les coûts de gaz pour des opcodes spécifiques et précompilé– Historiquement, nous avons effectué plusieurs cycles d’augmentation des coûts de gaz sur certaines opérations sous-prix pour éviter les attaques de déni de service.Nous avons fait moins mais pouvons faire plus, et c’est de réduire le coût du gaz pour les opérations trop chères.Par exemple, l’ajout est beaucoup moins cher que la multiplication, mais le coût des opcodes ADD et MUL est actuellement le même.Nous pouvons rendre ajouter moins cher, et encore plus simple (comme PUSH) moins cher.Il existe de nombreux EOF dans son ensemble.

• EVM-MAX et SIMD: EVM-MAX (« Extensions arithmétiques modulaires ») est une proposition qui permet des mathématiques modulaires à grand nombre natives plus efficaces en tant que module distinct pour EVM.Les valeurs calculées par les calculs EVM-MAX ne peuvent être accessibles que par d’autres opcodes EVM-MAX, sauf si c’est exporté intentionnellement;SIMD (« Multi-Data d’instructions unique ») est une proposition qui permet une exécution efficace des mêmes instructions sur un tableau de valeurs.Ensemble, les deux peuvent créer un puissant coprocesseur avec EVM qui peut être utilisé pour implémenter plus efficacement les opérations de chiffrement.Ceci est particulièrement utile pour les protocoles de confidentialité et les systèmes d’épreuve L2, ce qui contribuera à l’expansion L1 et L2.

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

Enfin, la troisième stratégie est le rouleau natif (ou « Rollup intégré et inscrit des rouleaux »): essentiellement, de nombreux exemplaires d’EVM fonctionnant en parallèle, formant un modèle équivalent aux modèles que Rollup peut fournir, mais plus nativement nativement dans le protocole.

Quelles sont les liens avec la recherche existante?

La feuille de route de l’extension Ethereum L1 de Polynya:https://polynya.mirror.xyz/epjU72rsyncfb-jk52_Uyi7HUHJ-W_ZM735NDP7ALKAQ

Prix ​​de gaz multidimensionnel: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-magicicican.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168

Simd:https://eips.ethereum.org/eips/eip-616

Rollup natif:https://mirror.xyz/ohotties.eth/p1qsccwj2fz9cqo3_6kyi4s2chw5k5tmegogk6io1ge

Entretien avec Max Resnick sur la valeur de l’extension L1:https://x.com/banklesshq/status/1831319419739361321

Justin Drake à propos de l’extension avec Snark et Rollup natif:https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

Que faut-il faire d’autre et quels compromis doivent être pesés?

Il existe trois stratégies pour les extensions L1 qui peuvent être exécutées individuellement ou en parallèle:

• Les technologies améliorées (par exemple le code client, le client sans état, l’expiration historique) facilitent L1, puis augmentent les limites de gaz

• Réduisez le coût d’une opération spécifique et augmentez la capacité moyenne sans augmenter le risque de pire des cas

• Rollup natif (c’est-à-dire « Créer n répliques parallèles de l’EVM », bien qu’elle puisse fournir beaucoup de flexibilité aux développeurs dans le déploiement des paramètres des répliques)

Il convient de comprendre que ce sont des technologies différentes avec différents compromis.Par exemple, Native Rollup a plusieurs des mêmes faiblesses que Rollup ordinaire en termes de composibilité: vous ne pouvez pas envoyer une seule transaction pour effectuer des opérations de manière synchrone sur plusieurs transactions, tout comme vous pouvez gérer des contrats sur le même L1 (ou L2).L’augmentation des restrictions de gaz prive d’autres avantages qui peuvent être obtenus en facilitant la vérification de L1, comme l’augmentation du pourcentage d’utilisateurs exécutant les nœuds de vérification et l’augmentation des parties prenantes individuelles.Faire des opérations spécifiques dans EVM moins chère (selon la façon dont elle est opérée) peut augmenter la complexité globale de l’EVM.

Une grande question à laquelle une feuille de route de l’extension L1 doit être répondue est: quelle est la vision ultime de L1 et L2?De toute évidence, il est ridicule de tout faire sur L1: les cas d’utilisation potentiels ont des centaines de milliers de transactions par seconde, ce qui rendra L1 complètement non vérifié (sauf si nous empruntions l’itinéraire de roulement natif).Mais nous avons besoin de certains principes directeurs afin que nous puissions nous assurer que nous ne provoquons pas une situation où nous augmentons la limite de gaz de 10 fois, blessant sérieusement la décentralisation de Ethereum L1 et constatant que nous entrons dans un monde, pas 99% de l’activité est sur L2 et 90% de l’activité est sur L2, donc les résultats se ressemblent presque, à l’exception de la plupart des pertes irréversibles de la particularité d’Ethereum L1.

Un point de vue proposé sur la «division du travail» entre L1 et L2

Comment cela interagit-il avec le reste de la feuille de route?

Faire plus d’utilisateurs dans L1 signifie améliorer non seulement l’échelle mais d’autres aspects de L1.Cela signifie que davantage de MEV resteront sur L1 (plutôt que d’être simplement un problème avec L2), il est donc plus urgent de y faire face explicitement.Il augmente considérablement la valeur du temps de plage rapide sur L1.Il dépend également fortement de savoir si la vérification L1 (« le verge ») s’est bien déroulée.

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