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)
2 Likes
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.
1 Like
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.
2 Likes
“we can prove that some EOA-to-EOA transaction has happened in the previous blocks”
How to prove ? Using EOA’s signature ?
1 Like
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.
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?
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.
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.
2 Likes
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.
1 Like
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.
This is actually very convincing and sad, I thought the anonymity set would be bigger.
2 Likes
I agree it is unfortunate. The plausible deniability is still incredibly valuable though. You don’t get that with tools like Tornado.
2 Likes
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.
3 Likes
@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.
2 Likes
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.
4 Likes
Makes sense! I like the fact that it economically encourages more users to enter the anonymity set! 
Will add to the current EIP soon.
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!
2 Likes
Are you aware of that could be used for circumventing AML regulations and may lead to ETH being banned in most of the exchanges?
2 Likes
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
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.
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 
3 Likes
Hi Ethereum Magicians. I recently published a deep dive on EIP-7503: Zero-Knowledge Wormholes as part of the EIPs For Nerds series. Read the full article on Ethereum 2077 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.
2 Likes
Wouldn’t reduce it only to the Ethereum accounts with zero outgoing transactions and some balance?
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) ?
Given your suggested EIP, how can the receiver not be trackable by a regulator ?