Trustless L2 ENS Registry Rollup Solution

Screenshots

Problem Statement

This project explores the use of the use of rollups to scale application specific logic. More specifically, we built an ENS Registry contract that used the cross-chain interface protocol (CCIP) & the write deferral protocol (CCWP) to decrease the gas fees required to manage an ENS name on ETH Mainnet. This works by separating the settlement and execution layers associated with the registry contract across the L1 & L2. All data can be read and used via the L1 contract, as it settles to the ETH network, but the actual storage, modification, and management of the data occurs on the L2, optimism. By utilizing the CCIP standard, with the ability to generate state proofs of data existing in the L2, the smart contract & the gateway server can perform a trustless “read” of data from optimism & instruct the user on how to manage their data & mutate various records. This is significant as it allows a scalable path to which protocols can move transaction processing and DA to a rollup, while preserving the security guarantees of mainnet. This project is an initial step towards a version of ENS that uses rollups to help scale ENS registrars & resolvers.This works by separating the settlement and execution layers across the L1 & L2.

Solution

This project uses ENS standards and contracts to create a compliant cross-chain ENS registry. It also uses the optimism L2 SDK to build and verify state proofs. This project also implements two key EIPs, 3668 & 5559 to enable for trustless cross-chain reads & async cross chain mutations.There are 4 different components to this project:The smart contracts (written using foundry)The frontend (a react based frontend that uses Ethers for on-chain transactions & queries)The Go backend for decoding and handling CCIP requestsThe TS backend for generating state proofs Each component plays an important role in the ability to read and use a rollup for cheaper transaction management and storage.The system works in this general order: [Reading Data]The user (on the frontend) clicks on the owner() functionThe owner function triggers a query against the L1 "gateway" contractThe L1 contract reverts with a CCIP requestThe CCIP request is caught by the frontend and ethers library then makes a GET request to the gateway serverThe gateway server decodes the request & calculates the SLO offset for the corresponding variableThe gateway server hits the node service and requests a stateProof to be generatedThe gateway receives the stateProof and abi encodes the dataThe gateway returns the data to the clientThe client then hits the callback function with the data from the gateway server and the extra data param provided in the original reversionThe contract verifies the state proof, by calculating the SLO, verifying the stateRootHeader, & accessing the dataThe verified data is then returned to the user[Writing Data]The client sends a write request, but the transaction reverts in preflighting with the CCWDPThe client catches the write deferral request and prompts the user to switch chainsThe client then sends a new transaction on the L2 (optimism) network