All Core Devs - Consensus #110

Transcript

foreign [Music] [Applause]

thank you okay

Danny Ryan: hello welcome to consensus there call AC DC 110. this is issue 796 in the PM repo here's the link um looks relatively light but we shall see um got a couple of denab things research spec thing uh actually something's not on the agenda Dock Road has some some big data tests that we're going to go over as well I hope so there are a couple of pending to NAB changes that came out of the 444 call on Monday uh this is to and that this has parallels to the execution layer so it's primarily updating the

data structure so adding data gas use field to execution payload and changing the access data gas type from unit 256 to 64. um these are both very simple uh they're approved and will be merged today uh the intention barring anything unexpected happening probably on this call is to have a release out tomorrow uh for the updated test Nets does anybody is the is the EIP the related PRS or the EIP have there's been reviewed and merged or are they still pending because that's kind of we're just waiting on that to push these through

Lightclient: uh so adding the data gas used to the header is yeah it's getting merged momentarily um there's a couple white space things but OnStar just approved it and we talked about on the call on Monday so everybody was okay with it uh yeah it'll be emerged as you know play into this call probably yeah yeah the changing the size okay yeah we haven't discussed that at all that kind of came after the call on Monday so I would like to just discuss it briefly here before moving that um into the

AV

Danny Ryan: right so again that's the access data gas going from a un256 to unit 64.

um I think if we look at the execution layer payload there's I think most fields that can fit within the 64-bit type do utilize the space savings um there's no concern that this would go in excess of 64 bits right

Lightclient: yeah and the pra had some numbers and I think the biggest it would get is like 28 nine bites 30 bytes sorry

that's that's good

Danny Ryan: and the and this is bound generally by the supply on mainnet if you had you know some crazy amount of Supply you

could break that invariant

Lightclient: I would need to see where it breaks but I think yeah I I don't even know if with 64 bits that allows I think that like that would be more than the representable amount of way in a un-256 in general I guess if every account has a un256 max

uh does

Danny Ryan: is anybody opposed to this uh I think we're pretty fine on the execution on the consensus layer

not the post I just have a quick question on the proper ordering is data yes use

um before excessive data I guess because um if you're just a consider spec PR is different than than the EIP here

Danny Ryan: yeah we might have it it it's not broken if we don't follow that ordering but we very much might as well follow that ordering okay I can make a note of that okay cool

is that I don't know is there enough execution layer uh representation here that we feel comfortable with changing the bit size on the payload or do we need to have a

uh okay okay

Danny Ryan: is anyone opposed because if not uh why don't we drop it into Discord um and get this merged quickly and we can get the release out of expenses there um Can someone do a quick blurb on Discord to ask if any opposition I it's ceremonial I don't think there will be any or could be any

Lightclient: I'll post it

Danny Ryan: all right cool thank you anything else on these couple of minor changes great Alex do you have uh an update to 4788 which is still intended to be included uh Alex can you give us that update

Alex Stokes: sure so there's a PR with the change to h no changes at the consensus layer so basically from the CL all you're doing at this point is sending over the route itself uh say an engine API we had

discussed maybe sending the slot over and like using that to like uh change some of the ux uh from the preview pile that we'll get to in a second but uh yeah that seemed a little clunky and basically we kind of moved away from that it's another question is what can we do without say that slot information so the CL will send over the root and the now the question is like uh how are these groups organized and the EAP is here for 788 uh this PR is 7107 and what this does is basically change this so that uh we basically have the timestamp and the root inside the evm that's written to this

pre-compile so the state of this contract as a pre-compile which you can call and yeah the really the last question here was how we key these things um how they're organized within the state of this pre-compile and there's a little bit of optionality here ultimately like the simplest thing we get uh uh from the Els perspective is we have the timestamp from the header and then now this root and that's kind of what the CIP proposes is just adding the root to that error as well so you have these two pieces of data and now the question is like how do you write them to the pre-compile uh what this PR does that I just posted basically writes the root and then sort of the value to that key is uh the

timestamp just itself and then the question is basically okay does this like is this equal to anyone and basically what this does is say there's now a set of all the valid Beacon routes uh and if you know it's in the set because you get back a actual time stamp rather than say zero or something and yeah generally all of the staking pools and different people in that space I've talked to are okay with this change yeah there's one maybe question around bounding the size of these things so right now the way it works is you would just for every block you would write parent Beacon root timestamp and just keep going an original or an earlier version

basically like bounded this with a ring buffer so we might want to add that back in otherwise it's going to it's looking like 80 megabytes of State growth per year which is not nothing so yeah hasn't even have time to look at this PR or think about these changes

Danny Ryan: yeah I mean my gut is to not have some unbounded State growth here especially given like only consider we have these double back miracle accumulators and try to like keep anything Unbound pretty small I know this is relatively small but um yeah

so

Alex Stokes: so another option is rather than do root to timestamp do timestamp to roots and then it becomes much easier

to handle bounding them in time

so

Danny Ryan: right and then it the impetus is on the

Alex Stokes: um the caller to juggle like okay if I'm going to prove something at the slots then I need to figure out which time stamp that was but that's not a huge

risk in

Danny Ryan: the construction people constructing transactions have access to apis yeah I guess the other thing you could have some weird like map where you have time A and time B and you always alternate between which one you're writing to or I guess you don't want to clear out memory like that never mind

Alex Stokes: so yeah I mean there's like different more complicated constructions you can think of but it's simpler to just say for example you could say okay if we want this many seconds worth of data then basically just take the timestamp mod

done

Danny Ryan: yeah I know we keep kicking this one back and forth a bit uh I would imagine the execution layer people have a bit more opinion here um I'm definitely of the it it seems like kind of just lazy's not the right word but if we can avoid

having unbounded growth with a simple change I would I would lean towards that

Alex Stokes: yeah okay um I mean I I tend to agree there's no reason just to like have this extra thing for fun in terms of State growth um I'll make a pass on trying to do that and have it ready for the next awkward dubs next week

Danny Ryan: right

Alex Stokes: in the meantime if you're listening take a look

or

Danny Ryan: any other comments or questions for

Alec

and then um Mikhail and I were discussing uh some stuff that comes out of 6988 which is that proposal proposal shuffling mod that proposers can't be slash um it looks like it might break kind of uh at least a property that we have today uh Mikhail can you give us the update on that one

Mikhail Kalinin: yeah sure uh so there is the 69 8080 AP which makes the stash Builder not eligible for to become a proposer and if slashing happens like within an Epoch it may change the proposal set for this ebook but currently we have this

invariant that the proposal shuffling remains unchanged for throughout the so this like this Peaks may break any cash in the beacon note or in the validator client um that we have on that clients may use on the um proposer shopping for the current or for yeah for the current people um and also it can't break some tooling um so that's a question that I think yeah it's very important to discuss before who we decide to have this change

Jacek Sieka: I'll just say right there that Computing

and your shuffling is very very expensive

sorry about that Rico yeah

Mikhail Kalinin: I was just gonna say that it's not like um probably in this case you don't have to compute to recompute a shuffling it's just about if a proposer that you have in this cache one of the users becomes slash so you have to swap these proposal for a particular slot with a new one yeah probate also computationally intensive what worries me more is that

there is a cash on for instance while their client side and whether a client will have to do some you know additional requests every time because it or otherwise will have to track flashings with which sounds like a quite an overhead or whether a

clients

Terence Tsao: it definitely brings more complexity I mean yeah you will break your for preset I'm speaking for prison you break our current um safety in terms of using uh proposal cash I mean it's not doable I mean we can definitely fix that so yeah I don't yeah so that's I think that's our

sense

Danny Ryan: yeah I mean my perspective is definitely um realizing this like a higher complexity change than we expected a few weeks ago when we green loaded this one I guess where I'm at is do we have the confidence to move forward on this or do we want to put this in the back burner to do a deeper analysis and slots in some other time I guess it's not really analysis of the spec we understand the spec it's just how much complexity it brings into clients

Jacek Sieka: I mean the validated land it has to

assume that The Proposal shuffling can change anytime anyway because of reords so I don't know if that's a big deal

right so it's constantly reassessing yeah a question to Terence so there is some cash that you used for that is attached to a um a fork right because I

Mikhail Kalinin: assume that probably body

recline can test this kind of this type of cash five I don't know there was probably yeah anyway yeah

Danny Ryan: brings up another interesting point you can still propose just not on the the parent or the the ancestor that had flashed you which in the normal case you then would be reorg but it does bring out bring in kind of like a weird side Dynamic here so zooming out um there are

it was 4788 there's 6988 there's 70 45 and there's this fixed voluntary exit domain which might have any IP as well um that we intend to build down into the deneb spec over the next couple of weeks to introduce these what are relatively small features in relation to 488 into the uh into the spec so given that timeline I guess we could focus on building the other three into the spec and then four four eight eight I said it out loud Marcus and I realized it was totally wrong

um but we could focus on building these other three into the spec to keep the discussion open for 6988 because this just came to light in the past 24 hours um and readdressed it on a call and and plus two weeks so likely before that call we'd have these other features built in for a release um and then can make the final call at 6988 at that point um does anybody post that gives a little bit of time to talk about this one um and and think about the engineering implications okay I see one thumbs up and here no opposition

okay and that was a point I wanted to make as well I I meant to make an issue before this call tracking the features that we tend to build into deneb from here um I did not but I believe that list of four is correct um did I miss anything four seven eight eight six nine eight eight seven forty five and the DAP lion voluntary exit domain which maybe has a number or not I'm not certain I'll make a tracking issue for that um and note in there that the intention is to build those down into the NAB spec over the next couple of weeks um and we will bring up 6988 in plus two weeks please

take a look at this you know this is um moderate wrench and the intention here or the what we thought was simple here so let's have that conversation and services back in two weeks any closing comments on 6988

um next up is dunkrid which you're very welcome to share your screen if that's helpful uh doc red ran some big data experiments and has some stuff to show us

Dankrad Feist: hello can you hear me

Danny Ryan: yes

Dankrad Feist: all right okay we'll see my screen as

well

Danny Ryan: yeah that's pretty small but I imagine whoa maybe you can zoom in it seems like that's

because she was kind of crazy is

Dankrad Feist: this better

Danny Ryan: yeah any additional amount of Zoom would be useful but um this is beginning to be readable I don't know

Andrew Ashikhmin: zoom in the browser

yeah like command yeah that's looking good um so over the weekend um I was I did some tests on mainnet

um basically I wanted to figure out um how uh the clips of course uh yeah those blogs and all men didn't put um I'm going to share this as well so that you can all have a look at it so basically hey Duncan are

Danny Ryan: you your mic sounds not great are you going through your

headphones yes I hope so wait let me just say is this better

Danny Ryan: quieter but clearer yes

that's good hello yes great okay

Dankrad Feist: great okay okay so over the weekend um I was uh I did some tests but I basically um created large uh blocks on mainnet in order to see how much data we could support um I shared the um uh the the dashboards that uh Sam created uh for this just in the chat so that you can all have a look at it as well uh so basically um we created blocks well I mean this is not the actual size of those blocks but that's how much basically extra data I try to integrate into each block I started at 128 kilobytes went to 256 512 5968 and uh one megabyte

um so that corresponds to between one and eight blobs per block um in terms of amounts of data we added um and uh what we saw was that um for pretty much the whole range the network itself was stable that there wasn't there weren't any crazy things happening um although I will come to that on the second test at one megabyte we did see some we did see one reorged due to the um delayed block um reork that some clients have implemented so uh one to start with and here is like a dashboard that has created that shows

how the bandwidth was uh on on different clients and yeah you can clearly see that on those blob tests that bandwidth consumed went up quite a lot um and I won't go through all so like basically up to 512 kilobytes like and even 768 kilobytes as you'll see like um everything looked very normal and stable so this is the first 768 kilobyte um test um the the red markers they are the um the annotations for when when the blocks were sent the Big Blocks and these are block arrival times at

different centuries on mainnet and on this first test actually for most of them it's like even well within the noise ratio when those blocks arrive like I mean you can see that um even under normal uh like um Network conditions you get blocks arriving up to three seconds um past the past the slot time and that's also what we saw during the tests so that looks pretty good and most of this is just completely normal uh we can see yeah almost a very very small

decrease in the attestation has seen distance for and there's one uh there's one decrease in attestation agreement here on the first

of those

Danny Ryan: and that's head agreement correct

Dankrad Feist: yes I think so although like I mean yes in this case it is but that's unfortunately not what this dashboard always shows like when nobody agrees to the Head then then the zero apparently indicates the block before uh yeah so that is the first 768 kilobyte tests um second one is here on this one I think it looks like a bit more like there were was a little bit like maybe

the blocks were a bit larger I have looked at exactly detail but like yeah you see a little bit more of spiking but it's still within the noise range and and you we also see a little bit more uh people missing ahead on some of these um overall I would say like 768 kilobytes looks very stable to me like this there's nothing I would be worried about in these metrics um so I think we can relate to be safely uh go to up to six blocks per block um and then I also ran tests at megabyte

which would correspond to eight blobs this is the first test which again looks fairly okay in terms of um block propagation well we're sometimes spiking to 3.5 seconds here but when you look at like the other dashboards that's even again something that you sometimes see for not even very big blocks but definitely some spikes on block propagation here um and yeah you

see

Danny Ryan: I think you're on the 756

no

Dankrad Feist: no this is one megabyte

yes

Danny Ryan: okay got it sorry this is the first test um and yeah you'll see a little bit more people not voting for the head here on some of these blocks and then on the second test we saw uh for the first time something's going wrong so like um you can actually stay here so very nicely like one of the blocks um actually arrived um more than four seconds into the slot time and so uh it was uh what actually happened is that it was um orphaned and um that's uh like we checked the next proposal was present so I I assumed that what happened was that they decided it

didn't have enough attestations and intentionally built on the previous block and it was something like they had eight percent or correct

had right

Dankrad Feist: uh I do not know that number

Danny Ryan: I I thought it was in that chat under discussion I'd have to look it

up

Dankrad Feist: okay I don't remember that okay maybe yeah um so yeah it looks like that that's just uh this is what happened I would say the network was still stable but this uh but we just didn't manage to get it um before that deadline but like nothing crazy happened

due to that

Danny Ryan: yeah you can also 92 attested to the parent of that block and eight percent attested to the eyes Okay it shows you you know

something about the kind of delivery boundary

Dankrad Feist: um actually if someone is able to get I haven't get this is this is the slot for that this is the orphaned block if someone is able to get um the block for the slot and could tell me how big it actually was because unfortunately I don't have that number I suspect that uh we met we created a Blog that like some of the later blocks were actually much bigger they were even up to 1.7 megabytes um and those made it in so I suspect that this block as well might have been larger than we were intending because yeah we can't perfectly control how big the blocks are going to be that

by

Trading

Danny Ryan: so given uh given the note stock especially the first one is that enough does that give other people that want to dig into this data enough enough note about which slots uh these tests are happening on

Dankrad Feist: oh yes yeah here in this the second in the stock here and it has all the block and Slot ranges cool so I guess some of the potential orphan blocks become harder to do historical analysis on but there was another actually in the second range there's another missing block but that validator was just offline and so

that that wasn't us it was already offline before

Danny Ryan: um so I do think it would be valuable for if somebody wants to or multiple people want to do a more data analysis on this rather than just looking at these dashboards like better understand kind of the variance better understand there's I guess some of this is going to be hard to do if you don't have Sentry nodes that we're already looking at at this I guess primarily we just have chain data

um nonetheless

Dankrad Feist: yeah so um my I I would say basically based on this that since this is actually quite pessimistic like we are actually

creating those huge blocks but we decided a while ago that we're going to separate block and block propagation um and also uh we should consider that um we were actually going through the mempool with 64 kilobyte transactions so that added an additional load that's not going to exist with the blobs which I have used the more like the less bandwidth intense member where like people do pull rather than push right so given that I think like uh going through like a a limit of uh six blocks and a target of three blocks blobs uh would actually still be safe um yeah so that would be my

recommendation based on these um and the second thing that I was maybe uh want to think or like recommend we start thinking about is whether they um four second uh deadline for blocks is still appropriate um because what we have done is that we have uh now we're adding more and more things that need to happen in this first third of the slot like we we had this four second deadline originally already when we launched beaten chain and back then the only thing that needed to happen is the beacon uh block itself and we also didn't have a for a second deadline

because we didn't re-oculate blocks and since then we have added the execution block which now needs to be propagated and verified we're gonna add the blobs um and uh we are also like we have now added us a kind of block slots um Poor Man's block twice kind of through through like uh the three org um if uh if it doesn't have attestations so I think like they are much much harsher on what needs to happen in this first third and I would think it may be a good idea to think if we want to move the deadlines around a bit in the slot at least it would be interesting to see what we know about uh when like at a

station 7 when aggregations happen and maybe it makes more sense to prolong this first um phase where we wait for the block and um have a little bit less time for the second and third phase because that would give us a lot more yeah first it would make the chain probably more stable and second it would also give us uh make it much easier to like increase the number of blobs a little bit at least

Jacek Sieka: this is really nice two points um if we're moving back times

which I'm generally positive about um what happens today is that there's like a big bandwidth Spike around the time when United Stations are published and then the aggregation publishing is actually not that bad anymore because we remove duplicates much better um so that would be interesting to see like look at when the bandwidth spikes happen and also in clients implement this rule that we're allowed to test as soon as we've seen the block this kind of evens out the bandwidth profile of attestations but I think not outlines implement it in fact maybe only

nimbus

Danny Ryan: sorry what was that what was the second thing you said maybe in business is only

implementing

Jacek Sieka: so the rule for when you're supposed to publish the attestation is currently when you've seen the block or when four seconds have happened

Danny Ryan: which kind of causes potential weird race conditions

right well it causes a

Jacek Sieka: big burst at the first second Mark if you don't implement the first rule because everybody then at the four second Mark sends an at the station like literally the whole uh well a 35 second of the validator set which is quite a lot of validators today

and they all just Spam the network at the exact same moment so so that's bad so if if clients were to implement uh send attestation when you see the block or a little bit after and that would even out that flow um the second good news is that thanks to the split we've also open the pr on the lipito piece pack which introduces a new message uh that's called uh I don't want instead of I want and it's basically uh oh great there you go thank you Techo also does this uh

even sending the I don't want it basically says that I don't want my neighbors to send me a particular piece of data because I already have it so this is really good for Big Blocks and big blobs so if anybody's interested in that kind of network optimizations check out uh the lip P2P spec repo where there is a PR App about this which I forgot the number of but I'll post it later in the consensus Dev are in the channel

Danny Ryan: yeah I'm definitely eager to see some of those types of optimizations

make it through um I think they they certainly complement the type of data analysis we're currently doing was there not a race condition problem with the releasing the attestation right when you got the block is that why there's some sort of like short time delay after

Jacek Sieka: um there is if you send the attestation to a client that hasn't yet processed the block it might ignore that attestation unless it has a cue which cues unknown attestations for the current slot that race is solvable let's put it this

way

Danny Ryan: um I guess so so Docker does have a concrete recommendation which is to change this from two four to three six is that the cards is that uh is this data convincing is there more analysis or additional longer experiments that should be done you know I just temperature gauge on that we have some time to tune this value if we are if there is an intention between the value but we need to begin to have that conversation now it is nice I think one of my goals in this experiment was to see that 2-4 was safe and I believe that

we have that data now which is good um but there's also been the question of and what else concrete for the data that's behind those dashboards which came from the centuries that the devops team is running um is there a raw version of that or an API version of that that people could do more analysis other than just look at the dashboards or are we pretty much sure have the dashboards and that's what we got

um but I mean

Dankrad Feist: I'm sure they can provide I can I can ask them

well this is

Danny Ryan: this is awesome um I really appreciate you taking

it

Dankrad Feist: I would like to also like because I see a lot of like messages in the chat being like very oh we should like start slowly and not like I have a lot of people asking me when blobs are finally coming and there are like several teams which are building products at the moment really needing us like I I think people underestimate how much this is going to be used and how big this is going to be

I mean that's what I recommend you start slow why for the

Dankrad Feist: simple reason that the data that like this experiment it shows

Behavior under

uh unsustained load right uh and it's already it is sustained a bit of effects

Dankrad Feist: it's sustained it's 10 people like 10 blocks in a row

Jacek Sieka: okay okay ten slots I don't know

it's

Dankrad Feist: actually a lot better than I thought

oh yeah and how nice I would

Danny Ryan: really considered trying to do a you know a longer one uh although it just becomes very expensive um if there's value in attempting to do more repeated experiments or longer experiments we can attempt to do so um I do believe there's also kind of a

side conversation going on on the ever pending honest block reorg specification and um if there should be additional changes about the percentage of attestation theme and potentially stronger circuit breaking uh mechanisms so that you know in the event that every block is taking more than four seconds for whatever reason um you don't you get more than 50 of the blocks uh there's hotels on the call no I believe on prism there there's some sort of justification circuit breaker that was said in the chat does that mean like if there's not sufficient blocks to justify they would actually suck your

break and stop doing the

reworks um so there's just such a break here so there is such a

Terence Tsao: breaker so there's so there's actually a bunch of sticker Burger that's defying this back right so we look at whether the parent block is missed I know we don't reorg like the first slot of the epoch and we also look at the participation as well so yeah

Danny Ryan: gotcha okay well let's let's continue that conversation and yes a longer test on Sky would cost multiple hundreds of thousands of dollars

Dankrad Feist: so I mean I well I mean that's on sh it's not that much we could do a longer test

I wonder what do what would we get out of this like what like what what would happen I mean 10 slots is already a lot realistically most things that could happen due to sustained load should happen after three slots already right like what would we learn from at 20 30 or 40 slot tests someone can

Danny Ryan: yeah I guess completely full Epoch a full Epoch and then through a Epoch transition might like that's the only kind of like Milestone thing that's happening is like it does sustained

Dankrad Feist: I mean okay

let's pull Epoch into that Epoch transition do something other than

Dankrad Feist: okay but like the the load doesn't make the epoch transition more difficult I can see

having it in an Epoch transition would be interesting but I still don't see why the full Epoch would change anything

Danny Ryan: yeah I guess my my intuition is that it likely would not but that there might be small things that compound like for example if you know you're having trouble processing everything due to delays and your cues are getting more full or at random stuff like that uh but I agree the actual Network component side of it should be you know if you're in more than three Slots of sustain load you're probably seeing a lot of what you're

expect to see and we can check we might have already hit an Epoch boundary I mean it's pretty

likely since we have quite a few tests okay

Danny Ryan: uh do we have any other questions for Doc red or the data as it currently stands um we can see to the extent the the data can be opened up for a more more analysis okay let's continue the conversation in uh The Simpsons chat or all production Discord thank you very much

okay anything else on deneb for today great thank you

um there is an engine API versioning RFC from Mikhail Nico yep

Mikhail Kalinin: thanks um so there is an intention to start uh starting from Dan to allow for every engine API method only one version of a structure that it can accept because uh having like multiple

structures accepted by the same method brings an ever-growing checks and complexity to El side um and we were discussing this in more details during for a call this week but the question is basically um some of some of cell clients already used relies on this feature that the most recent method the most recent version of each methods in engine API supports all the previous data structures so they can use the same method for sending a for instance for sale in a payload for Paris for Shanghai and for Cancun and yeah the

question is how hard it would be to uh break this Reliance and to get back to a one-to-one relation on sales side between the um matted version and data structure version so that's basically uh the main question for that discussion

I think the main reason that we had the decoupled was so that we could decouple or so we could deprecate old methods as well as update to newer methods outside of forks I can

I could see how we could still deprecate old methods if we linked up the versions but decoupling them from forks I think would be difficult if we enforce a one-to-one mapping

Mikhail Kalinin: so you mean that if any change happens between the forks it will be difficult to switch to a new

method version yeah like yeah the same Fork supports has two matted versions like one is you know we three for instance the other one is before and when we four is available it will be difficult to switch to report

is that what I mean

yeah

Mikhail Kalinin: okay see you say you're talking about when when the same method has the same the same actual data so you you cannot switch based on the data yet you're passing but but just using the latest available method whatever version is it it is and no matter whatever you're passing so if it is Data driven you cannot switch to easily to the next version of it if this data is the same that's the problem

well like we'll take the uh adding in of

the the value of the payload as an example that was a change we wanted um so if we wanted something like that to change it we would I guess presumably have uh a new method um but yeah the proposal is to have a one-to-one mapping like execution payload V2 new new payload B2 execution candid B3 new payload B3 that's what proposal um yeah whereas right now we can have any of the uh any of the underlying data types go with the versions basically the versions have supported all previous data types

Mikhail Kalinin: yeah and so in in order to make this kind of switch you will have to request the um available capabilities and then see that some new capabilities available and start using it with the old data structure I mean like with the data structure of a previous version and this basically what you would probably do anyway because if a new capabilities added between the ports it means that something new has been some new data has been surfaced to CL or some new data are requested from CL so you'll have to anyway handle this

somehow I mean it's not just you know you're switching to before and sending the same basically the same data that's actually how I see

it

yeah like presumably you could create a version like a new method for the interim before the next Fork but that that I mean then we would actually we would have to add a new method like if we we have new Behavior we can't just use it right away with the method that we will use in the next Fork we would have to have a method for the interim

Mikhail Kalinin: yep

and probably it will um yeah yeah so I mean like it it this does not I mean like having a method handling all previous data structure types data types doesn't seem to help much here that's that's just my intuition

we what if we didn't make this kind of a hard roll but like so that we could in the case where

we still where we want to do something between forks we could support two different types but in cases where we only need to do it at the fork then we can keep this one-to-one mapping just kind of a hybrid I don't know if that makes it too complex but

Mikhail Kalinin: um I would say that I don't have a president that who really eager to introduce something you know something in between the courts and uh that would be the case that we will really need these two versions supported in it um I'd say that let's discuss it by that time but by default use one to one I mean like not making any commitments for the future but if it will be reasonable too

to do this way yeah probably why not and the question for Lighthouse uh do you think it will be really difficult to get to get uh back to this one to one thing

no no okay cool

yeah it's just mostly not losing the ability to deprecate Old methods and not losing the ability to upgrade independent of forks which is the point of exchange capabilities

let's see

Mikhail Kalinin: and yeah the bad deprecation of old methods I was thinking about it

so we can currently deprecate with one or V2 and say that with three handles all of those data types but basically we just deprecating methods but these these last uh method version has all the complexity that those method has so in in one to one there will be just you know this complexity um yeah this logic of validation of data types voltages uh layer across different methods while with this approach they will currently have just in one method so I'll speed I don't see big advantage of you know of having those deprecated while you have

all this stuff checked anyway and deprecating the data structures is really a difficult thing because we want to allow for long step sync um since the Matrix since Paris so um that that would be another question does any other HCL clients then Tech when the lighthouse relies on this feature uh just that CL can pass whatever data structure to new payload for instance to the most recent version of it okay so yeah so I think that I can make

a PR if we are agreed on that so I can make a PR to make the blob extension file um certification this with one version

with this drain I mean an additional complication here comes in how we actually switch over because we're now we're changing the behavior unless we enforce it out you know before or something

yeah

Mikhail Kalinin: yeah I mean like this should be this should be agreed that since I know first I guess that the new uh this one-to-one should be implemented and every CL that is not yet it's supported and then we can

plan it for some devnet four four eight four four devnet because you have all those methods all those previous methods and you can just you know start using this logic that you send we want to V1 and we two two and so forth um and then you can El can just you know drop all these uh things from the three yeah and what's proposed is you start to do it since with three but we too will remain

unchanged yeah so let's

Danny Ryan: see how clients can switch over to this new version and then once

we're confident that all the CLS have done that then the Els can migrate anything else on this one okay so you do have that open RFC if anyone else has comments

right

Mikhail Kalinin: yeah yeah sure so and I'm doing talk in

the pr we can discuss it more if any concerns will arise

good

Danny Ryan: thank you Mikhail okay anything anything else under discussion today um I will put together we're gonna have a release in the next day with these minor changes the types in the additional field we'll put together an issue that's tracking the handful of eips that we're going to build into to nav over the couple weeks and we will

talk about 6988 in two weeks please take a look uh this is you know the the change that the proposer with respect to slashing okay thanks everyone take care talk to you soon thanks thanks bye everyone bye thank you bye bye

everyone

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