EPF6 Office Hours | Barnabas

Uh sorry that uh happy birthday Ethereum uh 10 years uh but u we are focusing on the future in the in the fellowship we are building for for present and for uh for for the future. So um we got uh we got a special guest today uh our first AMA with Barnavas from Pandops. Uh so Barnabas is part of the uh the Panda team of Ethereum Foundation. Um uh you might uh heard about the team you probably used some of their tools uh in your uh in your EPF journey and I invited Barnabas because uh uh before we even get started looking into the implementation we need to understand what tooling uh people need to use to uh locally prototype to uh to develop to understand how how the network is actually uh run and analyzed and so on. So we are starting with with Barnabas here today and uh thank you for being here of course uh thank you so much for taking the time and uh to give people some more context to get to know you a bit please tell us about yourself plus uh maybe more about PendOps and what is your specific role what are you working on these days?

Yeah, sure. So, my name is Barnes and I've started uh my dream journey approximately three years ago. Uh almost exactly three years ago. Tomorrow it's going to be my uh third year anniversary. And uh I'm in team of seven people right now.

We have three people living in Australia. We have uh four people living in Europe. And the Australian people are working mainly on the monitoring side and and the European people are focusing on the development of different tooling and the testing. Uh you guys probably heard about Pari. Pari is the other guy that is uh really pushing all the testing uh efforts and uh together Pari and me are the main people uh focusing on the testing side of things and the coordination with the different uh client teams.

So our main work uh is focusing on uh interoperability between the different C and EI clients. basically making sure that all the CIA clients are able to work with all the EI clients and vice versa and the different client teams are now have a combined uh number of uh 30 combinations uh to test each of the different clients and uh yeah so basically we just uh we focus on uh the prototyping the initial tests of uh different uh client implementations of a new fork or the current fork and the best fork. So we have uh test for uh currently running networks and the future forks which is uh right now the fusaka

I'm not sure how much uh I should how much background I need to give uh for the

well that's for that's that's good for the start just to have some context uh but uh uh maybe more about uh your background uh because you just mentioned it's three years since you started in Ethereum. So maybe tell us more about yourself. What have you done before? What is your journey actually starting in Ethereum? What was it like before?

I mean I'm not sure if PendOps was even PendOps 3 years ago whether it was in DevOps at the time still.

Yeah. So three years ago uh before I joined uh Ethereum I have actually worked at CERN which is u physics experiment in Switzerland. I was there for two years. I did my uh master degree there. basically finished my thesis there and uh before that I was u doing an internship on cargo vessels and I was uh swapping out uh physical equipment on cargo ships and I did my u bachelor's in the Netherlands in University of German and I did my masters in TUDA also in Netherlands uh [applause] yeah so it pend basically is a team that has been created at the time when I joined.

Uh it was not a team before and uh just when we started uh just when I started that's when the team was actually created and I think uh the actual official name uh was agreed on around the 20th of August of 2022. So just a couple of weeks before uh the merge. And yeah, so personally my first uh work was uh working on the merge uh together with party, Rafael and uh Sam back then. And then we started hiring some more people and uh yeah my really my first uh actual fork was uh the fork right after uh the merge which was uh

Chappella. Yep. With the wall. It was a very small fork and very fat that I can actually uh get my hands dirty and uh work on that.

Yeah. Awesome. Uh yeah, so the the ship and the the merge time. So it's very exciting to to join like uh that was a big project that everybody just look forward to. Everybody was really focused on it.

Uh so that's good energy. So I I'm wondering like what drives you today or what is something exciting? what are you looking forward to in the road map or in the current work on the protocol what uh yeah what excites you most

right so currently my main uh like 95% of my focus is on Fusaka which is u our next fork hopefully we can ship that in Q4 of this year fus fusaka's main headliner EIP is uh pure which is going to enable uh uh smaller validators to uh reduce their bandwidth requirements and larger validators to have an increased uh duties basically and this is going to enable us to further scale um develops throughput for their tools.

Yeah, Pas is very exciting change. It's it's really cool. We finally have the developer sampling uh reaching it. Um cool. So uh I will open the questions for the audience.

I just wait to get get us started. Uh if you guys have questions feel free to raise your hand. uh or write in the chat if you cannot speak uh use your mic uh but please ask some questions and uh before we get some we actually have uh some questions in the agenda from the folks who couldn't attend um from uh bridge we have a question about uh monitoring blind spots whether there are any uh monitoring blind spots in the current Ethereum infrastructure something that could bite us during the next hardwork uh whether there are any missing systems uh that you or the pand those wishes uh that existed. Yeah. Um we have I mean the grew a lot.

Is there still anything missing in the the infrastructure?

Uh yeah. So we hope that we cover everything but as you know about blind spots is that they are blind until you recognize them. So it's it's very hard to know what is uh going wrong until that thing is actually going wrong. So we are really trying to do as many edge case testing as we possibly can and uh really for the rest uh we hope for hope for the best. So we had a few accidents in uh Peterra when we were uh shipping Peter petra we had uh an incident on holleski which led to a bunch of validators getting injected.

Uh it was something that could have been avoided with a shadow fork which we decided not to do because of the uh extra cost that would have been involved in doing a shadow fork for hoski. Uh we decided uh not to do a shadow fork for seapia either and seap also had a bug that was caused by uh the different deposit contract uh value that we use on seapia. So none of them were major issues but they were all issues that uh are not a good look and ideally we want to avoid having uh breaking changes uh and breaking uh forks in any test nets. Um and this is exactly why we do a bunch of death nets before we start forking uh public test nets. And I think this also already answered the second half of the question which was uh if I would have any war stories uh things that look good on test nets or during simulations about assumptions not holding for production.

So luckily we didn't have any major incident on mainet in Petra but uh yeah breaking the test net was definitely something that is uh not something that we're looking forward.

Yeah thank you so much for answering both questions there. Yeah, I was uh going to ask the worst story as well. It's uh um it was tough during the pctor testing and I remember uh when we had the EF retreat like half of the EF in a single room and the pctor was hard working in the morning and like few minutes after all of the pent ups all of the team just stands up and goes away and was clear that some things up. Yeah. Uh thank you so much for answering that one and uh uh I will give another chance for somebody to raise their hand in case there are some questions here.

Nobody. We have Jun.

Uh yeah. Uh hi Baronas. Uh my name is Jun and uh I really love the pandas works. Uh so they built a lot of tools uh which is very useful that we use every day. So uh I wonder how the pandops teams work.

So uh for example what brought you to work on the pureas or fusaka uh right now? So uh is there any uh members who assign the task or the members are self motivated to uh dive into the specific topic or so. So yeah that's my question.

Yeah so our uh work is split among uh as I mentioned we have three people in Australia. So those people are mainly focused on uh collecting metrics. So if you have ever worked with Zatu or Zatu data uh they are really responsible for building that uh click house data set for example and uh all the monitoring all the graphana dashboards that you see that that was all done and then uh we have the people in Europe uh Pari and me are mainly focused on the uh actual testing of the clients. So uh working the client teams, communicating with them uh discussing uh what's going good, what's not going so good. So this work is kind of split between him and me and uh we discuss internally uh which fork he wants to do or which feature he wants to do and which uh feature I want to work on.

And then we have two other people that are mainly working on tooling uh Rafael and uh PK. So uh PK for example single-handedly uh built the door explorer uh like a week before he joined our team even and uh so that has been a tool that that's been very very powerful and um he also wrote spammer and uh Rafael has been helping a lot in the tooling side as well. So this is how we kind of split it up. Uh so pari right now is mainly focused on pushing the gas limit. uh all the performance admit uh side of things and I'm uh I'm text to ship the next fork which is for Saka and then we're going to be starting Glamsterdam scoping very very soon we're going to have Glsteramnat coming up and uh possibly in parallel we're going to be doing some uh lean Ethereum related stuff and which is the beam chain origin was called the beam chain

uh so a follow-up question uh So uh there are many tools built by pandelp. So uh uh I wonder uh how they uh uh how they made from the scratch. So uh is there any needs from the community or did the panda team need something? So build uh that tool or something.

I would say all of our tooling is based on our current needs. We if if we see that something is needed, we make it and and that is the best way because lots of people like to build tools and then they never end up using it themselves. So what we found very useful is if we we are the ones building a tool and we are actually using it, we can iterate on it so fast that we don't need to make the perfect tool from day one. what we want to do is uh have some proof of concept in implementation of something that that's also how door started. It was it was very very lightweight in the beginning.

We had uh the whole thing basically sitting memory. We didn't even have a database for it and we just needed to have something up and running uh as soon as possible just to have some kind of quick uh observability of the network's health and then we started adding uh extra functionality extra uh features uh and as you see it right now it has full functionality for peer death uh observability as well. It has uh visibility in the uh column structures and you able to make queries with the E test guardian which is a tool that's able to mimic a uh consensus layer client and able to scope out if a specific client has uh everything that it says it supposed to have like all the columns uh and costing everything.

So yeah, thank you so much. Yeah. Yeah, I would say everything is basically built by us for uh our current needs.

Yeah. So I really love how they integrate with the curtises. So we can just uh fix our YAML file that we can use uh the amazing tools. So yeah, I really love uh those tools and kudos to pandels. Thanks for answering my question.

So curious has been actually uh one of the first projects I picked up. it it was uh very much a proof of concept back uh when I started working on it and I've been trying to make it as uh user friendly as possible without introducing many breaking changes. So I'm I'm really hoping to get as many devs onto as possible because it's a really really great uh dev experience I think. Yes, thank you so much. Uh Irene, yeah, go ahead.

Hi. Yes, I don't know if it's uh too early to ask, but yes, I also had a question about curtosis because currently my project is about like migrating the sim test framework in lot to curtosis. So I was wondering whether you are actively using Corttosis as a testing framework and also because I saw it like being used in the Ethereum community more and more. So do you think that it will become like the to the go-to testing testing tool also in the in the future in a let's say more stable way as now uh is still like being maintained and and so on. Thank you.

So, Curtosis is the engine that's running underneath the Ethereum package. I'm guessing your question is mainly focused on the Ethereum package instead of the Crytosis engine.

Yes, exactly. I meant the Ethereum package. Yes.

So, the Ethereum package is uh it's something that I personally use uh maybe 100 times a day. So, it's something that I use very very very heavily. And uh we we continuously trying to improve it and make it better and keep it as uh feature complete as possible. Uh we don't intend it to be a production system. We want to keep it as the focus as possible.

We don't plan to have it running for months or years in a cryos environment because it's not what it's meant to do. We we don't want to we don't want other people to basically spin up a scam chain on crytosis and offer it as a their next whatever. Uh so that's why we we explicitly say that this is not meant to be run as production. It it's meant to be run as a dev tool. uh in terms of uh migrating tests into that uh I would say it's it's very stable and you should definitely look into doing that.

We have multiple assertive test examples where uh you could run a CI job and basically ensure that whatever test you write in assertter is going to adhere to what you what you want to do. So yeah, I I I can highly recommend u migrating into crypto classes.

Perfect. Thank you so much.

Thank you. Yes, great advice. Um we have uh a hand up for Lee want to ask.

Yeah, thanks. I already have my question like uh uh in chat. uh the major question is about the uh peer does because you mentioned that in during your implementation and also maybe the research did you identify any like challenges or any problems that uh need to be solved I mean even in like only in pure dos maybe also the further dos which or maybe some future you want

yeah so right now the the biggest um open questions in podas is still uh back field and uh syncing issues. So most of the CI clients have syncing issues right now when uh they depend on uh reconstructing. So in a perfect period scenario where you have 16 nodes with eight uh validator custody nodes each and you're trying to uh basically remove one or two nodes from that network and try to sync up a new node to that network and you are requesting columns that require a reconstruction or from a different set of columns. That is something that is uh a huge pain point at this point and it really needs to be ironed out before next month before we can uh start working uh production uh test nets. Basically I think that that is right now the number one priority for most uh consensus layer clients.

uh why is that part is high is because of the like uh the communication of the network or

yeah so reconstruction requires a bunch of uh P2P communication and uh your node will have to basically request a column that nobody has and from that uh you're going to need to figure out inside your client to request a column that can be used uh to reconstruct the column that you need And this this is logic that is new and it's something that has never been tested before and and that's this is what makes it uh difficult. So so far on the dev nets uh what we've been doing is happy testing and even the hepace testing uh has been uh a pretty big struggle because of the huge changes in the P2P layer and the and the complete rewrite of the blob structure basically. Okay.

Thank you. Uh sorry I lost my connection like just for a few seconds.

Yeah, I think everyone got kicked.

Okay. So it's only me. I mean it's like the meeting hits the D something like that. No. Uh yes.

I mean it's like Yeah, that's true. That's true. uh but uh that that feature sound not like reconstruction that sounds like a repair right it's like if one node want to uh get a just one column it's not really like reconstruct the whole set of the data

yeah so the the whole point of reconstructing is that you require columns that uh other people don't have and because of the uh properties of pure you you're going to be able to reconstruct those columns that nobody has from uh other columns as well. So you will have to your client will have to request other columns that uh some nodes will have and use those to reconstruct the columns that you need. And this is uh something that is uh most likely never going to happen in uh mainet ethereum because of the sheer amount of uh available nodes. But it's still something it's still an edge case that we have to test.

Yeah, that's true. That's true. We are actually also discussion uh discussing the uh repairability of the DOS because let's say we need to reconstruct the or repair one column. We only need to touch like very few nodes. Let's say uh five or six nodes.

That's already enough. You don't need to really touch everyone to reconstruct that. Would that be good for for the uh for this saturation?

I mean it depends on how many columns uh you want to custody because if you if you need to uh reconstruct eight columns that nobody has and you will have to worst case reach out to uh 16 different nodes.

Oh yeah exactly exactly. I mean it's uh I understand that part. I mean if we can reduce the number of the nodes you need to touch if you just need to like the nodes just need to reconstruct a few columns let's assume only one nodes lost and not like many nodes lost would that be a good feature or something like uh be benefit for the network? Well, uh I I was I was explicitly talking about the perfect pod scenario where you have exactly 16 nodes with eight custody columns for each. So uh that's why I said like if you remove a node from that specific scenario then uh you will have to reach out to basically every everyone else to reconstruct the costly columns that you need.

Yeah. Yeah. Yeah. Yeah. Yeah.

I mean uh I mean I'm thinking about like the fas like when we design the fas how can we avoid such saturation or maybe make it better

for fas. Yeah. It's going to be a totally different story I think.

Yeah.

I I haven't thought that far uh I have.

Yeah. Yeah. Yeah. Cool. Uh uh do you have any like test results or like uh uh for for the pure dust now?

for what?

Uh like the the test or like some benchmark for the test. No

for full death.

Yeah, for pure death

for pure death for reconstruction or for sinking.

Uh yeah, both maybe.

But reconstruction is currently not yet implemented in any of these CR clients. So reconstruction uh benchmarks are not yet existing. Uh hopefully in the next month we can uh get the implementation work done on that and uh we will have some benchmarks for that and for the reconstructions it's uh still working in progress. So we also don't have many benchmarks for that yet.

Okay.

Maybe in the end of next month we we going to have more uh numbers hopefully.

Yeah. Okay. Cool. Thanks a lot.

Awesome. Thank you. Uh it's interesting to dive into this a bit and before anyone I mean feel free to raise your hand but before somebody does we have one more question and answered in the issue uh from Mitrios uh about testing beam chain or beam chain includes many uh changes that are not incremental but from different cons mechanism there's also new cryptography but is the strategy to create good coverage tests and predicts on so many new components. So yeah, you can talk more about the the strategy sort of.

Yeah, so uh personally I have I have not yet looked too much into beam chain and u le ethereum how we call it now. Uh it's because it's so prototypy at this point. We haven't our team hasn't spent too much time on it yet. But uh hopefully in the coming weeks we can take a closer look. As far as I understand right now, we're going to need to rework a bunch of our tooling for uh getting liner working.

So that will require us to have an update in our uh libraries to update the genesis generator. It's going to need a total different uh validator key generator as well because it should use post uh quantum cryptography which might mean that uh key generation will take a lot longer time and uh hopefully we can find a way to make it quick on local testing. Ideally, we want to have a very similar uh test speed scenario set up for uh Bchain testing uh that we have right now for Ethereum. So, hopefully we can uh integrate all the uh required changes into the Ethereum package as much as uh we have for the current player clients. So I I expect uh again to have a bit better view at this maybe a month or two from now when we actually have a a better uh beam chain client implementation that's uh that's ready to to test something.

Yes, it's a lot of unknown unknowns and uh the thing is like one thing I would add like uh it might it will require a lot of additions to testing of course but I think it's still not really not even that big as merge even maybe the scope of the changes but uh the testing that we had before the merge is not even comparable to the robustness today. So now we have I think much better to learn from. Um yeah uh folks any any more questions uh feel free to raise your hands or write in the uh better maybe don't write in the chat because I think Jitsu is causing issues and uh I don't see all the chat messages. Um there was one before about why it's panda and not live and I'm not sure if you answered that. Um but it's a it's a very easy question.

Panda ops came from uh the merge testing from um the the meme that Shaw created that you put black and white bear and it's panda that was the merge. So the pandel are coming from uh from this uh this time. Um yeah, any any questions? Feel free to feel free to keep uh raising hands for dialogue um tuning.

Oh, hi. Uh I I also uh wrote this uh actually in the in the uh GitHub issue but is uh with different clients uh uh could you share with us like what is your common setup you use to test one test case or even even a simple one and is there docs uh or more on on how east panda team actually conduct testing on different clients and where that I can learn more about like the whole testing procedures and I can try it out.

Yeah. So one of our major testing tool is assertter. Uh assertter ensures that a certain condition is uh valid. So uh it's also a tool that uh PK has uh written from the ground up and it's it's a tool that basically validates uh I'm not sure if you can see my chat. It looks like the chat doesn't seem to be working for me at least.

Yeah. The chat is not stable.

Yeah.

Yeah. Maybe maybe Mario you can share assertter with APF uh the searcher um GitHub link. So basically uh assertter is a versatile tool that is meant to do comprehensive testing of the clients every every single client. So it it can check for uh CL and E uh if they are up to sync. It can uh submit transactions.

It can uh submit uh BS key changes and then it can assert specific conditions like uh did the BS key change has happened and is the change afterwards still stable. So this tool basically uh just asserts a specific condition and checks against all the different clients that you run in in curts and cliff. So the prerequisite for this is either a crytosis enclave or a running uh test net or net. So we we deploy assertter we can deploy assertter in crytosis with a very simple uh additional uh line to say hey I want assertter to also run in like crytosis and clave and we also spin up assertter on all of our dev nets and uh we sporadically run some specific test uh depending on the fork. So for example, PCRA petra had a bunch of changes regarding uh max cb and max cb introduced so many uh edge cases that we have to write some test uh that we're checking uh you know changing your uh validator from 0 0 to 01 then changing it to 02 then uh submitting some deposit then checking if the deposit has reached beacon chain and check if the effective balance have increased successfully.

And all these tests were basically uh uh written uh with the base components of assertter tests.

Thank you. Another question from Drew. Uh yeah so my question is uh do you have any personal opinion about the shorter slot time because uh I think it's it's there exist a discrepancy between researcher and engineer about the slot slot time. So yeah I I just wonder about your opinion.

I think it's something that needs to be done after I don't think uh it should happen in Glsterdam. I think we need to focus on the swap restructuring first. Uh we need to focus on basically what client teams want instead of pushing for what Ethereum researchers want. Uh every single client team has basically made a public opinion about they wanting EPBS ASAP and uh for sale as well. So there's a huge push for EPBS and for sale and that leaves very little space to do shorter spot times uh for the next fork in my opinion.

Also shorter spot times is something that has not been very heavily researched whether it would break any existing contracts or not. uh as far as we initially saw it would not touch any uh existing contracts but it might still uh affect some uh places more than others. So there's so many unknowns about shorter slot times and uh yeah doing shorter slot time before EPBS uh it doesn't seem like the right choice.

Thanks. That's interesting. Thank you so much.

Yeah, very cool to hear that. To be honest, it's it's tough for the the notes to get faster and faster. Um, yeah. Do we have some more questions? Anyone curious about anything?

Yeah. Uh, I I have one more question. Yeah.

Yeah. So, so a very uh basic question. uh if I I'm interested in joining Pandalf's team uh what's your recommendation uh from now on?

That's that's an easy question. [laughter] I I uh yeah, working on on tooling testing. Uh I don't know. It's it's probably one of the hardest questions uh to ask me. I'm not responsible for recruitment in our team.

We we basically uh want to hire people that are very very familiar with the whole Ethereum ecosystem. Uh we want people that basically know client teams in and out. They know how they work uh and uh fully aware of uh what the future forks might hold and uh basically be uh in the picture of like how to test things because I think right now uh we have the bottleneck of writing tests and writing edge cases and writing assertive tests. it it has became uh a very complicated tool assertter and that means that it's rather difficult to make new tests uh because it's so configurable uh that it's maybe overly configurable at this point. So we are uh working on possibly making it a bit easier by reducing the complexity.

But yeah definitely if if you look at the assertter uh repo and you see that hey there's a test missing and you just want to help to contribute uh then yeah that that would be very very good.

Cool. Thank you. Okay, awesome more questions. We have so many people here who have asked and yet please take opportunity. Um, hey Barnavas, I hope you can hear me.

Yeah. So I'm working on this project with lighthouse where basically because of the pectra incident the whole incident that happened. So we are like restructuring this um caching mechanis caching structure in lighthouse from countbas that is a number of beacon states to a memory aware caching mechanism. So this is the change that I'm working on. But my question is like is there any such ktosis scripts or configurations that we can like use or like in a test net to create such um simulate such like non non-fality like situation or large validator sets so that we can test it out once the implementation is done like how can we figure that out

sorry so you want to create a large beacon state

like how can we simulate such period like uh any in any test net like such periods of non-finality where you can test whether this thing is actually working in like Yeah.

Yeah. So basically crytosis allows you to just stop a validator client and if you have not that many validator clients uh you you stop you know uh 40% of them then you will have a non-finality and then you can mimic uh to try to gain back finality by just restarting that uh validated client. So creating a nonfidelity scenario on CU justice is actually very very simple and you can also do it programmatically using the searchter. So you got to look up some nonpre test in the searchter and uh basically uh implement exactly what you need uh in order for you to be able to do it in a TI test for example if you want to programmatically create an unfinity scenario.

Right? That makes sense. Thank you so much.

Thank you so much. Um, yeah, I'm curious more similar questions, folks. If you have if you're working on uh contributing to a client and you want to make sure that you test it properly before you open PR um you can um you can get some tips now.

Yeah. So basically if you create a new uh container image locally built even and you just run that container image in crytosis and you see that you know if you change something that would modify how the beacon would attach for example and your for your implementation is still working without throwing any crazy errors then that's a pretty good test already. And if you can do interrupt testing with other clients without you needing to you know dive into and figure out how to compile ROS binary for example you can just use a container image and uh you will be able to test inter testing basically locally before you even submit your PR.

Got it. Thank you so much.

Yeah. Thank you. That's that's your advice. Um definitely recommend doing proper testing before u something like final version of PR so the reviewers have less bugs to deal with um to be confident in your submitting. Yeah.

Yeah. Any more thoughts questions for my pass? So um I wanted to ask about your favorite uh pandops tool because you already mentioned so many things and uh I I think might not know the answer but I want to tell you that the lab website is my favorite recently called center data. So um that's really cool. So I'm curious yeah what is your favorite tool and like aboutu like there is something that you found surprising as you started collecting all this data it's still growing of course like whether there was something interesting that you found in the data

so my favorite tool would definitely be the Ethereum package uh as pretty much I've been working on that uh as my full-time job in the past few years other than other than package. It's proh probably second best is Dora. Uh Dora just been really great at everything. And the third one is probably uh Spammer. Uh Spammer just has been so good at uh basically finding crazy bugs and um generating uh generating insane amount of traffic.

And spammer has like a totally different dimension as well to be able to do state load uh basically create massive transactions and and create basically any scenario uh that you want to test in in a very rapid way. So yeah, these three would probably be my uh top top three.

Sorry, there was a second part of the question as well.

Yeah. Yeah. Yeah. I was asking about uh I was telling Yeah. the Yeah.

Was there something interesting in the data there um that surprised you or not?

Yeah. So, Zapu has been very good at uh uh at helping us making good decisions regarding uh whether we could increase the gas limit for example. So we have a contributor uh contributor tool that is helping us feed in metrics into ZATU and uh using basically random people around the globe uh feeding us data and uh giving us observability uh across different countries, different uh ISPs, different hardwares and seeing uh you know the long tail of uh the interesting of the gas limit we can just make much better predictions uh going forward using that.

Awesome. Yeah. Um it is really cool and uh finally having some like real world data and it's it's very useful and it's really cool that we have so many op tools that we can just make like a list now [laughter] it's uh with yeah and also that you mentioned we haven't mentioned it before but uh yeah PK was good and it's so cool that it's just so simple and it works like running the be chain explorer from the the Australian guys right is just so heavy so complicated and we're works like it's so easy to deploy and has so much

I mean they they do have a lot more uh observability in attestation data so that's why their tool is so much more heavy because attestations are especially mainet at astations are super super heavy operation and they keep track of basically every single atestation of every single validator which which is the main reason that uh we needed to create door where where attestation information is basically lost after uh a few epochs. So, we just keep that all in.

Yeah. Uh yeah. I mean, for our use case, it's uh it's just so much better. Yeah. And um yeah.

Uh folks, uh do you have any questions about some specific pendops tool? There is, as you can see, so many of them. So, uh tell us about your favorite one. Uh Irene.

Okay. I'm I'm going to have a follow-up question about the Ethereum package. So, are you integrating in the future new features or do you think it okay which one for example?

So, as I mentioned um we're going to be doing Glamstrodum testing very very soon. So, whatever Glamster requires uh currently it looks like it's going to be uh uh block level access and EPBS and possibly fossil. So those features will be coming to Ethereum package basically as soon as we decided that the spec is uh is going to make it into the next port. So I would expect in the next month or two we're going to be seeing a lot more uh related uh features coming to Ethereum package. Also uh Ethereum related stuff might make it into the core uh Ethereum package as well.

It still depends on how much extra complexity that we'll add and uh if it's insignificant then we probably just going to merge it in there otherwise we might uh create a fork of it and then u guys can also start in on that

great thank you

or what kind of features are you looking forward to because yeah if you're looking for a very specific feature just uh create an issue and uh we can take a I was thinking about like since I working on loadar like something in between some connections so probably everything that you already mentioned is uh is interesting for them. So so far I'm checking um the still want to integrate it because they have their current sim framework but maybe in the future. Um not sure exactly

the sorry the what

assertter.

Oh asserted. Yeah. So assertter is already uh integrated into uh cruises as much as it can. So what you can do is uh you can create a assertter test yourself and run that locally. So

yes yes exactly. But so far they told me that it's too heavy for them to run. So they want to just use the Ethereum package to simulate like the node uh the node setup and use their own uh uh sim assertions and maybe in the future use a setter.

Yeah, that's that that would also work.

Yes. Yeah, we do. We still have some time left, so please use the opportunity and ask us some questions.

Mario, your voice is really bad again.

Is it Is it bad again? I'm sorry.

Now it's better. So, I think you're on your laptop.

Need to be closer to the mic. Um, yeah. Uh folks feel free to ask any more questions because I will seize the opportunity and we have last couple of minutes. So please use uh use it to learn from Bernabas and get some insight. Um So what I'm curious about like um uh whether you uh what do you think about the u the limitation of number of client pairs we talked about across client testing here and now it basically rises exponentially with every client uh having a squared number of combinations.

So um where do you think are the limits or like what is some optimal for the for the network distribution for the client diversity like what we want to strive for there. Um yeah whether there are any existing issues already

I already think we have too many clients. I think uh ideally three or four per and per would be more than enough. I think anything more than that is just basically icing on the cake and not heavily needed. It's the same way as the number of validators on the beacon chain. Having 1 million validators on the beacon chain is overkill.

Absolutely. And this is why we introduced the max. And uh this is why we are asking large node operators to consolidate your validators to reduce the pick and state to to reduce the uh amount of work that a specific validator client will need to do or client will need to do. So I think we are overdoing it already. I

I'm not asking for more.

Yeah. Okay. So, we are already already there, right? It's like 30 combinations now. Six and five.

Yeah. Um Yeah, that's that's crazy. Um Yeah. Okay. Thank you.

Um that's Yeah, it's uh it's a bit of a negative tone uh to end this with. So, guys, if you have any more positive questions, I I'll give you one more chance uh to to ask something before we wrap it up.

Yeah, maybe one more thing from me. Uh so I'm also doing a 10-year Ethereum celebration. Uh but I'm doing it in Budapest. So if any of you happen to be in Budapest today, I will also be giving a talk there uh seven an hour from now. So I'm not sure how many of you are staying in Budapest today, but you're welcome to join.

Oh, that's awesome. I had no idea. So yeah, uh good luck there. Enjoy enjoy that. Very well.

Yeah. Is is Anico doing it maybe? I know she did some meetups in Budapest.

Yeah, Enico is doing it. She's the organizer.

Awesome.

We're going to have a few.

Oh, that's that's awesome. Yeah. Yeah. So, enjoy. And yes, my regards.

That's great. Yeah. Um, awesome. Yeah. I was visiting a couple of weeks ago.

I had no idea about like thinking about Ethereum community there, but it's it's awesome. We have have it all over. Yeah. Nice. Nice.

Um, okay. Um, so before we wrap it up, I I'll have one one last uh quick question about some um some advice or something maybe that you wish uh you knew when you were starting uh in Ethereum or something some advice for people who are now starting to on the in their core development journey. if anything comes to mind.

Any of our tool is basically brand new. So none [clears throat] of them were there when I joined uh Ethereum. So check out our organization and make an issue if you feel like some of the tooling is incomplete or if it's missing a key feature or even better make a PR if if you feel like you're up for it. Uh we are very open for any outside contributors and we are always open for suggestions of how to make our tools better because we really trying to aim to make it even better and we really trying to work on uh making our tooling as good as possible. Um yeah, you're putting me in the spot here right now.

Find the one best tool. I think uh once assertter has been reverted to be a bit easier to configure this specific test that's definitely going to be uh one of the tooling where I would basically push everyone uh making more tests because uh the more test the better and uh creating test is so cheap so we we should be writing test for everything and ideally all new EIPs would be paired up did specific tests as well. Same way as we have now consistency specs and execution specs, we would we should probably aim to have just as many asert test as well.

Yeah, that's really cool. Um yeah, so in the future for uh nice nice thank you so much guys. Um yeah and once again I encourage everyone to learn about the penthouse tools like it's also something that can help you to understand how uh the overall network of just individual clients work under like um it's um it's great resources. So thanks so much uh yeah thank you so much Barnabas we can be here in 4 hours. So uh uh really really thank you for your time and uh I hope you also enjoyed it.

I hope you guys learned something, you get inspired, and uh yeah, I'll see you I'll see you next week for another another one of these. Yeah.

Yep. Thanks for having me. Bye-bye.

Yeah. Thanks so much. Have a great day. Bye, everyone. That's