ENS resolver for the DApp layer

[pedroargento]

📚 Context

Allow DApps to interact with decentralized identities leveraging services like Ethereum Naming Service (ENS).

Decentralized identities allow users to take ownership of their identifications on chain without relying on centralized parties.

✔️ Solution

Build a Input Relay to inform the DApp about ENS domains and its related addresses, allowing the ENS domains to be used as identifiers on the DApp layer.

[tuler]

Keep in mind ENS supports changing names any time. Just resolving a name and sending an input is dangerous, because the DApp will only have a vision from when the input was sent.

[ZzzzHui]

Agree! ENS resolution is probably better to be done on the front end.

[xdaniortega]

Agree! ENS resolution is probably better to be done on the front end.

Agree as well.

[guidanoli]

So, here's an update of our view on this feature:

Relaying ENS name-address pairs to the execution layer is prone to leaving the DApp running in the execution layer with an outdated view of the registrar. Whenever an ENS name expires or is transferred to some other address, someone would need to inform the DApp running in the execution layer through an input.

To solve this problem, we let the DApp running on the execution layer store only the ENS name, and resolve it only on the base layer. Through the current version of vouchers, however, the resolution would occur in the context of the called address. We could shoehorn this feature by adding functions to CartesiDApp (like we did for ETH withdrawals), but we would like to avoid going in this direction, since it increases the bytecode code, and, therefore, the deployment cost of all DApps (even those that wouldn't even adopt ENS).

The ideal solution would be through DELEGATECALL vouchers, which are not yet implemented, and depend on the Output Unification. This instruction allows a contract to execute foreign code, while preserving context. This is exactly what we would need to resolve ENS names and perform subsequent calls still in the context of the DApp contract (like asset transfers).

In my opinion, the most thrilling application of ENS on Cartesi applications would be the ability to use an ENS name you own instead of your address to interact with DApps. More specifically, in games, you would be able to sell your account simply by selling your ENS name, instead of giving away your private key. The main differences are:

• Private keys control base layer accounts: allows signing transaction, messages, etc.
• ENS names control execution layer accounts: allows interacting with DApps registered with ENS names.
• A private key can be known by multiple people: one cannot guarantee they are the only one to know it.
• Each ENS name is owned by one person: this is guaranteed by ENS smart contracts.

[pedroargento]

Just to complement @guidanoli update, the resolve on the base layer happens when adding an input. So inputs are added in the name of the ENS name, provided that the msg sender is its current owner.

Note that ENSInputRelay only cares about the owner of the ENS at the time an input is added. The consequences of the input will affect whomever owns the name in the future (at voucher execution, for example); from the DApp point of view, only the name exists and all history of inputs/outputs refers to this name ignoring any base layer ownership tranfers.

[tuler]

1) the ability to use an ENS name you own instead of your address to interact with DApps. 2) you would be able to sell your account simply by selling your ENS name, instead of giving away your private keys.

I didn't understand the correlation of these two statements.

You can already do (1). If you own a name you can just set the (forward) address of the name to the DApp address, and thus use the name instead of the address.

ps: reverse resolution, address to name, is a different story, subject of PR #70

I didn't understand what you mean in (2). The ENS name is already a NFT. So you can transfer/sell just like an NFT. The owner of the name has the power of (1).

Maybe you are talking about making the DApp contract implement NFT (ERC-721)?

[pedroargento]

@tuler I think you are talking about ENS owning a DApp. This discussion is about users of the DApp interacting as an ENS name instead of an address.

Lets say there is a DApp that is a game. I create the user xxxx.eth and play the game for a while. I now can decide to sell my game account, with all its history with respect to the DApp, through selling the xxxxx.eth ENS. This sale will include all future side effects of current unprocessed inputs. And I can do that without giving away my EOA private key.

[guidanoli]

Sorry for the confusion, @tuler. There are two separate discussions going on related to ENS.

1. The CartesiDApp contract having an ENS name (see #70)
2. DApp users being able to interact with a DApp through ENS names they own (no open PR yet)

[tuler]

I don't see the technical feasibility of integrating with L1 ENS for that. You need a name resolving system inside the DApp (L2 ENS, not to be confused with THE ENS at https://ens.domains).

[tuler]

DApp users being able to interact with a DApp

Ok. It's because this sentence is very confusing.

[pedroargento]

You dont need resolving inside the DApp. You only need resolving when adding inputs and when executing vouchers.

[tuler]

You dont need resolving inside the DApp. You only need resolving when adding inputs and when executing vouchers.

I mean, you can already do what you want by implementing a simple naming system in the DApp. Your DApp can define the registration input to accept a name, like:

Register input: I want to register an account, and my username is "pedro"

In the DApp, you store that the msg_sender "0x123" is registering an account with username "pedro".

Later you Pedro (0x123) send another input for account transfer.

Account transfer input: I want to transfer my account "pedro" to user "0x345".

After that all inputs coming from 0x345 will have power over the "pedro" account. And vouchers to pedro will go to 0x345.

[pedroargento]

I suppose this is true, but ENS allows me to auction, sell, transfer the account in any platform that supports NFTs, both onchain and offchain. Its more composable and flexible to this outside the DApp.

Otherwise, we are putting the burden on the DApp developer to build a transfer system inside the DApp and it will not be compatible with names on other applications.

[xdaniortega]

I agree with @tuler that L2 ENS could have a good role here. I commented in the channel of our team the possibility to use a DID project deployed on Cartesi for this. (You could query a Cartesi DApp for the username of an address.)

[guidanoli]

Although a naming server in the execution layer may have its advantages, ENS may be more familiar to developers and, certainly, to users. Besides, there is a whole ecosystem around it, like marketplaces, libraries, etc.

[tuler]

Although a naming server in the execution layer may have its advantages, ENS may be more familiar to developers and, certainly, to users. Besides, there is a whole ecosystem around it, like marketplaces, libraries, etc.

I totally get the motivation. I just don't see how. Not without dehashing device.

[guidanoli]

I totally get the motivation. I just don't see how. Not without dehashing device.

We can hop on a call later if you want. :-)

[xdaniortega]

I totally get the motivation. I just don't see how. Not without dehashing device.

We can hop on a call later if you want. :-)

Ping me, I'll love to join.

[guidanoli]

Shall we close this issue, given that we'll no longer be caching address-name pairs in the execution layer anymore?