Reveal optionality in encrypted mempools: how big is the sender’s free option, and a post-quantum way to remove it

Cryptography
, ,
1

Hi all,

Thanks to @aelowsson @julian @b-wagn @GottfriedHerold, since this builds directly on LUCID and the criticism thread. Also a kind request for review on this work.

I’ve been wondering how much the “free option” in encrypted mempools is actually worth, and what happens if you try to take it away. The short version is in the TL;DR. The full treatment, with proofs, is in the paper, and the Lean 4 formalization is linked below.

TL;DR

The setup

Let G be the information everyone gets anyway, and F the information a sender who controls the reveal has. The endogenous option is V^endo = V^F − V^G: what control over the reveal adds on top of what the market gives you for free.

1. How big is it?

  • V^endo is exactly a Jensen gap, and it is strictly positive under a simple criterion.
  • It is bounded by ‖D‖_p (2ε)^(1−1/p) when the option is exercised with probability ε.
  • With ETH implied vol around 51% and an 8 s window, the exogenous option is about 1 bp. A fee of about 6 bp is enough to cap exercise at 1%.

2. Can forced opening fix it?

  • Making decryption mandatory with a time-lock helps, but hardware speed matters. Let γ be how much faster an attacker computes the sequential function than an honest solver.
  • Sound, timely forced opening needs γ ≤ (t2 − t_h)/(t1 − t_pub). With one slot of mempool wait, that ceiling is below 2.

3. Does the LUCID fee price it?

In LUCID (EIP-8184), a revealed transaction pays f/F of its top-of-block fee and a non-revealed one forfeits f, with F = 128. The idea is that the fee prices probabilistic frontrunning. It stops working once a sender uses many conditional commitments. One selector plus one executor is enough for any cap m ≥ 2. A hit costs f(1+1/F) and a miss costs only 2f/F, so the break-even fee is

f_inv = pΛ / (p(1+1/F) + 2(1−p)/F)

and it is at least Λ/2 whenever p1 ≥ 2/(F+1). With Λ = 50 bp and p1 = 1/64, that is about 25 bp. A single commitment would need only about 0.8 bp, so the multi-commitment attack is roughly 30 times more expensive to deter.

4. Where does the option go?

If you take it away from the sender, a blocking coalition of |W| ≥ n−t+1 committee members inherits it. For any threshold t, the smallest coalition that can either block or decrypt early has size min(t, n−t+1) ≤ ⌈n/2⌉. Deterrence works iff the coalition’s net penalty β is at least the essential supremum of the option payoff. Hybrid designs without independence still leave an induced-unavailability term.

BSR in a nutshell

Instead of fighting the option after the fact, BSR makes everyone commit before they can know anything useful.

  • During a short window ω after t1, each sender posts an escrow: a signed commitment to the value, plus the value masked by a long sequential hash chain (about 1.4e8 steps at 70 ns/step).
  • Normally the releaser just reveals quickly.
  • If they withhold, anyone can compute the pad and force the opening.
  • If the escrow is inconsistent, the deposit S is slashed and the value is dropped.

What you get (Theorem 5):

  • Before the escrow deadline d, the endogenous option is exactly zero.
  • After d, no deviation pays when S covers the largest gain from changing the executed set. Under the paper’s assumption A2, the fee f1 deters at any cap on commitments.
  • Informed blocking after d costs the coalition at least S.
  • With t = ⌈2n/3⌉, the smallest coalition that can block is never smaller than under any threshold without BSR, and strictly larger for n = 2 and n ≥ 4.
  • Everything is hash-based, so there are no pairings or discrete-log assumptions in the timing mechanism.

What I’m assuming, and what’s open

  • Hardware gap. BSR needs γ ≤ Θ/ω, where Θ is the opening window. At 12 s slots that gives γ_max = 5 (ω = 2 s, Θ = 10 s) or 11 (ω = 1 s, Θ = 11 s). This is an explicit assumption, not something I measured. Real numbers on sequential-hash ASIC speedups would settle it.
  • Not yet analysed. The bisection dispute game for inconsistent escrows, a full equilibrium analysis for non-colluding releasers, verifiable escrows, batched post-quantum forced opening, and end-user escrows.

I’d love feedback, especially on the hardware assumption and on whether the committee model matches what you expect in deployed designs.