[CCIP-7723] Define & Implement ICrossChainVerifierResolver

[kylesmartin]

Ticket: https://smartcontract-it.atlassian.net/browse/CCIP-7723

[0xsuryansh]

The resolver requires the first 4 bytes of ccvData to encode a version, but the blobs we emit are whatever the underlying verifier returns (e.g. the
current committee verifier returns ""). When we attempt to route verification through the resolver will revert with InvalidCCVDataLength right ?

I think if we are going with this "versioning" approach then CommitVerifier should prepend the version in verifierReturnData

[kylesmartin]

Thanks, meant to add this in.

[RensR]

The source CCVData is not the same as what is sent on dest. Offchain is responsible for getting the dest data and consuming source. There is no requirement that the version comes from source

[kylesmartin]

In the DD I posed a couple options we can take for the CommitteeVerifier specifically:

• CommitteeVerifier returns version as part of forwardToVerifier return data. We will use bytes4 to represent the version, as we’ve established precedent here with USDC. This information is then included in CCIPMessageSent.receiptBlobs and subsequently parsed by each verifier node. The aggregator would then need to validate that each verifier node pulled the same version before it can prepend the version to the signatures and write to storage.
• The aggregator service stores the verifier version assigned to each destination chain and prepends it to the ccvData for a particular VerifierResult.

I prefer the first because option 2 creates duplicated config. I've got offchain sign off on it as well.

[0xsuryansh]

Regarding OnRamp._parseExtraArgsWithDefaults
Consider the following scenario..

• Lane defaults point at ProxyA (just a plain proxy that resolves to VerifierImpl).
• A user supplies ProxyB which implements the resolver interface and also returns VerifierImpl.

Pre-resolution ProxyA != ProxyB, so both survive the merge. Post-resolution both map to VerifierImpl, so we’ll call forwardToVerifier twice and sum its fee twice. Until we either (a) dedupe after resolution or (b) guarantee that no two proxies/resolvers can collapse to the same implementation..

Thoughts on this edge case ?

cc : @RensR

[kylesmartin]

@0xsuryansh good call-out in your top level comment, resolution generally needs to happen as immediately as possible.

[kylesmartin]

Pre-resolution ProxyA != ProxyB, so both survive the merge. Post-resolution both map to VerifierImpl, so we’ll call forwardToVerifier twice and sum its fee twice. Until we either (a) dedupe after resolution or (b) guarantee that no two proxies/resolvers can collapse to the same implementation..

Thinking about it more, I actually don't think this is an issue. Different verifier addresses are effectively different entities. If they resolve to the same implementation, it shouldn't matter. They just happen to be using the same implementation. They should each still get their fee.

[github-actions]

Metric	CCIP-7723	develop
Coverage	69.4%	68.7%