ZK Podcast: Sean Bowe on SNARKs, Trusted Setups & Elliptic Curve Cryptography

Transcript

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 in this episode was sit down with Shambo from the electric coin company for a very special episode where we talked about all the things that he's worked on from trust of set ups and NPCs to zero knowledge systems like sonic and elliptic curve cryptography in general [Music] before we start we want to say thank you to this week's sponsor trail of bits

trails bits is offering a service where they will staff a security team inside your company they'll check up on you from time to time and make sure things are headed in the right direction have a security expert on design review calls reviewing your PRS or contributing security improvements where it makes sense once you outgrow the service they'll also help you replace them through prepping the work sample tests hosting some interviews and giving you an educated recommendation on who to hire this is not an audit it's a low-cost monthly subscription that will help you build a security team inside your company visit trailer bits comm for more info about the service so thanks again trailer bits and now here's our interview with shaunb oh hi Anna hey we

have very special guests with us today Shaun Bo I'm super excited about this we've had numerous requests to have you on the show and and we know that you're a very highly regarded person in this sort of zero-knowledge space so very excited about this episode thanks I'm really glad to be on here I've listened to a couple episodes of this podcast but this is really awesome did you actually hear the there's one episode I think it's like two three episodes ago where we we actually did a call out to you hoping that you'd come on our show I don't know if you actually caught that one i one of my friends friends heard that episode and pinged me mmm said hey you should you should check

this happen so yeah well I'm so glad you came on for those who don't know I'm just gonna give a little intro to who you are Shawn Shawn is a Z cache company engineer actually you're not called to the cache company anymore your electric coin company now yeah right so I'm a cryptographic engineer working for the electric coin company got it and you are you're the person who was behind the sprout and saplings e-cash trusted set ups as I understand it and you also have actually designed some of the elliptic curves and like the actual cryptography underlined Z cash yeah so I'm a mostly a protocol engineer working

for the company so I've done everything from designing and implementing the elliptic curves that we use at Z cash and also implementing the ZK snarks and the arithmetic circuits and the underlying protocol and other things that are anything that's related to the zk snark some kind of the resident ZK snark person at the electric point company very cool you're also doing a lot of this in rust as I understand yeah so it's really awesome that the latest sapling upgrade of Z cache is most of

the underlying cryptography is implemented in rust originally it was in C++ for the the for the original sprout release of Z cash but sapling is completely implemented and rust and it was a long journey because I had start I had started actually implementing rust ZK smarts in 2014 long before rust had even become a stable language so it took it took a few years but eventually I got I got Zika snarks and rust put into production cool why did you get into rust like what was what was driving

your decision to write all this stuff in rust I think rust melded with my personality a little bit rust is I guess the rust is a different thing to everyone but it seems to me like it's about writing robust software that is high-performance and those two things are really important goals to me when when engineering in general so I think that rust kind of inspired me to work on the projects that I do sometimes I work on probably say I don't need to in rest just because it's a lot of fun this brings us into our little bit of an

intro as well of something that we are curious about with our guests is why you're working the space what drives you what's your goal like yeah why are you here why are you working with this yeah so I think I'm here kind of as a little bit of an accident I really love cryptography and I really love rust I really love cryptocurrencies I really love privacy I actually don't have any academic background at all I didn't go to university actually I didn't even graduate high school I opted out of high school to study cryptography I had a

friend of mine that tutored me in cryptography he went to university he tutored me in his free time and so kind of in the early 2010's I was able to learn cryptography sir surrounded by a bunch of really groundbreaking papers that were coming out every other month solving some serious problems in the space it was really fun time because you know fully homomorphic encryption and snarks and all these other things were being addressed that actually practical implementations were being created for these kind of really exotic cryptographic primitives almost every day and so was

it was a really exciting time and snarks in particular when they came out I was fascinated with them I had already been very fascinated with bitcoins so I knew the implications and so I had started learning about how snarks work and trying to implement them and around the same time I was really interested in rusts so I actually in 2014 I had started trying to implement ZK snarks in rust and it is a project that I never finished until many years later but it caught the attention of Andrew Miller who's the chairman of the CH foundation and he introduced me to Zuko Wilcox I didn't have any job

experience or anything like that so Zuko kind of gambled a little bit and hired me and so I ended up working for the electric wine company it was one of the first couple employees and then I sort of became the resident snark expert from there for some house seems like a gamble that paid off yeah I'm sort of curious to go back to that time that like 2010 time you'd been studying cryptography with your friend but can you pinpoint like if there was some moment or spark or paper or something that really was like that turning point for you where

you got on this track I think it was the zero cash paper because I've been trying to implement ZK snark cryptography plus blockchain in my free time just as a little hobby project so I thought oh I'm onto something I can use CK snark something really private but when zero cash came out I looked like a fool because he's incredibly smart cryptographers were working on this exact same thing and they were miles ahead of me and they actually know how to do it and they actually implemented it and they're going to deploy it so I decided to just sit back and wait for the project to come out so I was I had known about

zero cash and I'd been trying to find information about when it was gonna launch and where its code was and things like that for a long time before eventually I stumbled into actually working on the project itself like so you mentioned a little bit we kind of talked about this in the intro what parts of the C cash protocol have you have you been involved in so when I when I joined Zee cash I was focused mostly on protocol engineering because we had to deploy as II catch so I have ripped out the current implementation and you know we're basically a fork of Bitcoin so I modified the integration between academic code and the Bitcoin

implementation to use a more recent version of Bitcoin then I reimplemented the academic implementation of the protocol and the arithmetic circuits and everything touching wauzeka snart's and then deleted all the academic code and in the process found a couple serious bugs and then I was tasked to join the multi-party computation project so I was the implementer of the first ceremony for Z cash ZK smart parameter ceremony so I guess if anyone has heard that radio lab episode on Z cash and you guys that that whole set up that was that was

something you designed yeah so I worked alongside our yoga boson I was the implementer area it was more of a you know crypto proof person and we kind of designed the protocol and implemented the multi-party computation for that is featured in the episode and it was it was a blast it took several months to develop and we were really I was a little bit worried because we were on the edge of our runway as a company this was back in 2016 and 2015 is when we got our funding so there weren't you know people throwing billions of dollars at your companies at this time like they do but like they did in 27

chose this little sling speaking about what this work that you've done and your background and I know the background of a lot of the people at sea cash are no PhDs or from the academic field what's it like working at sea cash and how does that balance between engineering and academia play out it's really it's really amazing because when I joins the cash I didn't have any academic background any Theory background really besides just learning my free time and the company gave me resources and access

to some of the best cryptographers in the world that founded our company or were friends of those people that I could talk to anytime I needed to learn about something or I had a question had something worked they were there and so that's that's incredible having the best cryptographers in the world at your fingertips it's really great so I learned a lot really fast because of that access and also the company was focused on the kind of technology I was interested in which is snarks so I was able to kind of catch up on everything at the time a lot of academics were working on snarks but

there weren't many like down-to-earth people that were actually implementing and trying to find applications for the software even though it was out there you know there's lip snark but there wasn't there wasn't anyone trying to actually dive deep and see if they could use it for something so being able to be one of the few people that were actually doing this at the time back in 2015 or so it was really a good opportunity especially for access to these academics because they were waiting for someone to say hey how do I use this thing they were really excited about that I think we actually so we did something different with this episode we actually

put out a call on Twitter asking if anyone had any questions that they wanted us to ask you and actually there was one question that came up that was related to this topic from Hadrian he was curious if you thought that getting a PhD was actually necessary or if maybe having more of an entrepreneurial background would be really useful for kind of entering into this face I think having a programming background is really useful I've been programming in hacking since I was so as long as I can remember but I didn't have any rigorous background in the actual theory and I think having a programming background is

really useful because these academics they post the the prototypes and so you can dive into the code and then figure out how that how it works and learn the theory and then BAM now you're a crypto implementer expert of some particular subfield so I think I think actually if you don't have a much of an academic background or you don't have a PhD or whatever I think diving into really niche subjects is really a good idea there's all sorts of things that you could become an expert in easily just by diving into the code that is produced by academics and and then learning things anything from fully homomorphic

encryption to to snart's and other things like that maybe not snarks anymore because there's so many people tackling that but there's there's all these really new bright ideas by cryptographers seem to sit in a corner until someone actually tries to come and figure it out from the programming background because these academics are not producing extremely high quality code they're just producing prototypes so that they can get their papers into conferences and so if you if you'd know code then jump in and make this stuff really fast and make it nice and clean and comment it and things like that I guess the problem here is or at

least that when I went to university what I found was that to be able to find those things that need implementation I needed to go to university and go talk to the researchers or find out through some means that these departments like what these things that I could dig into are if you don't go to university like how do you find out about this niche that could use a developer's touch that's interesting because I think what's cryptocurrency things have opened up a little a little bit because you can very plainly see the areas where cryptography can help and where improved can cryptography will have a substantial impact for example if you follow Bitcoin

you'll you'll know immediately when new papers are coming out and cryptography and and in cryptography it's pretty open everything supposed to be print and so on when new papers come out would say hey I have a way to do a zero knowledge proof that's really succinct then you know immediately that that can really be used to help improve a crypto currency like Bitcoin I think that's what allowed the space to be a little bit more open I wondered to just as an add-on to this do you think that sometimes having the it's gonna sound weird but do you think that it's possible that having the academic rigor and going through that theoretical thing could actually prevent some creativity there's a there's a missing

perspective I think from academics it depends on the academic you're talking about if you're talking about something some of them or I mean getting into a conference is really great but they're really rigorous about making sure that the code they produce is really high-quality but most of them are just interested in new results and prototypes are really really awesome for really enticing to accept a paper into a journal or a conference but most academics I think are not really concerned about that kind of thing unless they need to be so the perspective of an engineer is someone who's actually taking that code and trying to use it and which means that

you are trying to tackle problems that are really challenging that the academics were anticipating trying to write a robust implementation trying to avoid pitfalls that would cause the entire system to collapse that you're pointing so these sort of things are not really on the mind of an academic at the time that they're working on something but I think academics sort of really creative engineers are really creative they should they should work together at papers a little more often yeah I mean there is this meme of like academic code and it being bad but I think I mean you're right it's sort of it goes from being finding out new information

pushing the boundary of knowledge into what an academic might say it's like implementation details or it goes into engineering which is you know all the things that you're talking about like how do you make it scalable and fast and secure and avoid bugs and all of these things that we are we've learned in engineering and most of that is actually not really taught in schools at all in any field so yeah it's a very different space I should say that some some have for example there's this paper I'm a co-author on called sexy and we released code for fours XE it's basically a

programmable version of kind of aetherium programmable but with privacy kind of idea and I I didn't write most of the code well okay it's the codes based on what I've written but already for Z cache but a lot of the code was written by British and Howard from Berkeley for students of Alessandro and they have such a high standard of quality that it blows my mind they they don't release the paper or they don't release the code until everything's really really high quality and so I'm really astounded by that so some academics really go for the high quality

and really shows so I'm really impressed by that so it goes either way I guess yeah we've actually I don't know if you know this we've had Howard and Alessandro on the podcast before that's awesome so let's jump into some of the work that you've actually done I mean you just mentioned the sexy paper this is Zed e XE PS I just gave away my Canadian nest there with her she said I mean but yeah so tell us a little bit about that where is that coming from where is that coming out of so I can't say much about Zack city unfortunately what happened was basically after Zeke ash launched I had jumped in to trying to improve the the

ceremony of Z cache that we use for the first ceremony I wanted to improve the protocol because our original ceremony only involved six people as long as at least one was honest than it was secure I wanted it to be up to hundred people so I wanted to design a new ceremony at the same time I was working on optimizing Z cache so it was efficient enough that you could create transactions on a phone or something for example so in the process I designed some elliptic curves there's this pairing friendly curve and this this embedded elliptic curve and I was coming up with optimizations for how to do certain cryptographic primitives on

inside of the circuits for the pairing friendly curve and so on and so I I stumbled into this process of creating a new protocol for Z cache which was called sapling so I sort of shepherded sapling to the to the finish line along with the help with my co-workers especially Dara hawkwood was an amazing arithmetic circuit optimizer and also Strad so in this process I came up with a couple techniques and they ended up being useful for sexy so sexy was an idea of how do we create totally private totally anonymous smart contracts

basically and that kind of took took over my code and started doing some cool things that went out of control and I did not follow it so I don't know too much about sexier or how it works but I can tell you a lot about other things like things that I've started to work on more recently like Sonic or like the the new ceremony that we used for sapling which but let's get get into the setups that a little bit I think they're very interesting topics in general I want to get back to Sonic as well and touch a bit on that and carve development and a couple other interesting areas but why why are these trusted setups so interesting like why

has that been such a big focus of yours well unfortunately they're necessary a lot of people think that we're just it's just some kind of big production just for for public entertainment but it's really honestly absolutely necessary the first ceremony as we know now there was a there was a bug in the ZK snark a mistake in the ZK snark itself such that the ceremony although it produced secure parameters and and and the trap doors that were supposed to be deleted or were deleted the trap doors that we knew

about there were chapters that we didn't know that that weren't deleted and so so the first ceremony failed in that sense but it was successful in the sense that it was the first incarnation of this kind of concept of bringing people together and doing a multi-party computation and constructing parameters and going in these round-robin cycles and all doing all this stuff like this so that was a really really fun time but obviously six people cannot make a secure MPC it with at least one honest to construct parameters where millions of dollars or billions of dollars are at stake so especially not like to that like if you're looking for the

perception from the outside world six people who may or may not know each other I know that the code went out of his way to make sure that they didn't but like we as the outside parties need to trust that yeah this is a real challenge it wasn't just a challenge for Zee cash see I think if I'm not aware of any for other projects than Z cash that have actually deployed in production which have millions or billions of dollars underlying them which deploy I guess generic computation zero knowledge proves so 0 C cash is probably the first project and to do this and it's done it twice now but I

think the reason why especially because we've deployed ZK snart's and I think the recent one is because these these setups these setups are very expensive they're very challenging it's easy to screw up it's easy to for one participant to lose a network connection and then there's a bug and then they they don't know what to do and then the whole thing stalls or who knows but I find this also that a lot of the projects that I see in this space who are talking about wanting a snark of some sort they kind of brushed that aside us know we'll get we'll deal with that when we get to it and then when they start talking about ok now we actually want to deploy this saying how

do we do this they vastly underestimate how hard it will actually be to get the ceremony working yeah the ceremony is really a an extreme challenge and so improving it not just for Z cash but also for everyone else was something that was on my mind when Z Cash launched so I started focusing on trying to improve the ceremony what was that what you actually worked on after sprout had already been deployed was it like after that went live you then immediately started to think about this trusted set up or what were you focusing after that went live after that went live my focus was on the it was on that ceremony on the new ceremony but it was

mostly on the protocol for an improved version of Z cash which was sapling so I had designed some techniques and wanted to chain them together in a certain way and I started I implanted a prototype and got the company on board to to use it in Z cash and we have actually deployed it at a year after my prototype was posted but which involved you know I had to design some elliptic curves I had to come up with some optimization technique say they have commit circuits I had implement ZK starts in rust I had to implement the curve arithmetic in reston I had to do all this other stuff but tech you have a

hash function named after you to write the bo Hopwood Petersons hash or something yeah I think honestly that that hash function should mean okay well I participated in its optimization in some sense but Dara hopwood came up with most of the really clever tricks for that so maybe it should be hopwood both I don't know but yeah there's that there's a Peterson there's a there's a hash function which is based on an elliptic curve discrete logarithm problem which is just illusion resistant hash which is what we needed for the Merkle trees that we use in z cache Lee and Myers had told me hey if you could do this efficiently you know in circuits

I don't know if you can but if you can do this then you could swap this out for sha-256 or whatever we were currently using and so I looked at I looked at it and I was able to figure out some ways that we could optimize it I posted it at deira Hopwood came along and was able to have the cost that after I was off optimizing it so Z made it really efficient for our protocol to basically prove that you're spending real money and then with anonymously yeah so there's that there's I mean the elliptic curves that I designed the BLS 12:31 and

jeb job I didn't come up with a name job job either by the way that's also Dara Dara came with that name where'd they come from that's from a Lewis Carroll book of some kind one is one of them so it's one of those absurdist kind of things but yeah so if you if you had to like some like this is obvious a ton of work in cross you know ceremonies across fundamental cryptography and meant a new things engineering optimizing if you had to put like one theme or one focus of the type of work and the research that you do

well would you say that it is so I guess my focus is on ZK snarks and anything that it touches my focus is on taking academic ideas and implementing them and then improving on them performance wise yeah it's mostly that it's mostly it's mostly taking the the genius ideas of that are in papers and then trying to combine them in a way that actually ends up with a product it was really efficient I think that that's mostly what I do nice so we in our in our episode that we also did an episode Zuko I was our 50th episode and he in that episode we actually did talk about

like the details of the sapling upgrade and like the various things that had been implemented to make it a lot faster and would you say more succinct is that the right word in this um I wouldn't say voice succinct good fasters okay yeah so when people say succinct what you should think is at least four zero knowledge proof succinct means short and fast to verify so it should be asymptotically short so something like poly auger is maker there even constant for most snarks and it should also be asymptotically fast to verify so bugger is maker constant for most narcs to verify constant time with respect to the

underlying statement so that's what's the sentence we've been aware that the sapling update had a much broader trusted setup with a lot more people involved and I imagine it's more complicated I think it would be really cool to go into that like what what was the big change from the sprout trusted setup to this a clean one so there were a couple things the the sprout ceremony the reason why it only involves six people was be cuz if we for example we added a seventh person all the other six people would have to wait for that seventh person to do something which took hours and about an hour actually like three times so so

in that space of time they would have to sit with their computer and hug it while their computations are being performed or while computations aren't being performed and they're just waiting because some ninja might come and steal it or whatever and try to infiltrate the ceremony so they have to retain custody of their machine for this this long period of time in the case of the original sprout ceremony I think 24 hours continuous is how long it took to actually execute that ceremony that's just not practical what's really practical is you know for scaling purposes for involving lots of people is if people can just join contribute and then leave and the reason why

cryptographically the original ceremony couldn't support this was because you had to do for the security proof you had to commit to your secrets - to your - to this toxic waste so speak or this toxic waste by-product or whatever we call it you had to commit to that before the ceremony began so that you couldn't change your move that you're gonna make later on and this was just to make the cryptography work was clearly not necessary and so after after sprout I had I said screw this commitment this pre-commitment stage let's just get rid of it and find something else for powers

of tau and for the sapling MTC we figured it out that we could just do a randomness beacon and that was good enough but even if that failed I think it was securing the algebraic route model and then later on Mary Mallory and other people have figured out that oh you just use official and transforms and you get the security proof goes through that way just give a straight line of scare extractor so the important bit was getting rid of that commitment round but also the ceremony involved multiple phases so the original ceremony the sprout ceremony had three phases the first phase you create the powers of town so you're just in but you're

encoding some evaluation of different monomials and some unknown Tao into the elliptic curve group they need to a fast Fourier transform and then all of a sudden now you have the ability to create these interpolation polynomials in the group then you can create the correct interpolation polynomials and then you do another phase which sort of adds another several other unknowns in order to get the protocol to work exactly like the snark needs it and then you had to do another phase in the case of the the snark that we used for z cache originally but there was a new z case mark called cross 16 which are Drott 16 which was more efficient but

also you could compact it into two rounds very trivially and so you would have a single round set up that could scale forever which only dealt with the monomials the original the kind of the bottom layer it's kind of like at building a cake or something the bottom layer and anyone could use that as a basis to construct their parameters for their for their own ceremony so right now actually there's a rust library called phase 2 which anyone can use to create their own ZK snark public parameters with a multi-party computation using powers of tau as a basis I'm curious on like when it comes

actually implementing this how much of the work is split between the requirements of the snark and like the cryptography of that versus the MPC part of it like yeah like how much of the work is generating parameters because we always see like in Socrates for instance you can just download this you generate the parameters locally on your computer and it's totally insecure for public use but generating the parameters are actually pretty easy whereas it seems like ones you aren't to generate them securely in a multi-party conversation it becomes super complicated is that that because

of the multi-party computation or because scaling the like the parameter generation in this way is so complicated like it's complicated because the the multi-party computation itself is a logistical nightmare because you have to coordinate it you have to get people involved you have to implement it you have to make sure it's secure you have to multiple implementations maybe you have to do all these things but also and then the protocol itself is quite expensive but also there's a big difference between constructing the parameters and a multi-party computation and constructing them - kind of a solo setup that you do on your own machine and the difference is when you're doing

a solo setup you know all of the unknowns and so you can evaluate all the polynomials that those unknown that does unknown points very trivially and then just do a bunch of I mean they're expensive but you can do a bunch of multi-point exponentiations in the group and in the FPC you don't be every every person doesn't know every other person's secrets and so they have to each person needs to do that same process but with lots of different group elements and it becomes really expensive in that respect so that's that's why that's why doing an

MVC is really expensive so yeah so speaking of trusted set up so you said earlier that like it was part of your goal to make this easier and more approachable and serve better in general and it's down the line of other things that you have invented there's sonic which as far as I understand it aims to get rid of quote unquote the trusted set up even more you still have to do it but now it applies to multiple snarks you don't have to do an individual one for each snark is that a correct description yeah so one of the follies of our original it's folly the right

word I don't know and one of the one of the downside of one of the downsides of the original ceremony that we did is e-cash and then the following ceremony was that it was specific to Z cash so you couldn't just take those parameters and create your own snark for your own application if your circuit was different you had to create a new parameter you had to create new parameters in your own setup so what what people really want are universal parameters so someone else does the trusted setup and then everyone can use those parameters in their project and they don't have to perform their own ceremony I think that that would explode the usage of ZK snarks in the community but getting there is really challenging

so in last year in 2018 Yin's Groth and others mary malar and mark of Cole Weiss and other people that came up with a universal parameter ZK snark and this was really fascinating unfortunately was really inefficient the the parameters said the size of the parameters skilled quadratically with the size of the supported statements in terms of the number of multiplication gates in the arithmetic circuit so it's just totally inefficient so Masonic we're just trying to tackle that we're trying to come up with something that has a linear size parameter just like a normal ZK snart

that's updatable and and you get a you have snark in the end and so that's that's all it's Onix about and there's another facet to this which is great we have a universal parameters and anyone can use it it'd be nice if it could be updatable in the sense that someone can join contribute and improve the parameters security and be one of the few people who had contributed to its security then leave immediately and then people can do this forever so the ceremony basically never ends and in this case it can scale to a very large number of people and there's all sorts of settings or you

can imagine people contributing as part of the contract or you could or some requirement or whatever or people the ceremony can fork off when people can contribute in different ways or whatever which is really interesting and it leads to something I think is really fundamentally as six years you can get and it kind of comes naturally once you have universal parameters because at least for ZK snarks that your parameters are universal they're probably monomials and monomials are easily easily updatable inside of these setups so Sonic is a universal and updatable setup where the parameters are linear in size and you get a ZK Snarf's in the end you

you refer to Sonic there is a set up so it's is Sonic the only the trusted set up part of this or do you need like a different snark like I'm kind of curious where that lives is it is it sort of an overlap between a snark and the trusted set up or is it only to trust it set up it's blurry so Sonic is is a ZK snark we've kind of certain set up that happens to be linear in size and updatable in universal so but that that updatable in the universal part of the requirements of the snark is inherent to this is why we built Sonic we're trying to get a start which only required Universal not dateable parameters that were linear in size for those for those groups that have already been have

already implemented some form of snark that is maybe from a library what do they have to do to change that do they have to read redeploy the whole thing today can they use pieces of it so in general if you have a ZK snark that you've already used and you want to move to another ZK start you're you screwed you have to do in your setup or you have to change your protocol completely or anything need to change the elliptic curves kind of like you did so there's a lot of yeah it gets messy with Sonic so you sort of mentioned this upgradeable upgrade ability is that is that what you mean is that it we're like if you then had Sonic's would you be able to like

your snark a lot of people would need to scribe sonic to them they think oh it's updatable setup that means when I update the parameters I can all of a sudden they're more secure and then all the all the proofs that were constructed before I know that they were secured because I contributed it's not like that proofs are constructed using the parameters as they were at some point in time and if you update the parameters you were making them more secure but all the proofs that were constructed before do not leverage your contribution at all so update ability is really fundamentally about scaling the the process of constructing parameters so

that it can support hundreds of people and very high quality contributions I think the question is also when I updates can I change to a different circuits at the same time yeah so with with a you know because it's universal we release our sonic because it's Universal parameters then you can you can switch circuits anytime you want yes I like the upgrade ability aspect as well from the point of view just avoiding tinfoil hat people because if someone comes along and says no I don't trust these 400 people they all colluded that person can themselves enter into the ceremony at that point and do the job themselves and

trust that they didn't lie to themselves and therefore it's now more secure and they can trust this thing sure yeah exactly we keep I just realized we keep switching the word updatable and upgradable what is the right terminology available updatable okay it just confused people out there I I said it wrong the first time around so so from what I understand sonic kind of sonic grew out of what you would the work you had put in for the sapling upgrade you'd sort of already extended and added a lot more participants into that sort of second trust is set up and then I'm guessing out of that you realize oh we could do even more yeah so this new set up with with the sapling multi-party

computation of performed for constructing the parameters for sapling we had two phases one where you can see where you embed these monomials into the parameters and then one where you actually construct the polynomials and then you add another unknown and then you get your parameters what of what I wanted to get rid of was that second phase because either the phases can run indefinitely and and so you get that updatable effect you also get the universal effect if you get rid of the second phase that has the polynomials that are specific to your circuit so really the goal of Sonic was to and this was the goal of paper proceedings on it was to get rid of that

second phase and just have a ZK start to only required monomials for example that were embedded in the group so a lot of really clever people came up with techniques and we sort of just jammed them together to figure out how to I get it to to work so we actually had a few other questions from our listeners on this so we had one question from Georgia is constant topless who is asking if there are like further steps to improving the sonic protocol that you're working on right now I'm not while I'm trying you know not to work on it are you trying to I'm trying to work on it

I'm trying to come up with ideas and failing but there's a lot of other people that are coming up with really good ideas that are kind of orthogonal but they'll be able to improve Sonic one of the things I'm really excited about is okay so there are there are people trying to make sounding more efficient but then there's also a sharks z:k sharks which are these fun little snarks which are kind of like a bullet proof so it doesn't require strong assumptions and a set up and snark attached to it in a sense is I'm oversimplifying called sharks they're called sharks yes

that's amazing very deliberate - bullet proves and snarks become shark so so the snark that's attached in the bulletproof just proves that the bullet proof has been verified so instead of verifying the bullet proof which could be expensive you verify the snark and it's really efficient and if someone verifies the bullet proof are and if the verification fails and the snark verification succeeds then you know the trusted set up was a failure and so you can give that to someone say hey check it out the Senate failed so I think that this is really a and almost obviates trusted set ups for most applications I

can think of there's there's some applications where you still need snarks and you probably don't get anything from bullet proofs and also maybe the bulletproof part of is too efficient inefficient or whatever but I think that sharks are really really cool and I think people will want to see sharks using updatable own Universal parameters like sonic so there's sharks plus sonic so supersonic sharks so something you just touched on and a topic I definitely want to get to in this episode you just sort of mentioned this like with these sharks you can check you can check if

the trusted setup has failed or been compromised and this in a way kind of leads into a topic that you mentioned earlier in the episode but I think it would be really interesting to talk about and that is that bug is that the right way of saying that do you call it a bug oh it was it was a fundamental cryptographic mistake inside of a paper that precedes e-cash so I would call it the BC tv-14 bug or BC tv-14 mistake or whatever there this bug did it like it didn't really have anything to do with the trust is set up though did it like was the trust is set up that you did

was successful in a way like that that toxic-waste was not discovered right so the goal the trusted set up is to construct parameters for the ZK smart such that certain variables are unknown to anyone and they're destroyed forever well forever until a quantum computer shows up or something so I think we successfully achieved this unfortunately the paper that described the Z case Marik said you had to produce some other things as part of the parameters which actually weren't necessary for the prove it or the pervert didn't didn't need them to actually construct proofs and so we constructed them and then it ended up

being that they are actually not even it's worse than not necessary they they actually break the soundness of the proving system so we weren't aware of this I think if that mistake wasn't there then the ceremony would would be a success in the sense that it would produce secure parameters but I think the ceremony the first ceremony I'm sure was successful in producing parameters for a broken ZK snark but right wow so that's what it was it was more just like there was extra something extra produced which you didn't think would be in any way relevant and then was was the mistake that like that other extra stuff

could be used in some way yeah so I think we call the we call these things we call them bypass elements because we couldn't come up with anything better than that but there are these elements that are produced and exist in the parameters that allow you to bypass everything and just create a false proof arbitrarily and you could really think of the bypass elements as a as another trapdoor that you should have destroyed in addition to the existing trapdoors and initiative so you could call them toxic waste as well but I just call them bypass elements I guess would you need

would you have needed all of them like in the same way with the toxic way like was it only in the combination of all of it that it would be dangerous or was this like actually I was were these bypass elements something that actually came out at the end of it right there at the very end they appear in as part of the setup now it happened to be that the implementation of Lib snark deleted these elements because they weren't needed by the approver but it was defined as something that was constructed during the set up and so the NPC produced it and then deleted it because Lib snart provers needed these elements to be removed so the prover

would work correctly so the NPC that we did originally there was a transcript that contained these elements these bypass elements I'm speaking of at the very or in the middle of the transcript somewhere and these elements could be used to create false proofs so how did you guys discover this and what what happened after you discovered it what was the internal you know this is found and then you know what do you do so what happened was I was at financial cryptography this is a conference along with Arielle Gavin and zuko which is

really useful because having those two people at the same conference the same physical location when we discover such a critical bug was probably incredibly important to actually mitigating the bug correctly so I was at this conference and Arielle well sometimes message me and say hey I found a thing that seems weird about Zika is this broken no so no it's not because of this or that and then he told me about this bug that he had spotted in the paper and I was a little suspicious I wasn't I had to remember how this thing worked and so I

was like no doesn't mean this isn't all papers from 24 probably okay but I'll check it out I guess and I met him in person and confirmed that the bug is real so I I called Zuko up and I said hey you need to get back to the hotel as fast as you can it's an emergency and apparently he thought that I meant that someone had been kidnapped or something so he asked the hotel and asked bodyguards or something to come and check us out but but no I was just that there's a catch proving system was broken and people who'd counterfeit coins infinitely if

they had access to this this transcript that was produced in the original protocol so when Zuko came and met with us we decided to delete this transcript it was publicly available just deleted and then no one can there weren't very many people that downloaded it maybe like a dozen and so you delete it no one can exploit it I had a copy on my laptop which we eventually deleted but and in the process we come up with some way to actually fix the bug in Z cache covertly because if you tell everyone then who knows we didn't know that there was very few people who downloaded it or where it was or if it was archived so we were

worried if we went public with anything that someone would exploit it in Z cache before we could patch it so I came up with a way to patch it covertly in Z cache by using our new set up to the new set of for the sapling upgrade to actually replace the parameters for the old system that were broken and so we did this and we were able to do this hand of convincing so we won't didn't need to tell anyone besides us three and the and Nathan who's a CTO of Nathan Wilcox who's the CTO of electric one company we didn't

have to tell beyond us for about this issue the engineers our cryptographers of anyone because they had an explanation so to speak so we were able to patch it and once it was patched it was a matter of fixing it for all the other cryptocurrencies that were affected by it as well and the first like from Discovery to actually patch I mean it was quite a long time was that a time of just constant panic or what was the four of you that knew right what was the emotion there so I think maybe I aged 10 years during that one year well

okay so there's about eight months between discovery and patch I think it wasn't intending to be that long but there was a delay but having to keep such a bub secret which you know could lead to the destruction of the project that he worked so hard on was really really difficult so everyone everyone had serious emotional takeaways from that experience I think I personally I didn't get much done during 2018 because of I mean I was working on sapling and designing it and things like that I had done most of the sapling stuff that I contributed to in 2017 the

implementation and so in 2018 it was just about implementing things finishing the design work and doing the ceremonies and going through everything and making sure that there's not another bug or trying to make sure that there's not another bug in that in the code or something or in the crypto so that was a really yeah it was a really difficult time I remember it so as I underst the up the update or like the fix for this was part of the sapling I mean when when the sapling upgrade happened this issue was sort of like taken care of but I remember at Z con zero you guys were

doing this overwinter update or something it was like a part of the sapling like on the way towards the sapling update did you fix it then or did you fix it later so the the bug was discovered just prior to the overwinter upgrade literally like a week before it was deployed so or something like that so we didn't have a chance to actually deploy mitigation and overwinter the actual mitigation that we did deploy depended on the sapling upgrade it was a we kind of piggybacked on it in order to make it covert so that people wouldn't independently discover and exploit the bug so

so yeah so as part of the sapling upgrade over when our upgrade was mostly a logistical upgrade that was intended to improve the process of performing another upgrade back when we used to call them hard forks we called it hard fork zero but we don't call them hard Forks anymore in the Z cash community come network upgrades wise choice [Laughter] see um I just wanna like I imagine that people listening to this episode for the

most part especially if they've listened back to some previous episodes were explained a lot of you know about trusted setups and we you know when we talked about sort of the Z cash model in general like we we have covered what the bug exploit would mean but I think it would I sort of want to just say it here like what what would have happened if someone had actually gotten that that piece of information like what would they have needed to do to actually what you just described like mine in the shield it accounts so so what you can do with these bypass elements it breaks soundness of the proving system and so

you can construct false Proops so what can you do with that well you can create a bunch of money that doesn't exist and then take it out of this shielded pool and or keep it in the shielded pool if you want and use it to buy things like other currencies or whatever and rob every one of their money so it's very very dangerous if someone had access to this I think they wouldn't really rob right it's not that they would take out money from other shielded accounts they would just print more so there's no way to distinguish money that's been

counterfeited from money that isn't and so as a result in some sense well the first off by inflation year you are in some sense robbing value of from other people but in another sense because you can take all this money and then the counterfeiter is indistinguishable the the honest participants of the system look like potential counterfeiters and whose money is real you don't know so it's a it's a it's a big mess and the turnstile actually addresses most of this in that you can see how much how many tokens have moved from sprout to sapling and you have an

account of how many tokens have been created and so you know that if there aren't more tokens in sapling than have ever been created then things seem good the problem is that you don't know if someone is sitting on a huge stack of coins in sprouts just kind of waiting around like I don't know what they would do with those there but so there's old counterfeiters exchange their money that's what they do they and so is so if there's more if there's someone's counterfeiting it will be discovered because someone will have moved their money from spot to sapling at some point there was more money being moved and there should have been and so

you'll discover it you could also have a counterfeit or potentially who there's this turnstile that it doesn't detect like a counterfeit or that only creates a certain amount of counterfeit funds and only takes a certain a small amount of it out and exchanges it for another currency or whatever and it's that that amount happens to be less than the amount that is lost for example by all the participants in a network because people lose their private keys or are they just yeah whatever so you could you could totally do it undetected I think today actually I'm not really sure how

many coins are in the sprout chill did pool but I don't think it was ever exploited because I think any rational counterfeiter the for rational but evil counterfeiter would probably just take as much money as they could possibly sell at a time without being detected or something like that and it feels like they would try to move the tokens over to sapling it's like be the first to ever move it over and then sell it because like then that they have a longer time before they get detected or is this once the legit people you know who are slow and don't necessarily

follow our protocol developments start moving their coins over eventually some legit person moves their coins over and that the balance tips over but the the first guy the evil guy has already moved all their tokens and maybe sold them on me because the evil guy can make as many as they want I think to the rational thing to do for the evil guy is to literally counterfeit as soon as you discover the owner ability and are able to exploit it literally counterfeit as much money as you and possibly counterfeit and sell it as fast as the exchanges will allow you to do so without being detected and I that

didn't happen at all so I'm pretty convinced on top of some other reasons that no one ever independently discovered it and that no one ever exploited the vulnerability if this is so net just to be clear it sounds like there's still a sprout set up that exists in the world because as you mentioned this like a fork right so there still is sprout somewhere and then there's the sapling fork or update or upgrade but could somebody actually exploit this after the fact and somehow move it over like if somebody's still working in the sprout version and they like this has all been published it's out there now could they use this and in

any way affect the the new chain so not in Z cache that was the whole purpose of the the mitigation that was included in sapling was to prevent people from doing this entirely in other cryptocurrencies that still are based on sprout which there are very many but there's a couple then yes there is there's a way to exploit that to create counterfeit funds we tried to disclose too I mean you can't disclose to every one of these projects hey there's this bug you have to kind of pick and choose who you think is trustworthy enough to tell them hey there's a bug you have to fix it and so we chose a couple projects outside of Z cache and had them fix it as part of our disclosure process before we went public

in February but or whatever we went on yeah I think it's February but no but what I mean is you sort of mentioned this movement like you have to move your funds from sprout to sapling Frederick you said this the turnstile but sprout transactions are not valid anymore so you can like generate a sprout transaction today that okay yeah got it it's so by the way Sean this is really interesting and thank you so much for sharing this stuff with you because I can imagine it was quite traumatic so yeah I really thank you for for kind of coming on insurance it's nice kind of

therapeutic oh I'm glad to hear that cool actually that sort of leads me to the next question now that some time has passed though like what's your what's your takeaway looking back on this well it's sort of like you can always say like you have to work harder you have to look closer but like there is human error there is it is yeah I'm just curious like how do you like what what do you think of that I mean I won't I won't answer with all you have to look harder you have to whatever but I will answer with it this happened to be in the one spot where we didn't

reimplemented wery implemented almost everything of the academic prototype that was before us oh yeah although all that code for Z cash but the one thing that we didn't tackle was that this actual this spot of the ZK smart and so if we would have done that I think that we would have discovered it or switch to a different ZK stock or something like that but we were resource constrained and so it was just a matter of you know used it this this protocol was out for a couple years so somewhat trustworthy people had looked at it people had based other protocols on it that were also broken so which we didn't know but it

was just it was just a sad an unfortunate mistake I don't I don't know that you can't really address it much except adding more resources and more people to prevent it yeah speaking of re-implementing things and sort of on this line I mean we aperi are working together with the z cash foundation to write rusts implementation of z cash and while it's not reimplemented everything we're still using bellman but we've reimplemented Bitcoin since before what's your take on this sort of having multiple implementations and the foundation having one implementation and the company having one is this good or

bad or alike yeah I think what's our fill currencies having multiple implementations is great who very likely increased the chance that someone will discover a fatal bug and one of the implementations I think multiple employment implementations is generally good for almost I have everything that I can think of it's interesting to like that it comes back it's fine so in this interview earlier on we were just talking about this academic academic implementations and sort of the engineer implementations and as you described it was like every piece except for that that you hadn't redone or

whatever this was found in the one that wasn't redone and do you think that that maybe is the solution to have this is kind of going to your point Frederic that like just re-implementing just having people rewrite everything multiple times is sort of the the best way to assure safe it's one way obviously having verifiable verifiably correct code is another way but I think the the point I'm making is that the academic code was written to get a prototype out so that you could tell the journal or the conference that you're submitting your paper to that I have an implementation it wasn't I want to put a

billion dollars on top of this implementation being correct so going and we found other fatal bugs in the academic prototype of even in just the code also in the crypto but even in just the code which that we were replaced and so I think it's if you're gonna use academic prototypes you really need to just you need to master the crypto and you also need to completely destroy all the old code because academic prototypes are laced with with mistakes it's not because the academics are there's an I'm not trying to blame anyone it's just

that's the the academics are creating prototypes they're literally putting at the top of their read means do not use this code for the love of God you're going to you're going to screw everything up please don't down please so it's really we need to destroy all academic code before it ends up in production I think that that alone will help make things a little more efficient it's also nice to have more people tackling code so every time you reemployment something someone learns every facet of the code and so they can identify bugs and mistakes and stuff so there's a bit of both I guess another area of work that I'm very

interested in that you've worked on and it's be a list 12 381 the curve and the Jubjub curve and it sits on this boundary of engineering and and academia as well like I always thought it was a crypto researcher or somewhere sitting in their armchair designing this elliptic curve but here you are making them like what goes into designing and making an elliptic curve so I'm actually a little bit surprised that the austerity ones which is a pairing from the elliptic curve is actually has grown into this really popular elliptic curve for doing anything regarding elliptic curve

pairings originally we were just trying to come up with a curve that was more secure than the curve that we currently had because the curve it would current the the one that we had in sprout under some attack which isn't possible yet but theoretically in in the future if someone figures out a way to do it it would have a hundred bits of security or less than a hundred bit something like that we wanted to make a curve that was a little bit more efficient than that or sorry a little bit more secure than that without losing the efficiency and so we and so I just after the SAP sprout upgrade I just looked at the taxonomy of available curves and the different

design constraints and came up with one that kind of fit all the pieces that we needed and then at the same time building an elliptic curve that's embedded within it was not really much of a challenge it's just taking these academic ideas and applying everything and trying to make it really efficient and follow all the constraints not that it's not that hard for some reason people just don't do it I don't I don't understand them just don't be don't be afraid make your own elliptic curve go ahead would you describe what you just said there where it's like a curve in a curve is that recursive or is that a different um it's nested so essentially you have an elliptic curve like the LS

1231 which has a scalar field which is where you do all their your arithmetic circuit is built over the scalar field and you couldn't you can construct arbitrary curves on any field so you just construct another curve under on that field and I call it an embedded curve but I don't know what else to call it and then so that that curve will be judging I have to to questions from listener on this one is all actually from Jeff Burgess and I really only want to ask them because I think they hint at sort of how to think about this and how to work with curves like what the engineering effort that goes into it so

the two questions are when do we get hashing to this curve and when do we get constant time arithmetic in this curve so I've been working on an implementation of BLS 12 through 81 that has caused in time everything everything is kind of sometimes even the pairing which is not necessary usually so so that that's something I'm working on it's totally feasible hashing to the curve there was a new paper by Dan Binet and someone else where they had come up with a technique for doing fast hashing to the curve and so that's really exciting and I plan to learn how that works and implement it so it sits on a it's coming up in and be able to fell through 81

although it was designed for C cash originally it can be used by anything it can be used by projects that just want to have BLS signatures which are these really fast aggregate able signatures and and things like that so it's it's taken a life on its own I think a lot of projects that are now dealing with the sort of random beacon chains there are aiming to Abiola signatures in some regard and usually dealing with 12 three eight one and yeah and so it's sort of it sounds like it's a bit of these questions it's a bit of mix again

of like Dan Bunny and his research team are working on trying to figure out a way to do hashing while you're plugging away at the engineering things of getting constant time we had already implemented hashing to to be able to 12:31 that is theoretically constant time it's just not as efficient as Dan Benes paper we hadn't and and so it's been actually implemented it wasn't integrated into my implementation of Billa so through anyone but it was implanted in a couple others that have spawned off people have made their own implementations and so there was there was already hashing to the group it's just now that this new paper came out and it's much more efficient everyone should probably move to that

new thing before everyone starts using hashing in a specific way because ideally we'd like it to be pretty standardized and and so on yeah are you are you really involved in that standards talk like I know that there's a lot of people who are trying to get some ZK standards going yeah I was one of the moderators slash committee members of the ZK proofs workshop the first one in the second one and second one was just earlier this month in April so I guess part of the those stand I think it's a little too early to

standardize on certain things like elliptic curves because everyone needs a different elliptic curve the Syrians regrettably is using this old curve that G cache originally used because they just needed something so that they could they put it in because they wanted for our ability with Z cash and then Zeke has changed well I did try to warn them hey you should probably use BLS curves instead because of the security thing and everything else and we're gonna switch them in Z cache there's actually a couple of proposals on the table for the next upgrade to theme Ted there's there's a couple of different ones they want one generic

sort of pairing over any elliptic curve type of function and another one for I think could be lists well 381 yeah so so so it's really everyone seems to be picking up records for example bales 1231 isn't the end-all be-all because what if you want to do in a nested recursion of pairings or something like that well then you have to use the curves that were in sexy or what if you want to do indefinite recursion then you have to use this MNT for M into six cycle that's used in for example coda so everyone's gonna have a different curve probably with different trade-offs of

performance and security and features certain kinds and so it's really difficult right now to standardize on a curve but what the what we can standardize I guess on right now is language and techniques and things like that so we can we can come to an agreement of this is how you construct a curve rigidly to avoid backdoors or whatever other kind of possible things that you could screw around with explaining everything this is the term you use for for some particular topic and so on so that's currently what the standardization effort has been focused on there isn't much else to it

yet what do you think about trying to standardize the sort of on disk expression of circuits so that you can you can construct a circuit in some way and then plug in different provers to the same circuit as far as I understand right now your circuit is like completely specific to which you know the library you're using I'm personally there's a lot of people really interested in oh well bellman has a really fast implementation of shot ticket six I'll just use that and I'll implement my circuit and Socrates and then I'll connect them I think that this is my personal opinion is that this is really silly I think just to implement

sha-256 in your circuit language just do it and if you can't do it efficiently then you circulate which sucks or or you need to do something to improve it that's really just the there's no production software that I can see which uses Interop in that way that's both efficient and secure it's just it just seems like totally unnecessary to me so I I think it comes from this sort of you know we're used to having protobufs for wire specs and like no one has to deal with like specifying byte strings anymore it's just like oh you we use protobuf and then we don't have to think about it anymore I think people want the

same thing for circuitry it just seems like a different thing actually yeah I think that it explodes your surface area of fatal mistakes because you know if they think about it already where were clamoring for some kind of technique to do verifiable circuits so we're trying to see always this circuit a correct representation of the computation you start mixing languages and interrupts and everything else and need to play that in production how can you even justify that you really can't you have to you really just have to have some robust of centralized implementation of the circuit that's really in my opinion if you do anything else you just really you're building a prototype maybe and

then that's a that's okay maybe different projects they want to see if something's feasible then prototypes are cool but do you need to standardize in order to get prototypes no I don't think so at all so yeah whatever yeah I actually I did I have one little question on who wrote bellman IRA bill no way cool I that would that was literally like it was it was bellman was I started it in like 2014 really I was trying to influence narcs and rust and it took years but eventually I was able

to do it and get get it into Z cash it started out as a dumb ins purpose originally was to try to build a toolkit for building circuits securely because the way that you currently consider that the way that at the time that you constructed circuits was really error prone I had seen bugs in the academic code and Z cash how you could screw up and I had looked at the interfaces and I didn't like them so I wanted to create something that was a little less error-prone in those respects and there's in the respects that I was aware of so I wrote bellman originally to try to address those four circuit synthesis and I ended

up being just a general toolkit for building performing ZK starts and it's used today and ZK actually somebody asked Toby asked us if there were other missing tools that you felt were needed like you so you as you just described you started bellman in order sort of as a tool set as a toolkit right so I think bellman in the future is going to end up just being a library with some gadgets in it for constructing circuits but currently it does that plus it's also a ZK start proof generator and so on I don't want it to be that that's too specific so I'm gonna move all this

stuff out and did different crates but as far as what new tools need to be constructed I think it nice to see Adam attic so in some of these in some of these protocols like for example graph 16 or this new sonic protocol we work we can work within the algebraic group model which is a security model where you assume in here adversary is algebraic so they can only so every time they produce a group element they also produce its representation or you can extract it and in this model it seems like we can write formal proofs formally verified proofs

of of the zk snarks so I'd really love to see automatic generators of these proofs or verifiers of these proofs maybe not even just an algebraic group model you can also do generic group model it's just a little bit looser but automatic generators of these kind of proofs would have helped us write secure designs of new zk snarks then then as far as applications go obviously having new dsls for writing ZK snark circuits would be really nice I'm really unsatisfied with the current set of dsls I don't I think they're really both my

library and every other library and I don't think anyone's figured it out yet so I think that's a challenge that's probably gonna take if arithmetic circuits are still integral in 10 years which I think they probably will be they'll probably take a decade to actually figure out how to design ZK starts in a really verifiable and clean way so before we wrap up this episode we have to wrap up at some points let's dig into a little bit of like future stuff we have some questions left from listeners as well but I'm curious to hear what your take on Starks this in particular because that that is like the buzz of you know Starks will replace

snarks because they don't have to have this trusted set up and still have all the nice properties time that sort out no one really knows yet but what do you think about it I I think Starks are really awesome and all these other proving systems that are surrounding him I'm not I haven't been living in symmetric land for four years now so I don't know what the hell they're doing but they're really interesting and they keep making them more efficient I think snarks will always be the cream of the crop in terms of performance until until they can't even be used anymore because quantum computers or whatever shows up and breaks everything

so I'm kind of right now I'm living in denial that that will ever happen and trying to enjoy the pairing friendly world that I live in so I don't really know much about those things I'm really interested in other smart proving systems I think in terms of future things for snarks I'm really interested in new proving systems like sharks li explained earlier and then also improvements that can combine sharks and Sonic maybe but also parameters that are small so we we have ZK snart's where the parameters are linear and with respect

to the circuit size I would love to see a ZK snark with parameters that are logarithmic or something or constant with respect to the circuit size that would be really amazing because that would make the process of updating parameters really efficient so that's something that I'm hoping that someone will figure out in the next year or two probably won't be me but maybe someone I've been trying but there are Hopwood your colleague actually asked on Twitter besides the systems you're involved in developing yourself what developments in zk pro systems are you most excited about but maybe we take the twist of

like things that exist not things that could exist what are you most excited about things that exist well I guess seeing recursive snarks deployed in Kota will be really fun Kota Mike the second project in production that deploys was general-purpose zero-knowledge prints so that's that's really fun seeing more projects actually do NPCs would be really cool because it would lead probably two or more reimplementation of the protocol for the NPC and so you'd have more robust software and people come up with cool ways to to perform them but yeah those

are those are the ones that those are the things that I'm particularly excited about besides future things that don't exist yet after these years of working in the space do you still are you still getting like that thrill from when these things work or discovering these things so originally I fell in love with snarks because they're just magical and they really are bad the fact that you can have a proof that's a couple hundred bytes in size and it can verify a computation that is enormous within a millisecond is it's incredible eventually I get a little bored with that and I want to go a little bit

further and and now I think things are exponentially increasing in terms of the productivity of the crypto community so we have new papers coming out every every so every like month or so that completely blow everything up away for example with Sonic I'm a little scared to do a sonic MPC like a universal updatable sonic MPC because I fear that in like a month or two someone will release a paper that blows it away in performance so it's really just increasing it's just it's out of control in it I don't know what to do so maybe I'll maybe I'll start sitting back and waiting for everyone to figure it out before I start contributing or something ever I think we're kind of at

the end here Ariel Gabby's on Diddley one last question which is like what is EB foaming you're a Twitter handle I don't know if you you want to answer that I really don't want to answer that it's a silly story there's a there I had I don't know why I had a piggy bank that was name II when I was younger and I needed to pick a username so I said you will be full and then I turned it to e be full I don't know but that's actually great cool nice so that was so nice chatting with you about all of this yeah it was a really handsome to talk about

this stuff we'd love to have you on again sometime on maybe a deep dive in one of these topics as they develop so yeah they're always welcome on the zero knowledge podcast so yeah thanks again thank you and to our listeners thanks for listening thanks for listening