Trustless L2 ENS Registry Rollup Solution

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.

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:

1. The smart contracts (written using foundry)
2. The frontend (a react based frontend that uses Ethers for on-chain transactions & queries)
3. The Go backend for decoding and handling CCIP requests
4. The 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() function
• The owner function triggers a query against the L1 "gateway" contract
• The L1 contract reverts with a CCIP request
• The CCIP request is caught by the frontend and ethers library then makes a GET request to the gateway server
• The gateway server decodes the request & calculates the SLO offset for the corresponding variable
• The gateway server hits the node service and requests a stateProof to be generated
• The gateway receives the stateProof and abi encodes the data
• The gateway returns the data to the client
• The client then hits the callback function with the data from the gateway server and the extra data param provided in the original reversion
• The contract verifies the state proof, by calculating the SLO, verifying the stateRootHeader, & accessing the data
• The verified data is then returned to the user

[Writing Data]

• The client sends a write request, but the transaction reverts in preflighting with the CCWDP
• The client catches the write deferral request and prompts the user to switch chains
• The client then sends a new transaction on the L2 (optimism) network