►
Description
Topics covered
-----------------------------
02:06 - Author's introduction
02:32 - Working team
03:03 - Execution specs introduction
03:21 - Overview of the presentation
03:50 - History & Goals
05:45 - Current state of the Ethereum specs (what it does)
06:26 - Current state - What it looks like
07:28 - Current state - Tools
09:02 - Future Plans - execution specs
10:07 - Future plans - Tools
11:48 - Future plan - how it is used
12:45 - Deepish dive
13:00 - Tour of apply_body (codes)
15:12 - Future of EIP process
18:00 - Call for volunteers
19:39 - Would the Python implementation be on the EIP repo?
20:45 - Code snippets - have you considered the playground environment for Python?
21:45 - Why chose Python?
22:46 - What happens if there is a bug in specifications?
23:20 - Is there an intent to replace the Yellow paper?
24:17 - If there is any discrepancy between what the clients do and what is specified?
24:54 - The EIP process introduces the necessity for EIP Editor to be a Python developer. Would it make the reviewer pool even smaller?
28:35 - How do you ensure, it is going to be followed?
29:40 - Why document Yellow paper in Python in the first place?
30:42 - How do you see this documentation helping after the Merge?
32:50 - Opportunities & challenges to begin the documentation of Ethereum specs now, 4-5 years down the line?
35:04 - When was the Difficulty bomb added?
35:58 - As per the timeline, when do you think for the client developers to pay attention to these specs?
37:07 - How to implement the proposed EIP process
37:53 - A good place for technical understanding of Ethereum?
39:18 - Example of why having this PySpec?
Resources
--------------------
Slides - https://tinyurl.com/peep-an-eip-exe
Specs - https://github.com/ethereum/execution-specs
Follow at Twitter
-----------------------------------------------
Sam Wilson @_SamWilsn_ | William Schwab @William94029369 | Alita Moore @AlitaMoore85 | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
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
To
provide
some
background,
the
ethereum
community
is
progressing
towards
the
merge
of
ethereum
pow
and
the
beacon
chain.
The
client
devs
have
started
following
a
new
set
of
terminology
to
provide
a
clear
understanding
of
the
architecture
so
ensure
the
ethereum
pow
chain
will
be
called
as
execution
layer
or
el,
and
the
beacon
chain
will
be
called
as
consensus
layer
after
the
merge,
and
today
we
are
going
to
learn
about
executions,
layer
specifications.
A
They
consider
this
quilt
mesh
team.
They
have
spent
a
significant
amount
of
time
documenting
ethereum's
consensus
specification
of
the
ethereum
yellow
paper
in
python
implementation
to
provide
the
current
stat
of
implementing
the
execution
specs.
We
are
joined
by
sam
wilson
from
the
quilt
team
and
we
also
have
light
client
and
sky
dietrich
peter
piper
mariam
from
the
team.
A
A
B
Sure
so
this
is
gonna
be
a
little
bit
different
than
other
peep
and
eats
there's
no
eep
this
time.
This
is
more
a
meta
peep
in
eep
we're
gonna
talk
a
little
bit
about
kind
of
a
proposal
or
change.
So
who
am?
I
pujo
went
into
this
a
little
bit.
I'm
sam
wilson,
I'm
a
developer
for
quilt
at
consensus
ag
or
consensus
mesh,
I'm
not
sure
what
we
go
by
anymore.
One
of
those
two
you
can
find
me
on
twitter
or
my
github.
B
We
also
have
four
other
people
who
have
been
like
instrumental
in
kind
of
bringing
the
execution
specs
project
where
they
are,
and
I'm
here
to
take
credit
for
them.
We
have
somu
who's
worked
a
lot
on
eve,
hash
and
some
of
the
evm
opcodes
we
have
peter
who's
worked
on
the
optimize
state
db.
We
have
matt
who's
kind
of
led
the
project
from
behind
the
scenes
and
we
have
void
who's
pretty
much
contributed
everything
about
the
homestead,
hard
fork
and
many
other
contributions.
B
So
without
these
four
people,
this
project
wouldn't
be
here
yeah.
So
we're
here
to
talk
about
execution
specs,
which
was
born
as
the
eth
1.0
specs
repository,
going
to
talk
a
little
bit
about
what
they
are,
which
is
a
description
of
the
ethereum
blockchain
and
its
virtual
machine,
which
can
be
written
as
a
program
and
I'll
get
into
a
little
bit
about
what
that
means
later.
On.
B
For
those
who
don't
know
that
project
is
a
mix
of
markdown
text
with
snippets
of
python,
that's
kind
of
where
we
got
the
inspiration
to
write
a
specification
for
ethereum
one
that
is
executable.
So
it's
not
just
a
latex
document
like
the
yellow
paper.
This
project
is
going
to
hopefully
be
more
accessible
to
developers
and
then
kind
of
the
third
thing
that
got
us
started
on
this
project
is
creating
snapshots
of
ethereum
at
each
hard
fork
and
not
as
a
series
of
patches
which
is
kind
of
what
eaps
are
today.
B
So
we
want
to
have
a
way
to
look
back
at
frontier
and
say
this
is
exactly
what
frontier
was
at
this
time.
Go
to
homestead
do
the
same
thing,
the
tao
and
every
other
hard
fork.
We
want
to
know
exactly
what
ethereum
was
at
that
time
and
kind
of
the
goals
that
we're
going
for
the
things
that
we
want
to
accomplish
in
the
future.
We
want
our
respect
to
be
incredibly
easy
to
read.
B
B
And,
finally,
the
kind
of
one
of
the
goals
we
want
to
do
is
generate
tests
for
clients.
So
if
you're
familiar
with
the
eth
test
or
if
you're
not
familiar
with
tests
and
retest
eth,
they
you
define
kind
of
like
a
pre-state
and
what
you
wanted
to
look
like
after
and
then
you
run
those
tests
against
a
client
to
generate
specifications
for
other
clients
right
now.
That
role
is
filled
by
geth
and
we
want
to
take
over
that
role
with
the
ethereum
specs
or
execution
specs.
B
So
now,
I'm
going
to
go
into
a
little
bit
of
a
summary
of
what
the
current
state
of
the
ethereum
specs
is,
so
what
it
does
we're
functionally
complete
for
the
frontier
hard
fork.
So
as
far
as
I'm
aware,
all
of
the
features
specified
in
the
yellow
paper
are
implemented.
In
our
specification,
we
can
pass
all
of
the
tests
that
other
clients
pass
for
frontier
and
we
can
execute
mainnet
up
until
block
1.2
million
or
so,
which
is
where
homestead
comes
in.
B
So
this
is
kind
of
what
it
looks
like
right
now.
So
on
the
on
at
least
on
my
left.
Here
we
have
the
validate
header
function,
written
in
normal
python,
with
the
addition
of
typing
annotations,
which
I
can
cover,
which
I'll
talk
a
little
bit
about
later
so
you'll
note
that
we
use
normal
python
doc
strings
relatively
normal
python
and
it
generates
this.
This
output
on
the
right
hand
side.
So
this
output
is
definitely
in
an
early
state.
B
It's
not
going
to
look
like
this
when
it's
done,
but
you
can
already
see
that
it
has
a
lot
of
the
features
of
the
consensus
specs
repository,
so
we
have
a
blurb
here
of
annotations,
which
eventually
we'll
be
able
to
toggle
on
and
off,
and
you
actually
have
the
implementation
here,
which
this
format
again
comes
from
the
consensus
repo
we
recreated
it
here,
but
using
a
different
set
of
tools
yeah.
So
one
of
the
nice
things
about
this
that
we
have
over
the
consensus,
specs
repository
is
you
we
actually
have
navigable
links.
B
B
B
Our
testing
is
a
bit
of
a
combination,
so
we
use
the
same
test
that
clients
use,
which
is
the
ethereum
consensus
tests,
and
we
also
have
pi
test
flavor
tests
for
things
that
are
more
specific
to
the
specification.
So,
for
example,
our
uint256
implementation
is
tested
with
pi
test,
but
we
do
use
a
combination
of
both
of
them
now
for
linting.
Since
we're
a
specification,
we
have
fairly
strict
rules
about
the
format
of
the
code.
B
B
normal
python
tools
just
configured
to
be
pretty
harsh.
There's
also
spell
checking
and
a
few
other
nice
little
things,
but
otherwise
it's
pretty
normal.
Finally,
we
use
sphinx,
which
is
probably
the
most
common
python
documentation
tool
out
there.
It
takes
our
python
source
code
plus
annotations
and
converts
them
into
the
format
you
saw
earlier
all
right.
So
I'm
going
to
talk
a
little
bit
about
where
we're
going
with
the
spec
again.
This
is
all
my
opinion
feel
free
to
disagree,
yeah,
so
here's
kind
of
what
I'm
planning
for
the
specs
project
itself.
B
So
obviously
we
want
to
complete
the
rest
of
the
hard
forks.
You
know
homestead
the
dao
all
the
way
up
until
london,
shanghai
after
the
merge
yeah.
So
the
probably
the
next
biggest
chunk.
We
have
to
get
started
on
and
and
probably
now
is
a
good
time
to
get
started
on.
It
is
writing
narrative
style
documentation.
B
B
for
tooling.
So
this
is
probably
the
star
feature.
The
number
one
thing
that
I'm
looking
forward
to
for
the
execution
specs
project
is
rich
patches
or
semantically,
aware
diffs
between
hard
forks
and
eips.
If
you
write
an
eip,
it
will
be
able
to
generate
a
diff,
like
this
you've,
probably
seen
similar
stuff
on
github,
where
it
crosses
out
the
old
stuff
and
puts
the
new
stuff
in
and
highlights
it.
So
it's
super
easy
to
see:
what's
changed
between
hard
forks
without
having
to
read
through
pages
and
pages
of
eips.
B
So
this
is
probably
the
thing
I'm
most
excited
about,
and
I'm
really
like,
I'm
thrilled
that
this
is
starting
to
work.
I'm
working
on
this
myself
and
it's
coming
together.
Slowly
but
surely
another
feature
that
we've
seen
a
lot
of
desire
for
is
toggleable
annotations.
So
if
you've
seen
the
annotated
specs
project,
then
you'll
know
exactly
what
this
is.
B
But
if
you
haven't
it's
kind
of
like
a
longer
form
english
description
of
what
the
specification
is
describing
kind
of
explaining
the
rationale
behind
it,
why
it
is
the
way
it
is,
and
maybe
some
notes
about
implementation.
So
we
want
that
to
be
maintained
in
the
same
place
as
the
specifications
themselves.
B
B
B
So
now
I'm
going
to
do
a
deep,
ish
dive.
I
am
not.
You
know
the
primary
developer
on
this
project.
I
just
kind
of
manage
it
and
take
credit,
so
I'm
going
to
quickly
dive
into
the
apply
body
function
and
show
you
a
little
bit
about
how
it
looks
and
how
it
gets
transformed
into
the
output.
Then
we
can
come
back
to
this.
B
So
this
is
the
apply
body
function
in
the
rendered
state.
So
you
can
kind
of
see
the
function.
Signature
here
with
the
type
annotations
you
can
navigate
through
them
all
and
get
to
the
actual
implementations.
Now
here
we
have
kind
of
a
stub
note
about
what
this
function
does.
This
is
kind
of
the
narrative
portion
that
I
was
talking
about
earlier.
B
That
needs
to
be
expanded
upon,
but
this
function
takes
the
block
body,
so
transactions
omers
and
applies
them
to
the
current
head
of
the
chain,
so
description
of
all
the
parameters
and
stuff
and
here's
the
actual
implementation.
So
this
portion
all
of
this
code
or
all
of
this
html,
is
actually
rendered
from
the
the
actual
python
spec.
B
We
quickly
iterate
through
all
of
the
transactions
and
for
each
transaction.
We
set
the
try
value
with
at
the
index
with
the
value
of
the
transaction.
We
do
some
checks
to
make
sure
the
preconditions
are
correct
and
then
we
actually
build
the
evm
and
execute
the
body
of
the
transaction
subtract
the
gas
and
then
encode
the
receipt
into
the
receipts.
Try.
B
So
this
this
function
really
does
highlight
kind
of
how
simple
this
code
is.
It's
normal
python
implemented
almost
entirely
with
free
functions,
meaning
that
they're
not
attached
to
classes.
I'd
say
around
90
of
the
functions
in
the
in
the
entire
spec
are
side
effect,
free,
yeah
and
then
so
your
inputs
get
transformed
into
outputs
and
they
don't
change
anything
else,
and
that
makes
this
really
easy
to
follow.
B
B
Probably
running
a
bit
long
on
time,
so
I'd
like
to
talk
a
little
bit
about
the
future
of
the
eip
process.
Now
so,
first,
a
warning:
this
is
a
rough
idea
of
what's
possible
with
the
specs
don't
hold
me
to
this.
I
haven't
talked
to
anybody
about
it.
I'm
sure
there's
going
to
be
a
ton
of
input
that
we
need
to
have
on
this.
This
is
just
what
I'm
kind
of
envisioning.
B
Now,
these
types
of
changes
have
different
should
be
in
different
repositories
because
they
have
different
processes
associated
with
them.
They
both
describe
different
parts
of
ethereum
but
completely
different
parts,
and
you
know
the
technical
reason
for
this.
This
recommendation
is
because
ercs
don't
change
any
of
the
the
execution
specs
they're
implemented
entirely
within
the
execution
specs.
So
they'd
be
like
it'd,
be
difficult
to
combine
them
into
a
single
repository.
B
B
B
So
eips
would
be
documentation
for
a
diff
as
opposed
to
writing
out
what
changes
you
want
to
make
in
english,
so
you'd
basically
get
rid
of
the
specifications
section
of
eips
and
replace
it
with
a
literal
code,
diff
against
the
execution,
specs
repository
everything
else
about
eips
the
abstract,
the
motivation,
the
rationale,
I
think,
should
stay
the
same
again.
The
only
difference
would
be
to,
instead
of
describing
the
change
in
english,
make
the
change
with
python.
B
So
here's
kind
of
a
really
really
hastily
thrown
together
diagram
of
what
I
think
this
should
look
like,
so
we're
currently
at
fork
end.
You
have
a
bunch
of
draft
eips
which
are
branched
off
of
the
master
branch.
You
know
just
pick
some
random
numbers
each
one
of
these
would
live
in
their
own
branch
as
they
become
final.
B
So
I
just
want
to
quickly
put
out
a
call
for
volunteers,
there's
three
things
that
I
think
are
really
easy
to
get
started
on
and
where
I'd
like
to
get
some
help.
One
is
the
narrative
documentation,
the
code's
finished
for
frontier,
but
if
you
can
read
code
or
read
the
yellow
paper,
I'd
love
to
get
some
pull
requests
in
to
actually
start
writing
the
narrative
about
just
like
the
english
annotations.
B
The
next
thing
is
test
coverage.
We've
discovered
a
couple
issues
while
syncing
the
chain
that
didn't
have
test
coverage
in
ethereum
tests.
If
you
know
retest
ether,
don't
mind
learning
a
little
bit
about
it.
Talk
to
me
and
I
can
get
you
set
up
to
write
a
test
case
and
finally
tooling.
So
I'm
a
russ
developer,
mostly
I'm
fairly
new
to
python.
So
all
the
tools
are
hacked
together.
B
A
Thank
you
so
much
for
presentation,
sam.
It
was
too
much
to
take
in
like
in
all
but
interesting
to
know
that
there
are
some
new
processes
coming
up
and
I
was
really
happy
to
see
about
this
annotated
specs
for
execution
there.
I
have
read
about
the
consensus
layer
when
we
saw
for
the
altair
vitalik
wrote
the
annotated
specs.
I
am
really
thrilled
to
learn
about
something
similar
happening
in
the
execution
layer.
C
So
where
would
this
all
right?
So
you
were
saying
that
when
you
make
an
eip
and
you
merge
it,
it
would
then
be
in
the
fork,
and
you
would
like
include
the
change
in
python,
but
when
you
merge
the
eip,
would
that
be
like
your
your
diff?
So
in
other
words,
what
I'm
asking
is,
would
the
python
implementation
be
on
the
eip's
repo
and
then
you
change
it
and
then,
in
addition
to
that
you're
supposed
to
include
an
eip
and
then
it
goes
to
the
repo.
B
B
D
C
Well,
anyone
else
can
feel
free
to
jump
in,
but
I
noticed
that
there
were
like
code
snippets
that
you
had
like
in
the
diff
right,
and
it
would
be
interesting
to
me
like
have
you
guys
ever
considered
like
having
like
a
playground,
environment
or
something
to
like
mess
around
with
it?
So
people
can
like
see
the
change
in
behavior.
B
No,
that's
definitely
possible,
like
you,
can
take
all
of
like
there's
a
python
interpreter
that
you
can
run
in
javascript,
for
example.
So,
like
you
know,
definitely
stretch
goal,
but
you
could
totally
replace
the
javascript
vm
in
remix,
for
example,
with
this
and
run
this
like
run
remix
against
your
modified
spec,
but
that'd,
be
you
know
far
far
far
out
from
today
yeah
it.
A
So
I
have
a
question
that
is
unlike
more
on
a
broader
level:
it's
about
the
the
language
that
you
guys
have
chosen
about
the
implementation
you
did
mention
that
you
are
a
rust
developer
and
I
understand
this:
entire
implementation
is
going
on
in
the
python.
So
why
choose
python
for
this
documentation.
B
B
E
B
So
I
think,
there's
there's
three
separate
questions
to
unpack
there.
So
first
do
I
intend
for
this
to
replace
the
yellow
paper
and
personally,
I
would
love
for
that
to
happen,
but
that's
not
my
decision
and
I
think
the
yellow
paper
is
another
like
great
way
of
specifying
it's
just
not
as
accessible
to
as
accessible
to
developers,
so
that
that's
a
decision
that
the
community
is
going
to
have
to
come
to
now.
I
think
your
second
question
was
I've
completely
forgotten.
Your
original
question.
Sorry,
no!
No.
B
B
That's
a
much
more
difficult
question
because,
like
obviously
the
network
exists
and
lives
and
let's
say
all
the
clients
implement
it
in
the
same
way,
but
it's
different
than
what
the
specification
says.
Then
you
know
it's
probably
easier
to
go
with
what
the
specification
said
or
what
the
clients
say
unless
there's
some
compelling
technical
reason
not
to
we
would
update
the
spec,
but
this
really
has
to
be
decided
on
a
case
by
case
basis,
depending
on
what
the
bug
is
or
what
the
discrepancy
is.
C
C
I
know
how
to
review
that,
and
so
I'm
wondering
if
you've,
given
I
mean-
and
this
can
be-
you
know-
pushed
off
to
another
date
when
you
begin
to
collect
consensus
about
it.
But
I
wonder
if
you've,
given
any
thought
to
how
that
would
look
or
how
you
would
kind
of
not
make
the
the
pool
of
people
who
could
review
even
smaller.
B
I
actually
don't
have
an
eip
open
right
now,
so
I
can't
pull
it
up
easily,
but
some
of
the
rules
we
have
for
contributing
here
is
that
variable
names
have
to
be
full
words
that
can't
be
shortened.
Everything
has
to
be
very
explicit
and
written
in
a
way.
That's
easy
to
understand.
So,
if
you've
ever
reviewed,
an
eip
you'll
know
that
a
lot
of
the
eip
specification
section
is
is
describing
like
a
a
framework
or
a
language
for
discussing
how
the
change
will
work.
So
you
have
to
define
all
of
these
terms.
B
B
I
think
that's
going
to
make
it
understand
more
understandable,
even
for
people
who
don't
know
how
to
program
on
the
flip
side,
it
will
make
it
so
that
you
do
need
to
understand
python
to
or
be
able
to
write
python
to
propose
an
eip,
and
you
know
I
think,
that's
going
to
be
like
narrow
a
little
bit
the
number
of
people
who
can
contribute
in
that
way,
but
the
consensus
specs
are
already
written
in
python
and
already
require
that
knowledge.
So
the
bar's
already
been
raised.
C
B
E
And
I
think
the
advantage
of
python
also
is
something
that
you
mentioned
before.
Is
that
it's
a
fairly
intuitive
structure,
I'd,
imagine
even
people
without
much
of
a
python
background,
just
by
looking
over
the
code
could
probably
figure
most
at
least
not
exceptionally
complex
tasks
out,
even
if
it's
not
their
language
of
choice,.
B
C
I
have
one
more
question
yeah
before
somebody
else
can
feel
free
to
to
jump
over
me.
But
so
the
goal
is
like,
as
I
understand
it
is
to
provide
an
easily
accessible
way
for
developers
to
kind
of
see
the
difference,
the
the
diff
between
forks
or
changes.
But
how
do
you
assure
so,
like
you
kind
of
have
this
like
centralized
like
single
source
of
truth
of
python
implementation,
but
then
how
do
you
guarantee
that
the
clients
are
going
to
follow
that,
or
is
that
you
don't.
B
I
mean
one
advantage
for
python:
is
that
it
is?
You
can
translate
it
into
formal
verification
if
you
want
to,
but
that's
outside
my
area
of
expertise.
I
think
it's
going
to
be
the
same
process
that
we
have
now
with
the
yellow
paper,
where
I
and
eips,
where
you
have
to
write
your
eip
write
test
cases
for
it,
translate
those
test
cases
into
json,
retest,
eth
kind
of
tests
and
then
run
those
tests
against
your
clients.
A
So
if
I
understand
correct
this,
the
effort
that
has
been
put
around
is
mostly
about
like
yellow
paper
in
python
right.
The
yellow
paper
itself
is
editable,
as
per
my
understanding
like
it's
like
maintained
on
github,
and
we
recently
have
seen
eib
3607
the
reject
transaction
from
senders.
This
proposal
was
updated
in
the
yellow
paper.
So
what
was
the
need
for
having
this
documented
all
together?.
B
Sure
so,
there's
kind
of
two
two
parts
to
that.
So
one
you
can't
execute
the
yellow
paper.
You
can't
use
the
yellow
paper
to
do
anything
directly.
You
have
to
translate
it
and
there's
always
room
for
error
there
and
second,
I
think,
while
a
lot
of
people
in
the
ethereum
space
are
academic
and
in
background,
a
lot
of
us
come
from
an
engineering
or
development
background,
and
the
yellow
paper
is
rather
opaque
to
to
people
like
us,
and
I
think
that's
my
main
main
reason
for
rewriting
it.
A
B
So
so
we
don't
actually
include
any
consensus,
so
we
don't.
We
don't
really
describe
proof
of
work
outside
of
the
ethic
ethics
implementation.
We
don't
really
foresee
many
changes
at
all.
When
we
come
to
the
the
merge,
because
we
don't
we
just
don't
deal
with
that.
We
assume
that
the
blocks
we
get
have
a
valid
difficulty
and
a
valid
proof
of
work.
A
B
B
One
of
the
things
that
I
really
really
really
want
to
get
out
of
this
project
is
this
merge
here
I
want
to
be
able
to
like
see
ethereum
after
the
eips
have
been
implemented,
and
that's
what
the
yellow
paper
updates
are
and
then,
like
tim
said,
they
happen
way
after
they're
actually
implemented.
So
I
want
to
give
client
developers
and
people
watching
and
app
developers
kind
of
like
you
can
look
at
what
ethereum
will
be
once
everything
is
merged
together
and
I
think
that's
just
going
to
be
super
invaluable
for
the
whole.
A
I
would
totally
agree
to
that.
I
would
like
to
understand
some
of
the
maybe
opportunities
and
challenges
because
the
the
consensus
layer
they
have
this
specs
written
since
the
beginning
of
the
chain,
but
on
the
execution
layer,
we
started
it
after
the
period
of
time,
like
four
five
years
down
the
line.
What
do
you
think
turned
out
to
be
the
advantage
of
starting
late,
or
maybe
the
challenges
you
might
have
faced
during
the
implementation.
B
Sure
so
I
think
one
of
the
the
biggest
advantages
to
starting
late
is
that
we
already
have
you
know
three
or
four
solid
code
bases
that
we
can
steal
implementations
from
we.
We
don't
need
to
implement
everything
from
scratch,
which
is
which
is
great
like
when
we're
syncing
the
chain.
We
actually
swap
out
little
pieces
of
the
spec
for
faster
ones
that
come
from
other
people's
implementations,
so
we're
literally
just
borrowing
stuff.
That's
already
been
done
and
that's
been
absolutely
amazing.
B
B
So
technically
it
is
a
hard
fork
to
add
the
difficulty
bomb,
but
no
one
thinks
of
it.
That
way,
no
one
there's
no
difficulty
bomb
hard
fork
that
happened
like
after
frontier,
so
we
can't,
you
know,
introduce
a
hard
fork
in
between
frontier
and
homestead,
just
because
no
one
thinks
of
it.
That
way,
and
that's
one
of
the
challenges
that
we
we
have
to
face
is
we
have
to
match
our
kind
of
description
of
the
past
to
what
people
commonly
believe
the
past
was.
A
A
F
F
D
So
I
assume
at
some
point
in
this
process:
you'd
probably
want
like
some
attention
by
client
developers
paid
to
this
right
once
once
weeks,
restart
once
once
you
reach
parity
with
kante
mainnet
and
future
erp
proposals
will
be
specified
against
it.
I
assume
client
developers
would
have
to
be
familiar
with
it,
to
be
able
to
use
these
specifications
and
to
go
ahead
and
implement
those
changes
and
everything.
What
do
you
think
like
just
timeline
wise?
B
I
think
the
earlier
the
better
for
just
like
the
general
idea.
I
don't
know
how
many
core
developers
would
actually
be
excited
about
changing
the
eip
process
to
use
this
so
feedback
on
that
would
be
invaluable
now
feedback
on
the
code
itself,
I
think,
can
can
wait
probably
a
month
two
months
until
we're
closer
to
actual
mainnet.
A
In
fact,
my
question
that
I
was
about
to
ask
is:
maybe
a
kind
of
follow-up
of
this
like
we
can
probably
start
with
a
specific
category
of
proposal
from
which
it
started
up.
That's
what
I
consider
it
for
to
be
it's
about
the
interface
proposal,
so,
if
not
for
the
entire
eip
process,
maybe
we
can
do
the
experiment
with
one
particular
category
and
then
try
to
implement
it
to
the
rest
of
the
one.
B
Yeah,
I
think
a
really
interesting
way
to
do
this
would
be
when
we
get
up
to
parity
with
mainnet
every
eip
that
gets
proposed.
We
create
a
copy
of
that
eip
against
the
execution
specs
repository
that
way
like
eip
authors,
don't
notice
a
change
and
we
can
see
how
practical
it
is
to
start
rewriting
and
switching
over
the
eip
process.
G
I
was
curious
what
you
think
sam,
like
what
other
people
on
this
call
think
when
people
ask
them
like.
Can
you
give
me
a
good
place
to
look
for
a
technical
understanding
of
ethereum?
I
feel
like
I'm
getting
this
question
somewhat
frequently
over
the
last
few
months,
and
I
want
to
like
point
them
to
this
pie.
Speck
I
feel
like
after
the
narrative
is
written.
It's
going
to
be
a
good
thing,
but
until
then
I
feel
like
I'm
pointing
people
to
the
yellow
paper,
and
I
don't
know
if
there
are
other
things.
F
We'd
have
to
it's
much
simpler
and
I
remember
someone
called
gum
is
working
on
implementing
vertical
and
guests
and
he
demonstrated
on
a
peep
and
eep
that
he
had
a
version
of
this
working
with
guests.
That
could
talk
to
itself
in
vocal
tree
mode,
and
I'm
like
this
is
kind
of
cool.
But
you
haven't
actually
proved
anything
because
getting
guest
to
talk
to
itself
anyway
doesn't
amount
to
much.
But
in
terms
of
demonstrating
something.
But
if
we
had
the
execution
specs,
you
would
have
had
a
exit
of
a
verifier.
F
C
A
So
I'm
happy
to
see
that
there
are
a
couple
of
things
that
you
mentioned
about
that
that
we
can
expect
in
future,
just
like
the
annotated
spec
for
execution
layer
and
also
the
adding
of
adding
to
the
folkman
tool.
That
has
been
really
helpful
during
the
break
time
when
we
know
like
how
many
clients
are
on
thing
on
the
same
page.
A
So
on
that
note,
let
me
call
out
youtube
viewers
for
watching
this
episode.
I
hope
you
learned
something
today
and
if
you
did
please
pay
it
forward,
do
like
and
share
this
episode
and
share
the
link
with
the
community
members.
So
people
know
more
about
the
new
and
proposed
upcoming
changes
for
the
proposed
eip
process.
A
So
thank
you,
everyone
for
joining
us
today.
The
youtube
viewers
may
find
a
guest
contact
and
related
resources
of
the
topic.
In
the
description
section,
don't
forget
to
share
your
feedback
with
us,
we'll
be
back
with
another
interesting
topic
till
then.
Keep
watching
keep
sharing
your
love
with
us
see.
You
soon
have
a
good
one.