ZKPodcast: Alistair and Jeff from Web3 on ZKPs & more

Transcript

[Music] welcome to zero knowledge a podcast where we talk about the latest in zero knowledge research and the decentralized web the show is hosted by me Anna and me Fredrik this week we catch up with Jeff and Al from the web 3 foundation to find out more about the work they're doing on polkadot and how they are thinking of using Xero and ultra proofs in this system but before we start in we want to say thank you to this week's sponsor trail Abbott's trail of bits has developed from Manticore a simple

open-source dynamic binary analysis tool that takes advantage of symbolic execution Manticore helps you reason about code tests security properties and generate exploits with very little knowledge of a contracts inner workings recently the e NS contract or the etherium named service contract suffered from a critical bug that prompted a security advisory and a migration to a new contract ens allows users to associate online resources with human readable names this bug would have allowed an attacker to gain control of domain names that they no longer own so as an experiment the trail of bits team wanted to test if Manticore would have

discovered this bug using this tool in just a few minutes Manticore found two ways of expropriating back the sub node and therefore exploiting this vulnerability even though details of the vulnerability were originally unknown Manticore made it trivial to discover them this experiment was documented in the latest blog post on the trail of its blog you can check it out at blog trail of its com I've also added the link in the show notes there you can find out about Manticore and other work from trilobites so thank you again trail of bits and now here's our interview with Jeff and L so this week we are sitting down with Alastair and Jeff from the web 3

foundation welcome to the show guys all right and of course we have Frederik hello so this interview I mean we've just as some background we have actually talked about polka dot and parody quite a bit on the show given that Fredrik is a an employee of that company we have had Gavin talking about polka dot we've had Rob talking about polka dot and our chains as well I think we've talked about like the roles in polkadot a lot of that has been covered or what I think we could do for this episode is we can definitely start to explore like the research side of it and what I'm really curious about is to like find out one like what you guys are excited about in

terms of new techniques or new technologies and also how zero knowledge proof could be incorporated into the polka dot system we had an episode really recently with Chris goes from cosmos where we talked about zero knowledge proof sin the context of interoperability and I'd really like to see what that looks like in the polka dot contacts so yeah let's get started so I think it would be really great for audience to get to know you guys a little bit why don't you start by just introducing yourselves right I'm Alastair I'm a theoretical computer scientist by trade and I'm now working on the research on polka dot on just about everything security and I'm Jeff Burgess I once upon a time I was a pure mathematician

but I kind of retooled to be a cryptographer while working at a distributed systems group and I am I do sort of any part of the system that touches cryptography I'm heavily involved with I guess I would say I'm kind of an applied cryptographer so yeah I'm doing the things involving protocol design a lot of it so actually I have this question I don't think I've ever asked anyone on the podcast this before but go back 10 years 2010 what were you doing I guess I was doing I think I was to try and I think I was figuring out that I needed to quit working on simple groups to find out more than rank Y classification projects are not a good

career move okay sure classification projects do math they're not a good career move that I'd recently come back to University to do a master's in computer science I think it's just finished my masters in soft a PhD that yeah was it were you playing Civ for at the time it was mostly in okay Alan I have talked about this previously how we both are so we received four fan that was 2006 yeah exactly we lost too much of our lives to that game but it was fun okay so ten years ago that's where you guys were what happened in those 10 years that would have gotten you to this place maybe if you can pick like three for big events or big ideas that switched you

over I mean a lot of why I ended up here is I so I started working for this distributed systems group because I was making pull requests to this secure messaging program pond which kind of was at the time the only there were two sort of secure messaging programs that had a reasonable metadata privacy story and it was the only one that could be better than tor and so I started working for this distributed systems group and figured with the idea of doing something more serious there more scalable than pong and we settled on the idea of doing a mixed network and at some point that loop that Gramm we were making some progress on that but doing lots of other things did the crypto for this find signature payment system called taller

and the security person things like this anyway we that systems were that group sort of dissolved before the mix net stuff was really done and I met Peter and Rob at a bar in Zurich they were talking about some kind of broadcast system for secure messaging and I was explaining why this doesn't protect metadata at all and and then Peter decided he wanted to hire me so I was actually hired to do mix Nets but we needed a lot of crypto for polka dots so I mostly been doing that and that was Rob Havemeyer from parity and Peter Chavan from the web three Foundation got it that was your entry point yeah we just met them at a bit more restaurant and bar doing at a bar basically about cryptography well in my case it said a friend of mine got into a

theory earlier when I was still sort of finishing my PhD I sort of think about bit with the etherion people worked a bit on proof of stake but this point I was still in academia and in fact it was a sort of an accident it was there was a visa situation and I was going to be three months without the job and I said okay can I come over and I did up staying for two years this is going over too poka tivat yes okay so this podcast has taken a bit of a turn over the course of time and you know been more and more focused on their knowledge proofs really and I'm curious to hear from you guys like when was the first time that you heard about ZK stuff see he approves what was that to you at the time you

know did you have the typical like oh this is just moon meth I'll ignore it kind of reaction or was it just oh this is a cool thing or or you already aware of it from your academic pests I was aware of it from I was aware of in some sense from academic past I remember it clearly the first time I saw doing hash functions inside the zero knowledge proof thing then that Z cache was doing doing the Merkel who were doing actual Merkel proofs inside a snark that then I was like holy now one of the things so slow this is when it was like two minutes to do a proof well yeah no I didn't really wasn't really aware of these in some sort of two years ago and then you know since I worked at the idea this is magic yeah no this is not I have

to run away this is move map this is magic I should look how does this work what can this be useful and and why does it work and so I read up and got in this right not really being a cryptographer and I think I understand them now what was that process like to to learn them like how did you get in what was your approach my case just dive into the papers and it already had some background in doing crazy things with polynomials so unlike most of cryptography this actually made sense to me would you say like your knowledge of zero knowledge proof sand that kind of stuff is that your your cryptography understanding or do you feel like there's other parts of cryptography you've also explored yeah I'd try to read up on elliptic curves trying to

play about trying to understand pH you me I think it sounds like more interesting that people think definitely do you think there's more to it than people are well I think people just now they have this system you know they have this random Oracle model which you can prove things work but it's still not clear to me that you know if you have a hole in your you're provable security you should really be trying to attack it and I'm not sure that people really I think we've given up trying to attack it probably because a sensible security procedures people can follow but they didn't really argue that they are following them so one of the field I was sort of primarily a group theorist when I was a peer mathematician but I was also doing model theory and coming from that whole world like there's tons

of stuff that is used in that world that is vaguely like the random Oracle model or generic group model or whatever and many of those people would be very entertained by this stuff but they somehow don't know like it's very easy in these fields to not know where things go a bit deeper in some other field of math like what even though you're a mathematician you may not know something but like you may not know where the kind of interesting corners are somewhere else do you feel like in the work you do kind of doing research at web 3 you're you're forced to go into those corners like is that what you get to do so the random Oracle model comes up in the context of blockchains in some interesting ways which I don't think we're gonna go into right now but we do worry about those so those particular

things not too much but sometimes you you kind of should think you should keep a clear head about those things here's what I would say yeah we do worry about sort of where randomness comes from so in general in the context of blockchains you you want some randomness at some point in time and for most of cryptography you can you can sort of say we'll have a good system random number generator or D randomize something and those all those questions become much more intense in the blockchain problems so you talk to Justin a bit about that we did yeah yeah we poke it up you have a shape similar so it's yeah a typical thing that comes up and I think is that is pretty significant is so you you ban it we from this come kind of execute bot function we ban randomness and

especially in the context of poccadot where we can't control the execute block function that people are putting on there pair of chain we should we ban randomness and secrets but actually you can't do that completely because batch verification functions need it and they need the system randomness a lot of times so you you either have to make a more subtle argument that you can use some viatra mere things there or you just have to say that we're going to put this on the system side and we know it's safe to call this because it's neglige the chance of it failing is negligible and but then it's not something they can code into their own execute block function has to be a all out to substrate I want to go a little bit more into that but just before we do that I want to do a little

bit more on the kind of background like who you guys are and stuff like that going back to your role at web 3 foundation what does it mean for you to be a researcher what kind of tools material do you need to explore to be a researcher at web 3 foundation so a lot of the things I actually do it yet designing protocols and so for instance things like zero knowledge proof sip a detailed understanding isn't required for that but I mean the other function we research is just to work out what everyone's doing and whether it's going to be relevant for the future right we need to know because there's lots of places where zero knowledge could be used in polka-dot we need to know is it going to be feasible or not even if it doesn't end up being used hmm does that

just mean like do you have to do simulations do you have to like work through these things like what I'm just know it's not a simulation basically about calculation once you looked at what's really going on okay it's a question of whether it will ever be you you know whether we'll ever be usable in this particular way in this particular corner things like this do you end up having to interface a lot with the devs a bit yeah are there actually other developers are web 3 - it's only the only things we really code at web 3 our script o primitives okay actually there is some simulation code of a different more abstract sort every once in a while for choosing numerical parameters and almost anybody and the research team has has written some of that sometimes I will do or somebody will do a proof of

concept implementation that then the parity tabs look at to understand what something does but it's more usually and in terms of production codes so Sergey and I do some crypto primitives and we have a couple other people coming on who will be involved in that who's Sergei he's involved in snarks without doing snark circuits with us so he's able to maintain zero and all these things and then you're looking into that what's his last name Missy Liev okay so I think this is some nice background to understand like where you guys come from what you guys work on so let's jump in a little bit on what the actual research and what kind of outcomes you guys are seeing right now I want to go back Jeff to what you were just talking about where you talked about like

something banning randomness and I don't actually understand what you mean by that so it's it's it's just simply that you don't want you you don't want any code that runs in an execute block function to to cause a fork in the chain you don't want you don't want to have to or some portion of the validate you know you don't want 95% of the validators to say the block is valid and 5% to say it's invalid okay and we know randomness here the way power change work we need this to be Minister yeah otherwise fishermen and things it starts breaking down people wrong things it's accepting this is a general blockchain problem as well right like the no blockchain can have non determinism and sort of still still come

to like if you if you have a consensus system you want people to come to some consensus on something if personally computes a function and returns one and person B computes a function returns to how are they supposed to come to consensus on what the result is you know it conceivably a system where there's no slashing and whatever is more to be more tolerant to that but also just because you need to have you know you what you can't have is a is a non negligible chance of it if the if the chance of it happening is you know 2 to the minus 128 that's fine this is funny cuz like okay so we have done an episode just on randomness and the desire to generate

perfect like the not perfect randomness that like very very good randomness and in this case we're talking about like you don't want randomness yes but you also want very commonly you do want randomness in the sense that she wasn't known just recently so you want randomness and deterministic you want so you want determinism usually once you want is some kind of there to be some sort of commit process where somebody has people have committed to something and then some randomness some random decision happens that that then becomes a real struggle what part are you talking about right now which Huizar general comments so everything from everything go the way we do motions that's random okay where we've chooses making blocks the pair of chain the way

we choose the the outcome yeah the outcome Oh elections and just verifying some photography so that's a lot of places we have to use randomness and they has spent you've discussed before there's different requirements in terms of how soon you've seen this how much influence people can have over it yeah and some points we should just be using hm a heuristic but that's can be tricky what would you say right now is the most like in this in the system that you're building what are some of the most exciting kind of areas that you're really focused on so one of the course I mean well okay so one extremely important part of poccadot is the is just the fact that the pair of chains

are using y's um and you can have this fairly general stings running on the pair of chants and that's it that's extremely nice and quite important that you can sort of bring wheel dev tools to the table to use it the other thing is the shared security and this and that we have and a fairly complicated protocol that we have is this scheme for sort of how we validate pair of chain blocks and this includes quite a nice trick that we think gives us a lot more a lot more efficiency and scalability over over what aetherium to or business corn or the other charting designs do so we all we need to do is to make sure that the blocks and the prior chains have are available the data is available and that

they're valid for a single chain is not a problem because the same people that decide you know so if you for a Bitcoin and you've not been 51% it then if no one sees your block and it's not valid or it's not valid people aren't gonna build on it and so it never becomes final but in a sharded system the people will get to decide is it is did this happen they don't necessarily all but only a few of them can have this data and so how do we make sure for instance it doesn't get missing or it or it's invalid for the availability that there's a the trick which actually means that it is the people who design the consensus that guarantee the availability and the way you do that is with the radio coding pressure coding yeah we add some redundancy we hand

these out and then we make it so that you know and it the majority can have reconstruct what is the rager so it's you have a string of data and you encode it so that with you make it larger so that the you can recover from some subset of the data you can cover the full data this is how like broadcasts over any kind of wire or radio or anything actually work is they have some ability to correct for mistakes how English works like you know and I like that metaphor me yeah so just to explain try and explain this trick a bit more in these protocols like aetherium to or biscone or whatever you you use some some source of randomness

to choose or you know some on chain source of randomness to choose the nodes that will validate a particular shard and then you just trust them and the problem with this approach is that the adversary they know before they make the block then you you allocate these groups and they know before that you make the block who the group is they can see if they can Doss somebody before even making the block they can try all kinds of things and then if they can get an invalid block and they win so what we do is this we still have this initial allocation to para chains but these guys aren't really the source of validity for the block they their claim that the block is correct just puts their stake on the line so it switches from

something where nobody really has any work conceivably nobody you know whether the adversary kind of knows in advance everything that's happening now they put their stake on the line and there will be some other checkers coming later and the point is that we can use V RFS to decide later who these guys are and the address since each of these V RFS is local to a particular validator there's no way the adversary can know who all has the right to check that block so then it becomes a matter of knowing this so yeah what's a vrf verifiable random function so it's you know what okay so we're so used to I I was like maybe he said it wrong did he mean PDF you know

it's V are actually much more fun to be DF certain I story VDP are FS are funded using block production and everywhere so more or less it's a it's a deterministic signature that we treat as random Oracle so it's sort of private randomness that I know and no one else knows until I tell them but when I do tell them they know that I didn't make this stuff up I had to follow this procedure you can use them to basically limit get have somebody have randomness that they can prove they used the right randomness and they only have one choice in that random value or ten choices or however many choices you want them to have so the availability validity the sort of aim here is to sort of escalate the economic security to more or less like all the dots and polka

dot whereas if you have just the guys on one chain that's some 100 and you can sort of naively do this with with fishermen if you assume they exist right yeah I'm sure he talks about this usage of red polka dot a lot but that design didn't deal with the the availability problem that maybe people would collude and then withhold all the information for ever and then we're now we can't prove is incorrect because we don't even know it and the arranger coding fix that a bit and secondly we need to detect it in time and this this requires buy-in time even like in a decent amount of time like so that exactly what we do I file a nourishment ideally is we wouldn't finalize anything until we had it already had a good good under some

assumptions assuming that it's probably correct so does some extent this availability and the this this erasure coating availability system that that's in polka dot you can you might regard it as kind of this thing that is the one non ZK proposal that is competing with all the ZK roll-up proposals and a lot of our interests in the ZK roll out proposals and things is sort of to what extent is polka dots existing approach actually going to be challenged by these things and and what we're discovering is that actually a lot of these erasure coding and shipping things out ideas actually do seem to be useful to in conjunction with ZK stuff and we're not

ready to talk about any of that right now it's all very like pie in the sky and we we're too busy with other things to work it out at the moment but there's interesting there's interesting directions there and yeah right in principle succinct proofs would solve validity we have a very complicated protocol for validity and if we could have sink proof for everything that would go away but we'd still have the availability problem so we need to come up with a solution to that first I mean it's nice knowing things are correct but if you can't if no one can get hold of them then you know this thing is correct but no one else can it just stops no one else can build on it we know no one was stolen anyone else's money but it's not very useful I kind of want to go back to what

you were saying before with the V RFS and like what they were used so a fundamental construction in in cryptography that we use absolutely everywhere is what's called a PRF so chance or pseudo-random function pseudo-random function so there's always this problem of what do you mean what is it what is randomness mean what does it mean for something to be random so what a pseudo-random function is is the definition is that there's some family of functions began and the claim is that you can't if you pick a a member of this family at random you can't tell it from a truly random function and what a vrf the definition is that it's a PRF where but it's parameter the family instead of

just being parameterised by some string it's parameterised now by a public/private key pair and so you can check it with the public key so that's what what it means to be a random function is that there's something you know there's a function you can't tell which member of the family it is without seeing the knowing this the secret that proves it's that member of the family so that's what it means to be both a function and random is that you don't know which function is being used and what the vrf is is that you can't actually compute the output of the function in your shell yourself if all you have is the public key you can only check it when the other guy gives you the proof that either it correctly okay

but I want to go back to how it's actually used so what you're saying was actually like the emprender I'm trying to go back to it it's hard for me to remember exactly how you said it it was like it's it's the the the this is like in the pair of chain context you're using a vrf to show that like this is like you kind of put it in the context of like for verification for verification that this thing is correct without a fisherman so how we use it both here and in block production which you might end up talking about later is it's a way of randomly self selecting yourself you want to select people at random but what it's my turn yeah what it's my turn BRF yeah let's you say randomly selects I'm on it but no one

else knows whoo-hoo you know everyone randomly selects themselves and they can prove to everyone else that they were correct in doing this but no one else knows that they're going to do it before they do it and that in a way as of protection from collusion like the idea that they would I don't know who's gonna check our block though they're things that are a bit more they it's much more risky to try and sneak an invalid blocking yeah getting in volleyball ready requires a lot of people to collude yeah we have four different criteria for self selecting yourself for being one of these secondary checkers but the the primary one is simply there's a real aging block it includes a bunch of pair of chain blocks and everybody all the validators take the relay chain take

something from the real agent block two of the conditions look like this they say the relation blocks on vrf or they take the relay check lock hash and they run it through their own vrf and then just look at that mod that the pair of chains listed in the relay chain block and they said okay that's the one I check and so this means they're all assigned to one of them and there's no there's no way in advance since you can't know that each each validators vrs in advance there's no way to know who will check and it's not just that that's the one that they check and if they can't get it then they're done is that they have a right to check it and if they can't get it if they don't approve it then the network will respond in some you know if they say I want to check it

and and I can't then the network will respond and ask even more people to check that's basically this scheme this is like a way just to find bad actors that's like no it's a way to protect it's a it doesn't really identify bad actors you know does it they try and well yeah it's yes but it's not so much about identifying bad actors so it does matter that some economic security right it limits the bad actors so if you there's some power chain validate to sign off on this and maybe they're there read one in a hundredth of the stake of the entire system right we want to sort of escalate that so if we can catch these guys with probability 99% then sort of an expectation it takes them to take all

your dots to attack a Peres chain all the dots in the system it's going to be as cheap to attack to buy a third of dots and try and attack the real a chain consensus is is going to be to try and tackle parity that's what that's what you want and that's what we should have mean by shared security it's expensive to attack even a single power chain and so we need this sort of we're going to catch you with 99% probability preferably before we even finalize something but certainly before you can tell the Bitcoin bridge or something to give me Bitcoin or interact with the outside world right so there's some sort of horizon bone which we can't river anything easily and you might have got away with it we want to catch you

probably catch it before you get away with it we can't make this sort of astronomically small but we can make it such that it never going to be worth it to attack system got it before we dig into some more specific polka dot protocols and and like actually talking about what we use and and how it works there's a couple of things that come up on the podcast that I'm curious to hear your thoughts on how you think about maybe could they be used in polka dot or or not or like generally how you see them play into this space so some of those things are things like multi-party computation or fully homomorphic encryption or VD F's you know we've sort of mentioned in the past that vdf SAR on the radar for a polka dot but in what

way so generally how do you think about these techniques there's a very nice tweet by Dan Bernstein that essentially argues that there can't really be of meaningful notion of security for V DFS they still add something so we'll probably still use them one eventually that just yeah I'm not going to explain in his tweet yeah it involves something called a residue number system but the problem with V DFS is that there's we're talking about an enormous amount of money of capital outlay to do this thing in hardware and be confident that it's really hard to make the thing faster so I'm reluctant to say that we should spend all that money on that until we actually are pretty confident in what in

what we really want to do and there's essentially like there's two proof designs for groups of under an order and that that distinction is not so important maybe but there's there's two different groups of unknown order choices right now there's the RSA group which has an incredibly shitty trust it's set up and there's the class group thing which is a lot of nice properties and but it's not well analyzed enough if we're just gonna stick of EDF in right now I would say to go with the class Group one and it won't provide us all that much security but we'll provide something in the longer term the scheme that I like a lot is this Asajj needs base vdf by luca DeFeo and people that the right way to think of it is that the

vdf itself is computing a BLS signature where the secret key is the public is the the ice ogyny that's publicly known but just computing this is is the proof that you've done it and so the verification equation looks like a Payless signature and if you take the BLS signature equation and just turn it into the identity based encryption equation by sticking in two scalars so you start your vdf and then as soon as it starts running people can start encrypting to the output of the vdf which gives you this wonderful way to do all kinds of voting and stuff in a really simple way it's extremely meaningful to everything that people like and to stuff that the blockchain world likes in it will greatly simplify

the protocols so that's one reason why I think the Asajj anyone should be a serious contender and another thing is that there's a lot of things about the math that is a bit more easy to nail down so with an RSA composite the modulus you're working by is this thing you picked in a trust it's set up with a class group vdf well there's two ways to do it but in one of the ways the class group that you're working it you hash to a class group so the group you're working in is changing all the time and with this one you're doing arithmetic over a fixed field that was picked when you standardize the vdf of our fixed finite field of like you know maybe 50 you know fifteen hundred bits or something and

that means that you can really nail down your the the way you do all of the finite field arithmetic for that field so while the circuit complexity is massive compared to an RSA vdf you know you can maybe actually analyze the complexity of like how much faster can I do this in particular you can pick the residue number system that you're working in and with an RSA vdf you wouldn't know that somebody's not gonna that dan dan Bernstein's thing is gonna kick in and somebody can always pick a faster one words with the with the Asajj knees when you can maybe pick a sweet spot the other thing is is I'm not sure that the circuit being huge

is a disadvantage because if we really get into an ASIC war on these things then that's kind of sucks but if we can make the circuit big enough so that it we did we just were just happy with using FPGA s if that's even possible then that's great so if you can just make the circuit big enough that nobody ever wants to put it on an ASIC and but but it'll run on FPGAs then go for it mmm everything you've just talked about is kind of this I saw Jeannie's vdf yeah we actually did an episode with Luka on ice dodging ease so if people want to find out more they should listen to that what you just said though it left me with a question you just said that the I saw genève EDF versus the RSA vdf the RSA one requires this truss to set up

the ice dodging each replaces that in a way so there so Janine you you pick a field you pick a field and pick a curve on it much like you do with other things and then you like you pick a starting curve there is actually a trusted set up for the Asajj anyone but it's just us you know people wander up and say I'm gonna add it on the new I saw I'm gonna you know stick on a new ice ogyny and then people just keep running this for a while until you end up at some curve that you don't know how to get back to the curvature invariant zero so is it updatable in it is updatable yeah just like yeah that I like but updating it is a little slow you've got to recompute the video the the vdf it set self every time you update it but it is

obtainable sort of interesting what about those other techniques that Frederick just mentioned sort of are you guys also playing with NPCs or SPG's you see it would be so we're not using them for anything critical at the part of polkadots infrastructure are not using em pcs in anything critical okay and the problem this difficulty with making it all robust right you can verify this is MBC's you verified that they they work but what happens when they don't work yeah the other thing is yes so there's a problem with what happens when they don't work the other thing is is that so just from a like applied cryptographer point of view where what you worry about is one of the things like good applied cryptographers worry about is are people gonna miss use my code and with NPCs it's a like you need to use this

thing called session types even for like the simplest NPC that the blockchain world is really interested in which is like multi signatures I think the light the snorkel library I wrote is the only one I've seen I've not really been looking at all the C libraries out there but it's the only one I've seen that actually attempts to prevent devs from misusing the protocol and of all the the MPC libraries out there like the more general NPC libraries based on just conversation if you work in that area generally don't enforce this stuff so NPCs have a like they have years and years to go even the sort of development of misuse resistance techniques which partly exist but the devs need to start

using them and like basically nothing out there is misuse resistant we can't put it in front of normal devs and have it be safe so and basically what you're saying is that while theoretically sound and and you know attractive from that point of view the engineering challenge to actually get it to work and work robustly and reliably is too hard nor like you're not mature it'll work eventually I mean people will pens and figures start figuring out a lot of more the stuff eventually but I think we're talking a decade realistically and what about eiffage jeez yeah that's too slow are you paying attention to what kind of work has been happy around there's I know I shouldn't say that I I haven't followed it recently but that is a very that's a common answer I hear but I I

could I could be wrong we have actually we did one episode where we touched on FA cheese I think with tucks from new cypher but we should probably hear more than me but in general and maybe I just don't understand the primitive well enough but I often have a hard time understanding what I'm gonna do with them but that's maybe my own shortcoming I don't know what are your thoughts on encryption yeah so unchain our computing capacity is limited and off chain why would you do it it makes sort of sense if you're trying to pay someone to do computation for you but that's not how the economics works in in blockchain mostly it's cheap to do computation yourself and very expensive to do it on the blockchain there's another answer to this I think that's

relevant so with any of these cryptographic primitives if your question is should I be using them or not an extremely important paper in this space that you should look at is this thing by Phillip Braga way the moral character of cryptographic work if you can never have wrong way on the show you should absolutely do so the man is absolutely wonderful but it talks about sort of you have to think about how would this primitive be used and and fhe is part of what I mean what people one of the reasons why why FA G is so popular is this the fact that there's a lot of companies making a lot of money on doing cloud computing but actually what computers are cheap why do cloud computing just do it on your own machine if it's not that bad you know and and

since F H es flow up the CIM you know the computational cost so there's always this question with these things is why outsource this computation and the good answer is because we actually want some MPC we actually have a bunch of mutually distrusting parties and they want to collaboratively compute something but that falls into the MPC problem I was talking about and sure eventually it'll work hmm can you tell me the name of that paper again the moral character of cryptographic work but he you know he talks a lot about what you know you should think about like certain things like identity based encryption is just a bad idea another one that jumps out to me so a lot of people are interested in these CL signatures and signatures where

you can omit part of the signature because they want to use them in an identity system and an identity system shouldn't identify the people it shouldn't tell the age it shouldn't tell that you're male or female or that you live in Berlin it should tell you that you don't have a second identity on that service and nothing else so all these people doing identity on the blockchain stuff that want their CL signatures and Lola Lola it's it's ridiculous I'm trying to think if there's any are there any other sort of topics or techniques that we should quickly touch on because we next up I want to dive into like privacy on polka dot and zero knowledge proof some polka dot further any other kind of like background techniques that you are thinking about working on that I haven't mentioned or that we haven't talked

about yet techniques like future mere techniques like I don't I'm calling them techniques cuz I don't know what they're are exactly like NPCs like way to applied we uh need yeah the answer is is that we're we're trying not to use the grid cryptographers try not to use the stuff that's going to be kind of a pain in the neck so the nice thing about snarks is they're actually really orthogonal from the rest of the system so you can have one or two snark devs doing build your your snark thing and then you've got this problem with the trust it's setup and other things like this there's a number of headaches but it's actually really orthogonal to the

rest of your engineering so it doesn't have the same problem that the NPCs do where it like it's in it yeah it's so stuck in it everywhere mmm or it depends how you use it of course but it can be pretty orthogonal and this makes it a good in engine from an engineering perspective it's a good choice nice so in the episode that we did with crisco's I tried to paraphrase what you had told me Alistair on the phone about cross-chain privacy-preserving token transfers that were possible in polkadot Frederick you jumped in made it hopefully a little bit more understandable for people I still don't think we totally nailed it out what what is that can you explain it I don't think you did about I'd listen to the episode

now I don't think you did a bad job in covering it so I mean in Chris professor explained broadly speaking starting with how do you chard a system like C cash we're sort of each chair you notify determines which chain you're on somehow we need to get one big mogul three well we just pass around merkel routes between now in terms of interoperability these systems will need to trust each other but that's fine I'm polka dot we can do that so what we do on polka dot what maybe we should plan on doing is let let's sort of have a a spree module which is spree is further explained last week is a way of well it just does two things well one of which is we have code that's isolated from the rest of the the runtime for the particular pair chain

and secondly this is also shared code between chains so we'd have a spree module that was sort of like shards e cash it would be doing the thing that was very phone snarks it would talk to other things on other chains and send them the merkel routes of the UT x hours so they would be able to you be able to prove in it it's not just like c cash that this mochel tree had the UT EXO in it when you do that it could be from any chain because it's just shot a DC cash and each chain would have its own to do nullify a set and it would just make sense as long as we can guarantee you that this this code was rung correctly and it's the same code on all chains it just works on polka dot it doesn't need

any of the complicated things we might have to do for bridges that you discussed with Chris so there's actually a number of interesting privacy things you can do in polka dots design one thing that is of kind of interest here is so the the way in which this thing is spree it needs the all the spree design is a bit more relaxed I think than them a lot of how you'd use sprees so you could imagine even having chains that like you something like sexy and they're actually possibly not the same chain but some of their sexy components are shared and that's an interesting question is sort of how would we pipette part of the sexy components into a spree and have and still allow the different pair of

chains to have their own independent sexy like circuits and then hide which ones actually running the way sexy does there's a bunch of weird stuff like that we're not thinking about at the moment but one day speaking about privacy I'm curious to hear this story of mix nets which you started working on Jeff I mean when you talked about your background you said this is why you got into into the Dream Foundation but polkadot is not currently using a mix net is it planning on using a mixed net you know what's the current state of things so I mean the the foundation's mission is something about stewarding distributed technologies and that can't really be done without some metadata privacy stuff there's other projects doing mix nets I kind of think they're all going to

screw them up to some extent so eventually we need to do one correctly but we have to it there's some complexity here we have an incentivisation scheme for mixed nets we have some mix mix net designs that allow that while they're not as fat they're maybe a little bit higher latency than some of the other designs they're simpler than like some of the stuff that's been designed by academics that use it's like one privacy-preserving thing for fetching messages and a different one for sending them and they require all kinds of proofs in the mix net so we have a fairly simple design for the mix net and we have an incentive ization scheme that doesn't require the users to pay this is maybe a topic for another day but if people are interested

I can point them to the to the write-ups we have so far but I don't think we'll be working on that for much for the next six months maybe you can actually just share that with me and I'll put it in the show notes you know it's a good idea and we should make it happen I mean how would we integrate mix tests into polka dot it's not so obvious we there's a few things you might want to do and in Miss Lee like submitting transactions yeah we might we might look at how to do that if we leave that eventually one day with a mix net primarily polka dot is ultimately one tool for building kind of distributed infrastructure it's sort of more handles a consensus and a financial side of distributed infrastructure and the mixed net handles the sort of metadata protected you know the

protecting the metadata of messages that the users actually send so it's it's just a different piece of the basic infrastructure you need to build distributed applications because it's not the financial side it gets a lot less funding but I think we can still do it okay so you've covered this sort of example of the cross chain privacy preserving token using like where the zero knowledge proof uses spree basically or you is used within spree but how else are there no proofs like I mean I I know both of you guys are in my study club I know you're focusing on it so where else are the are we scenes they're an alder proofs being incorporated into the polkadot design well it's the polkadot design so we're looking with interest at for how people

do scaling about CKD rollouts about what coder is doing so so in in polka-dots braless para chains have to prove to validators that what they did is correct they could get an extra piece of scaling if they could do this with this is sink proof rather than what currently happens which is we have to give in extremely lots of merkel proofs on top of an already big block in order to make something huge that we pass off the validators so if we could do what code is doing we could definitely have far more scalable parrot earrings and we're definitely looking into that but no promises would that be like recursive snark based pair of jeans like well okay it doesn't quite need to be recursive if the difficult thing is how do you get a

state machine for a block chain into a snack in the first place and this all goes into how you write para chains and I think this this is totally up for grabs for anyone out there who wants to build this protocol and wants to build this parrot chain you could build a pair of chain that is like roll-up but instead of submitting that the end result to ethereum and like taking up a whole harem block with just this proof and it's data like you could just have that bead the parent chain itself and submit that to poke it on yeah we will be doing some stuff of this for sort we will be giving some grants to at least one if not more organizations working on this but yeah it's very much unclear I

mean there's a lot there's a lot of complexity here and yeah once we've got that it's from polka dots point of view we now have to you there's now an availability problem we had a solution for availability that worked before it doesn't work anymore because now the validators don't have the data so there's definitely some research needed to get that to work but it's also not necessarily on polka dot to get that to work like we could you know it would be nice to get that property but you could also do say this is on the parent chain to ensure data availability for its data like that that also gives an incentive for that parent chain to have its own token that you could then incentivize data keepers with them etc etc but I think that's kind of an

interesting design space that sets polka-dot apart from any other systems is that this flexibility is something that people don't necessarily account for or think about properly I mean it is a sharded blockchain at the end of the day so people kind of put it in a similar bag as maybe two and then say well you can do roughly the same things as in these two but no you can actually do way more but you know if you do more and if you do more stuff like this like you know a ZK chain and then you also take on more problems you also have to like be responsible for more things so I mean it's it's up to the designer but yeah are you then like is there something that you'd have to do from the research perspective to make this easier

for people so one thing you do have to worry about is when the verification functions in particular in the batch verification functions for these other things that people might build actually need randomness and what kind of randomness they need and stuff like that so it's conceivably you can end up with a situation that some I mean for things like snarks and whatever will put in stuff eventually into substrate to just verify them and and and and we still don't have a batch verification of signatures in but we'll have this and eventually and but if you do some like if you have your own custom Stark breed or whatever and then you need some randomness in the you know a validation function or something actually for those

I guess you don't at all but for something else you know maybe in particular if you did anything lattice based it would be a big problem like you we'd have to we'd have to accommodate you in substrate in some way or another and lattice based is actually worse because there's a the failure probabilities are not necessarily negligible assuming that people use substrate there are other ways to build pair of chains but no but I mean if it has to be checked by the validators if you have to check but never we can discuss this another time anyway lattices are far a long ways away from being used here so don't worry about it are you paying a lot of attention then to like coda and ZK roll-up work are you working with them are you like we're not really we listen to what they say publicly in a previous episode we

were talking we're actually talking to Isaac from coda and talking about naming and I told this story about baby Soros whatever the the crazy name we came up with was but this is polka-dots block production has gone through many stages of evolution and design and whatever else there's a new new kid on the block again you know yes I press sassafras can tell me what that is right so the the idea generally behind him so when you have a block producer there that there there now a single point of failure so if I have a scheme like or a simple round robin it works as long as the validators are sort of secure enough but if we have a single block producer and

everyone knows who it is then nothing stops anyone from just trying to run a denial of service on them in some sense it's much better to have to not know who the next pop producer is and this is the sort of idea behind babe that we use a vrf which we talked about earlier to sort of decide whether I should be a block producer but now what happens is every one independently at random might be a block producer or might not be able a producer there might be several there might be not and normally the way you'd fix that is essentially by emulating Bitcoin emanating proof of work but one of the downsides of proof of work is that the block time is random this leads to a lot of orphan blocks and makes the system difficult to reason

about so one of the big advantages of using hora before was that blocks have an in constant time there was only one person who's producing a block and they produced a block regularly every six seconds or something the problem man is how do I still produce blocks every six seconds but not know who the next block producer is we were aware of this problem like I don't know almost a year ago or something what we didn't really at that time al and I kind of lost it laughed it off it's like oh why would you do something complicated when you just have you know this babe thing that we can do so easily and your box will come in well you haven't pointed out that we kind of and Rob pointed out that it would kind of do want the blocks to come we we weren't taking proper

to the engineering side a lot of the engineering side here both on polka dot Allen pair chains so yeah so now we have this thing that's constant time but not as secure so your protocol labs had a competition they offered two hundred thousand dollars donated recent paper about how to do this problem so and sort of the solution we came up with was to compromise a bit on the anonymity but the basic idea is what we're going to do is everyone's gonna produce a v RF v RF output and then we're going to sort them and there's this will be the order people if we the plot produces the only trouble is is that you really want to anonymously prints this Vera who used to be a ref output so there's two problems here one of which is what do we put on chain do we could just have people

claiming that this is our output and then they'd be able to be use a block but they'd also be able to spam and we could have some complicated scheme to blame them the other idea is is we have this idea called a ring PRF and there's another construction called a group v RF which we don't use because it requires an MPC right and a ring v RF like a ring signature one of a group of people produces this and we prove that it was produced by one of a group of people it's a PRF it's a sort of private randomest that was produced by one of a good four people then later the person who produced it can prove that actually it was me it's my private key that was used in this so this is what we're currently doing with a bit of snark so

the the way this circuit works is there's two ways you could build a circuit the way we're currently using is the simple one which is simply you hash something to the curve so you get an elliptic curve point and that's a public input to the snark and then inside the snark it does scalar multiplication so your hash something literally to the Z cache Jubjub curve then there's a scalar multiplication by a job job in the circuit and there's a Merkle tree proof that that scale that the public key there's also a scalar multiplication of the base point and then there's a local tree proof that that guy was the that that's in the Merkle tree of public keys of the validators and now if we had a way to anonymously send these proofs that one of us generated this then we'd

have a completely anonymous scheme just solved dampeners prob problem that they wrote a paper out the dip would take a different scheme the only trouble is how did you do that well we could use a mixed net yeah be very complicated and I don't know if it reliable and be that complicated be more complicated less reliable but we actually did some analysis of it and at reasonable sort of parameter choices we're more vulnerable by making the thing more anonymous because the thing we care about isn't literally the block producer anonymity it's our vulnerability to these different attacks and so the main problem with mix Nets is messages being dropped so if someone drops your thing there maybe you have to publish it yourself and break you anonymity and so

what we actually came up with doing is a simple thing let's let's just send it to a random person and have them publish it so it's sort of a one hop mix now without all the complex and this obviously if you have 10% bad guys and you just ten percent of the time they know who you are but the calculation is it isn't enough for them to attack the consensus so it doesn't quite told the problem that Falco and we're talking about in this paper but it's good enough and it's much simpler and it's it's simple enough that we think we can yeah implementation work is going is ongoing and it's also a lot less bandwidth I mean some of the other designs are almost as simple in particular if doing permuting on chain the keys in some random way of the validators is is

almost as simple as this but it's or as probably is it simple but it requires a lot more bandwidth than this this is only sort of linear bandwidth than the amount of blocks where is that something like that would be quadratic the other nice thing about a ring vrf is it's actually I guess a way to think about it is it's almost like one of the very first things you would jump to when you start trying to put put things in snarks you mean it's it's a relatively simple circuit like it you know ring signatures are sort of one of the very first things you try and do and so a ring vrf is kind of right after that and one of the nice things he gives you is an identity scheme I meant this comment the earlier that you don't that

identity scheme shouldn't really say anything about the user except that they exist in that they don't have another identity so what a ring vrf does is you have this Merkel tree of all the users in the world in your world whatever it is and if they want to identify themselves to a particular mein then they the input to the vrf is the domain the place where they're trying to identify themselves you know Joe or Twitter or whatever or Twitter on Thursdays or something like this and and another thing what is an idea is an identity for you know this user a Twitter on Thursdays so now we consider say that in this context I'm one of these users and someone else can say I'm

another one of these users and we know these were different people what we wouldn't be able to link their identities with them identity generated in the same means on a different domain so Twitter on Wednesdays you know maybe Twitter if you misbehave seven times it wants you to be blocked forever but it's only gonna block you but one day of the week if you misbehave badly you know so we get the D sibling but we still anonymous which snark dis used for this Z cache stuff well actually we had there's another implementation done by parity intensive no I don't think so right oh yes so yet Jim post thing we haven't done let's see so he there's there's a couple other designs we considered here so Jimbo and I discussed using a group

vr af-s but the problem is these take that dkg which is an npc that would be kind of annoying it's it's asynchronous it's best better than a lot of situations see uses of that kind of thing but why have the complexity it's possible that this ring vrf at least at our validator sizes is actually would be faster everything would be faster to use not exactly bullet proofs but the IPP stuff from bullet that are used in bulletproof and Jimbo Jimbo worked that out but we're not using it at the moment we didn't quite push it to be production it was easier to get there with the snark maybe we should just didn't like benchmark things but because actually we could do that with the exist that could actually be added to snorkel so we could

do that but we haven't all right so I think we're almost at I'm I'm curious so I think to wrap this up what else is interesting what what are you looking forward to what are you what are you excited about that you haven't actually incorporated yet into any design but you're like thinking about so all that makes that stuff is interesting that we really need to do like that's important we need to actually get a feel for these roll up these roll up designs I mean this is so far all stuff we've talked about there's a large space around the mix net of stuff different stuff that has to happen and we had at some point in the past we had a collaboration or like a discussion with status on this but the at the end of the

day we were too swamped with polka dot so it kind of fell through and they're working on certain components that are very important in particular sort of how you decide which how the user tracks their own messages there's another thing you need some messaging layer crypto that's quite important and there's a bunch of different things some extent it's kind of solved by axolotl which is bet which moxie renamed to signal protocol but in the words of matt green will always be axolotl to me and but there's this group called the there's a project called messaging layer security which is attempting to sort of design a group ratcheting scheme for messaging stuff that will hopefully be better than all the other stuffs out the up stuff

out there but it's a big long slow running you know Stander's project and but I have a lot of faith in the people involved in it there you know Benjamin produced in Paris and cash Cramer these people are very good so hopefully whatever comes out of that will be really great so that's all this isn't really blockchain this is messaging encryption stuff but it's all very important and we've talked about thanks you including the some of the less plausible things yeah one thing I mentioned one thing that I really hope comes out so I mentioned why I thought the ice aaja news vdf was better and a thing that is not a problem for vdf is that i sadja knees are really really

slow and that's fine cuz if everybody if it's low for everybody the vdf is happy but pushing as a byproduct of trying to push and make this this work we may end up sort of understanding how fast we can push i sahjhan ease crypto in general which is important because it's one of the contender it's one of the less strong contenders for the post quantum crypto for more general usage and the reason it's actually the smallest so in certain sense I saw Jenny's crypto alternatives for a lot of for certain post quantum things are the most blockchain suitable because they're small but they're really slow so if we happens to make them fast as a byproduct

of doing a PDF then that's kind of that's actually probably good for us in other ways but we really no idea what's gonna happen there like I don't think Luca has a lot of faith in them ever being fast but you know when you start shoving things in FPGAs who knows cool all right well thank you guys so much for coming on the show thank you very much thank you vampy and through our listeners thanks for listening thanks for listening [Music]