Résumé de la 107e réunion de consensus des développeurs principaux d'Ethereum
Le 20 avril 2023, les développeurs Ethereum ont tenu la 107ème réunion téléphonique des développeurs principaux sur le consensus (ACDC). La réunion a été animée par un chercheur de la Fondation Ethereum, et a mis l'accent sur les modifications du niveau de consensus Ethereum (CL), les mises à jour des progrès de Deneb, ainsi que d'autres propositions lors de la prochaine mise à niveau de Cancun, à l'exception de l'EIP-4844.
Deneb测试网#5
Depuis l'activation réussie de la mise à niveau de Shanghai, les développeurs ont rapidement tourné leur attention vers les préparatifs de Cancun. Cancun est la prochaine mise à niveau de la couche d'exécution d'Ethereum (EL), tandis que Deneb est la mise à niveau correspondante de la couche de consensus. Pendant la réunion, les développeurs ont discuté de l'étendue finale de la mise à niveau Cancun/Deneb, qui sera centrée sur l'EIP-4844, mettant en œuvre le type de transaction blob.
Les préparatifs de Deneb ont commencé avec le lancement du testnet #5. Les développeurs prévoient de lancer le cinquième testnet de l'EIP-4844 la semaine prochaine. Les ingénieurs DevOps d'une fondation effectuent des tests pour plusieurs clients en vue de la publication du testnet de la semaine prochaine.
L'API du moteur a un petit changement, fusionnant les appels "getPayloadV3" et "getBlobsBundleV1" en un seul. Ce changement n'a pas encore été intégré dans la spécification EIP-4844, mais sera terminé dans les prochains jours pour être testé sur le testnet #5.
Les développeurs ont également discuté de la manière de réinsérer les transactions blob dans les blocs lors de la réorganisation de la chaîne. Étant donné que les transactions blob sont séparées des transactions ordinaires, les blobs réorganisés ne peuvent être obtenus que parmi les transactions de la mémoire publique. Étant donné que de nombreuses transactions contournent la mémoire, une solution consiste à permettre à CL de transmettre les données blob de chaque bloc à EL, puis EL peut les mettre en cache jusqu'à ce que le bloc soit complété. Une autre méthode consiste à demander aux utilisateurs soumettant des transactions contournant la mémoire de soumettre à nouveau leurs transactions lors d'un événement de réorganisation de la chaîne.
Un développeur a déclaré qu'il préférait transférer les données blob vers l'EL afin de pouvoir réinsérer les transactions lors de la reconstruction. Il pense que cela n'ajoute pas une charge importante à l'EL et que si ce processus devient compliqué, il est possible d'ajuster les messages entre l'EL et le CL pour alléger la charge.
Cependant, certains ont souligné que cette solution pourrait nuire davantage à l'abstraction entre les couches EL et CL, et pourrait entrer en conflit avec la mise en œuvre future de l'échantillonnage de disponibilité des données (DAS).
Proposition supplémentaire Deneb
En plus de l'EIP-4844, la mise à niveau Deneb a également pris en compte d'autres mises à niveau du code :
EIP-4788 : Publier l'état de la chaîne Beacon CL dans l'EL, permettant aux contrats intelligents d'accéder à la CL avec un minimum de confiance.
EIP-6914 : Réutilisation des numéros d'index des validateurs qui ont complètement quitté le réseau et qui n'ont pas été actifs depuis longtemps, ce qui aide à réduire la croissance infinie de la liste des validateurs.
Un changement de code potentiel, impliquant le remplissage de données à partir du bloc génésique de la chaîne Beacon et la création d'un nouveau contenu de "résumé historique".
PR 3175 : empêcher les validateurs punis de proposer des blocs lors de leur sortie de la file d'attente, fournissant une protection contre le "mode de défaillance élevé".
EIP-6493 : Résoudre comment les nœuds traitent les types de transactions blob formatés en SSZ sur le CL mais encodés différemment sur l'EL.
Les développeurs ont tendance à inclure EIP-4788, EIP-3175 et EIP-4844 dans la prochaine mise à niveau.
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.
13 J'aime
Récompense
13
3
Reposter
Partager
Commentaire
0/400
GasFeeLover
· 08-14 21:13
Ce rythme de mise à niveau est trop rapide, non ? tant que les gasfees ne augmentent pas.
Voir l'originalRépondre0
ImpermanentTherapist
· 08-14 21:02
Ha, enfin on va faire 4844, cette fois L2 va To the moon.
Voir l'originalRépondre0
UnluckyMiner
· 08-14 20:54
Cette mise à jour est vraiment trop fréquente, le Mining va être catastrophique.
La conférence des développeurs Ethereum se concentre sur la mise à niveau de Cancun, EIP-4844 étant la proposition centrale.
Résumé de la 107e réunion de consensus des développeurs principaux d'Ethereum
Le 20 avril 2023, les développeurs Ethereum ont tenu la 107ème réunion téléphonique des développeurs principaux sur le consensus (ACDC). La réunion a été animée par un chercheur de la Fondation Ethereum, et a mis l'accent sur les modifications du niveau de consensus Ethereum (CL), les mises à jour des progrès de Deneb, ainsi que d'autres propositions lors de la prochaine mise à niveau de Cancun, à l'exception de l'EIP-4844.
Deneb测试网#5
Depuis l'activation réussie de la mise à niveau de Shanghai, les développeurs ont rapidement tourné leur attention vers les préparatifs de Cancun. Cancun est la prochaine mise à niveau de la couche d'exécution d'Ethereum (EL), tandis que Deneb est la mise à niveau correspondante de la couche de consensus. Pendant la réunion, les développeurs ont discuté de l'étendue finale de la mise à niveau Cancun/Deneb, qui sera centrée sur l'EIP-4844, mettant en œuvre le type de transaction blob.
Les préparatifs de Deneb ont commencé avec le lancement du testnet #5. Les développeurs prévoient de lancer le cinquième testnet de l'EIP-4844 la semaine prochaine. Les ingénieurs DevOps d'une fondation effectuent des tests pour plusieurs clients en vue de la publication du testnet de la semaine prochaine.
L'API du moteur a un petit changement, fusionnant les appels "getPayloadV3" et "getBlobsBundleV1" en un seul. Ce changement n'a pas encore été intégré dans la spécification EIP-4844, mais sera terminé dans les prochains jours pour être testé sur le testnet #5.
Les développeurs ont également discuté de la manière de réinsérer les transactions blob dans les blocs lors de la réorganisation de la chaîne. Étant donné que les transactions blob sont séparées des transactions ordinaires, les blobs réorganisés ne peuvent être obtenus que parmi les transactions de la mémoire publique. Étant donné que de nombreuses transactions contournent la mémoire, une solution consiste à permettre à CL de transmettre les données blob de chaque bloc à EL, puis EL peut les mettre en cache jusqu'à ce que le bloc soit complété. Une autre méthode consiste à demander aux utilisateurs soumettant des transactions contournant la mémoire de soumettre à nouveau leurs transactions lors d'un événement de réorganisation de la chaîne.
Un développeur a déclaré qu'il préférait transférer les données blob vers l'EL afin de pouvoir réinsérer les transactions lors de la reconstruction. Il pense que cela n'ajoute pas une charge importante à l'EL et que si ce processus devient compliqué, il est possible d'ajuster les messages entre l'EL et le CL pour alléger la charge.
Cependant, certains ont souligné que cette solution pourrait nuire davantage à l'abstraction entre les couches EL et CL, et pourrait entrer en conflit avec la mise en œuvre future de l'échantillonnage de disponibilité des données (DAS).
Proposition supplémentaire Deneb
En plus de l'EIP-4844, la mise à niveau Deneb a également pris en compte d'autres mises à niveau du code :
EIP-4788 : Publier l'état de la chaîne Beacon CL dans l'EL, permettant aux contrats intelligents d'accéder à la CL avec un minimum de confiance.
EIP-6914 : Réutilisation des numéros d'index des validateurs qui ont complètement quitté le réseau et qui n'ont pas été actifs depuis longtemps, ce qui aide à réduire la croissance infinie de la liste des validateurs.
Un changement de code potentiel, impliquant le remplissage de données à partir du bloc génésique de la chaîne Beacon et la création d'un nouveau contenu de "résumé historique".
PR 3175 : empêcher les validateurs punis de proposer des blocs lors de leur sortie de la file d'attente, fournissant une protection contre le "mode de défaillance élevé".
EIP-6493 : Résoudre comment les nœuds traitent les types de transactions blob formatés en SSZ sur le CL mais encodés différemment sur l'EL.
Les développeurs ont tendance à inclure EIP-4788, EIP-3175 et EIP-4844 dans la prochaine mise à niveau.