In April of this year, the Clearmatics research team published a further iteration of their cryptographic research by releasing a white paper and proof-of-concept called Zeth, an implementation of Zerocash on Ethereum. More recently, EY has published an open source version of zero-knowledge private transactions on public Ethereum called Nightfall. This post gives a high level overview of Zerocash, the high level differences between Zeth and Nightfall, and also highlights some concerns we have of the technology and the academic approach.
The Zerocash protocol was initially designed as a Decentralized Anonymous Payment (DAP) scheme working on top of Bitcoin and aiming at preserving transaction privacy. This ground breaking work lead to the creation of Zcash, which, as opposed to Bitcoin and other public cryptocurrencies working on “plaintext” data, proposes a channel to carry out private transactions (also referred to as “Shielded transactions”). The cryptographic construct leveraged by Zcash makes network analysis harder, and protects users’ transactional privacy.
Zerocash achieves the purported privacy of transactions by introducing new payment semantics allowing users to interact with a “shielded pool”. This shielded pool keeps funds in an obfuscated form. New transaction types are described in the Zerocash protocol to enable the conversion of Bitcoins into obfuscated notes, and the conversion of obfuscated notes back to Bitcoins. Once shielded, the funds can be sent from one user to another privately.
Nevertheless, one might notice that operating on obfuscated data does not necessarily enforce that the system remains sound.
In order to maintain a sound system, ensuring one cannot act maliciously is because the Zerocash authors leveraged zk-SNARKs, a proof system which is of great interest in the blockchain setting. Such proof systems come with small proofs (this is important as the proofs are sent on-chain) and very short verification time (it is important to limit overhead on the throughput of the system). Moreover, zk-SNARKs ensure that valid proofs cannot be generated by malicious users who shouldn’t be able to generate these proofs (this is encapsulated by the notion of “Soundness” of the proof system. To keep it simple, the soundness says that if you do not have the key for a given lock, you should not be able to open it). This type of proof system enables to generate proofs for a wide class of statements (NP-statements).
As a consequence, the Zerocash designers were able to “encode the rules of the blockchain system” (no double spend should be allowed, no money should be created ‘out of thin air’ and so forth) as an arithmetic circuit for which a proof could be generated (with zk-SNARKs, the statement that should be proven is represented as an arithmetic circuit, and the goal becomes to prove that on a given set of public inputs, and private inputs (kept secret by the prover), the output of the circuit is 1 — this is what we call the Circuit-SAT problem, which is NP-complete). Furthermore, the private inputs used by the prover to generate the proof (the secret, or witness) cannot be inferred by looking at the proof. This is because zk-SNARKs produce “zero-knowledge proofs” — or, put another way, proofs which do not leak information about the private data used to generate them.
Part of the statement used in Zerocash enforces that during a private asset transfer, the sum of the values of the notes used as input to the transfer is equal to the sum of the values of the notes created (outputs). This is referred to as the Joinsplit equation, that ensures that no money can be created ‘out of thin air’ during private transfers.
Along with zk-SNARKs, other cryptographic primitives such as Collision Resistant Hash functions, Pseudo-Random functions, and Commitment schemes have been used to keep to design the protocol.
The Need for an Ethereum-specific solution
As described in the section above, Zerocash was initially designed to work on top of Bitcoin. Hence, it was not directly clear how to integrate such privacy preserving protocol on Ethereum.
In fact, these two protocols are very different. Bitcoin is defined in the UTXO model, while Ethereum is defined in the account model. Ethereum works like a state machine, where each state holds the set of accounts and their balances. Moreover, Ethereum supports the deployment of smart contracts, which enables network users to describe a set of state transitions. The code of a smart contract is executed every time a user calls it. This triggers the state transition specified by the smart contract, on the given inputs.
But what prevents a user from deploying a contract, intentionally or otherwise, that encodes a state transition that never ends?
In fact, it is well known that the Halting Problem (which aims to answer whether or not a program halts on a given input within a finite number of steps) is not computable by any Turing Machine.
As a consequence, if no extra check is undertaken, nothing would prevent a malicious user from deploying a smart contract specifying an infinite state transition (let’s say an infinite loop — “while True”). Calling such contract would then request the execution of an infinite state transition. This would be disastrous for the network, as all the miners (in charge of executing all transactions) would be stuck running the infinite state transition forever.
To prevent such issue Ethereum introduced the ‘’gas model’’. In this model, every instruction executed as part of a smart contract call costs some value. When a user calls a smart contract, he/she needs to specify — in advance — the amount of value he/she is ready to pay for the execution. This amount is secured and then decremented by the cost of every instruction executed as part of the smart contract execution. If this amount reaches zero before the end of the execution, the state transition is aborted and the miner gets the full amount as a fee for the computational power allocated to execute the smart contract.
A direct consequence to this model is that every state transition will eventually terminate, as no user has unlimited funds.
Furthermore, we note that, even plain transaction (ETH transfers — no calls to smart contract) cost 21k gas. This is a very important aspect of Ethereum: every transaction costs some gas.
Hence, the balance of the sender of a transaction is modified. Such modifications are public (the public state is modified). With this in mind, below we look at Zeth — Clearmatics’ implementation of Zerocash on Ethereum.
Zeth design choices
As mentioned, Ethereum enables users to deploy smart contracts. Since these smart contracts can encode arbitrary state transitions, it is possible to encode privacy preserving state transitions.
This is in fact the idea that underpins Zeth. This solution was designed and implemented by Clearmatics Head of Research Antoine Rondelet and Cryptography researcher Michal Zajac and released in April this year.
At a high level, Zeth works as follows:
- Alice deposits X coins/tokens in the Mixer contract (visible to the network — because her public balance is decremented)
- The equivalent X are minted in zethNotes and stored in obfuscated (commited) form on the Mixer contract
- Alice wishes to pay Bob Y in value (Y <= X), to that end:
- Alice generates a zero knowledge proof that she owns at least Y funds on the Mixer contract, and that she would like to create new notes of summed value Y for Bob
- Alice encrypts the newly created notes with Bob’s encryption key (the transaction details are encrypted, and thus can only be retrieved by the owner of the decryption key, in this case Bob)
- Alice calls the Mix function of the Mixer contract upon input of the proof (so that the proof is checked to ensure that she owns the funds she spends and that she does not create value) and the encrypted notes. To that end, Alice needs to pay the gas cost for the Mix function to execute (remember that state transitions are not free on Ethereum, the gas model is here to avoid the Halting Problem). This modifies her Ethereum account as her balance is decreased by the gas cost of the Mix function (this is visible to the network)
4. The Mix function executes:
- The zk-SNARK proof is verified. If the verification fails, the payment aborts (nothing is done), otherwise, the execution continues
- The serial numbers of the zethNotes spent are published (the cryptographic construct ensures that no correlation can be drawn between notes and serial numbers) to prevent double spend (once the serial numbers are published, the notes become unusable — ie: the protocol will reject other attempts to use the same notes)
- Bob’s newly created notes are added to the Mixer (in an obfuscated — committed — form)
- The smart contract emits an event to broadcast the encrypted notes (Bob’s notes encrypted by Alice under his key). This enables Alice to send the private information needed by Bob to manipulate his funds on the Mixer; without interacting with him directly. Leveraging Ethereum events to break the link between sender and recipient avoids carrying out off-chain communications (or relying on a trusted third party) and keeps everything “under consensus”.
5. Bob listens to the Mixer’s events and tries to decrypt their messages. Because Alice encrypted the private data with his key, he can decrypt the ciphertexts and retrieve the data he needs to generate proofs that would enable him to manipulate his funds on the Mixer. Bob can now either go through the same process to pay Charlie (by calling the function and paying gas from his account) or withdraw the funds into his mainnet account (visible to the network). We note, that other users might be inspecting the Mixer events and might try to decrypt the ciphertexts. However, only Bob has the key to decrypt Alice’s message, so he will be the only person to be able to access the sensitive data.
Below is a diagram to demonstrate the level of obfuscation from a network analysis perspective:
For more information on the protocol, and for security proofs, please refer to the Zeth paper.
It is worth mentioning that zk-SNARKs come with a need for a one-time setup in which a common reference string (CRS) is created and made available to each party participating to be able to generate and verify proofs. Alice (the prover in the example above) will need this CRS to construct a valid proof 𝛑. The proof is then verified as part of the execution of the Mix function of the Mixer contract. Hence, the role of the verifier is played by a smart contract (which is instantiated with the CRS).
To keep trust assumption to the minimum, we suggested to generate the CRS with a Multi-Party Computation (MPC) ceremony. In fact, while often considered in the literature, relying on a trusted third party to generate the CRS is not desired in practice. It introduces trust in the system as a malicious third party producing the CRS could keep the associated ‘trapdoor’, and could generate fake proofs (and “create money our of thin air”).
Needless to say that such trust model is a no go for us. This is the reason why we recently switched to the state of the art zkSNARK (Groth16), for which an MPC protocol exists. In addition to that we are actively researching distributed and secure ways to generate the CRS.
Finally, Zeth has been designed to be modular, abstracting the proof generation from the rest of the components. This follows a Separation of Concerns approach and uses similar patterns to the Libsnark approach proposed by the set of world class academics comprising the SCIPR Lab.
For more information on ongoing work please refer to the Github repository.
Nightfall comparison design choices
Recently EY’s blockchain team released a white paper and an open source proof-of-concept for private transactions on Ethereum. As another smart-contract based solution leveraging zkSNARKs in their protocols, it is not surprising to see similarities between the Nightfall project and Zeth, which precedes their solution.
Both solutions enable to obfuscate the “to” address, and amounts within the private transaction system, however none of the proposed solutions ensure user anonymity since gas needs to be paid for the execution of the smart contracts. As a rule of thumb, it is often assumed that a funded address is publicly known — ie: the binding between user’s identity and Ethereum address is known.
Despite being very similar at first glance, we list below a few points of divergence between Zeth and Nightfall:
First and foremost, Nightfall uses a Domain Specific Language (DSL), ZoKrates, which is a proof-of-concept language that abstracts the trusted setup and proof generation away from the user. Nightfall, as such, has assumed the trusted setup is indeed trusted (from the paper: “generous trusted benefactor” and “it is assumed the generous benefactor will not use secret information obtained during the setup to subvert the security of the protocol”).
As mentioned before, we do not believe this is an acceptable assumption for the public blockchain setting — which seems to be the use case considered in the Nightfall paper (“In this document we discuss Nightfall — an open source suite of tools designed to enable private token transactions over the public Ethereum blockchain.”) Equally, in the permissioned blockchain setting, centralizing the CRS generation is a non-starter for us as it could empower a malicious generator with the ability to forge proofs and violate the soundness of the system (without anyone knowing!), hence the research focus we take.
ZoKrates also takes care of the generation of the common reference string (CRS) for the generation and verification of the proof. It is noted in the paper that the team list 6 computations for which a trusted setup is required by the aforementioned “generous benefactor”. Not only does that widen the attack surface for malicious behaviour (ie: either one (very) trusted “generous benefactor” generating all CRS’s , or multiple trusted “generous benefactors”), but this also makes the entire suite of protocols harder to use as multiple CRS’s need to be handled by the application to be able to generate the different sort of proofs.
As a consequence, having a several statements to prove (different circuits) can pose difficulties in the maintainability of the project. Moreover, it seems very hard to imagine that MPCs would be carried out to generate all CRS’s used in Nightfall. Hence, it seems that the solution will stick to a weak threat model and strong trust assumptions.
Secondly, it is well known that zk-SNARKs can be vulnerable to “man-in-the-middle attacks”. In fact, in certain settings a malicious actor could generate a valid proof from another valid proof, without needing to know the private inputs (witness) that generated the initial proof. Considering blockchain applications, the list of potential bad actors in this instance is extensive, taking into account miners and the peers on a network that receive and broadcast transactions. A remedy for this type of attack could be to use a one-time signature in the arithmetic circuit, as Zcash implemented, or to switch to a SE-SNARK (SE standing for “Simulation Extractable”), which is what the Nightfall team did. However, using a Simulation Extractable SNARK does not necessarily solve all issues related to malleability. While a proof can be “non-malleable”, this might not prevent the whole transaction from being malleable.
In this case, a malicious miner can extract the proof from the original transaction and create another transaction that calls the contract to send a private transaction, but one that includes other false data, such as the payTo field whilst the transaction is still in flight. The Nightfall team had not accounted for that. Such issue was raised on a ticket on their Github repository. To their credit, fixes have been written and the ticket closed within two days. The point to note here is that Simulation Extractability is not a silver bullet. Careful and purposeful research is still needed for this cutting edge technology and we must remember this is still in proof of concept stage. The Groth16 zk-SNARK used in the Zeth design is the fastest construct to date, and the Clearmatics research team continues with the development towards minimising attack vectors and increasing efficiency.
Finally, it is worth mentioning that the Nightfall solution uses zkSNARKS as a ‘blackbox’. The paper lacks formal definitions and security proofs and fails to refer the reader toward resources that could bridge this gap. We note that very few resources are listed in the “References” section; most of them pointing towards informal explainers about zkSNARKs.
More importantly, no reference to Zerocash, this breakthrough work which seems to be the source of inspiration of the Nightfall’s suite of protocols, can be found.
On a broader note, we would also like to underline the lack of acknowledgement of other projects building privacy enhancing protocols on Ethereum. In fact, no “Related work” section is provided in the Nightfall document. This makes it hard to properly grasp the contribution made by the project, and gives a feeling of negligence toward similar projects.
Today, we count several projects that aim to propose confidential transactions on Ethereum, including Zeth, Aztec Protocol, Zether and more. Contrary to ignoring other projects, we believe that intellectual honesty along with collaboration is the only way toward robust and elegant protocols solutionizing today’s problems on Ethereum.
While we recognize the effort made by the EY team to release Nightfall in the public domain, and while we certainly support the advancement of these technologies in the open, we would caution that the devil, as always, is in the details.
Any question or comments? Tweet us @Clearmatics