Fork-Choice enforced Inclusion Lists (FOCIL) by Thomas Thiery | Devcon SEA

[Music] hello everyone um today I'm presenting fossil which is our inclusionist design that we're proposing to be implemented into itan Pro schol via Erp 7805 so you may have expected tomma here uh who is the lead on the fossil projects but unfortunately he couldn't make it so I'm Jillian I'm one of his teammates at the robust incenters group at the etherum foundation and and I'll presenting be presenting our joint work with to as the lead Franchesco me barnab Bay Terren who is here as well Jacob and Jun so first of all I'll give a bit of a high level introduction to what are inclusion lists and what are we actually trying to achieve here so the inclusionist design philosophy is that ethereum has access to centralized agents and decentralized agents and we want the decentralized agents to have some inputs into centralized blood construction so inclusion list really Leverage The decentralization in the validator set that we've gten from proposer Builder separation and it's the first design of its kind uh to do so uh and having inclusion list is necessary to obtain uh the core property of ethereum which is to provide CH neutrality CH neutrality we Define here as any valid and pending transaction that pays the pervading base fee is included within the block unless there's no space anymore so the basic idea of inclusion list is that there are some lists of transactions that constrains how a block is created and usually you would say that this list of transactions must be included in the Block in some way fosil doesn't change this basic idea it's more about who creates the list and how is the list enforced so what is fosil fosil is forth Choice enforced inclusion list so the four Choice enforced part says something about how it's enforced uh and F allows multiple validators to provide inputs into block construction achieving this core property of uh increasing the credible neutrality so here you can think about censorship resistance whether this is for transactions that are being censored because of regulatory reasons for economic reasons or by chance uh as happens today and then there are some other design goals which is robustness of the system we want fossil to be used and we want it to be only used to provide these um this increase incedible neutrality and uh another design goal is extendability so we want fil to be very future compatible um yet we need inclusionist today since block struction is so centralized so fil is a recurring architecture that we see in multiple designs that we're considering for other um use cases like pias or other economic benefits so now I'll go over on a more specific level of how foso actually works and how these inclusion list are created distributed and enforced and later we'll do a bit of a recap again so I said that F allows multiple validators to provide some inputs into block Construction in this EIP specifically we're saying that There are 16 validators that are randomly selected every slot to become inclusion list committee members uh and what these committee members do is they each propose uh a single inclusion list by themselves and these are then later aggregated into one complete one so committee members they observe the mol and see transactions in whatever way that they see them and they construct their local inclusion list which is a list of transactions that they sign over uh which is then distributed and each inclusion list is at most 8 kilobytes which should be around 20 transactions on average uh so 20 * 16 gives you 320 average transactions over all of the fossil inclusion lists uh and a block on average has about 200 transactions so we allow uh fossil to be used as like a block template all transactions in principle could be included via foso um with some extra overlap because these agents might the inclusion of committee members might not be coordinated agents so they may choose similar transactions um so there needs to be some overlap so now that these agents make their own inclusion list these inclusion List have to be created and they need to go to the proposer who needs to include them and the testers who enforce them via the fork choice so first we'll look at how these inclusion lists are distributed to the proposer each I Committee Member distributes their uh inclusion list over the global topic this is the the peer-to-peer part of the network where all participant listen to uh ATT testers who enforce the inclusion list which we'll see in a bit uh freeze their view of the available loal inclusion list at second n so what they do is all inclusion list that they had seen before second n uh they will enforce and inclusion list that come in later uh they do not enforce but they still propagate them to the to the block producer and this is essential because this time reference is there to prevent split view attacks a split view attack is when an inclusion list Committee Member is trying to split the view of the block producer and the attester so the person who has to act on it and those who has to enforce it you could imag that if the testers think that there are more inclusion lists than the proposer then the proposer can't adhere to the rules of the inclusion list because simply doesn't know what's available so we give the block producer three more seconds to act on it uh to prevent the split view so if the block producer doesn't have uh inclusion list at second 9 the attestor can still propagate it to the block producer the block also doesn't have to be entirely rebuilt inclusionist transactions can be appended to the block uh meaning that it can be fairly done fairly quickly so then on to enforcement so I've hinted at this already a bit and it's in the name of course enforced via the fork Choice um the testers enforce whether the proposer did indeed adhere to the inclusion list conditions that were specified so uh the testers only vote for the block if the inclusion lists were indeed adhered and how it works specifically is the testers have been listening to the global topic where the inclusionist have been propagated and they freeze their View at second n of the inclusionist that they're going to enforce first uh and they take the union of all transactions that they had seen in these inclusion lists and check whether any of these transactions was not included in the execution payload that that they received so they checked whether a transaction from the inclusion list was not in the block if this is the case they check if the block is full or not so if the block is full then obviously you can't include the transactions anymore so um if if the tester is happy so the block um contains all the transactions or the block is full and then the attester vote for the block if the tester is unhappy so the inclusionist U has more transactions and the the the execution payload misses a view then the test does not vote for the block so the the property that we're getting at here is if the block producer does not adhere to the inclusion list its block will not become canonical because in testers enforce it so this is the full fil mechanism we have 16 validators randomly chosen that make inclusion list they propagate them the block producer receives them it includes all transactions in its block and the testers uh then enforced that the block producer did in fact do this so the core property that we're trying to get at here is the censorship resistance property uh and the idea is that if there's only one honest inclusionist Committee Member in the committee it can include the transactions that are most likely to be censored by the blood producer uh and include them uh in its inclusion list meaning that the blood producer has to include them in the block if we have a network observation that there is a conservative estimate of 6% of solo stakers then there's a 63% chance that in this single slot there's at least one inclusionist Committee Member who's a solo Staker but again inclusion lists are not only about regulatory censorship they're very much about economic censorship there's been some observations of Builders strategically underfilling their blocks perhaps because they want them to be lighter uh in terms of the the bandwidth that they consume uh or maybe perhaps because they play some games or they simply haven't seen some transactions so inclusion lists are here for all of those sorts of transactions the idea is that we're boosting the signal that solar stakers provide uh while not relying on economic incentives here because they complicate the mechanism and it adds a lot of protocol complexity so now I'll go on to show how fossils designed to be as robust as possible and robustness here refers to robustness against consensus types of attacks like the um split view attack and equivocation and it also refers to execution layer types of attacks so people using fossil for other reason forens of resistance but for example as a vehicle to extract maximum distractable value me so first the consensus layer attacks um we've talked a little bit about the split view but there in fact there are two split view attacks to consider first of all um there's the split view that inclusionist committee members ensure that the block producer would have a worse view of the available inclusion list than the testers and this is bad because then the block producer can't produce a block that becomes chical so we prevent this by giving the block producer three extra seconds u in which the testers have a really Frozen their view then secondly there's a split view attack uh that's related to I equivocation so you could imagine a Committee Member signing two inclusion lists and sending one to the block producer and one to the tester set if it would have control over that um and how we prevent any bad things from happening here is we say it as if um there are two inclusion list so if an attestor blood producer receives two inclusion lists from the same Committee Member then they do not impact how the block is constrained at all um so what this means is that if a block producer receives two inclusion lists doesn't know how to act now it knows okay I I do not have to adhere to this this is a weird case it should not be happening and the testers also know this so they don't enforce inclusionist where there are two a testers have 4 seconds after the block is produced to receive these inclusion list so here again we uh prevent the split view not enforcing any inclusionist when two are sent uh is a deliberate decision because um this should happen either if the node is configured incorrectly or if it's an attack and um realistically it has the same impacts as someone sending no inclusion list so if you said no inclusion list no inclusion is enforced if you send two also no is enforced and the other inclusion list from the other committee members are still enforced of course so then there's transaction inv validation so transactions in the inclusion list may be invalid at the time that the inclusionist Committee Member propagated them towards that the block producer must include them there there are two reasons for this potentially the inclusionist Committee Member doesn't know the right head of the chain so it's building on some other head uh and the second reason is that the block producer could include transactions before the transactions from the inclusion list so the the inclusive Committee Member cannot possibly know what the block producer is going to do since it acts before so transactions could be invalid to prevent free data availability which is a a problem that arose with a previous uh inclusionist EIP uh a tester's only check where a transaction could have been validly appended to the execution payload so if a transaction is invalid then clearly it cannot be validly appended similar to how if a block is full a transaction cannot be validly appended because it because it would raise the gas limit over the maximum uh and inclusion lists are never written on chain um it's only the execution payload that's written on change so this prevents free date availability as well then if there can be invalid transactions in the inclusion list this may lead to some games uh that you might think of so it could be that uh someone knows that it will make the block at second 12 uh and it tries to flood the mle with transactions that it will invalidate in its block later on meaning that um it floods uh the inclusion list of transactions that will be invalidated therefore not really constraining its block uh too much so first of all this is a difficult attack to pull off in practice because usually the MEF boost Builders only know that they're the Builder close to the 12C line or maybe even past that uh but we have like a defense and debt strategy here uh to prevent this so how we do it is inclusion list proposers are free to choose whatever inclusion rule that they like so they're free to construct their inclusion list however they like and clients can be um an agent for them so potentially one client prefers uh the way of creating inclusionist By Priority fee others may prefer to make incl inclusion list based on how long transactions have been pending in the mle and others might use some sort of puristic that they think is most valuable to create inclusion list if people create inclusionist in various different ways it's more difficult to attack them so if for example one client incluses inclusionist mechanism that says I want to make my list based on how long transactions have been in a mempo uh just ordered youd need to flood the mempo long before that's uh long before your slot making it potentially a lot harder uh to know that you can invalidate them so this is really a defense and debt strategy uh it's unlikely that this will happen the G is quite limited uh but even then uh we're trying to prevent it so then um you could think of commitment ATT taxs so an inclusion list is some way to constrain the value that a block producer could um extract so inclusion list Committee Member could say um if you pay me then I include something in this block or if you don't pay me or sorry if you pay me then I exclude something from my inclusion list so the latter is an extortion attack the first is an inclusion attack and this is mainly a worry uh if there's only one uh Committee Member we try to prevent this by having multiple Comm committee members making it uh economically less less important uh and second most less likely so then uh taking commitments attached to the extreme you could think of fossil as uh a vehicle for meev but we try to prove that this is incorrect uh we do this via a concept that we call unability so the inclusion list cannot be crowded out by other users uh than simply providing this censorship resistance property so we don't want inclusionist proposers to sell their rights to make Invision list we argue that fossil is robust against these sorts of Mev boost like markets that you might think uh arise if um if if you would believe that um it's valuable to sell inclusionist proposing rates we say that fossil is not very useful for this because there are no ordering guarantees inclusionist doesn't tell you where in the block your transaction lands there is no private order flow possible because any inclusion list is publicly propagated over the network in order for it to be enforced there are multiple inclusionist proposal which prevents some of the inclusion and extortion attacks that we talked about briefly uh and the inclusionist created 3 seconds before the block producer acts so the block producer has more information about the external states of the world than those who make the inclusionist have and this means that no individual inclusionist proposer has the right to include order or exclude transactions which is like the canonical definition of me so fosil is specifically designed to be as robust as possible against meev markets for inclusionist proposing rats second is extendability and here uh we argue that foso is a great step in the right direction we feel that it's very necessary to have some form of inclusionist today since there are only two Builders uh and we see that fos of recurring architecture in different uh products that we're trying that I guess not products uh erps that we're in imagining um and so here I'll present two possible extensions you shouldn't take these as part of fossil because they're not in the Erp but there are things that could be built on fosil without changing the underlying architecture so first is making some transaction fee mechanism to incentivize sensorship resistance so the design philosophy behind fossil is to boost the value or boost the signal of those that already provide sensor resistance to ethereum uh in a way that's doesn't cost them anything but it doesn't gain them anything either potentially for some use cases you want these inclusionist committee members to actually gain something uh from from providing this resistance service and what you could think here is an Erp 1459 like mechanism where the priority fees are given to those who create the inclusion list um potentially subject to how much they contributed to individual transactions being included the general idea is to make it a lot more expensive to sensor transactions uh you could do this via this transaction fee mechanism and you could also change the way that tips work in ethereum potentially by having separate tips for uh inclusion list inclusion and block inclusion or having a conditional uh tip that was popularized by Elijah Fox Mann and mpai and then secondly we're looking at fossil for blobes so Erp 7805 currently doesn't support blobes although it could with some small changes potentially but then uh but taking it a step further and looking at full data availability sampling um enforcing inclusion is becomes a bit more difficult because those who enforce it need to know that all of the data was indeed available they need to know that the block could have included all of these transactions so then we could extend fil with some extra condition where the testers have a good view of whether the data is available or not to again prevent split view types of attach the important thing here is that this fully builds upon the architecture that we're proposing within fosil um so fosil is very future compatible fil architecture is basis for many more extensions these are just two examples but you could go crazy with this and um I think it's a very interesting design space so it's a summarize also allows 16 validators to contribute to blood construction which is currently very centralized and mostly in the hands of two Builders the main goal is to increase the censal resistance of ethereum right now and the cyles are to provide robustness against consensus layer and execution layer attacks consensus layer attacks again being the equivocation split view execution layer attacks being being crowded out by me types of markets and the second side goal would be to be very extendable so we want fossil to be future compat ible and unlock a new field for ethereum that we cannot imagine now so the next steps are Erp 7805 is available if you're interested please scan the QR code uh and v through it we're trying to move towards implementation in clients and my call to action to you is that please reach out to us if you have any questions about fil if you think that fosil could be used as a vehicle for me so this is the thing that we're explicitly designing against uh and if you think that you'd like to use fossil uh on your layer to to provide censorship resistance there so that was it thank you very much uh and I'll be open to any [Music] questions thank you and uh also big apologies for um calling out the wrong name um so this is Julian marah from robot incentive group at the EF um so let's get into the Q&A um julan please U maybe oh yeah yeah um so the first question the I committee introduces for the first time a duty for validators that require mempo access are there any concerns with this yeah that's an interesting question so um currently in ethereum validators need to have access to the menol anyway because sometimes they um in principle from the etherum protocol they they are asked to construct blocks most of them Outsource this vmf boost but currently validators have access to the mle uh so now we're introducing uh some way that this is necessary I guess even if there's a very strict reason why you don't want to have access you could also just propose an empty inclusion list and then again we rely on that there's at least one person willing to make an inclusion list um I think this shouldn't be a problem validators if they want they can run a version of the mle that's well suited for them um yeah so I I don't think this should be a big problem next question uh how does the validator access the mempo and how does it select transactions yeah so um I'm not sure if this is like more of a a Dev side of question or rearch question uh coming from the research side I'll answer it as a as a research question I guess so how does it select transactions um this could be to maximize some some objective function that they have for themselves uh maybe they want to include transactions because they they think that regulatory censorship is very bad or maybe they want to include transactions because they don't want uh people to mess with how their favorite application works or whatever for so for economic reasons um in principle inclusionist committee members are free to construct their inclusionist as they like um and since there are no rewards for this um there's no reason why you wouldn't for example order and buy priority fee um on the de side um potentially like catches later teren is here as well um yeah I think that will be better to do later right uh next question will there be PBS style Marketplace for uh forming for inclusion lists it seems to be just another block space consumption design from that perspective yeah um so we're very aware of this and fossil is designed explicitly to not uh Foster such a such a market for outsourcing some key observations here are that meev boost relies on economies of skill there are high barriers of Entry because of um because of private order flow and the economies of skill come because it's very difficult to construct uh a very valuable block uh and this makes that it's individually rational to Outsource my block construction to some M boost uh builder for FAL inclusion list this isn't the case so uh reting inclusion list is very easy because you just select transactions based on some heris that you like uh they're not that big I mean you could include 12 20 average size transactions um and you don't have any ordering guarantees over this so you can't run sophisticated algorithms to say what uh value can I extract from these um from these transactions you have to commit 3 seconds before the block producer so doing any Arbitrage is is basically impossible if it were not already impossible because of the ordering there's no private order because any inclusion list is propagated publicly otherwise it's not enforced uh so this makes it that it's not individually rational to oursource block um inclusionist um production I guess the question here is that we're very convinced of this and we've talked to builders and Searchers and no one has come up with a way to use inclusion list as a vehicle for me if you do find a way uh I'd be very interested uh in trying to contradict that is this proposal compatible with 4 second block times um so the person who asked this expression probably thought no but I think is actually very compatible um the interesting thing about inclusion list is that the the timeline um doesn't necessarily depend on uh the block construction timeline so when inclusion lists are created and propagated which is the largest part of the timeline uh can be completely parallel to block construction inclusionists don't have to depend on the head of the chain uh they could be made for example uh in principle they could be made whenever early let's say three blocks early or something and then it could still constrain the current block and since this timeline is very very easy as in the block producer must receive them for which it could have a very long time and the enforcement is done by the testers it doesn't add like additional time uh delays that being said if you make them very far in advance the inclusionist is more likely to hold invalid transactions which may not contribute much to sens resistance next question how about the integration of fossil with e PBS and single slot finality they should be aligned coordinately so we're proposing fil separately from epbs or single Sal finality I think this is important because I don't see an inherent tension between these as I explained in the previous answer the fossil timeline can be completely parallel from other timelines um so in my view it's it's very compatible with both and they don't have to be uh implemented at the same time they're proposed as different uh proposals does it mean transactions from inclusion list will always be at the bottom of the block it mean so first of all transactions aren't necessarily from inclusion list transactions in the men pool are seen by inclusion list and then included in the block but the block doesn't contain a set a section that's like this is for inclusion list um so some transactions that uh you I guess you could just see them as transactions in the mle mle transactions currently usually are not put on the top of block because this is a very valuable spot maybe someone can extract some me from being at the bottom of the block so I'd expect them somewhere to be in the middle there are no ordering uh or properties of like where and block it should be should equ equivocating committee members be slashed so in our design we don't slash committee members we do this because there is no reward scheme we want to incentivize as much participation as possible so slashing could be CS because you have a bad not setup and you accidentally signed something twice you don't want to do this uh you want to prevent it um but if it happens we don't want to penalize for it slashing in uh equivocating on your attestations is important for finality to give some economic weights behind the transactions that land on chain slashing for double signing a block already uh is different it it's not related to finality it's it's uh but it does cause a bit more stress on the on the Chain SL um equiv with your inclusionist doesn't cause anything it just means that your inclusionist isn't enforced it's equivalent to sending no inclusionist so that's why we don't slash for it right so unfortunately we have run