Title: EIP_7503__Zero_Knowledge_Wormholes___Private_Proof
Category: EIPs

Author: keyvank
Date: 2023-08-16T14:13:49.933Z

Abstract
While researching on privacy solutions and applications of ZKP, we discovered a technique,
by which people can burn their digital asset (E.g ETH) by sending it to an unspendable address,
and later build a ZK proof showing that some amount of tokens reside in an account that are
unspendable, without revealing the account.
The EIP proposes to add a minting functionality to Ethereum, so that people can re-mint
Ethers they have purposefully burnt. The mentioned privacy solution will bring strong levels of
plausible deniability for the sender, since there is no way one can prove that the sender
has been participating in a privacy protocol. This will also make an anonymity pool that includes
all of the Ethereum accounts with zero outgoing transactions by default.
Specification
In Elliptic-Curve based digital signatures, normally there is a secret scalar s, from which
a public-key is calculated (By multiplying the generator point with the scalar: s * G). An
Ethereum EOA-address is the keccak hash of a public-key.
Also, the funds in an Ethereum address might be spendable by a smart-contract, if the keccak hash
of the smart-contract’s parameters is equal with that address.
Therefore, an Ethereum address A is spendable if and only if:

A private-key s exists. such that A = keccak(s * G).
There exists a smart-contract c, such that A = keccak(c_params).

The preimage resistance property of hash functions implies that, you can’t find x where keccak(x)=r,
in case r is a random value. So the funds sent to a random Ethereum address r is unspendable, but
how can other people be sure that r is indeed random and not the result of calculating s * G?
A great source of randomness is a hash function. If the address is equal with the hash of a secret preimage
s, we can conclude that the address is unspendable, since there isn’t a polynomially bounded algorithm
to find x where keccak(x)=h(s). This is only true if the second hash function is a different hash
function, and it assumes it is impossible to find x_1 and x_2 such that h_1(x_1)=h_2(x_2) in case
h_1 and h_2 are different hash functions.
Using the help of Zero-Knowledge proofs, we can hide the value of s! We just need to prove that
we know a secret value s where the address is h(s). We can go even further. We can prove
that an Ethereum accounts exists in the state-root, which holds some amount of ETH and is unspendable.
By revealing this to the Ethereum blockchain and providing something like a nullifier
(E.g. h(s | 123) so that double minting of same burnt tokens are not possible), we can add a new
minting functionality for ETH so that people can migrate their secretly burnt tokens to a
completely new address, without any trace on the blockchain. The target addresses can also be burn
addresses, keeping the re-minted funds in the anonymity pool.
Rationale
Cryptocurrency mixers like TornadoCash can successfully obfuscate Ethereum transactions, but it’s
easy for the governments to ban usage of them. Anybody who has interactions with a mixer contract,
whether the sender or receiver, can get marked. However this EIP tries to minimize the privacy leakage
of the senders, by requiring zero smart-contract interactions in order to send money, so
we only use plain EOA-to-EOA transfers. In order to have a “teleportation” mechanism we divide
the set of all Secp256k1 points E(K) into two subsets/address-spaces:

The spendable address-space: {p \in {0,1}^160 | \exists s : keccak(s * G)=p OR \exists c : keccak(c_params)=p }
The unspendable address-space: {p \in {0,1}^160 | \nexists s : keccak(s * G)=p AND \nexists c : keccak(c_params)=p }

The spendable/unspendable addresses are not distinguishable, so we can exploit this fact and define
a spendability rule for the money sent to addresses that can’t be spent using regular elliptic-curve
signatures. Using the help of Zero-Knowledge proofs, we can hide the transaction trace and design
a new privacy protocol, which is what this EIP is proposing.
Scalability Implications
In case the circuits are able to simultanously re-mint the sum of multiple burns in a single-proof,
merchants and CEXs will be able to accept their payments in burn-addresses and accumulate their funds
in a single address by storing a single proof (And a bunch of nullifiers) on the blockchain, which
significantly reduces the transaction count on the blockchain. The people who will use this EIP as a
scalability solution, will also increase the privacy guarantees of the protocol.
Backwards Compatibility
The Ethers generated using the mint function should not have any difference with original Ethers.
People should be able to use those minted Ethers for paying the gas fees.
Reference Implementation
A reference implementation is not ready yet, but here is a design:

We will need to track all of the ETH transfers that are happening on the blockchain (Including those initiated by smart-contracts), and add them to a ZK-friendly Sparse-Merkle-Tree. The amount sent should also be included in the leaves.
We will need a new transaction type responsible for minting Ethers. The initiator should provide a proof (Along with a nullifier) that proves he owns one of the leaves in the merkle-tree that has specific amount of ETHers

Alternatively, we can use the already maintained state-trie and provide merkle-patricia-trie proofs, showing
that there exists some amount of ETH in an unspendable account, and mint them.
Security Considerations
In case of faulty implementation of this EIP, people may mint infinite amount of ETH, collapsing the price of Ethereum.

Author: Mani-T
Date: 2023-08-17T08:48:47.092Z

This approach could lead to increased trust in stablecoins, as it provides a means of verifiable backing without relying on a centralized authority. This is brilliant.

Author: keyvank
Date: 2023-08-17T11:33:33.179Z

Exactly, but unfortunately, it’s a one-way cryptographic wormhole. The secondary token can never be converted back to the original token. (It’s like privately moving your asset to another universe, and there is no way back)

Author: Jamasp
Date: 2023-09-03T08:57:00.407Z

I think the applications are yet to be fully contemplated, but IMO the USDT-BUSDT example is not a good one; since the BUSDTs are not redeemable, and also can not be transferred back to USDT (so that again be redeemable), and this renders them worthless.

Author: MicahZoltu
Date: 2023-09-11T08:51:04.809Z

While I would rather see this as part of the base layer, one could create a WETH contract where withdraws required a proof of WETH burn to redeem for ETH, rather than returning the original WETH token(s).
This would be far less useful though as it is quite uncommon for people to send anything other than ETH to an otherwise empty account.  Since you need gas to do anything, ETH is always the first (and sometimes only) thing sent to a new address.

Author: JXRow
Date: 2023-09-18T15:09:19.451Z

“we can prove that some EOA-to-EOA transaction has happened in the previous blocks”
How to prove ? Using EOA’s signature ?

Author: keyvank
Date: 2023-09-18T15:35:16.345Z

Given that we have the block-hashes of the previous blocks in EVM, we can feed it as a public-input to a ZK circuit, which verifies a Merkle-Patricia-Trie proof (Of the transaction-tree), convincing us that a specific transaction has been included in a block (Without showing the TX). We can additionally check the Tx’s signature but that’s not necessarily needed, since a transaction is only included when its signature is valid.

Author: JXRow
Date: 2023-09-19T16:28:27.447Z

But how do ChainB know the previous block of ChainA, you can prove the tx is included in the block, but how to prove in ChainB that the block of ChianA exist indeed?

Author: MicahZoltu
Date: 2023-09-20T11:59:05.417Z

keyvank:

Given that we have the block-hashes of the previous blocks in EVM


We currently only have the last 128 blockhashes in the EVM.  There is a stagnant EIP somewhere that proposes storing all blockhashes in state, which would be necessary for this to work.  Presumably if this went through then that EIP also would go through as a dependency.



 JXRow:

But how do ChainB know the previous block of ChainA, you can prove the tx is included in the block, but how to prove in ChainB that the block of ChianA exist indeed?


This proposal is for within Ethereum only, not for cross-chain transfers.  You burn some ETH on Ethereum, and then later you can mint an equivalent amount of ETH on Ethereum.  The cleverness of this solution is that all accounts with ETH in them and no transactions are part of the anonymity set until the ETH moves.

Author: MicahZoltu
Date: 2023-09-20T12:08:38.165Z

One downside of this strategy is that the anonymity set shrinks over time.  If you mint at block 20,000,000, then your anonymity set is all accounts with ETH and no transactions where the ETH was transferred into the account after this change goes live and before block 20,000,000.  However, over time the set of accounts where the ETH doesn’t move will trend towards only those which were actual burns, thus your anonymity set ends up (eventually) being similar to contract layer tools like Tornado.
The one exception is ETH that is mistakenly sent to a wrong address (e.g., typo).  This ETH will stay in your anonymity set forever.  Unfortunately for this protocol (and fortunately for everyone else) the number people who accidentally burn their ETH by sending to a non-existent account is quite small.  Losing private keys is slightly more common, but still pretty rare and such accounts usually have transactions.
That being said, this protocol still provides some amount of plausible deniability in that you can claim that ETH you burned was either sent to a wrong address, you lost the keys, or you have the keys but are unwilling to share them.  Unlike Tornado, burning your ETH through this protocol doesn’t give away that you used the protocol at all.  Only withdrawing proves that you used the protocol in the past.

Author: keyvank
Date: 2023-09-21T20:00:00.577Z

MicahZoltu:

We currently only have the last 128 blockhashes in the EVM. There is a stagnant EIP somewhere that proposes storing all blockhashes in state, which would be necessary for this to work. Presumably if this went through then that EIP also would go through as a dependency.


If this is going to be implemented on the base layer, then I think the best option is to not rely on EVM-providen roots, and build and maintain an additional tree with a ZK-friendly hash function on Ethereum clients.



 MicahZoltu:

One downside of this strategy is that the anonymity set shrinks over time. If you mint at block 20,000,000, then your anonymity set is all accounts with ETH and no transactions where the ETH was transferred into the account after this change goes live and before block 20,000,000. However, over time the set of accounts where the ETH doesn’t move will trend towards only those which were actual burns, thus your anonymity set ends up (eventually) being similar to contract layer tools like Tornado.


This is actually very convincing and sad, I thought the anonymity set would be bigger.

Author: MicahZoltu
Date: 2023-09-22T05:25:52.019Z

keyvank:

This is actually very convincing and sad, I thought the anonymity set would be bigger.


I agree it is unfortunate.  The plausible deniability is still incredibly valuable though.  You don’t get that with tools like Tornado.

Author: MicahZoltu
Date: 2023-09-28T18:49:57.891Z

The scalability idea from the slide deck presented at ACD should be added to the EIP, or perhaps a second EIP that depends on this one could “extend” it.


A CEX can accept deposits in burn-addresses and re-mint the sum of them in a single proof.
This way, a single nullifier will be stored on Ethereum client’s database instead of a complete TX.


Of note, this isn’t just for CEXs.  This would potentially be useful for anyone who sets up a unique recipient address for each payer including payment processors, merchants, etc.
Also worth noting: it would allow a merchant to accept payments without the payer being associated with the seller on chain.  The payers would all just send to burn addresses and the merchant would be able to simply mint all of their proceeds in one shot.  The same for allowing for anonymizing donations to political causes that one may not want to be publicly associated with (e.g., Canadian Truckers donations).
The nice thing about both of these use cases is that it creates an incentive to grow the anonymity set as receiving funds this way would be cheaper than receiving at independent addresses since you can “rollup” the consolidation transaction.

Author: runatyr1
Date: 2023-09-30T01:53:29.179Z

@keyvank couldn’t anonymity be increased by adding functionality to retrieve the newly mint tokens using uniform amounts and random time periods?
I’m not an expert at this but I think this could help further un-link the secretly burned eth from a new wallet that is receiving newly minted eth. e.g.
wallet A burns: 0.5 eth
wallet B burns 0.7 eth
…etc
then
new wallet A sets a retrieval schedule of 0.1 eth per mint at random times in the next  6 hours to complete retrieving the new eth in 5 transfers
new wallet B also sets a retrieval schedule of 0.1 eth per mint at random times in the next  6 hours to complete retrieving the new eth in 7 transfers
(maybe initially limit this type of anonymous transaction to be of certain amounts, like 0.01, eth 0.1 eth, 1 eth or 10 eth)
So even if the  anonymity set shrinks over time like @MicahZoltu said, it would be difficult to link certain burn to a mint because wallets doing the mints would be getting the same amounts per mint and at random times, plus the added privacy of the Private Proof of Burn when requesting the minting to start.
This could be optimized to avoid it from being too many transactions and resulting in expensive gas fees but still keeping it anonymous.
Because, otherwise, even if private proof of burn are used to anonymously mint new eth, i think the amount and timing would give away the identity. If wallet A burned 1.7598 ETH and other wallet B suddenly mints 1.7598 ETH then its easy to know that the owner is very likely the same.

Author: MicahZoltu
Date: 2023-09-30T07:16:51.923Z

runatyr1:

@keyvank couldn’t anonymity be increased by adding functionality to retrieve the newly mint tokens using uniform amounts and random time periods?


A big part of having a functionally large anonymity set is proper operational security and practices for people using the protocol.  I would argue that this problem is orthogonal to the technical problem being addressed by this proposal.
On the technical side, it is necessary to have at least one of the follow:

Allow partial withdraws, where you deposit 5 and then withdraw 3 and later withdraw 2.
Have fixed note sizes, where everyone deposits/withdraws the same amount.
Allow internal consolidation, where you can deposit 2 and later deposit 3 and then withdraw 5.

Having both (1) and (2) is ideal IMO, and hopefully if this goes through it would include both.  From there, it is up to tooling authors to build tools that make it easy to use this underlying platform in a way that doesn’t create correlation between depositors and withdrawers.

Author: keyvank
Date: 2023-09-30T08:02:48.321Z

MicahZoltu:

Of note, this isn’t just for CEXs. This would potentially be useful for anyone who sets up a unique recipient address for each payer including payment processors, merchants, etc.


Makes sense! I like the fact that it economically encourages more users to enter the anonymity set!  Will add to the current EIP soon.



 runatyr1:

Because, otherwise, even if private proof of burn are used to anonymously mint new eth, i think the amount and timing would give away the identity. If wallet A burned 1.7598 ETH and other wallet B suddenly mints 1.7598 ETH then its easy to know that the owner is very likely the same.


Definitely, but as @MicahZoltu mentioned, we still have plausible deniability  You can just claim that someone else has minted exactly 1.7598ETH to fake your identity and you have nothing to do with that transaction. Nobody can 100% prove that you are connected with that TX, nor can they prove that you are involved in any privacy protocol!

Author: jftavira
Date: 2023-10-19T12:14:45.152Z

Are you aware of that could be used for circumventing AML regulations and may lead to ETH being banned in most of the exchanges?

Author: keyvank
Date: 2023-10-19T12:29:55.752Z

It’s not that simple imo, if this was for a new/less-popular cryptocurrency, then yes, exchanges would ban it. But for a major crypto like ETH, I’m not really sure what will happen

Author: jftavira
Date: 2023-10-19T12:40:33.783Z

The decision is not in the exchanges, it is in the countries and AML regulations are quite rigid: no tracking of the money (whatever the kind) no money. TornadoCash accounts have been banned, Monero is also affected because its annonymity.

Author: lovely-necromancer
Date: 2023-11-01T14:27:23.971Z

Aren’t we reaching to a point that AML becomes just something from the past? I mean they just try to control something, which is not controllable at all. They wanted to ban Bitcoin in early years and as a result, they couldn’t. Sometimes newer tech forces governments to reshape. Will they be able to stand against the biggest web3 foundation?
This all reminds me of the same historic events happened between email and post industry: They tried to regulate emails with E-COM, the program allowed users to send electronic mail to a post office branch. From there, it was printed and hand-delivered

Author: eawosika
Date: 2024-03-27T15:19:56.438Z

Hi Ethereum Magicians. I recently published a deep dive on EIP-7503: Zero-Knowledge Wormholes as part of 2077 Research’s coverage of Ethereum Improvement Proposals (EIPs).  Read the full article to understand how EIP-7503 enables privacy-preserving transfers on Ethereum with zero-knowledge proofs and why we need a protocol-layer privacy solution like EIP-7503 (vs. relying on privacy tools like Tornado Cash).
All feedback and comments on the article are welcome.

Author: enricobottazzi
Date: 2024-04-23T15:10:01.244Z

keyvank:

zero outgoing transactions by default.


Wouldn’t reduce it only to the Ethereum accounts with zero outgoing transactions and some balance?



 keyvank:

(E.g. h(s | 123)


I’m not sure where 123 is coming from, but it doesn’t look secure to me. I understand that only providing  h(s) would reveal the burn address. Maybe another solution would be to use a different hashing function h3 and use as nullifier h3(s) ?



 keyvank:

Anybody who has interactions with a mixer contract,
whether the sender or receiver, can get marked.


Given your suggested EIP, how can the receiver not be trackable by a regulator ?

Author: irnb
Date: 2024-05-20T23:23:10.464Z

Wouldn’t reduce it only to the Ethereum accounts with zero outgoing transactions and some balance?

Yes, you’re correct. The anonymity pool will include all valid Ethereum EOA accounts with a non-zero balance for the current block minting transactions. Additionally, as new accounts join the network and receive ETH, they will contribute to the anonymity pool for future block minting transactions. This approach addresses the current privacy protocol issue and, from the bootstrapping day, solves the problem of having a small anonymity pool.

Given your suggested EIP, how can the receiver not be trackable by a regulator?**

At first glance, this approach solves the problem of making the sender and receiver unknown addresses, making it difficult to track them via on-chain data. However, the receiver of a mint transaction is still publicly visible on-chain, meaning anyone can track their addresses.
We have considered addressing this issue with another idea. Besides enhancing privacy, this EIP also offers a scalability approach. Major custodians, such as large centralized exchanges, need to provide unique addresses for each of their users to track deposits accurately. With over 2 million active users, these entities send numerous on-chain transactions to aggregate user-deposited assets into their cold wallets, consuming a significant amount of gas.
What if these entities provided unique burn addresses for their users and implemented proof aggregation in the Ethereum node for proof of burn addresses? They could then keep the secret of the burn address. During the aggregation phase, they could send a single transaction with aggregated proof for multiple addresses to consolidate assets into a single mint transaction (this was our initial idea, and we haven’t work on it).
This approach would save a lot of gas, allowing for more transactions on the network. If major players adopt this method, it would make it more challenging for regulators to target individuals receiving assets through mint transactions.
However, we still face the ERC20 token problem. In an ideal world, if this approach were implemented in ERC20 contracts (like Keyvan’s implementation for proof of burn for ERC20: GitHub - nobitex/burnth), it could further support this goal.
In conclusion, while the receiver remains publicly known, the source remains unknown, benefiting from a large anonymity pool and this idea can’t solve directly the problem you mention.

I’m not sure where 123 is coming from, but it doesn’t look secure to me. I understand that only providing  h(s) would reveal the burn address. Maybe another solution would be to use a different hashing function h3 and use as nullifier h3(s) ?

It was just an example. You can consider “0x000000000000000000000000000000000000dead” as a point on the elliptic curve that no one could find a private key for. This was the initial idea, but @eawosika did a great job explaining the our alternative approach in his blog post: [Generating the Provable Unspendable Address]

Author: kayabaNerve
Date: 2024-06-14T22:06:47.284Z

keyvank:

since there isn’t a polynomially bounded algorithm
to find x where keccak(x)=h(s). This is only true if the second hash function is a different hash
function, and it assumes it is impossible to find x_1 and x_2 such that h_1(x_1)=h_2(x_2) in case
h_1 and h_2 are different hash functions.


I don’t believe this is true. The usage of the birthday problem to find collisions doesn’t require introspection of the hash function. While yes, the map from preimage to output is different, two quality hash functions should both have the same distribution: one effectively uniform.
Mind linking the evidence/theory behind this claim?

Author: kayabaNerve
Date: 2024-06-14T22:15:18.321Z

I’ll also add in order for this idea to prevent amount correlation, I’d call for all redemptions to redeem two notes (one real, one either real or a dummy), and support partial redemptions (the left-over amount becoming itself a new note).
This would enable aggregating notes via redeeming the amount necessary for fees, effectively layering a private UTXO system over Ethereum. While aggregations could be their own class of TX (and unbounded in their quantity), variable quantity enables some degree of fingerprinting. Here, the only fingerprint is if the amount is zero if explicitly aggregating, yet a user who has two notes and only redeems the amount they immediately want will inherently aggregate (which is not only pleasant, yet enables hiding aggregations within redemptions).
Though if this idea is to become a full private UTXO layer, with a privacy set of all ETH addresses which haven’t made any transfers, I’d point to the extensive work done with Sapling, and also the Orchard protocol, as references. I’d question why reinvent the wheel (as my comments start to do) just because one can.

Author: Hugo0
Date: 2024-07-22T12:43:38.811Z

This proposal is absolutely genius

Author: 0xwormhole
Date: 2024-12-02T22:38:38.305Z

I proposed changes to EIP-7503. I have omitted the cryptographic details, as I lack expertise in that field. However, my changes are meant to provide the Ethereum developer with a basic structure that they should consider when working on the full implementation.

Author: thedevbirb
Date: 2025-03-04T13:39:02.746Z

In the EIP I can read the following:

Cryptocurrency mixers like TornadoCash can successfully obfuscate Ethereum transactions, but it’s easy for the governments to ban usage of them. Anybody who has interactions with a mixer contract, whether the sender or receiver, can get marked.

In this context, people could get marked by using this transaction type. Am I missing something?
Thanks

Author: CPerezz
Date: 2025-03-06T09:36:32.031Z

I wonder how that would play with new PQ concerns over EL/CL.
If we switch from EC to Multilinear/hashing/lattice/whatever PQ-secure proving scheme (IOP + PCS) we definitely have to spend insane amounts of gas (WHIR takes 1.9M to be verified atm, soon to be more if CALLDATA cost is increased).
Hence, this would become another thing that we need to migrate at protocol level that is not just plain Secp tx signatures.
Another topic is: “What happens with this once we migrate EL signature scheme to a PQ-safe one?” It definitely implies we need to give support for this.
The problem: It is quite hard to find a sig-scheme that allows us to migrate to PQ and that we can verify sufficiently fast and doesn’t have massive-sized signatures such that the P2P layer doesn’t explode.
But it’s even harder to assume that we have/will have PQ-secure proving schemes that can actually prove in a reasonable time and with small proofs such PQ signatures within a proof that then needs to be verified in EVM or via Precompile and sent through the P2P layer too.
I love this idea, I really would like to see it landing. But I think this is one of the features that L2s can definitely take first. As for mainnet this would need to be viable in a PQ setting in order to really be considered. And there’s too much unknowns for now.
What are your takes on this? Could this be a RIP? Would any of the L2s actually be interested on innovating and stewarding Ethereum’s core values?
Nice work and very very brilliant idea!!!

Author: MicahZoltu
Date: 2025-03-18T09:13:14.586Z

thedevbirb:

In this context, people could get marked by using this transaction type. Am I missing something?


On “withdraw”, yes.  On “deposit”, no.  With Tornado you are marked for both.

Author: mmjahanara
Date: 2025-03-25T19:50:22.271Z

@0xwormhole
The EIP mentions:
“The built-in PoW and 32 ETH limit prevent hash collision attacks: if an attacker can find collision (x1, x2) such that create2_address(…, x1) == sha256(MAGIC_ADDRESS + x2), the attacker could extract their ether twice (but only twice). Such an attack requires approximately 2^80 hashes. Adding 24 bits of PoW increases the difficulty to 2^92. This many hashes can be computed but is very difficult; currently, mining a Bitcoin block takes around 2^79 hashes, so those with the capabilities to attack this mechanism have a much more lucrative opportunity in Bitcoin mining.”


why 24 bits of PoW results in only 12 additional bit security? since the PoW property can not be satisfied with collision (it is not enough to have two secrets with similar hash prefix, the hash prefix has to be zeros, so it is a pre-image search not a collision search)


how do you calculate the 2**79 hashes number for bitcoin? could you provide a reference?

Author: zemse
Date: 2025-05-07T11:22:50.521Z

since there isn’t a polynomially bounded algorithm to find x where keccak(x) = h(s). This is only true if the second hash function is a different hash function

Introducing a new hash function for preventing collisions adds extra complexity with no considerable gain in security. Also, sha256 has efficient ASICs developed, which can make it unsafe to use in this situation.
An alternate approach is hash offsetting. For burning ETH, one could send funds to the address r = keccak(secret) - 1. Later, they can prove that the address r is just an offset from the hash of the secret. For someone to spend funds sent at such an address, they have to find x and s such that keccak(x) = keccak(s) - 1. This is comparable to a collision attack. Hash offsetting is also seen in ERC-1967: Proxy Storage Slots to prevent hash collisions.
PoW and address space extension would help as the nominal 80 bit security is not enough, see EIP-684: Revert creation in case of collision and EIP-3607: Reject transactions from senders with deployed code.