chore: Enable settlment merging in driver via flag

[MartinquaXD]

Background

Currently the driver tries to merge solutions when the connected solver returns multiple solutions. This can make sense under some circumstances (a simple naive solver trying to solve orders individually) but only adds overhead, latency and complexity when the solver already solves for multiple settlements.

Details

To address this we should add a flag to the solver section of the driver config file that enables or disables settlement merging.

Acceptance criteria

Settlement merging can be controlled via a flag.

[harisang]

I would argue that with solvers moving to the new api and potentially sending multiple solutions, this should be prioritized, as the default behavior should NOT be to merge solutions whenever possible. Is there any timeline for this btw?

[fleupold]

Do you have any indication that this is an issue in practice? Merging doesn't remove any solution candidates, and I'd expect solvers that send us multiple solution to not allow for them to be trivially merged anyways (e.g. by offering two different ways to solve an order, which will make merging using our logic impossible).

[harisang]

Do you have any indication that this is an issue in practice? It's definitely not an issue yet as i think very few solvers are actually submitting multiple solutions, but my reaction is based on the fact that creating a batch is fundamentally a solver's task, and so merging on the driver side is meddling with what solvers decided to propose as solutions. This can have a negative effect if the merged solution (computed by the driver) reverts.

E.g., if i see two meme token trades and gas prices are 200 Gwei, as a solver i might on purpose propose two separate solutions, each doing a single-order trade, in order to increase a bit the chance that i am getting ranked, and potentially able to settle onchain.

Disclaimer: what follows has not been thoroughly checked.

One more formal way to see that merging and adding up the surpluses of the different solutions might lead to a "wrong" bidding is the following. Let's assume for simplicity that there was explicit score reporting in CIP-38 (similar to CIP-20). In that case, for a solution that can generate some surplus X, the "correct" score is p * X where p is the probability of success. Now if you have two completely independent solutions with relevant values (p, X) and (p', X'), merging them would give a solution (p p', X + Y), where the corresponding score would then be `p p' * (X + Y). Instead, what we are doing now leads to a score reporting ofpX + p'X'.` Putting some numbers there, if p=p' = 0.8 and X = Y = 1, the correct score would be 1.28 while we would report 1.6.