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.
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 ?
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
123is coming from, but it doesn’t look secure to me. I understand that only providingh(s)would reveal the burn address. Maybe another solution would be to use a different hashing functionh3and use as nullifierh3(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]
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?
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.
This proposal is absolutely genius
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.
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
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!!!
On “withdraw”, yes. On “deposit”, no. With Tornado you are marked for both.
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?