Optimism CCIP Resolver (by dm3)
Problem
Using ENS to set records or other resolvers requires users to pay mainnet transaction fees hence ENS is deployed solely on Layer 1. We want to extend the capabilities of ENS by moving the resolver contracts to optimism to leverage the low transaction costs of the network.
This makes ENS more accessible and enables more use cases currently not feasible on L1.
This is used in solutions like dm3.network to store dm3 communication profiles as ENS text records more effectively.
Existing solutions
ERC-3668 defines how data can be retrieved from data sources other than the Ethereum mainnet.
A Resolver contract that implements the CCIP (Cross Chain Interoperability Protocol) standard, returns an URL to the client, that can be used to fetch the requested data.
A Gateway then queries the underlying data source and returns it to the client including a Merkle-Proof.
The integrity of the result is then proved using the Resolver contract to ensure the Gateway has not returned valid data.
There are already solutions built using conventional databases like Redis, Postgres, or others as data sources to store the data off-chain. While those solutions connect centralized web2 services to ENS, they offer a cheap and easy way to manage the data and might be sufficient for some use cases. But they require their users to trust the operators of the according system and other web3 ideals like censorship resistance and decentralization without any single point of failure are not fully possible.
Optimism Bedrock CCIP resolver
A different approach is to leverage decentralized Ethereum scaling technology to offer a trustless and decentralized way to store ENS records and link them back to their owners on L1. A key feature here is that rollups are committing a proof of their storage on Ethereum and thereby inheriting the underlying security of Ethereum. With this, proof of the integrity of the data can be provided.
This can be used to prove that arbitrary data is stored at the Optimism Rollup without having access to the Optimism Network in the first place.
This property is used by us to store ENS records in a decentralized trustless manner on L2 with a trustless proof on L1.
Why is this important to ENS?
Using ENS requires high transaction costs since the nature of the L1 fee market. Expanding to Rollups lowers the transaction fees significantly and allows using ENS for applications that are currently not thinkable. However, it’s crucial to stay compliant with the core values of Ethereum and not sacrifice decentralization and trustlessness or lower transaction fees. It also makes the strong growth of Layer2 solutions such as Optimism available as a standard for ENS data storage and combines both approaches in a way that can be easily and securely applied without significant additional effort and without giving up important web3 values.
To ensure that we’re scaling ENS the same way Ethereum is being scaled using Rollup technology.
How its build
Our Resolver Framework contains multiple components. In the section below an overview is given with a description of what their purpose is and how they are built.
Smart Contract L1
OptimismResolver
This contract is the entry point to the Resolver deployed on Ethereum L1. It implements the ERC-3668 standard. It returns the URL to the gateway and offers a way to prove that the returned data is valid. To prove the data, a delegate call is made to the BedrockCcipVerifier to prove the correctness of the data.
An ENS domain owner can set a different Verifier Contract. This is useful if they might use a different resolver contract on L2.
Bedrock CCIP Response Verifier
This contract proves that the requested data is part of a particular L2 contract. This contract might be the L2PublicResolver deployed on Optimism.
This contract is an implementation of the CcipResponseVerifier Interface for Optimism bedrock. Any other way of implementing CCIP response proofs can be deployed and registered by any ENS completely permissionless.
Bedrock Proof Verifier
This contract handles the internals of dealing with Optimism Bedrock Merkle proofs. It takes a Bedrock Storage proof as an argument and proves that the data is part of the optimism storage root.
Smart Contract L2
L2 Public Resolver
The L2 public resolver aims to implement the existing Public Resolver. One key difference is how we deal with authorization.
The L1 Resolver contract can ask the Registry contract whether a user has permission to alter a record or not. This can’t be done on L2 since there is no registry contract in the first place.
Therefore we established a “context” which is a separate layer intended to capture who has created the corresponding record.
This allows setting records on L2 without the need for authorization.
You can find an example of the TextResolver here Optimism-Resolver/contracts/l2/profiles/text/TextResolver.sol at bedrock · corpus-io/Optimism-Resolver · GitHub
Gateway Service
CCIP Gateway
The CCIP Gateway handles the request and computes a Merkle-Proof of the requested data. It supports every ENS Resolver Profile in the Layer2Public Resolver.
It contains the ProofService which can compute proofs of an arbitrary Storage Slot in Optimims Bedrock and the ENSService whose purpose is to calculate the slot position of the Proof Service.
While this is in the current implementation not decentralized, it is still fully trustless. If the proof is valid, the verification is true (and can’t be manipulated).
What is already build
- Every component mentioned above
- Metadata support and events to allow better indexing.
What we want to build in the future
- Audit of the Smart Contracts
- Productive Deployment
- Wildcard subdomains (We have an idea how this might be solved but yet have to make a specification for that…)
- Define and implement a decentralized approach for the gateways