Remove score field from /solve response.

[sunce86]

Once the autopilot is switched to use score from it's domain::Settlement object, there is no need to use driver provided score so this field should be cleaned up.

[MartinquaXD]

Isn't one important aspect of letting the driver provide the score the ability of solvers reporting a lower score than what the calldata would suggest to account for execution risk? Let's say there are 2 solutions that provide the same amount of surplus but one is much more complex. Then on average the more complex solution would revert more often resulting in lower rewards on average. A sophisticated solver should therefor bid a lower score for the complex route than for the simple route, no?
Maybe instead we should still allow solvers to lower their score and the autopilot could verify that the solver provided score does in fact not exceed what is reasonable given the calldata?

IMO it would be fine if the reference driver were to compute the score as is without offering any way to adjust the reported score based on revert risk but the /solve response format should still have the field to enable people to implement smarter drivers that can take advantage of it.

[sunce86]

Not saying we shouldn't do that (that's more a question to solver team whether we should or not), but per CIP38, ranking is done by surplus (without any mentioning of revert risk):

The quality of a solution is now defined as the sum of surplus of the different orders, measured in ETH; the conversion to ETH will be done the same way it is done now, i.e., via the native prices vector provided in the auction instance sent to solvers. The solver whose solution has the largest quality wins the solver competition and executes their solution.

I wonder would allowing this beat the purpose of introducing the rank by surplus. We would again allow solvers to bid how they want (it would just be capped from the top).

[MartinquaXD]

We would again allow solvers to bid how they want (it would just be capped from the top).

From my understanding only overbidding is an issue but not underbidding. So the capped at the top part is IMO exactly the thing that would make it so the competition works as intended. Although I agree that the CIP does not mention adjusting the proposed score based on revert risk so this indeed needs to be double checked.

[fleupold]

If you as a solver want to incorporate reversion risk into your solution you now have to do so by adjusting the prices you report (ie increasing the fees of each order) and not reporting a score that is lower than what you would be able to get if there is no revert risk. This was one of the main value propositions of CiP-38 and simplifies the mechanism drastically. Once the autopilot can compute the score, we should indeed drop it from the driver<>autopilot communication.

[github-actions]

This issue has been marked as stale because it has been inactive a while. Please update this issue or it will be automatically closed.

[github-actions]

This issue has been marked as stale because it has been inactive a while. Please update this issue or it will be automatically closed.

[github-actions]

This issue has been marked as stale because it has been inactive a while. Please update this issue or it will be automatically closed.