EIP-7251 - Maximum effective balance overview by Paul Harris | Devcon SEA

[Music] [Music] hi everyone jeez these bright the lights are bright um I'm here today to talk to you about increasing the maximum effective balance um EIP 7251 it's less of a technical talk than the previous one um because I think there's a few things we probably need to go over so to get started uh we're going to talk about what the effective balance actually is if we have a look at um the beacon state I'm hoping people know what the state is in the consensus layer um we've basically got two lists containing information about validators there's the list of validator balances which is the total list that a validator has uh total balance that a validator has and then there's a list of validator objects each of those validators has an effective balance and that effective balance is limited to a maximum at the moment 32 e there's also withdrawal credentials um and we'll go over that shortly so the effective balance is used in a number of ways on the consensus layer um we basically use it for Activation at the moment a validator needs to reach maximum effective balance of 32 eth in order to become eligible to be activated on the network we also need to um potentially eject validators if they reach below 16 e as well as all of that uh rewards and penalties correlate with your effective balance so it's fairly effective there um important there and your probability to perform some actions notably block production which I know everyone likes if they're a validator and being in a sync committee um your effective balance affects How likely you are to perform those duties last but not least um specifically around chain security it's your voting weight for how the chain progresses uh next we'll have a closer look at validators so when we started with phase zero there were two types of validators um a lot of people knew a lot about the BLS validators they have a withdrawal address which is why I mentioned before starting with uh zerobyte and BLS credentials there's also an execution lay validator which had execution credentials in its withdrawal address and it was prefixed with a one bite both of those validators from phase zero and up to now um had a ma maximum effective balance of 32 eth in Capella there were some changes made withdrawal sweeps was fairly popular um they were only actually available with execution lay validators so there was also a process made to swap from BLS credentials over to El uh e credentials in Electra the principal change that we're making is where introducing a compounding validator it's also going to have execution lay credentials and they're going to PR prefixed with a 02 so that's going to be our flag for where the effective balance can go to on a given validator the effective balance is going to be able to increase to a maximum of 248 eth which is um 64 times what it can today so yeah a compounding validator can have up to 248 eth that's pretty awesome um it has implications so you're going to become more likely to propose a block because you have more effective balance if you're at 248 eth and also to participate in a sync committee um your voting weight actually increases so uh your vote on the security of the chain uh is increasing because of that as well and um the minimum activation balance is something that we added so the problem that we had when we were going into this EIP is that we wanted to change the maximum effective balance but we also wanted people to be able to activate at 32 e so we can't just reuse the maximum effective balance like we have previously so there's now A Min activation balance which we use um it's going to be possible to consolidate validators any validator with execution credentials is going to be able to be potentially Consolidated under a set of restrictions obviously um the way it's going to work is it's going to be driven from an execution layer request and that will give us the ability to um to prove authority of the credentials of the source validator the validator that the balance C is moving from and then that balance is ultimately going to end up on a on a Target validator and the source validator will be shut down through that process the advantage of the consolidation process over say exiting the validator and then manually doing your own deposit is that through the consolidation process you only have to pay the duration of time in the exit q and you don't have to wait for the deposit to go through the activation Que um why switch I figure is probably a pertinent question um for solo stakers particularly it seems like a compounding validator might not be that useful but there's probably a lot of people that are in a position where there's they've got say 32 e to stake they might actually have 50 e to stake right and now you're going to be able to put that extra balance onto your validator and actually earn rewards on the 50 e not just on the maximum effective balance of 32 um some people have expressed also that they don't particularly like the withdrawals process the the withdrawal stre so by going to a compounding validator Hello by going to a compounding validator you're no longer going to have that withdrawal suep well not for a very very long time um as an Institutional you might wish to reduce the number of validators that you're running but maintain the same amount of stake so this would allow you to do that and potentially reduce infrastructure costs somewhat um and generally available will be the ability which I'll talk about in a minute to withdraw your balance down to as low as 32 eth so we've added partial withdrawals um for Electra and it's pretty much only useful for um compounding validators because you need to maintain that 32 e so you can if you're a compounding validator you'll have an excess effective balance but if you're not an compounding validator you won't it's also initiated via an execution layer request um which allows us again to prove the authority of the request and one of the changes that we have made is that talking about changing the cues so the balance that gets partially withdrawn will actually have to go through the exit que uh because of some more changes um the nice thing about partial withdrawals is when we were originally talking about 7251 we had the concept of a custom ceiling where a validator could say I want my maximum balance to be 128 or 50th or whatever uh that's actually really complex um and this is already a bit of a beast so we got rid of that for 7251 um so partial withdrawals anyway will allow you to draw your balance down on your timeline um without having to have a custom ceiling so activation and exiting um prior to Electro it was very easy to put a number on the number of valid it is we want to activate or exit in any given Epoch uh I think the current number is around eight so you could because it was eight you could know that like roughly a specific amount of eth was coming on or leaving the chain as the chain security at Electro though a validator is not just 32 eth anymore so you could have a validator that's that's activating that has 248 eth that really changes how we need to think about activation and exiting so now we're looking at the balance change rather than the number of validators um and it's pretty simple maths but the eight validators per Epoch translates pretty literally to 256 e uh there's a few fields that have been added as well um such as uh the earliest ex which just allows us to do the maths and Main it all in the background here's an example very simple of um activation Q so if we have a look at the top row and we imagine that that's validators coming online for three Epoch this example where all of the validators have the same balance Works actually in Electra or it works um in in Deb and before literally eight validators are coming online every single Epoch and that's super easy the problem is when there's a large validator like the second example so in that example the large validator is having to actually consume a number of EO to have its balance processed and then once it's complete we can go back to putting on more validators that obviously may be another compounding validator and it may all start again slashing my favorite topic um slashing is term that gets talked about a lot and the problem I had when I was writing this talk was uh that overloading of the term so just briefly um slashing in terms of the consensus layer is performing a malicious action on the network and that action is a One-Shot fail someone notices you've done something I you're no longer participating on the network you get booted there's two portions to a slashing event there's an initial penalty and then there's also inactiv afterwards which go on for a period of time um in Electra we are making some changes uh we're not changing the in activities the second phase of the slashing event but we are changing the initial penalty so the problem that we have is that if you look at the denb rules and a large compounding validator of 2048 eth the initial penalty for that validator would be 64 eth uh that's a bit uh and it's quite a bit of a barrier to entry for wanting to use this this actual change so we have changed uh the quotient and the net result is in Electra the initial penalty for a 2048 eth validator if they were to perform a slal event would be half an eth and they'd still pay the SL the in inactivity penalties which scale up with balance anyway so they will pay more balance a like more inactivity than a 32e validator but the initial penalty a bit more reasonable um this is a linear scale so the good news is for any non-compound validators they their initial penalty becomes very very small uh 78125 e so that's a good that's a good outcome um to try and explain why one of the scenarios where we're slashing is kind of becomes a problem in terms of infrastructure I've made a diagram um but I should read my notes because I was just missing something um so solo stake is if you're staking at home you're unlikely to have your keys in multiple locations so because your keys are in one location your risk to slashing remain zero before and after compounding because your keys aren't in more than one location uh this isn't a consistent statement for every single implementation some infrastructure providers rely on functionality of clients so that if a slashing event occurs in this first scenario um on average there's only going to be one or two of those performing a duty in every slot so if I can detect that quickly enough I can shut down that node and so maybe I get one or two of those validators slashed and I can save a lot of my balance but if I'm on that same shared kind of scenario like the second example and I have one validator key with the same balance there's a lot larger penalty for getting slushed so that's why the initial penalty was changed unfortunately it doesn't change how quickly you can get your funds back but that's a thing to consider if you're in infrastructure and in that position uh the takeaway message probably if you comp if you're doing consolidation is just make sure you reassess your risk and don't leave yourself in a worse position than than you are today um if you are like possibly going to get slushed uh that's it for me are we on to questions [Applause] hello thank you Paul um we're going to start with questions now um again you can upvote and the ones on the top will get answered first um so we're going to start with do you expect a reduction in validator count when this is implemented and if so how big I'm hoping for a reduction that one of the bigger reasons that we wanted to do this the validator list is already very large um a reduction in active validators yes by how much I would see this being heavily used by larger staking pools um there's advantages like partial withdrawals that they could get from it so I think that it will be pretty well embraced uh but I'm hesitant to give a number to it all right next question it seems selecting attestation aggregator in the committee doesn't follow each effective balance is this fine um it shouldn't be a problem because agre there's multiple aggregators in attestation committees um every slot thank you how much of a reduction in the number of validators do you see after this EIP uh I'm going to decline to answer sorry and the same as the last one um I would hope that it's of the order of 10% maybe more but it's really hard to put number on it because I'm not these operators how exactly is exiting an epic ordering to be determined oh sorry did you see that happen too I did see that happen um do you still have the question I don't know what hold the exit order I can answer the exit order um so the exit order is not any different to today in real terms we've just expressed it differently um the the people that have got a exit in earliest will be exiting first and the duration that it takes will differ when there's compounding validators or partial exits or partial withdrawals because of the fact that that balance change is going through but the ordering shouldn't change thank you um what happens if large operators don't adopt 7251 are there steps we can take to incentivize adoption we've taken a lot of steps to incentivize adoption um initial slashing was a big step towards incentivizing it uh and pushing all of this through execution layer requests actually reduces the ux for normal operators but it was what the largest staking providers requested specifically for so um we have definitely been in active discussions to make sure that it's going to be used is the probability of becoming a block proposer the same for both 2040 eth validator and 6432 E validators it should be roughly equivalent simple answer um how do we encourage more consolidation given that it's relatively risky it's only RIS risky for large operators if they're Distributing their keys amongst mult multiple nodes so the easy answer to this is always put your keys in one location don't share them across nodes and you can't get slashed oh we had another one okay there we go um can you switch from compounding credential back to the 0x01 credential to reenable Auto sweep without exiting there's no current um implementation that would support that but there's um some new functionality coming actually in the next talk um that enables that to be written relatively easy should we need to in the future wonderful um isn't it supposed to be expensive to attack the network why reduce slash then we any reducing the initial penalty which hasn't been I mean overly effective in some ways anyway at reducing like at discouraging people from performing slashing events um so the main thing is to not discourage people from using features that are help to helpful to the network I think we have time for one more we'll see if we can get two in but will EB still be computed only in one eth increments yes okay we're speed answering going to get to some more what is the average effective balance for valid validators at present the average effective balance I believe if I looked the other day was about 33 e but it might have been slightly more I could be wrong in that okay last one uh roughly a good one is not good enough me PE that's not a question is that a question it's not we're gonna go for the one after that I don't know what that is yeah would the reduction of work to operate multiple validators with 7251 result in further increase on centralization of the stakes not further increase because it's the same pool that's operating them and that is all we have time for today please give a round for Paul thank you thank you very