Universal Resolution #11
Conversation
Deploying ensips with
|
| Latest commit: |
d14a4ab
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://8be5da9e.ensips.pages.dev |
| Branch Preview URL: | https://ensip-universal-resolution.ensips.pages.dev |
|
Should the ENSIP mention upgrade paths or are they more of the implementation detail? I personally thinks it should be mentioned as A: if it's user initiated upgrade, there must be a public API that initiates the upgrade, B: If it's DAO initiated upgrade, there still needs a API DAO has to call and also the user should aware that the resolution logic is not immutable |
| - `bytes`: The data returned by the resolver | ||
| - `address`: The address of the resolver that resolved the name | ||
|
|
||
| ### reverse |
There was a problem hiding this comment.
Can reverse also handle multicall so that user can pass multiple cointypes?
There was a problem hiding this comment.
i don't really see a use-case
There was a problem hiding this comment.
the implementation for resolve is graceful in preserving a single-call happy path, whereas you can't really preserve that for reverse.
There was a problem hiding this comment.
What about batch reverse resolution - eg, for things like leaderboards?
There was a problem hiding this comment.
there's not much of a difference between something like viem's native batching (via multicall), and what a batch for many names in reverse resolution would do. if there are specific patterns for ccip-read that wouldn't use a batch gateway but instead would go straight to the source gateway, there's always the option of creating a ccip-read friendly multicall contract that assumes that scenario is true.
There was a problem hiding this comment.
Can't you make the same argument about forward resolution?
There was a problem hiding this comment.
batching for many different names means finding many different resolvers, whereas batching many records for one name (forward) is only 1 resolution lookup when using a multicall array.
for forward lookups, it also allows the potential removal of reliance on the batch gateway for some calls.
Co-authored-by: Nick Johnson <[email protected]>
|
@Arachnid by "callers", do you mean clients? or UniversalResolver implementations? |
|
@makoto i don't think adding implementation detail on upgrade paths is worth it, upgradability is down to each individual implementation and it isn't particularly relevant to universal resolution itself imo |
There was a problem hiding this comment.
Can you add documentation for the errors defined in https://github.com/ensdomains/ens-contracts/pull/421/files#diff-895978e0de194cab98cef8af1c7de86d9a16ac5c37a1b33a5a28faf671f3bf14 too?
| - `bytes`: The data returned by the resolver | ||
| - `address`: The address of the resolver that resolved the name | ||
|
|
||
| ### reverse |
There was a problem hiding this comment.
What about batch reverse resolution - eg, for things like leaderboards?
No description provided.