Ccip read

[mdtanrikulu]

Motivation

The goal of this PR is to integrate CCIP-read and wildcard resolution functionalities into the ether-rs.

CCIP-read (Chain Agnostic Communication Interface Protocol for reading data) is a protocol designed to standardize cross-chain data reading, enabling communication and interoperability between various blockchain platforms and/or offchain.

EIP-2544 (Wildcard Resolution) adds wildcard support for (ENS) subdomains to enable more flexible name resolution and advanced resolver creation without modifying existing contracts or resolvers. This change is backwards-compatible and does not affect the resolution of existing ENS records.

Solution

Both CCIP-Read and Wildcard Resolution features are in working condition at the time of creating this PR. However I would be happy to get feedback, regarding implementation details.

There are few things left unfinished, like validate_resolver function. I had to disable the check, due to how CCIP-Read works with unhandled interfaces. One option may be keeping the check if wildcard resolution support is not available (not really sure though, I will be checking).

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[prestwich]

This is out of scope for the crate it's in, as CCIP requests are not part of standard Ethereum functionality. We would recommend an extension trait for the middleware, in a separate workspace

pub trait CcipRead: Middleware {}

impl<T> CcipRead for T where T: Middleware {}

[lucemans]

If I may I would highly recommend giving this a second look @prestwich @gakonst . EIP-3668 is an officialy approved and endorsed Ethereum Improvement Proposal, and is actively supported not only by ethers.js, but also by most other ethereum libraries.

Having native support in ethers.rs would allow anyone to leverage CCIP functionality (as its not ENS specific), and it is part of how ethereum data retrieval works as a whole.

[prestwich]

the ethers-provider crate and Middleware trait handle Ethereum JSON-RPC requests, not calls to other services. You're welcome to implement this functionality elsewhere

[gakonst]

For extra context, we're trying to clean up ethers from tech debt and would like to avoid taking on new code to maintain which is not related to core json-rpc functionality. Would it be OK with you to implement that on your own as an extension trait like James wrote above?

[mdtanrikulu]

Thank you for the context. I am looking into the middleware concept as both of you suggested.