Re: ePBS Timing and Same-Slot Execution
Thanks for the detailed response and the ePBS point. Section 3 (Multi-builder key distribution) was meant to address it but should have been the main approach as you point out.
Conditional commitments are leaderless
The commitments in this proposal are conditional, same as how preconfirmations work today: each builder signs “if I win, I will include/order STs [x, y, z] at ToB.” Every competing builder issues such commitments in parallel. Only the winning builder’s commitment settles; the rest are no-ops.
Keypers release keys to all committed builders, gated by the registered commitment. As Section 3 notes, a non-winning builder who received keys holds plaintext for transactions already ordered and finalized as ToB placement is deterministic and state has moved on, so there is no residual ordering advantage. The trust surface widens with N builders, but threshold release at the keyper committee level (not per-builder) means no individual builder can exfiltrate plaintext to non-committed parties without being itself slashed via the same fault proof.
So EIP-7732’s pre-beacon-block winner uncertainty is not a constraint on the commitment layer. The “tie down the proposer, not the builder” framing applies to single leader-based designs and not leaderless designs; that is not what this proposal does.
Why same-slot matters (Section 6 recap)
N+1 is fine as a fallback. If it becomes the common case, the latency profile and stronger execution guarantees that motivate same-slot fade for DEX swaps, liquidations, oracle-sensitive trades. A same-slot path that only works when nothing goes wrong is structurally a 24-second confirmation for the worst-case mev-sensitive transaction.
Same-slot extension in the Rationale vs this proposal
| LUCID Same-Slot Extension (Rationale, t=6-9s) | This Proposal | |
|---|---|---|
| Builder visibility at build | Blind (keys arrive after payload) | Plaintext (keys arrive before build) |
| mev protection | Frontrun/sandwich prevented via blind ordering | Frontrun/sandwich prevented via slashable commitment + FOCIL backstop; back-running enabled at build as a price-discovery channel (Section 5) |
| Block quality | Suboptimal (Built blind; state conflicts can cascade to N+1) | Optimal (Built with full information) |
| Failure mode if keys are late | N+1 (and N+2); graceful degradation across 2 slots | Per-transaction fallback; ST included as ciphertext or deferred to N+1 |
| Robustness under 6s slots | Intra-slot window compresses to ~1.5s; addressed via optimistic verification (security degradation) | Commitment window does not depend on slot duration; is decoupled from intra-slot timing |
| ePBS commitment binding | Requires a new mechanism (winner unknown pre-beacon) | Conditional commitments from candidate builders; winner’s binds automatically |
| Key release enforcement | Voluntary release (PTC bitfield, view-merge) | Slashable commitment + FOCIL inclusion mandate |
| Builder-keyper incentives | Keypers expected to release on schedule; no compensation | Keypers compensated by builder for early access; payment is the release signal |
The Rationale extension solves when keys release; the proposal here is intended to fill the adjacent questions of whether they release, what builders do with the gap, and how the design behaves at shorter slot times.
The 6s-slot row is worth highlighting on its own. Because the commitment window in this proposal lives outside the consensus path, it does not contract as slot times shorten. The same design holds at 12s, 6s, 3s or beyond without requiring optimistic verification on the attestation hot path. As Ethereum’s slot times compress, this property becomes increasingly load-bearing.
ST-as-PT lands inside this model
The ST-as-PT idea is a clean spec-level expression of what Section 5 already describes economically. A builder with pre-bid key access does not need protocol-level decryption, they include the ST as a PT with the key attached and pay the format surcharge. LUCID’s blind path remains the default; conditional commitments become the opt-in market layer that prices the information advantage the design naturally creates and that the protocol does not enshrine.
Where this leaves things
The economic story and execution quality are what this adds to the Rationale extension. LUCID’s current same-slot draft leaves the keyper release incentive implicit; this proposal is the only mechanism on the table that explains why keypers release keys reliably and why builders pay for the privilege. That economic layer is independent of which timing model wins as the Rationale extension would benefit from the same enforcement structure either way.
Given that, two collaborative directions feel productive:
- Joint evaluation of this proposal as a candidate same-slot path inside LUCID. The two designs are complementary as both target the same circular dependency, with different commitment loci.
- An execution quality working session. We’d like to invite the encrypted mempool (EM) community to discuss this issue at the next EM Tech meeting to land on a path for positive execution quality
Looking forward to hearing from members of the EM community!