We Need To Talk About Fraud Proofs

Transcript

fraud proofs are broken but we can fix them this is the title of a recent blog post on the ethereum research forums authored by Gabriel from the cartei foundation in this video we talk with Gabriel about his research the current optimism and arbitrum implementations of fraud proofs as well as cartes's permissionless refereed tournaments this post in this video is a call for collaboration so that the entire ethereum Community can rally around interactive permissionless fraud purs please enjoy this video [Music]

[Music] [Music] [Music] GM what is going on today we are here

with Gabriel uh core developer of cesy and uh today we're going to be talking about something that is uh long awaited in uh in this ecosystem there's been a lot of conversation all purely theoretical uh and hopefully as a result of this conversation we can get a little bit more practical uh with the application of fraud proofs um I'm gonna I'm Gonna Leave the explanation of fraud proofs to Gabriel here in a minute um but uh first Gabriel welcome to the rollup and uh it's a pleasure to have you on uh maybe you could start by introducing yourself tell us a little bit of your journey uh that brought you up to uh being a core developer at uh at cartey who specializes in the Linux VM

what uh what brought you uh to this point in uh in your research yeah so hello thank thank you for having me uh so I joined PES on 2020 I think was the pandemic had just started you know uh and I was in the middle of my Master's Degree uh a friend of mine who actually he has been here Philippi uh he invited me to to uh join cesi and I did you know uh so I've actually worked on many parts of the overall stank uh and right now I'm specifically working on the the fraud TR system which is the topic of today awesome okay so let's start high level um it's obviously some sort of proof right a fraud proof but uh what is

what is a fraud proof yes so I I think first we have to set uh the context and the context is scalability you know we want to scale ethereum uh and we want to do that without compromising on security or decentralization uh because we can naively increase scal ility of ethereum uh but sacrificing J too so we need to get smart if we want to get all of three of them together and as you know the solution proposed that the ecosystem is going to is rollups and the idea is that you are going to execute everything off chain so you're you are kind of like um you know making the ethereum base layer uh

require less compute because you're moving compute away you're need offchain and then you're using some sort of proof system to prove back to ethereum that the result of all this compute that you did is correct so this is where like the fraud Proof come in you know it's it's actually addressing this let's add more scalability more block space without actually changing the the base layer uh and the way the front proofs work uh it's actually quite different than you know there are made two main proofs that we talk about today which are ZK proofs valid proofs and frog proofs and the main way frog proofs work is that you actually have a set of validators who are alog together uh validating the

rollup they're running all this offchain computer together and as long as a single one of those validators is honest you can enforce the correct result so those are the guarantees that fraud prooof people and we on that lens you know uh if it requires only a single honest validator and you can participate on that validator set then we can you know argue quite well that we are inheriting the security of ethereum you know if you want if you care about some rollup all you have to do is set up you know a laptop uh to validate and you know you're honest and you know you alone are capable of enforcing the correct result

you don't need to tress anybody else so that that's the uh overall idea of how fraud TRS like the mechanism is but the underlying assumption is that you need this validator set participating to theep permission list you must allow anyone to join in and it turns out it's very hard to design good algorithms that are both one of end we call this single onest validator in a set of n validators as one of n is like the way we call this property so it's very hard to keep one of end keep the permissionless also allow it to be like uh cheap you know like you want you

don't want to have like a superc computer or requiring like huge Stakes or bonds and also settling uh quickly so trying to fit all of those together is actually quite hard uh you end up sacrificing one or the other or more than one and that was the context of of that whole article that we're going to talk about today because uh we all and we all I mean like uh the ecosystem you know like arbitrum optimism cesia and others uh we've seen this problem uh and we have proposed algorithms that try to address all these problems uh but our analysis is that

none of them are actually good enough you know there was a recent uh article by by vitalic where he says the ecosystem standards needs to become stricter and that's absolutely true I think we can do better on front roofs and that whole article is actually a call for collaboration uh we offer a criticism like we analyze and criticize all solutions including ours and try to invite in everybody to for us together to figure out something good because I think some of these might not have even you know uh like maybe we didn't even realize we had those problems and the first step is like look we we we have this uh

depending on the algorithm different issues and we need to address them and try to open up the stage where we can do that together yeah and fraud proofs are a bit of a contentious subject in the in the field of rollups at the moment I think there's been this call for fraud proofs uh for quite a long time and everyone is sort of fighting to be either the first or the best solution to that problem um and there that that that uh it it leads to a lot of infighting whereas a lot of this is just a benefit to the end user if we can end up with the quickest best solution everyone wins um so I I I love the the perspective of of basically this

article that we'll we'll screen share we'll go through in a moment um is basically a call for collaboration um and to get some different criticisms on both sides so that we can constructively uh find the best solution to this praud proof fraud fraud proof problem we're going to say fraud proofs a lot during this uh during this video okay um you also mentioned an article by vitalik uh I just want to highlight that article what what was that one called so that the audience can can the latest one maybe there's another latest one so I think it's the uh we have blobs what now that's the yeah awesome so yeah cool so we'll uh I I'm got to bookmark that in my mind too because I want to check that

one out afterwards um okay great so you mentioned a couple things I want to talk about high level before we dive into uh the nitty-gritty of of uh the research post so you mentioned three different categories of proofs validity proofs ZK proofs and fraud proofs um yes so I I was actually bunching um ZK and validity together you know because ZK proof is like a proof that the whole computation is valid and then in contrast with prod proofs because you prove that a computation is invalid that's why you need a host of validators because the simple honest one uh that that's the Curious behavior of the algorithm it doesn't actually

find the truth uh it actually doesn't even find lies it finds Liars so what you do is you're the single honest validator that's the worst case scenario you can prove that everybody else is lying there is this interactive uh process you go through and you essentially manage to you can catch uh these Liars in a contradiction you know so the blockchain kind of goes asking questions the blockchain acts like this referee so it asks you the honest one like what was the state at that specific point and then it asks the dishonest party and until it reaches a certain point where it can kind of catch this like disagreement this Divergence and and then eliminate the liar so you're

not actually proving that yours is true you're proving that the author is a liar and we if we assume that there's one honest person that honest person will survive and then you can enforce the truth so it's actually worth it got it so so I think that that starts to answer my second question which was uh how do we know uh uh if 99 of the validators agree and I disagree and I'm the honest one how do I know how does the blockchain know that what 99% of the consensus is is actually the thing that's wrong and it's my minority opinion or or My minority validation that is the honest one when you started

you start to to answer that yes I will uh so this is I I need to zoom in actually uh because this is interactive frog proofs there are non-interactive frog proofs and that paper doesn't talk at all about non-interactive it's just interactive uh so we'll explain how this Interactive Works uh so all the communication happens on chain there is no communication between the set of validators happening off chain uh if we talk is mediated by ethereum so what happens is you have an ook if you're considering rollups we can actually reduce the problem to just being a computation it's easier to

reason about instead of a rollup you can think of a rollup as being like computation chain together and this chaining like interval happens at the end of every apport is when you settle uh so let's think of just a computation it's going to be easier so the setup is considering only two parties the setup between two parties is that we both agree on an initial State and a state transition function so this initial state for example if we are playing I don't know chess the initial state is going to be the chess board and the rules of Chess and if we want to play chess we need to

at least agree on that so we agree on that and there is like the state transition function I guess maybe you could think of the state transition function as being the logic of the chess itself or I mean in our case it's easier it's just a virtual machine and then you implement the logic on top of that and the state transition on our case is risk five it's like a single risk five CPU six single instruction you could also do web assembly you could also do evm you could do mips it's curious because uh like arbitrum and optimism they are evm but the underly machine is actually nips and

mm you know you can uh anyway so you agree on those two things the state transition and the initial state for you to reach the final State what you do is you apply the state transition function it's ly so in the loop you just go and do the state transition state transition you keep doing that until the computation is done you know until you prove that you know on the chess game that not prove but until you reach the end of the chess game you know Checkmate and once you reach the end of that you go back to the blockchain and you say this is the final state so that's a claim that's a proposal of the result of running this whole computation and once I make this claim

you will also make this claim if the two claims are the same the system will optimistically assume that it is correct but if there's a Divergence you know like I say something you say something different then somebody has to be lying and you start a fraud proof process where one of us will prove that the other is lying and the process if you want you want to know like the the in-depth mechanism yeah I think I think so I think the the the anal I love the analogy of the chess game the initial State uh the state transitions of playing chess and then uh

and each move on the chess board is a state transition ultimately we reach uh the end of the chess game uh which is the uh end of the epoch right is when we would settle to settle the winner of the chess match to ethereum and or the final state of the chess board even to ethereum and then and then uh the one thing I wanted to clarify is that uh in the chess match example there's two validators correct and if these validators agree optimistic settlement everything's cool truth but if these two uh players disagree that's when we start the prog proof example now

extrapolate this to the ethereum world uh we don't have two players we have n validators n n players correct and if all n validators agree optimistic settlement everything's good but if one out of n or two out of end or some amount out of end validators disagree then because there's some disagreement we must start this fraud proof resolution mechanism yes exactly so that's a a perfect observation that the chance example uh it behaves it's quite well behaved because it's just two players so it's just two people

interested uh that have a stake on the result of the computation it's like suppose I win but you say that you win like it's on my best interest to try to prove you wrong and vice versa you know so it's perfectly aligned that every user of the RO up uh is the validator so it's just to player it works well uh but when you extrapolate it to ethereum where you have something like uh like a DEX or actually a full evm roll up or you know something that anyone can participate uh then the validator set and the users kind of like start diverging so you have to separate those

two and you have to to to guarantee that uh not guarantee but uh well you assume that at least one of them is honest you might might want to have some incentive to make sure that people want to be honest but this is like outside the fraud proof system itself the fraud proof is kind of like just a primitive so the way you expand the two player to n player it's actually there are many ways of doing that uh so the I guess the two most straightforward ways are are uh first you match everybody in pairs everybody that has a a different

who disagree in pairs and then you can eliminate uh the liars and then you pair them again and then you eliminate the lies and you pair them again until all the participants Who Remain they all agree uh then there's the other one where you kind of pair everybody with everyone at the same time and then you find like each one fight fights uh n matches at the same time or n minus one I get anyway so you can just fight everybody at the same time um and both those uh approaches uh or either of those approaches it they don't scale well on the number of

players because if you make it so that every validator fights at most one validator that's the first alternative so you pair everybody like in pairs really so you're only fighting one at the same time if you do that then the settlement is delayed a lot because on the worst case scenario you will have to fight serly and matches and the match can take one week and if there are like 50 players you know 52 then it or it's already taking a year so that's like a delay attack you can just go there like

adversary uh they can create 50 fake personas they burn Stakes to do that that's not a problem you know like obviously depending on the value but um they can delay things for one year and that's not good that's you know as I said we need to become stricter this is terrible uh we all realize that and that's where this whole wave of new algorithms emerge from uh and the other way which is everybody fights everybody at the same time uh also it's also not civil resistant because you need to have resour enough

resources to fight everybody at the same time in a way that you wouldn't need to have if it's like in series so this initial idea of fraud proof which is based on this two player primitive uh it works quite well if you have like maybe 100 people you know like validators if you have a permission list of validators you can make that work uh but then it's hard to argue that that is safe because I want to be able to participate and ensure the safety of the whole thing because it's one of n but if one of n means one of 50 it's not it's

not good enough you know it's certainly better than a multii it's certainly better than you know like it's acceptable as this intermediary state where we have like a permission set of validators and we're working on the permissionless set uh but we need to keep researching an algorithm that will work with all these criteria that we're interested in okay okay so that there's a lot to unpack there I want to I want to start with a question uh because the chess example is very very easy I think I understand I understand the chess example and then extrapolating that to more uh Val more than two validators is uh increasing

difficulty quite quickly so one question I have is that we have a couple parameters in the chess example we have two players and we only have two outcomes for each player depending on what we're settling back to ethereum in and for this chess game when we're settling uh the winner and the loser there's only two outcomes for the for the it's it's just you know they're agreeing on a win or a loss if we if we are then so so I want to just start with the chess example again are we settling the

chess winner and loser back to ethereum or are we settling the the array of the chess pieces on the chess board because if it's the ladder if it's the chess pieces on the chess board there's so many different combinations that people could agree or disagree about and so that gets much much more complex than just settling the the winners and the losers uh because that's that's only buy and it's much more simple uh there's only so many things that we could disagree about but if we're if we're talking about the chest pieces there's maybe there's so many combinations of different chess pieces on the chess board and so if we have 50 people that are validating the the configuration of

the chest pieces on the board it's possible that all 50 validators have a different perspective and settle something different uh they have a different configuration that they settle back to ethereum we have 50 different disagreements if we're just doing the the winner and the loser maybe 25 people say that this person won the other 25 say that that person won so how do we handle the situation where there's more there's not just an agreement and a disagreement but there's agreement disagreement and then a third or fourth or fifth or sixth perspective

on what happened yes so uh that's like a perfect question it's you don't settle the winner versus loser you actually have to settle the chess uh board the whole configuration of the pieces otherwise you won't be able to uh do the dispute process because dispute works on the chance board configuration so like you have the initial configuration and the final configuration and then you claim that that's configuration you want you know uh and the the way the algorithm works it will ask just to person you know just to validators it will ask what was the configuration in the

middle uh and if they both agree it means that they're disagreeing on the configuration on the second half of the game and if they agree on the middle point it means that they're disagreeing on the first half of the game so you kind of go like reducing cutting the search space in half until you find two board configurations where before both players agree and after they disagree and that's where the blockchain applies the state transition transition function once and says no no look if you agree on this configuration I know that the next configuration is a and you said it's B

so you have to be lying now if you have as you said you could have like 50 validators and each one is actually claiming a different thing so let's assume there is one honest validator that's the the Assumption uh because if we don't assume that all the 5501s can actually be untrue uh but if we assume that there's one honest validator one of them is true so like naively what you can do is you could have the the honest validator uh fighting the first dishonest and then proving his ly then goes to the second

one proves that he's lying and it keeps going through all 49 liars and eliminate all of them and since it's now only one opinion left that one has to be the TRU the truth because we assume there's one honest validator there are different ways where you can set up uh this matchmaking you can kind of like match everybody together with everyone so uh the honest one would simultaneously be fighting all 49 of them and each of the 49 would also simultaneously be fighting the other foran uh and this is fast you know because like by the end of the week There's only going to be one

surviving uh but then it's very intensive on resources so there's this straight off but the the the approach is this you kind of like match uh uh validators together in these two player setup and one of them will be proved that to be lying uh but you did raise a very interesting point like what happens if it's like 25 say one thing the other 25 say say another and the Curious Thing is that if you take the setup that you fight in series and not at the same

time the optimal strategy for delays is actually 49 correct results correct Claims One incorrect claim however only one of the 49 was made by an honest validator I just reiterate what I said before I can I can I make I think understand I just want to make sure so you're saying that you have the bad fight the bad eliminate each other and then you just get all the way down to the one honest one and have them eliminate the be like the wor like the best villain in a sense yes exactly exactly so so that is a like a tournament like with brackets approach

and then that's like our algorithm like the one we proposed uh actually does this this is the approach you know you have like uh the good one fighting the bad one but all the other bad ones fighting each other kind of like go fighting on the brackets but to enable that we needed to make a core shift on uh on how the overall disputes work and this shift it's very subtle but it has to do with this somebody can say the right result they can post the correct chess configuration but then lose on purpose there's a way for them to to lie during

this you know oh what was the configuration in the middle and they they can lie they can say no was something compl so they said the correct final one but they play the game dishonestly and they lose on purpose so if you just witness you have 50 validators if you just witness a single match a single two-player match you can't know know what was the truth because both could be lying or one could be lying another telling the truth but the one telling the truth lost on purpose so that's like the very fragil this very annoying

fragility of this two-player uh uh primitive so there is this post uh that that arbitr made which is the post that um announced they were building bold the the name hadn't been like produced on that post uh and the attack that the current arbitrum setup suffers from is this the adversary post a single dishonest claim and then it posts like 100 honest ones and if they can control the matchmaking they can make sure they are

just fighting themselves one at a time and making the honest claim lose on purpose so so it's kind of like the the honest one that is able to eliminate the dishonest one is actually just waiting like like this you know uh waiting for his turn to go there and defeat the daddy whereas there you have like this trojan horse that is actually the truth but it's losing on purpose and is preventing the honest one from joining the pre because it's just one versus one at a time so this is like this fragility which is quite nuanced but it's at the core of all these issues that is annoying yeah that is very annoying like

the guy said the correct thing but he lost come on H yeah okay okay so in that case um so so so initially my my thought process is like why would he lose on on purpose because if he's a self-interested actor then um he would be trying to win the game and get the incentive and so there's no point to lose on purpose but because he's submitting multiple claims some honest some dishonest he's going to make the honest ones lose on purpose so that his dishonest one can win and maybe get a bigger incentive yes that that's one way

to say this uh but this attack uh it's just a delay attack so the dishonest one will lose eventually because eventually it will be matched with the correct claim protected by the correct person because the correct claims protected by the dishonest person can lose on purpose so as soon as the the dishonest one is matched with the honest one the dishonest one will lose uh so in the end uh you don't you're not able to steal the tvf of the r doing that what you're able to do is delay settlement so it's an attack on the livess of the settl head

so maybe I don't know it all depends on on the the bonds you know the stakes but if somebody can create 50 cbls 50 fake identities and launch this kind of attack they would be able to prevent for example arbitrum from settling on ethereum for a whole year and sure you won't gain money from the tvl no but there is ways to gain money there is ways you know if I take out a short position on arbitrum token and I know that I'm gonna execute this delay attack all of a sudden the news oh my gosh arbitrum is down what's gonna

happen it's not the train is broken arbitrum token dumps and I made a lot of money because I took out a short and I knew that I was going to execute this delay attack exactly yeah and and there are other attacks as well you know like uh maybe maybe this this rollup it's not arbitrum but it's some roll up maybe it could be arbitral you know like there is a a solidity Mark contract in there that controls some treasury that's on layer one and then this Tre treasury is like relief funds to whatever and if you can vandalize and prevent those funds from

reaching somewhere you know there are all sorts of uh bad behavior which could be quite profitable uh that you could do by by delaying so and delaying for one year is like not good enough and it's one year if you have like 52 sibles or something imagine if you have 100 you know it's forever you broke the thing you just vandalized it forever it's yeah so so what is let's and I want to get into the article but I do have like I I we already getting into the article so this is perfect okay okay great so um I do have a question as far as I'm gonna share the article but then just leading

into this I I want to understand which um which rollups right now have something like this in practice so like is arbitrum currently using this this fraud proof system that does not have protection against delay attacks are there any rollups that currently have that type of fraud prooof system enabled or are all these rollups currently still using multi- sigs because they realize that the early implementation of fraud proofs is still very problematic and we haven't seen rollups migrate away from multisig until and they won't until this proa fraud proof algorithm problem is

solved yes um I I'm not entirely sure what the rest of the ecosystem is is doing like uh currently in practice you know uh so I think you know this is just that arbitrum is running on this previous iteration of frog proofs that can be delayed for a very long time but they're running that on a permissioned set of validators and running and if you're on a permission set of validators then the maximum delay that can happen is bounded you know the problem is when you

make it permissionless because as soon as you make it permissionless you open up the possibility of civil attacks and their specific system can is vulnerable to civil attacks that can delay uh finality you know settlement right right so so I think specifically ARB and look I think okay I don't want to I me if I'm wrong please correct me on Twitter you know uh but I think they have like a current fraud proof that is permission because if they made it permissionless it would be delayed forever and that as I understand was the motivation for bold is to bold is the name of their new algorithm is to try to

prevent these delay attacks and and I feel that this is quite an acceptable uh intermediary State you know it's not a a multi you you have fraud TRS already you know it's like I don't know how many people are on the permission list but you know it's it's certainly better than no fraud proofs at all uh we're arguing that as we move along the decentralization of all these rollups we also need to make it permissionless and for that we need better better algorithms yeah and so we we spoke a bit about uh arbitrum bounded liquidity

delay model you're and you're saying that um in general uh if we keep the set of validators uh limited or permissioned uh then there is an upper bound on the amount of validators in the validator set therefore uh there is is an upper there is a bound on how long one of these cibil attacks could delay the settlement of the chain so yeah it's permissioned but it prevents a long or infinite delay on the other hand we have permissionless fraud interactive fraud poofs these are permissionless it's very open it's very uh open to new validators

and and more decentralized but because it's permissionless it means that you could have an unlimited amount of Cil validators and you could uh theoretically attach you could you could uh delay the settlement of the chain in in at infinum you infinitely delay exactly that that's the perfect yeah understanding okay so arbitrum and op stack have different algorithms and cartei has different these three algorithms are the current proposals for trying to get the The Best of Both Worlds trying to get permissionless but also trying to bound the the potential delay of one of these

attacks yes uh so I think there's more uh criteria than that um because first the permissionless aspect isn't just to do with decentralization it's also to do with security you know uh the safety of the the rollup because you can if there are no bugs in implementation you can guarantee the uh the rollup the optimistic rollup will function correctly because you can participate and it's enough that one honest person participates so the permission list it's is also uh important not just for decentralization

but also for safety You Know M okay and when you consider all these criteria um it's very hard to manage all of them you know so in specifically in the case of the first iteration of arbit from algorithm and our algorithm back in uh I don't know anyway um is that if you made them permissionless the delay would appear you know you would have these delay attacks uh but you could you know hypothetically make a new algorithm that has no delays but it's not one of n anymore so what I'm saying is that you have to fit all these like properties

together you know and it's quite hard to to fit all of them you you usually end up sacrificing one of them yeah so so just to say that's not just the lay attack lay attack is one of the ways you could attack it in particular our algorithm is vulnerable to the lay attacks it's not as bad as 50 sibl means one year uh but it's not good enough uh and bold algorithm which is the new one it's not vulnerable to delay attacks but there are other kinds of attacks got it got it okay um and so qu I I just want to clarify real quickly and then maybe get into

like some of the some more of the article as well as some more the the the attacks um right now out of the three uh algor uh fraud proof algorithms that we have here cartei uh is is named permissionless referee tournaments so this one is obviously permissionless arbitrum and op stack uh fault prooof algorithms are are these also permissionless right now or are these permissioned yeah so uh my analysis is more on the algorithms themselves and these algorithm they were designed to to handle

permissionless okay so they were all yeah so I mean you could uh even the permissionless referee tournaments you could uh take this algorithm but then Implement a permissioned uh system and deploy it permission yeah but if we're just analyzing the algorithms I think all three of those uh were designed to deal with permissionless so that you could deploy a permission list system even though you could add like a permission list on top of that if if you wanted yeah got it okay okay so you can uh so they're an attempt at permission list uh but you could always deploy them as

permissioned um and kind of handle some different trade-offs that way exactly yeah yeah yeah okay okay so uh as you said they all have issues uh they're vulnerable in different ways we talked about Cil attacks which which uh lead to this delay of settlement problem um you also state that uh these civil attacks undermine the the safety uh and this like we talked about the settlement speed Andor decentralization of the system you also went on to to talk about um not in the article but just now you talked about like there's other attacks that these systems are vulnerable to do you want to say maybe just a quick word or I can scroll down

in the article as to what are the other attacks that these systems are are vulnerable to that are not the Civil delay that that we spent most of the time today talking about yeah so they're all civil attacks but they compromise different things so one of them could compromise the uh the liveness you know like the settl in speed uh but another could could actually compromise the safety of the algorithm so so they're all civil attacks but they compromise different things depending on which algorithms we we're analyzing got it yeah okay got it so they're all they're all different types of civil attacks that that uh break different pieces yes exactly and and the

criteria that I propos you know uh so uh I invite everybody that's like uh watching listening to to read the whole discussion try to contribute to it uh so this criteria there were a few uh concerns raised I guess you know or disagreements raised uh and maybe they were not precise enough so maybe try to go again because there's some new ones to them so we all want uh the the algorithm to be permissionless uh so let's put that as our assumption you know like everything that we're analyzing is permissionless and we want a permissionless algorithm to be and then safe and by safety what

what I guess I meant that there on the on the article is that it keeps the one of n Assumption of fraud proofs you know so I'm considering something like a fraud proof algorithm safe is if one of n is enough to enforce the truth okay so so I could just rewrite safe by one of N I think it would have been a more precise uh naming uh then the second one I called it prompt prompt sat speed you know it's how long you can delay it uh yes okay and

yeah and decentralized uh if validating doesn't require a lot of resources like hardware and funds now yes because you could set uh so so there are mainly three kinds of resources that you need to have to participate in these games and these resources are bonds Stakes collaterals you know so that's one uh the other one is block space you know you need to have gas to to pay for like transaction fees and you need Hardware so those are the three resources that somebody needs to have now if you set the bond value to be like $1 million5 million

dollar uh you may gain more like safety or more prompt comp depending but then you're sacrificing on this axis that I'm calling decentralization because you know I want to be able to go there and validate some chain and then enforce the truth but if it cost me like a fixed five million uh then you start losing on this idea of decentralization and and and permissionless it it's almost exactly like a barrier to entry which means that the the system itself is less permission L than anyone and everyone uh exactly because not everyone can can overcome those barriers to entry

now I I I realize that decentralization is a spectrum um because May there maybe there has to be some sort of resources required yeah similarly promptness you know if we're thinking about the delay attack again you know obviously if we if we have to settle for and settle not a great choice of words here but I if the delay is 10 minutes uh that's much much much better than a delay of one year but it's still a spectrum between 10 minutes and one year there's a lot of Middle Ground where something can be more or less prompt than something else the the

first example here safe I would argue that this is binary because and and I would say that these promptness and decentralization are are more of a Spectra as as you say here but because we we rely on the oneof ENT assumption I would argue that the the safe uh property is more binary than than not uh because it's it it is uh expressing that if you can if you can remain in this one ofen system and still enforce that prud fraud proof uh then you're considered safe but as soon as you get into two ofen or or

worse uh then you start getting un uh less safe or yes the so so I would I would say that maybe safeness safety is a binary property while promptness and decentralization are uh are Spectra yes I I I would agree with that yeah like we could try to frame a more um like you could set different criteria but the way I'm arguing there yeah I would say that that it's it's binary yeah okay again constructive criticism just how how I'm reading um okay so that that makes sense I think those are very

you know virtuous properties that a fraud prooof system ought to have um and we say in an Ideal World we want the honest validator to win any dispute in a timely manner using nothing more than a toaster I I love I love that because it it represents uh like the low res low resources required to run a validator uh very low barrier of Entry if anyone can run it with a toaster um and and it also represents the one of n uh safety property because is even if there's just one honest toaster in the world if that toaster can win then it means that uh that the honesty is it it prevails and it's safe uh and in a timely manner and I think that

demonstrates the promptness uh property um which is very much at Spectrum um okay and then in this in this case we say that the honest validator the honest toaster is our hero um and then we have a set of dishonest validators um sometimes and and we talked about kind of like the the worst villain or the best villain uh which which we call the adversaries these dishonest validators um okay so now I think we've we've set the scene I want to Qui take a quick tangent actually because I I I had a realization I'm not sure how accurate it is but when we were talking about this splitting uh you know to to play

this game we have two let's just take the case where we have one against one um and we have an honest toaster against a dishonest toaster and we have this game where we uh we say okay you disag these two validators disagree let's cut the game in half let's look at the middle and we say do you disagree here yes or no and then we cut in half again do you disagree and we we cut and we cut and we cut until we get uh a single state transition that we can prove from one to the next now this reminds me a lot of data availability sampling um because we're sampling different pieces of the of we're we're

checking different pieces of the uh of of the validators and whether or not they disagree in the case of a block we're checking whether or not there's any there's any uh Missing data and we we're making sure that all this data availability of s uh is is available is this like a a similar mechanism that we're seeing da Solutions like like Celestia Ian da there's there's a lot of Da Solutions out there right now but is this data availability sampling process of splitting and splitting and cutting and and sampling is that a similar process to the game that we describ to resolve disagreements between uh honest and dishonest

validators yeah I don't know actually so this um this cutting you know uh it's from a class of algorithms then we call divide and conquer algorithm I guess you could call it divide and conquer uh where you're just really like splitting you know like and at each iteration of the algorithm you reduce your search space in half so the first cut you do you throw away half of the the search space and the second cut is always half so this is called like a binary search uh where uh if you like the binary search more like a standard uh uh presentation of it is if you have a sorted list of

elements you can quick find any element in this list by doing this cutting and splitting you know you check the middle is the middle uh larger than than than what I'm searching for if it is it's on the first half it's it's not on the second half uh so sampling I'm not sure if it's exactly the same algorithm you know like I'm not a specialist on it uh the way I understand it's more like random you know I tell you look give me this like you roll a die and then you say I want this one uh the other person cannot guess what it is otherwise you would have it would be able to like gain the system yeah that's my interpretation but I'm I don't know okay I I may be reaching for that for that connection

because uh in my mind I come from a math background and I'm I'm I'm remembering like my 10th like 11th grade calculus teacher teaching me how to take an integral with a Reon sum and and what you do is you have the curve right and then you just chop the area under the curve into very small rectangles so you you chop and you chop and you chop and you chop and there's where you take H that is equal to the number of rectangles and if you have H to infinity and you have you just keep like compressing these rectangles until they're like infinite tesm small and then uh you're able to basically uh estimate the area under the curve with

like exact Precision because you take the limit as the rectangles go to infinity and so they just feel both of those algorithms feel very much like a remon sum that we take for the in the data availability case for the data in a block by sampling and cutting cutting and sampling sampling and cutting and then in this case again like cutting checking cutting checking so in my mathematical mind trying to draw a connection there maybe it's there maybe it's not I might be seeing things but um okay that was a tangent let's let's get back on so we have these three properties of a good fraud proof a good permissionless interactive fraud proof is safe prompt

and decentralized and uh the goal here is to solve uh the question or play the game of of hero versus adversary hero being honest validator adversary being dishonest validator and and resolve uh this contradiction or this disagreement between uh honest and dishonest validators and so a lot of this uh is dependent on the incentives and there's bonds and there's there's resources that it it takes to re run a validator and then also to um to kind of like why you would want to play this game honestly or dishonestly so talk us through what's at stake a little bit and and why

incentives are important yes so I'm going to to uh take the problem of incentivizing uh people to validate you know you want to get like uh for example on ethereum if you deploy a smart contract uh it's going to work as long as ethereum is working you kind of don't have to worry about it uh in a way because you're trus in the security of the whole network uh now if we you are relying on a one of n assumption the best security you can have is you going there and validating it and and you could you know uh say that there are

many reasons to do that because you have maybe $1 million locked in that rollup and a laptop is much cheaper than that so you're going to run it or you could have like I don't know you're playing like MMO RPG and you have like this super high level character that you you want to to be there you know existing so there are many reason reasons for why you could have one honest person validating it so I'm going to just put that as an assumption I'm going to assume there already is one honest validator who's interested in protecting the chain so let's keep that as an assumption uh and now talk about the overall uh

system now if you're talking about a rollup which has a lot of money like a lot of like tvl and and and there is a way to exploit the system and steal the whole tvl I think it's a reasonable argument to say that somebody would be willing to burn I don't know a few billions if they stand to win like tens of billions yeah we we spoke a bit about like the the potential even if um you're not able to take the tvl from an or a chain you know we talked about like there is profit to be made from just

shutting a chain down if I have a short there's news oh my God this chain is down I'm my short is gonna be profitable like that there's gonna be poor news poor sentiment selling and so there is a lot uh that an adversary could make even if they're not directly rugging and taking the tvl from the network uh they could take out short positions and and generate Financial incentives that way yeah exactly exactly and so there there's opportunity in a delay attack uh and it's all of that you know like a a uh short position and certainly many others uh and there's also I think a different uh kind of winning you know

which is if you can't compromise the safety and actually rug the tvl uh then I I think actually possibly even larger uh uh uh winning you know like uh because as you said maybe you could short it and a delay would make you rich but if you could rug it you would be rich both from the short and from the tvl so I think the the point that I was trying to raise on that section uh which was quite contentious by the way is that to me it's reasonable that if somebody can win 10 billion by burning one billion it's a good exchange you know so if

there is a safety if there's a way to compromise the safety of the system by burning1 billion dollars uh it's reasonable that somebody might do it yep that makes a lot of sense okay um so now uh you go on to to uh kind of explain ketti like who is Ked and just at a high level what is the work uh that that set the stage for these Concepts yes so frog proofs are actually quite an old idea I think the first uh iteration is like maybe from the 90s I think uh from Fage I think I

don't know uh and then there's ketti which is I guess the more modern version of it that's an author you know like the the atall is like the list of all the other authors uh and and they offer a a very good Improvement on on the fraud proofs from the 90s by by adding Merkle trees you know so if you meriz the state you can actually make so instead of you imagine you said like the board of Chess you know you have to to put the whole board on chain and then when you make a claim you put the whole board all the positions now imagine if it's not chess imagine if something like really huge you know uh you don't want to have to

put all of that on chain so using like some very clever cryptographic uh techniques no use of merco trees and stuff like that you can actually just put uh merco root hashes on the blockchain and then you offer a few merco proofs and you're able to run a state transaction function on top of just uh merco root hash of the whole state if you're given enough merco Cru so I think that's like the the um the the fraud proof work that we are all based on uh so that's like a it's more like introduction to to how it works given some context because it was

important to explain the next algorithm uh and yeah so essentially on that that section I think it's explaining what I just said you know the binary search uh and then once you find the Divergence you you apply like the state transition function uh yeah then also the other paragraph is like if you try to extend this algorithm to many players then you run on this delay attack I also talk about the fragility that very annoying fragility yeah annoying um but hopefully we'll we'll get to a solution and and yeah that this makes sense so here um you this is basically the chess example yes um and with but stay just in

the uh uh computer uh computational uh terminology but this is basically the chess game with two players uh and then this is your extrapolation to many players more so in the ethereum world where we have a permissionless set of validators that would mean many players and then so uh you mentioned that Ked proposes a few ways to make verification games with many players um and and takes this fragility into consideration that that annoying little fragility um and then um this is what uh the uh permissionless interactive fraud proofs that cartey arbitrum like these

are what the algorithms are now based on um and so this was this conetti is kind of like the preliminary knowledge and research that have has gotten uh has kind of like set the stage for uh for uh these new algorithms to come forth and try to solve these annoying little issues yes okay um okay so yeah please please continue yeah so the the first issue uh to to solve which is a very un little issue is that somebody could could tell the truth and lose on purpose so you in the end you claim the correct uh final State you know like the chess board you put all

the pieces on exactly the right places but then you play the game dishonestly and lose on purpose now what does it mean to play dishonestly so as you said you know like the referee the the blockchain ethereum it asks what was the state in the middle uh and to see if the two agree or disagree right uh now the the dishonest person playing dishonestly but claiming the correct thing they could lie they could say oh no actually I disagree with this when in fact they should have agreed or vice versa they agreement should have disagreed or disagreement they should have agreed so during this binary search that's the fragile portion because you could lie during the whole process in a

way that the Divergence doesn't fall on the real Divergence so it would appear the the person who claimed the right thing is in contradiction so God so that that is like the the annoying part so we introduced something that we call computation hashes and computation hashes uh are a change on the claim so instead of you making a claim just about the final state so the claim is a commitment to the final State instead of you just posting a commitment to the final State you post a commitment of the

entire app of the computation so every intermediary step every intermediary board configuration you also post a commitment of that along with the final statement so it's a actually Merk tree so we put every like intermediary state meriz it together and then we post a single plane which is the whole path instead of just the end and so do you post this to ethereum yes okay and so like part of part of my understanding of like this ethereum Centric road map you know that

we that we opened up the conversation with was that we're moving computation off chain or or off of layer one in order to save the computational resources of the layer one itself and then we're going to post some sort of proof verification back to the layer one now that to me says okay let's do the whole Merkel tree path off layer one on on a rollup and then post the Merkel root for that tree uh and settle that that root to ethereum does is it counter intuitive or counterproductive to to then take that entire tree and post the entire tree to ethereum does that contradict the the problem that we were

trying to solve originally yeah so before you know if you just look at like the Canady approach what you put on chain is just the hash uh the state hash of your roll up so you don't put the board you put a merized you know version of the board so so it's just a hash that you post uh and and also on the con on the way everybody does this is that the whole fraud proof if it happens of course you know it only happens if there's a disagreement is already fought on chain so the change that we're making is that we're changing what a claim is it's

still just a hash but this hash now represents a different thing now it represents the tree the whole path exactly the whole path of State transitions from initial State at the beginning of the epoch to final State at the end of the epoch exactly exactly okay yeah and it's actually a nasted merco tree because the leaps which are mediary States they're also Merle roots of the state of the rollup you know so so we have the state you meriz it that's a single intermediary State root hash and then you get grab a set of them and then you make a second merco tree so it's like two merco trees nested one

inside the other they don't have yeah go ahead that's not is that not too computationally intensive it is it is quite intensive to the point of being prohibitive uh so there are other techniques we have to add so I think first uh just to understand how it works we can assume it's not prohibitive for now and then we go no no it's actually quite prohibitive and here are a few strategies to deal with that so uh if you can build this computation hash that that would be the prohibitive part but if you can build it and you can

claim it now when you make bisection um when when the blockchain asks what's the state in between you can't lie because you're committed to that so you you go there and you post a merco proof saying no no in the middle I committed to this specific St so you can't lie anymore uh so if you can't lie what this mean is that there is only one uh valid computation hash uh and nobody can lose on purpose anymore so the previous algorithm it revealed Liars not lies because you

could have the honest thing losing on purpose so it just revealed Liars so now there is this shift in that computation hashes reveal actual lies instead of liars got it because we can pinpoint the the transition in the path uh that is in disagreement with someone else's State transition yes yes so we are making a more robust commitment we're making not a commitment just to the final State since we make commitment to the whole thing uh you cannot dishonestly lie about what was in between because before the fragility is because you could lie

about what was in between now because you're committed to that like you pre-committed to that you can't lie anymore otherwise the proofs won't match got it okay so these uh permissionless referee tournaments um uh include these computation H hashes which solve that that finally we solve that little Annoying Thing where someone could lose on purpose um okay so that sounds great but this solution is somewhat problematic because it it is a much more robust claim uh to to settle the entire uh path of the the state transitions from initial state to end State and so um we have to make sure

that this is not prohibitive uh and so how do we solve you know we we solve one annoying little thing and it leads to another annoying uh problem so how do we how do we solve uh the problem that we've now created yeah so when designing algorithms it's always like this you know like oh yes finally I solved this and then you see oh no there's this trade-off you know like uh it's really hard to get everything together better you know uh so first like with by solving this annoying thing we can do exactly what you proposed before which is setting up these tournament brackets you know before you couldn't do the tournament brackets because it was a dispute between players not between

claims it matters who made the claim because the algorithm the previous one work by finding Liars so you need to know who's the liar like who who is the person behind the AG claim now we don't need to know that anymore uh so there's only a single honest claim there are not multiple honest claims and they're different because they were made by different people no now this here is only a single honest claim everybody can join together behind it you don't need like you don't need to sign the message in check who sending the transactions so this allows us to build this tournament bracket style that you described before which go like eliminating

half of the the sybles at each bracket level uh So you you're like essentially making the adversary who who like paid a lot of money to create those bunch of cbles and then you're making the adversary heal his own sibles himself uh so so that's like the the approach like the mechanism by which this can improve I love it and then there is the question that you raised like okay that's all beautiful you know how do you build the computation M uh there are two strategies the first strategies that is actually quite clever

you know like it was uh you know when you feel clever you know that that's one such pH of fing clever which is instead of making a commitment to the whole PA you know like each and all intermediary State step by step you create a sparse commitment so instead of being like uh one two three four five you go like uh 1 10 20 30 you know so you put like a stride in between each Leaf of this merco tree uh and and once you do that it means that you can't do the step anymore you can't do like the the state

transition function because now if you find the Divergence I gave an example of like 10 you know like a uh uh stride it's 10 it's not one you can't do a one step proof on something that's 10 you know however it once you find the Divergence and you rule out everything else and you reduce it to just like this 10 steps you can recursively use the same process but now require a commitment that includes all intermediary States so AR should call this like a refinement that's a good name uh you could call it like this sparse commitment that becomes denser as you go in but the overall idea

is this you have like a permissionless referee tournament on the top and each match can create a recursive new permissionless referee terment but with a smaller range of computation because you ruled out a lot of it and now you can make a more dense uh commitment and you keep doing that until you reach something that's comfortable you know so we are looking at two to three levels of MSY tournaments you know like with good engineering we can probably reduce that to two uh our benchmarks are like indicating that we can go down to

two uh but you know okay so you have these two levels uh that's very nice uh you make on the top level a very sparse commitment that the cost of building it is kind of negligible when you compare it with the cost of just running the computation [Music] um but it may makes the settlement speed significantly worse so if it's just one level if we could build the prohibitively expensive thing uh this would sett in like logarithm time in two levels like logarithm

squared which is not good you know like logarithm in this case is already not good enough because the constant is very high it's like like a week times the the logarithm uh but then if you do a week times the logarithm square that that's that's not good yeah yeah so so now we we like oh okay that's very clever uh but it's slow let's go back to like how can we build this prohibitively um expensive thing without doing this nested recursive thing and the solution we got is well we can use just on this point the ZK proof so you actually make uh a commitment

which is it looks sparse you know because you're jumping like I don't know 1 million instructions in one million instructions but now the one step proof is no longer a single step like Risk five on our case risk five step is like one million risk five steps and we can build a zi proof from that and the blockchain can validate the ziki proof of that uh cheaply so we can do everything on a single level you know without having to go through these uh recursive multi-stage disputes which what I said exactly yeah yeah yep make it makes sense I mean you you talk about um uh how this gets us

into logarithmic time which is great but because we we recursively Nest uh each of these game these dispute games um it it means that uh we're almost raising the settlement time to a power whether it's two or three or four depends how many times we have to go deeper and deeper and deeper into uh this path um and so you talk about that in this in this trilemma here that um yeah we can uh increase the stakes but it creates that barrier of Entry mentioned that at the beginning we could uh reduce um the base layer censorship um which is

good for promptness and decentralization but we lose that one event uh safety guarantee yeah just say we don't exactly lose it so our model is we model the blockchain as being we model the the dishonest actors as being able to delay like with the sensor your transactions on there one for up to a week MH uh so so this one week is kind of like this folk you know like knowledge wisdom that everybody's using like oh week we considered safe enough uh so that's what we're using yeah yeah but what what like what if like optimism and arbitrum these

optimistic rollups just arbitrarily chose like you know what seven days is actually harming like some of these fraud proof mechanisms why don't we why don't we cut that down to about three days exactly exactly so so you could argue that this weakens the security of it personally I think seven days is way too extreme I think three days it's probably something you know more manageable yeah so so that that that item in the middle is exactly what you said you know like oh wait a minute seven days is way too much let's do like three days uh and but this you could argue that it harms safety you know but since we in this conversation already um uh like established that safety we're

just considering one of end then it wouldn't harm the one of n but we need to set that to like some reasonable time okay okay got it um and and that's what you mean by safety uh like harming safety in this promptness and decentralization one if we reduce uh the maximum base what do the maximum base layer censorship mean so this is the seven day so okay okay yeah because it's curious uh I've seen people claim that you know uh if you have the reason it's seven days is because you need to send I don't know 50

transactions to the blockchain and we've estimated that you can put 50 transactions on the blockchain in seven days okay and the the 50 is that bisection game that you play you know like the cutting you have to cut it I don't know 50 times you know something like this uh but this is not how we model the the censorship you know uh model of ethereum what we model is there are two regimes under which the adversary can switch so there's a standard regime which is like the normal ethereum one and in the standard regime regime we can actually send 50 transactions we don't need seven days right to send 50 transactions we

can do that in less than a day probably could do that in in one hour I guess but we have to cons but if we set one hour this means that if an attacker can censor the single honest participant for one hour they would win uh like by pumping up the gas costs too high so that they couldn't or just like I don't know bribing uh block testers to not attest any block that contains a transaction it's very expensive to carry that out right but for an hour maybe you can do it m so we consider these two regimes and one of them is the censorship regime that adds up to up to a week so what we do is okay if we can

reasonably send 50 transactions in I don't know three hours whatever six hours uh then we must give six hours plus one week if we reduce the number of transactions instead of I don't know 50 to 25 then we reduced the 6 hours to three hours but we still keep the one week that's to say that non-interactive fraud grps I think like the original ovm I'm pretty sure it still had a onewe challenge period even though you could think that once you raise the flag it's okay you know like it's one transaction set of

50 yeah I think that's a bit complicated you know just yeah uh yeah I thinkal understanding is good up yeah yeah once we start changing the 7-Day window there's Arguments for both sides on why that would help some things but it would potentially harm safety which is kind of the trade-off that you mentioned in the second bullet point exactly exactly I I look I think three days is probably good enough you know uh especially if you're considering like small change you know like if it's a small rollup that's like doesn't have billions of in I mean three days might be good enough you know but but I chose the uh the industry standard 7 Days exactly so and

because the others are also geared to to large dvl so I felt that the the analysis would be like more like apples to apples if uh we we tuned these parameters to to match something with high tvl in mind got it okay right so that's yeah so so in in in this algorithm you can tune it to to like it's like a TR you know you can tune it to to sacrifice one of the three of them and got it and the final bullet point is um uh the logarithmic uh uh time that that the delay Grows by uh based on the number of cbls um yes okay um so that

that is uh still quite slow especially when we start nesting uh these disputes but then then you use ZK disp uh proofs um as a way to circum just to to a way to avoid this promptness issue where by if you were to Nest two three four layers that would grow uh the delay by two three four times but you have a way to avoid that uh growth in the delay by using ZK proofs um yes so and just say that this is still an interactive fra proof you're just changing like it's like an

implementation detail we are changing just the state transition function to internally use ZK you know like uh it doesn't turn into a non-interactive or to a ZK uh grow up it's really still an interactive fraud proof it's just that our state transition function now executes a huge chunk of steps instead of a Time tiny little step uh and this huge chunk of steps uh I shouldn't have said huge because uh our benchmarks were doing like uh 1 million uh steps and the reason was 1 million so this is all the trade-offs you know um we want to keep the toaster property

you know and and maybe if we add like a super toaster you know like a like a GPU Farm of toasters uh then we could probably do like I don't know several million transactions you know like um Cycles CPU Cycles um but we wanted to be able to do this on a laptop with one GPU like just one GPU so we were considering what can a laptop with one GPU do in an hour in ZK and our like very old benchmarks were hitting like this 1 million so this means we can make our commitment skip one million in one

million uh like uh stage brot calculations so we can make this it like one million steps sparse uh and now the work is really trying to optimize this as much as possible because all these Z kvms are becoming much faster so maybe we can still doing an hour instead of 1 million 2 million uh and also optimizing on our end because maybe we can do more like denser commitment uh in a shorter time got it yeah I think the main takeway of all this I said is just that

it's still a fraud proof still an interactive fraud proof just because use a ZK yeah despite the ZK um transition state transition function yes it's still an interactive fraud proof exactly okay okay and then um and and that's cte's implementation and then you go on to describe a little bit more about um about arbitrum bonded liquidity delay model um and then I imagine uh let's see do we do we get into uh like op we talked about variant one uh we talked about variant two which

is uh different attacks uh the first attack on the computational resources of of our honest toaster the second an attack on the uh the honest toer block space um and then the Third on uh the funds um and these are all different ways to uh prohibit the honest toaster from uh entering either permissionless or winning uh the the uh dispute resolution game yes uh so one way to call this is like a resource exhaustion attack so we create a bunch of sybl make the the our

hero toaster have to respond in kind M and just exhaust their resources until they can no longer participate uh in this in this game got it and go ahead yeah is this is this set of uh exhaustion attacks is that different than the cibil attacks that we talked about well well actually I think I answered my own question because these all fall under civil attacks but there's different types of of civil attacks some of them are an attack on the the liveness of the chain and the time that it takes to settle the chain we call those delay attacks and then we have

another subass of civil attacks that are these exhaustion attacks um that are uh that that try to exhaust the the computational resources of our hero toaster yes not only the computational resources but also like funds you know like their capacity to pay for bonds and their capacity to pay for for gas and and this uh kind of civil attacks so you have this class of attacks which is like civil attacks uh and now this specific one uh it compromises the safety of the algorithm so this one isn't like attacking the liveness anymore it's actually trying to

steal the TV out yep okay and then and then again we Leverage ZK proofs at the state transition function um to eliminate some of these challenges and so it seems like a lot of the suggestions made in this post are to implement the ZK proofs at the state transition function as a way to um prevent in the in the the first example cartei algorithm as a way to prevent us from going too deep into these nested tournaments and then yes arbitrum example a way to eliminate some of these exhaustion attacks yes but the mechanism

is very similar to cesi because uh arbitrum also uses computation hashes okay and they also use this strategy of nesting their uh dispute game so one and I think their current aim is at three levels M uh so when you can like when you Nest it three times uh you really open up uh this Vector of attack that allows you to to expand the the hero toer resources so just like our algorithm that we really want to make it single level if bold is made single level it also fixes uh this exhaustion attack uh

that we describe so so uh I wouldn't say that all of these the suggestion is to use ZK here and there it's just that bold and our algorithm they use very similar techniques and but similar techniques but different in very like important parts but likewise they are also vulnerable because of nesting tournaments and if we can unest them by using like a ZK proof on the state transition we can really like improve a lot of their uh safety issues or in the case of caresi lightess issue got it

okay um and so just one one more time you said it's not just that that we're implementing ZK proofs at the state transition function what what is it that uh separates uh like th this uh implementation from some of the previous ones that have been uh like theorized so what's the difference between I didn't get the the relation between Z sorry I think I I just I just zoned out I think I just didn't hear hear the explanation where where you started to say that it wasn't just about implementing ZK proofs here and there there yeah there's more yeah so uh no I like you said that um it

seemed that the solution was to use ZK here and there right because like you just saw two algorithms and the two of them had oh let's use a little bit of ZK uh but but the reason both of them had this let's use a little bit of ZK is because they use similar techniques of this computation hash and then this nesting this recursiveness creation of uh disputes and this recursion in case of cesi creates a liveness problem and in Bal it creates a safety problem so if you put uness them and one way to un uness them is to use ZK then you really improve the liveness

in conty and you really improve the safety in bold awesome okay that that makes a lot more sense um thank you for for reiterating that and then um okay so the solution was to unest uh these these resolution mechanisms for both bold in arbitrum case and then uh the permissioned uh tournaments or excuse me the permissionless referee tournaments in in cte's case the solution is is that there's a lot of issues by nesting in these these tournaments um for for liveness and for safety so if we unest them we can solve those issues and the way to unest them is with ZK proofs at the state

transition function now yes but it's still not good enough it's like a major Improvement but still not good enough uh so we want I guess we want to to kind of like finish our conversation in this like happy tone like oh the solution is doing XYZ uh no there's no solution yet I don't know what is the solution I know how we can get there and how is first agreeing upon all the problems we have and all of us in the industry in the ecosystem trying to come up with something better

yeah and that's why this is G this post is generally a a call for constructive criticism and uh uh to try to shed some more light but first agree on some of the the uh first principles and the premise and then start to extrapolate from there like what what some other potential Solutions uh we could Implement um and so op Stacks fault proof system um does this also have a a similar uh nesting type of mechanism um okay so it doesn't use computation hashes okay so you just claim the final State uh and then you kind of go like

bisecting doing that cutting that you you you mentioned uh but you allow multiple people to do The Cutting so I could go there and claim the the final State correctly uh and on the on the and then the adversary goes there and makes his like cut and then I go and make my cut but then somebody dishonest could make the same cut I did but dishonestly you know it would be that fragility that we talked about but on on uh optimism they created this clever uh data structure is like a graph a dag um that allows multiple people to BCT and then there's

a way for you to counter the wrong counter it's uh yeah it's getting more on the details on on how it works but the idea is that it allows anybody to go there and make a bisection got it okay and um you you mentioned that uh all of these all of the these uh dispute games are played simultaneously which makes the dispute finishing constant time that's better than logarithmic time right yes that is better yes okay and so the settlement of these uh game these dispute games is faster but I have a

feeling that we are still not going to like find a happy solution so what is what is what is the problem like what is the problem with uh the way that uh optimism has implemented their fraud proof system yeah so it is the a very similar problem as the the one involved the resource exhaustion so if the the attacker is better funded uh the adversary is better funded than our hero toaster the hero toaster will lose so that's the yeah and this ties back to what I said you know like I'd be willing to burn well I don't have a billion dollars but

I'd be willing to burn if I had I'd be willing to burn it to get 10 you know so it is a very uncomfortable position to to be in like having a adversary that's possibly quite well funded and requiring the the hero toasters to have the same amount of of resources and this violates our one of n because now it's no longer one of them it's a bit like ethereum you know like like Bitcoin like you need to have a percentage of the overall honest resource so I don't know like in in Bitcoin proof of work you need like 50%

of uh of hashing power or rather the set of honest Bitcoin validators need to together have 50% like and and we want to be one of n we don't want to be half of an we want to be one of n yeah and in this case n is the total amount of computational resources amongst all of the validators and so the honest validators would have to have 51% of of the capital the stake or the mining hashing power in order to win this this uh fraud proof game exactly exactly and in this case the resources

are computers as you said like Hardware uh also like gas fees but and this is the last one is the most uh the hardest one the bonds so if we just consider the last one uh then the uh the if the adversary can pay for more bonds than than the hero can pay for bonds uh then the adversary will win Yep this makes a proof of whale even more profitable for the adversary basically proof of and and proof of whale is basically like they can prove that they have more computational or just more resources in general the whale

can prove they have more resources and therefore win the fraud game yes yes I mean proof of way I admit it's a bit of like fous you know way to call this uh but it's essentially that you know like if you have more resources you can break the thing uh yeah that that's why we chose like proof of wh you can essentially prove by playing a very specific way the game that you have more resources than everybody else and win and so we're left we're left with this conclusion where we have this trilemma of safety promptness and decentralization and so we talked about the permissionless referee tournaments

um it does well but it's still great bold in arbitrum case again makes these tradeoffs you made some improvements to the safety property of bold and and we call it bold Plus+ but it still is not perfect and then and then once again the op implementation is is still problematic in certain characteristics when when it comes to proof of whale uh attacks and so we're left at this slightly less annoying uh situation uh where you know we've kind of addressed like the problem in the room um and we've kind of like called out what the issues are with each each

of these different design choices but SI but still we're left with this trilemma that has no perfect solution yet yet yes okay um so I just we won't get too deep into the comments uh but yeah please uh please go ahead yeah so just like for full like uh disclosure uh both bold with three levels and optimism they're both vulnerable to this proof of whale which means it's not one of n but it ALS indicates that the Bold performs better because it's not 50%

like 10% so whereas it seems that in the optimism case if the attacker has 51% of the resources they're able to win it also seems that in bold the attackers need instead 91% of of the resources to win so I mean it is an improvement you know like yes exactly but I I would argue that what we really need is one of n it's like it doesn't matter if it's you against the whole world the whole universe like this hor of this honest toasters like just tumbling around to try to you up you must be able to win a loan uh and I think that is the standard that we

should set for fraud proofs now obviously uh if it's one% of n that's very good that's better than 10% that's better than 50% if we can reduce that that is certainly an improvement uh you could argue that for some networks that is safe enough especially if it's a network like uh like arbitrum or optimism because like this huge roll up of a lot of tvl you know they could probably keep like 1% of like these resources like locked in the bank just waiting to to protect against the whale uh but I think as we try to design it we should try to design

something that is one of n maybe we have to sacrifice it to get the other things and if we sacrifice it maybe we can sacrifice it in a way that's like 0.1% you know instead of 10% or 50% but in the end this is really like a uh this like we need to talk about frog proofs moment uh I think we don't have an ideal solution yet uh and we need to I think all agree that we don't have an IDE solution yet because once we agree we can start working on the new solution and I hope we can start working on the new solution together I hope so too I I uh I I'm

looking forward uh to almost like some new conversations right I think this was perfect to lay out what the current situation is uh we identified pretty much all like the the general tradeoffs that that the current design choices make the issues with each of those design choices and so I I I tend to agree the next step is going to be to get some agreement make sure that we didn't miss any of these problems with any of these Solutions or any design choices that are are also worthy of being in this conversation and then we can start to make progress and we can start to push forward on on how to solve these with uh the least amount of uh tradeoffs um and and compromises yeah the least amount of

compromises exactly and and hopefully come to um a better solution that all of us are able to go and we can run with and we can Implement and in different cases yes and I'd also like to uh mention that we had replies you know so so there was an engineer from optimism who says look I work from for optimism but these are just my opinions you know uh but he answered and he he he quite engaged honestly on on the conversation and uh Ed Felton posted the newpaper that they had so so since the post was made they updated the paper uh which included the resources exhaustion angle uh analyzing all the risk that it poses

and everything so that's also like engagement so I am quite optimistic that we will be able to form some sort of cooperation because I think it's already happening and and I would like to thank uh the the other projects that I really like on board with this amazing amazing yeah it is really um it's really helpful to see uh the constructive criticism the comments the engagement from from uh the projects that are mentioned in the in the research post um Gabriel this is our long this is probably by far the longest video on the channel um wow yeah we should yeah this has been very good very pleasant you

know and informative and thank you so much for the time and and for explaining frog proofs all the way through uh to to the current landscape of fraud proofs uh that we see today thank you thank you