MEV Summit Comment: Solve the MEV problem while accepting the existence of MEV

MEV.WTF SUMMARY PT 1 MEV.WTF SUMMARY PT 1

原文作者： Nymph

Last night's porridge, Babbitt

MEV (Maximum Extractable Value) is a hot topic right now, and I've been trying to learn as much as I can and trying to understand the different solutions and the various issues they face in implementation. This is an area worth thinking about, and it is clearly critical to the success of permission-less blockchain systems in the long run.

The 8 hours of MEV.WTF and HackMoney roundtable discussions were fascinating, but to be honest, there was a lot to digest and I needed to re-watch the sessions.

Before I get into the body of the article, some terms related to encryption that I think should be defined are SGX, TimeLock time-lock encryption, and threshold decryption (sometimes referred to as threshold encryption, interchangeable). SGX stands for Software Guard Extensions, a set of instructions that provides hardware memory encryption, where specific code and data are isolated in "enclaves" where they can run without exposure to external code. TimeLock Time Lock Encryption means to encrypt something up to a certain timestamp and then unlock it. Threshold decryption is a mechanism in which a message can be decrypted after the signature of the key sharer reaches a certain threshold value.

Finally, I'll talk about the key points I gleaned from the summit, but throughout, the opinions in this article are not my own; they relate only to the views of the speakers and the content of their speeches.

Concept to summarize

MEV is the profit that block producers/proposers can make by using their role power in the network.

We now live in a MEV world, and whether we like it or not, MEV is not going away. Permission-free blockchain systems, especially complex state Spaces affected by smart contract operations, require a certain number of MEVs to function properly. A recurring theme in the discussion below is that we should minimize the MEVs that are not fundamental to the system and democratize the remaining MEVs.

The effort to minimize and democratize MEV is of interest to both system and application developers. System developers can't move fast in the experiment, but they do need to provide application developers with tools to handle MEVs on the chain.

Here are some of the highlights of the MEV Summit:

Evolution of MEV: Charlie Noyes (Paradigm)

MEV is a measure of the profit that block producers can make by reordering or reviewing transactions, and it exists in any system that does not prove its own consistency. The concept of MEV was first proposed by PMCGoohan in 2014, while Phil Daian popularized it in 2019 with his paper Flasboys 2.0.

Now, we live in the age of MEV. What does that mean? Miners may end up collusion, applications must be designed to account for changes in MEV, some systems will fail, and there will likely be an increase in the frequency of short-term reorganizations due to Time Bandit attacks. These are blockchain-based reshuffles where participants in such attacks can gain access to MEVs.

Phil Daian (Flashbots) - When Will Crypto Economics Crash?

Flashbots recognizes the problem of centralizing the point it brings to the ecosystem and believes that the solution is a decentralized "fair, real-time marketplace" where the characteristic definition of fairness is: Pre-transaction privacy (currently dependent on trust in Miners and Flashbots), spam transaction resistance (currently dependent on trust in Flashbots), and incentives are consistent with the stability of the Ethereum network. Flashbots can upgrade by removing these trust elements, but the question remains, what is good enough decentralization? There are always trade-offs, but a good framework is robustness to system shocks to miners, bots, and users, robustness to Byzantine (malicious) operators at certain thresholds, and robustness to rational selfish operators at higher thresholds.

In a post-relay world, we must be aware of risks such as trust breakdown/spiral, cat-and-mouse game of deniable attacks, need for persistent data, major central points in the ETH stack, and vampire tokens of relay providers.

Alejo Salles (Flashbots) - MEV after EIP-1559

Miner Incentive - Will miners be incentivized to extract more MeV? But first, will they "switch chains"?

The EIP-1559 design was done without MEV in mind, assuming that users are bidding for transaction inclusion (blocks), when in reality we are now bidding for sorting, privacy, etc.

Using a framework of the characteristics required for network change, we studied short-sighted miner incentive compatibility (the system is robust to rational miners over the span of a block), user incentive compatibility (users express their true preference for transaction inclusion without having to speculate on the behavior of other users), And off-chain privacy (users and miners cannot use off-chain agreements to avoid transaction fees). This framework will be used to evaluate EIP-1559 as well as a tip-less cost model that uses only the base cost.

Flashbots Code of Ethics: Currently 85% of the computing power on the Ethereum network runs through Mev Geth clients, which introduces a new central point for the system. What if the Flashbots fill size is only s0(1-e) (slightly less than the target block size)? What is the number of unfilled blocks required to return profits?

Roundtable discussion: MEV and interoperability: ROLLUP, ACROSS L2, AND ACROSS CHAINS

Round table guests:

John Adler (Celestia)

Eli Ben-Sasson (Starkware)

Ed Felten (Arbitrum)

Ben Jones (Optimism)

Zaki Manian (iqlusion)

Question 1:How is cross-domain communication handled in the implementation?

Ben Jones :L1 is the source of the facts, so it provides the communication for inter-chain operations. Optimism uses a lowered version of the L1 model where a smart contract or account on L1 specifies the data, targets, and GAS limits that will eventually be included in the Rollup. There is an opcode on L2 that allows you to access the user who sent it on L1. You can run out of Gas on L2 and not know about it on L1, so the additional messaging exposed to developers guarantees that it will eventually be accepted.

Eli Ben - Sasson:All communication is also done through L1. We're working on something else, but I can't talk about it yet.

Ed Felten:We have a general mechanism for sending contract calls from one domain to another. You know the call will run, but you don't know the result because domains are asynchronous. Asynchronous is necessary for Rollup due to the complexity of synchronization across domains.

John Adler:Celestia is about general data availability throughput, and it does not perform transactions, so there is no asset bridge (because there are no transactions or virtual machines (VMs)). The application defines its own cross-domain communication mechanism.

Zaki Manian:IBC is an asynchronous packet messaging system for blockchains that is fast deterministic and tolerant of mediation failures in terms of chain or relay liveness.

Question 2:Apart from the Token Bridge, are there any other applications that use cross-domain communication?

● 希望存在于多条链（包括 L1 和 L2）上的应用；

● 运行链下计算以开拓 DApp 设计空间；

● 跨链账户，指整个区块链可在另一条链上拥有账户；

Question 3:Are there any different specific ways for cross-domain MEV?

● 套利机会的组合爆炸；

● 不同排序机制之间的相互作用；

● L2 内部通信不依赖于 L1 状态和终结性，因此限制较少，从而开辟了新的 MEV；

● MEV 没有被销毁，而是被移动并分馏到不同的 Layer 层；

Question 4:Whose job is reducing MEV, the system developer or the application developer?

● 尽管大家都承认这是一个哲学问题，但每个人都同意 MEV 与系统开发者和应用开发者都有关；

● 系统设计需要公平假设的普遍性，因此不能涵盖一切；

● 并非所有 DApp 开发人员都会关心网络的最大利益，他们的工作就是赚钱；

● 系统开发人员需要为应用开发人员提供 MEV 工具，以用于设计他们的 DApp；

Sunny Agarwal (Omosis) -MEV classifies and identifies potential solutions

The MEV power is usually thought of as the inclusion and sorting of transactions, but because of Flashbots relays it now also includes reading the committed transactions.

It can also include (TIMESTAMP) timestamp manipulation, such as sweepstakes that use a block timestamp as a source of randomness. One way around this problem is the BFT time, where the block time is the weighted median of the timestamp proposed by the validator.

One solution is that transactions can be encrypted in the Mempool storage pool and decrypted after sorting is complete. This can be done with trusted hardware such as SGX, TimeLock timelock encryption, and threshold encryption. Threshold encryption seems to offer the least tradeoff.

The solutions to the transaction inclusion problem can be Joint Proposals, in which the validator votes in favour of the inclusion transaction, and the block producer/sequencer must include a list of votes.

The key point is that we need to decentralize power to block producers and be aware of the trade-offs between different mitigation measures.

Hasu (Paradigm, Uncommon Core, Deribit Insights) - A summary of MEV solutions

MEV is the general term for permission-free incentives in blockchain, which can be extracted on a first-come, first-served basis. Some MEVs (such as liquidating undercollateralized positions on lending platforms or arbitraging on AMM) are positive for the ecosystem, while other types of MEVs (such as preempt and sandwich attacks) are negative and should be minimized.

So far, the main impact of MEV has been to cause financial losses to users of the Ethereum network. Seventy percent of the Gas on Ethereum is used for Dex transactions, which result in higher transaction costs due to bidding for MEVs in the Priority Gas auction. In addition, because of the sandwich attack, the Dex trader will end up trading at a lower price.

Our goal should be to reduce MEV as much as possible, while democratizing what we cannot reduce. Minimization can be done at each level of the stack. At the consensus level, fair ordering and privacy implementations can be minimized. In the P2P layer, there is no GAS transaction mitigation and Mempool isolation (sending TX to a private Mempool that accepts the condition) scheme. In the application layer there is the Dex aggregator (which reduces the profitability of the sandwich attack and does not result in BackRun arbitrage), BackRunning as a Service (auctions the rights to the BackRun transaction and receives a cut), and out-of-chain sorting.

The general improvements that can be made are more centralized mobility and greater use of Dex aggregators, but this is not enough. Another idea is an AMM pool, which auctions off the rights to each arbitrage and returns it to the liquidity provider or user.

We need to reduce as much of the MEV as we can, and democratize the MEV that is essential to the web and dApps. The innovation has to happen at all layers of the stack, because the MEV exists at all layers of the stack.

Lakshman Sankar (Ethereum Foundation) - Is MEV a problem to be solved or a reality to be accepted?

The title of the speech is a rhetorical question, and it is clear that MEV is both a problem to be solved and a reality to be accepted. Synchronous block space is a scarce resource, and blockchains choose to handle MEVs differently, so a multi-chain world is inevitable, as is the interchain MEV.

The cross-chain MEV is probabilistic rather than deterministic due to the time delay between blocks of different chains in an asynchronous blockchain group. Different blockchains will also have different standards of fairness because they have different trade-off preferences.

These tradeoffs are present in all mitigation techniques. Fair sort adds assumptions in trusted predictors or on-chain random sources, and time lock encryption adds latency at the protocol layer. For different application sets and for different blockchains, different tradeoffs may be best.

conclusion

Well, I think that's enough, there's actually a lot more to learn at this conference, and I don't want to overload your brain. This article is a good introduction to some of the later discussions, which are beginning to become more technical.

I gathered some important information from the first two parts of the summit. First, there is a recurring theme that certain MEVs are the basis of the web, and we need to realize that we must both minimize and democratize MEVs. Another point is that each mitigation technique has special tradeoffs and implementation challenges.

If the content of the transaction is encrypted by a time lock, the transaction cannot be preempted until the finality of the sort is reasonably assumed to have been reached on a probabilistic basis. However, this introduces network latency in this hypothetical time window, and encrypted Mempool transactions generally do not solve the recombination MEV problem.

Threshold decryption can be achieved by voting the TX to be included by the non-block producer validator, where the content is decrypted when the validator threshold pair is the same as the finality of decryption and inclusion.

At some point, Sunny Agarwal comes straight to the point and says that something magical will happen about the encrypted transactions in Mempool that will be decrypted later. I don't like the magic wand encryption. Implementation details are critical to these systems, for example, you can read the example of a Ping denial attack for asymmetric Zcash transactions. We came to the conclusion that the timing and behavior of the implementation of these solutions might open up vulnerabilities that we could not detect until we figured out the details.

Reference reading:Remote Side-Channel Attacks on Anonymous Transactions"

All in all, I learned a lot by reviewing the MEV Summit speech video three times, looking up things I didn't know before, and writing this article to organize my thoughts on MEV. I'll be writing another section on MEV (maybe two, there's a lot to learn here) in the near future, and a summary of my crazy learning over the past few months.

The original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia