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

test #1

Open
samelamin opened this issue Nov 16, 2022 · 0 comments
Open

test #1

samelamin opened this issue Nov 16, 2022 · 0 comments

Comments

@samelamin
Copy link
Owner

samelamin commented Nov 16, 2022

Hey guys I have been looking at this in depth over the past week and I have a few questions

I decided to split the work into 2 sections

  1. Identify when the relay chain data has finished syncing
  2. Extract header of parachin to feed into StateSync

The plan is to get 1 done first

Looking into grandpa, The sync works by defining a Network Provider

https://github.com/paritytech/substrate/blob/master/client/finality-grandpa/src/warp_proof.rs#L254-L266

While the default implementation for this is a Warp Sync Provider

https://github.com/paritytech/substrate/blob/master/client/finality-grandpa/src/warp_proof.rs#L270-L286

The WarpSyncProvider then has 2 functions to generate and verify a proof, This uses WarpSyncProof

https://github.com/paritytech/substrate/blob/master/client/finality-grandpa/src/warp_proof.rs#L77-L100

Based on my understanding and from the helpful comments above, we don't need all of this because we - in Cumulus template node - will already know when the relay chain is synced from the relay_chain_interface function is_major_syncing

https://github.com/paritytech/cumulus/blob/26e17fea7ef95d91b94db92079034d4355ad3658/client/relay-chain-interface/src/lib.rs#L172

So here is what I was thinking of implementing

we could create a ParachainWarpProvider that takes in relay_chain_interface and waits for the relaychain to sync up then once it's done get the parachain header and then feed it to StateSync

My question is should we be implementing it via WarpSyncProvider to keep it consistent with the polkadot implementation? Do we need a WarpProof and generating/verifying implementations

Or have I gone down the wrong rabbit hole and we should instead be building our own ChainSync that doesn't require warp proof or a provider

https://github.com/paritytech/substrate/blob/a7ba55d3c54b9957c242f659e02f5b5a0f47b3ff/client/network/sync/src/lib.rs#L396-L406

https://github.com/paritytech/cumulus/blob/981b5d01eb5d0aab0926793e00a7fb933680cf34/client/consensus/common/src/parachain_consensus.rs#L425-L433

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

1 participant