Is there a reason we need this when CAIP-10 exists?
I feel that needs to be addressed in the motivation section as well as why this would be superior to CAIP-10 rather than merely just as good as CAIP-10.
CAIP-10 is off-chain, and doesnāt provide a framework for routing between L2s. This proposal sketches out a framework for wallets to send to L2s they know nothing about (though the specifics are left to future standards.)
I should point out that ERC-7828 is the more likely candidate for adoption, so you might want to repeat your comment there.
Aww based on the title I was hoping this ERC was recommending the best way to do multichain deterministic deployments.
What is the difference between 7831 and 7828?
Can you expand on this? Weāre proposing to use CAIP-10 āon-chainā for ERC-7786 and itās one of the points I have stronger doubts about.
The major design difference is that ERC-7828 resolves names of the form user@l2-name.l1-name (eg. sam@optimism.eth or bob@arbitrum.sepolia), while ERC-7831 resolves names of the form user-ens:l2-name:l1-chainid where :l1-chainid is optional (eg. sam.eth:optimism or bob.eth:arbitrum:11155111).
Iām not familiar enough with ERC-7786 to have a real opinion here, but both ERC-7831 and ERC-7828 use ENS as the source of truth for L2 metadata.
why is ENS enshrined?
It isnāt enshrined. One could easily write a similar standard for any name service and have it coexist reasonably well with this one.
While the character @ is generally overloaded, it provides a more mainstream approach to ābrowsingā multichain addresses because it mentally connects to another widely used primitive with same approach, i.e. the email.
Chains can be likened to email providers, so just like you @gmail.com, you now @arbitrum.eth. I see zero friction for users for ERC-7828 to be adopted.
Unfortunately, not all name services use the ENS standard. So if this is done using the ENS implementation, it cannot easily be ported on any name service on other L2s.But still, it could be a non-issue.
Thatās kinda the problem with the @ symbol though. With the email sam@example.com, sam is bound to the namespace example.com. Thereās nothing in ENS that restricts a name to the chain it was registered on. For example, someuser.optimism.eth:base and someuser.optimism.eth:optimism both refer to the same entity, just on different chains. someuser@gmail.com and someuser@hotmail.com do not share the same relationship.
mmm OK, maybe I have some confusion about this: I thought that the clean chain name would only be representative of the target chain of the transaction, not the actual position of the ENS record in the registry.
Meaning:
- I assume that ENS is the only and default name service, so that name resolution can be implicit in some cases (we only look at ENS if thereās a clean name, or if the name starts with
0x, a string that can be reserved so that nobody can take names starting with0x) - if I want to send 1 ETH to
alice.ethon Arbitrum, there can only be onealice.ethanywhere, just like there is now, so I just usealice@arbitrum.eth, and not because itās bound, but because that string, in that moment, routes to the specific address of Alice.
This flow works the same way as email on the UX part, but differently on the routing part.
Thereās a lot of confusion about chains and names because some L2s and dapps are reserving their chain or dapp name (like Base or Uni) and selling subdomains as identities on the chain (and yes, those are of course bound by the chain name!)
But if a universal multichain address routing goes through, then those subdomains donāt make sense anymore.
I imagine that the routing would be happening at runtime, and not in a predefined record, so that if a chain shuts down, changes name or if a user changes name or its account gets compromised, nothing can break.
Does it make sense?
Iām not sure I understand this part:
That said, I think weāre saying the same thing: there can only be one alice.eth. What differs is that I believe the @ makes alice@arbitrum.eth and alice@base.eth look like different entities.
Then yes, I think weāre saying the same thing.
What I meant is that of course it seems like a different entity, but this I believe will be easy for users to get accustomed to, because itās nearer to an āavatarā.
They look like different entities because they are, in some way: if you send money to alice on Arbitrum, but she wants them on Base, you made a mistake. Itās not the same mistake youād make if you send an email to alice@gmail.com and instead you wanted to send to alice@aol.com. These two email addresses could belong to the same person, but maybe theyāre not.
With that EIP weād basically be solving the cross-service name squatting: if you get an ENS, you get it everywhere, and the only issue arises if you want another type of domain name (like .blast, .sonic or whatever L1 or L2 you want to be on).