Un document très important. Passons en revue celui-ci "objectif" par "objectif". Nous commencerons par des créneaux rapides et une finalité rapide. Je m'attends à ce que nous réduisions le temps de créneau de manière incrémentale, par exemple, j'aime la formule "sqrt(2) à la fois" (12 -> 8 -> 6 -> 4 -> 3 -> 2, bien que les deux dernières étapes soient plus spéculatives et dépendent de recherches approfondies). Il est possible d'aller plus vite ou plus lentement ici ; mais le niveau élevé est que nous considérerons le temps de créneau comme un paramètre que nous ajustons à la baisse lorsque nous sommes confiants que c'est sûr de le faire, similaire à l'objectif de blob. Les créneaux rapides sont dans leur propre voie en haut de la feuille de route, et ne semblent pas vraiment se connecter à quoi que ce soit. Cela est dû au fait que le reste de la feuille de route est assez indépendant du temps de créneau : nous devrions faire à peu près les mêmes choses que le temps de créneau soit de 2 secondes ou de 32 secondes. Cependant, il y a quelques zones d'intersection. L'une d'elles est les améliorations p2p. @raulvk a récemment travaillé sur une couche p2p optimisée pour Ethereum, qui utilise le codage d'effacement pour améliorer considérablement le compromis bande passante/latence. En gros : dans le design actuel, chaque nœud reçoit un corps de bloc complet de plusieurs pairs, et peut l'accepter et le retransmettre dès qu'il reçoit le premier. Si la "largeur" (nombre de pairs vous envoyant le bloc) est faible, alors un mauvais pair peut considérablement retarder la réception du bloc. Si la largeur est élevée, il y a beaucoup de données inutiles en surcharge. Avec le codage d'effacement, vous pouvez choisir une configuration k-of-n, par exemple : diviser chaque bloc en 8 morceaux de sorte qu'avec n'importe lesquels 4 d'entre eux, vous puissiez reconstruire le bloc complet. Cela vous donne beaucoup des avantages de redondance d'une grande largeur, sans la surcharge. Nous avons des statistiques qui montrent que cette architecture peut réduire considérablement le temps de propagation des blocs au 95e percentile, rendant des créneaux plus courts viables sans compromis sur la sécurité (sauf l'augmentation de la complexité du protocole, bien que ici le ratio gain de performance/ligne de code soit assez favorable). Une autre zone d'intersection est la structure de créneau plus complexe qui accompagne ePBS, FOCIL, et la règle de confirmation rapide. Celles-ci ont des avantages importants, mais elles diminuent le maximum de latence sûre de créneau/3 à créneau/5. Il y a des recherches en cours pour essayer de mieux canaliser les choses afin de minimiser les pertes (notez également : le temps de créneau est limité non seulement par la latence de créneau, mais aussi par la partie coût fixe de la latence du prouveur ZK), mais il y a des compromis ici. Une façon que nous explorons pour compenser cela est de changer pour une architecture où seulement ~256-1024 attesteurs sélectionnés au hasard signent à chaque créneau. Pour une fonction de choix de fork (non finalisant), cela est totalement suffisant. Le nombre réduit de signatures nous permet de supprimer la phase d'agrégation, raccourcissant les créneaux. La finalité rapide est plus complexe (le protocole ultime est IMO plus simple que le Gasper actuel, mais le chemin de changement est complexe). Aujourd'hui, la finalité prend en moyenne 16 minutes (12s créneaux * 32 époques de créneaux * 2,5 époques). L'objectif est de découpler les créneaux et la finalité, afin de nous permettre de raisonner sur les deux séparément, et nous visons à utiliser un algorithme BFT de finalité à un tour (une variante de Minimmit) pour finaliser. Ainsi, le temps de finalité de fin de jeu pourrait être par exemple de 6 à 16 secondes. Parce que c'est un ensemble de changements très invasifs, le plan est de regrouper la plus grande étape de chaque changement avec un changement de cryptographie, notamment vers des signatures basées sur des hachages post-quantiques, et vers un hachage maximally STARK-friendly (il y a trois réponses possibles aux récentes attaques Poseidon2 : (i) augmenter le nombre de tours ou introduire d'autres contre-mesures telles qu'une couche Monolith, (ii) revenir à Poseidon1, qui est encore plus lindy que Poseidon2 et n'a pas montré de défauts, (iii) utiliser BLAKE3 ou d'autres hachages "conventionnels" maximally-cheap. Tous sont en cours de recherche). De plus, il y a un plan pour introduire beaucoup de ces changements pièce par pièce, par exemple, "finalité en 1 époque" signifie que nous ajustons le consensus actuel pour passer de la finalisation de style FFG à la finalisation de style Minimmit. Une trajectoire possible du temps de finalité est : 16 min (aujourd'hui) -> 10m40s (8s créneaux) -> 6m24s (finalité d'une époque) -> 1m12s (époques de 8 créneaux, 6s créneaux) -> 48s (4s créneaux) -> 16s (minimmit) -> 8s (minimmit avec des paramètres plus agressifs). Une conséquence intéressante de l'approche incrémentale est qu'il existe un chemin pour rendre les créneaux résistants aux quantiques beaucoup plus tôt que de rendre la finalité résistante aux quantiques, donc nous pourrions bien rapidement arriver à un régime où, si des ordinateurs quantiques apparaissent soudainement, nous perdons la garantie de finalité, mais la chaîne continue de fonctionner. Résumé : attendez-vous à voir des diminutions progressives à la fois du temps de créneau et du temps de finalité, et attendez-vous à voir ces changements être entrelacés avec un remplacement de style "navire de Thésée" composant par composant de la structure de créneau et du consensus d'Ethereum avec une alternative plus propre, plus simple, résistante aux quantiques, amicale pour les prouveurs, et formellement vérifiée de bout en bout.