AllCoreDevs - Execution #213

|2025-06-05| Agenda: #1565| canonical JSON

Transcript

Tim Beiko:Okay, thank you. Welcome to acde number 2 13.

Tim Beiko:I've posted a link to the agenda in the chat here.

Tim Beiko:couple of things to discuss today. So on the Fussaka front. There are a few things that came out of the testing call that

Tim Beiko:we should touch on so around the gas limit, and then some bon xp questions. Then for the finalization of the scope we discussed

Tim Beiko:making some changes to rip 7, 2, 1, 2, last call which are in progress, and then wanted to finalize the set of list. The set of eips for that 2. So do those. And then

Tim Beiko:continuing from last week we started discussing potential headliners for Amsterdam. So there were a few El related ones that had been proposed

Tim Beiko:that we we should cover there are also other eips that have started to be proposed, I think.

Tim Beiko:We probably shouldn't take

Tim Beiko:time on the call to discuss them unless anyone feels very strongly about it. But it's probably best to to stay focused on the the actual fork headliners for now

Tim Beiko:And then, just as a heads up as well the next week, because of the in person meetings we'll cancel the calls, and I will be out in 2 weeks, and Onstar will be taking over for Acbe

Tim Beiko:but just to kick things off. So on acd Monday there was a discussion about raising the gas limit,

Tim Beiko:and and kind of testing it on 60 million on Hoodie, and then moving to Mainnet and after that I know there's some follow up conversations about like what the right approach should be to actually increase it? And are there things we want to see or or like potential blockers there? So if someone might want to recap kind of the

Tim Beiko:the outcome. That discussion, and what the open questions were about, like actually moving forward with this on Mainnet.

Parithosh Jayanthi:Yeah, I can give a brief update. So on Monday, on Acd, we asked client teams if they saw any other blockers before we started to signal raising the gas limit on

Parithosh Jayanthi:on Mainnet for 60 million.

Parithosh Jayanthi:However, I mean in the last couple of days. I think once we started planning for Bell interrupt. We realized that we're going to be doing a lot of work on gas limit performance testing, anyway. So in in my opinion, we probably should wait to make a decision until that track is done, and by the end of next week we'll have a better idea about what our scaling limits are what? We? We would have a few more eyes from from

Parithosh Jayanthi:on the gas limit, from a security perspective, and so on, and then probably the acdt. The week after we can make a call on how we want to increase the gas limit.

Tim Beiko:And there's a question in the chat. Yeah, about

Tim Beiko:the intention around either jumping to 60 million straights or having some intermediate steps so I don't know if

Tim Beiko:yeah, is that basically what we're hoping to figure out in the next week or so.

Parithosh Jayanthi:Yeah, I think that would be one of the discussion points. I don't really see any problem with doing intermediate steps other than coordination overhead. I think it takes us quite a bit of time to

Parithosh Jayanthi:go through the gas limit increase process. So yeah, I think we should try to prevent as many steps as possible, but at the same time not have the steps too granular.

Tim Beiko:Thanks.

Tim Beiko:Anyone else. Have thoughts, comments on this.

Tim Beiko:Yeah, Micah.

Micah Zoltu:So the testing team appears to have done a great job of digging into digging very deeply into whether or not stakers will run into problems with the high gas limit which I think again, I want to

Micah Zoltu:acknowledge that excellent work. But I still haven't seen any research or discussion into how the gas limit affects other participants in the ethereum network. It seems everybody's focused on stakers and builders, and no one has even talked about Rpc. Providers, or, even more importantly, in my opinion, people who are running their own local Rpc. Clients, and how this affects them. I think

Micah Zoltu:the

Micah Zoltu:storage issue affects those people far more than affects people who are paid providers, and these are end users who, you know, hopefully, are running ethereum on their home computers. I've talked to a handful of people just ethereum developers across the ecosystem over the last few weeks.

Micah Zoltu:and there seems to be a lot of divergence in whether or not. We care whether people can run ethereum at home. There's some people, you know. Dankratt is very forward with this, and I very much appreciate how candid he is where he says, you know, he doesn't think that

Micah Zoltu:ethereum needs to be a tool that people can run on their computers at home, and that's acceptable. And there are other people in the developer community who seem to think that they should be able to run clients on home computers. And so it seems like there is a

Micah Zoltu:a mismatch between. Whether who we're targeting? Do we care? The question I would like to see answered very clearly is, does do the ethereum core devs. And as a group

Micah Zoltu:want people to be able to run ethereum at home on their just home computers? Or is that something that we're no longer targeting. It used to be a target back in the day.

Micah Zoltu:And there's again some subset that don't think it's a target anymore. And these gas limit changes will affect that. And so I would just like to see more discussion and research into how this affects people. Besides stakers and block builders.

Tim Beiko:So I guess like, yes, there's a there's a difference between

Tim Beiko:stakers. Block builders are just like node operators who want to validate the chain running at home versus running a full on Rpc service, which is by definition, like resource, more resource, intensive.

Tim Beiko:we had, I don't know. Like, yeah, I was gonna post in the chat. We have this eip that attempted to define some of these constraints eip 7, 8 70 and I think throughout this discussion, like A did not come up, that, like we should optimize for home. Rpc providers,

Tim Beiko:and so I I feel like this is probably the right

Tim Beiko:like I don't know distillation in a way of the opinion like we should serve like people running their local node. Obviously, you need to be able to make local Rpc calls to that node. But I think when you start to go into like running a kind of high usage

Tim Beiko:endpoints that's potentially used by others that feels like

Tim Beiko:like like that that feels like a comp like a qualitatively different thing.

Micah Zoltu:Yes, it definitely does the we.

Micah Zoltu:the there's there's 3 or 4 different demographics, right? You've got the block builders you've got, which.

Micah Zoltu:based on the research roadmap sounds like block builders are expecting to be super high end data center type hardware, you know, doing zk proofs. Yada, Yada, Yada, you have validators. Who are. We still want to support home quote unquote home stakers. These are people who, you know, can put a lot of money into building machines and whatnot. And they have hardware, but maybe not a data center. And then you have Rpc providers again, probably data centers. And the the last group is the group. Again. It used to be a group of people who

Micah Zoltu:existed and dominated the ethereum ecosystem and have basically disappeared as anchor had mentioned in chat here, which is people who just run ethereum on their home computers. They do not buy extra hardware. They do not go to the store. They do not.

Tim Beiko:Right.

Micah Zoltu:Spend a lot of time thinking about ethereum. They just double, click an installer, run it and it runs in the background. Baysu has a thing in their client where you can run a flat database. This is a somewhat trusted system, though it could be made trustless with some additional R&D, and this runs in, I think they said 50 or sorry. 80 GB ish right now for the full state.

Micah Zoltu:and so in under 100 GB. You can run an ethereum node today, and with additional R&D work from ethereum core devs. We could make that possible in a trustless way

Micah Zoltu:as we increase the gas limit that increases the rate at which that 80 GB grows. Now, we're not talking about 80 GB plus 3 GB a month. We're talking about 80 GB plus 6 GB a month, and that adds up real quick. And so yes, 3 GB a month of state growth. You're looking at one or 2 TB is not much. When you're looking at 80 GB, it's a very significant increase. And so that's the group that

Micah Zoltu:yeah, I really feel like, you know, if we're going to just cut them out, we need to make that clear that we're doing that.

Tim Beiko:I do think like, yes, I do think this is kind of clear in 78 70, like, basically, this is a effectively like, just like a non staking

Tim Beiko:like node and like, or like a full node, basically like and I think it's been

Tim Beiko:pretty clear in the past few years. That like, yeah, the the Median way to run this requires extra hardware. It should be consumer grade hardware. And it should be basically, you know, not

Tim Beiko:like, like, I'm not out of reach for people to do this, but I don't think. I guess I think we've passed the point of saying.

Tim Beiko:we can optimize this for effectively, you know, like a couple of 100 gigs of storage and nothing else.

Tim Beiko:some client implementations might be able to help with this. But

Tim Beiko:but yeah, like, it's, it's definitely not like the median.

Tim Beiko:yeah, the the median approach.

Tim Beiko:I guess. Yeah. Okay, odds are. And then, yeah, let's do that.

Ansgar Dietrichs:Yeah, I just wanted to say that, like, I think one way in which maybe I think many people at least have expressed in the past. The intention to change a little bit. How we do things in ethereum is maybe that we want to still like continue to take these concerns very seriously, because obviously this is crucial to the core of ethereum that we actually get this right kind of this trade-off and really understand the costs of scaling, and when that is acceptable and when it isn't, but that we stop doing it. The way where we always basically 1st get blocked on like

Ansgar Dietrichs:7 rounds of conversations before we have exact agreement, and only then make any moves, because then, in the meantime, the experience for actual users is just really really bad. So I, personally would just say that the the basically the process here of saying over the next 2 weeks, with the in person, events and everything. We basically make initial decisions for the short term. And we're only talking about at most, 1 point, something X increase right? Like 60 million is not even double today's level

Ansgar Dietrichs:and then going forward, we will have a process. And I think, Mike, I'm happy to to reach out and and have you been involved in this, where we we will also, over time, become more precise in the, in distinguishing between different types of nodes, including Rpc. Notes explicitly, so that we actually have a fundamental basis. And then we can still have the conversation

Ansgar Dietrichs:which assumptions to use. There was not used there. But I think, basically, for now we should still move forward with this process and not be blocked for 6 months while we have that discussion.

Tim Beiko:It's Dunker.

Dankrad Feist:Yeah, I mean, I think, like, when I hear these discussions, I often just feel like it's really disconnected from reality, like, I mean, I think, like

Dankrad Feist:the we're still thinking about ethereum as if it were 2050. And it's like people want to run like a home like this this node at home that has all these properties. But, like the Median ethereum user now, is so far away from that that's pretending that we still get the same

Dankrad Feist:like we still operate in the same space and still get the same benefits, is like

Dankrad Feist:not very reasonable to me, like, I think, like in practice, we, we know exactly like most of us know exactly what normal ethereum users do, and yet we keep designing for something completely different. And I think, like we need to move away from that and like, be like, well, this is what is really happening. And like.

Dankrad Feist:we want to get the Median ethereum users. The best properties that we can, rather than like a small set of like people who like

Dankrad Feist:do something very different from that.

lightclient:Lukesh.

Łukasz Rozmej:So I'm somewhere in the middle. So I agree with that we should be able to run ethereum nodes on standard consumer hardware, and we can.

Łukasz Rozmej:And if you need to buy a SSD. If you want the full history from Genesis.

Łukasz Rozmej:it's also fine, and if you need some decent connection to keep up with the network. And it's also fine. If as long as it's reasonable and available in a in a lot of locations, it's

Łukasz Rozmej:so. Yeah, I don't see a problem. You can build blocks with Nevermind and not only Nevermind, probably a few 100 Megabogas blocks. You can process them. You can store them relatively easily with newer architectures like Arygon free. Even archive node

Łukasz Rozmej:is somewhat reasonable, but it's also fine for us to say if you want that. By a SSD, right? It's technical limitation. We would love not to have that. But it's fine. I do agree that we should maybe focus a bit more on eap 4 force, and having it post merge pruning of that

Łukasz Rozmej:to to help with that. But that's about it.

Tim Beiko:Thanks. So I guess,

Tim Beiko:like, yeah. The the main thing I wanted to revisit today was like, yeah, whether we were okay, just

Tim Beiko:whether we were okay, just moving forward with 60 million on main net as of now, it does seem like there's more data that we wanna collect, at least in the next couple of weeks, we should we should figure out the like, yeah.

Tim Beiko:what what? What like the the requirements are, whether we want to do a 1 off like bump to 60 million, or to be more gradual. And I expect in like

Tim Beiko:2 weeks or so we'll we'll have a bit better of a an answer there.

Tim Beiko:And yeah, Marson.

Marcin Sobczak:Yeah, I would like just to add that on recommended specification from 7, 8, 7 0.

Marcin Sobczak:If we are running tests on it, and there are, like the the worst scenario is performing at about at about 20 megas per second. So we need to be conscious

Marcin Sobczak:that there will be a possibility to craft a block which will take 3 seconds about 3 seconds to process on 60 megas or 60 mega cut limit. I'm not saying that it's a blocker, but we just need to be to be conscious about that.

Tim Beiko:Yeah.

Tim Beiko:okay, so I do, wanna

Tim Beiko:move on for now, because, yeah, we could probably spend the next 90 min talking about this.

Tim Beiko:But yes, let's follow up on this in the next 2 weeks.

Tim Beiko:and then do we have. There is a discord channel gas limit testing. So we should use that to to actually talk about like,

Tim Beiko:yeah, what what the constraints are and how we're addressing them, or next week's.

Tim Beiko:I guess. Okay. So following up there were 2

Tim Beiko:minor update or updates to at least some of the the fussaka eips 1st off Powell had a had an update to 7, 8, 8, 3 that he wanted to discuss.

Tim Beiko:yeah, I don't know if you're on the call, Powell.

Marcin Sobczak:Yeah. So I can give you some insights about that.

Marcin Sobczak:because it was in touch with Pavel about that. This Apa is proposing. This Pl. Is proposing 2 changes. We already agreed with Pavel that one of them will be withdrawn.

Marcin Sobczak:So it is proposing to to not increase the mean price from 200 to 500. But it's opening the doors for for some case scenarios which we don't want to have, so it will be. It will be reverted, so we'll be keep increasing it from 200 to 500.

Marcin Sobczak:And like right now, in 7, 8, 8, 3, there are 3 small tenders in the code, and this will add the 4th one

Marcin Sobczak:so for on on real network, base and model are always have 22 Byte or more, but in theoretical scenarios which we can like craft to to be worst case setup scenarios, etc. We can craft

Marcin Sobczak:modex usages with with smaller amount of bytes for for base and modulla, and hmm

Marcin Sobczak:it. The the spr is in increase increasing gas price like we we are. We are counting price. If it is 52 Byte, even if it's smaller, thanks to that. like, we will

Marcin Sobczak:cover some at case scenario at case scenarios, and they will have 0 impact on on common cases on my net. So it's a clear win. And yes, I'm I'm I would like to to add this this 4th change to to this.

Tim Beiko:Thanks. Has anyone else had the time to review this or or comments on it?

Tim Beiko:Okay, otherwise. Yeah, let's have people review this Async and try to make a decision in the next week or so.

Tim Beiko:next up so on the last call we discussed some issues with rip 7, 2, 1, 2 needed to be addressed and that led to kind of a a change in the spec. So we opted to effectively write a new eip that provides basically the same functionality. But that addresses these issues. Carl has been working on that. And I'll call, are you on the call.

Carl Beekhuizen:Yeah, Hi, yeah. So I mean a few things. Basically, why do we want this?

Carl Beekhuizen:It's like the most ubiquitous signature scheme across the web. And most modern tooling stacks like it's basically the sha-two 56 of the signature world.

Carl Beekhuizen:Like defaults in Tls or Ssh for Vpns. It's like massive, but the main gain that we care about here is that, like it is the signatures that's used like embedded in most hardware, so like android key stores apple secure Enclave Ub keys.

Carl Beekhuizen:Anyway, we can use a passkey you could. You would now be able to just sign

Carl Beekhuizen:so that means we could like switch to a model where you just sign transactions with face id or fingerprints, or whatever works for you.

Carl Beekhuizen:So I think really massive. Ux unlocks.

Carl Beekhuizen:This exists in the form of Rip 7, 2, 1, 2, deployed across many of the L twos at the moment, as I mentioned previously on here before we had a small bug in 7, 2, 1, 2, which, like basically had undefined behavior and a degenerate edge case.

Carl Beekhuizen:And so we kind of needed a a new spec for that. This

Carl Beekhuizen:eip, 79, 51 is identical from an interface standpoint. So from within the Evm, you can't, you definitely won't be able to tell the difference. But we just patch this one edge case and have

Carl Beekhuizen:extensive tests for it.

Carl Beekhuizen:So that's I think, something we should really consider. Consider having in this fork.

Carl Beekhuizen:we had bls in the previous fork, and I think everyone can. Everyone's a little jaded. After that I totally understand that this is a much simpler cryptographic eip.

Carl Beekhuizen:so it only has one interface slash entry point versus bls, which had 9, I believe

Carl Beekhuizen:And the there's only like internally, cryptographically, there's only like one group where the whole Bls thing has 3, and they all interrelate and weird in wonderful ways.

Carl Beekhuizen:Because it is so ubiquitous. There are just many libraries that have it, and

Carl Beekhuizen:this eip matches the interface of all those libraries. So we don't use Ec recover like we do for the k 1 curve we use just verify as the interface again, just because that matches all the existing libraries. So it should just be plug and play

Carl Beekhuizen:and, unlike the Bls things, we already have extensive tests. Before we wanted to do this, I think there are 780 odd tests in this this new version of the Eip.

Carl Beekhuizen:So I think it's in a really solid place and ready to ship, and something that from Ux standpoint would be fantastic if we can. We can just have in there.

Carl Beekhuizen:As far as I'm concerned, the Major, unknown is just gas cost benchmarking. There's a

Carl Beekhuizen:number in there now which matches rip 7, 2, 1, 2,

Carl Beekhuizen:my intuition is, was probably a little on the cheaper side.

Carl Beekhuizen:But

Carl Beekhuizen:yeah, I think we should like we, we should basically just need to implement those in clients and see where that would would

Carl Beekhuizen:see how much that costs relative to other things, and then we can we can get that.

Tim Beiko:Right? Yeah. Thanks for for sharing. And so I guess yeah, there's 2

Tim Beiko:like decisions here. The first, st it's just like, Are we okay, swapping out, rip 71, 2 for this.

Tim Beiko:It seems like.

Tim Beiko:yeah, we we obviously should. And then I think, next, item is just what do we want to include in definite, too? So I feel like we should make the decisions about the Devnet as a whole rather than just 7, 2, 1, 2, or not.

Tim Beiko:so.

Tim Beiko:But yeah, before we do that, just like, does anyone have any concerns swapping? 7, 2, 1, 2 with 7, 9, 5, 1.

Tim Beiko:Otherwise we could just do this after the call.

Tim Beiko:And then, okay, so assuming there's no concerns,

Tim Beiko:basically on on the last call we had sfi, a bunch of vips for the definite one spec. Devnet one is not live yet. However, we did want to finalize the potential list for definite 2 today, meaning that like assuming that that one goes well, this is what we'd add in definit 2 and then finalize the scope for Fusaka

Tim Beiko:finalize the scope for Fusaka so the 4 eips we still had.

Tim Beiko:In the Cfi list, where the payoff code 7, 2, 1, 2, which is now being replaced by 7, 9, 5, 1 7, 9 0, 7 and 7, 9, 3, 4.

Tim Beiko:I guess. Yes, I would like to hear from client teams. Like which of these should we prioritize for Devnet 2. And then, I think, what doesn't get included for definite 2, we would probably just decline for inclusion now and leave the rest. And Cfi once we've so once we've shipped that this one, we can move move the the rest.

Tim Beiko:But

Tim Beiko:and so, Gabriel, to your question, like so far nothing has been confirmed for Government 2 and we want to figure out of

Tim Beiko:the set of vips we already have set for that. f 1. What do we want to

Tim Beiko:add? In addition to this,

Tim Beiko:and I can post. I'll post the full list of vips for devnet one in the chat.

Tim Beiko:Now. So this is what we had in the event. One.

Tim Beiko:Yeah, yeah, Ben.

Ben Adams:So the 7, 7, 2, 1, 2 replacement.

Ben Adams:Block execution size.

Ben Adams:I'm living on pay fine with that.

Ben Adams:The meter contract size still needs work.

Ben Adams:So would be against that. But

Ben Adams:potentially, we could just do in the interim,

Ben Adams:like 50% on the on the contract sizes.

Tim Beiko:Okay. So so sorry. That was 7, 2, 1, 2. And then what was the other one? Sorry you said I

Tim Beiko:just wanna make sure I got it right.

Ben Adams:7, 9, 3, 4.

Tim Beiko:Okay. The okay, yeah.

Ben Adams:But yeah, but 7, 7, 9

Ben Adams:o, 7 still needs a bit of work.

Ben Adams:and would be willing to to swap that for Fusaka, for like a 50%

Ben Adams:bump in size, and then look at doing the full eip for Amsterdam.

Tim Beiko:Got it. Thanks.

Tim Beiko:Andrew.

Andrew Ashikhmin:So I agree with Ben. It's the should be the r 1 precompile and the rop execution block size limit.

Andrew Ashikhmin:I I, personally don't have a strong view on on the increase limit, Eip. As to the pay OP. Code, I think

Andrew Ashikhmin:it. It has some implications to the tooling, and it's it's not trivial. So if we decide to do it, I would rather do it early in in Glamsterdam, so we have more time to think about it and test it so I wouldn't do it this late in in Fussaka.

Tim Beiko:Okay.

Tim Beiko:Anyone from Beisu or Geth.

Marius:I put my personal opinion on the chat already. I like 7, 2, 1, 2, and 7, 9, 3, 4.

Marius:I don't mind the others, but I also don't really need to push for them at this moment.

Marius:Okay, and.

Tim Beiko:And then, yeah, Gabriel, you're being put on the spot for basic.

Justin Florentine (Besu):If he's not near a mic, I think.

Justin Florentine (Besu):we don't really have a strong opinion. We published our earlier things. I think the pay. OP. Code is good. We'd like to see that included.

Tim Beiko:Oh, okay. Marius.

Marius:And this is actually just thought maybe I should give, because, Mario said he has his personal opinion.

Marius:So I do think that, like from my point of view, the 7, 2, 1, 2 is pretty important to ship like this has been sitting for so long, and it's kind of a small one. So we should just we should have this

Marius:and the 7, 9, 3, 4 for me, also pretty important one, just to basically be able to

Marius:constrained the other ones. I have less than a routine. But opinion about but I know that the 7, 7, 9 0, 7

Marius:is pretty important for the community as well. So I would say, like, if we can pull off, then it's probably also something good.

Tim Beiko:Thanks.

Tim Beiko:Yeah. Roman.

Roman:But this is a response to Felix. I would recommend to catch up on some manners and thread which I was unable to do. Yet

Roman:there was basically a long discussion on on the implications.

Roman:And I posted the comment earlier in the chat as well, that we're for 7, 2, 1, 2, and 7, 9, 3, 4,

Roman:and we're generally supportive of 7, 9 0. 7.

Roman:But given the extensive discussion, I cannot

Roman:give opinion right now, because I have not caught up yet.

Ben Adams:To to be effective. The 7 9 0, 7 really needs a change in the

Ben Adams:database structures of the El client. And

Ben Adams:it's a bit close to Fusaka.

Ben Adams:In terms of you know where we are in the devnets and things. If it was like at the start, I I would say it's fine.

Ben Adams:It seems a bit too much at this stage.

Tim Beiko:Okay, so I guess if 7, 9 0 7 is gonna be too complicated. Then this is

Tim Beiko:like, yeah, the last of net that we want. It seems like 7, 2, 1, 2, 7, 9, 3, 4 are pretty much supported by by everyone.

Tim Beiko:So I would keep those, hey?

Tim Beiko:And and then like yes, should we

Tim Beiko:decline effectively? 7, 9, 0, 7.

Tim Beiko:And I would also lean towards declining. 5, 9, 2. 0. Because it seems like it has pretty mixed support.

Tim Beiko:and also like, had some unintuitive implications. Okay.

Ben Adams:I wanted to.

lightclient:People think about trying to do 7, 9 0, 7 for this devnet. And if we find the database, changes are just going to be too complex. We drop it

lightclient:like, I know the database changes for us is only like one or 200 lines of code. It's not

lightclient:substantial.

lightclient:I don't know if that's pretty different for everyone else.

Ben Adams:Yeah.

lightclient:But it's 1 of those things.

Ben Adams:Changing all that good and pricing.

Ben Adams:I mean, I I think it would be better just to like

Ben Adams:increase the contract sizes by like 50% for Fusaka, as like a

Ben Adams:an interim, feel good, and then not not feel good. But

Ben Adams:you know it would be useful for Dev. And then

Ben Adams:in Glamsterdam we we do the the fuller, more complete thing.

lightclient:Yeah. But it already has a lot of things that people really want to do that are gonna be super critical.

lightclient:And

lightclient:it feels like we can just focus some effort now over the next month, and really lock in 7, 9 0, 7. Now, when there's not so much going on in the year.

lightclient:and then Glamsterdam is open for try to, the all the different yeah piece being proposed.

lightclient:Yep, my like, I just see us having the same conversation again, and

lightclient:6 or 9 months, and then saying, You know, there's a lot of stuff going at this fork.

lightclient:we should just wait till the next fork.

Ben Adams:Yeah, but it's it's the fact. We're at the end of the 4 promise. That's that's the main part.

lightclient:I don't think we're at the end of the fork almost.

Roman:Okay,

Tim Beiko:Robin. Yeah.

Roman:Yeah. Quick comment. My understanding that the problem with 7, 9 0, 7 was not this additional index.

Roman:but, like other explored implications of storing these huge contracts and and the database like. No, nobody just did the the analysis.

lightclient:I mean, I think Julia did look into it, and sequential reads is extremely fast from disks. So it's not really

lightclient:a major issue, but it's 1 of those things where we probably aren't going to get the best information until clients actually start to look at it.

lightclient:And I don't think that it like. It's not a big lift to begin looking at it like the whole implementation of this is probably sub 500 lines of code.

lightclient:and I think it's like a good stretch goal for us for the next devnet.

lightclient:And if we start implementing and we learn that this is not going to work out. Then we drop it no worries, and we look at Amsterdam.

Roman:Okay, I'm gonna Flip, I'm persuaded.

Roman:Rep is also for including 7, 9, 0, 7, or at least trying to implement it.

Roman:And if it's too difficult, we can always take it.

Tim Beiko:I guess one thing.

lightclient:Ultimately, the thing is that this is very important. IP for the community. They've been asking for this type of thing for many years, and we're close

lightclient:like we're really close. We just need to push through a little bit over the next month, and I think we can give it to them.

Tim Beiko:I think one thing to note about definite 2 is, even though Devnet one already has a bunch of things in it. The 2 other Ips we're considering are quite small. So 7, 2, 1, 2 is not trivial, but I believe most clients already have it implemented and would only need

Tim Beiko:would would only need

Tim Beiko:like to- to- to do the changes add from Vip 7, 9, 5, 1, 7, 9, 3, 4 is like also pretty straightforward. And it's like a a check on the size. So I guess.

Tim Beiko:like, yeah, do we want to commit to have it in Devnet 2. If it doesn't work out in Devnet 2.

Tim Beiko:We do that, and I get there's 2 comments about like tentatively including. This is why we call it scheduled for inclusion now, and not included, like, you know, if we learn something as we're working on it, that makes it no longer be a good fit, we should reevaluate that

Tim Beiko:but if we want to, if we feel like we have to actually include it on the Devnet, then I think it makes sense to ship that one and then potentially have that be like the one slightly more complex feature of that the 2. And if it works out, then great, we ship it. If we find that the issues are too big and that it's gonna delay the fork.

Tim Beiko:yeah, we we should just remove it.

Tim Beiko:So I guess if yeah, I guess and rest are

Tim Beiko:in favor. I know. Basically, never mind, Eric, on.

Tim Beiko:Yeah.

Tim Beiko:Do you have thoughts about this

Tim Beiko:If we did this, I think we should probably not do pay off code, and then that too. So this means, I think, if we include 7, 9 0. 7, and and there's some concerns we should probably

Tim Beiko:decline pay from this fork.

Ben Adams:Happy to experiment.

Ben Adams:Yeah, how it goes.

Tim Beiko:You're what sorry.

Ben Adams:Happy to experiment. See how it goes.

Tim Beiko:Okay.

Tim Beiko:Okay. Bay, Su. Argon.

Tim Beiko:I don't.

Andrew Ashikhmin:Andrew, we can try experimenting, implementing it.

Andrew Ashikhmin:So I haven't thought about it in detail. But

Andrew Ashikhmin:well, at least we can. Yeah, we can, we can start experimenting with it.

Tim Beiko:Okay, so let's do that, then let's do so so this means we'll leave 7, 2, 1, 2, 7, 9, 3, 4, 7, 9 0, 7 in Cfi, for now move 5, 9, 2 0 to Dfi. And then once we have shipped Devnet one assuming things don't break there, and there's not like a bigger correction. We would default to move these 3 Ips to Sfi and depart. Devnet 2

Tim Beiko:and then, if we find some issue with any of the Ips we should, we should reconsider whatever we want them in the fork, or just to remove them. And if there's some investigation that we can do on 7, 9 0, 7 in the meantime. Yeah, we should do that.

Tim Beiko:Yeah.

Tim Beiko:But I think we are set on the maximum possible scope for Fusaka. So as of this point

Tim Beiko:anything that's not in this list effectively out of scope. And if everything goes well, then, what's in

Tim Beiko:Sfi now? And the Devnet? 2 scope will be what ships.

Justin Florentine (Besu):So that includes pay. OP. Code is what I'm hearing.

Tim Beiko:No, I would say we, if we if we move forward with 7, 2

Tim Beiko:sorry with 7, 9, 0, 7, I would move to not do pay, and Devnet 2,

Tim Beiko:because it seems like most teams didn't support it. Then, if 7, 9 0 7 is already going to be complex.

Tim Beiko:I try to limit complexity, but.

Justin Florentine (Besu):Sure.

Justin Florentine (Besu):Okay.

Tim Beiko:Okay.

soispoke:Yeah. Over here.

Tim Beiko:Okay? Great. So, yeah, that's it for Fusaka.

Tim Beiko:So

Tim Beiko:looking ahead for Amsterdam, like, we discussed previous couple of calls, we want to start and consider headliners for the 4 1st line on that before we we we discuss other eips. So there were 3 headliners proposed already. I wanted to make the space if either of those proposals on the call to yeah, give a quick overview, and then I think it would be helpful. If

Tim Beiko:people on this call have like questions or concerns that need to be investigated to raise them, so that the champions, for these headliners can go and look into that over the coming weeks. There were also a bunch of like smaller, more minor eips. I don't think we should start making decisions about those, but I wanted to at least flag them so people could start proactively reviewing them.

Tim Beiko:But yes the 1st the 1st headliner candidate was fossil. I don't know if

Tim Beiko:anyone anyone championing fossil is on the call.

Tim Beiko:Okay, I linked the 3 threads in the chat so we can. We can follow up Async and discuss another call, and second was Evm. 64.

Wei Tang:Yeah, but I'm I'm here. So I'm the champion for 64. So this is something that

Wei Tang:I hope I'll probably give a formal introduction on this later. But at this moment I really want some more reviews. But the basic idea is quite simple. It's just we define a new group of codes that are only operating on the least significant of a stack value.

Wei Tang:And the good thing about this is that we can then, I mean the the each operation is done significantly faster, because you only have to do one statement of 4 for the 2, 56 bits.

Wei Tang:We currently have 2 different merchants.

Wei Tang:The 1st version is

Wei Tang:built directly on the legacy, or I, I would probably just use this name legacy Evm, which we define a prefix of code, and and the other set of the the opcode that follows it is is the 64 bits operation

Wei Tang:and the good thing. The the advantage of doing this is the way is less complicated. And we we just have. I mean.

Wei Tang:we have we? We can make the interrupt with 2, 56 bits really easily, because it's just a different set of codes. It can work with

Wei Tang:other calls really easily, and the second option is built on top of Eof. In this case, what I, what you have 64 will need is a change to Evm format, which does. Yes, we have a question already?

Wei Tang:No. So- so- so, yeah.

stokes:Sorry. Yeah, after this I just wanted to circle back to fossil for a second. I was just raising my hand for that.

Wei Tang:Okay, yeah, I will. Okay, I'll continue then. Then the second version, second option is built on top of Ui.

Wei Tang:And in this case we do need to do a change to the evm format which add a type.

Wei Tang:a type parameter into the code section. So the interpreter can can know, whether is running a code section of the the legacy evm or evm 64 and I think this this is the option I would prefer is it will be open up. A lot of organization

Wei Tang:approaches for us. And we can, we can basically write really fast jits for 64, like building on top of existing ui format.

Wei Tang:Quite well. And yeah, this, this is basically the the current proposal. And I will really looking for some reviews at this moment. If you have questions, I would really like to answer them. So

Wei Tang:yeah.

Tim Beiko:Okay, thanks any questions. Oh, there's a question by kev

Tim Beiko:there, there's a question by Kev around whether this has been prototyped and

Tim Beiko:and and whether we have a feeling of what the actual performance improvements are.

Wei Tang:I have a I have a prototype in for the the option one which just directly build on top of the the legacy. Vm, I haven't really benchmark it yet, but I will hopefully do that soon. So, but but I mean, if we write a jit for that, it will be

Wei Tang:faster because we are just not doing the actual work of of the actual extra 1 92 bits. So so for those, those computationally intensive operations functions that we only we can only use 64 bits. So this will be beneficial.

Tim Beiko:Thanks. I think, like, yeah, having hard benchmarks would definitely be helpful here. Are there

Tim Beiko:other questions, comments, concerns?

Tim Beiko:Okay? Then. Otherwise, I think, yeah, we can continue this conversation on these positions. And then,

Tim Beiko:yeah, move on to fossil so I think,

Tim Beiko:was, yeah. Toba, I think, is on the call. Maybe if you want to start to give like a quick overview. But then there were already a few questions about fossil in the chat, so we could get to those as well.

thomasthiery:Yeah, sure. So maybe first, st I can signal that I did give like a more sort of like fleshed out presentation on so like, everyone can sort of like refer to to the presentation, I guess if they want more details. But yeah, for so is Vip 7, 8, 0, 5 we

thomasthiery:presented it as a potential headliner for Amsterdam. What it essentially does is basically really improving ethereum censorship resistance by enabling multiple validators to just make sure that any transaction that is valid according to the protocol rules is actually included in ethereum blocks, and basically does so by having, like the multiple validators.

thomasthiery:build inclusion lists that are filled with transactions from the public main pool to impose some constraints on the

thomasthiery:on the builder. It has, like a bunch of interesting properties. I think maybe highlighting. Why it matters. It's because I mean, today, we have, like more than 80% of all works that are produced by just like the 2 builders. And we can just like decide whether to include or exclude transactions sort of arbitrarily. So folks, basically, what foci does is like it fixes this

thomasthiery:by empowering like the more like obviously decentralized set of validators to

thomasthiery:enforce inclusion constraints and build those plugs.

thomasthiery:for who it benefits it benefits basically everyone because it ensures. Like all the transactions are included on chain without sort of like any discrimination between different kinds of transactions that are just like arbitrarily decided by an external party instead of local.

thomasthiery:yeah, it has some

thomasthiery:benefits like you could like tie to scaling and improving ux. But of course, like the main, very big feature is improving censorship resistance.

thomasthiery:And why not? I think, yeah, it's really a solution to basically mitigate the censorship risk we've been having since. Pbs was introduced.

thomasthiery:and I don't know. Like the builder market is very, very centralized. It's like sort of inherent, because it's due to private. And I don't think it would change. And yeah, we have observed, like, sort of like increasing vertical integration across builders relays, and so forth over time and like, not the other way around. So

thomasthiery:yeah, I think there is a question also of like the urgency of including it. We've so that's been discussed and proposed a lot like there was another think fossil is is much better in many sense. But, like.

thomasthiery:yeah, there is a case for fossil, I think, because now we are like quite lucky that there's not much censorship on the network. I feel like in the future that can definitely change and make the inclusion of something like fossil or proposals to improve. I don't know censorship, resistance and privacy much

thomasthiery:harder to get in in the 1st place. So yeah, I think there is some big urgency in taking care of this. In terms of technical readiness. It's also, like

thomasthiery:like now fully implemented in 5 different clients and running on local, and get that are interrupting with each other soon. Lighthouse, I think. We've had 11 fossil breakouts. And we made sure, like, it's compatible with everything that's sort of like already in protocol, and also like other proposals. So

thomasthiery:yeah.

thomasthiery:I think there is a good case for fossil. I really want to. For for the for us to move this forward and not wait until things get back to get a proposal like fossil included.

Tim Beiko:Thanks.

Tim Beiko:One question that came up earlier in the chat was just the interaction of a fossil with delayed execution and block access lists. I don't know if you have like a some thoughts on that.

Tim Beiko:Yeah.

thomasthiery:Yeah. So there has been some recent progress on that front. It was mainly driven by Tony and Francisco. But there are like some very nice integrations between the 3 of them. So it basically works

thomasthiery:with delayed execution. But like, there are like some tricks that you have to sort of like deal with. To make it work together and plug level access is actually sort of like, make that easier. So there is a write up by Tony that I can link. But there is a nice integration between the 3 which is very nice.

Tim Beiko:Fixed any other questions. Thoughts about fossil.

Zane Starr | OpenRPC:Oh!

Tim Beiko:And okay, then, yeah, thanks a lot for jumping on a quick overview.

Tim Beiko:next up, the other proposed headliner was available at the stations. It's the one I have the least context on. I'm not sure if the author is

Tim Beiko:on the call.

Mingfei Zhang:Yeah, I'm here.

Tim Beiko:I hope.

Tim Beiko:Do you want to give a quick overview.

Mingfei Zhang:Oh, yeah, I will give us quick presentation for this.

Mingfei Zhang:Hmm.

Mingfei Zhang:oh, sorry. Wait wait a few minutes.

Mingfei Zhang:Okay.

Tim Beiko:Yeah. Thanks.

Mingfei Zhang:Okay? So

Mingfei Zhang:yeah, Hello, everyone. So today, I'm excited to present my eip 79, 79, 42 available attestation. So this is a proposal designed to make ethereum provostic fully reorg resilience. So first, st we are talking about what is real. So

Mingfei Zhang:as we as we can see, is it

Mingfei Zhang:table? So, despite money advancing ethereum approvals

Mingfei Zhang:protocol. The system also feeds the many new attacks. So some of tech we have already know about, like the ex, the balancing attack. It's a Lebanese attack and other attacks about attacking the Gasper

Mingfei Zhang:Cusper like the bouncing attack. So, and some of the attack, like the justification with holding. So these attacks they mainly focus on

Mingfei Zhang:attacking ghost or attacking customer, and they call mainly cause reorganizations, kind of like so the balance attack is more powerful, and it cause the

Mingfei Zhang:finalization. Stop also the Boston attack. So these attacks they have some mitigation by theorem. However, some of this mitigation has its limitations, like the proposal posting the.

Som | Erigon:Mitigation.

Mingfei Zhang:Oh, sorry I can't hear.

Mingfei Zhang:Okay, so the proposal boosting was 1st proposed, and it is. It set a very high boosting, and it calls sandwich, and then it is degraded to 40%, and it cannot fully prevent, however, if we set the anniversary stack to more than 20.

Mingfei Zhang:Also, the bouncing attack was 1st mitigated by the safe slot, so the justification cannot be

Mingfei Zhang:update if if apple has processed it slots. However, this medication is now removed, so

Mingfei Zhang:currently is now still facing the bouncing attacks. Vulnerability also, the justification withholding attack is not fully mitigated, and this cause, the staircase attack. This is one of kind of justification, withholding attacks

Mingfei Zhang:warranty, and this attack has been fixed in the current, and it is not really be fully mitigation, and what we want to do is

Mingfei Zhang:to keep the parent restriction. The idea is that

Mingfei Zhang:so in the Vernida Protocol, so if there is no adversary, the honest validator can propose one block of another. So the idea is like that. So this is block, one by one, and oh, sorry. And if there are some proposals that want to do something harm like they just want to make the system

Mingfei Zhang:very bad. So what they want to do is that they just build a block and dot point to the previous. They point to another block, and they may cause a chain fault, and there are 2 chains, and there are any other situation like this is

Mingfei Zhang:so, it may withhold a block, and it may released after this block is proposed, and cause a

Mingfei Zhang:cause. A fog like this. So this block, it will be fogged.

Mingfei Zhang:So

Mingfei Zhang:so this is why restricting the parent is very important. Our idea is that since the only validators always vote for the head. So if this is a chain and honest validator like the blue one, they always vote for this, and the adversary may vote for this and other blocks we don't know. So

Mingfei Zhang:what we want to do is make the honest validators vote be the parent candidate. So

Mingfei Zhang:so the idea is that. So if the adversary want to propose a block to this, this cannot be

Mingfei Zhang:our valid parents, since this block, it does not receive enough

Mingfei Zhang:attestations, because only 1 3rd of the State is controlled by the adversary, and we assume that we require that more than 1 3rd of attestation would for a block. This block can be the value, the parent so.

Tim Beiko:Big Faye.

Tim Beiko:Yeah, yeah.

Tim Beiko:I guess. Like, yeah. 2 things. One is would it be possible to share these slides in the chat to get for people to be able to review Async. But also, yeah. Given the topic, I think. Apologies about this, we should probably yeah, we should probably discuss this more on the the Cl call.

Tim Beiko:yeah. And this is my bad. I I think I I.

Mingfei Zhang:Yeah, yeah, I see. I see. So I'm I'm.

Tim Beiko:But if if you want to post the slides in the chat, I think we can.

Tim Beiko:yeah, we can have conversations, I think, as well on the youth. Magicians threads. If there's anything really important you want to finish like the minute or so.

Tim Beiko:go ahead.

Mingfei Zhang:Yeah, I think we will talk about it later. So.

Tim Beiko:Yeah. But yeah, I think, if yeah, if people can, if people can review the the actual slides that would be that'd be helpful.

Tim Beiko:Okay.

Mingfei Zhang:Okay. Okay.

Tim Beiko:I'm thanks.

Tim Beiko:I'm okay. And I think those were the

Tim Beiko:headliners that have been proposed for Amsterdam so far.

Tim Beiko:if people want to propose more. There is the East magicians thread for that.

Tim Beiko:yeah. Any other Glamsterdam Level conversation people want to have. Otherwise. There's also like something about pay that we should get back to in the chat. But

Tim Beiko:yeah want to wrap up the collapse of that headliner thread before

Toni Wahrstaetter:I could quickly talk about blocks of accesses. Maybe we forgot that now.

Tim Beiko:yeah. So yeah, I guess one question I would have for Bl is like, Do you think that's like a liner feature? And like should be the main thing of the fork, or, like, I know, we've talked about combining it potentially with fossil, potentially with delighted execution, so that might be

Tim Beiko:also worth getting into.

Toni Wahrstaetter:Yeah, I'm not sure about combining it with both of the 2, because it's more like block 5. Access list is a feature that helps delete execution, and possible to

Toni Wahrstaetter:be more aligned and to work more smoothly together. I saw Justin's comments and the chat that it might not be a headline. I think we can discuss that

Toni Wahrstaetter:right now. I would say. It's it has the size of a headliner.

Toni Wahrstaetter:I did the specs already, and there. It definitely looks like it's more of a headliner size. But yeah, debatable. Just to give a brief context on the eap, it's 7, 8, 28

Toni Wahrstaetter:and block level accesses, tries to introduce some parallelization.

Toni Wahrstaetter:So we can do batch I/O plus parallelly, executing transactions or executing transaction and doing the state root calculation in parallel.

Toni Wahrstaetter:So this is the primary goal there, and some secondary goals would be that.

Toni Wahrstaetter:for example, imagine a Ck world.

Toni Wahrstaetter:You get the proofs, and you want to up

Toni Wahrstaetter:the your state, and for that you can use the block of access list, because it essentially contains a full state. So without executing. You could keep your state up to date. And this is also nice for syncing, because we could kind of take the healing phase and replace it with the block of access list.

Toni Wahrstaetter:and then do the check. If if you are on the right chain at the end by comparing the headers

Toni Wahrstaetter:and regarding helping fossil and delayed execution. So the thing there is that fossil comes with post execution checks. So you have to execute the whole block, and then you have to check. Was there any transaction that was on an inclusion list? But it was not in the block, so you would have to try to append that transaction to the block and see if it could have been appended. If so, then the block would be valid

Toni Wahrstaetter:and Blocklet access list help there, because

Toni Wahrstaetter:usually you would need the post state for that.

Toni Wahrstaetter:and you only get the post state after execution. But with Blocklet access list you could have a function that looks like

Toni Wahrstaetter:it takes the pre-state and the block level access list and outputs the post state so you could do any checks that you would normally do post execution. You could do pre-execution.

Toni Wahrstaetter:and this is kind of where it aligns to that execution with puzzle a little bit.

Tim Beiko:Thanks.

Tim Beiko:Any questions.

Tim Beiko:Comments.

Tim Beiko:Yeah. Lucas.

Łukasz Rozmej:So one comment of mine about like scheduling. And so if we decide we want to do block access list, I wouldn't. I'm a bit reluctant to include fossil before, because then, with block access list, we would have to rework fossil a lot. So

Łukasz Rozmej:maybe it would be better to include them both, or actually block access list going before fossil just for

Łukasz Rozmej:redundancy of the work. It kind of seems. But it needs 1st decision. If you want to include block Ssds. In the 1st place.

Łukasz Rozmej:that's all.

Tim Beiko:Thanks, anzago.

Ansgar Dietrichs:Yeah, more on the process side around block level access lists and also discuss this a bunch with Tony. Basically the the way the structure of block level access works is that it's kind of it has 2 separate aspects to it. It's the the read side and the right side. And the count proposal, I think, for the for the reads basically only includes the location and for the rights, the location, and the values.

Ansgar Dietrichs:each on a per transaction level. It makes a lot of sense, if we want to ship both of these aspects of it to actually combine the implementation, because you can get a lot of synergies out of this, so you shouldn't have this completely, separately specified. But in terms of governance we should decide on both of these things independently. So I think we should really. Maybe that means splitting the Ap. But either way, like we should decide on. Do we want the reads? Do we want the rights plus diffs.

Ansgar Dietrichs:and then, if we want both, we ship them in a unified way. But if we only want to ship one of the 2. Then we should basically explicitly talk about that. So just on the process side.

Tim Beiko:Thanks. Guillaume.

Guillaume:Yeah, I mean, that's kind of building on what said, I am generally supportive of blocks access list, because I think it's it's a good 1st step to what I want to happen next the biggest issue I have with, you know, scheduling this right now is that there's actually 5 flavors of it. And I think, actually, there's a lot more. And we need to really really

Guillaume:limit the amount of of moving parts

Guillaume:so that we know what we ship. Because no, we're not gonna ship like we can't do it in 5 steps like it's it's completely useless if we? If we just move this in like many steps, because, you know, some of it might not be shipped. Some of it. You might change your mind and realize you took a wrong turn. So you need to get the final design. And I would say, the cip is.

Guillaume:quote unquote, small enough that we could reach a design, but I think before we even talk about scheduling it, and Tony knows my opinion. So it's not a surprise to him. I think before we talk about scheduling him, we should really get this this designed and and properly understood.

Tim Beiko:It's some.

Som | Erigon:So on some level, one or more flavors are already there, and, like historically

Som | Erigon:enabling parallel execution, and so on.

Som | Erigon:We have had some eips in the past as well.

Som | Erigon:Tony, do you know why we did not ship

Som | Erigon:this, or a variation of this in the past. And what changed now that we're in the position to do it.

Toni Wahrstaetter:Yeah, I think I think this is primarily because the community had some very clear stance on what the

Toni Wahrstaetter:what we want to achieve in the next one or 2 years, and it feels like l. 1 scaling was definitely on that list, and I would even say, on the top of that list. So

Toni Wahrstaetter:I would say, the focus shifted towards looking more into our one scaling and block of Access list. So parallelization was always a thing, and it. It is a thing today, right? All clients, almost all clients, have some prefetcher logic, some pre loading logic that already achieves that and is very good for that. In the average case.

Toni Wahrstaetter:block level access list would now go one step further by making sure that every block is parallelizable. There is this other year. Pf, I think it's 7, 8, 25, with the capping the gas limit, which is also already a

Toni Wahrstaetter:a step into the right direction, there to make sure that blocks are actually parallelizable, no matter if it's the worst case or the average case.

Toni Wahrstaetter:And just one more comment. I totally agree with what Anska and Guam said. We have to kind of get to the final design as fast as possible the 5 designs that were mentioned. This was just the 1st post I had on design space exploration.

Toni Wahrstaetter:But in the meantime I've been talking with some client teams. There was also a lot of great input in the discord channel, so check that out. And essentially it felt like. What clients wanted was the post transaction status, because this has many different advantages, not only for parallelization, but also parallel state route calculation or for execution by state updates. So the post transaction value seemed like something that clients really wanted.

Toni Wahrstaetter:and the storage locations. This is then something where clients could

Toni Wahrstaetter:replace Prefetcher code with the storage locations, because this is just a deterministic list

Toni Wahrstaetter:that is 100% correct, and it always gives you the

Toni Wahrstaetter:the right locations. And you're never yeah in the position where you run your prefetter. And it's actually incorrect.

Toni Wahrstaetter:Yeah, I think that that's kind of.

Łukasz Rozmej:I want to just add that I disagree that this wasn't the focus, because vertical trees and its witnesses carried a lot of these properties that we are now simplifying. Let's say with block access lists. So it was the focus of research for the last few years. It's just in a more complex form. And now it's being somewhat simplified with this proposal.

Toni Wahrstaetter:Oh, yeah, totally agree. I was more me thinking of focusing on kind of how to make it best for l, 1 scaling.

Som | Erigon:Are there going to be any?

Som | Erigon:My apologies? Changes in the block size because of this? Let's say you've

Som | Erigon:manage to scale the block nx of what it is. And then you have to ship

Som | Erigon:a lot of extra data as well, because right now, that is not being.

Som | Erigon:you know, taking place and like

Som | Erigon:with higher block limits and more transactions.

Som | Erigon:the bandwidth would be like a premium.

Toni Wahrstaetter:Yes, this is correct. So block type access list would add some additional size to the current block size.

Toni Wahrstaetter:And the worst case is not a problem here, because the worst case would be around 0 point 9 MB. So this is smaller than the worst case from call data, and the 2 are exclusive. So you cannot build a block that has a lot of call data and a big block level access list. But we should more focus on the average case here, anyway, and on average, the block of access list design, as it is in the Ap. Right now, would add on average, 40 kB per block.

Toni Wahrstaetter:And this is definitely a non negligible

Toni Wahrstaetter:increase. And we should, yeah, carefully analyze that. I think when we look at the pros and cons, I think it's worth it. But this is definitely, I would say, one of the most important points to to stress here that the block that access lists are not like

Toni Wahrstaetter:a super small object compared to yeah, anything that requires witnesses. It's very small. But yeah, definitely. Some some block average block size increase.

Tim Beiko:Odds are.

Ansgar Dietrichs:Yeah, on this point, I just wanted to briefly add a kind of caveat, just that, indeed, as account throughput levels, and especially at current pricing levels, even if we were to increase throughput. And this kind of extra data consumption is indeed not a concern, because for the same gas that you otherwise would have spent on call data. You already like, spend it on state breeds or writes instead. And so you can't spend it on call data. So the worst case block size does not actually get worse. However, there's a big big caveat there, because

Ansgar Dietrichs:going forward, we have more headroom to scale state accesses, reads or rights.

Ansgar Dietrichs:And then we have to scale data. And so this could actually change in the future. So basically we are locking us potentially in and basically, as we would want to change that pricing, we would then hit that wall, that now, basically, there's this, this this limit.

Ansgar Dietrichs:Same thing where we would. We are looking into these like multi dimensional pricing. Again, a bit of a scary term. But like, basically just like, make it so that you can consume call data and execution at the same time. Now, that would then also basically run into this bottleneck. And

Ansgar Dietrichs:none of this again, this is just a qualitative argument, not a quantitative argument. So I think over the next few weeks we will look into quantitatively. What does it actually mean, and what kind of relative consumption levels gas limit levels that would actually start to be constraining start to become an issue. And then hopefully, we have an empirical basis to actually make that decision. But I just wanted to flag that this argument that when you just brought up holds at today's levels, but not necessarily in that future that we're aiming to enable here.

Tim Beiko:Thanks.

Tim Beiko:And okay, anything else on block level access list. For now

Tim Beiko:otherwise, I do want to come back to this

Tim Beiko:pay OP code and and devnet inclusion. So previously, we said we would remove pay from Fusaka. It seems like a bunch of people in the chat voice that they they would actually like to keep it. And some of the client team said they already have implementations or the implementations are trivial. So there was a an ask, or should we consider this for definite? 3 for Fusaka? So

Tim Beiko:2 min ago, we said we wanted definitely 2 to be the last definitely where we add things, I think, even if we want to add one more, for with definite 3 we should be clear that

Tim Beiko:like, we need to ship what's in Devnet one, and then what's in Devnet 2. And then, if that all goes well we could potentially add pay to to defnet 3.

Tim Beiko:But yeah, how

Tim Beiko:how do people feel about that? Do we want to keep pay? Cfi, and then add it to Devnet 3. If everything goes wrong, everything goes correct, and we don't see major issues. And then that's 1 and 2.

Tim Beiko:Yeah, Ben.

Ben Adams:Yeah. So a very simple opcode in terms of it's just old that you delete 90% of the implementation.

Ben Adams:The the main thing would be around testing it, I guess.

Tim Beiko:Okay. Since base. You also wanted in Defnet 3 at the latest. 3 yeah. Lewis.

Luis Pinto | Besu:Yeah. So this came about in Uf, well, it was mandatory to to, because of the to to include it because of the

Luis Pinto | Besu:not passing the gas to the call anymore.

Luis Pinto | Besu:I see it was still useful as a simplification for, and even security wise, wise for mitigating reentrancing calls.

Luis Pinto | Besu:So I haven't seen that much pushback on arguments against it. So yeah, would like if there's any arguments against it.

Luis Pinto | Besu:But it's it's a really simple one, as Ben said, to add.

lightclient:I mean, I feel like I gave arguments against it last all quartz.

lightclient:which is that it's a very simple thing to implement. But the implications of implementing it are not as simple.

lightclient:And I don't know if people have thought really deeply about this, how we want people to use the epm going forward.

lightclient:It seems like something that people just want to do, because it's easy, and we can just do it. And it might make some like people's lives easier. But have we thought about? Is this really what we want the Evm to look like? Because we can't undo this.

Luis Pinto | Besu:As okay. So as I, I think the the use case is already available through self district. So it's not something new that we're gonna add, it's just making it explicit with the pay, with your code.

Andrew Ashikhmin:Yeah, I I'd like to add to like like clients. Point is that it changes the tracer. And if you want to trace historical balances. It just adds a new mechanism to transfer. If, which is fine. My only worry is that

Andrew Ashikhmin:it's maybe too late for Fusaka, and it's easy to implement in the Evm. But it has the

Andrew Ashikhmin:non trivial implements in

Andrew Ashikhmin:consequences. Down, down the stack, and we are disregarding that. We're only thinking, oh, it's easy to implement. Let's implement it.

Tim Beiko:Okay. So I think,

Tim Beiko:I'm fine, Le, leaving it. Cfi, if we want for the next 2 weeks. But I think we should definitely.

Tim Beiko:like, yeah. Have a better grasp on the implication if we are to include it in the 3.

Tim Beiko:But I would not.

Tim Beiko:But we're not gonna get that in the next 2 weeks.

Tim Beiko:So if we're not, then should be just remove it.

Andrew Ashikhmin:Is it possible to move it to Cfi for Glamsterdam, or something.

Tim Beiko:I would not do that yet. When we do this, it's like

Tim Beiko:we. We can propose it again for Amsterdam. We can have that conversation again in a few months, but I think it would be a mistake to decide today, when we don't even know what the biggest feature

Andrew Ashikhmin:Correct.

Tim Beiko:That will be yeah. So like, not like nothing against considering it for Glamsterdam. But I I think we should make those decisions independently.

Tim Beiko:Yeah, Daniel.

Daniel Lehrner (Besu):Yeah, I just wanted to say we we should be careful not not to repeat a similar mistake as with Evf, and maybe ask smart contract developers why they they wanted, you know, to to get outside voices, because there are things, maybe, that that we are missing.

Tim Beiko:Okay. So this makes me lean towards the word like, yeah, previous decisions removing it from Fusaka

Tim Beiko:and reconsidering for Amsterdam. And if it's mostly a question of like

Tim Beiko:design implications and community support. Then we have plenty of time to do that for Amsterdam, and if it's a trivial implementation,

Tim Beiko:if it's a trivial implementation, then it shouldn't be too too big to add to the fork, regardless of what goes in. But

Tim Beiko:yeah, given, we're already pretty full for Fuzaka. We've already stretched into this. In the 3rd definite I would lean towards removing it and just keeping your scope as is for basically what we had for def one, and then adding,

Tim Beiko:7, 9, 1, 2, 7, 9, 3, 4, 7, 9, 0, 7 2,

Tim Beiko:okay.

Tim Beiko:one more thing that I wanted to bring up on this call so there was an eip in the past about a versioning scheme for eips that the testing team had put together with, never mind they wanted to discuss it again on this call.

Tim Beiko:yeah.

Ahmad Bitar | Nethermind:See.

Tim Beiko:Yeah, I'm on. Yeah.

Ahmad Bitar | Nethermind:Yeah, hey? So I I won't take much of everyone's time. I just wanted to go quickly and suggest that we do the IP versioning scheme for all the Ips that we plan to include for Glamsterdam, which means that any IP that reaches the reviews. Date

Ahmad Bitar | Nethermind:should have a version, and then any consequent changes should probably ha add a an a minimum

Ahmad Bitar | Nethermind:at the end, saying, what was the change? If it was just a

Ahmad Bitar | Nethermind:linguistic change or deeper change, etc. Based on the spec that is written in the aip. There were concerns from raised from Tim about the friction that this would add to the

Ahmad Bitar | Nethermind:to the process.

Ahmad Bitar | Nethermind:and I think that we, like all core devs, have had instances where tests

Ahmad Bitar | Nethermind:and client implementations did not align just because we were not sure about the version of the aip that these tests were testing or the version of the implementation of that client that we are trying against these tests, or that even the version of the spec, like as an eels that we are using to generate these test

Ahmad Bitar | Nethermind:what they're called.

Ahmad Bitar | Nethermind:yeah, to generate like the test. So like a lot of a lot of things would benefit a lot of things in the process of the development and implementation of these Ips would benefit from this versioning scheme and this little friction that this adds, shouldn't account for should be like outweighed by the benefits that we get in testing, etc.

Ahmad Bitar | Nethermind:And yeah, like, I'd like to hear from everyone their opinions and potentially, if if there is like if if no, if people haven't even haven't haven't started looking at the aip, please do. And like, we can decide on it later. Obviously.

Tim Beiko:Yeah, I've I've looked at it in the past, and I frequently wrestle with the eip bot and get

Tim Beiko:and harass people to go wrestle with the eip bot. So I think

Tim Beiko:anything that's blocked on the eip.

Tim Beiko:But then, like anything that's like a strict enforcement.

Tim Beiko:it is something I would. I would have like pretty big concerns on like I would want us. I would basically want us to come up with like a proposal. For how do you actually automate this and and not add more friction to the process if you ship it? My counter proposal was like, let's just use the hash because we get it for free every time we do a commit to the eip. I think this gets you basically the value of clearly identifying the changes which

Tim Beiko:which

Tim Beiko:which is like half the battle. It doesn't get you. This idea of like, okay, the the magnitude of the change, and it doesn't quite couple it to the process. But I think if if that's kind of what we want like, then we should probably just have a much deeper rethink of eips around like, you know. What do we want statuses to mean? How do we want that to work with versions? How should that work with devnets and whatnot. And to me this feels like a much, much bigger can of worms that like we shouldn't just add a new

Tim Beiko:versioning scheme about like the the updates to the eip without taking this consideration. So I would say, like, if we want to say that, like the hash, is like the official version, have a way to automatically add that to the eips with a bot or something strongly support it. But I I think, any sort of versioning scheme should be much more comprehensive, and and reflect, like the Eip, state, the Hard Fork state, and all of that, and we should make sure the automation is is set up supported.

Tim Beiko:Yeah, I'm Andrew.

Andrew Ashikhmin:Yeah, I agree with you, Tim. I think this is a bit unnecessary, this this extra version, and it introduces more friction, because, we can always check the history in Github, but I think what would be helpful is to be stricter about

Andrew Ashikhmin:freezing eip commits on the devnet spec, because sometimes we do it and sometimes we don't. And I think that this is really helpful, because this gives us the level

Andrew Ashikhmin:of that we should target. So we are targeting devnet, say, 5 versions. We are doing tests for Devnet 5 versions. We're doing implementations for Devnet 5 versions. Everything is frozen, and we should do it like reasonably well in advance, and like new commands, can be merged, and so on. So.

Andrew Ashikhmin:But we'll have an explicit like for Devnet 6, we'll we can see the diffs between the commits and update everything to the Devnet. 6 version.

danceratopz:I.

Tim Beiko:Yeah, hey, Gavin?

danceratopz:It's, hey? It's it's Dan here. From the testing team from East.

danceratopz:thanks a lot Tim, for the input, about having a more sort of fully encompassed solution, and I completely agree.

danceratopz:So I think my proposal would be as the Eip, 7,577 stands. Now.

danceratopz:it's a little bit out of date, because that was written when we used the 1st available reference implementation from any client team in order to fill the test for any IP.

danceratopz:And now we've moved since Prague 5, I think of September like last year or October. We actually

danceratopz:generally, and I think we've managed to always use eels as the reference implementation as it should be, and

danceratopz:if eels was more tightly coupled with the eip process.

danceratopz:that if you propose an eip and you get

danceratopz:like Cfid, then you should propose an implementation in eels, and the and the Eip

danceratopz:document is tightly coupled to this eip implementation.

danceratopz:then it becomes a bit more reasonable to start adding a versioning on top of that.

danceratopz:I I don't want to take up much more time. It's just a thought that that we've had in the meantime.

danceratopz:Thanks. Yeah. I.

Tim Beiko:I think. And yeah, I think this is like an important discussion to have like I. But I do want to make sure that whatever process we have or whatever like scheme we use

Tim Beiko:is both like semantically useful, like we, we know what they're getting out of it, but also not completely independent from from the other parts of the process.

Tim Beiko:so my like, yeah. My again, my proposal, if we just want to track changes, then commits or or commit. Hashes are are kind of nice because you get them for free, and then, if we want to have a much more comprehensive thing. I think it should.

Tim Beiko:it should encompass a bit more.

Tim Beiko:yeah, we. I think it's worth continuing this conversation, I think, and happy to trial something for Glamsterdam as we as we work through the fork, which obviously we would, we would adjust.

Tim Beiko:And

Tim Beiko:we're already at time with this anything else people have to bring up quickly before we wrap up.

Tim Beiko:Okay? Well, oh, yeah, Ben.

Ben Adams:Just the issue. The blob, count Max per transaction that was just raised about.

Ben Adams:So the paired pair Dash related.

Ben Adams:It is, where is it?

Ben Adams:Re. Forward this that Alexia raised.

Tim Beiko:Okay, we're already past time. So let's have people review this. I think.

Marius:Alright, thank you. See you bye.

Gary Schulte:Bye Marius thanks Marius, Hi.

Ameziane Hamlat:And I.

Chat Logs

Tim Beiko:https://github.com/ethereum/pm/issues/1565

Barnabas:Do we still care about current devnet updates?

Marius:@tim nvm don't need any time for the modexp anyway

Ansgar Dietrichs:I could not make the acdt call, so the intention is to do an immediate jump to 60M? any specific reason to not do a step-wise increase?

Justin Florentine (Besu):he said "berlinterop" and i will never unhear that

Toni Wahrstaetter:60m is safe with regards to the 10mib limit

Josh Davis:Replying to "he said "berlinterop..." Glad its catching on

Barnabas:Replying to "he said "berlinterop..." He should have said Forschungsingenieurtagung

Marius:60m is not safe with regards to execution times imo

Justin Florentine (Besu):when previously discussed, we're ok with 60, but past that, not so much.

Ansgar Dietrichs:on one big vs multiple small steps: in my opinion it would be worth the one-time pain of going through the effort of getting node operators used to frequent changes of the recommended target gas level. yes, initially it will make each small step slower than a single one-time big step, but after that we will be in a much better spot

Marius:I modified one of the Nethermind test cases and it takes 2.7 seconds to execute as a statetest on geth

Barnabas:As a group there is not single answer.

Francesco:It’s very much possible to run at home at 60M

Luis Pinto | Besu:Besu tested a full node on Sepolia that’s not a validator and 60M was fine regarding attesting. That was a 4CPU on the cloud (don’t know the clock)

Łukasz Rozmej:I (and few other in Nethermind) run Ethereum on home computer.

Ansgar Dietrichs:Micah, how does this in your mind relate to EIP-7870?

Ansgar Dietrichs:Replying to "Micah, how does this..." or is the idea that you think any node fulfilling these constraints should be able to run a high usage RPC node?

Dankrad Feist:99%+ of Ethereum users don't run a node at home today Even of those that do, most still use a public RPC I think these discussions are disconnected from reality

Sophia Gold:I think we're commited to provers outside of data centers, although it will likely require more expensive hardware than current validators

Ansgar Dietrichs:the “super high end datacenter builder” is a bit of a misrepresentation. yes, it is a *research direection* how much we can lean into an asymmetry between building and verifying the chain, especially once we have CR that doesn’t rely on builders

Gary Schulte:Replying to "99%+ of Ethereum use..." 99.999% of internet users do not run an httpd server at home.

Justin Florentine (Besu):he's referring to our "fleet mode"

Marius:we don't have any numbers for state bloat etc yet. Bloatnet is a few weeks out afaik. So we shouldn't make any decisions on gas limit now

Ansgar Dietrichs:Replying to "the “super high end ..." nothing locked in roadmap wise

Barnabé Monnot:Replying to "the “super high end ..." arguments for/against: https://ethresear.ch/t/decoupling-throughput-from-local-building/22004

Micah Zoltu:Anyone have a link to 7870? Not coming up for me.

Kamil Chodoła:EIP-7870: Hardware and Bandwidth Recommendations

mrabino1:Curious… doesnt the zkevm verification narrative solve this? Wouldn’t a pragmatic path be to keep the course of at home users as the priority until zkevm verification is everywhere? My $0.02

Tim Beiko:https://eips.ethereum.org/EIPS/eip-7870

Micah Zoltu:Replying to "Curious… doesnt t..." It does not, you still need full head state.

Sina Mahmoodi:IMO heavy workloads such as a 30Tb archive node which is processing tons of rpc requests should be integrated into the tests. Hearing reports that they are under strain even at beefy hardware. Note that the “full archive” nodes are required for serving historical eth_getProof requests so many entities still need them.

Barnabas:I think this should be discussed offline.

Justin Florentine (Besu):off lining it is why we never talk about it

Preston Van Loon:There is also a diff between $2k device running on a fiber line at home vs a $10k machine that has to be in a colo data center. We can and should increase the requirements, but not so much that it isn't possible at all at home

Łukasz Rozmej:Replying to "IMO heavy workloads ..." Can Erigon 3 serve them with low disk footprint?

Justin Florentine (Besu):our values are changing, we should be explicit about it

Tim Beiko:@Marius can you expand a bit on what you’d want to see w.r.t. state?

Barnabas:Replying to "off lining it is why..." then we should schedule time for this discussion

Sina Mahmoodi:Replying to "IMO heavy workloads ..." Can it serve ancient state proofs?

ethDreamer (Mark):Doesn’t verkle / L1-zkevm both address this concern?

Micah Zoltu:Replying to "off lining it is w..." That was what this was supposed to be I was told.

Łukasz Rozmej:Replying to "our values are chang..." Are they though? Requirements are rising a bit, but it is due technical resons mostly.

Tim Beiko:Replying to "off lining it is why..." Ser

Justin Florentine (Besu):Replying to "off lining it is why..." no. this is literally where we plan the future of ethereum, if our values are not relevant here, then they are fake. your values are what you DO, not what you say.

Łukasz Rozmej:Replying to "IMO heavy workloads ..." no idea, I heard somewhere it can

Łukasz Rozmej:Replying to "IMO heavy workloads ..." would like to confirm

Micah Zoltu:Replying to "Doesn’t verkle / ..." No, you still need head state to use ethereum.

Marius:Replying to "@Marius can you ex..." I would like to see the results from bloatnet etc

Justin Florentine (Besu):Replying to "off lining it is why..." this is where we plan ACTION, material action.

Gary Schulte:conflating ethereum user with ethereum staker is a mistake

Sina Mahmoodi:Replying to "IMO heavy workloads ..." The thing is if you have to store all trie nodes that ever existed it kind of takes space. So I doubt it. But will check!

Marius:Median Ethereum users don't need decntralization, don't need censorship, they need a fast cheap casino

Marius:Not what we should be optimizing for imo

Marius:Or we need to redesign ethereum from the ground up

Ansgar Dietrichs:Replying to "Median Ethereum user..." that’s a very cynical take on your users

Bastin:Replying to "Median Ethereum user..." it's not. it's a connected take to reality.

Ben Edgington:Replying to "Median Ethereum user..." Not cynical - we have a responsibility to plan for the worst case, not the average case.

Barnabas:I don’t want ethereum to become solana2. I wanna be able to verify the chain at home. I think higher consumer hardware is acceptable up to about $5k range. I think bandwidth up to 100Mbps is acceptable. Higher hardware could make sense, higher bandwidth probably not.

Parithosh Jayanthi:Replying to "off lining it is why..." @Justin Florentine (Besu) what value do you feel is being compromised? It’s been unrealistic to run a node on a low end non-dedicated machine for about ~5-6y now. You could always run ethereum on low end hardware dedicated for the purpose 6y ago, you can today and you likely can even at 60M or 100M gas. Beyond that, I agree it degrades, but we aren’t talking about those numbers yet.

Kamil Chodoła:Replying to "There is also a di..." 7870 ones are far from datacenter ones - is like 100 usd/month machine ovh which we use for perf tests now.

Dustin:incidentally, can the future of Portal-based 4444 be clarified?

Micah Zoltu:Re https://eips.ethereum.org/EIPS/eip-7870, I have comments on the discussion thread for it, and I think a PR as well.

Łukasz Rozmej:Replying to "IMO heavy workloads ..." @Andrew Ashikhmin?

Ansgar Dietrichs:Replying to "conflating ethereum ..." That’s why EIP-7870 makes that distinction! I think we need to go further though, and also distinguish between simple full nodes and nodes that need the state, nodes that serve a high number of parallel rpc requests, etc

Marius:Replying to "Median Ethereum us..." Maybe cynically phrased, sorry for that.

Francesco:Replying to "I don’t want ethereu..." 5k buys you a lot of ssds 😄 I don’t think almost anyone here is advocating for even this kind of requirements?

Justin Florentine (Besu):Replying to "Median Ethereum user..." not cynical, accurate indictment of recent changes in Ethereum direction tbh

Francesco:Replying to "I don’t want ethereu..." Let alone for datacenter chain 00:20:54 FLCL: light clients can cover rpc argument what specific UX issues does Dankrad mean?

Kamil Chodoła:Replying to "I don’t want ethe..." 5k you can get ryzen 9 with very very decent ram and disk and you will still have some to go for quite a few good lunches :D

Som - Erigon:Replying to "I don’t want ethe..." 100mbps still a bit too high on average. 10mbps. An 8TB SSD is around $1000

Micah Zoltu:Replying to "off lining it is w..." Vitalik has a forum post that describes a path that could get us back to running on end-user hardware, so it isn't out of our reach.

Gary Schulte:Replying to "off lining it is why..." I have to disagree. my $600 computer at home is not even breathing hard to keep up with mainnet and produce bespoke non-mev blocks. I would call that low end

Barnabas:Replying to "I don’t want ethereu..." Exactly. So we have headroom in my books. We just have limited bandwidth. Bandwidth is always going to be blocker.

Sina Mahmoodi:Replying to "light clients can co..." Which light client?

Micah Zoltu:Replying to "off lining it is w..." The issue is primarily storage, next bandwidth, not CPU.

ethDreamer (Mark):Replying to "Doesn’t verkle / L1-..." Your concern was state growth pricing out normal hardware? I’m not sure I understand why verkle or l1-zkevn would prevent you from having the head state?

FLCL:Replying to "light clients can co..." ones we need to develop

Łukasz Rozmej:Replying to "IMO heavy workloads ..." https://github.com/erigontech/erigon/issues/12984#issuecomment-2708213147 ah it is limited in time

Parithosh Jayanthi:Replying to "off lining it is why..." Happy to help debug that, but my $500 node from 2019 is still sitting at 20% CPU usage while being a full node.

Ahmad Bitar | Nethermind:Replying to "light clients can co..." Portal is dead, lightclient roadmap more dead

Parithosh Jayanthi:Replying to "off lining it is why..." And re:storage, I agree. This is why history expiry is really important to ship

Tim Beiko:https://github.com/ethereum/EIPs/pull/9855

Micah Zoltu:Replying to "Micah, how does th..." See my comments in the discussion thread, and/or my PR (I think I opened one) proposing some changes to it.

Sina Mahmoodi:Replying to "light clients can co..." Very hard to do log filtering in a light rpc

Parithosh Jayanthi:Replying to "off lining it is why..." We would gain ~500GB of space back on the node. Also history doesn’t need to be on SSD even today, HDD are ~8x cheaper than SSDs.

Justin Florentine (Besu):Replying to "off lining it is why..." @Parithosh Jayanthi i'm more concerned with the opacity around the changing ethereum values, less wrt to gas limit. i'm actually fine with 60M, and more opposed around 100M. mev builders and poor upstream bandwidth are far bigger threats than raw compute.

FLCL:Replying to "light clients can co..." Portal is dead, lightclient roadmap more dead Which means it's a direction we need to prioritize

Gary Schulte:Replying to "off lining it is why..." agreed. can't build decentralized blocks with an empty tx pool

Parithosh Jayanthi:Replying to "off lining it is why..." Yup, hence the data collection from home stakers and only suggesting gas limits we know the network can handle

Micah Zoltu:Replying to "the “super high e..." To be clear, I'm not opposed to DC builders in general, though I do worry about resiliency when you start depending on too few actors. See power outage in Spain vs power outage in Africa. When outages are common, people have backups. When outages are rare, people don't have backups. When you have a small number of operators you can run into problems with there being no backups when they do go down.

Preston Van Loon:Replying to "There is also a diff..." Seems like a mac mini would work with 7870. Cost around 1 ETH too

Parithosh Jayanthi:Replying to "off lining it is why..." 60M is possible on p99 of mainnet home stakers

Sina Mahmoodi:Replying to "IMO heavy workloads ..." Yes a full archive node is a huge pain that some entities will need to endure and it will only get worse.

Parithosh Jayanthi:Replying to "off lining it is why..." This is data that has actually been collected. The question is if we expose ourselves to security issues. That is what we’d like to spend the next tweek.

Tim Beiko:https://github.com/ethereum/EIPs/pull/9833

Parithosh Jayanthi:Replying to "off lining it is why..." We’d never stand behind a gas limit change that affects the home stakers we actively gather data from, or that would be pointed out explicitly for ACD to decide

Kamil Chodoła:Replying to "There is also a di..." We have perfnets, opcodes analysis etc - if we want we can put some "low-end" spec machine and run everything here and see how it is working out there.

stokes:Huge UX unlock

Gary Schulte:Replying to "off lining it is why..." it seems unreasonable to stake 6-7 figures worth of eth on low end hardware. I’d expect the specs published recently (by Kev et al) should be future-proof for at least a couple hard forks

Barnabas:Replying to "Huge UX unlock" don’t think anyone opposed it before

Parithosh Jayanthi:Replying to "off lining it is why..." Yup, but I guess this is Micah’s point. How do we showcase the full node perspective, not just home stakes perspective.

Micah Zoltu:Replying to "off lining it is w..." @Paritosh The few remaining people who casually run Ethereum on their consumer hardware already drop history and prune state. The lowest you can get right now is under 100GB, and 4444 won't change this at all because those people already have locally implemented the equivalent. The increase in gas limit will increase state growth and those people are the ones most impacted, not people who are storing all of history and disabling pruning.

Łukasz Rozmej:Replying to "IMO heavy workloads ..." do you know what are the use cases for full one?

Parithosh Jayanthi:Replying to "off lining it is why..." Sure, and what is the upper limit such a user is comfortable with? 500GB SSDs are 32 eur right now.

Micah Zoltu:Replying to "our values are cha..." I believe they are. Bitcoin originally normalized it, and then Ethereum picked up on the ethos that people can do things from home, be it running your own Bitcoin node, or running totally private dapps. This used to be a big focus of a lot of things, but it no longer seems to be.

Barnabas:Lets ship 7951 ✅

Ansgar Dietrichs:context: difference between recover and verify is that recover returns the signer address, but verify takes signer address as extra input and only returns true / false

Parithosh Jayanthi:At 60gb/year, we have plenty of head room. Realistically no different of a headroom compared to 30gb/year.

Marius:yes

Marius:We have not started testing eips on the devnets yet

Micah Zoltu:Replying to "Doesn’t verkle / ..." It isn't a "pricing out" concern, it is a concern over how much free hard drive space people have on computers they have purchased for general usage at home. >60% of gamers (as a demographic) for example have <500GB of free space.

Gary Schulte:is the only 7951/7212 diff the security considerations?

Tim Beiko:EIP-5920: PAY opcode RIP-7212: Precompile for secp256r1 Curve Support EIP-7907: Meter Contract Code Size And Increase Limit EIP-7934: RLP Execution Block Size Limit

Łukasz Rozmej:Replying to "our values are chang..." but you can do it at home, at worst you have to buy a 4TB SSD, with Erigon3 you can have archive in 2TB the only problematic thing is full-forest archive for eth_getproofs, but home-users don't really need it

Gabriel Trintinalia | Besu:is eip-7907 making devnet 2?

Barnabas:Replying to "is eip-7907 making d..." thats what we are discussing now

Tim Beiko:EIP-7594: PeerDAS - Peer Data Availability Sampling EIP-7823: Set upper bounds for MODEXP EIP-7825: Transaction Gas Limit Cap EIP-7883: ModExp Gas Cost Increase EIP-7892: Blob Parameter Only Hardforks EIP-7917: Deterministic proposer lookahead EIP-7918: Blob base fee bounded by execution cost EIP-7935: Set default gas limit to XX0M

Ansgar Dietrichs:Replying to "Doesn’t verkle / L1-..." right, zkEVM in itself only helps create very light weight stateless nodes. It also enables cpu-light stateful nodes (if they don’t need tracing / only selective tracing), but then ofc they still need to be able to handle the state at whatever larger size it will be

Marius:7212, 7934 don't care about the other two

Barnabas:ideally we wont have any more eips for devnet 3 btw. So whatever makes it in devnet2 will ship to fusaka

Roman:Reth is for including RIP-7212 & EIP 7934. Was generally was supportive of 7907 but there is a long thread that I haven’t caught up on yet

Łukasz Rozmej:Replying to "our values are chang..." I will be the first to protest if I cannot profile Nethermind locally on my rig!

Carl Beekhuizen:Replying to "is the only 7951/721..." Effectively, yes. Bug patch Much higher quality spec Extensive tests (including all edge cases for possible internal cryptographic optimizations)

Micah Zoltu:Replying to "our values are cha..." "You can buy hardware that can be powered by standard 2kW residential circuits" is different from the original ethos of "you can run this on hardware you already have".

Parithosh Jayanthi:Replying to "Doesn’t verkle / L1-..." I actually think this is a bad dataset to start with. If I decide to download Call of Duty, that’s about 500GB that’s used right there. So now the user has barely any free space. Is the ethereum node more important than call of duty?

Parithosh Jayanthi:Replying to "Doesn’t verkle / L1-..." And why can’t the user decide this for themselves?

Hadrien Croubois (OpenZeppelin):Replying to "is the only 7951/721..." 7951 still behaves poorly when signature are wrong

Hadrien Croubois (OpenZeppelin):Replying to "is the only 7951/721..." empty output for invalid signatures or invalid inputs is sooo bad

Łukasz Rozmej:Replying to "our values are chang..." but it is fine to make people buy hardware as long as it is cheap, buying $200 drive to run Ethereum is fine. People buy $500+ GPU's to just play games.

Justin Florentine (Besu):@Gabriel Trintinalia | Besu is our point person for Fusaka

Łukasz Rozmej:Replying to "our values are chang..." most laptops come with miserable 1TB as default

Nicolas Consigny:Replying to "is the only 7951/721..." 7212 you meant ?

Nicolas Consigny:Replying to "is the only 7951/721..." @Hadrien Croubois (OpenZeppelin)

Łukasz Rozmej:Replying to "our values are chang..." Apple's probably 256GB :D

Parithosh Jayanthi:Replying to "our values are chang..." Let’s not conflate numbers. The testing machines we use cost ~1k, are NUCs and were bought ~3y ago. We run a fleet of them. These machines are worth ~200 if bought second hand now. The SSD is worth more than the machine. Its a very far world away from 2kW residential machines.

nixo:justin’s in a bird sanctuary? 😍

Nicolas Consigny:Replying to "is the only 7951/721..." What is wrong in the new spec

Barnabas:Replying to "justin’s in a bird s..." always

Ansgar Dietrichs:@Micah Zoltu we already accepted EIP-7870 though, so the agreed upon min disk space is 4TB NVMe. you can specifically ask for acd to revisit that decision - ideally you should have voiced your concerns while we were discussing the EIP (for several months)

Justin Florentine (Besu):Replying to "justin’s in a bird s..." It's Always Sunny in Philadelphia, Nix

Carl Beekhuizen:Replying to "is the only 7951/721..." So to be clear, it behaves correctly & constantly, but I hear that you don’t love the empty return vs 0.

Łukasz Rozmej:Replying to "our values are chang..." In terms os wattage, you can easily run on 30W machine

Micah Zoltu:Replying to "off lining it is w..." The smaller the footprint, the more people who can run. We do have to make a call and I think it is safe to say that 10GB is out of the question at this point (though see Vitalik's post where he poses some solutions that may allow us to get down into that range by storing a subset of state). My primary concern is that these users seem to be an afterthought, rather than a primary concern (which is what it should be IMO). Doubling the rate of state growth without dedicating any R&D effort (and in fact cutting R&D resources) towards making home operation on limited disk hardware is problematic IMO, given that state growth is what got us into this situation in the first place.

Łukasz Rozmej:Replying to "our values are chang..." the only reasonable issues could be SSD and internet connection

Marius:could you post the link to the discussion?

Tim Beiko:http://ethereum-magicians.org/t/eip-7907-meter-contract-code-size-and-increase-limit/23156/36

Carl Beekhuizen:Replying to "is the only 7951/721..." But there is nothing wrong from a safety standpoint, it just looks a bit ugly.

Hadrien Croubois (OpenZeppelin):Replying to "is the only 7951/721..." see my comment in the PR

Gabriel Trintinalia | Besu:same, prefence would be 7212, 7934 and 5920

Carl Beekhuizen:Replying to "is the only 7951/721..." I think it is very important to keep the same interface as 7212 as that is already in use across many L2s (and wallets) etc

Roman:@Ben Adams okay, so we still need an index, right?

Hadrien Croubois (OpenZeppelin):Replying to "is the only 7951/721..." safety is one thing, usability is another. Saying stafety is fine so lets ship it while usability is not fine ...

Barnabas:sounds like fusaka-devnet-2 will be: 7934+7951 Glamsterdam: 7907 + 5920 (maybe)

Łukasz Rozmej:Replying to "our values are chang..." And if you want heavy querying of local RPC, invest couple houndred bucks in better CPU and bit more RAM, but nothing one wouldn't buy to play some modern video games

Hadrien Croubois (OpenZeppelin):Replying to "is the only 7951/721..." tipically the mindset that got us in the EOF drama

Luis Pinto | Besu:I think that if we want to show we listen community we should eip-5920

Micah Zoltu:Replying to "Doesn’t verkle / ..." I did voice my concerns and I was told that 7870 was only meant to be a retrospective accounting of what was required to run "full" nodes and not meant to be representative on what we were targeting or why. Then lines were added after I reviewed it and it was merged without me realizing those changes until I found a bunch of people on Twitter telling me that anything less than 4TB was "officially unsupported for anyone running an Ethereum client".

Hadrien Croubois (OpenZeppelin):Replying to "is the only 7951/721..." almost like core devs don't care about users

Ansgar Dietrichs:Replying to "our values are chang..." @Justin Florentine (Besu) were we not explicit about that in the discussion on EIP-7870 a few months ago? E.g. a 4TB NVMe drive for full nodes (not stakers!) was a clear change. What we are doing now is just making use of this new headroom that EIP gave us.

Carl Beekhuizen:Usability is essentially the same, it can be checked in ~ the same amount of gas

Marius:Let them deploy libraries

Hadrien Croubois (OpenZeppelin):Replying to "is the only 7951/721..." >Usability is essentially the same Yes, both are bad

Kamil Chodoła:How come you can have a 100GB DB now after so many years on 30 and now on 36 and increasing to 60Mgas so almost 2x will now casue it to grow 60GB/year? Am I missing something?

Marius:Replying to "Let them deploy li..." -Marius Antoinette

Micah Zoltu:Replying to "Doesn’t verkle / ..." This is why I said on Twitter that we need someone who hasn't drunk the kool-aid who is "in the room" consistently when these decisions get made by some subset of people making such decisions.

Kamil Chodoła:Replying to "off lining it is w..." Still you have more space on decent smartphones now :D

Mario H:Replying to "Message sent befor..." 7870 is supposed to be the recommended hardware spec but it misses the minimum viable. Now it feels like the minimum moved to the recomended level

Sina Mahmoodi:Replying to "off lining it is why..." Hm geth state size is around 350gb tho

Kamil Chodoła:Replying to "off lining it is w..." It is probably abotu the fleet mode from besu (the 100)

Barnabas:we can give it one extra week if its needed

Micah Zoltu:Replying to "our values are cha..." People running nodes at home already prune state and drop history. Those people don't have 4TB disks, and when they do they are generally full (of things ilke Call of Duty!).

Łukasz Rozmej:INCLUDING is very hard wording here, we can experiment, but won't commit before bencharks

Roman:Can we tentatively include then?

Justin Florentine (Besu):does it need to be investigated on a devnet?

Micah Zoltu:Replying to "our values are cha..." Several clients have fully pruned modes that are well under 500GB today, some are trustless, and we could make trustless under 100GB possible, but cranking up the gas limit because "it is insignificant compared to the 4TB assumption" is just ignoring those users.

Kamil Chodoła:Replying to "Doesn’t verkle / ..." Recommended is a reference for testing. I was also suggesting actually specifying "minimal" but I got the point that we had none and now we have something to refer to but this doesn;t mean we will optimize to work only on recommended.

Parithosh Jayanthi:Replying to "our values are chang..." Sure, but they have to prioritise what they want to run then. In an ideal world we take up 100mb of space, but that isn’t a realistic outcome. IMO it’s worth more to focus on proofs rather than optimising for increasing competition on local multipurpose machines.

Marius:Matt will have to implement it though

Barnabas:Replying to "Matt will have to im..." he is happy to do so

Parithosh Jayanthi:The users who really need this feature can and should always be able to run a node at home. We should keep numbers at realistic sizes. IMO we currently aren’t in a territory where it’s unreasonable.

Barnabas:Replying to "Matt will have to im..." he just told me

Tim Beiko:Replying to "Matt will have to im..." He just told all of us

Gabriel Trintinalia | Besu:Happy yo try as well

Luis Pinto | Besu:I missed the question

Tim Beiko:7907 in devnet-2

Justin Florentine (Besu):7907 for devnet2

Marius:Replying to "Matt will have to ..." I thought he needs to work on 4444 now

Francesco:Replying to "our values are chang..." I’d rather ignore the users with an SSD full of games than users that are trying to use the chain or build things on it…

Ben Adams:We have the perfnet infra to test effects

Barnabas:spec sheet: https://notes.ethereum.org/@ethpandaops/fusaka-devnet-2

Gary Schulte:Replying to "our values are chang..." sounds very strawman

Micah Zoltu:Replying to "off lining it is w..." 30M gas -> 60M gas is a 2x increase in state growth assuming no change in behavior. I personally expect a behavior change that will result in more storage, but that is speculation on my part so not part of my argument. My main argument is that we should be focusing effort on keeping growth low and seriously thinking anytime we raise it. Right now there is no principaled approach to keeping state growth down, it is just "2x growth doesn't seem so bad" with no actual analysis on how it will impact the home operator demographic.

Roman:Scoping glamsterdam next ACDE!

Łukasz Rozmej:Replying to "Scoping glamsterdam ..." why not this one? :D

Roman:Replying to "Scoping glamsterdam ..." Fair point

Barnabas:Replying to "Scoping glamsterdam ..." PAY opcode for glamsterdam?

Luis Pinto | Besu:And there’s no devnet-3 right?

Barnabas:Replying to "And there’s no devne..." not spec wise different, unless we have some big problems.

Luis Pinto | Besu:Replying to "And there’s no devne..." right

Justin Florentine (Besu):idk why PAY was so controversial

Ben Adams:Replying to "idk why PAY was so c..." don't think anyone complained

Barnabas:Replying to "idk why PAY was so c..." it wasn’t controversial, it just didn’t seem to get enough people excited.

Tim Beiko:FOCIL EVM64 Available Attestations

Luis Pinto | Besu:Replying to "idk why PAY was so c..." I wonder if we are in the same place as before, where app devs are not following

Ben Adams:Repricing?

Tim Beiko:Propose it 😄

Justin Florentine (Besu):Replying to "idk why PAY was so c..." honestly, this is a great example of what frustrates me about us. this is a basic, cleanup of some techdebt that gets punted another month because it isn't interesting to people.

Parithosh Jayanthi:Replying to "our values are chang..." I am only arguing against the steam stats that were brought up. IMO it isn’t a valid datapoint to start with. The claim that more state growth is bad is one I can standby. The question will always be what level of state growth can we handle.

stokes:Replying to "FOCIL EVM64 Availab..." Not sure if my audio was working But we covered FOCIL last week if anyone wants to see an overview there There are some EL-specific concerns so worth having folks here take a look

Derek Lee:As a side comment (was late to the call) & speaking on behalf of Offchain Labs (at least for Arbitrum), we would love to see EIP7907 included. Sounds like it made it the cut but wanted to toss our support behind it as well

Justin Florentine (Besu):Replying to "idk why PAY was so c..." s/month/year

Łukasz Rozmej:FOCIL has big interactions with Delayed Execution and Block Access Lists, I think we shouldn't decide in vacuum, rather than having a broader plan.

Micah Zoltu:Replying to "our values are cha..." The target I would like to see is that people who buy a computer recommended to them by the sales rep at Best Buy or Walmart can run Ethereum in the background. I think it is achievable, but only if we actually try.

thomasthiery:I can present FOCIL (although I didn’t know there was going to be any presentation planned for this call)

Tim Beiko:Replying to "FOCIL has big intera..." Do you think DE or BAL are big enough to be "headliners"?

Toni Wahrstaetter:Replying to "FOCIL has big intera..." only with delayed exec, not really with BALs

Micah Zoltu:Replying to "our values are cha..." These are computers with maybe 512GB SSDs these days, standard home internet for their area, and their drive is probably 50%-75% full.

Justin Florentine (Besu):Replying to "FOCIL has big intera..." BAL is a tough one... maybe not big enough to headline, but too big to followon

Tim Beiko:Replying to "I can present FOCIL ..." It doesn’t have to be super formal, but I think it’d be good to take a few mins to give a quick overview and then answer some of the questinons like above

Parithosh Jayanthi:Replying to "our values are chang..." Will such a user ever run ethereum at home? Should we not prioritise for access patterns they might actually use? I.e, prioritise RPCs with proofs that you can validate. Make it such that you cannot be lied to.

Barnabas:Replying to "idk why PAY was so c..." Justin, Even you didn’t sound too enthusiastic about it. You generally sound very enthusiastic about everything 😄

Łukasz Rozmej:Replying to "FOCIL has big intera..." @Toni Wahrstaetter well if you want DE+FOCIL then you need some concreate flavor of BAL, so they are interconnected (not conflicting)

thomasthiery:Replying to "I can present FOCIL ..." Ok sg

Sophia Gold:Replying to "FOCIL has big inte..." We need delayed execution for zkEL clients, which we expect to roll out immediately after Glamsterdam. So it should be a a headliner at least in terms of importance

Łukasz Rozmej:Replying to "FOCIL has big intera..." why we need it?

Łukasz Rozmej:Replying to "FOCIL has big intera..." and why not ePBS? :)

Roman:Replying to "FOCIL EVM64 Availab..." Don’t see Delayed Execution on the list

kev:Has this been prototyped to measure the possible performance increase?

Tim Beiko:Replying to "FOCIL EVM64 Availab..." @Roman see the thread above 😄

Sophia Gold:Replying to "FOCIL has big inte..." We need the extra time for proving!

Kamil Chodoła:Replying to "our values are cha..." Will there be a person who will go to Walmart and ask "I want a machine to run Ethereum on" or rather will be asking about other things and will run Ethereum as a fun exploratory for them? And whenever you want to really start doing something you should have dedicated machine for that.

Gary Schulte:Replying to "our values are chang..." stateless solves the ‘background use cases’ imo. We need to engineer our way into the broader use cases, while keeping full node specs achievable by consumer grade hardware. proving roles notwithstanding

Łukasz Rozmej:Replying to "idk why PAY was so c..." TBH: I am not entusiastic either, but not sure why it was dismissed without proper conversation

Parithosh Jayanthi:Replying to "our values are chang..." ^ Yup, agreed with this use case for sure

Justin Florentine (Besu):Replying to "idk why PAY was so c..." long lived, durable institutions are built by people doing the boring shit, not hoping that the heroes happen to find the right thing interesting

Barnabas:Replying to "idk why PAY was so c..." how many weeks of impl does pay opcode takes?

Ben Adams:Replying to "idk why PAY was so c..." 20 mins (not including testing)

Luis Pinto | Besu:Replying to "idk why PAY was so c..." It’s similar to CALL but without the new context frames

Parithosh Jayanthi:Replying to "our values are chang..." I have, do and will continue to run my node at home. I think there are enough core devs that would ensure we can continue to run nodes at home. I don’t think 60M gets us even close to the territory where this isn’t possible anymore.

Ben Adams:Replying to "idk why PAY was so c..." Already have a PR in Nethermind for it 🙂

Luis Pinto | Besu:Replying to "idk why PAY was so c..." There were benefits around security presented in this call I believe, while EOF was still around

Wei Tang:Replying to "Has this been prot..." I've done a small prototype here: https://github.com/rust-ethereum/evm/tree/master/features/evm64 But benchmarking is still ongoing.

Francesco:Last week’s presentation time: https://youtu.be/cIHtUaIev4M?list=PLJqWcTqh_zKHU6gjnA6ZcFPU5Pr0xT0io&t=3378

Łukasz Rozmej:Replying to "idk why PAY was so c..." @Tim Beiko maybe revisit decision?

DA | Flashbots:Less than 70% of blocks are now built by Titan + beaver currently fwiw

Gabriel Trintinalia | Besu:Replying to "idk why PAY was so c..." Besu has an implementation for it as well

Micah Zoltu:Replying to "our values are cha..." @Paritosh Such users used to run Ethereum. All that I used to know no longer do because of disk requirements. Arguably more important than that though, is people need to be able to run at home as a fallback for when their country gets censored by the RPC providers. Right now if you are someone in Venezuala getting censored, you can't install Ethereum on your computer and be back to uncensored in 16 hours. You have to go buy new hardware, get it installed (which probably means giving your computer to a tech specialist who installs the drive for you, maybe migrates data off old drive because you only have one nVME slot, etc.), then finally sync Ethereum and use it. I don't think we should expect everyone in Venezuala to do this.

Toni Wahrstaetter:Saying that builders are the problem is not super fair bc even during the sanctions, builders included relatively more TC transactions than local builders

Toni Wahrstaetter:Replying to "Saying that builders..." FOCIL definitely gives you faster inclusion but it's not like you have no inclusion guarantees today

Micah Zoltu:Replying to "our values are cha..." @Kamil The latter, the idea is that users already have computers, we shouldn't be asking them to buy another one or upgrade their existing one if they want to use Ethereum trustlessly/privately/CR.

Justin Florentine (Besu):Replying to "Less than 70% of blo..." how full are the remainder? local builders can't even hit gas targets because the public mempool is starved.

Łukasz Rozmej:@Micah Zoltu on the other hand that means they don't care much about running ethereum locally? If 2TB is a dealbreaker for them

Sophia Gold:We need to do FOCIL before zkEL clients are made mandatory, but I would not say it's urgent vs. being sure we can ship Glamsterdam early next year

Micah Zoltu:Replying to "our values are cha..." @Gary Schulte Stateless definitely helps with the CPU utilization, doesn't solve the state growth or network utilization problems though.

Luis Pinto | Besu:Replying to "idk why PAY was so c..." https://docs.google.com/presentation/d/1pZgbr5yLaSNxpwRdixgkAV9mfo_gql448_iSOVKlyvA/edit?slide=id.p#slide=id.p

Ansgar Dietrichs:I agree that FOCIL is very important I think (not fully formed opinion yet) I disagree on urgency. I think it would be fine for this to be shipped one or two forks after Glamsterdam

Dustin:Replying to "Saying that builde..." It's a structural concern. There's a builer duopoly. Relying on Titan/Beaver to remain aligned with Ethereum overall is risky

Barnabas:Replying to "idk why PAY was so c..." How would you’ll feel about having devnet 3 with pay opcode?

Micah Zoltu:@Lukasz Or they just can't afford to spend the money/time to access Ethereum trustlessly/privately. They may still need or benefit from those properties, but they are out of reach when it doesn't run on their existing hardware. Essentially, there is a big gap between "double click installer" and "research and purchase hardware, operate multiple computers, double click installer."

Łukasz Rozmej:Replying to "our values are chang..." and btw for people really restricted Nethermind can run on 200+GB's

Parithosh Jayanthi:Replying to "our values are chang..." We actually aren’t even talking about 2tb yet, with history expiry we’re talking about 300-600GB. Which steam stats claims ~90% of users have. So if they are actively being censored, and Ethereum is important to them - id expect them to delete some data and setup their node.

Justin Florentine (Besu):Replying to "idk why PAY was so c..." love it

Tim Beiko:https://ethereum-magicians.org/t/glamsterdam-headliner-proposal-available-attestation/24377

Gabriel Trintinalia | Besu:Replying to "idk why PAY was so c..." yeah, same

thomasthiery:Here are the slides to the FOCIL presentation I made last week: https://docs.google.com/presentation/d/1BYZQOmNkv-nLe25NmPOowhBLPVa76kDDibR_nR0-RGU/edit?usp=sharing

Parithosh Jayanthi:Replying to "our values are chang..." The total hard drive space of over 500GB on steam stats is ~75%.

Parithosh Jayanthi:Replying to "our values are chang..." With 52% over 1TB

Micah Zoltu:Replying to "our values are cha..." @Lukasz Doesn't state pruning still require ~250GB? Last I checked you needed 250GB free on top of the actual storage used, unless you wanted to wipe your DB and resync every few days.

spencer-tb:Replying to "idk why PAY was so c..." Would be okay with pay if its in a future devnet as there are a lot of edge cases to test, including it with devnet 2 might be too much with 7907 on testing side

Łukasz Rozmej:Replying to "our values are chang..." you could just drop and resync every few months

Micah Zoltu:Replying to "our values are cha..." You are looking at total disk size, not free space. >60% have less than 500GB free.

kev:Isn’t this meant to be for ACDC?

DA | Flashbots:Replying to "Less than 70% of blo..." Local average is like 40% of target. BuilderNet I haven’t looked, but probably 90%+. Rsync is probably 75%. Not that FOCIL helps with this at all.

Parithosh Jayanthi:Replying to "our values are chang..." If you’re being censored, your money is worth more than your call of duty download

Francesco:Replying to "our values are chang..." What I don’t understand is how this hypothetical user that cannot afford to buy a 1 TB SSD is going to meaningfully *and reliably* benefit from Ethereum’s guarantees, in a world where we leave everything as is. Just 2-3 years ago fees were tens to hundreds of dollars for basic txs

Ansgar Dietrichs:is this an acde topic? seems pretty CL only

Micah Zoltu:Replying to "our values are cha..." Would be nice if Nethermind automated this. Only reason I don't turn it on is beacuse I usually don't notice the growth until I'm at 0 bytes free and my computer stops booting reliably. 😖

Mario H:Replying to "I agree that FOCIL..." Censorship resistance is a dependency for future privacy improvements and neutrality in general. With builder centralization and past attempts on censoring privacy tools, I sense the urgency

Micah Zoltu:Replying to "our values are cha..." (we should move this conversation to Discord, Zoom chat is horrible and painful, plus I have another meeting to get to)

Toni Wahrstaetter:Replying to "Saying that builders..." Not directly. If it was a bigger app that was censored then only non-censoring builders would win the block auction. Since it was only a small app (TC) we had longer inclusion times but builders (not only the big ones but also the small ones) included most sanctioned TC, not the local builders (relatively speaking since we only have 8% local builders).

Sina Mahmoodi:Replying to "I agree that FOCIL i..." We need focil today

thomasthiery:Replying to "I agree that FOCIL i..." The sense I have around urgency is mainly around the fact that pricing tail risks is difficult, but we shouldn’t wait for potentially massive censorship on the network before shipping an EIP to address its structural problems

Justin Florentine (Besu):Replying to "Saying that builders..." wait, are you implying that local builders had TC blacklists in place?

Sina Mahmoodi:Replying to "Saying that builders..." Maybe because builders include more txes in general?

Toni Wahrstaetter:Replying to "Saying that builders..." nope, but there were builders that only won by including TC transaction that censoring builders couldn't include

thomasthiery:Replying to "Saying that builders..." builders are making a lot more profit from private order flow (e.g., TG bots) and CEX-DEX arbs than any other app

Toni Wahrstaetter:Replying to "Saying that builders..." @Sina Mahmoodi but why would you submit your TC transaction privatly?

Marius:Can we move on, please?

Justin Florentine (Besu):Marius is actually very nice.

Marius:Replying to "Marius is actually..." Sorry, the last couple of days have been very busy

Justin Florentine (Besu):Replying to "Marius is actually v..." you're fine fren

Roman:@Toni Wahrstaetter talk about DE instead!

Ansgar Dietrichs:Replying to "our values are chang..." but zoomed out, I agree with the OP comment, to the extent that our values are indeed changing (doesn’t have to be a bad thing), we need to be explicit about it

Łukasz Rozmej:I would prefer FOCIL to go with/after BAL, not before as it will need to be reworked otherwise. (If we plan to include BAL's in the first place)

Tim Beiko:BAL EthMag thread: https://ethereum-magicians.org/t/eip-7928-block-level-access-lists-the-case-for-glamsterdam/24343/7

Justin Florentine (Besu):Replying to "our values are chang..." it's not to late to re-align what we are saying with what we are doing

Ansgar Dietrichs:I think the current BAL EIP should really be understood as a combination of two changes: per-transaction post-execution access lists, so just the location of all state reads of all transactions per-transaction post-execution state diffs, so the location and values of all state writes of all transactions

Francis:+1 for block level access list

Francis:good for scaling, fits the overall priority imho

Łukasz Rozmej:Writes OR Both for me

Justin Florentine (Besu):interesting - because one can unlock parallel ex broadly, and another is adding on the witness based use cases?

Ameziane Hamlat:Replying to "Writes OR Both for m..." Writes for besu would be the best direction

Justin Florentine (Besu):Replying to "Writes OR Both for m..." bonsai ftw

Karim T.:Replying to "Writes OR Both for m..." Yes I will prefer to have write

Łukasz Rozmej:focus was witnesses in verkle, which would achieve that

Tim Beiko:re: 5920 for devnet-3, I’d suggest making it clear in the Meta EIP but keeping all 4 currently CFI’d EIPs as CFI’d. If something goes wrong with devnet-1, then we reevaluate whether to trim devnet-2+3 scope, and if something goes wrong with devnet-2, we re-evalute devnet-3?

thomasthiery:It also interestingly might serve as a basis/requisite for zkEVM, so there are some interactions there as well to consider

Sophia Gold:Long term, BALs with state diffs are good for state providers in a zk word, which is what we started this call discussing wrt node requirements

Ahmad Bitar | Nethermind:Personally against block access list, just wait for binary trees and witness

Justin Florentine (Besu):the only aspect of this I am apprehensive about is in a future of rising gas/block, BAL acts as a block size multiplier and I remain concerned about home stakers with crappy upstream. Otherwise i love BAL.

Barnabas:Replying to "re: 5920 for devnet-..." nothing will go wrong.

Justin Florentine (Besu):wait, why are call data/ bal mutually exclusive?

Toni Wahrstaetter:Replying to "wait, why are call d..." you have to touch as many accounts as possible possible, thus spend your gas on writes

Toni Wahrstaetter:Replying to "wait, why are call d..." so no gas left for calldata and at this point you get a bigger block by investing all your available gas into calldata

Francesco:Replying to "the only aspect of t..." Like Ansgar said, there’s two orthogonal features in the current EIP, one involving reads and one involving writes (the per-tx diffs). When it comes to the state diff part of it, one aspect of it that imo mitigates these concerns is that this might be a cost that we have to pay long term. At least, at the moment I don’t see a long term architecture where we don’t want to have state diffs in the block, to be able to support stateful nodes that don’t do re-execution and partially stateful nodes (in both cases, where verification is through proofs)

Łukasz Rozmej:with big increases to gas limit we might need to increase price for SLOAD/SSTORE?

Justin Florentine (Besu):Replying to "wait, why are call d..." thanks!

Francesco:Replying to "the only aspect of t..." So at least for the state diff part of the EIP, I wouldn’t be too concerned about this bandwidth cost because I think it’s a must long term

Ansgar Dietrichs:Replying to "with big increases t..." because of BALs, or in general?

FLCL:can we include https://github.com/ethereum/EIPs/pull/9623 in a devnet?

Łukasz Rozmej:Replying to "with big increases t..." both

Francesco:Replying to "Personally against b..." Why? We can get a lot of benefits independently of witnesses. And it’s not even clear that we’ll ever have witnesses (if statelessness is through zkEVM)

Marius:Replying to "can we include htt..." we should

Gabriel Trintinalia | Besu:Happy with pay in devnet-3

Justin Florentine (Besu):i'd put it in 2, happy with it in 3

lightclient:easy implementation, big implications

Ansgar Dietrichs:Replying to "with big increases t..." I agree with the concern with regards to BALs

spencer-tb:Testing biggest bottleneck for pay. Not against dvnt3

Marius:Replying to "easy implementatio..." lol bug implications

Ahmad Bitar | Nethermind:Replying to "Personally against b..." Then why binary tree if not for statelessness?

Luis Pinto | Besu:Yeah agree with the testing non-trivialness

Marius:I think the geth team leans toward removing it

Luis Pinto | Besu:+1

Barnabas:@Justin Florentine (Besu) your time to shine :D

Justin Florentine (Besu):Replying to "@Justin Florentine (..." lol app devs don't talk to me, nobody does.

Guillaume:Replying to "Personally against b..." if we don't have witnesses in zkvms, BALs are instant technical debt.

Barnabas:Replying to "@Justin Florentine (..." just curious about your main point for pushing for this eip

Marius:Replying to "@Justin Florentine..." I will talk to you!

Justin Florentine (Besu):Replying to "@Justin Florentine (..." unless you want someone to complain (again) about or lack of market understanding, I can do that all day

Barnabas:Replying to "@Justin Florentine (..." but haven’t heard your voice at all when it was time to chime in

Tim Beiko:https://eips.ethereum.org/EIPS/eip-7577

Parithosh Jayanthi:Replying to "@Justin Florentine (..." Yessir, what made you be pro? that might even be enough reason

Toni Wahrstaetter:just for my understanding, at which size (in kib) does it become a concern?

Barnabas:Replying to "can we include https..." devnet 2?

Toni Wahrstaetter:Replying to "with big increases t..." And is the concern that we might not be able to execute that many SSTORE/SLOADs or the size of the BAL?

Justin Florentine (Besu):Replying to "@Justin Florentine (..." i am pro because the current means of transferring eth is an embarrassing hack. i'll re-review the args against, maybe my understanding isn't deep enough

stokes:Can we use the git hash per network spec?

Tim Beiko:yes

Tim Beiko:please

Łukasz Rozmej:Replying to "with big increases t..." just for my understanding, at which size (in kib) does it become a concern? that would have to be tested, I expect somewhere 10x+ current gas?

Gary Schulte:EIP versioning generally would clarify inclusion/devnet spec confusion we have experienced in the past. It also can show at a glance whether a current implementation needs to be revisited

Daniel Lehrner (Besu):Replying to "with big increases t…" Let’s make the SSTORE gas price flat at the same time. Independently what is written, it’s the same price. Saves us the disk lookup for every SSTORE.

Parithosh Jayanthi:Don’t we already use the git hash in the devnet spec page?

Toni Wahrstaetter:As an RPC provider, I just need the state diff to serve users. Why would it be instant technical debt? BALs are not supposed to replace statelessness for stateless validators

stokes:Replying to "Don’t we already use..." I feel like we sometimes do

Parithosh Jayanthi:Replying to "Don’t we already use..." We can make that to always

stokes:Replying to "Don’t we already use..." Personal opinion but semantic versioning can be a rabbit hole of bikeshedding

Francesco:@Guillaume I really don’t see why. Proof + state diff seems like exactly what you’d want in that world, so you can still run a stateful node without doing any execution. (Here with BALs I am actually only referring to the post-tx state diffs part, which is quite similar to just block level state diff)

Justin Florentine (Besu):Replying to "Don’t we already use..." srsly, just calver

Francesco:Replying to "Personally against b..." (Or a partially stateful node)

Francesco:Replying to "Personally against b..." Witnesses are just subsumed in the proof

Barnabas:Replying to "Don’t we already use..." getting hashes for each is pretty high manual task

Gary Schulte:Replying to "Don’t we already use..." git hash is deterministic but doesn’t convey meaning-at-a-glance like semantic version

Barnabas:Replying to "Don’t we already use..." we might need to ask mr claude to setup an automation for this

stokes:Replying to "Don’t we already use..." Can push the work to the author/champions

stokes:Replying to "Don’t we already use..." Ill even do it for CL stuff if I need to

Barnabas:Replying to "Don’t we already use..." They wont do it lol

Barnabas:Replying to "Don’t we already use..." they might do it 1x

Barnabas:Replying to "Don’t we already use..." but not the 10x time

stokes:Replying to "Don’t we already use..." Yeah fair point

Barnabas:Replying to "Don’t we already use..." I’m pro versioning!

Barnabas:Replying to "Don’t we already use..." I think the bot should be able to do it

Tim Beiko:Replying to "Don’t we already use..." git hash is deterministic but doesn’t convey meaning-at-a-glance like semantic version You will never get this fwiw

Tim Beiko:Replying to "Don’t we already use..." We can barely agree on Draft/review/ or CFI/SFI

Barnabas:Replying to "Don’t we already use..." can’t we just setup a semver versioning ?

Barnabas:Replying to "Don’t we already use..." bot would do that

Wei Tang:If we're talking about protocol specifications then there's really not "minor" version change. Every change to the specification is backward incompatible and it's always "major" version change.

Tim Beiko:Replying to "Don’t we already use..." How chooses what is minor/major/etc.

Gary Schulte:Replying to "Don’t we already use..." yeah but a PR can implement 8.0.1, whereas a hash just implies there was a change. Updating the verbiage can cause a new hash

Tim Beiko:Replying to "Don’t we already use..." Will bikeshed forever

stokes:Replying to "Don’t we already use..." How does the bot resolve the semantics?

Barnabas:Replying to "Don’t we already use..." feat major fix minor chore minor

Barnabas:Replying to "Don’t we already use..." semver already does this

Tim Beiko:Replying to "Don’t we already use..." What’s a “feat"

Barnabas:Replying to "Don’t we already use..." new feature

stokes:Replying to "Don’t we already use..." And each tag is labeled in each PR?

Barnabas:Replying to "Don’t we already use..." yes

Tim Beiko:Replying to "Don’t we already use..." Yes, but what I mean is how do you define this in EIPs?

stokes:Replying to "Don’t we already use..." You’d still have conformance problems

Barnabas:Replying to "Don’t we already use..." each EIP starts with 1.0.0

stokes:Replying to "Don’t we already use..." I guess walidator could demand it

Tim Beiko:Replying to "Don’t we already use..." 100x more conformance changes

Marc:Replying to "If we're talking abo…" could just be rewording, fixing typos etc.

stokes:Replying to "Don’t we already use..." But honestly I’d rather just use the commit hash

Anders Elowsson:Replying to "If we're talking abo..." Seems reasonable to clearly distinguish between changes to an EIP that affects logic and that does not, in whatever implementation we have.

Wei Tang:Replying to "If we're talking a..." In that case it's "patch".

Gary Schulte:Replying to "Don’t we already use..." very bike-shreddable. however lets not make the perfect the enemy of the good.

Marc:Replying to "If we're talking abo…" that would still change the hash though

Ben Adams:https://github.com/ethereum/EIPs/pull/9623

Zane Starr | OpenRPC:thanks folks