Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delegate Mission Request: Scale ENS to Optimism #134

Open
opjulian opened this issue Feb 15, 2024 · 0 comments
Open

Delegate Mission Request: Scale ENS to Optimism #134

opjulian opened this issue Feb 15, 2024 · 0 comments

Comments

@opjulian
Copy link

Delegate Mission Request: Scale ENS to Optimism

Delegate Mission Request Summary

The top priority for ENS in 2024 is scaling. To scale ENS to Optimism, we need dedicated Optimism production-ready gateways as well as documentation, sample code and support, ready to assist any teams that want to set up their own subname registrars on Optimism to offer subnames such as tim.opcommunity.eth.

S5 Intent
Intent 3:
Improve the Consumer Experience

Proposing Delegate: Jack Anorak 6

Baseline grant amount:

150K OP

Should this Foundation Mission be fulfilled by one or multiple applicants: Multiple

Completion date: Aug 1, 2024

Apply Here

Specification

How will this Delegate Mission Request help accomplish the above Intent?

Scaling ENS to Optimism improves users’ security and trust. The most basic use of ENS is to turn 0x addresses like 0x06109ff24C5c9759F8Ff01E6485a3c1544D70075 into human-readable addresses like jane.verro.eth, reducing the likelihood of errors and making onboarding smoother for new users.

ENS domains also enhance security by providing users with secure and verifiable named contracts, such as router.xyzswap.eth, and decentralized front ends for dapps, such as dapp.xzyswap.eth.limo. The incorporation of ENS domains is not just a technical enhancement but an overall usability upgrade, delivering a higher-quality user experience.

What is required to execute this Delegate Mission Request?

Currently the majority of ENS names, such as vitalik.eth, are registered on L1 Ethereum, which has very high gas costs, often more than $30 for a $5/y name. To solve this problem it is possible to use Optimism mainnet to register ENS names, starting with ENS subnames, i.e. tim.opcommunity.eth. With the recent introduction of the EVM Gateway, GitHub - ensdomains/evmgateway: This repository implements a generic CCIP-Read gateway for fetching state proofs of data on other EVM chains. The intended use is for contracts on L1 to be able to fetch and verify data from contracts on L2 in a read context. 6, it is possible to provably resolve ENS names via L1 Ethereum that are registered and maintained on Optimism mainnet. Recently Vitalik Buterin posted on X,

“All L2s should be working on (trustless, merkle-proof-based) CCIP resolvers, so that we can have ENS subdomains registerable, updateable and readable directly on L2s.

“ENS is super-important, it needs to be affordable!”

While some of the basic building blocks to make this possible have recently been built, e.g., the EVM Gateway, there is still a lot of work to be done in order to make the process of launching an ENS subname project on Optimism mainnet easy and affordable. As ENS scales it will become increasingly dependent on gateway servers, which are tasked with fetching data from L2s and verifying the date on L1 using proofs. Similar to DNS, which has decentralization and redundancy built into the design of DNS servers, ENS also needs to have multiple independent providers of trustless gateways. Establishing an independent dedicated production-ready Gateway service that is supported and can be used for free by Optimism developers is a vital infrastructure component. It is also necessary to provide documentation on how the service can be used, as well as provide access to all the code components necessary to create an Optimism based subname registrar. It should also be possible for this to be completed as a weekend hackathon project, with the support of the service provider of the gateway and documentation.

The deliverables for this execution path include:

  • Establish a dedicated Optimism production gateway service.
  • Create documentation and audited demo code on setting up an ENS subname registrar.
  • Offer a free tier of gateway services.
  • Maintain a support channel, e.g. Discord, for developers to receive free support.

How should the Token House measure progress towards this Mission?

These measures should focus on progress towards completion. Including expected completion dates for each is recommended

  • Please be as specific as possible in defining measures of progress so that Token House delegates can accurately track execution
  • Establishing a dedicated Optimism ENS gateway service – 90 days
  • Documentation and demo code – 150 days
  • Launch the public gateway service for OP Mainnet and OP Sepolia, i.e. to hackathon participants – 180 days
  • Setup and support a support channel, i.e. Discord – 180
  • Continue to support teams working on ENS subname projects – Ongoing beyond conclusion of project

How should badgeholders measure impact upon completion of this Mission?

  • These measures should be focused on performance and may be used by badgeholders to assess your Misson’s impact in the next round of RetroPGF
  • Please be as specific as possible in defining measures of impact so that Citizens’ House badgeholders can accurately measure the grant’s impact
  • The goal of the mission is to directly serve developers and teams that want to set up and run ENS subname registrars on Optimism. The first measure of success will be to objectively meet all the milestones by the completion dates, with easy to use code and documentation, as well as reliable gateway services and support. In addition, it is possible to determine the impact through objective measures, including real use of the gateway API service, hackathon projects using the sample code, and support.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant