thank you all for coming
myself shall we chat chang-dong could
justin and metallic who is apparently on
this floor will today give you a deep
dive into the phase zero specification
that is the beacon chain of Ethier and
2.0 protocol today we will get a sec
nickel as we can with the time
permitting and at the same time point
you to portions of the spec so you can
dive in deeper and hopefully just get
you more acquainted with what's going on
so that you can better technically
understand the problems at hand and the
solutions and kindig and contribute all
that so we're building this thing as it
theorem - it's a chartered protocol
there are many shards connected to a
central beacon chain it also is has
loose coupling to the existing ethereum
chain which at the beginning just
supports deposits coming into the beacon
chain today phase zero is just this pure
proof of stake chain connected to the
etherium one protocol so that is what
we'll talk about today I believe at the
same time will at least show you the
scaffolding upon which shard chains will
be connected but will you'll not dive
deep into this portion of the protocol
the beginning what we're gonna start off
with today is we're gonna look at the
kind of the some of the core building
blocks of consensus that's the cast for
FFG protocol the LNG ghost fork choice
randomness and BLS signatures after that
we'll take a short break maybe take some
questions and then we'll dive into the
actual some of the mechanics and in
stage concrete instantiation of the
protocol with the actual state
transition and things and validators and
things built on top of some of these
components so f of G applied to proof of
stake so there was a paper written
probably bout a year and a half ago now
by Vitalik and Virgil Griffith Casper
effigy consensus protocol
generally built to be layered upon a
block proposal mechanism the original
being a proof-of-work mechanism but
there's some modifications to bring this
protocol to be on top of a previous take
protocol and more importantly some
modifications that get us to where we
need to go for his protocol so I'm gonna
go over some of some of some of those
modifications how we think about slots
checkpoints epochs slashing finality
that kind of stuff I will give you an
intuition for the safety proof but will
not have time to dig deep into that and
we have a yeah I'll talk I'll talk like
that now I can hear myself we will we
have a modification of the FFG protocol
in a paper it is a draft I really wish
it was gonna be done by today it's in
last round of edits and will be released
on archive very soon so hopefully this
will help you read that paper when it
comes out so traditionally when we think
about blockchain protocols we think
about blocks and block Heights and every
block you build on top of another block
moves us into another block height the
original FFG protocol considered
considered block Heights and actions
that validators could take with respect
to block Heights these Heights were
divided into epochs and units of work
would be done per Epoque so essentially
a round of voting by all validators can
happen per a PUC what you can do and not
do to the protocol is also kind of
defined within these epochs we have a
slight modification to how we think
about a chain being built still we have
blocks linked to each other block by
block building a block chain but we have
this notion of of time called a slot
also embedded into this kind of overlaid
on this structure and so what we can
what can or cannot be done by a by a
validator in any given time it was with
respect to a slot so my duty to propose
or to a test or do any type of these
messages it's with respect to a slot and
so a block someone someone shows up and
they propose this at slot 0 this is slot
1 no one showed up at slot 2 or maybe it
didn't get propagated the network and so
the proposer at slot 3 built upon slot 2
but the the state-transition the
internal mechanics of the consensus
protocol and other portions of the
protocol are aware of this skip and so
instead of things being divided and to
strictly block heights because this
would just be a block height of 3
although much more has transpired with
respect to the the duties and positions
of the protocol so instead a pox are
divided into slots slots epochs in
actuality or on the order of like 64
slots this is just illustrative so this
consensus protocol needs to be modified
FFG needs to be modified to work on top
of this new kind of slot and epoch
mechanism checkpoints so in Kasparov oh
gee we checkpoint we attempt to finalize
checkpoints checkpoints are blocks at
per units of time here checkpoint might
be this block whereas there may be might
that but importantly because we have
this notion of skipped slots we have to
define what actually a block being at a
checkpoint is and means and so we call
it in the in this paper coming out it's
called an epoch boundary block EB B so
in this Fork of the chain we have the
epoch boundary block which is the 0th
block in that epoch is actually B but in
this Fork of the chain where a slot at
slot 66 was built on top of a the epoch
boundary block is actually it's the
block at the zeroth slot or the most
immediate block prior so it's actually
it's actually a so in this version of
the chain this fork of the chain if
votes
happening and blocks are justified if
something was was check pointed or
finalized it would actually be a at this
slot because a can be transitioned
through empty slots up until B exists
you're actually check pointing and
ultimately finalizing this tuple of a at
the start of this slot to illustrate
that a little bit more what I was
implying is we have this notion of
paired justification impaired finality
in the optimal case we're always just
say justifying the 0th in the optimal
case we're always justifying and final
exams exists at all slots then we can
just always justify the 0th one here but
instead because we we can have drop
slots and skip slots we have to have a
notion of what we're actually at a given
a PUC what we're actually finalizing and
it turns out that we're we're finalizing
this notion of a paired justification of
a block at an epoch so just to
illustrate that a little bit more we
have a block at epoch one the zeroth
slot at 64 but then a nothing happens
like some everyone goes offline or some
massive forking happens and the proposer
the next proposer actually in epoch -
it's la 129 builds on top of this 64 and
so and we go on in this epoch to to
actually justify this epoch boundary
which ended up being a block from a
prior epoch but at this slot and so then
we can go on to do further
justifications and actually finalize
this and so what that does is finality
in this mechanism ends up being not only
will this block say this block is at
this epoch is finalized not only will
this block never revert but blocks that
are lower than this epoch boundary slot
can also but built upon this can also
are also not valid so for example if
someone built a block right here it's
lost 65
cc6 but this was finalized those are
those are considered invalid and I don't
consider them a part of my fork choice
so we have this this notion of coupling
blocks with an epoch in finality
[Music]
so justification rules similarly to
Caspar FFG the original protocol the
genesis block at epoch zero is justified
and subsequently we have justified and
again we have these pairs these block
epoch pairs any justification pair from
a source of a prior justification pair
is justified and when votes are cast
we're always specifying a source and a
target so here in this link that was
created this prior justification was the
source and this new one is the target so
we create a justified link I think it's
called a supermajority link to create
these just this chain of justified
blocks and a subset of them depending on
the rules can be finalized so finality
rules I know this isn't actually super
meaningful this is taken from the paper
the finality rules in the original cast
ref of G paper were essentially you had
to have to epochs that were sequentially
justified where the the lower of those
two becomes finalized here we actually
extend the finality rules to be a little
bit include a little bit more cases
where we generalize it the original case
that I just described is called the K
equals one case where we are
sequentially justifying but we can we
can generalize this and add cases to the
K equals n such that the rule becomes if
we have a justification link and or
here's our justification link but all
epochs contained within that
justification link are also justified
then we can finalize the source of this
link so here we jump to but we justify
the center so we can finalize here here
we jump over over three but we had
justifications in the center and so we
can finalize the base and the intuition
here is that here our justification and
finality here is we can't double vote to
try to finalize something exactly and if
we wanted to essentially like skirt the
double vote and and jump over then we we
we can't there's an and I'll get to that
in a moment
we can't surround this vote to
essentially jump over and here we've
like plug to the holes so we have a
similar mechanism and we've plugged the
hole and then now we just need to
prevent surrounds to avoid that finality
issue in the actual e theorem to
protocol we only consider the K up to K
equals 2 case because and the reason
that we need this is because we allow at
two stations to be included during the
epoch that they're created on chain up
through the next epoch and so you have a
few if things are not performing super
optimally and at a stations aren't being
included on each epoch every time and
they're included a little bit delayed
the the state of the chain and what is
actually justified in the view on chain
can be delayed and so we have these
cases where if we open up here's our K
equals 1 cases case 2 in case for those
are nice but here we have these other K
equals 2 cases where by extending the
finality rules we actually can capture
finality in a few more cases I think
Justin will probably get into this a
little bit later but in the beacon state
we do have these are the portions of the
state that are related to finality we
track the last for just a epochs whether
we justified them and a few things about
the checkpoints and with that data we
can track these cases and no finality on
the case of on chain
here's this massive nasty function that
processes justifications and also
processes finality based upon those
mechanisms I was kind of alluding to
these and I probably should have these
earlier in the slides but we the things
that keep this protocol safe is we
prevent making double attestation so
voting for the same target in the end
within one epoch and we as I eluded said
earlier we want to prevent given any
source target link here here here we to
to prevent essentially getting around
the node double vote we prevent a no
surround so I can't come from something
earlier jump over and then begin
finalizing here's the actual code we can
probably get into this little bit later
where we take attestation data can't
have the same target epoch can surround
that's that for now sorry that was so
fast we have a lot to cover today and
that's like one of the more detailed
components metallic
all right so I am going to be talking
about as you can guess the LMG goes for
choice rule so I guess so to start off
kind of what is LMG ghost it's an
adaptation of ghost
aka a greedy heaviest observed subtree
which is a alternative proof-of-work
fortress rule that some academics humans
ensemble in ski anivia so hard developed
in 2014 and it basically takes the same
principles as original ghosts and try
stone have modified them slightly and
fit them into a proof of stake context
so to start just a kind of quick intro
of what ghost itself is basically the
idea here is that if you imagine a
network where there is a lot of network
latency or there is normal network
latency network latency but blocks are
very fast so say network latency is one
second you have a block coming every
three seconds then maybe like something
like a quarter of all the blocks are not
going to be here kind of conveniently in
the same chain right because you might
just have a block get produced to end
before that block gets broadcasted
another block gets created at the same
time and the reason why like this is bad
and so in Bitcoin they call this orphans
or sales and aetherium we call it uncles
the reason why it's bad is because if
you imagine there is an attacker and the
attacker is trying to do a 51% attack so
make an attack chain that's longer than
the honest chain after at some point
then the attacker has an advantage right
because the fork choice is tries to look
for the longest chain so the honest
chain one of every four blocks is not
lengthening the chain it's kind of a
sister of some other block but on the
attack chain it's just the attacker and
so everything works perfectly so instead
of needing to have 51% of the hash power
the attacker might only need to have 43%
of the hash power and if network latency
goes higher than the percentage drops
more
or announced Network latency approaches
infinity of the attacker can through a
51% attack with basically nothing
so ghost fixes this and the kind of
philosophy behind this right is that if
you imagine a chain here where let's say
block D was built on top of block PE but
then this chain was block C and then
block he ended up winning if you look at
block D like block G ultimately is still
a vote for B right it may not be a part
of correctly on the same chain but D is
still voting for B who ever voted for
overbuilt D still thought that B is a
good block to build a chain on and so
really you should be taking into account
both D and E as of blocks that's that
support B's rightful position as as part
of the chain so the way that ghost works
is basically instead of looking at the
longest chain you have the you run this
kind of iterative process where you
start from the root if some block only
has one child you walk over to the child
if you if a block has multiple children
then you select the child whose tree of
descendants is larger right so over here
this block has no descendants so total
of 1 including itself over here this
block has 1 2 3 4 5 6 descendants and so
we go over here then you walk over here
then you have another fork then this is
the kind of heaviest subtree again and
so E is the head now in this particular
case right like the the Wong is chain
rule and ghost agree but there are going
to be points like many theoretical cases
especially when there is an active
attack being attempted when these extra
blocks that really do matter and they
can save you from an attack now the way
that ghost applies this to a proof of
state context is basically to start off
it's very similar except instead of
looking at all blocks it only looks at
the block that is the most recent
message submitted by that validator so
for example in this case imagine you
have a proof of stake chain you have 5
validators we'll call them like la Alice
Bob Charlie David and Evan and if you
look at Alice now has created two blocks
over here and then one over here and a
Bob over here created this and this
Charlie created these two David created
this one but then David might have
dropped off line so he's got nothing
over here so this is his most recent one
and Evan created two blocks and that's
his more recent one so what we do first
is we only look at the most recent
blocks from each individual validator
would you basically means this this does
this and we run through the exact same
process but only using those five blocks
two counts toward the weight right so
over here you start from the root one
child go over here then over here this
side you have a score of one on this
idea of a score of 1 2 3 4 you go over
here then you go here and then score of
1 score of 1 score of two go here and
here and that's the head
now for now we're assuming a simple kind
of model where what I call blocks and
what I call messages are the same thing
right ends basically so in this case
blocks are serving a kind of dual
purpose one of them is that blocks are
kind of entries in this graph structure
and like your fork choices walking along
the blocks but the other rule that
blocks have is watch they're voting now
in LMZ ghosts as we use it blog sent
messages will be split and I will get
into this and why we do this later
so as in ghost start from the Genesis
walk up the tree at each branch choose
the child that has more latest message
latest messages supporting it and keep
going until you find the head so why LM
D ghost right the so this here were
interred bringing back kind of LM t
ghost as more like it actually exists in
aetherium 2.0 and what we have here is
he have blocks and votes on a key a
attestations as kind of three separate
concepts right so you have a block and
then you have five votes you have a
blocking or like in reality this might
be could be anywhere up to about 50,000
votes then you have a block you have a
huge pile of votes a blog a huge pile of
votes now over here you might have two
different competing blocks and this
could
because one of the blocks just got
delayed and the other boy and then the
next proposed who created the block and
this block appeared this could be
because a proposer was malicious and
created two competing blocks we don't
know so now everyone who's voting
chooses either this side or this side
and if they choose this side then this
block wins and then you keep on going
right so the ghost fork choice rule is
going to be counting these the antis
Nations and specifically it counts
latest data stations so if this like if
this is all inside of one epoch then
there's no difference because everyone
only votes once per you park but if you
imagine that say this and this are two
separate epochs then maybe this at the
station and this at the station come
from the same validator in which case
you don't count this one but you count
this one now in general if a chain is
progressing then the if you vote once
over here then the next vote that you
make is going to be a descendant of this
block right so most of the time
validators aren't changing their opinion
they're extending their opinion so if
you made a an attestation supporting
this block then you're saying my opinion
is this block is the best if you then
later make an attestation over here
saying my opinion this block is the best
then like you're not disagreeing with
your opinion before right you're an
opinion though this block is the best is
also an NPN you know this plug is the
best and of this block is the best and
then this block is the best but before
you did not have an opinion on these
guys and now you do have an opinion on
these guys but maybe you made an
attestation here then you make this at
the station then you realize this chain
wins and so at some point late at some
point later you do change your mind
so like both these things are possible
now the reason why we do this is because
this allows basically parallel
confirmations right so in a kind of
probabilistic for curious role there is
this general concept of confirmations
like basically how many kind of units of
information in favor of a block are
there and how many gee wants to wait for
to achieve a certain degree of safety in
Bitcoin you would wait for six and that
means waiting for six
in etherium like you would wait for 12
so you'd wait for 12 blocks but here you
basically get tens of thousands of at
the station's happening in parallel and
so you get a very high assurance that a
block is overwhelmingly likely to be
included in the chain pretty much like
in the average case after one single
SWAT so the goal here basically is to
give the same level of security after
ten seconds that a traditional
proof-of-work chain would only give
after minutes or hours and because you
have messages happening in parallel
there's no way that all of them are like
you can even possibly make all of them
form a chain if you try and so a longest
chain rule was not even sensible and LMD
go strength is the obvious approach for
how to have taken to account the
information from all of these validators
so why LMD ghost right so one reason is
that the longest longest chain rules
cannot take into account information
from parallel testers and ghost based
rules that do another interesting
property that LMG ghost has is it has a
property that the minority can never
beat the majority regardless of how many
messages they sign right so for example
suppose that you have like a structure
that looks like this and then base so
you have these four validators that are
all on this chain and these four
validators have all agreed that this
chain is best and you have this one kind
of a lone attacker now let's suppose
that a CD and E just get knocked off
line they disappear then if you use
traditional ghost right eventually be
could just make blocks we could make
blocks B could make blocks and
eventually be what B's chain will be
longer and B would win but in LMT ghost
if all four of these guys get knocked
off line then you could keep on making
blocks and B could keep on making vlogs
for a long time but this chain is still
going to continue to be the winning
chain because it's not about the
quantity of messages it's about the
quantity of distinct supporters of one
chain versus the other and if these four
Val
don't make any new messages than the
system assumes that they're just
supporting these four things forever so
this kind of insight this idea that
unlike longest chain rules lmg ghost has
this mechanism where if it gets into
this configuration but you just can't
move over to this chin pretty much like
no matter how long beach rise this is
actually the basis of ICBC casper which
is something that we're interested in
switching to for the longer term but so
this is one reason why and a second
reason why LMG ghost is interesting now
let's look at some edge cases of LMG
ghosts and specifically LMG ghosts
interaction with the with the finality
gadget right so safety message attacks
are one one a kind of example of an edge
case first right so basically here look
that here's the intuition behind a
safety message attack so a validator is
allowed to make a maximum of one
attestation in each epoch and the way
you enforce that is that every
attestation has to come with a tag that
says this is the epoch I come from and
if you send two distinct at the stations
with the same epoch tag then you can get
slashed for it now a thing that you can
do is you can say well I'm gonna just
drop off line for any box and now I have
in historical tags that I've unused and
then within one epoch I can just like
send all of those messages with all of
those tags all at once so a worst-case
traditional ghost like it's not very
it's not very good at handling this kind
of situation LMT ghost is better because
at least those n votes do not stack on
top of each other but lmd ghost is still
imperfect because with this kind of
mechanism well you have the ability to
and if influenced to basically make the
fork choice go back and forth right you
can say I vote for you now I vote for
you now I vote for you and now I vote
for you and you can repeat this a bunch
of times in a single epoch and this
could be used for some
attack still alive nacinda lay finality
so a proposed solution here is FMD ghost
which basically says clients only look
at messages and have tagged with the
current or previous epoch and this
prevents kind of saving saving up more
than one more than two epochs from being
a being useful for any kind of attack
[Music]
interaction between oMG ghost and FFG so
we use both LMG ghost and the FFG in
this kind of combined way basically lmd
ghost provides block by block consensus
and FFG provides finality and like you
do have to kind of glue these algorithms
together right so our actual a fork
surest rule basically says first select
the last finalized block you were aware
of and at the beginning this is the
genisis eventually you become aware of
new finalized blocks second you selects
the highest highest epoch the most
recent justified block that's a
descendent of the last finalized walk
and then third starting from the last
justified block you run LMG goes to find
the head so it's basically running FFG
first to figure out the last justified
block and then writing lmg lmg goes from
there to find what the head is now this
does open room for certain kinds of like
bounced attacks so basically the issue
here is that you might have a situation
where you have one block on one side and
you have a block that's winning the fork
choice rule but then you have some block
over here with 65% of the votes and then
the attacker has a few votes so then the
attacker waits until some block here
gets a 65% and then the attacker
releases a few votes here this block
becomes justified and so suddenly the
fork sure is the rule kind of flips over
from here to here and then people build
over here and then when this block
starts getting close to over to 65% then
this blocks at 65% the attacker releases
another 5% now this is justified now
this halts everyone moves over here and
so he can kind of bounce the chain
around right and there's some a couple
of solutions that are
intended to mitigate this kind of attack
one of them has to basically they all
have to do with kind of delaying when
you justified epochs have an effect
right so one of them would say in most
like in most cases delay until always
switching until when epoch boundary so
either finalization happens a coast of
the start of an epoch or it happens much
late or or you wait until the end or and
I another idea is that a checkpoint can
only be used
can only be used to as part of the fork
choice until like basically the height
since the last justified epoch
multiplies by three year and this
ensures that there's kind of periods of
three epochs eventually within which the
fork choice is not going to change and
you have the opportunity to finalize
something so then like LMT go stick is
not really more complicated more
complicated than this right it basically
is you have a block and if that block
has multiple children to figure out
whether you go to one child or the other
a child you choose the child that has
the most validators that you might have
most recently supported that block and
you can use that by itself as a as a
fork choice rule and you have a bunch of
validators that are making these
messages in parallel and each of those
messages contributes to the fork choice
rule allowing the chain to kind of soft
converge very quickly and after those
messages are also simultaneously votes
in FFG and so after about one epoch the
blog gets justified and then which kind
of entrenches it in the fork choice
further and then after one more epoch he
gets it gets finalized
hey I'm dicot Feist and I'm going to
talk about randomness in Ethier two
point oh okay
so basically I quickly want to summarize
why randomness is such an important
problem in if in any kind of proof of
stake protocol and if 2.0 I'm going to
talk about run now which is our first
and like routine routine airy source of
randomness quickly like also going to
the the issues that this has and why
like in the final protocol in a few
years we're going to use a verifiable
delay functions to improve this source
of randomness so why is it so important
to have a good source of randomness and
proof of stake well so we need to do
several things randomly and we don't
have this kind of proof of work
randomness that we have in proof work
chains anymore so we need to select
proposes we need to select committees
and we need also like as an extension
like some contracts on chain want to use
randomness and we need to provide
randomness for these as well
and so for each of these like like good
roundness required for proposes because
we need to be fair like we distribute
rewards to them and also we we want to
protect against denial of service
attacks but it's especially important
for the for the committee is that it has
to the short chains because if like if
the committees are not honest like the
the beacon chain cannot cannot check the
state transitions of all the charge
changed because that's the whole point
of shouting that you don't have this
huge load on the beacon chain but that
means we can have to trust these
committees to be honest and we can
remedy against an incorrect vote by a
commenter using for proofs but we don't
want to have too many of these and
finally we also want that smart contacts
can use randomness and yes some
applications like lotteries or so might
attach a huge value to random numbers
and like if you can somehow attack them
that might degrade the randomness in the
whole system right and then a bit
further on their committees why it is so
important this is like a very central
issue they're like if the the problem is
that we want to minimize the probability
for having a dishonest committee and
like a bad committee could potentially
create a link to an invalid or
non-existent block and a fraud proof
would mean that you have to revert the
state of the beacon chain until like
when that happened so like the
probability if you have a committee size
of 128 then it's quite small five times
10 to the minus 15 but this kind of kind
of cost completely changed as soon as
someone can bias the randomness that
we're using right so the idea behind run
now is let's say like we have n people
who want to generate a random number
everyone goes into a room everyone
contributes one random value X I you
compute the X off all these values right
so that sounds like it could get
generate good randomness but the problem
with that is the last player can just
change their value after they have seen
everyone else's value and then they
change their choice and like get
whatever they want
okay so let's improve this so with
commits reveal
we can start the same they all go into a
room and they each commit to their value
ex I by telling everyone the hash and
then they reveal their value we compute
the XOR of those values again okay so in
this case this cannot be manipulated
because we force everyone to reveal
their value because they were all in the
same room but in the real world the
problem is anyone can stop this process
by not not actually revealing their
preimage and then we can't compute this
XOR right so run now basically builds on
this idea so we make every everyone
who's a validator has already committed
to something in our case is actually
their signature because we have a
deterministic signature scheme BLS we
can just use a signature as a reveal
everyone can check that this was a
correct signature so you sign the epoch
this is denoted by E here and that's
that's the reveals and then what can of
course happen is that someone does not
produce a block and so they they haven't
revered the randomness and then we
cannot include them in this XOR yeah
okay so that is the basic process of run
now and and this is used as a first
instance to generate randomness eath 2.0
it only has one problem basically that
whoever is last in an epoch can just
choose to not produce a block so
basically what does what this means is
if I don't like the result of whatever
this reveal that I'm going to contribute
this like I can compute whatever the mix
would be then I just don't contribute
and it's as if I would get another roll
of dice essentially and like you can
that can be worse if if you control
several validators in a row
course than more bias as possible so
like there was one nice analysis by
vitalic on his research where he showed
that if you just have a longest chain
fork choice rule then with just 36
percent of the stake you can actually
completely take over a chain that's bait
that choose the step blocks based on run
down that block producers right so what
ran now is sort of our first source of
randomness in the beginning it's
obviously as I've shown not perfect but
at the moment we don't have anything
better so like in the future what we're
going to build is honestly like
so-called verifiable delay function the
idea is that you have a function f of X
that produce the results Y and prove PI
and such that the computing this
function takes a long serial time right
so you can't speed it up by having many
processors it's like you have to run and
see really on one processor and then
checking the result that the reason why
is correct
using the proof pi is fast and so one
example which is actually the one that
will we are very likely going to end up
using is this squaring modular and RSA
modulus so power taking many squares of
X modulo M where m is P times Q is like
one way to construct such a verifiable
di function and by using the vdf output
on run now VD f sorry the vdf on run now
so using the ran Arad as input for the
PDF the last revealer loses the
advantage and the way that works can be
Illustrated here so basically what
happens is you have this last block of
an epoch that starts the vdf computation
and so later the vdf computation will
have an output and that will be used as
randomness on chain but by that time
they will already be many more blocks so
it
the there the last reveal I wouldn't
have a chance to know what how they
could have influenced by not not
revealing their reveal yeah that's it
thank you so a stock is a POS signature
aggregation so the goal is to provide a
minimal set of knowledge that that make
developers life easier so the goal is to
introduce the signature scheme on a top
but that it is built on the pairing
operations and curved horns groups and
they all built under of field operations
button so yeah so a takeaway here is
that when we say BOS we might talk about
two things the one is the BOS signature
aggregation scheme and the other is the
curve parameter that of chosen by z
cache is called BOS 12
3:81 curve there are different authors
so first I'll give a primary how a queue
operation works so you have a feel
number like fill 13 that means it is
operator operator on the prime prime
number 13 and then you can define
addition subtraction multiplication and
division with this number and note that
the outputs are always between 0 and Q
minus 1 so
you have a no matter how complex
commutation you if none on @q you always
get the same data size and you can use
the py ECC library to to try try on
different of primer fields and here's
another primer on elliptic curves you
when we say elliptic curves it's a it's
an equation in this form is it's a Y
Square and X cubic and when you define
it on a real number when X Y is a real
number you see a curved shape but if you
defined on a finite field
it looks like scattered and so a point
on the curve is has a x and y
coordinates and usually you need to send
the points over the network so you can
compress it by only specify X and only
one pitch to him for which Y you are
talking about because given X the Y is
symmetric it's it's only two points on
our graph so and you can you can add a
point to another point so you can define
additions of the points on the curve and
it is usually on line when you want to
add P to Q you draw a straight line and
intersect the curve on another point and
then mirrored it down to find a peep ask
you so when we have the addition of the
point you can define multiplication for
a point you can multiply a point like by
ten times like adding your 10 times and
this is this is a hard math problem that
you can given you have P and Q and
you cannot find 10 easy it's really hard
so you can hide bodies in here it's
actually a secret key yeah
and so here let's talk about the PRS 12
381 specifications it has a small small
point called g1 and a big point called
g2 if we remember the first pyramid is
they have different finite prime fields
on a button the smoke smoke small point
has 48 bytes and a larger one has 96
bytes and they have different elliptic
curve defined and note that
so the fq2 is like a complex numbers
it's a double the size of the small
curve and there's a image in imaginary
number I there and the G 1 and G 2 is
that generator points that has a
specific x and y coordinates specified
for the for the curve and so I'm colored
whole days then so it don't don't get
lost with G 1 and G 2 so a pairing
function pairing function is a function
that takes a g1 group and G to group and
the magic of the pairing function is
that when you like multiplier constant a
or b to group elements and you can tag
the IV to the shoulders and that means
that you can take that AV into the first
one in a second one and that's rule
number one
and rule number two is that
when you are adding points now you are
adding points in g1 adding points in g2
you can like distribute them and spread
them out so with this construction we
can introduce how we can how the
signature scheme is built and this type
of construction and if you look at the
pairing function there are some monies
over there because it's expensive to run
so it's a it's a computational heavily
functions so we try to minimize the
times you try to run pairings so here
here is the POS a signature scheme
private key is an integer thinking like
1 2 3 4 5 and you get a public key you
just multiply the private key with G 1
point and to sign a message you need to
hatch the message to a group of point
and that's the when you her people
saying the POS standardization effort
they are standardized the way we hash
the message to two points and then you
multiply your primary key to a message
and you get a signature here and to
verify the signature and a public key
and message you are used to
pairing functions and the proof is
really simple it's like you write a G 1
and s on the left-hand side and then
that you can move the K from the right
to the left and you get the expression
of the right hand side and so the most
powerful thing about be our signature
seen is it can aggregate signatures and
public keys so this just a curve point
additions which
before and this is you can aggregate
three signatures and you can agree get
as many signatures as you want and then
verify using two pairing functions to
verify so yeah so the proof lived as a
exercise but what we are looking so what
you are looking at here you are looking
at a scalability so this this this is
how you can aggregate many validators
messages so here I present and it
samples that kind of power on the chain
saves simple C or istick on so it is an
attestation message and it has
signatures it looks like this and then I
hide data part and you will see an
aggregation page looks like this and
this is actually a record SS or varied
805 is your signature included in this
bunch of aggregation and then a kind
used that information to look up public
keys and to verify these signatures so
yeah this how tos signatures works
hopefully hopefully that helps you thank
you very much
thank you metallic dr. Chang next up was
a break but we don't have time for that
because we're definitely definitely
running late already
we might have some time for questions at
the end but we're just gonna keep
driving
next up shall we gonna talk about we're
moving into these are the kind of some
of the building blocks to help you
understand some of the underlying
concepts that we use to construct these
things and now we're gonna move into the
more concrete and San Shi ation of the
protocol shall we
so hello everyone I'm sorry I'm pretty
sick right now and konichiwa so my topic
is the life of the serum the concern
validator so this is the outline of this
topic so we were talking about two main
factors to define the editor state and
then we will talk about the entry and
exit cues and then the life cycle of
this so the current spec defined list
for status there are activation
eligibility which is the preparing stage
before it actually be activated and then
the second one is to it the state that
later is alive active and is helped to
validate the state the blockchain and
then when the editor they can choose to
accede then after a while they were
getting to to exceed status and finally
the beacon chamber later we're getting
to to withdraw Ball State so here we
need to know is that in the big engine
phase zero we only have with drawable
state there's the actually withdrawn
state will be introduced in the Phase
two where we have yeast execution
environments then that Square
the litter can actually withdraw their
deposit to the e to distractions okay so
here is the validate Hearst data
structure found the beacon train state
so the validator is has these
informations we need to know it's inside
the content state so here I highlight is
the status a parks so we can see this
four different state of each park are
defined here and initially the the state
epoch is set into the unsigned integer
of 64 bits which is the maximum number
of here so the reason is that we can we
haven't defined this status we haven't
defined when this status will be
happened
so we said a rebel own wave long epoch
okay so Stanley explained it that we
defined the slot and epoch so each epoch
consists of 64 slots and each slot is 6
seconds so we can use this epoch number
as the timestamp here
so as we define that we can see the
epoch of hyaline and if the data has
been set to with activation eligibility
epoch 100 and also the activation impact
200 then when the time actually between
two of this to ePub for example 150 the
violator is not activate yet
and when after 200 parks the data will
be actually at
it activate and so we introduced the
state epochs no there's another flat oh
it's another factor that in fact uh the
peak enchants the data state which is
called dashed which I think Danny will
talk about how the idea to actually be
slashed in the later session so in here
you only need to know is that a flashed
the later will be forced to exceed it
which is very reasonable because they
might be something that we have
misbehaved so they were big thoughts it
to be yeah I'm going to talk about the
red limiting cues before that want to
introduce the quick subjectivity this is
a feature of the proof of stake duction
and so if if you are new by daters we
got it online and you you can only join
you can only trust the your peers around
you and also if you get offline and then
be back again you can doing the same
situations that you can only trust your
neighborhood so then how long you can be
with the offline its introduced it
depends on how long the it takes for the
attacker to withdraw their stake then
then that's why the state I mean the
exit rate is important here and also the
tie line the the tie period we set for
and
but yet her from the time it initiates
exceed my operation
- it's actually be excited that triggers
is also important so in the potential we
have to choose which is twice the entry
queue and another wise exceed cubed so
let's two queues are the reason why we
use queue is that we need to network
also the you know that network and also
the data set to be as stable as it can
be so we we won't allow that enough
short short period a lot of the data
that they initiate exceeds then the data
state will be like you can't select
enough weather enough and the since say
it from the ladies estate and also it
ensure that the penalty guarantees is
still remained between the two chains as
well as the later locks on of often
enough so we will see that how the queue
is happen so so this is the channel rate
functions we you can see that the for
each epoch the maximal number of a later
can't join or to exceed 85 it's based on
the current active very data count so
you can see that it the number is set us
this and the tron red curtain is set to
like 65 thousands so as you can see the
number we can estimate that how many
later can be is it at the same time
and the lifecycle so at the beginning
beginning the relator they will make a
deposit on the east one trend and it's
one change is the end point get to get
let you get from the east one chain to
its the world so when the later they
make a deposit of the 32 either to
discuss deposit contract
you also watch the past encounter status
from the be control so so this is a
diagram here and we were show the four
that were later
so at the beginning the deposit data is
here and we will check online and on the
pension logic that is has enough balance
and ready to activate and after full
epochs and also it's a first influence
of our queue we defined that the tron
rate earlier like in that function so
only the small amount of data can join
the various said this is the entry to
here okay and then leave now let's take
a look the button diagram so from the
window the validator is activated and
there's two possible in this road is
maybe the radiators and he got penalized
and times my times and the the radiative
balance is insufficient so then in that
time the ladies will be objected and a
knowledge option is that
but nobody that can volunteer wellin
Harry exceed here's the second road so
both roads we'll get into will push
Terminator in exceed cue here so it's
also it has to wait for at its four
epochs and also it has to be enough room
Foley's theater to exceed and then we
call that this valley it is in the state
of it's our - but is exceeded okay so
and then after 27 hours it will be with
durable the reason why we remain we set
a delayed high between the excited and
we Straubel 3 most reasons why is that
the very literally after the it's
exceeded it's still possible that it
will cut slashed which is this route and
also maybe the very still have chance to
get some a small amount of free world
before it actually exit and also it will
provide proof of custody challenges high
to be made during this period I'm sorry
the poor velocity things to face one
thing that we will prepare this and then
let's take a look the top diagram
so the activated my later my got slashed
and after it got stashed you will wear
the short delay until a we can can
initiate withdraw operation
then you got into that the / and
exceeded status and after at least 36
days it will be with durable so it's
very you can see that the stash theater
has to wait for more time it's got
punished because the there either is
locked into the kitchen that's the full
picture that you can see how the little
B switch between those data's okay okay
okay
so I'm going to talk about the state
transition function of the of the beacon
chain and I encourage you to just you
know read the specs it's actually not
too bad it's only roughly a thousand
lines of code quite readable and the
link up there is quite long so I've also
shortened it okay just to give a bit of
context you know you all know this we
have the beacon chain which is kind of
the the system chain of the whole system
the spine all the shards kind of connect
to it via cross links the shots come
later and I'm going to focus on the
beacon chain
okay so we have slots we know this we
have blocks and we can chain and we also
have state and basically state advances
for every block and so what I'd like to
focus on today is you know what is a
block what is state and what is the
state transition so this is the state
transition function and you know it
takes a state
which returned the post state or an
error so we can just say okay this this
block is just invalid and I'm gonna
abort there and if it's valid I'll give
you the next version of the state and in
addition to slots we have a box so 64
slots for a park which is six point four
minutes and epochs are kind of important
from the point of view of the state
transition function because this is
where some of the kind of accounting
happens at the epoch boundaries so you
have these state transition functions on
the Block basis and then you have also
state transition functions that happen
on a Airpark basis okay so this is a
kind of a high-level overview of the
various components of of the beacon
chain and you can kind of think of it as
an organism with various organs that
connect to each other so you might have
a little Long's the heart whatever all
these things and here they each provide
kind of vital functions so for example
randomness you have the registry which
keeps track of the validators you have
finality down there
you need deposits of course if you want
proof of stake and yeah everything is
kind of flat so it's not like a layered
system but we do have like the beacon
chain and the shard data and the short
state but within the beacon chain is
actually quite flat and and horizontal
and each of these things you know we can
be swapped out it's very modular and so
you know one of the goal the roles of a
designer is kind of to pick the best
ingredients there and try and put them
together in a in a harmonious system and
in terms of color coding I'm gonna use
blue for the state and and green for the
blocks okay so what is the state let's
try and actually read the code chunk by
chunk
trying to understand what is in there so
we have these three properties which are
basically related to two versioning in
space and time so the the the Genesis
time tells you when when the state was
was created slot kind of gives you a
more granular notion of how much time
has processed and then the four core
kind of be versioning in in space as it
was as opposed to versioning in time so
every time we do a hard fork we're going
to update this and one of the the
impacts that has is on the the way that
signatures are verified okay so that's
all all basic stuff more kind of basic
infrastructure is you know the notion of
of roots so we have state roots and
block roots which is the equivalent to
what what is traditionally called a
block hash or an estate roots and this
is just a way of cryptographically
keeping track of the various objects
that we're working with and representing
them in a way which is friendly to to
work with so the reason why we're
working with roots as opposed to two
hashes is because the objects that we're
working with are structured and we have
this notion of a tree of hashes and so
if you're interested in a very specific
property of an object then you can
access it via a americorps path for just
a specific object as opposed to having
to need the whole object and then we
have kind of the the economic link to
'if one so we need deposit in to leave
to the deposits come from if one and so
the if two needs to be aware of if one
and and this is the state that is going
to help us be aware of if one and then
we have the register
this is going to be like probably the
most important part of the state so it's
just the data structure that keeps track
of all the validators and it's by far
the largest part of the state so you
know this might be hundreds of hundreds
of megabytes let's say and the rest
might be tiny just a few megabytes we
have some state related to shuffling and
and randomness we have state related to
slashings we have state related to
attestations
so at the stations is basically what the
validators need to do that's the work
that they have to do it helps advance
the system and make it move forward and
this is what the the validators get get
paid for we have the cross links which
is the link to the to the various shards
and then finally we have the finality
mechanism and in terms of concretely
what are the the modules that we've
chosen here are some of the key words so
we have F F G for finality
we have BLS signatures for the
attestation x' goes for the focus rule
we have Rand out for randomness swap or
not for the shuffling we have surety 56
as a hash function and we have tree
hashing as the way that we we Merck
realize the the objects okay
so it all fits in this slide this is
this is the the state okay so let's try
and understand what's in a block so in
the block we kind of have the header
this is the header with things you'd
expect like the slot which is the
equivalent of the height and other
systems the parent route which the
the parent hash in a novice system state
route the signature which is going to be
the BLS signature and then the body
which is going to be like the more
important part of the block okay so
let's let's look at the body what's in
there so you know we have fields that
are relevant to two of these systems one
is the randomness system making progress
ran down and then the other one is
related to the link to f1 so trying to
make that progress through voting and
then we have a graffiti which is just
any any data so this is kind of
encouraging people to to innovate with
putting data on the beacon chain and
then we have the equivalents of a
transaction so normally in a block you'd
put transactions here it's a bit
different because the transactions are
not user transactions they're
system-level transactions so we call
them operations and we have these five
different operations two are related to
to slashing one is the attestations
which is where like the real work should
happen and then you have transactions
which are related to people coming in of
the system leaving the system or moving
funds within within the system so these
are just registry operations the
attestation is probably the most
important so block contains at the
stations and that's what moves the
system forward okay so I want to try and
give you like the really high level of
the state transition function and I'm
gonna cheat a little bit and I'm going
to only present what I call the honest
state transition function and by honest
I mean that I'm going to assume that the
block has been honestly constructed
so it's a valid block and and what this
means in practice is that I'm going to
try and tell you what are the mutations
that the block will make on the state
but what I'm not going to tell you about
is all the various ways that you that
the state transition function can can
throw an error so all the various
assertions and it turns out that the
bulk of the complexity is actually here
but here is really boring stuff is like
Oh verified that the signatures valid
verify that if you're transferring funds
you have enough funds I think most of
the insight actually you know comes here
like you know just to try understand how
the state evolves and this is where it
all happens ok and so I've kind of
subdivided the modules into into three
columns so you have the the scaffolding
which is development pretty much for all
block chains time routes and randomness
and then you have the the registry which
is which is the one unique part to proof
of stake so you know you have things
like deposits and exits and then you
have a final bit which is you know
technically you know optional but it's
still extremely powerful related to to
finalization and cross links if you want
sharding and and also ghost 3d
attestations okay so let's go through
these components one by one so blue is
the state green is the the blocks so
what happens at every every every slot
the slot the slot number will increment
so
you you you read the slot value and you
just increment it nothing
nothing complicated here and the Genesis
time and the fork don't change I mean
the fork will change kind of at the
social consensus layer but it doesn't
change within the state transition
function then you have kind of the the
header part of the block in green which
gets saved into into a data structure
and also gets America lies into into
block routes so the the beacon chain is
kind of aware of its of its block routes
and in the past the recent block routes
and also recent state routes and it will
basically come build from these so
called historical routes so this is a
historical accumulator which allows you
to go back in time arbitrarily far and
provide a witness to any part of the
state or any part of a block and one of
the cool properties of this accumulator
is that the witnesses don't change over
time so if you have you know a statement
saying I know that you know its lot
1,000 the the balance of this validator
was this amount well whatever proof you
had the miracle path will remain valid
forever and then you have the randomness
which was explained by dank hat and
these is the basic this is the basic
scaffolding and the way that the the
randomness moves forward is that in
every every block the green part you XOR
in the reveal into the Randall mix so
the random makes just keep keeps on
mixing in entropy and and this entropy
is kept in the state and it is it
sampled every epoch to do shuffling
okay then we have the the registry with
the validators and one of the things
that we've done here as an optimization
is we've decoupled the the Val the
balances from from the rest of the of
the the validated fields and the reason
is that the validator fields will change
very infrequently whereas the balances
will change very frequently so there's a
high overhead to constantly be mark
realizing what what change is fast and
so we want to segregate in one place
everything that changes fast and this
was covered by Yahweh so in the let's
have a quick deep dive as to what was
inside these validators so the
validators is a list of valid data
objects this is what the validator
object looks like it has the the public
key as you'd expect this is kind of
interesting it's the hash of another
public key so this other public key is
meant to be your with withdraw key that
you keep in cold storage so you as a
validator you have two keys you kind of
have a hot one that you use on the on a
day to day basis to sign your
attestation and then you have a cold one
which you use for withdrawals and
transfers and so if you validate a node
which is online gets hacked then the
hacker cannot steal your funds so that's
why it's a nice level of protection for
you okay all of this was covered by bi
shall we okay so which parts of the
systems interact with the registry well
we have the deposits so every block in
the beacon chain will contain a list of
deposits here and these deposits will
get processed and then that will create
validator entries in the registry but
then the beacon chain is to know what is
a valid deposit and for that it needs to
be aware of the f1 chain so how does
that work so in every block we the the
block proposal will have f1 data saying
you know this this is what I think is
the block hash of of f1 around which we
need to come to consensus and so this
data gets stored in in the state as
votes and then at the at a certain epoch
boundary these votes are counted and if
there is a majority of votes for a
specific f1 data this specific f1 data
is updated in the state as the the
latest snapshot of f1 and the idea here
basic basically is on this majority
sampling so we have we have the large
number of validators that's a million
validators we have this honesty
assumption that at least 2/3 of the
active validators are honest we're going
to sample a thousand of them and and the
way that this the sampling works is over
a thousand sequential slots and if we if
this randomness is good enough then we
know if high probability that least one
half of the f1 voting committee will be
honest the voting committee being these
1000 block proposes and and so that
means that if we have at least half of
the votes here vote for a given piece of
data then that piece of data will be
representative of reality representative
of f1 and and by the way this on this
majority idea is reused for cross Nexus
as well
okay so now I guess comes the the more
interesting stuff so the the attestation
this is the work that the validators
have to do so what is inside an
attestation so this is kind of the
header of the attestation it has a
signature and here it's important that
we have the BLS because we have
different validators all part of the
same committee that will be signing the
same attestation and the way that the
aggregation works is that we're going to
specify in in the aggregation bits here
which validators have participated in a
specific aggregation so we have a
committee let's say of a thousand
validators they're ordered and this bit
list is going to be a thousand bits each
0 1 1 indicating that the a validator
was included in the aggregate signature
here for this attestation and then we
have the data which is going to be the
body of the attestation which is more
interesting and it basically has three
parts the attestation that when you make
an attestation as a validator you're
making three votes all in one go and
this is part of the reason why this is
part of what I mean by harmoniously
connecting the various elements this is
one one place where we've done it so
when you when you make an attestation
you you're voting for a a past beacon
block and that's going to count towards
the focus rule LMD ghost but at the same
time you're making a finality vote and
FFG vote and so you're going to be vote
you're going to be voting for a source
target pair and so that's going to lead
to justifications and finality and in
addition you're voting for a cross link
so as a
you assigned to a specific shot you
meant to download the piece a chunk of
the short run it validate it and if it's
good then make a cross link so vote vote
for that specific chunk of shot so I
mean this was covered by Danny basically
the the the in the what is a checkpoint
here in the FFG vote is nothing more
than a pair of an epic and an hash and
what is a cross link well the cross link
is a small segment of a shot so how do
you represent that well you need the
shot number you're going to need the
start of the end the end
Apoc of this chunk of shot that you're
cross-linking and you're gonna need the
the data roots which is going to
represent this can be the merkel is a
ssin of the chunk that your cross
linking okay so in green we have the
attestation in the blocks and then on a
slot by slot basis they get stored into
the states and they can either get
stored in the as previous époque or
current epoch attestation so if your
attestation is stale it's very old it's
older than the previous app book then we
don't even bother saving it in state we
only record the current and previous
epoch at the stations and then and then
here we have the the beginnings of the
finality mechanism so the financing
mechanism works on an epic by epic basis
hence the the blue arrow and what it
does is that it is going to look at the
the cache of recent data stations and
then count count the votes and if we if
we get to this two-third threshold is go
and we're going to record that we have
met the two first fresh hold by
modifying the justification bit and also
by potentially advancing the the last
and the previous justified at Bach and
then if we have this so-called finality
patterns of which we have four as
explained by Danny then we're also going
to advance the the finalize checkpoints
so the the beacon chain is going to be
aware of its its last finalized
checkpoint and as part as part of this
you know as part of the the safety of
this this mechanism is the idea of
slashing the testers that that make bad
votes so how does this work well we have
fraud proofs we have proofs that our
testers have been doing a bad job these
are included in in blocks in green and
they're going to have an immediate
effect a green arrow on on the registry
so if someone has has done / herbal
behavior they will be marked as slashed
immediately on in the registry and in
addition to that would we keep track of
the total amount of of 'if that that
that was slashed and the reason we do
that is because we want to the the we we
want to have a mechanism whereby if only
a few a testers do bad stuff for example
then we they're not really jeopardizing
the system so we don't want to penalize
them to too strongly but if lots of
people are doing bad stuff then the
system is at risk and so we want to
penalize everyone - to a large extent
and so this this variable here in the
state in blue is is keeping track of how
much bad behavior has
happened in the recent past and then we
have the cross links and this this works
pretty much exactly the well very
similar to mmm yeah to to to to this so
no doesn't work the same oh no this is
different sorry so this is basically is
as a mapping from from shard to to to
cross link and it records the either the
the previous cross links all the current
cross links and basically on on an every
every epoch hence the blue arrow we
would we save the current cross links in
the in the previous cross links and that
basically allows for the for the beacon
chain to be aware of of recent cross
links across all the shards and hence
for every shot to be aware through the
beacon chain of the cross links on on
every other shot and yeah this is this
is pretty much it so we have the full
kind of honest state transition function
at a high level again like made out of
these modules which are replaceable
which talk to each other and at the end
of the day there isn't that much
happening there's basic scaffolding
there's you know maintenance of the
registry which is kind of obvious stuff
and then there's finality which is a
very important gadget and then we have
this cross linking gadget for shouting
okay great so that's what we're looking
to launch in phase 0 but what what comes
afterwards we we have transfers which
are slated to come likely in in phase 1
which will basically allow for efj on
the beacon chain to be
and that will create a market for this
if now we also have a bunch of security
upgrades that we're looking to do and
each of these security upgrades are
optional but they're very nice to have
and you know one of the reasons why
we're not putting them up front is
because they all have you know fancy
constructions and fancy cryptography so
one one of them is Cassidy proofs which
we're looking to do in phase one we have
the idea of secret proposes where
instead of knowing upfront who then who
the next proposals will be we can have a
system whereby we don't know which
proposes will be invited to create
beacon blocks and that is a way to
protect ourselves against in our service
attacks because if you know who the next
proposals will be then you can target
them I didn't add the networking layer
we have vdf randomness upgrade which you
know my comment phase to my Combinator
and then we have data availability
proofs and I mean one thing I didn't
mention here actually is like clients in
infrastructure so we want to make it
very easy for for to have a beacon chain
like clients and and this infrastructure
will come in phase one and we also have
[Music]
CBC Ghost which is e CBC Casper which I
haven't listed here and then kind of to
two other ways in which we we may
upgrade the beacon chain is to have
multi hashing so instead of having one
single hash function sha-256 we might
add native support for another hash
function one which could be friendly to
stocks and to stocks and you know later
down the line we're also looking to
change the various cryptographic
primitives which are not quantum secure
and change them over to quantum secure
equivalents and so this includes BLS 12
381 which is not quite and secure and
also the RSA based vdf which is not
quantum secure so I guess that will keep
us busy for a few years and yeah that's
it Thanks
[Applause]
Thank You Justin I'm gonna close it out
talking about the validator duties in or
as age says duties I'm talking about the
validator duties in phase zero some of
this if you actually look at the phase
zero state transition spec the validity
conditions that Justin didn't go into
kind of imply what a validator should be
doing but to make that explicit we have
the separate dock and when I was
compiling my slides I thought that was a
good idea so I made a QR code and a tiny
URL so this document which I'll go over
some of the the core components of it
explain what and when a validator should
be doing with respect to the beacon
chain the initial part of this document
talks about creating public keys
initiating deposits and a lot of that
was kind of covered in sha ways and just
will be out of scope for this portion so
you the tooth the two main things that
you do in phase zero is you propose
blocks and you attest to blocks in
subsequent phases you would do similar
activity but also on chart chains so we
have some stuff going on pretty much at
any given slot you can say am i the
proposer and if you are make a block
this can be this is independent of your
at the station committee your
cross-linked committee assignment and
it's Noble within the epoch of of
assignment you you don't have a look
ahead in a prior epoch which is also
different from the committee assignments
and the action of proposing a block is
is at the
the initial start of a slot so slot ten
starts I make my block I give it to the
world and this is this is your proposal
is publicly publicly known and so as
Justin talked about secretly to election
of something that we're looking at you
computing the proposer index is
essentially taking all the validators
shuffling them and using some some of
the recent randomness along with their
effective balance to sample them great
so you the the chance of you being
selected is also proportional to your
balance most most validators and normal
operating conditions would have an
effective balance as we call which is
capped out at the max which is capped
out of 32 so most in many situations
that be an equal equivalent chance of
being selected for proposal so Justin
are you talked about these data
structures the beacon block pikna block
body what I do is I reveal my R and L
which is a signature upon the epoch I go
and find my eighth one data which I'll
show you about in a second I signed some
graffiti maybe I'll vote on some
proposal or I'll say things about Who I
am and I fill in any of these operations
most importantly I'm gathering up at two
stations because that's how I make my
block proposal worth it and profitable
by including high value add two stations
which are add two stations that have not
yet been included a decisions that are
highly aggregated so it has a lot of
participants in them and add two
stations that are a more recent by
optimizing those things I can optimize
my reward I think you get one-eighth of
the reward that was given to at a
stations for added stations you receive
yourself so in general by proposing by
being a good proposer over time you're
increasing your award by about 1/8
deposits deposits we come to consensus
upon the eath one data which is some
past eath block
and the deposit contract deposit route
and this deposit route allows us to
process deposits in order of making a
proof against that route a merkel proof
and this number max deposits is I have
to I have to buy the rules of the
protocol include deposits any
unprocessed deposits up into that max
deposit so I think that's the number 16
so if there were 32 deposits that are
unprocessed I have to include 16 if
there were 2 I include the 2 and then no
more if there's zero zero
I also voluntary exits might be flying
around on the network I can pick those
up put them in I'm kind of naturally
incentivized to put those in because the
fewer validators that exist
I'm the functions a little bit dynamic
but I get a little bit less overhead and
and it's nice proposer slashings and a
tester slashings I might also choose to
be I might be policing the network
looking for nefarious activity and if I
find these things submit proof proof of
them I get a portion of the I I get a
small reward a small amount of what was
slashed so we can look into a little bit
more into this eath 1 data essentially
what this function does is like what I
call a pile-on vote like once I see we
divide the voting period the youth 1
voting period into a number of epochs
and if I see good votes for each one
data I just picked that vote and and I
and I vote on it some of the some of the
mechanism in here is to prevent me
piling on to votes that were that were a
little bit stale so early on in the
period if that's less than the integer
square root of the slots per Earth one
data period I am will not pile on my
vote if it looks like someone was
putting in some stale information but
otherwise I just vote on what the
majority is and is valid if there's no
votes
[Music]
the default I go get my oneth one data
and what what we do in this this initial
release is that we follow the eighth one
chain by like a thousand blocks to be
safe this is not the eighth one the
beacon chain cannot handle if there were
a reorg past that and the eath one chain
knows nothing about the beacon chain so
this is an assumed safe distance to
follow the chain and so you do have like
an induced latency on handling deposits
because of that I'm not certain what the
most deep reorg has ever been in eath
one but it's not even on the order of
like 100 so assumed to be safe unless
there was an attack if there was an
attack
maybe we should revert the eath one
chain instead of the beacon chain
because it was attacked but that's
mostly cool slash ability to block
proposals it's really cheap to sign
things so we have to make it but it's as
opposed to improve work it's it's very
expensive to make blocks that look valid
because you have to exert the
computational power so if I've been
chosen to make a block I need to the
protocol needs to make that expensive so
that I can't make a ton of them so
essentially we have a very simple
slashing addition that is making sure
that I'm not making too the same block
in the epoch actually in a
soon-to-be-released version that's
changed to me not making the same block
in the same slot but essentially it's
like a no double vote no double proposal
mechanism committees so I don't know if
we've explicitly talked too much about
committees we talked about like how we
shuffle those people into committees but
essentially within a given epoch every
validator is assigned to exactly one
slot to attest to it to create an
attestation that they destructor that
has all the things votes on the head for
the fork choice votes on a cast for
every vote votes on a cross link it does
all sorts of stuff so I can use this
function
- essentially query which slot I'm
assigned to what shard I'm assigned to
and I can do my duty I get a look ahead
of at least one epoch so during the
current epoch I know my assignment in
the next epoch this allows me to sync
whatever shard I need to and kind of
like get ready for my duty this is
actually tunable in Mincey look ahead if
we for some reason needed a longer look
ahead because the overhead of syncing a
chart or something was long we could
tune that constant it's a trade-off
between a kind of the longer you have
you know the committee is the easier it
is to potentially dose or bribe or
whatever so I make an attestation yeah I
had the cursor highlighted so that's why
it's green
so I make this out to station I do it at
the slot might the slot I'm assigned to
that time plus half of a slot duration
so the ideas and optimal conditions a
proposer has created a block at the
start of a slot and by halfway through
the slot I've gotten that block I see
that as the state of the world I vote on
it in certain non optimal conditions I
might vote on some prior block but I can
still kind of add weight as Vitalik
showed an in fork choice and I can still
manage to we can still keep the chain
moving forward and finalize things
around my fork choice and I get I see
where the head of the chain is the state
relative to that head of the chain at
the slot that I'm assigned to is also
going to give me this information so I
can actually just go into the state and
say hey what was the checkpoint what are
we voting on right now and just pull
that information and construct this data
this is actually just stubbed in phase
zero but this is relative to me running
the fork choice on the sharp chain
um that's not super important that's
actually what I'm gonna put into the
crosslink which Justin pretty much
covered the fun part is that because
it's a zero and there's no short chains
so just a zero Hashim because he bit so
this is I just want to show you this
data structure because even though it
phase zero we don't have a notion of
sure we don't have any chart chains so
we don't have this notion of custody
games and having custody of shard data
but there is this notion of like a bit
in a custody bit which is tied to my
personal a personal secret that I have
and the attestation the cus of the cross
link that I'm cross linking and so I'm
not actually signing just the
attestation data I sign the attestation
data with my bit zero or one and so for
any given Committee in phase one we'd
have two versions of this aggregate able
signature the one with the zero bit and
the ones with the one bit in phase zero
this is stubbed as a zero bit right but
in this outer data structure with the
custody bits so we remember we remember
who participated with the aggregation
bits and we remember which custody bit
they participated with so that we can
reconstruct the mess the proper message
to validate the signature in the future
in phase zero when I'm constructing my
antis a Shinto broadcast I flipped my
bit my position in the shuffling of the
committee I flipped that bit and for the
custody of its that's all 0 and I
broadcast that to the network at the
halfway point of the slide let's see
there are some micro called micro
incentives related to the creation of an
attestation it's pretty much the various
components of what I'm doing is the head
correct correct being defined by what
ends up being the canonical chain was
the target of the F of G vote correct
was the source of the FG FG vote correct
the crosslink so pretty much any of
these things that end up
canonical if I got the vote right I get
a good reward and I also get rewarded
for fast inclusion this is so the sooner
the opposition gets included on chain
the more reward and this portion of the
world were word degrades very quickly
and this is so that I don't I'm not
incentivized to like wait a little bit
longer see what everyone else is doing
before I actually cast my vote I want to
move very quickly
get my vote in and get maximum reward
this is handled in processed rewards and
penalties this is maybe not so
surprisingly after our Interop session
this is where we found the most
consensus bugs on our initial networks
obviously the calculations that deal
with everyone's balances was where we
had bugs but then reading writing some
new tests and enhancing that getting
ready slash ability about his stations
this these correspond to the two
slashing conditions found in Casper FFG
pretty much if it's not the same vote it
can't I mean if it's not the same boat
it can't be the same the same epoch
essentially if you double signed in an
epoch you're slashed and you can't do
this surround vote so if we have this
add to station' that has a source and
target we can't have a kind of a
surrounding attestation that just like
jumps over it that's it cool yeah thank
you that was a long session appreciate
you all being here
[Music]
you