-
Notifications
You must be signed in to change notification settings - Fork 394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: universalresolver v3 #350
base: staging
Are you sure you want to change the base?
Conversation
I think this will be a good upgrade! |
yes
for sake of simplicity, i think not
this is what replaces the |
Consider: // (1)
multicall([
resolve("a.eth", addr(60)),
resolve("a.eth", text("avatar")),
resolve("b.eth", addr(60))
])
// (2)
resolve("a.eth", multicall([addr(60), text("avatar")]))
// (3)
multicall([
resolve("a.eth", multicall([addr(60), text("avatar")]))
resolve("b.eth", multicall([addr(60), text("avatar")]))
])
// (4)
multi(["a.eth", "b.eth"], [addr(60), text("avatar")])
I forgot to mention (4). It's more of a power-user feature. I never implemented it as it can be accomplished with more verbose (1) or (3). Included for example. For my implementations, I've been doing something like: if (resolver.isRaffyResolver) {
await contact.resolve(name, abi.encodeCall('multicall', [calls]), {enableCcipRead: true});
// effectively same as:
// await contract.multicall(calls.map(c => abi.encodeCall('resolve', (name, c))), {enableCcipRead: true);
} else if (resolver.isExtendedResolver) {
try {
// optimistically try resolve(multicall)
await contact.resolve(name, abi.encodeCall('multicall', [calls]), {enableCcipRead: true});
} catch {
// do individual calls
await Promise.all(calls.map(c => resolver.staticCall(c, {enableCcipRead: true})));
}
} else {
await Promise.all(calls.map(c => provider.call({to: resolver, data: c})));
// effectively same as:
// multicall3.tryAggregate(false, calls.map(c => [resolver, c]));
// but avoids issues with calling non-existent functions on old contracts
} I couldn't decide between the two variants, so I implemented and used both.
From what I understand, contracts that don't implement Contracts with an existing For example, if ethers/viem want a native solution, it would be significantly easier for them to use |
i started writing a long detailed explanation of my thoughts but i ended up concluding we should probably just not care about any extra latency added by using only issue is release timing and how fast people would be able to update their servers, and also how many resolver devs will complain to me when their resolution is slow in-app suddenly (but i'll cross that bridge when i get to it) i'll make the necessary changes and see how it goes |
I missed this— I agree getting CCIP servers to upgrade to supporting generic My point is that both forms are useful and synergize together. I think |
No description provided.