All Core Devs - Execution #170

Transcript

[Music] foreign thank you

Tim Beiko: and we are live uh welcome everyone to ACD 170 um so today I will cover obviously the updates on the devnets uh then there's two final spec actually two final editions uh that we have to discuss so the max Epoch turn limit and then the blob-based fiop code um and then we had some questions around definite nine and if we have time uh after this uh the red team uh has never sort of formally introduced their clients on Awkward Dev so um we can give them some time to do this

um yeah so I guess uh to get started um does anyone want to give an update on devnet 8 and how things have been going in the past week uh yeah I can try Barnabas is still on his way to the office so I think he has a better idea of what happened last week but we had a few updates I think both to prism and to bezu the Netherland team was trying out a couple of new things I think they didn't speak a bit more about that later on um I think that's largely it we should be finalizing I do see some nodes are off so I guess we'll be looking into

either of afterwards um I think that's all on the devnet eighth side um but otherwise we've been testing a lot of Mev workflows we have the mock Builder that's more or less up and running and we've been trying out Lighthouse as well as lodestar on kurtosis and if any other CLS are ready then please just DME which image or branch and I can start trying out all the Mev workflows there

Tim Beiko: nice thanks um yeah any other client team want to add more color to that

Marcin Sobczak: yeah so uh in uh on another my notes uh we are running

the branch with block pool implementation and as far everything looks fine so we are like we are testing it on one note for a few days and uh in few hours it's running on all another my notes and everything looks fine as far

Tim Beiko: nice any other crime team want to share updates

Terence Tsao: rather than your updates I have some like quite interesting data point to briefly mention this is very very early but we haven't got much investigation but we're seeing blobs

cycle that's arrived approximately 500 milliseconds later than the Vlog and Lighthouse also reported they're seeing similar Behavior so I'm not sure whether this is we can type this Behavior particularly single Cloud implementation or this is just a general P2P Behavior but something definitely worth investigating moving forward because like we likely will see a fairly High reward rate if today there is additional 500 millisecond delay given the four second cutoff but yeah that's just something to look into

Danny Ryan: um sorry you're seeing the aggregate of both of the things like once I get both a 500 millisecond delay are you saying you're getting a Blog blocked normally

and then blobs are are delayed on average

Terence Tsao: um so yes so so there are kind of the same because we so in our implementation we wait until we have both before we process for choice and we're seeing blobs on average 500 milliseconds later so block usually arrive within the first like 15 millisecond and then we'll ups are arriving 500 milliseconds around there

Danny Ryan: yeah I guess I I ask about the difference because you would expect a race condition between the two normally like they're they're roughly the same size right like 100 kilobytes or something

um and so the fact that it's taking longer for this other message to propagate is like very interesting and maybe that's because of the additional verification in the Hop times or something like that um but I would suspect that it might be something more akin to like a certain client isn't forwarding until they get the block or something like that which is causing latency so I I just very interesting I I'd love to follow along

Terence Tsao: right so I think my pre-dimer analysis is that the Gabe Halo takes longer to return if there's a blobs bundle involved so the kpl takes about three times a stone this is my prelimary uh investigation where this is dating but yeah I can um I can give a

more updates later

Danny Ryan: yeah cool cool great that we're seeing stuff

Tim Beiko: um any other climb teams have updates they want to share

Parithosh Jayanthi: there's one more thing I wanted to add Mario's I started uh 4788 related fuzzing on the devnet eat as well

Danny Ryan: got it

Tim Beiko: um and I guess on the El side so another mine mentioned you're rolling out uh The Blob transaction pool across all the nodes on the devnet uh now um yeah from the other client teams I'm

curious about like the status of implementation on the transaction pool because I know that was uh probably the last big uh open thing yeah a few weeks ago um yes I'm curious do you ever does every team have something to deal with the blog transactions and how confident are you that it's production

already

Andrew Ashikhmin: still work in progress so we've checked in one like once we are but there will be like maybe one or more yards to improve our Global transaction tool

Tim Beiko: okay

Andrew Ashikhmin: so we are hoping to test that on devnet9

Tim Beiko: okay

Péter Szilágyi: um the blog pool itself has been ready for quite a while and we're quite confident that it works okay the only thing that is missing in gas code is the specialized feature for Block transaction So currently block transactions are announced the same way as every other transaction and they are retrieved without throttling or without any other productive mechanism so that's the thing

we still need to add College thanks um on the basic side

yes for Basil and in the next release there is the new layered transaction pool enabled by default uh these new implementation doesn't have yet any specific feature for blob transaction the the overall concept is that instead of being limited by number of transactions is limited by size so in this way even having more big transaction means less transaction in the pool but should not create problem with the memory uh the

idea is to continue to tune it in order to have specific configuration or specific transaction type so and for blobs there will be less blob for senders and also uh strict limit for for props but at the moment uh drop transaction are treated the same as other and yes we still need to see uh how to find unit

Tim Beiko: got it thanks um so these are questions about the

question in the chat about years accepting blob transactions before the fork in the transaction pool because does anyone see a strong reason to do that

or

by default the best who doesn't accept this before the fork

Tim Beiko: why does the hive test demanded there's just a high test testing the interplay of the four Choice V2 four Choice V3 and it's trying to make sure there are blobs in the first block after so ah if it just seems most Els activate their transactions

type the the new transaction types whenever the fork is activated so you can't propagate transactions of that new type until the fork is active I was yeah I wasn't sure if anybody was wanting to start supporting the transaction type before the fork if there was any use case outside of just this test

Danny Ryan: it doesn't seem of immense value if there's additional complexity to do so I mean yeah it's not really much more complex it's just I mean it depends exactly what we do but it could be a little weird if we as soon as we push out the mainnet release candidates and

people upgrade for blob transaction just sit in the pool for a while you know days or weeks that would be weird

Tim Beiko: yeah it seems easier to just change the hive test to have an empty block yeah absolute fork or yeah we'll we'll talk about it offline thanks

Mario Vega: yeah we can make make sure that it doesn't happen I mean it's really easy to Simply modify the hype test

Tim Beiko: sweet anything else on devnet 8th or recent client updates that people want to share

okay so um next up then there's two potential spec changes uh you have to discuss uh yeah let's let's do that I just wanted to cover devnet nine after we discussed these spec changes so that we uh we can then debate uh if any of those fact changes make it in should they be part of that net mine or not um so the first one yeah the first of the spec changes is a CL change uh so there's now an EIP for a dip7 514 which uh that line presented on last week's call about adding uh Max Epoch churn limit to the validator queue which would

lower the rate at which uh validators can join and sort of limit or push back the time when we'd have uh 50 and then you know more than that of ease being staked yeah so we we discussed this on last week's call we're hoping to make a decision today given it's already quite late in the fork planning um so yeah curious to hear from uh CL folks yeah what do you think is

Danny Ryan: a quick note I believe that the current favorite proposal is asymmetric meaning this is only to the activation side of the queue and doesn't change how

exits happen um and there's an open PR it's had review um I believe xiaoway has been adding some tests and that like in the event that people want to do it uh it's very simple from a testing and release

puzzles thanks uh thank God yeah I mean I'm

Dankrad Feist: I'm in favor of doing this I think um it's it's very like I think there is a chance that um the the queue will stop being full at some point end of this year start of not next year or something um but I think it's uh it's a big gamble

to bet on this um we're not sure what's gonna happen and I have a fear that uh that we might get into like a very like into a situation where we could have to make very drastic moves on staking and so if we can agree to do this turn limit stage uh change then it would be uh for you be much more comfortable for us to make like more measured uh yeah transitions during the course of the next year or the year after rather than having to rush things

Tim Beiko: yeah how do you CL crime teams feel

about this

from the lighthouse side I think we we all uh are Keen to see this but the asymmetric version

uh yeah so I I was like a little resistant on the last call but I after looking into it further I think um yeah one the asymmetric version is nicer and to the actual like impact on wait times I don't think will be as Extreme as like I was maybe initially thinking because um the rate of new deposits is like currently lower than churn so I think

that the huge Spike that we had after withdrawals isn't actually the the norm um but yeah I still agree that it'd be good to have this train limit to limit like the worst case scenario

Tim Beiko: got it thanks uh Enrico

Enrico Del Fante: yeah we want to report we did an internal uh survey and generally the Google Deco team is in favor of adding uh this limit um yeah also we were looking at the last version and seeing looks simple to to implement

it was just a comment from from band uh giving maybe there there might be other alternatives to include in deneb maybe having another um consensus only for work to include it since maybe we are not super in rush but it's just a comment and generally speaking we are in favor of having this even in

Internet um any other CL teams

Danny Ryan: I suspect we can count lodestar as

four

Tim Beiko: uh okay yeah I see a plus one from load star yeah I don't know if anyone from Prism has thoughts

Terence Tsao: I don't have much thoughts I mean I trust all the CL teams on this but my Sly input is just like um with an app with blob the gossip May gear Wars so it seems like to me it made sense to account for that extra factor which that we don't have today

Tim Beiko: got it and anyone from Nimbus on okay it doesn't seem like it um so okay

so it seems like there's pretty broad support to have this uh pretty broad support to have it in the neb um and then there's a couple comments in the chat about the actual uh limit which I don't think we've chosen so the EIP uh proposes a couple different limits uh to be considered um yeah so that's probably assuming we're going forward with this then that's uh probably the thing we want to flesh out now um Ansgar so you have your hand up

Ansgar Dietrichs: so just stay on that point I personally would really like to see like a limit more like eight I think kind of the default one that was of course was 12 but there was different

ones kind of um like um in comparison and for me eight looked like the best compromise it doesn't limit the duper of the queue too much for users but it also still ends up giving us a significant kind of extra breathing room to just have more time to figure out all these questions first with 12 we still basically it's the cube roommates will we still have a relative rapid size Pro growth so I don't know if if unless people think it is true aggressive I think that would be a really nice

value thanks uh Daddy yeah I Echo OnStar sentiment hey

Tim Beiko: okay I guess does anyone want to make the case for another number than eight

it is a power of two as well has that going for it okay so in that case I guess we're adding EIP 7514 to the neb um we'll set the constant to eight and we can update the EIP and remove sort of the extra extra tables uh to make it clear what the impact is yeah does that make sense to everyone any objections or pushbacks

Danny Ryan: and just a note I I would suspect we can do a release on Monday

um I don't think we can confidently get it out tomorrow with the testing that we want

Tim Beiko: yeah and then let's do the blog basically and then we'll discuss how all of this fits with the devnet9 as well um but okay yeah let's consider this uh for uh sorry let's have this be included for uh the neb um and okay so we had another proposal this time on the El which was to add a blade a base fee to retrieve the blob uh The Blob gas price um so arbitrum mentioned this and then Carl uh put together a quick EIP to formalize it but the idea here would be

that um similarly to how we can query the execution layer base fee uh or I don't know gas price basically uh we could also allow um allow query of The Blob base fee and this makes it easier for l2s to generate uh transactions and whatnot that are dependent on this oh okay sorry before we go that Mikhail has a a final question on the churn EIP on the validator side so um do we consider the asymmetric version of the EIP or the symmetric version which seems I think we

all said asymmetric but I just want to

Danny Ryan: yeah make sure the question of the outside was asymmetric that's the pr that we've been under review and we're working on testing on in terms of the security from a uh accountability standpoint with respect to finality um there's only an improvement in that and the Improvement in which activity period um in either of these proposals um and we don't see any downside from a security standpoint and having it asymmetric obviously if they're dissenting voices on that we'd love to hear them immediately but right now that's our understanding of the security argument and that's our understanding of

kind of the the doesn't create any sort of degenerative incentives either

Tim Beiko: okay anyone want to push back against asymmetric okay so we'll go that route and yeah we'll make sure to update the EIP to make that clear as well

um okay black to the base fee so um yeah we have the CIP called put together it exposes The Blob base fee in the evm so it's very similar to eip3198 will expose it's just the basically op

code and yes this would make it easier for ltus to uh to interact oh lee uh are you're the one that proposed

that's correct yeah so I didn't write the EIP tea clear thanks Carl for that but um I initially suggested the uh The Blob gas price or blob base fee op code

Tim Beiko: yeah do you want to maybe just yeah talk like a minute for like why is this useful for uh arbitrum and other

ltus

yeah absolutely so um Altos need to charge users for the price of code for the price of posting the user's transactions to L1 or specifically Roll-Ups too I suppose um and

because how l2s generally work is there's a sequencer which accepts users transactions or if there isn't a sequencer there's some sort of aggregator model there's some entity that accepts users transactions over the RPC posts them to layer one and it has to charge the users a fee to um to pay for the cost to post those transactions to layer one and in arbitrum this is a trustless model where um the arbitrary system automatically sets the um automatically sets the price of this L1 data and it does that by looking at how much batch posting batch posting cost

and what the current base fee was at the time of batch posting that's in the system today but in Yeti 4844 um without the blog base fee op code it's no longer visible to the evm what the cost close of hosting the blob was or what the current cost of plots is so this EIP aims to address this by simply exposing that information it's already needed in that the evm or the El already needs to know this value tube charge for the blobs so exposing it to the evm shouldn't be much additional complexity there

Tim Beiko: yeah so we have as well yeah parallel

from optimism uh I'd be curious yet to hear this is also helpful for optimism and yeah I don't know if you have a mic uh it's okay so there's a comment The Blob base feature is not to require oh do you want to just yeah go for it

Protolambda: yes I got well so it's not strictly speaking like not strictly necessary for a day or two where you can do the fee Accounting in the layer two in the layer 2 should be able to access any state any data from

another one already now it is nice to have like I think it's a good Improvement and since we already have the base fee information I don't see why we should not have the

the blood pressure

Danny Ryan: to be clear you mean accessing through Merkel proofs into layer 1 headers

Protolambda: yeah exactly yes so for example room dial information that the there to exposes from the later one is also already basically passed along from layer one into Layer Two and layers don't use the difficulty of God for this like this is entirely true just a function of some

data that the layer 2 node sees and then converts into the layer two block

yeah historically Arbor firm

has not parsed um player one block headers um I think definitely applying that as they work around would make sense um and I think we figured out how that could be done for the blob-based feed in particular um it's particularly helpful for this workaround that the previous blocks header contains all of the information needed to figure out the Block Base B of the next block which would um because the parent blocks hash is exposed to the evm but um I think that this would be still a very

useful option to have both in terms of both in terms of I'm not sure on other else whose architectures and I'm not sure how many of them have looked at this particular part of eip4844 or how applicable this workaround would be to them and also if you want to make an L2 immutable um it you can't be parsing the L1 block header with no way to upgrade it because there's a risk of the L1 block header format changing in the future

Tim Beiko: right that's a that's a good point yeah there's a comment by Terrence but there's any ZKA teams uh that have

feedback on this side if there's anyone from a ZK robot team on the call another chance to speak up um so okay so clearly this is like oh asgaria yeah

Ansgar Dietrichs: I mean obviously not from a CK team I just wanted to briefly mention that while the the FPS is kind of a proposed to just have the up code that just pushes that one value onto the stack I think part of the reason maybe if I remember correctly by the Erp like right before it not initially include an awkward like this was just that we weren't but like that people wasn't weren't quite sure um how best to expose this just because

I think instead of just always having individual bits and pieces of Header information or context event context information over at some point we would want to have some sort of more structured way where you can basically go through some sort of pre-compile so you can completely stop always having to you know go through the head and that that would so that we have a longer restricted in updating the header structure and all these kind of things I mean this is Aboriginal disgrace basically ideally you don't want to go through your header if this is enough of a nice to have that we want to have it in Lincoln of course that's not feasible because then we need a simple way to do it in that case I would personally still prefer at least to have the op code be basically forward

compatible with multiple P Dimensions so we just basically take one value from the stack and then just um that's just the P Dimension basically so at zero it Returns the normal base speed one Returns the the database fee that now we have two up codes that both which have the normal basically but I guess that doesn't really matter and so then at least it's forward compatible I think that might be nice compromises you know a trivial change up to the AP um but yeah if we don't add it to denkun I think we would should instead start like a conversation soon for the next book after or maybe we should still do that how to expose and kind of had that information in a more structured way inside the evm

Tim Beiko: right thanks uh Carl

Carl Beekhuizen: yeah I mean I think it's very nice to be

able to expose more of these things uh from the header uh but I also don't think it's quite as simple as unsca's make it out to be um the like just trivially looking up header items is uh relatively constant but if you want to start adding more fee Dimensions uh particularly if we're starting to look at the L2 things like grouper costs or whatever uh then I think it starts becoming very complicated as to what the gas schedule looks like for all of this so I think like if we do want to do that having this like perfectly future-proof thing I think that looks like a very complicated research problem that will take much longer and would potentially push out this solution for a while

um Lee and then Andrew

yeah I wanted to um just briefly mention that well I definitely think something like an OP code that exposes different parts of the ebm context could be very useful um I don't think it could be quite as general as reading different parts of the header there are some parts of the header which should not be exposed to the evm because that would break the mining process and um also the blob gas price isn't a field in the header it's computed from two different fields in the header so I think um exposing the even context would definitely make sense I'm not sure about the just exposing generalized header Fields um also I think it would make more sense for this to be in the op code instead of a pre-compiled

um if we're talking about generally exposing the generally exposing different parts of the evm because for instance base fee um block number those things I don't think you want to pay the overhead of calling fruit and pile for blob-based feed I'm not concerned about overhead 4 but if this is just a general EDM context getting thing then keeping it as not code would probably make the most sense

Tim Beiko: got it thanks uh Andrew oh you're on mute Andrew

Andrew Ashikhmin: oh sorry uh yeah I think we should do it

because it's basically consistent with the base heat uh it simplifies live for abitrum and probably other ltos it's an easy change so it doesn't introduce any inconsistencies if we decide later to do some something clever about exposing the header we will just we'll have to do it for basically and blob base here and so on so like adding blob-based scene does not complicate that future refactor

Tim Beiko: got it thanks yeah and I guess this is probably a good a good transition like to hear from some of the El teams like do any El teams think this is not worth included or are opposed to this

or I guess have any other comments uh yeah so get yeah Geth already implemented it I think it took Marius 10 whole minutes that implement it as we were on a call together okay nevermind sends in support uh Carl you wanna

Carl Beekhuizen: other yeah just on the Lost comments thing uh I see I had a collision with the uh um the opcode number whatever so it's uh it will change to exactly what get has right now so it gets basically done it okay and what's one minor change

Tim Beiko: so what's the op code number that we will use

Carl Beekhuizen: I had zero x49 just goes next to uh blob base fee yes because I was using

evm.codes and that's an account for blob hash which already has rx49 so then it'll be zero x4a

Tim Beiko: okay so 0x4a would be the right one okay and we already have a PR for testing great yeah um okay so last call any objections to including this okay so uh let's uh yeah let's add this one on the execution layer side so we'll update the EIP to reflect the new uh op code uh address and I believe that's the only change we need to do to this EIP

okay so with all of that out of the way

uh definite mind so we had a plan to launch that nine in uh uh no we should not add more things EF Berlin um yeah we had a plan to launch that line in I believe five days so does anyone on track for that okay so Barnabas is saying we're still on track for that which is great I assume we should include those two changes in devnet9 does anyone disagree with that okay so we include both eips

does it yeah and do any client teams think it's not possible to get that done within a week

Parithosh Jayanthi: I would say as with the previous devnet Cycles we're gonna first have to have the client releases then make sure the high PR is merged have it in Hive do the local testing and get it on the devnet so I don't think they have nine Tuesday which is essentially four days from now it's realistic um just probably should move it by another week

Tim Beiko: got it and I guess is it realistic for teams to say a week from now like on next week CL call having implemented those things and passing tests given they're both quite small

and then assuming we get there that on the CL call we can make sure to iron out um like the final timelines for devnet9 um we also have the testing call next Monday so if if people run into issues in the next couple days um or there's something that's more complicated than it seems uh we can we can discuss it there but let's maybe aim for like implementations that are passing tests next Thursday um and then yeah on the CL call sanity check the the launch date for uh devnet9 and hopefully yeah those are not all plus ones on the vacation uh but plus one's on getting that done by next week

okay so and then so for definite nine um one more thing we've been doing these four seven eight eight audits uh in the past few weeks uh we've got three audits uh I believe two out of the three are complete the third one is finishing this week um so they've uh they've revealed some small tweaks uh to the 4788 uh contract we were planning to go over all the audits uh reports on the next acde so two weeks from now um so there was a question as to should we have the like should we have those uh audit post audit changes part of devnet9

or do we want to wait potentially another two weeks until all the audits are finished and we've had time to um to review the changes uh and and the reports uh yeah other people feel about I don't know if there's that much that will be necessary to review so maybe an optimistic case we just plan on moving forward okay I guess

Danny Ryan: yeah I'd be fine sharing the audits in a summary of changes in ACD and if it is an issue uh to deal with it rather than assuming we need to get on a call to share

Tim Beiko: yeah so I guess given we have at least

two of them done and I think the next one the other one is finishing tomorrow if I got that right can we discuss that on the CL call next week and if there's any more change that comes from this week's audit we'll have them included there and even though we may not have all the final reports and everything we can at least walk through the like yeah the pr which people can already start reviewing and then on the on the next CL calls or a yeah agree to merge.pr and to the changes yeah that's fine our calls are converging uh but yeah yeah well yeah we're getting close to shipping distance

so I tried to save weeks or we can I mean I can also mention yeah yeah do you want to go over it yeah yeah the output of the first two and how that's changed uh I'll post the pr in the chat here um yeah I mean I'm I'm hopeful that there are no other changes beyond what was found in the first two uh because generally the audits have been pretty good there hasn't really been anything you know specifically found there were three things that were sort of nice to have improvements the first uh main thing this was like the thing that we wanted to fix the most was that there was a edge case on the

get method of the system contract where if I passed in the timestamp of zero just all zeros it would actually return zero as the beacon route and it's not really useful for anyone I don't think that there's really anything that could have happened if this was live because you can't create then a proof against a beacon route of all zeros but it was a kind of a weird Edge case on the correctness of the pre-compile it was designed intended that you would the contract would revert in case it asks for a time stamp that didn't have an Associated Beacon route so that was the main thing that we really wanted to address and so now uh in addition to the other checks that

exist in the uh EIP to make sure that the timestamp passed in is actually associated with the result we make sure that the timestamp that's passed in is non-zero so that was the big thing the two other changes were very optional uh honestly just like slight improvements but OnStar had had taken a look at this a little while ago and he thought that the history buffer length the ring buffer length was um not the optimal size if the saw time were to change and so he proposed that we modified the buffer length to be a prime number roughly around the number of Beacon routes that we wanted to store so we wanted to start 8192 turns out

that 8191 is a prime number and what that gives us is that no matter what slot time we change it to the buffer will always be 100 full so we won't incur any additional storage overhead of kind of dormant storage slots if the slot time changes so this was kind of a you know nice like small uh change that was beneficial and then the last one was really just more for aesthetic preferences the uh the original contract was written to use the call data copy op code or sorry the call data load op code two or three times I think and we just modify the logic slightly to use call data load only once just in case in the future if called

Data happened to change in price um there's really yeah it was just Aesthetics it really didn't need to load it from call data multiple times once it was on the stack we kind of just uh duplicated and then swapped as necessary so those are the three things that we sort of found that we want to change based on the audits nothing else has really been found and yeah optimistic that after this next audit nothing else we found so I mean honestly the main reason that we haven't merged that PR to the EIP itself is that we're trying to just finish mining an address to deploy the contract to so yeah once once we find that we'll update it and um yeah merge it

yeah thanks for sharing it

Danno Ferrin: uh um can we get the explanation of the Prime modulus into the EIP I think that's really useful um but I think we will lose track of it if we only have it in this call um also there might be issues that it might be unreliable when we're transitioning between block change times because it's going to fill the buffer in a different order so that might be worth calling out as a security consideration not worth stopping but I think it should be called out

any other comments thoughts

Andrew Ashikhmin: I think there was a format from Mario's

is that the buffer size or something was was wrong in the pr something like that oh sorry for Mario Vega I think I was looking at five tests so yeah and download this course there was some comments

Mario Vega: yeah on the white code I think the modulu modulus value was incorrect and I I've not I don't know if that's already addressed yeah it's updated and actually maybe it's not updated on the EAP it's updated on the pr to the the byte code um but I yeah I don't know if I pushed that onto the

IP

Tim Beiko: yeah and I guess

the other option is we can also push to merge all these changes now and so it's kind of finalizing the EIP even though we haven't had all the full audit reports but it might make it easier to set up tests and and uh and whatnot would people rather do that or are we fine waiting until next week and and having the reports out and uh and the I guess confidence that nothing came out the next like in this this last day of audit or maybe another way of phrase this is anyone blocked if we don't

if we don't merge this uh before next Thursday

Danny Ryan: yeah I mean these are generally like transparent changes to the actual clients like the interfaces don't change so I I don't see how it's going to cause complexity one way or the other

Tim Beiko: okay and Maris when you say you would like to re-audit it do you mean having new audits run on this latest version or

Marius van der Wijden: sorry it's a bit loud here I would I would just like to run run like the

audit that I like myself did on it again on these new versions but I held off on that because I wasn't sure if the like if the improvements would make it through or if the changes would make it through and uh so oh that's my plus

um is

Danny Ryan: anyone descent against the changes as they currently stand and that any other changes would be like additive or in relation to further found bugs because you could I think given the state of where we're at like you could confidently audit that um also the auto reports coming out tomorrow so you confidently audit the pr especially after that audit report comes out

Tim Beiko: the reports won't come out tomorrow

sorry the audit will be done they'll probably send us an informal message to say you know looks good or here are some issues but the report probably won't but yeah

this

Tim Beiko: yeah does anyone oppose merging as as this changes is okay so let's maybe okay let's merge

these in well we'll discuss it again next week just at the very least to send it to check that nothing else has changed um and yeah it'll make something a bit cleaner for people to review um yeah in the in the coming week um anything else on 4788

Andrew Ashikhmin: yeah well I wanted to bring another thing uh is um like there is the subtle um if um you start with an empty system address that currently like

but

Tim Beiko: we lost did you just drop off the call yeah I can't hear me oh sorry is it better now uh yeah you're back yeah

Andrew Ashikhmin: Okay so basically like uh you would expect you know the system transaction to touch the system address uh and and then delete it at the end if it's empty but it doesn't happen in in yet and and no no no does it happen in Azure though because there is disability that the sub balance does not touch the address of

the transferred value is zero so effectively when it was effectively what it means is that the system address is not touched and left empty after a system transaction which is and so if we just agree that okay so there's there is this work some someone unexpected I just wanted to ask to agree while we keep things as they are currently implemented in yes or change anything about it and the these are there are just cases in the execution spec tests that

actually are uh rendered with with this behavior that the system address nmt system address is not uh cleared at the end of the system transaction so it's it's it would be fine that's that's this weird quirky Behavior that's why not oh oh we change it

Tim Beiko: um okay I see there's a couple of raised hands already so

mirac Le

Marek Moraczyński: okay my opinion is that we should remove this account from the state uh just by uh readings all uh all the IPS

however it's important to have that it's not minute issue and we analyze here only the edge case that is possible in high Fest but if we agree that we should remove this account from the state it would mean that some clients would stop passing the test only because of this empty Edge case uh uh however the client won't pass the test if they Implement for 788 as a direct right to the state without system transactions so they do not touch system account uh so what else we have an EIP 4747 that said that we removed all empty

accounts on mainac and clients are free to remove empty account handling edge cases from the code base so the thing is that we end up in the funny situation where there are two valid results of these tests unfortunately uh this Edge case is bundled together with two other with other cases that all clients really really want to pass and test so my proposition is to move this app space scenario outside of other four seven eight day and got contesting and just keep it as a separate test and I'm not sure maybe it sounds weird but clients

will be free to pass it or not depending if they want to rely on this system

uh assumptions um anywhere else have thoughts or make sense to me

Tim Beiko: okay so just to make sure we're all clear uh you mind just summarizing quickly what the password is

Marek Moraczyński: so

uh I guess we should remove this empty account handling from hive test and maybe keep it as a separate test yeah and it will be up to the client if um it is weird but it will be up to the client to pass or not this test so they can rely on assumption that there is no empty account accounts on mainnet and they don't need to touch and remove this account so it makes sense for Android for you for your like client as well

Andrew Ashikhmin: um well I I would like us to agree on on the same behavior because uh

we actually um it's kind of this one of those Corner cases that uh better if we do if our clients we had the same because then we'll have worry less about Pro protocol uh failures uh yeah I I would prefer to formalize it and agree on a single approach

Marek Moraczyński: so what version you would like to see removal or keeping in the state well it's probably the easiest version well well for me is that to keep things as is to keep this

weird Tech work that exists in a gas and then Aragon and not not remove um empty system address yeah but it would mean that it's so in theory by reading all all the IPS like uh 158 and 171 uh we should remove this so well maybe we separate this test it will be I haven't I don't know a bit easier to

arrive

Andrew Ashikhmin: exactly when an address is touched transfer well okay kind of color I see it because uh it was like it was never never specified and the touching of addresses was never formally specified in the yellow paper so I I guess we we could follow what would follow gas and treat guests guest Behavior as as the standard

or maybe I don't know does the new does EOS specify um whether an address is touched or not like like exactly that like the executions back does it specify executive and um when address is attached

Danno Ferrin: the reference test is normative whether or not it's in the yellow paper so that's when I do evm stuff and basically that's the approach I've been taking is that the tests that have been in place

for years are normative um as far as system accounts the rules not deleting system accounts is about specifically not deleting the right MD address um that's what's written into the yellow paper so that's the one exception that resulted from the Shanghai attacks

Tim Beiko: given there's like some uncertainty here is it worth maybe taking it offline and bringing it up on Monday's testing column after people had like a couple days to look into it more okay perfect let's see that's um

yeah so I'll make a note um and I ping the Els teams as well so um yeah let's let's discuss this on Monday um okay so I think yeah this was the last uh definite nine open question um so we'll we'll sort that one out on Monday but aside from that uh basically we've agreed We'll add uh the max Epoch turn We'll add the blog base fee um we'll also add the changes uh that have currently been um proposed by the audits for the the 4788 contract is there anything else people feel uh

should go in that that mine specs um assuming we'd want devnet9 to be the last one before we move to actual test Nets um so is there anything else we should be testing there uh yeah Mario

Mario Vega: so yeah probably The Trusted setup update would be a good idea to to have it in the demonline the mainnet across the setup

Tim Beiko: using this so loading the the mainnet file and using that

Mario Vega: yeah but this also comes with the update of almost all tests I think so it's it's a pretty high high

modification to all all of the tests it's easy to do but I I was just wondering if it's ready for for us to use

Carl Beekhuizen: so uh long and short of that is gonna need another say a week and a half to get that ready uh making some changes of those two file formats and that kind of thing

Tim Beiko: okay so then I would not block devnet9 on it agreed will we want I guess we could have like a super short-lived devnet if we just want to run through this on uh before going on like whole Sky husky or Gordy but yeah that would be the last thing I

guess that's that's out of scope for devnet9 anything else okay so yeah let's hopefully uh sort out uh this issue with the touch addresses on Monday and then by Thursday uh hopefully teams all have uh everything implemented for devnet9 and on the CL call we can discuss uh when we actually want to have this thing go live um does that make sense to everyone sweet so that was I think everything

from the spec side uh last thing we have today is uh the Reds team wanted to take time to actually introduce their clients so they've been working on it for a while and slowly becoming part uh of the the stack so um yeah George's take it away

hello good morning um let me share my screen all right this should be visible all right sweet so thank you for coming to my TED Talk and thank you for the introduction uh we're going to talk about red

which is a new execution layer that we've been building at Paradigm for the last um maybe almost a year now year and a month or a few weeks um the repository is here the dogs are here we have a book a chat room you can find me here and I will get into a few details about the client today and feel free to interrupt me so what have we done uh firstly we have an execution layer that Apache Mighty license in Rust the reason for the license was to make it maximally permissive for third parties to be able to consume it without having to think about the license

review the node as the first use case but what I'm really excited about is the usage as an SDK in infra so we pay a lot of attention to our abstractions to our tests or documentation such that people can use components of the node without having to have the full thing and we've already seen nice results for that which I can go on in a bit um it has very good performance we test on beefy Hardware so caveating that this might not always work for everyone but on the hardware we tested on on latitude and third-part Discovery reduced it with sync in 50 hours which is really impressive okay and that is in archive

mode uh full node syncs slightly faster due to less data written but overall the rough is the the ball is like around that I have two IPS here that people should feel free to play with they're running Alpha 8 uh it's been up for two weeks alfayette is running on the same machine and it's keeping up with the tip without any issues so we want people to hit this box and ideally identify new resource leakages or issues that we haven't identified so far we take an open source first approach a lot of culture around mentoring onboarding people and so on so far we have over 150 contributors with only eight of us being Paradigm funded me

included um and we have some encouraging numbers also on the library usage um just to give you a quick architectural uh sketch and I acknowledge that this should be a lot deeper but uh just to take this from a high level um on the sinking mode we employ Aragon's technique of the pipeline or stage sync which means that first you download all the headers then all the bodies then you recover all the senders then you execute then you generate the state route blah blah and this causes a nice thing because it allows you to separate workloads from each other and by separating the

workload from each other you can heavily optimize because each workload is very specific so some some stages are going to be CPU bound others are going to be i o bound and you can very carefully optimize each one without stepping on other people's toes we employ a new mechanism that we call the blockchain tree for staying up to sync so the pipeline or the stage sync is used only for the historical sync you should almost think of it as like a database batch read a batch historical backfill uh where the benefits of loading over big ranges of blocks are valuable was for the Live Sync we employ an in-memory data structure which basically tracks the last n blocks configurable uh it creates a tree of all

the possible states that you can be in depending on the messages received from the engine API um and then anytime we receive the four Choice updated we can only realize a branch of that tree or Flash into disk and everything else gets discarded in the database we employ the flat database design also an ergon innovation using the fast incremental State Route algorithm that they also came up with and we use mdbx via rust because we like consistency we like having multiple readers on the database and we have historically really liked its performance which is also driven somewhat by the usage of Mema um I haven't run personal benchmarks on

this but the node also performs well on ZFS currently we employ um that is decompression in some of our tables but some people have run rest nodes with ZFS and zsdd or lc4 I forget enabled and they had an archive node as low as 1.2 terabytes big asterisk on this number I haven't replicated it but I've heard it from more than one person revenue is the engine at the core of ref it's a VM developed by a dragon who some people here might know we use that evm in Foundry as well it's I think um the fastest if like I think evm1 might be faster in some uh Benchmark or

most benchmarks but it's General very easy to consume as a library it's basically hook on in various steps so it allowed us to build a lot of nice things on top of it for Json RPC um no w we support both guests debug Trace including the JavaScript Tracer by embedding a JavaScript runtime um whenever a user provides them a tracer and we also support parities uh original Trace module which is obviously very useful for map searching for data analytics and so on what one thing that we've done which I think was very useful is that we run the engine API and the blockchain tree in a separate thread from the main system which means that if somebody hits their

PC very hard it does not cause research contention with the consensus critical functionality which is nice um we take a very defensive depth approach to our releases dogs and testing or I guess in our testing and I'm not going to go uh through all of this right now but we have a lot of dogs we have a whole book for node operators we have rust docs inside the code base in fact we have lints in the code which do not let you merge publicly exposed code without documentation and we have a good map of the repository here for anybody that wants to follow we run Hive on a nightly basis um it runs on CI we get reports about it

we fix them um and yeah we're overall excited to also be included soon in the Upstream Hive testing Suite um another thing that is very interesting is that we developed an RPC load testing tool which we we've been using to evaluate RPC providers third body RPC providers but we also use it for equality checking uh as a differential fazer effectively between two rpcs so while we were testing our tracing implementations for example uh we were running the trace we're running flood with the equality mode on for an ergon a guest and a red node and would like see where was there a diff and we didn't slowly find the bugs so very very feedback loop-driven approach with

automated dueling for testing and so on um so far so good in terms of performance benchmarks uh this is the box that was mentioning so it's a big beefy box it costs order of 250 bucks a month which is quite a lot um it the sync what we found out is that the sync really depends on the disk and I know that most people in this room are experts like we didn't know about this and so we were very surprised to see a very big variance in Sinking time depending on this on the disk um and a matter of fact there is a great uh gist on GitHub or guest uh with a bunch of disks that you can use for sending nodes not just wrath nodes any

kind of node and overall pretty exciting to see like more people kind of publishing their numbers and overall getting a better understanding of what is the optimal like disk setup for a good ethereum node um again something that people know here is that the AVM is single threaded so less cores more clock speed is good for performance uh however we're starting to iterate on some parallel VM work and we're excited to see if that's gonna change in the future um Ram requirements it's eight gigs but we hope to go lower because it's all configurable and basically it's a bunch of in-memory caches uh that we can tune down uh it already has synced on ethereum on arm uh after coordinating

with the founder of the project so there is promise also in like lower end devices um this is like a meme I like to use from around we might have here basically we're not production ready um we are eight Alphas in um we've been running nodes for weeks without issues um but I cannot in good faith recommend somebody to put a hundred thousand dollars or whatever it is uh today in software that is a few months old without an audit uh if there is interest in helping with another please reach out or if you want to run a node also please reach out I know people are running it in production um we don't provide any reliability or

warranty for it um I don't know that we will ever will um but we hope to be production ready by the end of the year Cancun which is the big question for here uh basically you can see the establish here 4844 we basically have it all done in the evm we're merging the pr day mem copy is done t-store is done self-destruct we just had an open VR The Blob base fee we just had the APR um for it actually like a few minutes um 4788 it was very nice to actually see that it was not required to make evm changes for it and I think it's almost done and for 4844 the main thing that we're missing is a non-disc implementation of The Blob pool but we have an in-memory implementation of it

which means that we can move on uh hopefully to the definite testing high level cultural point from like our team we try to be good vibes and collaborative and I think this is kind of like the Cornerstone of the vibe um we have been attending awkward devs I haven't been because it's 7 A.M on a Thursday but sometimes I think most of the team is present because they're in Europe um we are happy to be part of any calls discords like sending us stuff to prototype we want to hope that we are able to prototype uh quickly one thing that was part of the core not like motivation of building the clients uh

we're happy to give feedback on future IPS or to be asked for feedback um and uh just to say it like we don't have like any political agenda here like to push for any like crazy changes uh if there is anything that is very numbers driven and we can provide a good objective uh in case for it we're happy to do the research or do like push for it if it makes sense but I don't think you know uh you would expect me to say oh there's a paradigm private funded company and like we would push this like that's not that's not the vibe here so just wanted to comment to that um and somebody has asked us about if we would do ACL we're not planning to um I am open to creating a single binary for like combining the nodes together as

an experiment but I don't know that this is like a great practice you know just because you could doesn't mean you should so TBD there but again open to experimentation we're like clean slate oh there's a big slide um so uh next stop devnet9 uh we hope to be ready for it whole skiing as well um very excited for that to kind of like Get out of your of our channel in the next steps or roadmap items we have snapshots um snapshots are kind of ergon style flat files that are used for accessing historical data unfortunately due to the way that we set up the sync which is also similar to Oregon we're not

compatible to the guest never mind snapsing we want to be part of some kind of snapshot thing that lets us be collaborative and also see data the network not just be Victorian glitch which is um it's not clear how we get there so if there is questions or discussion we can have on that please reach out and the third one is production Readiness so the hope is basically where feature complete with Cancun and snapshots and end of the year two three months of more polish audience refactors having our coverage and sharing 100 on hive all of that and we hope to have mainnet production testers soon and ideally you know we can enter

2024 and be like red is 1.0 use it let's go um there's a lot of like research that we want to do in particular more performance things um I'm a big fan of IO Innovations in databases whether it is I O urine in the kernel or direct i o if you have experience with that please help us um on Parallel VM we have designs we have read all the blog STM papers we have read the Aptos to move the like polygon implementations like we know how to do it I think um but I think there's like low level uh issues that prevent you from like going too fast so we're also happy to discuss about these

um and yeah please talk to us about any future ethereum changes uh we're happy to experiment discuss provide critical feedback say this is a great idea I'll say this is a bad idea but always good vibe and collaborative I think that's it happy to take any questions

Tim Beiko: um there was one question earlier around snap but it got answered both in the chat and through your presentation uh there's a question by Justin what's uh what do you use for the underlying key Value Store we use a libm dbx uh we do the library that was used in cell gorm ergon and this is a c like this is a C library but we have a five to it over rust and the

bindings were written by artem uh who was the previous rust node developer um we are we have abstracted the database to be behind an interface and we already have been experimenting with alternative uh databases the main thinking here is that we want to not be kind of like logged in to a certain B for example we don't allow the usage of mema in mdbx um because even though it gives performance in some cases the data sets are big and when the memo when the data set is bigger than the memory it ends up hurting performance actually so in general like we wanted to be able to experiment so mdbx is the first

database I know somebody has been experimenting with the postgres backend without it necessarily being a good idea but we have a clean interface for implementing new ones so you know we started with that one because that was the easiest one uh to use the best for performance but we're open to new ones you know if you could give me a Cassandra DB like integration that gives us good performance I would be also open to it what's the use for the underlying restore I'm not sure I understand the question I think that yeah that was the question you just answered okay yeah okay yeah

Georgios Konstantopoulos: there's like two details also on that which are interesting I think we do

um mdbx or in general like these types of databases they have uh transactions which means that you to write many things to the database you don't need to multi-thread and like just spawn a bunch of go threads which I think is how it was done in level DB uh you're able to open transaction roll up in memory a bunch of like database changes just flush them and we have architected in a way that only happens across blocks so by leveraging the acid of that database you're ensuring that your DB is always in a consistent State and this is very powerful because you never control c and end up in a Corrupted State which is a lot of like node devops issues

yeah

Tim Beiko: is there are any more questions

comments either raise your hands or put it in a chat okay yeah uh well yeah thanks for sharing this and yeah great work on

rest

Georgios Konstantopoulos: yeah of course thank you um snapsing is very top of mind I'm saying right double questions on this I don't know honestly I don't know I thought about like adding three images in the um in the things being gossiped I heard that there is like image pretty images being ghosted in the vertical trees um yeah I'm not sure ibfs back and when when I owe and bandwidth stop being an issue uh we do

have we had a first look at vertical um I have a dog I don't honestly I haven't read it in weeks um so I don't have a good answer there I know like like one person or team is like responsible for doing Explorations yeah we have a thread the Dual Merkle tree component seems like very scary and a lot of Maintenance overhead so no strong opinion but just saying it feels meaty

Tim Beiko: see any final questions okay well yeah thanks uh Georges and I think we also have a rest tag in the r d

Discord if people want to tag you there for any questions sweets that's everything we had on the agenda anything else people wanted to cover before we wrap up okay if not well thanks everyone um talk to you all on the Monday testing call

thanks Tim thank you thank you thank you [Applause]

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