leanConsensus Call #4: Exit queue

Transcript

Hello and welcome to beam call number four. Uh today we have uh an exciting topic uh the exit queue. Uh this is the very first uh call that is unscheduled. Uh so it's a topic that uh came up a little bit last minute. It's a little bit of a a niche topic but uh should be a fun call. And today we should be sticking to the one hour uh schedule. So, I'm going to uh start off with uh a quick round of updates uh before sharing the floor with uh to Mike and and Mesh.

Okay. So, first a few social updates. Um the first one is that I've uh added a little bit more information to the 2025 uh tentative schedule. Uh so in this schedule we basically have two main parts. The first part is the research updates in the first half of 2025 Q1 and Q2. And the culmination of this is beam day on June 29th. Uh we now have dates for the next few calls. APS uh with Julian and 3SF with uh Roberto, Franchesco and and Luca. And tentatively we have May 30th as beam call number seven for uh Rainbow Staking.

And then the second half of Oh, and in terms of choosing the the the dates, I uh you know, we did uh the first call on on Valentine's Day and and today is is Good Friday. So, happy Good Friday to to everyone who who celebrates. Um the second um part of the year will be dedicated to specking and here the strategy is to start with subspecs for specific modules and then to uh think about the full holistic spec towards the the end of the year. Um and in November uh we're going to have a beam day in in Buenosirus

uh during dev connect. And you know, maybe uh this is half a joke. Uh we could have the final beam call of the year on December 26th as a Boxing Day uh present. Uh another update that I wanted to share is that um we now have uh Luma registrations for Beam Day. So spaces are limited. We have about 60 spots and we'll give u precedence to researchers and devs. Uh but even if you're not a restru 1 day before ECC uh starts and here's a few useful links the Ethereum

protocol calendar uh with where all of the calls are are scheduled the ER&D consensus dev on discord as well as the playlist on YouTube where all of the calls uh go and there's also this very uh handy website beam roadmap.org that O from the ream team uh built. Uh thank you O. And uh the final uh shill that I wanted to give is that we have a new uh set of calls uh the EF proof calls with EF proof call number one happening on April 25th at 2 p.m. UTC and it should be a really exciting call with lots of alpha leaked on this uh initial call including three ZKVM reveals. Uh so

those are are three ZKVMs that uh have never been revealed uh publicly and will be first revealed uh during call number one. Um and there's also a telegram group if you if you'd like to join the community telegram group. Okay, on to the meat of today's uh call, the exit. So we have uh two speakers uh Malesh and Mike and Malesh and Mike have been working on this for several months now. So in uh June 2024, they published an academic paper and then they uh published an EIP very recently in March 2025 and even more recently in April uh this month they

published a NE research post to give a little bit of more context on on the EIP. And one of the reasons why I'm excited about this research is that it's a combination of two uh beam chain principles. The first one being that we're striving to have a system which is maximally simple. Uh and we're also striving to have designs uh which are optimal or close to optimal so that there isn't a need to go change them uh in in the future. So with that context um I will share the floor with uh Mike and and Males.

like do you want to go first or just opening remarks or should I go and which of us is are we going to share because we have a common set of slides? Yeah, why don't why don't you show the slides while you present and then Okay. Um and then I'll go. So yeah, just as a you know as a word a quick word to to kick us off. Thanks Justin. Um, yeah, we think the execute is is a pretty important topic and I guess it's something that we saw gain a lot of attention recently. I think especially when people started talking about staked ETH ETFs and like obviously we don't want to build a system that is like, you know, designed to be a a financial product or anything like that, but it just kind of called into question and it made people think about like, oh, what

what can like a long execute actually mean and like how does this impact people interacting with the chain? So yeah, I guess it it's Good Friday, so kind of as Justin alluded to in um in one of the earlier notes, we're kind of trying to revive the exit Q, raise it from the dead. I guess that won't happen until um until Easter Sunday. But yeah, very very happy to be here. Um I guess as a word of kind of order, Mles is going to give kind of a quick rundown on the academic results side of it and then I'll talk about the the practical implications and how we're hoping to apply those. So yeah, all yours.

Awesome. Uh this is what you get when you let an economist near uh protocol consensus. So uh you know, apologies if you don't like it, but Mike has tried to make sure that I'm saying sensible things. Uh so the plan like uh Mike said is I I'll give you a bunch of theoretical background and uh I I'll keep it short and then uh Mike will uh tell you practically what that means for our proposal or at least what our current proposal is. uh we'll start from where Ethereum is right now and uh update to that. Please feel free to jump in uh with questions. Uh there's there's no need uh to wait to the end. And uh also like yeah, if you don't ask questions, I just keep going faster and faster until we like you know finish

immediately. So uh just I I believe everyone can just unmute themselves. I won't be monitoring the chat. Mike, if there is something in the chat, just let me know. Okay. So the uh Ethereum exit Q and a lot of other exit cues are rate limited. We have uh discussions in the paper of different cues but in particular Ethereum is very rate limited. And a question you might ask is why? So there's some parts of it that are just around sort of you know stability of the uh validator set so that you don't have to keep updating who's in and who's out. But a more sort of economically founded reason is from this definition of uh Joe Kimu uh Emirat Tas and David Se and they defined uh

accountable safety. So accountable safety is basically the idea that if something goes wrong so there's if there's some inconsistency in the protocol some uh some people aren't agreeing um you have found you can identify a fraction of the validators as having provably violated the protocol. And why do you care about accountable safety? Well accountable safety is the foundation of the idea that we're using this proof of stake for economic security. That is the idea that if somebody is doing some if something's gone wrong then you know who's done something wrong you can punish them because you can punish them xanti you know that the fact that everybody has voted on something

has some underlying economic meaning. Now the core tension with this is that the consensus models and the simplest definitions of economic security uh start from a static validator set. So uh if you start from a static validator set um that's fine. You can say you can make statements about how much economic security is uh backing a particular transaction or a particular piece of finality. But of course real world blockchains people enter and exit. You're not going to commit your stake in perpetuity.

And when uh you allow for entry and exit, what that means is that the accountable safety of a transaction can only decrease over time. So something gets finalized but once that gets finalized um some of the stake that finalized it might have left the protocol, right? And what could happen is of course that the violation might occur be like violation might occur and uh the stake might exit before you can detect it at the protocol level in which case you can't hold it uh accountable.

So that's sort of why we uh oh mash can I add one thing quickly here? Yes please of course. Yeah. So, I guess one thing I really want to double down on is the fact that the accountable safety or kind of the economic finality or the economic weight behind a finalization guarantee does actually go down over time, right? Like this is kind of weird because you think, oh, time is passing like my transaction is getting more and more fork choice weight, which it is, but the reality is the because the validators are are able to exit the protocol, the economic security of the finality guarantee itself goes down. Now, of course, the rate at which it goes down, and this is kind of what what we'll get to, is very very slow. Like the the fork choice, the probability of the of the

block getting reorgked out kind of from uh from a fork choice perspective is going down, but the economic security is is going down as well. So, I think those two things are can both be true and and it's kind of counterintuitive when people are thinking about um these systems. Thanks. Yeah. Um what he said. Um all right. So what are we um what are we doing? So one way to think about it is we can model the accountable safety requirements that the protocol wants as a collection of validator set consistency constraints. So you could say something like um in time period t1 I only want delta 1 fraction of the

stake to be able to leave. in time period t2 I only want delta 2 fraction of the stake to be able to leave and so on and so forth. So for example you might say no more than 10% of the stake can exit within 7 days no more than 2% of the stake can exit within half a day. Whatever those uh accountable safety parameters that you want associated with the protocol are you can just write those down as a collection of constraints that you want uh the protocol to satisfy. And um now we need to now write down sort of what is the like you know going back to Justin's point about simplicity and optimality. So we've told you something um about what we want to do and now

let's think about what is the optimal thing you could do to do to define optimality you need to define some kind of objective function. So here's a particular model in which we can write down an objective function. So time is discrete and it represents when withdrawals can be processed. So for example in Ethereum it's every epoch boundary every uh 6 minutes uh in in uh you know Salana it's every 2 days whatever it is and each agent has a cost of waiting. So if you're starting to try and exit and you have to sit and wait for a bunch of time you're going to pay a cost uh this utility cost associated with how much time it takes you to exit.

I'll call the cost of an agent I CI and I'll uh put down a disutility that they suffer if they have to wait delta I units of time and what I want to do is I want to maximize I want to write down a protocol that maximi uh or sorry that maximizes utility or equivalently minimizes the expected disutility of people. So I want to let people uh I want to minimize the amount people have to pay in terms of the disutility cost of waiting. Um and of course I can't do this completely willy-nilly. I have to continue to satisfy the protocol constraints the accountable uh security constraints that we specified on the

previous slide. Right? So under that uh let's define a simple procedure. What is that simple procedure? That's the procedure that's going to be the ba basis of the first part of what we propose which is what we call minslack. So the minslack procedure just says at each period look backward in time and greedily process as many withdrawals as possible given the constraint. So look backwards, see how much uh based on past withdrawals, whatever that is the history, see how much of the um uh withdrawal capacity given the accountable safety constraints you've used up and then just process as many people as you can so as not to violate

any of the constraints. So let's do this by a simple example. To make the example even simpler, let's suppose the uh accountable safety constraints are given in terms of absolute numbers. So three units of stake can leave in the last four periods. Five units of stake can leave in the last 10 periods and 15 units of stake can leave in the last 20 periods. And here's a simple uh visualization. We are at time t today. And of course because the constraints tell us that we have to look back up to 20 periods. You sit up you you need to know what happened in the last 20 periods. So in the last 20 periods you had a whole bunch of departures. So on let's say 17 days 17 whatever periods before today one unit of stake left 15

periods before today one unit of stake left 13 periods and so on. So this is the history of previous departures. Okay. And now you are faced with these constraints. There's somebody or a bunch of people who potentially want to leave uh today in period t. So what do you do? Well, first you look back to three periods before and you see look only one unit of stake has left in the previous uh four periods. That was three periods ago. So regard with respect to that constraint, you can process up to two more units of stake and still be satisfying that accountable uh security uh uh constraint. So there's a slack of two.

Similarly, you now look back 10 periods. If you count that up and hope that we did it correctly, uh Mike did it, so it was done correctly. Uh there were uh four exits in those periods. And because there were four exits, there's one unit slack and there were nine exits over the past 20 periods. So there are six units of slack with respect to this constraint. So minimum across all these three constraints, there's one unit of slack. So you can process one. That's min slack. So you just count up all look at all the constraints take the minimum that you have and let that amount out. That means so given this history you can process one withdrawal. If you had a different history you'd have a

different number. It could be zero it could be much larger. In the paper we prove a simple theorem which is minslack is optimal under common values. Uh uh so if all if you think of all validators as having a common disutility from waiting then the best thing you can do is min slack that is the provably optimal thing under the assumption that uh you know me and Justin have the same sort of impatience to uh get things done. Now the reason why it's not optimal in general is that uh or why you might not be happy with that sort of assumption is that people might have extremely different time preferences. So I might

be a large validator who also happens to have uh aped a bunch of money into uh an a borrow position and that a borrow position is you know getting borderline. So, I quickly need to get my ETH out to top up that borrow position and not get liquidated. Um, on the other hand, Mike is just a very sensible uh careful validator who is just thinking, okay, it's it's coming up to that time of month where I need to valid rotate my key or time of year where I need to rotate my keys. Mike and I in that circumstance have very different time preferences. I need to go immediately in order to get uh not get validated. Mike is like anytime in the next month it's

not a big deal for me. Right? So with these heterogeneous values Minslack is no longer optimal. Why is it no longer optimal? Firstly of course within any given period you no longer uh even when you're looking at delays you know like even suppose you have like two units of stake that you can let out in a period you don't respect priority. That is to say you don't say okay a guy you can go first. And the second part is that you might say, "Okay, I have only one unit of slack left like in the previous example." So you might let somebody who's just rotating their keys out. That means you're now down to zero units of slack potentially for the next period. And now in the next period when a guy comes

along, you have you have to say, "I'm sorry, there's nothing I can do for you. The uh slack is empty. Um, you know, wait till the queue opens up." So there are two like I said there are two things one we don't respect priority two we don't take into mind that there is a marginal value of holding slack in hand there is a marginal future option value of holding slack in hand which is the ability to uh treat or ability to exit uh people who have a very high disutility of waiting so can I ask a question from the chat so yeah there's there's kind of an interesting conversation happening where um I The way in our model that that we represent this heterogeneity is with the

different cost you know CIS right um so Vitalik also kind of asked the question of what if what if cost is not linear in time right so instead of the the negative CI delta I what if it's like exponential in time or there's kind of like a constant fixed cost plus some exponential component I was just curious if yeah like from from your kind of economics background if any other model of dish utility would would make sense or like yeah I guess just curious your intuition here. I don't have immediate intuition like if there if we think that there's a class of utility functions that better models the um uh better models the disutility we can think about what is the optimal

uncqing procedure for that. Um yeah, I guess my my intuition is that as long as the disc utility is um kind of monotone in time like it's it still feels like a solvable problem. I think minslack still works um under any utility function if if all the CIS are the same. So that's kind of what we mean by the heterogeneity like we're saying CIS are different. So people have these different kind of slopes for their dis utility lines. If everyone has the same slope, obviously Minslack works. If everyone has the same parameterization of the other utility function, I think Minslack is also probably optimal. Um, but yeah, I I think it's it's kind of

like a good question and maybe something we can explore later. I mean, I I'll Okay, I'm just scrolling through the chat. So um I I I'll defend I I I won't defend it to the bone or anything, but I will defend the linearity assumption a little bit in the sense that there is always an option for me to like in terms of what I can do with my ETH up to sorry there is always like an outside option for me to get my ETH, right? I can borrow the ETH uh somehow from some other lending market and that could be a source like so uh because I can borrow the ETH the interest on my ETH is somehow my

dutility of not getting the ETH out of the queue immediately and my access to or my access or my ability to borrow the ETH um and or the interest rate that I can get for ETH could be my disutility of waiting for the ETH from the exit queue. So that would be sort of on the margin maybe one reason why you might think it is um hetogenous hetogenous because it's different people might have different abilities to access uh a lending market for the ETH uh but linear linear because it's uh that's that's sort of the interest or carry cost. I I don't know if you buy that but that that would be a

okay don't buy it. Um uh I guess the question we can also take it offline too. Yeah, we can take it offline. I'm very happy to chat about what you think the right utility model is because uh we can do it. Uh I mean we can talk about it. Uh uh I have to um I I'll take that offline. Okay. Um yeah, I guess uh this is the model. I'm I'm quite happy to uh work through other models of this utility if if there's something that's more uh palatable.

Um all right, where were we? Okay, with uh heterogenous values mean slack is no longer optimal because it you know it doesn't do the right trade-off. So it doesn't uh respect priority respect um the um it doesn't respect the uh sort of pri uh differences or the heterogeneity within period and it doesn't capture the option value of uh holding on to uh exit capacity for

future periods. Of course, given a distribution, uh you can solve it out using a uh markoff decision. Uh it's it's just a dynamic optimization problem if you buy um it's just a uh dynamic program if you buy a particular distribution. But uh so we we sort of model out a couple of uh things. Uh the mark of decision problem is super messy. So we do a priority queue instead.

Um so that we call pryomin slack and you can simulate it out for different distributions and you can compare uh the performance between the optimal pryomomen slack which keeps into account the option value of waiting uh and what what it gives you in terms of the this utility uh of course garbage in garbage out. If you didn't like the linear utility assumption, you're really not going to um uh you're really not going to like uh you know the uh distributional assumptions in uh optimal prior slack.

So but but we show numerically that prior slack performs very well. So you could write down a version and does that and I'll let Mike take over and deal with the questions. Thanks. Yeah. Um if you stop sharing then I'll share mine just so I have control slides. Cool. Here we go. Cool. You should all be able to see my screen hopefully. Yeah. just holler if if anything looks wrong and and yeah, happy to take questions online or or after at the end. So, right, that's kind of like setting the stage of what the what the

paper actually said. Now, of course, the you know, as as Vitalic was alluding to, like some things might not be um like part of the model you can take issue with. So, I think it's also worth just discussing how the Ethereum withdrawal setup is set, you know, is constructed today. And then we'll conclude by talking about kind of some of our design recommendations for for what beam chain could consider to kind of avoid some of the the mistakes that Ethereum potentially made. Not not mistakes but the design decisions that Ethereum made. Cool. So um right this is this is the diagram like I kind of have have been using to think about the withdrawal flow because it's it's quite complicated. So I guess there's four different

timestamps that we'll pay attention to. The first is when the validator initiates a validator exit. So there's currently just one way to do that. You use your your BLS key, which is your kind of consensus key. You send a message over the consensus network and that that like voluntary request says, "Hey, I would like to exit the validator set." At that point, you get assigned an exit epoch and a withdrawable epoch. The exit epoch is the point at which you can stop validating. Right? So up until this point um we say the validator is active because they're still expected to participate in consensus. Um if they're if they don't participate in consensus then you know they they kind of don't earn any additional rewards that they

would have for being online during that time. Um the next time stamp is the withdrawable epoch. So that's at the point where this the stake is kind of ready to be pulled from the consensus mechanism itself. And at this point the um kind of between the exit epoch and the and the withdrawable epoch the validator is not active but they do remain slashable. And the important thing here is that we want there to be some gap between these two so that if they commit a slashing violation right at the end of the active period. So like right at the end of this green period um we have like some amount of time to detect that slashability before their stake is withdrawable. And then the last part is when the withdrawal is is processed itself. So the first gap is

determined by the execute. So that's kind of like what we've been talking about this whole time in Ethereum. It's this rate limited first in first out Q. It's just very standard. The way that the rate limit is decided is you take the total number of validators and you divide it by um 2 to the^ of 16. Currently that leaves us at 16 validators per epoch. Um so that's kind of just how how we determine how fast that exit epoch gets hit. Um, of course, now we have to have this delay between the exit epoch and the withdrawable epoch. Um, as a as a kind of clear case study for why we need this. Consider if the execute is empty, right? If no one is in the execute, then your exit epoch could be like the very next epoch after you initiate your exit.

And so there is kind of this fixed 27hour delay to say we're going to give ourselves ample time to detect any slashable violation of the protocol. and then the stake will no longer be slashable and and will be processed for withdrawal. The last piece is is the sweep. Um the sweep is variable length because it just goes by validator index in kind of a roundroin fashion. So you start at validator index one and you you iterate through all of the validators. Currently we're at like right right over a million I believe. And during each block you can only process 16 withdrawals. Now this this seems like a lot. you're like, "Oh, you can only do 16 validators per epoch. 16 per slot doesn't seem that crazy." But the the

situation is set up such that every single validator has a withdraw in this queue processed. And that's because currently partial withdrawals, which are kind of any marginal ETH you earn above the 32 ETH that you the principal that you staked gets withdrawn automatically for you so that you don't have to um kind of pay any attention to it. So right now basically all of these like 0.1 point I I think it's like 05 increments get swept off um kind of repeatedly and that fills up the withdrawals for each slot. So that's that's currently like a bit of a inefficiency in the design and that's kind of one of the things we'll propose certainly for for a candidate for removing from Ethereum but also as we

can consider like the optimal design for an exit process like it probably wouldn't have this sweep in there because 9.2 Two days can be quite a long time. Justin's thing just hearts just floated up. I don't know why that happened. I clicked the wrong button. It was reactive with web animation. Cool. Um, right. So before jumping into kind of our proposal, I guess yeah, the that what I just described was was Ethereum as of the last hard fork, which is the Denun DB um Cancun hard fork. I think it's also worth talking briefly about what changes in progra. So progra is scheduled for for May 7th I believe.

So so coming up a year and there are some changes but the kind of core essence of the execute does not change too much and that's kind of very important to consider. So there's there's an EIP EIP 7251 increase the max effective balance. Um yeah and there's there's kind of three features about that EIP specifically to do with the execute that I'd like to highlight. Um okay that went away right so first and foremost the execute is now denominated in ETH instead of number of validators right so on the previous slide I said you can only pro process 16 validators per epoch that only makes sense if all the validators have the same amount of stake um max changes that so that there can be many many different

validator sizes so one validator could have 32 ETH one could have 20 thou uh 248 ETH and so you can't denominate the exec in just number of validators because they could have very different weights so you have to say I want some amount of ETH to be able to exit per epoch for example. Secondly, validators can choose to compound their stake. Um and this allows them to trigger partials withdraw withdrawals from their withdrawal address. So this is like some jargon. So let let me try and unpack it. There's two keys that are involved or or kind of two identities that are involved with the validator. First you have the consensus layer identity which is this BLS key. Um this is how you sign your addestations. This is how you sign your blocks when you're proposing them. Um,

this is like a very important set of keys. But separately, you have a place that like an address on the execution layer where the withdraw actually gets sent to, right? So, you have to like have that that ETH accessible somehow within the execution layer. And the way we do that is is there's a place you specify what withdraw uh what desk what the destination of the withdraw should be. Um, so if you opt into compounding rewards, basically now you're saying, okay, beyond the 32 ETH, I want all the the staking rewards that I get to be redeployed into the validator and keep kind of increasing my my relative weight in the validator set. Now, if you recall, the last stage of the the

withdrawal flow was this partial withdraw sweep that kind of goes around in this round roundroin fashion. So by by switching to these compounding things and saying I actually want to trigger my own partial withdrawals manually like maybe once every month once a year whatever you're opting out of that sweep. So now every 10 days instead of every single person processing withdraw you only process people who haven't switched to this compounding stake credential. So that's that's kind of an important piece. And then lastly kind of again double clicking on this um this withdrawal address validators can trigger exits from the withdrawal address. So previously with that kind of first step of the pipeline which is initiating the validator exit um we call these voluntary exits because it's kind

of initiated by the validator not from the protocol itself. And um now validators can trigger those from the withdraw address as well. So not only can you uh trigger partial withdrawals but you can trigger full exits. And these two things are kind of important and and again I'll double click on them when we get to the kind of beam chain recommendation section. Just taking a quick time check. Okay, it's 8:36. Uh yeah, I think we should be good. So what is our proposal? You know, we've kind of been yapping at you forever now. Give us some give us some details. So what we're proposing is what we call single constraint minslack.

So Mles talked about minslack being you kind of enumerate a list of maybe end constraints. Maybe you have 10 consistency constraints that you want to say about the protocol. Um, and Minslack goes through each of those constraints, determines kind of the remaining the the minimum one that has slack available and consuming all of the slack in that um with sub subject to that constraint. But we're actually taking a even simpler approach here and just saying okay specify a single constraint that you care about. Normally like this this could be like something like the week subject subjectivity period like over two weeks we only want 5% of the stake to be able to exit or over 90 days we only want um you know 25% to be able to

exit or something like that and kind of enshrine that single constraint and then let the protocol do whatever it wants outside of that. So how does that compare to what we have today? So today we have this setup here which is effectively a constraint per epoch, right? So we're saying in the next epoch only 16 people can exit. In the next two epochs, you know, really only 32 can exit and only 16 in the epoch after the the previous one and so on and so forth. And this new constraint per epoch is like very limiting in what the protocol can do because now if you have like some variability in demand for exiting like even if the average is 16 per epoch, you can still have periods of

like high high congestion because everyone's trying to get out at the same time and then there's periods where no one's trying to get out. So that's kind of the situation we're trying to avoid for I guess switching the the denominations of these constraints into something that looks more like the min slack constraints. We can say like oh currently we only allow 00015% of the stake to rotate per epoch and kind of you can you can take that out over longer time horizons. So yeah, the the kind of thing I was alluding to earlier is that in reality, this is probably too many constraints, right? Like no one is looking at the per epoch granularity and saying, "Okay, my transaction has 034% decay and safety

over one day." Like that that just feels like kind of unnecessary to um to to codify that many constraints. So, we proposed this kind of single thing that that gives everyone the same guarantees and allows the the exit process to be much more flexible. So, um if you haven't seen The Incredibles, you should you should watch it. It's it's a great movie. So, yeah, there's a line um Elastic Girl is very flexible and her husband Mr. Incredible says you need to be more flexible, right? Um post aside, let's let's continue on. So what does how does single constraint min slack actually work? Um we're kind of calling it or I guess one one nice way of thinking about it is

this idea of retrospection. So the protocol currently only can look forward in time, right? It doesn't keep any history about the past withdrawals. It just says epochn you can withdraw 16 epoch n plus1 16 all the way forward carried in time and in aggregate you know over the n +1 epochs represented here no more than 16 * n plus1 exits can be processed so what does retrospection mean retrospection means instead of that what if we looked back in time so we keep some history of the amount of people that have exited during the past 16 * n plus1 exits and we use that to enforce the consistency constraint Right? So now we say epochn is the present epoch. We're looking back m +

one epoch to epoch n minus m. And looking back in time we can say how many withdraws have we processed in that time period. Okay. What is our consistency constraint given those two numbers? We can calculate the amount of stake that we can withdraw in the in the current epoch. So that's kind of super simply what what this is trying to do. Um and yeah that's that's retrospect. Yeah go ahead mash. No just just like the one one sentence TLDDR is we're just taking some given constraint seriously.

For example no more than 10% a stake can leave in a month and just maintaining that invariant. So we're always looking back in time a month and we're saying how much is left the amount you can take out is whatever will not get you past this 10% invariant. It's a one invariant system. Uh the actual proposal is slightly more complicated because we're trying to be nice about or trying to be a little more sophisticated about a few things, but the idea is just you pick your invariant, tell me what you're happy with, and then uh we'll we'll just run with that invariant. Thanks. Yeah. Yeah. And I guess it's also worth pointing out that um with this invariant, you have kind of the guarantee that over every two week or every two week rolling window that

consistency is is there. So you kind of have this kind of every epoch you move forward, you take the the epoch two weeks ago and you toss out the exits that were in that one and you only consider the kind of intermediate ones as as part of your consistency constraint, right? Um so I included a few spec highlights just you know to to show that it's actually not too difficult to implement this. I guess there is right I'll I'll add some caveats at the end, but basically we use a few different things. First, we use this exit churn vector. The reason we do this is to simplify the accounting, right? So,

right now, if we counted the exact number of exits that were processed in each epoch, that's kind of a lot of data, right? Like every 6.8 um minutes is is an epoch and you'd have to write a new piece of state like consensus layer state data down for for all of that. So we use these generations to simplify things. We say a generation is about um 27 hours epochs per generation and we have we kind of account for 16 generations in our history. So that's the only thing we have to add to the state is instead of this kind of running tally from each epoch we just keep the running tally from the past 16 generations. And then the actual kind of like meat and potatoes of Minslack is is

codified in this for loop. We basically say how much churn did we use and let's like um given given how much we have left over the past 16 generations how much can we consume in this generation and that's that's kind of all that's happening here. Um there is some some tech debt here and I call it tech debt because if we were building this from scratch I don't think um we would have this issue but because of the way that Ethereum exits work today we have to explicitly set this exit epoch kind of when you when you first hear about the withdraw not when you actually process it right so there's kind of different ways you could think about designing this if you started from scratch but because we have to do this we have to

like look forward and map the exit to a specific generation in the future. So we're like looking a few generations in the past, two generations in the future, mapping the current exit into some generation into the future. And that's how we explicitly set the exit epoch like when in the initial stage of the processing of of the withdrawal. a more natural approach I think is to maintain kind of and and I guess this is this is definitely like for the engineers to answer not not for me but um intuitively what's a more natural way to do it is to to maintain some sort of state that says these are all of the exits that are pending and only when we process them do we have to set the exit epoch and then you can kind of do this thing where we only look to the past and we only use

this retrospection um but yeah that's that's kind of how we how we implemented it at least in the in the EIP I think this is all very uh very subject to debate and like if if people want to to go back to go back and forth on the spec um that's that's probably very useful. Um I guess yeah yeah I'll leave it there. Right. So I want to highlight I have like yeah a few a few minutes more then I want to highlight a few proposals and then we should have like maybe 10 minutes for for Q&A. So, um, as you might have detected in my kind of earlier discussion, I think we should we should also consider getting rid of the partial withdrawal sweep just because that extra 9.2 delay 9.2 day delay u, I guess on on average it's it's 4.6 days,

but it's seems very inefficient to have that mixed in with the full withdrawals. So, either you can remove the partial withdrawals sweep all together or you separate partial withdrawals and full withdrawals into like separate lanes and you don't bottleneck them in in the same process. So this on you know right out of the gate this could save on average 4.5 4.6 days per exit. Um also there's this priority fee ordering for withdrawals that that kind of could be considered. So up until this point I guess MSH Mles told us that Minslack itself is optimal under this heterogeneity um or sorry under homogeneity. If there's different priorities for exiting um then implementing pryo in slack is a clear

improvement and one way you can implement this is by allow allowing people to kind of explicitly bid or explicitly kind of tell the protocol this is how much I'm willing to pay to get out and then you can once the protocol has a view into into that market then they can order on based on like highest amount that people are willing to pay and um this is how this is kind of like one way you can implement pryomins it's it's one way you can elicit it bids. Obviously, there's some questions around what is the kind of procedure for bidding. Um, what's the, you know, there's some market design questions I would say that go into like what do you do with the the amount that people are willing to pay?

Do you burn that ETH? Do you give it to the with to the validator that processes the withdrawal? Like there's there's kind of questions there. But this is one way you could do that priority queue and elicit information from them to allow you to like handle the withdrawals in a more um priority Q way than a than a first in first out, right? As as we kind of alluded to earlier. Okay, cool. So, just going to highlight five or so beam chain suggestions and then we'll open up the floor for Q&A. So, first definitely denominate an ETH. I think this is a no-brainer. If your validators are going to have different stake weights, then you have to denominate the the execute itself in that numerator. Don't do the sweep. I think in

general, yeah, the the partial withdraw mechanism was kind of built for a world where full I guess I'm actually interested now in the history. Maybe Justin Orvital can can share, but the partial withdrawals logic that that happened before full withdrawals were even enabled or did they happen at the same time? I think it actually happened at the same time, which is in the fork after the merge, um, which is the Capella hard fork. But anyway, the the point being, you know, this is a world where we were building proof of stake kind of like in two parts, I guess. The the first part was well, in many parts. The first part was the beacon chain and then the actual

merge itself and then the withdrawals weren't enabled until after the hard fork after the merge. So I guess I'm not saying that like any of the decisions we made in the past were wrong but I think kind of starting from scratch it's pretty clear that the sweep should not be part of the um the design. Um, we suggest single constraint min probably the right place to start. Um, at least in terms of like only defining one constraint and one invariant that you want honored by the by the process. Also, this pay for priority thing is is certainly interesting. Um, and it ties in nicely to this next question which is I think it's it's important to get right how the integration with the execution layer works. So I think this is another thing that um that in progra we're kind of

paying a lot of attention to which is how like what what set of validator controls are accessible from the execution layer itself. So from a smart contract or from a key from an EOA that is like controlling the validator itself. And I think this is probably the correct way to implement this pay for priority thing. Like you'd have maybe an auction where you sell the right to exit five slots in the future. um and you conduct that auction with like a a native contract on the execution layer and then that gets kind of that data gets consumed by the consensus layer. So I think that's probably the right way to do it. Um again the the exact CL interplay and how that will work out um in beam chain I guess is is still

probably up for debate but um that's at least on on surface what I would suggest for for you all. So yeah, thanks very much. This concludes our presentation. We have exactly 10 minutes left in the in the hour. So yeah, here's just the links that that we've kind of been discussing and sharing over the course of the call and super happy to to take questions and thanks again for having us. Thank you Mike and Mesh. This was a a great presentation. Uh please raise your hand for questions. Terrence, yeah, this is a great presentation. Thank you. Have you thought about running this algorithm on perimenet and just backtrack all the data over the last few years and just see like how much improvement I guess in

terms of utility. I'm curious what that would look like. Super interesting. Um so I guess yeah you want to answer and I'll Yeah, I can answer that. So like at least we looked at okay we we've not we we've ran this visually. What does that mean? We looked at the historical uh validator exit Q and if you look at it there's only one period where the exit Q got past a day. Okay. So you look back at like uh validator Q.com it never happened. I think the bigger concern is not that it has never happened. The concern for a lot of people and uh Justin said there were people from Lido who would be in this call. There are lots of other

institutional stakers. For them, the concern is not that it hasn't happened. It's what do we do if it does happen and we have like 5% of stake waiting to get out just like we've seen. I guess maybe a different answer to your question is we could rerun it on Hleski or something and see what that would do for us where there is like a massive queue waiting but on mainet we've never had a massive queue. Yeah. So I I do think it's interesting. I'll say that we wrote this paper very much as like a theory paper, not an empirical paper. So we didn't go through and like process all the the withdrawals. I do think it's an interesting question. Um I guess some institutional staking people um asked me kind of like on average how long has the

delay been and you know the best data for this I think is is the validator.com. So that's where I'd point you. I also wanted to call out um yeah uh Vasil had a nice comment that is the average a tester slashing is about half an hour um and that's something I didn't mention in the talk itself but if scrolling back to this um you know I think everyone agrees that there needs to be a delay between the exit epoch and the withdrawal epoch that delay being 27 hours or 256 epochs um I think was made in in an abundance of caution like there wasn't any data on slashing at that point because the proof of stake didn't exist on Ethereum yet.

So, I think re-examining that number is also something that could be like a candidate for for improving efficiency. Um, and yeah, I definitely agree that 27 hours feels feels very long. I guess under the the world of like a a network level attacker trying to like partition or like eclipse some set some subset of the validators, it might be important to to really be cautious. Um but yeah, thanks thanks Vicil. One question I have is Males, you um talked about the exit Q not going over one day, but what about the deposit queue? Presumably similar improvements

can happen there. Yeah. Uh so we are less I guess I mean the entry Q we understood the constraints that we were trying to solve for uh the exh sorry the exit Q like that that that there's the accountable security constraint there is an entry Q and some of it is I guess for validator security like you can rewrite this for the entry Q uh you just have to tell me what is the underlying constraint that is cause making entries scarce um and once we agree on that we uh if if it's a similar kind of you don't want more than 10% of stake to enter in a month or whatever then you can we can redo the computation we just

don't we didn't have an underlying principle that is governing why there is an entry queue um maybe Mike knows yeah um we yeah I think in general the reason for rate limiting the entries historically has been that the overall set doesn't change too quickly. Um, and there's people in this call that are that are much much more, you know, aware and like, you know, Vitalik and Justin like were there designing it. Um, right. And Terrence says it's for influence on finality of for choice. So, yeah, I guess in in our paper, we restricted our attention to the exit Q because that's the thing that that we felt like is like the simplest thing we

can capture. I do think it's worth examining the entry queue and thinking about very similar questions. As far as I can tell, it's it's symmetric I believe as presently constructed which is the same amount of stake can enter as can exit. Um and obviously that doesn't imply that like the validator set can grow if if the entry Q is more full than the exit Q. And I do think there was I guess kind of calling back to the second question which is h how have you looked at the data? That that was Terrence's question. Um I think there was a period where the entry queue was very long, right? And and that was like immediately after withdrawals were activated kind of there was this massive rush for everyone to get into the consensus mechanism and um during that period I think even when

I deployed my validator I think it took me like two or 3 weeks before it was actually active. So quite slow. Um but yeah definitely worth um considering in future work. And I want to answer one other question from the chat from um unaw which of these suggestions actually absolutely require the beam chain eglack proud slack no sweep all could be beacon hard forks as well without overwhelming difficulty I definitely agree that's why we proposed to the EIP to you know the Ethereum chain instead of necessarily just to the beam chain um that being said I think there's there's push back and probably fair push back that this is a what we're designing in this EIP is an

upgrade for the validators right and Um, generally speaking, the focusing the Ethereum hard forks themselves on kind of like things that are facing more the application layer users and the the chain users themselves rather than the validators is probably like where the priority will be. And I think after EIP7251, which turned out to be like way more complicated and intricate than I think anyone expected, there's probably not going to be a huge core dev appetite to to like touch exit Q stuff again. like it's it's just like a very kind of painful piece of the process. So, I think we we'll continue to push some of these EIPs and like maybe they'll they'll be done by Ethereum mainet

eventually, but I guess it's also useful to just think through the groundup rewrite um approach and and that's I guess why why we're presenting at beam chain as well. So, thanks for the question. Oh, there's one more question. Oh, it might have been answered already. Oh, yeah. Meet the meeting is about to end. Oh, that's fireflies. One question I have is regarding the generations. My understanding is that you're trying to minimize the amount of blows in the state. Uh I guess one potential downside here is that it creates this spikiness uh at the boundaries of of generations and that might be kind of bad for things

like snarkification of the chain uh where we want to you know reduce the worst case uh processing is that the only reason for reducing for having generations that is the only reason like it will just I think uh we had some of um our friends at TEU uh look over this Yeah, we Yeah, I mean Mikuel is on the EIP and then uh other uh engineers and they were just like, "Dude, we're already like slammed at epoch boundaries. Uh so please don't do something at every epoch boundary." Like you could you could pre-do some of like anyway uh I understand that we're doing an even larger calculation writer generation

boundaries, but maybe you can uh smooth that out somehow or amatize that cost. uh it's just not adding something at every epoch. That was the only reason. Um it actually makes the proposal as you can see harder to gro. So we're not thrilled about it. Yeah. And I guess this does relate to um there's another EIP Justin's um Justin and Lynn have an EIP that um kind of determinist deterministically sets the schedule for leaders and doesn't allow changes in the effective balance to to reshuffle the leader selection.

Um, and I think there was similar push back on that EIP, right? Which is if you do these at the epoch boundary, it's like more overhead. And you know, I guess Franchesco and Luca will talk about this in the single slot finality thing, but if you don't have this epoch boundary constraint, like maybe this this alleviates a lot of the kind of bottleneck and and you can just with in a single slot finality world, you don't have to worry about these epoch processing things. So hopefully um hopefully the tech debt that was that we saw when we were trying to implement this um in Ethereum isn't present.

Yeah. I mean, one of the goals in the beam chain is to try and reduce the number of arbitrary time frames that we have and just process everything as much as possible on a slot by slot basis and have it very very smooth and basically remove the spikes at the boundaries. Oh, there's there's a long conversation going on. I don't think we'll be able to capture it in the next minute, but um yeah, I guess we can continue it in the in the beam chain chat potentially or um if anyone wants to reach out, we're super easy to find on on Telegram and Twitter and stuff.

So, please do. Actually, what I'll maybe do is uh put the chat in the Telegram group that we have u and basically rename it to exit Q and draw yours. And anyone who wants to have a post call discussion, please DM us and we'll we'll add you to the post call discussion. Uh Mike and Mles, thanks again uh for the great presentations and discussion and we'll see you all in a couple weeks for beam call number five. Thank you. Thanks so much. Thanks for having us. Thank you guys. All right.

Thanks.