Generic Verifiers

[LayneHaber]

Summary

This feature allows pointing to an external contract to evaluate whether a transaction should be cancelled or fulfilled. The current contracts restrict the fulfillment and cancellation conditions to verifying a user signature, making direct contract integrations difficult.

Motivation

Without a way to delegate the ability to mark a transaction as "fulfilled" to an arbitrary contract, many contract-based use cases would need custom code rather than allowing a native integration.

Proposed Solution

The team maintains a whitelisted registry of Verifiers that is identical across all supported chains. This VerifierRegistry should allow for details about a specific ConditionalVerifier to be retrieved by id (which would be the same across chains). As these verifiers impact the flow of funds throughout the protocol, the code should be reviewed and subject to approval by maintainers.

The InvariantTransactionData should be modified to include the following additional fields:

struct InvariantTransactionData {
  ...
  // Arbitrary encoded data needed to be specified on `SenderPrepare` that may need to be accessed 
  // by the functions in the verifier (i.e. the `lock` for a hash lock verifier)
  bytes calldata verifierData;
  // The unique id for the verifier logic stored in the registry
  bytes32 verifierId;
}

Each ConditionVerifier should implement the following interface:

interface IConditionVerifier {

  // Called prior to executing fulfill
  function shouldFulfill(
    TransactionData calldata txData,
    bytes calldata unlockData,
    uint256 transactionManagerChainId
  ) external pure returns (bool);

  // Called prior to executing cancel
  function shouldCancel(
    TransactionData calldata txData,
    bytes calldata unlockData,
    uint256 transactionManagerChainId
  ) external pure returns (bool);
}

Each interpreter will return a bool indicating whether the validation has passed for that interpreter.

Test Cases

The following tests should be implemented with a simple interpreter:

it("should successfully fulfill if the condition is met", () => { ... })
it("should revert if fulfill condition is not met", () => { ... })
it("should successfully cancel if the condition is met", () => { ... })
it("should revert if cancel condition is not met", () => { ...  })

Additionally, a happy case flow with the following interpreters should be implemented:

• Contract signing
• Oracle based (CCIP)
• MPC based
• Optimistic verification (Nomad)
• Nova
• Block header verification (IBC)

Outstanding Questions

• Instead of using the interpreterName and a library of registered condition interpreters, we can allow the user to pass in the deployed address of the condition on the sending and receiving chain, saving gas.
• Is verification on prepare necessary?

Tasks / PRs

• Much of the work is already done in [DNM] Generic conditions #433
• Update the PR to include a registry
• Implement test cases for ^
• Remove offchain code changes for ^

[rhlsthrm]

I want to make sure we enumerate some of the fulfill conditions that are possible to implement and make sure our protocol is flexible enough to support.

Here are some conditions I thought of so far, will add more as needed.

• Simple hashlock transfer
• Contract-based signing (https://eips.ethereum.org/EIPS/eip-1271)
• Rari Nova fulfillment
• Oracle-based (CCIP)
• MPC-based (is there an API for this?)
  I'd like to actually write out what the Solidity code for each interpreter is, so we can build an interface.

[LayneHaber]

Agree, the full flow should work with those interpreters and each one can be unit-tested. Would also add:

• Multipath transfers (multiple routers providing liquidity for a single transfer)

[ArjunBhuptani]

Missing from the above list:

• Block header verification (IBC)
• Optimistic verification (Nomad)

Multipath transfers (multiple routers providing liquidity for a single transfer)

@LayneHaber and I chatted about this a bit more and decided that it would be a good idea to have a logical separation between verifiers (under what conditions does a transfer get unlocked) and routing (how does the transfer get set up in the first place). This means that multipath/multihop should be built directly into the core contracts.

[jakekidd]

This means that multipath/multihop should be built directly into the core contracts.

I agree with this a lot

[sanchaymittal]

Couple of queries

Queries:

• Why do we need to add a balance struct? We can simply extract the information from Transaction Data.
• How will these conditions for validation or sanity check will look like? Can we share an example here?

Addressing the Outstanding questions:

Instead of using the interpreter name and a library of registered condition interpreters, we can allow the user to pass in the deployed address of the condition on the sending and receiving chain, saving gas.

Yeah, this sounds better.

Adding the shouldPrepare function allows the TransactionData to be verified with respect to some definitive rules for the condition, but may not be strictly necessary

This will be probably required on receiving side prepare, depending on the rules we are enforcing.

[ArjunBhuptani]

I generally think we should avoid having shouldPrepare be included in this unless we can specifically think of a reason why it should exist. Our current pattern is to have Connext be called into by other contracts when calling prepare, and there's no reason that implementers cannot enforce their own validation prior to the prepare call to achieve the same goal.

We should verify this against Nomad, Nova, and other verifiers we expect to implement to make sure this is the case.

[sanchaymittal]

@LayneHaber still not clear about the requirement of balance struct

[LayneHaber]

Originated in having Multipath and Multihop interpreters -- but I think it's fine to keep this interface more expressive. Is there a reason you don't like it?

[sanchaymittal]

No I'm just not clear about it's requirement.

[LayneHaber]

Updated the original to include:

• name changes
• default to not including prepare
• updated test cases
• InvariantTransactionData changes

[LayneHaber]

Moving discussion to archive, may no longer be necessary with the generic messaging direction.