chore: Rewrite The Optimisation Problem

[fleupold]

Background

https://beta.docs.cow.fi/cow-protocol/reference/core/auctions/the-problem reads unnecessarily mathematical (e.g. why do we define the order as an n dimensional vector with two elements set) and not really practical for anyone trying to actually understand what the system is trying to enforce. It doesn't for instance mention user balances (endowments) which may not be available for the orders they placed

Details

I'd suggest rewriting this section making it more practical (what do we actually enforce, vs what are soft criteria) and less math heavy.

Acceptance criteria

Someone without a strong math background can get a clear picture of what solvers need to optimize.

[acanidio-econ]

IMO, it really depends on who is the target audience. Because it is the technical documentation, we wrote it thinking of someone with a background in optimization working with/for a solver. The point is to specify the problem in mathematical terms so that this person can solve it using standard optimization techniques -- essentially the problem is a standard-constrained maximization problem because the constraints (i.e., limit prices) can be seen as sets.

But we are indeed more general than what is strictly necessary, both in defining what is an order and what are fees. This is useful if we want to change something tomorrow (like introducing new types of orders like basket orders). It helps with maintaining the documentation but also with implementing changes. For example, I would love it if solvers thought of orders as acceptance sets and perhaps treat them as such in their architecture, so if tomorrow we introduce new order types, they will immediately understand what we are talking about and more quickly implement them. This generality was also useful wrt to fees: everything we wrote back then is still valid under our new fee structure

[acanidio-econ]

In any case, I dropped part of the "high-level math discussion" such as the discussion of how the acceptance set mush have both positive and negative elements, as it us not relevant for understanding what comes next

[fleupold]

Oh, I didn't know this was already re-written for the new docs. In that case, if you feel this is better suited, feel free to ignore my comment. I was just guided by the mentioned acceptance tests (which sounded like things we used to verify, but are no longer checking, token conservation for instance). I was also reminded that originally we were describing the problem in a very mathy way that according to e.g. Eric Budish was just disguising what we actually want to bring across.

If this version is "econ approved" that's fine.

One thing it is still missing though is a mention that endowments are not guaranteed to suffice for all orders. Ie. a user may have multiple open limit orders selling the 1 WETH of balance they have for USDC, DAI, etc simultaneously.

[acanidio-econ]

We rewrote it in May. Cool, we'll add this as a constraint to the solution: essentially, a solution is valid if users have enough sell tokens in their wallet.

[acanidio-econ]

BTW, while adding this constraint, I propose to drop the one that says:

Maximum size of solution: The total number of trades does not exceed a certain number within each batch due to limitations regarding the size of a block on the blockchain.

it seems obvious that the solution needs to respect the constraints imposed by the blockchain: it cannot exceed the block size, it cannot re-use an old nonce, etc.. I don't think we need to mention it. What do you think?

[mfw78]

Given the feedback on the above, are we able to close this issue?