Per-transaction encryption to fight malicious MEV

Malicious MEV attacks pose a significant threat to traders on Ethereum. Our latest research shows that almost 2,000 sandwich attacks happen daily and more than $2 million is extracted from the network each month. Even traders who execute large WETH, WBTC or stable swaps remain at risk and can lose a substantial portion of their trades. 

MEV thrives because of the transparent nature of blockchains, where transaction data is visible before transactions are executed and finalized. One path toward mitigating MEV is mempool encryption, particularly through the use of threshold encryption. In our earlier articles, we examined two different models for threshold-encrypted mempools. Shutter, one of the first projects to apply threshold encryption to protect the mempool, introduced a per-epoch setup. Batched threshold encryption (BTE), a newer model, decrypts multiple transactions with a single key to reduce communication costs and raise throughput.

In this piece, we analyze Flash Freezing Flash Boys (F3B) by H. Zhang et al. (2022), a newly proposed threshold encryption design that applies encryption on a per-transaction basis. We explore its mechanics, explain its scaling properties as concerns latency and memory, and discuss the reasons it has not yet been deployed in practice.

How Flash Freezing Flash Boys implements per-transaction encryption

Flash Freezing Flash Boys addresses limitations in early threshold encryption systems that relied on per-epoch setups. Projects such as FairBlock and the early versions of Shutter used a single key to encrypt every transaction within a selected epoch. An epoch is a fixed number of blocks, e.g., 32 blocks on Ethereum. This created a vulnerability where some transactions that fail to be included in the specified block ends would still be decrypted with the rest of the batch. This would expose sensitive data and open up MEV opportunities to validators, thus making them vulnerable to front-running.

F3B applies threshold encryption on a per-transaction basis, which ensures that each transaction remains confidential until it reaches finality. The general flow of the F3B protocol is shown in the figure below. The user encrypts the transaction with a key that only the designated threshold committee, known as the Secret Management Committee (SMC), can access. The transaction ciphertext and the encrypted key are sent to the consensus group as a pair (Step 1). Thus, nodes can store and order transactions while retaining all required decryption metadata for prompt post-finality reconstruction and execution. Meanwhile, the SMC prepares its decryption shares but withholds them until the consensus commits the transaction (Step 2). Once a transaction is finalized and the SMC releases enough valid shares (Step 3), the consensus group decrypts the transaction and executes it (Step 4).

Per-transaction encryption had long remained impractical due to its heavy computational load for encryption and decryption as well as the storage requirement from large encrypted payloads. F3B addresses this by threshold-encrypting only a lightweight symmetric key instead of the full transaction. The transaction itself is encrypted with this symmetric key. This approach can reduce the amount of data that needs to be asymmetrically encrypted by up to ~10 times for a simple swap transaction. 

Comparison of different cryptographic implementations of F3B and their latency overhead

Flash Freezing Flash Boys can be implemented with one of two cryptographic protocols, either TDH2 or PVSS. The difference lies in who bears the setup burden and how often the committee structure is fixed, with corresponding advantages and disadvantages in flexibility, latency and storage overhead.

TDH2 (Threshold Diffie-Hellman 2) relies on a committee that runs a distributed key generation (DKG) process to produce individual key shares along with a collective public key. Then, a user creates a fresh symmetric key, encrypts their transaction with it, and encrypts that symmetric key to the committee’s public key. The consensus group writes this encrypted pair onto the chain. After the chain reaches the required number of confirmations, committee members publish partial decryptions of the encrypted symmetric key together with NIZK (Non-Interactive Zero-Knowledge) proofs, which are required to prevent chosen-ciphertext attacks, where attackers submit malformed ciphertexts to try to trick trustees into leaking information during decryption. NIZKs guarantee the user’s ciphertext is well-formed and decryptable, and also that trustees submitted correct decryption shares.  Consensus verifies the proofs and, once a threshold of valid shares is available, reconstructs and decrypts the symmetric key, decrypts the transaction, and then executes it.

The second scheme, PVSS (Publicly Verifiable Secret Sharing), follows a different path. Instead of the committee running a DKG in every epoch, committee members each have a long-term private key and a corresponding public key, which is stored on the blockchain and accessible to any user. For each transaction, users pick a random polynomial and use Shamir’s secret sharing to generate secret shares, which are then encrypted for each chosen trustee using the respective public key. The symmetric key is obtained by hashing the reconstructed secret. The encrypted shares are each accompanied by an NIZK proof, which allows anyone to verify that all shares were derived from the same secret, along with a public polynomial commitment, a record that binds the share-secret relationship. The subsequent steps of transaction inclusion, post-finality share release, key reconstruction, decryption and execution are similar to those in the TDH2 scheme. 

The TDH2 protocol is more efficient due to a fixed committee and constant-size threshold-encryption data. PVSS, by contrast, gives users more flexibility, since they can select the committee members responsible for their transaction. However, this comes at the cost of larger public-key ciphertexts and higher computational overhead due to per-trustee encryption. In the greater scheme of things, the prototype implementation of the F3B protocol on simulated proof-of-stake Ethereum showed that it has minimal performance overhead. With a committee of 128 trustees, the delay incurred after finality is only 197 ms for TDH2 and 205 ms for PVSS, which is equivalent to 0.026% and 0.027% of Ethereum’s 768-second finality time. Storage overhead is just 80 bytes per transaction for TDH2, while PVSS’s overhead grows linearly with the number of trustees due to per-member shares, proofs and commitments. These results confirm that F3B could deliver its privacy guarantees with negligible impact on Ethereum’s performance and capacity.

Incentives and punishments in the Flash Freezing Flash Boys protocol

F3B incentivizes honest behavior among Secret Management Committee trustees through a staking mechanism with locked collateral. Fees motivate trustees to stay online and maintain the level of performance the protocol requires. A slashing smart contract ensures that if anyone submits proof of a violation, which demonstrates that decryption was performed prematurely, the offending trustee’s stake is forfeited. In TDH2, such proof consists of a trustee’s decryption share that can be publicly verified against the transaction ciphertext. Meanwhile, in PVSS, the proofs consist of a decrypted share together with a trustee-specific NIZK proof that authenticates it. This mechanism penalizes provable premature disclosure of decryption shares, increasing the cost of detectable misbehavior. However, it does not prevent trustees from colluding privately off-chain to reconstruct and decrypt transaction data without publishing any shares. As a result, the protocol still relies on the assumption that majority of committee members behave honestly. 

Because encrypted transactions cannot be executed immediately, another attack vector is for a malicious user to flood the blockchain with non-executable transactions to slow down confirmation times. This is a potential attack surface common to all encrypted mempool schemes. F3B requires that users make a storage deposit for every encrypted transaction, which makes spamming costly. The system deducts the deposit upfront and refunds only part of it when the transaction executes successfully.

Challenges to deploying F3B on Ethereum

Flash Freezing Flash Boys offers a comprehensive cryptographic approach to mitigating MEV, but it is unlikely to see real-world deployment on Ethereum due to the complexity of integration. Although F3B leaves the consensus mechanism untouched and preserves full compatibility with existing smart contracts, it requires modifications to the execution layer to support encrypted transactions and delayed execution. This would require a far broader hard fork than any other update introduced since The Merge.

Nevertheless, F3B represents a valuable research milestone that extends beyond Ethereum. Its trust-minimized mechanism for sharing private transaction data can be applied to both emerging blockchain networks and decentralized applications that require delayed execution. F3B-style protocols can be useful even on sub-second blockchains where lower block times already significantly reduce MEV, to fully eliminate mempool-based front-running. As an example application, F3B could also be used in a sealed-bid auction smart contract, where bidders submit encrypted bids that remain hidden until the bidding phase ends. Thus, bids can be revealed and executed only after the auction deadline, which prevents bid manipulation, front-running or early information leakage.