Introducing Provable Object Data by Andrew Twyman | Devcon SEA

[Music] okay and we're live welcome everybody um my name's Andrew I'm with zerx Park um and I'm here to tell talk to you a little bit about pods um how many here have been using pods this week uh I think the answer should be one because you got into the building somehow um and that actually required one so what are pods um so your Devcon ticket is a pod um the uh proof of attendance to this talk that you can claim um from the Q&A app that's up on the screen there right now if you're in the room I don't think this wor Works remotely that's also a pod um some of you have been playing frog crypto this week I see some frog hats out there um all those frogs are pods um a pod really can be anything it could be a secret message it can be your identity credentials it could be your driver's license um if we get any governments involved to actually do this um it can it's cryptographic data of any sort um so what is the Pod framework so pod is is a technology a framework that makes it easy for apps to issue cryptographic data and to make ZK proofs about that data it's a data format that's optimized for efficient proving it's a standard um of how that data format can be sent around and and things can be proven about it and it's a framework with some developer sdks um check out our documentation site I'll have a l Link at the end um if you want to try it out um it's mostly in typescript but can be used on other platforms as well we have we have ports in a few other languages um so I'm hoping some of you will uh get some use out of it um so one last WTF is zero knowledge proofs how many people here have used ZK proofs before I feel like you understand them okay a few um it's kind of it's kind of obscure technology that's kind of the point of PODS is to make it easier to use so you don't have to understand how the underlying math works but in brief a ZK proof lets you prove the validity of any private data or any computation on your private data without revealing that private data itself um and that proof is trustworthy because there's some math that basically you can only calculate if you did it validly um at xerx Park we think of ZK proofs as a universal cryptographic adapter basically I've got lots of different kinds of private data by doing computations on that data in a verifiable way I can present to somebody whatever I want that is uh validly proven from that data the example in this diagram which you'll find in in our blog post is like what if I could calculate my own credit score from signed data I got from my bank or from the IRS I don't need to ask a credit reporting company to gather all this stuff together I can gather it myself and I can make a approvable statement about what my credit course score is and apply for a loan um this is part of the vision of something we call the parket programmable cryptography internet um which we think is going to be you know much better once programable cryptography Cates on um in all these ways uh ZK proofs are a big part of of this but it's only the beginning um see the other talks being given by my colleagues this week also we have a whole day CLS tomorrow about programable cryptography but today we're going to be focused on ZK proofs and what pods let you do with them so this is the Pod ecosystem that we envision uh right you need issuers who are issuing this cryptographic data they're mostly using a private key to sign it those takes the form of attestations which users themselves can hold on to they they hold on to their own private data they don't need an intermediary um at some point some consumer ask the user please prove something about yourself your identity your age the fact that you went to Devcon things like that and then the consumer can generate a ZK proof and send sorry the user can send the ZK proof to the consumer who can verify that proof um they do need that third arrow in the diagram um which is a little bit of knowledge about who the attester is you know need at the very least to know that that attester has a public key that you should trust um there might also be things like what is the event ID that represents Devcon on a ticket things like that um but that kind of completes the diagram okay so what why are we doing this so I I work with the the team that builds zup pass you've all been using that to check into Devcon um and we believe that the best learning on this kind of Technology comes from contact with reality uh meaning we want real users to try this we want to do it at scale there are 12,000 people at devcom this week who are who are stress testing zup pass for us thank you I'm sorry if the performance has not always been as great but it seems to be standing up um and we want to use these opportunities to onboard new users by bridging data that is not ZK friendly into our ZK friendly World um and take advantage of people who are willing to be early adopters like the crypto community so by bridging what I mean is we're bringing data in in the red boxes on this diagram into the green World red in my diagrams of this talk and the next one um means like non ZK friendly systems whereas green means ZK friendly systems we can Bridge it in we can then issue it like your Devcon ticket which is loaded from a database that isn't cryptographically signed um and then you can the verifiers can gate you into another system like Telegram in order to join the the Devcon chat group all that is working today um in order to bring this in front of the most users we do have to accept some constraints so we're not using the most cuted edge of ZK Technologies um we want everyone to be able to use it which means we've built a mobile friendly web app um which means everything we do has to run in a browser on a phone even an older phone even on a a bad Network when the Wi-Fi is overloaded at the conference um that so that became a bit of a mantra when I was building some of these Technologies like there's a lot of cool ZK technology out there that is great but it needs to run on a big backend server and I don't have one of those when I'm in a browser on a phone so we got to use tried and true Technologies uh for people who are in the know we use circom and grth 16 you may or not may not have heard of those but that's kind of the underlying technology they've been around for quite a few years so they're pretty well battle tested at this point um so I want to talk a little bit about the systems we built along the way so this is what D pass ticketing looked like a year ago at devc connect when we were in Istanbul um so it's the same triangle that you've seen here um we were pulling data out of preck and issuing the tickets uh we used a format called an eddsa ticket that's a assigned piece of data but it's not a pod which I'll explain a little bit later and then we had a a proving circuit where you could prove your your ticket you could reveal some Fields you can prove that you you owned it Etc um so what did it take us to build this um don't pay attention to all the details here but look at the line counts on these PRS when we wrote these things um it's pretty large that's quite a few lines of code that it took and there's uh in just the ZK proof there's about 15,000 lines of code that are still there that not including tests and documentation so it's kind of complicated um so that was the first thing we built the second thing we built was frog crypto um the first version last year which used a very similar data format so frogs were issued by the server as what was called an EDSA frog uh very similar for format to tickets and then you could make a proof about it you could Pres present it to our zcat telegram bot who would let you into the secret frog holders chat this all happened last year inan um so what did it take to build that um it turns out it was very similar there was a lot of duplication of effort there was a lot of like similar patterns but you couldn't actually reuse the underlying data um so there clearly is a pattern here right we want to issue some signed data we want someone to request a proof and then to be given a proof of that signed data but it turned out that each time we had to build it we had to rewrite a whole bunch of code in order to customize it so I'm an engineer I don't like this kind of complexity I'd rather do things once because I'm lazy so why is this so hard um so the signed data part the EDSA PCD that we were using as our underlying data format uses a fixed size hash it hashes 16 numbers in an array um and therefore every new data type that we want to put in there we had to do some custom coding to decide how those numbers in that array go together to make this data type um I would analogize this to imagine you were like processing all your data in a editor directly is bytes it's kind of inconvenient we have better tools than that now um and on the proof side ZK circuits are a little bit awkward to program like they don't use a normal programming model you don't write it in in a language you're used to um every variable is what's called a field element this is a mathematical concept there's a it's a very big number modulo some big prime number um and you've got to like write equations on those field elements so it's kind of complicated and also once you build a ZK circuit it's very fixed in order for the prover and verifier to to agree on what's uh valid the circuit can't change very much it's hard to you have to publish a whole new circuit um so that makes this a bit bit hard I would analogize this again to in the hardware world this is like an Asic it's a chip that does one thing it might do it very well but it still only does one thing and every time you want to do another thing you got to build a whole new chip it's kind of inconvenient um so what do we need here well what we'd really like to have is what's called a z KVM basically if you have an Asic and you want something more General why don't you use a CP you um and there is technology out there that lets you basically write code run it inside of a ZK circuit and validate that this is the correct output um it's great some other people are giving talks about it this week um but unfortunately for our situation it's a little bit too much like I said my Mantra has to work in a browser on a phone ZK VMS are pretty big right now um you're not going to be able to do that on an older phone in a few seconds so we have to do something a little bit more uh limited than that um but again I'm an engineer I like uh working within constraints and coming up with clever Solutions um so here's what we came up with um so on the data side um finally going to explain to you what a pod is at some level um so a pod is just a collection of names and values think of it like a Json uh object um except that it's flat there's no hierarchy of nested objects just names and values um it can have multiple data types in it for those values um the data is then cryptographically signed in a way that makes it easy to make proofs about it and I'm G to get into more of that a little bit later um also I forgot to mention this at the beginning we are having a deep dive session after this intro session so stick around for that if you want lots more detail um but I'll get I'll give you what I can in the next uh 15 minutes um the on the proof side we also can generalize we have what we call a general purpose circuit um which means rather than having a fully uh CPU like circuit in a zkm or having the Asic fixed circuit we can do something in between I would analogize it more to an fpga right we've got some logic blocks we call them modules you can feed in some inputs to your circuit in order to decide how those logic blocks are connected to each other and make a different proof every time using the same circuit uh we call this framework GPC for general purpose circuit um and in addition to the circuits individually being configurable we pre-compile a set of circuits in what we call a family at different sizes with different sets of modules so when you want to make a proof you can pick the circuit in the family that has enough module for what you want and not anymore because having a bigger circuit means more time to prove more memory Etc so you can make the right tradeoffs there so with that we get the generalized version of the ZK ecosystem where every issuer is issuing pods they might contain very different kinds of data it might be a frog might be a driver's license but it's still a pod and then when you make proofs about it you can freely decide what you want to prove and uh write a configuration to represent that proof um so with that in mind at this point what is a pod so a pod is a data format that makes ZK proofs easy um it's a key value store it's going to be hashed and signed in a very specific way involving a Merkel tree which I can explain more of later um and it's optimized for efficient ZK proving um here's an example of a pod um so we've got some names and values um most of these are are very straightforward so I'm not going to go through them all in detail the one that's may be a little bit interesting is the card holder this is meant to look like a driver's license in some you know fictional country uh the card holder is my semifur ID this is what zpass uses to identify you it's really a public private key pair um so the public key is what's going to go in the Pod to say that this is my pod or in this case this is my driver's license um what you see on the right is the Json format for this it's optimized to be a little bit tur and also human readable so things that don't need a type annotation you'll notice don't have them because the Json type itself is enough data um for that um once you get down to actually building the Merkel tree like everything does have a type but in this uh table I call them type hints because the type is not part of the cryptographic data instead it is guidance to how do I hash this data into a piece of uh cryptographically verifiable data um more on that later so the first thing I do to make this into a pod is I build a Merkel tree U I'm not going to go into detail on that but basically you arrange the elements into a tree you hash them all together until you get to a root um and that root is what we call a Content ID uh the content ID is derive from the data so if you have the same data you can derive the same content ID regardless of how it was formatted in Json um one detail that you might notice on the right is that the the names have been alphabetized that's how we make sure that it is deterministic and you always get the same content ID uh but everything else is just hashing um and then now once I've got the content IDE that's the thing that I sign so if I'm an issuer and I want to issue a pod first I get the data I meriz it I get a Content ID and then I just write a signature on that Content ID and that's enough to validate that the entire pod is valid so uh we have a a ZK friendly data format we'd probably like to do some ZK proving on it um so let's talk about the GPC side of this that is what you lets you do that um as I mentioned earlier ZK gpcs are circuits made of reusable modules um as well as a family of multiple circuits so you can pick the size that you want um let's look at what that looks like um so this is an example of a GPC configuration this is how you say what do I want to prove um and you're going to present this as this Json object that says what you want to prove and the system is going to do the rest compiling this down to what to do with the circuit so here's a very minimal proof um I'm going to try and prove that I have a driver's license that says I'm allowed to drive right so I my configuration says I have a pod I'm going to call it ID card this is actually an arbitrary name that's just part of the configuration to refer to it later um it has some entries and one of those entries is driver that is not an arbitrary name that's a name that was in the Pod and is going to be hashed and checked um and what do I want to do with it well I want to reveal it so is reveal is true means this is a proof it's going to proof that I have a pod that it contains this entry and it's going to reveal that its value is hopefully true because I'm going to try and drive a car um so that's simple enough there's one detail that wasn't on the previous slide um that is because it's done by default so I didn't need to include it in the config but it's important to talk about um what I proved if I don't have think about the signer key is I just proved that I have a pod containing the word driver with the value true that doesn't mean it's actually a driver's license um in order to do that you got to do something cryptographic so the way the easiest way to do that is you check that the Pod was signed by a public key that is well known um that might be the government of California which is where I live um hopefully we'll get them to issue pods eventually uh but that is implicit like the signing key is also always revealed by default but you can choose to not reveal it if you want to um in which case you can constrain it in other ways you might constrain it to be equal to some other element without uh actually revealing it or con it to be a member of a list like maybe I have a list of all the signing keys of the 50 US states um and I just want to prove I have a driver's license from one of them I don't want to tell you which one okay let's get starting to get a little bit more complicated um so I've proven that I have a driver's license that says driver equals true I haven't actually proven that it's my driver's license yet um I could have stolen somebody else's the thing is that pods because they're just data they are transferable I can copy them um the way we make a pod bound to a single user is by putting that user's uh public key in it which we I showed earlier when we were looking at the entries um and the way you prove that you are that user is you make a proof that you hold the private key that corresponds to that public key um and the way you say that in the Z GPC config is this is owner ID field you say is owner ID and I give the type of of uh public key I'm using which is semor version 4 from our friends at psse um and that basically means that this proof is going to be configured to check that I have the right private key which in my private inputs um and in this case it's not even going to reveal what my public key is just that I own this pod and this pod says I can drive okay let's get to a little bit more ZK and hiding some more data um instead of proving that I'm a driver what if I just want to prove I'm over 21 um maybe I want to go buy some some alcohol um I don't know what the age is in Thailand but back home it's 21 um so I can just say I have a pod containing a entry called date of birth um that entry is not going to be revealed but it's be in this range and that's the numeric range for the date that is 21 years ago um we should make this more friendly and let you just pass in a date object but for now it's a number uh so this is a proof that I am over over 21 and that I own this pod I didn't take out that that field but everything else is is not revealed and I'm being very Anonymous um one last example uh we can make proofs of multiple Pods at once if we have a circuit with enough modules so here's one that I'm proving I'm over 21 and also proving that I have a ticket um to an event that maybe I'm going to go to an party after Devcon um and in this case the ticket I'm proving that it its attendee name is the same as the name in my driver's license um I'm proving that I own it and I'm also proving that uh the event ID of that ticket is in a valid list I'm not revealing what I have a ticket to but it's in a maybe a list of like Devcon related events that are happening in uh in Thailand this week uh so this is kind of a a minimal Anonymous way of checking into a party of course if I'm there in person I'm revealing some more about myself by being there but you get the idea okay so last piece of this I've now configured my proof I've decided what I want to prove how do I actually make a proof um and all of this is an example of what you can do with the the GPC libraries um so the three things I need in order to make a proof one of them is the proof config that I've already given you some examples of uh the second thing is the inputs that's the actual pods um which I need to have in order to make proofs about them there are also other inputs like my private key uh or like that list of valid uh event IDs that I want to prove that my event ID is one of those are all inputs uh the third thing I have to feed in is something called an artifact path um that is where do we find the binaries that that generate that know how to generate this circuit so when a ZK circuit is compiled it generates a proving key a verification key and also a witness generator don't worry about what those are but there's some like big binary things that the prover and verifier have to agree with um we distribute these via npm we also put them on various CDN so you can download them so you have to just decide for your app are you going to download them put them on disk give a path to them are you going to download them from a URL they options um once you've got these things together the GPC proof function will generate the proof like it puts together that configuration it picks a circuit that fits that configuration with enough modules it downloads the corresponding artifacts for that circuit um and it generates the proof um and then the last thing it does oh I should have gone to the next slide here we go um so it needs to compile down all those inputs in into circuit signals that can feed into the actual ZK circuit um which are you know mathematical field elements as I mentioned and then after it's done and it gets a valid proof it will decompile some of the outputs and turn them into What's called the revealed claims object um so it comes out of a proof you've got the actual mathematical proof that's just opaque numbers that are needed by the verifier that's the actual ZK part um you've got a bound config which is exactly like the configuration that you fed in uh except that now it contains the identifier of the circuit that wasel Ed so that the verifier knows how to verify it correctly and then you've got the revealed claims if I revealed that uh I am a licensed driver driver equals true that would be in this object um if I revealed like my name Etc that would be here and that's what the decompiling is for it's taking the circuit outputs and turning them back into a string or whatever the the representative uh thing is okay so those three things are exactly what I should send to a verifier um whoever I'm going to prove this to um they need those three things they also need an artifact path to download the correspond verification key um and then they can verify the proof um they just do very much the same thing they're going to compile some of those inputs back down into uh into ZK land where there are circuit signals they're going to verify the proof and they're going to say yes or no whether it's valid uh and you know gravy we're at the we're at the end and hopefully everything went right and I've proven what I wanted to prove to you um so final takeaways summary of of what this was a bit of a speed run through um so pods are data that's designed to be prove proven about um any pod is a signed ad adastation of something um whether it's I have a ticket whether it's I have a driver's license Etc um gpcs allow you to flexibly make proofs about those pods by using modular circuits which can be configured using a a Json like configuration language uh and you can Auto the system will Auto Select the circuit that you need depending on your configuration so all your app needs to do is say please make me a proof of this with these inputs and everything else is handled for you um and then the last step after is the the verifier verifies the proof and then the apps have to do have to decide what things they trust how do you trust that this is the correct proof um like I alluded to before you should check that this uh ID card was actually signed by the government you should know the the public key or you should know the event ID for Devcon um you should also check and I'll tell say a little more about this in the de Deep dive that like the configuration that was sent to you was actually the configuration you asked for you want the pro to say oh I have a proof of something but not necessarily the thing you asked for that's something that you should check as well um but once you do all of that like this end to end should be should be very solid and you should be getting the information you need okay uh that's it for the the speedrun intro um please check out our documentation uh they're on p.org that just went live yesterday um and also there's a link that just went by t.me zass to join the telegram group uh and yeah let's go do some uh [Applause] Q&A all right uh where do you store the s for identity secret for users in zpass so that's all client side um zup pass stores all of your private private data client side um the zass server is aware of your public key because that's how it can make sure that you get issued the right Devcon tickets and things like that um but yeah zup pass is a is a client side cryptographic data manager to extent is POD an open data standard um so I consider it open um we haven't like uh published a spec for it I should work on that um but all of our code is open source so people can do interoperability with it um the Pod format itself is very generic and interoperable it's the GPC compiler that uh turns a pod into the specifics of what you need to prove with a specific GPC so the gpcs are kind of less standard and generic though they also could be used on multiple platforms we haven't we do have an example of GPC verification on chain um that just started working a couple days ago so all that is possible outside of a browser um but we don't have as many examples there as we do on the on the Pod data can we can we scroll down is there anything more uh can you compare pod to verifiable credential yes uh this is something I looked into um pod is simpler it doesn't really have a a fixed schema or anything uh that uh that like ties it into a specific standard you could put uh Json LD based verifiable credential data in a pod if you wanted to um but a pod is much more flexible um at the cryptographic level there is a difference in the kind of Merkel tree we use um the Pod uh uses the lean IMT which is something that semaphore uh created which is much shallower because pods tend to be relatively small um as opposed to the sparse Merkel tree that uh is used at least for the implementation of rare bio credentials that I'm aware of which is the one from Iden 3 um that is a much deeper Merkel tree but it can do things like prove absence of an entry which pods can't do uh okay what else do we have how frequent is POD refresh uh very frequent so far but we're hoping to keep it uh much more stable after de Devcon I don't have a strong answer to that uh what else uh how do you convert Json to a Merkel tree please stick around for the Deep dive session that's coming up I'll tell you all about that what else um yeah so the in the example prover and verifier um the user's device can generate the proof and that's why everything has to work in a browser on a phone um client side proving is definitely the default in zup paath not every app has to do it these are libraries you can call them wherever you want um there's much more difference between verifiers whether they're doing server side verification or client side verification that depends what your use case is and what you're protecting against um are the issued credentials signed and the proof that the credential oops you just we scrolled away uh uh we do not use BSS signatures uh to verify partial properties that's what the we use the Merkel tree for again more details on that coming up um is it possible to make information in zup pass portable I think that pods do make that possible yes um as long as it's a pod and there are uh apis for getting data out of zup pass if you want to um that's called the the Z um at which point you can take this to whatever platform you want we have implementations of pods on in Python C and rust for various projects so it's not too hard to do uh how do apps know whether a proof from a verifier is U is legit um well the framework tells you that it is a valid proof and it will confirm for you that this configuration and these revealed claims and this proof match up and are valid so the prover couldn't have Have Cheated about that um what they could cheat about is app level semantics so if you ask for a proof of a driver's license and I sent you a proof of a frog instead um that's something that the framework can't tell you because it just says that's a valid proof so you do have to check is that the configure I asked for um is the signing signer of this driver's license the the government Etc um yeah that's the that's the kind of level of of uh verification you get okay I think that's it can we go back to the slides briefly okay th those of you who are collecting frogs I've got something for you if we can switch back to my slides oh yeah we'll leave that up for a minute or two I think we've got uh like three minutes before the next session starts anyway so uh feel free to to frog away okay and as I said we're going to go straight into a deep dive session U which is going to be 90 minutes we probably won't use the whole thing but that's what we're scheduled for um so seek around if you want more details to answer any of those questions