[Epic] 7.1: Ext. solvers operating driver

[fleupold]

Epic label: E:7.1 Ext. solvers operating driver
Planned start date: April 15th
Due date: June 30th

Summary

We want at least 3 external solvers running their own driver on mainnet by the end of Q2. This serves as a sanity check that full decentralisation of the matching engine is achievable by the end of the year and will allow us to count on "solely colocated" L2 deployments for Q3.

Deploying on a new network without having to run driver + Gnosis solvers will drastically reduce our development and maintenance overhead.

Acceptance Criteria

Three solvers are running their own driver (and control the solutions submission as well as their submission account).

Risks

With great power comes great responsibility. As soon as solvers own their own private keys they could potentially violate some of the competition's rules. Solvers are bonded with significant stake, however in practice the bond is currently covered by CoW DAO which has some minimal KYC from the solvers it vouches for. At the same time, requiring solvers to come up with the entire bond themselves has turned out to be a large barrier for adopting the new infrastructure.

We can differentiate between attack vectors that are already possible in today's architecture and one emerging in a fully colocated world.

Existing attack vectors

• Drain buffers
• Set bad allowance

Given the current cadence of fee withdrawal we assume this attack vector to be around ~$200k, whereby damage is only accrued to CoW DAO (not users). Note, that other than rudimentary KYC there are no bonding requirements for the solver despite this attack vector.

New attack vectors

• Settle even though solver didn’t win
• Missing pre/post interactions
• Mess up fees computation (will lead to high negative slippage)

Fee computation errors are comprised in the existing buffer attack vector. While the the financial damage of omissions of pre/post interactions is hard to assess, we can estimate the amount of surplus (limit vs. execution price) a malicious solver could extract if settling order our of competition: Assuming proper detection and prompt disconnecting of solver we estimate the potential to be ~$300k (https://dune.com/queries/3667248).

It is important to note, that this damage would affect users of the protocol is thus more severe than buffer attacks.

Risk Mitigation

In order to mitigate the risk of misbehaviour while justifying smaller bonding requirements there are two initiatives we need to push.

Circuit Breaker

The size of damage heavily depends on how fast misbehaviour is detected and the solver is disconnected. If a solver starts settling orders outside of competition for instance it could potentially capture the entire difference between limit price and fair price of all orders until stopped.

Any violation of rules (and even accrual of significant negative liabilities such as fees or negative slippage) should thus be monitored and automatically acted upon if thresholds are reached.

Autopilot Signatures

In order to mitigate the new attack vectors mentioned above while still giving solvers control over the submission logic and their private keys, the autopilot could provide a signature to the solver, which commits to certain key aspects of the solution (ie. the fact that this solver won, the orders that need to get included, the execution price, etc).

We could then allow-list a meta contract to call settle on CoW Protocol, which takes the exact same arguments as settle but performs two additional checks

1. Solver is allow listed in another registry (joining which requires significantly less bond)
2. The solution is accompanied with an autopilot signature attesting that this settlement has won the competition

While this would alleviate all new attack vectors, it would also enshrine the autopilot as a long term centralized auctioneer (whose signature is required for the protocol to operate). While this would increase decentralisation in the short term it might chase a local optimum (some decentralisation) while making the global optimum (full decentralisation also of the autopilot) harder to achieve.
A counter argument to this concern is that even in the future we may have multiple autopilots (all of which are heavily bonded) who can chose to delegate execution rights to less well bonded solvers on the premise of having a look/verifying their solutions before allowing them to settle.

Another concern about this setup is the increased gas overhead of using the intermediary contract.

Tasks

Breakdown of the work (bold items are considered launch blocking)

Solver Team:

• Bonding Criteria for Colocated Drivers #60
• Implement standalone monitoring/circuit breaker infrastructure

Backend Team

Issues tracked as part of here

• Remove assumptions in autopilot about driver behaving in implementation specific ways
• feat: Implement basic circuit breaker in autopilot services#2667

Smart Contracts:

• Automate fee withdrawal process to reduce our exposure to malicious actions and reduce pressure on the bonding size (https://github.com/cowdao-grants/cow-fee)
• feat: Implement a facade contract that verifies a signature before calling settle contracts#84

Solver Adoption Status

• PLM
  • can start working on this in June
• Otex
• Copium
• Barter
• Rizzolver
• Dialectic
  • Want to start solving immediately
  • Waiting for them to join shadow competition