Cross chain execution and payments via UserOps

contracts/SCBridgeWallet.sol

@@ -1,17 +1,24 @@
 pragma solidity 0.8.19;
 
 // SPDX-License-Identifier: MIT
-
 import {IAccount} from "contracts/interfaces/IAccount.sol";
 import {UserOperation} from "contracts/interfaces/UserOperation.sol";
 import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
 import {HTLC, State, hashState, checkSignatures, Participant} from "./state.sol";
+import {UserOperationLib} from "contracts/core/UserOperationLib.sol";
+import {ExecuteChainInfo, PaymentChainInfo} from "./state.sol";
+
 enum WalletStatus {
   OPEN,
   CHALLENGE_RAISED,
   FINALIZED
 }
 
+enum NonceKey {
+  SHARED,
+  OWNER
+}
+
 uint constant CHALLENGE_WAIT = 1 days;
 
 contract SCBridgeWallet is IAccount {
@@ -100,7 +107,10 @@ contract SCBridgeWallet is IAccount {
     bytes calldata intermediarySignature
   ) external {
     checkSignatures(state, ownerSignature, intermediarySignature);
+    internalChallenge(state);
+  }
 
+  function internalChallenge(State calldata state) internal {
     WalletStatus status = getStatus();
 
     require(status != WalletStatus.FINALIZED, "Wallet already finalized");
@@ -125,7 +135,26 @@ contract SCBridgeWallet is IAccount {
     challengeExpiry = largestTimeLock + CHALLENGE_WAIT;
   }
 
-  function execute(address dest, uint256 value, bytes calldata func) external {
+  /// crossChain is a special function that handles cross chain execution and payment
+  function crossChain(
+    ExecuteChainInfo[] calldata e,
+    PaymentChainInfo[] calldata p
+  ) public {
+    // Only the entrypoint should trigger this by excecuting a UserOp
+    require(msg.sender == entrypoint, "account: not EntryPoint");
+    for (uint i = 0; i < e.length; i++) {
+      if (e[i].chainId == block.chainid) {
+        execute(e[i].dest, e[i].value, e[i].callData);
+      }
+    }
+    for (uint i = 0; i < p.length; i++) {
+      if (p[i].chainId == block.chainid) {
+        internalChallenge(p[i].paymentState);
+      }
+    }
+  }
+
+  function execute(address dest, uint256 value, bytes calldata func) public {
     if (getStatus() == WalletStatus.FINALIZED && activeHTLCs.length == 0) {
       // If the wallet has finalized and all the funds have been reclaimed then the owner can do whatever they want with the remaining funds
       // The owner can call this function directly or the entrypoint can call it on their behalf
@@ -160,24 +189,34 @@ contract SCBridgeWallet is IAccount {
   ) external view returns (uint256 validationData) {
     bytes memory ownerSig = userOp.signature[0:65];
     // The owner of the wallet must always approve of any user operation to execute on it's behalf
-    require(
-      validateSignature(userOpHash, ownerSig, owner) ==
-        SIG_VALIDATION_SUCCEEDED,
-      "owner must sign"
-    );
+    if (
+      validateSignature(userOpHash, ownerSig, owner) != SIG_VALIDATION_SUCCEEDED
+    ) {
+      return SIG_VALIDATION_FAILED;
+    }
 
     // If the wallet is finalized then the owner can do whatever they want with the remaining funds
     if (getStatus() == WalletStatus.FINALIZED) {
       return SIG_VALIDATION_SUCCEEDED;
     }
 
+    bytes4 functionSelector = bytes4(userOp.callData[0:4]);
+    NonceKey key = NonceKey(userOp.nonce >> 64);
+
+    // If the function is crossChain, we use validate using the chainids and entrypoints from the calldata
+    if (
+      functionSelector == this.crossChain.selector && key == NonceKey.SHARED
+    ) {
+      validateCrossChain(userOp);
+    }
+
     // If the function is permitted, it can be called at any time
     // (including when the wallet is in CHALLENGE_RAISED) with no futher checks.
-    bytes4 functionSelector = bytes4(userOp.callData[0:4]);
-    if (permitted(functionSelector)) return SIG_VALIDATION_SUCCEEDED;
+    if (permitted(functionSelector) && key == NonceKey.OWNER)
+      return SIG_VALIDATION_SUCCEEDED;
 
     // If the wallet is open, we need to apply extra conditions:
-    if (getStatus() == WalletStatus.OPEN) {
+    if (getStatus() == WalletStatus.OPEN && key == NonceKey.SHARED) {
       bytes memory intermediarySig = userOp.signature[65:130];
       return validateSignature(userOpHash, intermediarySig, intermediary);
     }
@@ -194,6 +233,73 @@ contract SCBridgeWallet is IAccount {
   uint256 internal constant SIG_VALIDATION_SUCCEEDED = 0;
   uint256 internal constant SIG_VALIDATION_FAILED = 1;
 
+  /// This validates the crossChain UserOp
+  /// It ensures that it signed by the owner and intermediary on every chain
+  /// It also ensures that the UserOp targets the current chain and entrypoint
+  function validateCrossChain(UserOperation calldata userOp) private view {
+    (ExecuteChainInfo[] memory e, PaymentChainInfo[] memory p) = abi.decode(
+      userOp.callData[4:],
+      (ExecuteChainInfo[], PaymentChainInfo[])
+    );
+
+    bool foundExecute = false;
+    bool foundPayment = false;
+
+    // We expect every owner and intermediary on every chain to have signed the userOpHash
+    // For each chain we expect a signature from the owner and intermediary
+    require(
+      userOp.signature.length == (e.length + p.length) * 65 * 2,
+      "Invalid signature length"
+    );
+
+    for (uint i = 0; i < e.length; i++) {
+      if (e[i].chainId == block.chainid && e[i].entrypoint == entrypoint) {
+        foundExecute = true;
+      }
+
+      // TODO: I think we could just have everyone signed the UserOpHash for the first chain, instead of generating a new hash for each chain?
+      // Check that the owner and intermediary have signed the userOpHash on the execution chain
+      bytes32 userOpHash = generateUserOpHash(
+        userOp,
+        e[i].entrypoint,
+        e[i].chainId
+      );
+
+      uint offset = i * 65;
+      bytes memory ownerSig = userOp.signature[offset:offset + 65];
+      bytes memory intermediarySig = userOp.signature[offset + 65:offset + 130];
+      validateSignature(userOpHash, ownerSig, e[i].owner);
+      validateSignature(userOpHash, intermediarySig, e[i].intermediary);
+    }
+
+    for (uint i = 0; i < p.length; i++) {
+      if (p[i].chainId == block.chainid && p[i].entrypoint == entrypoint) {
+        foundPayment = true;
+      }
+
+      // Check that the owner and intermediary have signed the userOpHash on the payment chain
+      bytes32 userOpHash = generateUserOpHash(
+        userOp,
+        p[i].entrypoint,
+        p[i].chainId
+      );
+      uint offset = (e.length + i) * 65;
+      bytes memory ownerSig = userOp.signature[offset:offset + 65];
+      bytes memory intermediarySig = userOp.signature[offset + 65:offset + 130];
+      validateSignature(userOpHash, ownerSig, p[i].paymentState.owner);
+      validateSignature(
+        userOpHash,
+        intermediarySig,
+        p[i].paymentState.intermediary
+      );
+    }
+
+    require(
+      foundExecute || foundPayment,
+      "Must target execution or payment chain"
+    );
+  }
+
   function validateSignature(
     bytes32 userOpHash,
     bytes memory signature,
@@ -215,3 +321,13 @@ contract SCBridgeWallet is IAccount {
     return true;
   }
 }
+using UserOperationLib for UserOperation;
+
+/// @dev Based on the entrypoint implementation
+function generateUserOpHash(
+  UserOperation calldata userOp,
+  address entrypoint,
+  uint chainId
+) pure returns (bytes32) {
+  return keccak256(abi.encode(userOp.hash(), entrypoint, chainId));
+}

contracts/state.sol

@@ -3,47 +3,64 @@ pragma solidity 0.8.19;
 // SPDX-License-Identifier: MIT
 import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
 struct State {
-    address payable owner;
-    address payable intermediary;
-    uint turnNum;
-    uint intermediaryBalance;
-    HTLC[] htlcs;
+  address payable owner;
+  address payable intermediary;
+  uint turnNum;
+  uint intermediaryBalance;
+  HTLC[] htlcs;
 }
 
 enum Participant {
-    OWNER,
-    INTERMEDIARY
+  OWNER,
+  INTERMEDIARY
 }
 
 struct HTLC {
-    Participant to;
-    uint amount;
-    bytes32 hashLock;
-    uint timelock;
+  Participant to;
+  uint amount;
+  bytes32 hashLock;
+  uint timelock;
 }
 
 function hashState(State memory state) pure returns (bytes32) {
-    return keccak256(abi.encode(state));
+  return keccak256(abi.encode(state));
 }
 
 using ECDSA for bytes32;
 
 function checkSignatures(
-    State calldata state,
-    bytes calldata ownerSignature,
-    bytes calldata intermediarySignature
+  State calldata state,
+  bytes calldata ownerSignature,
+  bytes calldata intermediarySignature
 ) pure {
-    bytes32 stateHash = hashState(state);
-    if (
-        state.owner !=
-        stateHash.toEthSignedMessageHash().recover(ownerSignature)
-    ) {
-        revert("Invalid owner signature");
-    }
-    if (
-        state.intermediary !=
-        stateHash.toEthSignedMessageHash().recover(intermediarySignature)
-    ) {
-        revert("Invalid intermediary signature");
-    }
+  bytes32 stateHash = hashState(state);
+  if (
+    state.owner != stateHash.toEthSignedMessageHash().recover(ownerSignature)
+  ) {
+    revert("Invalid owner signature");
+  }
+  if (
+    state.intermediary !=
+    stateHash.toEthSignedMessageHash().recover(intermediarySignature)
+  ) {
+    revert("Invalid intermediary signature");
+  }
+}
+
+/// Contains information to execute a function call
+struct ExecuteChainInfo {
+  uint chainId;
+  address entrypoint;
+  address dest;
+  uint value;
+  bytes callData;
+  address owner;
+  address intermediary;
+}
+
+/// Contains information to execute a payment
+struct PaymentChainInfo {
+  uint chainId;
+  address entrypoint;
+  State paymentState;
 }

docs/cross-chain-payments-and-execution.md

@@ -0,0 +1,77 @@
+## Cross chain payments and execution
+
+This document suggests an approach of using `UserOp`s to perform cross-chain payments and execution. At a very high level this approach can be thought of as a cross-chain state channel, where we have some state, that when fully signed can be submitted to an adjudicator contract to claim the funds based on the outcome of that state.
+
+However instead of implementing the state channel framework ourselves, we're making use of some of ERC 4337 infrastructure. Instead of signing a state, participants sign a **UserOp** that contains the state information. Instead of having a specific "adjudicator" contract, we have the **entrypoint** and the **BridgeWallet SCW** to handle adjudicating funds. Instead of making a on-chain call to challenge on the adjudicator, we can submit the `UserOp` to an entrypoint to trigger a challenge.
+
+Since we can specify the UserOp calldata, we can include whatever additional state information we want in that calldata. That lets us embed payment or execution information for different chains in one UserOp. When submitted to chain the UserOp will behave depending on the chain Id and the embedded payment or execution information.
+
+# Payments
+
+We embed payment information in the UserOp using a `PaymentChainInfo`
+
+```sol
+/// Contains information to execute a payment
+struct PaymentChainInfo {
+  uint chainId;
+  address entrypoint;
+  State paymentState;
+}
+
+```
+
+Whenever a fully signed UserOp containing a `PaymentChainInfo` is submitted to chain, it forces a challenge on that chain. This means that once you have a fully signed UserOp you know you can always use it to get your funds via challenge. In the happy path, we would expect participants to just exchange signed states afterwards, so they can discard the UserOp.
+
+## Cross-chain Payment Example
+
+Let's say we have Alice, Bob,and Irene. Alice and Irene have a BridgeWallet on chain A, Bob and Irene have a BridgeWallet on Chain B. Alice and Irene have both signed a state with a balance of `[A:5,I:5]`, and bob and Irene have likewise have a signed state with a balance of`[B:5,I:5]`. Let's say Alice wants to pay Bob.
+
+1. Alice creates two new unsigned states `[A:4,I:6]` and `[B:6,I:4]`
+2. Alice includes them in a UserOp(wrapped in a `PaymentChainInfo`), and signs the UserOp. She sends this to Bob and Irene.
+3. Bob and Irene validate the UserOp and also sign it, and broadcast it.
+4. At this point the UserOp is fully signed and can be used to force a challenge on either chain, by submitting the signed UserOp to the entrypoint on either chain.
+
+# Cross-chain Execution
+
+We can also extend this idea to cross chain execution. Instead of embedding a payment state in the `UserOp` we embed information to make an on-chain function call. If the `UserOp` is submitted to the `entrypoint` the function will be executed **if the chainId matches the chain**.
+
+We embed this information using a `ExecuteChainInfo`
+
+```sol
+/// Contains information to execute a function call
+struct ExecuteChainInfo {
+  uint chainId;
+  address entrypoint;
+  address dest;
+  uint value;
+  bytes callData;
+  address owner;
+  address intermediary;
+}
+```
+
+A UserOp can contain multiple `ExecuteChainInfo`s, meaning you can have "atomic" cross chain execution (once the UserOp is fully signed, you're guaranteed you can trigger the execution on either chain). A UserOp can also contain `PaymentChainInfo`s and `ExecuteChainInfos` allowing to pay for cross-chain execution.
+
+# Multihop
+
+Since a UserOp can contain multiple `PaymentChainInfo`s and `ExecuteChainInfos`, this approach can be used for multi-hop execution or payments. We just require the `owner` and `intermediary` of every BridgeWallet involved to sign the UserOp.
+
+# Replay Attacks
+
+It's important that we're not vulnerable to replay attacks, where a `UserOp` is submitted again using a different entrypoint or chain.
+
+If we're working on one chain, it's fairly easy to prevent replay attacks. The `userOpHash` [provided by the Entrypoint](https://github.com/magmo/Bridge-Wallet/blob/ad6d24fa2435f449751d1b61e24d12faff1f83a9/contracts/core/EntryPoint.sol#L298) to `validateUserOp` is hashed against the current chain and entrypoint. This means that if the UserOp is run against a different chain or entrypoint, there will be a different `userOpHash` causing all the signature checks to fail.
+
+With cross-chain execution and payments we need a slightly more complicated check. To prevent replay attacks we ensure that one of the `ExecuteChainInfo` or `PaymentChainInfo` matches our chainId and entrypoint. This ensures that the `UserOp` will only be handled by the chain/entrypoint specified by the `ExecuteChainInfo/PaymentChainInfo`.
+
+# Signatures
+
+We expect the UserOp to be signed by the `owner` and `intermediary` of every BridgeWallet involved. So based on the example above with Alice,Irene,Bob, we'd expect the signatures `[AliceSigChainA,IreneSigChainA,IreneSigChainB,BobSigChainB]`.
+
+When validating signatures we iterate through the `ExecuteChainInfo` and `PaymentChainInfo` and check the signatures against the hash generated using the chain id/entrypoint from the ChainInfo. It's important that we validate the signature for other chains, because that guarantees the UserOp is "atomic". Otherwise a partially signed UserOp could be redeemed on one chain, while not being redeemable on the other chain.
+
+# Nonces
+
+We need to be careful with how we use nonces. The `owner` of a BridgeWallet can always submit a UserOp to [trigger a](https://github.com/magmo/Bridge-Wallet/blob/66dbb9c41ea8830218265b4def76824320df6bca/contracts/SCBridgeWallet.sol#L207) `Challenge` or `Reclaim` call. So if we have a UserOp signed by everyone with some `nonce`, the `owner` could submit a UserOp just signed by them burning the nonce, and preventing the UserOp signed by everyone from being handled.
+
+Luckily ERC 4337 provides ["Semi-abstracted Nonce Support"](https://eips.ethereum.org/EIPS/eip-4337#semi-abstracted-nonce-support) where the first 192 bits of the nonce are treated as a `key` and the last 64 bits are the `sequence`. This means we can use a separate nonce for calls to `crossChain`, preventing the `owner` from burning the nonce and preventing the `crossChain` call.