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

Okay, we probably have enough people to at least get this started.

So some Dan Coon stuff today, getting some updates on DevNet

And then we can continue the conversation around the testnet ordering.

Dan, Andrew wanted to bring up the vertical try and state expiry strategy.

So we can spend some time discussing that.

And those are basically the 2 big things.

After that, I think Ethan just had some updates on SSZ you wanted to share.

I guess to kick it off, do we have a, yeah, Barnabas, do you want to give an update on DevNet 8?

Partner DevNet 8 has onboarded all the different clients and everything looks very healthy.

We have a few of the pairs that are not really working.

Yesterday we had a smaller issue with Nethermind.

Hopefully someone from the Nethermind team is here to let us know what has happened.

I'm not quite sure to be honest, but we see quite some, drop, but then they released a new version and, after I rolled it out, everything went back up again.

And, we have a few pairs of mentioned mainly Ergon and Ethereum.js that are struggling with a few of the seals.

We have now a beacon chain explorer also on boarded, we have a light beacon chain explorer also.

Does someone from Nethermine wanna give some context on the issue that was fixed.

So, I'm not entirely sure because I wasn't involved but as far as I know, the experimental transaction pool stuff was merged and was causing problems and it was like, means that

it was merged and so yeah, so basically it's so the transaction pool part that we have separate for each of our transactions

So was the fix just to revert that change rather than having a full working transaction pool?

Context on any issues or fixes they've made this week.

And I guess before we go into the test nets themselves, it seems like we probably still want to get more testing done on DevNet

Does it feel reasonable to try and get all of the pairs working on DevNet 8.

And then once we have that, move to DevNet 9, do the last changes with the 4788 spec, and hope all the pairs sort of work on that pretty smoothly.

personally think that's reasonable and I'm just curious if we had an agreement on how to deploy the contract.

So we, yeah, we decided we're just going to use a normal transaction.

And if I remember correctly, the reason was it was pretty split between that and the custom deployment logic.

But we figured a normal transaction was easier to implement and just start with that.

And then if for whatever reason, there's like issues with using the normal transaction, you can always add the logic around the inf work deployment.

So there is going to be like a particular address that needs to be sent from it's like a synthetic transaction and that it's reverse engineered from a particular actually don't know exactly how it works, I'm not going to explain it, but there will be a particular address that needs to be funded to do the deployment.

And there'll need to be a gap, a big enough gap between, you know, genesis and the fork on that testnet such that we can do that.

I think we normally have such a gap but it's just gonna be something that we manually need to make sure is done in that interim and not to just for this test net, don't just deploy it to a particular memory location at Genesis, we wanna do the actual transaction.

The spec, It's mentioned how to do so in the actual spec 4788.

You know, write a script or just do it themselves if it's not worth to be scripted.

But I assume for stuff like DevNet, we would need to have this then deployed on the actual epoch of Dengkun?

So that's why I said there needs to be an adequate structure between Genesis and Dan Cook.

It's because a manual transaction has to make it on chain.

expected address in the test and also just.

Just to match what the address is currently in the.

And, yeah, instead of sending the section and that's the reason I asked.

If we were doing a normal transaction or this transaction because we with this transaction we have a deterministic address everywhere and it's just easier But yeah for the tests I assume we're going to update the others to the final algorithms we are seeing in the VIP for DevNet 9 if that's okay with Barnabas and Parry.

Yeah we can do that ASAP if you guys want.

I was just gonna say yeah as long as it doesn't affect any.

So I guess as soon as you change it in Hive, you know, those tests will start breaking for clients.

And obviously we shouldn't retro actively change this on DevNet 8.

But yeah, going to DevNet 9, we should make sure that Hive reflects this address.

And when we get sufficient go ahead from every client, I will just update the Hive test.

Myra, can you make sure that there are Hive tests where this contract is not deployed in time to that address?

That address, just that's something that almost certainly won't happen, but it's something that can happen in this technique.

So I just want to make sure that we do test the kind of like no op at that address.

It should quote, just work, but we should have to.

And so there was a question by Barnabas in the chat asking if client teams are ready for DevNet

And I guess based on the comments by Nethermind, do we want to figure out the full blob transaction pool on DevNet 8 and potentially test that on DevNet 8 before we deploy DevNet 9?

Or would we want to move to DevNet 9 sooner rather than later so that we can have the final 4788 spec and then maybe do a bit more non consensus changes on that DevNet.

Hi, sorry, I just want to ask like about EIP

for DEFINET 9, do we also want to add the beacon contract as a WARM address or not?

A warm address, so like it is sort of a pre-component.

But do we want to add this as warm or not?

I'm not sure if this is the right place to ask this question, but do we want this or not?

Because I know this question has been raised before on the R&D.

Whether we should always treat it as a warm address?

Oh shit, I was muted for everyone on the stream.

Sorry about that, everyone watching the YouTube.

I can try and swap with the Zoom recording later today.

So do we want to get it live as soon as possible or do client teams want to make sure that things are working?

That we have like the blob transaction pool on DevNet 8 that we maybe spammed DevNet 8, sent some bad blocks on it and all of that.

Yeah, how do people feel about moving to the next 1 versus doing more testing here?

Assuming there's no spec change other than this, the way this contract is deployed, I'd rather be very confident going into DevNet 9 rather than like saying, okay, well, we hope these things are gonna work.

And so in that case, I'd rather iron out the things that we know are issues.

Otherwise, if we have a high chance of issues in DevNet 9, then we certainly will have a DevNet 10.

And I'm not saying we shouldn't have a DevNet 10.

We should have the amount of DevNet that makes sense.

But I think at this point, we can attempt to have DevNet 9 be really solid.

Yeah, I would also lean towards that, unless people think there's like some reason to test the 4788 change much, much sooner.

It looks like the current devnet, well, clients have several quite critical issues.

Like we have a different opinion about how to calculate block hashes, which is quite a basic stuff, right?

And we're observing payloads, new payloads, with some kind of wrong data up here.

So maybe we could at least make it more stable and fix all of that because the network had multiple forks as far as I know.

Now it seems more stable, but this issue is still exist.

And I think it will cause a lot of troubles if we do in other network.

Maybe we could spend more time on stabilization.

I also just want to echo, like I believe, and I think most people on this call believe that like the deploy method or 4788 is like almost a no op for clients.

And so I don't think we need to rush to test that spec change.

Like it really doesn't manifest as a change them it's obviously something we have to test but stability and reduction of additional overhead and DevNet seems to be the preference.

So yeah, that seems pretty widely agreed upon.

And obviously we'll check in on both the CL call next week and then this call in 2 weeks about DevNet 8 testing.

And we can use that to inform when we launch DevNet

And I guess, so the next thing, so once we're kind of feeling confident with the DevNets, whether that's after DevNet 9 or potentially if we need more after that.

We started discussing the ordering of testnets on last week's call.

I think it would be good to start to align on the order just because we're going to want to announce the launch of Hulsky, the deprecation of Gorli and all of that.

So even though we don't need to like talk or decide on dates or anything now, yeah, I'd like to just get a feeling from like, what do people think is the right order for them.

My proposal was starting with Hulsky because it's basically new, no 1 will be using it, and I assume there'll be like a pretty controlled set of operator at Genesis.

So it's not a huge group to coordinate to upgrade the testnet.

Then I would probably do Gordy if this is the last fork we're going to do on the network.

I guess the risks of breaking it are slightly lower in a way.

And it's also good because most of the applications and especially the L2s run their test on Gordy.

So it gives them a tiny bit more time to test.

And I would finish with Sepolia just as a final sort of dry run before mainnet.

And by then we'd obviously expect to no longer have any sort of issues.

Yeah, does that generally make sense to people as an ordering?

Do people have preferences or different preferences than that?

We'll probably have a blog post, announcing that host, he went live.

Once it's actually been launched and it's relatively stable.

And that same blog post will also mention that this is the last for Gordy.

And finally as well, There's been some folks working on ephemeri, which is a test net that keeps restarting at Genesys for stakers to test their setup.

So we'll start mentioning that as well, but it's still semi in development.

So we're not going to use it as like a 1 of the main testnets or anything, but I will at least let people know that they can test validators on it and have like a quicker iteration cycle.

And then, Barnabas, you had a PR, I guess, just changing the time on Holsky for, basically removing Cancun until we figure out the time.

So apparently everyone would have an issue overwriting the Cancun time if it's already set once.

So this is something that maybe some clients will have to change, but the peer is still open.

I would just want all the year to approve it before I merge it in because it can potentially cause some issues, especially for our users.

1 more thing that I also think that Holoski should be the first 1 going into Dan Coon.

And we should really stress test the 3 and 6 blobs that we have set up.

So it's going to be a very good test to see if we can handle it.

After that, we could adjust, if needed, down to 2 to 4.

Or if it's deemed reasonable, then I think we can leave it as is.

Because at 1.5 million validators, if that can handle it, then should be good for 2 minute too.

So heads up, adjusting down would be a hard fork.

And so I'd rather, if we did deploy through 6, I'd rather just leave it as is or reboot the net than having like a hidden hard fork for that.

I'm not saying that we should like hard fork Holeski.

I'm saying that we could probably adjust it down for Gradle or Sepolia.

Right, But would that mean, I know on the CL, I assume you can probably set all of this in the presets on the CL.

I don't know if on the EL this would mean we have to maintain 2 versions of the code paths based on the network.

So I don't know how easy it is for the CLs to support different blob counts on different networks.

It seems like a configuration parameter, but sometimes things go deeper than that.

See all Ethereum transcripts on Youtube

Execution Layer Meeting 169 [2023-08-31]