Store parachain bootnodes in relay chain DHT #8

tomaka · 2023-07-14T10:04:49Z

text/0008-parachain-bootnodes-dht.md

Co-authored-by: asynchronous rob <rphmeier@gmail.com>

tomaka · 2023-07-17T12:00:50Z

I've found a pretty big issue with this proposal, which is that the storageTrieRootHash value that can be queried can't be trusted, and thus that the genesis hash of the chain can't be trusted.

I initially just wanted to add a note in the RFC saying that the calculated genesis hash must not be used for purposes other than determining the networking protocol names.
Unfortunately, the JSON-RPC API has functions to query the genesis hash, and so if a light client connects to a parachain in a chain-spec-less way (through just a relay chain and para_id), it has no way to implement the JSON-RPC API properly.

As a side note, if you connect in a chain-spec-less way the JSON-RPC API can't be fully implemented anyway, as the chainSpec_unstable_properties and chainSpec_unstable_chainName functions can't be implemented. But that's already covered by the JSON-RPC spec, which allows some namespaces to not be implemented. In this case, you wouldn't implement the functions in the chainSpec namespace.

We can maybe simply remove the JSON-RPC functions that allow querying the genesis hash, except that when you submit a transaction you need to include the genesis hash in it.

I can see two ways of solving this problem, I'm not sure right now which way is best:

Give up for now on the idea of connecting to a parachain without a chain spec. Remove the stateTrieRootHash and forkId field from the new networking protocol, as they would be loaded from the chain spec. The RFC would simply make it possible to find the bootnodes of a parachain, but not to connect to said parachain without a chain spec.
Double down on the idea of connecting to a parachain without a chain spec, by removing the JSON-RPC functions that allow knowing the genesis hash, and instead JSON-RPC clients should read System::BlockHash[0] (or alternatively introduce a new item in the runtime) in order to know the genesis hash. Given that the runtime verifies the genesis hash when submitting a transaction, we know that this genesis hash is always available in storage and just needs to be queried in a way or the other.

tomaka · 2023-07-17T13:56:34Z

I ended up going for the first option, but I have also opened paritytech/json-rpc-interface-spec#61 in order to make it future-proof.

rphmeier · 2023-07-18T18:13:23Z

Give up for now on the idea of connecting to a parachain without a chain spec. Remove the stateTrieRootHash and forkId field from the new networking protocol, as they would be loaded from the chain spec. The RFC would simply make it possible to find the bootnodes of a parachain, but not to connect to said parachain without a chain spec.

It seems that light clients will always need some form of chain spec, but that it only needs a few piecse of information:

Para-ID
Genesis Hash
Fork ID

Given the weakly synchronous model it would also make sense for light clients to have additional information such as a recent (~1 month) finalized block hash, for maximum deterrence of long range attacks.

tomaka · 2023-07-19T06:12:57Z

It seems that light clients will always need some form of chain spec, but that it only needs a few piecse of information:

Para-ID
Genesis Hash
Fork ID

Also needed is the properties field (which PolkadotJS uses to know the token name and number of decimals (I've always thought that this should be moved on chain)).

Given the weakly synchronous model it would also make sense for light clients to have additional information such as a recent (~1 month) finalized block hash, for maximum deterrence of long range attacks.

I don't understand why? Isn't it enough to look into the relay chain which parablock is finalized?

gavofyork · 2023-07-21T15:05:29Z

Properties could definitely be placed in on-chain metadata. Para ID could too, no?

tomaka · 2023-07-22T13:31:51Z

Para ID could too, no?

The light client looks into the relay chain (and thus needs to know the para ID) in order to know which of the parachain blocks is canonical.
But if we put the para ID on chain, then in order to read the para ID from the storage, the light client first needs to known which parachain block is canonical.
In other words it's a chicken and egg problem.

rphmeier · 2023-07-28T17:32:27Z

I don't understand why? Isn't it enough to look into the relay chain which parablock is finalized?

Technically, validator sets can "go back in time" after their stake is withdrawn and create an alternative chain. This puts an expiration date on finality's trustworthiness, and is the case in all PoS blockchains.

Most of the time this is not a problem in practice, but in theory the correct thing to do is make sure that the node has some reference block for finality (which it either gets by synchronizing at least once every month, or has hardcoded in its chain spec).

Earlier I said it'd be a parachain block hash, but it could just as well be a relay chain block hash to use as a starting point for finality.

I suppose we can agree that light clients need some minimal chain spec?

Para ID
Genesis Hash
Relay Chain Spec
Properties (could be moved on-chain for later)
Finalized relay-chain block hash (nice-to-have)

tomaka · 2023-07-31T07:48:46Z

Earlier I said it'd be a parachain block hash, but it could just as well be a relay chain block hash to use as a starting point for finality.

That's what I'm currently going for in smoldot. It seems easier to me to update the relay chain specification with an up-to-date block from time to time, rather than update the chain specs of every parachains.

Substrate-connect hardcodes the 4 relay chains (Polkadot, Kusama, Westend, Rococo), and is meant to publish a new version at a regular interval containing an up-to-date chain spec for these four relay chains (although the publishing doesn't always happen in practice because it's currently a semi-manual process and the maintainers forget). With this solution, dApps/uApps don't need to deal with this problem.

I suppose we can agree that light clients need some minimal chain spec?
* Para ID

* Genesis Hash

* Relay Chain Spec

* Properties (could be moved on-chain for later)

* Finalized relay-chain block hash (nice-to-have)

The finalized relay chain block hash would be contained the relay chain spec, and you're missing the forkId, but otherwise yes.

bkchr · 2023-08-18T19:59:54Z

Could we not store the genesis_hash in the response as well? We only need it to connect to the networking protocols. The genesis_hash is case of FRAME is stored on chain and we can fetch it from there and ensure that it is the one we got in the initial response.

tomaka · 2023-08-19T07:59:09Z

Could we not store the genesis_hash in the response as well? We only need it to connect to the networking protocols. The genesis_hash is case of FRAME is stored on chain and we can fetch it from there and ensure that it is the one we got in the initial response.

What you suggest is correct, but in practice it's very complicated to implement.

The problem is: what to do if multiple parachain bootnodes return multiple different genesis_hashes?
It is in principle possible to write code so that it uses a separate networking protocol name for each parachain bootnode, which avoids the problem, but that's pretty complicated.

The way I was going with this RFC is to start with a minimal version, and then maybe add the genesis_hash and fork_id to the response later, but I'm not super confident in that decision and we could indeed maybe just add them now even if smoldot isn't capable of making use of them just yet.

tomaka · 2023-08-19T08:07:44Z

Also, while the genesis_hash can be verified at some point, the fork_id can't.

This means that it's possible for multiple different parachain bootnodes to return multiple different fork_ids, and to all be successfully reachable through their own individual fork_id.
This complicates the code, but isn't a problem by itself. What is a problem, however, is which fork_id do you use when you discover the other parachain nodes through Kademlia? The answer is obviously to use the same fork_id as the node that was queried, but since the same node can be discovered multiple times, that means that the same node can have multiple different fork_ids, and it basically becomes a mess.

tomaka · 2023-08-22T09:16:43Z

I've pushed another commit that adds back genesis_hash and fork_id, as the cost of adding them seems minimal to me, and adding them now removes the cost of going through another RFC and implementation+upgrade phase in the future (in particular, parachain builders can be pretty slow to upgrade their Substrate version).

I would like to submit this for voting, but there's still the unresolved question of what to do when it comes to obtaining randomness. Should we use the BabeApi_currentEpoch and BabeApi_nextEpoch runtime APIs (and later their Sassafras equivalents), as the RFC proposes? Or should it be separate new functions?

rphmeier · 2023-09-01T21:28:37Z

I would 'aye' this in its current state

tomaka · 2023-09-04T06:20:16Z

/rfc-propose

github-actions · 2023-09-04T06:20:34Z

Hey @tomaka, here is a link you can use to create the referendum aiming to approve this RFC number 0008.

Instructions

Open the link.
Switch to the Submission tab.

Adjust the transaction if needed (for example, the proposal Origin).
Submit the Transaction

It is based on commit hash d8298f6dbd96da490047e27634e89cc2a87f7251.

The proposed remark text is: RFC_APPROVE(0008,6978a0b277edba30e5c5a8d955554d842eede08cb180fea640dc7bf9b46f982c).

tomaka · 2023-09-04T06:24:32Z

I can't seem to be able to create a referendum ("bad origin" error), guessing it's because I'm not in the fellowship.

tomaka · 2023-09-08T06:16:26Z

I wouldn't mind some help or guidance with this administrative process

tomaka · 2023-10-16T06:58:42Z

/rfc process 0x56bfa1b49e69991617d8aed0c880101f5506e0595b06a6b97b9d5a6cc014b264

github-actions · 2023-10-16T06:58:56Z

@tomaka Handling the RFC command failed :( You can open an issue here.

rzadp · 2023-10-16T08:23:12Z

/rfc process 0x56bfa1b49e69991617d8aed0c880101f5506e0595b06a6b97b9d5a6cc014b264

github-actions · 2023-10-16T08:23:26Z

@rzadp Handling the RFC command failed :( You can open an issue here.

tomaka · 2023-10-16T21:34:00Z

/rfc process 0x56bfa1b49e69991617d8aed0c880101f5506e0595b06a6b97b9d5a6cc014b264

github-actions · 2023-10-16T21:34:28Z

The on-chain referendum has approved the RFC, however I was not able to merge the PR automatically.

rzadp · 2023-10-17T07:27:08Z

The on-chain referendum has approved the RFC, however I was not able to merge the PR automatically.

The bot seems to be missing permissions to merge the PR, although I cannot find out what exactly is missing and what needs to be changed. There were no changes to the bot since the last time it merged a PR.

rzadp · 2023-10-17T13:46:07Z

/rfc process 0x56bfa1b49e69991617d8aed0c880101f5506e0595b06a6b97b9d5a6cc014b264

github-actions · 2023-10-17T13:46:23Z

The on-chain referendum has approved the RFC, however I was not able to merge the PR automatically.

rzadp · 2023-10-23T12:59:23Z

/rfc process 0x56bfa1b49e69991617d8aed0c880101f5506e0595b06a6b97b9d5a6cc014b264

bkchr · 2023-10-23T13:19:14Z

/rfc process 0x56bfa1b49e69991617d8aed0c880101f5506e0595b06a6b97b9d5a6cc014b264

paritytech-rfc-bot · 2023-10-23T13:19:33Z

The on-chain referendum has approved the RFC, however I was not able to merge the PR automatically.

bkchr · 2023-10-23T18:20:42Z

/rfc process 0x56bfa1b49e69991617d8aed0c880101f5506e0595b06a6b97b9d5a6cc014b264

paritytech-rfc-bot · 2023-10-23T18:21:04Z

The on-chain referendum has approved the RFC, however I was not able to merge the PR automatically.

paritytech-rfc-bot · 2023-10-23T19:05:48Z

The on-chain referendum has approved the RFC, however I was not able to merge the PR automatically.

rzadp · 2023-10-24T12:29:09Z

/rfc process 0x39fbc57d047c71f553aa42824599a7686aea5c9aab4111f6b836d35d3d058162

paritytech-rfc-bot · 2023-10-24T12:29:29Z

Unable to find the referendum confirm event in the given block.

Instructions to find the block hash

Here is one way to find the corresponding block hash.

Open the referendum on Subsquare.
Switch to the Timeline tab.

Go to the details of the Confirmed event.

Go to the details of the block containing that event.

Here you can find the block hash.

rzadp · 2023-10-24T12:30:10Z

/rfc process 0x56bfa1b49e69991617d8aed0c880101f5506e0595b06a6b97b9d5a6cc014b264

paritytech-rfc-bot · 2023-10-24T12:30:27Z

The on-chain referendum has approved the RFC.

anaelleltd · 2024-09-16T02:24:10Z

@tomaka, do you have an update on the status of this RFC?
Is somebody working on its implementation?
Thanks.

tomaka · 2024-09-16T10:12:36Z

See paritytech/polkadot-sdk#1825

tomaka added 3 commits July 14, 2023 12:04

Store parachain bootnodes in relay chain DHT

98f2ff2

Small tweaks

1b40c30

Add sentence about chain spec variants

7991576

tomaka mentioned this pull request Jul 14, 2023

Allow resolving bootnodes through WebTorrent or IPFS smol-dot/smoldot#324

Open

rphmeier reviewed Jul 15, 2023

View reviewed changes

text/0008-parachain-bootnodes-dht.md Outdated Show resolved Hide resolved

rphmeier reviewed Jul 15, 2023

View reviewed changes

text/0008-parachain-bootnodes-dht.md Outdated Show resolved Hide resolved

rphmeier reviewed Jul 15, 2023

View reviewed changes

text/0008-parachain-bootnodes-dht.md Outdated Show resolved Hide resolved

Apply suggestions from code review

c0634da

Co-authored-by: asynchronous rob <rphmeier@gmail.com>

Remove the state root and forkId fields

50be350

tomaka mentioned this pull request Jul 17, 2023

Remove chainHead_unstable_genesisHash paritytech/json-rpc-interface-spec#61

Merged

Provide the fields anyway

d3ab94a

Comment on genesis hash

6dd5b08

Merge remote-tracking branch 'upstream/main' into rfc-8

d8298f6

tomaka mentioned this pull request Oct 16, 2023

"Handling the RFC command failed :(" paritytech/rfc-action#19

Closed

paritytech-rfc-bot bot merged commit 7adef29 into polkadot-fellows:main Oct 24, 2023

tomaka deleted the rfc-8 branch October 24, 2023 13:16

tomaka mentioned this pull request Dec 18, 2023

Announce "capabilities" over the network? paritytech/polkadot-sdk#523

Open

josepot mentioned this pull request Apr 19, 2024

🎉 Wishlist: Users paritytech/polkadot-sdk#3901

Open

eskimor mentioned this pull request Jun 10, 2024

DRAFT: offchain XCMP: Understanding Requirements paritytech/polkadot-sdk#4750

Open

anaelleltd added the Approved Has passed on-chain voting. label Sep 10, 2024

tomaka mentioned this pull request Sep 16, 2024

Add a discovery mechanism for nodes based on their capabilities #59

Merged

josepot mentioned this pull request Oct 3, 2024

client.getChainSpecData doesn't give the same SS58prefix as the constant System.SS58prefix on Paseo polkadot-api/polkadot-api#767

Closed

Store parachain bootnodes in relay chain DHT #8

Store parachain bootnodes in relay chain DHT #8

Conversation

tomaka commented Jul 14, 2023 • edited by Bullrich Loading

tomaka commented Jul 17, 2023 • edited Loading

tomaka commented Jul 17, 2023

rphmeier commented Jul 18, 2023

tomaka commented Jul 19, 2023 • edited Loading

gavofyork commented Jul 21, 2023 • edited Loading

tomaka commented Jul 22, 2023

rphmeier commented Jul 28, 2023 • edited Loading

tomaka commented Jul 31, 2023 • edited Loading

bkchr commented Aug 18, 2023

tomaka commented Aug 19, 2023 • edited Loading

tomaka commented Aug 19, 2023

tomaka commented Aug 22, 2023 • edited Loading

rphmeier commented Sep 1, 2023

tomaka commented Sep 4, 2023

github-actions bot commented Sep 4, 2023

tomaka commented Sep 4, 2023 • edited Loading

tomaka commented Sep 8, 2023

tomaka commented Oct 16, 2023

github-actions bot commented Oct 16, 2023

rzadp commented Oct 16, 2023

github-actions bot commented Oct 16, 2023

tomaka commented Oct 16, 2023

github-actions bot commented Oct 16, 2023

rzadp commented Oct 17, 2023

rzadp commented Oct 17, 2023

github-actions bot commented Oct 17, 2023

rzadp commented Oct 23, 2023

bkchr commented Oct 23, 2023

paritytech-rfc-bot bot commented Oct 23, 2023

bkchr commented Oct 23, 2023

paritytech-rfc-bot bot commented Oct 23, 2023

paritytech-rfc-bot bot commented Oct 23, 2023

rzadp commented Oct 24, 2023

paritytech-rfc-bot bot commented Oct 24, 2023

rzadp commented Oct 24, 2023

paritytech-rfc-bot bot commented Oct 24, 2023

anaelleltd commented Sep 16, 2024

tomaka commented Sep 16, 2024

tomaka commented Jul 14, 2023 •

edited by Bullrich

Loading

tomaka commented Jul 17, 2023 •

edited

Loading

tomaka commented Jul 19, 2023 •

edited

Loading

gavofyork commented Jul 21, 2023 •

edited

Loading

rphmeier commented Jul 28, 2023 •

edited

Loading

tomaka commented Jul 31, 2023 •

edited

Loading

tomaka commented Aug 19, 2023 •

edited

Loading

tomaka commented Aug 22, 2023 •

edited

Loading

tomaka commented Sep 4, 2023 •

edited

Loading