WEBVTT

1
00:14:25.330 --> 00:14:26.840
stokes: Hello, everyone.

2
00:14:36.940 --> 00:14:42.299
stokes: Okay, I think the way it's set up is, we're already streaming, so…

3
00:14:43.530 --> 00:14:46.420
stokes: That being said, let's give people…

4
00:14:46.540 --> 00:14:49.649
stokes: another minute or 2 to join, and then we'll get started.

5
00:16:32.930 --> 00:16:41.989
stokes: Okay, we're a little over 50 people here, and yeah, seems like a good place to get started. So, hello everyone.

6
00:16:42.730 --> 00:16:51.420
stokes: Welcome to ACDC number 189. This is issue 2247 in the PM repo.

7
00:16:52.590 --> 00:16:56.430
stokes: I dropped a link here in the chat to the agenda.

8
00:16:56.980 --> 00:17:05.110
stokes: So today should be another fun call. We'll touch on Glamsterdam. We just have the Sepolia fork and Hoodi coming up.

9
00:17:05.589 --> 00:17:07.919
stokes: A few other things there.

10
00:17:08.290 --> 00:17:16.420
stokes: and then we'll continue with Hegota again. A couple of things have come up, including, of course, scoping the fork. So

11
00:17:16.800 --> 00:17:18.269
stokes: Let's go ahead and jump in.

12
00:17:18.710 --> 00:17:20.399
stokes: First up, Glamsterdam.

13
00:17:20.609 --> 00:17:30.540
stokes: And, yeah, we had the Sepolia fork, seems like it generally went pretty well. Anything anyone would like to add or point out about the fork?

14
00:17:42.200 --> 00:17:48.659
stokes: Yeah. Time for Hoodi, says Barnabas in the chat. Generally, yeah, the fork went, I think, actually really well.

15
00:17:48.800 --> 00:17:52.279
stokes: And, yeah, that's a good sign. So, again, congrats, everyone.

16
00:17:52.830 --> 00:18:06.820
stokes: It was yeah. As always, it's a big lift to fork any network. So, yeah, it was a big thing. We did this for Sepolia, and it lined us up for, yeah, the the next networks coming up.

17
00:18:07.960 --> 00:18:10.709
stokes: Which brings us to Hoodi.

18
00:18:11.250 --> 00:18:18.019
stokes: So Hoodi has been scheduled for October 26th, UTC time.

19
00:18:18.540 --> 00:18:21.879
stokes: And, yeah, I think everyone's aware of this at this point.

20
00:18:22.240 --> 00:18:35.749
stokes: One thing I can ask for is client releases. I think only so far I've seen Lodestar and ethrex. I'm trying to keep an eye out. But yeah, one thing we'll do is put out a blog post from the EF.

21
00:18:36.150 --> 00:18:39.369
stokes: Like we did for Sepolia, we'll do this for Hoodi.

22
00:18:39.760 --> 00:18:43.600
stokes: And, yeah, that's pretty much ready to go.

23
00:18:43.940 --> 00:18:48.629
stokes: except for client releases. So, I believe we set a deadline of tomorrow.

24
00:18:48.990 --> 00:18:55.580
stokes: So still a little time, but yeah, would anyone like to… Call out earliest they've made.

25
00:19:00.640 --> 00:19:03.349
stokes: Otherwise, yeah, I'll just keep an eye out for that.

26
00:19:03.750 --> 00:19:09.049
stokes: Barnabas here in the chat says one small note, okay, devnet 12.

27
00:19:09.940 --> 00:19:17.899
stokes: And… Okay, yeah, just testing builder deposits there with invalid deposits. Okay, thanks, Barnabas.

28
00:19:19.500 --> 00:19:25.940
stokes: Let's see. Teku here says release tomorrow. Lighthouse says early next week. Okay.

29
00:19:26.740 --> 00:19:36.960
stokes: Yeah, as soon as we get quorum of clients, for the blog post, we'll go ahead and publish it, and then, yeah, you know, we can always update it if someone's a day or two behind.

30
00:19:37.810 --> 00:19:46.940
stokes: But that being said, yeah, let's get them out as quickly as we can because, again, Hoodi's a pretty distributed testnet. So

31
00:19:47.260 --> 00:19:51.499
stokes: We will need, yeah, people will need time to update.

32
00:19:54.250 --> 00:19:55.180
stokes: Okay.

33
00:19:55.920 --> 00:20:02.839
stokes: Otherwise, then, yeah, Hoodi is on rails moving forward. Anything else on Hoodi that we should touch on?

34
00:20:06.380 --> 00:20:11.870
Barnabas: We should actually test the builders being available at the fork transition.

35
00:20:12.120 --> 00:20:16.359
Barnabas: So I think we're going to need to make some deposits, before the fork?

36
00:20:16.540 --> 00:20:19.530
Barnabas: Probably some top-up transactions, and

37
00:20:20.070 --> 00:20:26.620
Barnabas: Then it would be nice to have the builders, end up And hopefully propose a…

38
00:20:26.810 --> 00:20:29.430
Barnabas: First or the second slot, probably.

39
00:20:31.160 --> 00:20:31.820
stokes: Okay.

40
00:20:32.210 --> 00:20:35.350
stokes: It's a nice segue to the next topic.

41
00:20:35.500 --> 00:20:41.489
stokes: But before we get there, let me just actually make a note about that. Give me one second.

42
00:20:49.580 --> 00:20:50.420
stokes: Okay.

43
00:20:51.480 --> 00:20:55.439
stokes: Yeah, good call, Barnabas. Thank you for pointing that out.

44
00:20:57.170 --> 00:21:04.170
stokes: Okay, then, yeah, so… that'll be nice, yeah, just to kind of run through all the paces with…

45
00:21:04.450 --> 00:21:06.259
stokes: Possibilities of Glamsterdam.

46
00:21:07.470 --> 00:21:19.989
stokes: And, like I said, that is a nice segue into the next, topic here. So… I believe this is Dmitrii. He brought up this issue from the consensus-specs that he wanted to discuss.

47
00:21:20.580 --> 00:21:25.100
stokes: Yeah, this seems relevant to… builder deposits here.

48
00:21:25.960 --> 00:21:27.170
stokes: is…

49
00:21:27.840 --> 00:21:44.020
Dima Gusakov | Lido: I'm here, yeah, yeah, and happy to start. Yeah, so the issue is pretty simple, and it has already been pre… preliminary, let's call it this way, discussed, in Ethereum R&D Discord.

50
00:21:44.130 --> 00:21:57.640
Dima Gusakov | Lido: However, I still want to have a broader discussion here and get to some sort of a consensus about this issue. So, the core of the issue is the following. We have a

51
00:21:58.070 --> 00:22:17.189
Dima Gusakov | Lido: pretty vulnerable, valid… initial validator deposit process that we're gonna talk about in a second when, scoping EIPs. But you all know that, the rule for the validator data to be set is that the first deposit wins. So, whatever deposit is the first in the

52
00:22:18.860 --> 00:22:28.529
Dima Gusakov | Lido: in the queue of the pending deposits, sets the validator data, namely withdrawal credentials and stuff like that, once and for all. It cannot be changed later, and any further deposits

53
00:22:28.530 --> 00:22:39.230
Dima Gusakov | Lido: Within this deposit, everything but the validator public key and the deposit amount is ignored, so all of the other deposits are considered so-called top-ups.

54
00:22:39.500 --> 00:22:50.530
Dima Gusakov | Lido: And for some reason, well, maybe it was even sensible at the moment, the decision was made that this specific one-time builder onboarding

55
00:22:50.560 --> 00:23:00.000
Dima Gusakov | Lido: would work in a similar way, though the outcome here is a little bit different. By similar way, I mean that if you have

56
00:23:00.090 --> 00:23:07.270
Dima Gusakov | Lido: a single deposit in the deposit queue at the time of Glamsterdam Hard Fork.

57
00:23:07.440 --> 00:23:26.790
Dima Gusakov | Lido: with withdrawal credentials with the prefix of 0xB0, which probably stands for builder, then any other deposits that are also in the deposit queue at the time of the hard fork will be considered top-ups, but top-ups not for the validator, but for the builder.

58
00:23:27.000 --> 00:23:36.909
Dima Gusakov | Lido: And the core of this issue is that it changes the way how this race, works. Because previously.

59
00:23:36.970 --> 00:23:53.009
Dima Gusakov | Lido: there were two possible outcomes. So, if you have a deposit within deposit, within pending deposits, you can be 100% certain that, your deposit will end up being Validator.

60
00:23:53.840 --> 00:23:55.880
Dima Gusakov | Lido: But,

61
00:23:56.020 --> 00:24:19.449
Dima Gusakov | Lido: yeah, end up being validator. And the only thing that might be different is the withdrawal credentials. So if you lose the race to an attacker, then you get a validator with invalid withdrawal credentials. And upon this assumption, protocols like Lido, and I believe many other protocols, have built their own protection systems, so that if you… if you can prove that

62
00:24:19.450 --> 00:24:36.370
Dima Gusakov | Lido: after making deposit, this initial, say, 1 ETH pre-deposit, your validator appears on the consensus layer with correct withdrawal credentials, then you're good to go, and deposits can continue. If your validator appears with wrong withdrawal credentials, but with the same public key.

63
00:24:36.370 --> 00:24:43.950
Dima Gusakov | Lido: Then, the other option for you is to prove that the deposit was invalid and discard it.

64
00:24:44.200 --> 00:24:53.160
Dima Gusakov | Lido: The problem with this builder onboarding process is that as the result of this builder onboarding process, if you have any deposits which were

65
00:24:53.160 --> 00:25:10.279
Dima Gusakov | Lido: made with validator prefix, not the builder prefix, but they stand in the deposit queue after the deposit that is made for the builder, the final outcome will be that no validator would appear at all.

66
00:25:10.580 --> 00:25:21.179
Dima Gusakov | Lido: Which means that, current protection systems on the application layer, for this very thin, like, the single moment of a Glamsterdam hard fork.

67
00:25:21.180 --> 00:25:37.589
Dima Gusakov | Lido: might find themselves in the situation where they made a deposit, expecting one of the outcomes, like, expecting a definite outcome that the validator would appear with either correct or wrong withdrawal credentials. They now have the third outcome that they were not prepared for.

68
00:25:37.710 --> 00:25:51.359
Dima Gusakov | Lido: Which is, no validator has appeared at all. And instead, the builder has appeared, and now their deposit is stolen by Builder. So, what we think from the.

69
00:25:51.390 --> 00:26:00.229
Dima Gusakov | Lido: like, from the application layer perspective and fairness, to the application layer. Would it be fair to do is, instead of treating all of this

70
00:26:00.230 --> 00:26:21.740
Dima Gusakov | Lido: further deposits with a validator prefix within the withdrawal credentials, instead of crediting those deposits to the builder, credit them to the validator. Because as far as I remember, after Glamsterdam Hard Fork, you… what you can do is you can have the builder and the validator with the same public key, so no problem here at all.

71
00:26:21.740 --> 00:26:29.369
Dima Gusakov | Lido: And the only thing we are proposing to change here is to keep the outcome the same. So if you ever made a deposit.

72
00:26:29.370 --> 00:26:54.299
Dima Gusakov | Lido: With validator withdrawal credentials prefix, you should expect and you should get a validator at the end of the day and not end up in a situation where you end up with nothing at all. And I hear the comments that, okay, you can rebuild your proof system and expect this third outcome, but this sounds a little bit ridiculous to me from two points of view. The first one is

73
00:26:54.620 --> 00:27:14.369
Dima Gusakov | Lido: building anything on the application layer, auditing and stuff like that for just a one-time thing looks like a little bit of an overkill. And the second thing that the fix is actually very simple, and it would not affect builder experience at all, because if you want to top up your builder later on, you can still do it with a legit

74
00:27:14.370 --> 00:27:21.440
Dima Gusakov | Lido: deposit with the same prefix. So, why, why should we

75
00:27:21.440 --> 00:27:35.569
Dima Gusakov | Lido: mishmash or intermix both deposits to validators and builders at this very particular moment, given the fact that after that, you would still be able to have a builder and validator with the same public key.

76
00:27:35.570 --> 00:27:54.080
Dima Gusakov | Lido: So, our proposal here is to fix this small issue, and the fix is also linked to… the fix to the spec is also linked to the issue. It's a very small and pretty simple fix that would make life way easier for the majority of the application layer protocols who rely on this.

77
00:27:54.080 --> 00:27:55.320
Dima Gusakov | Lido: pre-deposit

78
00:27:55.760 --> 00:28:07.879
Dima Gusakov | Lido: mechanism for… to secure their deposits, and it wouldn't also be a major lift for core teams to make this small change. So, that is pretty much it.

79
00:28:11.550 --> 00:28:14.350
stokes: Okay, yeah, thanks for bringing this up.

80
00:28:14.840 --> 00:28:20.659
stokes: I believe we talked about a similar issue in the past, if not the same thing.

81
00:28:21.340 --> 00:28:22.410
stokes: But yeah.

82
00:28:22.970 --> 00:28:25.320
stokes: That all being said…

83
00:28:25.640 --> 00:28:33.909
stokes: I hear you. It is also pretty late in the process, I think, to be changing things, unless, you know, there is some…

84
00:28:34.180 --> 00:28:49.189
stokes: critical impact to the actual protocol security. And yeah, I'll just surface some of the comments here, essentially saying that, yeah, you know, there are workarounds at the application layer, and while that might be inconvenient, I think given

85
00:28:49.310 --> 00:28:51.039
stokes: Where are we at in this process?

86
00:28:52.030 --> 00:29:00.770
stokes: That seems to be, I think the answer for now. And, yeah, again, I don't know if any of the people in the chat that commented wanna chime in.

87
00:29:02.730 --> 00:29:04.370
stokes: Anyone else from the client team?

88
00:29:04.770 --> 00:29:05.560
stokes: Can I ask?

89
00:29:05.560 --> 00:29:16.689
Dima Gusakov | Lido: Like, anyone from the client teams to specifically say why you guys consider that, making a really simple fix that, again, would not impact

90
00:29:16.990 --> 00:29:20.139
Dima Gusakov | Lido: The experience at all.

91
00:29:20.370 --> 00:29:39.329
Dima Gusakov | Lido: right now being too late, while fixes on the application layer and workarounds on the application layer, and I want to specifically stress that there are a lot of applications compared to just one base layer, and the fix on the application layer is orders of magnitude more complicated, and then multiplied by the number of

92
00:29:39.390 --> 00:29:44.100
Dima Gusakov | Lido: protocols who should fix that. Why do you guys think that.

93
00:29:44.240 --> 00:29:48.880
Dima Gusakov | Lido: It's indeed reasonable to say, oh, hey, go and do, like.

94
00:29:49.050 --> 00:30:08.070
Dima Gusakov | Lido: 10 or more, I don't know, 20, how many fixes on the application layer, instead of making this really simple change. And maybe you can elaborate on why you believe that it's too late to change something, given that it's not a breaking change at all, it's just a change to a one-time use function.

95
00:30:08.650 --> 00:30:16.119
Dima Gusakov | Lido: maybe I'm dumb and I'm missing something, but I really want to hear to someone from, from the client Devs.

96
00:30:18.350 --> 00:30:19.140
stokes: Barnabas.

97
00:30:20.340 --> 00:30:25.049
Barnabas: I'm a kind of. But if this is a actual issue, it should have been raised like.

98
00:30:25.560 --> 00:30:26.959
Barnabas: Five, six months ago.

99
00:30:27.110 --> 00:30:30.190
Barnabas: And then we could have actually included this,

100
00:30:30.380 --> 00:30:36.139
Barnabas: much, much earlier, but we already shipped this fork into Sepolia. We are about to schedule

101
00:30:36.340 --> 00:30:39.690
Barnabas: Hoodi, well, we have scheduled Hoodi already, so…

102
00:30:39.990 --> 00:30:42.719
Barnabas: You're basically asking us to make a fix?

103
00:30:43.510 --> 00:30:49.110
Barnabas: in live production that is going to only apply on mainnet, which is just not going to happen.

104
00:30:50.870 --> 00:30:58.020
Dima Gusakov | Lido: But we still have time, I guess, to have it on Hoodi again. The fix itself is very simple, and it doesn't matter that much.

105
00:30:58.040 --> 00:31:14.679
Dima Gusakov | Lido: how, Sepolia was delivered, because again, this is a one-time function, this is not a change to consensus, and I… I'm not even sure that this particular case was actually tested during the real Sepolia hard fork. And even if it was.

106
00:31:14.680 --> 00:31:23.440
Dima Gusakov | Lido: It, again, it would not change much, it's just a matter of how, like, which requests you pick from the pending deposits.

107
00:31:32.490 --> 00:31:37.169
stokes: Yeah. I mean, so I can just summarize the comments here. Essentially yeah. So

108
00:31:38.250 --> 00:31:42.559
stokes: Again, I hear what you're saying, like, you… I don't think you're…

109
00:31:42.900 --> 00:31:49.049
stokes: Seeing something clearly, other than the fact that, yeah, given where we're at in the deployment process.

110
00:31:49.340 --> 00:31:59.579
stokes: You know, I think the, like, proper thing to do in this scenario would be to, you know, if we were to make the change, we'd make the change. We'd probably then want to, like, fork Sepolia again somehow.

111
00:32:00.130 --> 00:32:09.640
stokes: then Hoodi, then Mainnet, it pushes things back, and again, that's kind of what I meant earlier when I said, you know, if this was, like, some actual consensus issue.

112
00:32:09.810 --> 00:32:12.299
stokes: Of course, then we would fix it,

113
00:32:12.920 --> 00:32:17.020
stokes: But given that it doesn't impact the security of mainnet, the protocol.

114
00:32:17.360 --> 00:32:22.259
stokes: I think it's hard to justify, and this is why all the client teams are chiming in.

115
00:32:28.580 --> 00:32:32.979
Pavel | MixBytes: Also, let me add from the security perspective of

116
00:32:33.540 --> 00:32:48.580
Pavel | MixBytes: this issue, because we audited multiple approaches to solving this issue, like a pre-deposit guarantee contract. We reviewed multiple approaches from different protocols.

117
00:32:48.740 --> 00:32:50.080
Pavel | MixBytes: Who wants to…

118
00:32:50.200 --> 00:33:03.250
Pavel | MixBytes: solves that issue to work around it somehow. And everything looks too complicated and too logic loaded. And everyone has to

119
00:33:03.300 --> 00:33:14.850
Pavel | MixBytes: Like, monitor it, how it goes to audit multiple off-chain services, like, signature-based, when you check the deposit root.

120
00:33:15.210 --> 00:33:21.039
Pavel | MixBytes: And, you have to… Just, adapt to…

121
00:33:21.200 --> 00:33:27.499
Pavel | MixBytes: Like, any changes in ConsensusLayer, so… It looks like,

122
00:33:27.770 --> 00:33:31.569
Pavel | MixBytes: Workaround, which can be easier solved.

123
00:33:31.880 --> 00:33:33.170
Pavel | MixBytes: In my opinion.

124
00:33:39.810 --> 00:33:41.709
stokes: Any other client teams want to chime in?

125
00:33:49.540 --> 00:33:51.949
stokes: I mean, one path forward here is…

126
00:33:52.120 --> 00:33:59.350
stokes: I think this is maybe the first time people are aware of the scope and impact of the issue from the application side.

127
00:34:00.460 --> 00:34:10.850
stokes: So what we could do is, you know, give people today to look at this, think about it some more, have a breakout tomorrow, Friday, and make a call there.

128
00:34:11.600 --> 00:34:16.079
stokes: But, yeah, it is… it is late in the process.

129
00:34:17.900 --> 00:34:19.460
stokes: How does that sound to people?

130
00:34:25.170 --> 00:34:30.430
Matthew Keil: I tend to think that waiting or trying to make a decision later is

131
00:34:30.949 --> 00:34:49.040
Matthew Keil: not gonna change many minds. And while I do appreciate that there is complexities on somebody's plate, the truth is that, you know, we've already cut releases for Hoodi, and so have all the rest of the teams. And it feels like it would be…

132
00:34:49.810 --> 00:34:53.900
Matthew Keil: Just difficult in order to try to change course now.

133
00:35:03.030 --> 00:35:03.650
stokes: Okay.

134
00:35:04.330 --> 00:35:05.530
stokes: Barnabas.

135
00:35:05.920 --> 00:35:15.350
Barnabas: Just a quick question, whether this would be still a problem post-fork, or this is just… No, this is…

136
00:35:15.350 --> 00:35:23.820
Dima Gusakov | Lido: Yeah, this issue only occurs at a single block, which is the first block of the new hard fork.

137
00:35:24.310 --> 00:35:27.930
Dima Gusakov | Lido: Like, the moment this function is executed, it's executed once.

138
00:35:28.940 --> 00:35:33.690
Barnabas: But then, can't you just… Make no deposits in that block.

139
00:35:36.220 --> 00:35:52.200
Dima Gusakov | Lido: It's less about making no deposits in this block, it's more about, having no such deposits within the whole pending deposits, and given the current entry queue, we cannot guarantee that it would be, like, exactly one block long. Right now, it's…

140
00:35:52.280 --> 00:36:06.039
Dima Gusakov | Lido: 22 days, and I hope that… I hope, I think, that this queue will not go down that much by the time, we will have a hard fork. So, the window would actually be not blocks.

141
00:36:06.430 --> 00:36:09.419
Dima Gusakov | Lido: Maybe not even days, but rather weeks.

142
00:36:13.610 --> 00:36:19.779
Tomer Ganor: Someone that audited the relevant code that Dima is referring to, it's very not trivial to…

143
00:36:19.970 --> 00:36:33.359
Tomer Ganor: to deal with this from the on-chain perspective, besides us actually pausing this relevant part in the code for, as Dima said, weeks, or, like, even to upgrade the code is not trivial at all.

144
00:36:33.970 --> 00:36:35.090
Tomer Ganor: Together with this.

145
00:36:35.440 --> 00:36:40.049
Tomer Ganor: It's a completely new scheme of, like, how does the flow of the system works.

146
00:36:40.200 --> 00:36:42.320
Tomer Ganor: in the relevant code in Lido.

147
00:36:56.940 --> 00:37:00.190
stokes: I'm just reading the chat here. Yeah.

148
00:37:02.100 --> 00:37:13.500
stokes: Yeah, I mean, this does seem to be the read that core developers wanted to stick to the schedule right now. It would involve… Yeah, like, there's more risk if we were to…

149
00:37:14.170 --> 00:37:15.410
stokes: Change Hoodi.

150
00:37:16.380 --> 00:37:20.750
stokes: And Mainnet, and not have, you know, another Sean Gold Sepolia.

151
00:37:21.930 --> 00:37:24.769
stokes: Also, again, yeah, just given the timing.

152
00:37:25.220 --> 00:37:28.200
stokes: It seems like people prefer just to keep things as they are.

153
00:37:35.080 --> 00:37:38.529
stokes: Are there any core developers who are interested in exploring this further?

154
00:37:50.490 --> 00:37:51.950
stokes: Okay.

155
00:37:55.470 --> 00:38:03.639
stokes: Yeah, okay. I also think in the interest of time, we should timebox this, but yeah, doesn't sound like there's appetite for a change right now.

156
00:38:05.100 --> 00:38:09.980
stokes: Yeah, but I hear you in terms of the impacts,

157
00:38:13.860 --> 00:38:18.690
stokes: I'm, yeah, I'll… I'll… I can try to reach out and see what's possible, but…

158
00:38:19.540 --> 00:38:22.390
stokes: I'm not sure. It sounds like you've done all the legwork already.

159
00:38:24.690 --> 00:38:31.450
stokes: So, yeah, again, unless anybody wants to explore this further, let's go ahead and say that we leave things as they are.

160
00:38:31.680 --> 00:38:34.759
stokes: And, yeah. That'll be that.

161
00:38:35.170 --> 00:38:41.509
stokes: Again, Dima, thank you for bringing this up and, yeah, all the work that everyone put into analyzing the fixes here.

162
00:38:46.790 --> 00:38:53.080
stokes: Okay, let's move on then. Any other final comments for Glamsterdam?

163
00:39:01.870 --> 00:39:02.790
stokes: Okay.

164
00:39:03.880 --> 00:39:13.430
stokes: Then we'll move to Hegota. So, yeah, the main thing today is just to continue the scoping process. First up, though, we…

165
00:39:13.600 --> 00:39:16.660
stokes: Barnabas always wanted to bring up,

166
00:39:17.270 --> 00:39:22.899
stokes: an issue, or at least, yeah, proposal here with, an EIP we've already CFI'd.

167
00:39:23.040 --> 00:39:24.600
stokes: 8365.

168
00:39:24.950 --> 00:39:29.859
stokes: Barnabas, would you like to say some things about your comments on the agenda?

169
00:39:31.640 --> 00:39:41.669
Barnabas: Yeah, sure. So, EIP-8365 is basically, disabling new 0x00 validators, and.

170
00:39:42.000 --> 00:39:48.160
Barnabas: as the EIP describes it right now, those, that would still make a deposit after the…

171
00:39:48.550 --> 00:39:54.179
Barnabas: After the fork, they would get all that ETH burned, basically, and,

172
00:39:55.660 --> 00:40:08.489
Barnabas: I kind of disagree with that. Like, I agree that we need to stop 0x00 validators, but mistakes can still be made, so I think it would be better if.

173
00:40:08.630 --> 00:40:12.720
Barnabas: We would still allow those validators to join just

174
00:40:12.930 --> 00:40:17.170
Barnabas: Basically, have no validatory duties, and they could basically earn nothing.

175
00:40:17.520 --> 00:40:19.280
Barnabas: If they do decide to join.

176
00:40:19.440 --> 00:40:24.150
Barnabas: They could still do a BLS change, they could still, make an exit.

177
00:40:25.040 --> 00:40:26.080
Barnabas: But they would not…

178
00:40:27.040 --> 00:40:40.880
Barnabas: they would not, do the validator duties. And as soon as they would do a BLS change, then the balance would get re-queued, and it would be basically handled as a…

179
00:40:41.360 --> 00:40:52.440
Barnabas: part of a new deposit. So this way, we cannot have an attack, basically, on the network, where there would be a bunch of 0x00 validator keys being made, and then.

180
00:40:53.110 --> 00:40:59.699
Barnabas: So then all of them would change to a 0x01, and we would get a huge inflow of ETH.

181
00:41:00.210 --> 00:41:01.269
Barnabas: Come to the chain.

182
00:41:09.660 --> 00:41:10.920
stokes: Okay, thanks.

183
00:41:11.550 --> 00:41:15.119
stokes: Has anyone else had time to look into this?

184
00:41:15.300 --> 00:41:16.270
stokes: In terms of…

185
00:41:16.270 --> 00:41:21.140
Barnabas: This is very recent, so I wouldn't expect anyone to have taken a closer look.

186
00:41:21.870 --> 00:41:22.520
stokes: Okay.

187
00:41:22.950 --> 00:41:26.950
stokes: Yeah, then I guess the ask today is just to say…

188
00:41:27.180 --> 00:41:30.250
stokes: you'd like to update the EIP with this, and…

189
00:41:30.570 --> 00:41:35.510
stokes: Yeah, I suppose from here, people can take another week, just to look at the changes.

190
00:41:37.330 --> 00:41:41.029
NC: I did spend a couple minutes looking through it.

191
00:41:41.560 --> 00:41:47.939
NC: And… I have some initial opinion, but I haven't fully formed my opinion yet, but

192
00:41:48.460 --> 00:41:51.970
NC: Why would burning ETH be bad?

193
00:41:52.190 --> 00:41:58.410
NC: Because, for example, like, if you submit a deposit with an invalid signature, The ETH is burned.

194
00:41:58.920 --> 00:42:02.850
NC: And it could be a user error, it could be a user using a wrong tool.

195
00:42:03.270 --> 00:42:11.180
NC: And the same argument can be applied to submitting 0x00 deposits in Hegota.

196
00:42:12.000 --> 00:42:14.570
NC: Why would we have sympathy?

197
00:42:14.810 --> 00:42:19.290
NC: to those 0x00, Scenario.

198
00:42:19.830 --> 00:42:27.050
NC: And we don't have sympathy for those who submitted with an invalid signature. Not only invalid signature, but like.

199
00:42:27.680 --> 00:42:40.990
NC: like, deposit and withdrawal and all that, there's just so many things that can go wrong, and if something goes wrong, people can potentially lose money. I don't see why we need to make a special case, just for this.

200
00:42:42.610 --> 00:42:49.250
Barnabas: So you could make a deposit with 0x00 in Aquatar, for example, or in Gloas.

201
00:42:49.430 --> 00:42:53.220
Barnabas: And, you would have a pending queue of, let's say, 60 days.

202
00:42:53.800 --> 00:42:57.470
Barnabas: And Within 40 days, we would have a hard fork.

203
00:42:57.740 --> 00:43:02.350
Barnabas: And in 20 days after the fork, you would have 32 burned ETH.

204
00:43:02.670 --> 00:43:03.790
Barnabas: So you could…

205
00:43:03.790 --> 00:43:04.190
NC: Okay.

206
00:43:04.190 --> 00:43:06.249
Barnabas: Possibly make a deposit where…

207
00:43:06.450 --> 00:43:14.319
Barnabas: it was still allowed, and then you go into a fork because of the long deposit queue, and you would get your ETH burnt.

208
00:43:15.040 --> 00:43:16.050
Barnabas: Okay.

209
00:43:16.050 --> 00:43:19.520
NC: Yes, I do agree with this point.

210
00:43:19.640 --> 00:43:25.379
NC: I think I, I asked this open question on Ethereum Magicians.

211
00:43:25.890 --> 00:43:32.250
NC: a while ago, but nobody answered, but I think essentially what we want here is to grandfather

212
00:43:32.380 --> 00:43:40.260
NC: those 0x00 deposits that were submitted before the Hegota fork.

213
00:43:41.420 --> 00:43:54.329
NC: And I thought about this, and I think the easiest solution here is instead of guarding the apply pending deposits, we just move the guard over to process deposit request.

214
00:43:55.080 --> 00:43:58.890
NC: So that, it happens…

215
00:43:59.170 --> 00:44:00.569
NC: So that it guards.

216
00:44:00.910 --> 00:44:10.849
NC: when you submit the request, not when, the protocol is trying to process the deposit. I think that would solve, the case that you're describing.

217
00:44:11.100 --> 00:44:14.629
NC: But if the deposit is submitted.

218
00:44:14.850 --> 00:44:23.949
NC: After Hegota is activated, then I have no sympathy, for, for this case.

219
00:44:37.410 --> 00:44:40.210
stokes: Okay, yeah, thank you both for that.

220
00:44:41.730 --> 00:44:53.500
stokes: Let's keep things moving, but yeah, I think the ask for now is just, yeah, to take a look at these changes, and yeah, I think we can just bring this back up in another call or two.

221
00:44:55.890 --> 00:45:01.460
stokes: Yeah, then we can hammer out if we want to… Change this EIP or not.

222
00:45:02.770 --> 00:45:03.989
stokes: Sound good to everyone?

223
00:45:10.650 --> 00:45:11.510
stokes: Okay.

224
00:45:14.850 --> 00:45:15.650
stokes: Okay.

225
00:45:16.690 --> 00:45:24.830
stokes: Then, from there, next topic is to continue scoping of the PFI EIPs.

226
00:45:25.410 --> 00:45:30.790
stokes: Let me share Forkcast again because that's been very helpful.

227
00:45:32.030 --> 00:45:33.899
stokes: Just to give everyone.

228
00:45:35.150 --> 00:45:39.360
stokes: A view on things… Let's see…

229
00:45:40.220 --> 00:45:44.339
stokes: Sorry I'm just making sure I get this sorted.

230
00:45:45.950 --> 00:45:51.170
stokes: And I can't see the window. Okay. And then usually people want this a little bigger.

231
00:45:51.660 --> 00:45:53.040
stokes: Does that look good to everyone?

232
00:45:54.650 --> 00:45:55.230
Barnabas: Yep.

233
00:45:55.990 --> 00:45:56.969
stokes: Okay, thanks.

234
00:45:58.310 --> 00:46:04.579
stokes: Okay, cool. Let's see here. So… this is filtered for…

235
00:46:05.110 --> 00:46:10.069
stokes: CL EIPs, that are still in PFI stage.

236
00:46:10.700 --> 00:46:14.430
stokes: And if we do that, then this should be the list that we have.

237
00:46:17.080 --> 00:46:19.470
stokes: In terms of jumping in.

238
00:46:19.740 --> 00:46:29.219
stokes: We had started discussing, EIP-8025 optional execution proofs at the very end of the last call, but I just started the conversation.

239
00:46:29.650 --> 00:46:34.829
stokes: I think that seems like a good place to just go ahead and wrap up the conversation there.

240
00:46:35.200 --> 00:46:36.769
stokes: That we started last call.

241
00:46:37.530 --> 00:46:43.639
stokes: Is Ignacio here? I believe he wanted to share just a couple slides.

242
00:46:44.910 --> 00:46:46.510
ignacio: Yes.

243
00:46:46.510 --> 00:46:51.080
stokes: Okay, I think I need to stop sharing, and then you can share.

244
00:46:51.900 --> 00:46:53.910
ignacio: Cool, I will share my screen.

245
00:46:54.520 --> 00:46:56.490
ignacio: Can you see my screen?

246
00:46:57.300 --> 00:46:58.300
stokes: Yep, I can.

247
00:46:59.080 --> 00:47:12.500
ignacio: Cool. Yeah, I want to make this very short because yeah, we have to discuss many other things, but we just wanted to do a refresher and directly address some of the points that were raised in the last call.

248
00:47:13.530 --> 00:47:23.019
ignacio: So, as a refresher, what EIP-8025 is trying to do is basically allowing opt-in proofs for execution proofs into the network.

249
00:47:23.170 --> 00:47:38.229
ignacio: And opting nodes to verify them, to collect metrics, and start having more understanding of how this, would work… would work in the network. An important point that we keep stressing is that every validator keeps re-executing the payload, and

250
00:47:38.590 --> 00:47:51.500
ignacio: Attesting as… exactly as they do today. The EIP is very clear that they are not allowed to, make proofs interfere or influence attestation pipeline in any kind of shape or form.

251
00:47:52.080 --> 00:47:57.289
ignacio: This is a feature that is off by default, so, even for node operators.

252
00:47:57.700 --> 00:48:07.679
ignacio: They won't be pulling these proofs or something like that. Only node operators that are interested in, helping collecting metrics and understand

253
00:48:07.840 --> 00:48:11.790
ignacio: Networking implications can really obtain on Judy's.

254
00:48:12.350 --> 00:48:21.109
ignacio: So what we are mainly asking for for this optional, network feature is basically allocating some resources

255
00:48:21.410 --> 00:48:24.290
ignacio: within the CoreDev community.

256
00:48:24.410 --> 00:48:34.880
ignacio: Mostly on the spec side, or I would say on the EL spec side. So we want, them to review and upstream and…

257
00:48:35.130 --> 00:48:47.580
ignacio: Mostly this open PR, which has all the changes for EIP-8025 in the execution specs. On the CL-spec side, the changes are already upstream as a feature.

258
00:48:47.730 --> 00:48:51.150
ignacio: So, we are in pretty good shape on that front.

259
00:48:51.750 --> 00:48:58.439
ignacio: And… On the right-hand side of this first slide, we have some summary of readiness.

260
00:48:58.870 --> 00:49:01.840
ignacio: on ELs, CLs and guest programs.

261
00:49:02.110 --> 00:49:08.829
ignacio: On the EL side, we have already 6 of them, integrated into our Hive dashboard.

262
00:49:09.100 --> 00:49:25.239
ignacio: EL clients, our main responsibility within the EIP is basically, implementing execution witness generation, which is basically the information the prover needs for proving. And 6 of them are already passing all the tests.

263
00:49:25.560 --> 00:49:28.320
ignacio: Or over 95% of the tests.

264
00:49:28.650 --> 00:49:33.470
ignacio: And all these changes are already upstream into the main branch, which is awesome.

265
00:49:33.750 --> 00:49:43.610
ignacio: So we are in a really good shape there. On the CL side, we have already iHub upstream the changes into the main branch.

266
00:49:43.950 --> 00:49:48.049
ignacio: We have Prysm already with an open PR based on Glamsterdam.

267
00:49:48.250 --> 00:49:51.179
ignacio: We have draft PRC in the ORCLs.

268
00:49:52.030 --> 00:50:03.429
ignacio: And on the guest program side and zkVMs, we have multiple combinations of integrations. This is not, like, blocking for EIP-8025, but there's really good progress on that front.

269
00:50:03.780 --> 00:50:14.289
ignacio: If you want to know more details about this, you can look at the Hive dashboard yourself. I will share the slides later, and also this progress MD file that we have, where we track

270
00:50:14.400 --> 00:50:15.890
ignacio: Things in more detail.

271
00:50:18.250 --> 00:50:28.509
ignacio: So why we we want to CFI 8025 in Hegota if this is like an optional protocol feature? I think this is the main question that people might have in their heads.

272
00:50:29.150 --> 00:50:38.520
ignacio: And I would say it comes from two main directions. The first one is having operational experience on how this change will affect the network.

273
00:50:38.700 --> 00:50:43.310
ignacio: And giving people, some resource… giving, like.

274
00:50:43.610 --> 00:50:52.250
ignacio: Being clear about some minimal resource allocation in some teams to really get more into this, and gain experience.

275
00:50:52.620 --> 00:51:06.580
ignacio: I would mainly say on the EthPandaOps side, to help us understand, how this will Affect the network, or which are, like, the unknown unknowns that we should still discover.

276
00:51:06.920 --> 00:51:17.639
ignacio: But the… I mean, we can do this anyway without CFI and EIP, but the strongest argument here is mainly on the development and efficiency of the protocol.

277
00:51:17.990 --> 00:51:25.390
ignacio: The EIP-8025 PR on the execution spec is pretty big, it's, like, 16K lines.

278
00:51:25.830 --> 00:51:29.650
ignacio: But,

279
00:51:30.510 --> 00:51:37.270
ignacio: On the right-hand side, I put a table where it really de-aggregates this number, because my sum a bit scary.

280
00:51:37.400 --> 00:51:43.899
ignacio: Only 65 lines are really touching the STF code, which is maybe the most sensitive part of the spec.

281
00:51:44.380 --> 00:51:54.709
ignacio: most of the… PR are mainly testing, framework changes or tests for EIP-8025, which we have a lot.

282
00:51:54.970 --> 00:52:02.879
ignacio: CI changes, unit tests, and things like that. All these kind of changes are not really, like.

283
00:52:03.060 --> 00:52:07.860
ignacio: don't have really a stable API within the testing framework, so we are always, like.

284
00:52:08.280 --> 00:52:13.329
ignacio: One, we are PR away from having a lot of conflicts.

285
00:52:13.580 --> 00:52:15.270
ignacio: And it's kind of…

286
00:52:15.500 --> 00:52:23.299
ignacio: A decent amount of work to really maintain this. This is a PR that we have been maintaining for quite a while, like.

287
00:52:23.530 --> 00:52:34.019
ignacio: At least for… for… for a… for… for a year, and it has been rebased on top of at least, five devnets in Glamsterdam.

288
00:52:35.940 --> 00:52:47.480
ignacio: So it's not really like a one-shotted PR or something like that. A lot of people have been refining many angles of it from EL and CL core Devs.

289
00:52:48.230 --> 00:53:05.920
ignacio: And these 56 line changes, I think it's really important to stress, because the main point here is that we don't want this EIP to really clash with other EIPs that may get scheduled for Hegota, so it shouldn't really interfere with other efforts in the fork.

290
00:53:06.840 --> 00:53:17.900
ignacio: And the other main thing that we want to stress is Proving Blocks might have some.

291
00:53:18.860 --> 00:53:24.540
ignacio: We might want to do more, experimentation on how ProvingBlocks.

292
00:53:25.490 --> 00:53:29.120
ignacio: interact with our upcoming changes, such as PBT.

293
00:53:29.370 --> 00:53:44.420
ignacio: And PBT already has its own branch in execution specs. We already have our own branch of 8025. They might be based on different base branches, and if we want to understand the implications of both being live, we'll have to maintain a third branch.

294
00:53:44.620 --> 00:53:47.130
ignacio: And the same will happen with other things.

295
00:53:47.310 --> 00:53:55.629
ignacio: If we are… if we have the conviction that ProvingBlocks in L1 will be something That will happen in the future.

296
00:53:55.890 --> 00:54:02.910
ignacio: It would simplify a lot, to really upstream, our work that,

297
00:54:03.290 --> 00:54:08.039
ignacio: We feel it's pretty mature and the EELS team has been tracking for a while.

298
00:54:08.350 --> 00:54:20.470
ignacio: And simplify all the coordination that comes from, creating all these branches, because now core dev coordination is really the bottleneck for protocol development, not really, like, execution.

299
00:54:20.700 --> 00:54:22.810
ignacio: Of the, of the changes.

300
00:54:23.330 --> 00:54:29.870
ignacio: And this will also simplify some pipelining of releases, such as releasing.

301
00:54:30.120 --> 00:54:39.320
ignacio: stateless log execution within the main releases from EELS, and we won't have, like, this Umm.

302
00:54:39.540 --> 00:54:43.330
ignacio: Lagging between, like, 80-25…

303
00:54:43.460 --> 00:54:50.019
ignacio: let's say zkVM releases and main releases, and there's a lot of things that will be more efficient.

304
00:54:51.120 --> 00:54:58.899
ignacio: On the last slide, I want to target some particular comments that we, had in the last call.

305
00:54:59.240 --> 00:55:05.879
ignacio: Which were mainly why this should be a core EIP compared to an informational one or an ERC.

306
00:55:06.750 --> 00:55:18.560
ignacio: My angle to this question is that we want to make sure that at the protocol level, we make clear that no CL is allowed to use proofs for attestation.

307
00:55:18.720 --> 00:55:20.710
ignacio: Because this is not safe.

308
00:55:21.120 --> 00:55:32.529
ignacio: If you put this EIP in an informational one, or somehow in an ERC, as someone suggested, I don't think this is, like, a strong rule that we are putting in the protocol.

309
00:55:33.020 --> 00:55:34.150
ignacio: Umm.

310
00:55:34.390 --> 00:55:39.030
ignacio: So, I see this as… It's much safer that…

311
00:55:39.140 --> 00:55:47.490
ignacio: As a community, we decide to be really clear about this rule, so we can keep moving forward with spec development.

312
00:55:47.640 --> 00:55:56.650
ignacio: Without putting the network at risk, and we have some clear rules about what CLs should implement. For the main releases.

313
00:55:57.410 --> 00:56:07.710
ignacio: And I know that some people, because I've been talking with them the last days, think, okay, what if someone changes the source code of CLs to a test with proofs?

314
00:56:07.920 --> 00:56:19.850
ignacio: I mean, my answer to this is that they can already change the source code to attest whatever they want, and drop ELs or accept proofs in new gossip channels.

315
00:56:19.880 --> 00:56:28.949
ignacio: So, the main assumption that we always have is that CLs and network operators are following the protocol rules. That's an assumption that we have.

316
00:56:29.070 --> 00:56:40.549
ignacio: And if someone wants to simply drop the EL, they can already do that by editing their CL source code and simply always attesting yes, and 99% of the time, they will be

317
00:56:40.680 --> 00:56:42.490
ignacio: Right, so,

318
00:56:42.910 --> 00:56:51.869
ignacio: I think it's important to set up the rules at the protocol level, and force implementations to follow the rules, because this is, like, our main assumption.

319
00:56:52.070 --> 00:57:09.889
ignacio: And as a last point, some random questions, if we need repricing for EIP-8025, that is not the case, because, proofs are not really required for attestation, as we clarified before, so repricing is more on the mandatory proofs.

320
00:57:10.130 --> 00:57:13.810
ignacio: Side of the story, so into the future.

321
00:57:14.410 --> 00:57:18.790
ignacio: And regarding picking zkVMs or these programs, again.

322
00:57:18.870 --> 00:57:29.980
ignacio: This is not something for EIP-8025, this is more for mandatory proofs. The execution spec changes are mainly how to correctly define a stateless block validation.

323
00:57:29.980 --> 00:57:40.450
ignacio: With the right rules, with the right checks, standardizing things so people have a coordination point, to really do the work and move forward.

324
00:57:40.980 --> 00:57:45.079
ignacio: So that's everything I wanted to share, and I'm happy to receive any questions.

325
00:57:47.060 --> 00:57:48.269
stokes: Okay, thank you.

326
00:57:49.000 --> 00:57:58.239
stokes: Yeah, just, process point, let's try to timebox this, just so we have room for other things.

327
00:57:58.600 --> 00:58:06.030
stokes: But yeah, that was a really nice overview. Thank you for that. There has been some discussion in the chat already.

328
00:58:06.480 --> 00:58:09.269
stokes: just… yeah, so I think, you know.

329
00:58:09.440 --> 00:58:12.800
stokes: Well, I was summarizing the chat here, like, the question's just, like.

330
00:58:12.970 --> 00:58:17.190
stokes: you know, do we need to CFI this versus is there some other way to…

331
00:58:17.800 --> 00:58:21.729
stokes: get the, you know, R&D work that you were just calling out without that?

332
00:58:22.990 --> 00:58:26.489
stokes: Any client teams want to… oh, yeah, go ahead.

333
00:58:26.800 --> 00:58:40.889
ignacio: Yeah, I just want to say that the main interest from our side is to upstream this into the specs. The EELS team has a pretty reasonable rule of requiring changes to be CFI to be really upstream.

334
00:58:41.070 --> 00:58:45.799
ignacio: And we try to simply honor on this rule, because

335
00:58:46.460 --> 00:58:52.910
ignacio: This rule is there for a reason for them, because if not, a lot of people will be upstreaming really experimental changes.

336
00:58:53.200 --> 00:59:00.840
ignacio: So we are trying to follow the process rules and honor the way they work. That's kind of our take.

337
00:59:01.330 --> 00:59:06.009
ignacio: on why we need to CFI this big instead of simply keep working in parallel.

338
00:59:07.320 --> 00:59:10.010
stokes: Yeah, I see. Lukasz?

339
00:59:10.560 --> 00:59:23.189
Łukasz Rozmej: I kind of agree with here that our process is not great in when we have this long running initiatives like block proving or

340
00:59:23.440 --> 00:59:28.340
Łukasz Rozmej: Binary trees or other things, to integrate them in…

341
00:59:28.680 --> 00:59:46.400
Łukasz Rozmej: So, this is… this is being tried to CFI to integrate them better also, but we could potentially come up with some process of this more experimental features that are long-running to try to integrate them better instead of leaving them in this merge hell.

342
00:59:47.880 --> 00:59:56.840
Łukasz Rozmej: And, interaction web, that's hard to untangle and discover everything, so…

343
00:59:57.570 --> 01:00:05.599
Łukasz Rozmej: we can consider trying to tackle this instead of CFIing also, but…

344
01:00:05.760 --> 01:00:08.560
Łukasz Rozmej: CFI is simpler with the current process.

345
01:00:11.350 --> 01:00:11.990
stokes: Yeah.

346
01:00:12.990 --> 01:00:24.530
stokes: I don't know enough about how ELs are set up, on this point, but I do wonder if, you know, rather than a branch of this, because I assume there's a, you know, branch that has this code already.

347
01:00:24.890 --> 01:00:29.710
stokes: In the EL spec, maybe something like a feature flag or something like that.

348
01:00:30.650 --> 01:00:37.669
stokes: I'm just kind of brainstorming. That being said, it'd be good to hear from some CL teams. Yeah.

349
01:00:38.140 --> 01:00:39.580
stokes: What their stance is here.

350
01:00:41.420 --> 01:00:48.530
stokes: If we go… actually, I guess I can reshare the Forkcast screen, but yeah, if any ECL teams want to chime in while I'm doing that.

351
01:01:09.920 --> 01:01:11.650
stokes: Okay, I lost the chat now.

352
01:01:14.710 --> 01:01:25.490
stokes: Are there any ECL teams that want to chime in on this? I pulled up the Forkcast here because, yeah, going by client rankings, it's pretty mixed.

353
01:01:30.660 --> 01:01:34.960
stokes: Okay, at least kingy here from Lighthouse, you know, they obviously support the work.

354
01:01:35.570 --> 01:01:37.319
stokes: But not so sure on CFI.

355
01:01:39.760 --> 01:01:45.919
saulius: I think that, well, I mean, it's something that,

356
01:01:46.040 --> 01:02:02.370
saulius: people want, I think, in some sense, but my main concern is actually the scope. I mean, I'm happy to include that later in the process, if we see that there is room for that.

357
01:02:03.370 --> 01:02:13.179
saulius: So, I mean, at the moment, the scope of FOCIL and… essentially, the scope of FOCIL is the main finger.

358
01:02:13.640 --> 01:02:18.160
saulius: That is blocking me to to CFI this.

359
01:02:23.630 --> 01:02:24.660
stokes: Anybody else?

360
01:02:33.700 --> 01:02:36.789
stokes: Yeah, I mean, personally, I'm here at Lukasz, like…

361
01:02:37.710 --> 01:02:41.369
stokes: I think this could go either way in terms of CFI or not, but…

362
01:02:42.070 --> 01:02:47.230
stokes: we have this process point around actually making sure the work does get done if it's not CFI.

363
01:02:48.030 --> 01:02:51.959
stokes: So… Yeah, this one's a little tricky.

364
01:02:55.780 --> 01:02:57.339
stokes: Any other CL teams?

365
01:02:57.880 --> 01:03:00.290
stokes: or EL teams that haven't chimed in yet.

366
01:03:06.610 --> 01:03:09.950
lightclient: Yeah, I mean, I've kind of said in the comments, I don't really…

367
01:03:10.140 --> 01:03:12.239
lightclient: Support CFI in this, I think.

368
01:03:12.620 --> 01:03:18.539
lightclient: All of these other large projects in ethereum have gone through the same process of.

369
01:03:19.080 --> 01:03:22.550
lightclient: waiting until they're actually getting CFI to be included.

370
01:03:23.040 --> 01:03:25.040
lightclient: It's a feature of ethereum.

371
01:03:25.310 --> 01:03:30.799
lightclient: And have had to work in parallel or on their own branches for many years.

372
01:03:31.120 --> 01:03:33.139
lightclient: I don't think that we should.

373
01:03:33.270 --> 01:03:35.540
lightclient: I'll be changing this just to support.

374
01:03:35.770 --> 01:03:38.690
lightclient: To optionalists, or an optional feature.

375
01:03:42.870 --> 01:03:44.239
stokes: Yeah, Iván, your hand's up.

376
01:03:45.490 --> 01:04:01.640
Iván | ethrex: Thanks. Yeah, on the EPIC side, we support moving EIP-8025 to CFI for Hegota. The zkEVM roadmap requires substantial integration and testing work, and we need early commitments from client teams.

377
01:04:01.980 --> 01:04:03.849
Iván | ethrex: To give that work enough time.

378
01:04:05.470 --> 01:04:17.930
Iván | ethrex: this was already told by Ignacio, but thinking that this could be an optional EIP because it's an optional feature is kind of a misinterpretation of its purpose. The feature should be optional for node operators and improvers.

379
01:04:18.470 --> 01:04:32.199
Iván | ethrex: But its support should be an expectation for all clients. Operators should be able to opt in, regardless of their client choice. That requires team to commit to implementing, testing, and maintaining this.

380
01:04:33.850 --> 01:04:52.680
Iván | ethrex: I was going to talk about the support this EIP already has in the code that Ignacio already shared. I will share the dashboard Again, the Hive tests that are running this. On the EL side, almost every client supports this, and almost everyone is passing all the tests.

381
01:04:53.990 --> 01:05:03.490
Iván | ethrex: I think that the more groundwork we lay now through EIP-8025, the more we can focus our efforts on the unknown unknowns for mandatory proofs.

382
01:05:04.500 --> 01:05:07.680
Iván | ethrex: And yeah, we've been supporting this feature from the very beginning.

383
01:05:08.130 --> 01:05:14.100
Iván | ethrex: and we… we want to see it CFI, even though this is a…

384
01:05:14.830 --> 01:05:22.819
Iván | ethrex: CL team client decision, it would be great to also maybe include execution client decisions on this.

385
01:05:25.990 --> 01:05:34.930
lightclient: I'll understand this point that any operator should be able to opt into this regardless of their client. That, to me, feels like a much broader scope than what

386
01:05:35.120 --> 01:05:37.029
lightclient: Even Ignacio was proposing.

387
01:05:39.280 --> 01:05:45.189
lightclient: Like, this is an optional feature that we are trying to test out to see if it is feasible on Mainnet.

388
01:05:45.380 --> 01:05:48.580
lightclient: I definitely don't think that any operator should be able to.

389
01:05:48.700 --> 01:05:49.689
lightclient: Who's that?

390
01:05:56.210 --> 01:06:03.150
ignacio: Yeah, I would say that we should focus more on the process here, and the proposal is to CFI

391
01:06:03.620 --> 01:06:09.380
ignacio: the EIP, and we can later decide to DFI it if we think

392
01:06:09.490 --> 01:06:24.310
ignacio: it's not convincing or something like that. I mean, all the rules for being CFI are already ready. We have the spec branch in the execution specs, has been maintained for a pretty long time. A lot of people are really working on this.

393
01:06:24.370 --> 01:06:30.340
ignacio: You have the safety guardrails to not really put the network at risk.

394
01:06:30.480 --> 01:06:36.810
ignacio: The main thing we want to do is to upstream work that is already quite mature.

395
01:06:37.080 --> 01:06:48.909
ignacio: And it's aligned with the original vision of Ethereum. If we have conviction that this is something that we will do in the future, it's just making our process much more efficient, and not really waste time on keeping

396
01:06:49.010 --> 01:07:08.490
ignacio: a lot of branches, when we also have a lot of our important work to do regarding, PQ or other things in the near future. So, it's very… will be really sad and inefficient when wasting scarce resources we have, trying to maintain all this stuff when it's really truly upstream.

397
01:07:09.290 --> 01:07:13.050
lightclient: That is just not a good reason to make a EIP.

398
01:07:13.630 --> 01:07:15.400
lightclient: A core EIP passed.

399
01:07:16.130 --> 01:07:17.160
lightclient: Governance.

400
01:07:17.280 --> 01:07:20.130
lightclient: Because the branches are difficult to manage.

401
01:07:22.900 --> 01:07:27.619
ignacio: Right, but who is managing that? It's basically me and the EELS team, right?

402
01:07:30.740 --> 01:07:35.989
lightclient: doesn't mean it's… still doesn't mean it's a good reason to push an EIP through the process.

403
01:07:39.060 --> 01:07:43.939
lightclient: Every other large feature of ethereum has had to deal with this for years on end.

404
01:07:44.180 --> 01:07:46.490
lightclient: Did we have a bit different process? Like, maybe.

405
01:07:47.690 --> 01:07:52.479
lightclient: But I don't think that this is… Good reason to do this.

406
01:07:54.880 --> 01:07:57.920
ignacio: I disagree on that, in the sense that that might be.

407
01:07:57.920 --> 01:08:00.740
lightclient: I mean, of course you disagree. You're the one who has to rebase it.

408
01:08:02.620 --> 01:08:08.089
ignacio: But it's not about me, it's about, like, resources that we have to do all the changes that we want for Ethereum, right?

409
01:08:08.090 --> 01:08:10.740
lightclient: It's never been easier to rebase features.

410
01:08:10.860 --> 01:08:15.430
lightclient: Like, 2 years ago, maybe it was a different argument, but, like, now, just ask Claude to rebase the feature.

411
01:08:15.810 --> 01:08:17.479
lightclient: 10 minutes later, it's rebased.

412
01:08:19.529 --> 01:08:19.989
stokes: so…

413
01:08:19.990 --> 01:08:26.129
ignacio: It's not about rebasing, it's about, like, complexity of how EIPs interact with each other, too, so it's…

414
01:08:26.130 --> 01:08:28.660
lightclient: Okay, now that's different. That's a very different argument.

415
01:08:29.080 --> 01:08:30.140
ignacio: But now we have to.

416
01:08:30.140 --> 01:08:34.909
lightclient: We constrain ourselves. We have to potentially constrain ourselves based on an optional EIP.

417
01:08:35.630 --> 01:08:40.629
lightclient: That's a totally different argument than you were making and I think that that's like way overstepping.

418
01:08:41.050 --> 01:08:42.060
lightclient: But they shouldn't.

419
01:08:43.550 --> 01:08:45.090
lightclient: What we should be accepting right now.

420
01:08:50.609 --> 01:09:00.369
stokes: In terms of the other EIPs we should touch on today, I think we should go ahead and make a call on this and then move on to others.

421
01:09:01.799 --> 01:09:13.059
stokes: What I'm hearing is that, yeah, in terms of this being a CL EIP from the CL clients here today, yeah, it doesn't seem like there's support to CFI this.

422
01:09:13.589 --> 01:09:23.319
stokes: That being said, I do think, you know, we can at least have a verbal commitment today to put resources on this, just to put attention on it, and keep it moving forward.

423
01:09:24.139 --> 01:09:24.989
stokes: But…

424
01:09:25.729 --> 01:09:31.599
stokes: yeah, I'm not really hearing any ECL team chime in if they want to go ahead and CFI this.

425
01:09:33.429 --> 01:09:35.329
stokes: Now is your chance to speak up.

426
01:09:36.789 --> 01:09:40.749
stokes: See all teams. If you feel differently,

427
01:09:40.750 --> 01:09:49.399
Manu: Yeah, Manu from Prysm. So actually, in our ranking, we… said, we…

428
01:09:50.790 --> 01:10:06.110
Manu: We did not write a big priority for this, because this EIP, yes, does not require a hard fork. Yes, that was the main reason. However, NITAS and Prysm are actively working on this EIP.

429
01:10:06.360 --> 01:10:11.339
Manu: Yes, Lighthouse has merbly CIP in unstable and Prysm has a branch.

430
01:10:12.610 --> 01:10:20.739
Manu: And so… CFIing or not, this EIP would not make a big difference about the…

431
01:10:21.320 --> 01:10:26.209
Manu: the effort we deploy to work on this EIP.

432
01:10:29.090 --> 01:10:31.020
Manu: Because that's… it's optional.

433
01:10:31.280 --> 01:10:33.949
Manu: So in my opinion, we could CFI it.

434
01:10:36.200 --> 01:10:39.320
Manu: And so it will kind of show that.

435
01:10:39.770 --> 01:10:46.150
Manu: So, yes, at least a few clients team are keen on working on this EIP.

436
01:10:49.070 --> 01:10:49.830
stokes: Enrico.

437
01:10:51.180 --> 01:10:58.819
Enrico Del Fante: Oh, and just a comment on the optionality, because it looks… it's weird to me. So, okay, then the optionality is…

438
01:10:58.940 --> 01:11:03.509
Enrico Del Fante: Around consuming the proofs.

439
01:11:03.740 --> 01:11:19.179
Enrico Del Fante: But since there is a gossip subnet now that is required by this, it means that all the nodes should support in helping disseminating the proofs, and then decide optionally to use the proof or not.

440
01:11:19.740 --> 01:11:31.290
Enrico Del Fante: But if this goes in, anyway, I believe all the clients must support the new… the new cells, the new topic, and support the dissemination of the proof.

441
01:11:31.680 --> 01:11:35.660
Enrico Del Fante: So, I mean… The optionality is not complete.

442
01:11:37.060 --> 01:11:52.350
Manu: I mean, I don't know if it's time to enter too much technical details here, but no, it's not true. I mean, if a node, should opt in, with this EIP, it just exposes an EPROOF field in its

443
01:11:52.600 --> 01:12:00.760
Manu: node record, ENR, and that's it. And, you know, other PR wanted to… to use as proof, just have to

444
01:12:01.780 --> 01:12:07.899
Manu: to to look for peers in the network with this, with this e proofs field, and then

445
01:12:08.120 --> 01:12:11.650
Manu: The peer will know that other peers will subscribe to the.

446
01:12:11.650 --> 01:12:12.250
Enrico Del Fante: Oh, okay.

447
01:12:12.250 --> 01:12:13.720
Manu: Execution proofs. So yeah.

448
01:12:13.720 --> 01:12:18.159
Enrico Del Fante: Okay, so it's optional also into participating in the networking layer.

449
01:12:18.160 --> 01:12:19.980
Manu: Yes, exactly, exactly, yeah.

450
01:12:19.980 --> 01:12:20.880
Enrico Del Fante: Oh, okay.

451
01:12:26.980 --> 01:12:27.740
stokes: Okay.

452
01:12:27.890 --> 01:12:31.990
stokes: So maybe now a bit stronger support for Prysm, but otherwise.

453
01:12:33.130 --> 01:12:38.520
stokes: I'm not hearing it from the other clients, and I think there have been a number of comments in the chat from CL

454
01:12:38.780 --> 01:12:43.279
stokes: Teams, slash persons, that… They don't see the CFI.

455
01:12:43.540 --> 01:12:52.130
Manu: I mean, I don't know if there is some Lighthouse people here, but Lighthouse already merged into the unstable branch EIP-8025, so it's…

456
01:12:52.340 --> 01:12:55.189
Manu: For me, it's an implicit support to it.

457
01:12:55.700 --> 01:12:59.539
Manu: And why would we want to merge in,

458
01:12:59.650 --> 01:13:03.290
Manu: in your unstable branch if you don't support the EIP. It does not make sense.

459
01:13:09.020 --> 01:13:15.779
Manu: Yes, said otherwise, who is against it? Yes, as Ignacio asked in the chat.

460
01:13:19.320 --> 01:13:22.249
stokes: Potuz, I'm assuming Enrico your hand was from earlier.

461
01:13:24.660 --> 01:13:39.629
Potuz: Oh, Enrico was up for earlier. I am against this, if this means merging into Heze. I'm sure that Manu's Manu's branch can be merged and will be merged into Prysm's trunk branch. This will be a feature that we will maintain

462
01:13:39.870 --> 01:13:52.329
Potuz: I am against merging this into the main fork branch. Because then it means that this goes away from being optional, and it would affect every single fork and every single work that we do.

463
01:13:52.920 --> 01:14:08.189
Potuz: And then we are actually forced to… not this maintainer, this branch maintainer is forced to rebase into what our forks are, but every single EIP writer for the CL spec needs to be compatible with whatever this branch does.

464
01:14:08.850 --> 01:14:12.140
Potuz: And this affects every single, every next fork.

465
01:14:12.420 --> 01:14:16.160
Potuz: I think this… this should not be happening for optional features.

466
01:14:18.150 --> 01:14:19.030
stokes: Francesco.

467
01:14:20.400 --> 01:14:31.209
Francesco Risitano (Tau): Yeah, I just wanted to touch on the interplay of this EIP in regards to the specs. So the execution proof handler is very isolated.

468
01:14:31.830 --> 01:14:37.290
Francesco Risitano (Tau): And, you know, we do introduce a proof engine, but it doesn't have

469
01:14:37.430 --> 01:14:48.110
Francesco Risitano (Tau): you know, a lot of interplay with the rest of the specs, so I'd argue that, the argument around, kind of, considerations may not necessarily.

470
01:14:48.260 --> 01:14:53.740
Francesco Risitano (Tau): Be, that significant, But, you know, I'd encourage.

471
01:14:54.070 --> 01:15:10.969
Francesco Risitano (Tau): kind of CL Devs to review that and come to a conclusion themselves, but that's my personal opinion, at least. It's quite isolated, and that was done, you know, the design was intentionally isolated to prevent, kind of complications of that nature.

472
01:15:11.010 --> 01:15:16.200
Francesco Risitano (Tau): We've actually done a number of iterations to reduce the footprint of this EIP

473
01:15:17.200 --> 01:15:20.040
Francesco Risitano (Tau): To make this more, kind of, maintainable.

474
01:15:21.320 --> 01:15:23.219
Francesco Risitano (Tau): We're not putting a burden on Devs.

475
01:15:29.580 --> 01:15:31.300
stokes: Yeah, thanks for the comments.

476
01:15:32.070 --> 01:15:41.640
stokes: Yeah, that's all helpful, but yeah, it just seems like there's not consensus here amongst the CL teams to merge this in, for this work.

477
01:15:42.230 --> 01:15:52.129
stokes: So, I… my read is that people will support DFI. Obviously, there's these caveats around, yeah, the process here, and how we work with this thing.

478
01:15:52.600 --> 01:16:01.949
stokes: it sounds like maybe there's something we could do in the EELS repo itself to make the work a little bit simpler, so we should definitely explore that.

479
01:16:02.800 --> 01:16:07.109
stokes: But yeah, as of today, in terms of scoping, this seems like a DFI.

480
01:16:08.290 --> 01:16:10.179
stokes: Okay, Mario, last comment.

481
01:16:10.180 --> 01:16:29.659
Mario Vega: Yeah, sorry, yeah, basically just want to echo the exact same problem that Potuz is having with merging into main is exactly the same that we're having today on the EL specs. Basically, when you merge something onto the main branch, you're asking the rest of the EIPs to adhere to the… to what's already merged, in this case, zk

482
01:16:29.660 --> 01:16:38.500
Mario Vega: EVM proofs. So that's what I wanted to get from today, the signal that this is important, we have to, accommodate for it, right?

483
01:16:38.720 --> 01:16:54.299
Mario Vega: And that's my concern of merging, just merging into the main development branch. I don't want this to be, like, enshrined if the EL Devs or the CL Devs are not in favor of it. So, yeah, that's my concern, right? Basically. Thank you.

484
01:16:55.460 --> 01:16:56.430
stokes: Yeah, thanks.

485
01:16:56.980 --> 01:17:04.389
stokes: Again, yeah, I'm not as familiar with the EL specs. On the CL specs, we have this notion of, like, feature specs that…

486
01:17:04.510 --> 01:17:06.069
stokes: Kind of sit alongside.

487
01:17:06.780 --> 01:17:14.469
stokes: The canonical specs, let's say, or main… mainline specs, yeah, either way.

488
01:17:15.760 --> 01:17:25.829
stokes: hopefully there's something we can do there, just to make the, you know, the actual engineering easier, but again, in terms of today, I think we go with DFI for this, and move forward.

489
01:17:28.740 --> 01:17:32.050
stokes: So… Let's do that.

490
01:17:34.720 --> 01:17:40.460
stokes: Okay, let's see here, we have about a little under 30 minutes.

491
01:17:40.560 --> 01:17:41.470
stokes: So…

492
01:17:44.140 --> 01:17:58.669
stokes: And one option here is to start from the bottom here, just in terms of how these are ranked, and try to get through things that we might try to think are DFI.

493
01:18:00.540 --> 01:18:02.770
stokes: Just based on the client's rankings.

494
01:18:03.610 --> 01:18:11.820
stokes: that, I think, will help us just move through some EIPs, and then, yeah, we're ultimately gonna have, yeah, more EIPs to get through, I think, probably on the next call.

495
01:18:13.270 --> 01:18:19.189
stokes: So… Let's do that next. Then in that case…

496
01:18:19.440 --> 01:18:28.570
stokes: So, yeah, we have this EIP here for VOPs. We had touched on it previously, that it's informational. I think we can just set it aside for now.

497
01:18:29.700 --> 01:18:37.669
stokes: Then, let's see what we can do here with the time remaining. We'll start with RowDAS here.

498
01:18:38.440 --> 01:18:42.819
stokes: Let's see. Yeah, Csaba, here is the champion.

499
01:18:43.000 --> 01:18:46.770
stokes: I don't know if you'd like to say anything briefly on this.

500
01:18:47.190 --> 01:18:47.950
Csaba: Yep.

501
01:18:47.950 --> 01:18:50.309
stokes: Are you on the call? Okay, yeah, go for it.

502
01:18:53.020 --> 01:18:56.800
Csaba: Yeah, so… I just have smells.

503
01:18:57.740 --> 01:18:59.120
stokes: There's definitely an echo.

504
01:19:01.400 --> 01:19:03.010
Csaba: some technical problems.

505
01:19:03.720 --> 01:19:13.840
Csaba: Oh, should be good. Yeah, so… RowDAS has… The goal of fixing,

506
01:19:15.100 --> 01:19:22.419
Csaba: past design decision that we made when we introduced PeerDAS. It's planning to fix two things.

507
01:19:22.520 --> 01:19:29.490
Csaba: One is the excess… CPU load that we have on.

508
01:19:30.600 --> 01:19:36.380
Csaba: On large nodes, and the other one is, the reliance on these nodes.

509
01:19:37.150 --> 01:19:41.020
Csaba: I think it's quite important to fix this.

510
01:19:41.270 --> 01:19:44.509
Csaba: But I can accept that it's not for everyone.

511
01:19:44.630 --> 01:19:51.130
Csaba: I wouldn't go by the argument that we don't have any way blobs today, so we should not invest in this.

512
01:19:51.250 --> 01:19:56.830
Csaba: What I wanted to say is that it does have a…

513
01:19:57.940 --> 01:20:13.120
Csaba: B option, a reduced version, which is fixing only one of these problems, which is fixing only the… the one which is the excess CPU usage, so the mechanism is based on a duty allocation, basically.

514
01:20:13.230 --> 01:20:21.129
Csaba: And, we could… do that, and that's very simple. So that is this B variant, if people feel that the other one is too complex.

515
01:20:21.330 --> 01:20:29.080
Csaba: Although that's what I'm more passionate about, which we just don't rely as a protocol on those entities.

516
01:20:29.400 --> 01:20:37.150
Csaba: Anyway, there is this B variant, which is very simple, and it's, just simply, putting into Protocol

517
01:20:37.320 --> 01:20:55.839
Csaba: what clients are trying to do on their own in different ways, but there is no synchronization behind that, and this would just allow us to distribute the load in the network in a simple way, and just distribute the load, the construction load. If it would happen that we have.

518
01:20:55.910 --> 01:20:59.699
Csaba: More blobs in the next, whatever number of months.

519
01:21:00.040 --> 01:21:01.790
Csaba: Until we arrive to Hegota.

520
01:21:02.970 --> 01:21:14.250
Csaba: I have published some design notes next to it, so feel free to go through those. If you feel like you still want to consider, then I'm happy to delay, but I see the score, so…

521
01:21:14.880 --> 01:21:18.730
Csaba: It depends on… Who is up to it?

522
01:21:21.240 --> 01:21:22.490
stokes: Okay, thanks.

523
01:21:23.040 --> 01:21:26.729
stokes: Yeah, any client teams want to speak to this?

524
01:21:29.300 --> 01:21:31.960
Csaba: My, yeah. Oh. Maybe there was T.

525
01:21:32.770 --> 01:21:38.090
Csaba: My speaker is muted, so I didn't… I didn't hear the responses, if there were responses.

526
01:21:38.770 --> 01:21:43.520
stokes: I don't think there's been any yet, yeah. But yeah, just going off of this,

527
01:21:44.200 --> 01:21:53.860
stokes: Yeah, didn't hear from Lodestar Prysm, according to Forkcast here. Nimbus was in favor, but otherwise, yeah, Teku, Lighthouse, Grandine.

528
01:21:55.880 --> 01:21:57.260
stokes: Were against.

529
01:21:58.690 --> 01:22:02.090
stokes: Any clients want to chime in with any more color right now?

530
01:22:13.500 --> 01:22:16.739
Csaba: The main argument I've seen is that we don't have blobs.

531
01:22:17.320 --> 01:22:17.910
stokes: Yeah.

532
01:22:18.740 --> 01:22:22.740
Csaba: I'm not sure that we'll find it in the following many months, but,

533
01:22:28.730 --> 01:22:29.500
Csaba: I don't know that.

534
01:22:29.500 --> 01:22:33.900
stokes: I mean, again, going off the client ratings, I think we go ahead and say DFI this for today.

535
01:22:34.560 --> 01:22:42.820
stokes: But yeah, I mean, this is the type of thing where it's like, I think we need to have the work ready to go, but again, yeah, like you're saying, just in terms of…

536
01:22:43.230 --> 01:22:47.360
stokes: where supply and demand of blobs are at today. This isn't…

537
01:22:47.510 --> 01:22:49.480
stokes: Doesn't feel like the most urgent EIP.

538
01:22:56.590 --> 01:22:59.940
stokes: Okay. Any other CL teams want to chime in here?

539
01:23:00.070 --> 01:23:01.930
stokes: Otherwise, we'll just go with DFI.

540
01:23:07.360 --> 01:23:08.100
stokes: Okay.

541
01:23:10.220 --> 01:23:11.270
stokes: Thanks, Trevor.

542
01:23:13.050 --> 01:23:19.369
stokes: Next up, we have EIP-8359. This is BeaconBlock reporting field.

543
01:23:19.970 --> 01:23:24.139
stokes: And the champion was hanniabu.

544
01:23:24.270 --> 01:23:30.240
stokes: Are they here, or is one of the authors here that would like to Say something brief about this.

545
01:23:30.810 --> 01:23:35.119
Luca | Vero: hanniabu isn't here, as far as I know, but I can… Say a few words.

546
01:23:35.410 --> 01:23:43.149
Luca | Vero: So, this is the new proposed BeaconBlock field, aimed to give us more data about client diversity on the network.

547
01:23:43.750 --> 01:23:49.929
Luca | Vero: The… that's the… the problem it solves is the current graffiti way isn't…

548
01:23:50.640 --> 01:23:56.760
Luca | Vero: Perfectly fitted for the more complex setups, like multi-node setups with different client pairs.

549
01:23:57.180 --> 01:24:05.199
Luca | Vero: So, here, we propose to add a new field to the BeaconBlock, which would properly, Give us that information.

550
01:24:05.620 --> 01:24:12.660
Luca | Vero: It would be possible to opt out of this if anybody doesn't want to share that information, but the default would be to provide that.

551
01:24:14.290 --> 01:24:20.460
Luca | Vero: The main criticism this EIP has gotten is that we should just do this in the graffiti field.

552
01:24:20.890 --> 01:24:26.269
Luca | Vero: Like we do today, which… Is… is okay, but…

553
01:24:26.460 --> 01:24:36.859
Luca | Vero: The problem with that is that the graffiti field is used for other purposes as well, so some people, just for that reason, won't want to

554
01:24:37.840 --> 01:24:40.390
Luca | Vero: Use that field for client usage data.

555
01:24:40.510 --> 01:24:45.330
Luca | Vero: So just using the graffiti fields for this purpose will hurt adoption.

556
01:24:47.000 --> 01:24:51.190
Luca | Vero: Of this kind of reporting, Yeah.

557
01:24:51.650 --> 01:24:57.789
Luca | Vero: adding a new field to the block is a very cheap way to get this kind of data for the whole network.

558
01:25:01.170 --> 01:25:10.849
Luca | Vero: Yeah, so if we want to properly measure client diversity, accounting for multi-node setups and DVT, then I think this is one of the easiest and cheapest ways to do this.

559
01:25:14.580 --> 01:25:15.820
stokes: Okay, thanks.

560
01:25:16.860 --> 01:25:27.920
stokes: Yeah, any client teams have questions or response to that. Again, going off the rankings that we've already assembled, it's not rated super highly.

561
01:25:29.890 --> 01:25:37.480
stokes: yeah, again, I think we all agree the topic is important. I'm not sure there's support for this in Hegota right now.

562
01:25:45.530 --> 01:25:49.820
stokes: Any client teams want to speak up in favor of this? Otherwise, we'll just DFI.

563
01:26:03.340 --> 01:26:05.100
stokes: Okay, going once.

564
01:26:05.360 --> 01:26:07.400
stokes: I mean, there is… there's some…

565
01:26:07.890 --> 01:26:11.249
stokes: comments here in the chat. But Paul, I think, was also an author. So

566
01:26:11.970 --> 01:26:14.310
stokes: I hope they'd be in favor.

567
01:26:19.250 --> 01:26:23.350
stokes: Okay, then let's DFI this. But yeah, thank you for that.

568
01:26:25.050 --> 01:26:33.850
stokes: Okay, next up, then, we have 7716. This is anti-correlation attestation penalties.

569
01:26:34.450 --> 01:26:39.170
stokes: Again, not… Yeah, okay.

570
01:26:39.370 --> 01:26:41.220
stokes: I think my mouse just died.

571
01:26:41.520 --> 01:26:47.020
stokes: Sorry about that. But yeah, go ahead. I was going to see who…

572
01:26:47.020 --> 01:26:47.460
Oisin Kyne: and.

573
01:26:47.460 --> 01:26:49.770
stokes: But yeah, go ahead.

574
01:26:49.770 --> 01:26:56.009
Oisin Kyne: Yeah, I'm champing and would share a screen if we had permission, but I think I was declined.

575
01:26:57.570 --> 01:27:17.099
Oisin Kyne: This EIP is a proposal to add, an increase to inactivity penalties the more people are offline. We already have this with slashing, it's meant to kind of disincentivize centralization, but we've never seen a correlated slashing penalty live on mainnet.

576
01:27:17.100 --> 01:27:21.779
Oisin Kyne: this EIP is… Relatively mild in terms of what it,

577
01:27:21.820 --> 01:27:32.279
Oisin Kyne: does, it increases the inactivity penalty by a max of 256, and there's a rolling average that means it's kind of bounded in terms of how long it can stay increased for.

578
01:27:32.350 --> 01:27:39.110
Oisin Kyne: I'll drop a link in the chat to a calculator so people can kind of give it a feel and see the FAQs and stuff.

579
01:27:39.330 --> 01:27:43.019
Oisin Kyne: The, you know, main arguments in

580
01:27:43.020 --> 01:28:00.680
Oisin Kyne: opposition to it, for the most part, has been either, like, let's just do PQ, I want to DFI everything that's not post-quantum, or Teku expressed a little bit of hesitance to touch beacon state. It is just adding one extra integer there, but they were like, beacon state is, you know, not super fun to touch.

581
01:28:00.930 --> 01:28:07.100
Oisin Kyne: But generally speaking, I think people are warm to the idea of encouraging

582
01:28:07.100 --> 01:28:30.449
Oisin Kyne: decentralization, but it's more of a question of, like, getting beyond B tier or something of the sort. So, my hope and ask for people today is that they say, like, yeah, I get that we're not jumping at the bit to kind of, you know, put in an SFI, but let's, you know, leave it as CFI for the coming weeks and see how we get along through the fork and say, okay, yeah, this is probably worth it. The EF are also gonna, like, put out some stuff about crops and things like that.

583
01:28:30.450 --> 01:28:32.220
Oisin Kyne: The problem, Barnabas, is that

584
01:28:32.220 --> 01:28:42.560
Oisin Kyne: We have probably some of the worst client centralization on the network since the kind of last 5 years of proof of stake. We've, I think, 3 different clients that, if they fail.

585
01:28:42.560 --> 01:28:55.829
Oisin Kyne: will cause a liveness issue, and if they fail together, like in Hoodi or in Holesky, we could have the worst-case scenario of, like, you know, the whole thing is screwed. But if we have liveness penalties, the idea is that will push people to

586
01:28:55.830 --> 01:29:02.710
Oisin Kyne: Take in more of the, like, longer tail clients, and not be so overexposed to the most popular ones.

587
01:29:02.710 --> 01:29:15.489
Oisin Kyne: It also impacts for, like, hardware, too, of not being all in the same data center. We have 5-10% of the network in OVH and Hetzner in certain data centers, so this would discourage that whenever they have liveness issues, which is occasional.

588
01:29:19.070 --> 01:29:20.730
stokes: Yeah, thanks.

589
01:29:20.850 --> 01:29:25.290
stokes: You mentioned slides. If you could keep it to, like, 2 minutes, I think I just have to.

590
01:29:25.290 --> 01:29:26.570
Oisin Kyne: Yeah.

591
01:29:27.380 --> 01:29:29.990
stokes: Okay, but yeah, let's just be mindful of the time.

592
01:29:30.840 --> 01:29:32.050
Oisin Kyne: That will do.

593
01:29:34.610 --> 01:29:37.179
Oisin Kyne: Can people see this?

594
01:29:37.490 --> 01:29:38.400
stokes: I can, yeah.

595
01:29:39.530 --> 01:29:51.479
Oisin Kyne: Sweet. Okay. I won't show too long. This is the one you can mess with what client you are. A common question is, well, what if I recover more slowly than, like, kind of the enterprises that can recover faster?

596
01:29:51.520 --> 01:30:10.669
Oisin Kyne: how the EIP works is once you come back under the moving average, you go back to normal penalties. So what that means for a slow responder is, you know, the longer you take to return, more likely it is you're close to today's rules. So relatively speaking, you know, it's actually more favorable to, you know, the small and solo stakers versus the others.

597
01:30:10.820 --> 01:30:26.850
Oisin Kyne: And this is kind of the main reason why. It's… if we, you know, turn up the liveness penalties, we go from the tiny blue dot you barely can't see to the orange dot in terms of penalties, and it's meant to discourage the slashing outcome, which would be, you know, pretty catastrophic, even if we are up to 10-20% of stake.

598
01:30:27.170 --> 01:30:37.970
Oisin Kyne: on the last, kind of, 4 major liveness bugs we had, it doesn't do a whole load. It, like, changed your amount of hours to earn back what you missed to, kind of, 20 hours to 4 days.

599
01:30:38.200 --> 01:30:46.280
Oisin Kyne: And this talks a bit about what clients can fail and the total slashing, you know, how it works for solo stakers, FAQ, etc.

600
01:30:50.360 --> 01:30:54.309
stokes: Alright, thanks. Yeah, and this is the link that you put here in the chat.

601
01:30:55.350 --> 01:31:00.110
stokes: So, yeah, thank you for the overview there.

602
01:31:00.600 --> 01:31:06.920
stokes: Any client teams want to speak in favor of this? I can put the Forkcast page back up.

603
01:31:07.550 --> 01:31:13.930
stokes: But ultimately, it was not rated super well. So I think that would lean DFI for Hegota.

604
01:31:14.600 --> 01:31:17.350
stokes: Any client teams want to add any color?

605
01:31:28.450 --> 01:31:36.310
Oisin Kyne: I would say got an S tier from ethrex. And naturally, all of the smaller clients have a bit of incentive to be more in favor of it because it, you know, hurts them less.

606
01:31:40.270 --> 01:31:45.579
stokes: Yeah, that's helpful, although ethrex won't be implementing the EIP, so…

607
01:31:45.580 --> 01:31:46.590
Oisin Kyne: No, fair.

608
01:31:46.590 --> 01:31:47.160
stokes: more.

609
01:31:47.160 --> 01:31:48.260
Oisin Kyne: As for the implementation, it is.

610
01:31:48.260 --> 01:31:48.670
stokes: the.

611
01:31:48.670 --> 01:31:57.650
Oisin Kyne: It is just like one variable in state and then the one pass through the validator list every Epoch to figure out, you know, if we're above or below.

612
01:31:57.840 --> 01:32:14.909
Oisin Kyne: moving average, so as to whether or not to scale the penalty. The EF protocol team kind of originally DFI'd it by saying it touched slashing, which it didn't. It's just a modifier to the existing inactivity penalty on a correct target and correct source.

613
01:32:15.630 --> 01:32:16.210
stokes: Hmm.

614
01:32:17.220 --> 01:32:18.900
stokes: Ben, quick comments?

615
01:32:18.900 --> 01:32:19.450
Oisin Kyne: you.

616
01:32:20.270 --> 01:32:23.939
Ben Adams: Yeah, this is, just another comment,

617
01:32:24.210 --> 01:32:30.610
Ben Adams: Related to, like, there was the discussion of changing emissions, which, we've

618
01:32:30.900 --> 01:32:41.099
Ben Adams: DFI'd. But I do think if we are… if we do do something like change emissions, then we should bring in these other things, like,

619
01:32:42.040 --> 01:32:46.120
Ben Adams: The… this penalty, and MEV burn, and all that sort of stuff.

620
01:32:49.170 --> 01:32:56.920
stokes: Okay, that sounds like a lot. It might be better to go piece by piece. But yeah, thank you.

621
01:32:57.790 --> 01:33:02.120
stokes: And yeah, Oisin, I think you were saying something, I cut you off. I don't know if you had another comment.

622
01:33:02.120 --> 01:33:03.460
Oisin Kyne: I was just gonna say that.

623
01:33:03.670 --> 01:33:11.220
Oisin Kyne: the EIP-7716 was implemented by ChainSafe and Lighthouse previously, before we slightly modified it, so it's not like…

624
01:33:11.370 --> 01:33:21.119
Oisin Kyne: crazy large by line count or anything. Probably the biggest implementation criticism is, yeah, it touches Beacon State, so that is a fair point. People don't love doing that.

625
01:33:23.480 --> 01:33:25.379
stokes: Any EL teams want to chime in?

626
01:33:26.260 --> 01:33:28.329
stokes: You've been awfully quiet on this one.

627
01:33:36.310 --> 01:33:38.410
Oisin Kyne: Is there anyone, like, actively…

628
01:33:38.530 --> 01:33:46.620
Oisin Kyne: opposed to it, or is it all just indifferent slash lower on the list? Like, I don't know if there's anyone that's strongly for opposition these days.

629
01:33:49.050 --> 01:34:03.129
Matthew Keil: Yeah, we do tend to like it. I don't think we necessarily want to see it DFI'd, but we're also kind of concerned about the amount of inclusion included EIPs in the fork.

630
01:34:03.390 --> 01:34:16.900
Matthew Keil: So it's something we'd love to see stick around, but maybe not be, obviously, SFI'd, you know, quickly. But we could, we could try to see it.

631
01:34:17.120 --> 01:34:19.659
Matthew Keil: You know, towards the end, if there's some more time.

632
01:34:22.190 --> 01:34:24.450
Oisin Kyne: Yeah, that's mostly my aspiration here.

633
01:34:29.750 --> 01:34:30.430
stokes: You're there.

634
01:34:30.800 --> 01:34:33.080
stokes: There was a comment here from Enrico.

635
01:34:33.280 --> 01:34:39.480
stokes: yeah, just echoing Ben's concerns that this might kind of open a can of worms of touching other stuff with it.

636
01:34:45.870 --> 01:34:50.730
Oisin Kyne: So if there's no one that's like actively feeling strong about DFI, can we leave it chug along?

637
01:34:51.610 --> 01:34:56.319
stokes: Well, I feel like we need consensus to CFI, right? I feel like the bar should be high.

638
01:34:58.930 --> 01:35:07.830
Łukasz Rozmej: My big concern is that no one would even notice the CAP until a big outage comes, which… but maybe that's enough.

639
01:35:08.640 --> 01:35:22.179
Oisin Kyne: I… you'd be surprised, I think, even if it's, like, on paper more punitive, people will care a bit more. I think people haven't bothered to optimize too much, because it's like, oh no, I can recover in 4 hours, and I lost…

640
01:35:22.480 --> 01:35:36.870
Oisin Kyne: 50 cents a validator versus, okay, I lost 50 bucks a validator. It's like, okay, I'll be a bit better. We see, like, a liveness issue kind of once or twice a year, whereas we never see a correlated slashing issue in the last five, which I think is a missed opportunity.

641
01:35:41.850 --> 01:35:47.060
Oisin Kyne: Consolidation Barnabe, it's, Oh, sorry, Alex, I just might…

642
01:35:47.060 --> 01:35:47.390
stokes: American.

643
01:35:47.390 --> 01:35:54.450
Oisin Kyne: Barnabé, but it's it's by ETH price. So it doesn't care if you're if you're consolidated or unconsolidated. It it's indifferent.

644
01:35:59.290 --> 01:36:06.029
Oisin Kyne: Sorry, ETH stake, Barnabas. So, like, you know, it just multiplies by how much ETH you have, not validator count.

645
01:36:10.020 --> 01:36:11.260
stokes: Yeah, just the amount of these.

646
01:36:11.700 --> 01:36:15.989
stokes: But yeah, that'll be inside. I do feel like the bar should be…

647
01:36:17.120 --> 01:36:21.800
stokes: we need strong support to CFI, not… you

648
01:36:21.940 --> 01:36:26.369
stokes: there's not… yeah, basically indifference, I think, should not be CFI.

649
01:36:26.880 --> 01:36:31.969
stokes: And I'm not hearing enough strong support, I think, to CFI this today.

650
01:36:40.170 --> 01:36:42.819
stokes: So… then I would…

651
01:36:43.210 --> 01:36:48.969
stokes: say, again, going off client team rankings and general opinions here, this is the DFI for today.

652
01:36:49.530 --> 01:36:51.810
stokes: Any ECL teams want to chime in?

653
01:36:54.210 --> 01:36:55.969
stokes: In favor of CFI in this?

654
01:37:06.470 --> 01:37:09.130
stokes: Then we'll DFI. Thank you, everyone.

655
01:37:10.730 --> 01:37:16.269
stokes: Let's see… I guess we'll just keep going here, although, yeah, we are…

656
01:37:16.640 --> 01:37:19.590
stokes: Getting towards time, so let's just be mindful of that.

657
01:37:20.930 --> 01:37:28.060
stokes: Next here on the list, 8205, withdrawal credentials pre-registration.

658
01:37:29.590 --> 01:37:33.309
stokes: Yeah, again, kind of mixed support here from the client teams.

659
01:37:33.580 --> 01:37:39.450
stokes: I believe this is… okay, yeah, George or Greg, are one of you on the call here today?

660
01:37:39.450 --> 01:37:53.010
Dima Gusakov | Lido: It will be me, even though I'm not mentioned as a champion. Though, I will occupy the rest of the call, because I was not expecting that you will reverse the order, so if you allow me, I will occupy the remaining 7 minutes. Is it okay?

661
01:37:54.660 --> 01:37:55.190
stokes: I.

662
01:37:55.190 --> 01:37:56.940
Dima Gusakov | Lido: It will not fit into.

663
01:37:56.940 --> 01:37:59.250
stokes: Let's… let's see how it goes.

664
01:37:59.250 --> 01:38:03.359
Dima Gusakov | Lido: Okay, fair enough. Give me a second to find the right presentation for it.

665
01:38:04.300 --> 01:38:06.040
Dima Gusakov | Lido: There he goes…

666
01:38:06.190 --> 01:38:06.780
stokes: Oh, you're right.

667
01:38:06.780 --> 01:38:07.210
Dima Gusakov | Lido: thing.

668
01:38:07.210 --> 01:38:09.069
stokes: I need to stop sharing then.

669
01:38:09.750 --> 01:38:13.450
Dima Gusakov | Lido: Yes, please, if it's possible. Perfect.

670
01:38:13.960 --> 01:38:15.230
Dima Gusakov | Lido: Okay…

671
01:38:15.630 --> 01:38:26.519
Dima Gusakov | Lido: Okay, okay… Let's go. I was not preparing for 7 minutes, but I'll try to do my best. So, withdrawal credentials, pre-registration, EIP-8205.

672
01:38:27.550 --> 01:38:37.660
Dima Gusakov | Lido: what's the problem we're solving here? The problem is simple, known for anyone, for anyone involved in Ethereum, has been with us since the inception of Beacon Chain.

673
01:38:37.740 --> 01:38:50.789
Dima Gusakov | Lido: Within delegated staking, if you have a node operator and a delegator, node operator can basically rug the delegator by front-running the deposit made by delegator with the data provided by node operator.

674
01:38:50.790 --> 01:38:57.780
Dima Gusakov | Lido: by simply putting one ETH deposit in front of the delegator deposit, but with.

675
01:38:58.080 --> 01:39:08.430
Dima Gusakov | Lido: its own withdrawal credentials. It's… it has been 32 ETH back in the day, now it can be even more if we are talking about 0x02 validators. But…

676
01:39:08.540 --> 01:39:11.320
Dima Gusakov | Lido: Let's assume for clarity that it's 32 ETH.

677
01:39:11.400 --> 01:39:13.139
Dima Gusakov | Lido: Okay, the problem is clear.

678
01:39:13.140 --> 01:39:34.069
Dima Gusakov | Lido: What's the scale of the problem? And here, for those of you specific lovers of saying that Ethereum is staked by the same person, like you own Ethereum and your own validator key, well, I have bad news for you guys. The majority of Ethereum is staked via delegated systems, and these are the numbers that are

679
01:39:34.070 --> 01:39:41.560
Dima Gusakov | Lido: From the confirmed protocols that are using some sorts of declared protection measures against this vulnerability.

680
01:39:41.600 --> 01:40:02.570
Dima Gusakov | Lido: And I take my word, the real number is, like, 70 or maybe 80% of all Ethereum stake. It's just participants like Coinbase, Binance, Bitmine, they are not declaring the ways how they protect from this vulnerability, but this vulnerability exists and impacts all of them. So, the majority of Ethereum stake is impacted.

681
01:40:03.430 --> 01:40:11.510
Dima Gusakov | Lido: And now let's look at the current solutions. Again, this well-known and declared solutions, other than just doing something off-chain or

682
01:40:11.890 --> 01:40:14.780
Dima Gusakov | Lido: standing with a solder iron next to your DevOps.

683
01:40:14.920 --> 01:40:27.799
Dima Gusakov | Lido: So, there are two main solutions here. One is bond or pre-deposit, the other one is off-chain guardian. Since we are running out of time, I guess you both know that pre-deposit is just make one ETH pre-deposit, wait for the validator to appear, if all good.

684
01:40:27.800 --> 01:40:41.119
Dima Gusakov | Lido: make the remaining deposit with Guardians, you check the deposit root. If all the deposits as of the deposit root are good and there are no front runs, you can make your own deposit, checking on-chain that the current deposit root

685
01:40:41.120 --> 01:40:44.850
Dima Gusakov | Lido: Actually matches the one that you already checked.

686
01:40:45.350 --> 01:41:00.260
Dima Gusakov | Lido: Both of the solutions comes with the price. The first one with pre-deposit comes with the price of the double the entry queue for the majority of your stake. So basically, by doing that, you first of all need to find this pre-deposit. You should either sacrifice your

687
01:41:00.260 --> 01:41:11.319
Dima Gusakov | Lido: 1 ETH from your protocol, or from your, from you as a provider, or you should take it from your node operator, like in cases of, Lido ST Vaults, Rocketpool, or many other protocols.

688
01:41:11.320 --> 01:41:15.950
Dima Gusakov | Lido: In case of off-chain guardians, I don't need to explain that. It's very simple. If you have

689
01:41:15.970 --> 01:41:23.629
Dima Gusakov | Lido: like, staking infrastructure, which is the core infrastructure of Ethereum relying on off-chain trust, this is definitely not the best solution in the world.

690
01:41:24.320 --> 01:41:35.699
Dima Gusakov | Lido: And the problem is that even though there are two main types of the solutions, like all of the protocols that you can see on the screen, and many more, they have their own bespoke implementations, like most of them.

691
01:41:35.700 --> 01:41:49.700
Dima Gusakov | Lido: Which means that the same problem is solved, like, multiple, multiple, multiple, multiple times on application layer. And yes, you might say that, well, this is a problem of application layer, but at the end of the day, what Ethereum is without its application layer.

692
01:41:50.210 --> 01:41:56.480
Dima Gusakov | Lido: So what's the solution? The solution is very simple. Like, the validate… there should be a way to…

693
01:41:56.990 --> 01:42:05.890
Dima Gusakov | Lido: Agree beforehand that the validator, this validator withdrawals should go to this address.

694
01:42:06.130 --> 01:42:30.949
Dima Gusakov | Lido: And how it's achieved within this EIP? Pretty simple, in three steps. First of all, you sign the commitment where you say that this public key should have this withdrawal credentials. No race with money at stake, like it is now, when you need to actually make a deposit and then hope that everything goes well, or… and you might lose this money. No, you are not putting any money at stake here, you just sign the commitment, you submit it using a system contract on execution layer.

695
01:42:30.950 --> 01:42:37.780
Dima Gusakov | Lido: Same way as 7002 and 7251 or any other EIP that is using system contract right now, and we have plenty of them.

696
01:42:37.780 --> 01:42:52.060
Dima Gusakov | Lido: And then, when you make a deposit, you can prove via 4788 that the preregistration exists, and you have a guarantee that whenever you make a deposit, your validator would appear with correct withdrawal credentials.

697
01:42:52.480 --> 01:43:10.760
Dima Gusakov | Lido: Perfect. What's from the implementation side? And even though you might think, oh, this problem has been with us for so long, so the solution must be super complicated, it is not. On execution layer, we just need a pre-registration request contract. Again, very similar to what we already have for 7002 and 7251 and others.

698
01:43:10.770 --> 01:43:31.290
Dima Gusakov | Lido: And the code is ready, for sure, and the Lido is happy to pay for the audit if it's necessary. On the consensus layer, like, four basic operations, add pre-registrations to the Beacon state, add request processing, remove expired pre-registration so that the state would not bloat, and add extra check on deposit processing as… and that is it. That simple.

699
01:43:31.610 --> 01:43:43.989
Dima Gusakov | Lido: So, who supports this EIP so far? We've been in talks with many protocols, many application layer participants, many security researchers, and these are just the examples of those who voice their support the loudest.

700
01:43:43.990 --> 01:44:02.509
Dima Gusakov | Lido: And I'm not quite sure, like, what should be the correct argument for the EIP to make it through, but if you have, like, major staking protocols here on the screen supporting the EIP, if you have L2BEAT saying that this is what is actually necessary, then I have no idea what's the better argument here.

701
01:44:02.740 --> 01:44:06.810
Dima Gusakov | Lido: There is also a support from Solo Stakers on HapEVA.net.

702
01:44:06.870 --> 01:44:30.389
Dima Gusakov | Lido: And now the final question, why Hegota, why not later? Because this is a good argument to always say, oh, let's put it to the other hard fork. Well, ISTAR Hard Fork will be fully packed with post-quantum migration, and I take my word, you guys will never accept this EIP for ISTAR Hard Fork, because you all will be incredibly busy, as well as we will be, with supporting this post-quantum stuff on the application layer side.

703
01:44:30.420 --> 01:44:42.220
Dima Gusakov | Lido: So, let's include it in Hegota. Scan the QR code on the screen, or go to EIPA205.com if you want to learn more about that, and that was it. And I made it right in 7 minutes. Thank you all.

704
01:44:46.060 --> 01:44:49.259
stokes: Yeah, thanks for the slides.

705
01:44:49.880 --> 01:44:53.970
stokes: Yeah, okay, we are at time, but I feel like we should just try to…

706
01:44:54.990 --> 01:45:04.980
stokes: Well, let's see. I think if there's, you know, much more discussion here, then it's probably best just to wrap up, but yeah, let's take a few minutes and try to see where we can get.

707
01:45:05.460 --> 01:45:07.710
stokes: Yeah.

708
01:45:07.910 --> 01:45:13.980
stokes: So… I don't know. There were some comments here. Barnabas Lion.

709
01:45:14.920 --> 01:45:16.320
stokes: Nico here.

710
01:45:18.840 --> 01:45:20.319
stokes: Maybe that's unrelated.

711
01:45:20.520 --> 01:45:22.139
stokes: But yeah.

712
01:45:22.840 --> 01:45:24.419
stokes: Or any other client teams.

713
01:45:25.450 --> 01:45:29.519
stokes: Again, I can pull up the Forkcast page…

714
01:45:31.330 --> 01:45:38.270
stokes: And let's see here. Yeah, okay, Teku was in favor, then otherwise, yeah, pretty mixed support.

715
01:45:45.440 --> 01:45:51.710
Dima Gusakov | Lido: Just to make it easier for client teams to make a decision here, again, the change itself Super simple.

716
01:45:51.730 --> 01:46:08.060
Dima Gusakov | Lido: like, we understand the way how hard forks work, and we understand that you guys don't want to put extra work in here. The thing is that all of the specs, tests, all of the stuff, like, everything that could have been done other than the actual client development is already done. The problem is real.

717
01:46:08.060 --> 01:46:16.810
Dima Gusakov | Lido: And the solution is indeed simple. So DFIing it right now would basically mean ignoring the problem that has been with us for 5 years.

718
01:46:16.810 --> 01:46:41.180
Dima Gusakov | Lido: When the solution is actually here, almost on the plate, very simple, and within future, like, if you guys are thinking about post-quantum and the post-quantum deposit contract, yeah, for sure, it might have a fix for it, but if we will reject this EIP now, then the likelihood of it being fixed in post-quantum deposit contract is very low, because there are a lot of other problems to be solved there.

719
01:46:41.230 --> 01:46:51.719
Dima Gusakov | Lido: And by having that, we are explicitly mentioning that we are reasonable people, and we do not want to have issues, such long-standing issues as this one.

720
01:46:51.820 --> 01:46:53.550
Dima Gusakov | Lido: Within our base there.

721
01:46:53.930 --> 01:46:59.630
Dima Gusakov | Lido: So, I hope, there is enough arguments to make a clear decision here.

722
01:47:01.190 --> 01:47:07.039
stokes: Yeah, one quick question, have you talked to EL teams about… because there is a system contract, right?

723
01:47:07.480 --> 01:47:24.269
Dima Gusakov | Lido: The system contract, yes, we talked to EL teams, and we talked to the guys, like, the system contract is almost apples to apples to what we already have, so there is no rocket science here. And again, the only concern that has been voiced is that this contract should be audited. We are ready to pay for the audit.

724
01:47:28.050 --> 01:47:33.380
stokes: Yeah, meditationduck. And then Tomer, if you have brief comments.

725
01:47:34.350 --> 01:47:45.569
meditationduck: Yeah, we, we are from ACK3, we support this because its strength dedicated staking deposit. One concern is that.

726
01:47:45.790 --> 01:47:53.180
meditationduck: Like, all protocol, all dedicated staking protocol need to.

727
01:47:56.800 --> 01:48:06.459
meditationduck: See the… Need to… adopt this protocol, adopt this EIP, but that's the only concern.

728
01:48:10.910 --> 01:48:12.320
stokes: Great. Tomer?

729
01:48:12.980 --> 01:48:21.589
Tomer Ganor: Yes, I'll make it shortly, I know we're tight on time. I just want to say that from security perspective, in my opinion, it's very, as Dima said, it's very simple, and…

730
01:48:21.700 --> 01:48:28.280
Tomer Ganor: simplify, I mean, it simplifies a lot the security of Lido and other liquid staking protocols in this… in this context.

731
01:48:28.350 --> 01:48:41.409
Tomer Ganor: For what, been said in the chat about 0x2 solve this problem, or just migrate to 0x2, I just want to say, even if you migrate to 0x2, great, so now you have less validators, but you still want to withdraw it from your validators.

732
01:48:41.410 --> 01:48:59.549
Tomer Ganor: for example, in Lido, if you want to exit, you need to withdraw the ETH from the validator, it exits, now you want to add new money, new ETH to Lido's validators, you run out of place, you need to deploy new validators. So this doesn't solve the problem. It maybe narrows the use case of entering new validators, narrows the usage, but it doesn't solve it.

733
01:48:59.550 --> 01:49:07.319
Tomer Ganor: So, from security perspective, I think it simplifies a lot, a lot of the assumptions, the workarounds needs to be done, and a lot of liquid staking protocols to deal with this.

734
01:49:07.470 --> 01:49:17.370
Tomer Ganor: Honestly, the first time I learned about this behavior, I thought this is, like, insane, like, the fact that you can do this, race of who deposits first.

735
01:49:17.520 --> 01:49:30.229
Tomer Ganor: And I was surely… I was confident that this will be resolved already, so I'm happy this is proposed to be resolved now, but really, it simplifies a lot of things, and Lido, I think, offers

736
01:49:30.340 --> 01:49:37.590
Tomer Ganor: And the solution they offer is very, very simple, and I think we should do it before the post-quantum changes.

737
01:49:38.870 --> 01:49:39.690
Tomer Ganor: Thank you.

738
01:49:40.970 --> 01:49:41.939
stokes: No, thank you.

739
01:49:44.040 --> 01:49:45.000
stokes: Okay.

740
01:49:45.540 --> 01:49:53.330
stokes: It looks like Enrico's dropping, although I think he was one of the client teams, at least one of the, yeah, core Devs in support of this.

741
01:49:53.630 --> 01:50:01.399
stokes: Because we did get a strong ranking from Teku. But yeah, I guess it'd be good to hear from other client teams who haven't chimed in yet.

742
01:50:03.640 --> 01:50:12.350
Matthew Keil: I don't understand why the importance of doing this when there's already existing app layer solutions and

743
01:50:12.790 --> 01:50:18.799
Matthew Keil: It's gonna take a lot of effort from a lot of teams to get it implemented when it's already

744
01:50:19.230 --> 01:50:23.179
Matthew Keil: solved. Like, the problem is already resolved at the app layer.

745
01:50:23.600 --> 01:50:33.449
Dima Gusakov | Lido: It is… yeah, well, it is… it is solved, but the… every time something is changing on the consensus layer, the solutions have to be maintained.

746
01:50:33.850 --> 01:50:37.159
Dima Gusakov | Lido: Like, imagine that you have solved the problem.

747
01:50:37.160 --> 01:50:49.770
Matthew Keil: Same with the protocol layer, like, that's… that… I mean, we've already talked about, you know, granted in different contexts where different EIPs have to play in with new EIPs, and every single time you…

748
01:50:49.920 --> 01:50:59.679
Matthew Keil: implement something at the protocol layer, it forces a rethought of that same EIP as other things are integrated with the same

749
01:51:00.230 --> 01:51:18.010
Matthew Keil: touching the same, parts of state, or the same part of the protocol, and I don't see this as being different than that. And to be honest, and really my only concern, it's not even so much the complexity of the implementation, because it's not… we did look at it, it's not…

750
01:51:18.170 --> 01:51:33.039
Matthew Keil: it's not a huge burden, it's probably, like Justin Traglia said, it's probably a medium effort, but there are gonna be downstream effects, and it only, affects a portion of the network, and it feels

751
01:51:33.230 --> 01:51:36.300
Matthew Keil: Partially from a precedent perspective of.

752
01:51:36.470 --> 01:51:40.579
Matthew Keil: When there's so much stuff that needs to be included in the core protocol.

753
01:51:40.750 --> 01:51:53.699
Matthew Keil: to be programming around specific use cases or specific, stakeholders, which I… not to discredit how important you guys are, because, like, I do want to say that out loud, is, like, we do appreciate

754
01:51:53.980 --> 01:52:03.050
Matthew Keil: the importance of you guys on the network and the good work you guys do. The problem comes in, though, is that there's a lot of…

755
01:52:03.160 --> 01:52:14.050
Matthew Keil: To use a bad, or to say a cheesy phrase, but there's a lot of mouths to feed when it comes to different use cases, and really, the core protocol

756
01:52:14.780 --> 01:52:20.220
Matthew Keil: It feels like we need to focus on the core protocol.

757
01:52:20.350 --> 01:52:33.560
Matthew Keil: And then as time, comes up, we can start to think about some of these other, you know, more limited use cases, which have a much smaller stake.

758
01:52:33.910 --> 01:52:50.540
Matthew Keil: stakeholder pool, that they benefit. And that really is the part that I think is the most important part of the governance protocol, or the process, is making sure that we're targeting and focusing protocol development at the, you know.

759
01:52:50.540 --> 01:52:58.730
Matthew Keil: at the core protocol level towards things that'll benefit all users and the core protocol itself.

760
01:52:59.370 --> 01:53:21.849
Dima Gusakov | Lido: You're absolutely right, and I'm fully with you, and I'm very happy that whenever I open my mouth, you guys think that anything that people from Lido can propose benefits Lido. But I explicitly mentioned in the presentation that ask any staking protocol that exists on the network, like EtherFi, RocketPool, whoever else.

761
01:53:22.190 --> 01:53:38.029
Dima Gusakov | Lido: All of them are using delegated staking, and this is the core. If it was only for Lido, I would not have been here and would never propose something that benefits only Lido. The thing is that ConsensusLayer is about staking, and the majority

762
01:53:38.030 --> 01:53:45.490
Dima Gusakov | Lido: of all Ethereum staked is staked in a delegated way. And this problem affects each and every

763
01:53:45.650 --> 01:53:58.159
Dima Gusakov | Lido: person, protocol, product, whatever, that does delegated staking. So, I think that your assumption about the level of impact, and about how wide the

764
01:53:58.160 --> 01:54:12.890
Dima Gusakov | Lido: variety of clients and how much of actual Ethereum staked is involved is definitely off, because the right assumption here, and the right estimate here, is that the absolute majority of Ethereum is staked in a delegated way.

765
01:54:12.970 --> 01:54:24.590
Dima Gusakov | Lido: So, I really want to stress that this EIP does not solve particular Lido issue. It solves the issue that each and every staking protocol has to solve on their side.

766
01:54:24.590 --> 01:54:39.830
Dima Gusakov | Lido: And there are tons of them. Like, if you just take the most well-known one, you will already have 5 or more. And I'm not speaking about, again, those who are not declaring how they deal with this issue, but they all have to deal with it, unfortunately.

767
01:54:40.000 --> 01:54:47.529
Dima Gusakov | Lido: True. And I fully understand that anything that is just for Lido should not be in the core protocol, but this is not just for Lido.

768
01:54:47.760 --> 01:54:52.220
Matthew Keil: And it's not so much that I say just for Lido, it's more of.

769
01:54:52.420 --> 01:55:04.110
Matthew Keil: Like, there's a lot more… there's many more stakeholders than just people who are staking, and while that is a very important function in order to get the chain

770
01:55:04.210 --> 01:55:12.170
Matthew Keil: Doing what it needs to do. There's a lot of other things, at the application layer that are not related to staking.

771
01:55:12.520 --> 01:55:22.590
Matthew Keil: And that's really, I think, where I think a lot of the sentiment, at least for some of the people that we've spoken with, because we did talk to a couple of other teams about this.

772
01:55:22.740 --> 01:55:25.829
Matthew Keil: And also within our own team, and…

773
01:55:26.170 --> 01:55:28.809
Matthew Keil: You know, that… and it's not that we don't…

774
01:55:29.290 --> 01:55:41.289
Matthew Keil: take the situation seriously, but there is gonna be, as a number of other people like Potuz and kingy had mentioned, there's gonna be a lot of work done when PQ comes in.

775
01:55:41.500 --> 01:55:45.639
Matthew Keil: Literally in the next fork, we're going to start looking at PQ keys. So it's…

776
01:55:46.830 --> 01:55:49.989
Matthew Keil: You know, it just feels like it might be better to solve it

777
01:55:50.100 --> 01:55:56.560
Matthew Keil: Solve it there once, instead of solve it now, and then have to reinvent the wheel again.

778
01:56:01.490 --> 01:56:05.729
stokes: We should wrap up. But thank you everyone for the discussion.

779
01:56:06.380 --> 01:56:16.009
stokes: And, yeah, I mean, I'll just play back, what I'm hearing here from the different client teams, that, yeah, I mean, I think this is an important problem, but also…

780
01:56:16.230 --> 01:56:19.699
stokes: Makes the most sense just to handle with PQ at this point.

781
01:56:20.510 --> 01:56:28.660
stokes: So, yeah, you know, I recognize there's a maintenance burden here for, you know, apps who touch this, and that's not ideal.

782
01:56:29.150 --> 01:56:35.569
stokes: But I also am not hearing support here to go ahead and CFI this today, so I would propose we DFI.

783
01:56:36.020 --> 01:56:41.720
stokes: And yeah, it does seem like a nice path forward here, then, is to take the work from here.

784
01:56:42.280 --> 01:56:46.610
stokes: jump into the PQ design and then settle this problem. Then.

785
01:56:51.150 --> 01:56:52.980
stokes: Yeah, Greg, final comment.

786
01:56:52.980 --> 01:57:00.640
Greg K | Lido: Yeah, so, because now I think we're running out of time, and also, yeah, there are still some open points. Could we just…

787
01:57:00.660 --> 01:57:13.949
Greg K | Lido: Yeah, leave it, like, the final decision for next call, because I don't think there is enough information now to just say that, like, at least this discussion that happened now, it doesn't sound like a DFI to me.

788
01:57:15.040 --> 01:57:28.679
Greg K | Lido: So, because, yeah, we were running out of time, it was just 7 minutes, we took some more time, but I think, yeah, it deserves a bit more discussion. Like, most of the EIPs discussed much more than this, so we can start next call from this one, right?

789
01:57:31.930 --> 01:57:33.320
stokes: Yeah, okay.

790
01:57:33.710 --> 01:57:35.590
stokes: Less defer this than today.

791
01:57:35.750 --> 01:57:44.889
stokes: We'll start next call with the greater scoping, we'll just come back to this. But again, yeah, in terms of time boxing, just so everyone's clear.

792
01:57:45.310 --> 01:57:52.390
stokes: Yeah, there will be a, you know, 5 minutes, I think, at most, to… Get back into this.

793
01:57:53.240 --> 01:57:54.759
stokes: Yeah, let's do it that way.

794
01:57:55.210 --> 01:58:00.660
stokes: And then we'll make a call, hopefully pretty quickly on the next call.

795
01:58:01.010 --> 01:58:06.029
stokes: And yeah, then we will do that, okay?

796
01:58:06.130 --> 01:58:12.669
stokes: Thanks everyone for staying over. But yeah, let's go and wrap up because we are quite over time today. So thank you.

797
01:58:15.850 --> 01:58:18.610
stokes: I'll go ahead and just say deferred. Yeah.

798
01:58:19.720 --> 01:58:21.670
stokes: Okay, thanks everyone. Goodbye.

799
01:58:23.680 --> 01:58:24.910
lightclient: Thanks, Alex.

800
01:58:25.320 --> 01:58:26.270
Potuz: Bye-bye.

801
01:58:31.390 --> 01:58:33.350
jochem-brouwer: You know… Fine.