Domains Layer2 and offchain data support

Summary

With the proliferation of layer 2 solutions for Ethereum that are starting to reach maturity, it's important that Domains is able to provide resolution services across the entire ecosystem, as well as making it possible for Domains users to take advantage of the efficiencies made possible by Layer 2 solutions. Subsequent to a post by Vitalik that suggested a possible means for this, the Domains team and the wider Domains and L2 community have been working on a general-purpose "Layer 2 bridge" that makes cross-platform interoperability possible for both Domains and other applications that need to be able to retrieve data from a variety of offchain sources (any data that resides outside of Ethereum Mainnet also known as layer 1/L1. This includes both proprietary database and layer 2/L2 solutions such as Optimism, Arbitrum, Starkware, ZKSync, and so on) in a trustless fashion and comes up with standards.

• EIP-3668: CCIP Read: Secure offchain data retrieval

• EIP-5559: Cross Chain Write Deferral Protocol

• ENSIP 10: Wildcard Resolution

EIP 3668 (Final) allows for offchain (including Layer 2/L2) lookups of data in a way that is transparent to clients and provides contract authors to implement whatever validation is necessary; in many cases, this can be provided without any additional trust assumptions over and above those required if data is stored onchain.

EIP 5559 (Draft) provides a mechanism in which smart contracts can request various tasks to be resolved by an external handler. This provides a mechanism in which protocols can reduce the gas fees associated with storing data on mainnet by deferring the handling of it to another system/network. These external handlers act as an extension to the core L1 contract.

ENSIP 10 (Draft) is a general way to resolve wildcard (eg: *.foo.tomi) on L1. Issuing subdomains and moving the resolution of the parent name offchain allows DApps to create subdomains offchain yet make it accessible through L1.

Steps required for Dapps and wallets to support offchain data lookup.

If your DApps or wallets use one of those libraries, the EIP 3668 and ENSIP 10 support will be built in, so simply update the library when ready. EIP 5559 is still in its early stage of draft and the content will be evolving

ethersjs

ethers.js 5.6.2 supports both EIP3668 and ENSIP 10.

To try out these features, offchainexample.tomi points to so-called "offchain resolver" that fetches data from JSON configuration file hosted on google app engine. It will reply data to any record for offchainexample.tomi and its subdomain record such as 2.offchainexample.tomi. The example resolver is not using L2 data but the same mechanism works when the L2 resolver becomes ready.

const { ethers } = require("ethers");
const url = `https://mainnet.infura.io/v3/${process.env.API_KEY}`;
const provider = new ethers.providers.JsonRpcProvider(url);

async function main() {
 let resolver = await provider.getResolver("1.offchainexample.tomi");
 let address = await provider.resolveName("1.offchainexample.tomi");
 let email = await resolver.getText("email");
 console.log({ resolver: resolver.address, address, email });
}
main();

The expected output is as follows.

$node index.js
{
 resolver: '0xCde4CA965F173AEFAF4c32b1E081256fD25D5D0b',
 address: '0x41563129cDbbD0c5D3e1c86cf9563926b243834d',
}

Steps required for Dapps and wallets to issue subdomains offchain

If you wish to issue subdomains using offchain data storage, please follow offchain resolver as a reference point. The example uses a flat file as a data source but can easily be replaced with database calls.

Offchain resolver provides an easy way to store data offchain but please be aware of some trade off. Users have to trust that gateway server returns the correct data. Some offchain resolver returns attestation by signing the signature. To do so, the owner of the parent domain that issue subdomains have to host the gateway on their own and have to have a private key to sign. If the gateway server is compromised, there is a risk that the subdomain address are redirected to the malicious addresses.

To minimise the trust to the gateway, we are currently working on L2 resolvers

FAQ

Is the change backwards compatible?

Yes. The existing names on L1 will continue working without clients nor applications supporting these standards. Only names that are outside of L1 will not be resolved.

Will L2/offchain data be supported by GraphQL?

Once each L2 is officially supported, we will need to spin up a subgraph for each L2 bridge, and we will use schema stitching to make using them transparent to callers.

For names that are not hosted on a supported L2, we won't be able to fetch data that are normally only available on the subgraph

How do you support other EVM compatible chains?

Non-L2 chains lack ways to verify data on L1 in a trustless manner. The alternative is for chain bridge operators to act as a trusted third-party and hosts the offchain gateway, or individual DApps host their own gateway and sign each data with the private key of the Domains name.

Can I issue a new tld unique to an offchain environment?

No. Please read "Why Domains Doesn't Create More TLDs: Responsible Citizenship in the Global Namespace" for more detail. Alternatively we suggest that you import DNS names as Domains like cb.id, and argent.xyz

Can I set a primary name to names on offchain?

Yes, you can. However, reverse registrar (it is a hidden top-level domain starting with .addr.reverse) currently resides on L1; hence you have to pay gas on L1. We may consider moving the reverse registrar to L2 in future.

Can I register .tomi name on offchain?

Only when we migrate .eth name to a specific L2 as one of the last steps of our migration after finding out which L2 supports tNDS integration the best.

How do I handle contract addresses?

Unlike EOA (Externally Owned Account), contract based accounts such as multisig may only be accessible in certain chains. ENSIP-11 allows a single name to hold different addresses across multiple EVM compatible chains and recommendation is to store contract addresses to EVM chain specific address record fields.