Next Generation ZKP System and Single Slot Finality | Tiancheng Xie - Polyhedra Network

And one day he encounters a tester, perhaps a malicious tester on the internet, and the tester makes the following claim. There is no audio. Yes. And there's no audio. There's supposed to be audio here.

So I intentionally included a phrase in Japanese, and I know most of you don't know Japanese. This happens in the world of ZKP. Where nobody really knows what the tester is going to say and he just spouts random nonsense. For example, the tester claims that their circuit is a Keccak hash circuit or claims that their circuit is a SHA-256 circuit. But who knows?

He could be making false claims, making false claims, right? And to verify these claims, the verifier needs someone to help him. One way to solve the problem is to enlist a trusted third party who can help you understand the claim. And here, in this example, we use Google Translate, where you trust Google to translate this phrase for you. And yes, in the ZKP world, this is often called a trusted setup, where you rely on a third party to perform calculations for you and identify the circuit contents.

People typically use Groth16 or Plonk to perform this task. However, this process requires many resources from the tester and also introduces additional trust. The tester also needs to perform very extensive calculations, such as MSM or FFT. Well, another way is for the verifier to do the work itself. In this example, you learn Japanese and, obviously, you can understand the sentence.

But the, the, the, the tester will have to do a lot of work to understand the tester circuit. She needs to at least scan the circuit, where the circuit can potentially be very large. Therefore, the calculation of the verifier in this solution is very expensive. And there is another solution that we are going to introduce, which is based on a compiler. And look at these phrases.

You may find that there is a pattern, in fact, in these phrases, where you will notice that they all begin with the same prefix. And by taking advantage of this type of pattern, you can, in fact, make the checker's calculation simpler; In this case, you will only translate one sentence and understand the rest. So let's delve into the technical details, where here is an example circuit that performs a very simple calculation. But if you compile the circuit, you will find that this compiled circuit, this circuit compiled in R1CS, is actually very large. It's on the order of 100 megabytes, but the source code is actually very small, very, very short.

And you may have already noticed that most of the source code performs this calculation. It's just a simple multiplication that can be expressed with a few bytes instead of 100 megabytes. So, in order for the verifier to understand the circuit, it doesn't need to look at the circuit itself, the compiled circuit, which can potentially be 100 megabytes. You can look at the source code, or in our terms, it's the compiler hint, where the compiler will tell you that this circuit is simply, uh, repeat this sentence. So here, I'm going to announce our revolutionary compiler, for which we don't have an official name.

I would tentatively call it a "log compiler" because we were inspired by this term. It is called a uniform logarithmic space circuit . And the circuit is actually the uniform logarithmic space circuit, which actually describes this property where the circuit can be generated from a very small program. And our compiler will initially support the Gox front-end language at launch, and we will gradually expand our compilation to PlonK, Halo, Circle, and even more. Our plan to make it open source is projected for May 2024, along with our tester.

So it's not just the compiler, it will be an end-to-end testing toolchain . So, the general architecture of this compiler is as follows. You take the programming language. It is described in the Go language and you pass it to the circuit compiler, and the circuit compiler will generate a circuit that has special structures, special substructures, and for the verifier to understand the circuit, it only needs to look at each individual subcircuit instead of looking at the entire circuit itself. Therefore, the verifier can save on computation by orders of magnitude.

And this new compiler could potentially allow recursive snarking, given that the verifier circuit is orders of magnitude smaller. So we can apply recursion directly to this verifier and make everything infinitely recursive. Okay, so let infinitely recursive. Okay, so let 's talk about the fitting room part. We also have the next- generation tester, which is a GKR-based tester and can operate over 3 million constraints per second on a single CPU with BN254.

And here is the general structure of the tester, where on this side is the tester, in the middle is the test structure and on this side is the verifier. So, the end-to-end experience is like writing the circuit program, running it on our tester, and finally being able to verify this test on the Ethereum chain. So, okay, that's never been done before on this scale, we can verify circuits of billions. onchain circuits of billions. onchain .

Yes, thanks. And if you really want to see our documentation, you can consult the article we presented called Libra and Pianist; there are two articles, and if you search for my name you can find these works. So this is the technical documentation we can offer right now, and after we make the code open source you'll be able to see it directly. Another interesting property is that we can scale horizontally indefinitely, adding many machines without overloading. And now, let me explain why others can't do this and why we can.

If we analyze the Fry protocol, it has a problem because it depends on the FFT, but the FFT has a drawback in distributed computing: in the middle of the FFT, there is linear-sized communication between machines. In our experiments, with a subcircuit of one million and 200 machines, gigabytes of data would have to be communicated if they used FFT or Fry. And this is impossible to decentralize. You can only place these machines in the same data center to achieve this distributed computing. We modified Fry.

In fact, we replaced Fry in our testing framework. We use the KZG for "bow" introduced by one of our previous articles. It's called Pianist previous articles. It's called Pianist . And this is too technical to explain here.

They might want to take a screenshot or a photo. The good thing about this KZG is that it replaces the FFT. Good. If anyone wants to take a picture, go ahead. So we replaced the FFT using this new polynomial commitment scheme and the advantage comes from the KZG.

The advantage is that we only require constant communication between the different machines. And if we combine it with the GKR protocol, at each node we only need to send or receive a total of 100 kilobytes of data; With that amount of communication, you can basically decentralize your tester globally. Let's talk now about decentralization. We conducted an experiment verifying 200, sorry, 32 thousand signatures and the result is quite impressive. It only took us five to six seconds to achieve it.

And the hardware requirement is 64 of these machines, portable machines distributed globally. Well, in the experiment we didn't distribute them globally. We just connect them to the same Wi-Fi network. But we observed that data transmission is very low and we believe it is possible to distribute the machines globally. So the hardware requirements will be minimal and could potentially allow a new scheme where validators buy a cheap machine and join the network to do collaborative testing the network to do collaborative testing .

The following is a new proposal, actually not so new since we proposed it last year, it is about all the validators in a single slot, since in the current Ethereum solution we have almost 1 million validators and, due to the scalability of Ethereum, they cannot process 1 million validators in one slot. They have to divide it into 32 different slots where each one has only 30,000 validators. And this can cause problems because people need to wait many slots or blocks to get a final result and for it to be confirmed get a final result and for it to be confirmed . In this simple example, you need to wait three slots for your transaction to be confirmed. And in reality, you need to wait about 20 slots for your transaction to be confirmed.

The problem is that the P2P network gets overloaded in some way if you put more committee members on a P2P network. And we use our signature verification algorithm that can bundle the signature into a very small proof, and instead of sending all the public keys and all the bit fields on the network, you can send a small proof. So you can reduce the load on the P2P network and finally achieve a single-slot purpose . And that's all for this talk . And that's all for this talk .

Thank you so much. And this is our official website. There's nothing else here.