Sorry for being very late to the discussion.
I believe in its current iteration, EIP-3668 is a very dangerous feature.
I think not having a global mechanism for verifying the validity of the gateway response is incredibly dangerous. Application-specific validation is just not good enough. Instead of having a blanket CCIP read, we should really have functions for off-chain merkle tree retrieval with built in verification. Same for verifying signatures.
You could have a function verifySignatureFromUrl which returns you the signed message ONLY if it was signed by the trusted public key. Validation SHOULD NOT be application-specific. Same for merkle tree inclusion.
There’s really no good reason for not implementing built-in validation. Sure, just having a CCIP read call allows to swoop all of those use cases in one go, but it creates a glaring hole for abuse for anyone who will be using this for anything else rather than signature validation and merkle tree inclusion tests. Devs will most certainly use it as a weird half-baked oracle. Someone will probably build a protocol which entirely revolves on misusing this feature.
There’s a lot to be said about ‘sane defaults’ and this is not one of them. This feature will misguide newcomers and make them think you can just “magically” read things from external gateways, and by having data inside EVM it suddenly becomes permissionless and fine to use. This feature will misguide web3 critics, who will think, just like in the case of ERC721 tokenURI, that you can just import any data from external gateway and do away with the trusted environment assumptions.
The ERC271 tokenURI debacle was a bombshell when it was pointed out by Moxie in his article Moxie Marlinspike >> Blog >> My first impressions of web3
, this feature on its own will be just as much of a setback for the ecosystem as well.
I really urge for the spec to have full bullet-proof validation of the inputs. I don’t think it can become a ERC in the current way it is - it will be misused, abused, mocked by critics and ultimately be a huge detriment to web3.
You could argue that CCIP read misuse tracking is something we outsource to contract auditors. I disagree. Contract auditing is a necessary evil, but we should avoid making a misguided protocol decisions which allow developers to shoot themselves and their users in the foot. I believe that having a more limited, but robust protocol is beneficial.
Maybe we should have a special mark for any contract that uses
EIP-3668. Perhaps to use this feature, you need to specify
pragma ccip_read; so that users and devs can see straight away that this particular contract uses the feature and evaluate it accordingly.