►
Description
Topics covered:
--------------------------
1:26 - Introductions
2:50 - Ethereum 2.0 has a long history
4:00 - Ethereum 2.0 through the years
4:40 - Prehistory
5:53 - The Serenity year
7:10 - The Serenity plan - Casper & EIP-1011,Sharding
8:54 - EIP-1011 - Hybrid proof of stake
10:33 - Serenity - Hybrid proof of stake - testnet
10:59 - Scalability in Serenity (Taipei)
11:41 - The Shasper Year
12:30 - Problems 1500 ETH per validator
13:50 - Opportunities - Birth of Beacon chain
15:22 - Berlin 2018
15:35 - Ethereum 2.0 architecture
16:10 - Some of the Ethereum 2.0 innovations
16:34 - Roadmap (3 phases)
17:48 - Different view (Phased delivery)
18:03 - Who is building Ethereum 2.0
19:23 - The Beacon chain launch
20:05 - The Merge year
20:35 - What changed?
21:53 - Roll up centric vision & L2 projects
24:12 - Reflection
26:25 - Vitalik’s roadmap
27:02 - A final word :)
27:41 - Q & A
28:01 - Are there any other currencies doing a similar process for project management or is it unique to Ethereum 2.0?
29:12 - When the merge happens do you see there will be a change in the way things happen?
32:25 - Do you think there is a future for process development?
34:28 - Do we see future upgrades going on simultaneously, or separately like London & Altair?
36:00 - Is there any potential threat for Ethereum 2.0 that is always considered for the beacon chain?
39:40 - Do you think Eth1 & Eth2 are two different approaches to handle the development or is it more like different stages?
41:31 - Do you see separate Eth1 & Eth2 clients or they can also converge?
43:36 - Do you see an Eth3 somewhere?
46:28 - What do you mean by statelessness?
48:41 - Is the increasing state of Ethereum a concern? Or will a Stateless approach tackle that?
51:12 - Archive node does not have much incentive
Resources:
-------------------
Slides: https://docs.google.com/presentation/d/1rG1wW6OwPEncvVWjiJM5Lh3FbUa6MEw8xXk1RVmvqio/edit#slide=id.g2f439b2757_0_0
What’s New in Eth2: https://eth2.news
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Follow at Twitter
-----------------------------------------------
Ben Edgington @benjaminion_xyz | William Schwab @William94029369 | Pooja Ranjan @poojaranjan19
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-herde...
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Welcome
back
to
people,
an
educational
series
dedicated
to
ethereum
improvement
proposals
and
features
of
upcoming
upgrades,
I'm
puja
ranjan,
and
today
we
are
recording
our
40th
episode
on
this
special
occasion.
We
brought
you
a
special
talk
to
learn
about
the
ethereum,
a
brief
history
of
ethereum's
future
to
talk
about
ethereum's
history,
prehistory,
eat,
1.0,
2.0
and
future
ahead.
We
are
joined
by
ben
eddington,
the
product
owner
for
teku,
a
beacon
chain
client
for
those
who
missed
it
earlier
beacon
chain
is
expecting
its
first
network
upgrade
until
very
soon.
A
You
can
learn
about
what
to
expect
with
this
upgrade
the
key
features
and
client
implementation
by
watching
the
recording
of
earlier
episodes.
Similarly,
we
have
got
the
overview
for
london
proposals
for
your
awareness
and,
if
you
are
interested
in
learning
more
check
out
p
penny
playlist
at
ethereum
categories
youtube.
A
B
B
So
I
got
involved
with
ethereum
something
over
five
years
ago.
It
was
proof
of
stake
which
really
grabbed
me
and
got
my
attention,
and
then
I
just
went
down
the
rabbit
hole
and
I
joined
consensus.
Almost
four
years
ago
I
worked
in
r
d
for
a
while,
and
now
I
am
product
owner
of
teku,
which
is
our
beacon
chain
client,
as
you
said
so
one
way
or
another
I've
been
involved
in
the
proof
of
stake
and
scalability
conversations
for
about
three
years
or
so,
and
we'll
see
a
bit
of
that.
B
As
I
go
through
the
presentation,
I
should
give
a
couple
of
sort
of
caveats.
I
wasn't
there
for
everything.
This
is
very
much
a
personal
view,
partially
reconstructed
from
sort
of
things
that
were
around
at
the
time
and
written
others
who
were
around
may
have
different
recollections
or
emphasize
things
differently.
But
this
is
one
of
my
favorite
topics.
Is
looking
back
at
how
ethereum
evolves
and
changes
and
where,
where
we're
going
and
how
we
got
here,
so
let's
take
a
look
at
a
brief
history
of
ethereum's
future.
B
So
first
thing
to
say
is
ethereum
2
has
a
long
history.
It
wasn't
invented
as
a
terminology
recently,
but
goes
back.
All
the
way
to
2014
is
the
first
mention
I've
been
able
to
find
of
it
so
vitalik
in
this
post
on
hacker
news.
You
can
see
the
bit
I
emphasize
this
is
april.
2014
anticipated
releasing
ethereum
two.
This
was
before
the
release
of
ethereum
one
I
mean
a
year
before
the
ethereum
chain
got
going.
B
B
B
So
this
is
the
kind
of
journey
I
want
to
go
on
through
this
little
presentation.
Hopefully,
won't
go
on
too
long.
Give
me
a
wave
if
I'm
rambling
and
we'll
we'll
tighten
it
up,
but
I
I
kind
of
see
the
history
as
like
four
stages
as
a
pre-history.
What
happened
before
the
ethereum
chain
was
launched
in
2015,
then
there's
what
I
call
the
serenity
years,
then
what
I've
called
the
shasta
years
and
now
we're
in
the
merge
years,
and
these
represent
different
sort
of
phases
or
directions
of
development
over
time.
B
So
we'll
start
with
a
sort
of
pre-history.
This
is
pretty
short
just
one
slide
on
this
and
it's
to
say
that
the
developers
of
ethereum
were
aware
from
the
very
earliest
days
that
the
blockchain
would
face
two
big
challenges,
one
of
which
is
scalability
and
the
other
is
sustainability
that
you
know.
Proof
of
work
is
not
long-term,
sustainable
and
so
from
the
ethereum
foundation.
Blog
here
are
two
articles.
From
back
in
the
day,
gav
wood
on
the
left
described
chain
fibers,
which
is
a
scalability
mechanism.
B
He
says
I
actually
came
up
with
it
in
early
2014
and
a
very
similar
time.
Vitalik
was
posting
on
slasher,
which
is
such
a
great
name,
and
I'm
I'm
sad.
We
don't
use
that
anymore,
though
we
do
still
talk
about
slashings,
that's
pretty
good,
which
is
a
proof-of-stake
algorithm,
even
before
ethereum
was
launched.
If
you
want
to
dive
deeper
into
the
development
of
the
proof
of
stake
as
a
protocol,
I
really
recommend
vlad
zamfir's
history
of
casper,
which
I've
linked
to,
and
I
think
the
slides
will
be
available.
B
So
you
can
follow
the
links
in
your
own
time.
So
that's
the
kind
of
prehistory.
These
things
are
on
the
agenda
from
day
one
scalability
sustainability.
So
how
did
that
pan
out?
Let's
look
at
the
serenity
years,
and
I've
really
dated
these.
You
know
july
2015,
the
launch
of
ethereum
through
june
2018
and
you'll,
see
in
a
moment
why
I've
chosen
that
date.
B
So
this
is
at
the
top.
This
is
a
blog
post
by
vinay
gupta,
again
on
the
ethereum
foundation,
blog
2015
march,
and
he
talks
about
the
release
stages
of
ethereum.
The
upgrade
path
as
as
the
ethereum
foundation
saw
it
at
the
time.
So
it's
going
to
go
through
four
stages:
frontier
the
initial
release.
Homestead
metropolis
and
then
serenity
and
serenity
was
where
proof
of
stake
would
be
delivered
and
proof
of
work
would
be
turned
off
again.
We
see
that
optimism,
which
I
love
so
much
about
the
ethereum
community.
B
B
So
what
does
this
serenity
plan
looked
like
and
there
were
two
really
independent
parts
to
it.
On
the
one
hand,
you've
got
the
proof
of
stake
side
which
is
casper,
that's
what
the
mechanism
was
called,
and
this
led
to
something
quite
concrete,
which
was
eip,
1011
1011,
which
we'll
look
at
in
a
moment
and
that
that
activity
was
happening
on
the
proof
of
stake
side
and
on
the
scalability
side.
There's
this
concept
of
sharding
that
had
emerged
out
of
the
chain.
B
But
the
the
critical
thing
here
the
to
understand
is
that
the
goal
was
to
implement
both
of
these.
Both
the
proof
of
stake
protocol
and
the
scalability
protocol
on
top
of
the
existing
ethereum
chain,
so
managed
by
ethereum
ethereum
is
turing
complete
it
can
in
principle
it
can
do
anything.
So
why
not?
You
know
run
its
own
proof-of-stake
mechanism
and
run
its
own
sharding
mechanism,
so
there
were
supposed
to
be
manager,
contracts,
one
for
proof
of
stake
and
one
for
sharding
sitting
on
the
ethereum
chain,
managing
all
the
validators
and
the
protocol
going
on.
B
Serenity
this
this
is
the
only
eip
I'm
going
to
talk
about
in
this
peep
and
eat,
so
you
do
get
to
look
at
one,
unfortunately,
an
abandoned
one,
but
there
we
go.
This
is
eip1011
authored
by
danny
ryan
and
chang
liang
back
in
2018
april,
and
this
was
the
proposal
to
build
a
hybrid
proof-of-stake
proof-of-work
mechanism
as
a
first
step
towards
going
to
full
proof
of
stake.
B
B
So
this
was
a
sort
of
interesting,
hybrid
approach
and
the
idea
being
that,
with
the
security
of
proof
of
stake,
you
could
crank
down
the
the
rewards
for
proof
of
work,
reduce
the
rewards
and
thus
reduce
the
hash
rate.
And
overall,
you
get
a
net
benefit
in
that
I'm
not
going
to
say
a
whole
lot
about
this,
the
erp
still
there.
If
you
want
to
look
at
it,
I've
just
picked
out
one
aspect
at
the
bottom,
which
is
we'll
come
back
to
in
a
moment
which
is
the
stake
size.
B
So
currently
it's
32
ether
on
the
beacon
chain.
The
stake
size
in
this
model
is
1
500
ether
per
validator.
So
we'll
come
back
to
that
in
a
moment,
but
this
actually
made
quite
a
lot
of
progress.
I
mean
1011
got
prototyped
had
a
test
net
december
31st
2017,
the
test
net
was
running
and
you
know
there's
an
explorer
there
and
and
so
on.
You
can
look
at
the
history
there.
B
B
Really
the
first
sort
of
kickoff
for
this
was
this
workshop
we
had
in
taipei.
So
here
are
the
attendees.
You
can
see
some
of
the
usual
suspects
there.
I'm
there
in
the
front
row
managed
to
position
myself
nicely
for
that
one.
We
got
raul
and
preston
from
prism
on
the
right
in
the
front.
You've
got
yadzig
from
nimbus
at
the
back
on
the
right
and
various
other
characters
from
the
history
of
ethereum.
B
You
know,
capture
the
essence
of
the
idea
at
the
time,
so
I've
dated
this
from
july
2018
and
that's
because
we
met
in
berlin
and
we
pretty
much
tore
up
everything
that
went
before
we
started
a
brand
new
plan
with.
Basically
you
know
blank
flip
chart
and
designing
a
whole
new
protocol.
Why
did
we
do
this?
What
was
the
problem?
Well,
I
mean
number
one.
Fifteen
hundred
eighth
to
stake
for
a
validator
was
not
attractive.
I
mean
imagine
paying
three
million
dollars
worth
of
ether
to
be
a
staker.
B
Now
I
mean
it's
bad
enough.
As
it
is,
but
there
were
other
sort
of
more
subtle
issues
like
you
know,
you
had
one
management
contract
for
proof
of
stake,
validators
and
one
for
sharding
validators,
and
they
were
separate
pools
of
validators
with
their
own
separate
stakes,
and
you
know
the
dynamics
weren't
clear
between
them,
whether
people
would
dominate
in
in
one
pool
or
another
and
they
would
leech
off
each
other
or
not,
and
it's
kind
of
inefficient
having
these
separating
the
validator
pool.
B
The
other
thing
was
that
it
was
realized
that
that
far
from
being
able
to
run
this
through
regular
smart
contracts
on
ethereum,
there
would
actually
need
to
be
protocol
changes
made
to
sort
of
prioritize
the
transactions
on
the
network,
dealing
with
proof
of
stake
or
sharding,
and
if
you're
going
to
change
the
protocol
anyway,
you
might
as
well.
You
know
go
large
on
it
rather
than
fiddling
with
it.
Danny
did
a
great
write-up
of
the
the
rationale
for
this
abandoning
the
sort
of
previous
path,
which
is
is
linked
there
and
the
opportu.
B
There
were
opportunities
with
building
a
sort
of
new
chain,
starting
with
a
blank
sheet
of
paper.
We
we
realized
that
if
we
built
a
beacon
chain
from
scratch
this
this
was
an
opportunity.
This
is
inspired
by
dfinity's,
random
beacon
at
the
time
threshold
relay
beacon,
which
was
really
interesting
idea
and
it
sort
of
sparked
a
conversation
about
new
cryptographic
primitives
like
aggregate
signatures.
B
We
could
combine
validator
sets
for
proof
of
stake
and
sharding
we're
doing
the
management
in
protocol
rather
than
in
contracts.
That
makes
that's
much
more
efficient,
so
we
can
have
a
much
lower
stake
and
have
many
more
validators.
You
know
thousands
of
times
more
validators
participating
in
the
protocol
and
yeah.
B
We
came
up
with
this
shasta
thing,
which
is
a
separate
side
chain
running
alongside
ethereum,
with
a
view
to
overtaking
ethereum
at
some
stage
this
is
charway's
famous
iconic
diagram,
which
has
you
know,
served
us
well
over
the
years
and
the
the
sort
of
architecture
is
at
the
top.
You've
got
the
current
proof
of
work
chain.
Then
we
build
a
beacon
chain
and
we
add
shards
to
it.
This
is
1024.
B
B
This
is
a
sort
of
chart
I
made
at
the
time
of
some
of
the
new
ideas
that
were
around
that
were
being
thought
of
importing
into
the
the
new
chain,
the
beacon
chain,
and
some
of
them
have
come
to
me
and
some
some
haven't.
But
you
know
it,
the
idea
was
we
could
do
all
sorts
of
experiment
with
all
sorts
of
things
and
we
had
a
sort
of
road
map
to
to
delivering
this.
B
So
the
plan
was
three
phases:
very
familiar
phase:
zero
phase,
one
phase,
two
phase:
zero
is
built,
this
beacon
chain,
which
is
a
standalone
proof
of
stake
chain
which
kind
of
hooks
loosely
into
the
proof
of
work
chain
at
the
top
just
to
onboard
new
validators,
but
otherwise
just
sort
of
runs
itself
and
doesn't
doesn't
do
anything.
Then,
in
a
later
stage
we
add
data
shards,
which
are
just
manage
blobs
of
data
and
then
in
phase
two.
B
Eventually,
we
put
some
execution
layer
on
top
of
this,
which
is
very
flexible
with
cross
shard
communication
and
all
of
that
and
then
finally,
we
import
the
state
of
the
current
proof
of
work
chain
into
one
of
these
execution
environments
or
we
just
like
deprecate
the
proof
of
work
chain
and
encourage
everybody
to
migrate
over.
That
was
a
bit
unclear
through
that.
So
that
was
the
master
plan.
B
Three
very
nice
phases
that
build
on
each
other
to
deliver
this,
this
impressive
architecture
and
we
turn
off
the
proof
of
work
at
the
top
different
view
of
the
same
thing.
You
know
we
have
this
linear
phase,
zero
phase,
one
phase
two
and
then
eventually,
we
transfer
across
the
ethereum
proof
of
work
chain,
stuff
and
shut
off
proof
of
work
and
yeah.
That
was
a
great
vision
and
a
bunch
of
us
kind
of
got
going
on
this.
B
I
I
made
this
slide
in
2018
back
in
november
then,
and
it's
interesting
what's
changed
and
actually
not
so
much
so
these
are
the
teams
that
kind
of
got
involved
at
the
time,
mostly
still
involved,
so
some
changes,
the
ethereum
foundation,
sort
of
abandoned
their
own
in-house
python.
Client.
Just
wasn't
performant
enough
and
focused
on.
You
know
developing
the
specs
and
the
testing
and
and
so
forth.
There
parity
dropped
out
fairly
early
on,
but
otherwise
we're
all
still
involved,
one
one
way
or
another.
B
B
B
I
kind
of
dated
it
2021
I
mean
it's,
you
know,
there's
no
single
date
where
we
change
plans,
it
just
sort
of
has
evolved
over
the
past
few
months,
yeah
what
happened
well
pressures,
I
think,
pressures
and
opportunities,
so
one
of
which
was
an
increasing
urgency
around
delivering
proof
of
stake.
So
the
day
I
first
presented
this
slide.
Elon
musk
had
just
tweeted
his
thing
about
bitcoin
and
the
environment,
but
I've
left
it
in
there.
B
There's
this
whole
thing
about
miners
power
and
the
kind
of
fighting
about
eip
1559
and
all
of
that
kind
of
turned
people
against
the
the
proof
of
work.
Mining.
Community
we've
got
the
whole
environmental
optics.
You
know
my
my
daughter
gives
me
a
hard
time
about
nfts
and
you
know
tell
her
I'm
you
know
I
want
to
kill
proof
of
work.
You
know
you
should
support
me
we're
moving
away
from
all
that
so
she's
happy
now
and,
of
course,
we're
paying
too
much
for
our
security.
I
mean
you
know.
B
Two
weeks
per
block
is
more
than
we
need
to
be
paying
for
the
security
that
we
get
and,
on
the
other
hand,
we've
got
this
new
opportunities
and
there
are
always
new
technologies
emerging
and
that's
the
exciting
thing
about
ethereum.
We
spot
new
technologies
and
we
adopt
them
and
absorb
them,
and
it's
it's
flexible
enough
to
do
so.
B
Layer,
two,
we
call
it
so
things
like
managing
the
parallel
state
and
managing
parallel
execution
can
be
done
outside
the
protocol,
and
we
have
this
nice
roll
up
thing,
which
we
understand
the
properties
of
the
security,
and
that
simplifies
what
you
need
to
do
in
protocol.
You
don't
need
to
have
executable
shards
anymore.
You
can
just
provide
data
shards
and
that
plays
very
nicely
with
with
rollups,
so
that
that
sort
of
took
away
an
emphasis
from
delivering
these
execution
environments
and
then
mikhail.
B
My
colleague
in
consensus,
kind
of
put
the
the
nail
in
the
coffin
with
his
executable
beacon
chain
proposal,
which
just
provided
a
road
map
to
very
quickly
getting
to
proof
of
stake.
So,
rather
than
waiting
until
we
developed
phase
zero
phase,
one
phase
two
and
then
do
some
kind
of
transfer
to
proof
of
stake,
turn
off
proof
of
work.
We
could
do
actually
do
it
very
quickly
and
then
do
the
other
things
later.
B
You
know
do
sharding
after
proof
of
stake,
so
those
two
things
came
along
and
really
evolved
the
road
map.
Here
it
is
sort
of
pictured.
So
instead
of
this
proof
of
work
going
along
in
parallel
right
to
the
end
and
then
coming
in,
we
do
this
merge
quickly.
We
have
the
proof
of
stake
chain
which
is
the
beacon
chain.
We
bring
the
proof
of
work,
we
kind
of
unite
them
in
this
merge
we
add
sharding
and
then
we
just
have
ethereum
scalable
sustainable
with
with
rollups
that
different
view.
B
B
So
that's
it.
We've
done
the
pre-history.
We've
done
the
serenity
years,
we've
done
the
shasta
years
and
the
merge
years.
If
I've
got
a
couple
of
moments
left,
then
I
just
I
have
some
sort
of
reflections
and
thoughts
about
how
this
process
has
gone,
because
it
can
seem
a
bit
bewildering.
Honestly,
I
think,
to
people
who
try
to
follow
this
space
and
in
my
old
life
I
used
to
make
technology
road
maps.
You
know
customers
would
demand
a
three-year
road
map.
B
You
know
one
year
committed
three
years
indicative
and
all
this,
and
this
sort
of
flexibility
was
not
available,
so
I
I
kind
of
liken
it
to
the
the
linux
robot.
This
goes
along
back
a
long
way.
I
don't
know
if
linux
still
behaves
like
this,
but
the
linux
famously
never
had
a
roadmap
and
sort
of
evolved
in
a
very
similar
way
to
the
way
that
ethereum
is
evolving.
So
there's
some
nice,
nice
stuff
there.
B
I
wrote
a
little
while
back
about
the
the
bizarre
development
model.
So
this
is
the
there's:
a
famous
open
source
essay
by
eric
raymond
about
called
the
cathedral
and
the
bizarre
contrasting
closed
source
cathedral
models,
which
are
very
well
ordered
and
hidden
from
public
view,
and
you
get
handed
down
the
fruit
of
the
the
work.
Much
like
say:
dfinity
is
now
you
know
they
went
away
for
three
years.
B
Nobody
had
closed
source,
nobody
had
any
idea
what
they're
doing
they
just
handed
down
from
the
cathedral,
their
fully
finished
product
instead,
ethereum's
development
is,
like
you
know,
crazy
bizarre
with
everyone
shouting
at
each
other
and
kind
of
bringing
order
from
chaos.
And
you
know
this
is
where
the
cat
heard
us
really
have
their
work
cut
out.
B
But
the
idea
is
that
it's
a
marketplace
of
ideas
and
it's
open.
Anyone
can
come
and
participate.
Everything
is
visible
and
it's
much
more
kind
of
flexible
and
organic.
So,
but
the
result
is
you
don't
end
up
with
a
nice
well-ordered
road
map.
Right
I
mean
it
is
creative
and
it
evolves
over
time.
It's
not
set
in
stone
with
dates
and
deliverables.
B
I
like
the
way
vitalik
thinks
this
is
much
more.
My
kind
of
road
map-
this
is
his
sort
of
post,
is
a
while
back
now,
it's
a
little
bit
old
now,
but
you
know
proper
road
maps,
look
like
they're
messy
and
complex
and
aspirational
and
there's
not
a
date
to
be
seen
on
on
on
it
which,
which
I
like,
and
I
this
is
ethereum.
It
emerges
from
this
sea
of
ideas.
B
A
C
C
B
B
So
it's
kind
of
kind
of
hard
to
answer
from
where
I
sit,
but
it
has
been
a
defining
characteristic
of
ethereum
that
it
is
very
open
to
anybody
coming
and
you
know
you
just
have
to
come
and
do
something
useful
and
immediately
you're
accepted,
and
I
that
that
all
that
almost
seems
unique
I
mean
I
I
can't
say
for
sure,
but
it's
you
know
we
we're
very,
very
committed
to
that.
It's
not
like
a
aspiration.
It's
reality.
I
mean
it's
what
we
do
and
we
fight
for
that
openness.
C
Do
you
see
that
there
will
be
a
change
in
the
way
that
things
are
handled
throughout
ethereum?
I
know
that
the
way
that,
for
example,
the
all
core
dev
meetings
happen
right
now
versus
the
east,
two
meetings,
there's
a
distinct
difference
and
I'm
wondering
if
you
think
that
that
you'll
sort
of
be
merging
those
methodologies
as
well.
B
Yeah
yeah,
that's
brilliant!
I
think
about
this
a
lot
so
ethereum
has
its
own
governance
process
and
it
can
seem
very,
very
slow,
as
you
well
know,
and
you
know
I
often
cite
things
like
it
took
three
years
to
get
bit
shifting
into
the
evm
and
even
eip1559
is
well
over
two
years
old
and
it
can
seem
very
ponderous.
B
Whereas
on
the
e2
side,
we've
moved
extremely
fast,
fast
and
loose
we've,
you
know
had
very
informal
governance,
basically
yeah
we
just
kind
of
get
on
with
it
and
make
changes
and
so
forth.
Now
we've
had
a
luxury,
though
we
haven't
been
managing.
You
know:
300
billion
dollars
worth
of
value
on
our
chain,
whereas
you
know
the
ethereum
proof
of
work
chain.
B
Technically,
we
could
do
the
merge.
You
know
really
quickly.
I
mean
we
could
probably
do
it
in
a
few
weeks.
The
the
blocker
is
the
governance
process
between
now
and
delivery,
and
rightly
so,
because
we
have
a
whole
community
of
stakeholders.
You
know
people
have
invested
in
different
ways
in
ethereum
who
have
to
be
certain
that
this
is
going
to
be
safe
and
is
not
going
to
break
their
thing
and
lose
the
money
and
you
know
cause
problems
for
for
them.
So
we
have
this.
B
I
don't
know
how
long
it's
going
to
take.
I
hope
it
doesn't
take
more
than
six
to
nine
months,
but
it's
mostly
around
the
governance
and
the
testing
and
the
proving
that
this
is
going
to
work
from
now
on
and
I
think
for
a
lot
of
the
devs
on
the
e2
side.
That's
going
to
come
as
a
shock
honestly
how
slowly
things
are
going
to
move
from
now
on.
C
Do
you
think
that
there's
like
a
future
for
that
process
developing
into
something
more
scalable
to
an
extent,
because
I
mean
you
know,
I
think
a
big
part
of
the
problem
is
just
it's.
The
all
core
dev
call
right
and
that's
like
the
only
place
that
it
happens,
but
I
don't
know
if,
like
there's
any
talk
about
that
in
the
e2
side,
on
how
to
like
speed
up
the
process
or
even
just
like-
and
this
is
my
last
question
with
regards
to
government
governance
from
me.
B
I
think
it
would
be
we
would
be
out
of
order
coming
to
the
ethereum
all
core
devs
and
and
telling
them
how
to
run
things.
I
you
know,
I
think,
there's
a
lot
of
respect
for
that
work
and
whilst
we
may
have
some
sort
of
frustrations
with
the
pace
of
the
pro
process
and
no
doubt
there
are
ways
in
which
it
could
be
accelerated,
you
know
generally
things
get
done
and
it
would
be
impertinent
for
us
to
kind
of
just
come
in
and
say:
okay
guys,
you're
doing
it
all
wrong.
B
We've
got
much
better
idea,
so
I
don't
think
we're
going
to
do
that.
You
know
tim
is
kind
of
settling
into
the
role
as
chair
of
all
core
devs.
I
know
him
very
well.
We
were
colleagues
for
some
time
in
in
consensus
and
you
know
I'm
I
trust
his
instincts
and
that
he
will
work
to
make
the
the
processes
efficient
and
safe
as
possible.
A
For
what
it's
worth
like,
there
are
a
lot
of
process
that
we
are
trying
to
learn
from
the
e2
of
one
of
those,
of
course,
is
the
eip
process
that
you
mentioned,
if
not
directly,
for
the
core
proposals,
we
are
considering
at
least
for
networking
layers
and
other
proposals.
So
it's
a
good
learning
the
way
we
both
chains
are
interacting
and
moving
ahead.
B
Interesting,
we
are
keeping
the
consensus
layer
and
the
execution
layer
quite
separate,
so
you
know
the
the
way
the
merge
works
is
this
existing
consensus,
clients,
the
youth,
two
clients
and
the
existing
execution
clients.
Eth1
clients
basically
are
only
minimally
changed,
so
you
run
teku
and
geth,
or
something
like
that
and
connect
them
together.
So
the
protocols
are
quite
independent
of
each
other
and
in
principle,
can
be
dealt
with
separately
or
with
loose
coordination
between
the
layers.
B
Now
there
are
some
things
where
we
have
to
coordinate
and
that
will
affect
both
layers,
but
it
it
could
be
that
yeah
we've
got
a
lot
of
work
to
do
still
on
the
consensus
layer.
The
whole
sharding
piece
needs
to
be
done,
nevermind,
withdrawals
and
and
so
forth.
So
we
may
wish
to
have
a
faster
cadence
of
forks
and
development
on
the
consensus
side
than
on
the
execution.
Side
has
traditionally
done.
That's
speculation
on
my
part,
but
I
I
could
see
that
as
a
as
a
possible
outcome.
A
Interesting
yeah,
we
see
that
with
this
merge
and
both
the
chains,
there
are
going
to
be
a
lot
of
changes.
One
of
the
changes
that
we
are
actually
seeing
right
now
is
the
importance
of
validators
for
ethereum
1.0,
one
of
the
key
stakeholders
and
miners.
Similarly,
we
have
validators
and
I
believe
there
that
they
are
playing
major
rule.
B
Centralization
is
always
a
problem
for
control
of
the
network
and
so
on.
So
it's
always
something
that
we're
trying
to
design
the
protocol
around
not
to
have
too
many
centralizing
pressures.
So
you
know
just
mining
power
is
concentrated
in
a
few
pools
and
in
principle
they
can
cause
trouble
for
the
network.
So
and
it's
the
same
if
two
too
few
entities
control
the
majority
of
validators
on
eth2
and
it's
really
hard
to
design
around,
so
the
goal
is
to
make
it
as
easy
or
as
to
disadvantage
as
little
as
possible.
B
Those
who
wish
to
stake
individually
so
that
there
is
a
minimal
disadvantage
to
people
who
you
know
to
entities
like
exchanges
who
are
running
huge,
validator
pools.
Now,
I'm
not
sure
that
we're
really
fully
succeeding
at
this.
There
are
definitely
centralizing
pressures.
There
are
things
like
you
know.
B
B
Whereas
you
know
the
individual,
like
me,
is
going
to
have
struggle
going
to
struggle
to
extract
as
much
value
puts
me
at
a
disadvantage
and
is
a
pressure
to
join
the
big
pools
so
again
we're
looking
at
ways
to
sort
of
minimize
the
unfairness
level
the
playing
field
as
much
as
we
can,
but
that's
a
kind
of
threat.
I
mean,
if
to
sort
of
answer
your
question
sort
of
more
directly.
Those
are
the
kind
of
threats
that
I
worry
about
is
the
centralizing
things.
B
D
Okay,
cool
and
there's
been
so
many
different
topics
here,
it's
like
hard
to
know
exactly
exactly
where
to
zoom
in
maybe
one
thing
that
I'll
kind
of
rehash
that
was
talked
about
before
some
differences
that
we've
seen
in
the
eth
one
visibility
ii
space.
One
comment
that
I've
heard
is
the
difference
in
structure
even
between
oh
started.
With
that
background
noise,
about
the
difference
in
the
structure
between,
say
the
all
core
depths
meeting,
the
ethereum
two
meetings.
I
was
struck
by
what
you
said
before.
D
Do
you
think
that
that
is
actually
two
different
approaches
to
handling
the
development?
Or
is
it
more
like
you're
saying
that
we're
actually
looking
at
things
that
are
in
two
different
stages
of
existence
that
all
core
devs
are
like
their
their
job
is
working
on
a
protocol
that
has
been
defined
and
is
currently
working
and
is
currently
holding
value
versus
the
ethereum
two
movement
until
now,
which
at
least
until
the
beacon
chain
was
still
in
the
theoretical
and
working
towards
closing
on
a
spec.
B
Yeah
exactly,
I
think,
we're
at
different
stages,
so
we
can
proceed
in
a
less
cautious
way
in
the
on
the
proof
of
stake
side
of
things
and
we've
been
able
to
run
more
experiments
and
not
be
so
concerned
about
breaking
things.
So
it's
a
maturity
question
and
inevitably,
as
the
the
value
of
what
we
are
guarding
grows,
then
you
know
our
processes
will
have
to
mature.
B
Along
with
that
yeah,
and
there
are
probably
different
approaches
that
could
be
taken
to
to
governance.
It
doesn't
necessarily
have
to
look
like
all
core
devs
does
today,
but
it
will
inevitably
be
more
cautious,
I
think,
is
the
good
word
for
this
than
than
we
have
had
to
be
so
far
in
developing
the
you
know,
the
beacon
chain
side
of
things
very
interesting.
D
And
I
I
guess
kind
of
on
that
note
about
kind
of
the
confluence
of
ethereum
youth
too
you
we've
talked
to
you've
talked
about
how
the
eth1
and
ether
the
the
ethereum
one
clients
and
ethereum
two
clients
are
largely
dealing
with
verticals
they're
independent
to
each
other.
Do
you
think
that
we're
going
to
continue
to
see
separate
with
like
one
and
e3
clients,
or
do
you
feel
like
that's
something
that's
going
to
converge?
B
It's
something
we're
looking
at
in
in
consensus,
because
we
have
in-house
eth
one
client,
baesu
and
eth2
clienteku
and
we're
sort
of
exploring
whether
there
is
some
advantage
to
more
tightly
coupling
them.
Teku
will
work
with
any.
You
know,
eat
one
any
execution,
client,
that's
our
kind
of
commitment.
So
you
could,
you
know
couple
teku
with
with
geth
on
their
mind
or
aragon
or
or
whatever,
but
there
may
be
some
advantage
and
in
particular,
for
our
target
user
with
teku
is
the
institutional
staker.
B
So
who
is
running
a
large
staking
operation,
and
it
may
be
that
they
wish
to
kind
of
single
source
their
infrastructure?
So
they
don't
want
to
have
to
deal
with
problems
that
that
occur
in
geth
have
to
be
reported
to
one
place
and
problems
that
occur
in
tecu
have
to
be
reported
to
another
place,
and
everyone
starts
finger
pointing
it's
much.
B
It
may
be
that
we
package
teku
and
baesu
in
such
a
way
that
it's
you
know
he
looks
like
a
unified
client
and
then
our
users,
then
just
have
the
one
entity
to
deal
with.
So
we're
sort
of
thinking
about
that
so
that
there
are
packaging
issues
and
they're
sort
of
do.
How
do
we
tightly
couple
them?
It's
not
clear
to
me
that,
yet
that
there
are
strong
advantages
to
tightly
coupling
the
execution
and
consensus
side
of
things,
but
that
may
change
as
as
time
goes
on,
so
we're
having
those
conversations
now.
D
Interesting-
and
I
guess
kind
of
as
one
last
question-
and
one
of
the
really
interesting
things
that
you've
pointed
out
is
that
there
was
an
eye
on
the
scaling
issues
and
the
consensus
algorithm
issues
already
from
the
earliest
days.
Do
you
see
an
e3
somewhere
I
mean
probably
eventually
there
will
be
problems
that
show
themselves.
We
probably
will
eventually
need
to
move
forward
from
something
I
doubt
anyone's
willing
to
claim
that
this
is
like
the
algorithm
that
shall
last
a
thousand
years
or
something
like
that.
B
In
europe,
I
think
vitalik
might
even
have
used
the
words
ethereum
three,
I
think
during
the
scaling,
ethereum
hackathon
presentation,
it
might
have
been
he
he
mentioned
ethereum
three.
There
are
things
we
will
have
to
do
if
we
think
quantum
computing
is
going
to
break
our
algorithms.
Currently,
the
cryptography
we're
using
is
vulnerable
to
assumed
quantum
computers
which,
depending
on
who
you
talk
to
or
a
decade
or
three
decades
away,
so
in
that
time
we
will
need
to
move
to
some
sort
of
post-quantum
cryptography.
B
This
probably
means
starks,
which
are
a
kind
of
zero
knowledge
proof,
speaking
of
which
there
are
very
cool
things.
You
can
do
with
zero
knowledge
proofs,
which
will
you
it
can
potentially
help
the
protocol
a
great
deal
so
yeah
that
might
be
an
ethereum
three
side
of
things.
As
justin
drake's,
famous
vdf
verifiable
delay
function
to
introduce
strong
randomness,
not
planned
for
on
the
current
sort
of
roadmap,
but
maybe
come
in
later,
there's
casper
cbc,
which
is
vlad
zamfir's
original
sort
of
casper
consensus
mechanism.
B
Our
consensus
mechanism
today
is
kind
of
a
nasty
frankenstein
bolting,
together
of
casper
ffg
and
and
lmd
ghost
they're,
two
different
consensus
mechanisms
sort
of
bolted
together
and
that
causes
a
bit
of
a
discontinuity.
You
can
definitely
see
the
joints,
whereas
casper
cbc
is
much
purer
and
there
may
be
ways
to
adopt
that
so
yeah
there's
just
this
whole
sort
of
ocean
of
ideas
and
then
there's
a
whole
statelessness
discussion
around
ethereum.
I
don't
know
if
we
bucket
that
in
with
eth2
or
or
what
we
call
it.
C
B
Yeah,
so
at
the
moment,
if
I
run
an
ethereum
node,
I
have
to
store
locally.
Basically,
the
whole
state,
which
is
everybody's
account,
balances
all
the
contracts,
all
the
contract
data.
This
is
quite
a
lot
of
data.
I
forget
how
big
it
is,
but
it's
order.
You
know
100
gigabytes,
plus
this
is
slow
to
access.
It
slows
down
nodes
because
they
have
to
every
time
they
interact
with
this
state.
They
have
to
do
many
disk
operations
and
it
grows
unboundedly
it.
Never
it
never
shrinks.
It
just
grows
and
grows.
B
So
it's
a
problem
forever.
It's
basically
you
pay
once
to
put
data
onto
the
blockchain
and
it's
there
forever
and
that
model's
not
sustainable.
There
are
various
ways
which
might
be
this
problem
might
be
worked
around.
The
current
leading
candidate
is
something
called
state
expiry,
which
means
that
we
store
maybe
a
couple
of
years
worth
of
state,
and
then
older
state
gets
deleted
locally,
but
you
can
always
recreate
it.
You,
you
store
enough
stubs
of
data
locally
that
you
can
rebuild.
B
If
you
need
to
access
it,
you
can
ask
the
network,
you
know
infurer
or
somewhere
for
the
data
that
you
need
and,
and
you
can
prove
that
it's
correct-
you
don't
need
to
store
it
locally.
There
are
more
radical
versions
of
this
which
are
fully
stateless
and
you
know
there
are
protocols.
I
think
the
mina
protocol,
which
used
to
be
called
coda,
is
completely
stateless.
They
have
a
very,
very
cool
sort
of
operating
model,
but
yeah.
B
There
are
things
out
there,
but
the
leading
candidate
seems
to
be
the
state
expiry
thing
and
it's
just
reducing
the
burden
on
nodes
so
that
we
can
re.
We
can
allow
as
many
people
as
possible
to
run
nodes.
You
don't
have
to
have
big
iron.
You
know
a
server
farm
to
run
a
ethereum
node
you
can.
You
can
run
it
on
on
consumer
equipment.
C
B
B
B
So
these
are
clients
that
can
go
to
the
network
and
they
can
ask
fire
gossip
protocols
for
certain
pieces
of
data
and
they
get
that
data
back
from
other
nodes
and
they
can
prove
that
it's
correct.
They
know
they've
got
the
right
data
because
it
matches
the
information
that
they
they
already
have.
So
that
and
ethereum
two
has
been
designed
to
be
light,
client
friendly.
B
B
That
means
that,
as
long
as
somebody
somewhere
stores
the
history
and
the
state,
I
don't
need
to
know
it
to
do
what
I
need
to
do.
I
can
just
ask
the
network
for
the
bits
and
pieces
that
I
need
how
we
incentivize
that
has
still
kind
of
got
to
be
worked
out,
but
you
know
there
might
be
micro
payments
for
providing
bits
of
state
and
so
forth,
and
you
don't
need
to
trust
anyone,
because
you
can
prove
that
you've
got
the
right
piece
of
information.
B
C
B
Yeah
so
archive
knows
sort
of
have
the
full
history
and
the
full
history
of
the
states
as
well,
which
is
kind
of
useful
if
you're
running
a
block
explorer,
but
not
not
for
much
else
and
in
ethereum.
Currently,
there's
no
incentive
to
to
do
that
unless
you
need
it
to,
you
know,
run
some
other
app
or
other.
Something
like
that.
A
A
No
all
good.
Thank
you
very
much
ben
all
right.
Thank
you!
So
much
ben
for
taking
out
time
and,
like
you
know,
talking
to
us
about
all
these
interesting
events
and
history
of
ethereum,
and
obviously
we
see
merge
coming
closer
with
this
london
is
expected.
I
believe
in
three
weeks
and
altair
would
be
there
soon
too.
A
B
A
This
note
for
all
our
youtube
viewers-
thank
you
for
watching
and
if
you
like,
the
episode
to
hit
like
and
share
it
with
people,
because
we
need
to
let
the
idiom
community
know
about
this
awesome
history.
As
usual,
I
will
be
looking
forward
to
your
feedback.
You
may
leave
a
comment
and
if
you
have
any
question-
and
you
would
like
to
reach
out
to
the
guest,
the
description
section
contains
all
the
information
for
if
you
can
cater
this
as
well
as
guests,
we
have
many
more
interesting
proposals
coming
up
interesting
topics
in
future.