I would prefer to take it futher and have no auction at all (whether GPA or MEVA). In this situation, you keep the EIP 1559 base fee to reflect overall demand and mitigate DDOS, but eradicate the tip (thanks @barnabe).
It is way better for users because:
no need to set/guess tx fees (which users dislike and which EIP 1559 is trying to address)
visible guarantees of order execution (tx order is quickly visible in the content layer before entering the block)
exploitative MEV is greatly reduced (simplest content layer=limited MEV auctions possible) or eradicated (enc/fair ordered content layer)
low gas costs
The low gas costs observation is potentially huge and is only just occuring to me. I am actively researching it and would love to stimulate a debate around it.
Essentially, any auction (whether GPA or MEVA) creates MEV by allowing users to bid on transaction order. In doing so we are not only auctioning off tx execution, we are also auctioning off tx priority (which is far more valuable as the MEV crisis has shown).
It is this extra value that makes it worth attackers bidding up gas costs to extract MEV. Users that are not trying to extract MEV then have to raise their bids to compete with the very attackers that are exploiting them.
Put simply, not only do auctions corrupt transaction order, they also raise gas costs (I suspect by a lot- I aim to quantify this).
Yeah what I am proposing is a systemic change. High gas prices and MEV are systemic problems.
Seconding this. Very little of traditional HFT revenue is purely extractive in the same way that the front-running sandwich bots on DeFi are. The sizable bulk of HFT activity is market making, cross-venue arbitrage, or statistical arbitrage based on signals in the microstructure. In all those cases, the HFT entity is increasing liquidity and/or improving market efficiency through price discovery.
Sandwich front-runners contribute neither. Thereās no permanent price impact, because the price ends at the same price as it would have without the attack. The closest analog to something traditional HFT actually does is the back runners which arb the price between different liquidity pools. Yes, HFT might contribute element of order flow prediction in the statistical sense. But itās nothing like the way sandwich front-runners directly. In a traditional exchange order visibility and execution are atomic at the exchange gateway level, so thereās no way to know an order will arrive before itās already filled. (The Michael Lewis book covered a very small corner case, where very large traders were sweeping liquidity at multiple venues with multiple orders, which were only predictable in the non-determistic statistical sense.)
Sadly not even that. It isnāt healthy price discovery if you can create or exacerbate a price imbalance by reordering/censoring txs.
Miners and MEVA winners literally create arbitrage and backrunning opportunities that would not otherwise exist and then risklessly exploit them.
And the final insult, average users that just want to get their txs executed have to compete on tx costs with the very people that have pushed the gas price up in order to rip them off (see my post above).
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.
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?
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.
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ā¦
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.
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.
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).
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.
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.