 So we're going to go ahead and get started. I'm going to be very, very brief. I'm Paul Brody. I'm the global blockchain leader at EY. And before I hand this over to the people who actually know what they're doing, I just want to kind of give you two pieces of information that might be useful for your background. Number one, a little bit about EY. EY is all in on the Ethereum ecosystem. Everything that we do, all of our applications that we develop in blockchain are developed in the Ethereum ecosystem. They run on the Ethereum private solutions. They run in Quorum. And most importantly, from a strategic standpoint, everything we do is focused on the long run towards making it possible for enterprises to use the public mainnet. Now, why do we believe enterprises should use the public mainnet? This is item number two. We believe that blockchains will be the biggest transformational technology for enterprises since ERP. So ERP got enterprises to coordinate internally. Blockchain is a tool that's going to allow networks of companies, entire business ecosystems, to transact seamlessly with each other, to build complex supply chains with a very low overhead and incredibly high efficiency. But, and this is the important thing, none of this matters. And it will never happen if we don't have incredibly high standards of security and privacy for public blockchains, right? No corporation, no enterprise is gonna sign up for anything if they know that their competition can see what they're buying or how much they're paying or where it's going. So nightfall is all about our efforts to start to make that possible. And it fits in with a lot of the other work we're doing, whether it's audit, security tools, or regulatory compliance. And without any further ado, I'm gonna hand it over to the brilliant nightfall team. Michael. Thanks, Paul. So yeah, what we're gonna do is we're gonna quickly go over what nightfall is. Paul's covered why we're doing this. We're gonna cover the high level architecture, how people can use nightfall to build on top of their applications. And then you, Seth's gonna cover an exciting new piece of work we're doing on batching. So yeah, public blockchain is great. We can all agree with that. But the transaction data is public. Whereas businesses, they need transactional privacy, as Paul mentioned, and that's why we built nightfall. So what kind of privacy does nightfall enable at the moment? Well, it enables privacy of ERC-20 contracts and ERC-721 contracts. So your fungible and non-fungible tokens already deployed contracts, people who own those tokens to make their tokens private and they can hide the content being sent. So for ERC-721, the asset, or for ERC-20, they can hide the value being sent. They can also hide the recipient. So the person being sent the money will be hidden and won't be known. Okay, and really importantly, and what we're most excited about is that this is completely open source in the public domain. So we've released all this because we believe the best way to get businesses to that stage to using the public mainnet is to contribute and to work with the community to get these tools as good as possible. So we're inviting everyone to come look at the repo, contributions are welcome and let's talk and we'll talk about what we're planning on doing next. If anyone has any good ideas, get in touch, open issues, open PRs on GitHub, we really encourage that. So at its core, nightfall has six sub-protocols. So it does mint, transfer and burn of standard ERC-20 and ERC-721 token contracts. So what a mint does is it takes your ERC-20 or 721 token and mints it as an equivalent token commitment that holds the same value as a fungible token of ERC-20 or the same token ID as the ERC-721. These token commitments can later be used to transfer between various parties to transact confidentially as well as anonymously. And burn lets you do the opposite of mint, which takes these token commitments and burns them to give you back an equivalent ERC-20 or 721. That is held in escrow, it's released on burn. At a very high level, nightfall looks like this. So if you would like to do a mint or a transfer or a burn of a token or a token commitment, you have to generate a ZK-proof off-chain and it's done in your local server. But also your local server also holds the private information that is required to do these proof generation as well. But the off-chain server now will have to interact with something called a shield contract to make these proofs happen on chain. Shield contract acts as an interface, it does multiple jobs, but it also talks to various kinds of contracts, most importantly being the ERC-20 and ERC-721 standard contracts. So when you'd like to mint or transfer or burn, what you would have to do is create a proof off-chain, give it to the shield contract, shield contract will then on mint escrow your token or on burn release your token, but it uses these various functions within a shield contract in order to do that. These functions in written themselves actually take the proof that is required along with the public inputs that is required to verify this proof and shield contract will then call a verifier contract and the verifier function within the verifier contract to verify these proofs. On a successful verification, it adds these token commitments into the token commitment markup tree. There are two important data structures in the shield contract, one being the markup tree that holds a list of all the commitments created and the other being a nullifier which holds a list of all the commitments that have been spent in such a way that you can't associate a commitment with its nullifier or whichever has been spent. Yeah, so if we take a look deeper into how the process works for first an ERC-721 token. So first let's suppose Alice, a user of an ERC contract owns a token T. Okay, and she wants to make this private, she wants to start doing transactions under zero knowledge. So she will invoke the mint function which nightfall exposes and that will first give the shield contract custody of her token and Alice will also say, here is a commitment which hides the token, hides the underlying details of the asset and binds Alice as the owner of that asset and all people, all other observers of the blockchain will see is just a random number. They won't be able to interpret thereafter what these commitments mean. So thereafter, every transfer is private. No one knows who has sent what to whom. So we get that privacy that businesses need and crucially the Merkle tree within the shield contract, the leaves of which hold all these tokens, we've made big. So we've given a huge anonymity set of about four billion. So that's a 32 deep Merkle tree. So it's really important. And again, people can transfer, transfer, no one learns who has sent what to whom while these commitments are being sent within the shield contract. If at some point in the future someone wants to burn their token, i.e. make it public again, do something else with it, they can do so. They can call the burn function and it exposes that now Bob owns T, the token. Similar thing for ERC 20 tokens. So if you have already deployed an ERC 20 contract, your users can use a shield contract to make those tokens private. So again, Alice owns some value and she gives the shield contract custody of that value in tokens. It means the commitment. And because of the non-fungibility of making a commitment, it's like putting money in an envelope. So then we have to do similar to Zcash, a two-in, two-out approach where Alice takes two of her tokens, transfers one of them to a recipient and she gets the other in change. And similarly, no one learns who is sending what to whom in this process. And finally, if someone wants to retrieve their token, they can do so at the end. Now there've been a lot of talks on Zcashenock, so we're not gonna go into much detail on how they work. There was a really great track yesterday on how they work. But crucially, an ordinary computation on the EVM, you pass inputs to the computation and it's done on the EVM. All the inputs are public. But some of our inputs we want to be private, such as our secret key, what the asset is, who we are. And so what we can do is we can generate a proof. And we pass that proof to the blockchain. And a proof just looks like random gibberish numbers to outside observers. But crucially, through Zcashenock, these can be verified as true on the blockchain and we can verify that this person does indeed own a token and has the right to transfer it. Okay, so the architecture of the nightful application itself looks like this. The entire application is dockerized and it's a microservices-based architecture. At a very high level, you have API gateway microservice, which acts as an authentication as well as an orchestration layer, which in turn speaks to the downstream microservices, being off-chain ZKP accounts and database. What off-chain microservice lets you do is talk to various parties off-chain without no information being recorded on such as Ethereum communication. And the kind of information that you'd like to transfer off-chain is the private information that you'd like to keep from being visible on Ethereum. But for example, a recipient of a token has to know in order to access his token commitment. So that kind of information, you communicate off-chain using SWARM, part of the Ethereum staff. And accounts microservice lets you create accounts on the fly, Ethereum accounts, standard accounts, in order to do mint, burnt or transfer as and when required. The database microservice talks to MongoDB database and it stores both public and private information that you're using in your proof generation and in your verification for various transactions. This will be user-specific information that you're storing in MongoDB. I'll talk about ZKP in a second. But all of these microservices can then be exposed to whatever sort of front-end interface you like. Nightfall currently has a UI that we use for demonstration purposes. You can also scrape that and integrate it with an IoT sensor device or an ERP or another web app as you require. Going a bit more detail into ZKP, it has two components that it talks to at its core. Firstly, the Socrates container. Socrates is an incredible tool that abstracts away the generation of proofs for ZK Snarks. It abstracts away the proving and verification key generation, exporting verifier and verification off-chain and it is also quite up to date on the latest happenings within the zero-knowledge world as in the various proof systems that are coming up or the various hashes that are people using today. So we use Socrates to create these various proofs of means transfer and burn and we then have to send these proofs onto the blockchain using a, we use a geth node for this for the moment. And the geth node talks to shield contract and shield contract interacts with the other complementary contracts that we talked to. All of this logic, of course, is orchestrated with Node.js controller code, which exposes a REST API that the rest of our microservices can consume. But ZKP microservice by itself can be used to do most of what means burn and transfer does today. So what next for Nightfall? So we have a roadmap here. So we're looking to build more developer tools. If anyone has any needs or ideas or they've looked at the Nightfall repo and think something can be made better, please get in touch. We're always trying to make it better. One of our primary goals is to reduce the cost of private transactions. And NUCHEF is going to talk about batching. So we've made some leaps and bounds on that. We're also going to chip away at the smart contract logic to reduce the gas costs there. And we're also going to take a look at the verification scheme to see if we can use a more gas efficient one. We're also going to look at making the transactor anonymous through relays. So if there are any people knowing about relays, please get in touch and we'll look at that. And also we'll look at the trusted setup. So there are some new schemes coming out at the moment that get rid of the nature of a trusted setup that are becoming more efficient. So one of these roadmap points I've been working on is proof batching. So as you may know, the verification is quite costly. So we've developed a prototype to do the batching. So the most generic and practical way to do batching for the time being is to do it via proof composition. That is, you create a proof that verifies another proof or the many others proofs. So it was introduced in this paper about proof carrying data. And but there's a gap between the theory and the implementation because the problem is there is a mismatch arithmetic when you want to do a proof that generate a proof because the arithmetic of generation of the proof is not the same as the verification of the proof. So in this paper they have introduced this cycle of elliptic curves. So mainly, so namely, MNT for MNT6 curves. So mostly in this research branch we know mostly negative results about this. We cannot find, for example, cycles, whether for example, Bienn family using Ethereum or Freeman family. We cannot find composite order cycles of elliptic curves. So we have only this MNT for MNT cycles. And the problem with this cycle is that so they have an embedding degree for insects so that makes the security low or, so to solve this problem there are two solutions. Whether you have to increase the size of the field. So this is like the variants MNT4, 753 and MNT6, 753 used by Coda. So this comes with a trader. So you have high security but slower batching. Or the other approach in parallel was introduced in ZXC paper which is maybe you need only one recursion, a bounded recursion, and then you can find good security curves but then also the outer curve is low. So there is some trade-offs and so our protocol we have developed is somewhat in between. So we took the advantage of this fast cycle of MNT4, MNT6. And we do the batching over this MNT4, MNT6 so as long as you want. And then, so you do it off-chain so you do not care much about the security even if it is not an acceptable security for the time being. But then in the last composition we created a new curve we call pendulum so via Cox-Pinch method and we push this last proof that has good security into the blockchain. So this creates some sort of a graph so we call the pendulum graph so you have curves in vertices and edges so those mathematical equations that is the subgroup order of the one elliptical is equal to the characteristic field of the other one and vice versa. So we're batching proofs, so two by two so we restrict issuers to submit proofs on MNT6 and then we do this recursion until we find a last proof and then we do a final composition over this pendulum curve that we push into the blockchain. So we've tried to do everything in Zocratis so that the community can use it. So we've added some nice features into Zocratis. For instance, so everything is public by the way so we've published this this morning. So for instance in Zocratis now you can do Zocratis verify so we have command line verification in Zocratis. So we changed how Zocratis was built and we made Zocratis generic over the curve so Zocratis for now allows you to generate proofs only on RTN curve and now you can generate in MNT4, MNT6 or any other curve that you have in your backend. And we've also developed this gadget of aggregation so our work relies also on Boojum so credits to Boojum for this as well so we put everything into Zocratis and we published our repos. But so yeah, the problem with that is we cannot go mainnet for the time being and UI vision is to go mainnet. So we are waiting for the community decision on EIP 1962. So if it goes in Istanbul we can have so pre-compiled of our pendulum curve and we can do this on the mainnet. So and finally so this batching protocol was developed in another project called French Kiss Under Nightfall so this is a private swap so that relies on ZKSnacks proof batching so in Nightfall now you can do transfer now you can do transfers in both ways so it is a swap and you will have three proofs so one of the first transfer is the second or the other transfer and one matching ZKSnacks proof and we aggregate those three proofs and we push to the shield contracts only one proof that verifies them all. So the repos are public and your contribution is welcome so here are the links and so I think that's it for me, thank you. So if you have any questions.