Zero-Knowledge Proofs

Wanchain's VP of Engineering, Dr. Weijia Zhang, talks about Zero-Knowledge Proofs (ZKP), how ZKP can help improve cross-chain bridges, how ZKP might fare against quantum computing and much more!

Transcript of the video content with slight modifications：

James: How's it going? My name is James. Most of you know me by the name Dub Digital, and welcome to another episode of Wanted. Today, we have the pleasure of speaking to Dr. Weijia Zhang once again, who is the VP of Engineering at Wanchain. How's it going, Weijia?

Weijia: Oh, great! Thank you, James, for this interview.

James: Of course, always a pleasure. Today, we want to talk a little bit about zero-knowledge technology being more and more in the forefront of bridge technology being integrated into it. For the people who don't know you already, give us a brief introduction of yourself, describe the nature of your work at Wanchain as well as the Enterprise Ethereum Alliance.

Weijia: Thank you. As you mentioned at the beginning, I'm the VP of engineer at Wanchain, and Wanchain is a project focused on crosschain bridges. We want to connect different blockchains together, just like the internet connecting PCs together. We have been working on that for a couple of years already and progressing technically very well. Also, we are growing our ecosystem. That's the Wanchain work. We realize the importance of standardization of crosschain bridges, just like internet TCP/IP. So we work with EEA, Enterprise Ethereum Alliance, to make the crosschain bridge technology more standardized. I'm chairing the crosschain interoperability work group for EEA, so we can make some very good progress with that. That's my work with Wanchain and the EEA.

What is a Zero-Knowledge Proof?

James: To get into what can be a complicated topic at a high level, can you please explain for the people at home what zero-knowledge proofs actually are and maybe provide some relatable real-world examples to help us grasp the concept?

Weijia: Zero-knowledge proof is a complex concept. When translated into Chinese, it seems like a proof without the need for knowledge, but that's not right. Zero-knowledge proof means that you can prove something without revealing the information of that knowledge. For example, when you go to a bar, you need to prove that you are over the age of 21 in the U.S. When you go to an airport, you prove that you are the person on the ticket. At a hotel, you prove that you have a reservation. Usually, you need to show them your identity, like your driver's license or passport. We trust these verifiers, but they can misuse our information. With blockchain, if they post your private information, it stays there forever. Zero-knowledge proof is a way to verify, for instance, that you're over the age of 21 without revealing your exact age or other personal details. Another common example is passwords. You can hash your password, and if the hash matches, then you are the one who holds the original password. We use this method with login systems all the time. And this can be improved for any system, including the blockchain transactions. How do you prove that transactions happened in the source chain? It can be proved by operating on the ZK proof system or running those transactions and then providing a proof. Instead of running the same operation on the main chain, you actually provide a proof to the main chain, saying that these are valid transactions. All of these can be done with ZKP zero-knowledge proof.

James: That's awesome, and it's very profound, I think, because a lot of the web 2 issues with security arise because those details are largely just out there and accessible. This is a good way to satisfy a requirement, like proving one has a driver's license to participate in a bar environment, without revealing all the details on that driver's license. It's very profound, moving forward for how the internet might develop. Very good. I think you also delved a bit into how zero-knowledge proofs verify. Can you walk us through the three core components of the verification of zero-knowledge proof?

Core components of ZKP

Weijia: It's a bit complex with a lot of mathematics involved. First, if you want to do a ZKP zero-knowledge proof, you need several things. The goal is to prove that you own or know something, or that a statement is correct. There's a prover who provides information and a verifier who verifies the information. For zero-knowledge proof, three things are important: completeness, soundness, and zero knowledge. Completeness ensures that any honest person providing a valid proof should be accepted. Soundness means that any false proof provided by a malicious entity should be rejected. Zero knowledge ensures that no private information is leaked. For zero-knowledge proof, several steps need to be taken. First, define the task or statement you want to prove. This definition can be in any language or form. For example, in the bar case, you want to check if a person's age is greater than 21. But in normal programming, if you put this into code, people would know the age immediately. For a password, you take an input string, hash it, and if the hash matches the supplied hash, you are the owner of the hashed password. For blockchain, you can take layer 2 transactions and provide proof that they happened in the source chain. After defining the task, you need to reformulate it into a zero-knowledge compatible language. This involves generating some arithmetic circuits. After all the computations, you generate a proof key and a verification key. Once the setup is done, every time you need to prove something, you give the proof key to the prover and the verification key to the verifier. The prover uses the proof key to operate on the input and produce a proof. The verifier then uses their verification key and the proof to validate its authenticity. Normally, the verifier can be a smart contract. In that way, the proof is done, and verification is done by the smart contract itself. If the input is a proof with a verification key, then the verification process is done on-chain. The beauty of ZKP is that the proof system, the process of generating the proof, is computation-intensive. However, once the proof is generated, the verification itself is quick and easy. So, it doesn't increase the gas for the main chain at all because that's still handled by the smart contract. That is how I understand the whole process is combined with how the proof is generated and how it's verified by the verifiers.

James: Very good. I think it's a great segue into interactive and non-interactive zero-knowledge proofs. Can you differentiate between interactive and non-interactive zero-knowledge proofs?

Weijia: Well, interactive is easy. When you want to prove something, the verifier can give you something, and you can leverage that input into your proof and then show it to the verifier. For example, if you tell the verifier that you know how to do multiplication, the verifier might ask, "What is two times two?" and you say it equals four. After enough iterations, if you get them all right, of course, you know multiplication. That's proven statistically. So that's interactive. But the challenge with blockchain decentralized applications is that there's no verifier to inquire multiple times; it's decentralized. So, you have to prove one time that you know multiplication. How do you do that? Do you want to submit all the multiplications you have done, or could you use zero-knowledge proof? Non-interactive means that you provide the proof one time, and the verifier has to verify it with just the proof you provide without inquiring for more information. This introduces more challenges to the ZKP system.

zk-SNARK vs zkSTARK

James: ZK-SNARK is one of the types of non-interactive zero-knowledge proofs. There are a few of them, like ZK-SNARKs and ZK-STARKs. They rhyme, just a coincidence. Can you go over the main differences between them? Starting off, what do they stand for?

Weijia: 'S' means succinct, 'N' means non-interactive, and 'ARK' means argument of knowledge. That's how they make up the word. 'S' means that the proof should be of small size, and the computation should be as concise as possible. The proof size should be small enough so that it can be sent to the blockchain or another chain. Also, you need to make sure the verification is easy; otherwise, a smart contract cannot handle that workload. So, there has to be succinctness. 'N' means non-interactive, which we just explained. And 'ARK' means argument of knowledge, which means you need to prove it right or wrong, true or false. ZK-SNARK is very commonly used with layer two already. Then there's ZK-STARK. 'S' means scalable, and 'T' means transparent. There are some differences. ZK-SNARK has a small proof size, but it scales linearly. ZK-STARK is quantum computation proof, which means that even with quantum computation, you can still use ZK-STARK. With heavy computing, it's better using ZK-STARK. There are some minor differences, so it's gaining some momentum for ZK-STARK.

ZKP and cross-chain bridges

James: Typically, ZK technology has been known for its privacy aspects. But there's also some research being done indicating that it also has some compatibility and significance in cross-chain bridging technology. Please explain what you see on the horizon for ZK technology being utilized for cross-chain bridges.

Weijia: What we see for the future of ZKP for cross-chain is a couple of things. One is data privacy. Today, when you see the blockchain, it's a variety of chains. We see a future for data chains, messaging from one blockchain to another. So, the data market with the crosschain operations, how can you show data on one blockchain to another blockchain? Many times, these data are private data. In that case, ZKP is very important. You can show that there's some data there without leaking the whole dataset. Another thing is the crosschain technology. We know that the crosschain contains several parts, one is the heterogeneous crosschain, and also roll-ups as well. We have seen the development from a state channel to Plasma, to Optimistic Roll-up, then ZK Roll-up. We are looking at the crosschain roll-up as well. The beauty of ZKP is that you do not need to run all these executions on the source chain. You can provide a simplified proof that something happened in the source chain without the burden of running those on the target chain or the main chain. In this way, we can improve the scalability and also improve the security as well.

James: Sure, that's a good point. Just to help people understand why this technology being applied crosschain bridge and security is so significant, how do crosschain bridges typically handle this now with the methods we have today?

Weijia: You probably noticed that Vitalik has written an article saying that cross-chain is not safe and Roll-up is safe. What he's saying is that if something goes bad in the source chain, then there's no way for the main chain to know that something went wrong in the source chain, and there's no way to roll back to mitigate that kind of hack. The whole security crosschain depends on the security of the source chain, the security of the bridges, and the security of the target chain as well. With ZKP, you can mimic the target chain, the main chain, with the ZKP. For example, you have a ZK EVM running on the prover; you can run all the transactions on the source chain with a ZK EVM and then provide proof saying that these transactions really happened on the source chain. Today, we only trust the events. We say that if this event happened on the source, if this is locked, and also on the source, we say, 'Hey, this happened already.' We just rely on the messaging itself; we did not run the transaction on the source chain to prove that this is a valid transaction. We just trust the event. With ZKP, we can run these transactions on the prover system and then provide proof saying that this really happened on the source chain. This is just one area, and there are other areas where we can improve the cross-chain bridges as well.

ZKP pitfalls

James: You know, sometimes the less data available, the better the security. Moving forward, I did some reading regarding the gas efficiency of ZK technology, and sometimes the amount of gas required to execute, depending on the number of transactions, is rather large. Can you talk about some of the pitfalls involved with this technology?

Weijia: Providing proof is not easy. That's why we say initially you define the task, you flatten that task into a hydrismatic circuit, and the computation of those circuits is very complex, involving a lot of polynomial computation. That's the drawback. People are developing specific hardware and firmware for that. They're designing firmware, so it's almost like a ZKP-specific hardware for all those kinds of computations. They will be improved. There are also questions about who runs these provers. For ZK-SNARK, there's a requirement for a secure setup, and for ZK-STARK, they also need to generate random numbers for those systems. There are setup processes, and some security considerations need to be taken into account. Those are drawbacks related to the decentralization of these proving systems. Can these systems be decentralized so that anybody can run them, or will they be a bit centralized for those prover systems? You have to trust them.

ZPK vs quantum computing

James: As you probably know, one of the buzzwords of the decade has been Quantum Computing. Everyone's anticipating quantum computing arriving. Regarding ZK-SNARK and ZK-STARK technology, how do you think it will fare against it once it does arrive?

Weijia: I think there's a thing. When you say you can't improve or not, it's normally the algorithm, the hashing that you used. Both can be improved. I believe that when that time comes, both ZK-SNARK and ZK-STARK can adapt to it. Today, ZK-STARK says that they are quantum computation proof, which is good. But even with ZK-SNARK, you can probably change something to improve it to make it quantum computation proof.

Wanchain and ZKP

James: You mentioned Wanchain's research on the topic. What types of integrations are you looking at and potentially integrating within the Wanchain ecosystem?

Weijia: First, the bridge. There's an actual layer of security, and they also improve the roll-up itself. We don't do roll-up right now with ZKP; we might do some roll-up as well. Once you have that capability, we also do side-chain, and maybe that can be used to improve the side-chain as well. Today, we just put the Merkle tree of transactions into the other chain. But I think with ZKP, we can do some computation and provide proof beyond the Merkle tree itself. There's still research being done, and there has been a request for data cross-chain. If there's a data cross-chain, then there's a data privacy issue that you need to consider. In that case, ZKP will be a good solution to provide some protection for the data itself in the solution.

James: Depending on what that data is, you would want to protect it. Well, I appreciate it. Thank you for coming back onto the channel. It's always a pleasure. If people want to get in touch with you or learn more about the ZK knowledge proof developments happening on Wanchain, where could they do that?

Weijia: Well, they can look at the Wanchain website. There are a lot of contact options there, so it's very easy to get in touch. There are also Telegram groups for Wanchain. It should be easy to find Wanchain and contact them.

James: Thank you again; it's always a pleasure talking to you.

Weijia: Okay, thank you, James. Great talking to you.