Encrypted mempool: a queue that hides transaction contents
Strawmap Beyond that (Long term) · encrypted mempool
This is a structure that keeps a transaction's contents encrypted until it is included in a block. Because even the block producer cannot see inside beforehand, front-running and selectively dropping particular transactions become harder.
Why it is needed
Today, when you send a transaction on Ethereum, it waits in a public queue called the mempool until it is included in a block. Anyone can look into this queue, so block producers and bots can know in advance which transactions are coming. This makes sandwich attacks possible, where an attacker jumps in front of a large trade order to move the price and then sells back behind it for profit, and it also makes censorship easier, where transactions from a particular address are simply left out. An encrypted mempool sends the transaction contents encrypted and makes them decryptable only after their position in the block has been fixed. Because the party ordering transactions does not know the contents, it is hard to selectively front-run or drop them. The goal is to reduce the losses users suffer to bots. The key open problem is who decrypts, and how. Approaches under study include having multiple validators each hold a share of the key and decrypt together, and having the content unlock by itself after some time passes. In the Strawmap it sits in the long-term column, and since it is still at the research stage, the design may change or be dropped.
How it works
- Send it encrypted The user encrypts the transaction contents and posts them to the mempool. Only the information strictly needed to include it in a block, such as the fee, is visible from outside.
- Order without knowing the contents The block producer puts the encrypted transactions into the block as they are and fixes their positions. Because it does not know which transaction is which, it cannot selectively front-run or drop them.
- Unlocking after the slot is fixed Once the order within a block is finalized, the key is revealed, and the transactions are decrypted and executed. Researchers are exploring ways to split the key among several validators or to have it open on its own after a set amount of time.