►
From YouTube: PEEPanEIP #22: EIP-3076: Validator client interchange format with Michael S., Sacha S., Danny R.
Description
Topics:
1:25 - Introduction
4:35 - Overview
7:25 - Slashing
8:00 - Double vote
10:15 - Surround voting
12:15 - Specification
13:12 - Signing rules
15:26 - Implementation
16:33 - Minimal history
19:24 - Escaping catastrophe
23:20 - Attestation
24:40 - Justification & Finalization
26:25 - Does every client has to know that the 2/3 has been met?
27:46 - BLS signature
29:51 - EIP finalization
31:34 - The implementation is reliant on a client, is there an issue if a client makes a mistake?
35:35 - Any places for a validator to look into to know what to avoid?
36:28 - How compatible is Prysm's new database schema for the implementation of EIP-3076?
37:25 - Would complete implementation of EIP-3076 in Prysm have prevented the recent (mass) validator slashing in Prysm?
39:45 - EIP status - when to move to the last call?
42:05 - Security concern - If honest validators are slashed due to some bug, will it be easier for a malicious party to take control of the consensus?
44:05 - If you were to revert the chain, will the slashed nodes be reverted?
45:30 - When you get slashed, where does the ETH go?
45:44 - Slashing other validators could be of very high incentive for a nefarious body to create a profitable attack?
47:00 - Timeline for HF1 and Eth1-Eth2 merge. List of proposals/features that Eth1 must-have for the Eth1-Eth2.
53:55 - Future of Pyrmont
Resources:
EIP - https://eips.ethereum.org/EIPS/eip-3076
Presentation - https://docs.google.com/presentation/d/19pHHc3qCPV6CXpoWOTKzeUKIb089ocZf9URW48Ti7-0/edit?usp=sharing
Discussion - https://ethereum-magicians.org/t/eip-3076-validator-client-interchange-format-slashing-protection/4883
Reddit post - https://www.reddit.com/r/ethstaker/comments/la62io/overview_of_eip3076_by_michael_sproul_sacha/
Follow at Twitter:
Michael Sproul @sproulM_ | Sacha Saint-Leger @sachayves | Danny Ryan @dannyryan | Pooja Ranjan @poojaranjan19 | Alita Moore @AlitaMoore85
Check out other exciting EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Contact Ethereum Cat Herders
Discord: https://discord.gg/tzYmDmF
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders/PM
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Welcome
to
another
episode
of
penny,
an
eip
dedicated
series
where
we
discuss
an
ethereum
improvement
proposal
and
understand
how
it
is
going
to
make
ethereum
even
better.
I'm
your
host
pooja
ranjan
before
we
proceed
with
today's
discussion,
a
quick
reminder
if
you
have
missed
discussion
of
any
other
proposal
that
we
have
covered
in
earlier
episodes,
you
may
follow
the
recording
available
on
people.
Playlist
at
edm
caters
youtube.
A
Today
we
are
going
to
talk
about
a
beacon
chain
proposal
that
helps
prevent
validated
slashing
in
certain
cases,
eip
3076,
validated
client,
interchange
format
is
a
core
proposal
that
is
already
implemented
in
four
clients:
lighthouse,
nimbus
prison
and
taku
created
in
september
2020.
The
proposal
is
in
draft
status
to
provide
an
overview
of
the
proposal.
We
have
got
the
co-authors
of
the
proposal,
michael
and
sasha,
from
lighthouse
and
nimbus
respectively.
A
B
B
That
sounds
ideal,
so
I
I
joined
up
and
since
then
I've
been
worked
on
lots
of
things
in
the
lighthouse
client,
including
slashing
slashing
protection,
the
database,
the
consensus
layer,
things
like
this,
and
I
came
to
write
the
cip
or
the
the
what
became
this
eip
one
morning
when
someone
said.
Oh,
we
need
a
standard
format
for
these
validators
yeah
over
to
you
sasha
hi.
So
I
got
involved
thanks
to
barnaby,
actually
who's.
B
I
did
a
bit
of
the
early
lighthouse,
docs
and
and
also
nimbus,
and
then
nimbus
lost
their
technical
writer
and
and
because
I'd
already
known
the
team,
I
kind
of
slotted
in
quite
naturally
there,
and
so
I'm
mainly
doing
nimbus
stuff
now,
but
also
ef
stuff
as
well
when
when
danny
needs
help
with
writing
something
yeah
my
involvement
in
the
ip
I
mean
to
be
clear.
This
is
michael's
brainchild.
I
just
sort
of
kind
of
helped,
write
it
and
and
and
make
things
clear.
B
B
Guess:
okay,
so
so,
essentially
the
the
worst
thing
that
can
happen
to
you
as
an
individual
when
you're
running
a
a
validator
or
node
is
getting
slashed
right.
It's
first
of
all,
you
lose
a
not
insignificant
amount
of
leave,
and
secondly,
it's
it's
game
over
you
can't
you
can't
really!
Well
you
can't
you,
you
can't
validate
again
with
that
same
validator
right,
you
have
to
hold
deposit
a
whole
new
32,
if
and
and
so
on.
B
B
Okay.
Next,
oh
so
I
kind
of
did
this
a
little
bit
already
yeah,
so
so
the
motivation-
essentially
maybe
I'm
repeating
myself
a
bit,
but
but
every
client
has
a
slashing
protection
database
and
and
if
you
standardize
it,
you
make
it
easier
for
people
to
switch
between
clients,
and
that
can
also
be
useful.
If
one
client
goes
down
because
of
the
bug
right,
there's
a
then,
then
you
know
you
don't
want
to
be
sitting
on
the
sidelines
doing
nothing!
B
B
B
A
validator
here
is
voting
for
two
different
target:
epochs,
it's
kind
of
the
equivalent
of
a
of
a
double
spend.
Is
that
correct,
michael?
Is
that
how
you
would
describe
it
yeah,
it's
kind
of
yeah
these?
These
are.
I
intended
this
diagram
to
be
an
attestation,
though
so
yeah,
it's
a
another
station
with
a
source
in
epoch,
560
and
then
two
different
targets
in
epoch
561..
So
it's
kind
of
saying
that
you're
voting
on
two
blocks,
but
those
blocks
conflict,
so
they
could
be.
B
It
definitely
is,
I
think,
almost
all
the
slashings
we've
seen
on
mainnet
have
been
double
votes
and
there
were
a
whole
spate
of
them
yesterday.
Actually,
so
this
presentation
is
quite
well
timed
yeah
yeah,
so
that
is
the
most
common
one.
So
this,
I
think
and
michael
correct
me
if
I'm
wrong
here,
you're
showing
that
there's
this
is
also,
although
it
looks
quite
different.
B
B
And
and
the
other,
the
other
where
you
can
be
slashed
is
called,
surround,
voting
and
that's
essentially
when
you're
voting
for
one
version
of
reality
and
later
voting
for
another
in
a
way
that
doesn't
make
it
clear
that
you
no
longer
believe
in
the
first.
But
here
the
specific
conditions
are
that
your
your
you
have
two
source
and
target
epochs
and
and
the
source
and
target
of
one
of
them
have
to
be
surrounded
by
the
source
and
target
of
the
other.
That's
why
it's
called
the
the
surround
vote.
B
B
And
I
wanna
vote
for
five
six
two
and
then,
if
you
later
make
the
small
vote
at
the
bottom,
there
you're
saying
that
time
went
backwards
from
five
six
two
to
five,
six
one
which
doesn't
make
any
sense
and
that
the
and
that
560
is
now
justified.
So
you're
acknowledging
the
progression
of
time
on
one
side,
but
not
on
the
other.
So
it's
kind
of
it's
it's
all
over
the
place
and
the
the
consensus
proofs
for
casper
ffg
require
that
this
case
be
prevented.
B
So
the
specification
itself
is
a
json
file.
It
allows
you
to
export
multiple,
the
history
for
multiple
validator
pub
keys
in
each
file,
so
you
don't
need
multiple
files
for
different
validators.
If
you
have
them
all
in
one
bundle,
and
you
can
have
a
list
of
blocks
and
attestations
that
you've
signed
for
all
your
validators
and
then
perhaps
most
importantly,
there
are
some
rules
about
how
to
interpret
this
import
file
if
you
import
it
into
a
new
client.
B
This
is
an
example
of
the
of
the
format
that
we
came
up
with
there's
some
metadata
at
the
beginning.
That
just
includes
a
version
for
sort
of
backers,
compatibility
considerations
and
a
genesis,
validators
route,
which
is
just
to
kind
of
pin
it
to
one
specific
beacon
chain
and
then
there's
the
data.
Where
you
have
a
pub
key,
a
list
of
blocks
that
you've
signed
and
a
list
of
attestations
that
you've
signed
and
yeah.
We
can.
B
We
can
return
to
this
example
if
if
people
have
questions,
but
I'm
gonna
keep
going
for
now,
so
these
are
the
there's
five
signing
rules.
These
are
the
signing
rules.
The
probably
the
most
intuitive
ones
are
number
one
and
number
three,
which
just
say
that
if
there's
a
block
or
an
attestation
in
the
in
the
validated
interchange
file
that
you
imported,
then
you
your
new
client
that
you're
importing
to
should
never
sign
anything
that
is,
that
is
slashable
with
respect
to
those
those
messages
that
you've
imported.
B
So
the
only
slashing
offences
you
can
commit
for
blocks
are
double
votes,
so
no,
no
double
voting
on
any
on
any
slot
from
the
blocks
that
you
imported
and
no
making
surround
surrounding
outer
stations
for
any
attestation.
From
from
this
set,
and
then
the
other
rules,
two
four
and
five
are
about
not
not
making
messages
prior
to
the
portion
of
history
that
you
imported.
B
Yeah.
So
the
reason
that
we
design
the
format
like
this
in
a
maybe
slightly
surprising
way
with
that
minimum
rule
is
partly
to
support
a
diversity
of
implementation.
So
there's
various
ways
that
clients
implement
slashing
protection
databases
and
we
want
to
be
compatible
with
all
of
them,
and
we
also
want
it
to
be
flexible
enough
to
handle
catastrophic
outages
and
in
fact
the
spec
was
born
out
of
an
outage
on
the
modasha
test
net,
where
it
would
have
been
very
useful
to
have
a
format
like
this.
B
So,
firstly,
just
about
implementation,
diversity,
there's
two
main
schools
of
thought
when
it
comes
to
how
to
make
a
slashing
protection
database.
One
is
a
complete
history
model
in
which
you
keep
a
copy
of
every
message
that
your
validator
signs
and
this
ends
up
being.
You
know
you
keep
more
data
than
in
the
minimal
approach
which
I'm
about
to
cover,
but
it
ends
up
being
a
fairly
straightforward
way
of
of
keeping
track
of
what
your
validator
has
voted
for
in
the
minimal
approach.
B
You
only
need
to
keep
the
latest
message,
so
you
keep
the
the
block
that
you've
signed
with
the
with
the
highest
slot
or
the
slot
of
the
most
recent
block
that
you
signed
and
also
the
source
and
target
of
the
most
recent
attestation
you've
that
you've
signed-
and
this
is
the
approach
that
teku
uses,
and
it
has
a
lot
of
advantages
because
it's
it's
very
simple.
The
one
thing
that
it
can't
do,
though,
is
if
you
accidentally
vote
really
far
in
the
future.
B
Then
you're
definitely
blocked
to
that
point
in
the
future,
and
that's
that's
actually
related
to
the
outage
that
we
saw
so
yeah
those
those
minimum.
Those
minimum
bound
rules
that
we
saw
before
the
two
four
and
five.
I
can
go
back
and
show
you
them
actually
just
to
be
so
we're
saying
no
adder
stations
with
source
less
than
the
minimum
imported
source.
So
if
you
have
an
attestation
with
source
five,
nothing
would
source
less
than
that
and
no
attestations
with
target
less
than
or
equal
to
the
minimum
imported
target.
B
So
these
rules
use
the
minimum
so
that,
if
someone
signs
something
far
in
the
future,
that's
completely
unrelated
to
the
rest
of
their
attestations.
You
can
keep
signing
in
the
gap
in
between,
whereas
if
a
client
like
teku
that
uses
the
minimal
format
exports
to
the
standard
format,
then
they're
only
going
to
export
one
block
and
add
a
station,
and
it
will
be
the
latest
block
and
attestation,
and
we
will
also
not
sign
before
that
which
is
equivalent
to
teku's
slashing
protection.
B
So
it's
in
this
case,
when
you
only
have
one
block,
the
minimum
block
is
the
same
as
the
maximum
block
and
teku
just
say.
Here's
our
latest
block,
don't
sign
anything
before
that
and
we
go
okay,
that's
good.
We
can
do
that
and
the
other
clients
understand
this
and
and
implement
this
as
a
sort
of
low
water
mark
where
you
advance
this
low
water
mark.
Each
time
you
import
one
of
these
interchange
files,
so
maybe
this
would
be
a
good
time
to
take
questions.
Does.
Does
anyone
have
any
questions
about
that
mechanism.
C
So
I
have
because
I
know
you
you
later
mentioned-
that
for
certain
types
of
clients
you
should
take
the
highest
block
and
then
otherwise
you
take
the
minimum
and
if
they're
sending
you
multiple
blocks
that
are
like
I
mean
you
know
you
have
multiple.
Will
you
have
multiple
like
epochs
or
whatever?
Wouldn't
that
be
an
issue
because
they're
kind
of
like
giving
you
the
future
or
whatever,
or
is
that
not
how
yeah.
B
So
the
the
intention
here
is
that
if
you,
if
you
have
an
interchange
file,
it
should
represent
a
an
uninterrupted
view
of
the
validator's
behavior
in
that
period
of
time.
So
if
you,
if
the
file
contains
a
whole
bunch
of
blocks
and
attestations
from
some
starting
point
to
an
end
point,
we
assume
that
that's
everything
that
happened
between
those
two
points.
B
So,
although
we
could
enforce
a
rule
that
says,
don't
sign
anything
less
than
the
maximum,
we
weaken
that
slightly
to
say,
don't
sign
anything
less
than
the
minimum
and
that's
in
order
to
deal
with
this
case
where
someone
has
accidentally
signed
something
far
in
the
future.
So
actually
I'm
going
to
get
that
I'll
get
to
that
on
the
next
slide.
Maybe
I
can
go
to
the
next
slide.
It
will
make
more
sense.
So,
during
this
there
was.
I
think
there
were
two
main
outages
on
the
madasa
test
net.
B
Basically,
so
you'll
be
able
to
make
a
few
more
attestations
until
the
source
epoch.
That's
that's
agreed
upon
by
the
consensus
like
until
the
justified
epoch
moves
forward.
So
once
that,
once
that
justification
happens,
say
you've
made
an
attestation
starting
at
epoch,
5
and
ending
at
epoch
1000,
as
soon
as
the
justified
epoch
moves
to
epoch,
six
and
you're
expected
to
vote
from
six
to
seven
or
six
to
eight
or
some
some
small
at
a
station
inside
there.
That
other
station
is
surrounded
by
your
your
incorrect
data
station.
B
So
you
can
no
longer
make
it,
but
in
the
case
of
blocks
you
can
keep
signing
blocks
through
the
whole
period
and
then
once
you
catch
up
to
where
your
faulty
attestation
in
the
far
future
was
then
you
can
resume
signing
again
as
normal
and
the
slashing
protection
databases
of
all
the
clients
will
handle
that
and
the
interchange
format
handles
that
as
well.
So
it.
B
We've
had
problems
with
getting
participation
high
enough,
partly
because
there
aren't
enough
block,
proposers
actually
making
blocks
so
just
not
losing.
You
know,
I
think
prism
nodes
make
up
a
huge
amount
of
the
network,
so
if
they
were
to
go
offline,
we'd
lose.
Maybe
you
know
50
40
of
our
block
proposals
and
that's
that's
block
space
that
other
voters
can't
include
their
attestations
in
so.
B
B
So
when
you,
when
you
have
attestations
from
a
sufficient
number
of
validators,
it
turns
out
to
be
two-thirds
of
validators.
By
balance,
then
you're
able
to
say
that
the
chain
agrees
upon
a
block
and
then
that
block
becomes
first
of
all
justified
and
then
later,
when
another
two-thirds
of
validators
have
voted
from
that
block
to
another
epoch,
then
it
becomes
finalized
and
once
the
block
is
finalized,
there's
this
crypto
economic
guarantee
that
that
block
can't
revert
unless
more
than
one-third
of
the
validators
by
balance
perform
a
slashable
offense
and
get
slashed.
B
B
Think
of
it,
intuitively
is
justification.
Is
you
you?
You
have
a
checkpoint.
That
two-thirds
of
validators
have
essentially
agreed
is
the
truth
at
that
time
and
then
how
I
would
say
how
I
would
try
and
how
I
think
about
finalization
is
so
a
a
checkpoint
first
has
to
be
justified,
so
two
threads
of
validators
have
agreed.
This
is
the
sort
of
provisional
truth
at
the
time.
B
B
That's
that's
exactly
right
and
that's
that's
exactly
how
a
bunch
of
byzantine
fault,
tolerant
protocols
were
designed
as
as
early
as
the
1990s.
So
this
thing
of
having
one
round
of
messages,
and
then
everyone
sees
that
round
of
messages
and
then
it's
locked
in
that's
a
that's
a
very
common
pattern
in
in
consensus
protocols.
So
yeah,
that's
I'd,
say
that's
a
good
intuition.
D
B
Cool
yeah.
So
no
that's!
That's
a
that's
a
fair
enough
question
the
so
the
attestations
that
I
was
talking
about
those
messages
where
everyone's
voting
there's
a
lot
of
those
right.
We
have
70
000,
80,
000
validators
on
mainnet,
so
that's
you
need
thousands
and
thousands
of
votes.
The
key
innovation
I
would
say
of
f2
is
that
we
have
a
way
of
combining
these
votes
into
very
succinct
messages
via
bls
aggregate
signatures.
C
B
If
you
have,
you
cut
the
validators
up
into
committees
in
each
slot,
and
each
committee
has
maybe
you
know,
100
or
so
validators.
If
all
those
validators
agree
on
what
the
chain
is,
they
all
sign
the
same
message
and
when
they
sign
that
message,
bls
allows
us
to
add
their
signatures
together
into
one
message:
that's
like
96,
128
bytes,
the
order
of
that
size.
C
Let
me
I
think
bls
is
a
little
bit
complicated,
but
like
essentially
with
bls,
it's
you,
you
add
up
every
so
everything
you're
trying
to
validate.
If
you
sum
up.
All
of
them
then
like
it
has
to
be
true,
like
if
you
sorry
or
feel
free
to
jump
in
I'm
trying
to
explain
this,
but
it
essentially
is
normally
for
for
normal
encryption.
C
B
Yeah
exactly
that,
that's
exactly
right,
so
you
don't
yeah,
you
never
need
to
communicate
with
70
000
nodes.
There's
the
the
network
is
cut
up
into
little
into
into
little
portions
called
subnets
and
in
each
subnet
everyone's
voting
and
they
send
their
votes
to
each
other,
and
then
that
subnet
sends
its
aggregated
vote,
which
is
what
a
leader
was
saying.
B
Yeah,
that's
that's
good.
I'm
happy
to
have
you
to
answer
more
general
f2
questions
as
well,
because
I
I
realize
that
it's
something
that
you
know
is
very
familiar
to
f2
devs,
but
to
other
ethereums
it's
a
bit.
It
can
be
a
bit
foreign
yeah,
okay,
cool,
I'm
trying
to
remember
whether
I
have
any
more
slides.
Let's
see,
okay,
do
we
do
we
want
to
move
on
to
the
eip
finalization?
B
B
I
think
that's
their
v
1.2
release,
if
you're
looking
out
for
that-
and
I
think
nimbus
also
have
support
coming
in
there
in
their
next
release
too,
and
there's
a
set
of
standardized
tests
that
we've
written
that
allow
clients
to
check
their
on
me,
their
conformance
to
the
spec,
and
I
think
all
the
clients
are
now
passing
those
standardized
tests
and
then,
as
well
as
f2
clients.
We
also
have
this.
B
This
remote
signer
from
consensus
called
web3
signup,
and
this
is
a
this-
is
a
like,
a
a
process
that
you
run
on
multiple
machines
or
you
run
with
a
with
a
really
big
back
end,
and
you
allow
lots
of
validators
to
connect
to
it
and
make
signatures,
and
then
it
keeps
track
of
all
those
signatures
and
make
sure
that
you
don't
get
slashed.
So
you
can
also
import
and
export
your
signing
history
to
and
from
web3
signup,
so
yeah.
B
C
B
Yes,
so
if
there
were,
if
there
were
a
bug
in
a
client
implementing
the
interchange
format,
so
probably
the
main
thing
that
would
happen
is
not
exporting
some
messages
for
some
reason
or
failing
to
import
some
messages.
For
some
other
reason,
then
that
could
be
quite
dangerous
and
that's
why
we've
worked
quite
hard
to
nail
down
all
the
corner
cases
in
a
in
a
standard
testing
format,
and
these
are
kind
of
already
corner
cases
of
corner
cases,
because
the
format
is
really
only
applicable
in
quite
catastrophic
scenarios.
B
So
to
be
clear,
you
could
a
lot
of
a
lot
of
people
before
this
interchange
format
existed
if
they
were
to
switch
clients
or
switch
machines,
they
just
wouldn't
bring
the
slashing
protection
database
at
all
and
normally,
if
the
network
is
running
well,
that's
kind
of
fine,
because
time
is
progressing
forward.
The
messages
you've
signed
in
the
past
have
almost
no
bearing
on
the
messages
that
you're
about
to
sign,
and
it's
only
really
in
the
case
of
sort
of
deep
reorgs
or
really
quick
switches
from
one
client
to
another
or
time
time.
B
Sync
issues
where
you've
signed
things
in
the
future
that
you
run
into
trouble.
But
yes,
if
there
were
a
bug
in
a
client's,
import
or
export
functionality
and
at
the
same
time
they
happen
to
get
unlucky
and
hit
some
turbulent
network
conditions,
then
people
could
end
up
getting
slashed.
That's
that's
the
ultimate
consequence.
B
Yeah
yeah,
the
the
main
way
that
it
really
gets
prevented
is
by
the
by
the
slashing
protection
databases
of
each
client.
So
the
interchange
format
is
really
just
a
way
for
them
to
to
transfer
that
knowledge
between
different
clients.
The
the
main
heavy
lifting
of
preventing
slashing
is
in
is
in
each
client's
flashing
protection.
So
if
you
just
use,
if
you
just
use,
say
teku
and
you
never,
you
never
switch
away
from
techie,
you
never
change
machines.
You've
just
got
tecu
set
up
and
it's
running
and
it's
stable.
B
B
To
add
to
what
michael's
saying
this.
Doesn't
it's
important
to
to
to
bear
in
mind
that
this
doesn't
prevent
you
from
it
doesn't
cover
every
case
where
you
could
possibly
slash
this
stuff
right
I
mean
one
thing
it
doesn't
cover
is
if
you
are
running
your
validator
on
a
machine
and
then
you,
you
decide
to
switch
machines,
but
you
leave
your
validator
running
on
the
original
machine
right
because-
and
you
forget
about
it,
because
by
definition
you
haven't
exported
that
database.
B
You
haven't
switched
your
validator
off,
so
it
doesn't
cover
every
possible
case
as
well.
I
think
that's
important
to
remember
to
not
be
complacent
that,
just
because
this
exists
that
there's
no
way
you
can
get
slashed,
you
can
still
make
errors,
and
this
is
more
about.
I
mean
this
covers
the
cases
that
michael
has
outlined
basically,
but
but
not
every
possible
case
yeah.
Actually,
that's
I'm
so
glad
you
emphasized
that.
That's
totally
true.
B
Yeah
so
that
when
you,
when
you
sign
up
to
become
a
validator,
the
the
f
launch
pad
tries
to
make
it
quite
clear
that
you
should
the
main
one
is
just
never
run
the
same
keys
on
two
different
machines.
At
the
same
time,
that's
that's
pretty
much.
The
only
case,
that's
not
covered
by
our
slashing
protections,
and
the
reason
for
that
is
that
it's
hard
for
clients
on
different
machines
to
even
know
that
the
other
one
exists,
and
there
is
some
work
being
done
in
this
space
to
make
that
safer.
But
yeah.
B
B
A
B
So
you
mean
the
so
the
prism
team's
new
database
schema.
I
was
nothing
yeah,
I'm
actually
I'm
not
familiar
with
what
they're
doing
internally,
but
I
I
I'm
quite
sure
that
it
would
map
closely
onto
the
format,
because
I
implemented
lighthouses
slashing
protection.
So
I'm
more
more
familiar
with
that.
The
the
export
process
is
basically
take
the
entire
database
as
it
exists,
transform
it
slightly
just
like
by
mapping
a
few
fields
and
then
dump
it
into
the
interchange
format,
and
I
suspect
that
it's
similar
for
the
prison.
A
A
B
Yeah,
no,
it
actually
wouldn't
have,
I
think,
for
each
of
the
slashings
that
have
occurred
on
mainnet,
including
the
one
yesterday
they
have
misconfigured
their
validators
or
they've
written
custom
software
to
try
and
do
fast,
failovers
and,
in
that
case,
they're
not
protected
by
their
internal
slashing
protection
database.
Nor
are
they
protected
by
an
interchange
format.
So
most
of
the
slashings
have
actually
been
slashing
pools,
writing
custom
software
and
and
ignoring
or
or
disabling
their
slashing
protection
databases
that
come
with
the
clients.
A
B
It's
it's
a
little
bit
unfortunate
that
that's
the
that's
the
state
of
it
at
the
moment
and
I
think
there's
this
to
talk
about
another
cycling
protection
strategy.
There's
this
thing
called
doppelganger
detection
that
we
might
do
in
the
future,
and
I
think
nimbus
may
have
it
already.
But
when
a
client
starts
up,
it
can
listen
for
messages
from
the
same
keys
that
it's
using
and
see.
If
there
are
any
messages
propagating
on
the
network
already
and
if
there
are,
then
it
refuses
to
start
and
doesn't
sign
any
messages.
A
Okay,
so
I
have
a
couple
of
suggestion
for
the
eip
status.
I
see
that
the
present
eip,
that
is
in
the
draft
status,
but
recently
the
process
improvement
group.
They
have
introduced
one
more
status.
That
is
called
review,
that
is
in
between
draft
and
the
last
card.
So
now
that
the
proposal
is
already
implemented
in
major
clients.
In
my
opinion,
the
best
would
be
the
review,
the
best
status
for
the
moment
with
the
review.
A
But
my
question,
however,
is
for
the
readiness
for
the
last
call
correct
me.
If
I'm
mistaken,
my
understanding
is
this
proposal
is
not
that
it
would
be
undergoing
hard
work.
One
hf1
that
that
was
mentioned
in
the
last
is
called
and
expect
it
to
be
final.
Sooner
than
that,
do
you
have
any
thoughts
like
how
soon
do
you
expect
this
to
be
ready
to
move
on.
B
Yeah,
I
I'd
say
we
could
we
could
move
as
fast
as
our
schedules
allow
us.
I
guess
the
the
main
reason
that
I
haven't
tried
bumping
this
to
review
is
that
I
haven't
had
time.
I
I'd
say
I'd
like
to
see
it
run
on
mainnet
and
I'd
like
to
try
out
all
the
other
implementations
of
the
format
before
I'm
happy
to
bump
it
to
final
call.
A
That
sounds
good.
It
would
be
great
if
one
of
you
can.
You
know,
create
a
full
request
to
change
the
status.
Also,
I'm
happy
to
share
that
the
cat
holders
are
currently
helping
out
with
getting
proposals
in
appropriate
status
like
we
have
done
it
for
so
many
eips.
I
understand
that
there
are
some
bandwidth
issues
with
the
implementers
tabs,
so
we'll
be
happy
to
create
a
pull
request
and
send
it
for
your
approval.
If
it
doesn't
get,
you
know
changed
a
request
status
very
soon.
B
C
Sure,
sorry
about
that,
I
just
wanted
to
jump
in
and
ask
you
about
security
like
it.
So
is
it
a
concern
if,
for
example,
there
were
some
sort
of
way
to
get
the
clients
to
begin
slashing
right
or
to
cause
problems
like
similar
to
the
madosa
chain
test
net?
Would
that
open
an
avenue
for,
like
you
know,
a
nefarious
actor
to
take
control
of
the
consensus
on
on
the
chain.
B
B
Yeah,
so
if
you
could,
if
you
could
slash
a
large
number
of
honest
validators,
then
you
would
have
a
better
chance
of
of
performing
a
hostile
takeover,
but
as
soon
as
you
did
perform
a
hostile
takeover,
you
yourself
would
get
slashed
by
the
remaining
honest
validators,
so
yeah,
I
I
I
don't
really
know
what
else
to
say.
I
think
that
yeah,
the
the
the
architecture
of
the
clients
is
the
main
thing
that
protects
against
that.
C
B
That
that
would
be.
That
would
be
a
big
like
social
commitment
to
to
revert
the
chain,
I'm
not
sure
if
we
would,
if
we
would
do
that,
if
there
were
a
mass
slashing.
I
think
that
I
think
there'd
be
quite
a
lot
of
momentum
to
just
keep
the
chain
running,
because
at
the
moment
the
slashing
penalties
are
actually
lower
than
they
will
be
eventually
or
slightly
lower,
so
getting
slashed.
B
Okay
now
getting
slashed
on
mass
is
still
bad.
If
you
get
sly,
the
slashing
the
slashing
severity
increases
with
the
more
people
that
are
slashed
alongside
you.
So
if
heaps
of
people
get
like,
if
half
the
validators
get
slashed
at
once,
then
they
lose
almost
their
whole
balance
actually
more
than
a
third.
If
more.
B
C
E
An
important
thing
to
note
about
that
type
of
attack
is
that
to
include
those
messages
you
actually
need
to
be
a
proposer
as
well,
and
so,
even
if
you
can
conduct
such
an
attack,
you're
not
necessarily
going
to
be
the
one
to
profit
from
it
if
those
messages
were
broadcasted
on
the
network.
Obviously,
if
you
go
and
like
hand
pick
them,
then
it
can
there's
a
potential
attack,
factor
there,
but
yeah
just
something
to
do
and
hello
hi
hi.
C
A
So,
like
we
had
this
wonderful
session
yesterday
about
the
research
work
that
had
been
done
by
the
f2
implementers
and
r
d
team,
I
first
of
all.
I
would
like
to
congratulate
for
that
and
I'm
curious
to
know
a
little
bit
more
about
the
hard
fork
one
and
the
you
know
following
upgrades
those
are
coming
on
the
timeline.
Basically,
my
question
is
assuming
the
first
upgrade
hard
fork
won
by
the
end
of
quarter
two.
Is
it
fair
to
expect
the
f1
f2
merged
by
the
end
of
2021?
A
E
E
There's
there's
a
kind
of
a
working
document
with
some
of
the
features
that
we've
definitely
kind
of
narrowed
in
on
which
are
some
minor
modifications
and
fixes
some
cleanups
to
the
way
state
is
managed
and
a
nice
to
have,
like
extension,
of
a
feature
that
does
makes
light
clients
very
easy.
This
hard
fork
also
serves
as
kind
of
a
warm-up,
hard
fork
in
the
sense
that
these
two
clients,
these
proof
of
state
clients.
E
This
beacon
chain
hasn't
gone
through
an
upgrade
cycle
yet
and
so
better
to
do
it
in
relative
isolation.
Before
we
attempt
a
larger
one
with
sharding
or
the
merge
from
there
kind
of.
As
that
hard
fork
is
put
in
place,
a
lot
of
there's
going
to
be
the
side
work
going
on
on
continuing
to
prototype
and
refine
some
of
the
early
specifications
on
sharding
and
the
merge,
and
hopefully
by
the
by
the
time,
hard
fork.
One
goes
out,
we'll
have
good
information
on
which
of
those
two
should
be
prioritized.
E
I
personally
think
that
for
these
two
major
upgrades
that
we're
gonna
do
for
speaking
chain
charting
and
the
merge
that
by
the
end
of
this
year
we
should
have
production
grade
and
we'll
have
production
grade
test
nets
and
are
setting
our
our
date
for
the
beginning
of
next
year
and
so
a
little
bit,
maybe
a
little
bit
slower
than
the
expectation
of
actually
launching
at
the
end
of
this
year.
But
I
think
that
we
can
be
in
a
good
place
to
have
all
the
pieces
in
place.
E
There's
this
nice,
we
have
to
figure
out
the
right
dance
between
where
things
are
specified,
because
I
mean
eth1
is
largely
specified
kind
of
in
the
yellow
paper
kind
of
in
the
smattering
of
eips
that
have
gone
into
the
network
and
ultimately
via
the
code
that
is
run
and
then
e2,
which
represents
this.
Like
proof
of
stake
layer.
E
E
There's
a
ton
of
work
to
do
on
e2
side
and
each
one
side
we're
beginning
to
do
some
work
on
hive,
which
is
kind
of
a
continuous
integration
work
on
that
does.
Like
load
insanity,
testing
of
eth1
clients,
I
think,
on
a
nightly,
build
movie,
weekly
and
proto
on.
Our
team
is
doing
some
work
to
modularize
that
so
each
two
clients
can
live
in
there
and
then
from
there.
We'll
do
hive
tests
that
actually
simulate.
E
That
came
up
at
the
end
of
our
call
that
peter
brought
up.
I
think
in
in
general.
This
kind
of
marriage
of
the
two
clients
is
is
pretty
straightforward,
but
then
on
some
of
the
edge
on
some
of
the
edges
like
state
sync,
which
is
it's
on
the
edge.
But
it's
a
big
one.
There's
there's
some
work
to
do
in
thought
and
specking
prototyping
and
all
that
kind
of
stuff.
E
So
there's
a
lot
to
do,
but
it's
definitely
scoped
like
we
know
what
we
are
attempting
to
do
and
the
bones
and
even
some
base
specs
are
in
place
and
even
I
actually
saw
somebody
not
on
any
of
the
teams
that
have
been
working
on
this,
but
an
independent
team.
A
different
blockchain
took
the
tekugeth,
merge
prototype
and
actually
has
a
live
test
net
today
with
it,
which
is
kind
of
cool
it's
kind
of
funny.
E
So
anyway,
that
was
a
long-winded
response,
but
there's
a
lot
to
do
and
in
terms
of
the
context
for
this
call
the
eips.
I
think
you
know
there
was
definitely
a
question
of
where
does
e2
fit
into
the
eitp
process,
and
that
question,
I
think,
becomes
exacerbated
even
more
so
when,
when
you
have
the
unification
of
the
two
kind
of,
how
are
these
things
linked
and
combined
and
it'll
be
a
fun
one
to
figure
out
in
the
coming
months?.
A
E
E
Essentially
right
now,
a
rogue
actor
could
get
a
bunch
of
girly,
eth
and
kind
of
like
they
couldn't
take
the
network
down,
but
they
could
make
it
not
finalize
and
make
it
kind
of
annoying
for
people,
and
so
it's
not
super
resistant
to
that
attacker.
If
you're
listening,
you
know,
there's
an
attack,
but
for
now
it
does
serve
quality
of
service.
E
We
might
end
up
as
we're
approaching
a
hard
fork,
one
consider
how
to
make
a
more
sustainable
version
of
piermont
and
and
coordinate
some
of
these
hard
forks,
but
if
paramount
continues
to
serve
our
purposes.
I
would
imagine
we'll
do
something
like
we
see
in
the
eth
one
dev
cycle,
where
we
we
take
it.
We
deploy
at
a
certain
slot
number
rather
than
block
number.
We
would
kind
of
this
hard
fork.