# Shutter on L1

This issue is a result of a brainstorm between me and @konradkonrad, further refined with Jakub.

The issue describes a concept how Shutter could be integrated into the current transaction supply chain on Ethereum. In contrast to [shutterized beacon chain](LINK), the issue describes an off-chain integration. The concept is derived from the current Gnosis Chain integration specs and adjusted to L1’s transaction supply chain.
After describing the architecture, economics, limitations and chances are discussed.

I think the technical details are not that new, so a lot of things will be known. This is merely an attempt how to integrate into L1’s transaction supply chain and to make it viable for the actors (validators, relay, block builders) to include shutterized transactions.

## Architecture

Note, that we are not discussing changes to modify the STF of Ethereum’s protocol and thus forcing the validator to include shutterized transactions. Once realizing that it is not mandatory to include shutterized transactions into a block, and given the fact that ETH L1’s transaction supply chain is an efficient free market, the introduction of a financial incentive to include shutterized transactions into a Block is necessary.

### Shutter-Geth
This concept is derived from [MEV-Geth](LINK), afaik the first ever product by flashbots. Back in the PoW days, they released a fork of Geth, which allowed MEV searchers to open a private channel to a miner, providing him with private transactions, and an incentive to include it at the top of the block. In a matter of weeks, 60-80% of all miners switched to the forked MEV-Geth. The reason for it is simple: It was an additional source of income.

If I’m not mistaken, this idea is quite similar to what we are working on with the Nethermind team for Gnosis Chain.

Shutter-Geth follows the same example: Allow users to encrypt their transactions and send it to all validators which run Shutter-Geth.

Once the validator is assigned to the next slot, it would get the decryption keys and include the transactions at the top of the block. That is definitely something we could build now (or rather are already kind of building for Gnosis chain).

To make sure that the validator is actually including the decrypted transactions, it is later described in Economics.

### Encryption point

...
## Economics

### MEV on shutterized transactions
As mentioned above, validators are incentivized by getting bribed to include pre-built transactions/blocks. This is exactly what we need to do for shutterized transactions as well. Shutterized transactions are simply a new extra way of income on top of including normal transactions. In order to get validators on board, they effectively need to have a financial incentive to do so. Sometimes malicious MEV might be more profitable, sometimes not. And that’s why the fee (which we believe, users will pay) should partly also go to validators to include these transactions.

### Commitment
Since Shutter is not integrated on a protocol level, transactions need to be decrypted, and only then being included into the block. Only after that the block is signed and the validator is fully committed. This is obviously a bad situation as the validator would decrypt the transactions and only then decide to include them into a block or not. And since it is not enforced on a protocol Level there is not economic mechanism to slash unintended behavior by the validators.

#### Additional commitments for block creation
This problem is not new to research and the transaction supply chain in general. For example, validators are signing a block header, but still could also sign another one. So there are some commitments being made before releasing the block but the validator could still choose to engage in equivocation. To be fair, this would be penalized by the protocol itself. So it’s not exactly our use case.

In the discussion of based rollups, validators do take on additional duties and commitments when it comes to building a block. They become sequencers of based rollups and receive the L2 transactions. Since one of the desired UX elements are fast pre-confirmations and this is what users enjoy today very much, this experience would be lost as block production time on L1 is 12 seconds.
I saw some discussions, that validators could simply pre-confirm (aka commit) to include the L2 transactions in a certain order. If they are not going to follow their commitment, they could be subject to be slashed on a non-protocol level (aka Eigenlayer - or something else).

If we think about it, that is a quite similar scheme of what we want to have. There is an additional pool of transactions (For based rollups -> L2 transactions, for Shutter -> encrypted transactions) and whichever validator runs this modified software, they would be committing to include certain things in their next block. Since we know in advance who is the next block proposer, we could directly communicate with that validator. Whenever he commits to additional conditions how he is going to build the block, he could be slashed retroactively on contract level, if he did not follow his commitments.

In exchange for that, he gets an additional fee (I would call it benign MEV) to actually follow his commitment.

Obviously, only after the commitment was signed by the validator, the keypers should release the decryption key.

### Value distribution
As a summary (there are some assumptions)

User (or wallet or dapp respectively) can calculate the potential MEV
There is a fee market for including shutterized transactions

If potential MEV > DAO Fee + Keypers Fee + Inclusion Fee

Then it makes sense to use shutter.

I assume that the inclusion fee would also vary as it competes with general MEV. But I would also be happy if the validator could use empty block space next to the current supply chain to include shutterized transactions.

## Limitations
This scheme is not fully trustless. It depends a lot on the configured parameters regarding rewards and slashing. But I would argue that this is the case today already. It might make sense for a validator to double sign two blocks and accept the slashing if the potential gain is higher.

In contrast to pre-confirmations for based rollups, in the shutterized scheme we introduce a third party (namely the keyper set). It is not addressed what happens if the keyper set is not releasing the key (Misbehavior). It is assumed if the validator doesn’t include shutterized transactions into the block, it is his fault. To mitigate slashing, we could change the slashing conditions in a way that even if the validator committed but missed the slot it’s not slashable. So whenever there would be misbehavior or a liveness failure by the keypers, there is a last resort for the validator to just miss the block (instead of not including shutterized transactions). This is not nice, but it is similar to the relay misbehaving in today’s transaction supply chain (The validator could sign a block header, but the relay is not releasing the full block. If the validator signs another block -> equivocation , instead the validator would simply miss the block and the rewards). So I would argue that this kind of trust assumption already exists today and is even improved with a decentralized keyper set.

## PBS

I don’t know exactly how the transaction supply chain (TSC) works nowadays in detail. Let's try to come up with a rough overview:

### Transaction Supply Chain (TSC)

Actors:

Wallets
Searchers
Builders
Relay
Validator/Proposer

MEV searchers — create small MEV chunks —> to block builders
Block builder —> assemble block -> Send Block to relay / market place
Validator —> signs most profitable header —> sends it to relay
Relay matches the deal and publishes the full block

I also read, that builders have private transactions flows and are trusted entities who reveal only a parts of the transaction information to searchers to allow for benign MEV such as backrunning.

### Shutter Integration
When pursuing vanilla Shutter-Geth, we would enter into competition to the current TSC. However, it would be the option with less work needed and less dependencies of other actors.
I think it would not be financially viable to switch from MEV-Boost to Shutter-Geth, especially in the beginning and it would be quite a difficult bootstrapping problem to solve.
However, it would be a very good first step entering into the transaction supply chain. We would need some validators in good faith who run our software and prove that the integration of Shutter on the edges of the protocol works.

## Further comments
I’m pretty sure I have missed something, and that there are a lot of parts which are not really new. But I really do think that it’s worth to finalize this concept and aim for it. To me it seems that this is technically not unachievable at all (actually it’s quite the opposite). And we are not making to many compromises compared to today’s current transaction supply chain.

It has a lot of potential upsides:

* MEV on L1 is by far the biggest
* we don’t have dependencies to build a first prototype
* Economic security via Eigenlayer for additional block building commitments (strong narrative)
* the same mechanisms are discussed or implemented in other fields (MEV-Geth, based rollups)

I do believe that we need to get the right people on board with the idea, so we need to talk to

* block builders
* Relays
* Validators

We need to understand where shutterized transactions are best to be fed into the supply chain. I mainly described the straight forward way to get the validator to commit and include, but it may make sense to actually let the block builders commit and include (or even to let them align on it).