[Applause]
[Music]
hello everyone shall we and finder and
foundation research thing so in research
team we do research on the next
generation in certain protocols and we
also drew some proof of concept to
verify our ideas so today this is a
lightning Hawk and it will be more about
the implementation part
so first let's a quick recap that now
may already know that from Tally's talk
lab Casper shouting and pick random be
concerned they are all together right
now and we I prefer to call it serenity
and know these circles our current world
is server 1.0 and poof up work chain and
the serenity is quite different but it's
still extension of the external 1.0 and
we will have those fantastic future like
the four pop-ups take a good random
number generator and the blockchain shot
in for scalability problem and we will
have a whole new brand brand new beacon
chain and many xiaochun's in this
ecosystem to realize it so if we
abstract the different chains into okay
make it into three levels so the if I'm
a user of the faux fur auction I can
make a deposit country on the pure
double chain I mean I say I can say that
hey I want to pass it at my 32 Easter
and I want to be for one of the other
editors and the validators is a long
list of the visitors and those letters
will be sued or Rendell a travel into
many groups
we call that this process the community
shoveling
so the mention is still here the pure
documentary is still here and the blog
is proposed but when we do the big hunch
and black proposed the pecans and black
will point to a reference make a
reference that point to the
proof-of-work chain and there will be a
committee lack there will be a sight and
be able to verify and attest earth
become black
so this committee they have to send
their vote them super to say hey yes
this blog is valid and then we call this
process the attestation so instruction
is similar the Charter will also be a
committee that will be assigned to
validate some specific shot block and
the shopvac the vehicle we have to
verify this blog and make their
attestations so um the following process
is similar just propose a block they
refer sit and notice that the retention
Park and shadow can be fast early and
the proof of work chip so that's the
simple high-level overview of this
system and I won't know when focus on
long talk about the kind side so I think
high is the heart of Israel right now
we never happy to have many deaths and
things they are working on the system
and we want to shout out their name here
we have harmony lighthouse lost our
numbers Pantheon's prison and parity
substrate Chester and Trinity we have a
active highs right now
and now research team and always find
their researchers develops we are
walking on the open source you have
repository and it's a community walk and
everyone can make an issue and get some
input down here and I also wanted to
shout out to Danny Ryan and he he
organized by weight to you community
call and so are some ongoing discussion
with Rico Thank You Danny
and all these pies they are all open
sourcing up I think yeah um with this um
a strong community we can have a chance
to read aside idea black transistor so
that's some example that list are some
question issues that we are working on
for example that because there are many
roads on the internet for the proof of
stake system because everybody literally
have to broadcast their individual votes
to say hey this block is valid or and if
we want to have them like thousands
shots in this system the trapeze is not
good for network traffic so how to make
how to build an efficient signature
application protocol or in the
cryptography thinking that's a problem
and also we have a chance to change the
IOP data serialization into something
more efficient or simpler
and for the name walk scilab there's a
problem is that because for I'm the I
say that the validator will be rendered
I traveled to a stylist I will be aside
to very day sounds basic shot English
basic Thai slots which means that when
the condition by later they will they
will be asked to hey I have to wear it
it welded shut lock like in ten minutes
for example then they it's easy in
protocol but if we say that in the
network layer they have to move their
peers they work in two different network
so it will cause a lot carnation tie to
the peer discovery and thinking so we
need to redesign a new technology and
new pH management system to deal with it
so our current idea is that we can use
the liquid to pick a zips up china's to
gossip channels to like a sigh of shot
for sounds basic channels in that way we
can reduce the connection overhead and I
like to spend some time for the
presentation so because we have a big
concern reference that and in a flag
effect the current spec but now we also
want to hold it in to the production
environment because I want to make a
test now in Python yay
and Trinity is the seventh one point
okay we've built with Python led by
Piper Miriam and his and his team the
snake tremors and it's open source now
you can check their website and link to
the repository and if we see the
architectural layer by layer there will
be an echo layer and state extrusion
they're like beacon chance state
machines different from evn it's quite
simple and for a shot we will have like
it wasn't in the system and different
chains and different Kairos because we
now we are using the validator or not
minor and the last I want to encourage
you to check out those resource if you
want to participate more and I think we
are doing something really cool here and
thank you for community contribution and
thank you for your listening and next
Ron found prismatic left he will give
you a talk about their golden exultation
[Music]
all right well so thank you shall we for
the amazing presentation I think it's
been so incredible how ever since kind
of the etherium charting efforts first
spun up there was essentially nobody
working on this there were a few
reference implementation a few reference
specs out there a few blog posts but in
the span of less than a year there have
been more than eight teams just
aggregating coming together and putting
together something that will work in
production as the next iteration of our
platform so today I will be talking
about implementing prism which is our go
client for aetherium 2.0 and I just want
to give a little bit of a background
kind of who we are so my name is Raul
and I am the co-founder of prismatic
labs so we are an independent team of
developers that aggregated to build an
implementation for shardene Kaspar and a
general upgrade to the etherium network
there is no token there is no there's no
presale there's nothing of that sort we
just want to create a public good we
understand how powerful this would be
for everyone to use and we want to
create something that is
production-grade using the best software
engineering practices to build a client
like this so
so why exactly did we start and how
exactly does this happen
so we fast-forward kind of we'll go back
to the late 2017 where italic had a
basic charting FAQ explaining the
possibility of having a parallelizable
world computer this was the start of
kind of a new initiative there were it
was very very high level in the sense
that it didn't really go into much
detail of how this would work you know
like how feasible would this be from an
implementation perspective and
essentially a bunch of a bunch of
blockchain developers like me and my
team were you know scouring gaiter going
through github issues trying to get a
grasp if like this is viable or not so
we started asking ourselves who is
working on this who wants to work on
this and just join us on an
implementation effort so we put together
a call on reddit and our whole team
assembled organically through the
internet and actually this Def Con marks
the first time all of us actually meet
in person so it's been an amazing
amazing time yeah so what does it mean
to work on earth 2.0 working on s 2.0
means at a very high level operating
under constraints and we have to
understand that we have a currently
functioning you know maintained client
that runs a proof-of-work chain right
now where there are real people with
invested at applications bid alerts as
we've seen and a lot of a lot of
initiatives to kind of keep this going
and make it into you know make it as
robust as possible so we can get to our
goal of achieving a world computer the
problem is that when upgrading the
system this isn't exactly going to be a
hard fork so what this means is that a
theorem 2.0 shall we explain it's going
to be a side chain of sorts is going to
be basically a parallel chain that is
then pegged to the proof work chain as a
way to create a full Kaspar FFG enabled
proof stake chain and what this means is
that we must have to be very very
careful with our crypto economic design
how we are more people into the system
and how we can get the same level of
scale of usability and a much much
larger level of throughput so what is
the road so far ever since we started in
around January of 20
we initially started doing a biweekly
development update we wanted to be as
transparent as possible about these
efforts we understand that given the
spec is so kind of young we need as much
discussion around some of these problems
we need people criticizing many people
coming in and being like you guys should
not do it this way you should try this
way instead aside from that we've been
big fans of having extensive onboarding
documentation so we've been able to
onboard a lot of contributors that have
not been as familiar with aetherium 2.0
to be able to come in and just build out
parts of our implementation we've been
leveraging get coined extensively so
thank you very amazing tool it's a it's
an incredible tool every time I make a
bounty we get tons of people just coming
in and flocking to it and it's just been
a great experience just onboarding
people into the community I think that's
that's the way to go aside from that
we've also been doing bi-weekly
development updates so we've been
frequently posting about everything we
do and on October 3rd we released our
very first POC of the current beacon
change as per spec and yeah so what does
it mean to create an entirely new system
it means that we have the opportunity to
make better and more robust design
choices so in that sense you know we've
been like aetherium as kind of italic
puts it was kind of a scrappy attempt to
build a work on the world computer and f
2.0 will actually be the world computer
so under this set of constraints we have
to consider you know how will the
underlying tech stack improve this
efficiency and reduce as much overhead
as possible so we can maximize the
throughput that we get from the system
as well as the usability so one of
things that we've been using is there's
a lot of kind of a lot of discussions
around all the ES 2.0 teams using Lib
PDP which is a very popular networking
library maintained by protocol labs
aside from that we've been using
Google's popular G RPC framework for a
communication between processes so we
want the friction to be as little as
possible we want nodes to be able to
just work you can spin up a node you can
communicate you can run a validator
client you don't need to think about it
and in our eyes what we see a
scalability of a blockchain is truly
having a base layer that does this job
good enough so the applications don't
even need to consider it aside from that
we picked go as our tool
go is an incredible language for
blockchains in particular where you have
so many concurrent processes
it's very concise and what's really
great about go is that you know we're
collaborating as a team it feels like
almost every file has been written by
the same person or the same group of
people because it's so strict and how it
does things aside from that it's very
batteries included so it prefers
simplicity over magic we have a lot of
other languages that just seem you know
like they're written they're coming from
some arcane alien knowledge and there's
a lot of crazy kind of constructs in
there
however with go we have the simplicity
that everyone that wants to contribute
to a blockchain project they basically
can just come in they'll understand
what's going on in the code all they
need to understand is to read more about
the context read our documentation and
we'll always gladly onboard them so we
we believe in the power of Geth gas has
been is an incredible project it's been
battle tested it's gone through a lot of
upgrades and even then like it maintains
you know the robustness and flexibility
of a language as greatest go so exactly
what does prism encompass as a client
for you guys we are careful to design
this knowing that a lot of people in
this room will probably be using this
client as a theorem 2.0 launches and we
want to be sure a great developer
experience as well as user facing piece
of software so if you guys check out our
repo you know fully open always welcome
so it's prismatic labs slash prism we've
put a lot of work together on
implementing the beacon chain making
sure we have up-to-date documentation on
how this works have parity with the spec
one of the biggest things is that were
very much we aim to be very much on the
bleeding edge the thing about the
interim 2.0 spec is that it's very much
still in the works so there are a lot of
core functionality and logistics about
how the validators will work that are
still kind of being designed a lot of
R&D efforts specifically around the
cryptography behind this and we've been
taking we've been a little bit more you
know we've been taking a little more
risks and implementing something further
ahead so we've been careful with you
know kind of how we design the system
what architecture we pick how users will
interact with this and what exactly are
the roles of the interact the people
interacting in aetherium 2.0 so in s 2.0
we
have an entity called a beacon node and
we also have validator clients
so why establish the separation right so
a beacon node essentially serves as like
the source of randomness for a theorem
2.0 it processes kind of information
that is aggregated across shards it
processes the votes from validators on
shards and it also determines casper FFG
rewards and penalties to people involved
so if you guys imagine running a current
guest node or a parody node in the
future that's going to be what we call
running a beacon node aside from that we
have an abstraction of a validator
client which is essentially like a
wrapper that can help you you know kind
of interact with your private keys
however you can store your private keys
elsewhere such as in a hardware wallet
or your other preferred methods this
validator client will actually be
shuffled by the beacon node into shards
and it's gonna be your main interface as
a user into you know participating in
securing the etherium network for the
future right and specifically everyone
needs 32 eath to participate so this is
a number you can't go higher or lower at
the moment and what would this look like
kind of from a software architecture
perspective so we have a beacon node
that serves as a single source of truth
for kind of short assignments state
transitions and everything that happens
in that 2.0 aside from that you have
your little validator client which is
your user user facing piece of software
so one thing we can imagine is that a
beacon node can be something hosted by a
provider like in Fuhrer you can run your
own beacon node for example staking pool
providers can run a bunch of beacon
nodes so ideally you know these these
machines are not going to be as resource
intensive as the ones that we have today
however like as a user we want to make
it also say you can run your own be
conduct validator clients can be run
anywhere and these are very lightweight
pieces of software ideally we might even
abstract it even more such that
validators all you need to do is really
manage private keys and that could be
them through it through you know through
your hardware wallet and have a little
interface for you to do that aside from
that in the system we also contain the
idea of shards and one question we get a
lot is I want to run multiple validators
how can I do that say you're you're a
company you know we as an example when I
give a shout out to rocket pool these
guys are awesome they're working
kind of a staking architecture for
people to get involved even if you don't
have the 30 to eath so what would that
look like one of the things that we
don't want to happen is this right so we
don't want you to have to spin up a
single client every single time you you
want to stake 32 eath you want to
participate in the network so one of the
one of the things we've gotten around is
actually creating a multi-tenant
validator client architecture so in the
sense that like validator assignments
are live streamed for a subset of public
keys so for example I'm running a
validator client on my laptop or my
computer at home I manage 10 public keys
on there I can send an API request to my
beacon node for the assignments for
those 10 public keys and I get a stream
telling me exactly what I need to do my
job I don't need to do anything I just
have one machine I trust it and things
get done so essentially we also this
also allows for validator as a service
sort of opportunities at prism we're
going to be shipping our own in-house
validator client that you guys can use
but it should be a very simple piece of
software that any other person can
create as well as long as it conforms to
the beacon know that theorem 2.0 API
right and like I said these are very
lightweight can be spun all types of
devices so I can even imagine having
your phone as as the entity that you
know stores private keys and can help
with signing the transactions required
so what does beacon change kind of
public API look like and one of the
things that we want to do is we want to
improve upon the current system which
currently uses JSON RPC I'm sure a lot
of you are familiar with that here
includes a lot of a lot of issues a lot
of issues with standardization and it's
not something that I think we believe is
robust enough for a theorem 2.0 so
instead we're going with protocol
buffers and protocol buffers give you a
lot of benefits so as an example say we
have two nodes communicating with each
other right protocol buffers provide
this by directionality of essentially
you know having a good standard for a
public API allowing notes to know
exactly what to expect and allow them to
interact with each other in a way that
we know will work even cross clients
whereas with JSON for example every
client needs to write kind of their own
way of doing things you're into the
situation where like on the
sender and I'm really happy with what
I'm sending the recipe has no idea right
as of today a lot of the current
aetherium clients they don't even
implement all the web 3 endpoint methods
that the other clients do that's
something we're going to actively try to
avoid and at 2.0 so just to give you
guys an example of gee our PC connection
metrics so G RPC is kind of like a
framework put together by Google for
this remote procedure call service
optimization and currently you know when
you use JSON RPC you get around you know
almost a 10 order which in reality is
about like a 6 you know 6 times
order of throughput compared to JSON RPC
when you see a proto bus why is this in
particular you know why is this
important well we want to make sure like
I said want to reduce the mutt as much
friction as possible which we knows
using a 2.0 to make it so that you don't
need to worry about this as a user you
don't need to worry about like the
bottlenecks that you'll obtain from this
aside from that here are some utilities
that will provide our client for you
guys to use and that are gonna be
basically like you know public packages
that can be imported across other
projects so if you guys went to Justin's
Drake I just in Drake's randomness talk
for s 2.0 we're going to be leveraging
the power of a six basic rigs to create
a verifiable delay function source of
randomness for a tearoom 2.0 so it's
really cool because you can actually
have a public API where you can query
the randomness like unbiased able strong
randomness I'm a theorem 2.0 nodes that
you can use in your applications we're
gonna have a very robust key value store
using both DB which is a write optimized
database specifically you know very well
very well created for block chains as
well as the signature aggregation
library using VLS so the cool thing is
that in previous iterations of kind of
the etherium 2.0 spec there are a lot of
questions around how can we do efficient
signature aggregation we have a lot of
validators voting on blocks how can we
get them basically doing their job in a
way that we don't have to worry about
the bottleneck of verification I'll
check so in this case we get the
wonderful
BLS signature aggregation tool aside
from that the beacon note serves as a
source of shards shuffling and cross
shard communication so on the con the
beacon chain spec right now that shadow
I pointed out in the official etherium
repo
there is essentially not enough mention
about cross communication that is a very
active area of research but the beacon
nodes are finality and the way
committees are handled gives us a strong
way to kind of begin on an approach
towards that another thing is we're
going to be building a common client
testing framework so we want to make it
so we have a very simple format in the
ammo where you can specify like hey you
know I want I want it I want to specify
a test for a fork choice in the theorem
2.0 I want to specify what happen with a
signature aggregation I want to know
exactly you know like what this would
look like what the result would be and
have a comprehensive test suite so that
even if people are not familiar with
their client and are coming from other
client teams they can come in and
testings robustly end-to-end so we did a
POC kind of early October in which we
essentially had our beacon node on the
left and on the right hand side you guys
can see validator clients that are
connected receiving streams of ERP see
responses getting shuffled into shards
and performing the responsibility of
basically a testing and proposing to
shard blocks and you know it was just
really interesting to see how this
implementation efforts give us a really
good idea of kind of where the spec is a
lot of a specification right now is
mostly like oh we should do block
processing we should be for chips but
nobody really tells you like okay where
should this live who should be doing
this how I should validate or clients
interact so by being a very
bleeding-edge focus implementation team
we get to answer a lot of these
questions ourselves and kind of come up
with designs that would make sense in
light of the spec and oftentimes come up
and be like hey there might be a bug in
the spec and that's that's I think been
really a really amazing experience
working with the etherium research team
on this so what are the next steps for
us prismatic labs there's still a lot of
work to do on the beacon chain spec part
of it is due to research but one of the
things I like to say is that the
research at this point is is most of the
core core kind of items will remain the
same what's really lacking is kind of
logistics around exactly validator
client interactions how that's going to
work and such working on benchmarks and
metering extensively for applications so
we want to make sure we understand if
our signature aggregation is done
properly
you know how many validated clients can
we realistically have attaches G RPC
processes as well as work on sharp p2p
which is a very big kind of umbrella
term all right so our next major
milestone is something that I'm really
happy to kind of announce so we will be
doing a test net cluster of beacon nodes
and validators and that's something that
you know we we aim to deal with the
other client implementation teams as
well but we want to make it so we have a
very simple system where you guys can
obtain faucet eath can basically deposit
your eath to become validators get on
board at as validators into the beacon
chain kind of 2.0 and can start
performing your responsibilities and
that it's a very exciting kind of
prospect and we really hope that you
know people will leverage prism to the
best of their ability and understand all
the tools that we have to offer and of
course you know this is a constant you
know work in progress
our constantly iterating on this and
we'll have a lot more for you guys in
the coming months so staying tuned stay
tuned for this
yeah so some learning resources there's
a lot of information out there if you
guys like a path 2.0 now called serenity
so there's an F 2.0 devs handbook if you
guys don't learn more about this we have
the spec we have a repo we have our
bi-weekly kind of implementer calls that
are kind of in parallel with the core
devs calls and overall all that is out
there
I mean earth 2.0 went from being
something that might happen maybe it
could be there maybe it's feasible to
being like it's gonna happen and we're
all gonna do it so thank you everyone
let's do some questions so have a bit of
time for questions yeah yeah
hi my name is Josh I got a quick
question yes it at 2.0 and charting and
beacon chains are gonna run parallel
with proof-of-work Shane is that true
yeah so essentially 2.0 is going to be a
new chain a new system for proof of
State Caspar f of G where you have the
proof work chain running in parallel
with it the reason we do this is so that
we make it easier for people to deposit
eath as a one-way deposit into the 2.0
chain so you want to leverage the fact
that like people have current eath they
want to leverage that to become valid
leaders so that's kind of why we're kind
of synchronizing the two at the moment
okay do you foresee the proof of work
chain being deprecated right now yes I
foresee that so the way we're gonna do
that is probably going to migrate the
entire state of the current Provo chain
into a contract on a shard in the future
in the meantime that still hasn't really
been designed but yeah we would still
keep the same state but in the future
ideally you want proof of work to be
deprecated over time yeah great thank
you yep yeah hey two questions first a
Ewing does does this clan prism client
intend to deprecate get always something
it's a good question I think the gas
team has been really busy right now with
all the hard fork situation and testing
and making sure everything goes up to
par I'm not quite sure exactly what
their plans are moving forward but yeah
I mean they have so much experience and
go that you know love for them to get
involved as well I'll try to be more
specific
we'll get B off of work like a theorem
one or we'll do they intend to implement
2.0 surrender I am Not sure okay sorry
okay and the second question sorry is
are you funded by consensus that you
intervene yeah we received funding from
Aragon nest
we received a major grant from with UN
Foundation a $500,000 in the latest wave
so I was super nice thank you if we
received ECF and one Shannon blockchain
labs a few other organizations but it's
all been grants we haven't taken any
equity you know we're not we're not kind
of full time you're walking full time
the team yeah on this okay great awesome
thank you yeah so we have one more
question
yeah hey can you talk more about running
a validated client on their smartphone
do you know your particular wor sure
ideally like if it's gonna run on a
smartphone a--probably just be like the
private key kind of signing
functionality of the validator client
we still haven't designed exactly like
what it would look like on mobile
because there are still things to be
done on the spec but ideally like yes
like we want to make it as lightweight
as possible if you're running on your
phone and obviously phones have like
availability assumptions like you know
you might not always have connection we
want to make sure that you're prepared
for that and have some way to protect
you against those things so there are
some compromises for running on the
phone but there hasn't been designed yet
so I can't give a strong answer to that
thank you right so thank you everyone
appreciate it
[Applause]
you