Emerged in a discussion here around an EIP by @loredanacirstea - would love some feedback on CAIP-2 and CAIP in general.
2 Likes
Note: I cross posed this over at CAIP-2 (Chain ID): The Ethereum interface ¡ Issue #3 ¡ ChainAgnostic/CAIPs ¡ GitHub, but since that issue is closed (despite being the discussions-to link) I am leaving this here to ensure it gets visibility.
I donât understand why Ethereum addresses are labeled as eip155. EIP-155 didnât change the addressing scheme for Ethereum in any way, it only changed the signing scheme and it is opt-in for every transaction and not something that is set per account. An Ethereum address may sign one transaction without a chain ID and the next with a chain ID and then the next without again.
I think that ethereum should be the term used, or maybe ethereum1 if you want some form of versioning.
1 Like
the prefix eip155 is used as we use chainIDs introduced in eip155 to specify the chains. Also ethereum: is already used by ERC681
1 Like
ChainID wasnât introduced by EIP-155, it has existed since Ethereum launched. The only thing EIP-155 did was integrate it into signatures (but not all signatures!) which made it part of consensus rather than just part of gossip.
As I mentioned in the linked issue, an account can sign a mix of EIP-155 transactions, pre-155 transactions, type 2 (1559) transactions, etc. Calling this address a âeip155 addressâ just doesnât make sense. This is different (IIUC) from Bitcoinâ segwit, where addresses were actually backward incompatible (my understanding of Segwit is very limited, so this may be incorrect).
ethereum: is already used by ERC681
If the intent is to make CAIP-2 compatible with other payment URLs, then it should pick a standard schema prefix (protocol) for everything that clearly delineates that it is a CAIP-2 address. For example, caip2:ethereum:0xabcd... or whatever. Having a separate schema namespace for every single blockchain out there is untenable because you will eventually run into conflicts. On the other hand, if the assumption is that someone is pasting an address into a box, I believe that CAIP-2 are compatible with 681 addresses because they both would end up being ethereum:<address>, unless you include the chain ID (which I donât think you should), in which case they would not match each other and you donât have a problem.
1 Like
interesting - I thought it was introduced with EIP155 - seems to be a common misconception then: private blockchain - What is a chainID in Ethereum, how is it different than NetworkID, and how is it used? - Ethereum Stack Exchange
Do you have any EIP/link where it was actually introduced?
How would you differentiate mainnet and goerli without including the chainID?
I am pretty sure it has always been there and I think it is part of the genesis block (though it might be called Network ID in there because early on the two were conflated)? It is necessary to keep testnetworks and mainnet separate from each other, and then eventually (with the ETC split) to keep ETC separate from ETH.
I meant to say that I think you should just have a separate address prefix for every chain, Goerli should not be called âEthereumâ, it should just be called âGoerliâ. The same as I donât think Polygon should be called âEthereumâ or Binance Chain should be called âEthereumâ. When people are talking about Ethereum, they are almost certainly talking about Ethereum Mainnet. There is a whole spectrum of chains that are similar to Ethereum Mainnet ranging from the testnets, to ETC, to side chains, to other blockchains that run the EVM Trying to draw a clean line is difficult and I donât think it adds value. Each chain should have a globally unique name (which they all already do), and we should use that globally unique name as the prefix without trying to group/categorize them.
Just read that answer. I think the source of the confusion is that prior to the Ethereum/Ethereum Classic split, Network ID == Chain ID, so there was functionally a single number. However, after the split we now had two networks with the same network ID but different chain IDs, so we (community) had to come up with a new name for one of them. Thus, âNetwork IDâ turned into âNetwork ID + Chain IDâ. Iâll concede that EIP-155 was perhaps the first place that Chain ID (as a term) came up in any documentation/consensus protocol stuff, so I can appreciate the confusion. However, the test networks have always had a different âchain IDâ, its just that it was called network ID previously because in all cases the two were the same so we didnât need two names.
1 Like
I think it is better to use the ID. E.g. this way you can craft transactions without needing to lookup the chainID. Also otherwise we might clash with networks outside the etheruem exosystem - I think it will be quite hard to enforce a globally unique name and have no collisions with more and more chains emerging.
You already have to do a lookup of the first key. bitcoin needs to be handled differently from ethereum. You can simply have a longer list there, no need for a separate lookup mechanism.
No - I just need to match eip155 and can then deal with all chains in this namepspace - even new ones that the app does not yet know about
2 Likes
Ah, I think this is where we are disagreeing. I donât think it is realistic that youâll be able to send coins/tokens or call contracts on an arbitrary chain that you arenât familiar with, whether it is Ethereum-like or not. For every chain (even test networks, Ethereum Classic, etc.) you need a unique client to be able to interact with that chain.
In other words, I donât think you gain functional value by grouping Ethereum-like chains together into a category.
Yea - this is where we disagree 
Imagine a wallet connected to a dapp via WalletConnect (where CAIPS are used heavily in V2) - the only thing the Wallet needs to know for signing and basic functionality is the chainID. Also if you just fast spin up a testnet - you do not need to register that on a global registry to do basic things. And not even speaking about the collision problem that gets harder and harder if you do not group. I see a not of advantages in using grouping and leveraging the chainIDs that should be unique. Even there we had collisions - but it is easy to argue against them as for the replay attack problem.
How do you plan on drawing the line between âEthereumâ and âNot Ethereumâ? Does Ethereum Classic fall into the Ethereum namespace? What about Tron? Polygon?
Even the Ethereum testnets arenât always compatible. As testnets received the London upgrade, they became signature incompatible with Ethereum if you signed using a type 2 transaction. Similarly, Ethereum Classic slowly drifts away from Ethereum compatibility with time, and some chains migrated to type 2 transactions before Ethereum did, while others are migrating after.
With the introduction of Proof of Stake and eventually state expiry, we may see more and more subtle differences between chains that makes it more and more challenging to maintain a consistent interface that works regardless of what blockchain you are talking to.
Something to keep in mind is that address space extension is currently under research which will likely break this grouping as different chains adopt that feature at different points in time.
Circling back to the original topic, if we do group by âEthereum likeâ then I still think we should prefix the name with ethereum:<chain_id>:address or ethereum:<chain_name>:address. chain_name is more user friendly, but I donât think there is a JSON-RPC endpoint that exposes this at the moment. Even if I concede to grouping (which I donât), eip155 as a prefix is wrong and should not be used IMO.
1 Like
All the chains in the eip155 namespace can at least do eip155 transactions 
So that clearly includes Ethereum Classic and Polygon - never looked into this Tron thing - the movie was great though.
1 Like
I do not think it existed from beginning, hence on the Morden testnet, each new account had a starting nonce of 2^20 in order to differentiate transactions from mainnet transactions.
3 Likes
This is why we chose not to use ethereum as a namespace but instead we chose eip155 to be the namespace
A chainId compatible with EIP-155 specification is independent of branding or nomenclature associated with Ethereum
We even discussed renaming to evm namespace but then it create ambiguity over what is considered an EVM chain
I can understand if you disagree with these points but these namespaces were chosen to provide the lowest friction point that chains could share in order to be identifiable without conflict
1 Like
EIP-155 support by a particular chain doesnât imply any sort of compatibility other than signing mechanism for a subset of transactions. Even now, there are Ethereum spin-off chains that have relatively few EIP-155 transactions submitted, and Ethereum Mainnet has an ever dwindling number of eip-155 transaction signatures.
Using eip-155 as the prefix feels similar to using any other EIP number as the prefix like EIP-2718 or EIP-55. You can very easily (and we may already at this point) have two Ethereum-like chains that have a chain-id but one of them doesnât support EIP-155 transactions at all (in fact, there was talk just today about deprecating EIP-155 transactions in Ethereum).
I think the core of my argument here is that the eip155 prefix doesnât provide any additional value to the user or developer that ethereum wouldnât similarly provide. I still argue that we should have a prefix per chain rather than trying to draw arbitrary lines around chain groups because that gives you real actionable information, but even if we ignore that and try to do a bucket-prefix, EIP-155 doesnât tell the reader anything useful that a random number or word would.
2 Likes
IMHO a prefix per chain is a horrible idea.
We can argue about eip155 as a prefix which depends a bit if chainIDs where introduced with eip155 or have been there earlier.
Since this is a standard, we should have very strictly/well defined terms. What exactly are the requirements for a chain being considered for the âethereumâ (or eip155) group of chains? If the requirement is just âhas implemented eip155â, then many Ethereum compatible chains wouldnât meet this criteria because they simply launched with chain ID support with no EIP155 hardfork. Also, any new chains that launch with only type 2 transactions (my recommendation to any new ethereum-like chain) would not qualify. Similarly, if we eventually deprecate eip-155 transactions (something being explored for Mainnet), then Ethereum itself wouldnât qualify as an eip155 chain in the future. Meanwhile, any chain that doesnât support EIP-155 would still be fully compatible with this specification by using the network ID as the middle delimiter.
I am personally unable to come up with any strong boundaries for what qualifies as an Ethereum-like chain and what qualifies as different enough to warrant its own name, which is why I think we should just have a root name for every blockchain. I donât think we have run into any real problem with namespace collisions in public blockchain names, and we can create a namespace reserved for private blockchains.
Iâm very strongly against drafting a standard that isnât clearly defined, and right now this eip155 prefix is not nearly defined well enough to know exactly what it covers.
1 Like
The requirement is that the network has a chainID (which was introduced with EIP155)