All Core Devs - Execution #120

Transcript

thank you [Music] [Music] foreign

[Music] thank you [Music]

foreign [Music] foreign [Music] [Music]

[Music] foreign [Music] okay welcome everybody to all core devs

number 120. um we have a kind of a potpourri agenda today with a lot of random things um but first uh Miguel put together a spec for the consensus API for the merge um I'm not sure he only shared it yesterday so um I'm not sure if people have had time to actually review it um but maybe Mikhail if you want to take a few minutes to just kind of walk through it at a high level and if anyone has questions uh we can we can answer them here sure uh thanks Tim um yeah we have this new Doc uh first of all uh this is not like a proposal for a

standard for the consensus API that we are aiming uh at the end of this journey uh this is uh called the design space and it composed from the previous work on the Ryan during the ryanism project from various conversations and thoughts during the work on the EAP 3675 and so forth uh and uh um yeah there is um the plan actually the actual plan is to start iterating uh on the consensus API as standard uh from this document uh

to um and uh yeah this is this should be a good start for the discussion around it so um the plan is to have a call next week on Thursday it would be great to engage as much client developers from both sides of this communication stack as we can also um also be uh there might be something missed in this document um like I know that the there is a focus group in the get team who works on the state sync design after the merge it would be

great to get those guys too on this call and yep and I can like go briefly through this Dock and just say what it's about if it makes sense now we can take a couple minutes for that for sure do you want to share okay I can share it if you want uh yeah I can share it awesome yeah sorry right okay you see yep yes

okay cool so uh first of all there is the minimal set of methods that is required to operate to to uh to operate uh for the null node operation uh after the merge which is which most of you might already familiar with because they are borrowed from the is back uh and a bit of refinement is here and there is like something new but nothing too extreme um there is a lot the next section uh which is one thing I want to know which is like lots of space in this document is about the transition process and uh

yeah all these methods for transition process marked as the scope transition which means that those methods and parameters uh will be deprecated after the merge and this is the unfortunate part of this uh implementation because it could take a lot of efforts and then eventually be deprecated but it's pretty critical for the merge and we will likely have to um Implement all this stuff anyway it's available yeah there is the extended set of features um which is sync related scene to some

um exchange of the operating mode between the consensus and execution clients there is a notion of synchrony here and the concept of consistency checkpoints which is which is critical for the transition process in particular and also may be useful for recovery after software failures when like execution client for example crash and gets back and it has and there is the inconsistency between the block 3 on the consensus and execution client side

um yep yeah there is dimension about the cache and some thoughts on the sharing fine and yeah that's pretty much it I would like um yeah any input on that is very much appreciated and before the call and on the call um so also one thing I would I would like to mention uh until I haven't forgot forgot it yet yeah there is the idea from Proto to reuse uh the core set of methods for uh layer 2.

uh communication um of course the layer 1 is the priority but if we can reuse this something from this API for A2 it could reduce the implementation complexity and unification is always good and so forth so that's one of the interesting ideas Express here um and that's pretty much it about the dock and I've actually some of these methods map to the like kind of blacks boxing events in 3675 so we try to note that there and make it clear like where this thing maps to that EIP which kind of

black boxes the proof the stick and this is the more practical implementation of a lot of that right thanks a lot uh for sharing and yeah so the call would be next Thursday before the 82 Dev call right right um I will dig out our old invitation list that we used for the merge calls um standard invitations to everyone if you want an invitation you can DM uh uh me and also we will share the link as always and uh might create an issue in the PM repo

it would be nice if get her herders could host this call um just to and and then kind of called the recording to YouTube or or My myself can do this um I just wanted to mention that we've had a death meet up this week and we went over this pack quite a lot and uh yeah discussed internally how things would work and we are putting together a paper or like write about some points we wanted to bring up and yeah so we'll try to get that finished

for Thursday um now we can yeah show you guys and discuss those things as well sounds good very awesome and I think yeah that's great there's a lot to evaluate here but your input especially on what type of synchronization you need between these two layers especially during think and especially during recovery uh you know an event of failure one side would be really really valuable right and yeah regarding the format of the call it will just you know go through the dock and you know sorting out the little hanging fruits and putting some comments

uh if anybody has any comments pre-order the call just go straight to this Doc and comment out or or let's discuss in the Discord and the option is good cool yeah thanks a lot for for sharing uh Miguel and uh yeah thank you yeah so next week uh yeah we'll have a

call focused on this and if people have any comments in the meantime there's a merge channel on Discord we can use for that um cool um yeah second thing on the agenda uh so I spent uh part of the past two weeks talking with the different client teams about how London went how generally they want to approach the merge and just like the other stuff that they have on their roadmap for the next six months um I think this was kind of helpful in in Illuminating a couple of like the things we can do better um I've shared a document on the agenda but just like to quickly grow over it um you know I like and to be clear this is like kind of their rough majority opinion like

some people not everybody agreed with all of this but it's like you know the the kind of bulk of what people agreed on um I think the main thing that came up over and over is um the fact that it wasn't really clear uh what we wanted to see on the test nuts before we set a mainnet block um and this you know was kind of forced because of the difficulty bomb for London but going forward you know I think uh there was a desire to have some criteria whether you know how long we want to see the test Nets running smoothly um if we find a bug on the test net how you know how much longer after the fix we want to see the test Nets running smoothly um and they kind of set those things in advance because

um people felt that during uh the London work there was a lot of community pressure that actually um that actually uh ship things and that'll probably be true at the merge two so if we can say kind of in advance you know this is what we're going for then if something goes wrong we already have kind of a default path um and it's it's kind of a no-brainer to do that whereas a lot of people said that you know they didn't necessarily want to be the person who speaks up if something goes wrong and even if if they did speak up they knew that there would be like a lot of pushback um so I think yeah just there's a lot of value in probably setting earlier what are the the kind of uh yeah what's the amount of time we want to see things

running in with conditions and what do we do if something goes wrong um and I think the other thing that came up is just trying to have like a kind of a common set of things that we want for every test net Fork so uh I think we did this pretty well on the first on the first test net and then it kind of slowly uh tapered off but just you know having four command Having Eight stats um having transactions that are basically ready to send which test the various edge cases um and then finally just uh one thing that came up also was um the idea of automated alerts when there's issues on test Nets um so especifically on the Roxton one I think it took something like four or

five hours for somebody to pick it up uh or to notice that it was it was happening um and so a couple teams mentioned it would be nice to have just like a ping automatically if if something like that happened um so you know uh yeah we can kind of discuss async you know which of these make the most sense to do but that's kind of the general feeling I got um the other bits uh that that kind of came up is um you know the basically the the delay between having the consensus changes finalized and having kind of the entire ecosystem uh adapt to them um and for London specifically this was you know all around Json RPC

um there was some feedback that like you know we were still working on the Json RPC spec when the 1559 or when the London blocks were being set um and there was even a change made after main net so it would be nice to just um have it you know ideally wrap up all the non-consensus changes before we have uh a mainnet block and I think this will be especially true for the merge as well we want to make sure that you know the various infrastructure and tooling providers are are already supporting the merge um and then finally like trying to trying to have a single place where we can highlight uh the changes the apis and whatnot um so you know one suggestion is just using branches or diffs on stuff like

you know execution apis or consensus apis where we can just show you know this is everything that's introduced by by the merge um and then yeah finally the the you know I asked teams what they think is important for them to work in the next six months um you know what's like high on their priority list um and specifically you know how that could potentially interfere with a feature fork in December um and most teams uh you know basically every team had a lot of work to do Beyond just the merge itself um a lot of that work is kind of behind the scenes stuff which helps actually uh get ready for the merge so whether

that's improving performance or trying to like major modularize their code base to split out at the consensus sections a bit more um and so you know when I ask teams about how they felt about a future fork in December um everyone except one team would rather not have one uh two of them were strong knows one of the team was kind of a mix you know some people were four some people were against um and it just seemed like I don't know the general feeling I got was that for everybody being able to focus on the merge and being able to focus on um on you know whatever kind of work that they need to do on their client uh would be really valuable

um and you know that for December they would rather see just like a difficulty bomb pushback and um like on the last call we said maybe you know if we need to change a constant in 1559 or something like that but you know nothing that's like a significant amount of new work um yeah so that's you know kind of my general read uh on the conversations I have I don't know if anyone from any of the client teams wants to add Nuance or just comment on this yeah um I just wanna read so regarding the non-consensus changes and of course ideally all of that would be finished and we just roll out the perfect documentation and perfect RPC spec

um however it kind of requires the tooling providers to be active early on and I want to give some credit to infuro because Ryan was actually very active in the early testing and tried to make sure that the apis were consistent across the clients which was great work and thanks for that um but in general it's yeah that that's where the core developers we're lacking the kind of knowledge of both this required and what to break and how does this affect this or that tool um so yeah it would be ideal but it's not easy to get various stakeholders too that's a really good point um so I guess

you know two things there one is uh Trent has started organizing calls with the stakeholders and I think that's helped kind of get people in the room and it was the first time we did it for London and we'll obviously do it for the merge the second thing that was interesting is a couple teams mentioned that they can't actually do much until one of the kind of public test Nets is forked um so it's just not that easy in their product for whatever reason to support like an arbitrary devnet like uh like Calaveras or something they need you know Gordy or Robson to Fort so maybe you know for the merge um it's worth forking one of the test Nets much earlier on in the process um and and have that be something that

like application developers can uh can use and start iterating on um yeah yeah but yeah we'll definitely keep reaching out to them any other thoughts comments okay um and I guess just specifically for December um would anyone be kind of opposed if I put together just a a spec for the upgrade with a placeholder EIP for the

difficulty bomb and just so that you know people can know that it's there um you know I think there's been a lot of uncertainty and it'll be also easier to communicate with just you know champions of various Eeps that uh you know we just have this upgrade with uh with the difficulty bomb and like any other actual feature EIP would go into the next uh upgrade um obviously not the merge but like the one after that sounds good that was good is that is that true that we're targeting features for the upgrade immediately after the merge what we're gonna need to do at least you know some things

um yeah but there's kind of been uh there's there's been discussions that there's a clean up Fork after the marriage and so does that mean that you get a better name for that we should Cancun yeah it's maybe worth having the conversation probably not today but like I don't know on the next color one after like if we want to have like you know like where do we point EIP Champions to yeah basically right um yeah well you know I think one of the one of the big things my execution layer is ideally enabling

um withdrawals Movement we can ease from the beacon chain back into the execution layer um and that's going to look like an EIP and it's going to look like some modifications to the evm from this layer uh and we can certainly debate if and how and what also could be modified in the institution layer at the same point I don't know you know if we're going to get to the point where I say this is enough complexity let's not do it but you know from a separation of concerns uh it touches far less things on the execution layer then um you know swapping the entirety of the consensus so maybe there will be room for additionally IPS but I don't know yeah yeah I mean that makes sense I

don't want to like die on this hill but I I just think it's important to like think what's going to happen in these hard Forks after because we did say before London that Shanghai would be a feature fork and we would ship things and it was okay to push things out of London to go into Shanghai and now it's like easy to say that and then when it kind of comes around it's like okay well maybe we should just focus on the merge which like this is definitely a unique situation that's like an okay decision yeah yeah to be fair we have like five major r d projects for the sustainability of ethereum so like that could you that you could imagine that happening earlier before so maybe

there is some sort of compromise we need to start being able to make sure we're making yeah it feels like there needs to be a meta conversation at some point between Big R D projects that we want to do but also like reasonable evm changes and I'm not like just speaking about 3074 there's there's a lot of other EDM changes that people would like to do that are lower touch and it would be nice to at some point consider like how we can try and do more things at one time yeah I I definitely agree with that um and also it is kind of a unique situation where like with London EIP 1559 was a bigger EIP than basically

everything else the merge is like its own thing that's just completely different from everything else that we've done um and hopefully yeah hopefully you when we have things that are a bit more straightforward we do have bandwidth to add stuff uh yeah to add changes to the evm order that's 3074 or the evm object format or stuff like that um yeah it seems reasonable to do those at the same time I'm yeah and I guess yeah we can definitely have a kind of broader conversation about this in a couple weeks it feels like it's there's maybe you know it still seems

very abstractive in how early we are even with the merge um but we definitely want to plan this in advance and not you know wait until the merch is done to figure out what we're doing next sounds good um any other comments thoughts I see there's a few just forkname suggestions in the chat we can debate those after okay um so next up I I think access wanted to be on the call for this exact year I see

you're on the call can you like talk yeah okay awesome if you can hear me yes uh so this was there was this EIP a long time ago uh which I think was six months but feels like much longer about uh limiting the account nons uh I think there were two proposals one was two to the 64 minus one which is the natural Bound for 64-bit integers and the other one was two to the 52 which is the natural bound uh for JavaScript um and neither of those uh nonses will likely be reached um but um yeah it would be nice for clients to actually agree on like what the limit

should be and um yeah this way I think a lot of tooling providers and whatnot could could just make stronger assumptions about uh about account nonsense uh I know yeah like client is not a fair summary of the issue yeah I think so um and yeah actually can artem you both had some comments so I'll let the two of you speak up yeah I guess I can um I can start briefly um I mean mostly I wrote this down in the in the comments um but I think this goes back to more

like two years uh with the CIP in 1985 which um the goal of that was or is um to put an upper bound to many of many of the fields in the evm and some of those upper bounds then if you put it on the evm you also want to put it to the outside the transactions Etc and then once was just one of these which we so we initially tried to get like this 18 1985 with a bunch of changes um push it through the the process but that turned out to be too too hard so we just started to split it into one of small eips and the nonce one was the first one um and we chose 64

um because that is the the limit most clients already have so low ethereum has 64-bit as a limit um and Michael raised initially that um because JavaScript doesn't actually has 64-bit integers it only has 64-bit floating Point um therefore the the actual upper bound or integers is is is smaller than 64 bits and I guess the reasoning is that since transactions I mean the nonsense predominantly is used in the transactions and transactions are predominantly created in JavaScript um it would be nice to optimize for this use case

um which I guess um I have two reasons against it and one is we don't really optimize for JavaScript in other cases um and JavaScript actually can support 64-bit numbers either through um big big integer libraries or the upcoming native big integers support advisors um but also another argument is that there are many other fields apart from the notes which um which have like a kind of natural limit of 64 bits and I'm not even sure if this is only about it 1.0 or the execution layer um

but I'm not even sure how many other fields there are in the beacon chain which could um you know could be argued for for the the same reason um so yeah I guess in short just I'm just not sure that um what is the ones of piece looks reasonable you know to optimize for the JavaScript case but I'm not sure if there's anything else where we could optimize for the JavaScript case and and if we just have this you know one exception it doesn't look like a consistent system yeah we had this debate around so we only have you went 64 types generally outside of uh crypto on the beacon chain um and and smaller bid types and

and we had this debate a couple of years ago to see if it was made since actually restrict and we did not and uh so all of those the the maximum value even though most of those values are uh impractical to get up there um can be higher than that I think there actually are some arithmetic operations that do exceed that that type and loads are the JavaScript client and the JavaScript tooling has just taken that into account so that's at least from from that side we have not restricted and explicitly so when you mean not restricted sorry just

to be clear you mean not even 2 to the 60 like you've restricted it to 2 to the 64. not to restricted to 2 to the 52 right corre correct correct they're restricted to the the that type of those the temperatures and um there's even some math that expects it and the JavaScript client um manage it and I think I think if you go look at techu they end up having like a rapper um integer type because I believe there may be some restrictions in Java on math and natively supplied I'm I'm curious about the Practical effects if we today say Yes we agreed to

pound it to to 64. it does not mean that we update the white paper and that those implementations who do not yet use it as un64 can slash will do so because in practice they can already do it and since it's unrealisticated to go above 2364. um geometry is sure what we are [Music] I'm all for it though there it's just so we can make

um kind of more stronger assertions um just when you're when someone new is coming in to write a clients like this shouldn't this change shouldn't actually affect any existing clients it's more if someone knew is coming in to work on a client they can see oh this number will always be less than 264 they don't need to go understand um deeply you know nonsense and think about that okay can I succeed they can just put it in a 64-bit or a double or if we do as the other one whatever but it's just easier for new developers and ecosystem is all JavaScript and that's it every single language has uh 2 to the power of 64 integer JavaScript doesn't

have it then it's the problem of JavaScript not of everyone else so well I'm with you that JavaScript sucks and it's terrible um it is also like the most dominant language on the planet right now sadly well you want to import its words into ethereum protocol specification doesn't sit well with me yeah well anyway actually I mean the JavaScript information can choose to to use it to to power 52 because both of them neither of them will be hit in practice so that's fine sorry but I mean from a practical perspective is there is it actually possible to do anything in JavaScript

without having using 64-bit integers with ethereum like is there a use case where you literally can do everything else with 52-bit integers and this it's only this month where you would need to introduce 64-bit into this because if that this is not the case then this discussion is a mood well there's an ergonomic Advantage so when you're do so to preface this this conversation started before JavaScript got big in um so my my arguments are much weaker now but just to summarize summarize them from an ergonomous perspective it is way prior to Big ends it was way easier to just work with uh Native numbers than it is to work with like these rap numbers um because JavaScript doesn't have

operator overloading and so like just things get ugly fast in your code and so just from a coder like a when you're right sitting down writing code ergonomically it's much simpler um right I I understand there are five other cases for in the same code that will already have to use begins anyway so you're now optimizing for that single case the nuns um the danger is to make code as lazy who to think like oh I can use a normal fruit floating point for nuns so they might start using it for the other types as well where it doesn't work and and then they get issues because of that

yeah that's fair like that's that's a A5 for argument I think um yeah like I think in my head it's just neither of these numbers are going to be hit let's pick the smaller one because it makes it things like it covers more like I generally like to be restrictive on my assertions and so if I know that I can assert this is going to never exceed a double um like or an integer packed into a double then that seems like a better assertion than asserting that this will never this may overflow that again my argument's much weird I'm just simply saying if like all three years later other things that you handling at the same time I have the same problem then I think the the dangers you're introducing by this chains are bigger than than what

you're avoiding um access your hand's been up for a while did you still have a comment um yeah just um what Martin asked you know what what's going to happen next um I mean the yellow paper always has been just following these changes it wasn't the one making them so if if the CIP is is I guess finalized then then whoever is is active on the yellow paper can can adjust it then um I think that that's going to happen um another comment regarding what could could be done is I think we could actually add a consensus test if we

wanted um which has just like um an arbitrary high non-set in in the state but maybe that um that could cause other issues down the line so I'm not I'm not 100 sure that is a good idea um and the last comment regarding the the 52-bits um I mean if you just if you're a new client implementer and you see that these fields are 64-bit if you just set it to 64-bit you already have a natural band and you don't need to add any extra code to check whether you reached another random limit or not and since it seems at least on this call that even if it would go to like 52 bits goiting

wouldn't have that extra clause in the code so whoever is just looking at go ethereum as an inspiration to implement a client they they wouldn't add the check and if somehow that case would somehow be reached then um then there would be a consensus bug so it just seems to be causing more problems than than benefits it provides yeah so it seems like there's definitely some fairly strong opinions against two to the 52 Mika seems weekly in favor um so I I don't know it feels like we should probably go which is two to the 64 and call it a day because this has

been kind of open for six months um yeah Michael will you I agree with that no I won't die on this hill like like I said this debate started back before JavaScript had the big negative type and now they do and so my arguments are way weaker than they used to be okay of course so let's go with 2 3 to 64. um yeah uh and I think yeah like clients were you the author on the actual eips um no uh Alex is the author okay oh okay perfect so yeah Alex uh I guess you can update the status I guess to like accept it or

yeah all right so final uh just quick follow-up on a quick follow-up on that there's um as Alex mentioned there's a whole bunch of these similar things nonce was kind of the canary that we're using to test this process out um do teams want us to continue to bring this up to all core devs or should we just like when the number is a number that is cannot reached should we just update the yellow paper and just us make an assertion on our own like those of us that care I think it makes sense for this to make its way and as a test vector and so maybe the next step is to enumerate a big list of them and go through them rather than like one one at a time

yeah and I think that we could have conversations on the actual test PR and we probably you know once we reach some consensus it just makes sense to announce it on all core devs but I agree we should debate those things on the call yes an indication of some of these other limits you can have a look at um 1985 1985 um so yeah I mean that only focuses on the event currently that the other fields which outside of the event which can also be restricted cool um anything else on this

okay um and I think uh Daniel was next he wanted to discuss EIP 1352 um I don't actually have a ton of context there that also do you want to just give a bit of background sure so 1352 is an even older it's a three-year-old eat kind of in line of what we were just talking about but the subject area is the restricted address range for pre-compiles and system contracts and a couple years ago when this was discussed it got tabled because it's like there was Zero impact it was a lot of work for zero impact um with Berlin that changed uh the pre-compiled contracts are considered already warmed when they come in so uh during the devnets uh both Basu

and nethermine still had the all BLS pre-compiles in their list of acceptable compiles at some point even though they weren't executable so they were going up to um I believe was 19 pre-compiles and when the actual number should have been nine so there were some consensus failures on that um the reason I think this is important to nail down sooner rather than later it has to do with the broader evm ecosystem and specifically um layer two type evm systems um what these other chains have been doing and I think it's a pattern we're going to continue seeing is they Define their own pre-compiles for system level access in case a great example is arbitrum if you need to initiate an eth transfer from the layer 2 back to layer 1 you have to call into the arpsis

contract that they put at ox100 and if there's no clear you know so the question in that case it's a pre-compile um when they go to Berlin do they charge uh warm gas or cold gas for that access so if we set if we pass this EIP and make it a standard and we just say that uh anything below um below 65 000 you know four F's is the address it's considered a pre-compiled for the purposes of these warmed accounts it's going to solve a lot of problems and give a lot of these layer twos in the broader EDM ecosystem a safe space to put their pre-compiles in without worries about breaking consensus rules when they bring in some of the the future hard Forks that are brought in for security

so it wasn't as relevant three years ago but I think it's very relevant now in the next feature Fork I think I would like to see this go in that's that's my general pitch for it uh Martin your hand is up yeah um I disagree because I think this Eep it says that these areas are and to me that sounds like if someone makes a transaction which will create a contract in one of these uh addresses it shall be rejected and some kind of failure that's the only technical consequence in my opinion and I don't think

because you you imply that any call made towards the 65 000 addresses should be uh cheaper to make because they're already considered hot and I think that would well for one be an erroneous interpretation of the eat but more importantly I think it would be a denial of service Vector because then you have 65 000 addresses that you can use to make very cheap lookups on the state try with which is not an insignificant number um so yeah I am in agreement with this e

but I don't interpret the same things that you do if I if I were to do that then I would say that this is no good I hope I make I hope I made sense okay these are the conversations worth having because I haven't thought of it in that perspective that you could still um you know we would need to prohibit those from ever holding value and put special handling in it for that um actually we wouldn't approve them from holding value because you can't stand but it's a big part that's fine I'm sorry could you repeat that again I mean you you can't it is fully possible to send value to a pre-composite that is

fine um and I think we already have initialized these services with well at least some of them with a way yeah yeah zero to 255 automated someone went through and did that so I think the point was to avoid the the dos and Vector you just Define their value to be zero so you don't never have to look it up it's just there if uh so that you you cannot well of course yeah we could delete the way that is sitting on them the problem would be that then it would not exist in the

state try and we would have this empty delete thing problem and that's that is why we did Empower them with one way so that they would exist and say try should we ever decide to make them uh pre-compile the latest stage so why can't you say the value is just always zero so you don't have to look up the state try like no value sent to a pre-compile has any meaning it's burnt so whether you store it or not doesn't matter yeah but then you're bringing in that could be a semantic change to how the try works and how we we could do it

but I think it will be more trouble than it's worse because there are lots of corner cases which arise during the same time upgrade if I'm not misremembering where this ripe and the we will clean up where we cleaned up the empties and one of the pre-compiles what was it it didn't exist but something like that things are easier if there is value on them and they exist in the trial it was the right MD and there's a set of test cases that cover that it was kind of a night you were remembering yeah it wasn't a bit of a screw up but we're done with it and I don't want to relive all of that again um

and it's it's kind of a mess so so it seems like I don't know Daniel you came into this thinking it was kind of a quick fix and it's it's slightly more complicated so it probably makes sense and and given you know the work it would require it would have to go like a future Fork um it probably makes sense to discuss this more async um but yeah I just like I mean I I guess I actually wrote this originally and me and Donna had two different interpretations of of how to read this Eep so I'm wondering exit like what is the original who is closest to the intent

because I read it as a pure reservation I think the intent changed over time and initially probably was much closer to to Dennis um interpretation but after we have the the access lists and a bunch of other discussions I think it's more like the way it's it's written at least in the current form it's more like a reservation as opposed to as opposed to doing much else [Music] um and I do agree that we need to definitely um examine

the I guess the cases were I mean another question we have discussed is like the creation um there there has to be like a clear specification what happens in case of a unrealistic collision and um what happens to the accounts which already exist at these addresses and and lastly whether these should be um covered under the the warm case of the access list and if they do then we definitely need to do something you mentioned and that these shouldn't result in entry lookups um and lastly the range was also debated because it started out as only 256.

um addresses and I think Nick Johnson asked to be extended to 64k um so yeah I guess in short this definitely is interesting to discuss but it it probably is really very early to making a decision on this call yeah I wasn't planning to get a decision on this call I wanted to get the discussion going and it sounds like there's enough to discuss is this something we should move to The ethereum Magicians thread it's it's about two years uh dry on it or should we start a new thread for it I think it's a good news good spread too goodbye hope what was that again to where people were

talking I would just revive the I wouldn't create a new you know forum for it um but there could be like a coal or something is anyone opposed to just um narrowing the EIP a little bit or make adding Clarity at least and so we don't quit making claims about warming and we just agree on a reservation only in the CIP and then a future EIP can talk about warming so warming is where it has the mechanical impact on change that may consider their system contracts pre-compiles or not um I mean within mainnet itself it you're right it really doesn't matter

but I'm hoping to get some more clarity as to how the other change should treat it you know for the broader evm ecosystem so I think I don't think it's we can just simply go to that path I think we should continue the discussion in the Forum and figure out where we need it from because I see there's discussion from Charles from the eea there's discussion um and you know it's this all sorts of other chains like um arbitrary and optimism have been putting on their own so I think it's you know we need some some forethought about this because people are are making decisions based on areas impacted by this before we can get a chance to figure out what the real impacts are so I think some some forward discussion is probably needed in this area

okay so would you say that this EIP is in your opinion not worth championing unless we can make some assertions about uh warm versus cold is that accurate no um but I do think that the EIP would need to be updated be clarified to reflect current reality as written today it's not doesn't really have much of an impact so I think it needs to be updated and I think this is the correct venue and vehicle to talk about it um I think there's value even if we don't do warm and cold maybe we explicitly say that you know non-mainet chains don't get a warm-up they're pre-compiles that might be worth putting in there for clarity and consistency so cool so yeah I guess we can continue

this on the existing it magicians thread um and yeah thanks Daniel for bringing this up and with the Nuance around Layer Two specifically um cool so next up I guess there were just two semi announcements just by guests that I wanted to make sure we we covered so there was the 865 deprecation and then eip3607 which got merged um yeah I don't know if uh Marius or or Martin you just want to give a quick overview of of those two changes and what people should expect foreign is 65 and we did uh I think a couple of

hours ago we put it back since we are doing a hotfix release on Tuesday and if we were to suddenly make the entire guess uh population dropped 65 and then another minor PC notes could no longer have anyone to speak to so yeah we reverted the drop back to the uh we made the emerged release we're gonna drop it again [Music] um and yeah as has been announced uh what was it three years ago a long time ago

it's been in the on the roadmap uh regarding the other check yes we are now have added this and check that it's under uh must be an eoa that means it must not have any code I think it was dank rod and a few others who brought up this and we discussed on all protocols and yeah I don't really have much else to say yeah the 65-bit was very helpful though to know that uh this will not be in the hotfix release of the release coming on Tuesday right yes okay

um and Lucas you have your hand up yes so uh just a quick update on those two things never mind uh we uh we have the implementation it's 66 in a branch we are testing it it looks fine but I think we still have one a hive test failing and investigating that so we expect to be it's 63 866 ready very soon maybe next week uh regarding 3607 we also have some initial implementation that we also might release uh next week or the week after that

cool thanks for sharing um does anyone on base you have like a similar update yeah we have a uh an 866 PR that's up right now and uh we'll be fast tracking that in light of uh uh the 65 being dropped uh we haven't looked to my knowledge at uh 3607 yet but we will it's on our list to do now got it and uh Marius you have your hand up yeah regarding uh 3607 um we noticed that

um oh email it yourself Marius you're on YouTube you're still here [Music] okay I guess we could come back Demaryius when yeah he might be on the train uh what I think he was going to say is that we noticed that there's this corner case you asunder might not actually exist because there's a zero gas price and it

doesn't really exist and therefore doesn't have the empty codash but just has old zeros [Music] so yeah that should be taken into account when doing this check okay is there somewhere is there like a test or something people can look is it reference in the EIP um it's we discussed on the EIP discussion okay it's added in the the r if you use our pull requests and some basis oh cool thanks and also yeah he is going to make a test

for this I don't think he has made it yet cool I expect I I would I would only add to that that um if you implement it in the basic way without taking twin into account ethical then you're going to break uh for example the gnosis uh the Legacy gnosis wallets so yeah you should really do not require the the check in in Esco cool and Lucas um so uh thank question

about seven are you implementing it like um um normal EAP switch from a block number are you just assuming it would be from block number zero and one may have come oh okay from book number zero and one's more comment we need a little bit more analysis on that and that's why um we are a little bit slower there because um some side chains like xdi work a little bit different here and not sure if how we should do that there but that's our problem cool thanks for sharing um okay and I guess yeah that's all we had

in terms of content for the agenda there were just a couple announcements um as well so first uh we we briefly touched on this but get has a hot fix coming out with a security to address the security issue on Tuesday so please if you're running get keep an eye on this um second Elita has been working on the Json RPC spec uh and I think there's a couple things where uh they needed clients to review uh certain PR's uh Alita do you want to just give a bit of context on that yeah for sure actually Jared has been doing um the bulk of the the writing here so

I'll let him um him to talk first to see if there's anything I don't know oh yeah so can you hear me yes awesome so uh I have uh just a few more drafts to finish up but I should have them all done by today and then I guess we're just looking for a review on wording and if the described behavior is actually uh the actual behavior and um yeah right now I have them as individual PR's but I'd have to make like another 15 plus more so I was wondering if anybody wanted me to just put them all in one file and share that somewhere else to get a better review

but other than that I don't have too much else so to kind of give a bit of a background as well like currently um we have a few markdown like description files that contain like the edge cases yeah I think someone just linked um the issue with like the pull request that Jared was just um referencing but we need reviews from clients and before we can um like basically complete the work um so ideally you know we would potentially get like um volunteers or representatives for each client to then go and be responsive on those issues and pull requests uh so

that way we can you know try to make this Cricket Suite and do you need all the clients are just a subset I suspect they all share the same behavior so like a subset would work yeah they do not share the same behavior that is the entire problem okay okay so a part of it is also like like the clients are comfortable with I you know like I'm not you know if Michael wants to approve and then we can merge and that's like that's fine but um I feel like the clients might want to be involved in finding the edge cases because of well what Micah just said but yeah so currently it's we're trying to

require um at least one approval for all clients Thomas you have your hand up yeah sure so um that's great work from Malita and Jarrett is a result of a um set of meetings between various client teams and uh also tool providers that were discussing of how the current Json RPC spec should look there was a lot of effort put into preparation a lot of effort to put into writing it down and now we need a few things so every single client not subset of them and every single client should review that

so we ideally would find one person that knows how exactly the behavior of Jason RPC is in each square and my comments on my conditions and we should detect all of those cases where we disagree on so much cases they keep causing a lot of trouble to people who implement the um the Integrations and they kept raising these concerns that they have like the if else uh code blocks for all the clients and also very often the Integrations are done for one client and later simply the teams don't want to move from the client to client um the other thing is I think it's a great time also for a community to step in look at those edge cases because very

often we have those integrators or users of Json RPC that are aware of the painful edge cases differences between clients and they can highlight them now so um I guess would be great to maybe tweet this at least somewhere soon and see what kind of feedback we can get that would help uh so yeah it's important to finish this project which would many many people are waiting for and many people worked on and uh it's been always invited because there's so much work on actually writing it down you know it and Jared did it so I think I think it's great that this has been worked on however I think if if he if it gets put down into text

uh we're losing a dimension and that Dimension would be if it was instead implemented as actual reference test for the Json RPC um and that and that would be maybe easier to integrate into the like Ci and life cycle of the clients and put on hive and you know actually show hey your your node is violating test number blah um I'm just I mean I think it's good that it's been worked on but I'm a bit afraid that this will wind up [Music] yeah forgotten [Music]

the plan right now was to do both to have both the description and the unit tests um address your concern Ed um also marking to address this case if um the exact look of it at the end so um we need to say feedback now at this stage and the formats I think addresses your concerns because it was discussed also by uh many gifting members attending those meetings when we're discussing how it should look so we'll have two or three formats that all

together like related to one source which will be openrpc based technical spec for model that can be used and also from it generated a single source of Truth for uh for Json or PC spec they can be verified and tests will come on top of it and that's what the letter and Jared are starting to work on all right as far as the test um just give a bit of a background on that by the way uh so every Edge case you see and kind of like the reason why it's taking so long is because every Edge case that you see on the pull request has like reference data that we've collected um so you know a response or request and

a response and um so like it's gonna be pretty trivial then to turn those into tests um for unit tests or whatever um so yeah getting some reviews now will help us kind of make sure that we have um all of the data we need to write the test properly cool well yeah thanks a lot for sharing Elita and Jared and yeah hopefully we can get folks to to look at this uh in the coming weeks um and yeah I'll make sure to link this uh list on Twitter as well and so hopefully some wallets and other infrastructure providers can

um Can can chime in as well um yeah we had two more just quick announcements so one is over the past week or so we've started renaming a lot of the GitHub repos and Discord channels uh from Ethan to execution and E2 to consensus uh with the merge coming we've wanted to start adopting kind of the execution and consensus layer terminology rather than Ethan versus E2 because the two will be the same at the merge um so if you're just like stumbling on GitHub or Discord and looking for Ethan or or two channels um uh they've likely been renamed I linked the document in the agenda that

kind of goes through the entire rename and and what is what now um yeah so just a quick shout out to that and lastly um the ddub team I hope I'm pronouncing this right ddub team uh has spent uh some time in the past month or so doing an analysis uh on the impact that uh charging for charging gas for code chunks using vertical tries would have so if we use this as part of the stateless ethereum roadmap um they've put out a long report kind of addressing the you know the impact that we'd see on current smart contracts and we've organized the call uh next Friday uh so next Friday one hour later than

the start of awkward Dev so 15 UTC for them to just share their report and for people to discuss it um so there's a link again to that in the agenda we'll post a zoom Link in Discord and if you want to calendar invite you can ping me um yeah that's all we had anyone else have any final topic they want to bring up okay well yeah thanks a lot everybody I appreciate your time thank you have a nice workout thank you thank you everyone thank you all right thanks a lot to everyone bye bye

goodbye [Music] foreign [Music] [Music] foreign [Music]

foreign [Music] foreign [Music] [Music]

[Applause] [Music] foreign [Music] foreign

[Music] [Music] [Music] thank you

foreign [Music] [Music] [Music] [Music]

[Music] foreign [Music] [Music] foreign [Music] [Music]

[Music] foreign [Music] foreign

[Music] [Music] [Applause] [Music] [Music] foreign

[Music] foreign [Music]

[Music] foreign

[Music] [Music] [Music] [Music] thank you