-
Notifications
You must be signed in to change notification settings - Fork 3
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
Add chainSpec_unstable_spec
method
#124
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_spec
method 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:
Genesis
entry contains either aRaw
entry or astateRootHash
entrystateRootHash
represents 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 astateRootHash
entry).protocolID
andforkId
are placed under a commonnetworkProperties
objectpara_id
andrelay_chain
are placed under a commonparachain
object; while using camelCase namingtelemetryEndpoints
contains objects instead of tuples to explicitly describe theaddress
of the telemetry server and theverbosity_level
checkpoint
object is addedforkedBlocks
entry is renamed totrustedBlocks
and moved under this objectforkedBlocks
are now identified by a block number and block hashbadBlocks
are moved under this objectThe
checkpoint
object 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