ENS resolution onchain is complex

[ZzzzHui]

Issue

ENS resolution can only start from one place, i.e., Ethereum L1. Otherwise, name collisions can happen.

However, "The source of truth for a name and its subdomains does not always have to be on-chain or on Ethereum L1 at all." (ref: https://docs.ens.domains/resolvers/ccip-read).

To enable users to claim ENS names on L2, what ENS does is to implement a Cross Chain Interoperability Protocol (CCIP). In summary, when trying to resolve a L2 ENS name, its resolver will revert with custom error OffchainLookup with gateway URLs etc. Offchain component can then visit this gateway to obtain lookup result. Finally the result will be validated onchain via a call.

Ethereum clients (including wallets) are able to resolve ENS names claimed on L1 and L2s. Thus, we might surprise users when they try to execute a delegatecall voucher that contains an ENS name (claimed on L2) and find out they will never succeed.

Solution

We should leave ENS resolution to offchain components.

Impacted contracts

• AssetTransferToENS.sol This contract has high risks because it potentially leads to funds being locked in app contract forever.

• ENSPortal.sol The risk here is not as severe, because the consequence is simply that users are not able to send inputs with a L2 ENS name

• LibENS.sol

• IENSPortal.sol

• InputEncoding.sol

@cartesi/rollups-unit

[guidanoli]

I don't think on-chain ENS resolution is complex. I do think, however, this CCIP Read protocol is more complex. :-)

[guidanoli]

This contract has high risks because it potentially leads to funds being locked in app contract forever.

The user would only have their funds locked in the application contract if the ENS node doesn't resolve to their Ethereum address anymore. I believe that is the case if the user forgets to extend the expiry date of their ENS name, for example. I don't know a solution to this problem. CCIP Read wouldn't fix it either.

[ZzzzHui]

Let's say I claimed an ENS name under Coinbase: zzz.cb.id, which is a layer2 ENS name. This name can resolve to my address with major Ethereum clients, like Metamask, ethersjs, etc. Now let's say there's a delegatecall voucher intended to transfer asset to this zzz.cb.id. It will never execute because it reverts when we call resolver.addr() here. Thus funds potentially locked in app contract forever.

Therefore, I think ENS resolution can only be done offchain, because ENS resolution should work the same regardless it's a L1 name or L2 name.

[guidanoli]

Now let's say there's a delegatecall voucher intended to transfer asset to this zzz.cb.id.

This depends on how the application is implemented. If the application only accepts ENS names which have been transmitted through the ENS input portal, then all of them resolve on-chain. If you allow an application to withdraw assets to arbitrary ENS names, you might lose your assets, just like if you allow an application to withdraw assets to arbitrary Ethereum addresses.

I think ENS resolution can only be done offchain

Not necessarily. Some ENS nodes only resolve on-chain.

[ZzzzHui]

If you allow an application to withdraw assets to arbitrary ENS names, you might lose your assets, just like if you allow an application to withdraw assets to arbitrary Ethereum addresses.

It's not the same thing actually. The former voucher may not be executable, the later mostly is executable. For example, say Bugless DApp allows ERC20 withdrawal for anyone who found a bug. If hacker uses an L2 ENS name for the withdrawal voucher, they will not be able to execute the voucher.

[ZzzzHui]

If the app only works with ENS names from the ENS portal. Then yes it's fine for L1 ENS names

[ZzzzHui]

The onchain team have reached consensus to remove ENS related onchain components. This issue has been addressed in this PR