Le 31 août, les développeurs d'Ethereum se sont réunis sur Zoom pour la conférence téléphonique Core Developers (ACDE). Modérée par Tim Beiko de la Fondation Ethereum, la conférence téléphonique ACDE est une série bihebdomadaire au cours de laquelle l'équipe client Ethereum discute et coordonne les modifications apportées à la couche d'exécution (EL) d'Ethereum. Cette semaine, les développeurs ont discuté des progrès du développement et des tests sur :
Mise à niveau de Cancun/Deneb (Dencun)
Conversion rapide du Trie
Mise à jour de la sérialisation SSZ
1. Surclassement à Cancún
Devnet #8 a été lancé il y a deux semaines, le 16 août. Barnabas Busa, ingénieur DevOps à la Fondation Ethereum, a déclaré que le réseau de test de mise à niveau de Cancun, axé sur les développeurs, semble bien fonctionner. Busa a mentionné qu'il semble y avoir des problèmes avec les nœuds exécutant le logiciel client Nethermind (EL). Lukasz Rozmej, développeur du client Nethermind, a expliqué que la nature du problème était due à une mauvaise configuration dans l'implémentation du pool de transactions Blob. (Note du traducteur : Devnet 8 est le premier réseau de test dédié qui contient tous les EIP finalisés pour la mise à niveau de Cancun/Deneb)
Concernant l'EIP 4788, les développeurs ont brièvement réaffirmé la nouvelle stratégie de déploiement des modifications de code. Les contrats qui exposent les données de la chaîne de balises sur EL seront déployés comme des contrats intelligents classiques, qui nécessitent que quelqu'un finance l'adresse du contrat avant que la mise à niveau ne soit activée. Devnet #9, le prochain testnet pour la mise à niveau de Cancun, adoptera ce flux de travail et garantira que les développeurs le connaissent.
Plutôt que de retarder la date de sortie de Devnet #9, les développeurs ont convenu de poursuivre les tests sur Devnet #8 jusqu'à ce que tous les problèmes liés à l'implémentation du client soient résolus. "Je préfère avoir confiance dans Devnet #9 plutôt que de dire que nous espérons que ces choses fonctionneront. ... Je préfère résoudre les problèmes que nous connaissons. Sinon, si nous avons des problèmes difficiles dans Devnet #9, alors nous le ferons certainement. " Nous devrions avoir à nouveau Devnet #10, je ne dis pas que nous ne devrions pas avoir Devnet #10. Nous devrions avoir un nombre significatif de Devnets. Je pense que maintenant nous pouvons essayer de rendre Devnet #9 vraiment fiable. ", a déclaré Ether Danny Ryan, collègue à la Fondation Fang et président de la conférence téléphonique de l'ACDC.
D'autres participants à l'appel, dont Tim Beiko, Marius Van Der Wijden et Justin Florentine, étaient favorables à passer plus de temps à tester sur Devnet #8 et à tester plus tard les modifications de l'EIP 4788 sur Devnet #9. Beiko a suggéré aux développeurs un moment pour réunir à nouveau Devnet #9 lors de la prochaine conférence téléphonique de l'ACDE. Concernant les stratégies de déploiement testnet, Beiko recommande la séquence suivante :
Devnet #9 : Un autre Devnet dont la spécification Dencun a été gelée. Testez le réseau et supposez que les développeurs en sont satisfaits, puis passez à un réseau de test public. Sinon, démarrez Devnet #10.
Holesky : lancez le testnet Holeksy récemment lancé et déployez la mise à niveau Dencun dessus.
Goerli : déployez ensuite Dencun sur Goerli. En tant qu'avant-dernier lancement du réseau de test avant le réseau principal, les spécifications de mise à niveau à ce stade devraient être définitives et donner aux utilisateurs et aux applications suffisamment de temps pour tester leur logiciel avant que la mise à niveau du réseau principal ne soit activée. Dencun sera probablement le dernier fork de Goerli avant qu'il ne soit obsolète et remplacé par Holesky. (Note du traducteur : le mot Dencun est un mot composé composé de Cancun (Cancun) et Deneb. Cancun est le nom de cette mise à niveau de la couche d'exécution d'Ethereum, et Deneb est le nom de la mise à niveau de la couche de protocole. Par conséquent, la mise à niveau de Cancun est liée à Deneb (les mises à niveau sont collectivement appelées mises à niveau Dencun.)
Sepolia : Enfin, déployez Dencun sur Sepolia pour obtenir de bons résultats.
Personne ne s'est opposé à la proposition de Beiko de publier un testnet après Devnet #9. Beiko a mentionné que le calendrier ci-dessus sera partagé avec la communauté Ethereum au sens large dans un article de blog une fois que le testnet Holesky sera officiellement lancé le 15 septembre. En outre, Beiko a déclaré qu'il existe également un réseau de test appelé Ephemery en cours de développement. Ehemery est un réseau de test Ethereum pour les opérateurs de validation qui revient à l'état de genèse après une semaine ou deux. Pour plus d'informations sur le réseau Ephemery, lisez la page GitHub du projet ici.
Avant de discuter de Verkle Tries, Busa a mis en évidence une demande d'extraction (PR) ouverte sur GitHub pour le testnet Holesky. A la demande de l'équipe d'Erigon (EL), le PR propose de supprimer l'heure d'activation spécifique de la mise à niveau Dencun sur Holesky. Le développeur définira ultérieurement une valeur pour l'activation de Dencun sur Holesky plutôt que d'écraser la valeur existante. Busa a également demandé s'il était possible de tester la cible/maximum de 3/6 blob au lieu de la limite de 2/4. À ce sujet, Beiko a suggéré que la question soit soulevée à nouveau lors de l'appel ACDC de la semaine prochaine, où Ryan a mentionné que les expériences récentes avec des blocs de grande taille apporteraient de nouvelles informations.
2. Conversion de Verkle Trie
Ensuite, les développeurs ont discuté de la proposition de Vitalik Buterin de combiner les feuilles de route Verkle Trie et State Expiry pour réduire la complexité de la mise en œuvre de Verkle Trie et accélérer les avantages de State Expiry sur Ethereum. En arrière-plan, un Verkle Trie ou Verkle Tree est une structure de données qui permet aux utilisateurs de vérifier facilement de grandes quantités de données en s'appuyant sur une seule preuve cryptographique. Ils ne sont pas différents de Merkle Patricia Trie (MPT), qui est une structure de données utilisée pour stocker l'état d'Ethereum. Cependant, l'efficacité de preuve des arbres Verkle est relativement supérieure à celle de MPT, c'est pourquoi les développeurs ont travaillé sur la transition de MPT vers Verkle.
L'expiration de l'État est une initiative distincte conçue pour résoudre le problème de la croissance illimitée de l'État. L’objectif de l’expiration de l’état est de réduire la taille de l’état de plus de 100 Go à moins de 50 Go en supprimant les parties de l’état Ethereum auxquelles l’utilisateur n’a pas accédé au cours d’une certaine période de temps (par exemple 365 jours). Andrew Ashikhmin de l'équipe du compte Erigon (EL) était favorable au regroupement des deux mises à niveau, en supposant que les conversions Verkle Trie seraient grandement simplifiées si elles étaient combinées avec l'expiration de l'État. Guillaume Ballet de l'équipe client Geth (EL), qui a dirigé le projet Verkle Trie, craint que le couplage retarde Verkle Tries depuis l'expiration de l'État, car un sujet de recherche a été « abandonné » au cours des deux dernières années.
Buterin a ajouté davantage d'informations sur les motivations de sa proposition, en déclarant : « Avec [Verkle] Le processus de transition, le problème est essentiellement de convertir un Merkle Patricia Trie de plus de 50 Go en un... Verkle Trie dans un réseau en direct est tout simplement assez compliqué. C’est en effet un problème avec lequel l’équipe de recherche se débat depuis plus d’un an. Je me souviens de l'année dernière à Devconnect, c'était essentiellement le sujet d'un événement de recherche et autant de travaux de R&D que tout le reste de la feuille de route de Verkle mis en place, juste le processus permettant de réaliser cette dernière transition. À certains égards, cela rivalise en complexité avec la fusion. "
Buterin a expliqué comment l'expiration de l'État a considérablement réduit la complexité de la transition vers Verkle. Cependant, il a également mentionné que l'expiration de l'état a des conditions préalables complexes, telles que la nécessité d'ajouter plus d'espace d'adressage pour prendre en charge de nouvelles « périodes d'adressage » chaque année. Ainsi, même si la complexité de la mise en œuvre de Verkle diminuera, les développeurs ont encore besoin de résoudre le casse-tête pour faire les deux simultanément. De plus, si Verkle Tries est implémenté avant l'expiration de l'état, l'expiration de l'état sera moins urgente, les développeurs devraient donc envisager d'utiliser Verkle pour la transition, ou attendre quelques années que l'expiration de l'état soit introduite après Verkle. ignorant la valeur ajoutée du regroupement des deux mises à niveau, et a accepté de continuer à discuter du sujet de manière asynchrone sur Discord et l'appel des développeurs de Verkle Trie.
3. Sérialisation SSZ
Ensuite, Etan Kissling, développeur du client Nimbus (CL), a présenté ses dernières avancées dans la mise à niveau des structures de données Ethereum vers le format de sérialisation SSZ. Pour plus d’informations sur ce problème, lisez la transcription d’un précédent appel de développeur Ethereum ici. Kissling a mis en évidence une nouvelle approche pour mettre à jour la sérialisation des données Ethereum à l'aide d'un format basé sur SSZ « PartialContainer ». Dans des commentaires sous l'ordre du jour de la conférence téléphonique de cette semaine, Kissling a écrit : « Ce [format] combine essentiellement tous les avantages du [format précédent] et peut également être réutilisé à d'autres fins, éliminant ainsi progressivement l'Union SSZ et le type facultatif SSZ actuellement inutilisés. " (Note du traducteur : la sérialisation simple (SSZ) est la méthode de sérialisation utilisée sur la chaîne de balises. Cette méthode remplace la couche d'implémentation utilisée partout dans la couche consensus, à l'exception du protocole de découverte par les pairs. Sérialisation récursive avec préfixe de longueur. La sérialisation simple est déterministe par conception et peut également être efficacement merkleisé.)
Après la mise à jour, Beiko n'a pas tardé à faire l'éloge de la nouvelle implémentation de référence d'EL en Python (appelée EELS). Dans un récent article de blog de la Fondation Ethereum, Sam Wilson, rédacteur en chef de l'EIP et chercheur de la Fondation Ethereum, a écrit : « EELS est l'implémentation de référence Python des composants principaux du client d'exécution Ethereum, en mettant l'accent sur la lisibilité et la clarté. EELS vise à être un successeur spirituel. Conformément au Livre jaune, plus convivial pour les programmeurs et synchronisé avec les forks post-fusion, EELS peut remplir et exécuter des tests d'état, suivre le réseau principal et constitue un endroit idéal pour prototyper de nouveaux EIP.
Certains développeurs utilisent déjà EELS pour réimplémenter leurs EIP, et la Fondation Ethereum offre une subvention à toute personne intéressée par la mise à jour du livre jaune afin d'inclure les mises à niveau de réseau pré-fusionnées manquantes comme Londres et Paris pour compléter EELS.
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 116e réunion des dirigeants des développeurs principaux d'Ethereum : mise à niveau de Cancun, conversion Verkle Trie et sérialisation SSZ
Auteur : Christine Kim / Source :
Traduction : Huohuo/Blockchain vernaculaire
Le 31 août, les développeurs d'Ethereum se sont réunis sur Zoom pour la conférence téléphonique Core Developers (ACDE). Modérée par Tim Beiko de la Fondation Ethereum, la conférence téléphonique ACDE est une série bihebdomadaire au cours de laquelle l'équipe client Ethereum discute et coordonne les modifications apportées à la couche d'exécution (EL) d'Ethereum. Cette semaine, les développeurs ont discuté des progrès du développement et des tests sur :
Mise à niveau de Cancun/Deneb (Dencun)
Conversion rapide du Trie
Mise à jour de la sérialisation SSZ
1. Surclassement à Cancún
Devnet #8 a été lancé il y a deux semaines, le 16 août. Barnabas Busa, ingénieur DevOps à la Fondation Ethereum, a déclaré que le réseau de test de mise à niveau de Cancun, axé sur les développeurs, semble bien fonctionner. Busa a mentionné qu'il semble y avoir des problèmes avec les nœuds exécutant le logiciel client Nethermind (EL). Lukasz Rozmej, développeur du client Nethermind, a expliqué que la nature du problème était due à une mauvaise configuration dans l'implémentation du pool de transactions Blob. (Note du traducteur : Devnet 8 est le premier réseau de test dédié qui contient tous les EIP finalisés pour la mise à niveau de Cancun/Deneb)
Concernant l'EIP 4788, les développeurs ont brièvement réaffirmé la nouvelle stratégie de déploiement des modifications de code. Les contrats qui exposent les données de la chaîne de balises sur EL seront déployés comme des contrats intelligents classiques, qui nécessitent que quelqu'un finance l'adresse du contrat avant que la mise à niveau ne soit activée. Devnet #9, le prochain testnet pour la mise à niveau de Cancun, adoptera ce flux de travail et garantira que les développeurs le connaissent.
Plutôt que de retarder la date de sortie de Devnet #9, les développeurs ont convenu de poursuivre les tests sur Devnet #8 jusqu'à ce que tous les problèmes liés à l'implémentation du client soient résolus. "Je préfère avoir confiance dans Devnet #9 plutôt que de dire que nous espérons que ces choses fonctionneront. ... Je préfère résoudre les problèmes que nous connaissons. Sinon, si nous avons des problèmes difficiles dans Devnet #9, alors nous le ferons certainement. " Nous devrions avoir à nouveau Devnet #10, je ne dis pas que nous ne devrions pas avoir Devnet #10. Nous devrions avoir un nombre significatif de Devnets. Je pense que maintenant nous pouvons essayer de rendre Devnet #9 vraiment fiable. ", a déclaré Ether Danny Ryan, collègue à la Fondation Fang et président de la conférence téléphonique de l'ACDC.
D'autres participants à l'appel, dont Tim Beiko, Marius Van Der Wijden et Justin Florentine, étaient favorables à passer plus de temps à tester sur Devnet #8 et à tester plus tard les modifications de l'EIP 4788 sur Devnet #9. Beiko a suggéré aux développeurs un moment pour réunir à nouveau Devnet #9 lors de la prochaine conférence téléphonique de l'ACDE. Concernant les stratégies de déploiement testnet, Beiko recommande la séquence suivante :
Devnet #9 : Un autre Devnet dont la spécification Dencun a été gelée. Testez le réseau et supposez que les développeurs en sont satisfaits, puis passez à un réseau de test public. Sinon, démarrez Devnet #10.
Holesky : lancez le testnet Holeksy récemment lancé et déployez la mise à niveau Dencun dessus.
Goerli : déployez ensuite Dencun sur Goerli. En tant qu'avant-dernier lancement du réseau de test avant le réseau principal, les spécifications de mise à niveau à ce stade devraient être définitives et donner aux utilisateurs et aux applications suffisamment de temps pour tester leur logiciel avant que la mise à niveau du réseau principal ne soit activée. Dencun sera probablement le dernier fork de Goerli avant qu'il ne soit obsolète et remplacé par Holesky. (Note du traducteur : le mot Dencun est un mot composé composé de Cancun (Cancun) et Deneb. Cancun est le nom de cette mise à niveau de la couche d'exécution d'Ethereum, et Deneb est le nom de la mise à niveau de la couche de protocole. Par conséquent, la mise à niveau de Cancun est liée à Deneb (les mises à niveau sont collectivement appelées mises à niveau Dencun.)
Sepolia : Enfin, déployez Dencun sur Sepolia pour obtenir de bons résultats.
Personne ne s'est opposé à la proposition de Beiko de publier un testnet après Devnet #9. Beiko a mentionné que le calendrier ci-dessus sera partagé avec la communauté Ethereum au sens large dans un article de blog une fois que le testnet Holesky sera officiellement lancé le 15 septembre. En outre, Beiko a déclaré qu'il existe également un réseau de test appelé Ephemery en cours de développement. Ehemery est un réseau de test Ethereum pour les opérateurs de validation qui revient à l'état de genèse après une semaine ou deux. Pour plus d'informations sur le réseau Ephemery, lisez la page GitHub du projet ici.
Avant de discuter de Verkle Tries, Busa a mis en évidence une demande d'extraction (PR) ouverte sur GitHub pour le testnet Holesky. A la demande de l'équipe d'Erigon (EL), le PR propose de supprimer l'heure d'activation spécifique de la mise à niveau Dencun sur Holesky. Le développeur définira ultérieurement une valeur pour l'activation de Dencun sur Holesky plutôt que d'écraser la valeur existante. Busa a également demandé s'il était possible de tester la cible/maximum de 3/6 blob au lieu de la limite de 2/4. À ce sujet, Beiko a suggéré que la question soit soulevée à nouveau lors de l'appel ACDC de la semaine prochaine, où Ryan a mentionné que les expériences récentes avec des blocs de grande taille apporteraient de nouvelles informations.
2. Conversion de Verkle Trie
Ensuite, les développeurs ont discuté de la proposition de Vitalik Buterin de combiner les feuilles de route Verkle Trie et State Expiry pour réduire la complexité de la mise en œuvre de Verkle Trie et accélérer les avantages de State Expiry sur Ethereum. En arrière-plan, un Verkle Trie ou Verkle Tree est une structure de données qui permet aux utilisateurs de vérifier facilement de grandes quantités de données en s'appuyant sur une seule preuve cryptographique. Ils ne sont pas différents de Merkle Patricia Trie (MPT), qui est une structure de données utilisée pour stocker l'état d'Ethereum. Cependant, l'efficacité de preuve des arbres Verkle est relativement supérieure à celle de MPT, c'est pourquoi les développeurs ont travaillé sur la transition de MPT vers Verkle.
L'expiration de l'État est une initiative distincte conçue pour résoudre le problème de la croissance illimitée de l'État. L’objectif de l’expiration de l’état est de réduire la taille de l’état de plus de 100 Go à moins de 50 Go en supprimant les parties de l’état Ethereum auxquelles l’utilisateur n’a pas accédé au cours d’une certaine période de temps (par exemple 365 jours). Andrew Ashikhmin de l'équipe du compte Erigon (EL) était favorable au regroupement des deux mises à niveau, en supposant que les conversions Verkle Trie seraient grandement simplifiées si elles étaient combinées avec l'expiration de l'État. Guillaume Ballet de l'équipe client Geth (EL), qui a dirigé le projet Verkle Trie, craint que le couplage retarde Verkle Tries depuis l'expiration de l'État, car un sujet de recherche a été « abandonné » au cours des deux dernières années.
Buterin a ajouté davantage d'informations sur les motivations de sa proposition, en déclarant : « Avec [Verkle] Le processus de transition, le problème est essentiellement de convertir un Merkle Patricia Trie de plus de 50 Go en un... Verkle Trie dans un réseau en direct est tout simplement assez compliqué. C’est en effet un problème avec lequel l’équipe de recherche se débat depuis plus d’un an. Je me souviens de l'année dernière à Devconnect, c'était essentiellement le sujet d'un événement de recherche et autant de travaux de R&D que tout le reste de la feuille de route de Verkle mis en place, juste le processus permettant de réaliser cette dernière transition. À certains égards, cela rivalise en complexité avec la fusion. "
Buterin a expliqué comment l'expiration de l'État a considérablement réduit la complexité de la transition vers Verkle. Cependant, il a également mentionné que l'expiration de l'état a des conditions préalables complexes, telles que la nécessité d'ajouter plus d'espace d'adressage pour prendre en charge de nouvelles « périodes d'adressage » chaque année. Ainsi, même si la complexité de la mise en œuvre de Verkle diminuera, les développeurs ont encore besoin de résoudre le casse-tête pour faire les deux simultanément. De plus, si Verkle Tries est implémenté avant l'expiration de l'état, l'expiration de l'état sera moins urgente, les développeurs devraient donc envisager d'utiliser Verkle pour la transition, ou attendre quelques années que l'expiration de l'état soit introduite après Verkle. ignorant la valeur ajoutée du regroupement des deux mises à niveau, et a accepté de continuer à discuter du sujet de manière asynchrone sur Discord et l'appel des développeurs de Verkle Trie.
3. Sérialisation SSZ
Ensuite, Etan Kissling, développeur du client Nimbus (CL), a présenté ses dernières avancées dans la mise à niveau des structures de données Ethereum vers le format de sérialisation SSZ. Pour plus d’informations sur ce problème, lisez la transcription d’un précédent appel de développeur Ethereum ici. Kissling a mis en évidence une nouvelle approche pour mettre à jour la sérialisation des données Ethereum à l'aide d'un format basé sur SSZ « PartialContainer ». Dans des commentaires sous l'ordre du jour de la conférence téléphonique de cette semaine, Kissling a écrit : « Ce [format] combine essentiellement tous les avantages du [format précédent] et peut également être réutilisé à d'autres fins, éliminant ainsi progressivement l'Union SSZ et le type facultatif SSZ actuellement inutilisés. " (Note du traducteur : la sérialisation simple (SSZ) est la méthode de sérialisation utilisée sur la chaîne de balises. Cette méthode remplace la couche d'implémentation utilisée partout dans la couche consensus, à l'exception du protocole de découverte par les pairs. Sérialisation récursive avec préfixe de longueur. La sérialisation simple est déterministe par conception et peut également être efficacement merkleisé.)
Après la mise à jour, Beiko n'a pas tardé à faire l'éloge de la nouvelle implémentation de référence d'EL en Python (appelée EELS). Dans un récent article de blog de la Fondation Ethereum, Sam Wilson, rédacteur en chef de l'EIP et chercheur de la Fondation Ethereum, a écrit : « EELS est l'implémentation de référence Python des composants principaux du client d'exécution Ethereum, en mettant l'accent sur la lisibilité et la clarté. EELS vise à être un successeur spirituel. Conformément au Livre jaune, plus convivial pour les programmeurs et synchronisé avec les forks post-fusion, EELS peut remplir et exécuter des tests d'état, suivre le réseau principal et constitue un endroit idéal pour prototyper de nouveaux EIP.
Certains développeurs utilisent déjà EELS pour réimplémenter leurs EIP, et la Fondation Ethereum offre une subvention à toute personne intéressée par la mise à jour du livre jaune afin d'inclure les mises à niveau de réseau pré-fusionnées manquantes comme Londres et Paris pour compléter EELS.