Inclusion List Breakout

Transcript

yeah hey sorry trying to get unmuted um hey everyone thanks for coming happy Friday uh yeah so I guess can kind of just run through these these points Bullet by Bullet the I guess purpose of this meeting is to kind of increase visibility about the current I spec that we're playing with some of the latest like design considerations uh we've been working a ton with uh with photos and teren so like a ton of this work is is based on those discussions and I think we're mostly coming to consensus among ourselves which is great because we had like different views originally and now

I think we reconciled those um yeah so I guess running through this short presentation I'll just kind of highlight the three specs that three spec changes and kind of the the highlevel theme for each of them which I put in these quotes and then the main design considerations that we're still thinking about um just I have the chat open making sure no one's um chatting and then yeah kind of hopefully this will only take maybe 10ish 15 minutes maybe and then the rest of the time we can just go back and forth talk about what makes sense and um yeah kind of brainstorm from there so if that sounds good I'll just launch in definitely feel

free to interrupt at any point um yeah the making sure that's funny okay um right so I guess starting with the spec docs I'll just kind of run through um the specs in this order execution consensus engine um I will say the these are definitely like not the endgame version it's just the point of this document was to kind of scope the whole problem and demonstrate that it's a relatively small change in the grand scheme of things um obviously there is some complexity from the fact that

there's execution consensus and engine overlay like all three of these um you know D are derived from the fact that the consensus stuff has to be verified by the by the execution engine so for that reason it's like not purely simple because it's not contained to one one of the clients but I think across the board the aren't too complex hopefully so yeah I guess starting with the execution specs I'll mainly just focus on this diagram because I think it's the most um kind of intuitive way to think about it and yeah I guess the execution engine or the execution apis part that changes most significantly is block validation

so when a block is being validated by an execution layer client we need to add an additional constraint and an additional check which is that the inclusion list is Satisfied by the block and the payload that that it was accompanied with so I have kind of two slots diagrammed here and the beacon block for each of them the I guess yeah the inclusion list itself is separated into two parts there's the summary and then the transactions the whole point of this summary thing is to not allow for free da for the inclusion list transactions and so the summary just contains a commitment to an address like this just

means um I guess like semantically there is an address zxb there must be a transaction in either slot n or slot n plus one from this address and the actual like one of the preconditions for accepting the beacon block into your view is that the summary that it contains is accompanied with a list of transactions that are signed from the same proposal ER that satisfy the uh inclusion list summary so here we have this like IL transactions object which is kind of completely separate from the beacon block but it's still signed not signed in the same message but signed as a separate message and it has this transaction from zxb

so the a testers for slot n and kind of the network as a whole will accept this block into their view because it has like the two components that are needed to satisfy it um you can think of this very much the same as the 444 blobs the the block won't be accepted until all of the blobs that are committed to in the block body are are in the view of that validator so that's kind of the high level design for for this slot itself and yeah I have a question uh just quickly the I transaction like the little the bluish blob or block yep that's the full transaction that is

valid with respect to the chain uh in clear Tex like there's no hash of it or anything like that right yeah that's the that's the clear transaction itself okay um it has to be valid in the slot and pre-state so like before the slot and execution payload is is simulated and executed this uh transaction has to be valid okay um yeah the nice thing here is that if it's valid in the pre-state it'll be invalid in the post state only if there's a Nots reuse so that's why this whole summary thing just needs to commit to the address um yeah and right thanks pus um it does also need to have enough gas to pay the base fee in slot n plus one even if the base fee increases by the full

12.5% so I guess one of the precondition checks for the transaction is that it has you know that it pays at least that Max Max fee per um per gas and teren said transaction has to be valid for yeah right they both said the exact same thing so great mind think like cool if there's no other questions we'll kind of just progress to slot n and finish up this diagram the block validation for slot n depends on the satisfaction of the previous slots inclusion L summary and here in this case we have the execution payload the transactions has the same transaction that was

specified with the um slot and aisle transactions object and now we can kind of confirm that not only is the full execution payload like all the transactions in it are valid and have signatures blah blah blah but also that the iil summary for the previous slot is satisfied so yeah that's that's kind of the the general flow um there's a lot of different iterations and configurations for how how these objects get gosip and stuff like that but in in general that's kind of the idea um Tim pointed out that you know it's worth mentioning here um if you're building your own block for slot n then it doesn't really make sense

to put transactions in the iil because you could just put those transactions in the block itself so the whole point of ILS is to to have some agency over your block conditioned on you Outsourcing the block production to the Builder so the idea here and and we'll get to this actually this kind of like transitions us nicely into um into the engine API but yeah I guess the idea here is that when um when I'm building a block or when it's my turn to propose if I don't want to build a block I can still build the iil and even though I don't know what is going to be in the payload of my block I can still specify the transactions in the iil without worry about whatever comes next cool um yeah if there's no

questions I will just keep rolling we're already at 910 so I'll try and speed up quickly that was kind of like the main pump to get over I guess from the CL side the the changes are mostly just around like the data structure itself so we kind of Define these new types inclusion of summary entry gosh this scrolling is really laggy sorry about that um the beacon block has this new summary um the payload attributes are going to have this this transaction thing and we'll talk about that when when we get to the engine spec the P2P spec changes slightly um there's kind of a few ways to do this you can gossip the

IL transactions alongside I'm just looking at Tony's thing this depends a bit if I want to push outs I can still okay I'm I'm going to circle back to that and maybe in discussion we can talk through it um right and then in the in the validator spec itself it's just the honest behavior is to construct this inclusion list based on the the view of the men pool so I guess tldr the biggest changes in the consensus spec are probably around the P2P and the networking stuff because it's kind of similar to 4844 where there's the side objects um hopefully with the 4844 kind of experience and development we've gone through already like this is

kind of old hat by this point but Again part of the open questions and design uh discussions will be around this very thing and lastly I'll just talk through the engine API again I'll focus on the oh I'll just respond to Stokes side cars what are we thinking yeah I think it's I'll go through that once we talk about the design decisions and then what is the estimated Max transactions per inclusion list yeah so we'll also talk about this in the design considerations there's kind of two approaches here you could limit the inclusion list based on well obviously you have to Li limit it on gas um you could also limit it on number of transactions I I kind of am of

the idea that just limiting it on gas makes a little bit more sense I think the fact that you have to have a max number of transactions per inclusion list you would just take the amount of gas and divide it by like 21,000 because I don't know I think constraining it both on number of transactions and gas is a little weird like just doing the gas makes more sense but yeah um cool just jumping in here the engine API has basically this new um get inclusion list uh definition this new interface so kind of starting at t equal zero starting at the beginning of the slot this is the view from a proposer who is building a block and they receive the the previous

slot block over the PDP the consensus client verifies it with the new payload State transition function happens and the fork choice is updated um if if the state transition is valid and basically now the um the building process starts for the um proposer so they have this they they do this uh the consensus client sends this work Choice updated thing to the execution layer client this includes the payload attribute if the payload attributes um yeah like there's there's some way that it triggers the the execution

client to start building and um yeah in the get inclusion list V1 kind of asks the consensus client to request to the execution layer client to grab the current set of transactions that it views as belonging to the inclusion list return it to the consensus layer client and then kind of continue the block building um as it goes the get payload is what actually the request from the consensus client to the execution client to like get the the current best block so that happens at t equal 12 and from my impression the the general thing that happens here is that the consensus client is pulling the execution client because there's like blocks being built

this whole time during this whole 12 seconds obviously with the um with the builder spec which is the spec that defines how the proposer talks to the relay there's like an extra pop in here but um for Simplicity I left it out and basically once once it's their turn to produce a block they publish the payload to the PDP oh yeah enrio your hand is up yeah just a question so you see that getting fusion list requires to have a a payload ID like to be bound binded to the to the for Choice updated that you previously called so is is the inclusion list kind

of bounded to the to the block that is being built by the execution layer is just an a a detached engine API that you can p whatever you want yeah great question and um originally and this is actually something Roman helped me think through um originally I was thinking oh it can be pulled along with the payload so it could be part of the get payload response one interesting thing is that really you don't need to pull for the inclusion list construction you only need to call it once right like at the beginning of my slot I should have a deterministic view of the transactions that I want to put in the inclusion list um and so that shouldn't change over the course of the

slot because no new payloads are coming in like nothing has changed from the view of the inclusion list transactions obviously like the payload you're building itself could change um but the inclusion list itself shouldn't because you know a candidate for belonging to the inclusion list is like it could have been included in a previous slot but it wasn't versus any transactions that are coming in during the 12 seconds that you're building haven't had a chance to be included yet so they kind of they in no way qualify they are not supposed to change at the moment you are actually calling that right so you call you can call it once at the beginning of your slot and then you say okay now I'm going to probably have to send this on to the relay like in in the reality

of me boost you'd have to send it onto the relay but you don't have to like continue building it during the 12 seconds and keep updating the relay with your inclusion and they are not bundled with the same get payload V4 because yeah we want to actually have them independently by the local building because we actually want to send over the network for the Builder to to to get it so that's why there is a separated engine API so yeah I yeah exactly I think Roman um is kind of pushed back a little bit on this and was like maybe we should consider putting it in get payload and just calling get payload because get payload I guess gets gets

called repeatedly um I think this is one of the the design AES we have but I think that there are some cases where you maybe don't call it because is this this put it a strong connection between the get payload and the inclusion list that you get it so I I my get feeling at the moment is that it's good to have that detached so you there is also a different timings that you can follow yeah yeah my gut was separation of concerns it just seems better to have a have a different API but because if for some reason your local fails and you still have the chance to go through the the builder at least you have something to send to them

yeah for sure hos yeah definitely agree on detached uh because the timings are really different you call for the Neel immediately and just send everything to the to me boost and uh it might take a longer time to construct actually the block and call get payload U but but on top of this uh default Behavior gets a little tricky if you are going to construct a local payload and you've ordered it in a you you called in a detached way for an inclusion list um the the local e either remembered what was the El that it sent you and doesn't include those

transactions in the local payload uh or uh doesn't send you anyl and uh it puts those transactions in the in the local payload so if you're constructing locally I I kind of disagree with with Tim I think what it has to do the default e should be give you an El and construct the local payload without any of those transactions in it it makes it like for every slot it makes it the same with or without me boost is the same kind of quality can you say that last part again that you don't you don't have different paths if you're calling with Med boost or not because you choose your

block even if you're using me boost you choose your block after you've received the be and the local payload so in order to keep these things symmetric and not treat like a in in a different way whether you're going to build locally or not the easiest implementation is you request an inclusion list at the start of a slot the El gives you an inclusion list you call later to get the payload and the El gives you a payload that did not include any of the transactions that were in the inclusion list that it just gave you so that way you're guaranteed that those inclusion lists are going to be included in the next slot and your current payload does not over uh does not coincide with those transactions otherwise we're wait in

Spates but that's weird because these are uh sensor transaction and your local is not going to include it yeah but but anyways these blocks I mean these transactions are forced to be included anyways so you're guaranteeing inclusion for those transactions which is the thing that matters so you you accept a one slot delay to have this kind of guaranteed mol onchain mol yeah yeah yeah I think I think that's interesting um it it is nice the Symmetry I guess I also don't see a super big problem with having an inclusion list that you satisfy yourself with your own block like it's a little

weird but it's also a little weird to like ensure that those transactions have to wait wait another slot um when you are yourself like wanting to include them so I mean also you could just make the default behavior for if you're building your own block to just sign an empty one an empty inclusion list you know what I like that no because then no because you don't make this Choice until after the thing is that you always have the option of choosing your local payload after you've receive the headers so this is not going to work you're not unless you're sure that you're going to choose only locally and then it makes sense so clients may have a flag that says always

give me an empty inclusion list because I'm I will be build locally but I get I I get your point where if I still want to have the choice if then afterwards I choose the local one it's kind of a waste to have an overlap because you're using an inclus you're you're at least consuming some onchain um transaction that are has been already included by yours so the the next proposal will won't use it so it's kind of a waste of space I think but I guess my point is like if you do end up okay like let's go through

the flow I grabbed all my my headers and I was like comparing them to my locally built block um let's say I do decide to go with my locally built block then the locally built one can have an empty inclusion list even if I was sent this the inclusion list to the relay you know what I mean like I haven't signed over the full header yet so I can still just do the empty inclusion list if I do choose to self build you two different paths to deal with it's going to be much more complicated to build our own block sorry you were both kind of talking at the same

time so yeah well I was just saying that at that time you already sent the inclusion list over the network am I right so well you just sent it to the relay I mean it's not you didn't really well it's a p P2P how how the publishing works is is a P2P Channel you haven't sent it to the relay you haven't sent it to the relay uh mic you only sent so the the the inclusion list summary goes with the with the blog and the really doesn't have this blog you're just getting headers at this time when you send the inclusion list somewhere in your block you've already signed a block well you you sent the summary though

you've sent the summary to the relay but then you cannot send a different block because you signed it already no but if you're calling get header like when you're calling get header to the relay you're not signing anything right you're just asking for the current best block but then when you're calling get header you're not sending any inclusion list but you have to right because the I guess when you call get payload because when you get call Geth header you have to sign over something and if you're signing over a beacon block that has to have a summary in it itself then you would need to have already communicated the summary to the relay you see what I'm saying like the header has to have the summary contained within

it like if if your slot in Block right this so the the beacon block commits to the Isle summary right in which case like that'll be part of the blinded beacon block that the relay gets yep but the relay doesn't have to care about that I for that slot well the relay has to have the summary like as the proposer if I want to use that relay I have to send them my summary so they can build me blocks but this for the next slot so like the the Builder does not need at all the summary yet it only needs it on the Block it will get it on Gossip or

n but yeah I guess I guess we're not um we're not seeing ey to ey here because the the the blinded beacon block has my own summary in it right so when the that constructs the full block that I'm going to sign the blinded version of it has to have the summary there construction goes the other way around you you signed assigned beacon block and on once you do that and you've included a summary then there's no way out of this once you signed this you don't have an option of building locally and having a different block with an empty list so I think what we're all saying is that if you are going to allow for building a local

block without an inclusion list or building MEF boost blocks with an inclusion list in different ways then when you send when you ask for bit for header for for bits then you choose and you choose before you constructed your local uh Beacon your local beacon block you need to choose before this and then decide what sort of a blinded block you're going to do this is not the way that clients do this today today we bu build a full block a full consensus block this is not going to change and we just plug in an execution payload now what you're if you want to have this two different paths we're going to have to build two different Bon blocks compute to different hashes compute to different

things and then decide which one we're going to broadcast yeah I think I think it'll be helpful to run through the um like to kind of go through the actual Builder specs and make sure that all this works but yeah I think we're saying similar things and I think yeah that working through that part of the design is important but maybe yeah maybe we table the discussion for now because um there's kind of other design considerations that that I think we all want to talk about too sound good this Roman with ends up oh yeah Roman sorry Roman uh yeah uh can you go back to the diagram with uh engine calls yeah so uh

I want to actually push back a bit on on uh get inclusion list being a separate method uh because so uh when when sale client forwards Fork Choice updated to to the engine client to the execution client the execution client should build an empty payload and then the inclusion list can actually change based on on the local payload that that the execution client builds so it it just it makes sense for the execution client to return the payload with the updated iil which is based on this on this

payload why uh and how how the iel would be communicated to the relay or to to the builders is with the initial call to with the very first call of get payload to the local execution client because local execution client should return um an empty payload with an optimistic iil meaning like everything that it considers censored yeah interesting so you're just advocating for for a single um get payload like changing the

to get payload to return the iil the first call has an empty block and then subsequent ones have the block and I and the kind of we know that there's no overlap between the I transactions and the block transactions so we don't have this kind of like wasted space exactly yeah I think that's that's pretty interesting yeah I do feel like all of these questions kind of um yeah are best understood in context of of the relay specs too so I think I left that part out of here uh kind of for Simplicity but to continue the discussion I do think it'll make sense to to walk through the Builder specs um cool yeah

pus Roman could you repeat I I didn't I didn't get this so so you're saying we should call get payload right at this start of the slot we're going to get an empty block but an inclusion list and then if we call later we're going to get a different block and with an inclusion list that might be different now and it's not going to have any cusions is that what you're proposing uh yes so how is this different than just calling the first call to get payload is just an inclusion list and the second call to get payload uh gives uh an inclusion list and uh a so no I I see what you mean so this way

we're just going to copy calling twice get payload I think this doesn't break us at least and it doesn't make us because iel should always be based on on the local payload yeah so so this might be though a different a bigger change in that the way I I can't speak for NCL but I can speak for prism and the way we typically would do this is you run some code that is B that is consensus you build build a consensus block and you call at the same time get payload for your local El and the get headers the get headers for the for me boost so you have one chunk that

is consensus and and different plugins that that are the execution Parts if we're going to do this the the way you're suggesting since the summary uh and the El is part of the consensus part of the block now we're going to have to keep two different consensus blocks and this is what worries me that this changes uh it's it's a little bit more invasive but I think it's doable cool yeah clearly um more a a little more ironing out the the relay interaction here is going to be super important um if if no one objects I'll just run through these key design considerations quickly and then we can

kind of open it up for General discussion so first is the this conditional versus unconditional enforcement um the original design the no free lunch design had this condition where the inclusion list transactions didn't need to be enforced if the subsequent block was full um but you know potes and barnab and others pointed out that this this kind of exposes this sort of degenerate Behavior where Builders can avoid including transactions by by topping up the block and filling it um and then there's also this secondary concern which is that a transaction that gets included in an inclusion list doesn't have actual guarantees until it gets included on the on the Chain so there might need to be

multiple proposers that include a transaction in an inclusion list to get it onchain which is kind of this sort of not very strong guarantee so I think I think most of us are on board with the unconditional enforcement the problem that or I guess the the question that it that it opens up is if you do this unconditional forcement thing should the aisle transactions like extend the gas of the next block if it's full should they be a constraint even like with the 30 million limit um you can also imagine this kind of like cumulative list that Tony has written about which is um you carry these transactions forward but then you have these weird gas tracking mechanisms so I guess that's that's kind

of the first set of questions we want to make sure we're all on the same page on second is this top of Block versus anywhere in Block thing um that yeah I guess the high level question here is do inclusion list transactions from slot n get enforced at the top of the slot n plus1 payload I think in general my view of this is that's bad because you're kind of selling the top of block and this is like the most potential block space the most potentially valuable block space um especially in the like classic plot specific me case where let's say you know that there's a nft mint starting at slot n plus1 you can bribe the slot n proposer to include your your mint

transactions in their inclusion list and you know that they'll be enforced at the top of the block which means you get theit the first nfts um for this reason I think that anywhere in Block enforcement is is better and I think we've all kind of started to I mean happy to receive push back here but generally I think anywhere in Block seems um a little kind of less gameable less meable and also it doesn't seem too much harder to enforce in terms of the state transition function um there's a lot of chats going on I'm just I can't keep up so hopefully everyone's take taking care of those um we can talk about those once we open up the floor again and then the next thing is this gossip uh question which is do

we put the inclusion list with the block or not um you could imagine extending the the P2P object type to include both the beacon block and the inclusion list transactions or you could imagine gossiping the beacon block separately from the transactions so this is kind of the exact same question that was originally asked about blobs because blobs could either be gossiped with the block or separate but that same question here um and lastly right okay this is what we were talking about earlier like how do we limit the inclusion list the the number of transactions or the gas um I think in general I prefer just gas limiting and then saying the

max number of transactions is the amount of gas divided by 21,000 the minimum gas transaction um happy to receive push back there this feels kind of like the least important one so um I feel like I'm forgetting one thing here summary oh right right uh the other thing I wanted to bring up is this whole where does the actual summary get included so the there's also a version of this where the slot n inclusion list summary gets included in the slot n plus one beacon block so the um I guess the state transition for slot n plus one now has two conditions the first of which is there's a valid summary that's signed by the previous slots proposer included in your block and the transactions in your

block satisfy the inclusion list summary signed by the previous guy um I think we generally are opposed to this in my mind mostly because it opens up this weird Behavior where the slot end proposer can commit to their inclusion list like very late into their slot so in this version right the slot end proposer has to commit to the inclusion list by the time they publish the beacon block which is I guess by the attestation deadline T equals 4 in the other version I is the slot n proposer could be bribed to give the slot n plus one proposer a very late inclusion list that has a different set of transactions um and different summary I think also it just feels a little bit like uh kind of co-mingling crossing of

concerns as far as as the slot n plus1 proposer I depend on the slot n inclusion list getting signed in broadcast um and like it just feels like slightly less there's just like some some clo smell there that just feels weird um but yeah that's kind of the last thing I wanted to bring up I think we're all kind of happy with this version so it might not even be worth discussing but I just wanted to bring it up as something that was a big point of of design iteration as we were thinking through these things um cool that's all I think I wanted to say I'll go back to the agenda here just so we kind of can remember what we

covered and yeah I think opening up the floor we have 22 minutes left in the call happy to continue the discussion that's happening in the chat kind of overvoice or yeah do whatever Stokes if if you have anything you want to say Poes Terrence Franchesco yeah happy to happy to pass off yeah Terence yeah so one thing I would add is that um with Miss that is that um for sinking this is actually interesting because this is like probably the first time we are um looking at this it's because like when you sink into the head the chance saying

e call blocks by range or block by root you're not going to have this inclusion this from from before because inclusion this only matters for the current slot right this is something something that you have to satisfy for the current slot so you can of have this like it's kind of similar to when you syncing today inp 444 you only need the blobs for uh for the last 18 days but the similar condition is that you only you only need the inclusion this for the current slot so um yeah so there's definitely that ways to implement it right you can say today I only care about inclusion this if today I received the block over gossip I don't care about inclusion this if I receive the block over RPC you can also look at a slot time I think there

are ways to um yeah it it um there's a tradeoff here and yeah we need to implement that in the spec would with the block forever well the interesting thing is the block won't be valid unless the iil is satisfied right so as you go through the state transitions like you can verify each time in the past that the iil was satisfied um I think he's the point Terrence is making is that the current block validity or in in terms of the fork Choice view depends on this isle object existing alongside it so at that point we still need

to kind of check the availability of the for lack of a better term and correct me if I'm wrong Terence but I think that's what he's getting at you could prune after you know that the block was valid but you do need it the first time like in the sinking news case like you would have to get it from your peer yeah exactly you don't really need this like necessarily though like it's not you don't have to Care on once the like once the new block has being built on top of it you really don't care about the fact of whether or not there was an i like already it's been satisfied so it's kind of irrelevant for you as you're sinking like the only one that you really care about at any given time is the one of the head basically so I think you should only you you always

need to keep around the one for the head but you don't really need like in case for example if someone uh start sinking it gets to the Head they need to have that one to know if the head is actually uh good or not like if if it's something that they should care about or not but they wouldn't need for example um the one at death like minus one or something like that y protest so since since I changed my own mind regarding the issue of uh of markets that are opened by El uh I uh I'd rather expand a little bit on that if you don't mind uh please there there are two designs that we considered uh one is to

not put any summary at all in the pon block and just have a side card that has the summary and the transactions that satisfy that summary uh as an inclusion list that is gosep and the Builder for the next block since this messages are signed the only thing that the Builder for next block needs to do is to include one such signed message so this allows uh this actually simpler to validate right because in the beon block you're not even going to have anything about the um so this allows for some something that I think is strong which is the ability for the validator to for the proposer to submit conflicting uh inclusion list actually conflicting

inclusion list like with transactions from different addresses and different nonsense and everything different completely different so it commits to zero information in the Bon block uh what are the tradeoffs here and and now I'm this is what I proposed and and I'm against this now uh I was convinced but but at least I wanted to have a discussion about this so what are the tradeoffs here it seems better the fact that you're not committing any information on the Bon block and you're allowing like conflicting transactions because uh elel I I'm sorry ILS are going to have a separate Market it's it's expected that that there there will be a market for ILS developed uh if we keep them limited by by having not not that much gas that's fine but but it's

suspected rational validators would develop some sort of like SE offchain market for iots uh if I don't commit to any information then this Market will never be trusted if I send you a transaction and you tell me yes here is an iil that that includes assigned iil that includes this transaction then I I I can't trust you because I know that you can't be gossiping another inclusion list with a complet completely different transaction and then I don't know of inclusion until the next block uh on the other hand if we go with this design where the proposer is committing to a summary with a particular address then once I have a receipt from you that you are including your transaction in this uh in this Blog then I know for certain

that this my transaction will be included in the next block because I am the one that holding that address there's no other I can make sure that no other transaction satisfies that summary so this seems like it's going to make trustless a market that should be uh trusted before uh so this this empowers proposers to actually have a secondary market for inclusion list on the other hand the problem is and this is what uh what Mike emphasized that if we go the other way around and we don't commit like at all like this then the proposer can actually send an inclusion assigned inclusion list after the fact and negotiate with the next uh proposer next Builder and and that that I think is even more

dangerous just for the like sake of argument I guess that it doesn't really matter but I don't quite understand this point about you can negotiate with the next Builder because if you send it later then no one would have voted for your block so the next Builder can just reor your block like what advantage are you getting from so the thing is no you you can send several but the thing is that I can I can I can negotiate with the next Builder to oh here's an inclusion list that is more beneficial to you just include this here's a different one include this one since there wasn't any commitment yeah I guess only thing to add here um

is that the freed da problem isn't solved by having the proposer allowed to sign multiple different summaries the 3da problem is the fact that multiple different versions of the transactions can satisfy the same signed summary so parents justst talking about how you could um or sorry Franchesco was talking about how you could U make signing multiple inclusion lists flashable the version we have here where you commit to the inclusion list in your own block kind of does make that happen through the protocol because if you sign multiple summaries that means you signed conflicting Beacon blocks and that's like the equivocation in itself so yeah I like I like this version for

Simplicity and it still solves the free da problem um right so thank thanks for the historical context there put us it's great to kind of shed light on on the decision we made any other questions um anything the execution teams want to call out you know Roman or Matt um what is the

limit maybe I I missed it now the gas limit right um I think we have it set to 2 million 48,000 gas in the spec or maybe we just I'm trying to remember if we hardcoded a number in there or not um right I mean it's kind of the the question of the hour I will say I do think there is this version of the unconditional inclusion list that doesn't have a gas limit which is you kind of do this cumulative thing like you know like you proposed Tony um and you can kind of keep with you a set of transactions that have been included in

an inclusion list but haven't um haven't been included in a block yet because those blocks have been full the example let's let's just take a a three slot n n plus1 n plus2 view of this um let's say slot n plus one is full flot n set some transactions in this unconditional inclusion list and by the time you get to n plus2 there's gas remaining in the block now at n plus2 those transactions have to be included even though they were only included in the slot and inclusion list this has the nice benefit of not allowing not forcing us to choose a gas line limit um and you still get this unconditional property the only slightly annoying thing here is

that you have to track the gas for each of those transactions right so in that in the case we just took let's say that the the transaction that was included in a slot n payload doesn't have enough um gas to be included at n plus one like or at n plus two rather because we only do the check for n plus one then you have to do this like pruning thing for the inclusion L transactions so that's the only downside I do like the fact that default is you can just as the client include all of the block all of the transactions you see in in your view this is obviously like slightly less data efficient because now your inclusion list is like as big as the

block itself but it makes it takes out this like default question and it also still preserves this unconditional property at the at the expense of some complexity um sorry hopefully that makes sense it was a little rambling enrio oh hand was up and then went down oh Sor I see a lot of chats coming I was expected to unmute but I put hand down so my question was uh still around limits so we're talking about gas limit here but so if we see this as a similar a side carard to to the beacon block the I Al

transaction we don't have a direct limit on the size of the object itself I'm thinking do we does makes sense to have an hard cap on the on the size together with the gas limits to have the constraint be size on the on the side car yeah I mean I guess it kind of does like setting a gas it does also constrain the size we currently have blocks with 15 30 million gas and you could still potentially have one megabyte of blocks am I right here so it

means that you could construct big transaction that pays relatively low gas and still have yeah it's just a big thing that G usage is is bigger but since this this is now a side carard of Bon block then we have these networking things that we have to care about and I think like having a limit a stricter limit on on the side of the of the of the object could be wise yeah I guess this in my mind falls into the bucket of like um engineering

considerations that are going to be super important um but that I don't feel equipped to answer um but yeah I I totally agree that like considering the data hit or just the bandwidth implications of the size of the iil it does feel very important putes my connection sucks uh so Franchesco um I'm sorry not Fran enrio the one of the concerns um about censoring there there're two two Targets for sensoring that are worrisome uh there there there might be much more but realistically today it's transactions like for particular

contracts uh that are not that large and they are just within the this gas limit that is think that we're thinking now and those are the transaction that are being regularly censored uh there's other censoring that that is worrisome for rollups which is censoring the batch poster uh this could be very profitable and sensoring the back poster would be exactly the kind of transactions that you're thinking of which are transactions that are trying to minimize the amount of gas that they pay and at the same time being as large as possible yeah right it's also we're saying that yeah links to the engineering of of the

of our consensus layer uh so if we still think like this as a as a side car and we start thinking about time being timing time timely the timeliness of this side car compared to the slot so several things start thinking start opening when you have separated things that needs to be gossiped and you have a point where you have to have everything together and you might for what it's worth this is why I prefer to just gossip the inclusion list with the block um obviously like this trade-off is that

like the block Max size is bigger for that specific message but um yeah you think coupling coupling this side car instead of having the cou version yeah yeah exactly one also nice thing that PO has pointed out before um which I hadn't thought about is that you can gossip the inclusion list before oh sorry never mind this is the previous version ignore ignore um right just agree with the sentiment that there would be there would need to be a lot of testing for this um a lot of messages going can't follow all of them but I

think Alex said something like do we feel like this is ready to present to ACD as this could be shipped now is the thing to discuss to rap yeah I was just saying like you know in terms of timeline like how do we feel about this like do we feel like the current design is like well speced enough to like move forward can you run a PO it seems like there are a bunch of like you know implementation details but the high level all seem pretty good right that's my impression um and that was kind of hopefully the point of this

discussion no no no go yeah just going to say I think it's also like the the main things to to figure out are these kind of networking questions um like couple decoupled which calls exactly should uh Eng API make um but like as far as a high level design I mean some parts of it have not changed very like months if not I mean some parts even years so I think at least there's definitely some kind of robust score to the whole thing um so yeah I think if we can like put our heads together and just really like dive into these uh you know this this remaining questions it's pretty close to to being presentable as a as a

full thing hes yeah so I run a poll I'm personally opposed uh but I run a poll within prism and I can now speak for prism uh we believe strongly that this should not be included for Electra if we are going to spec this fork for 2024 uh I don't believe we can test this I don't I I am I'm personally sure that this is is going to leak into 2025 if we spoke if we scope it for 2024 and on the other hand if we scope the fork for 2025 then we're strongly in

favor of including this we would include even different things that are bigger like what does I mean concretely like what does 2025 versus 24 2024 mean like there was an agreement mon on ACD on on and and ACDC and acde that the current Fork should be small enough as to not affect the next Fork uh aiming to ship veral by 2025 this was sort of like what seemed to me like a broad consensus that we would want this Fork to be small and small enough meaning we would scope it for this year

uh I it seems to me that it's impossible to scope this change for this year because we will not be testing these things in three four months five months as people are say so nice point in the chat that like oh were you about to say something yeah yeah I guess I I was G to ask both is like how long do say that we agreed that you know all the client teams put like one or two Engineers on this tomorrow like is you I guess is your view that just like we have so many other things to do that we can't like prioritize this or is it more that um this is like so early that it's going to need you know a year year of prototyping in refinement before it's even worthwhile to like have

every client team uh working on it I think we haven't shipped a on the seal side we haven't ever shipped more than a fork a year uh we're starting already this without even scoping this Fork I hardly see this Fork happening this year if it has any any non-trivial change like withdrawals itself was very trivial and it took over a year yeah I'm being realistic as to how long it takes for us to start testing on devet changes and this is a non trial change this is not it's more about okay so but it's more about the client team's ability or um like speed of implementing it than it is about the Readiness of the

spec right I guess those are I believe this spec is completely is is completely specified in in as as Franchesco said I completely agree Franchesco like I think the core features of this spec is specified and we only are worried about like Minor Details which we're going to gather numbers when we're actually testing them got it um because yeah that was my comment in the chat is like you know if you were to like if we think this is important but we're not sure whether or not they can make it in the next Fork without delaying it just like Speck it as the fork after and then you know if like worst case it still ships later than expected which is sort of

what you're you're you're saying now but then if this actually is simpler to implement than um or we are like quicker than we'd expect you know can you bring it in to Electra or potentially just have it you know if it's too complicated to merge the actual code bases but we feel like this is ready it's like can you just have the fork activate you know like one Epoch or like at you know one epoch after like 8,092 7,92 or something EPO after um this way like like you can still ship the fork basically like you can still ship the fork just repeat what I just said I I think with it never happened that we ship two forks in a year and

also somehow it seems dis you muted yourself or someone according to our belief that this Fork was being scoped for a particular year if we're going to change this year then we would have chosen a different set of eips and we would have prioritized a different set of things cool I I think we're not going to come to conclusion on this um in this call obviously there's a lot of other c teams that that we would love to hear

from too um we're at time we're one minute over so I think yeah I think it's good to wrap um I'm happy to continue the discussion in in kind of chats I generally don't use telegram so if there's a channel there or sorry I don't use Discord if there's a channel there you know I guess I can start but I'm also happy we have the inclusion list chat um on telegram that if you want to be added to definitely hit me up um I think everyone here has my contact so cool yeah thanks everyone happy Friday and we'll see you next week thanks mik bye thanks bye