Competition through Spam on L2s

Transcript

GM GM. Um, thank you for being here. So, I'm Kristoff from Flashbots. That is another civil from Flashbots. >> Okay. I I know him under the name Bruno, but that might be wrong. Um, today we want to talk about spam, spam, spam, spam, spam, spam, spam, spam. Um best thing to start is with an example that is January um 31st arbitrum block explorer. January 31st was a day where there was quite some activity in in the in the markets and you had a lot of liquidations at that date because prices

were moving moving a lot and that is um an arbitrum block part of an arbitrum block during peak uh liquidation times. And what you observe in these kind of blocks, this block contains 700 roughly transactions. And they do all literally all of them do the same in slightly different ways. They are bots. Um but what they do is they check for oracle updates. So they check they ping the contract of of chain link and want to see whether there was an oracle update because it they will expect soon there will be an oracle update and once this oracle update is triggered we could liquidate a bunch of um lending protocol positions.

They do it all in slightly different ways. So some of them check uh or um oracle contract see nothing happens revert. Some of them check or O or O or O or O or O or O or O or O or O or O or O or Oracle um state uh see nothing happens, do nothing but don't revert. Uh all kinds of different bots, but they all do literally no state transition. So the state isn't moved by these 700 um so transactions. Okay, if you like a visual, that's risky. Well, let's if you like a visualization.

So that's sort of your if you want to think about your standard arbitrum block, right? So you have a bunch of uh transactions that somehow make sense and a bunch of transactions that look bit like spammy and that is sort of this high liquidation peak liquidation block in arbitrum. It fills much more rapidly and basically none of those transaction change state in any meaningful way. Okay. um as I said January um 31st that was this peak liquidation event and that is not only arbitum it happens on a bunch of L2s as well right a bunch of other L2s and you see observe similar patterns so you observe basically blocks full of bot transactions that only check for

Oracle update and do nothing and you observe basically that uh a lot of the traffic on these days up to onethird of the traffic on these days is created by those bots, right? You observe it in the gas statistics. Gas increases as reaction to that because to a lot of is consumed by these uh bots that do don't do do much uh looking for for um uh for oracle updates and as I said there are different variants of those bots. So on arbitum they tend to it has to do with the architecture or or the EVM. Uh but on arbitrums they tend to to revert rather than uh not doing anything on base they tend to do nothing right but

it's sort of that's that's not a very important you know consideration. The fact is they don't change state but they just put transactions on chain. Question is spam. Um I mean spam literally if you think about I don't know classical example like email spam right there is basically you receive unilicited messages you didn't want to receive that advertisement you don't want to receive that fishing attempt you you didn't ask for it the L2 sort of ask for transactions right they post a price um everybody can include whatever they want on on that chain and you might as well include your um your uh attempt to read Oracle state on chain. I mean chain L2s

are open for business. So I mean nothing nothing uh bad is is happening. So in this sense it's not spam, right? It's is explicitly elicited uh elicited traffic. Okay. I don't know. I mean in in the end is it spam or isn't that spam? What is spam anyways? I I don't have you know answer to this philosophical questions but one question that we could ask instead. Okay. Is this a there's something weird about it, right? That doesn't look optimal. That doesn't look like a good chain design. That doesn't look like something we we should strive for. And I I motivated it with liquidations. That's not the only way uh bots try to uh do this optimistic um me

extraction, right? They also try that with back running um traits on a pool. So they optimistically spam the chain check whether somebody has touched a DEX pool and uh if they are lucky they want to background that transaction right same pattern okay it's less spiky in in the sense that it's happens more like uniformly on um over time but same pattern and it's so what what what could be wrong about it um I mean if you think about efficiency it sort of looks a bit wasteful right?

It looks a bit wasteful. It's very salient in the liquidation um uh liquidation story. So there's literally I don't know handful or even only one bot that can liquidate all of those I don't know other positions. Still there are gazillion uh transactions that try to perform this liquidation but only one of them wins and the other ones I mean seem to be wasteful right we only have would have needed one transaction that backgrounds in Oracle not like thousands thousands of them okay there's some waste you could argue from the point of view of the searchers still it's a very lucrative business for them so maybe it's yeah not that wasteful after all from an infrastructure perspective the

chain sort of suffers because some resources are used that arguably shouldn't be used uh to I don't know do do these kind of things um most salient one I would say is history growth right if that happens a lot and if you want to run an archival node uh I mean it's just blows up how much transactions you need to keep track of and all of the transactions are part of the history they don't do anything still you need to keep track of them so that's bad uh from a sequencer perspective if you are at this peak um peak uh load uh times where everybody wants to is waiting for the Oracle update. They can uh have to carry a lot of transaction load, right? So

that might lead to things like uh delayed uh blog posting in some L2s and that might lead to just higher infrastructure cost in general of running the sequencer. So that's that's if you want to use the chain while somebody is heavily spamming it, right? It's very bad UX. Um, you know, gas price is moving very rapidly. It's a moving target, right? So, I don't know, you don't know how to set your um gas settings to to get included. It's full of spams. Full of spam meets other other people might be crowded out. And you could argue, okay, it's probably a very very bad mechanism to capture that value that is obviously created by liquidations, right? Liquidations have

have an economic purpose. So it's reasonable that we do oracle we check for oracle updates and we liquidate positions that's that's a healthy thing to do but the value that is created by doing that I mean that could be internalized probably in much more uh clever ways okay how is it related to design of the chains so arbitum case is very you know very straightforward a first come first surf chain as they have this time boost product but that does not really use for for these kind of liquidation or probabilistic backgrounding strategies.

Um the problem is in a first come first serve um chain you cannot express a preferences of the kind I want to be placed behind a certain target transaction that might arrive in the future. There's some opportunity I'm sure will arrive in the future once it is there please uh put my transaction behind it. I cannot express such preferences in such sequencing design. if you have PGA um kind of architecture like in B actually it's quite similar at least in the in in the liquidation story because um people have a or searchers have a very good way of figuring out okay what are the gas settings that they have to match in order to be placed right behind a certain um um I don't

know Oracle update or backing trait so they match on gas right but many of them know how to match the gas so it's not a competition on gas right so because through PGA you cannot express to be behind something particular right you can only express uh to be placed on top of the block so to speak um so you many people match the gas and then it's basically a tiebreing race and usually if you spam a lot you have higher chances of winning with a tiebreaker okay that's the mechanics quick side note I mean I talked about L2 actually spam is happening on L1 right uh we work at flashports we observe it at our builder but it never hits the chain, right? So builders do a lot of

the filtering and the other thing is we have more expressive ways of you know um for people to express their preferences of I know backrunning a transaction and so on. So we have auction mechanisms that allow to do back running um arbitrage and express your preferences for that but in principle it's it's a thing also in L2 L1 okay final slide and then we go a bit into the theory that is I talked a lot about liquidations and but what is also as I said a very popular strategy is more this probabilistic background on on pools so you expect okay somebody will move the pool, right? Somebody will move a Dex pool and once uh once that has been

done, there's an opportunity to arbitrage. And if you just track that and that is something that our colleague Bert Miller did uh last year this analysis if you just look at this kind of uh sort of bot bot activity it um constitutes around up to a third of all of the traffic on on on those L2s at peak times has become a bit better uh first of all because you know bare market there's less value to be extracted also in reaction to spam L2s have raised uh repeatedly um fee parameters, right?

And if you make it more a bit more expensive to use uh the chain, you will elicit less less traffic. Okay? But I think you see a see in the data that there is a significant amount of spam activity um on these L2s and we have to reason about it. And now Bruno wants to tell you how we could reason about it strategically in a game threating model. >> Yeah, thank you. So we are researchers right? So ideally we would like to make predictions. We would like to analyze counterfactuals and to do so we need well a model. So here we have a very idolized model of how searchers do this type of mic extraction. And the ideas of the model is quite simple. Um you have

this representation of a time is zero is when the block starts and a time one is when it end when it it ends. and you have um an opportunity that is um this value C that arises stoastically between zero and one and you don't know exactly when um but has some positive EB opportunity let's say $1 and the searchers can place transactions at any moment of time um but they don't there is no information disclosure until the block ends because it's a private me and the searcher that just lands afterwards extracts the MAB opportunity Okay, that's the idea of the model. Um, and I don't know if I said it already, but

each one of the transactions has the base fee cost or um the priority fee that tries to match um the opportunity. So the question is, well, what will searchers do in this in this model? Because if they wait too much, for example, they they will wait until the the information disclosure, it's maybe too late. Let's say you wait until uh time one to see where the opportunity and then um instantly react and send a transaction. It's maybe too late because if your adversary sends it at time 0.99 with uh high priority it will extract it and you would just pay it for a cost and almost with zero proity will you will extract it. Right? So that's not ideal.

Um and so what we did is well we formally defined this model and try to compute like uh the equilibrium of the game and someone something we find is well there is a just one symmetric equilibrium and and it has a very beautiful form. First of all it's not pure. What does that mean? It means that essentially um people doesn't take like deterministic uh actions but they actually randomize. they they take um random seat and they decide okay where I will send the first transaction but interestingly enough they just randomize the first transaction when they send the first transaction and at the be beginning of the block uh depends on the parameters of how valuable is the opportunity and

the cost but this is general enough they randomize the first opportunity and the next one is deterministic as a function of the first one how this deterministic function works well it's a solution of a differential of equations No need to go into details details on that but this is more or less the geometrical structure. Maybe the most um this is very interesting as a game theory but but maybe the most interesting thing as a as um mechanism designers or as um for L2 is that this spam so the amount of transactions we'll see for extracting these opportunities is um around the expected value of the M opportunity divided by the basic cost.

So, um, just make the numbers for a 10 value, uh, $10 opportunity divided by a cost of 0.01 cent. That's a bunch of transactions. So, knowing that MAB spam scales scales expected me divide by base fee. What we can do as mechanis designers? Well, we have this subset of options at least that is first just better fees. So a better um um um mechanism for updating gas costs. Um and ideas would be to adjust um prices by resources. So isolating hot contracts from not very popular contracts and

update update dynamically in a multi-d dimensional fashion way that will raise cost in just a subset of them and therefore in will reduce essentially will reduce spam. Another idea would be just yes improve routing like a lot of um maybe it's being leaked because of inefficient routing. Um so that could um a solution could be to have just in time routing or onchain routing or just have back running auctions um offchain. I think this is already more or less starting to happen in liquidations. Uh chain link is starting to expose um um the Oracle updates offchain and back um and doing a

background auction. So probably in the future we'll see a reduce of spam because of this. And a third solution is just making the uncertainty window smaller. the smaller it is uh the smaller the expected uh meab per unit of time is and therefore also the the spam will reduce. So as an I think this in previous graphs we saw it more or less probably due to flash blogs we saw we have seen a reduce of spam because we essentially we have where before we had just um one blog now we have four.

So future work things that we are missing. Um we have numbers on aggregate of how spam more or less works but we we don't have the full distribution. We don't have okay how much people is spamming per opportunity. Um and there's a lot of things to analyze like for example how much actual surplus are searchers capturing how profitable these opportunities um are by searchers and therefore as a searcher maybe you have interest on on knowing this. for theorists. Um, yeah, I think Kristoff has already discussed it. This we don't have a formal definition of spam in this context. So, think about it. And also, we made make a bunch of conjectures the paper. Take a look and hopefully you're able to prove it. Either you or your AI

agent and yeah, for practitioners um just design better apps or try to think, okay, what what will happen in a regime with low um gas cost? Um and think okay what will be the negative externalities of a bad design to the to the L1 um or L2 your um your app is and yeah I think that's all for us um you have here the link of a blog post and and and a paper with all these models take a look >> also I wanted to shout out uh Thomas from flashbot Thomas Andal who provided a lot of the data and who used to be

back in the days a very avid spammer on base. Shout out. All right. Thank you.