All Core Devs - Consensus #128

Transcript

[Music] e J

[Applause] all

for in hello welcome to award Doon Slayer

Danny Ryan: call

2 to the 7th this is issue 966 in the PM repo uh we will spend as much time as we need on denb today as we are in kind of final launch preparation I'm not sure if there's anything outstanding other than quick recap um moving on to Electra I will attempt to give an editorialized outstanding EIP discussion recap um which will certainly be wrong but maybe we'll spark some discussion uh there is a proposed issuance curve adjustment research post that is out we also discuss um then uh beyond that General Aton will go

over his like client road map possibility cool um DB uh 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 um how are we doing on releases is there any are there any outstanding releases any any release that hasn't been put out yet

um PR is

Terence Tsao: releasing V5 just right after this meeting we have a a V5

release candid one and that's yeah and basically we will promote that to

V5

Gajinder Singh: same for loar we also have uh V1 .6 rc1 release candidate which is likely to be promoted to v1.16 maybe today or by tomorrow

Danny Ryan: okay on both of those are there can can the um people that are running the main at Shadow Fork can they use the release candidate and and begin doing their work now

yep it it is exactly the same

Gajinder Singh: I believe uh uh it is being used in our

case as well

okay

Danny Ryan: are those the only two outstanding releases I'll take that as a yes in prison was right for the call and load star is doing the same by end of today or or what's the time being recorded

Gajinder Singh: yeah I think our CI is running maybe in couple of hours it should be out it could be sooner

Danny Ryan: great um any any updates on the main at Shadow Fork um anything that we should

know any issues any or at least even just the expected timing

Parithosh Jayanthi: yeah I can give an update on that so we had the main natur for go live today um we checked with both prism as well as loar that we could use the RC releases instead of waiting and we got the okay from them um we had Genesis about an hour ago and tenun is live about half an hour ago there was a config generation issue where the nethermind configs had total difficulty instead of total terminal difficulty as a result the nether man no offline but it's been fixed now and um if you look at the last Epoch statistics we should be inching

closer towards Shadow f um we haven't started spamming blobs yet we're mainly waiting for exiting one or two Val so that we have the funds to spam the shadow for to begin with and once that's done we'll probably put an update in there we have zatu running as well but so far it looks like all the releases are good and there's no there's no report

Danny Ryan: so we'll have blobs being attempted to be pushed around the network prior to the fork

Parithosh Jayanthi: uh no we weren't able to we weren't able to exit any validator in time for for having funds that would be double

spend on

Main

Danny Ryan: got it any questions for the devops team

Terence Tsao: I have a one quick question from my understand understanding typically for Shadow Force Builder relay M boost are not tested right is that is that a correct statement

Parithosh Jayanthi: uh usually yes but this time we got the relay up as well uh we have and then the validators are register as well but we're having the same problem as with blob spamming um we normally like there's just not much traffic so locally block blocks are great there's no there's no point for the bids to be

higher um so we need the validator exits to happen so that we can run this tool called Mev flood and that will create the juicy Builder transactions and after that point is pi up by the network

Char

Terence Tsao: thank you

Danny Ryan: any other questions about the shadow of work

Parithosh Jayanthi: uh just one point about the releases I think the uh flash but team hasn't made a release for MAV boost yet um as far as I know they wanted to wait to see how the shadow for goes before they make the release but they should be making one

soon

Chris Hager: yeah that's pretty much it um we have an alpha release that's running since a couple of uh test net upgrades and we wanted to test it on mainnet but couldn't get the feedback from Lio or or so we are waiting for the shadow fork and if that goes well be tag a1. 7 release by Monday

Danny Ryan: great Barry any other updates from the devop team or testing in general cool

anything else related to denb okay um I believe Tim is looking to publish blog post on Monday uh so we'll be monitoring for those final releases and keeping an eye on the Shadow for it between now and then great work everyone okay um I'm going to attempt to do an editorialized EIP outstanding IP

discussion recap um I will get it wrong and we can go from there uh obviously we're kind of at this juncture where we do have some baseline eips that we um eager to see a couple of those are cross layer and have some agreement on there um certainly want to begin building those into uh a single build and getting some tests out so we can moving forward there are a number of things uh that have been a bit of sticking points the past month or so we had a couple breakout calls um I'll start with what I think is an easy one um my read on P us is that it is and regardless of the fork a major

R&D item uh that a number of people across most of not all the teams uh do want to be digging deep into uh specifications are getting into a reasonable place as Argus done some some R&D and as lighthouses begin to beginning to pick up uh from there so the intention there would be to paralyze uh 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 um additional work I'm not 100% sure that we could do it in a non-breaking way but I have some ideas there anyway probably coordinate on Epoch and then the

question becomes um 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 could be talking about it either in relation to an isolated single Fork this does has to be cross layer in the way it's specified um or you know in in the next one but essentially this can be a heavy parallelized R&D item um we did have a breakout around epbs my read from that breakout is that uh although we continue to hold this is

a high item that were given time and constraints and given where the state of research specifications are um 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 putting the pieces together there's some people in the spectrum of we need to do more fundamental research in in design and understanding um so this can also be a major R&D item um but we need to be hitting it um you know I think that there there is there is a kind of steady flow on the peros stuff on the epbs stuff there is not there kind of

fits and spurts there's some people that are trying to to keep it moving um it could be a Target at upcoming interop it could be a continued kind of series of calls U but we do need to kind of if that's going to move out of where it is right now um it needs to 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 I think some others expected um it is cross layer so it's not just a decision that we can

make here and it is um it does have the potential for more unknowns or gotas surfacing than some of the other stuff that is currently in Electra um just given the IPS that are in Electra it's just a matter of U making sure specs are sound and writing good tests we've done this kind of stuff before IL are close to that but I have a little bit of uh you know I think it could unknowns could surface um in relation to potential networking in relation to the complexities of passing things between layers I'm not I'm not certain but uh it could be something

that gets add 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 uh complexities um and then Maxi B that that conversation I think there's a lot of agreement that it's very valuable and important I think there's um enough concern around complexity in the context of the current Fork that it's not currently being pushed actively and likely unless uh gets rekindled very soon we put on ice now that's my read on those things um I

think the biggest question mark would be IL and getting a temperature gauge based off of what happened in that prior in that call last week um I saw you know gender in the chat saying uh plus one for Electra but I don't have a read beyond that uh dline does say Max EB is not that complex in the chat um I my read is that that ends up being a bit architecture dependent in some of the assumptions that are B based in architecture so maybe that is true with load star but there's at least concern from the prism side that it it

is um and poto wants to agree on the scope of Electra I believe that's probably with respect to timing um my read on scope intended scope almost across the the board is that people want to push for a 2024 Fork 2024 Fork that doesn't necessarily mean uh that it launches in 2024 as we know but pushing having a intended target will help keep things moving um that is why when I mentioned ILS that they could potentially be you know there's there's an intuition that

maybe they're not that complex but that we could rip out in the event that they are um that's why I did specify it in kind of that conditional manner um I think no one wants to open up a the same with the pios stuff um we get the ability to kind of work on it not integrated um but then think about how to launch it when it's ready um a bit of a different strategy than what I proposed for the is um but Ness I do believe that on both El and cl there's a desire to scope things in a way that 244 is at least realistic um and thus potential strategy is ripping

something out if that doesn't be allow us to that Target okay so I do see sorry I'm catching up one gender agrees on the ripout include I ripout conditionally um enrio says if we want to Target 2024 the three eips that are currently in there plus the tentative I um I starting work on something is

potentially ripping it out is equivalent to scoping for 2025 I'm um I'm not certain I agree I I the given the the eips that are currently scoped um obviously production grade quality is one thing but it these are likely features that with good tests um could be written on the order of two to four to six weeks um as dline said some volunteer working groups could speedrun people es by ACDC um IL 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 um ILS are a bit of more of a question mark but intuitively don't seem like that much complexity um and so I think the bass could be written very quickly not including ILS and then there can be some you know Sid Sprint on pcc's in that domain uh to to see so I I don't I don't necessarily agree that like the ripping out strategy does mean that we end up in 2025 I do see that if it's not handled with care um or that we don't acknowledge the complexity when we hit it soon enough

that that that could become the case um I do think the dependency on the on El and El also quickly being done with a lot of this stuff would hold us ail more honesty here

po

Potuz: yeah I don't mean that the port is going to be it's equivalent to scoping the whole for for 2025 it's just that if we start working on some features and we're going to divert some of our people we don't we aren't large teams uh at prism I think currently there's less than eight people that are actually actively coding if we're going to divert some people to work in some of these features and these features have chances of having trouble and being 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 for for 2024 if that's if that's the actual status of what we're going to 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 I was under impression that the broad consensus was that this Fork should be small without any large R&D objects

Danny Ryan: I agree with that um to a certain extent I I think the scking point is are I's actually a large R&D object

um the read from a number is that they're not quite in that domain uh but that we we can be careful nonetheless um there's another component of the is's discussion which is their cross layer um and I don't believe that we have brought this to the execution layer at all in terms of the discussion unless I miss something nor do we have much read on that Mike do you have

we to the execution layer

Mike Neuder: yeah I was just going to say we've talked a good bit to the execution layer teams um yeah I think in general the the vibe there is that the

complexity is not too high um I think if we wanted to prototype with someone um like ref would be interested in in kind of trying to speedrun something too um yeah also I guess the Bess team or sorry I mix up teu and Bess but um yeah the consensus team that does the execution client is um you know also involved in the discuss discs so I I wouldn't say they're Flying Blind for sure

Danny Ryan: right so one strategy is to begin the Electra build with the three IPS that we currently have um and to as has been stated by Mike and others in the chat

speedrun poc's uh to do a complexity sanity check such that at plus two or four weeks from now we can make a very clear and conscious decision whether this is in R&D item with unknowns or if this is a easier bread and butter Fork that we can just a bread and butter feature that we can integrate into Electra

is anyone against that strategy um I mean this would the onus would be on probably Mike and a handful of others uh to coordinate that speedrun and to

report on that speedrun yes affirmative all right I appreciate the dynamic verbal feedback I'm getting um okay I do I do think it's time to begin to build um what will look like an electr fork with the the features that exist um that are agreed upon so we'll begin working on that and in the event that in the next month we have reports back from

a PST speedrun group then we can um see where ILS fit into that build yeah so terence's asking if we need a another call like working group um I do think uh for coordination purposes if there's not a good explicit place in the Discord yet let's let's do that let's add a kind of an I's working group uh chat maybe there is something already um and then that speedrun group can and should coordinate whatever calls are

necessary um to do so they don't they should probably lean towards the public uh you know like dropping a call link into Discord and 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 or I don't care they can be recorded you can do whatever you want um they don't see utmost importance to surface as aort call okay I will let y'all coordinate in the chat or in Discord um and we'll go from there are there other discussion points

related to these uh for eips that I attempted to summarize cool um ongar or Casper are you here to discuss this um e magician post yes oh wanted hello hello yeah we can hear you okay yeah I

thought okay

Ansgar Dietrichs: yeah sure hi everyone um so so basically um we just wanted to briefly kind of mention kasan and I um we also briefly talked about it already I think two calls ago um we've been working um looking into kind of the current uh issurance policy um on ethereum looking at at the trend there the the long-term kind of consequences and we we just published two posts and one of them has at least is relevant for Lector so we want to briefly mention them so the first post um Kasper is putting them in the chat right now um is just a more General kind of look at at the count issuance policy and and looking at what what happens if we if we basically don't like do nothing and stay

on it forever and the argument there that we make basically is that um uh with uh with with the Advent of lsts kind of the the um the way to say it is Bally the supply curve for stake has been has been flattening a lot so more more and more eth holders are now potentially willing to participate in staking because it's so much easier um with lsts and because our current issuance curve still pays out significant rewards all the way kind of to to potentially like up to 100% stake that means that in the long term it's not clear where exactly kind of there would be an equilibrium in terms of stake and as and indeed you know since the beginning of the beacon chain

we've we've seen a continuous inflow of stake and we we at least predict that this will not stop anytime soon um we then looked a little bit into what what would be the consequences of of basically like more and more and at some point maybe say 60 70 80 90% of all each stake and we have several reasons why we think that that would be relatively bad for the network it's probably too much detail to go into them to much right now but basically just the intuitions being that um for one it it it harms solo staking viability because lsts just have economies of scale where the kind of the more and more kind of percentage wise or in absolute terms well they have under management the basically the more lean they and efficient they get and the

harder is to compete they also become specifically the liquidity that lsts give give users becomes more valuable as those lsts are more widely adopted which they would be as as basically they become the the the dominant kind of money token on on on etherum um also just for for kind of for the general protocol um it basically would mean that over time most most curreny holders would would basically do this via these intermediated entities which means it just adds a governance trust layer it adds a risk factor at some point they could be kind of too big to fail bailout kind of considerations it just we you can go through the document we we like we we laid out kind of why we we think that that would be a bad

outcome um pretty much in detail um and then we we have a proposal for basically what the the end game um could look like for fors policy like basically something that we could we could go to that then could could be sustainable for for the long-term future we we call that targeting so basically the idea is we would specify some sort of we would we would pick some sort of range of of St stake participation that we think is acceptable you know that could be something like I don't know 20 to 30% or like something you know 10 to 40% some some basically some broad range that we pick that we think is is acceptable and then we just pick an issuance curve that you know you can think of it like today where as as we as as as participation drops a lot you know issu Ro shoot up a

lot because we really want to make sure that not everyone leaves right 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 zero or maybe even to below zero um and that way we could really basically Al guarante had had stop so that's kind of that that was the the broad research post and then um we looked at this kind of this longterm solution we proposed and it is still has some open questions it's very unlikely that we we could kind of get there for Electra that will require basically big sprint on this seems like people already have they focus on other things um so we then looked at what happens if we Bally don't do anything about this in lecture

in you know of course it's not quite clear what Osaka the next book would come but could easily be say two years from now or like a year and a half to two years and if you do nothing for for for two more years basically um with the current kind of Maximum inflow um that we also we we kind of we we we we um of course with the NP we Shi this kind of Maximum rate of 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 two years of course it's not guaranteed that it will actually be 40 million but it could be quite quite a bit and so that would already um be um quite unfortunate in our views especially because also once we would want to move

to targeting afterwards if we are like Way Beyond the range we would end up on the new Target it's quite painful to come back down because you basically have to set incentives so low that people literally are pushed back out of the staking set which is not ideal um so then we looked at like what could we do in Electra um that basically just is is Absolut like minimal minimal kind of overhead for in terms of the the f I mean we've already talked here about how there's limited room in in in the fog and we came we B we came across this um this curve uh that that Anders came up came up with he also briefly presented this two calls ago if you remember um and the nice thing about his curve is

that on a technical side it's trivial like we I'm not sure Kasper yeah Kasper also already linked the the spec change it's it's literally on line change so so it would be completely trivial on the technical side would not be a blocker for Electro anything we could easily do this and so now it becomes really more a social consensus thing of course any issuance policy change Always is going contentious um and so we are fully aware of this so so we're just proposing it now hoping that we could have kind of enough of a broad conversation both here and of of course the broader Community to to to make a decision whether to include this in elect or not in time um and of course we could go into more detail like show the exact properties of of kind of this proposed curve and

everything I don't know this seems maybe a bit much for now um but we are happy I don't know kaspa maybe if you want to add something to what I just said but otherwise we also just happy to answer questions now or maybe give people time and then on the next ACDC kind of talk about it more in detail Casper do you have anything to add

no sounds good

fle

yeah hey folks I'm Vil from Lio um thing I want to talk about here is in response to this is I think that one uh there is a like a barrier for like there needs to be more research on

how this impacts the actual octus and staking the research on like how this impact profitability and like isance Etc is solid but what would happen like how would people behave how actors and Sten will behave when these changes uh happen is pretty important because I think that uh like this is reducing the decentralization budget for etherum and this might like if this change happens right now it's basically reduces the uh staking rewards by 30% and uh as um like I think about like 70 or 80% of

uh um other in staken right now is on delegators it's directly cut cutting into uh like not operator budget uh by 30% like the calculation about expected value of like how much is uh costing etc etc it's it's not going to play into this the budget is like if on uh on staking rewards uh and this means that the oors that have the best ability to cut costs on margin which means the largest actors and the actors have the ability to Vertical integrate and increase the uh the margin by like uh external ways this

is exchanges this is raking this is potentially um some um like uh more involved um um me uh capture than it is right now uh like private M things and stuff uh will have like a major upper hand uh in this world and um I don't think that like limiting stake amount of other and stake wi outweighs the like was you f data set yeah

Ansgar Dietrichs: uh yeah uh thanks thanks for the

comment and I I actually think there was a lot a lot in there that that I do agree with of course overall the the argument was we should not do this but still I think I think a lot of a lot of these these um problems are very much real the problem really is that is it's not that we are we have to make the decision between making and this being do doing something and not doing something if we if we decide not to include anything in Electro we implicitly also make a decision right and that's really important to understand because the current situation for staking is great I agree if we could just freeze that in time perfect we can't uh so so if we don't make make a decision we implicitly basically just allow for for for this for for just to for us to just keep sliding on this

existing cve and then basically two years from now or a year and a half from now we are also in a place where yields have come down just as much because because because again kind of like that that's kind of how the C curve works today as well so we have the exact same problems right and that's exactly kind of what motivated Us in the first place if we don't do anything by just sliding further and further up the curve we run into the exact same problems that there's less and less profitability more and more centralization pressures and so um the main point here to understand is that we we are comparing the the kind of the dynamic endgame um situations not just the the situation today and so if we do nothing then we would end up with a equilibrium amount of each stake

that's much higher than if we do the adjustment if we do the adjustment yes there's a onetime reduction but then basically you stay at a lower level and so if you compare that to the outcome of doing nothing it's not it's not it's not actually that the yield would go down actually in our in our post make the argument that we think it's very likely that even with with this curve adjustment the the the equilibrium outcome yeld would would be higher but I also agree and just a second comment you said that we should not rush into this and I totally agree and that's why I think we just wanted to basically start the conversation here because the technical set of this is so trivial I think this could be added to Electro basically up to the last moment of when we still have Electro open even

to small changes um and we should definitely take the time for this decision until then and this is not something where we should brush a include or not include decision anytime soon

apiz did you have a comment uh Asgard

Potuz: just made my comment this is just a trivial implementation it's just one liner so why why aren't we pragmatic and just keep research currently there's only research by Ansgar and kaspar why don't we just keep researching this problem until we see enough Mass we can just in the last very last minute just implemented is a

oneliner

Danny Ryan: yeah and I I think that's probably reasonable uh but to prime the pump so that we can have that

conversation in not a crazy rushed seemingly way at the end now is a good time to prime the pump and to decide what other research should be done um and how to go about potentially making s decision um all right thank you onar thank you Casper thank you others for comments um this is not I mean this isn't unless I misunderstand this is not even an AP at this point but this is a

um a set of research and a a dialogue that can play out out over the coming months um assuming that more research happens more discussion happens um and we can we can bring it up here as that does any other comments for today on that one cool thanks guys um anything else on Electra

okay um ton has a like client

road map possibility document uh that is in the chat I'll share the linkon do you want to go over any components of this

Etan Kissling: sure um I mean it's a document that describes um more or less the context in which those SSC eips and also the Light client development itself fits in um right now if you just look at one of the eips it's very technical doesn't really um explain on its own where it could fit in a larger road map and I think there are two important points

there um the first one is like this this entire s SS fication thing which enables the proofs on the execution side and further down the road also leads to decentralization of jsonrpc um because that needs proof If you don't have a trusted server anymore and I also added to this document a similar um thing for the beacon state where we can decentralize the checkpoint sync over time uh with something called Beacon State SNAP sync

Sahari presented an idea last year in Austria about it as well and that one also needs a tiny change to be can State as the proposal is right now for enabling backfilling of light client data in a canonical way so the two things that could be done in Electra to enable all of this are this backfill enabling on the consensus side and also the SSC proposals for transactions receipts um and the the three Roots like those mer Patricia

tries so I'm inviting everyone to just read this document and see if this vision is something that aligns with where ethereum should go um and also if someone wants to hack along I think creating a demo that actually is based on these ideas would be interesting as well and could be a small Shadow fork with like one e or so just to see how these SSC transactions would work in practice I mean right now I have the website the eth light XYZ it works by locally converting everything from Manet but it would be

nice to have it in an actual e as well yeah that's um what this document about

Danny Ryan: thank you um yeah I mean my my take here is that like clients unfortunately are the seventh to 10th priority on everyone's list all the time um so I appreciate you putting this document together and I I would encourage you know the person on each team that is paying attention to like clients uh to please take a look at this and and comment um but any questions for

today okay any other comments on this okay um any other discussion points great uh we'll keep our eye on that main that shadow fork and keep moving forward with this main net launch congrats everyone thanks talk to

you all soon by thanks everyone bye you thanks everyone you

by time he

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.