# Ethereum Privacy: The Road to Self-Sovereignty

_Special thanks go to [Paul Dylan-Ennis](https://x.com/post_polar_), [Tim Beiko](https://x.com/TimBeiko), and [Vitalik Buterin](https://vitalik.eth.limo) for feedback and review._

> Consider this roadmap a work in progress with many moving parts. Its primary goal is to offer a _tangible_ direction for building a **privacy-first Ethereum**, while each outlined approach demands its own discussion and research. You can share your feedback on this blog post in the discussion thread [here](https://ethresear.ch/t/ethereum-privacy-the-road-to-self-sovereignty/22115).

Ethereum must provide privacy **unconditionally**, without forcing users to prove their innocence.

This roadmap outlines the necessary steps to transform Ethereum into a **maximally private** and **self-sovereign** financial system. Privacy must not be an optional feature that users must consciously enable — it must be the **default state** of the network. Ethereum's architecture must be designed to ensure that users are private by default, not by exception.

Today, Ethereum operates in a partial, opt-in privacy model, where users must take deliberate steps to conceal their financial activities — often at the cost of usability, accessibility, and even effectiveness. This paradigm must shift. Privacy-preserving technologies should be deeply integrated at the protocol level, allowing transactions, smart contracts, and network interactions to be inherently confidential. A system that treats privacy as suspicious by default is fundamentally flawed. **Ethereum must empower users with unconditional privacy** — making self-sovereignty a guarantee, not a privilege.

## Principles of Sovereignty and Risk

Unconditional privacy comes with tradeoffs. It will be used by both the innocent and the malicious. But if privacy is granted only to those who can justify it — based on innocence, identity, or intent — then it is no longer a right. It's a permission. And permissions can be revoked.

This roadmap is rooted in the Cypherpunk belief that **freedom must never be weakened in the name of safety**. Privacy tools — like encryption, shielded transactions, and obfuscated smart contracts — are neutral. They do not create harm; they prevent it. Their misuse should be addressed by punishing harmful _actions_, not by restricting _access_ to the tools themselves.

As articulated in the [Open Access](https://hackmd.io/@pcaversaccio/the-ethereum-cypherpunk-manifesto#Open-Access) section of my [The Ethereum Cypherpunk Manifesto](https://hackmd.io/@pcaversaccio/the-ethereum-cypherpunk-manifesto), **essential tools and infrastructure — privacy included — must remain universally accessible**. A permissionless system cannot pick and choose which freedoms are acceptable to express. If we allow core technologies to be restricted based on how they might be misused, we risk ceding control to gatekeepers and undermining the very principles Ethereum was built upon.

> **We don't defend freedom by breaking it. We defend it by building stronger protections for the innocent, and holding the guilty accountable — without turning everyone into a suspect.**

This is the foundation of everything that follows. Each phase is not a technical milestone alone — it's a step toward a world where privacy is not a feature, not a favour, but a default.

## Status Quo

Currently, Ethereum's transparency model presents significant challenges to privacy. Publicly accessible transaction graphs allow anyone to trace the flow of funds between accounts, and balances are visible to all participants in the network, undermining financial privacy. While the Ethereum network's transparency fosters trustlessness, it also opens the door to potential surveillance, targeting, and exploitation.

The current state presents several specific technical challenges[^1]:

[^1]: Consider this list incomplete.

- **Address reuse:** The account-based model encourages address reuse, creating persistent identities tied to on-chain activity.
- **Public state:** All contract state variables are publicly readable, making truly private applications impossible without additional cryptography.
- **MEV vulnerability:** The transparent mempool enables Maximal Extractable Value (MEV) extraction primarily at users' expense.
- **Metadata leakage:** Network-level metadata, including IP addresses and transaction propagation patterns, can de-anonymise users even when using application-level privacy tools.

To address these issues, several privacy solutions have emerged within the Ethereum ecosystem:

- **[Tornado Cash](https://github.com/tornadocash):** A zk-SNARK-based mixer that obfuscates transaction trails by breaking the link between sender and receiver. While effective, Tornado Cash faces usability challenges and ongoing regulatory scrutiny (with a recent [win](https://ofac.treasury.gov/recent-actions/20250321)!), and its reliance on Ethereum's base layer makes it subject to the same public transparency issues.

- **[Aztec](https://aztec.network):** Aztec offers a Layer 2 privacy solution that leverages encrypted state mechanisms through their [Noir language](https://noir-lang.org) for zero-knowledge circuit development. This enables confidential transactions within its ecosystem while still allowing verifiability, although the adoption and scalability of Aztec are still evolving.

- **[RAILGUN](https://railgun.org):** RAILGUN leverages zero-knowledge proofs to shield transaction details but faces the limitation of needing broader adoption and integration across the Ethereum ecosystem. It also offers conditional privacy through [Private Proofs of Innocence](https://docs.railgun.org/wiki/assurance/private-proofs-of-innocence). Its [system architecture](https://docs.railgun.org/wiki/learn/privacy-system) utilises zk-SNARKs with [Groth16](https://eprint.iacr.org/2016/260.pdf) proofs and a smart-contract-based shielded pool model.

- **[Privacy Pools](https://privacypools.com):** Privacy Pools is another privacy solution, employing a multi-layered design with an upgradeable contract layer, a zero-knowledge layer, and an Association Set Provider (ASP) layer. Due to the ASP layer, it provides conditional privacy. As a relatively new project, its long-term success and integration impact are yet to be fully assessed, and like others, it faces usability and integration challenges as an application-layer solution.

> [!IMPORTANT]
> I have immense respect and gratitude for everyone working on privacy solutions, including those not mentioned here. Your contributions lay the foundation for this work — we're building on the shoulders of giants, and none of this would be possible without you!

These efforts represent valuable steps forward, but they are not fully integrated into the Ethereum base layer and remain limited in scope and scalability. Privacy is still largely a secondary feature, and a comprehensive, seamless solution that protects all aspects of Ethereum usage is still lacking.

## A Step-by-Step Roadmap to Privacy

To establish Ethereum as a **maximally private** and **self-sovereign** financial system, the roadmap takes a structured and incremental approach:

1. [**Phase 1:**](#Phase-1-Foundational-Transaction-Privacy) Foundational Transaction Privacy
2. [**Phase 2:**](#Phase-2-Private-ERC-20-and-ERC-721-Transactions) Private ERC-20 and ERC-721 Transactions
3. [**Phase 3:**](#Phase-3-Private-Smart-Contracts-amp-Execution) Private Smart Contracts & Execution
4. [**Phase 4:**](#Phase-4-Protocol-Level-Privacy-Integration-amp-Ordering) Protocol-Level Privacy Integration & Ordering
5. [**Phase 5:**](#Phase-5-Quantum-Resistant-Privacy-and-Finalisation) Quantum-Resistant Privacy and Finalisation

> [!NOTE]
> Private [ERC-20](https://eips.ethereum.org/EIPS/eip-20)/[721](https://eips.ethereum.org/EIPS/eip-721) transactions first could reduce protocol risk, but [Phase 1](#Phase-1-Foundational-Transaction-Privacy) is _foundational_: (1) ETH is the base asset — if ETH remains public, private [ERC-20](https://eips.ethereum.org/EIPS/eip-20)/[721](https://eips.ethereum.org/EIPS/eip-721) transactions still reveal links; (2) starting with ETH enables broader privacy adoption; (3) ETH privacy lays the groundwork for composable private assets. That said, prioritisation is flexible if private tokens prove more urgent.

### Phase 1: Foundational Transaction Privacy

The first step is to **shield native ETH transactions** and protect user activity before it is confirmed on-chain. This involves rethinking Ethereum's transaction model while securing both execution privacy and mempool privacy.

#### 1. Confidential ETH Transactions

- **Rethinking transaction formats:** Introduce a new transaction structure supporting privacy natively. Transactions should obscure sender, recipient, and amounts while remaining compatible with Ethereum validation. EIPs like [EIP-7503](https://eips.ethereum.org/EIPS/eip-7503) (`WormholeTxType`) offer potential foundations for generalisation.
- **Zero-knowledge proofs (ZKPs):** Utilise [zk-SNARKs](https://ethereum.org/en/zero-knowledge-proofs/#zk-snarks) to validate transactions without revealing inputs, maintaining Ethereum's security while enabling privacy (e.g., proving sufficient funds without revealing balances).
- **Sealed amounts and addresses:** Employ cryptographic commitments like [Pedersen commitments](https://link.springer.com/content/pdf/10.1007/3-540-46766-1_9.pdf) to encrypt transaction values. Implement native stealth addresses (building beyond [EIP-5564](https://eips.ethereum.org/EIPS/eip-5564)) to generate one-time recipient addresses, disrupting blockchain analysis.
- **Mana (aka gas[^2]) privacy:** Obfuscate mana usage patterns, which can leak information even with confidential transactions. Explore techniques like _randomised fee structures_ or _dummy mana consumption_.
- **Seamless integration:** Ensure Ethereum clients (e.g., [Geth](https://github.com/ethereum/go-ethereum)) can efficiently verify the necessary zero-knowledge proofs. Leverage Account Abstraction ([EIP-4337](https://eips.ethereum.org/EIPS/eip-4337)) to allow smart contract wallets to manage privacy features automatically for users.
- **Efficiency considerations:** Zero-knowledge circuits must be highly optimised for performance (proving time, proof size, verification cost) to be practical in real-world applications. At the same time, they must preserve strong auditability and verifiability, enabling independent inspection, formal analysis, and compatibility with evolving protocol standards. These circuits must efficiently prove _ownership, balance consistency, and transaction validity_ under strict cryptographic soundness guarantees. Tools like [ZoKrates](https://zokrates.github.io), [`snarkjs`](https://github.com/iden3/snarkjs), and [Circom](https://docs.circom.io) provide a foundation for building such systems. The overarching goal is to minimise user friction and performance overhead without compromising trust assumptions or protocol transparency.

[^2]: See [EIP-6789](https://eips.ethereum.org/EIPS/eip-6789).

#### 2. Encrypted Mempool

- **Threshold encryption:** Transactions should remain encrypted while propagating through the mempool. A [threshold scheme](https://web.mit.edu/6.857/OldStuff/Fall03/ref/Shamir-HowToShareASecret.pdf) can ensure decryption only occurs upon block inclusion via validator consensus, preventing single points of failure or censorship.
- **MEV mitigation via encryption:** Encrypting transaction details until near execution significantly hinders common forms of MEV like front-running and sandwich attacks.
- **Early commit-reveal mechanisms:** Explore cryptographic commit-reveal schemes where transactions commit to their actions without revealing details until inclusion, reducing validators' ability to reorder for profit.
- **Inspiration from existing research:** Build upon research like [Shutter Network's encrypted mempool concepts](https://docs.shutter.network/docs/shutter/research/the_road_towards_an_encrypted_mempool_on_ethereum).

#### 3. Early MEV Protection & Network Privacy

- **Enhanced proposer-builder separation (PBS):** Implement PBS designs with _privacy-enhanced_ relays that offer stronger confidentiality guarantees than initial versions (e.g., [Flashbots Protect](https://protect.flashbots.net)).
- **Network-level anonymity:** Integrate or encourage protocols like [Dandelion++](https://dl.acm.org/doi/pdf/10.1145/3292040.3219620) to obscure transaction origins at the peer-to-peer level, mitigating IP address tracing and censorship. Consider integration with mixnets like [Nym](https://nymtech.net) for stronger guarantees.
- **Decoy traffic & mixing:** Explore wallet-level strategies like sending _decoy transactions_ or participating in _background mixing_ to further obfuscate real user activity patterns.

#### 4. UX & Wallet Integration

- **Invisible privacy defaults:** Privacy features should be enabled by default in wallets wherever feasible. Users should not need to be cryptography experts to benefit. Wallets must handle stealth address generation, encryption, and proof generation _automatically_.
- **Seamless onboarding:** Integrate privacy tools into popular existing wallets (e.g., MetaMask, Rabby) via Snaps, SDKs, or native integration, rather than forcing users onto niche, privacy-only wallets.
- **User-friendly recovery:** Develop secure and usable recovery mechanisms for private accounts/keys, exploring options like [social recovery](https://vitalik.eth.limo/general/2021/01/11/recovery.html) adapted for privacy contexts.
- **Education:** Clearly communicate the benefits and workings (at a high level) of privacy features to users and developers to foster understanding and adoption.

> **Phase 1 rethinks Ethereum's transaction model for initial privacy layers.** Hiding on-chain details is insufficient if the mempool and network layers leak metadata. By combining confidential transactions, initial mempool encryption, basic MEV resistance, and network anonymity — alongside vital UX improvements — Phase 1 lays the groundwork for **end-to-end privacy**.

### Phase 2: Private ERC-20 and ERC-721 Transactions

With foundational ETH privacy underway, the next step is **extending privacy guarantees to token transfers**. This phase ensures both fungible ([ERC-20](https://eips.ethereum.org/EIPS/eip-20)) and non-fungible ([ERC-721](https://eips.ethereum.org/EIPS/eip-721)) assets benefit from confidentiality, protecting user balances, transfers, and ownership metadata. Importantly, this is not just a natural extension — it's critical for ETH privacy to succeed in practice. Without privacy-preserving equivalents for widely used tokens (e.g. [`WETH`](https://etherscan.io/address/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2)), applications and exchanges may default to accepting only public assets, undermining the broader goal of end-to-end privacy.

#### 1. Confidential ERC-20 Transactions

- Develop a standard (i.e., via EIP) for private fungible token transfers, potentially extending concepts from past proposals like [ERC-1724](https://github.com/ethereum/EIPs/issues/1724) but using modern zk-SNARK constructions (e.g., [PlonK](https://eprint.iacr.org/2019/953.pdf), [Halo2](https://zcash.github.io/halo2)) leveraging nullifiers and commitments for efficiency and security. This standard should provide a migration path for existing tokens, allowing them to opt into privacy pools seamlessly, preserving liquidity while ensuring privacy.
- Implement confidential asset transfers akin to protocols like [Zcash's Sapling](https://z.cash/upgrade/sapling), using nullifiers to prevent double-spending and cryptographic commitments to hide amounts, ensuring transaction unlinkability.
- Standardise commitment schemes and efficient range proofs (using constructions like those in [PlonK](https://eprint.iacr.org/2019/953.pdf) or [Halo2](https://zcash.github.io/halo2)) for token amounts to improve verification efficiency.
- Encourage the development of shielded pools with large, growing privacy sets (aiming for >10,000 users initially) to provide meaningful anonymity guarantees.

#### 2. Shielded NFT Ownership and Transfers

- Design a standard (i.e., via EIP) for private [ERC-721](https://eips.ethereum.org/EIPS/eip-721) transfers that conceals ownership links and transaction history, allowing NFTs to be held and transferred discreetly. This standard should provide a seamless migration path for existing NFTs, allowing them to opt into privacy pools or shields, preserving liquidity while ensuring privacy.
- Utilise zero-knowledge proofs for verifying NFT ownership or attributes without revealing the owner's identity publicly.
- Explore Merkle-based ownership registries where users can prove ownership via zk-proofs of inclusion, similar to [Zcash's note commitment tree](https://zips.z.cash/protocol/protocol.pdf#merkletree), ensuring private yet verifiable ownership.

#### 3. Layer 2 Privacy Enhancements

- Standardise private state transitions in rollups, perhaps via a common interface like [zkInterface](https://github.com/QED-it/zkinterface), to enable consistent cross-layer privacy guarantees.
- Promote native support in zk-Rollups for confidential transactions, leveraging privacy-preserving validity proofs for scalable and efficient private transfers.
- Enable private cross-rollup transfers using standardised [SNARK-friendly hash functions](https://github.com/iden3/circomlib) and commitment schemes.
- Design privacy-preserving bridges between L1 and L2s, and between different L2s, potentially using shared anonymity set models where feasible.
- Ensure Layer 2 solutions can leverage Ethereum's evolving data availability layers (e.g., [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) blobs) cost-effectively for publishing the data needed for private state proofs.

> **Phase 2 builds on [Phase 1](#Phase-1-Foundational-Transaction-Privacy) by extending privacy from native ETH transactions to all tokenised assets**. With confidential [ERC-20](https://eips.ethereum.org/EIPS/eip-20) transfers, shielded NFT ownership, and privacy-focused Layer 2 standards, this phase aims for comprehensive token privacy across Ethereum and its scaling ecosystem.

### Phase 3: Private Smart Contracts & Execution

With transaction and token privacy established, the next critical step is enabling **private computation** on Ethereum. This phase focuses on allowing smart contracts to execute confidentially, protecting sensitive inputs and state while maintaining verifiability.

#### 1. Confidential Smart Contract Execution

- Introduce execution environments where contract logic execution and state updates remain private from the public, yet can be proven correct to the network.
- Explore mid-term solutions like zero-knowledge Virtual Machines (zkVMs) that can prove the execution of specific computation, potentially using systems inspired by [RISC Zero](https://www.risczero.com) which avoid trusted hardware assumptions.
- Develop long-term full zkEVM implementations, building on work from projects like [Aztec](https://aztec.network), [Polygon zkEVM](https://github.com/0xPolygonHermez/zkevm-prover), [Scroll](https://scroll.io), [ZKsync](https://zksync.io), or [Starknet](https://www.starknet.io), aiming for universal privacy for arbitrary smart contracts.
- Ensure mechanisms allow for private state updates and confidential interactions between contracts or users and contracts.

#### 2. Smart Contract Logic Privacy

- Explore techniques for obfuscating[^3] contract bytecode or using cryptographic methods to prevent easy reverse-engineering of contract logic by adversaries.
- Utilise cryptographic commitments and zero-knowledge proofs to allow users or systems to verify _correct_ execution according to a specific (but hidden) contract logic.
- Develop methods for [zkSNARK-based contract verification](https://eprint.iacr.org/2022/1355.pdf) where a proof attests that a contract executed correctly, without revealing the execution trace or intermediate states.
- Foster standardised libraries (similar to [OpenZeppelin Contracts](https://github.com/openzeppelin/openzeppelin-contracts)) for common DeFi primitives (swaps, lending, etc.) with built-in, audited privacy-preserving implementations.
- Model privacy-preserving contract development frameworks on languages designed for ZKPs, like [Noir](https://noir-lang.org) or [Leo](https://leo-lang.org), to simplify development.

[^3]: For an intro to cryptographic obfuscation, see [here](https://www.iacr.org/archive/crypto2001/21390001.pdf) and [here](https://eprint.iacr.org/2013/454.pdf). More recent work is [here](https://eprint.iacr.org/2019/463.pdf) and [here](https://eprint.iacr.org/2020/394.pdf). For Ethereum's use case, see, e.g., [this post](https://ethresear.ch/t/how-obfuscation-can-help-ethereum/7380).

#### 3. Privacy Precompiles

> [!NOTE]
> I find myself genuinely conflicted about proposing new precompiles. On the one hand, the mana costs for the cryptographic operations needed for deep privacy (especially things like ZKP verification) are a huge barrier on L1, and precompiles are the most direct solution for efficiency. On the other hand, I'm fully behind the push to simplify Ethereum's core protocol, as exemplified by [The Purge](https://vitalik.eth.limo/general/2024/10/26/futures5.html), and adding more precompiles is counter to that spirit. My hope is that we can find clever ways around this, perhaps through future EVM enhancements or by architecting solutions primarily on Layer 2, but it's not immediately clear how to achieve the needed performance without some form of L1 support.

- Introduce EVM precompiles for verifying common zk-SNARK schemes (e.g., [Groth16](https://eprint.iacr.org/2016/260.pdf), [PlonK](https://eprint.iacr.org/2019/953.pdf), [Halo2](https://zcash.github.io/halo2)) to drastically reduce the mana cost of on-chain proof verification.
- Consider adding precompiles for basic Fully Homomorphic Encryption (FHE) operations or Secure Multi-Party Computation (MPC) primitives (inspired by libraries like [MPyC](https://github.com/lschoe/mpyc)) to enable different forms of collaborative confidential computation.
- Ensure these precompiles are mana-optimised implementations of well-vetted, secure cryptographic operations.

> **Phase 3 ensures Ethereum's programmability extends into the private domain.** By enabling confidential execution, protecting contract logic, and providing efficient cryptographic primitives via precompiles, this phase paves the way for a rich ecosystem of private applications and DeFi without sacrificing security or composability.

### Phase 4: Protocol-Level Privacy Integration & Ordering

At this stage, privacy transitions from an application-layer or optional feature into a **core aspect of Ethereum's protocol design**. Privacy mechanisms become default where possible, trust-minimised, and deeply embedded at the consensus and execution layers, including how transactions are ordered.

#### 1. Protocol-Native Shielded Pools

- Integrate shielded pool functionalities directly into the protocol, allowing users to move assets into fully confidential state managed by Ethereum itself.
- Utilise efficient data structures like incremental Merkle trees for tracking committed values without revealing them, optimised for protocol-level performance.
- Implement robust nullifier-based double-spend prevention directly within the protocol logic, inspired by mature systems like [Tornado Cash's implementation](https://github.com/tornadocash/tornado-core) or [Zcash](https://github.com/zcash/zcash).
- Explore designs for cross-asset or purpose-specific shielded pools managed by the protocol to maximise anonymity sets and usability.

#### 2. Private Cross-Layer Operations

- Establish standardised, secure, and privacy-preserving bridge protocols between Ethereum L1 and Layer 2 solutions, potentially using zero-knowledge proofs to verify state transitions without revealing user data.
- Implement confidential deposit and withdrawal mechanisms between layers that obscure the link between L1 and L2 addresses involved in the transfer.
- Utilise standardised ZKP formats for cross-layer state proofs to ensure interoperability and security.
- Aim for a unified or shared anonymity set model across layers where feasible to prevent fragmenting user privacy.

#### 3. Private and Fair Order Flow

- Build upon early encrypted mempool work ([Phase 1](#Phase-1-Foundational-Transaction-Privacy)) to implement robust protocol-level solutions for private transaction ordering. This includes _sealed-bid auctions_ for block space, potentially using threshold encryption or commit-reveal schemes, ensuring proposers cannot front-run or sandwich based on full transaction content.
- Integrate fair ordering protocols, potentially based on [Verifiable Delay Functions (VDFs)](https://www.vdfalliance.org) or other cryptographic sortition techniques, to prevent proposer censorship or malicious reordering.
- Design and implement cryptoeconomic mechanisms (e.g., slashing conditions) to strongly disincentivise validators or builders from attempting to break privacy or fairness guarantees.
- Refine commit-reveal schemes with threshold decryption, ensuring transaction contents are only revealed immediately before execution or after ordering is finalised.

> **Phase 4 solidifies Ethereum's privacy as protocol-native, not merely an application-layer feature.** With deeply integrated shielded pools, secure private cross-layer operations, and robust private, fair order flow mechanisms, Ethereum transitions towards being a privacy-first execution environment by default, while preserving scalability and decentralisation.

> [!NOTE]
> To clarify any ambiguity regarding the scopes: [Phase 1](#Phase-1-Foundational-Transaction-Privacy) focuses on making individual ETH transactions private and provides initial mempool/MEV protection. [Phase 4](#Phase-4-Protocol-Level-Privacy-Integration-amp-Ordering) elevates privacy to a core protocol function, integrating features like native shielded pools for assets, standardised private cross-layer operations, and robust protocol-level mechanisms for private and fair transaction ordering (advanced MEV resistance). TL;DR: [Phase 1](#Phase-1-Foundational-Transaction-Privacy) = Private ETH transactions & initial protections; [Phase 4](#Phase-4-Protocol-Level-Privacy-Integration-amp-Ordering) = Protocol-native private execution environment & robust ordering.

### Phase 5: Quantum-Resistant Privacy and Finalisation

> [!TIP]
> This section focuses on post-quantum privacy. For a broader overview of the general technical tasks required to make the entire Ethereum protocol quantum-resistant, see the discussion [here](https://ethresear.ch/t/tasklist-for-post-quantum-eth/21296).

As quantum computing capabilities advance, Ethereum's cryptographic foundations — especially those underpinning privacy — must be future-proofed. This phase focuses on **migrating to post-quantum cryptographic primitives**, implementing a fully private zkVM, and performing final optimisations to ensure long-term robustness.

#### 1. Post-Quantum Cryptographic Migration

- Plan and execute a transition from current elliptic curve cryptography (ECDSA signatures, pairings in SNARKs) to quantum-resistant alternatives. For signatures, consider NIST standards like [CRYSTALS-Dilithium](https://pq-crystals.org/dilithium) or [SPHINCS+](https://sphincs.org).
- Design a phased migration strategy allowing legacy and quantum-resistant accounts/contracts to coexist, minimising disruption. Account abstraction could facilitate this.
- Implement quantum-resistant signature aggregation schemes to manage the potentially larger sizes of post-quantum signatures.
- Replace potentially vulnerable zk-SNARK systems (especially those relying on pairings or discrete logs) with quantum-resistant constructions, such as those based on lattices or secure hashes (like zk-STARKs).
- Provide clear migration paths and tooling for existing applications and privacy solutions (like L2s) to adopt post-quantum cryptography.

#### 2. Full zkVM Implementation

- Develop and integrate a general-purpose zkVM capable of proving the correct execution of arbitrary EVM/smart contract logic privately. This means both state transitions _and_ the executed logic remain confidential from the public network. Build upon maturing research and implementations from projects like [Risc0](https://github.com/risc0/risc0), [Polygon Miden](https://github.com/0xPolygonMiden), and others exploring STARK-based or similar quantum-resistant ZK proof systems.
- Ensure the zkVM leverages quantum-resistant proof systems (like zk-STARKs), which often offer transparency (no trusted setup) as a bonus.
- Optimise ZK circuit generation and proving for EVM opcodes and common smart contract patterns, aiming for competitive proof generation times (e.g., ideally sub-5 seconds for typical transactions).
- Create mature developer tooling and high-level languages (building on ideas from [Noir](https://noir-lang.org) etc.) specifically designed for privacy-first smart contract development on the zkVM.

#### 3. Privacy Hardening and Optimisation

- Implement cutting-edge optimisations for existing (pre-quantum migration) proof systems like [PlonK](https://eprint.iacr.org/2019/953.pdf) and [Halo2](https://zcash.github.io/halo2) (e.g., recursion, aggregation techniques like [Nova](https://eprint.iacr.org/2021/370)) to minimise proof sizes and on-chain verification costs.
- Continuously optimise STARK-based proving systems to improve proof size and verification efficiency, keeping them competitive with SNARKs.
- Encourage development and standardisation of hardware acceleration (FPGA/ASIC) for core cryptographic operations (both pre- and post-quantum) to reduce proving times for users and provers.
- Further optimise mana costs for privacy-related operations through the EIP process, ensuring private transactions remain economically viable.
- Develop comprehensive test suites, formal verification methods, and ongoing audits for all privacy protocols integrated into Ethereum.

> **Phase 5 ensures Ethereum's privacy stack remains secure and efficient long-term, even in a post-quantum world.** By migrating critical cryptography, enabling fully private and universal smart contract execution via a zkVM, and relentlessly optimising performance, Ethereum can maintain robust privacy guarantees while remaining scalable and secure for the future.

## The Path Forward

Privacy is not optional; it is the backbone of self-sovereignty and digital freedom. Achieving this vision requires a concerted, sustained effort from developers, researchers, cryptographers, and the broader Ethereum community.

The roadmap outlined here presents a phased, technically grounded approach, leveraging existing research and proposing future directions. However, realising this vision demands more than just technical breakthroughs; it necessitates careful consideration of **how** such a significant focus on privacy integrates with Ethereum's ongoing development roadmap and governance processes.

**A critical discussion point is how this privacy-first direction aligns with existing priorities like the [The Merge](https://vitalik.eth.limo/general/2024/10/14/futures1.html), [The Surge](https://vitalik.eth.limo/general/2024/10/17/futures2.html), [The Scourge](https://vitalik.eth.limo/general/2024/10/20/futures3.html), [The Verge](https://vitalik.eth.limo/general/2024/10/23/futures4.html), [The Purge](https://vitalik.eth.limo/general/2024/10/26/futures5.html), and [The Splurge](https://vitalik.eth.limo/general/2024/10/29/futures6.html).** Does adopting this renewed emphasis mean revisiting the current roadmap to elevate privacy? Or could this function as a distinct, parallel development track, perhaps akin to a new "Privacy Pillar", aligning with evolving ideas about structuring core development (such as the concept of more parallelised workstreams discussed within the community, e.g., [Tim Beiko's post on reconfiguring AllCoreDevs (ACD)](https://ethereum-magicians.org/t/reconfiguring-allcoredevs/23370))?

Furthermore, the scale and specialised nature of this undertaking might benefit from dedicated coordination efforts. Could focused working groups, similar in spirit to the [Robust Incentives Group (RIG)](https://github.com/ethereum/rig) or potentially structured as distinct initiatives, be necessary to drive the research, specification, and implementation phases effectively? Drawing inspiration from ZK teams not directly focused on privacy, such as [0xPARC](https://0xparc.org) and [PSE](https://pse.dev), could offer valuable insights into how specialised efforts can be structured for maximum impact. Addressing these organisational and procedural questions is vital for turning the technical vision into reality.

**The optimal path for integrating this privacy focus — be it through reprioritisation, parallel tracks, dedicated groups, or other means — is deliberately left as an open question in this roadmap. Finding the answer requires thorough discussion and consensus building within the broader Ethereum community.**

Ultimately, whether this roadmap represents a reprioritisation, a new parallel effort, or a catalyst for evolving governance itself, its implementation path requires broad community discussion and consensus. While specific protocol changes will proceed through the established EIP process, the strategic integration of this privacy focus needs buy-in and rigorous review at every level. Challenges around usability, interoperability with the transparent world, and user education must be tackled concurrently with these governance considerations.

With a shared commitment — both technical and procedural — **privacy can (and must) become an inherent part of Ethereum's DNA**. The time to build this future, and determine _how_ we build it collectively, is now.

Let's make Ethereum Cypherpunk again!