soispoke.eth

FOCIL (EIP-7805) was just SFI'd and is the CL headliner for the Hegota fork. This means Ethereum has decided to prioritize a feature that improves censorship resistance, gives better inclusion guarantees to its users, and strengthens its position as the most credibly neutral network to build on. In today's world, it's remarkable that the Ethereum community can stand behind protocol upgrades that reinforce core cypherpunk values. It's truly unique, and I'm proud to be working on a technical and social project that stands for freedom and equal access. It's of course a meaningful step, but it's also only the beginning. Now is the time to show that cypherpunks can ship. Let's bring FOCIL to mainnet.

Quick summary:

What Alice still needs to worry about IP exposure. When Alice first submits her transaction, her network peers see her IP. The wallet should route this initial submission through Tor or a mixnet so that her IP never touches the gossip network in the clear. None of the four protocol upgrades address this. Post-execution traces. After her block lands and the encrypted frame decrypts, the Uniswap swap is on-chain forever. An observer sees the trade happened. They do not know it was Alice, but repeated trades from the same shielded balance with recognizable patterns make behavioral fingerprinting possible. Even pre-execution, metadata like fee fields, gas amounts, key-releaser identity, and timing can help classify transactions. Removing this requires private execution state, which is not currently planned on L1 in the short term.

Alice swaps privately on L1 tldr: Privacy protocol users today depend on broadcasters that can see, frontrun, and censor their transactions. In this thread we show how four future protocol upgrades can remove this dependency step by step. Native AA (EIP-8141) and 2D nonces let users self-submit with no off-chain infrastructure. Encrypted frame transactions hide swap parameters until after block ordering is committed. FOCIL guarantees inclusion as long as one honest includer can see the transaction pending in the public mempool. 👇🧵

Some of the hardest and most important deliveries are now within focus. Hardness track at the EF Protocol.

Very excited to co-lead the hardness track with @parithosh_j and @fredrik0x. We will focus on PQ, Network resilience, Privacy, Censorship Resistance, Security and Transparency for the next 6-12 months. Hardness/acc

🔥 Another day, another awesome encrypted mempool design for Ethereum 🛡️⚔️encrypt the mempool!

New post on EthResear.ch! Encrypted frame transactions By: - Thomas Thiery (soispoke) 🔗 ethresear.ch/t/24440 Highlights: - Core mechanism: “order-execute separation” enables same-slot encrypted execution by having the builder commit to the exact transaction bytes and their ordering (via a Merkle root) before any decryption keys are revealed, then executing that already-committed order after reveal. - The design is built on EIP-8141 FrameTx: each encrypted transaction has a public VERIFY frame (programmable, static, pre-reveal-validatable) plus one hidden encrypted execution phase; this also supports selective disclosure and future authorization schemes (including a path toward post-quantum approaches). - Reveals are handled with a LUCID-like key-releaser model (KEM-DEM): senders commit to H(exec_params) and a commitment to the symmetric key k_dem; at reveal time the network checks the key commitment and that decrypted exec_params matches the binding, while allowing “skip” behavior if no timely reveal occurs. - Consensus/roles and timing are central: proposer selects a bid that commits to the ordered tx set; key-releasers publish k_dem bound to (slot, beacon_block_root, tx_reveal_id); builder freezes a reveal view at a deadline and broadcasts a post-reveal payload envelope; a PTC votes on that envelope; attesters in the next slot re-execute and verify reveal_root/BAL against cached reveals using a view-merge mechanism (FOCIL-like) to limit builder discretion in excluding reveals. - Tradeoffs and risks remain: it provides pre-trade privacy (not permanent privacy or network-layer anonymity), introduces a “free option” for self-revealing senders who can withhold keys if ordering is unfavorable, and has failure/equivocation modes (non-cooperating or colluding key-releasers, builder withholding the post-reveal payload, or reveal_root equivocation) that require careful rule/spec design. ELI5: Imagine you want to put a secret instruction into a box (your transaction) so nobody can peek and cheat (MEV) before it runs. This proposal makes block builders lock in the full list and order of all boxes first, while the secrets stay hidden. Only after the order is fixed do special “key releasers” publish the keys to open some boxes, and then the builder runs them immediately in the same time slot. If a key doesn’t show up in time, that box’s secret part just doesn’t run, but the public “is this allowed?” check still runs. The design builds on Frame Transactions so the public checks are programmable, and it reuses LUCID-style encryption so keys can come from the user, a committee, or other providers.

Full write up here: ethresear.ch/t/encrypted-fr… And thanks @_julianma, @weboftrees, Benedikt Wagner and Gottfried Herold for feedback and comments!

About the (other) free option problem: A self-decrypting sender can observe the committed ordering and choose to reveal only when the position is favorable, effectively holding a free option on execution. Mitigations like additional fees on encrypted txs or skip penalties exist but I think more explorations are needed to make final decisions.

🔒🖼️ New post: Encrypted Frame Transactions 🔒🖼️ tl;dr: Encrypted frame transactions build on LUCID and EIP-8141 to hide execution parameters (target, calldata, amounts) until after the block's ordering is locked. This design unlocks same-slot encrypted execution, interleaved plain text/encrypted transactions, and is future-compatible with PQ schemes. 👇🧵