S1E06[EN] - Polyhedra - Unveiling the Full Node Proof 28:47

Welcome to ABCDE Podcast. I'm your host, Joy Son. I am Lobby. I am Lobby. In this podcast, we'll be exploring the latest groundbreaking ideas, cutting-edge technologies, and game-changing development in a decentralized world.

Welcome back to ABCDE Capital, episode five. I'm Joy from ABCDE Capital. And today I'm here with two guests. I think most of our audiences are pretty familiar with our co-host, Lovai. Hi, everyone.

Today, we also have another guest, Tian Chen, CTO of Polyhedra Network. Welcome. The reason why I wanted to invite Tian Chen to our podcast is I wanted to know more about Polyhedra. Can you tell us a little bit about your background? Yeah, I'm co-founder and the CTO of Polyhedra. My name is Tian Chen Xie.

Previously, I was a PhD student in UC Berkeley performing computer science and cryptography. So currently, I'm currently working in Polyhedra to lead the research and the technical team. Yeah, just a little bit of quick question. Why do you want to co-found Polyhedra? What's the reason? Yeah, let me talk about the history.

So we started working on the GK bridge since I think it's by the end of the 2021 because in August of 2021, there have been a lot of hacks to classical bridges. And at that point, my advisor told me that, okay, you should look at this and maybe zero-logic proof can help reducing this security issue.

Yeah, then we basically looked at the bridge for several months. After several months, we finally had the idea of ZKBridge. We started implementing and writing papers. And I think in May 2022, we submitted the paper. So that's why we started looking at ZKBridge.

and the paper is actually accepted in September 2022 so that's why we publish the result in September 2022 yeah and after September 2022 we got some interest in actually making CKBridge.jp becomes a product so then we discuss we develop and finally in

April 2023, we published the mainnet. Yeah, I was about to say congratulations on that as well. And so can you tell us a little bit about what are the advantages of ZKBridge and what are the applications of ZKBridge? Yes. So initially, when you look at our story, initially it's trying to solve the security issue.

So we think the ZK bridge is the most secure bridge. And after we actually developed the product, we have a very nice observation. It's that ZK bridge actually can be the most cheap bridge.

the user can pay lower fee because we can use zero-node proof to batch all of the transactions. It's like a roll-up fashion. User don't need to pay the full fee and the user can amortize their fee among other users. Initially, the most important factor is security of CKBridge and afterwards we think that the most important factor is the cheapest bridge.

So that's two advantages of ZKBridge. Yeah, that makes sense. And it's actually provide a efficient solution for the asset transfers and message passing. Yes. Yes, totally agreed. And why are you interested in releasing the ZKBridge at this point of time? Because it's just ready to get released at this point of time. And I think we can release it as soon as possible.

Because people usually say a system is secure or is robust only if they got used by a lot of people. And so when we release it earlier, we can get the system used by people earlier and fix some bug earlier. And we don't want to get into trouble when the system becomes a very hot topic.

That makes sense. Well, what are the partners right now for Polyhedron? What do you mean by partners? The partners means that people already using your ZKBridge or like they want to establish the partnership with you. Okay, so I think the most notable partner is Nero Zero. They use our ZKBridge to secure their own bridge. Another most important partner is the Binance chain.

bnb chain that's the first i think that's the first uh blockchain we integrated with there are a lot of other blockchains already integrated with us i think i can show the logo collection here 15 chains already more than that because this is this is not updated okay

Yeah, PolyHydro is also in our portfolio. I believe in a lot of around we can have like more resources provided to our portfolio and also have less synergies between the project that we invested.

Yeah, cool. Lao Bai, do you have any questions regarding Polyhedra? Yes, of course. Tenshi, I do have a few bit more technical questions I want to check with you. First is, how does Polyhedra use ZKBridge to prove the full nose of Ethereum POS? I think that's on July you guys published the

articles about full nodes of Ethereum POS. You guys are using a DeVirgo proving system, which always...

impressed me even as the investors because the performance is just way better than most of the other competitors. So I want also I want to ask how do you compare DeVirgo with the popular options so far in the ZK market such as Plunky 2 and some new stars such as like Nova, Supernova, Hypernova, etc. Okay, so let's go through it one by one. We prove

full node of the server by using Deeper Go. It is very fast. It can achieve like 3 million constraints per second per CPU core. So to compare with when you look at the growth system, it can only achieve 1 million constraints per second and not per CPU core. It utilizes a full CPU. So it's like orders of magnitude faster than growth system.

That's why we can handle this billion-size circuit in real life. In our actual development, we either employ one or two very large servers or use 64 or 32 small servers. In terms of proving Ethereum consensus, we need to prove 20,000 or even 30,000+ of BLS signatures in the circuit.

This is very hard when you look at older systems as growth system, it takes more than half an hour. We developed the Virgo and here the purple line is using 64 smaller devices in parallel to perform this computation. And the other line is using one giant server, only one giant server. So look at the time, it's only like five seconds or

seven seconds, depending on which hardware you use. People may ask, how small is the device? Because if people want to join our proof network, they want to get easy access to the hardware, right? This is our smaller device. It's a gaming console. And you can see my hand. So this is a really small gaming console. And we use 64 of them to perform this computation.

But for one prover, you only need to have one of them. And we can beat the other 63 of them on the network. So you don't need to purchase all of the machines. To compare with other proof systems, I think I need to pull some data from the internet. So here is the data for NOVA. When you look at the prover time,

here k is the number of signatures or number actually it's not number of signatures it's smaller than signature when you look at the airproving time when you when they deal with like 10 000 signatures they already become slow like five minutes six minutes or five minutes or four minutes but it's it cannot match our performance so they are more like a liner growth of the time

This is still smaller than our circuit. It's only 10,000. We can prove 30,000 of signatures within five seconds. Server is actually similar in our Gen2 server. The Dova is actually way slower than us. I think D-Virgo is more like a sharding technology. It's like you can assign the--

a huge proving jobs to different small devices or different cores of the CPUs and then aggregate the end, isn't it? I would say, yeah, we assign the proving task to different CPU cores. And when you look at there is a Plunky 2 benchmark, they have about 45 million constraint. And for this number of constraint, the Plunky 2 takes about hundreds,

hundreds of seconds on a linux server hundreds of seconds yeah and our size of constraint is about a billion way larger than their size of constraint so you can see the performance gap we handle larger circuit and we are way faster than that if that's the case since you guys already

prove the full nodes of the Ethereum POS, would that match what Vitalik mentioned before in the roadmap of Ethereum, the fully snuck Ethereum in the final goal? That's like at least three or five years later's goal or even longer. Can I say you guys have already achieved or partially achieved the goal?

using a different methodology, or maybe in my understanding that the fully snuck Ethereum should be not just a block header, should be every single transactions inside the Ethereum has to be snuck too. But Polyhedra is mainly just focused on the block header, ZK proof. I'm not sure which one is right. I think you're right. Ethereum has two layers. The one is the consensus layer and the other one is execution layer.

so when you look at the execution layer snark zk snark it will be the zk evm which already a lot of companies is working on and you when you look at the consensus layer you make it the zk you you stick it start to do to deal with it it becomes a zk bridge i see and you combine this two you can make the whole thing for the zero knowledge proof yeah

So that's two separate parts, but we can combine them. Right. So can we see Polyhedra is on the consensus? Yeah, more on the consensus part. More on the consensus, right. And the fully-slapped Ethereum has to include the execution layer, which is ZKE-BAM. Yes. When you combine these two, you have fully-slapped blockchain, Ethereum blockchain.

And also I want to double check with you with another popular terms raised by Axiom, which is called the coprocessor. You must be quite familiar. We've talked to a few projects, including Axiom, and also another few projects using different terms for this called storage proof or state proof, like Lagrange.

Herodotus and even Seller, Mr. Dong is doing another project on this racetrack too. So I was wondering on two parts. First is technically, can Polyhager do coprocessor jobs as well? And secondly is from the marketing perspective, would you guys go for that racetrack to compete with the names I mentioned before?

Actually, I was a bit surprised by the because the storage proof is actually a subset of ZKBridge. We already implemented that since the beginning of our project. We're just focusing on the ZKBridge part of it. So in our product, we already have storage proof, which is already used by our customer service. So when you think about ZKBridge, we

are relaying all the block headers through the zkp generation which is exactly what axiom do we store the block header on this updated contract here and when you look at our customer service or working procedure they are going to handle the

missed transaction for users. So initially our RPC server is not so stable or not so reliable. The server may miss some transaction and the user may report to us after several hours or even after several days. So in that scenario, our customer service team has to do a storage proof, historical storage proof.

to retrieve historical transaction for users several days ago or several hours ago. So that's already being deployed internally in our team. And I think we have done thousands or even more than 10,000 of historical proof because initially our system was not so stable. And currently, our system is stable enough. We don't need to do a lot of historical proof anymore.

Yeah, I think we are more focused on the interoperability and real-time relaying of data. Yeah, so that means you guys can do coprocessor anytime you want. It's just a matter of you want to compete on this racetrack or not. Yes, we can actually release our internal customer service part of our project anytime we want.

But still, our engineer team is more focused on the bridge part. And I think it's like we don't have the capacity to start another project right now. I see. I see.

Or you guys, once you've got time, maybe just open an API or a simple SDK to make it look like a coprocessor for the other project to use. Because coprocessor is like giving me the history, a particular price or even a TWAP price of history time of Uniswap for Ethereum.

and then you can do calculations you guys can definitely do it just just an api or sd yeah we we can we can modify our bridging api so you can request historical transaction at any time you want yeah definitely we can do that yes agreed agreed so a lot of things i want to ask you is uh about a single slot finalities which recently published by you guys i think uh last month

I just wondered what is that about? Because that's like a huge concept for Ethereum. Yes. So we observed that here we were doing like 32,000 of signatures in five or six seconds. And we were wondering whether we can do full signatures.

Ethereum validator set which has about 1 million signatures in terms of signature size. So let me give you some background on the Ethereum current implementation and how we are going to handle with it. So currently assuming that these white dots are the four validator will have 1 million in terms of size and currently

Ethereum will divide them into subgroups, 32 of them, 32 of them subgroups. Each subgroup will have like 20 or 30 thousand participants.

They call it slots. Each slot will have like 30,000 participants. So that's why when we talk about full node proving, we talk about 30,000 signatures. Each slot will be in charge of one block generation. Since there are 32 slots, they name this 32 slot as one epoch.

So each epoch will go through the whole Ethereum validator set. And when you look at this, there has some problem. When you put your transaction here in slot one, you cannot immediately confirm it because there is only like 32...

thousand validators signing confirming this block and you when you talk about ethereum consensus you always want a super majority of the validator set that's that's signing this block so

you need to wait until a sufficient number of validators has signed this blockchain, this chain of blocks. For example, if slot 3 signed this chain, then basically this means that these validators agree on slot 1. So you need to wait until a sufficient number of validators or sufficient number of blocks has appeared here.

In terms of an epoch, 32-slot epoch, you need to wait at least two-thirds of the 32 slots, which means that you need to wait about 20 blocks to get confirmed, at least about 20 blocks. Actually, in most exchanges, they require like 70 blocks. So that's why...

This becomes a problem. The waiting time is too long for users to confirm a transaction. We think about this problem and we think, why do they need to divide people into several slots? It's because of networking overhead. It's very hard to gather like 1 million nodes into the same slot.

So that's why they divide it. And when you look at, when you increase the size of the slot size, the P2P network just get too large to be sufficiently efficient. We introduce a ZK-based signature. That's what we do in the consensus proof. The ZK-based signature will become much smaller in terms of the signature size. How smaller? It's like 100%.

hundreds of times smaller than the original P2P network. That's why we can enable single slot finality. We can invite millions of validators into the same committee, into the same slot, and still get the P2P network working. I see. I remember Vitalik was mentioning about the possible solution for the single slot finality. I remember he was proposing two or three

different ways. In my memory, there are two. One is, the problem is we can't aggregate more than a few million BLS signatures because that's going to be too large. It's involved with the cryptography technology to involve to have a better way to aggregate those BLS signatures. And the second way is he's proposing a super committee, like a half million or like a 300,000

validators as a super committee and then as long as this super committee signed the contract or signed the signature then we can consider this as a valid block. I think you guys tried to hack into the first way by not aggregating millions of BL signatures but using a ZK proof of these signatures

and make the size way smaller and tweak the system so you can only just prove millions of CK proof of the signature instead of the signature. One proof. Single proof. Yeah, not millions of proofs. Have you guys talked to Vitalik about this? Yeah, we have a very short conversation with Vitalik. So he has recommended some people to us.

that's working on this single slot finality. Yeah, we have several meetings afterwards with these people. Okay, cool. Yeah, I wouldn't be super surprised or excited about if you guys can help Ethereum achieve single slot finality. Then there's the other chains that are fighting on Ethereum saying you guys are actually taking too long, taking 12 minutes to do the finality. Now, if it's 12 seconds,

Ethereum will be a way better blockchain layer one than it used to. Yes. So we are trying to do this. And this technology can not only be applied to Ethereum, but we can also apply to other blockchains. So it's the same concept like aggregating or aggregating validator signatures into a smaller, much smaller proofs. That's same concept that can be applied for every single blockchain.

I see. That's very interesting. And in terms of like the roadmaps, not talking about the single finality, but in terms of roadmap, maybe this year or next year, what are the important achievements that Polyhedra wanted to reach? Okay, so there's several stuff. I think the most important stuff is we are working on the optimism chain to make it as a very fast finality.

So, older generation of bridging optimism chain may require seven days challenge period to confirm a user transaction. So, we are working on solving this issue by using our signature proving technology to invite thousands of

to attest to attest to this transaction. It's the same concept as single slot finality, but we are experimenting with a smaller scale. - Does that mean that the challenge time will be sharply reduced? - Yeah. - Okay, that makes sense. Any other interesting things? - We are also considering like open source,

open our prover to the public. It's like what the stock will do. So it's still under development. I think it takes several months, one or two months to make a developer use our product or use our prover.

So yeah, that's another interesting stuff we are currently developing. Because if we got more developer using our proof system, people may speed up the evolution of zero-node proofs. Because we are way faster than why not just native people use it. Yeah.

yeah um that makes sense um one little heads up like in terms of um collaborations and also um polyhedra well what polyhedra is doing right now is um if you're you guys are going to have a huge event in istanbul as well right we are going to have a hack zone and we are going to actually release a beta version of our uh prover to to the

developer so they can submit their code and generate their proof in in istanbul so it's part of the hackathon and we are going to also release some interesting problems to the to the developers for them to solve very exciting very exciting looking forward to it um abcde will also go to istanbul as well hopefully we can host some events together of course yeah yeah great um i think

think it's almost about the time and if there are any last minutes add-on you want to talk about or exciting news that you want to announce. Yeah, so we are very excited to actually announce our final proving and fast finality for all of the blockchains. So just get ready for the new product and

the final time the latency will be significantly reduced by our product yeah looking forward to it all right everyone um thanks everyone for joining us at this podcast and hopefully we can talk more about the polyhedra um in different occasions and stay tuned to our twitter as well as our medium thank you very much thank you very much thank you bye bye