Resolve attested/finalized header confusion in rotation flow #44
Conversation
also `finalized_header_root` to `justified_header_root`
|
Lightclients only concern themselves with finalized objects and not justified objects. Attested headers are not justified headers they are finalized The logic changes look good otherwise. |
| @@ -101,8 +101,8 @@ mod tests { | |||
| let accumulator = [bn256::Fr::zero(); 12]; // this can be anything.. The test is just checking it gets correctly concatenated to the start of the encoded input | |||
|
|
|||
| let instance = CommitteeUpdateCircuit::<Minimal, bn256::Fr>::instance(&witness, LIMB_BITS); | |||
| let finalized_block_root = witness | |||
| .finalized_header | |||
| let justified_block_root = witness | |||
There was a problem hiding this comment.
This naming is incorrect. We work with finalized and attested objects w.r.t. the light client protocol. There is no justified things in the light client protocol
Can second this. We need to avoid using the term "justified" in this context as it isn't the same as justification in Casper and isn't mentioned in the sync protocol spec. Where "justified" is used here we should be using "attested" |
|
Closing as |
Aims to resolve confusion with finalized_header: update.attested_header that became an issue when integrating with Go node.
My understanding is that the attested state root that contains new sync committee (prev
CommitteeRotationArgs.finalized_header.state_root) is going to become finalized in the adjacent step, but since in Spectre.sol both these proofs are expected to be submitted together we useStepInput.finilized_header_rootfor what is actuallyCommitteeRotationArgs.attested_header.hash_tree_root()(ie.justified_header_root).In Go node we should, thereby, schedule rotation proof generation when the committee update epoch becomes finalized.