Spec: topdown spec #920
Spec: topdown spec #920
Conversation
specs/topdown.md
Outdated
| @@ -0,0 +1,84 @@ | |||
| #Topdown Finality | |||
|
|
|||
| The topdown finality propagates the states in the parent subnet to the child blockchain. The following data are passed: | |||
There was a problem hiding this comment.
I'd suggest to first describe what is the purpose of topdown finality in IPC, then when exactly it happens, and only then the exact data which is being passed from parent to the child. Wdyt?
specs/topdown.md
Outdated
|
|
||
| From a high level point of view, the topdown finality works as follows: | ||
|
|
||
| - Parent finality process will first fetch the last committed `ParentFinality`. If there is no previous committed parent finality, the genesis block is [used](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/topdown/src/sync/mod.rs#L36). |
There was a problem hiding this comment.
Can you describe what and when triggers "Parent finality process"?
There was a problem hiding this comment.
There is actually no one triggering the process, it's always running in the background once enabled. I have added this into the spec.
specs/topdown.md
Outdated
|
|
||
| As topdown finality relies heavily on RPC node for querying, make sure the RPC node is reliable and returns enough historical data. | ||
|
|
||
| See also [IPS Spec - Executions](https://www.notion.so/IPS-Spec-Executions-ebf13d833d6845ec9c11b59bd514fcda?pvs=21) for a description of how proposals and and executions are implemented. |
There was a problem hiding this comment.
It shouldn't link to Notion anymore.
There was a problem hiding this comment.
the issue is currently there are no links to those specs yet, I will remove the hyper link first and add them back later.
specs/topdown.md
Outdated
|
|
||
| A quorum detected by the `VoteTally` is used a pre-condition for finality proposals being added to the CometBFT block proposals, to avoid any liveness issues which could arise if the other validators were to reject the proposal. If a premature finality causes the block propsal to fail, it means in that round CometBFT cannot make progress, it cannot finalize a block, potentially causing the subnet blockchain to stall. By requiring a quorum, we avoid this issue by only proposing when we have high confidence that the proposal will be accepted. | ||
|
|
||
| See [IPC Spec - IPLD Resolver](https://www.notion.so/IPC-Spec-IPLD-Resolver-7b4290a0d60c40cdba98cd6d3e66648b?pvs=21) for a more detailed discussion of the `VoteTally`. |
There was a problem hiding this comment.
It shouldn't link to Notion anymore, since external teams won't have access to it.
There was a problem hiding this comment.
I removed the link for now, will add them back once they are merged
Co-authored-by: Maciej Witowski <maciej.witowski@protocol.ai>
Co-authored-by: Maciej Witowski <maciej.witowski@protocol.ai>
Co-authored-by: Maciej Witowski <maciej.witowski@protocol.ai>
Co-authored-by: Maciej Witowski <maciej.witowski@protocol.ai>
Co-authored-by: Maciej Witowski <maciej.witowski@protocol.ai>
Co-authored-by: Maciej Witowski <maciej.witowski@protocol.ai>
Co-authored-by: Maciej Witowski <maciej.witowski@protocol.ai>
Co-authored-by: Maciej Witowski <maciej.witowski@protocol.ai>
Adding topdown finality spec