ePBS, BAL, zkEVM, FOCIL, Glamsterdam, EthCC - Staking Nerd Talk - 6

Transcript

Intro

Hi, this is Staking Nerd Talk 6. I'm Yuro and with me I have >> Hi, I'm Patches. >> Hello Patches. So, uh, new face on staking nerd talk. Thanks for doing this with us with the staker group. Super happy to be here. >> And what happened to Remy? >> Um I mean, you tell me. I think uh I know a little bit, but it's really interesting uh stuff that he's doing right now and and why he can't be here.

So, >> yeah. So, Remy has decided that he's going to try having a life. Um he's been involved with a search and rescue group all along. He's going to focus more on that and on nature in general and life and a lot less on Ethereum. And that also means he's uh not completely stopping what he does with the East Staker, but dialing it back severely. Um all the infrastructure work he's doing for us, probably some of the coding work and definitely this. So really good for him and it's amazing >> and it's good for me too cuz it means that I have the opportunity to be here.

Right. So the topics we're covering today we are um going to lean into what's coming with Glamsterdam the next hard fork and what that means for stakers. Um main topic I think is going to be EPBS and try and propose a builder separation. Um, briefly BAL the access lists and what that means for performance of a sticking node. Um, I'd love to you had mentioned patches um that we could touch on ZKVM and and proof verification. I think that fits into Glamsterdam as well. Um, we want to talk briefly about the ETH staker stage

at ETHCC that is coming up in a week and a half, two weeks, something like that. And then if we have time, um, we're going to touch on two EIPs in glamps that um, that are kind of interesting but aren't headliners. >> Sounds great. So don't we why don't we start with enshrined proposal builder separation. Um do you know give us highle overview patches of what is changing for stakers there? What do they need to pay attention to? What does this do for them?

ePBS

>> Sure. I think um it might help if we talk a little bit about the current state of proposer builder separation and and MV boost which is the implementation of it that most people use. Um, >> essentially back in the day before the merge when Ethereum was still a proofof work blockchain, building a block could be profitable because you had an opportunity to organize the transactions that you put into that block in a way that led to some sort of opportunities to profit. And back then we called it minor extractable value or mind extractable value or something like that. Um that definition has

transitioned into maximum attractable value as we've gone away from mining. >> Um and the ability to organize those transactions has shifted from from being a miner's responsibility to a a staker's responsibility in proof of stake. Um but actually finding those profit opportunities is a very challenging problem. uh it's very complicated and it's very specialized and and it requires some pretty beefy hardware. So proposer builder separation up to this point has been a sort of external service to your validator client. So, if you're a homestaker, you probably run MEV boost. And when it's your turn to propose a block, you'll essentially have

your validator sign what's called a blinded block where you've asked a relay, a relay, um, and I may be a relay like flashbots to give you just the header of a block which contains a hash of the block body. So, you don't actually know what's inside the block. you just sign the header and you give that back to the relay to prove that you've signed it centrally which makes it safe for them to reveal the contents of the block um because they know that it'll be included when your block is proposed. Um if you propose a different block and you sort of like don't propose the block that the relay provides you even though you signed it, you can get slashed. So there's some protection from the relay side that you're not going to

essentially decipher what it was that they did to profit and they share a large portion generally of those profits with the validator, >> right? >> Okay. So that's that's the current state of the world. >> That's the current state. Couple questions about the current state. So you mentioned MV boost. I do have to do a quick shout out as well. The second side car that people might use is commit boost. Um, how much time does somebody have to re-execute the block once it's been unblinded and then say it's correct and attest to that.

>> So, right now you have 4 seconds. Um the the block is due at the beginning of the slot and then over the next 4 seconds you are essentially running the execution payload of the block against your local execution client as an atttor and you're saying whether or not it's valid and you submit a decision to the network and it gets aggregated into the next block if you do it in a timely fashion. >> Right. And you know briefly mentioned here we'll get to that later as well. People do play p timing games, so you might not actually have the full 4 seconds because you don't see the block right away. Do you know how many blocks are currently being built by the

centralized builders and how many are being built locally roughly? >> Um I I actually don't remember, but I understand that a large portion of blocks are published by uh relays and not directly by um beacon clients that are are participating in the network. So, I think there aren't that many builders and it's safe to say that like the largest builder probably has doubledigit percentage of the blocks that get published. I think that's right. Um, I have a number in mind of like 90% builder and 10% local. Sounds directionally correct. It might not be the exact number. And that we have something like three major builders and

then maybe a couple aside from that. So it's it's fairly centralized from a building perspective but still very decentralized for attestations. So now how does this change with enshrined proposal builder separation? So in EPVS when it's your turn to propose instead of asking for a blinded block from a relay you ask for a bid from a builder and you can ask multiple builders for bids and sort of pick the highest one. Um, and that bid is a signed message from a builder that says that they will publish an execution payload with a certain hash, meaning that like they have already figured out

what contents they want, what transactions they want to include, and they'll pay you a certain amount to do it. Um, and in enshrined PBS, when you publish that bid, it's binding. So, this works out a little bit better for validators because without the enshrinement, you're always trusting that the builder will honor their side of the agreement to share their profits with you. And now that you're just signing a bid and publishing a bid, you're essentially accepting the bid formally on on the beacon chain and the builder is forced to pay you after you've accepted the bid, even if they fail to publish the block.

>> Right. Um, there's a nuance there that I'm still struggling with, which is that bids can come through a peer-to-peer network. And I know that is a trustless payment method, but I don't know how that works when you directly connect to a builder via the API because that's faster, right? You don't have to wait for peer-to-peer. And peerto-peer is considered a fallback here, a livveness fallback, whether that's a trusted bid or a trustless bid, you know. >> Yeah, I actually meant to do a bit more research into this last night.

Unfortunately, I had an internet outage. >> It's all good. It's all good. We're all learning as we go. We we'll have a ECC part later and I'll mention a couple talks about that at the ESC stage. Um, okay. So, that's the change where we don't need the relay anymore. So, the validator doesn't have to trust the relay and the builder doesn't have to trust the relay. That seems like a good um that's probably not enough to do this big of a lift because we're changing a lot in the underlying consensus layer protocol. Um what else is changing?

>> So the structure of the slot is changing substantially. Um and and part of that is due to the observation that we're not actually using the full 12 seconds in the most optimal way. There's sort of a lot of free time based on when our expectations are set that things will arrive. Um and so I I jotted down the changes but currently slots are basically split into three sections. Uh at the beginning of the slot the block has been proposed and validators are validating it. Third of the way through the slot. So at the 4se secondond mark um at testations are being published and that's basically just each validator saying that this block is valid or not

ePBS Slot Structure

as the case may be. And then twothirds of the way through the slot, the aggregation window starts. And that's when the attestations all get combined. It's sort of a form of compression that makes it so that the full set of attestations from all of the validators, which there's, you know, over a million I think can fit inside a single block. Uh that's the current structure in EP. >> At that point, you'd also start so once the the block has been published, you'd also start building the next block, right? >> Yeah. So in the last third of a slot you can start building the next slot. You do want to include the aggregated attestations but usually by that point you have the majority of attestations

and so there's not that much to do. So you do have uh 4 seconds to build the the next block and and we can talk a little bit about timing games really quickly where at that 4 second window at the end of the slot is when you're supposed to be building but because MEV is easier to extract when you have more transactions. It's profitable sometimes to wait a little bit longer to get more transactions into the mem pool or to search through them and try and order them in more profitable ways. So, it's possible that you might actually propose the next block instead of at the zero second mark of the slot, like one to two seconds into the slot.

>> Yeah. And we've seen a lot of that. And I know there's some concern that this will cause issues um as we ramp up um gas limits and and makes just makes it harder for testers, right? It's really good for proposers and builders, but it makes it very hard for testers to be timely. right? The sort sort of the longer the attesters have with the block, the easier it is for them to validate the block within the time that that they have. So, um in order to attest to a block, you need to be certain of its validity, which means that you actually have to re-execute all of the transactions against your local execution client and and like make sure

that the outcome of the block is as described. >> Yeah. So, that's the current block structure. What does the new block structure look like? A slot structure, I should say. Sorry. >> In Glam Amsterdam, um, instead of even thirds, there's sort of a handful of of checkpoints throughout the slot that are interesting or relevant. The block is still proposed at the zero slot, at the zero second in the slot, but the block no longer contains an execution payload. It just contains that signed bid that we were talking about. Um, >> and so once that block is proposed, there's a 3-second point instead of a 4-se secondond point where attestations

start to be published. But these attestations don't imply that the execution payload is valid. They just imply that the beacon block is valid. >> Mhm. um at the six-cond point. So halfway through the slot, aggregations begin to to happen. And that point is also at which the the builder has to reveal the block that that corresponds reveal the execution block that corresponds to the beacon block. Um >> four seconds, I think. Yeah. And at six seconds, the timeliness has to be in.

Yeah, that's right. Um, at 6 seconds the timeliness, so there's a a new duty that I think there's 512 validators in a given slot who essentially say whether or not the builder revealed the execution payload in a timely fashion. Um, and that's important because >> when we get to the next slot, you need to say whether each attistation essentially needs to say whether or not the previous slot had an execution payload in it. And and if the builder wanted to wait, if we didn't have this timeliness um at stationation, the builder could essentially wait until close to the end of the slot. And that would create a sort of like

uncertainty among the validators as to whether or not they actually revealed the execution layer side. So there's uh timeliness stuff that's due um at the 9-second point. I think >> I think time is 6 seconds by 9 seconds. We need to have verified the the payload. >> Uh yeah, that sounds right. So at the 9-second point, you have to have verified both the beacon block and the execution block. Um, >> and that is substantially longer than you have right now. Uh, where all of that verification happens in 4 seconds.

The beacon payload verification is the bulk of that though. You have the full 9 seconds for for beacon payload verification. um verifying the actual execution payload you have less because it was revealed later in the slot, >> Okay. So, we're we're decoupling the beacon block from the execution payload. Um I think there's two ways we can go here now in this discussion. One is okay why are we doing that that extra complexity or the second one might be maybe we take that first well what does that mean for validators home validators in particular

ePBS Bandwidth

how does that change their bandwidth requirement their resource requirements more generally um how does that change the configuration >> um so when home val home validators have multiple different roles and I think as a as an atttor your bandwidth requirements don't really change that much. Um, and and that's because when you receive the beacon block, you're just getting a a small portion of the previous bandwidth requirement, but you get the rest of it later when you have to also receive the execution payload.

>> Uh, right >> as a proposer, it depends on whether you've been using me boost or not. If you're building blocks naively, um, your bandwidth requirements have gone up since the BO fork started, since Fusaka, right? So now you have to publish all these blobs. Uh, the difference is that if you're building a block locally in Glamsterdam, you still have to publish those blobs, but you publish them at a later point in the slot. So I think you you I'm not sure if you have more time to do it honestly because of the the attestation window is so much longer but the sort of upload

bandwidth that's required is spread out across the slot instead of all at once. >> Yeah, that's my understanding from what I remember from boat is that you do have more time to get this in. Yeah, I think >> because the attitation window is so much longer, it would make sense that you actually have a lower bandwidth requirement to publish the execution payload. Um, if you're using MEV boost, you never had to do that in the first place. I think you just sign the block header and you publish that. Um, and then the relay itself can publish this the the full block to the peer-to-peer network, but I'm pretty sure that most clients download it and publish it anyway. So your bandagements were still there with a slight wrinkle here that um

several valer clients default to a builder boost a proposal boost of 10%. So unless the remote builder pays 10% more than local, they'll build local. Um >> yeah, and and being able to build local is is good for a lot of reasons. I think um one of the main ones is censorship resistance because in PBS the builder set is so centralized. They could be coerced to exclude certain transactions from blocks. Um and we then rely on people who build blocks locally to include those blocks since they or include those transactions in their blocks since they get naively ordered into the block. And I think we'll touch

on um Fossil at some point probably, but that is one of the things that will mitigate will that centralization concern. >> Yeah. So we have a bit more time to re-execute the block. Am I right in thinking that that removes CPU pressure from home stakers when they're re-executing? They have a bit more time and they can more easily absorb gas limit increases. >> Yeah. And I think it's you get nine seconds now. And that's because the payload was revealed halfway through the first slot. And you don't have to publish an access station in the next slot until um the 3second mark in the subsequent slot. So that's 6 seconds in the current

slot plus 3 seconds in the next slot. >> Um >> okay. >> I'm still completely unclear about this by the way. I know we've been discussing this and I was just going to say to anyone watching this, >> you know, um it's okay. We don't I certainly don't feel like I need to fully understand this yet. Um we'll get there. So my understanding differs from yours patches. We had discussed that. I think it I I think 4 second for reveal, 6 second for timeliness, 9 seconds to say I've verified it. Here's my attestation to the to the payload. And then the next 3 seconds we start on the new um on the new slot. So we're already

again at 0 seconds. But whatever it is, whether I have 5 seconds to verify this or 9 seconds to verify it, we get more time. >> Yeah. And and that means that you can potentially run with the current gas limit, you potentially run a validator on a less powerful machine. Um, but ultimately the goal is not to reduce the hardware requirements, it's to increase the gas limit. >> Exactly. Although we'll likely get to both. Um, so maybe this is time to briefly touch on the other headliner.

BAL

Um, access lists. >> Yeah, these are really cool. Um right now essentially when you are reprocessing a block you go through it transaction by transaction and you run each transaction in the EVM in your execution client uh one at a time and computers are built one at a time if I have a 16 core thread ripper or whatever I'm using one one core. >> You're using probably more than one core just not for this particular workflow.

So this particular workflow is a sequential workflow. It's not parallelizable as it is today. Um and with the short caveat there because I know they'll say it. Baso is already doing some optimistic paralization even before balance. So it's sort of paralyzable but not really well. >> Yeah. I think a lot of the times in software uh we talk about the worst case runtime and the worst case runtime for a block right now is that it has to be executed fully in sequence because each transaction that you include changes the input to the subsequent transaction in the block. Um, and it might be possible to do some sort of optimistic

parallelization that would mirror, if you're really a computer nerd, that would mirror something like pipelining in the CPU where you optimistically start executing the next command in the program before you finish executing the one you're currently executing. And occasionally, you actually have to drop your pipeline and and and then re-execute >> the first one. Yeah. Um, and that's a really cool optimization, but we can do better because we want the worst case runtime to be predictable essentially and and that helps us optimize things and speed things up, increase the gas limit. So the proposal for BLS which are block level access lists is essentially that when a block

is published it comes with a sort of digest of what addresses will be modified by all of the transactions and you can use that to figure out which transactions are mutually exclusive and which ones can be parallelized. >> Right? So let's say that you know there is a transaction that has your download of ETH and one that has patches of ETH then those two could be done in parallel. They have nothing to do with each other. >> Yeah. And I think the thing that's important to understand about that is that it doesn't actually matter what order those two transactions are executed in. You can execute either one before the other and the final state

remains the same. If if I send ETH to person A and you send ETH to person B, no matter which one of those things happens first, person A gets the ETH from me and person B gets the E from you, they would be mutually exclusive if I sent ETH to person A and then person A sent ETH to you because now there's a dependency chain, right? So the transaction that I execute has to happen first to increase the balance of person A. Person A then has the ETH to send to you which they may not have had before, >> right? Or if I send something to A and you send something to A, M and then A does a swap, right? That needs to happen in sequence.

>> Yes. Um and a block level access list is a sort of elegant solution that doesn't change the fundamental structure of the block. It just adds a little bit of extra information that tells you that certain transactions can be executed in parallel. So now when you're processing the block instead of having to do everything in series or sort of the worst case is that you have to do everything in series the worst case becomes well defined by the number of transactions in the block level access list that are in fact mutually exclusive.

Right? So now we got more time to do this re-execution and potentially we can make better use of multi-core machines to do that and do it a bit faster. Right? I don't I'm not going to say what the speed up is. I don't actually know. You know, I'm very optimistic in thinking maybe a four core machine can get you a 2x, but it might not be that. It might be a 1.5x, you know. >> Yeah. And we talk about it being faster, which really just means that we can do more in the same amount of time because I think ultimately the goal still would be to raise the gas limits, which means that there are more transactions in each block. So you can do more work in the same amount of time instead of doing the

same amount of work faster. So I'll mention here the um the gas limit increase that had been floated by Justin Drake last year which was very aggressive. It was basically 3x every year. Uh see that as a marketing ploy and not necessarily a hard engineering road map. Yeah. Um but with that we would go to 300 million gas post Glammsterdam just to remind us all at beginning of 25 it was 30 million um then 900 million gas in 27 that still seems quite doable with this structure

zkEVM

on the current homestaking nodes if we have more time we can use a course better then 2.7 gig in 2029 um I think At that point, we're really 28. Sorry, I I I missed my my my uh my count there. Um at that point, we're really kind of pushing the current um architecture even with gas repricings, which will certainly happen as well to make that possible. And then past that, he was even thinking about 8.1 gig, 24.3 gig. to do that we can no longer locally re-execute. Um,

which also would mean that local block building is gone. Now we have mandatory proofs. So that leads us into and and let's say with a huge heaping of salt, right? I'm not saying we're getting to 24 gig gas in Ethereum. I'm also not saying it's impossible. It there is a road map there by 2030ish. Um, so ZKevm improving, what's that and how does it fit into all this road maps talk? >> Yeah, I mean I think this could be an entire episode and it probably will be >> and it will be.

>> Yeah. Um, but the the main idea behind a ZKVM is that it's a ZKVM and the VM that you're running is the EVM. So a ZKVM is basically a virtual machine. It's a model of a computer. Uh, and you can prove that you executed something successfully over certain inputs without actually having to reveal what it is that you've executed essentially. Um >> and that is interesting to us because it means that you can do a state transition on the execution layer and prove that it succeeded and then you can publish that proof and and that process of proving is

very difficult and it requires specialized hardware uh machines with lots of GPUs. It takes them a good number of of seconds to generate the proof. Um, it may involve gas repricings in the future just because certain things are harder to prove than other things. But once you have that proof, you can essentially just publish it alongside a block access list and say I executed an execution payload and it changed these addresses in this way. So it has this the before state and the after state and somebody can take the proof and verify the proof and verifying the proof is is relatively easy. it happens in milliseconds if I understand

correctly or in on the subsecond timeline. Um and once you've verified the proof you know that it is safe to apply the block access list which basically is the state transition. So the block access list tells you what addresses in the EVM have changed in balance and you can just add and subtract those balances or whatever the value changes are. Um, and that means that as a as a staker, you're no longer re-executing every block that gets proposed. Uh, or at least it becomes optional. You you can still do it if you want to, but since it's now optional, if we do raise the gas limit, we might raise it to the

point where commodity hardware is no longer capable of keeping up by reprocessing every block, but is more than capable of keeping up by applying the proofs instead. Right. And that's so that's we'll get to where these talks are. That's the part of the road map, right? The linear Ethereum road map is to have optional ZK proofs to start for a home viator. That might potentially mean you can run um with 16 gig of RAM and a one TBTE drive, no problem, because you don't have an execution layer client anymore. And it may become rational to do this, meaning you still get your full rewards because you have enough time to do this through

EPBS. Um, as soon as after claps done, you know, uh, there's other parts to that which is do we actually have clients that can do it and are people publishing the proofs? So I don't expect this to happen immediately when Lamster goes live but it it might actually become rational to do that still in 26 or in early 27 at some point and I know that Justin has said his vision is that eventually the proofs become mandatory. and Guam I think I hope I'm not misattributing I might be in defcon said listen local block building is dead it just doesn't know it yet. Um, do you

agree with that? Is that where we're going? >> Um, I I think that it's a good direction for us to pursue. I can get into why I'm not super worried about local block building dying and I think we mentioned it briefly earlier because of fossil. Um, but we're already in a place where double digit percent you know 90% of blocks are built by these centralized builders. So >> yeah, >> for the most part, the only reason that the local block building is important still is due to that censorship resistance that um we talked about before. And if we can fix that problem, then I'm not sure that there's a lot of

value in saying that commodity hardware should be able to continue to build blocks. Um, I happen to be very pragmatic and agree, but I'm willing to bet that Mika would disagree. Um, yeah, I I think that there's there's something that's a little bit beautiful about the way that all the participants in the blockchain right now are roughly on equal footing. Um, and that PBS is optional and that you can be a full participant in the blockchain with just like a, you know, $800 setup.

>> Um, although, you know, I haven't checked hardware prices now. It's more like 1,600, but yep. >> Yeah. Everything's getting so expensive. Um, but I I think that if we want to have a really well uh like a a really competitive L1, which means you can do transactions for very cheap fees, like absurdly cheap fees, we we need to find ways to raise the gas limit substantially.

FOCIL

um this is sort of >> ignoring the fact that L2s have have solved this in a different way and and I think >> a lot there are a lot of good reasons for the L1 to be as efficient as possible and to be as scaled as possible. Um and so I I'm on the side of of ZK EVM being a good thing and that we can sort of use other tactics to improve censorship resistance that don't require local block building. Yeah, which does mean we want full sill and h star though before that window closes and we keep pushing it and pushing it and pushing it. It was proposed for glamster then it was

decided too much not quite ready. Let's do it as a headliner in HAR. Um he go I think we're calling it now. Um so I really hope that happens. I I think we need it. I I don't want to see us get this centralized on the block building without having a way to force inclusion. >> Yeah, I agree. And I think um censorship resistance is sort of like core to the ethos of the Ethereum alt one. Um there have been a lot of discussions that have come up in the past around you know the US government and OFAC uh sanctioning certain addresses and and uh the idea that the Ethereum blockchain

needs this credible neutrality which which means that we can't we can't uh litigate who's allowed to participate as as validators uh who's allowed to send transactions and who isn't. Um, yeah, that goes really that like I feel that really strongly about crypto in general is that it's not >> it it's it's unique because of its trustless nature and the fact that there is no central power that gets to dictate who's allowed to participate and how. Um, so I fossil is like a a no-brainer for me. I think it's really important that we get it included.

>> Yeah. And to touch on that as well, right? So I view the block building part of Ethereum here as similar to an ISP. You had mentioned sanctions lists. I think those exist for good reason. Um when you look as who is on the sanctions list, we're talking, you know, traffickers of of humans. We're talking terrorists. These are not people that you want to enable. Um, and at the same time, when we look at how this works with IP addresses, which are also on the sanctions list, ISPs are not held to try and censor them in the network. They're meant to be censored where people interact with the internet, meaning on

websites, on financial sites, that kind of stuff, right? This is similar. Um, if you go to an exchange, that exchange might have a sensor list and say you can't work with us. Um, but then once the transaction is in, it's just another transaction and the underlying network should be neutral. >> Yeah. And I I think that the goal of putting certain addresses on the sanction list um you know, I don't like to hypothesize or put words in other people's mouths, but I think it was basically to say that if you're an American citizen and you're sending money to these addresses that are controlled by terrorists or hostile nation states, um that constitutes doing

business with them and that's illegal. Um I don't think the goal is necessarily to say that the infrastructure providers that make it possible to do business with them are also guilty of the same crime. Right? So if that were true then you know any sort of infrastructure that supports a sanctioned entity would be culpable. So like the roads that they drive on, the ISPs that they use to your point, um would all be guilty of of something that really was not something they participated in in the first place.

>> Right. Do we have time to touch on two EIPs in Amsterdam or do you want to go to ECC and wrap it up? >> Uh let's touch on the EIPs. I can very briefly say I have not planned my trip to ECC yet. I was supposed to do that today. I'm still supposed to be there today, >> but you're going to be there. >> I'm going to do my best to be there. Yeah. >> Awesome. Okay. So, um 80045 slashed validators no longer selected to propose. So, I'm going to put my Pikachu face on and say the what? Why would a slashed validator ever propose?

EIP 8045

Yeah, this is like an interesting uh sort of edge case that I think is kind of fun and and I thought it would be fun to talk about, but um the beacon chains proposer selection logic doesn't take into account whether or not your validator is slashed. Uh you stop performing attestation duties and you're forced to stay online, so to speak, uh and and bleed out ETH over a certain amount of time. And if there's a correlated slashing, that number goes up. That's why your validator isn't immediately ejected from the network.

It's because we don't really understand if more validators will be slashed after you and and that correlated penalty has to be applied. >> During that window though, you can you can still be selected to propose, which is counterintuitive uh since you've sort of been ejected from the network, but now we're asking you to build a block. Um >> but then if you do, we reject the block, right? I'm actually not entirely sure if it gets rejected honestly. >> Okay. >> Um but the they'll no longer be selected to propose in in Glamsterdam. So that's like a nice small change to the selection logic there.

>> Uh that kind of removes something that would violate what's called the principle of least astonishment, which is like one of the guiding principles in system design, which is that a good system doesn't astonish people more than it needs to. >> Okay. Yes. And I I certainly when I first heard that I felt astonished. It's like how what? >> Yeah. And there's another >> similar subject with sync committee participation where you can actually exit your validator and uh you'll stop receiving a tester duties but then suddenly you're in a sync committee and that's >> sync committee duties. Yep. Okay. So EIP80 um I'm assuming that's disallow using the consolidation queue for exits. Um,

EIP 8080

>> no, it's actually to let us >> what's going on now and what what do they want to fix? >> Yeah. So, uh, there's this weird edge case that I think everybody missed um and until somebody started exploiting it. But basically, when we added 0x02 validators, I believe back in PCRA um, MaxB went up. Is that right? Is that PCRA? That feels right. >> Yep, that sounds right. >> Um, uh, we we added a new Q, which is the consolidation Q. So basically you could take a 32 validator, convert it to a 0x02 balance and then consolidate a bunch of 0x01 or 0x02 validators into it where the balance of each of those subsequent validators is transferred to the first one. Uh and you can take a 32 E validator and increase its balance all

the way up to 248 E if you want to. Say I've done that and now I have 448 ETH in my validator and I keep consolidating another 32, another 32, another 32. Now what happens? Yeah. So nothing nothing unpredictable. Those balances just get added to your 2480 validator. It's allowed to go above the max effective balance. The keyword is effective. It's not a maximum balance. You can have a balance higher than the max effective balance. In fact, most validators on the network have a balance above the max effective balance because they're earning >> which then gets swept every 10 days. So >> yeah. So in a scenario like we actually had shortly after PCRA a lot of exits were happening. Um I think that was the

Kilm incident or I don't really remember but there was a huge rush to the exit queue. >> Uh >> and it could take weeks to get your ETH out of the beacon chain. It was actually faster for a while if you had a 248 validator that you weren't trying to exit but you wanted to exit a different one. you could just consolidate the other validator into your 2048 ETH validator. Um, and then when that validator got swept, the full balance would basically be swept. So if you take 2048 ETH and you add another 2048 ETH, you've got um 41 96 ETH balance and that's way above the maxed balance. So when it's your turn to

be swept, 2048 will be taken out of it and and sent to your withdrawal address, which means that you could essentially frontr run the exit. So EI80 is designed to close that loophole. >> It closes that loophole, right? So I remember um looking at the exec and thinking, well, we have two 256 Etherno, but we got these other 256 over here for consolidations. We could use that. and bringing that up to Lido. I thought this was as designed and then being told, "Stop talking about that."

>> I >> which was my first hint that this wasn't as designed. >> I I think that it was originally discovered because somebody did it. Somebody figured it out. They used it and then I forget if this is exactly right, so don't quote me on this. I know this is being reported, but uh the petrified website developer observed that somebody had done it and they asked the core devs like, "Hey, did I get something wrong here?" And they're like, "Uh, that's not supposed to happen, right? We just didn't think about that corner case." Um, so now 8080, which is to be clear, still inconsidered for inclusion, not scheduled for inclusion, right? Um, >> it would close that loophole and you

couldn't do that anymore. uh assuming it closes it veryant consolidate >> yeah the the way that it closes it and I haven't read the text of the EIP but basically when you are exiting you can exit through either the traditional exit Q or the consolidation queue so they should stay roughly equal in size and it basically democratizes access to this to this feature so that you don't need a 248 balance validator anymore to to use the shorter queue you can do it no matter what at one point Ethereum said we're going to have a hard fork every 6 months. It was kind of clear to people that that's very aggressive and optimistic. We're certainly not going to see Glamsterdam in June. Um I don't see how cuz we still

Glamsterdam ETA

have 20 EIPs that are CFI not even scheduled for inclusion yet these among them. Um so we don't know what even goes into Glamsterdam yet and we have three months left. Um, so best guess, when are we seeing Glamsterdam? >> Um, this is really just like a finger in the wind type guess, but I'm going to say September, October, somewhere around. >> Interesting. Yeah, I'm I'm I'm on September myself. I think that's that's my finger in the wind is September.

EthCC

Okay, ETHC. So, we're going to have um the East Staker stage on April the 1st as part of ECC and um we're going to have some talks there that go deeper into some of what we mentioned today. Um there's going to be a talk on EPBS, what Estakers need to know. There's going to be a talk on FOSIL, past, present, and future. Um I'm going to briefly talk about a uh niche topic which is homestaking behind CGAT. So if you're in Latin America, Asia Pacific or in Europe behind a CGAT um carry a great net and you can't get peers, this might be

interesting. Then in the afternoon we're talking issuance. That's going to be spicy. Uh Justin Drake is going to give us a stock staking straw map uh similar to what he did for Ethereum total. So that'll be I think very interesting to see how he sees the staking game evolving. Um then there's going to be a scaling road map by Mario on the Vidden G, another EPBS talk from Sigma Prime and then uh Rocketpool talk and we are going to wrap it up. So we're going to have a full day of talks that are relevant to stakers.

>> And where can I go to find out more? >> Where can you go to find out more? Exactly. I'm going to let leave that to Hannie to put the link in because I don't have the link already but it'll be in the description. Make sure it is Hy. Thank you. And uh yeah with that uh thank you patches for this talk. It was really awesome. I learned a lot. >> Super happy to be here and I will hopefully see you in can if I can get my flight sorted out. >> Exactly. So those of you who will be at the staking talk uh just say hi. We always like to uh shake hands and then uh otherwise I'm sure we'll have another

one after can discussing all the things we learned there. Maybe another brief thing on do we now fully both understand the the the slot timeline in EPBS. >> Yeah, I'll follow that. >> That's mostly me not understanding it right now. Um, and then what is Fosil doing and what did we learn from the staking straw map? You know what's coming down the pike. All right, thank you. Until next time. >> See you later.