 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 of minutes to talk a little, set this up, right? And, you know, it's good to see the hearty crowd here, 10 a.m. on a Friday morning, right? 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 of 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 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 aftermath, right? They publish their financial statements, but they won't tell you in advance 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. You need one kind of privacy which is to represent digital assets or physical assets, the 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 Ethereum. 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. So we've got one piece of this puzzle. It's called Nightfall. Nightfall allows you to move tokens around. It's currently in beta on the testnet. We will be in production one way or another at some point in the very near future. And that allows you to put things into a shield contract. In the sense, it's a little bit like Zcash, but for any kind of fungible or non-fungible asset. The second thing that we're building on and the thing that my colleague, Chitani, is gonna talk a lot about today is how it is both the combination of Nightfall and Starlight. And you're mostly gonna 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 spend a lot of time thinking about this, right? It's really hard to teach developers to use Zocrates. How many of you use Zocrates? It's hard, right? It's really hard, 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, in trying to completely transform how the entire world does business by moving enterprise transactions from private blockchains or private systems onto public Ethereum, but with the kind of privacy that enterprises need. I just wanna 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 gonna hand over to the true star of this presentation, which is Chitanya 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 effort. Chitanya, please. Thank you, Paul. I'm Chitanya, and I work in EY's R&D team as an applied cryptographer. Before we begin, I'd like to mention Miranda Wood and Swati Raval, 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 Starlight, 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 Zero 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 be getting 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 Starlight was born. But in order to do that, you now need people who are experienced in writing Zero Knowledge Proof circuits. That in itself is another problem, because the number of people who can do that today is very, very few. That was literally how Starlight was born. We thought, okay, we're gonna solve this problem because we need to scale much faster to create private applications, and Starlight lets you exactly do that. The other 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 fact, the amount of time it takes you to create 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 were 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 picked 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 Solidity Smart Contract, or Zero Knowledge Proof Compatible Smart Contract, and you take that decorated smart contract, and when you call Zappify, Zappify stands for Zero Knowledge Appify, Private Appify is pretty much what it can waste. So when you run Zappify command, the transpiler, which Starlight is, will churn out a fully working private application. Now, just to 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 which you then have to generate a proof with, and then you have what we call timber. Now, timber is another EY product that is actually one of our best work, in fact. What timber is, is it's a Merkle tree that holds as its leaf commitment, leaf nodes, commitments to values that you would like to have private, and the best part of it is that on chain, all you store is the root of this Merkle tree. You're not storing any of the leaf nodes, none of the commitments, but you also store what we call a frontier. Now, frontier is a bunch of nodes 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 Merkle tree. And the leaf nodes, which hold the commitments, the intermediate nodes of the Merkle tree, and the root itself, are held inside a local database which is listening to the blockchain events from timber. So that's what timber does. Timber holds a list of private states, essentially. And then you have a blockchain client, which will be used to do transactions of Starlight. You use a blockchain client to send those transactions. And then you have Zocrates. Now, Zocrates 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 SNAR. And then you can generate proofs with it as well as do of chain verification, which is not too relevant for us because we do on chain verification. And then finally, we also create tests, 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 circuits, 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 business logic do you actually wanna 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. You can apply secret to state variables, to function parameters, to functions also. It's a work in progress as we speak. It's a future enhancement, but you can't apply to local stack variables inside functions themselves just because that comes under 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 add does is 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 incremented by. That's pretty much what it does. We'll come to known in just a moment. So the next keyword that we have 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 known comes in. So what known does is it takes a 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 using a sibling path from the position of the leaf node and calculating the Markle root from it. So that just does not reveal which commitment you're actually using. Then you would 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 place of X. So that's the entire logic that's happening when you declare something as unknown. On the right, you see the exact same example as before. The only difference is you would see that X plus Y, 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, they're a 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 UTX or like notes 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 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 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, I keep talking about commitments. Just want to talk about what commitment actually holds. For your normal variable, 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 a 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 this mapping kind of state variable, which holds balances that are mapped from address to the balance amount. So 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 whosoever balance it is. And you hash them together and that becomes the first part of the commitment structure. 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 ZoologyT smart contract, which is the ZoologyT smart contract with the keywords added to it by the developers. You then syntax verify it. There will be various cases where the 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 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 ZoologyT smart contract. You take that contract, run it through a ZoologyT compiler and it outputs an abi.json file, which essentially is the syntax of the various state variables and functions that this contract holds. Now, it's a json object of the nest type, but essentially you can parse it as what we know as abstract syntax tree, an AST. So what abstract syntax tree is, it lets you take a new program and split the syntax of this program into a tree. In the case of a ZoologyT smart contract, you would have your contract at the very top, which will then be split into state variable declarations and function definitions. The 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 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 one end with its children node being the left hand and the right hand operands of this operation. 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. Before 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 this original abstract syntax tree. And from those abstract syntax trees, you will then generate the code files. That's pretty much how it works. Sounds simple. The code is painful, I tell you. Now, just to give a quick idea of what the architecture looks like, you would have your Zoll contract, which has three functions, all of which has 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, orchestrator can also do setup for your circuits, which generates the private approving keys and 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 to 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 commitment. All of this, of course, can be re-architected a bit more for production scenario where you're storing this information much more securely in a HSM, wherever you'd like. And then you will have the smart contract. You have the shield contract, which is the contract that gets called when somebody wants to do one of these functions, which will, in turn, call the verify a 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 a root. 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 zocrates, which holds the proving keys, the circuit files, which will help in the generation of the proof for each of these different circuits. And then you would have the timber mercury, which holds all of the nodes of the timber mercury itself. Now, we're almost to the final bits. So giving a quick example, here we have an invoice smart contract, the secret variable in this case is invoice, 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, pay invoice. The way I add invoice works is that somebody who wants to invoice, party A that wants to invoice party B, will add to party B's invoice, pending invoice amount, the amount they should be invoiced by. So that's why you will see that I am invoicing somebody else. So I'm sitting there state. So I'll have to specify unknown. That's pretty much what's happening here. And then when pay invoice is 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 invoice amount owed state variable by the amount I paid by. So that's what pay-in-wise does. Now, just tracking through the various steps that's going to happen is you have an Absoridity 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 to somebody else, 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, the orchestra will then have to speak to the Zockratis, asking it to generate a proof with the private inputs and the public inputs required for this function, using the private proving key of the add-in-wise. Once that is done, we get back the proof to the orchestrator and the orchestrator will then speak to Shield Contract by calling the add-in-wise function. The Shield Contract, which in turn will receive this proof from orchestrator, will have to verify your contract to verify that bit of proof using the relevant verification key of add-in-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 container, which is listening to the timber events off-chain, will receive the latest commitment and the routes 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. That is pretty much it. Thank you, Chitanya. 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 slash eY blockchain. 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. And please use our phrase zaps. Do we have any questions? Or just gratuitous flattery. Yes, 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. I just was curious, do you guys have a roadmap or what are your thoughts around when you think it'll eventually be a little bit more mature and ready for production applications? These are disclaimers that we are required to put there based on the advice of our attorneys. 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, 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, thank you for the talk. So one question, is there a way that two private keys can really reach the information at the proof? So in that sense, you always have been figured out that the balances, for example, the only one looking at its own 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 to the proof to be included in the information? You mean to say if a commitment can be owed by more than just one key? Well, ownership is just always with the one key. And ownership is defined as not who's key, there is insight, 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 states, but it doesn't make sense to include the events in this known, et cetera. 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 inside it anyway. And then nullifiers, those are really what will be the variables that events transmit. I think we have time for like one more quick question and then we're gonna be yanked off stage. This is definitely great. So nothing binds it to just Ethereum. It has any EVM compatible blockchain that should work, right? Well, it spits out solidity smart contracts. Obviously it's in the byte code that is required for solidity. So in that sense, 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 byte code that's relevant to whichever blockchain you'd like to use it for. So that's one. And the second thing is like, if you want to optimize for like, let's say proof size or verification time or whatever, draw 16 versus Planck or what, where do we set that up? So the proof itself is generated by Zocrates. As long as the proving system that you want is supported by Zocrates, you can actually have it generate the proof in exactly the proving system that you want. Don't think Planck is currently supported by Zocrates. 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. Thank you.