# Scaling Privacy with Starlight | Devcon Bogotá

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-09
- Duration: 28:23
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-HJtoGbZFLNI
- YouTube: https://www.youtube.com/watch?v=HJtoGbZFLNI

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/scaling-privacy-with-starlight/

Five years ago, at DevCon in Prague, EY took the wraps off Nightfall, our open source public domain approach to privacy. Now it's live on Ethereum as a layer 2 privacy-enabled ZK-optimistic roll-up solution called Polygon Nightfall.  That's only half the story though - we also need private smart contracts.  This talk will cover our roadmap to that end, including our newest tool in development (also open source) called Starlight.

Speaker(s): Paul Brody, Chaitanya Konda
Skill level: Intermediate
Track: ZKPs: Privacy, Identity, Infrastructure, & More
Keywords: privacy,;,layer,2,;,applications

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

foreign [Music] I only have a few sessions I want to give all the time to my co-star chitanya as much as possible I want to take just a couple minutes to talk about a little set this up right and uh you know it's good to see the hearty crowd here 10 a.m on a Friday morning right that's um that's not when you expect most people to be fully awake so what is the point of privacy right financial and Industrial use cases privacy is fundamentally essential right I think you know we talk a lot about the value privacy in the world of blockchain we don't actually do a lot about it but if you serve large companies we do a few Enterprises what you'll discover pretty quickly is that most of the things that enterprises do aren't uh suitable for fully public consumption right they don't publish their contracts they don't tell people how much they're buying they do in the in the aftermath right they publish their financial statements but they won't tell you in advance uh exactly what's going on at the time and they don't want to disclose what they're buying how much they're paying for it so privacy is really essential and one of the things that a lot of people don't realize is that you really need actually two kinds of privacy uh you need one kind of privacy which is to represent digital assets or physical assets to tokens right but then you need a second kind of privacy to represent the business agreements that move tokens between Enterprises right at the end of the day every business agreement boils down to one party has money the other party has stuff and they're exchanging them under the terms of some kind of agreement right so in theory if you can represent the money and the stuff as tokens and you can move them around with privacy and you can represent the business Logic the rules of that exchange with privacy then you can pretty much manage and operate any kind of business process on a public blockchain and for those of you who don't know at ey we are fanatically committed to public blockchains right that's really not just public blockchains but very specifically to a theory we only build on ethereum right we only build on ethereum we only build on public blockchains that's been our policy for many years now um so uh we've got one piece of this puzzle it's called Nightfall Nightfall allows you to move tokens around it's currently in in beta on the test net we will be in production one way or another at some point in the very near future and uh that allows you to put things into a shield contract in a sense it's it's a little bit like Z cash but for any kind of fungible or non-fungible asset the second thing that we're building on and the thing that my colleague shitanya is going to talk a lot about today is how uh is both the combination of Nightfall and starlight and you're mostly going to talk about Starlight right right so Starlight allows us to do something pretty useful and clever which is to make business logic private on the public blockchain and this is the really hard thing we we spent a lot of time thinking about this right it it's really hard to teach developers to use Socrates how many of you use Socrates it's hard right it's really hard um but there's an easier way which is what if we could make a compiler so you could just mark up a standard solidity smart contract and then recompile it as a zero knowledge circuit and then you could run it on the mainnet or on a layer two then you would have a really simple straightforward way and a scalable way to have secure Private Business Logic on the public ethereum ecosystem so that is our strategic goal it's nothing short in my opinion and trying to completely transform how the entire world does business by moving uh Enterprise transactions from private blockchains or private systems onto public ethereum but with the kind of privacy that enterprises need uh I just want to close out by saying that both Nightfall and starlight are in the public domain right we're a large company so people are sometimes a little suspicious of what it is we're doing right everything that we have done is in the public domain we have relinquished our ownership rights to it it's not just open source it is fully public domain right and so there's a lot of stuff that still needs to be done we are always looking for help in this we are trying to build a true open source ecosystem around industrializing and scaling privacy with that I am going to hand over over to the true star of this presentation which is caitanya Kanda she is one of the heads of our research organization and has been working on both Starlight and Nightfall for six years now I think yeah six years like that's real real effort shatania please [Applause] thank you Paul um I'm Titania and I work in ui's R D team as an applied cryptographer before we begin I'd like to mention Miranda Wood and swathi Ravel both of whom are not here today to present this but have been putting immense work and effort to bring it to where it is today now moving on to dilate the topic of a conversation what starlight is is it was born out of frustration out of six years of research within ey we've been working on General Knowledge proof for quite some time and we've learned quite a few lessons from it right trying to build private applications for businesses is not an easy task because what you have to do is come up with protocols that turn your business logic into private logic and then turn them into circuits now in order to do that writing circuits has a very steep learning curve and an everyday developer to be able to do that it takes quite a lot of time for them to learn it to begin writing the circuits to begin with that is just not practical because as ey we need to be able to churn out private applications at a much quicker rate than the developers can actually learn and that's pretty much one of the reasons why Starlet was born but in order to do that you now need people who are experienced in writing xenology proof circuits that itself is another problem because the number of people who can do that today is very very few that was literally how Styler was born we thought okay we're going to solve this problem because we need to scale much faster to create private applications and starlight lets you exactly do that another thing we've only realized after actually building this application is that it did something a lot more crucial in order to build private applications now it's pretty much instantaneous in the fact that the amount of time it takes you to create private private applications is the amount of time it would take you to write a solidity smart contract and modify it a bit and that's it instantaneously you have private applications ready most importantly what we've also realized with an r d is that as a bunch of people who are hired to be smart and to do smart work we've not done very smart choices because essentially what we've done is we automated our jobs what do we do now well sadly I think Paul had that today so he might or might not have realized that until now but there's no going around it anymore very smart again now how does Starlight work you take a solidity smart contract and we pick solidity because it's the most popular programming language that blockchain developers know today you take a solidity smart contract and then you mark certain parts of the smart contract private and then you create this other contract called zolidity smart contract or zero knowledge proof compatible with smart contract and you take that decorated small contract and when you call zapify zapify stands for zero knowledge apify private app if I is pretty much what it can raise so when you run zappify command the transpilar which Starlight is Will churn out a fully working private application now just to dig a dip more deeper into what that private application looks like essentially what you have are contracts contracts that hold the private business logic in terms of proof verifications and then you have circuits which have a bunch of statements that you then have to generate a proof with and then you have what we called Timber now Timber is another ey product that is actually one of our best work in fact what Timber is is it a Markle tree that holds as Leaf commitment Leaf nodes commitments to values that you would like to have private and the best part of it is that on Smart Con on on chain all you store is the root of this Markle tree you're not throwing any of the leaf nodes none of the commitments but you also store what we call a frontier the front here is a bunch of nerds at various Heights of this tree which is used to compute the root in a much more efficient way than you can traditionally compute today in a Markle tree and the leaf nodes which hold the commitments the intermediate nodes of the Markle tree and the root itself are held inside a local database which is listening to the blockchain events from Timber so that's what Timba does timber holds a list of private States essentially and then you have a blockchain client which will be used to do transactions um of Starlight you you use a blockchain client to send those transactions and then you have Socrates now Socrates is a tool that lets you create right circuits compile them create trusted setup of these circuits if you're using a trusted setup related stuff and then you can generate proofs with it as well as do off-chain verification which is not too relevant for us because we do on-chain verification and then finally we also create test end-to-end tests that show the entire application or private application working so it has to call the contracts generate the proofs from the circuit and then give you the final end state now what it is that we do by taking a plain vanilla solidity smart contract you need to use certain keywords to specify what parts of logic needs to be private and what kind of lot business logic do you actually want to hide and in order to do that we have three keywords that we use the first one is secret so secret is used on any state variable that is meant to be private or the value of which has to be confidential can apply secret to State variables to function parameters to functions also it's a work in progress as we speak as a future enhancement but you can't apply to local stack variables inside functions themselves just because that comes on the business logic and not really any state that you're storing the way it works is that we use this cryptographic parameter called commitment which is both hiding and binding so any value that is held inside a commitment is not visible to the outside world only visible to the people who can open the commitment and it's bound to that value too so you have to create a commitment of whichever it is that the state variable that is declared as secret now to take a quick look at the example here you have a very basic example you have a state variable called X you declare that to be a secret so which means any value that is held inside X has to be secret to the outside world can only be visible to the owners of that commitment and then you have a function called add which takes in as its parameter a variable called Y which is also meant to be secret so what ad does is it it increments the value of x by an amount of Y and both X and Y have to be private so nobody should know what x holds and nobody should know how much it was increment did by that's pretty much what it does will come to known in just a moment so the next keyword that we have is is called known secret State variables are useless if all they do is hold the variable and do nothing what you need to be able to do is to actually make changes to these variables you need to be able to update them but the question becomes who can update them should it be the owners of these commitments or should it be other people too and there are instances where you need both of those situations so you need to be able to differentiate between the two and that's where none comes in so what known does is it takes the state variable and it will only let the person that can update this variable to be the owner of that state variable so nobody else can make changes to that variable so the kind of changes you'd make is essentially incrementation statements and the way it works is also very important what you would need to do as the owner of a commitment is that show a proof of knowledge that you own this commitment by opening the commitment using the secret values to the commitments that only you would know and then you would have to show the existence of that commitment in a Markle tree not by pointing to it but by actually not pointing to it by CR using a sibling path from the position of the leaf node and calculated Merkel root from it so that just does not reveal which commitment you're actually using then you'd actually have to show that you can change that commitment by proving that you know the secret key of the public key that is used within the commitment and that public key essentially refers to the owner of the commitment right then you will have to nullify the old commitment by creating a nullifier and then you would have to create a new commitment which holds the updated stage which is X Plus Y in in place of X so that's the entire logic that's happening when you declare something as a known and on the right you see the exact same example as before the only difference is you would see that X Plus Y and X is equal to X Plus Y is defined as known essentially what you're doing is you're creating all of these statements which will then be generated as proof and the only person who can create that would be the owner of the commitment to begin with and then you have unknown now unknown is the opposite of exactly what known is so known was someone who owns it making changes to it unknown is someone who does not own this commitment should also be able to contribute to the value of that state the way you would do that is we have this concept called part commitments essentially what part commitments are that are part of the entire state of the secret variable so if you want to know the exact value of that secret variable that does not come from one commitment but it comes from the summation of all of the part commitments and these part commitments themselves can be seen as utxo like nodes that can then be individually used to move around so that's what part commitment does and to take a quick look at how that will work we have an example again here a slightly different example you have a secret variable which is called balances which is a mapping it's a mapping from addresses to the balance amount you have two functions one is deposit whoever calls deposit is going to be able to increment their balance by the set amount and then you have transfer and whoever calls transfer will transfer a certain amount from their balance to somebody else what I want you to notice here is that just the yellow bits of the code so you're declaring balances to be secret which means you want no one to understand whose balance is how much and then you have the function parameters amount and recipient to be secret so if you want to do a transfer to a certain user a recipient and it's by a certain amount we want both of those to be secret too so those will become private inputs to your proofs finally the last statement where you see unknown balances that's the other bit so the way unknown works is by creating part commitments and that particular statement you will notice that you're incrementing the balance of somebody else not your own balance that's why you need to frame it as unknown instead of calling it known and the compiler will be able to create part commitments instead of throwing an error at you very quickly um I keep talking about commitments just want to talk about what commitment actually holds for your normal variables commitment holds four things it holds the state variable ID every contract has a list of state variables and then each of them have an ID and then you have the value of the state variable and then the publicly of the owner of the commitment and the random salt which is required for the hashes now well you can't see what's happening there but I will tell you it's that it's about it's this mapping kind of state variable which holds balances that are mapped from address to the balance amount it's essentially in that situation there's a slight change where the first part of that hash has the state variable ID and the mapping key which in this case will be the address of who's ever balance it is and you hash them together and that becomes the first part of the commitment structure and that is literally how the commitment structures work now in terms of the various steps that we go through to actually have the completed private application these are the steps first you will take the solidity smart contract which is the solidity smart contract with the keywords added to it by the developers you then syntax verify it there will be various cases where developers would not use the keywords the right way and you'd have to be able to throw errors and warnings at it and install it is smart enough to be able to show that then the first step is to actually remove the keywords that you added these three keywords and you will have a plain vanilla looking solidity smart contract you take that contract run it through solidity compiler and output an api.json file which essentially is the syntax with the various State variables and functions that this contract holds now it's a Json object of the nested type but essentially you can parse it as what we as what we know as abstract abstract syntax tree and AST so what abstract syntax tree is it lets you take a new program and split the syntax of this program into a tree and in the case of facility smart contract you would have your contract at the very top which will then be split into State variable declarations and function definitions State variables will then be split up into the type of the variable and the value of the variable and the function definitions will be split up into the type of the you know the function parameters the return parameters and the body the function parameters and the return parameters will be split up pretty similar to the state variables between the type and the value they hold and then the body which is the important bit is going to be split up into the kinds of statements that can exist expression statements assignment statements so you will have the operation on on one end with its children node being the left and the right hand operands of this operation that's that's how your abstract syntax tree would normally look like so you take that tree now once it's generated from the abi.json and then you put back the keywords that you used originally in the solidity into this tree so if a variable was secret into its type you will now say secret type variable now from this modified abstract syntax tree you will have to generate four different output files the files being circuits contract the orchestrator code and the test code generating that you will actually have to create four different kinds of abstract syntax trees which will represent what the code should look like in files from these original abstract syntax tree and from those abstracts and tax trees you will then generate the code files that's pretty much how it works sounds simple and the code is painful I tell you now just to give a quick idea of what the architecture looks like um you would have your Zol contract which has three functions all of which you need to have all of which have secret variables that it manipulates then you will have the orchestrator the orchestrator holds the API essentially a user will call the API and the API will have an API endpoint for each of those functions so once you call the API the API will then orchestrate by interacting with the proof generation or the contracts accordingly now you also Orchestra can also do setup for your circuit which generates the private and proving keys in the verification keys for these circuits and then it will also deploy the required smart contracts onto the whichever blockchain you're using but in this case we always use ethereum pretty much and it will also deploy the verification key into the verify your smart contract and then it also holds the database of the commitments that pertains to the user who is using this orchestrator as well as the secret information that is required to open the commitments it will also hold Keys which suggest about the ownership of the of a commitment and all of this of course can be really architected a bit more for production scenario while you're storing this information much more securely in a hatches them wherever you'd like and then you will have the smart contract and you have the shield contract which is the con the function which is the contract that gets called when somebody wants to do one of these functions which will in turn call the verify your smart contract to verify the proof that you've just submitted to it using the verification key that is relevant to that verification and then you will have the timber tree that we just spoke about earlier all it holds is just the route that's why you see it in yellow the rest of it it's not really held inside the smart contract cost purposes and then you'll have the Socrates which holds the proving Keys the circuit files which will help in the generation of the proof for each of these different um circuits and then you would have the temple marker tree which holds all of the nodes of the Timber Markle tree itself now taking we're almost the final bits so giving a quick example and here we have it invoice smart contract and the secret variable in this case is in voice which is a mapping it holds against an address how much invoice is owed by that address now you have two different functions add invoice pane wise the way adding Voice works is that somebody who wants to invoice a party a that once in what invoice party B will add to party B's invoice pinning invoice amount the amount they should be invoiced by and so that's why you will see that I am invoicing somebody else so I'm setting their stage so I'll have to specify unknown and that's pretty much what's happening here and then when pain was called what it essentially does is I will pay my pending invoice to whoever I'm supposed to pay and while doing that I have to reduce the amount owed in my in Wise amount of debt statement State variable by the amount I paid by so that's what pain wise does now just tracking through the various steps that's going to happen is you know you have an absolutely smart contract which will spit out all of these different bits of logic a user will first call add invoice API because they just want to add an invoice when that happens immediately the orchestrator will look oh should I fetch a commitment from inside my DB or not in this case because I'm adding an invoice with somebody else I I don't have any of my commitments that I'm spending I'm just creating a new commitment for somebody else with their public key as the ownership so I'll just be creating a commitment from scratch once that is done I will then have the orchestra will then have to speak to the Socrates asking you to generate a proof with the private inputs and the public inputs required for this function using the private proving key of the ad invoice once that is done we get back the proof to the orchestrator to the orchestrator and the orchestrator will then speak to Shield contract by calling the ad invoice function The Shield contract which in turn will receive this proof from orchestrator will have to call verify your contract to verify that bit of proof using the relevant verification key of ADD and wise and on successful verification we update the state by adding the commitments to this Markle tree and the route is updated at which point the timber tree which is a Timber container which is listening to the timber events of chain will receive the latest commitment and The Roots and then it will store that within itself so that's pretty much how a private application would work and in order to build this entire application all the developer has to do is to write a solidity contract and add some keywords and then call A transpiler um that is pretty much it thank you to Tanya and I will just add one final message which is if you want to play with this stuff it's out there on GitHub it's github.com eyblockchain it is free it's open source it's maturing quickly I think we're in a pretty good beta now and it's getting better by the day so please go try it make zaps uh and please use our our phrase zaps do we have any questions or just gratuitous flattery yes you sir I just want to say this project is super awesome one of the most exciting things I've seen here at Devcon now I did notice on the GitHub there's a lot of disclaimers everywhere basically saying please please please don't use this in production um I just was curious what do you guys have a road map or what are your thoughts around when uh you think it'll eventually be a little bit more mature and ready for uh production applications these are disclaimers that we are required to put there based on the advice of our attorneys um uh I mean I think we are I mean we will say when we think we're sort of at version 1.0 right and we encourage people to test and play with it but um and and we will probably get some third-party verification as well but you know fundamentally we do like we can't tell other companies what to do and we certainly don't want to be responsible if things go wrong which they always do in software so so thank you for the talk so one question uh is there a way that two private keys can really reach the information another proof so in that sense you always have been figure out that the balances for example the only one looking at the same balance was the address who owns the balance so is there a way for example is there a regulator or somebody who needs to have all the access at all the proof to be included in the information you mean to say if a commitment can be owed by more than just one key um well ownership is just always with the one key and ownership is defined as not whose key there is inside but also actually the knowledge of the commitment if you wish to share the knowledge with more than just one person either of them can now you know spend that commitment so if you'd like multiple parties to be able to spend a commitment you just share the secret information with them that's what makes them the owner the other sense about events so now we are saying state but it doesn't make sense to to include the events in this uh known known Etc so as part of events you're not actually revealing these secret variables at all all that gets sent out as part of the events is commitment which is hiding such that no one can actually see what's in inside it anyway and then nullifiers those are really what will be the variables that events transmit think of time for like one more quick question and then then we're going to be yanked off stage this is definitely great um so nothing binds it to just ethereum it is any evm compatible blockchain this this should work right well um it spits out strategy smart contracts obviously it's within in the byte code that is required for solidity so in that sense if that yes but if you want to hack it to something else you literally have to change the code such that it spits out the bytecode that's relevant to whichever blockchain you'd like to use it for okay um so that's that's one and the second thing is like if we want to optimize for like let's say proof size or verification time or whatever growth 16 versus block or what how where do we set that up so the proof itself is generated by Socrates as long as the the proving system that you want is supported by Socrates you can actually have it generate the proof in exactly The Proven system that you want don't think Planck is currently supported by Socrates so you wouldn't be able to do that but I'm sure they're looking to add it thanks awesome thank you everybody have a great day [Applause]