Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Is The Future of Ethereum Centralised and Censored?

Episode Date: February 1, 2026

In this episode, host Friederike Ernst is joined by Thomas Thiery, a researcher at the Ethereum Foundation, to discuss EIP-7805 and the implementation of FOCIL (Fork-Choice Enforced Inclusion Lists). Thomas explains how the rise of MEV (Maximal Extractable Value) has created a centralized builder market where a few actors now control over 85% of Ethereum's block production, creating a dangerous bottleneck for censorship. FOCIL addresses this by empowering a decentralized committee of 16 validators to mandate transaction inclusion, making any block that ignores these lists invalid. They explore the "Tornado Cash" moment and the risks of "silent censorship" for competitive or regulatory reasons. Thomas explains why FOCIL intentionally prioritizes the public mempool over MEV-heavy transactions to prevent the system from being co-opted. Finally, the conversation looks at the future of the Ethereum roadmap, including the Osaka fork and the technical trade-offs between inclusion lists and long-term privacy solutions like encrypted mempools. Topics00:00 Intro & FOCIL04:15 MEV & Centralization09:30 The Builder-Searcher Pipeline15:00 Silent Censorship Risks21:45 FOCIL Architecture & Committees27:10 Validity Rules for Attestors35:20 Spam Protection & Invalid TXs42:15 FOCIL vs. Encrypted Mempools49:00 EIP-7805 Status & Fork Timelines55:30 Future: PQC & ZK EVMLinksThomas Thiery on X: https://x.com/soispoke Ethereum Foundation: https://ethereum.foundation/ EIP-7805 (FOCIL): https://eips.ethereum.org/EIPS/eip-7805 Gnosis: https://gnosis.io/Sponsors: Gnosis: Gnosis has been building core decentralized infrastructure for the Ethereum ecosystem since 2015. With the launch of Gnosis Pay last year, we introduced the world's first Decentralized Payment Network. Start leveraging its power today at http://gnosis.io

Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization in the blockchain revolution. I'm Frederica Anz, and today I'm speaking with Toma Tieri, who is a researcher at the Ethereum Foundation. I think being very careful that Ethereum preserves the permissionlessness and censorship resistance properties that it has is very important to me. Every slot, you select 16 validators randomly, and these validators are just, just have to look at the public mempool, basically, and make lists of transactions. The attesters will basically see the inclusion list, they take the union of all transactions in it, and then they check whether the builder block includes these transactions or not. And if it doesn't, based on what they saw,

just don't vote for the block. And the blog never makes it on train, basically. So it's sort of a valid condition for the block. There was also a very meaningful intent in the design of fossil not to involve MIV. The whole fossil design was like, okay, if we want this to be forced censorship resistance, we have to prevent it from being crowded out by MEP transactions.

I'm Frederica Ernst, and today I'm speaking with Toma Tieri, who is a researcher at the Ethereum Foundation, and one of the authors of EIP 7805, which is folk choice-enforced inclusionists, abbreviated to Fossil. Fossil makes censorship stop working by letting validators flag transactions that must be included, so blocks that leave them out simply don't get included into the chain. Toma, it's so good to have you on. Hello, thanks for having me. Nice to bring you. Cool.

Maybe we'll dive right in. So if you had to summarize Fossil in one sentence for people who are familiar with the Ethereum Coal Protocol, how would you characterize it? Yeah, very briefly, I think Fossil helps to drastically improve inclusion guarantees for public transactions by letting multiple validators that are like selected randomly basically to force include lists into Ethereum blocks so each validator is selecting randomly and they are going to make lists of transactions and these transactions basically have to go in the block otherwise the block is not made canonical so it just like won't be voted on by attestals and and so by

using this sort of like mechanism, you ensure that transactions that are like basically pending in the MAMPOO are included, which is very good for improving transaction inclusion guarantees, I guess, and just reduce vectors of censorship. This episode is brought you by NOSUS, building the open internet one block at a time. NOSIS was founded in 2015, and it's grown from one of Ethereum's earliest projects into a powerful ecosystem for open user-owned finance. NOSIS is also the team behind products that had become core to my business and that are so many others like SAFE and CowSwap. At the center is NOSIS chain. It's a low fee layer one with zero downtime in seven years and is secured by over 300,000 validators.

It's the foundation for real-world financial applications like NOSIS pay and circles. All this is governed by NOSISDAO, a community-run organization where anyone with a GNO token can vote on updates, fund new projects, and even run a validator from home. So if you're building in Web 3, or you're just curious about what financial freedom can look like, start exploring at nosis.io. What made you passionate about this topic in particular? And how big a problem do you think censorship is today on Ethereum? So what made me passionate about it is, I feel like that's one of the core, very sort of like central properties of what blockchains are made for. Before MEV basically came into the scene, we like validators were all doing everything.

Like they were building blocks, proposing blocks, attesting like all the sort of like duties a validator is supposed to do. Then there was MEV and basically there was a big centralization force caused by MEV. And so we were basically worried that validators that were decentralized would sort of like centralized because of that force. The solution to this was PBS, so proposer-builder's operations. You have like, you separate sort of like the validating validator role from the builder role.

And that was good for so many reasons, but like one of the reasons that was not anticipated maybe enough is that like builders were actually very centralized. I feel like we lost a bit of this property because now you have very dominant builders building most of the blocks on Ethereum, There are like no checks and balances to make sure these builders don't censor. They can basically censor 3D without like any checks and balances, which is sort of like not exactly what blockchains are for.

Yeah, I think sort of like being very careful that Ethereum preserves the permissionlessness, censorship resistance properties that it has is very important to me. Let's talk about centralizing force through MEV first. So kind of MEV at a high level is just the cost. context a transaction is placed in on the Ethereum block. So kind of not only kind of the ordering of existing transactions, but you could also kind of create new transactions and insert them before, after this transaction and so on.

This is often quite valuable. So this extractable value, it dwarves the transactions themselves. Years ago, kind of it was estimated to be around 1% of the transaction. volume of a block. Building these opportunities for MEV or kind of building an efficient way of extracting the MEV that is there is technically sophisticated. Can you talk about the people who search for MEV do to extract this value? There are many size of this and you actually have different actors. So you have the searchers and those entities are just like very sophisticated because they need to find these opportunities

and those can be arbitrages, sandwiches, arbitrages between the unchain price and the centralization price, for example. And so you need to have like algorithms that are like searching for these opportunities and trying to get to them first and sort of like price them accordingly so they can win the right to actually take advantage

of that opportunity. And the space is quite competitive. You have many searchers that are like all fighting for the same opportunities. So you have to be very fast. You have to adjust your risk and everything. So it is quite sophisticated. There is the builder role, which is, so these searchers will basically construct what we call bundles. So it's like transactions that are like all bundled together in sort of like an atomic unit that you can't like sort of like unpack. And they would send those bundles to builders.

And what the builders basically do is like you take all the mundals plus like transactions coming from other sources like the public mainpool and everything and you construct like a full block. And so that's also where the barrier blurs sometimes because you have builders that are also searchers. And builders have to also be sort of like sophisticated technically because they need to build blocks very fast. They also need to compete in an auction. We can talk about that later. There's a whole dynamic that around like private order flow or like exclusive order flow, which means. sometimes you have deals between builders and searchers, so you have searchers that only send their bundles,

like valuable bundles, to a certain set of builders, and that creates economic barriers to entries. You know, it's also bdy, basically. Like, it's not only, like, algorithms and, like, technical infrastructure that is sophisticated. It's also, like, having access to the right people that send you the valuable data that you can then leverage

to actually win more blocks and everything. So it's a whole sort of, like, ecosystem. Okay, so we talked about the builder and the searcher, and often they are the same people, right? So kind of, and these are the people who kind of build the blocks. What then happens? Because they are not the validators. How are these blocks or these constructed blocks committed on chain? Right. So yeah, if you start from the beginning, you have transactions that are, let's say, submitted by users.

And then they can either be submitted, via the public mempool and then everyone sees them and searchers can oftentimes like take advantage of these transactions when they are in the public mempool because everything is in the wild and they can you know place a transaction before after and construct this sort of like valuable bundles and once the searchers have done that they send the bundles to the builder the difference between the searcher and a builder is like the builder actually construct full blocks so it takes like all these bundles and all the transactions and construct like full blocks and then Then there's an actual auction that is run by the proposer or like the validator.

So a proposer is just a validator in the Ethereum network that has been selected to propose a block to the rest of the network at a particular slot. And so that auction is mediated via a relay. And so every slot basically you have builders that build full blocks and that bid to compete in that auction. And all the proposer has to do is to watch the blocks and their associated beads and choose the block with the maximum bid. And then it will take that block and it will propose it to the rest of the network.

So all the sort of like sophisticated builder, searcher or sort of like ecosystem is done by those entities and the proposer can stay completely unsophisticated because all they have to do is like just watch the beads, watch the blocks that are already built, take them and propose. and to the rest of the network. And maybe like a last thing that is worth mentioning is like the sort of auction is now mediated by a relay. So the option between the proposer and a builder has to go through a relay to make sure, you know,

the builder doesn't send his blog and then the proposer takes it, but like doesn't pay him for it. So it's just like a very sort of like fair exchange problem. So you trust a relay between the proposer and the builder and the relay is supposed to mediate the relationship. That will actually change very, very soon with EPVS, so in the next Ethereum hard fork, that sort of like trusted relay doesn't

need to be used. It can basically be replaced by a commit and revealed scheme that allow the proposer and the builder to communicate trustlessly. Okay, so kind of in the status quo, the relayer is there to basically allow the proposer to just select a price, basically. What it does from kind of it takes the builder's blocks and abstracts away all the details that would allow the proposer to kind of siphon off the MEV itself and kind of steal that from the builder. It just reveals the different price points that the proposer could get and then the proposer can take whichever one he wants but realistically will always take the most expensive one, right? Yes, yeah, exactly.

Talk me through where exactly this MED. extraction happens in this scheme? Well, it can happen at many levels, but generally happens mostly at the searchal level. So the ones that are actually constructing the valuable bundles are usually the ones that are like extracting some MEV. But then, you know, like they usually bid against each other to get their bundles included in a builder's block. So they might give a bit of that value to the builder for them to accept.

their bundles. The builder bids its value away to the proposer because they all again like they compete by having these bids and associated with their blocks but it's quite competitive so they have to outbid each other so most of the value is actually given to the proposer. Yeah that's sort of like the chain of events that you have multiple auctions happening but in the end the sort of like actor that has the most power in a way is the proposer because it's his role to propose the blog to the rest of the network. So yeah, there is quite a lot of value that goes to the proposer. There are, like, you know, some apps that are like capturing the value before it even gets leaked.

So it can be captured at like many levels. We also have, you know, order for auctions that are like redistributed some of the value that are captured from users to the users before like going to searchers or builders. So it can happen in many different ways and that value is sort of like redistributed to the proposer or to the builder or to the users. But it's evolving quite fast and I think we are like trending towards a world in which hopefully quite a lot of value

is actually redirected to the users because their transactions are actually the ones creating the MEP in the first place. So it would be nice to get it back to them. If you kind of look at MEP that extractable, that usually comes from the public mempool. So kind of if you connect to a regular RPC endpoint and kind of send your transactions there, kind of your transactions float around in public for a bit.

Kind of there are actually quite a lot of transactions that never see the light of the public mempool. I think it's between 30 and 40% of transactions and in excess of 50% of block value that never actually see the public mempool. So these transactions go directly to the builders. It comes from kind of like,

I mean, sure, kind of like the MEV searches that we just talked about, because kind of they also insert transactions, obviously. I mean, obviously they don't go to the to the mempool first. But also structural private order flow from applications with intent-based execution

like how swap wallets and RPC providers that protect you from being sandwich, so MEP blocker, flashbots, protect and so on. And then there's also kind of like white glove services that directly relay transactions from larger traders and institutions. These kind of remain private until the moment they're included in the block. With all the downsides that's sending a transaction to the public mempool there are, why are 70 to 60% of transactions still send that way? Because you could just connect to M.AV blocker or flashbots protect RPC endpoint, right?

Yes. I mean, the big downside of connecting to a private auction, for example, compared to the public mempool, it is the trusted part of it. You need to actually send it to someone that guarantees that your transaction is. going to be it's going to stay private and it's not going to be sandwich and everything but you still have to trust that the party whereas the public mempool is actually seen and watched by every node for me so it's like gossiped publicly and every node will actually look at the public mempool and so transactions can be included via the public mempool in a very trustless way so that's the

sort of like big difference i think it's like trusted versus untrusted but then Right now, if you want to do it in a trustless way, yes, if your transaction carries a M-EV, it will be seen by everyone. And that means they can take advantage of some, you know, sleepage you have in it or stuff like this. Maybe let's go to kind of how lucrative it is again. So kind of if you look at the builder role, in principle, it's a lot of power, but kind of it gets squeezed from both ends, right? So kind of it gets squeezed from the proposer and it gets squeezed from the, from the, from the searcher. And do you have any idea of how much money builders make today?

So I don't think it's public information, but I can tell you they do get squeezed. It's a bit weird. Like very dominant builders like can make a bit of money because they do have like very exclusive flow. So sometimes they have they can build blocks that are way more valuable than the competition because they have access to like a particular opportunity that will only get shared with them. So they can just bid a bit higher than their competitors, but they know they have this sort of leeway, and they can actually keep that for then status.

So that happens. But even with the main end builders, like the competition is actually quite fierce. I don't think like the builder is in like a super great position because as you say, like it, if you just build like it is very non-profitable. Like I would say if you have some exclusive order flow, then it becomes more profitable.

And if you do some searching yourself, which basically is exclusive order flow because it comes from you, then it can be actually profitable. But like it really depends, like, who you are. And right now I would say one of the big problems is like it's very hard for new builders to come in because they have to get access to order flow

or like search themselves, but then it becomes actually very, very sophisticated and hard. And it's kind of a chicken and egg problem because if you come in, you don't have access to order flow so you don't have a lot of builder market share. and if you don't have, you know, if you don't propose a block in a significant portion of the blocks that actually get to the network, then people will not send you their flow because they are like, well, it doesn't, it is not worth. So it's very hard to sort of like spin up new builders and the barriers of, barriers of entry are very high.

I mean, you probably also need a trusted relationship because if I'm a searcher and kind of like you're a new builder, kind of like what assurances do I have that you're actually trying to build a block and you're not just passing on the opportunities that I found to another builder, right? Exactly. Yeah, so that comes with like, it's very trusted. It's like that comes with reputation, basically, that you haven't done this in the past and like other people trust you. But like when you come in and you're new, like no one really knows, right?

So yeah. So give us an idea of how concentrated block building is in practice. Yeah, it's pretty concentrated. I would say, okay, so now you have a third one, but like it's, for a while it was mostly two, very dominant builders that you had like two builders that would be built more than 80% of the blocks of the network. Now you have Quasar that came in that is now, I think, around 10 to 15% of the network. So you have three that make up for like 85, 80, 85% of the network. It's worth saying you have like initiatives, for example, builder. that is like trying to go towards decentralizing block building, but it's hard and it's sort of like

it's the project in a way. And so, you know, they are having different nodes controlled by different people, but they share some infrastructure and everything. So it's not, we're not like there yet in terms of like decentralized block building. It's worse actually saying that there are like a lot of efforts to go towards this. But like right now it's we say, yeah, basically. basically three builders that are like building more than 80, 85% of the both. What about relayers? How centralizes that ecosystem? And is it fair to see them as just kind of like a pretty mechanical gate or do they have agency?

That's a good question. I think they were thought of as a very mechanical gate. But then, I mean, the incentives question actually popped up as well because like you're still like at the end of the day like running infrastructure and like providing service. So it's like if you make absolutely zero revenues, then it's a bit hard for people to expect that there will be many relays just like doing this electristically, I guess. So some of them do run like some kind of auctions of their own to sort of like extract some value just to fund themselves. I don't think it's very profitable, but like they have this sort of like auction mechanics as well. And they are quite centralized. I think I don't have the numbers in mind exactly for relays right now, but yeah, most of them go through, I would say, three, two, three relays.

Most of the, they are the most performant. They are the ones like that everyone knows. The thing maybe to note though is like not, they can censor as well because they can like not propagate a given block, for example. But they don't get really the right to pick and choose and exclude. given like some transactions over others. It's more at the block level. They can just like choose not to send the blog, but they can't really like manipulate the transactions themselves because the blocks are supposed to be built by the builders.

So maybe let's move into kind of this entire censorship topic. I think kind of like we understand kind of like how in principle blocks kind of become formed and end up on chain. So in this PBS pipeline, so builders, relays, proposes, who actually has the power to censor transactions? Yeah, all of them. All of them in very different ways in a way. So I think it's important to basically say that

when a block or a transaction goes through multiple steps, which is sort of like always the case, like basically at every step it can be censored, right? Because like the sort of like entity processing it can just be like, well, I'm not going to include this transaction or this block. Right now, yeah, builders. have quite a lot of power because they are the ones choosing transactions. So they can basically build blocks that are like profitable and everything without like

including some very specific transactions. Proposers can always do anything they want. Like, because proposers are, you know, in charge of, they can, first they can build their own blocks if they want to. They are just, they just choose to delegate to sophisticated builders because they get more MEV out of it, but they could and sometimes do build. their own blocks. And they can always, you know, choose not to propose a block at all and miss their stats, in which case the block just like won't make it on chain. And again, the relay can

choose to forward the block or not from the builder to the proposer. It can be like, no, this one, I'm not going to do it. So yeah, you do have like quite a few points of censorship along the way. The best way to think about is like every, everyone that processes your transaction will probably have a say on whether it makes it through or not. If we look at censorship in practice, where do transactions actually get cut out? So kind of I understand that in principle, kind of like it's possible at each of these gate points. But what happens in practice?

So it's worth mentioning like censorship right now on Ethereum is quite low. Like there is not much censorship like going on right now. It was a bit there was a bit more in the past. look like now is pretty much it's quite yet it's not a huge concern but when censorship like when people are censoring they do it at like all the levels I mentioned it is worth saying that right now proposers have always acted as this sort of like fallback to include transactions that were not included by for example dominant builders and so you know you had transactions at some point, for example, like Tornado Cash transactions that were sort of like censored from some

very dominant builders. So like they wouldn't make it on chain or they had to basically wait a way longer time than other transactions until they made it on chain. And you had these proposals that were locally building their blocks with all the transactions that were basically censored. So they could actually eventually make it on chain. So and it's still the case today. Like some proposals altruistically still build their blocks so that all transactions that are like pending in the main pool and waiting to be included are actually included. So and you know, I think something worth mentioning is like, and that actually matters a lot, is like the set of proposals is much more distributed and decentralized than the few builders

and the few relays. So at the end you have like much more preference. that are expressed through the set of proposals than you have through the set of builders in a way, which makes a very big difference for transaction inclusion and censorship resistance. If we kind of think back to the tornado cash moment that you kind of just talked about,

what actually happened was that FlashB Boost started not including transactions that touched upon these addresses. Remind me why kind of the censorship then happened at the builder level? Was it because there were just so much fewer entities there that kind of getting one of them would be kind of the way that law enforcement would go?

I think it's a good question for them. I don't think, at this, I'm not aware of like any actual laws or regulations passing at the time that prompted them to start it. So I think it was like an anticipation of maybe getting into some trouble if they did something. I don't know if I have no idea exactly the reasons why they actually started

this, but what was true is that they, I think a lot of the other like dominant builders followed and sort of like saw this and basically had the same thoughts, I guess. And so what was very important there is like since there was

very, very few builders and relays like you just need like the two dominant builders to start censoring transactions for those transactions to be censored for a very long time until they are included by like another entity. So and that's basically what, you know, fossil will talk about it is all about. But it's like if like two builders are like dominating the block production and are making 90% of the blocks, those two builders can have a huge impact on on some transactions for any reason.

Turned out it was it was totally occasion and all fact. But like it can be a lot of different reasons that we can also maybe get into because it's interesting. And then you have a huge impact on the network. And suddenly the sort of censorship resistance properties of Ethereum are like eroded quite a lot. Just because a few actors decided to, you know, exclude some transactions, basically. Do you have a sense of how many transactions are delayed by multiple blocks because of these policies? And I would be super interested to kind of hear what exactly kind of they are censored for. So you said that tornado is no longer a big driving force, but what else are we censoring for these days?

No, so I think that's basically it. That's like the one use case. I think like some people are like still censoring OFAC or tornado cash transactions, for example. It's just like there is way less as well because like people are not using tornado cash a lot these days. So it's like relatively off of the OFAC list. So kind of... Yeah, yes, but you know, there was a big hit

in sort of like tornado cache usage after the sanctions and everything and it never really recovered. So the amount of transactions that are actually going through because tornadoesch, for example, is still like very low. So there are like very few transactions that actually get censored

just because like few transactions that are like submitted and that would be censored in the first place. Okay, so there's, there's not a lot of things that actually currently get censored, but in principle they could. Okay. Exactly. Yeah.

And just maybe worth mentioning that, again, like, that was one use case, but I feel like it's sometimes forgotten about that you can censor like very easily for very different reasons. For example, just like pure competition. If you have a competitor that does exactly the same thing as you or like the same service, for example, and you know you can just like literally. get a deal with like two builders and you slow down their ux by 10x it's very tempting like it's like a counterparty risk basically and and that's and it's very real and there and like i think people are quite aligned right now like we haven't really seen a lot of it and but it's i think it's a bit naive to expect this won't ever happen so yeah so i think kind of the social norms not enough.

No, I mean, I mean, the whole thesis of blockchain is like we shouldn't rely on social norms to enforce these things. So yeah. Cool. Then tell us how fossil works and how it addresses this concern. Yeah. So basically, again, you have the builders on one side that are very centralized, like, centralized and quite sophisticated.

And then you have the proposers that are like part of the validator set that is much more decentralized. And so the ID is like every slot, you select 16 validators randomly. And these validators are just, just have to look at the public mempool basically and make lists of transactions. So up to a certain limit. So there are like small lists of transactions, basically, from the public mempool. And they do that like, it's hard coded in the client. So they just like include transactions in their list.

And any transactions that they see or kind of what, what, okay. I mean, you have. like some heuristics like you usually maybe want to like take the transactions that pay the most priority fees or that have been pending in the mainpool for the longest just like rough heuristic but like there's no actual preference of like i like these transactions or not basically and so they build these lists each of the 16 lists are like sent around so everyone can can see them and then the proposer and the builder have to build their blocks after having seen these lists and they need to include all the transactions that were contained across all these lists.

So basically they take the union of transactions across all the inclusion lists. And they have to include these transactions in their blocks if they want it to be valid. So that constraints the builders basically on the transactions it needs to include in its block. Otherwise, when attestell's vote for it, they see that they are not compliant to the sort of like transactions that were in inclusion list. and they just don't vote for it. So that means you have multiple basically proposals contributing to what needs to be included in a block, and you have this for every slot.

And in a way, it's like leveraging the sort of like decentralized validator set to impose constraints on the much more centralized builder set. It's just like a way to enforce some constraints to make sure they comply and they actually include the transactions that are like pending in the main pool, just based on protocol rules and not arbitrary preferences or compliance reasons. How are the validators who are on this inclusion list committee chosen? Is it the same way that kind of we choose the attestation committee?

Yeah, it's random. It's random. So kind of in principle, then transactions could still be censored if these six, 16 people or entities kind of colluded and decided to kind of leave off one transaction for sure. Because it's kind of like it's only censored if it's in none of the lists, right? Because kind of you're looking at the union. Exactly. So if all like are colluding, then yes, then it will be censored.

You have two kind of cool things. So first, you know, to consistently censor a given transaction, you have to do it over multiple slots. And every slot you have like a new random committee that's selected of 16. So like the chances like all of them collude all the time like to keep your transaction out are like very low. Unless like, you know, the whole attester set is colludes. And then you don't, I mean, they can have like 51% attacks. They can do a lot of like different things that are much more, much easier to just like sort of like try to to try to keep a transaction out. And then yeah, the one kind of cool thing is exactly related to what you said.

is like if only one of the 16 proposers decides to include in transaction, that transaction needs to be included. So you have a sort of like one out of end, we call it like minority assumption, which is quite strong because it's a pretty good guarantee. Okay, you just need one honest list producer and you're good, right? Exactly. So now I'm a builder and for some reason I kind of, I don't include one of the transactions that was on the inclusion list.

What, what happens? So kind of I sell that block to a proposal. and the proposer proposes the block and then? And then the attestors, so, you know, you have a block proposal and then attestors need to vote for that block in order for it to make it part of the canonical chain. And the attestals will basically, they will have seen the inclusion list. So they will have done the exact same thing.

They see the inclusion list. They take the union of all transactions in it. And then they check whether the builder block includes these transactions or not. And if it doesn't, based on what they saw. so based on their local view of what they saw, just don't vote for the block. And the blog never makes it on chain, basically. So it's sort of a valid condition for the block.

At thesters are like, yeah, I saw the inclusion list myself and I saw there was like transactions in there that actually didn't make it in the block you propose, so I'm not going to vote for it. Okay. So we already said that kind of as an inclusion list producer, I have no particular obligation to kind of choose any particular transaction. But what happens if I'm offline or lazy?

Do I get penalized for not producing an inclusionist? No. So offline, yes, you just like don't propose an inclusion list, but there's not much consequences. There will just be 15 inclusion lists enforced for that slot, and that's totally fine. And you don't get penalized. And then lazy can't really happen.

in all of this is basically hard-coded in the client, right? So it's not like we are asking validators to choose every time what transactions they want. Like you run a valetor like automatically it's basically going to do this and choose transactions from the mainpool

and build these lists and send them to the network. So there is no active sort of like tasks that they need to do. In practice, you just run a node and sometimes you get selected to do to perform this additional. duty. Okay. So kind of these are the inclusionists say they only include visible transactions so kind of transactions that come from the MAMPOOL but we just talked about the

fact that kind of a large percentage of the order flow is actually private. What influence does that that have one on censorship? Yeah so very very clearly for Seoul does not really like cover the MIV transactions use cases and an is missing like a lot of transactions because like a lot of transactions do contain MV but there is a bit of an incompatibility here because if you include your transaction in in an include like via an inclusion list that means it came from the public mainpool and you know imagine even even if you are like an includeer for example and you want to include your private transaction in an inclusion list you can do that but that will also need to become public

after the fact when you send your inclusion list it also has like all the transactions so they become public, public anyways. And MEV and public doesn't really go super well together. Like it's, if you are extracting MV by definition, you basically don't want people to be able to see it and modify it before the block is sort of like

finalized and sort of and set in stone. There are like ways to to sort of like build on top of fossil to accommodate for MEP transactions. And we can maybe get into encrypted memples later because it's one of the very obvious option. But for now,

a fossil is made for public transactions. So not for transactions, you want to keep private for MEV reasons, basically. So the mempool is a pretty ephemeral thing, right? So kind of there's no objective mempool because kind of like it relies on gossip. What prevents me from being an evil inclusion list, a producer,

and just inventing a transaction that no one else has seen, because I made it up. And then no block can be produced because obviously no one can include that transaction. So imagine you include the transaction in your inclusion list. That transaction will be revealed when you send your inclusion list around, right? And so then there are like two scenarios, basically. Either your transaction is valid, but then you have to pay for it.

So it has a cost, basically. You could, you know, fill your inclusion list with transactions that are only yours, If they are valid, you have to basically pay for it. Or you can just like submit an inclusion list with like invalid transactions, but then everyone will see that they are invalid. And so they won't penalize the builder for having proposed, for not having included them, basically. So you see the list of transactions,

but like as an attestor, you actually execute them and you see they are not valid or like they couldn't be validly appended to the blog, basically. And then when you see the builder's block, that doesn't include these transactions, because he also saw that it wasn't valid. You completely accept his block and you don't penalize him for it because transactions were not valid. Okay.

The transaction, it's not just a transaction idea. It's kind of the entire transaction that would be sufficient to kind of include it. Even if you don't see the transaction itself on the MAM pool, you can still include it. Okay, perfect. Exactly. Yeah, the inclusion list contains the full transactions. Okay. Are there any any of these strategies?

that are affected by forced inclusion? I mean, you could think of, like, use cases, for example, for liquidations. If someone, for example, doesn't want a liquidation to happen and wants to censor, like, a particular transaction that will liquidate someone, like, you could, like, submit that to the public mempool. And by doing that, if it's included with force, you have, like, a, you can do, like, force people's hands in a way. So that, that actually works quite well.

but other than this, just like, again, like, I think most AMIV strategies are like are centered around like not leaking any sort of like valuable data, which would be the case through FOSOLs. So, so no, I don't think it affects. There was also a very meaningful intent in the design of FOSOL not to involve MIV because if it involves MED transactions and you don't have like a, encrypted transactions, then all the inclusion list will be filled with MEP transactions, right? Like it's you can like recreate a MFbooth market basically where inclusionists become collusion vehicles to build very valuable stuff that will need to be included in the block. So the whole fossil design was like, okay, if we want this to be for censorship resistance, we have to prevent it from

being crowded out by MIV transactions, basically. And so we want to design it especially so it's ill-suited to include transactions that are extracting M-EV. Otherwise, it's just going to get co-opted just like the block was. And you're going to have like the builders that are going to be building extremely valuable inclusion list, and you are back to square one. So it was very intentional not to make it suitable for M-EV. One other direction that kind of we've talked about in the community for censorship resistance is MAMPOOL encryption. You already talked about it in Partsing earlier. Kind of MAMPU encryption just means that kind of before I send my transaction to a public MAMPUL, I encrypted and it's only decrypted once it's committed.

What does that solve that fossil does not? And vice versa, what does fossil solve that the encrypted mempool doesn't? not. So I think they are very complementary, like they just address very different things. The sort of like constraining builders using the decentralized proposer set to force include transactions is just like done very well by fossil, whether like you have encrypted transactions or not. The fact that you, it's more like I think encrypted mempools give you a protection against MEV basically. Because it's important to reiterate that encrypted memples mean you encrypt your transaction until it's, but then it's later decrypted, right?

And then, so it's not like privacy over like a long duration. It's really like sort of like temporary privacy. And so it's really useful to sort of like make sure a transaction, for example, go through fossil without revealing any sort of like crucial information. And that now means that basically sensitive transactions like MV transactions can be encrypted, go through fossil, be force included in the block. And then later you reveal their contents, which will actually protect you against MIV. And that's sort of like, is one of the very crucial steps to make MIV transactions,

to give like better inclusion guarantees or better the censorship resistance for MV transactions. So why doesn't encryption alone guarantee censorship resistance? Because someone could just say, look, I have no idea what this says, I'm not going to include it? Or one? Yeah. Okay. I mean, yeah. You could have builders that are like, yeah, I'm not including encrypted transactions at all.

And they could completely do so if you don't have something like forso. There is nothing that forces them to include any transactions and including all the encrypted ones. So yeah, I can see that happening. Okay. I recently did a podcast with Peter Van Bakenberg from Coin Center. And he very interestingly argued that networks must be actually blind, not just willfully blind to resist censorship mandates and remain credibly neutral. Do you agree?

Yes, I actually agree. I think if you never see any transactions content and you participate in a network, which means and you have validators and the whole network is like basically functional, then you have the best censorship resistance properties you could imagine. maybe one caveat is like it's even if you don't have like good censorship basis and properties you can't know right like so it's a bit like you you don't really have access onto anything so if you try to it then you know yes exactly but like no one not in the public mempool sense like no one can tell outside of you same like if you mint an infinite amount of tokens and like in theory like no one can actually

know but yeah no if you have total privacy, you have like extremely good censorship resistance properties, which is also important to note, like, because now we are talking about like permanent privacy, like, networks like, I don't know, like Z-cash or like that gives you actual privacy in a sort of like long-term sense of the, yeah, long-term. If you have like temporary privacy with encrypted memples, then you have like more censorship resistance, but less than you will have with like longer term privacy and if you have like full transparency you have less. So it's like a sort of like spectrum, right?

I do I do think there is like a very sort of like strong relationship between privacy and social resistance. I think the bottlenecks, if your next question where it's going to be like, why don't we have like better like privacy solutions, either like encrypted memples or or longer term privacy on Ethereum for example, it's just because it's, technically very difficult to implement and you need to make extremely complicated trade-offs even just for encrypted memples i feel like the you have to make design decisions that are like slowing things down or like that are not not always completely trustless or that ask more from user also like you need to

make trade-offs everywhere and yeah if we really want you to go full on privacy for everything you need to like re-architect some parts of the protocol quite deeply. And it is being like considered. People, for example, at DEF, like are working on this quite a lot. But I would say it's more focused on like what use cases do we want to enable privacy for rather than allowing everything to be private because, yeah, maybe another point is like, For example, Zicash only allows transfers. If you don't want to make everything that's possible in Ethereum private,

it's much more complicated because it's programmable and you can actually do a bunch of stuff other than just like transferring value. So it would be quite hard. Like Aztec is a bit of example of a network that tried this. But yeah. The current version of Aztec does actually make everything private. So kind of like it used to be that kind of there were only certain transactions that were private, but kind of in the, I forget what the current versions

hold, but kind of like it's actually fully private. Obviously kind of like it's no longer, it's not an EVM chain now, but I mean, it also was an EVM chain before. But yeah, so in principle, it's possible. Oh, no, no, for sure. No, so I was saying Aztec in the current version. I was just saying, if you want Ethereum to become like Aztec, then you need a complete rearchitecture of the protocol.

like it's it looks like a very different sort of like a protocol it's kind of it's also fine to kind of have private parts of the chain and non-private parts right as long as you kind of like if you want privacy you can go to the private parts as it obviously kind of this is okay um so tell us about the i mean we talked about foster the erp for a long time now so it kind of you you propose it probably like two years ago or so. What's the current status of the EIP? When are we going to see this live? Yeah.

So I proposed it for Glamsterdam, which is going to be the very next fork. But the scope has already been finalized and Fossol was not included in Glamsterdam. And then the reasons were really around four scope. Like basically we couldn't fit fossil in with what was already sort of like included in the fork, including EPBS, which is a very cool but like very big feature. So it's hard to pack it all in. And now we have a whole new process with headliner.

So we need to pick, you know, big sort of like EAPs. We are willing to delay the fork for each fork. And so you can't have like that many big EAPs included. It's not as big as the PBS at all, but it's still like an EIP that touches both layers and everything, so it needs a bit of space. And so what happened is like we couldn't include it in Glamsterdam and the decision was to automatically sort of like consider it for inclusion in the next fork after that. So, he gota. Now, I think next week, the headliner proposal period closes. then there's going to be a month of governance to decide what is going to be the headliner

and then after this we'll know if if also is selected as the headliner or not so of course I like reproosed it and it was already sort of like cified or like considered for inclusion for herewitha automatically but it's it's very hard to tell before governance actually happens but there are no open technical questions for inclusion right No, it's been a while now and there are no technical limitations, which is a very good sign. There are like tradeoffs and limitations that we already mentioned. For example, it doesn't cover MIVU transactions, but there are no incompatibilities or like we made sure it's actually very compatible with existing, you know, the existing protocol, but also the forks after. So it's, yeah, it's been worked on quite a lot.

If Faso were to be included tomorrow, is there a failure mode that would keep you up at night? That's a good question. Yeah, I don't know. It's also fine as an answer. Yeah, yeah, I don't think so. I don't think there is a failure mode that we just need to implement it very carefully, like every sort of fork because it touches fork choice. It's like another sort of thing.

All attesters have to do each block. So we need to be extremely careful about that part, but nothing like we haven't done before. And then not really because I do see fossil as like the first. It's a big step in terms of primitive, like a set of parties, sort of like constraining others. Like it hasn't really been done before in the protocol. So that's like, but but that's why we kept it very, very minimal as well.

We can try to add so many things on top of fossil. You can have like block futures. you can have encrypted mempools, you can have a lot of different things. You can have what I call ZK Fossil to sort of like break the link between who does, who proposes the inclusion list and the content of the inclusion list. You can actually do super cool things. But the version we want to shoot now is the primitive and it's very simple. And so I think I don't see like a big failure case right now at least.

Okay, then maybe let me kind of make the question somewhere. what milder. What's the strongest argument against Fossil that you've heard from someone we respect? I think that it doesn't do enough. Like it doesn't include MU transactions and doesn't include blob transactions. That's just a good argument because it's true. And so we are working very hard on having blob transactions. So sensory resistance for blobs. I don't think it should be part of Foss's just because it needs other things. Like, for example, you need to determine the availability of a blob because now we have PRDAS and so it's not the case for regular transactions it's you need like extra stuff so you can't really like put it all in fossil but

that is a very good argument because we actually need it very much and we are working on it and if as I said is a bit more tricky like you need encrypted mempours and I'm I'm let's sure we have enough confidence on the design for it to be enshrined on Ethereum right now but it's also like quite an active sort of like research topic. Yeah, I feel like the, no, the actual pushback I've heard the most. Aside from like it doesn't do enough is we don't need it right now because censorship is quite low right now. So that's been an actual pushback from people I respect as well.

There I'm like pretty strongly opinionated that we shouldn't wait for it to be bad to include something. I'm having a hard time sort of like seeing the argument. Like, yes, maybe, you know, maybe we'll be fine for years to come, like, but maybe not. And so I feel like for me, the fact that the risk exists and that it's, you know, if there is like a massive censorship event on Ethereum and we are not prepared for it, I do think like a lot of like the sort of like properties that Ethereum has and people care about are like around security, resilience, robustness up to. time, so sort of like all these things. So I don't want to expose the protocol to something that

will actually erode these values and sort of like properties that everyone deeply cares about. So I hear the argument. Like I agree there is not much censorship, but it's it's hard for me to sort of like think the same, I guess. So if this gets included in Hegota, what's next for you? What will you be concentrating on? Will it be improving on fossil or doing something altogether, no? Yeah. So on the fossil part, I am a researcher.

So I feel like I've pushed already quite far by, you know, like with the help of Ji-Hun, by the way, like coming up with like dev nets and implementations and sort of like preparing everything. So it will actually be very ready for being included in the forefront. But of course I'll still like monitor and sort of like make things make sure like everything is going fine if it's included right Just because from when it's included to when it actually ships on mainnet there is a lot of activity and There's are like trying to ship it and you need to be there to to support them But no generally there is a Quite a big effort at the F right now to support things around security more generally

So there is a quite a lot of work on transition to post-quantum, for example, network resilience, P2P networking resilience, hardening client code, preparing the transition to ZKVM in a safe way because it's early and it's new tech, so we need to sort of like make sure it's okay. Handling, stay good. If you want to scale, we also need to also make sure like that's okay for the network and we can handle it and not have nodes have to start. or like too much data all the time. Then there is like extensions of fossil.

I talked about like blobs is a very obvious one. And then you have like ZK fossil or like making it more accessible. Like everyone can become an included now. You know, you don't need to become a validate to be a validator, for example. You do have quite a lot of things going when it comes to making sure the network is more secure. Both on sort of like the very sort of like technical way, you know, engineering way in a way, like just like making the things more robust. But also in terms of, yeah, what are the failure, like the points of failure?

What are like the sort of like parts of the network that are like very concentrated and like one given actor could actually have like sort of like outside influence on on what happens in the network? And and you don't just have builders. Like you have like different cases. For example, RPCs is a quite obvious one. It's quite concentrated and centralized as well. So I think there is a big effort in the coming year to work on this and fix it and dedicate more resources as a as an orb to fixing this. Cool. Thank you so much for coming on, Toma. Thank you. Thanks for having me.