Ethereum Block Proposer selection with increased Max Effective Balance (EIP-7251)

Transcript

hello and welcome everyone my name is Peter Robinson this is the ethereum Engineering Group Meetup and Sandra Dr Sandra is here today to tell us about um the possibility of moving from um stakers with 32 e to maybe having a lot more stake and what the ramifications of that might be so um welcome Sandra and I hear you're going to introduce yourself via your slides so why don't you then laid off okay sure um let me just get share my screen and just confirm that you can all see my screen uh yes I can see thumbs up there from Joanne as well and and Peter

yeah we can see them good okay so I'm talking about uh some work some research we were doing um on proposer selection and I'll go through the EIP that I mentioned here as well so um as Peter mentioned I'm Sandra and I work for consensus software and I've been with the R&D team there now for approximately five and a half years an interesting little fact is Peter was the one who hired me and uh the research I'm presenting today is um actually joint work with kri mangas Patrick o Calahan that's on the call today as well and Andes Matson um who who's from Denmark uh at alborg

University so just a very brief overview of the talk today so I'll um provide a bit of context for our research um and then I'll um Talk a bit about um EIP 7251 as the title alluded to so because this research concerns that EIP and then what was the motivation for that EIP then we'll go into the actual proposer selection modeling um and I've got included some references and links to blogs um and then just um yep and then we'll kind of wrap up so just to provide um some context here so um the key issue here the problem

statement essentially uh is that in the ethereum beacon chain protocol there's sort of uncertainty about the future computational load that nodes will have to handle um and the the load is is roughly proportional to the number of active validators um and the attestation processing time Epoch transition processing time and memory requirements and they all kind of scaned line linearly with the active um validate account um so so basically this this problem was identified by vitalic and it prompt prompted him to write a a blog post on

how one could potentially cap the number of validators uh and this this blog post was the initial motivation for our research and we co collaborating with barab um mono from the robust incentives group um short um they just call them the rig group at the EF on this uh project and he mentioned that basically solving this dilemma um is a precursor to achieving single slot finality however when I started looking into vitalic musings on the subject I suddenly discovered that his blog post on validat set SI capping ADV vanished um and but instead uh vitalic had

Incorporated this problem within the larger context of single slot finality which really was the motivating the sort of driver of um capping U validator set size um so basically that is then what we had to do we had our initial research question was what is the preferred strategy for capping validator set size so vtic um proposed several potential options um basically super committee so instead of basically all of the validators participating in each consensus round only a medium siiz super um Committee of

tens of thousands rather than all of them um and they um will allow the the rounds of consensus to happen in just a single round the other proposal he had was to cap the validator Set uh which is where our Focus was rather than the super committees so um there were two strategies that he suggested one being uh order based capping and so in this um with this sort of strategy it's um either the oldest validator stays so if if it the if it's reach the cap then um then basically if someone leaves the

oldest validator would stay uh the other one is the opposite the newest validator stays uh and then there's the um other strategy is economic um capping and that can be done basically through um total capping the total eth that's deposited or the total validate account so this EIP or the ethereum Improvement um proposal uh was to increase the maximum effective balance and um basically that sort of happened at the same time as we started our research and uh a teacher who uh at the time worked for the EF but is since

left to work elsewhere he published a post uh that attracted a lot of attention um and giving us a more sort of specific path forward to reduce the active valid dat set as falic had mentioned so he also highlighted here basically that um our validator set is large but it need not be that big because uh he reckoned it could effectively be reduced by half um because a lot of stakers that stake in e would be running more than one validator so really um it's just unnecessary duplication of tasks of messaging that's

going through so in that little um diagram there which I took from his blog post um you can see there you've got one Staker that runs three and the others are two single um two single uh validators so um Mike Neer also from the ethereum foundation then started articulating adicha thoughts um in what he termed a modest proposal to increase the maximum effective balance so this was the means by which they thought they could um contract the validator set size because instead of single validators you could combine two

or more together into a single validator um I've included links to all these posts in my slides and I think Peter will share share them um with you later so so his Modest Proposal as he termed it was the start of uh formulating what would actually become EIP 7251 so it it appears to be a very simple objective uh to reduce the number of validators by increasing the maximum effective size to 64 times um what it is currently so currently it's 32 e um so proposing to to change it to

248 um on the assumption that the large validators will choose to consolidate some or all of their validators into large into larger validators the other interesting sort of um offshoot of this is that um say people do not or or unable like if you solo state you are unable to um combine more than one B data because you haven't got enough e to stake or you don't want to stay more eth um it also then effectively enables autoc compounding because um your your uh limit of um what you can stake is much higher now so any

rewards earned um can also then earn basically when you earn um reward Wards uh by participating uh as a as a validator you can basically earn more but um just remember that the increments though are in one e so providing your rewards have accumulated to one e that then instead of 32 e it'll be um 33 e so um anyway so effectively this is now been written up um consequently by so Mike Neer was then officially the champion of this EIP but it was also

co-authored by lot of uh by several other people um and although this is an EIP in its own right it it's also dependent on um another uh EIP being implemented EIP 7002 and what this EIP does um is it enables you to trigger a partial withdrawal um through from the execution layer now it'll I'll discuss a bit more down the track why this is this is important so what these um so as part of uh the spec changes as a result of if you know if we're going down the route

to implement EIP 7251 um you know some of the things that are required so there are three constants that are uh one will change so obviously the maximum effective balance will change from 32 to 248 and two new ones are being introduced so uh we've never had a minimum activation balance because basically the maximum effective balance of 32 was also what you needed to be able to start staking to to run a validator but now there's going to be a discrepancy between um your minimum activation balance so that's remaining the same so that's going to be 3 to e um and also the um withdrawal prefix will

change from 0x01 to 0x02 and then the protocol will uh basically know that this is a compounding uh validator um or you know a Consolidated validator and it does not um adhere to the rest of the sort of um rules that apply to the 0x01 validators um within the features there that um they clearly Define as the spec is sort of mainly stable now but it's still a little bit in flux uh for example there you'll see with um feature number three um talking about custom setings uh the discussion I can see at

the moment um around this EIP is that probably won't be included um because it'll add a lot more complexity to the code Bas and it doesn't seem if you know there's no real uh traction there for um people wanting to implement that and this is where that EIP 7002 will give this sort of functionality already because with a custom ceiling you'd basically be saying well once my validator gets to this I want to it to be part of this um so what happens um every night is there's a there's a continuous sweep of all the validators and um any balances above 32 e are basically

withdrawn into the validator account but once they Auto compounding obviously that's not going to happen until they reach um 248 e so if you've got a um a stake a balance effective balance much lower than that but um say it's 64 eth and you know um it's gone up to about 67 and you want to actually get that um use that two eth elsewhere you can actually then um initiate a partial withdraw from the um execution layer because and that's why they thought they they could put in custom ceilings and then you'll have a custom seiling say it's 66 and if it's any more than that it'll withdraw

but it just seemed overly complicated in this um the changes coming um through this is already quite complex anyway because you 7251 came along while we were looking at um sort of capping validator sizes um using one of the other uh sort of proposals of italic uh we decided to update our um our research question um to basically say that um can you know um if we allow for this varied con consolidation strategies by large stakers can we

confirm um that apart from an expected slight increase in processing time there's no adverse effect on propos a selection for stakers and validators so that is where we changed our Focus to um and also we just wanted to make sure that validators were stakers were not adversely affected by this change and um so it's um especially with regards to solo stakers um you know their stake will be so much smaller we just wanted to ensure that they are not adversely affected um however there is as I

mentioned briefly earlier there is a benefit to them in in as far as um the fact that they'll be able to compound um but also you know what does that mean for large stakers is one consolidation strategy better than another anyway just um a slide with some links if you're interested in looking at some of the analysis that's been done to date um there's a lot that has been done uh and more is done all the time um anyway you you'll be able to click onto any of those links um because the slides pet will make available after the talk so before I dive into the actual uh analysis and modeling just

want to know if there any questions so far I can't I I haven't checked the chat if not I'll carry on right I think it's all been very clear all right good so with proposer selection um analysis and modeling uh so first of all looking at this one con one um thing that was mentioned is a slight increase in proposes elction time we thought well let's have a look at what that would be so um here we um is a a sort of negative binomial graph and what we find is that

the medium value so so basically we're assuming that our entire validated set are people with 32 eth effective balance so the probability of any one of those passing the proposed check is 0.016 so we use that to then work out the um you know the number of basically iterations or failures basically before we have um a a successful successfully chosen proposer for the next block the median value for this was uh 43 so essentially you know half half would be less and half would be require more iterations um and then I thought i' just

look at a few uh as other sort of values like you know uh what is the probability that fewer than 100 will be required um and that's 80% which is pretty good but then there's still 20% um that we might need more than 100 iterations once we look at uh the probability that more than 200 iterations will be required we're looking at about 4% more than 300 1% and then it sort of goes down as you can see uh quite rapidly so really these additional iterations should not have any noticeable effect on processing time because it yeah so then um basically we're looking now at the actual process of selecting a

proposal and that involves a few steps so first of all um basically the validator set with all the validator indices comes along it gets shuffled then the first select the first um the first validator index on that set gets uh selected as a candidate and then we perform a check to say um has this validator passed the the test the shuffling of those um validator indices is done by what a technique called swap or not Shuffle um and that is a link to the actual um method that computes the shuffled index and again that's a link

that you'll be able to click on if you're interested um and also I've put a reference in the references to to the paper that um explained this technique in detail then to actually um choose the next proposal um also there's a link to that um that procedure in uh in the slides um so as I said we um well I've just said that so anyway you keep so obviously if if you then go through this process you Shuffle um got the first V dat do the check if it passes yes fine then you you move on you've got your next proposer your proposal for the next block if not then you just iterate and

you do the whole process until you find a um successful validator so um one of the things that happens as part of this is um there's a an equation where we need to um basically generate a random bite value so that used in our equation and that will be I'll show you in the next slide so so we need as part of this proposed check we need to generate a random bite um and this is the code that basically generates this pseudo random value and we ran this code to generate values for I just decided on a fairly large valid dat set random sides of like

76,800 and then we superimposed the uniform distribution across um those values that that the random bite can take and as you can see this clearly resembles um a uniform distribution which also then um supports the assumptions made in a lot of the analysis that you'll read uh if you read some of the analysis uh where they just assume that the random bite is uniformly distributed across that range and we also then confirmed it statistic Al through a QQ plot so with the um this is the uh basically the code check there so it

says if the um validator effective balance is um greater than um if it is um if the sorry if the um the proposes um effective balance times the maximum value that the bite can take which is 255 if um so if the effective balance time 255 is greater than or equal to the maximum effective balance times whatever random bite was was generated for that validator then that person gets to to

pass the test so we can just rewrite that um a bit we see that the randomly generated value needs to be less than uh 255 times the effective balance divided by um the 255 D effective balance divided by the maximum effective balance so clearly if the um validator keeps their effective balance at the maximum um effective balance then they will always pass the check um and if we just look more generally we can calculate the probability that a a proposed a check

will pass by taking effective balance divided by Max um effective balance so we can also then see this I thought it's quite um helpful to just do this as a um show this on a graph and I've picked a few sort of uh consolidations of validators so having different um Consolidated by two two or five or 10 or whatever um validators into one and the probability of them passing the test so it kind of varies from 0.16 for a 32 e validator to one for a um a fully Consolidated validator which is um

248 so the ones that I'm using in the example um are basically the ones that I've plotted there so um with the increase in in maximum effective balance we see that the probability of a 32 e validator being selected and passing the proposed check will fall from um what it is currently um if we assume the valid dat set size that I used um it'll go from um basically 1395 * 10- 6 to um right down to um 2.18 um time 10us 8 so when you look at

it it just seems obvious that solo validators would be worse off with such a reduction in passing the proposed check but we also got to remember that if the validator set remains unchanged and all the validators are still 32 eth then all of them will have a pretty small chance of being accepted um so it could be that even that um there were other validators that didn't pass the test and by the time this validator comes along they actually pass the test and we can calculate this probability um so let us then calculate the probability that the validator is chosen not just at the first iteration

but at all subsequent rounds so if we State this a little bit more formally um we're basically looking at the probability that a 32 eth validator um who selected at around I for example means that the previous round so one two through two the previous round I minus one were all unsuccessful and then there was the successful one and so we just calculate that by uh summing over all the possible rounds that this validator may have been selected yes so I mean just simply if a validator selected as the next block proposal in round three then another validator was selected at round one and at round

two and doing this if we sum across all rounds the probability of a solo validator being the next proposal is actually exactly the same as in the previous slide it's also 1395 * 10 min-6 however I was thinking that you know when EIP 7251 goes live it's kind of pretty unlikely that the validator set um would remain exactly the same because um it might be interesting then to look at a bit more um of a realistic scenario so before we look at the scenario there any questions if not let's dive in so let's

look an example and what I I did is I said um I actually asked um vitalic and it's amazing he responded and he um to ask him you know if he could group the type of stakers that participate in um in ethereum what sort of categories would he put them in and he suggested um that there'd be um a group of that we could turn we could call um small scale solo validators who will have typically 32 to a few 100 e then large scale individual validators and there are some that have got uh more run more than a thousand

validators um and then there large scale institutional solo validators too that comp where companies stake their own eth um and then we've got centralized staking pools and semi decentralized taking pools such as Rocket pool and Lio so if we assume um up at the top you'll see 716 800 active validators and we split them um against these different Staker categories and each category I mean I just made this all up just to for for an example to work with so and um each each category we say has got a different sort

of consolidation strategy uh and I used um a few different combinations so had some single um um validators single stake validators then two-fold Val twofolds validat is fivefold 10-fold and 30 fold and then the maximum where someone has or where people have decided on um the maximum so 64 um lots of 32 e and then um as I said for each of those staking categories we're assuming that they have the same sort of strategy and in the diagram you can see the proportion of uh validators that they have for each of the validator types so then um it shows

just in the calculation how many um validators then and then you can see um in the sort of turquoisey uh color that the consolidation set has now gone from uh 716 800 um to 3 128,129 to play around with um these values and see how how the probabilities work out um so before I describe the basy network model uh we built for a

proposal selection I thought I'd just give a Depending on time how we going for time I think it's okay I'll just give a quick overview of what a Basia network is I know that Joann's probably heard this many times and probably also Peter so anyway please bear with me um so so basically uh it's what we call a direct directed ayylic graph so as you can see there you've got nodes are those the round round things there are nodes and then you've got directed edges in other words um you don't have any Loops um so you just have the um the the edges that connect the the nodes in the group uh

and it's a type of probalistic graphical model um and I will sort of demonstrate where they fit in um and then we'll have a look at you know why is it a basian network and we'll look at conditional probability tables because that is why it's essentially considered to be basian um and also talk about two important strategies um statistical properties that they have so people often mentioned that a basy network is a probalistic graphical model so just taking a quick step back uh to get some context of where BN fit in within the framework of probabilistic graphical models so they can basically be broken down into those

that have directed edges as um the Basin Network I just showed um sort of between the variables in the graph and those that have undirected um edges such as markof um networks or perhaps better known as markof random Fields um and then we also have hybrid um graphical models and they hybrid in the sense that they include both directed and um undirected um edges or links uh between the variables um and like a chain graph would be an example of that so the um the basy networks obviously fall under the uh directed graphical models and then we've got a couple of specializations of a Basia Network such

as um a dynamic Basia Network and an object oriented basy Network and the latter is the approach um that we will use so so um who is BAS he's a he was born in 17002 his father was one of the first six publicly ordained nonconformist ministers in England um and interestingly for him because the practice with non-conformist ministers at the time was that baz was educated privately so there speculation that he was tuted by an eminent French mathematician Abraham de I don't know how you pronounce it he's French and he had to flee France due to persecution of Protestants and this guy was also friends with Edmund hady and Isaac

Newton so pretty interesting times he lived in um the thing I just find quite bizarre um is that Abram Deo he actually correctly calculated the date of his death when I read more about it I think he kind of almost woed himself into you know following his theory anyway Thomas Bay became an ordained minister and then Richard Price was a friend of uh Reverend Thomas Bay and he published his work in baz's work in 1763 uh two years after his death actually and he presented it to the Royal Society of London and it was called an essay towards solving a problem in the doctrine of chances and it's also known um more generally as a

method to solve the problem of um inverse equations and um inverse probabilities and basically this is the um base theorem as we all know and love and the central idea of base theem is we start with a prior belief about the probability of a hypothesis so of uh the probability a and then we revise our belief to take new evidence um B which is information or data into account which and that may confirm or contradict the hypothesis and we therefore look at the probability of this data given that the event or the hypothesis is true and we call this the lik Hood we then divide

by the probability of the data to produce the posterior um belief and this simple equation provides us with very intuitive way of dealing with probabilities and we can reframe questions of chance update probabilities uh with data and evidence the other thing that I mentioned is the conditional probability table uh which is uh also sometimes referred to as a node probability table so for the node uh in our model that you'll see shortly is um the proposal for the next block so we've got two parent nodes validated type selected as next candidate and propose a check so looking at the table you can see if the validator was not selected then whether

or not the proposer check passed or not is immaterial it cannot be the next proposer so the only time it is the next proposer is when the validator is selected and it passes the test so for the statistical properties um we'll first look at the mark of properties so the first order Mark of assumption is that if we know the present then the past has no influence on the future and related to The Mark of property is this concept of a mark of um blanket so a node um a node's mark of blanket includes all its parents its children and its children's parents and the interesting thing is that it can be shown that a node is is

conditionally independent of all other nodes given values for the nodes in its markof blanket so for example in this little diagram if we look at node C2 there um you can see that the parents are C3 C4 and C6 uh C2 has only got one child which is the outcome of interest and the parents of that child is uh C7 so basically these six nodes then would be the mark of blanket for node 62 so the only um other interesting statistical probability property is a desparation or directional

separation um and basically it's saying that if two nodes are D separated given a third node then they are A and B are conditionally independent of c and this particular property allows us to check whether the dependency among the V variables in mbn Mak sense and to also validate um the structure now um the two properties that I mentioned um which is really important um basically um helps us to make uh propagating probabilities through basy networks a lot more tractable so the classical way of computing a joint probability is given by that first

equation there um and and um then but then um we can using desparation and the mark of property we can simplify it into the the equation you see below so um and that is commonly known as the BN rule so basically the joint probability then is expressed as simply the product of the probabilities of the nodes uh given their parents then um objectoriented basing Nets which is what we'll use um I won't go into that too much but it just it really gives you away to to reduce some clutter in your um if you've got a a biggish um basy Network it just basically sort of reduces clutter so

you've got private nodes that are just visible to your little model you've got input nodes that are like placeholders for other nodes to to link to and you've got output nodes we just make them visible um to to other models to use so any questions I think I saw um did I see something in the chat Peter uh no that was Sly talking about um from before the basian um introduction about um talking about how how long it would take to go around a network trying to find the validator if

there are 76,000 of them okay yeah hopefully that's been answered okay so um let's dive into the object-oriented basy Network that we created um so the one on the left is the object oriented Bas Network you can see it's quite a nice simple little one and that box in the middle is expanded to the right and that really just um is a way to calculate the probabilities so this table performs calculations for the various validat types uh to become the next proposed so I won't um spend too much time on that um so now that we've got our um

model we were able to sort of basically run some scenarios through it so if initially we just don't do anything we just run the model we see as we saw in that earlier sort of diagram that I I showed that the valid dator set will reduce to 200 32 9 UM 810 from 716 800 and um the the proportion of validators that will pass the proposed test is 20.8% and the marginal probability across the various validator types in the validator set of being selected as the first candidate is

26.4% being the the um proposal of the next block is only 0.69% and if you cast your mind back to that um conditional probability I showed you uh you can see kind of a reason why because um the only time that you actually get through is if you are chosen and you pass the test um yeah then uh we ran another scenario so looking at so let's assume that um we disregard the Staker um sort of strategies um we enter evidence and so the way you enter evidence um there's several ways but the one where you just

say 100% I've observed this what are the consequences and it probates the probabilities through the BN um is say say all of the validators in the validator set are 64 e so they've just doubled up on each validator there um and you can see the validator set obviously has been reduced to pretty much half of what it was um and then clearly the probability that 64 e validate is chosen will be 100% because that's what you're doing um and the the probability for a 64 e validator passing the check is

3.12% and being the proposal for the next blockers uh 3.12% um then I ran another scenario and I thought well right let's let's look at the maximum contraction you could have on a validator set um and then so every validator we have is the 64 e validator and that reduces the validator said right down to only 11,200 um and then you can see from um the bottom there that um the probability of passing the check of of being the proposer for the next block is 100% as we expected because the equivalent

scenario would have been um a 32 e validator currently the maximum effective balance is 32 e so if you select it you'll definitely be the next proposer so and then um I thought well let's look at you know your your validator set consists only of small scale validators and um in that example um basically they mainly Consolidated into a two-fold um validators so 64 e or they left them a single um validators um but a small number compounded to 160 e so

five times um five times the uh 32 e and here the valid dat set had a pretty good reduction too to 458,000 um and the proportion expected to pass a proposed test is uh 3.44 and the marginal probability across the three validator types in the validator set of being selected as the first candidate is 38.757195 build the model and we chose them

specifically um because they've got good objectoriented um capability and um they very kindly offered uh to host the model for Us online um so uh there's a link there as well and I if you want I can click on it um and you're free to play around with it and you can run through the scenarios I've just run through um and then to the right is the blog post that I wrote basically on the pretty much on the um information that I've presented today so we can try and yep so this is the uh online model

if you click on that um it's basically um hosted on their demo site and um an one of the examples in their demo so this is live and um you can sort of play around with it ands see that looked a bit funny there so probably forgot your um person doing it is in um Denmark y it's gone very up what did they say the curse of um presenting live um yes so if we say the one we just

did small scale validator and you can see it then changes it to to red and you can look there at um what that is um you can reset it um you can see here that is the the number we started with and that is the adjusted total so they hardcoded in um for for this model but yeah it just gives you if you do want to play around with it and a link to the post as well um and then basically some of the references here um so there's also a link to the GitHub so

um we've got a public giab prepo uh with just some of the stuff in there uh I plan to add a bit more to it but um you welcome to play around with it add do it all Sandra um we're only seeing the model selection model proposer selection web page yep okay um right so so basically there's a there's a get up link and so um there a few few modules there like the negative binomial and proposal selection I think I I still need to add a few more to

it um cuz they they sort of the generation of the random bites from the spec uh Roberto is now on the call help me with and uh I still need to add that up that was done in Python uh yep and then just uh ackowledgements um that as I said previously it was joint work with krie um Anders and Patrick and it was also partly funded by the ethereum foundation academic Grant um and just want to acknowledge that the um Basia Network model we developed is being hosted by hgen expert and we had a review and feedback from many of our

colleagues at consensus and um collaborators including Ben Edington at the time from consensus he's um now with optimism I think and barab mono Mike Neer Mikel um Kellan and Roberto and then um I think uh we're going to be um handing over to Peter with his very creative merch store yeah which is back online yeah the linkage between um YouTube and fourth wall has finally been resorted out so it's now easy again to um click and um buy stuff um if you do

so wish next slide yes and so we've got um Alex Pruden coming along to talk about his thoughts um on the economics of zero knowledge on ethereum so talking about I think zero knowledge rollups and other zero knowledge systems and just how does it work how should you think about it so I think that will actually be a super interesting talk um the Austin is coming along um a little bit after that to talk about EX rc20 and it's funny when this talk was first proposed I was uh yeah it sounds interesting a novel but I'm not too sure but you know right let's run with it and

then since then some cross chain experts and myself at immutable have talked about oh yeah we really should have a look at xc20 and I said have we got a talk coming up for you um okay layer Z V2 um I've got to re-engage with the speaker for that because the person who was going to deliver the talk no longer works for zero layer zero they've moved on Happy circumstances and everything but I think we're going to have the CTO give that talk and then in June I'm going to give a talk about random number generation on evm based blockchains and rollups and uh the complexities of it and joys of trying to actually do it so

that you know if you were you had a million dollars at stake how would you really do this um and so I think it it's really interesting and particularly um so I'm given I'm coming from a mutable where we're developing a games platform and you know people want to be able to say issue a random nft be able to show that it was really um not biased by the game or someone else there's no one attacking you trying to um D you so I think it's um that should be interesting um yeah let's look at the next one yeah so if you're here today um there is a YouTube channel and if you're on YouTube and you think ah someone should have asked Sandra this really tricky question

um then you know come to Future Talks by um coming to the Meetup and um you can um find out and go to the Meetup link there is a slack workspace and for some talks there's example code as well and I think that's about it um so Sandra thank you very much um for a great talk um yeah it's so do you think that EIP or ERC no it's an EIP isn't it because it's yeah because it's core protocol is that do you think it's going to get up and you know when do you which Fork is it going to land in do you think um it seems to be slated for the electr heart fork and I think um there's

there's a lot of commitment there to make it happen there are still some um minor I think they're fairly minor issues to sort but there are still a few concerns and edge cases that need to be looked at um I know that I I intend doing a bit more um Research into um in into that um but yeah it it does look promising um but it does uh this what appeared to be a very simple change while it's simple to communicate but it touches so much of the code base um and I think that's uh that's been the concern and that's why a lot of testing needs to

happen and a lot of eyes on uh on the changes sure does anyone have some more questions for Sandra uh yeah I had a question um so what uh what future directions do you see stemming from the work that you've done so far um I don't know if it's self-contained within um the I mean the only future direction is sort of writing up what we've done but I I'm trying to think as far as the modeling goes um it's sort of specific to to propose a selection

so um it would really be um I suppose doing similar modeling to on other issues that that are around or looking at different angles but yeah if I may but in on that point um sure so um Sandra because it's very recent work Sandra hasn't mentioned it quite rightly because it's really my work um sort of it's I'm I'm a mathematical Economist I'm sure nobody knows me here um and uh so I'm very much about the you know my Approach is theorem or Lemma proof make predictions that are theoretical very much very different to

what we've seen today obviously right so um I do have preliminary results um which would give us predictions on on on what would what will happen under EIP 7251 and my I mean it's available I mean I think it's in the private repo instead of on the public one I guess but uh I mean basically you'll get full consolidation and it's an optimal strategy to to spread your as a Staker to spread your wealth or your stake across all validators to to maximize your probability because I mean what what what Sandra spoke of today is the probability of a validator being selected but we haven't spoke about what's the probability because what it's

the Staker we ultimately care about as economists right so if you put your economics hat on what what what you're going to care about is what do stakers do stakers can choose how many validators they're going to participate in uh uh stakers can choose how much uh how how you basically yeah how much to stake obviously but I mean but but that that the if they can maximize their probability of being selected or being in a winning being a proposer right just specific to the proposer if you ignore all the other stuff like the slashing and all this other stuff that's going on which was not discussed today but Sandra's working on that I believe uh if

you just focus on proposed selection um it's fairly easy to see that I can increase my probability a Staker by by diversifying across um multiple validators and that that works because of the linearity that Sandra highlighted today so you get this linearity in the probability of being selected so then you can use that to show this is the result that I've got that you're better off spreading yourself in so I mean my predictions are that if you're a it will not be good for solo validators right I mean um because I'd be better off spreading myself off across many validators if I'm a solo Staker so there won't be many solo

stakers because I can spread myself across many validators and increase my probability of being uh selected as a as a winning validator and it won't affect my return yeah um so so and this this is you specific to the current EIP um and and moreover validators then then you see you might want to which validators do I want to participate in yeah that was the other so stakers cannot only choose how many it's which part which validators do I want to join it's we're talking about coalitional Game Theory here right so I'm going to join the validator I'd be better off joining the validators that guarantee me

the highest probability of being selected to be a proposer that's fairly easy to see as well um because I want to if I you know I I want to make sure that if I'm at the front of the queue I'm going to win that that that um shuffling process that Sandra so clearly described earlier um you know if I want to make sure that if I'm at the front of the quebe I want to be as large as possible as a I want to join the validator that's as large as possible to ensure that we don't go further down that complex chain of probability events the the biggest win one wins but you don't want to be at the maximum why I I'll put the question to you I mean you can sort of see that

because of the compounding right the compounding means that you want a little bit of Headroom and then you can use that you basically you clear the you keep on clearing a little bit of uh leaving a bit of Headroom to allow for compounding of your stake um that that's at the validator level so if you once you allow for fractional because there wasn't much discussion about fractional ownership of validators I think once you allow for fractional ownership uh my my predictions are that you'll get an awful lot of spreading across validators by stakers um and you'll get very large validators so near the maximum so this it's it's sort of like

a purely on the basis of proposal selection economics not talking about punishments or or or or or or slashings or any other factors if you just focus you know Seterus parabis assumptions for anyone who knows about economics you assume everything else remains equal you focus on just this one area this proposed selection economics yeah so I mean Sandra is clearly a fantastic statistician and I've learned so much from her um and um I'm I'm The Economist in the house I have to put my two cents in so um yeah okay I'm done I'll step off the soap box now and it back when do you think when do you think that this this

thing you're working on will be publicly available uh so um we're we're aiming for a deadline of the the thing that I'm talking about yes yeah yeah yeah okay so um there's a 16th of April deadline I believe right Sandra but for a conference right oh yeah Roberto got two papers that he's submitting to the same conference so oh we so try and make that deadline and and get all the proofs ready by then okay okay thanks that was actually really interesting Patrick because I naturally assumed that we'd all suddenly have 248 e validators everywhere but you have

said essentially we're going to end up with I don't know 2020 eth validators something like that and and but yes a very few solo St because it's obviously going to be I think that's the other sort of you want to spread yourself across as many as possible so basically you've got a probability of one of being yeah in in the next validator um proposer know I mean it's super interesting like because it's one thing to to think about but then you know how does you actually do do the application you know if you're actually going to run a validator not that I've got 248 eth to put into a valid yeah it becomes a matching it becomes a matching problem for them

right they want to try and match so that they can maximize the size or almost maximize near maximize the size of the validator I think that would be the game yeah wow so there you go Sandra I've but yeah so what anyway it it sounds interesting I I've I know I've learned a ton in this talk Sandra and um thank you for your your act additional thoughts there Patrick because also just helped to crystallize some things um right thanks to Sandra she's she's been a wonderful organizer wonderful to work with I recommend it to everybody um just a super manager of the whole thing and

and got everything done thanks a lot and and everyone else it's been a pleasure working with you forward to the results of yeah exciting MH well right with that um thank you everyone thank you again Sandra and see you all again in two weeks time awesome bye everyone bye