Targeting Zero MEV - A Content Layer Solution

This is really, really interesting. If we consider transaction ordering to be a separate layer of consensus, the answer to “can we eliminate MEV” seems to be yes. As a trivial example, if we used a light-weight PoW sidechain that restricts each block to only contain 1 transaction as the content consensus layer for our main chain, the transaction ordering would be decentralized. I feel this framework opens up some new and interesting design space for developing a practical MEV-free blockchain.

1 Like

Hi @zefram_l. Yes it seems that way to me. I wanted to distinguish between the general concept of a distributed content layer and the Alex protocol as my first attempt at designing one.

Thank you for contributing ideas for another possible implementation. Re: a full secondary blockchain, you’ll have to be sure to keep network usage to acceptable levels and not to introduce another layer of MEV. I’d like to hear your ideas as you progress them.

I’m currently looking at a very stripped down version of Alex that mitigates some MEV (I need to work out how much) and is much simpler to implement as a first version. I’ll then look at how it can be built on to provide encryption and fair ordering.

Great post! I like the distinction b/w content and structure.

Do you think that we could use the randomness in the beacon chain (RANDAO today, VDFs tomorrow) to create shuffle seeds in a way that gives us something like the shuffler approach?

1 Like

Hi @Isankar4033. Thank you for your input.

I’m not an expert on Rando but I imagine you may have synchronization/visibility issues. If the content layer is chunking the mempool every 1 to 3 secs, any external rng process must be timed to reveal a new seed just after the pickers have committed. If the seed is known before, the pickers can game the order.

I will be considering VDFs not for rng so much as for tx encryption. I think we can incentivize the content layer participants to print chunks quickly and regularly (under threat of being skipped) at which point you may be able to use quite short term VDFs to reveal enc txs once the order has been committed to, possibly several times within a block (so no UX delays). TE is also an option.

The problem with random ordering is tx bloat due to stat arb battles. Once you are sorting enc txs, even bad actors are minimally incentivized to order fairly.

On a general note: I’m on the ChainLinkGod podcast next week discussing MEV and with any luck will be speaking at EthGlobal next Friday about these issues/solutions.

randao is a temporary measure for randomness in the beacon chain until things like VDFs are ready, but yes, it’s slightly biasable by the last participant in the randao. Ultimately, I think we can assume that we’ll have good, unbiasable randomness eventually b/c this is the thing used for committee assignments and if biasable, would completely screw up security assumptions around sharding.

It feels like this could be a drop-in replacement for the shuffler layer in your proposal and potentially something with a faster route to production on mainnet eth.

1 Like

I certainly don’t want to throw hurdles up against it being adopted on mainnet. Things to consider though…

Doesn’t rando produce a new seed every block rather than intra block, or is that not the case? If every block it would mean block length content chunks and an n+1 block delay I think (although it takes most txs far longer than this to go through).

When random ordering we would need to carefully assess potential tx bloat issues…

ah yes, it’s every block, so that source randomness could only allow block-length content chunks i think. this is undesirable?

1 Like

Not necessarily, but the faster you chunk the mempool, the better you preserve time order. Then there is the impact on UX of spanning multiple blocks…

…but actually I have new data on this. Once you have discounted miner inserted txs, the average time taken for a tx from arrival at the mempool to inclusion in a block is approx 2:30 mins.

Pretty high right? About 12 blocks. So a 1 block delay (supposedly too great for Dapp devs to use submarine sends) doesn’t look so bad.

And the stdev of inclusion time… 20 minutes!

This is the cause of MEV. Extreme tx order corruption.

In this talk for EthGlobal I discuss more recent ideas for Plain, Dark and Fair variants of the Alex Content Layer protocols as well as the root causes of MEV with some real world examples given here.

2 Likes

I’ve open sourced the code and data I used in this talk for analysis of tx arrival and inclusion times and to classify Flashbots bundles as sandwiches, frontruns and backruns.

See ReadMe for methodology and limitations.

Code & Methodology

Sample Data
https://drive.google.com/file/d/1WPknOb-Y3jIGaNc-2wA3VuWkUjXxuS8O

Thanks for all the updates you’ve kept adding here! Your recent jpg transposing pixels is a very nice visualization of corrupted ordering’s effect on a data source!

After reading through some more of your material via your links, I was wondering if you’ve also described your Alex Content Layer protocols from the view of walkthrough or lifecycle of a given transaction that would be submitted, processed and finalized using Alex as the Content layer protocol? There have been some helpful versions of this type of description for a transaction walking through the current GPA mempool mechanism. For example:

and

Though not 100% sure, I think such a walkthrough/lifecycle description would help others, like me, who have a reasonably competent mental model of the current transaction mempool protocol behavior among full nodes (mining+non-mining) on mainnet. With that description, we could probably better map that mental model to the changes with Alex in how each transaction enters into the Alex protocol and then progress through the various steps until eventual inclusion (or rejection).

1 Like

Thank you for the kind words @rjdrost. This is a great idea. It would help me work through the logic of it and find any issues as well.

The walk-throughs you have linked to are eth1 right?

Has someone done a similar tx walk-through for eth2 which I’m targeting with Alex?

Yes, the walkthroughs I linked to are for eth1. Happily, they will still be largely applicable for eth2: While the beacon chain’s validator deposits and withdraws have differences, for existing smart contracts and their transactions, “eth1’s” mainnet will merge onto eth2 to become its execution framework, just switching from PoW to PoS. As such, the transaction pool network and its operation stay largely the same, I believe. Note that I put “eth1’s” in quotes as a goal I’ve heard people mention going forward past the merge will be dropping the distinction between eth1 and eth2 at that point, as it will be simpler to just talk about the merged Eth chain then.

1 Like

I saw someone asking for slides of my presentation.

1 Like

Yes that makes sense to me. I’m working in earnest now on documenting Plain Alex. I will include a transaction walkthrough as you suggest.

@pmcgoohan wonderful post.

What do you think of the following below in terms of design considerations?

Key Design Considerations:

  • Slower is better and safer!
  • No Priority Gas Auctions or MEV auctions to avoid complex game-theoretic security analysis and keep the attack surface smaller
  • Small(ish) attack surface
  • Attack surface should not grow over time
  • Gas prices should always revert quickly to a defined/programmatic mean
  • Gas price volatility should be short-lived
  • Desirable characteristics that an Ethereum Block should/must have e.g. Zero MEV, low gas price, a large number of transactions, a large number of different individual or smart contract systems in the TO addresses.

I also think there is a way how to avoid transaction spamming and reducing volatility. What do you think of the below?

  • An AMM (bonding curve e.g. a constant less than 1 = number of transactions in an epoch of blocks * gas_price / 1.2M-block moving average of transactions in an epoch of blocks) for the gas price that is based on the long-term historical average of the number of transactions per block e.g. 1.2M-block-moving-average, the number of transactions included in a block and an initial gas price derived from e.g. the 1.2M-block gas price average.
  • Gas price is fixed for an epoch of duration of X blocks (X ~ e.g. 6 or 10 or 50, to be discussed)
  • Gas prices for the next epoch are published with the last block of an epoch.
  • Transactions in the mempool are picked based on received-timestamp (oldest first) and if they have a sufficient fee of at least the published gas price for the current epoch. This continues until the anticipated number of transactions for the blocks in an epoch is picked, and chunked following your content layer consensus proposal with the goal of always maximizing the number of transactions in a block.
  • Transactions are ordered using a consensus algorithm that randomly orders transactions for the blocks in an epoch as you suggested. That means that a transaction might be included in the 1st block of an epoch or the last block. If the epoch is long enough, then short-timed arbitrage plays become hard to realize unless an attacker sends a lot of transactions into the queue.
  • Gas price is fixed for an epoch of duration of X blocks (X ~ e.g. 6 or 10 or 50, to be discussed)
  • Gas prices for the next epoch are published with the last block of an epoch.

Thank you for your input @Therecanbeonlyone! My apologies for the delay in responding…

I think you may be referring to the original Alex (random ordering) which I have shelved for now due to possible transaction bloat from stat arbs. I am currently focued on a the simplest possible content layer implementation I could concieve- Plain Alex.

On your key design considerations:

Slower is not really better for the content layer. When it runs quickly it (a) reduces the number of txs available to exploit and (b) brings a more granular time order. Both are benefitical as they reduce MEV attacks and divergence from fair order (defined objectively as send time order).

I agree that there should be no PGAs, and we should definitely never build MEVA into the base layer- that would be a disaster. However, you can only stop MEVA (and any other tx reordering markets eg: Eden) from happening once you remove the right of miners to order txs. This is the case with Random Alex, but not Plain Alex where MEVA would still be expected- just not as much because the total MEV possible will have been reduced.

I am still considering the tx fee structure. Now EIP 1559 is in place, I am happy to use the base fee for the gas price. However, you still need to pay miners or they’ll produce empty blocks.

The problem with paying them a proportion of the base fee is they might manipulate it upwards by filling blocks with txs in order to pay themselves more. One decent solution is to pay them a fixed fee, and this was considered in the original EIP 1559 paper.

Another that I am considering is to have two averages, the base fee (which ramps up exponentially as it does now and is burnt), and the miner fee which increases linearly. This would mean that the tx cost will still reflect supply and demand, but any miner trying to manipulate the price upwards will find they are paying exponentially more for relatively far less in return. It’s early days for this idea, so I’d welcome input.

Well Zero MEV would be nice- it’s certainly what we’re aiming for eventually!

It’s not really the content layer’s business to be trying to reduce the tx costs per se. This will and should always reflect the supply of and demand for blockspace.

That said, once MEV is truly mitigated it will certainly reduce tx costs considerably. As an example of why, consider the extra demand a sandwich attack requires: for every 1 victim tx, 2 attacker txs are needed. This additional demand for blockspace from MEV extraction translates directly into higher tx fees.

I don’t think you can reorder transactions in a block at the end of an epoch if that is what you are suggesting. That will slow the confirmation times for all transactions to epoch intervals at a minimum. Also, as I say, I’ve gone off random ordering as a solution. Check a few posts above for a fuller explanation of this.

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

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.

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