All Core Devs - Consensus #117

Transcript

foreign [Music] this is

[Applause] thank you

Danny Ryan: okay welcome to the consensus layer call number 117 this is issue eight five four in the PM repo um focus today obviously I guess not obviously but no today will be on continued on deneb uh we'll talk about test Nets I do want to bring up the testing plan that was brought up a couple weeks ago and make sure that we've put some eyes on it and that we know who's gonna be working on the the CL P2P specific stuff so that's kind of a high urgency concern problem for a lot of teams um then we have promised to revisit the 44 magnet

parametrization so codex is here they've been looking at some Big mainnet Blocks so we can dig into that and then if there's any other inputs or thoughts on the 2 4 3 6 parameterization um we can discuss I have attempt to form consensus on mainnet parameters I actually don't know what the temperature gauge is going to be here so I don't know if that's something we can do today or something we can open the conversation for in the future um and then etan has a stable container proposal which is I think an update to eip7495 that we can take a look at let's get started

so now dencoon devnets um are there any any progress or discussion points worth bringing up today on our public call

Barnabas Busa: everything is half it we have 100 percent proposals and all the notes are up to the head and uh I've just deposited some more validators for Aragon so we're going to be able to check if Eragon is also able to make block of calls and we have indeed all the clients

Danny Ryan: very exciting

Marius van der Wijden: wasn't there some clients that had some issues that like kind of like fix

themselves at some point

Barnabas Busa: yeah but everything has been fixed as of uh last night or this morning

Marius van der Wijden: like do you know like why they didn't want to sink in the first place

Barnabas Busa: is anyone from from prison here maybe

they can yeah Terence is handed oh yeah

Terence Tsao: yeah I'm going to share some likes to learn so why we did not see this issue before so we found a bunch of issues with regard to saving the blobside car uh per the retention window so it's funny I'm happy we're just to test this

for more than 18 days so basically um the saving of the blobside card gets really messed up in the uh the index after the retention window so the blobs are getting like overwritten or deleted so that's why we're having trouble syncing so that's a crazy issue the second issue is that we were using the wrong blob stop now console removable from four to six but we did not update the parameter that's the blob subnetica so we're subscribing the four subnets this whole time so we also fixed that and then the last issue is that we were finally um incorrectly of the blog that's inside the blobside card field know so we were hashing a

block without the stay root before putting the stable in the block so we were so basically all our sidecar had to run um blocked route inside so yeah created testing I'm glad we figured out most of those issues within uh 24 hours

Danny Ryan: yes any other other updates or comments related to devnet eight yeah we have uh are we transaction spamming real quick and blogspam I assume so

Barnabas Busa: yes fuzzing just spamming for now

Danny Ryan: gotcha sorry Justin going

Justin Traglia: yeah real quick we're investigating a potential issue with um basically proposing empty blocks but only with lighthouse which is weird so um Lighthouse folks expect uh me or someone from my team to reach out thanks

Sean Anderson: so uh Michael's actually been looking into this on our team and I think he's gotten to the bottom of it we just haven't merged the fix for it yet um we were doing like multiple for Choice updated it's like quickly in a row on proposal and one of them had the incorrect parent beacon block route

Justin Traglia: awesome thank you

Danny Ryan: other devnet Eights

discussion plan I believe where we left it at the previous call was not having a timeline for devnet9 I got murmurs that that was changing now does anybody want to discuss

devnet9

Barnabas Busa: yeah we said uh I think on the Monday call that nine should launch on Tuesday next week what's the plan

Danny Ryan: okay cool yeah any any uh other things to

share or discuss around that while we're here

Mario Vega: I would like some more time to update the hive tests for the execution clients um I'm not sure if we're going to manage to update everything for for Tuesday so do we want to does anybody else have uh is everybody ready or are all clients ready for

for Disney

Justin Traglia: face is ready

Parithosh Jayanthi: I think the only change is how we're uh deploying the transactions right

Mario Vega: yeah but we are also including more tests uh on the transient storage we are simply more tests on the uh be congruent contract and I'm including more tests on the hive uh engine API uh engineer API simulator so

Danny Ryan: with all additional coverage right

Mario Vega: yeah solutional collaboration okay yeah but it would be nice to have it before the launch

Barnabas Busa: I guess after this but uh we're gonna be quite busy so if we don't do it on

Tuesday I think we will have to push it uh at least another whole week

Parithosh Jayanthi: I think so fine considering the only change is really the transaction and if we want to be more chaotic on devnet 8 we can be next week

Mario Vega: yeah I agree okay so it's only extra coverage from from high upside so if we find anything uh even after the devnet9 has launched we can just report it then I don't think we are going to find anything that breaks down the night so it's okay

Perry

Danny Ryan: were you saying the opposite and saying we could wait a week and just Spam eight more

Parithosh Jayanthi: yeah I think I'd prefer just waiting a week and then having everything that

Hive can catch get caught by Hive and then just focus on causing more chaos and definitely eat next week considering that devnet9 is pretty much just devnet 8 but with one change and Builders hopefully yeah but they haven't necessarily been working on local test Nets yet so another week for Builders doesn't seem too bad either

Danny Ryan: that's the direction I would lean on lean in but I wasn't a part of the call on Monday that um you know made a decision to keep it moving quick

Barnabas Busa: we still have one PR open uh 398 that

have been checking on whether we could merge that is the transaction and receipts is there any holdback for this or can we just get it merged and you don't know it

Lightclient: I mean we didn't test for it

Tim Beiko: hello there's a blocker to merging the pr

or

Lightclient: yeah

Danny Ryan: this is in the eth API not the engine

API

Lightclient: yes okay

Tim Beiko: if the PF is listening this is an easy project with high immediate value

Danny Ryan: um does anyone strongly opposed to devnet9 being at plus one week from Tuesday rather than Tuesday we can hopefully merge this PR and get the hype test stuff we can do more Chaos on dev 98 and uh something else in there but

Parithosh Jayanthi: just one more thing for devnet9 we'll be doing capella Genesis as far as I know

Barnabas has already tested and it was on our clients but just still wanted to mention that

Barnabas Busa: yep I haven't tested direct just yet but I think you should do it because

Danny Ryan: plus one week from Tuesday um sounds good cool anything else on devnets great um a couple weeks ago Perry and team

shared this document just on testing overview there are some things in here related to CL testing so probably um things around Network partitions or long-running forks and resolving those in the context of being able to get blobs or not they're past a print depth delaying blobs delaying blocks and blobs like that kind of stuff I think a number and just maybe some sync tests in the context of blobs based on conversations with infants layer teams you know those are some of the

these like exceptional code paths related to the new P2P stuff around blobs are definitely some of the high priority concerns and items but I just want to bring up the testing plan again and make this a couple weeks ago we talked about this our our bases covered in terms of the tools and the people that are working on these things or do we need to make a more concerted effort in the next few weeks too tackle some of those items I just discussed

Parithosh Jayanthi: just give some updates on this one so um sync testing it looks like the Netherland team has been running some

sync tests themselves I'll let them expand on that if someone from their demand is here but you might have seen some results of that on the interrupt Channel um we still haven't gotten around to updating our own sync test Suite so we're relying on the Netherland team for that uh chaos testing is still a work in progress we're hoping to get that done by the end of the month um we're kind of a bit held up because this protocol but soon and we're trying to get some things prepared before that and Mev related tests there was an issue with math boost not being able to handle Genesis and as far as I know since as of yesterday that's been fixed and they're

actively getting ready to test on local.nets and I still wanted to ask if CL side have had a chance to try it with mock Mev mode on curtosis because if that's working as well then devnet9 we can already test the entire Mev workflow but yeah besides that I will also we're having a call with Mario after this kind of if someone's interested feel free to join that one

Danny Ryan: and if anybody on consensus player teams did have a chance to look at this testing plan since it was first introduced our

our bases covered are there glaring omissions that we need to make sure to show up over the next handful of weeks

okay um so uh can you

Sean Anderson: just like briefly looking at it now but um do we want to deal with scenarios where the finalized checkpoint is further in the past than blob exploration and like how do we recover from that because that would require A 5.6 from like an unfinalized checkpoint I think

Danny Ryan: yes I guess there's two things there one is having a fork that goes beyond that depth um well I guess there's a number of things you can have a fork that goes beyond the depth and actually show that you can't you're not going to automatically resolve before because you can't do da and Fork meaning a partition because you could have done d a on the other Fork even if you weren't um seeing it as your head um and then then there's the resolving from that from those problems I think that it's probably worth throwing what we can at it and these scenarios are pretty exceptional and worth testing do you think does like Lighthouse Etc

work from starting from a non-finalized checkpoint from a subjectivity or is that just not something that's been coded up before

Sean Anderson: uh it would be nice to test especially if it's like it would be a requirement to recover from a scenario like this so

definitely

Barnabas Busa: it's already 20 days old or 22 days also it should have some expired blobs and it only has a single archive node that should have already update in there so we should be able to do all these kind of tests under the date I think

Danny Ryan: yeah one of the one of the things though is to make the network not finalized for the depth of the pruning period so on the order of weeks unless we change the parameterization of the of a Tesla

Parithosh Jayanthi: is there actually any objection to change that for depth at 9 because we could do this test there and then keep the period as like 1D or something

Danny Ryan: yeah it's probably worthwhile having like a much shorter print depth because I think you can get a bit more chaos it's certainly changes the load requirement because uh from a certain perspective because the amount of data

that blobs that are going to be stored locally for each one becomes much much shorter um but I do think that if not devnet9 some sort of lick side chaos net um seems really valuable to put it on a pretty short term depth I think things are going to fall out

Barnabas Busa: all right but do you mean the ejection balance should not be 16 or

Danny Ryan: no the pruning the pruning period so it's like three weeks um parameterized but you could make it half a day or a day um and you can do a lot more chaotic things around that threshold if you do so does that make sense

Parithosh Jayanthi: about once we're happy with uh some base level of stability um you can just start like a line of distance with attack Nets called attack Nets leave Donuts alone so people can do that tooling and stable testing and then we can have all the chaotic testing on our attack net

Danny Ryan: yeah I think I agree um especially in the context of like if we want devnet9 to look and feel like the thing that we're going to launch um it should probably look and feel like the thing that we're gonna watch okay cool um there is a there's a testing call on Mondays I think it was pretty low

attended on the consensus layer side uh this this past Monday I think it's every other Monday um and I think as we are moving towards ironing out the final Kinks that's definitely worthwhile having some more attendance there um what is the pruning variable it's in the P2P spec on the net if I can pull it up men epics or blob sidecar requests and I'll send the spec that it's for

them

Barnabas Busa: right so that's uh 4096 uh a box at the default which is 18 days

Danny Ryan: yeah um so you know 128 or 256 you know half a day or a day it probably gets weird if you make it really short but it might be worth playing with you okay all right cool anything else on uh testing conversation for today great thank you

um so outside of the open uh it's even if it proves tough to make decisions today it's time to reopen the conversation around the mainnet parameterization for the blob data gas limit I think maybe that name was changed or something but blob gas limit essentially the gas line um so codex is going to kick it off uh they've been taking a look at Big mainnet Blocks and the information we can parse out of that codex

let me take a share okay so you hear me

yep we can hear and see you still see the slides see your screen that's what I meant do you still see the slides yeah yes okay yeah yeah so let me just uh quick uh background so yeah I'm sure from the Codex team uh we are not many working on on the Central Storage but we are also working with an inbox team on only P2P and we are working with ef uh with a gland on data available sampling and what we show here is uh kind of a side product of that work so as part of the database sampling we were looking into gossip sub performance and uh especially to understand how it works

now onto the network with Big Blocks and with small messages we're going to show you that now and then we also had some nice findings on about big box now on the on the network so let's just look into this how Big Blocks work now in the minute uh so that was uh the big block experiment uh my data Foundation I think you're all uh aware of this so uh there was a capacity testing of the mainnet in which large transactions were submitted which then made it into large blocks which then could finalize so here you see one example one of these blocks uh that was one megabyte in size and it was nicely finalized uh so this would be a

nice result for the experiments nice big blocks can be finalized but the experiment was about much more uh besides sending these uh big transactions which we came into Big Blocks uh DF was also setting up the Sensi nodes so I don't know how much you will uh this Sentinels are uh was set up in three locations in each location uh each uh client was running basically depending on the time period a few of instances with running in in these locations and then metrics will collected uh well client implementation so here you see the dashboard which was shared previously in which you see delays in seconds and

some distributions of these and here she see the below the design dotted time instances when blocks were big and we wanted to get a bit more data out of this so we were looking into details and this is what we got so if you look into the into latency data and you look into the blocks and then you categorize blocks according to block size then you can basically plot uh how different block sizes are getting diffused in the network now this is not one block one block diffuse in the network because for each block we have only a few measurements but if we take a

large number of blocks between 64 and 120 kilobytes for example uh and we have measurements on all of these uh then from these we can plot a CDF so what you see here there's an orange curve for example is a large number of of blocks detail is that size uh and latency measurements uh on these the latency means uh the latency compared to the to the spot start so when uh client implementation was saying I have received this block and what you see here is what we expect so the bigger the block uh the bigger the delay uh the point that you see here that highlighted is uh 64 128 Kilby block uh 80 of blocks arrives before that time

which is kind of two percent two seconds a little bit less than two seconds uh so this is really nice uh we've seen since the diving we've seen the increasing delay uh we wanted also to quantify this delay but we were running into a few problems and the promise was that looking at uh different client implementations we were looking uh seeing different numbers so the figure that I was showing you for was for please but then if we look into into the uh different clients and here the client means the client receiving the block so not the client which was originally putting the block on the network we don't know that this is the client which

was receiving a block and and we see these kind of differences so as you can see there are differences and we already know that these differences are uh passage due to the semantics so so the meaning of the timestamp that we have as a latency is different in different uh different clients uh we need to know that there are some clients I think Disney is one of these uh which are exposing uh the timestamp when they receive the message on the gossip sub others are doing uh or the processing that they have to do and then they are exposing the timestamps uh I don't know this is just a guess others might have low priority reporting set so so they might just have a timestamp which is very different uh so we don't

know the other things behind uh but we have different spells for for different clients uh we were also looking into attestation latencies I'm not showing that now the the facilities that uh this has very small messages but we have lots of them so we have much more data to plot some uh this is what you have seen with the Big Blocks and then uh looking into this we had also some nice things which uh is that

hello yep okay

yes so uh looking into this uh at some point uh we started looking into the data sets that we have uh with with the group Amigo labs and we discovered

that we observe also other Big Blocks um in present uh in the network can you pass to the next slide and we noticed that these were out of the period uh where we were doing this experiment of injecting uh large transactions to make large blocks in purpose uh and so we noticed that there were organic uh blocks that were really really big in mainnet and so we did a study on this so here we collected data over the last six months so from March uh to till the end of August and we found that about we have over a hundred thousand blocks that are larger than 200 kilobytes knowing that the average block size in mainnet is about is about 100

kilowatts so this is about 1.3 million slots and so 109 000 is about eight percent of the blocks uh have these uh kind of big sizes the biggest block was uh in this six months of period was sent about 15 days ago on August 22nd you have the slot on the screen and the size is about 2 0.3 megabytes which is really really big I mean surprising um at the beginning we didn't know that we could have such big Big Blocks next slide we can see here just to have to give an idea of a distribution of the of the v-blocks this is all for blocks that are over 250 kilobytes um here we don't see really well the

Distribution on the right so if we pass to the logarithmic scale we can we can have a little bit more more understanding of of what we see on the on the side of uh large blocks next slide and so um yeah what what is interesting about these large blocks and the fact that they we can find them organically in in uh in the in mainnet is that we can use them to compare uh anybody can basically use them to compare how block propagation um happens uh for for this kind of large block so in this in this figure you see for example uh that between blocks of 250 kilobytes uh versus 2.5 megabytes uh we you know it takes about two more

seconds uh more or less in average um and so you know this kind of studies I think um I think help a lot as we move toward uh you know uh dank Chardon and very large blocks and again uh it would be nice to have like some kind of homogeneity on on how the different clients report this so that we see more clear distribution and and and we can convert resource across clients and yeah just to finish we have some resources here so if you have questions to answer

yep go ahead

just wanted to add that on this Slide the the time axis uh the x-axis is Logitech scale so that's why you'd see a different shape from the

from the previous one so you have one second is the one thousand and then ten seconds to ten thousand and you see yeah look at it thanks

right

Danny Ryan: so another question um is this the compressed or uncompressed size because the size Channel ether scan I believe is uncompressed

yeah we have discussed this uh this is the the uncompliced size so uh now we are collecting the composite sizes and we will deploy it as a function of content size uh actually both both metal so complex size is metals and network uncomfortable Science Matters in the complexion and processing so it's also interesting too to see those differences

Danny Ryan: yep thanks

yeah we were sharing these links on the

in the issue description so you can go and uh and check out uh these are uh uh Jupiter notebooks so let me play with them

Danny Ryan: this is awesome um any other questions for the Codex guys um obviously I think one thing that we need to contextualize here is these are sent as single payloads versus uh the method of serving blobs um via them being broken up into the different subnets is going to have a different impact on how they're propagated but still I think it's very valuable um yeah so any questions

yeah I mean in the meantime just too little from my side the the goal of of this was party to look into the also into how small messages will propagate and uh and for that we were looking into it yet the station latencies we didn't put it in the slides uh but that's somehow we defend the two we should also have an understanding of how I'm making up uh things we really can uh in in visual constructs

there's a question about the description of the methodology used to collect the items data uh I think is this is not describing the in the notebook uh links that there are in here in the slide but we're writing right now post and Brad is going to be ready in a couple of days

describing all the

mentality

yeah in in the first link uh Brock says latency uh you have a at the beginning you have a link to the to the EF post about the present the notes and the setup so that the times was part of the question and then you have a methodology to derive these results uh maybe it's important to say that behind such a distribution a curve heal you actually have a several random reliables you have uh at some point the block was put in the network then uh the network was getting to all the nodes in which we are sampling in a few points and then this is an aggregate of of many blocks of data collected from manibox so

so for the one specific block uh this curve would be steeper but when you are adding it up for for several blocks each one finding this pass then you will get

Danny Ryan: uh got it

yeah I think it's uh yeah from our point of view it would be really interesting to understand who is reporting how and maybe agree on on unifying this or if just exposing them all timestamps uh so that we have better data

Danny Ryan: right around the the client disparities we're seeing here

yeah around these differences which every child kind of

huge differences so uh but but we really know nothing some of the teams that the difference is uh it's just we don't have the full picture of who's who's doing what in in the reporting

Danny Ryan: right or I guess since we're here our clients immediately aware of like the disparities here you know why maybe lodestar reports a much longer number like maybe it has to do with finishing up a database operation or something like that

dapplion: yeah we are aware we'll look into it

yeah I'm just I'm not even sure the timestamp is coming from you or it's coming from the from the login go to the posting so that can be also uh I think for example you are depositing another applied the key and then it's getting time stamped much later so it's just this would be good to

naughties

Danny Ryan: okay thank you um any other anything else for on these experiments um I think Dakota says would be happy to take questions asynchronously as well yep thank you

yeah absolutely cool thank you this is great do we have other inputs other than these large block experiments to take into consideration as we have the conversation about before mainnet parameterization you know our devnets work our devnets are also toys compared to probably mainnet topology um is there any any comments about the devnets and n36 there

Sean Anderson: um so I guess it might be interesting on devnets if we had blocks with like that

like took longer for the execution to happen it's like we could test how different execution times impact our block processing times

Danny Ryan: because this is going to impact propagation probably not because propagation happens before that but it might impact like local import times which are relevant to attestations or what

Sean Anderson: uh yeah also block production which would be like the first input to

Danny Ryan: yeah and I guess it kind of to etons question uh If you're receiving three six blocks at three seconds and you have

really long processing you might actually not attest to them correctly so I see how it does compound okay so there's not a lot of uh I think there's probably not a lot of inputs that we have beyond our observing what we what we've just um and maybe there's also not a lot of more updated thoughts on it uh so conversations a little late today I then I I guess what I'll say is we need

to keep having this conversation over the next few weeks um and because the the lack of conversation here doesn't make me feel like we can try to make a decision yet am I reading the room right yeah I could say that my feeling is just probably we haven't did already the the tests that are needed the cows that needs to be created to actually exercise those those bad and difficult stuff uh the current death then it will be has

been or well used for bug fixing so far this is my my feeling so I think they the the actual test on these things should start now that clients are kind of more reliable and we can actually fire uh stable test Nets and then start playing with these partitions and delays all right so chaos and load from here and help inform the conversation okay uh this is something maybe we won't bring it up next week uh but we bring it up in a couple weeks

to at least make sure that we're getting the data that we want anything else on for for parameterization anything else on the net okay tan um you can take it away with the 7495 updates and looks like uh dapline threw on something last minute to talk about after

Etan Kissling: yeah sure um so as part of this ssce transaction and receipts work that I mean I started

this a long time ago maybe already half a year I think but um the current approach I tried to unify these unions and normalized approaches and I created a construct called a stable container like it's an SSC container crls is very similarly but it can have optional fields and they get skipped during serialization but they still consume space in the miracle tree so what this allows us to do is essentially to have something similar to a union where some objects have some of the optional field

set and other objects have other um field set um but the cool thing is as part of the Merkle tree the common fields that are used they always miracleize at the same location so if you have a merkel-proof verifier for some of the fields that like just doesn't care about the rest that verifier doesn't need to change all the time anymore so I was wondering whether this table container could be used for other purposes as well one idea is to for example attach it to the execution payload header so that we don't have to worry about those bombs

anymore where every time we add new fields and it reaches another Power of Two we break all the verifiers um or like some other structures as well and also in in the vocal specs there is currently an older version like this these optional fields are there to as part of the transition logic I think and there we could also use this stable container just because it's much more compact um in serialization the optional Fields there they just don't consume any space and like a zeroed field or I think the option allows it doesn't do space so

yeah whatever I mean question there is just uh I'm looking for reviews for EIP 7495 and also maybe an estimate how complicated it would be to get it into the various SSC libraries um yeah a channel in Discord if there are questions is the typed transactions Channel or just in the EIP there is also a discussion Link at the top that's all for now

Danny Ryan: yeah any questions all right take a look at it and uh

follow up Ace information thanks a

Tom tap lions

dapplion: hey so I'm linking this PR that opened a while ago and I'm bringing it up now because it only makes sense if we want to do this for thankful which I know that is zero appetite on changing anything for them at the moment but I think the pr holds submitted and I think at least dunkard and some other people showed um interest to do something like this so at least I want to bring it to everyone's attention this is something we could do and it

only makes sense if we do it for then so if we want to do it for the code we have to do it basically either now or very soon so the background here is as you know the network is growing at a very rapid rate and if we don't do anything about it it will reach levels that could trigger some scenarios that we may may be problematic uh the way to address this on the long term is changing the rewards curve but doing this would require a level of research that we cannot afford for Denco so it will take at least for the next Fork which would be

being optimistic meet to meet 2024 maybe later which at what point the network may be at a level that's again triggers this undesirable scenarios which is basically too much if stake and dangerous captured by lsds having State size to a level that clients cannot cope with it none of these problems is truly catastrophic but it could be so the idea of this PR is let's limit the churn so that at least we buy some time and whenever we come up with a definitive solution in a year or half a year or two years the network is still

at the size that could be manageable and specifically if we go for some solution since it's changing the rewards curve to encourage stakers to leave if we already have such a big um but later said I think it would be rather complicated to undo so again just take a look at the proposal think about it and if we want to do something about it we should do it now

Danny Ryan: thanks

Marius van der Wijden: can you quickly explain for Layman uh

what this proposal is about

dapplion: yes so this proposal has the intention to limit the growth of the ventilator set just by limiting the charm coefficient So currently the growth is exponential with mobile editors the amount operators that we allow to enter the set is proportional to that to the number of active so what this proposals specifically introduces is a Max so that the maximum number of validators that are allowed per Epoch remains constant and doesn't keep growing with the set size

Danny Ryan: just a note so it

you turn question grows with the set size because um essentially as a function of the set size to keep the same security parameters with respect to the subjectivity period you can change the set size only so much uh per unit time as a function of the set size and so that's why it does grow with it obviously there are other considerations how am I going to play these years so it bounds it to be linear as a Band-Aid uh well people think more

deeply about more Sustainable Solutions

dapplion: yeah this book was always the minimum that we can do that could be considered somewhat Fair like any other solution that tries to mitigate the problem becomes either really political or security sensitive and would require more analysis I think this is probably the only one that we could accept without a long time looking into it I mean there are definitely some considerations that Danny raised about fairness for people that want to enter before and after this change but I think it's not incredibly significant compared to what

could happen Downstream

Danny Ryan: yeah to be clear I I don't think there's a like perfect Band-Aid um and so if there's an appetite for Band-Aid this seems in a reasonable Direction um but I'm I'm not gonna throw my hat in the ring too much on if this should modifier spec at this point recording stopped recording in progress um is there are there other comments

today

Barnabas Busa: this is actually going to be considered for

dental

Danny Ryan: the answer is no no one speaks up and says something that has to be has to go in but here we are talking about it

dapplion: well in this course you have to ask the negative question right let's say is someone against adding this

to

the nib uh I

Sean Anderson: I think I might be I'd have to think about a little bit more but my two cents generally is that like this is sort of a patch fix and it's it is really small but it's small enough that like we could do it in its own pork in something equivalent to like a difficulty bomb delay or something I think it'd be better to put more effort into a better fix and also like I don't know

clients are continuing to improve how they handle larger validator set sizes stuff like that yes I I don't think I'm in favor of it at this point but

Danny Ryan: yeah I mean this is one of those things that is uh you know happens late in the cycle urgent or potentially urgent things come um I think at this point given the state

like the default is to do nothing and that I'd want a pretty loud we need to do this um if we're going to derail that obviously uh if I'm mystery in the room then be loud and tell me otherwise but I think we need we would need people to be speaking up um you know and if if that means review the proposal and sit on it a week and we talk about this you know asynchronously or even bring it up on the Executioner call that's okay but I I do think that we're at the default stable spec unless it's quite a verbal consensus here to switch

okay I do encourage you to look at and review this proposal there are High urgency problems in this domain and it's going to be probably a big part of the Electoral conversation if nothing's done no um so let's continue the conversation and if this does Bubble Up as critical higher urgency after others have reviewed this I thought more deeply about it this week speak up thank you

dapline

Tim Beiko: what is literally rewarding me uh I was

just add one thing is that sometimes things happens non non-linearly so you got you arrive you reach some level of things and things go bad very quickly so it's something that they're definitely is let us thinking for a while and I'm personally not against this proposal but to what would you also have all ski testnet ride about to be launched maybe this could be could give us more insights and prioritize it uh eventually in the

dapplion: right I want to mention if it's not

clear maybe in the proposal there are two angles so one is the state growth and what can that cost to clients and performance and the other one is the economics of it specifically if you don't believe that Lido having a hold of 50 of all the Ethan existence is healthy um there is a train of thought that the only way to prevent that is by limiting overall if stake because of the one Winner Takes all Dynamics so just to consider

Tim Beiko: yeah I was thinking only on the technical side of it at the moment

Danny Ryan: it's not actually I think abundantly

clear to me that by just changing the total amount of eth that it will be staked by a different limiting mechanisms that that would change light of dominance maybe tougher because you might have sticker short-term equilibriums but it's not I don't know if that changes like the convergence there are the incentives there yeah yeah I'm very concerned about it prevents later from having basically having a higher market cap than ethereum in terms of liquidity

Sean Anderson: this is just slime like the process of

that happening though it doesn't actually change it from happening

I think the argument would be it slows what happens to them have a more sustainable solution um before the equilibriums are totally out of whack nankara did say in the chat um he's in favor but uh and if we don't do it this probably becomes like a very

high urgency thing right after before how complex is the chain yeah it's essentially a not quite a parameter change it's like a parameter addition and conditional on at the fork it being constant rather than a function but it's a couple lines okay is there anyone's suggestion on

how to move forward do nothing let it marinate for a week make sure the spec is correct with tests in case we do want to bring this up again next week like what's the path

Tim Beiko: I'm not sure if this was discussed on AC DC before but on the execution side we typically try and not include something in the fork the first time it's brought on the call just so folks have you know a couple weeks to to review it yeah I don't know obviously the closer the farther we push this out the the

closer we are to like test Nets and the morning cups specs finalized but I don't know if given the small size of this change and like this sort of weak-ish consensus that there seems that to be around it it might make sense yeah delay another couple weeks before officially inconvenience

dapplion: so I want to point out that this is not the first time this is brought up this was brought up in call 113 on July 11th for the first time

Danny Ryan: is this something that we can put as a

special agenda item on the Executioner call in one week and uh people can go back to their teams and talk about it and either come with like a strong yo or strong yes from various teams so that we can push ourselves out of the murky equilibrium we sit in today and in the meantime we can review the spec and make sure that we're good on tests in the event that this switch to go in

dapplion: or maybe here if danker wants to help on writing a piece to

to help get the arguments through and why this is important

Danny Ryan: I will leave that to uh the docker if he wants to if we're sitting in like the UN super uncertain Zone in a week then this isn't going to happen so talk with your teams please try to form a consensus on whether this is you know verbally precisely where you'll stand um either as a team that'd be great or if you all have differing opinions to express those but if you can express

those you won't make time we can make a decision thank you Dad playing anything else for discussion today Barnabas

Co

Barnabas Busa: launches in one week as in eight days next week Friday is the lunch day so hopefully client teams can make a release before the launch day and uh everyone is ready

to go

Danny Ryan: very exciting thank you

Parithosh Jayanthi: and if you're a Genesis validator and don't know about the coordination group then please reach out

Danny Ryan: okay anything else for today great thank you and big ask talk to your teams sit on this proposal come with strong opinions on the execution layer called in one week time

thanks everyone talk to you all soon thanks bye

thank you bye bye bye

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