Zano, Common Prefix & NTUA | Zenith: Zano's Path to Pure Proof of Stake - Odysseas Sofikitis

Transcript

All right. Well, this is our last keynote before we take a break here on the Satoshi stage. How's everyone feeling? Woohoo! Thank you for following this stage, the best stage to this morning. No, but we also have of course the Vitalik stage. So, don't forget those people in the in the foyer we have a lot of best pearls and projects that are presenting their stuff. And of course, if you've already ventured out and gone to the Canary Club where you can see Swarm, uh and Zcash, and the Zano pool. So, there's a lot of things to discover over these next 2 days.

Um but >> Yeah. >> then without further ado, I would like to give the stage to Odysseas who's going to tell us more about Zano's actually full migration to proof of stake. Take the stage. >> Thank you. Hello everybody. Uh I'm Odysseas. I'm a researcher at Common Prefix. Uh today I'm going to talk to you about Zenif. Uh the new proof of stake privacy-preserving protocol for the Zano uh blockchain. This is a work uh developed in collaboration with the Zano team.

Uh before getting into the protocol, I would like to give some intuition why we're going to do this migration. So, >> [clears throat] >> there have been a lot of discussions including this place about the security of proof of work and security of proof of stake. And although a lot of these points are opinionated, one of the few things that are objectively true, let's say, is that it's difficult in a proof of work blockchain to translate the assumption of 51% honest state to the resource used to maintain this security.

So, although you we do believe that the majority of money can be in honest hands, this does not translate to the uh majority of hash rate being in honest hands. And hash rate can be the price of hash rate can change and will not follow every time the the value secured by the blockchain. So, in smaller chains, we have seen 51% attacks like in Ethereum Classic and Bitcoin Gold. And this is something that initially pushed the Zano blockchain to adopt a hybrid model where we're using both proof of work and proof of stake in order to leverage some of the proof of stake security.

However, this results in a much more convoluted protocol. We have a lot of a lot of more variables. It's not well studied in the literature, so we don't know exactly the the model where this protocol sits on. And it has a a bigger attack surface. So, the goal is to have one mechanism, proof of stake specifically, and keep the privacy-preserving part of Zano. But, if you look at the ecosystem out there, most of the privacy-preserving chains depend one way or another in proof of work. And there is no widely deployed pure proof of stake protocol as far as I know for the time being.

So, why is that? The answer is really simple if you look at the consensus mechanism of proof of work and proof of stake. So, in both protocols, we have a mechanism where every party checks a random value. And if this random value is less than a target, we allow this party to produce a block, broadcast it to the network, and extend the chain. In proof of work, this is a pre-image of a header where the hash of it is less than the target. So, it doesn't have anything to do with the ledger we're building using this this block this consensus mechanism. So, >> [clears throat] >> the consensus layer and the execution layer are completely detached, and then

we can easily use our known crypto tools to keep the execution layer private. On the other hand, in the case of proof of stake, in order to check this this election mechanism, I have to consult the ledger itself. I have to see if the party that produces a block holds the money that it says it holds, and if it allows them to build a block. So, in proof of stake uh an eligibility proof, that's how I'm going to call the part that I'm allowed to produce a block, looks like that. I am party P. Here is my public key. I hold this stake. And if I compute my VRF, I get an output below the target.

But we have to translate this to something like there is a party that holds some stake. We don't know how much stake. It is eligible for this slot, and it produced a block. So, this is uh this is an inherent problem in proof of stake. So, how are going to do this? We're going to design Zeno. Zeno will need some basic properties. First of all, it need to be secure in the proof of stake model. Uh what this means is that we want a leader election mechanism that is not based now on hash on on hash rate, but it depends on the amount of stake you hold. We want the probability of you getting elected to produce a block to be proportional to the stake you hold.

We also want this lottery mechanism to be ungameable. You you you cannot bias this lottery mechanism. You cannot predict it, and it's still fair in a broad sense of the word. And [clears throat] lastly, uh as we said, we want to keep our private uh privacy-preserving part of Zeno. So, we're going to do this using already established protocols, and we're going to use different protocols for the consensus layer and different for the >> [clears throat] >> execution layer. In this in the consensus layer, we're going to use Ouroboros Praos and Ouroboros Genesis. These are uh the first actually proof of stake longest chain protocols.

Uh they're well studied. They are provably secure, and we understand the model under which they can be deployed and the conditions under which they're secure. And we're going to keep from Zano the privacy the privacy the payment engine of Zcash which has the privacy preservation one. And we're going to match these two protocols using a variety of crypto tools. So, starting [clears throat] from Ouroboros it's actually pretty simple protocol. We will have a timeline. The timeline is splitted into slots.

And in every slot a party tries to produce a block. We check our outputs, we check some stake, we will see how this happens, and we we check a value and if we're eligible we produce a slot a block. In each slot 0 1 or many parties can be eligible to produce a block. But only one of these blocks will end up in the longest chain. Now we bundle these uh these slots into epochs. And in each epoch we clearly define our stake snapshot and our randomness. So, we define who are the parties that hold some money that was eligible to produce the block. And we use randomness to randomly select out of these people who will actually produce the block.

So, it looks like we like this. I take my my output. I check a VRF. If a VRF is small enough is if your VRF output is small enough, I can produce a block. I attach a proof that I actually was eligible and I broadcast it to the network. So, we're going to take from Ouroboros Praos the the eligibility [clears throat] part. How I test if I'm eligible to produce a block. And this will look like this in our case.

I have tried to simplify it so that I don't bore you with too much crypto. We will have some secrets that are about the output that I'm going to use to produce a block. These will be my private key and these are scalars that we use to hide the amount and the [clears throat] type of the transaction. These are Zano specific so it's not necessary for the consensus part, but it's also the hard part to match with two. So, I take my private key. I hash the >> [clears throat] >> Sorry, we also have the public variables, but it's the epoch randomness, the slot, and the difficulty.

So, I take my my private key. I hash together with randomness and the slot the the public address of the UTXO, and I get a key image. That's how we'll call it, ephemeral key image. I also hash all of this together, and I get the header of the previous block. So, now I have a value which only me can calculate because only me knows the private key. And I have also this ancestry pointer to form a chain. And I check from this value that only I can calculate if it's less than my target. So, here is my target. And this is This [clears throat] is scaled with the amount this output I used here it holds.

Okay, so I get a a lottery mechanism where only I can see if I'm a winner or not. And this lottery mechanism is also scaled with the with the amount of stake I hold. So, we've done with we're done with the uh the security-based on on stake part. Okay. Now, the problem here is that a lot of these variables here are secret. We want to keep them secret because we want to keep the privacy. So, I have to create proofs that indeed this output that I used here holds that amount. I have to not show that I actually am using this this UTXO, [clears throat]

and I have to see to show that all of this is well constructed and actually uses the values of this UTXO. And this we're going to privacy. This is the third part. So, we change the way I prove that I was eligible from Roboose proofs, and we use uh techniques to work well with the ZK-SNARK part. So, what I have to do, as I said, is so that I know the private key of the output that I'm using in this snapshot. This This This output indeed has these values and this much stake.

The inequality holds. And all of this is well constructed. None of None of the None of these may be revealed, obviously, because we want the privacy. We're doing this using one-time keys, commitments, and ring signatures. So, one-time keys is an idea from CryptoNote where I don't want a party to be able to tell if if I am the owner of multiple outputs. I don't want to I don't want them to be able to correlate outputs with each other. So, instead of using the actual keys that I'm using that I own know, I I generate a private key per address. And this hides my other outputs.

I use a Pedersen commitment to hide the the amount of the output. So, this is the amount, and this is the the hiding mask. And I use a ring signature to hide which output I use. So, I will take a lot of outputs from the from the stake snapshot, and I will do a ring signature over them to only show that one of these outputs was eligible. And how are How do these proofs work? We have a classic ring proof from Seal Sag, and we're using range proofs and Schnorr proofs. A range proof will be a bullet proof, and the Schnorr proofs are uh typical Schnorr proofs with uh Fiat-Shamir so that we don't have the inter- the interactivity part.

Okay, ring proofs will show that indeed one of the outputs is uh >> [clears throat] >> is uh eligible. It will not show uh which output, and it will show that these secrets uh were [clears throat] the correct commitments. While we will use the Schnorr proofs to translate our inequality to uh an equality, and a range proof to show that this holds. Okay? Doing this, uh the verifier does not learn anything. They only have to check that I indeed I'm using a decoy set, but it's from the stake snapshot, and it has to verify the proof.

And also, obviously, that the block extends the longest chain. Okay. So, we get this construction where we have a leader election that was private that only I can calculate. I have an eligibility proof that shows what anyone [clears throat] can verify, but will not learn the amounts which I used, and it will not learn who I am. And we get the security argument from the from Ouroboros Praos and Ouroboros Genesis. So, this is a typical longest chain protocol. We will have the typical properties of common prefix, liveness, chain quality, and it will result in the consensus protocol.

So, this is how do we design the whole thing. Now, this obviously does not come with no drawbacks. The most significant one is that we have to explicitly say which of the outputs we're using are staking outputs. And these staking outputs have to be identifiable spent. So, I cannot hide the fact that I spent the staking output. This is because we have to be able to take a stake a stake snapshot and know which of the which of the UTXOs can still be used and which cannot be used.

>> [clears throat] >> Because if we if we didn't do that, because of the privacy preservation part we had in the payment engine, we wouldn't know that the stake was a staking output was indeed spent at some point. So, somebody could use it although they had spent the money. And now we'll go to the security part. So, we base our security arguments to the private chain attack.

Actually, there is a really nice paper from David say it all where they argue what the private what this specific attack is the worst attack for longest chain protocols. So, we base our security argument there. What we do is we simulate an execution of the protocol. We do a Monte Carlo simulation. We do multiple simulations with an >> [clears throat] >> with a desired percentage of failure. And what we do is we have honest parties mining on the same chain and the adversary mining in private. We don't disseminate block. Blocks we don't try to do anything else with. We just try to mine faster.

So, I'm not mine because we're not in proof of work as we as we established, but produce blocks faster. Uh and anyone who produces first K blocks wins. And we do the simulation. We do it over a wide range of parameters over the over different network delays over different parameters from our for payment engine. And we actually see that as we raise our K parameter or common prefix parameter, the part of how many blocks you have to chop off from the end of the chain, we see that we're able to tolerate close to 50% which is what we want.

So, this is what we get. We get a a secure protocol which is private. It's stake proportional and secure. That's all and here is the QR. I don't know if you can see it. If you want to read more about it, there is a whole write-up and explains the protocol in details. That's all. Thank you. >> Thank you so much. Do you have any questions from the audience? May I ask why have you delved into this research out of all the topics that are out there in crypto? Like why this one?

>> Me personally? Well, I find it fun. I find fun breaking things and fixing them. I find fun the math behind proving things secure. And also the product is something that I'm confident I can use. I know that it will not break, and I'm confident in telling people to use it. >> Have you looked at um How did you How did you get into this space? How did you land here in this role and and researching this? >> Actually, uh I was uh for a short period into AI. I did my thesis on AI.

>> It's the other way around. Usually people come from crypto and they go to AI. You did the other side, the other way >> Yeah, I was doing uh computer vision stuff, but as I said, I wasn't confident that what I I produced was working. I felt like, well, this is a huge mistake. I felt like smashing my head on the keyboard until something worked. And then I said, "Oh, look, something worked. It has a a good signal-to-noise ratio. It will probably work every time." I didn't like that. I met Yiannis as well. And he told me about probably security. This This what I really liked, like getting into the math and showing something secure and be confident about it.

That's all. >> Well, thank you so so much. Round of applause for the Odysseas. Thank you. >> Thank you. >> [applause] >> And that's a wrap for That's it for common sense. No, I'm kidding. It's a wrap for this uh for the Satoshi stage for this morning for this morning. We have a 20-minute break, so don't go too far, but as uh as you may know already, we have the entrance with a few of the things that are happening, the Vitalik stage, and the Canary Club with Zano, Swarm, and Zcash over there. Thank you so much for being here. See you back in 20 minutes, where it will be a different MC, and we'll be leaving you. You'll see me running around. Uh Colin will be moderating uh the stage, and the next one is is was crypto made for AI agents,

not us, not people. All right. See you later.