Auteur : Christine Kim, galaxie ; Traduction : Huohuo/Vernacular Blockchain
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 :
Surclassement 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 de la mise à niveau Cancun/Deneb)
Concernant l'EIP 4788**, les développeurs ont brièvement reconfirmé la nouvelle stratégie de déploiement pour les 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.
Au lieu de retarder la date de sortie de Devnet #9, les développeurs ont convenu de continuer 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. 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. " Ether Danny Ryan, membre de la Fondation Square 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 à l'idée de consacrer plus de temps à tester les modifications de l'EIP 4788 sur Devnet #8 et plus tard 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 la dernière branche de Goerli avant que Goerli 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 Ethereum, et Deneb est le nom de la mise à niveau de la couche de protocole. Par conséquent, la mise à niveau de Cancun combinée avec la mise à niveau de Deneb est connue sous le nom de mise à niveau de 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 susmentionné 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. Les développeurs définiront ultérieurement une valeur pour l'activation de Dencun sur le Holesky au lieu d'écraser la valeur existante. Busa a également soulevé la question de tester la cible/maximum de 3/6 blob au lieu de la limite de 2/4. **Sur ce sujet, Beiko a suggéré de soulever à nouveau la question lors de l'appel ACDC de la semaine prochaine, Ryan mentionnant que les expériences récentes avec des blocs de grande taille apporteront 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, **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 d'un 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é pendant une certaine période (par exemple 365 jours). Andrew Ashikhmin de l'équipe de compte d'Erigon (EL) était favorable au regroupement des deux mises à niveau, en supposant que la conversion de Verkle Trie serait grandement simplifiée si elle était combinée 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 ne retarde Verkle Tries, car l'expiration de l'état en tant que sujet de recherche a été « abandonnée » au cours des deux dernières années.
Buterin a donné davantage de détails sur les motivations de sa proposition, en déclarant : « Avec [Verkle] Le processus de transition, le problème consiste essentiellement à convertir plus de 50 Go de Merkle Patricia Trie en... 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, sa complexité rivalise avec celle des fusions. "
Buterin a poursuivi en expliquant comment l'expiration de l'État réduit considérablement la complexité de la transition vers Verkle. Cependant, il a également mentionné qu'il existe des conditions préalables complexes à l'expiration de l'état, 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 sera réduite, les développeurs ont toujours besoin pour résoudre le casse-tête de faire les deux. 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 effectuer la transition, ou attendre quelques années avant que Verkle Then State Expiry ne soit introduit. Les développeurs n'étaient pas clairs sur la valeur supplémentaire qui résulterait du regroupement des deux mises à niveau et ont 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 façon de mettre à jour la sérialisation des données Ethereum en utilisant un format basé sur SSZ « PartialContainer ». Kissling a écrit dans des commentaires sous l'ordre du jour de la conférence téléphonique de cette semaine, "Ce [format] combine essentiellement tous les avantages du [format précédent] et peut également être réutilisé à d'autres fins, éliminant actuellement les types facultatifs SSZ Union et SSZ 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 tous les aspects de la couche consensus, à l'exception du protocole de découverte des pairs. Sérialisation récursive du préfixe de longueur utilisée au niveau de la couche d'exécution. Simple les conceptions de sérialisation sont déterministes et peuvent également être efficacement merkleisées.)
Après la mise à jour, Beiko n'a pas tardé à faire l'éloge de la nouvelle implémentation de référence 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 une implémentation de référence Python des composants principaux du client d'exécution Ethereum, axée sur la lisibilité et la clarté. Conçu pour être un successeur spirituel du Yellow Papier, plus convivial pour les programmeurs et synchronisé avec les forks post-fusion, EELS peut remplir et exécuter des tests avec état, adhérer au réseau principal et constituer 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 dernière réunion de direction des principaux développeurs d'Ethereum
Auteur : Christine Kim, galaxie ; Traduction : Huohuo/Vernacular Blockchain
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 :
Surclassement 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 de la mise à niveau Cancun/Deneb)
Concernant l'EIP 4788**, les développeurs ont brièvement reconfirmé la nouvelle stratégie de déploiement pour les 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.
Au lieu de retarder la date de sortie de Devnet #9, les développeurs ont convenu de continuer 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. 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. " Ether Danny Ryan, membre de la Fondation Square 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 à l'idée de consacrer plus de temps à tester les modifications de l'EIP 4788 sur Devnet #8 et plus tard 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 la dernière branche de Goerli avant que Goerli 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 Ethereum, et Deneb est le nom de la mise à niveau de la couche de protocole. Par conséquent, la mise à niveau de Cancun combinée avec la mise à niveau de Deneb est connue sous le nom de mise à niveau de 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 susmentionné 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. Les développeurs définiront ultérieurement une valeur pour l'activation de Dencun sur le Holesky au lieu d'écraser la valeur existante. Busa a également soulevé la question de tester la cible/maximum de 3/6 blob au lieu de la limite de 2/4. **Sur ce sujet, Beiko a suggéré de soulever à nouveau la question lors de l'appel ACDC de la semaine prochaine, Ryan mentionnant que les expériences récentes avec des blocs de grande taille apporteront 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, **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 d'un 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é pendant une certaine période (par exemple 365 jours). Andrew Ashikhmin de l'équipe de compte d'Erigon (EL) était favorable au regroupement des deux mises à niveau, en supposant que la conversion de Verkle Trie serait grandement simplifiée si elle était combinée 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 ne retarde Verkle Tries, car l'expiration de l'état en tant que sujet de recherche a été « abandonnée » au cours des deux dernières années.
Buterin a donné davantage de détails sur les motivations de sa proposition, en déclarant : « Avec [Verkle] Le processus de transition, le problème consiste essentiellement à convertir plus de 50 Go de Merkle Patricia Trie en... 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, sa complexité rivalise avec celle des fusions. "
Buterin a poursuivi en expliquant comment l'expiration de l'État réduit considérablement la complexité de la transition vers Verkle. Cependant, il a également mentionné qu'il existe des conditions préalables complexes à l'expiration de l'état, 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 sera réduite, les développeurs ont toujours besoin pour résoudre le casse-tête de faire les deux. 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 effectuer la transition, ou attendre quelques années avant que Verkle Then State Expiry ne soit introduit. Les développeurs n'étaient pas clairs sur la valeur supplémentaire qui résulterait du regroupement des deux mises à niveau et ont 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 façon de mettre à jour la sérialisation des données Ethereum en utilisant un format basé sur SSZ « PartialContainer ». Kissling a écrit dans des commentaires sous l'ordre du jour de la conférence téléphonique de cette semaine, "Ce [format] combine essentiellement tous les avantages du [format précédent] et peut également être réutilisé à d'autres fins, éliminant actuellement les types facultatifs SSZ Union et SSZ 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 tous les aspects de la couche consensus, à l'exception du protocole de découverte des pairs. Sérialisation récursive du préfixe de longueur utilisée au niveau de la couche d'exécution. Simple les conceptions de sérialisation sont déterministes et peuvent également être efficacement merkleisées.)
Après la mise à jour, Beiko n'a pas tardé à faire l'éloge de la nouvelle implémentation de référence 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 une implémentation de référence Python des composants principaux du client d'exécution Ethereum, axée sur la lisibilité et la clarté. Conçu pour être un successeur spirituel du Yellow Papier, plus convivial pour les programmeurs et synchronisé avec les forks post-fusion, EELS peut remplir et exécuter des tests avec état, adhérer au réseau principal et constituer 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.