UPDATE: Batched Threshold Encryption for Mempool Privacy

# UPDATE: Batched Threshold Encryption for Mempool Privacy This blogpost is an update on the status of encryption schemes for mempool privacy. For motivation and a better summary of the space, please read the earlier [blog post](https://hackmd.io/FNsglCqXR3W8GLXnxwVDvg). ## tl;dr In short, we would like to ensure privacy of transactions up until the point they are included on chain. A natural approach is to use any off the shelf threshold encryption scheme and a committee of $n$ parties can decrypt ciphertexts after they have been included on chain. But if each block contains $B$ ciphertexts that need to be decrypted, this would need $O(nB)$ communication -- one message per ciphertext, per party. Estimates for typical parameters ($n \approx 128$, $B \approx 512)$, show that the communication needed for decryption can be an larger than the block size itself! Prior work avoids this issue by using adaptations of the [Boneh-Franklin IBE](https://eprint.iacr.org/2001/090), where clients encrypt to a point of time in the future and ciphertexts can be decrypted after that time. This doesn't quite achieve our vision for encrypted mempools as ciphertexts get decrypted even if they never make it on chain! In an ideal world, clients encrypt ciphertexts which can be decrypted if and only if, they have been included on chain, with very little communication. A best of both worlds between the threshold encryption vs IBE approach. Earlier this year, we formalized this primitive as Batched Threshold Encryption (see [paper](https://eprint.iacr.org/2024/669)) and gave a concretely efficient construction, which allows a committee of $n$ parties to decrypt $B$ ciphertexts using $O(n)$ communication i.e. each party sends a constant sized message. :::danger ‼️ But there was a caveat, the committee needed to run a "per epoch setup" for each batch of ciphertexts that need to be decrypted. The initial setup was also significantly more complicated than the prior approaches. In short, we offered more efficient decryption at the cost of a more expensive setup. ::: ## New result We now have an [improved construction](https://eprint.iacr.org/2024/1516) of Batched Threshold Encryption, with a very simple setup -- estabilishing a shamir secret sharing of a single random value via a distributed key generation protocol. And more importantly, no epoch setup. In fact, this is **identical** to the setup used in prior approaches based on threshold encryption / IBE. :::info We provide the first construction to achieve these three properties simulataneously: 1. Simple setup -- one execution of a distirbuted key generation protocol 2. Efficient batch decryption with $O(1)$ communication per party 3. Ensures privacy for ciphertexts that are not included on chain. ::: :::success 📣 Our scheme is a **drop-in replacement** for mempool privacy approaches based on threshold encryption / IBE. ::: ### Comparison against prior work | **Scheme** | **Communication** | **Pending Tx Privacy** | **Setup** | |:------------:|:-----------:|:------------------------:|:-----------:| | Threshold Encryption <br> [[Ferveo](https://eprint.iacr.org/2022/898), [MEVade](https://ieeexplore.ieee.org/document/10174966)] | $O(nB)$ | ✅ | DKG | | BF-IBE variants <br> [[McFly](https://eprint.iacr.org/2022/433), [FairBlock](https://eprint.iacr.org/2022/1066), [Shutter](https://shutter.network)] | $O(n)$ | ❌ | DKG | | [CGPP24](https://eprint.iacr.org/2024/669) | $O(n)$ | ✅ | MPC + EpochSetup | | [**This Work**](https://eprint.iacr.org/2024/1516) | $O(n)$ | ✅ | DKG | ## Links - **Paper**: https://eprint.iacr.org/2024/1516 - **Implementation**: https://github.com/guruvamsi-policharla/batched-threshold-pp