Applied MEV protection via Shutter’s threshold encryption

Understanding MEV and its impact on blockchain users

Transparency is one of the basic features of blockchain, but it has enabled value extraction by controlling the order and inclusion of transactions within a block known as MEVs.

This issue is common in most blockchains and is rooted in the public nature of Mempools, a ledger that stores pending transaction data. This information allowed block producers and other parties to benefit from the final transaction.

MEV is particularly well known for Ethereum, and continues to be extracted at a rate equivalent to 11% of block rewards. Data shows that nearly $300,000 was lost in the September sandwich attack. This reveals that MEVs are not mild inefficiencies, but rather hidden fees that repeat and drive the biggest deals in unstable markets.

Shutter Threshold Encryption as a MEV Solution

Among the various MEV mitigation strategies, several encryption solutions have been proposed, including threshold encryption and homophone anomalies. These techniques encrypt the content of a transaction before entering a member and continue to hide it until the transaction ordering is finalized. This prevents block producers from extracting MEVs by manipulating the sequence of transactions. However, most encrypted Mempool architectures are in the research phase.

Shutter was the first threshold suppression protocol specifically designed to tackle MEV. Today, it stands out as the only threshold-based approach with real deployments, live on the mainnet of the GNOSIS chain.

Threshold encryption is an encryption technique that divides the decryption key across a committee of keychains, so a single party may not be able to decrypt a transaction on its own. In most threshold encrypted Mempools, the committee first runs a distributed key generation (DKG) process to create a public and private key for each member. The user can then encrypt the transaction with this public key and send ciphertexts to the network.

The block proposer orders these ciphertexts from the block, and each committee member publishes the decryption sharing once the block is confirmed or the obvious conditions are met. Next, combine the required number of valid stocks from the committee to recover plain text transactions. Like a multi-sig setup, a qualified majority of committee participants is sufficient for this. After transactions are sequenced and decrypted, they are performed by virtual machines in the network.

Applied MEV protection via Shutter’s threshold encryption

The Threshold Committee acts as an off-chain service that works with the blockchain. This design means that it does not require any changes to consensus rules and can be used on most blockchains, as it is consensus independent. Still, it is important to note that unlike validator sets, committees are usually strictly permitted structures that need to be trusted. In the shutter, the so-called Keepers, who are members of the committee, are selected by the governance of the protocol.

The first shutter design used per-epoch encryption. Here, the user encrypted the transaction under the current epoch of the underlying chain. This was intended to improve efficiency and reduce delays by amortizing computationally intensive decoding across many transactions. However, this design has produced serious flaws. When the epoch key was reconstructed, all transactions from this epoch were even exposed to those not yet included in the block. This could expose some network users to MEV.

This issue was fixed in actual deployments in GNOSIS chains where Shutter uses per-transport encryption. The shuttered beacon chain in the GNOSIS chain now acts as an alternative RPC endpoint that encrypts transactions and broadcasts Shifa text into sequence contracts. Following the normal threshold encryption process, when transactions are included and verified in a block, they are decrypted and executed.

Applied MEV protection via Shutter’s threshold encryption

As committee workloads are not nearly constant as per epoch designs, they grow linearly with transaction throughput, so per exchange encryption easily exchanges efficiency. Further developments in Mempool’s threshold encryption could potentially improve this trade-off.

The shutter team expects batching threshold encryption (BTE) to be a potential way to address the drawbacks of both per-epoch and per-transaction schemes. BTE maintains the committee’s load almost constant, while maintaining privacy for transactions not included in the block.

In addition to the shuttered Gnosis chain, Shutter’s team is working on the encrypted Mempool modules of the OP stack, which live in the optimistic testnet. This module supports per-epoch encryption, eliminating the problems with initial shutter design, as transactions are associated with a particular block. The transaction carries the target block information and the contract checks the current block during execution, so it only succeeds if it lands on that block. If you miss a target block, the check fails, the transaction returns, and you can then resubmit to a new block.

Despite its commitment to MEV mitigation, Shutter is not completely trusted today, as users rely on the permitted basic set. Another constraint is the high latency in the current deployment of GNOSIS. This means that the shutter has limited possibilities for the current format. Gnosis blocks are generated every 5 seconds, but shutter transactions are currently averaged about 3 minutes in the containment, due to a limited number of shuttered valtters and keepers. The Shotter team is planning a practical path and an out-of-protocol roadmap for a fully encrypted, more reliable and minimalized Mempool in Ethereum. However, this step requires step-by-step work through wallets, RPCs, relays, builders and validator incentives, and the same module can then be extended to other EVM chains.

This article does not include investment advice or recommendations. All investment and trading movements include risk and readers must do their own research when making decisions.

This article is for general informational purposes and is not intended to be considered legal or investment advice, and should not be done. The views, thoughts and opinions expressed here are the authors alone and do not necessarily reflect or express Cointregraph’s views and opinions.

Cointelegraph does not endorse the content of this article or the products mentioned here. Readers should conduct their own research before taking any actions relating to the mentioned products or companies, and before taking full responsibility for their decisions.

Leave a Reply

Your email address will not be published. Required fields are marked *