Summit Summary pt 2

It’s been too long since part 1. Things have been crazy and this part was more technical and harder to digest/distill. I apologize ahead of time that this one is a bit more dense. I was dragging my feet on it, and then I found out about reorg.wtf! Immediately motivated me to get this done and I’ll be trying to finish the last part before the end of the week so that I can be on top of the reorg conference and get my summary of that out faster than I did this series.

I’m a busy woman with no time to waste so let’s get into it.

Conceptual Summary

Fair ordering and encryption schemes are the main techniques being developed to combat MEV from a general way not specific to application design. It is very important to note that these are complementary approaches that need to both be explored and designed in ways that take the other into mind.

Fair ordering is generally seen as striving for send-order, or ordering transactions based on when they were sent to the network. However this requires trusting the user timestamps so usually this is relaxed to receive-order, or the order the majority of nodes in the network receive transactions in. If more nodes see A before B, A should be before B in a block.

Encryption is broken down into timelock encryption, threshold decryption, trusted hardware enclaves. Each of these have different tradeoffs with regards to block delay and trust assumption, but allow the encryption of transactions in the mempool to avoid their reordering based on content.

A key change to the consensus layer that Vitalik proposed an implementation for is separating the powers of block construction and block proposal. By doing this, much MEV can be disincentivized by including no point in block construction where the ordering can be manipulated for direct benefit by the constructor. This is not going to remove all MEV, but is a very big step towards minimizing it.

Much the same way there are tradeoffs with each of these techniques and their implementations, there are tradeoffs in choosing which layer they are implemented in. Consensus layer changes take longer but are more complete and holistic, whereas application layer changes iterate quickly but interfere with interoperability and are weak to side channel attacks.

Part 3: Protocol-level response to MEV

Fair Ordering

Mahimna Kelkar (Cornell) - The Fair Ordering Design Space

In fair ordering, there is a set of transactions T for which the input order with property X produces an output set with property Y where X and Y are defined by a set of fairness assumptions. The base case is the order in which transactions were sent, but this requires the assumption of trusted user clocks and a synchronous network. Minimum distance from send-order should be seen as the goal.

Fair ordering exists in permissioned and permissionless contexts, where the permissioned context is the situation emerging in rollups. This transfers MEV to the permissioned rollup sequencers. Additionally, fair L2s with an unfair L1 still create issues due to the reliance of L2s on the L1 consensus protocol.

Open research directions for fair ordering include the interoperability of different definitions of fairness and ensuring that the economic structures incentivizing sequencers to order fairly are designed to handle rational actors, especially those that take actions outside the network to modify their economic incentives.

Ari Juels (Chainlink) - Fair Sequencing Services

There are many forms of MEV, some of which are good and some of which are bad. The distinction between the two is still an open research topic. We probably can’t eliminate all bad MEV, but we can build tools to help enact fairer policies for users.

Transaction ordering in Chainlink FSS is determined by a decentralized committee offchain. These committees naturally coincide with node operators in a decentralized oracle network, as this is ultimately a pipeline of taking offchain data (unconfirmed txs) and putting it on chain through submission to block producers.

Phase one will focus on secure causal ordering, which is the idea that no node sees a transaction payload before ordering finality is committed to. It is important to note that this does not specify any particular ordering, simply that ordering follows a commit-reveal scheme. This prevents front-running based on transaction content but not blind front-running from a node operator in situations such as on a new token launch or NFT mint.

Phase two involves the addition of Aequitas ordering protocols (developed by Kelkar et al.), where the ordering is decided by receive-order in the super majority of nodes. This practically works by adding a transaction to the first-in first-out queue that represents transactions included in a block when a supermajority of nodes receive that transaction. Supermajority is a definable parameter by the protocol implementers.

FSS can be used as a preprocessing stage for L1 for specific contracts that implement it, as well as on L2 systems.

Klaus Kursawe (Vega) - Wendy: Adding order policies to the consensus level

The state of the defense against MEV includes distributing influence over validators, democratizing MEV proceeds, commit/reveal schemes, block order fairness, and fairness frameworks with causality (Wendy 2). Fairness definitions revolve around receive order, but it isn’t always decidable if all nodes see one transaction before another. Wendy takes the approach to make a best effort and sort out the rest on actual block production, sometimes weakening receive-order to send-order from trusted clocks when blocksize is too high.

The Wendy setup includes a known set of n validators (validators know and authenticate each other). It is available as an add-on to existing consensus layers, where it assumes that transactions for different uses have labels and only need to be relatively fair to each other.

To be honest, this talk was very technically dense and would be difficult to really get through any more than that here.

Pmcgoohan - Targeting zero MEV at the base layer

The root cause of MEV is the profit to be made by reordering and censoring transactions. Reordering/censoring of transactions is data corruption, and transaction order is as important as content. Send time order is objectively fair and leads to no MEV, and divergence from send time is a fairness metric. Divergence from send time should be symmetric to all participants.

Content layer solutions include decentralizing block production, structuring the mempool, and enforcing this in the attestation process. Structuring the mempool into chunks restricts the ability for miners to select from more transactions which lead to more MEV opportunities. The advantage of using 12 second chunks should reduce backrunning and sandwich attacks by 40% and maybe more with shorter chunks. This would lower user costs and increase data integrity while making the remaining MEV more even to extract due to lower computation constraints.

The Plain Alex implementation shown above would be quick to implement in early eth2 and provide an immediate/significant reduction in MEV. The next phase would be to implement transaction encryption in the mempool through threshold or timelock encryption. In a timelock encryption implementation, the timelock simply needs to be slightly longer than the mempool chunks to introduce no block delays. In the threshold encryption system, a reputation market for split key holders could help to keep them honest. The last phase is Fair Alex which implements an Aequitas-like fair ordering sequencer to prevent collusion between node operators.

Rick Dudley (Vulcanize) - Transaction level hinting considered helpful

Ethereum has an identity problem conflicted between being a casino and being a decentralized computer. If you see Ethereum as the house in a Casino, MEV seems like breaking the rules. If you want it to be safe as a decentralized computer, you need it to be predictable which is what creates MEV. Ethereum has problems in both of these situations and this is what makes MEV uncomfortable.

Ethereum defaults to transaction contention, which creates unpredictability due to the ability for nodes to reject a transaction but also creates a level of verification that allows information to propagate through the state machine only when it satisfies the rules for block production. The merklized data structure that is used to store the state has some problems with being difficult to read/write, limited caching capabilities that are only on the client side, state bloat leading to a need to scale storage more efficiently, and users needing to buy verifiable caches in order to be certain of their impact on state.

Regardless of what the purpose of Etherum is, these issues need to be solved for it to serve either one as well as it should. There are some upcoming EIPs that begin to address these. EIP 2718 creates transaction envelopes that allow for different transaction types to be created. EIP 2930 implements optional access lists, which allows users to give block producers a hint as to what part of the state will be affected by a transaction. Lastly, EIP 3584 implements block access lists which aggregate the access lists of all the transactions in a block that give access lists and hashes it in the block header to allow for verification after block proposal, similar to the way a merkle root allows for verification of transaction inclusion in a block.

Other things that we can do include a new transaction type that adds two predicates. One for only applying the transaction against a particular set of merkle leaves and one for only including the transaction if the set of merkle leaves has a particular set of values at the end of the block. This allows block producers to know which transactions will be contentious without needing to execute first, which helps us slowly and safely move from a contentious-first transaction model.

This new model also allows a separation of the block builder and proposer roles, which is essentially a generalized version of the way Flashbots works now where searchers propose blocks to miners and the proposer keeps a fee. A difference is that these predicates are set by the transacting user, which offloads some of the block proposal computation to the user client side. This should allow the block builders to charge less for building a block.

Ideal block creation that we should strive for includes pipelined data-access to allow parallelization of block production, constant time construction and verification in relation to byes included, and Bitcoin-level MEV or less. As an added bonus, separating ordering and execution of transactions leads to isomorphic (all aspects scale in a similar way) scaling.

The next steps in this plan are to write and implement an EIP. It should be safe to deploy on mainnet as an optional set of predicates, but may require a modified eth_call to generate these new transactions from old transactions and a set of services to support users’ and block builders’ state access.

Privacy Solutions

Mikerak Quintyne-Collins (HashCloak) - Survey of privacy solutions for minimizing MEV

Privacy in the context of MEV can be broken down into pre-trade privacy, failed trade privacy, and complete privacy. There are different ways of granting these types of privacy that introduce different trade-offs in trust, privacy, and complexity.

Zero knowledge proofs allow a verifier to be satisfied with the validity of a statement by the prover without the prover needing to reveal the details of the statement. They have properties that allow the aggregate proving of the validity of many transactions at once. They can be used at the application and protocol levels, but are computationally expensive and thus raise gas costs.

SGX is a hardware based encrypted enclave that validators send transactions to through a shared private key where their validity is verified and SGX outputs a proof or unencrypted transactions.

MPCs (Multi-Party Computations) allow a set of parties to jointly compute a function without knowing the inputs that other users provide but to be confident that the output is correct. This works similarly to a software execution of SGX, but is also inefficient and relies on trust assumptions regarding the behavior of node operators.

Timelock encryption is implemented through verifiable delay functions that allow an encrypted file to be read by anyone after a certain amount of time. This functions similarly to a non-interactive commit/reveal scheme, and thus has similar ux problems related to a minimum one block delay.

Threshold encryption involves a group of validators to decrypt data upon reaching a threshold percentage of key signatures, generally considered to be the threshold at which ordering finality is agreed upon in the context of MEV. It also has up to a one block delay.

Alternatives schemes include malleable cryptography (encryption schemes that allow some amount of execution on encrypted data) and order revealing encryption (encryption schemes that allow the encrypted data to be searched, such as for parts of the chain state that a tx will affect.

Flashbots is currently exploring SGX and MPC implementations to provide complete (pre-execution) privacy to transactions in the Flashbots relay without requiring the trust assumption of Flashbots being honest as it does now.

Panel - Privacy all the way down: Tackling MEV at different layers using cryptography

Panelists:

• Mikerah (Moderator)
• Deli Gong (Automata)
• Christopher Goes (Anoma)
• Can Kisagun (Secret Network)
• Jannik Luhn (Shutter Network)
• Dev Ojha (Osmosis)
• Barry Whitehat (Ethereum Foundation)

The cryptographic privacy focused systems for minimizing MEV fall in the previously discussed methods of timelock encryption, threshold decryption, trusted hardware encryption (SGX). Dev mentioned that threshold decryption can still leave a vulnerability to proposers including their own transaction before or after the rest without reordering so they use batch execution for things like AMM trades where they are able to and take a random ordering for events that don’t have an average outcome. Deli also mentioned creating “oblivious ram” which is designed to randomly change the memory access patterns in order to obfuscate signatures left behind by encryption solutions that can allow side-channel attacks.

The pros/cons of implementing these solutions at different layers are interesting considerations as well. I think the most salient point is that integration of privacy solutions with the consensus layer allow for a larger anonymity set to be bootstrapped for any transaction, which reduces the attack space for side channel attacks based on the timing and path of encrypted transactions the must be decrypted at some point to be read by the L1. Additionally, the silos created by application layer encryption lower interoperability that makes defi so powerful. All that being said, consensus layer governance is (and should be) slower to make progress on and experiment with. I think that rollups and sidechains are a great place to do this and see what the implications actually pan out to be in an adversarial setting.

Vitalik Buterin - Block space auctions in Ethereum sharding

Vitalik proposes a change to the design of Ethereum sharding that involves the separation of the role of block production and proposing. The diagram he presented is shown below:

Block builders arrange block bodies and hash them before submitting to the proposal header subnet, where the block proposer selects by fee and resubmits a signed header. The block builder that submitted that header sees this and builds the block, executing the state transitions and submitting the final block to the main shard subnet. The attesters are the committee that votes on whether a party is misbehaving and which one by voting on the availability of the built block body and the proposed header.

The important takeaway from this is that the block proposer only knows the header of the block it selects by fee when making the decision, and the block builder can only build a block that hashes to the header the proposer submitted. Once the body is committed to, there is no way for either party to reorder or exclude/include transactions in an effort to extract value. Another interesting takeaway is that the block proposer does not have to be a single entity, the role can be filled by a Multi-Party Computation or decentralized staking pool.

Vitalik also points out that this is only part of the vision he has for Ethereum. This is the economic layer that will layer together with a system of Flashbots-like relayers that take in submissions from searchers that they then use to fulfill the block builder role.

Ben Jones (Optimism) - Searching for EVM parallelism

Ben starts with an aside about how Flashbots and the concept of a Miner Extractable Value Auction are not the same but rather complementary concepts. His vision for what things will look like with L2s and Optimism in particular is that searchers operate on L2 and submit/harvest value from ordering where value from L1 inclusion is

He then gets into the real topic of the talk, EVM parallelization. Currently the EVM can only execute sequentially, which is inefficient and lowers the processing speed of the global computer that is Ethereum. In order to be able to change this, access lists of the parts of the Ethereum state a transaction touches need to be included with a transaction. Without these, it is difficult for block producers to determine because the last part of a contract call could affect a piece of state that another transaction depends on. While this is an open problem, Ben points out that this is a problem that overlaps with Flashbots’ incentives because the coinbase transfer mev-geth uses to pay miners happens at the end of a block as well.

The State and Future of MEV

Panelists:

• Hasu (Moderator)
• Phil Daian (Flashbots)
• Georgios Konstantopoulos (Paradigm)
• Dan Robinson (Paradigm)
• Mahinma Kelkar (Cornell)

Hasu started the panel by asking if the era of MEV could be over sooner than we think, and of course everyone agreed that’s the goal but that naive attempts to do so too quickly can introduce new problems. Vitalik brought up the story of ICO’s banning transactions above 50 gwei to prevent blind frontunning in the 2017 boom, but that caused frontrunners to do flooding attacks instead.

He also discusses that short re-orgs should be near impossible in Eth2 because you have to have a near majority of validators under your control due to the fact that validation is done by a committee. At some point they will implement a single secret leader election to avoid the situation where a proposer knows they will be the proposer for multiple blocks and can exploit having the last and first transactions within a sequence of blocks. Mahimna mentioned that even in single secret leader models there can be collusion outside of the network, but Vitalik countered with what he called an anti pre-revelation game where you can get rewarded from the slash penalty for anonymously “predicting” that someone would be proposer for the block with the idea that this is only worth it to do if they tried to collude with you.

Hasu asked Phil about Flashbots allowing re-orgs as part of bundles and he seemed quite against it. He thinks that it will destabilize the system and the accelerationist approach is wrong here because the stakes are large. He also responded to a question about the future of Flashbots by saying that he wants to make a turing-complete framework for expressing bot preferences and an associated cryptoeconomic system around that.

One takeaway is that encryption and fair ordering don’t solve all or the same problems. They should be seen as synergistic approaches that cover the weak spots of the other, much the same as the recurring theme of marrying democratization and minimization that the entire conference had. Also, Vitalik said that separating the powers of block production and proposing is a change that he would make were he given the chance to go back and change one thing about Eth1 (of course this is being proposed for Eth2 in his talk above). Dan said that when designing Uniswap v3 they considered adding a fee for removing/adding liquidity to prevent the LP sandwich attacks that are going on but decided it was better that the user gets the better price from added liquidity.

They briefly discuss cross-chain MEV, to which Georgios brings up the point of relayers failing to submit within the required amount of time to make an arbitrage profitable or even intentionally delaying/reordering transactions. This creates incentives for liquidity providers for cross-chain transfers at lower latency to allow quicker closing of gaps in cross-chain DEXs. Mahimna mentioned that he thinks there may not be a lot of MEV in cross-chain situations where both are fair ordering protocols, even if they’re different they may not have a large distance between the two.

Takeaways

Again, there was a recurring theme of synergy between solutions and approaches to tackling the problems that MEV introduces. It’s not a question of fair ordering vs encryption, it’s a question of how we can make them best work together in implementation to cover the weaknesses of each other. Additionally, we need to be careful about the ways that we implement these because naive controls can have unintended consequences.

Separating and decentralizing the powers of block production and proposal at the consensus layer is key to minimizing MEV, because it is the monopolization and combination of these powers that introduces the ability to unilaterally reorder transactions to your benefit. I highly anticipate that Vitalik’s proposal for Eth2 is the future of Ethereum. This would be a network of Flashbots-like private relayers that organize bundles for searchers and use these orderings to act as block builders in the system that Vitalik envisions.

Reflections

Personally, I’m not sure that “fair ordering” is the right way to go or at least that send-order is the ideal to aim for. I also think there are enough problems with receive-order that I’m just not sold on fair ordering in general. Receive ordering seems to devolve into a latency/infrastructure competition, even with the lack of a public mempool between users and a sequencer it may be possible to sniff the packets of transactions sent and frontrun them through infrastructure advantage giving speeds not accessible to the average user. Plus there’s the whole what is fair problem. I think that certain transactions are arguably more important than others, such as those that bring value to a network like oracle updates or liquidations. I’m not convinced they are more important but it’s something to think about. I haven’t seen a convincing argument for why send-order is the ideal.

Conclusion

The best part of this part of the conference is that we get to see that there are real solutions that people are working on. They aren’t perfect, but it’s encouraging that the people designing these mechanisms know that and are trying to find ways to work together to make for a better end result. Ultimately, we need to determine how to decide what is fair, how to deal with latency, and flooding in these models and we need to test encryption solutions for side channel attacks that allow the deanonymization of transactions in a way that introduces MEV.

Again, If you have any questions you can reach me at @CryptoNymph on twitter. I stay busy building my empire so apologies if I don’t get back quickly but I do try to get back. Many thanks to the Zero Knowledge podcast, Uncommon Core, Paradigm’s Dark Forest series, and MEV Senpai for helping me build the foundation to be able to understand this space enough to find my hunger for it. As always, thanks to the crew at Femboy Capital. They help in everything I do and I wouldn’t be where I am today without their support.

About Femboy Capital

Evolving from a simple joke, Femboy Capital is an autonomous cooperative incubator and DeFi accelerator that ideates, develops, and shepherds products, protocols, and initiatives within the DeFi space. Feel free to reach out if you want to know more, we are always incubating project ideas and looking for collaborators to help further them. You can get in touch through my twitter account or the official @Femboy_capital account.