All Core Devs - Consensus #146

Transcript

[Music] than

[Applause] for

we all

Alex Stokes: proceed okay great everyone let's see this is ACDC 146 it is issue 1200 in the PM repo I put the link here in the chat and yeah there's a number of things here on the agenda today uh we'll touch on Mong testet the intent is to finalize Petra oret 5 and presumably that's the last sort of spec updates we'll need for pectra itself um otherwise yeah then some other other research things at the end here so

in any case let's go ahead and dive in because there's quite a bit here so first yeah I wanted to talk about Mong uh this was essentially from devet 4 as I believe and it was a public basing test net there were a number of deposits uh I think Monday or Tuesday that caused some issues and I think every client well at least every sale client had some bug uh that being said uh the test net is finalizing again which is very nice so good work everyone and in any case uh is there anything else we should be discussing here any follow-ups or contacts clients

would like to add around this bug okay we got an all good from our side in the chat fair enough okay great so yeah there are some issues uh with the deposits and yeah I think there's a number of different places we can add tests uh just to make sure that there aren't any uh regressions and yeah we definitely need more spec test as po calls out here

Mikhail Kalinin: I just wanted to add on the spec test side uh we have tests already um in the pr uh for this specific case and for

other potential cases there is an issue that I've recently opened um so we need test to cover um the epoch processing in a bit different way than it's covered today in the consensus spe test so today we use kind of like code coverage metric for um for like for the uh processing tests which is the code code used that is that the spec has and the problem with the on the Mong that happened recently was because the the spack and the client code are different because clients use um caches so um we need to to do more

extens ensive testing and find potentially in ideal situation we find all these kind of dependencies when one hoc processing function does the change to the beon state and the other function um uses this change in its logic so if anyone wants to um if anyone wants to help with this Brien this tests um there is an issue and yeah I'm happy to to help on that

Alex Stokes: cool

Mikhail Kalinin: yeah yeah I'll just send a link to this issue

yeah

Alex Stokes: another thing to add there is uh at least I looked at one of the bugs and it wasn't so much a

cashing issue it was just like a you know an accident really and spec test should catch this kind of thing um one thing to add is the spec tests though are you know I would say primarily more like unit test not so much like in-in integration test um there are some types of spec tests that start to get towards more into in things but that being said um yeah clients should be careful writing code and you know do testing on their end as well and not just rely on the spec test

Terence

Terence Tsao: sort of mutation testing that's happening with the cicd sorry for the stupid question um I think like a couple months ago I went through um basically why I did in prism is that I started

commenting out every every single line of the state function and to see whether uh this the basically the spec will still fail and then if it doesn't fail I make a note of it because that typically means that there is a spec test missing coverage and I think I open like three PRS on the SP test because of that so I wonder if it's worth doing again from my end or do we feel like there is sufficient coverage on the SP test today

Mikhail Kalinin: I would say if you if you're willing to do this please go ahead and you know just just do it but for this particular case on mikong even if yeah that even if

this this pack would have a perfect test coverage um and probably it has in this particular case uh it it would not mean that um yeah that we would reproduce this bug using those tests

Terence Tsao: yeah definitely yeah

Alex Stokes: yeah I think with testing the more the merrier so everyone should always be thinking about testing from you know the more angles are better cool well that being said uh we quickly resolve the B the bug and I think everyone has Shi fixes or will soon so nice work and yeah anything else on that otherwise we'll go to devet 5

spec Okay cool so there's a number of things here um let's start with this first one there was an update to 7685 uh to change how we handle empty request with the hashing and the commitment on the El so this one yeah so it's in a bit of a word because I linked the execution API PR here uh these are the updates with engine API there was a corresponding EIP update and then also a CL PR update the CL spec PR and the EIP have been merged

uh this has not been merged but it sounds like just going off of a comment from Felix here on the agenda that there's maybe still some open discussion um my understanding is that we wanted this change and we are going to merge it and yeah I guess we should figure this out now um if we want to walk it back which I don't really recommend at this point we need to go unmerge some things in other places so then I guess the question is yeah does anyone feel strongly against this change at this point we have support so so yeah and

this is my sense so I think we just go ahead and Merch this one in

Mikhail Kalinin: yeah just Felix wrote that probably we should not um like have a requirement on on the strict hold on the engine API and just leave this requirement to to the CL side so the requests are sent in the right order this is kind of enforced by sales packs rather than by engine API um this one of the recent Felix comments um other than that I had some you know some comments about this ordering why not doing it on E but I don't mind to merge it as is it's not like super strong uh super strongly opinionated

that it should not have the order um statement in the engine Epi spec so if there is a strong um consensus if there is a strong willing to to merge this as is and there is no opposition from the client teams then just let's just merge it

Alex Stokes: okay yeah I mean that sounds like that's where we're at we're getting support in the chat and yeah I think given that we've merged other things that move and locks up with this one I think we go ahead and merge this and we can close out this question for pectra so let's go ahead and merge it and that was pretty straightforward next up okay so the next uh I think the

big thing here with devet 5 would be 7742 so let me grab this update and there are a number of 7742 PRS uh for the feature they've kind of been ready to go for a while now and let's say maybe like a couple weeks now ago in the process uh as people kind of dug into this there was a question about uh changing the fee Market because especially as we go to more flexible Target and Max values that 7742 unlocks uh you get to a place where the fee Market that sort of was hardcoded in 4844 uh doesn't respond in the best way so that all being said uh

there's an update here uh it's PR 947 and what we had said from a discussion at Devcon was that uh we'd have this PR and essentially make a today so there have been some comments on it uh but yeah I guess the question here is what's the consensus uh do client teams want to include this change or just move ahead with 7 742 without it

Ansgar Dietrichs: yeah I just wanted to say for for context um that basically the is like two different like

most of these changes are no way nice to have they definitely all make the fee Market somewhat nicer um and and forward compatible like we will have to do this anyway but we could also do a lot of this in fusaka um the one thing like if we end up rejecting this kind of bundle of of features um that is proposed on the pr then what we should do is at least have a minimal um um change although I think the better Target would actually be the throughput increase itself so 7691 um which just with just a small adjustment to the update flection because if we don't do this if we basically don't make that one small change which is literally one line change um then what would happen is basically after the fork now any empty

block would reduce the base feed by 21% which I think is a little bit much and because physically because because the sensitivity just becomes higher um because now basically we have six six blops under the Target in a single block um and so that would be like a 21% drop which I think we should adjust that value which is literally like one parameter change so that would be the very minimal change I think I would recommend at least doing that the other things are still nice to have but if if clients preferred we can do them in fora instead

Alex Stokes: yeah and you're talking about the update fraction like we would just change that to reflect the new Target

Ansgar Dietrichs: yeah and there's some ugliness like for example by doing that at the time of the for the Bas feed jumps a

little bit um which of course this is part of the things that would be cleaned up with this more expensive change but if we are saying we are going for like the barebones version here then we could basically just ignore that only change the the the update fraction that's a on line change um and do the the nice clean up uh in in

fusaka

Alex Stokes: right yeah so I'm well does anyone else have thoughts I have thoughts on this but

Dustin Brody: I yeah yeah uh just to some extent so one of the tensions that has come up in these discussions is this question of um incentive to propagate wobs at all and so they're obviously expensive and

getting more expensive and they're are good for the network as a whole yes but um and and so one of the and it would be I think maybe we'll say may um my what I would ideally Target and I don't know what other people think about this is actually for the Target uh price the target market to be a little more a to incentivize people to care about blobs a little more right now cl's actually are better off avoiding blobs mostly um honest validator standing against as side um and because they're just not paid enough for it to be worthwhile and then the trouble is as

soon as you get above the target it it this price ramps up fairly quickly and so that there's not a happy equilibrium really above that either which would have been otherwise kind of nice so it would be one possibility I don't know if this is feasible in this particular time frame for for pectra or if people want this is to explicitly Target um a slightly higher like just enough of um base fee that it is reasonable to for people to actually want to carry Bobs in the same way that people complain when they miss at aate or other things SN committee messages Etc right now nobody complains if they miss blob so to speak but that's a problem with blobs and

people are being brow beaten into like you know you have to have to do blobs so yeah that that's what I'm uh my my thoughts I guess

Alex Stokes: yeah I mean blobs are a critical part of the protocol so we should make sure that they're supported uh ongar has the comment here that you could have like client side basically a floor inclusion as you build um so yeah that's an option and in any case that was another yeah I mean there was another EIP for raising the floor um that's something we get into Tony you had your hand up

Toni Wahrstätter: yeah um first of all I would agree what an said um I think the nice to have

vs can be or the nice to have changes can be postponed until faka and regarding the question to put them into 7742 or not I would say we don't put them into there um and keep 7742 and anything that touches the blob base fee separate just because I think it's much cleaner that way and then we can still um put like the thing Ana said with The Blob base F fraction into the um EAP that eventually changes the blob tget and the max so that could also work and yeah I think we have it on the agenda at a later time anyway to talk about the blops and what Dustin mentioned would

basically be something new we can also think about as a nice to have when we eventually touch the blob base fee

Alex Stokes: yeah that makes sense and it does sound like a simple path forward for

Petra D

Dankrad Feist: yeah I mean it's two different things right we have both the Bas Fe and the tip and I think this like confused them a little bit but what we want is um like that yes like um block Builders want to include blobs and that's like that's already possible right now you can just set a minimum tip at which you include them it would be nice if like blobs just came with like a little bit

of a tip because they do um more like increase the risk of being reor more significant than more significantly than other transactions um like I would also be very much for like setting some minimum base three4 blobs and like um I think like it's been really obvious like uh over the last half year everyone's complaining oh rollups don't pay and uh like they don't contribute they are parasitic which is of course complete but I think like having a small um just like base fee would like end this uh annoying shade where like we will increase blobs

a little bit and then suddenly every like oh now we're not burning anything again um and like will make it a little bit more kind of a little bit smoother um so I I would actually think that it would be a great idea to to actually increase the base fi a little bit

Alex Stokes: okay

uh pus

Potuz: yeah I agree and I I think rabs also agreed that that increasing the minimum base fee is something that it's useful um unless we are always on congestion as now uh regarding the issue of like tip uh the markets with tip inclusion uh there's a bunch that are not really well

studied in my opinion one of them is the issue that tip applies the same for blobs that carry execution that blocks that don't carry execution uh this makes a huge difference for different rollups that's one thing the other thing is timing games uh even if the if the Builder has the blobs with pain tips uh as long as the pool is requesting the headers lateer enough because they want they know that they can and they do this now uh then the timing game Dynamics changes whether or not you are or not going to include blobs if you increase the limit to 10 blobs then either pools are going to start like requesting earlier and playing less timing games or they will continue requesting as they do

today and then the Builder will have to adjust the number of blobs that it includes uh so I think these two problems are need to be taken into account and they need to be studied uh if we're going to be like counting with tips as to decide uh on the blob limits or blob targets or blob inclusion even so I would suggest that we keep it to base fee considerations when we talk about the market until we understand these others out topics

Alex Stokes: yeah I think that makes sense just around gaining a better understanding of the actual Market out there and a quick injection uh it sounds like maybe from the chat people were confused so like right now we're talking about just this

one update to 7742 that would touch the blob fee Market we are not talking about raising the target uh or Max or anything we will talk about that in a second but that's very separate from these Bas mechanics we're like very zoomed in right now

uh good jender yeah

Gajinder Singh: just want to add that I mean this if we don't have any plan to update any Target before faka I mean then this PR is basically rended useless in the sense that it won't add any value but uh if we are trying to update the target then this PR is a bit relevant although we can also update Target with with some hardcoded uh uh update fraction like we

have done in 47 uh uh 4844 uh but I feel that uh this is uh this is a good way to go forward and uh maybe we can even have time based Target unlocks uh with the Paka but yeah that can happen that can this PR can be merged with other PRS at that point as well

Alex Stokes: right so I mean the question answer now is do we yeah essentially like how like what what is good enough we could do a very simple thing like there does seem to be quite a bit of demand to raise the target uh and Max in pectra and because

of that then we can ask about the fee market and this current PR is one proposal another proposal that ongar and Tony were just talking about that is even simpler is just changing uh essentially this update fraction that we have that would do exactly what we want that's like literally a on line change is changing a constant uh this one that is under discussion at the moment has some normalization involved it's a little little bit more complicated so the alternative would be to do like they were suggesting like we

just change this update fraction and then we kind of bundle this with a number of other things because as we're discussing there are other things uh around the few markets that we could imagine changing I don't think they're quite you know in the quote in-game state so that would be the idea is to go ahead and do the simple thing that works now and then uh hold you know these more invasive changes off until

fusaka

Gajinder Singh: yeah uh one thing I want to add so there are two changes in this one is normalization which uh which as you are saying is a bit more complex and the second thing is to in uh to add targets uh Target blobs per block in E header so maybe I think we should at least keep that one

well that's already in 7742 okay all right

thanks

Alex Stokes: okay so we have uh essentially a plus one from Tony to what we just described uh basically ignoring this update for now and just bundling it with Paka then inetra uh this is a topic we will get to soon uh around actually changing the Bob counts and yeah just having 7742 for that possibly with updating uh this update fraction there does anyone feel strongly about doing this more invasive change at the moment or would you rather go the simpler route

go

Ansgar Dietrichs: yeah just just to say basically like

Al said in chat to me there's three questions it's the definitely do the simple will definitely do the one simple change which is the um update fraction um and then probably it seems like the majority wants to push the bigger change the normalization um that gaja was working on to to fusaka which would then still leave the one extra decision that we have to make is um the minimum base fee change that's the one that Max Resnik originally proposed um D argued for it just now like 5 minutes ago on this call um we can also push that to um fusaka it's basically in the middle of those two it's like small but not a oneline change and also nice to have but not as important

as the other one so basically we should still if if we want to do the the very small thing and push the very large thing then we should make the an extra assessment of the do we also want to increase the minimum base fee in in Petra or do we also push that to

vaka

Alex Stokes: yeah well does anyone have thoughts I would say it's like pretty late in the game game uh because my sense is that Max dip well I guess that's the question like was Max's dip ready to go

Ansgar Dietrichs: it's almost a on line change the only reason it's not a oneline change is that we would have to basically at the time of the fog then reset the excess gas to zero so basically there would also it's like basically it's two lines it's like

in the in the the way you now calculate the excess gas there has has to be an if statement you know if it's the time of the F return zero and and and change the one value so basically like the max CP is like a two or three or four line change but my in my understanding is that that is not fully speced out I think he only spec the one line and not the the if statement

Alex Stokes: right yeah so I'm trying to ship pectra and my concern would be that if we take another cycle to get that ready then it's just going to delay things even further so I guess I'd want to sense of like how important raising the base fee would be or maybe I'll say minimum fee um yeah my sense from previous

conversations is that there wasn't like strong consensus that it was super urgent

Gajinder Singh: although the normalization with 9047 is that it will give a nice treatment to the current excess gas that is out there and make sure that when the target is updated that is uh sort of taken care of in a nice way and there is no irregularity so that is something that is there in 9 047 which could be considered

Alex Stokes: sure but then that's still a slightly different point to actually raising the minimum fee there are some comments in the chat that this is a nice to have but not

existential do we all agree to that anyone disagree I don't know D you feel strongly about this okay yeah Peter

yeah um just sorry I just joined um this is 7742 you're talking about right

Alex Stokes: well we're talking about a number of things so right now we're talking about raising the blob base fee so right now the way the protocol works is it's speced it one way and there have been proposals to raise it to some higher number

oh

okay yeah I I I feel it isn't existential but like if we're going to

do do um a version of 7742 we kind of have to because otherwi because we don't want the consensus L to have to deal with greater than

us6 FS all

Alex Stokes: right so this would be within the domain of the E and so the CL should be fine there

so I think we're forced to do it eventually because we're talking about if we do if we do a version of 7 42 this is a

preck

Alex Stokes: no so the thing that we're talking about now is essentially a number that's only on the E so the CL never has to deal with

it

oh yeah sorry now I'm confusing something else sorry yeah it's

Alex Stokes: okay no there's a number of things in play at moment uh okay so it sounds like from the chat their support to table is for fusaka the m uh just because yeah I really would like to move things forward here I think we all would and if we you know again take more time then it's just going to delay backra Oscar oh okay

sorry

Ansgar Dietrichs: sorry um I just wanted to briefly ask because we want to actually get through freeze and so if we say we go ahead and I mean obviously there's still then the next agenda point for for

the actual bub through put increase but assuming we decide to go with a blob throughput increase um then the then then that it does require this one small adjustment to the update fraction so the question is what is the timeline there what is the process there do we do that async in a PR who's going to open the pr there's different alternative options for the up update fraction I think it's insignificant enough that we can just say that we will figure that out in the pr and just go with any thing that has weak agreement over there but like how do we basically what's the timeline on that decision

Alex Stokes: yeah well uh it sounds like we should just get into that now um I think there was a suggestion just to put it into the 69 EIP which is EIP 7691 I think that's

perfectly workable so yeah Ben and then we will talk about the ball counts oh Ben I don't know you had your hand up I don't know if you

Ben Edgington: I think I think the mid is related to The Blob count so if you're not touching the blob counts that's fine but if you if the blob counts are changing then the Min fee becomes more important because it will immediately crash the market and go back to one way one way which is like a crazy small amount I mean the the way fraction is is used to be able to calculate the fractions of guay it's not used as a you

know you wouldn't launch a token on Unis swap at one way

Alex Stokes: you could

no

Ben Edgington: but well Unis swop would break because it can't handle there's no decimals further there's no you can't go smaller you know what I mean so you I yeah any I mean so if you're going from let's say you need to put the price up um where do you go from one one way or you you can't put it up by 10% you have have to put it up by 100% because there's there's no you know there's no fraction of a of a way for example

Alex Stokes: right yeah uh Francis do you yeah I guess I do want to move to

the blog counts but yeah yeah

yeah that's that's why I'm suggesting like because I think a lot of this depends on like what kind of Target we want to set right

Alex Stokes: okay yeah so uh we will come back to this next agenda item uh there is a change to 7251 but since we're already here let's talk about the BL throughput increase in Petra so to kick things off I think many of you have seen this EIP already uh 7691 which proposes raising the target to six and the max to nine uh I'll just grab the link here and maybe to kick us off uh Sam wanted to give a quick overview of some work that

uh he did is Sam here

yeah I'm here uh I think Parry we were gonna actually get par to present first and sort of combine them

Alex Stokes: okay sure yeah yeah

Parithosh Jayanthi: I'm just going to give a bit of context first um so there was concern at least in the past to um that we're going to have issues once we increase the blob count in terms of uh long range sying as well as how the network heals once there was non-f finality so in in order to collect some data we did do some uh de Nets over the weekend you can find a summary over here as well as a deeper blog post on the topic uh but the tldr is that um we're not at least the

indication from the devet is that we're not purely bottleneck by bandwidth um there are some optimizations that could help sync as well as SP performance but all of these optimizations are something we're going to need to apply on Main net today even with the current 36 limits um and at least the indication is that um even if we were to increase the lob count we wouldn't necessarily um immediately suffer that we would be able to in uh handle an increase uh in order to the question of what we can increase to I will pass it on to Sam

yeah thanks uh I'll just share my screen I hope everyone can see

that uh yeah I'm Sam from the Pander UPS team uh I just like to quickly go over this post uh I made yesterday about block Rivals home stakers and bumping the blob count um we as a team recently just started ingesting data from community members who are running nodes at home and this is what made this analysis possible um so quick shout out to those community members um so our analysis mostly focused on the case where blocks are being built locally by hakers and then observed by home stakers on the other end um home stakers are the most bandwidth constrained participants in the network um and this makes them particularly

sensitive to any increase on the blob count um so we asked three questions uh the first question was how is three Target and six Max performing today for these users appears to be pretty good um most bundles are arriving well under this 4 second deadline uh onto the second question uh does the arrival time of these blocks and and blobs uh scale with the count and yeah to the surprise of really no one it does um so onto the the third question here how can we how much more can we actually support on Main net um the long

story short is that we believe that both four Target 8 Max and six Target n Max are achievable as far as arrival times are concerned it's just one piece of the puzzle um yeah while this analysis made some pretty naive assumptions I yeah I personally believe these numbers are realistic and safe um we also on the way just forecasted how this would look with e 7623 which reduces the maximum compress block size from 1.8 Meg down to 720 kiloby um and yeah in this scenario even in the worst case scenario possible uh it's still yeah possible to do a blob

Camp bump uh that's pretty much it for this um I'll throw the link in the chat if anyone has any questions hit me up

cool thanks uh Amad

Ahmad Bitar: yeah um so one thing that I'd like to mention here is that there's also a push for raising the gas limit for the uh L1 gas in general and uh this needs to be taken into account because this raay will probably bump up the block size to around 1.1 even with 7 uh 623 um 1.1 or 1.2 mix um because like

the bump is to around the maximum of 45 million um um or something like that so might be also play on effect here

we think not bumping the blop count would be a big mistake uh in Petra because we're like essentially waiting for p times to scale blobs but that's in vaka and there's no like clear timeline on vaka um and it's already pretty apparent that from the presentation that based uh a few acds ago that they are looking at

needing more blobs on top of all the l2s uh being announced at the moment that they're also going to launch on mnet so it would be a huge mistake in in our eyes to not do anything at all we think 69 is preferable but I see in the chat that maybe 510 is easier to do and I think we'd be fine with that as well um obviously I'm an eev so from my perspective this seems pretty easy because we have 7742 now and um I don't have like a full view of exactly what changes need to be done on the seal here so I would like like some input on on

what seal devs think

Alex Stokes: yeah thanks so we do have this EIP for 69 and from what I've seen mostly in the chat over here that there's some concern that 69 is not a perfect double so yeah I guess I'd like to hear more about that uh my understanding is that really the only issues there were that it would make the fee Market you know have some weird Kinks but it's nothing existential

Tony

Toni Wahrstätter: yeah one of the issues I wouldn't even say it's a it's a big issue but if we kind of move away from the target being half of the max then what we could um end up with is the base fee the blood

base fee scaling um faster in One Direction then into another which is not a big problem I would say so 69 should would would basically work as 510 would work so I don't really see a concern there why 69 would be from the base feed perspective worse than 510

Ahmad Bitar: I mean in in the case of empty blobs you will get the base fee going down a lot whereas with full blobs you will get the base fee raising less than that

Toni Wahrstätter: so yeah this is true this is this is also one of the points that we talked previously about about those Bop base fee improvements

there's one point um called um making it symmetric again and by doing that we can also kind of account for that so we agreed earlier on that we might want to do those um optimizations at the later fork in this case if we say that this asymmetric blob Bas V update is a big problem then we should stay somewhere where the target is half of the

maxar

Ansgar Dietrichs: yeah I put I put some examples in the choices we could have so indeed with the c mechanism the sensitivity of of an empty block and a full block would be different because say for example for 69 right like you if an empty block is six

blops under Target and a full block would only be three blops under Target so we could say be very sensitive to a downside then we would have 21% maximum decrease and 12% maximum increase but we can also choose the the opposite so like 11% maximum decrease like today and then it's only a 6% increase um or anything in between right like literally this this update fraction we can literally just pick any point of that curve it will always be more sensitive to the downside than to the upside um the reason why I strongly would argue for 69 over a symmetric change is that in both cases only really the the rollups are concerned as consumers to blobs the network doesn't care about like about a slightly more flaky um base fee right

like that's only ux problem for rollups and from talking to rollups it really seemed like they they are much much more concerned with overall throughput than the ux of a slightly more um volatile base fee so basically they they would much rather have overall more more room um yeah and are not so concerned about the Bas fee of course I mean we have other concerns here right about average throughput levels and all these things but in terms of like the base fee I I don't think we would actually act in the interest of the people that we're trying to protect by by avoiding this asymmetric Bas way situation

Alex Stokes: right which argues for like 69 over say 510 because the point here is to raise the target as much as we safely can uh I think it was putus I'll just go

in the order I have on zo so

pus

Potuz: I want to give a perspective on Sam's result while it looks as though that increasing to those numbers would be safe when we are in congestion when actually blocks are needed to be posted regularly then we would be in a situation where hit on every slot the maximum if the builders are behaving correctly and then if you see for nine or 10 for limits then you're reaching a point where all of those blocks are being trying to be reared at least five not all I'm sorry at least 5% of those because the line of the 95% is very close to the 4 cents to the four seconds and this is without counting execution

without counting validation and without counting for choice on clients uh so your blocks are arriving near the deadline which is 4 seconds and we need to steal a test we need to process and we need to make a signature out of those so I would expect that at least 5% of those blocks are going to be re being reared besides the validators like losing the attestation and instability on the network if we see every single block nine or 10 my proposal would be to not do something radical this Fork move to 48 that we kind of know that we can handle uh probably 5'8 if you want to to increase the target 68 might might might work but I wouldn't increase the limit

without more measurements

Alex Stokes: okay Sam I imagine that you're in response to what p is saying

yeah uh so like the analysis was done off the beacon a event stream and the clients submit those events at at different times uh it it essentially looked at each slot the latest time for a client to admit the head the maximum blob or the block event so I I don't actually know I guess it's a client specific thing on when those events are are emitted but it's probably worst case scenario at like every stage of this and reality is that like we're we're actually way under when we say that like 5% of those blocks will be coming in

after 4 seconds that's yeah probably like a bit too much I'd say I'd say the real world picture is way better than that we've just left it there to be as safe as possible uh and this is also 5% of of like home users um not 5% of the network I know we care about home users but yeah it's just worth bringing out I think

yeah thanks than c

Dankrad Feist: yeah so um I want to say something about the limit targets I think like um in terms of predictability and everything like right now at least like most rollups like well we're seeing now

people starting to build base rollup but other than that um the timing of when rollups get their blobs in is like not very important to them because they like sequence separately anyway so I think um the the only concern about it is really the the potential economic attacks that uh that can be done like basically I think at 69 um like onethird of this the stakers could potentially just like um set the base feed to the minimum minimum and start extracting value via the tip so that's like the classical EIP 1559 um economic attack in uh quotation marks but um I just think like that this is at

the current state just like a very um very unlikely scenario and like we should just uh eat that and like basic like um as soon as we can like put it back into the in the normal range and then like um it's it's much more important to temporarily have this target increase

Alex Stokes: right so yeah I am hearing a lot of support for 69 uh I think one way forward would be 69 uh and then a simple sort of patch would be changing this EIP to include the target value that we want or sorry let me be more specific I mean the

update fraction that we want uh to help the fee markets in the meantime anyone want to argue against what I just said 69 with uh the fee update yeah Mel you had your hand raised I'm not sure if you want to respond to what I said or something else

no it will be something else okay

Alex Stokes: well is it relevant because I'd like to go ahead and just make the decision now

I mean this is slightly related to this um at probab we already have a session in Bangkok when we were discussing the whole bandwidth measurements that we

were doing uh we've been able to do this measurements from uh another regions in the the geographical location I can share the screen and show some graphs uh if there is time for that but otherwise like something that I want to raise is we are going to post this anyways around tomorrow but the idea is that the all the tendency to say that 69 it's fine it's basically on the idea that you still have bandwidth big bandwidth available to download everything like what happens if you see that people struggle to to fill that band withd like eventually you just get things worse and it's what I want to say is that it's not linear um and what we see is that from home takers like uh pretty much half of the network has less than 20 megabytes

per second and increasing the Target and the max like that could pretty much become a bottleneck when you are trying to resync stuff I think that this was also something raised by pus and nent on the Discord channel so yeah I don't know I would like to bring a bit more the concern about having such a big increase

Alex Stokes: right I mean that is definitely important data uh but it sounds like it's a little bit different than the analysis that Pand opad um so I'm not sure if there's a discrepancy there d r s what oh the hand was raised on Z oh sorry maybe yeah no it's not good uh

Ben

but

Ben Edgington: is an important Point um if the if we're running it sort of nine blobs um per block isn't that um a problem if you're also snap suddenly if you're snap serving will you start losing ass stations because

Alex Stokes: yeah I mean there are a couple things here so you know the max like we wouldn't stay at the max for a sustained period of time it'd be very expensive to do uh and then you know I guess another thing to note is that we did do some like sneaking experiments to this point and that was you know considered in the suggestion uh from Pand Ops around their

work for 69ine so my understanding is that at least with respect to the work they did they feel is a safe to do

what is

Potuz: I think there's a misunderstanding in the chat regarding timing games um and how Builders will react to the co the the cost of like the probability of rears of their blocks by including more blobs it's not so easy that the builders are going to now charge more tip and then they will include those blobs because they might be more likely to be reared but the the situation is that the proposer doesn't have a visibility over this so the proposer that is currently requesting the header later enough makes that decision so if the pools are

requesting late enough then the Builder is forced not to include blobs even if they will if they would include blobs with a higher tip they would not when the request for the header comes already late so this is not a this is a matter of like the chicken and egg and and I think people should keep this into account when they are thinking about higher limits

Alex Stokes: sure but if this happens then you know the blob producer would start paying a higher tip the Builder is more incentivised to include them the propos no they

Potuz: are not because the header comes late that's the point the header all the request for the header comes late and the Builder doesn't have a control over this the pool requests from the builder

at the time that the pool decides if the pool were to like start adjusting their timing games because of this extra tip that could be something but the the thing is that the pool doesn't have visibility over these numbers

Alex Stokes: but the Builder would have already made the block with the blobs in it right

Potuz: at the time the Builder would change the header the according to change the block according to when the header is being requested if the header request comes like 10 milliseconds before 4 seconds The Bu Builder would include zero blocks because they know there will be

reor

Alex Stokes: okay so I do think timing games are

relevant to consider here that being said um let's zoom out a bit and circle back to my question so 69 for eight okay so there's okay Oliver

I just want to quickly ask um I I know like obviously this is very late in the process we want to freeze pectra and all that U what is the potential delay here and is there anything uh my team can help on alleviating the delay like I would imagine it's mostly

testing correct or incorrect

Alex Stokes: I think that would be most of it and just any analysis you know that we can squeeze out of the network basically MH okay okay Terence

Terence Tsao: so I'm not aware of any consensus client team they has implemented in a way that you hard for to a different block number that the Max and Target are different so we're working on a PR right now I presume other consensus layer client team are working on PR right now so after that's done we need testing basically but yeah this is something new to us

Alex Stokes: right which is what 7742 introduces

so it's not really a surprise but it is new okay so right I mean I guess there are some there's some demand to consider 48 over 69 I think we've nered it down to at least those two from there I would lean towards moving ahead with 69 again just to provide the most bandwidth rollups that we can and you know if we are a month or two down the line and have some reason to think 48 is better we could always change that um because what we can start doing today is everything around you know this change 7742 and every any fee updates the

actual numbers will you know ultimately be a configuration change so it is easy to scale back down you know if we really feel like we need to so do we feel okay moving ahead with this with 69 and the fee update okay well just going off the chat there's support for this so let's do that and I do think it is important to keep doing analysis here if we find something that is really going to change our minds uh we should definitely discuss it as soon as we can Okay cool so I had another note here which is you know let's live in this

world where we're doing 69 do we want to include 7623 um I really think at this point we should only be thinking about things for network security uh for pectra so for example you know I would think it would make less sense to talk about raising the base fee for the Bobs or sorry the mint fee for the Bobs uh but this one actually impacts like worst case block numbers so I think it's at least worth discussing uh yeah Tony you have something to say here

Toni Wahrstätter: yeah quickly about 7623 I think we should um ship it together with the bluff increase um This was um the plan for 7623 for quite some time now so if you remember it was um CFI for months now um because we were always unsure if we will ever touch the

blob count in pactra and without touching the blob Target 7633 wouldn't have um had that impact really because now the actual median throughput will increase with the target increase and 7623 only touches the worst case scenario so I would argue that with the increased um maximum block blop count we should also decrease the maximum possible El payload just in order to make sure that um on the L side we cannot have like almost 20 blops in size while we are um discussing like one or two more blops on the

SE

Alex Stokes: right that's a good point I will surface uh this comment in the chat from like client I think this is probably the main argument against 7623 and pectra is just that it adds more things to do and there's already way too many IPS uh we just had a pretty bad bug on Mong so it's not that you know it's not that we like are super ready to go and this is just like a marginal ad it will add complexity to you know the whole fork and yeah we need to make that decision carefully uh I don't know like client if you want to add anything to your comment

Lightclient: I mean yeah I think we need to ship pcture

and I'm just worried about adding more stuff when I don't think that we have super high confidence on either the e or the C about what we have already committed to shipping in this for and onar saying this is an active security vulner ability but no one is actually taking advantage of it so I don't really think it's that big of a security vulnerability should we fix it at some point yes but I see not a strong reason to fix it in the next

for

Alex Stokes: yeah there are a lot of emoji reacts to his message though um anyone want to say something else to

7623

yeah if other people doing Emoji reacts uh maybe two or three of them should unmute and showare that perspective

I think this is

the point that has been made multiple times but well we cannot safely increase the number of bloves without decreasing the maximum possible size of the

block this is my reasoning for adding the Emoji reaction

Ben

Ben Edgington: if we're worried about increasing the gas limit because of 7623 and you know you're compounding it with increasing the blobs if you don't have it in it's the same issue

Lightclient: so then why did we agree to ship a blob increase before agreeing to do the thing that apparently is the prerequisite for the blob increase like now we're kind of just giving this as a writer because we agreed to do a blob increase and we're just saying that we should you know it's a prerequisite we have to do it

to

Alex Stokes: I feel like it's always been sort of

in The Meta at least over the last couple months so this is just now the time to discuss

sry

Toni Wahrstätter: yeah no I just wanted to say the same so it was always kind of bound to the to a potential blob increase or a gas limit um gas limit increase which is also still in the room and yeah for that we were basically saying now for months that um 76 to3 will be kind of this measurement against um yeah any dos attacks that might originate from scaling um scaling everything up

Alex Stokes: okay so I'm hearing a lot of support

for 7623 along with the blot increase so let's go ahead and move forward with

tost post

Lightclient: guys we're adding three eips in the call after we just had a three Fork testnet bug

Toni Wahrstätter: um it's two eaps right it's the blob increase and 7623 it's the

Lightclient: blob increase 7623 and the fee change

Toni Wahrstätter: but the fee change is in 7691 because it's basically only yeah

there

Lightclient: discussion about putting in its

own EIP so yeah you know we could put these all into one e but these are like three conceptual changes

Alex Stokes: yeah I mean I would like to decide today however I think there's grounds for making a decision on this uh on next week's acde because this is primarily an change I don't know what would change in the next week though uh Francis

I want to provide a like raw data that I collected uh for like 7623 so although the serotic like uh

block size limit is 2.8 megabytes now from my kind of like analysis over the like like last month or something the p9999 block size is like well under the like 700 or 500 kilobytes so theorically this could help uh but it could be like in in the real world you could not it could be like okay it's not that big of a deal but I think it could be helpful to include that if we are worried about the worst worst case scenario

but you'll be

Ben Edgington: you'll be running

for uh because of the BC being one way you'll be running an hour at nine blobs per block before it gets to anything that's even remotely pricey um so then you're opening up plenty of time for somebody to start sticking in vast um Siz oversized blocks for no purpose just for fun

Lightclient: okay what is the failure case here if someone does do this like I haven't really heard it compelling argument for what actually happened to the network

like you don't kill the solo stakers if this happens so are they offline for 10 minutes are they offline for three hours can you kind of keep them offline or like very low participation uh permanently what's

the I mean you

Ben Edgington: you won't pay the gas for the block that didn't happen so you can keep putting it back in

could

Lightclient: don't think that there's that much of the network that's going to be negative affected this like we're talking about like the bottom 5 or 10% validators

Ben Edgington: from what is it 13 megabyte blocks

um the addition of nine blocks 13 megabytes uncompressed

Lightclient: like what's the compressed value the compressed value is like 2.5

Alex Stokes: okay I would like to make a decision today and there's some chat to that end uh I would lean towards including this myself it sounds like only like client is the one opposed at this moment um okay I mean that being being said I

do feel like we probably want El's to like have signed off on this because they're going to be the ones implementing it so that does really motivate pushing into next week I guess does anyone oppose that the downside is just we have one week loss of you know a spec freeze Yeah Tim saying 69 today and then TBD 7623 next week and yeah that's the suggestion

I'm happy or

Alex Stokes: some thumbs up

okay lots of Thumbs Up cool okay great so let's do that and yeah uh if you're here Andor if you're an e client listening to this please have a view for a CD next week cool okay uh thanks everyone for that there is a lot of discussion there but it's a very important topic I think that's everything on the blobs we wanted to touch on today let's Circle back to this item that we skipped over with the sequencing of the agenda so there is a PR to update how consolidations work uh under 7215 and

yeah um basically so I think where this is coming from is that the way that Electro is scoped now you could essentially trigger consolidation for any validator not just the ones that you control and that's weird uh you know you it would be a very expensive attack but you could imagine someone you know is wanting to troll some other validator uh and basically force a consolidation on them so there is some back and forth on ways to address this and uh we go to this PR for 420 uh M I'm not sure if you want to say anything else uh this is from you uh in any case uh yeah it looks good to me I think we should go ahead and move

forward with this um and yeah I would rather go ahead and agree to this today rather than wait another cycle in the interest of a spec freeze yeah so yeah maybe just maybe just add one more comment from what Franchesco said it would cost you your stake so it is a very expensive attack but it could be on right

Mikhail Kalinin: you still can do consolidation uh so but what this is about yeah yeah sorry

Lightclient: sorry go ahead

yes

Mikhail Kalinin: there was a concern that could go some so basically this PR prevents um the target to be uh switched to compound in so if it's

compound and the anyone can do consolidation to the Target and the concern was about um that anyone can switch any validator to compounding credentials s that can have some legal implications and some jurisdictions so that's that's one of the reasons the other one is the we have just this uh in in in this place the like there is the way to switch to compounding upon request and uh in protocol we have uh this automatic switch to Compound on consolidation 2 which a bit of qu in the design so we're just removing that as

well and yeah that's about it and also um yeah there is the um the ux tradeoff so if you want to consolidate your value you will have to first switch to compounding Target and then do consolidation this is going to be two different requests and u but that's not a big problem because if you have like say 10 Val to to consolidate you should just do the switch once and yeah then send those two 10 messages 10 requests for consolidations if you're a soul Taker and you have just two validators you want to consolidate them then it will result in two messages instead of just

one as existing logic so it's not a big um reduction and also um to a bit alleviate uh this ux thing um I think we should increase the max consolidation requests to to two instead of one so we can basically switch to compound and then do consolidation in one block

Alex Stokes: yeah I think that makes sense and I guess one other point here is like this does actually simplify like the whole state transition just just thinking about about their life cycle States and how you Transit between them

uh so I really like that there was com here

Lightclient: is the compounding just get set today by whenever you have something as the destination of the consolidation it becomes compounding and problem is is that you can set any Target without authorization from the target

Mikhail Kalinin: yes one of the concerns come from that

Lightclient: so now you're separating the compounding from consolidation

Mikhail Kalinin: right so you cannot do you will have to to authorize the compound

and switch first before doing consolidation

Alex Stokes: yeah I'll just voice Francesco's comment here it is a very simple change and I think it does simplify things quite a bit which is nice

oh

Lightclient: do you authorize it ahead of

times

Alex Stokes: how do you sorry what was that

Lightclient: like today we authorize consolidations by looking at the like using the message. sender comparing it to the E1 credential is it going to be like that again or is it different

Alex Stokes: no

it's the same okay

Lightclient: sounds good to me yeah

Alex Stokes: yeah this just restricts what you can do okay so I think the people who have looked at this before this moment are in favor uh and it sounds like there's yeah simp support on the call as we talk through it uh anyone want to avoid this no move ahead otherwise I think we go and do it forra okay great uh I

believe let's see yeah so it does need Tes still but yeah this is something that we can get to the next release and uh yeah Mel I can help you get this tidied up ASAP so we can keep things moving cool

Mikhail Kalinin: yeah also requires the update to the consolidation smart contract to bump the max value from one to two but it's to real change

Alex Stokes: right okay yeah we should track that it is worth noting that it's okay if that doesn't change in the smart contract it would be nice if we do it it's not the end of the world cool so let's see I think that was

everything for the next devet spec and should have Petra in a pretty good spot um okay we don't have a lot of time left so we'll just keep going okay I guess were there any very quick updates with pios or anything any du nuts there my sense is that they've kind of been waiting for uh pectra to settle down

Barnabas Busa: exactly so the idea is uh that pust is going to launch once Spectra DEET 5 is is uh stable and then everyone can Reas their code I I think most of the Cs are already working on a PS rease on top of pectra so we didn't want to complicate things by launching some very old

pack

yeah y

Barnabas Busa: the same true for E Dev Nets by the way

Alex Stokes: okay great

Barnabas Busa: they both uh expect to arrive one Spectra Dev 5 is stable

Alex Stokes: okay sounds good thank you

Barnabas Busa: and for picture Dev uh then we can probably calculate with the 69 change already right

Alex Stokes: yes yeah so D Net 5 would be essentially the final exor spec

can we confirm the scope of the next I mean the pi defni five right now we talk about many sounds like

seven

Alex Stokes: it sounds like 7623 is still up in the

air for next week um I did want to leave some time for the other agenda items but yeah I guess are there any specific questions right now shall we

do we have for the co update do we need to wait for this discussion before we CAU the release

Alex Stokes: not for 7623 that's a good point so let's see right so from this list on this issue uh 7691 which is the blet increase that would need an update for the Target or sorry I keep calling that the update

fraction uh let's see do one of the authors want to go ahead and handle that change like Perry Tony Sam Andrew some of you are here on this call okay we Le got a thumbs up from Tony so yeah if we could do that like I mean today's the holiday uh for some of us but yeah if we could do this like in the next day or two that would be great okay says he's writing one right now perfect uh cool so otherwise yeah this list uh looks pretty good shall we this issue 426 uh I can follow up with you after and we can double check everything if

that sounds good cool okay okay so I think that was everything on Petra Andor pios to discuss at the moment uh again very nice work everyone I'm getting to this point it's been it's been a big one um yeah so now let's keep moving to the agenda uh next up we had a request to discuss another EIP uh 7805 which is fossil and this is a solution for C resistance uh let's see so I spoke are you on the call

Thomas Thiery: yeah yeah I'm here hey

Alex Stokes: yeah uh yeah take it away

Thomas Thiery: hi thanks I'll share my screen

Alex Stokes: it only shows like the upper quarter of your screen for some reason

oh

Alex Stokes: I'm not sure why

Thomas Thiery: does this work

now

Alex Stokes: uh it's better yeah I think this is everything

Thomas Thiery: yeah okay I'll I'll just start uh yeah uh thanks uh for letting me present uh this I'm Toma I'm a researcher in the robust incentives group at thef and yeah today I want to talk to you guys about EIP 785 805 which is on four Choice inclusion list short is for so yeah I don't want to take too much time so I'll Dive Right In and just give a quick uh context but uh yeah proposal Builder operation was kind of quite successful at keeping the

validator set relatively unsophisticated and decentralized um I think but uh Builders have become like super super centralized on the other hand probably more than we expected and so today we rely on like literally two very sophisticated and centralized entities to build more than 90% of all blocks and this is obviously like super bad for sensorship resistance properties because now those two entities can basically arbitr decide what transactions get included or excluded from almost all blocks and so for example like a couple of months ago you have like a major Builder that just decided to stop censoring some transactions and for some

reasons that are actually still kind of unknown at least to me and we got like this huge job in censorship out of kind of nowhere and so yeah it's directionally good in this case but it also just kind of shows how fragile uh CR is on ethereum right now and so you guys um know about this but one good way to drastically improve like the sensorship resistance properties is just to use inclusion list and just to say it again the very basic idea is uh super simple it's to let the decentralized set of a of validators Define a set of transactions that must be included in Builder blocks for them to be considered

valid by a testers and yeah there was like a lot of research done in the past couple of years uh on inclusion list obviously since there was even like EIP 7547 that was considered for inclusion but it was then rejected because of some issues regarding its compatibility with account obstruction and high equivocation um but there was also some like really cool and relevant research on block Co construction by multiple parties or the concept of view merge for fork choice and so we took kind of inspiration from these different research threads and came up with fossil which is actually like a very simple mechanism and that allows multiple

validators to propose inclusion lists and co-construct a template Ro block made of transactions that have to be included in Builders blocks and so we kind of think of it as like a very important step forward because fil what actually allows to give some power back to the validator Set uh and allows them to like reclaim some control over block production and reintroduce some kind of neutrality at the protocol level um another like important aspect worth mentioning is that fossil can also kind of be seen as a way to boost the signal provided by the solo stakers so today if you assume like there are like

6% of toal stakers we have to wait quite a long time like 17 70 slots on average I think before a block gets proposed by a solo Staker and we cannot like rely heavily on solo stakers to ensure like the censorship resistance properties of the network or like that censorable transactions are eventually included and with fil like still assuming around like 6% solo stakers uh there will be like a 63% chance of at Le one solo St being in N committee if we had like 16 I committee members per per slot um and so yeah it here's how how it basically Works uh there are like three

main step uh that I'll just briefly described the first step is about building and broadc broadcasting ILS so each slot you have 16 validators that are randomly selected to become I committee members and each of them will just like monitor the public M Pool and include transactions that are pending there in their ILS up to 8 kilobytes which is about 40 transactions per per a if you take like the medium transaction size and then they broadcast their is on the global topic over the CL P2P Network and what validators and like ATT testers have to do is just like monitor the P2P Network and store uh store ILS that are

broadcast until the view freeze deadline which is at 9 seconds into the slot and yeah basically at this point they keep for forwarding IL but like stop storing ones and in the Second Step it's about what the like the Builder actually including I's an i transactions in its Block in its payload so yeah the Builder will do just like the validators and will collect and store is but it actually has additional time after the view freeze deadline to ensure there is enough time for him to see all the available ILS that were broadcast by committee members and so about like like around 11 seconds into the slot so two

more seconds after the view free headline the Builder just basically takes the union of transactions across all its stored ILS and hecl he includes them in the the the payload before the full block is is then like just proposed to the rest of the network by the proposer and the step three is how it's enforced so at test will do exactly the same they will take the union of transactions from is dist but in their case until the view free deadline and then they will check whether all these transactions were actually included in the blocks execution payload that was proposed and this is kind of where the for choice and force comes from because that tester

will only vote for the block if it satisfies I conditions according to their View and yeah I I'll go quickly but I want to highlight like like fil core properties I guess the first one is that ILS and the payload are actually built in parallel and they only kind of need to be merged together towards the end of the slot so that's quite nice because it provides some almost real time sensorship resistance having multi proposers make makes also like really robust to Commitment attacks but it also actually um allows us to get like a super nice one out of an honesty absum so we only need one I Committee Member to build its

IL honesty and just like include transactions from the M pool without sensoring for the mechanism to work um and then we have the conditional property that just means the Builder must include all all transactions but until the block is full and the Builder is also not constrained on where I transactions uh or the order of I transactions in in it blog and so these two last properties are actually quite important to just prevent ILS from being proded out by me transactions like imagine if there was some dedicated block space or like if I transactions had to be included at the top or end of the block then we probably have seen something like IL boost emerge but in

the fossil case like transactions have like no ordering guarantees and they must be created before the Builder actually has the last look and bu it's the full payload they're also broadcast publicly so there is really no point in trying to include like valuable or Meb transactions for so um yeah and all are all these are I'll just mention them quickly because it also addresses like some issues that were present in like the previous uh proposals there is no 3da problem because in our case I stay on the cl2p network and they never go on chain um we've thought about like handling scenarios in which transactions can be invalidated we made sure it's compatible

with other eips those that are like considered for inclusions and others like abstraction eaps and P and epbs um we we handle I equivocation uh I already said that but it's quite robust against commitment attacks so bribing and extortion because we do have multiple validators uh and multiple I committee members uh and against fling fling attacks and yeah it's also like critical like if you want to move towards like a APS so a test proposer separation um it's it's actually critical to have a mechanism like forel to ensure there is validators that are unsophisticated and decentralized

involved in like building these row blocks uh before moving towards a world in which we might want to sell off uh execution proposing rights to sophisticated parties um and yeah finally I just want to say that fosil can be seen like as a core mechanism to enforce chain neutrality and improve censorship resistance quite drastically but it's also like quite well suited for extensions in the future so so far we've thought the most about extending fil for BL and transactions because like that's very obvious but we are also actively researching how for example to properly reward IL committee members if we wanted to do so because in the current version We rely on altruistic beh Behavior or how to

secretly select uh I committee members so they can contribute to the mechanism with without actually revealing their identity which also might be very useful and all of these are like yeah super exciting research direction that can extend fossil to give even better censorship resistance guarantees in the future um so thanks everyone for listening um and thanks to all the the authors of F and we just released today uh censorship resistance website using ens and ipfs for resources that are related to Fossil so it's called mid fossil DOL so check it out thanks

Alex Stokes: cool thank you uh yeah I mean

it's really exciting to see and especially like the history of research that got us to this place uh I guess one question I have that might be relevant for people here is if you thought about implementation at all I don't know if you've thought about prototypes or anything like that toy the EIP

Thomas Thiery: yeah we um so we we like opened thep a few weeks ago and now jihun that Al that's an author has starting working on a GU implementation that although that's quite recent uh teren uh is also planning to work on a prism implementation but that's like that's a great problem because like anyone who's willing to work uh with us on this we

like pretty active and we are looking for for other people to help us uh on the implementation

site

Alex Stokes: cool awesome uh yeah we will not get into future Forks today but uh this is something definitely everyone should have on their radar uh we only have a few minutes there was a question here how does fossil work

with epbs are there any caveats to us with epvs or F fossil anything like this

Thomas Thiery: no um so we discussed uh about like the potential

compatibility with thepbs uh and it is about like timing things right so we allow for enough time for for deadlines and and view freeze and like everything to to like not to to each too much time for for each of the proposal to go together but it seemed like it was actually like quite compatible and that we can make it work uh so we had like a lot of back and forth discussions uh in the inclusion list uh channel on the R&D e R&D Discord so if we want to check it out you can and happy to like yeah work on this even more once like I don't know maybe we have also more clarity on what

gets included or not

Alex Stokes: cool okay well we are actually at time now and yeah I think we'll go ahead and wrap up um I guess I'll ask are there any closing comments very briefly otherwise that will be that

um real

Tim Beiko: quick yeah we didn't have time to get to it and it's fine but I had some uh ACD process stuff on the agenda if people can review those before next week's call um and leave any comments I think that' be great um yeah just posted the link in the chat cool

Alex Stokes: thanks time um great okay then uh nice call

everyone I think we made a lot of good progress on pday and I'll see you next time

byebye thanks Alex bye thank

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.