Glamsterdam, Stakemap, Lean Ethereum - Staking Nerd Talk - 7

Transcript

Intro

Hello Patches. How are you today? >> I'm great. And welcome everyone to staking nerd talk seven. Uh today we are going to briefly talk about the next hard fork Amsterdam. And then we're going to look forward into the uh straw map for staking in particular what's coming down the uh the pipe there uh including post quantum security. And uh faster finality maybe if we get to it and uh the very scary proposal to uh kick everybody out of the staking pool who doesn't have at least 33 ETH.

Um Okay, let's let's get started. Yeah, so the I think one of the things that's worth mentioning is that last time we talked uh we talked about Amsterdam a lot and a lot has changed since then. >> Yes. >> [laughter and clears throat] >> So I think maybe we got a little bit ahead of ourselves. Uh We did a little bit. Um do we know what's in Amsterdam now? Still not really, but there's been some decisions made. Uh there was interop in in Svalbard and a bunch of the core devs got together and they made a bunch of decisions.

Glamsterdam

Um and forecast has been updated a few times since then from what I can tell. So you can go check, but the headliners are still the same. Right. Which are? >> Uh that's EPBS and access lists. Right. EPBS being the enshrined proposal builder separation, so the replacement for MEV boost. Last I heard from the dev teams, and this was actually on the Rocket Pool Discord, they said that um their current design, which again can change before it ships, is that the consensus layer client, so your lighthouse, Teku, Nimbus, Lodestar, etc., are going to talk directly to the builders, and there will not be a side car like MEV-Boost.

ePBS

Um the smaller EIPs, you know, around the edges that aren't headliners, they're still discussing which of those make it in and don't make it in. Yeah, and we talked about a few of them last time, so you know, it's possible that something we did talk about won't make it in. Um Absolutely. >> like I think one of the things that's kind of still on the fence is the using the consolidation queue for exits. I'm still not sure where that is. Right. So, last time, I know I felt a little bit confused about the the um slot timing in Glamsterdam with EPBS. I feel slightly less confused, but I I wouldn't say that things are settled. Um what can you say about that, Patches?

Yeah, I mean, I think it's still confusing. Um and I think a lot of the confusion comes from the fact that we are getting a little bit ahead of ourselves, and they keep changing things around, so um the data that I'm working off of right now is already stale, and I don't know how things changed in Norway, but I can tell you that one of the interesting things that I did see change was the way that payload timeliness is treated by uh members of the payload timeliness committee. So, when is a payload timely?

So, it used to be that there was a specified 6-second threshold in the spec. And if you are in the payload timeliness committee, you had to vote, I think it was at the 9-second mark, whether or not you had seen the payload by 6 seconds. So, that gave you sort of 3 seconds of downtime. >> [laughter] >> Um and they removed the 6-second uh threshold from from the spec entirely. And and now the payload timeliness committee at the 9-second point, which is when they used to vote, they still vote at the same time, all they're saying is like, yes, I saw the payload, or no, I didn't see the payload. And and the concept of timeliness becomes a

subjective thing where a payload is considered to be canonically timely if at least 51% or something of the payload timeliness committee votes for it. So >> Vote for that, right. Okay. >> Yeah. So we'll we'll circle back to that when some of the numbers are final and um I think our understanding is better. Uh do you have a uh good guess as to when Glamsterdam will ship? I have my own, but No, um I think we were kind of saying fall would be um optimistic last time. I think that's still optimistic, but I'm I'm hoping 2026.

Glamsterdam ETA

The next >> Yeah, that would be very nice. Um I believe there was a um there's a tool on forecast that lets you kind of put in some numbers and uh and see what Yeah, there's the scheduling planning tool, that's right. Here we are. That basically says, here are the devnets, and then counting forward from the devnets, right? This is what that gets us. So the absolute earliest day it could date it could ship is in September. Um and Yeah. So still in 2026 would be amazing. And that's sort of if everything goes as expected. So I think that's >> As expected and there's no further delays and no further discussions about what does and doesn't make it in and

etc. Yes, exactly. Uh so it will certainly not land on the 1st of September. Um good. I think that's all we had to say about Glamsterdam. Now there is a um rough ethereum roadmap that Justin Drake put out and I think it's important to say that this is kind of his view of things and governance for ethereum is notoriously decentralized so you can't take this as like the official ethereum idea right and that is at straw map dot org and then he did a similar thing just for stakers

Stakemap

all of the topics in the straw map are boiled down a little bit and and just presenting the things that he thought were most important to to stakers and that's stick map dot org um let's talk about that a little bit Okay so the straw map as sorry I just opened stick map and it's so much simpler It is so much simpler to follow yeah I mean straw map is really busy because it's got everything right and the stick map has just the things that he thought were important for stakers So they're both about seven hard forks of planning which is like a huge timeline I think

that that brings us well into the sort of 2029 2030 era and those days are important >> yeah I think it's important before we go any further to point out here when you look at both of these glass to them on here go to in this straw map are landing in 2026 which they most certainly are not glass to them on here go to is not landing this year it's not happening Amsterdam we still hold on to hope I think Yes we hold on to hope I have zero hope that he go to in 2026 so you know push everything out a little bit okay so with that we have three tracks here right the consensus layer the data layer of

layer Uh where do we want to start going through this? >> Um well, so we just talked about Amsterdam. Let's talk a little bit about Heyers uh which >> Sure. Um I think that on the straw map, and this is obviously not guaranteed, but the headliner would be fossil. Yep. What is fossil? What is fossil? Fossil is um inclusionless is what we've previously spoken about them as or um and it's basically a censorship resistance mechanism for Ethereum.

FOCIL

Right. So, when we think about attesters, and we have some proposers, which are via attesters as well, just rarely, you know, and and we have builders, which is external, and with EPBS remains external. So, the people building the blocks are external. Um what does fossil do? Does it force them to include uh transactions on and who decides what to force if there is a forcing mechanism? Uh so, yeah. It It The idea is that in a world where we've enshrined the proposer-builder separation, and we're sort of just saying that local building might not be as popular, or it might not be possible in the future, we need a

mechanism that says that someone will continue to force neutrality because if you centralize all of the building with a few builders, they can choose which transactions to include and which transactions to exclude, and that sort of damages the neutrality or the censorship resistance of Ethereum, where we want it to be this utility that is usable by anybody um and for any reason. So, fossil, from my understanding, adds a duty that is sort of uh deciding on on certain transactions that must be included by the next builder, by the next proposer.

Right. And I'm assuming there's going to be a committee as always in in Ethereum randomly chosen from all the testers or something along those lines. Yeah, I mean that sounds like a safe assumption. I haven't looked too deeply into the actual mechanisms that they're planning to use for it. Um I just know that when you're testing to a block, one of the things that you're validating is whether or not it included the transactions that it must have included. Okay. Um now there is an exception to this, right? Like if the block is full, then you need not put the things from the from the inclusion list in.

That sounds like a reasonable exception. I don't know [clears throat] I I think I heard that, yes. So um in that way builders could still censor, but it gets increasingly expensive because if they make every block entirely full, then uh gas costs the base gas cost goes up and up and on up up and up, right? Because the the the assumption in Ethereum for gas cost is that on average um blocks are half full. Right. And >> That's the target, yeah. We are also increasing the capacity of blocks regularly. I think um one of the things that came out of the Norway Svalbard interrupt session was a gas target of 200 million, which is a substantial increase from where we are right now.

Scaling, Local Block Building

It is a substantial increase. So we're at 60 million now, and a year ago we were at, I believe, 30 million. That sounds right. Um so we've already doubled it. Now we're going to go to 200 million. I know that this is still a conservative target. Could easily do 300 or even 600. but 200 is the conservative target to to do right now. This ties into Okay, so gas limit goes up and up and up. Um is that what eventually ends local block building? Or is there some other pressure?

Um I I think that it certainly doesn't help. I mean, the the amount of gas that you can spend in a in a specific block dictates how many transactions or how complex the transactions you can include are. And when you're building the block, you need to sort of apply all of those transactions in an optimistic way to determine if they're going to be included or not. Because if you want them to pay you the the the tips and and and fees and stuff, you want to pick transactions that that actually like work, right? Um, and I think that it will hurt local block building a little bit, but I don't think it's going

to be the thing that ultimately kills it, honestly. Okay. So, um let's say we're in the far future, our gas limit is now 24 gig. Um, can our current knock potatoes still re-execute the block within the time they have to build it? Um, I mean, that's in the far future, I I think this the the gas limit being that high certainly does present a impassable barrier. Right. So, this is what Ethereum is getting ready for now, right? Laying the groundwork to get that gas limit that high because the very aggressive framing I had seen, again, this is not as we've seen now in in Norway, you know, they're

Gigagas Scaling

being a little bit more conservative, but the aggressive framing I had seen was triple it every year. 300 million past Amsterdam, now we actually get 200 million, 900 million the year after, 2.7 gig the year after, 8.1 gig the year after, 24 gig the year after. So, you know, it it would I don't expect that to actually be followed because it's so aggressive. But at some point we're getting to gig gas and beyond for Ethereum layer one. Yeah, and I think one of the things that we should remember is that we are getting some efficiencies back. Um Mhm. the the [clears throat] effect building. So, I

mean, in EPBS, you typically have >> EPBS helps, yeah. to build the block, so you can have a higher gas limit, which is why we're >> hitting 200. Absolutely. So, um Eventually, we do run into the ceiling. Eventually, we do. So, you know, we had cleverly not mentioned this during the Amsterdam discussion, 200 million gas after Amsterdam, our current knox is still perfectly fine to re-execute with that limit that this is not going to be an issue. and then in Hegota, maybe for sale to force inclusion so that as Ethereum motors towards a future where local block building is just not in the reach of most attestors

anymore. we can still have decentralized censorship resistance. That's the idea, right? Yeah, so I mean, even if we we increase the gas limit so high that you need a supercomputer to build a block, and there's only three or four such supercomputers around the world, um we can make sure that they're including transactions that they otherwise would maybe decide not to include for jurisdictional reasons or stuff like that. Okay. So, Ethereum is becoming a data center chain like Solana, but also not.

It's also not. It's also not is important. It's very important, yes. >> Yeah. Um Okay, and I see Go ahead. I was just going to say, I think the the neutrality of of building is important, and and that's why we have fossil, right? So, if without fossil, I don't think that this would be a trade-off that we would make. Right, so which is why there's so much appetite for Fossil. Now, should probably also say um let me see at forecast. Actually, I'm curious whether Fossil is at this point already scheduled for inclusion.

It indeed is. Yes. Yes, it is. So, this is this shows you how much appetite there is to get this in, right? Um having the headliners for Hegota already lined up when Glasodem hasn't shipped is unusual. Previously, the idea was that you know, just before a hard fork ships, the headliners are final. There is no execution layer headliner yet for Hegota, but Fossil is already headlined. Yeah, and and also now noticing that uh frame transactions are CFI'd for Hegota as well, which is uh I think a good segue into talking a

Post Quantum

little bit about about post-quantum. Post-quantum. Yeah. So, do you want to explain uh what the threat is here? Sure, I can. Um it is a largely theoretical, yet at some point um urgently practical threat, uh which is that all of our signatures, and that's from the ones viewers probably care most about, which is not the staking stuff. It's the execution layer, where your you know, ETH and whatever tokens you have sit. Um that's all secured by public private key uh cryptography, and it is the nature of this

cryptography, the the specific algorithms chosen, that they could become vulnerable to what's known as quantum computing. Um the timeline for this keeps shifting. I think now we have Now, Google just had a paper out earlier this year. Um Justin Drake is saying he gives a quantum event by 2030 a 10% likelihood, which is too high for comfort, right? Um, you may have seen stuff like, "Oh my god, the world is ending by 2027. All Um, all addresses will be owned and uh, Bitcoin will go to zero and so will Ethereum. Um, that's maybe a little

breathless. Yeah, I mean, I think that uh, it's right to plan ahead for this. Like, we're the the strong map exists largely to to explain how we'll reach a post-quantum world safely and still make improvements to Ethereum along the way. Um, >> Mhm. but I don't think that the world is going to end. I think it'll be a little rough. It'll be a transition period. It's going to be a little rough where we figure out where all of the vulnerabilities are because we can plan to fix vulnerabilities that we know about and I'm not talking about Ethereum specifically um, Right.

>> right now, but there are obviously decades of software that have been developed that are part of our everyday lives that probably rely on some form of cryptography that will be vulnerable to quantum computers. Absolutely. Yes, and that includes um, every connection you make on the internet to uh, any website whatsoever. Yeah. So, um, do I need an all new wallet? What What is the plan here?

Key Vulnerability

Um, you certainly need new keys and I the explanation as to why your current set of keys aren't any use in a in a post-quantum world, but a new set of keys will be useful is very technical and very full of confusing math and uh physics also, which is is extra annoying. Um but right now, your keys essentially act as a way for you to prove your identity. A signature with your keys proves that you hold them, that you're the one that has those keys.

And >> because it's um with current computers, it would take longer than the projected lifetime of the universe to crack one of these things or something stupid like that. Yeah, so the the idea is that when you create a signature, anyone else can verify that that signature is correct in, you know, microseconds. But in order to create a false signature, they need billions of years and and they don't have billions of years to do that. With quantum computers, they can sort of take a public key and derive its private key in a much shorter time frame, um one that is practical.

>> potentially. So, that means that you won't be able to prove your identity anymore because somebody else could have observed your public key and then reversed the public key to a private key. >> you sign something, your public key ends up on the chain, right? At that point, it is truly public. So, for Ethereum, yes, the public key is slightly different from the address. The address is actually a truncated hash of your public key. But the >> So, that's safe. That's safe. The hashing, especially with the algorithm that is used on Ethereum, hashing is fairly resilient to quantum computers.

Ephemeral Keys

Um signatures are not. So, as soon as you send a single transaction from your wallet, you're revealing your public key because >> Or sign anything whatsoever and put that signature online. Sign any message and give it to anybody, you're you're revealing your public key. And and that is how you are proving that you were the one that submitted that transaction. So, without that reveal, you can't actually use the chain because we can't prove that you wanted to do what you said you wanted to >> let's just say because we had this happen we had this discussion I think you were involved in in uh Easter egg Discord where someone was extremely paranoid. It was like, "Yeah, yeah, you can tell me that post quantum is going to be here in time, but I don't believe it." So, if I today make myself a new wallet called pqyoric.eth

um by the way, that's not me. Don't send any ETH there. >> And I send all my stuff there and then I don't touch it. I don't sign anything. I don't send a transaction. I send it to the wallet. Is this now safe in the case of a quantum event? Um so, your Ethereum certainly is. And and it will sit in that wallet. Uh and that that is safe. Your tokens I would presume to be safe just because it you would be crazy to accept a signature from a different wallet, but the it's technically different with tokens because they don't actually uh reside in a wallet in the way that Ethereum does. I mean, Ethereum also doesn't really reside anywhere, but um

with tokens it's centralized. Contracts are centralized. >> this level of Sorry. Sorry. Sorry. I I just cuz I would say tokens they're probably safe. It's It's fine. I think we can leave it probably. Right. But also, if I want this level of security, now I can't touch this stuff anymore. I can't even sell it. You know, the moment I sell any of it it's all over. Right. So, the the way that it works after you've sent them to this empty or this wallet with no history, we'll call it a wallet with no history. The way that it works is that every time you want to do anything, you need to make a new wallet with no history.

And then in a single transaction ideally, but not necessarily, you need to do whatever it is that you're trying to do. So, swap your tokens, sell your ETH, whatever, and simultaneously transfer the full balance of your current empty history wallet to a new empty history wallet. And that's the only way you can preserve this level of security. This is obviously not something most people will do. So, if you're not don't have that level of paranoia and you're like, I trust that the um that the current efforts to become post-quantum secure by sometime 2029, 30, whatever it is, will be sufficient for me personally.

What is the plan? Well, I I before we move on, I just want to say quickly that the conversation that happened in the E sacred Discord was around withdrawal addresses for staked and validators, and I think that it makes a lot more sense in that scenario to use empty wallet, a wallet with no history. But, I will say that there is also a risk involved, and I I I won't recommend that people actually do it just because you should use it like a test transaction to confirm that you do have custody of the keys. >> And the moment you do that But, the moment you do that, you're exposing your public key. Yeah, exactly. The reason that I I'm not this paranoid is that the attack vectors for quantum computers on the blockchain

won't target staking wallets like this first, right? Like the the if I wanted to make a ton of money because I have a magic quantum computer in my apartment, and I can reverse a public key to a private key, I'm going to look at the execution layer for a whale. I'm going to find a huge amount of ETH. I'm going to short ETH, and then I'm going to sell it on the market, crash the price, cash out my short. Yes, and also I think we should probably say the first quantum event isn't going to be the magic quantum computer in your in your apartment or in some universities physics department. It is going to be a nation state.

>> And I don't know what we think the cost is going to be to break anything, but I'm assuming high. Right. >> At least initially. I don't think they're going to come for your staked ETH for a while. I think um you know, the first computers occupied warehouses. They were huge. And the first quantum computers are also very large and very expensive to operate. And occupy warehouses with all their power and cooling, I believe, at this point. So, they're probably not going to target you specifically, but it is still a risk to the ecosystem.

Um and and we're getting slightly off topic here, but we can talk now about how getting a new key protects you. Sure. Let's do it. Okay. So, in a post-quantum world, there are certain algorithms that are not vulnerable to quantum computers. Um they're really interesting, and I highly recommend you do do some research on them just because they're really but I'm not going to go into how they work because they are really cool. >> Sure. Anyway, while it is still possible for you to prove your identity with your quantum vulnerable wallet with you the current signature schemes that you use, you can essentially publish a message that says like, "Oh, this is my new key.

PQ Keys

This is my new public key." And that new public key can belong to an algorithm that is quantum resilient. And once that message has been published, the the beacon chain can essentially enshrine that information for your wallet and say like, "Okay, we're only going to accept signatures from this new key. We're not going to Next time somebody publishes the same message saying this is my new key, we're going to ignore it because it could be a quantum computer that cracks their private key and and and generated the same message, right?" And that's for validators on the consensus layer on particular, right?

This is just in general. I I I think >> Okay. Uh on the consensus layer, we do have BLS signatures which are quantum vulnerable, and we will need to fix that. Um and there's all sorts of contingency plans in place if it doesn't get fixed in enough. On the execution layer, uh this is manifesting much more quickly because again, that's sort of where the attack vector is >> That's where the money is, yeah. Um and on the execution layer, you will also probably need a new key. Now, you had mentioned frame transactions in this context. So, what are those?

Frame Transactions

And how do they help? >> They're so confusing. Um they're similar to account abstraction in that they sort of change who is allowed to spend the money and then account and Ethereum account is the same as a contract or an EOA. It's all the same. But the way that they are designed is to make it so that we can have multiple different post-quantum signature schemes supported by the chain and you can pick one to use or pick multiple to use. So the chain no longer says this is the one canonical encryption scheme.

Yeah, and I think that there's some skepticism around certain algorithms as to whether or not they truly are quantum secure or we just haven't come up with a quantum algorithm to crack them yet. And and so >> Okay. we're sort of hedging our bets because as that research evolves, it might make sense to remove certain schemes. Sure. Makes sense. And so high-level that is what frame transactions are. I saw a lot of churn about is this a good idea? Does this close off other avenues of research? So this isn't fully baked yet, right? Which is why it's not scheduled for inclusion yet for Hegota.

Right. And I think it's right to be concerned. It is a pretty big change to how Ethereum works and once we do it, we're sort of hedged in. And it we need to be sure that it's a good idea. So they're taking their time making sure that it's a good idea. I think that's important. Okay. So at Hegota though with this work here where I can say, "Okay, maybe frame transactions make it in and I have you know, the ability to register my new post actually post-quantum registry comes one later for for the for Istar for the for the consensus layer.

I'm still not fully post-quantum, am I? Because all the attestations are still on the old method. Yeah. Am I already post-quantum on the on the execution layer with Hego Tower? Does that need more work? Um so let me look at the straw map real quick. And Hego Tower >> map has ephemeral keys and I star and then post-quantum transactions sometime Well, they say 2029, so really 2031.

>> I see that, yeah. So, they're saying M star for um post-quantum transactions with ephemeral keys and I >> So, ephemeral keys though in 2027, they would already help me, wouldn't they? What does that do? Um you know, I haven't looked at ephemeral keys at all. Okay. So, um I'm going to give my extremely high-level and not nearly as detailed as anything Patches says understanding of ephemeral keys. So, basically once we have frame transactions, we can get freaky, right? Because I can now say this is this can spend from my wallet.

I could say from now on the only thing spending from my wallet is an ephemeral key with I'm actually not sure whether it works that way or I need to move You know what? May maybe I still need to move everything into my proposed wallet that never signed anything, right? My my fresh wallet that we had talked about earlier. But now, if I want to spend from it, I use an ephemeral key. And that ephemeral key is good for one transaction and then it is no longer accepted. So, I don't know whether this does something for my existing wallet, but I think the idea is that if there's a quantum event, everybody hops into a freshly created address that has never

signed anything. Also doesn't sign anything from now on, but just uses ephemeral keys. Which I know as the name suggests, are only good for one transaction. Um and this includes the transaction being rejected. So if for whatever reason the transaction fails, the key is still marked as no longer good for anything. Next time you do a transaction, fresh key. >> Yeah. So I I that's good. I that's a very good explanation. I just read through the abstract on um In 15 seconds as you do.

And I can tell you that the the idea is that every time you submit a transaction, you include the next um the next address that you will be able to sign essentially. So the next signer. Right. But you don't include its public key, you just include the sort of truncated hash of it. Uh which is the ephemeral key. And that means that when you do another transaction, you're including a third address and so on and so forth. So you're just daisy chaining signers. So if I'm daisy chaining that way, I might not even have to move my stuff. I just sign a thing that says from now on, we're doing ephemeral and anything you see from this address from now on is no longer valid. Right. And so the the address that we're talking about is a smart contract wallet and it holds in it

the next signer that it will allow. And when you submit a transaction, you are essentially burning that key, that ephemeral key, but telling the smart contract wallet to update the next address to whatever your next key is. So if I have all my stuff in a hardware wallet like a so also called an externally owned address, an EOA, right? Um or so either in a software wallet like a um a frame or a MetaMask or what have you or a hardware wallet like a Trezor or a Ledger, these are the what we're talking about now, these are smart contract wallets.

So, I still need to create the smart contract wallet, move all my stuff over there, and then start using that. Is that right? Yeah, and I don't remember what happened to that EIP about upgrading the EOAs to smart contracts. >> wallets. I'm I'm lost on that. >> There I I think I I think we have something, yes, where an EOA can delegate to a smart contract either for one transaction or forever, temporarily, I think right now. Yeah. Yeah, I think this this ephemeral key EIP, which is in the distant future still, right? When did When did we say that was coming?

I said I said Yeah, so I I hope that it will be accompanied by a way to upgrade your account without having to change the address just because that really simplifies a lot of things. >> Right. But I don't know for sure. Yeah, so that's important to say as well. With ephemeral keys, while these all have a separate address, that's the from address, that's the signing for my for my stuff address, the destination address remains the same. Right? So, if that doesn't change.

>> Well, I think the interesting thing is that the You know, actually So, here's the problem, right? Is if I deploy a smart contract to my >> If I deploy a smart contract to my hardware wallet's address, I still have the private key for that. So, I think there was an EIP that basically reverted transactions if there was contract code that that wasn't executed at that address, and I think we'd need that first. >> So, to be determined, but basically, let's put it this way, there is a plan.

There is a plan to be able to survive a quantum event even if we're still using vulnerable signatures. And this kind of banks on the idea that in the time it takes for your transaction, so fossil comes in here as well. In the time it takes for your transaction to be publicly visible, if it's going through the men pool, and be included, which fossil makes faster, um a quantum computer isn't going to break this. Certainly, you know, uh one it probably won't even be possible.

Um I think some of the really aggressive work right now says maybe within 5 minutes of seeing a signature it could be broken and it would be included and no longer valid for another transaction before then. and then the other part of course is what's the cost? How much are you transacting that actually you know, getting a 5-minute window to um replace your transaction becomes viable. But the idea is that even with a 5-minute window, if it gets that low, um your transaction would be in and then whatever what was broken is no longer relevant.

Yeah, and I think that, you know, with with gas limits going up, we're including more transactions, so the amount of traffic that's on the blockchain right now Right, that's that's kind of the plan. So I think high-level we can say there are things in motion to be able to survive a quant quantum event even before we have fully post-quantum signatures everywhere, which comes later. Um L-star for post-quantum attestations, um M-star for post-quantum sampling of the data layer and post-quantum transactions on the execution layer.

If the current road map holds. Post-quantum attestations is a big one um because the way that the the beacon chain is designed right now is based around the fact that BLS signatures can be aggregated, which basically means that you can take a a million validators like we have and um take all of the signatures that they they have for the same objects for the same attestation and just combine them into one signature and then you can still determine [clears throat] that all of those validators contributed to that signature even though it's tiny it's like it's this really cool piece of math um and we need to find a post-quantum algorithm that supports that kind of aggregation uh and we don't Right. Okay, I think

I I had seen something about that by the way which said we're not going to find one so we're not going to aggregate signatures we're going to prove signatures then we're going to aggregate proofs because proofs are wonderfully aggregatable. >> [sighs] >> Yes, that's >> the last thing I heard about that. That sounds really cool and I know nothing about it but Right. And and that was Yes, indeed. So that's that's a this you know just a side remark here we we have all this thing about you know Ethereum should become less complex but sometimes it sounds like we're doing stupid amounts of math and complexity.

This is necessary complexity. There's we we there's no way out of this this needs to be done. A lot of this feels very urgent even. Right. Yes, and it is being worked on right? So this is this is top of mind um for multiple Ethereum researchers. There is no one in Ethereum who says quantum isn't well I say no one of course there is someone somewhere but uh I have not heard prominent voices saying quantum isn't real and we're we're chasing a goose. Um this is being taken extremely seriously with the idea that if Ethereum becomes post-quantum secure sometime in the early 2030 time frame and it turns out we didn't need it

that is still vastly better than you would be getting than not having it. Yeah. And I think also if we spend too much time talking about it, we won't get to fast finality, so So, let's get to fast finality. Um I do want to mention one other thing coming in Hegota briefly, that's optional proofs. So, with Hegota, it will be possible for someone to rationally ditch the execution layer client, run just the consensus layer client, and verify a proof.

Um it will still be optional. It'll still be cutting and bleeding edge, but it'll be from a from a rewards perspective rational to do that then is the idea. We'll see whether that actually happens. Right. And I think we talked about it last time. The mechanism is just there's a proof that a certain block was applied successfully, and you validate that proof much faster >> Which takes milliseconds. Yep. >> than it's generated. Exactly. And so, you don't need the you know, you don't need the large hard drive anymore. You don't need to run an execution layer client at all. Yeah, so for validators, it's great. Um if you want to run a node that you're going to query for execution state, you still

need the execution client. >> Obviously not. Yeah, but it's for validators only. Okay, let's get to fast finality and fast slots, and the the the thing we teased in the beginning, which was the attester cap, which flows from that. Right. So, um and we talked just now about aggregated attestations and in-signature aggregation. So, um how many how many validators are there today, do you think? Uh 900,000-ish. consolidation is working, but slowly. We were over a million at the peak, if I remember correctly. We were, yes, correct. Just over a million. That's and there's 32 slots per epoch, so 1/32 1/32 of the validators

Fast Finality, Attestor Cap

>> 1/32, yes. validators um attesting every slot essentially. So, Right. that's you know, tens of thousands if I'm doing the math right here. Um and if they if they have all the same attestation, that's tens of thousands of signatures that you have to aggregate into a single signature. And that takes time. >> So, time is the enemy in fast finality is is my understanding.

Right. And so, with fast finality and um there was going to be a paper ready by now as to pause to fast finality, but it's not. So, maybe we can talk about that during SNT8. Um I see here on the on the straw map and the stake map, there's decoupled consensus in I-star, which isn't yet data, just lays groundwork. Then there's four slot rounds in J-star. So, that means now I would attest every four slots, not every 32 slots.

And that's where the pressure comes in, right? >> Right. And and just as like a quick refresher, finality is when 2/3 of the stake has to be burned in order for us to revert a block. >> Right. right now with 32 slots per epoch, epochs justify uh when I think you get to 2/3 and then they finalize when the next epoch justifies because we have one finality, one epoch finality.

>> Um which means that in perfect conditions, finality is about two epochs behind. And here now we're talking in J-star, four slot rounds then K-star run one round finality. So within four slots and also six second slots. So within potentially 24 seconds Ethereum would be final. And it's not doing that with 900,000 validators. Right. So the tens of thousands of attestations that you have to aggregate, currently that's because we're dividing by 32. When we're dividing by four, that becomes hundreds of thousands.

>> [clears throat] >> when we're cutting the slot time in half, that doesn't help. That does not help. So our current attesting wonderfully long tail decentralized way would not work anymore with this. So the researchers want this down to 128,000 validators total. Now we have type two validators which can hold up to 2048 ETH each. All staked ETH can fit in like I think less than 15,000 validators total. In theory, in practice that's not happening.

I think we're on track to get down to maybe 500,000 validators through consolidation eventually. So what's the proposal? How do we get to 128,000? Well, if you want to keep as much of the stake in the in the chain as you as you can while getting to 128,000, the naive approach, the simplest approach, the first thing that we think of is to just get rid of the smallest validators first. Okay, by just balance. Right. So if you have 32 ETH staked, you're a 0x01 validator. Or worse, you're a 0x01 validator who's been very negligent and you're down to 31 ETH because you've been offline and leaking

or something like that. Getting rid of you means that we're getting rid of one whole validator for the least amount of ETH. And and that's beneficial to the network because the amount of ETH staked correlates to the financial security of the chain. So, if we can get rid of the smallest validators first, we do that. We we we do it without damaging financial security or dynamic damaging financial security the least. But, we're damaging the long tail the most, aren't we? Right. So, the problem is that the people with 31, 32 ETH validators tend to be solo stakers.

more so than institutions because institutions would obviously just switch to 0x02, do consolidations, have fewer keys to manage. Hopefully, we hadn't seen a lot of them do it. It would be nice if more of them did it. I personally have worked with some large node operators in the past and I helped one of them switch from 0x01 to 0x02 and it was so nice. It was so nice to only have a handful of keys instead of hundreds. >> Absolutely. Um but the problem is that if you're a home staker, say you had, you know, 34 ETH at Genesis and you decided to become a staker and you staked 32 of your ETH uh and and you have two your ETH left on the execution layer uh you're really helping

decentralization. You're like a solid part of Ethereum's backbone, but you're also the one who's most vulnerable to being ejected if we have a validator cap. And I I think now is an important time to say that this is all distant future stuff and there's no need to panic. Right. Yes, but talking from J star at the earliest, so 2028 sometime. And there's also, I should say, significant pushback from researchers who say this this very simple method of just kicking stake out, we don't like that because that hurts the long tail so much, right?

obviously, there is a way that a solo staker could, if this comes to pass, protect themselves. Um change your validator to type two and top it up by one ETH. Now you're at 33 ETH and you're no longer at the vulnerable long tail. Yes, and and there's some game theory involved there where you're hoping that everyone else doesn't do the same thing and there's some protocols that can't literally can't do that like um They can't, right? Like if you stake with Lido CSM, you're probably using 0x01 validators. If you stake with Rocket Pool, you're using 0x01 validators.

Uh there's no way for those to be upgraded. You have to exit them and reenter if you want 0x02 validators and then you would have to solo stake because those protocols don't support 0x02 yet. CSM I think does. Rocket Pool doesn't yet and NodeSet said they don't have the money to ever. So, there we are. Oh, interesting. Yeah, it's it's expensive to to change a protocol that that exists on chain that makes the assumption that the max effective >> all of your smart contracts need to be changed and audited again.

Yeah, and audits are very expensive. Yes, they are. So, if you do want if you are a solo staker and you have one validator and you are worried about this even though I'm telling you not to worry yet, um you can upgrade to a 0x02 credential. You'll start compounding instead of getting regular withdrawals and then you can top up your validator so that you're at, you know, 33 ETH is fine. 32.5 effective balance might also be fine. I don't really know where the >> Effective balances are integers. Yes, you're right. So, 33 ETH is probably better. Um I assume that when we do start kicking out if we do start kicking out people, we won't use the effective balance as the as the watermark. We'll hopefully

use the true balance of the validator, but I don't really know because this is all new. >> I I don't know what the idea is and um Yeah, I So, there there is robust debate about this which is a polite way of saying people shouting at the top of their lungs saying that this is wrong and and will hurt the long tail and we shouldn't do it and we should be more complex. So, there are other ideas such as orbit where, you know, you still have your 128,000 attester cap that doesn't mean that the attester pool is only 128,000. We're just rotating people in and out um to only attest 128,000 per you know, per force slot round

and then we're rotating other people back in. Uh this is orbit is considerably more complex than just kicking people out of the protocol. It is. But it might also hurt the long tail a lot less. Right. And I I think that sort of the the problem that we stated is that you have to attest too frequently and that aggregating those attestations becomes very expensive and I think your natural inclination might be to say, "Well, why don't I just attest less frequently?" And that's sort of what orbit does. >> but the problem with that is that your attestation is your stake. You're saying I'm voting for the validity of this block and that is what leads to finality and because you're you're saying that my 32 ether backing this block. So, if you

start cutting down on the number of people who attest to each slot, you cut down on the amount of financial stake that's backing those slots finality and then, you know, you have to account for that somehow, which is what makes orbit more complex. This is a very good point. Okay, so uh things remain extremely interesting and I would say just keep tuning into this extremely nerdy talk to find out where it goes next. We will keep as abreast as we can. Of course, as we said, this is not until 2028 at the earliest.

Closing

So, we're not going to know what it looks like for at least another 2 years. Yeah, I think um before our next talk, I'm going to definitely read up on the decoupled consensus plans because those are very complicated and very interesting. Yep, they are. So, basically, in a nutshell, right now, we have two clocks that have to run in lockstep and that is creating the block and deciding which block is next, so the consensus. And decoupled consensus breaks that apart. There is the, you know, the the heartbeat that says we're creating a block and there's the heartbeat that says, "And we say that we came to consensus on the chain." And the

two are decoupled from each other, which creates all kinds of freedom for the researchers to do things like 6-second slots without breaking the world. Yeah, and I'm excited to talk about that next time. Sure, absolutely. Do we have any last thoughts here other than we're rambling and we're al- already an hour in and we didn't want to be in Do we not Oregon? [laughter] We have to do these more frequently, we'll have less to talk about. Or maybe they'll just be >> There you go. prices next time.

>> All right. Well, thank you, Patches. It was a pleasure. I'll see you next >> That concludes Serkingat Talk uh seven. And then uh we'll we'll have more of our thoughts on whatever happened at that point with the next one in, who knows, a couple months probably.