MEVconomics.wtf Part 3

MEVconomics for Modular Blockchain Stacks

The "Leader selection algorithm" is basically an algorithm that tells you who is permitted to actually produce new blocks. Blackchains that can't add new blocks aren't useful.
The "Sybil resistance mechanism" is the consensus mechanism (PoW, PoS...) to prevent spamming
The "Block validity function" which defines the execution rules of a block
The "Fork choice rule" to distinguish between two otherwise valid chains

Leader selection and the fork choice rule are linked to the MEV (maximum extractable value), as the leader can capture the MEV via arbitration, front running, etc...And the bifurcation rule can enable temporal attacks linked to MEV.

The Leader Selection Algorithm (3:00)

In a decentralized blockchain, no single leader can halt the chain on their own. This prevents any one party from destroying or controlling the chain

Leaders are generally tied to a consensus mechanism like Proof-of-Work or Proof-of-Stake. This makes it hard to manipulate who becomes the leader :

In PoW, you have to do a bunch of work
In PoS, various protocols have preassigned leaders

Fork Choice Rule (5:00)

It may be easier to manipulate the fork choice rule than the leader selection algorithm. Manipulating the fork choice rule could enable attacks like time-bandit attacks (miners rewrite blockchain history to steal funds allocated by smart contracts in the past)

Once an attacker has reordered the chain, they can also engage in front running, arbitrage, etc. within the blocks they now control.

The Modular World (5:30)

Overall, the leader controls the chain and can capture MEV, so preventing manipulation of leader selection and fork choice rules is critical. These may not be that much of an issue in a Layer 1 context, but they're much more flexible in a modular context, and this a concern.

The blockchain ecosystem is shifting to a model with multiple specialized chains and layers that interoperate. This includes shared data availability layers that provide data bandwidth (Celestia), and execution layers like rollups (Abritrum, Optimism, zkSync, Starknet) that run transactions.

The difference between MEVs (6:15)

Cross-domain aka "Horizontal" MEV refers to extractable value from arbitrage and sequencing opportunities between separate execution environments like multiple rollups.

Modular blockchain Stacks aka "Vertical" MEV refers to the extractable value between an execution layer like a rollup and the underlying data availability layer it relies on (this is what this talk is about)

Unlike with horizontal MEV, there are no direct arbitrage opportunities between a data layer and execution layer. This raises the question of why vertical MEV exists as an issue.

First Law of Cryptodynamics : MEV cannot be added or removed, it can only be moved from one layer to another John Adler

This "law" suggests that even if MEV is addressed on one layer, it may reappear on another layer in the modular blockchain stack.

Considerations for Leader Selection Algorithms (8:30)

MEV in the rollup should stay isolated there, and not bleed down to the data layer, because data validators will be incentivized to extract any MEV that ends up on the data layer => centalization pressure

For decentralization and modularity, it's better if MEV incentives are compartmentalized in the rollup layers above rather than aggregating on the base data layer

That said, aligning rollup and data layer incentives is an open challenge today. Rollups have their own economic incentives that may not align with the long-term interests of the data layer.

Some examples of Leader Selection Algorithms (12:15)

First Come Fisrt Serve : Participants bid to be the first to post a block blob to become leader. This turns leader selection into an on-chain auction, but brings several problems like plutocratic governance, MEV bleeding down to the data layer, and waste of block space since only one blob matters.

Tendermint-Style : Tendermint's leader rotation uses rollup state, avoiding dependence on the data layer. In addition, Tendermint is fork-free. However, since you may wait for data layer blocks, achieving good liveness and responsiveness is hard

Highest-Priority First : This idea requires the data layer to support priority fields that participants can manipulate. But it essentially becomes first come first serve with the auction happening off-chain, which lacks transparency.

Based Rollups : they use their consensus and MEV boost to improve efficiency. However, MEV boost introduces trust assumptions and Layer 1 still acts as an auction, leading MEV to bleed down.

MEVconomics of bridging

The goal of this talk is to discuss a specific technique to mitigate MEV when transferring assets cross-chain via a bridge

How it works

Cross-chain message flow (0:15)

When a user wants to transfer assets via the bridge, Chain A creates a message representing the transfer
Off-chain actors monitor Chain A and pick up this transfer message
The off-chain actors deliver the message to Chain B
Chain B validates the message came from Chain A and credits the receiving account

Creating the message on Chain A and validating it on Chain B are atomic on-chain operations. However, the off-chain steps of picking up and delivering the message add delays ranging from tens of seconds to minutes. Those delays in the cross-chain bridge process allows significant opportunity for MEV

MEV is early access to information (2:45)

Everyone has 10 minutes of warning on what this message does and what it's going to do when it hits the remote chain and how to front run that message most effectively.

So MEV pushes the ordering of a blockchain towards the maximally extractable ordering. What we want to do is mitigate the impact that Reordering and sandwiching have on crosschain messages because crosschain messages are more vulnerable than the average transaction.

Mitigating Reordering & Sandwiching

Batch messages (4:15)

Instead of immediately dispatching cross-chain messages, accumulate them into batches. Specifically, batch messages that relate to the same smart contract or application.
Instead of making each message a separate commitment, commit to the entire batch
Dispatch the batch and process it as a unit on receiving chain

By keeping messages in a batch, their relative order is fixed. This prevents reordering the messages within the batch to exploit MEV, and we remove ability to sandwich transactions to extract MEV

This usually introduces a small amount of latency, but as a result you can't be extracted from as easily

Reorder batches upon receipt (6:15)

When a batch hits the destination chain, we can reorder that batch on-chain. For example, use a deterministic shuffle based on receiving chain's block hash.

This technique isn't fully unpredictable, but it still raises costs of manipulating batch order. Searchers could try different shuffles until they get an exploitable order, but that takes work. Speaking of which, we already have a word for that : Proof-of-Work

Optimal extraction is now a PoW problem

So the searcher now has to iteratively repeat some shuffle hash function and then try to extract upon that blob and it has to repeat that many times, trying to find the best shuffling.

Manipulating the randomness is equivalent to doing the PoW. It increases the cost of extraction.

Pros and Cons (8:15)

In other words, we're increasing the costs. But this is only a mitigation, not a fix.

This only works if you have several messages, a significant number that touch the same state, so that shuffling changes the outcome of those messages. Furthermore, They want to know that messages are received in the order they're dispatched and this does not preserve that property

Things we couldn't get into (9:30)

Cross-chain MEV is mostly statistical, as it relies on patterns across many txs over time

MEV is the cosmic background radiation in crosschain in that it is going from everywhere to everywhere all at once.

Discussion with Jon Charbonneau (10:30)

There was a debate around whether rollups are defined by their bridge to layer 1 or not. According to James, rollups includes a bridge by definition, because it needs it to be linked with the Layer 1

When we think about it, rollups stand out because of their inherent bridge. This sets them apart from other rollup types, like Sovereign Rollups which don't have a native bridge. Rollups are a subclass of sovereign rollups with added bridge (Terminology evolved backwards, so is a bit confusing)

The question that we fight about is whether the bridge or the nodes determine the correct state of the rollup. James thinks that nodes decides rollup state, not the bridge :

Nodes can force bridge to accept anything, but not vice versa
Nodes decide rollup state, bridge can't force invalid blocks on nodes

Restaking and MEV

What is MEV ? (1:00)

MEV arises from the freedom of block proposers to order transactions in a way that benefits them. This freedom exists despite constraints from the consensus protocol.

This freedom gives rise to markets as well as negative externalities. Markets emerge around providing MEV services and paying for transaction ordering. However, practices like frontrunning are negative externalities - they impose costs on users and degrade the fairness of the system.

Some systems are easier to extract value than others :

In PoW, miners can more freely reorder blocks to maximize profits
In PoS, factors like staked deposits and slashing deter such practices. Stakers risk losing their deposits if they deviate from consensus rules.
Single-slot finality in PoS chains like Ethereum helps mitigate MEV by finalizing blocks quickly

Programmable staking/slashing could allow proposers to commit to more anti-MEV rules. Therefore, new staking and slashing designs enable interesting new mechanisms to manage MEV, and restaking wan be interesting in that way

What is "Restaking" (3:30)

Restaking allows Ethereum stakers to make additional commitments with their stake, and this was introduced by EigenLayer, which is a restaking protocol that enables stakers to set withdrawal credentials and opt into new commitments :

Running middlewares - Stakers can commit to running specific middleware protocols that likely have their own incentives and slashings.
Transaction ordering preferences - Stakers can commit to following certain transaction ordering schemes, for example anti-MEV schemes that limit extracting value.
Securing new services - Beyond just securing the Ethereum base layer, stakers can commit stake to secure other auxiliary services/blockchains

It's called "restaking" because stakers are reusing their Ethereum stake for additional commitments, not just securing the base layer.

Use cases

Event Driven Activation (5:30)

Some events like liquidations in a lending protocol or NFT Mints are based on events that occur on Ethereum blockchain.

These event-driven actions currently happen off-chain by various services like Gelato, Keepers, and Chainlink. They monitor the chain, detect condition changes, and try to broadcast transactions in response. However, there is no direct linkage between these monitoring services and the Ethereum block proposers who could include the desired transactions.

With Eigenlayer, stakers committing to event services can be obligated to include transactions responding to events. If the event happens in the Ethereum state, the staker must include the associated transaction or face slashing

Partial Block Auctions (8:30)

Partial block auctions allow block builders to purchase only a portion of a block from stakers, rather than the entire block like in current MEV Boost.

Currently, the entire block is sold to prevent stakers from modifying or censoring the purchased block contents, which they are cryptoeconomically committed to including.

With Eigenlayer, stakers can commit to including a prefixed "builder portion" of the block : The staker retains freedom to include any transactions in the remainder of the block. This lets stakers sell a chunk of MEV to builders but still include some of their own transactions :

Stakers can express more agency by including chosen transactions.
Retains decentralization of block building across stakers.
Allows stakers to capture some MEV value from the block

This balanced approach aligns incentives between decentralized stakers and professionalized MEV builders.

Threshold Cryptography (11:00)

We can also use threshold encryption with EigenLayer restaking :

Transactions can be encrypted via threshold cryptography and split into shards shared among restaked nodes.
Block proposers commit to only include the decrypted version of the encrypted transactions. If the decryption key is revealed, the proposer must include the decrypted transactions. Else, they can get slashed.
There is an honesty assumption that the threshold keeper group will reveal keys. If keys aren't revealed, proposers can waste block space instead of getting slashed. This disincentivizes the keeper group from withholding keys.

Blockspace Futures (13:15)

Blockspace Futures allow reserving future block space from validators :

Transactions are sent to a fast sidechain for priority inclusion.
If a transaction is included on the sidechain, Eigenlayer validators must include it in a future Ethereum block.
Validators make commitments to honor sidechain-included transactions.

This guarantees Ethereum inclusion for priority transactions.

Risks (14:45)

MEVconomic Security in Liquid and Restaking Protocols

Centralization risks (0:30)

Both restaking and liquid staking protocols currently face centralization risks, as there are a limited number of operators controlling the major protocols :

For liquid staking, most of the market is dominated by a small number of platforms
For restaking, there is also the risk that a few sophisticated actors come to dominate restaking services if it's profitable. Strong incentives could motivate more operators to become "sophisticated restakers", reducing heterogeneity.

Economic VS Decentralized trust (2:00)

Decentralized trust requires both sufficient financial incentives/economics and true decentralization across nodes. Relying on just one is dangerous

Some services like financial underwriting only require the economic incentives of staked assets for security. But others need decentralization for censorship resistance, secret sharing, threshold cryptography etc.

Decentralization of liquid staking providers (4:30)

There are inherent tradeoffs between decentralization of operators and scalability of the protocol. Fully decentralized providers like Rocket Pool sacrifice some scalability while more centralized providers like Lido achieve greater scale

Complete decentralization may not be feasible, but improvements can be made through technical solutions and protocol design :

Reputation systems : Track and quantify operator reputation based on metrics like uptime, performance, stewardship of funds.
Delayed Deposit Threshold (DDT) to limit risks from new/unproven operators
Staking Routers : Funnel staked funds through a decentralized routing protocol to assign operators (Lido)
Distributed Validator technology (DVT) : spread out the validation work across different nodes.

The Lido staking router model may represent the end goal for achieving both sufficient decentralization of operators while retaining scalability of the protocol.

Modular ecosystems don't help (9:00)

We're already moving to this kind of extremely complex ecosystem of chains and we're inevitably going to have to solve these allocation problems no matter what participant we are

And based on that, Tarun thinks figuring out what the collateralization looks like will change over time, especially if a lot of Lido node operators are restaking to also provide sequencing services for particular roll ups

Sequencing transactions (10:45)

Basic sequencing roles like transaction ordering and data availability can be designed to be stateless, simply requiring ordering transactions in blocks. However, the high bandwidth demands seen by early sequencers raises concerns about whether the infrastructure demands differ substantially from a high-throughput chain like Solana.

The lack of MEV auctions on shared sequencers so far exacerbates bandwidth issues by incentivizing dumping of transactions.

Overall, the relationship between staking value flows and participation incentives in different protocol roles deeply affects centralization risks. Misalignments can lead to centralization.

Rewards (15:00)

Centralization of stakes towards restaking protocols can occur even if the restaking rewards are only slightly higher than Ethereum staking rewards, as we've seen with adoption of MEV boost. The yields don't necessarily have to be very high.

Actively incentivizing decentralized nodes and committees with higher rewards is an option to counter centralization pulls, but algorithmically identifying decentralization is challenging :

Decentralization oracles can help steer node participants towards services with specific decentralization needs
Secret leader election protocols can help select decentralized nodes anonymously, but there needs to be a baseline of decentralization first. The state distribution needs to be uniform over unique identities, for the election to be meaningful
Threshold cryptography for decentralized committee election is an unexplored but promising research direction for the future

It's wiser to wait for these nascent technologies to mature before integrating them into critical high-value systems like Ethereum and its staking.

Leverage (27:00)

Overall, leverage is an external factor protocols must design for :

We can view the "leverage" created by restaking as a tranche-style insurance model
Liquid staking tokens already carry implicit leverage since they are used as collateral in DeFi lending markets to borrow other assets.
Even in Proof-of-Work, mining farms were highly leveraged, borrowing against their ASIC machines to finance purchasing more mining hardware

Protocols cannot control the leverage users take externally, so margins of safety are critical in design

Some design space still remains for innovation after initial liquid staking breakthroughs like staking routers and delayed deposit thresholds are established

Shared Sequencers (33:45)

Shared sequencers capture the MEV value that would normally accrue to rollup-specific sequencers, so rollups lose this benefit by adopting shared sequencing. There needs to be realignment of incentives for rollups to use shared sequencing if they lose their native MEV.

Shared sequencing should theoretically create additional interoperability MEV that doesn't exist today. The key is having transparent reporting of each individual rollup's marginal contribution to the total MEV generated by the shared sequencer.

Another option is estimating the counterfactual solo MEV that rollups could generate on their own, and incorporating that into fees. Randomly dropping rollups to measure impact on MEV can help estimate marginal MEV

Cognatorial auctions are possible but likely too expensive in practice for widespread adoption.

Rollups x Eigenlayer (39:45)

Allowing rollups to switch sequencers on a per-block basis introduces competition between sequencers to bid up MEV revenue paid to rollups. This constant competition could help align incentives, though viability needs assessment.

Making protocols aware of external slashing events, like Ethereum being aware of Eigenlayer slashing, will be possible soon through upgrades like smart contract triggered withdrawals. This awareness improves security.

However, bugs in hastily-added native commitment schemes could result in mass slashing. Ethereum may not want reliance on subjective slashing veto committees that exist today.

A prudent path seems to be allowing experimentation on opt-in overlay protocols first (Layer 2s ?), before formal adoption into Ethereum. This allows time to develop and vet any new staking logics first.