Security vs. Censorship-Resistance: Can We Optimize for Both?

Transcript

All right. Well, thank you DSS for having me. Uh my name is Andy. Um and um I I've I've tried to give this talk at a couple conferences. Um DSS was the first that actually accepted it. So um I'm excited about that. It's it's um this is a dynamic that we encounter a lot at Forda. Um and so I wanted to dive into it a little bit. Um, and I know some of the other presentations have have come at this from uh a different angle. I'm going to kind of from the security provider angle where we're trying to stop bad actors and and threats. And I think in and in that situation, censorship resistance gets a little bit more nuanced.

So, I guess just to kind of define a few things up front because um security and censorship resistance are big terms that I think get used a lot. uh from a security standpoint today for this talk I'm talking about preventing malicious activity and transactions from being executed on chain and uh causing harm and then on the censorship resistance side uh it's going to be ensuring that technically valid transactions uh can be executed. So that's that's that's the framing for this. Okay. um reasons I wanted to explore this first one like I said comes up all the time in our sales and um customer support conversations uh particularly with uh our product

called for firewall which is embedded into L2s and screens transactions pre-execution I'll talk a little bit more about that here in a sec um my observation is that most chains and protocols are fairly centralized um and don't have a strong ideology some do but the vast majority don't um they are simply listening to their customers. They're trying to find product market fit. They're trying to build a good business um and do right by their by their users. If given the opportunity, and again, this is just just our experience. If given the opportunity, most teams would block malicious activity if they could, particularly in advance. Um I feel like as a certainly as a security

industry, we often avoid having the security versus censorship resistance debate. um probably because it's uncomfortable. There's also a vocal minority of people on Twitter that will jump on you if you you know raise raise questions around this. Um but nevertheless, I think it's an interesting conversation to have. And then finally, I think there are very clearly situations where it's reasonable to block a malicious actor or transaction. Um and I crossed out the word censor there and just used the word block just because when you say censor, it invokes an emotional response in a lot of people. And if you use the word block uh or as I'll I'll share on the next slide there other other terms that I I think are easier to talk about this

with. So we just stopped using the word censorship completely um when we're talking with our customers and and potential customers. We use other terms like risk management risk mitigation threat prevention. These are all like much less emotional super boring. Most people, you know, don't want to spend any time on this stuff. Um, but when you use that language, it's a lot easier to talk about how you deal with a bad actor or malicious transaction. Um, the reality is that I think every team has the ability to manage these things, risk management, how they want to. Um, and it's going to depend on a lot of different things. You know, we have

chains and and protocols that are managed by public companies now. um regulated financial institutions. We have you know some in the US, some in Europe, some in other parts of the world, different different regulatory regimes um different considerations. You also have a lot of these products that are trying to go after different users. Some chains are trying to go after real world assets. Well, that's a totally different segment with a different list of concerns. Others are going after, you know, DG Defi users. Others are going after people that just want to play games. Um, and so I don't think it's a one-sizefits-all.

Um I don't know if anyone saw this but over the last two weeks ago week ago u bybit put out an interesting report essentially looking at um a big uh swath of uh L1's and L2s um and wanted to understand what the sort of uh ability was to freeze transactions uh freeze funds and uh what they found was uh 35 out of the 166 that they looked at had some sort of mechanism built in. It was either native or it was something that was added later um to you know in certain situations uh freeze an address uh freeze a balance. Um and you see this come up in you know large

exploits and I'll I'll I'll highlight two in a second. Um the three ways that they they do it are there's you know there's a a public blacklist which is very transparent to everybody. Uh the second is something that's a little bit more at the config level, which is usually like a a private list that's kind of shared amongst validators and and maybe the core team. And then you've got um third parties that might plug into a sequencer or an RPC in the case of an L2 and might be able to to block transactions that way. So I'm going to highlight SUI here, not picking on them at all, but um earlier this year they had a um a large uh exploit on a um on a DEX called Settus.

223 million uh was stolen. Sweet Foundation and validators um used the native freezing feature to lock a portion of that. I assume the rest of it was um moved and bridged off. Um and then interestingly validators subsequently voted to um return those funds back to the um affected protocol and and hopefully back to the to the end users and then the attack was eventually attributed to the Lazarus group. Um second example uh Lineia again not picking on Lineia at all but I know this was this was one that got a lot of u buzz online after it happened. Um, last summer, uh, Velor was exploited for a

much smaller amount of money, but nevertheless, Lineia made what I assume was a hard decision, uh, to halt block production for a period of time, uh, and also freeze attacker addresses, uh, and prevent stolen funds from being bridged off. They got a lot of I'm actually a lot of backlash, but there were certain certain folks in the community that were certainly not happy with that decision. and uh you know using it as an example of um sort of centralization and uh censorship etc. um and since then I think you know Lineia has has obviously prioritized um decentralizing their sequencer and and and block production.

So I think um and last example here um this one's more personal to us. Um we have a product called Florida Firewall. we plug in directly to L2s at the RPC or the sequencer. Um, and we screen 100% of the flow for malicious activity. And in certain situations, if we, you know, find something malicious, it could be an exploit, it could be a a scam, um, we have the ability to, you know, tell the chain to block it, but it's ultimately up to them to to to listen to our recommendation or not.

And what I think is interesting is um in our experience, you know, taking firewall to market and working with a lot of uh layer 2 chains at least in terms of where censorship resistance ranks in your company's priority or product roadmap. It's usually somewhere in the middle here on the spectrum. It's often not the top priority. Um it is a priority on the list. Um but there are a lot of other things that that that seem to take um uh you know priority over that. And it's usually in the case of L2s, it's finding product market fit.

It's finding a differentiator, finding a user base, finding liquidity, etc. As you guys probably know, most L2s are really struggling to find organic demand. There's only a handful that that have any real uh volume uh or sort of consistent user base. Um, and so when that's the reality that you're you're facing, thinking about censorship resistance and things like that just aren't aren't at the top of the list, right? Um, what I think is interesting, uh, when you look at the linear case, the sweet case, um, all the teams that use Florida firewall, even going back to, you know, 2016 with the the DAO hack, there's been a number of other instances between

then. Um, I know B&B Chain has has frozen addresses in the past. There's been a lot of examples of this, right? Um, and I think it just speaks to sort of a kind of a a very um human element, which is that when you see something wrong happening, you want to try and fix it. Um, you want to try and write the wrong. And I think as a business, you know, that same thing applies. Um, you want to do right by your users. um they are in some you know in some sense trusting you um and in this world you know they're often trusting you with with their finances um and so you want to try and protect that if you can you're also trying to build a

good trusted brand um and so you know I think that's why honestly you see a lot of chains do what they do in these situations um they're doing what anybody would do if you saw something happen on the street right you would I assume most people in this room would jump in and want to try and want to try and write a wrong if they saw This is in you know this is very much in the same vein. Um one of the interesting uh best examples of I think where uh this conflicts um and this is again specific to L2s but uh we work with chains that will come to us and they um they do want to do some sort of transaction screening at the sequencer. A lot of it is simple OFAC um sanctions address screening

but um they don't realize that um and I think the L2B uh gentleman spoke about this earlier there's another way to another pathway to get a transaction processed in most cases most chains have an inbox in the L1 um and that pathway exists in case something h happens with the sequencer um and that's a feature that you know is there you know if if you're using the optimism stack or the arbit arbitism arbitum stack for example. Um those decisions were made by those two those two teams. Um and in a lot of cases we find that the roll-ups when they choose a stack um uh they're not fully aware of this uh kind of back door to getting a transaction through.

And I'm not saying the back door is right or wrong. I I think in most cases it's you know the intention for it is great. um but uh we're talking to them about screening transactions at the sequencer and they're not aware that there's another way to get a transaction through. So we end up we end up educating them on that and then you know trying to find a a balance um because at the end of the day, you know, they're just they're they're trying to do the right thing. Maybe they're trying to satisfy some regulatory requirement or some request from a really important user that they have. Okay. So, I think all this kind of culminates in like one big question, which is if you do want to stop malicious non-compliant activity on

chain, where's the optimal place to do it? This is a probably an over overly simplistic version of the tech stack. Um, but we've got layer ones on the bottom, layer 2 zap chains, D5 protocols, um, tokenized assets, and then applications wallets frontends etc. at the top. Um, and on the right hand side here, we've got an example of the mechanisms that are used to screen, block, prevent malicious, non-compliant activity. So, at the L1 level, in the past, we've seen hard forks. Um, we have hard-coded public block list, config file, private block list. Um, those were the two um, methods that were mentioned in that

bybit report I referenced. We have builder validator screening. Um, and obviously the censorship resistant conversation there is has been alive and well for many years. Um, at the L2 app chain level, we have firewalls. We provide one of those. Um, there's also like sequencer level blacklist that chain teams have. Um, you know, they run those themselves. It's usually OFAC related. Um, at the protocol level, you also have firewalls that are, you know, more baked into the smart contracts. You have circuit breakers, which I'm using just to describe automatic pausing uh functionality. You have some teams that have contract whitelists. Um they don't want to let anyone um other than a a white list of smart

contracts um interact with their protocol because you know most attacks and scams are obviously not going through wallets. They're direct contract to contract interactions. Um, at the asset level, certain stable coins have onchain white lists, blacklists. Um, the concept of reversible transactions has been around for a while. There's been some white papers about this, but not a lot of adoption there. It's hard to implement, complicated. Um, and then at the application level, there's a lot more sort of traditional, you know, uh, mechanisms, KYC. You have transaction simulation screening via API. You've got UI warnings. I'm sure anyone that's used MetaMask or Phantom or anything like that has has received some sort of uh warning like that. So, this is sort of

what the the universe of experimentation uh has has looked like in this area. Um and back to the back to the question, you know, where's the optimal place to do it? Um the easy answer is push all the security and um protection mechanisms as high up the stack as you can. Um I think if you want to preserve censorship resistance at the layer 1, even at the layer 2 level, um even at the D5 protocol level, it has to go somewhere, right? These these mechanisms need to exist. Um so where do they go?

They need to go up higher higher up the stack. And I think when you get up there, teams tend to be more centralized. They're usually businesses venturebacked. They have, you know, identifiable teams. Um, and they're probably subject to certain rules. And so it's it's it would not be, you know, you know, uh, it's not it's not a stretch for them to um, sort of bear the burden of um, of doing this stuff. But there's a lot of limitations uh currently if you are limited to only doing security at those layers of the stack. At the

protocol level, um there's a lack of transaction visibility. Smart contracts can really only see message sender and TX origin. Um we tried to push an RP through uh a year and a half ago about this that there just wasn't a lot of appetite. Um so protocols are in some sense kind of blind to incoming transactions. Um and then another thing is if you actually want to introduce firewalls at the at the DeFi level um you you tend to have to sacrifice some composability which for a lot of teams that are trying to find product market fit and attract users and liquidity sacrificing composability is not something you really want to do at the asset level.

again like 99% of you know tokens don't have uh you know a blacklist mechanism. It's really just the large stable coins and it's really just um limited to to OFAC. Um so that's not a really realistic place to impose this right now. And then at the application wallet level that's where you've got the certainly the most flexibility. Um but again like malicious transactions don't go through the wallet. Um they don't go through frontends. It's direct contract to contract interactions. Um, it's also hard to impose good threat screening and and warnings on every wallet. So, you might have the, you know, the most sophisticated wallets, the most

wellunded wallets do it, but smaller ones might not, or maybe they just can't afford to do it. So I think this is this is kind of the reality today which is why I understand why um some of the mechanisms that exist at the L1 and L2 layer um are there and and being used. wanted to look at a couple examples here um just to kind of get people to put yourself in the shoes of um us or maybe a chain or a protocol that's that's facing one of these security events. So simple example, this is something we encounter literally on a daily basis.

You have a fishing contract deployment. So a scammer deploys a drainer contract on chain. These are really easy to detect. Um it's very automated programmatic. Uh they follow certain patterns. It's the same deployers over and over again. contract's clearly malicious uh but at the time of deployment it hasn't caused any harm yet obviously um no victims have interacted with it so question is should the L2 block this deployment um on one hand chain has a responsibility to create a safe environment for end users I say that generally um and if it can it's it's also in the best position to block a deployment no one else can can can do that um on the wallet side wallets should warn a user if they are

interacting um with this contract and I think it's a very reasonable position to say um the wallet is the only one that should really um intervene in this situation right um and obviously the user has you know has to sort of do their own research as well and and be vigilant with how they're how they're interacting so if you're the chain um there's always a risk that you block something benign that's the downside of doing uh sort of proactive uh screening and blocking, right? You might get it wrong and is that a risk that you're willing to take?

Uh at the wallet level, I talked about this on the previous slide. It's hard to force all wallets to, you know, to to do this. I think over time, um you know, certain certain standards, expectations will exist, but right now um you know, there's there's um there's some that do it extremely well, some don't do it at all. Um, so and I think it's entirely reasonable, again I say reasonable, uh, to sort of fall on either side of this. Um, we work with chains that take the first approach. They want to block the deployment. Uh, especially if there is no risk of it being a false positive.

Uh, if they know it's a malicious contract with malicious intent, um, they're comfortable blocking that. We also work with chains that aren't comfortable doing that and they would prefer to push that responsibility up to the wallet and and put it on their end user. And I I understand that position as well. I think that's also a reasonable u a reasonable thing to um to believe. Next one. Um this one's going to be a little bit more uh a little bit more difficult just because the dollar amounts are higher. Um, so let's just let's say a hacker exploits a D5 protocol um on an L2 u but it's for a billion dollars. And I'll just throw another um I'll add another kind of u uh data element here. Let's say the chain

only has 1.5 billion in total TVL. All right. So, you know, 70% is is is gone. Uh, should the chain blacklist the hacker EOAs and freeze stolen funds? Um, again, if you're the chain, you obviously want to prevent an extinction event. Um, this is your business. I assume you want it to continue. You also have a lot of users who are trusting you to keep their funds safe. Um, you want to do right by them. If you're the protocol, um, there's probably some additional things you could have done, but, you know, it's obviously hard to uh account for everything. you can't you can't um you can't prevent um or mitigate every possible risk. Um you also have the

ability to negotiate with the hacker after the fact and maybe get a lot of those back and pay a small bounty. Um so maybe the maybe the responsibility should rest solely with the protocol. The asset issuer again there's not a lot they can do. Uh but um you know to the extent there's a you know a blacklist component in the asset that was stolen um can you freeze those funds and somehow return them to end users maybe. Um so just to kind of look at the downsides here with with with each alternative if you're the chain man it would be very hard for me to not do anything in this situation. Um, I would imagine it would be very hard for for um you also to to say, you know, we're

we're our hands are tied. Um, and let someone particularly if it's, you know, Lazarus Group, uh, walk away with, you know, 70% of your chains TVL. I think that's a really hard decision to make. Um, I think the downside though is if you do it once, you might be forced to do it again when you don't want to do it. fear the protocol again it's really hard to anticipate and prevent everything so it's hard to put all the blame on them but they have certain steps they can take um and then we talked about the you know the asset issuer um that's really not a not a legitimate place to sort of put the responsibility so another observation here is I think when a chain has the ability and opportunity

to intervene we've just seen this historically nine out of 10en teams you know when faced with a security vent are are going are going to intervene and try and write the wrong um otherwise what's the point of having the ability to do it which I think raises an interesting um question um long-term um I'm despite all my comments here uh I'm actually really hopeful that risk management and um other security mechanisms and yep oh I see it now sorry um get pushed up higher in the stack um and I think it's going to happen with more decentralization and I think something that gets talked a lot about

now obviously is uh private transactions right if if you do those two things uh and you remove the choice at the L1 and L2 level I think it makes it a lot easier for these chains uh to not act in those situations but if you if they have the ability to do something they're going to act like humans and they're going to try and and do the right thing uh when they see a wrong happen. So thanks again uh everyone apologies I went over a few minutes Thanks Andy. Sorry um pack scheduled but thank you so much.

Thank you. >> All right, we got our last talk of the session. Um please welcome Ben Burger, research scientist at Offchain Labs. He's going to talk to us about economic censorship games in fraud proofs. Right. Ben, you're up. This is not your Okay. Let's see if this works.

>> Okay. Hi everyone. Uh wardes and my name is Ben Burgerer. Thank you so much for coming to this talk. Uh so I'm going to tell you about joint work uh with uh Ed Felton Akimilli. both of these are my teammates at offchain labs and with Benny Sudakov who's a professor at ETHZurich. Okay, so I'm assuming that everyone here has heard and knows about L2s. Uh but still I want to give a very very oversimplified introduction to what these are. So we all sort of have a similar mental model to think about about these uh in the context of uh of this presentation. So layer 2s as we all know uh this is uh the main scaling solution for Ethereum today meant to increase Ethereum's limited uh

throughput problem and a layer 2 uh like uh any blockchain will receive uh process and order a sequence of transactions and the computation of each such transaction updates the state of the layer 2. Um and every once in a while um uh the uh there will be some party which uh posts the current state of the L2 onto Ethereum with the goal of convincing Ethereum that this posted state is really the true result of the computation. Um so and the idea is to offload the expensive computation off of Ethereum and use Ethereum just as a means to record and verify that the computation went correctly. Uh so in this picture uh these uh orange uh

rectangles at the bottom these are uh like the intermediate states uh resulting from the computation of these subsequences of transactions and each of these orange uh states will be posted onto Ethereum at some rate. In the case of arbitum this happens roughly uh once every hour. Okay. So of course what is the challenge of such a system? uh how do we convince a how does the layer 2 convince Ethereum that the posted state is indeed valid and so there are two main approaches for doing this today there's the zk rollup approach which I will not talk about and there's the optimistic approach which is the main subject of this uh talk and so how do how does the proving mechanism work in an optimistic rollup

well each interested party can submit their claim on what is the current state uh of the layer 2 and in case that there are more than one uh uh claimed states then there is a dispute which is resolved via an interactive protocol which is run uh and governed by a set of smart contracts on Ethereum and this mechanism is usually called a fraud proof a fault proof or sometimes a dispute resolution protocol and the idea is that uh at a very high level without getting into the details the competing parties will submit moves uh to this protocol and each such move uh is uh uh an Ethereum transaction which sort of reduces the dispute in question uh in a

recursive manner and when designed correctly uh these systems have the very nice property it's called sometimes a one out of n property that the honest party that represents the correct uh claim is guaranteed to win if and this is a very big if all her moves uh indeed get processed and included in the canonical uh L1 chain. Okay, so as I said, these protocol moves are Ethereum transactions and because of that they might be prone to censorship which in this context is defined as any malicious activity which is intended to delay or exclude the inclusion of a transaction from from L1. And in the

context of fraud proofs, the censorship of honest moves uh what could happen is that the wrong state can be can get confirmed in the end which is of course a total catastrophe uh if this happens. And so to mitigate against this possibility um the parties in these protocols get a significant uh time window to have all the required moves uh processed on chain. Um and this is uh this time period is called sometimes it's called the challenge period in different context it's called the withdrawal window. Um and the idea is that if a party's uh timer run uh runs down to zero then that the the claim that that party represents gets

disqualified from the from the protocol. And so today this challenge period is set to about one week in the major optimistic roll-ups. Uh and this is aimed primarily against so-called strong censorship attacks uh whereby the the the potential attacker is assumed to control over 50% of the L1 stake in which case it has full jurisdiction over which blocks are added to the canonical L1 chain or not. And so this attacker will decide to remove a block that contains the honest parties moves in the fraud proof system. So this is of course a doomsday scenario for Ethereum. Um but uh but there are other forms of uh

censorship that are possible m much simpler to execute and it's not clear uh how the challenge period defends against these types of censorships. Uh so this brings me to the topic of this work um where we consider what we call economic censorship attacks and and in this attack the attacker what it will do. So these attacks exploit the fact that the L1 block proposer at at any block has full power over the contents of the block. And so the idea is that an attacker will go to this block proposer and try to bribe him to exclude the honest party's transaction uh from the block. So the scenario that I want you to have in mind is that uh if the

defender or honest party that submits the move offers the proposer a priority tip total priority tip of P then an attacker will try to will offer a bribe of B to the block proposer and the bribe will be successful if uh B is greater than P. So of course if if this bribe is successful at some block then what will happen? Well, the defender's move will not get included in that block and so its timer ticks down by by one block and and and so the time to get the moves on chain decreases. On the other hand, the attacker paid the bribe and so its budget for free future bribes uh

decreases. On the other hand, if the bribe is not successful, well, the defender is one step closer to victory because it got its move in, but the defender also has a budget and that also decreases. And so the goals in this project were to sort of try to understand the dynamics of these sorts of attacks in the context of fraud proof systems. In particular, we want to understand we wanted to understand what beating strategies or what strategies the players will use, what are the optimal strategies. Um and ultimately we want to to know who is expected to win uh this sort of contest given the parameters of the of the system. And in the end we want to understand what is the meaning of all

this uh for the security of optimistic rollups. Okay. So with this goal in mind uh we study uh we studied a stylized uh multi-round game model between an attacker that's wants to censor a defender which is the honest party h and the L1 block proposers. And this multi-round game is parameterized by these four parameters. T this is the total number of rounds corresponding to the challenge period. The length of the challenge period and this is the number of of those T rounds that the defender needs to win. Think of this as the amount of transactions the offender might need to put in the to to include

in the fraud proof uh protocol. A is the attacker's budget for censoring and D is the defend the defender's budget for getting all his moves on chain. And in this work we study three variants uh of this which differ in how a round is conducted. And the main question that we try to answer uh is how large does the attacker's budget a need to be relative to the defender's budget as a function of all these parameters uh such that it can guarantee uh victory in the game.

Okay. So um the first model and now I want to explain uh go more deeply into the results. So the first model that we study we call the G1 game. This is like the the uh straight most straightforward model you might think of uh for this uh which models a world with alternating rational block proposers. And so it each round corresponds to a block and what will happen is that the defender will offer a bid B. This is like the tip that I talked before which is upper bounded by her budget D. The attacker will get to observe this bid and then offer a counter bid B prime again upper bounded by the budget A. Um then the attacker will win the round if and only if uh B

is smaller than B prime and the winner of the round will get her budget deducted uh by exactly the the the amount that they bid and then a new round begins. And so the defender's goal is to win n of these rounds. This is just a single round what I explained here and well the the attacker wants to to win essentially the the t minus that. Okay. So this brings us to uh like uh and what what can we uh show here uh we show that in this game as I presented the attacker h can guarantee victory if and only if this inequality holds. So if t minus n +

1 / n * d is smaller than a. And so uh what this shows you is that the larger the challenge period t is uh the more funds the attacker needs to use in order to guarantee victory. Right? If t if t increases then then a needs to be bigger as well in order to be able to guarantee victory. Uh and so this is consistent with our intuition that the bigger the challenge period is uh the more secure the optimistic rollup is. Uh and I want to go over the simple proof of this just so you get an idea and I'm going to uh prove the if direction. So let us assume that this

inequality holds between the budgets and I want to show you how the how the attacker can guarantee victory. Well consider the following strategy by the attacker. What it will do is it will see the the at any uh round it will see what the defender bid. If the defender bid more than d over n then it will just let the defender win that round. Otherwise the attacker will match the the defender's bid so that the attacker wins the round. And the observation here is that the defender cannot win the entire game um because she doesn't have enough budget to win n rounds. On the other hand, the attacker does have enough

budget to uh to do this strategy and win the attacker's required number of rounds which is t minus n plus one. Okay. So okay so this is like a very simplistic model but still to get an idea what does this mean for example in the case of arbitum bold which is arbitum's fraud proof mechanism. So if you assume that the budget of the attacker is $15 billion which is uh depending on what day you check is roughly the TVL of arbitum one and plugging in n equals 60 which is uh roughly the amount of transactions in one path of bisection that that the defender will need to do. And if you

plug in t equal 50,000 50,000 blocks, which corresponds to one week of a challenge period, then what this tells you is that the defender can guarantee victory only if it has at least $18 million. Okay, so that's what this tells us. And of course, $18 million sounds like a lot. Uh which motivated us to sort of refine the model and and so so we can get better results essentially. Um and so and so this motivated us for uh to study the next variant uh which we call the G1 sub K game. Here K is some constant larger than one. And this game is very very similar to the game I

showed you before but now we have now two types of rounds. We have the regular rounds which are exactly like before and we also have special rounds uh which are conducted as follows. Basically they are conducted in the same way like a regular round only that in order if the attacker wants to win the round it needs to outbid the honest party by a factor of K. So these are rounds where it's much more expensive for the attacker uh to uh to to win the round and and so uh and so in addition to the parameters TN h and the budgets D and A from before we also assume the the game

is also parameterized by the like the configuration of regular and special round. So we assume in this simple model that uh both players know exactly in advance which rounds are special or not and they can maybe take advantage of this in their beating strategy. Okay. So now what is the motivation or where do these special rounds come from or why why do we even think about them? Well, so uh today it is estimated that about like between 2 and 5% depending on who you ask for the analysis uh between 2 and 5% of the Ethereum proposers um don't like the way that they build

their blocks is not through the more common proposer builder separation or mev boost framework but instead uh to build their blocks they rely on the default block building software um that is uh that is provided by the by the execution client by by essentially all execution clients uh of Ethereum. Uh so this is like they consider only the what's called the local block instead of like externally built blocks. And the way that this block building uh algorithm works essentially is that the the proposer will look at all transactions in its meool. it will um sort them uh by decreasing order of priority fee per gas and it will just

include the transactions. It will include transactions in the block one by one as long as there's still room in the block, right? The block has a gas limit. Okay. And so why is this relevant uh to us? Well, in the case of bold, uh a a typical uh bold uh transaction in the fraud proof consumes around 500,000 uh gas. And when Fusaka uh uh will uh will deploy in in a few weeks, uh the gas limit in Ethereum will be uh around 60 million gas. And so what does this means? Assuming that the bold transaction that the honest party is willing to put a priority fee which is the highest one among all the regular

transactions in the me poolool which is I think it's a reasonable assumption then if an attacker wants to censor that transaction when the block proposer is of this type it will need to submit to the public meool uh more than 59.5 million worth gas worth of transactions with a higher priority fee than the bold transaction. And so this is this is where this parameter K comes from. This is 59.5 over 0.5 uh times as much as the defender would pay to to get the transaction included. So so so so the the bottom line here is that to to censor here, the attacker needs to pay 119 times more than the defender would

pay to get the transaction in. Okay. So Okay. So now just a bit more into the the analysis of or what we did here. So to recall our goal here was to again understand how large the the attacker's budget needs to be uh in order to be able to guarantee victory. So to this end we we define as a tool this curly a expression uh which is the mi the minimum budget a such that the attacker can guarantee victory given the other parameters of the game. And our goal here is to calculate curly A.

Basically telling us how much the attacker needs to bring to the table. And so we prove first the lema that this curly A is uh is linear as a function of D. And also that its only dependence on the special round and regular round configuration is just on the number of special rounds but not not on their location within the entire sequence of rounds. So what this means is that we can redefine curly A to be just a function of TN and S where S here now is the number of special rounds out of those T rounds which is the minimum number R such that the attacker can guarantee victory given TN and S if and only if the ratio between the attackers

and defender's budget is at least R. So this was a lot to digest but just to give a flavor what we proved in the first theorem for the simple model is that in in the case that there are no special rounds but that that was the previous model curly a of tn and zero is t minus n +1 / n. So this is the ratio between the um the minimal ratio between the the budgets such that the attacker can win. Um okay so for a very long time uh we tried to find a closed form for like a nice formula for this curly a but we couldn't um but what we did do is uh is uh find a recurrence relation that it

satisfies so basically there are these boundary conditions that allow us to compute it for like edge uh boundaries and we also have the recursive step that tells us how to compute curly a of tnns given like smaller instances. of um of this function and so I'm not going to go over over all of this but uh the observation from this is is first of all because of this recurrence relation this means that we can compute or calculate this curly A in time which is uh O of T and S uh via dynamic program dynamic programming and this is feasible to do uh for the parameters that we find in practice and also another artifact of The proof

is that the optimal bid by the defender is always a fraction of her budget. Uh which only depends on TNA. So it doesn't depend, we don't need to assume that the defender knows the attacker's budget or something like that. Uh so if we believe this model and we again plug in the relevant parameters for bold, we find that this ratio is uh $2718 which again if you assume that the attacker's budget is $15 billion. Then now the defender only needs $5.5 million in order to be able to uh to get to to sort of mitigate this economic censorship as opposed to the $18 million from from before without special rounds.

Okay. So, uh I'm not going going to go over all this to for a lack of time. I just want to talk a bit about future work and like what we can take from this. So, this was like uh init this work is sort of an initial attempt to incorporate this very realistic possibility of economic censorship on L1 to the fraud context. uh but this is still you know a a simple model and there are many ways to extend it to uh to sort of get more insight uh uh for the practical relevance of this. So for example uh as a as an example in bold uh or I think in most other optimistic rollup systems uh the attacker can effectively increase n by placing a new

stake in the protocol. So how do we include that in the model and how will that change things? Um so I think it's important to understand another thing is that the bids and the budgets that we uh talked about here really only capture the priority fees that are paid to the proposers but not for example the base fee that is burnt and so the proposer presumably does not have interest uh in that. So uh that also should be incorporated in future work. Uh and one last thing is that I'm finishing 10 seconds. Um is to consider more refined utility functions or happiness functions. So here the defender really only cared about winning or about winning. So he didn't care

about how much of his budget was sort of spent for this purpose. But in practice of course the defender would want to both win the fraud proof protocol and while losing as less of his budget as possible. So I think that that is also an interesting direction for research. So >> thank you Ben. Thank you so much. Sorry running out of time. Um >> my apologies.