Résumé de la dernière réunion des développeurs principaux de ETH Place : Il y aura un shadow fork de Goerli et un test de la mise à jour Cancun/Deneb avant la fin de l’année

Titre original : Ethereum All Core Developers Consensus Call #124 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 (ACDC) ont lieu toutes les deux semaines pour discuter et coordonner les changements apportés à la couche de consensus (CL) de l’atelier ETH. Il s’agit de la 124e conférence téléphonique de l’ACDC, qui couvre les mises à jour de Devnet #12, les progrès de la mise à niveau Cancun/Deneb et les sujets liés à la diffusion de Slashable. Au cours de la réunion, les développeurs ont activement discuté des modifications mineures apportées au protocole réseau Libp2p afin de réduire l’effet d’amplification des messages volumineux sur les nœuds.

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 14 décembre 2023, ETH développeurs se sont réunis sur Zoom pour la session #124 de l’appel All Core Developers Consensus (ACDC). La conférence téléphonique de l’ACDC est une série de réunions bihebdomadaires dirigées par Danny Ryan, chercheur à la ETH Workshop Foundation, au cours desquelles les développeurs discutent et coordonnent les modifications apportées à la couche de consensus (CL) de l’atelier ETH. Cette semaine, les développeurs se sont concentrés sur l’avancement des tests de la mise à jour Cancun/Deneb sur le réseau de test Devnet #12. Depuis la réunion ACDE (All-Core Developer Execution) de la semaine dernière, toutes les combinaisons de clients Execution Layer (EL) et Consensus Layer (CL) ont été intégrées à Devnet #12, y compris le client Prysm. Le logiciel MEV-Boost est activé, mais les combinaisons de clients avec Prysm ne sont pas incluses. Les développeurs ont déclaré qu’ils étaient sur la bonne voie avec des plans pour lancer la branche fantôme de Goerli dans les deux prochaines semaines pour tester la mise à niveau Cancun/Deneb et inclure tous les clients. En outre, les développeurs ont discuté des règles de diffusion de l’information sur Slashable, ainsi que du calendrier des appels pour les deux prochaines semaines.

Mise à jour Devnet #12

Barnabas Busa, ingénieur DevOps à la Fondation ETH, a déclaré que toutes les combinaisons de clients EL/CL, y compris celles qui utilisent Prysm comme client CL, ont été intégrées avec succès dans Devnet #12. Le portefeuille de clients utilisant Prysm n’a pas été testé pour le logiciel MEV-Boost. Cependant, sur Devnet #12, le flux de travail MEV teste d’autres clients CL. Récemment, le client Lighthouse a fait l’objet d’une mise à jour de correctif pour corriger des bogues liés au MEV. De plus, Parithosh Jayanthi, un autre ingénieur DevOps de la Fondation, a déclaré qu’ils avaient remarqué un problème avec le nœud Besu sur Devnet #12 et qu’ils travaillaient toujours à déterminer la cause première. À l’étape suivante, les développeurs enverront délibérément des blocs malveillants sur le réseau, testeront des générateurs de blocs et exécuteront des tests de ruche pour les clients Prysm nouvellement ajoutés afin de tester les combinaisons de clients sur Devnet. Jayanthi a déclaré dans un message public sur Discord lors de l’appel que les développeurs prévoyaient toujours de lancer une branche fantôme sur le réseau de test Goerli d’ici la fin de l’année.

Mise à jour des informations sur les barres obliques

Ensuite, les développeurs ont brièvement discuté de plusieurs problèmes liés à la diffusion et au timing du message de Slashable sur le ETH après la mise à niveau Cancun/Deneb. Pour l’arrière-plan, les informations pouvant faire l’objet d’une barre oblique incluent la propagation de blocs et d’objets blob en double ou non valides. Dapplion, un développeur anonyme du client Lodestar, a fait une demande de tirage (PR) via GitHub qui vise à ajouter de nouveaux événements à l’API Beacon Chain pour permettre aux opérateurs de nœuds d’en apprendre plus rapidement sur les événements Slashable, ce qui serait particulièrement utile s’il y a une grande quantité d’informations Slashable. Dans ses relations publiques, Dapplion mentionne : « Pour les grands opérateurs, le coût total d’un événement de coupure dépend fortement de leur temps de réponse. S’il y a beaucoup de clés impliquées dans les erreurs opérationnelles, il peut s’écouler un certain temps avant que ces informations ne soient incluses dans la chaîne. Les relations publiques de Dapplion ont été fusionnées dans la spécification de l’API Beacon Chain avant l’appel et sont mises en œuvre par diverses équipes clientes de CL, telles que Prysm et Lighthouse.

Dapplion propose également un PR lié à la mesure du temps de propagation des blocs. Il a noté que la mesure du temps de propagation des blocs deviendra plus difficile en raison de la mise à niveau de Cancun/Deneb et de l’introduction des transactions d’objets blob. Dapplion développe la solution qu’il propose dans son communiqué de presse. Comme les développeurs l’ont remarqué dans le fil de discussion PR, ils ont tendance à résoudre ce problème en ajoutant un champ d’horodatage aux événements d’API Beacon Chain connexes existants.

Le troisième sujet abordé par les développeurs concernait la propagation des informations Slashable après la mise à niveau Cancun/Deneb : les conditions de propagation des blobs. Le développeur de lighthouse « sean » (ou « realbigsean » sur GitHub) a souligné que les règles existantes de propagation des blob entraînaient des conséquences inattendues. Au cours de l’appel, Sean a déclaré : « Si vous utilisez l’API Beacon pour l’authentification de diffusion, il est inattendu qu’une approche de commérages puisse conduire à des messages valides et invalides. La raison en est que, techniquement, il est possible de propager deux blobs avec des index d’objets blob différents de l’en-tête Slashable qui leur est associé. Vous êtes autorisé à les propager, mais pas ceux qui ont le même index d’objets blob. 」

Sean a ajouté que le comportement étrange en ce qui concerne la propagation de l’information par barre oblique des blobs n’a pas d’impact substantiel sur la santé du réseau, si ce n’est un résultat « étrange » que les opérateurs de nœuds doivent comprendre et analyser. Par conséquent, bien qu’il n’y ait pas d’urgence pour l’activation de Cancun/Deneb, il suggère que les développeurs envisagent d’apporter des modifications aux règles de gestion de la diffusion d’informations Slashable dans les futures mises à jour. Danny Ryan est d’accord, disant que les développeurs devraient prendre le temps de réfléchir de manière « holistique » à la façon de résoudre ce problème. Ryan suggère de revoir ce sujet en janvier pour donner aux développeurs le temps de concevoir un plan complet pour mettre à jour les règles de propagation des blob et des blocs de Slashable.

Ensuite, les développeurs ont discuté de modifications mineures du protocole réseau libp2p afin de réduire l’effet d’amplification sur les nœuds envoyant des messages volumineux, tels que des blocs avec un grand nombre d’objets blob. Sean a mis en évidence le nouveau message de contrôle « IDONTWANT », qui peut être utilisé pour avertir les pairs libp2p de mettre en pause l’envoi de messages volumineux. Ryan a déclaré qu’il essaierait de contacter l’équipe libp2p pour fusionner ce PR, et s’il y a d’autres retards, la question sera réexaminée lors de la conférence téléphonique de l’ACDE la semaine prochaine.