-
Notifications
You must be signed in to change notification settings - Fork 309
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
Comments
BeaconState
BeaconState
--strictFinality
option to track the validator set / BeaconState
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. |
Hi , can I take on this ? |
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. |
ok then , i would pick a different one |
Request: new option (off by default as the
BeaconState
can be quite large - as can be the attester set)--strictFinality
, which if passed:--checkpoint
we haveBeaconBlock.state_root
and probably also theBeaconState
. 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 thestate_root
.consensus.rs:apply_generic_update()
implementstate_transition(state: BeaconState, signed_block: SignedBeaconBlock, validate_result: bool=True) -> None
. We need the fullBeaconBlock
if we don't already have it. IIRC this is around 40 KBconsensus.rs:is_finality_proof_valid()
, implementprocess_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)
The text was updated successfully, but these errors were encountered: