Targeting Zero MEV - A Content Layer Solution

Security
42

This is a serious attempt to solve a real problem.

My feedback

  • We need to explicitly account for possible collusion among parties in the shuffling protocol, if they are staked the situation improves, but the problem remains.
  • Plain Alex (afaict) has two layers of MEV, which chunk do you get into and where are you in that chunk. If you can fairly order chunks you should be able to fairly order txs, no?
  • It would be highly desirable to make this non-interactive (the N in SNARKs), less moving parts, and it bypasses collusion issues.
  • The naive use of tx hashes to order doesn’t work but there might be a better use of hash functions, perhaps multiple rounds (like a kdf) of hashing the entire block to make it time-expensive for miner to iterate thru many block versions.

You are clearly passionate about this, OP. I hope the community will converge on a solid solution.

1 Like
43

Hello,
I think the Idea is great but not sure if not a much simpler solution could work. Already started a topic
MEV a simple Solution but basically my intuition is that it is a pricing problem:

  1. Something intersting happend outside of Ethereum. People react. What is the fair price? Right now you can just outbid each other through gasPrice
  2. Someone posted a “bad” transaction. People react. What is the fair price? Should be the same mechanism as 1. Right now we have a messy solution flashbots and co.

In my opinion, there do not exist more cases. MEV isn’t that bad per se. It often just correct’s the market. I think we need to find a solution that works somehow transparently.
In the end, DEX exchanges should just automatically protect from MEV or bad transactions. For example, warn a user that his transaction might be sandwiched.

44

I also came up with my proposed solution about more regulated, usable and transparent onchain service for users and applications while solving MEV and maintaining privacy as my industry research outcome.

Problems that my research proposal wants to solve:

  1. Onchain service providers are so powerful that they have unrestricted privileges to view, order, and censor transactions arbitrarily for MEV. Users and applications couldn’t regulate them to have reliable, stable, and protected onchain service.
  2. PBS regulated MEV for mitigating consensus centralization and transaction censorship, but didn’t solve them and prevent MEV from the root.
  3. Privacy preserving techniques could fully protect transaction privacy and prevent MEV for users without revealing any specific content in public. But some users and applications like AMM need to reveal some information in public like latest public states of the liquidity pool for usability and transparency, or have other special requirements for onchain service particularly.

In order to solve the problems above, the goals of my research proposal are:

  1. Users can get better onchain service including:
    1. privacy preserving for MEV prevention and censorship resistance
    2. different privacy protection level options and lower privacy protection costs
    3. faster transaction acceptance and onchain guarantee
  2. Applications can set more customized onchain requirements to fit their needs including:
    1. maintaining public usability and transparency while protecting personal privacy
    2. determining the processing order of transactions sent to them
    3. other special and personalized onchain requirements

In order to achieve these goals, the main contributions of my proposals are:

  1. Applying privacy-preserving technique to fully prevent MEV and resist censorship, and combining it with PBS to allow more privacy level options, and maintain usability and transparency
  2. improving PBS by assigning consensus work to proposers to reach consensus first before block construction to allow more privacy level options, and faster transaction acceptance and onchain guarantee
  3. designing customizable transaction and smart contract that allows users and applications set additional requirements for onchain service providers to meet their personalized onchain needs like self-determining the processing order of transactions sent to them

The process of my proposed solution is as follows:

  1. Users choose privacy level for their transactions. They can choose to encrypt transactions before being accepted by proposers for censorship and MEV resistance, and decrypt after being confirmed for lower gas fee when being processed by builder. They can also choose fully private or fully open. Then they send their transactions to proposers.
  2. Transactions will be broadcasted among proposers, who validate and accept transactions that they think should be appended in the new block. The transactions accepted by the majority after reaching consensus will be sent to the builder, and users can be informed that their transactions will be included into the new block or not definitely.
  3. Builder will decrypt some transactions if allowed to reduce the workload during block construction. They can only work on the transactions determined by proposers. Otherwise their constructed block will be rejected and invalid.
  4. Builder will verify and process proposed transactions according to the requirements set by users in their transactions, and applications in their smart contracts. Then the results and transactions will be appended into the new block, and the new block will be sent to storers.
  5. Storers check whether it meets the requirements of users, applications and proposers, and store it in the blockchain to provide data availability. Anyone can request the states of the blockchain from the storers with the validity proof.
1 Like