All Core Devs - Execution #173

Transcript

[Music] time [Applause]

h for

e

Tim Beiko: and we are live uh welcome everyone to

acde 173 um so bunch of Danon uh discussions today so around D 10 I think there's been some new analysis done as well on uh the CL block and blob uh receiving and processing times um some updates on kzg um and I think once we go through that we can uh chat about what we want to do next for denune and then finally uh Carl will give us an overview of the Roll Call series that's kicked off last week

and uh there's an EIP around empty accounts that Dano wanted to discuss um but I guess to start uh We've launched evet 10 and Perry I saw the

devop team put together a pretty comprehensive dock analyzing uh how things have gone so far do you want to take a few minutes to walk through that yeah um maybe Banus

Parithosh Jayanthi: can first set the stage and then I'll continue after with the analysis

Tim Beiko: yeah sounds good and I'll share this is the doc I've just shared in the chat is Barnabas here

Barnabas Busa: yes I'm here yeah I I I Can Begin uh I was just also looking for the doc so basically we launched with 330,000 letters so this is uh just slightly above the turn limit of four so we we started out with a turn limit of five and we wanted to test uh to make sure that the turn limit uh

thing is working the way uh we want it to and in Epo 256 we have uh hit daab and at that point we had about 5,000 wers uh in the deposit queue and a few thousand in the exit queue and a few EPO later I think in Epo 260 we started to see that uh the turn has indeed went down from 5 to 4 so that's nice that's working and uh what else we had a couple of open issues that should be now closed so we found a bug during EPO 32 to 35 during a non-f finality incident that I

have caused by mistake uh that prism uh couldn't think back after the uh chain has started finalizing again but this issue might have been solved already I'm not sure the issue has been closed by Prism and there was another uh issue by teu uh regarding uh some Mass deposits where the teu nodes were not uh voting on the correct deposit had also seem to be closed by now and we have some uh upending M related issues that uh maybe we can discuss a bit later

Tim Beiko: awesome thanks

Parithosh Jayanthi: yeah to continue on

that um we did the devet 10 in sort of two phases so the first phase was roughly 24 hours so we had um the Denon Fork running we targeted a stable blob production so roughly three they weren't we weren't spamming the network uh to any crazy number uh we had arm machines as well this time around um and we basically just wanted to see how the network behaves if there's nothing chaotic going on there was no blobber there was no uh bad block it was just blobs as you would expect in a regular Network um you can see that as the Baseline analysis and things look to be really good um we do see some spikes

here and there and put potential places optimization um most of the charts in the analysis are aggregated across clients but I've also linked all the dashboards and there's often a filter on the top where you can choose your own client so if client teams want to dig a bit deeper into how their particular client performs and if they notice something that's more of a client specific issue I would suggest um hunting those grafana dashboards if you don't have access to them please reach out and we'll create an account for you um the most important ones I think are the block and blob analysis so that kind of correlates how many blobs exist in a block and when things are being

propagated um as a tldr this was just a baseline um towards the end you can see blob performance of a client pair and just say every client is including blob so fundamentally we're good um what we tended was um last evening we started the blobber as well as um uh spamming blocks sorry spamming blobs to a much higher degree um also just a side point throughout the entire Baseline analysis we had TX fuz running that means there was transaction load you can see very often 100 plus transactions in the network um so last evening we started the blobber so we're targeting more um

six blobs all the time of course that's impossible to always hit six blocks but we're trying as often as possible um you can see there are some outliers in CPU or RAM usage but in general things still look quite good um we don't notice anything specifically different on our machines which is also a great sign um Network use did indeed go up and we're seeing extremely spiky Behavior which is also probably the point that um Peter mentioned I think at the last ACD or the call before where uh there's is really burst use of the network uh which we're yet to completely debug why but yeah once in a while you do see extreme

bursts um as a result of the globber uh we seem to have knocked out at least the prism node uh one prism node potentially more uh but Terren has already posted a message on interrupt saying they've identified the issue and they're patching it uh besides that there was a nimbus note that was also knocked offline but it seems to have healed before we got to it so that's a good sign um we're seeing an increase in the depth of the REO which is not a great sign and we're yet to debug if that's a result of the blobber or if that's a result of something else um in general blobs on average are still being included at a great rate but

the extremes have widened um I would recommend looking at the heat map for that um analysis and besides that yeah I think besides that we're still seeing stuff within tolerances it's just the trend that we're seeing very often is that everything is happening as we're expecting it's just our tolerances are limit are being reduced um and there is a note that um the depth of the riok seem to be for some reason higher on te nodes than the other ones so maybe someone from the teu team can also look at into that um and just uh one last Point regarding me um

we got the Mev workflow working completely uh there are blobs being included we only tested this with load star nodes so the M analysis you would only see loar nodes for now we're rolling out Mev on all other nodes but the fact that we're seeing blobs included indicates that M workflow probably works fine now and yeah I think there's some followup analysis from G11 Tech and from enrio from the TECO team so I'll also maybe ask if they want to say something about that

Tim Beiko: yeah amazing work um Perry and Barnabas and thanks so much for putting these docs together uh it's really

helpful to have it on one place um yeah and enrio gender either of you want to chime in with your

analyses

Enrico Del Fante: yeah I can I can share what I uh gather uh two days ago and and and actually yesterday and I updated also what uh the data from from our from three uh to this morning so I can share maybe my screen so I can give you a quick recording stopped recording in progress sorry about

that oh should be good yeah so um I'm sharing here what uh the the the aggregated view of the data I gather so I gather this data from only three teu nodes um because I'm using the the bag logs that we produce uh specifically for blocks timing and blobs timing so what I we what what we are seeing here is that we have um um this graph with the timing at which we first see uh something related to a particular

block route that could be the block itself or one blob that we saw and on top of it we have the competation time which is the amount of time that passes after we see the first block route to complete the whole set of of blobs and block and um this is taking in account the validation so this is post gossip validation so what is interesting here maybe this is the relation ship between zero and the the six so as as you can see we got a pretty Trend going up and um most importantly we have this

percentile table that says so the the mean here is the graph represents the mean so it's U roughly you see in the5 percentile and matches uh accordingly uh but I'm also reporting some more higher percentile and you we can see that um roughly at 09 we can and get around three two 200 millisecond or kind of each block uh each blob added to the block so up to having uh pretty high a wide a wide uh timing uh around 1

second compared to uh yeah maybe five millisecond in when when blobs are

yeah uh so we got yeah

Danny Ryan: so there's not a like this this is generally in line with the data we saw with loar right so not not like a big surprise we just com seeing data

yeah

Enrico Del Fante: yeah it's just confirming that this trend is very very similar what has been reported by lotar so uh removing the the the constant timeing of the validation

that maybe lar is not reporting but the trend is is very is very similar yeah

Danny Ryan: and these absolute numbers are fine and safe it's it's and it's which attempt or which method you try to use to then extrapolate these numbers to main net where you may or may not have concern

Enrico Del Fante: yeah that's the real that's the real deal here so so we got this Baseline that presents our test net here and then how we translate this to an hypothetical a main net Behavior this is where interpretation and ideas may may vary definitely

Dankrad Feist: I don't think you can unless

like at the very least I think you would need to um send non-empty blocks on the test net to get to understand what the actual Baseline is because I think you cannot get this comparison if you just compare to empty blocks like that's not that's not what mainnet does

Tim Beiko: and were were these blocks empty or were was this taken from devet 10 where we had the transaction fuzzer on

Enrico Del Fante: yeah this this is this is data is taken up to this morning so uh and and is taken from theb activation uh so the first uh um blocks that are

empty is just because I think the blobs were blobs transaction were not yet produced and after a while um blobs has been starting to to come in and you start getting these um blobs also with different numbers so and I don't know when these um blocks were were starting being full and I can definitely filter out and and starting gathering this data from a particular slot uh could be maybe interesting to remove the zero blobs zero blocks that are also empty

Dankrad Feist: yeah because I think like that

makes a big difference like like in in real life blocks aren't propagated that fast because they are like more than a few kilobytes big so this pushes just our basine down arbitrarily

I I I'll

Enrico Del Fante: I'll chat with Perry to to set the a reasonable slot to start uh printing this this this graph and I can update you afterwards

Dankrad Feist: right that would be interesting

Gajinder Singh: as as per part's input the blocks aren't empty so they they should be full

and uh from the beginning from from the then

activation

Parithosh Jayanthi: no definitely not from the DAP activation I think it's a couple of hours after because first we want to validate that the 4.1

Gajinder Singh: so but I mean that still would be only very small data compared of empty blocks compared to the entire data set that you have used I think

Enrico Del Fante: yes it's just a couple of hours maybe those numbers will not move that much much unless all the zero BL zero blobs block are always empty

Gajinder Singh: yeah I think it would be nice to

see what is the actual propagation of the full actual propagation SL laty data of the full main net block because full block which is similar to a main net block because load star on my main net note I saw that you know it takes around uh 3.5 seconds for 95 percentile of blocks to show up so yeah we need to figure out and also on the main net there is an additional factor of uh me blocks whose proposals might be delayed anyway because of the communication between uh the Builder and the validator and so yeah maybe even on the minut blocks I might need to filter out for the blocks which might not be me based

to do an actual analysis but even even if that is the case then our uh major concern will be to figure out how to resolve the MV flow so that we don't have an extra latency added over there so all all uh the entire concern is that whatever is this the diff the latency diff it shouldn't have an additive effect uh on on the blocks and if it does have a negative effect on the blocks for example loar would need to uh op optimistically import the blog in the sense that we need to optimistically run validations even before all blobs show up which we don't do as of now but seems like Lighthouse does it and it's

definitely seems like a good strategy so we might try to

Dankrad Feist: currently running the execution client when you haven't received all the blobs

Gajinder Singh: yeah lar is not doing that but seems like Lighthouse is doing sure whether other CLS are doing it or not

Enrico Del Fante: yeah ta is is doing that so um when we we see the block we all already start doing the block import process or the state transition and also contacting the for doing the the new payload API while dealing with blob dealing with blobs side cars and also doing some partial

keyg validation if we in the meantime we received uh subset of the blobs that we expect and we only do the final uh import while uh once once all the blobs have been received so there is a level of parallelism in in Te up to three different streams while is the state transition El importing and kg from blobs

Gajinder Singh: yeah lar will sort of need to improvise this flow and come to what you guys are doing so that you know we don't see an additive effect if there is an additive effect of glow leny on

the

minut

Dankrad Feist: I mean there will be an effect right because it just consumes more bandwidth and there will be an effect because you now need to receive all these things and if one is delayed it's just slower but yeah the question is how big that effect should be and I think that's just much more complicated to know

Danny Ryan: right and extra try to extrapolate

Gajinder Singh: even in the current data we see an additive effect even when for example the bandwidth is perfect we should if for example everything was parallel then we should as we all the numbers of blob is equal to zero and blob is equal to six they should basically align or maybe blob is equal to one and blob

Danny Ryan: no I don't agree with that because yeah depending on the

message you're going to sit somewhere different in the relative mesh so you might might be one hop on message zero and you might be four hops to get message five because they're just they're following different paths in the mesh so like by by virtue of that by having more messages you just you have a higher chance of being a longer hop distance on one of those messages than than other so

Gajinder Singh: but would the high translate into 2x delay which is what we are seeing well

Danny Ryan: it's not delay it's 2x to get the last message

Enrico Del Fante: yeah

Danny Ryan: rather than to get

Dankrad Feist: yeah right and then also this is

assuming infinite bandwidth which is also not true

Enrico Del Fante: I mean the as you you you think that things are not going in parallel but um taking my My Graph in mind uh since the first scene is also going up in time is is actually a proof that things are actually sent in parallel because even even the first blocks or blobs that we receive if in case of uh six blobs we are getting a delay there so it's it's definitely the

bandwidth that is kind of split between blobs and blocks so the first message that is completely sent to the to the pier is getting more time because bandwidth is is us it more

Gajinder Singh: actually on devet 10 the bandd is not an issue because 1 gbps symmetric upload download is there and so what the analysis it might mean that actually things are not being started in and also for example uh P mentioned that lighthouse first transmit the block and then transmit the blobs and I'm not sure whether it's also transmitting the blobs in parallel uh so I think we all the CL

client should go and see whether there is parallelism in terms of the data transmission

Pawan Dhananjay: yeah this is something that we are exploring that I'm exploring on Lighthouse if it's doable on P2P I'm not the P2P experts I've been looking into the code and seeing if just calling just calling publish on blocks and blobs in multiple threads would that gain like would that result in a concurrent publish over lip P2P as well so I'm checking that out and like I'll should probably have results sometime by tomorrow but it might take time because I'm not the P2P

expert

if

Enrico Del Fante: if it was if it was completely uh sequenced from all client I would not expect the first SC to move for me the first SC should be completely constant

Gajinder Singh: correct first be Conant because there is no bandwidth issue involved and for as far as lotsar is concerned there is some serialization that is happening till the point of all the block and blob data being converted into bytes and handed over to the network layer uh so there is a serialization factor for example which load are like engines can't do away with because we have only one main thread running

Enrico Del Fante: so you mean before even start sending anything you you you serialize everything and then you start so this is adding something

that is function of the number of things that you have to send even if you send

Gajinder Singh: yeah so that is because of the underlying noj concurrency model in which basically uh Asing task start after the current whatever it can execute uh in serial and then basically you know the hand

Enrico Del Fante: that's clear so I think every every client should double check the parall level of parallelism in in Gossip sending out

Tim Beiko: um yeah I don't know that there's a specific like that we have enough data here to come to a conclusion but what the people feel is the right Next Step um so there's some comments in the chat about potentially running this on more noes um potentially comparing it to large call data blocks um um it might be worth also like running this on a test net and seeing uh in an environment where like there are transactions in blocks by default and there's like a a larger distribution of nodes um yeah I don't know how the people feel

uh without next steps here

I

Gajinder Singh: I think we will definitely need to test it on a real test net and then only you know make some conclusions about it because uh having it in a data center will not get us near to the real deployment conditions that might exist

main

Parithosh Jayanthi: definitely agree with that one also the setup we use typically doesn't have web 3 signer it doesn't have stuff like vouch we don't use any custom things we're just basically running native clients and that's typically not how meet is run

oh uh po

Potuz: so one worry about like going to test Nets I mean certainly this has to be tested and and there's a danger that we might need to go to to bundling blobs with blocks but uh one thing that worries me is that we have only so many Des Nets to for and uh we are seeing very very serious bugs still on clients prism has had like terrible bugs and every client has for one way or another on their own Fork so I would want to to to wait a little bit before we test before test Nets until the clients are a little more stable

Tim Beiko: got it yeah and so I guess yeah so we basically have three test notes right like we have gorle which is uh

deprecated and this will be the last Fork uh we we have on it then we have sepolia and hos key so um yeah we we want to make sure for sure that by the last one things that are going live or effectively what's going to go on mainnet um but yeah how do people feel about stability in general at this point

um Terren

Terence Tsao: besides the ability there are still things that like we haven't tested such as the M Builder and the relay and Clan cat and that is arguably probably the biggest and most important part because like uh 90% of the main client uses M boost so I think we probably will

need to spend some more time testing it I know we started on low star but yeah be spend some more time testing it before moving to

test

Parithosh Jayanthi: I think the only counter point I have to that one is at least in all the previous Fox we we only tested the circuit breaker before we agreed on Main net um and we still have like a couple of weeks to to test out Mev workflows even before gy for example if we were to agree on it

Tim Beiko: yeah I'm curious how do other clients

feel about this

um um I'd be interested in seeing likeing on a bigger test net um and yes we'll continue to use devet 9 UM until we get another test net up and running because there's still things I think we can figure out and if we can like for example optimize our upload a bit we could see if Enrico's numbers change on devet 10 um so yeah

Tim Beiko: so when you say sorry you said see another test net but do you mean you

want to move to something like Gordy or you want to see another devet like devet 10 or devet 11

um yeah I was thinking G okay honestly and we would continue to use

devet 10 until got it that was dra

Barnabas Busa: uh we were actually thinking about shutting down devet 10 by Monday so maybe we can have like devet 11 with smaller number of validators just for uh running it for a longer period of time but not really for stress testing because running these 100 nodes is pretty expensive

okay yeah that works um as long as we have something because we're

still like uh digging into logs and like understanding how this works

um yeah

Barnabas Busa: yeah we can definitely launch something uh maybe even bigger than devet 9 for devet 11 and then we could have that uh until the point that we would fork early

okay that sounds good

Tim Beiko: any other client teams have thoughts on what they like to do for testing

I guess yeah so if all for all the like eight other teams the people feel I guess like they agree that they need more time before running to like a first test net or are people more comfortable um and and and potentially ready to move forward with Gordy sooner um yeah I I think I'll just call on the

team I don't know gu how do you all feel about yeah just overall readiness

no guess I guess I can say

Lightclient: um I mean I think I've set this for a little while like we are in a pretty good place a lot of things are also on Master now and yeah I mean on the E side this is not really where I think the big decisions are being made so I don't really feel like it's my place to say let's go forward but yes from gu I think we're

okay

Marek Moraczyński: more or less the same situation on nether side I think we are quite comfortable but I think it's not on execution side

Andrew Ashikhmin: yeah for Aron it's the same we are comfortable with um going with the fork on girly but we can wait as well if there is need to to wait more

Justin Florentine: okay yeah same at Basu we're we're comfortable with it not in a rush to move forward

Tim Beiko: got it okay so and I think okay

so clearly on the C then uh looking at uh the Mev Pipeline and and a bunch of other smaller like client specific issues are the two things um so yeah maybe it makes sense to uh yeah decide the next steps on this yell call next week and I guess until then um if we are uh launching a new devet then the main thing um the the main thing we should be doing is making sure that all the clients are uh all the clients are set up with the Mev pipeline is there anything else that we want to

make sure we um we do on on the next evet I see a lot of Thumbs Up and comments around Shadow Forks as well um yeah so if it either if uh I don't know if devops folk yeah want to give an update on

Shadow Forks

Parithosh Jayanthi: um yeah we can do Shadow Fox that's absolutely no problem for ourside we just need to discuss which network it would be um yeah girly just has a big state so that would be the most expensive and I guess either hsky or saoa would be the cheapest

what's the mosts oh sorry oh

sorry please go ahead

Potuz: yeah so for for shadow forks I wonder if there already rollups that are actually testing on 4 a44 I mean as soon as we have a deployment of actual clients that that are sending blob transactions at a more or less realistic Pace like a natural roll up batch posting uh then it would be nice to have those

tests

Parithosh Jayanthi: I mean once we do I I think at least optimism is using girly if I'm not wrong so I guess if we do a girly Shadow for then we can also ask them if they can point some load at us

Tim Beiko: okay and there's a comment in the

chat saying uh there's an OP stack roll up briefly that briefly ran on devet 9 um so we could likely get that either on devet 11 or on a shadow Fork um yeah whatever's the yeah whatever's the simplest there um okay so yeah DEET 11 um so aside from so basically getting the MF pipeline uh set up with all the clients getting a rollup um a rollup implementation running and then obviously every client sort of fixing the the issues they have with their own implementations is there

anything else we want to see out of devet 11 before moving to

to Gordy Stu

Gajinder Singh: so I'll add importing the block and running validations even before all the vops show up so that is my to

Tim Beiko: got it okay and is it realistic to get this done in like the next week or so um such that like either we uh such that like by by next SE call on Thursday we

have a like understanding of how all those things went

Parithosh Jayanthi: yes so we can plan for um just sort of summarizing on the schedule um we'd want to get rid of DEET 9 because it's using the old kcg setup and I guess at this point all the tooling has moved on and everyone's using different Forks so we'd like to turn that off um devet 10 can stay up as long as you you guys decide I think we were default into shutting it off on Monday um after we collect all the data that we need we'll start devet

11 which would just be a longer running small scale DEET so if anyone wants to actually test out tooling Etc they can expect it to last for a while um and we can do a girly Shadow for we plan for that early next week so that by CL call we'll have some more data does that sound okay

Tim Beiko: yeah does anyone disagree with that

Parithosh Jayanthi: and is there any sort of request on the sides of the gly Shadow f um yeah and we'd probably want to keep the

um this yeah it depends we're going to have to see how long we're still going to keep accepting girly traffic cuz in the past I think we had like roughly 3 days worth where we stayed peered to the canonical chain before it no longer mattered um but yeah I guess we can just do a midsize Network it would teach us more about the processing time but I doubt it will teach us much about the networking and the AL native is doing something at the scale of De at 10 just as a

shadow

fork

Tim Beiko: okay I yeah I think that makes sense uh Barnabas has a chat comment about um can we choose a Gordy date now um and he was asking for November 9th

Barnabas Busa: um next week we can postpone it if it's really rushed

Tim Beiko: yeah and I guess that yeah to give context so I think generally what we try to do with test net Forks is have the blog post out at least a week before the fork happens um so the blog post means all the clients have a release that's like people can go and download um that's that's fairly well packaged um so so like if we want to for Gord on the

9th it means basically mid next week we would need the client releases out um with all the clients um does that feel realistic to people and we basically by the time it yeah by the time the CL call happens next week we would be a week away from the fork so um yeah it it would be kind of the latest absolute latest we could post postpone

um it's fine for

Aragon how about yeah how about on the

Tim Beiko: on the CL side um because that seemed to be where uh there was most concerns about timelines

Potuz: I'm speaking for myself but I would say that prism is not ready to

for

Tim Beiko: got it yeah and I guess the the alternative basically if we do the same thing a week from now it's like instead of the nth then you're talking about something like the 15th or whatever on gordley at the earliest uh give or take yeah

Potuz: so again speaking for myself

not representative of the Tim but I see very large and deep changes still being pushed in the branch we are storing blobs on DB directly there's no gash for blobs we are moving that to file storage uh these things are like deep changes these are not just on liners I don't see how this is going to change in a week or so

Tim Beiko: got it and what's do you have a feeling for like the order like the the the time for just larger changes to stay like be done and the the overall code base uh for presum to stabilize

I

Potuz: I do expect this to be of the order of weeks certainly not months

but but one or two weeks

Tim Beiko: yeah got it any other teams have thoughts concerns about this okay and yeah there's a comment so saying that uh we probably shouldn't Fork if def connect uh is going on so um this means we yeah it's

unlikely if we don't do like the ninth which seems pretty early uh for for teams then it means we probably have the fork happen like in the week or so after death connect um at the at the earliest yeah um um and yeah so that means yeah basically the the We R death connect is having Gordy around somewhere between I don't know around November 22nd um yeah I don't know if that SS to be uh and then okay so Anar is a question if we Fork after death connect do we have a

shot of shipping this by the end of the year I mean historically I think the closest we forked test Nets apart has been like two weeks or so so like Dev connect if we Fork after def connect that's November 22nd two weeks after that is November 6 two week after that is December 20th so we can probably get all three test Nets done before Christmas but it seems unlikely you can also shove main net into that especially if we want to see um especially if we want to see things on test nets for you know more than a week um I think if if you really wanted to like push everything in 2023 um and you're forking the first

test net after Dev connect you'd have to have something like a week between each different test Nets which probably means that the same client releases are used for different test Nets um um so that seems um yeah that seems hard given it it doesn't give you the opportunity to like fix any issues that you do see on test Nets between one and the next and yeah yeah um there's a lot of chat going on I don't know if anyone else wants to chime in on on the call directly

okay okay I guess yeah let's see uh how things evolve in the next uh week and talk about it on the CL call next week um but I think clearly we won't be forking Gordy on November 9th um and then yeah if if we're also not going to be forking the week after that because of death connect then it means we uh will be doing it towards the end of November at the earliest um and that also will give more time for client code bases to to stabilize so yeah um any

other comments concerns thoughts around Denon uh testing and Fork schedule

okay uh if not uh Carl you had an update on the kzg ceremony

Carl Beekhuizen: yep uh so as you all know we're now using the final output from the kzg ceremony um which is great but a very important component as that is for everyone to verify the contributions so if you participated in the past and you

know you participated but your output's not in the final ceremony then something clearly went wrong um and we have ways of proving that but this is not something we seeing but it's important to check those so there are two easy ways for you to do this um one is the same website that most people use to contribute s.org um you should just be able to go there uh you can paste in your credentials use to contribute and that should allow you to uh verify the ceremony and claim a pup then there's a second alternative method which is a rust script for doing the same verification it performs slightly more in-depth checks and is a little bit

easier to obviously order that the code that you see is being run so uh if you really want to go in depth I'd recommend doing that so please everyone verify the ceremony

Tim Beiko: thank you um oh and as a heads up you need to be on desktop to do this um a bunch of people have ask this question so um yeah thanks Carl um oh and I guess yeah you had another so we were going to talk about next steps for dun after but I think that's that's pretty clear uh we sort of went over that um but you had another item Carl uh you want to give an overview about the

roll call

Carl Beekhuizen: yes sure so roll call is um

something that myself Anar and Y have been uh working on the idea is it's a neutral platform for coordination between a bunch of the rollups and al2s um so there's a process that uh uh much like we have uh eips and erc's um the new addition here would be rips which is basically changes specific to layer twos um and this ideally allows them to have a little bit more standardization between them there are many things that they've implemented which are slightly incompatible with one another so hopefully we can bring everyone on the same page and possibly even make um some slight changes to the evm if they if

people particularly want but at least try to do it in a standardized way that everyone can see and work on and then the second thing is uh the idea is to have it be an API between uh well like metaphorical API between uh L1 and L2 um so obviously there's lots of things happening in the l2s where it's people bring up points that they're interested in but it's not obvious that whether this is just like one particular team that's interested in something or whether this is something that' be helpful for the whole ecosystem so helping um L1 and all our governance processes to see have a bit more insight into what the needs are from the L2 side of things

and then also from the reverse side of things is to help L2 see when things are needed from them so great example of that is what we talk about uh uh testing on dev Nets by posting uh data blob data um so I'll go back and I'll bring this back to them the mini l2s and see if we can get some of them some more of them to test uh so the idea is just to help these processes become slightly easier to participate in um everyone here is of course welcome um that's not supposed to be exclusionary or whatever uh just help separate concerns so if you want to participate uh jump there's a roll call call which happens uh uh monthly um and

uh you should be able to see that coming up in the PM's channel the PM's repo um much like acde and ACDC and uh also there's the layer 2 channel in the E R&D Discord has been renamed to roll call for participation uh if anyone wants

Tim Beiko: thank you um any questions oh yeah please

Andrew Ashikhmin: sorry I didn't want to jump in but um I just want to mention um we also have an in-person event doing Dev connect so if you're in town and you have some free time on that's the Wednesday um I'll put the the link in the chat and um uh there's there might be some topics you can have a look in if

there's some topics that you you think you might be interested in maybe joining the conversation um yeah reach out to us and uh that would be great to have some L one people involved as well

Tim Beiko: awesome uh yeah thanks a lot um okay the last thing we had today uh Dano wanted to bring up EIP 7523 which is is about uh prohibiting empty accounts on post-merge networks um I don't know Dan or Peter if either of you are on the call to give

some context

Danno Ferrin: I'm on the call I don't know if Peter is so I'll quick summary of this EIP so um the scope really is mostly going toward some of the test data in the reference tests and uh formalizing some some behaviors for clients that meet the standards but what EIP um 7523 um says is that um if you're either the main net chain after the merge hash or if you are on a chain that um has the Genesis post spous dragon and has no empty Accounts at Genesis then if you follow the rules of the specification then empty accounts will never be

persisted between blocks So based on that um clients can make assumptions that they'll never see empty blocks and the whole swath of corner case um that interrupt as to what he you what he do with with an empty block if you do a revert when you touch an empty not empty block empty account if you do a revert when you touch an empty account um if you touch an empty account you delete it from the state that whole um bit of logic that was put in after the Shanghai attack no longer applies um and this it does have impact on some some client design if you're writing um some some State systems and uh um evm that can behave more efficiently if they don't have to care about empty accounts um and they can run

quicker if this you know this uh EIP is presumed so I guess the temperature check here is what do people think about um clients having modes where they're only um working post spous dragon with no empty accounts and um if that's favorable what would be the um how they would feel about um updating all the reference test cases that are post for Dragon to not have empty accounts and not test for empty accounts but only to test in the Legacy test cases so those are the two questions I want to get before before I uh um push this any further elsewhere to make sure that this is something that the rest of allore devs is cool with not everyone at once

um so I

Dankrad Feist: I

think I didn't get the full context but um I I are you aware that with vergal trees at least at the moment uh there will be a difference between uh things like uh positions in the state that have never been written to versus uh position in the state that have just been overwritten with zeros um I just want to make sure this is not creating a conflict with that

Danno Ferrin: so if you're following the evm specs right now um in producing it um it accounts would only get overr with zeros um if self-destruct happened and since we're deprecating that and possibly removing it it um you know I guess there

was one question about doing it within the transaction writing it out and I think we settled on it wouldn't get persisted to dis if it was a transient um storage option um if it never actually actually hit the disc so that is one corner case but just the general premise is that you would never write an empty account um in in normal operation if things are operating correctly aside from self construct in the band mode

Dankrad Feist: okay I'm not I'm not still not sure I understand fully what your change means I just wanted to make sure that the the new state fracture with local Tri would be taken into

account

Danno Ferrin: right it it shouldn't impact it I mean zero zeros on States will still be written I mean that changes nothing about writing a state it only has to do with at the end of execution if you you find you have an empty account or if you start with an empty account um how you would handle it differently than if you end with an empty account so as long as there's no empty accounts in the system um then following the rules of evm ensures that aside from self-construct you won't be writing empty accounts to dis and as far as pulling it off a dis I think that's fairly you know maybe we need to drill into this with this the veral account but I don't see how you know it would affect anything different because the real issue comes in

um there's one corner case where if you read an account that's empty you do a transaction that touches it which would then Mark it for deletion from the system and then you revert that block and then the the touch is undone and the deletion never happens that's the real Corner case that this is getting rid of so you know that I think that is you know separate from what's writing to this um it's almost entirely within the EVMS to make the assumptions and the real impact here is I want to go into the test code and there's a few test that still put empty accounts into post merge test cases and get those updated

Tim Beiko: so so I guess on on one hand it's worth taking some time to just sity check the

the vertical and self-destruct compatibility issues but assuming we did this um when what how do we reflect this in like the the chain activation history so we have eips now that like we've retroactively activated since Genesis this wouldn't work in this case because of spirous dragon so would we say this EIP was like activated as part of like the Paris Fork retroactively in a way or something like that

Danno Ferrin: so it's it's written into the specification there's two cases that matches the second is any chain which has no empty accounts in his posterous work and the first one is the main net chain whose merge block has the hash which is the merge hash so it's

written into the spec that that that the effect of this activates it the merge right

okay

Tim Beiko: okay so yeah we can figure out how to represent that uh and and and and the reason why I ask about this is like somebody who's writing your client from scratch you know do we want this to show up as part of the merge eips so that they can know when they they've get to that point like okay I can assume there's no longer empty accounts or is there yeah is there a better spot for for it to show up but

Danno Ferrin: right and I think that's exactly the question that we need to have yeah um what is the appetite for writing accounts that can't do the full history

of ethereum that only start at the merge or only start with a certain point with a certain set of data from a fork do we need to keep all historical ways to generate blocks in future clients or even current clients and that's a separate Pandora box to open that I don't think we have nearly enough time to talk about

Tim Beiko: so I guess where's the best way for people to discuss it should we just use the eth magicians thread of of this EIP

Danno Ferrin: there is an eth magicians thread yes I think that's the best place to drop your issues

Tim Beiko: okay um any other comments questions concerns about this okay yeah thanks a lot Danel um so yeah people can use this uh East

magician thread that was the last thing we had on the actual agenda uh is there anything else anyone wanted to discuss before we wrap up okay well if not uh we can yeah we can close out here um thanks everyone for coming on and I'll see uh pretty much all of you on the testing call next Monday yeah talk to you soon

thanks you bye thanks thanks

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