Fork-friendly chain identifiers

[danfinlay]

I'd like to highlight an issue with the current CAIP-2 chain identification format. There may be room for another such chain identification schema to be created, possibly as a CAIP-2 compatible extension (via a new prefix).

The issue is that the current schema treats chains as singletons, but without appreciation for the possibility of forks. The power of hard fork is an incredibly powerful social tool that is only present if the tooling all the way up and down the stack allows users to easily participate in exercising their own fork preference.

The current schema, for example, ensures that by encoding ethereum as eip155:1, if there is any contentious hard-fork on ethereum, it is unclear what identifier would apply to which end of the fork, and this can result in a variety of issues:

• Failure in replay-protection strategies for any layer-2 strategies that rely on this schema.
• Creation of increasing ambiguity around any chain or account reference.

There are many other reasons to make fork-friendly software, and I think I put off writing this post in part because I never felt ready to make the full case, and here I will just accept that I have not made the full case, but instead claim that this is valuable, and if you disagree then I or others can continue to explain why. I'm not sure if it's a contentious point.

Historically chain_id assignment has gone to the stronger chain claims the prior identifier, and the smaller chain then hard-forks to give itself replay protection, but maybe we could design a solution that does not require squatting identifiers, but instead identifies chains by their ongoing uniqueness?

I don't have a simple solution to this, but I have seen approaches, and so I'd like to start this thread to discuss possible fork-friendly chain identifiers: Chain identifiers that can retain as much specificity as possible in a fork-tolerant world.

An example of this I've seen is the truffle blockchain-utils library, which proposed an ethereum-chain identifying schema that identifies a chain by both its genesis block and a later block, like: blockchain://<genesis hash>/block/<latest block at uri creation> (Credit to @timcoulter)

A limitation of this strategy is that a parser needs to be aware of any block that may be used as <latest block at uri creation>, but I could imagine an optimized version where the second block-hash referenced is the block after a contentious fork.

Anyways, looking forward to seeing how others might imagine identifying chains in fork-tolerant architecture.

[ligi]

great Idea @danfinlay - wonder if we can leverage forkid (EIP 2124) here

[tjayrush]

I'll just toss in an idea. You don't really need the genesis block. The hash of the first block after the fork is sufficient to identify any chain. If you re-imagine the genesis block as being the first block after a hard fork from nothingness, then you can identify any chain by the first block after any hard fork. So, blockchain://<hash_of_first_block_after_most_recent_hard_fork>

[pedrouid]

I agree that we should take fork-friendliness into consideration. However I don't think this is fixed by changing anything on the CAIP-2 specification.

A chain can be defined with many namespaces and therefore many chainId's

Currently Ethereum chains have a single namespace which is eip155 integers. These are not fork-friendly therefore favor majority chains to keep the pre-fork eip155 integer.

Yet this is not an issue with the Cosmos chains which their chainId's are fork-friendly already. So the CAIP-2 provides the fork-friendliness for these chains on this namespace.

Hence what we should consider is fork-friendly namespaces for Ethereum chains and create a chainId for that namespace

[danfinlay]

That sounds good!

So sounds like what we'd want is just:

• An ethereum chain identifier that is fork-friendly
• Probably identified by a post-fork block, but could also take inspiration from Cosmos chains.

Any links to the cosmos chainIds you're referring to, @pedrouid? Would love to learn more about that.

[ntn-x2]

Hi guys. Just pinging here to know the status of this issue. It is particularly important in the context of CAIP-19 identifiers, where an NFT (especially EVM-based) might only require to be identified on a specific chain.

[bumblefudge]

I agree that we should take fork-friendliness into consideration. However I don't think this is fixed by changing anything on the CAIP-2 specification.

A chain can be defined with many namespaces and therefore many chainId's

Currently Ethereum chains have a single namespace which is eip155 integers. These are not fork-friendly therefore favor majority chains to keep the pre-fork eip155 integer.

Yet this is not an issue with the Cosmos chains which their chainId's are fork-friendly already. So the CAIP-2 provides the fork-friendliness for these chains on this namespace.

Hence what we should consider is fork-friendly namespaces for Ethereum chains and create a chainId for that namespace

The takeaway here, I think, is that each namespace can define its CAIP-2 system as genesis-hash-based or not based on the network identifier(s) available to it in a territory it defines. It follows logically that one [EVM, for example,] "blockchain" or network of nodes could be referred to by one or more CAIP-2 identifiers in one namespace (say, by EVM chainId) but ALSO be referred to by genesis hash in another namespace, whose identifier scheme is based on genesis hashes and for whom an EVM chain is a valid referent, and a third namespace whose identifier sheme is based on RPC endpoints which that chain's endpoints qualify for.

Maybe @danfinlay 's 2020 request for examples are easier to answer now that there are so many multi-namespace networks. an EVM-compatible layer two could answer to execution-api requests when identified by its eip155 chainId, and also respond to Cosmos, Polkadot, Hedera, etc RPC methods when connected to via that other namespace's identifier scheme and resolution/connection mechanics, and still be the same "chain" and network.

By extension, a theoretical "fork-friendly" namespace could be written if a more fork-friendly identifier scheme were forked into Eth and a substantial number of chains started using an alternate identifer scheme interchangeably with the legacy EIP155 system. This also explains indirectly, as @shanejonas asked on a recent RPC WG call, why the eip155 namespace is named as it is-- because it does not address all of ethereum, it addresses that subset of ethereum (currently 99.9%, perhaps, or 100) that is addressible via the eip155 chainId system. If people stop using eip155 tomorrow and start using something else, today's CAIP-10, 19, 22, etc usage might not translate over-- a new namespace would need to be set up, with different assumptions about resolution, uniqueness, etc.

Closing this as "do not fix" but linking to this conversation from a follow-up "BCP" CAIP updating CAIP-2 with lessons learned since finalizing.