IRL Workshop: Build on Ethereum, HCM Day 1

Transcript

foreign [Music] now okay

is oh thank you

so yes

huh okay hello hey

oh yeah um uh

you that's

unfortunately today

so hi everyone thank you very much for joining our first workshop with vietnam and we will start soon so please like be settled and please kindly like take up turn up your phone or put it in the silent mode please thank you so much [Applause] so i think that everyone is settled so let's start hi everyone welcome to eat vietnam thank you all for joining us today for our first workshop and first of all we would like to introduce our mentor

our speaker today barry whitehead from ethereum foundation and also today we also have other uh supporters and also other sponsor for this actually fnv sponsor from aws from dawn's and the aws team even though he got some injure but he come today to join the workshop with us he really loved to join this like gk knowledge workshop and also i have other support team must meet team uh also like former quickcom team and also like all you guys like from many familiar faces that i know here kaiba and many other team cypher and many

other community members also thank you very much for joining the workshop so first of all i would like to like let you know about the series of the workshop that each vietnam will do so the purpose like why we do this because like we see that we can you know like supporting and also connecting the global team and also the local team and also like focus on the technology and also the depth community so we believe that with that we can help all of us like leverage our own knowledge and also together we can view the better projects and thanks like to you um many other like experts and also mentor like very well today

we hope that like you also enjoy the workshop and we can learn more new things so i don't take the stage anymore please like welcome very white hat what is that schedule okay so so the schedule today is like very simple like first today we just like uh helped barry to share the basic knowledge about zika knowledge and also like about uh project on eth room ecosystem and also after that we also love to hear from you guys from the local community like what you are doing what you're building and also like what is your expectation so we also know that like what we can do better for the other

workshop and also for two tomorrow very well had also like have more technical workshop focus more on the technical part and also like we can have some you know like challenge or building something together and you might use a laptop to do some fun thing with verified hats i will take the micro at the the free one later do i have a thing for the slides

ah okay anyway so today i'm gonna talk about a couple of things uh first of all we're gonna uh start with uh introduction to like some things that you can build with privacy this is going to be like a sort of basic introduction to like what zkp's are and like what they do but we're not going to talk about like how they work uh so we're going to do that and then after that we're going to after that we're going to talk about like some of the different applications that have been built already and we're going to see like some of some of those things and then after that we're going to talk about like a bunch of scaling uh how to do how dk roll-ups and optimistic roll-ups work and we're gonna discuss

about like how we can like how you can make like secure bridges and things like that and how you can make like more scalable transactions uh on layer two so that's kind of my plan for today the first part is is kind of more prepared i have slides to discuss uh queen is there something for the slides i yeah so the first part is is more prepared um and the second part is a little bit more open i my plan is to is to like go through that stuff and then like i i'd be happy to have some interaction because it's going to be mostly on the whiteboard so so we can we can talk about it and like i'm happy to get questions and deeper discussion

about things so like on the second part we can go like whatever direction is used interesting for you all like my idea was to talk about like layer two stuff because that seems like a important topic in the community in vietnam at the moment so i'll spend some time doing that and like if you all want to go in another direction i'm happy to talk about other stuff too yeah so that's kind of roughly the plan so maybe we'll take a break in the middle because it's like it's like a long time it's like two hours so maybe we'll take a break after after we go through like the first section and we can have some coffee and some tea and stuff but yeah okay that's all good yeah

yeah okay okay so let me talk about like the background knowledge that okay so let's start the privacy part and let me first talk about like the the background knowledge that's required so like i'm not assuming any background knowledge here this is a this is like an introductory presentation so the background knowledge is basically it is basically nothing just have an idea of like how computers work and how like how you can define programs and things like that uh that's that's the the the main background knowledge that's required but like there is a couple of things i'm gonna explain right now that are important uh and the two things are like

hash functions and merkle trees uh so can i get the next slide please yeah so so the first thing to talk about is is uh hash functions so basically what a hash function is is that like it it's kind of this like irreversible thing that you you you give it some input you give it like a big input and it will give you a small output and it's impossible to take the small output and go back to the to the big input yeah so that's kind of what's described here in this picture that you have this like big input on the on the left hand side it enters into our hash function and on the right hand side you have this like completely random output

so like that's what a hash function looks like but like the output has to be much smaller than the input like the the point of this is that we're able to use it to turn like big amounts of information into into small amounts of information and that's important because like we we want to have like very small descriptions of things so that's what we use hash functions to do and we use high functions to do this in conjunction with we use hash functions to build what's called a merkle tree so can i have the next light please uh yeah this one so like a merkle tree is basically like this thing that you make with hatch functions so a hash function will will will take in this big input on

the bottom and it'll kind of like combine it together with each hash into a smaller field so you see at the bottom it takes in this big amount of data l1 and we hash it and then the the size of of the result is much smaller so so then we take the output of of hash zero zero and hash zero one and we and we hash that together again and we just continue doing this until all of our data has been compressed from being like really really big into just a single top hash here which we call the merkel merkle root so the merkle root is normally it's normally like it it it's really small

and we use the merkle root to commit to things on chains and like the reason we want to commit to things in a small way is because we don't have a lot of storage on chain we want to store only as the the minimum amount of information we can the other thing that merkle merkle trees that you do is to do something called a merkle proof that you're able to prove that like some data is inside the merkle root and that proof is really really small too and basically the way that you do it is is you just take a single leaf and you kind of hash it together with its neighbors all the way up the tree but you only need to know about the neighbors yeah you only need to know about the neighbors so if you look at the

like left-hand side here if we want to prove membership of l1 all that we need to have is l1 hash01 and hash1 that's all that we need to have in order to be able to prove that l1 is part of the treat so like like if this is too too difficult to understand we can just abstract it away and like we can abstract it away by saying that like it's a and that's all that you really need to know on on like the the highest level so often when we're doing zkp stuff it it's it's it's hard to understand all of the

complexity of like these systems so like what we try and do is try to abstract away the the the components to kind of black box out the pieces that we don't understand or black box are the pieces that are like a little bit too much information for us to to try and explore right now and that way we can still like make progress on what we're doing while also like later being in a good position to learn about like what else we need to do so so that's like that's a big part of like the philosophy of this presentation is we're black boxing out a whole bunch of different things and like we like the idea here is to get a high level view of what's possible and from there we'll be able to sort of like

see what's possible and then we can make decisions about the specific things that we want to learn so that we're we're still able to make things because like you you can make things with zkp's relatively easily or like it's possible to make them without understanding all of the math like a lot of people think that like oh i want to make something with ckps so therefore the first thing i need to do is learn about abstract algebra but that's not really the case because like when you want to make something with with a smart contract like you didn't like when you started to make something on on ethereum you didn't say okay i want to make something on ethereum the first thing i need to do is learn how ecdsa signatures work right no nobody ever does that everybody says

okay i understand what a signature is it's like it's like a signature that you you write on a letter it's like only you can make the signature and everyone else is able to verify the signature and that's what that's what a signature is and that's like and now we've successfully abstracted away this concept so we don't have to worry about studying ecsa signatures before we're able to like make our first ethereum hello world application so like let's take this this this approach and let's apply this to like the dkp problem where we're going to abstract away the different components that we that we that we want to that that that we we want we're going to learn about later so that we're still able to make like a proof of proof of concept applications and we're still able to like play and

learn and figure things out in a way we're we're making incremental progress rather than we're like studying a lot and then then like a year later we're able to make our first application so okay so that's kind of like the the plan here in this presentation and like that's that's also been my plan like when i've started to learn about these things i often just try and try and find the the specific piece i want to learn about and try and blackbox out the other pieces as much as i can okay cool so can i get the next type oh so oh yeah so so that's that's what a miracle proof is and that's what a hash function is but the other important piece of of like introductory or or or like background knowledge that i would like to share it's like what is a zero knowledge proof

because i'm sure you all have heard a lot about zero knowledge proofs being used for like private applications and and and and and like uh scaling but like the definition of zkp is is pretty simple it's basically i want to prove something to someone like you can give a proof to someone that someone can check and and like when someone checks the proof they basically just check everything that you've done and that's like that's not a zero knowledge proof that's just a proof so when we're gonna do like when we want to do like a zero knowledge proof it's it it's very simple it's it's it basically what we want to do is hide the information that we use to prove the statement so a zero knowledge proof is basically like i can prove to something to someone that something is true

without revealing why it's true okay so that's what a zero knowledge proof is so could i get that next slide cool okay so so this is this is this is how we're going to talk about zero knowledge groups we have this like visual representation and there's two oh i think we went two sides forward could we go back one ah yes this is right so so when we see zero knowledge proofs we're there's going to be two views that we think about right the first view is the

view of the system of the prover the way that the prover sees the world the the zkp because approver in order to make proofs about something being true the prover needs to know that it's true and like they need to know all of the information about how they're proving is true so for the user there's no zero knowledge or for the prover there's no zero knowledge the prover knows everything about the the proof and they know why it's true and like basically they use the zero knowledge proof to turn the like description from to turn the description from like zero to make a description that's private for the verifier ah here we go

uh sorry try it oh it's off okay we got it so where was i um right so the prover knows everything about the system because in order to make the proof they need to know why it's true and they use the zero knowledge group to hide it from the verifier and like when we talk about this it's it's gonna look

like this when we're talking from the provers point of view see that like we have a certain set of public inputs we have a certain set of private inputs we have the the check that's being performed and then we have the output and this is this is like the most basic circuit that i could come up with which basically says that okay i take a public input and a private input and then i multiply those two together and i say that it has to equal c and then i say i return c so like one like use case of this circuit could be like i want to prove to someone that i'm able to perform a multiplication i'm able to multiply a number a by b and that equals c and like i don't want

to reveal what b is that's one of the the applications that's like a very simple application i don't think that like this circle would be very useful it's more like an example that's the circuit that's our basic circuit and like let's see what it looks like for the verifier oops ah a little lag okay so for the verifier we see that yeah so this is our approver and this is what our verifier sees yeah i wanted to be able to cycle

through so you can see the diff but like basically the difference is that we've hidden this variable b oh this one is supposed to be hidden too this is this b and this b is supposed to be hidden because like inside the zkp we sort of hide we hide the the variable b so anyway so fire i've just talked about like this is what a zkp does and i've given like a a simple example of that that's like it's not very useful this circuit but it is going to be useful later to have this like abstraction or this way to discuss circuits okay so let's go to the next one so when you verify your views you can still see the input right

yeah so you see oh yeah okay that's a good that's a good thing to mention so the prover sees everything c's a and c but they don't see b yeah there should be a box here i'm sorry i i i i messed up the slides there should be a there should be a cover for the b but the rest of them should should should be should be covered uh the other thing to notice is that like the verifier sees a and it's cc but they also see the check that's being performed they see that it's like a multiplied by something equals c and

that's important to remember because like if you have like a a zero zero knowledge proof where like you don't know that the check that's being performed that would be like kind of meaningless right because like you need to know what the person is proving because if you didn't know what they were proving then it would just be like a it would it wouldn't be very valuable so so the zkp also reveals the the checks that are being performed it just hides some of the some of the input values to those checks what's the analogy of like approver and user or a verifier in some sense some application sure okay so uh let me see

so let's take the example of a of a mixer so a mixer is where you like deposit some money to a smart contract and and you make a zkp to withdraw that money to it to a new address and in that case the the approver is a user who is deposited yeah user deposited like some some some token inside and they when they're withdrawing they need to make a proof that like this is my this is my money the verifier is the smart contract yeah the smart contract will verify this proof and says oh look you deposited money you made a ckp now you're able to withdraw it so that's uh that's an example and that's that's the example we're going to

talk about next we're going to take this example of z cache yeah so c cache is is is like a mixer but it it yeah so z cache is like a mixer and basically it's a way to okay so z cache is like a mixer and basically it's a way to like you you can you can send private transactions to people and basically yeah so so zcash needs to verify that like transactions are correct um and it does this using zero knowledge boost it also needs to prevent that to to to make sure that like when i say transactions are correct we need to make sure that like the the owner of of that coin is consenting to this transaction

and basically we do that with like a signature check and we also have to i'll talk about that in a minute so so like first of all they approve ownership of the funds and secondly they prove that they they do something to prevent them like double spending a coin like double spending is a big problem on like in in cryptocurrency in general and all different cryptocurrencies have different approaches to prevent it and with with zcash the way that they prevent it is using a nullifier so basically i'll talk about another fire in a second let me go to the let's bring up our first abstraction okay that's too far just go back one okay okay so this is what our this is what

our approver sees right our prover sees everything they know all of the all of the states of the system they're using the zkp to hide some of the information ah i'm a little bit the first let's let's look at what we have here so the first thing we have is a merkle root so let's remember what a merkle root is so merco root is basically a way to like commit to data so in this case our merkle root is like all of the all of the coins that have been deposited so so we have our merkle root and this is this is like a public input and what's our public output is our

nullifier so so basically what we have here is we have something that sort of like says that like this this this user has spent this coin and then the nullifier prevents them from from spending it again so let's let's look a little bit deeper about how exactly we achieve this so we have our merkle root and we have our private inputs so let's look at our private input so our first private input is our merkle proof and that's basically proving something is part of the market it's proof of membership uh we have our public key and we have our private key we have our publication private key to verify that the consent of the user the user is consenting to to make this transaction so we have the we have the oh no

the the public key and private key is here to to consent to the transaction that users need to be like yeah i want to send i want to send this this money to here and the final thing that we have is the private input is our nullifier and our nullifier is to prevent the double spend so let's let's see how these are actually consumed so let's look at our look at our checks the checks that we perform inside of ckp so the first check that we perform is our membership check right we want to say that well you can only spend coins that are valid you can only spend coins that are inside our merkle root so how do we do that well we do a membership proof that basically takes the public key the merkle root and the merkle proof and it proves that like the public key is

inside the merkle route yeah that's our first thing that we're doing with the user is coming along and saying that i want to send this transaction here's here's proof that like i want to spend this coin here's proof that like this coin is valid this coin exists so that's what i hopes that's what our first check does our first check is just about like this is a valid this is a valid leap this is a valid coin this is a this is this is this is valid money and then the second thing that we need to do is we need to check consent okay it's working better

huh okay the second thing we need to do is we need to check consent so how can we check the consent of the user well we use a signature scheme normally so i made this like very very hacky signature scheme here which is basically just a hash function and the way the the way that the signature scheme works yeah yeah the way the way that the signature scheme works is that like you you you have a hash function you have a uh the the private key you hash it with the nullifier you calculate the public key uh and like the idea here is that like

the private key in the nullifier is only known by the user so if someone is able to make this this hash function that that from one can calculate the other there then then it's it only they know that so only they can make that proof therefore it's a signature that like only one person can create and so it's a it's a good signature scheme okay so this is the first site yeah so this is where we want to be so that's that's what our that's what our hash function is doing here so it's basically taking it's taking the private key in the no fire and it's calculating the public key and then the final thing that we're doing is that like okay so what's this concept of the nullifier so the

nullifier the nullifier is this is this is this thing that can only be spent once right oh so so the nullifier is this thing that's like deterministically calculated from the private key so when a user makes a when a user makes uh a coin they have they make a new private key and a new nullifier and every time they spend a coin they say okay here's the nullifier of the previous coin and and the idea of the nullifier is that it prevents people from from double spending the same coin so like when we have privacy we have to we have to be we have to make sure that people aren't able to like infinitely spend the same money so we use a nullifier to prevent this because the nullifier is just like

it's it it's like oh damn it that's not it's my fault i keep pressing the wrong button here i keep trying point the laser so okay that's that's that's what the nullifier oops okay so let me not use the laser i think that will help yeah so that's what the nullifier is uh so the nullifier is basically like prevents you from from from spending the coin more than once the nullifier is so so like let's talk about like what the verifier sees let's talk about what the verifier sees okay here's what the verifier sees the verifier seems a lot less than what

the approver sees so the verifier basically sees that there's a miracle route that like the verifier has also has a list of valid coins and the verifier says that i'm only going to let people spend coins that are valid so in the smart contract or in the zcash protocol the verifier will remember this merkle root and they'll only allow they'll only allow proofs of the merkle root if yeah they'll only allow proofs to have this mercury as a public input so yeah they that that's how that's how the verifier limits the set of of valid coins the other thing that they so so so they they they have the merkle

root and then they so what do they actually do they verify the proof of membership but they don't know which coin it is and they also verify they also verified like the signature but they keep the they reveal the nullifier right because we want to see what the nullifier is because we need to use it to prevent double spends so like the other thing the verifier will do is they'll store the nullifier in the smart contract and they'll basically say you can only spend one notifier once if you spend another fire if if if two proofs have the same the second proof is invalid right because that means someone's trying to like double spend the same same money how can they how can they verify the http of the membership without the

the medical proof all those keys so so the question is how can just for people in the live stream so the question is how can the verifier verify the the the proof without the data without the proof of membership without the the stuff that we saw on slide one and okay so like the answer that is kind of like outside the scope of this of this presentation so basically what we're what i would say is that like we use the zero knowledge boost to do that and like the way that zero knowledge proofs do that let me try and give an intuition for that ah oh okay so like one intuition that i have about this is saying that like

if you want to be a hundred percent sure that something is correct you have to try really really hard you have to check absolutely everything but if you want to be 99.999999999999999 999999 sure that something's true you actually have to check a lot less right because that lasts kind of like point zero zero zero one percent is a lot it's a lot of extra work to get that tiny bit of certainty because like as you get more and more certain the work you need to do gets more and more so basically what we're doing with how zero knowledge proof works then we trade uncertainty and we say that

like okay we don't want to be 100 sure we want to be 99.999 very very very very very sure but not 100 sure so and that means that we're able to hide some of the data and it actually means we're able to hide a lot of the data so yeah i thought in this diagram we should have like yeah so this is the proof the whole thing is the proof like this is this is what the this is this is a representation of the proof so the the proof gets sent and then the verifier kind of remembers the merkle

root uh they they know the checks that are being performed and then they they they store the nullifier to make sure that there can't be any any more double spans so this is the first this is the first kind of like use case that we're going to talk about okay cool so so is there any questions up until now yeah feel free to interrupt with questions and stuff as we're going yeah so this is the this is the level

yeah this is the okay this is the proof review the next verifier yeah yeah that's i'm sorry yeah so this is a verifier yeah this is verifier because they're because we're hiding stuff this is like yeah there's less information here cool any other hardest questions i think that that's like the the peak of

the hardness of the whole presentation so like the rest of the time we're going to be talking about like use cases of this so congratulations you can all relax now a little bit we did we did the hard stuff and i probably should have warned you before we did the hard stuff that we were going to do some hard stuff i will do that next time uh but like the the like we got over the hardest part if if like some of it didn't make sense the best way to let's abstract the way and then later we can go back and and worry about so let's just get a higher level view of what what we talked about actually does so basically it's like a proof of

membership yeah you're just proving that you're part of a set and you're proving your part of a set in a way that like you can't repeat and like that's that's it you just it's just like a a private way to prove oh and i'm part of this group and i'm not and i'm not able to make another proof of that so this can be used for a whole bunch of different not just for for private transactions like with zcash and like let's talk about some of those other things um so one of those other like so in order to like enable some of those other things we made this tool called stem before and basically what semaphore is is that it's a way to okay cool

oh yeah that's nice sorry it's all good okay okay can you hear me is that good yep okay ah that's nice yeah so semi-4 is a way to prove uh is it just a generic group of membership um yeah it's just a generic group of membership it's like oh i'm part of a group and that's it and like so let's let's let's let's see how it works

yeah so it's just a generalization of zcash it's it's what we talked about before it allows us to reuse like in the previous example we had a nullifier that meant it was only one-time use but we have this extra kind of step here that allows us to reuse the nullifier and so what can we do with it we can build some like private voting applications where we could build like a zk dao we could build uh some anonymous social media there's a whole bunch of different things that you can use this to build because like basically it's a it's like a it's a way to have like private proof of membership it's a way to private to prove oh i'm part of a set

but i'm not going to show exactly who i am so let's look at some applications of this do to do yeah so let's look at some do i go straight to the okay so i let's okay so okay let me warn you again there's a little bit of hard stuff coming but it's only a little bit and we're going to add something else to our circuit that we talked about before and we're going to add this new we're gonna use a new primitive and our primitive is basically uh shamir secret shares and the way that shamir secret shares work is it's like uh it's like revealing a tiny piece of

information that's meaningless but if you reveal a lot of information then all of the your secrets are revealed so it's like this sort of threshold thing that if you reveal one share then then nobody really knows what you revealed but if you reveal more than one share then everyone learns your private key so it's another way to do raid limiting we we we call this like rln which stands for rate limit nullifier so it's it's another type of nullifier uh instead of being like just black and white on and off it's like stop or don't stop there's there's there's a limit there's a man there's like oh you can you can do one per

second or one per minute and this becomes interesting when we're talking about like doing applications like yeah okay so let me just let me just show ah okay that's good yeah i want to talk about this so let's talk about how shamir secret shares work so basically the way that shamir secret shares work is that like we we have a line right and on our line yeah we have that we have this line and on our line we have like our our private key here and every time we make a smear secret share we reveal one point on this line and okay so this is the hard part uh

this is this is the hard part that will take you back to like high school when you did like uh uh what is uh linear equations yeah yeah yeah so so so so this this will this will remind you of that when you were doing like that kind of like you had linear equation you were drawing lines and like one of the things that like you might remember is that like if you had a line with one point on it it's just a dot you don't know anything about that line but if you had a point a line with two points on it then you know everything about that line you know every single point that that line goes through and basically what we do is we leverage this and we say ow well if we have a line with two points on if we know two points on the

line then we know every point on the line so we say right let's force our user to do a couple of things let's tell our user okay you can make a line but one point on that line has to be your private key and it has to be at this position then every time you make a proof you have to reveal a random point on that line and with those two things we're able to force our user to make only a certain number of only only one oops that wasn't i wasn't planning to do that with that with just that we're able to force our user to make only one transaction or only one only one action every

every epoch okay so so this is our private key our user reveals a random point if they reveal two points then game over we have enough information so that we're able to to calculate their private key so that's how rln works so let's talk about like okay so but what can this or what does our circuit look like so let's go to the next slide oops too many sides ah it's a little bit like okay okay okay cool cool okay yeah cool

yeah ah nice okay maybe i can just do next slide okay yeah this is this is right yeah so okay so this is the this is a nullifier so this is like what rln does so basically oln is like okay we have a miracle route we have a and we want to we want to do the same thing we did right so we have all the stuff that we had before we have our proof of membership we have our mercury we have our proof of membership we have our private key we have our message we have

all these things uh like this is all of this is the same as before and then we just add this like shamir secret share thing so so basically we calculate a line this is us calculating our line our the private key is at the point zero and we reveal a single point on the line and if a user makes more than yeah that's good so is it possible to cycle between those two to just go back one and forward one back one and forward one i think that that's that helps to illustrate the what's happening here so so so the prover sees everything but the verifier sees like much less information because we end up hiding oh this one is supposed to cover this a

yeah but anyway the the so so basically yeah okay that's good yeah can we go to the next slide oh the one before so this is our approvals view and like the approver just sees much less information cool can we go to the next slide right okay so let's talk about so so so those are our two primitives okay the hard part is over those are two primitives and and now we don't have any more hard parts uh the rest of the time we're going to talk about like applications of these things so like we have two primitives our first primitive is like our proof of

membership and our second primitive is our is our proof of membership plus this like rule of like one message per second uh so we have one nullifier that like doesn't have consequences the nullifier and we have another that does have consequences if you if you break the the the the rln rule then you you lose your private key and you're not able to participate in the system anymore cool so skater is a is a is a a private social media application that's built using semaphore and oil and so can we get the next one here's a link you can you can go and

visit it so so like how does it work well then before lets you prove that you're part of a group and when you prove you're part of a group you just make it as ekp so instead of having posts coming from people you have posts coming from groups so you have this group that's like uh i think they have a couple of groups to do with like number of twitter followers uh like if you have like 500 followers on twitter or 7 000 followers on twitter you can join different groups and like the the discussions and the things that these different groups say are are like just different and like this is just like the first set of groups but i think we've signed up more groups like maybe we could have like a group for

like ethereum communities in different parts of the world that might be fun where people can post anonymously so you so you prove that i'm part of the group but you don't prove which which which member you are yeah so they post from the groups rather than their id so so like the users posts are not really attributable to them but rather it's attributable to to the group so this gives people like some like more freedom to like express themselves without and it also leads to more like community thinking around like the groups that you're part of and like the way that you want that group to be seen in the world cool so could we get the next slide yeah so here's an example of what it looks like uh so this is

there there's there's like a a a couple of basic groups here the first is is one with like 500 500 followers on twitter and like they recently added a feature about dark mode and this person is saying that they really like the dark mode and then this is another member of the same group who's replying and saying oh sorry could we go back one side uh they're replying and saying that oh well the dark mode is not really working for me is there some does do other people have a similar issue cool so so like both of these are this is this like private group and you can have like discourse between the different groups the groups can talk to each other and like there's user accounts as well so users can talk to groups

so can i get the next slide yeah this one uh so let's talk about like the anonymity set like how big are these groups this is an important question when you're thinking about private social media or privacy in general that like always you're proving you're part of a group but you need to how big that's could we go back one side uh yeah so so like the anonymity said size is pretty it's pretty small uh right now the goal group has like six members i think gold group is like seven thousand followers uh silver is two thousand plus five uh yeah so the anonymity side is is pretty small but like it it's like this it's this proof of concept of like a

world that is possible where you have like these bigger these bigger applications with like with like bigger anonymity sets and like private discourse and communication cool can i get the next slide and this is my account i i this is a user account i i posted when i joined so you can post from a user or you can impose from an anonymous group can i get the next slide cool they also have direct messages and the way that direct messages work is that they use rln and basically the rule is that like you can send like one message per second if you send more than that messages per second you break the oral and rule and

your your private key will be revealed yeah so this is what it looks like uh this is this is a this is a chat that i had with like one of the people in the 7 000 twitter follower group messaged me and like the interesting thing here is that like i don't know which member of that group messaged me i just know that it's one member of the group and i'm having like this like dms with with that person but i just know it's one part of the group i don't know i don't know exactly who it is and i just basically asked them how many twitter followers they had and they just they just didn't reply to me i guess they were just too busy cool uh but i'll let you know if i if i get

if i get a reply so yeah can i get that next yeah so so then there's there's a there's a couple of like helpers who are invested in building some zika application so like one of them is the same before repo that i shared earlier i think the slides are public already so like you can you can check the links in the slides but there's the same people that might be interesting to to to build some like a private application on top of uh there's also this dk starter app if if i can get the next slide can i yeah thank you yeah uh yeah so it's a it's a react web app it's like uh proof verification i don't know i just go back one and like

yeah and it has like i think it's a basic this is this is another application that just basically compresses ecdsa edd dsa signatures together so this would be like the building blocks of a zk roll up for example you you could take this application and build on top of it to make a zk roll up uh yeah okay can i get yeah so here's some ideas for for like hackathons uh build something with some before or or like play around with unknown groups there's this other website called hey and on uh which is with which instead of instead of have like so the problem with like the semaphore group is the anonymity set is quite small uh because it's just like it's it's a very it's a very small group because

people need to sign up to join but like well if we replace if we replace that kind of like signature scheme with ecdsa the signature scheme used on ethereum then we're able to use like we're able to make much bigger groups that don't have a sign up and that's what hey and on does they use this uh ecdsa signature circuit verification circuit so they use like ethereum's signature scheme instead of instead of the other inside instead of like something that's snark friendly so it's a little bit more expensive in terms of prover but it's still it's still pretty interesting okay cool can i get the next yeah okay and and this is our we have a website and a discord if people want to join and ask questions or or explore

our our website and our project be very happy to have you so that's the end of the first presentation i do people have some some questions or something else yes yeah you can absolutely so so let me just so oh sorry so the question is can we add more use cases sharing videos and audio and things like that and the answer is so you mean to something like uh using semaphore you want to have like a group that will privately share videos yeah yeah we can absolutely do that uh

yeah that should be that should be relatively easy if i can go back a couple of slides to to just one of the orlan ones or to the one about uh skitter where like someone was posting from an anonymous group the 500 twitter followers talking about dark mode one yeah so so basically like the the the information you're using to your proofs can be anything it can be it can be you can make a proof that a video came from a group or you can make a proof that like that like a a text message came from a group the way that we kind of connect the message to the actual proof is we just hash the message and then we have the we pass the result of the hash

into the proof so the message or the the post that you're making can be anything any other questions is there only one nullifier

in zcash yes yeah so then the scheme that i described here is a bit simpler than the zcash scheme so i think that the zika scheme the old version of the cash scheme it did have just one null of fire and it was i think it was a i think it was a hash based on shot 256. for keeper we are i can only use it once ah right so yeah yeah that's true so so like that's like you're getting at it like there's two issues here it seems the first issue is

that like i can only use a key pair once the second issue is i can front run someone's transaction if i see a transaction that has a i can create another leaf that has that same nullifier inserted into the tree a different keeper with the same nullifier yeah but because like the scheme that i described was very simple and it would allow this attack because like the nullifier would be the same but like basically they make the so anyway to avoid that attack they basically make the the nullifier be determined from the

from the private key but the z cash i think the way that it works is they generate a new nullifier for each coin but they keep the same private key so so like each coin is a different nullifier but the nullifier is derived from the private key so when you when you make the transaction the nullifier is defined so actually the way that the node file is disconnected from the uh sorry hold on just wouldn't like yeah okay yes thanks so so actually you see like the nullifier is hash once and then hidden in the merkle tree and then as long as you don't review that leaf nobody can get the microproof and generate another uh

xeon proof in which also has the signature for the transaction that you're assigning so you cannot uh modify the transaction or use the nullifier to to to to to to to authorize another transaction right yeah so so so you know i i don't think it is actually related to the the connection between the nullified and private key you can't have uh the so okay so let me repeat just to make sure i understand what you're saying so so basically what you're saying is that z cash is private key the nullifier is determined from the private key but in the scheme

that i'm talking about it's it's it's not it's completely up to the user to decide what their nullifier is and like that scheme is broken because if the user is able to define their private key then or their nullifier they're able to just set the nullifier to be another user's notifier and that could be an issue so we can't do that basically am i sorry that so what i'm saying is that even with even with the nullifier yeah you still don't have the microproof in order to generate the zero nut proof that is necessary to to let people video your transactions right so okay let me draw on the whiteboard

i i'm sorry that like we we got a little bit off topic but i'm going to come back to your question in a little bit so right so so basically the the here is the attack like we have this is our our tree one and then this is this is my leaf here and this has like a private key of 21 and nullifier of 32. so like the first thing that happens is i make my ckp and i reveal my nullifier 32.

i broadcast this to the network right and the network is sort of mining my transaction then a malicious person comes along and they say you see this and they see oh the nullifier is 32. what they do is they make two transactions the first transaction is that they add another leaf to the tree that that is 22 the private key is 22 but the nullifier is 32. they use the same nullifier as me and like because i've revealed my nullifier to them they're able to like insert this this leaf into the tree and then they make it a zkp

and that reveals the same nullifier 32 that reveals the same nullifier 32 and like when you reveal the same nullifier only one of these proofs will be accepted right there's this race condition like basically the attack is a griefing attack i don't steal anyone's money i just i just cause someone to lose their money so like like like in this case like if this leaf was like a hundred or a thousand this user could make one that's just like one yeah this is like a thousand coins this is one coin basically they're able to like for the cost of onecoin they're able to delete a thousand other coins so like

sorry go ahead yeah okay okay i see your point so it's basically a denial of service attack yeah yeah yeah yeah exactly so you're able to like delete people's money so like that is that is one of the things we have to be careful about when we generate the nullifier so back to your question does this make sense so far uh yes it's not sense yeah so so like so your question was i like how does the nullifier scheme work in the cash do they do you have to generate a new notifier every time you know there is no you don't and the reason for this is that like the nullifier in our simple scheme was defined as just like whatever

the user wants it to be but in reality the nullifier will be defined as like the hash of this or something nullifier will be defined as like something that's deterministic so that like an attacker isn't able to set whatever nullifier they want so because it's something deterministic based upon the private key the private key doesn't change all the time the private key is constant and the nullifier just changes depending on on on like which which leaf it is like the simplest approach is that we can have the nullifier be the hash of the nullifier 32 and the index of the the position of the leaf in the tree that this is a position zero this is a position one uh so it'll be hash of this and one and that and and that kind of that kind of

breaks this attack but it still means that yeah that breaks this attack and it allows us to have nullifiers that are that are like different all the time but you're not able to double spend because the leaf never moves in the tree right so so with this you can have the same nullifier everywhere but it'll look different each time right so let me let me give a more concrete example okay let me give a more concrete example this is our this is our tree and this is

just the nullifier so this is nullifier so so this is my leaf this is my first leaf my nullifier is 32 and this is my second leaf and my nullifier is also 32 and my private key is one so we just need to change our nullifier scheme so we just add something else in the low fire and we the thing we add is the position in the tree so this can be zero this is one this is two this is three so just position from like left to right and then basically when we when we calculate our nullifier the nullifier of this is going to be the hash hash of 32 and one and zero and the nullifier of this one is going to be the hash so 32 and three

right so that's that's like just a better nullifier so you can see that we can use the same leaf you can see that we can use the same it's exactly the same so the user only has to back up one thing remember one thing and the nullifier is always going to be different because it's the hash of different things so yeah i think i think that that's a it's a slightly more sophisticated scheme that solves the two problems that we talked about yeah yeah no worries any other questions it also you can put if you're watching online you can put questions in the chat

so queen i was thinking that like now we might take a little break because it's like a natural break between like the the first part of the second part i don't want to talk for two hours and just everyone fall asleep wow bye

with okay uh

yeah we good to start um okay so the second part is a little bit less planned um i wanted to talk about some layer two things and like how different stuff works i don't know if people have a preference about what to explore like basically i was thinking to talk about like bridge security optimizations on l2 and how to do things like cheaply or more efficiently that was my plan uh do people have like some interesting like their two stuff they want to talk about or some questions about layer 2 stuff security oh the bridge security no no no

no i just thought i was just thinking this goes about bridge security about how to make sure your bridges yeah yeah all right let's get started with like let's talk about like a basic introduction to like roll ups and let's talk about where's the best place to start well okay let's talk about a little bit about like the history of like roll-ups and like what was there before what we ideally want to do so like the problem is that like on layer one

we have like a really limited amount of transactions per second because we want everyone to be able to verify layer one because if people aren't able to verify it then they're not really able to trust it so like layer one we purposely keep the number of transactions per second really really low because we want everyone to be able to verify it but like we also want to be able to build things that scale more on top of layer one and one of the ideas to do this is to say is to say that like okay so let's make this there's two big problems when you have like a list of transactions or when you have like a block okay so let's talk about per block so let's take an ethereum block and let's see like okay what's what's

actually inside this block the block is just composed of transactions and each transaction will do like different things like this might be uniswap this might be i don't know what else ens and this might be ens as well okay so these are different transactions that are going to different applications to do different things like the way that ethereum that the way that these transactions are are designed is that there's a whole bunch of fields inside these transactions uh the the user signature is this is this big enough can people

see or is that too small for people of the bike bigger it's better so what's inside a transaction so we have a transaction what's inside it we have our signature uh we have our r2 from amount nonce gas price gas amount and various other things i i think that's mostly it so like the signature is just about consent the the two is

like the recipe all this data yeah data's a important one to remember the data talks about like what the transaction you're doing does and the two is like the the address and the amount and all this other stuff so like that's what it that's what a transaction is so like there's a couple of like this is this is the l1 block and like l1 blocks are purposefully like really small because we want everyone to be able to verify them so like how can we get more transactions into into a block like the first way seems to be to do things about like right so

the first way seems to be let's make the verification easier right but like in in an ethereum block all the users need to verify all the transactions but like if we make it easier to verify people won't need to make they won't need to do as much work to verify the block so we can include more transactions in the block uh the first so there's two big approaches to this one is to use a fraud proof which is an optimistic roll-up and one is to use a zk proof which is a dk roller briefly how does a how does an optimistic roll-up work okay so let's go through an optimistic roll-up let's take

a look let's talk about an optimistic roll-up so basically an optimistic roll-up has two things it's like the commitment to the uh there's a commitment and a fraud proof so so basically we have this like block creator here this person is making blocks and like every time they make a block they they make the commitment so the commitment is basically like this is the result after the the the new block the other thing that they they make is they publish is the call data this is like you can think of this as like a div we talked about here

about the ethereum transaction format this is pretty big the df is like a compressed version of that like the idea of the diff is that like we want to have the minimal information so that someone can reconstruct the state let me talk about like before we talk about this let's talk about like the the state transition so the state transition is we start in state one we start in state one and then our blog producer here produces a block this block is a state transition so they

they publish the diff and we end up with a new state and like the i the reason why they published the diff is that we want everyone to be able to calculate the new states they do just using the diff and the previous date the reason we do this is we we just and then we end up having like this chain of state updates that publishes just the difference so why do we care so much about people knowing all of these different states like there's and the reason that we care so much is

because we want everyone to be able to execute a fraud proof in case that this state is not correct but like this person is basically just updating the state of our system and like until now we haven't really talked about like what constrains them or what it what rules do they need to follow and basically what we what we do is we we we make something called a fraud and our foreproof will basically say that when you do a state transition you're only allowed to do the following things you're only allowed to like okay so let's let's talk about a simple example of just transfers like our fraud proof will basically say so you you for each transaction you have to have the signature

so you so each transaction has one one the signature has two like the the from amount right okay so let's hold on let me let me let me rethink this a little bit so maybe we shouldn't talk about the simple one maybe we should just go for the full evm so like this is this is this is kind of like what optimism and arabic do but where they're thought proof is basically the all of the rules of the evm so so like the idea here is if someone makes an invalid state transition someone is able to produce a fraud proof that says this is this is not the correct new

and like basically they're able to say this state transition they're able to revert it if someone makes an invalid state transition so like the idea here is you you have a fraud proof that that like annie was able to publish and point out that like this is incorrect and here's why they give a proof that it's not correct that's that's that's what we have an optimistic rule of works and the reason that's not optimistic world works are there any questions so far do you have the mic the mic yeah i can just repeat your question the process of producing more computational

not really like the frog proof and the div oh so sorry let me repeat the question so the process of creating the dip is more computationally expensive than the floor proof and not really both of them are very cheap uh making the the fall proof and the dip is just like the difference just like the so like two and data like that's basically all that you need for an ethereum block to calculate the new state because like once you have this you're able to like execute the transaction locally and you can and you end up with the state after the transaction has been executed yeah so that's the

yeah so so like calculating the diff is is pretty easy it's just it's just like a list of what you changed right so like the way that you can think about this is that like we started in uh our our our block creator publishes a list of what they've changed and then we end up in say two the list of what's changed is not correct someone could make a proof that points out hey this one is not correct and if they do that no proof to go from state two back to state one right so that's basically the idea of

optimistic roll up that we have this like two-way pass that we can go forward where we where we make like new blocks new state transitions we can also go backwards where someone can produce a frog boom say hey this is not right so like the the kind of equilibrium that we sell into if people are doing making like valid blocks we keep going forward and you can't go back if someone makes a vowel block we can go back and we just undo what's been done so sorry does that does that make sense that's that's what the diff is the the

diff is like a compression of like a bunch of ethereum transactions but it's not compressed using like like you could compress it using some compression algorithm but normally normally it's just like the diff is is actually that's a really interesting topic diff compression that we're going to talk about later about like how can we reduce the size of the dip as much as possible uh because like that gets into another thing i'm also going to get to later because like it like and like one of the key takeaways from this workshop i think is that like the only thing we need to optimize for is is the diff compression that's the key problem

for scaling layer two or for building layer two applications that scale right we like i i don't quite understand i mean i think that diff is easy i mean it's it's like and it's good that it is like any like with an optimistic roll-up anyone can be the block producer anyone is able to come forward and make like make like blocks that that process

does that make sense okay yeah this this part is like yeah um i like i i think that in reality we very very rarely go back we basically never go back because in a case where we go back someone ends up losing like 32 or something like because because of that the the incentives to make invalid blocks are really really low we only go forward we almost never go back

like going back is just very expensive it just costs a lot yeah but like so i don't quite understand your question like when we send the fraud proof we yeah i don't know if i understand yeah then we will go back okay so like if that happens so we have s2 stay

so like your question is basically like say four so if we're let's say we're in state four and we find out that there's a fraud there's a fraud here and you're asking like what will happen so what will happen is we'll roll back all of these we'll go all the way back to state one this where each one of these will be slashed so there's 32 slash here 32 here 32 here uh so so so like it'll end up just having this like huge slashing event where like a whole bunch of different people lose their security deposits

and everyone just comes back to the very start uh yeah so like that's one of the that's one of the concerns here that when frauds happen i think that they would be found pretty quickly but if they don't it can it can cause the state to to to go back pretty far i think that it'll go it can go back yeah it can go back like it can't go back to zero there's normally like a limited time period in which you can publish your thought proof but like my understanding is that like it'll pretty regularly it'll pretty regularly the fraud proofs will be like if there's a fraud the fraud will be published almost almost immediately

because the reward is so big when you when you think about like when you think about like mev and things like that the reward is much smaller than the reward here for creating a valid draw proof yeah sure no ways no it's like this is the basic idea of optimistic roll up that we have like we have a frog proof and we have our div so let me write opera here we have our frog proof as well so if something if something isn't right then we're able to just undo everything we've done and go back to that

this is like the basic optimistic role and like uh basic zk roll up is very similar instead of having a forward proof we just have a validity proof instead of having a problem proof we have a validity proof and then our validity proof basically we're not able to roll back we only go forward so every time you make a block you have a proof that the block is correct yeah so we only go forward you only go forward and you and you make

a block that things are correct and we also yeah we we also keep the diff we have we have our diff and it's it's almost exactly the same yep okay so so that's basically how optimistic roles and zk rolls work um so what's the major like so what are the cost savings here i mean like why why are we why are we doing this like the the first reason of why we're doing this is that like the yeah the first reason why we are the

first reason of what like why this is more scalable we're just putting the diff on chain we're not storing it so the diff is is like the expensive the expensive thing now but we're not storing it we're just putting it on chain the other reason why this is why this is cheap is that like either we're executing as ekp that's super cheap or we're where we have a fog proof that's almost never executed because if a frog proof gets executed it's like 32 each will will be destroyed this is these are the two kind of big approaches to to scaling at the moment both of them depend upon both of them depend upon people putting

the different chain i like i started to think that like like one of the other key takeaways that that i have when i think about about like moving from layer one focus to development to layer two focus development one of them is diff compression is super important the other is that like execution is basically free now because execution doesn't cost anything anymore because either you have a fraud proof where which never gets executed or almost never get executed whenever it gets executed somebody loses 32 e's which means that it's it's very very rare or you have a validity proof that's super cheap to verify

unchained execution is free the thing that's expensive is is like publishing the diff so what is the cost of publishing this so the diff is basically published as call data call data is very cheap but it still costs so let's compare the two let's look at the diffs of zk roll up and optimistic quality so this is that signature so let's have a look at optimistic roll up optimistic

so what is gonna be in our div who are we sending the money to from who's the money coming from how much is it uh data what are the what is the the the contract call data what's the like if i'm calling unit swap what is the function signature what is the function parameters ah the key thing that's expensive for optimistic roll-up is signature because the fraud proof needs to check the signatures optimistic rope ends up including a

whole bunch of signatures this ends up being the big this is the big cost because i say a signature an easy dsa signature is like it's a it's big um especially when you have one per transaction so that's the optimistic role of diff uh let me do the zkd so the key thing of the zk div is that we just don't have the signature because the signature is checked inside the zkp the zkp is like implicit proof that the signature exists data

so because of that ck roll-ups can scale a bit more than optimistic roll-ups because they they just have to pull a lot less data on chain uh and that's been one of the like key features of zk rods for the last while or key like selling points that like the transaction cost is just a lot lower but there is some optimizations that we can do to make optimistic follow-ups and zk roll-ups equivalent so let's talk about them so this is the signature when we use ecdsa this is when we use the cdsa signature scheme but if we use bls signature

bls is just another kind of signature scheme but bls signatures can be compressed so basically we use vls signatures we can just get rid of all of this uh the signatures basically goes away and the call data cost becomes equivalent to physique rob so like the weaver project called bls wallet yeah that that that uses bls image replaces ecdsa with bls signatures so that like we're able to so optimistic roles and dk robs can have the same like transactions per second uh let me check the time okay any questions so far nice okay let's talk about some security

so like a lot of the the ethereum community has been worried about the like bridge security of layer two and like i think that like bridge security is like an important thing and i think that before we discuss bridge security for optimistic roll ups or zk roll ups we should first discuss great securities from one bring security from one chain to another so let's let's talk about that is there i'm gonna clean something is it okay if i clean this one okay so read security okay so let's say

we have like two chains chain one and chain two and they like want to talk to each other when they're trying to talk to each other like how can we make one understand the other well like what we talked about already is like oh can we have a fraud proof to let them talk to each other and the answer is basically no we can't and like we can't have a fraud proof chain and one and chain two have their

own consensus mechanism sometimes those consensus mechanisms change like sometimes we have like hard fork uh where like one chain will start to change its behavior other times we might have some sometimes we have a hard fork and like when a hard fork happens it's impossible for like chain one would have to like if chain two hired four chain one would need to also hide fork in order to be able to continue to support it so we're not able to have a frog proof and we're not able to have a zk proof because like these bridges wouldn't really be upgradable i think that like we could have one that would work for like a short amount of time but later the the connection might might be broken if it

was a hard fork the other kind of big issue when you try to have bridges is the consensus like you can have a bunch of different valid consensuses on the other side and it's impossible to tell which one is actually correct but like okay so let me give you an example of this let's say that there's like a 51 attack for a censorship attack like there's been some talk in the theory briefly about censorship attacks and basically the defense against a censorship attack is a user activated hard fork and and the way that that would happen is that the users on ethereum will basically say okay so let's talk let's describe the censorship attack a little bit so let's say that like in we're on

ethereum we're in proof of stake world we have like users on we have like stakers on are having a bit of a disagreement these takers are saying that like if this is the valid state this is a valid state but like a whole bunch of other stakers are saying no this is a valid state these takers are saying that this is the valid state i'm like what is the difference between these two states well this one includes transactions to a certain smart contract and this one doesn't i'm like what happens if this side has

more of the stake this is like 60 percent of the sake like the rules of the consensus algorithm basically say that like these people are in charge they're able to censor whatever transactions they want and the other group isn't able to really defend itself but like that's not the word that's not what ethereum is though i mean like ethereum is like defined by the ethereum community and like if the ethereum community wanted to say that like these are this is the actual valid ethereum that's that's their right to choose like

they're the people who who need to make that decision not like whoever happens to have 60 percent of of the ethereum state stake so basically what would happen is that like we would have a user activated hard fork where all of the users of ethereum would say that like this is the new valid ethereum this is a new one and like this is a very important defense mechanism for blockchains they need to be able to have this mechanism to upgrade so that like if there is an attack if there's a censorship attack we're able to like coordinate a recovery or a a recovery can be re coordinated by the community uh by the users of the system and they

they can basically say that like these these people just lose their money and everyone else just keeps going so like this is this is what we think about when this is this is this is like one thing you need to think about when you're thinking about trying to build a bridge from one chain to another because like when we're trying to build a bridge like how can your bridge capture these new ones of like this is the new valid state or this is a nevada state so that's what make bridges really difficult because you can't have zkp's and you kind of brought proofs so what people end up doing is is they come up with like multi-sig bridges and things like that and multisig bridges are like inherently centralized and because they're inherently centralized they're

easy to hack right they they end up getting hacked a lot there's been a lot a lot of news about like different different bridges getting hacked and like a lot of money getting stolen from them that this problem is just really hard because it's trying to connect together like this very the system that's not just like the rules of ethereum it's like the rules of ethereum plus like all of the ethereum community and its beliefs and philosophy like that's really hard to encapsulate yeah that's really hard to encapsulate yeah so it's really hard so people end

up making multisig bridges which end up getting hacked a lot and that makes people think that like all all bridges even layer two bridges are inherently vulnerable to these kind of attacks but that's not true so let's talk about like layer two bridges so let's talk about layer 2 bridge ah so hold on is there any questions so far so let's talk about layer two bridge a layer two bridge is is is very

different because it's not like one chain talking to another it's like inside ethereum we have like a smart contract that has uh state but it also has like a fraud proof or zkp that proves i like the state is correct because both of these things are true your withdrawal mechanism can just be a proof of about this state it can just be approved

like in state this i took 100 usd and i send it to the withdrawal i took 100 usd and i sent it to the withdrawal contract and then we have a separate contract that just lets you that just lets you withdraw that money so this is fine because anyone is able to make this proof that like this transaction came came that this transaction is valid so everyone is able to every everyone knows the state everyone knows the state so

everyone is able to make the state proof and anyone is able to withdraw their money so this is this is what makes like layer twos decentralized this is what makes layered tubes inherit their security from ethereum but the key thing to remember is that in order for everyone to know this state we need to make sure that this div is published that's the reason why we publish the diff and the call data so that we're able to build these process bridges so that users are able to withdraw whenever they want yeah yeah okay so let me let me draw a little bit more clear here so this is

like l1 this is l2 l1 and l2 so like the this actually should this is actually part of l1 as well this is a separate contract so this is part of l12 this is just like another contract from one yeah that's how the withdrawal works the deposit happens in a similar way that like instead of instead of the proof going instead of the state coming here you have like a message bridge that like passes the message from l1 to l2 so this is why we can build like trustless layer 2 bridges and this is like the whole point of like publishing

the cold data uh the point of publishing the cold data is that like anyone is able to withdraw unilaterally whenever they want so if there's like a censorship attack on a layer two people are able to ah that's a good thing to talk about well wait questions okay great um let's recap so far we've talked about what layer twos are how they work

what like a a crawl chain bridges how that works how to build like a trussless layer two bridge and we also talked a little bit about like consensus layer like censorship attacks on layer one but now let's talk about a censorship attack on layer two and let's consider like the implications of that can i delete this one sure um

so the question is am i implying that l1 to l2 bridges are more secure and censorship resistant than than l1 to l1 bridges yes yeah so one two side chain yeah yeah so l1 decide gene is the same as l1 to l1 so like at least in my definition um yes i am yeah that's exactly what i'm saying yeah that like l1 to l2 bridges are inherently more secure because we have a fraud proof and we have data availability guarantees that are all coming from the same place all of those guarantees are coming layer because of that if we have like some

censorship attack or something like that the layer one will automatically update to change to change like when that layer is fixed the layer twos will inherit that effect the liquidity problem right so like okay so basically okay sorry sorry let me repeat your question so the question is how can we connect layer one to layer two especially the liquidity problem right so connecting layer one to layer two is relatively easy like you can just do the positive withdrawal bridges like

as i defined already the liquidity problem that you that you're talking about is is that like optimistic roll-ups have a delay period when you withdraw and basically the delay period is there in order to prevent in order to give time for someone to submit a fraud proof for like some invalid uh invalid block because of this is a delay period and the delay period is it means that like there's a liquidity problem that i deposit into optimistic roll up and make a transaction and then i have to wait a couple of days in order to be able to withdraw that's a liquidity problem and like there is some ways to solve that like we can have bridges that are more

complicated that allow people to like up front give you the money to withdraw and for a slight fee the other ideas are like you will just have optimistic roll-ups that are evm compatible so you can do as much stuff inside as you possibly you can do most of the stuff you want to do inside but there is always going to be this delay period for optimistic rollover that's another argument for why like zk roll-ups are are better but i think that bowls are good and like it's important that we pursue both approaches uh because it's important we pursue both approaches because like number one we need diversity in the ecosystem and number

two i think that the approaches that will be the most secure are hybrid systems where there's a zk and an combined so there's a fraud proof and a zkp and like i think that that will be much i think that that would be the most secure the most secure layer two it's something that has both because like it will be like both would need to be broken in order like both would need to be broken in order for for for for the system to break so so yeah i think hybrid systems are make a lot of sense layer two censorship let's talk about okay so we talked about layer one

already we talked about like censorship tax on there one let's talk about censorship attacks on layer two uh so we have our layer two and we have a set of people who are able to make blogs and we have some mag we have some oh there's some there's some rule for for these people to be able to make the box what they do is they they make blocks every once in a while this is s1 this is s2 state 1 say 2 and this is just what they do it's just these set of people who are able to do it okay so how do we decide who these

people are that's our first question that we need to think about so like like when we're talking about layer one the way that we decide who these people are is with proof of stake but the issue is that proof of sake of layer one sorry let me slow down so i think that proof of stake on layer one makes a lot of sense because we can always have a user update a user activated hard fork in order in order to be able to continue the system in order to recover from censorship attacks we can't have such a fork on layer two right because like that would basically

mean that like a layer two would have to ask layer one to have a hard fork in order to fix that layer two and that seems like it might be difficult to do it might be difficult it's very difficult to get a theorem to hard fork unless it's like some very serious problem with like the layer one it's like either historically not hard forked to fix broken contracts and like i think that they would view like a broken l2 as like just another broken contract that's the that's the concern of like having proof of stake as like the way to decide who's who's in charge of the layer there is a bunch of other mechanisms

that we can use i'm not going to talk about those today but what i am going to talk about is like some things that we can do to mitigate the power of these people so the first thing that we can do to mitigate the power of these people is to have this concept of like forced transactions so that's basically something that like it's a mechanism so that on l1 you can submit a transaction that these people have to include so it's like forced so you can do that when there's like some kind of censorship attack you can submit a transaction that that they're forced to include the extreme case of this is that like if they don't include that transaction the

whole roll up stops because there's no way for it to continue and like the more extreme version of this is like if if if if they don't include a transaction the roll-up stops and like they're not able to make they just lose their position and someone else comes can come forward and like continue to make this is another reason why we want to publish the call data because if the call data is published then if the call data is not published it's not possible to replace these people because you won't you won't have the the state of the system if you don't have the state of the system you're not able to like continue to update the system so that's that's defense number one is

forced transactions so like what are some limitations of this like some of the limitations of this is that like you can force transactions and like mostly what people would do like you can force transactions but forcing transactions is more expensive than than just having transactions included naturally the reason it's more expensive is because you need to do like a single on chain transaction in order to force a transaction and that's that's hard to do uh that's expensive too there is some ways that we can optimize it but like it'll alway it will always be like slightly more expensive because you will need to do a little bit of extra engine work

yeah because of that it'll be a little bit more expensive so the other problem is that like so so like probably what will happen is that like if a layer two was broken i would draw all of my money i'll just say sorry if a layer two has a censorship attack where the block producers are refusing to create blocks i will create a withdrawal transaction that says i'll create a forced transaction that's a withdrawal and i'll just say oh i want my money i'm going to go to some other role that's a monthly goal uh but this is this is not good this is not good because like number one it's very expensive i need to withdraw from layer from layer two and deposit into another layer two i need to do a

force transaction on layer one and i have to do at least one layer one transaction to move my money from from one layer two to another and that's just going to be super expensive and it's especially going to be super expensive when we get to a point where we have millions of users on a layer two not only will it be super expensive it will be just practically impossible for those people to to move to another layer too so because of that we really need to be careful about leader election on there too because there's this like natural monopoly effect of like when a layer 2 gets big the the the people in charge of making blocks become very powerful the people in charge of making bots

become very powerful so this is something that we need to be very careful about any questions so far cool okay yeah so we have our force transactions which is kind of like this this exit feature we could also have something that's like much cheaper force transactions it might be possible to make a forced transaction that's that doesn't require you to do an l1 transaction in order to move from one uh layer or two to another layer like maybe we'll be able to kind of join

them together by making some kind of specialist withdrawal mechanism i'm not sure so it's like a layer too just for force yeah exactly yeah okay um yeah i think i'm getting to the end of like what i had prepared like is there specific problems that people want to talk about or is there questions that people have why ethereum decide to switch from po dub to pos

okay so the question is if we can move to to layer two why did people switch from proof of work to mistake yep right so there's a couple of reasons uh number one it provides better better user ownership of the network when we talked about like user activated soft forks a lot easier to do with proof-of-stake and it's practically impossible to do with proof-of-work because like in that case the people who are making blocks like okay it is possible to do with proof of work that's true you can just like revert a whole bunch of transactions but like the ability to finalize is dependent upon like your

like how much computational power you have or capacity you have so like because of that i think that like proof of stake is sort of moving a little bit more towards like more people having access to the ability to be a block producer and validator but that said it still is very limiting because like in order to be a proof of in order to do proof of stake you need to have like a whole bunch of ease you need to have like 32 which might be like prohibitively expensive for for the majority of the people in the world like we want to get to a point where like everyone is able to stake but it seems like that might be a barrier to people in the short term um so like basically we moved to proof

of work because of the security improvements and also because of the ecological impacts that like proof of proof of proof of work was just very it's using a lot of energy which we could probably use for more more better so like that was the other major reason that i thought that we moved to work other people have different perspectives on this and i'm i don't work very closely with proof of stake i i understand it like roughly how it works but i'm not i'm not an expert on that that's my that's my take okay thanks is moving from proofwork to the proof

stack in ethereum and atm 2.0 there will be like about 64 sharks right oh no so i think that that part is being deprecated so i i think that like ethereum has moved to the like roll-up-centric road map and the idea is that instead of having different shares to do execution you just have like data availability like so the plan is that like we're gonna do the merge and after the merge we're gonna do four it be four four ip4844 and basically what ap484 does is it just gives you this massive data availability layer so like you're able to make like megabits of data available per second

and like when we do that we're going to be able to have roll-ups that can support millions of users it's going to be really really cheap to make these transactions like that's the plan it it drastically simplifies ethereum's roadmap because instead of having to have instead of having to have like execution as part of layer one layer one becomes really really simple layer one becomes uh layer one one becomes just like zkp their one just becomes about data availability or not and that's all that it really is about at that point yeah so so that's that simplifies a lot to layer one and that allows for a lot

more innovation on layer two to make like more efficient execution engines or or different ways of building roll-ups with better user experience or guarantees or censorship resistance and those kind of things so as we know that the layer one blockchain we we are paid by forecast three for for the blockchain how about layer two layer two was the revenue from the for the player too ah so like layer twos can have transaction fees as well like my hope is that like layer two will be so cheap that like transaction piece will be almost nothing or that's like there will be no need to pay transactions there you can just do transactions

yeah like i think i think we want to get it to a place where like users don't have to worry about gas yes as i know that almost the layer 2 domain token native for for the gas free and they can make the revenue from that what what see the revenue come from for for the other source oh i'm not sure about like the the like i think that like you can take these from users making transactions that should be enough to pay for the for the gas cost of the call data and things like that i think that that's i think that that's already enough to be like yeah i don't know what the business

model is of like getting more revenue i suppose i suppose that like probably what the business model of the lyric is that like oh we just want to be we want to be these people so we can do like very mild censorship attacks and and and just kind of like force users to pay higher fees i i feel like that's the longer term the longer term like extractive model of a layer two but like my hope is that like when that kind of thing does happen that like we'll have we'll have ways for people to migrate to other layer tubes if they want to uh but yeah that's definitely an issue or a concern that like these layer twos might become too sort of like revenue driven

and we need to be careful to make sure that like we can recover from states where that happens okay sure so i just wrote back a little bit of what you were saying about the layer one application after you know we applied the sake roll-up and like ultimate uh optimistic roll-up uh you know mechanism that it only you know showing the divs right or the blockchain and then we don't really have to storage anything on the blockchain that's why it will reduce a lot of cost for that later one is that what you're saying yeah okay okay cool yeah that's that's it that's a key

recognition that like number one you do a lot less execution but actually the most expensive thing about most smart contracts is storage yeah but like call data is not stored but yeah yeah call data is just kind of put there you like most roll-ups you end up do storing one thing you store like the latest merkle roof sometimes you store like withdrawals and deposits but they're very very rare yeah no worries so sorry your question is like in the future ethereum will have a proof of replication uh proof of application for call that yeah yeah i

think they will yeah so so basically like a proof of replication is just making sure that like the data is available in more than one source or people have like many copies of the data i i i'm not sure exactly what the research plans are there but like yeah there's definitely some thoughts about like having these incentives to make sure that like the data has been replicated yeah no and like there's yeah there's some fun zkp things that we can do there i think i'm not too up to date on the latest research there but that does seem interesting okay time to wrap up the first workshop of vietnam today and thank you very much thank you very

much for the to do the amazing workshop and also like me like not a technical person but i also can follow the you know step by step so i know like after that also they can follow and learn a lot also um so today actually we over time about 13 minutes already but we we should wrap up now because like we also have another like more technical and more deep um workshop tomorrow so uh please please like you know bring the laptop tomorrow so we also like kind of do some challenge and exercise tomorrow big berry and also after this workshop we will i send all of you the become uh we also have the video and also have the

link for the feedback so welcome for all your feedback and then we also hope that we can do better for the next next coming workshop and by the way that we still have the cakes and the coffee and tea outside like you know a safer one and we can go around and then do you know you know like talk to each other and then hope to see all of you guys tomorrow thank you so much yeah of course