Barnabas:Alright, let's get started. Welcome everybody to AllCoreDev's testing call, number 64.
Transcript
Barnabas:We have a packed agenda for today, so let's get started.
Barnabas:Regarding Fusaka, we had, last week BP01 going live, and it was a success, so congratulations to everybody participating in that.
Barnabas:And, is there any other open questions regarding Fusaka?
Barnabas:The only thing I can think of is, possibly BPO2, which is scheduled to go live on the 7th of January, which is, still, like, 3 weeks away from now.
Barnabas:But other than that, I think, Fusaka is pretty much done. We're gonna have some BPO discussion later on the call, but, for now, I think we can move on to Glamsterdam.
Barnabas:Okay.
Barnabas:Oh yeah, prison, had a post-mortem of, what happened in Fusaka during, like, right after the fort.
Barnabas:James, could you maybe just put it in the chat, and then everybody can, take a look at the…
Barnabas:blog post.
Barnabas:Or, I don't know, do you guys want to talk about it?
Barnabas:Oh, I guess not. Okay.
Barnabas:I think, I think we can move on to Glamsterdam again. So…
Barnabas:Stefan, maybe you can give us an update for DevNet1 or DevNet 0 updates?
Stefan Starflinger:Yeah, sure. So, we made some progress regarding the execution specters. There has been a release 2.0.
Stefan Starflinger:And, it would be great if clients did test against this new release. It came with a small spec change, where we use now the UNT256.
Stefan Starflinger:for storage keys and values, so a lot of the tests will initially be failing. You can start testing against a BAL Definite 0 branch, but it would be great if all the client teams could switch to a biodefinite 1 branch.
Stefan Starflinger:There's, in particular, one test that some clients have been saying they're failing is the out-of-gas self-destruct test, so it'd be great if
Stefan Starflinger:You could have a look. If you need any help with that, feel free to reach out.
Stefan Starflinger:And otherwise, it's just general stuff. I've also added it to the agenda.
Stefan Starflinger:Is Philippe here, maybe you would want to give an update also from the testing side?
felipe:Yeah, sure. Other than…
felipe:the UN256 changes, we added, quite a bit of…
felipe:Gas boundary tests for call-up codes.
felipe:So we should have more coverage there as well.
felipe:But yeah.
felipe:I think, everything else, went pretty smooth on the testing side.
Stefan Starflinger:Corvettes.
Stefan Starflinger:Then yeah, it's… we have a breakout call, on Wednesday, I think, for Baos, and we can discuss anything in particular there.
Stefan Starflinger:But otherwise, I think we're making good progress. I'd also like to remind people that it would be great to run kiosis tests with the EVM files, and just to make sure, leave it running for a while, just to make sure that the clients are working well in interop.
Stefan Starflinger:But otherwise, if clients might want to give a quick update where they're at right now, that would be great, or we could…
Stefan Starflinger:do it on Wednesday as well.
Stefan Starflinger:more detailed.
Karim T. (matkt):I can on the business side, so,
Karim T. (matkt):Today, we implemented several features, we… we merged, state fruit conclusion…
Karim T. (matkt):traditional background, thanks to Block Access List.
Karim T. (matkt):We are finishing the perfect parallelization with block access list. We just have to add some tests, but it's currently working, so I think we'll be able to merge the PR soon.
Karim T. (matkt):We don't have yet batch reading using block accesses, but it will not be too hard to implement it, so I think we'll have it also as soon as possible.
Karim T. (matkt):We have some failing tests, some tests regarding the call operation.
Karim T. (matkt):So we know how to fix that, we just didn't start it to work on it, and we fixed also a self-district,
Karim T. (matkt):issue, recently. So… Yeah, accepting that, we started the BaldurNet1 branch, we merged all of the different fixes.
Karim T. (matkt):And, we also updated the slot key and values format in this branch, so…
Karim T. (matkt):Normally, it should be okay for the next run.
Barnabas:That's great. Is there any other ELs that could give us an update?
Barnabas:About their progress?
Marc:Yeah, for NetherMind, at the moment, I'm focused on the parallel transaction execution and, state route computation.
Marc:So, made some good progress on that, and I just need to, do a few updates related to this, new testing release.
draganrakita:From Redside, we made change to, storage, making from the… B256 to number.
draganrakita:Started work on the… using BAL on the state route, and talking about BAR, how to do it parallel.
draganrakita:How to do parallel education.
draganrakita:I have run, 2.0 tests today, and had one bug to self-destruct, and…
draganrakita:out gas that I fixed.
Barnabas:Thank you. Anyone else?
Barnabas:Anyone maybe from gas could speak up?
Barnabas:Okay, is there any… yup.
milen | Erigon:Yeah, hey, I can give a quick one for, Aragon,
milen | Erigon:We, just created the boudevNet branch and, joined the Hive tests. I think we have a bunch… a bunch of failure to go through.
milen | Erigon:And, yeah, we also have…
milen | Erigon:One other person working on, parallel execution, which also should be enabled by default on that branch.
milen | Erigon:So yeah, I think we're just gonna go through the tests, through the remaining test failures next week, and yeah, that's about it.
Barnabas:Okay, thank you. Do we have any other ELs that would like to give us on that?
Barnabas:In case not, then I will just, pass the word to Justin. He has a few proposals for EPBS.
Justin Traglia:Yep. Hello, everyone.
Justin Traglia:Yeah, so for EPBS, I guess the first thing we should talk about is probably,
Justin Traglia:the change to builders that we want to make. So, like, we want to change
Justin Traglia:builders so that they're not validating entities. This simplifies things quite a bit.
Justin Traglia:Faster deposits, instant top- like, instant top-ups,
Justin Traglia:Lots of other simplifications, but essentially this moves…
Justin Traglia:Builders from the validators list in the state to a new builders list.
Justin Traglia:Just asking client teams and everyone to review it, see if we all agree.
Justin Traglia:There's two different proposals for how we can do it. It seems that the second option is the most popular, so that's the one we'll probably go with.
Justin Traglia:It's just a term, like…
Justin Traglia:Simplicity versus, like, lots of changes, yeah, regarding the pub key. Like, whether or not we should update the withdrawal structures to include a pub key, or just to reuse the validator index field.
Justin Traglia:How do client teams feel about this?
Barnabas:Maybe someone from PRISM gonna comment on it?
Justin Traglia:That's a good question, Mario.
Justin Traglia:I mean, there's multiple different ways we could bootstrap this, or sorry, there is a way we could bootstrap this, I'm not sure if it's a good idea, though, but we could have 0x03 validators before the fork, and then at the fork, they are converted to the new builder type.
Justin Traglia:That's one option.
Justin Traglia:Or we just require builders wait one epoch before…
Justin Traglia:submitting bids so that they can create the builders. Like, it would be almost instant to create a new builder, and the minimum,
Barnabas:It would be too.
Justin Traglia:The minimum stake amount would be 1 ETH as well. What is it, Barnabas?
Barnabas:You mentioned, last week that it would be around 2 epochs to process a new builder, so if we have a fork transition, then we would basically go without
Barnabas:Without builders for 3 epochs, right?
Justin Traglia:Something like that, yeah.
Justin Traglia:Unless we do the bootstrapping, idea. And I think POTUS is in favor of that. It's just…
Justin Traglia:I'm personally not. I think it's kind of complicated.
Barnabas:I mean… we had 0x02 editors also going online before the fork of Spectra.
Barnabas:So why would…
Justin Traglia:Yeah.
Barnabas:Why would this be a problem?
Justin Traglia:So there's a property I want to maintain that…
Justin Traglia:There can't be a validator and a builder with the same pub key in the state.
Justin Traglia:Just for simplicity, that way you can, like.
Justin Traglia:Know that if you're given some pup key, you can look it up in one or the other, and know that they don't exist in both.
Justin Traglia:If we do the conversion, you would essentially have
Justin Traglia:Sorry, you would have a pub key in both, and I just don't like that.
Justin Traglia:Does that make sense?
Barnabas:Yep, it does.
Barnabas:Is there a breakout this Friday?
Justin Traglia:There is indeed. I can share a link just in just a second.
Barnabas:So, it would be very, very, very good if you could make a final decision on this by, this week's breakout.
Barnabas:And, I can go off to the holidays with,
Barnabas:the firm decision. I didn't really make the decision even before that, but I saw that, for example, Lighthouse didn't have time to take a closer look yet, so…
Barnabas:I would like to have a deadline on that for the breakout room.
Justin Traglia:Agreed.
Barnabas:Enrico?
Enrico Del Fante (tbenr):Just a very quick question. I was not looking into the details, but one question I had…
Enrico Del Fante (tbenr):In my mind is, if we go in that direction, does it mean that, like, any normal validator that wants to submit bids of the network are actually cut off?
Enrico Del Fante (tbenr):So, you… you won't be validating.
Justin Traglia:They would be cut off, yeah.
Enrico Del Fante (tbenr):So, like, a thing that, like, Potos is saying, always saying that, my node running at home will always submit beats, that, that's not true anymore.
Enrico Del Fante (tbenr):So, you have to have a different…
Justin Traglia:Correct.
Enrico Del Fante (tbenr):Okay.
Justin Traglia:I mean, you would just have to have, like, a…
Justin Traglia:Another note at home with one ETH.
Enrico Del Fante (tbenr):And, well, depends by where we land in terms of capital, minimal capital.
Enrico Del Fante (tbenr):Just to enable building, so if we go with higher… If required.
Justin Traglia:Yeah.
Enrico Del Fante (tbenr):Then this would become capital inefficient.
Justin Traglia:Agreed. Yeah, we can discuss that more later, but currently it's, 1 ETH is the minimum.
Justin Traglia:But you're right, it does break that,
Justin Traglia:That was nice that any validator could submit a bid.
Enrico Del Fante (tbenr):Yep.
Enrico Del Fante (tbenr):I was personally… personal liking it.
Justin Traglia:Any other top… sorry, any other, Points on the builder's change.
Justin Traglia:Okay, there's a different topic I'd like to discuss then, too.
Justin Traglia:the proposer preferences gossip topic suggestion that I, am wanting to make.
Justin Traglia:Essentially, we need a way to convey to builders the fee recipient and gas limit, and whether or not they accept trusted payments. And I think the best way to do that is via a new gossip topic.
Justin Traglia:What is it now? The epoch before the…
Justin Traglia:Proposal. Proposers would submit their preferences to the topic.
Justin Traglia:So yeah, just… 32 proposer preferences per epoch.
Justin Traglia:So it's a pretty minimal, topic without, like, a lot of traffic.
Justin Traglia:Have clients had time to review this one? Or… Do people have ideas?
Justin Traglia:Thoughts?
Bharath:I have one thought, like, so, I think recently, you added a field,
Bharath:To… to signal that the proposal will accept a trusted payment.
Bharath:I'm unsure if that should be on the gossip topic, because
Bharath:I would assume, like, the proposer would, what is that?
Bharath:you have a set of builders you trust, right? Because there's a risk here, like, the builder could say, I…
Bharath:could signal an execution payment with the bid, but can choose to, like, not do it, and there's no easy way to verify that, so…
Bharath:I would assume the proposer would want to, like, be like, okay, I trust Builder A, B, C, but I don't trust D.
Bharath:So, I would assume this should be more granular, is my take.
Justin Traglia:Possibly, yeah.
Bharath:Yeah, so… yeah, that's where, like, I am just evaluating, like, maybe validated registrations might be the place, because there you could kind of, like, be more granular in, sending per-builder preferences.
Justin Traglia:validator registrations with… with who? Like, the trusted builders out of protocol builders, whatever they're called?
Bharath:Yeah, no, no, I mean, like, you anyways have the URLs of the…
Bharath:So, like, to… let's say that you have a builder API, you anyways are going to have the URLs of the builders in one way or the other. You either have your own whitelist, or you fetch it from somewhere. You kind of know, okay, this is the builder, this is… this builder A, this is builder B, and through that, you're able to, like, okay, I don't trust this builder, I don't trust that builder, or I trust this builder.
Bharath:So, that's, like, in an initial thought right now, then.
Justin Traglia:I'm confused how the registrations part works. Do you send your registration to each individual builder, like, in Epoch before the proposal, or how would that work?
Bharath:Yeah, that's the idea. I mean, like… like, today, I think, on an epoch boundary, we send the registrations, so I would assume, like.
Bharath:This definitely has to be more thought out, and, like, I'm working on, like, writing more down here, but the initial thought is, like.
Bharath:On the epoch boundaries, when, you're sending a validated registrations, you… you take a design… you take a call, okay, like.
Bharath:I know I'm gonna send to this builder, I probably, like.
Bharath:I want to accept, like, a trusted payment from them, or not.
Bharath:But yeah, that's just the high thought, like…
Justin Traglia:Okay. Yeah, I mean, I don't have to think about it more, I don't know.
Bharath:Yeah, we can, like, take it out on the channel, like, yeah.
Justin Traglia:Cora.
Justin Traglia:I don't like the current way validator registrations work with relays, like, where each validator sends a registration regardless of whether or not they're proposing. It's kind of messy and inefficient, so… I feel that this gossip topic solves a big problem.
Bharath:It does, it does, like… I think it's just, like, the question is, like, do we want, like, per builder preferences? The gossip topic is great for, like, communicating, like, a global preference with, like, the fee recipient and gas limit, that totally makes sense, but…
Bharath:Like, maybe once you want, like, a per-builder, like, preference, like, I don't know, I'm just, like, putting it out, like, like, something like,
Bharath:like, min-bit doesn't make sense, but I don't know, I can't get anything in my head right now, but some up top, some, like, you know, per builder, like, preference, like, if you want. I don't know if the gossip topic is the best way to communicate it.
Bharath:Because that's on a global… But yeah.
Justin Traglia:Okay, yeah, we can discuss that more.
Bharath:Yeah, yeah, no, but off-cost, sure.
Justin Traglia:Offline. Palan, yes, but I just added a, accept… sorry, Trusted Payments Accepted field, because, we were discussing it in the EPBS channel on the Ether R&D Discord.
Justin Traglia:It's just a Boolean. If people don't like that, I can remove it.
Justin Traglia:Yep.
Justin Traglia:Thank you.
Justin Traglia:And, I guess that's it for me for EPBS.
Justin Traglia:Maybe just more client updates or something.
Bharath:I can give, like, a small update, like, I've been working on, like, just, like, starting to spec out the builder specs.
Bharath:thinking about, like, our documents, we've been thinking about,
Bharath:how the builder API will look for staked and unstaked builders. Unstaked builders probably, with the 1 ETH, like, change, like, where we reduce the stake to 1 ETH, I… I'm pretty doubtful we… we will have unstaked builders.
Bharath:We could, like, push builders to stake with one ETH, that should be fine, and do, like.
Bharath:A trusted payment on, this thing, like…
Bharath:So, so yeah, outside that, I've just been working on the builder specs, like, trying to, like.
Bharath:And it's an initial iteration. This will definitely, like, go through, like, a lot of, like, changes, a lot of iterations up once things are, like, more clear and more,
Bharath:What's that? More, like, concrete. So, yeah, that's one update I have, like, just, like, starting to work on that.
Bharath:4788, you mean… Like, the EIP47AA?
Barnabas:No, no, no, I meant, Justin's… yeah.
Barnabas:Yeah, the option too.
Bharath:Sorry, I couldn't, like…
Barnabas:So that's… that's the PR that Justin has been talking about, just previously.
Bharath:Oh, yeah, yeah, no, so I still have to look at that PR and, like, make, like, changes according to that, if it does impact.
Barnabas:Okay, hold on.
Barnabas:Yeah, and Justin has, two more, PRs that he would like to merge in today.
Barnabas:Please.
Barnabas:Go through them and review it, and approve if you're happy, or raise any questions if you're not.
Barnabas:Okay, is there any other EPBS, discussion topic?
Barnabas:In Kesnau, do we have anyone regarding, gas limit increase discussion.
Barnabas:Got done.
Ben Adams:Let's go! Sorry, assuming… I think it's, depending on, how we feel about the BPOs.
Ben Adams:As I understand it, that's all looking good.
Ben Adams:We're not, like, stressing, the, the validation's out?
Ben Adams:Because, obviously, we have BPO2 to come, so… Right.
Barnabas:The VPR2 would have a few requirements on the CL side. It would probably want to have the max blobs on the ER side and partial responses on the CL side.
Barnabas:Which might require a few more weeks of work.
Ben Adams:Yeah, I just mean in terms of… because it's lower… lower bandwidth than the, 3 free sockers.
Barnabas:Joe.
Kamil Chodoła:So, from testing point of view, we are improving test generation right now, as we have some missing tests, so… yeah, and we have already PR ready to merge everything and retest once more.
Kamil Chodoła:So, we need to have that as a precondition, that's first thing. And other than that,
Kamil Chodoła:We are working in Netherlands right now on some improvements around State DB.
Kamil Chodoła:but also would wait for BPOs first to see how it would go, and in the meantime, discuss it further.
Kamil Chodoła:But other than that, I don't see any reasons to limit ourselves.
Kamil Chodoła:So, I mean, 75 or 80, whatever we want to pick, should be doable.
Kamil Chodoła:Quite soon.
Kamil Chodoła:But you need to have these tests restarted once more.
Raúl Kripalani:Yeah, if there's a concrete definition for the gas limit and potentially a date, I would really appreciate that, because it would help us focus the analysis a lot more.
Kamil Chodoła:So, running tests, we'll have it this week, everything restarted, refreshed to the latest spec.
Kamil Chodoła:And then we'll know if there are any other bottlenecks which were introduced, or any new tests which are uncovering some… some worrisome scenarios.
Kamil Chodoła:And yes, and after that, I will make a summary, and will maybe suggest some… something for it.
Barnabas:Perfect, thank you.
Barnabas:Is there anything else?
Barnabas:Regarding interest in the gas limit further?
Ameziane Hamlat:I have a quick question. How do we want to handle the next increase in gas limit? Because if…
Ameziane Hamlat:We have to do it before, like, Lamsterdam, this means that…
Ameziane Hamlat:Either we change the defaults.
Barnabas:That would be the idea, to change the defaults for the next BPO, ideally.
Ameziane Hamlat:I see, okay, that's the… okay.
Ameziane Hamlat:That makes sense.
Ben Adams:I'm remembering… Also, you know, signal.
Ben Adams:Socially.
Ben Adams:The validators can choose if they want to.
Ben Adams:Go further.
Ben Adams:I mean, not go further. Raise, raise their own setting.
Barnabas:I mean, validators can do whatever they want right now, so, yeah, that's a different topic. I think that's very dangerous. Probably we should stop doing that.
Barnabas:But, that's a discussion for another day, I think.
Ben Adams:What do you mean? Socially signalling that… We think it's okay.
Barnabas:Yeah, like, same way as with the BPOs, the target and max are configured by the client, and it's not overwrittenable by a runtime flag. So I think we should be doing the same, for the guest limit as well.
Ben Adams:Oh, okay.
Ben Adams:Okay, that's a discussion for a different day.
Barnabas:Yeah, exactly.
Barnabas:Okay, is there any other…
Barnabas:Topics to discuss regarding the guesstimate increase?
Kamil Chodoła:I mean, it's kind of related, but in the meantime, we are working heavily towards the repricings.
Kamil Chodoła:And then some analysis.
Kamil Chodoła:We have already quite a lot of tests, like a sample test for each opcode.
Kamil Chodoła:a set of 160 tests with worst cases for each specific opcode, and right now Lewis is working on adding precompiles on top of that.
Kamil Chodoła:And…
Kamil Chodoła:hopefully today, or tomorrow, we'll gather some first data for Maria and her team to analyze the data and start suggesting some better numbers, because the current ones from 7904, which were suggested quite a long time ago.
Kamil Chodoła:are, I would say, completely irrelevant comparing to the client's performance, and it would introduce plenty of new bottlenecks and making spread much worse. So, we need to figure out the better numbers for it, surely.
Kamil Chodoła:And hopefully, we will have that by the end of December.
Barnabas:That's good.
Barnabas:Yep. So I think there's also a breakout room.
Barnabas:Where we can dive in deeper for the repricing.
Barnabas:Numbers, and yeah, just follow up in… offline, maybe, if you have a good suggestion coming.
Maria Silva:Sorry, I would add, I don't think there's a breakout room at the moment. We did, like, a one-time
Maria Silva:Thing, but if you guys think it's useful, we can restart it in a more, like, weekly basis or bi-weekly basis.
Maria Silva:If you feel that's helpful.
Barnabas:Oh, I… Yeah, maybe I, missed that. I thought that we had, breakouts for this.
Barnabas:I'm not sure if… if you need one. Maybe you can discuss that offline?
Maria Silva:Sounds good, sounds good.
Barnabas:Okay,
Barnabas:a few more follow-up topics regarding, possibly scheduling BP03. As I mentioned earlier, we would probably want to have the partial responses,
Barnabas:working before we activate BPOS3.
Barnabas:We should have a working prison and lighthouse branch right now, with, gas and nitrominees supporting Get Block Space 3.
Barnabas:hopefully we can have all ELs, push out a branch, at least, for GetLabs V3, and all other CLs also to, support the posture responses. And then we can start doing an interrupt testing, and,
Barnabas:Try to figure out what the next bottleneck is going to be.
Barnabas:Raul, maybe you have something else to add?
Raúl Kripalani:No, I think you… you summarized it pretty well. I think some ELs already had, PRs that they had submitted when we had this original discussion and Fusaka time, so it should be a matter of rehashing those PRs and… and refreshing them if Master has changed. So pretty… pretty straightforward. It's a backwards compatible change.
Raúl Kripalani:It would help if ELs would…
Raúl Kripalani:include, if they feel comfortable to do that, if they would include this change in their next release, whether a minor, patch, or whatever, because, it would help integration, like, it would help us integrate better in DevNets, going forward, so that we have to maintain fewer, fewer branches.
Raúl Kripalani:And yeah, we'll keep this group updated on what the numbers are and how things are looking as we continue the efforts. There is some open points in the spec that we are trying to
Raúl Kripalani:resolve, or at least get directionally resolved by the end of this week, so that, when we resume this work.
Raúl Kripalani:after, kind of, like, the stopping period finishes, we'll kind of, like, come back to a solid spec. So, yeah, if people can… we'll send a link, and if people can start having a look, like, most… there's already a working… there's already a working group. Most people…
Raúl Kripalani:Like, the different…
Raúl Kripalani:Devs that are network inclined from ELs and CLs have already been added, and we're meeting on a weekly basis. If you would like to participate in this call, just reach out, and I'll add you as well, and this is what we'll be sharing the spec. So yeah, that's pretty much it.
Barnabas:Thank you. Yeah, and one more follow-up on, possibly including this in the next, releases. I, I would like to…
Barnabas:Reach out to all the ES to implement the max blobs flag, which will limit local block builders to be able to limit how many blobs they would like to include in a specific block, making sure that they will not produce an orphan block.
Barnabas:I know that Netherland and REST has already implemented it, but,
Barnabas:I would like just to have this included in the next releases of every year, hopefully in the next, month or two.
Barnabas:And I saw Ben raise your hand for a little bit. Do you have something to add?
Ben Adams:Yeah, it was just back on the topic of raising the gas limit, but also with shorter slots, and your controversial
Ben Adams:Take on that it should be… Set.
Ben Adams:By the, by the values in the clients, rather than…
Ben Adams:by… by the validators. If we did do that, then the issue with shorter slots would be easily resolved, whereas at the moment, there's a… there's an argument over
Ben Adams:How we interpret the value.
Ben Adams:So, maybe, maybe we could put that…
Ben Adams:And there's something for the shortest slot.
Barnabas:How do we interpret which value?
Ben Adams:Like, if a validator set the gas limit, it becomes ambiguous what we want to do when.
Barnabas:It would be a no-op, that's my proposal.
Ben Adams:Yeah, yeah.
Ben Adams:But it solves the issue with shorter slots, and what do we do with the gas limit.
Barnabas:Yeah.
Barnabas:Yeah, I think this may be a topic that we could discuss early next year.
Barnabas:If you actually want to do this or not,
Barnabas:Yeah, I'm not sure if today is the right call for that.
Barnabas:Okay,
Barnabas:There's one more, topic, the RPC testing from Tulio, from Aragon. He has a quick presentation for us.
Tullio Canepa | Erigon:Yes, hi everyone. May I share my screen?
Tullio Canepa | Erigon:Okay, can you see the slides?
Tullio Canepa | Erigon:Hope so.
Barnabas:Yes, we can.
Tullio Canepa | Erigon:Okay, thank you. Okay, I'm Tulio from Aragon, nicknamed Kanipat on Discord, and I'll be talking about RPC testing in the context of the rising standardization efforts of the LRPC protocol.
Tullio Canepa | Erigon:The current status of the RPC protocol is well known. We have many differences among the various client implementations at multiple levels.
Tullio Canepa | Erigon:at namespace level, endpoint level, input-output levels, and above all, in semantics, especially for non-trivial API endpoints.
Tullio Canepa | Erigon:Of course, such fragmentation,
Tullio Canepa | Erigon:is the result of lacking standardization, but fortunately, there are some efforts already ongoing, which hopefully will produce a proper standardization process, and as Aragon, we are really keen to join such effort. I've been told that there is this RPC standard call, and I'm planning to join it in the future.
Tullio Canepa | Erigon:And in our view, three areas are fundamental. The specs, it's important to come up with a full spec, both in human-readable and machine-readable formats.
Tullio Canepa | Erigon:A proper version scheme is required, and it's particularly relevant to improve application layer developer experience. Last but not least, the largest possible non-regression test suite, and this is where I'm going to focus right now in the following slides.
Tullio Canepa | Erigon:In our opinion, testing for compatibility at the RPC layer, when full standardization is in place, will need more than one single tool.
Tullio Canepa | Erigon:Currently, there is IVRPC Compact test suite, and just to be extremely clear, we love it, we really love it.
Tullio Canepa | Erigon:It's just that, as always happens, it has strengths and weaknesses.
Tullio Canepa | Erigon:So, we have developed a complementary, let's say, RPC testing suite, which…
Tullio Canepa | Erigon:with its own strengths and weaknesses, which we call RPC integration tests, and we use both of them in our CI, as you can see from the picture.
Tullio Canepa | Erigon:We use them for non-regression testing, not only in Aragon main branch and release branches.
Tullio Canepa | Erigon:but also as gates in HPR.
Tullio Canepa | Erigon:But why should we use two different tools?
Tullio Canepa | Erigon:Well, because…
Tullio Canepa | Erigon:Both such tools inherently come down to some trade-offs when it comes to checking RPC compatibility. On one hand, Hive RPC Compact uses a small simulated chain.
Tullio Canepa | Erigon:contains…
Tullio Canepa | Erigon:about 200 tests, and adding new test cases may be hard in some situations. As an example, in case of a complex interaction among different contracts.
Tullio Canepa | Erigon:On the other hand, Hive automatically handles the provisioning of all clients in its chain, and it's quite lightweight in terms of resource requirement, which is good, of course.
Tullio Canepa | Erigon:So, in my opinion, it's very good for a priori testing, let's say, which means for testing well-defined cases that you can identify up front.
Tullio Canepa | Erigon:I mean, for example, when developing a new API implementation.
Tullio Canepa | Erigon:As opposed to this RPC, Integration tests instead work with real data from real chains.
Tullio Canepa | Erigon:Our collection contains more… oh, sorry, contains more than,
Tullio Canepa | Erigon:Contains more than 1,300 tests, and adding new test cases is
Tullio Canepa | Erigon:is really as simple as adding a new JSON file.
Tullio Canepa | Erigon:With request and response pair. Of course, in this case.
Tullio Canepa | Erigon:Client provisioning is completely left to the user, because we use, real nodes, in sync with, real… attached to, mainnet or real testnets.
Tullio Canepa | Erigon:And…
Tullio Canepa | Erigon:So, in some sense, the testing setup is heavy. Not the framework itself, the framework is lightweight, but I think you've got what I want to say, and the real test setup is… is heavy.
Tullio Canepa | Erigon:This tool really shines, in my opinion, in a posteriority testing, which means if you have an issue coming directly from mainnet or some testnet, you can simply add a new
Tullio Canepa | Erigon:JSON file to start testing, and come up with a non-regression test that will run on your CI at the end of the bug session, and this is very useful.
Tullio Canepa | Erigon:Okay, so let's take a look at the testing modes that we have in our RPC integration test. We have two different modes, historical tests and latest tests.
Tullio Canepa | Erigon:Historical tests are tests executed at some old block or old state.
Tullio Canepa | Erigon:Key features, okay, we support both HTTP and WebSocket Transport Protocol, also with optional compression.
Tullio Canepa | Erigon:And we basically use JSON response files containing
Tullio Canepa | Erigon:The request, and the expected response.
Tullio Canepa | Erigon:Historical tests typically work, for an archive node.
Tullio Canepa | Erigon:even in degraded mode, let's say. Here, with degraded, I mean, synced up to the max block contained in the test suite.
Tullio Canepa | Erigon:But not more, so you don't need to have it cinched up.
Tullio Canepa | Erigon:to the tip, necessarily. You can, but it's not strictly required.
Tullio Canepa | Erigon:Then we have, latest tests, which are tests done at the chain head.
Tullio Canepa | Erigon:We cannot compare the response with a predefined result in this case, so we use a reference system, which means we run another client implementation.
Tullio Canepa | Erigon:Issue the same request to both the system under test, which is arrogant for us.
Tullio Canepa | Erigon:And to the reference system, then we compare the responses and the test passes if they are the same.
Tullio Canepa | Erigon:This setup works also for a full node.
Tullio Canepa | Erigon:Or even for an aggressively pruned node.
Tullio Canepa | Erigon:As a last note, I would like to add that RPC tests also contain a tool for performance testing.
Tullio Canepa | Erigon:I suppose that currently, Each client team has its own way of doing this.
Tullio Canepa | Erigon:But there are so many challenges in performance testing,
Tullio Canepa | Erigon:That's… we think it would be good to share the burden and team up on this subject.
Tullio Canepa | Erigon:Main challenges are, of course, various node… handle various node configuration to test, different platforms.
Tullio Canepa | Erigon:different hardware and OSes, a huge number of test vectors that you can choose from, You… you need to…
Tullio Canepa | Erigon:probably save a results history if you want to experiment with fancy things, like automatic corrugation detection, which is something we are trying to do. It's still in progress, because it's not trivial.
Tullio Canepa | Erigon:And yeah, in the end, we run also performance tests, as well in our CI.
Tullio Canepa | Erigon:Nightly or on demand.
Tullio Canepa | Erigon:Okay, that's basically it. Once again, this is the public repository for our RPC testing suite.
Tullio Canepa | Erigon:the current version is, that we use on our CI is written in Python. It all started as a couple pall of dirty Python scripts.
Tullio Canepa | Erigon:Now we are doing a complete rewriting goal to have better control over the underlying tools.
Tullio Canepa | Erigon:that we use. For example, for performance testing, we rely on the data.
Tullio Canepa | Erigon:And we believe that all clients can benefit from using it alongside hybrid PC compacts.
Tullio Canepa | Erigon:As we do.
Tullio Canepa | Erigon:Or maybe, I don't know, using a modified version?
Tullio Canepa | Erigon:I mean, any way this community ends up using it, that's totally welcome, and we are happy to share it.
Tullio Canepa | Erigon:And to collaborate in standardizing the RPC also in the testing.
Tullio Canepa | Erigon:And, yeah, I think that's it, and… Thank you very much.
Barnabas:Thank you, Tulio.
Barnabas:Yeah, I think it would be very good for you to present this also, possibly in the
Barnabas:in the RPC standardization call. I'm not sure when the next one is for that one. Maybe next week, Monday, actually, at 3 p.m. UTC.
Tullio Canepa | Erigon:next Monday.
Barnabas:Yep. Okay, yep.
Tullio Canepa | Erigon:Yeah, yeah, yeah.
Barnabas:pre-systemization calls, so I'm not sure if they have it scheduled for that as well.
Tullio Canepa | Erigon:I'll do it.
Barnabas:That would be the… yeah, that would be the proper place to present this, I think, yeah.
Tullio Canepa | Erigon:Okay, okay. Thank you.
Barnabas:Thank you. Anyway, does anyone have a question, or…
Chase Wright:Actually, I was just wondering, Tulio, can you hit me up on Discord? I'm Mystic Ryujin. I'm working on documenting a lot of this stuff on the EF side, so I'd like to work with you on this.
Tullio Canepa | Erigon:Sure, I will ping you.
Chase Wright:Thank you.
Barnabas:Okay, so the next topic is, HTAR discussion topics,
Barnabas:There was a bit of confusion last week, raised by this comment on Eat Magicians, where we decided star name that we picked, HECA is not an actual star name.
Barnabas:So, Leo proposed that, Beginning to,
Barnabas:we're gonna rename Heko to Heze, or Hizzy, or… I still don't really know how to… how to pronounce the start name, but seems like we have actually got more votes on this alternative name than the original name, so I would just say that we move on with the…
Barnabas:new, H star name of Heather.
Barnabas:Oh.
Barnabas:Easy.
Barnabas:Does anyone know how to actually… pronounce it?
Barnabas:Yeah, and then maybe for the final sorting, we can make the decision on this Thursday call, so that this topic is,
Barnabas:Over, once and for all.
Barnabas:And then we can start working on the next, story.
Barnabas:Anyone has an opinion on this?
Barnabas:Oh, yeah, that would be very good to know the actual pronunciation of the star.
Barnabas:uncertain.
Barnabas:Okay, then… The next topic would be the holiday schedule for ACDs.
Barnabas:I'm going to be posting a…
Barnabas:proposal in the chat. So, this week's Thursday, there's gonna be an ACDE, and the 22nd of December, there might be a ACDT. It depends on whether
Barnabas:Redeem it necessary?
Barnabas:25th of December, ACDC would be canceled. 29th of December, ACDT would be canceled. 1st of January, the ACDE would be canceled. On the 5th of January, ACDT would become a ACDE. And on the 8th of January, it would be an ACDC.
Barnabas:Would everyone be happy with this schedule?
Barnabas:My main question would be the 22nd of December, which is next week, Monday. Do we actually need another ECDT for this year, or could this call be the last,
Barnabas:SCDT of the year.
Barnabas:If nobody's gonna raise anything, then, I think we're gonna be also canceling the ACDT next week, Monday.
Barnabas:our… yeah, James… James wants to…
Barnabas:Jim's on to the CDP, so… Go for next week?
Barnabas:Nope.
Barnabas:So I guess we're gonna try to schedule one more call for next week, Monday, and that's gonna be… oh, you don't want it.
Barnabas:Does anyone want a call next Monday?
Barnabas:Yeah, it doesn't… it doesn't sound like people.
Barnabas:want a call, so I would just propose that we cancel next week's call as well, and we're gonna be back on the 12th of January next year, so almost a month from now.
Barnabas:with the next, Oracle Devs testing.
Barnabas:And I think that's it, for today.
Barnabas:Unless someone has.
Barnabas:Has anything else, Jared?
Barnabas:Happy holidays, and here's the updated schedule.
Barnabas:And… see you all on the 18th of December on the last Occo Devs call.
Barnabas:this year.
Barnabas:Thank you, bye-bye.
felipe:Thanks, bye.
Pawan Dhananjay:Thank you.
Leo:Bye.
Tullio Canepa | Erigon:Thank you.
Chat Logs
00:07:09
Stefan Starflinger:hello
00:07:53
James He:Prysm released post mortem main net incident
00:08:14
Justin Traglia:Replying to "Prysm released post ..."
https://prysm.offchainlabs.com/docs/misc/mainnet-postmortems/#fusaka-mainnet-prysm-incident
00:08:37
James He:https://prysm.offchainlabs.com/docs/misc/mainnet-postmortems/
00:09:12
Mario Vega:https://github.com/ethereum/execution-spec-tests/releases/tag/bal%40v2.0.0
00:15:10
Justin Traglia:https://github.com/ethereum/consensus-specs/pull/4788
In the PR we've made, builders will be tracked in a new builders list in the state. Some key changes: There is no activation queue for builders. Top-up deposits are instant, as soon as they hit the CL. The minimum builder balance is 1 ETH. Builders will not be able to perform partial withdrawals; only do full exits. Builders cannot be slashed nor penalized, which leads to a few nice simplifications for payments. Builder payments are faster since they don't need to go through the exit queue & min validator withdrawal delay.
00:16:15
Mario Vega:How would this list be bootstraped at fork boundary?
00:16:53
Pawan Dhananjay:We’d need some time to review this for lighthouse
00:18:23
Justin Traglia:https://github.com/ethereum/pm/issues/1835
00:20:39
Justin Traglia:https://github.com/ethereum/consensus-specs/pull/4777
00:21:50
Raúl Kripalani:i'll take a look
00:24:47
Pawan Dhananjay:The preferences are just gas limit and fee_recipient right?
00:25:16
Pawan Dhananjay:Gotcha, I’ll check it out
00:25:22
Bharath:Replying to "Gotcha, I’ll check i..."
https://github.com/ethereum/consensus-specs/pull/4777/commits/779d0037dd12f272bb0e4bc84add20833416bddb
00:25:41
Bharath:https://github.com/ethereum/builder-specs/pull/138
00:26:22
Barnabas:Replying to "https://github.com/e..."
is this built on top of 4788?
00:26:41
Barnabas:Replying to "https://github.com/e..."
https://github.com/ethereum/consensus-specs/pull/4788
00:26:50
Justin Traglia:Also, consensus devs, please review the following PRs. I would like to merge them today:
Refactor process_withdrawals consensus-specs#4765
Refactor get_expected_withdrawals consensus-specs#4766
00:27:30
Pawan Dhananjay:Replying to "Gotcha, I’ll check i..."
My first instinct is trusted_payments_accepted is unnecessary as the proposer doesn’t have to adhere to this preference in any way
00:27:56
Justin Florentine (Besu):this guy gets it
00:28:20
Enrico Del Fante (tbenr):Replying to "this guy gets it"
He is just trying to emulate the original
00:28:27
Alexey:if we will have shorter slots, it might be not good to increase it now, unless we are ready to double it next time?
00:29:00
Justin Florentine (Besu):Replying to "this guy gets it"
ben has his own, significant energy lets goooooo
00:29:07
Ben Adams:Replying to "if we will have shor..."
Don't think shorter slots needs to effect it
00:30:19
Raúl Kripalani:perfect
00:30:27
Alexey:Replying to "if we will have shor..."
You will have less time for execution?
00:30:43
Enrico Del Fante (tbenr):Replying to "if we will have shor..."
Yeah, shorter slots should adjust GAS independently
00:31:37
Alexey:Replying to "if we will have shor..."
I mean in 6 sec slot time 80 will feel like 160
00:32:13
Enrico Del Fante (tbenr):Replying to "if we will have shor..."
So if we go to 6, at activation gas limit will be halved, independently by current value
00:34:08
Kamil Chodoła:Quite a broad topic so worth hearing from others - but maybe once we will have solid numbers?
00:34:09
wolovim:It was only 2 one-off sessions
00:34:35
Maria Silva:Replying to "Quite a broad topic ..."
Yeah, agreed
00:35:04
Alexey:https://github.com/NethermindEth/nethermind/pull/9942 will be ready tomorrow
00:38:24
Kamil Chodoła:Not controversial - not seeing much value in voting gas limit on validators side while blobs are specd
00:38:29
Justin Traglia:Replying to "Gotcha, I’ll check i..."
I’ve reverted the trusted_payments_accepted change. We can discuss adding that later, if/when the PR is merged.
00:39:41
Kamil Chodoła:Would be nice to have networks parameters be on specification to be set.
Imagine giving slot time as a parameter for validators to decide on :D
00:40:05
Barnabas:Replying to "Would be nice to hav..."
Giphy [ID:1T96TRBBGYThC]
[Full message cannot be displayed on this version]
00:40:39
Ben Adams:Replying to "Would be nice to hav..."
Voting on slot time; changing per block?
00:41:16
Kamil Chodoła:Replying to "Would be nice to h..."
but only can decrese by 0.001% per block
00:44:49
Enrico Del Fante (tbenr):Replying to "Would be nice to hav..."
🤯
00:48:58
Stefan Starflinger:https://notes.ethereum.org/@ethpandaops/bal-devnet-1 updated devnet note for bals
00:49:35
Stefan Starflinger:(not all the branches for ELs are available yet)
00:50:07
Barnabas:https://ethereum-magicians.org/t/h-star-name-for-consensus-layer-upgrade-after-glamsterdam/24298/16?u=bbusa
00:50:08
nixo:TIL how to pronounce chase’s discord handle
00:50:39
Kamil Chodoła:In Nethermind we built sth similar for RPC benchmarking - Carlos is not there but asked him already to comapre and see the way forward if we should continue our effort or we should collab to make it generally better
00:50:44
nixo:the portmanteau is already up too!
https://ethereum-magicians.org/t/h-star-name-for-consensus-layer-upgrade-after-glamsterdam/24298/18
00:50:44
Barnabas:Heka -> Heze
00:51:16
Ben Adams:Hezgota
00:51:18
Leo:I can look at the pronuntiation
00:51:37
Chase Wright:Replying to "In Nethermind we bui..."
Based on my notes and overall goals, it would be a perfect collaboration to combine these 2 repos and unify the architecture.
00:51:49
Barnabas:18dec - ACDE
22dec - ACDT Cancelled
25dec - ACDC Cancelled
29dec - ACDT Cancelled
1jan - ACDE Cancelled
5jan - ACDT -> ACDE
8jan - ACDC
12jan - ACDT
00:52:38
nixo:core devs being forced to take time off by calls landing exactly on holidays
00:52:39
0xAphrodETH:I think shorter is better, maybe Hekta
00:52:56
James He:Last one please haha
00:53:04
Ben Adams:Replying to "I think shorter is b..."
Hezta
00:53:12
Katya:Call for next week
00:53:22
James He:I don’t want*
00:53:23
nixo:Replying to "Last one please haha"
he’s saying this is the last one?
00:53:35
James He:Replying to "Last one please haha"
This one as the last one please
00:54:19
Katya:Happy holidays
00:54:22
Barnabas:18dec - ACDE
22dec - ACDT Cancelled
25dec - ACDC Cancelled
29dec - ACDT Cancelled
1jan - ACDE Cancelled
5jan - ACDT -> ACDE
8jan - ACDC
12jan - ACDT
Summary
16 highlights
· 2 decisions · 4 action itemsExperimental
Summary
16 highlights · 2 decisions · 4 action itemsExperimentalfork status and schedule
testing progress
client updates
- Besu: state root conclusion merged, perfect parallelization with BAL near ready00:10:57
- Nethermind: parallel tx execution and state route computation in progress00:12:30
- Reth: storage B256→number change complete, self-destruct bug fixed00:13:01
- Erigon: bal-devnet branch created, Hive tests joined, parallel execution WIP00:14:00
epbs progress
gas limit and repricing
Decisions
Action Items
- CL client teams: Review builder separation PR and decide by Friday breakout00:18:24
- Consensus devs: Review and approve withdrawal refactor PRs for merge00:26:50
- EL clients: Implement max blobs flag for next releases00:36:54
- EL clients: Include GetBlockV3/partial responses in next releases if comfortable00:35:27