I’m pleased to announce that we have the first version of an implementation of ENS offchain resolution (ENSIP 10 + EIP 3668) now ready for testing by developers.
The offchain resolver is a starter-kit for building infrastructure to resolve ENS names using external services. This implementation defaults to using a backend that loads names from a JSON flatfile, but the backend is easily pluggable and can be replaced to source records from any database as needed.
Over the next few days I will be improving the documentation and tooling, but for now the root level README describes how to try it out for yourself in a test environment.
This is an important first step to ENS-on-L2; once resolution support is available in ENS, it enables wallet providers etc to provide subdomains to their users at low-to-no cost by storing the records offchain and relying on messages signed using a trusted key for verification.
The next step from here will be to make this more production-ready, and to begin developing gateway and resolver implementations that support other verification methods - specifically, verifying proofs from layer 2 networks, which will make storing ENS names on L2s like Optimism and Arbitrum possible without any additional trust assumptions. This will make it possible for individual users to migrate their names to L2s.
Very excited about this and will go over the code carefully to understand exactly how it works. One thing that jumps out to me right away is step 2-3:
There are 5 main steps to using this in production:
Optionally, write a new backend for the gateway that queries your own data store. Or, use the JSON one and write your records to a JSON file in the format described in the gateway repository. 2. Generate one or more signing keys. Secure these appropriately; posession of the signing keys makes it possible to forge name resolution responses! 3. Start up a gateway server using your name database and a signing key. Publish it on a publicly-accessible URL.
Deploy OffchainResolver to Ethereum, providing it with the gateway URL and list of signing key addresses.
Set the newly deployed resolver as the resolver for one or more ENS names.
This appears to be a pretty significant security ask. Can the security be better than an average hot wallet? Are there hardware wallets for servers?
There are ways to secure this. For example, OpenZeppelin’s Relays are implemented using the Amazon Key Management Service, which allows for keeping key material secure and doesn’t allow exporting the key.
I just made some last changes to 3668, adding support for POST requests and adding notes on security and fingerprinting. Feedback much appreciated before I ask for it to be finalised.