Inclusion List Breakout #2

Transcript

[Music] e [Applause]

h okay we are

live cool hey everyone happy Monday um yeah so I have a short well not very short a decent length agenda here oh thanks Terrence that sounds very good um this we don't have to like go necessarily in this direction it's just what I thought kind of were some of the recent discussions so just trying to get them all in one place um but yeah I hopefully this can be like super interactive super free form definitely chime in if if if you want to say anything or you have any um other agenda items you want to add so yes this is inclusion list

breakout Rune number two um I guess the the main goal here in my mind is to kind of continue this um kind of Sprint that that Danny talked about and that we've kind of been scheming on about getting this proof of concept back in place and like starting the implementation seeing what um what the blockers are from from the CV side and then kind of making the go noo decision for inclusion list in Electra over the course of the next week or two um I know that's kind of like a short time frame but that's that's at least my goal um yeah I guess in terms of the spec discussions kind of starting

there I'll copy the um the agenda part from from that comment into the chat oh it doesn't render very well but okay yeah maybe ignore that but I guess um yeah in terms of the actual spec POC I think there's been a little bit of confusion because we've gone like in a lot of circles in terms of the exact details of the design and that makes people think there's a lot of different designs floating around but there's actually like only really four decisions that we kind of are still iterating on um those four decisions are this conditional versus unconditional

top of Block versus anywhere in Block bundling or unbundling and gas limit considerations I think the one that makes sense to talk about maybe first is this bundle versus unbundle because that's what teren and Poes have done um a ton of work on I read pius's doc which is I'll send a link here and Terren put a big you know um comment in the in the PM repo I'll also link that um so yeah I guess uh either Terren or poto do you want to just give like a you know thre minute discussion on on why un bundling makes sense I think I'm I think I'm pretty convinced but before I was basically I guess my

intuition for why bundling made sense in the first place was just like Simplicity like oh you send the block with the inclusion list the validation happens kind of at the P2P level um yeah I think after reading both these things I'm pretty convinced that unbundling makes sense but I think you guys could do a better job of of steal maning that case so maybe Poes do you want to do a few minutes on that and then we can open the floor up to see if anyone has any um any questions sure I'm not sure if I'm muted or not no we can hear you okay good so there there were some arguments so far as I understand the only one that actually gave a concrete

argument towards not bundling was dusting from Nimbus he was very worried about the fact that we would just have another situation like blobs where you would just tide the validity of the object in the case of blobs is blocks the block itself and in this case it would be the inclusion list to the availability of it and this is checked in an asynchronous manner I think in my dog what I just pointed is that well first of all this is not the analog of situation and and in the first spec it actually read and we were thinking in that way that it was that situation but then we realize that it's not needed to be that case you do not TI the validity of the e to the availability of it the

validity of the block to the availability of the E you can just sync the block and the only thing is that you keep track in for choice you can count attestations for the block you can do everything but you keep track in for choice of the status of that elel if of that I if you haven't seen a valid iel you do not vote for that blog and you do not propose you do not consider that block as head that's it so that's a very minor change to for Choice it doesn't tie the the validity of the block and it makes all of the implementation much simpler in particular I mean I made a huge list of arguments as to why it's much actually simpler but the one that is should be be definite is the fact

that the proposer can cause a split view on head simply by sending different iops and making it available to some making it not available to others and Trigger immediate on head trigger an RPC request for blocks and this is the sort of split views that we do not want and this is the reason why we didn't commit to the block the summary so the fact that you don't need to make this extra request and the next proposer Sol for you that split view makes it all for me this is a a rund a very decisive situation you don't allow the proposer to cause a split view to call to get half the network to request a block by RPC but

just the next proposer if he proposed a Blog and it's valid then it means that the ilil was valid there was already available and If it tries to reor the blog it reworks it and that's fine you don't need to request anything anyways so I I'd say that that's the the main argument so just to then to clarify the way that this is fundamentally different is even if you never saw the inclusion list if all the attestations are for that block you could still make it head like if all the like if all the weight is on that block I I do not think so you could you could call it your head but if you're going to attest to that block you should not but you but okay other blocks get

built on it and it can become call that's correct the other blog that comes on shows on it if you have seen the I for these other blogs that block is is your head you don't need to change anything in in your implementation right see and it's also it's also worth saying that that um sorry to interrupt in um the only one thing I wanted to add there is that also the next block um would have to have like a signature from the previous proposer over a summary so there will still be like the check that the summary is signed by the previous proposer and that like the the validity of slot n plus1 block does depend on that existing it's just that um you don't necessarily have to have seen the

list of transactions that was gossiped like alongside the block is that right pus it's correct we could in principle allow so the the the one attack that this design allows for is that your a malicious proposer you are in t you're colluding with the next proposer you send your your blog and you don't make your inclusion list available at all you just only send it to the next Builder the next Builder includes your inclusion list and no one has seen it no one has seen your previous uh your previous inclusion list the next Builder builds his blog n plus one on top of N and sends it at 11 seconds into the block

into the slot so what happens is that currently we will not reor that block because uh if we were to reor that block we would base our block into a block that we do not have the inclusion list and we do not make reorgs that are deeper than one than slot one so we might need to revisit that rule and we may want to allow for longer reorgs or another option would be to recover the inclusion list from the Block it's up yep because the block will include the summary it would include uh it would include the the some transactions but the problem is that to make the inclusion list available and we specify it then we this RPC point would

depend on previous blocks on the L and and this we we decided that this is just Overkill yep makes a lot of sense and Rico I think you were yeah it was actual thing I was trying to add and pus immediately yeah Market it out because we discussed last Friday and it was an edge case that we were talking about and yeah this one the only thing that is a little bit weird currently cool yeah I guess the one last question I have here um and then we can move on to the other parts of the discussion is the relationship between committing to the ilil and bundling um so if we commit to the ilil in the

beacon block do we have to bundle and if we don't and kind of the other side of that same coin is if we don't commit to the is and the beacon block does it make more sense not to bundle because then you can gossip them you could gossip the inclusion list ahead of time as a proposer especially I'm kind of especially thinking about the me boost case where a proposer wants to build an I but they're not going to be able to build the entire block yet um yeah I guess it does that does that question make sense like if if we commit to it do we have to bundle them together in the same gossip object and if we don't commit to it in the beacon block does it make more sense to unbottle them I guess this is probably a question directed at

you again PES but don't don't we need to have the property of being able to send multiple yells that's fine that's fine enrio because you can commit to a summary but not the transactions that's what uh that's what Mike is doing uh all right so so okay yeah yeah you just need to have a summary that can have multiple lists of transactions that sa that satisfy is satisfy it is the solution to the 3da problem yeah I think it's useless I mean the same argument if you commit to the summary uh you can still make the case that you can cause split view you can

make an iil that is valid that has a different summary or and send it to some and make another iil that is not valid or just not available and again cause the same kind of split views I very much like this so that's one thing so if you're going to cause a split view by just committing to the blog then we might as well just gossip everything together bundle everything because my whole argument is that you allow for split views uh by bundling and it's the same with committing it's exactly the same argument you allow for split views and this is dangerous there's many more reasons why not to commit and other one is you make a trust a more or less trustless

assumption on a trustless market for inclusion inclusion list because if I send you my transaction with one address and I know that there's no other transaction with that know from that address and you give me the signed summary then I know for a fact that you cannot put that another transaction that invalidate mine so this allows for trustless markets on inclusion list which I think is are just not good uh so that's another one and there there's a few more reasons but I think those two are the main ones yeah no that that makes ton of sense to me so I guess in the like yeah in the design space the the commit to not commit thing I think we all land on the not commit side and I think I find

this um this unbundle argument pretty compelling um so yeah if there's no other objections to that I'll rewrite the PC spe to unbundle instead of bundle the gossip objects and then you know we can kind of treat that as the as the final decision for what goes into the PC cool see thumbs up um Juan just had a question can't we have an inclusion proof with committed summary in the iil um so I guess you're saying that there's a there's like a Merkel proof that the transactions are included in the in the block itself is that what

you're saying I'm saying that like you basically a commit to the summary in the block and then you can similar to what we do in blobs we basically have a proof that whatever uh uh whatever aisle you're gossiping uh separately in an unb unbundled manner that is uh that is what is has been committed in the Block in some sense I actually I don't now that I've said it out loud I don't see how that would be useful need to think a little bit more about it yeah

um so one thing that we're still doing even if we're unbundling I just want to make sure you're still required to send the inclusion list to the Builder otherwise you can them right no you mean in the Builder API no then couldn't the proposer easily grief them like you know they they they force them to reveal their me they never reveal the inclusion list and then nobody wrotes for that block and now they've made no no no no wa wait wait wait so I am the proposer of N and I've never sent an inclusion list to the Builder what is The Grieving Factor here

so you you've sent an inclusion list summary right that that you have to do right no so that what is Gossip is a full inclusion list there's no reason to to to comit to the block forget about the block itself the Bon block doesn't have any any information about the inclusion list you gossip a summary which is signed and a full list of transaction and this goes in the same envelope it's just that the only signed part is the summary okay so the Builder will not consider your block valid and will not even send you a bid if it hasn't seen uh oh well no this is in the I'm thinking on epvs

yeah but for the Builder is irrelevant wait wait now so you're saying that that there's no summary included in the block the correct this is what we're discussing about committing or not committing oh okay I I thought this was or bundling or not bundling but I'm I'm sorry I got the confused with bundling and not bundling yeah so these are two different things you can commit to a blog and then it becomes a validity condition on the inclusion list itself that it's satisfi that it's a list of transactions from that summary or you could just forget about committing to a summary in the blog and then let the next Builder include it and then we only find out the reveal from

when the next Builder proposes his payload and then the bundling or not bundling is different situation which is we have a summary we may have it or not in the blog that's irrelevant the question is do the full list of transactions get gossiped with gossiped with the block or not so these are two independent thing situations okay so let me wrap my hand around the first one so so you you as the proposer want to include an inclusion list so you just when you have your proposal you send your block it's all normal you also send as a separate packet both an inclusion list summary and an inclusion list and then up to the next Builder on whether or not they want to want to include these things what well they need to include

one they need to include uh an inclusion list summary or or include the transactions is that so so the next builder in in during the production of block n you send your block your consensus block knowing information there about any inclusion list you send separately that's what I'm proposing I mean there are different decision but this is one let's just agree on one okay you send separately an envelope that has assigned summary and a list of transactions that satisfy that summary yes that goes separate now during your block nothing is seen of this on chain

right the proposer of the Builder of n plus one includes in his payload the signed summary and a bunch of transactions that satisfy some of the transactions in the summary except some that may have been satisfied in the previous block and if he doesn't the is not valid okay how is it not valid if nothing about the inclusion list is on chain yet if the next because you need to include one valid summary and the transactions in your payload that satisfy that valid summary it's a signed summary you need to include at least one and if the previous like there's nothing on chain yet so the thing I'm having trouble

understanding is that there's no difference to the chain at this point whether the previous the the Builder of block n didn't have an inclusion list at all like never broadcasted one that's correct so the Assumption here is that the validator set is honest and if the block is head it means that it got voted and if it got voted it means that the majority of validators got an inclusion list that is a valid inclusion list a testers only test for blogs where they have seen a valid inclusion list I see uh that okay so it's a softer um I I see okay so it's optimistic uh in the in the it's it's what H what the hell is it called I'm

sorry I'm forgetting the oh Pepsi would call optimistic validity in a sense I think like similar to that idea I think I'm not sure I mean this the votes are on chain the attestations eventually can be made on chain and if you have enough attestations and chain it means that either the validators were dishonest and they were lying or the inclusion list actually was there yeah this is just an analogy I Ed to understand but I think I believe this is how Pepsi Works um optimistic versus pessimistic validity but yeah okay that's that that's interesting idea I I have to think through the

implications cool um yeah I think I it probably makes sense to keep moving I have a question yeah I have a question thinking of blocks and you know while we do uh request by range and sync forward right so we don't actually need to uh get inclusion list till we have basically reached the head of it or you know we think that we are at the head because we don't know what the head is at any given point of time uh unless we have seen the current slot block so what what I'm saying is that U so when we

give these blocks to El and El should be able to validate whether the inclusion list of previous slot was was justified or not so I I think you know we basically so what we what I'm thinking is when we are thinking blocks by range till the end we don't really need to I there is one way the P where one p is saying right you know you keep track in your uh in your folk Choice whether inclusion list is satisfied or not but even then El can basically you know whenever it's uh basically you are you are doing new payload it can tell you

that the parents inclusion list was satisfied or not so I think if we have that then basically it would become super easy you wouldn't need to do we wouldn't need to sync inclusion list till you are at the head and you can just sync blobs blocks and give it to El and El can just tell you whether you know uh the parent block was valid or not totally valid or not and then you can basically for the current block that you have imported for that block you can basically start looking for inclusion list from the gossip or from request response yep I think we all

agree so just will do it oh go ahead Mark just to ens sure I understand and uh so you can in in this design that you're proposing pus you cannot broadcast an inclusion list that's a thing that's okay to do but no you you you may you may not broadcast an inclusion list and if you find the Builder and you off the Bad of I mean your block will not be attested and it might be Reed and but if you're in collusion with the next Builder you can you can just give it to the next Builder the Builder includes it and it makes your block canonical block is vot

no summary no inclusion list not like I mean like if you don't care about what goes in the block you have to find something no you have to send you have to send an empty summary if you want if you want to not include anything you need to send an empty summary because the next builder needs to include something signed by you okay um so that this would imply that you you then have if you're not sending that to the previous Builder or like the Builder of your block if you don't send anything then the Builder of your block doesn't have to include your signed thing they they include they have no inclusion they have no guarantees that

you the block that they just they're going to reveal the transactions and broadcast and they don't want to do that until they have some assurances that their block is going to become canonical and if you just never reveal your inclusion list you can block it from becoming canonical like griefing the Builder that's correct and the re that's correct so what's going to happen is the relay will not reveal anything if they haven't seen already your your inclusion list and in practice we will be at least prison would be broadcasting the inclusion list like 10 seconds before slot okay I have a I have a question regard the with this regard so just to

have a clear picture in my mind so when there is the need of sending multiple uh inclusion list against the same summary so where where is the use case where the the proposer have to do that no no so they never need to do this and actually one of the advantages of not committing the summary to the block is that you don't even need to have like different transactions for the same summary because if you didn't commit your summary to the block then you could have completely different summaries out there you could just send two completely different inclusion list you haven't

even committed to the list of addresses and the inclusion list could be anything so you can sign multiple multiple summary you can sign multiple summaries with multiple transactions that satisfy this there's no slashing condition here and the the problem it's not that you need to that you want to do this the pro the is that you may do this so this doesn't allow anyone to rely on the fact that they have seen such a thing to consider it already on chain and get the free data availability yeah this is the free da protection actually at the end I guess one thing to mention is also

when syncing right so when you sync um your inclusion L you only want to sync one inclusion this and also and also import and regressive only once and then you can drop the other otherwise you will have like a free do B there yeah I think the it makes sense for the honest spec just to be the first one right like just keep the first one and and disregard anything after that cool sweet I think I think it makes sense to keep moving we're at 10:28 just a reminder this call runs until um 11 a.m. this is I'm on Eastern time so 32

minutes left so a few more things to discuss um one thing I just wanted to mention kind of in passing is this relationship to outof protocol stuff so there's been kind of a Resurgence on on considering what we can do out of protocol in the Mev boost um in the Mev boost world to harden up the the properties of the of the software I guess um I have a few reasons why I don't think this is something that we should blck inclusion list in protocol on um I think I think there's potentially interest in doing something out of protocol but um there's kind of a few two main problems that are that I I cite in this document that I just wanted

to bring up quickly the first is that the mechanism that we would be implementing out of protocol is like a kind of in nature very different from the one we would do in protocol it's same slot versus next slot and I kind of outlined in this document um the difference and then the other thing is just the kind of continued Mev boost scope creep so if we build some CR mechanism into Mev boost we kind of increase our dependence on Mev boost and we also increase the amount of software and and stuff that goes into maintaining it um for those two reasons it it just doesn't feel like that that urgent to me like if anything just doing using those engineering resources to do e 7547 in

Electra feels like it makes more sense um yeah I just wanted to bring that up because there's it's been a topic of discussion if there's no questions on that um we can we can move on like client said I feel like whatever we can do outside the protocol should be done outside I agree I think my argument is that like we can't really do anything meaningful outside the protocol um you I mean that's not totally true like if we got people to use the Min bid feature more for example then it might have like a significant impact um but I we're not in the situation where you can like implement it out of protocol and like collect data about the mechanism and then decide if you want to enshrine it or not because the thing we'd be implementing out of

protocol is just like fundamentally different than the thing we would put in protocol um also it doesn't feel like oh goad is there any kind of comparison of what the outer protocol mechanism would be and how comp to the end protocol mechanism yep so there's a doc called censorship uh wait resistance is not futile let me get you the link just um and this kind of runs through the out of protocol stuff in the other link I put in the in the chat this uh the case for Electro do um I have I have links as well but yeah this is kind of the the status of the out of protocol stuff um as I see it so happy the chat

more offline too if um after you read it oh yeah there's also the paths to hardening PBS that's from Franchesco yeah cool I think makes sense to move on to the next section I have is called open questions um we already did the bundling discussion so the the next one I wanted to bring up was just this idea of having a much higher Gap limit for the inclusion list um I guess quick quick high level summary here is the inclusion list has its own gas limit because it's unconditional so it can extend the size of the slot n plus1 block by the amount of gas that's in the

inclusion list right now we have that number set to three million gas um raising it would potentially be nice the the kind of compelling reason to raise it is the the proposer for slot n has to exercise less discrep question over which transactions they put in the I so like if you took it to the to the extreme and said okay the inclusion list can be 30 million gas then what the slot end proposer would do is actually just kind of locally build their whole block propose that block effectively by gossiping their ilil and then the Builder would be able to arbitrarily like reorder insert um and kind of extend the next block by whatever private order flow they have I guess the downside of a larger so the the upside

here is that there's um there's kind of less less subjectivity in which transactions end up in the aisle because it's just all of them that you see in the B pool the downside here is that you end up gossiping a lot of transactions twice right so the inclusion list would be big enough like essentially the same size as a block so you gossip the entire block there and then the actual like many of those transactions would be in the slot end block self in the slot end block itself and so they would get gossiped again so the bandwidth requirements would kind of be like 2x I I guess like her istically that that sounds bad but um yeah wanted to kind of open up the discussion here see what people thought about it um I I even think if we do something less than 30

million gas for the inclusion list like let's say just say we do 10 million gas or something I still think the default Behavior should be kind of locally build the best 10 million block you can rather than having to go in and like specifically point at transactions that you think are censored though this thing could be like to clients to implement however they want um yeah I'll stop there and see if if anyone has any comments yeah Lucas so uh what is inclusion list and base fee uh relation right so can a potential attacker pump some uh find out and pump some uh

transactions to inclusion list to increase the base fee in in in the network just by doing that if he has some substantial validator set yeah so I guess the the inclusionist gas limit does not factor into the gas used in the body of the block so like if a transaction was forced included by the inclusion list that doesn't have an effect on the gas used um well actually I'm trying to think it's written in the E spec right now I don't think it should affect it I mean yeah let's see um Mike in the L spec you wrote not

included not included okay yeah so then it wouldn't modify the base fee at all right then it's a gas increase if you have a an inclusion list you it's just effectively a gas on increase right for that slot and it extends by the the size of the transactions that you gossip in in your inclusion list yeah yeah with valid transactions that's uh that's really good for like I guess not like removing the downside um to not include or at least removing some of the downside but it also means that we have to spec the gas limit to be below what is optimal whenever

people don't well include an inclusion list although people do or or I should say empty inclusion but yeah so the only time it's it the only time the inclusion list block space becomes very valuable is if the block is full because otherwise they could have just included those transactions in the block regardless right so this is like a relatively you know small market for when the the aisle becomes highly valuable so I think it's I think it's worth it ume you have your hand up yeah so I think uh because of what uh Mark is saying uh I think we should count the inclusion list uh as gas in the next blog because otherwise it makes

it harder to change this parameter uh there was this idea instead of having this constant as a constant in the spec to have it just something as a parameter we I see some some people discussing in the chat of like having it as some percentage of the gas limit whatever it is if we have it as something that we can configure and we just change a number and that's it that's good but if we if you don't count this as gas in the block then we can just not make it larger uh without changing the actual gas limit because we're going to be increasing the full gas limit outwards so I think it should count as part of the of the of the next blocks gas consumption cool yeah I'll I'll check

out the eel spec and make sure that um I fully rocket but yeah that that does potentially seem correct to me too if if we don't do anything I mean this is currently what would happen so when the next block will include transactions and if it goes above the target it will automatically for the next to next block it will raise the base V so if we don't do anything and don't specify anything it will be taken care of sorry I'm not sure followed that um could you say again so I'm saying that you know if the next block is going to be filled with

the transactions which are in inclusion list so next to next block we'll have we'll see it's Bas Fe going up so I mean it will automatically be taken care of we don't really have to do anything okay but what would prevent someone have to say that to trying to scope the uh transactions that have uh High base fee and can pay for it and maliciously add it to inclusion lists just to pump the base fee for the network right so that's potentially possible with this I don't understand how is this an attack if if you have these transactions in the mol you would want them to be included so H how is this an attack that we want to have our

there are transactions that are willing to pay the best fee and we include them uh this is what the blockchain should be doing I don't understand how this is an attack yeah like if those transactions exist they could just be included anyway and if there's space in the block by definition because they can't be included why wouldn't they be included I don't see how this is an attack to be honest I'm thinking out loud let me give give me a few minutes I will try to come back with an example no no attack I can tell what the attack is attack is that you know you don't include in this block so in the next block the Bas Fe goes down and then next blocks get included so if for example the next proposal is also sort of

controlled by me I can make sure that I can get bigger tip but I don't think the Chang at all this today just leave the transactions out of your first slot and then pay lower gas in the second slot it already exists yeah yeah is it is even possible today as well yes but I mean let's say how you this way maybe users can also collude by I mean let's say next proposal is not mine but I I have many transactions and I also control the proposal current proposal so I can make sure that you know my transactions will see less Bas Fe in the next block

because I chose not to P them in this and specify them in I so I mean this is not possible this is the same today too no it is it's the same as today because the you have to trust the proposer to leave them out of the block but put them into the iil if which you would you could just trust them to leave them out of the block today right like it doesn't seem different no but uh how is it uh not possible today is that you know uh by having an Isle I'm forcing the inclusion by the next block that guarantee is not available to me today right so uh so basically what I I'm saying that I mean this of course this is also possible

today in some ways but this is more uh easily able to attack or to make sure that you know I will definitely get less gas uh let I'll have to pay less uh if I can make sure that you know they will be included in the next block and this current block is below Target I mean again it's not that strong of an attack in my opinion but there is this possibility out there yeah I think it it doesn't seem that potent to me I think I understand what you're saying um like if you collude with the slot and proposer to leave the transactions out of their

block but to include them in the iil um then you get some stronger guarantees than you'd get today but yeah I guess it doesn't feel that urgent to me yeah I I agree with regard to how impactful is that and yeah this is just theoretical analys yeah I uh mind I I I mean this design that you've said pus has sparked some new ideas in my head but I guess they're not on the agenda but it it relates to what I was talking to both Mike and pus about earlier so I think there is a design that defeats what I was what we were

worried about um I don't know if I we could bring that up at the end of the call or but yeah why don't we do that we'll kind of cruise through the rest of the agenda and then we can open it up um yeah the the next question is how and this is from poas how big is the da problem um and if we have like the max size of the block EIP from Tony and and vitalic then are we kind of over engineering by trying to solve the free da problem and should we just go back to the older design oh V tal question um yeah I guess personally it doesn't feel like necessary to like the design is already simple enough to solve the 3da

problem it feels worth doing that um but if anyone has a strong opinion on further getting the design reduced to a point where we can just put the whole inclusion list including the transactions in the block um then I guess we could could get rid of the summary thing I don't know does anyone have a strong opinion on trying to go for that or brainstorming it uh unless I'm missing something terribly obvious I think there's a design where the whole thing could not be included in onchain at all and still be enforced by testers

uh like very similar to how me burn would work um in the sense that like you're just supposed to burn a certain amount of me and the testers will enforce and there's a cut off time you could have an you could have a you could have an inclusion like like if the testers see an inclusion list by a cut off time then the next enforce it yeah I I've heard like we thought about this a long time ago I forgot what we called it I think just like committee enforced no that anyway we had thought about this I think in general I don't like this because it's like why not put it on chain like what's the benefit of just

doing it at the attestation level it feels like a weaker guarantee and that the relay could no longer have the final say on whether or not a block is revealed in slot in and the entire concern that I mentioned earlier is completely mitigated like um I guess I can yeah but that that's the main benefit in my mind like if if relays were to take a very adversarial stance like they they already they already sort of they already censor blocks based on the idea that they're going to be held accountable even though that's never

been decided by any court or anything like that no no they censor blocks now because there's a demand for them to censor blocks I think right like some validators want hook up to it sensoring relay okay yeah all right uh I guess that does maybe maybe I think it makes sense to put the summary into the block and not only P2P because then you allow the ATT testers of the next slot to just check if the in if any inclusion list was fulfilled and not if their specific inclusion inclusion list that they got got confirmed right because otherwise we could just leave the summary out of the block at all yeah

I don't understand what's your point Tony I I didn't understand it would if you if you can answer the question like why do we put the summary um into the block at all I I was just answering like we don't we don't put the summary what I'm what I'm hoping is that we don't put anything on the Block but that that doesn't make sense in my in my n plus one block slot n plus one yeah I'm talking in the payload of n plus one you're talking now yeah yeah oh so that's just to say that it is on chain and the it's to enforce the validity of the payload and you're saying this might be

enforced uh without having a nonchain component I I mean yeah yeah I mean I was just answering to that that this might not work to to enforce it only on the P2P because current when the current signed that with few alterations the validators the testers just have to check if the in the block that they got that the inclusion list was obeyed and if you put that into the P2P layer then it's like okay I have to check if the inclusion lists all of them I saw were obeyed and this is kind of different not all of them just anyone that was seen by I

mean anyone that was signed by the previous block proposer by the cut off time yeah but you then you will need to like this is a Dos on the network right you'll need to keep track of all the possible ILS that the proposer might have sent right and you need to keep them all and then validate against all of them once you get you could make the the validity that if you do see more than one object then the whole then any inclusion list is invalid like or that you it's the same as then that's that def fits the purpose of of 3da if there's only one possible inclusion list then we might have just went might as well just commit to it in the block and this de fits the purpose of prda I'm just we're aren't we talking about an

attack where the proposer of n Plus or the of block n just broadcast a bunch of inclusion lists here and none of them are on chain is that what we're talking about so the issue is the proposer of slot n reveals a ton of inclusion lists he's allowed to do this and we want this to happen that he's allowed to do this because we want to Sol for the 3da problem now the builder of the next block includes transactions that satisfy some of the satisfy one of these possible ILS and you're an tester to that block how do you verify if that block actually satisfied one or not unless you hold all the possible ILS that this proposer might have sent there's no way for you to verify this I was that's why the payload comes with a

signed message with why why proposer would broadcast more than one I and my contention was that we would design with the expectation that they would broadcast zero or one and if they broadcast more than one then they broadcasted zero that was my no so so we want them to be able to broadcast several so that the I cannot build a rollup that relies on this I and not pay any gas otherwise I can just build a rollup my full da is going to be on this inclusion list and I'm going to send transaction that invalidate them on every single block uh we were speaking of the case where the inclusion list wasn't included on chain at all in which case there's no

3da yeah there is because I sent I pay the proposer to include my transaction in the inclusion list and at the same time so since this proposer cannot send more than one inclusion list then at the same time I send a transaction that invalidates the transactions that are in my inition list to the builder of the same block now the Builder includes that transaction my transaction in the inclusion list became invalid so already satisfied in n plus1 and I haven't paid any gas I paid very little gas I think I think we should probably um continue this discussion offline we only have 10 minutes left and I wanted to give um kajin the Florida have two things he wanted to bring up and then

maybe we can conclude with like a higher level discussion about next steps in in electric planning so um Mark and poz we can keep this going offline if there still questions yeah gender Yeah so basically uh one thing is that for the gossip sign inclusion list I would want to have slot so that you know it is easy to correlate if I haven't seen the parent uh that to what uh inclusion list this belongs to and the second thing is regarding uh and then basically do some validations or try to keep some reference around and maybe uh you know do some bookkeeping and the second thing that I've uh that I

think uh is in the execution specs right now it so one requires that for El to validate a current block they would also need to keep track of the parents uh transactions either transactions or I think in the current spec there is that you have to in the state itself you have to maintain who are the centers uh so if we basically uh I'm not sure why we moved away from the inclusion list that had nuances but if we had Nuance then I think we would not need to have this particular uh requirement on the execution side because then you can just check whether in the account whether the current nuances are uh set are more than

the nuances specified in the ilil and if that is then you don't need to actually keep the parent centers in the state or you don't need to no that's only that's so you're going to have to check so for each one access all of these accounts and check that the current nons is already higher in the state yeah so that could basically give a easy validity yeah I think a valid point yeah I think this works uh we should talk to the El I don't know if it's anyone from the El what's cheaper but yeah that works I was actually I was actually talking to Marius and that's where this point was brought in and basically I said J D to marus and he was on board with this because then this

sounds good to me all right cool cool I don't think I followed that fully but um yeah I'll I'll follow up with you after to make sure I can pull it into the heel spec and uh regarding the slot in the gossip sign inclusion list can we have that I'm sorry what was this thing can we so sign inclusion list doesn't carry the slot for which basically it was so can we have that slot information over there so that you know it's easy to oh so it's not currently there I I haven't even read the spec I keep my own spec in mind yeah you should have the slot in the

inclusion list because otherwise we we can be dosed by inclusion list from someone from anyone correct correct and then it could be future inclusion in the past or until you have B you can't make a yeah I think it needs to have it's easier just to have the proposer index in the inclusion list yeah it has proposal index again but again to validate that one would need slot so because you know the inclusion list could be from previous slot or whatever right so I think yeah oh yeah proposer index and Slot just to make that validation super easy cool we'll add that too I just took a note of it nice thank you very much

um those are those are great points G Jinder let's see um there's some chats going I think yeah I think the chats are seem kind of self-contained I guess maybe I'll I'll kind of dear us for the last five minutes into just um more of a meta discussion or like high level discussion around what is needed to to get to the point where we can make like a go noo decision for Electra um what's the appetite for for including this in Electra and like yeah I guess is there anything that needs to be done in the next week or two to really like help move the needle on that decision um yeah kind of that General

inclusion I'm all for inclusion list in Electra and I'm trying to Target up p with gs on this this week amazing yeah that's love that love that it's a onewe project for you that's incredible um yeah anyone else um I think the general vibe from people on the lith house team has been that we want inclusion list to happen but we feel like the there's a bit more urgency with something like maxu so that's something we'd probably prefer to prioritize but um yeah supportive of is I think I still have a few questions

around what the design is going to look like but um Pan's working on a prototype from our team seconded I mean not against iel in this Fork just against or I just really want Maxi be in this Fork yeah shall we uh so just uh updates for m since he's not here in the this SCH so he's working on the inclusion list PC from his side for guest and it should be down very soon y it

says he could get it done by Landing that's hilarious maybe it's a long flight or a very easy prototype one of the two from te yeah we are we are following it and we are already started working on a prototype has been a little little bit optimistic in the implementation but uh we already have something and once we adjust it for the unbundling and from the unbundled version and other changes I think we can have something working in next days or so so and um maybe can start doing some

interrupt and solidify ideas amazing probably I can stick for prism uh we we haven't coded a single line of code until the full python spec is more or less agreed on I'm not going to start coding because changing from bundled to non bundled where there slot is there are not there and the validation is different it's completely different the validation if the summary is in the block or is not so because I mean the inclusion list becomes a validity condition of block n versus block n plus one which is I mean I wouldn't waste time until this the spec actually uh is solidified uh having said so we don't feel anything has changed if I I don't see any situation where I personally

would be supportive of inclusion lists for the current Fork uh unless the fork moves to next year and if it moves the next year then I'd be supportive of inclusion list being as of ppbs cool um yeah but we can have a proof of concept a ton of progress honestly yeah yeah it sounds like the scope is very well understood um we're getting a lot of U messages in the chat about getting the spec finalized so that's going to be my number one goal um I think this call helped us get everyone

on the same page about the spec PC design um yeah I guess I'll probably close it here unless anyone has has any last thing they want to say um what are the next steps so we close the spec and we just meet for interrupt or do we want to set up like stages as to when a single client in single client def networks before running for interrupt or how are we going to do this do we want to have like spe back test vectors for validity conditions that we can run statically before P2P yeah I think this is maybe where i'

I'd lean on Tim or or any of you who've kind of done this a few more times to to understand that the the next phases but um yeah parents said it may be another break out room call

yeah y it sounds like a great plan thanks T um could I just hijack for a second to ask if anyone wants to or uh if just gauge the interest if anyone wants to talk about Maxi B on another uh organize a maxi B call before the interrupt like I'll I can organize it but does anyone want to attend is is

really the question I'd attend pron is not here but uh but I'm sure he will Paul from te will attend if it will be compatible with aak you okay I mean this think least want to fully talk on his behalf but I think he's the one that is following it from teide okay I'll I can shoot for like this time either tomorrow or Wednesday like night uh an hour ago when this call started but tomorrow or Wednesday and I can I think that's a little short notice but yeah you're probably better off waiting a couple at least Wednesday I would

suggest so like people at least have like a day or so to plan around it um but or Friday so you could advertise it in the allord Dos okay I I thought last Paul Danny was like hey let's try to make more decisions by all cordz so yeah yeah up to you I mean I just is tight that's true okay cool we're two minutes over thanks everyone appreciate you talk to you on Thursday or maybe sooner thank you