[Music]
all right hi everyone my name is scansa
and my project is beust metrics
specifications um so um U miss the slide
uh I'm not going to dive into what is
spear do uh it's been it's been
mentioned already so it's scaling
solution for data
availability and um all of you know that
uh etherum protocol is built with a um
according to the consensus uh and
execution specs um so uh but the metrics
for different clients are different I
mean uh we don't have uh the UniFi
metrics for the
clients um it's challenging for ceps to
compare the different clients uh and for
for the devops team it's challenging to
um to monitor all the clients there are
a lot of
them um and it's also difficult for
research to uh get the unified data to
synchronize the
data so the solution is One dashboard
for all clients and uh the unified
metric
specs uh so how it worked
before uh we
had sorry we had uh different dashboards
for every client uh different graphs uh
so uh to compare different clients uh it
was quite painful
uh what do we have now for P D um we
have a single dashboard with different
clients um the metrics implemented for
grandine for Lighthouse for um taco and
um grandine Lighthouse Teo and prism a
little bit so uh for this dashboard you
can apply
filters um you can choose if it's a full
node or super node um you can uh choose
one client two clients all clients and
you can also choose an instance and
compare or monitor or wherever you
need let's look at some examples um uh
this blue client implemented some
feature this one is piras and um uh the
filter is for full nodes and it is
obvious that there are some issues with
it because other clients um for full
node they have less values and this one
looks like super node this is the case
for
investigating
uh so the next one is obviously uh there
is some issue with one client uh which
devops can catch V visually or can
um can apply the alerts grafana alerts
as
well um for researchers the this uh
dashboard is helpful because they can
build benchmarks uh for example here you
can see two clients and they have the
same metrix uh so this means that
probably the case The
Benchmark with specific um
numbers uh this dashboard is also added
to curtois so uh whenever you want to
run curosis and you need a beard
dashboard it's already there so now need
to build your own
dashboard um the dashboard is already
actively used by jimy by Sigma Prime um
this is his notes about um no pust notes
uh super notes and full notes bandwidth
uh and you can see the graphs from from
the
dashboard why hasn't it been done
before because um especially before the
merge there were not so many clients and
it was manageable but why do we need it
now because the ecosystem is growing and
there's more and more clients not so
fast but anyway the uh number of clients
grows and as Perry told me plus one
client is 10 time consuming mean for
monitoring for testing
Etc so the benefits of metric specs uh
it's easier to catch errors um it's
easier to save resources of teams so you
just save some time or um for uh for
building for testing Etc um it's easier
to compare clients which sometimes
really important and for researchers
it's easy to create
benchmarks um currently padas metrics uh
specs cover um the main points of pias
uh they computation inclusion proof uh
kg verification reconstruction gossip
verification and
custody and uh they also um uh in the
discussion gossips up and lipop metrics
with labels for for p
do uh this is the current state of
project uh some of the metrics are
already implemented uh some of them are
open PRS um some they need a review or
need an adjustment and I hope to cover
all this um table but that's not the end
the road map uh sorry the workflow for
the implementing metric is kind of like
this we discover it on um we discuss it
on uh pus breakout rooms uh then uh put
it into the GitHub specs and then
develop test and if researchers need
then um create a
benchmarks uh then process of reviewing
goes and if it's needed then the circle
starts again and if it's not it's
merged uh but this is not the end so
puras metrics are only the beginning I
would say um the next goal is
to uh spread it to uh consensus clients
and later to execution
layer um I would like to wrap up with
the words of a poet such an i client
diversity for the win uh so um this
project um presents uh ethereum values
uh such like client diversity and
collaboration and it wouldn't be
possible without my mentors Perry and
Barnabas from E PES and Dimitri from te
and Jimmy from Lighthouse I also worked
with different teams uh prism with
Grine uh I had a feedback from megalops
um they are
researchers um so yeah I'm going to Pro
proceed with it
thank you for your attention if if
you're interested in any details you can
scan the code and thank
you all right thank you kacha any
questions for
Kia thank you Josh and Mario that's what
wonderful I may have missed it but how
are the metrics being collected at the
moment is it being produced by C
CIS um if you run it on cortosis yeah
they are collected uh uh using pereus
matrix it's like standard stuff yeah but
devop team also has their own databases
on Victoria matrics they collected there
so these um specifications are more for
internal use uh for devops team for
researchers but they also available for
uh public usage
uh you mentioned CL specs do you know if
there's any work being done on that yet
uh no no but we're we're in discussions
about uh uh building specs for um lipop
and gosip sub because yeah because they
are already in production so it's
difficult to kind kind of synchronize
them but we're trying to find the
solution
uh how do you think would it be
useful yeah you find
it have lots of lots of lots of metrics
um and the teams also have their lots
and lots of metrics so
find be the
EAS a
this is not a mass so um teams can also
uh create their own metrics if they need
like more or in different ways so but
some of of some of the points uh would
be great to be synchronized in any
points
yeah so um is it correct that uh you uh
implemented these uh PRS in different
client teams like different clients or
did yeah okay so do you see this moving
forward to add these metrics across all
the parts of the clients do you see this
as something that uh you or the devops
team would do or is it that the client
team themselves have to implement these
um like going the way how I see it so we
will start we will get used to it and
when the new for example EIP or any
other feature is delivered later which
is not yet started the process is for
example in
research um with building the specs for
the clients we can advance at least like
the we can mark the point where should
be the metric and the clients uh during
the building the feature the IP uh they
could bring bring it right into the
right place so I I hope I won't do all
the metrics for the clients so the idea
is just uh to bring this process so it
came natural and uh not that painful for
teams all right thank
you all right thank you Kata thank you