Shutter for Espresso

We are excited to announce a collaboration between Shutter and Espresso, marking a significant leap forward in our quest to enhance information symmetry, base layer neutrality, security, and fairness for Ethereum and L2s. This partnership aims to introduce an encrypted mempool for the Espresso sequencer network, leveraging Shutter's expertise in threshold encryption to combat the risks of front running and censorship.

Encrypted Mempools Improve Information Symmetry

At the heart of this collaboration is a shared vision to protect users from transaction ordering and processing pitfalls. By integrating Shutter's encryption mechanisms with Espresso's decentralized sequencing capabilities, we aim to obscure transaction details in the mempool. This not only shields users from malicious activities but also ensures that transactions are processed fairly and unbiasedly.

More specifically, these are some of the benefits we expect for Espresso and L2s who would choose the Espresso Sequencer Network in combination with an encrypted mempool:

• Safer trading for DeFi users (Front running mitigation)
• Added (real-time) censorship resistance (even for centralized sequencers)
• More profitable trading for DeFi users (because less value is lost due to malicious MEV)
• Reducing sequencer trust assumptions: The encryption “blinds” the sequencer to a certain degree, disarming them and thus reducing the degree of trust required in the sequencer
• The sequencer can plausibly argue that they no longer have the ability to front run 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)

The Path Forward: Two Approaches to Integration

Our teams are exploring two approaches to achieve our goals.

Each path forward is designed with the ultimate goal of enhancing transaction security and fairness. Yet the approaches diverge in their technical execution and implications.

Approach 1: Espresso Sequencer Decrypts

In this approach, the Espresso sequencer handles both plaintext and encrypted transactions.

The process unfolds in several critical steps:

Transaction Sequencing: The sequencer initially sequences transactions without distinction between encrypted and plaintext, maintaining the order received.

Decryption Key Publication: Upon committing to a new block, Keypers—designated members of either the Espresso network or an external committee—publish the decryption key. This key is generated explicitly to decrypt transactions encrypted for that block.

Block Commitment and Decryption: Following the key publication, the sequencer, or a designated subset thereof decrypts all transactions within the committed block. A new block commitment, including the decrypted transactions, is created, ensuring they are ready for execution.

Technical Considerations

• Modification Needs: This method requires alterations to the Espresso sequencer to handle the decryption process. It must be equipped to store encrypted transactions temporarily and decrypt them once the key is available.
• Latency Impact: Introducing an encryption-decryption cycle adds a latency of approximately 5 seconds to all transactions, affecting transaction throughput and user experience.
• Security and Fairness: By encrypting transactions until the point of execution, this approach effectively mitigates the risk of front running and censorship, enhancing the trading environment's security and fairness.

Approach 2: Derivation Pipeline Decrypts

This alternative strategy offloads the decryption task from the Espresso sequencer to the derivation pipeline, involving a different set of steps:

Transaction Sequencing: Similar to the first approach, the sequencer sequences transactions as they arrive, treating encrypted and plaintext transactions alike.

Key Publication and Transmission: Once a new block is committed, Keypers publish the decryption key. However, in this scenario, the key is sent as a transaction to the sequencer to be included in a future block.

Decryption by Derivation Pipeline: Upon recognizing a decryption key in a block, the derivation pipeline uses it to decrypt previously encrypted transactions. These transactions are then processed and executed as part of the rollup.

Technical Considerations

• Rollup Contract Modifications: This approach necessitates changes to L1 rollup contracts to accommodate the decryption process within the derivation pipeline.
• Congestion and Delay Risks: Including the decryption key as a transaction means it could be delayed during network congestion, potentially impacting the timeliness of transaction processing.
• Sequencer Modifications: Unlike the first approach, this method requires no significant changes to the Espresso sequencer, allowing it to operate without the added complexity of managing encrypted transactions.

Both teams prefer option two at the moment.

A Call for Community Feedback

As we embark on this journey, we invite our community to join the conversation. Your insights and feedback are invaluable as we refine our approach to ensure it best serves the needs of our users and the broader MEV and sequencing community.

Next Steps

Stay tuned for updates as we progress in our mission to deliver a Shutterized, encrypted mempool for the Espresso sequencer network, setting new benchmarks for security and fairness in the digital age!

Follow Shutter on X (formerly Twitter), and join the Shutter Forum!