CCIP Read implementation #41

pikonha · 2024-03-19T12:13:02Z

CCIP Read implementation

Description

This pull request adds the CCIP-Read support to the Go-ENS library. This function enables users to read data from offchain data sources that follow the EIP-3668 standard.

These additions enhance the versatility and utility of the Go-ENS library by enabling seamless interaction with contracts and providing efficient domain resolution capabilities. The implementation aligns with the library's objective of comprehensive support for Ethereum Name Service (ENS) operations.

How it works

Go-ENS calls the Universal Resolver ENS' contract with the intent of forward resolving a domain such as jesse.cd.id (externally handled by Coinbase's Offchain Resolver)
The Universal Resolver returns the address of the offchain resolver
Go-ENS calls the addr(namehash) or resolve(labelhash, encodedArgs) function on the contract which reverts with OffchainLookup as described on the EIP-3668
The client then parses the given error in order to get the following parameters:
- sender: contract's address
- urls: offchain API URL
- callData: encoded function call that should be redirected to the API
- callbackFunction: validation function that should be called with the API's response
- extraData: encoded function call with arbitrary arguments
A request to the given URL is made with sender and calldata as arguments following the Gateway Interface
The callbackFunction is then called with the API's response and the extraData to validate the authenticity of the data
The Offchain Resolver's callback function response is then parsed and returned by the caller

┌──────┐                                          ┌────────┐ ┌─────────────┐
│GO-ENS│                                          │Contract│ │   Gateway   │
└──┬───┘                                          └───┬────┘ └──────┬──────┘
   │                                                  │             │
   │ somefunc(...)                                    │             │
   ├─────────────────────────────────────────────────►│             │
   │                                                  │             │
   │ revert OffchainLookup(sender, urls, callData,    │             │
   │                     callbackFunction, extraData) │             │
   │◄─────────────────────────────────────────────────┤             │
   │                                                  │             │
   │ HTTP request (sender, callData)                  │             │
   ├──────────────────────────────────────────────────┼────────────►│
   │                                                  │             │
   │ Response (result)                                │             │
   │◄─────────────────────────────────────────────────┼─────────────┤
   │                                                  │             │
   │ callbackFunction(result, extraData)              │             │
   ├─────────────────────────────────────────────────►│             │
   │                                                  │             │
   │ answer                                           │             │
   │◄─────────────────────────────────────────────────┤             │
   │                                                  │             │

Related Issue

Issue #38
PR #40

Changes

Changes to Core Features:

Have you added an explanation of what your changes do and why you'd like us to include them?
Have you written new tests for your core changes, as applicable?
Have you successfully run tests with your changes locally?

Additional Notes

I'm working on the CCIP Read implementation for the other features such as reading text, multicoin addresses, and contenthash.

The Subdomain resolution PR was used as a starting point for this implementation, which enables this PR to handle both, CCIP-Read and subdomain resolution. They have been decoupled to make the review process easier.

Cheers from the Blockful team 👋🏼

pikonha · 2024-03-26T12:52:57Z

This is now fully working:

resolving off-chain addresses
getting off-chain text

feedback on the implementation is more than welcome

mdtanrikulu · 2024-04-02T14:13:19Z

lgtm! works fine with real examples. only small problem is that the following test fails, probably because of some custom error change;

TestResolveEthereum > resolver_test.go:74
Expected nil, but got: &errors.errorString{s:"unregistered name"}

pikonha · 2024-04-02T14:58:46Z

lgtm! works fine with real examples. only small problem is that the following test fails, probably because of some custom error change;
TestResolveEthereum > resolver_test.go:74
Expected nil, but got: &errors.errorString{s:"unregistered name"}

thanks for reviewing it, mate. this test is failing on the main branch as well, I'll fix it with a similar scenario.

pikonha · 2024-04-05T20:05:42Z

lgtm! works fine with real examples. only small problem is that the following test fails, probably because of some custom error change;
TestResolveEthereum > resolver_test.go:74
Expected nil, but got: &errors.errorString{s:"unregistered name"}

the ethereum.eth test is failing because no address is assigned to this domain on mainnet as you can see in here. a similar scenario is being tested on the TestResolveResolverEth test.

pikonha · 2024-04-23T13:50:24Z

any updated on this?

mdtanrikulu · 2024-04-23T14:46:09Z

any updated on this?

I think in that case this should be handled in the original go-ens repo. It's surely unrelated with the current PR. All good for me.

dneilroth · 2024-05-08T15:06:06Z

@pikonha Thanks for putting this together, was looking for an implementation just like this to help with x-chain reads for a project of mine. Anything I can do to help get it merged?

pikonha · 2024-05-08T17:41:01Z

@dneilroth it's pretty much done from my end tbh, just waiting for the review and approval.

dneilroth · 2024-07-08T21:22:38Z

@mcdee is it possible to get this one merged? cc @mdtanrikulu

mcdee

Various comments on the PR.

Note that I have not yet looked closely at the changes in resolver.go, I will attempt them at a later date.

mcdee · 2024-07-09T08:26:40Z

universal_resolver.go

+
+// NewUniversalResolver obtains the ENS UniversalResolver.
+func NewUniversalResolver(backend bind.ContractBackend) (*UniversalResolver, error) {
+	address, err := UniversalResolverContractAddress(backend, "mainnet")


This will fail for non-mainnet instances. The backend should be queried for the chain ID and a suitable address returned.

I know it is possible to fetch the chainID from the ethClient injected into the Resolver, however, I haven't found a way to fetch it from the bind.ContractBackend interface. any idea on how to solve this without changing the Resolver signature?

universal_resolver.go

mcdee · 2024-07-09T08:29:07Z

resolver.go

@@ -214,21 +240,11 @@ func resolveName(backend bind.ContractBackend, input string) (common.Address, er
 }

 func resolveHash(backend bind.ContractBackend, domain string) (common.Address, error) {


I don't understand the purpose of the changes here. Please don't use shortened names, it doesn't add anything (especially in a world where we have registry, registrar and resolver; r is not a useful letter). I also don't understand why the returned error has been changed.

renaming all the aliased variables to a more meaningful version.

the resolver.go had to be changed to support offchain domains the same way it does for the on-chain ones. the main goal is to maintain the syntax for both types of domain:

r, _ := NewResolver(client, "onchain.eth") actual, err := r.Text("com.twitter") r, _ := NewResolver(client, "offchain.eth") actual, err := r.Text("com.twitter")

the implementation was inspired by the Viem's implementation of the CCIP-Read which relies on the Universal Resolver instead of directly on the Resolver itself.

resolver.go

ccip.go

mcdee · 2024-07-09T08:50:27Z

ccip.go

+		return nil, err
+	}
+
+	sender := errArgs[0].(common.Address)


There is a lot of casting and array access here without checks, please add checks to avoid potential panics.

for the returned error to have the OffchainLookup signature (0x556f1830), it must have the following arguments:

sender

urls

calldata

callback

extraData

so I assume those variables will be on the errArgs variable and so they can be accessed directly by the index. otherwise, it would have failed on the (len(errData) >= 10 && errData[:10] == offchainLookupSignature) condition

It is easy for an error to be returned with the same four bytes but representing a different function (see 4byte.info for an example of clashes), and if done maliciously then it would cause a panic.

I understand the selector conflict and I did some testing to ensure it would break before an unexpected panic. in every scenario I've tested these conditions would return an error in case of an unexpected error since it wouldn't be present on the Universal Resolver's ABI

var sig [4]byte copy(sig[:], hexBytes[:4]) abiErr, err := uAbi.ErrorByID(sig) if err != nil { return nil, err } var errorData []byte copy(errorData[:], hexBytes[4:]) errArgs, err := abiErr.Inputs.Unpack(errorData) if err != nil { return nil, err }

ccip.go

resolver.go

pikonha · 2024-07-09T17:58:59Z

I'll go through the comments ASAP, thanks for reviewing it, mate.

ccip.go

mdtanrikulu · 2024-12-04T01:25:35Z

Hey there, may I ask what is the current status of this PR? I see that most of the issues have been addressed, but is there anything else that needs to be done to finalize it? cc @mcdee @dneilroth

pikonha added 7 commits March 13, 2024 20:18

feat: add ENS' UniversalResolver contract

1b38480

feat: add DNS encode utility function

7c398ad

refactor: resolveHash relying on UniversalResolver

c37ae63

refactor: handle offchain lookup revert error

80fea4f

feat(WIP): offchain resolution through coinbase

230bcec

refactor: decouple ccip read from resolver

8e3394d

fix: call addr with args on onchain resolve

59e01be

pikonha mentioned this pull request Mar 21, 2024

Support CCIP Read and ENSIP-10 #38

Open

pikonha added 3 commits March 21, 2024 15:53

test: onchain text reading

d1408e3

fix: decode text output

b7b1f4e

test: add subdomain ccip tests

0241d2b

pikonha added 2 commits March 26, 2024 11:33

refactor: move ccip to resolver.Address method

3d57523

test: invalid offchain subdomain

eefee11

mcdee requested changes Jul 9, 2024

View reviewed changes

dneilroth reviewed Jul 9, 2024

View reviewed changes

ccip.go Outdated Show resolved Hide resolved

chore: change variable names and add client timeout

9191928

pikonha requested a review from mcdee July 10, 2024 13:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CCIP Read implementation #41

CCIP Read implementation #41

pikonha commented Mar 19, 2024 •

edited

Loading

pikonha commented Mar 26, 2024

mdtanrikulu commented Apr 2, 2024 •

edited

Loading

pikonha commented Apr 2, 2024

pikonha commented Apr 5, 2024

pikonha commented Apr 23, 2024

mdtanrikulu commented Apr 23, 2024

dneilroth commented May 8, 2024

pikonha commented May 8, 2024

dneilroth commented Jul 8, 2024 •

edited

Loading

mcdee left a comment

mcdee Jul 9, 2024

pikonha Jul 10, 2024

mcdee Jul 9, 2024

pikonha Jul 9, 2024

mcdee Jul 9, 2024

pikonha Jul 9, 2024

mcdee Jul 10, 2024

pikonha Jul 10, 2024 •

edited

Loading

pikonha commented Jul 9, 2024

mdtanrikulu commented Dec 4, 2024

		@@ -214,21 +240,11 @@ func resolveName(backend bind.ContractBackend, input string) (common.Address, er
		}

		func resolveHash(backend bind.ContractBackend, domain string) (common.Address, error) {

CCIP Read implementation #41

Are you sure you want to change the base?

CCIP Read implementation #41

Conversation

pikonha commented Mar 19, 2024 • edited Loading

CCIP Read implementation

Description

How it works

Related Issue

Changes

Changes to Core Features:

Additional Notes

pikonha commented Mar 26, 2024

mdtanrikulu commented Apr 2, 2024 • edited Loading

pikonha commented Apr 2, 2024

pikonha commented Apr 5, 2024

pikonha commented Apr 23, 2024

mdtanrikulu commented Apr 23, 2024

dneilroth commented May 8, 2024

pikonha commented May 8, 2024

dneilroth commented Jul 8, 2024 • edited Loading

mcdee left a comment

Choose a reason for hiding this comment

mcdee Jul 9, 2024

Choose a reason for hiding this comment

pikonha Jul 10, 2024

Choose a reason for hiding this comment

mcdee Jul 9, 2024

Choose a reason for hiding this comment

pikonha Jul 9, 2024

Choose a reason for hiding this comment

mcdee Jul 9, 2024

Choose a reason for hiding this comment

pikonha Jul 9, 2024

Choose a reason for hiding this comment

mcdee Jul 10, 2024

Choose a reason for hiding this comment

pikonha Jul 10, 2024 • edited Loading

Choose a reason for hiding this comment

pikonha commented Jul 9, 2024

mdtanrikulu commented Dec 4, 2024

pikonha commented Mar 19, 2024 •

edited

Loading

mdtanrikulu commented Apr 2, 2024 •

edited

Loading

dneilroth commented Jul 8, 2024 •

edited

Loading

pikonha Jul 10, 2024 •

edited

Loading