Shutterized Optimism – An Encrypted Mempool for the OP Stack

[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)