►
From YouTube: PEEPanEIP #118: EIP-5656: MCOPY - Memory copying instruction #EVM #smartcontract #Mcopy #ethereum
Description
Resources:
-----------------
https://eips.ethereum.org/EIPS/eip-5656
https://ethereum-magicians.org/t/eip-5656-mcopy-instruction/10890
Slides - https://docs.google.com/presentation/d/1sOoQ3LUzQMTaQWsL7qmEezvbFydfdOJhcWaEnSGoGkw/edit
PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Dencun - https://www.youtube.com/playlist?list=PL4cwHXAawZxpnKFDl1KzGOKqwux5JaLlv
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
YT Clip - https://youtu.be/mw7ktiOhX-E
Follow at Twitter
--------------------------
axic.eth @alexberegszaszi | Paweł Bylica @chfast | Charles Cooper @big_tech_sux | Pooja Ranjan @poojaranjan19
Topics covered
---------------------------
0:29 - EIP-5656 intro
1:30 - Guests introduction
7:07 - MCOPY
8:02 - MCOPY - Copies EVM Memory
9:30 - MCOPY missing piece
14:48 - How important memory copying is for Vyper?
16:42 - Why?
17:45 - Copying via loop is expensive
20:10 - Identity Precompile cost
22:22 - Anecdotes identity precompile
24:30 - eip2929 made precompile pricing cheaper
26:20 - Technicality about memory copying
29:09 - End of presentation.
29:35 - How do the MCOPY instructions compile into in terms of gas costs to other memories like identity precompile?
32:16 - What benefits do static analyzers and optimizers gain from having a dedicated MCOPY instruction in the EVM?
35:09 - Why 5b instead of 5c as a specific opcode slot?
37:13 - Backward compatibility?
40:02 - EOF will solve some of the problems
41:20 - Security consideration
41:48 - Testing performance of EIP-5656
43:45 - Message for the community from Ipsilon & Vyper
A
A
A
A
As
some
of
you
may
know,
we
like
to
kick
off
the
talk
with
guests
introduction
briefly
about
their
professional
background
and
their
experience
with
the
ethereum
ecosystem.
It
will
be
followed
by
a
presentation
to
explain
the
EIP,
and
perhaps
we
will
have
some
time
for
question
and
answer
so
may
I
invite
Our
Guest
to
say
a
few
words
about
themselves.
B
Hello,
my
name
is
Pavel
balita
and
well.
First
of
all,
thanks
very
much
for
having
us
again
and
as
I
heard
like
180
episode,
I
mean
this.
That's
a
lot
so
also
big,
thanks
Puja
for
all
the
work
you've
done
so
far
with
this,
and
it's
really
amazing
I'm,
currently
working
on
evm
Research
in
the
Epsilon
team,
at
ethereum,
Foundation
I've
been
working
with
evm
for
a
long
time.
I
started
in
late
2014
also
experimenting
with
some
possible
optimizations
for
evm,
and
my
kind
of
Journey
and
professional
work
continues
since
then
around
this
technology
yeah.
C
Yeah
like
for
this
Bible,
said
Thank
You
Pooja.
This
doesn't
work
and
happy
to
be
back
again,
as
Paul
said,
I'm
also
part
of
the
Epsilon
team,
I
didn't
say
this
early
as
Pavel,
but
around
like
late
2015
and
have
been
contributing
since
then
to
evm
research
as
well
as
solidity
language
design.
In
the
past
two
years,
I've
been
mostly
really
just
focusing
on
the
evm
research
side.
C
D
Hey
yeah,
I'm
Charles
I
am
do
a
lot
of
work
on
viper
and
it's
been
my
main
role
for
the
last
couple
years
now
and
Viper,
as
you
may
know,
actually
uses
memory.
A
lot
and
I
think
I
was
talking
with
Asic
sorry
Alex
a
year
to
go
about
this
at
devconnect
and
I
was
like
you
know,
it'd
be
cool.
If
we
had
this
memory
copy
instruction
and
he
was
like
yeah,
we
have
the
Erp.
D
We
should
just
kind
of
push
it
so
in
the
a
few
months
ago,
I
think
I
realized
that
Cancun
was
coming
up
and
so
I
started
kind
of
pushing
this
heavily
on
all
cortex
calls
and
so
I'm
pretty
happy
that
you
know
we
were
able
to.
You,
know
kind
of
you
know
finalize
the
EIP
and
everything
and
get
the
support
around
it
that
we
needed
and.
A
D
You
know
it's
a
really
nice
instruction
and
it
solves.
You
know
a
lot
of
kind
of
performance
and
similar
problems
that
you
have
when,
when
you
start
to
write,
write
code
for
the
evm
so
yeah,
and
thanks
for
having
me
on
this
map,
this
is
my
first
time
on
this
format.
I
understand
it's
been
going
on
for
a
long
time,
so
so,
thanks
for
putting
it
all
together.
A
A
In
the
past
we
have
discussed
eip3860
limit
and
meter
init
code
eip3855
push
hero,
instructions,
eip3540,
eof,
evm,
object
format.
Most
of
them
are
deployed
with
earlier
upgrades.
So
if
you
missed
any
of
these
talks
check
the
links
available
in
description.
Moving
on
to
today's
talk
without
further
Ado,
let's
peep
in
so.
B
Yeah
I
will
start
with,
like
brief
introduction,
what
what
this
is
all
about.
I
was
actually
checking.
Where
did
we
start
working
on
this,
because
we
have
record
of
wrong
reviewing
eaps
waiting
for
being
included
in
network
upgrades,
but
it's
it's
not
so
bad
I
think
we,
we
did
worse.
I,
think
it
started
somewhere
in
the
beginning
of
2021
so
and
this
more
people
also
involved
in
preparing
this.
So
please
check
the
the
IP
itself
with
the
all
the
authors
list,
but
back
to
the
the
subject
so
yeah.
B
This
is
not
a
very
sophisticated
change.
I
think
we
can
compare
it
in
the
complexity
to
how
it
still
compares
to
like
Pro
zero
instruction
that
was
added
in
the
previous
upgrade.
This
is
instruction
that
helps
with
copying
some
areas
of
evm
memory,
which
is
internally
available
to
the
executive
program.
B
So
yeah,
the
AP
number
is
5656,
and
this
is
scheduled
for
Cancun
I.
We
don't
really
expect
any
surprises
and
like
last
minute,
removal
from
that,
although
I'm
not
really
sure
what
is
the
the
current
estimated
data
of
the
of
the
shipment
I
think
people's
they
might
want
to
to
do
it
this
year,
but
I'm
not
really
sure.
That's
the
the
current
design.
B
If
anyone
wants
more,
please
share
that,
but
I
think
this
is
has
been
implemented
in
in
the
clients
for
longer,
because,
as
I
said,
the
complex
is
that
it's
pretty
low
and
it
stays
within
the
evm.
So
this
change
doesn't
really
touch
anything
outside,
so
this
makes
it
relatively
easy
to
to
implement
so
yeah.
So
this
is
simple
instruction
and
it
copies
memory,
not
so
much
I.
Think
again,
this
is
not
really
surprising
how
it
works.
It's
mostly.
B
The
instruction
takes
three
operands
one
describes
like
the
source
index
of
the
memory
to
be
copied.
One
describes
the
destination
index
of
the
memory
world
where
the
area
will
be
copied
to,
and
I
also
specify
the
the
size
of
this
area.
I
think
it's
explained,
yeah
expressed
in
a
number
of
bytes
I,
won't
go
into
like
deeply
into
details.
What
exactly
these
things,
how
these
things
exactly
specified
but
I?
B
Don't
think
that
should
be
complicated
to
understand
the
details
and-
and
we
also
like
play
a
bit
attention
to
the
what
what
exactly
you
can
copy
with
so
just
wanted
to
present
that
this
instruction
handles
copying
no
overlapping
areas
of
memory.
They
also
can
handle
overlapping
ones,
and
you
can
also
copy
backwards.
So
there
are
not
really
restrictions
how
we
can
use
that
also
the
the
regular
gas
cost
applies.
So
if
the
copying
of
the
memory
would
extend
the
memory
itself,
it
will
pay
this.
B
This
additional
cost
related
to
how
evm
memory
is
priced
and
yeah.
We
can
talk
about
different
areas
of
memory
in
the
VM,
so
starting
from
the
top,
we
have
call
data,
which
is
the
input
data
the
evm
execution
will
get.
This
comes
from
the
transaction
from
a
parent
call
of
current
execution
and
we
can
also
have
access
to
return
data
which
is
kind
of
the
opposite.
This
is
the
buffer
from
the
data
that,
like
a
child,
call,
would
return
to
you,
and
both
of
these
are
reads
only
so.
B
You
cannot
modify
it,
but
you
can
read
pieces
of
these
and
on
their
like
basic
execution
level
of
evm.
We
have
a
stack
where
the
operands
of
the
instructions
unhandled
and
we
have
the
memory
which
we
mentioned
already
and
finally,
there's
also
a
code
which
means
the
code
of
the
current
contract
that
is
being
executed.
B
So
code
is
important
as
well,
because
it
kind
of
have
this
role
of
static
data
to
the
program,
and
this
is
also
read.
Only
the
difference
between
code
and
call
data
and
return
data
is
that
the
call
data
at
return
data
is
kind
of
coming
from
outside,
and
the
current
program
can't
really
control
it.
So
it's
like
external
inputs
and
to
the
execution.
B
The
code
is
something
that
the
contract
owns
and
this
can
be
used
for
internal
static
data,
something
like
that
so
and
there's
different
instructions
that
mostly
allows
you
to
move
this
data
between
these
different
kind
of
memories,
and
so
we
can
bring
some
information
directly
to
the
stack.
For
example,
call
data
load
will
bring
a
piece
of
data
from
the
call
data
to
the
stack
and
there's
also
direct
instruction
that
can
copy
as
some
part
of
call
data
to
the
memory.
B
So
we
can
kind
of
skip
the
stack
for
this
and
similarly
for
return
data
this
way
to
copy
to
the
memory,
but
you
can
notice
that
there's
no
way
to
actually
bring
the
duration
data
directly
to
the
stack.
That
is
also
something
we
can.
We
may
consider
missing
in
the
current
design.
The
more
basic
instructions
are,
these
that
moves
stuff
between
stack
and
between
memory.
So
we
have
amster
and
M
load
instruction
for
these
and
finally,
there's
a
way
to
copy
the
copy.
B
Some
data
from
the
code
to
the
memory
I
think
originally,
that
was
kind
of
imagined
to
be
used
for
contract
creation,
mostly
but
I,
think
currently
languages
use
that
also
to
start
some
smaller
pieces
of
of
data
I'm,
not
sure
we
don't.
We
want
to
actually
have
the
way
to
to
move
it
directly
to
the
stack,
but
I
will
leave
this
to
the
Alex
and
Trust.
B
Maybe
later
comment
on
this
and
what
M
Copy,
how
the
M
Copy
fits
into
this
model
is
that
it
actually
copies
from
memory
to
memory,
so
this
kind
of
improves
efficiency.
If
you
really
wanted
to
do
such
operations,
otherwise
you
would
need
to
kind
of
use
alternatives
to
this,
which
are
much
more
expensive,
currently
yeah.
B
C
Yeah
I
wanted
to
to
maybe
add
before
we
get
to
the
next
slide,
that
why
would
like
mem
Copy
being
used?
You
know
generally
in
languages
and
I'm,
pretty
sure
Charles
gonna
explain,
maybe
a
different
Viewpoint,
because
Viper
Works
quite
differently
to
the
solidity.
But
the
solidity
example
is
you
know,
looking
at
this
chart
how
you
can
obtain
data.
C
But
if
you
think
about
internal
calls
within
the
contract
itself,
you
may
be
in
more
of
a
need
to
manipulate
memory
and
create
like
data
structures.
You
know
specifically
where
you
may
be
able
to
to
moving
memory.
This,
of
course,
not
only
applies
to
internal
calls,
but
with
many
of
the,
if
you
only
focus
on
external
calls,
then
you
may
have
a
better
chance
at
utilizing.
C
Written
data
copy
or
call
data
copy,
and
the
cases
where
this
usually
comes
up
is
when
handling
a
race
and
a
specially
variable
length
data
yeah
I
just
wanted
to
give
you
know
some
kind
of
an
idea.
Why
would
memory
copying
be
happening
at
all,
but
on
the
next
slide
we
will
explain.
You
know
what
options
there
are
today
too,
to
actually
solve
this
problem,
I'm,
not
sure
Charles.
If
you
want
to
add
your
view
on
on
viper,
you
know
how
important
memory
copying
is
for
Viper.
D
Yeah
memory
copying
is
super
important
for
Viper
and
it's
like
kind
of
happening
all
the
time.
Basically
anytime,
you
want
to
move
a
data
structure
so
like
during
ABI
encoding
you're
going
to
like,
if
you
see
return
something,
then
that's
going
to
copy
data
into
a
return
buffer,
usually
or
if
you
have
an
internal
call.
D
One
thing
is
that
Viper
generally
stores
more
things
in
memory,
so
like
an
array
or
a
structure,
a
bright
string,
those
those
things
are
always
going
to
be
in
memory
and
then
Viper's
internal
calling
convention
also
uses
like
these
batch
memory
copies.
So
the
kind
of
the
places
where
you
see
memory,
copies
that
are
going
to
happen
are
like
internal
calls,
assignments,
return
statements
and
a
bunch
of
built-ins
also
do
that
so
like.
D
If
you
want
to
you,
know
concatenate
two
bright
strings
together
or
something
like
this
yeah
I
mean
so
you
know,
after
M,
Copy
was
kind
of
tentatively
approved
for
Cancun.
We
have
some
internal
routines
and
Viper,
which
for
copying,
bytes
and
I,
replace
those
just
from
the
identity,
pre-compile
and
also
there's
some
there's
some
Loops
that
are
kind
of
unrolled.
For
you
know,
copying
structs
around
and
stuff
like
this
and
byte
code.
D
Size
like
came
down
quite
a
lot
like
three
to
five
percent
and
gas
is
also
improved
yeah
so
from
the
compiler
perspective
having
M
Copy
instead
of
needing
to
there's
actually
a
question
in
the
chat
right
now,
why
not
M
load
and
dupe
and
M
store?
Well,
it's
because
it's
a
lot
more
expensive
and
it
takes
a
lot
more
code
so,
like
maybe
I,
should
just
like.
D
Oh
yeah,
we
have
the
Y
slide
next
like
to
give
you
an
idea
like
an
M
load
or
M
store
thing
is
going
to
take
like
9
to
12
gas
I.
Think
that's
just
12
gas
to
copy
a
single
word
and
then
like.
If
you
have
to
do
less
than
a
word
or
more
than
a
word
or
it's
not
a
line,
then
you
have
to
do
more
things
to
like.
You
know,
read
and
write
back
these,
these
unaligned
things,
and
it
also
costs
a
lot
in
terms
of
byte
code.
D
So,
like
a
loop
you're,
your
very
most
basic
Loop
is
going
to
be
like
I,
think
17
to
30
bytes
of
bytecode,
which
is
a
lot
every
time
that
you
want
to
copy
stuff.
And
if
you,
even
if
you
unroll
the
loop
you're
still
looking
at
like
minimum
of
four
bytes
to
copy
a
single
word,
anyways
I
think
that's
kind
of
like
the
compiler
perspective,
plus
some
kind
of
preview
of
the
next
slide.
So
I'll.
C
D
C
D
D
Using
M
Copy
allows
us
to
simplify
some
code
and
some
optimizations
and
then
so
like
currently
the
way
to
do
the
identity.
Sorry
to
do
a
memory
copy
is
like
you,
use
the
identity
pre-compile,
which
is
like
the
pre-compile
address
four
right,
and
that's
just
like
a
special
address
that
just
that's
the
identity.
It
returns
the
input,
and
so
that's
like
very
commonly
used
right
now
to
do
memory
copies,
but
it
kind
of
has
a
couple
problems
and
they
they
all
fall
under
this
umbrella
of
it's
like
and
I.
D
Think
Alex
and
Pablo
can
talk
about
this.
A
lot
more,
but
they'll
fall
under
this
umbrella
if
it's
like
a
pre-compile,
which
means
that
it
actually
functions
as
a
call
and
like
if
you
look,
it's
easiest
to
understand
this
I
think
by
going
and
looking
at
like
a
client
implementation
like
death
or
evm1
or
Pi
VM
or
something,
and
if
you
like,
look
at
how
a
call
is
implemented,
it's
like
super
complicated.
D
You
have
to
like
construct
a
calling
context.
You
have
to
allocate
memory.
You
have
to
like
copy
these
buffers
back
and
forth.
You,
like
you,
have
to
copy
this
memory.
Buff
the
The
Source
buffer
into
the
you
know,
call
data
buffer
for
the
child,
call
and
then
copy
back
into
the
return
data
buffer
and
all
this
stuff,
and
you
have
to
touch
the
address
and,
in
fact,
I
think
most
clients
actually
have
like
a
special,
a
special
Branch
where
they
look
up.
D
Return
data
copy
call,
data
copy
code
copy
is
an
overhead
of
three
gas.
It's
like
this
massive
pricing
differential
that
can
also
change
if
like
and
that
100
gas
just
comes
out
of
the
fact
that
it's
like
considered
a
warm
contract
from
the
perspective
of
like
what
is
that
the
VIP
2019,
the
warm
cold
addresses,
and
so
it
just
costs
100
guests
to
touch
the
address
and
then
allocate
all
these
extra
data
structures
which
you
need
and
then
the
other
thing
is
like
when.
D
D
C
Yeah
I
may
extend
this
with
some
anecdote
or
maybe
just
like
an
opinion
piece,
even
going
back
to
the
origins
of
like
this
identity,
pre-compile
so
I.
Think
generally,
there
has
been
like
always
a
case
of
debate.
What
level
of
complexity
of
a
feature
would
qualifies
an
opcode
versus
a
pre-compile,
and
even
before
that,
if
you
look
at
like
early
versions
of
the
evm
design,
there
were
no
pre-compass.
All
of
these
edible
features
were
just
part
of
the
instruction
set,
so
something
like
EC
recover.
That
was
an
evm
instruction.
C
You
know
catch
act,
256
that
was,
and
still
is,
an
instruction
chat
2.
It
was
also
an
instruction
and
then
I
mean
I
wasn't
there,
but
it
seems
like
you
know.
There
was
a
decision
to
move
some
of
these
out
because
they
were
considered
to
be
too
complex
to
be
instructions,
and
maybe
there
were
some
other
plans
with
them
and
it
feels
like
the
cat
check
instruction,
which
is
kind
of
like
an
outlier.
C
It's
remained
an
instruction
because
it
was
deemed
to
be
really
important
and
by
importance,
I
mean
even
a
lot
of
like
the
solidity
design
is
based
around
the
ketchup
instruction
and
so
looking
up,
hashmap
or
like
map
data
structures.
It
heavily
relies
on
ketchup
and
then
I
suppose
it
was
realized
that
memory
copying
was
expensive
and
identity
as
a
pre-compile
was
introduced,
and
at
that
point
solidity
only
used
identity,
pre-compile
for
memory
copying
and
everything
was,
you
know,
kind
of
all
right
until
the
Shanghai
attacks
and
at
that
point
all
of
the
cold
pricing.
C
C
In
any
case,
you
know
once
it
was
reduced
in
2929.
Solidity
technically
could
have
used
identity
pre-compile
and
there
have
been
a
number
of
people
requesting
it
to
make
it
like,
at
least
this
slide,
based
on
the
the
size
of
the
data
structure,
because
then
they
still
like
a
cutoff
above
or
below
the
memory.
Copying
Loop
is
still
better.
C
C
You
know
this
earlier
question
I
raised
what
is
like
a
good
level
of
complexity,
what
fits
fits
as
an
evium
instruction
versus
pre-compile
and
I
kind
of
feel,
like
M
Copy,
you
know,
it's
probably
explained
it's
so
simple
and
relates
to
already
existing
semantics
and
evm.
It
kind
of
really
feels
like
it's
satisfaction,
as
opposed
to
be
a
pre-compiled.
The
other
side
of
this
argument
is,
if
you
look
at
the
pre-compiles,
the
identity.
C
D
By
the
way,
I
think
that,
maybe,
like
you,
asked
like
you're
pointing
out
that,
like
some
decision,
was
made
early
on
to
make
it
like
a
pre-compiled,
non-code
and
I,
wasn't
there
but
like
if
I
were
I'm
just
trying
to
provide
some
rational
like
if
I
were
there
or
if
I
were
like
designing
the
evm
from
scratch
or
something.
There
is
one
technicality
about
memory,
copying
which
makes
it
slightly
more
complicated
than
the
other
copy
instructions
returned
in
a
copy
call
data
copy
code,
copy
they're,
not
copying
from
memory,
so
there's
no
transfer
overlap.
D
D
So
when
we
were
doing
the
spec
and
kind
of
actually
discussing
it
like
that,
came
up
as
like
what
happens
with
overlaps
and
like
after
you,
you
talk
about
it
or
think
about
it.
For
like
a
few
minutes,
like
actually
most
client
implementations,
will
most
implementations
of
memory
copy
will
do
the
right
thing,
which
is
that
it
acts
as
if
you
copy
the
input
buffer
into
a
temporary
buffer,
and
then
you
copy
the
temporary
buffer
to
the
destination
buffer,
which
prevents
any
like
kind
of
weirdness
going
on
from
the
overlap.
D
But
you
know,
if
you
were
doing
this
thing
from
scratch,
you
might
be
like
well
contract
calling
already
does
that
it
already
like
copies
it
to
another
buffer
and
then
copies
it
back
so
like,
let's
not
introduce
an
OP
code
and
let's
just
make
this
kind
of
clever
pre-compile,
which
just
returns
this
input,
and
this
for
the
reasons
outline
in
this
slide
that
Mexican
people
have
been
talking
about.
It
makes
more
sense
to
have
it
as
an
OP
code.
I
think
that
may
have
been
like
a
consideration
as
to
why
it
was
originally
pre-compiled
and.
D
D
The
way
that
we're
copying
memory
is
actually
going
to
do
the
copy
a
linear
way,
instead
of
creating
this
temporary
buffer
and
there's
a
technique
for
doing
this
like
if
you
look
at
the
docs
for
like
men,
move
in
in
C
plus
or
C,
it
actually
just
like
kind
of
copies
it
backwards.
If,
like
some
of
the
conditions,
are
written
that
basically
acts
like
it.
So.
B
D
Isn't
actually
a
temporary
buffer?
That
makes
it
kind
of
work
like
it
is
and
in
the
go
run
time
and
other
language
runtimes
that
I
looked
at.
They
do
the
same
thing:
there's
no
temporary
buffer,
but
if
there
were
then
there
could
be
some
kind
of
Dos
risk
where
you
can
force
somebody
to
copy
a
lot
more
memory
than
they
actually
meant
to
or
are
paying
for,
with
the
amount
of
gas
that
they're
paying.
A
Well,
thank
you
so
much.
It
was
really
nice
presentation
and
I
must
say
that
it
was
easier
to
see
it
through
the
diagram
than
going
through
the
proposal,
especially
for
high
level
understanding,
I
suppose
the
presentation
may
have
helped.
Thank
you
for
your
effort,
I.
We
have
a
few
questions
here
in
the
chat
santosha.
If
you
would
like
to
maybe
relay
your
questions.
E
C
So
pricing
is
is
based
on
Words
and
an
even
word
is
32
bytes
and
the
price
itself
is
is
fairly
simple.
It's
just.
We
have
a
base
cost
for
the
instruction,
which
is
three
and
then
we
charge
three
gas
for
each
of
the
the
words
copied
and
as
Pebble
mentioned.
If
we
do
expand
the
memory
to
like
a
new
area,
then
you
do
pay
the
regular
expansion
costs
as
well.
In
the
IP.
C
We
do
have
an
example:
calculation
for
copying,
256
bytes
and
for
that
size
of
of
area
with
like
an
unrolled
Loop,
it
would
cost
roughly
at
least
96
gas
I'm.
Pretty
sure
you
can
save.
You
know
if
a
few
gas
here
in
there,
but
it
would
be
on
the
order
of
like
90.
You
know
at
least
like
three
times
as
much
as
with
the
EIP,
so
with
the
IP,
it
would
be
around
27
with
an
unrolled.
Loop
would
be
96
and
in
the
current
case,
with
the
I
did
the
pre-compile.
C
It
would
cost
157
gas
and
of
course
the
bulk
of
this
157
is
100
for
the
call
cost.
So
if
you
would
copy
larger
areas,
then
you
know
the
base
costs
wouldn't
increase,
so
the
difference.
Would
it
be
a
significant
you
know
comparing
the
pre-compiled
versus
the
the
instruction,
but
it
is
always
significantly
more
expensive
to
use
the
the
pre-compile,
and
then
we
mentioned
the
cip2929
several
times,
which
is
the
change
which
made
the
patio
pre-compile
usable
again
before
that
change.
C
I
think
we
have
been
in
the
the
pricing
Paradigm,
maybe
for
like
four
years
before
that,
so
between
Shanghai
changes
and
2929
I
think
it
was
like
three
four
years
have
elapsed
and
during
that
time
this
was
so
expensive
that
it
costs
would
have
cost
like
over
700
gas
for
the
same
coupling.
This
is
just
you
know
a
rough
example
to
to
give
you
the
pricing,
so
it's
basically
like
3x,
cheaper
than
mlodem
store
and
like
6X,
cheaper
than
the
identity
pre-compile.
But
all
of
this
really
depends
on
your
individual
use
case.
B
C
It
may
be
duplicated
in
the
stack
from
like
far
away
so
it
may
become
more
challenging
to
figure
out
if
the
particle
call
is
to
die
identification
Empire-
and
you
don't
have
any
of
these
issues
with
the
instruction,
because
it's
it's
just
clear
what
the
instruction
is.
So
it
definitely
is
much
easier
to
enter
in
static
analyzers,
but
I'm.
Pretty
sure
that
you
know
there
are
a
number
of
like
highly
Advanced
analyzers,
who
can
deal
with
the
current
solution.
The
DM
copy
instruction
will
make
it
cheaper
and
easier
to
analyze
contracts,
utilizing
it
of.
D
Course
another
thing
about
analysis
is
like
is
also
kind
of
a
diff.
It's
like
a
defensive
consideration
which
is
like
protecting
against
forward
changes
in
call
semantics
so
like.
If
calls
in
the
future
have
some
kind
of
side
effects,
then
you
need
to
be
able
to
model
those
side
effects
and
actually
right
now
calls
even
a
static
call
already
does
have
a
side
effect
which
is,
is
it
adds
the
called
contract
into
like
the
access
list,
so
I
mean
just
going
continue
about
access
list
like
there's
already
different
transaction
types
with
access
lists?
A
D
B
I
think
I
remember
quite
that
I
think
originally
that
was
different
number
but
yeah.
That's
what's
Charles
already
sent
at
some
point.
We
realize
we're
actually
struggling
with
allocation
of
op
codes
because
well
this
kind
of
natural,
maybe
as
you
mentioned
5c,
would
be
like
more
natural
and
that
actually
causes
problems,
because
whenever
there's
like
some
additional
AP
that
maybe
it
does
something
different
proposes
different
instructions,
it
happens
also.
It
selects
this
natural
number
that
is
following
existing
crop
codes
and
I.
B
That's
probably
the
easiest
part
to
change
it,
but
you
need
to
kind
of
correct
all
the
testes
already
create
for
this
EAP
and
so
on,
and
there's
like
big
coordination
issue
with
these
and
finally
Dano
who
is
working
on
the
visual
client
or
beso.
Just
come
up
with
the
big
table
of
op
codes,
eaps
that
are
actually
considered
for
inclusion,
and
we
just
sorted
this
by
the
current
proposal.
B
So
everyone
gets
like
its
number
for
now
and
we
don't
have
to
go
back
to
this
and
yeah
I
would
need
to
open
up
some
implementation,
but
I
think
there's
there
won't
be
any
Gap
I
think
that's
already
filled
with
something
else,
probably
for
Cancun,
but
I
I
might
be
a
bit
drunk
about
if
it's
actually
about
the
the
transit
storage.
But
it's
like
if
this
is
the
case.
Good.
E
B
Not
sure
who
wants
to
answer
this
so
I
can
say
only
this
that
yeah
it's
it's
not
like
fully
Backward
Compatible,
for
the
reason
that
you
can
kind
of
I
don't
know
how
to
put
it
like
artificially
try
to
use
up
codes
that
that
is
already
unassigned
to
anything
any
instruction
and
this
other
side
opcode
has
defined
semantic,
and
it's
just
aborts
execution
at
this
point,
and
we
are
kind
of
changing
the
the
behavior
of
this.
This
upgrade
number
from
the
data.
That's
activated
right,
so
that's
the
breaking
point
I'm,
not
sure.
B
Yet
we
kind
of
we
dig
deeply
to
find
if
anything
is
broken
by
this
and
I,
don't
recall
if
we
did
it
for
previous
changes
as
well,
so
like
for
regular
contracts
that
rather
not
not
an
issue.
It's
kind
of
you
would
need
to
design
it
specifically
to
be
broken
by
this,
because
we
kind
of
design
already
decided
that
if
you
want
this
specific
behavior
that
you
want
to
abort
execution
at
some
point
to
which
kind
of
every
unassigned
op
code
works
for
this.
B
But
we
picked
one
of
these
and
we
decided
we'll
not
ever
assign
the
extraction
to
it,
and
this
is
this
Fe
op
code
and
the
rest
is
kind
of
either
you
it's
really
messy
contract,
or
this
like
it's
done
on
purpose,
just
to
be
broken
by
these.
So
that's
I
can
comment
about.
Maybe
Alex
and
Trust
has
a
bit
more
experience
with
these
I.
B
A
D
C
Here's
the
time
to
to
plug
the
eofd
EDM
object
format
which
actually
solves
this
problem,
because
you
can
only
deploy
contracts
with
the
assigned
instructions,
and
so
this
this
problem
wouldn't
actually
arise.
But,
as
Char
said,
this
problem
has
been
there
and
since
the
beginning-
and
there
are
certain
cases
of
introducing
changes
to
to
instructions,
reading
instructions
where
this
has
been
considered
more
thoroughly.
C
A
Very
well,
thank
you.
So
much
I
think
we
can
take
this
opportunity
to
even
invite
contractor
developers
to
let
us
know
let
your
team
know
about.
If
there
is
any
contract
breaking
because
of
you
know
the
backward
compatibility,
if
they
do
not
have
it
and
they
want
to
integrate
five
six
five
six
and
it's
breaking
their
contract.
A
They
can
let
the
team
know
more
about
it
and
on
uof
I'm
happy
to
share
that
we
are
trying
to
get
Dano
on
these
calls,
sometimes
in
October,
to
maybe
talk
a
little
bit
more
about
UF
proposals
that
the
team
are
building
on.
I
know
it's
time
to
wrap
up.
I
have
a
few
small
questions
that
I
quickly
want
to
take
it
up
with
the
team.
As
on
the
proposal.
Currently,
the
security
consideration
is
PBA.
I
was
just
wondering
if
there
is
anything
specific
under
security
consideration
that
implementers
should
keep
it
in
mind.
I.
A
Great
and
about
testing
I
was
wondering
if
the
proposal
was
included
with
devnet
8
I
know:
devnet
9
is
going
to
be
launched
next
week
and
hopefully
it
will
be
there
because
it's
going
to
be
a
feature
complete
upgrade.
So
was
it
included
in
termnet
8?
If
so,
was
the
performance
as
expected
or
anything
that
may
have
let
a
change
in
the
spec
of
present
EIP?
That's
a.
B
Good
question
I,
don't
think
I
have
full
information
about
it.
The
proposal
is
definitely
part
of
devnet
8
and
I
can't
still
really
how
early
it
was
included,
but
probably
one
of
the
earliest
devnets.
Actually,
because
to
my
knowledge,
that's
one
of
the
earliest
eaps
that
were
implemented
for
curriculum
upgrade.
So
we
can't
like,
as
the
Epsilon
team,
we
don't
really
actively
participate
in
devnets
because
we
don't
maintain
a
client
to
participate
in.
B
So
what
I
can't
tell
how
much
it
was
exercised
on
devnet,
but
on
our
side
we
are
pretty
confident
in
that
like
testing
coverage,
because
we
created,
like
I,
think
big
suit
of
tests
case
with
all
the
combinations
of
different
kind
of
overlapping
and
yeah.
So
from
one
hand
the
instructions
relatively
simple,
but
we
still
exercise
this.
B
But
these
are
like,
let's
say,
static
tests
in
a
Json
format.
You
can
run
your
client
on
the
devnet.
I
think
work
a
bit
differently,
but
there's
usually
some
kind
of
spam
transactions.
Palm
generators
that
do
some
inject
a
lot
of
activity
at
the
devnet,
but
I
can't
really
confirm
if
the
M
Copy
instruction
was
exercised
by
this
and
how
like.
What's
the
stick.
A
I
would
consider
here.
No
news
is
good
news.
If
no
client
team
has
tried
to
reach
out
to
the
author
Perhaps,
it
is
working
as
expected,
if
included
otherwise,
we'll
get
to
know
more
next
week
when
we
have
definite
nine
live
all
right.
It's
time
to
wrap
up.
Do
you
guys
have
any
message
for
smart
contract
developers
or
users
in
general,
yeah.
C
I
think
there's
maybe
one
message
from
the
Epsilon
team
and
yeah.
Maybe
Charles
can
also
speak
regarding
wiper
but
yeah
I
think
in
epsilon
we
would
be
happy
to
hear
any
feedback
on
on
an
editor
like
any
other
missing
feature
or,
if
you're
not
happy
with
on
the
evm
it's
probably
mentioned
in
the
beginning.
We
do
review
external
proposals
and
we
also
have
like
a
number
of
proposals
ourselves.
D
For
VAR
preside,
I,
think
I'm,
pretty
I'm
personally
pretty
happy
about
the
CIP
and
I'm
excited
for
it
to
go
in
and
it's
going
to
bring.
You
know
some
performance
improvements
that
you
know.
Maybe
you
won't
think
about
every
day,
but
will
be
passed
on
Smart
contract
developers
and
users
in
terms
of
byte
code
size
and.
A
Out
awesome,
Alex
chance.
We
thank
you
for
joining
us
on
bitaneep
and
talking
about
execution
layer
proposal
5656.
We
look
forward
to
follow
devnet9
and
public
test
net
to
see
EIP
5656
deployed
on
the
main
net,
but
then
can
upgrade
on
this
note.
Thanks
to
all
our
YouTube
viewers
for
watching
and
podcast
subscriber
for
listening,
this
Duncan
special
episode
on
eat
get
her
this
channel.
Should
you
have
any
question
on
this
or
any
other
topic?