Paradigm CTO : Interprétation du hard fork de Prague après la mise à niveau d’Ethereum Cancun

Texte : Georgios Konstantopoulos, directeur technique, Paradigm

Compilateur : Luffy, Foresight News

L’objectif de cet article est de fournir un aperçu des points de vue de l’équipe de Paradigm Reth sur les EIP qui devraient être inclus dans le Hard Fork de Prague (la prochaine mise à niveau majeure de Consensus Ethereum après le Hard Fork de Cancun) et notre plan global pour « EL Core Dev » en 2024. Les points de vue suivants sont en constante évolution et représentent les points de vue actuels de l’équipe Reth et ne représentent pas nécessairement l’ensemble de l’équipe Paradigm.

Nous pensons que le Hard Fork de Prague est susceptible de se matérialiser sur EthereumTestnet au troisième trimestre 2024 et sur le Mainnet d’ici la fin de l’année. Il doit comprendre :

• Les EIP liés au jalonnement, tels que l’EIP-7002 qui prend en charge le rejalonnement et les pools de jalonnement sans confiance.
• Variantes EVM séparées.
• Nous sommes prêts à travailler avec toute équipe qui souhaite en savoir plus sur Prague ou d’autres futurs Hard Fork EL et nous sommes heureux de fournir des conseils et de l’aide pour modifier la base de code de Reth.

Ce qu’il faut faire :

• Nous estimons que les EIP suivants doivent être prioritaires : 7002, 6110, 2537.
• Nous soutenons l’EOF décrit dans la spécification et espérons finaliser le périmètre et créer une méta-EIP dès que possible.
• Nous sommes prêts à ajouter EIP-4844 Max Blob Gas. Nous n’avons pas d’opinion sur des chiffres spécifiques, mais nous invitons les spécialistes des données à travailler avec nous sur le sujet.
• Nous sommes heureux de publier une version de l’EIP-7547 : elle contient une liste pour aider la couche de base à résister à la censure.

Ce qu’il ne faut pas faire :

• Nous ne soutenons pas l’inclusion de Verkle Tries dans le Hard Fork de Prague, mais nous aidons l’équipe du client à commencer à travailler dessus au deuxième trimestre 2024 avec un engagement à le publier dans la mise à niveau d’Osaka en 2025.
• Nous ne pensons pas que nous devrions augmenter la limite de gaz d’exécution L1 ou la taille du contrat, mais nous invitons les spécialistes des données à travailler avec nous pour étudier son impact sur le réseau. Nous sommes prêts à changer notre perception car les tests passés ont montré que Reth Node peut supporter l’augmentation de la charge sans aucun problème.
• Nous pensons que les EIP d’abstraction de portefeuille/compte doivent être testées de manière plus antagoniste les unes par rapport aux autres afin de mieux comprendre l’espace de compromis. S’ils ne s’excluent pas mutuellement, nous serons prêts à déployer plusieurs EIP liés aux AA à l’avenir.
• Si la communauté est d’accord avec la rumeur d’une porte dérobée de la NSA, nous pouvons franchir la ligne sur EIP-7212 (secp256r1).
• Autres sujets de la feuille de route : Nous n’avons pas de compréhension réelle du couplage des fourches CL EIP ou CL/EL, mais les EIP 7549 et 7251 semblent prometteurs. Nous voulons également contribuer autant que possible au travail de PeerDAS du côté de l’EL. Pour le moment, nous voulons éviter d’introduire des racines SSZ (EIP 6404, 6465, 6466). Enfin, nous voyons une opportunité de fournir une solution d’archivage de données à long terme pour les blobs, l’historique et l’état expirés, car EIP-4844 et EIP-4444 le montrent clairement, et il reste à déterminer si Ethereum est prêt à fournir une telle solution.

Développez-le en détail ci-dessous.

Choses à faire

Dans l’abstrait, nous soutenons 1) le fait de combler davantage le fossé entre CL et EL, et 2) les modifications EVM peuvent être effectuées en solo et peuvent être testées séparément et en parallèle.

EIP-7002

Cet EIP débloque des pools de rejalonnement et de jalonnement sans confiance en permettant à Smart Contract du côté EL de contrôler 1 ou plusieurs validateurs du côté CL. À notre avis, cela permettra au moins aux pools de jalonnement existants de supprimer une couche de centralisation du contrat intelligent qui permet les retraits.

L’introduction de la précompilation avec état dans l’EVM est une nouvelle abstraction que nous devons obtenir dans notre implémentation EVM, mais au-delà de cela, nous pensons qu’il s’agit d’un EIP simple.

EIP-6110

L’EIP introduit les dépôts dans l’état EL, simplifiant ainsi la gestion de l’état qui doit être effectuée sur le CL. En termes de mise en œuvre, cela est similaire au suivi des retraits de CL, donc dans l’ensemble, nous pensons qu’il s’agit également d’un EIP simple et autonome.

EIP-2537

Il existe actuellement plusieurs implémentations de BLS12-381, qui est une courbe fréquemment utilisée dans de nombreux SNARK, algorithmes de signature BLS et EIP-4844. Nous considérons qu’il est d’une faible complexité d’implémentation car il n’expose l’algorithme de validation de la courbe qu’à travers une interface précompilée. Nous pouvons également avoir besoin du hachage de la courbe BLS12-381 précompilé.

EOF

*Note du traducteur : EOF est l’abréviation de EVM Object Format, qui se traduit par le format objet Ethereum, et contient une série d’EIP qui promettent de rendre l’exécution d’Ethereum plus efficace, cohérente et évolutive. Les premiers plans ont été mis en œuvre lors de la mise à niveau de Shanghai, qui a ensuite été supprimée. *

EOF prendra en charge à la fois Solidity et Vyper. Il ne fait aucun doute que le formatage du code et les ajustements de vérification rendront l’analyse du bytecode beaucoup plus simple, et nous vous recommandons d’examiner attentivement tout le reste. Nous avons recommandé quelques EIP ci-dessous, mais nous sommes prêts à les peaufiner davantage.

Du côté positif :

• Modifications EVM uniquement qui peuvent être testées à l’aide d’Ethereum / Testnet et mises en œuvre par une seule personne.
• Changements d’EVM que Vyper et Solidity veulent
• Permet d’améliorer les performances et d’augmenter les limites de taille des contrats.
• Élimine le besoin d’analyse de bytecode au moment de l’exécution pour l’EVM. En l’absence de mise en cache, le temps d’analyse peut atteindre 50 % et augmente à mesure que la taille du contrat augmente.
• Activer le chargement partiel du code pour faciliter l’exécution de contrats intelligents volumineux.
• Devex : Permet de résoudre le problème de « stack trop profond » grâce à dupN/swapN et à d’autres améliorations d’outils.
• À l’épreuve du temps : de nouvelles fonctionnalités peuvent être introduites en toute sécurité dans L2, et l’outil saura ce qui est compatible.

Mauvais aspects :

• Portée et cibles dynamiques.
• Il n’y a pas de forte pression de la part des partisans pour l’inclure.
• La prise en charge du code hérité est toujours requise
• Avant l’adoption, il y avait un désaccord temporaire entre EthereumMainnet et d’autres chaînes EVM.

Nous pensons que les fonctionnalités EOF suivantes devraient être déployées en 2024. Nous vous recommandons d’établir la portée et de vous engager à la mettre en œuvre dès que possible. Tout le reste doit être pris en compte pour les déploiements ultérieurs. Nos recommandations sont les suivantes :

• EIP-3540 (EOF - EVM Object Format v1) : Introduit le code et les conteneurs de données, et ajoute une structure et une gestion des versions au bytecode Ethereum.
• EIP-3670 (EOF - Code Validation) : rejette tout contrat qui ne respecte pas le format EOF lors de son déploiement. Exécutez du code plus structuré et désactivez les directives non valides et non définies.
• EIP-663 (Infinite SWAP & DUP Instructions) : Cela résout le problème de « stack too deep » en solidité et a des effets secondaires en tant que valeur instantanée via l’analyse JUMPDEST. Une caractéristique très souhaitable du langage EVM.
• EIP-4200 (EOF - Static Relative Jumps) : Meilleure analyse statique sans sauts incertains. Meilleure compilation AOT. Les sauts sont plus propices à la réutilisation du code.
• EIP-4750 (EOF - Fonction) : Nécessite la résolution des sous-programmes qui peuvent utiliser des sauts dynamiques mais pas des sauts statiques. Il permet également le chargement d’une partie du code, ce qui fonctionne parfaitement avec Verkle pour augmenter la limite de taille du contrat.
• EIP-5450 (EOF - Stack Validation) : Vérifier les exigences du code et de la pile. Supprimez les vérifications de sous-débordement et de dépassement de la pile d’exécution pour toutes les instructions, à l’exception de CALLF (EIP-4750).
• EIP-7480 (EOF - Data Section Access Instruction) : Permet d’accéder à la partie données du bytecode.
• EIP-7069 (Improved CALL Directive) : Possibilité de supprimer l’observabilité du gaz de CALL, ce qui facilite la révision du prix du gaz à l’avenir. Bien qu’indépendant de l’EOF, nous considérons qu’il s’agit d’une bonne occasion de l’introduire.

Nous ne sommes pas si sûrs de l’EIP-6206 (EOF - JUMPF et fonction de non-retour). Bien qu’il permette l’optimisation des appels de queue dans les fonctions EOF, nous devons encore voir ce que le profilage linguistique fait pour lui. Si ce n’est pas le cas, nous pensons pouvoir le retirer du champ d’application et l’inclure dans une mise à jour ultérieure de l’EOF.

Nous estimons la charge de travail ci-dessus à 1 personne travaillant à temps plein pendant 1 à 2 mois. Nous sommes prêts à le réduire encore plus.

Une note sur le bytecode hérité :

• Bien que nous puissions interdire le nouveau bytecode legacy/non-EOF, nous ne pouvons pas déprécier le bytecode existant, qui agit effectivement comme EOF « v0 ». Le bytecode hérité nécessite toujours une analyse JUMPDEST après EOF et nécessite toujours une gestion spéciale du code pour le fragmenter en morceaux dans Verkle Trys.
• À notre connaissance, il n’est pas possible de vérifier une conversion d’un bytecode non-EOF en EOF sans accès au code source, mais nous sommes prêts à examiner des mécanismes pour faciliter cette conversion.
• Alternativement, nous serions prêts à explorer des moyens de forcer la migration de l’État vers EOF.

Augmenter le nombre d’objets blob EIP-4844

Nous sommes ouverts à ce changement, qui correspondra à une augmentation de MAX_BLOB_GAS_PER_BLOCK et TARGET_BLOB_GAS_PER_BLOCK. L’EIP-4844 se lit comme suit :

Sélectionnez les valeurs de TARGET_BLOB_GAS_PER_BLOCK et MAX_BLOB_GAS_PER_BLOCK pour qu’elles correspondent à une cible de 3 objets blob (0,375 Mo) par bloc (jusqu’à 6 objets blob). Ces petites limites initiales sont conçues pour minimiser la pression exercée sur le réseau par l’EIP, et le nombre d’objets blob devrait augmenter lors des futures mises à niveau, à mesure que le réseau fait preuve de fiabilité sur des blocs plus importants.

En fait, il s’agit d’un petit changement de code et nous devons étudier son impact réel dans le pool de transactions, mais nous avons pensé que nous pourrions réutiliser l’infrastructure de test de résistance EIP-4844 pour cela. Il peut être difficile pour le CL de répandre plus de blobs, et nous respectons les opinions de l’équipe CL.

À ne pas faire

Verkle essaie

Tl; TL ;DR : Nous ne voyons pas de tentative de déploiement de Verkle fin 2024/début 2025. Nous recommandons à l’équipe d’allouer des ressources à cet effet au deuxième trimestre 2024 et de s’engager à déployer le hard fork d’Osaka au cours des 2e et 3e trimestres 2025.

Du côté positif :

• Permet d’obtenir des clients légers moins chers avec des épreuves de stockage plus petites.
• Exécution sans état en incluant le préétat de lecture dans l’en-tête de bloc, ce qui peut également entraîner des gains de performances dus à l’accès à l’état statique.
• Augmentez la limite de taille du contrat en segmentant le bytecode et en activant le chargement partiel du code.
• L’expiration du statut est devenue plus acceptable en raison du coût inférieur de la « restauration » du statut.

Inconvénients:

• L’impact des changements et des efforts de mise en œuvre et de test.
• Modifications du calcul du gaz : Verkle Tries introduit la taille du témoin dans la fonction de calcul du gaz. Nous sommes préoccupés par le fait que les changements dans la tarification du stockage n’ont pas encore été explorés (p. ex., quel est le coût des principaux consommateurs de gaz après Verkle) ?
• Intégration de l’application : Que doit faire une application avec un validateur Merkle Patricia Trie lorsque la transition Overlay s’exécute ? Comment eth_getProof doit-il se comporter ?

Bien que nous comprenions les avantages de Verkle Try, nous pensons qu’il faut accorder plus d’attention à la façon dont les outils/contrats tiers doivent s’intégrer, et à l’impact que cela aura sur la couche 2 et autres pendant la période de transition. Au début, nous avions des doutes sur la stratégie de migration parce qu’elle indiquait que le trie Verkle devait être mis à jour lorsque l’état était lu à partir d’un MPT préexistant, mais cela ne semble plus être le cas. Par conséquent, nous soutenons l’approche de superposition en tant que chemin de migration viable.

La documentation de la stratégie de migration Verkle semble obsolète, car la plupart des ressources indiquent toujours que le trie Verkle doit être mis à jour lors de la lecture de l’état à partir de MPT. Nous aimerions voir une documentation de transition avec les approches les plus récentes, comme celle-ci, excellente. Nous aimerions également voir un projet d’EIP sur la stratégie de transition.

Par conséquent, nous soutenons toujours son déploiement en 2025 au lieu de le déployer dans le Hard Fork de Prague.

Limite de gaz L1

Nous ne pensons pas que l’augmentation de la limite de gaz L1 fera une grande différence dans la pratique. Nous pensons également que la plupart des clients peuvent supporter une augmentation moyenne de la charge, mais nous voulons être vigilants quant au pire des scénarios, c’est pourquoi nous ne recommandons pas d’augmenter la limite de gaz L1 pour le moment. Nous pensons que l’augmentation de la limite de gaz blob est une solution plus prometteuse à court terme.

Nous invitons d’autres personnes à travailler avec nous sur des recherches dans cette direction, souvent autour de la rupture de la mesure des ressources dans l’EVM. La thèse Broken Meter est un bon point de départ pour la recherche dans ce domaine.

Abstraction du compte

Nous aimerions inclure 1 ou plusieurs EIP, mais nous aimerions voir plus de comparaison de l’expérience utilisateur et de l’expérience développeur entre chaque proposition afin de mieux comprendre les compromis et les efforts d’intégration de l’outil. Nous examinons les EIP/ERC suivants, mais n’hésitez pas à nous en informer :

• EIP-3074 : Code de fonctionnement AUTH et AUTHCALL
• ERC-4337 : Utilisation d’Alt Mempool pour l’abstraction de compte
• EIP-5806 : Transaction déléguée
• EIP-5920 : Code d’opération PAY
• EIP-6913 : directive SETCODE
• EIP-7377 : Transactions de migration
• RIP-7560 : Abstraction de compte natif - EIP de base - Fellowship of Ethereum Magicians

Ce que nous devons noter ci-dessus, c’est que « l’abstraction de compte » est comme « la fonction de vérification abstraite, l’objectif principal est d’implémenter la rotation de la clé secrète, de créer une clé multisig et de nous fournir un chemin pour atteindre automatiquement la résistance quantique ».