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.