►
Description
The Ethereum Sharding Meeting #2 - Berlin
4. Beacon Casper chain by Vitalik Buterin and Justin Drake (Ethereum Foundation)
Resources: https://notes.ethereum.org/s/B1-7aivmX
---
Video: Anton Tal @antontal
Audio: Matteo Tambussi @matlemad
Producer: Chris Hobcroft @chrishobcroft
Executive Producer: Doug Petkanics @petkanics
For @livepeertv on behalf of @LivepeerOrg
A
Hello,
everyone
welcome
to
the
next
day
shorting
status.
Whatever
this
workshop
is
called
hope,
it
will
be
a
you'll,
find
it
as
happy
as
the
previous
days,
so
I
guess,
first
of
all,
so
I
guess,
first
of
all,
like
is:
are
there
many
people
here
who
were
not
here
the
previous
two
days
just
to
make
sure
okay,
so
about
to
I,
mean
yeah,
so
I
guess
sorry
about
the
oppressing
my
new
pressing,
the
minority
is
a
bit,
but
I
will
kind
of
like.
A
Did
you
assume
somewhat
that
people
some
knowledge
of
how
the
I
guess,
foreign
shorting
design
works,
but
maybe,
since
today
is
kind
of
the
development
day
will
focus
a
bit
more
on
details
from
the
implementations
from
an
implementation
point
of
view.
So
basically,
if,
if
you're
someone
looking
to
develop
a
Casper
in
shorting
client,
then
from
that
standpoint
it's
like
what
will
the
protocol
look?
A
What
will
developing
the
protocol
be
like
what
sort
of
and
it
demands
will
that
end
up
putting
on
you
so
I
guess
some
will
start
off
with
just
kind
of
repeating
a
simple
description
of
the
Abeka
of
the
beacon
chain.
So
there
is
a
first
of
all.
There
is
the
existing
proof-of-work
chain
that
we
kind
of
I
that.
A
Throughout
the
like,
basically,
the
all,
but
the
last
phase
of
the
Chardon
sharding
roadmap,
the
existing
proof-of-work
chain
is
going
to
continue
to
exist
and
it'll
begin
to
endure
continued
it
it
to
be
a
chain.
As
long
as
the
cryptic
ets
and
the
gambling
IC
o----
stay
online,
it
will
continue
having
an
uncle
rate
of
about
twenty
to
twenty-five
percent.
Unless
some
alex
a's
optimization
work
pays
off
really
well,
but
at
the
same
time
there
is
going
to
be
this
kind
of
new
beacon
chain.
That
starts
up
right.
A
A
C
B
B
A
A
The
original
spec
right
basically
had
this
idea
of
a
validation
code,
where
you
can
basically
specify
some
arbitrary
program
as
your
pub
key,
and
you
can
specify
some
arbitrary
address
for
the
withdrawal,
but
because,
especially
because
we
want
to
do
implement
webassembly
in
all
of
this
right.
We,
it's
probably
not
a
good
idea
to
like
bake
that
in
right
from
the
start,
because
the
MVM
details
might
change
so
realistically,
there's
a
large
chance
of
withdrawal
addresses
itself
going
to
be
another
pub
key
right.
A
That
you
use
for
with
that
you
use
for
withdrawing
right,
and
you
might
I
might
have
a
short
ID
in
here
as
well,
might
not
be
specified,
but
this
is
kind
of
roughly
what
it'll
look
like
right.
So
you
specify
some
data
and
at
the
very
least
you
have
to
pop
keys
and
when
you
up
deposit
the
transaction,
the
transaction,
if
everything
is
correct,
we'll
end
up
creating
a
receipt
and
this
receipt
is
so
first
of
all
any
client
of
the
products
take
beacon
chain.
A
We'll
needs
to
have
at
least
enough
access
to
the
proof-of-work
chain.
In
order
to
be
able
to
first
of
all
know
what
the
block
hashes
are.
But
seconds
know
what
the
receipts
are,
what
the
deposit
receipts
have
been
between
any
two
checkpoints,
so
for
a
previous
take
clients
being
a
proof-of-work
light.
Client
is
actually
totally
sufficient,
so
the
beacon
chain
is
going
to
also
exist
in
parallel
to
all
this,
it
will
have
because
of
the
address
of
the
attestation
mechanism.
A
And
the
idea,
basically,
is
that
if
you
have,
if
you're
processing
this
block-
and
you
see
that
first
of
all,
there
is
a
hard
consensus
rule
that
says
that
the
main
chain
reference
of
a
child
has
to
be
either
the
same
or
a
descendant
of
the
MHz
and
reference
of
an
of
an
ancestor.
So
but
then,
when
you
process
this
block
it'll
be
part
of
the
consensus
rules
that
you
also
have
to
execute
this
this
in
this.
So
you
also
have
to
execute
these
three
and
then
into
this.
A
Basically,
the
whoever
deposited
here
would
end
up
adding
themselves
into
the
and
into
the
pending
validator
set
that's
stored
over
here
right,
so
inside
of
the
beacon
chain
state
you
have
some
validator
sets
so
in
the
current
set
in
the
current
spec.
You
have
an
active
alligator
set
of
a
pending
validator
set
and
an
exited
validator
set,
and
obviously,
if
you
join,
if
you
deposit,
then
you'll
be
basically
a
joint
into
the
pending
validator
set
over
here
right.
A
So
then,
so
as
a
a
client's
developer
of
the
primitive
stake
chain
line
basically
needs
to
have
at
least
the
lifeline
of
the
proof-of-work
chain.
You
need
to
be
able
to
process
receipts
and
get
a
complete
listing
of
receipts,
and
you
would
need
to
be
able
to
actually
process
these
beacon
chain
blocks
right,
so
this
is
kind
of
fairly
abstract
structure.
This
so
far,
doesn't
really
depend
that
much
on
the
kind
of
inner
details
of
the
beacon
chain,
so
I
guess,
first
of
all,
any
questions
at
this
point.
D
B
A
So
if
you
want
something
to
be
useful
and
I,
think
the
a
proof
of
stake
chain
that
hooks
onto
the
minimal
derivative
work
chain,
basically
as
a
minimal
components,
because
that's
like
first
of
all,
I,
do
think
that
the
sharding
is
somewhat
more
up
in
the
air
than
the
proof
of
stake
side.
But
the
proof
stake
side,
even
without
charting,
will
serve
the
useful
purpose
of
providing
a
kind
of
linked
finality
gadget
right.
A
So
the
idea,
basically,
is
that,
if,
let's
say
inside
of
here
and
at
some
points
like
this
block
ends
up
being
a
of
the
beacon
chain
ends
up
getting
finalized,
then
because
this
contains
this,
and
according
to
a
consensus,
rule
that
implement
that
that
is
aware
of
the
beacon
chain.
This
being
finalized,
is
also
going
to
end
up
finalizing
this
right.
So
that's
probably
the
smallest
components
that
I
would
say
is
useful,
but,
like
the
Perot
stake
chain
is
a
significant
component
by
itself
right.
A
This
depends
like
to
what
extent
that's
actually
possible,
to
write
a
verifier
for
the
beacon
chain
inside
the
proven
work
chain
as
like,
especially
if
we,
if
in
the
earlier
versions
of
the
spec,
we're
using
a
yeah
like
we're
using
cryptography,
that's
more
kind
of
like
RSA
or
you
ought
to
curve
based,
then
snart
then
Stark
based.
Then
it
should
be
like
it
could
be
designed
to
be
implemented
implemented.
A
Oh
what
the
freaking
plows,
although
if
we
go
with
the
LS
12
381,
then
no,
because
the
main
chain
doesn't
support
BLS
to
all
3d
one
or
we've
definitely
not
efficiently.
Unless
you
do
some
ugly
hack,
where
you
would
use
BN
256
to
make
us
gnarrk
over
the
BLS,
well
3d
one,
but
that's
like
horribly
ugly
example
of
usefulness.
I
think
right.
D
A
So
shards
definitely
will
have
a
similar
dependency
relationship
as
the
the
beacon
change
in
the
main
chain,
though,
like
as
we
discussed
yesterday,
we
are
considering
this
plan
where
a
shard
chain
is
basically
only
dependent
on
the
last
finalized
walk
over
the
beacon
chain,
and
the
purpose
of
that
is
that
basically
increases
the
stability
of
the
stability
of
the
mechanism
because,
like
basically,
there
is
no
chance
of
like
the
beacon
chamber
you're
competing
to
Ocean
Road
chain
reorganize,
I
means
there's
a
bunch
of
code.
You
don't
have
to
write.
F
F
C
A
A
Like
actually
not
like
using
washes
as
randomness
for
like
any
of
the
test
debts,
that's
totally
fine
because,
like
realistically,
if
it's
a
test
that
we
don't
really
have
to
worry
much
about
attackers
and
actually,
if
someone
doesn't
and
doesn't
like
to
do
random,
it's
been
a
POA
show
on
the
blog
cache.
That
would
be
great
because
we
could
see
what
the
effects
are.
A
A
F
A
B
A
At
least
I
personally
super
to
continue
to
be
kind
of
like
throw
multiple
implementations
in
the
sense
of
like
multiple
actual
implementations
of
code
and
I.
Think,
the
reason
being
that,
like,
first
of
all,
like
we've,
seen
other
blockchain
strike
that
have
one
implementation
and
even
with
like
iOS
right,
they
have.
They
have
one
implementation.
There
is
a
bug
a
week
after
and
like
the
entire
thing
just
shut
down
until
they
get
had
a
totally
decentralized
phone
call
and
got
it
back
together
again.
A
So
it's
like
I,
don't
basically
I,
don't
think
that
especially
not
for
not
in
the
short
term,
we're
not
kind
of
slow
moving
enough
to
be
able
to
take
the
Bitcoin,
the
Bitcoin
core
approach,
which
is
like
in
basically
in
practice,
changing
barrage,
it's
changing
very
little
and
moving
slowly
so
I
mean
if
we
want
to
preserve,
like
a
very
high
degree
of
network
up
the
instability
of
which,
especially
as
we've
seen
from
the
Dass
attacks.
D
A
That,
like
you,
you
can
also
get
a
lot
of
the
benefits
of
this
by
doing
absolutely
like
basically
I
like
separating
the
two
parts
of
it
out.
So
basically,
you
have
a
establish
that
the
proof
of
State
clients
should
basically
only
talk
to
the
proof,
work
chains
through
art
by
clients
through
our
PC
and
then
theoretically.
H
A
Guess
with
my
black
box,
saying
what
we
mean
is
just
like
replacing
it
with
some
temple,
some
possibly
horribly
insecure
component
that
still
satisfies
the
same
interface
and
the
eye
base,
so
look
for
it
and
the
idea
would
be
that
it
can
be
kinda
like
swapped
out
with
the
real,
with
a
real
component
later
without
changing
on
any
of
the
rest
of
the
code,
so
for
the
random
number
generator,
like.
Obviously,
you
know
we're
thinking
of
five
design.
Well,
okay,
not
five
designs,
two
designs
and
it
can
be
gone.
A
A
Always
so,
you
know
like
arithmetic,
hash
function,
friendly
hash
functions
generally
recently,
but
even
before
that,
like
basically
the
like
you
can
outside
of
the
fancy
new
stuff
like
I,
think
we,
both
like
alike,
wake
to
and
Blake
too,
is
like
fairly
fast
and
there's
a
bunch
of
libraries
for
it,
and
we
can
in
it's
substantially
faster
than
shell
3,
and
we
can
like
get
rid
of
this
stupid
issue,
we're
using
a
slightly
different
non-standard
version
of
shell
3,
because
that's
how
it
has
to
work.
We
turned
out.
B
A
So
I
guess
we
could
go
with
the
Brewers
sub.
What
about
in
terms
of
like
what,
in
the
current
plan
as
it
exists,
a
now
beacon,
chain
blocks
and
state
are
likely
to
contain
now
obvious
weak
details
of
this
change,
but
but
it's
always
kind
of
enough
to
give
you
an
idea
so
yeah.
So
this
would
be
the
we
can
look
at
the
beacon
chain.
A
Block
structure,
so
basically
the
block
contains
we'll
start
off
with
the
block
right,
so
the
block,
first
of
all,
what
it
needs
to
contain
right
is
that
it
needs
to
first
like
first
of
all,
the
block
has
a
proposer
and
it
means
a
signature
from
a
signature
from
the
proposer.
A
second
a
block
contains
at
the
stations,
and
you
want
a
because
we're
using
aggregate
signatures.
You
want
an
aggregate
signature
for
the
ax
testers,
the
block
so
now
also
the
M.
A
So,
if
you
imagine,
you
have
say
5,000
and
testers
per
block
which
could
totally
happen,
then
you
meet
this
midfielder
basically
just
contain
5,000
bits,
so
600
us
so
625,
bytes
right
these
signatures
size
is
going
to
be
either
64,
96
bytes,
no
matter
how
big
it
is,
and
the
one
other
thing
that's
worth
pointing
out
is
that
it
is
theoretically
possible
to
combine
together
the
proposer
and
the
attested
signatures.
So
there
are
like
there's
totally
offered
some
opportunities
for
an
optimization
here,
so
that's
proposers
and
testers
blaga
testers.
A
A
A
C
C
A
Yes,
so
like
things
that
we
haven't
fully
finalized,
yet
basically
are
probably
transactions
for
slashing
conditions.
You
know,
and
basically
validator
penalization
and
I
mean
as
far
as
structure
goes.
It
might
make
sense
to
like
include
records
of
including
here
basically,
a
list
of
records
of
what
validators
joined.
Look
technically
that's
redundant,
because
the
information
is
in
the
main
chain,
but
it
would
be
a
good
convenience
feature
because
then
you
would
be
able
to
actually
fully
validate
a
beacon
chain
without
having
the
main
chain.
If
that's
what
you
want
to
do.
A
A
So,
in
terms
of
the
size
of
this
right,
like
the
bulk
of
this,
as
you
have
about
a
couple
hundred
bytes
here
couple-
maybe
a
couple
hundred
bytes
altogether
the
bid
field
could
go
up
to
something
like
a
kilobyte,
but
so
in
the
worst
case,
right
so
the
size
of
one
value
ders.
What
is
32
ether
and
the
maximum
like
for
the
maximum
amount
of
ether
that
could
exist
I'm
using
as
a
simplification,
132
million,
which
is
a
two
to
the
27?
A
And
you
know
this
is
not
a
statement
of
the
exact
exact
ether
Hartke
hard
cap
that
I
wants
to
impose
on
everyone
with
an
iron
fist.
It's
like
a
number
of
something
to
think
it's
a
like
a
number
to
use
to
kind
of
keep
in
your
head
and
think
and
what
that
gives
you
as
to
the
22
validator
slots,
which
is
about
4.2
million
so
with
4.2
million
validator
slots,
and
then,
if
we
assume
say
a
hundred
and
twenty
eight
blocks
epochs,
then
that
goes
down
to
a
two
to
the
15.
A
So
a
32,000
validators
get
included
inside
of
every
block,
which
is
baten.
32,000
bits
basically
means
these
block.
These
walk
headers
are
going
to
be
is
something
like
five
kilobytes,
and
this
has
five
kilobytes,
that's
coming
in
like
every
few
seconds
so
like
it
is
so
the
block
the
chain
in
this.
In
this
particular
structure
like
it,
it
definitely
would
be
kind
of
like
heavier
as
a
good
way
heavier
than
the
current
aetherium
header
chain,
which
is
500
bytes.
A
Every
15
seconds,
though,
in
practice
it's
not
going
to
go
up
to
5,000,
actually
will
be
like
500
bytes
every
five
seconds
and
a
one
area
of
research
is
also
thinking
about
it
like.
Is
there
a
possibility
of
designing
the
system
so
that
a
white
clients
can
get
by
with
some
subset
and
I
think
the
answer
is
maybe,
but
it's
not
clear
that
that
has
to
exist
in
the
form
of
a
chain
like
that
could
also
exist
in
the
form
of
a
structure.
A
Where
say,
every
checkpoint
vlog
has
to
point
to
the
previous
checkpoint
block,
so
you
could
download
just
the
chain
of
checkpoint
blocks
and
then
you
would
basically
use
just
the
validators
at
the
checkpoint
height
as
a
kind
of
proxy
for
all
of
them
for
all
of
the
validators
so
like
there
are
like
these
are
like
details
that
we're
thinking
about
but
not
finalized.
Yet.
A
Pointer
to
the
main
chain,
there's
no
point
well
so
remember.
The
only
case
where
the
beacon
chain
contains
pointers
to
shards
is
where
you
have
a
cross
link
and
so
like.
Basically,
the
idea
is
that
these
signatures
are
going
to
simultaneously
be
signatures
of
data
where
the
data
can
be
calculated,
but
basically
you
can
in
the
structure
in
Mike.
You
might
end
topics
you're
wanting
to
explicitly
include
like
a
list
of
what
checkpoint
hashes
hashes
people
are
voting
on
right.
So
basically
you
have
this
harriet
signature.
H
G
A
A
The
idea
is
that
there
is
no
possibility
of
general-purpose
computation
happening
on
the
beacon
chain
right,
because
the
beacon
chain
is
not
a
chain
on
which,
like
the
aggies
activity
happens
in
the
sense
of
what
people
like-
and
you
know,
end-user
activity
happens.
So
all
you
have
on
here
as
hash.
Verification
like
right
now
be
a
less
signature
of
verification
and
a
random
beacon
verification,
eventually
stark
verification,
and
that's
it.
A
D
I
H
A
Would
know
because,
like
well
in
the
design
in
the
idea
that
I
just
suggested
you
would
know
because
the
vegan
chain
would
contain
records
of
what
the
of
who
the
new
depositing
validators
are
every
time
the
median
reference
changes
but
like
you
would
have
to
trust
that
if
you're
not
validating
the
main
chain
yourself.
Okay,.
F
A
A
Right
we
do,
but
well
so
I
guess,
like
the
simplest
black
box,
random
number
generator
that
you
can
think
of
doesn't
require
any
reveals
at
all
right.
Well,
I,
guess
what
you
could
do
is
you
could
just
like
have
a
salon
for
reveals
and
then
what
block
producers
will
reveal
whatever
they
want?
That's
the
other
sort
of
that's
the
other
stubble
you
can
make.
H
A
H
H
A
I
personally
like
to
split
the
state
up
into
kind
of
two
parts
that
I
call
I
mean
in
the
spec
I
call
it
active
and
crystallize,
but
it's
basically
a
kind
of
quickly
changing
information
and
slowly
changing
information.
So
the
quickly
changing
information,
basically
is
so
number
one.
You
have
the
RNG
number
number
two.
You
have
basically
Asia
like
various
different
bit
fields,
so
you
would
have
a
you
would
have
a
bid
field
of
like
basically
who
participated
at
what
height
and
like
you
might
also
have
bit
fields
of
who
participated
at
each
cross
link.
A
So
basically-
and
you
might
have
a
series
of
cross
you'll-
have
a
series
of
cross
link
hashes
that
people
are
trying
to
submit
the
bit
us.
So
you'd
have
bit
the
bit
field
at
different
heights,
which
also
doubles
as
the
cash
graph
of
G
bid
field.
So
this
is
all
basically
storing
like
who
participated
bid
field
over
here.
Then,
let's
see
what
else
would
you
have
bid
field
at
build
fields
of
cross
links?
I,
remember
the
active
state
being
very
Caribbean,
being
very
small
right.
You
know
you
would
have
you
would
have
RNG
data.
A
That's
not
short
term,
that's
long
term
data
yeah!
Oh
yes,
so
then
long
term
data's
more
interesting
right,
so
long
term
data
you
basically
first
of
all,
you
have
validator
sets,
so
you
have
active
validators,
you
have
and
you
have
pending
validators
and
then
you
have
possibly
exited
validators,
so
exited
validators
or
just
validators
awaiting
withdrawal,
so
active
alligators
are
valid.
Is
that
Ark
active
right
now,
pending
validators
or
validator,
sort
of
logs
on
but
they've
or
that
have
deposited
but
have
not
been
inducted?
A
So
you
might
have
to
equate
one
dynasty
to
get
inducted
and
exit
evaluators
are
valid
leaders
at
which
jurors
that
are
waiting
either
withdrawing
or
getting
slashed,
depending
on
how
nice
day,
war
or
possibly,
some
combination
of
the
two.
So
for
each
of
these
right
you
have
a
basically,
you
have
a
validator
record
and
the
validator
record
might
contain,
but
first
of
all
it
contains
the
pub
key.
I'm
your
pub
pious.
It
contains
your
balance
and
real
really
might
contain
rng
private
state,
depending
on
what
the,
depending
on
what
the
rng
ends
up
being.
A
H
A
The
I
mean
it
would
also
get
environment
variables
so
like
for
environment
variables,
you
have
in
wash
timestamp
book
for
you.
You
might
want
to
allow
up
codes
for
random
number
state
and
all
that
so
like
basically,
just
for
that
assume
that
there
is
like
environment
data
that
and
the
short
is
aware
of
the
environment
data
from
the
beacon
chain
and
from
the
last
point
of
finality,
and
then
the
short
is
obviously
also
aware
of
the
area
of
the
environment
data
of
itself.
A
Pretty
much
instantly
there
isn't
sayin,
whatever
the
incentivization
of
the
execution
is
like,
depending
on
I,
guess
how
fine-grained
the
incentivization
ends
up
being.
It
could
either
happen
on
the
beacon
chain.
So
you
want
like
penalties
on
to
be
a
big
penalties
on
the
beacon
chain
or
you
could
you
incentivization
inside
of
shards,
if
you
have
like
penalties
that
have
to
be
applied
to
every
one,
every
block
or
rewards.
A
A
C
A
Well,
so
proof
of
custody
challenges
would
actually
go
here
right.
They
would
go
in
the
blog
and,
like
prove,
custody
itself
doesn't
need
to
have
a
large
state
sighs.
Does
it
I
mean
I,
get
that
in
in
this
part
of
the
state
in
the
validator
state?
You
probably
want,
like
a
you,
probably
want
proof
of
custody,
seed
commitment,
so
we'll
just
like
say
I
like
commitments,
and
then
he
OC.
A
The
active
state
is
mainly
a
bunch
of
bit
fields,
so
the
active
state
might
only
go
up
to
the
hundreds,
kilobyte
range
so
like
basically
from
an
implementation
point
of
view,
like
all
of
this,
would
just
be
a
big
long
thing
in
RAM
and
I.
Don't
know
what
she'll
the
active
state
into
an
l1
cache
or
whatever.
A
If
you
care
about
optimization
the
though
I
expect
like
basically
in
terms
of
like
cost
of
computation
and
processing
right,
you're
gonna
have
a
lot
of
bit
field,
manipulation
and
a
lot
of
hash
checking
so
up
to
or
and
a
lot
of
in
a
lot
of
BLS
signature
verification.
So
just
and
a
lot
of
like
randomly
fetching
public
key,
is
from
the
crystallize
State.
So
just
optimize
for
that.
C
A
D
A
Will
look
from
a
from
a
development
point
of
view
right
like
there's
things
that
are
easy
to
change
on
the
fly
and
there's
things
that
are
difficult
to
change
on
the
fly,
so
adding
parameters
to
header
structure
like
especially,
if
you
just
have
one
implementation,
you
know
care
about.
Consensus
is
fairly
easy
right,
so
I
don't
know,
I
figured
eonni
is
already
I
capable.
A
So
it
gets
like
at
this
point.
I
feel,
like
the
concepts,
are
definitely
more
crystallized
than
the
implementation
details
and
that's
in
part,
because
we
realize
that
crystallizing
the
concept
as
it
was
probably
what
matters
more
in
terms
of
providing
kind
of
development,
stability
than
crystallizing
the
or
like
specifying
exactly
what?
What
all
the
32
byte
hashes
look
like
in
what
the
alignments
are.
H
A
Possibly
right
so
it
depends
on
the
design.
So,
for
example,
over
here
right,
you
basically
just
include
the.
If
we're
gonna
do
the
optimization
or
we
combine
together
the
procore
signature
and
the
aggregate
signature,
then
you
can't
be
revived
the
proposer
without
verifying
everyone
else,
and
so
then,
like
basically,
you
can't
have
a
concept
of
header
whereas
like
if
we
don't
do
that,
then
you
do
have
a
concept
of
a
header.
A
Another
thing
worth
so
like
that
is
one
trade
off
and
then
the
other
question
is
like
by
having
headers,
who
are
we
trying
to
serve
anyway
right
and
like
my
answer,
is
we're
trying
to
serve
like
clients,
but
there
might
be
other
ways
to
serve
like
clients
such
as,
for
example,
on
basically
having
a
blog
parent
structure
where
you
can
verify
a
subset
of
the
chain
instead
of
value
verifying
the
full
chain.
If
you
want
to.
C
A
A
Everything
before
it
makes
sense
to
start
development
right
so
like
if,
for
example,
your
goal
is
to
have
like
a
toy
that
you
can
run
as
a
proof
of
concept
and
show
and
like
show
people
that
your
team
is
great
and
sharding
is
great.
Then,
first
of
all
you
definitely
don't
have
to
worry
about
validator
rotation.
You
definitely
don't
have
to
worry
about
penalties.
You
definitely
don't
have
to
worry
about
proof
of
custody
challenges
or
even
proof
of
custody
at
all.
A
You
can
just
implement
a
structure
that
has
some
static,
or
at
least
like
static
and
only
growing
validator
set,
and
you
can
just
like
basically
do
whatever
the
minimal
structure
is
for
FFG
messages
and
then
implement
that,
and
that
would
you
know
it
would
work.
It
would
have
a
lot
of
the
prot
of
the
properties
that
we're
looking
for
and
then
the
other
components
can
be
sort
of
added
on
over
time.