From zero knowledge to one
Disclaimer
Zklog [skloːg] is a documentation of my journey through zero knowledge. It’s very likely that I make mistakes on the way, kindly let me know if you come across any. Other than that I hope that I by answering some questions I come across, I can also help others to learn.
Intro
This weeks’ article will be about two more project ideas which have come my way and some research I did on both: 1) private transactions on MINA (like zcash) 2) enabling private domain name system on MINA.
This weeks article covers the following topics:
What I’ve learnt
- How ZCash, TornadoCash, Monero enable private transactions on chain, advantages & limitations of each approach
- How ENS works on a technical level
1k fun fact
Before Halo2 was introduced (late 2020), people developing systems relying on ZK SNARKS actually had to meet in person for trusted setup ceremonies to generate public parameters which were necessary for creating non-interactive zero knowledge proofs. Such a boomer thing to do! 😂
What have I learnt this week?
Current implementations to enable private transactions
So apparently it’s not possible yet to create private transactions on MINA, even though it prides itself with enabling security and privacy for users via zkApps. I conducted some research on the most famous implementations enabling private transactions, so I’m sure this list isn’t extensive. As far as I can tell to enable private transactions there’s several paths that can be taken (sometimes in combination):
- Crypto mixers
- Stealth Addresses
- Shielded addresses
- Ring signatures
We’ll dip into each of those concepts when walking through examples.
Crypto Mixers (e.g. Tornado Cash)
Mixers are essentially smart contracts where a user deposits an amount they would like to transfer into a pool which they can later on withdraw (usually by specifying someone else’s address). The idea here is that by depositing into a pool we destroy the 1–1 link between the sender and receiver and the way the process is designed ensures that not even the smart contract can link deposit and withdrawal, if you’re curious let me go into detail:
- On depositing, the user can usually only select a specific set of amounts e.g $10, $100, $1000 — otherwise the transaction would be easier to trace back — and having deposited successfully, is given a deposit note. This deposit note is very important since it’ll be needed when withdrawing the money again. A hash of the deposit note is recorded.
- It is recommended to wait for a while before the money is withdrawn, such that no outside can see the link between deposit & withdrawal.
- On withdrawal, the user computes a zero-knowledge proof proofing that they know one of the hashed deposit notes recorded. The proof generates a signature which is used to check whether the note has already been withdrawn. If the verification passes, the user can withdraw the money usually to a different address.
Advantages
- Enables possibility to opt-in for privacy
- Since it’s a smart contract it’s easy to integrate on top of existing layer 1 solutions
Limitations
- Transactions into the contract & going into the withdrawal address are public
- Only works if there are multiple people using the mixer simultaneously otherwise we could trace back the deposit with the withdrawal
- Care must be taken when withdrawing (it is encouraged to wait a bit before withdrawing). There’s additional services (e.g. relayers) such that the withdrawal is sent to a one-time address
- Given all the above it doesn’t seem very user-friendly since a user has to keep all of this in mind
Monero
uses a combination of stealth addresses (one time addresses which the sender creates on behalf of the receiver) for every transaction and ring signatures (using keys from a group of people and thereby making it impossible to tell who signed the key) to achieve privacy in transaction. Wallets scan each transaction with their private view key to identify if any transaction belongs to the given account (the transaction contains a one-time public key which was generated from the public view + public spend key and is therefore cryptographically linked to the private view key but cannot be traced back to it from the transaction alone)
Advantages
- Monero offers a high-end privacy solution by default
Limitations
- There’s not many wallets that have been developed for Monero
- Since everything is strictly private there’s no way to know where any money came from
- As one of the famous privacy coins, Monero is a top choice for the dark-web and might fall under attack by regulators
ZCash
does not offer privacy built-in but chose an opt-in approach: Users can create shielded addresses (z-addresses) which are fully-encrypted. A transaction to or from a shielded address requires a zero-knowledge proof proofing that the transaction is valid which is verified by the miners. The transaction itself is fully encrypted and sent along with the zk proof. A transaction to or from a transparent address will reveal the value on the chain. ZCash uses a UTXO model like Bitcoin, so to prevent double-spending miners verify the ownership of UTXOs during a transaction. Now to prevent double-spending for encrypted transactions, ZCash does the following clever process:
- When Alice wants to pay Bob, she creates a new note for Bob and throws it into an opaque pot (rather than a transparent one)
- Alice then puts the serial number of her spent note on a public list
- To verify that the spent note was indeed one of hers in the pot, Alice generates a zero knowledge proof
Advantages
- I like the idea of having both options opting in for privacy as well as transparency for users making transaction a nicer user experience
- Transactions from a shielded to shielded address are fully encrypted
Limitations
- Transactions between shielded addresses are not publicly visible, however all transactions into and out of the exchange handling your account are recorded and could be reported to regulators
- Shielded transactions are computationally heavy (~ several GB of RAM and therefore not feasible on a phone)
Conclusion
I think to enable private transactions on MINA right now, one could implement a crypto mixer (although there might be some implementations that from SnarkyJS that I’m not seeing), however, I’m not a big fan of the user experience such smart contracts offer. I much more prefer ZCash’s approach of having two separate types of addresses — one transparent and one shielded (encrypted) address. This allows transparency for organisations and privacy for users so they can opt-in for both. I also feel that such an approach would be less likely to be targeted by law enforcement. Essentially, I could either decrypt my shielded account in case of indictment or generate a zk proof to verify my account does not involve illicit activities.
Current state of Ethereum Name Service (ENS)
Credit for this idea actually goes to CTO of Chorus One and great mentor to me Meher Roy who told me he had recently gone through the pain of registering for a .eth domain and tried to do so without linking to his public account and had not found such an option. I’ve therefore brainstormed how a private decentralised naming service could work and did some research to look into how ENS works currently:
Why ENS exists
- Share a name instead account number
- To distribute content of IPFS (Some websites rely on ENS name)
- Have a decentralised domain name service which protects users from censorship
How ENS works on a technical level
ENS is actually 2 smart contracts: 1) ENS registry which records all domains registered on ENS and holds information about the owner, the given resolver and caching time for all records under the domain as well as 2) Resolver which is the mapping of the name and the given address (or IPFS hash)
When we receive a request to resolve an ENS name 2 things happen: 1) we ask the registry what resolver is mapped to the given name and 2) we query that resolver
Advantages
- The architecture offers flexibility to extend the current ENS system, one could simply create a resolve to add a new mapping
- Since it’s decentralised, domains are censorship resistant and more resistant
Limitations
- ENS identity is actually tied to a public account and therefore easily traceable
Conclusion
I think there’s great potential to develop a way for people to link a shielded (encrypted) account to their domain name or just generate a proof that they own a domain or address without making the public address visible. I think rebuilding everything from scratch would be difficult, so I’m brainstorming ideas how such an approach could be integrated in the current ENS implementation.
1k fun fact
An improvement in ZK SNARKS removed the need for trusted setup ceremonies! If you have no idea what that means, I will try and explain on a high-level: As mentioned in the last article, ZK SNARKS were a big breakthrough because they enabled a non-interactive way of proofing that you know a secret information (witness). To enable this non-interactive way the proofer and the verifier required a shared key (also called public parameters). This was fine on paper but very painful for cryptographers, because whoever gained access to the entropy used to generate the parameters would be able to generate false proofs. There’s amazing stories from Zcash organising such ceremonies (I truly recommend the Zcash episode from Zero Knowledge Podcast) where they went through massive amount of effort to enable a multi-party computation setup (a setup which reduces the risk for malicious actors since only one person has to stay honest to ensure security of the protocol).
Resources
Zkapps dealing with privacy:
- https://zkappsformina.com/zkapp/ethmexico-wip-zkapp-harpo/
- https://zkappsformina.com/zkapp/stir-with-jarofpickles/
- https://github.com/Comdex/shadow
Maths
- Polynomial commitments
Private transactions
- Tornado Cash (Podcast)
- Nice example to understand why and how ZK is used in tornado cash
- How monero works
- Zcash Technical documentation
- Zcash in General (Podcast)
- How Zcash uses Zero-knowledge proofs (Video)
- Removal of trusted setups
- More info on HALO2 (Podcast)
ENS:
- ENS- A Global Naming System for Ethereum (Epicenter Podcast)
- ENS Official technical documentation
- EIP-137 specification
- Lightweight intro to ENS
