⚖
Themis Architecture
Themis architecture is presented to be a solution for MEV on application-specific blockchains. The current iteration of the protocol is focusing on the minimization of MEV by combatting two major ways of value extraction: VER (Value Extraction by Reordering) and VED (Value Extraction by Denial)
Themis architecture prevents VER by splitting the block production into a two-step process, block building, and block execution. In the first step, transactions are accepted into a block, and in the second step, the transaction execution order is shuffled using information that does not exist at the time of block building. Prevention of VED is made possible by the encryption of transactions by the user, which can be decrypted only by the transaction executor. It is achieved by transactions being encrypted by public keys of both the block builder and block executor. This creates a doubly encrypted transaction that is sent to the mempool.
As a result, the protocol combats value extraction on multiple levels, paving the way for fair execution and better slippage for the users, in comparison to similar applications where value extraction is sustained by redistribution mechanisms or simply ignored.
VER solution builds on the assumption that block production consists of two responsibilities: deciding on block contents and deciding on execution order. We propose to split the block production into a two-step process, block building and block execution, wherein the first step transactions are accepted into a block (“block building”) and in the second step the transaction execution order is shuffled using information that doesn’t exist at the block building time (“block execution”). Every miner has a responsibility to build the new block and execute the previous block.
In the first step, the block builder gathers the transactions from the mempool and builds the block. After that, they provide a seed for the subsequent miner that will use it for shuffling the transaction execution order.
In the second step, the block executor signs the seed with their private key and uses that as a seed for shuffling. A private key is used because it’s unknown to the block builder and can’t be manipulated by the block executor. The signature is not malleable and the scheme is deterministic. After that, the executor builds a new block (performing the first step for the next block) and provides the private-key-signed seed.
This effectively creates a seed chain that is used for transaction shuffling. This separation of concerns guarantees that the block builder can’t affect the execution order and the block executor can’t set the block content and has to shuffle the transactions.
In consequence, this creates a 2-block HEAD of the blockchain and doubles the time of the block execution.
This solution introduces probabilistic value extraction. In the suggested design, participants will have a higher chance to claim any pure gains by sending multiple transactions, and we argue it is fair since every participant has equal opportunity. In other designs, even with Flashbots auctions, the power is shifted more toward miners, who are the ultimate decision-makers over the block content. At the same time in Themis Consensus Extension, participants are disincentivized to attempt to extract any gains with multiple transactions, thus eliminating an edge that is making frontrunning activities statistically profitable.
An example of a common VED attack is denying pure gain transactions (e.g. arbitrage) and replacing them with their own. We argue that if only miners have this possibility, it’s an unfair design because such a pure gain opportunity is never available for a user.
There are 3 levels of VED solutions, from least to most robust:
- Miners shouldn’t deny transactions
- Miners don’t know which transaction to deny
- Miners can’t deny transactions
The current state of the VED solution reaches the 2nd level of robustness that the Miner (or any transaction relayer) doesn’t know what to deny because it has no information about the transaction purpose.
To achieve this, we propose the encryption of transactions by the user, which can be decrypted only by the transaction executor, given it’s been first decrypted by the block builder. It’s achieved by transactions being encrypted by public keys of both the block builder and block executor. This creates a doubly encrypted transaction that is sent to the mempool.
In the following steps, block builders are required to decrypt the transaction, but that doesn’t reveal its content to them because the transaction still requires a final decryption from the block executor. In this approach, the transaction builder can’t know the content of the transaction, but the executor is forced to decrypt and execute it. This means that the block builder and block executor have to be known ahead of time and submission into the mempool is not node-agnostic, but has to include that foreknowledge.
It is important to note that transaction encryption is voluntary and should be used only where it is reasonable. This is because processing an encrypted transaction is costly and the processing costs are not guaranteed to be covered by the economic value created by transaction processing. In fact, since the content of the encrypted transaction is unknown, it may even be impossible to execute. This is why, unlike unencrypted exchange transactions, all encrypted transactions are required to have fixed gas costs.
.jpeg?alt=media&token=83df0ee7-04d2-4352-b627-7e545c21c82e)
Last modified 2mo ago