Becoming Immutable: how Ethereum is made

Transcript

Start right now. Hello hello. Hello everyone. My name is Andrea Canidio. I'm going to present research that we did jointly with Vabuk, who is here. About how the block building process affects Ethereum UX essentially. Now, I think we all more or less know about the strange way in which Ethereum transaction originate from a user or a wallet and end up eventually included on chain.

There is typically a user sending its transaction either through the public mempool, but now more and more through something called private RPC endpoint, order flow originators, private mempools. These are systems that relay transaction privately to builders without going through the public mempool. So, those transactions reach builders, they package into blocks. They then send those blocks to relays. Relays then run a sort of auction giving There are multiple relays, so it's like an auction with multiple auctioneers.

And then the proposer will ask the relays to give them the highest paying block. They will then give the the proposal the the block to the proposer. And finally, the proposer is going to append this block to the chain. Okay? Now, note that the protocol proper, so what we mean by Ethereum really starts with the proposer with the block. But of course, everything in between matters from the user point of view because it determines many things about like his own experience of using the chain. Also, there is a parallel path by that used by bots, searchers, which is very similar except that these guys being professionals, they typically they may have like the phone number of the bid number of the builder. So, they

might bypass some of these steps because they have direct communication channels. Anyway, this is very complex and I don't have time to go through it in details, but I do want to bring up two salient facts that not many people know. And they're going to important for the data I'm going to show you in a second. The first one is that this is this process generates tons of blocks for every one block that we we see on chain. So, there are thousands up to 5,000 blocks produced for each one block that is then selected and added on chain.

The reason being that this is very latest intensive process. So, every time a price move on a centralized exchange, some arbitrageurs are going to want to submit new transaction canceling old transaction leading to builders producing new blocks and into relays. That's why we have this explosion of blocks. Now, however, the vast majority of these activities therefore non-observable because the blocks that do not win, they're just discarded by the relays and builders. So, we have no clue, you know, what's in those blocks. And the second observation is that pri- this private mempool, private RPC endpoints are this type of intermediary that have became increasingly important in the

last couple of years. I think now they intermediate more than 50% of Ethereum transactions by counts and I think more than 90% by value. And at least when we did our study, there were five private RPC endpoints. MEV Blocker, MEV Share, Blink, and Merkle. That have some documentation with very degree of various degree of of of kind of completeness, but at least they explain on their website that they submit transaction to multiple builders.

And then there is MetaMask transaction, which actually is the default on MetaMask unless you click many times through the kind of settings. You are and you if you're using MetaMask, you are using MetaMask transaction. And unfortunately, there is no documentation on that. So, we have freely no idea how they share their transaction to builders. Okay. Now, in a this whole system has been at the center of a lot of debate because you know, it could have important implication for the UX of Ethereum. For example, it could be that because the the way transaction are routed, some transaction ended up in some blocks but not other. And then if the winning

block is a block in which these transaction are not present, well, the user essentially will have a for from the user point of view, this will be a delayed inclusion because the transaction was present somewhere among the blocks proposed, but not in the winning block. So, the guy's transaction will be included on chain maybe with one block or two blocks delay. Okay? Now, another way in which this process could affect the user experience is because even when the same transaction, same as swap, is included in multiple blocks proposed during this auction, it might be included differently in each block.

It might be included with different like with other transactions. And this will affect the execution price of those swaps or even if it's executed or not. So, the reverse probability. Okay? So, and then if you think of this process as some sort of random process that picks one block among the many proposed, this if you want is a form of risk. It's a form of execution risk. Now, as I said, we kind of knew from before that those things were possible and we may have some anecdote about you know, you know, I look this as transaction was delayed. So, or this transaction failed while there was another block in which it would have been executed. But what we do what what what was was not present at least until

we did our study was a number that that would quantify how much So, what to what extent those are problems? So, what fraction of transaction are delayed meaning present in some blocks but not in the winning blocks or can we measure the dispersion imply of prices for each given swap generated by the entire process? Okay? And that's actually the research question that motivated us to start our our our study. Yep. So, now if we look at some of the results. So, sorry.

First, let me describe the data set. So, basically we have 15,000 non- around 15,000 non-winning blocks accounting for around 10,000 unique transactions. And if we take them as pairs, we get around something like 2.3 million transaction block observations. And this accounts for 8 minutes only of Ethereum history. So, we got this data from a day on December 3rd and this accounts for a time period of around 39 winning winning blocks.

And this consists of 28% of all blocks that were proposed during the study period and we got this data from Agnostic Relay, which provided to us. So, we only have access to the blocks that went through that relay. And around this time period, they had around Yeah, this was around 28.3% of all the blocks across all the relays. And so, today in the presentation, what we'll look at essentially is we'll try to quantify basically the delayed inclusion on chain of users' transactions. So, how this PBS

essentially impacts the inclusion of users in the canonical chain. And the heterogeneity of the execution of the swaps meaning whether swaps actually happen. So, whether they fail or execute depending on who puts which block it's included in or what prices they get depending on which block is including it. So, now if we look at the results, so it's quite striking that 22% of user transactions are delayed meaning that they're not included in the block in which they first appear in our data set.

So, they were included by some builder. This was It was possible that they would have been included in that block, but they had to wait longer. Normally, normally two or three blocks longer in order to actually get in. And 54% of these delayed transactions are in fact sent publicly through the public mempool or appear in the public mempool at a certain point. And this actually accounts for 17% of all public transactions. And 35% of these delayed transactions actually initially appeared to a single losing builder meaning that the first block that in which they are

included was the Sorry, the first auction in which they were included, they were only included in blocks by one builder who eventually lost the auction meaning that they actually were delayed. And we see the repercussion of this is quite stark because if you we actually find 12 transactions that were delayed and were exclusive to a builder for two or three slots before they appeared actually in the public mempool.

And for one of them at least, they were in fact sandwiched meaning that they got terrible execution and were attacked because the private RPC just let the transaction go out in the public mempool. Um Yeah, and and Yeah, oh yeah, and uh basically uh in some cases uh even after they're seen on the public mempool at the end of the day, they're included by the same builder to whom they were exclusive from the start, right? So, um even though they were out in the public

mempool, the same builder in fact ended up putting it into the into the chain. Um Now, if you look at uh um why this like why they're getting such terrible UX, uh a good explanation a good possible explanation is that the private RPCs share their transactions exclusively with some builders for some reasons, possibly monetary, and they fall back to the public mempool only after the builder loses several uh of these auctions in a row, right?

Um Now, if you look at the execution quality of these user transactions across these candidate blocks, right? Uh we find that uh most transaction most of these user swaps always execute, right? But, we do see some distinctions um uh some distinctions on uh pretty significant amount of transactions, namely that 1.7% of the uh swaps fail in at least half the blocks they appear in.

So, for half of them, they're the swap executes, for the other half, it doesn't execute. Maybe it's slippage, maybe it's something else. Um The second part is uh that 1.1% actually fail in 80% of such blocks. So, most of their executions are in fact uh failures. Um yeah. Now, if you look at just like the quality of the prices that they get, uh so, for 50% of them, the execution prices are fairly concentrated in 2/3 of the cases, the uh the the prices deviate by 4.3 basis points from the swap's average.

Um but, we do see a long tail here of 7% of transactions where the execution prices are very dispersed. Um For a third of the case, they differ by more than uh 100 basis points a person from the swap's average. Um and we did some regression analysis just to see uh what we get, and uh what we found is that uh you know, they suggest that the presence of sex decks arbitrage bots um who swap in the same pool as the user typically leads to worse outcomes for the uh for the uh user. Um Yeah. And so, from this entire process,

what we can say is that yes, like once a block is included on the blockchain, it is deterministic, it's immutable, but the process in which it actually happens is uh you know, far from deterministic. Yeah, so how does this connects with many of the other discussion and presentation you probably heard throughout the conference? Well, there's a lot of debate about making Ethereum fast, but which has concentrated primarily on like a shorter uh block time.

Well, that's obviously uh kind of nice and useful, but in a sense, uh what this research shows is that you can make the block time as fast as you want. If then a private RPC or one of the actor in the supply chain somewhat act strategically in a way that ends up delaying the transaction, then maybe all the work you've done at the engineering level turns out not to be useful. Uh so, I mean, it you also have to think about how the routing of transaction when you talk about speed. Uh there is a lot of discussion about uh censorship, and obviously our work is I think is the first one providing a number on how many transactions are censored, particularly now fossil is going to be included in the next hard fork.

Um and we do find a lot of transaction from the public mempool that are in delayed. So, it will definitely help with those. At the same time, not uh there are also transaction that don't go through the public mempool that are delayed. So, this is a I would say fossil is a partial fix because only helps with some transaction that are delayed, not all of them. And then, of course, the whole discussion about EPBS, that's a bit of a moving target through the years. However, in general, it has focused primarily on relay and builders as the most problematic part of the supply chain, whereas I think our research shows that it's you know, at least right now, or I mean, during the study period, it was probably the private RPC operator that are more the more problematic part of the supply chain. So, maybe the

discussion should have focused more on those guys. Yeah, just to conclude, um you know, there is a tendency in the Ethereum community to think of the properties of the protocol um kind of starting from the moment there is a block, because that's when the protocol proper starts. Um and so, yes, it's going to be permissionable permissionless deterministic and immutable uh once a transaction lands off chain. Uh and of course, there are issues with finality and all that, but let's say by and large, those properties hold once a transaction is on chain.

But, from the user point of view, there are all these intermediaries that determine what their experience is. Uh and so, it might you know, from from their point of view, it might not really feel like the blockchain is immutable or or deterministic. Um yeah, and in effect, they may end up they may end up undoing completely the the the like Ethereum the protocol core promises. Um yeah, and I think uh this research fits nicely with some of the discussion already existing where um in practice, the idea is to um extend a bit the boundaries of the protocol um to include the submission process, for example, through fossil, uh

to provide stronger guarantees to the user, okay? Um yeah, and I think our empirical analysis supports this direction that has already been taken. Cool. I think we are done. Uh no time for question? Okay.