Guru Vamsi Policharla

@guruvamsi-policharla

Joined on Dec 22, 2023

  • The focus of this blogpost is on protecting the privacy of transactions that have been submitted to a public mempool but are yet to be included on chain. Based on work with Arka Rai Choudhuri, Sanjam Garg, Dimitris Kolonelos, Julien Piet, and Mingyuan Wang. :::info [09/2024] UPDATE: We improved batched-threshold encryption by removing the epoch setup and simplifying the initial setup. See new blogpost. ::: Why? There are many situations in which one would want to hide a transaction until the very moment before it is executed. A popular example is the mitigation of “bad” MEV, where a block proposer can frontrun and/or backrun a user’s transactions, thereby exploiting to exploiting price movements to gain profits at the expense of users.
     Like 1 Bookmark
  • 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. 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, 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) 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.
     Like  Bookmark