Nightfall by Duncan Westland, Chaitanya Konda, Michael Connor & Paul Brody (Devcon5)

so we're gonna go ahead and get started I'm gonna 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 a why right ey is all in on the etherium ecosystem right everything that we do all of our applications that we develop in blockchain are developed in the etherium ecosystem they run on the etherium private solutions they run in quorum and most importantly from a strategic standpoint everything we do is focused in the long run towards making it possible for enterprises to use the public main net now why do we believe enterprises should use the public name that 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 going to 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 going to hand it over to the brilliant nightfall team Michael [Applause] 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 going to cover the high-level architecture how people can use nightfall to build on top of their applications and their new serfs going to 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 okay as Paul mentioned and that's why we build nightfall so what kind of privacy does nightfall enable at the moment well it enables privacy of ERC 20 contracts and ERC 71 contracts so you're fungible and non fungible tokens already deployed contracts people who earn those tokens to make their tokens private and they can hide the content being sent so for ERC 71 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 ok 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 main that 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 or 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'd really encourage that so at its core nightfall has six sub protocols so it does mint transfer and burn off standard years 20 and years to 7:21 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 near c7 21 these token commitments later be used to transfer between various parties to transact confidentially as well as anonymously and Bern lets you do the opposite of mint which takes this token commitments and burns them stick 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 and so you 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 proof a Zika proof of chain and and it's done in your local server but also it your local server also holds their private information that is required to do these transit 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 and if it does multiple jobs but it also talks to various kinds of contracts most importantly being the ERC 20 in ER c 7 21 standard contracts so when you'd like to mint or transfer or burn what you would have to do is create a proof of chain give it to the shield contract shield contract will then on mint escrow your token or on burn release your token and but it uses these various functions within shield contracts 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 verify function within the verifier contracts to verify these proofs on a successful verification it adds these token commitments into the token commitment cartman's marquetry there are two important data structures in the initial contract one being the mercury 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 commit with its nullifier or whichever has been spent yes so if we take a look deeper into how the process works for first in ER C 721 token so first let's suppose Alice a user of an ER C 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 she'll 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 matter so they're after every transfer is private no one knows who is Sam what to whom so we get that privacy that businesses need and crucially the Merkel tree within the shield contract the leaves of which hold all these tokens we've made big so we've given a huge anon in anonymity set of about four billion and so that's the 32 deep Merkel tree so it's really important and again people can transfer transfer no one learns who assumed 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 you 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 er C 20 tokens so if you have already deployed an ER C 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 mints a commitment and because of the non fungibility of putting making a commitment it's like putting money in an envelope so then we have to do similar to Z cash a to in to our 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 have been a lot of talks on ZK snark so we're not going to go into much detail on how they work there was a really great track yesterday on how they work and 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 the proof just looks like random gibberish numbers to outside observers but crucially through ZK snarks 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 nightfall application itself looks like this the entire application is dark riced and it's a microservices based architecture at a very high level you have a PGA Tour micro service which acts as an authentication as well as an orchestration layer and which in turn speaks to the downstream micro services being off trains zkp accounts and database what option micro service lets you do is talk to various parties off chain without no information being recorded on it such as ATM 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 aetherium but for example a recipient of a token has to know in order to access his token commitments so that kind of information you you communicate off chain using swarm part of the etherium stack and accounts micro service lets you create accounts on the fly it's um account standard accounts in order to do mint sprint or transfer as and when required the database micro service 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 and this will be user specific information that you're storing in MongoDB I'll talk about zkp in a second but all of these all of these micro-services can then be exposed to whatever sort of front and interface your life nightfall currently has a you eat that that you can use that we use for demonstration purposes you can also scrape that and integrate it with an IOT sense or device or an ERP or another web app as you require going a bit more detail into zkp and it has two components that it that it talks to at its core firstly the Socrates container Socrates is an incredible tool that extracts away the generation of proofs for Zika start it apt it abstracts away the proving and verification key generation exporting verifier and verification of chain and it is also quite up to date on the latest happens within a 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 minge transfer and burn and we then have to send these trends and these proofs onto the blockchain using a we use a guest node for this for the moment and the get node talks to shield contract and shield content internal interacts with the other complimentary 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 micro services can consume but zkp micro service by itself can can be used to to do most of what mints burn and transferred us today so what next for nightfall so we have a road map 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 uture that's 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 cost 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 transact or anonymous through relays and so if there are any people knowing relays please gain touch we 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 they're coming becoming more efficient so okay so one of these odd more points I've been working on is prove batching so as you may know the verification is quite costly so we developed a prototype to do to do the bad chain so so the most generic and practical way to do batching for the time being is to do it via prove composition that is you create a pool that verifies another pool or the many others post so so it was introduced in this paper about four carri in 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 up for that generates a pool because the arithmetic of generation of the proof is not the same as the verification of the pool so in this paper they have introduced this cycle of elliptic curve so mainly so namely m84 mhz sex curve so mostly in this research branch we know mostly negative results about this we cannot find for example cycles whether for example be a family using in here young or Freeman family we cannot find composite order cycles of elliptic curves so we have only this energy for energy cycles and and the problem with these cycle is that so they have inbreeding degree four and six so that makes the security in low or so to solve this problem there are two solutions whether you have to increase the size of the film so this is like the variety for 753 an m-80 675 field used by coda so so this comes with a trader so you have high security but slow batching all the other protein powder was introduced in the XE paper which is maybe you need only one nicosia abounded a recursion and then you can find good security curves but then also the outer outer curve is is low so there is some trade trade-offs and so our protocol we have developed a somewhat in between so we took the advantage of the this fast cycle of 74 m86 and we do the batching over this energy for m86 so as long as you want and then whatever 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 you we created a new curve we call pendulum so via Cox pinch method and we push this last pool 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 you have so those mathematical equation that is the subgroup order of the one elliptical is equal to the characteristic field or the other one and vice versa so so we we are batching pose so 2 by 2 so we restrict issuers to batch to submit force on em 86 and then we do this recursion and so we we find last off and then we do a final composition of this pendulum curve that we push into the blockchain so we've tried to do everything in so practice so that the community can you use it so we we've added some some some nice features into the parties for instance so everything is public by the way so we've published this this morning so for instance in Socrates now you can you can do Socrates verify so we have current line verification in Socrates so we add so we made so we changed how how Socrates was built and we we made Socrates generic over the car so so parties for now allows you to generate force only on ads being curved and now you can generate in amenties for m86 or any other curve that you have in your back-end so and we've also developed this gadget of aggregation so we our work realized also on on bosoms or credits to Bhutan for this as well so we put everything into into Azure parties and we published ours our repos but so yeah the problem with that is we can go mean it for the time being and my vision is to go maintenance so we are waiting for the the community decision on AIP 1962 so if it goes in Istanbul we can we can have so pre-compile of our pendulum curve and we can do this on the minute so and finally so this batching protocol was developed in another project called French kiss and the night zone so this is a private swap so that relies on DK snacks proof batching so in in nightfall now you can have you can do transfer now you can do transfers in both ways so it is a swap and you will have three pools so one of the first transfer is the second or the other transfer and one matching ZK slack proof and we aggregate those ripples and we push to the shield contract only one one proof that verifies them all so the the repos are public any contribution is welcome so here are the links and so I think that that's it for me thank you so if you have any questions [Applause]