Shutter - In-Depth Explanation of How We Prevent Front Running

Some of you have already tried the example application of the Shutter. If you missed the announcement about the alpha release, check out our previous blog post.

In this article, we are providing an in-depth explanation of On-chain Shutter, Shutter’s first instantiation on Ethereum that is ready to be integrated by a dapp. We will explain why and how we are building the technology, give a detailed description of the architecture and the transaction flow as well as economics. After reading this blog post, you will be aware of the technology’s pros and cons and will hopefully understand why to include Shutter in your research project or a product roadmap.

Motivation

MEV and front running are recognized to be among the final unsolved fundamental issues in the blockchain space. Ethereum is vulnerable mainly because of the miner’s ability to arbitrarily reorder transactions in the blocks they produce. On-chain Shutter aims to combat front running for the contracts that opt-in.

With Shutter, we are circumventing this issue by securely encrypting and decrypting transactions using threshold cryptography. We also think that the technology should be decentralized and efficient, and it shouldn’t require integration in the base layer. Our goal is to provide a working decentralized solution that fulfills these requirements.

Architecture of Shutter

At the heart of the Shutter architecture, a decentralized autonomous organization (DAO) manages the system. Its main task is to hire a set of special nodes called Keypers. The Keypers generate cryptographic keys with which users encrypt their transactions. Various smart contracts coordinate the key generation process and the transaction execution pipeline.

The full list of parties and components you can find in the diagram below.

There are also two major components - the main chain and the mint chain. The main chain includes the batcher contract, target contract, deposit contract, Keyper slasher contract and key broadcast contract.

Shuttermint is an application-specific, private, Tendermint-based blockchain on which Keypers communicate with each other. In particular, the key generation process is carried out here. The Keypers themselves function as validators of this chain.

Keypers and Key Generation

Keys are generated by Keypers who are appointed by the DAO. The majority of Keypers are trusted to act honestly according to the protocol, while a minority can be malicious or offline. The Keypers use the Shuttermint chain as a communication channel. In essence, the Shuttermint chain is needed to achieve consensus over which Keypers are considered online and thus should be included in the key generation process (otherwise, peer-to-peer communication would suffice).

The goal of the key generation process is to repeatedly output epoch key pairs consisting first of an encryption key and second, shortly after, the corresponding decryption key. However, Distributed Key Generation (DKG) protocols are notoriously inefficient with many participants, so running one for each epoch is not viable.

Therefore, Shutter uses a two-step process: first, a conventional DKG process is carried out, generating the so-called eon key pair. The public key is broadcasted while the secret key remains unknown forever – each Keyper only has a share of it. The eon key generation step will take a relatively long time, but this is acceptable as it only runs very infrequently (whenever the Keyper set changes).

Transactions are not encrypted and decrypted with the eon keys directly, but with so-called epoch keys. From a single eon key, an unlimited number of epoch keys can be derived. This derivation is extremely efficient.

To derive the epoch public key, only the eon public key and a unique epoch identifier are needed. Thus, each user can compute it locally to encrypt their transaction. On the other hand, the epoch secret key is a composite of shares that at least a threshold of Keypers has to contribute. Each epoch secret key share is computed from the epoch identifier and the eon secret key share is only known by the individual Keypers. In total, only a single message per Keyper and epoch has to be published.

The Shutter key generation protocol is very efficient as Keypers don’t need to do anything to get a public epoch key. To get a secret epoch key, they just need to publish one message on the shutter mainchain. Then a decrypted transaction is sent.

Transaction Flow

To make it as easy as possible for users to get ahold of the eon public key, Keypers broadcast it via the KeyBroadcastContract on the main chain. The arising gas costs can be neglected as the eon key changes only very infrequently. Users verify that the key is correct by checking that at least a threshold of Keypers submitted the same key. Once it’s done, the users choose the batch number (happens automatically) and derive an epoch public key to encrypt their transactions. To do that they need to know the epoch index of the batch.

The batcher contract just stores the transactions and when the batch is complete, the Keypers decrypt them off-chain and then send them to the executor contract.

The executor contract performs some sanity checks to ensure that no previous batch was skipped and that the Keypers provided the correct transaction set, etc. In the ideal setup, the executor contract should do the key derivation and decryption. But currently, this is not possible as the EVM is not efficient enough. So instead we use the trust assumption that we already rely on and extend the functionality of the Keypers – they generate the keys as well as decrypt transactions.

In the current setup, we use an optimistic verification mechanism and threshold signature. It means that the Keypers sign decrypted transactions, then the signatures are combined into one, and finally, it gets verified and executed by the executor contract. By default, we trust that any decrypted transaction set given is correct.

In case a Keyper cheats and submits a set of transactions without having the required signatures, their colleagues can submit an accusation against them. If they cannot successfully appeal by providing the signatures by a certain deadline, they will get slashed. Future versions of the protocol will improve this process.

After all the checks are done, the executor contract sends the transactions one by one to the target contract (i.e. the contract the user wants to interact with). The target contract is the interface between Shutter and the application using it.

Economics

Shutter will be managed by a DAO which will be generating income by collecting fees in ETH from the users. The main task of the DAO is to manage the Keyper set — select trustworthy members, expel them if they are proved to be corrupt, and pay them for their efforts. The remaining profits can be retained by the DAO or invested in maintaining/improving/growing the project.

In the beginning, the DAO will have a lot of influence on the protocol: they will control the Keyper selection process, the fee schedule etc. This makes the system very flexible and simpler to design, but at the same time, it makes it prone to social attacks on the governance mechanism. Therefore, in order to lower the risk of governance attacks, we expect the DAO to automate more processes over time as the system matures, its practicalities are better understood, and flexibility becomes less important.

As we use an optimistic verification mechanism, to work with Shutter, Keypers need to make a deposit which they’ll get back once they quit their role. For that, we use a deposit contract.

Failure Scenarios

We believe it is important to understand what can go wrong when using Shutter, and how to avoid potential failure scenarios.

Probably the first failure that comes to mind can be caused by Keypers. If a majority of Keypers collude (more than the threshold), they can privately share the secret keys and decrypt transactions early, which means they could front run users. Everyone within the network would know they are lying, but the blockchain would not. This scenario cannot be fully prevented but it will not be substantially worse than the current status quo on the unprotected mainchain. Besides, the DAO can set incentives in a way that Keypers would be unlikely to collude.

Another failure scenario might be provoked by the DAO itself – it might be corrupt. If that happens, the dapps that use Shutter should be able to disable it in their network/app. But as the incentives of the DAO are exactly the opposite – it aims to contribute to the project and maximize fee value, we believe this scenario is unlikely in the real world.

Trade-offs

Innovative solutions often come with trade-offs and Shutter is not an exception. As you already know, a Shutterized transaction would be a bit more expensive due to the fees and the latency will be a bit higher due to the architecture, but in return, it would be fully protected from front running.

We also acknowledge that Shutter would add some complexity to the dapp using it. This issue might be solved once EVM becomes more efficient. However, that will most likely not happen in the nearest future. But if you are concerned about UX, it shouldn’t be affected if integrated correctly and end-users won’t experience any difficulties using dapps with Shutter.

From the security perspective, Shutter adds additional security assumptions. In particular, the majority of the Keyper set has to be trusted not to collude and by extension, the DAO has to be trusted to make reasonable decisions. Note, however, that if these assumptions are broken, while usability will be degraded, the security will essentially only fall back to the status quo.

Next Steps

In the next blog post, we will explain Shutter DAO in detail. We will tell you more about the current concept and how it will be brought to life.

On June 20, Shutter was a part of the exciting MEV panel discussion together with Flashbots and CowSwap. You can watch the video here.

Besides, Jannik gave a talk at #EthCC about how Shutter combats front running and malicious MEV, check it out.

Last but not least, we have launched a new Shutter website!  To stay up to date, check out our GitHub, follow us on X-Twitter and join the Discord server! You are welcome to share your feedback or reach out to us via DM on X.