---
tags: flashbots, research
---

# 🚧: Using Order-Revealing Encryption (ORE) to Provide Mempool Privacy

## Required Reading

1 https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8434214
2 https://eprint.iacr.org/2018/953.pdf
3 https://github.com/flashbots/mev-research/issues/34
4 https://eprint.iacr.org/2016/612.pdf

## What is ORE?

ORE is a cryptographic primitive that enables range queries over encrypted ciphertexts. Its main application is in the database world, where it's used to enable queries over encrypted databases to provide assurances in the case of data breaches.

For each of exposition, we will be simply providing a high-level definition.

ORE schemes are defined as follows:
- $KeyGen(\lambda)$: Given a security parameter $\lambda$, generate a secret key $sk$
- $Encrypt(sk, m)$: Given a secret key $sk$ and message $m$, outputs a ciphertext $ct$
- $Compare(ct_1, ct_2):$ Given ciphertexts $ct_1$ and $ct_2$, outputs a bit $b$

## How can ORE help us with getting mempool privacy?

ORE provides us with a way to efficiently encrypt transactions such that miners can still compare gas-related fields without actually revealing those fields. Using the $Compare$ procedure, miners can compare different ciphertexts for transactions based on their gas-related fields and include them into blocks as they normally would.

In more details, users will each usehave their own $sk$
and encrypt their transactions. Then they will send these ORE encrypted transactions to miners who will then be able to compare different ORE encrypted transactions using $Compare$.

However, as described, there are a few immediate problems with this approach. The first one is that miners still need to be able to execute transactions after they have verified that the transaction satisfies some gas related constraint. But, using ORE, the user will now need to decrypt their transactions in order for this to be possible, losing all of the benefits of using ORE.

How can this problem be potentially be resolved?

Let's consider a variant of ORE called multi-client ORE that is better suited for multi-client interaction. A slightly modified version of how we can provide mempool privacy is as follows:
- Each user creates a secret key $sk_i$ with the help of a trusted party called the key manager with its own key $MK$
- A new key is generated taking the indices of different users $i$ and $j$ along with $MK$, call it $sk_{i,j}$.
- A new comparison algorithm $CompareMC$ takes as input ciphertexts from different users, $sk_{i,j}$ that returns a bit.

Now, we have more problems. In this multi-client ORE scheme, we now have a trusted manager, multiple more keys to distributed and more comparison functions to handle.

## How does ORE differ from current solutions to mempool privacy?

TODO: Compare and contrast solutions

| Solution | MEV Security | Execution Delay | Consensus Time Speed | Requires hard fork? |
| -------- | -------- | -------- | -------- | -------- |
| SGX | | |
| Timelock Encryption | | |
| Threshold Decryption | | |
| Order-Revealing Encryption | | |

## Open Questions
- Is it possible to still execute the transaction if it has been encrypted using ORE?
- If not, can ORE be modified/extended to work in a more asymetric context for example threshold ORE, timelock ORE, etc?