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.
Transcript
Tim Beiko: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.
Tim Beiko:Then what I expect will take most of the call Fusaka.
Tim Beiko:So we have some updates on pure Das.
Tim Beiko: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.
Tim Beiko:and if we have time there are a few portal network and history expiry topics to also cover at the end of the call.
Tim Beiko: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
Parithosh Jayanthi:roughly at this time, and immediately after there was a relatively stable participation rate. We finalized without any unexpected problems.
Parithosh Jayanthi: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.
Parithosh Jayanthi: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
Parithosh Jayanthi:all the results on consolidations, manually trigger withdrawals and so on.
Parithosh Jayanthi:But so far everything looks to be going as expected.
Parithosh Jayanthi:yeah, I think that's most of what we have to report. At this moment more coming up
Tim Beiko:Thank you.
Tim Beiko: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.
Ivan Metrikin: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.
Ivan Metrikin: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.
Ivan Metrikin: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
Ivan Metrikin:client teams, I think you've done a fantastic job here
Tim Beiko:Thank you.
Tim Beiko: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.
Tim Beiko: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?
Tim Beiko:yeah, a lot of contracts depend on on safe. And then, Eigenlayer also has a lot of like restaking protocols on top of it.
Tim Beiko:so generally seems like things are going well on the application layer layer testing
Tim Beiko: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:Yeah, yeah, sure. I can share my screen quickly.
Fredrik:I am not going to go through all of this, considering that.
Fredrik:we don't have that much time.
Fredrik: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: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.
Fredrik:Most of this is, are things that is already being done today, and it's
Fredrik: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.
Fredrik:The the main difference, I would say, is something that's part of the end here.
Fredrik:which is some incident response plan.
Fredrik:Where, ahead of the hard work, we
Fredrik:assign roles to some people. And these people then have
Fredrik: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
Fredrik:that we have
Fredrik:the right people working to solve that incident as quickly as possible, and it also adds a few other things like, you know.
Fredrik:instead of just waiting for finalization and calling that a success there should be some
Fredrik:verification of the eips, for example, to ensure that
Fredrik:they were. They're actually working on the test nuts and on main nuts before success is is called.
Fredrik:There is.
Fredrik:There are some templates that can be used for the upgrades. Basically.
Fredrik:the idea would be that, you know, for the let's say we're upgrading Poleski again.
Fredrik:then we would fill this out. So we have a record of that. We would have some
Fredrik:information about where people can find updates and where they can communicate.
Fredrik: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
Fredrik:verification what should be verified after the upgrade has gone through, and then perhaps the most
Fredrik:like one of the.
Fredrik:I guess contentious or controversial points to discuss would be the timelines that are listed in this document.
Fredrik:basically. What it says right now is that there should at least be 14 days apart between each test. Net
Fredrik:test. Nuts should not be scheduled at the same time.
Fredrik:but it says, should, so they can. There is some reasoning why that should not be the case.
Fredrik:and it also states that there is this kind of
Fredrik:wait, or I guess, review period between clients being having their releases out and the 1st testnet being upgraded.
Fredrik:which in this document is 30 days. And the reasoning here is that
Fredrik:during these 30 days we can run
Fredrik: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
Fredrik:ready.
Fredrik:As well as external auditors. If we need to. But this, of course, adds a bit of extra time between clients being ready.
Fredrik:the upgrades being live on Mainnet, so
Fredrik:I don't know if that's something we should
Fredrik:discuss in this call team, or if the people should leave
Fredrik: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.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko: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.
Tim Beiko: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: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:Yeah, but I I have talked with the all the client teams, and they have provided a lot of super valuable information. So
Fredrik: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.
Tim Beiko: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
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:seems reasonable.
Tim Beiko:The other process change with regards to deploying hard forks was this idea of eth config as a Json, Ipc Api. So
Tim Beiko:To give some context on this
Tim Beiko: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 | Ipsilon:Sure. So I've drafted up any IP for the 79
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon:So that's basically the high level overview of how this is meant to work.
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon: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.
Tim Beiko: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:I feel like it's not something that requires like any kind of fork.
Felix: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
Tim Beiko:quadruple, checking the configs? Without this? For
Felix: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.
Felix: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
Felix: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
Felix: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
Felix: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.
Felix:The on the testnet obviously should be included. But no, I mean
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon:dev. P. 2 p. Stuff with the fork. Id. So we have that already in process
Danno Ferrin | Ipsilon:and working well. I think
Felix: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
Felix:useful thing, but we would still implement it. Of course, like it's no big deal
Danno Ferrin | Ipsilon: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
Tim Beiko: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
Tim Beiko:obviously manually review the configs on the clients for for Petra.
Tim Beiko:And yeah, anything else on this topic.
Tim Beiko:Okay. Thanks, Daniel. Next up main net timing. So
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:Yeah, do people have a strong preference around trying to set it today or waiting another week or 2.
Tim Beiko:okay, we have a okay. We have some preference towards setting a date the 1st is April 30.th
Tim Beiko:Which I think is also the slot Barnabas. I put out there.
Tim Beiko: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.
Tim Beiko: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.
Ivan Metrikin: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?
Tim Beiko:Okay, there isn't. So.
Tim Beiko:I guess if we just stick to client teams, is there any client team for whom?
Tim Beiko:for whom? Like having your release out mid April would be problematic.
Tim Beiko: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
Tim Beiko:yeah, is there any team that today feels like getting your release out by April April like 14
Tim Beiko:would be problematic for them, and that they would want to push back even beyond that.
Tim Beiko:Okay, then, if
Tim Beiko: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
Tim Beiko: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
Tim Beiko: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
Tim Beiko:that seem reasonable. Any objections?
Tim Beiko:Okay, let's do that.
Tim Beiko:Great.
Tim Beiko:So yeah. So again, that would be on April 30.th Epoch 3, 6, 2, 4, 9, 6.
Tim Beiko: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
Tim Beiko:and then our deadline for teams to share their perspectives about the fork was next week. So
Tim Beiko: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.
Tim Beiko:So please. Yeah, please review the list of pfi vips if you haven't already.
Tim Beiko: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.
Minhyuk Kim: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.
Minhyuk Kim: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.
Minhyuk Kim: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.
Minhyuk Kim: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.
Minhyuk Kim:Thank you.
Tim Beiko:Thank you.
Tim Beiko:Yeah. Any questions concerns.
Tim Beiko: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.
Minhyuk Kim:So yeah.
Felix:So maybe a quick comment from my side on this, since Geth has a disk based
Felix: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.
Felix:So this is just something to keep in mind is that we are not bounded by the
Felix: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
Marcin Sobczak: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
Marcin Sobczak: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.
Tim Beiko:Any other questions on this.
Tim Beiko: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.
stokes:Yeah, hey?
stokes:So I linked to Prs here, I think most people know the topic.
stokes:There's a migration of the salt proofs, which is a slightly new type of proof in paradox that we have.
stokes:There's been the idea to move this to the El from the Cl. We think it will help with performance.
stokes: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.
stokes: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: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
Francesco:unless someone wants to speak now, that that should be like a final decision. Because we've kind of
Francesco:yeah, we've been talking about this for a while, and
Francesco:really that seemed to be the the consensus on the call
stokes:Is that in the specs already in these Prs.
Francesco:It's in the IP here.
stokes:Okay.
Justin Traglia:Just to double check. This would go into the execution payload header and the execution payload right?
Justin Traglia:The version byte
Felix:So this version by would only be in the wrapper of the blob transaction that is transmitted over the network.
Felix:So that was the basically the idea, because that is the only place where we actually have
Felix:the proof. So the the versioning there is the versioning of the proof
Felix:and not the versioning of the transaction
Justin Traglia:So it doesn't go in the header
Felix:No, there's no header changes or anything. This is purely like a networking change
Justin Traglia:Okay, per perfect. Yep, that's good.
stokes:Okay, I can take a look at these Prs later today, and
stokes:I will bias towards merging them soon.
Tim Beiko:Sweet?
Tim Beiko:Any other questions.
Tim Beiko:Thoughts.
Tim Beiko:Okay.
Tim Beiko:Then moving on. Okay for eof so there's been a lot of conversations about Eof this past few weeks.
Tim Beiko:some concerns around the complexity of Eof, which were as well articulated in the shared blog post that I had in the chat.
Tim Beiko: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?
Tim Beiko:so
Tim Beiko: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
Tim Beiko: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
Tim Beiko:or none of them sorry kind of specified, which subversion they wanted to have
Tim Beiko: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
Tim Beiko:I guess
Tim Beiko: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
Tim Beiko:that we should somehow reconsider all the Vof in light of this?
Tim Beiko:Okay? Then.
Tim Beiko:assuming we do want to move forward with this. The question is, which version should we move forward with? And and and how?
Charles:Yeah, and
Tim Beiko:Oh, yeah, sorry, Osgar. You have a comment.
Tim Beiko: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.
Ansgar Dietrichs: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
Tim Beiko:I think the it it seems like, yes, like Felix's post
Tim Beiko: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:Yeah, I can get
Tim Beiko:Yeah.
Felix: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.
Felix:basically just knowing that people do all kinds of stuff.
Felix: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
Felix: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.
Felix: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
Felix:tangential to Uf, but is.
Felix:Yeah, there's just a bunch of things where I feel like it could be.
Felix: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
Felix:a lot of things out of the model that exists right now.
Felix:So basically and then the other. The reason why I said
Felix: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
Felix: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.
Felix:then it will be a simpler change in the end, because it doesn't remove so much from the Vm.
Felix:and yeah, that's kind of why I put this. But I am. I mean, if
Felix: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
Felix:addition. So
Tim Beiko:Got it.
Tim Beiko: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.
Ben Adams:It is kind of problematic, because we are
Ben Adams:considering repricing all the OP. Codes. So any sort of gas limiting that people put in their contracts will be wrong.
Ben Adams:It when we do reprice it just as an example.
Ben Adams: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.
Tim Beiko: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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: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
Felix: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
Felix:like what? That, what that really means.
Felix: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: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
Charles: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
Charles:I know the code and container format has been worked on for a long time. But like, even from the compiler implementation perspective, like
Charles: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
Tim Beiko:yeah, if that's not the case, does anyone
Tim Beiko:like, yeah, one advocate for that for make that point
lightclient: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.
lightclient:And we.
lightclient: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.
lightclient:or generally the idea of relaying user operations.
lightclient: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
lightclient: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: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: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
Ben Adams:the last hard fork. Geth, for instance, has had a hundred and sorry. 1,430 changes with
Ben Adams:160,000 lines changed.
Ben Adams:Never mind, because I had about the same scale.
Ben Adams:Eof is in Geth. It's like a thousand line change.
Ben Adams:So you know, compared to how much goes into a fork.
Ben Adams:It is a small change.
Ben Adams:Although you know. Obviously, it's in a it's in a significant impacting.
Ben Adams:But I just want people to not underestimate how large
Ben Adams:the changes between the last hard fork, and the next hard fork
Tim Beiko:Yeah, it does. I, I.
Tim Beiko:This gives like a proxy, but it, I think eof does change
Tim Beiko: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.
Tim Beiko:yeah, Matthew, you had your hand up and then go up
Matthew Keil:I think it's worth saying.
Matthew Keil:There's a lot of discussion. I haven't heard anything, and
Matthew Keil: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
Matthew Keil: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: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?
Yoav: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.
Yoav: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.
Yoav: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?
Tim Beiko:So I guess to summarize where we're at. It seems like
Tim Beiko:there's support pretty unanimous for uf a pretty broad support for uf gas and code introspection.
Tim Beiko:Seems like there's moderate support towards removing this.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:fair bit of work, or is it fairly trivial to to do?
Tim Beiko:Yeah, you want to share demo
Danno Ferrin | Ipsilon:Okay, so the question of how would we remove them?
Danno Ferrin | Ipsilon:Option a is complete Eof, and that is the plan of record that we had a few weeks ago on our Devnet plan.
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon:The next one is baseline eof, that's C. It was a C option.
Danno Ferrin | Ipsilon:We change it so that
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon:So the introspection is best preserved. The the the benefits of code introspection are best preserved in the introspecting eof
Danno Ferrin | Ipsilon:the code is least changed with baseline and minimal. We completely and totally would remove the notion of introspection dance
Tim Beiko:Okay.
Tim Beiko:So it feels almost weird to like, go back to the original version we had, which is like.
Tim Beiko:Hey, but I feel like at this point.
Tim Beiko:The yeah full eof with the pay up code seems like the most consensus path forward.
Tim Beiko:Should we do that? Or I? I feel like either.
Tim Beiko:Yeah, this is it. Then we move forward with it.
Tim Beiko: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
Tim Beiko:today, it seems like, yeah, there's broad support to stick with. Eof.
Tim Beiko:And then, yeah, some supports towards
Tim Beiko: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.
Ben Adams:alias any existing OP. Codes. So
Ben Adams:you know, if if in the future
Ben Adams:it was decided we needed gas introspection that could be reintroduced. It wouldn't. It wouldn't cause a
Ben Adams:a terrible conflict. Removing them would be a problem. Because once they're already there, you can't take them out
Ben Adams: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
Tim Beiko: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.
Tim Beiko: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
Ansgar Dietrichs: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
Tim Beiko: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
Tim Beiko:doing another round of feedback. And I think,
Tim Beiko: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
Tim Beiko:that might be reasonable, but at the very least agreeing that we broadly include Eof
Tim Beiko: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.
Tim Beiko:Yeah. Felix
Felix: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
Felix: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
Felix:whatever we decide, if there is something that
Felix: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,
Tim Beiko:like, yeah. Barring that, we should no longer revisit this decision once we make it.
Tim Beiko:Yeah.
Tim Beiko: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.
Ansgar Dietrichs: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
Tim Beiko:I think I would. I would agree with that and especially because this fork is pretty isolated.
Tim Beiko:yeah.
Tim Beiko:okay? And I guess. Yeah, before we we before we move on from the topic. The author of the complexity post.
Tim Beiko:I'm I'm not sure what your actual name is but like P. Cavas
Tim Beiko: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,
Tim Beiko: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.
pcaversaccio:So I mean, I'm coming mostly from the application side. And I saw that. Yeah, you would like to get ef included. And
pcaversaccio:I started reading about it, and it took me a lot of time to understand what's going on.
pcaversaccio: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.
pcaversaccio: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.
pcaversaccio:it takes so much knowledge, background, knowledge, and time
pcaversaccio:to understand the scope of it.
pcaversaccio:And this is a huge
pcaversaccio: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
pcaversaccio:between the core layer of people really understand what they're building
pcaversaccio:and on the on the execution layer and on the application side right now for this for this specific upgrade. And that's
pcaversaccio: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.
pcaversaccio: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.
Tim Beiko:but and yeah, like, these are complex changes to review. One
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:yeah, I don't think it came across as disrespectful or anything. So I appreciate. Yeah.
Tim Beiko:the the raising, the concern.
Tim Beiko:And
Tim Beiko: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
Tim Beiko:is there? Does someone have it like off
Tim Beiko:off the top of their heads, or
Danno Ferrin | Ipsilon:So what scheduled for inclusion does not include eip, 7, 7, 6, 1, eip, 7, 8, 8 0.
Danno Ferrin | Ipsilon:And those are what I call symbolic introspection, which have been requested, came in last year from like
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon:and these are mostly devnet 2 features.
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon: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
Tim Beiko: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
Tim Beiko: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 | Ipsilon: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.
Tim Beiko:Does that sound reasonable? Any final comments. Objections.
Tim Beiko:Okay?
Tim Beiko:Yeah. Thanks. Everyone. I think, yeah, I'm pretty happy. We finally got to a decision on this.
Tim Beiko:yeah.
Tim Beiko:And we can move forward,
Tim Beiko: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
Tim Beiko: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
Tim Beiko: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.
Tim Beiko: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: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
Felix:everyone else.
Tim Beiko:Okay, so I'll move to Cfi. I'll move to Cfi. One
Tim Beiko:to. Sorry I moved the MoD. Xp repricing, which is Vip. 7, 8, 8, 3 to cfi
Tim Beiko:and we can discuss all the other eips on the next call. But that one was just
Tim Beiko:yeah unanimously stated. So it's kind of a no brainer.
Tim Beiko:and yeah, well, we actually have 20 min to talk about the other topics. So I think we should move on
Tim Beiko:anything else on Fusaka before we wrap up.
Tim Beiko:Yeah, Potus
Charles:Freaking out.
Tim Beiko:We can't hear you, Potus, if you're speaking.
Tim Beiko:Okay, Charles
Charles: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: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
Tim Beiko:that on the next call. So
Tim Beiko: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
Tim Beiko:we know we're moving forward with eof and pure. Das, yeah.
Tim Beiko:In the next 2 weeks we can finalize the scope for everything else.
Tim Beiko:Yeah, photos
Potuz:I'm sorry.
Potuz: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.
Potuz: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.
Tim Beiko:It seems clear to me that every single team.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:in general and and and moving forward. But I for Petra, specific, sorry for Fusaka. Specifically.
Tim Beiko: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
Tim Beiko:But if
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:Yeah.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko: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,
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:Sorry, long, winded way of saying for Fusaka specifically, we should end the ship before the end of the year.
Tim Beiko:Anything else on Fusaka.
Tim Beiko:Okay? On the history expiry and portal side. There were a few things to discuss. The 1st was
Tim Beiko:this issue around the interaction of history expiry and the deposit logs. Alex, you put something about this in the chat
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
stokes:wait for Petra before moving ahead with history expiry.
stokes: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.
stokes: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.
Mikhail Kalinin:can actually sync a node from scratch without depending on historical deposits.
Mikhail Kalinin:So after the 61,
Mikhail Kalinin: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.
Mikhail Kalinin: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.
Mikhail Kalinin:for instance, to serve validator
Mikhail Kalinin:clients so just want to bring this up for us, you know, for for us not to
Mikhail Kalinin: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.
Mikhail Kalinin: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
Mikhail Kalinin: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.
stokes:I I think you're asking if clients are ready for Petra, and they are
stokes:so it should be good on that front
Piper Merriam:No, but I mean, whether or not, if it's removed.
Piper Merriam:are there Co clients today? That would have a problem if history was drives?
Piper Merriam:Are there cl clients today that if those logs were not available from their execution client that they would have a problem
ethDreamer (Mark):Before the extra upgrade. A lot of cl clients
ethDreamer (Mark):like, if you don't have a deposit snapshot still rely on the logs to sync to the public contract. But
ethDreamer (Mark):while many of them have implemented it, sometimes some of the tooling around syncing doesn't support it.
ethDreamer (Mark):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
stokes:Depends on the size of the deposit queue at the time of the fork. So it's kinda hard to say, but
stokes: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.
Piper Merriam:We need 8 days, I think, more like a week
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
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
Tim Beiko: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?
stokes:Is it
Tim Beiko:Yeah.
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
stokes:main estimation right now.
stokes: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
Piper Merriam: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
Tim Beiko: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
Tim Beiko:you know, are fine. With that we can see how sepulia goes. Analyze it, set a main update after I don't
Tim Beiko:see a major reason why we would want to
Tim Beiko: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?
Piper Merriam:Also, we need each 69 finalized before that as well. If I have
Piper Merriam:this correctly sorted in my head.
Tim Beiko:And
Felix: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
Felix:extra kind of.
Felix:So
Felix:also
Barnabas:Click now, like starting from today, whoever is ready can drop it and call. Today. You need to like
Felix: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
Felix: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
Felix:actively working on making sure the client is fully working
Felix:with some of the blocks removed, and
Barnabas:Question is, could other clients not drop it, though, like starting now in only in support? Yeah, I'm on
Felix:Yeah, I mean, we can't really prevent them to know. I mean, it's literally the status quo, as far as I understand.
Felix:So it's not something that I don't think we can forbid it in some way.
Felix: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.
Felix: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.
Felix:which is
Felix: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
Tim Beiko:is supposedly on my 1st thing we've agreed to. And
Tim Beiko:in the chat people seem to say, we're on the same page about this
Tim Beiko:like, should that be the latest date for everyone? If we need to hash this out more.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:But somewhere with this information would be nice.
Tim Beiko:Yeah, Piper, can you take the lead on this?
Tim Beiko:Okay, thank you.
Tim Beiko:we only have 2 min left. There were like 3 other topics around portal history expiry 869
Tim Beiko: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.
Tim Beiko: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
Barnabé 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
Barnabé Monnot: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.
Barnabé Monnot: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.
Tim Beiko:And with that we're at time. There's 1 last non urgent thing that was on the agenda.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:we can finalize the specs for Fusaka. But yeah, thanks. Everyone.
stokes:Thank you.
Fredrik:Thank you.
Ansgar Dietrichs:Thanks everyone, bye.
Potuz:Bye.
Tomasz Stańczak:Thank you. Both
Justin Traglia:Hi! Everyone.
Pooja Ranjan:Thank you.
Yoav:Hey!
Chat Logs
00:00:24
stokes:gm
00:00:27
rodiazet | Ipsilon:🍿
00:00:32
terence:早上好
00:00:58
Danno Ferrin | Ipsilon:Replying to "There were two EOF r..."
PAY is presumed in EOF option A.
00:04:22
Hadrien Croubois (OpenZeppelin):Replying to "There were two EOF r..."
If other opcode proposals (like 7819, but I don't think its the only one) don't have an opportunity make their point, and option A happens, these is basically no clear path for them being included at any point.
That allone pushes to away from option A.
00:04:37
Parithosh Jayanthi:Gnosis safe is live on hoodi now 😄
00:04:44
Hadrien Croubois (OpenZeppelin):Replying to "There were two EOF r..."
A mega EOF that doesn't really include everything is not a mega EOF, is it ?
00:04:46
Parithosh Jayanthi:(Deployed by someone else afaik)
00:05:14
Ivan Metrikin:Replying to "Gnosis safe is live ..."
It was deployed by Protofire, shoutout to them!
00:05:29
Parithosh Jayanthi:Replying to "Gnosis safe is live ..."
Yess thank you for organising that!
00:05:35
Tim Beiko:https://github.com/ethereum/pm/pull/1409
00:06:07
Danno Ferrin | Ipsilon:Replying to "There were two EOF r..."
I think there is still room to add CREATEDELEGATE no matter what option passes. This week is focused on EOF in general. This is not the last week for fusaka
00:06:45
pk910:Replying to "Gnosis safe is live ..."
is there a link? :)
00:06:57
Hadrien Croubois (OpenZeppelin):Replying to "There were two EOF r..."
2 weeks ago, it was mentioned that Fusaka EIPs would be frozen beofre today :)
00:08:33
Parithosh Jayanthi:Replying to "Gnosis safe is live ..."
Steve should have a link, he was using it yesterday 😄
00:08:52
Ivan Metrikin:Replying to "Gnosis safe is live ..."
https://app.safe.protofire.io/welcome
00:09:36
Tim Beiko:I think we can debate the testnet scheduling delays separately from deciding whether we want to adopt the mainnet portion of this for Pectra 😄
00:09:52
Danno Ferrin | Ipsilon:Replying to "There were two EOF r..."
31 march is client team opinion. https://ethereum-magicians.org/t/all-core-devs-execution-acde-207/23020/2?u=shemnon 10 april is current scheduled freeze.
March 24 was the last day for PFI, which 7819 made the cut.
00:12:25
Łukasz Rozmej:We kind of doing it now already? This is just writing it down?
00:12:31
Tim Beiko:Replying to "We kind of doing it ..."
Yes!
00:12:36
Fredrik:Replying to "We kind of doing it ..."
yeah
00:12:48
stokes:Strong +1 for this
00:13:18
Enrico Del Fante (tbenr):super welcome a process like that
00:14:06
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7910
00:16:24
Barnabas:Can’t we do REST api instead of JSON rpc? And might as well start pushing for making all EL’s REST compatible.
00:16:45
Danno Ferrin | Ipsilon:Replying to "Can’t we do REST api..."
We can also do this in rest
00:16:55
Luis Pinto | Besu:Why not Fusaka?
00:17:02
Barnabas:Replying to "Can’t we do REST api..."
all new api’s should be rest
00:17:19
Roman:delaying seems reasonable
00:17:34
Roman:While we take the time to argue over the specifics
00:17:35
Barnabas:Replying to "Can’t we do REST api..."
and slowly get clients to implement all their APIs in REST using the same calls kinda like Beacon api
00:17:41
marek:Let's have it in Fusaka
00:18:05
Parithosh Jayanthi:Replying to "Can’t we do REST api..."
We need a fully new rest api spec, one doesn’t exist rn
00:18:25
Barnabas:Replying to "Can’t we do REST api..."
That is my point 😄
00:18:27
Dustin:Anything which requires nontrivial new code seems risky after all the devnets testnets have already happened
00:18:48
Parithosh Jayanthi:Replying to "Can’t we do REST api..."
Yeah but a ideal solution shouldn’t stop us from making incremental progress we can have sooner
00:18:57
Parithosh Jayanthi:Replying to "Can’t we do REST api..."
Fully specced rest api will take months
00:19:39
Łukasz Rozmej:List activated EIP's?
00:20:10
Felix:Replying to "Can’t we do REST ..."
We are working on a REST API proposal at Geth.
00:20:50
Łukasz Rozmej:30 April is fine with me :)
00:20:51
Parithosh Jayanthi:Replying to "Can’t we do REST api..."
Are other clients also involved already? 😄 ideally it isn’t that geth has a new rest api, but that all clients have the same one and there’s no diff
00:20:53
julia:Set a date
00:20:55
Barnabas:happy with 11599872
00:21:36
stokes:Have we checked w/ CL teams on this date?
00:21:52
Barnabas:Replying to "Have we checked w/ C..."
they should be here lol
00:22:03
Tim Beiko:Replying to "Have we checked w/ C..."
I see some CL devs on the call 😄
00:22:49
Enrico Del Fante (tbenr):Don’t we need until we complete attestations analysis and have a completed tests for all flows around maxEB?
00:22:54
Barnabas:end of may seems excessive
00:22:58
Ivan Metrikin:Ether.fi comment https://github.com/ethereum/pm/issues/1374#issuecomment-2752724721
00:23:08
stokes:Replying to "Don’t we need until ..."
Idea is we have time over next few weeks
00:23:18
Parithosh Jayanthi:Replying to "Don’t we need until ..."
Wouldn’t these things be completed over the next week?
00:23:27
Parithosh Jayanthi:Replying to "Don’t we need until ..."
Releases the week after perhaps?
00:23:46
Parithosh Jayanthi:Replying to "Don’t we need until ..."
But yeah, please speak up if that timeline sounds unreasonable
00:24:36
Enrico Del Fante (tbenr):Replying to "Don’t we need until ..."
Ok to set it tentative and discuss next week
00:24:53
stokes:Ship it
00:25:28
nixo:Replying to "Ether.fi comment htt..."
they said they’ll comment on the PR if they have any opinions either way
00:27:56
Felix:Replying to "Can’t we do REST ..."
yeah, it's just a project that we have, to define a new API, like the spec for it. It's not going to be a Geth-only thing!
00:28:00
Francesco:Geth has a very large txpool size. Do you think the size is the problem, or the prioritisation logic?
00:28:33
Hadrien Croubois (OpenZeppelin):Replying to "There were two EOF r..."
So basically in 4 days team must give an opinion on EIPs that did not have an opportunity to present in ACD
00:28:37
Barnabas:Replying to "Can’t we do REST api..."
wen spec for this?
00:30:06
Felix:Replying to "Can’t we do REST ..."
we have done some preliminary research on this, but it's still in progress. We will start pushing for this more seriously after history expiry has shipped.
00:30:25
stokes:https://github.com/ethereum/EIPs/pull/9378
00:30:29
stokes:https://github.com/ethereum/execution-apis/pull/630/files
00:31:09
Will Corcoran:https://efdn.notion.site/DAS-atm-1c2d9895554180ac800fd0b571573483
00:31:15
Will Corcoran:Notes from the breakout
00:31:16
Tim Beiko:Replying to "There were two EOF r..."
We can extend to ACD next week, but every team has stated that they want Fusaka’s scope to be small, and to ship PeeerDAS quickly.
There are ~20 PFI’d EIPs now. I’m not sure if it is possible to actually present all of them on ACD synchronously.
00:32:06
Matt Nelson:Hi folks - we are looking to get EigenLayer deployed in Hoodi as soon as we can. We were waiting on some dependent contracts to be deployed, like SAFE
00:32:16
Tim Beiko:Replying to "Hi folks - we are lo..."
SAFE has been deployed 😄
00:32:20
Gajinder:Only required in network wrapper
00:32:29
Tim Beiko:Replying to "Hi folks - we are lo..."
https://app.safe.protofire.io/welcome
00:32:51
Matt Nelson:Replying to "Hi folks - we are lo…"
🚀🚀🚀
00:32:54
Matt Nelson:Replying to "Hi folks - we are lo…"
I’ll nudge my team today
00:32:55
Roman:Send it
00:35:05
Ben Adams:Nethermind supports Complete version
00:35:51
Ansgar Dietrichs:I think Vitalik’s comment was meant to indicate support for the lighter version in addition to the full version, not as opposition to the full version
00:36:00
Felix:wat
00:36:15
Felix:why did I bring popcorn
00:36:17
Ansgar Dietrichs:option unspecified should be interpreted as support for full version by default, as the others were not even proposed at that point
00:36:34
Kevaundray Wedderburn:Which version is currently implemented?
00:36:36
stokes:Replying to "why did I bring popc..."
We need an ACD chat comment hall of fame
00:36:43
Alex (axic):Replying to "Which version is cur..."
A
00:36:47
Alex (axic):Replying to "Which version is cur..."
The Complete EOF
00:36:48
Ben Adams:Replying to "Which version is cur..."
devnet-0 :)
00:37:04
Danno Ferrin | Ipsilon:Replying to "Which version is cur..."
Devnet 0 which is most of A.
00:37:07
Alex (axic):Replying to "Which version is cur..."
Yeah, to be correct devote-0, but tests are working off option A
00:37:07
Nicolas Consigny:Replying to "why did I bring popc..."
Say no more
00:37:40
Łukasz Rozmej:What is the reasoning why not to ban code introspection?
00:37:49
Luis Pinto | Besu:Replying to "Which version is cur..."
Should not impact the decision though
00:37:52
spencer-tb:Replying to "Which version is cur..."
Cc-ing hive instance, very green: https://hive.ethpandaops.io/eof-devnet-0/index.html
00:38:39
Hadrien Croubois (OpenZeppelin):Replying to "What is the reasonin..."
My understanding is that there are a lot of exisitng practices/standards that cannot work without some sort of contract introspection
00:38:53
William Morriss:this objection is solved by the PAY opcode
00:38:54
Danno Ferrin | Ipsilon:William morris, PAY opcode fixes
00:39:10
Alex (axic):It was not discovered last week, it is a well known TODO item on Solidity. It is just not implemented yet in Solidity, and is not an EVM issue.
00:39:11
Hadrien Croubois (OpenZeppelin):Replying to "What is the reasonin..."
In particular ERC-721 requires checking if some account has code to do stuff conditionnally
00:39:14
Tomasz Stańczak:Easier to add introspections than remove them from EOF, no?
00:39:18
lightclient:option D does still removes gas introspection right though?
00:39:33
lightclient:Replying to "option D does still ..."
so felix is saying he wants gas introspection
00:39:48
Danno Ferrin | Ipsilon:Replying to "option D does still ..."
gas introspection is orthagonal to code introspection, they are not tied to each other
00:39:50
frangio:Replying to "What is the reasonin..."
the solution for this without code introspection has been known for a while now and it is part of the eof proposal
00:39:58
Kamil Śliwak | Solidity:The send/transfer issue was just something that was not blocked off yet in the (incomplete) Soldiity prototype. Not a flaw in EOF itself.
00:40:03
William Morriss:I support removing gas introspection because gas costs should be free to change
00:40:05
Piotr | Ipsilon:Replying to "option D does still ..."
Option D "Introspecting" keeps gas introspection
00:40:07
Hadrien Croubois (OpenZeppelin):Replying to "What is the reasonin..."
If EOF doesn't support that, contract will code "legacy code" to do introspectrion anyway
00:40:14
Tim Beiko:Replying to "option D does still ..."
Lots of double negatives 😅
00:40:26
Piper Merriam:Gas introspection should be removed (in my opinion). It's a major pain point and worth removing. It has big benefits of we get it removed.
00:40:27
lightclient:Replying to "option D does still ..."
okay i understand
00:40:35
Sina Mahmoodi:Removing gas introspection simplifies also gas estimation
00:40:41
Tomasz Stańczak:Replying to "What is the reasonin..."
As in making calls to legacy contracts from inside EOF contracts?
00:40:48
Tomasz Stańczak:Replying to "What is the reasonin..."
Then seems ok?
00:40:53
Tomasz Stańczak:Replying to "What is the reasonin..."
(Or much more costly?)
00:40:55
lightclient:How do you do 4337 when removing gas introspection?
00:41:14
Luis Pinto | Besu:Gas pricing changes are safer without gas introspection
00:41:21
Tim Beiko:Can gas/code introspection be added back in a future fork?
00:41:23
Alex (axic):Replying to "What is the reasonin..."
I actually went through Solady adapting it to EOF, and at least two big patterns it uses with CREATE2 can be done clearly with EOF. I did not go through everything they have because it is a large codebase.
00:41:35
Alex (axic):Replying to "What is the reasonin..."
I.e. non-failing payments and proxy creation.
00:41:35
stokes:Replying to "Can gas/code introsp..."
I think easier to have and then remove later
00:41:43
stokes:Replying to "Can gas/code introsp..."
Vs other way around
00:42:06
Danno Ferrin | Ipsilon:Replying to "Can gas/code introsp..."
It can be restored just by restoring the opcodes.
00:42:19
Tomasz Stańczak:Replying to "Can gas/code introsp..."
Yeah, easier to add back
00:42:29
Danno Ferrin | Ipsilon:Replying to "Can gas/code introsp..."
But if we ship w/ GAS /CALL* opcode we can never remove it
00:42:31
frangio:Replying to "Can gas/code introsp..."
we already have gas introspection and eof is showing that it's not easy to remove
00:42:33
Tomasz Stańczak:Replying to "Can gas/code introsp..."
Alex, explain 😅
00:42:45
Alex (axic):Replying to "What is the reasonin..."
There’s proper lack of language support in the current experimental Solidity version to do everything nicely, but the instructions/features exists in EOF.
00:42:48
stokes:I think im wrong here
00:42:49
Piper Merriam:I feel the same about removal of code introspection, it should be removed. It's another pain point that gets in the way of upgrading things.
00:42:51
William Morriss:address.pay() can replace address.transfer() and address.send() in solidity eof
00:43:31
stokes:Replying to "Can gas/code introsp..."
But intuition is around keeping continuity of model, and then AIUI we can have a new EOF version later with further restrictions
00:43:48
frangio:Replying to "How do you do 4337 w..."
you can't. this is one of the unsolved issues. there is also similar logic like cross-chain messaging contracts where you need to specify a gas limit
00:44:02
Hadrien Croubois (OpenZeppelin):But you can call legacy code from EOF, can't you ?
00:44:05
Ben Adams:Can call legacy; just not delegate call it
00:44:07
Danno Ferrin | Ipsilon:It’s only delegate calling that doesn’t interoperate. Standard calls and static calls work fine.
00:44:26
Tomasz Stańczak:Deploying legacy contracts still possible, so it is not that we lose it?
00:44:30
yoav:Replying to "How do you do 4337 w..."
1. EIP-7701 no longer needs EntryPoint or gas introspection.
2. As long as we need EntryPoint (pre-7701) we can transact with EntryPoint outside of EOF.
00:44:50
Tomasz Stańczak:So the user experience could only get better but not worse? (Except for confusion between choosing the VM type when developing)
00:44:52
Tim Beiko:Replying to "Deploying legacy con..."
Yes, we still maintain the ability to deploy legacy contracts
00:45:04
yoav:Replying to "How do you do 4337 w..."
So basically native AA doesn't need gas introspection and actually benefits from removing it. And non-native remains legacy (non-EOF)
00:45:04
Tim Beiko:One difference @Tomasz Stańczak is we may choose to only ship new features in EOF going forward (but not decided yet)
00:45:25
yoav:Replying to "How do you do 4337 w..."
EntryPoint can still call into accounts that *are* EOF
00:45:28
Mario Vega:Regarding EOF testing I invite everyone to take a look here: https://eest.ethereum.org/main/tests/osaka/eip7692_eof_v1/
This is all tests implemented (so far) by the ipsilon/steel teams, but extra eyes are always welcome on suggestions on missing cases/extra coverage!
00:45:50
lightclient:Replying to "How do you do 4337 w..."
yes true, but there is a intermediate time where you need legacy EntryPoint but all tooling has moved over to EOF
00:46:34
yoav:Replying to "How do you do 4337 w..."
During that period we keep using EntryPoint as a legacy contract which can call EOF accounts. The handleOps transaction itself calls the non-EOF EntryPoint.
00:46:39
Dankrad Feist:I continue to oppose EOF
00:46:58
Dankrad Feist:developer features can be delivered by voluntary binary format
00:46:58
0xTraub:TSTORE/TLOAD is a particularly relevant example of how managing byte code differences on different networks which don’t support it is a huge pain point for solidity devs.
00:47:18
Tomasz Stańczak:Which would be ok?
00:47:21
Dankrad Feist:chain side features will never come to bear because we cannot deprecate legacy
00:48:27
Tim Beiko:1000 lines of consensus critical changes, though
00:48:38
lightclient:it’s 1000 line change with another 1000 or 2 that have already been merged 🙂
00:49:01
stokes:There’s appetite to do something, so we will have some lines of change
00:49:04
frangio:Replying to "chain side features ..."
i don't think it's been settled that legacy can never be deprecated. it's possible there are small additions to eof that enable translating legacy to eof code
00:49:20
Ansgar Dietrichs:one more aspect here: the EVM was pretty ossified over the past few years, but we will start to make bigger changes in the future again, on the path to scaling the L1.
That includes major changes to the gas model. A lot of the “hard coded assumptions around gas” will break at this point anyway. it would be very healthy to have the modern part of the smart contract ecosystem no longer rely on the crutch of gas introspection that we will take away soon anyway
00:49:37
Kevaundray Wedderburn:I didn’t get the point about side stepping — can I still deploy legacy contracts once EOF is live?
00:49:55
lightclient:also should note that we had chain split issue due to identity contract which is very simple 🙂 EOF creates many more interfaces for these types of problems
00:50:00
stokes:Replying to "I didn’t get the poi..."
AFAIK
00:50:07
Dankrad Feist:Replying to "I didn’t get the poi..."
yes
00:50:08
William Morriss:execution being faster is not a reason to block eof
00:50:08
Parithosh Jayanthi:Replying to "I didn’t get the poi..."
Yes you can
00:50:09
Potuz:this doesn't generate more MEV though
00:50:15
Roman:Replying to "this doesn't generat..."
yeeeee
00:50:16
Danno Ferrin | Ipsilon:Replying to "also should note tha..."
Ban precompiles
00:50:22
Tim Beiko:Yeah, this seems beside the point
00:50:26
Dankrad Feist:Replying to "I didn’t get the poi..."
you cannot stop this or you would break existing patterns
00:50:27
Tomasz Stańczak:It is not additional MEV, it is improved efficiency of block building
00:50:27
stokes:Replying to "this doesn't generat..."
right
00:50:31
Roman:Very out of scope for the discussion
00:50:54
Danno Ferrin | Ipsilon:Replying to "also should note tha..."
EIP-7666: EVM-ify the identity precompile
https://eips.ethereum.org/EIPS/eip-7666
00:51:01
0xTraub:Replying to "I didn’t get the poi..."
How so?
00:51:08
Dustin:Replying to "I didn’t get the ..."
In principle, hardforks (conceptually) could stop exactly this. They change existing patterns, that's the point
00:52:48
stokes:I would be curious to hear if we go w/ some variant of EOF today, what would it mean for shipping timelines?
00:52:50
Danno Ferrin | Ipsilon:can I share and talk?
00:52:52
frangio:who is making the case to have code and gas introspection?
00:53:00
Tomasz Stańczak:I think that Complete actually had some support that was maybe not expressed here? @Ben Adams ?
00:53:10
lightclient:Replying to "who is making the ca..."
i think Felix was
00:53:11
lightclient:Replying to "who is making the ca..."
also me
00:53:17
stokes:Replying to "who is making the ca..."
Ya I think many ppl
00:53:24
Piper Merriam:I haven't heard a strong case to add introspection back in
00:53:32
Josh Davis:Link to this doc?
00:53:36
Ansgar Dietrichs:Replying to "I haven't heard a st..."
same
00:53:39
Sina Mahmoodi:Replying to "who is making the ca..."
I think generally contract devs are not super happy to have these “features” taken away
00:53:40
Ben Adams:Nethermind supports A (Complete); has already been stated
00:53:43
Tomasz Stańczak:Replying to "I haven't heard a st..."
same
00:53:48
lightclient:Replying to "I haven't heard a st..."
many contracts use it today
00:53:50
Piotr | Ipsilon:Replying to "Link to this doc?"
https://notes.ethereum.org/@ipsilon/eof_fusaka_options
00:53:51
Tomasz Stańczak:Replying to "I haven't heard a st..."
Just heard Felix mostly on it
00:54:01
Alex Forshtat:Replying to "I didn’t get the poi..."
You can also use a legacy contract to regain some of the functionality banned by the EOF as far as I know, such as excodecopy legacy contracts, observing gas, etc, right?
Not likely any future hard-fork will ever ban EOF-to-legacy calling in my opinion.
00:54:03
Tomasz Stańczak:Replying to "I haven't heard a st..."
These contracts can continue using it
00:54:05
lightclient:Replying to "I haven't heard a st..."
4337 + all user op relaying systems require it
00:54:37
Luis Pinto | Besu:Replying to "Nethermind supports ..."
Besu is also split between A and C
00:54:51
Dustin:Replying to "I didn’t get the ..."
yeah, create a bunch of "gadget" contracts which exist to call now-banned opcodes
00:55:04
Piper Merriam:Replying to "I haven't heard a st..."
But legacy evm still allows 4337 stuff yes?
00:55:06
rodiazet | Ipsilon:If we ban it now it can be reintroduced back without version bump.
00:55:07
Ansgar Dietrichs:Replying to "I haven't heard a st..."
for L1 we always have legacy. any chain that launches EOF-only can find simple ways to add introspection in specific gated ways
00:55:07
frangio:Replying to "I haven't heard a st..."
most contracts that use these features can switch to eof features that achieve the same end effect. 4337 is an extremely special case
00:55:11
pcaversaccio:sorry just joined now: I still have to meet an application dev who asks for EOF. Can someone elaborate here from the core devs?
00:55:36
Tim Beiko:Replying to "sorry just joined no..."
https://soliditylang.org/blog/2025/03/27/the-case-for-eof/
00:55:38
0xTraub:Replying to "sorry just joined no..."
I support EOF
00:55:42
lightclient:Replying to "I haven't heard a st..."
solidity wants to drop support for legacy so how will there be any future development on user op relaying systems
00:55:58
Felix:Replying to "sorry just joined ..."
It's not really the question here. The push for EOF comes from compiler authors and client devs.
00:56:29
Ansgar Dietrichs:I am in favor of A (or no EOF at all)
00:56:41
Justin Florentine (Besu):same. I want A plus PAY
00:56:50
Piper Merriam:Long live full EOF!
00:56:52
pcaversaccio:Replying to "sorry just joined no..."
well should this be the right approach? At the end the consumers are the application layer devs
00:57:09
felix (eest):zoom poll would be spicy
00:57:43
Enrico Del Fante (tbenr):Replying to "zoom poll would be s..."
ZK poll here 🙂
00:57:50
Ahmad Bitar:A plus Pay to go, please 🙏
00:57:55
Ansgar Dietrichs:strong +1 to what Ben and Tim just said, full EOF is the maximally forward compatible version
00:58:08
yoav:Replying to "I haven't heard a st..."
I don't think solidity can safely drop support for legacy contracts, but I also don't understand what you mean by user op relaying system. There's just the EntryPoint contract which is a singleton and already exists. Anything else that handles UserOp (account,paymaster,factory,aggregator) can be an EOF contract that gets called by EntryPoint. Which contract do we need to compile as legacy?
00:58:09
Luis Pinto | Besu:Replying to "sorry just joined no..."
Can we set in stone all of the use cases that are going to break and brainstorm if they cannot be done without introspection?
00:58:41
Tomasz Stańczak:Replying to "sorry just joined no..."
App devs are not affected if they want to continue building legacy way
00:59:00
Justin Florentine (Besu):💯make the call today. if you want a say, be at the table.
00:59:03
Potuz:The discussion has been on ACD for a very very very very long time, I think the community has had more than enough time to analyze it
00:59:08
Justin Florentine (Besu):it's an infinite table
00:59:22
Danno Ferrin | Ipsilon:An infinite garden with an infinite table.
00:59:30
Ansgar Dietrichs:I don’t think we need to keep bikeshedding the versions
00:59:39
Kevaundray Wedderburn:Replying to "I didn’t get the poi..."
I was under the impression that we would also ban new legacy contracts — I guess any gas increases we make to EOF would also be made to the legacy in perpetuity
00:59:41
Ansgar Dietrichs:so if we want to make a decision today, it should be a full decision
01:00:01
Tomasz Stańczak:Let’s commit
01:00:10
stokes:Replying to "I didn’t get the poi..."
Can have different gas schedules, but yeah can’t ignore legacy
01:00:12
Tomasz Stańczak:This is a call dedicated to a big decision
01:00:14
pcaversaccio:Replying to "The discussion has b..."
well this is an issue btw - it takes so much time to dig into this that very few people do this from the community
01:00:26
Danno Ferrin | Ipsilon:That’s a standing requirement for any EIP. Security breakage means fix or pull.
01:00:34
pcaversaccio:Replying to "The discussion has b..."
the issue is that due to the complexity there is a bias who can give feedback
01:00:41
Tomasz Stańczak:Replying to "The discussion has b..."
Core devs can
01:00:43
pcaversaccio:Replying to "The discussion has b..."
it took weeks for me
01:00:46
Justin Florentine (Besu):yeah, we did that throughout pectra
01:00:51
Kevaundray Wedderburn:Replying to "I didn’t get the poi..."
If legacy cost 100 gas and EOF cost 300 gas, wouldn’t I use legacy as a “gadget” in that case?
01:00:55
Justin Florentine (Besu):rough consensus is not a suicide pact
01:01:06
William Morriss:please move PAY to CFI
01:01:19
Tomasz Stańczak:Replying to "The discussion has b..."
They spent 4 years building and analyzing across multiple teams, together with Solidity team, etc
01:01:22
pcaversaccio:Replying to "The discussion has b..."
Core devs are disconnected to some extend to the application layer if you ask me
01:01:24
rodiazet | Ipsilon:lest decide and get back to testing and finalising spec
01:01:24
Potuz:Replying to "The discussion has b..."
I agree, but there's not much that can be done but ossifying if any change to the EVM takes over 4 years to agree on and the community reacts after things have been scheduled after years of active discussions
01:01:25
Roman:Replying to "The discussion has b..."
@pcaversaccio do you wanna speak up since you are informed and haven’t had a chance to? Or do you feel like the post was enough?
01:01:30
Danno Ferrin | Ipsilon:Replying to "rough consensus is n..."
EIP-1057 has entered the chat.
01:01:38
pcaversaccio:Replying to "The discussion has b..."
I'm happy to speal
01:01:39
pcaversaccio:Replying to "The discussion has b..."
speak
01:01:42
Ben Adams:What if EOF is ready and PeerDAS is not?
01:01:48
Danno Ferrin | Ipsilon:Replying to "please move PAY to C..."
Better, SFI
01:01:54
Tomasz Stańczak:Replying to "The discussion has b..."
Some core devs are very close to application layer, it would be a very generalizing statement
01:02:03
Ahmad Bitar:Replying to "What if EOF is ready..."
Thats more likely than people think
01:02:09
Ansgar Dietrichs:Replying to "What if EOF is ready..."
that would be the ideal case. then EOF waits
01:02:11
Luis Pinto | Besu:Replying to "sorry just joined no..."
True, new features won’t land on legacy EOF though I suppose
01:02:12
yoav:Pascal
01:02:21
Potuz:Replying to "The discussion has b..."
FWIW, after studying a bit of it I feel I would also be against inclusion of EOF, however, at this point in time, I feel it's in detriment of Ethereum as a whole to keep bikeshedding
01:02:31
William Morriss:Replying to "What if EOF is ready..."
EOF is quite ready; they have been iterating on it for a while
01:02:33
Roman:Replying to "The discussion has b..."
Agree with @Tomasz Stańczak, that’s not a fair characterization
01:02:34
Danno Ferrin | Ipsilon:Replying to "What if EOF is ready..."
We spend the time testing an fuzzing
01:02:34
Ansgar Dietrichs:Replying to "rough consensus is n..."
a suicide pact is rough consensus though
01:03:03
stokes:Replying to "What if EOF is ready..."
Would love more EL resources on blobs (mempool)
01:03:12
Luis Pinto | Besu:What is complex is for a compiler to go through the current EVM bytecode
01:03:15
Tim Beiko:If we do Option A (with PAY), what is the diff with the current Meta EIP?
https://eips.ethereum.org/EIPS/eip-7607
01:03:16
Ansgar Dietrichs:Replying to "What if EOF is ready..."
yes I don’t expect EOF to miss the fork. just wanted to make sure we are aligned on process here
01:03:24
frangio:it's a very technical EVM change so i dont know to what extent app devs can give feedback
and fwiw i think EOF is really hard to understand in large part because of the split into thousands of EIPs and overall its not well presented
01:03:44
Tim Beiko:Replying to "it's a very technica..."
It used to be a single EIP but then people gave the feedback that it was too long and should be too modular 😄
01:03:45
Tomasz Stańczak:But if it is hard to understand for someone then better not to take a stance instead of advocating against?
01:03:57
Piper Merriam:I'm not sold on general "complexity" fear. I've read the post. Evm itself is also complex.
01:04:24
yoav:Are you against even the minimal version that allows introspection and just adds the container?
01:04:28
Tomasz Stańczak:But same, very appreciated that you did raise these concerns.
01:05:00
Dustin:Replying to "I'm not sold on ge..."
Yes, also, various of the objections were generic "EVM change" objections, it didn't matter which change
01:05:02
pcaversaccio:to be clear I don't want to sound disrespectful
01:05:07
sacha:mteam has a good thread on pushbacks
https://x.com/mteamisloading/status/1900733790873587906
01:05:26
Dankrad Feist:Replying to "sorry just joined no..."
why should we do something that app devs don't need though...
01:05:29
William Morriss:Replying to "it's a very technica..."
modular is much better
01:06:03
Piper Merriam:Also not sold on the suggested alternative approach via iterative change. I think doing it as a single push is a much more effective way to do these changes.
01:06:15
frangio:app devs were bit by gas schedule changes in the past. eof would have prevented that and will prevent that in the future
01:06:34
yoav:Replying to "sorry just joined no..."
@Dankrad Feist it unlocks things that they do want. E.g. native AA (eip-7701). More unlocks to come.
01:06:47
Dustin:Replying to "I'm not sold on ge..."
And especially this narrative of, well, ok, the overall goals are still good, but here's minimal approach to subgoal A, minimal approach to subgoal B, to subgoal C, etc.
That's how EOF evolved -- no one part is that complex on its own (mostly, a couple exceptions), it's a lot of changes all at once
01:07:06
Dankrad Feist:Replying to "sorry just joined no..."
yes I'd be ok with an eof version that implements native aa
01:07:19
Nicolas Consigny:Replying to "But if it is hard to..."
The way I understood it is Pascal says that it's very hard for the average app dev to give feedback due to the complexity. Which is a valid concern and something we can maybe improve (i.e the "disconnect between core devs and app layer"). But Pascal did spend the time and learned all the details to give a thoughtful feedback (shoutout to him for doing so).
01:07:19
Ansgar Dietrichs:+1 to normalizing shipping cutoff
01:07:25
Dankrad Feist:Replying to "sorry just joined no..."
but any version that doesn't seems like complexity with low benefit
01:07:28
yoav:Replying to "sorry just joined no..."
@pcaversaccio what's your opinion of the minimal EOF version that doesn't remove things like introspection?
01:07:39
Guillaume:I disagree, a lot of unnecessary things are just shipped because people, including core devs, don't understand the implications and remain silent. The burden of proof is on the EIP champion.
01:08:11
pcaversaccio:Replying to "sorry just joined no..."
Let me get back to you on this later - need to read this properly
01:08:20
Nicolas Consigny:Replying to "But if it is hard to..."
Disagree on which part ?
01:08:23
yoav:Replying to "sorry just joined no..."
> yes I'd be ok with an eof version that implements native aa
AA is not an EOF feature, but a feature built upon EOF. EOF is not a feature but scaffolds that enable many things in future forks
01:08:31
Dustin:Replying to "I'm not sold on ge..."
And I'm 100% unconvinced that people who just this week are discovering this (not necessarily the author of some of these posts) this month won't make a lot of the same mistakes and evolve a lot of the same quirks the various EOF EIPs have
01:08:37
Guillaume:Replying to "But if it is hard to..."
that you should remain silent if you feel a change is hard to understand
01:08:52
Nicolas Consigny:Replying to "But if it is hard to..."
Agreed 🤝
01:08:54
stokes:Now we turn to shipping
01:09:01
Dankrad Feist:Replying to "sorry just joined no..."
right but in the sense of having version, eof is already shipped
01:09:14
Dankrad Feist:Replying to "sorry just joined no..."
versioning*
01:09:35
Dankrad Feist:Replying to "sorry just joined no..."
my argument is that we should only have versions that add major features
01:09:39
pcaversaccio:Replying to "sorry just joined no..."
verkle tree EIP has versioning as well btw
01:09:41
Ansgar Dietrichs:+1 to modexp raise cfi, seems super uncontroversial
01:10:24
Francis Li:Would love to include https://eips.ethereum.org/EIPS/eip-7892 as well, it's BPO, and requires minimal change with PoC already done
01:10:32
Ansgar Dietrichs:acd process halted for 4 weeks while geth looks into blog providers
01:10:46
Tomasz Stańczak:Replying to "But if it is hard to..."
Yeah, do not remain silent, that was not the intention behind the sentence. Asking lots of questions - desired. Advocating against seems a bit more opinionated that ideally would stem from better understanding. But I can also see the argument that someone was not given enough time. But here we hear that from the 4 years process only a few weeks were used.
01:11:11
Potuz:ohh crap
01:11:19
Barnabas:Replying to "ohh crap"
micdao
01:11:22
Tomasz Stańczak:Replying to "But if it is hard to..."
There will be always someone in the community who has not had enough time yet to analyze an d understand in details
01:11:52
Tim Beiko:https://eips.ethereum.org/EIPS/eip-7607#proposed-for-inclusion
01:12:00
Potuz:Replying to "ohh crap"
yeah
01:12:05
Potuz:Replying to "ohh crap"
Fixed it hopefully
01:12:09
Tim Beiko:https://github.com/ethereum/EIPs/pull/9528
01:12:13
Tim Beiko:https://github.com/ethereum/EIPs/pull/9451
01:12:41
Ansgar Dietrichs:Replying to "But if it is hard to..."
a meta problem is that we are not good at resolving conflicts for in-work EIPs before they reach this acd inclusion discussion stage, at which point they are already time sensitive.
see e.g. ePBS, Verkle, …
01:13:03
Sophia Gold:Scope for time!
01:13:09
spencer-tb:If we stick to PeerDAS + EOF (opt. A with PAY), I’d rather not add anything else on the EL. Smaller fork is safer fork.
01:13:37
Ansgar Dietrichs:ideally peerdas before devconnect tbh
01:13:46
Justin Florentine (Besu):not even r1 curve 🧌
01:14:03
Ansgar Dietrichs:Replying to "If we stick to PeerD..."
I think small changes might still be fine, but yes, should be very limited
01:14:03
Tomasz Stańczak:Very much the community ask
01:14:04
Shoham Chakraborty:Replying to "not even r1 curve 🧌"
We need the r1 curve
01:14:42
kasey (fnord):Replying to "But if it is hard to…"
An idea I’ve shared with a few people is to build a look ahead into the acd process. Separate quick presentation of a topic from more in depth discussion. So at the end of each call, have 5 minute slots where people explain what they want to talk about on the next call and direct everyone to the eth pm gh issue for that next call to discuss further. Arrange these calls more explicitly around the eth pm github issues, so we do more of the discussion and basic question asking async, and only use these calls to resolve informed contention.
01:14:44
spencer-tb:Replying to "If we stick to PeerD..."
Okay for small changes if its not big on testing complexity
01:14:55
Ansgar Dietrichs:r1 is CFI, no?
01:15:08
Barnabas:anyone working on r1, any client impl ready?
01:15:08
Guillaume:Replying to "If we stick to PeerD..."
I know where this is going ...
01:15:24
Ansgar Dietrichs:Replying to "anyone working on r1..."
is it not already in geth?
01:15:31
Parithosh Jayanthi:Replying to "anyone working on r1..."
Its on op-geth
01:15:33
Parithosh Jayanthi:Replying to "anyone working on r1..."
Not geht
01:15:38
Ansgar Dietrichs:Replying to "anyone working on r1..."
ah, makes sense
01:15:49
Ansgar Dietrichs:Replying to "anyone working on r1..."
but also, I think I remember some concerns around some small details, return value and gas price
01:16:01
Ansgar Dietrichs:Replying to "anyone working on r1..."
not sure if these have been addressed yet
01:16:34
rodiazet | Ipsilon:ipsilon plans to have C++ implementation
01:17:08
Andrew Ashikhmin:Replying to "anyone working on r1..."
Erigon has it (and it’s live on Polygon)
01:17:44
Potuz:what does it mean "from scratch"?
01:18:19
Piper Merriam:Which CL clients are not currently ready for this?
01:18:59
Gajinder:Shouldn't be an issue for lodestar post pectra transition is complete for deposits with ofcourse checkpoint sync onwards that point
01:19:28
Dustin:Post 6110 it would violate specs, more or less
01:19:39
marek:We tested this internally and confirmed with (all?) CL clients that they are ready for history expiry. However, it would still be good to double-check.
01:19:41
James He:I think we have an issue ( prysm)
01:19:52
marek:Replying to "We tested this inter..."
of course, after Pectra - sepolia
01:19:56
James He:At least it will print an error*
01:20:17
Dustin:Just wait for 6110, it resolves all
01:20:23
Dustin:before, it's messy
01:20:37
Dustin:there's a transition period
01:20:38
marek:can we drop pre-merge history for sepolia?
01:20:46
stokes:Ah yes, that is a small but important detail
01:20:46
Tim Beiko:Heh we said we’d drop history on May 1st: if we keep our April 30th mainnet date, we’re good :tong
01:20:50
Tim Beiko:Replying to "Ah yes, that is a sm..."
yes
01:21:03
Parithosh Jayanthi:Replying to "can we drop pre-merg..."
Yes, huge fan of doing history expiry on the testnet first
01:21:12
Tim Beiko:Replying to "can we drop pre-merg..."
I think it would be pretty reckless not to
01:21:13
Potuz:just days max
01:21:27
Dustin:meh
01:21:31
Dustin:enough with "Target dates"
01:21:31
Dustin:etc
01:21:35
Dustin:wait for 6110 transition
01:21:40
Dustin:just wait for it
01:21:42
marek:Replying to "can we drop pre-merg..."
yeah, but I am wondering if we have any blocking issues
01:21:46
Parithosh Jayanthi:Why not set a date for sepolia now, then do it on mainnet after
01:22:15
Mikhail Kalinin:it is hours to cover the gap and to deprecate eth1data poll, not days
01:22:27
Barnabas:could we not do it before mainnet fork?
01:22:35
Mikhail Kalinin:Replying to "it is hours to cover..."
*depends on when the first 6110 deposit is submitted
01:22:52
Potuz:I agree with Piper
01:22:59
marek:Replying to "Why not set a date f..."
yes, let's agree on a date for sepolia now
01:23:02
Potuz:we can probably schedule something conservative now
01:23:07
stokes:Does provisional 4 weeks timeline work?
01:23:08
Potuz:and we can delay it beacuse it's cheap
01:23:14
Potuz:yes
01:23:53
Barnabas:we don’t need to schedule this tho?
01:24:04
Gajinder:Replying to "Does provisional 4 w..."
Makes sense to me
01:24:10
Barnabas:lets just roll it out asap
01:24:18
marek:yes, we just need a green light for ELs to drop history
01:24:23
Tim Beiko:We only have 5m left, I feel like we should move this to a breakout?
01:24:25
Dustin:+1 to Felix
01:24:31
Tim Beiko:But the plan seems a bit half-baked right now 😅
01:24:41
stokes:Replying to "But the plan seems a..."
Is it?
01:24:44
stokes:Replying to "But the plan seems a..."
Sepolia may 1st
01:24:47
Dustin:Replying to "But the plan seems..."
howso
01:24:52
stokes:Replying to "But the plan seems a..."
Provisionally say mainnet 4 weeks after pectra on mainnet
01:24:57
Tim Beiko:Replying to "But the plan seems a..."
Did we agree to this?
01:25:02
Dustin:Replying to "But the plan seems..."
yes
01:25:10
stokes:Replying to "But the plan seems a..."
Not explicitly but it is consistent w/ what has been said
01:25:13
Tim Beiko:Replying to "But the plan seems a..."
Ok then! Wasn’t super clear to me
01:25:26
Dustin:Replying to "But the plan seems..."
Bangkok L1 R&D discussions, and Portal Summit
01:25:36
Matilda Clerke:I thought the idea was that eth/69 signals that a node may not have the full block history? i.e. An eth/68 node is expected to have full block history.
01:26:03
Tim Beiko:Replying to "But the plan seems a..."
It would be nice to have a canonical place to document this 😄
01:26:12
Dustin:Replying to "I thought the idea..."
Part of EIP-4444 redefines this
01:26:31
Dustin:Replying to "I thought the idea..."
That expectation disappears
01:26:43
Dustin:Replying to "But the plan seems..."
Agree
01:27:20
Gajinder:A info EIP added to fusaka meta
01:27:26
Matilda Clerke:Replying to "I thought the idea w..."
ok, I'll revisit the EIP
01:27:37
Piper Merriam:Agreed
01:27:41
Piper Merriam:Yes
01:28:43
Ansgar Dietrichs:link to research call announcement: https://ethereum-magicians.org/t/protocol-research-call/23261
01:29:04
Ansgar Dietrichs:Replying to "link to research cal..."
hope to see some of you all there!
01:29:22
Tim Beiko:https://ethereum-magicians.org/t/testnet-name-needed-for-sepolia-replacement/23221
01:29:31
Potuz:history expiry: I think we can
- Mainnet: agree right now that it will be dropped 4 weeks after Pectra and that's it, roll back this if there are problems Sepolia or too many deposits.
- Sepolia, I'd say clients can start dropping now if they want to.
01:29:38
Potuz:it' s preferrable than to wait to test
01:29:51
Ansgar Dietrichs:I maintain that all acd naming decisions should be auctioned off onchain
01:30:02
Maintainer.eth:Thank you all, gm. 👋
01:30:05
Tim Beiko:Replying to "I maintain that all ..."
I had a devcon talk about that!
01:30:07
Danno Ferrin | Ipsilon:Replying to "I maintain that all ..."
With suitable veto rights.