Mike Neuder - Increase the MAX_EFFECTIVE_BALANCE

Transcript

well welcome very much uh we've got a full agenda today with lots of speakers and I'm very very uh proud and pleased to um introduce our first Speaker our first speaker is going to be Mike Neer Mike is going to be speaking about increasing the maximum effective balance and Mike is a researcher with the ethereum foundation who specializes in staking and proposer Builder separation Mike hello hello okay um let's get this cool hey everyone just going to

start a timer here cool yeah hey everyone thanks for the introduction I'll be talking about EIP 7251 which is the proposal to increase the maximum effective balance so just a quick sketch of the talk I'll start by outlining the problem so we'll talk about what the max effective balance is we'll also talk about the partial withdrawal sweep and why that's an important piece of the puzzle and we'll also talk about kind of what the max effective balance being set at 32 eth does in terms of the consensus layer then we'll talk through some of the solution so starting with just increasing the max effective balance and then talking about some of the other

features that are important in order to support this and encourage adoption of the EIP we'll conclude by talking through some of the results and the impact of doing this and kind of the the long-term vision for how this fits into the ethereum road map cool let's get rolling right so what is the max effective balance this is a picture of the constant taken from the consensus specs basically this is the value that's set to 32 eth and it caps the upper bound on the effective balance of a validator so from the consensus layer perspective the most eth that a validator can ever have is 32 eth and it's it's kind of confusing because it's actually also the minimum effective

balance that it takes to become a a validator 2 so it's kind of this tight bound on what the consensus layer views as an active validator and then there's another kind of piece of the puzzle that we need to to go through which is called the partial withdraw sweep so again from the consensus layer everyone has 32 eth but as a Staker as a validator you're going to start accumulating rewards for participating in the consensus layer so as those rewards start accumulating um you need some way of of letting people withdraw those rewards without necessarily um like because because they're not going to be earning extra extra yield for that reward that needs to be withdrawn and the process by which this is done is called the partial withdraw sweep so this diagram tries to

show um what's going on here and we're moving kind of left to right as the sweep progresses we have three validators and this base shows that this is their max effective balance of 32 and they're kind of accumulating some sliver of rewards on top of that for for participating in the consensus layer and the sweep is happening right now for validator number two the withdrawals um or the the rewards that they earned over the past time period are being sent to their withdrawal credential and then during the next time period The Sweep will move Mo on to validator 3 and then it'll cycle back to validator 1 so yeah it it just removes any excess balance above the 32 eth and it sends these rewards to what's called a

withdraw credential if the validator doesn't have the withdraw credential set then the balance will just accumulate without being withdrawn anywhere and it takes about six days for the sweep to complete one round so basically um it just does a linear scan through all the validators starting at validator index one going through the end and then it once it reaches the end it just starts back over so this shows the the set of withdrawals for my validator it happens about every six and a half days I get a withdrawal of about 0.16 e so this is kind of just setting the stage for um what changes when we increase the max effective balance and how the the consensus uh sweep works now cool so we're still kind of in the

in the laying the groundwork phase of defining what this problem is and what results from having a 32 max effective balance is a difference between the pool node operators and the actual validators that they're running so as you can see here we have kind of two participants in this in this hypothetical scenario we have Alice and she's a a node a pool node operator and she's running um potentially many many validators on a single machine that she controls right so in this case she might have four different validators that she controls all from the same machine whereas Bob who's the solo Staker just has a single validator running from his home box um you know locally and what this results in is actually quite a lot of redundant work

so in some ways all of the validators that are controlled by Alice and that are running on her machine are belonging to like are kind of like logically one entity but from the view of the consensus layer there are four different entities that you have to verify signatures for aggregate those signatures for ETC and it it also results in a huge number of validators right so for these staking pools they have way more than than 32 eth and so um they have to spin up many many duplicates of these validators in order to um deploy all that eth into the consensus layer and earn rewards on all of it um and we can see that the actual number of active validators has gone pretty um pretty dramatically up since the withdrawals were activated in the

chappella uh Fork which was in April of this year so this is starting around May we've kind of gone from around I guess yeah six 00,000 all the way up to like 875,000 um it was going very rapidly up when the immediately post the withdraws and now it's starting to Plateau a little bit but still we have kind of a few order of magnitudes more a few order of magnitude more validators than there are actual nodes in the network um you know at at about 875,000 validators with only around 10,000 nodes on the network potentially um we have kind of a ton of a ton of redundant work being done here and this has impact on the performance of the

consensus clients so this is a photo from a document written by Perry and his team and I highlighted kind of a few of the important points this is called the Big Boy Beacon chain test one um so this is a test net that they spun up with 2.1 million validators just to see what would happen basically and this is kind of the current versions of the consensus and execution layer clients and the key metric here it's a little small but the key metric says that there was yeah about 38% of attestations were actually like landing on chain so clearly like the network is not able to handle this load you need 66% of attestations to finalize any blocks so the chain wasn't finalizing um the just things weren't

working at that scale um so two 2 million validators is is kind of like a 2X increase from what we have today but still it's within the scope of possibility especially if there's a a huge increase demand for stake over the um over the next years so um another instance of of the consensus clients kind of taking a hit is this um finality event that happened in May of this year essentially what happened is some of the U validators were unable to keep up with the head of the chain and a huge percentage of them went offline again we have a huge drop in the attestation performance which is like one of the key metrics in measuring how the overall network is doing um and it recovered but the tldr is that this giant bloated

validator set leads to a number of things that has has a very large Beacon state so you have to hold all these validator indices in memory you have to hold their validating Keys you have long signature aggregation periods so each validator needs to make one attestation per Epoch and that's kind of no matter how big the validator set gets every one of those um signatures has to be aggregated over the course of one Epoch so you only have 32 slots to kind of go through accumulate all those aggregations and then propagate the aggregate add a stations too so there's kind of huge amounts of of overhead there and also just in terms of P2P networking um if Alice has four validators running on her machine she has to broadcast four messages for um every Epoch because she has four out of stations rather than a single one that

would account for all the stake on her machine cool so that's kind of the problem statement and the solution is it kind of sounds simple in principle which is to just increase the max effective balance um and that's why we call it a modest proposal because it's um a bit of a misnomer because there's actually kind of a number of other things that we have to do along the way to both make it feasible and secure and also to increase ad option and make sure that um this EIP actually gets used so this is the the two-line EIP if if it were that simple that would be great but um one important note here is that we keep the the max effective balance but we make a new variable called the Min effective or Min activation balance so we we want to raise the maximum balance while keeping

the floor at 32 e so um we still want 32 eth to be you know accessible to to home stakers and OBS but making it the upper bound 2048 eth in this case um will hopefully allow the big staking operators to to consolidate and merge their validators into smaller sets cool so one of the core um I guess features of of this EIP is that we need validators to um merge without exiting the consensus layer so again we have Alice here she has three valid four validators that each have 32 eth and and we want her to be able to combine them into a single validator that has one 128 eth um once she does this she can throw

away the the signing keys for validators 2 through four and just do everything under the validator number one index um and the reason we need this index merging to take place is because if we have you know 870,000 validators and we want to consolidate them we need the adoption of the staking pools because they're the ones who are running like all the stake they have all these signing keys and in order for them to adopt it they need to be able to merge without exiting the consensus layer in order to avoid the process of withdrawing all four of those validators combining the stake into one new deposit and then going back through the activation queue so that like that life cycle there is um I guess prohibitively slow especially for pools that are

trying to compete on API apy um so in order to incentivize them to do it or to kind of lower the cost of doing it for them doing it in um without without having to exit is is very important feature like it's kind of a must have from their perspective um another thing is either choosing um enabling custom ceilings or execution l or partial withdrawals or both so it's kind of a lot of jargon there but basically the idea here is that if someone's running a validator with say like a thousand eth they need um they need a way to signal that they want some of that eth out without necessarily withdrawing the entire validator um you could think of this as they they might need to pay their tax

bill or they need to pay the cost of running a large node but essentially there needs to be a way of um simplifying the process of of withdrawing stake given that the The Sweep might not be effective for people who have a very large effective balance so there's kind of two ways to do this the first one is these custom ceilings so this diagram tries to kind of highlight what we have we have the same sweep progression as before so we're moving left to right um but the three validators now have different ceilings that they set so validator one set a 64 ceiling validator 2 set a 32 2 e ceiling and validator 3 set a 96 e ceiling so the sweep will still move like um left to right and then Circle back and and go back to validator 1 but the amount that is swept off will change

depending on how much stake each validator has so in particular validator number three who has a lot bigger balance we'll have three times the amount of rewards that get swept off in each um through each sweep but they still are able to kind of fine-tune where they want that ceiling to be and you know in in the ideal world all the staking pools would set the ceiling all the way up to 248 eth and that would be like a full consolidation a full 64 times consolidation of all their validators we expect that the adoption would probably be a little more gradual in terms of you know maybe they they combined four validators into 128 e validators and then two of those into 256 Etc kind of like building up trust in their in their setup and reducing the risk of any any larger slashing event um

but that's the goal is is to have validators have more control over where the sweep kicks in for them um alternatively we could have what's called execution layer partial withdraws um it's a bit of a mouthful but basically the idea here is that the withdrawal credential is the place that effectively like owns the eth from the view of the execution layer right like when you initiate an exit from the consensus layer the the eth goes to this withdrawal credential this is just an eoa it could be either a contract or um or sorry it could be an EA or a contract and um e EIP 702 which was written by Danny is this idea that we could have exits triggered by the withdrawal

contract and this idea of execution layer partial withdraws just kind of extends this to say not only can you exit from the execution layer address but you can also initiate a partial withdraw so um this would help both the staking pools and um solo stakers like kind of maintain control over the validators without um necessarily having to worry so much about um only one one key being able to withdraw eth from their validator cool um another part of the solution space is potentially changing the slashing penalty so the slashing penalties on ethereum are really complicated so I won't go into too much of the detail but the the important

thing that we're going to pay attention to is What's called the initial penalty okay um the initial penalty is basically applied to a validator balance immediately once they commit a slashing violation and right now we have power set to one so what this means is we have effective balance um which is usually 32 e for all the validators so the initial penalty is one eth for a slashing condition in today's version um but the problem with this is that it would scale linearly and that would be very punitive for anyone to consolidate so if a staking pool Consolidated 64 times then that one validator if they get slashed would be slash 64 eth um which is which is quite bad so we could instead potentially scale it sublinearly um and we don't even have to necessarily

do this this form of of um scaling but this is like one potential option you could imagine uh the text is a little small here but you could imagine like a constant slashing penalty that's applied for everyone or you could imagine it the penalty scaling is like the square root of the effective balance rather than linearly in the effective balance itself cool so what does this actually get us um it cleans up some of this historical Tech debt so I guess a little uh of the reason for why this validator balance was set to 30 or the max effective balance was set to 32 ethers in the first place is that the original sharding design required um an honest majority of each subcommittee within the consensus layer and so in order to ensure that the the subcommittees

weren't like biased in any direction you had to set this this ceiling in order to make sure um that there's good representation of the honest major the honest majority in each subcommittee but with the new um design with you know uh sharding not the execution but just charting the data um we have a situation where we only use that committee for adastation aggregation which is a oneof n honesty assumption rather than a majority honesty assumption it also improves the network stability this kind of circles back to the um the ideas from before and it also enables this Auto compounding feature and flexible balances for solo stakers so just a quick before and after um without this autoc compounding feature

the the solo Staker will only ever have 32 eth until they accumulate enough eth to deploy another 32 eth validator right this is like many many years potentially in order to get that versus post um post increase to the max effective balance they immediately start earning extra rewards for all the rewards that they earned in the first place so you have this kind of compounding effect the staking pools already get this because they're big enough to to deploy new validators constantly but solo stakers don't have access to this and flexible balances just means like if you have 40 eth and you want to have a 40 E validator you don't have to deploy that 8 e somewhere else you can do it all through your Sol staking um it also opens up The Path path to single slot finality and potentially aims to decrete the decrease the Min activation balance

so this is if we get good adoption of this EIP we could potentially get into a world where you actually reduce the 32e minimum down to like 16 eth or 8 eth and make um solo staking and home staking more accessible so thank you very much this uh QR code sends you to this GitHub gist and it should have all the links you need to read more this so thank you very [Applause] much happy to take questions working oh perfect her comes um just because there's a number of

folks uh being live streamed here uh hello thank you very much for this and I I got question regarding entry and exit q and CH limit CU currently we have you know like CH limit equal to amount of datas and if I understand correctly in case of this Heap it would be switched to balance or like how it would work in this like how willat this would enter especially if I would like to make one validate which is 248 if so will it enter like one validator or I need to wait several boxs like how this will work yeah exactly thanks and then that's exactly the the type of question that the EIP tries to address so yeah the the context here is that currently the churn limit is rate

limited by the number of validators but we change it to be rate limited by the amount of stake of that validator so if you deploy a 248 eth validator it might take several epochs for it to activate and that'll be the only validator that's activating during that time so it's kind of like you you're just throttling it based on the amount of eth coming in rather than the number of validators so yeah and happy to talk offline about the technicals there it's it's a cool part part of the design okay perfect I think we have time for just one more question here does anybody have a question for Mike all right I I did have one Mike maybe you mentioned it um when you combine your validators if you're running multiple validators on your node um do they have to have the same withdraw credential or how how does that

work yeah so if you combine them the it will have to the the one Val dat that you combine into will have to have the withdraw credential that that you choose so um the way it's written now you merge them into an existing validator so you choose whichever one with has a withdraw credential that you're happy with the larger validator having and then you do that um I don't think it would be worth the complexity of of engineering it so that there could be multiple um withdraw credentials for a single validator that would be a bigger change but yeah perfect well again thank you very much for kicking us off today yeah thanks for having [Applause] me