In this article we discuss the zero-knowledge proof system: PLONK. We outline the benefits of using PLONK, discuss the relevance of an updatable reference string and showcase some of our benchmarking times.
Taking a closer look at our technical framework, we can see that PLONK has its own spot in the Dusk Network protocol, playing a crucial role in the entire blockchain stack.
This Technical Framework shows the different layers and components of the Dusk Network. Read more about how it all ties together.
Today’s content is a bit more challenging - we will start with a brief introduction to zero-knowledge proofs before we dive into PLONK.
Introduction on zero-knowledge proof
Zero-knowledge proofs are a family of cryptographic systems that enable a prover to make mathematical statements to a verifier without revealing the underlying information about that statement.
The most common variations of zero-knowledge proof systems include zk-SNARKs, zk-STARKs and the Bulletproofs. Some zk-SNARK systems utilize trusted setups, which are typically generated prior to the deployment of a zero-knowledge proof system. The trusted setup can be described as the main attack vector surface on the underlying zero-knowledge proof system. If it is compromised, a malicious actor would be capable of creating invalid proofs and convince the verifier that they are valid proofs. To alleviate the concerns about a compromised trusted setup, teams choose different approaches to convince the users of the honesty of the procedure. The trusted setup (referred to as "MPC Ceremony") for ZCash's Sapling upgrade (which utilizes Groth16 variation of zk-SNARKs) required only a single honest participant and had 87 participants (some of whom destroyed their hardware after the ceremony to prevent the so-called "toxic waste" from ever being recovered). Bulletproofs, on the other hand, do not require a trusted setup. This is also one of the reasons that it has significantly slower proving and verification times.
Proving and verification
When speaking of zero-knowledge proofs, the protocol can usually be separated into two distinct procedures: proof generation (to prove something) and proof verification (to verify the proof).
For example, we can prove in zero-knowledge whether we are above the age of 18, without actually disclosing our age, and convince the verifier of the soundness of this proof, just by relying on the mathematical properties of the proof system in place.
Or, we can prove that we are part of a whitelist, without disclosing any of the identities on the whitelist.
Or, we can prove that we know the password that belongs to a username, without telling the website what that password is.
Or, we can prove that a public key is ours, without revealing our private key.
And so on.
In every aforementioned case, a proof needs to be generated by the sender (i.e. prover) and the proof needs to be verified by the receiver (i.e. verifier). The time it takes to generate the mathematical statements (proofs), is what we call proof generation times (or prover times) while the time it takes to verify the proof is referred to as verification times.
Times vary
In terms of proving and verification times there are many influencing variables, and the design choices made have a direct impact on the performance of a proof system. Improvements of mere seconds on the prover side, or even milliseconds on the verification side go a long way. Proving time is generally on the side of the user (this means the longer the proving times, the longer a user has to wait before a transaction can be broadcasted to the network), whereas the verification times are accrued by the nodes that verify transactions. That means that the longer it takes to verify proofs, the fewer transactions can be included in the block.
Possible influences on these times are:
- The use of trusted setup
- The complexity of proofs
PLONK - updatable reference string
PLONK utilizes a trusted setup with an updatable reference string. Firstly, this means that integral to its design is a multi-party computation (MPC) procedure (i.e. trusted setup) to generate the original reference string. MPC procedure requires multiple participants in the ceremony and cannot be compromised as long as at least one of the participants is honest. Secondly, this original reference string is constantly updated, meaning that the probability of zero participants being honest decreases even further over time. In the case of Dusk Network, the string will be updated by Block Generators every N blocks.
Another benefit of PLONK includes that, unlike Bulletproofs, the verification times are (near-) constant, no matter how complex the proof gets. This brings various advantages to the Dusk Network, most of which are involved with security and speed.
Additionally, unlike other zk-SNARKs, with PLONK we have an original reference string that can be used to build proofs with any type of circuit. In other words, the reference string is universal, and we do not have to recreate a trusted setup for every circuit created on top of the Dusk Network. PLONK enables Dusk Network to scale drastically better.
Benchmark times / faster than a bullet(proof)
Figure 1 and 2 outline the major differences between Bulletproofs and PLONK in terms of prover and verification times. In Figure 1 you can see that prover times for PLONK are roughly half the times for Bulletproofs, while Figure 2 shows a monumental difference in verification times. The improvement on verification times for more complex proofs greatly increases the amount of transactions that can be included in the block.
After recent optimizations, we have gotten a Phoenix proof to under 2^16 gates, or 65.536, which denotes the amount of gates used in the proof circuit. At this moment in time our PLONK prover times are roughly 6 seconds on a mobile Intel Core i5 processor, while verification times remain near-constant at 5-7 milliseconds.
Tech demo
In this demo we have our Blockchain Developer Carlos Perez Baro first explain zero-knowledge proof basics followed by the demonstration of the verification and proof generation of a transaction on Dusk Network. As for transactions on Dusk Network, you can actually see the time it takes to generate a proof and verify, and it becomes clear why we updated from Bulletproofs to a PLONK implementation.
Next iterations are centered around the ease-of-use of our PLONK library. For instance, we will improve on our API to include PLONK as a dependency in Rust projects without the need for refactoring it on each API change. Besides, we will keep extending our built-in API usage examples and support documentation. Finally, we will continue to include more custom-gates to increase speed and performance as the circuits become shorter.
Next steps
Our previous demos featured three of our four Genesis Contracts. Before we jump to the demo of the final Genesis Contract (i.e. Bidding Contract), our next demo will demonstrate how users can easily build circuits from our PLONK library with the help of Turbo Composers.