Paradigm : Quelle est la suite après la mise à niveau de Cancun d'Ethereum ?
TechFlow SélectionTechFlow Sélection
Paradigm : Quelle est la suite après la mise à niveau de Cancun d'Ethereum ?
En raison de la demande induite, augmenter la limite de gaz L1 n'aurait en réalité que peu d'effet.
Dédié à des analyses Web3 approfondiesRédaction : Georgios Konstantopoulos
Traduction : TechFlow
Introduction
Ce document vise à présenter les propositions de l'équipe Reth de Paradigm concernant les EIP (Ethereum Improvement Proposals) qui devraient être incluses dans le prochain hard fork EL après Cancun — la fourchette de Prague — ainsi que leurs perspectives sur le programme « EL Core Development » pour 2024. Les opinions exprimées ici reflètent uniquement celles de l'équipe Reth à ce jour et ne représentent pas nécessairement la position globale de Paradigm.
Résumé
Nous estimons que le hard fork de Prague pourrait être déployé sur les réseaux de test Ethereum au troisième trimestre 2024, suivi d’un déploiement sur le réseau principal avant la fin de l’année. Il devrait inclure :
-
Tout EIP lié au staking, comme l’EIP-7002, qui permet le restaking et des pools de staking non fiables.
-
Des modifications indépendantes de l’EVM.
-
Nous sommes prêts à collaborer avec toute équipe intéressée pour approfondir les questions techniques liées à Prague ou aux futurs hard forks EL, en offrant accompagnement ou aide au développement du codebase Reth.
À faire :
-
Nous considérons prioritaires les EIP suivants : 7002, 6110 et 2537.
-
Nous soutenons la spécification formelle du format EOF (EVM Object Format), mais souhaitons qu’un périmètre clair soit rapidement défini, accompagné d’un méta-EIP consacré à ce cadre.
-
Nous sommes favorables à une augmentation du maximum Blob Gas dans l’EIP-4844. Bien que nous n’ayons pas d’opinion tranchée sur la valeur exacte, nous invitons les spécialistes des données à collaborer avec nous sur cette question.
-
Nous sommes disposés à implémenter une version de l’EIP-7547 basée sur des listes inclusives afin de renforcer la résistance à la censure au niveau local.
À ne pas faire :
-
Nous ne soutenons pas l’intégration des Verkle Tries dans le hard fork de Prague, bien que nous appuyions les équipes clientes qui s’engagent à travailler dessus dès le deuxième trimestre 2024, avec un objectif de déploiement lors du hard fork d’Osaka au milieu ou fin 2025.
-
Nous pensons qu’il ne faut pas augmenter la limite de gas d’exécution L1 ni la taille des contrats, mais nous invitons les analystes à étudier conjointement les effets potentiels sur le réseau. Nous sommes prêts à reconsidérer notre position en fonction des résultats antérieurs (montrant que les nœuds Reth peuvent supporter une charge accrue).
-
Les EIP liés aux portefeuilles/abstraction de comptes nécessitent davantage de tests pratiques pour mieux comprendre leurs compromis. S'ils ne sont pas mutuellement exclusifs, nous serions prêts à déployer plusieurs EIP liés à l'AA à l'avenir.
-
Si la communauté acceptait la rumeur concernant une porte dérobée NSA, nous pourrions alors prendre position sur l’EIP-7212 (secp256r1).
-
Autres thèmes de feuille de route : nous n’avons pas d’avis direct sur les EIP CL ou leur couplage avec EL, mais les EIP 7549 et 7251 semblent prometteurs. Nous sommes également prêts à contribuer autant que possible depuis la couche EL au projet PeerDAS. Pour l’instant, nous préférons éviter l’introduction des racines SSZ (EIP 6404, 6465, 6466). Enfin, nous notons qu’il existe une opportunité de développer une solution durable d’archivage des blobs expirés, de l’historique et de l’état, car ni l’EIP-4844 ni l’EIP-4444 ne la définissent clairement, et il reste à savoir si Ethereum souhaite assumer cette responsabilité.
Voici maintenant une présentation détaillée.
À faire :
En bref, nous soutenons :
-
Un rapprochement accru entre les couches CL et EL.
-
Des modifications de l’EVM réalisables individuellement, pouvant être testées de manière indépendante et parallèle.
EIP-7002
Cet EIP permet aux contrats intelligents côté EL de contrôler un ou plusieurs validateurs côté CL, ouvrant ainsi la voie au restaking et aux pools de staking sans confiance. À nos yeux, c’est un gain facile, car cela permettrait déjà aux pools existants de supprimer une couche centralisée provenant des contrats intelligents implémentant les retraits.
L'introduction de précompilations à état dans l'EVM représente une nouvelle abstraction à intégrer dans les implémentations EVM, mais au-delà de cela, nous jugeons cet EIP directement exécutable.
EIP-6110
Cet EIP introduit les dépôts dans l’état EL, simplifiant ainsi la gestion d’état requise côté CL. Cela revient pratiquement à suivre les retraits CL, donc globalement, nous considérons aussi cet EIP comme simple et indépendamment implémentable.
EIP-2537
Des implémentations multiples de BLS12-381 existent déjà, et cette courbe est fréquemment utilisée dans de nombreux SNARKs, algorithmes de signature BLS et dans l’EIP-4844. La complexité d’implémentation nous semble faible, puisqu’il s’agit simplement d’exposer via une interface précompilée les algorithmes de vérification de la courbe. Nous pourrions également avoir besoin d’une interface de hachage pour la courbe BLS12-381.
EOF
En résumé : nous soutenons une version bien définie que Solidity et Vyper adopteraient. Le format de code et les ajustements de validation facilitent incontestablement l’analyse, mais nous recommandons la prudence. Nous proposons d’adopter les EIP suivants, tout en étant ouverts à une réduction ultérieure du périmètre.
Points positifs :
-
Modifications limitées à l’EVM, testables via ethereum/tests, et implémentables par une seule personne.
-
Changements souhaités par Vyper et Solidity.
-
Amélioration des performances et augmentation de la limite de taille des contrats.
-
Élimine le besoin d’analyser le bytecode à l’exécution ; sans cache, ce temps peut atteindre jusqu’à 50 %, et augmente avec la taille du contrat.
-
Permet le chargement partiel du code, utile pour exécuter de grands contrats intelligents.
-
Expérience développeur : permettra de corriger les erreurs de type « pile trop profonde » grâce à dupN/swapN et d'autres améliorations.
-
Orientation future : permet d’introduire en toute sécurité de nouvelles fonctionnalités sur L2, sachant que les outils identifieront les versions compatibles.
Points négatifs :
-
Périmètre flou et cible mouvante.
-
Manque d’un promoteur fort pour son adoption.
-
Le code hérité doit continuer à être pris en charge.
-
Une divergence temporaire entre Ethereum Mainnet et d’autres chaînes EVM avant adoption complète.
Nous pensons que les fonctionnalités EOF suivantes doivent être déployées en 2024. Nous recommandons de fixer rapidement le périmètre et de s’y engager fermement. Le reste devrait être reporté à des déploiements ultérieurs. Nos suggestions comprennent :
-
EIP-3540 : EOF - EVM Object Format v1 : introduction de conteneurs de code et de données, ajoutant structure et contrôle de version au bytecode Ethereum.
-
EIP-3670 : EOF - Validation du code : rejeter tout contrat non conforme au format EOF lors du déploiement. Imposer un code plus structuré et désactiver les instructions invalides ou indéfinies.
-
EIP-663 : Instructions SWAP et DUP illimitées : résout le problème du « stack too deep » dans Solidity. L’analyse JUMPDEST pourrait avoir des effets secondaires, mais ces instructions sont très attractives pour les langages EVM.
-
EIP-4200 : EOF - Sauts statiques relatifs : meilleure analyse statique, pas de sauts indéterminés. Les sauts relatifs favorisent la réutilisabilité du code.
-
EIP-4750 : EOF - Fonctions : résout les problèmes de sous-routines lors de l’utilisation de sauts statiques plutôt que dynamiques. Permet aussi le chargement partiel du code, compatible avec Verkle et augmentant la limite de taille des contrats.
-
EIP-5450 : EOF - Validation de pile : vérifie les exigences de pile et de code. Supprime les vérifications de dépassement/de débordement de pile à l’exécution pour toutes les instructions, sauf CALLF (EIP-4750).
-
EIP-7480 : EOF - Instructions d’accès à la section de données : permet d’accéder à la partie données du bytecode.
-
EIP-7069 : Amélioration des instructions CALL : permet de supprimer l’observabilité du gaz dans CALL, facilitant ainsi sa revalorisation future. Bien qu’indépendant d’EOF, nous voyons là une bonne occasion de l’introduire.
Notre niveau de certitude est plus faible concernant l’EIP-6206 : EOF - JUMPF et fonctions non retournantes. Bien qu’il permette l’optimisation des appels terminaux dans les fonctions EOF, nous attendons encore des analyses linguistiques pour en mesurer l’utilité. Sans cela, nous pensons pouvoir le retirer du périmètre actuel pour l’inclure dans une mise à jour EOF ultérieure.
Nous estimons que le travail ci-dessus nécessite l’équivalent d’une personne à plein temps pendant 1 à 2 mois. Si cela permet de maintenir l’élan, nous sommes prêts à réduire davantage ce périmètre.
Remarques sur le bytecode hérité :
-
Bien que nous puissions interdire le déploiement de nouveau bytecode hérité/non-EOF, nous ne pouvons pas déprécier le bytecode existant, qui deviendrait en pratique la version « v0 » d’EOF. Le bytecode hérité nécessitera toujours une analyse JUMPDEST après EOF, ainsi qu’un traitement spécifique pour le segmenter dans les Verkle Tries.
-
À notre connaissance, aucune méthode vérifiable n’existe pour convertir du bytecode non-EOF en bytecode EOF sans le code source, mais nous sommes prêts à explorer des mécanismes facilitant cette conversion.
-
Nous envisageons également des méthodes d’expiration forçant la migration vers EOF.
Augmenter le nombre de blobs dans l’EIP-4844
Nous sommes ouverts à cette modification, qui correspond, dans le contexte de l’EIP-4844, à une augmentation de MAX_BLOB_GAS_PER_BLOCK et TARGET_BLOB_GAS_PER_BLOCK :
-
Les valeurs cibles actuelles sont de 3 blobs par bloc (0,375 Mo) pour TARGET_BLOB_GAS_PER_BLOCK et 6 blobs maximum (0,75 Mo). Ces limites initiales réduites visent à minimiser la pression sur le réseau ; elles devraient être relevées dans des mises à jour futures à mesure que la fiabilité du réseau sera confirmée avec des blocs plus gros.
-
Techniquement, il s’agit d’un petit changement de code. Nous devons étudier son impact réel sur le txpool, mais nous pensons pouvoir réutiliser l’infrastructure de tests de charge de l’EIP-4844. Toutefois, la propagation de plus de blobs pourrait être plus difficile côté CL ; nous nous en remettons donc à l’avis des équipes CL.
Ne pas faire
Verkle Tries
En bref, nous ne voyons pas de voie réaliste pour déployer les Verkle tries avant fin 2024 / début 2025. Nous recommandons aux équipes de commencer à y allouer des ressources dès le deuxième trimestre 2024, avec un engagement de déploiement lors du hard fork d’Osaka au deuxième ou troisième trimestre 2025.
Points positifs :
-
Clients légers moins coûteux grâce à des preuves de stockage plus petites.
-
Exécution sans état via l’inclusion des pré-états en lecture dans l’en-tête du bloc, améliorant aussi les performances grâce à un accès statique à l’état.
-
Augmentation de la limite de taille des contrats grâce au fractionnement du bytecode et au chargement partiel du code.
-
L’expiration de l’état devient plus acceptable car son coût de restauration est moindre.
Points négatifs :
-
Impact global, et volume important d’intégration, d’implémentation et de tests.
-
Changement dans le calcul du gaz : les Verkle Tries intègrent la taille des témoins dans la fonction de calcul du gaz. Nous craignons que les implications sur la tarification du stockage ne soient pas encore explorées (par exemple, quel serait le coût post-Verkle pour les principaux consommateurs de gaz ?).
-
Intégration applicative : comment les applications utilisant des validateurs MPT doivent-elles gérer la transition ? Comment eth_getProof doit-il se comporter ?
Bien que nous reconnaissions les bénéfices des Verkle Tries, nous pensons qu’il faut davantage réfléchir à l’adaptation des outils tiers/contrats, ainsi qu’à l’impact sur les solutions de couche 2. Initialement sceptiques face à la stratégie de migration, qui demandait de mettre à jour l’arbre Verkle lors de la lecture d’état depuis l’ancien MPT (Merkle Patricia Trie), nous constatons aujourd’hui que cette approche a évolué. Nous soutenons désormais la méthode de l’arbre superposé (overlay tree) comme chemin de migration viable.
La documentation générale sur la migration vers les Verkle Trees est souvent obsolète, la plupart des ressources affirmant encore qu’il faut mettre à jour l’arbre Verkle lors de lectures MPT, ce qui n’est plus le cas. Nous espérons voir les documents clés mis à jour selon la dernière méthode, comme ce document excellent. Nous aimerions également voir un projet d’EIP sur la stratégie de migration.
Par conséquent, nous soutenons toujours son déploiement en 2025, mais ne pensons pas qu’il puisse être intégré lors du hard fork de Prague.
Limite de gaz L1
Nous pensons qu’augmenter la limite de gaz L1 aurait peu d’effet en raison de la demande induite. Nous estimons que la plupart des clients peuvent gérer une augmentation moyenne de charge, mais nous voulons rester prudents face aux pires scénarios, donc nous ne pouvons pas recommander une telle augmentation pour l’instant. À court terme, relever la limite de blob gas semble être une solution plus prometteuse.
Nous invitons les chercheurs à collaborer avec nous sur ces questions, notamment autour de la rupture du métrage des ressources dans l’EVM. L’article « Broken Metre » constitue un excellent point de départ.
Abstraction de compte
Nous sommes prêts à inclure un ou plusieurs de ces EIP (ou ERC), mais nous aimerions idéalement disposer de comparaisons plus poussées sur l’expérience utilisateur et développeur de chaque proposition, afin de mieux comprendre les compromis et efforts d’intégration des outils. Nous surveillons attentivement les EIP/ERC suivants, mais nous invitons également à nous en suggérer d’autres :
Précisons que, dans ce contexte, « abstraction de compte » fait référence à l’« abstraction de la fonction de validation », dont l’objectif principal est la rotation des clés, le passage des multisignatures au rang de fonctionnalité native, et une trajectoire automatique de résistance quantique — uniquement pour 4337 et 7560. Les autres propositions relèvent plutôt de deux catégories : parrainage de gaz et opérations groupées.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Paradigm
