EIP-4844 Implementers Call #27

Transcript

um yes so welcome to uh 4844 call number 27. a bunch of uh PRS that we discussed uh previously to quickly review today um any updates on the devnets as well and then Roberto had a doc on this state of transaction pools um yeah so we can go through that and then I think there was some comment by pop in the agenda about whether we should restrict conversation on this to 4844 but as it's all starting to emerge uh into one big Dan thing it might be worth just rethinking uh how we want to either name or approach these calls

um because I guess it's gonna um become more and more combined with everything else that happens um but yeah I guess to kick it off um I know we discussed this on all Core devs last week but any other updates on devnet 7 or kind of new things that came up in the past couple days okay uh um oh yes yeah pretty soon I could just say for Lighthouse where um debugging it like a sync issue where I think we're either rate limiting or where like canceling

requests when peers don't respond quickly enough so I'm still just doing debugging that type of stuff cool any other time if you want to share updates an update from Deku um we're good with devnet7 not on zero Port um we're getting ready for their net eight um we're still working on the V3 block endpoint and the parent beacon block road uh moving to the execution period anyone else

and we should be basically ready for definite eight another mind here um but just checking this VR move parent to pick on block road so I'm not sure if we added it and what is the status here but that's all which PRC uh move parent Bitcoin block okay okay yeah let's jump in on that real quick oh yeah if you have an update perfect um so we left the call on Thursday operative saying okay it seems like people are neutral to

in favor of this on the consensus there um obviously at the cost of like duplicating a field but having it both in the block and then in the execution payload even though both are committed to with the proposal signature and are in the data structure already [Music] and then we put up the pr asked for some more feedback so that we could try to expedite a release and got a modern amount of negative feedback so I don't think that we can cut a release before Thursday before we can make a synchronous uh conversation on it so point being is it's not I I yeah I'm not I feel like maybe a coin flip I couldn't say better one way

or the other at this point so we will be discussing that on Thursday okay um yes amazing artifacts on the execution there is the engine API pretty much just if the data structure is separate or if it's in the um in in the payload in there but either way we need to figure it out like it's interesting okay sounds good so we can keep discussing it on the pr yeah uh basically yeah please if you have opinions one way the other jump in

because we will talk about this on the Thursday call and we're going to make a decision that day yeah and there will not be a breakout room specifically for this PR various anything else on that specific PR um we sort of jumped ahead a bit but were there other fine themes I wanted to share updates uh on either dead seven or the work that they're doing towards segment eight yeah Chris I'm here I was gonna add not much from uh some deafness seven we're

focusing on that thing so I think we're pretty much ready it's 744788 so yeah whatever decision we decide we can quickly Implement that so yeah looking forward to getting it oh um anyone else without sweating ethereum JS is also almost ready for definite I mean yeah so as soon as we decide upon the PRS we finalize the devnet it's back we should be able to cut images for definite um so for cath in theory we have everything for

definite age um but it's uh again multiple PRS and I'm going on holiday next week um so uh probably someone else from the team maybe Matt will take over and they would need to rebase and create a definite Aid Branch awesome uh Andrew yeah sorry I've just returned from holiday and yes the opposite to Marius um so I think we have like the we still need to to finish some bits and pieces for you

4844 as I mentioned on the Oco Dev so I'm I assume that like in in one but probably in two weeks we'll be ready for the not eight dollars uh for my house where we've implemented the devnet spec and we're just in the processor reviewing it so I think we should be able to merge it in the next week I've sort of lost attractive if there's any more clients that have please go ahead

okay but it seems like yeah some teams are pretty far along the implementation and basically just waiting on the final specs others need maybe like another week or two um so potentially we can um we can try to launch definitely eight if not by like late this week maybe early next week with like a subset of the clients see how that goes and um potentially add more clients in the week after that does that seem reasonable to people I think this back needs to be finished concrete before any yeah benefit would launch and we're also discussing that we would like to run a high test for Every client and we're going to be launching the

definite only once we have a decent amount of uh I've covered okay so that means then we agree on the spec yet The Hive test written make sure the clients pass the hive test and then launch their med8 is that right yeah yeah that's okay so maybe mid next week is more reasonable for government yeah yeah if if we can get the approved by Thursday then maybe we can have clients related by Friday and then Monday Tuesday we do hive testing and one day we can do a imitate launch I think that's really simple yeah that sounds good any other thoughts on that otherwise we

can go through these open PRS that we we had um okay so we're already from hive here sorry uh is anyone from hive around to maybe comment on the test coverage so I know so Spencer uh I know you and Mario have been working on the execution tests in Python um do you know who who if anyone has been looking at five and so

can you hear me yes we can yeah cool the 4A for four tests for ethereum Js on the pi specs simulator there is a timer issue that I've been looking into I've been putting it off but I need to fix that it's kind of been me and Mario mostly Ford devnet8 I'm still working on the beacon block group tests they're mostly done I just need to get them properly generating with uh T10 tool for spec tests but um getting the hive tests ready and running

on Monday Tuesday next week sounds doable would you mind dropping the link to the file or files for the beacon block root tests are I'd love to take a look sure no sounds good thanks okay so yeah for the spec um we had a bunch of open issues uh we covered already the first ones

um then uh okay I'll go through the list there's four more um so the Builder override flag uh I'm sorry I haven't we discussed this last week and now for some reason it got merged uh so okay yeah I'm actually sorry I don't have the context of this one so yeah we we talked about this on a few different calls yeah um I think everyone agreed to have it in for devnety okay yeah and and likely almost everyone will just have it yeah return false by default execution layer and be a no op on the consensus layer and they can add functionality

over time okay I think actually yeah yeah I copy pasted it from last call um so this is okay this is why it was already merged um okay so sorry yeah three uh that uh we wanted to discuss so the block V3 there is still a bit of comments on this today but generally it seems like everyone was in agreement around it and whether we want to have this indominate is the open question uh so this one only affects like communication between the beacon note

and the validator client so you would need it for like using different consensus layer clients together but it's not necessary for like interrupting like on the network but we don't necessarily need to have it or not for the devnet got it and I assume yeah I assume we're not going to be at the point where we're setting you up like a prism Beacon node and tried to get other validator clients to connect to it I don't know if you've ever even done that on the devnets nope yeah yeah pretty low priority for our yeah

um so yeah let's just leave it open and people can assess it um next one uh was uh pr426 which I get everyone's seen in favor of uh and again a question do we want this in the definite spec ific mostly changes some error codes and so even if client will not implement it it should be more or less fine yeah

sorry go ahead yeah of course we'll be better to decide what we want to do about generally it should be fine okay so I wouldn't yeah definitely not have it as a Blocker on the devnet um and then the last one um I doubt that this blocks anything as well but uh like client had a PR just renaming data gas the blood gas so oh right already this is a blocker for Hive that's a good question uh Barnabas um if it's like some very specific error message that Hive would check for then

uh I guess it's gonna be a blocker for Hive in this case um I don't know gizinder I saw you commented on or Alex type yes do you either of you know if I would cover the stuff in 426 um yeah four to six indeed so now it covers a non-defined behavior for some uh cases um so it would be cool to have this one next on the next download so do you know sorry if a hive like is

this something that will be tested in hive oh yes yes uh okay it appears that uh the current specification specification doesn't cover all the return like pieces and uh this period covers this wow it seems critical to include okay so um so then 426 we should try and get for devnet

but then the previous ones um basically the block V3 at the point I doubt I would check this so I don't think yeah I don't think we need to do anything there but let's add 426 to the actual spec and then uh okay so next one so we had uh PR by clients were naming blood gas the data gas I doubt this would be checked anywhere in a hive but it's probably something we can agree to here yeah I don't know if I guess does anyone

feel a strongly against this change I don't know strongly but yeah I'm somewhat against it's yeah it feels like block gas is clearer do you think block gas is clearer that's that's what the change is changing too oh sorry okay I see oh okay okay so perfect um I also don't have a strong opinion on it

um I think in general podcast seems clearer the only reason why we went with that I guess is that of course we might in the future want to use this gas type for something else in blobs otherwise also we wouldn't have had to go through all the direction of even having it in the first place we could have charged pops directly so if there's a potential scenario where in the future we use the same gas type for charging for something other than blocks it might be confusing because then we won't be able to change them again once we once once it's live it's live I think and I'm a little worried about this but on the other hand I can see that that argument with the confusion with call writer so I don't know I don't have a strong opinion

initial arguments in the pr just to make sure that we understood why the decision was made originally blob gas is probably fine if I didn't care about the length of names I might call it data availability gas but long name sucks so uh I'm not gonna I'm not gonna get in the way of this one it the main thing is it's just gonna be a big diff on the consensus specs that we have to do in a big diff or not big but touch a lot of things um but if people want it we can we can get it out no problem right okay any just in favor of like moving

this forward then you want one two blocks the plot data or or block gas or should we just go ahead get this merch and decide to rename it the data availability gas in a few years foreign people like acronyms D.A dog ass big ass so okay so Marist doesn't want me to name it that right now um oh my child hates acronyms um we we pretty we try to never use them in naming on the consensus layer at least have for years or so uh we should we probably would stick with not doing

it again okay let's just move forward with Rob gas I don't know so you said it causes a large diff on the consensus release is that something I wanted no it's gonna be a few lines in the spec and then it's going to touch a bunch of testing so like you know this is going to be a PR that has that changes it you know and then it's going to be some work for any team that wants to be named conformant across the board so you know it's just gonna be a diff in every software that does it um again not a big deal okay so I think yeah let's just go ahead with it and um

yeah oh there's a question why data available to gas too long I don't know like clients do you want to answer why data why data availability is too long why gases yeah why not data availability gas I mean it's just really long yeah it's not very nice I realize I'm talking to a Java developer yeah y'all can't even really have a conversation about this um it's hard because go go is like you know minimally small names okay so I think Roberto has says at the Roberto's comments of Max fee per beta

availability yes um that becomes very very long what if we made it update availability I guess okay we gotta keep we gotta keep moving yeah and Roberto's comment makes okay so that's okay let's merge it Bob the blob gas anything else on this okay uh back to more uh substantive issues uh Roberto put together a doc uh

looking at the different approaches to the transaction pool uh design um based on some conversations uh in the last four four call where it seems different teams have taken different approaches um I thought it was also a conversation with Peter this morning um about this on the Discord uh but yeah Roberto you maybe want to give a bit of background on your doc and uh kind of share uh the takeaways from the the chat with Peter yeah sure um it was I just wrote it up in a response to um the discussion last week where it sounded like um teams had only just started I guess getting to implement uh rules in the transaction pool around blob transactions there's a lot of additional

considerations for blob transactions because they're expensive to validate cpu-wise expensive to broadcast or not broadcast simply just send around and it opens up a lot of avenues for denial of service attacks so we've discussed this kind of on and off sort of piecemeal and different meanings and I just sort of wanted to consolidate the discussion um unbeknownst to me there was a there's a large PR in the Geth repo which Peter pointed me to this morning so I've linked to that and then as well it contains a lot of the um same similar rationale so anyway I think it's just worth looking at and making sure that we're all more or less on the same page with the rules that we're implementing I guess what I'm a

little concerned about is that one client will Implement one thing another client will have it completely different and then you know the um the software that interacts with the nodes to submit blob transactions won't really know kind of what is the appropriate behavior well how does it how should we set priority fees um how should we set the resubmission rules um should what should we expect to happen on rewards so so things like that um so you know it's a short read it's pretty easy um if there's anything I you know I guess my proposal is just let's do what Geth is doing um because it seemed to address all the concerns I laid out there um if there's any issues with that I guess be a good time to raise them um so I have a concern about block

transactions uh building on each other before they're confirmed I think they should just not see in that handful yeah that certainly simplifies things a good deal yeah that would be my suggestion because that's already a big problem with the current transaction as we've discussed before and uh like yeah I think it's safer to just not allowed and I don't see a lot of reasons to required like I mean if if a rule app actually wants several blobs in one block it can easily send them from several accounts as well there's no reason to like having to use

the same eoa to send the blobs but wait so you're saying this should not be in the public at all no I'm saying like each each AOA should have should be able just one oh yeah okay in the public member yeah and guess does not already do this correct I understood what Peter sent earlier that yeah currently you can have several transactions just like it just for yeah transactions and I would just like

remove that capability yeah that seems reasonable I guess we can continue the conversation uh in the in the sport with Peter there but yeah conversation Discord I mean Peter seemed pretty uh adamant that they wanted to stick with the way they're doing it um but he did suggest if you have um other opinions to let them know yeah certainly there's like a ux strictness trade-off and adding the additional condition but my read is he might be open to tightening

rather than loosening yeah I guess the other question to ask is if clients implement this this differently is this particular issue a challenge it seems like it this one it seems like it might be right uxy's um I guess there's two things right like Can I submit it to my node to broadcast and then if I submit it to my node to broadcast is it gonna generally make it across the network and it's like if if gas is 50 60 a network then maybe you don't get full propagation but once you get included maybe you maybe Geth then fills in the gaps with announcements but but maybe not so like you're right some of these things

could make things a bit more finicky I think another uh another way that this would make things different is if uh like basically the the roll-up operators and whatnot like you know if if the transaction will only effectively works with guests that it means you know anyone submitting blobs would end up just using gets so I think there's value even though the approaches are not the exact same to at least documenting like the best practice or something so that all the clients can have a good option um which is going to end up looking like the tightest uh is going to be what best practice

becomes I guess any thoughts from any of the other client implementers okay uh if not then yeah let's just continue doing the conversation yes sir it's like our transaction full-time tests are in development advice like end of it probably this week will be reviewed but other team members but

generally we are planning to be more or less in line with with graph like we have implemented 100 fee increases so the same like graph we will allow senders to have block transaction transactions or other types not above at once impending so it's the same thought and we are planning to keep included blood transactions until finalization so we will support Rio works as well and for now we don't have a minimum priority

requirements for one way but it's good idea so I will add it tomorrow probably and it's like just our implementation is very similar to the web ones we have one got it thanks any other time team um I guess I have a question whether anyone has thought about this right because if you look at many today about 95 or 90 of the blogs are proposed using Builder and the map boost right so then

so basically in this model right like say assuming blob there's not much data PSP blah blah blah it's very cheap like one of the builders incentive to basically like including blog from the problem and versus like just prioritizing their own stuff right so that's something that like I'm not sure I think it's worth thinking about like under that model like how does this work they just prioritize whatever makes the most money Yeah but whether it's public land pool or their private one yeah for sure I I was wondering if the blobs are basically free then by why do

they even here well I mean you can always set a higher much higher priority feeder pay them for the blob effectively right yeah that's fair I guess it's also what we came into the common side effect but I think so one thing we did look at in 1559 a while back is like as the block gets bigger you know there's a slightly higher chance of being uncalled on proof of work which doesn't apply on proof of stakes but it's like the only the only case where it doesn't make sense for them to include a blob at all as if they think

that they can't get their Block in time because it's going to be bigger the gossip but that shouldn't if if there's a small number of blobs per block that like that shouldn't be a huge Factor yeah I and obviously yeah if there's too much competition like if there's a blob like today validators can choose to include their transactions even though they're not the most profitable ones in the mempool right and and Builders can do the same so I I think what blobs you basically have the same thing where they get this degree of Freedom or they're

not forced to pick the highest paying one but if they want to maximize fees then that's the strategy we should adopt Does this answer your concern parents or is there something else that uh where yeah yeah yeah yeah I'm sure it does definitely yeah also like Builder I guess I just don't trust with the others I think Builders are weird sometimes they do things their own way correct versus like just using client start software it's way more like predictable

like what's going to happen but yeah it's definitely something worth like paying attention moving forward any other thoughts on the transaction pool um last thing then um so we discussed are starting to like Encompass more than just for it for four stuff and you know devnet 8 is going to be um is is going to contain some non-40

for four things as well so I guess I'm curious to hear from people like do we think we should keep this call if so should we just broaden it to like 4844 or sorry dencoon testing in general yeah how did people feel about this I guess does anyone feel we should stop having this call every two weeks no okay so keeping and broadening is the it seems to be the consensus so okay um we could keep them just rename them to

like then testing calls or something and uh yeah have them until the fork I think it's yeah it's good to have an extra spot where we can just discuss uh more of the kind of granular details around different devnets and whatnot and yeah we do still have a lot of work to do it's on that note anything else anyone wanted to cover today on the we have a lot of work to do front I'm you know we're in this typical phase where things are generally decided

and we know what we're doing and we're testing and we're iterating you know and we're refining it I think it's kind of hard to tell when you're not in your own client what else is going on with everyone else like in terms of this the path to reductionization and I'm not going to sit here and ask for timelines but like is it feeling good are we like finishing the productionization uh other than some of these new features that are added to dencoon for devnet8 or is it does it feel like there's still a long slog to go I don't I don't again I don't want to ask the question in a way that puts people too much on the spot but I

guess I don't personally have Clarity on that so I was wondering if others have perspective here uh Justin um yeah Danny um and everyone else our situations yeah we feel pretty good about the 4844 stuff and also pretty good about the remainder of what's going into Cancun we do have a decent amount of cleanup and a decent amount of um you know refactoring and merging and some regressions that we're still stumbling into so we have a little bit of you know cleaning up the house that we um see as not necessarily A blocker for anything on the schedule but we'd feel a whole lot better about having that in

order before we started merging into you know broader test Nets you know the sepolia and Shadow Forks Etc et cetera uh so um yeah you know I I I appreciate you not asking for a date therefore I will not throw one out um so we're happy with how we've been performing in a 4844 perspective and I have a little bit of concerns otherwise not sure if that's helpful or muddies the waters further no that that's helpful at least to me and I think also confirms that we should keep these calls and brought into scope so that we can start yeah addressing not just the foreign specific issues but potentially the utter uh VIPs with more Focus

uh parents yeah so um to add my thoughts for Danny's question I think we're at this like Pace that like we feel pretty good for a death net we feel that we can do all the deafness blah blah blah I also feel like we're are still a bit early for test man many because like um all the Builder and really interesting Universe are now there so for this time I'd like to see them being there first and I like to do more like back field testing for example thinking and that can feel blobs over the last 18 days I think that part is slightly less tested and uh and I'll also see a few like issues with the with the with the raidive making as well I think that's

gonna be like something that like client team will run into issues with also like at the um also for the edge cases where like the blob goes missing from the ghost of net and then you have to be in your request so there are definitely a few more tests in there that I like to get done before uh before going for test net so do you think this is the time to like start reaching out to like people working on MVP boost and whatnot and like get this tested yeah yeah of course yeah and on that but we we do do have our kind of Fail-Safe fallback tests in Hive

that carry forward so at least we get some sort of assurance that even if the map boost workflows failed the network doesn't fall over right yeah about that we have seen from the Presidential Power incident right so so so so what happens with that is that we're always just to say today your match skip slot it's like five per Epoch and then you basically will just give four skip slots per Epoch it's still not ideal uh so from lighthouse I've mostly been focusing on just trying

to production at what we have the past like two or three weeks now um the scope of the changes is pretty huge though because like every part of the client ends up being affected at some point so there still is like a decent amount of work there um I think generally we're pretty comfortable with all of the 4844 features the one like still work in progress is the Builder flow like Terence just mentioned but we have like Jimmy from our team has been working on that so got it any other crime teams want to

share your thoughts so from nethermite side we are pretty good in terms of implementation And Hive testing of all eips uh one potentially missing point is a transaction pool that we are still implementing hasn't about transaction pull it's like the current implementation uh it's like key points are we have implemented we are not sending full block transactions

and like basically logic is implemented we just don't have the separated blood pool finish there okay and this thing asks before we wrap up okay well

um yeah thanks everyone uh talk to you all uh this week on awkward devs and I'll change this calendar invite uh um issue name and what thoughts the refocus it on then testing um but I'll leave the time and everything else uh the same so see all two weeks on this call uh under a different name and yeah thanks everyone thank you bye bye thanks thanks hi everyone