MEV and Programmable Currency

Author: Kiara Bickers

Source: https://blog.blockstream.com/miner-extractable-value-mev-and-programmable-money-the-good-the-bad-and-the-ugly/

The security model of the Bitcoin core relies on this basic game theory - miners will ruthlessly pursue profits with their electronic pickaxes, and it is this pursuit that secures the network. The standard mining operation requires producing blocks to earn block rewards and transaction fees, but have you ever imagined that miners might have other ways to extract value from the blockchain? Are there other profit opportunities on the blockchain that miners can leverage their advantageous position to exploit?

What is "MEV"?

In a Proof-of-Work system, "Miner Extractable Value (MEV)" refers to the profits that miners can obtain by reordering, excluding, rearranging, and replacing transactions in the blocks they mine. However, as Ethereum has upgraded to "Ethereum 2.0", migrating the network to a "Proof-of-Stake" system, the concept of MEV has been given a new name, now referred to as "Maximum Extractable Value" in the Proof-of-Stake context. In this context, the block proposers - the "validators" - have the opportunity to extract this value, replacing the miners.

In these networks, miners (or validators in Ethereum 2.0) play a special role in confirming transactions in the form of blocks. Their position allows them to front-run other users and determine the final ordering of transactions on the blockchain. Within a block, transactions are generally ordered from highest to lowest fees, but there are always times when miners can strategically alter the transaction ordering to obtain additional profits.

You might ask, what's the problem, the miners are just earning a bit of extra profit? The issue arises when only a subset of miners have more advanced analytical capabilities and computational power to more efficiently identify and exploit MEV profit opportunities.

These opportunities will not remain low-hanging fruit forever, but as the potential gains from analyzing the blockchain increase, teams equipped with bots will be incentivized to do such analysis. Over time, the disparity in miner profitability will create a centralizing trend in the network, ultimately eroding the core principle of decentralization.

This is precisely what the Bitcoin developer community hopes to avoid as they consider how to unleash stronger expressiveness on Bitcoin.

Why do we want programmable money?

In the past, Bitcoin has operated with relatively simple smart contracts. But even for handling slightly more complex transactions, this model can be restrictive. Bitcoin Script can only verify identity authentication data and lacks the ability to impose rate limits on transactions or define the final destination of funds, as Bitcoin Script cannot access transaction data.

Another somewhat independent issue is that developing and writing Bitcoin smart contracts is challenging for users who do not fully grasp their security requirements. A proposed feature called "vaults" aims to address this pain point by introducing transactions with time-locked conditions. Essentially, vaults can serve as an emergency "escape hatch" to allow users to recover funds if their private keys are stolen. But such features can only be realized if our programming language has stronger expressiveness.

The Ethereum protocol is known for its highly flexible scripting capabilities, but it is also clearly plagued by MEV. Most users generally assume that Bitcoin is free of MEV, in stark contrast to Ethereum being viewed as the wild frontier. But is this really the case?

Does greater expressiveness in smart contracts necessarily bring more MEV scenarios?

It is known that multiple factors have fueled MEV: (1) transparent transaction pools; (2) transparent smart contracts; (3) the expressiveness of smart contracts. Each factor has opened new windows for MEV; let's examine them one by one.

The Bad: (1) Transparent Transaction Pools

Like the "mempool" of the Bitcoin network, the transaction pools of most blockchains are fully transparent, open, and visible, allowing everyone to see which transactions are waiting for block confirmation. Bitcoin blocks generally take 10 minutes to mine, theoretically giving miners equal time to front-run.

But in reality, the Bitcoin blockchain does not have the sources of MEV because: (1) Bitcoin transactions are simple enough that there is not a huge disparity in analytical capabilities between miners; (2) Bitcoin transactions generally do not involve multi-asset trades, such as asset swaps and open-ended trades that can be front-run.

Ethereum, on the other hand, has public decentralized exchanges (DEXes) on its blockchain that can execute some of the most complex multi-asset trades. Typically, Ethereum block times are 15 seconds, but during high transaction pool traffic, the gas fees required to get a transaction immediately confirmed can easily exceed $100. The result is that low-fee transactions can wait for minutes or even hours. This provides a long window for these malicious front-running activities, and with the huge value contained in Ethereum's various layer-2 tokens, such activities have become quite prevalent.

Translator's note: In this article, the author consistently uses the same expression "layer-2 token" to refer to what we would call "on-chain token protocols", rather than the meaning of "tokens representing the value of layer-2 projects" (on Ethereum and other platforms, there are many such "layer-2 projects").

Translator's note: The author's argument here is not very reasonable. Whether the transaction pool is transparent or not does not determine whether MEV opportunities will arise, it only determines which parties these opportunities are open to. One can imagine a completely opaque transaction pool (e.g., in a sidechain), and it is still entirely possible to imagine the existence of MEV opportunities within it, but only the block builders who can see the transaction pool would be able to see and exploit such opportunities.

The Bad: (2) Transparent Smart Contracts

Bitcoin's "smart contracts" are simple locking and unlocking mechanisms derived from Bitcoin Script. The details of transactions (value, sender, receiver) are publicly visible on the blockchain. While this complete transparency is not ideal from a privacy perspective, it is also one of the reasons why Bitcoin allows all participants in the network to verify the complete state of the blockchain. Any observer can analyze these contract details, potentially allowing certain MEV strategies to thrive.

However, Bitcoin's script programming language is intentionally designed to be very limited, focusing primarily on the basic functionality of sending and receiving funds, as well as using signatures or hash locks to validate transactions. This inherent simplicity naturally limits the scope for MEV, making such opportunities relatively (to other blockchains) rare.

Platforms like Ethereum, Solana, and Cardano have fully transparent smart contracts, but unlike Bitcoin, they have highly expressive script programming languages. Their "Turing-complete" systems can theoretically execute almost any computational task, including: self-executing contracts, integrating real-world information through oracles, decentralized applications (dApps), tokens, asset swaps in DEXes, and automated market makers (AMMs). Together, they provide fertile ground for MEV. Solutions based on zero-knowledge proofs, such as STARKex, can theoretically mitigate some of the issues, but at the cost of additional complexity.

The Ugly (3): Smart Contract Expressiveness

On some blockchains, MEV opportunities are so abundant that some "MEV trading firms" have reported monthly profits in the "six figures". This trend is so pronounced that there are now public data websites dedicated to scanning the Ethereum and Solana blockchains for profit opportunities. Their profitability comes from executing a full suite of MEV strategies: front-running, back-running, sandwich attacks (combining front-running and back-running trades to sandwich the victim's trade), token arbitrage, and liquidations, among others. Each strategy leverages different principles.

Some MEV strategies that can be used on both layer-1 and layer-2:

1. Generalized front-running: Bots scan the mempool for profitable trades and execute a transaction ahead of the original one to capture the profit.
2. Sandwich attacks: The attacker places a trade before and after a large transaction, exploiting the predictable price movements caused by the large trade to profit.

Specific strategies that only work for layer-2 tokens and smart contracts:

1. Arbitrage across different DEXes: Bots leverage price differences for the same asset across different DEXes to profit by buying low and selling high.
2. Back-running DeFi adaptive price curves (Bonding Curves): MEV bots profit by back-running large trades on adaptive price curves, where large trades have predictable price impacts; the bots can buy in an uptrend and sell at a profit.
3. DeFi liquidations: MEV bots target opportunities in DeFi lending protocols, where if collateral value falls below a threshold, others can claim the collateral at a discount.

The complexity of contracts has also significantly given rise to MEV-related issues.

1. Reentrancy attacks: These attacks exploit logical vulnerabilities in smart contract accounts, allowing the attacker to repeatedly call a function before it completes, draining funds multiple times. In the MEV context, experienced attackers can reap massive profits, especially in contracts holding large amounts of funds.
2. Composable contracts and global state: On platforms like Ethereum, smart contract accounts can interact, so a single transaction can trigger a chain reaction across multiple contract accounts. This composability enables complex MEV strategies: a transaction sent to one contract account may impact another, leading to cascading profit opportunities.

Here, part of the problem is that the total value of tokens and the dApps built on top of them may exceed the value of the native asset on the layer-1 blockchain, reducing the block producer's incentive to simply select and confirm transactions based on fees.

To make matters worse, many of these opportunities are not strictly the block producer's. Other participants with MEV scanning bots can also compete for the same opportunities, leading to network congestion and skyrocketing gas fees. This imposes negative externalities on the network and users - everyone is affected by higher transaction fees as the blockchain becomes less efficient and more expensive to use. MEV opportunities in DeFi are so pervasive that users have almost come to accept them as a kind of invisible tax on everyone.

So, are these MEV opportunities a natural byproduct of the high expressiveness of smart contracts, or are there other paths to the dream of fully programmable money?

In addition to moving away from highly expressive smart contracts and layer-2 token protocols, users can mitigate some risks by using protocols that support "confidential transactions" like Liquid, which hide transaction details. But unlike these platforms with more powerful programming languages, Bitcoin still lacks the capabilities to realize the vision of programmable money that we aspire to.

The Good: The Tradeoffs of Programmable Money

When considering the evolution of smart contracts on Bitcoin, we have the choices of: (1) pushing complexity off-chain; (2) carefully integrating narrow or "restricted" covenant functionality; or (3) embracing the path of maximum expressiveness. Let's examine each in turn.

(1) A new off-chain contract structure: ANYPREVOUT

Off-chain solutions, such as the Lightning Network, aim to strengthen the scalability and functionality of Bit, while avoiding adding burden to the main chain, keeping on-chain transactions fast and cheap. These goals all sound good.

SIGHASH_ANYPREVOUT (APO) is a proposal for a new type of public key that allows certain adjustments to a transaction to happen after signing (without invalidating the signature). This proposal simplifies the way of updating transactions, allowing transactions to more easily index previous UTXOs, making Lightning Network channels faster, cheaper, safer, and more direct (especially when resolving disputes between channel participants).

At the end of the day, APO is a new sighash tag. Every Bit transaction must have a digital signature to prove its legitimacy. When creating the signature, you will use a "sighash tag" to specify which parts of the transaction you are signing. With APO, the sender can only sign the outputs of the transaction, and not the inputs, thereby only fixing the outputs of the transaction, but not fixing the source of the funds.

APO brings Eltoo, which allows users to exchange pre-signed transactions off-chain (specifically, it actually allows users to only keep the latest transaction signed by the counterparty, rather than keeping all past signed transactions). However, because APO allows transactions to be reordered, it may accidentally introduce MEV. As long as you allow a signature to be bound to a transaction graph, you have the ability to switch transactions. The inputs can be switched, as long as the new inputs are still compatible with the signature.

(2) Restrictive clauses: CAT + CSFS and CTV

Restrictive clauses allow users to control where funds are transferred to, can impose withdrawal rate constraints on funds in a transaction, or set specific destinations. There are two types of restrictive clauses: recursive and non-recursive.

1. Recursive restrictive clauses allow funds to return to the constraints of the same type of restrictive clause.
2. Non-recursive restrictive clauses limit this control capability, requiring the future transfer path of the funds to be fully defined upfront.

CAT + CSFS is a proposed restrictive clause that allows scripts to construct (or define) specific parts of a future transaction. CHECKSIGFROMSTACK (CSFS) will verify a signature against some data, and OP_CAT can construct that data. By using CSFS to require the signature to match the data dynamically constructed by OP_CAT, we can define how these UTXOs can be spent in the future, and create a (somewhat clumsy) recursive restrictive clause.

OP_CHECKTEMPLATEVERIFY (CTV) is a way to create non-recursive restrictive clauses. It does not define and verify specific parts of a transaction, but only constrains how funds can be spent. It defines the "template" that the next transaction must conform to.

One risk of recursive restrictive clauses is that it may create a situation where funds must obey a set of rules and be trapped in a repeating cycle that cannot escape. Another risk is that since the restrictive clauses are transparent and self-executing, they may open up some MEV opportunities on Bit that have already been seen on other chains.

So what's the good news?

The good news is that these proposals will bring new expressive capabilities!

So where is the limit of the expressive capabilities we can get?

(3) Full Expressive Power: Simplicity

Simplicity is a blockchain-based programming language that is very low-level, unlike other script programming languages. It is not a language built on top of Bit Script, nor a new opcode in Bit Script, but a replacement for Bit Script. In theory, Simplicity can internally implement all the restrictive clause proposals and many other contracts that crypto-enthusiasts want a programmable currency to have, but with fewer negative externalities than Ethereum.

Video: https://youtu.be/n4iLNNF3sU0

Simplicity maintains the design philosophy of self-contained transactions in Bit, meaning the program cannot access any information outside the transaction. Driven by the design goals of maximum expressiveness and security, Simplicity supports formal verification and static analysis, giving users more reliable smart contracts.

The Bit Script restrictive clause proposals, although simpler than Simplicity, also lack the expressive power to handle fee estimation within Script, because Bit lacks arithmetic functions. Bit Script has no multiplication and division, nor conditional or stack manipulation opcodes; it is very difficult to estimate a reasonable fee for a given contract (or restrictive clause). Users will end up with spaghetti code where 80% of the logic is used to guess what a reasonable fee might be. This will make these restrictive clause contracts very complex and difficult to analyze.

The Ethereum Virtual Machine has loop constructs, making static analysis of gas usage very difficult. But in Script and Simplicity, you can just count the number of opcodes, or recursively add up the cost of each function, to estimate the cost. Since Simplicity has a formal model, you can formally analyze the behavior of the program. But in Script, this is not possible, although you can statically analyze resource usage.

Simplicity will give users the maximum expressive power, as well as other valuable features like static analysis and formal verification. Users will be encouraged (rather than restricted) to develop MEV-resistant smart contracts. Additionally, the combination of different contracts may introduce MEV, even if each one individually does not. This represents a fundamental tradeoff.

Video: https://youtu.be/rv1YNI-0BXk

The idea of enhancing Bit's smart contract capabilities is undoubtedly promising and exciting. But it is important to know that all these proposals will bring a certain degree of MEV risk - although not to the extent of other blockchains. As we think about adding more programmability to Bit, we need to answer these questions:

• Can we develop protocols without MEV risk, or is this an unattainable ideal?
• Given the inherent MEV risks in many proposals, what level is acceptable?
• Finally, which proposal is the simplest, yet offers the greatest expressive capability?

Each proposal will have its own pros and cons. However, whichever direction we take, our analysis should prioritize security and support for decentralization principles.

Note: This article was originally published on Bitcoin Magazine.

(End)