All Core Devs - Execution #180

Transcript

[Music] J all

for sweet

Tim Beiko: welcome to acde um number 180 uh so we have a bunch of stuff to cover today um including a very last uh minute Edition about uh blob spamming breaking Dev 12 um but yeah so first uh we wanted to chat about the Basu maget event and we uh basically made that bug sorry and um uh yeah we've been pushing this back for a call or two now so I've put that at the top so we can get through it um then let's shout about

Denon and we'll do the devet um conversation as part of that and then obviously sort of reflect on how uh sepolia went and uh after that hopefully the bulk of the call we can spend uh going through the three big things we've been discussing uh potential candidates for Prague and potentially the fork after so veral eof and 4444 um and then lastly there's three small things people wanted to talk about we'll see if we have time but uh worst case we'll just uh at least point to them and folks can chat async about it um but yeah I guess the kick it off uh

is Matt on the call yeah Matt do you want to give some context on the Basu agenda item

Matt Nelson: yeah absolutely um so as many of you know uh January 6th of this year we had a halting event with Bas nodes on mainnet it was not all of the Bas nodes on mainnet it was probably somewhere between 60 and 70% of the nodes um we of course have shared a pretty detailed postmortem um so if if someone is is in the chat for my team would love to paste the full link that would be great but I'll give a quick overview of what's going on uh that we kind of discovered um what we uncovered was that a lot of kind of freshly funded

accounts were experimenting with metamorphic contract deployment in a way that was exposing some edge cases uh in in basus implementation of the state database called Bonsai um you know we we've shared tons of information on Bonsai in the past but uh we we viewed a few of these kind of iterations of metamorphic contract deployment when I say iterations it means that there were they're intentionally different edge cases that we noticed um you know that we had been kind of also slowly patching in various releases so we first noticed um these things happening on some of our Canary nodes on Gurley and sapoia um uh prior to the January 6th event so we noticed again some of our canaries going down on on those other

networks um you know we would we were noticing some issues and then we were patching them as we were going along but on the main event on Main net on block 18,9 47,9 183 uh that was the big event for what we triggered that caused kind of the the the the big halt um what was happening that we noticed was that the pre-image uh that was being created uh for some of the block or excuse me the pre-image for that specific block um was being written incorrectly uh for the trialogues and the way that

trialogues work in Bonsai is that it's a Delta between you know the state and in one block to the next um and we were incorrectly writing a pre-image uh in that for storage that was self-destructed uh to the triog so when the block was rolled from one state to the next that would be considered invalid State um we were not parsing that correctly uh and then we were considering the block invalid in some cases which would cause the Bas notes to go off on a fork and then in some cases we were just simply halting the node um we noticed again that this was happening we provided some mitigations for users on mainnet um asking them to resync uh their node in some cases to avoid that kind of problematic trilog since we're

not generating trogs um as we kind of do the world State sync so if you were able to sync past the the problematic block you weren't writing that incorrect pre-image to those Bonsai trogs which means you weren't applying them as you rolled the block uh from the uh previous good block to the problematic block um this was all well and good uh we had again mitigations in place we were able to put out a patch uh how we were able to discover this was was kind of a kind of collaborative effort which was really exciting to see we were able to get traces of this block from some other teams um so that was absolutely great we were working with the nethermind team we

were also able to use um archive consensus nodes to create kind of initial States at the Block right before uh the the problematic block so that we were able to again kind of exercise that uh trilog rolling from the the last good block to the problematic block uh we were able to capture that pre-image and see what was happening with the self-destructed uh contract storage so we again generated that initial Beacon state observed that state change uh view the bug that we were able to find uh with the implementation of bonsai uh and being able to again put out fixes for that so it was very interesting um in in

that sense it was also interesting that these again these transactions were from freshly funded accounts that were playing with these kind of metamorphic contract flows um they were coming all from exchanges with no kyc um but at the end of the day you know there the you know kind diversity angle kind of works here uh the there were no additional kind of know correlated penalties triggered for a bunch of Basu nodes uh and again the kind of client diversity aspect worked and it showed that there can be issues Beyond just the evm implementation um so we were very happy to have support from some other teams um we were very happy to be able to kind of pass or to parse some of those self-destruct issues that

have been plaguing us for a little while and we're also very happy that when we ship uh the fork on Main that the self-destruct will no longer be something that we have to worry as much about so um that was a super quick overview again it it really had to do with the way that metamorphic cont contract deployment interacts with pre-images in our state implementation um I encourage you to go down the rabbit hole uh if you want we have shared the link in the chat um and maybe we'll do one second 30 seconds for questions because I know we have a super packed agenda today um and and Tim frankly the the second part of this discussion around performance numbers I don't think we need to get too deeply into that because there's been tons of you know public discussion about this at this

point and you know there's been a lot of uh uh frankly benefit coming out of that discussion so I don't feel the need to rehash uh the what went down regarding execution layer minority client performance um but but that's basically all I have for for that agenda item this morning

Tim Beiko: yeah thanks for sharing and uh amazian for sharing the link in the chat with all the details as well any questions comments thoughts

I I would

Marius van der Wijden: I would uh just quickly like to say sorry again for for sharing those numbers on on on Reddit those were old numbers and on outdated versions of the clients and I should

have checked with the client teams before sharing them and um yeah but I'm I'm I'm glad that um uh there was a discussion about it and we have um very nice numbers now um and everything looks kind of good um with regard to like the worst casm execution that that we that we can do at the moment

Matt Nelson: yeah thank you for that that's great and and we appreciate that

Tim Beiko: thank you any other comments questions okay well yeah thanks again

Matt for uh sharing uh the overview um yeah moving on to

Denon

Tim Beiko: um first we had sepolia Fork uh uh two days ago now um does anyone want to give a quick update about how that went um overall it seems to have gone super smoothly

Guillaume Ballet: yeah so we had the suppo f a couple days ago and um all the valid or most of the validators had updated that client so it was an uneventful Fork we saw finality as well as blobs showing up exactly when we wanted them to

Tim Beiko: anything anyone notice that was Weir

or unexpected okay well I guess that uh says it all yeah it looked good um and then hosi is uh for King next Wednesday I believe um so yeah that'll be our last one uh to see before mainnet and I believe early next week the blobs should start expiring on gorle as well so I know that was something we wanted to uh see on the test Nets obviously before uh upgrading to main net um so yeah it seems like uh things are progressing

smoothly uh that said uh Lucas you posted uh something about devet 12 saying that the blob spam broke it do you want to tell about that

Łukasz Rozmej: yes so I will maybe leave March in the field uh in the second just um we are we are hunting one bug in never mind which is uh which caused the potentially The Blob pool to grow uh beyond the limit we set uh and Martin was doing a test uh like two hours ago uh and spamming the devet with blob messages and the uh participation rate went down from over 80 to below 60 so over 20% and it

haven't recovered yet so we need to definitely investigate uh devet 12 and we want to also do similar spamming on test net uh probably will with gurle uh so we want to coordinate with devops and the community uh about this because uh maybe we can make some problems there too so I don't know uh and I think we need to like look into this before we can for example schedule main net date uh because uh this is troubling that it happened Marin do you want to add anything

Marcin Sobczak: uh yes I used to uh do such spamming experiment a few times uh

before but I was always sending uh six transactions so uh in NE mind in NE mind we are limiting it to 16k of transaction doesn't matter how many blobs they have uh so we had this 16,000 and uh like other client we know that Gab is limiting by uh s like on this space so uh if there was only six block transactions then they had like 13,000 something like that and today I changed a bit and I sent a mix of six blob transaction and one blob

transaction so in nether M we still have 16k but other clients uh have above uh 20,000 of transactions and uh seems like it may be a problem but I'm not sure it's just like like guting so for the first time the number of transactions sent in St experiment was uh So High

um Barnabas you have your hand up

Barnabas Busa: yeah just want to mention that before we start blobbing on girley we should wait a few more days uh before we can test the maximum uh turn

limit because it's possible that uh we will not recover from that and uh we only need we only need a few more days to reach the turn limit test

okay okay sure we can

Danny Ryan: ideally we figure out what happened to deut 12 before we break the next testet just yeah sure

yeah exactly

Tim Beiko: and then uh pis has a comment in the chat as well saying uh there's some block proposals that came late and didn't have blobs in them and it's unclear if it's a prism or a relay issue and this is on sepolia um so I guess based on all of this um it

does seem like we have a few different things to investigate um and then we'll obviously see whole ski for King uh later this week or early next week um does it make sense to wait until ACDC to potentially sell a main that date I'm assuming that uh a week from now we've uh assuming that a week from now we've figured out what's going wrong with devet 12 we've seen the churn uh limit activate on Gordy we've seen the blobs expire on gordi and um yeah have a have a better understanding Alex is asking to set a provisional date today I don't know if people would prefer to do

that yeah I mean we can set a tenative date today and confirm it next week but then if we realize in the next week or so that things are going to take longer um we're going to have to push it back so I don't know what people's preferences there

Łukasz Rozmej: my preference is not to say the date the right now because we don't know if we have some kind of uh issues in the clients to fix uh so before we are resilient to uh to this kind of Dos attacks I I don't think it's a good time to set a date

Tim Beiko: fair enough um okay and a plus one uh from Terren on

prism um any other thoughts

yeah

Marius van der Wijden: I would be fine with setting a date but we can also the the the thing is like we kind of need the execution layer FKS to set the date as well

Tim Beiko: so yeah so okay so what I would do is then if we're going to set it next week like again assuming that we've uh diagnosed and like understand the issues by next week um then yes e folks please show up on the call next week or you're just going to have to live with whatever

date gets set there um but I think yeah it's probably more reasonable to wait until we have a better view of things and then yeah aim this set a date for main net on next week call if those issues are fixed or we at least know when things are going to be fixed um yeah and I guess if for whatever reason some El teams can't make the call next week uh just leave a comment in the agenda if you have strong preferences around I guess what's the earliest you could have a release out for main net um and yeah we can discuss that on ACDC

Danny Ryan: yeah and if you don't have

representation also you know within 24 hours in the chat if you have any further discussion maybe I don't know

Tim Beiko: um okay and then there's a comment as well about getting some L2 feedback um I know there was a roll call yesterday I don't know if there was any feedback given there um otherwise it's something we can

and starware

Danny Ryan: is testing as well right

yes

Tim Beiko: starkware has some uh yeah

starkware has posted some blobs yeah um but yeah that's maybe something we can do as well before next week's call let's just try to tally up uh the different uh different L2 status updates um okay anything else on Denon then okay then moving on um so uh next up the main thing uh we wanted to

discuss today are the three potential big things that we could do in either the next fork or the one after and potentially try to get to a decision about about uh what we prioritize when um so the three uh to recap Were veral Trees uh eof and then EIP 4444 even though the last one doesn't quite need a fork um we could decide to just do a small fork and put extra engineering Cycles uh into uh 44s um so yeah I guess maybe to kick it off uh I believe the veral folks have a quick update on their work and we can do questions and kind of type deeper into it after that um I don't know Gom or

Josh which one of you is giving the update yep hello

Matt Nelson: can you hear me okay

yes cool

one second let me share my screen if I can o I'm getting an error here um can I drop a link and maybe Tim you could share for me sure

Tim Beiko: yeah

yeah yeah

no wor um one second I'll just drop it in chat and yeah

Tim Beiko: okay um let me open this up and try to share

this okay I'll I'll leave it like this though CU I think if I go full screen it'll break my oh actually wait um I need to change something on the stream is oh Mike says he thinks he can share yeah the problems it was visible on YouTube but it seems like when I start sharing my screen there the sound just stops coming in okay Peter thank you Peter saved us

thank you Peter okay uh so we were on slide four I believe perf we can go back up one previous yes cool thank you I saw a comment from Lucas as well uh a good clarification that it does not solve but

the state growth problem but does provide uh I guess it's a partial solution there we can get more into this um so yeah so not spending too much time on the Y veral but U just making sure we don't lose track here of of why why we're doing the work we're doing uh the decentralization benefits I think are pretty clear and have been gone through a bunch um perhaps the most direct but many other reasons why all of this work is valuable of course instant sync again probably pretty easy to understand for people uh any new node can theoretically spin up receive a block and the witness assuming the Witnesses are in the blocks uh and instantly start validating uh on the performance and

scalability front uh perhaps a bit more theoretical but still i' say a fairly clear benefit in reducing dis IO for example for non-b Builders uh and I think just overall the TLD drr here is that statelessness small enough execution witnesses that can be passed over the network uh this will all unlock a lot of cool new things uh so we can go to next slide Peter I don't know if we're having more okay cool thanks uh here we have high level overview of

what's changing with veral just sort of at a glance to give a sense for why there are so many moving pieces a lot going on here and we will spend time uh diving into each of these a bit next slide so yeah before we dive into each element here is a just a slightly different view of the main ingredients needed for veral uh and how we are doing so far on on each of them uh I guess as a note uh on this on the progress indicators you see below each item this isn't really intended or this may not

accurately reflect the progress of each individual client uh but is more so intended to give a very sort of approximate sense for how far along we are on each item don't want to give an impression that there isn't still a lot of work to be done of course um but it's helpful I think hope uh to understand how much progress has been made on on on each of these fronts um these numbers could certainly still go up or down a bit over the coming weeks uh but overall I think we can be fairly optimistic that they are all trending in the right direction um cool so now we can quickly go into each of these one by one

next slide Peter uh so yeah um going through these we tried to organize each into three sections hopefully that's clear uh section uh three sections what's already been completed what's left to do and then at the bottom trying to anticipate where we might get surprised to the Downs uh the tree structure is one of the items that is the most far along uh next up here uh as a to-do is the shadow Fork uh which will give us more data and and even more confidence in our approach uh and this should be complete fingers crossed really uh any day now uh next

Slide the cryptography also rather far along thanks to Kev Gotti donrad many others for their long-standing work uh we have two main implementations go and rust Nim also catching up with their own work um on the uh I suppose on the potential surprises front we are interested to get more data on performance and potential impacts of 4844 uh and this may be a good topic for Q&A at the end but um yeah next slide gas schedule updates uh making progress here recently still a good bit

of work and testing to do understand things and one of the next big Milestones here will be getting more daps other large contracts deployed on testnet so we can continue to learn um anything else here I think we can move on yep uh thank you transition uh clearly I think people understand one of the most complex and trickiest parts of all of this uh but has also been our highest Focus area namely gomio and and others for some time uh really solid progress we believe we have

a viable migration plan which is a lot uh and we'll know more once we complete our shadow Fork um again thanks to Perry devops for all the work there uh next up on the to-do is just sort of finalizing the plan uh yeah sorry on on the transition and um locking that in uh reviewing that and a big piece of that will be uh the finalizing the pre-image distribution strategy uh next slide witness generation verification uh live on the cenin test net is used in the current

version um of veral sync main thing here perhaps is finalizing the actual distribution strategy where are people going to get the proofs from uh included in blocks or distributed in some other way out of blocks um yeah so I think that's it for witness generation can go on to the next slide uh and the fact sheet so Gom and Osio uh helped to put this together and actually G May to you here if you're able

Guillaume Ballet: right so uh yeah the the thing is we wanted to present some some numbers but we're a lot of them depend on the

success of Shadow Fork which is stomping us a bit has been stomping us a bit for for a couple months uh but so what we have to offer are mostly educated uh estimates uh so for example the the average weight we estimate that uh the average witness size should be around 150 kilobytes uh the tree size so uh this is actually an upper limit right I just want to make that clear um it would be 80% of the current uh tree size as of yesterday like when I did this dump and uh what needs to be yeah so what what's not specified here is that we we haven't optimized the compression

in the database yet so there's there's a lot more to to scratch uh like like there's a there's this is just the surface and we we need to scratch deeper um execution time so we we ran that so this is actual data um we ran that on uh somewhat older version of the database uh so there could always be a surprise there but uh yeah from where we can tell in terms of uh uh of performance of executing a block it's like 10% slower um of course once we have the the shadow Fork running we can get more current numbers uh we did not really try to measure uh the time it takes to to produce a

proof uh because well there there are several reasons but one of them is we could still decide to go without the proof in the first uh in the first iteration of the fork or we could decide to distribute them differently uh but once again like once we have the shadow Fork we'll we'll be able to get numbers both the time and the size actually and uh yeah I think the most um worrisome part for for people is how long it would take to to do the conversion so we tested on a fairly slow machine right uh how old is that machine par uh the rock 5B Rock no sorry not the rock 5B the other one the the Nook is about three generations old three generations old right and uh we also tested indeed on

the Rock 5B which is which is quite slow so we are able to handle 10,000 Lees move per block and it takes about one extra second uh so we and more importantly it can be done before uh before the block uh before the slot starts so that's uh that's quite convenient um and we estimate right now based on the estimated number of leaves and the uh in the future that we could be we we would be able to do the just the copying part within two weeks then there's a buffer there's a required buffer of one week to distribute the pre-images uh but yes that's that's we should be able to to handle that under a month basically and yeah that's pretty much

it

cool uh so

we can go to the next slide almost finished here um yeah and this is pretty much it I just wanted to bookend this by quickly recapping again benefits of veral why we believe it's a powerful upgrade uh comes of course with a good deal of complexity but thanks to everyone's efforts here making very solid progress and uh confident it'll be ready for prime time soon um so yeah thank you all any questions I think we can yeah the next slide is just Q&A so um we can take those now assuming we are okay on time

Tim Beiko: yeah let's let's do question now if there if there

are

the slides that we want to go back to um sorry if it was too quick

Tim Beiko: and I know there's been a ton of discussions in the chat uh some back and forth there are there more questions or concerns people want to discuss

Gajinder Singh: uh hey Josh so the execution time that I think someone also mentioned this in chat uh that you have mentioned over there is it uh the block production time or is it an execution time by a full node maintaining work trees or is

it a stateless execution time

more the latter stateless execution time

okay uh Lu some questions as well

Łukasz Rozmej: uh so I just want to comment on the discussion there that uh not to extrapolate for example holeski Performance on Main net performance if we do holeski Shadow fork and I'm talking this uh directly from our uh never mind experience because we are currently trying to move to a pu based storage and one of uh our uh tries on that worked

very well on sepolia for example which is a lot smaller but when scale to male net uh it actually didn't scale well so uh until we have like a shadow Fork on Main net and some uh performance numbers from there like just keep that performance numbers with a grain of salt that uh it's not uh not something to make any decisions based on it

Guillaume Ballet: so to be clear the 10% performance is main net data

okay

Łukasz Rozmej: okay so sounds sounds interesting uh but uh after you do holeski Shadow Fork I would be very eager to see like main Shadow

Fork me too

Łukasz Rozmej: yeah

cool

Ameziane Hamlat: yeah but I guess it's main data stateless data right it's it's only like the cryptographic overhead uh no no

Guillaume Ballet: no it's not it's a actual writing to the database in fact that's where a lot of the performance goes

all

Ameziane Hamlat: right okay

Tim Beiko: okay any other questions comments

Péter Szilágyi: um can I ask about the status of this so if we go back um a few slides you had this sort of status situation um based on this are we in a position where we're ready to do

this in the next Fork like I'm just sort of like if veral think is only five out of 10 like done is there a risk that if we allocate this to the next Fork that we're going to get delayed on that fork because we have like research needs on the verical SN and would it be better to push it one more Fork so that like vericle can be like basically done when people are ready to start implementing it

um I'm

Guillaume Ballet: not sure I understood the question actually do you which for are you talking about pushing it back to Osaka or uh what would that

Tim Beiko: I guess he's asking about Prague versus Osaka like if we decided this was the

main priority today is it even in a state where um it's valuable to have all the clients shift to prioritize that or is it better to potentially have a few more Cycles around uh development where um we we sort of get something like the Sy from five to an eight and then at that point we we prioritize it you know for Osaka or some some other Fork

Guillaume Ballet: um right the the problem with this is that um if you don't prior as long as you don't prioritize it people will not work on it this is exactly what happened with thenon um you know it it went uh it went

ahead no one looked at veral I mean no one of course some people did uh that's why we're here but um it didn't get the attention because it was that thing up up in the air that people uh think they will work on when it's scheduled so um my understanding is that it should be scheduled it doesn't really make a difference whether or not you schedule it for Prague or Osaka what matters is that uh people start looking at it as if it was the next fork and uh because if you don't you're always going to look at

two U right yeah yeah you're going to

Tim Beiko: focus on on on the other thing that's important so okay so you're saying like it's not necessarily the most urgent

thing to deploy on the network but it is urgent to get teams attention on this and like significant engineering resources in order to actually make progress on all those things and

Guillaume Ballet: um sorry let me qualify that uh it is quite urgent to deploy it on the network I mean of course we should not rush but we have the current state that is growing growing the more we wait the more the conversion is going to take longer which means we have this area of time that is a bit more risky than the rest of normal operation uh so it is quite urgent to to deploy it on on the test sorry on the test well also on the test net but on Main net especially

got it thanks um I believe

enrio you have your head yeah

Enrico Del Fante: just he just covered right now because my question was if we postpone this too much is the state growing too much and then affect the transition that makes from maybe two weeks to to maybe one month because the state now is too big and transition will be very painful especially for little boxes

Guillaume Ballet: so so far what we see is that the state grows by roughly 25% each year if we extrapolate hopefully it stays this way um we have a little bit of time also machines or nodes on the network are

going to get faster and faster right the The Rock 5B is probably not going to be uh there forever there will be more powerful versions if that's what we want to keep uh running of supporting I mean um so yeah it's not like it's super urgent but what you have to realize as well is that it's not just um it's not just the transition itself it's every full sync you're you're going to do in the future and right now or more like June about June this year you will already add about one day to a full sync just in terms of pure computation if you wait much longer you're making your full sync more and

more impractical so now it doesn't sound like very interesting to most people but full sync is excellent for testing new code or new yeah new code so this is quite useful for for core devs

um Luc and than so

Łukasz Rozmej: uh few things I want to cover so I disagree that we cannot work in on Parallel because we work on for it for for in parallel very well and we had the test Nets of 4844 way way before we uh delivered Shanghai uh so and we already have some test Nets on vericle trees so kind of working parallel kind of works uh secondly I

am against for going this in prog if I already we're talking about schedule um because of two things I think like uh while the maybe G implementation might be maturing enough uh I think like each each client has its own implementation and it's a very hard thing to do in my opinion like for for me from myself like the state management and state three is the hardest part in the code base uh um and if we want to have multiple client implementations polished to the level of uh what they are comfortable with uh I think it will take a long

time um so uh just because of that I'm I'm against uh and again talking from experience for over a year we are working on our pu based three uh we haven't delivered it yet hopefully we can deliver something in the first half of this year but it's taking a long time and it's delaying and delaying and uh like I said for me it's the hardest part in the code base and we don't want only one client to be have it implemented in implemented well we want to all clients to have it implemented well and on on a good enough uh level so I don't see that's happening early and I'm talking

this as a client that has a vericle Tre implementation already that's joined the test net and that has a verical sync prototype in it so I would say that never mind it's pretty um decent on the on the level of implementation but I I am really really worried about for example uh main net performance numbers so never mind I I think they would be very very bad so a lot of work uh need to go there uh yeah so I I I don't see this coming in months it's uh it's still way over a year to deliver in my opinion

uh thank CR

Dankrad Feist: um yeah I just I had a big quick

question about the transition which is um uh what is what is the limiting factor is it IO bound is it CPU bound uh like um that might be interesting to know for knowing like what to expect when it's first like how which which Hardware do we need to watch when we say like um is it going to get faster because we get better hardware and like also like yeah how much worse it gets when the state gets bigger do you know that

g uh sure

Guillaume Ballet: I'm just trying to unroll everything yeah so the hardware Hardware wise um yeah um from it's definitely

both uh it's uh I bound because the The Rock 5B is extremely is extremely slow in when it comes to iio it's also CPU if we get better CPU uh we can indeed pack more uh more um more leaves but um yeah my I'm trying to remember to to be honest but I think the the biggest problem was uh was indeed IO do you remember

Ino if you're here

yeah I would say it's um mostly CPU bound to be honest and also depends yeah um right because go ahead like it kind of depends which is

the the lowest hardware setup that we are trying to push for uh because there's a huge difference between Rock 5B and any other like normal machine

right

Guillaume Ballet: yeah exact now I remember because Rock 5B I think had extremely slow IO which is why the performance was bad but but your average machine is actually CPU bound that's uh that's

Dankrad Feist: and how many how many seconds is those 10,000 leaves on your average machine

uh 1 second is

Dankrad Feist: and that's parallelized or not

Guillaume Ballet: uh um I also need to I mean I would like to

answer lukash if

Tim Beiko: uh yeah yeah let's do that and then maybe let's move on to the next ones yeah

Guillaume Ballet: right so I wanted to to clarify um two things so I agree that uh verco is is a bit far off but that's that's exactly the point I'm making it needs to be looked at so far uh you know it's just it's just a fairly small team trying to to make a gigantic thing happen um yes uh I'm not claiming it will be there uh in I mean I never claimed it's been it's going to be there within a month um I still think a year is realistic maybe maybe not but uh but it's definitely not going to happen until every client

starts looking at it this being said there's been a lot of optimizations that have already been worked on that you can immediately Import in other clients so a lot of the the work uh when it comes to optimization has been done the second thing um I wanted to says it's true that um 4844 and uh withdrawals were worked um on in parallel but that's the point the withdrawals were extremely easy from an Neel point of view what uh what I'm saying here is if you schedule some very very light uh um yeah items for uh for Prague and then we come in to do in eka that's

no problem those things can be uh paralized if you start doing something way more complicated um you're not going to be able to do uh to do anything in parallel so yeah that's uh just one point I wanted to to clarify

Tim Beiko: thanks and yeah I guess yeah before we start uh going into like more planning discussion I think it's worth going over eof and 44s so we have the full picture um yeah Peter I don't know if you can stop sharing your screen um so we can move on to the eof folks thank you um yeah eof I'm not sure who's the main person uh giving an update

here

Danno Ferrin: is Alex on I don't see Alex or many of the other UF crew okay um I'll go ahead and give an update um we've been U moving into ship it mode um we're trying to close the door on as many of the spec possibilities as are out there there is one um out there lingering with regard to um whether we're going to use variable length instructions um probably not just because of scheduling issues irregardless of the merits um it seems like we could get some value out of it um but as far as the main issues with with eof it's very derivative of big eof that we tried to ship about this time last year and it was about this time

last year that we pulled it out out of Shanghai um it was going to be another big feature in Shanghai um because of um solidity couldn't get some of its um Constructor stuff working so over the past year we added some more stuff to um add a couple big highle features um we remove uh introspection um code introspection from eof um so you and uh which was a major ask from from a high level um people in in ethereum and also we remove gas introspection and those two things going to do things like um gas schedule changing I2 is much easier um so let me paste this into the chat so we are starting a just just started this yesterday we started an

implementation Matrix to get final status on some of these specific um eips and nailing down some of the reference tests we have reference tests for a lot of these again these are very derivative of what we had this time last year so we got kind of good head start on on some of this um some of this featuring um so of course you know my pitch like I mentioned back in on October November um I would like eof to ship as part of Prague um targeting Q3 to ship in a test net so that we are on Main net by the time we get to Devcon southeast Asia and I think it's achievable where we're at with the spec if we ship the spec as we have it today we don't do any major changes um and you know my pitch if if you talk to me I'll probably go way too

far in the details of it but I feel that these fundamental changes for um fixing a lot of technical debt in evm is kind of existential for the evm in the next couple years um all the complaints we see about things like uh we can't increase the the code size um the problems the fundamental problems that are fixed in the way eof works um and there's a lot of other things that are going in you know the you know why can't we have uh evm Max we really need immediate arguments why can we have immediate arguments and it's just it's like the hole in the bucket onong uh we just need to fix a lot of things at once and this container format fixes it with container without fun Fally changing the um the way the evm works we still have frames we still have halts we still have

accounts we still have storage and um probably the last thing I'll say is uh the engineers that have been working on evm stuff tend to be different Engineers that work on the data stuff so I don't think this would stop any work on verl from going forward um I don't think it would impact and steal any resources from that effort so

Tim Beiko: thank you yeah great overview any questions comments uh Andrew

Andrew Ashikhmin: yeah so my preference is to schedule eof for Prague and vle for Osa um

yeah

Tim Beiko: thanks um yeah before we get into the scheduling just any technical questions on what D shared or on eof specifically oh yeah y or Perry or whoever that is

yeah so um I have a

Guillaume Ballet: yeah I'm not sure if it's a question or more like a a uh feasibility uh well I guess it's a question yeah um did you I mean we we talked about this uh in on telegram yesterday U there's some kind of understanding how eof is going to impact uh

vertical um what I would like to see before I I we make this kind of decision of putting EF before veral is to ensure that it runs on the veral test net um as long as we like the reason for this is because there's this whole chunking thing happening in in veral um eof does the chunking differently meaning we have two code bases to that that that have never been tried before that have to be tested uh in parallel I am not comfortable uh going with the first as long as I don't see the feasibility it's

not just the ability to do it I I agree that UF can be done faster than veral that's for sure the question is can it be done in parallel with veral that's a different story um but if um if it does go first I need to make sure that there's no uh that it we we don't ship something and paint ourselves in a corner realizing oh actually we broke something so I would say even to before we even try to solve this question of who goes first I mean clearly probably verle is not going in prag right um do we uh can we get some actual data as to what's uh what's uh how well they work

together basically

Tim Beiko: and then and then your main concern just to make sure I understand is about the way eof does code chunking and um how veral then chunks that differently to put data as part of the the tree

Guillaume Ballet: right it's just that um yeah it's basically um they they do it differently and I want to make sure that both path both both code path that are going to be entirely new work fine if not or if we can't get enough confidence I think e should go afterwards if it if we can get that confidence then no problem but I don't

want to make a claim and I don't want us to commit to ship E before veral as long as we haven't answered that question

Danno Ferrin: so the code chunking with with e is going to be basically the same um the code sections going work exactly the same like Legacy code sections we're just going need to add the extra bit of logic to make sure that we bring the right parts of the header in and and making sure that we can execute eof code in a chunked environment has been a discussion in several of the past different eof uh implementers calls um it's been something that we've been aware of it's been something that we're building some things design around um one example that you might might be worth pointing out is the current chunking plan has an overhang bite and then 31 bytes and that's because of

Legacy jump test analysis um for for eof code we don't need that hangover bite um because every code is valid you don't need to do jump test analysis if it hits main net then the code's valid because we only deploy valid code and all the jumps are going to hit legitimate places so in that sense we could save a little bit of space with eof but it's going to work it'll it'll work within the current chunking system we just need to add some extra analysis to make sure all the appropriate parts of the header are brought in and that shouldn't be terribly hard

I

Guillaume Ballet: I don't want shoots that's the thing I want to see it working uh I mean I'm I'm sorry I don't want to sound extremely uh rude uh all I'm saying is shoots are fine what I'm afraid of is that we paint ourselves in

a corner and we only realize too late that's all that's all I'm asking

Danno Ferrin: and before we can put it in a test net uh verticle we need to have it working in clients exactly so we need to implemented clients which is where where we're at with the implementation Readiness Matrix

Guillaume Ballet: right but do you have any client that has implemented it that's my question you say you say it's going to be fast right did I understand that correctly

Danno Ferrin: what was the claim

Guillaume Ballet: my understanding of your claim is that you say it's uh it can be done quite easily by uh different people

Danno Ferrin: yes it'll be done by different people right different in Basu I have no

I do not work on any of the the Patricia tree stuff I only work on the evm stuff and my understanding is that's the same on a couple of the other clients

Guillaume Ballet: but how quickly can you slap together and once again I'm not trying to be I'm just trying to see where e fits is does it fit before or after veral um Can it can you slap together something to run on the veral test net in like a matter of a couple months

Danno Ferrin: yes okay cool we're finishing the spec that's what the implementation Readiness Matrix is for we're writing reference tests for this um gu would need it probably is the most advanced verticle so we would need to have gu um dig up and update theirs um whoever was contributing that um or we could have evm 1 do it through uh the evmc but but

um I mean this does seem like you're moving the goal poost to be honest that's how it feels

Guillaume Ballet: um once again just making sure we're not painting ourselves into a corner because I fear that's what's

happening

Tim Beiko: okay and yeah let's I think we have a good uh Next Step here but yeah just to make sure we don't cycle around this over and over um yeah let's move on um Andrew

Andrew Ashikhmin: um yes so can we like uh commit to e in prag but with the K that uh we will have to run a veral test net that includes UF and also spend some

brain Cycles on the compatibility and if it turns out that there is an incompatibility we just decide then we don't ship e in Prague

Danno Ferrin: just like Shanghai yeah

Tim Beiko: yeah let's hold that uh again I want to make sure we we get to 44s as well before we do the scheduling stuff but

uh dran um hi

Dragan Rakita: uh I just want to say that storing the bite code and using the bite code are totally different things and how we store it be that in the verle be that in the Merle is totally different than how you're going to use it inside

DM so I don't see that as the like cutting point or dependency between those two I just wanted to mention that UF in general seems better fit for the veral truing than it's for the Legacy

Guillaume Ballet: just a quick answer in a stateless context it is the same thing

Dragan Rakita: yeah but for the stateless context we will have at least two or three heart box to come to that sure even for that it's better to have UF than the Legacy because the bite code

is a little bit smaller

um uh gu Yeah

Łukasz Rozmej: question mark about e and verod because if we store um coding chunks in veral would accessing it uh would be potentially would we have to revise the cost of accessing this code and from the tree like just to uh on the

uh gas costs

Danno Ferrin: that's one of the eips that was posted a little bit ago so yes that's in verle's plan

Tim Beiko: but we're going to need to Res

revise access costs regardless right this is not an eof specific thing

no

Paweł Bylica: I don't think that matters because you just count like 32 bites chunks and yeah so like youf execution probably will need less of these trunks but that's the only effect

Tim Beiko: okay um let's move on from eof I want to make sure we also have time to cover uh 44s um and I guess on that front uh I

know we had someone from portal to give an update on their history Network um so maybe we can start there and then if there's any other updates on 44s we can do those

Kolby Moroz Liebl: uh yeah for sure uh I'll share my screen quick okay uh I wrote an FAQ for this but I'm probably just going to go over like the highlights and what I think I should share to just like kind of make clear what portal is and what our goals are so a quick tldr the ethereum portal networks is a collection of separate peer-to-peer DHT networks built on dis V5 the current goal is making execution

layer data accessible utilizing minimal resources currently we're working on three different portal subnet NW Works history Beacon and state each with their own timelines and when they're expected to be online portal has a verification first approach for M ethereum mainnet data and this plays a big part into our guarantees over generic Solutions um we currently are building three clients but we have been in talks with a few other of the El teams uh some have expressed interests and we've also heard of like other third party teams who aren't really in uh layer one who who have expressed interest uh the portal

history Network which will be the main like 44s Network which will provide uh uh headers block bodies and receipts uh we kind of have three major milestones for this when it says quarters we mean we're planning to get it out by the end of the quarter uh the first Milestone would be validating all pre-merge block history so so this would be like the first 15.5 million blocks uh and we're planning to hopefully get that done in Q2 uh the thing holding us back from launching that is mainly just um like asynchronous uh bugs in our code base uh and yeah uh the second most interesting one I'd say

is valid being able to provide and validate all up to the latest everything but the latest Epoch of blocks uh we're hoping to get that in Q3 and providing that validation uh people will also have to run a portal Beacon client what is what is a portal Beacon client uh basically it's just a portal uh Network which provides all the data to validate post merge data we'll be using it in both the state Network and the history network uh it's more of just like uh getting the stuff you need to validate stuff Network and then in q1 of

20 uh 2025 we plan to be able to provide all the historical data um is Portal the thing I turn on when I need history or should it be run continuously we expect users to do both but we really hope people do leave it on in the background portal is meant to be uh very resource efficient so we're hoping that it shouldn't really be an issue um hopefully in terms of resources it's on the lines or a little bit more than running a a dis V5 client as that's what we're built on so that's a little I guess reference point of course the

clients may be storing or um storing data or collecting data to store on their node but that can be limited uh to how much it does like a Max's basically connection count we use an xor metric so lookups for data on the network are in login time uh do individual portal network node store all the block history uh in normal cases no and we really recommend against this because if you store all the block history uh people won't be really able to find it easily on the DHT because we use a metric on how close data is to a node and we'll ask the

closest node first um every person who runs portal will be able to configure their own uh amount of disc space they want to allocate so it's completely optin um is the portal Network robust what if a node goes offline so the main way the portal net like a portal Network gets robustness is through replication values on the network uh how will this look like let's say you have 400 gigabytes of you you only need 400 gigabytes to store all the history on the network but you have like a terabyte of Total Space on the network

you would have up roughly around 2 2.5 replications of the data uh the more replications you have the uh the less likely of a chance that all the nodes that have the data go offline uh I believe I seen a year ago a graph ipfs had but also other DHT networks had on metrics on like how long noes they up uh which is kind of interesting I should post that oh what

Tim Beiko: yeah sorry there's a question in the chat I think uh that might be useful in the SC is uh if you can talk a bit maybe about the incentives of running portal whether or not there are any and if uh

if if there aren't um like what is the plan um to get this you know up and running at scale so that uh like the execution layer can eventually depend on it

Kolby Moroz Liebl: uh yeah for sure so I was actually just about to get there okay so there's this big question uh do you assume nodes will store the data altruistically uh the assumption is there's inherent value in this data itself uh there's also intrinsic value in having access to this block history and the cost of running a portal node being extremely low as in you should be able to run our client and you wouldn't even notice it's there

uh so we are planning to have no monetary incentives and one of the major reasons for this is because when you bring monetary incentives like into the frame it's kind of like AAS to to the bottom who can provide this data the cheapest and normally normally those kind of incentives don't really align with the health of the network but who can like basically mmax the reward for what you need to provide um so realistically over time as the network gets bigger the amount of like default storage a node will use will lower more and more

and that will just decrease the cost of running portal uh like as the network grows assuming people actually want want data um so yeah uh so who do we expect to run these clients well probably we would expect like maybe an El client who wants to provide a good Json RPC experience uh let's say you have a post for for for is node and someone queries a transaction receipt from block 5 million if they're running a portal client they would be able to just uh take that call they check their database it would be a

missing hit but they could check portals to see if that receipt ever existed and then they could return an actual like the actual receipt instead of saying I have no idea if this block ever existed for people who are going to run portal altruistically uh we expect uh like we expect to like bundle like a portal client with like uh the I guess the bit torrent clients what are going to be hosting uh Arrow one files uh Arrow one files for anybody who doesn't know is the uh it's just the archival format for pre-merge data um and yeah so we expect portal notes to be ran alongside those

as they are providing pretty much much the same data so the cost overhead to run a portal node alongside that is also extremely low uh I hope I answered uh but yeah I'm going to avoid like any like deep things but on the history Network we provide uh headers block buys and receipts we also provide a header like header EPO accumulators which can be used on premerge to get uh block number to block hash indexes uh this is like kind of a fuzzy thing we're going

to have it for a certain amount of time uh but we can talk about that in detail another time so we have that Ro map uh the beacon CL is in that and then let's see I think the last thing I just want to say is does E4 fours include e 4844 is blobs uh blobs nope uh blobs are supposed to be transient E4 fours is a proposal for the expiry of ethereum mainnet headers blockwise and receipts uh not blob expiry uh I just wanted to mention that as I seen some confusion on like what will that include uh and then

uh I guess I would just want L Cent to talk about era one cu is kind of like the spearhead of that and if anyone wants access to Air1 to experiment with I guess like the file archival format for pre merge uh we have some posted in the history expiry Channel but if there's any questions ask me I'm happy to answer them offline and I'll provide a link to the FAQ and expand it whenever I get more questions but that is everything I want to go over just like a highlevel overview of what portal is and trying to focus on any of the main confusing points or pain points uh thank thank you

Tim Beiko: um yeah there were a couple

question in the chat but I think we covered the biggest ones it's probably worth yeah Matt giving an update on the error files and then uh doing more questions

that's up okay

Lightclient: uh era the era one format just to be clear is slightly different to the era format which you might have heard of in relation to this format that I mean both formats have sort of been developed by the nimus team but the era format is focused specifically on providing consensus layer data which post merge has the execution layer data as well and so the ar1 format is really just focused

on all the data that we need to provide for historical purposes that occurred before the merge and so the format of it is execution layer data only so blocks bodies receipts the total difficulty of the chain Etc as for the format it's more or less been spec out for the last year and in the last year there hasn't been a lot of discussion or changes on things it seems relatively stable I think the biggest thing that came up over the last few weeks is we're realiz ing that the compression format that we're using Snappy is relatively platform specific or at least implementation specific in

terms of its bite forbite guarantees and so we can't take a a simple hash of the era file format to get a check sum it ends up changing whether you export with nether mind or gu and that threw a bit of a wrench into the situation but I don't think that it's necessarily any kind of deal breaker I think that generally we should go forward with the format as is and we should rely on this accumulator data structure which Colby talked about this is something that the portal network has come up with and it's basically just an ssz object that allows us to uh quickly share a rout that represents the accumulation of all of

the pre-merge blocks so the a format has this thing it does verify across all of the platforms and that will be the main way of validating that the data you download is correctly I think if client teams want to provide a check sum for convenience we can do that but um it's not going to be the recommended way to verify everything in terms of like next steps for era one I think we're we've got some implementations in NE mind other people are looking at implementing to clients we really just need to go ahead and you know put the stamp on the spec and then go ahead and ship it and then start trying to get providers to provide this data data because the spec itself exporting the data is great

verifying the data is great importing the data is great but until the data is available we can't actually move forward with removing the data on the PTP Network so I'm thinking in the next one to two months we'll see era PR start to get merged and then we'll get the data out on bit torrent we'll try and find some people to serve the data and we'll have to give it around a year or so to make sure that the availability is to the degree that we want it and then you know maybe sometime next year we can discuss actually turning off the sharing of pre merged data over Dev P2P and it doesn't necessarily need to go into a

hard Fork but I think we're probably going to want to roll it out in unison so it would be a upgrade of the eth wire protocol most likely that is all the updates I have far one happy to answer any questions on that or if you have questions on Portal

Łukasz Rozmej: so I have one question about um okay it's fairly straightforward what would happen if a client uh user would want to have the whole fixed history he can download er1 files from either portal or or uh like a bat torrent at once and get it but I'm a bit interesting the more interactive like

light light client uh use case right especially with veral Now with uh with portal Network and forier 4 you can store potentially very small amount of History uh but how would an e client existing El client interrupt with a portal uh network uh would it be through a different process on Portal Network client or do we expect it to like bundle in process uh like this is like an open question what what do you think about it uh how how what would be the best approach

Kolby Moroz Liebl: uh I think clients will do both uh depending on like what they want and the use cases they want to support uh

for portal we're probably not going to be bundling Arrow one files into like our architecture ourself we're going to be supporting a lookout model where you use a block hash and an index of the type of data you want to f from the network uh one of the reasons for this is to have nodes what have really low requirements um I believe the biggest a one file is like 600

megabytes

Kolby Moroz Liebl: uh so yeah I guess the question would be the answer would be like both we'll probably end up

seeing

Łukasz Rozmej: okay so uh two more questions about it um one I haven't seen in the document a look up from transaction hash

to for example block body or something so without with having just only transaction hash we cannot find anything in Portal network

Kolby Moroz Liebl: uh I think in regards to that uh so you said you would need a transaction hash to block hash lookup

Łukasz Rozmej: uh yeah something like that

Kolby Moroz Liebl: uh I believe how we're going to be supporting that use case is we're going to most likely make a new portalet work just for storing those indexes so then you could do a quick look up there and and then you could do a quick look up on the history Network would is how I believe we would Implement that

functionality uh but I could look into that specific use case more and get back to you offline

Łukasz Rozmej: and last question if I for example in never mind want to prototype uh integration of portal Network for this use case of interactive one just looking up things on the flly uh how problematic is it do I need to implement like the full portal Network protocol or only some parts of it to doing the lookup and how uh would it uh affect the network if I would be only doing the easier part for the lookup right because I'm El and I'm not really interested in like maybe doing everything yeah Le leaking exactly

Kolby Moroz Liebl: uh okay I kind uh I think I

heard all your uh all your questions so uh I think it would be so basically implementing portal is just cloning is cloning uh the cloning the basic routing table on parts from dis V5 and then just calling that portal so implementing portal in that way is pretty simple for I guess in like prototyping with a client uh the recommended thing I would think is bundling like uh an already built portal client with your client and interfacing it using IPC I believe u we have Jason uh RPC endpoints to provide the data we

have some lower level like portal ones and we're also planning to provide like uh actual ethereum Json rpcm points but I'm assuming that uh like layer one clients would want to like access the lower level calls but yeah probably something like that IPC for prototyping and then if you find it's worth the investment then looking to build your own client and yeah

well in in Portal we have a different types of overlay networks and for example to access the the history network data you don't need to run

all of the overlay Networks that that we are we are going to implement for example for the history network uh you will need only the Bon portal Network which is used to track the the head of the chain and uh and uh then if if we decide to implement this transaction uh history uh overlay network uh you you will need that to to uh to be able to look up for a history data by using only um a transaction hash so it will be

transaction index uh overlay Network and uh for example to access the state network data then uh you will need to run um uh the beon network and the his hisory Network alongside the state Network so you have some kind of choice or make the which uh networks you want to run based on what uh data exactly you want to access

Tim Beiko: um okay we only have about five minutes left um I think we probably have

enough context on Port to at least have a rough idea of like where it it fits in um I guess probably the most valuable thing at this point would be to hear from the different El teams um yeah how they're feeling about basically eof veral and and 44s um and and I I think for for Pride specifically there's a bunch of small eips that we're all considering so um you know we already have three that are slotted in uh so it's it's probably not worth going into like all the small things we can do in addition in prag but just um yeah with regards to eof with

regards to veral and with regards to 44s like are those things we want to prioritize for Prague do we want to pre-commit something like veral in the Osaka Fork um yeah how the E teams feel about that do you feel like ready to make a decision you have a strong view or do you want to spend more time thinking about this and going over stuff uh outside the call

Lightclient: uh I'm just curious if other client teams feel similar to me here on 44s it feels like 44s is pretty orthogonal to a lot of the changes we want to make on

mainnet and it's something that's somewhat pressing for teams I mean the history is growing hundreds of gigabytes of a year and it's this isn't a really big lift to just like continue working in that direction to actually start lowering the history requirements we're you know one year away from doing that probably so I think it's extremely high priority and really low touch for teams to be putting some resource to that today at getting down that path

yeah

Tim Beiko: it seems like NE and Basu agree

um okay so and I mean yeah the work is already happening so uh doesn't seem like there's a reason to stop it and it's just worth being mindful that like the time and effort we spent on that obviously reduces bandwidth for other stuff but if it's is a minimal lift and teams already working on it we can we can keep that going

Lightclient: I really think we're like looking at around one month of effort now is and we don't have to have every client team I think if we have two maybe three client teams do this that's really what we need to start bootstrapping this era one distribution Network and we can you know I can go off and try and work with some people on what to do for the future for

era but I think getting era one off like we're very close to it and there's not a lot of work that needs to be done at this point so if client teams are good with you know I think nethermind is working on I'm going to talk to Basu later if we're good with doing that then let's just get that out and then we can come back in six or eight months and figure out how things are going

yeah thanks um Andrew um yeah um as to uh for fours

Andrew Ashikhmin: so in in Aragon we actually have to do a major release first um and we call it Aragon three because in Aron 2 we need to reexecute all the blocks from

Genesis uh and for that we of course need all the blocks right yeah so Aron 3 is a few months away so for us like after that 44s will be easy but beforehand we we have to do a a mammoth engineering effort um yeah and in terms of e and and V vle I've already said that my preference is to commit to e in prog with the Kat that if it's not compatible with vle we don't ship it and to commit to a vehicle in

O got it

Tim Beiko: thank you and there was a comment by nethermind as well around uh

committing to veral in Osaka and like a weaker view on eof in prag um and then obviously uh from the Basu side uh there was a desire to do uh eof in in Prague um I guess and we we sort of have a a minute to end on here um it feels like eof sort of has to be considered a bit more in parallel with the other potential eips for Prague um whereas the decision for veral in Osaka is a bit more independent so do people want I guess is anyone object to committing to

have veral be the main thing for Osaka um and figuring out on the next call a bit more um the the exact scope of Prague and what we want to include there um knowing that like we already committed the veral for Osaka last chance if there's objections otherwise I'll open a PR for the Osaka spec uh later today

oh uh Anar yeah I mean just then to make a point um out of it I I I think

Ansgar Dietrichs: it makes a lot of sense but I do think just given that it's a Rel relatively rare that we

are planning for features that are basically year plus um out still and just kind of from historical experience that sometimes things slips quite a bit we should at least be open to say revisit this in 6 to 12 months if by that time for some unfortunate reason it turns out that just verle takes massively longer than plan I mean I don't very much not expect that um but I'm just saying it should not be a hard commitment

Tim Beiko: yeah I think that's reasonable and I think basically the the thing we also can commit to is like working on it in parallel to shipping Prague like we did for the past two forks uh which means that you know in um you know in the in the the time until

like the next 12 months will build up our confidence towards like is this thing actually uh actually ready to ship or are there some issues we didn't we didn't see but um yeah I think you know based on a lot of like the veral folks's comments and what teams want to prioritize flagging this explicitly as the main priority for the fork after uh Prague and having teams start to or I guess mostly continue to invest engineering resources and and develop this probably is what makes the most sense um yeah any other comments concerns okay and we're already one

minute over time so I uh I'll just give a quick shout to the other three uh agenda items but I don't think we we we have the time to to go over them um first one was um specifying the client versions on the engine API the idea here is that it would maybe help um it would maybe help identify uh what what El's are are working on there's a lot of conversations on the thread already but if people want to uh go there hopefully we can get it merged in the next couple weeks um then uh Peter

uh you had something around or actually yeah there someone asked to review 7523 but I'm pretty sure we agreed to this a while back so yeah uh so I guess yeah poell maybe um if you want to chat in the R&D Discord exactly what the ask was but I'm pretty sure we had agreed to the empty accounts um because we already cleared everything uh on L1 and then last one uh Carl uh asked uh about just reconfirming um the uh

decision we'd made around reserving the pre-compile range for L2 promiles um I believe there were no objections to that last time but if there are any uh maybe just raise them on the eth magician thread for this in the next uh couple days otherwise the EIP is going to move to last call and uh be finalized um yeah I think that covers everything uh and then next call let's focus on the various uh potential eips for uh Prague and try to scope that out a bit more anything else before we wrap up

um so I just wanted to point out that

there's there's a new PR in the engine API we're trying to get some data so that we can measure execution layer client diversity which is crucial as we move into the Danon Fork um so if you haven't seen it please check it out weigh in trying to get more awareness thanks that's all

Tim Beiko: that's 517 right

correct okay great yeah

yeah it's in the notes it's in the notes for the meeting

Tim Beiko: sweet well okay let's wrap up then um yeah thanks everyone and uh also yeah if everything goes well on the test Nets and we figure out these uh these bugs uh we'll be setting the date for main net uh next week on ACDC so please

show up there to discuss that yeah thanks everyone

thank you thank you thank you thank you by thank you bye

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