Is The Future of Ethereum Centralised and Censored? - Thomas Thiery. Ep635

Transcript

Welcome to epicenter [music] the show which talks about the technologies projects and people driving decentralization in the blockchain revolution. I'm Fria [music] Ans and today I'm speaking with Tomati who is a research at the Ethereum Foundation. >> I think being very careful that Ethereum preserves the permissionlessness 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 mele basically and make lists of transactions. The testers will basically see the inclusion list.

They take the union of all transactions in it and then they check whether the the builder block includes these transactions or not and if it doesn't based on what they saw just like don't vote for the block and the block like never makes it on train basically. So it's it's it's sort of a validity condition for for the block. There was also a very meaningful intent uh in the design of fossil not to involve MV. The whole fossil design was like, okay, um, if we want this to be for [music] censorship resistance, we have to prevent it from being crowded out by me transactions.

I'm Fedria Ans and today I'm [music] speaking with Tomat Kiri who is a researcher at the Ethereum Foundation and one of the authors of EIP7805 um, which is fork choice enforced inclusionists abbreviated to Fossil. Um, 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. Hey Tom, it's so good to have you on. >> Hello. Thanks for having me. Nice to be here.

>> Cool. Maybe we'll dive right in. So um if you had to summarize Fossil in one sentence for people who are familiar with um the Ethereum Cool 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 selecting selected randomly basically to force include lists into Ethereum blocks. Uh so each validator is selecting randomly and they're going to make list of

transactions and these transactions basically have to go in the block otherwise the block is not uh made canonical so it just like won't be voted on by testers. Um and and so by using this sort of like mechanism you ensure that transactions that are like basically pending in the meool um are included uh which is very good for for improving transaction inclusion guarantees I guess and just reduce vectors of uh censorship. This episode is brought to you by Nosis 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 userowned finance.

Nosis is also the team behind products that had become core to my business and that of so many others like Safe and Cow Swap. At the center is Nosis Chain. It's a low fee layer 1 with zero downtime in 7 years and 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 Nosis DAO, a communityrun 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 me basically like 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 ME and basically there was a big centralization force uh caused by MEV and so we were basically worried that validators that

were decentralized would sort of like centralized because of that uh force. The solution to this was was PBS. So proposer builder separation. So you have like you separate sort of like the validating validator role from like the builder role and that was good for so many reasons but like one of the reason that was not anticipated maybe enough is that like builders were actually very centralized. I feel like we lost a bit of of this property because now you have very dominant builders building most of the blocks on Ethereum. there there are like no checks and balances to make sure these builders don't censor. They can basically sensor freely without like any checks and balances which is sort of like not exactly what blockchains are

for. Yeah. Uh I think sort of like being very careful that Ethereum preserves the permissionlessness censorship resistance property that it has is is very important to me. >> Let's talk about centralizing force through me first. So kind of me at a high level um is just the 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 um uh kind of uh create new transactions and insert them before after this transaction um and so on.

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

can be arbitrares, sandwiches, arbitragees between the onchain price and the centralization uh price for example. And so you need to have like algorithms that are like searching for for for these opportunities and 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 and 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 um adjust your risk and everything. So it is quite sophisticated. there is the the builder role which is so these searchers will basically construct what we call bundles. So it's like um transactions

that are like all bundled together in sort of like an atomic unit that you can't like sort of like unpack. Um and they will send the those bundles to builders. And what the builders basically do is like you you take all the bundles plus like transactions coming from other sources like the public main pool 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 cuz they need to build blocks very fast. They also need to compete in an auction. We can talk about that later. The 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 like economic barriers to entries. You know, it's also BG basically like it's 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 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 um 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 um they can e either be submitted via like the public meool and then everyone sees them and searchers can often times like take advantage of these transactions when they are in the public meool 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 and a builder is like the builder actually construct full blocks. Uh so it takes like all these bundles and all the transactions

and construct like full blocks and 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 relay. And so every slot basically you have builders that build full blocks and that uh bid to compete in that auction. And all the proposer has to do is to watch the blocks and their associated bids 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 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 bids watch the blocks that are already built take them and propose them to the rest of the network. And maybe like a last thing that is worth me mentioning is like the sort of auction is now mediated by a relay. So the auction between the proposer and a builder has to go through a relay to make sure you know the builder doesn't send his block 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 the relationship. That will actually change very soon with EPBS. 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 reveal scheme that allow the proposer and the builder to communicate trustlessly. >> Okay. So kind of in the status quo the re layer 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 um and kind of steal that from the builder. just reveals the different price points that uh the proposer could get and then the proposer um 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 ME extraction happens in this scheme.

>> Well, it can happen at at many levels but uh generally happens mostly at the central level. So the ones that are actually constructing the valuable bundles are usually the ones that are like extracting me some me but then you know like uh they usually bid against each other to get their bundles included in 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 out bid each other so most of the value is actually given to the proposer. Yeah,

that's sort of like the chain of events that um you have multiple auctions happening. uh 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 block to the rest of the network. So yeah there's quite a lot of of value that goes to the proposer. There are like you know some apps uh that are like capturing the value before it even gets uh leaked. So it can be captured at at like many levels. We also have you know order flow auctions that are that are like redistributing some of the value that are captured from users to the users before like going to to searchers or builders. So it 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 uh it's evolving quite fast and I think we are like trending towards a world in which hopefully um quite a lot of value is actually redirected to the users because their transactions are actually the ones creating the me in the first place. So it would be nice to to get it back to them. If you kind of look at me that's extractable that usually comes from the public meool. So kind of if you connect to a regular RPC endpoint and kind of send your transactions there kind of your transactions um float around in public for a bit. Um kind of

there are actually quite a lot um of transactions that never see the light of the public meool. I think it's between 30 and 40% of transactions and in excess of 50% of block value that never actually see the public me. So um these transactions go direct directly to the builders. Um it comes from kind of like I mean sure kind of like the me searches that we just talked about because kind of they also insert transactions obviously and I mean obviously they don't go to the to the meool first. um but also structural private order flow from applications with um intentbased execution like cow swap wallets and RPC

providers that protect you from uh being sandwiched. So me blocker, flashbots, protect and so on. And then there's also kind of like white glove services that um directly relay um 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 sending a transaction to the public meool there are, why are 70 to 60% of transactions still send that way because you could just you could just connect to me blocker or uh flashbots

protect RPC endpoint, right? >> Yes. Uh I mean the big downside of of connecting to a private auction for example compared to the public meu is the trusted part of it you need to actually send it to someone that guarantees that your transaction is going to be is going to stay private and it's not going to be sandwiched and everything but you still have to trust that that party whereas the public man is actually seen and watched by every node uh from so it's like gossiped publicly uh and every node will actually look at the public meool and so transactions can be included via the public meool in a very trustless way. So that's the the

sort of like big difference. I think it's like trusted versus untrusted. But then uh right now if you if you want to do it in a trustless way, yes, if your transaction carries me, it will be seen by everyone and that means they can take advantage of of some you know slipage 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 um 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 search and do you have any idea of how much money builders make today >> so I I I don't think it's a public

information but I can tell you they get they they do get squeezed it's a bit weird like like very dominant builders like can make 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 like bid a bit higher than their competitors, but they know they have like this sort of like leeway and they can actually keep that for themselves. So that that happens. But even with dominant 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 said like it's if you just build like

it's it's very nonprofitable 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 it can be actually profitable but like it 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 uh they have to get access to order flow or like search themselves. But then it it becomes actually very very sophisticated and hard. And it's kind of a chicken and 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're like, well, it doesn't it's not worth. Uh so it's a 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 it's very trusted. It's it's like uh 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 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 a 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 build more than 80% of the blocks of of the network Now you have Quazar that came in that is now I think around 10 to 15% of the the network. So you have three that make up for like 85 80 85% of the the

network. It's worth saying you have like initiatives for example builderet that is like trying to go towards decentralizing block building but it's hard and it's uh sort of like it's the project in a in a way and so you know they are having different nodes controlled by different people but um 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 worth actually saying that there are like a lot of efforts to go towards this but like right now it's we say yeah basically it's three builders that are like building more than 80 85% of the birth.

>> Mhm. What about relayers? Um how how centralized is that ecosystem and um 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 you're still like at the end of the of the day like running infrastructure and like providing a service. So it's like if you make absolutely zero revenues then it's a bit hard for people to expect but there will be many relays just like doing this altruistically 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 to fund themselves. I

don't think it's very profitable but like they they they have this sort of like auction mechanics as well and they are quite centralized. I think um I I don't have the numbers in in mind exactly for relays right now but yeah most of them go through uh I would say three two three relays. Most of the they are the most performant. they are the ones like that everyone knows. Uh 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. Uh but they don't get really the the right to pick and choose and exclude given like some transactions over others. It's more at the at the block level. uh they can just like

choose not to send the blog but they can't they can't really like manipulate the transactions themselves because the blogs are supposed to be built by the builders. >> Mhm. 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. Um so in this PBS pipeline so builders re layers proposers. >> Yeah. >> Who actually has the power to send the transactions? >> Yeah. All of them all of them in in in very different ways in a in a way like so I think it's important to basically say that when a a block or transaction goes through multiple steps and and which is sort of like always the case like basically at every step it can be

sensor right because like the sort of like entity processing it can just be like um 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 transaction. 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 um 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 me 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 h and again the relay can choose to forward a block uh or not from the builder to the proposer it can be like no uh this one I'm not going to do it so yeah you you do have like quite a few points of censorship along the Okay. Um the best way to think about is like every everyone that processes your transaction will probably have a say um 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 it's possible at each of these gate points, but what happens in practice? So it it's

worth mentioning like censorship right now on on Ethereum is quite low. Like there there is not much censorship like going on right now. It it it was a bit there was a bit more in the past but like now it's pretty pretty much u it's quite yeah it's it's not a huge concern but when censorship like when people are censoring they they do it at like all the levels I I mentioned. It is worth saying that right now proposers have always acted uh 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 um for example like tornado cash transactions

that were sort of like censored uh from some very dominant builders. So like they wouldn't make it on chain um or they had to basically wait a way longer time than other transactions until they made it on chain. And you had these um proposers that were locally building their blocks uh 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 uh altruistically still build their blocks uh so that all transactions that are like pending in the main pool and waiting to be including uh included are are actually included. Um so and you know I think something worth mentioning

is like uh and that actually matters a lot is like the set of composers is much more distributed and decentralized than the few builders and the few relays. Um so at the end you have like much more preferences that are expressed through the set of proposals than you have uh through the set of of builders in a way uh 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 um what actually happened was that um flashbots me boost um 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 I I don't think at this I'm not aware of like any actual, you know, laws or regulations passing at the time that would that prompted them to start it. So I think it was like in anticipation of of maybe um getting into some trouble uh if they did something. I don't know if I have no idea exactly the reasons why they actually started this, but what was um true is that they I think a lot of the other like dominant builders like

followed and sort of like saw this and and basically had the same thoughts I guess. Uh uh 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 to be censored for a very long time until they included by like another entity. So, and that's basically what you know for we'll talk about it is all about 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. uh turned out it was uh it was to the cash and and fact but like

it can be a lot of different reasons that we can also go maybe get into because it's interesting and then you have a huge impact on the the network and and suddenly like the sort of like censorship resistance properties of Ethereum are like um eroded quite 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 um I would be super interested to kind of hear what um what exactly um 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?

>> Uh no, so I think I think that's basically it. That's like the one use case. I think like some people are like still censoring u ofac or tornado cash transactions for example. It's just like there's way less as well. Uh because like people are not using tornado cash a lot these days. So it's >> taken off of the effect list. So kind of uh >> Yeah. Yes. But um you know there was a big hit in in sort of like tornado usage after the sanctions and everything and it never really recovered. So the amount of transactions that are actually going through because tornado cash for example is still like very low. So there are like very few transactions that actually

uh get censored just because like few transactions that are like submitted and that would be censored in the first place. >> Okay. So there's not a lot of things that actually currently get censored, but in principle they could. Okay. >> Exactly. Uh yeah, and just maybe worth mentioning that again like that was one use case, but I I feel like it's some sometimes forgotten about that um you can sensor like very easily for very different reasons. For example, just like pure competition. Um, 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 pretty t tempting

like it's it is like a counterparty risk basically and and that's and it's very real and and there and like I think people are quite blind right now like we haven't really seen a lot of it and but it's uh I think it's a bit naive to expect this won't ever happen. So >> yeah, so I think kind of the social norm is not enough. >> No, I mean I mean the the whole thesis of blockchain is like we shouldn't rely on social nor social norms to enforce these things. So yeah. >> Cool. Um then tell tell us how for works and um how how it addresses this concern.

>> Yeah. So basically again you have the builders on one side that are like very concent like centralized and quite sophisticated and then um you have the proposers that are like part of the validator set that is much more decentralized and so the idea is like every slot you select 16 validators randomly and these validators are just just have to look at the public meu basically and make lists of transactions so up to a certain limit. So there are like small lists of of transactions basically from the public man poolool and they do that like it's hardcoded 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 uristics like you usually maybe want to like take the transactions that pay the most priority fees or that have been pending in the meool for the longest. just like rough huristic but like there's no actual preference of like I like these transactions or 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 blogs 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 uh if

they want it to be valid. So that constraints the the builders basically on the transactions it needs to include in its block otherwise when you know a test 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 like multiple basically proposers contributing to what needs to be included in in in a block. Uh 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 it's just like a way to to enforce some constraint to make

sure um 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 or or compliance reasons. H >> how are the validators who are um on this inclusionless committee chosen? Is it the same way that kind of we choose the attestation committee? Uh yeah, it it's random. Uh >> it's random. So kind of in principle then transactions could still be censored if these 16 people or entities kind of colluded and decided to kind of leave off one transaction for sure because it's kind of like if it 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 it will be censored. you have two kind of cool things. Uh 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 elected 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 tester set is um 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. Um 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 n 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. >> Exception. >> So now I'm a builder and for some reason I kind of I don't include one of the transactions that was in the on the inclusion list. What what what happens?

So kind of I sell that block to a proposer and the proposer proposes the block and then >> and then the testers so you know you have a block proposal and then atesters need to vote for that block in order for it to make it part of the the caninical chain. uh and the testers will basically they will have seen the inclusion list. So they will have done the exact same thing they they see the inclusion list they take the union of all transactions in it and then they check whether the the builder block includes these transactions or not and if it doesn't uh based on what they saw so based on their local view of what they saw just like don't vote for the block and the block like never makes it on train basically.

So it's it's it's sort of a validity condition for for the block and testers are like yeah um I did 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 proposed so I'm not going to vote for it. >> Okay. So uh we already said that um kind of as an inclusion list producer I have no particular uh obligation to kind of choose any particular transaction. But what happens if I'm offline or lazy? Do I get penalized for not producing um an inclusion list?

>> No. 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 for that slot and that's totally fine. And you don't get penalized. And then lazy can't really happen in like in all of this is is basically hardcoded 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 validator like automatically it's basically going to do this and choose transactions from the main poolool and and build these lists and send them to the network. So uh there is no there is no active sort of like tasks that they need to do in practice you just run a node and that sometimes you

get selected to to do to perform this additional duty. Okay, so kind of um these are the inclusionists. They only include visible transactions. So kind of transactions that come from the me pool. But we just talked about the fact that um kind of a large percentage of the order flow is actually private. What influence does does that that have on on censorship? >> Yeah. So very very clearly for does not really like cover the me transactions use cases and and it is missing like a lot of transactions cuz like a lot of transactions do do contain MV but uh there's 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 man poolool and you you know imagine even even if you are like an includus 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 me and public like doesn't really go super well together like it's if you are extracting me by definition you basically don't want people to be able to see it and and modify it before the block is sort of like finalized and and sort of and set in stone there are like ways to to sort of like build on top of

for accommodate for me transactions uh and we can maybe get into encrypted mess later because it's one of the very obvious option but for now uh for is made for public transactions so not for transactions you want to keep private for me reasons basically. >> Yeah. So the mempool is a pretty ephemeral thing, right? So kind of there's no objective meool because kind of like it relies on gossip. What prevents me from being an evil inclusion list producer and just inventing a transaction that no one else has seen because I made it up. Um and then kind of note 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 transaction like 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. Uh so it has a cost basically. You could you know fill your inclusion list with transactions that are only yours. if they are valid like you have to basically pay for it or you can just like submit an inclusion list with like invalid transactions but then um everyone will see that they are invalid and so they won't penalize the the builder for having proposed for not having included them basically. So you

you you see the list of transactions but like as an you actually execute them and 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 kind of it's not just a transaction idea idea. It's kind of the entire transaction that would be sufficient to kind of include it even even if you don't see the transaction itself on the meool, you can still include it. Okay. Perfect.

>> Exactly. Yeah. the the inclusion list like contain the full transactions. >> Okay. Are there any me 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 meool and by doing that if it's included with for you have like a you you can like force people's hands in a way. Uh so that that actually uh works quite well. But other than this just like again like I think most strategies are like are centered around like not leaking any sort of like

valuable data uh which will be the case through false. So, so no, I don't I don't think it affects. There was also a very meaningful intent uh in the design of Fossil not to involve MV because if it involves MV transactions um and you don't have like um encrypted transactions um then all the inclusion list will be filled with MV transactions, right? like it's you can like recreate a meth boost market basically where inclusion list 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 um if we want this to be for censorship

resistance we have to prevent it from being crowded out by me transactions basically and so we want to design it especially so it's ills suited to include transactions um that are extracting MV otherwise it's just going to get corrupted just like the block was and you're gonna have like the builders that are going to be building extremely valuable inclusion list and you're back to square one. So, so it was very intentional not to to to make it suitable for MV. >> Mhm. One other direction that kind of um we've talked about um in the community for censorship resistance is meool encryption. You already talked about it in paring earlier. Kind of me encryption just means that kind of before I send my

transaction to a public meool, I encrypt it 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 the encrypted meool does not. >> So I I think they are very complimentary 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 false whether like you have encrypted transactions or not. um the fact that you it's more like I think encrypted mess give you a protection against me basically um because yeah it's important to reiterate that encrypted mess 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 um to sort of like make sure a transaction for example goes through Fossil without revealing any sort of like crucial information and that now means that basically sensitive transactions like me transactions um can be encrypted go through for be force included in the block and then later you reveal uh their content which will actually protect you against me and that sort of like is one of the very crucial step to make um MV transactions uh to give like better inclusion guarantees or

better better censorship resistance for MV transactions. >> So why doesn't encryption alone guarantee censorship resistance? Because someone could just say, "Look, this I have no idea what this says. I'm I'm not going to include it." Or what? >> 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." So if you if you don't have something like Fossil, there is no nothing that forces them to include any transactions and including all the encrypted ones. So yeah, I I can see that happening.

>> Okay. I recently did a podcast with uh Peter Fenbachenberg from Coin Center and he very interestingly argued that um networks must be actually blind, not just willfully blind to resist censorship mandates and remain credibly neutral. Do you agree? >> Yes. Uh I actually agree. I think if you never see any transactions content and you participate in a network which mean and you have validators and like the whole network is like basically functional then you have the best sensorship resistance properties you could imagine. Maybe one caveat is like it's even even if you don't have like

good sensor 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 it then you know. >> Yes, exactly. But like no one not in the public meool sense like no one can tell outside of you. Um same like if you mean an infinite amount of tokens like in theory like no one can actually know. Um but yeah no if you have total privacy you have like extremely good censorship resistance properties which is also important to to note like because now we are talking about like sort of like permanent privacy like um networks like I don't know like Zcash or like that give you actual privacy in a sort of like long-term sense of the yeah long term if you have like temporary privacy

with encrypted mess then you have like more censorship resistance but less than you will have with like longer term privacy and you if you have like full transparency you have less so it's like a sort of like spectrum right it's I do I do think there is like a very sort of like strong relationship between privacy and and social resistance I think the bottlenecks uh if if your next question was going to be like why do don't we have like um better like privacy solutions either like encrypted mess or or or longer term privacy on on Ethereum for example it's just because it's technically very difficult to implement and you need to make extremely um complicated trade-offs even just for

encrypted mess. 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. So like you need to make trade-offs everywhere. And yeah, if we really wanted to go full on privacy for everything, um you'll need to like rearch rearchitect uh some parts of the protocol quite uh like deeply and it it is being like considered and people um for example at DF like are working on this quite quite a lot. Um but I would say it's more focused on like what use cases do we want to enable privacy for rather than uh allowing every everything

to be private because um yeah maybe another point is like for example Zcash only allows transfers. If you if you don't want to make like everything that's possible on Ethereum private, it's much more complicated because it's programmable and you can actually do a bunch of of stuff other than just like transferring value. So uh it would it would be quite hard like Aztec is a is a good example of like uh a network that tried this but uh but yeah >> the current version of Aztec does actually make everything private. So right kind of like it used to be that kind of there were only certain transactions that were um private but kind of in the in the I forget what the current versions hold but kind of like it's actually fully private.

>> Yeah. of obviously kind of like it's no longer it's it's not an EVM chain now but uh I mean it also was an EVM chain before but uh yeah so in principle it's possible. >> Oh no no for sure. No so I I was saying Aztec in the current version uh I was just saying if you want Ethereum to become like Aztec then you need a complete re rearchitecture of the protocol like it it's it looks like a a very different sort of like protocol. It's kind of it's also fine to kind of have um 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. Uh it obviously kind of this is um Okay. Um so tell us about um the I mean we talked

about the EIP for a long time now. So kind of you you proposed it probably like two years ago or so. Um what what's the current status of the EIP? Uh when are we going to see this uh live? >> Uh yeah, so I I proposed it for Glamsterdam which is going to be the very next fork. Uh but the scope has already been finalized and and Fossil was not included in Glamsterdam. And then the the reasons were really uh around for scope like basically we couldn't fit a fossil in with what was already sort of like included in the fork including EPBS

u which is a very cool but like very big feature so it it's hard to pack it all in and now we have a whole new process with headliners so we need to pick you know big sort of like um EIPs we are willing to delay the fork for for each fork and so you can have like that many big EIPs included for is not as big as EPBS at all, but like it's still like an IP that touches both both layers and everything. So, it needs a bit of space. And so, what happened is like we couldn't include it in Glamsterdam. Um, and the decision was to automatically sort of like consider it consider it for inclusion in the next fork after that.

So he go now uh I think next week the headliner proposal uh period closes then there's going to be a month of governance to decide what uh is going to be the headliner and then uh after this we we'll know if if if selected as the headliner or not. So of course I like reproposed it and it it was already sort of like cified or like considered for inclusion for for her automatically. Um but it's it's very hard to tell before uh governance actually happens.

>> But there are no open technical questions for inclusion, right? >> No. Yeah, it's been a while now and there are no technical uh limitations which is a very good sign. Uh there are like trade-offs and limitations that we already mentioned. for example, like it doesn't cover MV transactions, but the there are no incompatibilities or like we made sure it's actually very compatible with existing um you know the existing protocol but also the the forks after. So it's uh yeah it's been worked on quite a lot.

>> If if uh were to be included tomorrow um is there a failure mode that would keep you up at night? >> That's a good question. Yeah, I don't think >> no is also fine as an answer. >> Yeah. Yeah. I don't think so. I I don't I don't think there is a a failure mode that that like we just like need to implement it very carefully like every sort of fork because it touches fork choice. It's like another sort of thing all at testers have to do each each block. So it's uh we need to be extremely careful about that part but nothing like we haven't done before and and then not not really because I I do see fossil as like the first it's a big big step in terms of primitive um 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 the but that's why we kept it very very minimal as well. You can try to add so many things on top of fossil. >> You can have like blood futures. You can have encrypted mess. You can have a lot of different things. You can have what I call zk fossil to sort of like um break the link between who does who proposes the inclusion list and the content of the inclusion list. You can you can actually do super cool things. Uh but the the version we want to ship now is the primitive and it's very simple. And so I I think I I don't see like a big failure case right now at least.

>> Okay. Then maybe let me um uh kind of make the question somewhat milder. Um what's the strongest argument um against FOSA that you've heard from someone we respect? >> I think that it that 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 it's true. And so we are working very hard on like having blob transactions. So sensory resistance for blobs. Um I don't think it should be part of fossil just because it it needs other things like for example you need to determine the availability of a blob because now we have pas and and so it's not the case for regular transactions.

So it's you need like extra stuff. So you can't really like put it all in for um but that is a very good argument because we actually need it very much. uh and we are working on it. MV as I said is a bit more tricky like you will need encrypted mess and I'm I'm less sure we have enough confidence on on the design for it to be enshrined on Ethereum right now but it's also like quite an active sort of like research uh topic. Yeah, I feel like the no the actual push back I've heard the most um aside from like it doesn't do enough is uh we don't need it right now because censorship is quite low right now. So that that's been an actual push back 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. Uh uh I'm 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 on Ethereum and we are not prepared for it. I I do think like a lot of like the sort of like properties that Ethereum has and people care about are like around security um res resilience robustness uptime. s like all the these things. So if I don't want to expose the protocol to something

that will actually erode these these values and sort of like properties that everyone deeply cares about. So I hear the argument like I I agree there is not much censorship but it's it's hard for me to sort of like think the same I guess. Mhm. So if this um gets uh included in uh Hegota, what's next for you? What will you be concentrating on? Will will it be improving on fossil or doing something all together new? >> Uh yeah. So on the fossil part like I'm I am a researcher. So I I feel like I I've pushed already quite far by you know like u with the help of of June 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 fork. But of course, I I'll still like monitor and sort of like make things make 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 mainet, there is a lot of activity and devs 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 uh quite a lot of work on transition to post postquantum

for example network resilience P2P networking resilience hardening client code preparing the transition to ZKVM uh in a safe way because it's it's early and it's it's new tech so we need to sort of like make sure it's it's okay um handling stake growth if you want to stay scale we 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 to store like too much too much data all the time. Then there is like extensions of fossil I talked about like blobs is is a very obvious one and then you have like ZK for like making it more accessible like everyone can become an includer now you know you don't need to become a validate to be a validator for

example you you do have uh quite a lot of things going when it comes to making sure the the network is is more secure um both on sort of like the very sort of like technical way uh you know engineering way in a way like just like making the the things more robust first um 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 on what happens in the network and and and you don't just have builders like you have like different case for example RPCs is a quite obvious one it's quite concentrated and and centralized as

well. So I think there is a a big effort um in the coming year to work on this and and fix it uh and dedicate more resources as a as a nor to to fixing this. >> Cool. Thank you so much for coming on to >> Thank you. Thanks for having me. [music] [music]