SIMD-0387: BLS Pubkey Management in Vote Account. #387

wen-coding · 2025-10-27T22:07:27Z

Add BLS Pubkey Management in Vote Account for Alpenglow.

proposals/0387-bls-pubkey-management-in-vote-account.md

buffalojoec · 2025-10-28T05:37:59Z

proposals/0387-bls-pubkey-management-in-vote-account.md

+Since BLS verification is expensive (in the order of ~1 millisecond), these
+operations changing BLS public key will need to have correct CU specified to
+succeed (actual numbers to be measured and published later).


Are you saying we should change the Vote program to use different CU consumption amounts per-instruction? That should be specified in here, and we should probably include the new values themselves.

Added. I don't think we have the actual numbers now, need to test that.

@samkim-crypto confirmed it's about 801us to 1.15ms in benchmark. I'll check with @tao-stones the actual CU numbers we would need.

Yes it is 801us on my local machine and 1.15ms on my remote dev machine. My remote dev machine matches the ed25519 sigverify cost pretty closely, so 1.15 is probably a more correct number.

But the precise CU would depend on how/where we execute the verification: one syscall, multiple syscalls inside the vote program or CPI into a BLS program.

To be consistent, using current conversion rate of 30cu per 1 micro-sec, 1.15ms converts to 34,500 CU. It exceeds 3,000 MAX builtin allocation CUs. (As a reference, currently all vote instructions have 2,100 CUs). So the v2 vote needs to be excluded from "builtin " list. Also, to echo @buffalojoec 's point, are all instructions do same BLS verifications therefore cost same CUs, or they can be different?

Thanks! The new instructions/new variants all do the same BLS verification and they should cost the same amount of CUs.

Yeah we should exclude these from the builtin list.. We could exclude the vote program completely since AFAIK simple vote transactions don't go through that code path and other vote related transactions are relatively rare and then 3k -> 200k default cost per vote ix is not very impactful.

Sounds good, do I need to write that into this SIMD?

Yeah, I think so — excluding the Vote program from the built-in list would affect consensus. It’d be great if you could include what @jstarry mentioned in the section where the Vote program is defined.

Added, see if what I added make sense?

proposals/0387-bls-pubkey-management-in-vote-account.md

buffalojoec · 2025-10-28T05:49:58Z

proposals/0387-bls-pubkey-management-in-vote-account.md

+- AuthorizeCheckedWithBLS(VoteAuthorizeWithBLS)
+
+Changing the vote authority public key and BLS public key for existing vote
+account without using seed: (we can also use it to add BLS public key to
+existing vote account, just check vote authority public key didn’t change)


If the BLS key is set, I can't use the old instruction to change my vote authority, right? Otherwise, the BLS key would be out-of-step. So, we need to deprecate and fully disable that instruction in order to add this one.

You could alternatively just add a new variant for the instruction input. Then you can use the existing instruction, and the SIMD can specify Vote program behavior that rejects updates to voter address without corresponding BLS proof of possession, if BLS key is set.

I think the alternative above would also allow AuthorizeCheckedWithSeed to just have a behavioral change and also capture the new variant in authorization_type.

I actually only care about touching vote authority pubkey, for other changes I'm fine to have old instructions go through, but it's going to be confusing to user, so maybe better to move everything to new instructions.

If capturing the new variant in authorization_type does the work, then I'm fine with it. All I care is:

Must specify BLS pubkey when creating new account

Whenever vote authority pubkey changes, BLS pubkey must change with it

I don't see why we couldn't do a new variant in VoteAuthorize. I think the program would just have to have a feature gate that changes its behavior once the new variant is activated. It should disallow changes to the Voter variant if a BLS pubkey is set.

We would need this behavior with the existing instruction anyway, so IMO it's cleaner to just add a variant to the input rather than a new instruction.

I'm totally fine with that. @jstarry what do you think?

Chatted a bit with @buffalojoec about this. I don't mind either approach (new variant in VoteAuthorize or new instruction). But I think that if we go with a new instruction it would be pretty nice because we could remove the clock sysvar account input and make it specific to the vote authority and not need to worry about supporting "WithSeed" because that's really only useful for the withdraw authority anyways.

In either case, @buffalojoec is right that we can't allow voters to use the old instruction (or variant) to change the vote authority if a BLS key is already set. This behavior needs to be detailed in this SIMD.

While I can appreciate the ability to remove the sysvar accounts, my opinion is that it feels a bit like scope creep and I think the new VoteAuthorize variant is a cleaner solution right now. Vote and VoteSwitch will still need Clock anyway, and we can always just remove the need for such accounts, in a completely backwards-compatible way, either separate from this SIMD or whenever the program is migrated on-chain post-Alpenglow.

Does the current change look correct then?

jstarry · 2025-10-29T03:14:16Z

proposals/0387-bls-pubkey-management-in-vote-account.md

+corresponding BLS keypair. Then the vote program can do a syscall to actually
+verify the validity of BLS public key. If the verification fails, the
+transaction will fail.


There's no precedent for native programs making syscalls that I know of. We should probably add a BLS program which can verify the BLS key proof of possession. Then, the vote program can invoke the BLS program to verify the proof.

Added that to "Alternatives Considered".

jstarry · 2025-10-29T15:00:32Z

proposals/0387-bls-pubkey-management-in-vote-account.md

+- AuthorizeCheckedWithBLS(VoteAuthorizeWithBLS)
+
+Changing the vote authority public key and BLS public key for existing vote
+account without using seed: (we can also use it to add BLS public key to
+existing vote account, just check vote authority public key didn’t change)


Chatted a bit with @buffalojoec about this. I don't mind either approach (new variant in VoteAuthorize or new instruction). But I think that if we go with a new instruction it would be pretty nice because we could remove the clock sysvar account input and make it specific to the vote authority and not need to worry about supporting "WithSeed" because that's really only useful for the withdraw authority anyways.

In either case, @buffalojoec is right that we can't allow voters to use the old instruction (or variant) to change the vote authority if a BLS key is already set. This behavior needs to be detailed in this SIMD.

… Alternatives Considered.

jstarry · 2025-11-05T03:50:27Z

proposals/0387-bls-pubkey-management-in-vote-account.md

+// Will be totally forbidden, use InitializeAccountV2
+InitializeAccount(VoteInit),
+// Forbidden when VoteAuthorize is VoteAuthorize::Voter
+AuthorizeChecked(VoteAuthorize),
+// Forbidden when authorization_type is VoteAuthorize::Voter
+AuthorizeCheckedWithSeed(VoteAuthorizeWithSeedArgs),


We should have a period of time where both legacy and alpenglow instructions are active to give us time to migrate offchain tooling like the CLI commands for creating vote accounts. But as discussed, we should not allow using the VoteAuthorize::Voter variant if the BLS pubkey is already configured for a vote account.

Changed, how does this look?

Is this comment still relevant if we don't do new instructions and instead do the new VoteAuthorize variant? I think no - since it appears outdated - but wanted to double-check as I review!

I think forbid VoteAuthorize::Voter when the BLS pubkey is already configured is probably enough, this guarantees once you have a BLS pubkey it is always valid. For those people rejecting to write BLS pubkey to their vote account, allowing them to do VoteAuthorize::Voter is not end of the world, we will kick them out eventually per SIMD 357.

jstarry · 2025-11-05T03:51:49Z

proposals/0387-bls-pubkey-management-in-vote-account.md

+operations changing BLS public key will need to have correct CU specified to
+succeed (actual numbers to be measured and added to this PR).
+
+#### Disallow change of vote authority by old instructions


VoteInstruction::Authorize and AuthorizeWithSeed also exist. We need to address changes for those instructions as well

jstarry · 2025-11-05T03:56:03Z

proposals/0387-bls-pubkey-management-in-vote-account.md

+program, see "Alternatives Considered" for comparison with other solutions.
+
+Since BLS verification is expensive (in the order of ~1 millisecond), these
+operations changing BLS public key will need to have correct CU specified to


Can you clarify that CU's must be consumed right before doing BLS signature verification? And cc @tao-stones for discussing the CU number given time for BLS verification.

Yup, already asked Tao and he estimate 1.15ms running time translates to 34,500 CU. Updated that in the PR.

34,500 CU for BLS verification is based on current 30cu per 1us - questioned here if vote program be excluded from "builtin". @jstarry if this is the case?

proposals/0387-bls-pubkey-management-in-vote-account.md

bw-solana · 2025-11-20T15:47:41Z

proposals/0387-bls-pubkey-management-in-vote-account.md

+BLS keypairs can be generated randomly like ed25519 keypairs. But to save the
+users some trouble on keypair management, we chose to derive their BLS keypair
+used in Alpenglow votes based on their ed25519 vote keypair. In other words,
+with an existing ed25519 vote keypair, the users can safely regenerate the
+associated BLS keypair on demand.


we should be clear as to whether it MUST be this way or not. This reads as if it's just 1 (perceived easier) option. Is it okay if I generate a BLS pubkey that is completely unrelated to my ed25519 key, stick that in my vote account and use it to sign?

It's actually possible, and we have no way to verify the two are related. So users can do:

Generate a random BLS keypair and put that in vote account

Change code to use the given BLS keypair instead of using the vote authority keypair

The protocol works as long as the users use the same BLS keypair in step 1 and 2.

The long term plan after Alpenglow migration is that we should get rid of vote authority keypair and have BLS keypair only, then users supply BLS keypair to validator execution.

Clarified it a bit.

might be nice to specify what the "we chose to derive" pertains to. I believe what it means is that we (Azna) chose to make the Agave client default implementation infer the BLS keypair from the ed25519 keypair and use this for signing votes.

I have mixed thoughts as to whether this client implementation detail belongs in a SIMD.

Yeah, I originally didn't want to put it in the SIMD, but then the users may have the question: "Do I need to generate a BLS keypair and put it in my wallet?" So this is user visible.

We mainly chose current route so during the migration epoch, we don't need to tell users: "Please explicitly load both keypairs in your wallet, you will need the BLS keypair suddenly in the middle".

After Alpenglow launches it matters less, we can relax this association and remove vote authority ed25519 keypair completely.

Changed.

yeah, makes sense. I'm assuming FD will do this the same way. Might be good to spell out this is the default client behavior (as opposed to something in protocol)

Sure, changed it to be:

The association of BLS keypair with vote authority ed25519 keypair is the default client behavior to simplify Alpenglow launch. After Alpenglow launches we may get rid of ed25519 vote keypair and allow users to randomly generate BLS keypairs.

How does this look?

proposals/0387-bls-pubkey-management-in-vote-account.md

bw-solana · 2025-11-20T15:55:35Z

proposals/0387-bls-pubkey-management-in-vote-account.md

+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.


We should mention a critical piece of the proposal here, which is how the network verifies PoP

Proof of Possession Calculation actually is the verification method as well, reworked that section.

simd-bot · 2025-11-20T19:16:56Z

Thanks, @lidatong!

⚠️ Status: Cannot merge yet

Missing approval from: Anza (@t-nelson, @sakridge, @bw-solana)

qkniep

Looks good to me, just some last nits. Thanks for adding the PoP specification.

proposals/0387-bls-pubkey-management-in-vote-account.md

qkniep · 2025-11-21T09:59:36Z

proposals/0387-bls-pubkey-management-in-vote-account.md

+- 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


Do we say that we check whether the public key is already in use? I don't see it.

We don't enforce it anywhere, but we can emit a warning in CLI if the public key is already in use. The reasons being:

it's hard to perform cross account check in vote program transactions

it should be cryptographically hard to generate the same private key as others

the PoP proof above guarantees you can't easily claim a BLS keypair you don't own by replay attack
So without checking we should still be okay.

Co-authored-by: Quentin Kniep <[email protected]>

simd-bot · 2025-11-21T16:23:28Z

Thanks, @bw-solana!

⚠️ Status: Cannot merge yet

Missing approval from: Firedancer (@ptaffet-jump, @topointon-jump, @0x0ece, @lidatong, @ripatel-fd)

simd-bot · 2025-11-21T16:32:08Z

✅ All approvals received! @wen-coding, you can now merge this by commenting /merge.

✅ Status: Ready to merge

wen-coding · 2025-11-21T16:35:45Z

✅ All approvals received! @wen-coding, you can now merge this by commenting /merge.

✅ Status: Ready to merge

/merge

wen-coding · 2025-11-21T16:37:03Z

/merge

simd-bot · 2025-11-21T16:37:09Z

✅ Merge successful! @wen-coding's PR has been merged.

wen-coding added 4 commits October 27, 2025 15:06

SIMD-387: BLS Pubkey Management in Vote Account.

6f8f199

Add in missing sections.

29a6d38

Make linter happy.

9c9ead5

Explain alternatives.

229b601

wen-coding requested review from buffalojoec and jstarry October 27, 2025 22:30

wen-coding added 3 commits October 27, 2025 20:35

Mention BLS rogue-key attack in security considerations.

eed2c38

Reword the BLS rogue key attack a bit.

e8e24d3

Proof of knowledge -> Proof of possession

39033d5

wen-coding changed the title ~~SIMD-387: BLS Pubkey Management in Vote Account.~~ SIMD-0387: BLS Pubkey Management in Vote Account. Oct 28, 2025

buffalojoec reviewed Oct 28, 2025

View reviewed changes

Address pr comments.

d0dde55

wen-coding requested a review from apfitzge October 28, 2025 17:29

jstarry reviewed Oct 29, 2025

View reviewed changes

wen-coding added 4 commits October 30, 2025 09:14

Specify that it's a compressed BLS pubkey.

5de2954

Clarify the new vote program additions and add BLS syscall/program to…

a8e44f9

… Alternatives Considered.

Specifying the new variant will fail in all other instructions.

b71247b

Make linter happy.

3197a17

wen-coding requested review from buffalojoec, jstarry and samkim-crypto November 1, 2025 16:49

github-actions bot mentioned this pull request Nov 3, 2025

Upstream Updates - Mon Nov 3 00:17:14 UTC 2025 smartcontractkit/chainlink-solana#1377

Open

Some small fixes.

629daad

wen-coding mentioned this pull request Nov 4, 2025

Add VoteInitV2 and new variant in VoteAuthorize to add BLS Pubkey to vote program. anza-xyz/solana-sdk#424

Merged

Update enum new variant definition.

561edb2

jstarry reviewed Nov 5, 2025

View reviewed changes

Address pr comments.

34a576b

wen-coding requested a review from jstarry November 5, 2025 05:10

Add proposal to remove vote program from using builtin CU limit.

109feee

wen-coding mentioned this pull request Nov 7, 2025

SIMD-0357: Alpenglow VAT implementation #357

Merged

bw-solana reviewed Nov 20, 2025

View reviewed changes

wen-coding added 8 commits November 20, 2025 09:17

Address pr comments.

a6a8ef0

Make linter happy.

02cc97c

Explain PoP calculation and verification.

c3813cb

Clarify a bit.

9382ffa

Clarify more.

e81fa9e

Address pr comments.

5296d19

Clarify the cli will do everything for the user.

cba1c98

Fix english.

3ec7407

wen-coding requested review from bw-solana and lidatong November 20, 2025 18:36

lidatong previously approved these changes Nov 20, 2025

View reviewed changes

Clarify a bit.

b88c205

wen-coding dismissed lidatong’s stale review via b88c205 November 20, 2025 21:54

Address pr comments.

3a55e37

qkniep reviewed Nov 21, 2025

View reviewed changes

wen-coding and others added 2 commits November 21, 2025 08:04

Update proposals/0387-bls-pubkey-management-in-vote-account.md

20b5657

Co-authored-by: Quentin Kniep <[email protected]>

Update proposals/0387-bls-pubkey-management-in-vote-account.md

e1f1a07

Co-authored-by: Quentin Kniep <[email protected]>

bw-solana approved these changes Nov 21, 2025

View reviewed changes

lidatong approved these changes Nov 21, 2025

View reviewed changes

simd-bot bot merged commit a47c8f1 into solana-foundation:main Nov 21, 2025
2 checks passed

wen-coding deleted the bls_pubkey_management_in_vote_account branch November 21, 2025 16:37

github-actions bot mentioned this pull request Nov 24, 2025

Upstream Updates - Mon Nov 24 00:18:18 UTC 2025 smartcontractkit/chainlink-solana#1391

Open

samkim-crypto mentioned this pull request Nov 24, 2025

[bls-signatures] Add support for custom payloads for bls PoP anza-xyz/solana-sdk#452

Merged

SIMD-0387: BLS Pubkey Management in Vote Account. #387

SIMD-0387: BLS Pubkey Management in Vote Account. #387

Uh oh!

Conversation

wen-coding commented Oct 27, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wen-coding Nov 21, 2025 •

edited

Loading