L2 Interop Working Group #16

Transcript

Okay. Should be visible. Okay. So, yeah, I got asked to to say a few words here. Um I like this is not a new conversation. Uh this is something that um has been ongoing for more than a year probably. And this conversation started um mainly when the first uh single round for proof systems uh came out. Uh there was a big discussion I remember um from these teams that were saying uh we can reduce the challenge period because uh if you do one step instead of 60 uh you need less time to to play the challenge, right? And and you know and this was uh because of a misconception

that the seven days are needed because of the of the many steps is not true and you know and that's kind of where it started. uh now you know over time we kind of uh understand more uh what's the trade-off uh but yeah so let me let me get started um so again the reason we have um the seven days is because we want to protect the rollups from strong censorship attacks and strong censorship attacks means you have a majority of validators that are malicious and they will not attest to blocks that contain uh for proof transactions Right. And if the majority of validate resis issues

um they can censor uh indefinitely and we say actually uh this is not indefinite because uh the Ethereum protocol will coordinate a fork uh to get rid of the sensory validators. So after the fork, censorship resistance will be restored, but we need the fork, right? And and you know, it was not uh at the time like super clear uh what was like the exact timeline. uh I wrote this article uh that was trying to to come up with uh with a tentative timeline and uh this timeline kind of estimates that uh we can fork in 5 days. Uh we can

coordinate, implement and activate or fork uh either a software or a hard fork uh in five days. Uh which if you think about it uh it's already very tight. Um and um so again there's this assumption that uh if you have a challenge period of seven days um Ethereum protocol will uh make sure that censorship resistance will be restored and most of the proof systems that have been designed uh like that have been studied um uh are based around assumptions, right?

So, this is bold from off labs. Uh if you read, you know, through the paper, they say, uh we have this Cmax value. Uh that is the bound of the censorship budget that the attacker has. The we we we assume that the attacker can sensor can delay transactions uh but not more than uh this CMAX value. And we say that this CMAX value is around of the order of a week. uh here uh the paper says that this is a conservative estimate. I kind of disagree with that. I don't think seven days is conservative. I think it's pretty tight. Uh but in any case like the safety of the system or like the security of the system is based around

the fact that censorship will not be indefinite and eventually it will be resolved. Uh this is so this is from bold this is from Dave uh which is another uh proof system from Carteesi. uh they also have a censorship budget they call it uh TC and again it assumes that this is uh one week uh and again if this doesn't hold the system is broken uh so we kind of assume that um and something to keep in mind is that you know uh on Ethereum if there is if you have funds on Ethereum and there is a majority of validators that is malicious these validators the attacker cannot

steal funds from you. Uh it can double spend, he can censor. But like if you have ETH in your account and doing nothing, uh the attacker will not be able to to steal these funds from you. And for this reason, uh we should expect the same from the roll-ups, right? So if you say roll-ups get the same security as Ethereum, ideally at stage two or whatever, we should expect the same property from the roll-ups as well, right? Uh but you know what we want to argue here is kind of okay stage one is supposed to be something in the middle uh between stage zero stage two. So maybe we can relax a little bit um the security assumption also because we have a security council we already have you know this this strong assumption that security council

will not r the chain. So maybe you know this is not that bad for first stage one right. Um so let's say that we agree that it is okay to have this assumption that uh 51% attacks will not happen and um also let's assume that the TVS the combined TVs of all the optimistic roll-ups will remain well below the economic security because otherwise uh it becomes profitable to become to to to do this attack and this is like systematic risk that Ethereum has as well. uh this kind of scenario similar to uh liido that needs to self-limit right I hope uh optimistic rollups will not need to uh to do this uh but also you know um it kind of gets to to the

same conversations so okay let's assume all of this uh that we are okay uh with this risk um and if we do this we now to study what is a safe lower bound for a challenge period uh to protect ourselves from soft censorship attacks so builderdriven uh at the station driven, right? And uh first we need to kind of understand um how the like builder or like um building block market works and I kind of tried to to look into the you know top consensus clients and I was not super familiar with this uh but like uh just for everyone to know the way that

validators choose a block uh when they're connected to builder is um they build the block locally. based on the transaction in demand pool they get the bid from the builder and if the money that they get from the local block is more than what they get from the builder they will build uh using the local block right and the local block has the you know censorship resistant property because you know you get structur by tip whatever um so the builder needs to pay you to convince you not to use your local block right so it's not that if you're connected to a builder it's not that to just accept whatever block uh without thinking. Uh you compare uh the block

that the builder gives you to the like you compare the builder bits with the uh tips that you get from the from the local block. Uh so this is good because now there is a cost to the attacker um to to censor transactions right to prevent you from including a transaction uh that is paying enough from the MO. Uh otherwise if this is uh this was not true um the attack would almost be free right but but but um it is not and all these nodes all these softwares have some patterns uh with good default values uh to do this. Uh if it's 100% uh it means that if the local block has

more value you would use that. If it's 90 for example and a lot of projects use 90 it means that the builder block needs to be more than 10% or more profitable than the the local block and luckily uh we have offchain labs that writes good paper. Um so um earlier this year uh after loaves published an analysis around the cryptoconomic security of challenge protocols exactly under this scenario when uh there is an attacker that can do soft censorship attacks. Right? So uh if you go through the abstract they say uh major major optimistic rollups today set this period

at roughly one week uh talking about the challenge period u mainly to guard against trans censorship that undermines Ethereum's own cryptoconomic security however other forms of censorship are possible and the replication and optimistic role of security is not well understood and this is what uh this paper uh tries to do uh and uh it's very good u and this paper I will go briefly to to what the paper says. Uh but it tries to model uh different type of scenarios. Um one of the scenario which is the simplest one which is the one that I will go through is uh there is a challenger that wants to uh send a transaction uh to a challenge a malicious state route. Uh this

challenge this transaction will pay a tip and now the attacker needs to pay more uh so that the validator accepts a block. uh the sensors, right? So, uh the game is the validator will accept uh the transaction from whoever beats the most, right? So, if you have let's say a transaction from the challenger in the man pool with one e tip, uh the attacker needs to beat at least one e uh at every block to prevent the transactions from getting in.

So and also uh they also model different type of games where a certain percentage of actors is just uh building blocks locally. Uh and then they also model uh the scenario where false is implemented. Uh but I will not go through them. Uh let's go through the simple scenario where all the validators are delegating to builders and they will accept either the local block or the builder block based on who paid who pays the most. And since the uh fraud proof game is interactive um the challenger needs more than one transaction uh to to settle uh a challenge a fraud proof, right? Um so

if the defender which is the challenger let's say has a certain budget it will need to divide this budget based on the number of transactions that it needs to submit. So we have t here which is the total number of rounds that you can also see as the total number of blocks that there is uh during a period. So if we have one day as a challenge period t is the total number of blocks in one day. N is the number of uh let's say steps that the protocol needs to make for one challenge to resolve. And then there is Alice budget which Alice is the attacker because it starts with an A and D area is the defender because it starts

with a D. And you know uh in the end they come up with a formula that says okay if the attacker has this budget the defender needs to have this other budget. uh and so the defender budget is calculated as a function of the attacker budget and the attacker's budget can be fixed to for example the protocol TDS right because if let's say arbitrum has $10 billion in the bridge the attacker can spend up to $10 billion uh to steal money from the bridge so now you need to calculate okay to protect $10 billion of value how much money the defender needs to have and this is you know uh very classic, you know, cryptoeconomic analysis um where an attacker can uh

exhaust the resources of of a defender. And if you go to chapter six, section six, uh they do the math and the result is that the defender to protect $10 billion needs uh at least $12 million. Uh which is a lot, but it's not that bad. Uh and I'm going to also explain why it's not that bad. Uh but this assumes that the number of rounds that the defender needs to win or like the number of steps that the challenge a challenge takes is 60 and this is based on both uh like the uh the depth of the game is uh 60. So uh the defender will need 60 steps.

I think uh it's a little bit more complicated than this uh to be honest. And you know while this analysis is is very good um you know there is there are two form of cryptoconomic attacks that can happen on challenge protocols and this is something that I discussed at Devcon uh last year um in terms of civil attacks that you can do on optimistic rollups. So like if you have an attacker that proposes uh invalid state roots um it might not be enough to play one challenge, right? Because an attacker can just post 1,000 invalid state roots.

So you may need to play 1,000 challenges. And if you need to play more challenges, it might be that the number of steps is more than the number of steps that it takes to resolve one challenge. Um there is a cost usually associated to opening new challenges. You may need a new stake. um and different for proof systems. Um you know I also posted a very long article explaining all the trade-offs between for example bold proof system and optimism opfp and cartesi uh proof system. Uh if you want to read it uh it like um I present like the the full trade-off in terms of large bond size, small bone size, full concurrency,

pressure concurrency, whatever. uh if you want to read it or like listen to the talk uh it's called proofs war um but basically there is what what I'm trying to say is that there is already a an economic attack that is possible on optimistic roll-ups and uh this and these economic attacks are measured based on what is the advantage that the defender has uh on the attacker right so we said before, uh, with the paper, we see that even if the attacker is willing to spend up to $10 billion, the defender just needs $12 million. So,

the advantage is pretty good uh in this case. But the problem is this advantage is lower when we consider uh dissolve their form of cryptochcomic attacks that has nothing to do with censorship like these attacks exist even in the absence of censorship. And again I don't have time to go into into the details of how this works. Uh but for example bold uh for the like the advantage the defender advantage for bold is around 66.5 uh x. So this means that if the attacker is willing to spend 10 billion the defender needs to have at least 1.5 billion already. So this is like again ignoring censorship per optimism.

uh this ratio is 0.91 uh is much much worse than arbitrum and in practice it means the defender needs to have more money than the attacker uh to protect the protocol and you know arbitrum is better but again it's not is not like amazing right uh it's not uh the same as zoloph if you want to use that as a comparison uh but usually people say okay $1.5 billion is a lot but this is fine because at in the end uh the winner will get all the money back plus a reward from the funds that will be slashed from the attacker. Uh so it's a lot of money but probably we can find people that can

pull funds together and we'll make a profit eventually, right? Um so the problem is while is this true that it might be easier uh in this case to to pull the funds and reach you know these very high amounts of money in the censorship case um you lose the money like you will not get this money back uh you need to spend this money in tips and you will not get it back. So I argue that it is more difficult uh to spend the same amount of money in stakes versus uh in tips uh to to be able to pull to pull the funds. And the paper also uh fixes the number of rounds uh that

that it uses to calculate this 12 million that discussed before. But this number is not fixed because as I said before the attacker can spend his budget to create more challenges uh increase the number of rounds that the defender needs to needs to win, right? And if you do the math um you know the relation is not even linear. It's faster than linear but like 60 rounds which is one challenge. The defender needs $12 million to protect 10 billion. If you have 10 challenges, let's say 600 rounds, and this is again a simplification, but like just to just to give some numbers, uh the defender needs $120 million. And for

uh 6,000 rounds, it needs uh 1 billion or and something dollars, which is similar to the other type of uh economic attack. But but again, in this case, the defender will not get this money back. So it's arguably worse, right? Um so what I'm trying to say is that we need to understand how this uh economic attacks that can happen around censorship uh how they play together with the economic attack that are already possible because of other reasons because of civil attacks on on censorship and we need to understand like based on the attacker's budget whether for the attacker it makes more

sense to uh let's say spend this budget on stake or spend this budget on uh censorship or like how the two things play together, you know, because again uh it could be that one stake induces more rounds and more rounds induce um more spending to the defender and also the attacker one thing that they can do is force the defender to spend money in a way that this money will not get back to the defender, right? So instead of forcing the defender to spend his money stake, it would force the defender to spend his money in tips.

Um so what I'm trying to say is that you know this is uh this is complicated and and I don't think it's very clear uh that a protocol would be safe with uh a challenge period of one day. like it's not clear how much money we need to reserve for propers uh to protect ourselves from cryptoconomic attacks. Uh the good news is that if we had fossil uh fossil would get rid of most of these concerns. Uh also in the paper they they do the analysis where fossil is presented and they say uh the money that the defender needs is uh under 1

million uh because like censorship resistant guarantees is are much much better. the um attacker needs to spend way more money uh to to censor um than the version that we we just discussed. So I think it's a good idea to you know uh push fossil if this is the uh what we what we want to do also like pragmatically speaking I really believe that today uh most of the stage one projects uh if there is indeed an attack like a serious attack will not use the challenge protocol uh to protect themselves. I bet that if something like

this happens, uh the security council will be used to just get rid of the the malicious state in one way or the other. And if this is the only like realistic safeguard uh to these crypto attacks, I don't think we can consider uh these projects as having fully functional proof systems, right? And uh on to be right now having a fully functional proof system is not even a stage one requirement, it's a stage zero requirement. uh so you know I think we need to be to be careful uh around these things. Okay. So uh apart from uh all this discussion we also need to get realistic or like discuss what are the benefits to go from seven days to one day uh or like two

days or whether there is you know significant difference between one and two uh in some way or the other and um we didn't get a lot of comments to be honest on this and I hope you know some other people can chime in. Uh we got one comment in the in the research post from Hart which is no founder of uh across the internet protocol and he says you know one day is of course uh much much better than seven days. Um but also you know um it says where we was where we want to get to is 1 hour bridge or like few hours bridge right um a challenge period in the other of

hours is of course unrealistic very unrealistic and there is also Greg representing like uh solvers um says that of course one day is better than seven days but at the end here it says my gut instincts say that if you go from 7 to 1 day, we might see the LP go down by a marginal amount, say 20 to 30%. Simply because the cost of locking up is still relatively high and the manages are already so low. Um, and uh and you know at the top also I missed out it says uh reduce deal to exit window market but only if it's done in a significantly more dramatic way I'd argue down to a few hours. So like to me

again it's not super clear that the advantage from going to 7 days to one day is that big uh to cause all these potential issues in in uh cryptoconomic attacks that's forces force us to use security councils all the time uh if these things happen. and I would love to get uh like more opinion of this uh if uh if people have some uh and I'm not really sure that uh like end users not even solvers uh will start using the the the canonical bridge compared to let's say a cross or like other interro codes. Um so that's all I had and I couldn't read the

chat so I will do it now. Thanks, >> Greg. >> Yay. Can you um Yeah, thanks for that. That was really, really well done. I just want to speak. Sorry, this is Greg. I wrote the post um or wrote the reply. So I I think there's like one key thing to understand here which is like especially when it comes to market makers, LPs and AMMs, arbitrageers, you know, anybody really in that

category. Um it doesn't, you know, the name of the game for us and these folks in order to use the native bridge is like how many rebalances I can get in in a day and at what cost. And that's why like unless you dramatically drop it to, you know, an hour ideally, you know, that'd be great. Uh the, you know, I'd rather just like take the risk for $12 to send it across Binance. You know, Binance is like maybe a buck, a dollar to move in and out, right, to mainet. And I can for like $12 in a day get like anywhere from you know eight to 12 rebalances in. And

so for most people it's probably you know there's higher incentive to wanting to just like get it done faster and we operate over rel our books are relatively centralized as is. So for us it doesn't matter. And so that's why I don't think like us as the end user it's going to solve a whole lot of problems. What it will solve is it will bring the cost of capital for teams like across to run their LP system and that's the one that settles all the like fast exits for solvers to like move across and that's great right that will have a dramatic reduction in the amount of capital I need to held instead of seven days worth of capital because of one day of capital um and it might change the rate slightly

but I don't think you'll see a huge dramatic shift in the end user because you'll probably just uh watch the total liquidity in that those pools just ride the utility curve, right? The same way like an a curve, the pricing of an a curve, a lot of these LPS will drop out, the fees will go to zero, and then it'll probably rebalance back to roughly where it was before, maybe a slight maybe a slight discount just because some people will stay in it for longer. Um, so it has huge benefit and I'm all for dropping the time because I think it makes overall capital efficiency much smoother where you have to use the native bridge in the true you know and the protocols that actually follow like you know a true

decentralized uh you know by using the native bridges but it's not going to dramatically improve end user experience in my opinion and it won't dramatically improve the market maker solver landscape as like we just still won't use it. Um because it's, you know, one rebalance versus upwards of like 12 to 20, you know, just depending on how many you can do in a day because the user volume is not going to change, right? It's just the it's just the amount of capital needed to process these transactions faster is what what dramatically changes. Um yeah, I think that's like the main gist of what I what I'm saying. And I think Hart is also relatively in line with

that. I don't want to speak on behalf, but he based on his comments kind of similar. >> Um, I wanted to jump in and just uh maybe outline a few points that Greg, I I think we're mostly on the same page, but I might I might quibble on a few points there. I think the way the way I think about these L2, And by the way, I'm I'm Matt from across. Um, I don't think Hart can make it today. um he might be on the call later but um the way I think about it is like when you have birectional flow if you have like equal flow in both directions you just net everything off and it's fine but if you do have directional flow off of these L2s off of a particular L2

um somebody's going to be left holding the bag like somebody has to be waiting in the 7-day bridge with those funds whether it's Binance whether it's across his LPs somebody's got to be holding the there. And ultimately, somebody's going to have to pay that cost of locking that capital up in the bridge. Um, and so where I push back a little bit on what what you said, Greg, and and I'll leave a a more detailed comment um in the thread um like in the in the ETH research post, but um the like that cost is going to be paid by users like users to get off that chain. If there is directional flow off the chain, they are going to have to pay that rate. um for somebody basically taking you know lending them the money

to get their funds off quickly. Um and so like you know ultimately that cost is going to be borne by users. Um and like the across LP fees I think would go down substantially. Um because the rate that a user pays on a particular transfer is different from the rate that an LP gets. If you think about it this way, like an LP holding their capital for seven days, you know, having their capital in the system for seven days, they could support seven transfers over that seven-day bridge with with, you know, with a week, you know, holding that holding that dollar there for a week.

Whereas in the current, you know, with a 7-day bridge, they can only support one transfer. So, you can think about it as a user basically an LP can support more transfers with the same dollar. So they get paid they basically get paid more while the users get paid you know have to pay in less. Um so this does make like systems like across much more efficient and basically means that users pay um you know in terms of the capital cost they're paying on these transfers they should see a roughly 7x lower cost. Um once again this is for directional flow off of the L2s. Um, so I do think that reducing from seven days to one day would be a pretty big deal for user costs, for ease of of moving capital off these chains. Um, especially when you

see directional flow and at a cross like, you know, we've we've we've sort of been in the L2 space for a while. there are, you know, these things go through es and flows and we have seen massive directional flows off these chains at during periods of time and like our LPs just get super utilized because, you know, there's a bunch of people trying to move ETH off particular chain because there's some farming opportunity somewhere and um and this puts a lot of stress on the system and drives up costs for users because we have to sit here waiting for seven days to get the buns back. Um so yeah, I think it would be a big deal.

Um I think one hour would be much much much better but um but yeah I think any reduction here would be would be you know helpful to users and impactful. >> I wanted to bring back the focus to security for a bit for a bit following up on what uh Danu mentioned. So um yeah this discussion was triggered a year ago about a year ago um largely because of a non-interactive um protocol being promoted and um the claims it had made about um finality.

there are there is a lot of nuance here. One thing to note is that um by the way I'm Rammy. I'm from Boundless. I worked on that non-interactive protocol called the Kyua and some of the nuance there was that even if you have a challenge going on you can still have um very low delays because you can resolve that challenge as fast as you can computer proof. So you don't have to go and play out a full non-interactive dispute game and spend the whole 3.5 or 7 days playing that if a dispute happens. you can just shut that down immediately. Um the other nuance detail to uh also bear

in mind is that um a non-interactive protocol like Kyua means that these uh economic attacks or whale attacks that are possible today in uh interactive protocols are not possible in a non-interactive one. mainly because no matter how many disputes an adversary opens or how many state proposals an adversary submits, um the honest defender only needs to submit one honest proposal every dispute period and that automatically prevents um any of the adversaries um proposals from being acceptable. the proofs then come in

later at any pace to uh eliminate these uh bogus proposals. So that ties into the analyses that Donno had mentioned. Uh so if we even if we consider a uh proposer builder model where we have to bear in mind um the uh censorship budget. So we're not talking about 50% attacks. We're just talking about bribery essentially. Uh so if we have this one honest challenger transaction um basically have its fees set to be the collateral the entire collateral requirement um for

participation in the protocol you get a completely different cost uh of attack. So for example, let's say this uh fee is uh one ETH, just one ETH to put up as collateral to participate in the protocol. Um and you want to bribe all the proposers, let's say they are 100%. they are dominating 100% of the blocks and you want to bribe them for a full day. um then you basically need uh 72,000 ETH right to spend to do that attack and that's assuming you know PBS is 100%

because if PBS is just you know 1% off um that transaction should be landing within a day right um and these are details that are often often overlooked and I think when we want to analyze this and come to a reasonable conclusion. We have to differentiate between interactive and non-interactive protocol protocols. Even if you know the interactive one in consideration has a pretty good um defender to attacker ratio.

>> Uh Paul. Hi, I'm Paul from Opie Labs and uh I wanted to follow up on what Vammy said uh because I think right now is a good time to talk about this when optimistic ZK is also available for many people to use and I think um the 7-day L1 hard fork assumption is quite optimistic and a lot no pun intended and this is a lot of this hangs off of that original assumption and with dispute games interactive dispute games it doesn't matter that much because you still have this three-hour uh transaction inclusion times your number of transactions for the whole dispute game and it sort of

works out the same. But if you have an optimistic ZK then essentially you need one transaction to to uh challenge it and I think that's that's kind of relevant now. Thanks, Paul. Toris, >> hi. Um, I want to mention a couple of things, different things. Uh, I think there's a bunch of confusion here. First of all, it's it's completely irrelevant for the window for the withdrawal window. It's completely irrelevant if you're interactive or not. You only care about censoring the first transaction.

The interacting protocol can just automatically go on chain into like 10 months Chinese protocol. I don't care. So you only care about that very first transaction that triggers the the challenge. So that's it for any system. We only care about censorship for one single transaction. Now I would phrase the whole discussion here not in terms of a tradeoff of yes we all know this lower security versus this is what we're going to gain on capital efficiency or whatever it is. It's not such a trade-off. I think we should actually define as with when you're designing any kind of system what are the boundaries that we're trying to work with what are the security assumptions that we want to guarantee our users and given this set of constraints this is what the challenge

protocol should be or this is what rollup should be we should really get into in in aligned into what are the security guarantees that we we want to provide our users we might agree or might disagree on we rollups should be resistant to a 51% attack on on Ethereum like like Ethereum users are or or might not agree on this. But but the whole point is that uh we should set the line of what are the security assumptions that we're willing to guarantee and once we have that and we agree on that we can design a system and we can talk about like deadlines for Windows or not. Uh regardless regarding the the challenge the sensoring for one day or 7 days or whatever it is it's a single transaction. uh there are changes on L1 that uh that we can propose regardless

of fossil even uh fossil certainly makes the economic guarantees much better than the than the current guarantees. Um because I mean this is already in that paper that was mentioned by by Luca like this multiple proposers make the economics uh attack much less profitable but it doesn't account for the 51% attackers fossil just that you you don't even need to include the transactions if you have a 51 attacker they can just vote a block as valid even though it's censoring what I wanted to mention is that strong censorship and even that fossil censorship can be detected on chain. So the challenge protocol can onchain count

with very strong statistical inference how many blocks were reordered by the attacker can be can count how many inclusion list bit list were not included or not satisfied and these kind of things that can be said on chain we can uh we can just immediately delay onchain the protocol. So oracles for these kind of things exist if we decide to implement those things in L1 and then we move the problem to just purely an economic problem that we can actually analyze as it was analyzed and we can just measure what is the censorship that we're guaranteeing our users or not. So I think we should like set those parameters first and then talk about capital efficiency which I think is just secondary to these kind of problems. If I if I can jump in, I I disagree because

I think that the argument isn't we know what we want the security we want L2s to have. We want L2s to be stage two. The argument is that because of the requirements of of these security guarantees, which is the 7-day withdrawal window, users do not actually get the security of the L2s because they're using trusted bridges and synthetic assets. So the argument is that we we know what this what the security we want is. The argument is that by enforcing this security the users are actually not getting it. And so that I think is the argument. So I kind of disagree there. >> I also disagree with the idea that it doesn't matter how many moves you have to make in order to defend against an attack.

depending on how you model your adversary, you can assume that if they have managed to bribe or control a certain percentage of the change, then they can effectively delay each and every one of your moves by a certain amount of time. So this means if you have to make 60 moves and an adversary can delay each one of your transactions on average by an hour, then your lower bound is 60 hours. So this does play a major role in how much time uh should be allotted for a dispute.

>> Carl, >> yeah. Uh I I think that it is going to be very hard for us to align on a detailed security model for L2s because that is very challenging. However, I think we can all align on or at least I feel very aligned on a few things which is one that we want L2s to be very secure and two that we all want to get to stage two and three that we want to provide a good experience for users. And I think that we should really focus on the conversation about okay, we know for a fact that lowering the withdrawal times to from 7 days to one day will

massively increase the amount of chains that are able to get efficient price discovery and efficient uh bridging from their chain to other chains. more chains in the across network and I think that would be a really good thing for the Ethereum ecosystem because we want L2s to be massively successful and so that I think is the starting point and then it is a question I do think it is a question and a nuance question of okay do we think that that is still in line with our security goals and the point that Ellie I think really made very well there which is well if we don't make these changes will people use these bridges anyway so is this kind of a moot point in, you know, is the security

question a moot point. At least we're giving users better security than the alternative. So, um, I'm not going to say that we're going to all convince all be aligned on the security nuances on this call, but you know, I I I don't know. I felt like that just like directionality is is useful to keep in mind as we have these discussions. >> Thanks, Carl. Let's go to Harry next. Um, man, this is a conversation that I feel like has been going for like I don't even know how many years now, like five years now. I was just thinking about uh Carl, you probably remember Kelvin had a great blog post in like I don't remember like 2021 2022 which was just like what the hell is this 7-day period thing? Um, which was put in place

like before the merge when prospectively there was this idea that like we could slash in if censorship occurred um even though that was completely impossible before proof of stake. So, the history of it is like kind of wild. I have a lot of mixed thoughts on this. I definitely the argument of essentially kind of like I'm like one argu one argument I'd like to make is like stage stage two is great in theory and everybody is trying to move for stage two, but also I I worry about getting too caught up in like sacrificing stage one where most chains are today in the interest of stage two.

in that like I think that like the argument that basically like today the actual security assumptions people are getting are not from the native bridge because they're using like other bridges is a great one. Um and like that definitely seems like worth thinking about and looking at and like trying to balance like cohesively. Like I I guess what I'm saying is like I think I would argue we should be optimizing for the practical security of stage one roll-ups today. Um versus like and not worrying as much about stage two, which is a goal and will be a goal no matter what. But like also we don't know exactly when like mainstream high adoption rollups are going to actually be at a point where like the trade-offs for stage 2 are acceptable. And like I wouldn't I I hope it's soon. Um, but I

wouldn't want to like bet too much that it's going to be like very soon. Um, the the other let's see a couple other like small thoughts. One like I think the just just to like clarify like the conversation that happened a little bit in the chat from what PO just said like for for optimistic for like multi round interactive groups what you can do is basically say like hey if there's no challenge at all it'll be confirmed in a day. If there is a challenge that challenge window will be extended out for longer. um you still have the LP risk of a withdrawal could take seven days. In the happy case, in the average case, it would be one day. It's kind of a middle ground. I think the question of like how much like average expected time to complete the withdrawal versus worst case time is something that would be

very worth like evaluating um when it comes to this. And then the let's see the last the the last one being just well last two sorry too quick. Um one like at least for our model like there's no time for censorship per transaction. Like if that model is wrong, then that's worth discussing. Like the model we use is basically there's a global censorship budget that can be applied across a a number of transactions, but that if you spend it all up front or something, then the rest of transactions will be able to go through quickly. If there's disagreement about that, that definitely seems worth flushing out. Again, not settled on this call. Um like people have said, there's only so much time.

Um, the last thing is like I would love for us and I feel like there's like, you know, yes, agreeing on this call in like an overall security model is probably infeasible, but also like it's it's a scary messy thing messing with the challenge period. There's a reason why it hasn't made any momentum before now. And I'm really excited that there's a serious conversation happening about it now because it's really needed. Um, but also like I don't want to move too fast. I mean, I think we need to like be very careful of the optics here externally in terms of like if the optics are just like, hey, we're just like yolo changing it because we felt like it. Um, then we are going to get attacked to hell by everybody outside the Ethereum ecosystem. Um, and so like making sure we have like a

fundamentals-based like strong analysis of it feels like pretty damn important. Um, all right. Sorry for taking up so much time, but a lot of thoughts. >> Yeah. I also just wanted to mention that the idea that we would be able or I don't know who we are but that a fork would be able would be something we can do uh in 7 days isn't isn't really a security guarantee like if the whole reasoning is um we're going to keep the seven days because the Ethereum has managed to do a fork uh previously in six days or in 5 days or something a fork is going to be catastrophic for everyone in every possible way. Values going down. No

one's going to trust the system. 7 days as a reason for seven days doesn't make a lot of sense. I had another point, but I forgot. >> Um, just on that and super quickly, I was talking with Bodas last week about like I would love for us to start actually like having real sort of drills on for Ethereum of like, hey, if if this if the sort of censorship attacks we're worried about were to occur, like could we coordinate, could we align, what would happen? That would be amazing to try to like actually simulate.

I also wanted to add that Fossil is an amazing step towards um having better guarantees on all these fraud proof transactions. I just wanted to second that voice. >> Yeah, Pis, go for it. >> No, I'll ask you later in a >> Okay. Anyone else want to jump in with anything or we have about nine minutes? Maybe I >> can just add to this.

I think instinctively to all of us it makes a lot of sense that shortening the time uh like the settlement time would increase capital efficiency for solvers and but I I haven't seen any good data for that. So one of the things I'm worried about is without like sufficiently justifying this move which actual research that we just kind of yolo the the the time window to be shorter and then if there starts a race between fraud proof uh uh rollups to lower it lower it more than everyone else kind of has to follow in step for sort of business needs.

>> Nice. Okay. this I I mean other people should honestly talk to this as well um across included um but I'll just say that we have talked with both market makers as well as centralized exchanges and everyone at the end of the day if you are uh supporting ETH on an L2 you need to account for the fact that you need to withdraw at within some time frame and whether or not you are a market maker that is like actually rebalancing yourself or you are a market maker that uses a centralized exchange for that rebalancing. What you are doing is you are not removing that problem.

You are deferring that problem to the centralized exchange because now the centralized exchange will offer rates amounts of you know withdrawals per second or per day that they support for uh market maker. And so this is this problem is fundamental and what it ends up doing is it means that small chains do not get two things. they do not get efficient price discovery for ETH and they too do not get across integrations. Um and so this is definitely we can talk about it we can compile a whole big doc but it is factually accurate that it is a impact.

>> No I I fully agree this is a disproportionate benefit for small chains right if you have a large chain you have enough usage to actually incentivize market makers. This is definitely a benefit for small chains way more than ARB one or OPM network. >> I think for me it's the small chains that almost worries me more here because they're having an extra security council. It's almost acting like authority. Sorry, I'm on mobile so I couldn't figure out the hand raised button.

>> No worries. Thanks. Noah Pus, did you want to jump in? I want to mention that uh regardless of what happens with this shortened period, I think we should uh get to a stage in which we can make some sort of assumptions about for example percentage of honest validators. And today we if we flip this and we go we we neglect the 51% attack then we're making that assumption there's at least 51% of honest validators. And I would love to be in a situation in which the kind of assumptions we can make is there is at least 5% of honest validators which is something that would be I would consider reasonable for all of operators and unfortunately today we cannot make that

assumption because of the way of the PBS market on how it's set up. Uh we can we cannot even make the assumption that validators are running vanilla software because someone else is building their blocks for them. uh I believe that after glamsterdam we have a chance of actually setting this up in such a way that we can make an honest assumption on 5% of and will not allow sensor transactions get in and this is regardless of fossil so I think I would try to make this discussion after we are in such a stage instead of like miss of dismissing the 51% back.

>> Yes. Sahi. >> Yeah. Uh there is just one small point I wanted to uh comment about. We're talking about uh if we don't give uh like users going to bridges. So they are anyway not getting security. And I just wanted to put it out that there is a huge difference between user while bridging an asset not getting security and user while staying on chain not getting security and playing with u uh when the chain finalizes is playing with the second which is way way worse than uh uh trusting a bridge for like 15 minutes with some funds.

So we have four minutes left. Um maybe we can bring it back to the start. I don't know Donna if you have anything that you that you find useful to sort of bookend this conversation with or anyone else have thoughts on potential next steps here. here. I think there's been a lot of really great discussion so far. Happy to help contribute to a summary that we can use for uh perhaps actually coming to some conclusions here. But >> yeah, so the like the only comment that I would leave is you know like it's well it's kind of easy maybe or maybe not so easy but for sure easier to discuss like the benefits. I think it should be clearer what is the defender budgets that we're comfortable with you know

like because um like if it is unrealistic again that uh the defender will be able to uh protect the chain uh because it needs too much budget and needs to burn too much money it means that proof systems that we use are completely useless like you can just remove proof system if if that's the case and just use a security council for everything right so uh like I think Someone uh should run some number and see uh what is the expected budget the defender needs to have based on the ATVs and if you're comfortable with that.

>> Yeah, go for it. Here >> one just like quick quick note to throw in. I mean, and and Po's mentioned a couple times Glamsterdam, like it seems like, you know, if we get alignment from everybody that there's something here that could be done pre-Gamsterdam, even better. But like also Glamsterdam's not that far away. It's relatively late stages. Like if we think that there's like some set of changes that is practical to be included along with that hard fork that would give us like a confident base to go off of, um, that seems like a very specific target that shouldn't be missed. Um, so it's worth certainly having both conversations, but like also like that the let's not like miss Glamsterdam and have that pass and say like, oh wait, if we had just done X, then we would have been able to, you

know, lower the period more confidently, assuming that there's general alignment in terms of that as a as a fork priority. Because no one's saying anything, I'll just say that I'm really hopeful that at the end of this, we can figure out a way to make to give users the best experience possible while keeping them safe. And we can do that with practical solutions which are implementable and reasonable.

And uh that I think is something that we sometimes struggle with in the Ethereum ecosystem. We we get a little bit we start talking around about all these crazy ideas and stuff and then we're like oh wait where did the users go? So let's make sure that we focus on the users and we give them a great experience and I think that's what matters. So don't let the egg anyway. >> Well said. Thank you Carl. I think that's uh the best way to end the call. Thank you everyone for being here. We will share some summaries and continue the discussion.

Talk to you guys soon. >> Thanks. Bye. Bye bye. Bye bye. Thanks.