Testnet chainspec for Light Client Demo about interbtc HOT 12 CLOSED

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

from interbtc.

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

from interbtc.

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

from interbtc.

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.

from interbtc.

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

from interbtc.

@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.

from interbtc.

@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.

from interbtc.

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.

from interbtc.

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.

from interbtc.

@ns212 any updates?

from interbtc.

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?

from interbtc.

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.

from interbtc.