Plumo: Towards Scalable Interoperable Blockchains Using Ultra Light Validation System - Kobi Gurkan

Transcript

Yeah, it sounds good. Okay. Hello everyone. Welcome to the new room. Um, I want to just introduce Kobe who's going to be talking about Plumo. Uh, what we're going to do is we're going to do this talk and while he's speaking, feel free to ask a question in the ask a question thing at the bottom or potentially have a chat as well. Uh at the end of this session, we're going to be doing the Q&A and actually get a chance to dig in a little deeper into Plumo. So, please take it away, Kobe. All right. Thank you, Anna. Uh very, very excited to present in the ZK summit. So, yeah, I'm going to tell you a bit about uh Plumo. Plum is the light

client we've been developing in Cello. Uh it's joint work with um with a bunch of people. Uh specifically it's Merrick, Asa Michael Ariel Iran Phillip and Sai. Uh bunch of smart people that have been working on this. Um and yeah, I want to tell you about this snark enabled lifelines. Okay. So why plumo or what is plumo in general? What does it mean?

So let me share. Plumo actually means feather in espiranto. So it's a kind of play on words. Uh it means that Okay, just a second. I have a technical issue. Sorry. Okay. So it means that it's a light very very light client. Uh it's light lighter than a feather. Uh and the goal is to make a light client that is very efficient to instantaneously sync to the latest state on a chain uh without having to to download a lot of data and without having to perform a lot of computation. So let's start a bit with the motivation of why you would want such a client.

So if you look at the bitcoin chain size in general uh you can see that it has been growing steadily um all the time and it's few hundred gigabytes right now if you want to sync a full node and that's something that is not doable for normal clients to work with. So let's say that I have um let's say that I have a mobile phone that wants to sync to the latest state of the chain. If they actually want to perform full verification of the chain, which means downloading all the transactions and processing them, that's not something they can do. Uh especially if it's someone that wants to just

download the the latest state of the chain and without waiting a lot of time. Okay, sorry. I have to pause for a second because my presentation is messing up. Let me see if you can all still see my screen. Yeah, we still see it. It looks good. Yeah, it was just jumping between slides automatically. Well, I guess for from from where we're sitting, it looks pretty good, actually. Okay, cool.

Thanks. Uh, all right. So first uh motivation point uh it's hard to sync a full node. On the other hand uh we have a growing number of resource constraint devices in the world. Uh specifically if we look at mobile devices we have a bunch of them already existing in the world. Uh you actually have like 8 billion mobile devices that are active. And if you look at the numbers, it's maybe surprising, but 6 billion of them are smartphones, which means that they can run advanced software. So that's something that we can work with.

Another point to make is that there is a growing interest in something called CBDC's, central bank digital currencies. And these are currencies that are run by countries. And they're going to use private blockchains. And if we want them to be actually useful in the world, we need to we need for them to be communicated with other chains. So for example, you would want them to communicate with the Ethereum blockchain and somehow be able to transfer currency from here to there. So this is something that you would normally achieve by having a smart contract for example on

Ethereum verifying the private blockchain light client protocol. And while when you have that, you have a smart contract that can reasonably uh reasonably talk about what are balances of addresses and so on. And if we're talking about resource constraint devices, smart contracts on Ethereum are even more resource constrained than mobile phones. Things are very very expensive in the EVM. But yeah, people don't actually sync full nodes when they want to interact with blockchains today. And Satoshi actually Satoshi actually came up with a very efficient way to to sync with the

chain without having to process all transactions but still achieve reasonable security. And that's something called simple payment verification SPV. And the way it works is that instead of downloading all the transactions in the chain or downloading all the hundreds of gigabytes, uh you just download the headers of the chain and verify that the proof of work puzzles are valid and so on. And now whenever you want to make a transaction or whenever you want to query some information about the transaction whether it was included in the past and so on then you can ask other nodes to give you this transaction data and with the headers that you

downloaded you can uh you can verifiably check this. But this is still uh not perfect because if you look at Bitcoin which has a very long block time, you already need to download let's say tens of megabytes at least. And if you look at Ethereum, you have to download a few gigabytes. So it's still not exactly what you want if you want to instantaneously sync to the latest uh state of a blockchain. more more specifically if you look at the new style blockchains such as Cello then a lot of these use proof of stake

so in those chains the block time is even shorter it's a few seconds it's less than 10 seconds sometimes even less than 5 seconds so if you had to download all the headers then you would be in a bad state you would have to download gigabytes just to sync to the latest state of chain yeah So to summarize, it's just too much data for a permissionless mobile wallet that works on a blockchain. Yeah.

And it's specifically also too much data to create a trusted bridge between two chains. So one example of an attempt to do this was BTC relay. And BDC relay was a really cool project uh done by really smart people that tried to verify the Bitcoin headers inside Ethereum and it ran for some time uh successfully but the cost of maintaining it became really high partly because of the Ethereum price and partly because it's just expensive to verify each Bitcoin header.

And if you look at the current state it hasn't been active for almost two years. So it's there are already data points that show that this needs to be solved in a better way. We're not the first ones to talk about these problems. Um there are other people that have been thinking about this. So if you look at other works like Nepopa and Flagland, they also talk about how to sync to a later state of a chain very quickly. in Flagland it's even something that's logarithmic uh which is about half a megabyte for Ethereum

and they're very good works but unfortunately they work on proof of work blockchains and they don't really work on proof ofstake blockchains or any other chains that don't have a fork choice rule. So this is uh not not doesn't work for all the use cases and especially all the new proof ofstake chains. Another solution is KOD which is also a really cool solution that actually achieves higher security uh than just verifying a light client protocol. In KOD you actually verify something that is akin to verifying a full node. So you

have a snark proof that shows that all the transaction has been processed correctly and the state that you're receiving is the latest state of the chain. It's very strong. It's strictly better than SPV. But uh there is a trade-off because you have to verify all of these transactions in a snark. You limit the flexibility of what these transactions can be. So that means that you can do payments or some other simple forms of transfers but getting fullyfledged smart contracts like the EVM is going to be very hard.

Additionally in the past uh and code they used a pair of mnt curves in order to do the the proof technique that they use the recursive proof composition. And these curves are pretty expensive for our case. They're 760 bit or even 80. And that's that's makes them very slow both to prove things and verify things. So how is Plum different?

So first of all, Plum works in the context of Celos's proof ofstake protocol. And what is this cell proof ofstake protocol? If you look at the consensus protocol, it's a BFT style consensus protocol. It's similar to Cosmos for those that new that know Cosmos and essentially you have a valid a set of validators and this set of validators at each block have to sign the block header that they deem to be valid. So there is a proposer that sends a proposal for a block and if all the other validators in the network agree that this block is valid and the state update is correct then they sign

this and uh eventually if we have enough signature more than 2/3 then we can deem this block valid and propagate it to the other people in the network. And where does proof of stake comes in? every every some time there is an election that chooses what are the next validators that are going to be validating on this chain. So how would the light client for this kind of protocol look like? It's very simple. A light client would download the headers sends the genesis block. So very similar to what you would do in SPV and you could then make Merkel proofs or

Merkel queries in order to know bits of data in the chain. So Cello is also EVM based. So in the headers you have a state route and now if you want to know the balance of an address for example you can say you can give a miracle proof that shows what is the balance of this address. Now the difference between that and SPV and proof of work blockchains is that instead of verifying the proof of work puzzle you verify that each block has enough signatures.

Um and that's uh that's the way you say that the block is valid. The next thing that you do is whenever there's an election, wherever there is a new validator set chosen, you need to update your own state as a as a light client that you know what is the new validator set that you should be verifying the signature against. In order to help you with that, the validators when they perform an election include in the block header a diff which is a diff between the current validator set and the new validator set. So that means that in order to sync to the latest state in the chain, you don't actually need to write to read like the

smart contract that contains the election results and so on. You can just look at the headers to know the current validator set. But that's that is nice. That works. But like I said, if you have to download all the 5-second blocks, so a block every 5 seconds, that already becomes a lot of data. So we want to perform, we want it to be better. Moreover, if you use something like nave signatures, like ACDSA signatures, then imagine that you now have a 100 validators and these 100 validators sign the block. Let's say 70 of them sign more than 2/3

and now each block would contain 70 signatures at least or something like that. And that grows very quickly. So that's not something you want to do. So how does Plumo improve on this? The first thing it does is it introduces epoch based syncing. And what it means is that you can't perform election in every block. You can only perform elections at epochs. So in the cell protocol, it's around 17,000 blocks. And that means that an election occurs once a day.

So if you want to sync to the latest state of the chain and to know the current validator set, you only need to download these blocks where elections are performed because in other blocks the validator set doesn't change. So you can skip them if you don't care about their content. The next thing we do is we use BLS signature aggregation. And this is something we'll cover later. Don't worry about it. But essentially instead of having 100 signatures or 70 signatures in a block, BLS signatures allows you to non-interactively aggregate them into a single signature.

Uh so instead of having 70 signature in a block, you have a single signature and the bit map that says which are the validators that signed that participated in this signature. So that's already a great reduction in size in both of both of these solutions. But this still wasn't enough for us. So that's where snarks come in. So now instead of downloading all of the epoch blocks, so a block each day which contain a single signature, we want to do better. We want to download maybe let's say that I join the cell network after 6 months. cell the cell network has been running for six months

now. So I don't want to download a lot of epoch blocks in order to sync. I want to download a single snark proof that just shows me the latest state of the chain. So that's uh the snark related innovation that luma uses. Let's recap. What are we trying to prove? I quickly went over what is the lifeline protocol that we want to prove and that's exactly what the snark does. It essentially verifies that the light client protocol uh performed correctly and saves you from downloading all these

different epoch blocks. Essentially, you can imagine that instead of running um instead of downloading all these different epoch blocks, you can just receive as an input let's say the validator set that existed in the genesis block and the validator set that uh has evolved after six months of this this chain running and you don't have to see any validator set in the middle. So you receive this input validator set, output validator set and a proof.

So in each epoch in the proof what are we trying to prove? So the first thing we want to show is that in each block we aggregate the public keys from the header according to the bit map that exists in the header. The second thing we want to verify is that that each block um was signed by more than 2/3 of the validators. We want to check that this is the next epoch and not the previous one. We then want to make sure that this epoch is encoded correctly and hashed to some form of hash to group which I'm going to cover soon in order to verify the BLS signature on them. Now if we perform these steps for each epoch

inside a proof and we perform many of them inside a single proof that means that I can completely hide all the intermediate processing from clients. So how would you do such a thing? So a first approach would be to use recursion. And recursion means is that let's imagine that you have a proof and in each proof you do this process and then in the next proof you don't only do this process again for the next block but you only you also verify a previous proof that the evolution of the valator set is what

you expect it to be. So let's say that proof zero talks about the evolution from validator set in the genesis to block one and proof one talks about validator set one to validator set at day two. Then when pi one is produced the only thing you have to show now is validator set at the genesis validator set at day two and pi 1. You don't have to see pi zero anymore. So that's nice.

But you can also do something that is simpler. You can do you can run a bunch of epoch transitions inside a single large proof. And whenever you run out of space in this proof because of efficiency reasons and so on, you can create a new proof. And now whenever you want to make sure that these two proofs talks about the same the same chain you need to see that the output of proof zero and the input of proof one line up. So let's say that proof zero is between time zero and two months. Proof one is 2 months to four months. You just need to see that the

validator set that was output at the end of two months is the same one that was input at the beginning of the two months for proof four. So that's already nicer. But I just mentioned a lot of motivation. So let's talk about the math of BLS verification. So BLS verification uses pairings um and it uses some elliptic curve operations and it has a few interesting properties that make it attractive for these kind of use cases.

So quickly to recap how BLS signature properties makes things easier. We can look that we can see that one signature verification is the simple pairing equation. You have a signature sigma and you have a message that is hashed to this G1 group in this uh elliptic curve and you have a private key X and public key XG and this is the way you verify BLS signature. But if you have a bunch of signature on the same message, you can actually just add up all the different signatures and add up all the different

public keys and still perform just a single pairing equation that involves only two pairings. So that's a nice property. Also, if you have multiple signatures on a different message and also potentially different signers, you can also do this thing better than just doing two n pairings naively. You can also add up the signatures. But on the right hand side, you perform a multiplication of n pairings. So it's the hash of each message and it's also the the aggregated public key for each of

these different signers. Another optimization that you can make is instead of doing two n +1 pairings, you can actually just run the product of n plus1 miller loops and just run the final exponentiation once and check that they're equals to one. that these are standard techniques. So now we've talked about how we actually do these things in general. So we need to verify BLF signatures inside the snark and that's not something you can usually do because running pairings inside the snark is something that is problematic.

So how you can do this? In order to do this we use depth to recursion. So we use a pair of curves that has been introduced by the smart people of the Zexi paper and these are a pair of curves that such that we have a good security curve BLS 12 377 that allows us to do reasonably sized BLS signatures and that's what we use for BLS signatures. But there is another curve, a curve that embeds BLS 12377.

And this curves allows us to create proofs about BLS 12 377. So we can actually do pairings um inside the snark proof that is created on SW6. But we have another problem. If you remember, I mentioned that in order to verify a BLS signature, we actually have to hash to group. And what does that mean? It means that we have to take a message, which in our case is going to be the validator set changes uh the election results essentially. And we have to create a a a point inside the G1 group of this elliptic curve that such that we don't know the discrete

logarithm of. So some people make the mistake of trying to hash the group by just hashing the message into some random number and then multiplying it by generator. But that's insecure. If you do that, you can actually create fax signatures and that's not really good without knowing knowing the private key of course. So but alternatively if you do this outside of snarks it's easy. You just use something like Blake 2 and then try to interpret the random bits that you get as a valid xcoordinate and then you get the matching y-coordinate. You choose one of the two according to another random bit and

eventually you get a point that you don't know the discrete logarithm of. But running Blake 2 inside the snark is very expensive and it cost about 20,000 constraints per 5 12 bits and our validator set diffs are large. So running this inside snark is going to be hard. So in order to cope with that we use a hybrid hash function. So instead of doing directly Blake 2, we first compress the message. We take the message, the large message, we run a collision resistant hash function. And this hash function is actually the boho wood variant of Peterson hash that

Zikesh developed for sapling. And this is only collision resistant. So we can only use it to compress the message. We cannot use it as a as a random oracle. essentially we cannot derive random bits out of it. So after we run this collision resistant hash function we run Blake 2 and now we can derive random bits that allows us to uh to derive this point that we want. Of course later on we need to clear the co-actor and so on but these are easier steps. This was the crucial part right.

So let's talk about how these things look like in uh in real life. So first of all we we we should say probably thanks to the to skiper lab which developed uh the amazing Zexi library that we base a lot of our work on. Now all of our code uh that implements all of this protocol is also open source. So if you want to do something like this uh yourself or integrate something like this, feel free. We we can share the links later.

And we we are happy to say that we've contributed a lot of this work back to to Zexia already. So if you want to do point compression or this boho wood efficient variant of Peterson hashes or smaller than gadget and so on, you can already use xi to to do them. Right? So how does this work in real life? If you look at the numbers that we have here, these are numbers that show how much time it takes to generate the proof.

If you look at the proof time that runs on this S SW6 curve, the one that does the heavy work, you can see that if you want to run for let's say 180 epochs, which corresponds to about 6 months, then it takes about two hours. And that sounds like a lot, like wow, that that's a lot. But that's not really bad because this is something you have to to run once. So in contrast to for example solutions like other solutions, you only need to run this let's say every few months. So you can use whatever strong machine you want you you want to do that. You don't even need

zero knowledge. So you can do it on any machine. So just boot up the strongest machine that you can and compute the proof. And that's what we did. We booted up a Google Cloud machine that has 160 CPUs, 3 and a half terabytes of RAM, and it takes there two hours to generate a proof, but that's okay. And the proof size is also okay. It's about half a kilobyte and a bit of data to encode the validator sets as inputs and outputs.

as to verification which is actually what we wanted to optimize. We tested mobile phones. Uh so we took the weakest phone that we could find on browser stack which was the which was the Motorola Moto G2 and even on this uh weaker phone verifying this proof took about 6 seconds which is not that bad. uh it's still very very fast to sync and you didn't have to download a lot of data and on newer phones it's almost instantaneous to sync in the context of bridging or this these CBDCs or just crosschain communication

this is also realistic so if you assume EAP 962 which talks about generic elliptic curve computation in Ethereum or equivalent APS that talk about specific curves like the specific SW6 curve then you can see that this is already realistic to verify these proofs in Ethereum. So it would cost about 4 million gas to verify a single proof that could spend any month any amount of months that you want. And then once you have the state route in this in the output of this proof or more correctly assigned state route then you can just do miracle proofs and

see balance of addresses or fields in a smart contract and so on. So if you look at the gas prices today it's going to cost about $6 to do this verification. So that's nice. Um so we're almost at the end so let me just cap uh some possible improvements that we are thinking about and before that maybe I should mention that we're exploring how to do this trusted setup for these large curve efficiently. So people know about doing trusted setups.

They know about it from Zcash, from Ethereum, from Falcoin and Aztec and so on. And here we need a trusted setup that is pretty large on a pretty large curve as well. So let's say 2 to the 26 constraints and so on. And this already takes days to to do on uh on a normal PC. So we're looking for ways to to improve this, but we actually already have code working that uh can perform toet setup for any x curve.

Um so some improvements that we've been thinking about are these just replacing the S SW curve with another curve that is just more efficient. This is a curve that has been introduced by the smart people in EY and I think you're going to hear about it today. So I'm not going to talk about it a lot. Another another approaches is to use other kinds of recursion. So instead of using the zaxis style to depth to recursion, we can actually use full depth recursion.

So something like half pairing halo that kod has been pioneering. But that's a bit more novel. So we chose a more conservative approach. But eventually when these things become more widely accepted we could do something like this. We could look at other approaches to recursion which is PL lookup which is also going to be described today by the SEC team and we can look about how to improve the lifeline protocol. So for example to answer questions like was transaction E X included in some block of the past? We can't answer that right now. We can only answer questions about the retest state route. So if you want to answer these kind of questions,

we have to introduce more data into the protocol. Yeah. And that's what I had to tell you. Sure. Cool. Okay. So I'm going to open up the chat now. Yeah. So, do you want to check out the ask a question? Yes. Okay. Clapping. This is what you miss a little bit from the uh from the not live version. Yes, I even got the c which sounds very cool.

Okay. All right. So, let's see. Questions and answers. Would it be fair to say that Plumo does not solve the data availability problem for light clients? If so, how does Cell address or mitigate the data availability problem for light clients? That's a question by Justin Drake. Yeah, and that's a very good point. It does not uh suppliability problem. And in order to cope with that, we actually have in the cell protocol some incentives for full nodes to provide data for light clients. So I hope that gives some intuition of why it's going

to be better. But we also know that light clients usually have enough enough sources to ask data from. But yeah, so these combinations are good. All right, the next question by Alistister. Are the signers public? I thought you were okay. I thought you were using aggregation rather than threshold BLS for accountability. If not, why not use threshold? That's a great questions. The signers are indeed public and if you look at the election results you can exactly see who are the signers and we do use aggregation that's why we

include a bit map in each of the blocks to tell us what are the public keys that participated and then you have to aggregate these public keys in order to verify the signature. So threshold BLS is very nice but then you lose two things. You lose accountability. You don't know exactly if someone uh you don't know exactly if someone provided the wrong signature or whatever. And you don't know exactly who participated to provide rewards. So that's a bit of a problem. And the other thing is that it's pretty hard to set up. In order to set up threshold BLS, you need to do a DKG. And that's something that is just significantly harder than doing

aggregate BLS signatures. So we kind of emulate fatial BLS. Okay, the next question. Uh what is an MMR? Yeah, I didn't say an MMR is a miracle mountain range and you can actually think about it just as a miracle tree. And in flagline they introduced this MMR as something that accumulates all the block headers that existed in the past.

So if you look at the last block you can just have this Merkel root that allows you to make efficient queries about past blocks. So in our case, if we look at the latest block, we have a signed M. You could if you improve the protocol or if you change the protocol, if you really care about it, you could look at the signed MMR root and just do queries about past transactions and past blocks. All right, I think we have a last question.

Have you thought about using a stark for the outer layer inside of a snark? Starks can be done in prime fields of any size. So you would not need to deal with funny curves and they would have lower prover costs. Verifier costs would increase but starkware has shown that fitting a stark inside an Ethereum block is possible and that was pre-installable. That's a question by Vitalik. Yeah, and that's a very very good question. uh we have been thinking about these kind of things and we've eventually opted with snarks for a few reasons and I think the main reason would be that we really really wanted to optimize for both very fire computation and the data that you have to download

and when you use a stark you you improve improver cost which is actually not our problem and you would make proof sizes much larger especially when you you want to make proofs about these large amount of epoxes we want to do and it would also make the verifier cost increase. So we really wanted to optimize for the best verifier cost that we could get. Um okay so I think we have another question. Do we have time?

I think we can't hear you. Sorry. Sorry. I was muted. Um uh I think uh we have this is probably the last question that we can do here. Sounds good. And then we'll wrap. Uh sounds good. So the question is by Louis. In the flag plan paper they claim you could adapt client for any consensus algo. Have you looked into this direction? Yes, we definitely have looked into this direction and it's not for any consensus algo. It's for any consensus algo that has an equivalent of a longest chain rule. And to be honest, I've even asked the

authors about this. And the only other reasonable consensus algorithm that might work with this would be Oraorus that seems to have a longest chain rule, but the others have not worked out the full details of how it would work. So, it's not sure that it could work for the use case at all. All right. So, I think that ends our uh session on Plumo. I want to say thank you so much. You can see a lot of claps in the chat. Y uh and next up is Justin Drake uh talking about Plunk. I'm going

to head over there now and get them set up. Okay. Thanks for listening everyone. See you soon.