zkSummit - Lightning Talk: Lucas Vogelsang (Centrifuge)

Transcript

hello everyone I'll be talking about a small library that we've been building has nothing to do with zero knowledge proof itself but hopefully is something that will show you how you can use your knowledge proofs specifically like how you can deal with large amounts of data that you would need to very fine and proof or need to work with and improve if you think of how like mostly your knowledge proofs start out with is like you have some sort of miracle tree and you need to make a proof about some attribute a leaf in a tree in the cache that is like your your so if your your coins that you

have your your commitment other in in what we're doing it's sort of data large large sets of data just a little bit of background information so we built this at centrifuge where we are building a decent price protocol for companies to interact so this means they send invoices and purchase orders back and forth and sort of the very basic protocol is that you have Alice and Bob they exchange data off chain they sign each other's data and then that that data gets committed on chain and this is our merkel route so when i talk about

data this is this is described in in a proto in protobuf protobuf is a schema schema binary format that is developed by google they try to build something that was better than json or xml to build their api's with we're using that as a way to sort of have a very easy highly efficient serializable data and data structure and then a way to sort of construct a Merkle tree out of out of something that looks roughly like this so if so what we do is we have this instead of like using a miracle tree to prove that a transaction is part of a set we

actually can make a statement about a certain and in our case not a transaction we just just talk about documents so it that a field is part of of a certain document so what we do is we take and this is an example an invoice we take each and every field we create a leaf for each field we suppose we encode the the name of the field so the the amount with the value and the salt we hash that and then that's that's our leaf so at a later point in time if you want to if you want to make use this merkel route to prove something about your off chain document what you do is you say here's the label the value and the salt you hash that together you give

your merkel proof and you can prove that basically a this value is included in this in this set this so this now makes it independent of the position in the tree so instead of having to rely on oh give me the fifth leaf in the tree or the the tenth leaf all I need to care about is that the field has to correct prefix and go going back to this specification because so and so this is something that protobuf is giving us they they use sort of these field tags so it's just an integer that you in the denominator I describe your field with so this is basically the prefix we use

to to encode encode the field value so in our case basically Alice and Bob they they send these documents back and forth they manipulate them they validate them they both know how to encode or create this Merkle tree based on the schema that they have and can then sign the merkel route and if I now have a signed merkel route i can give you like if alice has a sine root by bob she can make a claim that Bob agreed to for example the invoice amount being $1,500 so practical example let's say I haven't I have an invoice that I want in sure so

I want to ensure that my goods will be safely delivered I don't want to tell the insurance company what I'm selling to my buyer I don't want to tell them exactly I don't want to reveal any of that on chain what I can do is I can use his miracle proofs a lot in this in a snark basically the insurance provider would give me a snark that has their sort of their fee table encoded I could give my private inputs so the invoice amount is a thousand dollars it's the goods or a certain category the delivery country is the UK and therefore I should pay one percent insurance fee I attach a payment to it and by validating this

snark and the payment insurance contract can basically say can can check the committed state on on chain and say yes this was a valid this is a valid fee that was paid therefore the the the transaction is now insured this is in vs. now insured all right so this just concludes sort of the quick introduction to the precise proofs library it's on github there's a go implementation of it you can sort of play around with it try to sort of build your own complex trees so we support all sorts of different data types you can have sort of just

sets embedded messages and then just create proofs very easily and write and actually validate them both in the browser and in in solidity that that's it are there any questions any questions how can you make sure that it's easy to verify your proofs in different contexts like for example with snarks you wouldn't necessarily use the same hash function to bill your tree

well if you are doing this within the context of a theorem you're ultimately bound by what a theorem has to offer the library itself is not opinionated about what hash function you should use but so one thing you can do is actually you essentially always trust a signature right so as as Alice and Bob create these trees and sign it and one thing that we've been thinking of doing to optimize for both marks and and EVM verification you can have you duplicate the tree once you hatch it with peterson hashes and once you do it with file 256 or sha 3 and so if you were to make a statement that is public you can you can

use sort of the sha 3 branch of the tree and otherwise you used the Peterson branch of the tree all right