WEBVTT

1
00:15:13.700 --> 00:15:18.319
nixo: Good morning, good morning. We're already live, but we will wait a few minutes to get started.

2
00:17:08.609 --> 00:17:11.539
nixo: Okay, let's, let's go ahead and get started.

3
00:17:12.589 --> 00:17:24.039
nixo: Welcome to All Core Devs Execution number 247. Today's October 8th. And we have successfully undergone.

4
00:17:24.139 --> 00:17:26.929
nixo: Glamsterdam fork on the Sepolia,

5
00:17:27.429 --> 00:17:38.199
nixo: Testnet, which is exciting. Good job, everybody. Does… do the pandas want to give a, An update there?

6
00:17:39.720 --> 00:17:41.060
Barnabas: It was a boring fork.

7
00:17:41.770 --> 00:17:42.570
Stefan Starflinger: Yeah. Good.

8
00:17:45.270 --> 00:17:46.219
Barnabas: Congrats, everyone.

9
00:17:48.180 --> 00:17:50.430
Stefan Starflinger: Do you want to give the update Barnabas or?

10
00:17:55.400 --> 00:17:56.200
Barnabas: Yeah, it was pretty boring.

11
00:17:56.200 --> 00:17:56.770
Stefan Starflinger: you.

12
00:17:56.770 --> 00:17:57.700
Barnabas: Yeah.

13
00:17:58.100 --> 00:17:59.700
Barnabas: Do you have anything else to add?

14
00:18:01.210 --> 00:18:05.989
Stefan Starflinger: It went pretty well, I think. I would also say.

15
00:18:06.180 --> 00:18:10.920
Stefan Starflinger: And, gas limit ramped to 200 million now, which is nice.

16
00:18:11.830 --> 00:18:17.210
Stefan Starflinger: After the fork, that went pretty well, I think. Just some clients needed to update.

17
00:18:24.660 --> 00:18:31.749
nixo: Great. Do we have, any other, any other things that we want to cover before talking about scheduling the Hoodi fork?

18
00:18:39.940 --> 00:18:44.969
Stefan Starflinger: I have some stuff for Mainnet shadow fork for benchmarking, but we can do that after also.

19
00:18:46.550 --> 00:18:54.800
Justin Florentine: Regarding, ePBS, I was curious if we could elaborate a little bit on maybe builder-searcher participation on Sepolia? Are we seeing much?

20
00:18:57.830 --> 00:19:03.919
Barnabas: We're seeing a few builders coming online, but nothing crazy. I'm actually a bit surprised.

21
00:19:04.200 --> 00:19:07.630
Barnabas: That's how little builders are participating in Sepolia.

22
00:19:09.600 --> 00:19:12.930
Barnabas: We currently have 5 builders active.

23
00:19:13.310 --> 00:19:16.219
Barnabas: You know, 4, one of them just exited, so…

24
00:19:16.720 --> 00:19:21.099
Barnabas: And all of those are, I think, either

25
00:19:21.320 --> 00:19:25.689
Barnabas: Titan or Nico, and I'm not sure who the rest of them are.

26
00:19:26.770 --> 00:19:30.070
Barnabas: So it's… All a bit, quiet.

27
00:19:33.730 --> 00:19:35.460
Barnabas: On to our Sigma Prime, so…

28
00:19:35.630 --> 00:19:40.180
Barnabas: Really, the big players are not yet, not yet on Sepolia.

29
00:19:41.310 --> 00:19:42.279
Justin Florentine: All right, thanks.

30
00:19:44.560 --> 00:19:50.019
Barnabas: And we are also seeing that lots of local-built blocks are I'm not sure why.

31
00:19:51.610 --> 00:19:54.840
Barnabas: I guess we're just not, not having enough,

32
00:19:55.850 --> 00:19:58.029
Barnabas: Proposal preferences to send out, or…

33
00:20:00.460 --> 00:20:05.219
Barnabas: Quite uncertain, because we don't draw a better Forsopolia, but maybe we should.

34
00:20:05.790 --> 00:20:06.699
Barnabas: Not sure.

35
00:20:19.750 --> 00:20:25.449
nixo: Great. I think that we can talk about scheduling the Hoodi Fork then.

36
00:20:26.320 --> 00:20:34.919
nixo: I have two slots, here that I think would be, good. They are both.

37
00:20:35.200 --> 00:20:41.229
nixo: the last week of October. One is Monday the 26th, and one is Tuesday the 27th.

38
00:20:41.760 --> 00:20:47.149
nixo: Do… right now, I have defaulted in that, in that pull request to Monday.

39
00:20:47.330 --> 00:20:51.759
nixo: Do clients have any preferences, about those two times?

40
00:20:55.940 --> 00:21:04.010
Barnabas: One thing I would like to raise is, this is a week before Devcon, and the earlier we do, the more time people will have to fly.

41
00:21:04.230 --> 00:21:10.930
Barnabas: So, ideally, I think we should do this as early as possible, and I would vote for Monday.

42
00:21:12.100 --> 00:21:13.559
Barnabas: Even though it's a Monday.

43
00:21:20.640 --> 00:21:24.850
nixo: Great. If no pushback, then we will, schedule that for…

44
00:21:25.250 --> 00:21:29.430
nixo: Monday the 26th at 1742 UTC.

45
00:21:31.080 --> 00:21:34.590
nixo: When do we need to get releases out for that?

46
00:21:35.820 --> 00:21:38.550
nixo: Tuesday does look like a lucky day.

47
00:21:39.500 --> 00:21:42.049
nixo: Can we say a week before that?

48
00:21:43.740 --> 00:21:46.779
nixo: Or is that too… do we need more time than that?

49
00:21:48.710 --> 00:21:50.350
Barnabas: I would do at least 10 days.

50
00:21:51.070 --> 00:21:51.880
nixo: 10 days.

51
00:21:52.360 --> 00:21:56.969
nixo: Okay, let's see if we're doing the 26th.

52
00:22:00.180 --> 00:22:11.549
nixo: So, by next Friday, then. By October 16th, that would be 10 days. That gives, the full week of the 19th through the 23rd for people to update their nodes.

53
00:22:19.640 --> 00:22:23.140
nixo: Tight to get releases out by next Friday?

54
00:22:23.800 --> 00:22:26.640
nixo: What is… what feels like the earliest, potuz?

55
00:22:28.340 --> 00:22:38.860
potuz: It's tight on both ends. It's for the operators, for ourselves to send releases. I mean, it's probably fine, we are probably ready to fork on the 26th.

56
00:22:39.140 --> 00:22:53.029
potuz: But we have, like, staking pools that are… that are deployed on Hoodi, like, all of the home stakers are deployed on Hoodi. It's a much more complicated fork to have than just Sepolia, where we know every validator.

57
00:22:53.360 --> 00:23:07.429
potuz: So if you give them less than two weeks advance on releases, I presume we're gonna have problems, and if we give them more than… I mean, if we give us less, the two weeks, we're not going to be able to put them.

58
00:23:07.660 --> 00:23:11.469
potuz: Right? So we should, like, get a release today or tomorrow?

59
00:23:11.750 --> 00:23:21.379
potuz: In order to be able to be ready for Hoodi. And besides anything, I really think we should have, for Hoodi, we should have a plan, since that's not

60
00:23:21.420 --> 00:23:35.329
potuz: permissioned, we should have a plan, we should make sure that we can, sync from unfinalized, and that we have flags to disable the P2P builders, and to fall back to the trusted builders.

61
00:23:35.770 --> 00:23:41.060
potuz: Or fall back to local building, we should have these, these flags ready on clients.

62
00:23:46.860 --> 00:23:48.439
nixo: Do we not have those flags right now?

63
00:23:49.900 --> 00:23:55.380
potuz: Prysm does not have a way of disabling the P2P stack.

64
00:23:55.820 --> 00:23:57.320
potuz: Immediately.

65
00:23:57.420 --> 00:24:03.849
potuz: It's an easy flag to add, we can add it, but the thing is that… and we don't even need to test it, it's a very simple change.

66
00:24:03.970 --> 00:24:17.039
potuz: But, again, these things add up. We are talking about how… if we want to give two weeks for, say, like, Rocketpool or Lido, then we need to cut up the release tomorrow, and we're gonna be rushing today, therefore, to merge all of these things.

67
00:24:17.590 --> 00:24:23.830
potuz: I really think it's unrealistic. I'm pretty sure we're gonna delay the release, and they're gonna have less than 2 weeks.

68
00:24:33.090 --> 00:24:35.579
Barnabas: When do you propose we do the fork then?

69
00:24:35.890 --> 00:24:36.570
Barnabas: Perfect.

70
00:24:37.730 --> 00:24:56.259
potuz: I do not know. If we do… if we do fork on the 26th or the 27th, which I… I mean, again, this… the dates are fine by me, but then the question is, do we want to give this operate… these large operators, less than a week, or… to… to have releases, or do we want to risk

71
00:24:56.440 --> 00:25:03.050
potuz: Exactly what happened in Sepolia. We, like, the majority of clients had a patch release right before the fork.

72
00:25:03.660 --> 00:25:09.240
potuz: Because the release that came out in the blog post was not the release that actually needed to be used.

73
00:25:09.910 --> 00:25:16.940
nixo: Is there a… is there a reason that, these large operators need more than, say, a week to update their notes?

74
00:25:21.020 --> 00:25:28.749
nixo: Besides just, like, us making sure, like, cat herding and making sure that they're actually doing it. Because I feel like we could commit to… to…

75
00:25:29.150 --> 00:25:34.939
nixo: Bugging people more aggressively to update their notes, since it's…

76
00:25:35.470 --> 00:25:43.449
nixo: a quick operation for them, and it is not such a decentralized validator set as, like Holeski, for example, was.

77
00:25:49.740 --> 00:25:57.779
Barnabas: I think if the 16 is fine by clients, that should give 10 days. I think 10 days is more than sufficient for everyone to update.

78
00:25:58.400 --> 00:26:01.159
Barnabas: And if it's not, then they can update afterward.

79
00:26:02.360 --> 00:26:02.740
nixo: james.

80
00:26:02.740 --> 00:26:08.919
Barnabas: probably 80-90% of the validators sell easily. So it's not like we're going to have a non-finality scenario.

81
00:26:10.800 --> 00:26:14.270
nixo: James, what docs, state that we give 2 weeks?

82
00:26:17.560 --> 00:26:19.659
james: I'll need to find it, but…

83
00:26:20.310 --> 00:26:25.470
james: That's… that's from memory. I thought it was written down somewhere. It was 2 weeks.

84
00:26:28.770 --> 00:26:35.709
nixo: Okay, I can't… I… the only two weeks that's in my head is the two weeks between… between testnets, but I can't.

85
00:26:40.010 --> 00:26:41.440
nixo: Yeah, I'm not sure.

86
00:26:42.400 --> 00:26:51.599
nixo: For now, can we say, Client releases by the 16th, that gives 10 days, for…

87
00:26:52.090 --> 00:27:00.260
nixo: for, operators to upgrade, and that is 8 days from now. Is that too tight for clients to cut releases?

88
00:27:07.550 --> 00:27:09.100
nixo: I I Ivan.

89
00:27:10.260 --> 00:27:16.219
Iván | ethrex: Yes, I'd like to try to move from Monday to Tuesday.

90
00:27:16.290 --> 00:27:31.660
Iván | ethrex: most of the ethrex team will be flying, on… between 26th and 27th. We are making a couple of days to Europe, because to avoid a plus 35 hours flight to India, so…

91
00:27:31.990 --> 00:27:36.769
Iván | ethrex: in that day, we'll be flying. Maybe if we can do it Tuesday, will it be better?

92
00:27:38.430 --> 00:27:44.780
Barnabas: Yeah, but this argument is also a pass to a bunch of other people that will be flying on Tuesday to Wednesday.

93
00:27:45.120 --> 00:27:46.840
Barnabas: So, yeah, the question is…

94
00:27:47.000 --> 00:27:52.619
Barnabas: there… whether there would be more people playing on Monday, or whether there would be more people playing on Tuesday.

95
00:27:54.420 --> 00:27:54.910
nixo: Daniel.

96
00:27:54.910 --> 00:27:55.550
Iván | ethrex: ER.

97
00:27:56.680 --> 00:28:02.269
nixo: Can y'all put in the chat whether you guys will be flying towards the beginning of the week or the middle of the week?

98
00:28:03.640 --> 00:28:04.910
nixo: So that we know.

99
00:28:05.700 --> 00:28:09.429
nixo: If a Monday or Tuesday fork would have more clients available?

100
00:28:10.730 --> 00:28:12.690
Iván | ethrex: Okay, fair. That's fair.

101
00:28:19.640 --> 00:28:20.859
nixo: Any chime in.

102
00:28:26.990 --> 00:28:29.430
nixo: People have no idea when they're flying yet.

103
00:28:31.110 --> 00:28:32.889
nixo: You guys bought your tickets yet?

104
00:28:44.450 --> 00:28:46.690
nixo: Not flying Monday or Tuesday.

105
00:28:46.940 --> 00:28:49.119
nixo: We'll be meeting in person, not flying.

106
00:28:57.950 --> 00:29:06.010
nixo: I will point out that the Tuesday slot is significantly later than, than the Monday slot.

107
00:29:06.430 --> 00:29:18.609
nixo: The… Tuesday slot is… like, 8 PM UTC, and the other one is… 11 Utc.

108
00:29:26.350 --> 00:29:28.899
nixo: Let's, let's default to this Monday slot.

109
00:29:29.140 --> 00:29:34.569
nixo: Yeah, it's… I think better to give a little bit more time.

110
00:29:40.210 --> 00:29:44.189
nixo: Okay, great, we will schedule that for Monday, then.

111
00:29:51.970 --> 00:30:03.339
nixo: And, somebody wanted to just note that, we are confir… to… we should confirm that we did decide that the gas limit is changing right on the fork… fork epoch, correct?

112
00:30:04.130 --> 00:30:07.210
nixo: If that's not anyone's understanding, please speak up now.

113
00:30:13.500 --> 00:30:19.109
nixo: Great. For Hoodi and Mainnet, then, we are planning the gas limit change.

114
00:30:20.330 --> 00:30:21.760
nixo: on the fork epoch.

115
00:30:28.810 --> 00:30:32.900
nixo: Okay, anything else, Glamster? I think, Stefan, did you have…

116
00:30:33.200 --> 00:30:35.460
nixo: One more thing that you wanted to say.

117
00:30:35.700 --> 00:30:38.050
Stefan Starflinger: Yeah,

118
00:30:38.160 --> 00:30:44.429
Stefan Starflinger: So basically, I did the mainnet shadow fork, and the idea was to do one for benchmarking.

119
00:30:44.700 --> 00:30:55.959
Stefan Starflinger: And I went or it went a little bit wrong and right at the same time. So it raised the gas limit by an insane amount.

120
00:30:56.110 --> 00:31:04.260
Stefan Starflinger: To allow for deploying large contracts. But it ended up never lowering the gas limit amount.

121
00:31:04.390 --> 00:31:14.619
Stefan Starflinger: And we also went through, the Gloas fork in the mainnet, shadow fork, which was also not necessarily intended.

122
00:31:14.760 --> 00:31:20.829
Stefan Starflinger: But it went very, very smoothly, which is very nice. So we have a mainnet shadow fork.

123
00:31:21.040 --> 00:31:39.809
Stefan Starflinger: fork transition, already, and we had, builders, during the fork, which was also very nice straight away. And now, we're using that shadow fork, for Snap 2, testing, because there are large blocks, and large BALs.

124
00:31:40.000 --> 00:31:47.349
Stefan Starflinger: And that's probably a good edge case, to test with very large payloads.

125
00:31:47.490 --> 00:31:52.219
Stefan Starflinger: But I'm planning on relaunching the benchmarking shadow fork.

126
00:31:52.280 --> 00:32:08.220
Stefan Starflinger: So this ManageHeaderFork 1 will run till tomorrow end of day, and I'm planning to relaunch it beginning of next week and to do to make sure it runs more smoothly this time.

127
00:32:09.010 --> 00:32:10.520
Stefan Starflinger: That's basically it.

128
00:32:17.650 --> 00:32:19.060
nixo: Great, thank you.

129
00:32:20.740 --> 00:32:22.860
nixo: Do we have anything else on Glamsterdam?

130
00:32:30.630 --> 00:32:33.590
nixo: Alright, almost done with this fork.

131
00:32:37.460 --> 00:32:41.419
nixo: Then we will move on to Hegota.

132
00:32:41.750 --> 00:32:51.560
nixo: And the first thing, I wanted to go through with Hegota was, We have, so far…

133
00:32:56.860 --> 00:33:00.189
nixo: dealt with quite a few of the EL,

134
00:33:01.010 --> 00:33:04.810
nixo: EIPs, but I want to make sure that we, are…

135
00:33:05.100 --> 00:33:11.350
nixo: Thinking about, fork scope, especially, given

136
00:33:12.700 --> 00:33:17.250
nixo: desires to speed things up, use AI to, speed things up.

137
00:33:17.580 --> 00:33:31.549
nixo: So I wanted to give a few minutes to Dan, for talking about, the complexity assessments that they are doing on, EIPs that are being proposed.

138
00:33:33.950 --> 00:33:36.039
danceratopz: Hey, good morning, everyone. Can you hear me alright?

139
00:33:36.550 --> 00:33:37.190
nixo: Yes.

140
00:33:37.680 --> 00:33:38.860
danceratopz: Okay, perfect.

141
00:33:39.840 --> 00:33:45.569
danceratopz: Seems like the monthly laptop boot worked for the audio. Okay, can you see my screen?

142
00:33:47.250 --> 00:33:48.480
nixo: Yep, looks good.

143
00:33:48.890 --> 00:33:54.879
danceratopz: And I'll just share the link to the slides and this site that I created in the chat.

144
00:33:54.900 --> 00:34:10.580
danceratopz: So, thanks Nixo. Basically, I've been mucking about a little bit with, LLMs and EIP Markdown, and trying to see whether the complexity assessments that we do on the steel team can be automated and

145
00:34:10.760 --> 00:34:19.000
danceratopz: whether that data sort of gives us any signal that could help with scoping or with Devnets and whatever. And that's what I'd like to show you today.

146
00:34:19.290 --> 00:34:23.909
danceratopz: So what is a complexity assessment? Basically.

147
00:34:24.239 --> 00:34:43.209
danceratopz: a complexity assessment is like a questionnaire for people that love EIPs, and they can go through this questionnaire, and they can answer questions that tell you what this EIP changes about ethereum. But it's limited to the execution layer side at the moment. So these

148
00:34:43.350 --> 00:34:52.169
danceratopz: Basically, the goal is to try and sort of estimate how much effort it would take to implement the EIP, but scoped to the execution layer.

149
00:34:52.850 --> 00:34:56.350
danceratopz: And this has only existed since Glamsterdam.

150
00:34:56.600 --> 00:35:07.800
danceratopz: Where Mario, like, created this template with 24 questions or criteria. And you can give a score from 0 to 72 to some EIP that you get as input.

151
00:35:08.010 --> 00:35:14.230
danceratopz: And we did this for Glamsterdam, human evaluations at that time, of course, it was already AI-assisted.

152
00:35:16.160 --> 00:35:16.980
danceratopz: And

153
00:35:18.360 --> 00:35:25.239
danceratopz: what would what would one of these questions look like? You've got example in the bottom right hand corner. So like, basically, this is a quite simple example.

154
00:35:26.510 --> 00:35:40.239
danceratopz: did we add in? Did the EIP add any new opcodes? And then you can score it based on whether that was the case, and how complicated these opcodes were, or how many there were. And then you've got some kind of indication of how hard that would be to implement and test.

155
00:35:40.960 --> 00:35:41.750
danceratopz: Umm.

156
00:35:42.140 --> 00:35:55.520
danceratopz: It seemed that the first version of the template had a few pitfalls. And for example, it didn't really take into account across the EIP interaction very well. And Mario did a sort of retrospective.

157
00:35:56.440 --> 00:36:00.340
danceratopz: like evaluation of what the Glamsterdam EIP testing did.

158
00:36:00.510 --> 00:36:06.510
danceratopz: and then calibrated the original template against the effort that he saw in in our repo.

159
00:36:06.630 --> 00:36:11.819
danceratopz: And so this added four new criteria, and the range grew.

160
00:36:12.200 --> 00:36:16.989
danceratopz: But in particular, it catches, captures cross EIP interaction as well.

161
00:36:19.180 --> 00:36:20.210
danceratopz: And.

162
00:36:20.610 --> 00:36:39.180
danceratopz: like Mario and I were talking about this and like wondering if it's like actually useful. I mean, who knows? Like, you know, it's quite hard to sort of assess these things. How how much signal does these does this thing give? And we sort of vibed a little bit and had the idea that what we could do is we could use LLMs to basically do a retrospective study.

163
00:36:39.310 --> 00:36:47.039
danceratopz: of these EIPs, sorry, of all EIPs and all previous forks, in order to really see whether.

164
00:36:47.610 --> 00:36:59.109
danceratopz: we can somehow see that the amount of effort that this EIP questionnaire tells us, like, does it really, like, represent how much time it takes to ship the EIP?

165
00:37:00.190 --> 00:37:01.360
danceratopz: And…

166
00:37:02.490 --> 00:37:11.979
danceratopz: So I think that's pretty — so yeah, basically, I'll just say I just reran this late last night, and I reran it with Opus 5.5.

167
00:37:12.180 --> 00:37:21.910
danceratopz: And it's ran, like… so that it may… Claude will basically, like, evaluate any EIP, and for the retrospective assessments, it tries… I've picked dates.

168
00:37:22.190 --> 00:37:30.230
danceratopz: from the EIPs markdown and commit refs, which represent when, like, fork development started or scoping stopped.

169
00:37:30.610 --> 00:37:39.219
danceratopz: and took a snapshot of the EIP. And asked Claude to do his best to not apply his knowledge afterwards in order to evaluate it at that point in time.

170
00:37:39.530 --> 00:37:42.210
danceratopz: So somehow sandboxed. It's not perfect, but

171
00:37:42.520 --> 00:37:45.709
danceratopz: It will have been trained on that data, but it is what it is.

172
00:37:48.220 --> 00:37:51.719
danceratopz: And when I did this study like 6 weeks ago with like

173
00:37:51.830 --> 00:37:54.799
danceratopz: Soul 5.6 or something, and,

174
00:37:54.940 --> 00:38:11.709
danceratopz: it seemed to over evaluate a lot of things, and it seemed to get things really blatantly wrong. So I just I've made a proposal to improve the template again, but it keeps the criteria so it shouldn't really change what human rights, but it tries to disambiguate the language so that an LLM. Can be a bit more precise about its evaluation.

175
00:38:12.920 --> 00:38:20.389
danceratopz: You can have a look in more detail afterwards, but it's just basically trying to keep the wording a bit more,

176
00:38:21.000 --> 00:38:27.080
danceratopz: a bit more precise to avoid disambiguity for the robots.

177
00:38:30.160 --> 00:38:43.239
danceratopz: So I think, at this point, I will go away from my slides, because the site's a bit nicer, and so basically what I… I posed the question, does, like, the complexity… the accumulated complexity for the entire fork, does it somehow track

178
00:38:43.530 --> 00:38:57.840
danceratopz: the time to mainnet and you can see if you count. So from all these evaluations you get all these scores, you get a score per EIP, and then you can accumulate all these scores and add them all up, and you get a tally.

179
00:38:57.850 --> 00:39:08.490
danceratopz: And the blue is basically what we could tell at the time of the scoping cutoff. And then the orange here is what was added later on that we didn't foresee or what we felt was necessary afterwards.

180
00:39:09.960 --> 00:39:17.249
danceratopz: And then here you can have a look, of what… so every color here is a question in the assessment, and,

181
00:39:17.530 --> 00:39:35.730
danceratopz: you can see what which forks kind of contributed. You know what what complexity contributed to the effort of of those of those forks. What's interesting is, if you normalize each fork to 100, the breakdown is is kind of strangely similar. And I think that's mainly because a lot of our work

182
00:39:35.910 --> 00:39:37.790
danceratopz: is,

183
00:39:38.870 --> 00:39:46.729
danceratopz: is kind of dominated by edge cases, by cross… so, cross-EIP interactions, by things that forgot to get specified.

184
00:39:47.140 --> 00:39:55.150
danceratopz: From security and performance in particular for the benchmarking effort and gas repricing for Glamsterdam

185
00:39:55.340 --> 00:40:08.220
danceratopz: And so a lot of the effort for a fork is dominated by these things. On the left-hand side, you kind of see more concrete things like, we got a new precompile, we got a new opcode, we changed gas constant. And these are sort of the less predictable things, I'd say.

186
00:40:10.260 --> 00:40:23.820
danceratopz: If you go to the individual forks and EIPs, there's a lot of information here, and it's just to, you know, give… I think it's useful to look at. It should be taken as one data point. It's,

187
00:40:24.510 --> 00:40:27.120
danceratopz: You know, it's not absolute, and it needs work.

188
00:40:27.520 --> 00:40:33.950
danceratopz: But basically to answer our question, what with that data, the amount of complex. So

189
00:40:34.150 --> 00:40:38.900
danceratopz: On the x-axis, you're looking at the complexity score for the whole fork.

190
00:40:39.440 --> 00:40:40.200
danceratopz: Why not?

191
00:40:40.510 --> 00:40:45.279
danceratopz: accumulated. And then… on the Y-axis. What you see

192
00:40:45.460 --> 00:40:50.440
danceratopz: is for time from the first to execution layer client devnet

193
00:40:51.360 --> 00:41:06.580
danceratopz: until mainnet. How many days that was. And yeah, I mean, doing a lease squares here doesn't really make much sense, but it's kind of fun. So I did it anyway. And if you kind of what you can do in this little widget is you can. You can like you can.

194
00:41:07.150 --> 00:41:16.090
danceratopz: you can like click or remove or add the Ips, and then you can see more or less where this complexity moves, and where where that would that where that would land.

195
00:41:17.580 --> 00:41:24.180
danceratopz: So you can have a play around with that. But basically, what's shown at the moment is all SFI and all CFI VIPs.

196
00:41:24.320 --> 00:41:34.500
danceratopz: At the moment, that's 14 EIPs. That's a lot. And we're already at the most complicated fork before we would CFI any of the other PFI EIPs.

197
00:41:35.310 --> 00:41:41.679
danceratopz: I think that's pretty much it. I would just like to say one more thing, and that's more…

198
00:41:42.950 --> 00:41:45.960
danceratopz: More of an outlook, about this work, so…

199
00:41:46.340 --> 00:42:03.800
danceratopz: all these numbers, are we optimizing, like, for the right thing? And, I mean, these provide signals, but I don't think we should be focusing AI tooling on these numbers at all. Like, I don't think it should be the main focus. There's a bigger fish to fry here, and I think we should now start running this stuff

200
00:42:04.380 --> 00:42:09.940
danceratopz: regularly on EIPs as they come into ethereum EIPs.

201
00:42:10.090 --> 00:42:16.199
danceratopz: And use this tooling to actually provide signal about Whether there are contradictions.

202
00:42:16.570 --> 00:42:24.720
danceratopz: Underspecified aspects, inconsistencies between a required EIP and the EIP being studied.

203
00:42:25.140 --> 00:42:30.750
danceratopz: and help provide tooling to EIP authors in order to

204
00:42:31.680 --> 00:42:40.839
danceratopz: to then improve their specs, which will then improve and help people's lives, implementing respectively agents lives and implementing these specs.

205
00:42:42.470 --> 00:42:44.990
danceratopz: All right, that's about me. Thank you very much.

206
00:42:49.020 --> 00:42:51.159
nixo: Thanks very much, Dan. Mark?

207
00:42:51.970 --> 00:43:11.439
ethDreamer (Mark): Yeah, did you have a look at actually implementing these EIPs? Because, like, for example, EIP7549 was, like, in Electra, where we changed the attestation, and from a spec point of view, it was quite simple, but from an implementation point of view, it was quite difficult, so… Like, are you… are we including just…

208
00:43:11.700 --> 00:43:14.950
ethDreamer (Mark): the… Time there as well.

209
00:43:15.180 --> 00:43:18.560
ethDreamer (Mark): to actually… You know, put this in clients.

210
00:43:18.990 --> 00:43:27.099
danceratopz: I think it's a fair question. And I mean, for all this study, I asked myself lots of questions like, what am I doing with my life? Like, is this worthwhile?

211
00:43:27.120 --> 00:43:39.079
danceratopz: at the end of the day, the LLMs are getting better every day, and, essentially, a complexity score could just be, in the future, a one-shotted EIP, right? Like, why not just implement it and then see what happens?

212
00:43:39.300 --> 00:43:49.709
danceratopz: And I mean, currently, we don't automatically do an implementation. We could think about that as things get better and better.

213
00:43:49.980 --> 00:43:58.599
danceratopz: What I can say is today that the SPEX team on the EL side has implemented, or they've got PRs up for every CFI

214
00:43:58.790 --> 00:44:06.030
danceratopz: the EIP. Unfortunately, we haven't updated the human complexity assessments that correspond to those implementations.

215
00:44:06.410 --> 00:44:11.930
danceratopz: That'd be nice to do. It's just a lot of work. I guess it's just another thing to do.

216
00:44:12.470 --> 00:44:17.460
danceratopz: But it would be… Worthwhile, in my mind, to do that in order to

217
00:44:17.590 --> 00:44:25.540
danceratopz: as a verification against against the the LLM outcome and and basically see if How good the match is.

218
00:44:26.140 --> 00:44:31.670
danceratopz: So you can find some human scores, like, on the site, but they're

219
00:44:32.660 --> 00:44:36.050
danceratopz: You can't really compare it one-to-one, because they're on an older version of the spec.

220
00:44:36.050 --> 00:44:45.999
ethDreamer (Mark): I don't even mean human scores. I just mean the difference between like how quick is this thing to write up a spec for versus how quick is this actually to write an implementation in all the clients.

221
00:44:46.000 --> 00:44:56.229
danceratopz: So I see where you're getting at, and I think that probably the most important thing would be to have a dashboard which shows whether the spec is worth implementing yet.

222
00:44:56.490 --> 00:45:04.490
danceratopz: So… I would like to have what you what you're suggesting. But I suggest that basically the first…

223
00:45:04.880 --> 00:45:07.530
danceratopz: The first step is really to do

224
00:45:07.640 --> 00:45:14.610
danceratopz: a sweep over this over the my pound spec to validate it so not necessarily to get a number, but to get

225
00:45:15.000 --> 00:45:16.910
danceratopz: The fact that,

226
00:45:17.200 --> 00:45:25.680
danceratopz: this line of spec contradicts the value listed in the table, for example, and just silly things like that, or or more reasonable, more important things, or

227
00:45:25.810 --> 00:45:28.060
danceratopz: For example, the,

228
00:45:28.690 --> 00:45:39.310
danceratopz: some downstream EIP stays consistent with its dependent EIP. So, for example, with frames and keyed nonces, the keyed nonces EIP

229
00:45:39.650 --> 00:45:49.179
danceratopz: if something changes in 8141, we get feedback immediately that the dependent EIPs need updating, and that, you know, if someone forgot to do it, for example.

230
00:45:49.820 --> 00:45:53.040
danceratopz: I would say that's the first tooling that I'd like to have.

231
00:45:53.330 --> 00:45:59.099
danceratopz: And then… Then you can go for the fully automated implementation, and then you can

232
00:45:59.260 --> 00:46:00.770
danceratopz: Do a human review.

233
00:46:03.560 --> 00:46:05.620
danceratopz: I hope that answers your question somewhat.

234
00:46:19.880 --> 00:46:23.779
nixo: Great. Does anybody else have any comments on that?

235
00:46:23.970 --> 00:46:30.080
nixo: I think that this is a really useful place to start out, to… Make sure that they're…

236
00:46:30.460 --> 00:46:34.360
nixo: Stomachs aren't bigger than our… A.

237
00:46:34.970 --> 00:46:42.980
nixo: whatever the phrase is, so that we don't over-scope this fork, because we do have a lot of EIPs, still to scope.

238
00:46:45.590 --> 00:47:00.070
nixo: With that, we will move on to the next agenda point. I wanted to give, 2 or 3 minutes to Lukasz, who wanted to talk about, actually speeding up and better parallelizing these works.

239
00:47:00.600 --> 00:47:11.040
Łukasz Rozmej: Thank you. One comment about the tool. I like the tool. I think it's probably can be iterated upon and made better, even if it's

240
00:47:11.040 --> 00:47:20.659
Łukasz Rozmej: already useful today. And I agree that's actually giving LLMs EIPs to prototype, not only to look at the spec.

241
00:47:20.840 --> 00:47:27.100
Łukasz Rozmej: Made them do better assessments, because they often, discover things while they're doing it.

242
00:47:27.550 --> 00:47:33.780
Łukasz Rozmej: So, my… going to my point, which is somewhat similar, that I would prefer

243
00:47:33.920 --> 00:47:49.390
Łukasz Rozmej: to try to accelerate and doing more hard forks per year, doing more work in parallel, doing more things. What inspired me? So, for example, in Nethermind, we are currently

244
00:47:49.390 --> 00:47:57.770
Łukasz Rozmej: implementing EIPs as soon as they get CFI'd. We already have 100,

245
00:47:57.770 --> 00:48:04.729
Łukasz Rozmej: 50 PRs related to Hegota, most of them already merged, I think 12 are open.

246
00:48:07.250 --> 00:48:08.470
Łukasz Rozmej: we can go…

247
00:48:08.570 --> 00:48:17.370
Łukasz Rozmej: really fast and even faster. This is, this is not a problem for us, so implementation is somewhat solved.

248
00:48:17.510 --> 00:48:31.469
Łukasz Rozmej: And I think the… the main problems for speeding up is actually coordination, testing, and other things, which were always really, really hard. But we are…

249
00:48:31.500 --> 00:48:38.589
Łukasz Rozmej: doing better tools. One of them we just saw. We have forecast which actually streamlines a lot scoping.

250
00:48:38.600 --> 00:48:54.239
Łukasz Rozmej: We have initiatives like Bantek initiative to standardize tracing, which I think should be looked upon and studied by more people how it works. I can…

251
00:48:54.280 --> 00:48:57.740
Łukasz Rozmej: send the link in the chat, I will drop it now.

252
00:48:57.910 --> 00:49:17.130
Łukasz Rozmej: Basically, he's leading that, he's coordinating on many levels and getting things done. I think we should create more different tools that, for example, would help, EIP champions to be more involved in both,

253
00:49:17.620 --> 00:49:29.920
Łukasz Rozmej: implementation to some extent, and testing, and other things like that, so we should involve more people, especially for not the biggest EIPs, so not the ones, not the headliners that have all the attention, but

254
00:49:29.930 --> 00:49:37.800
Łukasz Rozmej: Things that are smaller, it's good to have more people owning that, but we need to give them more… build for them, and give them more tools to…

255
00:49:37.860 --> 00:49:45.950
Łukasz Rozmej: to easy come and easy have a full picture of the state of the EIP, of the state of the test, on everything.

256
00:49:46.010 --> 00:49:59.379
Łukasz Rozmej: We can also automate a lot of things, like, I don't know, test is failing, and LLM already opens a PR with a fix for the client team to look at. That's a very easy thing to do.

257
00:50:00.080 --> 00:50:09.279
Łukasz Rozmej: And if we have a good dashboard for that and good notification systems, I think we can like shorten the feedback loops by huge amount.

258
00:50:09.500 --> 00:50:23.129
Łukasz Rozmej: I don't want anyone to be replaced by LLMs and AI. I think that the people should still steer it, and should decide it, and should review it. I am reviewing hundreds of

259
00:50:23.320 --> 00:50:26.439
Łukasz Rozmej: of PRs per month now in Nethermind.

260
00:50:26.470 --> 00:50:44.960
Łukasz Rozmej: So I still think this is… this is how it should be done, and I don't… we shouldn't give the steering wheel away, but we… we can do a lot, a lot, a lot more, and especially focusing on this kind of tools that would streamline things, that would make things

261
00:50:45.020 --> 00:50:49.520
Łukasz Rozmej: Very easy to spot, that would allow less…

262
00:50:49.800 --> 00:50:59.889
Łukasz Rozmej: Like I said, for example, more EIP champions to be involved, and more like a product owner role, rather than just writing a spec and forget it.

263
00:51:00.070 --> 00:51:09.940
Łukasz Rozmej: which sometimes happens. So those those are kind of my thoughts. I don't have like all the specifics, and I'm happy to start a debate and

264
00:51:10.110 --> 00:51:17.200
Łukasz Rozmej: Maybe prototype something on my own of this kind of tools if I have a good idea how to, what is needed.

265
00:51:19.230 --> 00:51:20.310
Łukasz Rozmej: That's it.

266
00:51:21.230 --> 00:51:29.649
nixo: Thank you, Lukasz. Before I move on to Mark and Justin, I'm just gonna say I'm gonna timebox this. I don't think that we should have this.

267
00:51:29.820 --> 00:51:38.269
nixo: too much of a conversation here. I think this would be a really good topic for Mumbai, for in-person working, but, yeah. Mark?

268
00:51:39.280 --> 00:51:43.099
ethDreamer (Mark): Yeah, I… Kind of just also want to echo the sentiment, because…

269
00:51:43.100 --> 00:52:00.500
ethDreamer (Mark): Like, I can remember back in the Electra fork scheduling, when we were considering MaxEB, like, at the time, just due to the resources that we had, we basically had one client, Prysm, that had, like, even been able to… had the bandwidth to, like, look into it and start to implement it, and we had…

270
00:52:00.500 --> 00:52:05.580
ethDreamer (Mark): Just at least at first, it was just potuz who had had like

271
00:52:05.890 --> 00:52:12.240
ethDreamer (Mark): any kind of handle on how complex MaxEB would be, and then…

272
00:52:12.470 --> 00:52:22.890
ethDreamer (Mark): So we kind of went with that because it was all we had, and then later we kind of reassessed that, and that's how Max EB ended up getting in. But the, the point is that like.

273
00:52:23.110 --> 00:52:29.470
ethDreamer (Mark): Yeah, we are in a different regime now. Like, it's totally possible to have every single EIP

274
00:52:29.630 --> 00:52:42.490
ethDreamer (Mark): all the, like, at least initially spec'd and through implementation. Even if it's AI slop, and then rated against each other. And that's going to realistically be more work than.

275
00:52:43.170 --> 00:52:58.090
ethDreamer (Mark): like we've ever had in the past. For… for as much as you can say is, like, it may not be correct, it's not a… it's not foolproof, and all of that kind of thing, it's still significantly more, like, vetting than we've basically ever had.

276
00:52:58.460 --> 00:53:03.310
ethDreamer (Mark): before, so I think, yeah, the taking advantage of that would help significantly.

277
00:53:07.940 --> 00:53:08.740
nixo: Justin.

278
00:53:17.180 --> 00:53:18.100
nixo: Maybe.

279
00:53:18.380 --> 00:53:19.440
Gary Schulte: You're muted, Justin.

280
00:53:20.600 --> 00:53:23.609
Justin Florentine: Great, alright, let's try that again.

281
00:53:23.790 --> 00:53:28.469
Justin Florentine: So, yeah, two points I want to make. You know, I'm generally.

282
00:53:29.110 --> 00:53:33.079
Justin Florentine: averse to speed for speed's sake. However.

283
00:53:33.260 --> 00:53:38.740
Justin Florentine: I do see the writing on the wall, and I do think that there's plenty of capacity here, to…

284
00:53:39.490 --> 00:53:40.649
Justin Florentine: To take that up.

285
00:53:40.740 --> 00:53:57.690
Justin Florentine: So, I think I'd like to frame this question around, great, we have this new capacity that's been unlocked. Do we have specific things that we want to do with it, or do we just want to randomly accelerate? So, for example, PQ. I think that's probably the only thing that I see on our roadmap.

286
00:53:57.690 --> 00:54:13.519
Justin Florentine: that is a clear and present danger, and that if I had unlimited capacity to accelerate, I would accelerate in that direction. So I would like us to be specific about this, and follow-up point to that is, like.

287
00:54:14.310 --> 00:54:22.270
Justin Florentine: Lukas, I liked your write-up, it was very good. The idea of kind of just going towards 4 hard forks a year of the same size.

288
00:54:22.270 --> 00:54:43.570
Justin Florentine: to me seems a little arbitrary, and I'm sure that's really, you know, that's just a starting point, that's just a, you know, an idea. But, you know, maybe we couch this in terms of, let's just accelerate, let's just see how fast we can go, without forcing a target that we feel that we have to meet, because there's just… there's just so many unknowns here.

289
00:54:43.650 --> 00:54:46.879
Justin Florentine: So yeah, I just wanted to float that out there, thanks.

290
00:54:47.680 --> 00:54:49.220
nixo: Oops. Luis?

291
00:54:50.990 --> 00:55:10.460
Luis Pinto: Yeah, I wanted to raise a point about the specs and the use of AI writing specs. I think we need to be, like, specific, simple and concise on the spec side, because that's really what drives AI implementations.

292
00:55:10.620 --> 00:55:26.869
Luis Pinto: And, if we are vibe coding specs and, implementations, then, aren't we kind of losing a bit, the side of client diversity that are interpreting, the specifications?

293
00:55:28.050 --> 00:55:38.349
Luis Pinto: on each own, and being critic about the specification, so which allows us to improve, and make the best version of the EIP

294
00:55:38.870 --> 00:55:48.599
Luis Pinto: yeah, I… I would like, like, to hear, like, how do we solve this problem, and, what's your thoughts about that?

295
00:55:53.640 --> 00:56:05.630
Łukasz Rozmej: So, client diversity doesn't… shouldn't be considered in terms of the core spec, because we… clients need to agree on the core spec, actually, so it's actually the other way around.

296
00:56:05.630 --> 00:56:17.080
Łukasz Rozmej: All the testing we are doing is to make sure that clients do agree on the core specs and all its edge cases, so we don't want diversity of spec, because those are consensus issues.

297
00:56:20.530 --> 00:56:28.239
Ben Adams: Just to follow up on your point, Justin, PQ, for instance, I don't think is an easy thing

298
00:56:29.220 --> 00:56:43.509
Ben Adams: To accelerate with AI and maybe in terms of implementation and, how it works. But I think the main bottleneck, bottleneck there is decision making and.

299
00:56:43.800 --> 00:56:45.269
Ben Adams: We can't really do that.

300
00:56:45.880 --> 00:56:47.130
Ben Adams: With AI.

301
00:56:47.130 --> 00:56:49.760
Justin Florentine: And I think that's kind of my point here.

302
00:56:50.150 --> 00:56:53.710
Justin Florentine: Like, I think that's… That's actually a huge problem.

303
00:56:53.840 --> 00:56:56.879
Justin Florentine: Right? Like, how long does it take us to schedule a hard fork?

304
00:56:57.460 --> 00:57:01.949
Justin Florentine: That's not a thing that we let AI do, and I'm not sure that we should.

305
00:57:02.480 --> 00:57:09.929
Ben Adams: Yeah, but there's a lot of admin, and there's a lot of stuff that can be automated around it. That's…

306
00:57:10.330 --> 00:57:11.230
Ben Adams: them.

307
00:57:12.010 --> 00:57:14.300
Ben Adams: Yeah, that could accelerate it.

308
00:57:14.830 --> 00:57:18.070
Ben Adams: But yeah, the decision making we still have to do.

309
00:57:18.970 --> 00:57:23.310
nixo: I'll mark, and then let's let this be the last comment.

310
00:57:24.730 --> 00:57:33.600
ethDreamer (Mark): Yeah, that's exactly it. Like, for initial assessment, before we make any decision, like, it's either we have

311
00:57:33.780 --> 00:57:53.709
ethDreamer (Mark): I mean, maybe if some dev is really driven for one EIP, then they can go further and look at it like a human, but when it comes to, like, the myriad of EIPs that we have to consider for a fork, it's… like, an initial vibe-coded spec and vibe-coded implementation is fine for, like, an initial score and initial assessment, because the alternative is nothing.

312
00:57:53.740 --> 00:58:05.940
ethDreamer (Mark): Because we don't have the resources to vibe, or to spec out and thoroughly look at everything. But then once we have something to help us wrap our heads around all… everything that we face.

313
00:58:06.050 --> 00:58:10.950
ethDreamer (Mark): Then obviously we're gonna go thoroughly look at and do things.

314
00:58:17.320 --> 00:58:18.850
nixo: Great.

315
00:58:19.120 --> 00:58:24.889
nixo: I feel like this is fruitful conversation, and I hope that it continues at Mumbai, because…

316
00:58:25.370 --> 00:58:27.930
nixo: Lots of lots of things are changing in this.

317
00:58:28.500 --> 00:58:29.609
nixo: In this land.

318
00:58:30.500 --> 00:58:41.410
nixo: We can move on to, Scoping. The first thing that we have is, from Ben, there is…

319
00:58:41.770 --> 00:58:45.080
nixo: So we have 11 EIPs left in, in the…

320
00:58:45.320 --> 00:58:52.669
nixo: PFI status, but Ben has a new EIP that he'd like to talk about, adding to the PFI list.

321
00:58:54.610 --> 00:59:01.069
Ben Adams: Yeah, so this, we already did half of this, the original, in,

322
00:59:01.990 --> 00:59:07.710
Ben Adams: Glamsterdam, which was increasing the contract size and the other half was,

323
00:59:08.040 --> 00:59:18.029
Ben Adams: to charge based on the contract size. And we didn't do that. So this is reintroducing that aspect, and this comes from the testing we did.

324
00:59:18.640 --> 00:59:21.690
Ben Adams: And it showed that…

325
00:59:22.500 --> 00:59:38.009
Ben Adams: this… this will potentially be our new ceiling based on how many contracts we can load, and based on disk speed. So the idea is we… we… I would like us to reconsider, not necessarily, you know, CFI it for the fork.

326
00:59:38.170 --> 00:59:42.370
Ben Adams: But reconsider the metering based on contract size.

327
00:59:45.740 --> 00:59:56.049
nixo: Cool. Does anybody have any opposition to adding this to the PFI list, assuming that we will not make a decision about it today, but we'll make a decision about it on the following call, which is our last scoping call?

328
01:00:03.050 --> 01:00:03.890
nixo: Cool.

329
01:00:05.650 --> 01:00:06.560
nixo: Okay.

330
01:00:06.900 --> 01:00:14.080
nixo: Then we'll move on to the, 11 EIPs that need decisions. I'll share my screen.

331
01:00:14.710 --> 01:00:15.700
nixo: See?

332
01:00:18.970 --> 01:00:22.959
nixo: Make sure I choose the right screen. Alright, can you guys see my screen?

333
01:00:25.320 --> 01:00:26.769
jochem-brouwer: Yes, yes, yes.

334
01:00:27.260 --> 01:00:27.930
nixo: Great.

335
01:00:29.710 --> 01:00:36.479
nixo: Okay, I'm gonna… Put the chat in it, too, so that…

336
01:00:40.740 --> 01:00:46.470
nixo: Livestream can see that. Okay, Where are we? Okay.

337
01:00:46.700 --> 01:00:48.520
nixo: So, I've ordered this by…

338
01:00:48.640 --> 01:00:55.399
nixo: Sort of what seems like it has consensus, versus what we need to talk about.

339
01:00:56.370 --> 01:00:59.259
nixo: Because we've already… we've already had these conversations.

340
01:00:59.470 --> 01:01:14.639
nixo: And then what seems like an easy DFI. So the first three, that we're looking at, there was pretty okay consensus. These ones, look like they all have, based on.

341
01:01:14.940 --> 01:01:27.269
nixo: Dan's assessment, medium complexity, so I want to make sure that we're not just throwing everything into the fork. Let's start with the highest, the highest rated one, 5920.

342
01:01:28.400 --> 01:01:32.320
nixo: This got, Decent.

343
01:01:32.920 --> 01:01:37.700
nixo: Decent ratings for most clients, with most clients in support just saying.

344
01:01:38.060 --> 01:01:44.099
nixo: It's… Something that we would like, but we're not sure that it's urgent.

345
01:01:45.790 --> 01:01:49.510
nixo: I am gonna, just…

346
01:01:51.190 --> 01:01:56.370
nixo: So, for 5920, this is the last one that we had that was the highest rated.

347
01:01:56.490 --> 01:01:59.680
nixo: Are we okay CFI-ing this one?

348
01:02:09.930 --> 01:02:19.489
nixo: Is there any, push for DFI-ing it based on keeping the scope smaller? Oh, zoom in? Okay.

349
01:02:29.680 --> 01:02:30.440
nixo: So…

350
01:02:36.770 --> 01:02:37.490
nixo: Ben.

351
01:02:39.140 --> 01:02:47.220
Ben Adams: I'm keeping the scope smaller, I mean, it's not, it's not an SFI, so I don't think there's a problem.

352
01:02:49.280 --> 01:02:54.250
Ben Adams: Okay. We can always… we can always do another round where we… we DFI-based funds.

353
01:02:56.670 --> 01:03:00.460
nixo: Okay, I'm gonna move to CFI 5920, then.

354
01:03:06.990 --> 01:03:11.619
nixo: And then we can move on to 8151, so ecRecover.

355
01:03:13.320 --> 01:03:14.779
nixo: Just got a pretty good.

356
01:03:15.690 --> 01:03:19.229
nixo: Reading from all the clients except for Erigon and Reth.

357
01:03:19.740 --> 01:03:22.819
nixo: Does anybody want to say anything on this one?

358
01:03:24.180 --> 01:03:42.309
CPerezz: This should be paired directly with SETCODEFROM both together, as the combination of both is what allows you to transition into post-quantum, without no longer relying on your ECDSA and taking all the funds and positions and whatever you have with you, so…

359
01:03:42.400 --> 01:03:45.560
CPerezz: If we CFI, we should CFI both together.

360
01:03:46.620 --> 01:03:48.299
nixo: Okay, great.

361
01:03:48.520 --> 01:03:56.780
nixo: We have from Besu and Erigon C tiers on SETCODEFROM. Do they want to say anything about those ones?

362
01:03:57.660 --> 01:04:16.059
Justin Florentine: I can go for Besu. We discussed this a little bit further. We are more open to it, but not enough to actually change it to B. I think that might change as we pair it with, other things, I think, that, you know, were just mentioned.

363
01:04:16.070 --> 01:04:25.969
Justin Florentine: As well as, I think, deactivating self-destruct, that goes in, that becomes a thing that we care more about as well. So, I treat us as a C+?

364
01:04:30.180 --> 01:04:33.080
nixo: Great. Is this…

365
01:04:33.780 --> 01:04:43.869
lightclient: Just ask, like, what… Sorry, hello. What's your… what is Besu's preferred approach for EOAs to migrate to post-quantum?

366
01:04:51.010 --> 01:04:55.399
Justin Florentine: I don't have an answer to that right off the top of my head.

367
01:04:55.400 --> 01:04:57.370
lightclient: Because to me, like, SETCODEFROM is, like.

368
01:04:57.530 --> 01:05:03.470
lightclient: a critical part of like what I'm imagining is the path for EOAs to become post-quantum.

369
01:05:04.250 --> 01:05:08.190
lightclient: So that's why I feel ranking it so highly is important.

370
01:05:09.130 --> 01:05:19.460
lightclient: But if you guys have an alternative approach that you prefer, like, we could discuss that. I just think that, like, we need to figure out in Hegota how EOAs can become post-quantum, and if it's not this, then we should decide that.

371
01:05:23.420 --> 01:05:29.520
Justin Florentine: So I think our current thinking is kind of some of the existing models Might be sufficient for it.

372
01:05:30.080 --> 01:05:43.070
Justin Florentine: But we don't have examples that I can give you as an alternate path for that, so I don't think I'm prepared to answer that question. We recognize the point, though, for sure, like, if we were to prioritize

373
01:05:43.870 --> 01:05:46.399
Justin Florentine: like, a pure PQ fork.

374
01:05:47.290 --> 01:05:56.320
Justin Florentine: That for sure would go in there. We also have trouble teasing out the size and complexity that comes with some of these ratings as well.

375
01:06:05.910 --> 01:06:07.520
nixo: Carlos, do you still have your hand raised?

376
01:06:07.890 --> 01:06:11.860
CPerezz: Oh, never mind. My client make the point, so that's it. Yeah.

377
01:06:14.040 --> 01:06:19.580
nixo: Okay, so as… as I understand, this is, some…

378
01:06:21.210 --> 01:06:26.260
nixo: Some path to, PQ readiness is dependent on this.

379
01:06:27.300 --> 01:06:28.300
nixo: And so.

380
01:06:28.880 --> 01:06:33.950
nixo: CFI-ing it would create that path, whereas DFI-ing it leaves no path.

381
01:06:33.950 --> 01:06:46.749
Justin Florentine: Yeah, let me clarify Besu's position here. We don't want to be a blocker on this. This is kind of our, you know, our ranking of it amongst everything else. So, like, if everybody else thinks that this should go in, we're certainly not going to put up a fight.

382
01:06:48.700 --> 01:06:49.410
nixo: Cool.

383
01:06:49.660 --> 01:06:55.309
nixo: Since these go together, then are we comfortable CFIing both of these?

384
01:06:56.850 --> 01:06:59.570
nixo: That's 8151 and 8298.

385
01:07:05.820 --> 01:07:07.190
nixo: Any opposition?

386
01:07:12.130 --> 01:07:13.040
nixo: Cool.

387
01:07:13.390 --> 01:07:23.860
nixo: So, they're… the next two are also, somewhat paired, TCREATE and Self-Destruct.

388
01:07:25.020 --> 01:07:36.249
nixo: this was talked about on the last call. Milos, who agreed to champion this, who unfortunately could not be at the call today, gave, an update on TCREATE.

389
01:07:37.830 --> 01:07:40.430
nixo: And I think that there was…

390
01:07:40.850 --> 01:07:50.100
nixo: pretty good response, seeing that, this was, something that is being introduced in Glamsterdam and doesn't have,

391
01:07:51.410 --> 01:07:57.850
nixo: doesn't have a… this fix is something that isn't being introduced in Glamsterdam. So…

392
01:07:59.690 --> 01:08:04.949
nixo: First of all, does anybody have, any comments about pairing these as well?

393
01:08:15.640 --> 01:08:28.850
nixo: Great. I think the only things… the only teams that we didn't get, responses for… for 8360 were ethrex, Geth, and Reth. Do… do they want to weigh in at all? Because otherwise, this is…

394
01:08:29.950 --> 01:08:31.390
nixo: Quite highly rated.

395
01:08:33.250 --> 01:08:49.339
Iván | ethrex: On the ethrex side, sorry, Nixo, I couldn't give you my opinion in time. We are okay for, tiering it up to a B. I was thinking between a C and a B, but I'm okay not doing it.

396
01:08:51.109 --> 01:08:57.559
Iván | ethrex: I would start thinking on doing it later in the process, after we figure out all the

397
01:08:57.910 --> 01:09:00.730
Iván | ethrex: main ones, the main EIPs.

398
01:09:01.720 --> 01:09:06.249
nixo: Okay, yeah, that's… that makes sense, and that's, I think generally how the…

399
01:09:06.350 --> 01:09:10.369
nixo: CFI works as we move things into SFI and put them in devnets.

400
01:09:14.420 --> 01:09:18.429
nixo: CFIs for both of these? Any… Opposition to that?

401
01:09:29.590 --> 01:09:30.460
nixo: Great.

402
01:09:33.080 --> 01:09:46.159
nixo: For the next ones, the next ones are… have a little bit more contention, and so I'm going to ask, that… that we default to DFI-ing, unless there is opposition. The next ones…

403
01:09:46.640 --> 01:09:56.940
nixo: I think our… 7709, 877… 8077, and 7666. These are.

404
01:09:59.150 --> 01:10:10.819
nixo: ones that have flags on them, or have been, flagged as not urgent by clients. So, let's start with 70… 7709.

405
01:10:13.540 --> 01:10:14.670
nixo: Yes.

406
01:10:18.000 --> 01:10:26.349
nixo: Does anybody feel like this is urgent, and that we have to get this in, given the scope that we're already looking at for Hegota?

407
01:10:32.050 --> 01:10:35.029
Ben Adams: Yeah, so I recently looked at.

408
01:10:35.490 --> 01:10:41.159
Ben Adams: Sort of a light client working off BALs as the data.

409
01:10:41.680 --> 01:10:52.219
Ben Adams: And, BLOCKHASH is one of the things that's problematic because you still need the previous 256 blocks.

410
01:10:52.840 --> 01:11:00.310
Ben Adams: Whereas if we include… if we change to this form of BLOCKHASH, so you're reading from the storage, then that will be in the BAL.

411
01:11:00.470 --> 01:11:02.000
Ben Adams: Umm.

412
01:11:02.840 --> 01:11:10.279
Ben Adams: and also in the data, so you won't need the trailing 256 headers, so I'd like to…

413
01:11:10.860 --> 01:11:15.379
Ben Adams: Movement Nethermind's vote up from B.

414
01:11:16.160 --> 01:11:17.500
Ben Adams: To… to A.

415
01:11:26.530 --> 01:11:27.490
nixo: Ignacio?

416
01:11:29.240 --> 01:11:39.899
ignacio: Yeah, as an EIP champion, I agree with what Ben said. It was kind of the underlying purpose of proposing this for Hegota.

417
01:11:40.010 --> 01:11:44.839
ignacio: I particularly asked Dragan from Reth, which is the team that

418
01:11:45.040 --> 01:11:51.830
ignacio: decided to DFI this, and I think his point was that it wasn't really a strong opinion.

419
01:11:52.330 --> 01:11:56.500
ignacio: So, maybe if he's here, or anyone from Reth is here.

420
01:11:56.600 --> 01:12:02.879
ignacio: Can't give… its view about this, if it is, like, a strong DFI or they don't really care.

421
01:12:03.000 --> 01:12:04.189
ignacio: About it.

422
01:12:21.350 --> 01:12:28.700
nixo: Alright, And we can move to, CFIing this one as well.

423
01:12:31.990 --> 01:12:34.820
nixo: Any opposition there?

424
01:12:48.360 --> 01:12:57.110
nixo: Okay, then… 8077. This was really mixed support. I,

425
01:12:58.710 --> 01:13:01.770
nixo: I'm gonna ask if anybody… Csaba?

426
01:13:04.220 --> 01:13:06.900
Csaba: I let you ask the question.

427
01:13:07.210 --> 01:13:12.940
nixo: If anybody, opposes moving this one to DFI, just to…

428
01:13:14.150 --> 01:13:18.399
nixo: Keep the scope a little bit smaller, especially given that there were no

429
01:13:19.240 --> 01:13:21.920
nixo: There was only one, S tier for this.

430
01:13:23.020 --> 01:13:28.760
Csaba: you Yeah, so… Why I think it's important.

431
01:13:30.740 --> 01:13:39.500
Csaba: we are making networking changes on the CL, but on the EL, we have the mempool, and the two visions of how

432
01:13:40.960 --> 01:13:46.640
Csaba: The transaction volume that we are increasing should get on-chain, and one is…

433
01:13:47.150 --> 01:13:50.069
Csaba: Where does anybody have the private feeds?

434
01:13:50.230 --> 01:13:53.920
Csaba: And the other is supermempool.

435
01:13:54.090 --> 01:14:00.870
Csaba: And this is to support the mempool region in which we are increasing the capacity of the mempool.

436
01:14:01.800 --> 01:14:08.439
Csaba: And, the underlying reasoning is that we should increase… improve the networking of the mempool as well.

437
01:14:09.110 --> 01:14:16.690
Csaba: And yeah, it's outlined in the EIP with specific reasons that are. I was naming four.

438
01:14:17.340 --> 01:14:20.180
Csaba: But in general.

439
01:14:20.950 --> 01:14:27.439
Csaba: With the current mempool, everything is fine if we have all the bandwidths on us, all the bandwidths that we need.

440
01:14:27.540 --> 01:14:33.280
Csaba: But we are absolutely not prepared to operate in a regime when we have a node which is falling back.

441
01:14:33.380 --> 01:14:35.750
Csaba: So this is this is tool.

442
01:14:35.920 --> 01:14:37.330
Csaba: To make that work.

443
01:14:39.960 --> 01:14:47.140
Csaba: Since we are raising the gas limit already now, and we don't know what we will do in Hegota, but I don't think we will reduce it.

444
01:14:47.550 --> 01:14:49.419
Csaba: I will be…

445
01:14:50.060 --> 01:14:54.929
Csaba: strongly in support, but I'm… I'm the champion of it, so that's not… not a surprise.

446
01:14:55.670 --> 01:14:56.520
nixo: Lukash.

447
01:14:57.160 --> 01:15:12.069
Łukasz Rozmej: So 2 things so if node is falling back, we can actually temporarily disable a transaction pool on it and actually don't do anything. If you're now you're you have time to catch up. There's no point of

448
01:15:12.070 --> 01:15:19.169
Łukasz Rozmej: Downloading transactions from other things and just focusing on catching up first because you cannot validate them properly.

449
01:15:19.340 --> 01:15:26.669
Łukasz Rozmej: I was debating actually to did this kind of EIP exactly this one like 4 years ago.

450
01:15:26.880 --> 01:15:36.880
Łukasz Rozmej: I decided not to back then, because, looking at our transaction pool rules, just adding sender and nonce is not enough.

451
01:15:37.000 --> 01:15:55.820
Łukasz Rozmej: To actually have a full picture, if we should request this transaction, does it have a real good chance of, of going into our pool, or being better than the transactions we have, or not? So, I would rather do it all-in or nothing.

452
01:15:55.890 --> 01:16:07.169
Łukasz Rozmej: So nothing is to DFI this, or doing all-in, so actually transmitting a bigger kind of transaction Header where, each transaction pool can

453
01:16:07.700 --> 01:16:18.799
Łukasz Rozmej: Preemptively assess if this is the better transaction than it has or not, and based on that, download that transaction or not, and sender and answer is not enough there.

454
01:16:21.030 --> 01:16:30.250
Csaba: Okay, I see. So, standard analysis is enough for many things. It doesn't have the fees. The fees is something we have been discussing along

455
01:16:30.800 --> 01:16:39.110
Csaba: DCIP, and as I understand, you also looked at it previously. I'm absolutely open to look into that. Also, others are…

456
01:16:39.210 --> 01:16:44.850
Csaba: I'm happy to look into that. So, it came up in many other discussions that the fees might

457
01:16:44.990 --> 01:16:52.680
Csaba: Might make sense, obviously, depending on transaction size and everything. There's a size where you just send a transaction, because it's almost the same, but…

458
01:16:53.690 --> 01:17:02.939
Csaba: Yeah, we can definitely kind of make it more sophisticated in that sense. Sometimes there is a field of that sophistication, so, you know, we have to…

459
01:17:03.120 --> 01:17:04.460
Csaba: We're going to little bit.

460
01:17:04.580 --> 01:17:06.010
Csaba: But happy to work with you.

461
01:17:13.740 --> 01:17:14.870
nixo: Any other comments?

462
01:17:17.380 --> 01:17:20.380
nixo: Okay, what I'm observing is, is…

463
01:17:20.780 --> 01:17:31.629
nixo: like, tepid support here. Nothing urgent and nothing, not, like, wide consensus. I… I'm gonna move to DFI this.

464
01:17:31.930 --> 01:17:35.710
nixo: Does anybody have… Strong opposition to that.

465
01:17:36.140 --> 01:17:36.820
Csaba: Yes?

466
01:17:38.480 --> 01:17:48.709
Csaba: I don't understand your, kind of… decision process, but other than that, no. So I would… I would either CFI or defer, if it would be me.

467
01:17:49.530 --> 01:17:56.860
nixo: Lukasz, does Nethermind want to move its, its ranking at all, based on the conversation?

468
01:17:56.860 --> 01:18:01.779
Łukasz Rozmej: If we made it more robust, I could give it a B.

469
01:18:03.160 --> 01:18:06.350
Łukasz Rozmej: Which is fine and potentially fine in fork.

470
01:18:11.520 --> 01:18:13.299
nixo: Do any other clients want to weigh in?

471
01:18:23.130 --> 01:18:36.129
Justin Florentine: I can elaborate a little bit on why we like it. We see a future where, you know, filtering these things in the mempool becomes a lot more important, so, we have a future utility angle to our B-Rainy.

472
01:18:37.480 --> 01:18:38.260
nixo: Okay.

473
01:18:39.390 --> 01:18:41.680
nixo: Then we will move to CFI that one.

474
01:18:42.020 --> 01:18:50.000
Ben Adams: Yeah, also with, frames, potentially putting transactions in the mempool costs a lot more, so.

475
01:18:51.300 --> 01:18:53.460
Ben Adams: It might be interesting from that respect.

476
01:18:56.870 --> 01:19:07.679
Łukasz Rozmej: I would just ask to do a deeper analysis if anything beyond gas prices should also get in that, especially counting frames and other stuff.

477
01:19:08.240 --> 01:19:12.740
Łukasz Rozmej: So it will be actually robust and future looking.

478
01:19:16.840 --> 01:19:17.390
nixo: Cool.

479
01:19:19.130 --> 01:19:23.240
nixo: The next one we have on the docket is, 7666.

480
01:19:24.660 --> 01:19:32.519
nixo: This got… A's from Besu and ethrex, and C's or D's from all other clients.

481
01:19:33.760 --> 01:19:36.010
nixo: Does anybody want to say anything about this one?

482
01:19:36.770 --> 01:19:42.880
Łukasz Rozmej: I could also revise it to be I actually found One edge case where,

483
01:19:43.530 --> 01:19:49.299
Łukasz Rozmej: where this precompile I had to optimize around it, so making it

484
01:19:49.710 --> 01:19:56.079
Łukasz Rozmej: I'm removing it kind of way would also solve this, so it is a bit of a technical depth.

485
01:20:00.820 --> 01:20:04.750
Justin Florentine: Basically looked at this as kind of a healthy vertical spike.

486
01:20:04.850 --> 01:20:10.789
Justin Florentine: So we do think on the merits, it's useful, interesting, and fairly cheap.

487
01:20:10.890 --> 01:20:17.540
Justin Florentine: However, when we get time to actually sizing and considering it, whether it should go in the fork.

488
01:20:17.990 --> 01:20:23.400
Justin Florentine: Again, we consider it a useful vertical spike, so… The urgency is…

489
01:20:24.300 --> 01:20:27.360
Justin Florentine: Aligned with our appetite for paying off tech debt.

490
01:20:33.160 --> 01:20:34.770
nixo: Any other comments around this one?

491
01:20:36.650 --> 01:20:45.739
Ben Adams: Yeah, I assume there's still an appetite to, if feasible, move more precompiles in the future.

492
01:20:46.610 --> 01:20:56.880
Ben Adams: To EVM, so this would be like a useful, as you said, Justin, to prove that mechanism in a very low risk way.

493
01:21:01.770 --> 01:21:02.570
nixo: Felix.

494
01:21:03.870 --> 01:21:16.169
Felix (Geth): So, I'm somewhat strongly against this EIP. The main reason is that I think, like, we can… we can talk about EVMifying precompiles that actually do something, but this one is not…

495
01:21:16.980 --> 01:21:26.870
Felix (Geth): I mean, it's a trivial thing, so it doesn't really make sense to… Like, spend resources on… Like.

496
01:21:26.870 --> 01:21:27.430
Ben Adams: But.

497
01:21:27.430 --> 01:21:27.850
Felix (Geth): this.

498
01:21:27.850 --> 01:21:31.400
Ben Adams: That's why, that's why it's low risk.

499
01:21:32.550 --> 01:21:35.699
Felix (Geth): I mean, low risk in the sense that, like, I'm…

500
01:21:36.150 --> 01:21:42.370
Felix (Geth): We will not, I mean, if this gets done, we will not implement it, basically. We will just keep doing what we're doing now.

501
01:21:42.490 --> 01:21:44.389
Felix (Geth): And just change the gas price.

502
01:21:44.520 --> 01:21:45.970
Felix (Geth): So there's no…

503
01:21:46.110 --> 01:21:52.589
Felix (Geth): I think it's kind of pointless. It's better to talk about the other ones where we're trying to reprice the

504
01:21:52.780 --> 01:22:03.639
Felix (Geth): precompiles based on their EVM code, but for this one, it's a bit… it's more… this… I feel this is more signaling EIP than actual technical implementation EIP.

505
01:22:12.560 --> 01:22:16.490
Kevaundray Wedderburn: What does that… What does that mean? Like…

506
01:22:17.530 --> 01:22:22.530
Felix (Geth): I mean, as in, like, what's the benefit of doing this? It's just to signal that we are able to

507
01:22:22.800 --> 01:22:34.180
Felix (Geth): use the EVM to implement this trivial operation. We might… if we're gonna use the EVM to implement something that used to be precompile, we should do a real one, like a precompile that is actually

508
01:22:35.400 --> 01:22:36.819
Felix (Geth): You know, does something.

509
01:22:38.350 --> 01:22:44.389
Kevaundray Wedderburn: Right, I guess the point is we've never done this before, so this is a low-risk way of doing it.

510
01:22:45.040 --> 01:22:51.950
Kevaundray Wedderburn: Like, you don't need to worry about the bytecode being incorrect or anything like this, because it's a simple identity precompile.

511
01:22:53.200 --> 01:23:00.569
Felix (Geth): I mean, the general benefit of changing a precompile into EVM code is that it de-risks it, so it is kind of a…

512
01:23:00.620 --> 01:23:13.839
Felix (Geth): low risk operation as long as you, you know. I mean, if it has a bug, it has the same bug on all the clients. So then it's kind of like we're just stuck with the wrong behavior, and that risk is not removed by this

513
01:23:14.050 --> 01:23:31.630
Felix (Geth): EIP shipping. So there's no risk in running the EVM instead of a precompile, because it's just a normal contract. So the only thing we'd be doing is remove it from the table, and then instead, you know, make it call the actual bytecode, which we're doing all the time. So there's no risk in changing a precompile into something else.

514
01:23:32.950 --> 01:23:33.510
Kevaundray Wedderburn: I mean, I think.

515
01:23:33.510 --> 01:23:34.130
Felix (Geth): Anyway…

516
01:23:34.130 --> 01:23:47.830
Kevaundray Wedderburn: Technical risk to changing a precompile to make it use bytecode. Like there's the risk of the bytecode being wrong, but then there's just the technical risk of changing, like adding code to the address where it is.

517
01:23:48.050 --> 01:23:54.150
Kevaundray Wedderburn: And this sort of removes the bytecode risk, because the identity precompile is, like, pretty simple.

518
01:23:54.460 --> 01:23:56.370
Kevaundray Wedderburn: But there's also… yeah.

519
01:23:56.520 --> 01:24:01.149
Kevaundray Wedderburn: We just haven't done this before, so there is a technical risk of just adding code at that address.

520
01:24:02.060 --> 01:24:03.349
Felix (Geth): There's no risk in that.

521
01:24:03.960 --> 01:24:22.089
Felix (Geth): Like, on the implementation level. I mean, may… some… some contract somewhere might assume that, you know, it can check that this address has no code, but for… yeah. We're not gonna discover these cases by changing the identity precompile either. So I think this argument is not valid.

522
01:24:28.110 --> 01:24:32.550
Kevaundray Wedderburn: Yeah, I'm just reading the comments, yeah, I don't think we should spend too much time on this.

523
01:24:32.680 --> 01:24:35.340
Kevaundray Wedderburn: Yeah, if he M.

524
01:24:40.150 --> 01:24:45.430
Kevaundray Wedderburn: I agree that implementing it would be faster than, DFI.

525
01:24:58.720 --> 01:25:00.120
nixo: Alright,

526
01:25:03.680 --> 01:25:19.860
nixo: Let's, let's move this one to CFI, and we can… I do want to point out that there is another part in this process that we added, we talked about it in Svalbard, which is prioritizing the CFI EIPs, and devnets would move through that priority list.

527
01:25:20.290 --> 01:25:25.280
nixo: So, we still can have the conversation about whether or not it's…

528
01:25:25.820 --> 01:25:30.960
nixo: worth it relative to the other CFIs as time goes.

529
01:25:35.800 --> 01:25:37.070
nixo: Thank you, guys.

530
01:25:42.980 --> 01:25:44.709
lightclient: Wait, why are we not DFI-ing it?

531
01:25:47.530 --> 01:25:58.419
nixo: It seems that it is very little complexity, and that there is more conversation that needs to happen. I'd be comfortable deferring it to the next call if people want to take another look.

532
01:25:59.060 --> 01:26:08.700
Łukasz Rozmej: So Jochem has a point on potentially changing the gas cost, which is potentially breaking compatibility, if I understood it correctly.

533
01:26:11.830 --> 01:26:26.239
jochem-brouwer: Yeah, so 2 points, the EIP says in security considerations that, the, as no new new functionality is introduced or made cheaper. Well, that's actually not the case because this actually makes certain inputs.

534
01:26:26.450 --> 01:26:31.529
jochem-brouwer: More expensive. And the other thing that is also not in the EIP is if this,

535
01:26:31.980 --> 01:26:36.360
jochem-brouwer: Contract then gets removed from the default warm accounts, so

536
01:26:36.800 --> 01:26:41.050
jochem-brouwer: This at least needs to get some attention on the spec side.

537
01:26:43.780 --> 01:26:46.650
Łukasz Rozmej: Okay, I would then DFI it because it's not worth it.

538
01:26:49.930 --> 01:26:50.360
nixo: Felix.

539
01:26:50.360 --> 01:26:55.039
Felix (Geth): I mean, this thing copies memory from A to B, like, why are we messing with this?

540
01:27:00.560 --> 01:27:01.330
nixo: Okay.

541
01:27:03.650 --> 01:27:05.870
nixo: Then moving to DFI.

542
01:27:13.060 --> 01:27:15.409
nixo: You guys give me one DFI.

543
01:27:17.100 --> 01:27:19.229
nixo: I'll take it.

544
01:27:25.420 --> 01:27:28.110
nixo: Okay, moving on.

545
01:27:28.320 --> 01:27:32.079
nixo: The other… the last three, I think, are more…

546
01:27:33.540 --> 01:27:39.260
nixo: There's much less, or much bigger spread on these ones.

547
01:27:41.650 --> 01:27:50.340
nixo: I don't have a lot of context on the ML-DSA verification. Does anybody want to talk about this one?

548
01:27:53.800 --> 01:27:56.980
Ben Adams: I think there's. There's a little bit of comp.

549
01:27:57.730 --> 01:28:05.690
Ben Adams: complexity or disagreement, because I think the spec proposes three different things, and some people are happy with one,

550
01:28:06.120 --> 01:28:08.170
Ben Adams: I don't know, somebody else can speak to that.

551
01:28:11.000 --> 01:28:26.619
Kevaundray Wedderburn: Yeah, I think I brought up this argument that, even if we were okay with lattices, it doesn't really make sense to me that we'd be, CFI-ing three different versions of a particular signature, scheme.

552
01:28:27.270 --> 01:28:27.990
Kevaundray Wedderburn: like.

553
01:28:28.260 --> 01:28:38.029
Kevaundray Wedderburn: We're not gonna use all of them, and this argument that maybe one country needs to use the weaker version, while another needs to use the stronger version doesn't…

554
01:28:38.200 --> 01:28:40.830
Kevaundray Wedderburn: At least that's not a strong argument for me.

555
01:28:41.850 --> 01:28:43.409
Kevaundray Wedderburn: Outside of that?

556
01:28:43.530 --> 01:28:45.599
Kevaundray Wedderburn: I think we should definitely look at.

557
01:28:45.990 --> 01:28:53.580
Kevaundray Wedderburn: what the gas cost is in the EVM bytecode. I'm personally not okay with, CFI and a lattice-based scheme.

558
01:28:54.350 --> 01:29:00.810
Kevaundray Wedderburn: But I still think we should look at what it costs, just for people to do it, like, in EVM bytecode.

559
01:29:05.180 --> 01:29:05.820
nixo: You know?

560
01:29:07.300 --> 01:29:10.170
Danno Ferrin: So a couple of questions there.

561
01:29:10.330 --> 01:29:30.160
Danno Ferrin: So, first, the overarching… my overarching motivation for this is cryptographic agility. We need to have multiple signature families available for people to put their funds in. We can't… locking in on just one is, is, is incredibly risky, in my opinion. As far as why all three, because people need choices. We can lock down into one of them.

562
01:29:30.250 --> 01:29:47.940
Danno Ferrin: But to directly address Kevaundray's question, what's the cost of doing this in the EVM? It's about a million, and they've had… it started out at 5 million, and it's gone down about a million, and that includes, a lot of AI performance improvements to get the cost of doing this evaluation in raw EVM.

563
01:29:48.110 --> 01:30:07.600
Danno Ferrin: And that runs into a couple of major problems, because 4337 limits, validation to 500,000 gas, and 3160, which is BASIS, response to frame limits validation to 100,000 gas. So, doing this in EVM-only bytecode locks out two of the major account abstraction solutions that are going to be out there.

564
01:30:07.670 --> 01:30:14.610
Danno Ferrin: So that's one of the reasons why I think we need to look at specifying what it would look like if it were to be.

565
01:30:14.780 --> 01:30:15.960
Danno Ferrin: a precompile

566
01:30:16.000 --> 01:30:29.550
Danno Ferrin: One of the strong arguments brought against it is, well, look at what happened with Blake, and look at what happened with RIPEMD. Nobody's using those. Look at, you know, BLS, you know, nobody's using those, it's relatively low impact. But I think that's the wrong comparison. What we need to look at is P256.

567
01:30:29.560 --> 01:30:44.469
Danno Ferrin: And that has been, brought around… that has been brought up over 8 to 10 years before it was finally adopted in various levels to various people. The reason it was brought up is because it's the one that financial regulators are asking all of their clients to use.

568
01:30:44.630 --> 01:30:49.959
Danno Ferrin: So, one potential middle ground for this, is maybe not to ship it directly.

569
01:30:49.980 --> 01:31:07.649
Danno Ferrin: in Hegota, but instead to reserve one of the 100 series precompile ranges, like was done for P256. Get a specification for it, get the tests written into the Ethereum compliance tests, so that if it were shipped, this is what it would look like, it's known, this is the address, it is standardized.

570
01:31:07.650 --> 01:31:12.600
Danno Ferrin: And that'll avoid the problem we have with P256, which is where there are about 2 or 3 different definitions.

571
01:31:12.600 --> 01:31:32.539
Danno Ferrin: There are different, reactions to the various, you know, how do you respond when the answer's no? Do you respond with a hash? Do you not respond with a hash? The standardization, putting it in, like, the 100 series makes it a lot easier to, if the… if Ethereum may not decide suddenly it does need it later, to just turn it on. It also creates space

572
01:31:32.540 --> 01:31:42.379
Danno Ferrin: for… for roll-ups and L2s to decide, well, even though Mainnet doesn't like lattices, we like lattices because our customers like lattices, so we're going to go ahead and turn it on.

573
01:31:42.410 --> 01:31:53.880
Danno Ferrin: So, from my perspective, that is something that I would like to, rather than just turn our nose up at lattices because we don't like the math behind it, we need to make room for all users to use the whole of Ethereum.

574
01:31:58.180 --> 01:31:59.070
nixo: Antonio.

575
01:32:00.310 --> 01:32:08.890
Antonio Sanso: Right, yeah, I mean, probably people know already my opinion, and as you probably know, we have been running bi-weekly.

576
01:32:09.460 --> 01:32:18.259
Antonio Sanso: Breakout rooms on this topic. We've been looking at the beginning at lattices, but with time, we've been moving away from it for several reasons.

577
01:32:18.570 --> 01:32:21.699
Antonio Sanso: I can, I can summarize some of this.

578
01:32:21.890 --> 01:32:33.280
Antonio Sanso: Start from the end, we have, some testnet called Daisugi, where we actually are running, at the moment, a version of SPHINCS with aggregation.

579
01:32:33.340 --> 01:32:42.740
Antonio Sanso: So it's gonna be really, really cheap on gas. And this is actually, thanks to aggregation, of course. And this is actually one of the issue with this, with this.

580
01:32:43.070 --> 01:32:52.839
Antonio Sanso: EIP is the fact that it's really short-sighted. Namely, like, there is no plan to scale this. If literally every user of Ethereum is gonna use this

581
01:32:53.060 --> 01:33:01.409
Antonio Sanso: this precompile, the network is basically frozen, or, like, the gas is gonna spike, like, the level that we were at the 2021.

582
01:33:01.510 --> 01:33:20.860
Antonio Sanso: This is the first issue. The second issue is, like, zkVM compatibility. We're… the moment is… I mean, the gas is really mispriced at the moment. If we keep in consideration that the fact that we're gonna move to zkVM, this is gonna be really a total bad price at the moment.

583
01:33:20.960 --> 01:33:34.839
Antonio Sanso: And the last but not least, I mean, I have 10 other reasons, but I don't want to take all the evening, is basically, like, we are introducing this new assumption in Ethereum at really bad timing.

584
01:33:35.020 --> 01:33:41.829
Antonio Sanso: We have seen what happened in the last weeks, months, introducing this right now.

585
01:33:42.180 --> 01:33:50.169
Antonio Sanso: I don't know if it's the best things. Once we have a solution that actually works, and it's really scalable with hash, and it's really conservative.

586
01:33:50.630 --> 01:33:55.109
Antonio Sanso: And I stop here for now. I can answer some questions more offline.

587
01:33:59.980 --> 01:34:00.979
nixo: Thank you guys.

588
01:34:02.240 --> 01:34:10.980
nixo: It seems like a clear lack of consensus about the specific path forward, so I'm going to, propose that we DFI this one.

589
01:34:12.180 --> 01:34:16.489
nixo: There seems to be a lot of support for that in the chat.

590
01:34:24.830 --> 01:34:25.660
nixo: Great.

591
01:34:30.570 --> 01:34:33.049
nixo: Alright, 8116.

592
01:34:33.360 --> 01:34:36.580
nixo: Replace cumulative receipt fields.

593
01:34:37.800 --> 01:34:48.820
nixo: Low ratings from Besu, ethrex, Reth, mid-tier Erigon, and supported by Geth and Nethermind. Does anybody want to say anything about this one?

594
01:34:57.970 --> 01:34:58.710
nixo: Ben.

595
01:34:59.400 --> 01:35:04.460
Ben Adams: It's it's not useful, so it's just waste.

596
01:35:04.840 --> 01:35:10.299
Ben Adams: Because in order to work out, in order to use it, you've got to request two transactions.

597
01:35:10.610 --> 01:35:14.580
Ben Adams: And then subtract them, so… Umm.

598
01:35:15.040 --> 01:35:18.669
Ben Adams: It's… yeah, it's technical debt removal.

599
01:35:20.780 --> 01:35:23.530
Ben Adams: And also, network, bandwidth.

600
01:35:25.100 --> 01:35:27.159
nixo: What is the complexity of this one?

601
01:35:28.070 --> 01:35:29.639
nixo: Very low.

602
01:35:36.540 --> 01:35:39.789
nixo: ethrex or baser. Do you guys want to say anything? You guys.

603
01:35:40.250 --> 01:35:42.250
nixo: Rated RF.

604
01:35:42.550 --> 01:35:50.700
Justin Florentine: We agree with Ben's and Lukas's assessment that this is technical debt clearing, and that's why we put it in C tier.

605
01:35:51.260 --> 01:35:53.280
Justin Florentine: Sure, it's great, we love it, we should do it.

606
01:35:53.600 --> 01:35:56.459
Justin Florentine: But where does it fit amongst everything else?

607
01:35:57.360 --> 01:35:58.870
Justin Florentine: I don't know, about the middle?

608
01:36:03.250 --> 01:36:10.099
Iván | ethrex: Yeah, we don't see it as a priority, so we just DFI'd it. We don't see any.

609
01:36:11.670 --> 01:36:14.069
nixo: Okay, great. I think this is…

610
01:36:14.630 --> 01:36:19.660
nixo: An easy CFI, but put at the bottom of the priority list, item, then.

611
01:36:22.250 --> 01:36:23.600
Justin Florentine: We'd be fine with that.

612
01:36:24.650 --> 01:36:31.390
Ben Adams: I'm not sure if it was proposed this time, but I'd… like, log… removing the logs or…

613
01:36:31.830 --> 01:36:33.959
Ben Adams: To me, seems like a more important one.

614
01:36:37.460 --> 01:36:41.380
Ben Adams: Sorry, not the logs, the, bloom filter.

615
01:36:41.380 --> 01:36:44.010
Justin Florentine: Bloom filters, yeah, and we rated that one higher as well.

616
01:36:54.940 --> 01:36:55.840
nixo: See?

617
01:37:03.720 --> 01:37:07.130
nixo: Oh, yeah, that's CFI. So, okay, we can.

618
01:37:09.040 --> 01:37:23.690
nixo: Put that one above that, then. Alright, we've got one more to consider today, and then 7907 next week. Do we want to use the last 8 minutes, to get a decision on persist warm access sets across reverts?

619
01:37:24.290 --> 01:37:31.959
nixo: Looks like ethrex felt strongly against it. Reth and Erigon were mildly against it, and the rest was lukewarm support.

620
01:37:40.750 --> 01:37:45.080
nixo: Interesting that it's authored by Dragan, and only a C tier from Reth.

621
01:38:01.620 --> 01:38:04.100
Ben Adams: I have a bit of 8037.

622
01:38:04.260 --> 01:38:08.360
Ben Adams: Ptsd, and…

623
01:38:08.730 --> 01:38:11.840
Ben Adams: This. This feels like revisiting that wound.

624
01:38:17.230 --> 01:38:18.170
nixo: Felix.

625
01:38:19.420 --> 01:38:28.770
Felix (Geth): So I just want to give some context on our decision here to put it in A tier. So we did analyze this EIP and we, all of us, couldn't remember why.

626
01:38:29.070 --> 01:38:36.950
Felix (Geth): we implemented it this way. Like, why are these, why is it reverted? We just cannot figure it out.

627
01:38:37.120 --> 01:38:44.859
Felix (Geth): So this is something to consider, is that it's a bit unknown for us. There may… the original, author.

628
01:38:45.440 --> 01:38:54.510
Felix (Geth): may have… like the original authors of this warm… Access…

629
01:38:54.880 --> 01:39:03.880
Felix (Geth): construct might still remember this, but honestly, I don't think anyone really remembers, like, I think it was just because it would mirror how

630
01:39:04.540 --> 01:39:09.329
Felix (Geth): others tracking works. So then they were just like, yeah, it should work like…

631
01:39:09.550 --> 01:39:18.130
Felix (Geth): other storage access works, and that also gets reverted. But as far as we can see, there's no real downside to changing it.

632
01:39:21.000 --> 01:39:26.900
Felix (Geth): However, it does introduce complexity to then have both paths in the client, so there is this…

633
01:39:27.490 --> 01:39:32.480
Felix (Geth): forever argument, I guess. So it doesn't reduce complexity for the moment.

634
01:39:32.610 --> 01:39:39.639
Felix (Geth): But it's just, like, for us, it was impossible to see. Is it correct or not, or what are the implications?

635
01:39:49.210 --> 01:39:54.580
nixo: Does anybody want to sway either direction here? CFI, DFI? It seems…

636
01:39:55.640 --> 01:40:01.189
nixo: Luke warned so far, and given that we already have a ton in the,

637
01:40:01.810 --> 01:40:05.460
nixo: in the fork, I would lean towards DFI-ing.

638
01:40:09.120 --> 01:40:12.460
Ben Adams: I'd lean that way because it's changing, it's making

639
01:40:13.440 --> 01:40:17.700
Ben Adams: What is changing is quite deep at fork boundary.

640
01:40:18.780 --> 01:40:20.829
Ben Adams: I don't know. I don't know if it's worth it.

641
01:40:31.920 --> 01:40:33.679
nixo: Okay, I'm clicking the DFI button.

642
01:40:36.810 --> 01:40:54.729
nixo: All right, that gets us through all of these. We have… I think there are two informational ones still. We can, talk about those next call, but we're going to have the whole next call to, talk about 7907 and whatever other Hegota scoping things that we want to talk about. Does anybody have anything else?

643
01:40:55.070 --> 01:41:01.340
nixo: that they want to bring up today. I think there was one more item which Andrew Codeup added, which was just.

644
01:41:01.580 --> 01:41:05.349
nixo: sort of pressing on Justin Drake's.

645
01:41:07.080 --> 01:41:11.490
nixo: Bunker Mode tweet yesterday, does Andrew want to say anything about that?

646
01:41:17.820 --> 01:41:20.679
nixo: I think the idea was,

647
01:41:24.220 --> 01:41:29.120
nixo: paying, I don't know, paying attention to that in terms of Hegota scoping.

648
01:41:29.600 --> 01:41:33.699
nixo: If there's nothing else today, then I think we can close up.

649
01:41:38.080 --> 01:41:52.310
Pooja Ranjan: If I may take 30 seconds, just wanted to quickly bring up the Glamsterdam Ecosystem Readiness Checklist for Devs Attention. That is to collect feedback from enterprise. They wanted to understand and share their.

650
01:41:52.570 --> 01:42:03.680
Pooja Ranjan: results from testing on the Sepolia testnet, so if this checklist looks good, we can perhaps add it to the Ethereum PM repo, the PR is already added there, and share it with the enterprise to collect the feedback.

651
01:42:08.070 --> 01:42:09.619
nixo: Great, thank you Pooja.

652
01:42:13.930 --> 01:42:16.890
nixo: Yes, scoping was definitely fast. I…

653
01:42:17.730 --> 01:42:21.380
nixo: Gonna contribute a lot of that to Forkcast and Mark's work.

654
01:42:28.040 --> 01:42:29.180
nixo: Thank you, guys.

655
01:42:32.090 --> 01:42:33.080
Justin Florentine: Good work, everyone.

656
01:42:33.570 --> 01:42:34.990
jochem-brouwer: Thanks all, bye-bye.

657
01:42:37.190 --> 01:42:38.010
Andrew Ashikhmin: Thank you, bye.

658
01:42:38.010 --> 01:42:39.110
Łukasz Rozmej: Bye, thank you.