SIMD-0387

TL;DR

This proposal specifies in detail how a BLS public key can be generated by users via updated existing tools and how they can put the generated BLS public keys into their vote accounts for voting in Alpenglow. It also describes in detail the data structure changes needed.

Summary

This proposal specifies in detail how a BLS public key can be generated by users via updated existing tools and how they can put the generated BLS public keys into their vote accounts for voting in Alpenglow. It also describes in detail the data structure changes needed.

Motivation

The Alpenglow SIMD (326) described the new consensus protocol which will be launched on Solana. The protocol requires efficient and safe aggregation of validator votes to succinctly prove certain state transitions can safely happen (for example, 60% of the validators voted to skip a slot). The ed25519 signatures we currently use are not the best fit for this purpose, so instead we will be using the Boneh–Lynn–Shacham (BLS) aggregate signature scheme to sign Alpenglow votes. However, the BLS public key is entirely different from an ed25519 public key (as BLS operates over a different elliptic curve), so we can’t naively reuse the current ed25519 public keys in vote accounts either. Each validator must add a BLS public key into their vote account before the network enables Alpenglow in order to vote.

Key Changes

• Authorize(Pubkey, VoteAuthorize): when VoteAuthorize is VoteAuthorize::Voter
• AuthorizeWithSeed(VoteAuthorizeWithSeedArgs): when authorization_type is
• AuthorizeChecked(VoteAuthorize): when VoteAuthorize is VoteAuthorize::Voter
• AuthorizeCheckedWithSeed(VoteAuthorizeCheckedWithSeedArgs): when
• label is a constant string, we will make it "ALPENGLOW" here (all upper
• vote_account_pubkey is the Ed25519 address of the vote account.
• bls_pubkey_bytes is the compressed new BLS public key (48 bytes).

Impact

### Before feature gate in this SIMD is activated There is no change, users cannot update their BLS public key in vote account. ### After the feature gate in this SIMD is activated but before Alpenglow launch Users can update their BLS public key in the vote account. ### After Alpenglow launch Per SIMD 357, only vote accounts with updated BLS public key can participate in the voting process. When starting a validator, the operators are supposed to provide all ed25519 keypairs like before. The BLS keypair will automatically be derived from the vote authority keypair (if that’s missing, then the identity keypair is used like now). The operations needed to switch the keypair and the operations needed to switch to a standby node are the same as today.

Security Considerations

The safety of BLS votes in Alpenglow is still guarded by the ed25519 vote authority keypair, so users are supposed to safe guard it like before. We need to have the proof of possession in the instruction inputs so we can guard against BLS rogue-key attack. If anyone is allowed to randomly choose a public key, then an attacker can select a particular public key which interacts with other participants' keys so a forged aggregate signature verifies even though not all honest parties actually signed. We need to put `vote_account_pubkey` in Proof of Possession calculation because a replay attack exists: - User A wants to update vote authority, calculates PoP signature - The attacker sees this PoP signature in the transaction and sends in another transaction grabbing the BLS public key before user A - Now user A cannot use the BLS public key generated for his own vote account We also add a `label` so in the future we can update the version.