“Mastering ZoKrates: Ethereum’s Privacy Toolkit” — Part 2
“Welcome back, privacy seekers! Part 2 of “Mastering ZoKrates: Ethereum’s Privacy Toolkit” is here. In case you missed it, Part 1 covered the basics of zkSNARKs and ZoKrates. In Part 2, we’ll dive deeper into the features, workflow, deployment, writing code, etc. Let’s go! 🚀”
Note: To make the best out of this article, feel free to browse the contents and skip the section if you’re already familiarized with the same.
If you want to learn the basics, please read the Part 1:
Part 2 of the series Mastering ZoKrates will include:
- Understand why and what before getting started.
- Trusted setup in ZoKrates.
- Process of performing Trusted setup.
- Writing, compiling, and deploying zkSNARKs using ZoKrates and verifying smart contracts on the Ethereum blockchain.
Understand why and what before getting started:
In the world of zero-knowledge proofs, the trusted setup plays a critical role in ensuring the security and integrity of cryptographic systems. Before we jump into learning ZoKrates, let’s understand a few differences b/w ZkSNARK and ZkSTARK and also why there is even a need for a trusted setup and toxic waste.
What is Trusted Setup?
- Trusted setup is a process used in zero-knowledge proofs to generate the necessary cryptographic keys for proof generation, and verification.
- It involves the generation of toxic waste, which must be securely disposed of to prevent the creation of fake proofs.
- Trusted setup introduces a potential vulnerability if the toxic waste is not properly handled.
Need for Trusted Setup in zkSNARKs
- zkSNARKs rely on trusted setup to achieve succinct proofs, ensuring that the proof size remains small and efficient.
- The generated proving and verification keys are crucial for proving the correctness of computations without revealing sensitive information.
- However; the disposal of toxic waste is essential to maintain the integrity and security of the system.
Few points before we jump into setting up of Trusted setup:
- Ensuring Trustworthy Systems: Trusted setup is a fundamental process in zero-knowledge proofs, including zkSNARKs. It establishes the foundation for creating cryptographic systems that can prove the validity of computations without revealing sensitive information.
- Importance of Trusted Setup: Trusted setup is necessary to generate the proving and verification keys, which are essential for executing zero-knowledge proofs. It ensures that the keys are unique and secure, allowing verifiability and preventing the creation of fake proofs.
- Avoiding Untrusted Setups: Untrusted setups pose significant security risks as they can lead to the creation of fake proofs, compromising the integrity of the system. Trusted setup protocols, like those used in ZoKrates, offer a decentralized approach to enhance security and trustworthiness.
- ZoKrates as a Privacy Toolkit: ZoKrates is a powerful tool that simplifies the development and deployment of zero-knowledge proof programs, specifically designed for use with the Ethereum blockchain. It provides a user-friendly interface and robust functionalities, making it an ideal choice for privacy-focused applications.
Comparison b/w zkSNARKs and zkSTARKs:
Note: This is just to give you all glimpse; this series is focused on zkSNARKs.
Trusted setup in ZoKrates (MPC):
Trust is the base of Zero Knowledge proof, and trusted setup is one of the procedures that is required in ZKP; specifically we will be talking about ZoKrates in this article. Before, we go deep dive lets try to understand few of the terms associated with it.
+---------------------------+
| Trusted Setup Ceremony |
+---------------------------+
|
|
+--------------------------+----------------------+
| |
v v
+---------------------+ +---------------------+
| Toxic Waste | | Proving and |
| Generator | | Verification Keys |
+---------------------+ +---------------------+
| |
| |
| |
+---------------------+ +---------------------+
| Toxic Waste | | Proving and |
| Storage | | Verification Key |
+---------------------+ | Distributor |
+---------------------+
The diagram shows the flow of the trusted setup process in ZoKrates. It includes the following components:
- Trusted Setup Ceremony: The ceremony is run to generate the proving and verification keys. The ceremony is run in a decentralized way, so the responsibility for deleting the toxic waste data is shared among all participants.
- Toxic Waste Generator: This component generates the toxic waste data that is used to create fake proofs.
- Toxic Waste Storage: This component stores the toxic waste data until it can be securely deleted.
- Proving and Verification Keys: These keys are generated during the ceremony and are used to generate and verify proofs.
- Proving and Verification Key Distributor: This component distributes the proving and verification keys to the users who need to generate and verify proofs.
Now, we know the terms associated with this. Let’s understand the process in a simpler way and then we will deep dive into more technical and implementation:
- Trusted setup is a process used in zero-knowledge proofs to generate the keys needed for a zk-SNARK scheme.
- However, the trusted setup procedure introduces a potential vulnerability because the generated data, referred to as “toxic waste”, could be used to create fake proofs.
- To prevent this vulnerability, the entity running the trusted setup is responsible for deleting the toxic waste data.
- If the toxic waste data is not properly deleted, it could be used to create fake proofs that would be accepted by the verifier.
- It uses a multi-party computation protocol to perform the trusted setup in a decentralized way to increase security.
No worries, even if you don’t understand the above explanation. Why don’t I give you an analogy to relate:
Let’s consider a real-life example. Imagine you are tasked with creating a new lock that can only be opened with a specific key. You design the lock mechanism and make a prototype, but now you need to create the key. You could make a copy of an existing key, but that would leave the lock vulnerable to being opened by anyone with a copy of that key. Instead, you decide to create a unique key by randomly generating a series of cuts in the key’s metal. This random generation process is equivalent to the trusted setup in ZoKrates — it ensures that the key (or proving and verification keys in the case of ZoKrates) is unique and secure.
However, just like in the case of ZoKrates, there is a potential vulnerability in this process. If someone were to copy the series of cuts used to create the key, they could create a duplicate key that would also work in the lock. This is similar to the toxic waste generated in the trusted setup — if it is not properly deleted, it could be used to create fake proofs.
In conclusion, a trusted setup is a crucial step in the security of a zero-knowledge-proof system, and ZoKrates allows for a decentralized approach to this process through multi-party computation. By understanding the importance of a trusted setup and the potential vulnerabilities involved, we can ensure the security and trustworthiness of the resulting proof system.
Process of performing Trusted setup:
In this we will break down the process into steps; I’ll be adding analogy after every step.
Note: Reference is taken from official docs of ZoKrates; this will be the breakdown of those steps in a much simpler way. If you want to go into the code part, here it is — https://zokrates.github.io/toolbox/trusted_setup.html
- Pre-requisites: The trusted setup is done in two steps -
— The first step, also known as “phase 1”, does not depend on the program and is called Powers of Tau.
— The second step is called “phase 2” and is circuit-specific, so it should be done separately for each different program.
— The Ethereum community runs a phase 1 setup called Perpetual Powers of Tau, whose output we can use. Therefore, we only need to run phase 2 of the setup. - Compiling a circuit:
— We start by using ZoKrates to compile a basic program. [Read below how to do this]
— The compiled program is called a circuit.
Analogy: It’s like building a house. The blueprint is like the program, and the actual building is like the circuit. - Initializing a phase 2 ceremony:
— We then initialize a phase 2 ceremony with the command “zokrates mpc init”.
— We pass a path to the file which contains the parameters for our circuit with depth 2^n.
— The parameters for various circuit depths can be computed using the phase2-bn254 utility by picking the latest response from the Perpetual Powers of Tau and following the instructions in the mentioned repositories. - Making a contribution:
— In this step, we conduct a ceremony that has multiple participants who run contributions in sequential order.
— Each participant uses the “zokrates mpc contribute” command to generate a contribution.
— The contribution file is passed to the next participant in the sequence.
— Each contribution file contains a hash of the previous contribution to ensure that the contributions are performed in the correct sequence. Analogy: It’s like playing a game of telephone, but instead of passing a message, you’re passing a file with information. - Applying a random beacon:
— To finalize the ceremony, we apply a random beacon to get the final parameters.
— The random beacon is the 2^n iteration of SHA256 over the hash evaluated on some high entropy and publicly available data.
Analogy: It’s like mixing a deck of cards before dealing them out, to ensure that the game is fair. - Verifying contributions:
— At any point in the ceremony, we can verify the contributions made by the participants to ensure that they are valid.
— This can be done using the “zokrates mpc verify” command, which requires the contribution file, the public input file, and the index of the participant whose contribution is being verified.
— If a contribution is found to be invalid, the ceremony is aborted.
Analogy: It’s like a referee checking that each player in a game is following the rules and making valid moves. If someone is found to be cheating, the game is stopped to ensure fairness. - Exporting the proving and verification keys:
— After the ceremony is complete, we export the proving and verification keys.
— The proving key is used by the prover to generate proofs for a specific program, and the verification key is used by the verifier to check the proofs.
— The exported keys can be used with ZoKrates or any other system that supports the same zk-SNARK scheme.
Analogy: It’s like giving a copy of the lock’s key to the bank’s employees so that they can open the vault when necessary.
ZoKrates: Setting Up, Compiling, and Running Zero-Knowledge Proofs:
There are several ways to use ZoKrates for developing and testing zero-knowledge proof programs:
- Remix IDE: ZoKrates can be integrated with Remix IDE, which is an online development environment for Ethereum contracts. We will see the whole process below, how to use in Remix IDE.
- ZoKrates Playground: ZoKrates also provides a web-based Playground where developers can write and compile ZoKrates programs without installing anything on their local machines. The Playground includes a code editor, compiler, and tools to generate and verify proofs.
https://play.zokrat.es/ - Local installation: Developers can also install ZoKrates locally on their machines using package managers such as npm or by downloading the binary directly from the ZoKrates GitHub repository.
— One line Installation
curl -LSfs get.zokrat.es | sh— From Source
git clone https://github.com/ZoKrates/ZoKrates
cd ZoKrates
export ZOKRATES_STDLIB=$PWD/zokrates_stdlib/stdlib
cargo build -p zokrates_cli --release
cd target/release— Javasript binding for ZoKrates
npm install zokrates-js- Docker container: ZoKrates also provides a Docker container, which can be used to run ZoKrates programs in a virtualized environment. This option is useful for developers who want to avoid installing ZoKrates locally and prefer to use a standardized environment.
docker run -ti zokrates/zokrates /bin/bashLet’s see how to compile, run, and, verify in Remix IDE:
- Open your web browser and visit Remix IDE.
- Install ZoKrates extension from Remix extension bar at the left bottom.
- Go to the ZoKrates extension and hit the example file, it will ask for permission. Once that is accepted, it will create an example main.zok file. Remember .zok is extension for ZoKrates. ZoKrates DSL is very much similar to C, Python. If you want to edit the code or learn more about the DSL visit this.
4. Example code looks like this, let’s try to understand this.
- The keyword
fieldis the basic type we use, which is an element of a given prime field. - The keyword
privatesignals that we do not want to reveal this input, but still prove that we know its value.
5. Compile: On the left side panel, you will see the compilation button hit that. If there is no error, we can proceed further.
6. Run Setup: Next step is to click the setup button. This will creates a proving key and a verification key. These keys are derived from a source of randomness, commonly referred to as “toxic waste”. You will see a file is generated named verification_key.json which have all these details.
7. Export Verifier: The "export verifier" command in ZoKrates generates a Solidity contract that includes the verification key. This contract provides a public function to verify solutions to the compiled program. It enables independent verification of correctness and enhances transparency in zero-knowledge-proof systems.
8. Compile & Deploy .sol: The next step after exporting the verifier in ZoKrates is to compile and deploy the verifier contract. This involves using a Solidity compiler to compile the generated verifier contract into bytecode, and then deploying the contract to the desired blockchain network. Once deployed, the verifier contract can be used to verify solutions to the compiled program, providing a trustless and transparent verification process.
9. Compute Witness: Generate the witness for a given input to the program, which contains the private and public inputs.
10. Generate Proof: Use the witness to generate a proof that demonstrates the validity of the computation without revealing the private inputs.
11. Verify Proof: Return to the solidity code and use the exported proof and the verifier contract to verify the proof’s validity and ensure the computation was performed correctly.
After the transaction finishes executing, expand the logs and check the decoded output part. It should say “0”: “bool: r true.” That means that the transaction is successfully verified, which you can see in the above screenshot.
What’s Next?
In this informative article, we have explored the second part of “Mastering ZoKrates: Ethereum’s Privacy Toolkit.” We gained valuable insights into the trusted setup process, including toxic waste generation and key distribution. Additionally, we discovered how to leverage ZoKrates in Remix IDE, allowing us to write, compile, and deploy zero-knowledge-proof programs. The article also highlighted alternative approaches such as the ZoKrates Playground and local installation. Stay tuned for the next part, where we will delve deeper into ZoKrates’ future, developments, and alternatives.
