J’ai presque tout faux sur le consensus, sauf les parties importantes : * Cela ne peut pas empêcher les producteurs de blocs d’utiliser 100 % de la bande passante 100 % du temps. * Les utilisateurs ont besoin d’une certaine finalité déterministe en un seul tour (2-delta) Alpenglow répond à ces deux exigences avec un design simple et élégant qui est vraiment facile à deviner. L’hypothèse intelligente sur laquelle s’appuie Alpenglow est de diviser les failles en deux catégories. Byzantin complet, et en bas ou indisponible. Si le réseau est d’accord avec une tolérance ne dépassant pas 20 % de votes byzantins et 20 % de down, alors dès qu’un nœud voit un fork avec 40 % de votes, il est sûr de s’y engager car soit ce fork est finalisé en un tour avec 80 % de votes et nous avons terminé, soit deux tours avec 60 %. Je ne peux pas aller plus vite que ça 🤌🤌🤌 Ce que les utilisateurs devraient voir, ce sont les confirmations optimistes actuelles, qui voient 95 %+ votes, devenir immédiatement des confirmations complètes. Il n’y a pas de mots dans les langues humaines pour exprimer ce que ressent l’ingénierie de base lorsqu’elle ne gère pas plus de 2 blocs de transitions d’état à la fois au lieu d’une époque pleine de blocs non confirmés. Il est 1000 fois plus facile de raisonner sur la surface d’attaque du pire des cas avec l’exécution asynchrone. Le document simplifie et formalise également turbine (maintenant Rotor). Votor et Rotor nous ont mis en place pour un chemin facile vers plusieurs leaders simultanés, et toutes les bonnes choses qui s’ensuivent. 🏒🥅