All Core Devs - Consensus #112

Transcript

foreign [Music] thank you

[Applause]

Danny Ryan: great we should be live welcome to

AC DC you can sense the Slayer call one one two this is issue 821 in the PM repo if you're following along that's the edge of this so uh a few denab items a couple things from Mikhail about the engine API and then we had planned to talk about three six as the blob Target Max we hopefully those some of the data but we've also had some test net hiccups so um we'll see as to where we are on that conversation let's start off with you Mikhail

um the deprecation

Mikhail Kalinin: yep um yeah so from the latest call we've learned that uh dropped it talking to chat we've learned that basically uh execution layer clients do not log any error anymore if exchange transition configuration is not being called by the CL so that's that's great and yeah the next step would be uh if we take these spots The Next Step would be for sale clients to stop calling this method or remove it entirely from the code base and a requirement for according to this procedure requirement would be to make

this change into Cancun at most so after Cancun everyone upgrades their nodes and then uh and then elk went can remove this method entirely from their code base as well so um that's basically it about the deprecation for for sale side does anyone want to rise any opposition to doing this

Danny Ryan: so it was you can remove the call or remove the code entirely now and you should certainly do so by the fork

Mikhail Kalinin: yeah that's the perfect crew cab in the opposition

Danny Ryan: and what happens if the client teams do not do so by the fork that means they'll call a method or attempt to call a method that does not exist on the execution layer and would probably see errors

Mikhail Kalinin: yeah yeah exactly that

okay but we

Mikhail Kalinin: we actually will not be able to safely say that El developers can remove this palette method from from the

code base I don't think it's it it's superb big problem but still uh I guess we want to keep the basis clean as clean as possible

Danny Ryan: and this is in the Cancun engine API spec

Mikhail Kalinin: yeah it is it is there basically so I take silence as no position to that so it would be great if um clients would be would keep this uh document posted so we can track the progress

and be sure that it is done before Cancun there is the table for sale clients in it

Danny Ryan: sounds good I'd say when we are discussing test net dates Nick IO that maybe you just kind of do a quick pass on this on a call once more to make sure everyone's in line

yeah yeah yeah all right good idea

Danny Ryan: great and the next item is also an internet API item from

McDowell

Mikhail Kalinin: yeah so it is a tiny change to the engine API uh but it's not a tiny conversation as time is the change looks

like so basically uh this is about overriding Builder Builder block by using by falling back to local execution payload if El if local El client suggests that some censorship is happening in the network and we uh we had this question before um in one of our conversations after Russian high and we decided to get back to this in the context of Cancun so now is the time to get back to this conversation and yeah I think that the change to

engine API is really tiny and doesn't look too complicated but yeah I would like to ask photos since he's on the call to give more context about this and refresh the background on that

Terence Tsao: yeah I can add more color right so the high level idea is just to give your local validator more find the control today local validator look at payload value decide between the higher value between local um between the local payload versus the Builder Halo but this enables more controls such that like we can see what the censorship for example what the

transactions haven't been included for several slots with higher priority fee or some certain Tas keep getting reward and I think it's what mentioned me the idea of optionality here is nice which is different El to have different heuristic it's kind of like her immunity and this is a future not a bug and this is also an optional endpoint as well so yeah I think we discussed at the end of case capella um and due to timeline we didn't make it in and I think this is a good inclusion for Cancun

Danny Ryan: yeah I mean it seems on the very minimal side of complexity because you can

essentially do nothing um on both sides other than just have this field I'm pretty supportive

Ahmad Bitar: uh I'm sorry my understanding was that it was a soft fork or it does not need to be hard like is this field required to be sent

Mikhail Kalinin: um according to this spec yes it is required to be sent but the client can just send true if it sorry false if it's not support if it's not supporting any heuristics or do not want to support it and the CL can do a no-up

on or can can for some amount of time not do anything in relation to the value but the value

Protolambda: just ignore it so it might depend on zero change for us

Ahmad Bitar: why did we not opt for an optional value where someone can add it to the execution engine whenever they want

I

Mikhail Kalinin: probably can't think about it but currently we don't have optional values in

this pack

Danny Ryan: there's also a hard Fork coming up which is a great time to transition and not deal with the complexity of

if values exist but on the on the CL side we already do some all back based on other uh conditions so I think to support on the CL side that flag should be quite easy and as said on the on the El side you just pass Falls by default and the protocol doesn't doesn't need any optional value is there El signal other than Geth let's see Marius has an implementation

Ahmad Bitar: is there a specific consensus on the

heuristic that's going to be used to determine the value

Protolambda: I think it's better not to have consensus I think it's better to have client diversity here and I think it's better to have uh diverse options of to where that each validator can decide on what kind of sensors is censorship or not I can give some several algorithms that I think are reasonable but I suspect it's better to have each client team to come up with their own design decisions

is there a reason for this to be a field in get payload as opposed to like

um having a new endpoint that has this sort of more general information it's sort of like sort of like transaction pool information to some degree

Protolambda: yeah so so here's I think there is there is an actual reason so so this opens the door albeit minimally to break in the boundaries between the El and the CL so we really wanted to keep it at the absolute minimum and being trivially implementable like having a different endpoint this would uh definitely uh raise more concerns from El deaths and and it would increase complexity in like in using the same point or not

uh and I think just uh the fact that we're opening the door to uh breaking the boundaries between cl's and yells in a way that we didn't do before it's better to just keep it absolutely minimal

Mikhail Kalinin: alternatively there was a suggestion to for cl to use Json or PC API endpoint to grab the information required to implement some heuristics and encapsulate this completely NCL but uh I should say that Yale has all the information required for that

and probably some information will be really difficult to expose why Json CPI and this is additional complexity and definitely to do that and the existing information that one can grab from Json CPA might not be enough for implementing some heuristics so it's pretty constraint constraint path

Danny Ryan: yeah not even not not because even like types functions just all sorts of stuff that exists in El to process even if you can get the data on the CL

Jacek Sieka: yeah that was actually my suggestion I think the reasoning was more or less that the

cl has other information that it might want to weigh against whatever the El is claiming so like you know a little bit of censorship is fine but I'm happy to be bought off by uh a big bribe and you still can be

right I guess you you only see true pulse but you can still decide whatever you want to do with true false there is still the value on the that you can read it's always it's a matter of bribe you see the value and you can decide to ignore the flag at this point

Danny Ryan: yeah you could also see false and have seen you know eight missing blocks and say you know what I'm gonna

fill both away so yeah there is information it just looks granular obviously yeah I mean there is but like it's it's it's very binary uh by definition in many I mean I could be naive it seems sufficient but uh maybe I'm missing something

I know

Protolambda: and also it's not really binary right so here is we have on the CL side all of the information that we can process and we make a decision and then the El side has whatever information they have and they make a decision and then we get to choose what we're gonna

do or not without having to know how to parse the El side so you whatever Nimbus decide if they might want to say well if I'm connected to get I more or less understand what is the implementation of get and I know what true or false means and I implemented this in prison I might say well I know what Aragon would do and then I'll just pay this or that much attention to whatever concept does but I think it's it's not really binary

yeah

Danny Ryan: there's more information also it does not preclude a client from hitting the Json RPC and doing other things

Jacek Sieka: do we have a good Json RPC to query the transaction pool this way I basically I

don't know give me the top 10 unincluded transactions

we

Marius van der Wijden: we have the TX pool namespace and and guess and you can query the whole um transactions but this is a lot of information and it's very um not really meaningful um we don't have a endpoint that like solves the transactions yeah or all sorts of transactions by arrival time or stuff like this that's not really implemented and it's also something that might not be going to be implemented so we kind of moving away from this end point in Geth

because we want to store way more right now we the transaction pool stores roughly 5 000 transactions in memory and we would like to move to a world where we can dump some of the transactions to disk and only maintain the metadata for those transactions and in that case um servicing these these transaction queries that we have right now uh it wouldn't be possible for us anymore it's already not really possible for Block

Jacek Sieka: all right now I I wanted to explore the

idea before before we commit to this but I think if we get a Boolean we'll we'll implement it for sure

Danny Ryan: okay further discussion Miguel this has not been brought up on El call has it sorry this has not been brought up on the Executioner call right

Mikhail Kalinin: no it wasn't I mean like it was before but it was a lot longer I guess

Danny Ryan: yeah but as a breaking change for the Cancun engine API it has not been brought up

yeah

Mikhail Kalinin: it tests I think it worse to do it next next week

Danny Ryan: yeah and maybe right after the call we can try to circulate it and get some async conversation going um so that there's something that looks like Clarity before the call

Ahmad Bitar: do these changes in that engine API require an

AIP or no and that's what it does not just send this back

Danny Ryan: so the the mergy IP and the consensus layer specs kind of describe the high level communication

and the requisite validations in the abstract and so that remains stable and all this other stuff is an implementation detail but doesn't doesn't affect the course guys okay great um next up we had committed to revisiting three six a couple weeks ago um I hoped that some engineering folks on the various teams have had a chance to look at the mainnet 36 data

experiments we had hoped that we would have a test net at this point do we have devnet 7 is that still work in progress

Parithosh Jayanthi: it looks like by passing all the five tests that we wanted to so we'll start planning it out and most probably launch it tomorrow if not Monday

Danny Ryan: okay cool um obviously the mesh the types of nodes in the load are certainly very different on our devnets but I think there was a desire to see this functioning on there um open it up for conversation uh the spec is currently written as three six is there any further opinion on the data thoughts on load thoughts on the

stability of picking such numbers

Mikhail Kalinin: been spoken to Anton about this thing and he said that I think that this is fine the only thing that his concerned about is is the flood published and if the plot publisher is adjusted to uh to these large bulb messages to the large messages and in the context of 4844 and should be fine from his perspective

I mean like three six um blobs should be fine

Danny Ryan: what is the status of doing a staggered blog publish we'll be doing it pre dnab like it will go out forging up and and will you be doing any sort of like uh bandwidth estimation in doing so or that will just be the behavior and maybe you can turn it off

Jacek Sieka: we're gonna start with a reasonable value

probably user configurable uh and then we figure out bandwidth estimation which is tricky um but on the other hand we're gonna base it like not on the net like we're gonna certain message sizes and like reasonable bandwidth for what a note should have and then we're going to include a couple of fail safes as well so that we like if we run into a slow pairs that that pair doesn't break the thing and so on um but we're certainly going to do something because like above all four blocks it's a topic that

everybody is subscribed to practically so if you're connected to you know 30 50 70 pairs that's another appears to this flat publishing too so it's like it's a no-brainer that we need some limit and then

one yeah and Dagger I guess there's two things

Jacek Sieka: yeah yeah yeah but like flood Cloud flood publishing in its pure form would send it

to all connected Pairs and that's not the same right

Jacek Sieka: yes so like if if you're if if any client is not implementing any kind of limited flood publishing as it comes in you know native gossip something this is this is bad but then the Staggering is

is another thing and uh like we have a long conversation about this in an early b2p repo as well uh but the the basic idea at least is that for the first heartbeat we tried to flood as much as possible but after that we kind of want to leave room for now I have and I want mechanism to do more of the work because it's less redundant so um well that's that's where the backup mechanism comes from as well where and then we're also discussing this other protocol upgrade which is the I

don't want message which is basically saying that I got the message I please don't send it to me anymore and and I I think I would really love to push for this to happen before the ramp as well but I don't know if timing wise that's possible but it's it's a really important part of the overall strategy I'd say

Danny Ryan: yeah I don't want is uh backwards compatible I mean it could be partially upgraded

Jacek Sieka: yeah yeah yeah yeah but but like yeah it's a significant difference and the um it kind of depends on most clients implementing it or rather the more nodes online that implemented the better it works

Danny Ryan: what is the status of that spec becoming a spec rather than a PR discussion

Jacek Sieka: I haven't looked at it yeah

Danny Ryan: a couple weeks ago and it was still active discussion rather than something that looked like it was going to be rolled out into the

postcode

Jacek Sieka: yeah I mean the alternative is really the um like we might pursue an experimental version of it before this pack is out I mean I find I feel that it's that

important but then we'll have to deal with the upgrades somehow

uh do other clients have notes about their blood published modifications and or that I do not want I know in working on like blood publish modification like specs and I think he's been doing some experimentation but like I don't have much Insight specifically into what you're doing um on top of that he's also working on like experimenting with using quick as a

little transport protocol instead of TCP um but yeah both of those things like I don't think we really have results from yet

Mikhail Kalinin: probably we can in one in the next um 484 implementary school we can recap the networking thing I mean like uh what should be done and what we highly desire to be done before work on the network instead so and discuss more like I don't want

them to publish and all this yeah and update statuses on on those implementations ends backward

Danny Ryan: yeah I agreed and I can knock on a few doors between now and then and make sure that the information surfaces so that'll be a one and a half weeks uh which hopefully we can talk about on the breakout call and then surface it again here um I guess fortunately The Staggering approaches um in blood publish modifications can happen very independently of each other um the I do not want I would much rather see is like a solidified spec than something experimental but

I guess we can cross that bridge as we get there

I'm quite curious like if there is anyone here that that can merge the pi into the P2P spec it seemed like uh that level is maintained by other group of people right

Danny Ryan: and we can always Fork but it'd be best to get it into the main um I guess I'm not I'm just not at the I'm not sure given where I last looked at the conversation it wasn't clear to me that the kind of General r d effort was ready to merge them but that could have

changed since I

lived in okay

Mikhail Kalinin: so we can ask for uh lik2p maintainers What's blocking this barrier from being merged as well can you reach out to them right um on Dance guard comment about the attacks um I think we should not worry about such attacks because the system will be able to pass the those transactions through um yeah they could be um empty slots as a result of this attack but considering the cost of this attack with like um

no no um no gain or almost no gain for someone that's just you know bugging the system for a short period of time this kind of attack does not look like a sustainable attack long term like a viable attack

Danny Ryan: yeah I mean I suppose it's unclear what the threshold of making it a viable attack becomes right or we does adding all the little blobs lower the threshold thus lowering the cost for such the attack um it's also hard to parse in the context of split meshes which that block

would ride on a split mesh from the rest of the data so feels like an unknown

yeah that's good

Ansgar Dietrichs: yeah just wanted to if you say of course it's a bit of a side uh worry because the main conversation you're around is of course around just the normal case but I think it's important to think about a little bit it's obviously the situation will strictly get worse than before just because bugs can still be as big as they were before and they're still propagate this one thing and then we have this this additional props now um I I think a person would be fine with just physically not worrying about it too much just because also it's in the best interest of proposes to make sure that block arrives at peace in time so

if this actually becomes a problem on mainnet we could imagine having just slightly modified thought building Behavior where you just make sure your block never gets too big um which is not actually too bad to do um so I personally don't worry couldn't worry about it too much but I do think we should at least basically make sure we we don't just forget about it we are just basically we make the conscious decision not to worry about it

Mikhail Kalinin: that's all um yeah I pretty much agree and I would like to add that um it adding blobs might reduce um the thresholds but I don't see how it reduces the cost of this kind of attack

in terms of spending it to keep your transactions keep your large transactions at the top of the man pool or via in the space from Amanda space from block building market

Danny Ryan: so the percentage of the block you have to consistently buy is lower

Mikhail Kalinin: yeah of course

Danny Ryan: but I guess but with the exponential considerations yeah it may be it converges that yeah not sustainable regardless

Mikhail Kalinin: yeah well I I would say that it seems to me that what is uh what is like makes this adapt attack cheap I mean like the the

space that one can buy and pay um not that one not that big host uh this in this case uh I think the network can handle this it will not it will definitely not be more than one megabyte or even more than a half of a megabyte

Danny Ryan: okay so we will monitor devnet7 which will have these configuration values um when is the P2P Community bi-weekly

call Alexa you mentioned that in the chat uh most likely after Tuesday uh let me show calendar oh okay yeah so given the urgency of maybe some of the I do not want things that might be worthwhile for a couple of us to join that call we will service more discussion around flood publish and I do not want on the 444 call in a week and a half and we'll

talk about this again two weeks you have a polesky or is that how we pronounce this update

Parithosh Jayanthi: yep uh we just had the community call Rafi in our Togo and we decide we have commitments from all the client teams that basically sign up to about 1.7 million validators we're going to be validating if that actually works we're just going to have a small side chain where we're going to load up every single client combo and make sure that we can handle such a large chance of

state but if that's the case then you should expect Genesis state to be ready at the end of July and ideally they're included in all client releases by mid-august so that we can oh sorry we'd be on track for mid-september Genesis um there's a link to the key takeaways as well as call notes um so please have a look and let us know if if you oppose anything

this

Danny Ryan: is the allocation uh fixed

Parithosh Jayanthi: uh yes the allocation is mostly fixed we have uh three tiers client names node operator slash l2s and others in case

someone did not make it in time please post a comment with a reason and we're still open to evaluating stuff Case by case but ideally we don't want to because we're already over our plan Target of 1.5 million

Danny Ryan: got it well there's a difference between the validator allocation in the allocation inside of the execution layer right is it or is there a zero allocation in the execution there

Parithosh Jayanthi: no there would be a allocation in the execution layer and there's a separate issue for tracking that um I'll just share a link to that as

well yeah I share a link in the chat for them

Danny Ryan: any questions for Perry um any other didn't have discussion

points for today

Parithosh Jayanthi: it would be awesome if Clan teams could uh especially CL teams could DM me which branch I should use it and keep an eye out for info on that

Danny Ryan: uh so there was a release the release has four seven eight eight seventy 44 70 45 built into the spec at this point devnet 7 is only 4844 um obviously the Divergence here might cause some stickiness but hopefully after devnet7 we can move towards full future

test snaps if that's not the case then we might have to revisit kind of how what test vectors released what clients look like and things like that but at this point I don't think there's much to revisit we wanted to get this back out there so development isn't blocked um hopefully it doesn't cost too much issue are there any questions or comments on the state of specs versus Dev nuts right now okay cool any other app related

discussions

Jacek Sieka: uh I have a question so let's pick one for oh includes this attestation subment subscription stability subscription model change do we have a roll-up plan for that like when when clients start using it when clients start enforcing it

Danny Ryan: yeah so it's a backwards compatible change right now because of the not any peer scoring um the intention is to turn on the enforcing of it at Plus one hard Fork I believe

um I would have to Circle back with age on whether he intended to change the spec such that it was at deneb but right now it can be rolled out in a backwards compatible way I guess we should bring up the discussion as to whether that's the never plus one hard work for the enforceability

Jacek Sieka: and the other thing enforceability is nice but obviously you can just not join the mesh did we ever solve that

so

Danny Ryan: what do you mean

Jacek Sieka: well the enforcement says basically that if you're not subscribe subscribe to the right topic you'll you'll get a penalty um but you can subscribe to the topic and then leave the mesh so you still don't take the traffic hit which is kind of equivalent

buy

Danny Ryan: leave the mesh meaning you don't have any peers yeah even though you're

average

Jacek Sieka: yeah exactly because you can't really detect that somebody else is on deep here like has DPS in their measure already and therefore is

crafting you from the mesh when when you try to sorry pruning you from there mesh when you're trying to craft them um and the effect is kind of similar-ish actually similar to what similar to just not subscribing or not all right which is what we're trying to sort of enforce here that people subscribe to the subnet that they're supposed to be subscribing to I mean the implication that I was

thinking about as well was for like clients right now they're kind of Uncharted Territory whether they should be subscribing to the block topic or not probably not maybe and they should be wreck resping their blocks Maybe but there's no real policy for what happens when a light climbs like connects to a node

this is not really

Danny Ryan: yeah like right now right now in many ways you'd probably be

downscored

Jacek Sieka: um you might there's not there's no explicit down scoring like there's nothing that says that you have to subscribe to block topic for example you should but

um only if you're synced for example so you can't really tell an unsynced node from them the light client and so on so there are all these little gaps let's say that that one could think about if you wanted to

Danny Ryan: yeah I'm not sure age's consideration on subscription versus participation and if there's any sort of I mean intuitively you would probably not be able to actually know if somebody's sporting messages along or participating at the

level you expect them to um but maybe there's another consideration hn that I'm not aware of

Jacek Sieka: but anyway rollout is as clients want or continuous at this point

Danny Ryan: yes

Jacek Sieka: yeah okay cool

Danny Ryan: cool other denab items any other items for today

Mike Neuder: yeah um can I chat a bit about the max effect about stuff if that was a good time cool yeah so I guess conversations have been continuing um thanks very much um to to dapline Aditya Mikhail and Francesco we've all been kind of jamming on this together and it's been super helpful so I wrote up a short one pager on kind of the status of these discussions I also opened up a kind of a very draft PR to the eip's directory here so yeah I guess a few just kind of

running down the biggest discussion points right now I thought that might be useful so first is the idea of execution layer triggered partial withdrawals being a prereq for the max effective balance increase I think this wasn't originally the consensus but now it's it's kind of shaping up to be just in terms of ux being pretty unacceptable otherwise um the idea here being if a small validator opts into compounding they basically will never see withdrawals ever until they fully exit their validator even if they stake from like 32 each up to 40 each for example over over months or years then they need some way of withdrawing some of that without

exiting their validator fully so execution layer partials are kind of what we're saying is a prereq for the max effective balance increase the question kind of then becomes do we do that in the same EIP as the max effect balance increase or do we bundle it into 7002 7002 is an EIP from Danny about exits coming from the execution layer here's the consensus spec PR and there's a link to the EIP PR in there too so yeah the the decision around whether to include the partials withdrawals in there or in the max effect balance EIP I would say it's kind of still up for

debate but I don't think it's too consequential so yeah the second thing I wanted to bring up is this idea of proposer equivocation issues so basically slashing penalties are as written in the spec are proportional to the effective balance of the validator this has to be the case for a testing equivocations because that is actually like Fork Choice weight being thrown around if if there's an application there but for proposal equivocations we think the penalty doesn't necessarily need to be proportional to the full effective balance and the reason being the proposal equivocations kind of only proportional to to one 32 each validator

um kind of misbehaving um because a a larger validator doesn't have higher weight on a proposal than a 32 week validator so yeah the there's a bit of discussion around how to handle that but that's that's one thing that comes up the reason one reason that this would be desirable is just to help de-risk consolidation like if if big stakers consolidate and there still is such a huge flashing penalty for a double uh proposal then even like non-malicious double proposals are really heavily penalized which might not be ideal um Additionally the the third thing I wanted to bring up was the pros and cons of just removing the validator sweep all

together um this this came up I think Danny brought this up when when discussing the fact that if we have execution layer triggered partials then maybe we should just turn the sweep off altogether um this would make a lot of things easier from the implementation perspective but it's also like pretty invasive because then everyone who's used to these automatic withdrawals would have to set up some way to trigger them and you know it's just a bigger overall change to the network so not sure if if that's possible but yeah kind of continuing keeping that discussion alive just in case it is possible because then it makes a lot of things like it's almost intuitively like the right way to do it because then

everyone's compounding automatically and they only withdraw like as an opt-in thing and they withdraw however much they want to and then the last thing is this ejection balance consideration so this was brought up in the research post the proposal um someone commented on on what the ejection balance could look like so right now the injection balance is fixed to 16th so it's it's kind of like intuitively half of the max effective balance and the question here is like if someone has a has a really large effective balance like 2048 is there ejection balance still 16 each because then it would take basically forever for them to drain out

um through an activity leak or whatever and the kind of the use case here for who we're trying to protect is people who might lose their keys obviously like a big Staker losing their keys is pretty unlikely and um yeah but there was some back and forth on like if we could say make the ejection balance like three eth below their highest effective balance that they ever reached then the most like we could guarantee that even if you lost your keys and you're a huge Staker the most you're ever going to lose is three Ethan you just have to wait for the inactivity leak to bleed you down to there and then you'll get ejected um so yeah those are those are the things I wanted to bring up again that dock that I linked initially has kind of some of

these discussions and we'll be updating regularly as as they evolve but just to highlight execution layer partials uh proposal equivocation penalties instead of slashing pros and cons of removing the validator sweep altogether and considerations around the ejection balance so yeah happy to to take questions um and definitely to the other folks that have helped work on this um please chime in if I missed anything

Protolambda: yeah just a quick comment on the sweep uh just two comments uh one is that uh mixing this with the exits uh of PR planning it's it's a bit of a thing

right because the the exits runs it's easy to implement at least on the consensus side uh and the withdrawals if you don't take away the sweep it's very hard to implement on the consensus side and it's probably even hard to specify how it would work on the consensus assessment and also one would have to take uh care of making sure that everyone would be able to if we remove the sweetie the current addresses that are that are being forwarding without with robots now might not have access to like trigger the to make the call yeah right so so I don't think it's even possible to get

out of this week given that kind of commitment we made so I would want to see research on this

yeah that's a good point

Danny Ryan: um yeah in the past we were able to do we were trying to figure out if you could do push first pull withdrawals uh there was an effort to go and look at the uh to do a scan of all the different execution layer contracts that were set for withdrawal credentials there weren't that many at the time so we were able to get a kind of a complete view that has changed so it might be interesting to do analysis there again

Mike Neuder: yeah I do think the sweep would probably

be met with a lot like removing the sweep altogether would probably be pretty controversial so we just we're throwing it out there more as like a you know a far-fetched idea than necessarily like pushing for it

Protolambda: but it would be uh you know kind of if we were designing it from scratch now I think we would we would prefer to not have definitely but but then if if there's no sleep removal then I would propose that this is considered completely separate than

the nspr seven to seven thousand two

Mike Neuder: I see so you're you're arguing that the partial withdrawals shouldn't necessarily come to the execution layer at all is that what you're saying

Protolambda: oh no no I I'm hoping that they are I think this is a very nice ux

to have it's just that mixing it with something that is very simple to implement us that is PR I think it's a it's just a way of delaying

down SBR

Mike Neuder: sure yeah I guess the only counter argument is like if we do the partials in Danny's then the max ebpr is like very simple because then we don't have to do any of the ux considerations

Protolambda: but yeah I think it's it's then I'm only pointing this out which is a tiny piece of the max EB then uh I mean the Mac TV it would be very nice to to see and have a larger conversation about the security issues of it and we've had had this kind of change system for choice and

that we kind of rushed into them and then we found uh very very deep security concerns it would be nice to have a longer conversation on the Mac CB and how Securities and these things that are probably out of scope of this call

Mike Neuder: yeah for sure um I linked a doc called Max CB increased security this is uh something Francesco and I wrote so that has that covers some of those things but yeah I agree the it's a bigger PR than the 7002 for sure and I guess uh and maybe it makes sense to to bundle the execution layer partials in with maxi B then just because it's all like one Atomic unit which might be cleaner intuitively

Danny Ryan: yeah one one consideration for 7002 is

is at least even if you're not doing things like uh removing the sweep or other stuff like that you know do you add maybe a a balance field where if it's Max sent it's an exit otherwise you can interpret it as something else like a partial withdrawal so that in the event that you do want to trigger information from uh more information from the execution layer you have it there rather than having to go back and make a cross layer change at that point um obviously we've shot ourselves in the foot prematurely optimizing like that before so but at least a consideration to you know do you do you try to make seven thousand two slightly more generic

well

Mike Neuder: yeah I think yeah big action item for me is to do due

diligence on 7002

Protolambda: um so that's something oh just throwing this out um depending on how much we're willing to wait it's even possible to produce in stages we could deprecate The Sweep and allow validators to exit even if it's that's that might be a possible impossible as well but we could do this in stages some deprecating in one for hard work and then implementing without the sweep in the next one

Danny Ryan: by deprecation you mean a signal a commitment in the

space right the

Protolambda: commitment that you you need to exit your validators that now that we are allowing them to exit this way or another way

by the these many Forks we are going to remove the sweep

Danny Ryan: yeah certainly an option I think we're probably not quite there

Mike Neuder: I mean the we could also do the other order which is like if we have Maxi B and partials then we signal removing the sweep after that right because now suddenly The Sweep becomes like less relevant and if people want to exit they can I think that might be a more reasonable track but yeah either seemed good

Danny Ryan: regardless of deprecation notice a validator presumably can exit so they

would always be able to exit you know even yeah um if they can't then that's a problem yeah I mean and there are there are validators that can't exit

Mike Neuder: uh there are people that have lost all right yeah that's the ejection balance stuff too right

Danny Ryan: like yeah yeah so they're just waiting for succeeding one day Okay cool so um this is a PR apparently IP I think the design doc is where a lot of the considerations might go if you're interested in following this uh design path if you have any other questions for Mike today cool thanks Mike

um I'm gonna get seven thousand two merged and it's something I would like to discuss in the coming weeks coming months um just another potential feature but not free to them we'll probably do a process is it

Mercury though

Mikhail Kalinin: yeah the EIP is merged

Danny Ryan: wow I didn't even know the editors are the iPods yeah okay cool um I'm gonna do a pass on that but anyway check out 7002

I think it's a nice to have future in the coming works for the theoretical forecaster geneb that will be a star name starting with e uh we will create a tracking issue um and people can toss potential stuff into it um I think we're probably a little bit early but it's the beginnings of that conversation probably start today too soon almost too soon

Mikhail Kalinin: one quick thing with the seven thousand two I think there is a bit of a space to pass the balancing

um to pack the balance as a part of other POP key the second part because it's 48 bytes and we break this down into two pieces but definitely would be cleaner to have a separate separate storage slot for for the balance if you want that

Danny Ryan: sorry what field were you going to pack it into

Mikhail Kalinin: there is the value report key which was soar right in the um in the storage when this pre compile is being called and the pop key is broken into Parts first 32 bytes

and the max 16 bytes so we have like 16 bytes of space uh which yeah which probably not enough Syrian that we use Grace okay sorry yeah sorry for the rating the main

Danny Ryan: well but the you could pass it in as an argument but it wouldn't then pass into the message would it pass into the message because the message is actually packed 48 bytes

Mikhail Kalinin: I don't know

Danny Ryan: yeah that's all right we can take a look at it I if there's probably not a reason to shove stuff into the extra bites of another field at this point if we want it we still this

design is pretty wide open so we can revisit that definitely um other discussion points for today yeah protest just took a quick comment on that um in terms of the consensus layer it could be a binary operation of the time right it can either be if it's Max sent it's an exit if not it's a no op so there are there are pretty simple

ways to have that field available and and really not change

Protolambda: oh so you want to just to have the field so that uh for future like we just keep it as an o-up and but then the field is there

Danny Ryan: yeah the argument there would be to reduce the changes you have to make on the execution layer to make further changes on the consensus layer to have the data available that but we've done that many times and have weird Fields sitting around that we never use like Whistler blur index so like it's just it's a possibility I just want to bring in I would not argue to do 7002 and utilize that field in a meaningful way because that

changes a lot of things right like all of a sudden partial withdrawals have to think about the Q in relation to the validators that churn and things like that which is a much much deeper consideration as you noted anything else for today Tim was that a spicy enough blob data size conversation for you

Tim Beiko: yes and you're finishing right as I'm done packing so couldn't have asked for a better call

Danny Ryan: thank you

have a great vacation okay thank you everyone uh talk to you all soon

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