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

This is our last keynote before we take a break here on the Satoshi stage. How's everyone feeling?

Thank you for following this stage, the best stage to this morning. No, but we also have of course the Vitalic 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 and Zcash and the Zano pool.

So, there's a lot of things to discover over these next two days. Um, but

yeah,

then without further ado, I would like to give the stage to Odisas 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 Adas.

I'm a researcher at common prefix. Uh today I'm going to talk to you about Zenif uh the new proof ofstake privacy preserving protocol for Vano uh blockchain. This 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 proofof work blockchain to translate the assumption of 51% honesty 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 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 in Bitcoin gold and this is something that initially uh pushed the Zano blockchain to adopt uh a hybrid model where they're using both proof of work and proof of stake in order to leverage some of the proof ofstake security. However, this results in a much more convol convoluted protocol. We have a lot a lot of more variables. Uh it's not well studied in the literature.

So we don't know exactly the the model where this uh pro 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 uh Zano. But if we 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 pro pure proof ofstake protocol. uh 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 mechanisms 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 preage of a header that the the h of it is less than the target. So it doesn't have anything to do with the ledger we're building using this uh this block this 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 uh the case of proof of stake in order to check this uh 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 part 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 inherit problem in proof of stake. So how we're going to do this?

We're going to design Zenif. Zenif will need some basic properties. First of all, it need to be securing the proof ofstake model. Uh what this means is that we want a leader election mechanism that is not based now on H on on H 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 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 privacy preserving part of zano 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 the in the consensus layer we're going to use roborus browse and robor genesis these are uh the first actually proof ofstake longit chain protocols uh they're wellstied 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 privac the privacy the payment engine of zorganum which has the privacy preservation and we're going to match these two protocols using a variety of crypto tools so [clears throat] starting from robor 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. They check their outputs.

They check some stake. We will see how that happens. And they they check a value and if they're eligible they produce a slot, a block in each slot uh zero, one 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 this uh these slots into epochs and in each epoch we clearly define our stake snapshot and a randomness.

So we define who are the parties that hold some money that are 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 this. I take my my output I check a VRF. If a VRF is small enough is if the 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 Roborus browse the uh the [clears throat] eligibility part how I test if I am eligible to produce a blog. 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 scalers that we use to hide the amount and [clears throat] the 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 these two. So I take my private key. I has the [clears throat] and sorry we also have the public variables that it's the epoch randomness, the slot and the difficulty. So I take my my private key I has together with the randomness and the slot the the public address of the UTXO and I get a key.

That's how we will call it ephemeral key. I also h 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 uh 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 um this [clears throat] is scaled with the amount this output I used here it holds. Okay.

So I get 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 security based on uh 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 uh 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 where we go into privacy. This is the third part. So we change the way I prove that I was eligible from robotus browse and we use uh techniques to work well with the user canon 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 uh this this output indeed has these values and this mstake 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 signature. So one time keys is an idea from cryptonode where I don't want a party to be able to tell if uh 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 I only know I I generate a private key per address and this hides my other output. I use a Penderson 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 Rick signature to hide which output I use. So I will take a lot of outputs from the from a 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 have a classic ring proof from CLAG and we're using range proofs and snore proofs the range proof will be a bullet proof and the snore proofs are uh typical snore proofs with fatir so that we don't have the inter the interactivity proof okay rink 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 coefficients.

While we will use the snore proofs to translate our inequality to uh an equality and arrange proof to show that this holds. Okay, doing this uh the verifier does not learn anything. We only have to check that indeed I'm using a decoy set that it's from the ST snapshot and it has to verify the proofs 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 elig eligibility proof that shows uh that anyone [clears throat] can verify but will not learn the amounts which I used and it will not learn whom I am and we get the security argument from the from roborus brows and robor genesis.

So this is a typical longitude chain protocol. We will have the typical properties of common prefix livveness chain quality and it will result in a consensus product. So this how did 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 identifiably spent. So I cannot uh hide the fact that I spend a staking output. This is because uh we have to be able to take a next a ST 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 a 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 go to the security part.

So we base our security arguments to the private chain attack. Actually there is a real nice paper from David Satal where they argue that the private that 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 uh [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. They don't disseminate blocks. They don't try to do anything else weird. They just try to mine faster.

So, 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 this simulation. We do it over a wide range of parameters over the over different network delays over different parameters from for payment engine. And we actually see that as we raise our K uh parameter, our common prefix parameter, the part of how many blocks we 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 it explains the protocol in details. That's all. Thank you.

Thank you so much. Do we have any questions from the audience?

May I ask why have you delved into this research out of all the topics that are outside 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 the space? How did you land here in this role and and researching this?

Actually, uh I was for a short period into AI. I did my faces on on AI

other way around. Usually people come from crypto and they go to AI. You did the other side. Yeah.

Yeah. I was doing 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 stake. 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 UIS then and he told me about probable security. This this is 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 ODSAS. 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 Vitalic stage in the Canary Club with Zano Swarm and Zcash over there. Thank you so much for being here. uce 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.