From 98f2ff23231944b6b9408335fb6ca294f7edfe53 Mon Sep 17 00:00:00 2001 From: Pierre Krieger Date: Fri, 14 Jul 2023 12:04:30 +0200 Subject: [PATCH 1/7] Store parachain bootnodes in relay chain DHT --- text/0008-parachain-bootnodes-dht.md | 146 +++++++++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 text/0008-parachain-bootnodes-dht.md diff --git a/text/0008-parachain-bootnodes-dht.md b/text/0008-parachain-bootnodes-dht.md new file mode 100644 index 000000000..1ea5abdb7 --- /dev/null +++ b/text/0008-parachain-bootnodes-dht.md @@ -0,0 +1,146 @@ +# RFC-0008: Store parachain bootnodes in relay chain DHT + +| | | +| --------------- | ------------------------------------------------------------------------------------------- | +| **Start Date** | 2023-07-14 | +| **Description** | Parachain bootnodes shall register themselves in the DHT of the relay chain | +| **Authors** | Pierre Krieger | + +## Summary + +The full nodes of the Polkadot peer-to-peer network maintain a distributed hash table (DHT), which is currently used for full nodes discovery and validators discovery purposes. + +This RFC proposes to extend this DHT to be used to discover full nodes of the parachains of Polkadot. + +## Motivation + +The maintenance of bootnodes has long been an annoyance for everyone. + +When a bootnode is newly-deployed or removed, every chain specification must be updated in order to take the update into account. This has lead to various non-optimal solutions, such as pulling chain specifications from GitHub repositories. +When it comes to RPC nodes, UX developers often have trouble finding up-to-date addresses of parachain RPC nodes. With the ongoing migration from RPC nodes to light clients, similar problems would happen with chain specifications as well. + +Since the PeerId and addresses of bootnodes needs to be stable, extra maintenance work is required from the chain maintainers. For example, they need to be extra careful when migrating nodes within their infrastructure. In some situations, bootnodes are put behind domain names, which also requires maintenance work. + +Because the list of bootnodes in chain specifications is so annoying to modify, the consequence is that the number of bootnodes is rather low (typically between 2 and 15). In order to better resist downtimes and DoS attacks, a better solution would be to use every node of a certain chain as potential bootnode, rather than special-casing some specific nodes. + +While this RFC doesn't solve these problems for relay chains, it aims at solving it for parachains by storing the list of all the full nodes of a parachain on the relay chain DHT. + +Assuming that this RFC is implemented, and that light clients are used, deploying a parachain wouldn't require more work than registering it onto the relay chain and starting the collators. There wouldn't be any need for special infrastructure nodes anymore. + +## Stakeholders + +This RFC has been opened on my own initiative because I think that this is a good technical solution to a usuability problem that many people are encountering and that they don't realize can be solved. + +## Explanation + +The content of this RFC only applies for parachains and parachain nodes that are "Substrate-compatible". It is in no way mandatory for parachains to comply to this RFC. + +Note that "Substrate-compatible" is very loosely defined as "implements the same mechanisms and networking protocols as Substrate". The author of this RFC believes that "Substrate-compatible" should be very precisely specified, but there is controversy on this topic. + +While a lot of this RFC concerns the implementation of parachain nodes, it makes use of the resources of the Polkadot chain, and as such it is important to describe them in the Polkadot specification. + +This RFC adds two mechanisms: a registration in the DHT, and a new networking protocol. + +### DHT provider registration + +This RFC heavily relies on the functionnalities of the Kademlia DHT already in use by Polkadot. +You can find a link to the specification [here](https://github.com/libp2p/specs/tree/master/kad-dht). + +Full nodes of a parachain registered on Polkadot should register themselves onto the Polkadot DHT as the providers of a key corresponding to the parachain that they are serving, as described in [the `Content provider advertisement` section](https://github.com/libp2p/specs/tree/master/kad-dht#content-provider-advertisement) of the specification. This uses the `ADD_PROVIDER` system of libp2p-kademlia. + +This key is: `sha256(concat(scale_compact(para_id), randomness))` where the value of `randomness` can be found in the `randomness` field when calling the `BabeApi_currentEpoch` function. +For example, for a `para_id` equal to 1000, and at the time of writing of this RFC (July 14th 2023 at 09:13 UTC), it is `sha(0xa10f12872447958d50aa7b937b0106561a588e0e2628d33f81b5361b13dbcf8df708)`, which is equal to `0x483dd8084d50dbbbc962067f216c37b627831d9339f5a6e426a32e3076313d87`. + +In order to avoid downtimes when the key changes, parachain full nodes should also register themselves as a secondary key that uses a value of `randomness` equal to the `randomness` field when calling `BabeApi_nextEpoch`. + +Implementers should be aware that their implementation of Kademlia might already hash the key before XOR'ing it. The key is not meant to be hashed twice. + +The compact SCALE encoding has been chosen in order to avoid problems related to the number of bytes and endianness of the `para_id`. + +### New networking protocol + +A new request-response protocol should be added, whose name is `/91b171bb158e2d3848fa23a9f1c25182fb8e20313b2c1eb49219da7a70ce90c3/paranode` (that hexadecimal number is the genesis hash of the Polkadot chain, and should be adjusted appropriately for Kusama and others). + +The request consists in a SCALE-compact-encoded `para_id`. For example, for a `para_id` equal to 1000, this is `0xa10f`. + +Note that because this is a request-response protocol, the request is always prefixed with its length in bytes. While the body of the request is simply the SCALE-compact-encoded `para_id`, the data actually sent onto the substream is both the length and body. + +The response consists in a protobuf struct, defined as: + +``` +syntax = "proto2"; + +message Response { + // Peer ID of the node on the parachain side. + bytes peer_id = 1; + + // Multiaddresses of the parachain side of the node. The list and format are the same as for the `listenAddrs` field of the `identify` protocol. + repeated bytes addrs = 2; + + // Hash of the root node of the trie of the parachain. + bytes storageTrieRootHash = 3; + + // So-called "forkId" of the parachain, which can be found in its chain specification. This must be taken into account when constructing the protocol names used by the parachain. + optional string forkId = 4; +}; +``` + +The `storageTrieRootHash` and `forkId` fields can be used in order to calculate the genesis hash of the parachain, which is necessary in order to determine the names of the protocols used by the networking of the parachain. + +The maximum size of a response is set to an arbitrary 16kiB. The responding side should make sure to conform to this limit. Given that the only variable-length fields are `addrs` and `forkId`, and that `forkId` is normally very small, this is easily achieved by limiting the number of `addrs`. + +Implementers should be aware that `addrs` might be very large, and are encouraged to limit the number of `addrs` to an implementation-defined value. + +## Drawbacks + +The `peer_id` and `addrs` fields are in theory not strictly needed, as they could be always equal to the PeerId and addresses of the node being registered as the provider and serving the response. However, the Cumulus implementation currently uses two different networking stacks, one of the parachain and one for the relay chain, using two separate PeerIds and addresses, and as such the PeerId and addresses of the other networking stack must be indicated. Asking them to use only one networking stack wouldn't feasible in a realistic time frame. + +## Testing, Security, and Privacy + +Because not all nodes might not want to be used as bootnodes, implementers are encouraged to provide a way to disable this mechanism. However, it is very much encouraged to leave this mechanism on by default for all nodes. + +This mechanism doesn't add or remove any security by itself, as it relies on existing mechanisms. +However, if the principle of chain specification bootnodes is entirely replaced with the mechanism described in this RFC (which is the objective), then it becomes important whether the mechanism in this RFC can be abused in order to make a parachain unreachable. + +Due to the way Kademlia works, it would become the responsibility of the 20 Polkadot nodes whose `sha256(peer_id)` is closest to the `key` (described in the explanations section) to store the list of bootnodes of each parachain. +Furthermore, when a large number of providers (here, a provider is a bootnode) are registered, only the providers closest to the `key` are kept, up to a certain implementation-defined limit. + +For this reason, an attacker can abuse this mechanism by randomly generating libp2p PeerIds until they find the 20 entries closest to the `key` representing the target parachain. They are then in control of the parachain bootnodes. +Because the key changes periodically and isn't predictable, and assuming that the Polkadot DHT is sufficiently large, it is not realistic for an attack like this to be maintained in the long term. + +Furthermore, parachain clients are expected to cache a list of known good nodes on their disk. If the mechanism described in this RFC went down, it would only prevent new nodes from accessing the parachain, while clients that have connected before would not be affected. + +## Performance, Ergonomics, and Compatibility + +### Performance + +The DHT mechanism generally has a low overhead, especially given that publishing providers is done only every 24 hours. + +Doing a Kademlia iterative query then sending a provider record shouldn't take more than 5 kiB in total for the parachain bootnode. + +Assuming 1000 parachain full nodes, the 20 Polkadot full nodes corresponding to a specific parachain will each receive a sudden spike of a few megabytes of networking traffic when the `key` rotates. Again, this is relatively negligible. If this becomes a problem, one can add a random delay before a parachain full node registers itself to be the provider of the `key` corresponding to `BabeApi_next_epoch`. + +Maybe the biggest uncertainty is the traffic that the 20 Polkadot full nodes will receive from light clients that desire knowing the bootnodes of a parachain. Light clients are generally encouraged to cache the peers that they use between restarts, so they should only query these 20 Polkadot full nodes at their first initialization. +If this every becomes a problem, this value of 20 is an arbitrary constant that can be increased for more redundancy. + +### Ergonomics + +Irrelevant. + +### Compatibility + +Irrelevant. + +## Prior Art and References + +None. + +## Unresolved Questions + +While it fundamentally doesn't change much to this RFC, using `BabeApi_currentEpoch` and `BabeApi_nextEpoch` might be inappropriate. I'm not familiar enough with good practices within the runtime to have an opinion here. Should it be an entirely new pallet? + +## Future Directions and Related Material + +An alternative form of the protocol added by this RFC could be to return the entire genesis state. This hasn't been added in this RFC because it isn't clear whether this would actually be useful. I would be against adding such a mechanism just because we can. + +While the body of the request in the networking protocol in this RFC isn't easily extensible, it is easy to add other networking protocols (and in fact, adding parameters to requests like is the case for many of the existing networking protocols is an anti-pattern). From 1b40c30be25bb1be3cac5fe55501b55f71eea626 Mon Sep 17 00:00:00 2001 From: Pierre Krieger Date: Fri, 14 Jul 2023 12:11:20 +0200 Subject: [PATCH 2/7] Small tweaks --- text/0008-parachain-bootnodes-dht.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0008-parachain-bootnodes-dht.md b/text/0008-parachain-bootnodes-dht.md index 1ea5abdb7..480c3b834 100644 --- a/text/0008-parachain-bootnodes-dht.md +++ b/text/0008-parachain-bootnodes-dht.md @@ -97,7 +97,7 @@ The `peer_id` and `addrs` fields are in theory not strictly needed, as they coul ## Testing, Security, and Privacy -Because not all nodes might not want to be used as bootnodes, implementers are encouraged to provide a way to disable this mechanism. However, it is very much encouraged to leave this mechanism on by default for all nodes. +Because not all nodes want to be used as bootnodes, implementers are encouraged to provide a way to disable this mechanism. However, it is very much encouraged to leave this mechanism on by default for all parachain nodes. This mechanism doesn't add or remove any security by itself, as it relies on existing mechanisms. However, if the principle of chain specification bootnodes is entirely replaced with the mechanism described in this RFC (which is the objective), then it becomes important whether the mechanism in this RFC can be abused in order to make a parachain unreachable. @@ -116,7 +116,7 @@ Furthermore, parachain clients are expected to cache a list of known good nodes The DHT mechanism generally has a low overhead, especially given that publishing providers is done only every 24 hours. -Doing a Kademlia iterative query then sending a provider record shouldn't take more than 5 kiB in total for the parachain bootnode. +Doing a Kademlia iterative query then sending a provider record shouldn't take more than around 50 kiB in total of bandwidth for the parachain bootnode. Assuming 1000 parachain full nodes, the 20 Polkadot full nodes corresponding to a specific parachain will each receive a sudden spike of a few megabytes of networking traffic when the `key` rotates. Again, this is relatively negligible. If this becomes a problem, one can add a random delay before a parachain full node registers itself to be the provider of the `key` corresponding to `BabeApi_next_epoch`. @@ -141,6 +141,6 @@ While it fundamentally doesn't change much to this RFC, using `BabeApi_currentEp ## Future Directions and Related Material -An alternative form of the protocol added by this RFC could be to return the entire genesis state. This hasn't been added in this RFC because it isn't clear whether this would actually be useful. I would be against adding such a mechanism just because we can. +An alternative form of the protocol added by this RFC could be to return the entire genesis state. This hasn't been added in this RFC because it isn't clear whether this would actually be useful. I would be against adding such a mechanism "just because we can". While the body of the request in the networking protocol in this RFC isn't easily extensible, it is easy to add other networking protocols (and in fact, adding parameters to requests like is the case for many of the existing networking protocols is an anti-pattern). From 799157679f8f46e5f9dae53d4dcc408c4fe6159a Mon Sep 17 00:00:00 2001 From: Pierre Krieger Date: Fri, 14 Jul 2023 17:20:44 +0200 Subject: [PATCH 3/7] Add sentence about chain spec variants --- text/0008-parachain-bootnodes-dht.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/text/0008-parachain-bootnodes-dht.md b/text/0008-parachain-bootnodes-dht.md index 480c3b834..06c96cc35 100644 --- a/text/0008-parachain-bootnodes-dht.md +++ b/text/0008-parachain-bootnodes-dht.md @@ -19,6 +19,8 @@ The maintenance of bootnodes has long been an annoyance for everyone. When a bootnode is newly-deployed or removed, every chain specification must be updated in order to take the update into account. This has lead to various non-optimal solutions, such as pulling chain specifications from GitHub repositories. When it comes to RPC nodes, UX developers often have trouble finding up-to-date addresses of parachain RPC nodes. With the ongoing migration from RPC nodes to light clients, similar problems would happen with chain specifications as well. +Furthermore, there exists multiple different possible variants of a certain chain specification: with the non-raw storage, with the raw storage, with just the genesis trie root hash, with or without checkpoint, etc. All of this creates confusion. Removing the need for parachain developers to be aware of and manage these different versions would be beneficial. + Since the PeerId and addresses of bootnodes needs to be stable, extra maintenance work is required from the chain maintainers. For example, they need to be extra careful when migrating nodes within their infrastructure. In some situations, bootnodes are put behind domain names, which also requires maintenance work. Because the list of bootnodes in chain specifications is so annoying to modify, the consequence is that the number of bootnodes is rather low (typically between 2 and 15). In order to better resist downtimes and DoS attacks, a better solution would be to use every node of a certain chain as potential bootnode, rather than special-casing some specific nodes. From c0634dacc7f174d91db54e0a9c38cbefbaadd04d Mon Sep 17 00:00:00 2001 From: Pierre Krieger Date: Sun, 16 Jul 2023 09:05:29 +0000 Subject: [PATCH 4/7] Apply suggestions from code review Co-authored-by: asynchronous rob --- text/0008-parachain-bootnodes-dht.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0008-parachain-bootnodes-dht.md b/text/0008-parachain-bootnodes-dht.md index 06c96cc35..d3fca20c7 100644 --- a/text/0008-parachain-bootnodes-dht.md +++ b/text/0008-parachain-bootnodes-dht.md @@ -31,7 +31,7 @@ Assuming that this RFC is implemented, and that light clients are used, deployin ## Stakeholders -This RFC has been opened on my own initiative because I think that this is a good technical solution to a usuability problem that many people are encountering and that they don't realize can be solved. +This RFC has been opened on my own initiative because I think that this is a good technical solution to a usability problem that many people are encountering and that they don't realize can be solved. ## Explanation @@ -45,7 +45,7 @@ This RFC adds two mechanisms: a registration in the DHT, and a new networking pr ### DHT provider registration -This RFC heavily relies on the functionnalities of the Kademlia DHT already in use by Polkadot. +This RFC heavily relies on the functionalities of the Kademlia DHT already in use by Polkadot. You can find a link to the specification [here](https://github.com/libp2p/specs/tree/master/kad-dht). Full nodes of a parachain registered on Polkadot should register themselves onto the Polkadot DHT as the providers of a key corresponding to the parachain that they are serving, as described in [the `Content provider advertisement` section](https://github.com/libp2p/specs/tree/master/kad-dht#content-provider-advertisement) of the specification. This uses the `ADD_PROVIDER` system of libp2p-kademlia. @@ -53,7 +53,7 @@ Full nodes of a parachain registered on Polkadot should register themselves onto This key is: `sha256(concat(scale_compact(para_id), randomness))` where the value of `randomness` can be found in the `randomness` field when calling the `BabeApi_currentEpoch` function. For example, for a `para_id` equal to 1000, and at the time of writing of this RFC (July 14th 2023 at 09:13 UTC), it is `sha(0xa10f12872447958d50aa7b937b0106561a588e0e2628d33f81b5361b13dbcf8df708)`, which is equal to `0x483dd8084d50dbbbc962067f216c37b627831d9339f5a6e426a32e3076313d87`. -In order to avoid downtimes when the key changes, parachain full nodes should also register themselves as a secondary key that uses a value of `randomness` equal to the `randomness` field when calling `BabeApi_nextEpoch`. +In order to avoid downtime when the key changes, parachain full nodes should also register themselves as a secondary key that uses a value of `randomness` equal to the `randomness` field when calling `BabeApi_nextEpoch`. Implementers should be aware that their implementation of Kademlia might already hash the key before XOR'ing it. The key is not meant to be hashed twice. From 50be350f57486148404e6eee4b23492349994ba6 Mon Sep 17 00:00:00 2001 From: Pierre Krieger Date: Mon, 17 Jul 2023 15:52:00 +0200 Subject: [PATCH 5/7] Remove the state root and forkId fields --- text/0008-parachain-bootnodes-dht.md | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/text/0008-parachain-bootnodes-dht.md b/text/0008-parachain-bootnodes-dht.md index d3fca20c7..dd2ec4f12 100644 --- a/text/0008-parachain-bootnodes-dht.md +++ b/text/0008-parachain-bootnodes-dht.md @@ -78,24 +78,16 @@ message Response { // Multiaddresses of the parachain side of the node. The list and format are the same as for the `listenAddrs` field of the `identify` protocol. repeated bytes addrs = 2; - - // Hash of the root node of the trie of the parachain. - bytes storageTrieRootHash = 3; - - // So-called "forkId" of the parachain, which can be found in its chain specification. This must be taken into account when constructing the protocol names used by the parachain. - optional string forkId = 4; }; ``` -The `storageTrieRootHash` and `forkId` fields can be used in order to calculate the genesis hash of the parachain, which is necessary in order to determine the names of the protocols used by the networking of the parachain. - -The maximum size of a response is set to an arbitrary 16kiB. The responding side should make sure to conform to this limit. Given that the only variable-length fields are `addrs` and `forkId`, and that `forkId` is normally very small, this is easily achieved by limiting the number of `addrs`. +The maximum size of a response is set to an arbitrary 16kiB. The responding side should make sure to conform to this limit. Given that the only variable-length field is `addrs`, this is easily achieved by limiting the number of addresses. Implementers should be aware that `addrs` might be very large, and are encouraged to limit the number of `addrs` to an implementation-defined value. ## Drawbacks -The `peer_id` and `addrs` fields are in theory not strictly needed, as they could be always equal to the PeerId and addresses of the node being registered as the provider and serving the response. However, the Cumulus implementation currently uses two different networking stacks, one of the parachain and one for the relay chain, using two separate PeerIds and addresses, and as such the PeerId and addresses of the other networking stack must be indicated. Asking them to use only one networking stack wouldn't feasible in a realistic time frame. +The new networking protocol is in theory not strictly needed, as the PeerId and addresses could be always equal to the PeerId and addresses of the node being registered as the provider and serving the response. However, the Cumulus implementation currently uses two different networking stacks, one of the parachain and one for the relay chain, using two separate PeerIds and addresses, and as such the PeerId and addresses of the other networking stack must be indicated. Asking them to use only one networking stack wouldn't feasible in a realistic time frame. ## Testing, Security, and Privacy @@ -143,6 +135,6 @@ While it fundamentally doesn't change much to this RFC, using `BabeApi_currentEp ## Future Directions and Related Material -An alternative form of the protocol added by this RFC could be to return the entire genesis state. This hasn't been added in this RFC because it isn't clear whether this would actually be useful. I would be against adding such a mechanism "just because we can". +A previous version of this RFC had extra fields in the networking request that indicated some elements of the chain specification of the parachain, namely the genesis state hash and the `forkId`. Using these extra fields, it would be possible to connect to a parachain from just a `para_id` and without knowing any chain specification for that parachain. -While the body of the request in the networking protocol in this RFC isn't easily extensible, it is easy to add other networking protocols (and in fact, adding parameters to requests like is the case for many of the existing networking protocols is an anti-pattern). +Unfortunately, the correctness of these values in these fields can't be verified by the client willing to connect to the parachain. Furthermore, it is possible for multiple parabootnodes to provide multiple different values for the genesis state hash and `forkId`, making a secure implementation very complicated to write. From d3ab94af9efaf5de03eb07cd191bc6df09922bc5 Mon Sep 17 00:00:00 2001 From: Pierre Krieger Date: Tue, 22 Aug 2023 11:14:16 +0200 Subject: [PATCH 6/7] Provide the fields anyway --- text/0008-parachain-bootnodes-dht.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/text/0008-parachain-bootnodes-dht.md b/text/0008-parachain-bootnodes-dht.md index dd2ec4f12..6ea7e71fe 100644 --- a/text/0008-parachain-bootnodes-dht.md +++ b/text/0008-parachain-bootnodes-dht.md @@ -78,16 +78,24 @@ message Response { // Multiaddresses of the parachain side of the node. The list and format are the same as for the `listenAddrs` field of the `identify` protocol. repeated bytes addrs = 2; + + // Genesis hash of the parachain. Untrusted. + bytes genesis_hash = 3; + + // So-called "fork ID" of the parachain. Used to determine the name of the networking protocol to connect to the parachain. Untrusted. + optional string fork_id = 4; }; ``` -The maximum size of a response is set to an arbitrary 16kiB. The responding side should make sure to conform to this limit. Given that the only variable-length field is `addrs`, this is easily achieved by limiting the number of addresses. +The maximum size of a response is set to an arbitrary 16kiB. The responding side should make sure to conform to this limit. Given that `fork_id` is typically very small and that the only variable-length field is `addrs`, this is easily achieved by limiting the number of addresses. Implementers should be aware that `addrs` might be very large, and are encouraged to limit the number of `addrs` to an implementation-defined value. ## Drawbacks -The new networking protocol is in theory not strictly needed, as the PeerId and addresses could be always equal to the PeerId and addresses of the node being registered as the provider and serving the response. However, the Cumulus implementation currently uses two different networking stacks, one of the parachain and one for the relay chain, using two separate PeerIds and addresses, and as such the PeerId and addresses of the other networking stack must be indicated. Asking them to use only one networking stack wouldn't feasible in a realistic time frame. +The `peer_id` and `addrs` fields are in theory not strictly needed, as the PeerId and addresses could be always equal to the PeerId and addresses of the node being registered as the provider and serving the response. However, the Cumulus implementation currently uses two different networking stacks, one of the parachain and one for the relay chain, using two separate PeerIds and addresses, and as such the PeerId and addresses of the other networking stack must be indicated. Asking them to use only one networking stack wouldn't feasible in a realistic time frame. + +The values of the `genesis_hash` and `fork_id` fields cannot be verified by the requester and are expected to be unused at the moment. Instead, a client that desires connecting to a parachain is expected to obtain the genesis hash and fork ID of the parachain from the parachain chain specification. These fields are included in the networking protocol nonetheless in case an acceptable solution is found in the future, and in order to allow use cases such as discovering parachains in a not-strictly-trusted way. ## Testing, Security, and Privacy @@ -135,6 +143,4 @@ While it fundamentally doesn't change much to this RFC, using `BabeApi_currentEp ## Future Directions and Related Material -A previous version of this RFC had extra fields in the networking request that indicated some elements of the chain specification of the parachain, namely the genesis state hash and the `forkId`. Using these extra fields, it would be possible to connect to a parachain from just a `para_id` and without knowing any chain specification for that parachain. - -Unfortunately, the correctness of these values in these fields can't be verified by the client willing to connect to the parachain. Furthermore, it is possible for multiple parabootnodes to provide multiple different values for the genesis state hash and `forkId`, making a secure implementation very complicated to write. +It is possible that in the future a client could connect to a parachain without having to rely on a trusted parachain specification. From 6dd5b08c911133e7e06c796b2551b8718e3bf752 Mon Sep 17 00:00:00 2001 From: Pierre Krieger Date: Tue, 22 Aug 2023 11:18:14 +0200 Subject: [PATCH 7/7] Comment on genesis hash --- text/0008-parachain-bootnodes-dht.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0008-parachain-bootnodes-dht.md b/text/0008-parachain-bootnodes-dht.md index 6ea7e71fe..aed3869e1 100644 --- a/text/0008-parachain-bootnodes-dht.md +++ b/text/0008-parachain-bootnodes-dht.md @@ -79,7 +79,7 @@ message Response { // Multiaddresses of the parachain side of the node. The list and format are the same as for the `listenAddrs` field of the `identify` protocol. repeated bytes addrs = 2; - // Genesis hash of the parachain. Untrusted. + // Genesis hash of the parachain. Used to determine the name of the networking protocol to connect to the parachain. Untrusted. bytes genesis_hash = 3; // So-called "fork ID" of the parachain. Used to determine the name of the networking protocol to connect to the parachain. Untrusted.