Plus tôt dans la journée, j'ai présenté à tous les développeurs principaux notre argument en faveur de temps de créneaux 2x plus courts à Glamsterdam. Nous croyons que des créneaux plus courts sont une option solide que l'Ethereum devrait envisager dans ce calendrier, avec de nombreux avantages allant d'une meilleure expérience utilisateur à l'amélioration de l'une des principales propositions de valeur d'Ethereum L1, son moteur de confirmation. Glamsterdam est un fork qui devrait être lancé en 2026. La présentation est liée ci-dessous, ainsi qu'une discussion sur la manière dont cette proposition s'intègre (jeu de mots :)) avec d'autres, en particulier les propositions de restructuration des créneaux. Si les décisions à prendre sont "quelle proposition de restructuration devrait être sélectionnée" et "dans quel ordre devrions-nous expédier des créneaux plus courts et des créneaux restructurés", je crois qu'il est essentiel de trouver des réponses en tenant compte des créneaux plus courts et de la latence des transactions. Quelques étapes suivantes précieuses : - Un comptage approprié du travail nécessaire sur les deux voies (raccourcissement -> restructuration contre restructuration -> raccourcissement) - Une analyse de la propagation des attestations et des agrégations - Trouver nos points préférés sur la courbe de compromis entre le débit et le temps de créneau pour chacune des propositions de restructuration. La question est ouverte de savoir si nous pourrions viser moins de 6 secondes avec certains de ces créneaux restructurés. Il semble, d'après la conversation, que cela pourrait être le cas ! Si vous êtes intéressé à contribuer, n'hésitez pas à me contacter :)

Enregistrement de la présentation et de la discussion

Diapositives

Lien vers notre proposition