►
From YouTube: Peep an EIP#13: EIP-2982 with Danny Ryan
Description
EIP: https://eips.ethereum.org/EIPS/eip-2982
Discussion: https://ethereum-magicians.org/t/eip-2982-serenity-phase-0/4621
Peep an EIP episode #1: Writing an EIP - https://youtu.be/Vnu4m4bBqCs
Follow at Twitter:
Danny Ryan @dannyryan | Matt Garnett @lightclients | Pooja Ranjan @poojaranjan19 | William Schwab @William94029369 | Brent Allsop @Brent_Allsop
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/sgdnxZe
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
Ethereum
2.0
genesis
is
less
than
a
month
away.
We
understand
that
it
is
essential
to
talk
about
f2
and
the
features
that
it
may
bring
for
the
ethereum
chain.
A
huge
section
of
the
blockchain
community
could
use
the
better
understanding
of
ethereum
1.0
and
2.0
chains.
Keeping
that
in
mind,
we
invited
someone
very
special
from
ethereum
2.0
development
team
to
talk
about
eip2982
serenity,
phase
zero.
B
B
B
Which
ultimately,
is
kind
of
the
upgrade
of
ethereum's
core
consensus
and
we
are
moving
towards
mainnet
with
this
initial
phase
and
I'll
get
into
that,
and
this
eip
kind
of
represents
that
bundled
into
one
thing
a
little
bit
more
about
myself
in
case
you
care,
live
in
colorado,
hang
out.
If
I'm
not
on
my
computer
working
on
this
stuff,
I
try
to
hike
and
I
have
two
cats,
one
of
which
will
probably
join
us
at
some
point.
I've
been
working
on
this
stuff
for
years
now
I
did
work
on
a
similar
specification.
B
B
B
So,
first
of
all,
if
you
follow
the
iv
process
or
if
you've
seen
these
other
peops
you're
familiar
with
the
fact
that
eips
have
a
type
and
the
most
common
type,
I
think
is
core
which
these
are
changes
that
actually
bring
in
consensus
changes
to
existing
to
the
ethereum
mainnet.
There
are
ercs
which
are
requests
for
comments.
B
Then
you
can
check
out
the
initial
pull
requests.
It's
a
bit
of
a
hot
topic
debate
and
I
think
people
were
generally
happy
with
informational.
Although
there
was
a
debate-
and
I
can
get
into
this-
this
is
more
about
like
specifications
as
to
whether
this
should
have
even
been
an
eip.
So
we
didn't.
Even
we
didn't
intend
to
drop
anything
controversial
here,
but
it
kind
of
it
is
a
strange
gip
for
a
number
of
reasons,
one
of
which
is
that
it
is
informational
thing.
B
Even
though
it's
intended
to
affect
mainnet
eventually
and
the
other
is
the
specifications
we
can
get
into.
That
later
so
I
have
the
eip
pulled
up
here:
dropped
it
9,
15,
20,
20.,
there's
some
discussions
on
theater
missions,
magicians,
there's
actually
more
discussions
on
the
actual
eip
repo
in
the
pull
request
and
there's
probably
often
a
balance
between
discussions
here,
like
the
discussions
in
the
theory,
magicians
are
maybe
a
little
bit
more
high
level,
whereas
dynamic
discussions
and
the
pull
requests
are
more
like
well
think
about
this
line.
B
Maybe
move
this
stuff
here,
but
there
was
also
some
kind
of
existential
debate
as
to
whether
this
should
be
an
eip
or
how
it
should
be
structured
in
general
there.
So
you
can
check
that
out
and
as
you
as
speaker
said,
this
is
a
draft
and
I'll
talk
about
kind
of
the
status
and
the
path
there
in
a
bit.
So
I
will
have
a
presentation
going
on
over
here
and
I
will
highlight
and
point
to
some
of
the
actual
eip
along
the
way.
B
B
And
there's
kind
of
a
proposed
structure.
If
you
don't
follow
the
proposed
structure,
the
editors
will
probably
say
why
the
hell
didn't
you
follow,
structure
and
make
suggestions
so
that
you
follow
it.
So
if
you're
writing
eip
just
follow
the
proposed
structure.
First
of
all,
is
the
kind
of
the
simple
summary
this
the
tl,
dr
is.
This
is
an
initial
phase
of
a
multi-phase
upgrade
of
ethereum's
core
consensus.
B
I
note
here
that
it's
it's
long
planned
if
you
look
at
some
of
the
early
writings
about
ethereum,
finding
ethereum
a
more
sustainable
and
scalable
census.
Algorithm
for
its
final
destination
has
been
discussed
since
early
on
and
that's
been
called
serenity
on
the
original
map,
and
what
this
does
is
breaks
up.
B
The
upgrade
of
serenity
into
a
number
of
phases-
and
this
is
kind
of
the
initial
bootstrapping
say
that
right
here
of
this
new
consensus
mechanism
in
parallel
to
the
existing
proof
of
work,
but
with
the
intention
at
that
as
the
ethereum
consensus
mechanism
in
the
future.
So
a
simple
summary:
nothing
crazy!
We're
trying
to
get
proof
of
stake
out.
Simple
summary
says
that
the
abstract
is
a
little
bit
more
technical.
B
It
says
more
concretely,
you
know
it
repeats
some
of
the
stuff
in
that
it's
like
is
of
this
consensus
mechanism,
but
it
actually
goes
more
concretely
to
discuss
like
what
actually
is
accomplished
in
phase
zero,
and
this
really
is
the
proof
of
state
consensus.
That's
the
bootstrapping
of
that
and
there's
really
two
key
algorithms
there's
a
lot
of
fine
details
on
in
terms
of
the
management
of
validators
and
accounting
and
state
and
hashing
and
all
sorts
of
fun
stuff.
But
really
what
we're
trying
to
accomplish
is
consensus.
B
Algorithms,
that
kind
of
interact
with
each
other.
The
first
is
ffg
the
friendly
finality
gadget,
which
is
a
proof-of-stake
kind
of
byzantine
fault,
tolerant,
algorithm
that
provides
accountable
safety
in
the
event
that
cohorts
of
validators
try
to
do
evil
things
accountable
safety,
meaning
that,
if
you
do
something
nefarious,
we
can
prove
it
and
your
money
can
be
burned.
B
Lmd
ghost,
which
is
really
the
driven
greedy
heaviest,
observed
subtree,
and
this
is
just
a
fancy
way
to
find
the
head
of
the
chain,
essentially
in
any
blockchain
algorithm
a
blockchain
protocol.
We
have
a
chain,
but
we
don't
actually
just
have
a
chain.
We
have
more
of
like
a
tree
and
we
find
a
single
chain.
What
we
all
agree
on
is
the
head
of
the
chain
and
is
the
the
state
of
the
world
in
proof
of
work.
That's
relatively
simple:
you
just
find
the
heaviest
chain
the
chain
with
the
most
work
improve.
B
So
really
what
we're
trying
to
accomplish
here
is
the
execution
of
these
algorithms
in
a
live
environment,
and
my
cat
has
joined
us,
hey
tyco
cool,
so
I
also
a
lot
kind
of
a
strange
part
of
the
cip
is
that
a
lot
of
work
has
gone
into
this,
both
in
research
specifications,
implementations
and
so
a
lot
of
what
happens
in
this
eip
is
I'm
referencing
kind
of
I
give
a
tl
dr,
and
I
reference
the
work.
So
you
know
I
note
that
the
in-depth
specifications
are
in.
B
B
So
the
motivation,
if
you
follow
ethereum
at
all,
the
motivation
was
probably
pretty
obvious.
I
put,
and
his
name
is
inflation
causer,
which
I
thought
was
a
pretty
funny
name
but
anyway,
circa
was
that
2017,
I
don't
even
know
2018.
I
think
it's
2017.,
the
first
like
large,
mainstream
ish
dap
that
made
it
to
ethereum
and
had
a
lot
of
usage
called
cryptokitties.
All
of
a
sudden,
some
of
the
scaling
problems
that
we're
going
to
run
into
and
and
researchers
and
some
developers
were
aware
of.
B
Solutions,
so
the
motivation
really
is
to
be
able
to
support
an
efficient
global
scale,
general
purpose
transactional
platform,
while
retaining
high
crypto
economic
security
and
decentralization.
We
won't
get
into
the
finer
details
of
all
those
things,
but
essentially
we
want
this
thing
to
be
centralized.
We
want
to
be
secure
and
we
want
to
be
able
to
handle
a
lot
of
load.
We
can't,
quite
frankly,
can't
handle
that
today,
on
ethereum
and
since
early
days
in
ethereum,
there's
been
disc.
B
In
my
opinion,
I
think
most
these
days,
it's
gonna,
be
a
combination
of
the
two
to
get
us
that
that
global
scale,
and
so
what
this
eip
aims
to
do
is
to
kind
of
take
the
step
forward
towards
layer,
one
being
able
to
handle
more
skill
and
there's
two
things
in
that
efficient
global
scale.
General
purpose,
transaction
platform,
security
centralization-
is
scaling
through
sharding,
so
essentially
to.
B
Be
able
to
handle
more
load
at
layer
one
without
sacrificing
decentralization
and
decentralization
and
economic
finality,
so
some
what
we
think
are
some
nicer
properties
and
more
sustainable
properties
by
migrating
to
proof
of
stake
rather
than
proof
of
work.
So
I
put
the
the
very
high
ltl
drg
here.
Essentially
proof
of
stake,
decentralization
security,
energy
efficiency
get
rid
of
that
all
that
wasteful
mining
and
sharding
scale
or
retaining
decentralization.
B
Essentially,
you
can
scale
up
a
block
mention
this
in
the
eip,
just
by
making
blocks
bigger
just
by
making
it
really
hard
to
run
a
full
node
and
that
I
think,
is
kind
of
in
our
cortens
sakura
sacrifices
decentralization.
So
we
want
consumer
machines
to
be
able
to
validate
the
protocol,
and
thus
we
do
this
thing
called
sharding,
where
we
break
up
validation
of
the
protocol
into
smaller
chunks
such
that
anyone
can
validate
recall
and
have
guarantees
about
other
portions
that
they're,
maybe
not
necessarily
validating
so
anyway.
B
B
B
I
spent
a
lot
of
time
here,
but
we
have
specifications
for
zero,
subsequent
phases
and
integrations
and
and
cool
stuff,
and
we
have
the
ability
to
have
like
very
dynamic
conversations
and
in-depth
discussions
over
pull
requests
and
code
changes
and
spec
changes.
So
in
terms
of
where
to
write
these
specs,
this
independent
repo,
separate
of
the
ipa
has
been
kind
of
an.
It
was
an
obvious
choice.
It
worked
really
well,
but
to
kind
of
ground
the
specification.
B
Because
that's
where
people
look
to
see
what's
going
on
in
ethereum
and
specs
and
things
we
decided
to
write
this,
what
became
an
informational
eip
with
some
of
the
core
details
for
discussion
and
understanding
and
some
of
the
core
specifications
some
of
these
like
key
parameters
for
kind
of
a
place
of
reference,
but
to
not
actually
port
the
entirety
of
the
specifications.
The
specifications
are
big
and
complex
into
this,
and
this
was
some
debate
as
to
whether
eips
should
be
used
for
this.
I
think
that
the
conclusion
was
not.
B
There
isn't
necessarily
necessarily
a
conclusion.
I
think
we
got
this
one
through
and
it
will
live
as
an
informational
eip,
but
it
really
it
brought
into
question.
You
know
if
there
is
significant
development
of
specifications
in
other
places.
Just
where
should
the
eips
stand?
Should
they
be
referencing
pointers
to
these
things,
or
should
they
not
really
be
brought
in
at
all?
B
B
B
This
is
the
proper
trade-off.
I
don't
know.
I
don't
really
know
if
I'm
gonna
weigh
in
too
much.
In
that
conversation,
the
eip
editors
will
probably
have
fun
with
that,
but
I
think
it's
a
reasonable
trade-off.
So
here
we
are
so
specification,
no
breaking
consensus,
changes
to
existing
ethereum,
we're
boot
shopping
proof
of
stake
in
parallel,
and
what
we're
doing
here
is
bringing
in
some
of
the
more
relevant
especially
to
the
community.
B
B
Orders
penalty
parameters,
genesis
time,
that
kind
of
stuff,
the
deposit
contract,
the
things
and
and
some
of
these
subsections
we
we
get
into
these.
What
we
tried
to
do
here
was
expose
some
of
the
high
level
concerns
that
community
members
and
people
that
aren't
too
familiar
with
the
e2
specs
things
that
they
might
want
to
think
about
and
be
able
to
talk
about
and
reference.
B
And
so
that's
that's
what
we
did
here.
You
know
the
release
version,
a
commit
deposit
contract,
minimum
genesis,
time,
that's
a
unix
time,
that's
december,
1st,
12
pm
utc
and
then
some
values
with
respect
to
rewards
and
penalties,
and
then
we
go
and
we
talk
about
how
there's
the
deposit
contract
that
becomes
kind
of
the
interface
into
this
new
proof
of
stake
chain
and
how
people
need
to
think
about
making
those
deposits.
B
And
then,
let's
see
kind
of
the
high
level
mechanics
about
the
fact
that
there
is
this
system
level
chain
the
beacon
chain.
There
are
validators
consensus,
participants
akin
to
minors,
and
they
have
roles
and
rights
and
responsibilities.
With
respect
to
this
and
then
really
reference
more.
Some
of
the
granular
specs.
B
At
all,
and
then
I
think
something
that's
very
relevant
to
the
community
we
brought
in
here
is
the
discussion
of
issuance
the
intention
here
being
to
bootstrap
the
proof-of-stake
protocol
in
parallel
to
the
existing
chain
and
thus
they're
actually
being
issuanced
both
to
minors
and
to
professing
validators
for
some
amount
of
time.
In
parallel,
noting
that
the
the
total
issuance
and
proof
of
stake
is
much
lower
than
proof
of
work
and.
B
Needs
to
be
made
explicit
so
that
community
members
and
other
developers
that
are
kind
of
interpreting
and
trying
to
understand
how
this
works
get
a
good
handle.
This
is
parameterized
by
the
base
reward
factor.
So
it's
definitely
it's
kind
of
a
configuration
that's
set,
and
this
dictates
those
rewards
something
that
can
obviously
be
debated.
B
This
is
a
from
consensus,
codify.
They
have
a
great
spreadsheet,
and
it's
linked
to
here
the
e2
consensus,
activate
sorry,
e2
calculator
check
it
out
that
just
shows
based
on
total
stake
kind
of.
What's
the
max
validator
issuance
and
total
ether
could
be
could
be
issued
and
then
there's
also
there's
links
to
technical
papers
scattered
throughout
here.
B
In
terms
of
like
what
the
proof
of
stake
network
is
validating
at
that
time,
but
there's
probably
a
lot
to
lose.
If
you
have
technical
issues,
and
so
there's
a
discussion
here
about
modifying
some
of
these
constants
to
be
less
punitive,
so
there's
actually
a
little
bit
less
security
margin
because
of
that
at
an
v2,
but
with
the
intention
here
to
up
these
two
they're
kind
of
full
security
parameters.
Once
things
are
stable.
B
So
that's
those
are
kind
of
the
really
relevant
portions
for
discussion.
But
in
you
dig
a
little
bit
deeper
than
that
and
you
go
into
the
e2
specs
repo
and
there's
a
lot
to
dig
in
debate,
discuss
and
reason
about
cool
here's
a
little
slide.
It's
probably
not
too
relevant
specs
the
specs
repo
is
kind
of
detailed,
very
dynamic
collaboration.
There's
a
lot
of
tests
and
there's
extensibility
we'll
be
using
them
for
subsequent
phases.
The
I
so,
although
the
specs
are
public,
anyone
can
participate.
B
B
But
again
I
don't
know
the
relationship
between
specs
and
and
eips
and
what
they
should
be.
But
this
is
how
we're
using
it
today
we'll
see
and
the
rest
there's
a
number
of
these
other
sections.
The
rationale
the
backwards
compel
compatibility,
discussion,
implementation
two.
There
is
an
incredible
amount
of
work
done
and
all
of
these
components
before
the
eap
existed.
B
B
Credibility
issues
here,
but
with
kind
of
an
intention
to
have
some
backwards,
incompatibilities
based
upon
this
in
the
future
implementation.
There's
a
lot
of
implementations,
there's
four
or
five
better
near
production
ready,
but
there's
been
a
number
along
the
way.
I
think
there's
maybe
three
that
died
that
had
valiant
lives
but
eventually
were
deprecated
and
there's
a
couple
that
are
up
and
coming.
B
We
this
this
is
not
exhaustive
and
I
should
probably
like
actually
go
through
here
with
the
fine-tooth
comb
and
add
more
things,
but
there's
a
number
of
papers.
There's
these
faqs,
I
mentioned,
there's
a
research
compendium,
so
a
lot
of
it's
kind
of
bundled
into
that.
There's
been
a
number
of
audits.
Actually,
since
I
put
this
up,
there's
been
probably
like
five
more
audits,
released
of
clients
and
implementations.
B
There
is
a
lot
of
formal
verification,
work.
Runtime
verification
has
done
a
lot
of
cool
stuff
here,
both
on
the
deposit
contract
and
on
some
of
the
security
properties
of
the
protocol
and
there's
a
number
of
bug,
bounty
programs
at
which
rewards
are
pretty
high.
I
recommend
I
need
to
update
this
link
because
this
is
released
and
these
two
are
deprecated.
Thank
you.
I'm
glad
to
be
reviewing
this
right
now,
but
the
bug
binding
program
is
live.
That's
at
eat2bounty.theorem.org
and
I
think
critical
vulnerabilities
are
currently
worth
like
fifty
thousand
dollars.
B
So
dig
in
find
some
vulnerabilities,
copyright
and
citation.
I
didn't
write
this,
so
I
presume
that
it
was
auto
generated,
let's
see
so
something
that
I
was
asked
about
before,
and
I
actually
got
the
gears
turning
because
I
realized
that
it's
probably
time
to
update
this
at
the
top.
We
have
this
the
status
I
mean
it's.
A
draft
draft
drafts
can
be
merged
once
they
kind
of
fit
the
minimum
standards.
B
By
a
wider
audience,
we've
kind
of
in
terms
of
the
wider
audience
we,
we
probably
had
some
review
during
the
draft
for
the
wider
audience
and
then
the
final
call
the
final
and
let's
skip.
Some
of
this
is
a
shorter
sequence
than
core
and
some
of
the
other
eips
statuses
erp
types.
But
then,
once
we've
had
last
call
for
two
weeks,
any
technical
changes
have
been
addressed.
B
B
And
then
we
will
call
it
final,
we'll
have
a
the
fifth
informational
eip
ready
and
that
will
be
genesis
of
genesis
of
e2.
This
proof
of
stake
mechanism
that
we're
bootstrapping
is
a
little
bit
dependent
on
getting
a
threshold
of
deposits
in
so
the
earliest
that
can
happen
is
december
1st,
but
so
this
might
be
final
right
about
then,
but
in
terms
of
winning
once
we
hit
that
threshold,
but
that's
yup,
that's
my
presentation.
You
can
follow
me
on
twitter.
Here's
a
link
to
the
eip.
A
Thank
you
that
was
great
presentation
danny,
so
one
of
the
things
that
that
was
there
in
your
last
slide.
I
had
I
have
one
question
about
that:
I'm
not
actually
a
question.
It's
some
change
that
I
would
like
to
highlight
here
yeah
now
about
this
statuses.
There
is
a
another
status
called
review
that
has
been
added
recently.
It's
now
available.
B
B
A
Came
out
of
the
eipip
like
a
process
improvement
group,
we
recently
have
made
two
changes.
One
on
this
part,
which
is
which
is
relevant
for
the
net
informational
eip
or
they
process
and
the
different
statuses
and
the
other
part
which
may
not
be
relevant
for
informational.
But
for
core
eip
is
the
like.
We
separated
the
network
upgrade
process
from
the
eip
standardization,
so
there
is
a
blog
on
cathedral's
medium
about
that
I'll.
Add
the
link
in
the
description
section
for
people
who
would
like
to
follow.
B
Gotcha,
so
I
would
say
that,
probably
two
weeks
ago,
when
we
cut
these
version,
one
releases
we
probably
should
have
moved
to
review
and
then
right
about
now
should
have
moved
it
from
review
to
last
call.
So
I
might
skip
that
one
this
time,
but
I
also
am
realizing
that
eip
eip1011
should
probably
get
moved
to
stagnant
or
is
there
a
oh,
maybe
withdrawn
yeah?
I
should
probably
move
1011,
which
has
been
deprecated
for
multiple
years
now
to
withdraw.
C
D
I
had
a
question:
are
we
ready
now
yeah?
I
I
it's
kind
of
a
governance
question,
but
early
on
you
talked
about,
we
need
to
be
able
to
if
there's
a
nefarious
actor
and
if
it
does
something
nefarious
being
able
to
prove
that
that's
nefarious
and
then
it
sounded
like
you
were
talking
about
some
human
making.
The
decision
to
after
that's
been
proved
to
burn
some
ether
or
something
like
that
is.
B
What
is
nefarious
types
of
attacks,
and
so
in
the
protocol
there
is
the
ability
to
include
these
slashings
what
we
call
slashings
on
chain.
So
a
block
proposer
could
find
something
that
looked
slashable
that
was
slashable
from
another
validator.
It
could
include
it
on
chain
at
which
point,
depending
on
the
severity
of
the
effects
they
might
have
brought
to
the
network.
They
will,
some
amount
of
capital
will
be
burned
and
the
proposer
gets
a
small
finders
fee,
and
so
there's
an.
D
B
A
B
B
C
C
You
know
repo
outside
the
ethereum
specification
and
some
factions
of
the
community
think
that
print
out
all
the
eeps
and
the
yellow
paper
take
it
to
a
remote
island
and
develop.
You
know
a
fully
made
net
compatible
client
and
you
know,
with
phase
zero,
not
really
affecting
how
the
mainnet
happens
today.
B
C
B
Yeah,
so
I
don't
know-
and
I
I
think
that
there's
probably
some
things
to
discuss
and
and
ponder
here
because,
like
I
mentioned,
there's
and
maybe
maybe
I'm
mistaken,
there's
there's
kind
of
some
more
radical
upgrades
that
are
wanted
to
be
handled
in
the
move
to
statelessness,
which
is
kind
of
like
a
major
upgrade
to
more
of
the
execution
and
state
layer
of
ethereum
developed,
an
independent
repo.
But
they
might
be
parsed
out
into
individual
eips.
B
B
But
even
then
it's
very
nice
to
have
a
repo
with
tests
and
an
independent
place
to
like
talk
about
this
component
of
the
ethereum
protocol.
So
I
don't
know
I
mean
I'm
well,
I'm
open
to
suggestions.
I
I
hadn't
pondered
it
very
much
before
this
eip
and
and
pondered
the
relationship
between
the
two,
and
so
you
as
an
editor
might
have
a
process
than
I
do.
C
This
is
like
this
is
an
informational
eep
and
that
basically
means
that
it's
just
trying
to
gain
some
consensus
with
the
community
and
to
share
this
information.
But
this
isn't
necessarily
something
that
you
needed
to
do.
You
guys
could
have
just
shipped
east
2
without
even
working
with
through
the
e-process
at
all,
and
you
could
have
said
here
this
is
it
and
in
a
year
or
two
we're
going
to
take
maintenance
put
it
in
and
at
that
point
we'll
go.
B
For
one
I
mean
operating
in
an
infinite
spec
repo
is
like,
at
least
with
respect
to
how
things
have
been
done,
is
like
kind
of
rogue
and
doesn't
really
fit
into
whatever
the
core
process
of
ethereum
is,
and
so
this
was
like
an
attempt
to
kind
of
bring
it
back.
I
think
again,
operating
as
independent
repo
has
been
very
beneficial,
but
one
reason
is
just
kind
of
like
bring
it.
B
People
are
putting
real
capital
online
to
line
to
bootstrap
this
proof
of
stake
consensus
before
it's
really
unified
with
the
current
theorem
protocol,
and
so
obviously
an
information
informational
eip
is
not.
Is
it's
not
a
promise?
You
know
no
one's
promising
anything
to
anyone,
but
we
do
have
something
that
people
have
reviewed.
People
discussed.
People
have
had
a
chance
to
kind
of
get
their
rebuttal
and
that
when
we
do
attempt
to
unify
these
two
systems,
we
can
kind
of
point
say
like
yes,
we've
been
intending
to
do
it.
B
Yes,
it's
been
part
of
the
conversation,
and
so
that's
that
was
one
of
the
motivations
here
yeah.
So
so
again,
yeah
it's
it.
Maybe
that's
not
the
use
of
the
ips.
Maybe
eips
should
be
used
for
specifications
and
shouldn't
be
used
as
like
signals
and
whereas
you
know
my
explanation,
just
now
was
more
of
like
well.
We
use
it
as
a
signal.
E
E
E
B
Concepts-
and
maybe
it
would
have
been
clearer
for
like
what
we
could
have
done-
is
designed
the
entirety
of
eth2
and
at
the
flip
of
a
switch
gone
from
proof
of
work.
Proof
of
stake
governed
by
this
totally
new
consensus
mechanism,
and
that
would
have
been
a
core.
It
would
have
been
more
clearly
a
core
eip.
B
Still,
you
would
have
had
the
debate
as
to
whether
you
actually
dumped
the
entirety
of
the
spec
in
the
iep
or
not,
but
I
think
it
would
have
been
a
little
bit
more
clear-cut
about
the
relationship
between
the
specs
and
yeah
the
ethereum
protocol.
But
I
also
think
my
opinion
is
that
that
would
not
be
a
smart
thing
to
do.
C
B
Yeah
so
there,
if
I've,
given
a
couple
talks
recently
about
the
terms
eth1
and
the
terms
e2
and
that
it's
useful
to
think
about
them
as
something
separate,
but
it's
not
useful
to
think
about
them
as
something
sequential
in
the
sense
that
if
you
go
back
and
look
at
the
original
roadmap,
you
had
this
thing
called
serenity
and
what
is
serenity.
Serenity
was
upgrading
the
core
consensus
and
what
is
eth2,
it's
an
attempt
to
upgrade
the
core
consensus
and
so
yeah
if
we
would
have
called
it
serenity
from
the
beginning.
B
I
think
it
would
have
been
more
clear.
The
relationship
between
these
things
and
even
now,
I'm
trying
to
find
maybe
to
discuss
the
difference
between
these
things
so
like
we
have
what
we
call
the
e2o
specs
repo,
but
it's
not
really
the
ethos.
Specs
repo,
in
my
opinion,
it's
more
like
the
eth
proof
of
stake,
specs
repo
or
started
proof
of
stake,
specs
repos,
the
it's,
the
eth
future
consensus
repo.
You
know
what
do
we
have
with
most
of
the
eips
so
far,
and
what
do
we
have
with
the
stateless
upgrade?
B
It's
really
upgrades
to
the
execution
and
user
layer
and
application
layer,
and
rather
than
the
you
know,
it's
like
we're
trying
to
figure
out
how
to
come
to
consensus
on
things
better
and
when
you're
working
in
this
other
layer
that
we
usually
call
eth1
people
are
trying
to
come
to
consent
like
what
are
they
coming
to
consensus
on.
You
know
more
interesting,
precompiles,
state
structures
and
and
different
things
like
that,
and
so
each
one
need
two
or
more
of
layers
rather
than
sequentiality.
What
would
I
have
done
differently?
B
C
B
B
A
B
Yeah,
so,
first
of
all,
e2
genesis
may
come
on
december
1st,
depending
on
the
amount
of
deposits
that
go
into
that
deposit
contract.
There's
this
there's
this
deposit
there's
this
genesis
delay
of
seven
days,
and
so
the
threshold
has
to
be
hit
seven
days
before
any
day.
That
genesis
would
be
so
if
we
are
to
have
genesis
on
december
1st.
That
means
that
about
10
of
each
deposits
need
to
make
it
into
this
deposit
contract
by
november
24th.
So
something
to
keep
in
mind.
B
5
00
am
for
this
piermont,
which
is
a
version
one
testnet
of
eth2
page
zero
is,
is
launching
it's
going
to
be
launching
entirely
in
the
control
of
client
developers,
and
then
it
will
be
opened
up
for
the
community
to
make
deposits.
So
if
you
want
to
test
your
final
setups
before
mainnet
check
it
out,
piermont
there'll
probably
be
some
noise
on
twitter
and
stuff.
Tomorrow,
you
can
make
some
deposits.
A
A
For
people
watching
us
on
youtube,
hopefully
today's
episode
answers
some
of
your
questions
related
to
it
too,
and
if
you
still
have
any
questions,
feel
free
to
leave
a
comment
in
the
comment
section
below
you
may
find
the
twitter
handle
of
the
guest
and
rest
of
the
participants
of
this
meeting
in
the
description
section,
along
with
the
resources
that
is
shared
in
the
meeting
today
to
participate
in
x2
discussion
join,
add
to
rnd
server.
Invite
link
is
not
provided
in
this
description
to
avoid
spammers,
but
it
is
available
on
other
public
channels.
A
If
you
like
this
eip
focus
series
share
it
with
other
community
members
and
let
them
know
about
p.
Penny
do
hit
like
share
and
subscribe
to
ethereum
canada's
channel
we'll
be
back
soon
with
another
proposal
till
then
keep
sharing
your
love
with
cat
hoodies.
This
is
your
host
pooja
ranjan.
Thank
you.
Everyone
for
joining
cheers.