https://github.com/ethereum/pm/issues/835

Bunch of PRS that we discussed previously to quickly review today.

And the updates on the definite as well and then Roberto had to dock on the state of transaction pools.

And then I think there was some comment by Pop in the agenda about whether we should restrict conversation on this to 4.44 but as it's all starting to merge into 1 big Dan Coon thing, it might be worth just rethinking how we want to either name or approach these calls, because I guess it's going to become more and more combined with everything else that happens.

But yeah, I guess to kick it off, I know we discussed this on awkward devs last week, but any other updates on DevNet 7 or kind of new things that came up in the past couple days.

We're debugging like a sync issue where I think we're either rate limiting or we're like canceling requests when peers don't respond quickly enough.

So still just doing debugging, that type of stuff.

Any other time team want to share updates?

We're good with DevNet 7, Mountain City Report.

We're still working on the v3 block endpoint and the parent beacon block route moving to the execution payload.

We should be basically ready for DevNet 8, never mind here.

Just checking this PR move parent beacon blocker, so not sure if we did it and what is the status here?

So we left the call on Thursday overdubs saying, Okay, it seems like people are neutral to in favor of this on the consensus there, obviously at the cost of like duplicating a field by having it both in the block and in the execution payload even though both are committed to with the proposal signature, and are in the data structure already.

And then we put up the PR asked for some more feedback, so that we could try to expedite a release and got a moderate amount of negative feedback.

So I don't think that we can cut a release before Thursday.

I feel like maybe a coin flip I couldn't say better 1 way or the other at this point so we will be discussing that on Thursday.

I talked something execution layer is the engine API, pretty much just if the data structure is separate or if it's in the, in the payload in there, but either way,

Okay, sounds good so we can keep discussing it on the PR.

yeah, opinions 1 way or the other, jump in, because we will talk about this on the Thursday call and we're going to make a decision that day.

And there will not be a breakout room specifically for this PR various.

We sort of jumped ahead a bit but where there are other client teams I wanted to share updates on either that 7 or the work that they're doing towards them at 8.

I was like, not much from us on that 7 were focusing on that day So I think we're pretty much ready except for 4788.

So yeah, whatever decision we decide, we can quickly implement that.

So as soon as we decide upon the PRs, we finalize the DevNet

spec, we should be able to cut images for DevNet

So for Gareth, in theory we have everything for DevNet 8, but it's in multiple PRs and I'm going on holiday next week.

So probably someone else from the team, maybe Matt will take over and they would need to rebase and create a definite 8 branch.

Yeah, sorry, I've just returned from holiday and yes, the opposite to Marius.

think we have like, we still need to finish some bits and pieces for you, for for for for as I mentioned on the ocor dev.

So I'm, I assume that like in, in 1 but probably in 2 weeks will be ready for them, not 8.

for lighthouse, where we've implemented the definite spec, and we're just in the process of reviewing it, so I think we should be able to merge it in the next week.

If there's any more clients that have updates.

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 2.

So potentially we can try to launch DevNet 8 if not by like late this week, maybe early next week with like a subset of the clients, see how that goes and potentially add more clients in the week after that.

I think the spec needs to be concrete before any would launch.

And we're also discussing that we would like to run high test for every client, and we're going to be launching the DevNet 8 only once we have a decent amount of Hive coverage.

So that means then we agree on the spec, get the Hive test written, make sure the clients pass the Hive test and then launch DevNet 8, is that right?

Maybe mid next week is more reasonable for DevNet

If we can get it approved by Thursday, then maybe we can have client releases by Friday.

And then Monday, Tuesday, we do Hive testing.

And Wednesday, we can do a DevNet 8 launch.

Otherwise we can go through these open PRs that we had.

Is anyone from Hive around to maybe comment on the test coverage?

So I know, so Spencer, I know you and Mario have been working on the execution tests in Python.

Do you know who, if anyone has been looking at Hive?

And so the 4844 tests for Ethereum JS on the PySpecs simulator, there's a timer issue that I've been looking into.

And It's kind of been me and Mario mostly for DevNet

I'm still working on the beacon block group tests.

I just need to get them properly generating with TA-Tentile for our spec tests.

But getting the Hive test ready and running on Monday, Tuesday, next week sounds doable.

Would you mind dropping the link to the file or files where the beacon blocker tests are?

So the builder override flag, I'm sorry, We discussed this last week, and now, for some reason it got merged.

So, okay, I'm actually sorry I don't have

I think everyone agreed to have it in for devnet

And likely almost everyone will just have it return false by default execution layer and the no op on the consensus layer and they can add functionality over time.

Okay, I think actually, yeah, I copy pasted it from last call, so this is, okay, this is why it was already merged.

Okay, so sorry, Yeah, 3 that we wanted to discuss.

So the block V3 endpoint, there's 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 in DevNet 8 is the open question.

So This 1 only affects like communication between the beacon node 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 right.

We don't necessarily need to have it or not for the definite.

Yeah, I assume we're not going to be at the point where we're setting up like a prism beacon node and trying to get other validator clients to connect to it.

I don't know if you've ever even done that on the DevNet.

Yeah, pretty low priority for this type of testing.

So yeah, let's just leave it open and people can discuss it.

Next 1 was PR 426, Which everyone seemed in favor of.

And again, a question, do we want this in the definite spec.

I think it mostly changes some error codes.

So even if client will not implement it, it should be more or less fine.

Yeah, of course, it will be better to decide what we want to do, but generally it should be fine.

OK, so I would definitely not have it as a blocker on the DevNet.

And then the last 1, I doubt that this blocks anything as well, but like kind had a PR just renaming data gas, the blog gas.

Already, it is a blocker for hive that's a good question.

If it's like some very specific error message that hive would check for them.

I guess it's going to be a blocker for hive.

Gish in there I saw you commented on it, or Alex I do either of you know if I would cover this stuff in 46.

Yeah, for 2 things, indeed, covers an undefined beaver.

So, do you know sorry if high, like, is this something that will be tested and hide.

It appears that the current specification, specification doesn't cover all the written like pieces and this PR covers this.

Okay, so then 426, we should try and get for a DevNet, DevNet 8, But then the previous ones, basically the block v3 at 1 point, I doubt Hive would check this, so I don't think, yeah, I don't think we need to do anything there.

So we had a PR by our client renaming blob gas the data gas.

I doubt this would be checked anywhere in Hive, but it's probably something we can agree to here.

I guess does anyone feel strongly against this change.

I don't know strongly but yeah I'm somewhat against it.

Yeah, it feels like blood gas is clearer.

I also don't have a strong opinion on it.

And I think, in general, but that seems clearer.

The only reason why we went with it I guess is that, of course, we might in the future want to use this gas type for something else than blobs.

Otherwise, we wouldn't have had to go through all the direction of even having it in the first place.

We could have charged for blobs 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 it's life it's life I think.

And I'm a little worried about this, but on the other hand I can see the argument with the confusion with call call data so I don't know I don't have a strong opinion.

Yeah, I mean I parroted on scars 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 guess, but long name sucks so I'm not gonna I'm not going to get in the way of this 1 it.

The main thing is, there's going to be a big diff on the consensus facts that we have to do and a big diff, or not big but touch a lot of things.

But if people want it, we can get it out, no problem.

Okay, any, just in favor of like moving this forward, so you want to want to blot the blob data or or blood gas or should we just go ahead, get this merchant decide to rename it the data availability gas in a few years.

People like acronyms, da dog ass, the gas.

So okay so Maris doesn't want to name it that right now.

See all Ethereum transcripts on Youtube

EIP-4844 Implementers' Call #27