Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

research: Use MEV Blocker to decentralize solver bidding #21

Open
fleupold opened this issue Oct 30, 2024 · 1 comment
Open

research: Use MEV Blocker to decentralize solver bidding #21

fleupold opened this issue Oct 30, 2024 · 1 comment

Comments

@fleupold
Copy link

Problem

For every auction, solvers and protocol verifiers need to agree which solver submitted the or a winning solution that is supposed to be landed on-chain.

At the moment this is done by a central auctioneer that signals to winning solvers which of their solution(s) should be submitted. The auctioneers log together with the on chain observations can later be used to compute rewards and penalties and block solvers that violated the rules of the competition.

A tangential problem of the current system is that there is no way for the auctioneer to know if a winning solution will actually make it into the next block. Therefore it cannot signal to a runner up to submit their solution (the auction needs to restart from scratch in the next block). This leads to the requirement of negative solver rewards (aka penalties) for unsettled solutions and can cause bad user experience.

Possible Solution

Use priority fee in combination with MEV Blocker auction (or other builder commitments, or even base layer consensus rules) to evaluate and include the best non reverting solutions just in time.

Details

MEV Blocker is the leading private orderflow RPC, connected to all relevant builders and is already imposing a bunch of ordering rules on connected builders (e.g. maximize refund across all backruns).

While these rules suffer some theoretical drawbacks (ie. a builder could claim not having seen a refund maximizing bundle that was received late into the block), they have proven robust and useful in practice.

It seems therefore doable to add another rule saying that for a certain target contract (ie the settlement contract) or a specific meta-transaction type, all transactions that are submitted of this type, have to be included (unless they revert) sorted by priority fee.

Solvers could then be required to set a priority fee which is a function of the surplus they generate (ie. more surplus => more priority fee). This should lead to the best, non reverting solution getting included while allowing for dynamically picking the runner up in case the winning solutions get broken by top of block arbitrage). Furthermore we assume that the smart contract reverts in case a second solution violates some mechanism rule (e.g. using a different clearing price for a token pair that was already submitted).

This should make the mechanism much faster and robust to reverts and remove the need for negative rewards for failed submissions.

Evaluation

TBD

While this solution would move the centralisation point away from CoW Protocol's auctioneer, centralisation points are moved to the RPC/builder level. However, those are attributable to the nature of PBS and hope remains that there is much more brain power working on decentralising PBS than CoW Protocol alone.

It is for instance reasonable to assume that at some point in the future Ethereum enshrines priority fee ordering into its consensus rules as proposed by BRAID and to be implemented on Unichain.

It could therefore be argued that having a solution which assumes a base layer that provides priority fee ordering and short-term censorship resistance is sufficiently decentralised.

@sambacha
Copy link

A tangential problem of the current system is that there is no way for the auctioneer to know if a winning solution will actually make it into the next block. Therefore it cannot signal to a runner up to submit their solution (the auction needs to restart from scratch in the next block). This leads to the requirement of negative solver rewards (aka penalties) for unsettled solutions and can cause bad user experience.

This can be solved1 using our split auction system, XGA. You would have an inclusion guarantee (re: 'inclusion preconfirmation').

Footnotes

  1. Your mileage may vary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants