►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/how-to-design-dvt-while-ensuring-non-correlation/
The proof of stake Ethereum specs are designed to encourage decentralization by punishing centralization.
In this session, we will discuss how to design Distributed Validator Technology in a way that minimizes correlation risk by using design choices across distributed key generation, middleware, networking topology, and versioning. We'll also describe why creating a trust-minimized, non-custodial, and non-correlated architecture is the most healthy way to enable multi-operator staking.
Speaker(s): Collin Myers, Oisín Kyne
Skill level: Intermediate
Track: Staking & Validator Experience
Keywords: Distributed Validator Technology,Staking,Validators
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
Happy
day,
three
of
Devcon
six
before
we
get
started
today,
I
just
want
to
send
a
huge
shout
out
to
all
the
organizers,
all
the
people
that
came
from
all
over
the
world
and
everyone
who
is
at
this
talk
today
so
appreciate
it.
So
today,
I'm
Colin
Myers
I'm
co-founder
of
mobile
Labs
with
ocean,
and
today
we
are
going
to
discuss
designing
DDT
for
non-correlation.
A
So
before
we
get
started.
Who
is
Obel
labs
best
way
to
think
of
us
is
that
we're
an
R
D
team,
we're
focused
on
building
a
different
ethereum
infrastructure
Technologies
for
staking
today
the
core
team
consists
of
16
members
across
eight
countries,
so
we're
quite
distributed
right
now.
Our
main
focus
is
delivering
distributed,
validator
technology
for
ethereum
as
a
primary
Network
to
begin
with.
A
So
before
we
dive
a
little
bit
deeper
in
today,
let's
kind
of
talk
about
just
ethereum
as
a
whole
and
kind
of
the
the
road
map
of
scalability.
So
a
lot
of
it,
we
just
had
the
merge
and
if
anyone
went
to
the
opening
ceremonies,
you
know
there's
this
ossification
discussion
happening,
which
is
essentially
like
hardening
the
things
that
we've
put
together,
the
things
that
we've
created
and
what
we
see
here,
the
three
main
areas
that
we've
been
focusing
on
over
the
past
few
years
to
scale
ethereum
into
its
next
chapter.
A
So
on
the
left
here.
The
first
area
is
the
execution
layer.
This
is
the
most
mature
of
all
the
different
scalability
Technologies
and
research
studies
that
have
been
done
over
the
years.
Cryptographic
Primitives
that
are
used
for
this
problem
are
optimistic
in
ZK
Roll-Ups.
This
comes
through
in
the
form
of
Layer
Two.
A
It's
actually
been
quite
interesting
this
week
to
see
that
layer
two
is
taking
over
as
they
should,
and
Layer
Two,
honestly
in
my
eyes,
seems
to
be
the
future
of
of
what
ethereum
will
build
out
of
from
a
research
perspective.
The
second
area
ties
to
layer
or
two
and
as
it
matures
more,
we
are
getting
in
front
of
the
next
problem,
which
is
the
data
layer.
So
the
data
layer
must
also
scale
while
execution
scales.
A
Common
methodologies
used
for
this
is
called
Data,
availability,
sampling
and-
and
here
are
some
examples
of
some
few
projects
that
are
focusing
on
that.
The
third
piece,
which
is
kind
of
the
most
immature
and
not
only
like
research
and
adoption
and
implementation,
is
scaling.
The
consensus
layer,
like
scaling
consensus
to
date,
has
basically
been
getting
to
Genesis
and
then
getting
to
the
merge
and
now
that
we're
in
this
post
merge
World
we're
all
kind
of
re-evaluating
the
consensus
layer
and
saying
how
do
we
scale
it
more
today?
B
I'm
going
to
take
a
million
to
describe
what
distributed
validator
technology
is
and
a
bit
more
words,
so,
at
its
most
simple,
a
distributed.
Validator
is
an
ethereum
validator
that
runs
across
multiple
machines.
Why
you
might
want
to
do
this?
Is
it
protects
you
from
a
lot
of
Technical
and
social
risks
from
validation,
and
one
of
the
first
ones?
Is
software
issues
if
you're
running
just
one
node
and
just
one
software
client,
you
know
software
generally
doesn't
like
Run
Forever
without
issue
and
similarly
I'm
running
a
distributed.
B
If
you
take
a
distributed
validator
and
you
run
it
with
other
people,
so
each
person
only
has
you
know
a
subset
of
the
private
key
that
makes
private
key
much
more
difficult,
privately
compromised,
much
more
difficult,
because
you
have
to
compromise
three
or
more
different
operators
to
get
the
full
private
key
to
you
know
flash
or
do
whatever
with
it
and
the
last
one
is
a
bit
more
abstract,
but
it's
the
idea
of
if
your
validator
goes.
Haywire
they
become
a
bad
actor.
B
They've
been
hacked
remote
code
execution,
whatever
you'd
like
generally,
you
have
no
Safeguard.
If
you
just
have
all
of
your
money
with
one
validator,
it's
just
you're
in
trouble,
but
if
you
have
your
money
in
a
distributed
validator
and
you
have
protection
so
long,
it's
only
a
subset
of
validated,
you
know
become
Byzantine
or
go
away
well
or
whatever
you
want
to
call
it.
B
Another
thing:
that's
super
important
is
to
talk
about
who
benefit
from
DVT
and
the
great
thing
about
it.
If
we
think
more
or
less
everyone
involved
in
validation
can
benefit
from
it.
The
liquid
sticking
providers
themselves.
They
at
the
moment
are
trusting
huge
amounts
of
stake
and
to
single
operators
and
they're
just
kind
of
crossing
their
fingers
and
praying
that
nothing
bad
happens.
B
They
would
much
prefer
to
be
able
to
do
to
divide
their
stake
across
operator
and
then,
if
you
know
anything
bad
happens
to
one
there's,
you
know
no
risk
or
no
loss
to
the
liquid
staking
protocol.
Similarly,
the
centralized
providers
can
gain
a
lot
from
using
distributed.
Validator
technology
I
had
the
pleasure
of
building
block
demons.
E2
staking
platform
at
Genesis
and
I
know
that
you
know
you
could
reduce
devops
risk
of
you
know
you
have
to
wake
them
up
in
the
middle
of
the
night
on
a
machine
dive.
B
If
you
know
you
have
a
distributed
validator.
Similarly,
you
can
reduce
your
Hardware
cost,
because
most
people
put
a
very
small
amount
of
validators
for
any
given
machine,
because
if
it
goes
offline,
there's
nothing
you
can
do.
But
if
you
have
a
fault,
tolerant
validator,
you
can
start
to
safely
increase
the
amount
of
keys
per
node
and
that
can
reduce
your
operating
costs
and
then
on
the
more
extreme
or
like
the
further
outer
side
of
things.
A
Cool,
so
how
is
stake
accumulating
these
were
taken
from
Elias
from
raided
his
liquid
staking
dashboard
on
Dune
data
in
this
area?
For
for
those
of
you
watching
and
who
were
looking
at
data,
this
is
probably
some
of
the
best
data
on
the
status
of
pools
and
how
they've
accumulated
over
time
and
I
would
highly
recommend
it.
A
So
where
are
we
at
today?
This
chart
here
starts
on
the
left
at
Genesis,
which
was
December
2020,
and
it
shows
the
the
dramatic
increase
in
pooled
assets
as
a
percentage
of
total
staked
assets
over
time.
So,
as
we
can
see,
it's
it's
kind
of
quite
frankly,
like
you
know
exponentially
growing
today,
numbers.
Where
are
we
there's
about
six
million
each
locked
in
pools?
A
That
equates
to
around
eight
billion
dollars
today,
and
it
represents
nearly
37
percent
of
stake
in
the
network,
so
the
37
have
stake
in
the
network
is
like
probably
the
most
important
thing.
I
want
to
touch
on
as
it
ties
to
like
what
our
thesis
is,
which
ties
to
how
we
believe
DVT
should
be
designed.
A
We
believe
that
over
the
next
12
to
18
months,
that
pooling
will
become
dominant
inside
of
most
networks,
especially
ethereum,
and
we
suspect
that
more
than
two-thirds
of
stake
in
the
near
future
will
be
inside
of
pools.
Dbt
is
today
on
the
focal
road
map
of
pools
to
help
decentralize
and
to
help
build
themselves
out.
Therefore,
we
believe
that
DVT
saturation
inside
of
these
pools
will
also
end
up
being
75
plus.
A
Lastly,
this
is
important
because
DVT
is
ultimately
a
security
protocol.
It
comes
in
a
middleware.
However,
it's
based
upon
security,
so
different
than
Mev
boost
right.
You
use
Mev
boost
to
get
more
with
DVT.
You
use
it
to
protect
the
largest
reward,
which
is
consensus,
rewards.
We
believe
that
DBT
adoption
will
be
kind
of
a
winner,
take
all
Market
due
to
its
like
security
premises
and
the
purpose
of
what
it's
used
for
so
to
kind
of
set.
The
tone
before
we
go
into
correlation
here.
A
I
just
wanted
to
to
give
a
size
of
the
market,
our
expectations
of
how
DVT
will
sit
inside
of
pools
and
then
how
large
pools
will
be
as
a
percentage
of
total
stake.
Therefore,
if,
if
this
thesis
does
play
out,
it's
incredibly
important
that
DVT
stay
is
helpful
at
scale
instead
of
becoming
more
correlated
and
unhelpful.
A
So
now
we'll
spend
a
little
bit
of
time
on
slashing
what
it
is
and
what
it
isn't
so
slashing
the
best
way
to
think
of
slashing
for
for
those
of
you,
as
if
it's
a
New
Concept
is
slashing,
is
like
the
defense
mechanism
or
the
immune
system
of
proof
of
stake
networks,
and
what
it's
here
to
do.
It's
it's
punished.
It's
here
to
punish
you
for
not
following
the
rules
in
an
attempt
to
keep
the
network
credible
and
to
follow
the
rules
of
the
protocol.
Today,
there's
two
primary
ways
to
get
slashed.
A
The
first
one
is
a
double
sign
back
in
proof
of
work.
This
was
called
a
double
spend,
and
this
has
been
mostly
predominantly
what
the
top
slashing
event
in
the
network
to
date
has
been
through
and
we'll
get
into
like
how
how
that's
happened.
The
second
one
is
a
bit
more
abstract
best
way
to
think
of
it
is
walking
back
a
slot
height
that
you
previously
said
was
finalized.
Now,
a
more
layman's
term
way
of
describing
this
is
in
the
future.
You
try
to
change
something
that
you
said
was
true
in
the
past.
A
So
therefore
you're,
trying
to
like
change
State
inside
of
the
network,
and
if
you
do
that,
you'll
be
slashed
for
it
inside
of
slashing,
there
are
different
levels
in
degrees
of
slashing
there
is
correlated
slashing
and
uncorrelated
slashing
uncorrelated
slashing
today
is
predominantly
that
the
most
of
what's
taken
place
in
the
network.
We've
been
fortunate
enough
on
mainnet
to
not
see
a
large
correlated
event.
A
Aside
from
maybe
a
couple
small
incidents
and
in
an
uncorrelated
sense,
you
can
expect
to
lose
up
to
a
minimum
of
one
eighth
based
on
the
state
of
what's
happening
in
the
network
when
it
comes
to
correlated
slashing
I
won't
spend
a
whole
lot
of
time
digging
into
it.
But
what
everyone
needs
to
know
is
is
that,
in
the
event
of
like
a
a
network-wide
event,
correlated
slashing
can
result
in
a
validator
losing
all
of
their
ether
up
to
32,
which
is
much
more
of
a
catastrophic
event.
A
So
as
we
begin
to
like
look
at
the
future
of
slashing
there's
certain
Technologies
best
practices
that
have
kind
of
gotten
over
this
uncorrelated
slashing
we'll
definitely
see
a
few
in
the
network.
It's
okay,
but
now
what
we
need
to
begin
to
prepare
care
for
is
as
like
stake,
scales
and
there's
more
products
and
more
infrastructure
providers.
How
do
we
prevent
correlated
slashing
because
it's
like
what
could
take
the
whole
network
down
or
take
all
a
validator
stake?
Okay,
so
what
is
an
activity
penalty?
A
This
is
super
important
because
it's
not
slashing
many
people
who
are
coming
into
the
space
now
try
to
say
that
inactivity
is
a
slashable
defense.
By
definition,
it's
not
and
the
way
that
we
should
think
about
inactivity
is
if
your
machine
goes
offline,
it's
okay!
You
can
take
the
time
to
bring
it
back
up
online
and
you
are.
You
can
expect
to
lose
what
you
would
have
made.
So
there
is
a
penalty
associated
with
it,
but
it's
not
a
slashing
and
it's
not
because
you
broke
the
rules.
It's
just
due
to
downtime.
A
Inactivity
can
also
be
more
severe
in
scale,
so
if
a
large
portion
of
the
network
is
inactive,
a
big
driving
force
in
the
E2
economics
and
design
is
this
average
percent
uptime
in
the
network.
So
if
that
drops
below
66,
the
inactivity
penalty
across
the
whole
network
will
grow
and
grow
and
grow
in
an
attempt
to
push
ether
out
to
rebalance
it
to
get
back
to
66
percent.
B
We've
discussed
a
bit:
what
is
the
distributed?
Validator
technology,
what
it's
useful
for
and
then
we,
like
you
know,
had
a
bit
of
a
refresher
on
slashing
and
inactivity
now,
we'd
like
to
discuss
how
we
at
Opel
have
made
certain
design
decisions
to
minimize
the
correlation
risk
because,
as
I
said,
the
tightly
the
slide
is-
or
this
talk
is
how
not
to
make
things
worse
when
we're
trying
to
make
them
better.
B
That's
not
the
customer,
that's
not
only
one
operator
and
instead
all
the
operators
come
together
and
they
do
a
distributed
key
generation,
which
means
they
all
take
part
in
a
bit
of
a
protocol
and
they
like
contribute
to
entropy
to
it
and
at
the
end
they
all
get
their
private
keys
and
they
get
approved
that
everyone
like
took
part
and
followed
the
rule
fairly.
But
there
was
never
any
moment
where
one
person
had
the
full
private
key
for
the
validator.
B
This
is
super
important,
because
if
somebody
does,
you
know
they
can
run
it
in
a
validator
and
get
you
flashed.
We
don't
put
these
private
Keys,
you
know
more
or
less
anywhere
they're
created
on
the
machine
where
the
validator
will
run.
We
don't
encrypt
them
and
put
them
on
chain
or
leave
them
anywhere
anywhere
where
people
could
attack
and
compromise
a
large
number
of
them
to
follow
through
with
that,
once
we've
helped
create
these
validator
private
Keys.
We
don't
actually
keep
control
over
them.
B
B
Your
current
clients,
all
they
really
do,
is
they
play
a
consensus
game
and
they
say
what
are
we
going
to
ask
the
validators
to
sign
and
once
they
come
to
consensus
on
that
they
present
that
to
each
validator
every
validator
says:
okay,
let
me
check
my
slashing
rules.
Have
I
already
signed
something
at
this
height?
No
okay,
that's
good
have
I
said
financially
with
further
than
what
I'm
being
asked
to
say.
No
okay,
sweet
I'm
not
going
to
get
flashed
I'll
sign
this
message
and
I'll.
B
Send
it
back
to
what
I
think
is
a
beacon
note.
We
are
actually
sitting
in
the
middleware
there.
We
intercept
that
signature.
We
gossip
them
to
the
other
different
like
nodes
in
the
cluster
and
once
any
of
them
have
enough
of
the
partial
signatures
they
can
reconstruct.
They
can
reconstruct
the
aggregate
signature
and
send
it
on
to
the
network
and
the
rest
of
the
network
says
yep.
That's
just
a
normal
validator
looks
good
to
me.
What's
nice
about
this
middleware
and
not
having
the
private
Keys,
is
you
know
if
we
are
compromised?
B
The
worst
we
can
do
is
show
something
slashable
to
a
validator
client,
but
we
get
to
rely
on
the
fact
that
the
validator
clients
are
independent,
have
their
own
code,
probably
don't
have
the
same
bugs
and
you
know
are
not
going
to
sign
anything
flashable
most
likely.
However,
if
you
only
have
just
one
validator
client,
there
is
a
scenario
where
you
know
you
find
a
zero
day
in
that
and
you
can
convince
them
to
to
sign
something
flashable.
B
So
the
next
thing
I
wanted
to
talk
about
is
the
networking
side
of
things.
So
over
the
last
three
design
decisions
we
talked
about,
we
said:
how
are
we
going
to
set
up
the
private
Keys?
You
know,
how
do
we
keep
them
maximally
safe
step?
One
then
step
two
is:
how
do
we
keep
our
software?
You
know
out
of
the
driver's
seat.
We
don't
want
to
have
total
control
over
these
private
keys,
because
if
we
can
sign
arbitrary
data,
that's
a
threat.
You
know
you
don't
want.
B
You
know
something
running
more
than
33
of
the
network.
If
you
know
they
can
sign
whatever.
Without
you
know,
any
oversight,
the
third
piece
is
obviously
are
multi-client
implementation.
Trying
not
to
have
exposure
to
any
one
piece
of
implementation
makes
you
more
like
resilient
to
bugs
and
makes
you
less
correlated
and
then
the
last
one
is
more
on
the
inactivity
side.
So
the
three
before
have
been
all
about
preventing
flashing,
preventing
flashing
preventing
flashing,
but
we
also
try
and
prevent
downtime.
B
Of
course,
if
you're
running
a
highly
available
validator,
the
pitch
is
that
you're
going
to
be
up
more
often
than
if
you're,
on
a
solo
note,
and
similarly,
if
we
had
a
distributed
validator
architecture
where
something
goes
wrong
and
we
knocked
off
every
distributed
validator
all
at
once.
The
inactivity
pattern
could
be
rather
severe
and
we
would
make
things
worse
when
we
were
trying
to
make
them
better.
So
we
have
architected
Karen's
networking
stack
is
they
are
totally
independent
from
one
another.
B
One
group
of
people
running
a
distributed
validator
over
here
has
no
common
infrastructure
with
someone
running
it
over
in
a
separate
place.
We
think
this
is
super
important
because
it
allows
you
to
have
non-correlation
effectively
if
the
alternative
to
this
was,
if
you
kind
of
bound
all
of
these
together
into
a
shared
like
networking
layer
like
message
boss
or
gossip
Network,
the
problem
with
that
is
well.
First
start,
it's
usually
slower.
B
You
have
to
go
multiple
hops
around
the
internet
and
with
the
distributed
validator
time
is
money,
so
you
don't
want
to
be
doing
that,
but
also,
if
anything
happens,
to
this
network,
you
knock
off
all
distributed
validated
simultaneously
and
that's
something
that
we
don't
want
to
do.
So
if
you
have
a
scenario
where
every
distributive
validator
has
their
own
independent
networking-
and
you
know,
if
anything
does
go
wrong-
they
go
wrong
separately
and
the
nice
piece
about
this
is
you
know
going
through
this
like
effort
of
making
everyone
set
up.
B
New
note
like
set
up
new
networking
is
definitely
a
bit
more
hassle,
but
the
benefit
of
having
independent
clusters
is.
You
can
also
have
independent
versioning
and
what
I
mean
by
that
is.
You
know
one
of
the
scary
things
in
software
development
is
releasing
an
update
because
you're
not
really
sure
it's
going
to
work,
and
it's
particularly
scary,
if
you're
securing
billions
of
dollars.
B
So
the
last
thing
we
want
to
do
is
introduce
a
correlated
outage
by
pushing
a
new
version,
and
it
is,
you
know,
pragmatic
to
assume
that
you
know
you'll
push
a
broken
version
at
some
point.
We
saw
gets
do
it
last
month
and
you
know
they're,
probably
the
most
experienced
team
in
the
space,
so
it
can
more
or
less
happen
to
anyone.
B
A
A
Our
North
Star
is
a
project
today.
What
we're
most
focused
on
is
convincing
everyone
that
validators
are
communities,
not
individuals
today.
The
way
that
the
network
topography
sits
is
validators
are
a
single
key.
Validators
are
a
single
person
or
validators
are
a
single
entity,
and
with
this
technology
we
can
migrate
that
Paradigm
into
validators
being
run
predominantly
by
communities.
A
A
Pushing
and
incentivizing
people
to
have
diversity
in
where
the
machines
are
is
actually
the
real
problem.
There
right,
there's
a
variety
of
validators,
large
ones
that
choose
to
run
on
Prem,
there's
a
variety
that
they
choose
to
run
in
the
cloud
we
were
at
dinner.
Last
night
and
the
menu
was
running
on,
you
know
us
Amazon,
East
2,
and
we
just
laughed
because,
like
everyone's
running
on
us,
Amazon
East
too,
so
there
are
like
other
types
of
correlated
problems
with
internet
usage
that
we
necessarily
can't
fight
but
still
susceptible
to
them.
C
I
was
wondering
about
the
dkg
itself
recorded
about
the
ceremony,
and
how
do
you
think
about
the
risk
that
there
is
some
problem
with
some
data
data
centers
or
something,
and
somehow
like
at
one
point,
two
out
of
four
Keys
get
lost
like
how
probable
do
you
think
this
is,
and
what
do
you
think
about
possible
mitigations
to
to
this
problem?
Yeah.
B
This
is
a
very
good
question
and
this
is
usually
referred
to
as
like
verifiable
secret
sharing
in
like
Academia,
and
this
is
the
thing
of
doing
a
tkg
is
one
thing,
but
how
do
you
know
it
actually
worked?
How
do
you
know
that
you
know
everyone
actually
contributed?
Everyone
got
a
piece
like
they
expected
and
usually
there
are
two
types
of
ways
to
prove.
A
dkg
is
fair,
they're
called
verifiable
secret
sharing
and
publicly
verifiable
secret
sharing
But.
B
Ultimately
speaking
at
the
end
of
a
dkg,
everyone,
that's
taking
part,
they
get
a
private
key
and
they
get
a
proof
in
a
verifiable
secret
share.
You
need
to
have
one
of
the
private
keys
to
check
the
proof
in
a
publicly
verifiable
Secret
chair.
It's
like
a
zero
knowledge
proof
anime
can
just
check
that
it's
verified.
So,
yes,
it
is
actually
super
important
to
make
sure
that
everyone
took
part
and
usually
there's
like
challenge
rounds
built
into
dkg,
which
says
you
know.
Does
everything
look
right?
Does
anyone
want
to
hit
the
abortion?
B
Is
everyone
going
to
like
sign
off
on
this
and
yeah
at
the
end
of
a
dkg?
Normally,
there's
a
proof,
I
think
right
now
we
have
a
VSS
proof,
meaning
only
the
peers.
No,
it
was
legit
But.
Ultimately,
we
would
like
to
add
a
zero
knowledge
proof.
So,
even
like
you
know,
the
Izzy
alido
can
say
yeah.
Those
four
operators
definitely
do
the
dkg
correctly
because
they
wouldn't
have
been
able
to
produce
a
VK
proof.
Otherwise
for
sure.
So
the
question,
because
he's
not
miked
up,
was
you
know
what
happens
if
people
lose?
B
You
know
more
than
a
subset
of
keys
and
honestly,
the
answer
is:
if
you
lose,
you
know
more
than
the
threshold
you're,
probably
gonna
you're,
probably
out
of
luck
to
be
perfectly
on
for
generally
speaking,
that's
why
you
want
four
different
operators
and
they
should
all
make
you
know
independent
backups.
If
you
have
two
operators
that
didn't
make
backups
and
left
them
in
the
same
Data
Center
and
everything
blew
up
yeah,
that's
probably
a
big
problem
to
be
perfectly
honest
and
yeah.
B
That
would
be
one
of
the
ways
where
forced
exits
would
be
nice,
because
then
the
person
that
the
withdrawalikey
could
be
like.
Oh
please,
send
it
back
to
me.
But
what
would
realistically
happen
is
right
now,
you'd
be
offline
and
you'd
be
offline,
and
should
you
hit
16
ether
and
get
kicked
out
so
yes,
if
people
don't
back
up
their
private
Keys,
you
know
even
in
a
distributed
validator.
If
you
lose.
You
know
too
many
of
the
private
Keys
you're
still
screwed.