Testnet chainspec for Light Client Demo

[bernardoaraujor]

Is your feature request related to a problem? Please describe. We at Parity are preparing a light client demo for Bitcoin Miami 2022. We want to use a substrate connect light client to move kBTC. It would be nice to do that on the testnet that's live at https://testnet.interlay.io/bridge

With substrate connect, light clients connect to a relay or parachain without syncing with it. All they need is the correct chainspecs. Greg forwarded some chainspecs from Interlay devops:

• https://interlay-public.ams3.digitaloceanspaces.com/staging-latest-parachain-1.7.4.json
• https://interlay-public.ams3.digitaloceanspaces.com/rococo-local-0.9.16.json

However these chaispecs don't give us the necessary information on bootNodes. They are:

• empty on relay chainspec
• 127.0.0.1 on para chainspec

Without the correct information on bootNodes, we can't get the light client to connect to Interlay testnet, because they don't know how to find the chain.

Describe the solution you'd like We need chainspecs with bootNodes that are prepared to launch nodes outside of Interlay infrastructure.

Describe alternatives you've considered Worst case, we will launch our own testnet. But using Interlay infrastructure would be very helpful to us.

Additional context Here's a screenshot of the burnr wallet in action:

The plan is to have kBTC instead of WND, and interact with the testnet chain over the light client that we will launch from the provided chainspecs.

[ns212]

The chainspec files have been updated. Please download them again and test it out.

[wirednkod]

The chainspec files have been updated. Please download them again and test it out.

Thank you @ns212 . One question though - is there an apps (like polkadot.js/apps) test site of the relay chain - that I can verify that the parachain is connected to it? I can see that in the parachain spec there is a parachain Id of 2121. also though the parachain spec contains the "relay_chain": "staging", but the relay chainspec's id is rococo_local_testnet which does makes me think that there is something missing.

In addition - for the light client there is a need of at least 2 bootnodes on relay chain and parachain for the connection to take place.

[ns212]

We added an additional boot nodes on both the parachain and the relay chain; The chainspec files have been updated.

[wirednkod]

Thank you @ns212 . Will test new chainSpecs and let you know of the outcome.

[wirednkod]

@ns212 Can you please also add the following settings in collator (and relay if possible) so that they are listening for WebSocket connections? In order to do that - please add --listen-addr /ip4/0.0.0.0/tcp/30333/ws --listen-addr /ip6/[::]/tcp/30333/ws. This must be done on before the -- that separates the collator CLI options from the relay chain options, if there is any.

This is necessary, because we would like to connect to the collator from substrate-connect, which runs in the browser. Browsers only allow webpages to open WebSocket connections, meaning that the node we want to connect to needs to listen for WebSocket connections.

[ns212]

@wirednkod Thanks for the clarification. The chainspec files are updated and include 2 nodes (both ipv4 & ipv6) with websocket p2p ports. Please check on your end if this setup works.

[tomaka]

Hey,

https://interlay-public.ams3.digitaloceanspaces.com/staging-latest-parachain-1.7.4.json

~~When connecting to the bootnodes in this chain spec, I'm getting a genesis block hash mismatch between the bootnodes and the chain spec. In other words, what is under raw doesn't match what the chain spec of the bootnodes have under raw.~~

EDIT: sorry, my bad. The bootnodes are actually fine, it's just that there seems to be many nodes connected to the peer-to-peer network of your parachain but that don't actually belong there.

[tomaka]

From my investigation, it seems that everything is working more or less fine, you just need to wait a very long time (several minutes) for smoldot to finish syncing the relay chain.

The problem is that the relay chain has a new session every 10 blocks. Compare this for example to Polkadot, where there's a session every 2400 blocks. The block at every session change needs to be verified by smoldot, so in total this takes a lot of time.

One way to mitigate this would be to generate a checkpoint of the relay chain by calling the sync_state_genSyncSpec RPC call. See this script for example. This will generate a chain spec that contains the current finalized block, meaning that you will start syncing from that block and not from genesis.

[bernardoaraujor]

@ns212 any updates?

[nud3l]

From my investigation, it seems that everything is working more or less fine, you just need to wait a very long time (several minutes) for smoldot to finish syncing the relay chain.

The problem is that the relay chain has a new session every 10 blocks. Compare this for example to Polkadot, where there's a session every 2400 blocks. The block at every session change needs to be verified by smoldot, so in total this takes a lot of time.

One way to mitigate this would be to generate a checkpoint of the relay chain by calling the sync_state_genSyncSpec RPC call. See this script for example. This will generate a chain spec that contains the current finalized block, meaning that you will start syncing from that block and not from genesis.

Does smoldot have to verify both the relay and the parachain state on the session change or is that only required for the relaychain?

[ns212]

@tomaka @bernardoaraujor this is the chain spec generated by the script https://interlay-public.ams3.digitaloceanspaces.com/rococo-local-0.9.16-syncspec.json

[tomaka]

Does smoldot have to verify both the relay and the parachain state on the session change or is that only required for the relaychain?

The parachain state is always simply downloaded from the relay chain. Smoldot doesn't verify anything regarding the parachain.