Block Producer Extractable Value (BPEV) — called MEV on proof-of-work chains (Miner Extractable Value) — is a form of arbitrage present in most decentralized finance applications on blockchains. It is undesirable, because it imposes costs on users, to the benefit of block producers (examples below).

To help improve this situation we propose in Hangzhou a new Michelson smart contract instruction, based on a cryptographic primitive named Timelock (technical documentation). The solution we propose allows to temporarily hide the payload of a transaction sent to a smart contract for a period of time greater than the time it takes to include the transaction in a block.

In this way there is no leakage of information at the P2P level and no reordering of transactions can be applied in order to arbitrage the smart contract.

We argue that this tackles the issue of BPEV at its core.

In this post we explain BPEV and its relationship to the fees market.

We identify the core problem as a leakage of information between different layers of the architecture of modern blockchains. We argue that this problem is not inherent to blockchains and thus can be solved with the right cryptographic tool.

We explain the advantages of cryptographic commitments and why they are not enough to tackle our problem.

Finally we show how the Timelock primitive improves over commitments and we sketch how to use it to protect a smart contract from BPEV.

Block Producer Extractable Value (BPEV)

Block Producers and fees market

To understand BPEV it is useful to recall the role of block producers in a blockchain.

To enjoy the benefits of decentralization, blockchains have a permissionless design so as to attract a large number of block producers.¹

In Tezos for example anybody with a computer and the necessary stake can become one. Today the network is run by around 400 block producers. In order to motivate block producers to operate on the network they obtain an economic incentive for each block produced.

This incentive is usually composed of a fixed amount created from inflation (block reward) and, less importantly, the fees of all transactions included in the block.

Because each block can only include a finite amount of transactions, a fee market forms where users bid for inclusion of their transactions. The block producer naturally prioritizes transactions with a higher fee.

This system popularized by Bitcoin works well for simple transfers. However things get more complicated when transactions are intended for complicated smart contracts, and can for example affect the price of an asset when executed. A first hint of the problem is visible from the fact that the order in which transactions are included in a block is the prerogative of the block producer and is outside of the control of the transaction emitter.

What is BPEV?

A large class of smart contracts (typically ones related to DeFi) are sensitive to the ordering of transactions. By scanning the transactions on the network, arbitrageurs can exploit the fees market to manipulate smart contracts and produce undesirable arbitrages.

We can see a simple example in which a smart contract automatically computes the price of an asset based on supply and demand (e.g. an Automated Market Maker). A user wishing to buy this asset sends a transaction with a fee. An arbitrageur monitoring the P2P network then produces a transaction to buy the same asset but with a higher fee, so as to have priority in the next block. When the arbitrageur’s transaction is executed, the price of the asset is adjusted by the smart contract and the honest transaction buys the asset at a higher price from the arbitrageur, who then immediately sells the asset and makes a profit, a so-called “sandwich”.

This simple example can be reminiscent of front-running in a classic financial market, although a key difference is that front-running in financial market involves the malicious use of client’s information by fiduciaries while, in this scenario, no direct breach of trust is involved.²

The phenomenom is particularly relevant on blockchains since the effect of a block can be determined algorithmically, and the process can be easily automated and leads to more sophisticated arbitrages that are used in practice.

It is important to note that several actors can compete among themselves for priority in a block thus causing spikes in the fee prices and reducing their margin of gain.

In the end, block producers are extracting the most value from this practice because of the inherent power of their role.

The value in this attack is therefore called Miner Extractable Value (MEV) on Ethereum. Tezos faces a similar phenomenom, that we call Block Producer Extractable Value to extend the terminology to proof-of-stake networks (BPEV).

One concrete account of MEV (on the Ethereum network) is described in the article “Ethereum is a dark forest”. The author suffered a 12,000 USD loss on a transaction which was submitted and arbitraged away. See also

• Flashbots docs (permalink), and
• a detailed paper “Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges”.

which shows the extent of the problem.

The core of the problem

It is important to understand that this is an architectural problem. Blockchains are usually separated into three layers: a P2P (peer-to-peer) layer, a consensus layer, and a smart contracts layer. Let’s take an example to see the life of a transaction throughout the three layers in a typical blockchain. A user creates a transaction of the form (source, fees, payload). The source is the address of the user, the fees are meant for the block producer, and the payload is intended for a smart contract. The user then broadcasts the transaction in the clear on a gossip P2P network. The consensus layer validates the transaction and includes it in a block. In principle the validation could only ensure that the source has enough balance to pay the fees. Once the transaction is included in a block by the consensus layer, the recipient smart contract executes the payload.

Note however that the P2P and consensus layers have access to the payload even if it’s not necessary for their operation. This unnecessary leakage of information is the core cause of BPEV.

As we will explain in the rest of this blogpost our solution consists of hiding the payload from the P2P layer. Note that this is a non-trivial task as a smart contract cannot hold secret keys.

Users of the Tezos network might recall the integration of the Sapling protocol in the Edo amendment and wonder if it could solve the problem. Indeed in some cases Sapling can be used to alleviate BPEV, however it offers a very strong notion of privacy which in many cases is not required and which may limit the expressivity of the smart contract.

The solution we propose, called Timelock, allows to temporarily hide the payload of a smart contract for the time necessary to have it included in a block. The payload is then decrypted and the smart contract can operate as before.

Cryptography and fairness

Before explaining our solution based on Timelock, we digress to explain the concept of fairness through the children’s game rock-paper-scissor.

The commit-and-reveal technique

Consider the game of rock-paper-scissors. In this game, it is key that players reveal their moves simultaneously — or at least within a time interval less than a human reaction time. Unfortunately if we play the game on a blockchain, computers have ample time to react to broadcasted transactions on the P2P layer before they are included. This makes it impossible for our children to play a naïve version of rock-paper-scissors across a blockchain.

How to play rock-paper-scissors over a blockchain, using commitments

Using a commitment scheme, our children could still in principle play rock-paper-scissors on our blockchain. A commitment scheme is a well-known cryptographic primitive in which we commit to having made a decision, without immediately revealing what that decision is.

Formally, we require two properties:

• Hiding property: given a value I can commit to this value. However, my commitment gives no information about the value committed to.
• Binding property: If I reveal my value, this is guaranteed to be equal to the value that I committed to earlier.

We can now devise a protocol to play our game:

• Player 1 chooses a move \(M_1\in\{rock, paper, scissors\}\) and broadcasts a commitment \(C(M_1)\) of \(M_1\).
• Player 2 receives \(C_1\) and sends a move \(M_2\in\{rock,paper,scissors\}\) in the clear.
• Player 1 receives \(M_2\) and reveals \(M_1\).

The hiding property gives Player 1 confidence that Player 2 cannot use the value of \(M_1\) to choose \(M_2\), and the binding property gives Player 2 confidence that \(M_1\) was indeed the chosen move. Thanks to commitments, both players are protected, neither can gain an advantage, and the game is fair.

Commitments and BPEV

Commitments are a partial solution to BPEV.

Users can commit to transactions, and block producers can include these in the blockchain. However, block producers are kept honest in the sense that the hiding property means that they cannot interrogate the commitments for information with which to extract value for example by reordering or inserting transactions. The binding property means that commitments really do commit users to the transactions that they chose.

The overall P2P-Consensus-SmartContracts blockchain architecture, is untouched. Later — just as in the game above — users can reveal their actual transactions.

However, there is a catch: the binding property guarantees that a user cannot reveal a different transaction, but does not force the user to reveal. Users could spam the system with transactions and only reveal the ones that suit them.³

So commitments are a step in a good direction, but they do not fully solve the problem.

Timelock and BPEV

We propose a solution to alleviate this issue which is relatively easy to implement and is based on an old cryptographic technique called time-lock encryption (see Time-lock puzzles and timed-release Crypto for more details).

Time lock encryption allows to encrypt a message such that it can be decrypted in two ways: it can be decrypted rapidly using the author’s secret; or a long and time-consuming computation can decrypt the ciphertext without requiring access to the author’s secret. The duration of this computation can be set to an arbitrary predetermined constant \(T\). In addition, a proof of the correctness of the decryption can also be produced and checked rapidly (\(\log T\) in our case).

We can see intuitively that this solves the problem we had with the commitment. Indeed even if a user refuses to reveal the content of their transaction, someone else can go the slow way to decrypt it.

General principle

Armed with our new Timelock cryptographic primitive we can image a smart contract implementing the following pattern:

1. In a first period, a contract collects user-submitted and Timelock encrypted Michelson values along with some valuable deposit, such as tez.
2. In a second period, after the values are collected, the contract collects from users a decryption of the value they submitted alongside with a proof that the decryption is correct.
3. In a third period, if any value remains undecrypted, anyone can claim part of the deposit by submitting a decryption of the value, with the other part of the deposit being burnt. Different penalties can be assessed depending on whether the user merely failed to submit a decryption for their value, or if they also intentionally encrypted invalid data. Different rewards can be distributed for submitting a correct decryption. The third period needs to be long enough so that people have enough time to perform the Timelock decryption.
4. Finally, the contract can compute some function of all the decrypted data.

There is generally no incentive for users not to provide the decryption of their data and thus the third period generally does not need to take place. However, the second period needs to be long enough so that bakers cannot easily censor submission of the decryption in a bid to later claim the reward. Burning a part of the deposit also limits grieving attacks, meaning where a user gets back their whole deposit by providing the decryption, but in a way that delays everyone else.

As we can see our solution is generic in the way it solves the leakage issue in the P2P network. However it has to be included in the design phase of an application, and many parameters need to be carefully evaluated depending on the application (incentive, latency…).

We propose in Hangzhou the introduction in Michelson of an opcode (OPEN_CHEST) and two types (chest and chest_key) allowing Timelock-encrypted values to be used inside a Michelson contract. See more information in the technical documentation.

Caveats

Although Timelock solves the core of the problem of BPEV, it also moves part of the complexity of validating an operation to the smart contract. In the traditional setting, a number of errors can be detected during validation by the block producer, which can for example mark the transaction as invalid (all the while retaining the fee). Once this information is encrypted this is no longer possible. Special cases such as decryption and deserialization errors (see the technical documentation for more details) are inherently application-specific issues which we therefore leave to the designer of the specific smart contract application to address.

Other uses

While the problem we wished to solve was BPEV, Timelock might also be useful for other applications, for instance this self-tallying fully-decentralized voting system. Intuitively, as we outline in this blog post, Timelock allows to bring some notion of fairness in interactive protocols with respect to the ordering of messages. We hope other creative uses can be made of the instruction we propose.

Conclusion

Thanks to the introduction of Timelock in the Michelson smart contract language, transactions can hide sensitive information at the P2P layer, preventing any malicious reaction before the consensus layer orders them. We believe our solution tackles the BPEV problem at its core, at the price of additional complexity during smart contract design. We hope Timelock will help protect the next generation of DeFi applications in the Tezos ecosystem from the threat of BPEV.