I’ve spent the past week or so heads-down on CCIP Read, ENS and Chainlink’s solution to resolving ENS names from offchain data (including L2s), and wanted to give everyone a development update - and a call to action, as it’s now ready for devs to start playing with it.
First off, I’ve made substantial changes to the spec. It’s now formulated around offchain callbacks, which removes the need for a ‘prefix’ of the return data that the client validates, simplifies the interface for both contract and gateway server, and should make it easier to understand, as it’s now utilising a fairly standard callback mechanism. I think this also makes clear that there’s a wide variety of potential uses for this standard beyond ENS, too - it’s basically a “pull” protocol, where standard oracles are “push”.
I think it’s realistic to move the EIP to last call soon, and I’d like to get feedback from developers on any changes we should make before then.
- Implements the changes from the spec mentioned above.
- Restructures the repository as a monorepo.
- More READMEs and documentation.
- Adds a package for an Ethers provider that allows you to use CCIP read in your webapp by changing a single line of code.
- Rewrites the ‘trusted token’ example to use the new server framework and the Ethers provider.
The Ethers provider makes using CCIP read particularly simple. If you currently set up Ethers like this:
const ethers = require('ethers'); const provider = ethers.getDefaultProvider('mainnet');
Adding CCIP read support is as simple as doing this:
const ethers = require('ethers'); const ccipread = require('@smartcontractkit/ethers-ccip-read-provider'); const provider = new ccipread.CCIPReadProvider(Ethers.getDefaultProvider('mainnet'));
If you’re interested in exploring this functionality, please take a look - and come back with any feedback or criticisms you have on how easy and practical it is to use. I’ll aim to update this post with a more detailed “howto create a CCIP-read app and contract” post in the near future.