Substrate-connect/smoldot support a ligher version of chain specs

[tomaka]

Content request

The chain specifications that Substrate generates contain a field that looks something like this:

"genesis": {
  "raw": {
    "top": {
      "0x26aa394eea5630e07c48ae0c9558cef75684a022a34dd8bfa2baaf44f172b710": "0x01",
      "0x3a63": "0x",
      "0x26aa394eea5630e07c48ae0c9558cef7b99d880ec681799c0cf30e8886371da9b04f1294d48f00313f90829cc9e71bdddc0ab723ecf97d82c92ef7df9c26cc9ca6f5b0326921368fe99eef9c298e3467": "0x0000000000000000010000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "0x26aa394eea5630e07c48ae0c9558cef7b99d880ec681799c0cf30e8886371da9a92ae391586c8d2463bc6fbbe0a6b763def75b7e0082c62f2b333e148d2d394f5fbc62f698957fb595fbb5d65fcca325": "0x0000000000000000010000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
    }
  }
},

When using substrate-connect/smoldot, you have the alternative possibility to pass just the state root hash:

"genesis": {
  "stateRootHash": "0x29d0d972cd27cbc511e9589fcb7a4506d5eb6a9e8df205f00472e5ab354a4e17"
},

The reason why this is advantageous is that chain specs are way ligher. For example, the regular Polkadot chain specification is 5.7 MiB, while the lighter version of it (with raw replaced with stateRootHash) is only 110.4 kiB. This is a big factor when the chain spec is loaded when visiting a website.

Substrate will return an error if you try to load a chain with this lighter version of chain specs, as it is too complicated to implement support in Substrate at the moment. Only substrate-connect/smoldot will successfully load it.

In order to calculate the state root hash, you can load the regular (with "raw") chain specs into smoldot, and it will print the state root hash at initialization in its logs. There is currently no easier way to do that.

Are you willing to help with this request?

Yes!

[nuke-web3]

I think this should be included in #1122 (or another PR that will replace it)