ZKPodcast: Zexe- Decentralized Private Computation with Pratyush Mishra

Transcript

[Music] welcome to zero knowledge a podcast where we explore the latest in blockchain technology and the decentralized web the show is hosted by me Anna and me Fredrik [Music] in this episode we'll sit down with British from UC Berkeley to talk about sexy which is a paper for a new type of private smart contract BOC chain before we start we want to say thank you to

this week's sponsor Aragon one if you love working with talented designers building smart user interfaces or if you're really excited about making dows easy and accessible to create and manage then you should check out aragon ones available job openings the project is currently hiring a front-end engineer to help build the platform for modern organizations for more about the front-end engineering role or other available jobs check out aragon one slash jobs that's ARA gon dot o NE slash jobs so thank you again Aragon one now here is our interview with / - Sh today we're sitting down with purchase to talk about

sexy and it's a project I'm very excited about its we we've kind of teased it in episodes past and let's finally dig into what it is and we're also here with Anna as usual hello welcome to the show hi everyone thanks for having me on the show it's a pleasure to be here and excited to talk about sexy so first of all let's talk a little bit about you and where you are coming from what's your background and how did you get involved with this so I'm a I do cryptography as part of my PhD so I'm a PhD student at UC Berkeley I just finished my third year so yeah so my background is really I work on tsunamis

proofs and applications thereof so I started off my PhD with working on this project called decentralized anonymous micro payments and that was in some sense the precursor to who's actually and what that project did was basically trying to take Z cash like protocol and give it some flavor of micropayments as microphones are basically very tiny payments and how do those efficiently without suffering from large transaction fees same way that project had some notion of computation in there somewhere and what we did bit sexy after that was to try to extract that and formalize it and actually have an implementation and so that's where I got into sexy before that yes in general I'm just very very

interested in cryptography which is why I started my PhD in there and Here I am now what is it about this stuff that actually gets you excited is it math is it cutting like what's what's the what's the thing that attracted you to this attracted me to cryptography I think just the concepts in crypto are pretty mind-blowing light so your knowledge proofs that he has this concept where I can prove something to somebody and they'll be convinced but they won't learn anything other than the fact that what I'm claiming is true allowed there's a pretty insane topic myself there's also this notion of multi-party computation where a bunch of people could come together and compute each has some private input and at the end all of them learn the output of the

computation but they don't learn any of the other person's input so the only thing we learn is the output and syndrome being introduced to these concepts as an undergrad as also at Berkeley it's just mind-blowing that such thing would be possible what drew me specifically to I guess I work on more applied side of cryptography so trying to take this stuff and I know making systems that people could potentially use out of it so yeah but roomie to that is I know a lot of results in cryptography I've been very some sense theoretical I mean there's a promise of taking it to practice but people have not been really able to maybe ask because people in the real world don't care about privacy I don't know so like what I was interested in was trying to take some of

this stuff and actually make it practical and usable for people in the past though there have been crypt cryptographic ideas that have been implemented it took a very long time do you think in the space that you're working in right now is just faster so for a long time I think in cryptography like what was used in industry or in the real world was really the very basics of cryptography next signatures or encryption and these things we've known how to enter at least theoretically do for ages but this a lot of this interesting stuff like zero knowledge proof ramp you see we've also known how to do for like since the 80s mid eighties that's when like the first theoretical results about these care about but there has been like there hasn't been a similar ID no infiltration

into the real-world use cases I think recently at least was you know all its stuff maybe in general I know privacy has become more important as you get a lot of I notice big data stuff and people becoming more concerned about how the data is used and in a spread around so if they Apple in the blockchain world because everything otherwise is public's as far as your knowledge proofs have seen like a big and a lot of interest has been generated in these proofs most of our scalability and I think now for example in other parts of Industry also this multi-party computation is becoming interesting so yeah I think maybe now is perhaps the ideal time to be getting into just the transition period to be working on this stuff so it's definitely

exciting for me when I started there was no prospect of going to industry and working on all this cool crypto but now there's openings do you think though the world has been better educated about a lot of the stuff do you feel like outside of academia there's more and more interest I think definitely within the blockchain space there is a lot enough awareness much more than expected I was at the Zika proof workshop earlier this yeah a couple of months ago and I did not expect to be there to be that many people who tested in zero knowledge proof so that was certainly a very pleasant surprise I think yeah so maybe the blockchain space is a quite a bit of awareness I think outside of that still in like the rest of industry there's a lot of room for people to become aware

of it and that's partially on I mean probably mostly our cryptographers as well because sometimes you tend to be like siloed up and not ready to maybe dumb it down a little yeah part of part of it is like better education and simplifying how we explain stuff part of it actually is trying to go out and look for use cases and try to engage with people and industry that can be difficult like conflicting interests all over the place and it seems like that has been a lot of the path of awareness and adoption in the blockchain space is like gee cash came out and did it and and showed a successful use case and then it's sort of easier to understand the context and how to use it and for where it fits in and maybe other industries just need their use cases to look to and

get the inspiration to then dig in you sort of mentioned this other project that you were involved in that led to the sexy project was there anything else that you were working on in in your studies that kind of fed into this sin directly related to zexion not quiet I have a couple of other projects ongoing and done in the past that are in other areas of a plac tip to like one is in some sort of encrypted search where let's say that somebody has I upload my ID no files to some cloud server how can I retrieve the files without telling the server ok this is my file telling what the contents of the files are so that's one project as me making as if I had been audited SDX and stuff so not like directly related to

sexy and I have some ongoing work in some sort of private machine learning sort of area as well but yeah so related is XE I guess like just working with your knowledge proofs and yeah this this dissent Eliza known as micropayments was really like their core stuff in the pipeline up to sexy now would be a really good time to talk about sexy or z XE if anyone's curious how that looks I've heard a lot of discussion around whether or not the name is a good choice it's C exe and I suppose it stands for like zero knowledge execution help that it's a provocative name 76 in the memory

we actually have had I remember when we had Benedict on talking about bulletproof we actually had a little section where we talked about how that name came to be where did this name come to be so we had a lot of iterations on the names and remember all the candidates at some point we had something like ze ke Zeke and you're like yes an OK name but who is Zico Zeke is a character from a TV show in the 90s maybe a boyband yeah I was too young thing we're like okay so you know the zero knowledge is the K I said but we have this execution thingy why we like limiting that to just one letter and so

then we were like okay is your knowledge execution how do we I don't know shot in that okay like the core primitive and sexy we call the decentralized private computation or DPC is the name for that in the paper like should we put that is the name of the thing off the paper as well and we're like no that might confuse people cuz there's this other area of crypto called MPC which is multi-party computation look as XE seems nice and it's it's certainly interesting to say the least and did you make it an acronym does it stand for anything larger or knowledge execution education got it so what is sexy a system for doing some sort of private Oh any arbitrary private

competition on some decentralized ledger so if you take something like aetherium or and any of these smart contract systems what did how how the work is that when I want to execute a smart contract I publish the transaction and then everybody all the minors in the system or any phone or whose wants to verify my transaction has to we excuse the computation inside the transaction right and this has problems in terms of privacy and scalability in terms of privacy like we have to execute the program you need to know what data goes in who called the program and so the scalability we executed computation can be expensive so what we try to do ins XE is how to address both of these problems

so in privacy perspective what we try to do is have support general computation so you can perform like a theorem any arbitrary computation while hiding what program is executed what data is input to the program as well as who invoked the program so all the information should remain hidden and also we wanted the cost of the system to not really scale with the competition that you are doing so even if I do a very heavy computation the people who are verifying my computation on the ledger which they will be doing many years in the future I would to minimize the cost for them so I want that to be independent that cost of verification to be independent of the cost of my computation that I did offline and so me exactly the system is

just tries to achieve both of these goals by relying on technically own snarks when I first heard of sexy I I wasn't clear if it was something that would sit on top of a smart contract platform or if it itself was that platform and I wonder you know where do you see it so how be mile designing system envisions XE to be deployed I mean we'd haven't defined it yet but we thought of you deployed is you have some arbitrary I had no consensus mechanism underneath that provides you with some sort of I don't know block chaining mechanism and that's all you need and then is actually implements the computation aspect of its

mind privacy aspect of everything so it really sets as its own doctrine separately you could potentially try to deploy it as a smart contract within the cerium ecosystem but that would require at no loss of additional engineering considerations and then the privacy guarantees and scalability guarantees all that would change as well so we really thought I mean in speaking in terms of like this layer Palance at sitting at the l1 level and all that like l to scaling solution or privacy solution when you talk about these arbitrary consensus mechanisms or setups like what would that be like group of work or proof of stake or permission system permission it really you could be running on some single person's computer or somewhere in the world as long as it

provides some sort of a blockchain that you can verify that or this block came after this block that's all you really need so let's dig into this a little bit more you know imagine it is a blockchain you have transactions coming in you have you know transactions piling up and blocks being produced our contracts deployed to the chain publicly or are those private as well so unlike aetherium it's so sexy doesn't work in sort of this account based model it works in more of a UT Excel based model so for people to be able to use a smart contract you need to agree like what the core of the contract is so in that sense the code of the contract is publicly available at some point perhaps only to

the people who care about the contract executing maybe everybody else doesn't care so they don't know it but going back so because it works in this UT EXO model I feel how you can think of it is that if I have a coin that's associated with in Zach's ISA so it's associated with a so called birth and death scripts or predicates and the idea is that when I consume the coin when I spend it that corresponding predicate must almost be executed so must be satisfied please think in like the Bitcoin world you have these Bitcoin scripts right so if you have a pay to script hash sort of address and when I want to consume or spend the coin which is living at this address I have to satisfy the corresponding Bitcoin script similarly in sexy instead of the script we have this death predicate and when I

want to spend the coin I have to satisfy the death predicate so the code for the coin for the contract early lives inside each coin in some senses associate with each coin I always think of smart contracts as being like deployed to something and what you describe is it sort of like lives somewhere but not so the idea is often when I create a coin right I associate that coin with some sort of code and when I want that coin to when I want to consume that coin that code must be executed and many checks inside that code must be satisfied so really the code is only executed when the coin is spent so it's like when you spend the coin you're invoking the contract in some sense we could implement I'd know something like zero cash or Z cash inside sexy by having

your code be when the checks at the value of the input coins is equal to the value of the output coins and now when I spend a coin I have I this code is executed so it checks at the input quantity equal to the output coins in terms of value this in general is you know a quite different computation model to something like a theorem like you said where you know in people familiar with Bitcoin and Bitcoin scripts probably understand this and just sort of it's it's intuitive and like how Bitcoin script executes in a theorem though the model is you deploy this contract and then you can you know send a transaction to this contract with zero balance and you just pay for the gas to execute whatever it is and you have some output of that contract

or it's to store some stage or whatever it may be you don't really have that here you kind of with your transaction you deploy a piece of code and then whoever like is the other party in this computation execute that code to like consume the coin and then I guess it's gone yeah I mean it could be self-propagating you could have the predicate say okay the next output coins must also have this whatever X predicate or X code inside them so yeah it's a very different model from aetherium so that you don't really I don't know it's telling the contract please run yourself you're actually executing it on your within the transaction and then it really you could plausibly have like a coin which is only associate whose only

purpose is to execute the code but the point is that now when I spend that code coin or whatever then that coin is consumed and can be self-propagating so it can say okay once I'm consumed please in the output make sure that there's another coin of my same code whatever whatever and then this keeps on going but it's not like this like this permanent account that lives in the thing--i'm world here you have you can have the same sort of permanence off the code but it has to be something self-propagating so yeah so we've actually had I mean this is not a uncommon thing to have VI had lots of troubles actually figuring out how do you program stuff in this model is it useful for anything and I know so far we found that a lot of the useful applications are really in this sort of

financial sort of well that we are really interacting with tokens and they're this notion of self propagation makes sense you can say okay this coin it can only be spent if the other coin is of type B or something in the transaction so then your predicate really is reasoning about local information right so then it makes sense reasoning about global information requires really sort of free shifting your understanding of how to write the code and it might not be I don't know hey it's possible that we can't think of applications where it's entirely clear how to make use of this model and how to write efficient code on the gate there's obviously some some big differences in

trade-offs and how these different models work you're not going to deploy like a Hugh contracts with is either because you're limited in in my transaction space and you know you're not gonna run cooked or kitties in this way because it's sort of like you need to like breed kitties then and like store them somewhere and self propagate this thing and redeploy it every transaction like it's not suitable but clearly there are some other things where it is more suitable and I'm curious like how does the programming language like whatever the script or the assembly or whatever that is compared to something like the EVM or something like

Bitcoin scripts so currently sexy is that a pretty very very beta state so we haven't in the implementation for example decided on what the official programming language scripting language for this would be even in the implementation and we just write arithmetic circuits and I mean our our 1cs constraints systems and put those inside us mark so we don't have some sort of like solidity or I know Bitcoin script type language is ekv M type language it's entirely plausible that one could implement these on top of our protocol because and snacks can do any computation right but yeah so we don't have as I said this is a very bitter

state so we don't have anything like a standard library for developers to use or even yeah it's syntax for what a language would look like but would you see that as a future step if somebody would like to run with this for any sort of plausible usability or deployment you would have to sanitizing some sort of efficient efficiently executable scripting language that is sufficiently high level that people could even use without shooting themselves in the foot as programming stacks directly as a pain yeah and I have enough experience of that so I mean in essence this predicate script that you deploy is a smart and then the person who executes this you know has their input parameters creates

a proof that they've run this execution correctly in this snark and then in there what they send back to the chain I guess is this proof and then it can be verified yeah almost exactly so we have a little bit of an extra step but basically as is as you said the person who's creating the transaction they execute the computation produces snark for it and this snark is basically a test that the competition was done correctly but this doesn't quite get you to our goal of like super strong privacy we want to also hide which function executed because for modern snacks roughly I want to verify the snack I need to know like what function the snark is for so if the blockchain wants to verify the snack it

has to know which function the snack is being produced for and this compromises our goal of so-called function privacy so what we do is do another level of so-called recursion so we use a snark to verify that these per application snacks are themselves correct and because this snark this big snark is zero knowledge we hide all information about the per application snacks yeah so but in the end what the chain is verifying is this big snark which attest to the correctness of the predicate proofs who runs the proof for the big snore it's the person creating a transaction so when they fit the transaction they have

to create this big proof verifying proof this is only one level of recursion yeah so basically so my adviser Ally and a bunch of his co-authors back in 2014 or so they had this very nice paper on so-called recursive snacks and the idea there is that what do you want to be able to do is you want to have a bunch of snacks verifying stocks verifying stocks or verifying stocks you keep how have this endless chain of so-called stock verification on this is based on this cycle of elliptic curves sum number theory stuff that's probably not necessary but anyway this is also something that coda is using so this sort of recursive composition idea but they're doing it like quite deep yeah

they go like basically infinitely that's their goal but the point is that this isn't maybe necessary for something like blocking scalability where you keep getting more and more blocks being produced if you keep verifying the passed state but in our case we don't really have that sort of concern because we only need to verify one level of proofs the predicate proofs you don't need to verify like those proofs don't you to verify other proofs and so on and so forth so when the person who's creating the transaction they just make this one mega proof that verifies these small proofs and that's it and they publish this to the to the ledger and yeah verifying this mega proof is still constant time the bigger proof you said verifies many smaller proofs what are the many smaller ones if I'm just you know executing one predicate or like one

transaction this one in into this one and then if I want to execute multiple transactions at the same time I can verify all the more what so what I mean I'm multiple proof is that within one transaction you're going to have I probably at least one or more input coins in one more output coins right so I mean what we have in the implementation is we fix it to be two in and two out so each of these two inputs and two output coils they have associated predicates so the two inputs have so-called what we call death predicates are dead scripts and the outputs have so called both predicates that dictate conditions on they're both and now this mega proof has to verify the correctness proof source of these for deathbed or each of these predicates so you have two births deaths Raticate

proofs and to both predicate proofs and the mega proof verifies all of these four I see if that makes sense why would you have to two coins is this sort of like if you're doing a trade like are they it's just a Bitcoin detail I mean at the very minimum you need I don't know when I what I want to do in the trade is for example if I don't have enough money in one coin and each we have to combine coins right so I need to have at least two coins that are so I can combine them and then if I have I want to have some like change from the transaction right I want to send if I have fifteen coins coming in but I only want to send ten coins to the vendor that I want to have like a change

address so then that's why neither to two out as well so two and two out is like really the minimum that you would require want for any sort of functionality I mean that's the standards like Bitcoin you take cell model thing if you had one in one out you could only pay if you had the exact amount to pay and you could never get changed on is there any case where you have more than two well you could have I mean if you wanted to reason about lots of different so in sexy is not just for payments it's supposed to be for like arbitrary computations right so instead of having just coin value inside a coin but we have in sexy are so called data records and they store arbitrary pieces

of data so if you want a transaction to reason about lots of different pieces of data coming from different sources then you might want more than two and two out you could have and no 3 and 5 out 5 in 10 out 10 in 5 out whatever so is is this already defined in this or arbitrary fashion that you could tack on as many as you want or is that a like theoretical you could sew the okay so the code base that we have it's entirely generic in terms of this you just specify what you want and it'll generate the parameters for that I could totally imagine in a system like this because you want to keep each code piece relatively small there might be like cascading things happening so like I

call this that creates a bunch of coins and then I caused the death predicate on these five and then like I mean we already see this sort of happening in aetherium if you touch one thing it does a bunch of Paul's calls to other contracts and then at the end of everything you've dirtied like 15 places in the in the tree so yeah that that's cool then you can sort of do a bunch of stuff in one yeah yeah this has some caveats though so the issue is that doing this now you're paying for my look so in terms of privacy you can either have like multiple parameters for two and two out three and three art or whatever combination you want but the

point is now these transactions will look different to observers on on the blockchain so they see what this is that for example if I know that one particular contract can only be executed as three and three out then I know that okay if I see a three in three our transaction is probably for that contract so then you lose some of your function privacy guarantees and also from a efficiency perspective now okay so let's say you don't want to have this sort of loss in privacy or you can then say as everybody in the chain must use say five and five out but now everybody in the chain has to pay for this cost of five and five our transaction which is higher than two and two our transactions so you use like a efficiency functionality a privacy trade-off you have to make so

what you can generally do is sort of stripe your computation across transactions so you can be like okay I'll conduct part of my transaction and my computation in this transaction and this leaves them intermediate state I lose that intermediate state for a computation and I'll put in a new transaction and then so on and so forth so you keep propagating a state and keep prop dividing your computation up across transactions that's also possible but that again makes reasoning about this stuff trickier just to go back for a second on that when you talked about the different number of coins that you could actually have is that something that would be consistent throughout an implementation or could that be different per ZK snark within the same system you could have like different

transaction types which say two and two out three and five out whatever number you want and that's entirely possible within the same system you would have to have different snoc parameters so basically in the end for this mega proof that we talked about it has to verify either two and four proofs or ten proofs or whatever so for each of these different numbers you would have to have different parameters so that makes some of the cost a bit trickier would you do something like Sonic for example which has this nice property that your setup is entirely universal right so you can use something like Sonic to get around this problem of doing setups per number of inputs outputs when you have to do a set up per contract that you deploy as well yeah so that's one big downside

that we are hoping to address in sexy so as I said so now we have a proof predicate that is executed in the transaction right and as we know snarks have this terrible problem of clustered set up or at least the most efficient snacks have this problem of trust etcetera right there is a per application set up one nice thing in Zack see is that we're able to isolate these sorts of different applications so that if one application does some malicious setup as long as they don't use that application and can't affect mean anyway only the users of that application will have to suffer the consequences of this animilitia stress to set up but that still leaves the problem of the application that I do want to use how do I trust that they're

set up as one then has been done correctly so this is where like one nice feature of our implementation is that it's entirely and our construction paper is that it's entirely generic in terms of proof system so we use the concrete proof system in our implementation that requires a particular per application set up different one but we can easily replace this with something like Sonic which has a universal set up so you do this Universal set up and then each application can deterministically derive their SRS on this their public parameters so you only need to trust this Universal common reference ring that everybody in the world has to use so as long as everybody trusts that then your application is also secure and yeah so there's a lot of work coming up that

tries to build on Sonic and improve efficiency there so we could deploy that in Zack see it's really cool because this is like a we had we had Sean Bowen talking about Sonic's and this is like kind of a place where we see I mean I think we've heard a few things today at Z Khan where's Sonic's can really come in and help or this Universal trusted set up could be incredibly helpful to solve a lot of the problems that [Music] necessarily just across all like predicate sins XE but across multiple block chains even yeah you could just have one set up across one uni Universal trusted set up in the world trust across all of these systems because everybody

has to trust it yeah it's pretty cool one thing I'm curious about it was the construction is you had this EXO model have you thought about applying it to an Accounts based model something like ethereum what's the pros and cons with that so we did think about this and I think that it might I don't know maybe I'm just being very negative and cautious I'm not sure how one would achieve the same sort of privacy guarantees that you can achieve in new TX a model that that you would in an account based model mostly because so the issue is that so now let's say I have a smart contract in aetherium right somebody invokes is somebody and now the state gets updated yes the computer let's say I'd know it's some sort of token smart contract right so somebody makes a payment to somebody else so this

involves updating some locations in the table of this in the database of the smart contract right the problem but this is now how do you hide which locations are updated and the UT Excel model this is okay because in some sense this table is distributed across the entire blockchain in some sense but in this account based model if you want to hide which location is changed which balances is decremented and which is incremented that would require somehow touching all the other locations as well right because you have to you can't reveal which location was touched and this is this is really the problem like extrapolating this - Thank You Jeanette compeition this is a problem with getting the sort of privacy in account based models so there's some work like I

think it's called solidus it's from I see three folks which does this in a very very permission setting which is maybe like three or four nodes in your ledger or something they do it in like between banks or something where there's a specific triple graphic primitive called oblivious RAM which allows you to do this sort of oblivious or is update to one location without revealing which location is updated so there is a way to do this but it it's not really scalable if you have thousands of people updating the database at the same time from what I understand taking the sort of strong privacy guarantee and trying to put it in accounts based model at least it might be beyond the reach of our current techniques so let's get back to the proof systems you said it was generic over any proof system which ones are

have you implemented which are you planning on using like what would what fits what's a good proof system to use with this okay so to clarify that on the generic food system we do require some conditions on the proof system so at least for the predicate proofs for the per application proofs we need them to be succinctly verifiable so what I mean is existing stocks like I don't know garage 16 or in growth malice 17 what these provide is believed that when you verify the proof it's constant time independent of the size of the computation that occurred something so the nice thing is that the proof is shot but also verification time is shot something like bullet proof you get the property that the proof is shot but

verifying it it still takes as much time is proving right and this doesn't quite work at least in our design of the system for mainly for the privacy guarantees all right because if you it's sort of a timing attack thing where if you can determine how long some contract takes to execute you can didn't like see which contract they call by measuring the verification size yeah exactly if you know that the contract is supposed to take one contract expires won't of contract extend as you can see on this verification is obviously faster than the other one and you can exactly tell which contract is being executed so you lose your function privacy guarantee see as this function privacy is really the

reason a lot of the reasons for a big user for a lot of the decisions that you made but yeah so because of this constraint we want to succinctly verification we've mostly been limited to mostly the sparing based snarks in seeker snarks in particular in in our implementation we implement this growth mala 17 because this also provides this technical property of so-called simulation extract ability it basically prevents in some sense replay attacks within the blockchain so that's the one that we use is pretty efficient proof size is very tiny it's no less than 200 bytes verification is also only a few pairing equations so it's very it's very nice the downside of course is this per

application setup that you have to perform the nice thing is that we can our system being generic we can replace each of these with something that is still has the same 16 clarification and 16 proof size property and replace that with something that doesn't have this Universal set up drawback so maybe in the future if it happens you get some sort of I know something like Sonic is improved it so that proving and verification all are very nice and fast and we could drop that into sexy with I mean they would require some changes not the core structure but just maybe writing constraints to verify proofs and stuff so there is some work not a large amount of work you could drop those in in the future maybe if you get some sort of

very efficiently verifiable Starks or these IP based snarks that Alessandra was talking about also as econ today then you could also drop those in you would have at the moment the downside is the proof size is a bit larger and verification time is a bit worse so but it's possible that they can bring that down as well and then you could just drop those into sexy as well so it's very generic the requirements should be zero knowledge sixteen verification and sixteen proof size and that's the mean they're not non-trivial demands but there's a number of constructions which meet them and which probably will be more in the future getting a chance to be here at seek on and around a lot of really good

cryptographers and academics researchers I actually asked some people who had read the sexy paper what they wanted to ask you and one of the questions was could efficiency be achieved by sacrificing generality in the death and birth predicates so it does depend on the on the application so if you want to specialize is XE and say okay I don't care about doing general computation I just care about I don't know tokens plus maybe a little bit of and I just want to do Dex's for example are some atomic swap then yeah you could hard code all of that information into say I want parameters and you don't have per application parameters and then that's it now then you got you got you got actually probably a 10x boost and efficiency so you got a massive improvement it depends on like how how

how much generality you're willing to lose if you say okay I only want to execute these five computations then again maybe you can get a slightly better efficiency than what we have there we don't know at all about what applications somebody might want to execute so we have to so basically this actually has to be ready for any application right that might come now or in the future or people who have not even thought of at this extreme end of specialization doesn't just becomes ecash yeah you could just remove all the very fancy stuff and just be like okay I just want to do one one payment with one sort of token and then then you have something like Z cash probably less efficient because Sean and Dara and everybody else has put in a lot

of effort into optimizing it but you would have that you could go like a couple of steps you say okay I want multiple tokens and okay then that's something that you can do you can go a couple of more steps and then be like okay I want to do a little bit of maybe very simple Bitcoin scripting kind of thing then maybe you get Adnan then you're already at like some level of generality where you don't really buy much from not being fully general that you still paying a cost but you're not getting full generality at that point you might as well be like okay I'm gonna support arbitrary computations there's a big gap I think between supporting some very minimal set of computations and then once you start bleeding over into in very very limited sort of generality then you paid the full cost anyway so it

doesn't make sense to not be fully general in the case so we didn't actually get a chance to touch on this but one of the use cases that you will often talk about in presentations and actually it's in the paper as well is the it's like a private scaled decks in a way in the case of that example how generalized is it so you could limit so you can't as we have this progression right you go from Z cash to you add one more token a couple more tokens and you have multiple tokens doing the same thing that's still very far from generality so you can just you can do that a few tweaks to the Z cash protocol for example so you have that and then if you only wanted to support was just this Dex sort of application you could also do that with us after a sacrifice or

conceding much in terms of generality you just have this very simple I don't know you check that the other coin is off the what do you want to exchange it for and then again you're not anywhere near generality so now they are still limited at like basically three things right now you can trade and then you can trade between assets and that's all you can do the moment you want to start doing more general stuff like you want to have any sort of user control on what what is being executed then that's where you need the generality so if you just limit it just Dex by themselves and that's all you care about in the entire lifetime of your system then there's no need for not no need but there's less need for a lot of the infrastructure that we develop in sexy but if you ought to have any sort

of user control and what they want to execute then that's why you want more of a generic infrastructure cool the other use case that you have is a is a private stable coin yeah so that case is a bit more interesting because what do you support or what discussed in the paper is some sort of not just stable coins but any kind of token where you want to maybe perhaps change the policy surrounding at an issuance of the coins or in a black listing or white listing of addresses and in these cases email actually do want to update the policy as time goes on and they're having some sort of generic infrastructure is actually very useful because they had the policy changes so now you need to support different policies which is you don't know what the boss is gonna be so you have to be general one other

question who came from one of the co-authors of the paper Howard Wu he was talking to me it wasn't exactly a question but he was talking to me about all these other things that would be amazing to include so if you had a wish what would you like to include what would you like to have included in this iteration of the paper so I don't know what how I was talking about whatever US was super tired at the end if like working on sexy because it took us we cited it basically so in the beginning of the talk I said how he like this decentralized micropayments paper was sort of the inspiration so that paper was published sometime 2017 and we started having the seed ideas for sexy like a couple of months after that so yeah this is like we started working on

the very eve I know rough idea of Jack seeing like maybe June 2017 so and we published the paper on or we put on any print like in October 2018 or so so which is a long time to work on that so this is me and Howard we and Sean we works on the implementation and yeah just all implementation was difficult but also formalizing all these ideas of how do you program and like what what sort of security guarantees in privacy grant did you get all that was worked out with us and Rove and Matt and Ian and everybody else so just all this entire process took very long so all the way the paper is very dense in both conceptually as well as in terms of like the implementation side of it so I don't think that any reader would have

either get by the time they get to the end of the paper would have maybe two to two types absorb more concepts who knows maybe it then they're like give me more that's a 75-page be very very excited enthusiastic reader they can just talk to me or anybody and the paper so yeah you mentioned a bunch of other people there this is obviously shared work with a lot of people who is involved I'm also super curious to hear what is actually implemented what exists in theory your implementation what is it written in where can I find code okay a lot of questions well it's tough in the beginning so yeah so this is joint work

with a lot of brilliant people's palace and Rukia has my adviser at UC Berkeley Matt green and Ian Mears who are were at Jeju ian is now faculty at University of Maryland so congratulations on that Shawn Bo who is I was on the podcast previously but yeah here's one of the foundational aspects for writing a lot of the code and Howard was also ya know me and him collaborated on a lot of the code say I was a very much a group effort both on the conceptual side and the implementation side and yeah it really needed I think everybody's inputs to formalize like what we wanted and actually get some sort of reasonable

system at the end of it and the second part of Frederick's question what has been implemented and what is sort of in the pipeline to be implemented yeah so with the implementation is basically we have information of the transaction creation mechanism the transaction verification mechanism and the set of mechanism all that stuff is implemented what we don't have is we haven't hooked it up with some sort of blockchain that you could plug in so you can what we've written our code in a generic you know fashion that you could take it and plug in adding something like the cosmos SDK or the parity substrate SDK and you can just anything which has some sort of block chain mechanism and you give it a bunch of transactions and and implements the chaining and block

creation mechanism for you so as long as you have that you can take our code and plug it in everything so you can yeah in with our code you can create the transaction verify all that stuff it works you just need this database or blockchain underneath to plug it into it's implemented in Russ but yeah we have like a implementation of the finite field magic snark stuff gadgets for these snacks and constraint systems and then there's XE m and this transaction creation all this stuff on top of that and yeah a large fraction of the code was built on top of my Sean and Darrin works on namely the pairing and bellmen libraries as well as a lot of techniques from the sapling version of Z cache for like the efficient Edison hashes and all

this all the stuff is like a core component of as XE as well where can I find the code yeah so the code is at libs XE org so li b z e XE dart and the paper is also online if you just probably I don't think this XE is a very common thing to search for so if you said sexy I think it's a little it's a little further down but maybe you know it'll move up an SEO cool well thank you so much for being on the podcast and telling us all about this very very interesting concept protocol paper good luck with it

no thank you thank you very much is all in my pleasure to be here and yeah there's a fantastic platform thank you and to our listeners thanks for listening thanks for listening you [Music]