Résumé de la dernière réunion de ETH Workshop Core Developers : Activer la mise à niveau Cancun sur le réseau de test début janvier 2024

Titre original : Ethereum All Core Developers ution Call #176 Writeup

Article original de Christine Kim

Compilation originale : Luccy, BlockBeats

Note de l’éditeur :

L’atelier ETH Tous les principaux appels de consensus des développeurs (ACDE) ont lieu toutes les deux semaines pour discuter et coordonner les modifications apportées à la couche d’exécution de l’atelier ETH (EL). Il s’agit de la 176e conférence téléphonique de l’ACDE, qui couvrira les discussions sur la mise à niveau de Cancun/Deneb, l’avancement des tests de Devnet #12 et le plan de mise à niveau de Prague/Electra.

Les développeurs ont discuté de la façon dont la mise à niveau Cancun/Deneb a été testée sur Devnet #12, y compris la progression et certains problèmes rencontrés par différentes équipes clientes, ainsi que les défis techniques liés à la propagation des blobs, à la valeur maximale extractible, etc. Pour la prochaine mise à jour Prague/Electra, les développeurs ont proposé une série de modifications techniques possibles.

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

Le 7 décembre 2023, ETH développeurs se sont réunis lors de l’appel Zoom for All Core Developers ution (ACDE) #176. La conférence téléphonique de l’ACDC est une série de réunions bihebdomadaires dirigées par Tim Beiko, responsable du support des protocoles à la Fondation ETH, au cours desquelles les développeurs discutent et coordonnent les modifications apportées à la couche exécutive (EL) de ETH Place. Cette semaine, les développeurs ont discuté du test de la mise à niveau Cancun/Deneb sur Devnet #12. Ils ont convenu de coordonner la date d’activation de la mise à niveau sur le réseau d’essai de Goerli au début du mois ETH janvier, après la fin des vacances. En outre, ils prévoient d’entamer des discussions au début du mois de janvier sur les modifications de code qui devraient être incluses dans la prochaine mise à niveau de l’atelier ETH, Prague/Electra.

Mise à jour Devnet #12

Les tests de la mise à jour Cancun/Deneb sur Devnet #12 se déroulent bien. Parithosh Jayanthi, ingénieur DevOps à la Fondation, a révélé que des bogues ont été trouvés chez deux clients, Reth et Lighthouse, et que les deux équipes clientes travaillent sur un correctif d’urgence. Pour tester les flux de travail MEV de manière plus approfondie, les équipes DevOps se concentrent davantage sur l’activation du logiciel MEV-Boost sur un plus grand nombre de validateurs sur Devnet #12. Selon Jayanthi, son équipe a trouvé au moins un bogue dans l’implémentation du relais MEV des Flashbots. Danny Ryan, chercheur à la Fondation ETH, a souligné que pour s’assurer que les validateurs peuvent passer à la construction de bloc local en cas de défaillance d’un relais, des tests supplémentaires sont nécessaires pour vérifier l’existence d’autres mécanismes.

Pour les mises à niveau d’équipe spécifiques au client, Terence Tsao, le développeur du client Prysm, a déclaré que son équipe travaillait sur une conception mise à jour pour la propagation d’#122中讨论的 d’objets blob ACDC. Tsao a confirmé que le client Prysm sera prêt à rejoindre Devnet #12 pour des tests la semaine prochaine, peut-être la semaine prochaine. Justin Florentine, le développeur du client Besu, a déclaré que Besu est prêt à quitter Devnet #12. Les représentants des équipes clientes de Nethermind, Erigon, Lodestar et Teku ont également déclaré qu’ils étaient prêts à continuer à tester la mise à niveau sur le réseau de test ETH public.

En fonction de l’état de préparation du client, Beiko recommande de coordonner une date de hard fork dès que les développeurs sont sortis des vacances. En supposant qu’aucun bogue majeur ne soit trouvé sur Devnet #12 dans les prochaines semaines après l’arrivée du client Prysm, Beiko déclare que l’activation de Cancun/Deneb sur Goerli est susceptible de se produire vers la mi-janvier. Ben Edgington, de l’équipe Teku, a demandé aux développeurs s’ils étaient confiants dans la modification du nombre d’objets blob par bloc de deux à trois. Ryan suggère des tests supplémentaires de l’augmentation des cibles de blob pendant le fork de l’ombre massive et l’activation de Cancun/Deneb sur Goerli. Beiko a confirmé que l’activation de la mise à niveau sur Goerli sera le « dernier test significatif » des trois cibles de blob par bloc. En supposant qu’aucun problème n’est détecté, les développeurs continueront d’utiliser le nombre accru d’objets blob pour l’activation du réseau principal.

Dans l’ensemble, Beiko a déclaré que les développeurs continueront à tester les mises à niveau sur Devnet #12 d’ici la fin des vacances. L’équipe DevOps prévoit de lancer au moins un shadow fork de Goerli d’ici la fin du mois de décembre en vue d’un véritable hard fork de Goerli en janvier. Si les développeurs se réunissent pour la nouvelle année, ils discuteront de la date d’activation du hard fork de Goerli.

Indicateurs de remplacement du constructeur

Ensuite, Tsao a demandé à l’équipe du client quels étaient ses progrès dans la mise en œuvre de l’indicateur de remplacement du constructeur. L’indicateur de remplacement du générateur est un nouveau champ booléen dans la mise à niveau de Cancun que le client de la couche d’exécution peut utiliser pour indiquer au client de la couche de consensus que lorsque le générateur détecte une activité de censure, le validateur doit revenir à la génération de blocs locale au lieu d’utiliser un générateur tiers. Comme le souligne Tsao, les détails de la mise en œuvre sur la façon de détecter les activités de révision du constructeur sont subjectifs et délibérément laissés à l’équipe du client pour la conception. Pour plus d’informations sur les indicateurs de remplacement du constructeur, veuillez vous référer aux procès-verbaux d’ACDC#112 et d’ACDE#165.

Le développeur de l’équipe client Geth, qui se fait appeler « Lightclient », a déclaré que son équipe avait implémenté le drapeau, mais qu’il ne le fusionnerait pas dans la version officielle « dans un avenir proche ». Les représentants des équipes de Besu et de Nethermind ont déclaré que cet indicateur facultatif n’avait pas encore été mis en œuvre chez leurs clients. Tsao a souligné que le drapeau peut être un outil utile, et qu’il est préférable de le mettre en œuvre le plus tôt possible pour décourager et décourager les pools de jalonnement ou les opérateurs de grands nœuds de validation de participer à certains « jeux de temps ». Tsao a expliqué que les validateurs peuvent gagner plus de MEV (Maximum Extractible Value) en retardant la propagation des blocs, et qu’après l’introduction des blobs après la mise à niveau de Cancun, il y aura un retard dans la propagation des blocs. Au cours de ces délais, les validateurs peuvent choisir d’inclure des transactions MEV plus rentables dans le bloc, ce qui n’est pas optimal pour la propagation d’objets blob en temps opportun.

Confirmant que les transactions blob devront rivaliser avec les transactions normales, un développeur pseudonyme de l’équipe Prysm, qui se fait appeler Potuz, a ajouté : « Les blob doivent rivaliser non seulement avec les frais, mais aussi avec la latence elle-même et tout le MEV gagné en retardant les blocs. Lors de la conception du mécanisme de tarification des blobs, j’ai pensé qu’il s’agissait d’un marché qui n’avait pas été bloqué ou pris en compte. Tsao a déclaré qu’il soulèverait à nouveau la question sur le Discord Ethereum Research pour une discussion plus approfondie. En outre, Ryan a souligné le dernier article des chercheurs de la Fondation Ethereum, Caspar Schwarz-Schilling et Mike Neuder, sur les « jeux de chronométrage » sur le site Web d’Ethresearch.

Avancement du projet

Ensuite, Beiko a partagé trois mises à jour liées au processus de planification de la mise à niveau de ETH Workshop. Tout d’abord, comme dans le #123上讨论的那样 de l’ACDC, Beiko a créé un document Meta EIP pour la mise à niveau Cancun/Deneb, qui répertorie toutes les propositions d’amélioration ETH (EIP) qui ont été incluses dans Cancun/Deneb. Il a été créé sur GitHub avec le numéro EIP 7569. De plus, Beiko a créé EIP 7568 en tant que document Meta EIP pour toutes les mises à niveau précédentes, et les développeurs n’ont pas créé de document dédié pour suivre la liste des EIP incluses dans la mise à niveau. EIP 7568 est lié à la spécification du code de mise à niveau.

Deuxièmement, Beiko a annoncé qu’il avait créé un nouveau fil de discussion sur le site Web d’Ethereum Magicians pour identifier la prochaine mise à niveau du réseau, Prague/Electra. Il a demandé aux développeurs de réfléchir de manière critique à l’opportunité de regrouper les mises à niveau de la couche d’exécution (EL) et de la couche de consensus (CL), comme l’ont fait les deux derniers hard forks. L’activation de certains changements de code, tels que l’EIP 7002, nécessitera des modifications à la fois EL et CL, de sorte que les mises à niveau de Prague et d’Electra devront être coordonnées. Cependant, pour d’autres modifications de code, telles que l’arborescence Verkle, il existe un moyen de reconcevoir l’implémentation et il suffit de mettre à niveau la CL.

Ryan a noté que les développeurs de la couche de consensus (CL) travaillant en parallèle avec l’arborescence Verkle apportent également des modifications au code pour prendre en charge l’échantillonnage de la disponibilité des données. Beiko conseille aux développeurs de ne pas entrer dans les détails de tous les EIP qu’ils souhaitent voir dans la mise à niveau Prague/Electra, mais plutôt d’examiner tous les changements de code candidats pendant les vacances et d’être prêts à en discuter sérieusement en janvier. Potuz est d’accord, ajoutant qu’un EIP conçu pour résoudre le problème croissant de ETH taille de l’ensemble des validateurs serait un changement de code important à Prague/Electra. Sur la base de la complexité des changements de code, Beiko recommande que pour certains EIP, tels que Verkle ou l’échantillonnage de la disponibilité des données, les développeurs organisent des réunions dédiées après les vacances pour discuter en détail de ces changements de protocole plus importants.