ZK10: Incremental Proof of Solvency with Nova - Enrico Bottazzi

Transcript

[Music] so hi everyone my name is enrio batti I work at PSC and I'm a technical lead at Suma Suma is a proof of solvency protocol and today I'm going to explain you how we use Nova inside Suma so I think like the main main takeaway today is that we are not really only using Suma to per performance so most of the time you see it like a different back end that you can use to speed up your performance but actually in this case we're going to use Nova to uh increase the security of our protocol so we are

like leveraging the characteristic of Nova to for an application basically so before I want to give you some overview of what proof of solvency is so we are operating in the context of centralizing exchanges from like the two main main pillars are assets and liabilities from the point of view of uh centralized exchanges the liabilities are the deposit of the user so these are denominated in different currencies and the main thing here is that this deposit do not live in onchain so they just live in the database of the exchange and on the other side we have the assets so these are actual cryptographic assets

that are controlled by the wallet of the exchange they do live on chain and the ru R theoretically is that they should map at least one to one the deposit of the user for each currency so the proof of solvency is like a cryptographic proof that is generated by The Exchange that is proving that this assets are greater than the liabilities at a specific moment in time so it's important that uh the specific moment in time thing is like just a snapshot in time so this guarantees the solvency of the exchange how how does it work so this is not really just specific to Suma it's more like how generally work for every protocol the centralized exchange will

first commit to their asset at a specific Moment In Time T they will commit to their liabilities so this commitment can have like more or less privacy according to what you want to do like uh some ZK stuff later or not but you can think as basically a Nash or like a root of a mircle tree at the the third step here is the proof of solvency so the exchange will generate a proof that the assets are greater than the liabilities according to the commitment performed before and this is given out to the world so like everyone will be able to verify it everyone will be able to to see that but there's like a a further step so as you see the first

step is that the exchange will generate a proof for Alice so this is like a proof specific for each user that is telling Alice that she has been included correctly in the liabilities commitment so correctly means that she has been included with the correct balance so you can see already like a problem here because if uh Alice doesn't perform the verification so if Alice doesn't uh is not involved in the in the protocol then the cental exchange can basically fake the liabilities at the step two and uh and get away with it so the

security of this protocol relies heavily on the user verification and the problem is that we cannot really avoid that because there's no General consensus on the state of a user in a centralized exchange is just basically unilaterally decided by The Exchange so this is an issue and the second I mean the consequence of that is that if the user doesn't perform the veric ification the centralized exchange can cheat and how can they cheat they can remove the balance from the liabilities commitment or they can or like the consequences that they can achieve a valid solvency without actually having enough assets to

cover all the real liabilities and uh as I said before this is a process that is uh related to a specific moment in time so ideally this should be performed very frequently and there are like many rounds of proof of solvency performed so like realistically what's happening now is that some exchanges are doing it on a weekly basis but actually with our protocol we can also achieve it on a per minute basic basis potentially so yeah I wanted like something else that I want to point out in in this slide is that they each round do not really talk to each other so are kind of independent entity that are not

related there's a very interesting concept that was described by Costas in a in this paper that is the failure probability so this is basically theorizing the probability that a prover misbehaves while going undetected so in this case the Prov is an exchange and the misbehavior is like understating or removing the balance of some user so this graph is basically like the distribution of this fail probability we're going to focus on this point in red just to like it's randomly chosen but just to give you an idea it means that we are operating on the red curve which means that this exchange has

1 million user the x axis 2% means the amount of user that are performing the verification so in this case it will be 20K uh the C parameter indicates uh how many users like what percentage of user The Exchange cheated on like the how many user have been manipulated in this liability 3 so is 0.01% which means 100 user have been manipulated their balance and on the y- axis we see the failure probability in this case is around 0.13 so it means that there's like a 13% chance that the exchange can perform this malicious

action and go undetect it so as we said before there are many rounds and as you can see for each round we if we keep this assumption that there are like 20K user performing the verification we see that the fail probability is always the same 13% so now finally we get to Nova what what we achieve using Nova but first very brief introduction to no Nova so Nova as you know is a folding scheme we have like three main components here the Z is like the state so is a state that can start with zero and then is updated

at every every step so like Z1 is like the state uh updated on uh on the instance F so f is like the the function that we are applying at every step and on the right you see like the W which is the private Witness applied at every step so if you go at the end we have like ZN which is the state after n steps and we also have the proof Pi which is like basically a very a proof that is able to to verify that this all state transition from 0 to n was performed correctly according to this instance function f so how we apply Nova inov of solvency

so we keep as the Z is like the round of uh the state of each round the function instance F that is applied at every every step is the inclusion and the private witness is the proof of inclusion for a specific user at each round so you can see like basically every step in this Nova proof is a round of proof of solvency eventually you get this proof Pi that is still very fast to verify is comparable to like a proof of inclusion that we used in the previous design but it contains a lot more of information so rather than containing just the proof of

correct inclusion in a single round it now contains the proof of inclusion in several rounds up to round n so now I want to give you like the what is like the added security that we gain using Nova so still we have so we start round one there are still like U 20K user performing the verification and the failure probability is still the same so it's the same scenario as before but what is the difference here so let's consider that we are operating in the hypothesis that for each round there are still 20,000 user performing the verification but this user do not repeat

so it's just like a a simplification to let you understand what's the benefit so now for round two there are 20,000 user performing the verification so the failure probability is still 13% but if you see like this 20,000 new user are actually performing the verification also for round one so we kind of decrease the failure probability of round one to 1.6 because now there are 40,000 user performing the verification so we see that the point in red is kind of now going to zero which is the failure probability and and if we apply another round we see that for the latest round the failure probability is still the

same but like the it it decreases for the previous round and it decreases even more for the first round so now we get into a situation where like for round one we have 60k user performing the verification and the failure probability is close to close to zero basically and it goes asymptotically to zero so what are the conclusion of this present ation like thanks to Nova user can verify their correct inclusion in multiple rounds all at once so I think like also a more General takeaway is that Nova is not only useful for speed for increasing the performance but you

can actually leverage this uh IVC characteristic to apply to your application logic so in this case the user verifying approv at the most recent round is actually decreasing the failure probability of any round in the past so it's like the exchange is more accountable for every every kind of malicious action they perform so they are more likely to be detected and this can lead to a more secure let's say crypto world where like exchange do not blow up and uh last thing is that this wasn't only like a theoric application but we actually

implemented that in Suma so this QR code is like the pr that basically apply this changes thank you thank you for that any questions we have one here thank you enrio for the presentation um on one of your last slides you were talking about detecting exchange exchange exchange are more likely to be detected is there a way to such that the exchangers cannot cheat in the first place where they cannot even take the assets from onchain unless they generate a proof of some sort okay so um like the problem is that let's go back to

maybe this slide no not this slide this slide so the the point is that like ideally when they generate this proof we we should try to create a system where they cannot cheat so they can generate this proof only if uh if everything is correct but like for how centralized exchange are designed there's no really way to enforce uh um the correct State on the liabilities so they can just say okay yeah I I remove your balance from my database and you you have no way to to to verify that this happen so let's say ideally they could like you know pin each user

database on chain but is basically then building a decentralized exchange so I think this is like one of the the constraint that you need to operate with when dealing with like centralized entities where like the database is basically just an opinion of this centralized entity any other questions um you mentioned that the property of decreasing probability comes from IVC rather than Nova so have you considered any other implementations of ivcs like full fully recursion Atomic accumulation yeah yeah yeah yeah like the the Yeah we actually tried to do um aggregation in uh in

L2 which basically I mean it gives the same property but at each step F you're not only verifying F but like you're verifying a proof from the previous step but it's like way more expensive like maybe I don't know to give you an idea like aggregation in L2 for this small circuit which is just a bunch of Ashes will take uh maybe between 30 second and 1 minute for each step but while Nova is like very like almost uh few hundreds of millisecond so it was better for performance was also better for um I guess developer

experience I I want to mention that this old Nova thing was uh applied using Nova Scotia by nin so it's a very great tool if you want to experiment with Nova also where are the proofs uh produced at the final layer verified where yeah like in which context on onchain or yeah yeah okay yeah good point in this case it's offchain because like this uh yeah I don't want to go go back again but like the the user verification can be performed locally it doesn't need to be on chain but if you wanted to do it on chain I think this might be problematic you need some other compressor like some snark that is compressing this Nova

proof so you cannot just take the NOA proof and verify the chain because it still is sucin but it's not suent enough for onchain verification one more quick question otherwise oh yeah um for this proof of solvency do you have any assumptions on um uh for example the failure for the failure percentage do you have any assumptions on um like every user holds the same amount of money or that sort of thing so sorry can you can you elaborate more yeah in the Assumption of the failure mode um do you assume every uh

say depositor uh has the same amount of money I guess in my head I'm thinking one user could have like a huge amount of money but they never bothered to check it ah okay yeah yeah yeah okay I think like in the I think this uh this failure probability you can check the paper but I think they assume like uh that like the the probability that a user verify is equal no matter like their balance so yeah I mean like in the real world of course there are user that are more incentivized given their stake to to perform this verification and user that won't matter so now like this failure probability graph assumes that is a there's an equal incentive for each user to perform the

verification all right thank you very much ero