Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: --strictFinality option to track the validator set / BeaconState #180

Open
llllvvuu opened this issue Jan 26, 2023 · 4 comments

Comments

@llllvvuu
Copy link

llllvvuu commented Jan 26, 2023

Request: new option (off by default as the BeaconState can be quite large - as can be the attester set) --strictFinality, which if passed:

  1. From the --checkpoint we have BeaconBlock.state_root and probably also the BeaconState. If not, get it in full from /eth/v2/debug/beacon/states/{state_id}, or if not available, from the /eth/v1/beacon/states/{state_id} endpoints. Verify against the state_root.
  2. In consensus.rs:apply_generic_update() implement state_transition(state: BeaconState, signed_block: SignedBeaconBlock, validate_result: bool=True) -> None. We need the full BeaconBlock if we don't already have it. IIRC this is around 40 KB
  3. In consensus.rs:is_finality_proof_valid(), implement process_justification_and_finalization(state: BeaconState) -> None.

Maybe some code can be taken/imported from Lighthouse or ethereum-consensus (state_transition(), BeaconState, process_justification_and_finalization)

(The case against this is whether it would be faster to work backwards from a normal CL client - remove EL body, slasher, etc - than to work forward from Helios)

@llllvvuu llllvvuu changed the title feature request: option to track the validators feature request: option to track the validator set / BeaconState Jan 26, 2023
@llllvvuu llllvvuu changed the title feature request: option to track the validator set / BeaconState feature request: --strictFinality option to track the validator set / BeaconState Jan 26, 2023
@ncitron
Copy link
Collaborator

ncitron commented Jan 26, 2023

Yeah this is a good idea. I do think we can make it a bit more like the cosmos LC protocol though for efficiency reasons. We don't need to track the validator set fully but can rather fetch it once from the checkpoint and then check future headers with that set. Every once in a while we need to refresh the validator set to ensure that many validators haven't churned, but you only need to do this infrequently. This means we don't need to do the state transition every slot, but as long as we are smart about setting the set refresh cadence, it should be just as secure.

@mahmudsudo
Copy link

Hi , can I take on this ?

@ncitron
Copy link
Collaborator

ncitron commented Oct 27, 2024

I'm not sure we're interested in pursuing this at the moment. I think verifying all of consensus would be much to heavyweight in practice, but if you think its possible and have some data on how much bandwidth and compute we'd need I could be convinced.

@mahmudsudo
Copy link

ok then , i would pick a different one

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

No branches or pull requests

3 participants