Marco Marinelli, Horizen Labs: The Missing Piece of the ZK Puzzle | ETHSofia

[Music] presentation today is the missing piece of the Z puzzle and we're going to speak about Z technology and uh a brief introduction about myself I'm Marco I work for Horizon labs and we're doing a lot of stuff in the blockchain space and specifically we are developing zifi and we're going to go through it along with the uh the entire space of the ZK Tech so the I will say more high level definition that we see around about Z technology is the following one imagine being being able to prove that you know something without revealing any details of what you know but what's the meaning of this sentence well usually it's surrounded by a sort of Mag K but in reality it's about Advanced cryptography and to explain it to also a non-technical audience I I came across different examples and maybe the most fitting one is uh to play a game Where's Waldo so we we know that wo is in the picture over there but we don't know where is it and uh today I would like to use ZK to prove that I know where Walo is without giving you any details about his location so we can imagine that we have a friend that know where Walo is and he wants to prove it to us without revealing any additional information about his location apart from the fact that he is present in the picture so our friend tells us to close our eyes and then puts a black sheet with a hole way bigger than the image on top of it when we open our eyes again what we see is the following we see see that W is in the picture and we're sure of that but given that the sheet is very big uh we don't learn any more detail about his exact location apart from the fact that we know for sure that Walo is there so this was an oversimplified explanation and we're going a little bit more technical right now so in terms of zero knowledge proofs we have two main actors in the game we have the prover and we have the verifier the prover uh receives a private input that is called witness usually and it's uh the thing that we don't want to disclose but we want to prove and along with the private input it receives also a public input along with a verifier that that are the values used to perform the computation these inputs are public and not a secret and another part that that is optional uh I mean it's optional for Starks but compulsory for Z snarks is the thrust setup that uh is basically a trust assumption used in the setup of the proof scheme and it works by giv to the system a random number a random string that is used to compute a uh shared the secret needed to set up the prover system and in zik Nars this the result of this thrust setup is is given to the prover and to the verifier as well seeing a real world use case of what I just said we can consider Z rollups so rollups works by batching a lot of transactions into a single proof uh usually a layer two like you can see in the picture and uh the transactions in the L2 batch are then basically a proof of of the of the transactions is created and then sent to the underlying blockchain for settlement in this case ethereum so the proof is generated and then verified natively on ethereum to verify the legitimacy of the transaction that caused the state to change and uh this is something kind of new because zero knowledge proofs have been used originally for privacy feature but right now we are seeing them being used also for scalability purposes for their suance property and suance means that the proof is small and easy to verify but the given that the proof is small doesn't mean that it's a cheap to verify so the life cycle of a zero knowledge proof is that as we as we have just seen we have a Z app or basically any project that implements zik technology requesting the creation of a proof to approver the proof generates the proof this is a comp computationally expensive process and then the uh the generated proof is sent again to the blockchain ethereum where the verification algorithm is executed the proof is verified and the app goes to take the result of the verification and integrates it in the business logic of it's a smart contract let's say so what about modularity and zero knowledge proofs we have seen the rising of the modular narrative first with Celestia and data availability and now the same mindset is being applied to zero knowledge proofs as well today we're going to focus about the modularity of the proof verification so if we take the same life cycle as before we can see that this time we have a dedicated service for verifying the proof so the proof is not verified natively on ethereum but it goes through a pro verification layer that is dedicated and it's needed to offload the verification operation and then the verification layer sends the verification result to the settlement chain where the application takes the result and integrates it in the in its smart contract business logic but the question is why we should modularize why we need a dedicated verification layer well the answer is quite straightforward onchain verification of proofs nowadays costs a lot so the proof verification is checking the mathematical validity of the zero knowledge proof through a publicly known algorithm and doing that on ethereum is quite difficult nowadays because the evm lacks the pre compiles for efficient proof verification and also it consumes a lot of gas in the table in here you can see a few estimation of how much gas gas per proof is needed for its verification and the associated cost in US dollars from considering gas being 30 G and ethereum $3,000 so the range for verifying a single proof in an application is between a little bit more than $16 to more than than 100 for very heavy uh Z Starks and this is actually a problem because it hinders the use and the adoption of this technology from publicly known data we we know that uh since uh the adoption of zero knowledge technology applications that relies on it for uh for the for its properties have spent more than $60 million all time for the pro verification on chain and uh this can be somehow avoid it and that's why we are working on secy which is is a dedicated proof verification layer that provides verification for any project using Zer knowledge proofs the verify is a modular dedicated blockchain designed with Simplicity in mind and it provides two Services consensus and proof verification in an Nell Z verify works as follow it takes uh one proof from every proof scheme that uh is supported or can be integrated in a second moment ranging from classical Groth 16 or plun proofs to more let's say new and exotic proof schemes like B so the proof is sent to the verify protocol where there are native verifiers in AR and uh they provide proof verification and then store the verification result on the Chain but not only that because if the verification result is needed on on another blockchain then it's sent to the blockchain as well so the architect architectural diagram is the one you see in the picture and basically it um we start again from an application that needs zero knowledge proof verification it generates the proof and then sends the proof along with some public inputs for computation to Z verify that verifies and store the proofs through the verifiers and at this point the verification result is relayed Des sent to the underlying blockchain and uh in the underling blockchain such as ethereum we have actually the Z verify smart contract that stores that tation that are identified by a unique ID and at this point the proof uh through that tation goes to retrieve the proof verification result and then update its smart contract business logic execute some kind of actions once the proof validity is verified so with Z verify we calculated that the verif the cost saving for verification cost is more than 90% And by verifying proofs through our technology we can actually bring down the verification cost uh a lot and uh this is quite important for both projects that can use zik Tech uh more uh more easily and more cheaply but also for the overall adoption of Z proofs that uh it's um I would say it has been uh plugged by the high verification costs and uh this is uh these are two qu codes the first one is the Z verify Twitter you can follow the page being updated on the last um on the last news and the technology upgrades we are releasing and the second one is my personal telegram so in case you have any questions or curiosity you can reach out and U and I will be there also in addition to that we are launching our incentivized test net and right now we're in the phase one and it's focused on developers so if you feel like experimenting with sec by creating a Dimo application that verifies proof through it we can uh we can support you in that and that will be it thank you so do we have time for questions or okay we have some time for questions just in case you have any please okay so the question is what are the issues related uh by integ in Z verify for proof verification so actually the only trust assumption here I will say is that you are delegating trust to a third party service is decentralized we use uh we are based on substrate and we we are layer one blockchain and we use nominated proof of stake like P does so I will say that the trust assumption here is uh relying on validators not colluding with each others so use pling consensus that will be the only trust assumption here [Music]