🚧: 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(c{t}_1,c{t}_2):$ Given ciphertexts
  $c{t}_1$ and
  $c{t}_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
  $s{k}_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
  $s{k}_{i,j}$.
• A new comparison algorithm
  $CompareMC$ takes as input ciphertexts from different users,
  $s{k}_{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?