An article to understand the new concept of technology Shutterized Beacon Chain

Author: Cducrest

Source: ethresear.ch

The Shutterized Beacon Chain allows transactions to be selectively encrypted and incorporated into the chain before their contents are visible to anyone. This will greatly increase censorship resistance and reduce malicious MEVs. This article will introduce this concept in detail.

Summary

• MEV is an important problem, but it can be solved directly in the L1 beacon chain
• Shutter offers a solution: a group of nodes uses the DKG protocol to compute an encryption key, let users encrypt their transactions with it, and release the decryption key on the encrypted transaction chain.
• By using the validator set to run the DKG protocol and introducing a scheduling mechanism for encrypted transactions, this technique can be applied to a beacon chain similar to Ethereum.

question

Miner Extractable Value (MEV) and front running are widely considered to be the last unsolved fundamental problems in the blockchain space. There are now hundreds of millions of dollars in MEV on record, most of which do more harm than good to users and traders. Over time, this problem will inevitably become more destructive, and eventually it may even become a fatal obstacle preventing our community from going mainstream.

The term MEV was coined by Phil Daian et al. to describe the benefits that block producers earn by selecting, inserting, ordering, and reviewing transactions. The value of MEV extracted in 2020 alone is more than 314 million US dollars, which is only a lower limit. Typically, MEV is not captured by the block producers themselves, but by independent entities using sophisticated bots.

An important subset of MEV is revenue from so-called front-running, an attack that is illegal in traditional markets but remains unregulated in the crypto space. Front-runners monitor the network for worthwhile transactions, and once they identify a target, they send their own transaction in an attempt to get it included in the chain early. They achieve front-running transactions by paying higher gas prices, operating network infrastructure spread across the world, becoming block producers themselves, or paying through reverse channels.

The most common victims of front-running attacks are traders on decentralized exchanges. Front-running forces them to pay higher prices instead of being fairly rewarded for the information they provide to the market. Front-runners, on the other hand, siphon profits from victims in an almost risk-free manner without making any useful contribution to the system. A simple example is arbitrage trading, earning the difference in the price of the same asset on two different exchanges. Front-running traders are often rewarded by copying these trades from other market participants and executing them earlier, while the original traders come away empty-handed.

Besides exchanges, many other applications are also affected, including bounty distribution and auctions. Importantly, since they rely on voting in the governance system (which represents a large and rapidly growing area in Ethereum), they are more vulnerable to front-running attacks. Without a system in place to protect against these types of attacks, significant challenges can arise.

In traditional finance, front-running can be curbed (to a certain extent) by the regulation or supervision of various trusted intermediaries and operators. This is not the case in a permissionless, decentralized system, so it could be a strategic barrier to mainstream cryptocurrency adoption.

Require

We believe that the Beacon Chain should provide MEV protection to its users without additional overhead or changes in user experience. This protection should also not come with additional security guarantees, or at least fall back to standard non-MEV protection features when additional security assumptions fail. In the end, it should have a similar level of decentralization as a consensus protocol.

Shutter

Shutter allows users to send encrypted transactions in a way that protects users from frontrunners on their way through the dark forest (every transaction has to go through a frontrunner’s hunting ground). For example, traders can use Shutter to make their order opaque to front-running traders, meaning that the attacker can neither be sure that it is a buy or sell order, nor which tokens are being exchanged, or at what price . The system will decrypt and execute the transaction only after the transaction leaves the dark forest, that is, after the execution environment of the transaction is determined.

Keys for encryption and decryption are provided by a set of special nodes called Keypers. Key holders typically generate encryption keys by running a distributed key generation (DKG) protocol. They then issue the corresponding decryption key. The protocol uses threshold cryptography — a technique that enables a group of keyholders to provide cryptographic locks that can only be opened when at least a certain number of members cooperate. This ensures that neither party nor a small number of colluding keyers can decrypt anything in advance or break the protocol to prevent it from executing transactions. As long as a certain number of Keyper ("threshold") does not break the rules, the protocol can run normally.

L1 Shutter within the core protocol

We have developed an on-chain shutter, a mechanism to protect individual smart contracts from L1 command attacks, but it has the disadvantage of breaking composability. We are further investigating deploying shutter directly inside rollup. Here we describe a design for integrating the shutter system as part of an Ethereum-style beacon chain. The advantage of this is that it is completely out of the user and remains composable.

As in every shutter system, this protocol requires a set of Keypers. Keyper groups select committees or block producers among blockchain validators through a similar process, except they are selected much less frequently (e.g. once a day). Keyper uses the beacon chain to generate shared eon keys. The eon public key will be provided to users to encrypt their transactions.

Block producers collect encrypted and plaintext transactions for blocks. They contain cleartext transactions to be executed in their blocks, while encrypted transactions are scheduled at future block heights.

After a block is produced, Keyper should generate a decryption key to decrypt the transactions planned for that block. Subsequent blocks must contain decryption keys to be considered valid. The post state of a block is computed by first executing the encrypted transactions scheduled for the block, followed by the plaintext transactions contained in the block.

Execution order and context (block number, timestamp, etc...) are determined by the order in which ciphertext transactions are included and the context of the previous block. Before the transaction is decrypted, the context of execution is determined, so it is impossible to use information about the transaction data to extract the MEV. It also prevents side-channel information that could be used to optimistically front-run trades.

Cryptographic transaction fee

Block producers need to somehow ensure that encrypted transactions are worth including in a block, i.e. they can pay transaction fees without knowing the transaction data. If the fee would be paid upon execution, the block producer would not be guaranteed to be paid, as the account could deplete its balance between inclusion and execution.

Thus, encrypted transactions justify their inclusion by providing a signed envelope that pays a fee when they are included in the chain. The envelope contents include: gas consumption, gas price, and a signature on these fields to recover the payer's address. This fee will be paid to the block producer when the ciphertext transaction is included, i.e. not when it is executed. The gas consumption of a ciphertext transaction is included in the gas limit of the block it is in.

Traditional gas caps need to be replaced by gas consumption, meaning that users will be charged for all the gas they plan to use, even if they only use a portion of it by the time the transaction is decrypted and applied. This is necessary for fees to be paid when transactions are included in the chain. This prevents block producers from decrypting a transaction with an incredibly high gas limit (replacing other transactions and their fees) into a transaction that uses very little gas (and fees).

Another disadvantage of using envelope transactions is that the metadata of the transaction will be leaked, i.e. the payer and the gas price/consumption cap are known. Chances are, a small fraction of MEVs can still be extracted using this leaked information.

It was pointed out that a zk-SNARK approach could be envisaged to solve this fee payment problem and prevent metadata information leakage.

ASD

The eon public key and decryption key generated by the key user require a threshold of t/n honest participants. The parameters t and n can be adjusted to suit the protocol. The higher t, the harder it is for keypers to collude and decrypt transactions prematurely (allowing MEV extraction). On the other hand, a lower t can guarantee that the decryption key can be released in time.

In order to enforce the decryption and application of ciphertext transactions, we must enforce the inclusion of the decryption key in every block. In these cases, if the Kepers go offline or refuse to generate decryption keys, block production will stop.

We can mitigate Keyper's activity by allowing blocks to be generated without the decryption key if there are no encrypted transactions scheduled to be executed. In case Keyper goes offline, the chain will recover by splitting blocks with encrypted transactions and only producing blocks with plaintext transactions.

We can also restore liveliness by stating that if no blocks are generated during n slots (since there is no decryption key), the next block need not contain the decryption key and decrypted transactions will be ignored. This would fall back to the traditional non-MEV protection functionality of the chain.

Deployed changes

We have developed the Keyper software, and all the encryption/decryption logic. We also developed logic that allows the Block Producer (or Orderer/Sequencer) to commit to a batch of encrypted transactions, signaling to Keyper that it is now safe to release the decryption key.

All that needs to be done now is to change the rules that define block correctness in client deployments, and the rules for transaction execution. The interface for submitting transactions to clients must be redefined. Finally, tools and plugins may need to be written to allow dapps to seamlessly integrate with MEV-protected chains that require public-key encrypted transactions.