| The WhitePaper Reading Club X Devcon | Nov 16 2024 |
|---|---|
| ERC 3668: CCIP Read: Secure offchain data retrieval | https://eips.ethereum.org/EIPS/eip-3668 |
| Is offchain data and compute the way forwards? | Roni |
Summary
Create a standard for offchain data retrieval.
Why This Is Important
Eliminate the need to write bespoke code for the retrieval of information from multiple storage sources. The main goal is to optimize cost and scalability without compromising data integrity.
Common Use Cases
(i) DeFi price feeds from oracles (ii) NFT metadata where the data is stored offchain due to size (iii) Cross chain decentralized identity verification (iv) IoT data verification - fetch real time data from IoT devices. (v) The first application to implement the standard was ENS. By leveraging CCIP Read, name resolution can be taken cross-chain, off-chain, and more. This allows for a lot of flexibility in how you can use your ENS and for storage of your ENS records on your favorite Layer 2, or even off-chain.
Key Innovation
ERC 3668 will simplify clients who consume onchain or offchain data and make them agnostic to the storage solution being used. The key benefits are quicker development time and a significant reduction in maintenance of the client code, as well as reduced cost that is incurred during the lookup process. The benefits will result from the standardization of the retrieval process.
Overview
The standard implements the CCIP (Cross-Chain Interoperability Protocol) Read, which allows contracts to retrieve data directly from external sources without intermediaries. This reduces reliance on centralized oracles and improves data integrity by directly linking the data source to the smart contract. The retrieval process of data includes 3 entities:
- Client: initiates a call to the smart contract
- Smart Contract: requests data, provides the location (url) and contextual info for the retrieval and acts on the data
- Gateway: a service which fetches the data
All three entities must implement the CCIP standard.
Background
Minimizing storage and transaction costs on Ethereum has driven contract authors to adopt a variety of techniques for moving data offchain. Thus far, applications have tended to devise bespoke solutions rather than trying to define a universal standard. This is easy to do when a single offchain storage solution is used but becomes highly inefficient when working with multiple storage solutions. It also requires increased maintenance as the code may need to be updated when any of the storage solutions update their interface.
Team
Creator of the standard: Nick Johnson (@arachnid). Developers of generic implementation: Alex (@AlexNi245), Makoto Inoue (@makoto) , @hai-ko, Steffen Kux (@steffenkux)
Opinions
Overall, ERC-3668 seems like a step forward in simplifying the coding process and reducing cost by removing intermediaries in the lookup process. The removal of intermediaries also enhances security. However, the protocol itself cannot enforce all of the required validity checks and only recommends best practices.
Components (Generic Implementation of ERC-3668)
| ERC3668Resolver | The core contract implementing the Ccip Interface. It delegates the actual implementation to an instance of the CcipVerifier contract. |
|---|---|
| CcipResponseVerifier | An app specific Handler needs a CcipResponseVerifier contract that implements the resolveWithProof function accordingly. For example, the handler related to the optimism-Bedrock validates the Merkle proof for the returned data and ensures it is part of the Optimism Network.Proof Types:Digital Signatures: The data is signed using a private key associated with a trusted verifier. The recipient smart contract can use the associated public key to verify the signature and ensure that the data came from a legitimate source.Merkle Proofs: For data fetched from another blockchain (like an L2 solution), a Merkle proof may be used. The proof shows that the data exists in a specific state root of the blockchain, making it verifiable against the canonical state posted on Ethereum mainnet |
| BedrockCcipVerifier | An implementation of the CcipResponseVerifier Interface. This contract proves data from a certain contract |
| Gateway | A Node.js app resolving incoming requests made by the CCIP Reader. It queries the Type Specific handler defined in the Config to retrieve the desired data. |
| Trust Model | The standard was designed with security considerations and includes specific fields for data validation. The validation is done by the Contract and performed on the response from the Gateway and Client. However, the details of the validation is application-specific and not specified in the standard. |
References
(i) https://eips.ethereum.org/EIPS/eip-3668 (ii) https://github.com/dm3-org/Ccip-Resolver (iii) https://docs.ens.domains/resolvers/ccip-read