All Core Devs - Consensus #126

Transcript

[Music] [Applause] h for

in

Danny Ryan: all right we should be live welcome to

cons Slayer call lward devs 126 this is issue 938 in the PM repo uh first off we will have uh and just discussions related to neb testing test Nets Etc then we will begin our discussions around Electra next planned upgrade hard Fork on the consensus layer um and then a quick discussion or note around um some research around State participation targeting cool so we go ahead and get started um there was a blog post yesterday maining releases for I believe

all main net clients um for the the next denb denune test Nets um any notes on that other than the existence all right great um if you are running validators please upgrade if you run noes and Leets please upgrade if you plan on using uh blobs it is time to test them um any other discussion points around testing test NS or anything

related to denb for today okay great next up Electra

so there is an issue in the specs repo uh this is 3449 in the specs repo cons specs repo here's the link okay thank you time uh this is going to be we're going to move through this list uh we may or may not get to

everything today um and the general format will be quick one of the authors should give a quick High description of the EIP um and then just some notes on relative complexity you know in general maybe some comparisons to Prior work uh the components it touches and and if it's cross layer um and then uh open for for General discussion I do appreciate the teams that did uh have some brief posts on what they are eager to support and not support for the fork uh but please also do Elevate that here either as individuals or as a team um just so that

everyone gets on the same page cool uh any questions or thoughts before we get started here okay um this is the beginning of this process uh this doesn't necessarily mean that uh all decisions will be made today um and especially as kind of specifications become refined and packaged and and people doal prototyping obviously like this conversation will continue as it has in the past um Okay cool so looking at that list uh the first EIP on there is EIP

6110 is mik here

Mikhail Kalinin: yeah I'm here can speak on it yeah cool okay so yeah this uh the CIP basically uh deprecates eth onean Bridge uh that we still have today uh to bring new deposits uh uh into the beacon chain so it uh yeah and with the deprecating Ean Bridge we deprecate uh also one data voting uh and uh um the things related to it like dependency of Cl um on the jasonp CPI because currently today deposits are being patched by jasonp CI uh from uh

execution lay clients which is kind of maybe stressful for execution lay clients uh sometimes and also it creates some problems with the configurations uh from time to time uh of for not operators and developers have to solve those problems also it's ever growing um data complexity because all those deposits um are required to reconstruct the deposit tree to process new deposits and this is done by CL clients today when they are uh sying with the chain yet it will be fair to say that there is an alternative proposal to cut

this um complexity which is basically deposit deposit contract uh yeah depository snapshots um which is yeah there is an EIP for that yeah but this is kind of our ultimate solution for getting rid this E1 Bridge also a related thing is the security of the protocol uh there is a design flaw that's uh uh yeah we know for uh several years already and yeah for main that this is not an issue but yeah for General the protocol practically it's not an issue because it requires a lot of uh adversarial stake yeah and um it requires uh L work

as well it requires change but on the L side it is very well scoped and the change is really minimal um pretty um kind of isolated and in terms of testing and in terms of um implementation um and well there is already a prototype in Lighthouse and bzu and I know that other teams are working on prototyping this EIP we ran several Deets uh during the prototyping phase um to to to see how it works how it plays out so and uh I would say that spe specifications are pretty mature um yeah

and we did some fixes after prototype in Phase also I would like to say that uh on the activation uh like when this EAP uh is activated in the network when the change is activated it does not require any further um coordination on the transition period uh from e one data bridge to this new mechanism so it will have it's pretty deterministic um and will happen automatically and uh e one data bridge will be able to uh be deprecated uh thereafter after this transition period finishes which is like several hours uh and yeah it can be done in uncoordinated

fashion so that's mainly sorry for being hectic on it I did not prepare a presentation but that's the kind of summary on

the C

Danny Ryan: no that that's perfect I think most people for most of these eips have pretty deep context so just a brief overview is really great um I guess I think almost everyone's call understands like the security of of what you could call this eth1 bridge or the deposit Bridge you know has this uh honesty assumption on on proposers over a certain time Horizon um rather than just a straight validation of of these two systems that are now connected and

related to each other and so it's certainly like a major security Improvement although an unlikely in normal circumstances place for an attack to happen um are there any questions around this EIP uh both security featur set complexity and you can hear okay um I I believe that there has been General signal for support um on the execution layer was that Tim would you

call that like unanimous meaning in the event that the cons layer wants to do this uh you know and no further issues or um having to PR things due to complexity like that this would be moving forward as of now

Tim Beiko: yeah so I think 6 one one Z and 702 7002 are the two where if we have to start working on a devet tomorrow um along with another one that doesn't impact us yell um it seems like all yel teams would start working down that so yeah

Danny Ryan: yeah cool um is there any are there any cons teams that are not supportive of this

in uh electri as of their understanding of the fork today I say not because I've seen a lot of signals for support in both some of these blog posts as well as uh in the chat okay uh generally very positive signal on this on both layers um I don't know if we have like ter terminology official terminology to use here but uh as of now 6110 can move forward in

Electra um next EIP EIP 6914 uh reusing validator indices D line do you want to take this one

dapplion: sure so I can quickly say say that DP is useful in the long term but it's not a time to roll it out so very bevely I would say we should skip it for the fork um I'm not sure if any team wants to include it for the fork but I don't I'm not sure if that is wise I did write a hackmd I can link it on the notes but

that would be all for now

Danny Ryan: okay um does anyone want for further detail on what this EAP entails or does anybody want to make the case for inclusion okay and I'm seeing um from a couple of different teams kind of a general agreement that no need to prioritize this in the upcoming Fork cool thank you um EIP 70002 um I can give a a quick on this

one um this is execution layer triggerable exits uh essentially just for some context there are two keys there's the active key and the withdrawal credentials um the active key manages the stake the withdrawal credentials ultimately own the funds since phase zero there's arguably kind of a bug in this relationship and that only the active credentials can trigger exits um and so if the active key is lost or if there's some sort of more Dynamic relationship between who owns the active key and who owns the withdrawal credentials um you can have pretty degenerate cases and degenerate outcomes um additionally uh with execution layer

withdrawal credentials zx01 introduced a couple Forks ago um or a for ago uh the stake the ownership of the stake can be controlled by a smart contract which is really exciting for trustless pools and all sorts of other uh more Dynamic relationships in staking uh but these cannot trigger exits and so again you have this pretty degenerate relationship in existing kind of across the board in this exy design landscape um that makes the barrier to entry in these kind of trustless pools designs much higher because you then need some sort of committee construction to be able to like hold pre-signed exits and use them

and things like that whereas if you're a big entrench player uh that might be a sufficient solution at least for the time being whereas if you're a new ENT that's like a one of those semi major things you have to accomplish um so anyway 70002 adds a what is right now written as as a stateful precompile although um after after uh the way we've done the beacon route in denb uh dun it is uh going to be changed to just deployed uh evm Vite code uh which like client does have some assembly written for this uh that is under review and

will make its way into zip that's just a note uh this is cross layer uh this is relatively straightforward on the consensus layer in that it um you know is it a new operation type but that triggers very well-known kind of exit code paths um It's relatively straightforward as well on the execution layer um a lot of the complexity being able to be masked in that evm code um and at uh kind of on a per block basis um doing some stuff in relation to the state that is in that evm code and hoisting um some messages

into the the block as a new validity condition um yeah so nothing nothing crazy here cross it being cross layers really probably the biggest complexity component um and I will say that in relation to things that might happen with Max EB now or even in the future um some of the Logic on the message being passed around might be future proofed for potential partial withdrawals um not that that really without changes to the validat doesn't really make sense today but um that's a a pending potential change in

there yeah I I I think this is very important in relation to um just like fixing the ownership story of staking um and very importantly I think in enabling much more trustless designs in onchain pools any questions um anybody want to Signal support or uh against I guess as uh Tim mentioned this is generally conditionally included on the

execution layer side um and so in terms of cross layer support we have left okay seeing General positive support I think we saw General positive support in um the blog post that teams released uh and even notes of top priority from Prism is anyone against the inclusion of this in Electra great um we will as of now includeed in Electra um please keep your

eyes on uh this assembly that like client's working on uh that's the kind of thing that is very nice that we get to kind of capture a lot of complexity in one place rather than having to implement it across many client teams uh but it's something we definitely definitely need to get right so um evm Wizards want to do some review in the the coming month or two please anything else in this great moving on to EIP 7251 Mike

Mike Neuder: hey Danny hey everyone um yeah so

we'll do a quick run through on 7251 and 7547 um starting with 7251 I think most people in the call are are probably familiar um but to give a quick high level overview this this proposal is to increase the max effective balance um currently this is set at 32 eth and represents both the the minimum balance to become a validator and the maximum balance of a validator so anything above that balance gets um gets swept off so this proposal has has a number of features that that kind of make sense of it because it it seems simple but there's kind of a decent amount that goes into it the current list of features U I'll link in the chat um just to run through them quickly first is

increasing the max effective balance to to 2048 second is custom ceilings which lets validator specify at what level they want the sweep to kick in um the third is uh consolidation mechanism by which validators can consolidate multiple validators into a single validator fourth would be execution uh execution layer triggered partial withdrawals so this is um kind of Piggy backy on 70002 which is what Danny was talking about and the last one is the initial slashing penalty U making that zero so I guess the the high level reason for doing the CIP is to allow um some consolidation of the the total number of validators we have we're currently at around like 9 100,000 um but many of those are representing like

single entities because many entities have much more much much more than 30 to St so for example runs around 140,000 validators right now and each of those um each of those validators has to find an ad station that has to be um aggregated and then the signature verified for for each Epoch so yeah just trying to cut down on the both the network graffic and also improve some of the ux around solow staking um so I have a a short like super high level list of pros and cons um that I'll link here in terms of complexity the the reason this EIP I think is is a little more controversial or has kind of been a little more uncertain is because there's kind of a

lot that goes into making it um effective one of the most important parts here is this um in protocol consolidation and we just wrote a doc on this recently I'll link that um and the the high level takeaway here is that without an in protocol consolidation mechanism the only way big staking be able to to merge validators would be to fully exit that stake and redeploy it as larger validators um which would be a big hit in terms of of their rewards so that's that's kind of the incentive for the in protocol consolidation mechanism um yeah I think in general there's there's lots being um that there's lots that has been written on this I'll link the kind of General related work doc um in terms of reducing

the complexity to to get the um the scope down I think yeah if if there's appetite for that would be happy to discuss um generally have been kind of working under the assumption that in order for it to be worth doing it makes sense to like kind of do it right just because um like if if we did it and it didn't gain any adoption then it wouldn't be as valuable um but this has led to like yeah some some extra features I guess so yeah happy to keep discussing um I think that's that's the the high level summary I wanted to give there

Danny Ryan: yeah any questions for Mike there is certainly some support in

the chat but also some kind of questions and push back Sean

Sean Anderson: hey uh so I generally support this um I think it's really important to increase like the networking load for consensus messages because then we can increase the networking load for things like increasing blob count um but with regards to like the question on like how big of a scope do we want in order to like how how like attractive of a feature or how can we get people to actually use this feature um could we also potentially do this in stages where we do

like the minimum secure amount to increase Max CB while also keeping like uh the other consensus properties like secure unchanged and then and later Forks potentially add things like uh in protocol consolidation or other other like of the extended features um to sort of like not have this feature be too complex if we have too many other changes in this fork and also enable some of the nicer features like the compounding to happen for new deposits potentially allow people to like

deposit aggregated validators as new deposits

Mike Neuder: yeah so to respond to your first question um I don't think any of the features that we've described change the security properties at all actually like that's a big like in ter especially in terms of the cons consolidation like that's the main design constraint it's like we don't want to change either the weak subjectivity or the like amount of churn um that the that the protocol can like handle so yeah but I definitely do agree that like maybe it does make sense to consider kind of like a Mini max effective balance change um it's funny because Mini Max is like an algorithm but um so yeah happy to happy to kind of like brainstorm on on what exactly that

minimum feature set would be I think it would probably not include ude the protocol consolidation and it probably would not include um well I don't know we we'd have to decide about execution layer partial withdrawals but um yeah thanks for thanks for bringing that up Sean definitely happy to maybe chat more offline and come back next week or in a couple weeks with a with a counter proposal Sean do you mean

Danny Ryan: just Pro protocol security or do you mean just kind of security in relation to complexity of rolling out a fork

um soorry what what was the question

Danny Ryan: you you mentioned security did you mean security is in like how to make sure this protocol is secure or Security in relation to just managing a complex fork

and reducing complexity

so

Sean Anderson: so my understanding was there were some changes related to like um how we have to I think wait exit churn for example um and changes to slashing to keep the security properties the same and I sort of meant like there is work involved in the consensus changes related to that so a minimum change would have to include those along with raising Max EB and I'm not sure exactly what else but something like that um and just to be clear my right now my St gen I think is to like do a fully fleshed out version of this if possible but if the there's too much

in the fork then maybe there there's still a way to do a minimum version of this

gender yeah lar

Gajinder Singh: is of the view that we would not want to divide it across two FKS and if we want to implement it we should basically just do it uh in the single Fork because uh the context division is more complex and I think you know if we can sort of finalize the spec in terms of how we are going to maintain the security basically right now uh as per spec it says that okay you know the validator exits uh exit turn will be

respected uh but then there is a certain period in which the operators will not earn Revenue so if we have done the temperature check with the operators that they are okay with that and then the consolidation can actually happen so that we can see the benefit on the beacon State uh then I would say that we should do it in the single

Mike Neuder: just to clarify one point on the um on the revenue thing so yeah in the consolidation doc we talk about this um the only time that the consolidating validators won't earn the um the revenue for what we're calling the source validator which is the one that's merging into the target is during the time between the um exit Epoch for the

source validator and the withdrawable epoch for the source validator so it's it's not based on the exit Q it's just that 256 Epoch DeLay So in that regard like yes they'll lose a little bit of Revenue um but it's it's kind of always bounded and always constant which is good um but yeah thanks again for bringing all that up very good context

Gajinder Singh: yeah uh so another thing with that regard is that have are the operators have with with whom we have done the temperature check with are they okay with this little loss of Rue on there because the cons if the consolidation doesn't happen then we don't see any benefit so

Mike Neuder: yeah we've been um working super closely with with the

the large operators and generally have have kind of tailored the feature set based on not only like what we think will be good for solo stakers but also what what they would actually make use of so um I guess both both L and coinbase have have been really involved in this process and um talked talked to figment last week and they're also kind of keen to continue learning more as we as we finalize the design but yeah I guess all the temperature che check so far especially once we kind of settled on the initial slashing penalty reduction which was most of their concern um all the temperature checks have been quite good

parents

Terence Tsao: yeah so um I've you um as you guys have seen from the blog post prison

S no no support and um we all agree that we need we need this EIP as point right but the fundamental reason is that like I haven't heard much voice is that do we want like a smaller fork in 2024 or do we want to wait until 2025 to do a bigger fork and I and we do think that a small Fork is very beneficial so therefore we just think this EIP has too much complexity to fit in a small Fork assuming it's coming in October and November

Mike Neuder: thank you ter yeah and circling back to to Sean's point maybe yeah maybe if there's appetite for that small Fork thing then thinking through what um a mini version of the EIP could look like

might might be extra useful in that in that regard so happy to talk to you offline about that too

Terence

Potuz: yeah just with regard to this spr I just wanted to mention that uh there is no mini version in terms of complexity for us just changing the max effective balance uh is not just changing a constant this uh and the fact that we can Fork into something that changes the max effective balance even if we didn't do anything else uh even if we didn't change the validator structure to have this slashing being a a bit bit mask would be very large complexity at

least on prism's code base it would be very very hard to test uh we we do support the CIP C certainly we do support we we actually want it uh we we we prioritize cpvs and with think this is necessary for that but uh I don't see how this can be scoped in any form for 2024

Danny Ryan: does there exist um a prototype in any client

Potuz: I'm working on one for present because I'm working on epbs that includes this and uh this this is the

last change that I'll add because uh this touches everything so I I I don't have a pro but I but I started thinking in how I would implement it in prison and I just my head blows up immediately

Danny Ryan: gotcha uh does anybody else want to Echo the discussion of complexity or or push back or provide any more color here

Gajinder Singh: I think the consideration of this might also be taken in uh in context with the other feature heavy EIP which is p so

depending upon either P or Max evb we would want the inclusion of at least one of these things

Danny Ryan: got it so there is there's a bunch of discussion Just Happening um in the chat around small vers Big Fork um and what that means and what the intended timelines are um and how that couples with the execution layer intentions I do believe that the execution layer quote is anling towards small Fork um with a 2024 Target uh knowing that timelines are to predict until you get into the

meat um this also given the features that they we're discussing looks almost certainly like a cross Slayer Fork um and so the intention unless we kind of open up a router conversation probably be try to uh couple couple complexity in a way that like we're kind of hitting a similar uh intention in terms of when to ship unless something in here emerges as like you know worth the complexity and worth the time in the discussion um so I that's just to kind of contextually frame this but that doesn't mean that we can't debate that

poas

Potuz: yeah so we didn't start the the this meeting uh trying to get an agreement on how to scope this Fork I I I don't really care about what when it actually happens but what is the scope that we're going to have and what's what the dates that we have in mind so I am under the assumption that in the previous meeting there was some sort of loose agreement that we should scope it for the end of this year if this changes and this is not a reality then prison would have a completely different fork in mind uh if we if we had an agreement that we want to Fork we want to scope the fork for 2025 then we would be pushing for not only Max CB but also inclusion list and epbs in it we would

want to have a larger Fork but we're we're very very conservative because we know that we haven't fored ever twice in a in a year not in the CL and uh I I think it's uh it's not up it's it's not realistic to try to put this manys if we're scoping for this year

Danny Ryan: got it and I just we can re we can we can uh challenge that notion of scoping for the year uh but but I think that is the intention as of now unless it becomes challenged and we and we open up the conversation again so I do think that's the correct framing as we move through this okay so

there's no one is against a max evb type feature um to make it onto Main net at some point um people generally agree on the the the value um here and the necessity here there is disagreement as to the relative complexity especially contextualized in how this next forp is Being Framed um and I would also say that it's also a matter of balancing the complexity with the

um expected outcome because there's been also some debates about how this feature will be used at the End by big big no operators so we got a very high complexity and not certain outcome on the benefits that has been designed here so this also the there is also an unknown behind the scene right and and as as Mike said there's been a lot of attempt to kind of proactively mitigate that and ensure that Uh something's being built that will be used um obviously when push comes to shove uh how people choose to

run their businesses is not up to this group um and the timeline in which this kind of thing might be adopted is not up to this group so there is there is uncertainty although it's been attempted to be mitigated um would anyone like to continue the conversation on this or would we is the preference to look at the next handful of eips um to wrap our heads a bit more around the fork the complexity the intention of the rest um and to come back to this in further discussion

okay that's what we're going to do next up EIP 7547 inclusion lists is this also you Mike

Mike Neuder: yeah

Danny Ryan: cool

Mike Neuder: um this maybe a a shorter kind of list of things but um yeah I guess starting with the kind of motivation here Tony made this awesome dashboard called censorship. piix um it shows the relative censorship for for different operators in the um in the block production pipeline I guess the one that has changed recently that is um kind of very relevant is the amount of builders that are censoring So currently 67% of Builder blocks are censored and about 95% of ethereum

blocks 90 to 95% of ethereum blocks are met boost blocks generally so um yeah I guess a large chunk of of ethereum blocks are censored um so motivating the need for inclusion lists I think is um just getting getting some kind of version of a forced transaction inclusion mechanism on chain to increase the censorship resistance and kind of make it more robust to to these types of weak censorship um attacks so yeah I guess in terms of complexity I think this this EIP is much less complex than 7251 there is one kind of major design decision that I want to bring up which is this kind of um unconditional versus

conditional enforcement of the inclusion list um this is a doc that is in draft we're kind of just working out the details right now there's been a lot of conversations over the past few days but um yeah so kind of making sure we have have the design of exactly what it what it means to enforce the inclusion list is is super important but I guess generally the design um looks something like this no free lunch version um and yeah I guess this inclusion list stuff has been discussed for a long time like vitalic and um and Franchesco have been talking about it since I guess 2021 2022 so kind of just taking a lot of This research and trying to to get it closer to um to fully ready to go on chain I

think is is the general push um shawe has been um shawe teren and Poes have all kind of poked around at different parts of the inclusion list spec um I'll just send a link to the current poll request that that was open six hours ago um yeah I guess in terms of complexity on the theide there's there's not as much um because most of the validation happens when you check the enforcement of the inclusion list as a as a precond precondition of block validity and also there's some amount of of work that needs to be done on the PPA to make sure that like when a block is gossiped there's a corresponding inclusion list gossip with it before you consider the

block um for the head candidate so yeah there's there's a little less written on this but I'm also compiling a related work document in this gist here so happy to um happy to share that and definitely you know this I guess this is a relatively um newer EIP but I think the ideas are very well established and um important for kind of one of the core properties of ethereum which is that censorship resistance so would be super excited to kind of keep keep jamming on this and keep prioritizing this in in the near term if that's what there's appetite for

ter ter

Terence Tsao: yeah I can give a quick like

brief background on this so this was essentially derived as part of the epbs project with the EPF sorry epbs project with the EPF last year and as as as you guys have heard that PO and I have been working on epbs spec for the last few months and the this inclusion list um is basically part of it so essentially I mean we think this is too small to be included in 2024 right and then if and then if and then if it comes down to 2025 I think from our end we will push heav for epbs because this is part of epbs already and which um which um we will have more to share in the next

coming month

Mike Neuder: yeah just just wanted to point out one tiny thing is that um you you don't need epbs to do inclusion list just to make sure everyone's on the same page at some point I think we we did think that was the case but now we do feel confident that the design would work with or without epbs um but yeah I I do think the the relationship there and the work you guys did with the EPF was super valuable so thanks for that

Danny Ryan: other questions or comments I I have much less of a read on um how client

teams are thinking about this right now so some some verbal discussion around um support or or questions if you don't have a good understanding this would be great

Sean

Sean Anderson: um so yeah this it seems cool I'd want to do something like this I would support something like this um this one does strike me as pretty complicated though from when I was going through the E it seems like uh there are changes to sync for example and gossip and um this would probably require changes in the engine API and the beacon API so it's it's like

similarly touching a lot of parts of the client um to to what it was like making the the neb changes um on the other hand though we now have some experience with passing around data like blob data um so maybe it won't be as complicated but but yeah generally Str me as like relatively heavy complexity but it is

yeah since uh I have this the sign very very fresh in my mind and uh I just want to confirm uh with Sean H still this is much smaller scope at least in pris code base than

maxb so it's much easier to implement for prism than Maxi B but uh it's true you require to have new side cars for the inclusion lists exactly like just the net blops you required to have new end points on the beon on on the on the engine API so that you get an inclusion list from the L and you get uh and you send the inclusion list to validate from to the L the there are already PR some of the EPF fellows on some of the EP fellows that work with us already uh worked out the code the the list validation and the list production on G so there's some some code already to be seen for elel on the elel side on the CL side uh the heaviest four changes are

around gossiping because you need to gossip these new objects and on for choice because you need to validate uh this blog this these side cars to to even say that this this blocks are valid to even put them in

projects

Sean Anderson: okay cool thank you

Danny Ryan: yeah anybody any other team want to kind of discuss how they're feeling in relation to CIP right now

yeah

Gajinder Singh: speaking forar uh We've we are basically uh not I mean we support the CIP but we don't strongly feel about it because we feel that not all options

have been exhausted there is should override Builder flag in the El and uh using that lot of censorship can be dealt with if uh this particular flag is actually implemented in the El code base and is shaped and it does not require any consensus hard folk so uh for Lota that path is a bit preferable because uh again if we want to the scope of the fork small then we would basically vote in favor of some feature EIP uh than basically this one

Danny Ryan: is the general understanding of the sh override Builder as kind of

um a Band-Aid that will help for a while or or is there an understanding that that might be like a a long-term viable solution

protest I

Potuz: I don't share load star reading of this uh this an inclusion list is something that the is suggesting the proposer to to force include it's it's kind of too strong to Guess that the transactions uh I mean we are seeing 90% of blocks already uh censored so if says particular contracts have transactions that are outstanding um then we're going to be not taking any

Builders block with this uh flag instead of like trying to choose builders that are non sensoring uh I think use overwriting this overblowing this this flag is just too much of a

Le Jinder

Gajinder Singh: but we haven't even seen this flag in action so we don't even know that how how useful this flag is

Potuz: definitely and we we need to see what are the heuristics that are going to be implemented on the Els hope hopefully

this is going to be implemented soon because there are some simple heris and hopefully it's going to be against like strong censorships uh but not something that would just disrupt the network by trying to overwrite every single block or like because we currently have statistically 90% of blocks produced by well many blocks produced by sensor Builders

Gajinder Singh: but if this flag is actually implemented then it would achieve the same purpose that inclusion list would do in the sense that

Potuz: no it can't because the proposer send it before you get the block from the Builder so this flag does not allow you to see the block from the Builder with this flag the the Builder

the El is going to signal there is already censorship censorship on the network you should not even ask for the Builder's Block in the next slot you should not even consider the Builder's block on the next load this is because the way we have me boost we you you don't get to choose after you see the block so this is very different than inclusion list where in inclusion list you're going to say to the Builder take give me a block that has these transactions and then you're going to filter out every sensoring Builder with this flag you filter out every Builder

Gajinder Singh: no I understand that inclusion list is a stronger way to prevent censorship uh but yeah I me also side Builder could be a first step that can be taken to see

whether we can have whether this flag can have effect and prevent censorship

Danny Ryan: right and poas I guess the gensor also gets to add their own heuristic in relation to that flag um you know so 100% return value of it doesn't necessarily mean 100% usage of it um I I know that's not necess Point here um does any are any consens teams making the case for inclusion of 7547 in Electra given the um the knowns the unknowns and the kind of General

intention of scoping of the for that was asking anyone making the case any positive anybody wants to say yes this is this should be included this should be prioritized for for okay we're going to set the side for now uh again like the conversation will continue so it's not necessarily death sentence but this is not currently being prioritized or included

poas

Potuz: just a quick note uh again the same the same

note as before if this Fork happens to change the scope for next year this would be a very top priority for prison we believe this is strongly needed and we can do it in the next few months we can have a proof of concept at least of

Danny Ryan: thank you okay EIP 7549 move committee index outside

fation D plan

dapplion: hey so DCP clears technical depth from the previous road map where we were going to execution charts there is no reason now

to sign over this B of data signing over it it means that we cannot aggregate equal votes in terms of FFG lmd ghost this has very significant implications not to our own clients but to any other application that tries to prove finality outside of the clients for example breaches that want to develop a zero knowledge Pro they would immensely benefit it from verifying much less pings with this optimization it can significantly accelerate the delivery of thrust

solutions for yeah basically um bridging from consens networks to other networks so it's not as important to ourselves to improve the efficiency as our clients but to other consumers that want to prove consensus in in some restrain um execution environment

Danny Ryan: is there a marginal difference we can block verification at layer one or is I mean

dapplion: yeah we would we would benefit but we I think clients are already kind of optimed that would be not like like a significant difference maybe CPU would go from 25% to 20% but it's not a game

changer it it it is a game changer for these scenarios that I'm talking about like um ZK bees and these sorts of applications

Danny Ryan: and from a complexity standpoint this is a very minimal of the way you you specified it um kind of leveraging a helper in Phase zero the s that being a very minimal change um really changing just a couple of data structures um in ensuring that we we kind of get the tests Ripple through the tests that way

dapplion: yeah so there are different ways that we can deprecate the existing committee index uh the most basic one where we just keep everything

as is and just set it to zero it should be a really really trivial change um we can go more crazy about it and scope the hell out of this but if if we keep it tiny it should be really really painless

D

Dankrad Feist: yeah I mean I think like because the current draft mentions all three options I think like for a small fog only setting it to zero is realistic I think like um realistically given all the all the infrastructure that has been built around signing things like um like protection and um distribute validators and so on um I think it's a major change

to change the format of attestations but if we set it to zero then it can be a very small one

Danny Ryan: yeah I Echo that all right um I believe we've seen like very positive sentiment from all client teams um and no descent does anybody uh want to bring up any reason not to include this in Electra and it probably goes without saying this

is not cross layer okay um as of now we will include 7549 oh that's that's funny the next EIP 7594 uh is pus I can give a quick overview on that um um this so data availability sampling is in some form is the method to go from um 444 levels of scale where everyone's downloading all blobs to um Extended scale beyond that call it full dank shorting um by not having

enabling nodes to be able to ensure that data is available without down downloading all data uh this has been very high R&D task um for quite a while now um and almost all of the complexity although a very elegant mathematical construction uh ends up being in the networking layer and kind of the Practical instantiation of doing this in a distributed context um pure Das P day availability sampling uh is a an attempt to utilize known very well tried andrue known um networking components um and to to get a kind of basic data availability sampling

out the gate uh utilizing um discovering peers in a similar way that you discover peers for at nets um utilizing gossip and subnets and utilizing uh A diversity of peers for sampling it also does attempt to uh leverage a notion of data availability sampling providers um by allowing peers to custody more than the honesty requirement and let that known PE such that if there are um funded or altruistic nodes whatever that that want to serve the network um that can kind of naturally slot into this um this is

something that has a specification this is something that uh multiple people are working on prototypes of uh but it's also uh something that you know compared to 7549 has quite a bit of complexity and quite a bit of things uh to work through that's not to say that it isn't everything that it utilizes is very well known uh but putting the pieces together um certainly on these networking things can be a challenge cool

Terren

Terence Tsao: I mostly have questions so my first question is are we increasing the

Target and meds come if yes then like I feel like maybe we probably should wait until how IP 444 is to see if there's sufficient demand and if today we're not increasing the Target and that's time is this like a um backwards compatible changes in a way that if we just apply like a data sampling Network on top of the current 4 a con do we even need like a hard hard for I um I understand we probably need like a eot such that the P can pay attention to the subet but besides that is are there like consensus changes

Danny Ryan: as it is specified right now there are no consensus changes yes

you're right in that if you're going to leverage these new gossip topics and things you would want to premise it upon an Epoch that is not to say that um pios should not be coupled with with a data gas limit um increase I I just personally think that that would likely look like a separate very self-contained EIP that just looks like it essentially a gas limit increase EIP um which I guess in the event that people want to move forward with 7594 I would argue that it's the an open question as to whether um and to what value you would you would do that at an initial Fork

um D you are

Dankrad Feist: yeah so in terms of yes um

what Teran said about the demand I think what is important uh to realize is that um yeah I mean I don't think there will be a question about demand for 4844 like right now like we see rollups are already using about but this has grown by effect of 10 over the last year theow said

the data amount grown

Dankrad Feist: right so the the amount right now is on the order of one blob per block um and but this has this has grown by a factor of 10 over the last year I'm going to share the graph in the chat but it's um yeah it's I think it's very important to realize that this will

very quickly become an urgent thing I think because we R we will run quickly into the regime where rollups will also question why are we using 444 at all if it's not cheaper than um than call data um so yeah like I mean I think like the demand is like the smallest worry I have about this I think like that will be very obvious very quickly after

444

Danny Ryan: other comments questions um how people

are feeling about this that

plan

Tim Beiko: yeah I think

dapplion: every every other I has made it but scaling Remains the best investment in terms of time and output there is a very clear return on investment investing in this field so it's seems very unwise to not have this as the top priority basically constant and we deliver fold and Charing provided that we do all the other good things on the back as it allows

po

Pawan Dhananjay: yeah I was curious about the crypto side of things for this mainly like the

efficiency of verification of large amount of uh the greater amount of blobs here like so what is the state of the cryptography libraries basically for

PS

Danny Ryan: is Justin taglia or George here or maybe donr if you have context

Dankrad Feist: um yeah I will I don't have the numbers in my head I like so what you're asking about would not be the N the blobs because we wouldn't be verifying full blobs anymore instead we would be verifying samples and um I do not have the numbers in my head I am pretty confident that it's not going

to be a problem but I will quickly look I think Justin compiled something and never find those numbers

Danny Ryan: and Justin has no mic but um can maybe provide a resource or uh some quick data for us um if possible and there's also the question of not only efficiency but like just the state of these libraries um and I know that there's being work done but I I can't make a claim as to what that works looks like in relation to production

Dankrad Feist: yeah I mean I think like the complexity is not like enormous so I'm fairly confident that like we will be able to finish all the work on the libraries

well in time like we already have a c implementation and I think we have every like everything we need to do that very quickly

Danny Ryan: is this more what you call it ative or fundamental um in relation to what exists

for before

Dankrad Feist: I mean there are some fundamentally new things um yeah I think like yeah

but Mo most of the

Dankrad Feist: yeah it's it's very it's mostly very similar to what exists already the one big piece that changes will be the the computations of the samples which like which you don't have to do unless you produce

blocks um so that will be on a slightly different um yeah that that will have much higher complexity than like the other things we've done but like the verification all stays very simple and the additions are quite small I would say

photos

Potuz: yeah I'm going to sound like a broken record but uh yeah I'm not worried about the cryptography nor nor all of these changes that that are on software that is there are isolated changes I mean they can be worked in parallel from everything else and they can be self- tested they can be unit tested and they can be self- audited uh we' we've learned something from theb is

that uh testing networking changes uh gossiping new object CH testing changes to gossip is complicated and it takes time and we were under the assumption that we did we were going to prioritize this is what what led all of our decisions that we were going to prioritize verle on 2025 by scoping this in 2024 I don't see how can we test this and vertical in parallel and ship something like this by this year that's the reason why we were not supporting this for this year for this small work if we scope it for this year

Danny Ryan: let me clarify something you just said um you say you don't see how you

can test this in vertical in parallel I in the event that this were not included in what is attempted to be scoped this year it seems like a very obvious thing to work on in parallel to veral because it is um very independent uh yeah

Potuz: definitely but but but then we'll have like a year I understand but then you will have the double the time to test this instead of just test this on vertical in parallel and ship this by this year so we're going to have to like have this ready and be tested in a period of like the next five months six months probably Max

SE

Sean Anderson: um so my perspective sort of that denb actually helped us get a lot better at testing these types of changes so I would I would be more confident that we could test p d more quickly like I feel like the tooling got better Dev Ops has been putting put in tons of work um yeah

Danny Ryan: yeah also say the premising uh Fork Fork Choice inclusion and Things based upon uh alternative Network messages is was probably like a major hurdle um in working on for full 4 whereas you know this is leveraging the

same logic obviously it's can be very different in many ways um but maybe that also reduces the complexity I I would hope and I do agree Sean um we have gotten better and even from here hope to get much better Perry

Pawan Dhananjay: um yeah I want to mention two things I think the first one is that like a lot of people have said uh we didn't have a lot of the testing tools we needed for effectively testing Network upgrades and I feel like now the got into a stage where we we actually can do that quite reliably and we've kind of been spending time testing work in parallel already and one thing we've learned is that most of the veral

changes would benefit greatly from Shadow Fox so we have a way to do Shadow Fox but in an automated manner such that you don't actually need to call someone from devops to do them you can just run them and like a CI test and I at least our working assumption is that if we can deliver that um over the next month two then most of the El teams can in a siloed manner test transition at least and they only need us at the point when we're talking about doing the transition with the network complications which would most likely be later in the year at which point we've gotten farther ahead with pias so we're trying to like paralyze at least our time such that we're not blocking either

party

Danny Ryan: yeah I even if it were not included intended to be included for Electra I would still make the case for spending quite a bit of Cycles on it um in parallel assuming that Electra was kind of a bread and butter fork with respect to you know very well and understood consensus changes I think that hopefully would uh keep some resources available to to work pretty hard on this in parallel um and if that

is the case you could make an argument for sensitive inclusion and Electra as like a kind of the uh parallel R&D track uh but that to not hold up what would otherwise be a bread and butter fork in the event that we hit unknowns um maybe that's a reasonable compromise um I don't know if we need to or we'll have the time to make uh fully make this call today oh we have we have 20 minutes left we have the ssz ification uh set of of

eips um we also will save six minutes at the end um for quick research update do we want to table this and think about where it may sit and if there are R&D compromises here or do we want to continue this conversation right now does anyone else have anything to add additionally to this conversation right now okay I I think that likely in plus two weeks um we'll kind of pick up the

conversation around some of these more complex things and where uh we sit in relation to them in relation to Electra or potential future ports um this being one of them Maxi be being the other obvious one okay

tonification

Etan Kissling: hey hey so it's a couple different eips but they all have a shared motivation namely that right now every application that um Builds on top of ethereum they use this Json RPC API and normally they have to use a trusted server for that because there are many responses in that API uh

where where there is no efficient way to verify that the response is correct um for State um balances nft ownerships we have EET proof and verl will make those proofs more compact um so there it's solved but there are three other trees namely transactions withdrawals and receipts where additional changes are necessary to make it viable to use those um to to create proofs that we can put into those Jason RPC responses um why is it important that there are proofs there right now um the

big uh providers of Jason RPC such as in fura they have privacy policies where they log your user data they tie together um your IP with all the wallets that you are accessing so there is like a privacy concern there and there is also a security concern because you're trusting a server for providing the correct response um so with those proofs it becomes possible to verify that the response is correct they can still censor you but you can just ask a decentralized network of servers like they cannot uh send incorrect data anymore um so one key um for

transactions that is necessary to introduce is a commitment to the transaction ID right now transactions have an ID but it doesn't exist anywhere in the mer Patricia tree so in in the blockchain the transaction ID doesn't exist so any request by transaction ID such as obtaining its receipt or its transaction data it takes an ID and you cannot even verify that that transaction actually exists on chain um you have to download all the transaction and all the receipts to verify that a transaction actually is part of a block right now it could be optimized a little

more with a Merkle Patricia Tri proof but it's not efficient um that's also one thing that Proto Lambda brought up just a couple like maybe an hour ago in EIP um for receipts that it's important for Bridges uh because a receipt can be multiple Mega bytes so it can even be that like a fraud proof doesn't even fit into a transaction so having a standardized way on how to meriz um a receipt in a transaction would would help with layer tws as well so um what is being added is this transaction root

concept so so we can have Merle proof that a particular transaction route is included on chain um that would also help simplify the inclusion list because it is no longer necessary to include the full transaction in every block multiple times so we can just include the transaction route there um and it also includes the from address of who is signing the transaction right now that is also not on chain data um you actually need the full transaction right now and then hash it to obtain the signer from the signature and the transaction hash which is quite an

expensive operation for embedded devices and it is also opening up for example EIP 8102 uh which proposes BLS signature scheme but without a from address commitment it becomes impossible to efficiently um deploy such an EIP so it fixes that it adds the from address and the transaction Dr um for receipts we are adding the contract address if someone is deploying a new contract right now that is also not part of onchain data so um adding that there is important and also um there is a slight change to the gas used right now in the

receipt there is a field called cumulative gas used so if you want to know how much gas was used by a particular um transaction to compute the correct gas usage um you need to download multiple receipts and then compute the difference to see how much an individual transaction actually used um so changing this to actual guess used by just a single transaction um simplifies that that well so um you can download a single receipt you know how much that transaction used um by not including cumulative gas used anymore it also opens up future

parallelization in execution because you can now um process multiple transactions at the same time as long as they do not touch the same storage slots and accounts um this cumulative gas use is final part that right now prevents that I think um yeah so those are the three different roots there is also this signature scheme proposal um the three other eips they could um be implemented by simply converting all the existing transactions and receipts from new blocks onward so this this only applies to new blocks

anyway and we could while building the block um convert the transactions from rlp to SSC to gain those advantages in 6493 there is also a scheme to create transactions directly like this so metamask could directly sign an SSC transaction um to to avoid the conversion step and SSC is also about 30% smaller than rlp when stored on disk because it uses a compressed um format it's called Snappy it's the same one as as is used on consensus because there are a lot of zero bytes in receipts

especially it saves a lot of data as well um pushing out the 44s a little bit more um like giving it more time it's still an important dip and yeah the final EIP is 7495 it essentially defines how we want to represent transactions receipts withdrawals um it is a format that that is forward compatible um to avoid a situation like we have right now in consensus layer the problem there is for example rocket pool they query the beacon State um to see whether a

validator is slashed and right now every time that the number of fields um reaches a new power of two in the beacon state or in the execution payload um the proof format changes so they have to um update all of their um proof verification logic to consume the new um formats um with 7495 this is no longer necessary because any proof um will continue to work even if future um additions or removals uh re like yeah um change the actual data so if you just care about

slashing as long as slashings are a concept you can write a verifier right now I mean after 7495 is deployed and it will continue to work until slashings are no longer a thing conceptually regardless of other changes um yeah but it's it's different like we can choose to use a different approach of course if if we say that it's fine for clients to have to update the code continuously um yes um what is

does

Danny Ryan: shifting to a stable container change merization it changes once

Etan Kissling: yeah so any container that is touched changes it

once um I have proposed to just do it for where it's necessary for transactions and receipts but it could also be done for other structures of course um one thing to keep in mind is that 7495 also introduces a way to represent optional values so right now in the veral consensus specs there is an optional value I'm not sure if the final design will still include it but if we are going with a veral design that uses optionals we should decide how we want to represent optional so at least the 7495 must be decided before veral and

the transactions encoding needs to be decided before inclusion lists those are the two dependencies yeah I have also created the demo where you can explore how a transaction looks um after uh after this EIP um for example here I just pick the random one and put it in the chat the first link is the transaction s the second link is the receipt SSC and if you want to look it um into rlp you just delete the ssse part from the

link if someone wants to explore it's it's it works

in the web anyway for

Danny Ryan: almost all of this the the high complexity component ends up being on the execution layer whereas uh it's more of kind of Bookkeeping on the consensus layer except potentially uh use using stable container you know if you stable container the whole Beacon state or something that might be reasonbly higher complexity change

Etan Kissling: yes and of course the transaction representation in CL and El it would be aligned to be the same so right now the CL and El use a different transaction

container

Danny Ryan: and do we before we move on to questions um was this brought up on the execution a call and is there any um signaling over there that we should know about before we begin this discussion

Etan Kissling: I didn't bring it up um for a while now I just joined this one because I saw Electra being discussed um but thec proposals are there for a while now

Danny Ryan: gotcha um we are going to shift gears in about a minute Gom let's do the question and then um the ssz vacation we can continue in

sub well Gom

Guillaume Ballet: yeah uh not really a question just um a remark so yeah the veral spec could change that's

not a problem especially if we don't uh guarantee that proofs will be available right at the first veral Fork they might be activated later so yeah there's no there's no dependency there just what I wanted to specify

Danny Ryan: got it um given that a lot of the complexity of this does lie on the execution layer I do think that we should HT a bit to um getting some more signal from them um and we can uh depending on how that goes uh we can put this on on the agenda for the next time on theayer call and also even if that doesn't go well and people have questions and further comments from the

consens side we can also discuss in plus two weeks um I do want to okay so in two weeks uh we are going to bring up discussion of uh Max evv imp P us again um in terms of complexity in terms of priorities in terms of uh fork or not in terms of even if not Fork how to think about them as as R&D items to help accomplish our goals over time um in plus two weeks uh and for the last five minutes uh we do have some time for kind of an R&D update SL discussion or at least the beginnings of such

um ancar and Anders yeah hey everyone I think there's

a Frisco and also pleas exive be in the background um but

Ansgar Dietrichs: yeah so basically um I just wanted to briefly flag a topic that could potentially contribute like one more candidate Electro EIP um and that's kind of the stake staking reward um mechanism so so basically the way think about it is that um the the original kind of saking w curve was was chosen to kind of pratically to to kind of get the beacon chain off the ground and then we haven't really looked at it in in much detail since and then of course by now we have a lot of experience looking at the real world kind of usage of the for the beacon chain and for staking and a lot of interesting mechanisms like lsts and and and now of course reaking um and

popping up which which are great to see but of course um kind of were hard to predict so um over the last few months kind of on the research side we've started to to to look a bit more um into into that mechanism again course the idea is to to kind of make sure we we have um we we have a situation in place where etherum is just long-term stable and needs no further changes um I don't think it's certain necessarily to us that that we do need changes from from from currently but but basically um um the IDE is to to project forward um what if what if we basically don't touch this this this taking mechanism where will we be in in 12 months 18 months 24 months right like three three four five years from now um so basically what path are we on um what

properties does it have and do we like that what alternatives uh could there be this this this kind of exploration um we basically um in terms of commun communication there of our thoughts we'll we'll have have some kind of Articles and and writeups out on on that um over the next couple weeks um and then um a decision that we might want to make is around um are we comfortable with the path we are on if we at least kind of not sure we're comfortable with that there could be a small EIP we might want to to to get into Electro to basically just P down the the rewards a little bit to basically slow down any potential kind of future um staking ratio kind of creep up and that that that could happen

that would also by the way alleviate a little bit of the of the the Conant pressure on total total validator um um count um but again this is all kind of I mean now now we at the end of the call so this is not the idea is not to to to have a good discussion now it's just to to flight the topic and say that kind of by by the next call we'll have some some kind of material out and then we can kind of start to have that conversation um yeah and that's all for now I think unless was is basically the first one that already has has a write up out that you published yesterday so un do you maybe very briefly want to to say what um what you have looked at

yeah so I'll just say that um yeah I

post yesterday evening on on E research and I just write a link here and so basically what I'm looking at is sort of what can be done to the isan's level and what happens to various important features such as consensus incentives and reward variability for S States if we are to change the level and so the conclusion is essentially that if we wish to temper isance we would like to do it a with a rather moderate approach so because if you do it too aggressively we we would sort of unbalance the different economic Force as we have you know me and issuance and this could then render the micro incentives of the

consensus mechanism a little bit you know ineffective because if we push down if we push down reward so much that the stakers only receive met then there's a lot of sort of bad things that happens under the equilibrium and so then I just review sort of what can be done and what cannot be done in terms of different reward curves that that could be explored and I showed some viik does quite a nice summary also of this in a comment on that post so you could read that if you want some sort of quick overview

and that's it

Danny Ryan: great um so do check out the post I

think the intention is to um there's some subsequent uh post and research to come out and the conversation will be furthered at plus two weeks or plus two four weeks time um but this is just kind of setting the stage that there is um intended to be a conversation around some of these forces um yeah any single one question we have time for yeah okay uh take a look at the post um hopefully be some other stuff between now and a couple weeks from now um and towards the latter component of the next call we can dig a bit deeper into some

of the research Concepts and potential things to do uh thank you that was a really productive call uh we got through a lot more than I expected um talk to you all on the execution layer call in a week and then we'll pick up this conversation in two weeks

thanks guys hi see you you thanks everyone thanks bye thanks

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