Title: ERC_7831__Multi_Chain_Addressing
Category: ERCs

Author: SamWilsn
Date: 2024-12-03T13:42:46.226Z

github.com/ethereum/ERCs








Add ERC: Multi-Chain Addressing


master ← SamWilsn:cas



          opened 01:39PM - 03 Dec 24 UTC




            SamWilsn
          



+367
-0

Author: shemnon
Date: 2024-12-03T15:23:33.712Z

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.

Author: SamWilsn
Date: 2024-12-04T13:53:37.360Z

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.

Author: wjmelements
Date: 2024-12-05T04:52:44.907Z

Aww based on the title I was hoping this ERC was recommending the best way to do multichain deterministic deployments.

Author: frangio
Date: 2024-12-06T13:53:06.572Z

SamWilsn:

I should point out that ERC-7828  is the more likely candidate for adoption


What is the difference between 7831 and 7828?



 SamWilsn:

CAIP-10 is off-chain


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.

Author: SamWilsn
Date: 2024-12-09T20:12:56.173Z

frangio:




 SamWilsn:

I should point out that ERC-7828  is the more likely candidate for adoption


What is the difference between 7831 and 7828?


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).



 frangio:




 SamWilsn:

CAIP-10 is off-chain


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.


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.

Author: sbacha
Date: 2024-12-16T19:42:15.737Z

why is ENS enshrined?

Author: SamWilsn
Date: 2024-12-16T19:54:14.560Z

It isn’t enshrined. One could easily write a similar standard for any name service and have it coexist reasonably well with this one.

Author: jaack
Date: 2024-12-17T11:19:43.469Z

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.

Author: jaack
Date: 2024-12-17T11:42:29.419Z

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.

Author: SamWilsn
Date: 2024-12-17T14:44:35.235Z

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.

Author: jaack
Date: 2024-12-19T09:17:22.247Z

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 with 0x)
if I want to send 1 ETH to alice.eth on Arbitrum, there can only be one alice.eth anywhere, just like there is now, so I just use alice@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?

Author: SamWilsn
Date: 2024-12-20T17:46:25.193Z

I’m not sure I understand this part:



 jaack:

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.


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.

Author: jaack
Date: 2024-12-20T18:06:31.327Z

SamWilsn:

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).