resolve()method that permits more flexible handling of name resolution.
CREATE2addresses), to designated "fallback" addresses, or other schemes. Additionally, individual resolvers would still be assignable to any given subdomain, which would supersede the wildcard resolution using the parent resolver.
namehashbe the algorithm defined in ENSIP-1.
dnsencodebe the process for encoding DNS names specified in section 3.1 of RFC1035, with the exception that there is no limit on the total length of the encoded name. The empty string is encoded identically to the name '.', as a single 0-octet.
parentbe a function that removes the first label from a name (eg,
parent('foo.eth') = 'eth').
parent('tld')is defined as the empty string ''.
ensis the ENS registry contract for the current network.
supportsInterface()is called on it with the interface's ID, 0xTBD.
resolvewith the DNS-encoded name to resolve and the encoded calldata for a resolver function (as specified in ENSIP-1 and elsewhere); the function MUST either return valid return data for that function, or revert if it is not supported.
currentname = name
resolver = ens.resolver(namehash(currentname))
resolveris not the zero address, halt and return
nameis the empty name ('' or '.'), halt and return null.
currentname = parent(currentname)and go to 2.
calldatato the ABI-encoded call data for the resolution function required - for example, the ABI encoding of
addr(namehash(name))when resolving the
supports2544 = resolver.supportsInterface(0xTBD).
supports2544is true, set
result = resolver.resolve(dnsencode(name), calldata)
resultto the result of calling
resultafter decoding it using the return data ABI of the corresponding resolution function (eg, for
addr(), ABI-decode the result of
addr()etc) and the
resolvefunction are supplied the original
name, not the
currentnamefound in the first stage of resolution.
resolvefunction for resolvers, taking the unhashed name and calldata for a resolution function increases implementation complexity, it provides a means for resolvers to obtain plaintext labels and act accordingly, which enables many wildcard-related use-cases that would otherwise not be possible - for example, a wildcard resolver could resolve
id.nifty.ethto the owner of the NFT with id
idin some collection. With only namehashes to work with, this is not possible. Resolvers with simpler requirements can continue to simply implement resolution functions directly and omit support for the
resolvefunction for non-wildcard use-cases (eg, where the resolver is set directly on the name being resolved) should consider what to return to legacy clients that call the individual resolution functions for maximum compatibility.