Discussion topic for EIP-8184: LUCID encrypted mempool (PR).
Description
Public encrypted mempool for commit-before-reveal inclusion of MEV-sensitive transactions, without enshrining a specific encryption scheme.
Relevant resources
Special thanks to the Shutter team including Jannik Luhn and Luis Bezzenberger; the EF cryptography team, including Benedikt Wagner and Gottfried Herold; and Potuz.
Note that some details regarding resource pricing in the EIP still remain to be settled.
Abstract
This EIP specifies LUCID, a mechanism for carrying encrypted transactions through Ethereum’s public inclusion pipeline while keeping their contents hidden until after the scheduling decision has been fixed. By requiring commitment before reveal and delaying decryption until that point, LUCID protects MEV-sensitive order flow, limits probabilistic front-running by minimizing pre-execution information leakage, and broadens the practical censorship resistance of inclusion lists. The design remains open to different off-protocol decryption schemes, including trustless self-decryption, rather than coupling Ethereum to a single enshrined cryptographic construction.
1 Like
Over the spring and summer, we have been studying the design space further.
The main forum is the bi-weekly Encrypt the Mempool technical meetings. These meetings have focused on avenues for removing optionality, but no convincing alternative design has yet to emerge. The main issue is the required PQ cryptography.
A prominent critique of commit-reveal schemes was posted in June by Gottfried.
In the other direction, a critique of threshold-committee schemes has also recently been shared by Jannik.
Jannik has suggested a variant of the trusted set in EIP-8105: a Key Publisher Whitelist maintained by validators. A hidden benefit relative to the trusted set is that it open up for easier CR via FOCIL. However, I wanted to explore if we could still achieve CR under a trusted set. One avenue is to have validators construct the weighted longest path of the trust DAG when enforcing the ILs.
The PQ cryptography blocker described above can be removed now. LUCID does not need to wait for a production-ready post-quantum threshold KEM or a distributed key-generation ceremony to remove sender reveal optionality. The important distinction is between knowing the decryption key and having authority to make the protocol accept its reveal. Today the sender already knows k_dem, and LUCID permits the sender to publish that key itself. That means the sender retains a choice after commitment: reveal the transaction or withhold it. For a protected threshold mode, possession of k_dem should no longer be enough to satisfy the reveal condition. The sender can still generate the same random 32-byte k_dem, encrypt the transaction exactly as LUCID does today, and commit to that key through the existing ticket. Before submission, the sender threshold-shares k_dem across a protocol-approved committee. Each share is encrypted independently to its committee member using that member’s post-quantum KEM public key. There is no committee master key and no distributed private key. Once the scheduling decision has been fixed, each committee member decrypts its own share and publishes an authenticated release. That authentication needs to bind the release to this transaction and this scheduling decision, using a fork-approved post-quantum signing credential. When the required threshold of distinct committee members has released valid shares, every node uses the same canonical set of releases to reconstruct k_dem. The reconstructed key must match LUCID’s existing key_commitment, after which the existing decryption and reveal checks continue normally.
For this mode, a sender publishing k_dem by itself does nothing. The transaction has not satisfied its reveal condition until the threshold of independently authenticated committee releases exists. That is what removes sender optionality: the sender may know the plaintext and key from the beginning, but after committing the transaction it no longer controls whether the protocol recognizes the reveal. This gives us the property that threshold encryption was supposed to provide without requiring threshold encryption to exist as one monolithic primitive. Ordinary independent PQ encryption protects the individual shares. Threshold sharing prevents fewer than the required number of committee members from reconstructing the key. Independent PQ authentication proves that those designated members actually released their shares after scheduling. LUCID’s existing commitment binds the reconstructed result back to the transaction that was originally committed. There is no DKG because there is no shared decryption private key. Every committee participant only needs its own ordinary PQ keys. Malformed shares do not create another valid outcome. The network reconstructs from the canonically selected threshold releases once, and the result either matches the key already committed by the ticket or the ticket fails. A malformed ticket can therefore cause its own reveal to fail, but it cannot give the sender a new decision after commitment about whether a correctly formed transaction should execute.
This does not make threshold corruption disappear. If enough committee members collude or sell their releases, they can reveal early. If too many withhold, they can prevent reconstruction. Those are the explicit corruption and liveness assumptions of the committee, and Jannik’s bribery critique remains relevant to how the committee should be selected, rotated and incentivized. But that is a different problem from the one above. It does not mean Ethereum still needs a PQ threshold KEM or DKG before sender reveal optionality can be removed. The builder/PTC optionality identified in Gottfried’s critique is also separate. Removing the sender’s reveal choice does not by itself settle how the protocol should handle disagreement about timely releases or builder behavior. That remaining consensus question becomes easier to isolate once sender-controlled reveal is gone. The committee also cannot be chosen arbitrarily by the sender. The strong guarantee requires a protocol-defined committee, threshold and approved cryptographic profile. Otherwise the sender could simply choose decryptors it controls and recreate the same optionality under another name. The remaining cost is concrete rather than cryptographically unknown: one PQ-encrypted capsule per committee member. That creates an O(n) bandwidth cost which can be measured against realistic committee sizes and LUCID’s data limits. If the desired committee is too large for the current header representation, the capsules can be committed separately without changing the reveal rule.
So I believe the main cryptographic question above is resolved enough to move forward. LUCID does not need to wait for post-quantum threshold encryption. The required reveal property can be composed from independent PQ encryption, threshold sharing, authenticated post-scheduling releases, and the commitments LUCID already has. The remaining work is to specify and benchmark that profile, then separately resolve committee corruption economics and builder/PTC optionality. If there is a sender-reveal security property required by LUCID that this construction does not provide under the stated threshold-corruption assumption what is it?