All Core Devs - Execution #177

Transcript

[Music] for J

oh [Applause] oh okay

Tim Beiko: sorry I was muted on the stream

this should be fixed but uh just went over what was on the agenda okay so to start uh Denon the Gordy Shadow Fork Perry or Barnabas D if you want to give an update

Parithosh Jayanthi: yeah I can go um so we had the girly Shadow walk this week um the networks consisting roughly of 300 nodes um split across New York Frankfurt Bangalore and Sydney um we're running 100 validators per node and then we initially synced the curly Network and then fed it into our own shadow for uh started with capella and thenon was at eoch 220 we we didn't notice any issues

with the shadow for itself um all almost all the clients uh joined the shadow for we weren't able to sync Aragon in time unfortunately but we're going to shift to a snapshot approach next time so that doesn't happen um but all the other clients joined the shadow for successfully and they all fued into can uh tenun without any issue uh we were observing roughly 999 to 100% performance um at a station as well as plock production um and then we started um blob spamming so there's a link to the um more detailed analysis that I've uh put put up today

Danny Ryan: there was Zero blob transactions before that point

Parithosh Jayanthi: exactly

so for roughly a period of one hour it was just Cancun and nothing else um and then you can see the massive spike in the overall Network use graph and that's exactly when the blob spamming began um so we you're seeing no use roughly 700 kbps so that's bytes per second um in the Cancun SL capella Paradigm and once blob spamming starts properly you're seeing it at roughly the 900 kbps Paradigm so with we can assume that there's a roughly 200 kvps increase with healthy blob usage um one caveat I will note is that the Network's extremely flat um there are 300 nodes and most of

them have between 70 and 100 peers which means you're going to be peered with someone from almost every region so it's as perfect networking as you can possibly imagine there's no clustering or anything that's happening but also not particularly sure how to simulate the clustering or what would be useful there um and then we went on to the blob analysis itself so we have a few blob spamming tools that we use so we have marius's TX F that's blobs and we have pk9 t0 G blob spammer um we were targeting at roughly the four blop range and if you look at the distribution I

think we've successfully hit like three with six being the least and zero being the least as well so I'd assume this is pretty much a scenario we'd also see on Main net because the target is three so most of the time we would likely see three BLS U per block um the next one is the average blob propagation time um most of the time across 95% of the node so this includes the ones in Australia you they are receiving all the blobs in under two seconds if we don't include the P95 value and just take the average it's under 500 milliseconds and we have a couple more graphs as to how the effect of more blobs effect um what effect that has on

network latency with respect to blog propagation as well as block propagation the caveat is that for Block propagation the CL the way different CS emit their events is varied so some might emit the first time they see a block without verifying it others might emit it after they've verified all the blobs so just keep that in mind when you're looking at that graph at least um yeah and in terms of block latency uh we see an increase of roughly 300 milliseconds so the presence of lobs um increases the latency by about 300 milliseconds attestations don't seem to

be affected they still happen at roughly the 4 second Mark so we're able to achieve everything we need to by every node is able to have all the data it needs by the 4 second Mark um within the last roughly two days we haven't seen any reog on this network but I did post an alternate message on interrup yesterday as to periodic spikes we see and the periodic spikes seem to be correlating with EPO transitions so I think it's a known fact that Epoch transitions are heavier so we do see that the block or the slot at the epoch transition would take longer to propagate as opposed to the rest

Danny Ryan: on the overall bandwidth

consumption increase that we're seeing you said 700 to 900 if I remember correctly

Parithosh Jayanthi: um yes

Danny Ryan: do you have any insight if that is from the consensus layer or the execution layer obviously you know we're the propagating blobs on the the goset but we're also sending on the theayer we're also sending in the men pool I presume you're not sending these just through like Builder networks these are hitting the the public H

the

Parithosh Jayanthi: exactly they're hitting the public M Pool um so we're not we're not able to get the metric per um CL and El so what we've what we we've done is instead Target the public interface so this is just the come each node has one El and one cl and this is

all the traffic that has come out and gone in from that public interface um there are some um client specific metrics that we can track but the issues that they're not necessarily standardized so you might mean different things based on which client you talk to

Danny Ryan: one way to get transparency on the ratio there would be to to spam blobs but only through assuming you know we had nearly 100% Builder Network or something uh only send them to builders uh through this and then you'd see only the increase from the consens layer because you wouldn't have any blobs in the H so that's true that might be interesting

obviously that's that's work but uh could be

Parithosh Jayanthi: yeah we can give that a shot um I'd propose we try that on Deet 12 though because the other point we wanted to make is that we'd like to turn off that uh girly Shadow for today evening so if there some last minute test we can do it but that's about it and I've added the blob bar um a couple of hours ago so it adds some latency of 1.5 seconds to random blobs and currently I don't see any effect of that so I guess the analogus um yeah the analogy on mainnet is if you have a random dispersion of I don't know

10 nodes out of 300 that are really slow and propagating things there's no network wide perceived impact

Danny Ryan: they're not The Originators of the message though

Parithosh Jayanthi: uh in some cases they are in sometimes they are uh round dropping which node we submit the blubs to yeah I think that's all we had from the curly Shadow for um there was one thing that the r team wanted to look into with rate limiting CU we noticed these massive spikes um once in a while but I

think they already have a PR ready for it

so

Tim Beiko: yeah thank you this is a really valuable analysis any other questions comments

Parithosh Jayanthi: one last point I wanted to make was um we've listed a link to every graph that I've referenced um the analysis is based on all the clients together but there's a filter on top so you can filter just for your El or CL that you care about and look at per client Behavior

um I think there's just too many clients to do individual analysis but it would be awesome if you guys can have a look the metrics are persisted for the next couple of months so there's no there's no need to do it before the network is torn down just adjust your time frame accordingly

Danny Ryan: this is awesome guys thanks

Tim Beiko: any other questions comments on this okay if not um yeah I guess the next thing I was uh hoping to discuss

was what uh to do in terms of next steps um a couple people reached out oh sorry okay before we do that uh anyone oppos to tearing down the Gordy Shadow Fork uh by the end of today please voice your objection now

Gajinder Singh: yeah we want to look into Theo transition thing and so basically we are debugging it and we might need some time that

okay so at least load star

Barnabas Busa: would you not be able to do that on 12 though

Gajinder Singh: on what so you are seeing the same behavior

on Deet 12 as well

Parithosh Jayanthi: I would be quite sure that it's ail it's present on Deet 12 as well

Gajinder Singh: okay we'll basically look over there as well and see if we find we can replicate it there then yeah we can get rid of the goalie Shad of fork

Tim Beiko: okay any other team who wants to look at something on the shadow Fork okay so let's uh coordinate offline but uh at least check with load star before

we we shut it down

um okay so yeah next up uh basically discussing next steps from here um so I know in the couple calls ago we talked about potentially foring Gordy uh assuming the shadow for went well and that client teams uh were were ready to do that um I think I'm pretty sure we had prism uh run through the shadow fork and and live on devet 12 now um so I'm curious to hear from teams like is anyone uncomfortable with moving to Gordy as a next step and if no one's uncomfortable um when would people want to see that fork

happen so yeah maybe first question anyone not ready to move to gordi sometime in January okay promising um and so if we were to uh for Gordan just

Danny Ryan: do we have consensus layer teams represented I'm on mobile so I'm kind of scanning through right now

Tim Beiko: um let me see at the very least there's someone from Prism here

Danny Ryan: that's what I was worried about

James He: oh I'm here

Tim Beiko: oh oh cool okay so I I'll James just you know to

make sure like from the prism side does like January for Gordy feel reasonable

James He: um based on what our team talked about I I think so uh there's a couple of issues that we're still trying um uh work out but it it looks promising

Tim Beiko: got it um so so yeah so if I mean if we want to Fork this in January I think we probably want to have the client releases out um something like 10 days before the

Fork actually happens um So based on that uh you know with teams basically with teams if teams are are ready to like put out a release as soon as uh they come back from the holidays then we could Target something like mid January and then if teams feel like they might need a couple weeks coming back from the holidays to like polish things up and and and put uh put out a release for Gordy then maybe it makes more sense to Target end of January um and the question is you one do people have a preference there and two is it helpful to agree on like an Epoch or at least a tenative Epoch today so that uh

when teams are starting to put out release they can they can use that number I guess if there's no objections or push back um I would personally go first oh uh okay so okay there's uh January 8 release around prism I was going to say I would personally go for either the 17th or the 25 which are two uh dates where um we get like a midweek accumulator boundary slot

um does anyone have have a strong preference between the 17th and versus 25 okay lots of people like 11 and 17 some people like 1725 so yeah I think 17 is a decent compromise so I from the the row I had uh in the in the the table on agenda this would be the epoch number so it would be Epoch number uh 23168 on the network start slot is 741 3760 um which happens at 6 a.m. UTC 6:32

a.m. UTC on the 17th and then there's other local time zones uh on that but yeah let's do that um obviously if we find a major issue or something crazy before then we can always cancel but um this would mean that ideally we're putting out the blog post for the fork sometime during the week of the seventh uh or sorry the week of the eth um so that people have you know at the at least a week to update uh so if client teams can Target to have a release you know at the latest on the 8th or the 9th of January then we'll put up the blog post with all of those and

yeah that should give people time to update before um before the fork happens any comments questions thoughts

Marius van der Wijden: yeah what what's the time stamp

um I don't know

Tim Beiko: I don't know if Adrian added it to his website uh so oh he does uh let me just check this real quick Gordy the slot uh I'll post the time St I'll

verify it um offline but I think this is the time stamp what I just posted in the chat um yeah there's a comment by Anar around you know talking about a best case yeah timeline between different test Nets um I think historically like yeah two weeks is the closest we've done um just it's like the pace at which client teams can put out a release and have the test net Fork um depending on how confident we are we one thing we can also do is bundle have a single client release for something like seia and hosi if we

assume that uh you know if gordi goes really well and uh uh we assume host key is going to be trivial to Fork once uh seoa Forks we can um yeah we can just have a client release and a single announcement telling people to update their notes once and that might save us a week or something um aside from that assuming we actually have like a client release per test net it's hard to do less than two weeks per test net um and then between the last test net and Main net we might want a bit more time for people to upgrade their notes um yeah okay so yeah let's aim for yeah

releases around the e or n9th uh we'll have the fork on the 17th and then from there um yeah from there we can also figure out steps next steps for the other test Nets and if we want to bundle those releases anything else on I guess Denon as a whole before we move on to other things

Barnabas Busa: shouldn't we try to tentatively uh assign like plus two weeks from girlyy to the next test net and then in case something was wrong then uh possibly modify it instead of just waiting for gly to happen and then discuss uh when we could for next one because then we going to be losing

another two weeks at least uh in just discussing potential future Fork times

Tim Beiko: I'm not against it I don't know yeah how client teams feel about that uh I I would want to look at the numbers not on the fly right now on the call but like if people want to agree to rough dates now we can definitely propose tentative um we can definitely propose tentative like slots and and then maybe what we could do as well if uh actually yeah what we can do is propose tenative slots that go in like a two week uh motion if if people are okay

with that and then um reconfirm them on like the call two weeks from now so that yeah like teams won't have their releases out yet and then if they want to already include that in the in a release it still gives them a couple days but yeah I guess would anyone be otive 31st

Danny Ryan: and then 14th and continually reconfirm after each of those

fors

Tim Beiko: and I guess my question for between 31st and 14th is assum assuming we do suppo first and hsky do we feel like we need two weeks between those two um given you

know if gorle and seol have gone well hosi should be trivial so I could

I could see the the value1 and 7th

Tim Beiko: yeah 31st and 7th I definitely would not want to bake in a mainnet date yet like I want to sort of roll through that and at least get gordian sepolia uh like smoothly upgraded but yeah does anyone think that like 31st and 7th is too aggressive or we should do something different okay let's do that then so I'll look at

some uh EPO and Slot numbers uh right after this call but uh let's do Gordy on the uh 17th of January client teams have a release on the 8th or 9th that we can announce then we'll do sepolia around the 31st of January and uh H ski around February 7th again assuming nothing goes wrong if at any point we see something we can always change those dates um but yeah teams can start planning around that and and the implication as well being that we'd only have a single client release for the um seola and hosy forks so um yeah we'd want both of those coded in in uh

network uh and yeah Barn you have the question did we agree to do sioa before hosi I guess sepolia feels higher risk than Holi so if we are combining the reduces it makes sense to do it before but I don't know if anyone has a counterargument to that right

Danny Ryan: Define higher risk

Tim Beiko: so there there's just like stuff on it right there's like a bigger State there's more people using it um whereas hosi is basically completely new um although hoski has like a larger validator set I guess um so

Barnabas Busa: it would be earlier to catch some Network related bugs on hosy thania so that's why I

would I would personally prefer to for Hy before

seoa

Justin Florentine: I think higher risk is also more informative too right there's more people using this sepolia we might want to consider learning from it earlier

Tim Beiko: but yeah I guess it is a good point if there are more validators on Hos key and the main thing we're concerned around is like networking and blood propagation I I think it's fine to do hsky first if if people want to drisk that

Danny Ryan: yeah I could make pretty compelling arguments either way

Tim Beiko: um I wrong I guess does anyone again aside from Barnabas have a strong preference

on ordering uh the argument for siolo first is just there's more usage there's a bigger state but there are less validator nodes um yeah

Danny Ryan: so usage is also important for actual users testing things yeah so like if that gives l2s an extra week uh to test where they're actually currently testing their environments then that's a good argument for me

Tim Beiko: yeah I don't know if any

L2 people are on the call I don't think so but oh Carl yeah um yeah

Carl Beekhuizen: I think that would be helpful most of the testing's been done in private so far and I think it also just act as a signal that hey this is really happening in the short term and might help have more robust deploy ments ready sooner around main net launch cuz I think that might not necessarily be the case for some of the l2s right now so just better in my opinion

Tim Beiko: okay so I guess that would bias me towards sepolia first I don't know how much is on sepolia already but I've definitely heard l2s wanting to move stuff to spolia um if they haven't already so yeah giving them an extra

week to do that seems reasonable yeah okay so I think I I'd push towards sticking with theolo first Barnabas are you okay with that

Barnabas Busa: yeah sure

Tim Beiko: okay so we have the schedule then um Gordy so

just

Danny Ryan: just to State it out loud like the we picked the oldest test net because if it BS who cares we picked the second oldest testnet because that will help users more than the newest test net in terms of timing and then the newest test net I just say it out loud it doesn't have to be a general rule but

like that is reasonable logic and maybe we will reuse it

Tim Beiko: yeah and I guess the argument to have done hsky first is if we cared less about uh user Behavior like onchain behavior and wanted to optimize more for validator Behavior because there's just more validators on

host on host key

Barnabas Busa: it's not just really about the validators but it's the number of nodes on the network right and the polio only has like 100 nodes or something like that and POI has a significantly more so BL

Parithosh Jayanthi: I think Holi is kind of like in the order of magnitude of the Shadow for

we just did at least based on some crawling it's like 5 600 so it's not that

and what do you think suo is 100 like 200 at Max

Danny Ryan: we could beef it up if we felt like it right before obviously that doesn't beef up the validator nodes but you'd still get uh deeper like block paths I don't know I probably wouldn't advocate for that but it is a possibility

and

Tim Beiko: I mean both of these are also like in order of magnitude under main net right so it's not like defitely

it's not it's not like is like yeah 75% of main net and zolia is like 10% they're both

Parithosh Jayanthi: yeah yeah I think the most we're going to learn is from girly because the valid dat set is small enough there are a lot of esoteric setups and so on um hsky just has a very large valid dator set size which means by default most people are just running really beefy machines with a lot of valid data keys on one host

Danny Ryan: got it

Tim Beiko: okay yeah so I think let's stick with the Gordy SEO hosi ordering if we see something going wrong on Gordy we can always readjust that and you know if we think that the next test being Yan Holi

is better um we can just swap them around but for now assuming things go well let's just follow that order I'll come up with some slot numbers um I'll come up with some slot numbers uh after the call but yeah and then yeah clients should have the first release for Gordy and then the second release after Gordy for the two other test notes that makes sense everyone cool um anything else on

thenon

okay if not uh next up uh Anar you wanted to talk about uh pre-compile address ranges and um yeah how this uh how L2 pre compiles may affect this

Ansgar Dietrichs: yeah I mean Carl has hand up

Tim Beiko: I'm not sure I think Carl's hand is just St up from the last comment

Carl Beekhuizen: okay okay so um yeah so so so basically um but fun enough that's also K me so just recap we have recently started this iip um process rollup Improvement proposal process to standardize evm and evm related changes across Layer Two Chains

um of course purely opt-in so it's not a governance call or anything it's it's really just a standardization Forum um and now as we're starting to get the first kind of um proposals through this process um we we're starting to just um kind of run into several kind of questions and and and one of those specifically referred to pre-compiled so you might have already I think I think we already discussed on alod as well the the potential future R1 um curve precompile 66 p256 R1 um and that now has an IP number and is scheduled to go live on several rollups basically as soon as possible they all just waiting for for it to to be finalized in this process um and so the the last remaining

question we have is now um for pre-compile like that that starts out as initially a layer two targeting evm change should that basically take the next sequential pre-compile number that we have open on Main net or should that go into a separate range um and so the the one kind of nuance that that makes this not not a trivial question because I think initially a lot of people had the intuition that kind of a separate range for L toos might be better but the problem of course is that a lot of evm changes that will start on layer twos first will at some point later and potentially come to mainnet especially in the future we would expect that most dips actually start on layer 2s because they just ship things faster and then later on potentially come down and so if of course we wouldn't want to have them

be on a separate address on mainnet from layer 2 so then that would mean that if we give layer 2's their own pre-compile um um ranges that would mean that now on on ler one we would at some point also start shipping from that new Range which which is a bit weird so so alternatively of course we could just keep one continuous uh range um and then that would mean that at some point in the future on Main net once we once we ship future pre- compiles we might start to have gaps where where there's just no pre-compiled for a few addresses because they are only on layer twos and and then some that we shipped on layer one so that that's kind of the trade-off here um and given that again like a few L really want to ship this this R1 um um

um pre-compiled soon basically the The Hope was that we could kind of just make a at least like a like a decision maybe maybe oneof decision ideally of course the most atic decision here how we how we want to treat this um yeah and the one ones maybe because um hog also asked uh on the on the call Scheduling um uh get up issue um there there will be some sort of registry as well like a meta RP with with a list of all the pre- compiles um and the different layer tools that they shipped to um we haven't created that yet but we are in the process of also setting that up and then the question is if we decide to have one continuous range on layer one and layer twos and is that enough to basically just have this kind of list of of of of

pre-compiled in the IP repo or would would C then also prefer to have some sort of meta EIP in the EAP reper as well that kind of clearly lists which pre-compile addresses are basically blocked so so yeah those are basically two questions that I would have for people

Tim Beiko: thank you uh Danny

Danny Ryan: given we don't know like how much I I'm Pro adding a range for l2s um and if there is significant adoption of an EIP before L1 adopts it to use disjoint sequencing and use what was selected from that range for L1

because it's very unclear at this point what's going to happen with rips in terms of like you know is there to be one EIP for the R1 curve yes probably but you could imagine maybe there's two because there's splintering in terms of like what one L2 wants to do ination to another L2 um you know then we also have to think of what is that EIP being adopted on l2s what is an L2 you know what makes it in that range there's all sorts of these like questions which could make that space quite utilized could make that space quite fragmented um obviously I know that's the goal is to avoid a lot of those things uh but as we don't know how that's going to happen I would be I

don't think it makes much sense to like give it the main net allocation range at this time um and to instead like pick from it if we want to use it obviously like having disjoint ranges is also kind of annoying so I understand the argument the other way but I I think this gives us just better better optionality as we kind of watch the L2 the rip process full unfold

Marius van der Wijden: I think we will be having disjoint ranges anyway um because like the no matter how we do it in the end there will be eips that are or rips that are finalized that will not make it to

mainnet and so there there will be unassigned um um precompile uh uh uh pre-compiled addresses um I would also like I would also prefer the rip process to have their own disjointed range like it doesn't really need to be disjointed but we could say something like okay from like I don't know like address address 256 upwards is the L2 range and the address um zero or one upward is the uh until 2 256 is the is the normal range

Danny Ryan: and Mario if if for example they selected one from the range on the above 256 and then say it was the R1 curve and then L1 was going to ship that same exact functionality would we then utilize their number is that what you're suggesting

Marius van der Wijden: um that's the other question um I'm not like I'm not 100% sold on on just using what what they propose um I don't I I think there needs to be a debate uh about that and it kind of feels like um uh an SK is just like proposing this as it's given that we adopt the same address um but I don't think so

what's

the rationale for not what yeah well that

Marius van der Wijden: that's what I'm saying like there's there's a there's a debate to be had around this and um I of course like it would be preferable for users for for for smart contract deaths um to have the same address um um but

Danny Ryan: it's really a matter of how this manifests in compilers and things most of the time right

Tim Beiko: right yeah and I guess my question is like what is there an advantage to having the same functionality at two different addresses it feels like it might only just create additional risks or confusion so I'm I'm

trying to understand what's the what's the argument for having like the r R1 curve at address a on an L2 but address B on an L1

Danny Ryan: encumbering L1 to L2 for example if the R1 if if all the l2s we're like oh actually we're going to modify the deployed EIP and functionality at have that address then then they might modify extend Etc and now there's now L1 is using something different than L2 you know these things can move independently uh so I would that that's my main argument

Carl Beekhuizen: okay so to be clear on that in rip process we'll enforce that if you do

want to do that once we agree that something is finalized you need to deploy a new RP and you'll have to use a different address because that's horrendous ux on the L2 side as well

that's uh I don't know

Danny Ryan: that's kind of debatable in my opinion as to well you know when you're adding new functionality whether you you know if it's an extension of functionality or just a minor breaking change of functionality then you do change things you know like self-destruct we changed for good reason um and so things that are calling a previous uh place still get they get a different functionality so like that's certainly a precedent for changing functionality uh at a at an address

space

Carl Beekhuizen: I mean I think if that's if if if that's a concern then we should deploy uh RPS as eips um to the same address as a as as as the rip um and then like the main thing just follows the whatever said in the EIP but I don't know it it just seems silly to like potentially lose out on all these synergies just because uh there's a potential for change in the future like we're just default into a worst case scenario unnecessarily

Danny Ryan: yeah I I disagree just because the practicalities of how I've

seen things upgrade in the past uh but obviously like it's optimal from a certain perspective not to change things once they've been deployed

Ahmad Bitar: um yeah one one concern about this is that if if the addresses are not the same uh then there will be like different versions of compilers and like um compiler developers will have to deal with like different versions of the compiler for each network

Tim Beiko: but they would have to do that anyways because on L1 even with a separate address range

on L1 that address is nothing and on L2 it might be a precompile right so they're going to need an they're going to need ideally two versions but not n versions so

I don't yeah I don't yeah

Danny Ryan: there is certainly like Network specific like metadata depending on compile Target as well

yeah um ongar

Tim Beiko: I don't know if you're ra your hand again

yeah yeah

Ansgar Dietrichs: yeah I just wanted to briefly say um because I I was just Al didn't want to make it sound like by the way that that that I assumed that was a given of course that was just kind of um an opinion I wasn't aware that that that there might be kind of

opinions against against ever kind of deploying um um two PR comp at the same address um I think it's fine we can we can discuss this and if this is something that basically we don't feel comfortable at least committing to yet which it sounds like we're not then I think that would mean that we also already have an answer for my other question around the pre compar ranges because then we should definitely not use the same range right because if we of course use the same range then we're kind of committed to shipping at the same address um so then I would say kind of as a takeway from today we should just give L2 pre compiles their own separate range um maybe question are people generally okay with 256 that seems like a very sane default um and basically ZX whatever 256 and and and

upwards um I mean of course not ZX whatever the heck that is um and um and then we can basically discuss this once we move closer to actually shipping one of those pre- compiles to layer one which I could imagine might be the R1 pre-compile relatively soon but um then we don't have to make that decision today

Tim Beiko: yeah that seems reasonable where we can always choose to take 0 x256 if we want to go that route or 0x10 if we prefer um yeah does anyone disagree with the 0x 256 range if not yeah and I guess we should

probably put this in like some informational EIP or rip or at least somewhere um other than the transcript of this call yeah the Highlight that we reserve um 0x I guess we would Reserve 256 onward for l2s like maybe we want to bound that range at least for now to some I don't know if it's like 100 or a

thousand pre compiles

Marius van der Wijden: um we already have a bound and that is zero like basically we have 0 to 1024 is the bound of the

pre-compiled okay

Tim Beiko: okay

Danny Ryan: so we're saying that then we just flip the upper bit and call it half

the range rather than starting at 256

do we

Tim Beiko: I feel like we'll probably have more than a one to one ratio though

Marius van der Wijden: so you're proposing 512 right

Danny Ryan: yeah yeah it just it's essentially like the the the bit flip signals which one you're on that would be that feels natur to me if you if there's compelling arguments about like the ratio of the amount that we'll see

Tim Beiko: yeah I feel like 3 to one

feels more reasonable like if you look in the history of ethereum we've shipped 10 promiles in like seven years uh some of the eips you know have a bunch of pre- compiles they want to add but feels unlikely we hit 256 but I can see

L2 yeah

Danny Ryan: yeah I mean yeah there's a lot more degrees of freedom one who's doing Innovation and what so it's a compelling argument

Guillaume Ballet: uh could it be possible to have a range that's actually starting from zero x f like all the way at the end of the space and having a decreasing so that you can extend it as much as you want uh it will never Clash

Marius van der Wijden: well you cannot extend it as much

as you want

Danny Ryan: but you don't have to decide where they're going to meet

yes you can yeah you don't

Guillaume Ballet: yeah exactly you don't have to worry where the wrench starts because you know where it starts it starts at the well not FFF all the way because it's been reserved for other chains but FFF e for example and just have it decrease and decrease and decrease

Tim Beiko: are there some like weird gas cost arguments to that I don't think so but the fact that it's zero that

that

Marius van der Wijden: definitely are yeah so I think yeah if you're loading

Tim Beiko: sorry go ahead

Marius van der Wijden: yeah if you call into a a pre-compile that is or like if you if you're loading the address of

pre-compile you can just add a two push two instead of push 32

Tim Beiko: so how about we do 512 pus one how about we do 512 and then if we ever exceed the 512 on the l2s we can give the sort of second 256 range back to the l2s which will be kind of ugly but something we can deal with five years from now does anyone disagree with that

Carl Beekhuizen: I mean we could also just we could also just add another 1024 on top of it if we

ever needed to and give that to El as well right which give us that 3 to1 ratio whatever it doesn't matter

Tim Beiko: yeah but I think yeah 512 probably gives us room for like several years and we can revisit this or other people can revisit this in 5 10 years and think we made a really bad decision

Danny Ryan: or we can revisit ourselves and think we made a bad decision

Tim Beiko: yeah okay so let's do that and then uh yeah I think an informational EIP probably makes sense because we want L1

to be aware of this and then we can have RPS that like reference the range or something um I think if it's just an uh rip if it's just an rip then someone just looking at like L1 stuff might not know that we have reserved this range so yeah I would add an e for this

Carl Beekhuizen: okay we can get

Tim Beiko: sorry go ahead

Carl Beekhuizen: no I just want to say just to point it out though because we have had the similar conversation in the past that people would are generally uncomfortable actually having layer to specific information in an EAP so the would literally just say that the basically the upper half of that range is blocked for mainnet and then to actually see which of these addresses

correspond to which layer two pre compiles you wouldd have to go to the to the iip repo it sound like a good

Tim Beiko: yep yeah exactly but knowing that on L1 we shouldn't deploy anything in that range I think is yeah is what we wanted in the

yeah sweet anything else on this okay um okay next up uh real quick uh we discussed this a bit last week on ACDC but um in in uh in the next couple weeks uh with regards the award devs we

said we're going to skip a formal award devs next week potentially have a testing call at 14 UTC on Thursday if people want to show up and and organize something the week after that January 4th given uh we're going to want client relases shortly after it feels like we should have an awkward FS call but I just want to check does anyone feel strongly that we should not okay so we'll keep the call I will be out but a light client will be running the call uh so he'll see you all there in two weeks and then last thing on the agenda

um we have this thread for the prag and Electra EIP proposals um I went over it a couple days ago to to compile sort of everything that's been proposed so far there's been two more proposals uh in the last day so uh 7547 and 7212 um but aside from that we have a a decent list already there I was curious to hear if anyone has um thoughts about the overall set of proposals anything they'd want to bring up now to discuss or bring to people's attention I

think at the very least people should be reviewing this over the next couple weeks and as we move towards the test nets for denune we should start you know triaging to all of this sort of individually but yeah any initial thoughts comments questions from any of teams

Guillaume Ballet: um yeah just to question are we still targeting a very short Fork a very small fork for Prague

Tim Beiko: I don't think we've agreed to anything yet um so yeah

uh

Anar

Ansgar Dietrichs: yeah I basically had a comment on that I just wanted to say because we are also actively working on EIP one or several eips regarding adjustments to the kind of um staking um uh reward mechanism um I think related to similar how in dun we ship basically this the throttling of the of the um cues just to make sure that we kind of never um go out of bounds in terms of how many how many vales we have on ethereum um and so while those are not quite finalized yet I think in general it would be nice from from that point of view if we did have enough of A fine grain foring schedule that we don't have to worst case wait

for 9 plus months um on to change once that becomes urgent with potential kind of developments in the the total amount of Stak eth and whatnot um so in principle there would be a preference towards having more of like a smallish for that we can still Ship by the end of by the end of next year at least um instead of one that like really bundles everything that might be delayed until I don't know mid 2025 and then we basically are not very reactive in case we need to make small adjustments

Danny Ryan: one additional thing to note is a number of the consensus layer proposals are not and do not have to be cross layer uh so there is an ability to make an independent decision here on a

lot of those eips um if the execution layer is going to be digging deep into a big feature

right

Tim Beiko: and I think on the El side the Big Fork is basically do we choose to do veral now and then prioritize it and you know we might include other eips alongside veral but effectively you know we' only ship the fork when veral is ready and just generally any large feature has taken us over a year to ship whether it's uh the

merge obviously whether it's uh it's 444 that we're working on now um so I think if we do go down the road veral at least on the El side it's we shouldn't assume it's going to go live in like less than a year right um and I mean you know we can hope and like work hard and whatnot for that but like if there's something that actually urgently needs to go live before that um bundling would would veral scenes uh unlikely to to have it go live in like less than a year

Danny Ryan: and yeah on my read is there is demand to get some of these things out on the consensus layer in 2024 um and so we can just keep that in mind as

we're making the decision on that side

and G

Tim Beiko: uh yeah

Guillaume Ballet: just to be clear nothing should go at the same time as rco it's such a complex thing that there's too much risk I mean if it's activating yeah even if it's activating some pre- compiles I I would prefer seeing a like smallish Fork that takes three months to release I know it's never been done but uh if it's just for a PR compile it might be doable um I would rather have that than anything happening at the same time as Roo because yeah once again the the complexity is is Bonkers

Tim Beiko: I guess yeah on that you're really selling it yeah on that then uh I

think yeah I think again with like the three- Monon thing it's it's hard to like realistically commit to that and I think the reason is there's never just one pre-compile we want to ship like if we want to have a fork um there's a bunch of stuff that's going to want to be included um and there's like high fixed cost to shipping your fork so we should probably bundle a bunch of things together by the time we're bundling you know three to five eips it's basically you know more like a six to n month thing so I think it's fine to do that but we should not tell ourselves like oh we're going to like choose the things and like fork in April after we've chosen in January because it's only one

thing that said I think what we did do this time around is we um we sort of pre-committed 4844 to the fork after while we were working on uh on the withdrawals Fork so if we wanted to ship a bunch of smaller things on the El side um whether coupled or not with the CL and then you know slowly start work working on veral in parallel and um sort of pre-commit the next Fork to that that is something we can do as well and um this way we can get all the smaller things out earlier um but also sort of Reserve uh yeah reserve the next fork for for veral in advance and and

potentially have parts of the teams working on it in parallel and I guess maybe like this is probably the main thing that would be good to like agree on in the first couple weeks of next year regardless of like what the small eips are I think you know on this thread everybody can get a feel for like the the type of stuff that's being proposed but you know are all client teams like do client teams want to do at least on the El side something before veral or not um and then if we agree to that you know early in January we can

then figure out okay what are the things we want to do before verol and this will give us uh this will give us a good idea of like um yeah how long this Fork is going to take um and and maybe on veral specifically uh like gam was just saying it's a pretty huge change I know there's been the veral implementers calls and and there's the website now and and Josh has been doing the summaries on Twitter but do people feel like it it would be valuable to maybe dedicate part of like the ACD e call to go deep in veral and have people sort of understand exactly um where things are at and and

potentially ask some questions um yeah would it be worth having a call like that like early next here so that we can zoom in to the details

Marius van der Wijden: good idea okay

Tim Beiko: so um yeah let's maybe do that I I don't want to like schedule an exact date we can we can maybe play it a bit by ear but I think if teams want to start looking at uh everything around veral uh start looking at all the other smaller eips and and get a feeling for you know do we want to do those eips before veral and if so do we do we have

preference on which on which ones um we can discuss that uh in January and then find a time uh even if it's not like a full alord devs maybe have like half of an aord devs focused on just going deep into veral so that we we sort of know what we're getting into or at least what the the current state of things is any other questions comments okay um anything else anyone wanted to discuss before we wrap up okay if not uh we can leave it at

that thanks everyone um yeah let's uh get Gordy out for denune and hope everybody has happy holidays

you see you next year y'all thanks Christmas bye bye happy holidays are

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