Résumé de la dernière réunion des principaux développeurs d'Ethereum : conversion des spécifications de l'API Beacon, optimisation du sous-réseau de preuve CL
Le 11 janvier, tous les principaux développeurs d'Ethereum ont participé à la 125e conférence téléphonique All Core Developers Consensus (ACDC).
Écrit par : Christine Kim
Compilé par : Luccy, BlockBeats
Note de l'éditeur : L'appel de consensus de tous les principaux développeurs (ACDC) d'Ethereum a lieu toutes les deux semaines pour discuter et coordonner les modifications apportées à la couche de consensus Ethereum (CL). Il s'agit de la 125e conférence téléphonique de l'ACDC. La conférence a fourni une brève mise à jour sur la situation des tests de la prochaine mise à niveau de Cancun/Deneb et a impliqué deux sujets de recherche tels que la transformation de la spécification API Beacon et l'optimisation du sous-réseau de certification de la couche consensus.
L'équipe de test a lancé le troisième et dernier shadow fork du testnet Goerli le 11 janvier pour préparer la mise à niveau Cancun/Deneb qui sera activée le 17 janvier. Dans le même temps, les développeurs ont discuté de la spécification de sélection du fork et ont pris la décision de lancer un fork de consensus de manière asynchrone à proximité de l'activation du réseau principal Cancun/Deneb. De plus, le développeur Lodestar « Dapplion » a partagé les derniers progrès sur le mappage des spécifications SSZ vers JSON du routage des API de balise et a discuté de petits changements liés aux sous-réseaux d'assertion de longévité (attnets).
Christine Kim, vice-présidente de la recherche chez Galaxy Digital, a enregistré en détail les points clés de cette réunion. BlockBeasts a compilé le texte original comme suit :
Le 11 janvier 2024, les développeurs d’Ethereum se sont réunis sur Zoom pour participer à la réunion n°125 de l’appel All Core Developers Consensus (ACDC). L'appel ACDC est une série de réunions bihebdomadaires organisées par Danny Ryan, chercheur à la Fondation Ethereum, au cours desquelles les développeurs discutent et coordonnent les modifications apportées à la couche de consensus Ethereum (CL). Cette semaine, les développeurs ont brièvement présenté les progrès des tests de mise à niveau de Cancun/Deneb et ont discuté de deux sujets de recherche, à savoir la conversion de la spécification Beacon API en mode OpenAPI et l'optimisation du sous-réseau d'attestation CL en exploitant les préfixes d'ID de nœud.
Cancún/Deneb Goerli Shadow Fork
L'équipe de test de la Fondation Ethereum a lancé un shadow fork du testnet Goerli le 11 janvier. Il s'agit du troisième et dernier fork fantôme de Goerli avant l'activation de Cancun/Deneb sur Goerli le 17 janvier. Les versions client finales de toutes les mises à niveau de Goerli sont testées sur Goerli Shadow Fork (GSF) #2. Parithosh Jayanthi, ingénieur DevOps à la Fondation Ethereum, a noté que l'analyse initiale du GSF#2 est positive, déclarant : « Les blobs et les blocs semblent se propager sans problème. » Concernant la version client finale de la mise à niveau Goerli et la spécification Cancun/Deneb Plus de détails peuvent être trouvés dans un article de blog publié par la Fondation Ethereum le 10 janvier.
Modifications du filtre de sélection de fourchette
Comme indiqué dans ACDC #114 et ACDC #115, quelques modifications mineures ont été apportées à la spécification de sélection du fork CL, et les équipes client devraient progressivement mettre en œuvre ces modifications de manière asynchrone à proximité de l'activation du réseau principal de Cancun/Deneb. Mikhail Kalinin de l'équipe du compte Teku a expliqué : « Auparavant, nous avons décidé de déployer progressivement ce changement dans Deneb et de le faire de manière peu coordonnée. » Par conséquent, ces changements devraient essentiellement être activés dans la version du réseau principal. Kalinin a suggéré que les équipes client puissent commencer à fusionner ces modifications dans leurs versions au cours des prochaines semaines, ou choisir d'attendre une limite d'époque, telle que l'époque d'activation de Cancun/Deneb, pour déclencher ces modifications après un horodatage spécifique. temps sur tous les clients. Pour plus de détails sur les modifications du filtrage par fork-select, veuillez lire cette pull request (PR) GitHub.
Les développeurs ont convenu à l'unanimité de fusionner ces modifications le plus rapidement possible sans avoir à attendre ou à se coordonner pour respecter les limites d'époque, démontrant ainsi la confiance de l'équipe client dans sa capacité à intégrer rapidement les modifications dans leur prochaine version.
Définition du type OpenAPI de l'API Beacon
Le développeur Lodestar "Dapplion" a partagé le mappage canonique SSZ vers JSON de toutes les routes API de balise terminées cette semaine. Les avantages de ce mappage incluent la simplification du code. "Le code est beaucoup plus concis et semble beaucoup plus clair", a déclaré Dappion. "Pour l'instant, ce n'est pas très important, mais pour les futurs forks, cela devrait alléger beaucoup de maintenance, et si nécessaire à l'avenir, nous pourrions facilement tout convertir en SSZ. Cette idée existe depuis un certain temps. Avec le temps, cela le fera rendre ce processus très facile. » Pour en savoir plus sur les discussions de coordination SSZ, veuillez lire la transcription de l’appel ACDE #153.
Dappion a demandé aux développeurs ce qu'ils pensaient du passage d'OpenAPI à SSZ comme prochaine étape. Aucune opposition significative n’a été entendue. Dappion a déclaré qu'il communiquerait avec les équipes concernées au sujet des modifications de spécifications qu'il a répertoriées dans la pull request (PR) et assurerait une transition en douceur.
Modifier le calcul du sous-réseau de preuve
Les développeurs ont également discuté de petites modifications apportées aux attnets, les sous-réseaux d'attestation à long terme des nœuds. Les Attnets sont les réseaux auxquels les opérateurs de nœuds de jalonnement se connectent lors de la publication de preuves de blocs. Les développeurs ont amélioré les attnets pour la dernière fois en mai 2023. Pour optimiser davantage les attnets, le développeur de Lighthouse, Age Manning, a proposé d'améliorer l'utilisation des préfixes d'ID de nœud pour faciliter la découverte des nœuds sur le sous-réseau, ou, selon les mots de Manning, "la recherche du préfixe pour trouver tous les nœuds du sous-réseau". pourraient avoir sur le réseau et les vecteurs d'attaque liés à l'utilisation des préfixes d'ID de nœud pour trouver des nœuds sont brièvement discutés. Ryan a déclaré que les changements proposés par Manning nécessiteraient de toute façon un hard fork. Il a demandé à Pop Chunhapanya, l'un des développeurs participant à l'appel, d'étudier les stratégies de mise en œuvre de la proposition de Manning et de recueillir les commentaires sur ce sujet auprès d'autres développeurs des PR.
Discussion sur Electra
Enfin, Ryan s'est ouvert aux suggestions de modifications de code ou de propositions d'amélioration d'Ethereum (EIP) à prioriser dans la prochaine mise à niveau post-Deneb (nom de code Electra). Ryan a déclaré qu'il mènerait une « conversation plus structurée » sur le sujet lors du prochain appel de l'ACDC dans deux semaines. En attendant, Ryan a encouragé les développeurs à consulter les EIP proposés sur Ethereum Magicians et GitHub et à partager leurs réflexions sur ces forums.
Ansgar Dietrichs, chercheur à la Fondation Ethereum, a déclaré qu'à son avis, l'échantillonnage de disponibilité des données (DAS) est une mise à niveau « de la plus haute priorité » axée sur la couche de consensus. « [DAS] Dans une large mesure, il a des fonctionnalités qui feraient normalement partie d'un EIP, mais juste à cause de la façon dont nous avons structuré 4844, cela ne nécessite pas vraiment de hard fork ou d'EIP supplémentaire, et je pense que le risque qui en découle est que il n'y aura peut-être pas la même visibilité", a déclaré Dietrichs. Ryan a contesté ce commentaire, affirmant qu'à son avis, le DAS serait inclus dans l'EIP car le changement serait naturellement lié aux discussions sur la modification des limites de gaz de données d'Ethereum. Pour plus d'informations sur ce qu'est le DAS et comment il est implémenté sur d'autres blockchains telles que Celestia, lisez ce rapport de Galaxy Research.
Ryan a mentionné qu'il existe un PR préliminaire pour DAS et qu'un numéro EIP formel sera proposé dans les deux semaines. Ryan a encouragé les équipes de comptes participant à l'appel à réfléchir à quelles devraient être leurs priorités chez Electra lors du prochain appel ACDC le 25 janvier.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Résumé de la dernière réunion des principaux développeurs d'Ethereum : conversion des spécifications de l'API Beacon, optimisation du sous-réseau de preuve CL
Écrit par : Christine Kim
Compilé par : Luccy, BlockBeats
Note de l'éditeur : L'appel de consensus de tous les principaux développeurs (ACDC) d'Ethereum a lieu toutes les deux semaines pour discuter et coordonner les modifications apportées à la couche de consensus Ethereum (CL). Il s'agit de la 125e conférence téléphonique de l'ACDC. La conférence a fourni une brève mise à jour sur la situation des tests de la prochaine mise à niveau de Cancun/Deneb et a impliqué deux sujets de recherche tels que la transformation de la spécification API Beacon et l'optimisation du sous-réseau de certification de la couche consensus.
L'équipe de test a lancé le troisième et dernier shadow fork du testnet Goerli le 11 janvier pour préparer la mise à niveau Cancun/Deneb qui sera activée le 17 janvier. Dans le même temps, les développeurs ont discuté de la spécification de sélection du fork et ont pris la décision de lancer un fork de consensus de manière asynchrone à proximité de l'activation du réseau principal Cancun/Deneb. De plus, le développeur Lodestar « Dapplion » a partagé les derniers progrès sur le mappage des spécifications SSZ vers JSON du routage des API de balise et a discuté de petits changements liés aux sous-réseaux d'assertion de longévité (attnets).
Christine Kim, vice-présidente de la recherche chez Galaxy Digital, a enregistré en détail les points clés de cette réunion. BlockBeasts a compilé le texte original comme suit :
Le 11 janvier 2024, les développeurs d’Ethereum se sont réunis sur Zoom pour participer à la réunion n°125 de l’appel All Core Developers Consensus (ACDC). L'appel ACDC est une série de réunions bihebdomadaires organisées par Danny Ryan, chercheur à la Fondation Ethereum, au cours desquelles les développeurs discutent et coordonnent les modifications apportées à la couche de consensus Ethereum (CL). Cette semaine, les développeurs ont brièvement présenté les progrès des tests de mise à niveau de Cancun/Deneb et ont discuté de deux sujets de recherche, à savoir la conversion de la spécification Beacon API en mode OpenAPI et l'optimisation du sous-réseau d'attestation CL en exploitant les préfixes d'ID de nœud.
Cancún/Deneb Goerli Shadow Fork
L'équipe de test de la Fondation Ethereum a lancé un shadow fork du testnet Goerli le 11 janvier. Il s'agit du troisième et dernier fork fantôme de Goerli avant l'activation de Cancun/Deneb sur Goerli le 17 janvier. Les versions client finales de toutes les mises à niveau de Goerli sont testées sur Goerli Shadow Fork (GSF) #2. Parithosh Jayanthi, ingénieur DevOps à la Fondation Ethereum, a noté que l'analyse initiale du GSF#2 est positive, déclarant : « Les blobs et les blocs semblent se propager sans problème. » Concernant la version client finale de la mise à niveau Goerli et la spécification Cancun/Deneb Plus de détails peuvent être trouvés dans un article de blog publié par la Fondation Ethereum le 10 janvier.
Modifications du filtre de sélection de fourchette
Comme indiqué dans ACDC #114 et ACDC #115, quelques modifications mineures ont été apportées à la spécification de sélection du fork CL, et les équipes client devraient progressivement mettre en œuvre ces modifications de manière asynchrone à proximité de l'activation du réseau principal de Cancun/Deneb. Mikhail Kalinin de l'équipe du compte Teku a expliqué : « Auparavant, nous avons décidé de déployer progressivement ce changement dans Deneb et de le faire de manière peu coordonnée. » Par conséquent, ces changements devraient essentiellement être activés dans la version du réseau principal. Kalinin a suggéré que les équipes client puissent commencer à fusionner ces modifications dans leurs versions au cours des prochaines semaines, ou choisir d'attendre une limite d'époque, telle que l'époque d'activation de Cancun/Deneb, pour déclencher ces modifications après un horodatage spécifique. temps sur tous les clients. Pour plus de détails sur les modifications du filtrage par fork-select, veuillez lire cette pull request (PR) GitHub.
Les développeurs ont convenu à l'unanimité de fusionner ces modifications le plus rapidement possible sans avoir à attendre ou à se coordonner pour respecter les limites d'époque, démontrant ainsi la confiance de l'équipe client dans sa capacité à intégrer rapidement les modifications dans leur prochaine version.
Définition du type OpenAPI de l'API Beacon
Le développeur Lodestar "Dapplion" a partagé le mappage canonique SSZ vers JSON de toutes les routes API de balise terminées cette semaine. Les avantages de ce mappage incluent la simplification du code. "Le code est beaucoup plus concis et semble beaucoup plus clair", a déclaré Dappion. "Pour l'instant, ce n'est pas très important, mais pour les futurs forks, cela devrait alléger beaucoup de maintenance, et si nécessaire à l'avenir, nous pourrions facilement tout convertir en SSZ. Cette idée existe depuis un certain temps. Avec le temps, cela le fera rendre ce processus très facile. » Pour en savoir plus sur les discussions de coordination SSZ, veuillez lire la transcription de l’appel ACDE #153.
Dappion a demandé aux développeurs ce qu'ils pensaient du passage d'OpenAPI à SSZ comme prochaine étape. Aucune opposition significative n’a été entendue. Dappion a déclaré qu'il communiquerait avec les équipes concernées au sujet des modifications de spécifications qu'il a répertoriées dans la pull request (PR) et assurerait une transition en douceur.
Modifier le calcul du sous-réseau de preuve
Les développeurs ont également discuté de petites modifications apportées aux attnets, les sous-réseaux d'attestation à long terme des nœuds. Les Attnets sont les réseaux auxquels les opérateurs de nœuds de jalonnement se connectent lors de la publication de preuves de blocs. Les développeurs ont amélioré les attnets pour la dernière fois en mai 2023. Pour optimiser davantage les attnets, le développeur de Lighthouse, Age Manning, a proposé d'améliorer l'utilisation des préfixes d'ID de nœud pour faciliter la découverte des nœuds sur le sous-réseau, ou, selon les mots de Manning, "la recherche du préfixe pour trouver tous les nœuds du sous-réseau". pourraient avoir sur le réseau et les vecteurs d'attaque liés à l'utilisation des préfixes d'ID de nœud pour trouver des nœuds sont brièvement discutés. Ryan a déclaré que les changements proposés par Manning nécessiteraient de toute façon un hard fork. Il a demandé à Pop Chunhapanya, l'un des développeurs participant à l'appel, d'étudier les stratégies de mise en œuvre de la proposition de Manning et de recueillir les commentaires sur ce sujet auprès d'autres développeurs des PR.
Discussion sur Electra
Enfin, Ryan s'est ouvert aux suggestions de modifications de code ou de propositions d'amélioration d'Ethereum (EIP) à prioriser dans la prochaine mise à niveau post-Deneb (nom de code Electra). Ryan a déclaré qu'il mènerait une « conversation plus structurée » sur le sujet lors du prochain appel de l'ACDC dans deux semaines. En attendant, Ryan a encouragé les développeurs à consulter les EIP proposés sur Ethereum Magicians et GitHub et à partager leurs réflexions sur ces forums.
Ansgar Dietrichs, chercheur à la Fondation Ethereum, a déclaré qu'à son avis, l'échantillonnage de disponibilité des données (DAS) est une mise à niveau « de la plus haute priorité » axée sur la couche de consensus. « [DAS] Dans une large mesure, il a des fonctionnalités qui feraient normalement partie d'un EIP, mais juste à cause de la façon dont nous avons structuré 4844, cela ne nécessite pas vraiment de hard fork ou d'EIP supplémentaire, et je pense que le risque qui en découle est que il n'y aura peut-être pas la même visibilité", a déclaré Dietrichs. Ryan a contesté ce commentaire, affirmant qu'à son avis, le DAS serait inclus dans l'EIP car le changement serait naturellement lié aux discussions sur la modification des limites de gaz de données d'Ethereum. Pour plus d'informations sur ce qu'est le DAS et comment il est implémenté sur d'autres blockchains telles que Celestia, lisez ce rapport de Galaxy Research.
Ryan a mentionné qu'il existe un PR préliminaire pour DAS et qu'un numéro EIP formel sera proposé dans les deux semaines. Ryan a encouragé les équipes de comptes participant à l'appel à réfléchir à quelles devraient être leurs priorités chez Electra lors du prochain appel ACDC le 25 janvier.