EY 🛠 Meet Starlight - Write ZKP smart contracts without a PhD - Andrew Forman

foreign [Applause] [Music] so hi my name is Andrew Foreman I'm part of the ey I'm part I lead our product and development teams at ey and we worked on this um we're currently working on this open source compiler called Starlight so that's kind of what I wanted to talk uh with this group about um and maybe just a chair but like how we got here like the problem that we ran into at ey why we built this thing uh why we open source to why we're going to be here at the hackathon talking about it this weekend uh so one thing to maybe know about ey2 is a background before you know getting the problem here is that ey loves privacy we're really committed to zero knowledge proofs we believe that businesses are going to want to operate privately on public blockchains or mostly ethereum other uh public uh EVMS and so we were doing all these projects where I would bring them my team of Engineers developers product managers and we'd work with this our our R D team that's very committed to this the zero knowledge proof research cryptography research and for each of these projects what we'd have to do is then like kind of work out the requirements build these custom circuits work with the team to then Implement those custom circuits and deliver the project and so we just found that that model wasn't scalable so we tried a couple other approaches we tried um teaching some of our developers uh how to use Socrates with some mixed success on that and so really our response to kind of scaling solving this issue of scale for developers to write privacy and zero knowledge proof enables adapts was to build this this compiler a transpiler but now it'll be open source and so we're making it available for for everybody to use we've got a grant this or a prize this weekend uh so come by stop by the table and uh we'll walk you through some of the details as well um but yeah I mean that's why we built it up here right so the journal group is hard we believe that a lot more people know solidity and we want to make it easier for those facility developers to then write privacy features into their into their app directly so how does this thing work um what we do is we take a a solidity smart contract we and you mark it up with these functioned uh these decorators which I'll walk through in a minute uh how those decorators work what they look like um then we use that to create this validity smart contract or a solidity file type is what we call it which uh zero knowledge smart contract and that is then what gets run through our zapify Command or zero knowledge amplify command into our transpiler so it turns out this private uh display private working uh application so to go a little bit more detail of how that works so you get the kind of the front end here once you get through the zapify side really from your perspective as a developer you really don't need to know the details of how the back end works but you know we're all you know I think people like to know so and it's important so um what you have here is you have um contracts so that holds the private business logic that you would use for Approved verifications uh you have the circuits which is just like a bunch of statements that you would use to generate the proof with uh then in the back end containers a couple couple core components here they become important uh one is uh Timber Timbre is another ey product that uh that we worked on it's essentially it's a Merkle tree that holds the commitments of the values that you would want to keep private so all you store on chain is the kind of the route to that Merkle tree um and then there's kind of this like uh whole idea of like Frontier nodes which are um kind of like nodes along this other different various Heights of that tree so we're using that to very um to compute the the Merkle root very efficiently so just something that we've worked on is kind of like a back-end infrastructure component uh we also have the blockchain client obviously to send transactions and then uh Socrates is what you we use to create the trusted setup uh so we're connecting to the Socrates that way and then um we also create the end-to-end test uh because if you once you get through the execution flow this will make more sense but you couldn't actually write tests for for uh Zap for Starlight if you wanted to because once you deploy that contract we're going to actually generate the zero knowledge proof circuit in the background for you so you wouldn't be able to recreate that logic without us writing the test all right so this is where I kind of want to spend uh most of the time is is on these function decorators because this is what you'll want to be used and and think through properly if as you go to kind of design and build your applications uh this weekend so there's three there's three function decorators to know uh the first one is a secret and so what's secret is is um is used to uh for State variables that are meant to get private so obviously we couldn't use the word private because that has a definition in solidity but you know you could think about it that way private or confidential uh secret um and so what right now what that takes is any kind of state variable function parameters on our roadmap is to then add a function uh themselves but what you can't add and this makes you know you can't add local stack variables inside of functions because they don't have a state component and we need something in real estate to to actually make private um the other important thing here and I think it's listed here in the in the how it works bullet is that this commitment is now uh something we call hiding and binding or the requirements that we've set around that which means that when you create a commitment nobody else outside of that commitment owner can see now see the commitment it's not available to anybody else on chain and it's binding meaning that that commitment is always matched to the state variable that you wanted to be applied to okay uh so so kind of with all that definition you look at our example here on the right we have the state variable called x and x has to be um kind of hidden from the outside world uh and so we have then we have a function add and we're going to have another secret uh uh decorator for y so now if x is a secret on chain and I want to add y to it both X and Y are a secret right so like you're keeping that you're maintaining the Privacy domain or the Privacy set that you want in in your application by marking both of these a secret um the way they actually do that execution is through something called known so let's move to that one next uh known so known and unknown are going to be then how you kind of update these State variables right so like we've created now we've created a state variable that's private on chain that's really cool but we want to be able to update it so for known what you're you're going to use known and times when you are the owner of the commitment that you want and you want to update your own state um so in this case it takes a state variable and like you might want to increment your own balance of something right I'm I'm the owner of my commitment I know only I know my balance I want to increment it I will use I'll use known um so here's the way that works is um what you need to do is as the owner commit you would need to show the proof of knowledge that you can open that commitment so it's kind of we're kind of getting to this like language of privacy and zero knowledge proof development that I think is new for myself and a lot of celebrity developers is like we're creating commitments we're saying who can now open that commitment who can make who can nullify that commitment and who can create a replacement commitment right and this is kind of the the pattern you'll see uh followed through in a couple of these examples but to walk through it here as the owner of the commitment now to show proof of knowledge that I can open that commitment and then using the secret values that commit that only I know and uh what our team did was develop some um kind of merkel-proof Merkle tree um magic that that lets us say we use that commitment without revealing which commitment we used in the Merkle tree right which is also part of kind of maintaining a strong privacy um so then you'd be able to um nullify the old commitment using a nullifier and and create a new commitment in its place um and I guess you know in the pr the public key up there too is also the owner of Republic if that wasn't clear okay so then no unknown will be kind of the exact opposite of known unknown is we want to increment the balance or contribute value to somebody else's uh a balance that we don't own or we don't control their commitment um and so um the way you do that is you called the so we we do something called a par commitment because um they're part of the entire state of the secret variable so if I wanted to if I want to access the the value of a variable you wouldn't be able to do that in apartment right what you have to do is you'd have to sum up all the parts to know what the full value of that variable is this is more like the utxo model and actually I think someone's just referencing the last it's more it's like the mental model that I kind of use for it is like a bunch of notes that you would pass around as like ious or something you trade right it's like what is the full value that that some person is owed you'd have to count up all the ious it's kind of how I've thought about it uh so that's what unknown does um so here let's walk through our example here it's a little small for me so we've got um our mapping here which is a mapping of uh addresses to uh to the to the balance amount in the for each address and we've got two functions one is to deposit so whoever can call whoever calls deposit increments the balance by that that set amount and we've transferred so whoever calls transfer then we'll transfer their balance to somebody else so if you focus here on the the yellow parts of the code what you can see is um you can declare some of these balances to be secret which means that no one would be able to see who are the addresses and how much do each of them control own or control in this in this contract um then you have these function parameters here at the bottom so in this in our transfer function we have a mount and recipient are also sent to Secret uh so that means that you know the amount that I'm sending in and who I'm sending it to is also going to going to stay Secret okay so that's those are those are the secret variables we've covered now we're covering a known here at the bottom as we get the balances and the way that we we works here is we create this part commitment so in this particular statement you'll notice that I'm incrementing the balance of someone else not your own right the recipient here um and uh and so then we create this essentially like an individual note or part commitment that we then passed through the transpiler and that's how um that's how we we essentially create the circuit for it in the back end um so I think yeah if there's some questions around and I know later this weekend you know come stop by we can we can talk through that as well okay so I've been kind of talking about commitments wanted to kind of flash what uh what they look like so uh for our basic normal State variable commitment here uh we've got it holds four things it's going to hold the state variable ID um so it's like right here we're kind of using the existing solidity compiler the way that each contract has a list of state variables and each of them has an ID so we're going to use that ID in in our commitment structure uh the second thing we're going to use is the value of of that state variable so it could be a number address string mapping like you know like you saw uh in the past in the previous example uh the third thing is the public key of the owner of that commitment so you know again this is like something that was new for me to think about when I'm writing my slaves like each time you create a commitment you have to think about who the owner of that commitment is who can see at any time and if I want to update that commitment who do I need to ask about for permission to update it or you know if I'm the owner then I don't have to ask anybody and then a random assault which is which is used for the hashes uh the um the mapping State variable is pretty much the same with one uh important Nuance um in that first part of the hash we also bring in the the mapping key so we have the state variable ID along with a hash of the mapping key that we created okay so here's our our quick example uh so in the invoice smart contract we have a mapping and address of how much the invoice is owed to that address uh we've got two different functions here add invoice and pay invoice ad invoice Works uh by having you know your party a we want to pay party B uh and so with this pending invoice amount and and how much they should be invoiced by um so then when I go to actually pay the invoice uh what I need to be able to do is I need to be able to reduce the amount of pay invoice by the amount that I paid uh and make the update to the commitment structure so what the user has to do here is something called the add invoice API and I'll kind of walk through the architecture of that in a second and um and I'm adding cream from somebody else with their their public key as the owner and then once that's done then we're using the orchestrator here on the bottom and the orchestrator will have to speak to Socrates and ask them to generate the proof with all the private inputs and the public inputs uh that are required for that function so and then once we get that we get the proven key back from the orchestrator which is another called a verifier contract upon successful verification we'll have to add the state variable to the Merkle tree um I think a lot of that stuff is like what's important from the zero knowledge and the Privacy assumptions part of of kind of using Starlight um the important part I think for like if you're just going to focus on the solidity part of this about how to write a private smart contract uh to to start to set balances and mark them as private is really knowing when to use secret when to use known and unknown and what your contract is going to look like as you start to add more and more of these uh into a given contract because you can sort of have very heavyweight contracts you can start to add different logic complexity to the back end the compiler essentially as you as you start to combine bind them but this is just a simple example of that that um that you know we wanted to walk through is that all you're going to do is here is come in add the keywords uh and you've got your your private your private account on chain um so then I guess you know kind of just to close and some key takeaways here one I think um it's a really important to think about privacy like I think that this is going to be a big thing for ethereum the the developer ecospace in general it's just like it becomes very important now for us to think our users want privacy and have uh demands and and needs for their privacy features so that we I think it becomes important for us to think about that I think it'll help us build more sophisticated applications I think right now like it's pretty easy for us where you just you go and you write your facility smart contract and you just assume a lot of these variables are public and things are available on chain and as we start to think about what a privacy set in an application could look like and when different information will be revealed I think it will allow us to build more sophisticated applications going forward uh and so just so you know one of these big changes that I see you know that is has come up in the last couple hackathons that we're going to see more this weekend um so you know just a call out here like it's important to think about privacy both for your users from a system perspective um you know kind of uh with some Downstream consequences could be as you start to hide and reveal information um I think that's a there's like some important product design decisions that go into that uh I mean also it's just very cool you know we've got a lot of like privacy and circuit stuff work going on in the background and a lot of that's abstracted from you as a developer and for me that that's like the ideal uh developer experience uh the second key Point here is that this is open source we've open source the code the repo everything is available um the next slide I've got a link it's ey.blockchain.com or GitHub um we're going to be working on the transpiler a little bit more to get it out I mean I would consider this probably still more like in its Alpha stages um but this is not something that you know we expect uh to to license or salary you know right now this is open source technology so that's what we're here this weekend we want you to use it we want to talk about what some cool use cases for it might be uh we want to see um you know people people hack on it and give us feedback um so here's here's the link to my to the GitHub for it I think this weekend too we're going to create a developer support Channel which we don't have yet so um if you if you don't I put my telegram up there but if so if you don't um if you want to hack on on it just shoot me a message and I'll add you to that chat um I also have any let me guess we have a few minutes or questions I could take some questions also I've got a poab that they had given me so I can flip over to that yeah so you have to go set up the transpiler which is the first step there's a transpower setup step and then once you have the transpiler then then you just write your Decker is correct yeah but you're right probably probably uh that's you know I don't know I mean to kill you run through it it wasn't it wasn't too too bad so uh command and we find this quarter yeah yeah and maybe just repeat that on the mic basically what you're doing is you're going to run the execution file then you um execute the zapify command and then you have a deploy a local deployment that you can use um yeah so I I put up a different schematic or a different version of the architecture here uh just to show you kind of how that looks uh in the example that I gave with the ad invoice and the pay invoice um and and then the and the different numbers here what they're calling out is how I would um excuse me uh update and change the commitment structure where it's not it's not an update it's really nullify and create a new one but yeah still learning the uh the salinity part of it um any other questions like does anybody does anybody want to pull up does anybody care cool uh yeah so I think they're probably two levels to think about that so uh anytime we work on these kind of zero knowledge proof and um and privacy features we write up the trust assumptions that we assume the users to take on using the application so that's what I refer to in the talk was trust assumptions from using uh Starlight like where the off chain on chain components uh I think if you were to build your own application using Starlight you really wouldn't have to consider uh the way that our system works in your own trust assumptions but probably good practice as you start to go build privacy features uh you know making make a couple bullet points to make that clear to the user it appears here's where information is is stored here's who can access it that's that's why that's all I mean by trust assumptions yeah cool all right ready time thanks everyone