I got nearly everything wrong about consensus, except the important parts: * it can’t be in the way of block producers utilizing 100% of the bandwidth 100% of the time. * users need some deterministic finality in one round (2-delta) Alpenglow nails both of these requirements with a simple and elegant design that’s really easy to intuit. The clever assumption that Alpenglow builds on is splitting up the faults into two categories. Full Byzantine, and down or unavailable. If the network is ok with tolerance of no more than 20% Byzantine and 20% down then as soon as a node sees a fork with 40% votes it’s safe to commit to it because either that fork is finalized in one round with 80% votes and we are done, or two rounds with 60%. Can’t make it any faster than this 🤌🤌🤌 What users should see is current optimistic confirmations, which see 95%+ votes, become full confirmations immediately. There are no words in human languages to express how core engineering feels about dealing with no more than 2 blocks of state transitions at a time instead of up to an epoch of full of unconfirmed blocks. It’s 1000x times easier to reason about worse case attack surface with async execution. The paper also simplifies and formalizes turbine (now Rotor). Votor and Rotor set us up for an easy path to multiple concurrent leaders, and all the good stuff that follows. 🏒🥅

1/ Przedstawiamy największą w historii zmianę w protokole Solana: Alpenglow, nowy protokół konsensusu Solany opracowany przez zespół Anza Research. Pożegnaj się z Tower BFT i Proof of History. Przywitaj się z Votor & Rotor 🧵👇