vitalik.eth

@VitalikButerin

If we want to make the Lean Ethereum consensus chain aggressively more "lean", and add strong validator privacy (ZK-unlink deposit from staking activity from withdrawal, and re-anonymize stakers every day), here is a path:

ethresear.ch

The Extremely Lean Chain

Special thanks to Emile, Potuz, Anders Elowsson for initial feedback and review. The goal of this post will be to show how the Ethereum consensus chain, in the context of “Lean” upgrades (single-slot...

2,454

7:30 AM • Jul 6, 2026

What are zkWormholes?

Ethereum addresses are created following these steps:

1. Pick a secret Elliptic Curve (EC) key $$s$$

2. Generate a public key $$pubK = G^s$$

3. Hash it using keccak $$h=keccak(pubK)$$

4. Slice the first 12 bytes and keep the last 20 bytes $$addr = slice_{12}(h)$$

In order to move funds from that address you have to sign a transaction with your key and the validator will perform the hashing and slicing to retrieve the address and authenticate it with the respective on-chain address.

zkWormholes use "burn addresses" where a user sends funds (native ETH or tokens) to an unspendable address generated by the following steps:

1. Chose a random secret $$s$$ or $$s | domain$$

2. Hash it using keccak $$h=keccak(s)$$

3. Slice the first 12 bytes and keep the last 20 bytes $$addr = slice_{12}(h)$$

As you can see there is not elliptic curve secret key capable of signing messages that will expose an elliptic curve public key. This means the address is unspendable, only the address generator knows this fact and the rest of the on-chain observers only see a normal-looking Ethereum address. When a user generates a burn address and sends funds to it, he is privately burning funds without disclosing it to the public observers.

After sending funds to the burn address, the user can generate a zk proof that they know secret $$s$$ that generates the burn address that received $$N$$ tokens without showing which burn address it is. The user can present this zk proof to a smart contract and mint new tokens to a fresh non-related Ethereum address, basically teleporting the funds from the burn address into the new fresh address.

It is worth pointing out that for this mechanism to work with native ETH, L1 changes (e.g. an EIP like EIP-7503) are required to be implemented. The zkWormholes mechanism can be used with other ERC20 tokens where the and burn and mint functions can be properly adapted. There is already a production private transfer protocol called WORM which uses zkWormholes in Ethereum mainnet.

Why zkWormholes are important for CROPS?

Censorship Resistance, Open-source, Privacy and Security (CROPS) are the crucial values for Ethereum in order to build a permissionless neutral world computer according to the Ethereum Foundation. In order to achieve privacy, a private transfer solution is required at the protocol level to covers anonymity, confidentiality and plausible deniability. The latter means the ability of users to hide the fact that they are using a private transfer solution at all.

Without plausible deniability, external organisations and governments can censor and block addresses that have interacted with any protocol they do not like. A clear example of it is the OFAC ban of all Ethereum addresses that ever interacted with the Tornado Cash contracts.

To achieve true CROPS, a plausible deniability private transfer solution is required and zkWormholes look like a strong candidate for it. There are another explorations like EVM bytecode obfuscation that rely on statistics rather than traditional cryptography, but are still in research and prototyping phase. For more information about it check out Mirage.

What are the challenges?

zkWormholes are not perfect and as some readers might have noticed by now, they could bring a huge security vulnerability in two different scenarios.

Scenario 1:

A burn address looks exactly the same as an Ethereum address but it is generated differently by computing $$addr = slice_{12}(keccak(s))$$ where $$s$$ is a random secret only known to the address creator. The number of Ethereum possible addresses (spendable and burn) is $$2^{160}$$ because each address is 20 bytes (160 bits) long.

According to the birthday problem, an attacker can theoretically find two different secrets $$s$$ and $$s'$$ that would produce the same 160 bits address $$addr$$ in around $$2^{160/2} = 2^{80}$$ tries. If the attacker succeeds, he would be able to mint "burned" tokens twice by presenting a zk proof with $$s$$ and another zk proof with $$s'$$ . The attacker will need a large enough computer that can compute $$2^{80}$$ hashes in a reasonable time frame and also a considerable amount of funds to be burn in a single transaction. These two requirements make the attack feasible only for wealthy stakeholders but not less important from a security perspective. Just imagine if some entity would be able to double ETH without anyone noticing it.

Scenario 2:

We can have additional steps to secure the generation process of secret $$s$$ with Proof of Work difficulty (as stated in the EIP-7503 rationale section) or longer secrets stored along side the transaction (data storage or Elliptic curve nonces).

Even though these solutions look promising, at the end of the day the collision problem persists because the Ethereum addresses are 20 bytes (160 bits) long and we have two different algorithms that can run in parallel in order to find the same address in around $$2^{80}$$ tries.

A malicious user could generate a normal Ethereum public address with its respective private key $$addr = slice_{12}(keccak(G^{s}))$$ that would also be an be computed as burn address with secret $$s$$ resulting in $$addr = slice_{12}(keccak(s))$$ . Here, the user will have control of the address' assets and will be able to prove to the minter contract that the address is a burn address allowing him to mint new tokens and move the "burned" tokens after it.

To summarize, zkWormholes using standard Ethereum addresses have a 80 bits of collision security. To increase this security, we need a new address longer than 20 bytes and we will lose the plausible deniability property because a burn transaction will be different than a normal transaction. A L1 protocol change from 20 bytes to 32 bytes will be needed if we wanted to keep the unlinkability and plausible deniability properties. EF's researchers wrote a technical post explain this issue in more detail. If you are a little bit lost on why the 20 bytes long addresses are a problem in zkWormholes but not in normal Ethereum setup you can check out my comment on the post.

What is the proposed solution?

So zkWormholes are not possible in Ethereum L1? Not quite. At the end of the "Wormholes and the cost of plausible deniability" post of the EF's researchers there is a possible path to implement zkWormholes at the protocol level by leveraging the validators public keys. The authors wrote a new proposal: Lean Staking EIP-8222.

The Ethereum protocol currently runs in two layers: the execution layer where the applications live (smart contracts, dApps, transfers) and the consensus layer where the validator logic lives (Proof of stake, BLS signatures, consensus, etc). In the former we use 20 bytes long Ethereum addresses and in the later we use 48 bytes long validator public keys. The current roadmap points to leanEthereum, a set of upgrades aiming to the consensus layer, and it is possible to fix the $$2^{80}$$ collision problem at that layer.

Users who want to perform a private-only transfer will use the validator deposit path to deposit into the zkWormhole and will exit with the validator withdrawal path without ever joining the validator set. The EIP proposes to change the current validator deposit and withdraw logic into a more privacy-preserving logic that will allow validators and private transfers users share the same entering and exiting lane.

As you can see by now Lean Staking is informally called lean zkWormholes because it tries to adapt the consensus layer deposit and withdraw paths (lean) with zkWormholes.

What is my opinion on zkWormholes

I am passionate about zkWormholes because of their plausible deniability property but at the same time have some concerns if it is shipped. The following points are strictly my opinion and can change with new arguments or research:

• Good: plausible deniability makes Ethereum more permissionless. It will harder for any entity to map down your activity and censor you depending on if you have used a privacy protocol or not.

• Good: zkWormholes can give pausible deniability to existing privacy protocols. They can be combined with other approaches (Railgun, Hinkal, Privacy Pools -- note-based shielded pools, Zama, Fhenix, Tongo -- homomorphic encryption) as a entry point method in order to enable plausible deniability.

• Bad: the lean Staking proposal is still in research phase and it could take years to be shipped to Ethereum L1 as native private transfers. There are some protocols like WORM and zERC20 already offering zkWormholes solutions at the application layer.

• Bad: Compliance might get messy. Today private transfers protocols offer compliance in different ways, some use Proof Of Innocence and others use Global Auditor keys. Integration of native private transfers in Ethereum L1 might cause some governments and stakeholders to censor and block all Ethereum activity because they would not be able to distinguish users. Today, without plausible deniability, this can happen only with addresses that have interact with specific protocols (e.g. Tornado Cash OFAC ban, Zama USDC freeze, etc.).

Thank you for your time reading this post. It took me a while to write it. If you are interested in learning about the Private Transfers ecosystem in Ethereum, check our dashboard here: https://private-transfers.pse.dev/

If you liked this post, follow me for more privacy related content. My X (former Twitter) is @NicoSerranoP.

Cover photo by NASA Hubble Space Telescope on Unsplash

There are multiple privacy protocols deployed on Ethereum at the moment (Privacy Pools, Railgun, Zama, Hinkal, etc.) and many more on the production pipeline (Mirage, Bermuda, Redact, etc.). End users have been using them for a while on the permissionless L1. The incoming wave of institutions to Ethereum will require privacy components. It is worth analyzing one of their key requirements: auditor keys.

Institutions will come on-chain in two ways: to use what the Ethereum ecosystem has to offer (e.g. DeFi, borderless transfers, decentralized voting) or to offer a product to the Ethereum ecosystem (e.g. Real World Assets (RWA), stablecoins transfers, etc.). In this post we will focus solely on the latter scenario where is important that institutions provide product or services following regulations that enforce user data privacy.

The challenge

Usually regulations ask for two things: end users data privacy and guardrails to prevent malicious actors. Institutions trying to comply lean towards the ability to examine data if a user is under investigation. Today this already happens in traditional digital systems (web2). Let's consider a bank that offers digital transfers through their mobile or web application. End user data is privately stored in the bank system infrastructure. Only the system administrator can see the transactions happening and can stop them or freeze accounts if required by law enforcement.

A similar on-chain product to the previous example is a permissioned private transfer protocol deployed and controlled by a particular institution. The following benefits over traditional systems would be:

• 24/7 system availability guaranteed by the underlying chain (e.g. Ethereum mainnet)

• Global accessibility and scalability while maintaining security through the Ethereum protocol.

• Exposure to other protocols and tools on the Ethereum ecosystem (e.g. DeFi)

The on-chain protocol can comply with the end user data privacy and the malicious actors gatekeeping by using different compliance methods but the most compelling one for institutions is selective disclosure through auditor keys.

The solution

Selective disclosure means that specific private data can be revealed in case law enforcement or auditors want to view it. This allows to maintain end user data private from on-chain observers and allow the administration entity to actively cooperate with regulators or law enforcement. There are two types of selective disclosure: voluntary selective disclosure or involuntary selective disclosure. Every development team implements it's own version but there are common patterns visible across different protocols.

Voluntary selective disclosure uses a public key pair per user. The protocol encrypts the transaction/interaction of a particular user using his own public key. This key is called a viewing key, it is separate from the spending key which allows the user to spend the funds. In case regulators ask access for a particular transaction or user's balance, the user has to actively collaborate with the protocol administrator and the regulator to reveal the requested data by providing his viewing key. This approach respects user privacy over regulations which is beneficial for most users but it can allows bad actors to refuse collaboration and continue using the protocol.

Involuntary selective disclosure uses a global viewing key. In every private transaction/interaction, the protocol encrypts the data with the user viewing key and with the global viewing key. These two ciphertexts are published on-chain so the user can find transfers related to him and the auditor can check all private transfers without users' explicit consent. This approach puts regulation and law enforcement over users individual data privacy because there is a global viewing key that allow access to all transactions from the protocol deployment date to the current date. 

Any form of selective disclosure is more appealing to institutions than other compliance mechanisms like Private Proof Of Innocence because it is similar on how traditional digital systems work. Institutions do not want to risk themselves in nascent innovation and prefer common already proved methods. Given that how can we make selective disclosure as private as possible?

Approaches

1. Voluntary selective disclosure using zk proofs: on the design above the user shares his private viewing key to auditors so they can check a specific transaction or set of transactions. The problem is that the auditor with the viewing key can see all user's transactional history. It is not bounded to a specific transaction. This can be solved by using zero knowledge (zk). Each transaction will encrypt the data with the user own public viewing key and when an auditor ask him to selective disclose a specific transaction, the user will download the encrypted object, decrypt it using his private viewing key and encrypt it with the auditor public viewing key. He will share the new encrypted object plus a zk proof that the decrypt-encrypt process was performed correctly. Using this approach the user will keep ownership of his transaction history while the auditor will be able to check a specific part of that history.

2. Involuntary selective disclosure through DKG: the described involuntary selective disclosure uses a single global viewing key pair that is stored by the auditor, administrator or any stakeholder depending on the protocol. This allows the auditor to check all transactions therefore user privacy could be rugged if the auditor shares any information with a third party. The centralization problem can be solved by splitting the private key between N parties. That way the transactions can only be decrypted if k parties agree on doing so (k < N). The ability to see all transactions is split between the N parties and they would need to collude in order to perform a decryption. This problem is called threshold encryption and the Distributed Key Generation (DKG) process generates a shared private key that no single individual have seen. Stoffel and Shutter Network are projects offering the infrastructure and development tooling to abstract away the complexity of threshold encryption and DKG.

Conclusion

Privacy is coming to institutions willing to go on-chain. I believe most of them will choose the global auditor viewing key mechanism in order to meet regulation and compliance. The discussion about the tradeoffs of this approach needs to happen sooner than later, otherwise we might end up with on-chain privacy solutions integrating a global viewing key that could affect end users privacy. I invite you to comment on this post or start a conversation in social media. In the crypto space the best approach to build long-lasting useful products is to build in public. If you liked this article please follow me in X (former Twitter): https://x.com/NicoSerranoP for future posts and discussions.

Cover photo by Ries Bosch on Unsplash

Ethereum, the world permissionless computer, is becoming popular among users who want to regain control over their finance and digital data. Nowadays every interaction with Ethereum is public and anybody can monitor what other users are doing. Privacy is a crucial component for building a trustless computer used worldwide and not a global panopticon that would enable total surveillance.

At the PSE team we worked in different aspects of on-chain privacy. My most recent role involved evaluating and benchmarking private transfers protocols (you can see a dashboard here). In my opinion private transfers are the atomic operation required to bring privacy on-chain but I was wondering what would be the next steps after users are able to successfully perform private transfers.

Lending protocols

My crypto experience started with learning about decentralized ledgers (Bitcoin, Ethereum, Polygon, etc.), investing into multiple assets (BTC, ETH, etc.) and later on learning cool stuff that I could do with those assets. One of the most revolutionary one was permissionless lending.

In a nutshell, a lending protocol allows a user to deposit collateral (e.g. ETH) and borrow any asset (e.g. USDT). This is called a lending position. The collateral value (ETH) would have to always be greater than the borrowed amount in order to protect the lenders assets (USDT). The user would be able to use USDT in anything he wants. The happy path would be the collateral increasing in value, because the user would still need to return only the borrowed amount and nothing more. The worst case path would be the collateral decreasing in value, because the protocol would sell the collateral in order to cover the borrowed amount. This action is called liquidation.

Now the question is how would a private lending position work? It would depend on the private transfer protocol and its tradeoffs. Let me expand with the most popular and production ready private transfers categories:

Notes-based private transfers for lending protocols

Notes-based private transfers use UTXOs (Unspent Transaction Output) like Bitcoin. Every time a user receives a private value, a note is assigned to him. In order to spend it he generates a ZK proof showing note ownership and also a nullifier that invalidates the note from being used again (prevent double spending). On the on-chain layer, these protocols keep funds in a shielded pool smart contract. Every transaction sends ZK proofs to the contract and the private state is updated.

To integrate notes-based private transfers protocols with a standard lending protocol (e.g. Aave or Morpho), the protocol needs to publicly deposit collateral funds and borrow assets. If multiple users want to use the lending protocol, the shielded pool contract will have different positions to its name. One contract will be the owner of several positions with different collaterals and different borrowed assets. This would create a huge liquidation risk that could affect conservative and risky users.

Another approach to do this would be to deploy one contract per position. The user would send a request to interact with the lending protocol and the notes-based protocol will deploy a single smart contract that would control the position. The risk will be isolate to each smart contract so users will not be affected by the decisions of other users. The tradeoff here is that the position itself will be public and visible. Nobody will know the position owner but everybody will be able to check the data and conclude the position strategy. In some cases the metadata (position amount, chosen assets, timing, etc.) could leak the owner identity.

Homorphic-encryption-based private transfers for lending protocols

Homomorphic-encryption (HE) based private transfers usually involve confidential transactions where the amount and balances are hidden but the sender and recipient are visible on-chain. These protocols could use simple HE schemes (e.g. Tongo Cash) or co-processors (e.g. Zama and Fhenix) to perform operations that sends tokens from one account into another.

To integrate HE-based private transfers protocols with a standard lending protocol, the former will need to be updated in order to understand and execute HE operations. For example a user would deposit a confidential wrapped token (cUSD) and borrow any available public asset. The position collateral amount will be private and the liquidation mechanisms would need to perform HE comparison operations (e.g. lessThan) in order to execute a liquidation if required.

There is progress on modifying and adapting lending protocols to use confidential tokens but it is not as straight forward as the other categories because the lending protocol is required to be adapted. In my opinion, private lending using HE will be the cleaner way to hide your position and strategies from on-chain observers.

Stealth addresses private transfers for lending protocols

Stealth addresses are single-use addresses that recipients will generate so senders can send assets to those unlinkable addresses. The recipient will later on be able to deploy smart accounts into those addresses and move the received assets around.

An integration of stealth addresses protocols with standard lending protocols would be straight forward. The smart accounts deployed on the stealth addresses are normal smart contracts that can interact with DeFi protocols like lending ones. If one of these smart accounts interact with the lending protocol, the unlinkability property will be intact but the position data will be public. This is the same tradeoff as notes-based protocols.

Conclusion

As you can see, there are multiple challenges and tradeoffs in implementing private lending protocols for end users that would like to have their position private from the on-chain observers. There are multiple teams and organizations tackling these challenges and the only comment I can be sure of saying is: Privacy is coming.

If you liked this article please follow me in X (former Twitter): https://x.com/NicoSerranoP . I am planning on writing more about Ethereum and the privacy layer. Thank you very much for reaching the end, I apologize in advance for not describing other interesting private transfers categories but in future writeups I will highlight them.

Cover photo by Nihar Bhagat on Unsplash