Rédigé par : Ethlabs
Compilé par : Chopper, Foresight News
La direction du développement d'Ethereum concerne tous ceux qui construisent des applications, utilisent le réseau, détiennent de l'ETH et croient en son potentiel futur. La trajectoire à long terme d'Ethereum est finalement déterminée par les participants qui y construisent des produits, exploitent des applications et des communautés quotidiennement, mais les mises à jour du réseau sont le principal moyen d'itérer le protocole et de répondre aux besoins des utilisateurs. Hegotá est la prochaine mise à jour majeure planifiée d'Ethereum après Glamsterdam. Cet article expose les domaines qu'Ethlabs considère comme prioritaires pour cette mise à niveau et les raisons de cette position.
Actuellement, le périmètre de la mise à niveau Hegotá est en cours de finalisation via le processus technique public d'Ethereum. Les propositions mentionnées ci-dessous sont le fruit du travail de nombreux développeurs, équipes de recherche et d'équipes client. Cet article présente clairement les domaines qu'Ethlabs recommande de prioriser, ainsi que les sujets sur lesquels nous n'avons pas encore d'opinion arrêtée. Nous accueillons favorablement l'évaluation, les questions et l'amélioration de ces propositions par l'industrie ; au cours des prochains jours et semaines, nos points de vue évolueront également avec les discussions continues et les mises à jour d'informations.
Pour la mise à niveau Hegotá, compte tenu de toutes les EIP proposées, nous considérons que les domaines suivants sont les principales priorités pour Ethereum :
- Une meilleure résistance à la censure : Toute personne, quelle que soit son identité ou son usage, doit pouvoir faire inclure une transaction dans un bloc.
- Un Ethereum plus rapide : Des blocs plus rapides signifient des confirmations de transaction plus rapides, des prix en temps réel sur la chaîne et un temps de finalisation plus court.
- Abstraction de compte native : Les comptes prennent en charge les clés d'accès, le parrainage de transactions, le paiement des frais en tokens, les transactions groupées, une meilleure protection de la vie privée et une voie de mise à niveau vers des clés post-quantiques.
- Expansion continue de la couche 1 (L1) : Les applications disposent d'une capacité de réseau stable et abordable, même en période de pics de demande.
Préambule : Comment fonctionne le processus d'avancement des EIP ?
Avant d'entrer dans l'interprétation formelle des propositions, clarifions le contexte clé : la deuxième phase de définition du périmètre de la mise à niveau Hegotá vient de commencer. La première phase a déjà établi FOCIL comme proposition de mise à niveau centrale pour Hegotá. La date limite pour les propositions d'EIP non essentielles est le 6 août, après quoi la réunion ACD évaluera complètement l'ensemble du plan de mise à niveau Hegotá.
Toutes les EIP suivantes sont actuellement en phase PFI (Proposition d'inclusion). Soumettre une EIP pour une mise à niveau est sans autorisation, mais la grande majorité des propositions ne seront finalement pas incluses dans la mise à niveau formelle.
Au fur et à mesure du développement, les propositions passent par plusieurs tours d'examen, franchissant des étapes successives, avec une certitude croissante de mise en œuvre :
PFI (Proposée pour inclusion) : La proposition est soumise pour cette mise à niveau. Cette étape n'a pas de barrière d'entrée, n'implique pas le soutien des clients et ne garantit pas la mise en ligne finale.
CFI (Envisagée pour inclusion) : Les équipes client ont terminé leur examen et prévoient de développer des prototypes et des tests.
SFI (Confirmée pour inclusion) : Les parties sont généralement d'accord pour l'inclure, sous réserve d'un développement et de tests réussis.
Pour comprendre le processus complet, nous recommandons de regarder la vidéo explicative de Tim Beiko. (https://www.youtube.com/watch?v=-S4blFZl28g)
Guide de lecture
Cet article suit les critères de classement Forkcast pour exprimer le jugement de priorité d'Ethlabs sur les différentes EIP de Hegotá. Pour simplifier la décision, toutes les propositions évaluées sont classées en cinq catégories :
- 【Niveau S】 Fortement recommandé pour l'inclusion
- 【Niveau A】 Recommandé pour l'inclusion si les obstacles liés à la difficulté de développement, à l'évaluation de l'impact, à l'adoption par l'écosystème, etc., sont résolus
- 【Niveau B】 Présente de la valeur, mais difficile à inclure dans cette mise à niveau
- 【Niveau D】 Dans les conditions actuelles, non recommandé pour l'inclusion dans Hegotá
- 【Avis en cours de formation】 Nous sommes encore en train d'étudier cette EIP
⚠️ Note : Ce ne sont que les recommandations d'Ethlabs. Nous évaluons principalement en fonction des objectifs de la proposition, des spécifications techniques et de la complexité estimée du développement ; nous disposons de plus d'informations sur les projets auxquels nous participons activement (par exemple, Frames, Quick Slots). Nous mettrons à jour nos points de vue en continu en fonction des retours d'ethPandaOps, des équipes de test et des différents clients. 【CL】 indique un impact sur le client de la couche de consensus ; 【EL】 indique un impact sur le client de la couche d'exécution.
De plus, des membres d'Ethlabs ont participé à la rédaction de plusieurs EIP (y compris FOCIL, Frame Transactions, Quick Slots). Nous nous efforçons d'évaluer objectivement toutes les propositions, sans être influencés par notre propre niveau d'implication, mais les lecteurs peuvent garder ce contexte à l'esprit lorsqu'ils consultent nos opinions.
Liste de priorité CL
Liste de priorité EL
Sans plus tarder, voici le point de vue complet d'Ethlabs sur la mise à niveau Hegotá à ce stade.
Les quatre axes centraux de Hegotá
FOCIL : Renforcer la résistance à la censure
L'EIP-7805 FOCIL est déjà en phase SFI, officiellement confirmée comme proposition centrale de Hegotá. Trois membres d'Ethlabs (Francesco, Barnabé, Julian) sont co-auteurs de cette proposition, nous soutenons pleinement sa mise en œuvre. Étant donné que la solution est définie, nous l'expliquons brièvement ici : seule une blockchain qui reste neutre pour tous peut devenir une base de confiance pour tous. C'est la pierre angulaire pour qu'Ethereum puisse s'étendre, devenir une véritable couche de règlement pour l'économie mondiale et servir chaque participant.
Quick Slots : Un Ethereum plus rapide
L'intervalle actuel de 12 secondes entre les créneaux (slots) sur Ethereum entraîne une latence élevée, ce qui nuit à l'expérience utilisateur. Par conséquent, nous recommandons vivement d'inclure 【CL】EIP-8198 Quick Slots【Niveau S】 dans Hegotá, pour quatre raisons principales :
- Amélioration de la vitesse de confirmation des transactions pour les utilisateurs de L1, optimisant ainsi l'expérience.
- Les marchés on-chain sur L1 obtiennent des données de prix plus récentes, améliorant les écarts entre les prix d'achat et de vente et les revenus des fournisseurs de liquidités.
- La finalité, les règles de confirmation rapide sont liées à la durée du créneau ; des blocs plus rapides amélioreront simultanément l'interopérabilité cross-chain d'Ethereum.
- L'augmentation du nombre de propositions de blocs par seconde renforce la résistance à la censure, y compris la résistance économique : le coût nécessaire pour effectuer une censure en vidant continuellement les blocs est plus élevé.
Raccourcir l'intervalle entre les blocs tout en conservant les caractéristiques de décentralisation d'Ethereum peut augmenter la valeur de l'espace de blocs d'Ethereum, les bénéfices revenant au réseau et à l'ETH lui-même. Chaque réduction de latence crée directement de la valeur pour les utilisateurs. Parallèlement, l'accélération est également l'une des améliorations les plus demandées par les développeurs d'applications.
Il est raisonnable de lancer cette transformation maintenant. L'ajustement de la durée du créneau ne peut pas se faire en une seule fois. À l'instar de la logique d'expansion, une optimisation itérative basée sur des tests réels offre bien plus de certitude aux développeurs d'applications qu'une simple promesse sur une feuille de route. Atteindre des créneaux inférieurs à 6 secondes est un objectif à long terme, le chemin se déroulant en deux étapes :
- Refonte ponctuelle : Permettre aux spécifications et au code client de supporter des modifications flexibles de la durée du créneau.
- Réaliser le premier raccourcissement lors de Hegotá, puis continuer à réduire lors des futures mises à niveau majeures, accumulant des données de fonctionnement sécurisé.
Hegotá est le moment opportun pour assumer le coût de cette refonte ponctuelle. L'ePBS de la mise à niveau Glamsterdam a déjà refondu la logique liée aux créneaux ; les modifications de la couche de consensus lors de cette mise à niveau sont relativement gérables. Une fois la fenêtre de mise à niveau du consensus découplé atteinte, les ressources de développement de la couche consensus seront très tendues, et il sera difficile d'avoir une telle fenêtre d'opportunité lors de futures mises à niveau majeures.
En termes simples, soit nous maintenons des créneaux de 12 secondes pendant au moins deux ans, soit nous réalisons des créneaux de 10 secondes lors de la mise à niveau Hegotá dans un an, avec la possibilité de les réduire encore à moins de 10 secondes lors du prochain cycle. Ces deux accélérations ne sont pas des optimisations théoriques ; elles peuvent directement augmenter la valeur pour les utilisateurs et optimiser le modèle économique du réseau. Nous pensons que le moment est venu.
Réponses aux principales controverses
Nous avons compilé quatre préoccupations principales apparues lors des communications préliminaires avec les équipes de développement des clients et l'équipe du protocole de la Fondation Ethereum :
- Complexité du développement. La logique temporelle des créneaux au niveau milliseconde a déjà été intégrée aux spécifications du consensus via l'ePBS ; les projets de spécifications de la couche consensus et de la couche d'exécution pour l'EIP-8198 sont terminés, les frais de base, la limite de Gas, la planification des Blobs ont tous été convertis pour garantir un comportement réseau stable par seconde. Le travail restant se concentre sur l'adaptation de divers outils clients et les tests de scénarios limites qui supposaient des créneaux fixes. Une fois cette refonte ponctuelle terminée, les futurs raccourcissements de créneaux ne nécessiteront qu'un ajustement des paramètres.
- Pression sur les preuves zkEVM. Principales inquiétudes : la durée relative de la preuve et le coût fixe de la preuve. 1) Durée relative de la preuve : la proportion de temps disponible pour la preuve à l'intérieur d'un créneau. Actuellement, le constructeur de blocs peut commencer à construire après avoir reçu la charge utile du bloc précédent ; le bloc phare (beacon) confirme la charge utile du créneau actuel. La charge utile doit être prouvée avant que le prochain proposant de phare ne publie son bloc. Le temps minimal disponible pour terminer la preuve est approximativement égal à un créneau moins le délai de propagation du bloc phare. Le délai de propagation est difficile à réduire, mais sa valeur est faible et ne constitue pas un goulot d'étranglement central à ce stade. Un constructeur de blocs optimisé peut exécuter la preuve en parallèle pendant l'assemblage de la charge utile, sans attendre que la charge utile gagnante soit confirmée par le bloc phare. 2) Coût fixe de la preuve zkEVM : Le temps de preuve est globalement linéaire par rapport à la taille du bloc, mais il existe un coût fixe. Des blocs plus rapides signifient que ce coût fixe est déclenché plus fréquemment, augmentant la latence pour un même débit. Avec un budget de latence fixe, il faut garantir que le débit ne soit pas significativement impacté. L'industrie explore deux voies d'amélioration : l'itération technique pour réduire continuellement le temps des opérations fixes ; l'EIP-7862 qui retarde le calcul de la racine d'état, déplaçant une grande partie du travail de preuve hors du chemin critique. En progressant simultanément sur ces deux fronts, des créneaux plus rapides n'entraveront pas la croissance continue future du débit.
- Feuille de route de mise à niveau post-quantique. Le schéma de consensus découplé a obtenu un soutien suffisant pour devenir la direction stable de l'architecture de consensus future. Le découplage signifie déplacer les votes de finalisation hors du chemin critique de production des blocs. La logique de l'agrégation à grande échelle de signatures post-quantiques et des STARK récursifs sera également hors du chemin critique. La production de blocs et les règles de choix de fourche ne dépendront que d'un petit comité d'environ 512 validateurs (pouvant potentiellement être réduit à 256). Les signatures post-quantiques ont un volume plus important, mais peuvent être propagées dans l'intervalle de créneau prévu de 10 secondes (avec potentiellement d'autres réductions futures).
- Adaptation des contrats intelligents et de l'infrastructure. L'équipe mène une enquête complète sur les scénarios où les contrats intelligents sont fortement couplés à la durée du créneau. Nous avons mené une analyse conjointe avec Sourcify sur tous les contrats vérifiés ; nous évaluons également l'impact du changement de créneau sur le stockage des racines des blocs phares historiques introduit par l'EIP-4788 (racines des blocs phares dans l'EVM). Au niveau de l'infrastructure, les retours d'Etherscan indiquent : l'ajustement du créneau augmentera probablement la charge serveur, mais l'infrastructure était déjà adaptée à des temps de bloc variables à l'époque de la PoW, donc l'ampleur des modifications est gérable.
Abstraction de compte : Optimiser l'expérience, la sécurité et la confidentialité
L'écosystème Ethereum a longtemps eu un besoin urgent d'abstraction de compte native (AA) pour permettre des portefeuilles avec clés d'accès, le parrainage de transactions, le paiement des frais en ERC20, les transactions groupées et d'autres améliorations de l'expérience. Cependant, le chemin vers une AA native a été exceptionnellement sinueux : l'AA touche toute la pile d'Ethereum, couvrant les clients, L2, les portefeuilles, RPC, les outils de développement, nécessitant une coordination multi-parties. Cela a non seulement rendu difficile l'avancement des EIP associées via le processus de développement piloté par le consensus, mais pose également des défis d'adoption par l'écosystème après le lancement.
C'est pourquoi nous classons la proposition d'AA native Frame Transactions pour Hegotá au niveau A. Ce n'est pas que les standards techniques ne soient pas de niveau S, mais plutôt qu'il faut pleinement prendre en compte les risques d'adoption à grande échelle par l'écosystème, le travail de coordination étant énorme. Forts de notre expertise en abstraction de compte, Ethlabs prévoit de pousser en profondeur la mise en œuvre de Frame Transactions, en collaborant avec les participants L2, les portefeuilles, etc., pour garantir un lancement réussi de l'AA native.
Examinons maintenant les propositions liées à l'abstraction de compte pour Hegotá.
【EL】EIP-8141 Frame Transactions【Niveau A】
Nous considérons Frame Transactions comme la meilleure solution d'abstraction de compte native pour Ethereum. Comparée à d'autres solutions d'AA native, plusieurs caractéristiques correspondent aux principes de développement CROPS d'Ethereum :
- Innovation sans autorisation pour les comptes : La logique de validation est exécutée par du code EVM, les développeurs peuvent définir des règles de validation arbitraires ; certaines solutions d'AA imposent une liste blanche de logiques de validation, limitant la flexibilité.
- Adaptation native aux protocoles de confidentialité : Sur la base du point précédent, des projets de confidentialité comme Railgun peuvent héberger la logique de validation des transactions Frame, permettant aux utilisateurs d'envoyer des transactions privées sans dépendre de relais centralisés, améliorant significativement la confidentialité et la résistance à la censure.
- Conçu pour la sécurité post-quantique : Développé dès le départ pour correspondre à la feuille de route post-quantique d'Ethereum. Prend en charge l'agrégation de signatures, permettant des coûts de Gas relativement bas même si la validation d'une seule signature post-quantique est coûteuse.
Le plus grand défaut de Frame Transactions découle également de sa flexibilité : la logique de validation étant exécutée par du code EVM, son coût est dynamique, ce qui pose un défi pour les L2 visant un TPS élevé.
Nous sommes optimistes sur le fait que cela peut être résolu via des standards EIP/ERC d'accompagnement (par exemple, l'EIP-7819), où une transaction déclare statiquement sa logique de validation, permettant aux séquenceurs d'optimiser le flux de validation avec du code natif. Nous mènerons également des tests de référence conjoints avec les L2 et la Fondation Ethereum pour identifier et résoudre les goulots d'étranglement de performance.
[CL][EL]Composants additionnels pour Frame Transactions
De nombreuses EIP peuvent être considérées comme des extensions des transactions Frame, améliorant leurs fonctionnalités.
【EL】EIP-8250 Nonce à clé pour les transactions Frame【Niveau A】
Nous considérons cette proposition comme une partie intégrante de l'EIP-8141 et recommandons son déploiement simultané. L'introduction d'un nonce bidimensionnel permet à un compte d'envoyer plusieurs transactions en parallèle au mempool ; les protocoles de confidentialité peuvent également stocker des valeurs nulles dans le nonce bidimensionnel. Le coût de lecture/écriture du nonce 2D est très faible. Comparé au modèle actuel qui écrit les valeurs nulles dans le stockage ordinaire, les transactions privées peuvent économiser considérablement du Gas. Ceci est particulièrement important dans le contexte de l'augmentation du coût du Gas de stockage (EIP-8037) lors de Glamsterdam.
【EL】EIP-8272 Racine la plus récente pour les transactions Frame【Niveau B】
Optimise davantage l'expérience des protocoles de confidentialité utilisant les transactions Frame. Le processus de validation des protocoles de confidentialité nécessite de lire la racine d'engagement la plus récente. Si elle est stockée dans le stockage ordinaire, le coût est élevé et cela entre en conflit avec les règles du mempool public pour Frame. Cette proposition stocke les données de racine via un tampon circulaire de contrat système, nettoyant automatiquement les anciennes données. Classée niveau B car elle ajoute une complexité significative à Frame pour un cas d'usage unique ; nous ne sommes pas certains qu'il existe une solution plus générale et plus simple.
【CL】EIP-8369 Profil VOPS pour l'éligibilité FOCIL【Niveau B】
Résout l'interaction entre Frame et VOPS (Stateless uniquement pour la validité). Le schéma VOPS permet aux nœuds du mempool de ne conserver qu'un minimum d'état pour valider les transactions, garantissant la résistance à la censure du mempool dans un environnement futur sans état pour les zkEVM. Classée niveau B car cette proposition est fortement liée à une feuille de route de stateless qui n'a pas encore obtenu de consensus communautaire.
【EL】EIP-7906 Assertions de transaction via des opcodes de différence d'état【Niveau B】
Améliore l'auditabilité statique des résultats de transaction. Les utilisateurs peuvent actuellement affirmer des résultats positifs, mais ne peuvent pas contraindre « aucune autre modification d'état ». Pour prouver l'absence de modifications supplémentaires, de nouveaux opcodes sont nécessaires. Une assertion positive (par exemple, le solde WETH augmente d'au moins 1,5) combinée à une assertion négative (aucune autre modification d'état) permet de verrouiller tous les effets d'une transaction sans simulation, les portefeuilles matériels étant un scénario bénéficiaire clé. Cette proposition est assez complexe et nécessite une prudence pour être incluse dans une mise à niveau majeure. Nous recommandons de l'avancer uniquement si deux conditions sont remplies : 1) Les équipes client comprennent parfaitement tous les détails et les impacts en cascade ; 2) La portée des tests et l'évaluation des risques potentiels sont complètes.
【EL】Migration des EOA【Niveau B】
L'EIP-7851 et l'EIP-8151 peuvent être considérées ensemble, formant un schéma de migration des comptes externes (EOA) vers des comptes intelligents. Le chemin est le suivant : Un EOA délègue d'abord à un compte intelligent via l'EIP-7702 ; l'EIP-7851 ajoute un opcode pour rendre permanente la relation de délégation, désactivant la clé ECDSA d'origine ; l'EIP-8151 fait en sorte que ecRecover reconnaisse que la clé est désactivée, empêchant le vol d'actifs via des transactions de type Permit avec l'ancienne clé. Classée niveau B : Ce n'est qu'un schéma de migration d'EOA parmi d'autres, n'ayant pas encore bénéficié d'un examen large ni d'un consensus communautaire. Le plus grand risque est la compatibilité multi-chaînes : les utilisateurs devraient répéter l'opération de migration sur chaque L2, y compris les chaînes pas encore nées, ce qui entraîne une mauvaise expérience utilisateur. Nous attendons un schéma qui utilise L1 comme racine de confiance, une opération unique s'appliquant à toutes les chaînes EVM ; un tel schéma pourrait être promu aux niveaux A/S.
【EL】Standard de signature post-quantique【Niveau A】
Hegotá devrait établir une voie claire pour l'adoption de signatures post-quantiques, mais la meilleure mécanique doit être déterminée avant la mise en œuvre formelle. L'EIP-8355 ajoute un contrat pré-compilé ML-DSA : Combiné avec les transactions Frame, il permet des capacités de sécurité de compte post-quantiques. Alternative : Pré-enregistrer le support des signatures post-quantiques sans les activer immédiatement, ou définir un format de dérivation compatible avec les clés post-quantiques.
【EL】EIP-7819 Instruction SETDELEGATE【Niveau A】
Une fois l'AA native déployée dans Hegotá, il est crucial de réduire le coût de déploiement des comptes intelligents. Mais l'EIP-8037 de Glamsterdam augmentera le coût de création de compte. L'EIP-7819 permet à un nouveau compte d'utiliser un pointeur de délégation léger, remplaçant le contrat proxy, réduisant considérablement le nouveau stockage d'état et les coûts de déploiement. Classée niveau A car des coûts de déploiement de compte plus bas peuvent significativement abaisser la barrière à l'entrée pour l'AA.
Optimisation des performances : Poursuite de l'expansion de la couche L1
Glamsterdam a marqué un changement dans l'approche de recherche et développement d'Ethereum : la performance est devenue une contrainte centrale dans la conception du protocole et le développement des clients. L'exécution différée, les ajustements de tarification des ressources, les optimisations massives des clients ont augmenté la capacité de charge du réseau de 30 millions de Gas à au moins 200 millions de Gas en deux ans. L'optimisation des performances crée des options, la marge de performance libérée pouvant être utilisée pour l'expansion, le raccourcissement des créneaux, la réduction des exigences matérielles des nœuds, ou pour atteindre plusieurs objectifs simultanément.
Le besoin d'expansion reste urgent. Les projets choisissent leur emplacement non seulement en fonction des prix actuels du Gas, mais aussi de la capacité d'Ethereum à augmenter continuellement et de manière stable l'offre d'espace de blocs. La mise en œuvre continue de mises à niveau d'expansion donne bien plus de confiance aux développeurs qu'une feuille de route sur papier. Le réseau principal est encore loin de supporter de manière stable les pics de trafic : lors du 11e anniversaire d'Ethereum, la médiane du Gas était d'environ 0,1 gwei, une seule activité de frappe NFT a poussé le Gas dans la fourchette des 10 gwei, le coût médian des transactions dépassant 1 dollar. La tendance à l'expansion initiée par Glamsterdam doit se poursuivre avec Hegotá.
En résumé, les EIP suivantes poursuivent l'élan d'expansion de Glamsterdam tout en renforçant le principe plus large qui le sous-tend : la performance doit toujours être une considération primordiale dans le travail des clients et la conception du protocole.
【EL】EIP-8131 & EIP-8279【Niveau S】
Propositions combinées de tarification des données Après la mise à niveau Glamsterdam, le goulot d'étranglement central du réseau est devenu la propagation de la charge utile des blocs. La racine du problème est que différents types d'octets de ressources ont des normes de comptabilisation du Gas non uniformes, certaines même sans frais. L'EIP-8131 unifie la limite inférieure de base des transactions : étend les règles minimales de frais existantes aux données pouvant être confirmées avant l'exécution ; L'EIP-8279 limite inférieure d'octets pour la liste d'accès du bloc : applique des frais aux octets de la liste d'accès générés dynamiquement pendant l'exécution.
Le mécanisme de tarification dynamique rend l'EIP-8279 plus complexe, mais les deux devraient être considérées ensemble. La solution combinée permet une comptabilisation unifiée des octets associés aux transactions, limitant le pire scénario de charge de bloc, tandis que la grande majorité des transactions normales et à faible utilisation de données ne sont pas affectées. Elle comble les lacunes dans la comptabilisation des ressources, ouvrant la voie à de futures augmentations de la limite de Gas.
【CL】【EL】EIP-8146 【Niveau A】
L'EIP-8146 améliore le chemin critique lui-même en séparant la propagation du BAL et de la charge utile, complétant ainsi le mécanisme de retarification. Cela améliore non seulement l'efficacité de la propagation, mais permet également aux clients d'exécution de prendre de l'avance sur la pré-extraction d'état et le calcul postérieur de la racine d'état. Nous pensons que c'est une optimisation à faible coût à ne pas manquer. Le travail de mise en œuvre repose principalement sur le mécanisme de gossip CL familier, c'est donc une EIP à faible investissement et à haute valeur, surtout dans une branche avec beaucoup de code EL.
Autres propositions liées à l'expansion
【EL】Recalibrage CPSB【Niveau A】
Modification simple. Nous recommandons de continuer à l'avancer et de l'inclure soit en fonction de l'augmentation planifiée de la limite de Gas, soit de l'utilisation de l'état on-chain et du Gas d'exécution. L'EIP-8368 Calibration CPSB pour la nouvelle limite de Gas : Proposition d'accompagnement après l'EIP-8037. Le coût des octets d'état passe d'un ajustement dynamique basé sur la limite de Gas à une valeur fixe, simplifiant le développement et les tests. Le CPSB actuel est basé sur une limite de Gas de 150 millions ; après l'augmentation de la limite de Gas, Hegotá aura probablement besoin d'un recalibrage. L'EIP-8372 Standardisation de la limite de Gas d'état : Extension de l'EIP-8368, avec un grain d'ajustement plus fin pour les scénarios où les objectifs de croissance d'état ou les objectifs de Gas réguliers s'écartent des attentes.
【EL】EIP-7862 Racine d'état différée【Niveau B】
La spécification elle-même est simple, mais d'après nous, la complexité de la mise en œuvre par les clients n'est pas encore pleinement comprise. La racine d'état est omniprésente dans les bases de code. Les bénéfices à court terme sont limités, la valeur principale étant concentrée à long terme (prolongation de la durée de disponibilité des preuves de racine d'état). Cette Hegotá subit déjà une pression importante pour les modifications de la couche d'exécution.
【CL】EIP-8341 Engagement de charge utile d'exécution partielle【Niveau D】
Il est recommandé de ne pas l'inclure. Bénéfices limités (retarde légèrement le calcul de la racine d'état), le besoin n'est pas pressant, et l'EIP-7862 peut offrir un effet plus fort, pouvant directement la remplacer.
Discussion catégorisée des EIP restantes
Nous abordons maintenant les propositions restantes, regroupées par thème. Pour certaines propositions, notre avis est encore en formation ; nous mettrons à jour en continu en fonction des communications avec les équipes client et les auteurs.
Hegotá devrait être une mise à niveau majeure avec des modifications substantielles sur la couche d'exécution, nous devrions donc contrôler strictement l'entrée des EIP de la couche d'exécution. À l'exception de FOCIL et Quick Slots, nous devrions limiter autant que possible l'étendue des modifications de la couche consensus : réduire la portée de la mise à niveau pour laisser aux équipes client suffisamment de temps pour faire face aux futures transformations architecturales majeures.
【CL】Lié au mécanisme d'émission
Nous ne classons pas par priorité l'EIP-8363 Émission et destruction progressives. La politique d'émission inflationniste ne devrait pas être décidée unilatéralement par les développeurs principaux ; une liste de priorités équivaut à donner une recommandation de mise en œuvre claire aux développeurs principaux. La grande majorité des EIP relèvent de décisions techniques, la communauté déléguant le pouvoir décisionnel aux développeurs principaux ; mais le mécanisme d'émission relève de la politique monétaire, nécessitant un large consensus communautaire. L'opinion des développeurs principaux ne sert que de référence pour la discussion publique. La classer au même niveau que les EIP ordinaires équivaut à la traiter comme une décision technique ACD habituelle.
D'un point de vue technique, l'EIP-8363 a de la valeur. Avec l'augmentation de l'ETH total mis en jeu, la crédibilité du mécanisme de pénalité (slashing) diminue ; à un taux de mise en jeu élevé, les nouvelles récompenses compensent largement l'inflation ; les économies d'échelle continuent d'accroître l'écart entre les grands opérateurs et les validateurs indépendants. Mais les changements comportent aussi des risques : la distribution de la mise en jeu est incertaine, le processus de solidification de la politique monétaire serait relancé. Le post de discussion publié par Ansgar énumère complètement les arguments pour et contre, en accord avec notre position. Certains membres de notre équipe ont précédemment soutenu un ajustement du mécanisme d'émission et maintiennent ce jugement.
Nous recommandons de discuter de l'ajustement du mécanisme d'émission après que tous les autres aspects du périmètre de Hegotá aient été finalisés. Donner à la communauté suffisamment de temps pour discuter, évitant d'interférer avec le fil principal de définition du périmètre de la mise à niveau.
【CL】Optimisation des fonctionnalités de staking
Les améliorations du staking ont de la valeur, mais il faut privilégier les optimisations orientées vers l'utilisateur final ; les modifications purement infrastructurelles doivent être reportées, sauf si nécessaires.
【CL】EIP-8015 Suppression des champs deposit et eth1data【Niveau A】
Nettoyage léger de la dette technique historique. S'appuie sur l'EIP-7688 pour une compatibilité ascendante des structures de données de consensus, les preuves Merkle des champs obsolètes ne sont pas affectées, ne perturbant pas les lecteurs de données on-chain.
【EL】【CL】EIP-8237 Synchronisation indépendante de la couche consensus / exécution【Niveau B】
Construit sur la séparation ePBS des blocs phares et de la charge utile, permettant une synchronisation indépendante de CL et EL, pourrait simplifier la logique complexe des clients.
【CL】EIP-8205 Pré-enregistrement des informations de retrait【Niveau D】
Il est recommandé de ne pas l'inclure. Bien qu'elle résolve un vrai problème du staking délégué, les solutions de pré-dépôt existantes peuvent déjà y faire face ; la complexité ajoutée par un nouvel ensemble de mécanismes de protocole ne correspond pas aux bénéfices à ce stade.
【CL】EIP-8148 Seuil de liquidation personnalisé par validateur【Niveau D】
Il est recommandé de ne pas l'inclure. Mécanisme complexe (ajout d'un contrat système, de requêtes d'exécution, de logique de couche consensus), bénéfices limités, ne faisant que légèrement avancer l'intégration du staking des particuliers. Compte tenu de la distribution actuelle du staking, cela ne changera probablement pas significativement la tendance à la concentration des validateurs sur le réseau.
【CL】EIP-8372 Brûlage forcé des récompenses d'exécution ePBS【Niveau D】
Il est recommandé de ne pas l'inclure. Cela incitera probablement à davantage de canaux hors-chaîne. Des années de discussion sur le brûlage du MEV n'ont pas abouti à un schéma faisant largement consensus.
【CL】EIP-7716 Pénalité pour preuve anti-corrélation【Niveau D】
Il est recommandé de ne pas l'inclure. Manque de preuves suffisantes pour justifier un ajustement majeur des incitations au staking, et la mise à niveau du consensus découplé redessinera le système d'incitations au staking.
【CL】EIP-8333 Alignement des points de contrôle sur les blocs de limite d'époque【Niveau D】
Il est recommandé de ne pas l'inclure. C'est un travail d'optimisation et de nettoyage qui peut être reporté pour être traité avec la mise à niveau majeure plus vaste du consensus découplé.
【CL】EIP-8359 Champ de rapport de bloc phare【Avis en cours de formation】
【CL】Travaux préparatoires pour la mise à niveau post-quantique
Les propositions suivantes réduisent la dépendance aux signatures BLS, pavant la voie à la transition post-quantique à long terme.
【CL】EIP-8365 Mise hors service des informations de retrait BLS【Niveau A】
Met hors service les anciennes informations de retrait, simplifiant le protocole et préparant la future transition post-quantique. Modification simple, adaptée pour une mise en œuvre maintenant.
【CL】EIP-8367 Mise hors service du mécanisme d'expiration du solde des validateurs BLS【Niveau D】
Il est recommandé de ne pas l'inclure. La grande majorité des validateurs avec l'information 0x0 migreront leurs informations avant ou après le déploiement de l'EIP-8365, retirant leurs fonds ou continuant à staker. Aucun besoin d'ajouter un mécanisme spécifique pour traiter le stock restant ; déployer d'abord l'EIP-8365 et observer la situation réelle.
【CL】EIP-8321 RANDAO à chaîne de hachage【Niveau D】
Il est recommandé de ne pas l'inclure. Implémenter uniquement la sécurité post-quantique du RANDAO a un intérêt limité, la clé BLS du validateur reste à risque ; de plus, chaque validateur ajoute 32 octets de données, ajoutant une logique de gestion des clés pour un usage unique. La solution complète de consensus post-quantique n'est pas encore mise en œuvre. Nous soutenons les mises à niveau itératives, mais la première étape devrait suivre une feuille de route unifiée pour éviter qu'une solution soit remplacée par le standard final.
【EL】【CL】Optimisation d'adaptation pour zkEVM
La plupart des optimisations préparatoires pour zkEVM offrent des bénéfices à court terme limités, facilitant uniquement l'exécution de nœuds complets pour des groupes spécifiques, tout en consommant des ressources de développement et pouvant potentiellement augmenter le coût d'exécution de l'EVM. Seules les propositions dont la valeur à long terme dépasse significativement le coût à court terme méritent d'être incluses.
【CL】EIP-8025 Preuve d'exécution optionnelle【Niveau D】
Ne devrait pas être incluse dans cette mise à niveau. La proposition elle-même n'impose pas de mise à niveau majeure, l'associer à Hegotá n'est qu'une demande de priorité, ce que nous ne soutenons pas. Avant de déployer une preuve optionnelle, la forme finale à long terme devrait être clarifiée, progressant de manière stable, et ne pas être mise en œuvre à la hâte avant que le modèle de validateur/état ne soit fixé. Question clé non résolue : Les validateurs doivent-ils conserver/stocker une partie de l'état, ou être complètement sans état ? Les validateurs sont un groupe important de nœuds, disposant de ressources matérielles et réseau ; les modifications qui affaiblissent leur rôle nécessitent un seuil d'entrée plus élevé.
【EL】EIP-7666 ÉVMyfier le pré-compilé d'identité【Niveau A】
Modification simple, offre une valeur pratique.
【EL】EIP-8200 ÉVMyfier les pré-compilés【Niveau B】
Remplace trois catégories de pré-compilés natifs par du bytecode EVM. Deux catégories sont peu utilisées, migration facile ; la troisième est largement utilisée pour les preuves SNARK. Une évaluation d'impact doit être réalisée pour confirmer que le coût de migration est gérable, ou pour retirer la troisième catégorie de la portée, avant de pouvoir la promouvoir au niveau A.
【EL】EIP-7709 Lire BLOCKHASH depuis le stockage et ajuster le Gas【Niveau D】
L'augmentation du Gas est importante, perturbation notable, le besoin n'est pas pressant. Pour réduire les risques, une évaluation d'impact pourrait être menée, ou elle pourrait être associée à un mécanisme de préchauffage des blocs pour un déploiement ultérieur.
【EL】EIP-8268 Inclure la racine de stockage dans la liste d'accès du bloc【Niveau B】
Nécessite une évaluation de l'impact réel sur le volume de la liste d'accès et le coût en Gas des transactions (l'EIP-8279 appliquera des frais aux octets de la liste d'accès), chaque entrée de compte d'accès incluant en plus la racine de Merkle du stockage.
【EL】Fonctionnalités natives de l'EVM
Hegotá verra encore certaines améliorations dispersées de l'EVM. Nous pensons qu'après cette mise à niveau, Ethereum devrait élaborer conjointement avec tout l'écosystème EVM une feuille de route de développement à long terme pour l'EVM, à laquelle Ethlabs participera.
【EL】EIP-5920 Opcode PAY【Niveau A】
Logique simple, primitive de bas niveau très utile pour l'EVM. Nécessite encore de clarifier les cas d'usage réels.
【EL】EIP-8163 Réserver l'opcode EXTENSION (0xae)【Niveau A】
Hautement utile pour les L2, coût quasi nul pour L1, sert uniquement de réservation d'identifiant.
【EL】Réutilisation du code de contrat【Niveau B】
EIP-8058 Remise pour déduplication du bytecode de contrat, EIP-8298 Instruction SETCODEFROM pour réutilisation de code S'appuie sur le modèle de stockage client : le code du contrat est stocké indépendamment, le compte pointe vers le code via un hachage. Les deux propositions implémentent le stockage unique du même code, réduisant les coûts de déploiement. L'idée est attrayante, mais nécessite une évaluation de l'impact sur la compatibilité ascendante de la structure de stockage arborescente. Aucune préférence claire entre les deux propositions pour l'instant.
【EL】Réforme de la tarification de la mémoire【Niveau B】
Nous n'avons pas encore déterminé si une réforme de la mémoire est appropriée pour Hegotá. Notre compréhension de l'espace de conception n'est pas encore complète. EIP-7686 Limite de mémoire EVM linéaire : Modification mineure, supprime le coût de croissance quadratique de l'expansion de la mémoire ; EIP-7923 Tarification de la mémoire linéaire basée sur la pagination : Refonte des règles sous-jacentes, plus complète, mais plus complexe.
【EL】EIP-8219 Opcodes arithmétiques avec vérification de dépassement【Niveau B】
Ajouter des fonctions d'opération sécurisées natives à l'EVM a de la valeur. Nécessite des tests de référence pour confirmer un prix raisonnable ; après une évaluation d'impact (nombre de transactions bénéficiaires, état de l'adaptation des compilateurs) pourrait être promue au niveau A.
【EL】EIP-8360 Opcode TCREATE【Niveau B】
Prend en charge la création de contrats temporaires durant le cycle de vie d'une transaction, primitive de bas niveau polyvalente. Mais la proposition est assez complexe, pourrait être reclassée après évaluation de la difficulté de développement et de test.
【EL】EIP-7645 Alias ORIGIN pointant vers SENDER【Niveau D】
Il est recommandé de ne pas l'inclure. Modification destructrice, abuse de la sémantique d'ORIGIN.
【EL】EIP-8182 Transferts privés natifs d'ETH et d'ERC20【Niveau D】
Il est recommandé de ne pas l'inclure. Modification d'envergure massive, introduit une dépendance aux ZK. Si elle est mise en œuvre à l'avenir, elle devrait être une proposition centrale de mise à niveau.
【EL】EIP-2488 Dépréciation de l'opcode CALLCODE【Avis en cours de formation】
【EL】EIP-4758 Désactivation de SELFDESTRUCT【Avis en cours de formation】
【EL】EIP-7979 Opcodes d'appel et de retour EVM【Avis en cours de formation】
【EL】EIP-8173 Fondations du flux de contrôle EVM【Avis en cours de formation】
【EL】EIP-8253 Incrémentation du nonce du compte de stockage avec nonce zéro【Avis en cours de formation】
【EL】EIP-8030 Ajout du support de l'algorithme P256【Avis en cours de formation】
【EL】Mécanismes de tarification de l'EVM
Glamsterdam a augmenté les coûts en Gas d'opérations sous-tarifées qui limitaient le débit. Les propositions de tarification associées à Hegotá vont dans la direction opposée : réduire les coûts d'opérations actuellement sur-tarifées qui limitent l'adoption d'applications, mais contribuent peu à l'expansion globale du réseau, ce sont des optimisations « agréables à avoir ». Nous soutenons les ajustements de prix ciblés, mais les propositions ajoutant de nouveaux modèles de facturation doivent être bien conçues, avec des promoteurs déterminés ayant pleinement validé les risques, avant d'être incluses.
【EL】EIP-8358 Facturation nette du Gas pour les changements de compte【Niveau B】
Bénéfices incertains. Les données d'un échantillon de 900 blocs du réseau principal et 400 000 transactions montrent : seulement 2,07% des transactions économisent du Gas, le Gas total économisé par bloc ne représente que 1,14%.
【EL】EIP-7973 Facturation des écritures sur comptes chauds【Avis en cours de formation】
【EL】EIP-7609 Réduction du Gas de base pour TLOAD/TSTORE【Avis en cours de formation】
【EL】EIP-7971 Limite stricte pour le stockage transitoire【Avis en cours de formation】
【EL】EIP-3298 Suppression des remboursements de Gas【Avis en cours de formation】
【EL】EIP-8374 Conservation de l'ensemble d'accès chaud après annulation【Avis en cours de formation】
【EL】EIP-8115 Collecte groupée des frais de priorité en fin de bloc【Avis en cours de formation】
【EL】EIP-8188 Enregistrement du dernier bloc d'écriture pour les comptes et les emplacements de stockage【Avis en cours de formation】
【EL】【CL】Données d'exécution et indexation
【EL】【CL】EIP-7668 Suppression du filtre de Bloom【Avis en cours de formation】
【EL】【CL】EIP-7807 Format SSZ pour les blocs d'exécution【Avis en cours de formation】
【EL】EIP-8116 Simplification du champ de reçus cumulés【Avis en cours de formation】
【EL】EIP-8304 Indexation de logs et de transactions sans confiance【Avis en cours de formation】
【EL】【CL】Couche réseau
Le réseau P2P d'Ethereum a encore de la place pour des optimisations ciblées, en particulier dans les mécanismes de propagation des messages de transaction, de Blob et de preuve.
【CL】EIP-8371 Reconstruction distribuée de Blobs RowDAS【Niveau A】
Évite que la reconstruction complète et l'hébergement par les nœuds complets ne deviennent un goulot d'étranglement pour l'expansion des Blobs. À long terme, un mécanisme de reconstruction distribué devra être intégré au protocole, pourrait supprimer l'exigence d'hébergement de Blobs par les validateurs. Nécessite encore une évaluation de la complexité de mise en œuvre.
【CL】EIP-8142 Blob incorporant le bloc (BiB)【Niveau D】
Le moment n'est pas encore venu, l'urgence n'est pas là, laisse de nombreuses questions non résolues (utilisation ou non de KZG, création d'un nouveau sujet de diffusion). Ne souhaitons pas introduire le mécanisme KZG dans le chemin critique de production des blocs, les solutions alternatives ne sont pas claires.
【CL】EIP-8243 Diffusion groupée de preuves à la source【Niveau D】
Ne garantit pas clairement un raccourcissement du temps de finalisation, la limite de charge utile n'est pas claire ; la capacité du mécanisme à résister aux DoS nécessite une validation.
【EL】EIP-8077 eth/XX Diffusion de transactions basée sur le nonce【Avis en cours de formation】
【EL】EIP-8094 eth/vhash Protocole de mempool supportant les Blobs【Avis en cours de formation】
【CL】EIP-8334 Diffusion groupée de preuves【Avis en cours de formation】
Conclusion
Les mises à niveau d'Ethereum sont extrêmement risquées, donc une certaine complexité est inévitable. Des milliers de nœuds dans le monde doivent synchroniser le changement de règles au même créneau, le fonctionnement du réseau ne peut pas être interrompu. Cette rigueur a soutenu toutes les mises à niveau réussies d'Ethereum, réalisant un réseau décentralisé avec zéro temps d'arrêt pendant 11 années consécutives.
Ceci est le jugement actuel d'Ethlabs concernant Hegotá. À mesure que le développement avance et que les discussions s'approfondissent, nous mettrons à jour nos points de vue en présence de nouvelles preuves. Certaines EIP sont dirigées par des membres d'Ethlabs, les autres propositions proviennent des nombreux excellents chercheurs, développeurs de clients et contributeurs indépendants de la communauté Ethereum. Mais pour que toute solution soit mise en œuvre, la collaboration des équipes client, des portefeuilles, des applications, des L2, des fournisseurs d'infrastructure, des institutions, des opérateurs de nœuds et des utilisateurs finaux est indispensable. Ethereum appartient au monde entier, les progrès majeurs du réseau n'ont jamais été le fruit d'une seule organisation.
