Skip to content

[DRAFT] Compute real deposit signatures when BLS verification is disabled - #1

Draft
syjn99 wants to merge 1 commit into
masterfrom
fix/never-bls-deposit
Draft

[DRAFT] Compute real deposit signatures when BLS verification is disabled#1
syjn99 wants to merge 1 commit into
masterfrom
fix/never-bls-deposit

Conversation

@syjn99

@syjn99 syjn99 commented Jul 30, 2026

Copy link
Copy Markdown
Owner

Similar motivation with ethereum#5489 and mirrors it. An invalid deposit signature does not invalidate the block - the deposit is silently skipped - so its validity is reflected in the BeaconState. bls_setting: 2 currently makes fixture use stub deposit signatures, so the expected post-state depends on how the client handles BLS-off mode. In Prysm, we always verify deposit signatures, so the deposit created in the test like test_is_one_confirmed_fails_recently_activated_validator_voting_in_empty_slot fails because of state root validation. I guess Lodestar has similar problem with us, currently just skipping the test attributing the reason to their FCR implementation.

The alternative - clients disabling all BLS verification under bls_setting: 2 - would require a test-only hook inside production deposit processing in every client, because deposit signature validity is a state-transition branch rather than a verification gate. With this change the vectors remain bls_setting: 2 (block signatures are still stubs) - only the signature whose validity selects state content is real.

Related to ethereum#5489 and follow up of ethereum#5400. Verified with Prysm fcr branch (PR), as the following tests pass when new fixture is generated based on the change that this PR will bring:

  • test_is_one_confirmed_fails_recently_activated_validator_voting_in_empty_slot
  • test_is_one_confirmed_passes_with_new_validator_activated_in_head_state

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant