To learn what Rolling Shutter is, see our announcement blog post.
What is MEV?
MEV stands for "Miner Extractable Value" or "Maximal Extractable Value." It describes revenue that block producers can extract by selecting, injecting, ordering, and censoring transactions. Often, the MEV is not captured by the block producers themselves but rather by independent entities using sophisticated bots.
What practical problems for end-users are you trying to solve?
We are trying to prevent sensible user transactions from front-running or sandwich attacks. An example would be a user trying to swap tokens on a decentralized exchange getting front-run by a malicious transaction that will negatively impact the user transaction's price. We are also making transactions less likely to be censored.
What type of MEV is Rolling Shutter protecting against?
We aim to protect against all types of MEV that rely on knowledge of the transaction data. Currently, this means selective front-running and sandwich attacks and most censorship attacks. Depending on the exact implementation details, some information such as transaction origin could be leaked and still used to delay transactions. However, censorship of a transaction would be noticeable and detrimental to the reputation of the rollup.
Who is Rolling Shutter for?
We hope that ultimately, all users of DEX's/DEFI benefit from Rolling Shutter. However, this is dependent on rollup projects implementing Shutter or new rollups being built with it from the start.
How are users protected against MEV? (very general answer)
Shutter allows users to send encrypted transactions to protect them from front runners on their path through the dark forest (the metaphorical hunting ground of front runners that each transaction must cross). For example, a trader could use Shutter to make their order opaque to front runners, which means attackers can neither determine if it is a buy or a sell order nor which tokens are being exchanged or at which price. The system will only decrypt and execute a transaction after leaving the dark forest and being included in a block.
The keys for encryption and decryption are provided by a group of particular nodes called keypers. Keypers regularly produce encryption keys by running a distributed key generation (DKG) protocol. Later, they publish the corresponding decryption key. The protocol uses threshold cryptography, enabling a group of key holders to provide a cryptographic lock that can only be opened if at least a certain number of members collaborate. The protocol functions appropriately as long as a certain number of keypers (the "threshold") is well-behaved. This ensures that neither a single party nor a colluding minority of keypers can decrypt anything early or sabotage the protocol to stop it from executing transactions.
Why implement Shutter into a rollup? (And not in L1 or somewhere else)
Shutter was implemented first as a smart contract system on top of L1 to protect smart contracts from MEV. Still, it required a gate in front of the smart contracts and was breaking composability. Shutter needs to be integrated with the core protocol to restore composability requiring fewer changes for optimistic rollups with a simple consensus protocol than for Ethereum 2.0, for example. After Rolling Shutter proves to be successful, it could be integrated at the L1 level. See our proposal for this here: https://ethresear.ch/t/shutterized-beacon-chain/12249.
What is the difference between Rolling Shutter and Flashbots?
Rolling Shutter's goal is to minimize MEV. At the same time, it seems Flashbots' purpose is to democratize the access to MEV via auctions, i.e., to give access to MEV not only to a set of privileged users but to every user. We believe that democratizing access alone is not a sufficient solution to MEV for end-users. Still, Flashbots could be used in conjunction with Shutter for the potential remaining MEV that Shutter did not eliminate.
What are the up- and downsides of a Shutter protected rollup versus a non-Shutter protected rollup?
The goal of Shutter is not to have any apparent downsides for its user. The upside is MEV protection; users' transactions cannot be front-run, sandwiched, or censored based on their data. However, the way transactions are sent by the user changes, as they have to be encrypted first.
What is the role of the collator?
The collator is responsible for collecting encrypted transactions from the user and determining the order and execution context of the transactions (block number, timestamp, etc.). Once a batch of encrypted transactions is ready, it commits to it with a signature that it sends to the keypers, signalling that it cannot change the order or execution context of these transactions (i.e., it cannot extract MEV.)
What is the role of the keypers?
The keypers are responsible for generating the eon public key, from which the users derive the encryption key of transactions. They are also responsible for generating the decryption key necessary to decrypt the user's transactions for each batch once the batch is committed to by the collator.
How many keypers and collators are there?
There is only one collator in the Rolling Shutter design. Still, there could be a design where the entity of the collator changes, e.g., similar to the selection of block producer in a PoS protocol.
On the other hand, there should be multiple keypers, in order of fifty to a hundred. Ideally, two-thirds of the keyper set needs to participate in the protocol to generate the decryption key for each batch.
What happens if the collator turns offline?
In Rolling Shutter, the collator is expected to be the same entity as the rollup sequencer. As such, it is unexpected to turn offline regularly. However, if it did turn offline, the rollup would fall back to the default behaviour of an unprotected MEV exploitable rollup.
What happens if the collator is malicious?
The only way the collator could misbehave is by committing to a particular order of transactions and including a different order in a block after the keypers have released the decryption key. This would mean two signatures on different sets of transactions for the same block have been created by the collator, which can be cryptographically proven and result in slashing.
What happens if keypers turn offline?
The set of keypers is decided upon by a DAO that should then be responsible for removing offline keypers to resume MEV protection. If more than a third of keypers is offline, the remaining keypers will generate no decryption key for the user's to encrypt transactions. The rollup will have to fall back to its default behaviour of unprotected rollup.
What happens if keypers collude to extract MEV?
For the keypers to extract MEV, they would have to release their decryption key sharing too early, which should be noticeable by honest protocol participants. Additionally, we hope that the community will develop tools to analyze MEV on blockchains, making it apparent to end-users whether the protocol is failing or not. The set of keypers is decided upon by a DAO that should then be responsible for removing misbehaving keypers that attempted collusion.
Who is behind Shutter?
Shutter incubated at brainbot, a software development company deeply rooted in the Ethereum ecosystem.
We're hoping that Shutter develops into a fully decentralized entity that gathers and aligns those interested in mitigating malicious MEV and other market inefficiencies in the foreseeable future.
What is the role of the DAO?
The DAO will be responsible for selecting the keyper sets. It cannot be proven cryptographically whether a keyper is online and participating in the protocol or offline. It also cannot be easily proven whether it released its decryption key share too early in the protocol. Thus, we rely on social cooperation in the form of a DAO to ensure misbehaving participants are kicked out.
The DAO will also be responsible for collecting fees paid by the users for the MEV protection to incentivize keypers to participate honestly in the protocol.
How can I find out more?
Join the telegram: https://t.me/joinchat/Lot-njex3Pc1YzJi
Subscribe to the blog: https://blog.shutter.network/