Authors: Jannik Luhn, Maximilian Langenfeld, Luis Bezzenberger, Jakub Al Soori
This document serves as a requirements and technical architecture document for a threshold encryption-based front-running protection mechanism for the OP Stack and Bedrock codebase, capitalizing on the capabilities of the Shutter Network. The mechanism targets the reduction of front-running and MEV-related exploits in the Ethereum DeFi ecosystem by adopting a shielded mempool using threshold encryption.
By integrating this mechanism, we foresee OP Stack-based rollups becoming more secure and efficient layers, attracting safer trading for DeFi users, more robust censorship resistance, and increased profitability. Moreover, the sequencer operators will be able to claim immunity from front-running and censoring transactions by design, while retaining their ability to collect and/or distribute back-running related MEV.
Decentralized Sequencer and MEVA designs are largely orthogonal to this proposal and complement it well.
- Executive Summary
- Table of Contents
- Introduction and Goals
3.1. Problem Statement
3.1.1. Malicious MEV and Censorship
3.1.2. MEV and Censorship on Layer 2 (L2)
3.1.3. Regulatory Implications
3.2. MEV mitigation solutions overview
3.3. OP Stack
3.4 Shutter Network
- Participant Requirements
4.1 End User
4.2 Dapp Project
4.3 Optimism Rollup Node
4.4 Optimism Sequencer
5 Component Requirements
5.1 Functional Requirements
5.1.1 Optimism Rollup Node
5.1.2 Optimism Sequencer Node
5.1.4 Front End Library
5.2 Non-functional Requirements
- Technical Architecture of Shutterized Optimism
6.2.1 Keyper Set
6.2.3 System Contracts
6.2.4 Client Library
6.3 Code Modifications
6.3.1 Shutter Inbox Contract
6.3.2 Keyper Set Contract
6.3.3 Key Broadcast Contract
6.3.4 Engine API
6.4 User Interaction
6.5 Interaction With Decentralized Sequencers
6.6 Finality Assumption
6.7 Potential Issues and Solutions
6.7.1 Liveness Failures
6.7.3 Sequencer Side-Channel Attack
- Design Options
7.1 Block or Transaction Keys
- Future Considerations
This document presents requirements and an architecture proposal for a threshold encryption-based front-running protection mechanism for the OP Stack and Bedrock codebase, leveraging the Shutter Network. The mechanism aims to provide front-running protection using an encrypted/shielded mempool and threshold encryption, as proposed in Shutter Network’s Optimism Governance Forum post.
We think by adopting this mechanism, OP Stack-based rollups become better, more neutral base layers and can gain the following benefits:
- Safer trading for DEFI users (no front-running)
- Added censorship resistance (even for centralized sequencers)
- More profitable trading for DEFI users (because less value lost due to malicious MEV)
- Sequencer can plausibly argue that they no longer have the ability to front-run transactions nor censor transactions based on their content by design (potential compliance, image and regulatory benefits for the sequencer operator)
- Sequencer still retains the ability to collect or distribute back-running related MEV (arbitrage and liquidations)
This document begins with a goals/motivation section, then presents a two-phase process for defining the architecture of a threshold encryption-based front-running protection mechanism for the OP Stack and Bedrock codebase, leveraging the Shutter Network.
The process starts with Phase 1, where high-level, solution-agnostic requirements for the mechanism are defined. This phase is primarily driven by the perspectives and needs of the end users and the sequencer, with requirements categorized by actors in the system.
Following this, Phase 2 transitions to defining Shutter-specific requirements, focusing more on the details of the proposed implementation. These requirements are categorized by expected technical components in the system.
It then outlines the user interaction with the system, followed by the core of the document, the technical architecture section. Within this section, the technical components and code modifications are outlined, a transaction flow diagram is given, among other things.
The document closes with a conclusion and future considerations.
The rising popularity of Ethereum’s open finance (DeFi) ecosystem has led to an increasing amount of maximal extractable value (MEV). Unfortunately, it has also exposed the network to potential exploitation through front-running and other MEV-related tactics, which can deter prospective investors and traders. Furthermore, the measures put in place to manage this issue have proven to be suboptimal, introducing unnecessary trust assumptions and centralization factors. For instance, MEV relays, though beneficial for market health, require a high degree of trust, making them unsustainable in their current form. To unlock the billions in side-lined investment and ensure Ethereum’s long-term base layer neutrality, an effective approach to transaction ordering and inclusion is required.
Front-running and malicious MEV extraction pose significant threats to Ethereum’s ecosystem. Front-running involves the unethical practice of a broker executing orders on a security for its own account while taking advantage of advance knowledge of pending orders from its customers. On Ethereum, this has resulted in a measurable amount of value extraction from users. MEV relays, which were introduced as a solution, unfortunately introduce centralization risks due to the required high degree of trust.
This tendency to centralize parts of the transaction supply chain infrastructure not only adds censorship vectors but also facilitates actual censorship on the protocol level, as evidenced by instances of adherence to sanctions lists such as the Office of Foreign Assets Control (OFAC) list.
Layer 2 solutions, which aim to scale Ethereum’s network by processing transactions off the main blockchain, face a similar yet distinct set of challenges. Here, the problem lies in the private mempools and potential spamming issues. Currently, rollup sequencers — responsible for collecting and submitting transactions on L2 — are trusted not to extract MEV. However, this centralized approach could potentially amplify the MEV issue in the long term. To avoid front-running, we place our trust in the sequencer, inadvertently consolidating their power, thus creating an unsustainable and censorship susceptible system.
The regulatory landscape poses another challenge. Regulatory bodies worldwide have begun to clamp down on front-running, potentially categorizing sequencers who extract malicious MEV as financial intermediaries, rather than purely technical entities. This could complicate compliance, as financial intermediaries are subjected to stringent regulatory requirements. Consequently, without proper management of MEV, Ethereum could face stricter regulations, deterring users and stifling growth in the DeFi sector.
- Proposer Builder Separation (PBS): Proposer-builder separation (PBS) is a proposed upgrade for Ethereum that divides the tasks of creating and broadcasting blocks between multiple validators, enhancing censorship resistance, preventing hobbyist validators from being outcompeted by institutional players, and aiding Ethereum’s scalability; it also reconfigures the economics of maximum extractable value (MEV), allowing any validator to benefit from sophisticated MEV extraction performed by block builders.
- MEV Auctions (Optimism MEVA): Optimism MEVA is a proposal for an auction-based system where proposers bid for the right to order transactions within a block, reducing the potential for MEV extraction.
- MEV Revenue Sharing Approaches: These approaches involve mechanisms that redistribute MEV to various stakeholders, thus diminishing the potential profits from malicious extraction.
- Trust in Sequencer or MEV Relay to Not Front-run: This approach depends on the trustworthiness of a sequencer or MEV relay to act in the best interests of users and not engage in front-running.
- Encrypted Mempools: Encrypted mempools are a way to hide transaction information until it is included in a block, preventing front-running and other MEV extraction tactics.
Solution Comparison Table
|Solution||Reduces or Redistributes MEV?||Trust Requirement|
|Proposer Builder Separation (PBS)||Redistributes||Separates trust requirements|
|MEV Auctions (e.g. Optimism MEVA)||Redistributes||Depends on specific implementation|
|MEV Revenue Sharing Approaches||Redistributes||Usually introduces additional trust requirements|
|Trust in Sequencer or MEV Relay to Not Front-run||Reduces||Introduces additional trust requirements|
|Encrypted Mempools||Reduces||Reduces trust requirements|
In conclusion, a comprehensive solution to the MEV problem may involve a combination of multiple strategies. For instance, encrypted mempools could be used to significantly reduce malicious MEV, and then redistribution frameworks such as Optimism MEVA could be applied to manage the remaining MEV. The goal is to balance the need for trust with the potential to reduce or redistribute MEV effectively.
The OP Stack, managed by the Optimism Collective, is a standardized, shared, and open-source development stack that fuels Optimism. Currently powering the Optimism Mainnet, it’s expected to evolve and shape the Optimism Superchain and its governance. Its design promotes a shared, high-quality system for creating new L2 blockchains, minimizing the need for siloed software development.
The “Optimism Bedrock” is the latest iteration of the OP Stack, providing tools to launch production-quality Optimistic Rollup blockchains. It’s designed to support the Optimism Superchain, a proposed network of L2s that share security, communication layers, and a common development stack.
As an evolving concept, the OP Stack will grow and adapt with Optimism, aiming to simplify the deployment of new L2 Rollups and foster interoperability among different chains within the Superchain ecosystem. For those interested, resources are available to explore the OP Stack further and launch a Superchain-ready L2.
Shutter is an anti-frontrunning, malicious MEV-preventing protocol using threshold encryption. It’s intended to be used as a plugin by any L1/L2 protocol to provide front-running and censorship resistance via implementing a shielded/encrypted mempool.
Shutter incorporates a Distributed Key Generation (DKG) scheme into an L1 or L2 rollup sequencer mechanism to protect all dapps deployed on the rollup by default while also improving censorship resistance and potentially latency properties. In principle, it operates by making the sequencer accept encrypted transactions in their blocks and revealing and executing them only once they are ordered.