Idea: Replace protocolId with the genesis hash

[tomaka]

At the moment, most networking protocols contain what is called the protocolId, defined in the chain specs.
For example, the syncing protocol of Polkadot is named /dot/sync/2, because Polkadot has protocolId: "dot" in its chain specs.

Instead of using a user-chosen protocolId, we could name the protocol using the hash of the genesis block.
The sync protocol could for example become /91b171bb158e2d3848fa23a9f1c25182fb8e20313b2c1eb49219da7a70ce90c3/sync/2.

The advantage of doing so is that things become "automatic". No need to define your own protocolId anymore, and no need to verify whether the genesis hash is the same between two nodes during the blocks announce handshake.

The drawback is obviously that this is longer than just dot, so more bytes are transmitted on the network. The multistream-select protocol requires protocol names to be string.
To mitigate this, we could use an encoding other than hex encoding of the hash. Using a different encoding might however make things confusing.

This also depends on how we tackle #7458. After #7458, the definition of "genesis block" might become a bit blurry.

[tomaka]

Depends on #6605

[tomaka]

Some remark: using just the genesis hash would make it impossible to do a hard fork.
We should use the combination of the genesis hash and some optional value found in the chain specs.

Adding an extra field also makes it flexible enough to not run into an issue if a chain transitions from standalone to parachain.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[tomaka]

Issue still relevant and important.

[nuke-web3]

I am writing some guides on parachain configuration, and especially in that context, having unique network protocol IDs seems more important, and as you mention, accounting for the possibility of hard forks and changes in paraID and such.

We have seen solo-chains run into improper discovery & attempted peering because of this, and my hunch at least is in a common-relay chain context, this will be exacerbated.

[acatangiu]

At the network level, when looking at scale wouldn't it be expensive to string match against such a long protocol id?

Would protocolId + truncatedGenesisHash like /dot/91b171bb1/sync/2 also work?

[tomaka]

There's no need to truncate. We don't care about the performance of comparing strings of 50 bytes.

[acatangiu]

Done in #10463

[tomaka]

This was done for Grandpa/Beefy, but not for the syncing and transactions protocols.

[tomaka]

One last thing to do is change the Kademlia protocol name:

substrate/client/network/src/discovery.rs

Line 202 in c76c40a

config.set_protocol_name(proto_name);

Unfortunately, this is maybe more complicated, because libp2p doesn't allow setting backwards compatible names for this protocol.

[bkchr]

One last thing to do is change the Kademlia protocol name:

substrate/client/network/src/discovery.rs

Line 202 in c76c40a

config.set_protocol_name(proto_name);

Unfortunately, this is maybe more complicated, because libp2p doesn't allow setting backwards compatible names for this protocol.

@dmitry-markin could you check with upstream if adding support for backwards compatible names would be accepted? If yes, could you please do this.

[dmitry-markin]

@dmitry-markin could you check with upstream if adding support for backwards compatible names would be accepted? If yes, could you please do this.

Done in libp2p/rust-libp2p#2846.

[bkchr]

@dmitry-markin could you check with upstream if adding support for backwards compatible names would be accepted? If yes, could you please do this.

Done in libp2p/rust-libp2p#2846.

Nice! So we will be able to close this with the next libp2p update.

[mxinden]

with the next libp2p update

For the protocol: libp2p/rust-libp2p#2869

[bkchr]

@dmitry-markin please keep track on this and when it is released, please update libp2p. :)