Ensuring User Protection and Rollup Revenue with Radius and MEV-Boost

[Tariz]

By Tariz, Co-Founder & ZK researcher at Radius

Abstract

The following presents a novel approach to balance the tradeoff between protecting users against harmful MEV (frontrunning, sandwiching) and generating revenue for rollups. The proposed solution is a trustless zk-based shared sequencing layer (developed by Radius) in collaboration with MEV boost to maximize capital efficiency and revenue for rollups while ensuring user transactions remain unaffected.

The proposed solution consists of a two-tiered blockspace structure: Top blockspace is intended for regular user transactions and offers cryptographic protection against harmful MEV, while the Bottom blockspace is designed for builders to carry out revenue-generating activities.

Problem

Rollups face the challenges of balancing the tradeoff between protecting users against harmful MEV and generating revenue from blockspace. While rollups employ a single operator to use a FIFO (first-in, first-out) approach to protect users from harmful MEV, this may sacrifice potential revenue from blockspace and overlook the importance of economically rational actors in contributing to the stability and growth of the rollup ecosystem. Additionally, operators must consistently prove they are adhering to FIFO principles and avoid changing the block order.

Using the bottom blockspace can generate revenue for rollups, but it can also pose a challenge related to user trust. Users must trust that the rollup operator did not exploit the bottom blockspace and subject their transactions to sandwich attacks.

To address these issues, we use a cryptographic method to create a trustworthy environment between users and rollups. This can protect users against harmful MEV in the Top blockspace while utilizing the Bottom blockspace for revenue generation.

Design

We divide the rollup blockspace into two sections:

• Top blockspace: This space is for regular user transactions and provides cryptographic guarantee of harmful MEV protection using PVDE
• Bottom blockspace: Builders can use this space to build the most profitable bundle of transactions by considering the rollup state and transactions in the Top blockspace.

Top Blockspace: Harmful MEV protection

The shared sequencing layer consists of the following components to protect user transactions from harmful MEV:

1. Encryption-as-a-Service (EaaS): Enables secure transaction encryption using Practical Verifiable Delay Encryption (PVDE), a zero-knowledge-based scheme that employs time-lock puzzles to generate zk proof on user’s side.
2. Sequencing-as-a-Service (SaaS): Sequences encrypted transactions ensuring a fair sequencing mechanism.

The process of protecting user transactions from harmful MEV works as follows:

The user encrypts the transaction and sends it to the sequencer. The sequencer must determine the transaction order and send it to the user before they can decrypt the transaction and view the contents.

User:

1. Creates a transaction
2. Encrypts it using a symmetric key, a solution to the time-lock puzzle
3. Generates zk proof to prove the integrity of the time-lock puzzle and the encrypted transaction with PVDE
4. Sends the time-lock puzzle, encrypted transaction, and zk proof to the sequencer

Sequencer:

1. Verifies the validity of the user’s transaction and time-lock puzzle with zk proof
2. Starts solving the time-lock puzzle to find symmetric key (sequentially compute 2^T)
3. At the same time, the sequencer determines the block transaction order and sends commitment to the user. This must be completed before solving the time-lock puzzle
4. Once the symmetric key is found, the sequencer decrypts the transaction and includes the transaction in the next block

Bottom Blockspace: Revenue generation for rollups with MEV Boost

The sequencer orders the decrypted transactions in the top blockspace and submits them to the mempool. Searchers and builders view the transactions in the top blockspace and use the bottom blockspace to build the most profitable bundles submitting a bid to MEV Boost.

• Searchers are economically rational actors who specialize in building profitable bundles of transactions using advanced strategies like back-running, arbitrage, and liquidation.
• Builders create the optimal combination of bundles received from searchers and add them to the bottom blockspace before submitting them to MEV Boost.
• MEV-Boost selects the block with the highest bid from the blocks received from builders and submits it to the sequencer.

Architecture

Solution Implementation

360° (https://360dex.io) is a DEX that fully implements the structures described earlier, including the core components of the shared sequencing layer (SaaS and EaaS) and the bottom blockspace (batchspace) structure, delivering transactions in batches to validators.

In correspondence to the above structure, the top batchspace contains regular user transactions protected by PVDE, while bottom batchspace with backrunning bundles for revenue generation. The bundles are automatically created using flashloan-based arbitrage strategies without requiring their own liquidity. Transactions in the top batchspace can be opened so that MEV-Boost participants can utilize the bottom batchspace.

Practical Verifiable Delay Encryption (PVDE)

Time-lock puzzle encryption for harmful MEV resistance

Existing time-lock puzzle encryption solutions are impractical due to their high computational costs, which can result in wasted resources and DoS attacks by malicious users if an invalid puzzle is sent. Practical Verifiable Delay Encryption (PVDE) addresses this issue by generating a zk proof for the RSA group-based time-lock puzzle, making it a practical solution for protecting against harmful MEV.

PVDE generates a proof that solving the time-lock puzzle will lead to the correct decryption of valid transactions. This ensures that transaction content is revealed only after the sequencer sequences transactions, delaying the time for the sequencer to find the symmetric key needed to decrypt the transaction and effectively preventing MEV attacks.

The user’s statement is as follows:

πPVDE : The output value (also the symmetric key used for the decryption of the encrypted transaction) is found by computing the time-lock puzzle 2^T times

The circuit must include the two computations necessary to prove the statement:

1. Time-lock puzzle: g^{2^T} \ \ mod \ \ N = S_K
2. Poseidon Encryption: enc(tx, S_K ) \rightarrow C_{tx}

Details: MEV-resistant ZK-Rollups with Practical VDE (PVDE) - Layer 2 - Ethereum Research

Radius

The Future of MEV-Resistant Cross-rollup Ecosystem

Radius has been part of the Ethereum Foundation Grant developing the core architecture of Practical Verifiable Delay Encryption (PVDE) and successfully demonstrating a PoC for an MEV-resistant DEX.

The shared sequencing layer also enables a latency-free atomic bridge for cross-rollup integrations, fostering further ecosystem growth and stability while remaining resistant to harmful MEV.

[Hasu]

Hey @Tariz, thanks for sharing this proposal!

We are seeing increasing innovation in schemes that divide the building of an individual block over multiple parties and this one is an interesting addition. I have some loose questions/observations and would encourage others to add their own.

I think the most interesting fundamental question here is how the two ordering approaches should be combined. I.e. should searcher txns go at the top or the bottom of the block? Which yields better overall outcomes?

In your proposal, you are putting searcher txns at the bottom in order to capture backrun revenue for the protocol. I would argue that it would be better to put the searcher txns at the top, and this is purely additive to your goals but removes some undesirable properties.

First, while you can run an auction for bottom-of-the-block MEV in your scheme, top-of-the-block MEV is generally (much) more important on empirical grounds.

Second, if you don’t run an explicit auction for top-of-the-block MEV, it will generally form in other ways. In your case, I assume the sequencer orders encrypted txns by arrival time, so the result would be a latency auction that encourages spam and latency optimization to the sequencer. For the negative externalities incurred by that, you can look today at the Arbitrum (latency optimization) and Polygon + Solana (spam) ecosystems.

Third, users are generally in a privileged position to capture their own backrun revenues, and your scheme stands a little in the way of that. For example, look at the mev-share protocol. Here, users reveal information about their transactions to searchers, who compete to backrun them. One difference is that the profit goes straight to the user or wallet (which is preferable to these parties). Another is that mev-share is much more extensible toward searchers filling arbitrary intents for users. For example, searchers can route user transactions towards best execution, they can pay gas fees on their behalf, and more. But all of these advantages require collaboration between user and searcher before the exact user transaction is committed to the ordering.

For an alternative design that would be fully compliant with PVDE, I would encourage you to check out @sxysun’s FCFS-FBA proposal to the Arbitrum research forum. In his proposal, there is a searcher auction at the top of the block, followed by FCFS ordering at the bottom of the block, which you can additionally encrypt.

I understand that you want to use encryption but another alternative would be to not put in-flight encryption of transactions into the protocol at all. It’s very hard to do encryption in a way that maximizes revenue for the protocol and best execution for the user, and minimizes negative externalities/centralizing forces because such a scheme would have to consider the MEV supply chain in a holistic way. In the medium term, it can work. In the long term, I hope we can provide a better alternative with SUAVE as an encrypted mempool for blockchains that also satisfies the goal of revenue generation as well as user protection and expressivity.

Cheers!

[metachris]

Interesting, thanks for the writeup!

I don’t fully understand what you mean with “submitting them to MEV Boost” – do you mean something like today’s mev-boost relays?

Do I understand correctly that searchers and builders see the top-of-the-block transactions in cleartext, and just build the bottom part? Does that work with decentralization of the sequencer?

Sidenote – splitting up the blockspace like this reminds me of Ari+Co’s recent post about PROF: PROF: Fair Transaction-Ordering in a Profit-Seeking World | by IC3 | Apr, 2023 | Medium – which I understand to be a TEE-based builder that accepts partial blocks (which go to the top of the block, and private OF going to the bottom of the block).

[Tariz]

Hi @Hasu, Thank you for your response.

We appreciate the insights you have provided, and they have been quite helpful to us. We have addressed some of your questions and also I have a few additional inquiries. Furthermore, we welcome any opinions and questions from those who are interested in MEV and scaling solution.

1. bottom-of-the-block MEV / top-of-the-block MEV

In fact, our scheme is designed in such a way that it is indifferent to whether we offer the top or bottom of the block to searchers. If searchers are given access to the top of the block, they can identify good MEV opportunities based on the state values altered by the previous block. On the other hand, if we provide them with the bottom of the block, they can anticipate state values that will be affected by the included transactions to find good MEV.

In the absence of our scheme, offering the top of the block to searchers would expose the system to potential front-running and sandwiching attacks. However, with our approach, searchers are unable to see the contents of user transactions, effectively eliminating the risk of such attacks.

Thus, our primary objective is to determine the more advantageous structure between the two. We would be grateful if you could share any empirical ground or data suggesting that top-of-the-block MEV is generally more valuable.

2. FCFS-FBA

We concur that a mechanism should be implemented to enable users to give their transactions a competitive edge, such as through gas fees, to ensure network security and maintain the ecosystem’s revenue model.

From the ecosystem’s standpoint, the revenue models for top-of-the-block and bottom-of-the-block MEV differ. In the case of top-of-the-block, participants (traders, users, searchers) seeking good MEV opportunities can gain a competitive advantage for their transactions through gas fees, with the ecosystem earning revenue from these fees. For bottom-of-the-block MEV, the bids submitted alongside the bundles will serve as the ecosystem’s revenue source. To accommodate both revenue models, we are contemplating the introduction of an auction at the top of the block as an alternative to the FCFS approach.

We believe the proposed FCFS-FBA could be a viable option for our system to adopt.

3. Eliminate bad MEV

For the sustainable growth of the ecosystem, we prioritize safeguarding honest participants from financial losses over maximizing immediate revenue. Our decision to employ a zero-knowledge proof-based encryption method aims to prevent third parties from extracting funds from user transactions. Achieving sustainable revenue in the long run would be challenging if it stems from the losses of good participants or if doubt lingers over the system’s integrity. This rationale is likely the driving force behind current rollups opting for FCFS, despite the associated side effects (latency, spam).

We are curious to learn if Flashbot’s SUAVE has any additional features in its long-term vision for an encrypted mempool scheme beyond encrypting auction prices. More specifically, we are interested in the type of data you plan to offer searchers to discover MEV opportunities while maintaining transaction information confidentiality through programmable privacy. Furthermore, we would like to know if SUAVE’s ultimate objective aligns with Radius’s user protection goals (shielding user funds from sandwich attacks and front-running) and how it differs from our scheme.

[0xkookoo]

@Tariz

Sequencer:

1. Verifies the validity of the user’s transaction and time-lock puzzle with zk proof
2. Starts solving the time-lock puzzle to find symmetric key (sequentially compute 2^T2T2^T)
3. At the same time, the sequencer determines the block transaction order and sends commitment to the user. This must be completed before solving the time-lock puzzle
4. Once the symmetric key is found, the sequencer decrypts the transaction and includes the transaction in the next block

I have a few questions that may be basic in nature:

1. Could you clarify what the commitment that the sequencer sends to the users consists of? Is it solely the order of block transactions?
2. What mechanisms ensure the completion of the block transaction order commitment prior to solving the time-lock puzzle?
3. If the symmetric key is uncovered, what would occur if the sequencer alters the order of block transactions? How can such an action be prevented?
4. How to set the time of this time-lock puzzle more appropriately? Can users overwhelm the entire sequencers by sending a large amount of tx in batches? Although a single zk proof can be guaranteed to be solved within a certain time, but if the tx amount is too large, it will take longer for the entire block to be packaged, right?

[Tariz]

Thank you for the insightful questions.

1. The commitment includes information that can identify the user’s transaction and inform its order. For instance, elements like block_number, transaction_order, transaction_hash, encrypted_transaction_hash, and sequencer_signature are part of this. Here, the transaction_hash refers to the transaction hash received by the sequencer from the user.
2. The time when the sequencer discloses the order can be used to verify this. The sequencer must determine the order earlier than the decryption time.
3. One method involves verifying the validity of the order commitment based on MMR. You can refer to the writings on Ethereum research forum for more details on this. However, this is just one of the methods we are currently researching, and we are exploring other potential methods as well. In particular, I am exploring ways to verify the validity of a block’s construction based on the order during the stage of verifying the block’s validity.
4. Could you please elaborate on the scenario you’re concerned about?