The first ENS Layer 2 meeting, coordinated by @makoto, was held today. Participants included people from several L2 solutions, ENS community and team members, and wallet developers.
A recording of the session is available here: https://www.youtube.com/watch?v=vloI0VT8DXE.
There was some discussion of both the possibility of hosting ENS on its own rollup, and means to encode and resolve L2-specific addresses using ENS, but both of these were deemed offtopic and a subject for future discussion.
The main topic of discussion was how to support ENS name resolution for layer 2 platforms, specifically:
- Committing names to Layer 2 solutions so that they and their subdomains can be managed without needing to perform L1 transactions.
- Resolving L2-based names without the client doing the resolution needing to be aware of the details of the L2 implementation a given name is managed by.
Discussion revolved around the starting point given by Vitalik in this post on Ethereum Magicians, which can be summarised as:
- Names that are to be managed on an L2 have ownership transferred to a contract responsible for interfacing between ENS and that L2.
- Attesters are participants who lock a bond in the above contract, and sign messages asserting what a name resolves to.
- If an attester makes a false attestation, another party can make a challenge; doing so requires the attester to prove the resolution of the name (at the time the transaction was signed) onchain, or lose their deposit.
This concept was explored in some more detail at the first ENS workshop, with refinements being suggested, including reversing the burden of proof - requiring the challenger to prove the attester wrong, which shortens the time period between an attester producing a false signature and their losing their deposit, thus reducing the threat window and hence the size of the deposit required.
Participants generally agreed that this was a good direction to explore, with several refinements being suggested. The most notable of those was by Harry Kalodner, from Offchain Labs, who suggested an alternate approach, along these lines:
- Each L2 ENS interface contract maintains a merkle root of the resolution status of all the names it is responsible for. This merkle tree is structured according to a standard that is identical for all L2 implementations.
- Changes to any name managed by this contract on the L2 result in updates to this merkle root on L1 - though these updates can be delayed and batched.
- Instead of producing a signature backed up by a bond, attesters can simply provide witness data that allows the client to resolve the name themselves by checking it against the relevant merkle root.
- Faster updates can be supported by having attesters submit a bond and generate signatures asserting what a future merkle root’s value will be; unlike Vitalik’s original proposal, anyone in posession of an invalid proof can use it to invalidate the attester’s deposit, without needing to understand the details of the particular L2 in question.
I (Nick Johnson) observed that while on the surface use of a structure like this reduces flexibility for resolution by requiring it to only be static lookups, this can be remediated by making the data committed to a tuple of (resolver address, call data). To resolve, clients (locally) call the resolver address with the call data, then in the same context, call the resolver to perform their initial resolution request. The typical usage of this would be for the call data to be a function call that configures the resolver to resolve that particular name, but this is application-specific, and clients need not understand the data being sent.
Participants wrapped up by agreeing to form a working group to further explore ENS-on-L2 and begin designing a standard, with future calls as needed.