IRL Workshop: Build on Ethereum, Hanoi Day 1

ETH Vietnam Talks · 25 Aug 2022 · 2:17:18

Barry Whitehat of the Ethereum Foundation teaches the first day of the in-person Build on Ethereum workshop in Hanoi. The long hands-on session introduces developers to building applications on Ethereum, and is followed by a second day. It is a long session.

Speakers

Topics

From ETH Vietnam Talks, hosted by ETH Vietnam.

Transcript

out and meet up with you guys after this workshop to understand more about what you're doing and about the project that you're building and we'd like to also introduce the ethereum foundation mentor speaker and also from the this meetup today firstly very white hat um please give a big plus for barry and this thing over there yes also from from interim foundation and we also have current from singapore women's blockchain and will also come here to support for this workshop and thank you very much for your presence today thank you kaiba team support us you know because like we do

it super last minutes to be honest but thanks for that support we make it happen very quickly um so you know like if vietnam is a siri at the workshop and event from now from august until the main event in november 25th to 27th and the purpose of this kind of workshop you know we want to connect the local dev team and also the global depth teams and other you know projects especially on each room foundation and interim ecosystem and the content focus on layer 2 also so that's why you know like also we have the first workshop with mary whitehead his support and also a focus on zkp

and if you want to look in for more information about the workshop we have the website eat vietnam and also discord telegram community will send you up to this workshop with all the recap video so you can check it out later and now i get back to barry whitehead for the workshop thank you so much [Applause] thank you quinn um is there a thing for the slides uh for the slide whenever you need to next i'll tell you yeah he will he will do okay and also the laptop

oh it's here just in case you need something okay oh okay all right thanks everybody for coming uh while we're getting the slide set up i wanted to kind of try and get a idea of people's backgrounds like uh who is here today to learn about or like who is primarily interested in in scaling could you raise your hands okay okay and and and who who is primarily interested in privacy okay cool and like

who is interested in making like applications as opposed to like doing like okay all right okay uh okay let me get started [Music] yeah so like i wanted to talk today about like quadratic funding and how it can be how it's an important tool to us for us to like not only kind of show not only to like better support the ecosystem in a in a neutral way but it's also really useful because it it kind of helps us to deal with like some of the some of them it kind of helps us to show our values to the rest of the world that like at the moment there's a lot of

uh talk about cryptocurrency and scams and like speculation and nfts and like this is this is this is quite frustrating because it feels like we're we're sort of missing some of the some of the the point of like why we're all interested in this space that like and like it's hard when the community is sort of growing that like when more people are joining we want to sort of share with them like our values and what we think is important like one thing that i think we all think is very important is is for us to be able to like support public goods or to to have like some neutral mechanism to support public goods and like this is like a use case that's like a

lot less controversial than the ones that were more used than like nfts and fi it's just basically like people just getting together to fund and support projects that they're interested in uh who here has used that quadratic funding before uh maybe via bitcoin grants or or something some other sure yeah should i start again should i go back to the start no need okay okay cool so um yeah so one one of our priorities is to try and make these other types of use cases

happen so like one thing i wanted to see is like did have some people here like are familiar with quadratic funding or quadratic voting like maybe you use that with git coin or maybe you use that for the recent like eat sticker quadratic funding round has anyone used that before i'll introduce that in a minute like one of the so there's a whole bunch of different tools that we use to do quadratic funding and like one of them is is called macy amazing stands for minimal uh

anti-collusion infrastructure and basically like a big problem with quadratic voting and quadratic funding is that there's this issue of bribery like you're able to like trustlessly bribe other people to vote in a way that that that you want them to vote and and this turns out to be like very like it it makes a lot of like economic sense to do this which we'll get into in a minute okay so before i talk about macy a little bit let me talk about quadratic funding so like quadratic quadratic money is kind of like a mixture of voting and it's kind of a mixture of voting and and donating so basically the idea is

that like we all get together and we want to fund a bunch of like public goods and like public goods can be so the definition of a public good is basically something that like that is like beneficial to everybody for example software is an example of a public good or open source softwares and like i think that a public good is something where you where you you're not able to say who benefits from it for example like if i can say that like you get it you get it you get it you don't get it and it's not a public code because i have control over it but like something like the linux kernel is an example of like an out-and-out public good because you just publish it and then everyone is able to get the benefit of that so like open source software is an example of a

public good and like we've been spending a lot of time trying to figure out how we're better able to fund and support public goods because like that's one thing that the ethereum foundation spends a lot of time doing is to like give grants to the ecosystem and try to support these different kind of public infrastructure and initiatives so well let's think about a little bit about the sort of tragedy of the commons and why these these these public goods don't get funded in the first place like basically the tragedy of the commons is basically that like if something is going to be beneficial to everybody why do i need to be the one to fund it right because everybody sort of says

this to themselves and they say oh well everyone's going to benefit from it i'm not going to support it right and and this is this is a tragedy right because it it really benefits everybody but like nobody wants to be the one to to support it so like quadratic funding is a way to sort of bypass this mechanism and what we do is we say that like we'll make it worth your while to donate the things that's about that's valuable to you because not only will your donation count but we'll give you like an extra magic amount every every time time you donate we'll give more so that like that that kind of breaks this sort of tragedy of the comments problem because like when you want to support some public good you you feel a bit

better about doing it because it's not just you who's donating you're getting the matching funds from someone else this is basically what quadratic funding is it's like this idea of matching and like the reason we call it quadratic is that like we match quadratically so if you give a little bit we give a little bit no if you give a lot we give a little bit if you give a little bit we give a lot and like the idea here is that we want to give more to things that like many people want as opposed to we want to get yeah so we give more to things a lot of people want and we give less the things that like only a few people want and that's how it's kind of like that's the piece that's sort of like voting things that are very popular tend to get a lot

of money and things that are not very popular tend to get not not a lot of money yeah exactly so it's a system to allocate resources more efficiently yeah that's that's that's that's 100 world-class moving games yeah so so like that's that's actually a great summary thank you for that right so so that's what we want to do we want to make a system to allocate resources more efficiently but the problem is that when we try to make a system to allocate resources very efficient or more efficiently there's always this issue of bribery because if we're able to allocate resources efficiently people are always able to to kind of mess with us that system and break that

system basically what they can do is they can say i will bribe you in order to donate to this calls instead of this other cause i'll give you all the money that you need to donate and you just need to donate for me and like in that case that kind of corruption really breaks this system because we we we we've designed this thing that like lets us efficiently support public goods but like bribery from outside the system is able to break it so corruption corruption corruption exactly yeah yeah corruption is a big problem yeah so so like this system kind of makes it impossible to to for for corruption to affect the

result of this kind of like uh system right yeah so how do we do that how can we prevent corruption so the first thing that we basically okay so let's think about how corruption works so if i want to corrupt somebody i basically need to tell them oh if you do this i'll give you this in return i'll give you this much money this arrangement is based upon that like if you do this then i'll do this what the way that macy works the way that we make it impossible to to to to

corrupt people or to bribe people is is we make it impossible to prove if you actually did what you claimed you would do that's that's that that's like the key of like how this all works and we're going to get into that in a uh we're probably going to get into like how we achieve that later but like on a high level what we do is we use your knowledge groups you know and this kind of like encryption to make it impossible to see exactly exactly what any one person did but we'll get into that later in the second half on the whiteboard we'll start to explore yeah so so like okay sorry

yeah so basically what we're saying here is that we make it impossible to prove how you voted and then or we make it possible to do to prove that you did what you were bribed to do and therefore a driver can never trust you because you can't prove it to them you don't have a some sort of evidence to show that i did what what we asked okay so like when i first started working on this i was unsure whether like bribery was really that big of a problem for like these unchained voting systems because like my intuition was that like well i've seen voting systems a lot and

it's very rare for bribery to really be an issue there and and i think that that was because the systems that i saw were all off-chain uh all of the yeah this isn't that i saw all off chain it was all sorry one second uh yeah so the system that i saw were all chain it was basically like paper and pen ballots you would go and you would vote and you would put it in the box and like those kind of systems it's really hard to write people because it involves a lot of work right you have

to go and find the person you're going to bribe and you have to ask them and you have to find a way to trust each other that like i am actually going to bribe you and you're going to do what you're going to what you you're going to do what you say you're going to do and like and then i just have to repeat that for many many other people like this seems like all in the all-chain world bribery is just like prohibitively expensive because it's just like so much work to go and find people and then to actually execute the bribe and the other thing is that like if people find out that i'm trying to run this like massive bribery campaign in the middle of a of like some kind of voting that could affect the result of the vote i could

get in trouble it seems like that's just going to be really really difficult to set up and to pull off actually people can just like the on-chain approach like somebody going to try to build the app and also allow people to use that app toolbox the d2 problem is i think it's the same if you're using the approach sure so let me just repeat what you said just for the live stream so i mean that adversary is going to use the

the same mechanism they build apps enough and allow people to use that app to vote in option the problem is uh will be the same for two cases oh you think so like the problem with the so let me repeat just to make sure i understand what you're saying so basically you're saying yeah but like in the old chain voting context an attacker could just make an app and like incentivize people to to bribe so they would go and they would vote and they would take a picture of their vote and they would submit that in the app and then they would be able to get bribed is that is that what you're saying yeah they're going to building up like an app to buy the

people right yeah that's yeah i i see what you're saying i i think that like if i built that app i would i would be really worried that people would be kind of like pretending to get bribed right because i don't really have a way for them to prove to me that they got bribed or not like all they could do is like like i'm worried that people with like some kind of film background or something would would kind of forge the the ballot and scenario and they would kind of take a picture and they would submit that to the app in the all chain voting context there's there's no way for someone to to like

prove that they did or didn't get bribed or they did or they didn't do what you want them to do sorry so the question is what is the meaning of blockchain yeah so offchain isn't isn't the cryptographic signature of chain is like just like paper and pen ballots that was the example that i was using i think that like maybe you understood that off-chain was like just signatures that weren't verified and changed okay okay again okay my apologies yeah yeah you can just keep that and give it

to someone else if they have a question okay cool um right so that's where they all change voting context but like when we start to move things on chain uh or when we start to have cryptographic signatures associated with our votes what you're saying it becomes a lot more easy to do right because you just like in that case all you need to do to bribe someone is have have you can make a smart contract that does that right a smart contract that basically just pays if you send a signature uh that's folding in a certain way like that's that's my kind of bigger concern here that like when we if we

start to move voting on chain that it can become it can become like it can become really easily corrupted that like that was kind of one thing that was sort of difficult for me to grasp when i first started working on this project because when i first started working on this project i didn't really see that like all chain voting is like considerably easier or safer than than on chain molding especially because you you have this concept of receipt freeness that you you're not able to prove to anyone how you voted because all you can do is take a picture of your paper ballot and send that but you can always like photoshop or whatever make a deep fake of the photo it seems like there's a bunch of

different ways that we could that we could like attack or trick a driver who's trying to bribe us my my larger point here on this side is is to say that like we have to be careful when we build these unchained systems because bribery will become a serious problem i think that it's just it's just a matter like we've already seen some like governance attacks against taos where people were like bribed the vote in a certain way and like corruption and things like that seem to be coming like more and more pressing issues when we think about daos yeah so in order to be able to scale our

own chain voting we need to be careful to to account for these problems ah thank you yeah so i already talked about this a little bit a little bit when i was talking about quarterly folding well let me or quadratic funding but let me go through this again um so like the question here is like why quadratic funding like why is that important or why is that better than just regular voting and like one argument is that like when you're doing like a regular vote there's no so so there's all these arguments why it doesn't make sense for people to participate one of the one of the arguments is basically like i am one of a person who

lives in a country with 19 million people my vote is basically meaningless there's no way for me to affect the out the outcome of the of the of the vote that's that's one thing where where it's it's it it it doesn't really make a lot of sense for people to participate so like with quadratic funding it's slightly different with quadratic funding we're able to we were able to give people like who really care about issues the chance to express themselves and or or who people who really care about funding public goods a chance to express the politicals that they really care about

and basically the way that this works is is that like we we force people to to donate in order to be able to to signal how much something is worth to them and that that's kind of like put your money where your mouth is kind of kind of thinking where like if i'm gonna donate like two dollars or something that that's that's a lot of signal from of how valuable that is to me we can make all these arguments about how like getting people to to to contribute money to things is a good way of seeing how much they value that thing because money is like scarce and they people are reluctant to spend money on things that are not valuable to them the final thing is that like when we

think about quadratic funding and talk about donating there's always this thinking that like well what will rich people have like a lot more impact on the actual result but the answer is that that won't happen because the the the matching funds are weighted quadratically if a rich person donates a hundred dollars they they get like a very small matching amount compared to someone who donates one for example someone who donates one dollar will get one dollar matching amount someone who donates 100 will get 10 matching amount and like it just scales like that the more you give the less that's actually going to be matched right okay so

that's quadratic funding the the way that i sort of think about quadratic funding and and how we can how it can help our world because i think about like having this like neutral and censorship resistance sort of hierarchy of different quadratic bonding rounds that are like happening all over the world on the same kind of cadence that like four times every year we have like a whole bunch of quadratic funding rounds one thing that like we didn't talk about yet is that like when we're doing a quadratic funding round we need to have like a proof of individuality uh and the reason that we need a proof of

individuality is that people need to because we have like because we have like one person every person is able to contribute just from one account we need to be able to limit the set of accounts that people have created and to do this we use like a proof of individuality ah so not necessarily so we can have like different kinds of proof of individuality like oh sorry sorry let me just repeat the question for the live stream so someone said so basically kyc and i said oh not exactly because we can have different kinds of

proof of individuality we can do kyc but we can also do like a bright id where you're where your social graph is indicating whether you're civil or not or else we can do some more advanced things with kind of zkp's like there's this really cool algorithm called eigentrust that allows you to calculate scores in like social networks similar to the way bright idea does it but in a private way so like there's a bunch of different uh proof of humanity proof of individuality algorithms that we can explore so it doesn't have to be like off-chain kyc we can have like other other examples for example like one thing that we could do is we could have like a quadratic funding round for east

vietnam and we could say anyone who attends east vietnam is a is an individual person and they're able to contribute could contribute to the round so like we can do things where like the proof of individuality is not really really strong but we can still have some like benefits we can still have some like pretty pretty good results with with those systems too like we don't have to be like 100 kyc in order to be absolutely certain that everyone is a individual human cool any other questions a long time before the last

uh death row io and then the hacker is going to get a github account to get the financial yeah so i i think that that's a problem with like proof of individuality rather than with quadratic funding but like what you're getting at i totally agree with proof of individuality is really hard it's really hard to have a way to be sure that like a a different person is actually a a an individual human being that like there has been attacks like that before and there will be in the future and i think that like we need to build

better proof of individuality systems and in the short term we should just be like adaptive when we're running these quadratic funding rounds if it's clear that someone signed up with like a million accounts we can we can adjust and change what we're doing i think that like probably what we should start doing is to start and start and build a system where it's impossible for an attacker to make more than 10 accounts and then start to go down and down until we get to the point where like it's also really hard because there's this trade-off of like how difficult is it for legitimate users to sign up and how this difficulties are for an attacker to fill up the whole state but like i totally agree with what you're saying like proof of individuality right now is not very advanced and that's something that we

really need to spend spend more time trying to improve cool yeah so any other questions questions so one of the key things we're trying to do with macy and qfi is to try and make it as easy as possible to run these rounds like what you're saying is like one part of that having like this easy kyc protocol or process in place is is very important yeah so like we're trying to start doing more of these rounds by doing like

uh uh just many local rounds around the world we did one in in barcelona we did one at east prague we did one in honduras and and like we're hoping to do more and more rounds in different places another thing that we need to do is improve the security of macy the quadratic folding system that i'm going to talk about later because security is such an important important uh requirement here we want to be in a position where we're able to run these rounds in like all kinds of different places around the world and in order to do that we need to be able to to have like more security and more confidence in the system that we're building yeah another thing that we need to do is like share and spread the idea of like

quadratic funding and why it's important or different why it's an important tool for communities to to kind of fund public goods cool yeah so that's our plan with this quadratic funding round uh incubator that we're running uh we've already run one round in in in honduras and we've done a couple of others maybe you all heard about the eid staker quadratic funding run this was a this is a funding round for the eatstaker community they're like people who run staking infrastructure and ethereum and we did a quadratic funding round in partnership with them in order to like support the local quadratic funding republicans

we're trying to do like some non-crypto focused rounds so far we we we've been exploring like different places that we could do with those that are not just about like the crypto stuff but also about like different kinds of things yeah so this is our plan for the rest of the year to sort of scale up the number of rounds that we're doing ah next slide yeah so okay let's start to think about like the the amazing stuff that we want to do so let me briefly describe how how amazing works and then then we can talk about some of the improvements that we can make all right

okay so now is a now is the zkp stuff so we finished finished all of the preparation right so okay it seems like it's a hard problem we want we have this system where we want people to be able to vote but we also want it to be impossible for them to show other people how they voted how can how can we do this it seems like okay so these are the people who who want to vote i suppose that this is their votes then we have this this role of like a coordinator and the coordinator kind of takes the

volts and decrypts them so the coordinator takes the votes and decrypts them and from there we kind of like process the votes into a merkle tree after the coordinator processes all the votes they do the like tally step where they calculate the result and share it okay cool so like when someone is voting what are they what are they able to do so they there's two actions that a user is able to take the first action is

they're able to vote and the second action the second action is they were able to like update their public key they're able to update their public key okay so so like basically we maintain this merkle tree of all of the different public keys the user is able to all of the different public keys of each user so each user has a leaf inside this tree when they update their when they update any given leave we give them okay so we have work on root here

so so this is this this is the state of the system at the server so each user is has like a single leap inside this tree which is like their public key um i'm gonna hold on let me just draw this a little bit bigger okay so in this system everyone has a public

everyone has a public key that's associated with their leave so each user in the system has has a different leave in this tree when when the user wants to update wants to make a vote or command they they sign their vote and then they encrypt the signature of their vote so we have this encrypted vote we have an encrypted vote that gets passed to the coordinator so the coordinator then creates a zkp that they've done a whole bunch of different things the first thing they do in the zkp is they decrypt it they decrypt the the encrypted

the encrypted vote or command when when they decrypt it inside the zkp and then they update the leaf according to the rules of according to what that command says and we prove all of this insight is ekp yeah we prove all of this inside zkp what what do we prove so we improve the decryption and we improve the tree update and that's it this this is this is what's happening inside our insider zkb

and like let's think about the situation where there's a there's a driver who wants to wants to bribe a user so we have our user here this is our user okay this is our user they created a boat and this is there's a there's a driver who's kind of like observing survivor here is who's observing the vault that might not change in this situation is there is there any way for the briber or is it is there any way for the user to

convince the driver that they bribed in a certain way or that they voted in a certain way they can show something like if they know the leaf they can try to open it so they don't know the least so so like sorry let me repeat for the live stream so so like uh uh nam said that oh if they if they know the tree they can open the tree they can just show them that like this is my vote can i have my bride please and like that's true uh but they don't know the tree that's the only person who knows the tree is the coordinator only the coordinator knows all of the leaves inside the tree and so it's so it's hidden from the

users the users are unable to to show what's inside is there why does the user need to update the public key so ah so the user can the user has two options oh sorry the question is why does the user need to update the public key the user has two options they can vote or they can update the public key we give the option to update the public key in order to prevent bribery which will like we'll get into that in a little while there's still a couple of steps first before we get there um there's like a couple of other attacks first that we have to kind of solve and then we can solve that one uh any other ideas about about like how

the driver can successfully bribe the user here sorry well sorry that's too loud yeah that's a very good point and that's a that's a very important attack that like one thing that one wave that the bribe could succeed is that instead of voting here they could do the update public key they could do the update public key for the user and when they update the public key they just set the public key to the public key of the briber

but like my question to you is that how does the bribery know that the public key has been updated correctly right because remember the user and the briber they don't know the state of the street they don't know all the details inside the tree but there is a way for them to know so what does the writer can access here so right which one right so the driver can see all the encrypted messages i can put on chain they can't see the stream they they can't see like inside the zkp when they can't see the tree

all that they can see is the the list of encrypted messages so i assume that the user use the coordinator's keypad to entry yes so he can just show the all the randomness you have with the encryption and the driver can pull the encryption itself and check that so so the the first thing that we can do is that the who wants to be bribed can show the plain text to the briber and then the briber will be able to encrypt the plain text for the coordinator's public

key and see that that's actually the text that was included so that's does that make sense so like let me just repeat just once more so so the idea here let me let me draw it because it'll be it'll be nice so we have two people here we have the user and we have the briber what has this this command right and the and the user wants to and the user just encrypts this command

for the coordinators for the key they encrypt the command for the coordinator and they get out this like kind of like encrypted cyber text that's really difficult to read for anybody else so the user who wants to be bribed what they do is they share this with the primer they share this plain text and they tell the briber i encrypted this for the coordinator if you do the same thing the result will be the same and you can believe me so they do the coordinator take the the driver takes the coordinator for the key they do the encryption and they find out

oh yeah it's exactly the same i know the text that they have encrypted for the coordinator any questions so far do the encryption actually necessary what people try to um sorry could you say that again that is using the blind so let me repeat just to make sure i

understand what you're saying so the user is using the blind signature to vote so so like what do you mean by blind signature is that like the the text that gets encrypted it doesn't need to be encrypted oh so so basically you're saying well we don't need to encrypt the ciphertext because it's basically meaningless here right there's no point in encrypting the ciphertext because you can always give it to a briber and they can encrypt it as well you can always show on bribery that look this is my cipher text see this is how i voted and like that's

a very that's a very good point the reason why we need the encryption is for the next step so so far we've been operating in a system where we had just a single voter we just had a single encrypted message on chain but in reality we'll have many different encrypted messages on chain so this is message one this is message two message three message four

let's take message four this is message four it came from this user here message four came from our user who wants to be bribed and the user who sent message four basically says to the briber he tries to repeat the argument we've made already he basically says to the coordinator hey look here's my plain text you can take this plain text and encrypt it exactly the same and you'll see that my message in message 4 is valid

you can see exactly what i've done at message4 and they'll give this to the coordinator and the quarter coordinate or they'll give this to the driver and the driver will say oh but i don't i don't believe you and like does anyone know why the coordinate or the briber wouldn't be able to believe them in this context ah exactly this message comes first this message comes second this is third this is fourth when we're when the the coordinator is processing this message these three messages have already been processed so it goes like this so this is the order in which they get

processed so i see where what you're getting at here the reason that the driver could never believe the the user in this case is that the briber doesn't know what happened here the user could have submitted a message here that that that made the final message invalid right because we have this ability to update the public key right so any one of these messages could have been public key updates yeah okay let me check the time okay cool um yeah but that can't

open all these yeah he can but he's not he didn't make all these messages like this is this is these messages are coming from other users yeah basically the user cannot prove to the brand that these are all my messages i have no other messages okay yeah so like as soon as you have like a single message on chain that can't be decrypted then the briber can't trust the user anymore like if all of these messages were from then they could have a trusses bribe but because they're not from the user there there's no way for the coordinator

to know which ones are which so basically that the user needs to secure them publicly also because if they leave the publicly to other one they they also put the same views up right so so basically your question is that like basically the user needs to like okay so like you're asking what if gives their public key to the or you're asking something else uh maybe this guy they know the the public key from the primary will give to me and then he also proved that that is not from him not from me okay so so like basically you're saying

like what if a user what if a user gets another public key from a different user and basically pretends to be that user and say hey i did this yeah i suppose i suppose that they could do that but like is that is that going to be a bribe or is that just going to be no maybe maybe they just want to prove to someone else maybe they they do another vote but they prove this one so that's an interesting i i see what you're getting at here and it's an interesting attack so basically the attack that you're saying let me just just i just to make sure i understand correctly

you you said that like okay i believe you in this context it's gonna be it's gonna be impossible for the user to convince the briber but what if the user just sells their public key to the briber what if they just say here's the public key here's my public key you can have this public key like could uh could the could the briber trust that is that is that what you're saying i i assume that someone else got the farmer and they want them to understand everything and then they just just put someone else i hope that's one but he did right so so like a user is trying to so

so like in this context the user gets someone else's public key and they basically take that public key and they use that to show the bribery hey i'm user number one this is my vote but like right they could do that but like why would the users share their public key with that no i mean that they also need to secure like so basically what you're saying is they need to secure the private key that's true they need to secure their private key if their private key gets leaked there a couple of different things can

happen you end up having this sort of race condition where let me let me draw a little bit so like we have to think about this in two contexts let's think about in the context of like first a user just loses their private key so a user loses their private key to them to themselves and to some attacker this user gets hacked both of these people are able to interact with the system and they're able to like change it in whatever way that they want

um the first thing that they can so so so you end up like there's a couple of different layers here the first thing to think about is that is like well who's going to be able to vote it seems like both of them are able to create like valid encrypted messages but it'll basically be a race a race whoever's message gets processed first will update the leaf in the tree and then that will be the final the final then the other user won't be able to so like both users uh do an update public key all the users try to update their public both users try to update their public

key they get the encrypted message they both go on jane and basically whichever one gets on chain first is gonna be is gonna be the valid one and the other one is gonna it's gonna not work but like one interesting thing to recognize here is that like in this case this user might never know that that

happened they might never know they got hacked they don't know the state of the tree they don't know they don't know what what kind of commands have been processed because they don't know what all the previous messages are so like we end up with this system where like you never know if you got hacked or not which is kind of scary especially if you're if you're voting on things or doing like big quadratic funding experiments so like and it seems like it would be nice to have a receipt but like as soon as you have a receipt then you're able to use that to get bribed so that's and like okay the other way that we need

to look at this attack is what if a user shares their public key with another user with a driver in this case it's just a using a hacker but like what if the the user like voluntarily gives their public key to a to a hacker or to a to a briber we thought about this before and like basically we said that like if at any point here you give your public key if you're any point after the first message you give your public key to a briber then the briber will never be able to believe you if it was there if it was actually a rather public view or not if they give it at the start at the sign

of time then it's possible for them to believe you right because they know that like no messages have been processed so this attack becomes quite serious and it's at sign of time it's when i'm joining the group i say oh i want to sell my uh account the credentials for my account you can take this and use this for whatever you want and the these credentials are basically given to the given to the briber and the driver the bribery kind of takes those credentials but they don't have certainty that they'll actually own the leaf of this the user and the coordinator both have

the public key in this context so they have this race condition so the the the user and the briber both have the public key so they have this like race condition where the user and the bribery are trying to compete in order to get their get their commands on uh so let's check the time yeah okay they can do that that's yeah there's two things to talk about there the ordering of transactions is not handled by the coordinator it's handled so like they wouldn't be able to bribe the coordinator uh they wouldn't be able to bribe the

coordinator they would only be they would have to bribe the like ethereum miners or whatever or sequencers or stakers whoever is ordering the transactions they would have to bribe them but they could do that the issue the other issue that we need to think about is right so we talked about all of these different attacks where the user was trying to attract the briber but what about if what about if the coordinate where a driver is trying to bribe the user but what about this coordinator person like wouldn't they be able to bribe the user because like basically they know the whole tree they know the whole state of the system and the answer is yes like the coordinator is able to bribe users and

like basically what we do is that we've broken it down such that there's only like a single person who's able to do this driving uh yeah sorry you said like there are three people no there's one person there's the coordinator yeah well i think the corner would have to work with the user but yeah yeah right so you can see that message

when you encrypt your vote you can see this message whichever message it is but you can never be like 100 confident that well you you can be 100 so the answer is yes you can see the question is like as a user so the question is like when you're using snapshot after you voted you can see your vote in this system can you do

the same no no no you can okay you can see okay so i suppose that you can you can see you can see this you can see what you've done but you can't see what other people have done that's enough yeah i think i think it's enough too yeah yeah i'm sorry it was a little bit complicated a minute ago i was trying to get at the nuance of like the system as a whole but like users can see their votes they know what they've done and they know they know yeah they know they know the what they've done ah that's another important question so

the question is can the coordinator change or remove your votes and the answer is no and that's why we use the zkp here the zkp here kind of prevents the coordinator from from like ignoring any votes or or not processing votes in the correct order so the zkp is is basically like limits the coordinator what they can do the only thing the coordinator can do is to refuse to reveal the final results yeah they can if like so there is some like annoying situations where like after the the round is done the coordinator is just basically like no i'm not going to reveal i'm not going to process all the votes i'm not going to

reveal the result but that seems like it's okay we could just do the round again it's just slightly annoying the divorce and then they they try to reject that and do not include no so they're not able to do that the votes are put on chain so there's a smart contract on chain if the coordinator wants to affect the the number of votes or the order in which they're processed they need to basically affect the ordering of transactions on on ethereum which is which is hard to do

like basically a censorship attack against this is a censorship attack against ethereum if you want to you know if you want to prevent users from participating yeah so like that's that's some of our yeah let's maybe we'll talk about that after the after the break right so like at the moment we don't have a ultra plunk uh ckp but like we're we're working on including it so let me let me let me talk about that after the break so we'll talk about some of the scaling challenges that we see when we're when we're dealing with this and we'll talk about like some of the things we can do

to improve it and like some of those things will be about ultra pump but it'll be very very little i'm afraid uh it'll be very little we're not going to go so deep on ultra punk stuff today yeah i have a question so right now is it the machine so yeah so like the question is like at the moment what is this coordinator yeah it's a machine it's it's just a it's just an aws or it's just a pretty beefy server because it has to make a lot of ckp's it's effectively like a person or a trusted entity um like someone has to run the server so like that's kind of where the trust comes from well yeah it's just a it's just a computer

if this machine is compromised there's no privacy uh yes but yeah there's a couple of ways that we can add privacy inside our system um and like the other thing we can do is when we're doing the proof of individuality sign up we can have zkp at the sign up time so users so you don't know like the connection between like a user and the actual votes uh but yeah privacy inside macy is is important what i mean is that like the decryption is done right so if you get the if you get the coordinator's private key you see all

the messages yeah you basically become the coordinator and you're able to write people like once you get the coordinator's private key you also know the state of the whole system wait let me think you don't know the state of the whole system because like we have this thing where like we have a special leaf in the tree and we have a random number there we we write a random number there all the time and like the reason every time we update the state and the reason that we do this is that like a lot of the time our commands fail a lot of the time a command is processed and like one of the checks that we're trying to make fails like a signature check and when that fails we don't update the merkle root the

merkle root stays the same and if the merkle root stays the same then an observer can see that like oh that didn't work that whatever happened here didn't work that just reduces the like number of messages that are that could potentially be other users doing things so in order to prevent that we write a random number to the tree to one leaf in the tree every single time you don't like if you hack the coordinator you get the private key you get the private key but you don't get the random number you don't know what the random number is so you don't know the like the rest of the state of the system but like that doesn't really matter you could tell bright people

though right because you know all of the valid messages and you're all the invalid ones you just don't know the tree but yeah okay that's uh yeah i mean basically if you get the private key right you can just reprocess the whole history yeah yeah yeah yeah once yeah if you get the private key you can proceed to history yeah so like basically i see this as less a private application and and it's more of a like a a way to have like bribery resistance i think that the privacy guarantees here are like a lot weaker than what we're used to like with like zkp's uh we're used to having a privacy of like you would you you have to mess up in order to use privacy but in this case like other people have to mess up which is not which is not as good

well i just think that privacy is important if you want to secretly yeah right so privacy and receipt freeness are inherently connected uh like this is kind of like a stronger case where you want to make it impossible to even show anyone you you want to be make it impossible to lose your privacy even if you want to just saying where you are yeah so the idea is to use sex or on the coordinator and yeah that'll that will definitely improve the security guarantees

but like yeah i i just don't like to build things that are like oh yeah intel's probably honest but yeah yeah no but that's it's definitely better than the status quo for sure yeah the status quo right now is just it's just a big server but yeah like the thing i would be concerned about making the proofs inside stx might be might be very i think i think expensive security of the company can depend on the user who the user going to send a message and how the user sends the message like if the user sending the

message direct to the terminator let me repeat so like what you said was basically the security of the coordinator depends upon where who is able to talk to the coordinator if the user is talking to the coordinator giving the messages it's bad because they have like access to the coordinator and like in an ideal world they shouldn't even know where the coordinator is yeah i totally agree so like in the status quo the user doesn't talk to the but we are working on an improved version to save to scale and in that version the

user does talk to the coordinator uh but yeah it's definitely it's definitely it's something they can to consider when we think about security so uh how efficient and expensive is that atx i i don't know svx is i'm not sure so like the latest thing i heard about people doing with sgx sorry the question was like how efficient is sgx nowadays uh the the the most important like the biggest thing i heard people doing with sgx was using stx to do like a trusted setup for some of the bigger zkp circuits i think it was like uh polygon hermes did their trusted setup inside intel sgx but unfortunately

uh zero day was found after they did the did the did the setup inside it so like theoretically they could have known about that exploit and executed it before it was published to get the the you know yeah they can just redo it again yeah but they have to read the contracts oh i think c so the question is did someone use sgx for their private smart contracts yeah i think a secret network or something dude oasis yeah yeah okay yeah it's possible i i don't pay a

lot of attention to that to the chosen hardware stuff but yeah okay so let's have a break there's some food and we can have a have some chats and then come back we'll talk about scaling cool thanks it doesn't

i'm good read more

are you interested in doing quadratic morning actually very new to me telegram yes sir oh i don't have the qr code thing let me type my username into here

okay folks um let me start the we basically talked about how macy works in the previous section and then this section we can talk about how we can use that how we can scale it more so let's talk about like the unchained footprint of what we have right now can i okay let me just clean this is it okay if i clean this one okay so we end up having like

a bunch of users who send their encrypted commands to a smart contract yeah this happens many many times and then our coordinator sends zkp to the same smart contract to calculate the results cool so there seems like there's two different

two different pieces that we can optimize we can optimize this part where users are putting their their commands on chains and we can also optimize the zippy uh optimize the number of ckps that we need to volunteer like the simplest and kind of like biggest like least work for most impact is to just deploy this on like a layer two on like an optimistic roll-up and then all of these commands that are going on chain they just end up you just get a lot of like storage reductions because like when you're working with layer 2 execution is basically free execution is basically free because like

either you have a fraud proof which almost never gets executed or you have a zkp which is like constant cost to verify so for that reason the the verification is free uh but like when these when these messages come on chain they get they get put into a snark friendly merkle tree and that's to make it easier for the coordinator to process them and that's that can be expensive uh because it's just a lot of like snack friendly work in the evm which is not which is not cheap so like one optimization that we were thinking that we that we have that we're going to apply is to realize about the like this system is very similar to like a ck roll-up where like all of the data is published

uh all of the leaves are published on jane and like we're just calculating the final results uh but like the thing to notice is that like the consumer of this data is only let me try only the coordinator and because it's only them we don't need to make data availability guarantees for everyone for just this one person like if you remember from earlier we have this system where like you're able like the coordinator is able to refuse to reveal the result of the vote and if we make data available on layer one it becomes this like super expensive thing that that they have to to process

those it becomes it becomes really really expensive because like each of our users has to have like gas each of our user has to pay on chain transactions and that just becomes like prohibitively expensive so in order to avoid this what we can do is is we can allow the coordinator to sort of help the users so basically what happens is that like instead of the users talking directly to the smart contract the users will talk directly to so the users will talk directly to the they'll say to the coordinator hey i want to put message one one on chain and another one will say i

want to do m2 and basically what the coordinator does is it calculates like the hash of m1 and message one of message two and puts that on chain and then to each of these users it returns a vertical proof oh let me do this in another call then to each of these users they return a marker proof that basically says here's a proof that i included here's a group that i included m1

in this root and here's a proof that i include m2 so like this like as long as the coordinator is is is is able to help the users to do this we can basically turn the like two on chain transactions into a single launching transaction and the important thing to notice here is that like we can grow the size of the tree that we're putting on chain it doesn't have to be just like two it doesn't have to be two two two leaves in the tree it can be like 200 or 2 000 and like this is a way for us to turn to if the coordinator is happy to help the users then then

then the unchained gas costs basically disappear uh there is some issues here to do with like censorship resistance where like the coordinator could say oh i want to i want to censor a certain user so i force them to put transactions but like given that i'm like that is hard but it's also like attributable if a user is not able to if the coordinator is not helping users the user can kind of show that like i i wasn't helped to put this ball on chain and we can maybe decide to use a different coordinate who's not censoring users so yeah that was that's that's one of the optimizations that we're applying here it basically reduces the need for unchained gas costs

on the user side the other major cost that we have is the zkp verification uh because the the the zkbs are quite big uh and we need to have many zkp's it's not just one it tends to be like a bunch of zkp's that we need to publish we do many zkp's to public to to to check various things and like each of them has a high cost the thing to notice here is that like although we've already moved to deploying this an optimistic roll-up the gas cost is still quite expensive because when you're working on an optimistic roller or zk roll up the only

thing that costs is data availability everything else is basically free and because data availability is the only thing that costs putting a whole bunch of zkp's on chain is really expensive and it's really expensive because yeah it's really expensive because it's just like a lot it's a lot of data that can't be compressed like ckp's is just random numbers and you can't compress them together to reduce the call data that you're putting on chain so our plan for the zkp is to reduce it is just to aggregate the proofs together so we're basically working on like this aggregation toolbox to to be able to merge like money's ekps together immigration

and then that will result in us just needing to put like a single proof on chain or like much less much fewer proofs on chain uh let me check yeah basically the way the aggregation circuit works is that is that like we we do the kind of like plong style aggregation where you where we like aggregate together a whole bunch of different polynomial commitment openings and then we do a single pairing outside to verify the aggregation is correct so those are the two those are the two main like gas cost optimizations that we applied here to try and reduce the cost it like this should drive the cost down to be like

very very cheap as long as the coordinator is willing to help the users there'll be basically no cost and like what's really important for us is the fact that users don't need to pay to vote and they don't need to pay to put commands on chain and that's that's that's really key for us because like we we want to use this with people who don't have cryptocurrency and like in order to be able to do that we need to we need to have it be super cheap and we need to have to it to be able to be done off offline often yeah so that's our that's our scaling plans here um we do have some other plans about like decentralizing the coordinator and the idea here is to like basically there's been this new

work about like doing plug proof generations inside the mpc we're thinking about rewriting our circuits using plunk and then leveraging that work to to decentralize the coordinator like one of the limitations of zkp's is that like someone needs to know the witness data for the zkp if we can move that if we can move the proof generation inside the ckp then like many different people are that then like a single person doesn't need to know that we can have like this proof generation by like a a bigger entity or by like a group of entities so like that's interesting for amazing but it's also interesting for a bunch of other

applications because like one of the limitations of ckp's is that like someone needs to know the witness so that's another plan that we have to do to try and to try and decentralize the coordinator there's other ideas about privacy like there seems like like nam raised an interesting point earlier about like how like having private having a private macy would be would be good uh and the issue is that like the coordinator still knows everything that every user is doing and like there seems like there's two ways to avoid this or to avoid this to break this kind of connection like one of them is to have this like

mixer kind of thing where like you can when you update your private key you can update your private key inside another zkp uh doing that like we didn't do that until now because like zkps are really like it would mean we would have to put another zkp on chain and that's really but now that we have the now that we're working on the proof aggregation that's something that we could potentially investigate i think that there was also some work to do with like re-randomization where like they would re-randomize like the key i think they would re-randomize some of the messages so like the coordinator didn't know who that message came from

uh but i'm not really sure about how exactly that worked yeah so that's another thing that we'd be interested in doing like um trying to add privacy the other big thing that we're thinking of doing or the shortest the shortest term solution that we have is to have like a zkp at sign up time so you sign up with like proof of humanities ekp so at least like the things that you're doing inside those aren't attributable to your like your identity yeah those are those are some of our plans for mac in the future uh do you all have any questions so far i have a question

they have a sequencer so the question for example i think or in somewhere they have plans to decentralize the sequence so we can uh let me just repeat just for the people on the live stream so so basically you're saying that like

the role of coordinator looks similar to the roll-up sequencer in inside the zk roll-up and like is our plan to learn from like other zk roll ups as we try to decentralize the the answer is yes and no but like there's definitely a lot of things that we can learn from that process but like the thing that we can't really benefit from there is that they don't have any hidden information that we our coordinator has a bunch of hidden information that they're trying to they're trying to hide or they're trying to process and like we're like they need to know that information because they needed to process the but like with with the zk roll-ups they

don't have any hidden information so there's like a limit to what we can learn from their approaches and can you explain more about configuration yeah so the question is can you explain more about aggregation is that just another ckp verifying a bunch of other zkp's yeah that's exactly what it is that like we just have one zero knowledge group that verifies a whole bunch were correct a whole bunch of other ones were correct and like aggregation becomes this really powerful tool because it allows us to like number one compress the

verification costs on chain and number two it lets us to build it lets us build these systems where like different people are working together to make like a bigger proof and being able to do that means that we'll be able to make like proofs of connections in social graphs and things like that like there's a whole bunch of like right right now we've only been able to make proofs about information that one person knows but with aggregation with npc we'll be able to make proofs about the information that like multiple different people know cool um yeah let me check the time yeah is there any other stuff people

want to explore a little bit more we can we can talk more about this we can talk about some other zkb things let's talk about ultra planck so like the question is like how is ultraplunk different than the original plonk so the original planck uh is like what was defined in the in the in the blank paper was very simple it was basically like a single constraint where it's like add and multiply and it was like copy constraints and it was like just like a three column table

uh ultra planck is something a little bit more advanced than instead of having like a single constraint where you can do additions or multiplications you can like define whatever custom restraints you want so you can have custom constraints that do like uh but bit bit checks and things like that like you can do a range checking size of custom constraint because it's basically just like a polynomial you can just define like whatever polynomial you want and you can apply that wherever you want you can even have multiple different custom constraints that you're turning on with different selectors uh that's what we do inside the zkvm a lot we have like a custom constraint for each op code for example or like we have a set of custom constraints and like you

compose those together to make the uploads that's uh that's like one of the killer features of of ultra plunk the other killer features look up tables and lookup tables basically like uh uh like set membership check that like with blanc and other things we we wanted to do a bunch of set membership checks but like it's really hard to do that like the big reason we want to do that is we want to do big integer arithmetic and that means we need to do greater than checks less than checks inside our circuit and when we're doing those checks it's really really expensive when you're only able to do multiplications and additions when you're only able to do multiplications and additions all that you you end up just taking all the number

the number you want to do a greater than check on you you take that number you break it up into binary and then you kind of you kind of break you you kind of convert it back into the field element after you've done that you know that the you know the binary representation of that number and you can use that to do a greater than check look up tables let us do that much more efficiently because instead of breaking open the binary we can break it up into 8-bit or 16-bit words and like that means that we're able to like look up we're able to make sure that each 16 bit words is less than 16 bits and then we're able to do our greater than check much much easier

those are the two like killer features of ultraclunk and like together we're able to build like aggregation we're able to build like ultra we're able to build a ckvm and we're able to do a whole bunch of other other things that we wanted to do like another one that's kind of another one that's really another really interesting feature is the fact that like the dimensions of your circus not fixed that we can have a a a circuit with like many many columns and when we have a circle with many many columns we're able to we're able to have like a custom constraint with a higher degree we're able to check more things in in each row of our circuit uh it also like gives the circuit

builder more control over exactly how the circuit is laid out which makes it easier to do like more complicated things the thing to remember is that like the i when you have many columns verification cost increases but we end up using we end up using proof aggregation to reduce the verification costs yeah so basically look at custom constraints and look up arguments are the are the killer features of ultra planck yep

ah so the question is when i mention dave and this wise operations is that like a native operation or not no so that's not a native operation that basically will that basically gets built by doing by using lookup arguments to to do the range checks like okay so i guess it depends upon the type of bitwise operation that you want if you want to do like you can build a multi-dimensional table it doesn't have to be just one let's do a super naive example of like uh

an xor so an xor has like a b and out uh does someone know the truth table of an xor gay yeah i don't i don't know it or okay let's do an and i think i can remember an and yeah it's like zero zero one one zero zero zero one zero one one one is that an and great truth table or is it zero at the top anyway that doesn't let's not worry about that so so like sorry it's the first one is that all right that should be zero yeah okay that's the end gate

yeah so let's take this as a big operation we want to do this with a lookup table so what we would do is we would build like a multi-dimensional lookup table with three columns and basically what we would do is we would we would take our two inputs and we would look them up let's say our inputs are zero zero our output will be zero uh that's that's what we would do yeah that's what that's what we would do to make like to do a bit wise operation this is this is really overkill though because you you don't want to do it on this level you probably like do you have an example of a bit wise operation that you want to do or like is it on this level that you want to do bitwise operations or is it

like a bigger a bigger thing you want to check actually so you try and implement something that involves bit wise but also a lot of other stuff oh a hash function or something okay yeah so i can definitely share with you some of our approaches to implementing hash functions inside the zkvm i can i can share those details with you uh we've been working i think the one we spent the most time on was catrack and we yeah we spent a lot of time optimizing catch up because it's such an important

and cheap off code in the evm uh so let me share that with you like roughly the intuition for how ketchup works is that we have many two columns we have many columns and like i think we have so many columns that like it takes eight rolls to do a full cat check or to do a catch like permutation just because our our circuit is so wide uh so our circuit's really wide and then i think another like it's hard for me to remember but i think another thing that we did was like all of these columns are ones and zeros they're all binary constrained and because of that our prover will be very efficient uh because like when you're doing the the the proving i think you need to do exponentiation

but if it's zeros and ones that you're exponentiating it's a lot it's a lot cheaper i i can't really remember the details of that one but let me see let me show you some links with our ketchup spec you can have a look and we can discuss it tomorrow exactly like what hash function are you trying to implement sorry what what hash function are you do you have some targets that you're

focused on okay if if you do have some that are that you're focusing on and it is either shot 256 blake 2b or cat jack then maybe we can share an implementation between the zkvm and the old work cool hello hello yes hello actually i i i haven't read about that like they used guy preconceived yes

so do you plan to use it right so we're using so right the way that i think about zkp is is i try and separate the polynomial commitment from the circuit arithmetization so we're using the halo 2 library because it has a really nice long charismatization api but we're not using the halo 2 polynomial commitment because it's too expensive to verify on chain the way that i think about halo 2 is it's basically like bulletproofs with cycles between curves and also they use this like ec fft algorithm so they use this ec fft

algorithm which means that you can have like efficient ffts on curves where you don't have like a high number of order rules and unity that's that's one of the limitations like for example we really wanted to do uh use do like verify zkp's and secp 256k1 but we couldn't do that because it was just the the the the roots of unity and the curve was really low so we couldn't do ffts uh but this new algorithm allows you to to do an fft on those curves so we're working on implementing that at the moment and we're hopeful that it will allow us to have like much bigger

circuits because right now we use the bn 2x4 curve that one is limited as like 2 to the 28 rows or 2 to the 28 roots of unity but like if we use the easy fft algorithm we can we can grow it much much bigger yeah like some of the star curves have like two to the 256 roots of unity because they can just pick whatever curve they want or they can design their curve however way they want so it would be really nice to be able to have that those size of circuits so right so the way that i understand it

is that they have two curves and like they cycle between the curves and they defer the verification of some of the cur one of some curved stuff until the next and like they they have this like bulletproof that's like you're only able to do like a really small circuit on each and they just keep going and going through the curves until they manage to build their whole circuit or to verify the whole circuit that's roughly my understanding i can send you a link to some better write-ups about it right so the question is like for lookup

arguments are there any performance penalties yeah so the current lookup argument is more expensive than a than a row i think it's dependent upon like the size of the table and the number of look-up arguments you do in the circuit altogether i know that the new the caulk look-up argument that we were talking about is much cheaper if we can use it and i think we can also make like bigger tables but like one of the big limitations of of like lookup arguments at the moment is like the maximum number of roles in your circuit has to equal has to be like like okay so your prover time is dependent upon the maximum size of your lookup arguments or the the maximum number of rules in your

circuit whichever is bigger so you have this kind of trade-off where you're trying to make the number of rows in your circuit equal to the number of elements in your lookup argument but i think with the new caulk stuff it should be a little bit easier or it should be like a little bit more efficient but like i like the way that i think about this is that like okay it's more it does give you a circuit penalty but like most of the time it's going to work out as cheaper than just doing that natively in custom constraints so this

is the most popular snack scheme nowadays and how is it compared to like some other one like mali i okay so let's let's take this idea of like talking about the arithmetization and the polynomial commitment separately so like planck is definitely the most popular arithmetization um everyone like that's used in flunky2 it's used in in like the polygon herma zkvm it's used in in a whole bunch of different places it's just a really flexible way to define your circuits the most popular polynomial commitment is probably kzg but there is some competition from frye

specifically because like the fry verifier or verifier can cheaply be expressed inside the circuit so people end up doing this like two layer recursion where like inside you do fry and outside you do plank the limit the negative of fry is the proofs are really big so when you do this reversion you you end up with small proofs and oops you end up with small proofs and and like with a small verifier and a small verifier too or small proof sites or small fruits i do so sonic has definitely been replaced

with other stuff i think like halo 2 plunk both were improvements of sonic marilyn is still out there i think that marlin i think that marilyn's killer features it has really cheap proof aggregation they can aggregate proofs together more efficiently or you can just aggregate manny proofs together on j without like a external external circuit but like there is some people working in maryland i think that like the what was the name of it i think uh mina and also

ooh arc works i think they both use marlin but like both of those are making the same distinction between arithmetization and like proof system and polynomial commitments so i think that like marilyn and planck have largely merged together and resulted in like ultra plunk that's my that's my current understanding any other questions okay so let's meet back here tomorrow

and we'll do the same thing about zika vm um we'll explore explore that how to how we implemented that and see how we can help with the wasm efforts and see see if we have some ideas about optimizations cool thanks folks so do we need to prepare to bring the laptop into more no not really neat okay so thank you everyone for joining the first workshop today and then i hope to see all you guys

tomorrow again and actually the topic tomorrow very interesting workshop oh no you