Top Down Checkpoint - Parent View #205
Conversation
cryptoAtwill
changed the title
| Ok(cache.get_value(height).map(|i| i.0.clone())) | ||
| } | ||
|
|
||
| fn validator_set(&self, height: BlockHeight) -> StmResult<Option<ValidatorSet>> { |
There was a problem hiding this comment.
I see that the ValidatorSet contains every validator's key and address. How does it get included at every height? Could it be shared between them when nothing changes? Or be just the configuration ID, to be retrieved from yet another sequential cache? Although the increments are not necessarily uniform there AFAIK.
There was a problem hiding this comment.
We can query the ValidatorSet at every block height in ipc agent. The thing I'm more concerned about is the size of the validators. If there are significant number of validators in the subnet, then every proposal would contain the full list of validators which the validators should not change that frequent. So we are wasting space/bandwidth for sth that does not change much. I have a feeling, which could be wrong, but a cid of the last committed validator set + validator changes in the proposal would be more efficient.
There was a problem hiding this comment.
Yes I totally agree, at least in your cache you could include the validator set changes in a monotonically increasing list of configuration IDs. You could treat them similarly to cross messages. Staying with our example of checkpointing every 10th block, if the last checkpoint was at height 50, and now we are 60, then the agent could add the new finality view by including:
- The hash of block 60
- The messages between height 51 and 60
- The validator set changes that happened between height 51 and 60, sorted by configuration ID
The child validators are not obliged to adopt all validator sets, e.g. if between 51 and 60 we went from configuration 5 to configuration 7, then they can send the next checkpoint signed by validator set 5, stating that they will next adopt validator set 6, or 7, it's up to them. As long as they agree on what these numbers mean, they can use them to identify to the parent who to expect the next signatures from.
There was a problem hiding this comment.
For now, only block hash and height is in the finality.
There was a problem hiding this comment.
Nice progress! My main concern is with how top-down messages are proposed. I am either misunderstanding something or I think we are doing something wrong. Have a look at my comments and let me know if they make sense.
Additionally, it would be really helpful if you could add more extensive comments on the implementation of the DefaultFinalityProvider so it is clear the end-to-end of the parent view (the flow of information, how are variables updated and when, and is each function expected to be used).
…ard/fendermint into parent-view
…ard/fendermint into parent-view
Co-authored-by: adlrocha <6717133+adlrocha@users.noreply.github.com>
|
@adlrocha @aakoshh The querying of top down messages is changed to indexing by height. As discussed in slack, we dont include top down messages and validator set in the finality, we just propose on the block hash and height. Once it’s finalized, in Please help take a look again. |
Co-authored-by: adlrocha <6717133+adlrocha@users.noreply.github.com>
Adding parent view into top down checkpoint, so that the child can constantly sync with the parent to get the latest state of the parent. At the same time, it also make finality proposal, checks finality proposals.