feat: Implement a facade contract that verifies a signature before calling settle

[fleupold]

Problem

Solvers can theoretically submit solutions outside of the competition (simply calling settle with a bunch of signed orders). The way this is prevented is by requiring large bonds being put up by solvers in order to get allow listed. Those bonds pose a barrier to entry for the protocol. In the current state, they cannot be easily reduced without adding additional risk to the system.

The potential damage can be broadly differentiated into two parts

1. Economic damage to the protocol (withdrawal of token balances stored in the settlement contract, e.g. by incurring high slippage, setting a bad allowance, or simply transferring out funds)
2. Economic damage to the user (settling orders out of competition at limit price, omission of pre/post interactions, etc).

While 1. is fairly contained and can be mitigated by frequently withdrawing internal buffers, 2. poses a much bigger risk to the protocol and is the main reason high bonds are required.

Suggested solution

Have the off-chain auction provide a signature attesting that a specific solver has indeed won the settlement they are trying to settle. The signature would attest to the following things:

1. Which solver has won the competition
2. Which order uids are expected to be executed and at what clearing prices (exact match, ie the solver is not allowed to add more orders)
3. Any pre/post interactions those orders are expected to yield (the solver may add additional pre and post interactions)

We would then have an intermediary contract intercept a solver's settle call, verify that their solution is indeed in line with the attestation committed to by the auctioneer and in this case forward the settle call to the main settlement contract. The intermediary contract would be associated with a full bond and allow-listed in the main settlement contract. Solvers would still require to post some amount of bond (cf. risk 1 above), but the bond could be significantly smaller and in a separate allow-list. in the future there could be many such intermediary contracts (one per bonding pool).

This would allow smaller capitalised solvers participate in the auction.

Acceptance Criteria

• Smart contract built with foundry and extensive test suite
• Implements the following logic:
  • Expose a method that accepts a solution and signature
  • Checks msg.sender is registered
  • Furthermore, computes commitment by hashing
    • msg.sender
    • auction id
    • included order uids and executions (buy/sell amounts)
    • a subset of interactions
  • Ecrecovers signer from signature using the commitment and asserts it matches the configured auctioneer
  • Forwards provided solution into the GPv2Settlement contract's settle call

[mfw78]

We are currently nearing the completion of the sub-pool mechanism and then will be moving to implement the actual facade contract. In doing so, the question has come up as to which interactions should be verified by signature (in this issue, it highlights a subset as the autopilot only knows which orders are going to be included, but does not know the precise interactions for swaps, and therefore can only deduce order-originated interactions).

This creates complexity around defining a signedSettle interface that in and of itself will require custom settlement encoding (if only using a subset). At the root of my concern is that:

1. CoW DAO's bonding pool is an entity that is using / settling on CoW Protocol. CoW DAO != CoW Protocol.
2. Given (1), it does not make sense architecturally to enshrine sub-pools at the "protocol" level (where protocol in this context is the auto-pilot).

Given that there is a strict requirement that there will have to be custom settlement encoding, architecturally it seems that the driver being operated by sub-pool bonded solvers should actually be reporting to some other piece of architecture that is different entirely (i.e. not the autopilot, but some "meta" driver that is able to sign on behalf of the CoW DAO bonding pool).

Given this nuance in architecture, it would also mean that any driver/architectural piece that is signing off on a sub-pool bonded solver on behalf of the CoW DAO bonding pool, would be in receipt of all interactions, and therefore this would be able to have knowledge of the complete set of interactions for signing.

tl;dr I'm hesitant on this being enshrined within the autopilot as it doesn't seem to be an appropriate architectural fit.