Justin Drake - Beacon chain design mistakes

Transcript

🚨 Justin Drake discusses the mistakes made in the design of the beacon chain and how they can be improved in the future.

all right thank you all I'll get us going really quick here um another person that needs no introduction is Justin Drake a uh researcher with the ethereum foundation and he's got a very tight schedule so we'll go ahead and pass it right over to him okay perfect thank you um so today I'd like to do a bit of a retrospective on the the design of the beacon chain and and try and highlight some of the mistakes that we made and basically explain how you know we messed up but maybe we can improve improve next time um and yeah I I think that you know we have made significant mistakes so if

we hadn't made these mistakes if feeling would be you know really really awesome but we have made some mistakes and uh let's have a look what these are um so I've split the mistakes in kind of two sections one like painful today obvious mistakes and then you know things that might come bite us uh in in in the future so uh I think the the biggest mistake that we've made that's that's biting us today is the the the max effective balance so we we kept the um the amount of e per validated to 32 e and the reason why we did that is for Shing we we used to have a shing design with these Shing committies and it was kind of important that the sampling was

🔑 The beacon chain design mistakes include unnecessary friction for validators, high number of validators causing load on clients, suboptimal compounding, longer slot times, high minimum deposits, unfairness, centralization, and delays in the withdrawal queue.

done very very smoothly you didn't want any lumpiness with very big validators um kind of over overflowing like one one of the Committees but with d Shing we have this awesome new design which doesn't require committees so we don't need to cap the validator that's pure technical debt in in my eyes and that comes with consequences it's like unnecessary friction for the validators we have way too many many validators we have roughly speaking a fact of a 100 blowup uh like operators to validator so roughly a million validators and roughly 10,000 operators um big overhead there um and we also have suboptimal compounding if you have 32 e uh right now in order to to to do the compounding

you need to wait until you have 64 e and so when you have 33 34 35 e you you're not making use of that additional uh if as a as a sort of validator at least and the obvious thing here is just to remove the the max balance uh and the the way that we plan on doing that is in two steps one is to increase the maximum effective balance from 32 e to 2048 but also eventually just completely remove it because uh we won't need it in in the long term now in terms of like this one mistake that has like Rippling consequences so for example the fact that we have two many validators uh puts a lot of load on the clients but it also means that future upgrades are harder so

for example enshrine PBS which requires two rounds of attestations harder um single start finality which also requires an extra around of attestations much harder to do uh it means you know we have longer slot times it means that we have um you know maybe unnecessarily High uh minimum uh deposit so we could be having 16 e validators or eight e validators but because uh because of this one design mistake where we we have 32 e validators right now okay um and I guess the the compounding is is you know obviously a source of unfairness it's a source of centralization uh it's not a good look um and uh it it also has impact on the withdrawal queue

because right now what happens is that as soon as you have a little bit more than 32 e don't know if you you've obser observed that but basically you have these partial withdraws that will sweep uh the extra balance from all the validators and that takes a whole week more or less to sweep through the whole validator set and that you know means that if you want to do a full withdrawal as opposed to a partial withdraw you have to pay the cost of waiting roughly uh roughly a whole week which is you know totally unnecessary okay next big mistake which is actually very much related to the first mistake which is the in the committee index so we used to have these Shard committees and there was an Associated committee index uh and what happening is that at every slot uh we have um different

🔑 Removing unnecessary shard committee indexing and gating withdrawals with LS signatures is causing unnecessary friction for initial validators, resulting in a 64x overhead on verifying signatures.

committees that are signing different messages and in the previous design basically each Shard would have its own State Route uh and so it was kind of normal to kind of index them uh because the these would be different messages signed but um turns out that now we can have all the validators signed the exact same attestation um and BLS aggregation works like Works basically when it's the same message that's being signed that's the the key trick um and so we have like roughly speaking 64x overhead on on verifying signatures which is pretty crazy um and it it also affect well it affects normal clients but it also affects uh like clients like you want if you want to SN ify the beacon chain now

you need to have a circuit which can verify you know all the pairings to do to do the signatures so that's a a very kind of s mistake in hindsight that that is causing a lot of pain uh and the obvious um you know fix is just to remove the the committee index um this one is also kind of a big face palm um basically we we have this feature which is completely unnecessary whereby we're gating withdrawals with a LS signature um but like withdrawals where uh and like eventually it's back to to E1 and and so we're causing all this unnecessary friction with the initial validators that had to set up you know Cold Storage without the

hardware wallet because there was no support for BLS signatures and then all the stress I don't know if you've gone through the stress of like going from 0x00 to zx01 it's is like um you know not not nice uh and then there's like this useless feature that's there uh that's like not not not helping so we messed up here as well um next up proposal rewards so this this is kind of a fun one it's one that I realized only recently but basically uh right now there's this proposal Lottery uh roughly speaking once every four months as a validator you win the proposal Lottery you get to propos a block and you get some uh some issuance that corresponds to to this to this uh to winning the lottery um and really what we should

🔑 Implementing penalties for being offline instead of rewards would reduce variance and make future upgrades safer in the beacon chain design.

have done is we should have done a propose a penalty in case you're offline so you you still want an incentive to be online but instead of having a reward which creates this this High variance you want to have a penalty in case you're not offline and most of the time like 99% of the time folks are online and so it would be like a completely flat uh you know APR and reward curve um and you know this this Varian is calling is one of the reasons why we have you know this pulling um and this also makes future upgrades harder so for example we want to do stake capping uh where we we we have this this issuance curve which goes uh towards negative Infinity once you reach this the state cap and in order to do that safely you need the the the the variance

to be very very low uh so so this is this is a fix that we could do um you know at some point in the future um okay issuance curve kind of uh talking about issuance one I mean I think we did a pretty good job with the issuance curve but uh one thing in it is that I think we're just overpaying for security we have a huge amount of of of Economic Security right now almost 60 billion and I think we could have like reduced by aaor of two uh the the the assurance and another thing that we kind of messed up a little bit is that there's no there's no State capping and that would have been like extremely easy to do if we had you know thought about it earlier on um basically is this idea

that you know if you want to have a maximum amount amount of stake let's say 30 million e then as soon as you start getting close close to to to to this so the amount of stake gets close the the the issurance goes goes negative um and then there's also no stake lower bounds so if there's for some reason there's like a very small amount of of e Stak you know let's say only one million e there's no real incentive uh to to to to Really push people to to stake and and increase the economic security and that we can do something similar where basically the curve like starts growing very very fast as soon as you're below kind of the safe the safe threshold and like the the instead of a square root basically my suggestion is

to use a cotangent which basically starts at at infinity and then goes goes to zero and then negative Infinity okay uh Fork Choice bugs um so we've we've had main net issues um and you know not not great um but also you know it's just caused so much um so much friction for for the developers and and and various researchers including academics because we've had these academics look at a fork Choice rule they find like all these little edge cases and we try and fix it and the process of fixing the fork Choice rule introduces more more more attack vectors and then this cat cat and mouse where we keep fixing and breaking um and it's

🔗 Beacon chain design has encountered fork choice bugs, causing friction for developers and researchers, leading to a resource-intensive process of fixing and breaking, and should have faster and more dynamic ejections and reduce the increment on the effective balance to avoid unnecessary harshness and centralization.

just very resource intensive uh and you know it's also not not a great look um so really what we're working towards and I think we're you getting close is basically a provably secure folk Choice rule which is which is bulletproof and and won't have to be to be fixed on a continuous basis ejection balance so right now we have this process where if your balance reaches 16 e you get automatic automatically ejected from the beacon chain um and what and unfortunately there's about 0.2% of validators that they just permanently offline and like you know this Z validators that are just just just leaking e for for no real reason and they're also kind of affecting to a small extent the the

liveness of the chain um and so it's just unnecessarily harsh to to those validators and it's all very inflexible and so really what we want to be doing is having faster ejections and also more Dynamic ejections so if if you know you have 99% of the validators that are online then it's actually safe to eject people that that go offline but if you have a m you know problem where like I know 80% of validators go offline you don't want to eject you want to give them a chance to come back in um so you want to have this Dynamic logic uh to take care of that the effective balance um so right now we basically have one e increments on the effective balance um and it was

done as an optimization to to improve the democratization but I I think it's probably unnecessary uh complexity um and it also adds uh you know problems to the compounding right because if you if you have uh you know 31.9 e you know you have now you have 0.9 e which is not working for you and not actively staking and this again is a centralization vector because like the really big stakers they can they you know for them one e relative to all their stake is a is a is a tiny portion and so you know the the the obvious solution here is just to reduce the increment uh maybe bring it down to one gay so that we have a single balance

🔑 Reduce beacon chain balances to one, increase slot duration, address coordination challenges, sync committee issues, and adjust penalties and gas costs for larger deposits to fix design mistakes.

on the Deacon chain not two separate balances uh slot boundaries um so this is this is more of an estatic thing uh but for some reason our 12C slots don't start exactly at the minute they start kind of one second before the minute which is kind of a bit arbitrary a bit strange um and uh yeah maybe a l unpolished okay and and you know you know I think that ideally we would have align slot boundaries but it's kind of now that we've while we have it you know it's changing is actually quite difficult um okay painful stuff that might be you know painful in in in in in

the future so one of them is the 12 talking about slot durations the the the 12 second slot duration so um it turns out that you know just just like the fact that we have too many validators the fact that we have a relatively short uh slot slot time makes it difficult to to do certain upgrades like single slot finality and then Shrine PDS and the reason is that these upgrades add new rounds of attestations within a single slot so basically a single user level slot now has multiple system Subs slots um and so if we stick with 12 seconds now we have you know sixc subslots to do to do these these these attestations and

aggregations with potentially hundreds of thousands of the validators and it becomes very difficult and so the the the obvious fix here is to increase the the the slot duration but um I think just changing the value is going to be just uh difficult it's going to be a coordination Nightmare and I think some users or some dap developers will push back on on larger slot durations so that's going to be an interesting uh development another thing which you know is a little bit underwhelming is this the sync committees so that there isn't much adoption today we have all this infrastructure for like clients um with the sync committees but you know not much adoption and also the the thing

that's kind of annoying is that we don't need Sy committees in the long term it's just a piece of temporary infrastructure until we have like a fully sned Beacon chain you know which is your like client and so it's kind of over time going to be a piece of technical debt uh which maybe we should we should consider removing or at least removing some of the incentives attached to it so that we we reduce the cost of of syn communties um uncapped penalties I mean this is a bit more of a you know bleeding edge and maybe more controversial thing but basically um today if you want to build a rocket pool style um liquid staking token uh it's not fully trustless uh and there's a

very easy fix at the Beacon chain level which is just you cap the amount of penalties so for every 32 e validator for example we could cap the penalties to just four e um so if you if you get slashed maximum you lose is for E if you go offline and you start leaking maximum you lose is for e and then the 28 e is now like guaranteed kind of uh unlash um and so now you can build rocket pool where like the the r e is like as good as as if it was built natively almost like an enshrined liquid staking token um so yeah that's a that's a possibility it's a very easy fix technically uh but uh I guess we need to to look into the

consequences and then here okay this is a bit of a an interesting one basically if we're going to increase and we I think we will increase the um the the maximum uh effective balance to or even remove the the maximum effective balance now basically people will be making deposits that are much larger than 32 e um and in order to retain the fairness of making deposits we need the amount of gas used to be proportional to the to the deposit um so if you deposit for example 64 e that should cost twice as much as depositing 32 e if you deposit a

million e that should be you know correspondingly larger um and right now the the way that the gas scheduling works for the for the deposit contract first of all it kind of is it varies depending on like if you get lucky or unlucky with the Merkel tree uh but also is not is not fair is not um scale to be uh to to to to stake basically um and you here the the obvious fix which if we had done it earlier back then it would you know would have been very easy but now the deposit contract is like a a piece of infrastructure that that's very very hard to to remove so we kind of stuck with it and then I think this is my final slide which is uh BLS signatures so I think

🔑 Redesign of Beacon chain and Ethereum needed due to potential lack of quantum security in BLS signatures, with focus on implementing a quantum secure algorithm and aggregation signature support.

BLS signatures have been been really successful but the one thing that will come bite Us in maybe 10 15 years is that they're they're not Quantum secure uh and so we're going to have to kind of rip everything out and also remove other pieces of cryptography which are not uh Quantum secure um and you know it's possible that we have to rip out so much cryptography and and redo so so much of the internals uh that we kind of have like Beacon chain 2.0 or ethereum 3.0 uh and I guess at that point there will be an opportunity to just clean up all the technical debt and have a design which is you know essentially you know close close to perfect and that um that's it thank

[Applause] you now let me let me ask Justin first because I know you're on a typ time frame do you have time for questions or no I can take one or two questions yes two questions who would like them two questions anyone do we have a Quantum secure algorithm that supports aggregation signature aggregation yes so uh the cryptography team within thean Foundation has been looking into that quite a bit um basically we at a minimum we have uh fry based uh basically similar to the stock technology signatures and and and you can do

recursion of snars in order to do the aggregation there's something even more uh efficient uh which is basically Lattis based so luses is this very promising piece of postquantum cryptography um which still has like these these these these powerful properties with the homomorphisms and so we can get maybe similar things to BLS signatures where you just add the signatures together uh and then and then they just magically aggregate all right just uh one last question maybe I'll I'll throw at you here is of of the ones that you covered uh there were quite a lot of uh maybe things in hindsight what is your level of confidence about how many of those could be fixed in the future and how

many of those we'll just have to live with yeah so um I think the good news is that most of them can be fixed and if we thinking about you know eum 3.0 uh then you know everything can be fixed um but the good news is that like the really like the worst one which is probably like the 32 EV validators that that's something that we can fix there's an EIP for it it's called increasing max effective balance I think it's a no-brainer I think we should do that as soon as possible um and so I'm hoping it will happen maybe not in the next hard Fork but the one after that all right well thank you again very much for your time today everyone thank you