Une autre réunion @ethereum #AllCoreDevs s'est terminée le 15 septembre : les mises à jour du réseau de développement, les ajouts à Dencun et un aperçu complet de Reth ont été discutés !
Ordre du jour : Lien en direct :
Vous trouverez ci-dessous un résumé de la réunion par @TimBeiko.
1. Mise à jour du statut Devnet-8
Tout d'abord, une mise à jour de l'état de devnet-8 : le réseau est en cours de développement final et de nombreux clients y ont déjà envoyé de nouvelles mises à jour. En attendant, nous avons commencé à tester le processus de construction MEV/bloc en utilisant @KurtosisTech. @NethermindEth a déclaré que leur pool de transactions blob est maintenant prêt et qu'après quelques jours de tests sur un seul nœud, ils l'ont déployé sur tous les nœuds de test Dencun.
Le pool de transactions blob de Geth est également presque terminé. Besu apporte d'importantes améliorations à son pool de transactions (en limitant la taille totale des transactions blob et non-blob) qui devraient être publiées dans sa prochaine version. Erigon continue d'améliorer son pool de transactions et espère être prêt pour Devnet-9. Prysm note également qu'il existe une certaine latence dans la réception des side-cars blob, qui, selon eux, arrivent généralement avec un délai d'environ 500 millisecondes après le bloc (alors que le traitement du bloc prend environ 15 millisecondes).
Ils étudient ce problème pour déterminer s'il peut être causé par une condition de concurrence entre les importations de blob et de fragments. Concernant la question de savoir s'il faut autoriser la prise en charge des transactions blob dans le pool de mémoire avant le hard fork, l'équipe a convenu à l'unanimité de ne pas le faire.
2、EIP-7514
Ensuite, nous avons poursuivi la discussion de l'appel ACDC de la semaine dernière sur l'opportunité d'ajouter un plafond constant à la file d'attente d'activation du validateur. Cette proposition a été officiellement formée sous le nom d'EIP-7514. En bref, dans le pire des cas, cela ralentira la croissance en pourcentage de la mise en jeu d’ETH. Dankrad a exprimé son soutien à la proposition lors de l'appel, affirmant que cela nous ferait gagner du temps pour apporter des modifications potentiellement plus complexes aux récompenses des validateurs.
Toutes les équipes du CL sont favorables à ce changement, avec la précision que cela ne s'applique qu'à la file d'attente des dépôts et non à la file d'attente des retraits. Après plus de discussions, nous avons décidé de fixer la limite à 8. Par conséquent, l'EIP-7514 fera partie de la mise à niveau de Dencun ! Il est prévu que dans les prochains jours, l'EIP et la spécification CL associée PR soient mis à jour pour refléter ce changement.
3. EVM et Blob
Ensuite, nous avons discuté d'une autre proposition provisoire : ajouter un opcode à la machine virtuelle Ethereum (EVM) pour exposer les frais de base des blob. Cette proposition a été avancée par @PlasmaPower0 d'Arbitrum, qui a déclaré sur le R&D Discord plus tôt cette semaine qu'elle leur serait utile (ainsi qu'à d'autres solutions de couche 2). Nous avons déjà un opcode similaire qui expose BASEFEE dans EIP-1559, qui a été introduit en même temps que l'activation d'EIP. Cela permet aux solutions de couche 2 de déterminer plus facilement le prix du gaz correct à facturer aux utilisateurs en fonction des coûts de données L1.
@protolambda d'Optimism a également assisté à la réunion et a suggéré que ce n'est pas le seul moyen d'obtenir les frais de base du blob pour L2, car ils peuvent consulter l'en-tête du bloc (qui contient les valeurs utilisées pour calculer les frais de base du blob) et Prouvez Merkle contre ces valeurs. Il reconnaît néanmoins que c'est une fonctionnalité intéressante. Arbitrum n'effectue actuellement pas d'analyse d'en-tête de bloc, et s'appuyer sur cela pourrait être problématique pour les solutions immuables de couche 2, car cela pourrait causer des problèmes si le format de l'en-tête de bloc finissait par changer.
L'un des auteurs de l'EIP-4844 @adietrichs a mentionné que cet opcode n'était pas inclus dans la spécification originale car il y avait un souhait de développer un moyen plus général d'accéder aux informations d'en-tête de bloc (plutôt que d'ajouter un opcode unique). Néanmoins, adopter ce changement plus ambitieux serait une tâche plus ambitieuse que d'introduire cet opcode.
Les informations exposées par cet opcode sont déjà ce dont le client EL a besoin pour calculer, et sémantiquement elles sont presque identiques à l'opcode BASEFEE. L'équipe client a convenu à l'unanimité que nous devrions ajouter cet opcode, ne serait-ce que pour être cohérent avec BASEFEE. Si à l'avenir nous proposons un mécanisme "plus fluide", toute fonctionnalité redondante dans ce nouvel opcode deviendra également un problème pour les autres opcodes qui utilisent les informations d'en-tête de bloc. En outre, il convient de souligner qu'il s'agit d'un très petit changement : @vdWijden l'a implémenté dans Geth avant l'existence d'EIP, et cela n'a pris que 20 minutes environ, et l'équipe de Reth a apporté un changement à ce sujet lors de l'appel PR de l'ACD.
4、EIP-4788
Ensuite, nous avons discuté de quelques mises à jour d'EIP-4788, une proposition visant à stocker les racines des balises dans les contrats sur la chaîne principale Ethereum. Au cours des dernières semaines, nous avons effectué plusieurs audits et tests fuzz du contrat, qui ont abouti à quelques modifications mineures décrites dans ce PR. Bien que tous les audits ne soient pas terminés et que les rapports ne soient pas encore publiés, @lightclients a donné un aperçu des changements envisagés jusqu'à présent. Le premier changement consiste à gérer explicitement les horodatages 0 afin qu'ils provoquent une restauration (tout comme les autres horodatages non valides) au lieu de renvoyer 0. Le deuxième changement concerne la taille du tampon. En supposant que les créneaux horaires changent, le contrat initial entraînera un gaspillage de stockage en raison du fonctionnement de l'arithmétique modulaire.
5. Optimisation du gaz
Enfin, il existe une optimisation du gaz qui réduit le nombre de chargements de CALLDATA. Les auditeurs examineront ces changements et nous espérons avoir leur rapport final avant la prochaine réunion de l'ACDE. Afin de poursuivre les tests de fuzz et le travail de mise en œuvre, nous avons convenu de fusionner les modifications proposées maintenant.
@shemnon a également mentionné que ces changements devraient être documentés dans l'EIP lui-même - nous y travaillons ! Ensuite, nous avons discuté de la manière dont les clients doivent gérer cela si l'adresse du contrat système fait partie de l'état mais est vide à la fin de l'exécution. Bien qu'il soit peu probable que cela se produise sur le réseau principal (d'après ce que j'ai compris !), il s'agit d'un cas limite qui s'est produit lors des tests en définissant l'adresse dans le bloc Genesis.
Étant donné qu'il s'agit d'un cas limite assez particulier et qu'il n'y a pas de comportement canonique clair, nous avons convenu de consacrer plus de temps à réfléchir à cette question et de poursuivre la discussion lors de la réunion test de la semaine prochaine. Tout dépend des changements de spécifications ! Tous les éléments ci-dessus devraient être inclus dans devnet-9. L'équipe client convient que tout devrait être implémenté et testé avant l'ACDC de la semaine prochaine. Lors de cet appel, nous nous mettrons d'accord sur une date de lancement pour devnet-9.
La prochaine ACDE devrait avoir lieu le 28 septembre à 14h00, heure UTC. D'ici là, suivez @terencechain pour les résumés des réunions tests, @benjaminion_xyz pour les informations sur les réunions ACDC et @christine_dkim pour une couverture plus détaillée de l'ensemble de l'événement.
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.
EIP-7514 fera partie de la mise à niveau d'Ethereum Dencun
Auteur : @TimBeiko Traduction : Huohuo/Vernacular Blockchain
Une autre réunion @ethereum #AllCoreDevs s'est terminée le 15 septembre : les mises à jour du réseau de développement, les ajouts à Dencun et un aperçu complet de Reth ont été discutés !
Ordre du jour : Lien en direct :
Vous trouverez ci-dessous un résumé de la réunion par @TimBeiko.
1. Mise à jour du statut Devnet-8
Tout d'abord, une mise à jour de l'état de devnet-8 : le réseau est en cours de développement final et de nombreux clients y ont déjà envoyé de nouvelles mises à jour. En attendant, nous avons commencé à tester le processus de construction MEV/bloc en utilisant @KurtosisTech. @NethermindEth a déclaré que leur pool de transactions blob est maintenant prêt et qu'après quelques jours de tests sur un seul nœud, ils l'ont déployé sur tous les nœuds de test Dencun.
Le pool de transactions blob de Geth est également presque terminé. Besu apporte d'importantes améliorations à son pool de transactions (en limitant la taille totale des transactions blob et non-blob) qui devraient être publiées dans sa prochaine version. Erigon continue d'améliorer son pool de transactions et espère être prêt pour Devnet-9. Prysm note également qu'il existe une certaine latence dans la réception des side-cars blob, qui, selon eux, arrivent généralement avec un délai d'environ 500 millisecondes après le bloc (alors que le traitement du bloc prend environ 15 millisecondes).
Ils étudient ce problème pour déterminer s'il peut être causé par une condition de concurrence entre les importations de blob et de fragments. Concernant la question de savoir s'il faut autoriser la prise en charge des transactions blob dans le pool de mémoire avant le hard fork, l'équipe a convenu à l'unanimité de ne pas le faire.
2、EIP-7514
Ensuite, nous avons poursuivi la discussion de l'appel ACDC de la semaine dernière sur l'opportunité d'ajouter un plafond constant à la file d'attente d'activation du validateur. Cette proposition a été officiellement formée sous le nom d'EIP-7514. En bref, dans le pire des cas, cela ralentira la croissance en pourcentage de la mise en jeu d’ETH. Dankrad a exprimé son soutien à la proposition lors de l'appel, affirmant que cela nous ferait gagner du temps pour apporter des modifications potentiellement plus complexes aux récompenses des validateurs.
Toutes les équipes du CL sont favorables à ce changement, avec la précision que cela ne s'applique qu'à la file d'attente des dépôts et non à la file d'attente des retraits. Après plus de discussions, nous avons décidé de fixer la limite à 8. Par conséquent, l'EIP-7514 fera partie de la mise à niveau de Dencun ! Il est prévu que dans les prochains jours, l'EIP et la spécification CL associée PR soient mis à jour pour refléter ce changement.
3. EVM et Blob
Ensuite, nous avons discuté d'une autre proposition provisoire : ajouter un opcode à la machine virtuelle Ethereum (EVM) pour exposer les frais de base des blob. Cette proposition a été avancée par @PlasmaPower0 d'Arbitrum, qui a déclaré sur le R&D Discord plus tôt cette semaine qu'elle leur serait utile (ainsi qu'à d'autres solutions de couche 2). Nous avons déjà un opcode similaire qui expose BASEFEE dans EIP-1559, qui a été introduit en même temps que l'activation d'EIP. Cela permet aux solutions de couche 2 de déterminer plus facilement le prix du gaz correct à facturer aux utilisateurs en fonction des coûts de données L1.
@protolambda d'Optimism a également assisté à la réunion et a suggéré que ce n'est pas le seul moyen d'obtenir les frais de base du blob pour L2, car ils peuvent consulter l'en-tête du bloc (qui contient les valeurs utilisées pour calculer les frais de base du blob) et Prouvez Merkle contre ces valeurs. Il reconnaît néanmoins que c'est une fonctionnalité intéressante. Arbitrum n'effectue actuellement pas d'analyse d'en-tête de bloc, et s'appuyer sur cela pourrait être problématique pour les solutions immuables de couche 2, car cela pourrait causer des problèmes si le format de l'en-tête de bloc finissait par changer.
L'un des auteurs de l'EIP-4844 @adietrichs a mentionné que cet opcode n'était pas inclus dans la spécification originale car il y avait un souhait de développer un moyen plus général d'accéder aux informations d'en-tête de bloc (plutôt que d'ajouter un opcode unique). Néanmoins, adopter ce changement plus ambitieux serait une tâche plus ambitieuse que d'introduire cet opcode.
Les informations exposées par cet opcode sont déjà ce dont le client EL a besoin pour calculer, et sémantiquement elles sont presque identiques à l'opcode BASEFEE. L'équipe client a convenu à l'unanimité que nous devrions ajouter cet opcode, ne serait-ce que pour être cohérent avec BASEFEE. Si à l'avenir nous proposons un mécanisme "plus fluide", toute fonctionnalité redondante dans ce nouvel opcode deviendra également un problème pour les autres opcodes qui utilisent les informations d'en-tête de bloc. En outre, il convient de souligner qu'il s'agit d'un très petit changement : @vdWijden l'a implémenté dans Geth avant l'existence d'EIP, et cela n'a pris que 20 minutes environ, et l'équipe de Reth a apporté un changement à ce sujet lors de l'appel PR de l'ACD.
4、EIP-4788
Ensuite, nous avons discuté de quelques mises à jour d'EIP-4788, une proposition visant à stocker les racines des balises dans les contrats sur la chaîne principale Ethereum. Au cours des dernières semaines, nous avons effectué plusieurs audits et tests fuzz du contrat, qui ont abouti à quelques modifications mineures décrites dans ce PR. Bien que tous les audits ne soient pas terminés et que les rapports ne soient pas encore publiés, @lightclients a donné un aperçu des changements envisagés jusqu'à présent. Le premier changement consiste à gérer explicitement les horodatages 0 afin qu'ils provoquent une restauration (tout comme les autres horodatages non valides) au lieu de renvoyer 0. Le deuxième changement concerne la taille du tampon. En supposant que les créneaux horaires changent, le contrat initial entraînera un gaspillage de stockage en raison du fonctionnement de l'arithmétique modulaire.
5. Optimisation du gaz
Enfin, il existe une optimisation du gaz qui réduit le nombre de chargements de CALLDATA. Les auditeurs examineront ces changements et nous espérons avoir leur rapport final avant la prochaine réunion de l'ACDE. Afin de poursuivre les tests de fuzz et le travail de mise en œuvre, nous avons convenu de fusionner les modifications proposées maintenant.
@shemnon a également mentionné que ces changements devraient être documentés dans l'EIP lui-même - nous y travaillons ! Ensuite, nous avons discuté de la manière dont les clients doivent gérer cela si l'adresse du contrat système fait partie de l'état mais est vide à la fin de l'exécution. Bien qu'il soit peu probable que cela se produise sur le réseau principal (d'après ce que j'ai compris !), il s'agit d'un cas limite qui s'est produit lors des tests en définissant l'adresse dans le bloc Genesis.
Étant donné qu'il s'agit d'un cas limite assez particulier et qu'il n'y a pas de comportement canonique clair, nous avons convenu de consacrer plus de temps à réfléchir à cette question et de poursuivre la discussion lors de la réunion test de la semaine prochaine. Tout dépend des changements de spécifications ! Tous les éléments ci-dessus devraient être inclus dans devnet-9. L'équipe client convient que tout devrait être implémenté et testé avant l'ACDC de la semaine prochaine. Lors de cet appel, nous nous mettrons d'accord sur une date de lancement pour devnet-9.
La prochaine ACDE devrait avoir lieu le 28 septembre à 14h00, heure UTC. D'ici là, suivez @terencechain pour les résumés des réunions tests, @benjaminion_xyz pour les informations sur les réunions ACDC et @christine_dkim pour une couverture plus détaillée de l'ensemble de l'événement.