Ownable L1 Resolver #6
Conversation
| // Handler for arbitrary resolver calls | ||
| fallback() external { | ||
| address RESOLVER = rootResolver; | ||
| assembly { |
There was a problem hiding this comment.
how much do we save here with the assembly?
There was a problem hiding this comment.
Can characterize; I used this format since it's a well-understood pattern from proxy contracts w/ one small change to call instead of delegatecall since we need the state of the rootResolver to respond.
| @@ -40,6 +75,11 @@ contract L1Resolver is IExtendedResolver, ERC165 { | |||
| * @return The return data, ABI encoded identically to the underlying function. | |||
| */ | |||
| function resolve(bytes calldata name, bytes calldata data) external view override returns (bytes memory) { | |||
| // Resolution for root name should fallback to existing resolver | |||
| if (keccak256(BASE_ETH_NAME) == keccak256(name)) { | |||
There was a problem hiding this comment.
so base.eth goes to root, and what else? Longer comment might be helpful
There was a problem hiding this comment.
Will clarify in an updated comment. But yeah, in short, only "base.eth" resolves to root; all other resolution requests would be for *.base.eth subdomains
There was a problem hiding this comment.
got it, I am curious how name comes through in those other cases. Don't we also fall back to root for some other subdomains?
There was a problem hiding this comment.
Nominally, all ENS name resolution starts on L1. So there are three cases:
base.eth-> we want to call therootResolversince that has our base.eth records- New base username, i.e.
wilson.base.eth-> Resolution fails on L1 so the flow requires resolution to be called against the next higher domain, in this case "base.eth", triggering the cross-chain resolution flow - An existing base subdomain, i.e.
mint.base.eth-> The L1 resolution process finds the existing subdomain resolver which exists on L1 and this contract is never queried
There was a problem hiding this comment.
Ok cool--do you have diagrams of these? Would help me. In particular trying to understand 3. better
There was a problem hiding this comment.
This is probably the best reference (sorry not a diagram). https://docs.ens.domains/ensip/10
Co-authored-by: wilsoncusack <[email protected]>
Co-authored-by: wilsoncusack <[email protected]>
|
This Pull Request was merged without enough reviews |
| } | ||
|
|
||
| // Handler for arbitrary resolver calls | ||
| fallback() external { |
There was a problem hiding this comment.
might be helpful to document which functions we expect to called
* [audit2] #2 Typos and Documentation (#72) * Fix typo in PaymentReceiverUpdated * Fix typo in L2Resolver commment * Fix typos in L2Resolver and ReverseRegistrar natspec * Fix comment in IPriceOracle * Fix natspec in controllers * Remove unused event (#71) * [audit2] #4 Cleanup GRACE_PERIOD handling for launch auction (#73) * Cleanup GRACE_PERIOD handling for launch auction * Add GRACE_PERIOD to EARegistrarController * [audit2] #5 Explicitly declare state visibility (#75) * Explicitly declare state visibility * Style guide * Change resolver for reverse node when changing default resolver (#76) * Remove reverse claiming from EARegistrarController (#78) * Add IExtendedResolver supported signal for L2Resolver (#77) * Add reverse node claim to L2 Resolver (#81) * [audit2] #6 Remove addr.reverse setting from ReverseRegistrar (#74) * Remove addr.reverse setting from ReverseRegistrar * Address PR suggestion
This PR modifies examples of existing CCIP-enabled Resolvers:
rootResolverwhich resolves requests for the base nameIn addition, a lot of new testing infrastructure has been added.