ENSIP-16: Offchain Metadata

Authors: jefflau, makoto

Created: September 22, 2022

Status: draft

Abstract

This ENSIP specifies APIs for querying metadata directly on the resolver for EIP-3668 (CCIP Read: Secure offchain data retrieval) enabled names. EIP-3668 will power many of the domains in the future, however since the retrieval mechanism uses wildcard + offchain resolver, there is no standardised way to retrieve important metadata information such as the owner (who can change the records), or which L2/offchain database the records are stored on.

Motivation

With EIP-3668 subdomains already starting to see wide adoption, it is important that there is a way for frontend interfaces to get important metadata to allow a smooth user experience. For instance a UI needs to be able to check if the currently connected user has the right to update an EIP-3668 name.

This ENSIP addresses this by adding a way of important metadata to be gathered on the offchain resolver, which would likely revert and be also resolved offchain, however there is an option for it to be also left onchain if there value was static and wouldn't need to be changed often.

Specification

The metadata should include 2 different types of info

Offchain data storage location related info: graphqlUrl includes the URL to fetch the metadata.
Ownership related info: owner, isApprovedForAll defines who can own or update the given record.

Context

An optional field "context" is introduced by utilizing an arbitrary bytes string to define the namespace to which a record belongs.

For example, this "context" can refer to the address of the entity that has set a particular record. By associating records with specific addresses, users can confidently manage their records in a trustless manner on Layer 2 without direct access to the ENS Registry contract on the Ethereum mainnet. Please refer to ENS-Bedrock-Resolver for the reference integration

Dynamic Metadata

Metadata serves a crucial role in providing valuable insights about a node owner and their specific resolver. In certain scenarios, resolvers may choose to adopt diverse approaches to resolve data based on the node. An example of this would be handling subdomains of a particular node differently. For instance, we could resolve "optimism.foo.eth" using a contract on optimism and "gnosis.foo.eth" using a contract on gnosis. By passing the name through metadata, we empower the resolution process, enabling CcipResolve flows to become remarkably flexible and scalable. This level of adaptability ensures that our system can accommodate a wide array of use cases, making it more user-friendly and accommodating for a diverse range of scenarios.

Implementation

L1

// To be included in
// https://github.com/ensdomains/ens-contracts/blob/staging/contracts/resolvers/Resolver.sol
interface IOffChainResolver {
    /** @dev Returns the owner of the resolver on L2
     * @param node
     * @return owner in bytes32 instead of address to cater for non EVM based owner information
     */
    owner(bytes32 node) returns (bytes owner);
 
    // optional.
    // this returns data via l2 with EIP-3668 so that non EVM chains can also return information of which address can update the record
    // The same function name exists on L2 where delegate returns address instead of bytes
    function isApprovedFor(bytes context, bytes32 node, bytes delegate) returns (bool);
 
    /** @dev Returns the metadata of the resolver on L2
     * @return graphqlUrl url of graphql endpoint that provides additional information about the offchain name and its subdomains
     */
    function metadata(bytes calldata name)
        external
        view
        returns (string memory)
    {
        return (graphqlUrl);
    }
 
    // Optional. If context is dynamic, the event won't be emitted.
    event MetadataChanged(
        string name,
        string graphqlUrl,
    );
}

L2 (EVM compatible chain only)

// To be included in the contract returned by `metadata` function `storageLocation`
interface IL2Resolver {
    /**
     * @dev Check to see if the delegate has been approved by the context for the node.
     *
     * @param context = an arbitrary bytes string to define the namespace to which a record belongs such as the name owner.
     * @param node
     * @param delegate = an address that is allowed to update record under context
     */
    function isApprovedFor(bytes context,bytes32 node,address delegate) returns (bool);
 
    event Approved(
        bytes context,
        bytes32 indexed node,
        address indexed delegate,
        bool indexed approved
    );
}

const node = namehash('ccipreadsub.example.eth')
const resolver = await ens.resolver(node)
const owner = await resolver.owner(node)
// 0x123...
const dataLocation = await.resolver.graphqlUrl()
// {
//   url: 'http://example.com/ens/graphql',
// }

GraphQL schema

GraphQL is a query language for APIs and a runtime for fulfilling those queries with onchain event data. You can use the hosted/decentralised indexing service such as The Graph, Goldsky, QuickNode or host your own using The Graph, or ponder

L1

Metadata is an optional schema that indexes MetadataChanged event.

 
type Domain @entity{
  id
  metadata: Metadata
}
 
type Metadata @entity {
  "l1 resolver address"
  id: ID!
  "Name of the Chain"
  name: String
  "url of the graphql endpoint"
  graphqlUrl: String
}

L2

L2 graphql URL is discoverable via metadata function graphqlUrl field. Because the canonical ownership of the name exists on L1, some L2/offchain storage may choose to allow multiple entities to update the same node namespaced by context. When querying the domain data, the query should be filtered by context that is returned by metadatafunction context field

type Domain {
  id: ID! # concatenation of context and namehash delimited by `-`
  context: Bytes
  name: String
  namehash: Bytes
  labelName: String
  labelhash: Bytes
  resolvedAddress: Bytes
  parent: Domain
  subdomains: [Domain]
  subdomainCount: Int!
  resolver: Resolver!
  expiryDate: BigInt
}
 
type Resolver @entity {
  id: ID! # concatenation of node, resolver address and context delimited by `-`
  node: Bytes
  context: Bytes
  address: Bytes
  domain: Domain
  addr: Bytes
  contentHash: Bytes
  texts: [String!]
  coinTypes: [BigInt!]
}

Backwards Compatibility

None

Open Items

Should owner and isApprovedForAll be within graphql or should be own metadata function?