►
Description
Topics covered
-----------------------------
1:44 - EIP-4399
1:50 - Header
2:14 - Abstract
3:55 - Depending on EIP-3675
5:15 - Specification
7:50 - Side effect
9:41 - Backward compatibility
14:50 - Do you have any project in mind that could be affected with this change to PoS?
17:50 - Randomness beacon
18:09 - RANDAO mechanics
21:50 - RANDAO properties
28:17 - Example of usage
35:53 - Backward compatibility - Is there anything that could be done to onboard some of the dApp devs who are not very confident of the proposal?
38:47 - Security consideration - Would you see it creating any vulnerability to the chain or any other downside ?
41:07 - Reference implementation - Do we plan to add links to different implementations of clients?
42:36 - Do you think it is a good time to move the EIP to the next status?
46:29 - What are your thoughts on the semantic use of the word “Random”?
Resources:
------------------
- Slides: https://docs.google.com/presentation/d/1YU-MBZiM8oHH1yzAr734atfUFqMJi1V9MmwFM9oVP6k/edit#slide=id.g8cb00373fc_0_96
- EIP: https://eips.ethereum.org/EIPS/eip-4399
- Discussion: https://ethereum-magicians.org/t/eip-4399-supplant-difficulty-opcode-with-random/7368
- How The Merge Impacts Ethereum’s Application Layer - https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/
- Practical SNARK-based VDF - https://zkproof.org/2021/11/24/practical-snark-based-vdf/
- EIP-3675 - https://youtu.be/zNIrIninMgg
- The Merge playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqoLxXqZqT4hcYhoHoP6w12
Follow at Twitter
-----------------------------------------------
Mikhail Kalinin @mkalinin2 | William Schwab @William94029369 | Pooja Ranjan @poojaranjan19
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow PEEPanEIP earlier episodes at https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
A
Welcome
to
another
merch
special
episode
of
p
penny,
an
educational
video
series
where
we
learn
about
an
ethereum
improvement
proposal,
upcoming
updates
and
the
basics
of
ethereum
blockchain,
I'm
your
host
puta
ranjan
and
today
we
are
going
to
have
an
overview
of
eib
4399,
supplant
difficulty
opcode
with
random,
with
our
very
special
guest,
mikhail
kalanin.
Thank
you
for
joining
us,
mikhail.
A
He
is
one
of
the
co-authors
of
the
eip4399,
a
core
proposal
proposed
in
late
october
this
year,
and
this
proposal
is
expected
to
be
deployed
on
the
midnight
with
the
march
upgrade
previously
mikhail
joined
us
on
the
show
to
explain
eip3675,
which
is
a
great
consensus
to
proof
of
stake.
That
is
another
very
important
proposal
for
the
merge
and
it
is
highly
recommended
to
watch
episode
41,
that
is
a
peep
3675
before
watching
this
episode
to
get
a
better
context
of
eap
4399.
A
B
Thanks
a
lot
for
introduction,
so
this
one
is
43.99
and
yeah.
It's
gonna,
be
it's
not
gonna,
be
like
too
long
presentation
today.
So,
let's
start
so
we're
starting
with
the
header
and
one
of
the
co-authors,
as
puja
mentioned,
the
other
one
is
daniel
ryan.
Most
of
you
are
familiar
with
him.
Also,
this
eap
depends
on
36.75.
B
So
the
motivation
is
default
here.
First,
first
of
all
would
like
to
expose
the
randomness
that
is
accumulated
by
the
begin
chain
to
the
application
layer
and
hence
the
upcode
is
required
to
allow
for
access
to
this
randomness
inside
of
the
evm
and
the
other
thing
why
it's
implemented
this
way,
why
it's?
What
the
randomness
outputs
the
plants,
the
difficulty
value
that
is
exposed
by
the
difficulty
of
code
is
to
avoid
breaking
the
existing
applications.
That
depends
on
the
difficulty
as
a
source
of
randomness.
B
So
that's
that's
the
motivation
behind
this
eap
and
behind
this
specific
behind
this
specification.
So
the
next
one
is
the
dependency.
Let's
just
go
quickly
through
the
dependencies
on
the
3675
here.
So
the
transition
block
has
has
been
mentioned
is
literally
the
first
proof
of
stake
block
in
the
system,
and
this
is
where
the
c8,
this
eap,
30,
the
for
the
399,
takes
the
effect.
B
They
are
just
deprecated
by
sets
to
the
their
respective
constant
values,
and
there
is
the
node
below
this
table,
which
just
says
that
this
this
fields,
these
constants
these
fields,
will
be
used
in
the
future.
So
these
constants
may
be
replaced
by
some
real
values,
and
this
is
what
happens
for
43.99
the
mix
hash
value.
The
mixed
hash
field
is
reused
to
keep
the
randomness
output
value
after
the
merge.
B
Yeah,
the
the
motivation
behind
the
rationale
behind
why
to
use
the
mix
hash
instead
of
difficulty
is,
is
the
following.
The
difficulty
is
in
the
essence
of
the
folk
choice
rule
before
the
merge
in
the
proof-of-work
network,
and
this
way
by
keeping
it
zero
literally
zero.
We
we
try
to
avoid
hidden
bugs
in
the
fortress
rule
that
might
appear
if,
if
this
field
would
be
set
to
any
arbitrary
large
number,
which
is
the
randomness
out
of
these,
so
instead
of
this,
we
use
a
mix
hash.
B
B
B
C
B
B
So
it's
pretty
yeah,
it's
pretty
safe
to
use
it
okay.
So
let's
move
to
the
backwards
compatibility
section,
which
is,
I
think,
very
important
here.
So
obviously
this
eap
introduces
backwards
and
compatible
changes
to
the
protocol
itself
because
it
changed
the
semantics
of
the
op
code
and
the
it
changed.
The.
B
B
So
if,
if
there
is
any
smartphone,
if
there
is
any
smart
contracts
that
use
the
difficulty
field
as
the
real
proof
of
work
difficulty,
they
will
no
longer
function
normally,
but
this
is
actually
does
not
relate
to
the
4399,
but
it
rather
relates
to
the
getting
rid
of
proof-of-work
at
all,
and
this
is
basically
what
the
3675
does
and
yeah.
That's
that's
what
not
like
likely
introduced
only
here
by
this
specification.
B
B
B
So
the
next
is
statistics
the
next
which
which
is
outlined
here.
I
think
it
makes
sense
to
put
all
like
randomness
stuff
on
one
slide
is
the
just
want
to
remind
that?
The
block
hash
of
code
will
not
anymore
the
the
values
that
is
returned
by
block
hash
of
code.
Since
the
merge
happens,
they
will
not
be
any
more
secured
by
the
proof
of
work
seal.
B
B
The
compound,
in
fact,
is
like
as
follows:
if
you're,
if
your
application
use
the
difficulty
to
to
obtain
a
real
preferred
difficulty,
it
will
be
like
no,
it
will
not
operate
normally
after
the
merge.
Obviously,
because
there
is
no
proof
of
work,
then,
if
your
application
used
the
block
hash
and
only
a
block
hash
to
obtain
the
source
of
randomness,
it
will
be
easily
manipulated
by
the
the
the
the
flow
of
yeah.
B
The
way
that
it
works
will
be
easily
manipulated
by
the
proposers,
and
if
your
application
uses
the
difficulty
of
code,
mixing
it
with
any
other
source
of
randomness
as
a
source
of
randomness,
it
will
continue
to
operate
and
normally
and
will
get
this.
You
can
chain
randomness
after
the
merge.
So
that's
like
the
summary
yeah
yeah.
I
I
I
take
a
short
break
here
before
we
go
to
to
the
randomness
discussion,
how
it's
what
the
mechanics
of
randomness
on
the
beacon
chain
and
what
the
properties
does
it
have.
A
So
I
had
a
question
on
the
backward
compatibility
we
just
discovered
so
as
per
the
eip,
the
backward
incompatible
changes
to
execution
and
validation
of
evm
state
transition,
and
you
just
talked
about
the
projects,
though
those
can
be
affected.
With
that,
do
you
have
any
project
in
mind
right
which
could
be
affected
with
this
change
to
pos.
B
As
being
said,
just
if
you're,
if
any
application
uses
the
difficulty
as
the
real
difficulty
from
the
proof
of
work
world,
it
will
be
affected
if
the
application
is
relies
on
the
block
hash
and
only
on
the
block.
Hash
is
a
source
of
randomness.
It
may
be
affected
because
the
block
hash
is
like
becomes
malleable
after
the
merge,
because
it's
not
secured
by
the
proof-of-work
seal
anymore.
B
B
A
B
Yeah,
if
it
uses
difficulty
in
any
in
any
way
to
obtain
randomness
if
it
even
if
it's
mixed
with
block
hash
with
timestamp
or
whatever,
is
people
use
for
to
get
randomness
yeah,
it
will
not
affect
it
and
it
will,
like
you,
know,
yeah,
it
also
yeah.
Of
course,
it
depends
on
how
it's
designed
yeah,
but.
B
B
Okay,
so
randomness
it
yeah.
That's
all
for
this
eap,
it's
pretty
straightforward
and
easy
to
unders
to
to
be
understood.
Yeah
and
now,
let's
talk
about
the
randomness
which
is
offered
by
the
beacon
chain,
so,
first
of
all,
yeah
the
run-down
mechanics
in
a
very
simple
way.
So
you
may
see
here
that
there
is
the
each
picking
block
contains
the
randow
reveal,
which
is
revealed
by
the
proposer
of
this
block
and
yeah.
Even
before
the
merge.
B
B
First
of
all,
the
the
reveal
is
the
signature
and
each
proposer
proposer
of
each
block
signs
the
number
debug
number
with
the
its
private
key
and
that's
the
basically
the
real.
There
are
some
other
input
parameters,
but
this
what
makes
like
the
most
sense.
So
it's
the
signature
and
we
assume
that
propose
that
validators
picks
their
private
keys.
They
really
like
using
the
very
secure
randomness,
so
it
gives
the
very
high
randomness
properties
to
these
render
reveals
and
they
can
be
verified.
B
So
this
is
basically
each
reveal
is
the
output
of
the
very
file,
verifiable
random
function
and
all
these
xors
and
the
rundown
mix
is
the
output
of
the
verifiable
random
function.
So
it
can
be
like
literally
from
the
very
beginning
from
genesis.
It
can
be
verified
all
these
random
axes.
If
you
know
the
all
the
other
stats
till
till
that
time.
So
what?
B
If
the
random
code
is
called
in,
the
block
number
say
number
two,
then
the
return
value
will
will
be
the
random
x
computed,
with
the
render
our
reveal
from
the
previous
block
from
the
block
number
one.
That's
it
that's
how
it
works.
So
it's
the
random
returns,
the
previous
random
x,
not
the
one
that
is
computed
within
this
block
box
reveal
so
there.
There
is
the
reason
behind
this,
but
it
doesn't
that
matter
much
here.
B
B
B
B
Fee
includes
transactions
fee
and
yeah
mev
after
the
merge,
and
for
this
ghost
it
may
decide
to
not
propose
a
block,
and
this
gives
the
proposer
one
bit
of
one
bit
of
manipulation
power,
so
it
it
may
in
theory
and
in
practice
it
may
produce
two
different
render
mixes.
One
is
with
his
current
render
reveal
that
is
about
to
be
revealed
in
the
blog
or
the
one
without
his
render
reveal,
because
he
is
withholding
the
block
withholding
the
proposition
of
the
block.
B
By
playing
with
these
empty
slots
and
yeah
part
one
is
empty.
Another
one
is
contains
the
block
and
vice
versa.
First,
so
four
different
outputs
may
be
produced
in
this
case,
but
if,
if
these
empty
slots
that
were
made
on
purpose
to
avoid
revealing
their
endow
is
followed
by
an
honest
proposer
that
proposes
the
that
reveals
his
randall,
then
dislike
kind
of
doesn't
make
much
sense
for
these
two
like
this.
This
will
not
have
them
and
a
further
effect.
B
So
this,
like
this
sequence,
just
like
broken
here,
so
that's
how
it
could
be
biased.
There
is
yeah
just
to
remind
that.
The
size
of
the
output
is
256
bits
and
one
bit
can
be
one
bit
of
manipulation.
Power
is
behind
each
proposal.
So
it's
not
like
that
big.
Of
course,
it
depends
on
the
number
of
the
outputs
that
the
user
of
this
randomness
oracle
has
and
yeah.
It
depends
on
the
application
of
this
randomness.
B
So
it's
just
unsafe
to
use
it,
but
what's
not
that
much
predictable
is
the
future
random
axis
the
future
mixes
that
computed
with
the
future
reveals,
and
here,
for
example,
if
we
take
a
look
at
the
above
diagram
if
we
say
that
that
the
the
random
op
code
uses
the
render
mix
generated
by
the
block
before
so
at
the
time
of
block
b1
b1,
it's
not
yet
known.
What
will
be
the
rundown
reveal
of
of
this
block
before
and
it
can't
be
like
yeah
to
to
to
to
get
this
value.
B
The
one
will
need
to
ask
the
proposer
or
bribe
the
proposer
to
to
reveal
its
render.
Of
course,
the
proposer
knows
what
renderer
will
it
will
have
in
the
next
block,
but
yeah,
but
this
like
kind
of
look
ahead
into
the
what
render
reveals
will
occur
in
the
system.
It's
very
much
limited
and
this
limit
is
it's
limited
by
the
set
of
proposers
that
will
be
assigned
to
some
future
ebook.
B
So
the
mechanics
of
the
smart
contract
that
user
and
random
may
look
as
follows.
Suppose
it's
a
lottery
or
any
other
logic
that
depends
on
the
randomness
and
smart
contract,
has
deployed
some
epochs
epochs
behold
before
the
end
e-book
and
starts
to
accept
bits.
After
beginning
of
the
epoch,
end
bids
are
no
longer
accepted
and
during
the
in
the
two
epochs
after
the
results
of
the
results.
B
B
So
before
the
the
set
of
proposers
the
set
of
rendau
reveals
is
even
exists,
is
even
is
known
or
the
set
of
proposers
even
exists.
This
players
who
can
influence
the
like
who
can
gain
something
from
influencing
their
and
the
randomness,
do
ebooks
after
they
even
yeah,
they
even
don't
exist
and
they
they
have
no
like
incentive
to
participate
in
this
lottery.
B
And
yes,
let's
just
try
to
imagine
how
it
can
be
gamed,
so
one
may
bribe
validators
of
a
few
epochs
to
reveal
together
and
our
reveals
in
advance.
This
can
give
the
understanding
of
what
the
proposer
set
will
be
and
by
bribing
the
in
the
in
all
the
validators
from
the
proposer
set,
basically
it's
theoretically
possible
to
get
this
exact
random
x.
That
will
be
used
to
draw
the
results
of
this
application
of
this
lottery
and
in
the
in
all
this
sequence.
B
Also,
there
is
the
incentive
to
introduce
the
slashing
condition
for
earlier
randall
reveals,
so
if
it
will
be
pretty
unsafe
for
the
proposer
to
reveal
his
rendao
beforehand
to
to
anybody
in
the
network
that
can
use
this
to
slash
this
proposal
also,
the
other
way
that
it
could
be
gamed
is
the
like.
Suppose
you
you,
you
know
the
the
whatever
is
that
you
will
know
this.
B
There
is
chaos
for
leaders
that
reveals
the
randall's
contributions
before
the
call
to
random
code
and
try
to
get
some
manipulation
power
out
of
this
and
try
just
bribe
them
to
not
to
not
propose
a
blog
and
that's
it.
So
that's
pretty
much
yeah.
That's
also
also
bear
in
mind
that
you
have
like
not
that
much
time,
because
each
epoch
is
like
six
six
minutes
and
a
half.
So
it's
it's
not
practical.
B
I
would
say
so:
it's
not
practical
to
to
to
game
this
kind
of
application.
So
the
cost
of
this
is
relatively
high.
Also
to
reduce
the
bias
ability
property.
There
is
a
vdf
research,
the
link,
all
pnt
resources,
so
the
pdf,
basically
the
verifiable
delay
function,
will
will
significantly
reduce
this
passability
vector
yeah.
A
A
B
A
B
Yeah-
and
I
would
like
to
say
that
it's
it
can
this
this
randomness
that
is
accumulated
by
the
beacon
chain,
it's
pretty,
with
pretty
strong
properties
coming
with
pretty
strong
properties,
with
respect
to
what
the
bulkhash
can
give,
but
it
depends
of
course,
on
how
the
application
is
designed,
but
use
it
it
can.
It
can
be
designed
in
completely
unsecured
way
like
using
the
already
published
random
mix,
and
that's
that's
the
way.
It
should
not
be
that's
the
way.
You
know
the
design,
also
yeah.
B
A
Interesting,
yes,
and
we
also
have
recorded
an
episode
on
kinsuki
testnet,
with
parito
and
proto,
for
people
who
want
to
have
a
little
bit
more
background
on
that
and
want
to
learn
how
to
participate.
Please
go
check
out
the
documents
which
are
listed
in
the
description
section,
all
right.
Moving
on
to
the
question
and
answer
section,
I
have
a
follow-up
question
on
the
backward
compatibility.
A
So
if
I
understand
correctly,
the
idea
of
preserving
the
difficulty
instruction
numbers
for
the
new
random
op
code
is
to
support
the
existing
smart
contracts,
so
they
will
be
able
to
use
the
evm
instruction
with
the
same
number
as
source
of
randomness
output.
Irrespective
of
whether
merge
has
happened
or
not,
I
mean
there
was
also
a
pointer
which
can
actually
indicate
when
it
is
being
on
the
pos
chain.
B
B
So
but
anyway,
they're
announced
in
the
discord,
so
you
can
follow
up
appear
there
and,
let's
just
discuss,
I'm
always
open
for
discussion.
So
reach
me
out
directly
any
of
this.
I'm
not
sure
that
there
is,
like
you
know,
all
the
concerns
that
are
addressed.
All
the
concerns
of
that
developers
are
addressed,
but
if
you
have
them,
please
appear
and
yeah.
Let's
start
working
on
it
because
it
soon
will
be
moved
on
and
yeah.
B
A
And
just
to
add
on
here,
the
merge
community
call
that
mikhail
is
talking
about
generally
happens
once
a
month.
We
had
the
call,
I
think
in
early
december,
third
or
fourth
december,
and
the
recording
is
available
on
ethereum
cathode
is
youtube,
we'll
be
planning
another
one
in
early
january
or
somewhere
around
that,
so
it
would
be
nice
to
have
you
guys
around
and
share
your
share.
Your
concerns.
A
A
Would
you
see
this
I
mean
like
in
in
terms
of
a
project?
Like
you
explained,
with
the
lottery
system,
it
doesn't
seem
very
harmful
when
we
look
it
from
the
application
side,
the
lottery
side.
Would
you
see
it
creating
any
vulnerability
to
the
chain
or
any
other
downside
that
possibly
could
be
there.
B
B
Currently,
it's
it's
pretty
much
predictable,
because
the
difficulty
is
computed
out
of
the
difficulty
formula
and
it
can
be
predicted
and
in
a
much
more
feasible
way
than
this
random
access.
So
I
think
that
what
have
been
discussed
today
in
this
example
should
be
like
in
the
security
consideration
so
like
to
given
an
idea
to
to
dub
developers
to
people
how
this
should
be
properly
used.
To
avoid
this,
you
know
to
avoid
the
lack
of
security
for
the
applications
that
use
this
random
app
code.
A
A
So
my
next
question
is
related
to
reference
implementation.
As
you
mentioned
that
this
proposal
is
already
implemented
in
most
of
the
clients
and
it's
a
live
on
the
kinzuki
testnet,
I
find
the
section
as
tbd,
so
I
was
just
curious.
Like
do
we
plan
to
add,
maybe
reference
links
over
there
for
the
different
implementation
in
different
clients.
B
A
Right-
and
there
is
another
small
question
which
is
again
related
to
the
proposal:
it's
about
the
test
cases.
So
it's
good
like.
I
understand
that
testing
the
functionality
may
go
beyond
the
eip
documentation,
but
I
was
just
wondering
like
it
would
be
nice
to
have
pointers
where
people
can
follow.
I'm
not
saying
that
this
is
a
requirement
for
a
proposal
to
move
to
the
next
status,
but
just
wondering
if
we
can
have
the
link
that
can
be
added
for
a
reference
for
the
cip.
A
B
Yeah
one
thing
I
would
like
to
add
there,
as
I
mentioned
this
security
consideration
stuff,
to
explain
more
about
the
the
randomness
properties
and
yeah.
Basically,
these
properties,
like
probably
with
more
working
and
more
you,
know
clear
way,
and
I
think
then
we
can
move
it
to
review
and
yeah
when
it
will
happen.
I
I
expect
that
this
will
happen
like
kind
of
in
february
so
and
this
this
one
will
this
eap
as
it
depends
on
36.75
their
status
will
be
changed.
A
Right,
yeah,
right
and-
and
you
rightly
mentioned
that
this
eip
439
is-
is
having
a
requirement
of
a
eip3675,
and
it
is
already
mentioned
in
the
proposal
that
they
both
are
supposed
to
be
deployed
at
the
same
time
on
the
main
net.
That's
fair
enough,
but
I
understand
you
are
also
the
co-author
of
the
eip3675.
A
B
A
D
B
B
That
will
give
like
you
much
understanding
and
much
awareness
of
how
it
should
be
used.
So
it's
called
random
just
for
simplicity
and
what
does
mean
random
in
this
particular
setup,
and
this
particular
system
is
better
read
from
the
the
description
and
which
will
the
description
of
this
proposal
and
specification
and
the
security
considerations.
B
So,
that's
I
don't
think
yeah
I
I
I
see
the
the
intention.
I
see
the
sentiment
here,
but
I
really
don't
think
that
it
makes
much
sense
to
use
anything
other
than
random
here,
because
you
will
anyway,
whatever
is
used.
You
will
have
to
go
and
read
the
stack
and
understand
how
does
it
work
and
how
and
understand
how
can
you
use
this
in
a
safe
and
secure
in
a
secure
way?
A
A
A
I
hope
this
proposal
4399
and
even
the
proposal
3675
to
be
moving
up
to
the
review
status
and
eventually
become
final
when
the
upgrade
is
deployed
on
the
main
net.
On
this
note,
thank
you
viewers
for
watching
this
episode.
If
you
like
it,
please
hit
the
like
button
and
share
it
with
the
rest
of
your
community
member,
slides,
discussion,
2
and
other
related
links
along
with
guest
twitter
to
follow,
are
provided
in
the
description
section.
A
Should
you
have
any
question
or
anything
you
want
to
ask,
or
you
want
to
suggest
some
proposal
to
be
discussed
in
future
episodes.
Please
leave
us
a
comment
or
share
with
us
in
the
chat
at
this
part,
I
would
like
to
take
a
moment
to
thank
all
our
guests
and
ease
contributors
and
youtube
viewers
for
your
love
support
throughout
this
year.
Today
is
the
last
recording
for
penny.
For
this
year,
it's
been
fun.