diff --git a/app/local/data/resolver.tsx b/app/local/data/resolver.tsx index 1f91b447..5f87ff87 100644 --- a/app/local/data/resolver.tsx +++ b/app/local/data/resolver.tsx @@ -2,24 +2,6 @@ import { CodeGroup } from '../content/prose/code/group/CodeGroup'; import { ContractMethod } from './interfaces'; -export const PUBLIC_RESOLVER_SUPPORTS = [ - // 'addr', - // 'addr.reverse', - // 'contenthash', - // 'contenthash.set', - // 'multicoin', - // 'multicoin.set', - // 'text', - // 'text.set', - // 'ABI', - // 'ABI.set', - // 'pubkey', - // 'pubkey.set', - // 'name', - // 'name.set', - // 'multicall', -]; - export const resolver_methods: ContractMethod[] = [ { name: 'supportsInterface(bytes4 interfaceID) external pure returns (bool)', @@ -162,7 +144,7 @@ export const resolver_methods: ContractMethod[] = [ name: 'pubkey(bytes32 node) view returns (bytes32 x, bytes32 y)', interface: '0xc8690233', usage: 'Read Public Key', - seeMore: 'ENSIP- / EIP-619', + seeMore: '', input: [ { name: 'node', @@ -197,6 +179,21 @@ export const resolver_methods: ContractMethod[] = [ }, ], }, + { + name: 'resolve(bytes memory name, bytes memory data) view returns (bytes memory)', + interface: '0x9061b923', + usage: 'Wildcard Resolution', + seeMore: 'ENSIP-10', + input: [ + { name: 'name', type: 'bytes', description: 'DNS-encoded name' }, + { + name: 'data', + type: 'bytes', + description: + 'Encoded function data for other resolver calls like addr(), text(), etc.', + }, + ], + }, { name: 'setAddr(bytes32 node, address a)', interface: '0xd5fa2b00', diff --git a/docs/resolvers/ccip-read.mdx b/docs/resolvers/ccip-read.mdx index c8bf4c53..707d2f09 100644 --- a/docs/resolvers/ccip-read.mdx +++ b/docs/resolvers/ccip-read.mdx @@ -12,9 +12,9 @@ export const meta = { The source of truth for a name and its subdomains does not always have to be on-chain or on Ethereum L1 at all. By leveraging [EIP-3668](https://eips.ethereum.org/EIPS/eip-3668), the Cross Chain Interoperability Protocol (or CCIP Read for short), we can load information by hitting a so called "Gateway". -Within the context of ENS, this enables us, to read names, addresses, records, and more from other chains, or even off-chain. +Within the context of ENS, this enables us to read names, addresses, text records and more from other chains, or even off-chain. -
+
➡️
@@ -27,7 +27,7 @@ Within the context of ENS, this enables us, to read names, addresses, records, a
api.example.com
➡️
-
+
Address:
0x225...c3b5
diff --git a/docs/resolvers/interacting.mdx b/docs/resolvers/interacting.mdx index ab7b1606..c04660ac 100644 --- a/docs/resolvers/interacting.mdx +++ b/docs/resolvers/interacting.mdx @@ -31,12 +31,12 @@ Interface IDs are calculated according to solidity ABI and stored in a four-byte If you want to help a user set their avatar, specify a preferred color scheme, or set any other record on their ENS name you can do so in specific cases. First we need to check if the user's resolver supports the interface we want to use (see [setText](/resolvers/interfaces#0x10f13a8c)). -Afterwhich you can call the `setRecord` function on the user's resolver contract. +Afterwhich you can call the `setText()` function on the user's resolver contract. ```solidity -interface ENS { +interface Resolver { function setText(bytes32 node, string calldata key, string calldata value) external; } ``` diff --git a/docs/resolvers/interfaces.mdx b/docs/resolvers/interfaces.mdx index 00403799..241d5bd8 100644 --- a/docs/resolvers/interfaces.mdx +++ b/docs/resolvers/interfaces.mdx @@ -1,7 +1,5 @@ -import { WIP } from "@/components/wip/WIP"; import { interfaceDetails } from "#/data/interfaces"; import { resolver_methods } from "#/data/resolver"; -import { h2, h3, h4 } from '@/components/mdx/heading/h2'; {/* * @type {import('@/lib/mdxPageProps').MdxMetaProps} */} export const meta = { diff --git a/docs/resolvers/quickstart.mdx b/docs/resolvers/quickstart.mdx index d443036b..944bb9b9 100644 --- a/docs/resolvers/quickstart.mdx +++ b/docs/resolvers/quickstart.mdx @@ -7,7 +7,7 @@ export const meta = { # Resolvers Quickstart At the heart of every ENS name is its resolver. A resolver is a smart contract that implements a specific set of Resolver features (see [Resolver Interface](/resolver/interfaces)). -The resolvers smart contract functions have control over the resolution process of a "node" (a name or subdomain) and onwards (subdomains of itself). +The resolvers smart contract functions have control over the resolution process of a ["node"](/resolution/names#namehash) (a name or subdomain) and onwards (subdomains of itself). ## Basic Resolver @@ -15,9 +15,17 @@ A naive but very plausible example of a resolver is the following. ```solidity contract MyResolver { - function addr(bytes32 node) public view returns (address) { + function addr(bytes32 node) external pure returns (address) { return 0x225f137127d9067788314bc7fcc1f36746a3c3B5; } + + function supportsInterface( + bytes4 interfaceID + ) external pure returns (bool) { + return + interfaceID == this.addr.selector || + interfaceID == this.supportsInterface.selector; + } } ``` @@ -40,4 +48,4 @@ Are you writing a dApp and want to build this? Checkout the [Interacting with a ## Offchain Resolution Although by default ENS resolution is done on-chain. You can leverage the power of CCIP Read to redirect resolution to an off-chain gateway. -More about writing a ccip-enabled resolver [here](/resolvers/ccip-read). +More about writing a CCIP Read-enabled resolver [here](/resolvers/ccip-read). diff --git a/docs/resolvers/writing.mdx b/docs/resolvers/writing.mdx index cd0e4c8a..cf3ca59b 100644 --- a/docs/resolvers/writing.mdx +++ b/docs/resolvers/writing.mdx @@ -1,5 +1,3 @@ -import { WIP } from '@/components/wip/WIP'; - {/** @type {import('@/lib/mdxPageProps').MdxMetaProps} */} export const meta = { description: 'How to write your own resolver.', @@ -10,28 +8,46 @@ export const meta = { # Writing a Resolver Every ENS name has a resolver, which is responsible for resolving information about a name. -By writing your own resolver contract you can extend the functionality of your name, subnames, and more. -Resolvers are a core part of the ENS protocolm, they give the power to a name "node" to control the resolution process from itself onwards (its subdomains etc). Resolvers were originally standardized in EIP 137, but have since received a few updates such as [EIP 181](https://eips.ethereum.org/EIPS/eip-181), [EIP 2304](https://eips.ethereum.org/EIPS/eip-2304), and [ENSIP-10](/ensip/10). +Resolvers are a core part of the ENS protocol. They give each name, represented as a ["node"](/resolution/names#namehash), the power to control the resolution process for itself and all of its subnames. Resolvers were originally standardized in [EIP 137](https://eips.ethereum.org/EIPS/eip-137), but have since received a few updates such as [EIP 181](https://eips.ethereum.org/EIPS/eip-181), [EIP 2304](https://eips.ethereum.org/EIPS/eip-2304), and [ENSIP-10](/ensip/10). + +You can find the latest default resolver implementation, called the Public Resolver, on [GitHub](https://github.com/ensdomains/ens-contracts/blob/mainnet/contracts/resolvers/PublicResolver.sol) and [Etherscan](/learn/deployments). ## Resolver Interface -the idea of a resolver is pretty straight forward. "any contract that implements the resolver interface". There have been a few extensions to the original interface, however a summarized interface is defined as follows: +You can view an extended list of resolver methods [here](/resolvers/interfaces), however a simple interface might look something like this: ```solidity -contract MyResolver { - fn addr(bytes32 node) public view returns (address); +interface IMyResolver { + function supportsInterface(bytes4 interfaceId) external view returns (bool); + function addr(bytes32 node) external view returns (address payable); + function addr(bytes32 node, uint256 coinType) external view returns (bytes memory); + function contenthash(bytes32 node) external view returns (bytes memory); + function text(bytes32 node, string calldata key) external view returns (string memory); + + function setAddr(bytes32 node, address addr) external; + function setAddr(bytes32 node, uint256 coinType, bytes calldata a) external; + function setContenthash(bytes32 node, bytes calldata hash) external; + function setText(bytes32 node, string calldata key, string calldata value) external; } ``` ## Wildcard Resolution -In [ENSIP-10](/ensip/10) a new method was added to the resolver interface, the `resolve()` method. -This method allows for fetching +In [ENSIP-10](/ensip/10) a new `resolve()` method was added to the resolver interface to allow for wildcard resolution. ```solidity -interface ExtendedResolver { - function resolve(bytes calldata name, bytes calldata data) external view returns(bytes); +interface IExtendedResolver { + /** + * @dev Performs ENS name resolution for the supplied name and resolution data. + * @param name The name to resolve, in normalised and DNS-encoded form. + * @param data The resolution data, as specified in ENSIP-10. + * @return The result of resolving the name. + */ + function resolve( + bytes memory name, + bytes memory data + ) external view returns (bytes memory); } ``` @@ -41,8 +57,4 @@ Don't forget to add `0x9061b923` to your [EIP-165](https://eips.ethereum.org/) ` ## Offchain Resolution -When you write your own resolver you are able to leverage the power of CCIP Read. More about writing a ccip-enabled resolver [here](/resolvers/ccip-read) - -## Test your Resolver - - +When you write your own resolver, you are able to leverage CCIP Read to effectively defer name resolution to an HTTP server. This server can then load data from any source including offchain databases, APIs, or other blockchains. Learn more about implementing CCIP Read in your resolver [here](/resolvers/ccip-read).