SIMD-0384

TL;DR

Migrate to Alpenglow from TowerBFT

Summary

Migrate to Alpenglow from TowerBFT

Motivation

Migrating from TowerBFT to Alpenglow consensus requires a safe handoff mechanism that doesn't rollback TowerBFT confirmed user transactions.

Key Changes

• Slot at which Alpenglow migration begins
• For all slots after and inclusive of this boundary slot:
• Turn off packing anything other than simple vote transactions in blocks. Any transactions not belonging to the vote program will cause a block to be marked dead during replay by all correct validators.
• Core code will stop notifying RPC services of any optimistic confirmation/ commitment updates.
• TowerBFT will stop rooting blocks to prevent losing optimistically confirmed blocks that could qualify as the Alpenglow genesis blocks.
• The last TowerBFT block before the "migration boundary slot" which is the
• A block B is strong OC if there exists a block T such that B is the parent of T and slot(B) + 1 = slot(T) and T contains vote transactions for B from at least 82% of stake.
• Pick a "migration boundary slot" (defined above) S as follows. Let X be the feature activation slot. Let the migration slot S be X + 5000, as to avoid the beginning of an epoch.
• After the migration boundary slot S, wait for some block B >= S to reach strong optimistic confirmation.
• Find the most recent ancestor block G of B from before the migration boundary slot S. This is the Alpenglow genesis block. Cast a BLS vote, the "genesis vote", for G via all to all. Note validators should have filled out their BLS keys prior to the feature flag activation, and will sign this genesis vote with this BLS key.
• If we observe >=82% genesis votes for the ancestor block G, this consitutes the genesis certificate, and G is the genesis block for Alpenglow. Validators will periodically refresh genesis votes every GENESIS_VOTE_REFRESH = 400ms (i.e. once a slot) until this genesis certificate is observed. During this period they perform regular TowerBFT consensus for all blocks.
• Anytime a correct validator receives a genesis certificate for a slot G (either constructed themselves, received through replaying a block, or received from all-to-all broadcast), they:
• Verify the certificate against the BLS keys for the epoch.
• Broadcast the certificate to all other validators via the Alpenglow all-to-all mechanism. Validators will continually retry broadcasting this certificate every 10 seconds via the certificate pool standstill timer so long as a finalized Alpenglow certificate for a higher slot isn't detected.
• We initialize the alpenglow votor module with G as genesis, and disable TowerBFT for any slots past G
• In block production pack the genesis certificate as a GenesisBlockMarker for any blocks that are direct children of G. This means anybody replaying any of the initial Alpenglow blocks must see the genesis certificate.
• Delete all blocks and shreds with slot greater than slot(G) from blockstore, and reset all associated state (replay, AccountsDB) to block G, as is currently done when we rollback duplicate blocks.
• We re-enable packing non-vote transactions, enable Alpenglow rooting, and re-enable RPC commitment/confirmation reporting.
• Anytime a validator receives a genesis certificate validated through replaying the header of a block, they store the certificate in a migration success off-curve account Pubkey::find_program_address(&["carlgration"], alpenglow::id()). This means all snapshots descended from the block will contain this account and signal to validators that they should initiate Alpenglow after unpacking the snapshot.
• Alternatively, anytime a correct validator that has not yet detected a genesis certificate, but receives an Alpenglow finalization certificate for some block X that they can verify, they should repair/replay all the ancestors of X

Impact

During the migration process, there will be a liveness impact for the duration of the migration, which is optimistically only one slot past the migration boundary slot. Validators will run Alpenglow after discovering the genesis block after the migration boundary.

Backwards Compatibility

This feature is not backwards compatible.

Security Considerations

N/A