# Providing Low-Cost ENS Subdomains Based on Scroll

[[EN]](https://hackmd.io/@Jayden-sudo/Byz5Zd8Kp) [[zh-CN]](https://hackmd.io/@Jayden-sudo/r1HxMu8Y6)

*The interaction costs of ENS on Layer1 hinder its widespread adoption.*

As SoulWallet is a contract-based wallet (meaning we can't achieve consistent multi-chain addresses), ensuring a low-cost ENS for users is crucial for a good experience.

Currently, we own the swl.eth domain and aim to offer users nearly free subdomains (e.g., bob.swl.eth). There are basically two solutions:

1. Completely store all subdomains outside the blockchain using [EIP-3668](https://eips.ethereum.org/EIPS/eip-3668).
- Pros 👍: Zero gas fees for users during the subdomain usage.
- Cons 👎: Completely centralized (which is unsustainable in the long run).

2. Migrate ENS subdomain to Scroll network.
- Explanation:
- In Scroll, we'll deploy a control contract for swl.eth subdomains. Users can set their subdomains on the Scroll network.
- When ENS is resolve, our server will provide proof of a specified slot in the Scroll network. Users can use this proof to verify domain information (e.g., bob.swl.eth) on Layer1.
- Pros 👍: Decentralized, and gas fees on the Scroll network is low.
- Cons 👎: **<u>Delay</u>** (users need to wait for Scroll execution to finalize transaction on Layer1 before their settings take effect).

**We lean towards 'Solution 2'.**

The main issue in Solution 2 is the longer waiting time for users (although Scroll has advantage over Optimistic Rollup in Finalize Transaction, the delay of nearly 1 hour still significantly impacts user experience).

**Need help:**

Can we verify using the data stored in [commitBatch](https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code) ( `committedBatches[_batchIndex] = _batchHash;` )?

- Trust: For non-financial products like ENS, to maintain user-friendly experiences, we may compromise some security (better than complete centralization). Moreover, the ENS resolve process, such as generating proof through our server, <u>implies that our server and the data in the Commit Transaction need to conspire together to provide fake data</u>.

I am currently uncertain whether using the batchHash stored in committedBatches can be used in Scroll to verify the latest storage status: proving specific data stored in a particular slot in the Scroll network. And what other potential risks might be associated with using the data from commitBatch?

--- -

Thank you very much, please feel free to message me if not clear!