ERC-7831: Multi-Chain Addressing

2 Likes

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.

1 Like

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.

3 Likes

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

2 Likes

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.

1 Like

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.

1 Like

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.

2 Likes

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?

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.

1 Like

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