Au cœur des mises à jour d'Ethereum : Hegotá

Ce qu'Ethlabs priorise pour Hegotá et pourquoi.

La direction d'Ethereum compte pour tous ceux qui construisent dessus, l'utilisent, détiennent de l'ETH, ou croient simplement en ce qu'il peut devenir. Bien que cet avenir soit en fin de compte déterminé par les personnes, les applications et les communautés qui construisent sur Ethereum chaque jour, les mises à niveau du réseau sont l'un des principaux moyens par lesquels le protocole évolue pour répondre à leurs besoins. Hegotá est la prochaine mise à niveau prévue du réseau Ethereum après Glamsterdam, et ce document partage le point de vue d'Ethlabs sur ce que nous pensons qu'Ethereum devrait prioriser pour celle-ci, et pourquoi.

Ethlabs est un laboratoire de R&D à but non lucratif pour Ethereum et ETH âgé de 8 semaines, et notre mission est de faire d'Ethereum la couche de règlement de l'économie mondiale. Nous nous situons entre l'utilisation réelle d'Ethereum et le développement du protocole, et nous passons notre temps à écouter les utilisateurs, les portefeuilles, les applications, les rollups, les institutions, les détenteurs d'ETH, les chercheurs et les équipes clientes. Parfois, nous construisons même sur la chaîne, car on ne peut pas construire une arène sans y participer ! Nous croyons qu'une bonne ingénierie de protocole devrait permettre de créer de bons produits, et que les bons produits devraient aider à orienter la prochaine évolution du protocole.

Le périmètre d'Hegotá est actuellement en train d'être défini par le processus technique ouvert d'Ethereum, et les propositions ci-dessous reflètent le travail de nombreux individus et équipes de recherche et clientes. Ce document est un compte rendu transparent de ce que nous recommandons de prioriser et des domaines où nos opinions sont encore en formation. Ce sont des positions que nous aimerions voir évaluées, contestées et améliorées par d'autres, et nous les ferons évoluer à mesure que nous discuterons et apprendrons davantage dans les jours et semaines à venir.

Pour la mise à niveau Hegotá, compte tenu de toutes les EIP proposées, voici les domaines que nous considérons comme les plus prioritaires pour Ethereum :

1. Une résistance à la censure plus forte : Tout le monde devrait pouvoir faire inclure une transaction, peu importe qui il est ou ce pour quoi il utilise Ethereum.
2. Un Ethereum plus rapide : Des blocs plus rapides signifient des confirmations plus rapides, des prix on-chain plus frais et une finalité plus rapide.
3. Une abstraction de compte native : Les comptes devraient prendre en charge les passkeys, les transactions sponsorisées, le paiement du gaz en tokens, le regroupement (batching) et une confidentialité renforcée, avec une voie vers les clés post-quantiques.
4. Un passage à l'échelle continu de la L1 : Les applications ont besoin d'une capacité qui reste abordable et prévisible, même lorsque la demande augmente.

Travailler ouvertement est un objectif fondamental pour Ethlabs, c'est pourquoi nous publions des mises à jour hebdomadaires et, à des occasions comme celle-ci, nous publions de très longs articles techniques pour partager notre réflexion 😅. Nous publierons également du contenu plus concis dans les semaines à venir pour ceux qui ne veulent que les points forts. Cette prochaine partie va être longue et technique. Pour ceux qui liront tout, bonne chance !

Tout d'abord : comment fonctionne le processus EIP ?

Avant de plonger dans les propositions elles-mêmes, un point important : la deuxième phase du processus de cadrage d'Hegotá vient de commencer. La première phase a sélectionné FOCIL comme la pièce maîtresse d'Hegotá. Le 6 août, il y avait une date limite pour proposer des EIP non principales, et le processus ACD va maintenant évaluer la mise à niveau Hegotá dans son ensemble.

Toutes les EIP ci-dessous sont actuellement au stade PFI (Proposé pour Inclusion), à l'exception des EIP qui ont suivi le processus de sélection des pièces maîtresses. Proposer une EIP pour inclusion est sans permission, et la plupart n'atteignent jamais la mise à niveau finale.

Plus précisément, à mesure que le travail d'implémentation progresse, les propositions passent par des étapes de révision et de confiance de plus en plus fortes quant à leur éventuel déploiement :

• PFI (Proposé pour Inclusion) : une idée a été proposée pour la mise à niveau. Cette étape est sans permission et n'implique pas le soutien des clients ou une inclusion éventuelle.
• CFI (Considéré pour Inclusion) : les équipes clientes ont examiné la proposition et ont l'intention de la prototyper et de la tester.
• SFI (Planifié pour Inclusion) : il existe une intention large de l'inclure, en supposant que l'implémentation et les tests continuent de bien se passer.

Pour en savoir plus sur le fonctionnement de ce processus, nous vous recommandons de regarder la brève explication de Tim Beiko ici.

Mise en garde : comment naviguer dans cet article

Nous suivons le classement par niveaux de Forkcast pour exprimer notre point de vue sur la priorisation des EIP pour Hegotá. Pour minimiser la prise de décision, nous cartographions toutes les EIP examinées en quatre niveaux avec les interprétations suivantes :

• [Niveau S] : recommande fortement l'inclusion.
• [Niveau A] : recommande l'inclusion si les obstacles restants, tels que la complexité d'implémentation, l'analyse d'impact ou l'adoption, sont résolus.
• [Niveau B] : intéressant, mais ambitieux pour cette mise à niveau.
• [Niveau D] : ne recommande pas l'inclusion dans Hegotá sous sa forme actuelle.
• [opinion en formation] : nous sommes encore en train de former notre opinion sur cette EIP.

Veuillez noter qu'il s'agit de \recommandations\ d'Ethlabs. Nous évaluons chaque proposition principalement en termes d'objectif, de spécification et de notre compréhension de la complexité d'implémentation plausible, sauf lorsque nous avons plus de certitude ou une implication directe (par exemple, Frames et Quick Slots), et nous mettrons à jour notre point de vue en fonction des évaluations d'ethPandaOps, des équipes de test et des clients au fur et à mesure que nous avançons dans le processus.

[CL] signifie qu'une EIP affecte les clients de la couche de consensus et [EL] signifie qu'elle affecte les clients de la couche d'exécution.

Notez que nous sommes co-auteurs et impliqués dans plusieurs EIP (y compris FOCIL, Frame Transactions et Quick Slots). Bien que nous nous efforcions d'évaluer toutes les EIP indépendamment de notre implication ou non, veuillez en tenir compte lors de l'évaluation de notre position.

tl;dr

Classement CL

Vous pouvez itérer sur ce classement [CL] spécifique sur Forkcaster ici.

Classement EL

Vous pouvez itérer sur ce classement [EL] spécifique sur Forkcaster ici.

Maintenant, sans plus attendre, voici nos points de vue sur la mise à niveau Hegotá tels qu'ils se présentent aujourd'hui, dans leur intégralité :

Thèmes pour Hegotá

0. FOCIL : renforcer la résistance à la censure

L'EIP-7805 : FOCIL est déjà SFI et confirmée comme la pièce maîtresse d'Hegotá. Trois membres de l'équipe Ethlabs (Francesco, Barnabé et Julian) figurent parmi ses co-auteurs, et nous soutenons fermement son inclusion. Étant donné que la décision est déjà verrouillée, nous restons brefs. Seule une chaîne qui est neutre envers tout le monde peut devenir la racine de confiance pour tout le monde. C'est ce qui permet à Ethereum de passer à l'échelle pour devenir la véritable couche de règlement de l'économie mondiale, et pour chaque personne qui y participe.

1. Quick Slots : un Ethereum plus rapide

Le créneau de 12 secondes d'Ethereum est un coût de latence qui dégrade la valeur pour l'utilisateur. Nous recommandons donc fortement d'inclure [CL] l'EIP-8198 : Quick Slots [Niveau S] dans Hegotá, pour quatre raisons :

1. Amélioration de l'UX sur la L1 avec une confirmation de transaction plus rapide.
2. Les marchés on-chain sur la L1 fonctionnent avec des prix plus frais, améliorant les spreads et l'économie des fournisseurs de liquidité.
3. La finalité et la règle de confirmation rapide héritent du temps de créneau, donc les deux deviennent plus rapides avec des blocs plus rapides, améliorant l'interopérabilité avec Ethereum.
4. Plus de proposeurs de blocs par seconde signifie une résistance accrue à la censure, y compris la résistance à la censure économique : le montant que vous devez payer pour maintenir les blocs vides pendant une certaine période.

Aller plus vite tout en préservant la décentralisation unique d'Ethereum rend l'espace de blocs d'Ethereum plus précieux, et cette valeur profite au réseau et à l'ETH. Chaque diminution est une valeur immédiatement livrée à nos utilisateurs. Enfin, des blocs plus rapides sont l'un des changements les plus demandés par les développeurs d'applications.

L'argument pour commencer maintenant est que la réduction du temps de créneau ne sera jamais un changement unique. Comme pour le passage à l'échelle, les réductions livrées donnent aux applications plus de certitude que les engagements de feuille de route. La route vers des créneaux de moins de 6 secondes commence par rendre le temps de créneau modifiable, puis en le modifiant de manière itérative. L'EIP-8198 divise le travail en deux :

• Un refactoring unique qui rend le temps de créneau plus facile à mettre à jour dans les spécifications et le code client.
• Une première diminution dans Hegotá, suivie de diminutions supplémentaires dans les forks suivants, à mesure que la feuille de route progresse et que des preuves empiriques de sécurité sont obtenues.

Hegotá est le bon fork pour payer le coût unique. ePBS dans Glamsterdam restructure déjà le créneau. Hegotá est alors un fork comparativement léger pour la couche de consensus, une fenêtre qui se ferme avec le consensus découplé dans I*, donc la bande passante CL pour le refactoring unique est disponible maintenant d'une manière qui ne le sera plus avant plusieurs forks.

Cela signifie : Soit nous nous engageons à rester à 12 secondes pendant au moins les deux prochaines années, soit nous atteignons 10 secondes dans environ un an dans Hegotá, et peut-être moins de 10 secondes l'année d'après. Ces deux diminutions ne sont pas des améliorations théoriques. Elles obtiennent directement une valeur accrue pour l'utilisateur et une amélioration de l'économie du réseau. Nous pensons qu'il est temps de commencer.

Les objections les plus courantes

Nous discutons ici de 4 points importants qui ont été soulevés lors des discussions préliminaires avec les développeurs clients et le Protocole EF :

1. Complexité d'implémentation : Le timing de créneau à la milliseconde près est déjà fusionné dans les spécifications de consensus via le travail ePBS, et des projets de spécifications CL et EL pour l'EIP-8198 existent, avec les frais de base, la limite de gaz et le calendrier des blobs redimensionnés pour préserver le comportement par seconde. Le coût restant est une traîne de cas particuliers dans les clients et les outils qui supposent un temps de créneau fixe, plus les tests. Le refactoring unique charge justement ce travail en amont. Ensuite, chaque diminution est un changement de paramètre.

2. Preuve zkEVM : Les deux principaux problèmes sont le temps de preuve relatif et les frais généraux constants de preuve.

2.1 Le temps de preuve relatif mesure la part du temps de créneau dédiée à la preuve, et comment cette part change lorsque le temps de créneau change. Voici une brève description des moments pertinents dans le créneau. Les constructeurs actuels observent la libération de la charge utile précédente et peuvent commencer à construire immédiatement. Le bloc de la balise actuelle s'engage ensuite sur la charge utile du créneau actuel. Cette charge utile doit être prouvée avant la libération du bloc du prochain proposeur de la balise.

Pour la preuve, le temps relatif minimum est un créneau complet, moins la latence de la libération d'un bloc de balise. La latence de la libération du bloc de balise est incompressible, mais est courte par construction, donc ne nous limite pas fondamentalement à ce stade. Il existe également la possibilité que des constructeurs optimisés co-prouvent la charge utile pendant sa construction, leur permettant de commencer à prouver avant que la charge utile gagnante ne soit engagée par le proposeur du bloc de balise.

2.2 La preuve zkEVM évolue principalement de manière linéaire avec la taille du bloc, à l'exception de certains frais généraux fixes. Des créneaux plus rapides signifient que les frais généraux fixes sont payés plus fréquemment, ce qui ajoute plus de latence pour la même quantité de débit. Étant donné un budget de latence fixe, il faut alors s'assurer qu'un bon débit peut toujours être obtenu. Nous voyons ici deux opportunités : Premièrement, les progrès techniques continueront de réduire la latence de ces opérations fixes. Deuxièmement, retarder le calcul de la racine d'état, comme décrit par l'EIP-7862, déplace une plus grande partie de la preuve hors du chemin critique, ce qui signifie que nous pouvons augmenter notre budget de latence pour les opérations incompressibles. La convergence de ces deux opportunités nous indique que des créneaux plus rapides n'entraveront pas les augmentations de débit amples à l'avenir.

3. Transition post-quantique : L'approche du consensus découplé a recueilli un soutien suffisant pour être considérée comme stable en ce qui concerne l'architecture de consensus future. Le découplage signifie déplacer le vote de finalité en dehors du chemin critique de la production de blocs. En particulier, l'agrégation à grande échelle des signatures PQ, et toute la machinerie STARK récursive associée, seront en dehors du chemin critique. Ce qui reste pour produire des blocs et obtenir une règle de choix de fork pour suivre la tête de la chaîne résultante est un sous-comité actuellement prévu pour comprendre 512 validateurs, et peut-être 256. Les tailles de signature post-quantique sont plus grandes, mais sont confortables à propager dans le temps de créneau proposé de 10s et probablement moins à l'avenir.

4. Contrats intelligents et infrastructure : La dépendance au temps de créneau dans les contrats intelligents et l'infrastructure est actuellement étudiée. Pour les contrats intelligents, nous nous sommes associés à Sourcify pour effectuer une analyse sur tous les contrats vérifiés. Nous étudions les impacts d'une mise à jour du temps de créneau sur les racines historiques des blocs de la balise, telles que stockées selon l'EIP-4788 : Racine du bloc de la balise dans l'EVM. En ce qui concerne l'infrastructure, à titre anecdotique, Etherscan a mentionné qu'un changement du temps de créneau entraînerait probablement une charge plus élevée, mais que l'infrastructure avait été construite à l'époque des temps de créneau variables dans la Preuve de Travail, ne nécessitant donc pas beaucoup de changements.

2. Abstraction de compte : améliorer l'UX, la sécurité et la confidentialité

Ethereum et son écosystème plus large attendent depuis longtemps une AA native, qui apportera des avantages UX tels que les portefeuilles passkey, les transactions sponsorisées, les paiements de gaz en ERC20, le regroupement de transactions, et plus encore.

Cependant, le chemin vers l'AA native a été particulièrement cahoteux car l'AA touche chaque partie de la pile Ethereum, y compris les clients, les L2, les portefeuilles, les RPC, les outils de développement, etc., nécessitant donc l'adhésion d'une grande variété de parties prenantes. Cela rend difficile pour toute EIP d'AA de passer à travers le processus de développement consensuel d'Ethereum, mais aussi d'atteindre une adoption pratique après le déploiement de l'EIP.

Nous plaçons donc la proposition d'AA native d'Hegotá, Frame Transactions, dans le niveau A, non pas parce qu'elle n'est pas assez bonne pour le niveau S techniquement parlant, mais parce que nous voulons tenir compte des risques d'adoption pratique qui nécessiteront une énorme quantité de coordination pour être résolus. Compte tenu des antécédents de notre équipe en matière d'AA, Ethlabs a l'intention de jouer un rôle majeur dans l'introduction de Frame Transactions sur le marché, en travaillant avec des parties prenantes telles que les L2 et les portefeuilles pour assurer un déploiement réussi de l'AA native.

Passons maintenant aux propositions d'AA spécifiques pour Hegotá.

[EL] EIP-8141 : Frame Transactions [Niveau A]

Nous croyons que l'EIP-8141 : Frame Transactions est le meilleur candidat pour le système d'AA natif d'Ethereum. Par rapport à d'autres propositions d'AA natives, Frames possède un certain nombre de propriétés souhaitables qui le rendent particulièrement aligné avec le mandat CROPS d'Ethereum :

• Innovation de compte sans permission : la logique de validation est gérée par le code EVM, donc les développeurs sont libres de développer toute logique de validation qu'ils souhaitent, contrairement à d'autres approches d'AA qui imposent une liste blanche de logiques de validation.
• Support de première classe pour les protocoles de confidentialité : comme corollaire du premier point, un protocole de confidentialité tel que Railgun peut gérer la logique de validation des transactions frame, permettant aux utilisateurs d'envoyer des transactions privées sans dépendre de relayeurs centralisés comme c'est le cas aujourd'hui. Cela rend les protocoles de confidentialité considérablement plus privés et incensurables.
• Sécurité post-quantique : les transactions frame ont été développées en tenant compte de la feuille de route PQ plus large d'Ethereum. Par exemple, les transactions frame sont explicitement conçues pour que les signatures puissent être agrégées, permettant à Ethereum de facturer éventuellement un faible gaz pour les signatures PQ même si individuellement chaque signature peut être très coûteuse à valider.

La principale faiblesse de Frame Transactions découle également de sa plus grande force : parce que la validation est gérée par le code EVM, la validation induit désormais un coût dynamique au lieu d'un coût fixe, ce qui peut poser des défis pour les chaînes à haut TPS telles que les L2. Nous sommes optimistes que ce problème peut être résolu par d'autres EIP ou ERC au-dessus des transactions frame, comme l'EIP-7819, où les transactions peuvent indiquer statiquement leur logique de validation afin que les séquenceurs puissent "court-circuiter" la validation avec du code natif si nécessaire. Nous avons également l'intention de travailler avec les L2 et l'EF pour mener des benchmarks sur les transactions frame afin d'identifier et de résoudre les éventuels goulots d'étranglement de performance.

[CL][EL] Modules complémentaires de Frame Transactions

Il existe un certain nombre d'EIP qui peuvent être considérées comme des extensions des transactions Frame, s'appuyant sur leurs capacités.

[EL] EIP-8250 : Nonces Clés pour Frame Transactions [Niveau A]

• Nous considérons cette EIP comme faisant conceptuellement partie de l'EIP-8141 : Frame Transactions, et croyons qu'elle devrait être livrée avec elle.
• Cette EIP introduit des nonces 2D pour les transactions Frame. Les nonces 2D permettent aux comptes d'envoyer des transactions parallèles au mempool, ainsi que de permettre aux protocoles de confidentialité de stocker des nullifieurs comme nonces 2D. Ceci est important car les nonces 2D sont un stockage spécial qui coûte très peu à lire et à stocker, donc les transactions de confidentialité économisent considérablement sur le gaz par rapport au stockage des nullifieurs dans le stockage dynamique classique comme aujourd'hui. Ceci est particulièrement important dans le contexte du re-pricing du stockage de Glamsterdam (EIP-8037 : Augmentation du Coût de Gaz pour la Création d'État).

[EL] EIP-8272 : Racines Récentes pour Frame Transactions [Niveau B]

• Il s'agit d'une autre EIP qui améliore l'expérience d'utilisation des protocoles de confidentialité avec les transactions Frame. Les protocoles de confidentialité ont besoin d'accéder aux racines d'engagement récentes pendant la validation, ce qui, s'il est stocké dans un stockage régulier, peut être non seulement coûteux mais aussi entrer en conflit avec les règles du mempool public de Frames. L'EIP-8272 résout ces problèmes en exposant un contrat système pour stocker ces racines dans un tampon circulaire qui purge automatiquement les anciennes racines.
• Nous le plaçons dans le niveau B car cette EIP ajoute une complexité significative à Frames pour un cas d'utilisation spécifique, et nous ne savons pas s'il pourrait y avoir une manière plus générale/élégante d'atteindre le même objectif.

[CL] EIP-8369 : Profils VOPS pour l'Éligibilité FOCIL [Niveau B]

• Cette EIP traite de l'interaction entre Frames et VOPS (partialité sans état uniquement valide), qui est une proposition pour permettre aux nœuds du mempool de stocker juste assez d'état pour valider les transactions, de sorte que même dans un monde sans état (dû à zkEVM), le mempool puisse rester résistant à la censure.
• Nous le plaçons dans le niveau B car cette EIP est fortement liée à une vision particulière de l'apatridie sur laquelle la communauté ne s'est pas encore pleinement alignée.

[EL] EIP-7906 : Assertions de Transaction via Opcode de Diff d'État [Niveau B]

• Cette EIP améliore l'auditabilité statique des résultats de transaction. Les utilisateurs peuvent déjà affirmer ce qui devrait se produire, mais pas que rien d'autre ne s'est produit. Prouver l'absence de changements d'état nécessite un nouvel opcode. La combinaison d'assertions positives (par exemple, le solde WETH a augmenté d'au moins 1,5) avec une assertion négative (aucun autre état n'a changé) permet aux utilisateurs de délimiter les effets complets d'une transaction par construction, sans simulation, les portefeuilles matériels étant un bénéficiaire clair.
• Compte tenu de la complexité, l'inclure dans le hard fork serait un choix très engageant. Nous suggérons de ne le faire que si (a) les équipes clientes comprennent vraiment les nuances et les implications de cette EIP spécifique, et (b) la surface de test et les complexités sont très bien comprises.

[EL] Migration EOA [Niveau B]

[EL] EIP-7851 : Délégation EOA Contrôlée par le Code [Niveau B] et [EL] EIP-8151 : ecRecover Restreint par le Code du Compte [Niveau B] sont mieux considérés comme des normes appariées qui ensemble présentent une histoire pour la façon dont les EOA peuvent passer aux comptes intelligents. Dans cette histoire, un EOA déléguerait d'abord à un compte intelligent via EIP-7702. Ensuite, l'opcode que l'EIP-7851 introduit rendrait la délégation 7702 permanente, désactivant la clé ECDSA racine. D'autre part, l'EIP-8151 rendrait ecrecover conscient de la désactivation, de sorte que l'ancienne clé ne puisse pas drainer les fonds via des flux de type Permit.

Nous évaluons cette paire dans le niveau B car ce n'est qu'une des nombreuses approches pour migrer les EOA vers des comptes intelligents, et cette approche particulière n'a pas reçu un large examen ou une large adhésion. En particulier, nous craignons que cette approche ne réponde pas à la question multi-chaîne : comment le même EOA migre-t-il sur les L2 ? L'utilisateur devrait effectuer la même action sur TOUTES les chaînes, y compris les chaînes qui n'existent pas encore, ce qui entraînera une mauvaise UX. Nous soupçonnons qu'il pourrait y avoir une meilleure approche où les L2 peuvent tirer parti de la L1 comme "racine de confiance" pour la migration EOA, donc nous réservons les niveaux A/S pour les approches qui permettraient aux utilisateurs de migrer une fois pour toutes les chaînes EVM.

[EL] Schéma de signature PQ [Niveau A]

Hegotá devrait établir une voie crédible vers les signatures post-quantiques, mais nous devrions confirmer le bon mécanisme avant de nous engager.

• L'EIP-8355 : Ajouter la vérification ML-DSA précompile, rendant la sécurité des comptes post-quantiques concrète aux côtés de Frame Transactions.
• Alternative : Pré-enregistrer le support PQ sans l'activer, ou définir un format de dérivation qui peut accueillir les clés PQ plus tard.

[EL] EIP-7819 : Instruction SETDELEGATE [Niveau A]

• Avec l'AA native susceptible d'atterrir dans Hegotá, il est important que le coût de déploiement de nouveaux comptes intelligents soit faible, mais le déploiement de comptes deviendra en réalité plus coûteux dans Glamsterdam en raison de l'EIP-8037. Avec l'EIP-7819, les nouveaux comptes utiliseraient de simples pointeurs de délégation au lieu de contrats proxy, réduisant considérablement la quantité de nouvel état à créer, réduisant ainsi le coût de déploiement.
• Nous plaçons cette EIP dans le niveau A car nous croyons qu'un coût de déploiement de compte plus faible réduirait considérablement les frictions pour l'adoption de l'AA.

3. Ingénierie de performance : passage à l'échelle continu de la L1

Glamsterdam a marqué un changement dans la façon dont Ethereum aborde la R&D, avec la performance traitée comme une contrainte de R&D de première classe, à la fois dans la conception du protocole et dans le travail client. L'exécution différée, les re-prix des ressources et beaucoup de travail d'optimisation client permettent de passer à l'échelle de 30M à (au moins) 200M au cours des deux dernières années. En général, le travail de performance nous donne de l'optionalité : la marge de manœuvre que nous gagnons peut être utilisée pour le passage à l'échelle, pour raccourcir les créneaux, pour abaisser les exigences des nœuds, ou tout cela à la fois.

Aujourd'hui, nous considérons encore le passage à l'échelle continu comme une nécessité. Les applications décident où construire en se basant non seulement sur les prix actuels, mais aussi sur la capacité d'Ethereum à augmenter l'offre d'espace de blocs de manière prévisible au fil du temps. Livrer des augmentations de manière cohérente offre plus de certitude que les seuls engagements de la feuille de route. La capacité du Mainnet est également encore assez loin de pouvoir gérer les pics de demande : le onzième anniversaire d'Ethereum, les frais de base médians quotidiens n'étaient que d'environ 0,1 gwei, mais un mint NFT les a poussés au-dessus de 10 gwei pendant un certain temps, avec des coûts de transaction médians atteignant environ 1 $ et le 90e percentile plus de 5 $. L'effort de passage à l'échelle de Glamsterdam devrait donc se poursuivre dans Hegotá.

Pris ensemble, les EIP suivantes poursuivent l'élan de passage à l'échelle de Glamsterdam tout en renforçant le principe plus large qui le sous-tend : la performance devrait rester une préoccupation de première classe à la fois dans le travail client et la conception du protocole.

[EL] EIP-8131 & EIP-8279 [Niveau S] : Ensemble de re-prix des données

Après Glamsterdam, la prochaine contrainte contraignante est la propagation des charges utiles, en partie parce que différentes sources d'octets de charge utile sont reflétées de manière incohérente, ou pas du tout, dans la comptabilité du gaz. L'EIP-8131 : Plancher de contenu de transaction unifié étend le plancher de transaction existant au contenu connu avant l'exécution, tandis que l'EIP-8279 : Plancher d'octets de liste d'accès de bloc couvre les octets BAL créés dynamiquement pendant l'exécution.

Cette mesure dynamique rend l'EIP-8279 clairement la plus complexe des deux. Cependant, nous suggérons de les considérer comme un ensemble. Ensemble, ils établissent une comptabilité cohérente pour les octets associés à une transaction, limitant la charge utile dans le pire des cas tout en laissant la plupart des transactions ordinaires et non gourmandes en données inchangées. Cela comble le fossé sous-jacent de la comptabilité des ressources et ouvre la voie à de nouvelles augmentations de la limite de gaz.

[CL][EL] EIP-8146 : Sidecars de liste d'accès de bloc [Tier A]

L'EIP-8146 complète les revalorisations en améliorant le chemin critique lui-même, en propageant les BAL séparément de la charge utile, ce qui améliore la propagation et donne aux clients d'exécution une longueur d'avance sur la pré-extraction d'état et le calcul de la racine d'état post-exécution. Nous considérons cela comme le type d'optimisation à faible effort que nous ne devrions pas laisser de côté. Le travail d'implémentation est principalement un mécanisme de gossip CL familier, ce qui en fait un EIP à faible effort et à haute valeur ajoutée, surtout dans un fork qui s'annonce très lourd en EL.

Autres EIP connexes

[EL] Recalibrage CPSB [Tier A]

• Changements très simples, nous recommandons de les garder dans le pipeline et d'en inclure un des deux si jugé nécessaire en fonction des augmentations prévues de la limite de gaz et de l'utilisation observée du gaz d'état et d'exécution.
• EIP-8368 : Recalibrage CPSB pour la nouvelle limite de gaz: Suite pré-planifiée de l'EIP-8037, compensant le fait que le coût par octet d'état (CPSB) a été rendu statique plutôt qu'une fonction de la limite de gaz, uniquement comme une simplification d'implémentation et de test. L'idée était de remplacer l'ajustement bloc par bloc par des ajustements ponctuels lors des forks, si nécessaire pour maintenir la croissance de l'état sur la bonne cible à mesure que la limite de gaz augmente. Étant donné que le CPSB actuel a été calibré sur une limite de gaz de 150M, il est probable qu'un ajustement dans Hegotá soit justifié.
• EIP-8372 : Limite de gaz d'état normalisée: Sur-ensemble encore assez minimal de l'EIP-8368, permettant un ajustement plus fin que le seul CPSB, compensant soit la cible de croissance de l'état, soit la cible de gaz régulière qui serait sous-atteinte en raison d'une mauvaise tarification relative.

[EL] EIP-7862 : Racine d'état différée [Tier B]

• Simple à spécifier, mais la complexité des implémentations client est, à notre connaissance, mal comprise. La racine d'état est omniprésente dans les bases de code.
• Bien qu'il y ait un certain avantage à abaisser la barrière d'accès à la construction compétitive (calcul rapide de la racine d'état), le principal avantage de cet EIP réside, selon nous, dans le futur (plus de temps pour prouver le calcul de la racine d'état).
• L'EL est déjà le côté lourd de Hegotá.

[CL] EIP-8341 : Engagements partiels de charge utile d'exécution [Tier D]

• Nous recommandons de rejeter : faible bénéfice (retarder légèrement le calcul de la racine d'état), pas urgent, et supplanté par l'EIP-7862 : Racine d'état différée (qui donne beaucoup plus de temps pour cela).

Autres EIP

Nous couvrons maintenant le reste des EIP, regroupés librement par sujets. Sur certains EIP, nous sommes encore en train de former notre opinion. Nous mettrons à jour ce document à mesure que nous en apprendrons davantage auprès des équipes client et des auteurs d'EIP dans les jours et semaines à venir.

Hegotá s'annonçant comme un hard fork à prédominance EL, nous suggérons de rester disciplinés et de maintenir un niveau d'exigence élevé pour tout EIP côté EL à valider. Nous pensons qu'il est souhaitable de garder Hegotá relativement léger en CL au-delà de FOCIL et Quick Slots : un périmètre plus restreint préserve la bande passante pour donner aux équipes client la marge de manœuvre nécessaire pour se préparer à la transition architecturale plus large.

[CL] Émission

Nous attribuons intentionnellement aucun niveau à l'EIP-8363 : Brûlage d'émission progressif. Nous pensons que l'émission n'est pas une décision que les développeurs principaux devraient prendre seuls, et une liste de niveaux est une recommandation explicite aux développeurs principaux. Pour la plupart des EIP, le processus ACD fonctionne bien car les décisions sont principalement techniques, et la communauté les a effectivement déléguées aux développeurs principaux. L'émission est différente en ce sens qu'il s'agit d'une question de politique monétaire sur laquelle la communauté elle-même doit parvenir à un consensus approximatif. Les opinions des développeurs principaux comptent, mais en tant qu'apport à cette discussion publique. Classer l'EIP-8363 aux côtés des autres EIP le traiterait comme une décision ACD normale, ce que nous pensons qu'il ne devrait pas être.

Techniquement, nous voyons un intérêt à modifier l'émission conformément à l'EIP-8363. Les problèmes qu'il aborde sont réels : la crédibilité de la réduction de solde s'érode à mesure que plus d'ETH est mis en jeu, des ratios de mise élevés signifient que les récompenses compensent principalement la dilution, et les économies d'échelle continuent d'élargir l'écart entre les grands opérateurs et les validateurs individuels. Un changement comporte également des risques, allant de l'incertitude des effets sur la distribution des mises à la réinitialisation de l'horloge d'ossification de la politique monétaire. Le fil de discussion d'Ansgar expose les deux côtés et reflète notre position. Certains d'entre nous ont plaidé pour des changements d'émission dans le passé et continuent d'avoir la conviction dans cette voie.

Nous recommandons de prendre la décision sur l'émission après toutes les autres décisions de cadrage de Hegotá. Cela donne à la discussion communautaire le temps nécessaire et évite de distraire du processus de cadrage lui-même.

[CL] Fonctionnalités de staking

Les améliorations du staking peuvent être précieuses, mais les avantages pour l'utilisateur final devraient primer sur les changements d'infrastructure uniquement, sauf si strictement nécessaires.

[CL] EIP-8015 : Supprimer les champs de dépôt et eth1data [Tier A]

• Nettoyage très simple de la dette technique. Grâce à l'EIP-7688 : Structures de données de consensus compatibles ascendantes, les preuves Merkle de champs non liés ne sont pas affectées, donc aucun impact sur les consommateurs de la chaîne.

[EL][CL] EIP-8237 : Synchronisation CL/EL indépendante [Tier B]

• S'appuie sur la séparation du bloc de balise et de la charge utile introduite par ePBS, pour permettre à l'EL et au CL de se synchroniser indépendamment. Nous pensons que cela a le potentiel de simplifier une partie complexe des clients Ethereum.

[CL] EIP-8205 : Pré-enregistrement des identifiants de retrait [Tier D]

• Nous recommandons de rejeter. Bien que l'EIP fournisse une solution intra-protocole pour un problème réel dans le staking délégué, nous pensons que la solution de pré-dépôt existante est adéquate et que la complexité des mécanismes ajoutés n'est actuellement pas justifiée.

[CL] EIP-8148 : Seuil de balayage personnalisé pour les validateurs [Tier D]

• Nous recommandons de rejeter. Nous pensons que l'EIP est trop complexe (nouveau contrat système, nouvelle demande d'exécution, mécanismes CL) pour ses avantages, que nous considérons comme encourageant principalement une consolidation marginale supplémentaire de la part du pool d'opérateurs individuels. Nous ne pensons pas que cela aura beaucoup d'effet sur la consolidation globale des validateurs compte tenu de la façon dont les mises sont distribuées.

[CL] EIP-8375 : Brûlage obligatoire des récompenses d'exécution ePBS [Tier D]

• Nous recommandons de rejeter. Nous pensons que cela conduira probablement simplement à plus de canaux secondaires. De plus, des années de discussions sur les stratégies de brûlage MEV n'ont abouti à aucune proposition ayant atteint un large consensus de recherche.

[CL] EIP-7716 : Pénalités d'attestation anti-correlation [Tier D]

• Nous recommandons de rejeter. Nous ne pensons pas qu'il y ait suffisamment de preuves claires qu'un changement aussi important dans les incitations au staking soit justifié. De plus, les incitations au staking seront probablement retravaillées dans le cadre du consensus découplé.

[CL] EIP-8333 : Aligner le point de contrôle avec le bloc limite d'époque [Tier D]

• Nous recommandons de rejeter. Bien qu'il s'agisse d'un bon nettoyage, nous pensons qu'il vaut la peine de le reporter à la grande transition à venir du consensus découplé.

[CL] EIP-8359 : Champ de rapport de bloc de balise [opinion en formation]

[CL] Préparation PQ supplémentaire

Ces propositions réduisent les dépendances BLS restantes avant une future transition post-quantique.

[CL] EIP-8365 : Retrait des identifiants de retrait BLS [Tier A]

• Retire un identifiant de retrait hérité, préparant le terrain pour des simplifications du protocole et simplifiant la future transition PQ.
• Étant donné sa simplicité, nous pensons qu'il vaut la peine de l'inclure maintenant.

[CL] EIP-8367 : Coucher de soleil du solde pour les validateurs BLS retirés [Tier D]

• Nous recommandons de rejeter. Nous pensons qu'il est probable que la plupart des validateurs 0x0 effectueront un changement d'identifiant (BLSToExecutionChange) avant ou après l'activation de l'EIP-8365 : Retrait des identifiants de retrait BLS, soit pour retirer leurs fonds, soit pour pouvoir continuer à staker. Nous ne pensons pas qu'il y ait une grande urgence à introduire un mécanisme pour traiter la mise 0x0 restante. Nous recommandons simplement d'inclure l'EIP-8365 et d'observer le résultat avant de décider des prochaines étapes.

[CL] EIP-8321 : RANDAO à chaîne de hachage [Tier D]

• Nous recommandons de rejeter. Rendre RANDAO post-quantique sûr de manière isolée offre peu de sécurité au niveau du protocole alors que les clés BLS des validateurs restent vulnérables, tout en ajoutant environ 32 octets par validateur, de nouveaux mécanismes de gestion de secrets et un mécanisme largement à usage unique. La conception plus large du consensus PQ reste non résolue. Nous soutenons une transition itérative, mais sa première étape devrait suivre une feuille de route convenue plutôt que de risquer d'être supplantée par la conception finale.

[EL][CL] Préparation zkEVM

La plupart des préparations zkEVM offrent des avantages limités à court terme au-delà de faciliter l'exploitation d'un nœud complet pour un ensemble restreint d'utilisateurs, tout en consommant de la bande passante d'implémentation et en rendant potentiellement l'EVM plus coûteux. Nous ne devrions inclure que les changements dont la valeur à long terme justifie clairement ces coûts immédiats.

[CL] EIP-8025 : Preuves d'exécution optionnelles [Tier D]

• L'EIP ne nécessite pas de hard fork. La proposition de le regrouper avec Hegota est purement une expression de priorisation, et nous ne sommes pas d'accord avec ce choix. Nous pensons que le travail devrait se poursuivre dessus, mais Hegotá ne devrait pas être bloqué par cela.
• Avant de livrer des preuves optionnelles, nous devrions d'abord travailler à définir l'état final, puis accélérer vers celui-ci, plutôt que de livrer des preuves optionnelles avant d'avoir une vision claire du modèle validateur/état à long terme.
• La question ouverte fondamentale est le rôle que les validateurs devraient avoir vis-à-vis de l'état : s'ils doivent continuer à servir ou détenir une partie de celui-ci, plutôt que de devenir complètement sans état. Parce que les validateurs sont une cohorte de nœuds de base avec une réelle valeur matérielle et réseau, les changements qui affaiblissent ce rôle devraient franchir une barre plus haute.

[EL] EIP-7666 : EVM-ifier la précompilation d'identité [Tier A]

• Changement utile et petit

[EL] EIP-8200 : EVMification [Tier B]

• L'EIP-8200 remplace trois précompilations natives par un bytecode EVM équivalent. Deux sont peu utilisées et semblent simples à migrer. La troisième est largement utilisée dans la vérification SNARK, donc nous voudrions une évaluation d'impact avant de soutenir sa suppression.
• Si l'analyse d'impact trouve des coûts de migration faibles pour les utilisateurs concernés, ou si la troisième précompilation est retirée du périmètre, nous déplacerions l'EIP-8200 vers [Tier A].

[EL] EIP-7709 : Lire BLOCKHASH depuis le stockage et mettre à jour le coût [Tier D]

• Assez perturbateur en raison de la très forte augmentation du coût en gaz, pas urgent
• Le dérisquer pourrait impliquer une analyse d'impact, ou le faire plus tard avec une certaine forme de réchauffement au niveau du bloc (ou un réchauffement ad hoc de ces valeurs) pour réduire l'impact.

[EL] EIP-8268 : Racines de stockage dans les listes d'accès de bloc [Tier B]

• Pourrait nécessiter une analyse de l'impact concret sur les tailles BAL, et l'impact connexe sur les coûts de transaction (l'EIP-8279 propose de facturer les octets BAL), car l'entrée BAL pour chaque compte touché obtient une racine d'arbre de stockage supplémentaire.

[EL] Fonctionnalités EVM

Hegotá nécessitera encore quelques décisions EVM ad hoc. Nous pensons qu'après Hegotá, Ethereum devrait travailler vers une feuille de route EVM à long terme façonnée par l'écosystème EVM plus large. Ethlabs y contribuera.

[EL] EIP-5920 : Opcode PAY [Tier A]

• Très simple, et nous pensons que c'est une bonne primitive pour l'EVM
• Il serait important de mieux comprendre les cas d'utilisation concrets

[EL] EIP-8163 : Réserver l'opcode EXTENSION (0xae) [Tier A]

• Très utile pour les L2, aucun coût réel pour le L1 (juste informatif)

[EL] Réutilisation / déduplication de code [Tier B]

• L'EIP-8058 : Remise sur la déduplication du bytecode de contrat et l'EIP-8298 : Instruction de réutilisation de code SETCODEFROM tentent tous deux de tirer parti du fait que le code du contrat est stocké séparément du compte correspondant dans les clients, avec le hachage du code comme pointeur entre eux. Ainsi, un code partagé identique peut être stocké dédupliqué. Les deux EIP permettent un moyen peu coûteux de définir le codehash du compte sur le hachage d'un code existant ailleurs.
• Nous considérons cela comme une idée générale attrayante, mais il serait important de comprendre les implications et la compatibilité ascendante avec les arbres binaires. Pas de préférence pour l'instant entre les deux.

[EL] Réforme de la tarification de la mémoire [Tier B]

• Nous devons décider si nous voulons ou non faire une réforme de la mémoire dans Hegota. Il ne nous semble pas clair que nous ayons actuellement une compréhension suffisante de l'espace de conception pour faire cette évaluation.

EIP-7686 : Limites de mémoire EVM linéaires

• Changement plus petit, se débarrasse simplement du coût d'expansion de la mémoire quadratique.

EIP-7923 : Coût de la mémoire linéaire basé sur les pages

• Refonte plus profonde et plus fondée sur des principes, mais plus complexe.

[EL] EIP-8219 : Opcodes arithmétiques vérifiés [Tier B]

• Dans l'ensemble, ajouter des mathématiques sécurisées à l'EVM semble utile.
• La tarification devrait être confirmée par des benchmarks, quelle est sa complexité ?
• Avec des benchmarks et une analyse d'impact (combien de transactions pourraient en bénéficier, de combien, quels compilateurs ajouteraient le support ?), il pourrait être de niveau A.

[EL] EIP-8360 : Opcode TCREATE [Tier B]

• L'EIP introduit la capacité de créer des contrats temporaires limités à la transaction. C'est une bonne primitive à avoir en général.
• L'EIP ajoute une complexité significative. Avec une évaluation plus approfondie de la complexité de l'implémentation et des tests, il pourrait être de niveau A.

[EL] EIP-7645 : Alias ORIGIN vers SENDER [Tier D]

• Nous recommandons de rejeter : Changement cassant, utilisation inappropriée d'ORIGIN.

[EL] EIP-8182 : Transferts privés d'ETH et ERC-20 [Tier D]

• Nous recommandons de rejeter : Changement énorme, ajoute des dépendances zk. Si jamais introduit, nous pensons qu'il devrait être un titre principal.

[EL] EIP-2488 : Déprécier l'opcode CALLCODE [opinion en formation]

[EL] EIP-4758 : Désactiver SELFDESTRUCT [opinion en formation]

[EL] EIP-7979 : Opcodes d'appel et de retour pour l'EVM [opinion en formation]

[EL] EIP-8173 : Fondations du flux de contrôle EVM [opinion en formation]

[EL] EIP-8253 : Augmenter le nonce des comptes de stockage à nonce zéro [opinion en formation]

[EL] EIP-8030 : Prise en charge de l'algorithme P256 [opinion en formation]

[EL] Tarification EVM

Glamsterdam a augmenté les prix des opérations sous-évaluées qui limitaient le débit global. Les propositions de tarification EVM de Hegotá abordent principalement l'autre côté : baisser les prix pour les opérations individuelles dont le coût actuel limite leur utilisation, mais pas l'évolutivité du réseau. Ce sont donc des « nice-to-have » avec un impact par EIP plus faible. Nous sommes ouverts à une revalorisation ciblée, mais les propositions qui introduisent de nouveaux mécanismes de mesure ne devraient être incluses que si leur conception est solide et suffisamment dérisquée par un champion engagé.

[EL] EIP-8358 : Comptabilité nette du gaz pour les modifications de compte [Tier B]

• Pas convaincu de l'impact. Dans 900 blocs du réseau principal échantillonnés, ~400k transactions : 2,07 % de toutes les transactions économiseraient du gaz et 1,14 % du gaz de bloc serait économisé.

[EL] EIP-7973 : Comptabilité d'écriture de compte chaud [opinion en formation]

[EL] EIP-7609 : Diminuer le coût de base de TLOAD/TSTORE [opinion en formation]

[EL] EIP-7971 : Limites strictes pour le stockage transitoire [opinion en formation]

[EL] EIP-3298 : Suppression des remboursements [opinion en formation]

[EL] EIP-8374 : Persister les ensembles d'accès chauds lors des annulations [opinion en formation]

[EL] EIP-8115 : Frais de priorité par lots à la fin du bloc [opinion en formation]

[EL] EIP-8188 : Dernier bloc écrit pour les comptes et les emplacements [opinion en formation]

[EL][CL] Données d'exécution et indexation

[EL][CL] EIP-7668 : Supprimer les filtres bloom [opinion en formation]

[EL][CL] EIP-7807 : Blocs d'exécution SSZ [opinion en formation]

[EL] EIP-8116 : Remplacer les champs de reçus cumulatifs [opinion en formation]

[EL] EIP-8304 : Index de transaction et de journal sans confiance [opinion en formation]

[EL][CL] Réseautage

La couche P2P d'Ethereum a une marge d'amélioration ciblée, en particulier dans la façon dont les transactions, les blobs et les attestations sont propagées sur le réseau.

[CL] EIP-8371 : RowDAS - Reconstruction distribuée de blobs [Tier A]

• Empêche généralement la reconstruction complète et les performances des nœuds de garde complets comme goulot d'étranglement vers la mise à l'échelle du nombre de blobs.
• Précieux, éventuellement une forme de reconstruction distribuée devrait certainement faire son chemin dans le protocole. Cela pourrait nous permettre de supprimer la garde du validateur.
• Besoin de mieux comprendre la complexité.

[CL] EIP-8142 : Bloc-dans-Blobs (BiB) [Tier D]

• Prématuré, pas d'urgence forte, assez de dernière minute, beaucoup de questions en suspens (KZG ou non ? Nouveaux sujets de gossip ou non ?).
• Ne veut pas introduire KZG dans le chemin critique de la production de blocs, les alternatives ne sont pas claires et ajouteraient une complexité supplémentaire.

[CL] EIP-8243 : Regroupement des attestations à la source [Tier D]

• Incertain si nous pouvons compter sur cela pour diminuer le temps de finalité, ne met pas de limite claire sur la charge.
• La résistance aux dénis de service du mécanisme n'est pas totalement claire.

[EL] EIP-8077 : eth/XX - annoncer les transactions avec nonce [opinion en formation]

[EL] EIP-8094 : eth/vhash - Mempool conscient des blobs [opinion en formation]

[CL] EIP-8334 : Propagation d'attestation groupée [opinion en formation]

Si vous êtes encore avec nous après tout cela, merci d'avoir lu jusqu'au bout. N'hésitez pas à répondre avec toutes vos questions, et nous ferons de notre mieux pour vous répondre ! Si vous avez sauté et avez simplement fait défiler jusqu'ici parce que parcourir un mur de texte gargantuesque n'était pas la façon dont vous avez décidé de passer votre dimanche, vous aurez le plaisir de savoir que cette prochaine partie est brève.

Encore quelques mots...

Les mises à niveau d'Ethereum sont complexes car les enjeux sont élevés. Des milliers de nœuds à travers le monde passent à de nouvelles règles au même créneau, et le réseau ne s'arrête pas une seule seconde pendant qu'ils le font. Cette rigueur a porté chaque mise à niveau qu'Ethereum a livrée, résultant en un réseau décentralisé qui a célébré 11 ans de disponibilité à 100 %.

Nos positions sur Hegotá sont nos meilleures évaluations à ce jour, mais nous mettrons à jour notre réflexion chaque fois que de nouvelles preuves issues de discussions ou de travaux d'implémentation changeront notre point de vue.

Certains de ces EIP ont été rédigés ou avancés par des membres d'Ethlabs, d'autres proviennent des chercheurs, développeurs clients et contributeurs individuels incroyablement vastes, talentueux et bien intentionnés à travers Ethereum. Cependant, tous nécessiteront une collaboration entre les équipes client, les portefeuilles, les applications, les L2, les fournisseurs d'infrastructure, les institutions, les opérateurs de nœuds et, en fin de compte, les utilisateurs pour réussir. Ethereum est le projet partagé du monde, et un progrès significatif du réseau n'est jamais le travail d'une seule organisation.

Nous sommes reconnaissants de faire une petite partie de cet écosystème, et nous nous réjouissons d'aider Ethereum à réaliser son potentiel.

– Ethlabs