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.