EIP-4844 Breakout Room #2

okay uh we are live uh welcome everyone to the second uh 4-h 4-4 breakout um i guess the goal for this call is just to kind of get everyone on the same page about the progress on the implementation on the kcg ceremony um and then take some time to chat about like what we see as the biggest uh blockers or like issues that we need to address on the eip and uh also kind of try and list out like what are the types of skills that would be helpful to have people contribute to the eip um so like yesterday there were a bunch of people talking on twitter about like how important this is and i think uh yeah a few people already reached out but if there's a way we can just better articulate like what's needed and what's helpful um i think it'll help filter the different people who would like to help out um yeah that should be it um i guess to kick it off uh mophie and i don't know if michael is on the call um i don't see him um but yeah mophie do you want to start and give us an update on like the implementation and where things are out there do you have i can't hear you yeah you're right he muted yeah no worries hey uh can you hear me yeah it's a bit uh it's a bit quiet but we can't hear you okay um um yeah so i've been working on the implementation um so where are we at um we uh basically have been working through the specs during the meeting um right now we have um an implementation for the um voluntary vision optimization and this is something that worked on um a couple weeks ago where we're yeah all right let me try the shape like that this is actually perfect whatever you just did work yeah uh is it better now yeah much better okay i'll take it all right so yeah um we're currently we have like most of the spec now now and other than the couple open issues that we need to resolve um right now we're working on just optimizing the implementation making it as fast as possible and the point of contention there is the um kcg blob verification um there's like an open issue where um we want to ensure that um verifying blobs is an adult vector so there's been some work that's been put into this back-end implementation to uh speed that up and uh yeah that's mostly where we are right now um and also like a quick um like prelude to announcement um we are working on a devnet um that will be publicly available pretty soon so looking forward to having like external contributors joining the network um and testing things out because that's going to be really needed nice um anyone have questions comments thoughts on that um i guess do you have a link to like the repo that's uh you and or repos that you and michael are working off to share here with with folks um yeah yeah yeah sure um what's that in the zoo awesome uh by the way mophie you asked some questions about the verification code and why it's so slow and all that stuff i tried to answer last week i hope my answers made sense but if they didn't just like ask again and or we can do a call the two of us to figure out in more details how to optimize the code yeah thanks george i did skim through them but i haven't looked into it in detail but it should have more time um next week to take a closer look at that sweet response is like a public doc or anyone can look at i think it was in the short i think it was in this charted data chat yeah oh okay thanks yeah and yeah maybe maybe it's what what the briefly saying because i also put it in chat just no but um like we got because we have this kind of 1559 like mechanism for blobs as well we kind of we have a reasonably good understanding of the kind of frequency with which transactions will will come in because the mempool can be very small for them as well so so you'd only expect like to see one legitimate block transaction legitimate meaning that kind of the commitment actually matches that the bob sent with it um coming in every few seconds so the verification of the legitimate ones is not a problem at all like performance wise it's really about handling if people spam you with transactions where the blobs just don't match the commitments because then you can't even charge them for for it so it's it's like it's similar to like an invalid signature so it's really mostly about like peer scoring and making sure that you just don't allow one pier to send you multiple of those and yeah so so that's at the core of the dos issue got it and as i understand it though there's just no pure scoring uh on the execution layer right like there's no um yeah there's no easy way like you need to be able to verify them quickly because um we there's no like uh granularity in the scoring either you stay with the peer you disconnect them so um so you could disconnect up here but basically after they've tossed you in ideally you you haven't gone down because of that all right okay um so i'm just related to that um um we do have like peer scoring um in the consensus layer but um there's like a weird issue where um you sort of have to defer verification of um log kcgs in consensus um whenever the block headers are not available right um and at that point at that in that case if you are deferring bob verification it's much harder to penalize peers if they do send invalid laws because it's it's sort of like you'd have to like keep track of like what peer is associated with there's a blob and i imagine that's like that complicates the implementation of uh various consensus clients at least that's what my experience has been implementing this in prison so i mean if the execution layer is not synced like you're in an optimistic sync mode or something like yeah which header did you mean um i'm i'm referring to the the blob site car in consensus client so as that's being gossiped um it is possible that you receive a side card that's associated with um the beacon block that um hasn't been observed yet and in that case you want to like defer processing of that blobside car rather than just simply rejecting it because you it might be incorrectly labeled as valid so if you do defer that processing then you need to keep track of what peers sent that sidecar in order to penalize it and that's just one um complexity with the implementation yeah like so obviously it's like yeah we want to make sure that verifying blogs is ideally just like not a dos vector because it's very practical on the ell and like somewhat impractical on the cl to to deal with peers based on that well we do do this on the cl like this you know if you get an attestation ahead of time it's the same problem so okay it's not impossible it just probably is more complicated than like an mvp got it oh okay get to them okay and and yeah i see you have a comment about like the the cl sync and the site cars um does it make sense to like discuss this now yeah i guess i guess so actually yeah important implementation stuff um yeah do you want to take a minute and scar and kind of share your thoughts on that right so i think this is basically just a question that a couple people had but when we were discussing this so in paris so basically uh i think for now the plan is to um as morpheus was saying uh just now as well to have this this sidekick architecture where basically um blobs are more or less gossiped independently uh from from from the beacon blocks uh between cl clients um and that can lead to all these differences where sometimes you get a blob and you haven't actually received the the observed the beacon block yet and the other way around and and and everything and um there was some concern and i think i only heard that like secondhand like i think proto was saying that some cl client teams had kind of i'm not sure maybe could say something but like there were people that basically yeah raise some concern that this this might introduce scene complexity um i'm not surprised if you want to say like some some to that um because uh and and and so basically the the conversation that we were having is whether or not it's actually worth introducing this extra complexity now of course the the the reason people did it in the first place who came up with this architecture in the first place is that it's more cleanly forward compatible with full sharding because um basically then we could just drop that that whole kind of uh um this is because they're like like in the future we'll have to have um blobs and blocks be separated anyway because you know clients will no longer download all the blobs um so it's cleaner to already have that separation today but it does front load some of the extra complexity so if we want to really follow the strict minimum complexity approach for 484 and there is a case to be made to just to return to something where basically um you you bundle the blobs and the blocks after all um so that like whenever you receive a blob it comes with a block and the other way around so there's never like this and there's no extra complexity around having one but not the other and things like that i think that's fair um long term with tank sharding you may need the separation short term maybe i think it's up to implementers to make the right call mophie what do you think yeah i think that um bundling them will simplify this implementation on ways to present one concern um i do kind of like have is uh so the advantage of like having to keep the tip separate is it makes it easy and quickly to drop invalid sidecars before we even observe them and what i mean by this is basically if you observe like the vegan block that is invalid and you immediately later receive like the associated sidecar um you don't have to like do expensive pallets you can just drop it immediately and um if we start bundling things there is a network cost of like transmitting the whole gamut and therefore um it's i guess like you're shifting the uh the cost um there's like a cost involved with like always transmitting the entire video block and making sure that um if it's invalid then you've already incurred that cost of like you know storing that you can walk momentarily which includes the sidecar and yeah i guess this issue can be solved with appropriate peer scoring and maybe yeah maybe this is not a non-issue but that's basically my only concern here we're doing this and mophie the current implementation does already separate the side cars from the regular blocks correct yeah okay so maybe we should not change it for the stability of this definite then and then take more time to consider whether or not we should merge the two things i don't see a short term going into merchandise yeah i i would tend to agree with that and i feel like once we have maybe a devnet working and like uh kind of these other spec issues resolved we can also bring this up on the cl calls and like get and and in the meantime also get cl devs to like look into it assuming they have time which is a very generous assumption and but yeah i agree like if if the current version works right now it's not worth refactoring the entire sync but it's worth noting that like there might be a simpler approach and yeah discussing this with cl teams does that make sense to people yeah that sounds good cool um any other thoughts comments on the implementations generally or on sync a fun thing to add right now we have the prism prototype there's this fork by mophie in one separate repo and then there is this other gaff prototype with a fork from michael the house so we have these two forks of consensus and excretion clients that are that may have this distance in terms of kids differences from the latest merge work and so if people from these clients are listening i'd like to hear our feedback about incorporating more of the latest merge work and whether or not it's the right time to start rebasing okay yeah um i don't think there's anyone from geth here and uh terence from prison told me he could join probably uh for the second half of the call so um yeah when he joins we can maybe ask him about that directly as well anything else on implementations um i guess oh yeah there's good i don't ever get to this later but there's the uh issue of um the kcg libraries we have um we are using for the implementation and you're using whatsapp the kcg libraries um yeah we are using for the stages like the blog verification um we've basically just been using the library and guest and uh now that we are uh we also need some of that functionality in prison the consensus uh we sort of like have to like decide uh what's like the best approach to we're using the same functionalities across both implementations so on that front we are in contact with the blast international people i would say that there is progress but this progress is kind of slow so like uh we sent them like that like over a month ago we sent them the requirements for what is needed they got back to us this week and they told us they're gonna send us back some sort of report on what they gathered from what we sent them and that we should do a call next week to figure out next steps so you know things are moving and things will probably happen next week i will report back with what i learned but also another thing i want to raise on this topic is that it might be a good idea to have some of the more people more involved in the implementations of this of these things involved in such future calls with the supranational people to give a better idea of what is needed in terms of interface because you know like i think i know what is needed but maybe someone who is more involved with the actual uh stuff can give more insight so i'm gonna let you know next week of what happens but i might ask for some like volunteers to join in future such calls with them to build the better api basically cool yeah that's really you so i know amerius from guest had mentioned like he had some thoughts on that um so um he's probably a good person to reach out to to join those calls um and beyond obviously like you know murphy and michael here as well but yeah he on the last one of these calls he seemed to have some pretty strong opinions about it so yeah yeah yeah um and i guess generally the people feel like blast is like basically the best option is to adapt blast and make that better because i believe that's like what all the cl teams use already correct um but there's no kind of other option really on the table right now uh the the interfaces we need are a very thin wrapper around functionality that blast already has i mean around functionality that any bls library will implement already so um since we're all using blast it makes a lot of sense just to um to put those in got it okay um okay anything else on the implementation that's all i got cool any other questions folks here okay um i guess next up uh trent i see you're here do you want to give a quick update on the bls side of things all right sorry about bls at the kzg side of things yeah i was going to say i could barely cover the kcg set i definitely can't cover bls but yeah um so similar to the since we started this we're just doing kind of the same stuff uh we have an audit coming up for the um the ceremony implement early not the implementation but the the design of the ceremony um with sec bit coming up soon so we're preparing for that in a few weeks i just shared a link to a bunch of resources which has a link to the implement or one of the implementations but specifically their calls if anybody wants to catch up or is curious how far along we are um that's the main thing we're preparing for the audit um and we have the next call next week on thursday 11 30 30 or utc awesome yeah there's also a timeline doc in there uh if anybody's curious about when we plan to start this hopefully around defcon and then we'll have an uh we'll have a period of closed contributions before that to test it and then um at devcon hopefully we'll have some live contributions from the audience and then it'll run for a few months uh we also have some people starting to work on a couple test sites uh jeff lampard's been working on that um to make sure all this stuff works and uh we started working on an interface that will that users will actually uh interact with in the browser so that should be everything any general questions that i can maybe answer okay that's it uh just a quick question i'm just curious like what is the size of the ceremony that you have in mind number of participants yeah roving for ten thousand okay which would depending on who you ask it would make it the largest uh trusted setup ceremony nice i get your questions on the ceremony okay um i see terence has joined um oh are you can you hear us terence do you have a mic yeah sorry i had another meeting but i am here so feel free to yeah yeah there's two i think there's two things that we discussed that like we're curious to get your your input on um the first is um around the the cl sync uh we were having a conversation that like we've decoupled blobsync from block sync to have it be kind of forward compatible with the full sharding approach um but that might introduce like more complexity at the cl side and we were thinking that like there might be value and potentially just recoupling blobs and blocks at the sinking level um for like the first version of 4844 and then you know eventually making the this the sink um more decoupled um but i i hear like yeah generally do you have any thoughts on that and like how how much of a simplification it would be to like couple them now and like is it first and is it valuable to do it or should we try and front load as much of like the sync design as possible right we definitely had this conversation at ecc which i remember and i am in favor of the coupling approach i'm not too worried about like trying to be the same as sharding in day zero i think like we we got real then charting we need to have a far hard work anyway so we can change it then it's not that big of a change but it would be nice to just like i think we can definitely shoot 444 slightly faster just couple them together it's less engineering challenge that way it's less implementation it's also better ux so i am i i am 24 saying in favor of the coupling okay awesome um and uh the second question we had for you is um the diffs between like the current prototype are starting to diverge from like master with the merge work and presuming get when do you think it's like the right time to rebase this like uh yeah yeah yeah portal asked me to help i am so i think i should be free after in a few days just trying to finish last minute um met those related um issues so yeah i should be free in a few days and then i'm more than happy to help just send it over the branch i can replace it for you shouldn't take me more than a few hours yeah oh okay well nice um so i think those are two things for for parents um sweet and i guess um yeah the other thing i i want to make sure we chat about is like um we have folks now like uh obviously on the optimism side on coinbase kind of working on this um but this is like a pretty big vip and there's always a bunch of folks like sorry so by this i mean the implementations uh there's a bunch of other work as well but um yeah there's obviously a lot of work to do to like get this implemented and tested in clients um and it seems like there's some interest by like the community to help and um i guess i'm curious like from like coinbase and optimism like what like skill sets or like tasks do you think would be most helpful to have people help out with um that are like maybe a bit like independent from the work that you're doing or that like can be parallelized um if there's like engineers who have some time and like yeah experience that that can help here um i guess yeah one i'll start one that's will be really useful once we have the data running is just having users in the network um testing all sorts of scenarios um sending blobs downloading jobs um ensuring that you know they um the current gas feed calculation sort of works um in a dev environment and yeah we just like to have more participants in the eib4044 test net that would be super useful um another thing would be um if people should just take a look at the the codes um the various repos that i posted zoom maybe we can make these available um somewhere like in the community call agenda but take a look at the repo um see if like we can improve test coverage um particularly in prison because um a lot of the testing we're doing here is uh based on another repo that basically come um interrupts both guest and prism for testing um but it'll be nicer to have like more test coverage in presents you target specific scenarios that ensure that you know the vip is as most as possible got it and i guess in terms of like actually implementing things um uh i guess we have like kind of the coinbase coinbase folks working on on the guest implementation you working on on the prism side um i see there's like a bunch of pine devs on the call like do we think oh sorry yeah uh mixed up but get in prison and coinbase and optimism um yeah do you think it it makes sense to have like other implementations sooner rather than later or should our focus be like let's get these two kind of as as far as possible and and then add some more yeah i think it makes sense to get as far as possible because yeah we are still making changes to the spec um particularly the gas price update rule um we're probably gonna have a discussion later right now um and for how we're gonna do that also if we do decide to go ahead with bundling the law um we can block inside cars and that's like another change that other implementers will have to like do so it just makes sense like consolidate um all the changes that we want and once we get to a point where um we're sort of like the the spec is sort of stable then we can start introducing more implementations okay that makes sense um okay and so base so basically yeah i guess the two main things now is just like testing on the devnet um as soon as that's out and then um basically uh seeing if there's test coverage that can be approved uh in the in the current uh prism and get implementations um those would be like the two most useful things right yep yeah but that said i think if you know someone came along with an expert a particular client we're not working on wanting to get started we would we certainly wouldn't stop them yes yeah obviously uh yeah and i guess would it be helpful like if someone comes along and they're an expert in prism or guest you know is that also helpful to have more people working on those specific implementations um or is it just like too much people on the same kind of parts of the code uh no i think that would also be helpful um there are like two or three major items i foresee in like the next couple weeks where um back like two or three people can work on um differently without like stepping each other's toes so yeah i think that will be helpful um having like experienced prison or death devs contributing to the implementations okay great so um so i guess if tier and experience get the prism dev listening um you can reach out like to me or i guess liam you also posted about this yesterday so i'll put you on the spot here um yeah if you're if you're interested in contributing and like if you're not sure where to start we linked i'm i have notes for this call so we linked a bunch of stuff there um and then like the very like first place is probably either the devnet or looking at the specs and and kind of diving deeper from there does that make sense um okay so i guess yeah the last thing i wanted to cover today and i think it should bring us right to time is um just basically like our list of uh of issues from the last time and we touched on some of these already but not not all um so on the kcg library section you know we're still working on improving this um on this this we discussed the sync a fair bit um and i guess the last one is like the fee market um yeah uh and and i guess just to to put some context here so right now the current devnet implementations use kind of the the um the naive fee market with like a hard-coded uh hard-coded gas price uh for blob all the time um this is not gonna work um there was a proposal in the eip for just a more complex one that was basically uses eip1559 uh style pricing for for the free market on the last call we kind of discussed moving this from the uh from a special contract in the state to the block header um yeah and i guess i was curious to hear a from people like you know does this general fee market just makes sense do we think it's good enough to move forward and b does everyone agree that just having this in the in the block header is is the way to go yeah oh enscar yeah sure so um i think kind of with regards to the header uh i think basically everyone agreed that it might just be the more practical way to go for now uh the only person disagreeing with vitalik incidentally but uh so you know forfeiting is his boys here and i think on the mechanism itself uh generally kind of the mechanism proposed by the ap more or less uh works uh the only reason why we kind of by for a while now it's been a somewhat open research topic is just that there are things we would like to get that are not fully provided by the fee mechanism but they are more like nice to have so basically um for one it's uh that while this works really well for something like blobs where demand is relatively slow moving it wouldn't quite like perfectly be be generalizable because for like basically sorry stepping a step back like this would be the first time that we introduced like a two-dimensional pricing mechanism one dimension for bobs one dimension for normal execution um roller projects for why now have been saying that they would really like to have like a standard standard for doing two-dimensional pricing because they have to do that anyway because they have to price layer two guys and layer one guess with inside one transaction basically for now all roll ups basically hand roll their own mechanism for for like two dimensional pricing um we would like for the four eight for four mechanism basically to be generalizable the current version is not ideally generalizable just because uh like um in in in that context kind of the two dimensions would be much more fluctuating and because they share the same gas limit that that might become a problem again not a problem for blobs just a problem for generalizing the mechanism and then also kind of similarly we would also ideally want this to be maximally forward compatible with like full on multi-dimensional pricing further down the road but i think on both of these counts um it's in this it's a somewhat similar situation like we when we're talking earlier about bundling blobs and blocks on the cl side where we might just want to be practical and say we move forward with the minimum working version for now and then you know we can always iterate on it later so i think there's still some effort to try and maybe look into this whole kind of compatibility with layer twos just because they would really like that i think um so maybe we'll you know if if we come up with a slightly alternative design within the next month or so that would include that i think well like all the better but for now we can just you know we can just work on the basis that we have a mechanism that is good enough basically sorry that was a bit long but i hope that that made sense yeah no thanks that's quite useful and yeah i was gonna be you because you have a bunch of comments on like clients pr so yeah right uh systemat mentioned that uh live client does uh have a pr open in the eaps repository to update the old mechanism to a new mechanism that uses a header field instead of state but then other s does not change anything about the previously proposed fee update mechanism and i want to note here that this is not exactly the same as erp1559 the adjustment works a little bit different and i think there are some subtle issues with this of that mechanism and i'm not entirely sure what the right direction is to correct them with this blob pricing problem we have this balance we can make or this incentive whether or not we want to prefer a burst of blood data or a repeated small smaller burst so if we go over the target the guest price or the fee rises and this is incrementally more costly and so small bursts right now are more expensive than grouping all the uh the blobs together even though the total amount of throughput after the end of the the example is the same and so at this question do are we more concerned about bandwidth on the network and about the stability of the bandwidth or are we more concerned about the processing because if processing i think it might actually be favorable to create this incentive for a large burst of blobs rather than this more stable amount of blocks i don't think we care much about either of those i thought what we care about is long-term storage costs like isn't that the dominant factor here by a pretty large margin we have pruning so long term is really just a month worth of data there's this other issue with the current design of the fees here i'll give an example if you exceed the target then the price will go up and then if for say a month whatever the period is that blobs are retained if you perfectly match the target then you will eventually prune the excess but the gas price will still be sticky and will still be high so even after pruning after correcting it for a long period of and stabilizing it for a long period of time the gas price is still high due to the old excess so i think the gas price update should consider pruning perhaps and we should consider like the kind of characteristic that we want with the blob throughput if you want like repeated small additions or infrequent large editions so what are the concerns so sorry just briefly mentioned i think one of the concerns with um on the pruning side was just that it might be um not not ideal to basically um entry in specific retention like specific assumptions about retention periods in the pricing mechanism itself because otherwise this is basically just a a client parameter where of course i don't know we we we like to give some defaults and some some some recommendations but basically if you want to run a cl and just drop blops after a week you can do that or if you want to keep them for a year you can do that um but with the moment we kind of have have some sort of like finite memory set in in in in the block pricing mechanism then of course we're starting to enjoy that other than that i think it's perfectly reasonable and it's also not not too complicated i think to do that so we should i think no matter what sorry i'm just gonna say i agree we probably shouldn't enshrine some specific value but we should price the fact that like they are like temporary to some extent right and it's almost like you don't want to enshrine like a week versus a month but you also don't want the mechanism to like even implicitly assume they're going to be stored for a year if that makes sense because that kind of nudges clients to like not store them for a year which is what we want but it's i agree you don't want to have like a a hardcoded cutoff of like this many epochs or something one approach could be to bias the pricing towards more reason throughput so that's older throughput is dampened i think there are some balance here because otherwise we basically end up pricing blobs based on like very very old throughput details which might already be pruned and this just makes pricing less accurate in my opinion i think we can be better than that that's exactly the same situation one five five nine however i believe that the counter argument there is that's a kind of latent like remem memory of historic pricing is completely lost the noise in the real world like so in a theater in your theoretical scenario you had perfectly even uh throughput except for that one little spike and that one little spike causes that to retain kind of remember the spike forever but in the real world you are never going to get that perfect and as soon as you have any kind of variance that little tiny spike gets lost in the noise like right away i believe like i'd be very surprised to see to see like that that kind of that memory matter at all in any like even kind of worst case scenario real world real world situation yeah this is this is maybe like a dumb question but like can you just walk us through actually how the repricing occurs like and how it differs from 1559 yeah like so 1559 is like you look at the gas in each block and you go up or down by like 12 percent i'll try to give my best interpretation i do think there is like a small inconsistency in the explanation of the gas pricing in the erp currently so it might not be 100 correct about those um so the basic interpretation is that we track the amount of blobs that have been confirmed since the start of the eip and we track or we can compute the the targets the expected amount of plops that we that we would want now we take the minimum of those so we know whether or not we are under bloated targets and say if we're over the targets we're going to adjust the prices upwards if we're into the target then the sorry for under order targets i think the current efp makes blobs very very cheap i don't i'm not exactly sure if the erp is correct in this case but let's just take the case where we are over the target in the case that we're over the target we use this this exponential thing where the more you're over the target the more the blobs will cost i think there's a mat there's a cap where if it goes below target it'll take the maximum of target versus where we currently are so it never actually goes below target that's that was my reading i think i think that that's just basically um uh so it doesn't so i think the the pricing basically the difference between the pricing of the the post pricing for 484 and 1559 is that 1559 basically always does relative adjustments so it it doesn't care about the absolute value of the base basically just says okay the block was under full go down the book was over full go up whereas um so it's always like just you know it only looks at one last block whereas um four four eight four four does the the exact opposite it has like this infinite time horizon where it just says i want to always have half of the blob space filled and i just keep track of historically like accumulating over all history what was the percentage and as long as the percentage was under is under 50 then basically blocks are free um and the moment we are over 50 then blobs uh basically cost something and that price keeps like keeps going up uh the the further we are about 50 to basically until we at some point you know get pushed back down to to 50 or like there could be some equilibrium where we know we are 51 or something but now just very briefly saying like why does it not really matter that this is that it has this long term memory and i think that's kind of also what mica was alluding to um because of this mechanism we will always end up in a scenario where we are close to 50 we could be below 50 in the very early days when no one uses blobs but besides that we'll always be like in the 50 to 55 range or something something like that right um and so just because bob's might have been more in demand in the past something doesn't really matter because it just means that this value will be at 50 between 50 and 55 so the the worst case is that now the demand is only 50 and it or 51 and it used to be 55 so there's like a four percent difference or something but that that really doesn't make a big difference and it washes out over time so so it i agree that maybe it's still preferable to to to to make that more explicit but there can't be a scenario in which like the the historic uh accumulator is at like 90 or something because that's so that's the entire like thing that the the kind of targeting was supposed to help against is that right that makes sense with erp level f9 though we as we are adjusting downwards there's more precision in adjusting downwards whereas in eip484 as soon as we're under the target even by a little bit things start to become i think a little bit chaotic as the pricing is not accurate anymore yeah that seems weird because you could imagine like i don't know there's no blobs for a week that doesn't mean that like we can then like process infinite or like a ton of blobs the week after right no but but but it kind of does so so basically the idea is that uh because we have this maximum that's only two x the average anyway like we we would be okay with it to sustained oh like okay yeah okay yeah so we're okay so the assumption we're making here is where okay would have sustained full blobs for long periods of time which is not an assumption 1559 makes that is correct yes i think even like that if a counter argument against this in your example when there's a week of no data and then a week of double the amount of data then on average there's no excess but the there's a bias towards recent data so assuming there's pruning or no pruning we i we might end up holding a lot more data due to this this imbalance over time right so because the pruning time was a week now we're holding twice as much as otherwise with normal pruning and normal throughput right i think basically the the assessment was just that basically this inefficiency is there like you could basically just because i mean in the long run we don't expect this to be to really be the case much because uh you'd you'd never be like for a sustained period of time be below 50 because at least in our assumption there would always be some demand for blobs so that it would be used like before we get dipped down you know 50 um but in the early days it could definitely happen um and so we have this slide in efficiency that we basically have to be able to handle storing 2x the amount the average amount for say a month or so because there would have been an empty month and then a double month and so we basically have to store two eggs uh for that we gain the simplicity in the algorithm so this is a trade-off we could try and make the trade algorithm more complex and more more sensitive and then we don't have the strike storage overhead in the worst case yeah that's a choice i think we're starting to basically convert some of the other problem with this choice between prioritizing many small smaller amounts of pops versus a few larger amount of blobs if we have clarity about this part like what kind of throughput maximum like in a sustained manner is that we want to favor then maybe we just also solve for the other problem michael uh what what was the reason behind choosing this mechanism instead of the 1559 mechanism like what is the perceived advantage they seem like they'd result in basically the same thing but this one requires an extra header field wait how does it require anything i can give some because you have to keep track of how many blobs have since since genesis okay there's some details about the header fields and how it would look like if emulate the erp-1559 so uses the parent's information the parent block base fee and then has this lag to update towards the new base fee for the dating but the base view update is correct and it uses the total amount of gas that was used to do so so this is the second header field that is already available for your regular gas to be able to do this update with two header fields from the parent block to get and compute the new base fifteen expo block with this erp we don't have such information that captures how many blobs were included in the previous block without having to make the full block available like the header data itself is not enough to get the right information to update a base fee in the same way that eip-1559 would do so instead this mechanism tracks just that information the amount of blobs that have been included and then instead of introducing this base feed that needs to be updated it complete it computes it just from the total amount of data that has been included by keeping track not just of the last parent block but of all of the total included blobs and then comparing it against a theoretical target based on the the block height difference and the number of blocks that are the number of blobs that you go into each block so with the short version of that beef that um if 1559 requires the transactions from the parent block this does not require the equivalent of that which would be the blob so if you're going to exactly emulate earpin1559 we would need to add two fields to the header we want to count the number of blobs and one to count the or to represent the base fee for the blobs isn't number of blobs already in there now effectively can you repeat that isn't the number of blobs already effectively in the block header we keep track of that not total number but number of blobs in the previous block no us blobs right now they are referenced by the blob transactions and the blob transactions are just part of the transaction list so if you only really have a hash of the transaction list which doesn't really tell how many blobs there are is this formula written down in the um eip at the moment the one based on total number of blobs for all time yeah yes that is in the eip and then in the pr of maps you can find the the header based version of that as opposed to reading it from the stand i'll link it in the description the gas price update rule in the ap is that correct it's in there yet um yeah just because we're kind of uh basically hitting on time here um i feel like yeah the the two like this idea around like yeah short burst versus like long-term history is something that we probably should get like client team seat backs on and especially on the cl side and along with the the sync design um that feels like the main probably like thing here i guess the other part like enzgard you mentioned around like having l2s being able to use this as well as a pricing mechanism um it feels to me like once we kind of have the preference from the cl teams that's maybe like the second thing to look at and and basically those are like the two most important things to figure out for the free market does that make sense right although just just to clarify this would not be this would not be on on this question of what specific kind of well i guess i guess it would also be relevant like whether it would be short-term or long-term kind of stabilization mechanism i guess they would favor of course the short-term stabilization mechanism but for that it's much more about uh kind of how does the the two-dimensional pricing actually works so the way the base the the erp right now works is just basically basically just translates the variable price into like a variable um amount of gas consumption but then the gas is within the transaction is accounted as normal um that has some like disadvantages that aren't really that relevant for 484 but they would be more relevant for roll-ups so so basically if we wanted to make this kind of more raw compatible that might need might mean we would have to slightly change the way the accounting works as well not not just this okay this design choice but but yeah yeah okay i do feel like yeah oh good so am i correcting that this is not adjusting the gas price it's adjusting the gas uh cost like the amount of gas that's used for blob yeah we just said nascar yes oh i see yeah i'm not a fan of that but i'm running out of time so i won't complain too much right now yeah yeah but okay yeah that makes sense i i i guess it's like yeah indeed if you think of it as like the interloping constraints or something i just want to make sure that like what we present as like the trade-off space for l2s is or yeah is kind of what cl teams want to optimize for because like yeah i it's it's it's kind of crucial that like cl teams are happy with this uh if we wanted to implement it on l1 um and then yeah i guess beyond that uh i guess getting yeah the blst editions uh that'd be really helpful launching the devnet and having people kind of look uh look into that um and then finally does it make sense to like already schedule another one of these calls or the people prefer to do this like async um oh karen yeah i wonder sorry i came late so i wonder if this was discussed has there been any thoughts about having some sort of meta spec just because for me i'm like looking at all the specs and it's hard to know which one is the version that we're aiming for so something like that would be nice i think proto has one but i'm not sure how i'll change 30 minutes ago so that must be yes i'm adding links as they pop up to keep track of everything but i we do not have a first name scheme for the eip so all these different resources are at varying stages of purpose and we'll be discussing the executable spec for the execution layer on welcome devs next that's the type week stuff people are interested in uh sorry george i know i was just gonna say that like this desync between the two specs right now is an actual like issue because um with shawway we did the consensus specs for eight for fourth thing to be executable and that brought a bunch of like edits and differences and right now the two specs are pretty desynchronized in terms of the kcg stuff and i've been waiting to make an eip pr um to bring it in sync but i'm not sure when to do that so that was another topic i want to raise in this call but maybe we can do it on the next one like what's the best way to keep it to sing yeah is the reason for not uh updating the ap regularly just because um too much hassle when you wait until things are kind of hammered out and then update the ap or is there some other reason that the ip is lagging yeah that's that's the reason that like it's like two like code duplication in the code base but to like change the second code duplicate i need to go through the whole pr process and so i was waiting to batch a bunch of stuff inside before i do so but this is all related to the execution executable spec thing so maybe after the acd we can do have a more like productive discussion about this stuff i do think yeah i think this is like one of the best examples of like why our process is broken because anyways like yeah and i know already over time but i i think if if you want to come or and proto as well like uh on awkward ebbs to like kind of highlight that next week i think it would be good um because i don't think this is the last time we have a feature that touches like both layers and um yeah yep um yeah so yeah that would be that'd be really helpful yeah i guess do people want to set up a next call right now or do we want to do that um outside of this and the time i guess looking just like roughly at the next couple weeks i think the time i would propose would be like wednesday august 17th at 14 utc so if everyone here is happy with that we can just put that now otherwise we can just chat about it on the discord so any objections to the 17th 1400 utc okay no objections uh cool so i will see you all then um and yeah let me share the notes in the chat here i'll post them in the in the github agenda as well um yeah thanks everyone this is this is really good thank you thank you thanks everyone careful you