EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL)

Transcript

The main goal of fossil is to increase the credible neutrality of the Ethereum. It might unlock some like big scaling improvements and some kind of better separation between participants and duties. The maximum is set to the lowest hardware requirements. Then we need fossil. What's the most overhyped use case for blockchain? No use case is worth hyping without Hello and welcome to PEEPanEIP, the one and only show where we dive deep into Ethereum Improvement Proposal and we explore their impact on the ecosystem.

This is episode 141 brought to you by Ethereum Cat Herders. I'm your host Pooja Ranjan and today we are talking about EIP 7805, forced choice in forced inclusion in it. Documented in November 2024, EIP 7805 is a standard track core proposal currently in draft status. This proposal aims to allow a committee of validators to force include a set of transaction in every block.

Co-authored by Thomas Thiery, Francesco, Julian Barnabé Terence Jacob and Jeehoon, the proposal is in active discussion for a future upgrade. In this episode, we'll explore the details of EIP 7805, its implication, and its potential impact on Ethereum ecosystem. To talk more about the proposal, we are joined by Thomas Thiery and Julian Ma. Welcome to PEEPanEIP. Thanks for having us.

Yeah, thank you so much for having us. We are excited to learn about the overview of the proposal, where it stands today, and how soon we can see it on Ethereum mainnet. But before we get started, our community love getting to know our researchers and developers behind the work. Could you share a bit about yourself, the project you are currently involved in, and your journey within the Ethereum ecosystem? Yeah, sure. I can start off maybe. So, I'm Julian. I'm a researcher at the Robust Incentives Group, just like Toma, at the Ethereum Foundation. The Robust Incentives Group is concerned with economics of the protocol very broadly.

Uh so, some of us have been looking at transaction fee mechanisms, like EIP-1559, and others have been looking at consensus layer attached, mostly based by economic incentives. I think for me, I started off with an internship by looking at base fee derivatives, and after that I joined full-time, and I've been working mostly on proposal builder separation, MEV-related topics, and now focusing on inclusion list via fossil with this EIP, and looking forward to a tested proposal separation. I'd say I'm most excited about bringing research into production via uh this pipeline of starting with some more theoretical work and bringing it towards an EIP that can hopefully be proposed and implemented within Ethereum.

Uh yeah, I'm Toma. So, I also work at the Ethereum Foundation in the Robust Incentives Group. I'm doing research. And so, yeah, no, before like my background is actually I did a PhD in neuroscience, which was very different. But then got like curious about like blockchains and and like distributed systems, and so wanted to try something a bit different out, and I joined a crypto data company that's called Dune. I stayed there for a while, but then I missed doing research more, I guess. I was lucky enough to be able to join the EF and the Robust Incentives Group, which was has been great so far.

Um I've also worked on like similar topics, I guess, like MEV was quite big when I joined. Interestingly, my very, very first like if research both were very small, but it was on like inclusion delays and censorship resistance. Then I like didn't really like dive deep into it until like more recently, I guess. For the like 6 months or 2 year I've been a little more active on the censorship resistance inclusion uh side of things. It's been like really nice to be able to come and start with like research ideas and then like sort of improve on previous ideas that were like very interesting, but like

didn't include some of the details we are going to talk about and be able to come up with a proposal and now implementations and devnets actually that are, I think, like quite good and and that most of the people I've talked to at least think would be a good addition to to Ethereum and would allow some cool things. Thank you for sharing. It is always inspiring to learn the background about the developers. It is interesting to follow that they are coming from different domain and ultimately contributing to Ethereum ecosystem.

I understand we do got a presentation here today. So without further ado, let's peep in. Perfect. Thank you so much. Okay, so I'd like to start off with a small presentation about how EIP-7505 or Fossor works and why exactly we want to do it. It's meant to start the conversation and it's not supposed to be too long. It also won't be too in-depth to leave some room for discussion afterwards. So without further ado, the main goal of Fossor is to increase the credible neutrality of Ethereum. And Fossor does so by removing the inclusion monopoly that currently a single proposer or block builder holds within a slot. Instead, Fossor allows a multiple validators to to building a block by including transactions in each block.

The higher level goal is to pursue this property that we call chain neutrality, which means any pending fee paying transaction also be included if it's available and if there's room to include it on chain. And we believe that if this property is sufficiently satisfied, then we can credibly increase the credible neutrality. Why do we need something like this? Well, currently almost all validators outsource block construction to MEV Boost, which is an out-of-protocol market where builders bid for block construction rights. And in this market, there are only two entities that really dominate. And this means that 90% of blocks are built by only two entities.

And we see here that Ethereum can't source its credible neutrality from local block building anymore. It once did. It started out by having proposers located all over the world, and they each built their blocks locally, meaning that all transactions were included. But now that block building is outsourced to these sophisticated entities, this isn't sufficient anymore. So, it's necessary to implement some more robust anti-censorship measures, and Fossor is the best-known way to do so. So, why should we implement Fossor now? Well, you may think that builders are not censoring as much now, but they could start censoring at any point, whether this is because of regulatory reasons or economic reasons. And economic censorship is definitely something not to be misunderstood. It's also good to introduce Fossor when there's relatively little censorship

because then you introduce it as a baseline and as a default. All validators make inclusion lists regardless of of their jurisdiction or economic incentives. And also, it causes little market instability. Whereas, if you were to introduce Fossor and when all builders are censoring, perhaps it would be more difficult. Then, base rollups are becoming more of a thing these days, and they will overload Ethereum's block building. So, it's necessary for us, if we want to provide the sequencing that Ethereum has, then it's necessary to have credible neutrality here via Fossor.

And potentially, Fossor could help with skating depending on who you ask. So, during the Ethereum still sources its censorship resistance from local block building. However, if Ethereum can send sources censorship resistance from elsewhere, for example, via fossil, then maybe we can increase the expectations that we have of block builders and allow for for example, more blocks. But potentially this could be done without fossil as well. Therefore, we have proposed or Demas proposed fossil to be implemented in Fustata. So, now I'll walk you through how fossil works. We'll start with the basics and go step by step until we have the full mechanism and then explore how this full mechanism satisfies the properties that we want. So, the basic idea of an inclusion list that's been proposed by

Mike Neuder before as well is that there's a list of transactions that constrains the block in some way. So, there's for example, this inclusion list which includes transactions A and B and it's signed over by someone that's recognized by the protocol and then these transactions must be included in some block. So, fossil doesn't change it. It builds upon this and it's more about who creates this list and how this list is enforced. So, who creates this list? This is the first step of how the fossil protocol works. And each slot 16 validators are selected as inclusion list committee members. And each of these committee members observe the mempool and construct their own inclusion list. This inclusion list all play could look something like this as we've seen in the previous slide as well.

And it should be around 8 kilobytes or about 20 average transactions meaning about 320 average transactions in total. Then the second step is distributing these inclusion lists. So, the inclusion list committee members distribute the inclusion list over the global topic and they don't include them in the block themselves. They must do so before second 9 into the slot at which time attestors freeze their view of local files. So, as we'll see in the next step, attestors are the people that actually enforce these inclusion lists as the name suggests for choice and for inclusion lists. And what they do is they'll freeze their view of which inclusion list they'll enforce at second 9.

And this prevents the split view attack. So, the block producer still has a few extra seconds to observe inclusion lists and to ensure that it's not negatively affected basically by missing any inclusion lists, and therefore the block producer has no risk in this setting. Then we head over to the final step, which is enforcement. So, as I said, the enforcement is done via the fork choice. Attesters will only vote for a block if it satisfies the inclusion list condition. They do so by observing the inclusion lists that were sent in the global topic and making an added list of transactions that they had seen in these inclusion lists, and then checking whether all of these transactions were in the block. If this check passes, then they vote for the block. However, it could also be the case that not all transactions are in the block that they had seen in the

inclusion list, but the block is full. In that case, attesters also vote for the block. So, unless the block doesn't contain transactions and isn't full, attesters vote for the block. So, then we get to the full mechanism recap. We see that in each slot, 16 committee members are selected as inclusion list committee members. They observe the mempool and they construct these inclusion list objects that they distribute over the global topic, and they must do so before a deadline. And in this case, this is second nine. The builder observes these inclusion lists and includes all transactions that it had seen in its block.

The attesters then check whether all the transactions that they had seen before second nine in inclusion lists are indeed in the block. And if this check passes, as I explained previously, then they vote for the block and we move on to the next slot in which the same setup happens again. So, one of the big worries about inclusion lists that have been voiced for the previous EIP from Mike and for the development after that is IO boost or unprofitability. And it refers to the fact that single IO proposers might want to sell their their rights to build an inclusion list. It's a very logical concern because we see this happening with block construction, that selling this right leads to a centralized market of sophisticated builders.

We argue that fossils are robust against these sort of like MEV boost like markets or IO boost as they're colloquially known because of the following properties. Full soul doesn't guarantee any ordering transactions. So, regardless of where you put your transaction in your inclusion list, it will be ordered in whatever the way the block builder seems fit. So, if you would for example include an arbitrage transaction in the block, it's highly unlikely that the builder will put your arbitrage transaction at the top of the block so that it will actually execute the arbitrage. Instead, the builder will probably do it themselves. Moreover, private order flow is not possible. So, these inclusion lists are distributed over the global topic. And so, your transactions are public before the builder builds the block. So, it's not possible to have private order flow

enter the block uh via inclusion list. Thirdly, there are multiple inclusion list proposers per slot. So, even if there was something valuable to sell, all of these 16 inclusion list committee members have the same possibility to construct this inclusion list. And so, competition amongst those inclusion list proposers would drive the value of down to zero. And finally, these inclusion lists are created 3 seconds before the block producer acts. So, there's 3 seconds of extra information which is usually extremely relevant for MEV type of transactions that will happen after the inclusion list is committed to and before the block producer acts, meaning that there is very little informational advantage. And actually, there's an informational disadvantage for those that are trying to use inclusion list as

a vehicle for MEV. And because of these reasons, we believe that no individual inclusion list proposer has inclusion, ordering, or exclusion power, which is the fundamental definition of MEV. And therefore, inclusion list should not be subject to MEV. So, just to summarize this quick presentation, full soul allows multiple validators to contribute to block construction, preventing inclusion monopoly of a single proposer, and boosting Ethereum's credibility and neutrality. And we believe that it's necessary to implement full soul now because uh there are currently only two dominant builders that could start censoring at any point.

Again, this could also be for economic reasons that they may benefit from. Block building could become more load-bearing because base rollups will want to use the Ethereum sequencing properties. Fossil will launch far more smoothly when there are few censoring parties. One, because it means that it's a default for validators to build inclusion list. And secondly, because it means that there's less market instability from certain builders that are censoring and certain builders that aren't censoring. And finally, fossil could potentially help with skating, which is maybe a subject that we can dive more into. So, yeah. Thanks for the time to give this small presentation. And I just wanted to show the QR code, which leads to the EIP for people are interested.

Thank you so much for this quick presentation and the overview of the proposal, what it is proposing altogether. I would like to begin the next section, the Q&A section, with the very first question that was also mentioned in your presentation about the earlier proposal. Proposal number is 7547 inclusion list by Mike Neuder. I want to understand what is the basic difference between that proposal and the fossil we have it with 7805. You did partially touch in your presentation about the IL boost and uncrowdability. Would you want to maybe explain a little bit more about it?

Yeah. So, maybe perhaps Thomas best suited to answer the question of how 7805 differs from 7547, but I could say a little bit about it. First of all, fossil is for the same slot, whereas 7547 was for the next slot. The same slot property sat at I just made some properties easier because it means that the inclusion list doesn't have to be stored on chain. And then with regards to the uncrowdability property, I think this is a very interesting one. It's a very subtle one, actually. So, within Mike 74 7547, which was a a great proposal that our proposal builds on as well, the inclusion list is unconditional appended at the bottom of the block and made by one person. And so this has a few different properties than ours.

First of all, transactions are ordered. So it could be that in the future, it's very valuable to have bottom of block arbitrage. And in fact, some of Thomas' research has highlighted that this could could have potentially be a valuable place. And so having rights to build the inclusionist means that you are the last person to act in the block. And so for some cases, this might be valuable. Secondly, it's made by one single person. So there's not this competing effect among inclusionist committee members. This inclusionist committee of consisting of one person has the full right to include transactions at the bottom of block, which might make it more valuable as well. And so and thirdly, there's this unconditional property which means that regardless of what the block producer does, your transaction will be included on chain anyway. And so it has a few extra

guarantees that are not the necessary minimal for inclusion that might make them valuable to some extent. Maybe some big difference is also is like the just like the number of inclusionist proposals we have. In the previous proposal, there was a kind of a mechanism by which the proposal of slot n will make the inclusionist that proposal of slot n plus one needed to enforce. So the two big key things here is like first, there is a one slot delay because there is a a one slot delay. So the transactions in the inclusionist only have to be included on the next slot by the proposal of the next slot.

And there is only one proposal, right? That actually makes like the inclusionist. So with fossil, we have 16 now, but at least we have many. And it does make a huge difference because now we only need one out of the 16 IL committee members to be honest for the whole mechanism to work as intended. So it kind of multiplies your chances of actually having a good censorship resistant mechanism, whereas before you just relied on that single party. So, I do think there is a big crucial difference there. And then, yeah, some like more like technical details, there were some like incompatibilities with the account abstraction, and it was hard to deal with the IL equivocation as

well. Like, how do you deal with the someone that sends two ILs? Because, I mean, block equivocation is like a known thing, and it's actually special by the protocol, but like you since like everything went on chain in the previous proposal, you also had to deal with like a weird edge cases, and it wasn't like very easy to actually accommodate for it. Now, yeah, with fossil, like the inclusion is actually don't get on chain. They're just like broadcast over the P2P consensus layer network. So, so yeah, it's a bit technical, but it does make a big difference in terms of like dealing with these kind of edge cases caused by the account abstraction or or sort of

attacks you could do with the splitting the network into two views with IL equivocation. Thank you so much. We will perhaps get into details with other compatibility with different EIPs later on, but for people to maybe who would want to learn more about this proposal 7547, we do have a recorded episode with Mike Neuder on episode 130 on PEEPanEIP that can also provide a high-level overview. I always love to see competitive proposals because I know that is for the betterment of the ecosystem, that is betterment for the chain. So, thank you for sharing the basic difference with us here.

I see on chat there are a few questions. Maybe I would like to invite Katya to share her question here. It has been answered, but it would be nice for listeners to follow the question as well as answered there. Hello. Yeah, thank you. My question was, so is the block proposer gets like 16 E in cursed at least each from one committee and it has like to include all the transactions from this list. Yeah, that's right. You take the union of all transactions across all lists and you have in our case like 16 lists. So what you do is like yeah, you have to include all these transactions that are contained in all all lists. You might

have overlap obviously, so that's why you take the union, you deduplicate, but yes, like all transactions in all need to be included in the block for it to be considered valid by attestors. Thank you. The next question in the chat is by Justin. Justin, would you like to maybe read your question for the guest? Oh boy, I've been asking so many questions. Let's see. Yeah, I think it was fairly answered. I wanted to ask what prevents putting a transaction from a private mem pool into an inclusion list. It sounds like that's totally fine considering that the builder is essentially going to order them however they see fit anyway and your transaction becomes public when it goes out on the IL as well. So

I think that makes sense. Thank you. That was one consideration like I think Julian mentioned it but like we really didn't want fossil and inclusion list to be used for either including a maybe transactions or private order flow or pre-confirmations cuz ultimately what we want is like censorship resistance and like it's very easy for it to become a vehicle for including valuable transactions if you're not very careful. And so the fact that when you include your transaction in an inclusion list, it automatically becomes public, everyone can see it, it has no ordering guarantees and it can be included by the builder anywhere in the block makes it like very hard or like it's just not very well

suited for valuable transactions to try to get in this way. So, it's either or like your public transaction and you might just like want to submit your transaction in the public mem pool for it to be included in an inclusion list, or you have valuable private transactions, and then you wouldn't go through fossil because it's just a a better way to do it. You would just like contact the builder directly and send it privately or like through through the app through private ways. Thank you for sharing. I see the next question is by Laddi Singh Laos. If you would like to maybe read the question.

Yeah, hi guys. So, this refers to the point you and you brought up in terms of fossil and scaling. And I hope it's the right time now. Maybe we can do we can answer now. So, I've seen some discussion lately on we all have I guess on scaling Ethereum and as you are rightfully mentioned, there's this this bottleneck by a few builders out there. And so, I personally like to think of fossil as re-empowering local building. And then I see it as a necessity to be in protocolized before we increase the bandwidth requirements or in general node requirements. So, maybe you can or it would be great if you could elaborate on how you think about this and also potential other ways to scaling maybe without fossil as you mentioned. I'm

curious to hear your thoughts on this. Yeah, thank you for the question. So, first of all, yeah, I think the the case for scaling via fossil. The idea is that currently 90% of validators outsource block construction to MEV-Boost. And these sophisticated entities obviously have more bandwidth than the minimum hardware requirements. So, they could for example include more blobs in their blocks without leading to any issues there, I guess. An interesting thing though is that the Ethereum relies on local block building for credible neutrality or censorship resistance because these two like sophisticated entities aren't ones that Ethereum censorship resistance is built on. So, the Ethereum protocol must still be designed that it's possible that these two do load to block building

and in fact we design it so that it's not unprofitable to do load to block building or unprofitable compared to MEV boost. This is in the design of Ethereum, but in practice of course MEV boost is far more possible. One because these sophisticated block builders are sophisticated and have more involved algorithms and secondly because of the them having a lot more private order flow. So, there was some research by Data Always recently that showed that MEV boost blocks contain far more transactions. That alone leads to more profit of course. Still the protocol is designed so that if there's no forces from within the protocol rules that say that one validator makes less profit than another. And if we want to keep that rule, then fossil is necessary because then load to block builders can

contribute to inclusion list and thereby uphold the censorship resistance. We could however also get rid of this rule and basically say that load to block builders can include a certain number of blobs, but other more sophisticated block builders could maybe include more blobs to the extent that load to block builders wouldn't be able to handle that load while creating a block themselves. So, no more validating. So, if we want to keep the rule that the maximum is set to the lowest hardware requirements, then we need fossil. If we're fine with relaxing that rule, then potentially we don't need fossil for stating. I think yeah, it's very similar I guess but like right now on Ethereum we are in this kind of weird position because we rely on sophisticated builders to build most blocks, but those are like not

great for censorship resistance cuz it's just like two parties. If if they decide to censor transactions or some addresses for some arbitrary reasons, then basically we we don't have censorship resistance or permissionlessness, which is also very important. It means like they can just like censor or like refrain any actors they will want from participating on chain and lending that production, which is very bad. But so to keep like some risk censorship resistance properties, they're not like amazing, right? Because since most blocks are built by these two builders, you basically need to wait until there is one local block builder that gets

elected and proposes a block to include all these transactions that are normally censored, which just like doesn't feel great. Because it means like these users will basically need to wait like 10 12, I don't know, a lot of blocks until their transactions are actually included on chain. So yeah, but so we really want to keep home stakers and local block builders because they are the ones like preserving censorship resistance. At the same time today like even using them is not great because you still have to wait like a a lot of time to have your transaction included if it's censored by the the two builders.

And so with fossil like you move to a world people like participants that are guaranteeing censorship resistance will be I include in these committee members in our case or includers might be different from people building the blocks. And I think it opens up a like a very interesting landscape because now we don't have to rely on the exact same person like participant or validator to both build valuable block and contribute to censorship resistance. And so I think fossil can also be considered as a first step in that important direction and because you have like two very different duties, two very different tasks and we ask the exact same validator nodes to do

both, which is like very much in intention. So yeah. Thank you so much. I think the next question is by Luis. Yeah, so I've kind of joined a few minutes after the hour after the start of this, but um it looks to me this uh is like decentralizing transaction selection in the network as a whole. That's how it kind of looks to me, so that's very good in my opinion. It fights against MEV and censorship. And I definitely like the part of having the attesters doing this job because I think in the future they might they will have the lower hardware requirements than the builders have,

which even first statelessness for stateless agents. Since you will be able to run this with a very lower hardware, and so it makes things very decentralized that way. I guess the main problem or the main challenge here is to define what are the criteria for the transaction selection of these inclusion lists, and whether you go with priority fees or number of blobs, or there's so many variables, which have you guys landed on a set of criteria that you're thinking by enforcing in this? Uh yeah, that's a great question. I think it's twofold. Like the first one is very important. I think about like trying to

separate attesters from people that are building the block or proposing the block. So that's the whole like APS line of research. Julian has worked quite a lot on on this. And then you can like we call it bundling like roles, so they match like duties of the protocol more closely. I wrote a post that I I just shared about like a possible separation, which is like very much open and like would love like more input from people. In this post I guess I make a separation between attesters, includers, which are like I have committee members now, and execution proposals or builders. Because I think like those are like fundamentally different duties, and maybe we should have different roles for

them. And then for the inclusion rule, it's a very good question. We did think quite a bit about it. So, I think we landed on two things. The first one is we want to diversity of rules. Like we don't want one single rule, for example, like order descending on the order of priority fees for all clients because then you can actually play some games and try to route the mempool so you have only your transactions included in the ILs. And then maybe you can also like Yeah, I mean, you can actually play games. But if you have a diversity of rules including one rule that also takes into account the time a transaction has been pending in the mempool. And if like

different clients, for example, like implement different rules, with all of the same flavors, like it's going to be Yeah, mostly around like priority fees and and time pending in the mempool, then it's like very, very hard to game and it makes like the protocol even more robust. It's also like a good way, I think, to take advantage of like the diversity of clients that we have on Ethereum today to to let clients make opinionated choices. We have like a rules in mind, but like we think clients can also like choose the best rules for them as long as no one has like the same exact rule that is ordered by priority fees, we'll be fine.

Okay, so you're kind of also distributing this criteria or letting the the inclusion rules the the ones that build inclusion lists to select to have their own criteria or is this going to be part of the protocol? So, the inclusion rule won't be part of the protocol. First of all, it's very hard to enforce and secondly, it's actually better to not enforce anything. If we allow business committee members to decide by themselves or let the let the client team act upon their behalf of how they include transactions, then we create some robustness in the network. People have different preferences will include in different ways, which means it's harder to attack the system, basically.

Okay. Okay. Thank you. Thank you so much. As I understand this proposal is already proposed for the upgrade after Petra Fusaka. And given Fusaka may or may not include some other EIPs which are under progress, I'm wondering what is the status of compatibility for Fusaka with respect to proposals such as 7702 which is for account abstraction, EPBS, Peer Das. Yeah, great question. Yeah, we had a a bit of an advantage here because of the history of inclusion list. As we mentioned like 7547 was considered for inclusion and then rejected because of incompatibilities.

So we we were like very careful and like solving those before we proposed like a new proposal which because we knew like people were like going to look at it with the same questions which makes sense. So we were very careful and we do we are very confident because we also talked with the extraction teams and we talked a lot with Protus and Terrence. Terrence has been like helping us actively so he's been working on both EPBS and Fusaka so it was very easy for us to to try whether that's compatible as well. I had a clarification as I said and then like yeah, I really don't think there are like incompatibilities with any of the other EIPs. I mean EPBS is like you're going to have to be careful of the timings of things because

you know, you you separate like the execution payload from the consensus block and so you like the whole basically slot times are like being changed and now you also add the creation of ILs that need to be made before the payload is proposed. So so you need to like be careful about the timings but if I remember correctly last time we talked about it with both Protus and and Terrence, there wasn't like any crucial incompatibility at all. Yeah, so no I I I think we are looking good in when it comes to incompatibilities.

That is good to know and I noticed Jihoon also shared a hackmd which we will add as a resources for people who would want to learn more about the compatibility with epps in specific. And yes, I remember the last conversation with Mike. I guess the proposal was not included because of this account abstraction incompatibility. So, it's good to know that this has already been taken care of. I was going through the documents and the details that has been added to the website meet fossil and learned about a term called multi-slot mev. Julian also mentioned that mev boost in general is profitable despite the desire and the efforts made by devs to like control it and have it in at par.

I wonder how fossil will prevent this. Yeah. So, thank you for your question. First, let me say this about fossil and mev and then we can move on to the sub session of multi-slot mev. So, fossil doesn't necessarily prevent mev and this is precisely because we want to unbundle like the mev parts and the inclusion parts. In our view, it's important to do so because otherwise you have like these io boost sort of markets pop up. Um by by reasoning, you could say that if the inclusion list could constrain the amount of mev that's extractable, then building the inclusion list becomes very valuable and people will spin up some sort of markets. So, our design is really there to make like the minimum inclusion guarantee meaning that it's

not so valuable to be this inclusion list committee member and there are 16 meaning that there is no market of sophisticated block producers. Then going on to multi-slot mev, fossil alleviates some of the problems but it doesn't go all the way. Uh and this is again because of this like incompatibility between providing both censorship resistance and like a a solution to mev. What fossil does is it allows any transaction to be included as long as it pays the fees which solves the multi-slot mev to some extent. And multi-slot MEV here is where a person gets more they're able to extract more MEV if it controls two blocks in a row.

Why Fossil alleviates some of the problems is because it allows you to insert your transaction. So, for example, if you need to insert a transaction liquidating your bad debt on some position somewhere, you're able to do so even if the proposer tries to censor you and would extract MEV from you in next block. Why it doesn't solve all of the problems is because of this being adverse selection. And adverse selection is like a an economic property where one person has more information than the other. And so, one example of multi-slot MEV would be extracting arbitrage over two blocks where you don't the block builder doesn't extract arbitrage in the first block and does so in the second block.

And there are some theoretical results that show that this is more possible to do for the block builder than to extract arbitrage in both slots. You could think that Fossil helps here because arbitrageurs could in principle include their transaction in the inclusion list and thereby it force some sort of arbitrage to happen. And while this is the case, it's not incentive compatible for any arbitrageurs to submit their transaction to Fossil because if they submit it, there's still 3 seconds between their transaction being submitted and the block builder being able to do arbitrage. And so, if you're trying to do arbitrage and the price is constantly moving on some external market, you don't want to submit 3 seconds in advance because you have far less information than the block builder who will act later than you.

And so, the adverse selection comes into play here because the builder has more information. So, the builder will let you win if it's bad for you. So, if the price on the external market has moved against you in those three extra seconds, and it will let itself win if it's better for itself to win. So, therefore, Fossil solves some parts of multi-slot MEV which is where transactions don't suffer any adverse selection. Uh but for transactions where there is adverse selection, it's slightly more complicated, but it alleviates the problem to some extent at least. In principle, it makes it better than it is now, but there's still a little bit of work to do.

Very well. Thank you so much for sharing that. Yeah, I understand that there are a lot of research ongoing and maybe address the MEV thing. So, it's good to know that at least in principle it is going to help a little bit more than the present scenario. I have one question which is kind of not related to MEV, but related to what Thomas mentioned earlier about IL equivocation. I noticed that in the security consideration section of the proposal, there are quite a few points mentioned like consensus liveliness and IL equivocation and payload construction. I wonder what would you consider as the biggest either trade-off or something that may require more

research and may prohibit to get this proposal on the next upgrade as is. Well, to be honest, I think the section on security considerations was mostly a way to show that we have thought of and addressed like concerns regarding security. It's more this than like having open questions about like security things that we don't know about. So, I don't think there are like any big like blockers or like problems in terms of security considerations. For the trade-offs, Okay, but well, I mean the very If you take a very narrow view, it's true that FFS adds some tasks to validators both when they have to propose an IL, an

inclusion list, and when they and for attestors, when they have to check that one more condition to make sure like the block is valid according to the inclusion list. So, it adds like a small task to different parties. It also adds a small task to the proposal, right? Because now he needs to make sure his payload actually includes like transactions in the ILs. So, I guess that's like the For me, that's like the only trade-off. I don't see anything else and it's like those tasks are not like heavy or sophisticated tasks. Like literally I am committee member of just monitor the public member pool and include transactions in a list that they send.

It's like it doesn't like require any sort of skill or sophistication, which I think is nice. And yeah, so I would say like maybe the end on the other hand like as we said it might unlock some like big scaling improvements and some kind of better separation between participants and duties within the protocol. I might be biased, but I don't see big trade-offs. I do think it makes it sort of like flips everything on its head when it comes to censorship resistance. Now you need like only basically 15% of the network to be honest for like all transactions, including ones that may be censored by builders, to be included in the next block, which is like a very big improvement. And no, I don't think

you you trade off a lot of things there, honestly. It's good to know that. Yeah, I understand in most of the proposal we find that security consideration is either none or very less information there. So, it's good to know that the research has been done on that part and we are aware of what could be the possible security consideration. Glad to know that it's not a blocker or it's not a potential challenge in implementation and adoption in future. I have a question with respect to some open questions which I found on the website itself. It is about the transaction fee mechanism. I wonder if there is any update or if you would like to share more about what is the best way

to charge fees and distribute these fees for inclusion in the inclusion list. Yeah, I think I'll let Julian answer this one, but we have an ongoing grant that's specifically looking at this and incentive mechanisms to reward IL committee members. It's not easy. Like it's it's tricky and no matter how you approach it, like, you know, it's also very big changes because like changing fees on Ethereum, whether like you change it or you add one fee or you like add like some new issuance, like all of these are like big changes that need like a lot like of considerations and to be very quite careful. But it is being explored and like ideas around like distributing fees

across, for example, committee members that include a transaction seems like a a decent idea. Like it kind of has the properties we want because we want to reward people for including transactions that others might not want to include. So, we are thinking like quite deeply about this and we have an ongoing grant. Yeah, there is also a question before I let Julian like give his take. There's also a question of like whether we want ever to give fees to IL committee members. Because it's notably very hard in general to also like reward smaller participants that are distributed around the world. Like you don't want civil attacks, so you don't want like big like participants with like a lot of stake to

crowd the IL committee set to come in. So, how do you prevent that? That's very hard. Yeah, so you have like a lot of design considerations to take into account. One of the takes I had lately is like if we add some cool features to fossil like privacy, so you can't really know what who proposed like the list of transactions. You know it was actually selected as an IL committee member, but you don't know exactly who proposed what list of transactions, so you can't like link the IL committee members to the set of transactions they had in their ILs. If we can have that and let like the IL committee member be

sort of opt-in maybe then we will probably have like honest participants in the protocol and maybe we wouldn't need like we actually rely on altruistic behavior unknowingly but we don't like need to set up a few mechanisms. That's like a very recent opinionated take and and like it's very much being explored right now. It's like all of these are like future of fossil discussions. They're not like supposed to be included in the current VIP. Yeah, just to add on to that I think that last is also very important so EIP-7805 doesn't include any transaction fee mechanism to make it simpler to implement. Basically like the the smallest possible way that we can provide the essential resistance properties but it's very extendable. So

we are looking into that as to my has done quite a bit of work in this in looking at separate transaction fees for includers and for load proposers. Then as to my mentioned we have an ongoing grants with an awesome research at Nethermind who's looking into creating a transaction fee mechanism for fossil and this is very promising. And then finally there's been work in some sort of transaction fee mechanism for something called also. It's a variant of fossil proposed by Cyrus Vadjala, Vanzan and Kartik Nayak from Zilliqa and they look in some sort of ways to incentivize inclusionist committee members.

To Luis's point earlier this is like incentivizing is very much about how inclusionists are created. So it means that we want the protocol wants to give a certain view of how inclusionist committee members should behave this exact behavior. Usually what this comes down to is that it wants certain participants to do different things. So for example it it may order committee members and assign them certain transactions via something in fossil called the correlated Nash equilibrium in order to still have some different behavior between committee members. So yeah, it's not part of the current proposal but we're definitely looking into it and it fits within the line of Fossils extendibility.

Oh, that's interesting. So, we should be looking forward to get some more supplementary proposals in future to enhance the current Fossils feature. I have another question, which is I'm not sure if it is it should be part of the present proposal, but just curious to understand if there is any update on the IL size. Like inclusion list must likely be bounded in size to prevent excessive bandwidth usage. Do we have any further research or updates to share on this like how the optimal size of the inclusion list can be determined?

Yeah, so we have a fixed size now for the spec and that's been there for a while. It's 8 kilobytes. And so, we put it in kilobytes because what really like Fossil and ILs consume is bandwidth. And that's pretty much it. And so, yeah, if you take like the median transaction size, we get to about 40 transactions per IL. And then like if all the transactions are unique, that's I think 640 transactions that could be like put combined together across like all 16 committee members.

I don't know if there is like too much research to be done on like the exact like optimal size. What we went for is like 16 * 8 kilobytes is basically the size of a blob. So, it's not like an enormous amount of bandwidth all combined together, right? And but I mean, yeah, and then you have I do think you need to consider things like for the future. Like for example, you can both increase the IL size, but I think like since for now the all the combination across like different transactions across ILs is like larger than a block, I don't think like we run into very like issues there.

but you could also like consider is actually increasing the number of IL committee members, right? And that allows you to kind of even have like more chances of getting one honest IL committee member if like most of the network decides to start censoring. So, that's like also something we could do. For now, it seems like 16 would be completely fine and and enough, but like you can definitely play around with these parameters in the future base like if like censorship gets very very crazy or we need to take some more actions towards that.

Just a follow-up here. Do you guys have any metrics in mind that we can keep track of in order to understand the adoption or the success of this proposal? Yeah, so that's a great question. Let me quickly answer and then give the button over to Tim Beiko. I think some easy metrics are just like how many inclusionists are proposed that are non-empty. And you could think of dashboards like the little pig series from Tony where there's maybe a more flavor of of assigning some quality to these inclusion lists. In principle though, if there's only like one person necessary per slot who makes a a proper inclusionist in order to provide censorship resistance.

Uh but I think it's such an important point and that it's important to implement fossil soon because now we're on this magical regime where block builders aren't censoring too much, validators aren't censoring too much. I would say this is very fragile. Like up until now, block builders have been censoring for a long time, and if we introduce fossil now, we have the possibility of of making it a default that all of these validators do actually adopt it and do create inclusionists that are meaningful. And because these block builders aren't censoring, there's no like market instability created here. If we wait and we wait until there is censorship among validators, among builders, then it's far harder to introduce fossil, and I would imagine as all of these metrics that that would be used to measure the adoption would be far worse.

Yeah, I think one key metric to just look at as well is like literally like the inclusion delay for public mempool transactions. And you take all the transactions that are pending in the public mempool and you see how fast they get included. And if post all works like they will all be included in the next block. If they are not, that means like like large proportion of validators are censoring. And so we can look at this and and so like the kind of other metric we can look at is like who is censoring and what proportion of the network is censoring. Which I think will be I mean we will have dashboards and very transparent like metrics to keep track of this because it's it's

basically like the what post all supposed to do. So if I mean public transactions don't don't get included in the next block, that means there is a very large portion of the network that's actually censoring these transactions. Very interesting. So maybe it's something for researchers. This could be a possible wish list for upgrades that generally should be shared by developers. Different kind of dashboards and different kind of metrics tracker for this particular proposal whenever included with the network upgrade. As Julian mentioned that this proposal may need to be implemented as soon as possible. I'm curious to understand where we are on client implementation because I remember

in the last testnet call Paritosh mentioned adding some support with devnets. So where we are on that? Yeah, we are doing quite good. So first of all, yeah, I do want to mention it's been like super nice to see people and how they actually took on the implementation part of post all because I'm not a dev, I'm a researcher. So I've been working with uh devs from the beginning, but like I'm not like the one implementing things in in clients. So it starts, I would say, like the two that spearheaded were were like the default where others. So, the three, actually. So, we have Terrence from Prysm. We have Jehoon that's been helping Terrence a lot on Prysm, but I

have also worked on geth. So, what now we have like a working devnet that's combat that's for Prysm and geth. So, it's great, and there are like a lot of tests going on, and like we are now trying to also um get also to be shown and visible on the raw the explorer. And then you have Jacob who's also another that's worked on Lighthouse and Reth, and I know some efforts are still going on there. Lodestar has been like very active lately. I think they're like very close to have like a a devnet working.

Uh we had some news from Nethermind today that they say they have a prototype, which is super nice. I feel like I'm forgetting some of them. But, uh yeah. Overall, I would say like the like we are like getting more and more devnets like uh ready and live like local devnets, but more and more like combinations between execution and consensus layer clients as well. And it's been super nice like I mean, there has been like some really good progress, and it's nice to see because we all know like devs are like quite busy now uh with the Electra that's coming and then already working on on PLS and other things. But like yeah, some of the clients have

Okay, well, Nimbus is is joining as well. So, said Jehoon, so that's really nice. But yeah, overall like it's been kind of really great to see how people on Ethereum just like uh overall care quite a lot about censorship resistance, and like most of the teams I haven't really specifically reached out, and they just like joined the effort and are now like working towards devnet and testing and yeah. Thank you for sharing that. I look forward to follow the updates with the devnets. I'm not sure how many versions of our iterations of this devnet will be there, but excited to see it is coming up.

I see Justin has a question here. Justin, please go ahead. Okay, buckle up for this one. So, you made a very good point that you know, the best time to address censorship is before censorship happens, right? So, fossil in Fusaka or can it wait for Glampsterdam? And which should I advocate for as a developer? I mean, we have opened the PR and it was merged with like fossil being proposed for Fusaka.

We think it should go into Fusaka. Part of the reasoning as well is like because some clients like have already like started work on it and they haven't like really encountered like too much hurdle. It's not like other proposals that are like much harder to implement and like and involve like a lot more work, I think. And it it's not very contentious either. Like I don't I don't think anyone is like advocating against censorship resistance and everyone sort of agrees it needs to be included at like as soon as possible. So, yeah, I would go for for Fusaka.

I don't know whether it can wait or not. Just I mean, proposals and upgrades can always always wait. I just sort of want to avoid Yeah. First, I want to avoid a world where in which like it's not as easy to implement these changes. Like as Julian mostly said, like we don't want to like I don't know. Things can flip very quickly. As we saw like it was in the other way around, but I think like a few months ago, like three four months ago, one of the main builders just like out of the blue stopped censoring. Just like but and we asked why and it was like yeah, we decided just like not to. So it was good in that case cuz like it was like on the good side. But it can like completely flip back and then we can have like the

two builders like censoring some transactions and then we are like back in a very bad place. So like I don't think it's great. And then yeah, the other thing I want to mention cuz I do think it's important like if we go towards like some of the things we talked about like APS where you can actually like separate a tester or proposer with like some of the designs we have worked on. Like we need to have fossil before and we need to know fossil is working. So we need to have fossil in for on mainnet for like a a year like 6 months a year like to to actually be sure like it's actually like fulfilling its purpose which is maintaining and improving the censorship resistance properties of Ethereum. So I

would say I yeah, another like urgency to me at least is like if we want to I don't know shield the testers from timing games and like some other concerns we have and we want to to get to with the APS, we need to have fossil in as soon as possible. It's sad to see sometimes when proposals not get selected for the next upgrade or the nearest upgrade, but it's only so much proposals can be included in one upgrade. I really appreciate all the hard work being done behind the proposing of the proposal, the readiness of the proposal as well as the testing that goes into it. So thank you so much for all the work you guys are doing for the Ethereum ecosystem.

Before we wrap up, we do have a quick rapid fire round. I know uh the answers are going to be fun for our listeners as well as for people who would be watching it later. So if we are ready, uh we can perhaps go ahead with this. The only condition is the answer should be of one word or one sentence and we'll try to do it on a timer. Maybe for 30 seconds each. So, if you are ready, uh let's go ahead and start with Julian. What's the hardest problem in blockchain research right now? I won't be too meme-y, so I'll answer it seriously. I'd say the hardest problem is future of staking.

What the future of staking means what roles which providers of services provide, how they're compensated for it, and how they relate to each other. What's one blockchain use case that hasn't been explored enough? I'd say fossil. What's the biggest security risk for Ethereum today? I would honestly say that that of censorship resistance is very critical here because of things like multi-block MEV that could really pose huge security risk for for example for L2s. Should MEV be minimized, embraced, or something in between?

I largely agree with the Flashbots take here that it should be uh democratized, meaning that it should be maximized where this is necessary, and minimized at the application layer. Is decentralization always worth the trade-offs? It's usually worth the trade-offs. What's the biggest innovation Ethereum has brought to the world? Here I'd like to see uh Mike Neuder's thought from Devcon with the digital property rights. And I guess I'd say censorship resistant digital property rights that are really changing the world. Thank you so much. Very well answered. My next set of questions are for Tim Aus. So, if Ethereum didn't exist, which blockchain would you be working on?

Yeah, I think I will be very meme-y and and Julian ragged a bit because I thought he was going to do the same. But the blockchain was fossil. What's the most overhyped use case for blockchain? No use case is worth hyping without fossil. What's one thing Ethereum needs to improve as soon as possible? Censorship resistance with fossil. One word to describe decentralization? Fossil. Do you think Ethereum will fully solve scalability? Ethereum with fossil, yes. Layer one scaling or layer two scaling, which wins?

Infinite layers all with fossil. Very well done. Thank you so much, Thomas. I don't know. If you wanted, we can redo Julian's. Later on sometimes, but that's all right. Thank you so much for answering all these questions. As we are wrapping up, I would like to give this opportunity to you. If you guys have any for the community, what would you say about the proposal or in general any message for Ethereum community? Yeah, yeah. Actually, that's like a very important one cuz like we have active discussions all the time and it's all public on the Discord mostly. When I say mostly, it's like yeah, all of it, which is nice. Like there was a push at the beginning to make it all public. So, and people like are actually doing it. So, I'm very glad. So, can

just like follow discussions and and progress on the public ETH R&D Discord on the inclusionist channel. It's like basically where all of it is happening right now. Then you can reach out to us either on Twitter, Telegram, like anywhere. Like just feel free. And yeah, I think the more people we yeah, we talk to and we get involved, the better like the design will be and better the implementation will be. So, if you can help in any ways, reach out and we'll be happy to help on all side, I would say. Like even on the research side, I guess. Like it's even like more suited, I guess, for us to work with

people that want to work on like the future of fossil. So, we mentioned privacy. We mentioned transaction fee mechanisms. We also are like going to focus a lot on fossil for blobs. So, all these things like need people and like research efforts. So, if you're interested, reach out. Yeah, thanks a lot for having us and yeah, thanks for all the work you do for Ethereum as well. Just to add on to that, I hope we made some people enthusiastic about Fossil. If you are enthusiastic, like please please let us know. And if there are some questions that you still have, we'd be happy to answer them. And hopefully we can convince you that Fossil is indeed the way to go. Yeah, thank you so much. It was really pleasure to be here and thank you for hosting the session.

And also thanks to everyone for attending, of course. Thank you. That's a wrap. A huge thanks to Thomas and Julian for joining us today and sharing their insights on EIP-7805. Thanks to all participants. Your questions are encouraging and informative. Thanks for tuning in. If you enjoyed this conversation, be sure to like, subscribe, and share this episode with your fellow Ethereum enthusiasts. We'll get you more EIPs and research progress on Peep and E. Until next time, keep purring with the knowledge and prowling through Ethereum with the Ethereum Cat Herders. Have a great rest of the day.