-
Notifications
You must be signed in to change notification settings - Fork 6
Add chainSpec_unstable_spec method
#124
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
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
relay_chain Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
|
While I like the idea of defining the format of the chain spec in the JSON-RPC specification, it is unfortunately a bit complicated to define a proper format, due to a lot of details. In smoldot, I intended to indeed add a JSON-RPC function that returns the chain spec, but I wanted to leave this JSON-RPC function unstable forever and make it smoldot-specific. Apart from which name to give to things, here's a list of remarks:
|
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
|
In this revision I've added the consensus and finality bits we need to sync with the chain. I suggest adding this as unstable and implementing it in substrate to have a starting point. |
This PR adds the
chainSpec_unstable_specmethod to fetch the chainSpec from a running node.Substrate nodes expose currently
sync_state_genSyncSpec. The new method unifies the format of substrate chain-spec needed for the light-clients to sync to the head of the chain.There are several differences from the traditional chain-spec:
Genesisentry contains either aRawentry or astateRootHashentrystateRootHashrepresents the merkle value of the genesis. This is an optimisation used by smoldot to store smaller chainSpec files, and to allow light-clients to sync up faster (since a raw entry must be first converted to astateRootHashentry).protocolIDandforkIdare placed under a commonnetworkPropertiesobjectpara_idandrelay_chainare placed under a commonparachainobject; while using camelCase namingtelemetryEndpointscontains objects instead of tuples to explicitly describe theaddressof the telemetry server and theverbosity_levelcheckpointobject is addedforkedBlocksentry is renamed totrustedBlocksand moved under this objectforkedBlocksare now identified by a block number and block hashbadBlocksare moved under this objectThe
checkpointobject could then be extended to include the syncState needed by lightclients: https://github.com/paritytech/substrate/issues/11184Block numbers are represented as string unsigned integers, similar to the current chainSpec. I believe this may be an artifact of javaScript users.
Would love to get your thoughts on this 🙏
// cc @jsdw @tomaka @bkchr @skunert