►
Description
Resources:
EIP - https://eips.ethereum.org/EIPS/eip-2315
Discussion - https://ethereum-magicians.org/t/eip-2315-simple-subroutines-for-the-evm/3941
Follow at Twitter:
Greg Colvin @greg_colvin | William Schwab @William94029369 | Alita Moore @AlitaMoore85 | Brent Allsop @Brent_Allsop | Pooja Ranjan @poojaranjan19
Follow PEEPanEIP earlier episodes at https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
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-herders/PM
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Hello,
everyone
and
welcome
to
the
25th
episode
of
deepening
the
one
and
only
eip
focus
series
where
we
discuss
an
ethereum
improvement
proposal
and
understand
how
it
is
going
to
make
the
ethereum
chain
even
better.
I'm
your
host
and
with
me
is
william
schwab,
brent,
alsop
and
elitamore
from
the
athenian
cathodes
wow.
It
feels
so
good
that
we
are
24
episodes
old
to
me.
It's
like
just
we
just
started.
A
Nevertheless,
if
you
have
missed
any
proposal
that
we
discussed
in
earlier
episodes,
you
may
follow
the
recording
available
on
p
penny
playlist
on
ethereum
cathedrals
youtube.
Today
we
are
going
to
have
an
overview
of
eit2315,
simple
subroutine
for
the
evm
that
is
created
in
october
2019
and
is
a
standard
track
core
eip
that
is
in
draft
status.
It
is
also
up
for
berlin
upgrade
to
provide
an
overview.
We
have
got
with
us
greg
colvin,
one
of
the
co-authors
of
the
proposal,
who
happens
to
be
on
our
show
multiple
times
as
an
editor
welcome
again
greg.
A
It's
always
been
a
pleasure
to
have
you
on
the
show
this
time,
it's
a
little
different
that
we
would
be
talking
about
a
proposal
and,
of
course,
if
time
permits,
we
will
hear
your
thoughts
on
new
standardization
process
network
upgrade
and
other
things
as
an
eap
editor.
So
without
further
ado,
the
floor
is
all
yours.
B
I'm
broadcasting
from
a
hotel
room
in
huntington
west
virginia
because
everyone's
heard
of
the
big
storm
in
texas,
but
a
little
place
called
boyd
county
kentucky,
got
hit
as
hard
or
harder,
and
I've
been
a
refugee
for
almost
two
weeks
now
so
finally,
they
they
cut
a
kind
of
route
into
our
home
monday
and
we
got
there
and
there
was
power,
but
no
internet,
no
telephone,
so
I've
rented
a
room
here.
Where
would
I
have
internet
so
join
this
meeting
and
start
to
get
some
work
done
again
so
glad
to
be
here?
B
I've
lost
track
of
the
process.
This
is
labeled
draft.
I
I
looked
at
the
other
eips
going
into
berlin
and
I
think
they're
all
in
a
different
status,
so
clearly
things
we
haven't
gone
back
through
things
and
labeled
them
with
whatever
the
new
labels
are,
you
know,
but
I
think
they
must
all
be
close
to
final
or
they
wouldn't
be
going
in.
B
B
This
particular
proposal
actually
has
a
long
history
going
back
to
eip
615,
which
was
basically
an
attempt
to
get
the
evm
up
to
the
standards
of
the
jvm.
It
wasn't
a
more
structured
assembly
code
that
assured
certain
safety
properties,
and
that
was
just
too
big
an
ask
just.
I
don't
entirely
understand
why.
B
You
couldn't
underflow
the
stack
and
other
safety
properties
would
be
nice.
One
of
the
hang-ups
there
is
there
needed
to
be
a
mechanism
for
doing
versioning
on
evm.
The
original
evm
did
not
reserve
an
op
code
or
something
to
put
at
the
beginning
of
the
code
to
say
this
is
version
one.
This
is
version
two
and
that
turned
out
to
be
difficult
enough
to
do
that.
It
still
hasn't
been
done
and
it'll
take
a
lot
of
motivation
if
it's
easily
doable
at
all,
so
I'll
screen
share
briefly.
B
B
B
We've
introduced
a
begin
cell
bob
code.
That
says
this
is
the
beginning
of
the
subroutine.
We've
introduced
the
jump
sub
out
code.
It
says
you
push
the
address
of
a
routine
and
then
you
jump
to
it
and
we've
introduced
return
sub,
which
says
I'm
done
with
this.
Please
return
yeah,
so
we
have
a
multiply
which
has
a
begin
sub.
The
market's
beginning
has
a
mall
instruction
to
multiply.
B
What's
on
the
stack
and
the
return
sub
markets
on
the
stack-
and
here
is
an
example
of
actually
using
the
routine,
so
you
start
out,
you
want
to
multiply
two
times
three,
so
you
push
two,
you
push
the
multiply
address
and
you
jump
to
it.
So
here
you've
pushed
the
two
you've
pushed.
I
got
that
backwards
anyway,
stack's
running
the
other
way.
That's
right!
It
grows
down.
It's
right.
B
You
push.
The
three
you've
got
a
two
and
a
three
multiply.
Then
you
push
the
multiplies
popped
off
the
stack.
You
have
a
two
and
a
three
on
the
stack
you
implement,
multiply
and
there's
a
six
on
the
stack
and
you
return
so
a
huge
saving
in
the
complexity
of
the
code
and
a
huge
saving
in
the
amount
of
gas.
You
have
to
spend
the
call
of
something
and
that's
pretty
much
all
there
is
to
it.
B
And
the
eip
is
longer
because
there's
more
detail
and
there's
test
cases
for
most
of
the
ways
to
do
it
right
and
to
do
it
wrong,
but
there's
just
so
very
little
to
say
about
it,
because
it's
that
it's
just
that
simple
the
difference
here
from
615
is
there's
no
error.
Checking
you
can
you
can
do
these
in
any
way
you
want.
You
can
make
all
kinds
of
messes.
B
You
could
actually
do
an
ordinary
jump
right
into
the
middle
of
the
multiply
routine.
It's
not
entirely
clear
what
would
happen
but
you're
on
you're
on
your
own
with
that,
so
you
could
do
things
like
implement
subroutines
with
multiple
entry
points,
which
is
supposed
to
be
a
very
naughty
thing
to
do.
But
if
you
want
to
do
it,
you
can
do
it
and
it's
your
problem
not
to
shoot
yourself
in
the
front.
B
I
prefer
I
preferred
that
the
code
be
verifiably
correct,
but
this
is
a
much
easier
thing
to
get
into
the
interpreters
on
the
turbo
death
project.
There's
some
people
doing
static
analysis
and
a
possibility
that,
rather
than
restrict
the
evm
code
to
enforce
safety
properties,
we
can
do
hispanic
static
analysis
of
the
code
when
we
deploy
it
and
the
static
analysis
can
prove
that
the
code
meets
certain
safety
constraints
and
then
the
proof
can
be
attached
to
the
code.
So
you'll
have
a
certificate
of
the
proof
attached
to
the
code
and.
B
B
Compilers
fancier
interpreters
can
use
that
certificate
to
say.
Okay,
for
instance,
they've
proved
that
this
program
will
never
open
the
flow
of
the
stuff.
Therefore,
I
don't
need
to
check
the
stack
overkill.
They've
proved
that
this
program
follows
the
structured
control
flow.
So
when
I
compile
it,
I
can
assume
that
the
control
flow
is
structured
and
other
things
like
that,
rather
than
here
guarantee
that
they're
true
through
the
uvm
code,
you
prove
it
later.
It's
a
more
sophisticated
technique,
but
actually
much
more
flexible
and
we'll
just
see
how
that
works
out.
C
B
B
C
B
D
B
Code
is
dynamic,
you
could
do
a
calculation
of
what
stuff
routine
you're
going
to
jump
to
and
then
a
static
analyzer
might
have
to
throw
up
its
hands
and
say
I
don't
know
where
it's
going
to
jump.
I
can't
run
the
calculation
myself,
I'm
doing
it
statically,
I'm
not
running
the
filter,
so
having
subroutine
jumps
and
using
them
makes
it
easier
for
static
analyzer
to
know
when
it
sees
a
jump
sub.
That
always
knows
where
it's
going
to
go.
B
I
understand
it
also
means
I've
heard
people
doing
static
analysis,
for
various
reasons.
Tell
me
that
it's
it's
difficult,
looking
at
solidity
code
to
know
where
the
subroutines
are,
they
have
to
go.
Looking
in
the
code
for
patterns
like
this
that
say.
Oh,
this
is
the
pattern
of
a
subroutine
call
and
return,
and
these
patterns
change
a
little
bit
with
releases.
B
They
can
be
difficult
to
recognize
and
it
makes
their
life
more
difficult
if
solidity
starts
generating
code
like
this,
it's
easy
to
scan
the
code
and
say:
oh
here's,
the
start
of
the
cell
routine.
Oh
here's
the
end
of
the
cell,
routine,
here's
the
start,
here's
the
end,
so
it
gets
much
easier
to
parse
the
code
for
analysis
purposes.
C
Interesting
you
mentioned
before
that
in
this
simpler
version,
the
current
eip,
so
there's
all
kinds
of
quote
naughty
end
quote
things
that
you
can
do
with
with
the
dynamic
jumps.
Does
that
introduce
any
new
security
like
security
concerns,
new
attack
vectors
by
being
able
to
manipulate
the
evm
directly
with
low
level
code.
B
B
C
B
B
Adding
anything
gives
you
new
ways
to
write
an
attack.
It
also
makes
it
possible
to
generate
code,
that's
simpler
and
less
likely
to
have
errors
in
it.
So
that's
that's
a
reasonable
balance
and
it
means
you've
got
to
write
a
little
bit
more
code
in
the
client,
but
in
this
case
not
very
much
and
being
that
they're
very
simple,
the
the
test
suite
is,
is
we
we
think
it'll
it's
going
to
catch
any
problems,
so
we're
pretty
confident
in
this
one.
B
C
So
there's-
certainly
I
you
mentioned
before
that
one
of
the
big
pros
so
to
speak
in
favor
of
the
cip,
are
saving
on
gas
costs
by
eliminating
a
lot
of
evm
steps
in
code.
So
I
mean
you're
saying
that
there's
also
not
going
to
be
any
like
it's
not
going
to
be
a
massively
more
expensive
op
code
than
previous
app
codes.
D
E
B
B
We
actually
started
out,
just
using
jump
desks,
which
would
be
the
simplest
possible
thing
to
do,
but
it
it
was
simpler
for
the
interpreter.
But
it
was
simpler
for
the
programmer
to
be
able
to
to
see
the
difference
between
a
the
beginning
of
the
subroutine
and
and
just
any
other
jump
destination
so
that
that
op
code
is
essentially
free
and
then
the
jump
sub
and
the
return
sub
are
pretty
cheap.
D
A
So,
in
terms
of
writing
these
codes,
what
difference
did
people
find
it
in
writing
in
solidity
and
evm
assembly?
I
remember
some
discussion
and
discard.
I
think
it
was
getting
around
the
performance
issue.
Could
you
shed
some
light
on
that,
like
I'm
curious
to
understand,
if
this
is
normal
to
have
these
issues
using
different
language,
or
was
this
any
this
proposal
specific.
B
B
I
think
this
example
or
something
close
to
it,
showed
up
in
the
theater
discussion.
You
know
that
it's
just
either
as
an
assembly
language
programmer
or
as
a
compiler
writer.
It's
an
awful
lot
easier
to
write
the
code
on
the
right
than
it
is
to
write
the
code
on
the
left
and
it's
going
to
burn
a
lot
less
gas
to
run
the
code
on
the
right
than
to
run
the
code
on
the
left.
B
B
A
B
Oh,
I
definitely
wanted
it
to
be
cheaper
yeah,
but
partly
just
from
a
software
structure.
Point
of
view:
it's
it's
nice.
If
you
can
break
the
software
down
into
fairly
small
sub-routines
that
you
know
do
a
small
thing
and
do
it
well
and
if
there's
a
lot
of
overhead
for
calling
subroutines
people
tend
to
write,
you
know
big
complicated
subroutines
and
get
them
wrong.
A
So
you
didn't
mention
about
eip.
615
subroutines
and
static
jump
for
evm,
which
was
like
this
proposal
was
very
much
inspired
by
that,
as
you
mentioned,
that
this
proposal
may
have
been
helping
us
to
lift
up
some
of
the
constraint,
maybe
more
on
the
structure,
and
apart
do
you
think
any
other?
You
know
advantage
that
we
got
with
this
proposal.
B
It's
going
to
complicate
the
yellow
paper
a
little
bit
more.
That
I
would
like
actually
introducing
begin
sub
adds
a
adds,
a
whole
other
little
section
to
the
yellow
paper.
That's
almost
the
same
as
the
specification
of
the
jump
routine,
but
not
quite
so,
but
I
guess
making
the
yellow
paper
just
a
little
bit
more
complicated
is.
A
B
The
actual
proposal,
I
think
it
took
me
about
two
days
to
design
and
write
it
initially
when
615
failed,
it's
like
well,
we
need
something
so
given
six
one,
five
extracting
this
wasn't
hard
and
over
the
course
of
a
few
months
on
and
off,
martin
manaxic
and
christian,
and
I
refined
a
few
things
and
right
writing.
The
full
proposal
took
longer
because
we
went
to
the
effort
of
trying
to
define
it.
All
very
clearly
include
a
complete
set
of
test
cases.
A
Yeah
that
that's
certainly
interesting,
I
I
just
want
to
mention
one
thing
like
I
see
this
proposal
is
not
updated
with
all
the
clients
implementation
link
like
this
is
up
for
burling,
so
this
is
something
maybe
we
could
do
it
with
the
help
of
pr
to
add
the
references
of
the
clients,
even
the
turbo,
get
that
you
mentioned,
that
they
are
trying
to
do
some
experiment
with
avm
codes,
so
yeah.
I
think
that
would
be
great
for
people
to
reach
out
to.
B
A
A
B
So
it's
more
convenient
in
that
sense
to
put
them
into
memory,
but
then
you
have
the
inconvenience
of
keeping
track
of.
Where
did
you
put
them
in
memory
and
clearing
that
memory
out
when
you
exit
the
routine
and
nick
johnson's
suggested
that
we,
in
addition
to
the
stack
pointer,
have
a
frame
pointer
yeah,
because
a
lot
of
languages
and
machines
have
the
concept
of
a
large
frame
of
parameters
and
local
variables?
B
So
that
would
let
you
keep
in
in
memory
a
a
frame
of
data
as
well
as
the
stack
pointer
and
then,
as
you
move
along,
you
move
the
stack
pointer.
You
move
the
frame,
you
move
the
stack
pointer,
you
move
the
frame
and,
as
you
go
back
up
it
re,
it
recovers
the
memory
automatically
and
nick
nick
points
out
that
his
mechanism
is
more
general
than
that.
So
I
I
called
it
an
auxiliary
stack
and
he
didn't
like
me
calling
it
that
I
think
I
told
him
well.
B
B
F
B
A
So
yeah,
I
have
one
last
question
about
the
eip
status.
It's
actually
not
a
question
like
in
the
beginning
of
the
call
we
were
discussing
about
the
status
of
the
proposal
right
so,
as
you
may
have
been
familiar,
that
the
standardization
process
that
we
are
trying
to
enforce
here,
with
every
proposal
getting
into
upgrade
or
not
an
upgrade
in
standardized
general.
B
Yeah
the
way
back
when
it
was
pr
pretty
much
me
and
nick
and
hudson
who
worked
out
the
initial
scheme
and
we
were
pretty
much
in
the
eip
scheme-
things
became
drafts
and
they
stayed
drafts
and
then
the
core
devs
could
do
whatever
they
wanted
with
it,
and
if
ever
it
hit
the
main
chain,
then
whatever
it
was
that
actually
hit
the
main
chain
would
come
back
to
the
eip
process.
As
final
last
call
got
introduced
mainly
for
ercs,
so
there'd
be
some
process
for
saying
this
erc
is
done.
B
This
is
what
you
need
to
implement
and
they'll
only
be
errors
on
it.
After
that
and
in
in
discussions
over
recent
months,
some
more
a
more
complex
scheme
has
been
put
together.
I've
been
one
of
those
just
goes.
No,
I
don't
really
want
a
scheme
like
that,
but
given
that
exists,
I'm
not
quite
sure
where
it
should
be.
There's
no
point
in
last
call
on
this.
It's
done.
It's
implemented.
It's
tested
it's
in
the
clients,
so.
A
Yeah,
but
for
the
sake
of
the
process,
what
we
were
suggesting
and
we
are
trying
to
practice
this
with
every
proposal
like
I
have
created
a
pull
request
to
change
it
from
draft
to
at
least
in
review.
Obviously
it
is
implemented,
so
it's
not
good
in
review
status
as
well,
and
there
is
no
fixed
duration
that
it
needs
to
be
in
that
status.
A
So
what
it
is
merged
as
a
review,
we
can
go
ahead
and
create
a
pull
request
to
keep
it
in
last
call
and
we're
going
to
keep
it
till
there
until
it
is
deployed
on
the
main
net,
because
in
case
something
goes
wrong
when
we
have
to
make
some
smaller
changes
on
the
code.
So
we
are
just
trying
to
be
safer
here,
keeping
it
in
last
call
till
deployed
so
yeah
I'll
be
happy
to
create.
B
A
A
A
On
that
note,
for
all
our
youtube
viewers,
this
was
one
of
the
five
proposals
going
in
the
berlin
upgrade,
which
is
expected
to
be
on
the
test
net
on
second
week
of
march
and
on
the
main
net
around
mid
april,
you
may
find
recordings
of
all
other
eips
going
in
berlin
at
the
penny.
Playlist
at
ech
youtube.
A
If
you
have
any
further
question
on
any
of
these
proposals
of
this
episode,
particularly
you
may
leave
your
comment
or
ask
the
author.
His
twitter
handle
is
provided
in
the
description
section,
along
with
the
resources
for
this
proposal.
Do
let
us
know
how
you
like
this
episode
and
which
eip
would
you
like
to
see
in
upcoming
episodes?
A
Your
feedback
is
important
to
us.
You
can
share
your
feedback
and
tag
me
at
bucharan019
or
the
helium
catalyst
at
cat
hurdles
on
twitter
join.
The
ech
discord
for
latest
on
ethereum
network
upgrade.
Invite
link
is
provided
in
the
description
below
next
week.
We
will
have
eric
marks
with
us
to
talk
about
eip,
3085
wallet,
ad
ethereum
chain,
rbc
method,
so
stay
tuned
for
the
upcoming
episodes
do
hit
like
and
share.
Don't
forget
to
subscribe.
Keep
sharing
your
love
with
the
theory
of
cat
holders.
This
is
all
of
us
signing.