All Core Devs - Execution #208

Transcript

Tim Beiko: to get to it. But let's see if we can sort out the high level discussion around the Eo 1st and then next call. We can also go into a bunch of small sweet. Yeah. Joshua, move us over

Josh Davis: You were live.

Tim Beiko: Okay, welcome everyone to Acde number 208. We have a lot on the agenda today. We'll talk about Petra, how the fork, went on Hoodie. Some process upgrades with regards to how we deploy hard forks, and then we'll see if we're comfortable talking about main net timing. Then what I expect will take most of the call Fusaka. So we have some updates on pure Das. and then lots to discuss about Eof. Hopefully, we could come to a final resolution about eof shape and size and inclusion today. And then there was also some other minor Fussaka eips that client teams brought up. and if we have time there are a few portal network and history expiry topics to also cover at the end of the call.

but to get us started. Perry, do you want to give an update on how the Hoodie Fork activation went

Parithosh Jayanthi: Yeah. So the Hoodie Petra fork happened yesterday, almost roughly at this time, and immediately after there was a relatively stable participation rate. We finalized without any unexpected problems. There were 2 issues that were noted relatively minor and non-critical ones. One seems to be related to Kaplan, Aragon validators, and the second one was higher than expected. Resource use on lighthouse. During the transition which has since been fine. The lighthouse team also found another issue for which they had a bug fix released last night in the form of the Beta 5 release we haven't yet finished all of our validator state testing purely because the queue is relatively large, as it's an open, valid data set. So that might still take a few more days for us to have

all the results on consolidations, manually trigger withdrawals and so on. But so far everything looks to be going as expected. yeah, I think that's most of what we have to report. At this moment more coming up

Tim Beiko: Thank you. And then the other big part of Petra testing on Hoodie was application and infrastructure. Lido posted an Update in the chat. Seems like the fork has gone smoothly on their end. I don't know if there's anyone from the team. Yeah, I see Yvonne is here. Do you want to get a quick update from Lido side?

Ivan Metrikin: Yeah, absolutely. So we have successfully passed the hard work with 14 node operators, and all 4 staking modules worked well in simple DVD, we had both Mobile and Ssv clusters running, and also the community staking module as well. All our oracles worked well, we got all the reports this morning. We also got the report for the community staking module. It went smoothly. and we have confirmed that all the compatibility upgrades that we included in our side of the Petra artwork are also functioning well and and correctly. The only note here is that we haven't tested the actual new functionality in Petra. Like triggerable exits, consolidations, and features related to Max, effective balance that will come later. But so far the upgrade is looking good, and besides those small issues with Aragon and lighthouse that affected some of the node operators, we we are pretty happy with the upgrade and big Big shout out to all the

client teams, I think you've done a fantastic job here

Tim Beiko: Thank you. And then I also saw in the agenda comments either 5 said they plan on starting to test, but it's dependent on Eigenlayer and I I believe Eigenlayer was dependent on gnosis safe deploying their contracts on Hoodie. I don't know if a match from again this on the call today. Okay, maybe not. Okay. And then Perry says, I know this life is live on Hoodie now. So nice. That's that's good news. It seems like, yeah, it was blocked. It was kind of this chain of blocking where? yeah, a lot of contracts depend on on safe. And then, Eigenlayer also has a lot of like restaking protocols on top of it. so generally seems like things are going well on the application layer layer testing

like we discussed last time. We probably want to wait at least a few more weeks to give people plenty of time to test, and I think related to this. In general figuring out how we want to approach maintenance deployment. This is quite important. And Frederick, from the Ef security team has put together a doc to to discuss this. Yeah, Frederick, do you wanna share your your doc?

Fredrik Svantes: Yeah, yeah, sure. I can share my screen quickly. I am not going to go through all of this, considering that. we don't have that much time. I can also, maybe you can share the the link if you have it.

Tim Beiko: Yeah, I put it in the chat already

Fredrik Svantes: Okay? Good, yeah. So so basically, what this document is is a an attempt to try and formalize the upgrade process that takes place during hard works. Most of this is, are things that is already being done today, and it's merely a way of formalizing it and ensuring that, you know we do the same each time, and we don't miss a particular step. The the main difference, I would say, is something that's part of the end here. which is some incident response plan. Where, ahead of the hard work, we assign roles to some people. And these people then have various responsibilities to ensure that things are getting done. For example, that verification of the hard work is taking place. It can be that communication is going out. If there's an incident

that we have the right people working to solve that incident as quickly as possible, and it also adds a few other things like, you know. instead of just waiting for finalization and calling that a success there should be some verification of the eips, for example, to ensure that they were. They're actually working on the test nuts and on main nuts before success is is called. There is. There are some templates that can be used for the upgrades. Basically. the idea would be that, you know, for the let's say we're upgrading Poleski again. then we would fill this out. So we have a record of that. We would have some

information about where people can find updates and where they can communicate. The status updates, for example, might just be a hack. Md. Page, where, you know, updates are posted, or maybe at some point some kind of fancy fancy plates. We also have some verification what should be verified after the upgrade has gone through, and then perhaps the most like one of the. I guess contentious or controversial points to discuss would be the timelines that are listed in this document. basically. What it says right now is that there should at least be 14 days apart between each test. Net test. Nuts should not be scheduled at the same time. but it says, should, so they can. There is some reasoning why that should not be the case.

and it also states that there is this kind of wait, or I guess, review period between clients being having their releases out and the 1st testnet being upgraded. which in this document is 30 days. And the reasoning here is that during these 30 days we can run bug bounty competitions, we can have the bug bounty program active. We can have the security, the Political security team review the the clients as they are ready. As well as external auditors. If we need to. But this, of course, adds a bit of extra time between clients being ready. the upgrades being live on Mainnet, so

I don't know if that's something we should discuss in this call team, or if the people should leave comments on the Pr. Perhaps. But

Tim Beiko: Yeah. So I think for sure, the specifics around like test net deployments and whatnot will require bike chitting. And we can save ourselves this from the call. People should comment about this on the Pr. Or you know, if we merge this, and people want to change it, they can open another. Pr. I think the most important part with regards to Petra is one. The idea of like assigning people from different teams to be on call when the upgrade happens. And having that set in advance, so that we kind of know who to ping, and that the people who will be pinged, or maybe Pinged know to be on alert. and I think there the idea would be that like, you know, team set somebody, if for whatever reason that person cannot make it, there's like a backup. Or if you know, we thought this was, gonna take 2 h and it ends up taking 3 days. The team can obviously rotate who is on, but to always have kind of a source of truth. Of okay, this is the person who's owning things, for you know Prism, or Nimbus, or Aragon, or whatever

and having said that in advance, and I I also think the other big part is, yeah, before we kind of close things off and say, that picture is live having a set of things we want to actually test for the upgrade and see happen beyond just finality feels like it would be important. so does anyone disagree with like those 2 parts that a we should schedule. You know, specific people from different teams. And then B, that we should try to identify like, what are the things we want to see before we complete the upgrade

Fredrik Svantes: And also, maybe, if there are some voices that feel very strongly that we should not have this type of process

Tim Beiko: Process at all. Yeah.

Fredrik Svantes: Yeah, but I I have talked with the all the client teams, and they have provided a lot of super valuable information. So Yeah, I hope there won't be any big major. Yeah, sure.

Tim Beiko: Nico

Nicolas Consigny: Yeah, just a question, should this be a meta IP, or should this remain like a process

Tim Beiko: No, I would put it in the Pm. Repo, because we want to keep changing it, for you know, forever. And Meta Ips are hard to do that way. yeah.

Nicolas Consigny: Okay, makes sense.

Tim Beiko: Yeah. And then Lukash has a comment saying like, Don't you already do this? This is just writing this down. And yes, and I think every like, you know, to take Lucas as an example. If he is the person on call for never mind, it's helpful for other people to know that he is the person on call for another mind. Even if that was already the case. yeah, because clearly this kind of happened with the issue where it wasn't clear like who should take the lead and and like who should pay? Who. So I think, after the extent we can make this clearer. it's valuable. So okay, it seems like there's a lot of support for it. We should probably merge this in the next couple of days. Again, we can debate the specifics around like the test that delays and whatnot, either on this Pr or in a follow up pr, but I think, using the minimal version of it and trying this for Petron may not

seems reasonable. The other process change with regards to deploying hard forks was this idea of eth config as a Json, Ipc Api. So To give some context on this part of the reason why we had these bugs on Sepulia and Holeski is that they have different configurations than Mainnet does with regards to the deposit contract. And so the idea here is that we could have a Json Rpc. Endpoints that nodes can use to to check that. They actually have the same parameterization for the upgrade. Dana was the author on this, Dana, do you want to give quick context

Danno Ferrin: Sure. So I've drafted up any IP for the 79 1 0. It's basically a Rpc that returns from the current operation. What the configuration is, and I wanna get get this in team members in find teams minds right now. I don't expect moving on this for a few months. But just to make sure that we have everything that we need to work with. A couple of high level design things is I'm not. I don't just want people to report the text of their configuration file, because that may not be what got reflected into their system. So this proof of concept I built from base soup, pulls it entirely from the Runtime configuration, and I try to put in this configuration object things that we know have caused deviations or or consensus failures

from the configuration. Broken code can't report on that. But if we forgot to set the system contract, if we have the wrong set of precompiled which has broken some tests and activations contract id getting wrong. No one's gotten the blob schedule wrong yet, but that's the sort of thing that would break if that's a configuration item, or if they activate at the same time. So this would just be a Json. Rpc, that you would say, give me your east config, and then we return what your current configuration is, and this is off of a old booty from Bay su. Pre. 4. And this is what we're currently running and a little quick comparison hash. This is what we plan on running next.

if next is set. And if next is not set next to next hash or null. So this gives us an idea before the fork. If we're configured properly, and teams can look at this Ipi and compare things. Now, if everyone's got everything exactly the same through canonicalization rules, the hash is going to be identical so that can be a quick check, and if that's different, then they can go to what made up that hash and do a diff and see where things differ. So that's basically the high level overview of how this is meant to work. So what I would like from teams is to go to the discussion link and give me feedback what they think should be added, what they think should be removed. If they think the design should be different.

Feedback is what I'm looking for right now. I don't think it's ready to commit to final review. I think we need other client teams to get feedback

Tim Beiko: Okay, yeah, before we debate press versus Jason, rpc, I guess, yeah. does anyone feel like we should push to have a version of this for Petra, so like teams implementing it in the next week or so? Or are we fine delaying this for Glamsterdam?

Felix Lange: I feel like it's not something that requires like any kind of fork. Scheduling

Tim Beiko: Right? Yeah, yeah. Sorry. I meant for second. Sorry about that. But more like, you know, given we had config issues with Petra on testnets? Will we feel more confident if we have this before Petra on Mainnet? Or are we fine quadruple, checking the configs? Without this? For

Felix Lange: So my my sorry to just speak. But I guess anyone else can also, from my point of view, this thing is interesting, but at the same time I do feel like some more work is needed on this to really bring it to the. to the finish, and especially since, like the config model that it assumes is not something that actually, for example, in get, it doesn't exist like this. We don't actually have like a current. And next configuration. We just have, like a list of blocks and timestamps when the fork is supposed to activate. So we actually have to write some new code to generate this response. And then I guess, yeah, well, I mean, that code will be really well tested. But is that going to mean that everything is correct. I don't know like it's

it's just something where, like I, personally, would have been much happier just seeing kind of an endpoint that reports the current sort of like list of 4 block numbers and timestamps, because I feel that is something that is kind of missing. And I mean, yeah, the the parameters as well like they they are. They are important, and the ones that we got wrong. The on the testnet obviously should be included. But no, I mean

Danno Ferrin: This is the feedback I'm looking for in the discussion, but we didn't fail on getting the fork number wrong we got. We failed on getting the config wrong. That's why I focused on more than that, we have the fork number in the dev. P. 2 p. Stuff with the fork. Id. So we have that already in process and working well. I think

Felix Lange: Yeah, well, okay, so we will have more discussions about this. I do think it's a cool proposal. So yeah, I mean, I just wanted to say that, like for us. Specifically, it doesn't seem like the most useful thing, but we would still implement it. Of course, like it's no big deal

Danno Ferrin: It's early enough that I'm very open to counter proposals. Discussion topic could be the best place for that

Tim Beiko: Yeah. And from the chat that seems like there's moderate support at least to have it over. Fusaka. But yeah, not something we'll need for protection. So we can continue discussing it. And then obviously manually review the configs on the clients for for Petra. And yeah, anything else on this topic. Okay. Thanks, Daniel. Next up main net timing. So Hoodie has forked. It's gone relatively. Well, it seems like testing is underway, for you know, staking services and and other applications. Do we want to set a fork date today? Do we want to wait another week or 2 to do this. And then Andrew has proposed a set of dates given, we said, like we wanted at least 30 days before, between the who deactivation and and the main net fork the 1st proposed date is April 30.th and then he's proposed some pretty much on a rolling basis after that, that that we could use.

Yeah, do people have a strong preference around trying to set it today or waiting another week or 2. okay, we have a okay. We have some preference towards setting a date the 1st is April 30.th Which I think is also the slot Barnabas. I put out there. Does anyone think April 30th would be too soon? And the expectation there is, I think, if we want to have the fork on April 30.th It would be nice to have the blog post out with all the releases, at least like a a good 2 weeks before that. So April 30th is is a Wednesday. So this means that client releases should be out somewhere between like April 10 and April 14.

Does that give people sufficient time to put out a magnet? Release

Ivan Metrikin: Yeah, I'll just jump in quickly from lighter side. We are. Gonna be ready. We think it's pretty reasonable. We're finishing all the tests, and I think this date will work. However, I just want to flag that I've noticed in the discussion. Thread on on Github. Pm. that etherfi are not yet started, and they depend on Eigenlayer that was also depending on on save and some other things, and they commented that they might need time until the end of May. I'm not sure if someone from Etherfi is on the call. I just wanted to highlight that it might be a a challenge

Tim Beiko: Great thanks is, is anyone from either on the call? Okay, there isn't. So. I guess if we just stick to client teams, is there any client team for whom? for whom? Like having your release out mid April would be problematic. if not, what I think we could maybe do is set a tentative date today. Verify with verify with etherfi and other applications over the next week, and then confirm this on the Cl call. But yeah, is there any team that today feels like getting your release out by April April like 14

would be problematic for them, and that they would want to push back even beyond that. Okay, then, if if people feel generally okay with that, what I would do is I'll open a Pr on the Pm. Repo with this with this slot that which is slot 1, 1, 5, 9, 9, 8, 7, 2 I'll and then client team should also assign like we just said, assign different people to to like, actually watch the fork. So my hope is that by next awkward devs next Thursday we we have this filled out. We've heard from any applications that have, like a major issue with that date. And we can make a final call. But I think we can at least get the ball rolling on, tentatively, scheduling a date figuring out who from each team is gonna be it's it's gonna be like assigned to to monitor the fork. And then, yeah, follow up with applications

that seem reasonable. Any objections? Okay, let's do that. Great. So yeah. So again, that would be on April 30.th Epoch 3, 6, 2, 4, 9, 6. okay, moving on to Fusaka. So our deadline for people to propose eips was this week. There's there's been many, many proposed eips. There were 2 that I couldn't merge for some random bot reasons, so I posted them in the agenda and then our deadline for teams to share their perspectives about the fork was next week. So hopefully, if we sort out eof right after this, teams can take some time in the next week or so to share their preferences, and then we can finalize the scope for the fork by April 10.th So by all court of 2 weeks from now. Which is what we originally were aiming for.

So please. Yeah, please review the list of pfi vips if you haven't already. And now, yeah, main thing in Fusaka is pure. Das, I believe Sunnyside Labs has an update on the work they've been doing on the pure Das devnets

Minhyuk Kim: Yeah, Hello, everyone. My name is Minya from site labs. And we are currently working on helping peer to ship faster by running quick iterations of devnets with higher block counts like 72. So we're currently mostly working with the consensus client teams in identifying potential bottlenecks. But as Perez pack expands into the execution layer. I think there will be more to test in the El site as well. So I've left the links to the reports of the test we did in the past few weeks in the execution dev discord. So I'd really appreciate it if the El Teams could take a look at it, and see if there are any other tests or analysis that we could do on the El side as well.

So, like few things already came up, such as like. We were testing with the large number of blobs like 50 blobs per block, with Petra and tierdas, and we saw some limitations in the Tx Pool size. So I mean, we could manually increase the default expo size of the clients to maintain a good hit rate in the gap blobs. But maybe if we aim to scale this to the higher blob count in Saka, we might want to consider like different approaches to the blob polls. So like. This is one of the many discussions to come. But I just wanted to highlight here and ask for some feedback and comments in the relation to high blob performances across the frontier, and what we could do to help things ship faster.

Thank you.

Tim Beiko: Thank you. Yeah. Any questions concerns. If not, then I think the main thing we should probably touch on a bit is the sell proof competition? But okay, Francesco has a actual question, yet has a very large transaction. Full size. You think the size is a problem or the prioritization logic

Minhyuk Kim: We didn't see the problem with get, or we saw the issue in other clients. But I think it could be the size problem, since, like, we are increasing, the block counts by the factors of 10. So yeah.

Felix Lange: So maybe a quick comment from my side on this, since Geth has a disk based transaction pool for the blobs, it's like we. There isn't really a limit to it. At the same time, it does require some like SSD space. So this is just something to keep in mind is that we are not bounded by the are the amount of main memory for our blob pool, which is why we are able to run it with much higher limits than the other client, and also it is not a shared limit with other transactions, since it is a dedicated pool for blob transactions only

Minhyuk Kim: Oops!

Marcin Sobczak: Yeah, for for another mind. We are saving block transactions to this as well, and we are limiting it. But number of transactions. So by default, it's 16,000 of block transactions. So actually, our, this space will be growing when and there will be more blobs in transactions. So if we will not limit Max number of blobs per transactions, we will just need to decrease a bit. Our maximum amount of transactions in block pool but generally it's we are sending it to disk so it should. There, there will be no memory problem at all.

Tim Beiko: Okay. Any other questions on this. if not the other part of the El peered aspect that we should discuss is this cell proof? Computation. I don't know who's the right person to give an update on this Alex.

Alex Stokes: Yeah, hey? So I linked to Prs here, I think most people know the topic. There's a migration of the salt proofs, which is a slightly new type of proof in paradox that we have. There's been the idea to move this to the El from the Cl. We think it will help with performance. And yeah, I think there is a lot of good progress on the pure dos breakout this week. I was not able to make it if someone's here and wants to give an update that would be useful. But either way I'd like to merge these 2 as quickly as possible, so do we feel like we're in a place to do that. Are there any final questions or comments people have

Francesco D'Amato: So I think one of the main updates from the breakout was, we pretty much agreed that we should have this version byte that Felix suggested. So I think unless someone wants to speak now, that that should be like a final decision. Because we've kind of yeah, we've been talking about this for a while, and really that seemed to be the the consensus on the call

Alex Stokes: Is that in the specs already in these Prs.

Francesco D'Amato: It's in the IP here.

Alex Stokes: Okay.

Justin Traglia: Just to double check. This would go into the execution payload header and the execution payload right? The version byte

Felix Lange: So this version by would only be in the wrapper of the blob transaction that is transmitted over the network. So that was the basically the idea, because that is the only place where we actually have the proof. So the the versioning there is the versioning of the proof and not the versioning of the transaction

Justin Traglia: So it doesn't go in the header

Felix Lange: No, there's no header changes or anything. This is purely like a networking change

Justin Traglia: Okay, per perfect. Yep, that's good.

Alex Stokes: Okay, I can take a look at these Prs later today, and I will bias towards merging them soon.

Tim Beiko: Sweet? Any other questions. Thoughts. Okay. Then moving on. Okay for eof so there's been a lot of conversations about Eof this past few weeks. some concerns around the complexity of Eof, which were as well articulated in the shared blog post that I had in the chat. and there was a another proposal made by live clients to bring some of the functionality of eof in more piecemeal size, and then ipsilon team also put together a doc explaining, like, what are the different flavors of Eof that we can move forward with if we are to stick to this? so yeah. I asked if teams could share their positions or views in advance of the call. Most of them have. So thank you for this and a high level summarizing on the get side like client was a person who proposed the Eof alternative, and one of the authors of the Post with the complexity concerns. But then, Felix said that he personally supports the one of the options of eof so option d

base you seems to generally support eof but also had some or had some uncertainty with regards to which version of it. So there's option A or C from the blog post that they seem to preferred. And then Aragon, Nethermind, and Ref each had posts out, saying that they support eof but those came out, I think, before the blog post with the specific different options. So none of them kind of supported this or none of them sorry kind of specified, which subversion they wanted to have solidity also, put out a block post, saying that they support eof and kind of went into a the list of like. Why, they like each features rather than sticking to an option. And then, Vitalik had an agenda comment, saying that he would be fine with either having these piecemeal options, or like maybe some more minimal version of eof

I guess at a high level. It seems like there's pretty broad support for eof still, despite kind of these issues raised around complexity. But maybe I'll I'll start here like does anyone feel like that's not the case. And that we should somehow reconsider all the Vof in light of this? Okay? Then. assuming we do want to move forward with this. The question is, which version should we move forward with? And and and how?

Charles Cooper: Yeah, and

Tim Beiko: Oh, yeah, sorry, Osgar. You have a comment. Not quite sure. I got it

Ansgar Dietrichs: Which comment, no, I was just trying to. I mean, I did not speak to Vitalik about this topic. I just I was just saying, I think my understanding is. Oh, did you mean the other comment

Tim Beiko: Oh, yeah, yeah, like unspecified should mean support for the for the full version. Right?

Ansgar Dietrichs: Shame because you said there's a few clients that didn't specify the option as well, and I think, unless expressly stated otherwise. Given, that the full version was the only one proposed at that time. I think that should be by default interpreted as support for only the full version

Tim Beiko: Got it. Okay, yeah. And then I think the it it seems like, yes, like Felix's post actually oppose this. So and and that seems to be the main second point is, do we actually want to ban code introspection? And yeah, at least, Felix was

Felix Lange: Yeah, I can get

Tim Beiko: Yeah.

Felix Lange: I can give my 2 cents on this. So I mean, I'm not per se, like I mean, I understand that, like some of the benefits of Uf, which I also learned a lot about from Solidity's post. Today. Some of the benefits actually come from having this in. For example, this idea of being able to transpile the contracts like with basically without keeping their original code. This is something that I can understand. Like the fewer features, the Evm has, the easier it is to make it work. And my main concern is just that. basically just knowing that people do all kinds of stuff. It's I feel like it's pretty strange, for example, to remove the gas introspection because it's something that exists right now, and it is pretty heavily used. So creating a new model where it's not possible is just something that is gonna raise some issues. And

I'm not sure I mean, this is also something that was raised by I forgot the name of the person, but there was this thing discovered pretty much, I guess, last week or the week before, where, just not having a gas introspection, for example, can lead to a situation where all of a sudden, without some extra precautions. there is the problem that even simple transfer operations can all of a sudden lead to an arbitrary execution that wasn't really possible before. And in general I do feel like it's a pretty cool feature in the Evm to be able to constrain the gas of a sub call and just not having that, I guess it's maybe tangential to Uf, but is.

Yeah, there's just a bunch of things where I feel like it could be. It's somehow simpler to not do these changes to the, to the model of the Evm. And just only focus on the encoding of the bytecode. Some of like cleaning up some of the basic access to the stack and the memory, and the jumps, and so on, but leaving the fundamental feature set of the Evm. Kind of the same, whereas with this the proposed changes of removing code introspection, removing gas introspection. It really cuts like a lot of things out of the model that exists right now. So basically and then the other. The reason why I said it might be good not to remove these things. It's just because, yeah, I feel like it. Somehow. It it would somehow simplify uf, still like it is

a compromise in some ways, like some. Some things that uf proponents really want will not be possible. If we have code introspection, or at least they will have to somehow emulate it in some way, or it has some. It has to be evaluated. But what it actually means to have Uf, with these features in place, and probably someone has already done this analysis, and I'm just not aware of it, but kind of what I think is that if we don't focus on removing these particular parts of Evm. then it will be a simpler change in the end, because it doesn't remove so much from the Vm. and yeah, that's kind of why I put this. But I am. I mean, if

I would just really prefer to like see some kind of analysis where someone has, I feel like this option of like having Uf with the introspection is kind of a new one also, that's not like it was even listed in that document as being like a very recent addition. So

Tim Beiko: Got it. Thank you. There's a couple other hands up. Ben.

Ben Adams: Yeah. So the the pay up code, which is slated for Devnet 2 fixes the the transfer issue. But just on the gas introspection front. It is kind of problematic, because we are considering repricing all the OP. Codes. So any sort of gas limiting that people put in their contracts will be wrong. It when we do reprice it just as an example. For code introspection. There's still like data sections that you can inquire. You can ask the contract about, you know data. So you can still put data, and you just can't inspect the actual running code

Tim Beiko: Got it. Thanks. Onstar

Ansgar Dietrichs: Yeah, I just want to say, from my point of view, I I don't have a strong opinion on like overall is you have worth the complexity, cost, or anything, but in terms of just the introspection. I think this has been the kind of result of of pretty long, careful design considerations, including thing things like, it's always easy to add things back later. But it's basically possible to remove. So if we ship the version of Uf without removing introspection. Then that means that until maybe you have v. 3 or something like in in 5 or 10 years, we will just not have any ability to remove introspection at all, and whereas if we ship it without introspection, it turns out that it really really was important, and the considerations were wrong about why we don't have it. We can always add it back in a fork in a year or so. So I think the the kind of costs of getting this wrong are very asymmetric here, so that I think, should by default biases a lot towards keeping the the bands in.

And then also, in addition, this was the kind of the very mature version that we kind of worked on or like people work towards for years, whereas, like these, these ideas, for, like removing the inspection bands came in last second. So for all of these reasons, I personally think that it would be like a very headless decision to to now last second kind of change, this so fundamentally

Felix Lange: I get it? Maybe one question I have sorry to interject is just with regard to the compatibility, isn't it? Also that, for example, removing code. Introspection means that we I always felt like. This is the main reason why, for example, there, there are these restrictions on calling legacy contracts from within Euf and things like that, like. The only reason not to allow it is to basically because it could be used to sidestep the introspection again, so that these kinds of limitations, I feel it will actively hurt the user experience, like, if there is no real interoperability between the 2 systems, if they are kind of isolated from each other. I always felt like that part is a bit weird, and we don't really know how that's even going to play out in the app layer

like what? That, what that really means. But like. So that's that would be another reason for me to just say, Well, if it's if we just if we just don't have that problem because everything kind of remains the same, then it's somehow easier. But this is more like a gut feel thing like I haven't really analyzed this

Tim Beiko: Thanks. Charles, you have your hand up

Charles Cooper: Yeah, I I think you maybe apologize if this background but I think you asked if there's like overall concerns, and I do. By the way, I'm Charles from Piper, and I do think there are some concerns about complexity on my end. I think that we could get a lot of the benefits of Uf with like much fewer eips and I know the code and container format has been worked on for a long time. But like, even from the compiler implementation perspective, like if you have, like, eip 2315 subroutines and static jumps that already get to a lot of the benefit of so I wonder if we can do it in some kind of more stripped down way again? I know a lot of the work has been done on this, but I don't think it's too late to think about simplifying it.

Tim Beiko: Right. So I guess on this point there was a proposal by that client, and there was obviously the the post. I don't know if you were one of the authors kind of arguing for this. My sense now is, client. Teams have reviewed all this, and still feel like some version of Eof is the best path forward. But yeah, if that's not the case, does anyone like, yeah, one advocate for that for make that point

Lightclient (Matt Garnett): Think everyone has reviewed most of the posts. But I will just reiterate again, since we need to verbalize some of these things. But there are many risks to doing this. And we. you know, even on much simpler proposals like Tstore and T. Load, have had issues where there are things that we simply did not consider during the design and implementation that ended up becoming problematic and with tstore and tload because it is scope to the transaction level, it kind of negatively affects how we use 4,337 with it. or generally the idea of relaying user operations. So eof is a much bigger change. And there is almost certainly things that are going to negatively going to be negatively impacted. And this is, you know, why I have kind of one of the reasons I've been against Eof, but also like one of the reasons that I agree with Felix, that if we are to do eof, then we should probably not

go very strong in the direction of banning a lot of behavior that exists today, because we will likely end up in a world where eof contracts are calling legacy contracts to get around some of the restrictions

Felix Lange: Yeah. So I'm learning this kind of right now that it is. Actually, it appears to be possible actually to just sidestep these restrictions. Anyway like this, there's this is actually not being prevented actively

Ben Adams: You can't. Code introspect Eos, from legacy. It'll tell you. It's like too bad

Felix Lange: Oh, right? Yeah, yeah, yeah, right? Right? No, no. Sorry. Yeah. It has it this way. Yeah, yeah, no. I agree. Sorry. Sorry. I was confused.

Ben Adams: Just just on the scale of the changes. Since the last hard fork. Geth, for instance, has had a hundred and sorry. 1,430 changes with 160,000 lines changed. Never mind, because I had about the same scale. Eof is in Geth. It's like a thousand line change. So you know, compared to how much goes into a fork. It is a small change. Although you know. Obviously, it's in a it's in a significant impacting. But I just want people to not underestimate how large the changes between the last hard fork, and the next hard fork

Tim Beiko: Yeah, it does. I, I. This gives like a proxy, but it, I think eof does change an extremely broad surface area of consensus critical code, which is different than I don't know what Guest did since the last hard fork. But if they added, you know, a bunch of Json Rpc stuff, or like, you know, stuff at the edges. Obviously, that's different than like rewriting. Dvm. yeah, Matthew, you had your hand up and then go up

Matthew Keil: I think it's worth saying. There's a lot of discussion. I haven't heard anything, and and that's 1 of those things is, Eof does open up a broad surface for additional Mev, and if there's going to be additional

Tim Beiko: Sorry? Why is that? Why is that true?

Matthew Keil: You know, I was talking with Guillaume about this and the idea that you can precompile all the contracts because there's a lot less of the dynamic jumps. And whatnot it gives you as as a block builder the ability to figure out much quicker how to pack the block because you don't have to do it. you, you could do it much faster, and I don't know enough about the other changes that are coming into the eof spec now, and I just wanted to at least bring it up as a cld, because I don't know, how some of the El stuff works that someone in research is talking about that, or at least looking at it. What are the implications to some of these new changes that are going to be coming in

Tim Beiko: Yeah, I I don't think this creates more. Mev, I think it. It might make block building more efficient. And so would it make like verifying transactions. So I I would not go down this round of hold. Now. Yeah, you'll have to a bunch of comments about the interactions of this and account abstraction

Yoav Weiss: Yeah, I wanted to reply to Matt's comment about potential potential issues with compatibility with the 47. So 1st of all, for account obstruction in general. I see things like gas introspection as a net positive, at least in the context of a validation. We don't really need the introspection. So eap 7, 7. 0, 1 does, removes the need for having this? But, as Matt pointed out, until we have 7,701, which will happen hopefully. One folk after eof we have to continue using 43, 7, and the entry point contact does require a gas introspection. However, I don't see it as a problem, because, you can still call entry Point as a legacy, as a legacy contract, and to my understanding it can. The accounts themselves. All the other contracts involved can be eof because you can call into an Eof contract from from entry point, which is not an Uf. Contract.

so I don't. So personally, I don't see an issue with having the full version of, say, eof from account, abstraction, perspective.

Tim Beiko: Okay? So I guess to summarize where we're at. It seems like there's support pretty unanimous for uf a pretty broad support for uf gas and code introspection. Seems like there's moderate support towards removing this. and there was a comment as well in the chat from earlier around, like what versions have been tested? And you know, the versions that are currently tested are the ones which do remove all of the introspection. so what if we were to add introspection back in? How big of a change is this like? Is this something we expect to take fair bit of work, or is it fairly trivial to to do? Yeah, you want to share demo

Danno Ferrin: Okay, so the question of how would we remove them? Option a is complete Eof, and that is the plan of record that we had a few weeks ago on our Devnet plan. so if we get rid of them, there are 3 approaches we can do, and the main 3 differences between these 3 is what happens in the create process and the create pads. Introspecting Eof is closest to what we have a complete eof today. All that we do here is we expose the existing ban, OP. Codes so we would just ban, I think, 7 OP. Codes. We wouldn't ban nearly as many, so we would have the the old call OP codes, which would give us full gas utility, and we would allow ext code copy into eof contracts. However, you would not be able to write an Eof contract from memory, you would still need to use Uf, create a creation transaction or Tx create. Coming from an init code transaction. If you want to do dynamic creations.

So that's what this introspecting eip preserves. It preserves basically all of complete except it gives you gas introspection and the read introspection on the band code introspection. So we would just band code writing from memory, which is the more critical piece for jit compilers. The next one is baseline eof, that's C. It was a C option. We change it so that create and create 2 can take either Eof or legacy contracts, and then it switches down one of 2 paths. If you're using init code, that is, from Eof, then you can only create Uf contracts from that. And if you have a knit code that is legacy, you can only create init code. You can only create contracts that are legacy, and it uses the existing Eof create version.

The 3rd option which is based off of what we had at Shanghai only listed what we had in Shanghai, and what was mandatory? All the create and create to everything would come from memory, whether it's eof formatted container or whether it's legacy and the create options would would apply to those. And for this minimal option we could very easily add 620-26-3748. It would be easier to just leave them in than to take them out. What really differs between these 3 is how the create options work. So the introspection is best preserved. The the the benefits of code introspection are best preserved in the introspecting eof the code is least changed with baseline and minimal. We completely and totally would remove the notion of introspection dance

Tim Beiko: Okay. So it feels almost weird to like, go back to the original version we had, which is like. Hey, but I feel like at this point. The yeah full eof with the pay up code seems like the most consensus path forward. Should we do that? Or I? I feel like either. Yeah, this is it. Then we move forward with it. the other option is like, if we agree, we want to do eof, and people feel like there's more stuff to discuss. We can finalize the actual spec on the breakouts next week. But I think at the very least today, it seems like, yeah, there's broad support to stick with. Eof.

And then, yeah, some supports towards like the full version. But I don't know if that needs to be debated some more. Ben

Ben Adams: An important thing to highlight is that Eof doesn't overwrite. It doesn't. alias any existing OP. Codes. So you know, if if in the future it was decided we needed gas introspection that could be reintroduced. It wouldn't. It wouldn't cause a a terrible conflict. Removing them would be a problem. Because once they're already there, you can't take them out because of that. Yeah.

Tim Beiko: That would also be my intuition that I personally would rather see a version of Eos ship with the bands than one without. Because, yeah, if we realize that we ship the of with the bands and that was a mistake, we can always add them in. But yeah, if we ship you off without those bands. We have something that's very close to the Evm. Already, and then no opportunity to no opportunity to like change that in the future. yeah, Onsgar.

Ansgar Dietrichs: Yeah, one last question, just on on process here. Do we want to make a, are we making a final decision on Uf today or I. I know that there was like a lot of the opposition to Earth in general came from people that are not super close to the Acd process. So I'm just wondering if it's worth basically saying, okay, we basically a plus pay is the version we want to go with preliminary decision. We basically confirm this in 2 weeks, unless there's like some strong push, basically by people or something. Then we revisit? Or are we just making the call today

Tim Beiko: I think we should make the call today. I think that, like the post that was written around the complexity objections was extremely good and well articulated and thorough, and I at least I don't. For the past few years I follow the of like. I haven't seen other objections that what was put into this post. So I don't know that we'll get much more signal by like doing another round of feedback. And I think, yeah, I I think we kind of have all the data. I I'm fine saying, if people feel like we need like a few more days to decide on the specific like configuration of Eof that might be reasonable, but at the very least agreeing that we broadly include Eof

seems to make sense and I think we can maybe get more than that. If we have consensus that we wanna, we wanna keep the the interest introspection bands and add the pay OP. Code. Yeah. Felix

Felix Lange: So just to mention something in general, our process is structured as such that even if we fully commit to shipping uaf option a today. If a breaking incompatibility or security related issue is discovered in the proposal, it will be retracted, or the issue has to be fixed. So I feel like it. It's very valuable today to agree on something, because whatever we decide, if there is something that means we cannot do it. It won't get done. Anyways, it's not like we have to do it. Then it's just this has happened before, like people. We have decided on something, and then we had to pull it later, because some last minute thing was discovered. So

Tim Beiko: Yeah, yeah. So I think, obviously, if we find some critical security issue like, that's always the case. But I do think, like, yeah. Barring that, we should no longer revisit this decision once we make it. Yeah. Oscar.

Ansgar Dietrichs: Yeah. One last point. Just also, as we start moving to talking about the other features. For Fusaka, either today or like in 2 weeks. I do. I still maintain, and I think it's good. It would be good if we could could affirm this, or at least affirm this in 2 weeks that I still think that the biggest priority by far of Fuzaka is Peter's. So I would stick with the plan that we ship Fusaka the moment Peter's is ready. and and basically stable. And that means that if, for example, you have for some reason does take longer in actually like working out all the kings. And people are not comfortable with the readiness of you have. By the time that that Pdas is is ready, I would still prefer, or any other feature that we might end up, adding, I would still very strongly prefer, if we basically are okay with, just let let leaving any features behind that just can't make it in time, because I really think, like Peters is the main feature for this year.

Tim Beiko: Yeah, I I think I would. I would agree with that and especially because this fork is pretty isolated. yeah. okay? And I guess. Yeah, before we we before we move on from the topic. The author of the complexity post. I'm I'm not sure what your actual name is but like P. Cavas Trevor Sakio. Sorry if I butchered your name. Is on. Do you want to give? Maybe, like some background on your perspective here. And oh, Pascal, yeah, your perspective on Uf, and like, what got you to write the post and the concerns

pcaversaccio: Sure you hear me

Tim Beiko: Yes.

pcaversaccio: Okay, cool. So I mean, I'm coming mostly from the application side. And I saw that. Yeah, you would like to get ef included. And I started reading about it, and it took me a lot of time to understand what's going on. And this is a huge concern to me because if it's so complex and it takes so much time to understand such a huge upgrade. You can't expect the community to give feedback. And about the community meeting on the application side. We had, for instance, for Teastore, T. Load. We had enough people from the application side who actually yeah, try to contribute, but the complexity of ef in itself the package overall. it takes so much knowledge, background, knowledge, and time

to understand the scope of it. And this is a huge concern to me personally, and that's why I started actually advocating against it. Because even right now, if I look into Tx, create Prs takes 3 h, or to understand what's going on for me, and to try to write feedback right? And there's some sort of disconnect between the core layer of people really understand what they're building and on the on the execution layer and on the application side right now for this for this specific upgrade. And that's I mean I'm against Uf. I can say here doesn't mean that my my opinion counts at all. But I'm really against Uf even at this point in time.

And yeah, that's that's what I want to say.

Tim Beiko: Thanks. Yeah. And I will say, look, I appreciate the time you've spent writing this, I again. I've said this, I think maybe right before you join, but it feels like the objections and concerns were very well articulated. My sense now is, people have reviewed this and still feel like it is the the right path forward. but and yeah, like, these are complex changes to review. One one thing I will note is, you know the people working on it have been thinking about this for the better part of 5 years, and yes, there is complexity in Eof, but it's also kind of the result of a long iterative process. So yeah, I I it. It is something we should consider. But we should push back. We shouldn't decide to not do something just because there is complexity in it.

yeah, I don't think it came across as disrespectful or anything. So I appreciate. Yeah. the the raising, the concern. And to move this forward practically, I guess one question I had in the chat is, if we went with option A, which seems to be the favored one at this point, and we added the pay up code, which, seems like we we have to. What would be the diff with what we already have in the Meta eip is there? Does someone have it like off off the top of their heads, or

Danno Ferrin: So what scheduled for inclusion does not include eip, 7, 7, 6, 1, eip, 7, 8, 8 0. And those are what I call symbolic introspection, which have been requested, came in last year from like Eip, 720 developers for for nfts, and those address those, and also open. Zeppelin has some concerns about safe proxies, and the and the delegates, and the type and address address those. So those who need to be moved in and payop code, I think, falls in the same bucket. It's not symbolic introspection, but it solves important findings that were brought forth by the community. And also one request from sourceify 7, 8, 3, 4, and these were all listed in the testnet plan that I presented over a month ago.

and these are mostly devnet 2 features. and the way it's structured is devnet. One has all the backwards incompatible features and stuff in Devnet 2 is forward, compatible. If we run out of time and period as is ready on the 1st of June. We could cut with what we have, and and drop Devnet to if we have to. So the design of the devnet is, we could cut it if we need to, and I think you know. on a different unrelated tangent that might be a model we might want to go for forks in the future is just because your schedule doesn't mean you're going to go in because it might get cut, because it's time to ship, and that just means you have a priority position for the fork. After that only works. If we do faster forks, so separate discussion.

Tim Beiko: Yeah. So I guess in terms of a practical next step here, I feel like we should schedule for inclusion the eips we want in the next eof devnet and then cfi the other ones that are part of option a, and including pay could you open a pr against me. I want to make sure we get this right. I know there's a lot of Ufips. But can you open a Pr. Against the Meta eip to do that where we yeah, sfi, the ones that would be in the next Uf devnet cfi, the ones that would be in the ones after that, and then we can make it. We can make a call to add them progressively based on how Peer Das evolves

Danno Ferrin: Yeah, I will do that before lunch.

Tim Beiko: Okay, thank you very much. So, and yeah, so a high level, the decision would be, move forward with option. A for eof include the pay off code, change and then break this down into manage manageable chunks for the Devnet implementation so that we're not holding off. We're not holding all of peered ass. If that is ready and you know, eof is a devnet one instead of devnet 2. Does that sound reasonable? Any final comments. Objections. Okay? Yeah. Thanks. Everyone. I think, yeah, I'm pretty happy. We finally got to a decision on this. yeah. And we can move forward, On the on the Fusaka front more broadly. So teams are like expected to share their preferences for all of the scope of the fork next week. We wanted to make sure that

we got like the big fundamental pieces locked in first.st So that's eof and pure das some teams have already put out blog posts. It seems like the only eip that came up in all of those posts. Was raising the gas costs, for MoD. Exp is the only El team that doesn't have a a blog post out yet. But I think if we wanted to take one more decision today, I would consider cfiing this vip about raising the MoD Xp gas costs. Also fine waiting to next week. If people want to have a call where we actually go through, like all of the different proposed Ips, and only make decisions, then. and yeah, if we wanted to. Cfi the MoD. Xp repricing, I would just sign it to check with guests that they're also okay with it.

Felix Lange: I mean, yeah, I can give the statement right here that I think like scoping it with Euf and the couple other small changes that were proposed is totally fine for us. This is literally also how we see it. It's mostly the issue, just we don't really have a blog to post it on. So I guess we we would be putting out a statement somewhere. But basically, we agree with the positions that are put forth by everyone else.

Tim Beiko: Okay, so I'll move to Cfi. I'll move to Cfi. One to. Sorry I moved the MoD. Xp repricing, which is Vip. 7, 8, 8, 3 to cfi and we can discuss all the other eips on the next call. But that one was just yeah unanimously stated. So it's kind of a no brainer. and yeah, well, we actually have 20 min to talk about the other topics. So I think we should move on anything else on Fusaka before we wrap up. Yeah, Potus

Charles Cooper: Freaking out.

Tim Beiko: We can't hear you, Potus, if you're speaking. Okay, Charles

Charles Cooper: I know it's a late change, but it's a small one. I'd like to propose. Eip 7, 9, 0, 3 and 7, 9, 0, 7 for increasing code sizing.

Tim Beiko: What is the IP. Sorry. 7, 9. 0, 3,

Charles Cooper: 7, 9, 0, 3 and 7, 9, 0, 7,

Tim Beiko: Yeah. So you already had those on the Meta eip. So I so the plan now is, teams will review this list of Pfi vips over the next 2 weeks, and we can discuss that on the next call. So I'll post the link here in the chat. But there's a bunch that have been proposed and of include in addition, sorry to the list I just posted. There were 2 more whose Prs couldn't be merged for some random bot issues. I had those in the in the agenda. But the expectation now is that given we we know we're moving forward with eof and pure. Das, yeah. In the next 2 weeks we can finalize the scope for everything else.

Yeah, photos

Potuz: I'm sorry. Think I probably fixed it

Tim Beiko: Yes.

Potuz: Okay. Good. So I'm not sure if it's for this call or the next one, or the very next one. But I I'd love to to have a discussion about, not about which Eip goes or which Eip doesn't go, but about timing of works, whether or not we want to prioritize scoping for time or scoping for content. And I think this discussion should be held before agreeing on what is gonna be. And I I could, if you want, I can give you an argument or otherwise. We could just

Tim Beiko: You know I

Potuz: For whatever it goes.

Tim Beiko: Yeah, I agree with that, I think for Fusaka specifically. It seems clear to me that every single team. or at least every single team I've spoken with says they want pure desk by the end of the year. And that should be our like baseline. starting point we literally just talked about this with with, you know, how would we handle eof if pure das is ready before? So I think we we should probably make this more explicit in general and and and moving forward. But I for Petra, specific, sorry for Fusaka. Specifically. I think it's shared by every single team to to get peered. Us live before the end of the year and or before Def connect

But if yeah, if a team doesn't feel that way I think they should make that clear. But I I don't think there is one, as far as I can tell. This doesn't mean we add nothing else to like the fork. But I think it. Yeah. It means we should wait that against the shipping date, and it also means that we should. We should be willing to remove stuff if it if it blocks if it blocks pure dash shipping earlier. Yeah. and and sorry. One more thing. So there's a comment about the r. 1 curve in the chat. I think the way we should proceed for the El side or the El on the Cl. It seems like there's 1 big feature to ship, and that's pretty much it on the El there's Eof. But there's also a bunch of small features.

My proposal there would be we only Sfi stuff when we're ready to implement them. So say that, like now we all agree the eof plus the MoD xp, or sorry Eof was like Sfi and we've like Cfi, this MoD. Xp repricing. Maybe we cfi the r 1 curve. We only move those into the fork when, like everything else, is ready, and then we can make a call like look if we can only implement one more thing. Do we do. MoD. Xp, do we do the r 1 curve, or or whatever but like. And yeah, sorry the the r 1 curve is already Cfi. So when we move, basically moving things from Cfi to Sfi should mean that we are putting it in the next devnet. And we don't think it's gonna significantly delay the 4th

So for now, what we would have specified is Eof peered us. Let's focus on implementing those and then see how close we are to shipping peered us. Sorry, long, winded way of saying for Fusaka specifically, we should end the ship before the end of the year. Anything else on Fusaka. Okay? On the history expiry and portal side. There were a few things to discuss. The 1st was this issue around the interaction of history expiry and the deposit logs. Alex, you put something about this in the chat

Alex Stokes: Yeah. So there was a summary in the comment on the issue. For today's call. Essentially given the way that 61 10 which changes, how deposits process, how clients today get the history for the deposit contract processing. There's a bit of a dependency here with history expiry, and from last week's call, we decided to wait for Petra before moving ahead with history expiry. So yeah, I think because of that, we said, Move ahead with doing this on sepulia both to test. And then also again, the fact that pector is live there. We have this dependency resolved already. And yeah, I think just because of that, then there would be an update to timelines for history expiry. And I think that was essentially the context

Tim Beiko: Yeah. Mikkel

Mikhail Kalinin: I just want to add a bit on that. I think we should be before doing the expiry. We should be sure that all cl clients. can actually sync a node from scratch without depending on historical deposits. So after the 61, 6, 1 10 activation, there will be a period of deprecating the previous mechanism, and after that cl clients will be able to completely wipe it, wipe it out from from their code bases. I don't know how how cl clients all cl clients are designed around this feature, but in the past, if I'm not mistaken, some of them were acquiring sinking deposits before they could start. for instance, to serve validator clients so just want to bring this up for us, you know, for for us not to

forget about this. And I think testing with Sepoli is important to show this, and probably it also will require infrastructure node operators to actually. I don't know. Maybe be aware of this, that for Bootstrap. And then, you know, they will need to use a new software. Yeah. So from scratch means that you start syncing with the empty database

Potuz: But I mean, I assume that you mean just checkpoint sync and backfield back down to Genesis, or something like this, or the week, just subjectivity period, or whatever. But you don't really mean syncing from genesis. Okay.

Piper Merriam: Are there actual cl clients today that are not ready for this? Just curious. I haven't been able to get an answer to that yet.

Alex Stokes: I I think you're asking if clients are ready for Petra, and they are so it should be good on that front

Piper Merriam: No, but I mean, whether or not, if it's removed. are there Co clients today? That would have a problem if history was drives? Are there cl clients today that if those logs were not available from their execution client that they would have a problem

Mark Mackey: Before the extra upgrade. A lot of cl clients like, if you don't have a deposit snapshot still rely on the logs to sync to the public contract. But while many of them have implemented it, sometimes some of the tooling around syncing doesn't support it. So like it's a fallback, basically, for now, until the fork goes, live

Piper Merriam: Cool and do so. I see prism listed as as potentially one that has a dependency on us

Potuz: I don't think prison has an issue past the period, the 6 1 1 0 period. I mean, it's there are cosmetic messages. But we should work fine if the history is dropped after the transition period after 6, 1, 1 7 0

Piper Merriam: Got it. So prism's fine as long as the drop happens after Petra, and that's fine. If it's shortly after Petra

Potuz: Well, it's it's not Petra. It's after the 6 1 1 0 I mean, there's a transition period after the fork, and after that transition period. If you drop it after that, then it's fine

Piper Merriam: Got it, and we, and reasonably we, expect this transition period to last no longer than

Alex Stokes: Depends on the size of the deposit queue at the time of the fork. So it's kinda hard to say, but we can look closer to the main net date, and we can get a better

Piper Merriam: Sure, but but just like ballparking it. So that people have a are we talking about 6 weeks? We need 6 months. We need 2 months. We need 8 days, I think, more like a week

Alex Stokes: But I think more like weeks or days even. But it depends like if someone comes in and makes like a bunch of deposits right before

Piper Merriam: Sure, but we could set a target date of 4 weeks after the 4, and that we would be in a high confidence of hitting

Alex Stokes: Seems fine, but again, I think like we'd have a much more high confidence estimate right near the fork

Potuz: Is it too hard to drop it on Sepholia, or to drop it on booty and change? And and all these chains that already have merged, have a port

Tim Beiko: Yeah, I think I I would agree with that, like, I don't see why we would not run this test through our standard process, especially considering that in the past month everything we've put on a test net has had issues. So I

Piper Merriam: Nope, I I was under the understand. It was my understanding that we had come to some agreement that we were. Gonna do fully a drop on May first.st That's 1 of the other topics for today.

Tim Beiko: Okay, yeah, is that right?

Alex Stokes: Is it

Tim Beiko: Yeah.

Alex Stokes: I was. Gonna say, the suggestion then, is just focus on sepulia. And then once we do that, then we can think about main debt, although I think Piper is asking if we could go ahead and have some main estimation right now. But everyone's suggesting we just wait on Mainnet

Piper Merriam: I think it is a silly idea to just say that we're going to wait on Main Nap if we expect it only to take a short time after main nap. Then I think it is important for clients to have an expectation that the plan is that shortly after goes live on Mainnet that their clients are ready to do the drop there as well

Tim Beiko: Yeah, I think that makes sense. But yeah, we don't necessarily need to have a specific date set. Yet we should have a date for sepulia, and if client teams are you know, are fine. With that we can see how sepulia goes. Analyze it, set a main update after I don't see a major reason why we would want to main that they'd set before we know if sepulia worked and it was a Barnabas has a comment in the chat, saying, like, do we? Can we do this? Before the main net, Petra, for like? Is there a reason to wait to may 1st for sepulia. Aside from everyone being busy right now.

Piper Merriam: I think the main thing for Oppolia is el clients having a release ready that is able to drop the the pre merge history at that time. How much time do clients need for that? Also, we need each 69 finalized before that as well. If I have this correctly sorted in my head.

Tim Beiko: And

Felix Lange: As far as I understand, there's no real need to finalize the E 6, 69 before we drop the history. It's just something that is an optional extra kind of. So also

Barnabas Busa: Click now, like starting from today, whoever is ready can drop it and call. Today. You need to like

Felix Lange: Oh, yeah, I guess so. We're not so in terms of get. For example, we are still very much working on the implementation of it, and we were kind of like working towards that May 1st date. So I would like to see that. You know, we have a bit of extra time to actually finish our implementation of it. There is. It's not entirely trivial in the client, I mean, yeah, for some clients, it's easier because they kind of already had this, but we didn't, and we are still actively working on making sure the client is fully working with some of the blocks removed, and

Barnabas Busa: Question is, could other clients not drop it, though, like starting now in only in support? Yeah, I'm on

Felix Lange: Yeah, I mean, we can't really prevent them to know. I mean, it's literally the status quo, as far as I understand. So it's not something that I don't think we can forbid it in some way. I mean the main impact this is going to have is just it's going to make it a bit harder to sync these blocks, but as long as it doesn't become impossible, it's fine. The main thing with the why we wanted to agree on a date is because it actually may become impossible after this, because if everyone drops it, they're just gone, and then we would have to somehow put them back in. which is not super easy. So that was the main reason why we wanted to agree on this date. I mean, if we're now going to just go with whatever date. It's also fine. As long as we're reasonably confident there will be some notes that are still kind of serving it for those who really do want to sync it. Now.

marek: So! Oh!

Tim Beiko: Okay. So we only have 3 min left, like is supposedly on my 1st thing we've agreed to. And in the chat people seem to say, we're on the same page about this like, should that be the latest date for everyone? If we need to hash this out more. then agreeing to May. First, st I feel like we should move this to a separate call or a separate discussion. Forum I'm not sure what the best place is, though

Piper Merriam: There's no strong objections to May. First, st let's say that it's May 1st today, and we can confirm this over the next week. Asynchronously

Tim Beiko: Okay. And where should we document this like, it feels like it would be nice to have something more than just. I'll code of zoom chat to like keep track of the overall plan for how we deploy history expiry. I don't know. If you want to update the eip with this information, or have some like Meta eip or some other spots. But yeah, it would be because infrastructure providers like it's not just client teams. I need to coordinate on this. There are like the users of the nodes, and it would be good to be able to inform them of what the yeah, what the plan is. And yeah, maybe it should be just an informational vip that's added to the Fusaka Meta.

But somewhere with this information would be nice. Yeah, Piper, can you take the lead on this? Okay, thank you. we only have 2 min left. There were like 3 other topics around portal history expiry 869 like client and portal issues. I don't think we have sufficient time to cover those. But does anyone want to give a quick shout or share where people can discuss this. Okay? If not, then I could take the last minute. Barnabay and Onskar are launching a protocol research call. Do you guys want to give a quick overview about what this is

Barnabe Monnot: Yeah, I can do that quickly. Thank you for the time. So we're launching this experimental call protocol research call next week. Wednesday at 8 o'clock. The idea of this call is to try and address the why of some of the big questions that ethereum faces, and we hope that it's a place to bridge research, core development and the larger community of builders and users as well. So yeah, the 1st call will be on what we want from our nodes on the network. We'll talk about questions like local building. The validator set. Yeah, I see, Onsgar has dropped a link to the to the announcement. So yeah, we hope to see as many people there as possible.

Tim Beiko: Nice. Thank you. And with that we're at time. There's 1 last non urgent thing that was on the agenda. andrew brought up that. We need to start thinking of a sepulia replacement for a year or so from now, and we need a name for it. So if you wanna discuss potential name, you can do the one do so on East magicians. and with that we actually covered everything that was on the agenda. Thank you very much. Everyone. I'll make a small Pr to the Meta eip to add. The MoD. Xp precompile we'll wait on Daniel for the larger Pr for the Eof changes, and then yeah, on next week cl, call and the El call. The week. After that we can

we can finalize the specs for Fusaka. But yeah, thanks. Everyone.

Alex Stokes: Thank you.

Fredrik Svantes: Thank you.

Ansgar Dietrichs: Thanks everyone, bye.

Potuz: Bye.

Tomasz Stańczak: Thank you. Both

Justin Traglia: Hi! Everyone.

Pooja Ranjan: Thank you.

Yoav Weiss: Hey!

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