All Core Devs - Consensus #114

Transcript

[Music] foreign [Applause]

thank you welcome to

ACDC

Danny Ryan: 114 this is issue 8 30 and the PM repo if you're following along on the agenda um cool we we'll go over a bunch of deneb stuff we have a placeholder for the e-star upgrade does that have a name did was it decided when I was gone I saw there was a name that seemed to be potentially decided upon that's a question all of y'all were on that call and I wasn't

Ben Edgington: okay

we went with Electra okay nobody's taken it was just

decreed

Danny Ryan: great as long as it wasn't me decreeing was great Elektra um okay so so we have a placeholder for Elektra um I will I have some comments when we'll get there and uh then a handful of kind of Beck updates and presentations so we'll get into it um on danab just some space for a general update uh devops testing um anything people want to share with respect to progress

Parithosh Jayanthi: uh yeah we had a spoiler Shadow Fork

last week um we bloomed the validator set a little bit so we'd have some spending each one um since we trolls are inhibit now and use that spending each to spam it with blobs potentially find anything useful on the network so yesterday we tore it down but other than that we've just been updating tooling Etc um to make it a bit easier to test for that eight and I think Barnabas is supposed to the rough timeline of when we'd like devnets eat related things to happen on the internet interrupt Channel uh so hopefully by late next week worst case early week after we should have definite

date up and running

Danny Ryan: right and show away how to comment on because the spec release is likely Monday which is one we need to figure out uh an item in here but there's also some renamings that are going into there cool any other General updates or deneb um that uh have a new PR here and thanks for thanks protest and be careful for their previous reviews uh the current

proposal is simpler than the previous one so um hopefully it will get included to the next next release and from client to test yeah and if you have some feedback please comment thanks meaning the release on Monday or any or the nebulous release after Monday hope it will be on Monday one it's got it only three more test cases I'll review okay any other General comments that are

not on the denab agenda okay um I think there's been a lot of discussion about this over the past week um essentially my Boost relay testing we are as we transition into full featured test Nets um with what we expect to be relatively stable features data structures Etc um it's time to begin to integrate you know additional testing around this this piece of software so I'm curious is Alex Stokes on a call

yeah so yeah maybe you have an update on kind of where we're at both in terms of I guess there's two things one is the minimal amount of software and stubs such that consider clients can do testing in these new types and context and then more fully featured such that people on the other side of the party can uh test their setups the builders in real life

Alex Stokes: sure yeah so Mario has I believe it's uh essentially like Hive testing uh for like mocking the Builder API I don't know I haven't looked at it so I'm not sure if they fully support the genob specs but uh it should be pretty straightforward to do if they don't

Perry's been working on uh more Hive testing to actually like run at least like the flashboss software uh which would be amazing um I've been helping some with that and yeah so generally things are moving along uh I don't think the updates to the Builder specs that like for example flashbots would need in their relay or I think even my Boost right now uh aren't you know emerged but that works very much underway so should all come together in time um but yeah this is something we should focus a lot more on over like the next month or so as things stabilize

Danny Ryan: yeah cool I think the main reason to get

on the agenda is like it's it's kind of that that time to transition into having this type of testing um so just primarily a signal but thank you for the update and uh any questions or further comments on this one and we can certainly continue to discuss it in subsequote Tammy Ron muted did you mean to say something

oh no sorry I'm accidentally unmuted myself

Alex Stokes: oh I may be jumping the gun into the next topic but uh I would say the sooner we can actually freeze the spec the better uh because you know for example a lot of the flashbot stuff is just going

to wait until the thrash is is settled um so that would unblock sort of finalize the network with the builders in realize

Danny Ryan: okay other than we are kind of entering into my Boost testing time any other comments or questions okay cool thank you Stokes thank you others that are putting some effort into that shall we you had

um a PR open with some naming and consistency between uh yeah the EIP and the consensus effects do you want to go over that real quick

Hsiao-Wei Wang: yeah so it's still just an issue here um because of it we didn't decide which place we should change so one is about the inclus like it's called version hash version kvg and the EIP has a different name and another one is the custom type description for vlog so they also have different definition please see the issue tickets there so

my preference is updating the EIP and you know I think there are some uh El client depths here and I don't know if does anyone has some strong opinion so uh by the way this is not a blocker for the definite 8 because this two um naming can be just changed without the stake I mean it's not a consensus logic so it's fine so just post sharing here and I hope you will be resolved very soon

and we can finally freeze the dnf space yeah any suggestions yeah if no then I will try to open a PR on the VIP side on Monday and we can keep discussing there thanks

Danny Ryan: yeah cool so if you have comments jumping on this issue um I think at PR being open and

circulated for discussion before the execution I recall would be a good way to keep in mind uh next up we have the PR from agenda that we thought we might be able to get some consensus on early in the week but we're not able to we do have a number of comments since we did discuss this last Thursday a lot of them are in a negative light that we had not previously seen in the calls I really think that we should make a

decision on this today and be done with it again for context uh the parent Beacon route is obviously committed to in the beacon block it is not independently in the execution payload the data structure on the consensus layer but obviously all of the fields that the execution layer needs are committed to within the beacon block so you can kind of reconstruct it from the piecemeal components the execution payload plus this additional field which is passed into the engine API as of today um it works there was definitely some discussion before we made the decision one way or the other uh Ginger brought it up that uh Beyond just kind of

aesthetic reasons it's a bit annoying with debugging um we've since that reopened the conversation we've since seen uh Enrico like client Terence Mikhail and Julio um Echo that they don't really want the data duplication in that in this pattern we should be able to just utilize the fields as they come and Stokes in the chat says Mio we should leave it alone um are there strong opinions one way other that want to be voiced Beyond kind of the distillation of the thread that I just

gave I think at this point given this is what people are working on and given uh some of the negativity and counter arguments brought up in the thread that the default is we're going to do nothing here but there's a chance to Echo otherwise

Mikhail Kalinin: yeah I'm curious what is the reason to add this field actually to the consensus data structures

um I

Danny Ryan: the arguments presented were that

having the execution payload as kind of a self-contained thing from the what is on the consensus layer being able to map that directly to the execution layer allows for kind of this one-to-one mapping such that when you're debugging uh when you're like grabbing things to maybe check hashes or whatever like it's just it's just like a very self-contained thing you don't have to think about Gathering pieces of data from other places obviously like if pieces of data exist in other places tooling is just going to be built to be able to get it um but it kind of adds an additional thing you have to think about

Mikhail Kalinin: I didn't get this because yeah I I don't understand how you can read the execution paper or decide from the

beginning block that wraps it that envelops it so I mean like this field should be should always be around

Danny Ryan: yeah and then you're probably but you probably then have some sort of function or script that combines in a way to check it but sure uh if gojinder wants to Echo some of that uh but when I did say the default is going to be doing nothing I did see a thumbs up from good gender I saw thumb up from Sean and maybe a few other people

Gajinder Singh: I think Danny you have covered it I don't really have anything more to add part number pack that you know yeah it's basically self-contained and then

you can just grab it and use it and also this particular field impacts the state uh basically state that is calculated in the El so aesthetically also it makes sense but I'm fine with not including it and doing a few more operations to just construct it while debugging

okay

Mikhail Kalinin: yeah I was just trying to think about this duplication from the perspective of a client that has both CL and DL in one binary and this looks a bit weird from that perspective because we have this redundant check that the parent you can look root corresponds to

the one that we have in a beacon block and we have this field duplication so um because the engine apis uh basically and a and one of the ways that connects two layers together so the other one is just you know as I've said using the same binary which is not does not exist today but probably will exist at some point in time so I mean like from that perspective I think that this is really this duplication really weird thing that's one of the arguments that I was at the time having

Danny Ryan: right like the engine API leaking even more so into the consensus structures

Mikhail Kalinin: yeah exactly

Danny Ryan: I think we're gonna do nothing

unless anybody says otherwise okay we will close the pr and move on uh thank you for bringing back up for discussion go gender and thank you everyone else for taking some time to consider the arguments here okay next up this is pr3431 um Roberto and a number of others have been doing quite a bit of work in um getting the new confirmation rule specified there is a minimal change to the store

um and how the store is utilized I believe it was a change to the store certainly how it's utilized to enable before this new confirmation rule to enable the functions and the analysis the security analysis um it's actually relatively a simplification but it's something that is necessary I mean the confirmation rule is very high value to get in so there was a discussion point on again confirmation rule side which can be done and implemented independently when and where we should be thinking about the confirmation rule prerequisites the fork Choice filter change

should this be something that is specified tested and attempted to be rolled out the NAB does this need to be rolled out in a high coordination Point like a fork can this be rolled out more iteratively there's just some things that we should be thinking about in the context as we prepare for the next work can someone maybe give us the tldr on the changes and someone gave us a perspective on where how this should be thought of in relation to upgrade

Mikhail Kalinin: um I'll try to uh so basically this change is relaxing the filtering and the

difference between what we have currently and what what is proposed is can only be visible in some really edgy cases that are unlikely to happen on mainnet so basically uh the difference can occur when for instance canonical chain does not have a weakness of the previous people people Justified um while the other the side chain has this evidence so in the in this case um yeah the these new change uh will uh will like allow to remain canonical change to remain canonical so while

today um it's not going to be the case so it will be filtered out yeah while they're all rolling out this change uh so this this is what we should take into account as I've said this is quite unlikely to happen on mainnet but we don't want to um I I this is my personal personal preference and probably the preference of other people um that we don't want to you know um have this roll out um uh take for a month or whatever and from that perspective it is uh reasonable to use a hard sport coordination um at least for uh releasing the

software client the clients um yeah at the same at the same time like all clients will support this change and uh when the software is upgraded um this change takes into that

Danny Ryan: right so there's two ways to use the hard Fork as a coordination point right there's the actually do a conditional logic change at the fork boundary and the other is to you know because there's maybe a three week lead time too hard Fork cut it into that release and know that there's a transitionary period where there might be disagreement during that lead time but to not have to support both Logics

in a single release which one are you suggesting

Mikhail Kalinin: okay so I that that that's that's the question to client developers I don't know if we have this Quark obstruction for the fork Choice rule I mean like can one version be discerned by for at the fourth boundary from the other and uh like the first the first point like the first question what do people think about right now at all um how big of this change it oh there are tests uh basically so uh um it should be fine I mean like this picture is ready to you know to be implemented ready for implementation I'm just curious how people think about it

in terms of

then Kun

Danny Ryan: and there are tests but there are not like Fork boundary tests

Mikhail Kalinin: yeah right yeah correct I'm taking silence as at least there is no stronger position to to do this at

Dengue

Ben Edgington: speaking for uh okay we discussed it a little earlier um I don't think we'd object to doing this at uh but would prefer the option

not to enable it at the fork so that we can we can enable it earlier so that we're not supporting two versions of the four choice in One release

Danny Ryan: right which we don't have a history of doing so right now so that likely represents a lot more engineering complexity

Ben Edgington: right

Mikhail Kalinin: yeah so so the question is does any client uh support this uh forking um work in the fork Choice rule okay so yeah

Danny Ryan: it's not something we've

done so I I doubt

yeah

Mikhail Kalinin: yeah okay so um and kind of related question is whether we want an EAP for it or not I mean like to comply with the process so it probably straightforward to do I mean like in a way that some small changes already in the node or can we like merge it without an

EAP

Danny Ryan: uh this is an interesting one

because it's in the four choice we haven't really done a lot of VIP stuff in the four Choice it's also an interesting one because we're just changing Bay zero instead of we're kind of saying this is the new correct logic rather than uh and coordinating at the net but not necessarily at putting it in the neb solely yeah yeah I understand Sam but this is also it depends as we usually do VIPs and we change past behavior um but this is also it's not networking but it almost feels like changing to P2P

Mikhail Kalinin: yeah it's not it's not the chance to to

the state transition so this is this makes a difference disagreement though actually some networking updates can cancer can also cause disagreement on split use so probably no EIP for this one I mean like I mean it's fine at least from my side

Danny Ryan: yeah I'm not friendly fundamentally opposed but it would be a bit different than the way we've been doing them for deneb you know maybe it

would be an EIP and then an annotation in the phase zero spec on the line that this line has been changed since Genesis via the CIP yeah um I I think we can go either way on that

Mikhail Kalinin: yep so probably it makes sense to create an issue for you know for including this change into the net like so people can you know um buy their hands there find GitHub

Danny Ryan: yeah let's do that and we would have to think about when when this actually makes it into the canonical test vectors and whether

we want to cut kind of future Branch test vectors uh because clients likely would want to wait until you know T minus a few weeks from the fork to actually have it in their main net release right good gender I guess the problem with including in the spec release at least the one a problem worth discussing is that that would kind of begin to force the hand of the client by its CI um to just get this out immediately rather than potentially waiting until just a few weeks before the fork to get

it out um so there's certainly like some considerations on how this would impact mainnet releases and tests uh best generation in in relation to each other

Mikhail Kalinin: I think we can't uh yeah I mean like it is it would be too late to include it into devnet 8. so probably not I think

Danny Ryan: I agree with that okay Mega can you open up an issue so we can Surface any uh potential pushback and or discuss a bit more about

the strategy on how this is going to go under test vectors and releases

Mikhail Kalinin: yep sure thank you

Danny Ryan: any other comments or questions on this one anything else on the NAB so the next work is an e star name Electra there is an issue up we're cataloging things that people want to have for discussion for Elektra I personally

and I'm open to discussion debate on this um I think we should be in the mode where we're maybe presenting these ideas and making sure people understand them but I don't really want to open up the Elektra work what's going to go into the fork conversation at least until deneb settles down a bit more so for example you know there's a quick update on 6914 there's a six one ten overview today but those are more in the context of like sharing technical information then getting into the debate of what goes on um is that cool that we push this back the the lecture inclusion debate until we have a bit more

Insight on the NAB timelines and didn't have stability silences agreement cool moving on research spec and other discussion points um pop had a quick update to 6914 if anybody's following that EIP is Papa Nicole yeah pop do you want to just give us a quick on that

uh yes uh the eip6914 is about using the volatile index uh

uh yeah and initially we already have the EIP to to truly use the index that's that is not used anymore and uh and there is an update on that VIP because uh because uh previously we haven't we because previously we didn't update the the the the selection index in the BOK Choice store so this uh this Pi is about updating the the uh Slash variator index in the punctual store

Danny Ryan: right so like the once you operate an index the past transgressions should be cleared with respect to support Choice

store and so there's an additional Handler called on reused index essentially abstractly when you reuse an index you need to make sure to discard the associated index and equivocating indices in the store I'm pretty straightforward but if you're following 69 14 definitely a very important update anyways doing prototyping and stuff

Mikhail Kalinin: I have a small question here so the intention is to call the cell number used index whenever then you uh while they're with a reused index is created right or whenever you get the index renewable layer start to return this you

know oh so yeah it's basically probably the same

Danny Ryan: yeah I mean abstractly you're calling this Handler anytime between the validator being fully exited the validator being reused um but it's not it's not like hooked into the state transition function it's more like upon reusing the index trigger cleaning up the store um I think that's better than trying to have the dependency of the pork Choice store and the state transition being

explicitly integrated again this is kind of an r d EIP so open to Alternatives and different ways to think about this is there a reason that the EIP isn't in the EIP report right now is it just waiting in a pull request somewhere

oh is it

Danny Ryan: is it a draft I think it's maybe a PR I would have to open up yeah so it's pull requests 6914 and I opened the pull request and it's still sitting there

which means it's my fault um I'll go clean that up no worries I was just looking for it yeah cool I can get to that today there's a like typos and stuff Roberto and a few other people have worked on a document kind of thinking about how to improve spec compliance across clients in this kind of unique domain um Roberto would you like to explain this

Mikhail Kalinin: um I believe prepared so it's not on the

call today oh and a ditch is not on the call today

Danny Ryan: Okay cool so there's this doc uh I think Roberto edicha and Alex lassov have been thinking about you know our unique challenges in uh this distributed context especially thinking about some things like work Choice Etc uh where we probably don't have super high assurances on spec compliance um and it produces Dock and outlying the challenges and also potential things that we could continue to do I am not the one to present this doc so

I will leave it at that the stock exists there are people that are thinking about these hard problems um and people that might be proposing additional Solutions pieces of software and strategies better spec compliance I invite certainly those folks to continue to come to the poll and just discuss these but given they're not here I don't have much more on that

celius

Saulius Grigaitis: yeah so there is one thing that that actually we discussed here internally that's related with spare compliance and I hope I can take a few a couple of

minutes to um to express that and yeah maybe this could be um in line with with what is it's what is in the dog so uh essentially we we kind of often gets to this interesting problem where we see that there is a written specification and there is test vectors uh and in reality clients they are kind of compliant to something in between written specification and test vectors because all the clients seems at least at my knowledge all the clients targets to uh to run test vectors and pass them however there are multiple

multiple optimizations in each client and that slightly or sometimes more than Sometimes the best diverges from the written specification and so for us the the problem here is that if we have a highly optimized code for the optimizations that at some point for ourselves it looked that it makes sense just for example this latest non-finality incident where clients implemented various optimizations that often involved with discarding the attestations that according to specification shouldn't be discarded so for us the problem is that if after

these optimizations test vectors are changed and they covered some some case which was not covered in the Forum then sometimes we lead to you know to huge refactorings like that takes even months to to accommodate some some new test director that was added recently or something like that so so actually we are thinking to make a two modes in a client so the whole mode is is less optimized that tries to fully Target or or Target as much as possible the uh the written specification and another mode is optimized the mode which

targets test vectors uh like you know like a little bit stripped down version in terms of the cases that are handled so this would allow us to quickly bring back the functionality that is closer to the written specification so so my question is uh is there some other team that experiences something like that and see the Asia and in this in the thing that we think that it's an issue or we just going some somewhere somewhere else from the mainstream

with this approach

Danny Ryan: yeah so the question is has anybody tried this kind of dual approach where you maintain highly optimized and much more straightforward version

Saulius Grigaitis: yeah this recorded version is more like a written specification compliant

Mikhail Kalinin: does it mean that the optimized version will be actually used by users and yeah yeah and not optimized one like straightforward one will be used for compliance testing

Saulius Grigaitis: uh no I would say uh this this straightforward it wouldn't be just a

very straightforward I mean the idea is not to just repeat the written specification the idea is to have uh also pretty fast code but the code that handles these edge cases that are that are let's say covered with a more General written specification because you know test vectors are pretty Limited in in the cases that they cover um because these are specific cases not not a general uh specification so so for us this uh written specification mode let's call it that for now would the work just for the um

you know for the proposed that we have a code in the out in our code base uh that is a spec compliant so if test vectors changes and uh and our optimize the version needs a huge factoring then we can easily switch back to to this um to this General mode and this from the engineering perspective this would be much faster than to refactor this optimize the but the users would be running the optimized version

Mikhail Kalinin: yeah but that also means that in some cases user will run the client that does not comply to the spec right

Saulius Grigaitis: yeah yeah but if if you see at least from our understanding that I would say probably all the clients debates from from the speca I mean I'm actually not sure uh did all the clients Implement uh the optimizations for the last non-final incident where uh like those weird attestations are discarded but if if yes then I think all the clients does not uh are not compliant to the spec uh at least from this perspective so I mean I think that that probably

there is no point that is fully compliant to the specification or am I wrong

Danny Ryan: yeah I think there are heuristics used by all clients on anti-dos considerations around which attestations too actually consider I guess depending on where where your view of the the spec compliance is you

could have Divergent you could say divergent or not right if you're looking at just the four choice in the context of which messages were given to the four choice then there's probably a higher compliance but then if you're now kind of expanding that scope to um and then which messages are you going to give there's more Divergence yeah so I don't I don't think anyone is doing the Dual maintenance strategy um I think it would certainly be interesting to to investigate and write about more if you do get on that path another nice thing there potentially at least is uh you could actually have some uh intra client conformance testing right

you could fuzz the interfaces of the optimized and non-optimized um and see if you get the same results so there's maybe a few other things that come out of there other than um have the refactoring speed and stuff

Saulius Grigaitis: okay I think I'll probably try to check this this Docker that you Danny mentioned maybe maybe they are talking about something like that

Danny Ryan: yeah cool so take a look at the dock any other comments or questions in this domain right now all right cool

um if you do have anything in this domain certainly uh reach out to the authors and we can bring up points of discussion from the stock anytime subsequent calls okay next up uh Mikhail and a couple people that have been working on prototyping eip6110 I would like to give us an um and opened up for questions just so we can better understand this feature as we're making decisions in the future again um I think that certainly over the next handful of calls we do have some time if you have an EIP that you're want to get

some feedback on or you're potentially considering for discussion for Elektra it would be a good time to just take 10 15 minutes out of these calls to explain these things to each other so we get on the same page just in general but Mikhail take it away

Mikhail Kalinin: yeah thanks Danny so uh Kevin and c and myself like have been working on on the Prototype and this EAP for like four months um and yeah of course we'll work with so we receive tons of help from Baza team and my house team which which clients we used to in

Fernandez um this change to the design also thank many thanks to peritos and the devops team uh we had prepared a document that is a compilation of our goals accomplishments and challenges all the other stuff so I'll just share my screen now and we'll go over this talk yeah can you see my screen yes yeah so to remind what this EAP is about is basically supplying the deposits on

chain so the way the deposits delivered to consensus layer um is going to be changed by reading them directly from the execution payload instead of relying on it one data poll the thing that we have today and so there is the detailed motivation section in the cap for those who are interested why so there are many many points why this change is really desirable so in this project we pursue several goals one is just obviously prove the design by by implementing it and also estimating the engineering complexity looking for blind spots in the specification and incorporating the

feedback from the development process into this pack also covering the specification with tests have an additional stress testing and just making sure that the design work Works in general so this EAP has a transition period transition from like the one beta call to the new Machinery we tested that as well um yeah and like just briefly go over the accomplishments we have implementations we have spec tests we have a kind of like I would say ready for implementations back now we ran several

multiplayer devnets the stress tests independent on that so like the conversation release is quite impressive on that so I'm I'm deferring it to Kevin and and C to talk about to go over the implementation side

yeah so on the MCL site is EIP ads deposit receive container and this is now an additional field of the execution payload and to process those deposit receipts you basically re use the applied deposit function and these are like the main changes on the CL side

all right on the El side uh pretty much

like we are extending the execution payload of V3 to be like v6110 and have like the deposit receipts to be in it as such like the engine API the new payload and get payload will have a new version of it as well um and also for the yeah to change the block structure we have like deposits roots and deposits to the header and body respectively so similar to Shanghai with the withdrawals um and also yeah so for the blog validations uh we are comparing uh the deposits receipts against um the deposit receive extract from the transaction logs and as such like we need to have a API decoder because

um those logs were from uh the you know the sales side so this is something that's very new um to the execution layer client right yes so uh so the current implementation uh that is Shanghai base is already incremented on Basu and um and last night I saw that you know the 4844 PR from um just in Florentine has been merged so we are going to replace uh um the current implementation to be on Cancun um this is something that's going to be done next week uh yes go on

Mikhail Kalinin: yeah I just wanted to add here that we used Cancun basically um as the basement for this this change

because the Cancun um yeah is the fork that uh this change presumably will be rolled out after and for for best zoo we we used a separate Branch to have a base implementation based in Cancun for testing and now uh the question is about moving these implementation to to the main branch which is actually great um at least in the main one okay so we're rather several multi-pered devnets um which was really exciting um and Kevin Dubin Kevin Nancy do you want to say a few words about it

I can say that for local deafness we

used ketosis um for testing some basic functionality and then we um quickly ran a multi-pier devnets and received help for um for from the EF devops team for that I don't know NC maybe you want to say something about block Scout

um yeah because of our inexperience uh with you know having blocks go working you know nicely with Basu so like there's a lot of parameters that we need to you know juggle with and as well like because uh block scale relies on track transaction um to you know to populate the

historical blocks and of course and there is like a limit of 512 blocks that we can look back on Basu when we're on Bonsai so as such like we need to switch the storage option over to Forest to get over this limits so this is something that's very tricky to you know to discover this issue and then I I don't think there's anything else to be mentioned

okay so for stress testing we we first used a fusser and which allowed us to make like 100 deposits per slot and to maximize the gas limit we deployed a batch deposit contract to handle like

725 Depot 6 per slot with one single transaction

Mikhail Kalinin: yeah and here is kind of results from this stress testing uh there is a block delay uh parameter that output and Lighthouse log so what we've seen is that there is like 1.3 seconds to input the block with 700 deposits versus like several Middle East for an empty block uh this block delay parameter should be taken as a grain of salt because it's uh because the breakdown of this timing um is not like kind of visible

and requires more deep investigation like uh obviously 725 or leaders have been created during this processing after processing this block so some portion of this time taken by the hashing of the state but obviously most of this time taken by signature verification we also not sure if the botched signature verification used for the positive processing in White House so that's kind of a question uh worse investigating if you want to like implement this um new CIP I think that some optimization of war is doing on that front

so I should also say that 725 deposits is really a huge number uh which we should not ever seen on the mainnet but that stress testing was like uh trying to estimate and see um what uh kind of Dos attacks can can be employed by this new mechanism and the Dos analysis in the EIP outlined in the EAP shows that basically the maximum number for 30 million gas block the maximum number of deposits in Block is around 1200 so it's quite huge number

um but yeah the attack does not seem to be like sustainable long term there is also a Basel section uh of like uh really uh deep analysis uh on the performance done by uh Amazon from Vasa team so there are some charts here so for those interested we'll share this document you can take a look so the conclusion of this section mainly so this new uh validation Logic on deposit does not introduce like a lot of an overhead um and surprisingly we had challenges during the work on these prototype so guys do you want to cover on that as

well

yeah so overall the biggest challenge of the whole prototype was Finding compatible basil and Lighthouse versions of Vancouver because our implementation is based on that

Mikhail Kalinin: yeah so like my my main takeaway and my main lesson learned from that part is that you don't want to try to build a prototype or whatever feature on top of a um and on top of a feature that is an active development so we had to chase for you know bezu and

um most the best Lighthouse as well I mean like in in their implementation of 4844 because they were at some stage they were at different uh you know status on on this and yeah I was just thinking it was just incompatible with each other so the reason for that was like we have a spec based on Cancun so it is obviously um reasonable you know to base the implementation of Cancun as well but that's really uh damaged the um the progress on on this project so that's that's to bear in mind for for the future prototypes of this kind

um so the open questions that are still open for this EAP this EAP currently I mean like this design uh suggests the Qs approach so there is no cue for deposits uh alternatively there could be a queue in the beacon State um to rate limits the deposits per block or sorry not per block but rate limits deposit um processing per epoch it does not affect the signature verification at all it's more about like affecting the number of deposits that can be applied to the active uh whether like to the active

balance as well because there are top-ups and with this approach uh like one decent number of the pops can bypass the churn which uh yeah one of the um things that we might want to consider and also the skills approach uh we we try to to do it because like we don't want to introduce any cues to the beacon State we previously tried on that but failed with withdrawals so there is a pushback from client developers but also on the other side we have been exploring the max effective balance the exploration of max effective balance

increase suggests that queues are not that bad actually so we might review this revisit this design Point design consideration especially if if Mark's effective balance will be considered for inclusion probably at the same time or I don't know at around the same time so we definitely need to do like a deeper performance performance analysis on sale uh to look for potential optimization and the signature verification so basically that's the remaining open questions on that and yeah there is a gratitude section thanks everyone who

made this project happen um guys do you want to add anything on that Okay cool so we are happy to answer any questions that people might have on the call if any questions will rise around this prototype or around this EIP VR in Discord

you can find us there

Danny Ryan: and Mars you said yay more validator churn which I know was slightly unjust um just to clarify this did not change the rate of validator induction it just changes the how quickly they kind of deposits appear to the beacon chain to then be decided to how to put into a queue um and so like hitting that that 700 something number changes the amount of processing that might happen in a single blog it doesn't change the mechanics of the induction queue so just to clarify

yeah then

Mikhail Kalinin: yeah thanks Danny for clarification I was not clear on that so what we might care is top-ups with without the queue they can bypass return I mean like they not not bypass the churn they bypass they turn today but they are eight limited that's that's important probably important

Danny Ryan: this is awesome um thank you to the entire team I mean it's it's really badass to see these things prototyped in the end uh before we're trying to make decisions on them so thank you very much

Mikhail Kalinin: thanks everyone

Danny Ryan: okay uh uh great 6110 is on the Elektra discussion list so we will be discussing in due time um any other discussion points for today okay great thank you everyone uh talk to you very soon

uh thank you so thanks bye thank you thank you foreign

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