FOCIL Solves Censorship. What Doesn't It Solve About Builders?

Transcript

Awesome. [music] >> Hey guys. Oops. Let me go back one. Hey guys, I'm Marissa. I'm head of product at Eureka Labs. Uh we build blocks and we just recently launched Beex, which stands for builder execution extensions. Uh which let a transaction compute its parameters while the block is being built. Uh, so I spend a lot of my time thinking about what happens to a transaction once it's in a block. Today I want to talk about Fossil, which for those of you that don't know stands for fork choice enforced inclusion lists, um, and what it doesn't solve about

builders. So I'm going to start with a number. So we're a builder, so we have a lot of uh, data on transactions on chain. So we looked at about 16,000 transactions across 64 Ethereum blocks. uh almost half of them never showed up in the public memp pool before their block. Those transactions went straight to builders from private order flow sources and Fossil's committee never would have seen them because it only looks at the public mem. So Fossil can't force these private transactions into the block. Um, it's not a knock on Fossil because Fossil fixes a really important problem and it definitely should ship, but some apps now only work if the builder adds something in the block. Um, like a price update that needs to happen right before a swap with

a prop amm for example. So, we need to ask like what happens after your transaction gets in the block. Um, and to do that, let's start with how blocks get built today. So today, most Ethereum blocks are built by a handful of like specialized validators, uh, specialized builders. Last week, about 90% of Ethereum blocks were built through Mev Boost. And these builders have a lot of control over what goes into the block. Um, and if the builder doesn't want to include your transaction, there's very little you can do except hope that it like the next builder will include it. And that's the exact problem that Fossil is designed to fix. So Fossil works like this. Ethereum selects a committee committee of 16 validators a for each slot and each one

publishes an inclusion list um that for of transactions that seeing in the public mele. So if the builder leaves out a valid transaction that was in the public mele that was in this list when there is room in the block then the validators voting for the block uh like won't vote for it. So in other words, builders still get to build the blocks, but uh they no longer have like unilateral control over whether like a specific listed transaction gets into the block. Um so this is a real step forward, but I just want to be precise over like what it actually solves.

Fossil's guarantee is basically this. Um no builder can keep a valid listed transaction out when there is room in the block. Um which is a new like bar for censorship resistance. um but getting into the block is not the whole story. So there's two things that I want to look at. First are the transactions that Fossil um doesn't cover. And the second is apps where getting into the block um isn't enough because whether the transaction works depends on something earlier in the block such as like in the in the case of propm. So let's start with the first. So the first is private flow which as I said earlier is 47% of Ethereum transactions. Some of those users choose private channels with

MEV because they don't want to be backrun or sandwiched which makes sense but other users do not choose this and they are simply their order flow is sold by wallets um uh and sold to like offas. So either way Fossil's lists are coming from this public meool. So for private order flow those transactions are never seen and a builder can like fill the rest of the block with private flow. Um and as long as the list of transactions are in Fossil is satisfied and all good. Um so Fossil is basically like a floor on what gets in. It is not a ceiling um on how much of the block can be private.

So that's more about the transaction that Fossil never sees in the block at all. Um and then the second one is about transactions that do get in. So the second thing I want to talk about is apps that need the builder. uh some prop ammms like which are pools that where the market maker uh a market maker sets the price basically only accept a swap if the maker's latest price update is included earlier in the block. So basically how it works is they stream these constant price updates and it needs to get included. Um and you can see it in these three blocks on chain where these first two were reverted um and then only with when in this one where the maker update was before the swap was it successful. Um, and the only thing that changed was whether the

builder put the makers update in the block. Um, and Fossil has no say over that. Fossil can force the swap into the block, but it can't make it succeed. So, inclusion is only the first step. Every transaction has two questions. And did it did it get in? And would you have gotten a good result no matter which builder built the block. Um, and for public transactions on the list, Fossil answers this first question. But for apps like prop ammms, the second question is still open. Um, and it matters because of who builds the blocks. So last week, uh, Titan, the largest builder on Ethereum, built 53% of Medblau's blocks. Um, and makers integrate with the biggest builder first

because like that's how standards kind of roll out. Um, so Titan's propm interface was the one that quite like other builders then adopted after. Um, so basically the like biggest builder is setting the stage for all of the builders after it, which means that things are concentrating I would say without the builder censoring it. Um, and the like the more builders that can give the user the result they need, the less it matters which builder is actually the builder that wins because the user's transactions are getting in exactly how they need. Um, that's why a diverse builder market is good not just for like users um, but also builders.

Um, so where does that leave us? Fossil makes it harder to censor transactions. But as more apps rely on the builder to add something into the block, we also need to make sure that using those apps doesn't depend on which builder wins the block. None of this has to wait for a hard fork. And these are just three things that we can do today in order to um make this more possible. So one is that the apps can keep a path that works in every block. So the builder basically makes the result um better instead of design deciding whether it works. Two is that capabilities can use shared standards. For example, this ERC 8324 which was a prop amm standard. Um and

three we can measure it by builders. So we can measure things like how often transactions revert and choose blocks. So this is something that I spend a lot of time thinking about at Eureka. not just about how to build the most valuable block, but how to give apps more flexibility in what they can do inside the block. And that's part of the thinking behind VEX. Um, and it's why we're interested in supporting apps like propm. So, I'll end with um two asks. Sorry, I clicked. Um, I'll end with two apps. asks if you're building an app or a maker that needs a builder. Uh we would love to chat with you um about it and like getting you guys on chain. And then if you are also researching this, we have a lot of

builder side data and would love to provide that to anyone that's interested um in learning more about uh what types of transactions make it on chain versus what stay private. Thank you so much. Yeah please. >> What do I need to do in order to get included inclusion list? >> You need to send your transaction to public memool. >> So your transaction has to be sent via public mem pool >> and it's going to get into the inclusion list from there automatically.

>> Not like it it the validators are the ones that go over the public mem pools. There's some differences in how transactions get propagated from different nodes. Like not every node has every transaction from the public mem pool. But that's the point of like if you have a wide set of nodes that are then all like looking at the at the the public at the nodes then you will eventually have like most of the transaction. So it's like n it's like 95% plus. Yeah. >> Anyone have other questions? Uh yeah here.

>> Okay. Uh I wanted to ask if uh this can cause any security issues uh of uh random transactions getting included. So >> random transactions >> like uh like if anyone wants to hack it so can it go through uh in terms of security? >> Um that's a great question. There was recently a security issue found in a different EIP. Um, so I think a lot of uh new EIPs are under a new scrutiny um and being considered. I think that's a great question for all core devs um and for the testing team at the EF to discover if there are any issues. Um but yeah, let's see. As of now, >> they've not specifically found them.

>> Yeah, one last question. [clears throat] >> So, uh what's the incentive for the validators to participate in this? Is there any monetary benefits to the validators? >> Yeah, validators like get paid like they stake in the network and they they >> for this domain like for >> [music]