The ongoing development of output unification will make possible the implementation of DELEGATECALL vouchers. Technical details omitted, it will allow us to implement a ENS resolver in the execution layer.
This will allow DApp users to interact with DApps under their ENS identity without the application caring about their original EOA address. The ENS Relay will make sure that only the current owner of the name can add inputs on behalf of the identity and the resolver will direct any consequences of input to the rightful owner.
I am excited about this feature for two principal use cases:
-
Imagine a decentralized application (DApp) functioning as a game. I establish a user identity, dragonslayer.eth, and actively participate in the game. Now, I have the option to transfer ownership of my entire in-game account, complete with its historical data within the DApp, by selling the associated dragonslayer.eth.eth Ethereum Name Service (ENS) domain. This transaction encompasses all potential future outcomes arising from yet-to-be-processed inputs. I can sell my game account without having to sell my private key (what would be also unsafe for the buyer).
-
Suppose I harbor concerns that my wallet may be compromised due to a security lapse, perhaps because of an inadvertent mistake or a necessary mnemonic input to MetaMask during an emergency, making me feel uneasy about its safety. The logical course of action is to promptly transfer all my funds to a new wallet. However, a critical consideration arises regarding future earnings that might still be locked within a decentralized application (DApp).
Take, for instance, a scenario where I’ve placed a bid in an auction application and am awaiting resolution to receive an NFT. If I’ve been using an Ethereum Name Service (ENS) to interact with the execution layer, migrating the identity associated with my ENS to the new wallet becomes essential. This ensures that any future rewards, such as the NFT from the auction, will be correctly directed to the updated wallet address, mitigating potential complications and ensuring a seamless transition.
DApp developers have the option to create their own identity manager, but utilizing the Ethereum Name Service (ENS) offers a distinct advantage. ENS enables me to conduct auctions, sales, and account transfers across any platform that supports Non-Fungible Tokens (NFTs), whether onchain or offchain. This approach is more versatile and composable beyond the confines of the DApp. By embracing ENS, we avoid imposing the responsibility on DApp developers to construct an internal transfer system, which would lack compatibility with names on other applications.
More context and technical details can be found on Github issue ENS resolver for the DApp layer #58
5 Likes
Woah, thats very cool!
I always imagined that extending ENS identities to dappchains would be great for convenience. And possibly save costs on adding inputs too. But never actually thought of the implication it’d have on migrations/asset management for L2s. Essentially, you’re describing a way to mass migrate your assets/interactions from all dappchains to another address in one transaction.
A small technical question:
Changes in the ENS are reflected instantly, right?
I don’t understand how delegatecall vouchers are the thing that makes this possible, but I’ll read more in the github link you provided.
2 Likes
The changes in ENS are reflected instantly.
The delegate call allows the DApp to generate a voucher to a library that resolves the ENS name. The workflow would be the following:
Add input as “ENS name” - ENSRelay verifies that the msg.sender is the ENS name owner.
Dapp uses “ENS name” as any other address.
DApp generates a voucher with delegate call to a library that can resolve the ENS name to owner on layer one.
3 Likes
ENS names are perfect for user identification!
Compared to Ethereum addresses, they are shorter [1], easier to read [2], and customizable [3]:
- generally take less than 42 characters
- are generally made up of real words rather than hexadecimal digits
- you choose the name, instead of it “choosing you” at random
I like very much this proposal its a small convenience layer that can be built within our execution environment
Also can be a very small nice adding for the gaming vertical but also any application where the account itself can carry some value, future gains or reputational information
1 Like
@Zehui-Cartesi and I had a very interesting discussion regarding ENS names on the execution layer.
It seems that many ENS names are resolved off-chain, following a protocol called CCIP Read. Supporting this protocol would make on-chain ENS name resolution code substantially more complex. Meanwhile, if we don’t support this protocol, some users might not be able to register with their off-chain ENS names.
Furthermore, we’ve identified the possibility of funds being locked if ENS names aren’t renewed or if their resolution is delegated from on-chain to off-chain. This could lead to catastrophic events for some users.
A safer alternative would be to deal with ENS names exclusively on the front-end. Ethereum addresses with registered primary ENS names could be displayed as such on the front-end, improving readability. There are already libraries, such as viem, that reverse resolve Ethereum address to ENS names seamlessly.
One functionality we would lose, however, with accounts on the execution layer not being linked to ENS names, is the ability to sell accounts by selling ENS names as NFTs on known third-party platforms like OpenSea. This functionality could be instead implemented by the application back-end itself as an atomic operation that transfers tokens (that can be withdrawn from the execution layer to the base layer) from one account to another in exchange for the account itself (such as character items, gameplay history, etc.).
Hello,
Thanks for asking for this.