Discussion on final launch preparation for Deneb and outstanding releases

Preparation for Deneb Launch

Updates on mainnet ShadowFork, release candidates, and potential issues

Mainnet ShadowFork and Release Updates

Summary of the discussion on EIPs including Pyrdos, EPBS, Inclusions List, and Maxi-B

Discussion Recap on EIPs

Discussion on the potential features for the Electra fork and the strategy for implementation

Discussion on Electra Fork

Overview of the current issuance policy and its long-term consequences

Casper and Issuance Policy

Discusses the impact of LSTs on solo staking viability and the economies of scale. Also addresses the liquidity value of LSTs and the governance trust layer they add.

LSTs and Solo Staking Viability

Proposes a range of stake participation and an issuance curve to manage participation levels. Discusses the long-term solution and the potential impact if no action is taken in Electra.

Targeting and Issuance Curve

Introduces a curve adjustment proposal with minimal overhead and emphasizes the need for social consensus. Encourages broad community conversation and further research.

Curve Adjustment Proposal

Addresses the impact of changes on staking rewards, decentralization, and actor behavior in staking. Emphasizes the need for decision-making and the comparison of dynamic end game situations.

Staking Rewards and Centralization Pressures

Presents a document outlining the context of SSC EIPs and light client development. Discusses the vision for Ethereum and invites participation in creating a demo based on the outlined ideas.

Light Client Development and Beacon State

- The meeting is focused on final launch preparation for Deneb
- Discussion on proposed issuance curve adjustment research post for Electra
- Updates on releases for Deneb and Lodestar
- Mainnet ShadowFork has gone live with some issues that have been fixed
- No issues reported with the releases
- Questions about testing for shadow ports and Flashbots team release for Mavboost

- The Flashbots team has not released Mavboost yet, but they plan to do so after the ShadowFork
- They have an alpha release running and are waiting for feedback from Lido and film
- The team is discussing various EIPs and their potential inclusion in the upcoming Electra fork
- There are concerns about the complexity of Maxi-B and the potential for unknowns to surface in relation to networking and passing between layers
- The team is aiming to target a 2024 fork and may consider ripping out certain EIPs if they prove too complex or time-consuming

- The speaker disagrees with the idea that ripping out features will delay the project until 2025
- They suggest starting with the existing features and running POCs to check for complexity
- They discuss the potential consequences of the current issuance policy on Ethereum
- They predict continuous inflow of stake and discuss the potential negative impact of high stake percentages
- They suggest creating an IELTS working group to coordinate calls and discussions on the features

- The piece discusses the impact of changes in staking rewards on the Ethereum network
- It proposes a long-term solution called "targeting" to maintain stake participation within an acceptable range
- The proposed curve adjustment is technically trivial and can be easily implemented
- There is a need for more research on how the changes will impact staking actors and profitability
- The decision to include the proposed curve adjustment in Electra should be carefully considered and not rushed

- Discussion on the need for more research and dialogue before implementing a decision
- Presentation of a document outlining the context and vision for Electra and light client development in Ethereum
- Invitation for feedback and collaboration on the proposed vision
- Acknowledgment of the low priority of light clients and encouragement for teams to prioritize it
- Conclusion of the meeting with a focus on mainnet launch and gratitude to participants

- Meeting focused on final launch preparation for Deneb
- Discussion on proposed issuance curve adjustment research post for Electra
- Updates on releases for Deneb and Lodestar
- Mainnet ShadowFork live with fixed issues
- No reported issues with releases
- Questions about testing for shadow ports and Flashbots team release for Mavboost
- Alpha release running, waiting for feedback from Lido and film
- Discussion of potential EIPs for upcoming Electra fork
- Concerns about complexity of Maxi-B and potential delays
- Targeting a 2024 fork, considering ripping out complex EIPs
- Predicting continuous stake inflow and potential negative impact
- Proposal for "targeting" to maintain stake participation
- Need for more research on proposed curve adjustment impact
- Emphasis on careful consideration before rushing decisions
- Presentation of document outlining vision for Electra and light client development
- Invitation for feedback and collaboration
- Conclusion with focus on mainnet launch and gratitude to participants.

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

♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪ ♪ ♪ ♪ ♪ Hello.

Welcome to Awkward Devs Consensus Lair call 2 to the seventh.

We will spend as much time as we need on Deneb today as we're in kind of final launch preparation.

I'm not sure if there's anything outstanding other than quick recap.

Moving on to Electra, I will attempt to give an editorialized outstanding EIP discussion recap, which will certainly be wrong, but maybe we'll spark some discussion.

There is a proposed issuance curve adjustment research post that is out, also discuss.

Then beyond that, generally, Eitan will go over his light client roadmap possibility.

Daneb, I believe we are closing in on releases and attempting to do a mainnet shadow fork and get a blog post out at the very start of this week.

Is there any, are there any outstanding releases, any release that hasn't been put out yet.

Some is releasing be 5 just right after this meeting, we have a V5 release Canada 1 and that's yeah and basically we will promote that to V5.

Same for Lodestar we also have V1.16 RC1 release candidate which is likely to be promoted to v1.16 maybe today or by tomorrow.

Okay on both of those are there Can the people that are running the main net shadow fork.

Can they use the release candidate and begin doing their work now.

I believe it is being used in our case as well.

Are those the only 2 outstanding releases?

And prison was right after the call and load star is doing the same by end of today or what's the timeline recorded.

Yeah I think our CI is running maybe in a couple of hours, it should be out.

Any, Any updates on the mainnet ShadowFork?

Anything that we should know, any issues?

Any error, at least even just the expected timing?

So we had the mainnet ShadowFork go live today.

We checked with both Prism as well as Loadstar that we could use the RC releases instead of waiting and we got the okay from them.

We had Genesis about an hour ago and Dengkun is live about half an hour ago.

There was a config generation issue where the Nethermine config said total difficulty instead of total terminal difficulty.

As a result, the Nethermine nodes offline, but it's been fixed now.

And if you look at the last epoch statistics, we should be inching closer towards a perfect shadowfog.

We're mainly waiting for exiting 1 or 2 values so that we have the funds to spam the shadowfog to begin with.

And once that's done, we'll probably put an update in that.

We have Zatul running as well, but so far, it looks like all the releases are good, and there's no issue report.

So we'll have blobs being attempted to be pushed around the network prior to the port?

And we weren't able to we weren't able to exit any validator in time for having funds that would be double spent on mainnet.

From my understanding, Typically for shadow ports, builder, relayer, and maybe boost are not tested, right?

Usually yes, but this time we got the relay up as well.

We have the validators that are just there as well, but we're having the same problem as with blob spamming.

We normally like, there's just not much traffic.

So locally blobs are, there's no point for the bids to be higher.

So we need the validator exits to happen so that we can run this tool called MevFlood and that'll create the juicy builder transactions and after that point, it's picked up by the network.

Any other questions about the shadow fork?

I think the Flashbots team hasn't made a release for Mavboost yet.

As far as I know, they wanted to wait to see how the ShadowFork goes before they make the release, but they should be making 1 soon.

We have an alpha release that's running since a couple of test net upgrades, and we wanted to test it on Maynard, but couldn't get the feedback from Lido or, or film.

And if that goes well, we take a warm dot 7 release by Monday.

Barry, any other updates from the DevOps team or testing in general?

Okay, I believe Tim is looking to publish blog posts on Monday.

So, we'll be monitoring for those final releases and keeping an eye on the shadow for between now and then.

Okay, I'm going to attempt to do an editorialized EIP outstanding discussion recap.

I will get it wrong and we can go from there.

Obviously we're kind of at this juncture where we do have some baseline EIPs that we're eager to see.

A couple of those are cross-layer and have some agreement on there.

Certainly want to begin building those into a single build and getting some tests out so we can move forward.

There are a number of things that have been a bit of sticking points.

The past month or so, we had a breakout calls.

I'll start with what I think is an easy 1.

My read on Pyrdos is that It is, and regardless of the fork, a major R&D item that a number of people across most, if not all the teams do want to be digging deep into.

Specifications are getting into a reasonable place as Argus done some R&D and as Lighthouse is beginning to pick up from there.

So the intention there would be to parallelize.

This does not need to be launched with a hard fork, but it does need to be launched at an epoch coordination point, unless we did some additional work.

I'm not 100% sure that we could do it in a non-breaking way, but I have some ideas there.

And the question becomes when to introduce a data gas limit increase EIP.

If this was done far before Electra, then we could be talking about it in relation to Electra.

If not, we can be talking about it either in relation to an isolated single fork.

This does have to be cross-layer in the way it's specified or in the next 1.

But essentially this can be a heavy parallelized R&D item.

My read from that breakout is that although we continue to hold this as a high item, that we're given time and constraints and given where the state of research specifications are.

It's not ready to be put in for Electra, but there is a lot of appetite to dig deep on here.

I know there are some people on the spectrum of, It's just a matter of putting the pieces together.

There's some people on the spectrum of, we need to do more fundamental research in design and understanding.

So this can also be a major R&D item, But we need to be hitting it.

I think that there is a steady flow on the peer to us stuff, on the EPBS stuff, there is not.

There's some people that are trying to keep it moving.

It could be a target at upcoming interop.

It could be a continued kind of series of calls, but we do need to kind of, if that's going to move out of where it is right now, it needs to have more consistent work done on it.

On the inclusions list stuff, my understanding is that It is less complex than I expected.

So it's not just a decision that we can make here.

And it is, it does have the potential for more unknowns or gotchas surfacing than some of the other stuff that is currently in Electra.

Just given the EIPs that are in Electra, it's just a matter of making sure specs are sound and writing good tests.

IELTS are close to that, but I have a little bit of, I think it could, unknowns could surface in relation to potential networking, in relation to the complexities of passing things between layers, that I'm not sure, I'm not certain.

But it could be something that gets added to Electra, depending on appetite.

It could also be something that could be ripped from Electra in the event that we do hit unexpected complexities.

And then Maxi-B, that conversation, I think there's a lot of agreement that it's very valuable and important.

I think there's enough concern around complexity in the context of the current fork that it's not currently being pushed actively and likely unless it gets rekindled very soon.

I think the biggest question mark would be IELTS and getting a temperature gauge based off of what happened in that prior, in that call last week.

I saw, you know, Agenda in the chat saying plus 1 for Electra, but I don't have a read beyond that.

Dappline does say Max-EB is not that complex in the chat.

My read is that that ends up being a bit architecture dependent in some of the assumptions that are based in architecture.

So maybe that is true with Lodestar, but there's at least concern from the Prism side that it is.

And Potos wants to agree on the scope of Electra.

I believe that's probably with respect to timing.

My read on scope, intended scope, almost across the board is that people want to push for a 2024 fork.

2024 fork, that doesn't necessarily mean that it launches in 2024, as we know, but pushing, having an intended target will help keep things moving.

That is why when I mentioned IELTS, that they could potentially be, you know, there's an intuition that maybe they're not that complex, but that we could rip out in the event that they are.

And that's why I did specify it in kind of that conditional manner.

I think no 1 wants to open up a, the same with the peer to us stuff.

We get the ability to kind of work on it, not integrated.

But then think about how to launch it when it's ready.

A bit of a different strategy than what I proposed for the IELTS.

But nonetheless, I do believe that on both EL and CL, there's a desire to scope things in a way that 24-4 is at least realistic.

And thus, potential strategy is ripping something out if that doesn't allow us to target.

Agenda agrees on the include IL ripout conditionally.

Enrico says, if we want to target 20 for the 3 IPs that are currently in there, was a tentative IL.

I put a starting work on something that's potentially ripping it out is equivalent to scoping for 2025.

Given the EIPs that are currently scoped, obviously production grade quality is 1 thing, but these are likely features that with good tests could be written on the order of 2 to 4 to 6 weeks.

As that 1 said some volunteer working groups could speed around PCs by a CDC.

So, a lot of that, given, depending on where engineering resources that like, could be done very quickly, and then it's a matter of honing.

IELTS are a bit of more of a question mark, but intuitively don't seem like that much complexity.

And so I think the base could be written very quickly, not including IELTS.

And then there can be some side sprint on POCs in that domain to see.

So I don't necessarily agree that the ripping out strategy does mean that we end up in 2025.

I do see that if it's not handled with care, or that we don't acknowledge the complexity when we hit it soon enough, but that could become the case.

I do think the dependency on the on el and el also quickly being done with a lot of this stuff would hold us a bit more honesty here, potos.

Yeah, I don't mean that the board is going to be it's equivalent to scoping the poll for 20 25.

It's just that if we start working on some features and we're going to divert some of our people and we don't we aren't large things at present, I think currently there's less than 8 people that are actually actively coding.

If we're gonna divert some people to work in some of these features, and these features have chances of having trouble and being ripped, then those features, I consider that those features are equivalent to being scoping them for 2025 with the hope of getting them into a fork for 2024.

If that's the actual status of what we're gonna be doing, then I would rather have a different discussion of what are the large R&D objects that we might want to see in this fork or not.

I wasn't under the impression that the broad consensus was that this fork should be small without any larger R&D objects.

I think the sticking point is RIL is actually a large R&D object.

The read from a number is that they're not quite in that domain, but that we can be careful nonetheless.

There's another component of the IELTS discussion, which is their cross layer.

And I don't believe that we have brought this to the execution layer at all, in terms of the discussion, unless I missed something, nor do we have much read on that.

Yeah, I was just gonna say, we've talked a good bit to the execution layer teams.

Yeah, I think in general, the vibe there is that the complexity is not too high.

I think if we wanted to prototype with someone like

we would be interested in kind of trying to speed run something too.

Yeah, also, I guess the Besu team, or I mix up Teku and Besu, but yeah, the consensus team that does the execution client is also involved in the discussions.

So, I wouldn't say they're flying blind for sure.

So 1 strategy is to begin the Electra build with the 3 IPs that we currently have and to, as has been stated by Mike and others in the chat, speed run POCs to do a complexity sanity check, such that at plus 2 or 4 weeks from now, we can make a very clear and conscious decision whether this is an R&D item with unknowns, or if this is a easier bread and butter fork that we can just, or bread and butter feature that we can integrate into Electra.

I mean, this would, the onus would be on probably Mike and a handful of others to coordinate that speed run and to report on that speed run.

I appreciate the dynamic verbal feedback I'm getting.

I do think it's time to begin to build what will look like an Electra fork with the features that exist that are agreed upon.

And in the event that in the next month we have reports back from a POC speedrunner group, then we can see where IELTS fit into that build.

Yeah, so Taryn's asking if we need another call like working group.

I do think for coordination purposes, if there's not a good explicit place in the discord yet, let's do that.

Let's add a kind of an IELTS working group chat.

And then that feed around group can and should coordinate whatever calls are necessary to do so.

They don't, they should probably lean towards the public, you know, like dropping a call link into discord and scheduling.

I don't know if they, because it's more of a kind of engineering sprint I don't think they need to be recorded or I don't care.

They don't see the utmost importance to the surface as a reportable.

I will let y'all coordinate in the chat or in Discord, and we'll go from there.

Are there other discussion points related to these 4 EIPs that I attempted to summarize?

Are you here to discuss this ETH Magician's Post?

So basically, we just wanted to briefly kind of mention Casper and I.

We also briefly talked about it already, I think, 2 calls ago.

We've been working, looking into kind of the current issuance policy on Ethereum, looking at the trend there, the long-term consequences.

And we just published 2 posts, and 1 of them has at least, is for Australian collectors.

So the first post, Kasper is putting them in the chat right now, is just a more general kind of look at the current issues policy and looking at what happens if we basically don't do nothing and stay on it forever.

And the argument there that we make basically is that with the advent of LSTs, the way to say it is basically the supply curve for stake has been flattening a lot.

So more and more ETH holders are now potentially willing to participate in staking because it's so much easier with LSTs.

And because our current issuance curve still pays out significant rewards all the way kind of to potentially like up to 100% stake, That means that in the long term, it's not clear where exactly there would be an equilibrium in terms of stake.

And indeed, since the beginning of the beacon chain, we've seen a continuous inflow of stake.

And we at least predict that this will not stop anytime soon.

We then looked a little bit into what would be the consequences of basically more and more.

And at some point, maybe say 60%, 70%, 80%, 90% of all each stake.

We have several reasons why we think that that would be bad for the network.

It's probably too much detail to go into them much right now.

But basically, just the intuitions being that for 1, it harms solo staking viability because LSTs just have economies of scale where the more and more percent twice or in absolute terms as well, they have under management that the more lean and efficient they get and the harder it is to compete.

They also become, specifically their liquidity that LSTs give users becomes more valuable as those LSTs are more widely adopted, which they would be as basically they become the dominant money token on Ethereum.

Also, just for the general protocol, It basically would mean that over time, most currency holders would basically do this via these intermediated entities, which means it just adds a governance trust layer.

At some point, they could be too big to pay out, bail out considerations.

We have, like, we laid out kind of why we think that that would be a bad outcome, pretty much in detail.

And then we have a proposal for basically what the end game could look like for operations policy, like basically something that we could go to that then could be sustainable for the long-term future.

So basically, the idea is we would specify some sort of, we would pick some sort of range of stake participation that we think is acceptable.

That could be something like, I don't know, 20% to 30%, or like something 10% to 40%, some broad range that we pick that we think is acceptable.

And then we just pick an issuance curve that you can think of it like today where as we, as, as, as participation drops a lot, you know, issuance rewards shoot up a lot because we really want to make sure that not everyone leaves.

And we could do the same thing on the right side as well, where basically if we, if we go too far beyond the maximum range that we like, basically issuance rewards go all the way down to 0, or maybe even to below 0.

And that way, we could really basically also guarantee a hard stop.

And then we looked at this long-term solution we proposed, and it still has some open questions.

It's very unlikely that we could get there for Electra.

Seems like people already have their focus on other things.

So we then looked at what happens if we basically don't do anything about this in Electra.

Of course, it's not quite here, but in Osaka, the next book would come.

But it could easily be, say, 2 years from now, or like a year and a half to 2 years.

And if you do nothing for 2 more years, basically, with the current kind of maximum inflow that we also, we kind of, we, we, we, we, we, of course, with the net, we ship this kind of maximum rate of new inflow, but even, even with that maximum rate, we could have up to say 40 million additional ETH coming in over the next 2 years.

Of course, it's not guaranteed that it will actually be 40 million, but it could be quite a bit.

And so that would already be quite unfortunate in our views, especially because also once we would want to move to targeting afterwards, if we are way beyond the range, we would end up wanting to target.

See all Ethereum transcripts on Youtube

Consensus Layer Meeting 128 [2024-2-22]