Shutterized Optimism – An Encrypted Mempool for the OP Stack

[Jannik]

Shutterized Optimism – An Encrypted Mempool for the OP Stack

Requirements and Technical Architecture

Authors: Jannik Luhn, Maximilian Langenfeld, Luis Bezzenberger, Jakub Al Soori

Executive Summary

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.

Table of Contents

1. Executive Summary
2. Table of Contents
3. 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
4. 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.3 Keyper
   5.1.4 Front End Library
   5.2 Non-functional Requirements
5. Technical Architecture of Shutterized Optimism
   6.1 Overview
   6.2 Components
   6.2.1 Keyper Set
   6.2.2 Sequencer
   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.3.5 op-node
   6.3.6 op-geth
   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.2 Latency
   6.7.3 Sequencer Side-Channel Attack
6. Design Options
   7.1 Block or Transaction Keys
7. Future Considerations
8. Conclusion

Introduction and Goals

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.

Problem Statement

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.

Malicious MEV and Censorship

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.

MEV and Censorship on Layer 2 (L2)

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.

Regulatory Implications

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.

MEV mitigation solutions overview

1. 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.
2. 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.
3. MEV Revenue Sharing Approaches: These approaches involve mechanisms that redistribute MEV to various stakeholders, thus diminishing the potential profits from malicious extraction.
4. 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.
5. 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.

OP Stack

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 Network

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.

[Jannik]

Participant Requirements

This section defines requirements for a threshold encryption-based front-running protection mechanism for OP Stack and Bedrock. They are high-level, solution-agnostic, and primarily driven by the perspectives and needs of the participants in the system who are as follows:

1. End users: These are individuals who interact with the system, usually by submitting transactions.
2. Optimism sequencer: The Optimism sequencer is a component of the Optimism rollup architecture, responsible for ordering and executing transactions by building new rollup blocks.
3. Optimism rollup node: The Optimism rollup node is a component of the Optimism rollup architecture, syncing the rollup state from the sequencer and the L1 chain.
4. Dapp project: Dapp projects provide some service to end users and typically consist of a set of smart contracts deployed on the Optimism chain, a browser-based frontend, and potentially additional components.

End User

1. User experience and security should be comparable to using a Dapp on Optimism today.
2. Users can submit encrypted transactions that cannot be frontrun.
3. Users can still send unencrypted transactions that have the same execution guarantees as before.
4. Inclusion and execution latency for unencrypted transactions is similar to the status quo.
5. Inclusion and execution latency for encrypted transactions is not much higher than for unencrypted transactions.
6. Transaction fees for unencrypted transactions is the same as the status quo.
7. Transaction fees for encrypted transactions is not much higher than for unencrypted transactions.

Dapp Project

1. Comprehensive documentation on the front-running protection mechanism is available.
2. Existing front-end applications require no to minimal changes to remain compatible.
3. A frontend library that handles the encryption, submission, and execution status tracking of encrypted transactions is available.
4. Usage of the system requires no additional networking besides the existing JSON RPC interface.

Optimism Rollup Node

1. Setup and operation of the rollup node should be similar to the status quo.
2. Additional computational overhead of decrypting transactions does not significantly impact hardware requirements.
3. Error handling and reporting mechanisms for issues related to transaction decryption or processing are reliable and robust.
4. The node can scale in response to increased demand for encrypted transactions.
5. Failures are handled gracefully.

Optimism Sequencer

The sequencer inherits the rollup node requirements.

1. The sequencer can plausibly argue that they no longer have the ability to front-run transactions by design.
2. The sequencer can plausibly argue that they no longer have the ability to censor transactions based on their content by design.
3. Encrypted and unencrypted transactions are processed within the same pipeline.
4. The sequencer can reject encrypted transactions if they do not pay an appropriate fee, taking into account the cost of both storing it on L1 as well as executing it.

Component Requirements

This section defines requirements for a concrete instantiation of a threshold encryption-based front-running protection mechanism, leveraging the Shutter Network. It first defines the main software components generally needed for such a system and then states requirements on them.

The technical components in the system are as follows:

1. Optimism rollup node: The rollup node reads the L2 state from the sequencer’s unsafe sync and occasionally compares it with the L2 state locally derived from L1 sequencer batches and deposit data. The rollup node also propagates unsafe, safe and finalized block data within a P2P network. It uses the same software as the sequencer but in a different mode of operation and as a different entity in the Optimism system.
2. Optimism sequencer node: The sequencer accepts transactions via a (private) mempool and integrates them in new L2 sequencer batches, which will eventually be included in an unsafe block,persisted on L1 and later included in a finalized block.
3. Keyper set: The keypers run a distributed key generation (DKG) protocol. This process outputs a single public key as well as one secret key share for each participant. From the public key, encryption keys can be derived. The keypers can compute the corresponding decryption key in a collaborative manner. The process assumes that at least a certain fraction (e.g. 2/3) is honest and online.
4. Frontend library: The frontend library helps Dapps to use encrypted transactions in the user interface.

Functional Requirements

Optimism Rollup Node

1. The rollup node reads decryption keys from the chain.
2. The rollup node verifies correctness of decryption keys.
3. The rollup node decrypts encrypted transactions included in the chain with the decryption key.
4. The rollup node executes decrypted transactions in the order that the sequencer has arranged the corresponding encrypted transactions in the block.
5. The changes do not affect inclusion and execution of deposit transactions.
6. The state does not progress without decryption keys to prevent frontrunning.
7. The system provides a mechanism to indefinitely stop execution of encrypted transactions in case the keypers fail to produce decryption keys.
8. The rollup node implementation is based on the OP Mainnet node with minimal modifications.

Optimism Sequencer Node

1. The sequencer accepts both plaintext and encrypted transactions through the existing mempool.
2. The sequencer chooses to include encrypted transactions in a block if they pay a fee appropriate to its resource requirements at both inclusion and execution time.
3. The sequencer has a guarantee at inclusion time that encrypted transactions pay a fee for their execution.
4. The sequencer receives decryption keys from the keypers and includes them in their blocks after validating them.
5. The sequencer does not store state in memory that if lost would prevent the chain from making progress.
6. The sequencer implementation is based on the OP Mainnet sequencer with minimal modifications.

Keyper

1. The keypers generate a public key used to derive encryption keys and broadcast it on L2.
2. The keypers read the keyper set membership and peer information from a contract on L2.
3. The keypers generate the decryption keys for encrypted transactions.
4. Hardware requirements should allow running a keyper node on a consumer grade laptop given access to an external rollup node.
5. In order to circumvent sequencer censorship, the keyper is able to send deposit transactions via L1.
6. The keyper software is implemented in Go.

Front End Library

1. Comprehensive documentation of the library API and usage patterns exists
2. The library exposes a small API surface and hides away implementation details
3. The library integrates well with existing commonly used front-end libraries.
4. The library is implemented in JavaScript or TypeScript.

Non-functional Requirements

Disclaimer: At this stage in the architectural planning process, these are provisional estimates for non-functional requirements and are subject to change.

1. At least 20 keypers
2. New epoch every 4 seconds.
3. Inclusion confirmation within one block.
4. Execution confirmation for unencrypted transactions within one block.
5. Execution confirmation for encrypted transactions within two blocks.
6. No gas overhead for unencrypted transactions.
7. Less than 3x gas cost for a typical encrypted transaction.

Technical Architecture of Shutterized Optimism

Overview

The main addition to the stack is the set of keypers, a committee responsible for generating keys that will be used to encrypt and decrypt transactions. Its members are managed by a contract on L2, the Keyper Set Contract. In a one-time setup phase, they generate the so-called eon public key and broadcast it via the Key Broadcast Contract.

In addition to standard transactions, the system allows users to send encrypted transactions that will be protected from frontrunning and censorship. To do so, users have to first create the payload (consisting of receiver, calldata, and value) and then encrypt it with the eon key. They then submit the encrypted payload to the Shutter Inbox Contract via a so-called Commit Transaction. The contract stores the payload in its storage and charges the user a fee which covers the gas the scheduled transaction is going to use when being executed. The amount is derived from the gas price as well as a user-provided gas limit and sent via the Commit Transaction’s value field.

Whenever the sequencer seals a block, the keypers collaboratively generate the decryption key for it and broadcast it on a P2P network. The sequencer picks it up and puts it – in the form of a so-called Reveal Transaction – at the front of the block. Executing this transaction will result in all encrypted transactions that have been scheduled previously being read from the ShutterInbox Contract, being decrypted and executed.

The state transition function ensures that the sequencer plays by the rules, i.e., that blocks fulfill the structure outlined above. In particular, blocks without a decryption key at the top (or an incorrect one) are invalid.

Internal structure of blocks: Time increases from left to right, with decryption processes between the blocks. Inside of the block structure, transactions are executed in a left to right order. Decrypted payloads committed one block earlier are executed within the “Reveal Transaction” at the beginning of the block. (high res)

[Jannik]

Components

Keyper Set

The keyper set is a threshold-committee consisting of at least 20 members. During a setup phase, the keyper set generates the eon public key and broadcasts it. This key will be used by users to encrypt payloads. After each block produced by the sequencer, the keyper set generates a decryption key that can be used to decrypt these payloads.

It is assumed that at least a certain number of keypers – the threshold – is online and behaves honestly. If not, they can produce decryption keys before the corresponding block has been produced and use this advance knowledge to frontrun in collusion with the sequencer.

Sequencer

The job of Optimism’s sequencer is to receive transactions from users, build blocks, broadcast them, and submit them to L1. In addition to that, this proposal requires them to listen on a P2P network for decryption keys from the keypers and produce blocks with slightly altered rules.

System Contracts

The system relies on a small suite of smart contracts deployed on L2:

• The Keyper Set Contract: Manages the set of keypers.
• The Key Broadcast Contract: Acts as a billboard on which keypers can publish the eon public key.
• Shutter Inbox Contract: Collects encrypted payloads and metadata submitted by users in the form of Commit Transactions.

Client Library

This frontend library provides functions for Dapps to easily

• retrieve the eon public key from the Key Broadcast Contract,
• create and encrypt payloads,
• submit them to the Shutter Inbox Contract via Commit Transactions, and
• be notified when they are included as well as decrypted and executed.

Diagram of the different components making up the Shutterized Optimism System. Arrows indicate the data flow starting with the user submitting a plaintext as well as an encrypted transaction and ending with it being executed on the chain. Numbered text over arrows describe successive steps in the block building process. (high res)

[Jannik]

Code Modifications

This section describes the main modifications that have to be implemented on top of the existing OP Stack and Bedrock codebase. In addition, it describes the required system contracts.

Shutter Inbox Contract

The central system contract is the Shutter Inbox Contract. It exposes the commit function which can be called by standard Ethereum transactions. In the following, those are named Commit Transactions.

The user encrypts a payload, consisting of data, value and to fields, and attaches this in serialized form as an argument to the commit call. Additional arguments are the future block-number when the transaction has to be executed as well as the estimated gas-limit for the execution. The Commit Transaction has to include an ETH-transfer to the contract via the transaction’s value field, so that the amount is equal to the gas-limit argument multiplied by the gas-price of the Commit Transaction.

The contract will store a FIFO-queue of the passed in arguments together with the sender address in its storage. The contract makes sure that the cumulative gas-limits of the queue can never surpass the block-gas-limit, otherwise the contract call fails. In order to keep the total state-growth constant, the contract will only accept and enqueue transactions where the block-number argument equals the next block number, and the contract will delete all previous transactions from the queue once they are handled in the Reveal Transaction. The accumulated gas transferred to the contract via the Commit Transactions can be withdrawn by a configurable account, e.g. the sequencer or a DAO.

Keyper Set Contract

The Keyper Set Contract manages the current keyper set. It allows an owner, e.g. the OP DAO, to add and remove members at will at certain block numbers. The keyper set contract also defines an emergency shutdown mechanism described in more detail in the “Potential Issues and Solutions” section.

Key Broadcast Contract

The Key Broadcast Contract is a simple billboard that allows any keyper set to broadcast its eon public key after they generated it. Users can fetch it from there.

Engine API

In order to include the decryption key in the block and make it available in the state-transition-function (STF), it has to be passed from the receiving end (op-node) to the block-building engine in op-geth. Therefore the EngineAPI payload-attributes for the engine_forkChoiceUpdatedV1 have to be extended to include a decryption-key field.

op-node

The op-node is responsible for initiating the construction and release of new blocks in the op-geth node in regular intervals. It does so by continuously adding transactions to the block candidate at all times. This process now has to be paused briefly after each proposed block until the keypers have produced the decryption key.

Concretely, the time between a sequencer’s unsafe head update and the successful keyper-decryption process blocks the execution of the next call to engine_forkChoiceUpdatedV1. Since the decryption key generation time is variable, the op-node adjusts the time for successive calls to engine_getPayloadV1 / engine_newPayloadV1 in order to keep the overall block time constant.

The op-node additionally communicates with the set of keypers by operating a libp2p module that connects to the keypers and subscribes to a decryption-key topic via the gossipsub protocol. The op-node has to have access to the current layer 2 blockchain state, in order to verify keyper-set membership and the validity of received decryption keys.

op-geth

The miner in op-geth is responsible for assembling new blocks. To do so, it picks transactions from the sorted mempool as well as deposit-transactions received from the op-node via the payload-attributes of the EngineAPI.

Block-building is initiated by the op-node via the Engine API. In this process, additional constraints have to be fulfilled and considered for block validity. It requires the decryption key for transactions included in the previous block, which the miner receives via the payload-attributes from the op-node.

The first transaction to be executed in the block’s state-transition function is the special Reveal Transaction. It is exclusively assembled by the miner and contains the decryption key. It fetches the encrypted payloads for this block from the Shutter Inbox Contract and decrypts them. Subsequently, it executes it, taking the corresponding metadata fields sender and gas limit into account. Note that the gas for the transaction has already been paid for by Commit Transaction.

After successful execution of the decrypted payload, the resulting events of all decrypted transactions are included in the receipt of the Reveal Transaction. In the remainder of the block, the miner includes new transactions from the mempool as usual, including Commit Transactions for the next block. The miner takes the execution gas limit of the latter into account in the scoring function used for mempool ordering.

Sequence diagram of the block building process. Two iterations of block building are shown - in the first, only the inclusion of normal transactions is shown in detail. In the second, only the inclusion of the Reveal Transaction is shown in detail. “NextBlock” represents the current locally built block within the sequencer’s memory. “Layer2State” represents the publicly visible unsafe head state of the layer 2 blockchain. (high res)

User Interaction

The user experience of using encrypted transactions is very similar compared to normal ones, and involves only a few additional steps in the transaction submission and status notification process. When using a specific Dapp frontend, an action that posts a transaction to the blockchain will be handled in the following way:

The user will be informed beforehand that the gas mechanism of this transaction is handled differently and the value transferred to the inbox contract is a pre-payment of gas for execution of the revealed transaction. In the background, the Dapp will locally handle the gas estimation of the payload, eventually fetch the relevant encryption inputs from the L2 chain, and encrypt the payload.

The Dapp then constructs a normal Ethereum transaction that calls the commit function of the Shutter Inbox Contract and adds the calculated execution-gas to the transaction’s value field.

Next, the Dapp will ask the user’s wallet to send the transaction, which in turn will prompt the user to sign it. Finally, the wallet will submit the signed transaction to the Optimism JSON RPC endpoint.

The Dapp will then continuously show the current execution status of the user’s transaction – but execution confirmation will take longer than usual: As a first pre-confirmation, the Dapp will check the layer 2 chain for successful inclusion of the Shutter Inbox call in the latest block. As soon as the Commit Transaction has been included, the user will see the status of the transaction as “committed, waiting for decryption and execution”.

Once the corresponding decrypted payload is found in the Reveal Transaction of the next block and executed successfully, the user will see the status of the transaction as “revealed, successfully decrypted and executed”. The Dapp may read the receipt of the Reveal Transaction and construct more detailed information on the transaction’s execution. Among others, this receipt indicates if execution was successful or if it reverted, e.g. due to running out of gas.

In case the Reveal Transaction receipt does not contain a trace of the decrypted payload, it was invalid.

Interaction With Decentralized Sequencers

Decentralized Sequencer and MEVA designs are largely orthogonal to this proposal. The only requirements for Shutterized Optimism on the block proposal mechanism are that they come with a certain degree of finality, or achieve it quickly over time (without additional blocks).

Finality Assumption

The system assumes that unsafe heads are final, as the keypers release the decryption key immediately upon observing them. If they are not, i.e., if a malicious sequencer can create a competing fork, this sequencer would be able to frontrun. Note that this attack would be both provable and attributable. We therefore recommend that the sequencer has to deposit a stake that will be slashed in case the sequencer attempts this attack.

Potential Issues and Solutions

Liveness Failures

The main failure to consider is a liveness failure caused by the keypers not producing the decryption key. This would prevent the sequencer from proposing the next valid block. For this scenario to take place, Shutter’s threshold assumption has to break: More than 1 - t keypers have to be offline, where t is the threshold parameter.

To recover from this and similar types of failure, Shutter can be disabled by a smart contract emergency switch. In that case, the rollup’s operation would fall back to standard Optimism mode. In particular, this would allow the sequencer to produce a block without including the decryption key, so that the system can continue to make progress. This cannot be used to frontrun as encrypted transactions will never be decrypted nor executed. Various options exist for which entities could trigger the emergency switch: The sequencer, OP governance, Shutter governance, or a subset of the keyper set itself. In addition, the switch could be conditional on the duration in which no block has been produced.

Latency

Encrypted transactions are executed over the course of two blocks (commit in some block, reveal in the next). Naturally, their latency until execution increases by a factor of two. Latency until inclusion of the Commit Transaction is still only a single block (note that inclusion guarantees later execution). Standard transactions are largely unaffected by Shutter, so they will still be included and executed in the next block.

However, building a block now involves generating the decryption key. Since this is carried out in a distributed manner over a P2P network, the default block time may have to be increased. The exact number will depend on the number of keypers and network latency, but a cautiously optimistic estimate is 4s.

Sequencer Side-Channel Attack

The design involves a potential issue related to the sequencer’s ability to freely choose block attributes. This control enables the sequencer to affect the execution path of previously committed transactions at a time when they already know the decryption key. This allows them to frontrun.

For instance, the sequencer may include a transaction at the top of the block that buys a token on a DEX if the block timestamp is even and sells it if it is odd. As soon as they receive the decryption key, they can decrypt the other transactions, and learn about the resulting price movement over the course of the block. By choosing the timestamp for the next block accordingly (even if it increases, odd if it decreases), they can effectively frontrun.

The sequencer can thus potentially gain an unfair advantage by executing transactions based on privileged information before other participants.

As a possible prevention mechanism, the sequencer has to commit to all variable block parameters already in the previous block. In order to prevent any degrees of freedom in the block attributes, the sequencer has to pre-commit to the block attributes difficulty, layer1-origin-hash, coinbase, and timestamp.

However, this step has to be carefully considered in order to make sure normal operation is not negatively affected.

Design Options

Block or Transaction Keys

Shutter uses an identity-based encryption scheme. This means that the encryption key is derived from the eon public key and an identity, an arbitrary parameter. This parameter is also used when the corresponding decryption key is generated. There are two major options how to choose the identity:

• one identity per block (e.g., the block number)
• one identity per transaction (e.g., a custom nonce)

The advantage of block keys is efficiency: Only a single decryption key per block has to be generated and included in each block. However, they have a negative UX impact: Before sending a transaction, users have to figure out what the identity value of the next block will be (or rather, the identity value of the block in which they want their payload to be executed). This can be difficult if network latency is high and may lead to higher confirmation times if users have to estimate more conservatively. In addition, encrypted payloads will be revealed even if the transaction is not included at all, e.g., due to high latency, network congestion, or a malicious sequencer. Note however, that an already revealed transaction can not be included later on, so this does not make the transaction susceptible for frontrunning.

Transaction keys, on the other hand, can be derived purely locally without any knowledge over the state of the system. This makes the user experience maximally straightforward and prevents revelation without inclusion. On the other hand, the system is less efficient because for each transaction a separate key has to be included.

Future Considerations

For the purpose of this proposal, practicality and low implementation complexity were primary goals. When these become less important in future versions, more options open up. Here we describe three.

Instead of including encrypted transactions in the chain and decrypting them during execution, it is possible to do the opposite: Only commit to a hash of all encrypted payloads, and at time of execution only include the decrypted payloads. As part of the state transition function, the payloads would be encrypted again in order to check correctness against the commitment. This approach is more efficient: Decrypted transactions can be compressed much better than encrypted ones, so they use less of the expensive L1 space.

The main drawback of this, however, is a much higher complexity in the sequencer: They need to keep track of which transactions they have committed to in the previous block. If they lose this data, e.g., during a crash at an inconvenient time, they will be unable to produce a valid block and the system is stuck.

Zero knowledge proofs are another potential tool to increase efficiency: A zkSNARK that proves correct decryption would allow omitting the decryption keys from the chain altogether, thus severely limiting the L1 footprint of the system, in particular if transaction keys instead of block keys are chosen. Furthermore, users could use zero knowledge proofs to make statements about their account balances without revealing the sender account, which in the current system is leaked to potential attackers. Unfortunately, zero knowledge technology is still somewhat complex.

Lastly, a potential modification to make reorg attacks by the sequencer much harder is to involve the keyper committee: In addition and simultaneous to the decryption key generation, they could produce a threshold signature on the current head of the chain. The state transition function would check this signature in order to make sure that no reorg has happened. In order to successfully attack, the sequencer would thus not only have to produce a competing block, but also require the keypers to sign it off.

Conclusion

In this document, we have proposed modifications to the OP Stack to provide front-running protection and censorship resistance to its users. The required changes are relatively small in scale, not overly complex, and viable to implement.

We have evaluated failure cases and outlined robust solutions for such scenarios, with the legacy system always serving as a fallback point to recover to, even in the worst-case.

Notably, the proposed architecture does not compromise the user experience of normal transactions, while also providing an only slightly diminished user experience for front-running protected transactions. Importantly., it is possible to submit encrypted transactions with standard wallets, requiring only small frontend modifications that can be implemented straightforwardly by using a provided library.

Overall, the outlined software architecture lays a solid foundation for a front-running protection system, balancing practicality, complexity, and security.

[Jannik]

Due to character limits, we had to split this up into multiple posts. Here’s the whole document as a PDF.