|
| 1 | +--- |
| 2 | +description: Allows metadata to be queried on EIP-3668 enabled names |
| 3 | +--- |
| 4 | + |
| 5 | +# ENSIP-16: Offchain metadata |
| 6 | + |
| 7 | +| **Author ** | Jeff Lau \<[email protected]>, Makoto Inoue \<[email protected]> | |
| 8 | +| ------------- | ---------------------------------------------------------------- | |
| 9 | +| **Status** | Draft | |
| 10 | +| **Submitted** | 2022-09-22 | |
| 11 | + |
| 12 | +### Abstract |
| 13 | + |
| 14 | +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. |
| 15 | + |
| 16 | +### Motivation |
| 17 | + |
| 18 | +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. |
| 19 | + |
| 20 | +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. |
| 21 | + |
| 22 | +### Specification |
| 23 | + |
| 24 | +The metadata should include 2 different types of info |
| 25 | + |
| 26 | +- Offchain data storage location related info: `graphqlUrl` includes the URL to fetch the metadata. |
| 27 | + |
| 28 | +- Ownership related info: `owner`, `isApprovedForAll` defines who can own or update the given record. |
| 29 | + |
| 30 | +#### Context |
| 31 | + |
| 32 | +An optional field "context" is introduced by utilizing an arbitrary bytes string to define the namespace to which a record belongs. |
| 33 | + |
| 34 | +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](https://github.com/corpus-io/ENS-Bedrock-Resolver#context) for the reference integration |
| 35 | + |
| 36 | +#### Dynamic Metadata |
| 37 | + |
| 38 | +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. |
| 39 | +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. |
| 40 | + |
| 41 | +### Implementation |
| 42 | + |
| 43 | +#### L1 |
| 44 | + |
| 45 | +```solidity |
| 46 | +
|
| 47 | +// To be included in |
| 48 | +// https://github.com/ensdomains/ens-contracts/blob/staging/contracts/resolvers/Resolver.sol |
| 49 | +interface IOffChainResolver { |
| 50 | + /** @dev Returns the owner of the resolver on L2 |
| 51 | + * @param node |
| 52 | + * @return owner in bytes32 instead of address to cater for non EVM based owner information |
| 53 | + */ |
| 54 | + owner(bytes32 node) returns (bytes owner); |
| 55 | +
|
| 56 | + // optional. |
| 57 | + // this returns data via l2 with EIP-3668 so that non EVM chains can also return information of which address can update the record |
| 58 | + // The same function name exists on L2 where delegate returns address instead of bytes |
| 59 | + function isApprovedFor(bytes context, bytes32 node, bytes delegate) returns (bool); |
| 60 | +
|
| 61 | + /** @dev Returns the owner of the resolver on L2 |
| 62 | + * @return name can be l2 chain name or url if offchain |
| 63 | + * @return coinType according to https://github.com/ensdomains/address-encoder |
| 64 | + * @return graphqlUrl url of graphql endpoint that provides additional information about the offchain name and its subdomains |
| 65 | + * @return storageType 0 = EVM, 1 = Non blockchain, 2 = Starknet |
| 66 | + * @storageLocation = l2 contract address |
| 67 | + * @return context = an arbitrary bytes string to define the namespace to which a record belongs such as the name owner. |
| 68 | + */ |
| 69 | + function metadata(bytes calldata name) |
| 70 | + external |
| 71 | + view |
| 72 | + returns (string memory, uint256, string memory, uint8, bytes memory, bytes memory) |
| 73 | + { |
| 74 | + return (name, coinType, graphqlUrl, storageType, storageLocation, context); |
| 75 | + } |
| 76 | +
|
| 77 | + // Optional. If context is dynamic, the event won't be emitted. |
| 78 | + event MetadataChanged( |
| 79 | + string name, |
| 80 | + uint256 coinType, |
| 81 | + string graphqlUrl, |
| 82 | + uint8 storageType, |
| 83 | + bytes storageLocation, |
| 84 | + bytes context |
| 85 | + ); |
| 86 | +} |
| 87 | +``` |
| 88 | + |
| 89 | +#### L2 (EVM compatible chain only) |
| 90 | + |
| 91 | +```solidity |
| 92 | +// To be included in the contract returned by `metadata` function `storageLocation` |
| 93 | +interface IL2Resolver { |
| 94 | + /** |
| 95 | + * @dev Check to see if the delegate has been approved by the context for the node. |
| 96 | + * |
| 97 | + * @param context = an arbitrary bytes string to define the namespace to which a record belongs such as the name owner. |
| 98 | + * @param node |
| 99 | + * @param delegate = an address that is allowed to update record under context |
| 100 | + */ |
| 101 | + function isApprovedFor(bytes context,bytes32 node,address delegate) returns (bool); |
| 102 | +
|
| 103 | + event Approved( |
| 104 | + bytes context, |
| 105 | + bytes32 indexed node, |
| 106 | + address indexed delegate, |
| 107 | + bool indexed approved |
| 108 | + ); |
| 109 | +} |
| 110 | +``` |
| 111 | + |
| 112 | +```javascript |
| 113 | +const node = namehash('ccipreadsub.example.eth') |
| 114 | +const resolver = await ens.resolver(node) |
| 115 | +const owner = await resolver.owner(node) |
| 116 | +// 0x123... |
| 117 | +const dataLocation = await.resolver.graphqlUrl() |
| 118 | +// { |
| 119 | +// url: 'http://example.com/ens/graphql', |
| 120 | +// } |
| 121 | +``` |
| 122 | + |
| 123 | +##### GraphQL schema |
| 124 | + |
| 125 | +[GraphQL](https://graphql.org) 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](https://thegraph.com), [GodSky](https://docs.goldsky.com/indexing), [QuickNode](https://marketplace.quicknode.com/add-on/subgraph-hosting) or host your own using The Graph, or [ponder](https://ponder.sh) |
| 126 | + |
| 127 | +##### L1 |
| 128 | + |
| 129 | +`Metada` is an optional schema that indexes `MetadataChanged` event. |
| 130 | + |
| 131 | +```graphql |
| 132 | + |
| 133 | +type Domain @entity{ |
| 134 | + id |
| 135 | + metadata: Metadata |
| 136 | +} |
| 137 | + |
| 138 | +type Metadata @entity { |
| 139 | + "l1 resolver address" |
| 140 | + id: ID! |
| 141 | + "Name of the Chain" |
| 142 | + name: String |
| 143 | + "coin type" |
| 144 | + coinType: BigInt |
| 145 | + "url of the graphql endpoint" |
| 146 | + graphqlUrl: String |
| 147 | + "0 for evm, 1 for non blockchain, 2 for starknet" |
| 148 | + storageType: Int |
| 149 | + "l2 contract address" |
| 150 | + storageLocation: Bytes |
| 151 | + "optional field to store an arbitrary bytes string to define the namespace to which a record belongs" |
| 152 | + context: Bytes |
| 153 | + "optional field if the name has expirty date offchain" |
| 154 | + expiryDate: BigInt |
| 155 | +} |
| 156 | + |
| 157 | +``` |
| 158 | + |
| 159 | +##### L2 |
| 160 | + |
| 161 | +L2 graphql URL is discoverable via `metadata` function `graphqlUrl` field. |
| 162 | +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 quering the domain data, the query should be filtered by `context` that is returned by `metadata`function `context` field |
| 163 | + |
| 164 | +```graphql |
| 165 | +type Domain { |
| 166 | + id: ID! # concatenation of context and namehash delimited by `-` |
| 167 | + context: Bytes |
| 168 | + name: String |
| 169 | + namehash: Bytes |
| 170 | + labelName: String |
| 171 | + labelhash: Bytes |
| 172 | + resolvedAddress: Bytes |
| 173 | + parent: Domain |
| 174 | + subdomains: [Domain] |
| 175 | + subdomainCount: Int! |
| 176 | + resolver: Resolver! |
| 177 | + expiryDate: BigInt |
| 178 | +} |
| 179 | + |
| 180 | +type Resolver @entity { |
| 181 | + id: ID! # concatenation of node, resolver address and context delimited by `-` |
| 182 | + node: Bytes |
| 183 | + context: Bytes |
| 184 | + address: Bytes |
| 185 | + domain: Domain |
| 186 | + addr: Bytes |
| 187 | + contentHash: Bytes |
| 188 | + texts: [String!] |
| 189 | + coinTypes: [BigInt!] |
| 190 | +} |
| 191 | +``` |
| 192 | + |
| 193 | +### Backwards Compatibility |
| 194 | + |
| 195 | +None |
| 196 | + |
| 197 | +### Open Items |
| 198 | + |
| 199 | +- Should `owner` and `isApprovedForAll` be within graphql or shoud be own metadata function? |
| 200 | + |
| 201 | +### Copyright |
| 202 | + |
| 203 | +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |
0 commit comments