Why
The briefing reads as if the question is still open — developers will meet, encryption is being considered, no scheme is ready. Two of those are true and one is not. There are already two competing drafts on the table: EIP-8105, which enshrines a technology-agnostic key-provider layer, and EIP-8184 (LUCID), which makes the builder commit to sealed payloads before it can read them. So the design space is no longer "should we"; it is "which failure do we accept." And the failure worth naming is not cryptographic strength. EIP-8105's envelope stays in the clear by construction — chain ID, nonce, priority fee, max fee, gas amount, key provider ID, key ID, and the signature components, which means the sender is recoverable. Ethereum's own pattern documentation states the consequence without hedging: size, gas limit, and sender address remain visible before decryption and can still enable inference attacks on large or identifiable trades. A sandwich bot does not need your calldata to know that a known DEX router address just posted an unusually large gas limit and bid aggressively to get in. It needs to know that a big trade is coming and roughly how big. Encryption removes the exact number and leaves the shape. So the claim worth testing is not whether encrypted mempools work; it is how much of the extracted profit the leftover metadata still funds. That number decides whether this is a fix or a tax.
How it works
Three measurements, cheapest first. One, the residual-MEV replay. Take a window of historical mainnet blocks, strip every transaction down to only the fields EIP-8105 leaves in plaintext — sender, nonce, gas amount, priority fee, max fee — and try to select the sandwichable ones from that alone. Score the selection against the sandwiches actually extracted in the same window; the relay and bundle plumbing the live pbs card already built is the labelling path, so this is analysis on top of existing infrastructure rather than new infrastructure. The output is one fraction: the share of extracted profit a metadata-only adversary could still have targeted. Publish it whichever way it comes out — a low number is the strongest possible argument for the EIPs, and a high one is the strongest argument against calling this solved. Two, the two-block bill. EIP-8105 executes the envelope in one block (nonce incremented, fees paid) and the decrypted payload in the next, and the fee is paid even when decryption fails. So encryption costs a block of latency plus a failure mode where the user pays for nothing, against a status quo where routing through a private relay costs zero at the point of use. Model the crossover: at what trade size does the sandwich you avoid exceed the latency and failure cost you accept? Below that line, users rationally keep using private relays, and an encrypted mempool that the largest traders route around has not fixed the centralization it was meant to fix. Three, the failure nobody can attribute. The unresolved item on the call was that the protocol cannot establish why a key failed to arrive, or whether a provider sold it early. Build the smallest possible simulator — n key providers, threshold k, one colluding subset — and generate three traces: a key withheld deliberately, a key leaked early, and a key that was merely late. Then ask the only question that matters for enforcement: from outside, are the three distinguishable? If they are not, slashing has nothing to attach to, and the honest-threshold assumption is not an assumption but the entire security model. Reads against the live pbs card, which sits on the extraction side of the same market, and alongside third-party-blast-radius, which asks the same committee-capture question of every threshold scheme.
Where it lands in Jayverse
- Verex: test residual-MEV before trusting any private settlement path. If Verex ever routes resolution or large order transactions through an encrypted or private mempool, check whether sender, nonce, gas and size alone still let a bot target the largest settlement transactions.
- Devnet: build the threshold-encryption simulator before adopting the primitive. Reproduce the PoC's n-provider, k-threshold, one-colluding-subset simulator on devnet; if withheld, leaked and late keys aren't distinguishable, don't treat the scheme as usable for Verex order flow.
- OFA: price the commit-before-decrypt cost into the auction. A solver that must commit before it can decrypt pays for failed matches, so model that latency and failure cost explicitly in the intent/solver design, not just as extra gas.
Key expressions
| Expression | 뜻 · 쓰이는 자리 |
|---|---|
| in the clear | (암호화 안 되고) 그대로 노출된 · 설계상 평문으로 남는 필드를 가리킬 때. "stays in the clear by construction" |
| without hedging | 에두르지 않고·단정적으로 · 결과를 돌려 말하지 않고 명확히 밝힐 때. "states the consequence without hedging" |
| fund (a profit) | (이익을) 자금원이 되어주다·가능하게 하다 · 남은 정보가 여전히 공격 수익을 뒷받침할 때. "the leftover metadata still funds" |
| whichever way it comes out | 결과가 어느 쪽으로 나오든 · 실험 결과를 미리 받아들이겠다는 태도. "Publish it whichever way it comes out" |
| model the crossover | 교차점(전환점)을 모델링하다 · 두 선택지의 유불리가 뒤바뀌는 지점을 계산. "Model the crossover: at what trade size" |
| rationally keep using | 합리적으로 계속 ~을 쓰다 · 손해를 피하려고 기존 방식을 고수하는 행동. "users rationally keep using private relays" |
| has nothing to attach to | 걸 데(근거)가 없다 · 처벌·제재를 적용할 근거 자체가 없을 때. "slashing has nothing to attach to" |
| colluding subset | 담합하는(공모하는) 일부 집단 · 임계값 기반 시스템의 공격 시나리오. "threshold k, one colluding subset" |
| honest-threshold assumption | 참여자 다수가 정직하다는 가정(임계값 기반 신뢰 가정) · 보안 모델의 전제 조건. "the honest-threshold assumption is not an assumption" |
| labelling path | 정답 라벨을 매기는 경로(기존 인프라를 재활용하는 방식) · 새 인프라 없이 기존 것으로 분석할 때. "already built is the labelling path" |
| MEV | 최대추출가능가치(Maximal Extractable Value) · 블록 생산자가 트랜잭션 순서 조작으로 뽑아내는 초과 이익. "the sandwiches actually extracted in the same window" |
| EIP-8105 | 이더리움 개선제안 8105번(암호화 멤풀의 키 제공자 계층 표준) · 이 카드가 분석하는 두 경쟁 초안 중 하나. "EIP-8105, which enshrines a technology-agnostic key-provider layer" |
| EIP-8184 (LUCID) | 이더리움 개선제안 8184번, 코드명 LUCID · 빌더가 내용을 보기 전에 봉인된 페이로드에 커밋하게 하는 경쟁 초안. "EIP-8184 (LUCID), which makes the builder commit to sealed payloads" |
| PBS | 제안자-빌더 분리(Proposer-Builder Separation) · MEV 추출 측을 다루는 이더리움 인프라, 다른 카드에서 이어짐. "the live pbs card already built is the labelling path" |