welcome everyone to the a theorem 2.0
client panel discussion the idea what
this is - well after this morning's
presentations where we saw lots of the
work that's been done and and been given
insight into - some of the solutions
that have come up with to explore more
how we move on from here in particularly
how do we do that together there's a lot
of - togetherness I think in general in
a theorem 2.0 there's there's many of
the the the design aspects have been
centered around trying to coordinate
people be that through the use of
technologies that other people are using
was on the p2p BLS standardization etc
to the multi client approach we're
taking and I think it's a really
powerful a powerful thing as we've we've
we've seen and so I think a good place
to start off with was something we had
quite recently which was the Interop
event this this look great a great
opportunity where we looked well some he
basically locked a bunch of people in a
room to see what happened and and the
results of this experiment was we got
seven clients speaking to each other
which is pretty pretty freakin
incredible and yeah so so so now that
we've achieved that I think that's that
that's allowed us to do to get a lot
further along this this route so I think
you should have some introductions
before we quickly dive into this so if
you can start down that side and have
everyone just say the name
what who they're working on and what was
the sort of one thing that they took
from from from Interop or what's the the
one maybe the the main thing that you
guys are now working on as a result of
Interop hey I'm Ben I'm just standing in
for the great Joe DeLong on this panel I
kind of assembled the Artemis team a
year ago I'm best better known for
what's new in eath to these days I was
at Interop and it was awesome
takeaways I think it's time to press on
to production now we've proved the
concept it works we can interoperate
it's it's very cool but now we're moving
into a new phase with without a Miss and
handing it over to the production team
to do all the stuff like writing
documentation and and searching the
comments for to do and all that all that
good stuff everyone I'm rolled from
prismatic labs I was unfortunately not
to interrupt but uh remotely helping out
the teams there and figuring out kind of
how to get people on board prism one of
the biggest takeaways was getting
everyone to easily run a beacon chain
and a validator mate like we had to make
it easy for everyone and it improved a
lot of our local development a lot I
made it very very easy to launch a
beacon chain with n number of
deterministic validators so that's sort
of standardization that came out of the
effort made our lives easier and
hopefully others lives easier everyone
I'm Alex Stokes I work on Trinity which
is the python implementation of eath -
oh yeah Interop was great as well
probably I'll tell you here the biggest
thing I think we probably all saw across
the board was yeah just having like
these sort of coordinated starts and
like getting these tests nets to
actually like all go at the same time we
have a large number of clients and so we
have some extra fun just like wrangling
all these cats there's like a bunch of
little stuff that we saw sort of
specific to Trinity from the Interop and
the big thing that we'll probably be
focusing on longer term over like the
next I don't know let's say three six
months is a heavy focus on performance
like I said we're a Python client so we
kind of have a performance penalty we
incur de facto so we'll be doing a lot
of a lot optimization there we were
looking at dropping our like really sort
of tight loops and things interests so
we've had some work on like rest modules
and Python which is fun and yeah that's
about it
hello everyone my name is Paul I work on
lighthouse it's one of the rust
implementations
I think one of the great things that
came from Interop was just a lot of
scripts that we can use to build each
other so Yessica built a bunch of
scripts which was great so now we have
we have a bunch of tools that we can use
by ourselves to test with other clients
so that really helps reduce the friction
that we can before we can test our
client against others what we're working
on now after Interop we're basically
targeting feature completeness we have
an RFP for security review out there so
we're preparing for that and we're
working on trying to take a client into
the sort of the tens of thousands of
validator ranges and above to make sure
that we can run nice and quickly and
efficiently with production level
numbers of validated I'm sorry from the
Nimbus team lesson that we learned from
Interop I guess is the importance of
testing our success was largely due to
the very well-prepared a suit and where
there was bumps along the road
this is places where the tests are kind
of missing I would repeat what what Paul
said that one of the most valuable
takeaways was these scripts that allow
us now to run multi client s nets and
now I think we should all keep improving
on them and regarding the future of
Nimbus plant will be planning we'll be
publishing very shortly our roadmap for
getting Nimbus production ready and we
hope to do that in the next six months
hi I'm Desmond from wrong time
verification so we developed a kind of
client but we are not really just
running the client but formally
verifying the client so but I hope
there's some crazy idea of crazy users
use our K client as just adding another
diversity
and yeah but yeah so far we just for
verification
first though my name is Mikhail I'm from
harmony team and the Interop went very
well
and I even didn't expect it it was so
productive as a follow ups we are
continuing to work on EV fork choice
tests like a complex test also we need
to finish sync and was thinking about
start working on Bella stuff finished in
discovery and the main takeaway from
interrupts that we are merging efforts
with Artemis so we probably can avoid
this production really stuff so yeah ok
that's it I'm away from party so I think
I I didn't join the interval on site but
I was doing some similar interrupts
stuff at home trying to get it work
put them all nice it mostly works I
think the most important lessons we
learn is to testing so we were while or
to patched version behind but even even
except that we still have like power to
consciousness bugs from drawing the
interrupts that doesn't pick up the test
doesn't pick up by the tests we pass all
the tests before so I think that's the
biggest lesson we learned testing is
really important also I forgot to say
that we tested GBM the p2p as well as
our client and he fixed some bugs and
it's now compatible at least the stag
that used for Interop is now compatible
with all other implementation like
JavaScript Python and rust and you
I also just wanted to use this moment to
toss out a PSA we're all using the same
BLS library at the moment I believe yeah
so if anyone out there wants to write
it'd be a lot of implementation more
implementations is better on the note of
bilis implementations the
standardization efforts have been
charging forward and we have some more
reference implementations from those
efforts so hopefully within the next 1
month or so we should have what is the
final specification for pls and which is
really a major step forward and means
that basically then that's the me the
last hurdle in terms of specification
that's left you know so moving on and
we've had all these these interoperate
events but we need to now start
transitioning to more organic starting
up of these events and and allowing
nodes clients to properly sync with one
another with with we previously used
scripts and files to start up these
these test Nets but to have more we
allow validators to join into your
network and transitioning into proper
test nets so I would be interested to
hear comments on what how we can do this
and sort of what are the challenges and
what are the next steps in these regards
yeah so I think a huge step forward from
what we had at Interop would be sort of
testing out our eighth one integration I
think most of clients have at least some
form of it but essentially this would be
like having you know some eath one test
nut ideally one that we kind of all
could easily for example produce eath
for or spin up or spin down as we need
and then use that to kind of test ok
like you're saying here's a real world
setting where it's like there's no eath
one network we then have this if to
deployment how can we actually have
validators join and leave but mainly
join
[Music]
yeah I think it's time for
specialization I think we're gonna see
like all the clients at this point now
that we know we can talk and we know
like we have a baseline we're gonna see
everybody kind of splitting down
isolating and like going down basically
challenging you know their languages and
their respective implementations to
whatever it is that like their original
goal was set out to be I think that's
probably will see like half in the next
six months for us as well then the very
next milestone is running test nets
connected to each one and for this so
we've been following the lead of prism
and we've been publishing deposit
contract on the Gourley Network and I
expect that we have some
interoperability with they'll be able to
use ours contract and you'll be using
able to use theirs and so on and there
have been some talks in here with the
past few days one of the clients agree
that it would be beneficial if we set up
a shared organization on github where
everybody has commit rights and where we
can work on and improve these scripts
that allow each developer to bounce test
nets on their own computer on their own
environment so I see two directions one
is public facing test nets running on
each one and then the ability for
everyone to just make quick walka setups
yeah I mean that we really enjoy using
early I think corley is becoming a lot
more of a de-facto standard as well for
like each one devs to test out smart
contracts and it's been really nice to
try out deposits another big effort is
the ARP is like the API standardization
effort that will come over the coming
months so there's a lot of talk about
not having people use the CLI to stake
to run validators you know can we have a
standardized API that allows people to
build things interesting things like
while it explores other things that
allow you to interact with the chain and
that will be a really critical effort
over the coming months as well so on the
note of sharing deposit contracts do you
think it's worth then having one
centralized deposit contract or
earlier so similar for what of this
night last night this makes a lot of
sense to restart them frequent
frequently and then nothing prevents you
from having multiple deposit contracts
being active at the same time you know
basically the client only needs to
specify the address of the deposit
contract that he'll be using just in
terms of the the shared deposit contract
I think something that would be nice too
would be a common onboarding process for
validators I think TF was maybe
considering about jumping on that so
yeah it would be nice if we don't all
have to build you know a million
different little validator onboarding
things than to be superseded by an
official one coming out we also probably
want to test this beacon chain start for
many times because it could be a huge
point of failure I mean the kicking off
from eath one chain to the beacon chain
so it's probably worth to focus on as
well definitely we don't find that often
in production and on that topic I think
it'll also be worth discussing what are
the what a valid criteria how would we
decide that we are ready to do this main
net launch so I agree one of them should
be that we've had launchers bastes based
off f1 and these starts but how do we
actually decide that this is the
finalized version both in terms of we
can specify minimum each deposits and
that kind of thing but also more in
terms of how what we require of clients
to be able to participate in these
networks and and how do we say that this
client should should or shouldn't
participate I mean obviously it's not
gonna be some definitive thing but what
what is a good signal for deciding that
a client is ready for participating in
in am a net launch
I mean yeah that's obviously a big
question at a high level right like I
would expect we want this to be actually
fairly community driven probably like
highly directed by the client developers
themselves obviously there's things like
uptime and performance and stuff right
so for example if we end up with like a
ton of early validators we all want
clients to be able to handle that many
validators I know for example Trinity
like can't scale to like the theoretical
max right now like we just don't have
the performance we'll get there but
we're not there yet so these types of
things are like it really important
qualifications you know at a certain
point it's hard to say like are you
ready you can always defer and like do
more testing so a certain point you just
have to like you know I'll say well
these are all sounding really negative I
was gonna say jump off the cliff or
something but yeah hopefully we know it
when we see it and we're like okay we
all feel good here we go yeah I agree
the story that there should be some we
should start testing with some the
parameters that affect the performance
of the network we should start
validating that each of the clans is
ready for this but our own roadmap is
also built around the need for security
for performing security audit on our
code and this is a pretty complicated
thing to plan out because it requires
you to freeze a lot of the code so we
are currently creating a plan that will
allow us to create sort of a pipeline
for smaller and smaller components that
will go through audit and then bigger
and bigger parts until we are ready to
answer yeah as country comment along the
same lines I mean in this network you
can't prevent anyone from saying I'm a
validator and being part of a network
Ronit that's the whole point
so it requires client teams need to take
responsibility on the one hand and so I
think exactly right audits are going to
be important one of the very strong
differences between aetherium two and a
theorem one is that in eighth - we need
to do online signing you have to have
your key available to sign in real time
which is something that all the f1
clients and nodes have moved away from
over the years
because it is really hard to do it
securely so that's going to be a
critical point where we need to focus
audit and security effort on that and on
the other hand users need to be kind of
wise as well because they have to choose
a client in which to to run and to stake
and so forth and I think the best thing
we can do there is probably to have some
joint benchmark suite or you know some
make is all about information right and
making it consistent and so people can
compare and contrast and you know
understand which is the client that
meets their needs but yeah I definitely
like to see a diversity I think it would
be a shame if the network were dominated
by one client more than 50% on one
client would be would be a pity I guess
another point of point of importance is
formally verified the safety and live
needs of the beacon chain so amazed you
know that I mean in the paper was the
paper that proved these two properties
on that the abstract model of the beacon
chain but reality is the implementation
has caught a lot of the optimization and
also it's slightly different the
finalization rules so you also make sure
that those differences
doesn't actually break the safety and
avenues so yeah that's our actually
calling in our end you wanted to finish
the phone verification before others are
actually ready to release and the the
safety of all our clients relies on this
assumption that someone's gonna slash
bad people I don't know anyone that's
got a slash of working that can that can
efficiently run they can efficiently
cover the the distance that we need and
it's still in research as to you know
how exactly can we how can we store all
of the previous votes and efficiently
search them so we're really we're
definitely going to need
Slash's out there and I think they're
gonna have to have some degree of review
and guarantee that you know they're
watching and they'll get you adding on
to that quickly you also need like
slashing protection right so like in
terms of like infrastructure providers
or people that are they just don't want
some sort of crazy situation with their
infra to cause them to double propose or
double sign so that's also something
needs to be built in and users will be
asking for that I totally agree with
everything that Ben said and one just
yet that we might probably need some
more QA stuff like fuzzing we want to do
cross client fuzzing to find tricky
consensus breaks that could not be
probably fine
it could not be probably found during
test net runs and also we need to expose
basic interface to chain data to build
even primitive block explorers around
that and to get some network monitors to
understand what is going on so yeah
that's that's my point
another fun thing leading up to
production would be incentive ice test
nuts so in a cosmic community they've
done some of this with the game mistakes
it'd be fun if we do the same thing get
together prize pool and the idea is we
have a test net public test net anyone
can come and go and then try to keep the
test no life other than everything would
be like actually talking to validators
or potential validators and like getting
their input sort of been like a product
feedback typesetting I think we were all
very focused on like the spec and like
the engineering and like making really
nice sexy clients but definitely it's
like for physio who are the users of
these things well validators so talking
to operators of validating that
validation pools and not actually just
pools but validators in general and yeah
seen seen how that process unfolds sorry
one more I think we need some interest
from external I get guys know inclined
developer team
you eye people so I think a lot of the
client developers where systems
programmers and the idea of choosing a
color makes a sweat so it would be great
to have and we don't we don't I think at
the moment have maybe a few of people
that are like you know front-end devs
that are that are interested in building
UIs for this and it'd be great to have
these things as a common good that lives
outside of the client teams that gets to
love that they deserve and on top of
that I think it's very important for the
the general validating experiences to to
not only just help them with the general
running of the clients but what happens
when validators get slashed how do we
notify them of this or when there's this
major chain consensus how do you if your
clients not updating or there's
something did this there's some
fundamental issue how do we notify
clients like of these problems and I
mean we could trouble you have some
central solution which sends you an
email or something but having people
register they validators with such a
thing as a kind of scary concept from a
privacy standpoint so how can we how can
we enable these kinds of things which I
think also very important for the for
the community and and to help validators
understand a what their clients doing
and how they can stay on to all the
things cool well with that I think cuz
we were heading into the final minutes
yeah I'd like to open the floor to
questions for anyone who'd like to talk
about anything related to immediate
future v3 Pune I'm somewhat forwarding
this question from Philip casting guy
from horizon games and the fairway and
Ponzi scheme revelation my name is John
Marlon I do security audits so I'm not
adaptive but I know a lot about smart
contracts and his question is about like
the migration process and if there will
be if there are plans for doing any
migration testing for gaps moving to the
youth to maintenance
test night
yeah no definitely so the the migration
from f1 to teeth et tu is clearly
something that came up in the
discussions yesterday too and and is a
very important thing and clearly a pain
point for the community I think that's
something everyone is nervous about we
have this great community within varium
one how can we we transfer that as
seamlessly as possible we don't want
bugs in any of these scenarios the the
verbs the challenge with answering this
question is that right now we have such
flexibility in the space that is very
hard to answer exactly what this is
going to look like so it is some form of
moving routes between earth 1 and E 2
and we will have an execution engine
which allows each one to run very
similarly to how it does right now and
that will be very well tested for for
these kinds of purposes but I think the
the the challenge here is we're trying
with with these execution environments
that allow us such flexibilities and so
many possibilities we trying to not lock
ourselves down just to to committing to
saying exactly this is how it's gonna
work right now because that starts
closing down the the design space for us
and and it could ultimately end up in a
worse product so the the answer to that
is yes it will be tested there will be
some migration path exactly what that
looks like I can't specify right now but
we did that will definitely existent is
vital for for the continuation of a
theorem 2.0 and just add on to that like
concretely there's definitely an
intention to essentially move eath one
into the new eath 2 infrastructure in a
way that you wouldn't have to migrate
your adapt and it would just continue to
run not quite seamlessly there'll be
some sort of metadata updates of like Oh
new network new chain that sort of thing
but in terms of like you would enough
like rewrite your DAP or like do these
things that being said there will be an
opt-in upgrade path to go to perhaps
this new type of EVM ee that karl was
alluding to which you get like a lot of
honestly like great improvements on top
of what we have today
so yeah keep an eye out and I think a
lot of this ties into what Griggs
presentation was on earlier on Harvey
making connections and building common
tooling between these these frameworks
and it's very important to have these
intermediate tools between the two
chains
it's totally having a easy path for
upgrades is definitely important and
it'll be there something else worth
considering too is that you know if you
if if you've just gone from like this
pocket calculated to this like
multi-core like thousand times faster
machine that perhaps a refactor is is is
gonna be important for a lot of the taps
like we're not not saying that like
you're gonna have to refactor but you
got a lot to do it like you got a whole
new space to play and now so it might
might bring a refactor might be what you
end up choose doing because it will be
better for your customers or not
customers people that are using your
thing opting in without any control from
you where's this conversation happening
where do you guys like you know interact
with the DAP dev community so they can
ask those questions it's hey I can speak
on behalf of that a little bit like
we're a little bit early still you know
that's like phase two and to be quite
frank like the role a lot of confusion
around this is because like some of the
as Carl explains it like the design
space is so open but it makes it also
super complicated like a lot of people I
feel like rethink the way this is I mean
how long did it take most developers to
actually understand the EVM like two
years
like before people like fully understood
so it's gonna take some time to
understand these new concepts and once
that happens you'll see a lot better I
don't think it's immediate to fully
discuss with them I think the first
priority is just talking with like
tooling teams to understand that we can
better help them and concurrently going
with adapt developers yeah the quilt
team deserves a plug here - they're
building a simulator so that you can
build II's or tests on top of e's
without needing all the chain
infrastructure you can just start a
process and start start testing so
I think this is something that's gonna
really enabled app developers developers
to get involved because it's a bit a bit
low level at the moment I think for them
but it's opening up to them so we were
at interrupts to lose my blog and we're
very grateful I think we was fun to work
with out of you
we did a couple changes so that's also
an announcement for change safe in
particular so we support alpine so we
don't be to mess around
if you alpine for docker images so it
would be pretty easy for us to set up a
test it was your stuff I think we just
do you have a docker image okay cool and
Wade you have a docker image as well
okay all right so if we can help in any
way we're here to help right yeah just
give you this like credits and fonts
with that so please involve us and we'll
be happy to a couple you you know
probably know like some of the eath one
core core devs but usually a lot of them
are kind of like detached so it's like
if if there were some things with eath
to designs that you would want them to
like try to look at like maybe each of
you it's like what what is it that you
would really like them to look at
because there's a lot of brainpower
there as well thanks sing strategies
[Music]
we're running out of time so can we use
this as like sort of a wrapping up thing
as what yeah data serialization API
standardization efforts okay this is not
just a single line still working on
Trinity we actually have a focus of both
eath one any two so I actually feel like
I've been exposed a lot to a lot of the
eath one efforts and ongoing two things
and like really from what I've seen like
both groups of quote weirdos are like
starting to really just tackle the same
questions I could pick one that comes to
mind is like state management and things
we obviously want to like you know we've
seen what has happened on 8th one in
terms of the state growing and growing
and growing and we want to you know
basically find a solution 8th - we're
like that's not going to be a problem
and yeah like the law there's lot of
cool ideas are like state those clients
and things that again have application
in both domains might be I think a good
thing we can learn is what to and not do
with in terms of governance what we have
right now with anything point to is if
they're 2.0 is the research team I think
leads a lot of the decisions and so
there's sort of a central shelling point
which exists much less than a theorem
1.0 and the idea is that the the
research team wants to have less and
less of this role but how can we do this
in a manner that prevents deadlock and
allows for continuous innovation I think
a lot of lessons to be learned from F
1.0 that I'd be willing to take anything
I'll take any advice from any of the
people that have building been building
as one or Bach chains or people like
anything they've got bringing here came
for it I think there's a lot of who we
can learn about right clans how to
create light trance from it one and on
the other hand ATM one will greatly
benefit from the fact that the e to
chain will be finalizing it one as well
so it would be much easier to create
efficient light clans for it one but the
instant evasion schemes the dog
balancing of the requests this these are
areas where we can share the solutions
and and on that grant I'm kind of
excited about the possibility of each
one incorporating the p2p support in
some way this is some something that's
possible in the future
okay probably yeah I'd like to take
advises with Network reputation systems
connection managers and sync strategy
and optimized incremental storage for
this state yeah that's it I'm actually
mostly like related to both Israelis who
I'm actually both curved like a lot of
parts of pike were a couple really issue
like the thing is for like currently if
like probably all of you know the unis
when we have a breaking change that
creates a lot of conflicts
I hope we can try to avoid the same
situation I mean stew by designing the
execution engine biter like make it
forward cut Cabello from the beginning I
think that's something quite important
it's also really important to consider
future changes of webassembly because
there will be a pwease a diversion is
that's how the web works that will be
how webassembly specification works so
how do we incorporate those new features
adopted in web assembly into our my
person reacts a fusion engine as to I
think that's also something that's quite
important to consider just quickly
before Carl wraps this up I just wanted
to just to announce that we're looking
for a senior US developer if you are
rust developer and you wanna work enough
to come talk to us thank you
well thanks everyone for attending that
thank you to all of the clients
represented here and I'm really like
excited to see the DVP work that's gonna
happen these these incentivize test nets
this may net launch which is like this
is this incredible event and then this
time next year I look forward to seeing
all of you back here on stage hopefully
we can talk about these experiences
we've had all in good light and yeah I
hope there are things very exciting to
see where this is going
thank you
[Applause]
you