All Core Devs - Consensus #97

Transcript

foreign [Music] foreign

[Music] [Music]

Tim Beiko: welcome to consensus layer called number 97. uh Danny's out this week so um I'll be the one uh facilitating this we have quite a few things on the agenda I think this is the first CEO call since

uh the post merge one um lots of stuff around withdrawals and then getting to this conversation around uh the engine API and the the block value that we we sort of didn't have time for in aqua Dev um and finally uh there were a couple other topics uh so the rebase of the 4844 spec on capella um the proposal for historical batches um some follow-up of the Gordy discussions and a way we can potentially fix that on the CL side uh and then some updates from Mev boost and I think that should uh cover it um

yes I'm just covering for Danny being quote unquote out for a long time um I believe like client saw Danny in person so hopefully he's still around um okay I guess at the kick us off uh so there's two there's two PR's on the withdrawal side uh that we've been discussing uh there was the one about moving withdrawals through a single queue by Danny um tons of discussions on that and then POTUS added or opened a new draft PR this week um which removes the queue all together and it seemed like there was some

support on that but then also a couple uh a couple of pretty significant comments in the past uh day or so um and POTUS could not make it on the call um is there anyone who wants to just kind of share quickly the context and and where things are at on that PR

oud yes yes yep can you hear me

Tim Beiko: yes we can

Terence Tsao: yeah sorry yeah so I guess POTUS can make it I thought he could make it but yeah I guess I could give a high level summary on like Potter's approach So pldr currently two-person withdrawal there's three EPO processing there's two Loops one for full withdraw and one for

partial withdrawal and this is not ideal for both like complexity and performance perspective and but what one thing that's cute about this is that food withdrawal is truly differently than partial withdraw so therefore it has some variety and some people really like this and this is also easier to test for the sweat test perspective because now you have full and partial and because they're separate right and then they opened up here that's 3042 and this was born to withdraw into a single function single pipeline therefore if it's slightly simple to implement and then but this has a downside that the partial and full withdrawal they are treated equal so

this shift the fairness under certain um circumstances and therefore who we draw may take longer and this is also like harder to write spare tests because everything is under one Loop and client may have to implement some some caches around there but those are client implementations so uh POTUS after seeing these photos actually came up with something else because he felt that well maybe we don't need the queue right so we don't need a queue therefore this is actually much simpler from the spec and client limitation and then you can remove constants such as that mass with drugs per Epoch and then also match uh mats with drug huge image he also reduce

pressure on like equal processing so and then also the lookup for funding withdrawals in a blog for the happy case of small and fast since every since the block limit is quite small this also has the same uh argument versus the 1q approach such that the full and partial are 3D equal quality but that can be further extended or improve for example like you can use some ratio system that you can give variety of over like full draw um there are some concerns such as that well like if the network has like inactivity over five days validated JS slash before processing partial

withdrawal but and then with those concerns it could be more expensive but generally I guess from the commands I'm seeing from other from other client teams it doesn't seem too bad so yeah it seems to me like most of the teams have like a proof um on this PR and this seems like a way to go so yeah I'm curious if I miss anything people feel free to chime in and please let us know like how we can proceed further

Tim Beiko: and I I think there was oh sorry Mary's yeah go ahead

Marius van der Wijden: so I have I really have no idea about this um but one thing that I uh had a question about when reading is with the with drug you the order of everything is under consensus right with this new approach is the order of the of the of the like with every every no deterministically come to the same order or can you like I don't know prioritize your own withdrawals over others or just say I didn't have any withdrawals and um kind of like a sense of

withdrawals or whatever

Paul Hauner: it's fully deterministic you can't censor

perfect

Tim Beiko: um and yeah like reading uh I guess skimming the pr and and the Discord in the past day it seems like pretty much all client teams support this um but is there someone who opposes potus's proposal and thinks uh Danny's like the 3042 would be a better way to go

foreign

Micah Zoltu: description of how withdrawal order is determined when there are more withdrawals they can then can fit in a block those of us that are familiar intimately familiar with this

dapplion: in the new approach or the

Quran that and in the

Micah Zoltu: new approach

dapplion: so do you have 100 you have a pointer that's persisted in the state and this would keep looping and the point double process withdrawals up to the capacity of the block then it will stop and that would be persisted on the states and that continues on the next on the next

block

Micah Zoltu: so so is there still a withdrawal Q it's

just in a different place then what you're describing sounds like

it will drop you

dapplion: so I would think in terms of of a pointer that Loops over the states and just stops when there is no more block space for withdrawals right

Tim Beiko: and so the thing is you don't need to store the full Q you just need to store that pointer is that correct and this is why it's simpler

dapplion: yeah so the way it was looking before is if at specific Epoch if there is a a large amount of withdrawals that would be cute by order of index from less to highest and that would be the cute um as the emperor processes through the

blocks here it's just if we start we start at e at index 0 if we can process say 120 20 indexes worth of withdrawals then it will stop and then at the next block it will continue after the point that it has passed if index one becomes available it will need to wait for this pointer to Loop over the set to be included

Micah Zoltu: so let's say 100 people let's say we have room for 10 withdrawals in a block and 100 people all the same time decide just miraculously they all simultaneously say I want to withdraw right now so you have 100 people that want to draw but only 10 can fit in the

block so presumably those hundred people need to line up in some way or somehow be sorted right are we still recording those 100 people like or the night only 10 of them get in is just the first come first serve another 90 try again on the next block and race each other

dapplion: so it's a first come first served by index provided that that you are after The Pointer

Micah Zoltu: so so all 100 people would register themselves as wanting to withdraw and that would still happen is that correct

Tim Beiko: well it depends on your validator index

Potuz: can I can I can I probably increase here a little bit so so there might be a misconception uh you do not request to

withdraw you request to exit a validator I guess that's what you're so all excellent validator automatically will be available for withdrawal so what we're gonna do is you start today your pointer was pointing to validator numbers 100 and you're gonna check 100 is available to withdraw okay good then we put it in a block we go to 101 is this guy available to be thrown no okay so we go to 102 until we finish like getting the 16 ones that we that we can put in a block and then we continue after in the next block with the next indices so it doesn't matter when you actually are out for withdrawal it just only matters what's your validator index

Micah Zoltu: and I'm guessing that we the clients

don't need to actually Loop through all 400 000 validators there's some easy way to skip over

most you

Potuz: you will so there's a very uh nasty case which is that no one wants to withdraw so no one wants to take out all of their teeth and also the whole network has been leaking for the last five days so in this situation then you're gonna go over the whole validator set and you're not gonna find a single withdrawal

Mikhail Kalinin: I think if you're also looking and there are just a few people that are willing to withdraw it's also like a kind of nasty case because he might not meet them like scanning for say hundred thousand values

and that that those nasty edge cases aren't so bad the clients will fall over

Micah Zoltu: like you can still handle that within 12 seconds no problem

Potuz: yeah we can handle those so we are doing anyways some pool validator set loop uh in four choice on every block and last time I timed it it was five milliseconds

Micah Zoltu: okay there's been talk in the past about wanting to allow people to exit without withdrawing would this make that significantly harder could we decide to implement it in the future

Potuz: so what do you mean one of our

withdrawal methods will automatically withdraw you if you have a neat one withdrawal address

Micah Zoltu: yeah I think that the idea with X without withdrawal is that if you are no if you know you're going to have an outage for some amount of time like let's say I'm going on vacation I'm going to turn my computer off for three weeks I want to exit but I don't want to go through all withdrawal process because as soon as I get back I'm going to rejoin right away it is to make it so users again this is just a proposal this isn't final or anything but the idea was is that someone might want to exit leaving their stake on the beaker chain and then when they return they would re-enter without having to go back to the execution layer and then back to the beacon chain uh

would would this change make it so such a feature is harder to implement should we decide to implement such a feature

Potuz: not going to be harder or easier uh there are research projects about putting validators to sleep and uh yeah so nothing is set uh this proposal is not going to make it any higher harder or any easier most probably we're going to have if we want to implement that we're going to have to have a different figure instead of exit it but sort of

clip invalidated okay

Gajinder Singh: yeah I think it should be easy to skip the validator to pushing in the withdrawal queue if you have that flag of sleeping set for a particular

valid results

Tim Beiko: so does anyone have an objection that protest this proposal

Alex Stokes: so this is not an objection and if someone has one they should chime in but there was like one kind of open question on the pr which was if we want to bound how much you look per block or per slot uh I don't know potos do you have any thoughts about that uh yeah so uh we uh perhaps I'm I'm not counting correctly but it's I think that most of us would not object that and some people really wanted this so I think it's probably a good idea to add a

bound uh my only objection to to the bound is that I think it should be very large because it should give us enough time so that holes in the validator registry given by validators that actually exited do not become so uh so many that we're gonna be proposing blogs without all uh without all withdrawals available so I think this constant if we put it which I'm not opposed to it should be of the order of 2 to the 17 so instead of like a hundred thousand validators or something like this and but I think everyone agrees that this there should be a bound to have a constant boundaries better than having this ever increasing number of

validators that uh we're going to continue depositing

Potuz: yeah I think that makes a lot of sense so perhaps in like next day or two we can work on that and yeah it sounds like there's pretty complete agreement on 3068

dapplion: so I I want to add I did a proposal on the pr that had bugs but it should be fine with a bit more complex code to have both a no queue approach Plus no wait for full withdrawals so extend approach of photos to just have a double pointer and loop Loop for full and partial independently I'm not sure if that's support for that

but that would be like the best of

both worlds

Alex Stokes: does anyone feel strongly enough about prioritizing full withdrawals that we would add more state to the beacon state

dapplion: so it would add four bytes and it's not it's not exactly prioritizing it's just allowing them to be processed faster

Potuz: so the problem with I think if we can approach is that it makes the full the full loop on every block if there are no so we do expect times where people are not with fully withdrawing and are only

partially withdrawing and I mean this this should be the common scenario and uh this proposal will make it so that we run the full loop on every single block uh it's not something that is particularly bad it's just that it's just more complex and it has this full loop on every single block

dapplion: I mean you don't really have to do that so if you at at every Epoch do one Loop and pre-compute the list of potential with the wings that should be sufficient I did a demo implementation two days ago and it's not complicated and for the normal cases it should be extremely light and you have this cache attached to the state um you can have either being forking or not each one has different trade-offs but

that easily prevents having the loop having to loop on every block

foreign

Sean Anderson: is that it's probably worth prioritizing for withdrawals if it's like not too much additional complexity just because otherwise in the normal case I think if there aren't many full withdrawals you'd be waiting like around two days or so because almost over on the network will have partial withdrawals pretty constantly

dapplion: so I hey I think it's important to

clarify that there is no presentation here unless there is a much slash event because the the churn is really strict so uh unless there is a a bump at the start for people that have exited before we activate Cabela um parcel withdrawals will take the pass majority of withdrawal block space so it's just a matter that the the approach of having a the partial pointer affecting the with the full pointer it will just add an extra delay but I don't really buy the polarization argument

Alex Stokes: so then why would we make this change I thought it was to prioritize full

of trolls

dapplion: so it's not really too great that is to not add a delay an artificial delay on them

Alex Stokes: okay well I'll just go with Michael was saying in the chat just so even if it's just like only four bytes it's like a whole new field and it's more to test and so like generally I think we need like a very good reasoning to include stuff uh in the beacon state right because like we'll have to maintain it forever and test it forever so what I would suggest is we get 3068 in a good place and then you know you could open another PR to that once that's together uh but yeah personally I think we should just keep it as simple as possible

Micah Zoltu: can we add the the second pointer

they're referring to can we add it later just as easily as we can today or is there some significant advantage to adding

it up front

dapplion: no that could be another later and I I agree I would vouch for Simplicity it's just that we we can avoid these ux penalty so I think we should try to but yeah I agree if it's complex we uh I will be totally fine not doing that in my recommendation

Micah Zoltu: then if this can be added later just these days now the mirror Foundation would be uh do this the simplest thing first and then have it live for at least one fork see what the actual behavior on mainnet is like and see if people are complaining see what the delays actually are like once

we clear out the historic withdrawal queue and then if it does seem to be a very significant problem we can add it in a future hardcore we'll do my vote

Tim Beiko: does anyone oppose that cool okay so I I think we have consensus we're gonna keep working uh on polishing potus's PR so uh that's 3068 um and that sort of supersedes um 3042 um which was which was kind of heavily discussed before

um and I suspect in the next two weeks or so we should be able to have something that's quite final and and potentially emerge into the spec um yeah so we can keep uh keep making progress on the withdrawal front anything else on those two PRS

Alex Stokes: just one thing to chime in here and I think there's been a lot of discussion across both of them but the one thing with this approach is just making sure there's not like you know undo extra load if there's reworks so you know rather than going at the epoch we're now basically moving the processing into a per block setting and that's fine but you know if there's like some crazy forking situation does this like put

more cash pressure or something like that uh that we don't expect

Potuz: so yeah so so the way the way I'm thinking of implementing this I'm gonna do this today I think it's zero optimization it's just run the loop uh whenever we update that uh and I think this this is immediately reorg resistant because you're just gonna compute it again on a rear and there's essentially no load um because we're doing this and this Loop this full loop anyways on Fortress once we realize that we're doing this cool loop anyway in Fortress then I I didn't mind any of these implementations because all of them don't suffer much uh of uh of a performance issue that was my

first concern and that's why 3042 I think with all as well but then it turned out that it's really not that bad to do that for Loop

Alex Stokes: when you say full loop you mean a full loop over the entire validator set

Potuz: yeah so and we're proposing to put to add this bound but even if we didn't have this bound it would be fine to just computed it to just compute it uh on a reorg immediately again there's no need to Cache here anything we would need to cash if we had something like uh like lions proposal to have like the list of uh fully withdrawal indices uh per Epoch but uh if we don't need to Cache

anything I think it's fine just recomputing it you only compute up to 16 uh 16 withdrawals per block and that's it right

so

Gajinder Singh: the point you know that is to notice that uh the worst case scenario is when we do the full loop most of the times when most of the people would have set their uh uh their payout address I think we we might just end up doing in 30 or 40 props at best I mean at worst so it won't really be a full loop anyway

Potuz: yeah so so typically the loop is going to be only the next 16 validators except a few that might be exited but the

problem happens if the full network has done already a loop so everyone did a partial withdrawal because with this proposal with any proposal you all of your validators will be with 32 with uh and not much more so if you spend like a week leaking then all of the validators will be below 32e none of them will be

withdrawable

Alex Stokes: and then in that situation you're gonna do this look on every block and you're still saying like even in that situation from your benchmarks it's not an issue

so either way I think you should if we put this bound at 100 100K right I think yeah it's in the micro seconds per Loop right

Alex Stokes: so yeah I mean I think we go with what Tim said this is

the direction but also just everyone listening as you're implementing this just think about this particular topic uh on that topic

Jacek Sieka: one more question I haven't really seen the proposal yet but so excuse me ignorance but um the effective balance how how much does that change because that's actually when the effective balance changes that actually a little bit more expensive because then we have to Hash three root things uh valid errors in particular and that's as everybody knows one of the bigger pain points performance wise

Potuz: but so there are two kinds of withdrawals one of them is already on

exited validators and the balance is going to become zero and the other one is removing all of the excess from the effective balance so the effective balance is not going to change it's going to continue being the max effective balance

Jacek Sieka: all right great thanks

Gajinder Singh: I have yeah I think we also wanted something to have to have to leave a little bit of margin so that you know we don't really drop uh the max the effective balance even if for example there are few missed Restorations uh so I'm pretty sure whether people feel strongly about it

Potuz: but I think it's not that's not really the reason right you cannot miss your effective balance by just not missing attestations

yeah the histories takes care of that you'd have to drop down to 31.75 balance before your effective balance drop to 31. so you've got 0.25 e margin

dapplion: so if I understand the comment is that whenever someone withdrawals after withdrawing it will trigger a change from the process effective balance updates function is that intentional

Potuz: no why why would that happen

dapplion: so process effective balance updates

what it does is it enumerates state DOT validators I need the balance has navigated sufficiently from effectivity balance then that would be updated and that's what's going to happen when you withdraw

Potuz: why would that happen your validator never so it changes your balance from all to zero and that's gonna happen on all four withdrawals anyways and on partial with robots is not going to change your effective balance because yeah sorry I'm I'm talking only about full okay but then on full withdrawals these validators are already exited so there's no problem that uh that the balance becomes zero

dapplion: right but that's that's going to incur

extra hashing but I guess that's fine

Mikhail Kalinin: question to what is um are you suggesting to have this limitation on the maximum number of scanned valid errors in in the spec like a hundred thousand as you mentioned

Potuz: yeah it's just a constant right so it's going to be some some configuration constant some preset yeah yeah right yeah

just and just yeah

Mikhail Kalinin: it's not in this in the uh PR yet right

Potuz: it's not in the pr uh I wanted to see if there was consensus it seems that there is consensus uh but someone raised now the issue of like the minimum scheme amount and I'm not sure if Jim is here but Jim

has a good point I think it's a valid point that if withdrawals are too cheap then it becomes expensive to produce proofs for them because the withdrawal itself doesn't pay gas it doesn't pay the gas of the proof so that's the actual reason that Jim is proposing to have a minimum scheme amount I am very skeptical in putting such a constant because uh this depends on the price of it so if we put a constant now it might become a lot in a couple of years and then we need to change it and that requires a hard work just to change a silly constant

Alex Stokes: yeah again I think from a Simplicity perspective I think we leave that bit out and if you need to you can batch your proofing right at the

L

Gajinder Singh: I just want to bring to attention uh that in consensus specs there is a test case in which uh the validate the validator is withdrawing as well as it's present in the current sync committee so I in the consensus group I have sort of mentioned the two tests and maybe those can be rectified

Tim Beiko: okay anything else on the withdrawal PR um Micah I don't know

you can't trigger I guess if your balance is you're going to be automatically partially withdrawn every block if your balance is above 32 8 so I don't know

that oh I missed that

Tim Beiko: yeah I didn't realize this was fully automated okay yeah so we are dossing the queue ourselves in a way and okay with that yeah apparently yes um okay so the next thing is kind of related uh Alex you had uh I don't know if it's your PR actually would you yeah your PR uh about adding withdrawals as part of the engine API

um yeah do you want to get some quick context on that

Alex Stokes: sure yeah okay yeah so Tim just linked it in the chat it's very helpful so uh there shouldn't be anything here other than uh silence because I think this has been reviewed um basically it's just adding the extensions to the engine API to support withdrawals and yeah okay it looks like they're just a comment by like clients but otherwise uh uh yeah I will address that and then basically I just wanted to give everyone one more chance to say you know we should change this or we should hold on it otherwise I'll go ahead and merge it and this piece will be subtle so does anyone have any additional feedback on

us

Gajinder Singh: I have sort of used it implemented it and interrupt with cats and it works fine so thumbs up from my

site

Tim Beiko: okay sweet so um yeah we can go ahead and merge that um next up uh there was this issue about uh adding the block value in the engine API we wanted to discuss this on our core devs uh ran out of time and the idea is that this would help

um validators compare the value of their local block to something they get from an external Builder and there was a bunch of back and forth on the pr about how exactly we should um compute this value and what's the right comparison to have um foreign I don't know I think Terence you were to want to bring it up on all core devs uh do you want to give a quick update on on where we're at uh with this

Terence Tsao: yeah so I just want to say this PR will be really helpful us like the Baseline for censorship by resistance for like just defense against censorship for example we can have a Clive flag they basically Implement a ratio and you can

compare it say like okay if if if the bid from the Builder is half less than my local block value in any case I will select my local blog essentially so I think this definitely opens a lot more Avenue to this type of Defense so I'm basically I really want to see this happen in terms of progress I honestly cannot say much I have been following as well it seems to me yeah it seems to me maybe a little class on that demand or yeah for someone else comment on that

Łukasz Rozmej: in terms of progress I think it's fairly easy to implement in any client uh the

thing is is just uh focusing on the spec what do we want to implement because uh I think that in Gaff it was I think prototyped as only the fees uh will was returned while for example in the old flashbots pack it was the Delta between the balance of accuracy print before block and after block while the um the proposal here was about the does the balance after block so we just need to figure out which one we want to do and that's it so from my opinion the balance after block is the easiest but yeah but it depends on the use case

what do you want to compare right

Alex Stokes: so I think we want the div right not like the complete balance because then you can just directly compare that to bids from remote builders

uh Mikhail here hand it up

Mikhail Kalinin: uh just a quick comment on that um I I feel like yeah I I feel like we have we should have something simple here and it definitely should be compliant with how the beat is computed by Builder if we'll have any fancy logic of computing this beat um and then we will incorporate this

logic into El and then this logic after sometimes it's changed on the Builder's side for whatever reason we'll have to change this uh on the El side as well and this is what just you know um what I would try to prevent from happening um designing this particular thing so we just need I I think that balance uh absolute balance is of is fine uh the diff is also fine but yeah uh something else probably uh be more like more just adding more complexity without any

um game

Gajinder Singh: so I would all right I would

like I would like to add the support provides of opinion on this I think it should be diff because that is the perfect uh Target uh that Builder May converge to and most of the times Builder will also match the diff for example if uh there is there is no uh self-initiated withdrawals or there is no payment into the Builder uh proper Builder account so most of the times it will match and and for the engine API it should always be the perfect fees that that is being paid to the P recipient so maybe over the time with the builder can

find a way to converge to this but 99 of the time it will anyway match

Tim Beiko: um Chris you want to give the perspective from the flashbot side here

Chris Hager: yeah there has been Lively discussion about the block scoring and better to score it as the diff or as the value to payment transaction which seems to more accurately reflect the additional value provided to The Proposal because otherwise transactions to and from The Proposal fee recipient will inflate or deflate this value without any doing From the Block Builders I guess any weight implemented in gef or in the engine API it's fine but there's another discussion going on

about in the build respects what should be the pit value should this also include main pool transactions to the proposal fee recipient and there is some back and forth on this I post a link again here and it's also a question about what is the easiest to as a if we would include a payment proof as part of the bids in the Builder specs which type of proof would be easy to validate inside map boost so my Boost could filter out bits that are not conforming or but that the proofs are not valid if that makes sense so I think in general there's no clear consensus which way to go but it's

an important discussion that we would like to see moving forward

Tim Beiko: um anyone else have comments or touch on this

Łukasz Rozmej: so um my comment here is that I'm not sure if we are talking on the same level because we are I think this discussion is about um consensus clients and its configuration being able to pick a local build block even if it's slightly worse for example but it needs to be able to compare how worse is it than the one from the Mev boost

and just pick up because someone is fine not not receiving small amount of additional fees in terms of providing uncensored blocks right that's that's I think is the final value and you're talking about payment transactions things like that we don't have this concept here at this level

Chris Hager: well but it compares to the bid value that the Builder Network provides as part of a bit so there is like this same relation here because you're going to compare it to this block score that is not yet divided so I agree it's not the core question but it's uh related I just want to bring up the connection

Marius van der Wijden: so one property that I kind of like about um about doing the div is that it's kind of improves like it uh it encourages transactions or like transactions to the Builder or to to to to to the validator in that case um increase the likelihood of the block so if if I have a transaction That Pays 20 East to me uh then this will increase the diff and

um I will be more likely to put this transaction into my blog problem is the other way around because uh gas will always include local transactions first um all of my transactions that decrease my the amount of money I have will negatively impact my score kind of unfairly because the the its transactions and it's not really that I'm losing money because of this because of the block that I sent

Micah Zoltu: right and if if any view boost decides

to use block scoring then it would be using the same strategy as the El and therefore they'd be directly comparable if it mov boost decides to go with or the relays or whatever whoever between the block scoring if they decide to instead go with payment transaction then the situation you described comes into play so Mikhail I think the the problem here if I understand correctly is that if the relays are submitting bids in the form of payment transaction and the El is submitting bids that were the equivalent of a bid in the form of

um fee recipient balance change then the two aren't actually comparable because the reason is that Mario's just mentioned and so either we need to accept they're not we're comparing two things that aren't shouldn't be compared they're basically different units and we just kind of accept that and in some cases we're gonna get it wrong or we do the same thing as the relays are doing in terms of what they're bid bid submission is or the relay is submit a bid and they also submit the thing Bo is doing so they're basically two versions of the bid

Mikhail Kalinin: um my understanding that which is to try to evaluate the value of the block of a local block and compare it to the value

of the uh produced block

Micah Zoltu: uh we don't know the value of the block coming from the relay we only know the bid that we lied we know we know the claim

Mikhail Kalinin: we know the claim right right

Micah Zoltu: but the claim is a different unit the claim is what is the payment let me rephrase that slightly the claim being made is either going to be we claim this the balance of the free recipient increased by this much or the claim might be we claim that the fee recipient received a last transaction in the block that paid them this much and those are two different things and uh the relays and then maybe boosts and all that haven't

decided which one they're going to go with yet and so if they go with the latter one then the claim they're making is not comparable to the balance change of the future recipient in the block

yeah

Mikhail Kalinin: I agree with that but I don't think it should be comparable I mean like the algorithms like the ways of uh evaluating these two beats let's let's call it this way anyway it's different but yeah I think that it's okay I mean it's if if wheeler claims that it pays a proposer this amount of Eid and locally build block is estimated with a higher amount of php2 proposal then yeah that that's it we just need to set the right

algorithm for estimating the local uh value that we can get for

Micah Zoltu: right so the problem is as Mario syndicated there will be situations where the locally built block will underestimate because the user is sending a transaction from the fee recipient address and so therefore their balance decreased over the course of the block

ah yeah see what I mean yeah yeah yeah yeah that's yeah

Micah Zoltu: and that's fine as long as that's fine as long as the bid from Mev boost is of the same form because they're comparable and so if both of them include that transfer then there is an edge case because gas will include local transactions whereas the Builder won't um but you know for the normal cases I don't think that's an issue

Alex Stokes: yeah just to boost where Chris said in the chat uh this conversation has been had in other places and yeah this is like a known sort of uh con to this plan but the general I think like solution here is just say yeah like validators like how often would you have a valuator sort of have a transaction that would decrease their balance when they're also proposing a block and I think it's pretty rare

Lightclient: this is only a problem if we're trying to figure out the balance or the amount receives if you're building locally

Alex Stokes: well in any case I mean I can gossip the transaction I like sense but if yeah but if I'm building

locally

Marius van der Wijden: I think that it's actually a really

important use case um if I'm being censored and I have a validator I can build locally and get my transaction in

Alex Stokes: so how would you do that because then you could just say ignore meth boost entirely and just use the local Pathways and like force it through

Tim Beiko: is there a case maybe with like staking pools or what not like mining pools would uh prioritize their transactions and payouts and whatnot at the top of the block so could you imagine something like um there's a large validator who like when they propose a block they like to

include their transaction first or whatever and so well it's a balanced if it comes oh right it's a balance stiff if it comes from that same account but they could if I guess if this was a yeah they could just use another account or something and sidestep that

Mikhail Kalinin: actually if we rethink on the balance sheet so the balance deep for me is like you have this balance before the block has been executed now the recipient address and you just has another one after that block it has been executed and you you do the it's just the subtraction and calculate and delete the other way is to

pay with all the um fees right that that has been charged to the recipient's address and I think that if we will not account for if we use the former approach uh we will not account for coin-based payments and direct transfers to the peer recipient address which is probably fine because uh this type of payments are usually used by Searchers right and probably Builders to pay um to the to the peer recipient not not something that you can grab from your local landfall which means that probably be the sum of

fees received is is a better approach

Lightclient: yeah I'm not sure what this debate for the balance diff at the local El layer is about like it's already trusted so we don't need to have any kind of proof against things like for me the reason to do the diff is that you can prove it against the state easily

Micah Zoltu: and so you can compare against the Mev boost block so you can decide whether you should include your locally built block or they maybe boost one one can imagine uh maybe boost but you can do this with some of these uh what do you mean

Lightclient: I'm saying you can calculate the total sum of like the tips of the transactions regardless of how many transactions you send from your account and then that's the value of the block to you so let me catch that

go ahead and also stuff

Alex Stokes: I was just asking does some fees include coinbase payments

Micah Zoltu: presumably no there wouldn't be coinbase payments in your own block that you build locally most likely

Alex Stokes: why not

Micah Zoltu: um because your local El isn't doing um Mev extraction and so there's I mean someone could send you a coinbase payment but no one does it's one of

those things like why would someone just be giving the block Builder free money because you're extracting long tail

and EV

Lightclient: and so this is like that you're running a different Builder like I'm talking about like the stock client mechanism and there's there's nothing precluding clients from adding support for tracing all the transactions of the block and adding this to the total sum if they see a coinbase payment there's just no reason to like subtract from that value like something sent from the coinbase

Micah Zoltu: yes I see your argument um it's not unreasonable and it gives a high estimate so if we say if we're assuming stock El that doesn't do any sort of nuv extraction just does you

know Fair ordering for some value Affair then the fees that it gets from transactions is basically all it's going to get in the standard case and that will I think generally be an optimistic estimate and potentially higher than any boost especially if Mev boost is doing um block before and after diff and so that gives a little bit of nudge towards using the yield build block which is nice

Lightclient: I just don't I don't get why your comparing these as if they're like different mechanisms they're both outputting like the value of a block to the validator

Micah Zoltu: oh so again the goal here is to compare

like I built my Yale built a block and I mean boost has given me a bid that means something if those two things are counting different numbers like if if maybe boost is saying the balance after versus the balance before and in that block there was a transfer um away from my account then Meb boost will score the block low so it's going to say Hey you made 1 8 whereas my local El is going to say oh you made 1.28 because I didn't subtract that out I only used some of the fees and so the local El will have a slight Advantage there and therefore you will choose locally Yellow Block instead of the MU boost block even though the Met blue spot may have actually given you more money

Lightclient: I mean sure but I think if we were to use a

state diff then we have to have an invariant for people using enough boost if they can't be sending transactions from their fee recipient during that block

Micah Zoltu: yeah I think your ways is reasonable for the ESL side since we don't need to prove anything

Tim Beiko: so like Beyond discussing just these approaches like what's the best way to like prototype it and get this actually tested where where should like the conversation happened and how do we

get like a prototype of it

Marius van der Wijden: so um and prism already has a prototype I think

Tim Beiko: okay so get that representative are you doing what actually

Marius van der Wijden: I'm Computing the fees the just the normal coinbase fees and uh returning them to prism and prism is

Terence Tsao: from Mario's branch and comparing it and just pick the highest one to go sorry and if the local one's higher we just keep MVB boost

Tim Beiko: got it

Lightclient: um I think we need to like push the conversation forward on the engine API PR

Tim Beiko: yeah okay and but and to be clear there's no PR yet right now all there is is an issue like this RFC

Lightclient: um yeah um oh no this is all boxes versioning get payload to support locally built block value

Tim Beiko: okay I can't find it right now but I can post a link cool okay so yeah let's move the conversation there um okay awesome thank you and um

yeah I don't know

Lightclient: yeah I mean what kind of timeline are people interested in for making something this happen

Marius van der Wijden: as soon as possible

double ASAP triple ASAP

Lightclient: okay I mean yeah so it would be great by next meeting to merge the pr so If people could review it um yeah in the next meeting we can talk about cutting a new release for the engine API and figuring out how to roll it out

Micah Zoltu: we still don't have versioning solved for engine API yet right

Lightclient: no we do

Mikhail Kalinin: we have salt it just need to stack it

out and yeah we can we can have a PR so it will be if if the new methods and the structures following currently specified versioning that we currently have a small piece of version in its back in the engine API so they will be forward compatible with the whole design it's very simple I mean they design like introducing the map that's and how this will be handled by clients um and yeah with respect to this CPN payments um uh we agreed on submitting APR and taken the conversation of what the value what

the computation of this value will be to some other place right or we agreed on that it will be some of your recipients uh payments in the blog unlike node payments just transaction tips

Alex Stokes: I think we just set it on tips I want to make sure that this is not gamable but yeah that's the simplest thing it sounds like for now

Sean Anderson: wait so I thought it was more that in the execution API like you're getting a value with your execution palette or whatever and since this is coming from a trusted node we don't really care about like how it's derived it's like you can uh someone implementing the execution API could do it however they want but it's trusted so

it doesn't matter we don't approve it

Alex Stokes: definitely there's still value in all green to do the same thing

Micah Zoltu: I think the important part of the ingredient I think the most important part of the agreement is that the cl the cl's all assert that we will compare the thing the number the El sends us against the number we get from mbu boost and then if someone wants to run an El that you know fudges their numbers up or down or whatever that's that's on them like they can or someone to build an El that fudges numbers up or down that's fine I think as long as we have standardization on what comparison is being made

Łukasz Rozmej: uh so um are the Seals wanting to also do some kind of wiggle room because it's probably probable that um every boost block will be better but if for example it's like five percent better or ten percent better or whatever maybe the user could set it still would go to the local one for example so if someone is okay with losing like five percent of the of the of the rewards to dust Supply uh censorship resistant for example but if he gets like 200 percent uh tip in this block maybe he still wants to take Mev right

Alex Stokes: yeah I think that makes a lot of sense I

also think that's like a different conversation different PR so this is like the foundation and then from there we can say Okay separately someone is going to have to make that comparison and then you can also like you're saying add in that you know this wiggle room

Gajinder Singh: also ladies are corresponding PR on the Builder specs uh I mean if anyone wants to chime in there as well

Tim Beiko: um Can someone post the pr to the Builder specs in the in the chat

um okay second okay just we have a couple more things to cover anything else on this okay um thanks everyone and yeah we can follow up on the next call and and see where implementations are at um okay the next big uh PR is this rebase of 4844 on uh capella um basically uh there's there's work happening on on 4844 and I think we have pretty strong consensus that like withdrawals are the first thing that's

going to be prioritized on the CL side we'd like to get uh 4844 implementations done so that we can potentially ship them um if not together very close to one another um and the the sort of way we've discussed doing it is having 4844 uh rebased on top of capella so that you know you could imagine activating them one Epoch apart or something um on the consensus layer um and yeah I know there was a lot of discussion on this PR and how we want uh to approach it but um yeah and and xiaowi had some updates on uh basically making uh a lot of the

withdrawal stuff no Ops I don't know if this still applies given the change in withdrawal spec um so yeah curious uh what people think we should be doing with this one

Terence Tsao: I was pretty happy that we were able to come into some sort of decision on not having the queue in the business day so I think like it's fairly easy to move forward now so now we know there's not going to be a queue in the between state but within the block you still have those like uh POs to uh to Eve one um signature changes the address changes and those can be stopped out with like empty or zeros so yeah I don't I don't

see anything that's blocking this PR right now so yeah I'm happy to approve it or anyone else want to approve it as well

Sean Anderson: uh so from Lighthouse like we were pushing for this but since other teams didn't really like the building on top of the unstable changes in withdrawals were working like on our side to make withdrawals completely disableable so um our positions now just like whatever can support other teams more easily and I guess generally it sounded like actually merging this into the consensus spec repo might not be great in terms of

like uh just the general structural repo like testing infrastructure so it's another point

Potuz: yeah also the beacon State structure is going to change so I I'd suggest to hold on on that VR a couple of days at least until we get our the pr with the with the actual Beacon noon Beacon State and all the structures that you will need on the consensus side

Tim Beiko: okay and then in terms of implementing and continuing the work on 4844 people can just about the withdrawals um as they were previously doing or what would be the

yeah what would be the best path there

Terence Tsao: I don't have a strong preference on this I I mean I think for us we can follow other clients if other clients have strong opinion on this

Sean Anderson: um yeah I think for us also like whatever would better support clients that might be further behind in development

Tim Beiko: so um any other client team have opinion here

Potuz: so perhaps I I missed the the question

but I think uh so if I understand correctly there are two things to test this one is 4844 and the other one is withdrawals and it seems that withdrawals the execution layer is already ready to test I think at least that's what I'm getting from Marius uh so my my guess is that we can try to to give him give them clients now with the actual structures for withdrawals so that we can start testing right now the execution side yes please yes as soon as possible it's been a week so yes yes in just a couple of days

Tim Beiko: yes so that's yeah that's definitely something and I think that the the other Challenge on the 4844 side is I believe the prism implementation was

built with like 4844 after the merge so like after Bellatrix rather than capella and um others are starting to implement it and would rather have four four after capella and so making them interrupt together is a challenge just because of that

um I think if we all

Potuz: my suggestion there is that we actually ship today or tomorrow or as soon as possible the actual structures on our clients yeah just the structures because they then they can be start stopped out I'm gonna have this in prison today

Terence Tsao: Yeah so basically we can do basically we can do with propeller or without

propeller I mean yeah basically we have two options and uh I think we can go with whatever other teams prefer

Tim Beiko: yeah I think if it helps us with the testing for withdrawals to just get the like get all the structures implemented in clients and move that forward and then we can step them out when we're doing the 444 stuff that seems like the best approach um does anyone disagree with that yeah and obviously yeah we need to get a high level order for all the withdrawal stuff done before so let's yeah let's have teams focus on that and then uh the

forward for four people can yeah just work with those trucks and stuff to help cool anything else on this

VR

Tim Beiko: okay um yesek I believe uh you're the one who proposed uh the historical batches PR um do you want to give a quick uh overview of that here's the link

Jacek Sieka: yeah sure um so this is really just a small cleanup of of one of the fields in the state um

right now for those that I haven't seen that PR it's basically that in the state we have this historical Roots field uh it's basically the Merkel root of all the blocks and all the state roots of all the history that led up to that particular state what the pr does is that it splits it up into two lists historical Roots uh or rather that you can get um root for the block route separately from that of the state and what that enables is that whenever you have 8 000 blocks like the data of

them you can verify that these 8 000 blocks belonging to that state without having to recompute the state route which is nice for archival purposes like you just grab a checkpoint state and you can immediately verify all block data against routes that are present in that state um the pr itself it's gone through a couple of iterations it's where it's kind of simple right now I think it's like 10 lines or something um in the beginning we thought we'd like kind of backfill some of the information but we've come to the conclusion that

the information that is to be mindful it can be shipped as a content because it can be verified against other state data and the other simplification that PR has gone through is that the fee the new field that it adds uh now ends up at the end of the state so that we don't change the the header of the beacon state so that if you're reading like the first n fields of the beacon state across different Forks that will continue to work um

the pr itself we kind of it came the idea came kind of late in the Bellatrix cycle so we decided to postpone it I think um now would be a good time to just throw it in seriously questions

Tim Beiko: yeah do any other climate do you have comments or thoughts about this okay

um I guess people can comment on the pr directly if there's anything um yeah and once there's a bit more feedback we can probably make a decision on it um thanks I guess next up uh there's been a lot of discussion recently around Gordy's supply issues so it's really hard to get Gordy ether um and people are literally paying for it which is not great um there was a community called earlier this week uh which afri ran um to go over these so afried do you want to maybe take a minute to talk

about the different kind of things that came up there and um what are the proposals that like we can maybe do on the CL side to help with this

uh yeah sure thank you I mean test Nets um girly specifically has been an issue for a while now specifically was a total Supply just not satisfying the needs both for stakers that want to test staking setups but also application developers and with the amount of test Nets we deprecated this year earlier priorities emerge there are a lot of applications and layer tools migrating

too early which does not make it easier with a supply issue currently so we had a community called two days ago and we discussed various things and there's always two sides to this discussion the one side is the client teams that really don't want to put so much effort in testing infrastructure or Tesla specifically and on the other hand there are application teams that um ideally just want to have one functioning test net for literally forever and um our challenge now is to find a middle ground here and one thing because

so the easiest way for us would be to just duplicate girly and start something new but the issue is that so many teams are currently migrating to girly and we kind of had missed a chance to communicate this properly what the state of girly is about the future for Tesla looks like someone a million would be to find an intermediate a solution to inflate the supply and there was this discussion if the withdrawals was capella offers the opportunity to maybe have something in the consensus layer specifications that would allow us to tweak some kind of factor um that would allow us to inflate to query Supply and I submit the pull request versus the e-specification is

consensus layer specification um that proposes of a strong boost Vector that would be basically a multiplier for the withdrawal amount that was always one on all tests but it could be tweaked for testing or test net purposes and the discussion is now how trivial would the lead to implement this I mean it would be trivial but what are the implications what are the downsides um is inflating the supply generally good idea if anyone can do it and yeah if anyone has any comment on that I would appreciate it

Tim Beiko: and maybe one extra piece of context of

like why this is a CL thing is um on the El side there's not really the ability to change network parameters after this the the the the Genesis is set um whereas the CLS use a bunch of constants that um yeah the CLS use a bunch of constants that uh can be like extended and so this is just a easy it seems like a low impact uh from a code perspective way to add a constant that's set to one for mainnet and then um to something else for other networks

so that when people withdraw that's a way to increase the Gordy Supply um and the biggest risk is obviously that you can then have like a sort of infinite Loop of growing the supply so um you know you can launch a validator withdraw multiply your Gordy eth and then um do that over and over and over um so there's a point that's which you would exceed like uh what clients can handle and I believe lodestar has a relatively low value uh which is something like 70 million times uh the the current Supply so like it's there's still some room to grow but yeah

people can just withdraw increase their eat um over and over so that's the risk yeah that said if we could get this changed and it would help with all the supply issues on Gordy um which is which is great and um if we can set the constant to something that's relatively low that we don't expect to be hit to quickly um I think it's it's probably quite valuable and also I think Perry someone who mentioned this um we've had proof of work testnets in the past proof of work test notes have a lot of like fatal flaws in their design and people have generally not broken them um so there's a hope that like

users will be somewhat altruistic here and won't destroy Gordy this attack um and I believe most of the Gordy validators are controlled by client teams uh the EF anyways so like um yeah a large part of the stake would probably not be malicious

Micah Zoltu: doesn't only take one person to execute this

attack

Tim Beiko: yeah so someone yeah so somebody can like slowly you know start from 32 each double it double it double it and then eventually become the core the validator set um which could give us having a mostly altruistic validators that doesn't really help us at all well it helps you

can just it helps slow down the rate at which this attack would happen right

Lightclient: um I feel like before we even like debate to the actual mechanism we should determine if CL teams are even willing to accept a test not specific parameter before exchange right

Tim Beiko: so the accepted test that specific deposit contract but yes

Paul Hauner: so the first I'm I'm not fully opposed to doing something weird to help Goliath one concern that I have is that we really pay in terms of clients performance for every validated index that's created and if we create a scenario where one person or a few

people are incentivized just to spawn validate and then exit them to make a lot of goalie which I think people will just do then we're going to blow out the size of the validator register we're going to make it really hard to process the chain that have been my concern with this approach

Tim Beiko: got it

Jacek Sieka: well growing it to the double of the current validators around early wouldn't be bad actually because uh once we enable withdrawals um we need to be ready for that right

it would

Paul Hauner: it would be an interesting test but if we want to have goalie as a place where people can test things it might

like to if they if they want to be able to have a stable operating environment it might not be a good idea I mean certainly be interesting for us but I'm not sure right but the intention of it

Lightclient: okay so I guess then the next question is is it the right decision to try and improve the distribution of girlies because we do have this test at sepolia that we kind of are wanting developers to move to and that should be like the preferred place and if we resolve this Supply issue for Gurley I think that sepolia there's not as much points for it because the developers aren't going to move

Jacek Sieka: I mean I think there are two core issues

here actually one is that uh well there's the Dual use use um case of girly one is to test out your validators uh and that requires 32 each which is a whole lot right and then there's applications that just wanna you know I don't know unit swap whatever and they don't require as much or somebody wanting to test their units or transactions or whatever uh could something be done to keep the two apart

Lightclient: yeah I think that there is work on creating a like Staker testing specific test net because it doesn't make as much sense to have those things two things together

um so so that the Staker aspect is being resolved so I think we're like really thinking about these people who are like trying to cast on a test net to like run integration pass across many applications and so the question is like do we want to resolve this for girly like what is the future of Gurley and to me I was thinking like the right thing was to kind of let girly die over a longer period of time and then push the developers to

sepulia

Potuz: there's also a way of uh keeping girly working towards the Acres uh and having the full testing environment if you just have a contract that is founded and I think each taker is already deploying

these things where you just send very little girly and then the contract deposits for you uh so so you you send the deposit that it's exactly the same experience it's just that you send a less amount and then the contract acts as a proxy and deposits for you so it keeps girly working for people that want to stay and I agree with Lighthouse they're with like clients that if if we fix girly then we're not going to see developers moving to sepolia

I want to make two comments before we move on with this discussion they're just a scroll boost factor is just one of uh different uh a couple of measurements we want to take

um the there is also um Mario working on the status test net so we are trying to um have a different solution for people or specifically want to test a staking setups so this is like an entirely different discussion and we don't need necessary emphasis right now and also I have been working on um something I call a test net release schedule that is kind of predictable so when which test net should be the primary test net is also a different discussion for now I would like to focus back on feedback on how to how to fix curly or if we should fix curly at all or move on to another test now that would be really appreciated if we can

can discuss if something like is um like a withdrawal factor of on on the contrast clients would be feasible

foreign

Lightclient: does anyone feel super strongly to keeping girly alive for the longer term for Developers or is everybody on board with trying to mix apolia the default place for application Developers

Tim Beiko: so it depends what you mean by like long term right like I think

it's unrealistic to think about shutting Gordy down in say the next six months like I think we've shut robston and rinkerby down and some people are already are like in the middle of like migrating to Gordy I don't think there's as much infrastructure support for sepolia yet as there is for Gordy so like you know sure we can push people off of it I think that is still like a you know call it six or so months probably more like six to twelve um process and it's like what do we do in the meantime um and they might not be it might be fine to just say like look even if it takes a year it becomes weird for a year

that's okay and we move people to sepolia um and we can invest our time and efforts in building something like a Staker specific test Nets which shuts down gradually or or frequently but yeah I don't think we can like say we're gonna just turn off Gordy in three months or something

Parithosh Jayanthi: um there was another um idea that kind of came up in chat now uh we could in the next Fork of girly um change the effective balance and the

ejection balance as well so that when partial withdrawals and withdrawals are enabled we kind of free up locked girly ease in the deposit contract it wouldn't solve the problem but it would at least free up existing locked colleagues and a lot of the freed up amount would still be under the control of client team EF so we can solve the allocation problem in a separate manner probably with hopefully better faucets or whatever the solution there is

sorry guys but what if we will have this schedule of network disabling what would happen to users that want to check what can happen to their stuff like nfts and

stuff like that after for example the period that archive nodes keep the date so how can users be able to test long-term effects of their contracts and their stuff if we will have like schedule of killing networks every say half of a year a year what's an example of a long-term thing you think that like how data can survive after it is migrated from like I had something made recently then I waited for a period of time that is longer than our like period of fresh note the period when data is like kept in archive node how can I

check that the data is still alive still accessible from the nodes that are currently in the network so such kinds of tests

Tim Beiko: is that something the network should guarantee

Marius van der Wijden: it's something that you want to test and I think it's it's actually valid there should be some longer running test case a test

net

Parithosh Jayanthi: um well the longer running test net could still be supported right

yes yes

Marius van der Wijden: yes exactly the way I see it this this like ephemeral kind of ephemeral test that is more for testing for giving stakers a way to test

um and what just just the flow

Tim Beiko: why do we think sepolia won't end up in the same state as Gordy you know fast forward two years from now like we have the ability to Mint as much ease as we know because of the because of the token gated withdrawal contract okay

Parithosh Jayanthi: yeah we kind of deployed a couple of Tricks when uh when deploying the support yeah Beacon chain we have Genesis validators with a couple million eats um Genesis balances and we can withdraw them or I should draw them or whatever and we have the token gated deposit contract with another couple of trillion

each

Tim Beiko: okay and we can we can

mint eth in that toe because we we also had like you know uh Genesis whales for Gourley and Curry that's not sufficient long term but like if we have the ability to Mint additional yeast uh through the token contract I think that's probably like the big differentiator yeah um Paul for your suggestion uh we had proposed that the El devs and they were against it so if CL does want to do that that works um

I guess it's worth I would actually be the most faithful one so if but even if you do you want to move to sepolia like in the the medium term is it worth specking out this effective balance change because um that seems like something where we're not actually adding a new constants to the spec uh you know like with the withdrawal boost Factor we don't run into this potential like infinite Loop of Supply issue and like given that most of the the Gordy East uh on the validator side is most of the Prater validators were run by client teams and the EF if we have a lower effective balance and it allows all those teams to get a ton of of Gordy eth

um I think it it's reasonable to like have them distributed the faucets and whatnot and it might just buy us some time um so is anyone strongly opposed to that or is it worth at least putting together respect for it and seeing what it what it would look like

Lightclient: I think I'm generally opposed of modifying

girly just because we want to move people with disabilities that's the main reason

Lightclient: uh yeah I think if we modify early then it makes it pretty unlikely that we'll ever move to

sepulia okay

anyone else strongly opposed to this or I'd be tempted to say if we were going to bother with doing a fork to change the max effective balance then um I'd be tempted just to do like a irregular State balance transition and just um yeah just dump a trillion ass into Paris account it seems like it'd be easy to me I mean into a into a validator um account yeah I guess I just see like the mechanism which happens is like a separate discussion there are many ways of doing it in a good way the old like to me like you know we agree that clws are okay with doing some sort of irregular type of fork for a test net then now the question that we need to

really answer is like are we going to do something about girly or are we going to push people to sepolia yeah and then once we agree on that then we can like decide like how to make it happen yeah that seems reasonable um do we have a testnet Channel or something in the r d Discord I don't think we do um I don't know where's the best place to have this conversation um we have a testing Channel yeah they're used for actual that's that's Channel under the CEO category oh is there okay okay so let's use that uh to continue just I literally had that channel muted for some reason um let's use that to continue this conversation um

yeah and um okay we're we're already sort of at time uh I know uh Chris you wanted to give a quick muv boost update do you want to take a minute or two to do that and I know you shared a link in the chat as well

Chris Hager: yeah sure um just running through it there is an upcoming release of meth boost 140. which is a bunch of minor improvements but the notable Improvement is the ability to set a minimum beat value so any proposal can Define whatever value they want as a minimum beat value and below that no bid will be sent to the client that's uh they're only notable there is a bunch of minor improve improvements

like clogging and multiple really flex and you can see the details in the GitHub issue so I really did API updates as we discussed before the profit switching in the beacon node and the block scoring standards and payment proofs that are somewhat related ongoing research about inclusion lists insight and or outside map boost uh improving performance with SSC accorded payloads there is conversations in both the Builder specs and the beacon apis previously there was also the discussion about SSC subscription to trigger block production that's a stagnant at the moment

and a few stats about the relays there are eight relays currently producing blocks with put a table in there with the number of payloads in the last 24 hours for each one and I put together a table of notable builders that submit blocks to the flashlights relay that are landing on chain so you can get a bit of a feeling of what's going on in the Builder ecosystem at the moment yeah that was the very short version any questions all right

Tim Beiko: okay yeah thanks Chris anything else uh as we wrap up

Alex Stokes: okay thank you one more thing just to call out the document I put in the chat about the drawers progress uh I'd be very good if we could get to a test net by the end of the year and I'm generally trying to keep track of everything let's see I'm trying to find it but uh here we go oh I can't copy it that's annoying there we go this one uh what I just pasted in the chat just everyone uh take a look

cool

thanks everyone um and yeah uh next one of these Danny should be back uh to run um thanks for bearing with me today and see you all on all quarters next week bye everyone thank you thank you [Music] [Music]

foreign [Music] [Music] foreign [Music] [Music] [Music]

foreign [Music] [Applause] [Music] foreign [Music] thank you

[Music] [Music] [Music] thank you [Music]

foreign [Music] [Music] [Music] [Music]

thank you [Music] foreign [Music] foreign [Music] [Music]

foreign [Music] [Music] [Music] foreign

[Music] foreign [Music] [Applause] [Music] foreign

[Music] foreign

[Music] [Music] thank you

foreign [Music] [Music] [Music] foreign [Music]

[Music] [Music] foreign [Music] [Music]

foreign [Music] [Music] [Music] [Music]

foreign [Music] foreign [Music] [Applause] [Music] foreign

[Music] foreign [Music] [Music]

[Music] foreign [Music]

thank you [Music] [Music] foreign [Music] [Music]

thank you foreign [Music] [Music] thank you

[Music] [Music] [Music] foreign [Music] foreign

[Music] [Applause] [Music] foreign [Music] foreign

[Music] [Music] [Music] foreign [Music]

foreign [Music] [Music] [Music] foreign [Music]

[Music] thank you foreign [Music] [Music]

thank you [Music] [Music] [Music] foreign [Music]

foreign [Music] [Applause] [Music] foreign [Music] foreign

[Music] [Music] foreign

[Music] [Music] [Music] [Music] thank you

[Music] foreign [Music] [Music]

foreign [Music] [Music] foreign [Music] [Music]

foreign [Music] [Applause] [Music] foreign [Music]

foreign [Music] [Music] thank you

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.