feat: upcoming developments on ethereum l1#40
Conversation
|
|
||
| Take an anonymized custodian running a shielded-pool redemption, the same pattern we built in [Building Private Transfers on Ethereum with Shielded Pools](/blog/building-private-transfers-on-ethereum-with-shielded-pools/). The cryptography is settled and works today: the custodian proves it owns a note, burns a nullifier, and the pool releases tokens to a fresh address without revealing who held the note. | ||
|
|
||
| The base layer is where it leaks, in four ways before it lands on Ethereum. Paying gas from the custodian's own address re-links it to the private spend. The pool's single nonce lets one stuck withdrawal freeze every redemption behind it. The protocol guarantees nothing about inclusion. Before it is even ordered, the redemption's amount and destination sit in the public mempool. The five proposals below each take one of these off. |
There was a problem hiding this comment.
"The pool's single nonce lets one stuck withdrawal freeze every redemption behind it."
The pool doens't have a nonce; also the nonce issue pointed here might be to link to EIP-8250, but this come as a patch to EIP-8141, it doesn't solve a current issue.
|
|
||
| The base layer is where it leaks, in four ways before it lands on Ethereum. Paying gas from the custodian's own address re-links it to the private spend. The pool's single nonce lets one stuck withdrawal freeze every redemption behind it. The protocol guarantees nothing about inclusion. Before it is even ordered, the redemption's amount and destination sit in the public mempool. The five proposals below each take one of these off. | ||
|
|
||
| ## Paying for a private spend without a relayer in the path |
There was a problem hiding this comment.
Maybe best to emphasize Censorship Resistance here (aka counterparty risk for them)
|
|
||
| ## Paying for a private spend without a relayer in the path | ||
|
|
||
| The gas payer and the spender have to be the same account. [EIP-8141](https://eips.ethereum.org/EIPS/eip-8141) frame transactions would drop that, pushing account abstraction down into the base layer: a transaction splits into ordered frames, one to validate, one to approve who pays the gas, one to run the user's operations, so fee payment becomes programmable instead of hanging off a single ECDSA key. |
There was a problem hiding this comment.
"account abstraction" needs to be defined here.
|
|
||
|  | ||
|
|
||
| **Maturity: scheduled for inclusion.** [FOCIL](https://eips.ethereum.org/EIPS/eip-7805) was a candidate for [Glamsterdam](https://forkcast.org/upgrade/glamsterdam), then deferred when pairing it with enshrined proposer-builder separation in one upgrade was judged too risky. It is now the consensus-layer headliner for [Hegota](https://forkcast.org/upgrade/hegota/), [marked Scheduled for Inclusion](https://forkcast.org/eips/7805/) and targeting late 2026. That status can still change at any core-developers call, so the open question is which committee parameters an institution can accept. FOCIL would guarantee inclusion but not confidentiality. The transaction still sits in the public mempool with its contents exposed, which is why it has to pair with an encrypted mempool. |
There was a problem hiding this comment.
Would be great to translate what it means in their framework. What risks are removed when inclusion is guaranteed.
|
|
||
| ## Removing the trusted relay underneath block production | ||
|
|
||
| Underneath all of this sits a trusted, off-protocol chokepoint: the hand-off between the proposer of a block and the builder assembling it runs through relays such as MEV-Boost, which can delay or front-run flow with no in-protocol recourse. [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732), enshrined proposer-builder separation, would pull that hand-off into the protocol itself, replacing the relay with a slashing-backed fair exchange of block payload for payment, the consensus substrate that inclusion lists and encrypted mempools have to be enforced on. |
There was a problem hiding this comment.
Not sure to grasp the problem it solves here, maybe an example of what is broken when both are done by the same actor.
|
|
||
| ## Hiding the order before anyone can read it | ||
|
|
||
| The last gap is outside the cryptography's scope: the redemption's amount and destination sit in the public mempool before it is ordered. [EIP-8184](https://eips.ethereum.org/EIPS/eip-8184), called LUCID, would close it. The withdrawal travels the permissionless inclusion path as a sealed ciphertext; the builder must commit to including it while blind to its contents, and only then is the key released. LUCID is encryption-scheme-agnostic commit-before-reveal rather than a [Shutter](https://shutter.network/)-style keyper-committee scheme, and in the simplest case the sender releases its own key, so no committee has to be trusted to decrypt. For the custodian, a desk could route a large rebalance without leaking who sent it or how much until ordering is fixed, and paired with [FOCIL](https://eips.ethereum.org/EIPS/eip-7805), the builder can neither read the transaction nor exclude it. |
There was a problem hiding this comment.
"style keyper-committee scheme" could be described as threshold encryption.
|
|
||
| None of these proposals removes regulatory visibility. Pre-trade confidentiality is part of best execution: an order that leaks before it fills has its execution quality compromised, and SEC Rule 15c3-5 market-access controls assume the venue is not leaking it against the client. Confidentiality of a redemption's amount and destination is data minimization, the principle behind GDPR Article 25, and the shielded-pool work's viewing keys still let a regulator audit. Sanctions screening and the conduct rules under MiCA keep running at the application layer, where an institution already runs them. Privacy here supports these obligations rather than amounting to legal compliance on its own, and any deployment still needs its own legal review. | ||
|
|
||
| ## Related work and references |
There was a problem hiding this comment.
https://ethresear.ch/t/a-criticism-of-lucid-and-encryption-scheme-agnostic-encrypted-mempool-designs/25210
https://ethresear.ch/t/lucid-encrypted-mempool-with-distributed-payload-propagation/24042
https://ethresear.ch/t/frame-transactions-and-the-three-gates-to-privacy/24666
https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870
Links to posts on the topic, for curious readers.
Meyanis95
left a comment
Meyanis95
left a comment
There was a problem hiding this comment.
Nice first draft.
My general feedback is that the post only highlights a specific path to enhance shielding from a protocol standpoint, but doesn't address the Ethereum roadmap in general, nor other privacy paths (wormholes, lean staking). Maybe the title can be rescoped to upcoming protocol EIPs that will harden shielding. Or, if the post is about the Ethereum roadmap in general for institutions, then it'd be cool to mention: PQ resistance, gigagas L1, teragas L2, fast finality, private L1 (native shielding).
2 participants
This pull request adds a comprehensive new blog post,
2026-07-02-ethereum-roadmap-for-institutions.md, outlining five major upcoming changes to the Ethereum protocol that are particularly relevant for institutional users. The post explains how each proposed change addresses current limitations around privacy, transaction inclusion, and censorship resistance, and provides guidance on how institutions can influence these protocol upgrades while they are still under active development.Key additions in the new post:
Ethereum protocol roadmap for institutions:
Institutional impact and guidance: