← Back to home

Resolving ENS on L2

Resolving Ethereum Name Service (ENS) names directly on Layer 2 (L2) networks

Screenshots

Resolving ENS on L2 screenshot 1
Resolving ENS on L2 screenshot 2
Resolving ENS on L2 screenshot 3

Problem Statement

Resolving Ethereum Name Service (ENS) names directly on Layer 2 (L2) networks is currently not possible. For instance, it's challenging to utilize ENS addresses for guardians instead of fixed addresses on L2. Example problem that can be solved using this solution: Currently, users have to add a fixed wallet address (like 0xycc...) of their guardians. Later, during the recovery phase, the guardians (owners of the guardian addresses) have to approve the recovery by signing the recovery request via the originally specified address. However, a problem arises when guardians lose access to the originally specified Ethereum address due to various reasons. For instance, they may decide to migrate their assets from one wallet to another and unintentionally forget to update all references to the old Ethereum address or informing their friends. This can lead to difficulties in the recovery process as the guardians may no longer have control over the specified address, hindering the successful recovery of the user's wallet.

Solution

We need to be able to read the L1 data from L2 rollups which is currently a very difficult process. This project leverages the Scroll L1SLOAD precompile, which facilitates fast and inexpensive access to Layer 1 (L1) state from L2. This approach enables the resolution of ENS names on L2 by reading the necessary state information directly from L1 efficiently.

Hackathon

ETHGlobal Brussels

2024

Prizes

  • 🏆

    Best use of ENS4th place

    ENS

Contributors