1. Introduction: MEV and Its Evolution
Traditionally, MEV has been thought of as a problem dealing with miners/validators exploiting arbitrage opportunities by being creative in their block production mechanisms and techniques. Currently, there exists only two options broadly construed, either fight the MEV by creating ways to limit MEV opportunities or to embrace it and create new ways of bringing back fairness in the block production politics for it is but inevitable, the MEVolution is here. What is underlying these options is the framing of greed once available becomes irresistible. This makes it a design choice between greed versus fairness, how best to strike the delicate balance, and how to introduce other forces in this picture so as to enlighten the dark forest. These new forces come in the forms of cryptoeconomic mechanisms that have been proposed, most of which, leveraging the PBS and Flashbots research.
There is another way of looking at it. This is the Question and the Concept of Time. Specifically, how it plays out in models of consensus, as is evident in the original name given by Nakamoto for blockchain: timechain. MEV has opened up the plasticity of time in Ethereum.
In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions.
— Nakamoto S., Bitcoin: A Peer-to-Peer Electronic Cash System, 2008 [Highlight by the authors]
The change in blockchain transactions' ordering and execution model from a sequential one to one that reflects a flexible time, as exhibited and exposed by MEV searchers, lets us imagine and engineer radical new transaction semantics. Specifically, transactions can now validate values provided to them by searchers (via transactions infrastructure), reverting when validation fails. Such programmable atomicity (or semi-atomicity and its many variants) exemplify the fact that blockchains are technologies of time.
For example, consider a "smart" transaction pattern where searchers provide valid oracle values to a transaction or else the transaction reverts. This can be used to implement parameterized function calls, allowing searchers to more directly solve and search/optimize transactions. It can also be used to provide signed data to transactions, including off-chain price information or additional third-party transaction validation.
For another example, consider a pattern where searchers must provide values from the future, under the logic that the transaction reverts if it finds a different value when it finally arrives at this future point of its execution. This pattern is leveraged by our transactions infrastructure (See §7) called the callbreaker, which has searchers front the return values of the callobjects (aka internal transactions) that are executed by the breaker as a bundle. It can also be leveraged in the time turner, through which searchers front entire callobjects from the future.