Résumé de la dernière réunion des développeurs principaux d’Ethereum : EIP-7702 intègre des doutes, la conversion de la méthode de sérialisation de la couche d’exécution

**Écrit par : Christine Kim

Compilation : Luccy, BlockBeats

En plus de se préparer pour la bougie à longue mèche Pectra Devnet 0, les développeurs ont discuté de nouvelles propositions d’EIP, de la discussion et de l’analyse des EIP existants et de l’analyse de l’impact des smart contracts et des transactions. Parmi eux, la discussion de l’EIP 7702 a attiré beaucoup d’attention de la part des participants, et la proposition a été considérée comme un remplacement potentiel de l’EIP 3074.

Christine Kim, VP de la recherche chez Galaxy Digital, a donné une note détaillée sur les points forts de la réunion, que BlockBeasts a compilée comme suit :

Le 9 mai 2024, les développeurs Ethereum se sont réunis à Zoom pour la session #187 de l’appel All Core Developers ution (ACDE). La conférence téléphonique ACDE est une série de réunions bihebdomadaires dirigées par Tim Beiko, responsable du support protocole à la Fondation Ethereum, où les développeurs discutent et coordonnent les modifications apportées à la couche d’exécution Ethereum (EL). Cette semaine, les développeurs ont discuté des préparatifs de Pectra Devnet 0, des mises à jour de l’implémentation EIP 3074 et de l’urgence de convertir les méthodes de sérialisation sur EL de MPT à SSZ.

Mise à jour Pectra Devnet-0

Barnabas Busa, ingénieur des opérations de développement à la Fondation Ethereum, a déclaré que son équipe testait la configuration client du premier réseau de test Pectra axé sur les développeurs et s’efforcerait d’assurer une configuration stable de Pectra Devnet 0 d’ici le lundi 13 mai. Selon l’outil de suivi de l’état de préparation Pectra Devnet 0, les équipes clientes de Geth, Nethermind et EthereumJS ont entièrement implémenté la spécification de code Pectra.

Au cours de l’appel, Justine Florentine, développeuse chez Besu, a déclaré que tous les EIP Pectra ont été implémentés sur Besu, mais que son équipe travaille toujours sur le débogage du code. Andrew Ashikhmin, le développeur d’Erigon, a déclaré que son équipe avait déjà commencé à traiter tous les EIP, à l’exception de l’EIP 7002, qui est un retrait déclenchable EL. L’équipe de Reth a publié un lien vers son outil de suivi de la mise en œuvre dans un chat Zoom, montrant que son travail sur EIP 7002 est toujours en attente, tout comme l’équipe d’Erigon.

Du côté du client CL, le développeur de Grandine, Saulius Grigatis, a déclaré que toutes les EIP avaient été implémentées, mais lors de l’exécution avec le client EL, son équipe a rencontré quelques bugs. Les représentants de l’équipe Lighthouse ont déclaré qu’ils étaient sur le point d’avoir une implémentation complète prête pour Pectra Devnet 0 et ont noté que la spécification de l’API du moteur devait être mise à jour. Mikhail Kalinin, développeur chez Teku, a déclaré qu’il travaillait à l’ajout de ces mises à jour à la spécification de l’API du moteur.

Mario Vegas de l’équipe de test EF a déclaré que les développeurs travaillaient sur l’ajout de cas de test pour EIP 3074, AUTH et AUTHCALL Code d’opération, et plusieurs autres EIP.

Mise à jour EIP-3074

Bien que les développeurs aient accepté de conserver EIP 3074 dans la spécification de Pectra Devnet 0, une alternative EIP a été discutée pour la remplacer, EIP 7702. Le développeur de Geth, « Lightclient », a résumé la dernière session en petits groupes sur EIP 3074, au cours de laquelle les participants ont discuté des changements à prioriser dans la mise à niveau de Pectra qui sont liés à l’amélioration des compte Programmabilité de contrôle des utilisateurs. Selon Lightclient, tous les participants ont convenu que l’abstraction de compte native complète est encore à quelques années d’être implémentée sur Ethereum. Cependant, il n’y a pas de désaccord sur la question de savoir si cela signifie donner la priorité aux changements apportés aux compte appartenant à l’extérieur (EOA) ou migrer les EOA vers smart contracts Portefeuille. Le 8 mai, la veille de cet appel de l’ACDE, Ethereum cofondateur Vitalik Buterin a proposé un nouveau EIP, EIP 7702, qui permettra à Ethereum de support un nouveau type de transaction pour permettre aux EOA de fonctionner comme smart contracts Portefeuille lors d’une seule transaction. Selon Lightclient, les participants aux séances en petits groupes de l’EIP 3074 étaient généralement positifs à l’égard de l’EIP 7702. Cependant, il a ajouté plus tard qu’il restait encore des détails importants à régler sur l’EIP 7702. Par exemple, les détails sur la façon dont les transactions EIP 7702 sont inversées et sur la façon de mettre à l’échelle le coût du gaz pour ces transactions restent flous.

Si EIP 7702 est accepté et inclus dans la mise à niveau de Pectra, il sera considéré comme un remplacement de EIP 3074 car EIP 7702 obtient des résultats similaires à EIP 3074 mais ne crée pas de nouveaux codes de fonctionnement sur Ethereum et améliore la facilité d’analyse statique du nouveau comportement EOA. Le chercheur d’EF, Ansgar Dietrichs, a suggéré dans un chat Zoom que l’EIP 7702 soit envisagé pour inclusion dans Pectra et qu’une décision formelle sur le remplacement de l’EIP 3074 par 7702 devrait être prise dans environ 2 à 4 semaines. Il ressort clairement de la discussion des développeurs sur l’EIP 7702 lors de la conférence téléphonique que d’autres travaux étaient nécessaires avant que la proposition puisse être considérée comme prête à être mise en œuvre. Le développeur de Nethermind, Ahmad Mazen Bitar, a noté que le travail déjà effectué pour EIP 3074 pourrait ne pas être réutilisé pour implémenter 7702. Beiko a confirmé que les développeurs devraient toujours aller de l’avant avec la mise en œuvre de EIP 3074 pour Devnet 0 et revoir la spécification Devnet-1 plus tard.

EIP-7685, SSZ et EIP-6110

Les développeurs ont ensuite discuté de certaines des préoccupations soulevées par le développeur Nimbus Etan Kissling au sujet de l’EIP 7685, à savoir les requêtes génériques de couche d’exécution. Dans un commentaire GitHub sous l’ordre du jour de la conférence téléphonique de cette semaine, Kissling a demandé s’il était nécessaire de proposer une conception pour une demande de couche d’exécution commune, et si cette opportunité pourrait être mieux utilisée pour passer à SSZ, un format de sérialisation que les développeurs ont voulu mettre à jour sur la couche d’exécution depuis la mise à niveau Merge. L’équipe client de la couche d’exécution la plus longue lors de la conférence téléphonique prend en charge le maintien de EIP 7685 dans Pectra, et s’il existe des obstacles à l’inclusion d’EIP en fonctionnement, tels que la synchronisation optimiste des clients, revoyez la conception.

En ce qui concerne le sujet de SSZ, Kissling a expliqué que le nouveau format de conception pour la demande Common Execution Layer est basé sur les formats de sérialisation traditionnels MPT et RLP, de sorte qu’il devra être mis à jour lorsque les développeurs passeront à SSZ. Il souligne que si les développeurs continuent de créer de nouvelles structures de données MPT/RLP, retarder le passage à SSZ ne fera qu’entraîner plus de travail long pour les développeurs. Cependant, il n’y a pas eu de support fort de la part de l’équipe client d’exécution pour inclure EIP 7495, le conteneur stable SSZ, dans Pectra. Un développeur nommé « Dustin » a écrit dans un chat Zoom que la décision de reporter la transition SSZ était « folle » et que le problème de la bibliothèque SSZ fonctionnait mal dans EL était « un problème sérieux ».

En ce qui concerne EIP 6110, le dépôt de validation d’approvisionnement hors chaîne, Kissling a posé des questions sur les commandes de dépôt. Kalinin a déclaré qu’il était d’accord pour dire que la question était « une préoccupation importante » et qu’il travaillerait avec les principaux pools de jalonnement pour enquêter plus en profondeur.

Mise à jour de l’EOF

Danno Ferrin, développeur Ethereum protocole indépendant, et Alex Beregszaszi, responsable de la recherche chez EF Solidity, font le point sur les efforts de mise en œuvre de l’EOF. Le contexte est que l’EOF est une série de modifications de code visant à améliorer le EVM Machine virtuelle (EVM) que les développeurs envisagent d’inclure dans la mise à niveau de Pectra. La méta-EIP de l’EOF a été finalisée. Les développeurs ont également simplifié le processus de création de transactions dans l’EOF et travaillent sur une implémentation côté client de l’EOF.

Mise à jour EIP-7623

Un développeur qui a utilisé le pseudonyme « William Morris » lors de la conférence téléphonique a fait part de ses préoccupations concernant la modification du coût du gas du stockage calldata dans EIP 7623. Il a expliqué que les changements permettront à certains utilisateurs d’effectuer des transactions en abandonnant leurs transactions pour réduire les frais, encourageant la création d’un marché secondaire pour les remises sur le gaz afin que les rollups de deuxième niveau (L2) et les autres participants puissent effectuer des transactions sur le réseau à moindre coût. Il recommande un EIP alternatif, EIP 7703, qui résout ces problèmes en augmentant le coût des données d’appel à un taux forfaitaire.

Buterin a déclaré que bien que les préoccupations de Morris soient légitimes, la probabilité de créer un marché secondaire pour les données d’appel à la suite de l’EIP 7623 n’est pas élevée, car le nombre d’utilisateurs qui choisissent de participer à un tel marché sera extrêmement limité. Buterin a noté que les principaux acteurs affectés par EIP 7623 sont l’équipe de développement de Layer 2, Starkware et les créateurs d’inscriptions. Il a ajouté que, bien que le marché total adressable pour le marché secondaire des données d’appel soit petit, le pump short supérieur de la limitation de la taille maximale des blocs par le biais des données d’appel est extrêmement élevé, car cela permet aux développeurs d’augmenter la limite des blobgas et donc d’étendre Ethereum capacité à support L2. Vitalik a également déclaré que l’aplatissement du coût des données d’appel aurait également un impact plus sévère sur L2 et d’autres parties prenantes que l’EIP actuel, comme Morris l’a suggéré. Buterin a partagé des réflexions nostalgiques sur la tarification du gas blob dans un article de blog avant l’appel.

Toni Wahrstätter, co-auteur de l’EIP 7623, est d’accord avec Buterin, disant qu’il pense que du point de vue de l’utilité, la L2 la plus longue ne crée pas de marché secondaire pour les données d’appel. « D’un point de vue pratique, ce n’est pas très faisable, d’autant plus qu’un tel marché nécessite de la confiance et un haut degré de coordination entre les participants. Imaginez qu’en tant que L2, vous souhaitiez publier vos données sur L1, mais que vous ne sachiez pas quelle adresse publiera les données et où les données se retrouveront. Du point de vue de l’utilitaire, vous devez personnaliser l’index, etc. Je ne pense donc pas que ce soit très faisable », déclare Wahrstätter.

Le développeur de Reth, Georgios Konstantopoulos, a demandé si les développeurs étudiaient la possibilité d’augmenter les limites de blobgas si EIP 7623 était inclus dans Pectra. Sans augmenter la limite de gaz blob à mesure que l’EIP 7623 augmente, Konstantopoulos dit que l’EIP « ne résout pas la nostalgie du problème ». Dankrad Feist, chercheur chez EF, suggère d’augmenter la limite de gaz des blob au point où la taille maximale des blocs d’Ethereum reste la même, ce qui signifie que les shorts publiés à mesure que le coût des calldata augmentent seront remplis de blobs (objets binaires volumineux). Ansgar Dietrichs, chercheur chez EF, a déclaré que l’EIP est utile non seulement lorsqu’elle est combinée à une augmentation des limites de gas des blobs, mais aussi du point de vue de la sécurité, car elle peut garantir que le réseau n’est pas déstabilisé par des blocs contenant le plus grand nombre de transactions et d’objets blob.

En ce qui concerne l’analyse de l’impact du EIP 7623 sur les smart contracts et les transactions, M. Wahrstätter a déclaré que sa proposition n’affecterait pas 98% des utilisateurs. Beiko a également mentionné que Parithosh Jayanthi, ingénieur des opérations de développement chez EF, pourrait effectuer une analyse plus approfondie de la spécificité de la limite de blobgas, en tenant compte de compte EIP 7623.

Nouveau remplacement pour EIP 7609

Au cours de l’appel, un développeur portant le pseudonyme « Charles C » a proposé une nouvelle EIP pour empêcher les attaques de ré-entrée dans les smart contracts. Charles a déclaré que la proposition, qui crée deux nouveaux codes d’opération pour sécuriser smart contracts, est une alternative à une proposition qu’il a précédemment soumise appelée EIP 7609, qui vise à réduire le coût de base de TLOAD/TSTORE dans Pectra. Charles a déclaré qu’il ne savait pas pourquoi EIP 7609 n’était pas envisagé pour Pectra et qu’il recueillait toujours les commentaires des développeurs sur la façon d’empêcher la ré-entrée de manière rentable. Il souligne que les solutions actuelles, telles que Reentrancy Guard d’OpenZeppelin et le code d’opération TLOAD / TSTORE, sont trop coûteuses pour les développeurs d’applications décentralisées à utiliser par défaut. Beiko a suggéré que les développeurs donnent leur avis à Charles sur ce nouvel EIP sur le Ethereum Magician Forum.