Meet Fusaka/PeerDAS + Runtime Metrics

Transcript

Okay. So, hi. Um it's my second time you see the first time come. I'm very proud to be here. I'm David Milbacher representing the Rock Logic company. Um and we are talking about today about um Fusaka, Peer Das, and runtime metrics. And about this ominous um Sterum Labs. So, what is my today agenda? I mean, basically it runs for getting answers about Ethereum client behavior. But, first of all, I want to say who we are, then what we did want to know from everything like that.

And how we solved it, and how it might impact you. And then, of course, what you're waiting for for Sika Fusaka and Peer Das metrics. So, who is Rock Logic? Rock Logic is a company that um is based in Austria. Um is now ISO 27001 certified. And is running in the Lido curated set. And is so active node operator running day-to-day on production.

And we are one of the few who run 37 client combinations. Six um execution layers, six uh consensus layer, and standalone Aragon Kaplan on bare metals with 90 days metrics. So, we do this every day. So, that but now I want to go into historic of Rock Logic because so you can um get why what we did. Um what I want to say is um we we gave what we first developed was Sterum launcher. And we wanted to empower the Ethereum community to spin up their own nodes in every client combination.

Um you can you can use it. Then we um invented Sterum Plus, which um gave you the infrastructure to run it on if you don't want to go with the major um companies like Hetzner and everybody else. And now we thought about, yeah, we could talk about Fusaka and Peer metrics, and we will. Um no worries. But, we want also to empower you to to to to do such analysis. And that's how we came up with Sterum Labs.

So, um if you're not a node operator, I have to say um um you something it's um not like you um truth. Getting answer about Ethereum client behavior is very painful. And if you do your analysis um yourself, you have a lot of dashboards. You um navigate dozen panels. You have to write queries. You have um always asking yourself if you're um looking at the right metrics. And if you're running actively at 3:00 a.m., you don't need you need answers, not dashboards.

So, if a client ships a new uh client app ships a new release, you always find yourself in a room with the same painful questions. Did it help or hurt? How many uh on how many help pairings? And compared to what baseline? So, here it comes, Sterum Labs platform. As I said, we run 20 we run um all major um execution layer and consensus layer combinations, and one standalone Aragon Kaplan. And we um have 20 plus dashboard that help you um to monitor them and answer all these painful questions.

We run them on isolated bare metal nodes. We um make them re- real reput- reproducible comparable data. And yes, we got an Ethereum grant, so thank you very much for that. So, but uh the the final thing is but dashboards have limits, and it still takes a lot of time to compare all these metrics, even if you have um good dashboards. And we wanted everybody to make um clear um or get to clear results. And that where AI came in.

So, what are you able now? You can ask now an AI chatbot to compare this growth between Geth and Aragon over the last 30 days. You have um the ability to check if the update of Prism um what um imp- imp- what affected the resource usage. You can now ask um what how the memory uh changed on Lighthouse in the latest update.

And this proper analy- analysis, which with with real numbers, don't take you uh days or hours. It is here in seconds. But, as we see um with AI, the question always is, is it just another wipe coded um yeah, hallucinating AI said. And that's where the secret sauce in our company lies. Uh we have a lot of experience in running nodes. And so, we we trained the AI model um or had made the instruction so that you can really see if which metrics matter for what combination.

We also learned it to see normal ranges for pairings. So, for example, three gigabyte in RSS for Prism and Geth, that's just fine. But, Prism and Besu, for example, this is a red flag, as you might know. Um we we we have also the metrics of client um architecture differences. So, we for example, memory models. And of course, um one painful thing um also the query sequencing. In which um in which order you have to run the queries. Everything is answered by AI.

And here's a proof. There's also a report we um published just a few days ago. So, if you want to scan it, um it's yeah, I I it's a Chrome QR code. Um not hacked. Promise. And um you can easily see um on average, the memory is minus 5.1 um percent. The block processing is faster. The peer count is stable. And CPU is very mixed on um depending on the combination.

So, but is this enabling um or what is in for you as an as a node operator? What what what could we help you even more? And that is where AI alerting is coming in. Of course, we set normal alarming. So, we have near real-time alerts. For example, the attestation rate dropping. For the disk um usage um exploding. Um for the peer count drop. But, also for security reason, I will come back on that later.

But, of course, um just having the stats and having an alert doesn't answer you why some such thing is happening. So, we implemented also an AI root cause um analysis so that it gives you um over a webhook that um uh is triggered by the anom- anomaly um a um real explanation what you have to do. And not within minutes, but in 5 to 15 seconds. So, what is also very useful is as we run all 37 um combinations,

is it gives you this baseline. So, you can always answer with every question you're ask- asking is it happening to the whole Ethereum network? Is it just happening to this specific client version? Or is it just in my local environment? And this could be also a very helpful for security as a we- but we always also do a security monitoring. We do checks on every login. Um we we do um a restart restart analysis.

Which, for example, um can make the change if, for example, the uh peer recipient changed, we would give you an alert. Uh this can um mean big money loss. And um and of course, drift detection. So, if your configs changes, AI will um warn you. So, this brings us to the next question. How could this um run on your system? How it will affect you? Um And of course, the one thing is um to have it as a um a software as a service as a platform. I think that's right for researchers or for small node operators um who want uh to come. I will ask uh I

will tell you later about um um yeah, uh how you can onboard. But, there is also pool model. And maybe I have to enforce that we are um ISO certificate, so it's very safe. Um we will scrap your data um on your Prometheus in endpoint. And your data will never enter our system. It's just on the AI interference level. So, you will never have any trust issues. But, if you have trust issue, there is even a more, um, direct full control way how to run it and that's is on premise already running.

Um, you will get the entire stack in your infra. Um, you get your own API keys and your data will never leave, um, your own network. So, that's the third option. So, what makes this unique? Um, of course, the coverage. Um, 37, um, client combinations, I think that's um nothing every else is running currently and we're monitoring and analyzing it and we have historic data over, um, since since September.

Um, of course, the instructions set which is based on years years of, uh, staking knowledge since merge and of course, our security expertise trained, of course, by the ISO certification but also on a long experience on running, um, nodes ourselves and, um, dealing with with every issue. Yeah um the current status, um, I think almost everything is running and the rest is coming soon in Q2 Q2. So, if you have want to have access to a AI alerting and security monitoring, yeah, um, just connect and you might get

early access. So, okay. Um, what I now, uh, and now I'm coming to the thing you might finally came for and, uh, it's just an, uh, overview of what, um, Fosaka meant, um, for the ecosystem and we want to enforce you, of course, um, to to to do this yourself in the future or if you have any more specific, um, a question to it.

So, what are the results? The network RX dropped by 60% the CPU raised in average by 30, the memory um is down, uh, 8% and the disk crease, as probably expected, is down, um, half so a drop of 53, um, percent. So, what we could say in average overall Pyrus trades a modest CPU for massive bandwidth and IO savings. So, um, I think, uh, we can see it this is a very, uh, significant drop, uh, cost reduction. Of course, on non-supernode pairings, I mean, it's the only thing we could compare.

So, here's some highlights maybe for the consensus layer. Um, yeah, Nimbus is currently the most CPU, um, intensive Pyrus implementation. Lighthouse is the lightest and, um, Grandine and Nimbus have all both a very a significant memory improvement. The on the execution layer, um, well, um, Besu has has the most overhead, um, and Nethermind and Erigon, um, is the only, uh, the only the only implementation that reduces CPU and Besu, um, is, uh, 35% drop in, yeah, also in easy memory.

Okay. So um you can now connect with us, um, getting early access. Um, what we are always searching for for researchers that want to run in our infrastructure, all client teams, um, all client development teams, um, getting access to our model. Um, that's that's based on the Ethereum grant so if you're in if you're a client team, please contact and ask for us.

Um, yeah. And then there's only one final question and this is what would you want to ask your infrastructure? Thank you very much and if you want to connect, please scan the QR code. >> [applause] >> Yeah. Questions now? Yeah, if you want the questions. A small one. Okay.

Okay. Thank you very much. Thank you.