#DappCon22 : Day 3 - zK Panel, Martin Köppelmann, Uma Roy, Alex Gluchowski, Jordi Baylina

Transcript

we're ready for the panel I'd like to invite uh Martin koppman and everyone else that was the previous panelists so I know your name all right yeah great greatest panel so first one word uh to vitalik vitalik had agreed to join the panel unfortunately he just wrote yeah he got sick so good uh well get get well soon get well soon for the March

but but but let's uh let's have the pennant yeah with with the three previous speakers and we saw um yeah three great presentations I want to start with um where are we coming from and I I looked up um I looked up the agendas of uh well previous defcons here um and yeah the last one due to cover it was in 2019 and first the question to you guys are you still remembering which talks you gave there I forget just mentioned me before here because probably I could not remember but I was talking about the identity and and yeah it's a good it's a good thing

because actually in in in polygon we finally relaunched the project of identity we created polygon AV and the same thing is one of the important projects for the space that's needed so I'm super happy that this project is happening at this point it's a project that you as you know we had to like Fritz for where we built the first the first roll up we used all the technology from the identity just to build the Rob circum and all that and but now it's uh very amazing team in polygon that just taking care of that project and actually they are doing incredible work and just uh well just uh you'll hear a lot about it in the in the upcoming month

Alex do you still remember your talk I'm pretty sure it was about DK Roll-Ups just explaining how zika roles work and uh looking back uh it's it's been an amazing journey like how much progress we made like as a space overall make it easy Roll-Ups reality first and then actually um very Advanced and things like CK Bridges like that was unimaginable back then yeah I think it was even kind of free the pre the idea of DK roll up so so that was like like still one level simpler it says how ZK proofs can help your depth so kind of it was more like a single Deb could have some element or some function um uh that it would would kind of put

into put into a snark and yeah I think then then only then probably half a year or year later kind of there was the Ada you can have full roll up and eventually there was the idea well you can actually have the full uh full fully VM and Alex in in your talk you kind of um yeah discuss those those levels of compatibility so let's just um yeah make make sure we uh we understand that maybe I I can describe again so layer four or kind of I think that's what you also started with was to say okay we have uh code in solidity and other smart contracts

written let's make sure we can um uh kind of deploy that but it's not what what what what what what what what is it not kind of therefore sure so it's not bytecode compatible so if you think about compatibility if you think about compatibility in the normal software world uh like you take uh Microsoft Word or photoshop written for uh windows and then you want to run it on the MacBook yeah what are your options option one is take the source code recompile look into what API compatibilities you might have fix those do you know like see what what like slight nuances you can introduce

and just recompile and run it natively on this new machine uh second option would be to run a virtual machine virtualbox where you run the same software inside the virtual machine in the second case you do not have to make any changes to the compiled code you take whatever is working already and you just run it in this kind of simulator environment which will come with the cost penalty you will feel it it will be slower tangibly slower right but but then you don't have to make all these adjustments don't have to think about the slight differences yeah you already so that I I at least heard that that idea kind of that we can go to bytecode compatibility I highly started first from you at in Paris ECC I think one and

a half years ago um so yeah then the the the the uh again the advantage is um yeah there are some compatibility uh issues that you potentially get rid of at the cost of or potentially at the cost of of some some speed or which yes yes a selection again it's a balance between compatibility and and view on efficiency the the interesting thing and this is something that we learn a lot in in this last year is that uh the loss that you may get in the performance is not as big as you may think actually

doing as a compatible or SDK ebm you know as a KVM ethereum virtual machine so writing uh uh uh KVM system it should not be uh us you should not have as much penalty as we thought it could be when we started the project yeah because we had to we had this challenge you know the AVM was not designed it for for for for building a in a in in in a CKC here we had to struggle a lot and we have to think in very optimal ways just doing you know just uh 256 uh operations uh you see the essay we had you know of

course you know a lot of things that were not designed and we had to struggle a lot just to optimize uh those functions and we come up to a quite optimal way so that we believe that the differences that we will be will be between uh non-compatible but with more high performance with a compatible evm the difference should not be uh very big again this is something that we need to see I have not seen Alex so the ckvm code and I don't know who this is going to perform this is something that we need to check but what I can tell you is that what we thought at the beginning that this penalty would be and what actually it is is at least one or two

orders of magnitude less so this is well at this point uh I yes so I had dogs when I get started there when when I started to do with the ABM we had those because of this performance at this point um I have no dope I think this is the way to go yeah I I want to can briefly also discuss the even the two layers above and Alex you made the point why that's uh maybe not even desirable for for the roller perspective I just at least want to make the point it it would be desirable if we could do it it would be desirable for another reason and please correct me if my understanding is here is wrong but if we would actually

be able to to reach this layer one it would make a huge difference for running an ethereum full node because then you could recursively prove the state um yeah maybe can you describe that or against the Nina yeah I think uh if you combine the zkevm alongside verification of consensus you can have you can combine the two and I think similar to what Mina's doing you can verify like the current state of the chain and you get ability to prove for the state Transitions and also the consensus I think there's some problems with that like you have to be worried about long range attacks and uh I think the details are actually kind of matter

in terms of like how do you implement this like four Choice Rule and stuff like that but I think certainly when you have both it should be possible um I I just don't think it eliminates the need to actually run the full node with the full State because you need to execute it fast like you cannot rely cannot wait uh and have this lag between the the latest State and the finalized state would approve um yeah like it would still not solve it would not eliminate all the all the problems there but yeah that would be possible it would at least probably eliminate the problem that currently right now it can take many days or even weeks to agree to get a note uh sent yeah very important also for like

clients you know right now like clients they need to synchronize the headers and this is this takes a while and it's well the batteries and it's expensive and so on with this you just get a proof that this is the last the last uh the last block and you just verify that and you are synchronized that so you don't need anything else and that would be amazing and and this is clearly this is the way to go we are we are still a little bit far from that but we are much closer than we were good then maybe let's push the topic beside and kind of in two years at that point we can we can hopefully then uh but I just talk about want to add one thing like there is a simpler way to to solve it if ethereum is embracing layer to Centric roadmap

roll up Centric called map what you could do is you could eventually just like limit the block size from 12 million gas to like whatever it takes to verify just a few is your knowledge proofs right and then then like the access to the state could be increased multi-fold so that it's it's very very expensive to use layer one directly yeah so you push everyone into layer tools which should be decentralized Broad and offer variety and offer like all the functionality with high speed High throughput 31. that that brings me uh to to the next uh topic uh could could that be the could that be a desirable solution and the the thing

um why I have at least um yeah kind of doubts about that or at least say well that should be probably um uh yeah kind of other approaches and well with another chain we are actually going another approach is the question of who can actually build uh blocks and how realistic is that to um yeah to to to to to decentralize um and yeah I think or maybe maybe maybe you can comment directly of like how how how well who will be able to build blocks or kind of a Penn State or

therefore kind of make sure that the Chinese censorship resistant in the layer two yeah in the layer two that here the solution and this is I think is quite common in the optimistic role up and in the in the zigiro labs is the this idea of uh the sequencer splitting the sequence and the approver the proverb actually cannot do anything you just take what we call it an implicit state so once once the transactions are sequenced you already have a state it's it's that the transactions are actually finer the thing is that this state is not available [Music]

balance in the in the in the in the trilemma in the real one dilemma you need to build like another system in front it can be a centralized system with all the you know you are in the Dilemma you are in one corner of the triangle you can build uh another blockchain a consensus mechanism to to have different properties in this dilemma or you can use uh layer one but what's looks clear I don't have a mathematical proof for that but looks what's clear is that you will not have Better Properties if you are Layer Two you will not never have better properties than the layer one you're running uh on top of that so the development of these consensus uh so this sequencers this is gonna this is I think this is one of the

interesting things that needs to happen this is common to optimistic relapse and zigger relapse and I think that we should put a lot of effort in that side because well it's it's it's temporary you know it's a temporary because once the transaction when Once the sequencer is is put it in layer one then you already get the all the property this of the layer one but for temporary especially for latency and even for even for throughput this is going to be the one of the limitations there and this is I think this is one of the interesting topics that will happen in in the air doing the coming in the in the coming in the coming times so let's uh try to nail this down so essentially um if any system

is a layer two on ethereum and it says it offers one second finality it cannot be true right well it's going to be a probably you will have you there will be some assumption maybe that you trust a centralized sequencer so if if you accept that assumption and it's okay in your application then that's fine and but uh you you probably have to get some specific assumptions or you decentralize the sequencer right and then you add some economic uh weight to the sequencer so they put some Bond and if they like revert transactions that were committed but not yet finalized in ethereum they will have to pay right so essentially

you implement its own consensus system and then you can have at least the guarantees not of the L1 but of well that is yeah but then the entire state of this validators of this decentralized sequencer is only securing a few transactions in the flight not all of the transactions in the long range of like all accounts but only a few recent transactions that could or could not be reverted so that that's a lot of stake for a very very small amount of value which gives you a very high security and I think Uma that would be a good transition to um to lay out

what kind of the bridge you have been working on offers and also what it does not offer because I think yeah maybe you can extend on that so he said all the all the transactions that have previously are secured how does it look like in this bridge uh yeah so I think for the bridge uh especially thinking about Roll-Ups uh you can't for a roll-up if there's transactions in Flight that have not been validated and secured by like the main chain of we're bridging from like roll up to roll up for example you can't get the in-flight validation until it's like posted on ethereum for example if you're validating ethereum block headers on a different chain what you can do if there

is like a decentralized sequencer that has its own consensus mechanism is if you want and if you trust like that level of security and you're willing to do those assumptions for like the faster finality of the roll-up maybe you could Implement that consensus algorithm or verification of that consensus algorithm on like a different chain as well um so I think one thing we're really excited about is when Roll-Ups do decentralize the sequencer maybe you can take advantage of that for like faster finality between role of bridging in like a similar manner but in general I think decentralization of the sequencer is very important especially for censorship resistance um and I think it'll also be really important in the bridge as well when

we're generating these headers um and generating these proofs I think it's really important yeah I mean my perspective is a little bit we are start like on those chain we are starting with the extreme of decentralizing the sequenture sequencer which means we have a hundred thousand validators because that's kind of the uh that's what it is I mean that's kind of in a way each validator is a sequencer that's randomly uh Chosen and yeah we were able to come up or you were able to build build this bridge uh but yeah that it has lesser security guarantees because or maybe you can expand on that so again Alex said um the the old state that that can never

be meddled with in in our case in our case kind of if the if the if the validator said yeah so if the validator set of gnosis chain probably has like less economic security than full ethereum of course um so if you're bridging from gnosis back to ethereum and validating the consensus hypnosis if there's an attack on notices chain or a reorg or something like that uh then you get that level of security when you're validating the consensus on ethereum so you're not able to inherit the full just because you're bridging from gnosis to ethereum with this does not mean you're inheriting full ethereum security of course it's just the security of the consensus protocol right right so we're proving the state is canonical we are

not necessarily proving and it's it's correct maybe just as an Outlook maybe eventually it's it's possible uh to combine um those two things but but yeah do you actually prove that the state is canonical because you like what happens if there is a fork which Fork will be canonical right like a hard Fork yes uh yeah I think dealing with hard Forks in this design we are thinking about that like a hard Fork is a most it's like a social thing right like the old chain is just as valid as the new chain but everyone agrees um yeah people have ideas I mean we've thought about you know you can have some governance over what the hard Fork is right that you keep track of the fork ID

um or something else but you do need some like social mechanism to keep track of which Fork this like client is going to keep track of because the old chain is as valid as the new one and I would I would argue if you talk about hard Forks then in a way your system or you can kind of Decay VM system suffer the same issue I mean theoretically if there's a hard folk on ethereum that I don't know kind of removes the Roll-Ups are immune from from Forks because the robots like you will just have two versions of the roll up on two different Forks okay it's a problem for Bridges not for Roll-Ups because Roll-Ups what we call a bridge on a roll up is actually just the basement the fundament on which the roll-up is connected to lead to its

underline layer one but you never detach it from real error one it's not as separate ended right so forking right layer one will automatically Fork their roll up as well with all the assets yeah right and with other consequences sorry and with all the consequences you know yeah maybe there are maybe you can have the usdc that's uh consensus to run in one roll up and uh tether it has a consensus to run in the in the other roll up and yeah that make that perfectly concupble I hope not but yeah maybe next let's talk about um yeah because they touched touched already the the topic of

um upgradability um what is a yeah realistic uh strategy to roll out those systems and um I I can just share our experience Years Ago by just developing something like zenoso safe which is probably one or two orders of magnitude less complex I'd say that was still a process of one and a half years to get it to a point where it was really broadly uh trusted and um yeah so now I guess the question is

those systems and the question goes to all three of you uh again that are so much more complex how can we roll them out we are writing these to be decentralites okay so we want this to be absolutely uh even governance lesson so it's just a system that works its system is from the humanity and the system works alone and you are not even parked you created that but that's it things happen this is the idea of the system that we are building and this is of course the goal uh that we have reach that point is is a long track and already know let's let's try to launch

some production systems and see how they work this along path to arrive there but something that we need to be to have present all the projects uh we need to have it present that we are going to uh to that direction we well we have a we want to have a plan for for for going that direction and stick to the plan uh because it's easy to get lost in that you know it's uh things work you don't touch it but we need to uh we need to have always in mind that the end goal is to decentralize the end goal is to even to to

create systems that are common goods yes it's a really hard question for us because the there is really no good solution like the ultimate solution is does not yet exist the the um the the problem is uh that um you want to protect against potential vulnerabilities but if you like who do you give the the right to to make instant changes to um if there is a certain group of people like our community who can do those changes then like let's say it's

governance um then they could potentially like do like all kind of malicious changes as well how do how do you balance like or like how do you prevent people from doing militia changes but like being able to respond to malicious actions uh what we came up with in ziki Singh what we currently have in place for version one and we will be embracing for version two is the team the core developer team can only initiate upgrades with a time lock and it takes multiple weeks so everyone can see the upgrade uh and uh if you don't like the upgrade if you don't believe it's properly audited or like you can look at the call yourself and decide whether you trust it or not you

can always withdraw your funds through a priority queue mechanism which is permissionless and trustless like there is no way to censor it because you do it on layer one if there is a vulnerability which requires an Urgent Care an instant upgrade then in addition to the team initiating an upgrade there must be a consent from what we call a security console where we have a number of Highly prominent public figures from the uh ethereum Community who have to approve this upgrade with a with a certain uh pretty high threshold that is for now the best thing we can we can have the the ideal scenario would be if we could Fork our l2s but then we we can't really Fork

hard assets that are locked in the contract on ethereum however we could Fork all the derivatives like if we never used directly ether but we used uh something that is emerging like nfts or any kind of assets that are minted directly in the L2 this would not be a problem so maybe that's a solution maybe the solution is to say okay like in in this in the Altos we you should prefer using the virtual assets derivatives rather than actually bridging heart ether um not sure one of the one of the things that we implemented in haramis1 and I think it's an interesting thing is that we limit the ratio of uh exit outputs so

if you want to exit 100 is decentralized so you can do it it's it's you cannot we cannot stop that but we limit the quantity of dollars per hour the system allows to withdraw and this combine it with some uh kind of uh Escape rushes this allows us to to do something on there but the idea is to try to do a cup try to to make so to to control the risk that you are assuming so for this you need to you need to assume some risk in order to grow so you say okay this is maybe there are some

vulnerabilities but we need to go forward so it is how we limit this risk or how we control this this risk and here there are some mechanisms none of them perfect but at the NR in the middle Solutions just to to to to to to handle this put a strapping uh process which is but it's quite complex does it mean that your team has an ability to send their funds that are locked in Hermes one and like not like if I have one million dollars they are sent uh they are sent to uh uh no not not that way they are sent to there is an intermediate smart contract for withdrawal so small small funds can

always go uh go through but for the Dig throw you can choose to go to Via this one and this one is the one that can be uh that can be uh set up but it's uh it's uh it's up to you to go to this to do this withdraw that goes to that then you can do the escape hatch it's not escape the smart contract to a temporary smart contract that you can save your funds because the problem of the time the problem of the time lock is that if you find a vulnerability maybe it's too late you know you cannot react uh to that with this system you can uh you know just you can the people can uh do a withdrawal to this place really fast and then or to

can be throw themselves or can we throw to this place really fast and then from here do it uh do it as safe do it so go to a to a safe um but it's time locked right you cannot it's a dialogue It's a combination of both things it's a combination of time lock and rate uh uh limitation of the rate that you can withdraw without asking without doing without doing it sure so if I have a large amount and I try to withdraw I will not be able to do it immediately it will be subject to time block during which your team can upgrade contracts and actually you can buy time data is that we can somehow we can buy time to try to fix the system or just try to maybe free diui or just which I

understand but like that that just automatically gives you the right center and this is the right we for example don't we cannot get the funds so the phones are also locked there so we we just stop withdrawings so then the attacker will have the funds right and then how can you prevent them if you stop the withdrawals then you have one one one week and then you have to take a decision and in the last thing it's it's escape hatch that's not going to go to us it's going to go to a third party I yeah I I actually feel like uh it's a hard topic yeah this is and this is but at the end these are solutions at the end is this is not good none of them you know all of them are are all of these Solutions have its problems you know at the enemies are

just intermediary things just to to handle these uh Buddha strapping so that's not fully centralized so that you cannot take the phone or the phones and at the same time you have some protection at the end is systems to to to balance this I I fully I understand and I would actually say kind of at this kind of early stage it's a technology I would probably uh trust the system where the developers can can make changes because I I would say the risk at this early stage is is higher from um or I mean it's higher from uh yeah still backs than malicious developers again long term

um well that definitely needs to change I think in the long term in the short term you like time lock or governance or these kinds of mechanisms are really important uh because the systems aren't really tested but then over time as they get more hardened and there's better auditing support and people understand them better and empirically they've held up then I think you can move to a future where you remove these safeguards yeah maybe maybe here uh connected to that is that's also kind of a security or uh um and rollout strategy question is the question of open sourcing so um I think yeah both of you have open sourced what's what's your strategy Alex

we are going up to open source everything after the code is audited but we're going to open source it under permissive license and let like just like the kissing one is completely open source under MIT Apache License you can take it Fork it there are a number of forks uh what we realized is people were forking the system before it was so that before we like there was a fork that launched their token before we actually launched the new version in production and they had some bugs there that were not yet fixed and we had to inform them and let them fix those things so like we decided okay we're going to open source everything at launch one once we have everything is like ready for for people to use but I have a question tutorial uh you decided to open source it on the

copyright um uh like why did you take this decision are you planning to to change to like permissive open source so people can actually use the code because we don't want to avoid we want to avoid this but we want so we want to avoid this somebody just launched with bugs in there but at the same time we want the people to have access to the code and we want the people to review the code we want the people to to audit and to check and to know before using the network what they are using and for us it's very important that before launching at least half sometime to the people to review what's in there to take a look what's in there to check what's in there and

that's the for me this is fundamental but yeah this is a crew then let's uh after discussing kind of all those potential issues and problems so let's do the uh finally the the Outlook of kind of let's say two three maybe five years how each of you uh how do you envision um kind of the block blockchain landscape will look like kind of will there be one one chain with with just Roll-Ups and at many chains um yeah maybe talking in the round or you don't know I mean so what what I know is that it's five years is very difficult in in the

space to think but uh what I see is that in maybe one two years it's gonna be many not many but you know maybe I don't know three four five six seven eight Roll-Ups uh with maybe with different properties and with different things and this is what I would would expect and I think this is the best for uh growing the technology that many roll ups are running there and that many relapsages we learn from one you know we learn from one each other we see the properties what we see what are the trade-off we see what are the things that are good or that bad and this is I think this is the most important thing for the for the maybe for the midterm in the long term

uh we need to see we need to see the performance maybe I don't know maybe in ethereum there is a standard roll up and and then everything else is done I don't know or maybe uh these roll ups we have a good communication so a good interval app communication and we go to a system that's more um way but I have no clues on that uh I will begin with saying that I believe that in the midterm ethereum will win the uh it will be very clear that ethereum won the L1 race right now it makes a lot of sense to have alternative alarm set over alternative properties that are more higher throughput something else in the

in the midterm once Roll-Ups actually take over and we have tank sharding costs are a lot cheaper for all apps ethereum will just have all these properties which you can have on ethereum directly so um with regard to roll ups we will have indeed some period of experimentation with multiple roll ups in the end we'll have a very interesting Dynamics with what concerns the layer 3s and the hierarchy of chains on top of of Roll-Ups or like on top of the zika systems because with zero knowledge proves the most interesting property is the recursive succinctness that we can

leverage to create truly infinitely scalable systems but that that that changes the Dynamics in a way that takes a separate discussion to to explain but the we will have some very different properties of the network effects that will play a role and then we'll we'll see how like so what I believe like we will be thinking about the uh Roll-Ups very differently in a year from now once we have the first layer freeze taken off that's my prediction yeah I think as Jordy mentioned it's really hard to predict five years in the future in this space it's an eternity um I think maybe an argument for

different L ones to exist is maybe people don't want to be locked into the evm model of course Roll-Ups can be non-ebm as well I think it's very hard to predict empirically it seems like there is demand for these different chains with these different properties right now um and yeah I think you just have to build and see what happens one one argument I I'll try to make uh for another in a way one is to say that in my view um whenever you build a roll up or kind of something on top uh layer for layer it's pretty clear that the layer buff will be less decentralized or well it's I mean

yeah less decentralized than the layer below so kind of if you built higher and higher you will build into centralization so I would say it is if if you kind of the first thing um you care about and again I think the block production is something I would say um other l once will have um its value probably who knows I think we all don't know I think we will converge I think the layer tools will develop properties similar to Alternative l1's and alternative l1s can develop properties similar to Roll-Ups and they are going from from different

uh directions to to the same point eventually they're going to meet maybe we will see another chain with like some some very specific properties that make it very valuable on top of ethereum like as easy as she and maybe you know like you this this could happen so um no I mean for sure for sure and that's I mean that is this possible future and I think we termed we use the term layer 1.5 not sure if it's a good one but kind of if we would also introduce those uh well VK VM proofs and have that bridge then yeah kind of it becomes less and less I mean yeah they become pretty similar actually or they they uh merge together

thank you very much although to all of you and I think we would like to open up open up it for questions from the audience again [Applause] I see you there is I see their hand in there yeah how do you feel about that specific chains are they going to become popular and how do they fare against roll-ups big chains how we feel about them sorry

I think Dev specific chains are a thing they will exist they have their uh uh Niche simply because generic chains will always suffer from problems like uh Mev Bots Etc that will specifically create uh like disproportional load on the parts of the chain capacity on the Chain total bandwidth uh pushing out the application specific some Niche cases out of of those chains so like I think they will be there I think they will be uh also running on GK I think everything eventually will be running on ZK we'll have a single one world coordinated uh

ZK like three hierarchy of chains that all converge to the single simple like single proof that everyone verifies which is probably going to be like ethereum fully succinct ethereum proof uh where you can like check the validity of all the transactions on all chains and then specifically explore certain chains and see what happened there but those chains will be will be separate like they can be roll-up based they can be validium based with external data availability resources that are secured specifically by operators or by validators or by users of uh of those dev-specific chains but yeah I can totally see that it's happening for like social networks for

certain games for uh for uh some micro transactions for some specific payment networks even like if you just take payments the very basic use case you can't really have all of the world's payments happening on a single monolithic system or on a single in within the single consensus because we have like some systems in the world like Ali alipay handles at peak times like 140 000 transactions per second just one single Network Visa picks it I think 40 000 transactions per second and that that's like those are Niche systems that only cover specific parts of the world if you take everything

and then you imagine like digitalization of the world going on with acceleration and penetration of Internet embracing like all of the countries uh we will need to separate them in like payment specific chains just for the specific region just for specific use cases so yes we will have a lot of them and that's payments alone many more use cases on top at least in the short run uh maybe in the very long run uh you know blockchains become very much a commodity and and then uh everything can run in us in a single chain but this is a long long run I'm curious about the panelist's opinions on alternative approach like

optimistic products whether they can coexist with validity ZK based rollups and whether hybrid system would be interesting for Optimus Roll-Ups I feel like the main con is the broad proof challenge period which like ZK rollups obviously do not have I think similarly like an optimistic Bridge or also has like that similar issue that a ZK based proof-based Bridge does not have so I view that as the main con and if the ZK proof-based system is going to be as performant or close to his performance and not as expense and is not much more expensive to run because

proof generation does cost money like you probably do need custom Hardware um then I think the advantages are clearly in favor of the validity based roll-ups and here is the the difference so in in the in the in a CK you are paying the the proving cost and in the optimistic you are paying the capital cost uh Capital cost uh is uh you cannot read out of that because this is what secures the the network so it's very difficult to improve this in the other side in the SDK roll ups the proof cost can be improved a lot it's a lot of margin to

improve the proofs so it it looks and here maybe here we're a little biased that we are in a ZK uh panel here but uh it looks like the for me it looks like clearly that the cost of the proof will be uh minimal and then it will make no sense to have a so for the same price you have SDK so you have an instant so you can withdraw instantly so I don't think it makes sense to have a optimistic relapse in the mid in the mid run in the short run while we are building the proofs and about it there is some they have some other advantages it's much easy to build an optimistic roll up that circuit that to validate that but

that's my opinion again buy a set on here maybe the panel should be something from the optimistic to to to talk to explain his his side cool then again thank you uh thanks very thank you all very much and see you maybe in two years or three years again and we kind of discussed how this goes in the middle good thanks