Rolling Shutter: MEV protection built into Layer 2
We’re announcing Rolling Shutter to bring MEV protection to rollups on Ethereum. It builds upon our previous efforts of using threshold encryption to combat front-running and malicious MEV. However, it implements the DKG scheme directly into L2/rollup sequencer mechanisms in order to protect all dapps deployed on the rollup by default. This also increases censorship resistance and potentially latency properties of rollups.
Managing Layer 2 MEV is key to the future of rollups
MEV also exists in L2 and is an underexplored yet highly significant topic and potential issue for anyone interested in scalable DeFi/DAO/NFT applications.
It’s imperative for L2 teams to work on this, and many of them do so already. To quote John Wang from Immutable/Saber:
[...]the rollups with the best MEV mitigation mechanisms will have an edge.
As a potential revenue stream, MEV in rollups will also be deeply linked to and needs to be considered in L2 tokenomics designs.
Refresher on MEV
By now, you know what maximal extractable value (MEV) is. As a refresher: MEV is revenue that block producers can extract by selecting, injecting, ordering, and censoring transactions, and the subset of MEV we can measure is in the hundreds of millions of dollars per year on Ethereum Layer 1 alone.
Not all MEV is inherently bad; a portion of it aids in ensuring a more equal/accurate asset pricing in the form of arbitrage, e.g., between DEXs.
But we also know that a significant share of MEV, especially front-running (e.g., sandwich, sniping attacks), is malicious. This portion, combined with the suboptimal way in which MEV is extracted today, leads to significant value loss and painful UX for ordinary buyers, sellers, and users of crypto. It most likely also deters potential users from entering markets and thus hinders mainstream adoption of crypto in a big way.
Layer 2 MEV
We strongly believe that the place where the most crypto activity will happen in the future is on L2, so this is where we should focus our efforts to deal with the problem.
Rollups and L2, in general, are the future of Ethereum. As it currently stands, the rollup-centric Ethereum 2.0 roadmap proposed by Vitalik seems to be our best hope to scale Ethereum with increasing demand while maintaining the decentralization, trustless-ness, and general security properties that cement Ethereum as the de facto best place for DeFi, NFTs, DAOs, and all crypto applications.
Rollups are also a great way to implement new features because they represent a sandboxed way to experiment and demonstrate the viability of specific mechanisms to Ethereum or other L1s.
Currently, L2 MEV is somewhat hidden because users implicitly put immense trust in the rollup sequencers, which are mostly centralized. However,
MEV in rollups is poised to be an even more significant issue than on L1 due to the more centralized nature and level of sophistication of sequencer operators.
To make things worse, Vitalik expects the incentives to operate multiple rollups will likely lead to even more centralized operator setups.
Threshold encryption to combat malicious MEV in L2
This is where Rolling Shutter enters the stage. It builds upon our previous efforts of using threshold encryption to combat front-running and malicious MEV but implements the DKG scheme directly into the rollup sequencer mechanism.
The result is that all dapps and DeFi protocols deployed on the given rollup are protected from malicious MEV by default and - crucially - remain fully composable within that rollup.
As an added benefit, having the block producer sign encrypted orders will also increase censorship resistance, reducing the downsides of more centralized rollup operator setups even further.
Rolling Shutter explained (technical)
Let’s explain how Shutter’s threshold encryption DKG mechanism can be applied to rollups:
Generally, transactions are encrypted, batched, and signed while still encrypted, without the collator (in this case, a node expected to be operated by the rollup’s sequencer) knowing the content of the transactions. This ensures no one can censor or front-run transactions.
For the encryption/decryption part, a set of nodes called “keypers” generate a shared asymmetric key pair for each epoch (e.g., 5 seconds). Users encrypt their transactions with the public key and send them to the collator.
Since the collator does not know the content of the transactions, the collator can not (effectively) front-run those transactions.
For each epoch, the collator selects the encrypted transactions to include, orders them, and creates a corresponding batch. They commit to the batch with a signature and publish it.
The commitment finalizes the order and the selection of transactions and prevents the collator from changing it after the decryption key is released. In case they sign two conflicting commitments, they will be slashed and removed from their position.
Once the keypers see the signed batch commitment, they reveal their decryption key shares for the corresponding epoch. This allows anyone to compute the decryption key and decrypt the batch proposed by the collator.
The encrypted batch plus the decryption key are passed to the sequencer, who applies them to the rollup. The state transition function of the rollup takes care of checking the batch signature, decrypting the batch, and executing it.
This is how the above setup guarantees malicious MEV protection on the rollup.
Due to the fact that the ordering of transactions is determined and committed while they are encrypted, the collator cannot change their order based on the data. If the collator re-orders them after they are decrypted, they will produce two different commitments for the same set of the epoch, which can be used to slash it. This would guarantee malicious MEV protection on the rollup.
Bonus: “Shutterized” rollups have the potential to decrease latency
There’s one more potential benefit for rollups using Shutter: In order to achieve censorship resistance, “non-Shutterized” rollups will have to decentralize the sequencer, which will increase latency. “Shutterized” rollups might be able to utilize a centralized one, which might improve latency (or not decrease latency from the status quo) of mostly centralized rollup sequencers.
Summary/outlook
We are bringing MEV and front-running protection to L2s where it’s utterly needed.
We’re pretty far into the development of Rolling Shutter already and are currently evaluating partnership options with rollup developer teams. If you are such a developer, or if you’re a dapp developer on a rollup who cares about MEV, do not hesitate to contact us (or the rollup you’re building on)!
Also, reach out to us if you have other ideas on how to leverage Shutter MEV protection (e.g., in sidechains, L1, or at the application layer on-chain)!
Also, stay tuned for our next blog post on this, in which we’re aiming to explain the problem of L2 MEV in a more in-depth fashion. Shortly after this, you can expect a beta release of a Shutter-enabled rollup!
To close: we strongly believe (and were reassured) that MEV protection mechanisms such as Rolling Shutter will be a necessary and integral component of future L2 systems if they set out for serious adoption.
To learn more, see our Rolling Shutter FAQ.
Shutter Network
