All Core Devs - Testing #64

Transcript

Justin Traglia: Good morning, gentlemen. You're leaving today's call, right, Barnabas?

Barnabas Busa: I really can't.

Justin Traglia: Cool, cool.

Barnabas Busa: Do you want to discuss the… The new ventilator type thing?

Justin Traglia: Yeah, I do. I just left a comment on the agenda.

Barnabas Busa: Okay, yeah, I haven't seen it yet. I think it would be good to discuss it, for sure. Especially if you're gonna be merging it in now.

Justin Traglia: Yeah, and also the… and also the proposer preferences gossip topic thing I'd like to discuss. I just kind of want to get, like, a feeling for it, like, what do others think, and then maybe ask for reviews and merge it. Just whenever.

Barnabas Busa: Yeah, sounds good.

Groupon? Let's give it another minute, then we can get started.

Alright, let's get started. Welcome everybody to AllCoreDev's testing call, number 64. We have a packed agenda for today, so let's get started. Regarding Fusaka, we had, last week BP01 going live, and it was a success, so congratulations to everybody participating in that. And, is there any other open questions regarding Fusaka? 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. 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. Okay.

Oh yeah, prison, had a post-mortem of, what happened in Fusaka during, like, right after the fort. James, could you maybe just put it in the chat, and then everybody can, take a look at the… blog post. Or, I don't know, do you guys want to talk about it? Oh, I guess not. Okay. I think, I think we can move on to Glamsterdam again. So… 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. 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. 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. 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 You could have a look. If you need any help with that, feel free to reach out.

And otherwise, it's just general stuff. I've also added it to the agenda. Is Philippe here, maybe you would want to give an update also from the testing side?

Felipe Selmo: Yeah, sure. Other than… the UN256 changes, we added, quite a bit of… Gas boundary tests for call-up codes. So we should have more coverage there as well. But yeah. I think, everything else, went pretty smooth on the testing side.

Stefan Starflinger: Corvettes. Then yeah, it's… we have a breakout call, on Wednesday, I think, for Baos, and we can discuss anything in particular there. 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. But otherwise, if clients might want to give a quick update where they're at right now, that would be great, or we could… do it on Wednesday as well. more detailed.

Karim Taam: I can on the business side, so, Today, we implemented several features, we… we merged, state fruit conclusion… traditional background, thanks to Block Access List. 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. 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. We have some failing tests, some tests regarding the call operation. So we know how to fix that, we just didn't start it to work on it, and we fixed also a self-district,

issue, recently. So… Yeah, accepting that, we started the BaldurNet1 branch, we merged all of the different fixes. And, we also updated the slot key and values format in this branch, so… Normally, it should be okay for the next run.

Barnabas Busa: That's great. Is there any other ELs that could give us an update? About their progress?

Marc Harvey-Hill: Yeah, for NetherMind, at the moment, I'm focused on the parallel transaction execution and, state route computation. So, made some good progress on that, and I just need to, do a few updates related to this, new testing release.

Dragan Rakita: From Redside, we made change to, storage, making from the… B256 to number. Started work on the… using BAL on the state route, and talking about BAR, how to do it parallel. How to do parallel education. I have run, 2.0 tests today, and had one bug to self-destruct, and… out gas that I fixed.

Barnabas Busa: Thank you. Anyone else? Anyone maybe from gas could speak up? Okay, is there any… yup.

Milen Filatov: Yeah, hey, I can give a quick one for, Aragon, We, just created the boudevNet branch and, joined the Hive tests. I think we have a bunch… a bunch of failure to go through. And, yeah, we also have… One other person working on, parallel execution, which also should be enabled by default on that branch. 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 Busa: Okay, thank you. Do we have any other ELs that would like to give us on that? In case not, then I will just, pass the word to Justin. He has a few proposals for EPBS.

Justin Traglia: Yep. Hello, everyone. Yeah, so for EPBS, I guess the first thing we should talk about is probably, the change to builders that we want to make. So, like, we want to change builders so that they're not validating entities. This simplifies things quite a bit. Faster deposits, instant top- like, instant top-ups, Lots of other simplifications, but essentially this moves… Builders from the validators list in the state to a new builders list. Just asking client teams and everyone to review it, see if we all agree. 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. It's just a term, like…

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. How do client teams feel about this?

Barnabas Busa: Maybe someone from PRISM gonna comment on it?

Justin Traglia: That's a good question, Mario. 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. That's one option. Or we just require builders wait one epoch before… submitting bids so that they can create the builders. Like, it would be almost instant to create a new builder, and the minimum,

Barnabas Busa: It would be too.

Justin Traglia: The minimum stake amount would be 1 ETH as well. What is it, Barnabas?

Barnabas Busa: 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 Without builders for 3 epochs, right?

Justin Traglia: Something like that, yeah. Unless we do the bootstrapping, idea. And I think POTUS is in favor of that. It's just… I'm personally not. I think it's kind of complicated.

Barnabas Busa: I mean… we had 0x02 editors also going online before the fork of Spectra. So why would…

Justin Traglia: Yeah.

Barnabas Busa: Why would this be a problem?

Justin Traglia: So there's a property I want to maintain that… There can't be a validator and a builder with the same pub key in the state. Just for simplicity, that way you can, like. 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. If we do the conversion, you would essentially have Sorry, you would have a pub key in both, and I just don't like that. Does that make sense?

Barnabas Busa: Yep, it does. Is there a breakout this Friday?

Justin Traglia: There is indeed. I can share a link just in just a second.

Barnabas Busa: So, it would be very, very, very good if you could make a final decision on this by, this week's breakout. And, I can go off to the holidays with, 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… I would like to have a deadline on that for the breakout room.

Justin Traglia: Agreed.

Barnabas Busa: Enrico?

Enrico Del Fante: Just a very quick question. I was not looking into the details, but one question I had… 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? So, you… you won't be validating.

Justin Traglia: They would be cut off, yeah.

Enrico Del Fante: 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. So, you have to have a different…

Justin Traglia: Correct.

Enrico Del Fante: Okay.

Justin Traglia: I mean, you would just have to have, like, a… Another note at home with one ETH.

Enrico Del Fante: And, well, depends by where we land in terms of capital, minimal capital. Just to enable building, so if we go with higher… If required.

Justin Traglia: Yeah.

Enrico Del Fante: 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. But you're right, it does break that, That was nice that any validator could submit a bid.

Enrico Del Fante: Yep. I was personally… personal liking it.

Justin Traglia: Any other top… sorry, any other, Points on the builder's change. Okay, there's a different topic I'd like to discuss then, too. the proposer preferences gossip topic suggestion that I, am wanting to make. 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. What is it now? The epoch before the… Proposal. Proposers would submit their preferences to the topic. So yeah, just… 32 proposer preferences per epoch. So it's a pretty minimal, topic without, like, a lot of traffic.

Have clients had time to review this one? Or… Do people have ideas? Thoughts?

Bharath Vedartham: I have one thought, like, so, I think recently, you added a field, To… to signal that the proposal will accept a trusted payment. I'm unsure if that should be on the gossip topic, because I would assume, like, the proposer would, what is that? you have a set of builders you trust, right? Because there's a risk here, like, the builder could say, I… 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… I would assume the proposer would want to, like, be like, okay, I trust Builder A, B, C, but I don't trust D. So, I would assume this should be more granular, is my take.

Justin Traglia: Possibly, yeah.

Bharath Vedartham: 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 Vedartham: Yeah, no, no, I mean, like, you anyways have the URLs of the… 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. 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 Vedartham: 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. 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. On the epoch boundaries, when, you're sending a validated registrations, you… you take a design… you take a call, okay, like. I know I'm gonna send to this builder, I probably, like. I want to accept, like, a trusted payment from them, or not. 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 Vedartham: Yeah, we can, like, take it out on the channel, like, yeah.

Justin Traglia: Cora. 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 Vedartham: 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… 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, 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. Because that's on a global… But yeah.

Justin Traglia: Okay, yeah, we can discuss that more.

Bharath Vedartham: 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. It's just a Boolean. If people don't like that, I can remove it. Yep. Thank you. And, I guess that's it for me for EPBS. Maybe just more client updates or something.

Bharath Vedartham: I can give, like, a small update, like, I've been working on, like, just, like, starting to spec out the builder specs. thinking about, like, our documents, we've been thinking about, 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. We could, like, push builders to stake with one ETH, that should be fine, and do, like. A trusted payment on, this thing, like… So, so yeah, outside that, I've just been working on the builder specs, like, trying to, like. 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,

What's that? More, like, concrete. So, yeah, that's one update I have, like, just, like, starting to work on that. 4788, you mean… Like, the EIP47AA?

Barnabas Busa: No, no, no, I meant, Justin's… yeah. Yeah, the option too.

Bharath Vedartham: Sorry, I couldn't, like…

Barnabas Busa: So that's… that's the PR that Justin has been talking about, just previously.

Bharath Vedartham: 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 Busa: Okay, hold on. Yeah, and Justin has, two more, PRs that he would like to merge in today. Please. Go through them and review it, and approve if you're happy, or raise any questions if you're not. Okay, is there any other EPBS, discussion topic? In Kesnau, do we have anyone regarding, gas limit increase discussion. Got done.

Ben Adams: Let's go! Sorry, assuming… I think it's, depending on, how we feel about the BPOs. As I understand it, that's all looking good. We're not, like, stressing, the, the validation's out? Because, obviously, we have BPO2 to come, so… Right.

Barnabas Busa: 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. 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 Busa: 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. So, we need to have that as a precondition, that's first thing. And other than that, We are working in Netherlands right now on some improvements around State DB. but also would wait for BPOs first to see how it would go, and in the meantime, discuss it further. But other than that, I don't see any reasons to limit ourselves. So, I mean, 75 or 80, whatever we want to pick, should be doable. Quite soon. 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. 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. And yes, and after that, I will make a summary, and will maybe suggest some… something for it.

Barnabas Busa: Perfect, thank you. Is there anything else? 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… We have to do it before, like, Lamsterdam, this means that… Either we change the defaults.

Barnabas Busa: That would be the idea, to change the defaults for the next BPO, ideally.

Ameziane Hamlat: I see, okay, that's the… okay. That makes sense.

Ben Adams: I'm remembering… Also, you know, signal. Socially. The validators can choose if they want to. Go further. I mean, not go further. Raise, raise their own setting.

Barnabas Busa: 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. 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 Busa: 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. Okay, that's a discussion for a different day.

Barnabas Busa: Yeah, exactly. Okay, is there any other… 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. And then some analysis. We have already quite a lot of tests, like a sample test for each opcode. 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. And… 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. 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.

And hopefully, we will have that by the end of December.

Barnabas Busa: That's good. Yep. So I think there's also a breakout room. Where we can dive in deeper for the repricing. 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 Thing, but if you guys think it's useful, we can restart it in a more, like, weekly basis or bi-weekly basis. If you feel that's helpful.

Barnabas Busa: Oh, I… Yeah, maybe I, missed that. I thought that we had, breakouts for this. I'm not sure if… if you need one. Maybe you can discuss that offline?

Maria Silva: Sounds good, sounds good.

Barnabas Busa: Okay, a few more follow-up topics regarding, possibly scheduling BP03. As I mentioned earlier, we would probably want to have the partial responses, working before we activate BPOS3. We should have a working prison and lighthouse branch right now, with, gas and nitrominees supporting Get Block Space 3. 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, Try to figure out what the next bottleneck is going to be. 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. It would help if ELs would… 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. 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

resolve, or at least get directionally resolved by the end of this week, so that, when we resume this work. 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… Like, the different… 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 Busa: Thank you. Yeah, and one more follow-up on, possibly including this in the next, releases. I, I would like to… 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. I know that Netherland and REST has already implemented it, but, I would like just to have this included in the next releases of every year, hopefully in the next, month or two. 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 Take on that it should be… Set. By the, by the values in the clients, rather than… 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 How we interpret the value. So, maybe, maybe we could put that… And there's something for the shortest slot.

Barnabas Busa: 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 Busa: It would be a no-op, that's my proposal.

Ben Adams: Yeah, yeah. But it solves the issue with shorter slots, and what do we do with the gas limit.

Barnabas Busa: Yeah. Yeah, I think this may be a topic that we could discuss early next year. If you actually want to do this or not, Yeah, I'm not sure if today is the right call for that. Okay, There's one more, topic, the RPC testing from Tulio, from Aragon. He has a quick presentation for us.

Tullio Canepa: Yes, hi everyone. May I share my screen? Okay, can you see the slides? Hope so.

Barnabas Busa: Yes, we can.

Tullio Canepa: 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. The current status of the RPC protocol is well known. We have many differences among the various client implementations at multiple levels. at namespace level, endpoint level, input-output levels, and above all, in semantics, especially for non-trivial API endpoints. Of course, such fragmentation, 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.

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. 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. In our opinion, testing for compatibility at the RPC layer, when full standardization is in place, will need more than one single tool. Currently, there is IVRPC Compact test suite, and just to be extremely clear, we love it, we really love it. It's just that, as always happens, it has strengths and weaknesses. So, we have developed a complementary, let's say, RPC testing suite, which…

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. We use them for non-regression testing, not only in Aragon main branch and release branches. but also as gates in HPR. But why should we use two different tools? Well, because… 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. contains… 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. 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.

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. I mean, for example, when developing a new API implementation. As opposed to this RPC, Integration tests instead work with real data from real chains. Our collection contains more… oh, sorry, contains more than, Contains more than 1,300 tests, and adding new test cases is is really as simple as adding a new JSON file. With request and response pair. Of course, in this case. Client provisioning is completely left to the user, because we use, real nodes, in sync with, real… attached to, mainnet or real testnets.

And… 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. 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 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. 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.

Historical tests are tests executed at some old block or old state. Key features, okay, we support both HTTP and WebSocket Transport Protocol, also with optional compression. And we basically use JSON response files containing The request, and the expected response. Historical tests typically work, for an archive node. even in degraded mode, let's say. Here, with degraded, I mean, synced up to the max block contained in the test suite. But not more, so you don't need to have it cinched up. to the tip, necessarily. You can, but it's not strictly required. Then we have, latest tests, which are tests done at the chain head. 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.

Issue the same request to both the system under test, which is arrogant for us. And to the reference system, then we compare the responses and the test passes if they are the same. This setup works also for a full node. Or even for an aggressively pruned node. As a last note, I would like to add that RPC tests also contain a tool for performance testing. I suppose that currently, Each client team has its own way of doing this. But there are so many challenges in performance testing, That's… we think it would be good to share the burden and team up on this subject. Main challenges are, of course, various node… handle various node configuration to test, different platforms.

different hardware and OSes, a huge number of test vectors that you can choose from, You… you need to… 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. And yeah, in the end, we run also performance tests, as well in our CI. Nightly or on demand. Okay, that's basically it. Once again, this is the public repository for our RPC testing suite. 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. Now we are doing a complete rewriting goal to have better control over the underlying tools.

that we use. For example, for performance testing, we rely on the data. And we believe that all clients can benefit from using it alongside hybrid PC compacts. As we do. Or maybe, I don't know, using a modified version? I mean, any way this community ends up using it, that's totally welcome, and we are happy to share it. And to collaborate in standardizing the RPC also in the testing. And, yeah, I think that's it, and… Thank you very much.

Barnabas Busa: Thank you, Tulio. Yeah, I think it would be very good for you to present this also, possibly in the 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: next Monday.

Barnabas Busa: Yep. Okay, yep.

Tullio Canepa: Yeah, yeah, yeah.

Barnabas Busa: pre-systemization calls, so I'm not sure if they have it scheduled for that as well.

Tullio Canepa: I'll do it.

Barnabas Busa: That would be the… yeah, that would be the proper place to present this, I think, yeah.

Tullio Canepa: Okay, okay. Thank you.

Barnabas Busa: 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: Sure, I will ping you.

Chase Wright: Thank you.

Barnabas Busa: Okay, so the next topic is, HTAR discussion topics, 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. So, Leo proposed that, Beginning to, 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… new, H star name of Heather. Oh. Easy. Does anyone know how to actually… pronounce it?

Yeah, and then maybe for the final sorting, we can make the decision on this Thursday call, so that this topic is, Over, once and for all. And then we can start working on the next, story. Anyone has an opinion on this? Oh, yeah, that would be very good to know the actual pronunciation of the star. uncertain. Okay, then… The next topic would be the holiday schedule for ACDs. I'm going to be posting a… 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

Redeem it necessary? 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. Would everyone be happy with this schedule? 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, SCDT of the year. If nobody's gonna raise anything, then, I think we're gonna be also canceling the ACDT next week, Monday.

our… yeah, James… James wants to… Jim's on to the CDP, so… Go for next week? Nope. 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. Does anyone want a call next Monday? Yeah, it doesn't… it doesn't sound like people. 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. with the next, Oracle Devs testing.

And I think that's it, for today. Unless someone has. Has anything else, Jared? Happy holidays, and here's the updated schedule. And… see you all on the 18th of December on the last Occo Devs call. this year. Thank you, bye-bye.

Felipe Selmo: Thanks, bye.

Pawan Dhananjay: Thank you.

Leo: Bye.

Tullio Canepa: Thank you.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.