| Decision Item | Description |
|---|---|
| 148.1 | With regards to the Shanghai implementations, we agreed to include the following EIPs in Shanghai and launch a devnet with them ASAP: |
| EIP-3651: Warm COINBASE | |
| EIP-3855: PUSH0 instruction | |
| EIP-3860: Limit and meter initcode | |
| EIP-4895: Beacon chain push withdrawals as operations | |
| 148.2 | We also agreed to keep working on EOF and 4844-specific devnets in parallel, and have them build on top of this "Shanghai Core" devnet, to mirror how the CL teams are having 4844 rebased on top of Capella (which is mostly withdrawals). |
| 148.3 | We also discussed potentially including EIP-4758, which deactivates SELF DESTRUCT, but agreed there needs to be more analysis done here. |
| 148.4 | Next Tuesday 15:00 UTC there will be a community call about outstanding Goerli supply issues: eth-clients/goerli#129 |
—----------------------------------------------------------------
Tim Beiko 7:26: Okay. So good morning. Everyone. Welcome to all core dev 148. After basically a month off. We have a bunch of stuff to cover today. I think the main thing, I hope we can get through is basically just getting your view from the different client teams around. You know where they're at generally, what they see as priorities going forward for Shanghai. So we've had a bunch of time, Async. And in person at Devcon, and other ways to just like, discuss all the potential eips, all the stuff that's been Cfi that a while back. And so I think it's valuable to just take time to go over. Yeah, how each team kind of sees that, so far.
Related to Shanghai. I think there's also two specific topics, and beyond the actual eips themselves that are worth covering. So one is just how we do the fork activation. So we discussed this a little bit in Bogota. But basically you know how we want to trigger the fork, and there's different implications there. And then there's a devnet that's already been stood up for some Shanghai stuff, so it'll be worth covering that as well. And I think then, if we get through that, we still have time. There's a couple of other sorts of important topics that aren't directly related to Shanghai. But around the engine API a new protocol version, and all the issues we've been seeing around Goerli. Yeah, so if we can get through all that, it'll be a good call. I guess you know just to kick this off from the el slide . Does any client team just want to kind of share? You know, over the past month as you've looked at like all the stuff we could be doing next. What do you think they are like? The priorities? What do you see as important? And where you would like us to to focus on.
Marek Moraczyński 9:36: Okay, I can start with nethermind updating our view , So we have the raft or merge. PR for all candidates for inclusion for Shanghai . Of course we are testing and reviewing them. We also implemented the activating self, distract and transient storage up codes, so far we synced the Shandong test yesterday. we run and pass you. You have tests. If it's about withdrawals, we need to adjust them to the latest spec employment test on our site and check with Mario's test vectors about priorities. My viewpoint is that current candidates for in class inclusion are good choices for the next Harvard. If we added something big, we would delay withdrawals for sure, and I believe we don't want to. And we can work in parallel on other eips. Perhaps I would like to consider small eips like reactivating self destruct. That is my opinion.
Tim Beiko 10:48: Got it? Thanks Lukasz, I see you have your hands up.
Lukasz Rozmej 10:51: Thanks, I can get away with one thing. So, in my opinion, the biggest priority right now is to define the scope of Shanghai in the next. Hopefully, four weeks or something.So we can plan accordingly and to move accordingly to that. So that's probably the biggest priority.
Tim Beiko 11:13: Right? Yeah. And on that note I guess, just as I was talking a little bit about this before we went live to some people, I think, at a high level today, if we can sort of work through with all the client teams as priorities with their current views are. And then on the next call, there's obviously a bunch of like eip champions that have stuff proposed. We could make that call sort of the main one for people to come and advocate for those, and my hope is like the call after that. So, like four weeks from today. We sort of have a pretty clean list for Shanghai that doesn't move uh. So we should have probably an idea today of like, you know, if there's stuff that every single client team thinks is important, then it probably makes sense to me forward for that. But then, yeah, in the next call or two we can. We can sort out all the potential additions. But yeah, I think every client team I've spoken with has echoed, but like getting even almost even more importantly than like what the list is getting is sort of a finalised list for Shanghai, and in the next month or so it is really important to allocate resources. Anything else from Nethermind?
Marek Moraczyński 12:27: No, I think that is all.
Tim Beiko 12:29: Okay, Thanks. Andrew, Do you have your hand up?
Andrew 12:33: Yeah, I agree with Eric. I think the current is the current. Cfi list is a good one, and I would add to the self-destruct the activation. If 4758 it will simplify at least Eric Ons code base significantly and it's also a prerequisite for
Tim Beiko 13:04: Thanks, Peter.
Péter Szilágyi 13:09: So from the Geth team's perspective we have a little debate on how we kind of use Shanghai. And what we view is important. One in quotes rather than because they are to the simple streams, and they are. The effort is mostly about making sure that they work correctly. This is probably the testing at what is more significant. So we're kind of on these smaller features. I think our opinion is that yeah, whatever people would like to go with, we kind of have to go with, although we do support. I think that self destruction would be super nice to do as soon as possible. However, on the bigger features within the team, we kind of have a few champions for three specific features. Like clients, is Well, the withdrawals are something that people kind of take for granted that it's going to get really shanghai. So that's definitely being worked on correctly by that time. And as for another, two main features, one of them is, which was brought up quite a lot on in Descon was four, eight, four, four, and larger tasks to tackle, but at least on the execution player. It's a relatively simple and straightforward uh vip, and it would allow a lot of scalability. So at least uh Marius and myself are kind of pushing towards that direction. Also, the if sixty eight update that we propose to zoom in is going on the same path. And, as for the third large uh features that Mark in would be like to champion the UF. Stuff. So there! I guess the two possibilities of getting into this one of them is just getting a view of support without, and any actual use case which the rationale behind it is to try to keep it to minimal changes and other rationalities to get the us in with some actual new use cases. I am fine with going through the minimal approach to, if we can actually define these future use cases in advance, so long as we know what we want them to be enabled for. I think that's also fine. So kind of that's how they get in, kind of sees Shanghai and It might be interesting to try and get more and one big feature too, since we also suck at shipping hard for us. yeah, it might be interesting to find some of the um um middle ground between how many stuff we add and how rarely you should.
Tim Beiko 16:59: Yeah, okay, there's a ton of hands up. But thanks for that here. That's a really helpful perspective. Matt, from Besu. I think you were next.
Matt Nelson 17:09: Yeah, no, and we have a little bit of a different opinion. But at the same time, you know, I think, what netherminds put out was pretty much in line with what we were looking at. We have some of the came to PRs from the list pretty much wrapped up besides testing. You know, our perspective is that it really depends on the complexity of four hundred and four whether we want to conclude that we haven't done enough scoping to understand fully on our side. But the the rest of the candidates on the list, maybe, with the exception of eof should be relatively straightforward for our team. So you know, I think the EoF. Where there's a little more discussion to Peter's point. But other than that, you know, the only kind of unknown is what the actual complexity of four hundred and four will be in terms of what we need to implement and test um, and also with the consensus layer side. Do we want to? You know. How will that look in terms of delaying the features that we would ship in Shanghai, or at least you know, complicating that question. So that was kind of where our team landed. But yeah, it definitely, definitely Okay, with the rest of the candidates on list and and already have a lot of that in flight also for the including the things like transient storage and self-destruct also are on board with that, especially considering that, you know, with transient storage a lot of the implementations are already written. So I think that we should just, you know, push for those kinds of lower stakes things as long as again to Peter's point the testing is thorough and understood.
Tim Beiko 18:37: Thanks.Yeah, I think, Lukasz, you're next because the Mayor and Andrew.
Lukasz Rozmej 18:42: Yeah, I want to weigh in on prototypes for 4844. So we had a big discussion, this thing about it, and there were some concerns. So the first concern is that the scope Isn't finalised, the thespec is really still evolving, and we are afraid that it will go and go in a way that's like the match. That's some minor things we're changed up to the last moment. Not that the last one was quite, quite far into the pipeline, and it created a lot of tension. It creates a lot of uncertainty on some things for us. So If we want to include them. I would like to have this spec finalised in a month, and then in the next month, and then we can take a final decision based on the scope. Because Um, yeah, that was the biggest um like um unknown to us. How big it would be in the final scope. And we see that as problematic, and we don't want to commit to something that might change in the future, et cetera, before the actual recent, potentially even, postponed Shanghai itself. And we would like to get withdrawals out of the window sooner. So yeah, those are our concerns for it, for that still developed in terms of spec a lot.
Péter Szilágyi 20:14: Got it. We are up here very nicely. Sorry 4844 is not the pro-bank startup that's built on top. That's something. After that 4844 is just the block transactions.
Lukasz Rozmej 20:27: Okay. Okay. So I'm not championing that so I might be a little bit confused here.
Tim Beiko 20:36: so I think there. So the for it for four still has some moving parts on this spec um, and and as far as maybe Ansgar. you commented a couple of times about this. But you want to have maybe an update of where things are at with the spec and what you expect we can get done in the next month or so.
Ansgar Dietrichs 20:55: : Right? I think I've only been passionately, but maybe it's good enough. So, I think. Basically there was one more moving piece from a couple of weeks ago. The free market. That's um done like this with one small question left. But I'm very confident in this office in the next four weeks, and there's also some small uncertainty left around the specifics on the side like they, there might be one additional parameter that the precompile it's supposed to return. It's like very small changes there. I don't think so. Yeah, I basically think it would be very reasonable to come if it's within the next month or so. Um, there might be some more moving parts on the networking stick side. I'm sorry about that. So if someone else on the call could talk to that.
Tim Beiko 21:51: I think maybe the other parts that we could probably see moving are like some constants, so like from an implementation perspective, it's probably not a huge change. But, like, say, you know the actual blob size or the retention period on the cl deciding, you know, whatever it's like 500K or 256K. So those constants I suspect, could probably still change as we do more testing. But it shouldn't alter the implementation significantly, I guess
Ansgar Dietrichs 22:23: right, and I I don't specifically see a reason why, if we want to, I think we could also make more or less final decisions on that within the next four weeks also. But yeah, you're right, I don't think there would be an issue with still changing them at a lighter point. But if there was a strong desire to just make final calls soon, I think we could do that.
Tim Beiko 22:45: Okay, Back to the raise hands, Marius.
MariusVanDerWijden 22:53: Yes, so I had some issues that I would like to discuss. I am actually sorry I actually quit it. The only problem I see is that the State UF. Is in right now with the proposed Eps. It doesn't actually help us with anything and so we would need to for UF to be really useful. In my opinion, we would need to get rid of the job test analysis. maybe also have the stack validation and so we need to create. We need to put uh like have another hard, for with at least two Eips. The problem is that contracts that are deployed now between now and real UF, or like the useful Uf will could still have a code that is not that doesn't have these validations in place. So we would have at least three versions of the Avm. We would have the normal version. We would have UF. Version one which has the Eps in that we have right now and then we would need to have the Eof version two which has, like the full validation and getting rid of the trump test analysis. The problem is that we need to maintain three different versions with the three different kinds of security guarantees, and if we change something across all versions. I don't know. Rep. Pricing repressing a knob code, then we would need maintain six versions of it all of a sudden, and the problem, I see is like we can very easily shoot ourselves in the in the foot with uf, and I would really like to see the full version of UF going in the problem with that is, I don't see us realistically doing the full version of Uf within a couple of months. And so the way I thought about it, or the way I would propose would be to delay uf and focus really focus on withdrawals and thanks, shouting, and then get us in in a hard fork after Shanghai. I know that's a bit contrarian to what others have said, but I just don't want us to shoot ourselves in the foot again with this, and then having to maintain something. And the thing with the old hard folks, we can eventually, with a history expiry. We can eventually get rid of these rules one hundred and fifty, but with us we can never get rid of them, because there will always be contracts on the different versions. so we will need to maintain the different versions of UF.
Tim Beiko 26:47: Thanks. Yeah, there was a couple of comments in the chats about the UF. Yeah, Thomas, do you want to go next? And then if we have Alex from the UF. yeah, eips we can. We can do.
Tomasz Stańczak 27:06: Yeah. So my proposal is a bit unusual. So I was thinking, That's uh, if it's definitely a right direction and something that I fully support, although I wouldn't like to see it being rushed to mainland, still I think it requires a lot of testing that people would uh possibly be able to test it in parallel to many other changes, and almost like the the Uf. Can be parallelized in the work streams, because Evm itself is very independent from any other changes that we work on. So the proposal is to actually either build a test that or include you have on the test minutes. It's the room, test nets with versioning. Then keep improving the versions of that one until we find a version that we're happy with, and only then push that change to the main net which would lead to test and city room tests to be, not entirely consistent with the mainnet, however, only for the smart contract that would be on different versions. So you would sign that. I'm not sure if it would have to limit those versions of the Vm. To only interact with other contracts with the same version for the sake of testing, not to cost additional trouble. but this is the idea. Then we can then, over time, collect everything that is needed, for you have to have its final form, and whatever version it will be, version five version six, and then say, this is the version that goes to maintenance.
Tim Beiko 28:31: right? Then I guess there's two ways You can do this, either on the New Testnets, if you don't want to, you know. Do you want to break things a bit more or have the existing test minutes. Yeah, Alex, Do you want to give an update from the Epsilon side? And just yeah, your perspective is like championing eof of what you think could be like a good approach here. I don't know if you have.
Alex Beregszaszi 29:04: yeah, maybe just like a brief update. The reason we split them into different vips initially, was due to the idea that it would be much easier to review. You know those changes in isolation. But even when we started with the first version, our goal was to get this full feature set which the five it's accomplished, and one of the main goals of that is to also get rid of dynamic jumps. Then the last two eips. Well, there's one I the very last one, which is the stack validation that I kind of consider as optional. It just simplifies the evening implementations, but it doesn't give a user visible feature. It could speed up the EVM, but that's about it. However, if you skip that, then we likely would skip it forever, because that's what a version of Pump and regarding the I guess, in terms of like uh maturity of the changes. The first one is, of course, 3540 and 3670. Those basically define the structure. Those, I believe, have been, or at least have had, some kind of a review already. obviously not like you know, Merge ready review, but I think some that there were more is that it? And implementations in multiple clients exist for those.Then the following one was the aesthetic jump. I think that change is relatively simple. and that I don't think that there would be any changes to that feature. However, the biggest one is the function sections um, which Hasn't Hasn't received too much attention from all Core dev. So far. So that's the only bottleneck in getting this you know, fully accepted. we do have implementations of that in, I believe in two Evm. Um, but obviously it's not covered in as much as the other changes are. And then, lastly, we wanted to change these last three ips to review status from the draft, because we don't really expect too many changes in them. Um before dev combat that just held through the cracks. Um! And we have been in discussion with solely a team regarding the usage of all of these changes and Daniel responded to some extent on the research discord to state the viewpoint of solidity. Yeah, I think that's all I can really say from our perspective. You would prefer to have the full set. Um, and I want to go. I think this tech validation, as I mentioned the last vip that can be debated whether to include or not; but the others, I would say should go into uh anything,
Tim Beiko 32:20: And when you say single step I mean you know. Yeah, would you rather say that, like the trade off was like sort of this minimal you that we have now in Shanghai versus the whole thing in the fork after. Do you think it's better to delay to have the whole thing? Or is it because we're sort of in between state. Now, where we've like, cfi the first half of it, not the whole thing. So I'm curious. Do you also think even if it requires a delay having them all together is better. Or having This, like subset asap is, is actually valuable. Um, if we can't get the whole thing,
Alex Beregszaszi 33:13: I would say, even the subset is valuable, but obviously way less than a dental set. The preferred outcome would be having all of it in Shanghai, of course. Yeah.
Tim Beiko 33:25: Got it. thanks. That's very helpful.
MariusVanDerWijden 33:33: Great question for Alex. Um, What's What's the steps of like the support in solidity for it? Is it like all going to be supported? Is it something that's acidity once? Oh, it's going to support. And what about other languages? I don't want to do the simple subroutine thing again. But whether it's like the language that's saved, We' not going to support this.
Alex Beregszaszi 34:04: Yeah, I mean, obviously, there's an overlap between the people and Epsilon and sality. And so the discussions for more. you know more closely. There is an implementation of most of the features, except for the function sections and in solidity. Yeah, but it's on the to do list for us to actually implement it. Besides that we had discussions with some other language teams including the half team, and they were interested in actually supporting the function sections, as is but solidity itself, I mean they had nothing against it, of course. I don't think they were any blockers. It is seen as a useful feature.
Tim Beiko 35:04: Yeah. And we had um Daniel from the solidity team comment on discord yesterday. He can't make it. I don't think he's on the call. Yeah, now. And he couldn't make the call. But I pasted his thoughts in the zoom Chat here. Okay, Andrew, you've and that you've had your heads up for also. Yeah, Andrew.
Andrew 35:33: I agree with Marius. I think it's better to implement all your UF changes in one goal with the goal of disabling dynamic jumps. And I also agree with Thomas that it's kind of in almost an independent uh chunk of work. And we can probably have a separate test net for it. So I would think about it. You have changed, as dedicated. You have hard fork, which might happen after can cancune, or with cancone or whatnot, but kind of try to think about the enabling two to two sets of hard folks cancune of one and then that's when we have everything ready for eof we just to synchronise on, whether it goes with cancone or after all, before and I have two additional uh concerns about UF. The last one, as far as I understand it, we need to pick between 2315 and 4750 because they both deal with functions, so that should be resolved with which one of them goes. And my second concern is whether the UF will help or hinder code chunking in your countries. So maybe someone knowledgeable about local trees, perhaps could double check that UF doesn't hinder local trees or even helps potentially. So yeah, I would extract all your work into a separate, dedicated hard work.
Tim Beiko 37:35: Yeah. And there's a call by Alex saying it doesn't hinder chunking, and that they work on it before vocal trees. Anything else you want to add on that front? Alex:
Alex Beregszaszi 37:51: Yeah. So basically uh the headers and all the headers are upfront, so they would be in the first junk in the work of trees in the virtual tree and the everything else would be and subsequent chunks, and I believe the first chunk. Well, the first like one hundred and twenty chunks are cheaper, anyway.And so I think it works well with.
Andrew 38:17: Don't. We have to align to somehow ensure that boundaries between code sanctions like to play nicely with code chunks. So what if your Call section is split between two code chunks, or if somehow you, your code chunk is uh in the middle of an intermediary, like an intermediate. Where do you like to pool? Whose data? What not. So is it a problem at all? Some kind of misalignment between code, section boundaries and code chunks.
Alex Beregszaszi 39:00: I don't think so. So in the code chunking regular Evm code, you need to know the code offset uh which is taking up one byte of a chunk because of jump test analysis. Now you wouldn't need that in the Uf. You may need to load the first junk with the headers. But then you can calculate all the offsets based off that, and I don't think there would be any downside effect be on that
Andrew 39:36: cool
Tim Beiko 39:40: Greg. Messages to say could raise his hand up. But you had a comment about your point of around like 2315 versus EoF Greg. Do you want to take a minute to talk about that?
Greg Colvin 39:55: Can people hear me? Don't know if my mic is working. Okay, 2015 is simpler than the 4075 functions and the other surrounding stuff give slightly less security guarantees rather than saying that all functions take a specified number of arguments and return a specified number of arguments. It simply proves that all functions, that the same functions everywhere it's called, takes the same number of arguments and returns the same number of arguments, so it's simpler. But if we're going with the full suite of EoF. I will happily withdraw 2315 in favour of vo, and I very much support the full suite of EoF. I also support getting it in sooner rather than later because I've got work. I'm doing that. I cannot go live with them until I'm able to reverse the control flow graph of EVm. Code in linear time and space. And until I can generate machine code from byte code in linear time and space. So we have to get rid of dynamic jumps and replace them with subroutines. And I've been trying to do this for years. So every month that we delay it delays the ability to compile bytecode to machine code. We delay it for months. We delay it for years, so it's really so close to ready to go. So I'm getting frustrated by these costs and delays. We couldn't get it in before the merge. We couldn't do it during the merge, and I'll quit whining. That's all, by the way.
Tim Beiko 41:53: Thanks. Yeah, And that's good to know, though you know the 2315 that can sort of be superseded by 4750. If we go that route. Then you've had your hand up also for a long time.
Dankrad Feist 42:07: Sure. Yeah. So I only have a very small comment on EoF. Because I'm definitely an expert on this. But I kind of feel like I want to add to like, basically marry us. This feeling that having a minimal version seems not ideal to me, because reserving an extra version seems a very high cost because it has to be maintained forever, and it will also be an extra version with every upgrade of EVm. That comes orthogonal to this like up code changes and so on. That will not be reflected in eof versions. So yeah, that's just my small comment on us. I also feel like it should be much more like trying to make the first version something that's really worthwhile. And the second small comment I had was with regards to Lucas on an API change. What I wanted to say is, I think actually that this is sorry, this is 1444. So I think what actually it is through that there are so small changes going on right now. They are like what? At least okay. So there's one on the free market, I guess, but otherwise. So what's happening in cryptography Api. So the high level of that is actually completely settled. The only thing that is happening right now is like something that would be deep in the library. And so I think it actually doesn't affect client teams implementing this at all, so they can work with the current. API as it is. Yeah, that's it for me.
Tim Beiko 43:47: Thanks. And I guess Yeah, we also have a couple of folks from cl teams uh on the calls. I see some people who like house folks, and I don't see everyone at the Grandine , I guess they are probably all here. but I'd be curious to just hear quickly from the different cl teams like, you know, after hearing all of this, what's your general view on things. And I don't know I can pick on uh, Paul, if you want LightHouse to go first,
Paul Hauner 44:20: hey? Sure, thanks, Tim. I think mostly what Shanghai involves for us is withdrawals, and ip for it. So where is the opinion that withdrawals need to go in? So I think that's a given for us. For a full four, so a little bit on the fence. I think we probably need a little bit more data and about how it's going to affect the network before we can make a call on it, but I'm keen to work towards making a call. Um, we're implementing both of them, I think something useful from our perspective is that we're keen to see it for four always built on top of Toronto's when we're doing the test, I think that's already given. That's well, obviously on the matter.
Tim Beiko 45:02: Thanks. Terrence.
Terence 45:04: Yup, Hey, everyone. So um with prism we definitely agree with Paul that withdrawal is a must but withdraw. It's also less complicated, much simpler. I believe that we should have a definite in the next one to two weeks, So that's very exciting to see also four, four, four. We have the luxury of calling base and optimism contributing. So we're kind of more on the luck side here, I guess. But yeah, So I mean for us. We're. I think we still remain very bullish for including, I think the unknown here is first is the bandwidth concern is the size of the target. And Max, I think with testing we can get into a pretty good idea on what we should use. But even today I think one mega by two megabytes is too big. I think we can lower it to two fifty States, and five to twelve, I think, at the minimum that's going to dramatically reduce the concern. And now another one is Kzg Ceremony and I think that's being worked on right now. So I'm definitely curious to hear more on the timeline.
Tim Beiko 46:13: Um, yeah, There was a comment about the Kzg ceremony trends. Do you want to give a quick update on that before we go to other Cl teams?
Trent 46:24: Yeah, Was this in the chat, or what's the context.
Tim Beiko 46:26: I am wondering what is the timeline of Kzg ceremony
Trent 46:31: Oh, yeah, yeah, sure. So we have an audit with Sigma Prime, which starts in a couple of weeks November seventh that'll run for a little bit, and then we hope to wrap everything up and have it launched by late November. We're worked with our team to tighten up the website in the past and collaborated with the Psc. Team. But now we're getting to a point where it's in a good place, and once it's publicly launched. It will run for about two months, give or take. We want to make sure there's enough time for as many people as possible to participate. But yeah, that's the the general timeline is should launch before the end of November,
Tim Beiko 47:12: and as I understand it, we only need the final input or output of the ceremony like the main net. So like, even if, say we even had the test, nets go live with 4844. But If we don't have the output of the ceremony, then you could just plug in the different number when we move to the mainnet, and it doesn't really change anything. Implementation wise. Is that right?
Trent 47:49: To the best of my knowledge? Yes, but uh, maybe somebody else with a better understanding can jump in. But yeah, yeah,
Tim Beiko 47:54: And then I don't know if you're still here. But that might be helpful to know when we need the final output? Basically,
Dankrad Feist 48:08: Yeah, I mean, yeah, I mean it. It's really just a file with a list of constants. So yeah, like I mean basically definitely before May not hard for. But I mean, I think even if it where just at a time of the client release. It would be fine like There's nothing new to test like the cryptography works exactly the same, whether that's like some testing version, or if that if it's a final trust setup,
Tim Beiko 48:32: Got it? Thanks.
Dankrad Feist 48:35: And yeah, I'm. Also very optimistic that it will be very easily done by then. I think the team is working very hard on that, and I think it will be fine.
Tim Beiko 48:44: Got it? Any other folks from the Cl. Side when it just
MariusVanDerWijden 48:52: web can also taker the testnet ceremony out of testing so that we have some realistically looking.
Tim Beiko 49:02: Right? Yeah, Phil
Phil Ngo 49:07: Yeah. So basically for us at load start, we echo the same sort of comments from Terence. We're also getting good positive support from some of the other contributors. So there were some things that were addressed in terms of blockers in the 4844 calls, but other than that um! They are being addressed uh so I am optimistic with 4844, and of course withdrawal.
Tim Beiko 49:35: Got it. Any other. See all folks
Enrico Del Fante 49:44: Yeah, take over here and we definitely have the vision that everything will be easier compared to f4844. So we are discussing generally that we might prefer to have them separate, and having the withdrawal first, and then for it later also to have some chance to do other time for doing some clean ups and refinement with, they will do things that we already have for the merge. So, having some time also to settle down, and have better, better things in place, with the help, instead of continuing to add stuff. But these are our recommendations.
Tim Beiko 50:38: Got it? before we go to N. Star. Is there any other Cl team?
Saulius Grigaitis | Grandine 50:45: Yes, so far for the grandine a team, I think it, unless something serious to show off on testnet that existing features work on the form of 4844. I think that would be nice to people the next upgrade
Tim Beiko 51:10: got it? Thanks. Think that's everyone. Okay,Ansgar
Ansgar Dietrichs 51:33: it is.sort of my mike is not working . I'll just post in chat.
Tim Beiko 51:51: okay, Yeah, I'll read it from the chat. And okay. So there's another Yeah, there's another comment by Alex in the chat around, you know there's sort of this implicit assumption of like, you know. There's a high cost to each upgrade, and that means we need to do big upgrades. But would it be simpler to potentially have smaller upgrades and quicker rollouts? we, I guess.Yeah, Oh, Peter, Yeah.
Péter Szilágyi 52:23: And some kind of,and it always fails. So it sounds in theory it sounds nice to You have put our more free control out, but in practice. It takes us forever to test the hard work. Generally clients are kind of lagging on the um income, I think stuff, so we always have to wait until everybody picks up their uh thing and just rolls with it, and then we somehow need to debate on Okay, less for one test, and that's for the other test. That's to wait until it survives and it survives. Okay, we're tweaking again. We need to test again, and it just is a very long procedure, and it actually makes sense that it's long, because you don't really want to mess it up. But that's kind of all. It doesn't matter whether you do frequent hard works or rare hard work, you always need two to three months of just wasting time rolling it out, or at least six months of extra useless time for the sake of it. So it's again. It's kind of a balance. As to I would say that sometimes it's worth cramming one more feature than to wait it out.
Tim Beiko 53:54: It's Marius.
MariusVanDerWijden 53:57: Yeah. So what really? convinced me that this was um in uh in Bogota. Peter said that I think it was something around the lines. If we were to push for growth only with growth, and maybe so the current Cfi stuff. Then we can probably have a hard fog in February, March, and so on for four. We'll probably come in like September or something. But if we put it both together, and to do everything we have one big heart for, then it might be June, or July, and so we will save two or three months if we put them together. It's more realistic to have these bigger, bigger things. I don't like it.I would also prefer. But the bigger hard folks are just way easier, because we need so much time to roll it out to the community. We need everyone to update their most and everything. So that's where the most time is spent.
Tim Beiko 55:33: So I guess, to summarise all of this. It feels like with withdrawals is like a given across everyone Oh, okay, sorry. So Do you want to comment on it? Why did the burden in London come so quickly? I think the reason for that is basically we had really started the work in 1559 in advance. So while Burden was still happening, and then Burden had, like a relatively long roll out period across the multiple test nets, I think during that period we did manage to get like clients to start working on London in, in sort of the parallel, as we were waiting for burden to happen. Um. So I think, It's possible to have forks follow each other and to like, Use this sort of down period as a way to like start implementing more stuff in clients. it did feel like it was like, you know, pushing people a bit at the time, and it was the difficulty, bomb and all of that. But I don't think it's impossible, and maybe there are other differences. It was only el teams. So the coordination was slightly less. so it might be, you know It might still be possible to do something like that. but yeah it I wouldn't say it was trivial to do, either. yeah, And I guess yeah, to go back. What I was saying was at a high level. It seems like every single team is sort of on board with withdrawals, being a part of Shanghai.: I haven't heard anyone mention anything about all of the small kind of utter Cfi eips, but from conversations with client teams and the testing teams in the past month. It doesn't seem like there's any opposition, or like, you know A. Or that there is a ton of work so like the stuff around like the warm coin base, the push zero limiting and metering in its code. It seems like most teams have either a PR. In progress, or can easily make one there. So it seems like that's kind of a pretty solid set we have then there's probably like three buckets that we've discussed So first, EoF. Whether we want to have it as currently specified, have it as a bigger kind of bundle with everything coming together, and and if we make the bigger bundle, whether it should go in Shanghai or not, then the second bucket is obviously four, eight, four, four. So I think. Uh, you know, there's some concern about how ready it is, and how big of a change is relative to everything else. And then the third bucket. That sort of mentioning is, I think, every El team has mentioned that, like removing self destruct is something they would like to consider, and then eleven fifty-three, that sort of mentioned here and there as well. so I guess like I am at a high level, you know, between, like uh, between these things. Is there any client team that feels like there's a big thing missing there, or is this sort of like withdrawals. Just all the small stuff 1444 eos, and then self destruct 1153 kind of the big things. Andrew, as you just raise your hand.
Andrew 59:00: Yeah, I think just a small comment about 1153, I think. It's nice to have but it's not as urgent as to be considered for Shanghai. That's my two cents.
Tim Beiko 59:15: Okay, Marius. sorry I just have my hand up. But the same thing. I also think 1153. Isn't that important? Okay, Oh, and Endsgar, You're against the self-destruct you wanna share. Why, I don't know if your mic is working.
Micah Zoltu 59:49: I can give the quick argument, which is that there are contracts that depend on it, and will break. And we historically have tried very hard not to break people right, and not just a gas tokens like actual people. You can do it from a long time ago.
Tim Beiko 1:00:01: Yeah. And I think, as I understand it, the breakage that would be introduced uh for self destruct with this specific eip. So the eip doesn't remove it. It converts it to send all which sends all of the eats back to the caller. But doesn't this sort of contract there's one pattern that breaks which is using like create to this, and then self-destructing contracts and reinstantiating a different contract. At the same address. I think that's basically the main one. Is that correct? Yes,
MariusVanDerWijden 1:00:43: we need to remove this code. We need to remove it anyway. It's just not that's the fact. And the earlier we do, the less people actually write software with this weird pattern and in mind. so I would like to remove it as soon as possible, so there will be some people that are brick by this. And it's unfortunate. But I think the longer we wait with removing this, the more people will actually shoot the stuff in the foot with this.
Micah Zoltu 1:01:25: I don't think that everything is true, I think, basically, from what I've seen and heard, there's basically one legitimate contract that actually used this pattern. And it was a long time ago, and since then everybody's been advised not to, and no one has since, and this person did it before that advice was popularised. And so If we are going to self-destruct eventually and now versus later, it seems inconsequential, but that is a very big decision to make. I think, to declare that we are going to break a legitimate, immutable contract that is, on a chain not upgradable, and it's not going to work anymore.
Tim Beiko 1:02:03: Andrew, you have your hand up.
Andrew 1:02:06: I think self distress is like removing self. Destruct is, but it is critical for simplifying the code and to to and vocal. But I would suggest, if we want to consider some kind of maybe transition remote measures or not breaking point contracts in the analysis Who is? Maybe it's? Jupiter. I think there was a um. Some analysis was done some time ago. They identified one contract, pop, fine core, or from fine fine finance. And there they say one possible solution is to allow self destructing a contract if it was created in the same transaction. So I would say that we should declare our intention to remove self destruction in Shanghai, and with the default option, just to turn it into, send all. But if somebody screams like between now and the next call that oh, absolutely, you will ruin my contract. Then we should discuss how to uh by possible solutions. But if nobody screams, then maybe it's not that important, and we should proceed.
Micah Zoltu 1:03:36: Someone Someone is already screaming. That's why I like it. I actually want to get rid of self-destruct. But at the same time there is someone out there who is saying this will guarantee break my thing that I deployed five years ago.
Andrew 1:03:50: If it's only if we only allow uh this, this particular scenario, when uh a contract is self destructed in the same transaction, then I guess it's fine because it doesn't entail It's a kind of a virtual self destruct, and it doesn't entail a uh an unlimited uh database deletion, soI think we could conscocoa could consider such limited. But people should uh definitely raise their concerns now and then we should discuss them. That's my opinion.
Tim Beiko 1:04:34: Peter.
Péter Szilágyi 1:04:39: So just have to spend some discussions on the chat about. Why or why not? You will sell this from,and I wanted to just emphasise one use case where we were really self destructive, really really bothering some specifically that some instruct has a fixed gas. Cost. However, if you have a client that implements proper pruning disc proving that in theory I could just self-destruct the massage contract if they if I mean if the contract would have some struct, and that would end up deleting gigabytes of State data from one block to the next. Essentially the work required to execute that operation would be insane and then the only hacky solution is that Well, if this contract is huge, then what? Yeah, Okay, we're not going to prove it. Yeah, Tough luck. That's it. And that's essentially how well our code currently works, and that's kind of bad. And The point is that if we, if some destruct becomes a no off, then yeah. So so essentially some disrupts one of the last main operations where you have a fixed cost, but it can entail an unlimited uh storage cost for approving kind, and that's what that we would like to avoid. Not to have these unlimited, unbounded factors.
Tim Beiko 1:06:05: Thanks.
Guillaume 1:06:07: yeah. So I indeed talked to someone that approached me about this specific topic and like. Andrew said it would be nice to be able to have a special case that if during the creation contract like this for the creation, creation, transaction. Some would call it self destruct, then it should be able to. It would not affect the it should not affect the state, and therefore it should be allowed. The only problem with this is that in the virtual tree context you would still need to add an indicator that this address was missing before. So I'm sympathetic to this request of you know, making self destruction behave differently. If the contract is deleted in the same transaction that is created. But, there's a lot of complexity involved with this, and we should not make this decision. Take this decision. Likely.
Tim Beiko 1:07:12: Yeah, I'll do. Another comment in the chat is that it can force ether into contracts that are non payable.
Micah Zoltu 1:07:23](https://www.youtube.com/watch?v=oQfEW8LdE88&t=4043s): I believe the current proposal would still allow for that. Because we're just changing it. Send all
Tim Beiko 1:07:26: okay. I see. So if you do send all. But then the self-destruct today. But then the address is a non-payable contract. Yeah, with jaws could do this as well.Oh, Peter is your hand up again.
Péter Szilágyi 1:07:32: Yes, I just want to add that if we can identify one to the hands of contracts that are legitimate and get broken, then I think it's perfectly fine to have the special case. Then I mean, we already have the right to be in contact. Special case in the yellow paper is super ugly, but we can actually surgically fix it,and have a solution for those two contracts instead of being a completely different generic solution that happens right now.
Tim Beiko 1:07:36: Right? I guess so. The challenge with that is, it's almost like what we did with Eof. You probably need the first band to deploy new contracts using the opcode, and then you need to retroactively sort of analyse the cases. so clearly. Yeah, it seems like, you know, this is a direction people generally want to go in. There's a lot of edge cases and uncertainty. I don't know if someone wants to, I guess. Try to investigate those in the next few weeks, so that we can have a pure picture. because it seems including, you know, making the current vip. Cfi, as it doesn't give us enough unless we want to explicitly break. You know those contracts, and I think there's security. Some concerns there. So is there anyone who wants to Look into this more in the next few weeks to see if we can come up with a you know proper solution, and something that we can then consider for Shanghai, because I think as is, it's probably under specified. Okay, Jared says he can look into this. thanks, Jared So I guess, for this one we can just discuss it uh further Once we have a better idea. it's good to just start talking about it. So people get aware that this might happen. And so I guess yeah back to like the two. So it seems like the two other big buckets are. Basically What do we do about Eof how do we approach? 4044 I think so for EoF. There was this idea of having a special test net to see if we can get it implemented, narrowing down a version which has some kind of support for all of the operations. And then, you know, some people seem to think this is realistic for Shanghai, Some people disagree. But is that something that would be? We're trying to set up a sort of 444 dev net, which we gradually, you know, add, or we we, we sort of specify what it's like. The minimum set of features that we think are valuable for a full EoF. So beyond what's already 656, you know, if clients can implement this um, I guess a bit like what we're doing with 444 in parallel. yeah, I'm: i'm curious to hear from from Yale teams okay and scar disagrees that If we want this for Shanghai, we have time to do a special test that yeah, curious to hear from promoters.
MariusVanDerWijden 1:11:51: We already have a special test that is mostly for you.It doesn't have it Doesn't Have withdrawals on it.
Tim Beiko 1:12:01: And so what? Yeah, Actually, yeah, What is um? Can someone from the Js team. What's in there?
hdrewes 1:12:15: Yeah, sure uh hoga here from the Javascript team.yes, i'm. I'm always uh live thinking all the time here, along these discussions. What? How? How is the shamong test that might fit in here a bit? yes, Shandong is actually It's kind of a bit of a small experiment from the Javascript team. So Mario once tweeted about kind of like the more or less settled Shanghai yeah piece. And then we had all these implemented, and thought that might be a good publication to test our client implementation and set up a small test on this, and then we made a cooperation with you. Have devops and set up this Yeah. And in the show we don't test that we actually have. Yeah, we have these two Uf yeah pieces. added. So 3540 and 367, And then these other kinds of like uh, settled Cs: Cfi: yeah piece like one coin by coin, base and push zero and limit and metre in it. Code. Yeah, please. yes. And again this is kind of like a small chestnut uh uh uh experiment balloon and We launched this kind of like two weeks ago, and we had to restart it yesterday because of some actually, you know if xbox yeah, and it's running pretty well. And yeah, we are kind of like Nethermind. Wanted to join as well, or did join as well. They're sinking as well. And yeah, that I kind of like our contribution with some small experiments. If there's maybe some space for pre fork, test nets with which fill in a bit in the gap of of this long time period, where we actually don't have test enough, because the hard work is not yet to settle
Tim Beiko 1:14:06: Nice. And I guess yeah is, Would it be valuable to try and activate the like? Two or three missing us on that as well? or I guess, like Nstar was saying, You know, it might not be enough time to actually generate insights and tweak them and whatnot.
hdrewes 1:14:30: Yeah. So we are relatively flexible with this kind of test not set as I always thought it might be a way kind of like that that we stay a bit on board here, if this turns out to be kind of like accepted by the community and somewhat successful. And yeah, this might kind of like be a test that serious that we do where we work really, where we really try to reflect kind of like the current situation of the or the state of the discussion in the in the court of calls or so, so that we kind of like We start with such a test note every eight to ten weeks or so, and if and just l losing from the hard fork just put in the eips, which are kind of like probable to get included in the next or in the next one or two hot forks. So that might be a way to go with these test nets.
Tim Beiko 1:15:19: Got it? Thanks, Andrew. You have your hand up.
Andrew 1:15:23: Yeah, To my mind, we need uh three test nets. One is for withdrawals, and uh, the smaller Eips that go into Shandong high like a warm code base for zero. Limited metre in it calls right? So like about the 444. It's in Shanghai maybe plus potentially self-destruct and the other two test nets would be keep 4844 and eips because we don't know yet whether eip-4844 will go into Shan, I or not, and the same for you
Tim Beiko 1:16:02: Right. I guess if we do that right, if we split in like three testnets. Then how much work is it to merge things? So say you know we have these three test that withdrawals, and this all the Ips is kind of like the basic Shanghai, you know, like for sure, it's going to happen then, if we have this Eo F test net, and this 404 test net, and we want to merge like one and three or one, and two or one and two and three. How much extra work does that? Does that create for us? Peter?
Péter Szilágyi 1:16:39: Yeah. So I think it's more like having a separate. I think the idea is that everybody agrees with the roles, and the small stuff should go into that kind of work based on the hard work. And then the other two tests, I think, would be just these uh proof of concept things so that everybody's kind of on the same page and does it work, doesn't it work, and if it works that we can, we would probably end up with creating a combo desktop or something. So I think the idea of these multiple tests is just to sanity, check how people's implementations are, and just to hop on the sidewalk to ship. And then, whenever we decide okay, we're going. The final list of the appies will be text that we just either launch the last desktop, and we're tested with those changes, everything included. Or yeah, I think that would be the same.
Tim Beiko 1:17:32: And I guess one thing that would be nice, but that is so like the cl folks were saying that 444 is being built on top of a capella. I assume. This means that if we had this, we would call it minimal Shanghai testnet, which is basically this: what's in Shendong now? But it might be even less than what's in Shendong: because if you say you remove the eof ips then I assume that withdrawal test that could interrupt with the Capella test that on this C outside Is And we would like start testing withdrawals a step. Basically. I mean, I know, Alex Stokes. You've been thinking about this. I don't know if this makes sense.
stokes 1:18:26: Yeah, we're sorry you want to add which also to shandong
Tim Beiko 1:18:29: Right? Yeah, I guess you know, don't think of it! It's not anchored to Shanghai Shandong, but, like, say, we had a test n that has on the el side withdrawals, and then all these other small eips, you know, push zero limit metre in it, code and whatnot not eof not 404 that can interrupt with the Capella test that on the Cl Side: Correct.
stokes 1:18:53: Right? Yeah. So I wanted to withdraw. Test not. And if there's a few other sort of, you know, quote smaller Evm things those are fine,
Tim Beiko:1 19:04: so I guess I don't know what my rough proposal to move forward would be, and also like, because client teams have said, it's really valuable to get some clarity on what to focus on Should we move withdrawals and these small eips to be, you know, fully included to Shanghai. leave eof as cfi. I don't know what we do about 444. But then focus on getting this testnet. that's running withdrawals along with all these small eips on the El side, and then just withdrawals on this Cl side have that across our clients. Then, in parallel we could work on the 444 devnets we've been doing already. I think, on the Eos side there's clearly a desire to try and get the whole thing, so I don't know if it's realistic to. If there's enough resources, I guess, across some client teams that to come up with an eof like a full eof definite basic T as well. And so if in the next month we could sort of trial those two things, we might be in a good spot to then see? Okay, What's what's actually involved with what's actually involved for? But no, that's like we already have this core stuff moving into Shanghai. yeah, I'm: curious. Does anyone have an objection to that?
hdrewes 1:20:42: Yeah, I I was just wondering what you suggest that we actually add um withdrawals to our sundown test net, and then also remove the Uf staff.
Tim Beiko 1:20:53: Basically yes, if it's Sheng Don, it can be another test net, because I imagine it might get complicated to just, you know, like that. But yes, what I would suggest is, we move basically the warm coin base ip the push, zero, one limiting and metering in it code. And then the withdrawals we move them all to included. For Shanghai. We start working on a devnet which has those four eips in parallel. We can have another definite that's uh that supports basically full Eos. So to try and see what's like a version of EoF. That we could ship, and not then worry about having to upgrade the version really quickly. And then in parallel, there's already all this work happening on the next, so we can keep working on that. And just from a code management perspective. We would assume that, like both the EoF the next and the 4844 That's kind of built on this um, you know. Call it Shanghai core implementations.
stokes 1:22:05: That sounds good to me. Tim.
Tim Beiko 1:22:15: Okay. So no objections there. So I'll, I'll move those things included. And then yeah, I think about the next call. Okay, Mary is zoned out. Sounds good. He'll realise Monday morning what he signed up for. So that's good. And I think Okay, so I'll move those. It's included. I think, on the next call, when we have all of the kind of utter eips. Come on as well. We can maybe make a decision about it. Do we want a Cfi for 4844? Do we want a Cfi more of the eos stuff. And then you know, if we have some better data on self destruct, or also like 1153 and Dls. We can. We can discuss all of those on the next call. But at least we are for client teams. I think it's clear that like getting started on withdrawals uh make sense, and then, uh, you know, looking at the Eo F looking into four hundred and four, and seeing if we can kind of make progress on those to get them in a good spot for Shanghai. Seems like a good next step. The other thing I think that's where this is starting a discussion now, for Shanghai is. What do we want to think about for activation? So we discussed this a little bit with devcon. basically The idea is that oh, it's sixty-eight after I don't think we could finish the activation discussion anyways today. But Just so, people are aware, basically if we choose, kind of the Cl Side activates using an epoch which is cleanly mapped to a timestamp um, because time and e pops just like map together. Well, on proof of work we would use block numbers. There was a big drift there. Um, with upgrades like withdrawals. We want to ideally coordinate when they happen on both sides. So you want withdrawals to activate uh on the Cl. And then immediately be credited on the el. Otherwise you get a bunch of weird complexity. So I guess I'm curious to hear from teams like, What do they think is the best way to deal with fork activation. One obvious candidate is to move from using block numbers to the timestamps on the But there's a bunch of weird um edge cases that pop up because of that. it's worth it, be I get. And I guess when we're thinking about planning Shanghai. This is something where, if we need to change the activation procedure as well, it does add some work. yeah. So I'm curious to hear from client teams like. What did they think about that and what they see as the best option for activation?
MariusVanDerWijden 1:24:58: So we had a discussion about it in Bogota, and I was the only execution layer person there. And so the consensus layer teams kind of convince me. I did implement it to be clear, they convinced you with time stamps. So yeah, yeah, they convinced me of time. Stamps. I also implemented uh Shanghai forking based on timestamps on the execution layer. Which was possible. There are a few questions, or like a few things that can come up the fork, Id one is um. We can just use the timestamp as the next fork to calculate it, so that's pretty easy. the more interesting things are, the more interesting questions uh for execution. There are clients around retrieving stuff by block number. Basically Right now, you know before you retrieve a transaction by a block, by block number or receipt by block number, you know which rules to apply. but, after this we don't know which rules to apply to the thing that we just got, either from the network or from the database, and we would need to read the header of the block first or we would need to, ex. So if we, if we were to change something in the receipts based on a fork. We would need to always fetch the header first to see if this is the header by number first to see which rules to apply to the receipts. It's not a problem right now, but it might be a problem for other clients, so it's not a problem right now. Forget, but it might be a problem for other clients.
Tim Beiko 1:27:19: Oh, Peter,
Péter Szilágyi 1:27:21: just to that. Essentially, I guess the reason is that when you would, previously to transaction or any other stuff from the Rpc. Currently, you did not get back the block timestamp. You only get the block hash and the block number. So if you want to check which four of these happened, then you would be using an additional fetch. However, in this case, I mean. We could see if Time Sam, all of a sudden, becomes a discriminator. Then we could add the timestamp to the result of these requests, and then you, you still have the same amount of information.So that's our
Tim Beiko 1:28:07: So I guess. Is there something less worse than this basically to consider? My feeling obviously introduces complexity. But there's not really a better alternative. Does anyone have a strong disagreement with that, and I guess is it worth having a sort of eip or Meta? I don't know how to define this, so that's clients, because I understand it's like two parts of it. One is like the activation, but two is like the implementation details which might vary by clients. But is there some part of it that we want to standardise kind of like eip 2124, but not quite.
Péter Szilágyi 1:29:10: that I mean standardised. Seems a bit much, but maybe just have a document which highlights that. Okay, Once we sit on the timestamps take care of Api. That's because they need some extra love.
Tim Beiko 1:29:27: Got it?
Lukasz Rozmej 1:29:29: Yeah. So we should. The standardised Jason. Our Pc: Right? I think we should make those changes explicit so that if someone uses it can count of those being there.
Tim Beiko 1:29:45: Okay, And I guess so. If this is the route we're going, I think we should probably implement that in Sorry, this, like minimal Shanghai. So that's like we basically assume it for some time step and go from there. And I think this is roughly what people have been doing in existing definitions already. So does that make sense to people? And then, once we have, like a first debt or two. We'll probably know exactly how we want to change Jason, our Pc. And we can open PR. For that.But yeah, does it make sense for this first, like withdrawals and small Y ip that nuts they use timestamps, and and we can go from there. Oh, Peter,
Péter Szilágyi 1:30:29: So I guess one interesting quirk could be that if I set up the genesis for a for a desktop, then essentially every previous part for currently defined with block numbers, and then um! This one will be defined, and big future ones will be defined by a timeStamps, If the the previous forks are not all aggregated into block zero. Then I can't imagine a scenario where essentially you say that okay uh London will happen in Block Number ten. But the timestamp of block number one already exceeds. Already we have a scenario, so there's some unexpected us that can have fun if people just use the same genesis as so currently. You can just reuse the same private network, Genesis, for your own testing purposes and the timestamps People need to be aware that you actually need to change your genesis every time you spin up in the
Tim Beiko 1:31:34: right. Okay, Yeah, that's for. And I am for the definite. I feel like we can just have like ten minutes, or whatever either the trigger or something like that. But I do. Yeah, that's an edge case we should document somewhere. I'm: not sure where to go. Okay. So uh, just as okay. We only have four minutes left, and there's two more things, I think. Uh, we should really try and cover. So eth/68 by Marius, and then Gordie um I there's a separate call to talk about Goerli. But if you give a free a minute or two to kind of share it, so that folks who are interested can can show up and discuss that.
Tim Beiko [1:32:12] (https://www.youtube.com/watch?v=oQfEW8LdE88&t=5532s): Marius ETH/68
MariusVanDerWijden 1:32:15: Yes, So eth/68 is the newest version to the East protocol um, and basically we have two ways of sending transactions. we have a broadcast, and we have an announce retrieve scheme. you announce the transaction hashes that you have, and the other person can uh fetch the transactions from you. Blobs for 4844. We don't want people to broadcast these transactions, because this will increase the load on the network. quite a bit. And so we want to not have them broadcast it. Um, and already have them via the announcements. Um, But we would like to have eip, which adds the transaction type and the transaction size to the nodes. Basically you announce the transaction hash transaction type and the transaction size. And so your peer can choose which transactions to fetch. It is written in a way that it can be implemented and rolled out right now. So I like it. It helps us in the future with forum, but we can roll it out right now. And yes, we would like to roll it out as soon as possible, So that we have a lot of people moving over to eth/ 68 as soon as possible.
Tim Beiko 1:34:09: Okay, Altair.
Péter Szilágyi 1:34:11: Yeah, just after that The single denial of service that we've seen on the execution client side for4844 is that these block transactions are kind of large in in in shandong mobile, that we're talking about 128 k transactions and broadcasting them to square root number of peers means that on the order of magnitude you will. That's the same transaction across every link seven times or more. And seven people will get a lot from it, and when transactions are two kilobytes that's not one of them. But when transactions, when you have these large transactions, you really don't want them to be broadcast more than once, and this announced mechanism simply allows us to say that. Okay, it's a lot of transactions that we're just going to announce. So we guarantee that it will for every single pier. Will Max recruit it once. So it's kind of like the optimal uh network bandwidth usage. The cost is that they can see why it will be ever so slightly slower. But I think that's perfectly reasonable for block transactions, and there you don't get thousands of transactions per second, you just have a few. So it's being blocked. It makes it a bit special, and you can uh this. This probable extension allows you to handle it especially and decide how you want to handle it.
Tim Beiko 1:35:40: Got it? Okay, we're already on time. Sorry. It was one thing. I skip. So we're on the agenda. We're obviously not gonna have time to discuss it today, but I would encourage people to review an async, and we can cover this on the Cl call because it's relevant there as well. But basically uh, this, this proposal to add the block value in response to the get payload call and the engine Api And this would help basically validators. Compare local blocks with blocks provided by third-party relays, which is something that we've been talking it all about lately. Um! So I posted. I posted the issue in the chat. I think if people want to review this before the next cl call next week. That would be great, and we can discuss it in more detail there and then. Lastly, I, just before we wrap up a free. Do you want to give a quick rundown on what's happening on Goerli and the call that you have scheduled next week to discuss this.
Afri 1:36:41: Yes, thank you. I keep it very short. So girly is in a really complicated situation due to the supply issues. It's totally easier to buy girls and to get it from a faucet which is not the way it is supposed to work. So I created a discussion with potential ways out of the situation on the issue of magicians phones. It's linked in the Pm. Thread. Please click on it. If this is important for you and I have scheduled a community call next week where we can discuss part out of this pass. Out of this situation 150 in detail. And yeah, I would not underestimate this, because this will affect not only infrastructure providers and application developers, but also might unpick our work for protocol engineering and testing. So if you could spend some time digging into this threat and maybe join the core next Tuesday at three Pm. You'd see, I would really appreciate it. Thank you.
Tim Beiko 1:37:41: Thanks. Um, yeah. It's been kind of weird in Goerli recently. Anyone have final thoughts or comments before we wrap up. Okay, Thank you, everyone. I think. Yeah, we had a lot of good conversations today. I'll make an update from the Shanghai spec , and then for anyone listening on the next call, we'll try to cover a bunch of other potential proposals for Shanghai. So if you have something that you feel really strongly about next week or two weeks from now is the time to show up. Yeah. And then I think about it. If the EoF people and four people can also show up to weeks from now, we'll probably want to continue those conversations as well. Um. But in the meantime, yeah, for client teams withdrawals and these other small Shanghai ips are probably the most solid thing to be focusing on Yeah, thanks, thanks. It done everybody
- Tim Beiko (host)
- Gary Schute
- Enrico
- Tomasz Stańczak
- Andrian
- Oxcasey
- Leo Arias
- Zuerlein
- Potus
- Terence
- Kenway Wang
- Roberto
- Mario Havel
- Paul Hauner
- Vitalik
- Ruben
- Mario Vega
- Kamil Chodola
- Trenton Van Epps
- Afr Schoe
- Alex B.
- Alex Stokes
- Pari
- Tukasz Rozmej
- Andrew Ashikhmin
- Ben Edgington
- Daniel Lerhner
- Danny
- Micah Zoltu
- Marius VanDerWijden
- Pooja Ranjan
- Marek Moraczynski
- Rai
- Greg Colvin
- Lightclient
- Justin Florentine
- Danno Ferrin
- Marcin Sobczak
- Mikhail Kalinin
- Karim T.
- Martin Holst Swende
- Fabio de Fabio
- Pawel Bylica
- Sam Wilson
- Jamie Lokier
- Dankrad Feist