Encrypt every transaction to combat malicious MEV

Malicious MEV attacks pose a major threat to traders on Ethereum. Our latest research shows that about 2,000 sandwich attacks happen every day and more than $2 million is taken from the network every month. Even large traders of WETH, WBTC or stable exchanges are at risk and may lose a portion of their trades.

MEV thrives on the transparent nature of blockchain, where transaction data is visible before transactions are made and completed. One way to simplify MEV is memory pool encryption, preferably using initial encryption. In our previous articles, we explored two different models for threshold-encoded membranes. One of the first projects to implement baseline encryption to protect the mempool, Shuter introduced the epoch-making configuration. Batched Threshold Encryption (BTE), a new model, decrypts multiple transactions with a single key to reduce communication costs and increase efficiency.

In this episode, Flash Freezing Flash Boys (F3B) by H. Zhang et al. (2022), a new proposed derivational encryption scheme that implements encryption on a per-transaction basis. We examine its mechanics, explain its effects on latency and memory, and discuss why it has not yet been put into practice.

Table of Contents

Toggle

Flash Freezing FlashBoys how to implement encryption per transaction

Flash Freezing FlashBoys addresses the limitations of early encryption systems that rely on pre-existing configurations. Projects like Fairblock and early versions of Shutter used a single key to encrypt each transaction in a selected era. An epoch is a fixed number of blocks, for example, 32 blocks on Ethereum. This created a vulnerability where some transactions not included in the defined block ends could still be decrypted with the rest of the group. This exposes sensitive information and opens up MEV opportunities for verifiers, thereby making them vulnerable to front-running.

F3B applies initial encryption to each transaction, ensuring that each transaction remains confidential until it reaches the final stage. The overall flow of the F3B protocol is shown in the figure below. The user encrypts the transaction with a key that can only be accessed by a limited committee known as the Secret Management Committee (SMC). 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 necessary decryption metadata for end-to-end reconstruction and execution. Meanwhile, the SMC prepares the decryption shares but withholds them until the consensus commits the transaction (step 2). Once the transaction is complete and SMC has released enough legal shares (step 3), the consensus team decrypts and implements the transaction (step 4).

Due to the heavy computational load for encryption and decryption, as well as the storage requirements of large encrypted payloads, transactional encryption has long been impractical. F3B solves this by encrypting only the 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 asymmetric encrypted up to ~10 times for a simple swap transaction.

Comparison of different implementations of F3B encryption and their duration

Flash Freezing Flash boys can be implemented with one of two encryption protocols, TDH2 or PVSS. The difference lies in who bears the burden of setup and how often the committee structure is adjusted, with corresponding advantages and disadvantages in terms of flexibility, delay, and storage.

TDH2 (Threshold Diffie-Hellman 2) is based on a distributed key generation (DKG) process to generate private key shares with a shared public key. A user then creates a new symmetric key, encrypts their transaction with it, and encrypts that symmetric key with the committee's public key. The consensus team writes this encrypted pair onto the chain. After the chain achieves the required number of verifications, the committee members publish a partial decryption of the encrypted symmetric key with NIZK (non-interactive zero knowledge) verifications, which are required to prevent selective cryptographic attacks, where attackers deceive trustees while providing ciphertexts while decrypting information. NIZKs guarantee that the user's ciphertext is well-encrypted and decipherable, and that trustees have provided valid decryption shares. The consensus verifies the assertions and, once a valid stake threshold is reached, reconstructs and decrypts the symmetric key, decrypts the transaction, and then executes it.

The second scheme, PVSS (Publicly Validated Secret Sharing), follows a different path. Instead of the committee running the DKG every generation, each member of the committee has a long-term private key and corresponding public key, which is stored on the blockchain and accessible to any user. For each transaction, users choose a random polynomial and use Shamir's secret sharing to generate secret shares, which are encrypted using their own public key for each selected trustee. The symmetric key is obtained by hacking the reconstructed secret. Each of the encrypted shares is accompanied by a NIZK proof, which allows anyone to prove that all shares are derived from the same secret, with a public polynomial commitment, a record linking the share secret relationship. Subsequent transaction inclusion, post-end share release, key reconstruction, decryption and execution are similar to those in the TDH2 scheme.

The TDH2 protocol is more efficient due to fixed committee and fixed size limit-encryption data. PVSS, on the other hand, gives users more flexibility as they can choose the committee members responsible for their transactions. However, this is at the expense of large public-key cryptographs and high computational cost due to each trustee's encryption. In the grand scheme of things, the F3B protocol has proven to have a low implementation cost in Ethereum based proof-of-stake implementation of the protocol. The delay created after the deadline by a committee of 128 trustees was only 197 ms for TDH2 and 205 ms for PVSS, which is equivalent to 0.026% and 0.027% of Ethereum's 768 second completion time. Storage overhead for TDH2 is only 80 bytes per transaction, while PVSS overhead grows linearly with the number of trustees due to member shares, confirmations and commitments. These results confirm that F3B can provide privacy guarantees with negligible impact on Ethereum performance and capacity.

Incentives and Penalties in the Flash Freezing FlashBoys Protocol

F3B promotes honest behavior through a locked case between the Trustees of the Confidential Management Committee. Payments motivate trustees to stay online and maintain the level of performance required by the protocol. A smart contract ensures that if anyone provides evidence of the breach, which shows that the decryption was done prematurely, the offending trustee's share is lost. In TDH2, such proof includes a publicly verifiable trustee decryption share with the transaction ciphertext. Meanwhile, in PVSS, the authentication consists of a decrypted share with a trustee-based NIZK authentication. This mechanism penalizes disclosure of previously decrypted shares, adding value to detectable bad behavior. However, it does not prevent trustees from privately collaborating off-chain to reconstruct and decrypt the transaction data without publishing any shares. As a result, the protocol still relies on the assumption that the majority of committee members are of honest character.

Because encrypted transactions cannot be executed immediately, another attack vector is for a malicious user to flood the blockchain with invalid transactions to delay confirmation times. This is a potential attack surface common to all cryptographic schemes. F3B requires users to store every encrypted transaction, making spam expensive. The system deducts the deposit in advance and pays the amount when the transaction is successfully completed.

Challenges to deploying F3B on Ethereum

Flash Freezing FlashBoys offers a comprehensive cryptographic approach to reducing MEV, but is unlikely to see real-world deployment on Ethereum due to integration complexity. Although F3B leaves its consensus mechanism intact and maintains full compatibility with existing smart contracts, it requires an implementation layer upgrade to support encrypted transactions and deferred execution. This requires a more extensive hard fork than any update since the merger.

Nevertheless, F3B represents an important research milestone that extends beyond Ethereum. The trusted minimal method for sharing private transaction data can be applied to both emerging blockchain networks and applications that require decentralized execution. F3B-style protocols may even be useful on sub-second blockchains. As an example implementation, F3B can also be used in a sealed auction smart contract, where bidders submit encrypted bids that remain hidden until the bidding process ends. Therefore, bids can be revealed and executed only after the end of the bid period, which prevents bid rigging, face-to-face or early information leakage.