SIMD-0326

TL;DR

This proposal changes the core consensus protocol from the current one, based on **Proof-of-History** and **TowerBFT**, to **Alpenglow**, specifically the **Votor** parts of Alpenglow. Compared to the old protocol, **Alpenglow** offers higher resilience and better performance. This SIMD comes with an extensive companion paper. The Alpenglow White Paper v1.1 is available at https://www.anza.xyz/alpenglow-1-1. More precisely, this SIMD covers everything in the v1.1 White Paper **except** - Section 2.2 Rotor: Initially we stay with Turbine as the data dissemination protocol. Rotor will be introduced later and will get its own SIMD. - Section 3.1 Smart Sampling: Related to Rotor, will be included in the Rotor SIMD. - Section 3.2 Lazy (Asynchronous) Execution: Has its own SIMD.

Summary

This proposal changes the core consensus protocol from the current one, based on **Proof-of-History** and **TowerBFT**, to **Alpenglow**, specifically the **Votor** parts of Alpenglow. Compared to the old protocol, **Alpenglow** offers higher resilience and better performance. This SIMD comes with an extensive companion paper. The Alpenglow White Paper v1.1 is available at https://www.anza.xyz/alpenglow-1-1. More precisely, this SIMD covers everything in the v1.1 White Paper **except** - Section 2.2 Rotor: Initially we stay with Turbine as the data dissemination protocol. Rotor will be introduced later and will get its own SIMD. - Section 3.1 Smart Sampling: Related to Rotor, will be included in the Rotor SIMD. - Section 3.2 Lazy (Asynchronous) Execution: Has its own SIMD.

Motivation

The current TowerBFT consensus protocol: - has a consensus finality time of 12.8 seconds, - additionally provides earlier pre-confirmations, - and does not have a security proof, which is concerning. Alpenglow takes into account the current state of the art in consensus research to improve the consensus protocol in all points mentioned above. Alpenglow: - Lowers actual consensus finality latency below the pre-confirmation latency of TowerBFT. - Decreases bandwidth use, e.g., by eliminating costly gossip traffic. - Reduces the consensus computation overhead, e.g., by replacing on-chain signature verification with local signature aggregation. - Increases resilience on all fronts (sophisticated attackers, adversarial network conditions, DOS attacks and crash failures). - Removes harmful incentives, such as waiting to cast more profitable votes.

Key Changes

• In the first round, validators vote either to notarize a specific block or
• In the second round, validators vote finalize if they saw enough notarize
• Notarization: corresponds to 60% of notarize votes.
• Skip: corresponds to 60% of skip or skip-fallback votes.
• Finalization: corresponds to 60% of finalize votes.
• Fast-Finalization: corresponds to 80% of notarize votes.
• Notar-fallback: corresponds to 60% of notarize or notar-fallback votes.
• Create or receive a fast-finalization certificate.
• Create or receive a slow-finalization certificate and a notarization
• Epoch inflation: E = (1+(yearly inflation))^((epoch length) / year)-1
• Inflation in SOL per slot: T = (total SOL supply) E / (slots per epoch)
• Given validator’s stake: R = (validator’s stake) / (total stake)
• Section 2.2 Rotor: Initially we stay with Turbine as the data dissemination protocol. Rotor will be introduced later and will get its own SIMD.
• Section 3.1 Smart Sampling: Related to Rotor, will be included in the Rotor SIMD.
• Section 3.2 Lazy (Asynchronous) Execution: Has its own SIMD.

Impact

The most visible change will be that optimistic confirmation is superseded by faster (actual) finality. Validator operators should also see their resource usage (including bandwidth usage and compute) drop after the migration to Alpenglow.

Backwards Compatibility

Incompatible. Alpenglow completely replaces the old consensus protocol with all its voting logic.

Security Considerations

The white paper provides proofs for safety and liveness under byzantine faults. When instantiated with SHA256 for hashing and BLS12-381 for aggregate signatures, the desired security level of 128-bits is achieved. Alpenglow features a distinctive 20+20 security model. While it does not have the 33% byzantine security that can be achieved with two-round voting protocols, we believe that the one-round voting and the 40% crash failure resilience is worth the tradeoff.