Applied MEV protection via Shutter’s threshold encryption

Understanding MEV and its impact on blockchain users

Transparency is one of the foundational features of blockchains, but it enabled value extraction by controlling the order and inclusion of transactions within a block, known as MEV, or maximal extractable value.

This problem is common on most blockchains and is rooted in the public nature of mempools, a ledger that stores pending transactions data. This information allowed block producers and other actors to benefit from frontrunning transactions. 

MEV is especially notorious on Ethereum, where it continues to be extracted at a rate equivalent to 11% of block rewards. Data shows that nearly $300,000 was lost in sandwich attacks in September. This reveals that MEV is a recurring hidden fee, not a minor inefficiency, hitting large trades hardest in volatile markets.

Shutter’s threshold encryption as solution to MEV

Among a range of MEV mitigation measures, several cryptographic solutions have been proposed, including threshold encryption and homomorphic encryption. These techniques encrypt transaction contents before they enter the mempool and keep them concealed until the ordering of transactions is finalized. This keeps block producers from extracting MEV by manipulating the sequencing of transactions. However, most encrypted mempool architectures are at the research stage.

Shutter was the first threshold-encryption protocol designed specifically to tackle MEV. Today, it stands out as the only threshold-based approach with an actual deployment, live on the Gnosis Chain mainnet.

Threshold encryption is a cryptographic technique that splits the decryption key across a committee of keyholders so no single party can decipher a transaction on its own. In most threshold encrypted mempools, the committee first runs a Distributed Key Generation (DKG) process to produce a public key as well as private key shares for each member. Users can then encrypt their transactions with this public key and submit the ciphertexts to the network. 

Block proposers order these ciphertexts into a block, and once the block is finalized or a reveal condition is met, each committee member publishes a decryption share. The required number of valid shares from the committee is then combined to recover the plaintext transaction. As in a multisig setup, a qualified majority of committee participants is sufficient for this. After transactions are sequenced and decrypted, they are executed by the network’s virtual machine.

The threshold committee acts as an offchain service that operates alongside the blockchain. This design makes it consensus-agnostic, meaning that it can be used on most blockchains with no need to change consensus rules. Still, it is important to keep in mind that unlike the validator set, the  committee is usually a strictly permissioned structure that needs to be trusted. In Shutter, committee members, so-called Keypers, are selected by the protocol’s governance. 

The initial Shutter design used per-epoch encryption, where users encrypt transactions under the current epoch of the underlying chain. This was intended to improve efficiency and reduce latency by amortizing computationally intensive decryption across many transactions. However, this design created a critical flaw. When the epoch key was reconstructed, all transactions from this epoch became public, even those not yet included in blocks. This could expose some network users to MEV. 

This issue was fixed in the actual deployment on Gnosis Chain, where Shutter employed per-transaction encryption. The Shutterized Beacon Chain on the Gnosis Chain currently operates as an alternative RPC endpoint, which encrypts transactions and broadcasts ciphertexts to the sequencing contract. Following the regular threshold encryption flow, once the transactions are included in a block and validated, they are decrypted and executed. 

Per-transaction encryption trades efficiency for simplicity, since the committee’s workload grows linearly with transaction throughput rather than remaining roughly constant as in a per-epoch design. Further developments of mempool threshold encryption could improve on this trade-off. 

The Shutter team anticipates that batched threshold encryption (BTE) is a potential way to address the drawbacks of both per-epoch and per-transaction schemes. BTE holds the committee’s load near constant while preserving privacy for transactions that are not included in a block.

Besides the Shutterized Gnosis Chain, Shutter’s team is working on the encrypted mempool module for the OP Stack, which is live on an Optimism testnet. This module supports per-epoch encryption and eliminates the issue of initial Shutter design, since the transactions are tied to a specific block. A transaction carries the target block information, and the contract checks the current block during execution, so it only succeeds if it lands in that block. If it misses the target block, the check fails and the transaction reverts, after which it can be resubmitted for a new block.

Despite its promise for MEV mitigation, Shutter is not fully trustless today, since users rely on a permissioned keyper set. Another constraint is the high latency in the current deployment on Gnosis, which means that Shutter, in its current form, has limited potential. While Gnosis blocks are produced every five seconds, Shutter transactions currently average about three minutes to inclusion, caused by the limited number of Shutterized validators and Keypers. Shutter’s team is planning a practical path and an out-of-protocol roadmap toward a fully encrypted and more trust-minimized mempool on Ethereum. This step, however, will require phased work across wallets, RPCs, relays, builders and validator incentives, followed by in-protocol support, after which the same modules can extend to other EVM chains.

This article does not contain investment advice or recommendations. Every investment and trading move involves risk, and readers should conduct their own research when making a decision.

This article is for general information purposes and is not intended to be and should not be taken as legal or investment advice. The views, thoughts, and opinions expressed here are the author’s alone and do not necessarily reflect or represent the views and opinions of Cointelegraph.

Cointelegraph does not endorse the content of this article nor any product mentioned herein. Readers should do their own research before taking any action related to any product or company mentioned and carry full responsibility for their decisions.