Staking Strawmap

Transcript

Okay, perfect. Hi everyone. Um, who is a staker here? Raise your hand. Okay, pretty much the the whole room. That's great. So, this talk is for you. This is the stake map. Uh, the strawman road map for stakers. Um, so what I'd like to do is start with this document that was published about a month ago. Uh, you can find it on strawmap uh.org. And what I've done is that I've taken the subset uh that is relevant for stakers and we have a new domain stakemap.org that you can check out now. Um that is basically just this slide. Now what I've done uh to help us walk through the the stake map is color code the various boxes. So we have green boxes that are generally like good for

stakers. We have red boxes that are kind of bad or apply pressure in some way that's worth discussing. Um, and we also have in uh the black outline there some of the boxes that in bold um where you need to pay special attention because there's like some sort of potential change to your setup to your DevOps um and the dash lines um is actually a good thing. It means that there's a potential simplification to to your setup. Okay, so let's start from a clean slate and basically add the boxes one by one and uh walk you through the the stake map.

So I'm going to do this uh layer by layer starting from the execution layer at the very bottom, the data layer and then the um the uh the consensus layer. And the way that this this document is organized is that we have the various forks. So we have seven forks covering uh four years. So roughly roughly two forks uh per year. So our starting point at the execution layer is this idea that we're going to increase the gas limit a lot and this is going to put pressure on on stakers who have to process all of these blocks. Um and we actually have this proposal from Dankrat uh before he left where um we can have the gas limit increase automatically. So there won't

be any need uh to basically have to manually override um your your your gas limit setting. And this is why it's a potential simplification to to your setup uh in in the dash lines. Okay, so that is our starting point. In order to deal with the increase in gas limit, we're going to have to deal with multiple resources. One is state growth. How do we make this manageable for stakers? And the the best idea that we have here is called multi-dimensional pricing where in addition to having a gas for execution and a gas for blobs, we would also have a gas uh for for for state growth and we will have a corresponding gas limit and that gas limit can be set in such a way that it

is uh sustainable. Uh we also have another idea called block in blobs. What does that mean? It means that we take EVM blocks and we put them in blobs. uh and so instead of having to download the the the EVM blocks, you can just do data validity sampling. And this is a massive improvement uh on a on the on the bandwidth standpoint. Now, in order to enjoy uh block and blobs, you actually need to verify ZKVM proofs because you're not downloading the blocks. You won't be able to naively re-execute them. So in HAR uh we have this proposal called optional proofs um where early adopters like yourselves could opt in to um to download ZKVM proofs uh instead of verifying the

blocks uh naively and that will be a massive change uh and simplification to your setup. um you know you won't need an NVME hard drive, you won't need a powerful computer, you won't need, you know necessarily a powerful, uh internet connection, especially when the gas limit increases. Now, um optional proof is kind of the training wheel mode. Um we don't recommend it to large stakers such as institutional stakers because we want to keep the amount of EF staked that is in on those training wheels relatively small. Uh but then eventually we will have mandatory proofs. Um and at that point all of the uh the validators uh will be verifying ZKVM proofs uh and it

will be an extremely lightweight thing to run staking nodes. But um there is one small detail which is that we still want the validators to be maintaining the mempool and to help with censorship resistance. Um so there's this idea called validity only partial state also known as vops and it's basically asking the validators to keep a subset of the whole state that is relevant for maintaining the menool. So when you have a transaction on the menool you want to know that it pays for gas. This is the the main anti-Bible mechanism and in order to know that it pays for gas you need to know the account balance and you need to know the nons and like just a small amount of

data and it's roughly 10% of the whole state. So today's Ethereum state call it roughly speaking 100 gigabytes you only have to store uh 10 gigabytes if you want to participate in maintaining the memp pool and with censorship uh resistance. Now um related to VOPS is this other upgrade called binary trees. So the idea here is to move from a hexary tree to a binary tree. And the reason why I put it in red with a bold outline is because in the transition point from hexary trees to binary trees. One of the proposals is to run both trees in parallel. And so what that mean is that you have to store kind of an extra copy of the state and

that might be an extra you know 100 gigabytes or whatever uh overhead um and that might require some sort of intervention uh from from the staking operators but hopefully not too much of a of a big deal. And then we also have bals um which is coming uh in in the next fork in glamsterdam. And here um it's generally a good thing because it means that um verifying blocks should be much easier. Uh you won't need a fancy NVME hard drive because you'll be pre-fetching all of the the state that you're accessing. Um we'll be able to increase the gas limit uh more safely.

But there's a little bit of a red outline because there is going to be a little bit of a of an increase in um in bandwidth usage um at least before we have uh things like like ZKVM proofs. Okay. And then final box uh in the at the execution layer is uh what is nebulously called endgame state. And the the idea here is to try and find some sort of solution that's sustainable in the long term for state growth. Uh and one of the ideas is called state expiry which is basically saying that if you have some pieces of state that are unused. So you have some accounts or some smart contracts that no one touches for long an extended period of time you can just prune them away from the state.

Uh and if for whatever reason the owner of that state uh wants to revive it or anyone wants to revive it, they can you know pay the gas cost to to revive it in in a in a safe way. And so that would mean that the the VOPS uh state would also benefit uh from from this pruning and make things more sustainable for the for the validators. Okay, next up we have the data layer. So the main pressure point at the data layer is that you know we want to increase the number of blobs on a regular basis. So what we have in the straw map right now is uh a blob increase through so-called BPOS's blob parameters only every every year. So that would be uh once every

couple forks and eventually we had these very ambitious plans uh you know to have one gig gigabyte per second of data availability that would unlock you know so-called teragas L2s with where all of Ethereum could process you know millions of transactions per second and be the the the center of the internet of value. Um, now we already have data availability sampling which is already uh fantastic to deal with the the increase in in in in blob count but there's a couple other ideas. One idea is called blob streaming. So here um you download and process and sample the blobs ahead of time offchain before they they they they they go onchain. And so that means that you can spread the

bandwidth load uh outside of the cricket critical path uh which is going to alleviate things here. Um and then there's another you know quite exciting um development. So EP2P is a new networking library that was uh open source just a couple days ago. It's developed by the foundation Raul and the networking team. Um and basically they've um they're suggesting moving away from lip P2P which is quite inefficient um and uh you know having all sorts of clever ideas like erasia coded broadcast in order to dramatically uh reduce the total bandwidth consumption of uh of the peer-to-peer uh network.

Okay, so that's the data layer. Notice that none of the boxes here are um are in bold. So there's there's really nothing to to worry too much about from the point of view of a staker. Now if we look at the at the consensus layer, this is where things uh you know are a little bit more subtle. So one source of pressure is in terms of continuously improving uh the slot duration. So we're at 12 seconds now. There's a proposal called quick slots uh you know which might bring it down a little bit potentially to 10 seconds or 8 seconds. Maybe it'll go down to six seconds and then potentially even lower.

Four seconds, three seconds, two seconds. We don't really know. Uh but you know, more likely than not it will go down quite significantly. And you know, this increases the amount of bandwidth usage because there's a fixed overhead per block that needs to be you know dealt with somehow. And it also has some pressure on on on on geographical collocation and and things like latency. Um so that's something that uh you know will be partially mitigated by by EFP2P for example. Now we have another uh source of pressure uh which is this idea that we want the validators to be voting more often. So right now as as an attesttor you vote once every epoch uh and the epochs are quite long. It's 6.4 minutes.

Um so there's a proposal here called four slot rounds. So that's a round of voting. Um and that that would you know dramatically reduce um the the epoch duration effectively and and mean that you'll have to do uh uh more work. Um and both of these uh upgrades here like reducing the slot duration and reducing the um the the voting rounds are to a large extent unlocked by this idea called decoupled consensus. So right now we're coupling the so-called heartbeat with the finality gadget. So everyone's familiar with the finality gadget, but what is the heartbeat? The heartbeat is basically the mechanism that keeps um chain growth. So what is the mechanism

that keeps the chain from growing and gives us livveness? So Ethereum has had liveness you know 100% uptime for the last uh 10 years. And the idea here is to change the livveness mechanism uh to have a randomly sampled committee of 256 validators again randomly sampled at every single slot and that would be a different mechanism to the fast finality and so these this modularity gives us the opportunity to update things uh on different schedules.

Now in order to dramatically uh reduce the the the voting uh duration we will need to try and encourage the the validators to consolidate. Uh so we have this proposal and it's bolded. This is something that you have to pay attention to. Um this proposal to cap the number of attesters to 128k. So what does that mean? It means that the attesters would be ordered by balance. So greatest balance to the smallest balance. And if you're not in the top 128K, you get forcefully exited. So basically, as an operator, there's a a couple things that you can do. Either you can consolidate if you have multiple validators. That would be

the preferable thing. Um, and if you only happen to have one single validator, like my suggestion would be just to make a little top up so that you're slightly above 32 E. maybe at at 33 E. Um, and you know, 128 at testers is way more uh than validator slots that we need because we only have about 8,000 um actual operators. So hopefully um there aren't that many uh attesters that that that are that that are kicked out.

Um and uh you know by reduc sorry going back to this slide here by reducing the total number of attesters uh by you know a factor of eight it makes it easier to reduce by a factor of eight the the the epoch uh duration and then you know there's this this this final piece of pressure um that comes from uh you know eventually what is you know a bit nebulous endgame finality reducing the the voting duration to the maximum which might be you two slots per round or one slot per round or or three slots per round. We don't we don't really know.

Okay. Now, um one of the things that the decoupled consensus gives us is this idea of having a postquantum heartbeat. Um that would come very very soon potentially in 2027. And the idea here is that if quantum computers were to come much earlier than we expect uh we would have the opportunity to gracefully degrade uh Ethereum. So we would still have the the chain livveness the heartbeat um but we would disable the economic uh security. So we disable slashing uh because the slashing requires very fancy postquantum uh cryptography with the aggregation whereas the heartbeat um doesn't need

aggregation and the reason is that there's only 256 um at testers the signatures are about 2 kilobytes uh each and so we're talking about uh you know something like half a megabyte or maybe a megabyte uh of of data which is uh which is totally manageable. Now another piece of um uh of action that needs to be taken uh by the validators is to register their postquantum pup key. So this is a bit of a of an expensive action. It means that you have to go to your cold storage, access your withdrawal credentials and sign a message saying, "Hey, my new

postquantum pub key is going to be uh XYZ so that you can participate in the heartbeat." But the good news is that there's synergies with the attest cap and the consolidation. And the reason is that consolidating validators also requires touching your cold storage and your withdrawal credentials. And so you might as well do both things at the same time uh while you're at it. And if you so happen, you know, to control multiple validators, well, the tooling can just set the same uh pup key for all of all post quantum pup key for all your validators and also automatically do the the consolidation.

Now um another um uh and yeah another another kind of consideration here which adds pressure is the idea that um attestations are much more expensive in the postquantum world. So BLS signatures are under 100 bytes uh roughly 96 bytes and they're going to grow uh dramatically maybe a factor of of of 20x uh all the way up to to two 2 kilobytes uh per attestation and so that is going to put load uh on on on on the on the peer-to-peer uh networking but there is like some amount of of of of good news here uh which is that um in

the LAR fork uh which is um currently slated to be the big lean fork where we have the postquantum upgrade, we have endgame finality. We also have an amount of of cleanups that do provide a little bit of uh of relief. So, one of the advantages here for for the stakers is that we're going to have very optimized cues. So, right now the deposit and the exit cues are just needlessly slow. uh and this is something that uh will provide a little bit of quality of life uh for for for the validators.

Uh we also have EPBS uh which is uh coming very soon in Glamsterdam. This is mostly a good thing uh for the validators. It gives them the option if they want to to not connect to relays if they don't like relays. Um, but you know there's a little bit of a red outline uh because there's you know potentially you know a a new vector for denial of service attacks or or things like that. So I'd like to see how how it all pans out uh in production. And then we have fossil here uh which is marked in a bold outline. And the reason it's in bold is because some validators might want to opt out. So by default the client uh you know should be um uh

having the the validators participate in censorship resistance through inclusion lists. Um but if you for whatever reason you don't want to participate uh then you you will have to explicitly opt out and this is an action that you would have to to make uh as as a staker. And then we come to um a couple boxes that are like much more uh speculative because they're a little bit uh controversial um and are basically related to to Jerom's uh talk just before me. So uh the attest uh state cap here um you know would is something that is you know in my opinion extremely healthy for the entire network. Uh I

mostly agree with with Jol's talk. Um but it does you know very much change the economics uh for the stakers. So instead of having a minimum guaranteed like 2% yield uh for for for the stakers um we would have a market uh set uh yield and um and and and and the way this would this would work of course is by changing the issuance curve so that as soon as the total amount of Eve staked gets close to the cap the yield starts uh starts going down. And the reason why I put it uh in bold here is because I expect um you know some of the validators not to change their their

DevOps setup but basically to to start lobbying uh the social layer and this is something that that that we've already seen. So, you know, I guess we're in France, there's a lot of of strikes, and so, you know, maybe at next EVCC, all the stakers could kind of say, okay, we're going to shut down staking for for one day or something uh in protest of the ATS state cap. Um, now, if we are going to do the state cap, we should also do something called APS. And the reason is that if we do state cap but not APS um then we would be in a position where the issuance more likely than not would be extremely low potentially even zero. Uh and all of the rewards would come or most of the

rewards would come from from me. Uh and MEV is extremely spiky. um it's um extremely noisy and this would this would basically be a centralization vector because the average validator would would make much more than the median validator and most of us are median validators. So we would be making much less money than the average validator and it would basically be gambling. It would be it would be a lottery um and it would uh be a centralization vector because it would incentivize pooling and and smoothing. Okay. Now um there's a few final uh green boxes here. One um in the longer term is the idea of having um way more

attestations uh per slot. So what I expect will happen is that when we consolidate the validators here with the capping the minimum balance to become a validator will only increase a little bit maybe from 32 E to 33 E for example. And then when we go back and increase the number of um tester slots, we would more likely than not just saturate the market with supply of attest slots and there wouldn't be enough demand, right? There isn't a million operators out there who want to be staking. And so the minimum deposit to become a validator will be much closer to whatever we set it to, which could be some arbitrary number like like one Eve. Um, and so

this is kind of an an an action call for those who don't have 32E, uh, but might want to stake in the future, you probably will be, uh, able to. Then we also have a box here called secret proposers. Um, this is a kind of a quality of life thing where as a proposer, you don't leak your IP address ahead of time and so you're not exposed to denial of service attacks. And then there's another quality of life thing uh called real-time consensus layer proofs. So the idea here is that instead of having to uh verify blocks the naive way, you can just verify proofs which is much cheaper. So for example, if you're syncing from uh the chain because you

went offline for a little bit, that will be much faster. And it also opens up the possibility if you want to uh to stake on a on a ridiculously low powered device like you know a Raspberry Pi or even a a $10 Raspberry Pi Pico. So that's pretty much it and happy to take questions. Thank you. Just a just a question on the postquantum cryptography here. It seems to be the big theme of this conference.

Um in in your road map that you indicated here, what roadblocks do you see that would um prevent us from becoming postquantum proof? And what are solved and what are not solved? And is your deadline going to make the emerging Q day that's coming closer and closer? >> Yeah. So um you know a lot of progress is being made of quantum computers but very few experts believe that we're going to have cryptographically relevant quantum computers also known as crocs uh before 2030. And the idea here is to try and complete the entirety of the postquantum migration uh by 2029. Uh we do have a lot of work because we have to

migrate the consensus layer, the data layer and the execution layer. Each of which is using three different pieces of cryptography. Um specifically BLS for the consensus layer, KCG for the data layer and and and ECDSA for the execution layer. Now um we have been working for quite a while now uh on on the solution uh to uh to to to Postquantum. We have a new team uh the postquantum team with Emil and Tomar and at first approximation I'd say we we have done all of the research we've done a lot of the prototyping and now it's a matter of productionizing um so we have uh 10 different client teams uh that are

you know um have implemented the these these post quantum clients in the context of of of lean consensus we have had four devets um we have the equivalent of BLST. So this is the library for BLS in a postquantum um in a postquantum flavor which is called um lean VM. Um we've done you know a lot of the the hardcore um cryptographic R&D with the with the consensus team. You know we've optimized these hashbased signatures. So at this point I'm feeling extremely good about uh the Ethereum's uh road map. Um what I think will happen is that the whole

blockchain industry will copy Ethereum because right now almost no one is tackling the hard problem which is so-called signature aggregation. So I already mentioned the size problem that an individual's postquantum signature is at least 10 times larger than ECDSA and um the only solution that I know of is to use SNOX to aggregate all all of those signatures and no one's working on this other than than the Ethereum Foundation and one of the strategies that we're taking is uh to you know ironically partner with Bitcoiners and The reason here is that if we can pill the bitcoiners in using the same

solution that we have, then we basically will create a de facto standard because the top two blockchains will have adopted it and it's an easy copy paste for for everyone else. And um turns out that uh blockstream is now taking this seriously. um they uh we we you know we we we had conversations with them and uh we have a solution which is extremely bitcoin friendly where they only need a single hash function and they can use shhatu which they already have so for them it's a some cost um and ironically it also provides a um scalability increase for them and the reason is that in any given uh bitcoin block there's roughly 10,000 uh uh signatures each signature is 64 byt ecdsa Okay. So

that's 6 6 640 kilobytes of data. But the proofs that we're developing are about 100 kilobytes. So it's basically a 6x improvement in data overhead for the signatures uh which would allow Bitcoin to adopt postquantum signatures without um uh decreasing their throughput and also without increasing the block size which is socially very difficult for them to do. >> Okay, we're out of time. Thank you. Have fun.