All Core Devs - Execution #198

Transcript

oh [Music] [Applause]

and we are live uh welcome everyone to acde number 198 uh bunch of pectra related things today then um some EIP updates and new eips to talk about and then uh if we have time there's a couple more CL related topics that we also put on the agenda um so we'll see if we can if we can get to those um and before we get started uh we had this request out for audits for the Petra system contract so the proposals are closing tomorrow um if there's anyone who still wants to submit their proposal um yeah this is your last day uh today and tomorrow to do so

posted the link in the chat here but it's also on the agenda um and yeah uh on Petra itself um I believe there's a clpc release for devet 4 um any other updates on overall Readiness and where we're at there yeah hi everyone uh so I'm taking over from Bari while he's on holiday so for devet 4 we have a this spe list uh right here I just linked it in we have a couple of more open uh issues that we should probably discuss during

the call today but uh it looks like we we managed to close quite some issues throughout the or quite some PRS throughout the best week so I think we should be good to go we also had alpha 8 release uh just yesterday I think yeah um let's go over the issues now I know maybe BLS was already on the agenda um but yeah uh do you do you want to go over the ones you think are most relevant right now we had the update the submit pool

attestation V2 endpoint uh 472 okay we haven't got an update on this in in a while so I I would just like to make sure that we want to include this and if we do then maybe you can merge that in um does anyone know Alex are you saying that we do not want to merge this in basically uh yeah for 472 so I think for this it's for a different CL PR uh that we at least that we put into to a later

devet okay so we can emit this one from devit uh yeah perfect I'm pretty sure that's what's going on okay so uh we can admit this um and then uh if we scroll down uh future hard for future devet so uh on the CL spec uh okay we we have this one so I think we're good then on the CL spec and Bon API is unless I'm missing something um and then on the execution API uh we had uh like client already put this uh

this one on the agenda but the uh for request 575 on the execution API um yeah don't know like C do you want to give some context on that one I think H has been working on this I don't know if you wanted to just quickly mention the changes yeah I can screen share too if you need but um it's essentially the same as 4844 minus the blobs and plus the authent the authorization lists um the links in the

agenda as well so and I guess given this is like an API scheme do we want to block launching the devet on this or um yeah I can say that we need to get the 7702 changes Upstream to a few places okay uh before we can merge this so I would not block on it but clients should be aware of the scheme and this is a good time to raise any concerns with the formatting right

now okay uh anyone have comments now otherwise we can uh Point people there to review a synchronously um okay if not it seems like there's a CL uh PR that uh was marked as merge but that isn't um uh 3900 separate type for an aggregated Network at the stations um I don't know if we have the right people here to to make a call about this one but any updates or um yeah things uh people wanted to flag is this something we want for devet

4 no so yeah this is the one that wased with 472 so yeah this is change to the attestations along with I always forget this number I think it's 7495 is that peros anyway uh the at the station EIP and pectra uh this would go with that but when we discussed uh this might have like more code change than it appears and then we want to evaluate that against timelines for Petra so what we said was we'd give another like ACDC cycle for client teams to take a look point being it would at least be devet 5 uh definitely not devet 4 okay sounds good

um okay and then on the El side uh there is one last uh open PR which is uh 8 uh 8949 um that changes uh bunch of VIPs based on how we adapted the request format um yeah like kind any more context you want to share on this um I don't think there's anything that people care about here other than

just making the request eips match the new formatting for 7685 CU before request data referred to a single request and now we're using request data to refer to the output of the system contract so that's just updating that but the other changes have already been made to all the eips for the dep net so this is kind of um this is yeah not really changing any Behavior okay so I guess can we just get this merg in the next day or so if there's no comments on it

um okay and I think that's everything that was open or like uh under consideration for devet 4 um anything else I'm missing barnabus oh Andrew um yeah Andrew has a question yeah um yeah I have a question uh I'm slightly confused I think there was a proposal to remove a request from blog body but uh I see that the corresponding um change to EP 7685 was closed by light client um oh it's okay suid yeah that's the pr we just talked about yeah

ah all right so but like does it mean that requests like that blog B is are no no longer contain requests and you just want to clarify so areest removed from they're removed okay okay good okay sorry Barnabas you to say something yeah so I think that that's it

for D 4 uh I'm curious about uh client implementation Readiness possibly we could uh talk about timelines for launch of this dep net I think there's one last thing and yeah since 3 is not finalizing right now we should maybe talk about this first okay so yeah let's finish just spec discussion um then talk about Dev 3 and then we'll talk about de 4 launch um one other thing so uh L Cent has a comment and then it's also worth talking about

the BLS pre- compiles and you know whatever one those changes that I'm eped for um but yeah m c yep so there were some changes to 7702 in the last couple days one of those was uh fixing up the serialization 4772 authorization to pull elements so we restricted the sizes to the values that we had pre previously discussed but one thing that sort of fell out of that was we had a serialization requirement previously that the um forget I think it's the S value has this EIP 2

restriction where it's um half it has to be on the lower half of the valid range and this exists in transactions today to avoid this transaction hash malleability and we sort of just pushed it into the authorization Tuple list because that's how we typically do signatures and there is now a question I didn't necessarily intend to remove it whenever I updated the spec my intention was to keep that check but it sort of opened the question and you know Kim mentioned that it doesn't seem it's necessary to have this check for the signature in 7702 for the authorization toles because you don't have the same transaction

malleability issue if you were to have another if you were to change it to be the same valid signature just on the other end of the range then it would actually change the entire transaction hash which would require the outer eoa to resign Etc all this to say I'm indifferent to what we do here I think if people have any feeling one way or another I'm happy to go with it uh I just had kept I had the intention to keep the bound check on it just because that's how transactions are typically signed and verified against but if there the re there the reason that it exist this for transactions is not necessary for here so it's just a question do people want

to be consistent with transactions or is it okay to have it slightly different and closer to EC recover as it normally is in the preap pile anyone have thoughts comments about this um if not should we move this conversation to uh yeah the R&D Discord um and yeah maybe give people a bit more

time to to think through it yeah I mean I think barring any comments here I'm just going to add the check back in since that's how tests are and if has a feeling that we should change it for devet 5 let's do it but I don't really see a reason to block anything else related to devet 4 on this okay so you're going to add the change back in and we assume that PR is part of De four correct um yeah okay sweet yeah so yeah just I guess uh send Barnabas a pin uh when you have that PR up so we can track it but sounds good um and okay so while we're talking about spec changes um yeah there was uh

some updates around uh the BLS pre-compile pricing saying that their uh the mole uh promiles still are like underpriced and then uh a PR open to uh potentially remove them um do we have author on the call yes yes I'm yes hi okay yeah hi PA yeah want to give context yes uh so I think uh this this these requests are not actually related uh the biggest issue we have is that the the gas price for uh multiscalar multiplication one of the precompile in

BLS uh don't fully match the reality of how the implementation works and to my understanding this is because uh this discount to the multiscalar multiplication uh some like table which says how cheaper this supposed to be based on the number of points you get in the input it kind of makes the the general cost Trend sublinear and but at some point which to my understanding is that was done after this initial gas cost were

proposed we also added um a subgroup checks for the inputs which is kind of linear Factor because you need to do the check on every point and this linear Factor actually quickly relatively quickly dominates the the total cost so to my to my implementation which is based on blst Library um around 100 120 points like half of the time is spent on the subgroup checks of the input and the other half is actually spent on actually doing computation so that's that's more less

how it looks like um and I think there was number discussion number places if do we need this sub group checks and yeah there number of opinions I don't have strict opinions about it uh but I think that's like the the most pending issue we should uh resolve um I I can speak for um NE mind on this um so we ran some native C benchmarks um and these had much lower variance than the um the state tests

and they also agreed that the um with the results that um the MSM pre- compiles steam underpriced um but without the subgroup checks they seem okay um so I think one possibility is to have uh to increase the the cost of the normal MSM and uh check and then have an alternative version without the subgroup checks uh because I think in a lot of cases um you might already be confident that the points are in the correct subgroup so you don't need this overhead um so we could have a cheaper version of the pre-compiled um without the subgroup checks um yeah so I mean this would be sort

of like an an unsafe version as if you did call it um with points from outside of the subgroup it wouldn't be guaranteed to have the same result um so you'd have to be careful about when you use this version um oh yeah and also I saw that evm one team made another proposal to um remove the uh multiplication pre-compile um and generally we would also support this as it it's just redundant as the same functionality is covered by MSM uh and if we were to add a nons subgroup check version then this would just simplify things a bit and we wouldn't have to add even more pre-compiled we only have to

add two for MSM and uh the pairing yeah from a basic perspective um we did a lot of benchmarking um specifically with the uh proposed discount table bump uh and with subgroup checks uh obviously uh and we found that when we're using PPP Anders uh the discount table gives us a pretty flat um price uh distribution across different pair counts uh but we did find that G1 MSM was still underpriced uh and and G2 MSM is overpriced at least in comparison to EC

recover so um in order to kind of bring those into parody with uh EC recover um we we found that bumping the multiplication cost from 12 to 19 on G1 MSM uh brought that in line with uh EC recover and dropping the G2 MSM multiplication cost from 45 to 33 kind of just gave this almost flat uh kind of parity with the cost of UC recover um one other thing about the uh removing mole um one of the kind of idiosyncrasies of our implementation is that we initially started with a non-pi Anders version of MSM and found it for

single pair counts or low low count uh pairs that we it actually performed better than pingers so if we removed mole um I think at least in basically what we probably would do is just kind of intercept the single pair count uh MSM and and not use Pinger specifically that but I it seems like we could remove mole and and the notion of having a non-s subgroup check version seems like maybe we could um reuse those pre-compile addresses for a non-s subgroup check version thanks uh

pus po disappeared um sorry so an advantage of having the separation of the subgroup check and the the the the linear combination is that there there's different safety me safety stretchh hold that you you may have in an application some applications may not need at all and even those that do need there's two scenarios you either need to check for every one of the points that you're summing up or you need to check only one that you're adding so it means that uh you can check on the total sum and be fine or check independently each one of them and be fine and I'm sure there's application for all of these things I I

don't see any reason not to include them separately that's an interesting notion you're saying like have a G1 and a G2 subgroup check pre compile yeah just have them separately and then anyone that actually needs to uh to call this uh linear combination with the sap check just check it and there's some that might want to check it before doing the linear combination and some that might want to do the check only after and just check the sum and and and this is something that we are I mean this this of course for contracts but this is something that is actually happen happening on the CL there's a lot of times that we have a linear

combination that uh that we don't do the the subr checks at all okay and then there's yeah some comments in the chat about you know maybe we could do this as an input to the pre-compile so either it has the subgroup checks or not um and then um and then yeah whether or not we want the same number of pre compiles I guess my sense here is overall there are still things to figure out um on this so I would lean towards potentially not making these

changes for devet 4 um unless someone feels it's it's urgent to do so um but yeah like I I think if we can try to work out uh this the spec on this in the next couple weeks um yeah we we shouldn't block that on that and just yeah I guess one question I have is like what's the right um what's the right Next Step here do people just need more time to review this I think um should we have a call specifically focused on this and trying to go more into the details yeah any strong opinions there uh

RC yeah so there is a one additional thing to add here because uh this subgroup check uh now guarantees that you can use um you can use the the additional optimization in the algorithms uh which is the using of the endomorphism but um but so if we remove this subgroup check not sure what would be the results for for this kind of algorithm uh when the points are not guaranteed to be in the proper group but uh yeah this this is something which should also be considered here and I think the issue there is that different libraries might Implement

different algorithms for this and so if the behavior is undefined if it's not in subgroup then that might lead to some consens issue on some point because they behave differently we we might not know yeah exactly but on the other hand on the other hand from The Benchmark it looks that basically this this uh this pre compiles are kind of useless for many points because the the cost of the subgroup check and exactly the the case which pus already mentioned about algorithms which by Design uh guarantee that uh that the input is in the a proper sub group doesn't need don't need

the the check so so in these cases the these PR compiles won't be won't be useful but absolutely I don't know how how exactly this promiles are going to be used uh yes Kev um so I think the subgroup check is mostly useful for the G1 M for msms most implementations I've seen don't use the this optimization that we're talking about uh just because it's not that useful for after a certain threshold uh so gar for example just

doesn't use it but G1 M they do use uh this optimization that we're talking about uh and I guess if we don't do the subgroup check uh then G1 M would probably increase by a 2X um so yeah I guess uh there's a comment in the chat by Alex about potentially having a breakout if we can get all relevant people on the same call um

would it be realistic to try and do a breakout uh on Monday either before or after the testing call um if not you know potentially making that the focus of the testing call I'm sure there's other stuff as well but like um okay people seem to be available at 15 UTC so um okay let's do 15 UTC Monday uh breakout on this um I'll put up an agenda um put up an agenda for it uh right after this call um is there anything else I guess before we um before we close off here that people feel we should discuss on

the BLS pricings or additions or removals of contracts okay so yeah let's try to iron this out on Monday um and then we'll see uh yeah how big or large of a change it is that we need to do um and yeah thanks everyone for spending time looking into this uh over the past couple weeks I think this was the last devet for spec uh issue um and then yeah we'll see whether not we add this based on complexity but is there anything else around devet for specs that people want

to chat about okay if not uh devet three um we're not finalizing right now um yeah anyone had contexts or things they want to bring up around this we're running an older version of G uh deploying the new version now and seeing if it will recover so G was the only one that had an issue yes okay it was like a super majority of the de is that why it let it oh it is barely over 30 okay yeah I see um okay nice and we have some other

validators that also not attesting and that's why we just went under finalization G on its own shouldn't have breaken the network okay and so the other validators um I guess we we need to figure out what the issue is with there with them uh we so ejs is the other one that uh that is not able to follow the the head of the chain but that is known uh we're going to exit those validators and we have some big deposits that we had made in the beginning of the devet and we're going to exit those vators also so we should be able to reach very close to 100% participation nice and I guess is

there anything else we want to be testing on there net three uh aside from this G bu fix um or assuming that works are we happy with things we're at and uh ready to shift our Focus to that 4 I think we should be good to go to proceed to D4 okay um and in terms of implementation yeah um you know BLS aside because that's still an open question but I'm curious how yeah how much work the teams feel they have to do to get the Readiness for 4 oh and yeah Mario maybe if you want to

start with a testing update yeah of course um so I think uh all the spe changes are uh that we needed to update test already so it's just a matter that of we finalize the changes to the test so that should be done today or tomorrow and I think at the moment ethereum GS is working on an updated version of the the transition tool interface we will which will uh help us to fill the test so I think a release uh for the ad 4 fixture should be possible for tomorrow amazing um and then gu is saying a couple days for them in the chat um so is it again take BLS aside for a second but assuming

we made no changes to BLS would it be possible to try and launch devet 4 before next ACDC or does anyone think that's unrealistic okay uh so yeah let's let's try and aim for a preac CDC launch date uh and then see Monday if there's any big BLS changes that we consider urgent but otherwise um it might be worth yeah it might be worth just trying to ship Dev net 4 next week and then uh deal in with BLS in Dev Net

5 yeah could we actually just freeze this back in this call maybe and agree that we're not going to do anything with BLS and if we do something with BLS then that would be in defet five that way Cent teams can actually uh yeah I'm happy with that ready by next week anyone have an objection here okay we talking about removing BLS from no no changes okay no changes we leave it as yeah um yeah yeah so this way like any engineering work towards BLS goes towards de5 basically

um okay so let's consider DEET for spec Frozen um try to get it live before ACDC next week and then we can uh yeah deal with BLS in the next devet um and actually yeah maybe as we start talking about devnet 5 um there was this idea uh brought up a couple weeks ago that uh yeah we we we'd want to do like a live or a longer lived Petra devet um or Petra test net sorry I don't know if we want this to be devet 5 or maybe it'll be what would be devet 6 um yeah we can see how uh how this evolves but there is a thread on E

magicians to try and set a name for it so I think uh in the next couple weeks once we um in in the next couple weeks once we uh finalize the spec for devet 5 and decide whether or not we want to make this The Long Live Test net we should find a name for it so please visit this thread um yeah I don't know if there's any other thoughts comments on that I did cly we also want client teams to make a release for this so uh the public can also easily sync up this chain I'm not sure if this is uh reasonable but I think it would be nice to

have okay um and yeah to comment like saying devet 4 should be moodang um yeah let's I guess let's see how devet 4 goes and then if uh um yeah if there's any issues um we yeah we can address that um and I guess my my argument for maybe the BLS changes being in the public death net is if we do something like change the pre-compile you know like remove some or split the subgroup checks out as separate pre- compiles and stuff like that um there might be value in having that in public devet if people want to test applications against it um so if there is something that like is going to change how you'd interact with the BLS

precompile um and we think that's important for the community to test and we should probably try and include it if it's just gas pricing I agree it's probably not the end of the world um but yeah we don't have to make this decision right now yeah I agree but I'm also just thinking like uh I I think it would be best if mudang whatever we call this testnet is stable uh for the community so like I wouldn't want to like launch Five a few days before Devcon and then you know find issues and then now it's chaotic so I think timing wise we'll have a better chance of having four be nice and stable uh yeah sure yeah yeah and I think actually yeah I I do agree

that having it for Defcon would be nice because um we'll probably cancel a couple award Dev calls during Defcon and like you know all of us or majority of us will be like traveling and stuff so being able to ship off something that's relatively stable either right before right at the start of Devcon means that for the couple weeks while uh there might not be as much um as much like new Dev Nets going live and stuff like that at least there's something for the community to test um so I think that might be the right approach like you know working backwards from like what can we ship before Devcon and then if the BLS changes make it in great otherwise um yeah otherwise then we just don't include the there and have stable

um okay sweet I think that's everything on Petra um anything else that people wanted to discuss that we didn't get to okay um then eips um so uh Tony had an update to 7623 uh Tony do you want to give a quick overview of that yeah sure um yeah e 7623 increased called data cost so based on the feedback I got from Tanish we

changed um we changed that we don't deduct the intrinsic gas cost before execution now we instead just check if the transaction sender is theoretically be able to pay the floor cost a yeah thanks for um posting the link to um you can find all the changes in the execution specs PR um so far um I heard that um ref and Ne mind have already implemented it I think Marios was also implementing it and also curious um how how is it going at Aragon thanks um yeah any comments about this from

implementers yeah I've not implemented the latest soon PM okay um okay anything else on this not uh yeah thanks only for uh sharing the changes um okay so next up um there were two new eips proposed uh in the past couple weeks that tried to address simar issues around resource consumptions first there was one proposed to reduce the slot time and then one that was proposed uh as a

noncore IP to adjust the gas l liit uh based on on uh to adjust a gas limit programmatically um slot TI one although it was like the first proposal is like kind of a CL thing so it probably makes sense to discuss the gas limit one first even though it came after um but yeah I think let's just open this up and then be mindful that there's like these two proposals that are somewhat uh related um but uh yeah Julio do you want to start with yours and um from there okay yeah yeah so um so first just to give an introduction to what this IP does it's basically just another strategy to

adjust the gas limiting client so it doesn't add any hard work it just basically makes it so that with certain parameters you can set your proposed gas limit to increase over time with a cap at some point so the re so the reason why I wrote this was first of all to address some of the problems that were with the the slot time reduction and also because one of the main issues that were that most people have with increasing gas limit is the uncertainty of potential bugs coming up due to the increase and an example of this is kind of the 413 status code incident which if we increase the gas limit to 40 million we

would probably have had issu in the chain because then the blocks would have probably been too big on for main net um and this this is type of issue is kind something that you cannot really predict either so uh this IP mostly um tries to decrease the risk um related to the actions of increasing the gas limit it doesn't really of course help to scale anything but it does reduce the risk significantly um compared to a fixed gas limit strategy which is now employed by clients um and yeah I mean it also addresses the pro some problems that um that that the slot time reduction have

for example the fact that it has to go to the this one doesn't even need an artwork and it's also quite much and it's also simpler but maybe I think that the the drawbacks can be discussed when uh when when the other AP will be discussed probably thanks and yeah actually let's maybe do that let's have Ben share his eips and then we can take uh yeah we can take questions and conversations about kind of the the set of them yeah um yeah sure the um so the idea is no sorry so I just want to say that of course another thing I I would like to say about this is that this of course is uh is to increase the gas limit in

the short term so maybe it's better to also get like kind of a Vibe check from that too yeah um so mine was in response to uh balic suggesting that we increase the without peas to increase the blob count um and the idea was if we speed up the slot time we increase the blob counts and we increase the um the gas limit also but without um increasing the block size that any individual validate uh block producer validator has to deal

with um and for for both the PRS one of the concern sorry for both the eips one of the concerns is like you know what about history growth what about State growth um State growth isn't pressing immediately but um for history growth we obviously have 444s or 44s um but um due to due to blobs the amount of call data that's being posted has decreased significantly so the history growth has also decreased significantly so we we do have some safety margin that

wasn't previously expected there you go that's the summary mostly thank you um and yeah there's a comment saying that you know the state size does matter if we uh if we do uh something like veral or and we transition to a new type of structure for the try um but yeah any other thoughts comments on these two eips uh sorry just to comment about veral I mean mandatory comment about veral uh the state Size Matters before we do the transition right after that

not as much but before it does so I guess yeah maybe let's start with the gas limit one like how the people feel about one the overall idea of a potential increase and two that if we were to do an increase uh to have the increase be kind of programmatic uh rathered than like a a one-time uh you know number that we propose and obviously this isn't something that like this is something that every every validator sort of decides but like

there's a difference of the default you know in all of the client software moves from uh you know 30 to 40 m uh 30 to 40 million um yeah wow after like four days of the Discord being completely flooded with this um yeah not much interest on the call um bigger problems right now than raising the gas limit um yeah I mean I if no one has thoughts on

this we can continue discussion acing but um okay IR thinks a gradual increase would be better and then I mean I feel like we've committed to increasing the scalability of ethereum through blobs so we need to focus on getting higher blob throughput out there um yeah but uh blobs and gas limit kind of works on two different blob is blobs are um capped by bandwidth while gas limit is capped by storage they are two different dimensions you if you increase the gas limit you're not going to increase the bandwidth required by that much because most of the bandwidth right now is from blobs yeah I'm not saying that they're

addressing the same thing but we have sort of made a commitment as an ecosystem that we want activity on l2s and that means that we need to increase the throughput for activity on l2s not necessarily on the L1 well but it's nice to have on L1 isn't it as well yeah and we should address it after we finish the things that are the priority right now but my point is that it can be done in parallel because if you if it's not if it doesn't get in the way of the priority why not making it in parallel because we don't have the ability to do things in parallel we can barely Shi this Fork that we're working on right now well but I mean this this is kind of

a trivial change it doesn't even require an hardart Fork right it does require testing and Analysis and like yes yes it does but it's not something big like like blob in Blob increase does require a lot of time right and also seconds per slot require time to test this just make you need to just make sure that every client that this function Returns the same number on every client during a devet which can be done in parallel with I know devet 4 for example or and I think one one thing about this uh proposal as well is like a lot of the um a lot of the concerns around like you

know blob increases is like we have to wait for another hard Fork which will take you know six months or something like that or more um you could imagine doing something like this right after pectra right like where if we think that you know we are bandwidth constrained in the next couple months and we want to like maintain our focus on shipping Petra um or even you know when we when we put out the main net client releases at this point you know we expect clients to be effectively done with the Petra work um this is something we can we can literally ship you know the week after that or something like that um yeah yeah but in another and when and like and the and another thing and another thing is

yeah that and another thing is that um yeah again this is not really that big of a change but I I just I also saw that Alex St said that it's actually riskier um I don't know what he means by though um yeah I mean the concern is like I mean again uh I haven't looked at this exact EIP yet so maybe I'm missing something but the concern is just like if we have some automatic increase schedule it could be very hard to stop the auto automatic increase and then the concern is then that you know like there is a cap Falls over no you can set a cap like it's not infinite like the in the it's written that there is a cap and

after you reach to say 40 million it stops IT increase of course if you change the defaults yourself it's going to still increase but the same can be said by the current fixed strategy yeah so actually so yeah a way to frame disc can it's we're we're like expanding the bound right like we're and again yeah yeah yeah but I think that overall this is just an an an improvement upon the current strategy so if anything um it should be treated as just a nice Improvement to have and eventually to bump up the gas limit um and uh yeah so yeah got and Poes yeah just wanted to e to Echo what

Julius just said that um I'm not advocating for increasing or decreasing or anything on the gas limit but but the CIP seems to make it safer actually than the way that we currently have of increasing the gas limage if we decided as a community to go and and we get people that are ramped up and we get validators to like say move to uh 45 million uh for the gas Target or or for the gas limit um then it would start immediately increasing at the maximum level and we may find out that that it's that it's hard to do and getting back from that is much harder than if we do this at a slow pace uh as the CIP is showing so I actually think it's safer

than the current mechanis not more dangerous um yeah and I also would like actually to have a more like um strong response from because for now I just heard from Gaff and Ne mind nether seems to be okay with raising the gas limit GFF seems to to say what like client said but other clients like Basu I I I would like to he their opinion too of course yeah um as as I shared on on Discord so so we have like these two eips um decreasing slot time and increasing uh block size U so as I said on Discord decreas in Block time it

seems more a c uh are concerns because um currently from the metrics I gathered we have 5% of the blocks that arrive after 3 seconds um so we could have um attestation misses maybe uh blocks reorgs um yeah so this is like more on the seal side and uh uh and basically if we're going to keep the 4 seconds window on the El side or we're going to review it uh like related to this 8C on on the on the Block size um so increasing the block size um so there are different um areas we need to uh we

need to check here in terms of block processing I think there is no issue on B Sude we have like few um um like we have few evm uh or pre compiles that are slower than other clients that that we are currently addressing uh but this is on the per second basis I I mean on um like there's still still window right but we're addressing those those differences um so in terms of um slot time there I mean in terms of block processing there is no issue so in terms of bandwidth uh uh solar Staker uh requirements um uh storage uh so I

believe uh this is more we need like more testing to know how how how it's going to um to behave uh but my my first feeling is to say uh yeah we are for for increasing block like block size because we already um this is something we already have on layer twos not exactly on the Block size but um yeah but I I I mean we have like similar um uh configuration on r2s that work very fine even if there is you know it's less decentralized um but maybe uh yes but for more testing uh and uh yeah in as as

as I said also in the on on the discussions uh in a gradual way it it seems to be the right way to do it yeah and also and also yeah so and also with if you increase it gradually you also don't have most of these problems because the moment you see that soloers cannot stay their computational you can just Al it right you you can just make release or and even set it lower because in the EAP I state that you can still use the fixed gas gas limit option and it will overwrite the option right yeah right and Ben uh one of the advantages with increasing the block size versus the um uh increasing slot time is increasing

slot time does increase the number of um consensus votes that happen because whereas block size has no effect on the consensus there in that way oh oh right yeah and and also I did this I mean I did some research about around how the block size increase actually affect computationally and the bigger the blocks the faster actually transactions execute amortis because of the state rout um and also because of the CES so actually if you if you execute a big block it will actually take on average less time per transaction than for a small block and I think AR is not the only one

that does that is like this by the way so actually yeah um yeah just for that to consider okay so I guess yeah this is yeah uh clearly something people have opinions on yeah please oh no sorry I was reading the chat that there was some B said that there is more bandwidth but in reality I mean the block bandwidth is very low like it's like 70 kilobytes per block and a blob is like 128 kilobytes so if you increase the block size by 50% you have like a quarter of a blob um it's

really not U it's really not like a bottleneck on the the bandwidth it's not going to be significant I think and po yeah so um it's true that the decrease of the slot time is better discussing the CL uh meeting uh I mean there's there's a lot of problems on the CL if we were to adopt something like this is not trivial at all but uh there's one component that is on the El which is does it probably break uh contracts or not there's currently you can you could you have a linear relation between block height and um and time stamp and we would break that uh

and this is this is a breakage on the EV at the evm level so this is something that probably you guys should discuss yeah that's we didn't have that relationship before the merch so people may have deployed contracts but there's contracts that can be right now using this since there was never the stated thing that we are never going to change the BL time I think yeah like this is not an assumption that we ever made and so developers that relied on this assumption um kind of make that assumption on their own so it's not our

fault in my opinion there is a there is a Time parameter for the block so they should be using that rather than the block number yeah and I guess if we were to do this change we should definitely look at it on chain um I'm not saying that we should posit based on this but there's a difference between a handful of random contracts you know have like a hardcoded divided by 12 somewhere or like you know some large and well-used contracts have this bad pattern um I think that's unlikely but it's definitely something we'd want to be sure about if we um if

we were to change the slot time so there are so since I have some experience on the CL side I can kind of give some feedback very quickly on on this lot time and my and my concerns about it is so my main point my main stance is that it's probably a good Improvement overall and it's probably going to happen eventually but it probably should not happen now because uh because first of all um first of all the biggest problem with solo staking is bandwidth and this and and this will not only increase the gas limit but also the blobs uh the blobs and it will increase the the band requirement and after talking to some sort of stier and the guys from DVT they

told yeah from the VT they told me that it's very it will be very punitive to have an increase in band uh significant increase in bandwidth and another issue with this is that if you is that it will get in the way of research on single Sal finality because the times there actually matters and currently there are there are being taught to approach one approach is and one approach actually does is kind of reliant on time of the slot time so I wouldn't really do this upgrade before single out finality if anything and also you need to also consider that maybe you need tojust some economic incentives with the c because now validators will have more money per

year and more e will be issued so you need to also think about uh yeah so yes that's just my my main concerns thanks and yeah we can I think we can follow this conversation on this yell call next week but um agreed we should consider uh not just can the protocol support this today but are there future changes or or things that would be um Complicated by changing this slot time um anything else on either of these topics it doesn't seem like there's an

urgent decision to be made here and there's clearly like more conversations to be had but yeah is there anything people feel we should address on this call um oh and nice de 3 is close to finalize again but there's may be some uh Lighthouse issue so um yeah some want s to that but okay uh moving on from this um Alex you had the pr on the Builder spec uh that was also kind of Cl related but uh you wanted to bring up if we have time so so

please yeah thanks uh so this is back to the request uh structuring that we've been talking about and where we landed for Dev 4 was that the engine API would send essentially like the serialized list of bytes and so we kind of have the same question to answer in the Builder API and yeah I guess I was just looking for feedback on any like preferences people would have the most natural thing to do based on how the Builder specs work is to use what the beacon apis do and then in the beacon apis we have like sort of this full Jon structure of the request uh rather than like this more compressed

serialization and it was a bit of an open question do we want to mirror the engine apis or do this other way and yeah I was curious if anyone had any thoughts on how to handle it here if there's no feedback I'll go with what I had uh right now which is essentially to have again yeah following the beacon apis which has like the full Json structure so the sort of downside to this is that as a Mev Builder you'll

need to get your transactions which you know in some way will sort of emit the request data then that request data um will need to be put in the right format it will require a little sort of der serialization uh but that's that's how we have uh that's how it works I put this now probably for the CL but uh but this is this is spand with the pendant right so this is adding latency on the Builder path uh I wonder if we cannot just blind it the builders can themselves compute the HDR that we're

going to put in the Bon block body and signed over uh and then we just trust them that they include the right uh requests since anyways we're trusting them on the on the transactions yeah the issue is that the C like the proposer will need the request to actually execute the state transition which they need to sign over the blinded block yeah you need a you need you basically need yeah you need the yeah we we need yeah otherwise we can compute the state route that we signing over that's right I had it that way originally because it was I was concerned more about like me and maybe some more Niche case but yeah teren ra this point which is correct epbs makes this much nicer

okay any other comments okay um and then the last thing we had on the agenda so Ryan uh had an eth research tread again more of a CL related topic um trying to uh nudge people towards getting better numbers around what we believe uh you know home Staker bandwidth requirements should be and and uh this way we can make better decisions around things like blog counts um yeah again more of a c topic but I don't know if anyone has thoughts comments or things I want to discuss about this okay if not uh yeah this is clearly a

topic that'll come up uh over and over as we start discussing blob counts on the S side so we can leave it at that um that's everything we had on the agenda for today anything else people wanted to bring up that we didn't get to H yes Ben just on the staking band considerations um that should hopefully they helped a lot from the e get blobs um if the most the e are implementing that so that the validators can pull the blob from their own transaction pool um if the C has use that rather than waiting for it to be propagated

nice um and then yeah there's a comment in the chat by Alex about uh 44s um any updates on this are any problem made yes so NE mind we are working on both basically portal Network and uh ER files as well I mean right now we are kind of finalizing P TR AP so we should have more power to push for four

fors nice anyone else do any client teams have thoughts on how portal is coming their implementations or is it still too early okay um yeah anyone from PTO here J yeah going a snapshat sync if that counts um

we don't plan on really using portal but we can get heav old blocks without the P2P and old blobs too so uh I think there's three people from Portal in the call uh me Piper and Jason Carver but yeah yeah any update you want to share or where people can go for updates if not yeah uh I mean for project not exactly uh I know that two people picked up

making a portal client for basus uh in the EPF and that's coming along fairly good uh they're just about to integrate with uh Hive tests which is cool and yeah sweet okay anything else people wanted to bring up there's a question in the chat how people are integrating portal um into their infrastructure does anyone have thoughts on and uh I guess I could give some ideas

so uh some of my ideas are I guess running it as an alternative like uh history provider instead of De PTP uh especially because with E4 fors you'll no longer be able to retrieve that data over de P2P uh it could also be used to like seamlessly once 4 force is activated no Json RPC functionality would be lost uh which is nice so if somebody tries to fetch something before the e44 window uh you can actually give like a valid message if that data actually existed instead of just saying I have no idea what this data

is uh but I'm sure there's other things I missed yeah I was mainly interested in how it's being done now like is it being integrated are are the current e clients calling the portal Network or is there like some Network that's being created that that doesn't integrate well with portal if you know um so for us for another mind implementation I think we're connecting directly to the P2P of portal and trying to get the data from P2P directly um and also trying to serve uh so not only getting data but also serving

um but yeah uh other clients could choose to uh do it differently yeah I'm not sure I see benefit in uh like half of the clients having a separate P2P Network for serving a history like portal and then half connecting to portal seems like unneeded redundancy I'm a little confused with how that is phrased uh but I think every

implementation would probably be like stinct in that like I'm a little confused by your two examples but I think they would all be done the way uh ah ahed I think that's his name a smart programmer said uh I think that'd be the most uh sensible implementation Portal if not yeah I think we can wrap

up here um thanks everyone so I'll put up the uh uh issue for the BLS breakout on Monday but we have that and then the interrupt testing call and then hopefully we can uh finalize specs for de 5 and get devet 4 up before next awkward devs and uh yeah in case you miss the chat Petra devet 3 finalized as we speak um so yeah thanks everyone and talk to you soon thanks Tom bye he

all