►
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 IPFS and more.
https://archive.devcon.org/archive/watch/6/time-in-ethereum-on-the-implications-of-replacing-our-dear-friend-poisson/
Time in PoW is a random process, whereas in PoS we make progress in fixed time intervals. This has far reaching implications and incentivizing timely behavior by validators is non-trivial - especially in the context of MEV.
Speaker(s): Caspar Schwarz-Schilling
Skill level: Intermediate
Track: Layer 1 Protocol
Keywords: L1 research,reorgs,fork choice
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
A
I'll
be
talking
about
time
in
ethereum,
in
particular,
I
mean
this
talk.
Title
talk,
talk
title
is
a
bit
mysterious,
so
let
me
maybe
a
bit
clarify
what
I
intend
to
talk
about,
as
you
probably
all
know,
in
proof
of
work,
ethereum
block
production
was
a
random
process
called
AKA
plus
all
process.
Hence
the
subtitle
implications
of
replacing
our
dear
friend
prosor
and
which
basically
means
nothing
else
that
other
than
that
at
a
constant
average
rate,
a
miner
would
find
a
new
block.
A
Sometimes
it
takes
three
seconds
sometimes
13
or
23,
but
on
average,
roughly
13
and
and
today
in
proof
of
stake
ethereum,
as
we
heard
already
blocks,
show
up
every
12
seconds
like
clockwork.
So
there's
no
Randomness
in
this
round
time,
but
blocktimeness
doesn't
necessarily
that
does
necessarily
is
it's
not
necessarily
12
seconds,
but
so
basically,
this
difference
in
Randomness
versus
deterministic
time
may
not
immediately
appear
as
a
big
deal,
but
it
comes
with
some
implications
that
I
want
to
explore.
There's
some
good
and
some
bad
implications
at
first
hand.
A
It
might
seem
that
it
should
only
or
predominantly
be
good
in
terms
of
load.
Balancing
the
gas
fee.
Market
should
be
a
bit
more
relaxed
Etc,
but
basically
improve
of
stake
having
these
slots
and
a
single
proposal
for
each
slot.
We
kind
of
give
this
proposer
some
kind
of
Monopoly
guaranteed
Monopoly,
and
this
Monopoly
power
can
kind
of
be
at
least
screwed
to
some
extent
to
the
advantage
of
The
Proposal.
If
that
doesn't
make
sense
right
now,
hopefully
it
will
at
the
end
of
this
talk.
A
A
This
progress
was
random
in
time.
Sometimes,
blogs
come
up
very
quickly
after
three
seconds
or
20
seconds,
but
on
average
13
seconds
in
proof
of
stake.
It's
constant
every
12
seconds,
assuming
that
a
block
proposal
shows
up,
and
basically,
when
I
talk
about
deterministic
versus
random
time,
I
talk
about
how
we
make
progress
in
our
chain,
that's
kind
of
it.
Now.
How
do
we
make
progress
in
ethereum
today?
A
Next
slot
comes
along,
we
build
on
top
of
it
and
then
here
we
have
the
scenario
that
was
discussed.
If
the
block
proposal
doesn't
show
up,
that's
okay,
the
next
block
will
just
build
on
the
previous
block.
Simple
enough.
I
want
to
kind
of
briefly
touch
upon.
Where
does
this
deterministic
nature
of
time
actually
come
from?
And
so
basically,
in
any
proof
of
stake
system,
we
need
a
mechanism
to
select
a
proposal
for
a
block
from
a
set
of
bonded
validators
and
in
proof
of
work.
A
This
is
clearly
happening
randomly
just
by
nature
of
it
being
a
race.
Every
Miner
tries
to
create
a
block,
but
on
average
only
one
minus
succeeded
every
13
seconds,
roughly
improved
working
theorem,
and
importantly,
you
don't
actually
know
who
will
win
the
next
round
improve
of
stake.
This
random
selection
needs
to
be
explicit
now.
Clearly,
there
is
no
true
Randomness
in
a
blockchain,
since
all
notes
must
come
to
consensus
on
it
and
so
different
notes.
Calling
random
a
Randomness
function
will
just
create
chaos
by
basically
outputting
different
results
in
each
case.
A
So,
instead,
what
we
do
is
we
generate
pseudo-randomness
on
chain
from
a
seed
that
is
computed
and
updated
as
part
of
the
blockchain,
and
the
challenge
is
basically
to
make
this
seat
unpredictable.
Now,
for
the
purpose
of
this
talk,
we
can
safely
treat
it
as
a
box
and
just
pretend
it
works.
It
actually
does,
and
so
essentially
what
we
do
is
we
generate
pseudor
Randomness
on
chain
to
sign
and
schedule
duties
and
the
sequence
of
Duties
is
scheduled
deterministically.
A
So
we
as
as
validators
we
need
to
agree
on
a
view
of
when
Duties
are
scheduled
and
also
of
their
time
and
so
in
ethereum.
We
chose
this
arbitrary
parameter
of
12
seconds
as
our
block
time.
It's
not
completely
arbitrary
because
obviously,
things
like
latency,
Etc
and
block
processing
are
considered,
but
it
could
have
been
11
or
13,
and
it
would
probably
work
just
fine
now
to
kind
of
boil
this
down
a
bit
more
heavily
in
proof
of
work.
A
We
are
fed
this
exogenous
Randomness
into
our
system,
which
gives
us
this
random
block
time
and
in
proof
of
stake.
We
have
to
generate
this
Unchained
pseudor
Randomness,
giving
us
this
notion
of
deterministic
time
in
ethereum
and
to
make
it
even
more
blunt.
Basically,
you
can
think
of
proof
of
work
as
a
continuous
race.
A
You
never
know
who
will
win
and
when
could
be
anyone
at
any
time,
whereas
in
proof
of
stake
we
have
the
scheduled
sequence
of
Duties,
and
this
different.
This
difference
here
already
implies
what
the
core
of
the
problem
is.
That
I
will
talk
about
in
proof
of
work.
There's
no
notion
of
late,
whereas
improve
of
stake
there
is.
A
You
can
basically
show
up
late
for
your
duties,
such
as
block
proposing,
and
you
can
basically
show
up
late
but
early
enough
to
still
become
canonical
and
that's
basically
the
wiggle
room
that
the
proposer
has
and
can
abuse
so
yeah.
Basically,
this
nice
graph
by
Martin
here,
not
sure
if
he's
here,
but
I
saw
him
earlier.
A
Essentially
it's
it's
about
block
time
around
the
merge.
You
can
easily
see
here,
yeah
improve
of
work.
Obviously
you
have
this
very
large
variance
in
Block
time
and
as
soon
as
we
hit
merge,
we
have
this
very
boring,
beautiful,
12.
Second,
slot
time
block
showing
up
beautifully
until
there's
one
missed
slot
so
block
time
jumps
up
to
24
seconds
once,
but
that's
kind
of
it
now.
A
That's,
let's
think
about
the
implications
of
this
deterministic
time,
and
this
plot
really
kind
of
illustrates
it
quite
well
and
I
want
to
kind
of
continue
on
it.
Vitalik
here
notes,
basically
I'm,
actually
in
the
way
am
I.
Not.
Basically
it's
immediately
obvious
that
this
block
time
is
less
volatile
and
there's
less
decreased
volatility
means
that
the
Galaxy
Market
is
more
stable
and,
as
vitalik
points
out.
A
There's
a
block
that
shows
up
after
a
long
time
in
proof
of
Works
case.
So
basically,
there's
another
tweet
here
by
Barnaby
who's
sitting
right
there,
basically
just
visualized
again,
it's
not
as
immediately
obvious,
but
you
can
basically
see
the
the
gas
limit
is
not
hit
as
often
in
the
second
half
of
the
plot,
and
essentially
we
can
just
summarize
this
as
better
load.
Balancing
and
I've
now
talked
about
transaction
load
balancing
essentially,
but
this
really
kind
of
translates
throughout
the
stack
on
the
P2P
layer
in
terms
of
messaging
load
Etc.
A
So
there
are
huge
benefits
to
this
constant
progress
that
we
make
in
proof
of
stake.
Ethereum,
but
obviously
that's
not
the
end
of
it.
Otherwise
I
wouldn't
be
talking
about
it
probably
essentially
proposes,
can
abuse
their
guaranteed
Monopoly
power,
and
what
I
really
mean
is
that
what
do
I
mean
by
guaranteed
Monopoly
I
mean
that
in
proof
of
stake,
there's
only
a
single,
unique
validator
that
has
the
right
to
propose
a
valid
Block
in
a
in
a
given
slot
and
improve
of
work.
A
That,
obviously,
is
not
the
case
and
this
guarant
basically
now
that
we
have
this
unique
proposal
that
is
allowed
to
propose
the
block
for
the
duration
of
a
slot.
There's
this
leeway
of
timing,
your
block
that
is
possible,
but
before
going
there,
I
need
to
briefly
introduce
some
ethereum
Basics,
basically
a
slot
there's
something
several
things
happening.
On
the
one
hand,
we
have
a
block
proposal
on
another
hand.
A
So
the
honest,
validator
spec
guide
basically
specifies
that
a
valid
data
is
expected
to
propose
a
signed,
beacon
block
at
the
beginning
of
any
slot
during
which
is
proposal.
Yada
yada
returns.
True.
So
basically,
if
you're
the
valid
the
elected
proposal
proposal
block
at
the
beginning
of
the
slot
so
zero
seconds
into
the
slot.
A
Ideally
now,
then,
the
next
phase
is
basically
testing
and
we
have
this
test
attestation
deadline
four
seconds
into
the
slot
which
basically
the
rule
or
the
spec
says
a
test
as
soon
as
you
hear
a
valid
block
or
four
seconds
into
the
slot.
Whatever
comes
first,
so
if
the
slot,
if
the
Block's
on
time
you
hit
after
one
second,
you
immediately
attest
to
it.
A
So
the
foxes
is
a
flavor
of
lmd
ghost,
which
stands
for
latest
message:
driven
greediest
heaviest,
observable
subtree,
which
is
a
mouthful,
but
it
really
intuitively
is
quite
simple.
If
you
look
at
the
Block
tree
here,
essentially
as
long
as
there's
no
Fork,
you
just
yeah,
you
just
extend
the
the
chain,
and
here
you
see
the
scenario
once
we
get
to
n,
plus
one
extending
block
N
Easy,
but
then
comes
n
plus
two
and
for
whatever
reason,
the
proposal
is
on
top
of
n,
creating
a
split
in
the
block
tree.
A
Now
now
we
have
the
basics,
and
so
let's
talk
basically
about
what
the
proposal
can
do.
I've
mentioned
it.
It's
basically
about
timing,
their
block
releases
and
there's
basically
different
Notions
of
on
time.
Like,
ideally,
you
release
your
block
zero
seconds
into
the
slot.
Then
some
validate,
like
notes,
were
on
the
P2P
layer,
receive
them
at
different
times,
probably
one
seconds
in
two
seconds.
A
Probably
everyone
has
heard
it,
but
so
as
long
as
you
hear
the
block,
zero
or
four
seconds
into
the
slot,
a
vlog
is
basically
considered
on
time
in
terms
of
a
testing,
because
you
you
hear
about
the
block
before
a
validator
test.
So
in
this
case
nothing
really
happens.
Business
is
usual,
but
the
more
interesting
case
is
what
happens
if
the
block
proposal
is
really
late,
say
11
seconds
into
the
slot.
A
Essentially,
as
you
can
see
here,
as
you
can
see
on
this
diagram,
you
have
this
attestation
deadline
four
seconds
into
the
slot
and
because
they
haven't
seen
a
block,
yet
they
will
just
vote
for
Block
n.
Now,
at
some
point,
block
n
plus
1
comes
along,
and
once
we
get
to
the
next
slot,
block
n
plus
2
has
to
make
a
decision
on
what
block
to
extend
on
what
basically
to
build
on
block
n
or
n
plus
one.
A
You
might
think
that
n,
plus
one
shouldn't
become
part
of
the
chain,
because
no
one
actually
voted
for
it,
but
in
terms
of
fog,
Choice
The
Weight,
by
is
the
weight
of
block
n,
is
actually
inherited
by
block
n
plus
one
and
so
n
plus
2
will
extend
that
chain
for
a
good
reason.
Actually,
so
we
have
maybe
to
go
back.
How
does
this
here
we
go
so
what
basically
happened
here?
A
A
That,
obviously,
can
lead
to
centralizing
effects
that,
if
you're
not
a
sophisticated
proposer,
you
yeah,
you
simply
earn
less
than
sophisticated
once.
So
what
can
we
do
about
it?
Essentially,
there's
I
think
roughly
three
categories
to
think
in
one
is
containing
this
Monopoly
power
right
now.
Basically,
you
can
release
the
block
at
the
end
of
the
slot,
what
about
making
it
so
that
we
can
kind
of
enforce
a
shorter
time
frame
where
block
can
still
be
released
but
become
canonical?
A
I
will
go
through
some
things
in
a
second
another.
One
is
explicitly
incentivizing
timeliness,
which
we
currently
don't
do
in
our
protocol
and
the
third
one
is
I'm
not
actually
going
to
talk
too
much
about,
but
is
trying
to
think
about.
How
can
we
maybe
introduce
competition
to
proposals
again
in
the
sense
of
right?
Now
we
have
this
guaranteed
Monopoly.
A
Maybe
there's
a
way
the
protocol
can
introduce
some
notion
of
competition
where
the
proposal
can't
rest
assured
that
they
have
12
seconds
to
release
their
block,
but
that
would
require
like
fundamental
changes
to
the
protocol
and
I'm,
actually
not
entirely
sure.
If
it
even
is
possible
in
a
in
a
world
where
we
have
attestations,
with
thousands
of
attestations
happening
each
slot,
what
can
we
do?
There's
some
Fork
Choice
fun
that
we
can
do
today.
A
For
reasons
unrelated
to
this
is
proposal,
boost
and
essentially
proposal
boost
is
a
is.
Is
it
called
is?
Is
something
that
the
fox
it's
like
part
of
the
fork
choice
where,
if
you
propose
a
block
on
time,
the
block
will
be
treated
as
if
it
had
already
received
40
of
a
commit
of
committee
votes.
Basically,
you
have
a
head
start
in
terms
of
fork,
Choice
weight,
but
only
for
the
duration
of
the
slot.
A
Now,
how
can
we
basically
use
this
to
defend
against
this
quote?
Unquote,
guaranteed
Monopoly
here.
In
this
scenario,
we
see
block
n,
plus
one
is
relatively
late
around
the
four
second
that
it's
released
around.
The
four
second
deadline,
such
that
some
of
the
committee,
that
votes
doesn't
inherit
in
time
before
they
test,
and
so
they
vote
for
Block,
n,
70
and
30
inherit
before
they
test.
So
they
test
for
Block,
n
plus
one
now
block
n
plus
two.
A
A
A
Another
idea
that
I
mentioned
briefly
is
that
why
don't
we
try
to
incentivize
timeliness
explicitly
today?
A
Blog
proposal
is
basically
they're
rewarded
in
proportion
to
the
profitability
of
attestation.
They
include
in
their
blog,
so
basically
attestations
that
already
exist
floating
around
this,
the
fresher
they
are
the
better,
and
so
they
are
included,
and
these
incentives
are
good
because
we
need
to
make
create
incentives
for
them
for
the
attestations
to
actually
land
on
chain,
so
that
we
have
this
notion
of
finality
on
chain.
A
A
What
I
mean
is
here
in
slot
n
log
proposal
seems
to
be
on
time
such
that
a
hundred
percent
of
the
committee
votes
for
that
block,
and
so
what
we
would
do
in
this
with
this
idea
is,
we
would
scale
them
by
a
factor
of
one,
so
nothing
changes
you're
on
time,
nice,
good
block,
n,
plus
one
for,
on
the
other
hand,
seems
to
be
slightly
late.
Only
90
vote
for
that
block.
Ten
percent-
probably
didn't,
have
didn't
hear
it
in
time,
so
they
vote
for
Block
n.
A
A
What
I
want
to
say
is
basically
that
it
should
be
incentive
compatible
in
the
sense
that
the
next
proposal
is
also
incentivized,
to
include
these
attestations
on
chain,
because
they're,
fresh
and
so
they're,
more
most
profitable
and
I,
don't
see
an
immediate
way
to
basically
grief
one
way
or
the
other,
essentially
another.
The
the
one
problem
that
it
does
have
is
that
Mev
rewards
may
actually
be
able
to
dominate
these
timeliness
rewards.
A
That
is
probably
in
some
cases
always
going
to
be
true,
but
regardless
I
think
rewarding
timeliness
makes
intuitive
sense.
Regardless
of
this
problem.
As
such,
it's
just
it
just
seems
like
it's
a
bit
strange
that
we
actually
don't
do
it
in
my
opinion
and
a
spicy
hot.
Take
that
I,
don't
actually
personally
agree
with,
would
also
be
something
like
in
a
world
of
Mev
smoothing
where
we
have
an
on-chain
oracle
of
Mev
of
the
value
of
Mev
in
a
given
slot.
A
We
could
think
about
using
that
Oracle
to
scale
timeliness
rewards
to
ensure
they
are
dominating
Mev
effects,
based,
basically
making
sure
that
the
timely
in
the
rewards
are
big
enough
to
fight
off
any
kind
of
Mev.
Dynamics
but
honestly
seems
like
a
dangerous
path
in
terms
of
making
consensus
decision
decisions
on
some
Oracle
like
that.
A
Basically,
in
short,
we
can
summarize
this
as
load
stability
being
a
good
thing
and
a
guaranteed
Monopoly
being
a
bad
thing.
Thankfully,
we
have
things
we
can
do
about
it
and
things
we
can
do
today
is
things
we
can
improve
going
forward
even
further
and
yeah
I
just
wanted
to
kind
of
put
this
out
there.
A
bit
more
and
I
will
certainly
certainly
be
thinking
about
it
more
going
forward
as
well
and
yeah.
Thank
you,
and
if
any
of
these
kind
of
incentive
games
are
of
interest
to
you,
then
yeah.
A
C
Thank
you
for
the
presentation,
I'm
just
curious
about
the
fork.
Choice
rules
like
currently
as
a
validator
I
will
either
sign
something
or
I
will
not
if
it's
too
late
right.
But
if
we're
looking
at
the
build
proposal,
there
are
some
other
stays
right
where
you
will
get
like
a
40
percent
boost
of
the
votes.
If
you
are
enough
in
time,
how
do
we
deal
with
time
actually
being
subjective
to
validators?
C
A
D
Hi,
thank
you.
So
I
had
two
questions.
One
was
on
the
one
of
the
later
slides
about
incentivizing
timeliness,
kind
of
reducing
the
reward
for
proposure
that
proposes
their
block
a
little
late.
Why
would
we
not
give
the
subtracted
reward
to
the
next
proposer,
given
that
they
were
the
ones
kind
of
I
guess
robbed
of
some
Mev
opportunity?
Is
that
kind
of
a
problem
of
just?
A
A
D
But
okay
and
then
one
more
question
is
to
better
understand
why
more
validators
don't
propose
their
block
late,
like
what
is
the
additional
incentive
for
proposers
to
propose
their
block
on
time
like
we're,
discussing
potential
ideas
for
it,
but
I
guess
in
the
current
state.
Why
do
more
validators
not
propose
late
good
question?
Okay,
thank
you.