WEBVTT

1
00:00:50.740 --> 00:00:51.820
stokes: Hello.

2
00:01:05.280 --> 00:01:06.530
stokes: Hi, Pooja.

3
00:01:06.530 --> 00:01:09.549
Pooja Ranjan: Hey, Alex, welcome back, happy to see you!

4
00:01:09.800 --> 00:01:10.640
stokes: Thank you.

5
00:01:11.740 --> 00:01:17.099
stokes: Yeah, should be, should be a good call today. Time to get back into things.

6
00:01:17.510 --> 00:01:18.260
Pooja Ranjan: Sure.

7
00:01:33.170 --> 00:01:39.599
Pooja Ranjan: Alex, just to let you know, Akash will be helping with streaming, so whenever you are ready to move over, just let us know.

8
00:01:40.960 --> 00:01:42.229
stokes: Okay, good, thanks.

9
00:01:42.820 --> 00:01:52.380
stokes: Yeah, I think then… let's give people a few minutes past the hour to join, so… maybe another 6 minutes or so?

10
00:03:00.210 --> 00:03:04.849
stokes: Okay, everyone who's joined so far, I'm trying to figure out how to…

11
00:03:06.080 --> 00:03:13.619
stokes: go to the grid view, so I can just see everyone. But let's give people a few more minutes to join, and then we'll kick things off.

12
00:03:16.350 --> 00:03:17.640
stokes: How do I…

13
00:03:19.210 --> 00:03:24.250
Pooja Ranjan: Do you see 9 checkboxes on the right top?

14
00:03:24.820 --> 00:03:25.930
Pooja Ranjan: on Zoom.

15
00:03:28.770 --> 00:03:32.060
stokes: Yeah, this is it. Okay, thank you. There we go.

16
00:03:33.130 --> 00:03:36.880
stokes: This is better in case people raise their hands or something.

17
00:03:38.970 --> 00:03:47.109
stokes: Yeah, okay, let's, get started in just a few minutes. People are… well, okay, a lot of people actually have joined, even in the last minute.

18
00:03:47.970 --> 00:03:52.020
stokes: Let's wait, like, 2 more minutes, and then we'll kick things off.

19
00:03:53.120 --> 00:03:56.860
nixo: FYI, Alex, it starts automatically 2 after, now.

20
00:03:57.360 --> 00:03:58.750
stokes: Okay, great.

21
00:04:00.540 --> 00:04:04.669
stokes: Then, yeah, let's just start in a minute.

22
00:04:10.470 --> 00:04:14.389
Matthew Keil: I love you, Stokes, I'm so happy you're back, oh my god!

23
00:04:15.340 --> 00:04:17.149
stokes: Thank you, thank you, yeah.

24
00:04:18.560 --> 00:04:23.279
stokes: It's a good call to be joining back to. I think it'll be a fun one today.

25
00:04:25.720 --> 00:04:33.790
Will Corcoran: Yeah, Alex, I think George adjusted the settings last week, so it should be live now. It starts right at the time that the meeting starts.

26
00:04:34.610 --> 00:04:40.230
stokes: Okay, now let's go ahead and get started. So, let me grab…

27
00:04:41.220 --> 00:04:49.430
stokes: the agenda here. So, yeah, everyone, welcome to ACDC number 187.

28
00:04:49.700 --> 00:04:54.100
stokes: This is issue 2222 on the PM repo.

29
00:04:54.530 --> 00:05:01.030
stokes: And today, we have Glamsterdam to discuss, and Hegota to get into, so…

30
00:05:01.290 --> 00:05:02.939
stokes: Let's go ahead and do that.

31
00:05:03.660 --> 00:05:13.540
stokes: To get started, yeah, I'm still catching up on some things, so yeah, just correct me if I'm off by some numbers or something, but I believe we've had devnet 11.

32
00:05:13.930 --> 00:05:17.929
stokes: And… it might be done now. I don't know if there's any follow-ups there.

33
00:05:18.100 --> 00:05:25.460
stokes: I think also we could touch on DevNet 8, I think it is. So, anyone have anything they'd like to share on the status of the DevNets?

34
00:05:27.450 --> 00:05:29.859
pk910: Yep, I can give a quick update.

35
00:05:30.350 --> 00:05:37.249
pk910: So DevNet11 was the latest devnet launched, and it activated Glamsterdam on Monday.

36
00:05:37.870 --> 00:05:46.970
pk910: And the activation went perfectly fine. We saw no participation drop, all clients followed ahead. It went all perfectly smooth, basically.

37
00:05:47.480 --> 00:05:54.890
pk910: Lido and Optimism deployed the stack on it, and they also gave an early feedback that everything went well, so…

38
00:05:56.530 --> 00:06:07.870
pk910: We likely keep the network up for another week. If no one complains, we'll then shut it down, because, primary testing should still go to definitely, 8.

39
00:06:09.090 --> 00:06:10.960
pk910: Yep.

40
00:06:13.870 --> 00:06:18.350
stokes: Okay, great, thanks. And DevNet 8, DevNet 8 is looking good, too.

41
00:06:19.930 --> 00:06:30.850
pk910: That's it for devnet 11. Quick update. Yeah, that's what I just wanted to follow up with. On devnet 8, we were running JUMP attack till early this week, that had quite some impact on several nodes, primarily, Besu.

42
00:06:31.180 --> 00:06:44.879
pk910: We stopped the attack early this week, and basically all nodes recovered since then. Besu still had shown a lot of out-of-memory issues, and we finally switched to, SnapSync to get them back up.

43
00:06:45.380 --> 00:06:55.170
pk910: There were a lot of minor issues. We had some block production issues with Lighthouse, a reth-gasmit mismatch yesterday.

44
00:06:55.440 --> 00:07:01.310
pk910: But both were basically due to bad images, and were solved by rolling the right images down.

45
00:07:02.210 --> 00:07:07.150
pk910: Yeah, one more thing that we've, seen this morning,

46
00:07:07.330 --> 00:07:13.270
pk910: some unknown attacker started to do some heavy t-store spamming on the network.

47
00:07:13.660 --> 00:07:25.299
pk910: Most clients did handle it properly, but again, Besu seems to be heavily affected by that, so we have seen block import times of around 7 seconds, which corresponds to a…

48
00:07:25.490 --> 00:07:31.740
pk910: megapas per second of around 20, which is quite bad. So, yeah, something to look into.

49
00:07:33.190 --> 00:07:35.289
pk910: I think that's it from the DevNet side.

50
00:07:36.360 --> 00:07:42.049
stokes: Alright, yeah, thanks. And I'm assuming all the different client teams are aware of these issues.

51
00:07:43.190 --> 00:07:46.890
Justin Florentine: Yeah, we are. We actually have two PRs in flight to address them already.

52
00:07:47.500 --> 00:07:48.780
stokes: Okay, great.

53
00:07:50.410 --> 00:07:55.510
stokes: Cool. So… Yeah, there's nothing else on the DevNets.

54
00:07:55.920 --> 00:08:00.310
stokes: One thing we should certainly talk about today is the test networks.

55
00:08:00.760 --> 00:08:07.249
stokes: And yeah, maybe this latest data on the DevNets might adjust what we want to do there.

56
00:08:09.750 --> 00:08:18.730
stokes: But yeah, before we get to that, there was a question about MPLEX and Qwik, and some of the networking stack here.

57
00:08:19.010 --> 00:08:26.549
stokes: I don't know exactly where to put this, because I think depending on how we want to handle it, it could be a Glamsterdam thing or a Hegota thing, but in any case.

58
00:08:26.890 --> 00:08:29.130
stokes: Is Lukas on the call?

59
00:08:29.560 --> 00:08:32.530
stokes: Actually, wait, I think you said in a comment. Okay.

60
00:08:32.669 --> 00:08:39.429
stokes: Anyone from Teku, would you like to… Touch on this comment.

61
00:08:40.809 --> 00:08:48.019
Stefan Bratanov: Yeah, it's, Stefan from Teku. Yeah, so we had a discussion internally with the team.

62
00:08:48.389 --> 00:08:55.399
Stefan Bratanov: And, what we… Like, basically our thoughts are that we…

63
00:08:55.539 --> 00:08:59.419
Stefan Bratanov: Don't want to deprecate NPLEX for Glamsterdam releases.

64
00:08:59.889 --> 00:09:03.639
Stefan Bratanov: And then, slowly, after the first glance enamelis, we can…

65
00:09:04.029 --> 00:09:09.339
Stefan Bratanov: not even only deprecate NPLEX, but also just completely remove TCP.

66
00:09:09.559 --> 00:09:12.939
Stefan Bratanov: But we would like for Glamsterdam to have TCP.

67
00:09:13.639 --> 00:09:19.639
Stefan Bratanov: enabled, just because right now we don't have the data, actually, how many people still use TCP.

68
00:09:19.839 --> 00:09:21.609
Stefan Bratanov: How many people use Quick?

69
00:09:21.739 --> 00:09:30.139
Stefan Bratanov: So… Just to be safe, we, would like to… Start disabling it after Glamsterdam?

70
00:09:35.050 --> 00:09:40.350
stokes: Okay, and to be clear, so for now, for Glamsterdam, it would just be…

71
00:09:40.480 --> 00:09:44.250
stokes: Announcing that we are deprecating, not actually pulling out, say, Inplex.

72
00:09:46.270 --> 00:09:49.700
Stefan Bratanov: Yeah, so we have Quick enabled by default.

73
00:09:49.850 --> 00:09:56.329
Stefan Bratanov: But, problem is, right now, Not every user has migrated, potentially, to latest versions.

74
00:09:56.630 --> 00:10:03.489
Stefan Bratanov: So… yeah, we don't have the data, and I think it's risky to just completely remove TCP from Glamsterdam.

75
00:10:03.940 --> 00:10:05.650
Stefan Bratanov: But after that, yeah.

76
00:10:07.490 --> 00:10:08.150
stokes: Alright.

77
00:10:08.700 --> 00:10:12.689
stokes: Have you talked to other client teams, and or do other client teams now?

78
00:10:12.820 --> 00:10:14.559
stokes: Have anything to add here?

79
00:10:15.000 --> 00:10:18.869
stokes: I think this seems pretty straightforward, assuming we want to do it now.

80
00:10:19.300 --> 00:10:20.910
stokes: We've been talking about…

81
00:10:21.550 --> 00:10:26.150
stokes: Well, at least the NPLEX part. We've been talking about this, I think, for quite some time, and…

82
00:10:26.750 --> 00:10:34.479
stokes: Yeah, Qlik seems interesting, But, yeah, I think probably something for Hegota at this point.

83
00:10:34.680 --> 00:10:35.500
stokes: Daniel?

84
00:10:37.530 --> 00:10:43.050
Daniel Knopik: Yeah, so… We have to…

85
00:10:43.530 --> 00:10:49.939
Daniel Knopik: So… so the ongoing efforts, to deprecate MPLEX is…

86
00:10:50.100 --> 00:10:54.079
Daniel Knopik: Yeah, has been ongoing for… Three years now.

87
00:10:54.210 --> 00:11:02.719
Daniel Knopik: And, we, earlier in the year, agreed to deprecate it for Glamster Dam, and it's a bit unfortunate that it's now

88
00:11:02.920 --> 00:11:05.490
Daniel Knopik: considered not ready.

89
00:11:05.630 --> 00:11:16.710
Daniel Knopik: So that is, like, the first point I want to make. And the second point is, this is not, like, deprecating MPLEX is not deprecating TCP, because MPLEX, Yannux is still…

90
00:11:17.380 --> 00:11:24.039
Daniel Knopik: Existing, in principle, and supported by a large share of the network.

91
00:11:24.270 --> 00:11:27.680
Daniel Knopik: So… Yeah.

92
00:11:28.660 --> 00:11:31.780
Daniel Knopik: I guess it's… it's… yeah.

93
00:11:32.580 --> 00:11:39.139
Daniel Knopik: a bit disheartening to see that Teku is now pushing again for a delay after 3 years, and…

94
00:11:39.470 --> 00:11:45.600
Daniel Knopik: I don't… it's that confidence-inspiring that we will, like, ever get rid of this.

95
00:11:53.690 --> 00:11:56.370
stokes: So, what's a good way to import today?

96
00:11:56.870 --> 00:12:03.590
stokes: I mean, yeah… So… Am I correct that we can separate Influx from Quick?

97
00:12:07.600 --> 00:12:07.920
Daniel Knopik: Sorry?

98
00:12:07.920 --> 00:12:13.229
stokes: Are they a couple… can we, can we, like, treat these separately? Can we, say, deprecate NPLEX and focus on that?

99
00:12:13.690 --> 00:12:16.260
stokes: Cause I feel like that's something we can do.

100
00:12:17.110 --> 00:12:18.880
stokes: Hopefully, for Glamsterdam.

101
00:12:19.070 --> 00:12:21.540
stokes: Then, separately, we can have the quick question.

102
00:12:23.790 --> 00:12:26.840
Daniel Knopik: Well, the thing is, we need to communicate somehow.

103
00:12:27.260 --> 00:12:32.770
Daniel Knopik: That is either TCP and MPLEX, TCP and Yamooks, or Quick.

104
00:12:33.140 --> 00:12:41.250
Daniel Knopik: And deprecating MPLEX, like, having some clients actually remove it, without enabling quick.

105
00:12:41.980 --> 00:12:46.509
Daniel Knopik: Would render some clients unable to communicate.

106
00:12:49.110 --> 00:12:57.369
Daniel Knopik: So, but… So, Teku's… is Teku is quick and enabled by default, right?

107
00:12:57.530 --> 00:12:58.190
Daniel Knopik: Bye now.

108
00:12:58.190 --> 00:13:00.919
Stefan Bratanov: Yeah. Yeah, we have quick enabled by default.

109
00:13:01.300 --> 00:13:01.970
Stefan Bratanov: Yep.

110
00:13:05.300 --> 00:13:06.110
Daniel Knopik: Cool.

111
00:13:07.030 --> 00:13:08.239
Daniel Knopik: So I think…

112
00:13:08.240 --> 00:13:12.600
Enrico Del Fante: But the problem is that our user space is… we don't know how…

113
00:13:12.880 --> 00:13:17.670
Enrico Del Fante: How many of the user base, or techo user bases, actually…

114
00:13:17.890 --> 00:13:22.859
Enrico Del Fante: change the configuration so that they are actually using WIC.

115
00:13:23.330 --> 00:13:26.970
Enrico Del Fante: Because you have to do your networking configuration.

116
00:13:27.560 --> 00:13:28.650
Enrico Del Fante: to do that.

117
00:13:29.010 --> 00:13:33.190
stokes: And you're concerned about forcing the default on them when perhaps they're not working

118
00:13:33.320 --> 00:13:35.029
stokes: Environment's not set up for it.

119
00:13:35.410 --> 00:13:39.819
Enrico Del Fante: Oh, yeah, the problem is that you find out when… when there is a problem.

120
00:13:40.500 --> 00:13:45.580
stokes: Yeah, but… well, yeah, I was gonna say what Kev said here in the chat, wouldn't this be an issue for everyone?

121
00:13:45.770 --> 00:13:53.280
Enrico Del Fante: We were also thinking about suggesting putting stuff into our… into all clients, saying.

122
00:13:53.520 --> 00:14:06.550
Enrico Del Fante: some, like, some warning, like we did during the merge, to check the configuration and say, if you, if you are not actively using quick,

123
00:14:06.860 --> 00:14:22.720
Enrico Del Fante: and you don't have peers on QUIC currently, you throw a warning, say, hey, please check your configuration, because in the… we're gonna deprecate TCP connections soon, so please migrate to QUIC.

124
00:14:23.010 --> 00:14:30.890
Enrico Del Fante: But unless you don't do that, it's kind of unsafe, because we are Blindly. We're blind.

125
00:14:31.630 --> 00:14:38.880
stokes: Yeah. Okay, I do want to just be aware of the time on this topic, but yeah, potuz and Matt.

126
00:14:38.880 --> 00:14:51.309
potuz: Just a quick comment. I don't buy Enrico's comment of, like, not knowing how many people change their configuration. Just flip the flag now that you're gonna have Glamsterdam releases, and they are forced to use them.

127
00:14:51.750 --> 00:14:54.279
potuz: Make, quick by default.

128
00:14:54.420 --> 00:14:59.680
potuz: and then we can just quickly deprecate it on the first release after Glamster, and if there's no problems.

129
00:15:01.830 --> 00:15:09.900
Matthew Keil: That was exactly what I was gonna say. Just make it by default, and then, with a warning that we're gonna deprecate soon after, and get rid of everything else, just use quick.

130
00:15:09.900 --> 00:15:13.330
Enrico Del Fante: Sure, no problem. It's already like that. Its bite is not…

131
00:15:13.750 --> 00:15:22.590
Enrico Del Fante: force deprecating MPLEX before Glamsterdam activates. After that, It's okay.

132
00:15:23.300 --> 00:15:30.400
stokes: Okay, do you want to do it that way, then? So, with Glamsterdam, everyone will be quick by default. Yeah, it'd be nice to have a warning.

133
00:15:30.630 --> 00:15:32.999
stokes: Say if you detect there's pairing issues.

134
00:15:33.330 --> 00:15:37.459
stokes: then clients are free to deprecate and Plex after Glamsterdam, once it's live.

135
00:15:40.120 --> 00:15:40.840
stokes: Okay.

136
00:15:43.510 --> 00:15:44.350
stokes: Cool.

137
00:15:44.540 --> 00:15:48.349
stokes: Anything else on this topic, or will that make us happy for now?

138
00:15:48.730 --> 00:15:52.060
stokes: I mean, there's… I don't… let me just check this corner one time.

139
00:15:53.300 --> 00:15:55.759
stokes: Yeah, I think that'll cover it.

140
00:16:00.150 --> 00:16:06.299
stokes: And… Should that employee, we merge, the spec PR that Justin has here?

141
00:16:06.840 --> 00:16:12.360
stokes: 3866 after Glamsterdam, because then it will reflect the fact that we've deprecated NPLEX.

142
00:16:12.890 --> 00:16:14.170
stokes: Does that sound good to everyone?

143
00:16:21.190 --> 00:16:25.309
stokes: Okay, one thumbs up. I think this car hasn't open for a very long time.

144
00:16:26.410 --> 00:16:31.080
stokes: But hopefully it's, acceptable at this point.

145
00:16:32.310 --> 00:16:33.040
stokes: Okay.

146
00:16:34.600 --> 00:16:41.530
stokes: So… Yeah, there's some more discussion in the chat here, but it sounds like we have a good plan.

147
00:16:41.640 --> 00:16:44.469
stokes: Does someone raise a hand if we need to revisit this?

148
00:16:44.720 --> 00:16:51.820
stokes: So, okay, in that case then, yeah, it sounds like that's pretty straightforward and won't really impact Glamsterdam timelines,

149
00:16:52.050 --> 00:16:54.080
stokes: Which is good, that's what I wanted to clear.

150
00:16:54.560 --> 00:17:10.249
stokes: So then now… okay, I do want to talk about the fork dates. It seems like we agreed either last week or even, this week on ACDT that we would fork Sepolia to Glamsterdam on October 6th.

151
00:17:11.050 --> 00:17:13.140
stokes: And let me just grab this here.

152
00:17:14.000 --> 00:17:15.339
stokes: So…

153
00:17:15.730 --> 00:17:22.369
stokes: It sounds like everyone's in agreement here. I guess this is your final, final chance, if you want to change something.

154
00:17:22.950 --> 00:17:26.150
stokes: I guess in particular, given the latest

155
00:17:26.270 --> 00:17:29.859
stokes: information on the DevNets from PK. That wasn't, I think.

156
00:17:30.540 --> 00:17:38.060
stokes: the most, heartwarming outcome, so I don't know if this is worth revisiting, but I assume it's not.

157
00:17:38.540 --> 00:17:42.019
stokes: So, are we all good with, the Sepolia fork date?

158
00:17:45.510 --> 00:17:48.749
stokes: of October 6th, which is very soon.

159
00:17:53.260 --> 00:17:54.120
stokes: Okay.

160
00:17:54.700 --> 00:17:57.819
stokes: I'll assume that's good, because no one's saying anything.

161
00:17:58.410 --> 00:18:06.569
stokes: So, yeah, that means a couple things, like, I believe, we'll want to get a blog post out, just with the fork timing.

162
00:18:06.760 --> 00:18:12.740
stokes: We also want client releases, so this is where I would like client teams here to chime in.

163
00:18:13.040 --> 00:18:18.349
stokes: Do you have client releases out already, or will you very soon, like this week, for Sepolia?

164
00:18:27.550 --> 00:18:35.019
stokes: A week before… You tell me, Terence. Is that enough time for your users, historically?

165
00:18:35.830 --> 00:18:41.779
terence: Yeah, I mean, Sepolia is fairly, like, centralized by nature, so…

166
00:18:41.780 --> 00:18:43.270
stokes: That's a good point.

167
00:18:45.020 --> 00:18:45.860
stokes: Okay.

168
00:18:46.150 --> 00:18:49.880
stokes: Then, in any case, are we okay with the timeline?

169
00:18:50.570 --> 00:18:53.240
stokes: Yeah, basically just have releases out as soon as possible.

170
00:18:53.240 --> 00:18:57.639
terence: Well, it's mostly the blog post, right? When do you guys think to do the blog post?

171
00:18:59.250 --> 00:19:00.759
stokes: Mike, that could be done…

172
00:19:01.940 --> 00:19:07.019
stokes: Tomorrow at the latest. Like, that won't take very long. That should have already been out, I think.

173
00:19:07.560 --> 00:19:10.370
stokes: So something we should do ASAP.

174
00:19:11.090 --> 00:19:12.759
stokes: Otis, then Fredrik.

175
00:19:12.940 --> 00:19:17.579
potuz: Just a comment, if… if we are going to fork soon, I would…

176
00:19:17.750 --> 00:19:21.020
potuz: Strongly advise clients to have a ready,

177
00:19:21.030 --> 00:19:39.670
potuz: good circuit breaker for the P2P stack on DevNets. It might not need to be the same as the… I'm sorry, for DevNets. Might not need to be the same for Mainnet, but on DevNet, it's just trivial and cheap to… to, like, dust the entire chain by sending high bids, so please have good circuit breakers.

178
00:19:41.040 --> 00:19:43.840
potuz: We're not gonna work without circuit breakers on DevNets.

179
00:19:47.620 --> 00:19:51.960
stokes: Yeah, do we not already have this, put us? I imagine… I would hope for.

180
00:19:51.960 --> 00:19:52.859
potuz: I don't think Fred…

181
00:19:52.860 --> 00:19:55.199
stokes: We would have already been doing this on DevNuts.

182
00:19:55.340 --> 00:20:07.070
potuz: I don't think we have, we have all clients having circuit breakers, especially none that are banning per builder. I think most circuit breakers, like, just fall back quickly to

183
00:20:07.240 --> 00:20:14.390
potuz: To… to local building, Only after a lot of blocks have been missing?

184
00:20:17.290 --> 00:20:19.189
stokes: Okay, well, this is a good point.

185
00:20:22.250 --> 00:20:24.349
stokes: Yeah, try to do this, and…

186
00:20:25.810 --> 00:20:30.249
stokes: as long as enough of the steak on Sepolia has this, then it should be okay.

187
00:20:30.590 --> 00:20:31.450
stokes: T.M.

188
00:20:31.700 --> 00:20:33.710
stokes: Fredrik and then Tony.

189
00:20:36.270 --> 00:20:38.429
Fredrik: Yeah, I just want to say that…

190
00:20:39.950 --> 00:20:45.229
Fredrik: By doing this, we're… just so people are aware of it, that we are bypassing the…

191
00:20:45.750 --> 00:20:50.730
Fredrik: Protocol upgrade process, which do state that we should have

192
00:20:50.900 --> 00:20:58.660
Fredrik: or there must be at least 14 days between client release being ready and the first testnet going live. The reason for that is that

193
00:20:58.820 --> 00:21:00.290
Fredrik: Those 14 days?

194
00:21:00.570 --> 00:21:04.980
Fredrik: Have been used for internal security reviews, and…

195
00:21:05.420 --> 00:21:09.950
Fredrik: Adding the release-ready clients to the bug bounty program.

196
00:21:10.070 --> 00:21:15.509
Fredrik: As well as, you know, potentially doing some external security reviews, and by…

197
00:21:16.500 --> 00:21:23.670
Fredrik: Lowering the window to 7 days, we… Don't have as much time.

198
00:21:24.320 --> 00:21:30.060
Fredrik: to… to review… I'm guessing it's…

199
00:21:31.990 --> 00:21:41.629
Fredrik: may be more acceptable this time, because, as terence mentioned, Sepolia is more centralized, so if something do go wrong, then we can probably…

200
00:21:42.300 --> 00:21:44.689
Fredrik: Rescue it easier.

201
00:21:44.960 --> 00:21:52.519
Fredrik: But, yeah, I just wanted to flag that it's, Yeah, that's the reason.

202
00:21:53.290 --> 00:21:55.619
stokes: Yeah, we have those two weeks for a reason.

203
00:21:55.950 --> 00:21:57.449
stokes: Thank you for flagging that.

204
00:21:57.660 --> 00:21:59.710
stokes: I think it's a good point.

205
00:22:00.810 --> 00:22:07.799
stokes: I would say if we're comfortable with the shorter time frame for just Sepolia, I do… at least I hope it will be okay.

206
00:22:08.510 --> 00:22:13.999
stokes: Maybe a path forward is just to have clients say.

207
00:22:14.130 --> 00:22:21.320
stokes: Hey, try to get your releases out as quickly as possible, and, you know, if that takes… let's see, it would be, like…

208
00:22:22.410 --> 00:22:31.149
stokes: let's call it maybe 10 working days. That's one week before, but if you can do it sooner, you know, that's obviously better, because it'll just give more time for more eyes.

209
00:22:35.880 --> 00:22:36.680
stokes: So…

210
00:22:38.340 --> 00:22:43.530
Fredrik: Yeah, as soon as… as soon as the release is ready, they can be included in the Bug Bonsai program.

211
00:22:46.080 --> 00:22:48.780
stokes: Okay, so yeah, please try to get a release out sooner.

212
00:22:51.490 --> 00:23:01.989
stokes: If anything, I don't even want to say one week, which would be the 29th, but 29th at my latest, please try to get it out sooner. I think that will do for now.

213
00:23:02.670 --> 00:23:08.750
stokes: And… Yeah, Marius, to your question, that's what we're discussing right now. Like,

214
00:23:08.880 --> 00:23:11.280
stokes: The fork should be ready to go for the 6th.

215
00:23:11.790 --> 00:23:14.119
stokes: And that basically means client relations should be out.

216
00:23:14.330 --> 00:23:15.290
stokes: Face up.

217
00:23:17.280 --> 00:23:19.099
stokes: Tony, you'd hide your hand for a minute.

218
00:23:22.530 --> 00:23:36.600
Toni Wahrstätter: Yeah, I had a comment, not to the dates, but to what you said earlier. I was wondering why we would, be stricter on the definite when it comes to the P2P circuit breakers, because I've been using

219
00:23:36.930 --> 00:23:41.199
Toni Wahrstätter: a few builders to test EL

220
00:23:41.400 --> 00:23:50.799
Toni Wahrstätter: things, and having, like, strict circuit breakers would make that impossible. I think we should just use the same circuit breakers that we have on mainnet.

221
00:23:51.230 --> 00:23:59.950
potuz: Well, because I can just spin up a thousand builders, rotate them, offer very high bids, and not produce

222
00:24:00.260 --> 00:24:01.750
potuz: payloads.

223
00:24:01.890 --> 00:24:02.820
potuz: for free.

224
00:24:03.330 --> 00:24:05.510
potuz: And I just dOS the chain for free.

225
00:24:06.950 --> 00:24:09.840
potuz: I expect this to happen. Any teenager can do this.

226
00:24:15.380 --> 00:24:18.250
Toni Wahrstätter: Yeah, but it's also possible on Monet, like, that's how…

227
00:24:18.250 --> 00:24:19.000
potuz: Yeah, but it may not.

228
00:24:19.000 --> 00:24:20.289
Toni Wahrstätter: Like, if you can take the…

229
00:24:21.540 --> 00:24:24.259
Toni Wahrstätter: Right, but if the attack works, then…

230
00:24:25.280 --> 00:24:27.920
Toni Wahrstätter: It might be worth it, even if it costs money.

231
00:24:29.260 --> 00:24:42.250
potuz: Yes, but that's not a problem, that's just the market. You can do this today. So today, I can buy a block, I am paying Ethereum to buy a block, and produce an empty block. That's something that is fine, and we live with that. I can do this today on Mainnet.

232
00:24:42.380 --> 00:24:47.710
potuz: But on DeathNet, this becomes trustless, and it's not something that we want to accept.

233
00:24:48.920 --> 00:24:49.760
potuz: Because it's free.

234
00:24:49.760 --> 00:25:07.189
Toni Wahrstätter: Yeah, I'm not thinking of… I'm not thinking of attacks like this, I'm more thinking of an attack like I buy a payload, I wait a few slots, I release it into a different payload, I try to DOS the proposal of this different slot by releasing a completely different payload way too late.

235
00:25:07.510 --> 00:25:12.370
Toni Wahrstätter: Causing the EL node to reorg back to that state, and then execute

236
00:25:12.480 --> 00:25:20.620
Toni Wahrstätter: the block. There are, like, scenarios like this that I try to test. And for that, I'm always, like, missing my payload, because I'm releasing way too late.

237
00:25:21.730 --> 00:25:30.200
potuz: that's… that's fine, and we are going to carry those kind of tests. Both we're doing this on DevNet now, and we're going to do this on testnets.

238
00:25:30.480 --> 00:25:39.419
potuz: But, I mean, facilitating this kind of testing by allowing anyone to come in on a testnet that is free to get ETH,

239
00:25:39.580 --> 00:25:56.059
potuz: and honestly just take every block out by just outbeating everyone? It sounds crazy to me. We… users are relying on these testnets to actually test their infra. We cannot make it, like, have zero payloads and ruin everyone's testing on these testnets.

240
00:26:02.370 --> 00:26:10.709
stokes: Yeah, I mean, that makes sense in general. I think we just try to do what you asked, put us, which was, yeah, everyone do their best to have circuit breakers in place.

241
00:26:11.560 --> 00:26:14.719
stokes: Again, as long as we end up with

242
00:26:15.040 --> 00:26:18.219
stokes: A large chunk of the stake in place and time.

243
00:26:18.410 --> 00:26:20.579
stokes: Should be okay, and address this issue.

244
00:26:21.220 --> 00:26:24.689
stokes: And… yeah, then we can keep things moving.

245
00:26:26.760 --> 00:26:31.530
stokes: In part because I also want to touch on the Hoodi fork.

246
00:26:32.150 --> 00:26:39.429
stokes: And, yeah, essentially, just the more we delay Sepolia, the more Hoodi's delayed, the more maintenance delayed, etc, etc.

247
00:26:42.380 --> 00:26:50.339
stokes: Okay, it sounds like everyone's good with Sepolia. There's a set of PRs that go with this,

248
00:26:50.920 --> 00:26:58.620
stokes: Yeah, so I can work on these today. So, like, a blog post for everyone, there's ETH clients repos that have various data in them.

249
00:26:59.090 --> 00:27:01.210
stokes: And then also the Meta EIP, so…

250
00:27:01.970 --> 00:27:05.209
stokes: Assume that will all be handled today or tomorrow.

251
00:27:05.600 --> 00:27:08.880
stokes: Then we'll get client releases out ASAP.

252
00:27:09.920 --> 00:27:17.860
stokes: Again, absolute deadline would be the 29th, but please, please, please try to get them out sooner. That will just make it much easier to do a security review.

253
00:27:20.160 --> 00:27:21.460
stokes: Everyone okay with that?

254
00:27:26.050 --> 00:27:30.919
stokes: Okay. And there was a question now of Hoodi, and when we want to schedule Hoodi.

255
00:27:31.320 --> 00:27:37.649
stokes: I think there might have been a question, again, either Monday this week or last week, about scheduling them together.

256
00:27:38.500 --> 00:27:44.630
stokes: I don't know if we want a couple of these things, but in either case, I did want to float a date for Hoodi.

257
00:27:44.850 --> 00:27:55.880
stokes: I think there was a suggestion… a suggestion of either the 26th of October or 27th would just be, I think it was 3 weeks from the 6th. I can double check that on the calendar, yeah.

258
00:27:56.680 --> 00:28:00.480
stokes: Yeah, are we ready to go ahead and pick a date for a hoodie?

259
00:28:06.260 --> 00:28:09.159
stokes: Okay, Matt says he wants to wait to see Sepolia.

260
00:28:10.400 --> 00:28:12.120
stokes: Which isn't the worst idea.

261
00:28:12.330 --> 00:28:16.550
stokes: It just puts more time in to things.

262
00:28:18.400 --> 00:28:23.210
stokes: if we… here, yeah, Matt, what are you thinking? Like, what is WavePoint.

263
00:28:23.210 --> 00:28:24.219
Matthew Keil: I mean, it'd be nice to see…

264
00:28:24.220 --> 00:28:26.299
stokes: Like, one week, or longer?

265
00:28:26.700 --> 00:28:30.910
Matthew Keil: It'd be nice to see a smooth fork transition, both on the CL and EL.

266
00:28:31.160 --> 00:28:34.120
Matthew Keil: Is all I'm… I'm saying before we schedule Hoodi.

267
00:28:34.750 --> 00:28:44.000
stokes: Yeah, yeah. That's fair. But then it's like, yeah, do we want to have, like, an observability… let's say observation period of one week, or just a few days?

268
00:28:44.950 --> 00:28:47.149
stokes: Anyone here have any thoughts on this?

269
00:28:50.370 --> 00:28:54.250
stokes: Because… so there's an ACD on the 8th.

270
00:28:54.400 --> 00:28:56.379
stokes: So that Thursday after the 6th?

271
00:28:57.100 --> 00:29:01.900
stokes: And… what we could do in that case, then, is we could pick…

272
00:29:02.040 --> 00:29:11.790
stokes: the Hoodi date… I mean, even before, so let's say by, like, the 1st, you know, there can be a, you know, concrete date with all these PRs and all these different resources that can be ready to go.

273
00:29:12.310 --> 00:29:18.559
stokes: Such that on the 8th, we can basically just say, yeah, if Sepolia went well, everyone gives a thumbs up on that ACD.

274
00:29:18.900 --> 00:29:22.560
stokes: Then, we're live, client relations can be out.

275
00:29:24.320 --> 00:29:28.660
stokes: Yeah, hopefully soon. I'm looking at the calendar while I'm trying to work through this.

276
00:29:29.200 --> 00:29:34.419
stokes: Like, say we did that, client releases were out by the 13th.

277
00:29:34.690 --> 00:29:39.990
stokes: And then that's 2 weeks until the fork if we targeted the 27th? Would that be enough time?

278
00:29:40.790 --> 00:29:41.880
stokes: For a Hoodi.

279
00:29:46.810 --> 00:29:55.570
Matthew Keil: I mean, we could do a party like we did for, what was it, with the fish, and do it at DEFCON, and we do the fork at DEF CON together, we can hold hands.

280
00:29:55.900 --> 00:29:56.650
stokes: Hmm…

281
00:29:57.680 --> 00:30:16.569
stokes: I would say not to do that. At least that'd be my strong suggestion. Just because Devcon can be distracting, and if something does go wrong, it's suddenly… we're not doing DEF CON, we're doing fork fixing. This has happened in the past, and it's been…

282
00:30:17.670 --> 00:30:21.579
stokes: not fun. So… I think we should avoid that week.

283
00:30:22.410 --> 00:30:25.820
stokes: And… that being said, also trying to figure out…

284
00:30:26.400 --> 00:30:30.490
stokes: Yeah, how to schedule these things to move things forward.

285
00:30:31.940 --> 00:30:39.300
stokes: Let's see… Yeah, POTUS, wait, can you speak a bit more to this? I think you're just saying…

286
00:30:40.970 --> 00:30:45.720
stokes: I assume they'll be ready. Yeah, I mean, I assume they'll be ready, right? So, like…

287
00:30:47.390 --> 00:30:53.349
stokes: Like, we won't schedule Mainnet until we see Sepolia and Hoodi, right? So…

288
00:30:53.840 --> 00:30:54.490
potuz: Yeah, but it…

289
00:30:55.030 --> 00:31:11.550
potuz: We are not… we're not really testing the actual builders that are the ones that we're using on… on mainnet, and it'd be nice to test them with them already ready at the fork, because that's what's going to happen on Mainnet, and we haven't been doing this on DevNet.

290
00:31:11.550 --> 00:31:12.310
stokes: Hmm, okay.

291
00:31:12.310 --> 00:31:14.630
potuz: I hope to do this on testnets, at least.

292
00:31:14.970 --> 00:31:22.009
stokes: Right. I mean, yeah, that's a good call. So we can do this on Hoodi, at least, and, you know, if we pull it together, also on Sepolia.

293
00:31:24.260 --> 00:31:26.550
Toni Wahrstätter: What exactly wasn't tested there?

294
00:31:27.560 --> 00:31:34.640
potuz: just direct connections to builders, that's going to be, like, most of our blocks on mainnet, and we're not testing this

295
00:31:34.770 --> 00:31:51.879
potuz: neither them depositing before the fork and trying to build payloads after the fork, and having all validators, or most validators, actually connecting and calling them. I think even CL clients, I'm not sure how many of them are actually calling already on the builder API.

296
00:31:52.480 --> 00:31:57.610
potuz: So I know Prysm and Lodestar are, I'm not sure other clients.

297
00:31:57.760 --> 00:32:04.479
potuz: And this is really how we build our blocks, so we really need to test this, and it's completely under-tested now.

298
00:32:06.220 --> 00:32:07.920
stokes: Oh, it's been tested on DevNuts, right?

299
00:32:08.150 --> 00:32:10.480
potuz: It is being tested on DevNets.

300
00:32:10.480 --> 00:32:14.470
stokes: Yeah, but then you just want the integration of, like, quote, production, yeah, software.

301
00:32:14.480 --> 00:32:24.669
potuz: Yeah, we need at least Titan ultrasound, the normal builders, to actually deploy. Otherwise, we're gonna go without knowing what's gonna happen.

302
00:32:27.110 --> 00:32:35.459
stokes: Yeah, so… I don't know how many of them run on Sepolia. If there are some, then we can start this now with Sepolia.

303
00:32:36.200 --> 00:32:38.180
stokes: I think we should definitely do this for Hoodi.

304
00:32:39.520 --> 00:32:44.389
stokes: So it's a good call-out. I think, though, that won't really change too much.

305
00:32:45.300 --> 00:32:46.300
stokes: From today.

306
00:32:49.570 --> 00:32:57.649
Matthew Keil: I mean, just from a messaging perspective, like, do they realize 10,000 of us are gonna call in the same epoch and, you know what I mean, and try to open sockets all at once?

307
00:32:57.650 --> 00:33:05.850
potuz: No, that's not true. No, wait, wait, why would you do that? You only need to call 32 or 64 maximum.

308
00:33:05.850 --> 00:33:08.110
Matthew Keil: That's a good point. Okay, take that back.

309
00:33:14.030 --> 00:33:18.949
stokes: Okay, so, yeah, these have been good points to flag.

310
00:33:19.460 --> 00:33:25.679
stokes: I think then what we can say today is we move ahead with the Sepolia fork on the 6th.

311
00:33:26.550 --> 00:33:27.730
stokes: we…

312
00:33:28.510 --> 00:33:39.219
stokes: Sorry, let me just check the calendar one more time. A lot of logistics I haven't done ahead of time. So… yeah, if anything, we can have, like, a tentative plan for a Hoodi next week.

313
00:33:39.780 --> 00:33:45.639
stokes: As in, sure, like, I can even come and just propose a concrete time. Of course, that's pending Sepolia.

314
00:33:45.950 --> 00:33:53.110
stokes: And the point here is just to have these things pipelined, such that what we can do then is Sepolia fork on the 6th.

315
00:33:54.060 --> 00:34:02.569
stokes: Give it a day or two, such that by the ACD on the 8th, if everything looks good, we go ahead and say yes, Hoodi's happening, say, on the 27th.

316
00:34:03.650 --> 00:34:05.310
stokes: That gives…

317
00:34:05.540 --> 00:34:13.450
stokes: call it a month, then also to get the builders, ready for testing on Hoodi, and then we should all be good to go.

318
00:34:13.929 --> 00:34:21.299
stokes: That gives us those few days after the 27th, you know, whenever that fork happens in that week, to observe what happens with Hoodi.

319
00:34:22.400 --> 00:34:28.059
stokes: then DEFCON happens, and… From there, yeah, we'll be in a good place to figure out mainnet.

320
00:34:30.199 --> 00:34:31.659
stokes: Sound like a good plan to everyone?

321
00:34:37.580 --> 00:34:40.500
stokes: Okay, got some thumbs up, cool.

322
00:34:41.210 --> 00:34:52.590
stokes: And, yeah, I don't know what sort of AI will produce some artifact after this, but yeah, I'll make sure that that gets written down somewhere, so that we can…

323
00:34:52.870 --> 00:34:54.380
stokes: Use it to move forward.

324
00:34:55.790 --> 00:35:03.239
stokes: Cool. So… let me grab the agenda here. Okay, I think this was all I had for Glamsterdam.

325
00:35:03.580 --> 00:35:06.580
stokes: Any other Glamstrame comments we should touch on right now?

326
00:35:07.110 --> 00:35:09.510
stokes: Otherwise, we'll move to Hegota.

327
00:35:15.210 --> 00:35:16.630
stokes: Okay, thanks.

328
00:35:16.940 --> 00:35:21.529
stokes: So now with Hegota… so… yeah,

329
00:35:22.990 --> 00:35:30.419
stokes: my understanding is that we've, done the PFI process, so now that we have all these EIPs.

330
00:35:30.660 --> 00:35:38.710
stokes: For non-headliners, clients have put out their rankings, and those have, yeah, they're at least up now.

331
00:35:39.850 --> 00:35:49.479
stokes: Before we go directly into scoping, where I will have a suggestion on just how to approach the process overall, because I think there's something like 20…

332
00:35:50.420 --> 00:35:54.260
stokes: 23, CLE IPs that we'll have to work through.

333
00:35:54.840 --> 00:35:57.849
stokes: So that's, yeah, a moderate number.

334
00:35:58.220 --> 00:36:04.220
stokes: But before we do that, there was a request to go ahead and PFI 8411,

335
00:36:04.580 --> 00:36:09.020
stokes: From Kamil here. I don't… is Kamil on the call?

336
00:36:09.400 --> 00:36:10.769
Kamil Salakhiev: Yeah, I'm here, hello.

337
00:36:11.240 --> 00:36:12.120
stokes: Okay, hey.

338
00:36:12.360 --> 00:36:20.050
stokes: Would you just want to give, like, a super… well, I don't know, maybe people already know 8411, but maybe just, like, you know, a few sentence summary?

339
00:36:20.440 --> 00:36:25.849
stokes: And… yeah, then the ask is, yeah, just to go ahead and PFI it so we can consider it for HEGOTalk.

340
00:36:27.310 --> 00:36:33.319
Kamil Salakhiev: Yeah, can I have a few minutes just to give a context and explain what this maybe is?

341
00:36:33.760 --> 00:36:34.120
stokes: Trick.

342
00:36:34.540 --> 00:36:38.120
Kamil Salakhiev: Sweet. Yeah, hope you can see my screen.

343
00:36:38.270 --> 00:36:45.140
Kamil Salakhiev: Yep. Okay, yeah, it's a new EIP, just, yeah, I would like to quickly go through

344
00:36:46.010 --> 00:36:48.899
Kamil Salakhiev: Some timeline to explain the…

345
00:36:49.240 --> 00:37:05.170
Kamil Salakhiev: motivation and some… give some context. So yeah, originally we proposed 8142, which is blocks and blobs, to be PFified for Higota. Yeah, that EIP proposed reusing data column subnets for payload broadcast. Then we iterated quite a lot, and

346
00:37:05.450 --> 00:37:18.040
Kamil Salakhiev: Yeah, we updated the EIP, we replaced the networking scheme so that we are not reusing data column subnets, introducing new payload data column subnets, and also replacing KZG commitment scheme with Mercury commitment scheme.

347
00:37:18.490 --> 00:37:27.770
Kamil Salakhiev: But yeah, that doesn't matter, because eventually we decided that much cleaner would be just to create a new EIP that would be purely focused on the

348
00:37:27.820 --> 00:37:38.640
Kamil Salakhiev: fast payload broadcast, and so here we are, yeah, we just would like to propose ACD and ask permission to PFI this Hegota instead of the originally proposed Blocks and blobs EIP.

349
00:37:39.110 --> 00:37:43.190
Kamil Salakhiev: Yeah, the motivation is still the same. Yeah, we'd like to…

350
00:37:43.390 --> 00:37:49.279
Kamil Salakhiev: Well, we can see the execution payload topic to be inefficient, payloads are large messages.

351
00:37:49.590 --> 00:38:03.650
Kamil Salakhiev: Well, we don't have payload, topic today, but yeah, the blocks are around 100 kilobytes today, and in the past, we observed blocks of size 1MB, so that gives some numbers for what we can expect for payload messages.

352
00:38:04.300 --> 00:38:15.369
Kamil Salakhiev: And, yeah, gossip-sub is not efficient for that large message processing, so we have store and forward delay. Yeah, so before we can propagate the message, we have to download it in full.

353
00:38:15.700 --> 00:38:19.209
Kamil Salakhiev: We have in-flight duplicates, so it's very hard to cancel

354
00:38:19.350 --> 00:38:27.549
Kamil Salakhiev: A message that was already sent on a wire, even if the receiver already received the message from someone else, that creates some wasted bandwidth.

355
00:38:28.010 --> 00:38:36.060
Kamil Salakhiev: And we think that, yeah, the urgency is growing with upcoming forks, so Glamsterdam increases gas limit, which implies larger payloads, and

356
00:38:36.250 --> 00:38:41.589
Kamil Salakhiev: Yeah, there is a proposal for quicker slots, which cuts slot time from 12 seconds to 10 seconds.

357
00:38:42.130 --> 00:38:51.449
Kamil Salakhiev: And importantly, we think that current… this new EIP's fundamentals will be, yeah, eventually applied in some other large messages.

358
00:38:51.800 --> 00:38:57.849
Kamil Salakhiev: For example, for Bulse, there is EIP8146, it may be in LeanVM proofs eventually.

359
00:38:58.010 --> 00:39:04.529
Kamil Salakhiev: And, yeah, kind of building this segment… segmented message broadcast machinery today.

360
00:39:04.990 --> 00:39:09.820
Kamil Salakhiev: would be, I mean, very useful in future, so yeah, we can iterate faster.

361
00:39:10.270 --> 00:39:17.920
Kamil Salakhiev: with the next forks. Yeah, really briefly what this EIP actually is. Yeah, we're just splitting the payload into 64 pieces.

362
00:39:18.410 --> 00:39:24.190
Kamil Salakhiev: Yeah, we build the Merco tree on top, we have Merco root commitment in the… well, we include it in the bid.

363
00:39:24.390 --> 00:39:27.909
Kamil Salakhiev: We replaced execution payload topic with payload chunks topic.

364
00:39:28.020 --> 00:39:32.580
Kamil Salakhiev: we attach, yeah, marco proofs to each chunk message.

365
00:39:32.820 --> 00:39:44.370
Kamil Salakhiev: And importantly, yeah, we are not introducing any new EIP2P changes, we are not adding a res recording, we are not introducing 128 new topics that we proposed in Blocks and blobs, so we just want to keep this EIP really simple.

366
00:39:44.610 --> 00:39:50.429
Kamil Salakhiev: But even with this change, yeah, well, in my simulations, and there were a bunch of other previous

367
00:39:50.570 --> 00:39:55.359
Kamil Salakhiev: work that confirms that as well. Yeah, we observed that we can already gain quite a lot.

368
00:39:56.610 --> 00:40:11.700
Kamil Salakhiev: So, yeah, if we just replace this Vanilla gossip sub with the full message broadcast with chunked gossip sub, yeah, for example, in my simulations with 4,000 hosts and 1MB payload, the P95 latency for broadcast drops from around 6 seconds to around 2 seconds.

369
00:40:11.910 --> 00:40:17.439
Kamil Salakhiev: We can squeeze much more if we just, yeah, introduce maybe a resume coding, introduce dedicated

370
00:40:17.760 --> 00:40:33.790
Kamil Salakhiev: path traversal for each chunk, for example, by having dedicated subnets for each of them. But, yeah, that's, extends the scope. Yeah, we just want to keep the scope simple for Hegota, and yeah, in future we can iterate on top.

371
00:40:33.920 --> 00:40:36.859
Kamil Salakhiev: Yeah, you can read more about,

372
00:40:37.130 --> 00:40:44.370
Kamil Salakhiev: some more research and some other stuff that we can build on top to actually optimize stuff. For example, there was post from Caba, there was a lot of

373
00:40:44.690 --> 00:40:49.779
Kamil Salakhiev: work done by potuz, Raul, and many others that, yeah, was around about this.

374
00:40:50.120 --> 00:40:57.969
Kamil Salakhiev: And yeah, that's all I had for today. Yeah, happy to hear opinion from clients, so thanks.

375
00:40:58.670 --> 00:41:05.139
stokes: Well, yeah, let me jump in here really quick. So, just to be clear, both, I think, for myself and then to everyone else.

376
00:41:05.430 --> 00:41:11.780
stokes: The ask is just to PFI it such that we can consider it as a non-hemliner EIP for Hogoda, right?

377
00:41:11.980 --> 00:41:13.110
Kamil Salakhiev: Correct, yes.

378
00:41:13.110 --> 00:41:16.820
stokes: Yeah, okay. So yeah, like, just again, to make this super clear.

379
00:41:17.530 --> 00:41:25.819
stokes: That would mean that it is then, in the set of EIPs, you know, clients will need a week to go think about it and put it into their rankings,

380
00:41:26.040 --> 00:41:34.449
stokes: Yeah, unless that's already clear, but I think we'll need to take some time for that. So we're not deciding on it going into Hegota necessarily today, just… yeah.

381
00:41:34.710 --> 00:41:37.120
stokes: We're deciding, can we consider it?

382
00:41:38.170 --> 00:41:42.379
stokes: Okay. So as long as that's good… oh yeah, Kamil?

383
00:41:42.830 --> 00:41:46.950
Kamil Salakhiev: Yeah, I think some clients already kind of mentioned that in their tier lists, so…

384
00:41:46.950 --> 00:41:47.920
stokes: Yeah.

385
00:41:48.090 --> 00:41:49.709
stokes: Yeah, I think I saw at least one.

386
00:41:50.260 --> 00:41:56.639
stokes: But yeah, so I'm just trying not to get ahead of ourselves before we jump into scoping.

387
00:41:56.920 --> 00:42:04.799
stokes: Then on the EIP itself, I did have a question, because you mentioned erasure coding. This would be for it's compatible with anything we want to do there, right?

388
00:42:05.700 --> 00:42:13.070
Kamil Salakhiev: Well, it's not backwards compatible, I mean, we need a fork for that. I mean, we're making change to the bit, we're introducing a new field.

389
00:42:13.450 --> 00:42:16.760
stokes: Yeah, well, I mean more, like, if we do… like, if we do…

390
00:42:17.150 --> 00:42:20.370
stokes: 8411, can we, like, add more stuff on top later?

391
00:42:20.750 --> 00:42:28.079
Kamil Salakhiev: We can, but it's not… for example, introducing a resure clinic will not be backwards compatible in full, I mean, we can.

392
00:42:28.080 --> 00:42:30.140
stokes: This is something we could change, too, yeah.

393
00:42:30.140 --> 00:42:48.550
Kamil Salakhiev: We can change some stuff, definitely there could be some implementation details which each client can work on individually, that… but yeah, on a wire, I mean, for Consensus… yeah, there are some optimizations that we can do that would not require a fork, but in future, for example, if we want to introduce erasure coding, I would rather have a separate EIP for that.

394
00:42:50.900 --> 00:42:52.140
stokes: Ahmad.

395
00:42:53.820 --> 00:42:56.469
Kamil Salakhiev: Yeah, I see a hand from Toni.

396
00:42:56.650 --> 00:42:57.859
stokes: Yeah, Toni and Chopper?

397
00:42:57.860 --> 00:43:06.870
Toni Wahrstätter: Yeah, I just wanted to add, the EIP is also very much a simpler subset of the Block in blobs EIP. So, to me, it feels like,

398
00:43:07.000 --> 00:43:14.850
Toni Wahrstätter: Should be fine that it comes a little bit later, because it seems like clients, there's little appetite to ship Block-in blobs.

399
00:43:15.010 --> 00:43:17.620
Toni Wahrstätter: But the CIP does make a lot of sense.

400
00:43:21.700 --> 00:43:31.519
Kamil Salakhiev: Yeah, exactly. Well, these blocks in blobs, I mean, yeah, it was… the blocks themselves, they were a bit of disruption, I mean, yeah, which is why.

401
00:43:31.670 --> 00:43:41.850
Kamil Salakhiev: I mean, the more we were iterating on the blocks in blobs EIP, the more… the less it was about blobs, and more about just payload broadcasts, which is why, yeah, we have this dedicated EIP.

402
00:43:43.550 --> 00:43:45.410
Kamil Salakhiev: And from Caba.

403
00:43:46.930 --> 00:43:56.219
Csaba: Yeah, from my side, I just wanted to, yeah, that the goal is to be a fight, so that we can do the technical discussion without process.

404
00:43:56.520 --> 00:44:00.470
Csaba: Complexities. And then, on the…

405
00:44:01.060 --> 00:44:04.079
Csaba: Whether that Azure code or not, it's LEDE.

406
00:44:04.680 --> 00:44:16.250
Csaba: The thing that we need here is to… to… to make sure that we have the additional commitment in the bid, and that's, that's… we regard that as the vehicle to…

407
00:44:16.340 --> 00:44:29.400
Csaba: to send it around, and then from there, there are the details of whether we are good or not, and which scheme we use, and all those kind of things. I have a long lineup, which is going through, like, 20 options.

408
00:44:29.770 --> 00:44:33.379
Csaba: And we can definitely go into more detail on that later, but…

409
00:44:34.530 --> 00:44:39.179
Csaba: We need that kind of change in the bid structure.

410
00:44:42.300 --> 00:44:43.849
stokes: Thank you.

411
00:44:44.420 --> 00:44:51.900
stokes: So, yeah, and again, just to be clear, this is just on the PFI question. I… Well, yeah,

412
00:44:52.980 --> 00:45:02.639
stokes: My take is this seems fine. Ansgar had a comment here in the chat with a number of thumbs up. So, yeah, anyone have an issue with PFI?

413
00:45:03.320 --> 00:45:05.849
stokes: And, you know, kind of just to make…

414
00:45:06.310 --> 00:45:20.400
stokes: the process clear then, we'd DFI it today, we wouldn't, I think, be able to make a decision on it today, so then that would be a future call as part of the actual scoping decision, but it then would be in the set of possible non-headliners.

415
00:45:22.610 --> 00:45:24.790
stokes: Got another PFI seems fine.

416
00:45:30.600 --> 00:45:31.430
stokes: Okay.

417
00:45:32.110 --> 00:45:36.469
stokes: Okay, yeah. Seems to go to people then. So yeah, we'll go ahead and PFI it.

418
00:45:37.020 --> 00:45:48.300
stokes: Then, the ask after this call will just be to have client teams, take a look and weigh it into their other rankings, and ideally even update their rankings.

419
00:45:48.720 --> 00:45:50.910
stokes: With this EIP.

420
00:45:51.440 --> 00:45:54.390
stokes: And then we will handle that on a future call.

421
00:45:55.220 --> 00:45:56.850
stokes: Okay, thank you, Kamil.

422
00:45:57.980 --> 00:46:03.579
stokes: So, now we can turn to… oh yeah, Ansgar, did you have a comment on this?

423
00:46:03.580 --> 00:46:13.990
Ansgar Dietrichs: Yeah, just because I'll put it in chat, I would just directionally maybe ask that we… it doesn't have to be, like, a strict, this EIP gets decided after literally everything else, but I think at least…

424
00:46:14.050 --> 00:46:33.039
Ansgar Dietrichs: like, for example, I would not love if we would make a decision on this EIP in particular, say, already in two weeks, because I think while it is similar, like, it's basically a somewhat modified subset of BlockN blobs, but I think the considerations also around forward compatibility and, and say, for example, specifically the Why Now, it's all a bit…

425
00:46:33.040 --> 00:46:45.630
Ansgar Dietrichs: different, it's different enough that I think having sufficient time to really look into it would be really valuable, so I… I would just maybe ask that shared understanding is that we will make the decision on this EIP more towards the end of the scoping process. Yeah.

426
00:46:45.970 --> 00:46:47.149
Ansgar Dietrichs: Just wanted to say that.

427
00:46:50.030 --> 00:46:53.399
stokes: I mean, seems reasonable to me. I think that's a reason to ask.

428
00:46:55.590 --> 00:47:02.659
stokes: I guess on that topic, are there… is there, like, a breakout call for this work, or something like this?

429
00:47:03.160 --> 00:47:04.919
stokes: Because, yeah, the… Yeah. Okay.

430
00:47:05.070 --> 00:47:17.659
Kamil Salakhiev: I think there is a Discord thread, yeah, where I will share the link in the chat, where you can jump in and discuss more. Yeah, we discussed that on P2P call, about the EIP itself, so… from the technical perspective.

431
00:47:18.910 --> 00:47:21.279
Kamil Salakhiev: Yeah, I can share all the links.

432
00:47:21.950 --> 00:47:24.089
stokes: Okay, thanks. Yeah, cause I…

433
00:47:24.350 --> 00:47:31.039
stokes: It might just be me, but I haven't had time to look at this too closely, so… yeah, it'd be good to…

434
00:47:31.570 --> 00:47:36.820
stokes: Have a place where we can learn more, and yeah, use that as a path to move this forward.

435
00:47:37.450 --> 00:47:38.929
stokes: In the scoping process.

436
00:47:39.690 --> 00:47:40.830
stokes: Okay.

437
00:47:42.620 --> 00:47:48.929
stokes: So, now we'll turn to, Hegota scoping with the non-headliners.

438
00:47:49.390 --> 00:47:55.749
stokes: So… Yeah, again, there are… let me pull up the forecast here.

439
00:47:56.090 --> 00:48:01.399
stokes: Looks like there are 23 EIPs, which is quite a large number of them.

440
00:48:02.330 --> 00:48:05.199
stokes: In terms of starting.

441
00:48:05.700 --> 00:48:13.719
stokes: What I would suggest is that we try to do what we can today. If you go by the client rankings, there are…

442
00:48:14.040 --> 00:48:18.600
stokes: you know, batches of EIPs that I think pretty much everyone agrees that we DFI.

443
00:48:19.220 --> 00:48:27.860
stokes: There's something like two that we seem to have nearly universal support for, via the client rankings.

444
00:48:28.130 --> 00:48:32.550
stokes: So, I think for these, it seems like we can go ahead and make those calls today.

445
00:48:33.160 --> 00:48:40.060
stokes: Then from there, there's a number of more ambiguous EIPs I think…

446
00:48:40.250 --> 00:48:48.559
stokes: those will ultimately need more discussion, and so I would at least ask that we just handle those, at least on the next call, and…

447
00:48:49.100 --> 00:48:53.260
stokes: Point being, it might take multiple calls to get through this, we'll just have to see how it goes.

448
00:48:54.310 --> 00:48:56.899
stokes: But in that case, let me…

449
00:48:57.660 --> 00:49:05.439
stokes: Let's see… I was talking to Mark, he offered to help screen share. Let me try, Mark, because I think I can just do this here.

450
00:49:05.730 --> 00:49:08.130
stokes: Oh yeah, Terence, you have a comment?

451
00:49:08.130 --> 00:49:31.120
terence: Now, there's one thing that I realized, and it's probably my fault for not reading this correctly. So basically, from our stance, we have this EIP that would give it, like, a very high tier, but then we say only if the EIP conditioning does something else, right? So basically, one example is this BOS withdraw credential retirement, that basically the EIP does two things. First.

452
00:49:31.140 --> 00:49:53.200
terence: you basically block the deposit through the deposit contract. Second is that it… I think it forced, ejects 0x00 Validator, and for us, we really, really love the first part, we don't like the second part, so we basically say that we will give this an A tier if it only does the first part. But today, it does two parts, so I think it may be more like a

453
00:49:53.200 --> 00:49:57.290
terence: C or DFI tier in… in basically today's

454
00:49:57.290 --> 00:50:11.310
terence: state versus, A tier, that's what we wrote it. But if you look at the forecast ranking page, it actually counts as an A, so I just want to throw that out. It may screw some, like, number here and there.

455
00:50:17.150 --> 00:50:28.750
stokes: Hey, sorry, I was screen sharing, and I lost the mute button. Yeah, yeah, that's helpful, and I did want to get into that one, because that was 8365, right?

456
00:50:28.880 --> 00:50:34.679
stokes: So yeah, we should discuss that, but… Before we get there,

457
00:50:35.020 --> 00:50:39.360
stokes: I just wanted to run through kind of what I was thinking in terms of what I think would make sense today.

458
00:50:39.630 --> 00:50:44.269
stokes: So, essentially, yeah. So, can everyone see this forecast page?

459
00:50:46.160 --> 00:50:47.479
stokes: You're with the rankings?

460
00:50:47.820 --> 00:50:48.420
nixo: Yes.

461
00:50:49.100 --> 00:50:51.380
stokes: Okay, thank you. So…

462
00:50:51.760 --> 00:50:57.799
stokes: Okay, like, just going by this, the way that I kind of look at this first pass is…

463
00:50:57.960 --> 00:51:04.720
stokes: We have these top two here, they have this little green box of a high enough average score via the client rankings here.

464
00:51:05.900 --> 00:51:15.579
stokes: Seems like those are non-controversial, and yeah, other than what Terence brought up, there was a scope question to get into around 8365, which we can do in a second.

465
00:51:16.230 --> 00:51:18.700
stokes: But, yeah, seems…

466
00:51:19.070 --> 00:51:25.530
stokes: And again, I'm not saying these are CFI'd, but I would propose that we start there, for today.

467
00:51:25.670 --> 00:51:34.870
stokes: So I think we can start there. And then also on the other end, we have all of these EIPs here that have essentially this little red box here.

468
00:51:35.290 --> 00:51:40.379
stokes: There was not… Well, if anything, there was consensus on DFI for these things.

469
00:51:40.700 --> 00:51:45.740
stokes: So, I propose, in terms of actually working through the scoping, we would…

470
00:51:46.230 --> 00:51:49.009
stokes: do the two here that we can CFI.

471
00:51:49.240 --> 00:51:55.980
stokes: Then also do all of these that look like clear DFIs, which is everything 8237 and below.

472
00:51:56.520 --> 00:51:58.100
stokes: I will…

473
00:51:58.830 --> 00:52:08.230
stokes: strongly suggest we pull out issuance here, just because I think that needs to be considered separately, given the community impact, so I'd actually just ask to table 8363 today.

474
00:52:08.780 --> 00:52:14.419
stokes: But otherwise, I think we can go ahead and do this. There's, yeah, maybe 40 minutes or so left on the call today.

475
00:52:14.700 --> 00:52:16.080
stokes: I think we can do that.

476
00:52:16.490 --> 00:52:22.879
stokes: What that means, then, is there are these, like, more ambiguous EIPs with maybe more mixed support.

477
00:52:23.310 --> 00:52:29.729
stokes: those I would suggest we tackle next call, you know? And again, it might take multiple calls to get through everything, but…

478
00:52:29.920 --> 00:52:33.369
stokes: That seems like a pretty smooth way to move forward, so…

479
00:52:35.470 --> 00:52:44.039
stokes: Anyone have any comments on that proposal? If not, we can go ahead and just get into it, and we could start with, these top two.

480
00:52:50.460 --> 00:52:52.530
stokes: I'm catching up on the chat.

481
00:52:54.210 --> 00:52:58.269
stokes: But also, I don't hear anyone. Oh, zoom in a little bit.

482
00:53:00.200 --> 00:53:04.280
stokes: It zoomed in on the Zoom UI. Hang on.

483
00:53:05.270 --> 00:53:07.889
stokes: There we go. Okay, sorry, is that better?

484
00:53:08.060 --> 00:53:09.919
stokes: I can make it quite big.

485
00:53:09.920 --> 00:53:10.490
Justin Florentine: Much better.

486
00:53:10.490 --> 00:53:12.549
stokes: Maybe like that. Okay, sorry about that.

487
00:53:14.290 --> 00:53:20.400
stokes: Okay, so, sounds like, we're on board with this process of just doing the things

488
00:53:20.510 --> 00:53:25.790
stokes: That, yeah, we can kind of clearly make calls on today. So let's go ahead and do that.

489
00:53:27.080 --> 00:53:30.319
stokes: We can try slide mode.

490
00:53:30.560 --> 00:53:32.000
stokes: Let me see what happens.

491
00:53:33.600 --> 00:53:39.639
stokes: The thing about slide mode is I don't know if it's gonna break it out… by rating.

492
00:53:39.770 --> 00:53:40.680
stokes: Yeah.

493
00:53:41.790 --> 00:53:51.370
stokes: So, we can do it this way. I think it might be easier, just given the way that I'm suggesting we think about it, just to go back to the other view. But, yeah.

494
00:53:52.010 --> 00:53:53.889
stokes: Because it kind of mixes these things.

495
00:53:54.780 --> 00:54:00.480
stokes: Let's hold off on slide mode, and if people think that it's useful, just, yeah, say something.

496
00:54:01.160 --> 00:54:05.820
stokes: I think we might need it in future calls, but I think for today, we can move forward this way.

497
00:54:06.150 --> 00:54:10.260
stokes: Okay, so that was a lot of preamble, but then…

498
00:54:10.970 --> 00:54:12.890
stokes: Let me clear up my own screen.

499
00:54:13.270 --> 00:54:21.140
stokes: 8015. So, yeah, I honestly don't even know who the authors are. I guess I can keep screen sharing.

500
00:54:23.490 --> 00:54:31.470
stokes: Terence and Etan. Okay, so, yeah, I think essentially these just don't do anything today, and the EIPs just remove them.

501
00:54:31.750 --> 00:54:33.030
stokes: Pretty straightforward.

502
00:54:33.310 --> 00:54:39.039
stokes: It has pretty strong client support, so I would say we go ahead and CFI this one.

503
00:54:39.310 --> 00:54:41.670
stokes: Anyone… Once.

504
00:54:41.990 --> 00:54:43.099
stokes: To add anything?

505
00:54:51.820 --> 00:54:52.730
stokes: Yakhv?

506
00:54:55.460 --> 00:55:00.649
Kevaundray Wedderburn: Yeah, I think Terence made a comment on the 8365 one.

507
00:55:00.650 --> 00:55:02.430
stokes: Yeah, we're gonna get there next year.

508
00:55:03.170 --> 00:55:04.850
Kevaundray Wedderburn: Oh, sorry, I misheard.

509
00:55:05.340 --> 00:55:11.600
stokes: Yeah, 8015. So just removing these, I believe they're not even written to on the chain today.

510
00:55:13.800 --> 00:55:21.170
stokes: Okay, no one's saying there's any issues with this, so let's go ahead and CFI that. Pretty straightforward. Yep, okay, thanks, Tristan.

511
00:55:21.970 --> 00:55:27.890
stokes: Okay, now then, 8365, again, pretty wide client support here.

512
00:55:28.280 --> 00:55:31.800
stokes: I think this was NC, I think was the author?

513
00:55:32.120 --> 00:55:34.230
stokes: Yeah, I'm not sure if they're here, but…

514
00:55:34.520 --> 00:55:39.949
stokes: As many have pointed out, there was a question here around the actual scope of this one.

515
00:55:40.420 --> 00:55:51.890
stokes: And… yeah, I think, given the time, we have time to go ahead and CFI this, again, reflecting the client support, and figure out the scoping questions, yeah, before we even get to DevNuts.

516
00:55:52.620 --> 00:56:04.809
stokes: Would anyone like to speak to the scoping? I looked a little bit yesterday, and it sounds like there might be this EIP and a complement EIP, and then the question is kind of, yeah, which subset of features make the most sense.

517
00:56:05.240 --> 00:56:06.070
stokes: Notice.

518
00:56:06.890 --> 00:56:08.079
potuz: Are you trying…

519
00:56:10.700 --> 00:56:12.059
stokes: I think you muted yourself.

520
00:56:12.570 --> 00:56:16.939
potuz: Are you talking about the scope of 8015 or 8365?

521
00:56:17.740 --> 00:56:25.560
stokes: Sorry, so… the… yeah, I believe we've all agreed to CFI 8015.

522
00:56:25.560 --> 00:56:26.629
potuz: Yeah, and that's fine.

523
00:56:26.630 --> 00:56:27.260
stokes: That one's done.

524
00:56:27.260 --> 00:56:27.990
potuz: As, usage.

525
00:56:28.330 --> 00:56:30.290
stokes: Yeah. Yep, yeah, so that one's good.

526
00:56:30.570 --> 00:56:31.229
potuz: Okay, so important.

527
00:56:31.230 --> 00:56:32.000
stokes: Next, next year.

528
00:56:32.000 --> 00:56:36.850
potuz: of 8365, I think Prysm would DFI it, and it would change

529
00:56:36.990 --> 00:56:46.850
potuz: very much the scope, if we keep the scope… it would change very much the score if we keep the scope as it is. And I believe Lighthouse posted essentially the same view.

530
00:56:47.090 --> 00:56:50.600
potuz: That we… we are fine with…

531
00:56:50.770 --> 00:56:58.279
potuz: deprecating BLS at the fork, not allowing any more deposits, but we definitely do not want to force exits.

532
00:56:58.410 --> 00:57:01.500
potuz: So, I think this is not a… yeah.

533
00:57:01.620 --> 00:57:05.509
potuz: We strongly believe this. It's not… it's not a minor issue.

534
00:57:06.200 --> 00:57:06.790
stokes: Okay.

535
00:57:08.510 --> 00:57:09.300
stokes: Yeah, I like so.

536
00:57:09.300 --> 00:57:16.200
NC: So the opinions I've gathered, is that, yeah, I see a lot of support of removing

537
00:57:16.390 --> 00:57:19.059
NC: the… the exit part from the EIP.

538
00:57:19.470 --> 00:57:30.670
NC: But I just want to gauge, if any client teams or any researchers have made decisions on this, given that, XA is part of the EIP.

539
00:57:30.860 --> 00:57:36.150
NC: And if I reduce the scope of this EIP, would they change their answer?

540
00:57:43.050 --> 00:57:47.269
stokes: Yeah, maybe just unpack this a bit. So, yeah, the EIP right now…

541
00:57:47.920 --> 00:57:56.020
stokes: would also force exits of all 00 validators at the fork. And then the change, that sounds like there's…

542
00:57:56.480 --> 00:58:07.129
stokes: somewhat strong demand for, is just to drop that part, such that you can still no longer make 00 deposits, but otherwise, I think you just don't touch anything else. Is that correct?

543
00:58:08.690 --> 00:58:09.570
NC: Yes.

544
00:58:09.890 --> 00:58:10.580
stokes: Okay.

545
00:58:11.230 --> 00:58:11.830
NC: But…

546
00:58:11.830 --> 00:58:12.880
stokes: As authors.

547
00:58:12.880 --> 00:58:13.699
NC: I see that a congregation.

548
00:58:13.700 --> 00:58:15.120
stokes: Okay with that change?

549
00:58:16.400 --> 00:58:23.420
NC: I'm okay if a lot of client teams show support, which I have seen there, there are.

550
00:58:23.580 --> 00:58:27.529
NC: But I'm just, trying to see if there's any kind of team that's strongly against

551
00:58:28.120 --> 00:58:31.140
NC: removing this exit part from this EIP.

552
00:58:34.450 --> 00:58:35.130
stokes: Anyone?

553
00:58:38.730 --> 00:58:51.770
NC: To Nixo's question, forced exit means that, the 000 Validators will be excluded from performing Validator duties. Their CL, their funds are, will still be on the CL side.

554
00:58:52.060 --> 00:58:55.310
NC: Until they submit a BLS execution change.

555
00:58:55.680 --> 00:58:59.909
NC: Then their funds will be swept into their execution address.

556
00:59:01.040 --> 00:59:09.709
NC: In the meanwhile, they do not earn rewards, nor incur, occur… Or, incur any penalties.

557
00:59:13.470 --> 00:59:21.399
stokes: Yeah, so I think part of the motivation here is that it's gonna make future PQ plans radically simpler, to go ahead and

558
00:59:21.790 --> 00:59:31.089
stokes: remove this mood of the credentials? Is there any issue on that front? Like, do we still have the same benefits if we don't force exit?

559
00:59:33.330 --> 00:59:33.920
stokes: I know.

560
00:59:33.920 --> 00:59:34.720
NC: a…

561
00:59:34.720 --> 00:59:35.210
stokes: Yeah.

562
00:59:35.210 --> 00:59:46.070
NC: I would say the signal, for encouraging, people to switch to 001 or 002 will be weaker without force exiting these, validators.

563
00:59:46.530 --> 00:59:51.330
NC: Because if you are only doing the deposit guard, it really doesn't touch

564
00:59:51.610 --> 00:59:54.910
NC: Or, it doesn't touch their daily lives, like.

565
00:59:56.830 --> 01:00:04.680
NC: It's just… it's mostly, yeah, it's not really… like, you're not, like, hitting them with a stick to encourage them to switch, basically.

566
01:00:06.850 --> 01:00:16.829
stokes: I might be misremembering, but, what does this deposit card look like? I thought it was that you could still make a 00 deposit, but it would just burn your ETH, basically.

567
01:00:19.180 --> 01:00:24.889
NC: So in the status quo in Glamsterdam, you can still create a new 000 Validators.

568
01:00:25.060 --> 01:00:27.679
NC: There's nothing that rejects or drops them.

569
01:00:27.780 --> 01:00:29.440
NC: So, the first part of this…

570
01:00:29.440 --> 01:00:30.210
stokes: EIP.

571
01:00:30.970 --> 01:00:33.190
NC: With this EIP, it would drop them.

572
01:00:33.390 --> 01:00:40.149
NC: But the top-up deposits to exist, the 000 validators will still be processed as usual.

573
01:00:40.620 --> 01:00:41.190
stokes: Hmm.

574
01:00:44.890 --> 01:00:52.230
stokes: Okay, in terms of time, it does sound like there's interest for this with the reduced scope, so…

575
01:00:53.800 --> 01:00:59.459
stokes: Is there a PR yet with the changes, or were we kind of waiting for this discussion?

576
01:01:09.250 --> 01:01:14.109
Enrico Del Fante: Sorry, guys, what's the argument of not doing the exit?

577
01:01:20.220 --> 01:01:27.950
NC: Some arguments I've, seen is that it might be too rushed, and we might not be given enough grace periods

578
01:01:28.120 --> 01:01:32.370
NC: For… for those, people to switch.

579
01:01:32.650 --> 01:01:38.770
NC: Before freezing their funds and essentially take away their ability to earn rewards, basically.

580
01:01:42.030 --> 01:01:48.350
NC: And by reducing the scope, that means that maybe in a future fork, we do the forced exits, but not in the current fork.

581
01:01:52.420 --> 01:01:57.089
stokes: Yeah, Terence, I feel like you're pretty strong on this, like, what do you see the difference being?

582
01:01:58.980 --> 01:02:07.450
terence: It feels like we're, like, committing to, like, a solution, but, like, without knowing what is the future roadmap of the PQ landscape, right?

583
01:02:09.630 --> 01:02:16.300
stokes: Yeah. Can someone speak to that, actually? I'm also curious, like… I'm assuming somehow it's…

584
01:02:17.170 --> 01:02:22.880
stokes: I guess we're just worried about the BLS keys being… BQ… Sensitive, let's say.

585
01:02:23.100 --> 01:02:24.740
stokes: Put us in a cove.

586
01:02:25.940 --> 01:02:29.960
potuz: Yeah, so, the standard procedure for deprecation is

587
01:02:30.330 --> 01:02:35.750
potuz: Is to do a deprecation, and then another time for actually exiting.

588
01:02:35.850 --> 01:02:44.309
potuz: And agreeing on deprecating this right now, and… but at the same time, the protocol accepting deposits is contradictory.

589
01:02:44.350 --> 01:02:59.440
potuz: So I think deprecation is that thing. We're no longer accepting deposits, and then the next time that we actually enforce exits is the next fork. But also, it gives time to several thousand keys that are active today, that are validating today, because they were stolen.

590
01:02:59.440 --> 01:03:07.779
potuz: To try to… and they're earning rewards, to try to mobilize their stakeholders, probably ourselves.

591
01:03:07.810 --> 01:03:16.210
potuz: to see if we can find a solution for those kids. Otherwise, we're just rushing them on the next year without having them… giving them an opportunity.

592
01:03:20.310 --> 01:03:20.820
stokes: down.

593
01:03:20.820 --> 01:03:23.570
NC: Right, so the argument is, like, how long…

594
01:03:23.740 --> 01:03:25.970
NC: Over time should we give them?

595
01:03:26.640 --> 01:03:36.139
NC: if we do the announcement right now, if the EIP is CFI'd to the live day of Ekoda, that would be, like, 6 to 8 months. Would that be enough?

596
01:03:36.290 --> 01:03:37.859
NC: Or are you saying… consensus.

597
01:03:37.860 --> 01:03:48.940
potuz: I'm saying that if we do this today, that would count as the deprecation time, but then at the same time, the protocol still accepts deposits, so we're not really deprecating anything.

598
01:03:50.660 --> 01:03:56.240
potuz: So I think the standard procedure to deprecate is you no longer accept anything, and then

599
01:03:56.520 --> 01:04:00.769
potuz: In a future epoch, you force exits.

600
01:04:02.270 --> 01:04:17.579
Matthew Keil: you know, this is what I was just thinking. Is it possible, and we've never done something like this before, where we have a two-fork, a two-fork EIP, where it's written into the EIP as, as of now, that

601
01:04:17.590 --> 01:04:22.450
Matthew Keil: In H, we close the door, and then in I,

602
01:04:22.540 --> 01:04:36.609
Matthew Keil: We're gonna do the force exits so that there is a well-trodden timeline that people will be able to, to refer back to in order to get their keys sorted and get themselves ready to… before we exit them.

603
01:04:38.220 --> 01:04:41.470
stokes: Yeah, it sounds like a number of people are kind of proposing something like that.

604
01:04:41.910 --> 01:04:45.590
stokes: maybe figuring out the exact I-Star details down the line, POTUS.

605
01:04:45.790 --> 01:05:04.179
potuz: Also, I want to stress that most likely, these keys are PQ-safe. They have never signed a public message, and we can just keep them as they are. They are PQ-safe. We can trust the signature from those keys because they've never signed anything public on the withdrawal credentials.

606
01:05:04.340 --> 01:05:21.239
potuz: So I don't see how this is a problem. We're gonna be frozen… freezing these keys right now, in Hagota, and by the time that we actually come up with a solution for PQ, then, well, we can trust the opening of those keys. They are hashed.

607
01:05:25.170 --> 01:05:28.569
NC: That also means that, in the PQ world.

608
01:05:28.730 --> 01:05:40.609
NC: We're still going to maintain these 000 validators and potentially design a new credential switch mechanism just to take care of these 9,000 validators.

609
01:05:40.610 --> 01:05:50.870
potuz: That's not true. That's only if PQ happens before we force exits, which is very unlikely, according to any of the expectations we have for PQ.

610
01:05:57.800 --> 01:06:04.420
NC: Okay, so you're… okay, so you are proposing that forced exit is not Hegota, but I-Star.

611
01:06:05.080 --> 01:06:07.860
NC: yes. Is that right?

612
01:06:07.860 --> 01:06:08.410
potuz: Yes.

613
01:06:08.410 --> 01:06:09.020
NC: Okay.

614
01:06:11.360 --> 01:06:26.770
Matthew Keil: And can we just write that into the EIP as it is, so that 8365 covers both situations? H star is the closing the door for new ones, and I-star is going to be the exiting of, exiting of any that are existing.

615
01:06:26.830 --> 01:06:33.450
Matthew Keil: And then that way, there's, like, it's documented that we're doing it in two forks. That's plenty of time for someone to react.

616
01:06:35.910 --> 01:06:44.730
stokes: Yeah, it sounds like there's consensus for this, although I do have a question then, if we take out the forced exits and pagoda 8365?

617
01:06:45.360 --> 01:06:46.929
stokes: what's left in the EIP?

618
01:06:49.160 --> 01:06:56.310
potuz: the… the… the EIP still burns ETH that deposits into a 00 Validator.

619
01:06:56.450 --> 01:06:59.200
stokes: I see, okay, so they, yeah, they wouldn't make new validators.

620
01:06:59.200 --> 01:07:13.070
potuz: By the way, so what Greg is saying is not crazy, but it can be discussed, perhaps, on the chat. We can just hardcode an epoch a year after the Hagota, if people are worried that we might backtrack for the iFork.

621
01:07:13.330 --> 01:07:16.939
potuz: We can just hardcore an epoch in which we just force the exits.

622
01:07:20.710 --> 01:07:25.009
stokes: Maybe. Yeah, no, it seems like we want the optionality.

623
01:07:25.350 --> 01:07:27.380
stokes: Cause, like, I don't… like, we're not gonna go through this.

624
01:07:27.380 --> 01:07:33.929
NC: I thought about this, and I'm actually okay with adding… it's just essentially, like, configure a variable.

625
01:07:34.280 --> 01:07:38.629
NC: In EIP to… to… to start checking those exits.

626
01:07:47.050 --> 01:07:53.999
stokes: So, in terms of moving forward today, it sounds like we have agreement on the path forward with this EIP.

627
01:07:54.550 --> 01:07:59.829
stokes: Kev said there's a PR, which is good.

628
01:08:00.030 --> 01:08:08.589
stokes: So, what I would suggest then is… yeah, again, it sounds like we're in alignment with CFI and the reduced scope version of this.

629
01:08:08.890 --> 01:08:15.720
stokes: So, then yeah, why don't then, in C, just get that merged and get 8365 adjusted.

630
01:08:16.040 --> 01:08:21.369
stokes: by the next call, and then we can revisit this on the next call, where I expect it'll be CFI'd.

631
01:08:22.229 --> 01:08:24.089
stokes: Does that sound good to everyone? Okay.

632
01:08:27.410 --> 01:08:28.090
NC: Sweet.

633
01:08:28.609 --> 01:08:30.279
stokes: Alright.

634
01:08:30.659 --> 01:08:34.869
stokes: Cool. So, yeah, then just to play it back,

635
01:08:35.369 --> 01:08:38.539
stokes: We lean towards CFI and the…

636
01:08:39.799 --> 01:08:42.779
stokes: iteration of 8365. We don't have that today.

637
01:08:42.899 --> 01:08:48.049
stokes: We expect to have it by the next call, next ACDC, where we can then go ahead and CFI that one.

638
01:08:48.739 --> 01:08:49.439
stokes: Okay.

639
01:08:49.779 --> 01:08:50.539
stokes: Cool.

640
01:08:52.299 --> 01:08:58.029
stokes: I feel like you're teeing yourself up, Kev, to say something.

641
01:08:58.349 --> 01:09:00.429
stokes: Would you like to say something?

642
01:09:03.059 --> 01:09:07.869
Kevaundray Wedderburn: I don't know if we still need it to resolve this question.

643
01:09:07.870 --> 01:09:11.900
stokes: Sounds like we're good, but… If you want to add something briefly, you can.

644
01:09:13.270 --> 01:09:23.210
Kevaundray Wedderburn: Sorry, Francesco. Yeah, I guess what I read in the Discord as well is that, I see it conceptually as three different steps as we deprecate first.

645
01:09:23.210 --> 01:09:33.570
Kevaundray Wedderburn: We exit next, and then we deprecate the BLS execution change, which basically means that the 0x0 validators can't actually do anything.

646
01:09:33.689 --> 01:09:41.410
Kevaundray Wedderburn: We can choose to do the two, the two steps, or the two last steps together, which is pretty aggressive.

647
01:09:41.760 --> 01:09:46.609
Kevaundray Wedderburn: But I'm not sure we should do the two first steps together, as people have, noted.

648
01:09:47.600 --> 01:09:59.880
Kevaundray Wedderburn: to the PQ roadmap, we have been sort of speaking with a bunch of people in the ecosystem to figure out, like, what are the right steps in order to get PQ into the fork.

649
01:10:00.330 --> 01:10:02.899
Kevaundray Wedderburn: There is a plan out there that gets it in…

650
01:10:03.000 --> 01:10:07.969
Kevaundray Wedderburn: Roughly around JSTAR, that we've been trying to circulate and get feedback on.

651
01:10:08.260 --> 01:10:09.060
Kevaundray Wedderburn: Mmm…

652
01:10:10.470 --> 01:10:25.749
Kevaundray Wedderburn: But it seems like Kind still DFI'd Hashtrain RANDAO. I would probably quickly say that even though that EIP is DFI'd, it would make sense to, maybe reserve some space, like, somewhat virtually in this fork to work on

653
01:10:25.750 --> 01:10:33.659
Kevaundray Wedderburn: some of the plans that we have for PQ to ensure they're ready, at least for I-Star, because there's a lot to do at the moment.

654
01:10:36.960 --> 01:10:38.170
stokes: Alright, noted.

655
01:10:40.230 --> 01:10:41.000
stokes: Cool.

656
01:10:41.200 --> 01:10:47.700
stokes: Okay, so… CFI8015, just this first EIP here.

657
01:10:48.190 --> 01:10:55.780
stokes: We expect a CFI be updated 8365, but again, we'll touch on that on the next call.

658
01:10:57.040 --> 01:11:05.319
stokes: And then, yeah, then my proposal in terms of moving forward today, because, yeah, we only have about, maybe, what.

659
01:11:05.490 --> 01:11:07.130
stokes: It's called 20 minutes left.

660
01:11:07.770 --> 01:11:14.259
stokes: There are a bunch of EIPs here where it was pretty clear that, there was not client support.

661
01:11:14.750 --> 01:11:17.799
stokes: And the way I'd read this is basically everything

662
01:11:18.040 --> 01:11:23.529
stokes: With the red box here, so, like, you know.4 or less of a average score.

663
01:11:23.990 --> 01:11:25.490
stokes: Growing by forecast.

664
01:11:26.290 --> 01:11:37.129
stokes: I would suggest we pull out issuance for today, because again, I think this is kind of a different discussion, just given its nature. It has, like, very wide-reaching community impact.

665
01:11:37.450 --> 01:11:42.310
stokes: And, yeah, I'm just not sure, we're in a place to tackle that one today.

666
01:11:42.930 --> 01:11:49.190
stokes: So putting that aside, the rest of these, it looks pretty clear that we can just go ahead and DFI them all.

667
01:11:50.300 --> 01:11:52.230
stokes: Would anyone like to…

668
01:11:52.370 --> 01:11:57.409
stokes: Yeah, either support this, or, yeah, is there something we should talk about before doing that?

669
01:11:57.910 --> 01:12:00.289
stokes: Otherwise, that would be deifying…

670
01:12:00.810 --> 01:12:10.570
stokes: everything here on forecast, which is 8237 and below, except, again, we're gonna put this issuance, EIP to the side.

671
01:12:12.390 --> 01:12:13.370
stokes: Sorry I spoke.

672
01:12:15.440 --> 01:12:26.100
soispoke: Yeah, I think… So I don't really care about SFI the box profiles one, because it's an informational EIP.

673
01:12:26.530 --> 01:12:28.979
soispoke: As long as it's clear that it's, like…

674
01:12:29.490 --> 01:12:40.989
soispoke: Also, basically, it's meant to be a bit of a spec to align on what we… how we want to handle, sort of, like, interactions between FOCIL and frames.

675
01:12:41.410 --> 01:12:44.769
soispoke: So now that both are SFI'd, it fills,

676
01:12:45.240 --> 01:12:51.309
soispoke: you know, we don't need to SFI this information EIP, it doesn't, like,

677
01:12:51.670 --> 01:12:54.449
soispoke: Change anything, really, except that…

678
01:12:54.650 --> 01:13:09.290
soispoke: it is, like, a good sort of, like, dock and starting point to sort of, like, try to agree on exactly how we… we handle frames and fossils. So, I'm not exactly sure how to go about it, I don't think it's, like, extremely…

679
01:13:09.490 --> 01:13:14.360
soispoke: clear what needs to be done, but at least, like, it would be nice if people agreed that we need to sort of, like.

680
01:13:14.600 --> 01:13:21.250
soispoke: You know, change fossil, and change frames so that they can work together.

681
01:13:24.580 --> 01:13:28.329
stokes: Okay. I mean, also, given it's informational, I'm not even sure…

682
01:13:29.220 --> 01:13:31.789
soispoke: Yeah, exactly, that'd be like so. Yeah.

683
01:13:33.150 --> 01:13:43.860
marc | wolovim: Just a quick logistics note there, too. Because it's informational, it was left off of the rank page, so clients were not explicitly asked to rank that. Lighthouse just…

684
01:13:43.970 --> 01:13:46.000
marc | wolovim: Gave an opinion on it, anyway.

685
01:13:50.530 --> 01:13:51.580
stokes: Okay, thanks.

686
01:13:53.360 --> 01:13:56.000
stokes: Okay, so it sounds like…

687
01:13:56.140 --> 01:13:57.740
stokes: Oh, it was… do you have something to add?

688
01:13:58.150 --> 01:13:58.900
stokes: Okay.

689
01:13:59.000 --> 01:14:02.070
stokes: Sounds like then we're good to…

690
01:14:02.340 --> 01:14:06.919
stokes: Take no action on 8369, so we're good there.

691
01:14:07.390 --> 01:14:16.370
stokes: Sorry, it's a lot of numbers. Okay, there was a comment in the chat for 8321 next.

692
01:14:16.800 --> 01:14:24.209
stokes: Yeah, Enrico, I don't know if you wanted to add anything yourself. Let's see, 83… okay, this was the Akash and RANDAO.

693
01:14:24.490 --> 01:14:27.290
stokes: It was also something that Kev mentioned, so…

694
01:14:27.620 --> 01:14:33.269
stokes: Yeah, again, just going by the client rankings, there doesn't seem to be great support.

695
01:14:34.720 --> 01:14:39.430
stokes: However, if there's a PQ argument, maybe there's something to be said there.

696
01:14:39.990 --> 01:14:48.840
stokes: I think just going by what process we do have, this would be a DFI today. But, yeah, anyone want to argue for something else?

697
01:14:58.140 --> 01:15:02.309
Kevaundray Wedderburn: Yeah, I think it's mostly what I just said a minute ago.

698
01:15:04.010 --> 01:15:04.740
Kevaundray Wedderburn: Yeah.

699
01:15:06.030 --> 01:15:07.530
stokes: So it's good for PQ.

700
01:15:07.820 --> 01:15:11.629
stokes: but also potentially something we can do in I-Star.

701
01:15:14.300 --> 01:15:20.740
Kevaundray Wedderburn: I would probably push for us to work on it in H-star.

702
01:15:21.370 --> 01:15:32.710
Kevaundray Wedderburn: Okay. So that it's ready for I-Star, along with a bunch of other things, like, having new deposit contracts, even though we haven't PFI'd it… PFI'd these things. We have EIPs for them.

703
01:15:33.010 --> 01:15:35.140
Kevaundray Wedderburn: It's just that we didn't get her in time.

704
01:15:36.230 --> 01:15:52.669
Kevaundray Wedderburn: The most important thing I'd just like to clarify is having, all of the Validator PQ material registered on the Beacon chain, because if we have, like, an emergency, PQ comes earlier than we want it to.

705
01:15:53.130 --> 01:15:58.990
Kevaundray Wedderburn: If we don't have PQ material registered for each validator, there's, like, no recovery mechanism unless the…

706
01:15:59.450 --> 01:16:01.420
Kevaundray Wedderburn: And as we can do it pretty quickly.

707
01:16:07.280 --> 01:16:09.200
stokes: Okay, yeah, that makes sense.

708
01:16:09.710 --> 01:16:14.600
stokes: So then in that case, we'll go ahead and, DFI…

709
01:16:14.740 --> 01:16:21.160
stokes: A through 21 today, but yeah, just have the general understanding that there will be PQ work that we want to do

710
01:16:21.770 --> 01:16:27.860
stokes: Yeah, there's legwork I want to start doing well before I start, so just keep that in mind.

711
01:16:31.970 --> 01:16:36.570
stokes: Yeah, I'm trying to catch up on the chat here.

712
01:16:38.350 --> 01:16:43.490
stokes: Yeah, so I spoke, are you… everything clear on 8369?

713
01:16:45.150 --> 01:16:50.330
soispoke: I was just asking if there was a decision or not, and it seems like no.

714
01:16:50.330 --> 01:16:53.229
stokes: Well, yeah, I mean, I think because it's informational.

715
01:16:53.460 --> 01:16:58.480
stokes: I'm not sure it matters if we, like, CFI or DFI, right?

716
01:17:00.110 --> 01:17:12.440
soispoke: Yeah, I think it would be nice to at least agree that we need to converge on the specs for Solon frames. I think it's, like, implicit in the fact that we SFI'd both, but…

717
01:17:12.690 --> 01:17:18.090
soispoke: Like, there needs to be actual efforts into making sure we all agree

718
01:17:18.310 --> 01:17:21.839
soispoke: How to handle the… the interactions, and…

719
01:17:22.000 --> 01:17:32.690
soispoke: yeah, that was sort of, like, supposed to start from this informational EIP and then bring changes to both Forceall and, like, both 7, 8, 05, and 8.

720
01:17:32.750 --> 01:17:43.059
soispoke: one for one, and if, like, everyone agrees it's the case, it's good, like, we don't need much more, but it's, yeah, the dog served that purpose.

721
01:17:46.860 --> 01:17:50.110
stokes: Yeah, I mean, yeah, there's comments here ranging from…

722
01:17:50.580 --> 01:17:57.710
stokes: Yeah, acknowledged, and it's just something we'll have to figure this out as we get into implementation of FOCIL and Frames.

723
01:17:58.180 --> 01:18:06.180
stokes: Or that it's, more of an EL or concern, so… It seems like today…

724
01:18:06.980 --> 01:18:08.879
stokes: We don't need to do anything.

725
01:18:09.240 --> 01:18:14.590
stokes: And to be clear, it's not that we're DFI-ing it, it's just more there's just nothing to do.

726
01:18:15.020 --> 01:18:18.910
stokes: It's more just, yeah, everyone be aware that there's stuff to figure out here.

727
01:18:19.880 --> 01:18:26.350
stokes: I think in terms of, like, actionable next steps, I think there's breakouts both for frames and FOCIL, so…

728
01:18:26.490 --> 01:18:27.910
stokes: Yeah, either…

729
01:18:28.710 --> 01:18:35.649
stokes: we take the CIP to those calls, or… yeah, we combine them somehow, but yeah, I agree, there's stuff to do here.

730
01:18:36.040 --> 01:18:37.450
stokes: I think in terms of…

731
01:18:37.700 --> 01:18:43.049
stokes: making these scoping decisions today. This one's actually just kind of orthogonal to the others.

732
01:18:46.370 --> 01:18:47.929
stokes: So, everyone clear on that?

733
01:18:57.170 --> 01:19:02.519
stokes: So… okay, then we had DFI on…

734
01:19:02.950 --> 01:19:07.539
stokes: 8321, again, with these caveats about PQ and the work to do there.

735
01:19:08.480 --> 01:19:18.320
stokes: There's been some discussion of issuance here. Again, let's just table this for a second. Let's touch on the others, because I think they'll be pretty easy DFIs.

736
01:19:18.870 --> 01:19:30.759
stokes: I guess just to make it clear, suggestion would be to DFI 8237, 8341, 8367.

737
01:19:31.160 --> 01:19:33.040
stokes: We already have 8321.

738
01:19:33.370 --> 01:19:36.110
stokes: 8243-8146.

739
01:19:36.790 --> 01:19:38.210
stokes: 8375.

740
01:19:39.540 --> 01:19:41.210
stokes: Anyone have any issue with this?

741
01:19:46.940 --> 01:19:47.640
stokes: Alright.

742
01:19:48.650 --> 01:19:50.050
stokes: Got some thumbs up.

743
01:19:53.070 --> 01:19:55.809
stokes: Yes, 5 by DFI. It's a nice rhyme.

744
01:19:58.210 --> 01:20:03.820
stokes: Okay, so I think we're good there, and then, yeah, so circling back to issuance now.

745
01:20:05.010 --> 01:20:07.960
stokes: again, I think this one's a little special, just given…

746
01:20:08.150 --> 01:20:14.569
stokes: The fact that, you know, it's in part a core developer decision, it's also a much bigger decision with the rest of the community.

747
01:20:15.300 --> 01:20:18.270
stokes: I mean, you can see here, with,

748
01:20:18.890 --> 01:20:24.140
stokes: The client rankings, you know, there were 3 teams that were against, 3 that just didn't chime in.

749
01:20:24.400 --> 01:20:35.600
stokes: So yeah, and I think in part it's just because, yeah, it's hard to speak today to how we want to move forward on making this decision, just given the fact that it is much bigger than present company.

750
01:20:36.470 --> 01:20:46.969
stokes: So, given that, and the fact that, yeah, we just have maybe 10 minutes left on the call, I feel like this might deserve a larger discussion than that.

751
01:20:47.580 --> 01:20:53.479
stokes: So, again, I would suggest that, we just table this one for today, And then it would…

752
01:20:53.700 --> 01:20:57.949
stokes: You know, just kind of go into this other bucket here of stuff we'll need to discuss in the future.

753
01:21:03.720 --> 01:21:07.189
stokes: So, in that case, if we're all good with that.

754
01:21:08.070 --> 01:21:11.230
stokes: I think that would clear us up for the work we need to do today.

755
01:21:11.850 --> 01:21:20.359
stokes: And, yeah, either we end the call early, or if someone would like to talk about one of these other EIPs we haven't touched on, there are some time.

756
01:21:21.460 --> 01:21:24.289
stokes: So yeah, I'll give you a few minutes to think about that.

757
01:21:26.030 --> 01:21:30.820
stokes: I'm reading photos as common here. Can we try to get people that work on the… Okay.

758
01:21:33.240 --> 01:21:39.129
stokes: whoever we use can definitely try. I don't know, I mean, this is also part of the thing, it's like, I think this is just…

759
01:21:39.400 --> 01:21:45.290
stokes: This is a very big conversation that we need to have, but I don't think we're necessarily prepared today.

760
01:21:48.110 --> 01:21:51.240
stokes: Free to Clare… sorry, okay, I'm just gonna read the chat. You guys can…

761
01:21:51.550 --> 01:21:52.909
stokes: Take the mic if you want.

762
01:21:54.050 --> 01:21:57.830
stokes: Otherwise, I'll just kind of read it as I go. I think we should pre-declare…

763
01:21:59.160 --> 01:22:00.319
Ansgar Dietrichs: Yeah, I mean, if you read it.

764
01:22:00.320 --> 01:22:01.130
stokes: I mean, I…

765
01:22:01.130 --> 01:22:06.190
Ansgar Dietrichs: I just basically wanted to say, like, ideally not just saying, we leave it pending. I mean, it's fine for now, maybe, but then…

766
01:22:06.410 --> 01:22:12.970
stokes: No, I'm just saying for, like, one call. Like, I'm just saying not today. I don't… yeah, it shouldn't be forever pending, it's just, I think…

767
01:22:13.390 --> 01:22:15.659
stokes: Given all the constraints today, it's…

768
01:22:15.660 --> 01:22:20.420
Ansgar Dietrichs: But then, can we make a decision? Will we discuss this in two weeks? Yes or no? I think it would be good… I mean, we don't necessarily.

769
01:22:20.420 --> 01:22:21.059
stokes: Yeah, no.

770
01:22:21.060 --> 01:22:25.329
Ansgar Dietrichs: decision life on the call, but, like, I think it would be really good if people have that expectation, like…

771
01:22:25.610 --> 01:22:28.340
stokes: Yeah, and also, just so people know and can prepare.

772
01:22:29.050 --> 01:22:32.029
stokes: I think that would be good, personally.

773
01:22:32.140 --> 01:22:32.760
stokes: But I'm…

774
01:22:32.760 --> 01:22:33.320
Matthew Keil: Two weeks ago.

775
01:22:33.320 --> 01:22:34.000
stokes: It's gonna be big.

776
01:22:34.000 --> 01:22:42.040
Matthew Keil: though. Like, when we're going through all the other stuff, it's gonna be a busy call. We've got 10 more minutes. It's already kinda deified.

777
01:22:42.250 --> 01:22:45.740
Matthew Keil: Maybe we spend the last 10 minutes and just get that one out of the way.

778
01:22:48.820 --> 01:22:52.060
stokes: You're saying issuance is kind of DFI'd? Is that what you're talking about?

779
01:22:52.770 --> 01:22:54.230
Matthew Keil: Yeah, and it's kind of… and, like.

780
01:22:54.650 --> 01:23:01.440
Matthew Keil: gonna be a lot of talk around the, like, I think short slots and some of the others are gonna be longer discussions for two weeks from now.

781
01:23:02.130 --> 01:23:02.550
stokes: Yeah.

782
01:23:02.550 --> 01:23:03.200
Matthew Keil: Oh, but…

783
01:23:03.200 --> 01:23:10.900
stokes: would push back a bit, it just… I just think we don't have the right mechanisms to make it… like, to say anything on it today.

784
01:23:12.860 --> 01:23:20.420
stokes: So I'm, yeah, not trying to shut it down, also not trying to make a decision necessarily, but more just saying.

785
01:23:21.150 --> 01:23:23.880
stokes: we're not set up today to do this. Potus?

786
01:23:25.140 --> 01:23:44.560
potuz: My personal feeling on that EIP is that it's… it's an unfair situation in which the community members that are affected by this EIP are all overwhelmingly against, because, well, they're just gonna earn less. And we haven't heard at the other side, we just only have the opinion of researchers.

787
01:23:44.820 --> 01:23:49.129
potuz: making a point about LSTs, and we are…

788
01:23:49.160 --> 01:24:03.079
potuz: by and large, not capable of making this decision. So it seems to me, if we keep just, like, postponing this, we are eventually going to either DFI it or make a choice without really understanding it. Ourselves, we're not…

789
01:24:03.080 --> 01:24:19.150
potuz: This is not our topic. So that's why I really strongly propose the authors, or whomever is pushing for this EIP, to try to get people that are outside of our community, but that work on international money policy, that work on these classical topics that might

790
01:24:19.310 --> 01:24:25.199
potuz: Might have an opinion Yeah, that is not directly biased.

791
01:24:28.600 --> 01:24:32.470
stokes: Yeah, or just, yeah, I mean, putting aside bias, just more having…

792
01:24:32.750 --> 01:24:34.820
stokes: Contacts that we might not have here today.

793
01:24:36.010 --> 01:24:45.650
stokes: And, you know, just to drive my point again, I think these arguments all point to the fact that we are not going to make a call on this today. I…

794
01:24:46.090 --> 01:24:50.280
stokes: do, like, Ansgar's point of, yeah, not just leaving this in limbo?

795
01:24:52.750 --> 01:25:04.029
stokes: So, I think it would make sense to say next call, but that being said, I also think there's room here with what is saying, to have, yeah, maybe more expert advice.

796
01:25:04.220 --> 01:25:07.729
stokes: On the topic, in which case that might take more than one call, so…

797
01:25:08.040 --> 01:25:12.020
stokes: Point being is, yeah, if anything, like…

798
01:25:12.170 --> 01:25:15.569
stokes: We might want to work with the champions, just to figure out the best path here.

799
01:25:16.300 --> 01:25:17.769
stokes: Enrico, then Ansar.

800
01:25:18.840 --> 01:25:25.779
Enrico Del Fante: I just want to echo Bos and add a comment on your comments, which is, today we are not

801
01:25:26.120 --> 01:25:33.230
Enrico Del Fante: In the right place to discuss that, but it will be… it won't be anywhere, anyway, into…

802
01:25:33.520 --> 01:25:34.879
Enrico Del Fante: In two weeks.

803
01:25:35.280 --> 01:25:43.869
Enrico Del Fante: because I believe, like Paul said, he thinks it's a little bit outside our… our knowledge, and it's a broader and bigger…

804
01:25:44.140 --> 01:25:51.190
Enrico Del Fante: Topic that needs to be discussed in proper… in proper dedicated calls.

805
01:25:51.930 --> 01:26:03.479
Enrico Del Fante: like, we can be… we can be there as ACDC guys, but other people must be there too, and discussion are not technically driven, mostly.

806
01:26:04.000 --> 01:26:04.590
stokes: Yeah.

807
01:26:04.890 --> 01:26:05.650
stokes: Right.

808
01:26:06.760 --> 01:26:11.159
stokes: I mean, yeah, what I could try to say today is I would ask to…

809
01:26:11.680 --> 01:26:16.930
stokes: give me until the next call, just to come up with a plan on how I'd propose we move forward here.

810
01:26:17.770 --> 01:26:25.789
stokes: Because also, yeah, like, I might be surprised, but I feel like this might take a little more legwork, than just 2 weeks.

811
01:26:31.740 --> 01:26:35.210
stokes: Ansgar, you had your hand, but I don't know if you had anything to add. You took it down?

812
01:26:35.960 --> 01:26:38.999
Ansgar Dietrichs: Yeah, I was going to say very similar things to Enrico.

813
01:26:40.030 --> 01:26:40.610
stokes: Okay.

814
01:26:42.110 --> 01:26:43.440
stokes: Yes, true.

815
01:26:44.260 --> 01:26:49.609
Jerome de Tychey: Yeah, I appreciate the different comments here, regarding issuance.

816
01:26:49.690 --> 01:26:53.619
Jerome de Tychey: As was, suggested by several other organizations, we need to,

817
01:26:53.620 --> 01:27:17.140
Jerome de Tychey: come up with a way to get everybody on consensus on what should happen, and if anything should happen. Regarding the push forward on making a decision on the EIP potentially later, it's giving us time, the offers, to come up with a proper write-up on all the comments that were done,

818
01:27:17.140 --> 01:27:22.630
Jerome de Tychey: Regarding the, the, on the, ethereum thread, and also, to,

819
01:27:22.790 --> 01:27:42.329
Jerome de Tychey: convene to what should be the next steps, with the different parties that have voiced their opinion and have voiced wanting to participate on something broader. And as you mentioned, to, get, people that are not in the room, or didn't express their opinion, to actually, voice, what they think about this kind of change.

820
01:27:42.450 --> 01:28:02.009
Jerome de Tychey: So, yeah, in a, in a process where, you want to, shrink the list as much as possible, as, as quickly as possible, issuance is, kind of, a people in the, in the shoe, but, we're working very hard to, make it, easy to remove and, toss around.

821
01:28:04.260 --> 01:28:06.760
stokes: Okay, yep, sounds good, and yeah,

822
01:28:07.270 --> 01:28:09.610
stokes: Let me know if I can help with any work there.

823
01:28:11.680 --> 01:28:25.229
Jerome de Tychey: Yeah, and additionally, we appreciate the, EF protocol teams, mentioning it, to say that, yeah, this needs a bigger forum, and it needs to, something broader, to reach, broader consensus. So, yeah, we're working hard on the matter.

824
01:28:26.900 --> 01:28:28.330
stokes: Alright, thanks.

825
01:28:30.220 --> 01:28:38.940
stokes: Okay, then in that case, let me just play back what decisions we made today. Oh yeah, Greg, I assume you have a comment here.

826
01:28:39.770 --> 01:28:52.689
Greg K | Lido: Yeah, sorry, just… I didn't intend to talk today, but just in order to understand what are we expecting now to happen? So, we have currently 3 clients suggesting to DFI, and 3 clients not expressing opinion.

827
01:28:52.810 --> 01:29:01.440
Greg K | Lido: So, just in terms of process, like, How could, finally, let's say.

828
01:29:01.670 --> 01:29:09.659
Greg K | Lido: take a decision about this particular EIP, because this is exactly the reason that they had asked to not PFI this particular EIP, because

829
01:29:09.850 --> 01:29:27.230
Greg K | Lido: it's… it makes Ethereum's change and this EIP looking equivalent, while this is not. So, one thing is discussion about changing issuance, which cannot be done in ACD, of course, and the… and this EIP, this particular EIP, is just one very, very special case of it.

830
01:29:27.490 --> 01:29:41.450
Greg K | Lido: So, I don't see what should we expect to happen in the next two weeks, and how could the final decision will be taken? Are we going to say client team opinion is not important at all, and we will create another process for this?

831
01:29:41.450 --> 01:29:49.100
Greg K | Lido: Or, like, I just don't see… I'm okay with not designing today, I don't say, let's do something today, but I have no clue

832
01:29:49.140 --> 01:30:02.359
Greg K | Lido: what is the expectation here to happen? Like, what… from the way that people are talking now, I expect that in two weeks, we are going to have rough, more or less the similar discussion. Like, we're not qualified, we don't know, like.

833
01:30:02.730 --> 01:30:06.389
Greg K | Lido: So, is there some idea on how to move forward, or we'll just keep it?

834
01:30:07.400 --> 01:30:17.860
stokes: Yeah, I mean, again, this is probably a conversation we need to have. My view is what we should probably do in, you know, say, the next couple calls.

835
01:30:18.590 --> 01:30:29.920
stokes: is figure out how we want to handle this type of thing as core developers, right? And I think, again, reflecting the comments we've had, like, this isn't just a core dev decision, right? And so…

836
01:30:30.420 --> 01:30:40.329
stokes: you know, like, one outcome could be, hey, we actually think we need this other forum. I don't know, people said something about ACDI, which I assume is ACD issuance, so…

837
01:30:40.570 --> 01:30:41.890
stokes: You know, maybe…

838
01:30:42.040 --> 01:31:00.290
stokes: this isn't necessarily, like, just an ACDC call to make, and maybe it's, like, in the, you know, allCoreDevs, pun intended, call to make, or… okay, moms are saying no ACDI. But anyways, like, that's just kind of, you know, straw man for what this could look like.

839
01:31:00.500 --> 01:31:07.709
stokes: And I think that's something we could do in the next couple weeks on this call, is just figure out how we want to move forward here.

840
01:31:08.030 --> 01:31:10.409
stokes: In terms of how we make a decision.

841
01:31:11.160 --> 01:31:16.950
stokes: And yeah, I understand if it's frustrating that… It's not super clear today.

842
01:31:17.900 --> 01:31:21.559
stokes: But I don't have much more to… to give you.

843
01:31:22.160 --> 01:31:23.880
stokes: Ansgar and Kev?

844
01:31:24.770 --> 01:31:27.990
Ansgar Dietrichs: Yeah, so, one more comment. I just, I do think…

845
01:31:28.050 --> 01:31:35.380
Ansgar Dietrichs: One thing that I do feel a bit bad about is that, like, I think many people are specific on this topic, following the ACD process, because

846
01:31:35.420 --> 01:31:43.979
Ansgar Dietrichs: by default, ACD is where decisions about hardfogs are made, and they… I think a lot of… a big portion of the community is worried about this change.

847
01:31:43.980 --> 01:32:06.739
Ansgar Dietrichs: again, I personally even speak as someone who actually thinks this might be a good idea, but again, I understand, like, many, many people are really worried about this, and I think they might see us not making a decision as somehow, like, maybe get the feeling, or maybe there's some sort of conspiracy that is trying to basically delay and then last minute push this in. I just would want to reiterate that this is very much not what's happening here. I think it's more that we're seeing that with this EIP,

848
01:32:06.770 --> 01:32:24.810
Ansgar Dietrichs: I think as was obvious for everyone who paid attention, the fact that we just didn't really know how would even a decision-making process here look like, I think, caused a lot of extra friction. Like, when this was initially proposed, there was a lot of discussion about PFI timelines, and why would CR Devs even be the right group, and who else are stakeholders here, and I think

849
01:32:24.810 --> 01:32:35.910
Ansgar Dietrichs: all of these are just really, really important questions, and so I think the reason why I think we would want to have some proper time to figure out how to even think about approaches to this is less

850
01:32:35.910 --> 01:32:49.520
Ansgar Dietrichs: because it's still so up in the air what the fate of this specific proposal specifically for Hegota will be, I think it's actually quite clear, that we are very far away from any scenario in which this would go into Hegota.

851
01:32:49.890 --> 01:32:55.300
Ansgar Dietrichs: it's really more that I think we just need to figure out, on a topic like this, what…

852
01:32:55.340 --> 01:32:57.710
Ansgar Dietrichs: What… how do we think about the general…

853
01:32:57.710 --> 01:33:21.519
Ansgar Dietrichs: governance, legitimacy, decision making, so that in the future, this will… either this, or topics like these will occasionally come up, and so I do think it really takes… like, I think just saying DFI now, and then just, like, moving on, then we will have the exact same problem again next time something like this comes up. So I really believe it's worth the time, but I just want to really stress that for anyone listening with a little bit less context on ACD, this does… this is very much not a…

854
01:33:21.710 --> 01:33:27.249
Ansgar Dietrichs: let's try to delay and then squeeze this in as some sort of conspiracy thing. Like, just really wanted to reiterate that.

855
01:33:28.690 --> 01:33:30.050
stokes: Yeah, thank you. Bye.

856
01:33:30.550 --> 01:33:37.620
stokes: Hope no one reads it that way, because, yeah, that's not what we're doing. It's more just, given this type of decision, the space it needs.

857
01:33:38.070 --> 01:33:48.340
stokes: So there are a lot of hands. We're also at time. I guess, yeah, if people want to hop, they can. Otherwise, let's try to get to these hands, and then we'll wrap up. So… now we have Kev.

858
01:33:48.930 --> 01:33:50.740
stokes: Matt, and then my client.

859
01:33:52.440 --> 01:34:10.210
Kevaundray Wedderburn: I had a different topic on 8333. I don't know if Matt was gonna talk about that. I was basically just trying to get 3 more DFIs before the end of the call. Matt, if you was going to talk about that, I can just quickly say it seems like it makes sense to also DFI that.

860
01:34:10.680 --> 01:34:13.479
Kevaundray Wedderburn: If clients are still on the call…

861
01:34:14.890 --> 01:34:30.889
Matthew Keil: I did just want to ask out loud to Ben, that there was telegraphing that 833 would no longer, be relevant when we get to a decoupled Consensus world, and if that's the case, yeah, we would… we would recommend DFI also.

862
01:34:32.020 --> 01:34:39.880
Ben Edgington: Yeah, I agree, but I think we shouldn't make the decision now. We're over time, and next two weeks' time is fine, I think.

863
01:34:42.630 --> 01:34:43.770
stokes: Yeah, I agree.

864
01:34:44.690 --> 01:34:46.030
stokes: White client.

865
01:34:50.530 --> 01:34:52.509
lightclient: Yeah, I just wanted to ask…

866
01:34:52.900 --> 01:34:55.170
lightclient: kind of related to Ansgar's point, if…

867
01:34:55.280 --> 01:35:01.310
lightclient: There's, quote, not really much chance that this issuance change makes it to go to

868
01:35:01.810 --> 01:35:10.029
lightclient: why would we not be DFI-ing it right now? And in the meantime, figure out what the right process in the future for

869
01:35:10.360 --> 01:35:16.459
lightclient: accepting and issuance changes, because I'm afraid that if we don't DFI it and we have this discussion.

870
01:35:16.620 --> 01:35:19.480
lightclient: That in the process, will also start legitimizing

871
01:35:19.790 --> 01:35:25.479
lightclient: And people will start accepting that this issuance change is happening, when I don't think that that's what the current

872
01:35:25.900 --> 01:35:29.390
lightclient: You know, belief of the core Devs or the community is.

873
01:35:29.760 --> 01:35:33.849
lightclient: So I think that those need to be very separate, and I think that we shouldn't…

874
01:35:33.980 --> 01:35:42.659
lightclient: Leave it op… the door open while we figure out what the right process to accept it is, to avoid, like, overfitting and figuring out a process that will accept that specific change.

875
01:35:45.270 --> 01:35:48.600
stokes: I think the simple answer today is just that we've run out of time.

876
01:35:48.850 --> 01:35:54.139
stokes: And, yeah, like… That could very well be the outcome. Next call.

877
01:35:58.480 --> 01:35:59.320
stokes: Artists.

878
01:35:59.530 --> 01:36:05.120
potuz: I wanted to answer to Matt, and I am with you, Matt, that, core Devs after

879
01:36:05.180 --> 01:36:25.060
potuz: after all, they are going to read the room, and that they're going to try to do the best for the protocol, but in this particular EIP, you have over 90%… the clients that hold over 90% of the stake on mainnet didn't want to admit an opinion, and I think that in itself is an opinion that we are not capable of deciding this now.

880
01:36:25.270 --> 01:36:36.960
potuz: And even though it's likely that this is going to be DFI, it might be DFI in the next call, we could even DFI it now, we really need to have this discussion. This discussion needs to happen outside of Twitter, and we should…

881
01:36:37.060 --> 01:36:45.939
potuz: Even though we might end up doing… making the decision, we really need to have the tools to make such a decision. And we really want this to happen. We don't want to

882
01:36:46.060 --> 01:36:51.609
potuz: every single fork that this comes up, saying, well, we're gonna just DFI it because we're not capable of doing this.

883
01:36:52.010 --> 01:37:02.880
potuz: This discussion needs to happen, and… well, we need to bring in the community members that are not on Twitter, yelling, but actually that come up with technical facts, or…

884
01:37:03.160 --> 01:37:04.470
potuz: Actual arguments.

885
01:37:10.240 --> 01:37:10.830
stokes: Yeah.

886
01:37:10.980 --> 01:37:12.879
stokes: I agree. Otis.

887
01:37:13.340 --> 01:37:18.539
stokes: Yes. We're over time. Thank you, everyone.

888
01:37:19.340 --> 01:37:27.389
stokes: Let's see, I will make sure somewhere the decisions made today are recorded. We DFI'd a good number of EIPs.

889
01:37:27.660 --> 01:37:32.539
stokes: And made CFI progress on two of the others. So yeah, good work, everyone.

890
01:37:32.810 --> 01:37:35.430
stokes: And we'll pick this up next call.

891
01:37:35.860 --> 01:37:44.730
stokes: And also, just, yeah, final reminder, Glamsterdam, releases for Sepolia. Let's keep this moving, too.

892
01:37:45.990 --> 01:37:48.869
stokes: Okay, thanks everyone. I'll see you next time.

893
01:37:50.570 --> 01:37:51.710
Kevaundray Wedderburn: Alright, see ya.

894
01:37:52.040 --> 01:37:53.070
potuz: Bye-bye, everyone.

895
01:37:53.070 --> 01:37:54.299
Fredrik: Thank you. Bye-bye.

896
01:37:54.300 --> 01:37:55.260
Marius: Bye-bye.