►
From YouTube: EOF Breakout Room #2
Description
A
I'll
share
my
screen
and
we
can
see
how
that
works.
So
this
is
the
checklist
right
now.
These
are
the
EOS
yips
that
we've
been
working
on
and
the
open
issues.
So
the
first
one
is
just
renaming
all
the
UF
Eeps
to
have
this
prefix.
A
Sounds
good
yeah,
so
I
mean
in
the
meantime
we
can
go
ahead
and
start
going
through
some
of
these
things.
The
first
one
is
more
of
just
operational
thing
having
this
eof
prefix
for
all
of
the
UF
Eeps
I
think
this
makes
sense.
C
She's
gonna
have
the
the
reason
this
came
up
because
there
was
no
nice
document
like
this
listing
out
what
is
considered,
and
you
know,
like
a
entry
point,
people
could
find
all
the
editing
information,
and
so
what
people
did
they
were
rather
grapping
for
UF
on
eip3
on
the
torque
and
which
is
currently
not
possible
right.
A
Makes
sense
I've
been
trying
to
push
people
to
this
page
when
I
can
as
well,
just
because
I
think
that
this
is
a
good
overview
place,
but
yeah
I
would
be
good
just
so
they
can
grab
through
it
so
yeah.
If
you
guys
want
to
accept
this
PR
to
make
the
modification
that
would
be
great
first
Eve
to
talk
about
is
35
40,
the
object
format,
V1
first
question:
Moon
generic
contract
creation
rules
from
3670
foreign.
B
So
that's
later
so
yeah
I'm
for
like
moving
what's
possible
to
the
to
the
main
one
and
I
think
the
the
code.
Validation
will
be
just
smaller
because
of
that
so
yeah.
A
Yeah
yeah
makes
sense
I'm
in
favor
of
that
foreign.
A
Okay:
next,
we
have
a
question
about
whether
we
should
forbid
eof
deploying
Legacy
contracts,
I
think
yes,
but
I'm,
also
like
very
far
on
the
spectrum
of
generally
restricting
what
you
know,
people
can
do
with
respect
to
Legacy.
So
does
anyone
have
an
argument
for
allowing
you
up
to
deploy
Legacy
contracts.
C
A
C
C
But
basically
the
current
limit
would
apply
to
everything,
but
we
did
had
a
discussion
and
both
of
the
context
of
30,
3860
and
eof.
C
What
if
the
limit
would
be
changed.
So
what
the
3860
says?
It's
the
creation
code
limit
is
twice
of
the
deployed
code
limit
and
you
were
thinking
what,
if
we
would
actually
modify
both
of
these
to
be
slightly
bigger
than
it
is
today.
That
is
like
another
discussion
to
be
hit
at
some
point.
D
B
Makes
sense
it
was
confusion
was
about
like
what
yeah?
What
does
this
mean?
I
think
we
we
always
intended
to
be
like
that
whole
thing
yeah,
but
maybe
that's
I,
guess
we
might
need
to
read
the
specs
to
make
sure
it's
clear.
C
Yeah
I
mean
for
that
I
believe
you
need
to
investigate
the
origins
of
the
limit
why
the
limit
was
introduced
and
what
it's
supposed
to
cover
and
restrict
and
I
think
it
was
more
about
straight
State
growth
and
not
about
like
drug
test
analysis,
but
if
it
would
be
only
for
covering
like
the
jump
test
analysis,
then
of
course
it
would
make
sense
to
say
that
it
only
covers
the
code
section,
because
that's
the
only
one
which
would
be
affected
yeah.
C
But
the
main
question
in
this
is:
are
we
even
open
to
complicate
this
limit
so
like
Erp
170?
Are
we
hoping
to
complicated
such
that
it
wouldn't
cover
everything,
but
sections
and
I
think
the
likely
answer
is
no
because
that
seems
like
seems
like
a
quite
a
complex
rule
set,
but
maybe
that
that's
something
we
have
to
answer.
A
I
would
also
agree
that
it
would
be
better
to
avoid
complicating
this
170
rule
set
at
least
for
now,
but
yeah
I
guess.
I
also
was
thinking
that
the
code
size
limit
was
originally
in
place,
with
the
assumption
that
jump
dust
analysis
was
not
linear
in
cost,
so
in
that
sense
it
would
make
sense
to
just
do
it
over
the
code
sections
but
yeah
I
think
for
now
my
preference
would
be
to
just
stick
with
what
exists
there
and
run
the
limit
across
the
whole
container.
D
A
C
Think
it
was
not
only
for
that,
but
also
the
state
growth,
because
I
think
it
was
stage
growth
in
the
sense
that
some
codes
were
not
well
priced
and
the
bigger
it
animated
containers.
You
could
craft
much
bigger
code
abusing
those
OP
codes,
so
I
don't
think
it
was
related
to
jump
test,
but
it
would
be
yeah.
We
should
really
ask
you
know,
maybe
Martin.
C
A
Okay,
anything
else
on
3540
that
we
should
discuss.
A
Okay,
3670
UF
code
validation.
We
didn't
mention
this,
but
I
assume
that
this
points
will
also
involve
removing
the
contract
creation
rules
from
the
code
validation.
So
the
main
thing
to
update
with
3670
now
is
to
reject
the
deprecated
op
codes
call
code.
We
you
know
mostly
already
accepted.
That's
going
to
be
deprecated
has
been
deprecated
for
a
long
time.
Self-Destruct
I
guess
is
the
more
questionable
thing.
Should
this
be
deprecated?
Should
it
not
be
deprecated?
D
C
I
guess
I
internally
expressed
my
opinion.
It's
a
call
code
I'm,
definitely
in
favor
of
because
who
needs
call
code
self-destruct.
My
opinion
was
that,
because
it's
still
floating
in
the
air
I
think
a
final
decision
of
about
that
can
only
really
be
made
once
there's
more
clarity.
What
the
future
of
self-destruct
gonna
be,
but
I'm,
leaning
more
towards
you
know
just
just
restricting
it,
because
it
can
be
added
later.
A
Yeah
I
was
also
leaning
pretty
hard
in
restricting
it,
but
now
I'm,
like
questioning
slightly
more
with
these
people,
wanting
to
use
this
as
like,
like
a
pay-all
type
of
op
code,
and
so
even
if
we
do
get
rid
of
the
self-destruct
functionality
of
the
op
code,
and
it's
just
send
all
I
wonder
if
that's
going
to
be
a
frustration,
I
do
still
think
the
evm
is
better
overall
without
it,
even
if
it's
just
pay
all
but
I'm,
not
sure
if
that
will
upset
developers,
but
you
know
I
think
again
like
if
we're
coming
from
the
mentality
of
more
restriction
in
the
beginning.
A
E
Isn't
the
only
reason
why
I
self-destruct
these
on
the
on
the
Legacy
contracts
currently
is
because
it
is
probably
going
to
break
some
contracts
in
the
minute
yeah.
Another
reason
we
are
not
basically
removing
it
is
because
we
are
afraid
to
break
some
things,
but
with
this
format,
we
are
breaking
a
lot
of
things.
I
think
should
be
okay,
just
to
remove
it
all
together,
yeah.
F
C
I
guess
the
argument
is
that
if
a
bit
is
still
a
likelihood
there's
still
stuff,
this
truck
can
be
modified
in
Shanghai,
so
the
same
Hartford,
and
if
that
happens,
then
the
decision
here
likely
has
to
be
changed.
In
light
of
that,
you
know
whatever
the
decision
going
to
be,
but
if
self-destruct
is
left
as
it
is
in
Shanghai,
then
I
think
restricting.
It
is
the
best
way
forward.
C
D
A
Sounds
good,
okay,
anything
else
on
3670
code,
validation,.
G
Hi
Dana
hi
sorry
I'm
late
calendar
posted
over
an
hour
later
so.
A
A
No
I
think
we've
just
gone.
I've
recorded
a
couple
of
the
things
related
to
3540
on
this
document,
but
generally
this
has
all
been
accepted.
So
yeah
we
just
we're
finishing
up
36.70.
If
anyone
has
anything
else,
otherwise
we
can
go
to
4200.
A
Okay,
4200
static
relative
jumps.
One
point
here,
there's
a
question:
should
we
calculate
the
offset
of
the
relative
jump
from
the
current
instruction
position,
or
should
we
calculate
it
from
the
next
instruction
position,
which
is
plus
three
bytes,
taking
account
for
jumping
over
the
op
and
its
operand.
C
D
D
B
A
B
Yeah
yeah
well
I
think
jvm
has
had
it
also
from
the
like.
It
calculates
from
the
instruction
I
believe,
but
I'm,
not
entire
issue,
but
I
did
some
research
on
jvm
when
I
was
comparing
the
verification.
D
H
I
mean
yeah
I
mean
the
offset,
doesn't
make
much
of
a
difference
for
us.
We
can
generate
code
either
way
so
I
don't
mind
that
at
all
General
we
have
been
discussing
for
or
starting
to
discuss
whether
we
want
to
have
the
Erp
extended
by
some
jump
table.
Jump
I'm,
not
sure
whether
we
want
to
go
into
that
we're
not
entirely
clear
about
that
yet,
but
yeah
regarding
the
offset
first,
not
to
just
distract
yeah.
It
doesn't
matter
to
us.
A
Okay,
I,
don't
know
how
to
make
a
decision
on
this
right
now,
we're
still
at
the
plus
three
bytes
I
think
you
know
we
should
either
keep
it
at
that
or
if
somebody
is
able
to
point
to
a
few
other
instruction
sets
that
are
doing
it
from
the
instruction
itself
or
you
know
some
other
reasoning
that
we
should
seriously
change.
It
I
think
we
should
just
stick
with
what
we
have.
C
I
think
there
are
two
data
points
which
can
help
make
this
decision,
so
one
is
looking
at
the
once.
This
is
implemented
in
all
of
DVM
clients.
Look
at
you
know
which
way
has
more
overhead.
From
the
evm
perspective,
I
mean
Pavo
said
that
in
evm1
the
current
one
has
a
slight
overhead
right,
but
would
be
nice
to
see
it
across
all
the
different
tvms.
So
that's
one
data
point
and
I
suppose
slightly.
C
We
have
to
prefer
The
evm
Interpreter
perspective,
but
the
other
data
point
could
be
some
statistics
from
solidity
once
this
is
implemented
in
solidity,
which
is
which
is
planned.
You
know
in
this
year.
So
what's
it
it's
implemented
in
solidity,
we
can
collect
some
statistics
of
frequency
between
backward
and
forward
jumps
and
that's
like
another
data
point.
You
know
which
could
help
this
decision.
C
Okay,
but
yeah
I
think
the
evm
implementation
has
precedence
because
you
know
we
want
to
make
the
evm
implementation
is
simpler.
A
Yeah
makes
sense
there
I
think
is
definitely
going
to
be
an
overhead
for
the
plus
three
semantic.
But
it's
you
know
just
one
addition,
so
you
just
have
to
decide
yeah.
Is
that
worth
it?
G
Java
jsr
does
it
from
the
instruction
not
from
the
next
instruction.
So
that's
one
point:
okay,.
G
D
B
G
B
D
G
A
C
I
think
there's
one
more
data
point.
So
what
Daniel
mentioned
we
have
been
discussing
the
jump
table
or
like
this
yeah
jump
V
instruction,
and
there
are
many
different
questions
around
that,
namely
whether
it
should
be
dense
or
sparse
whether
it
should
have
the
data
as
an
immediate
or
in
a
section.
C
This
depends
on
on
many
questions
we've
been
discussing,
but
in
it
would
be
nice
to
get
more
clarity
on
that
and
I
think
we
want
to
discuss
that
on
Monday
with
solidity,
and
that
may
also
have
like
an
influence
of
this,
because,
ideally,
if
you
do
end
up
having
such
an
instruction,
it
should
be
following
the
same
semantics
as
air
jump.
D
A
All
right,
4200,
a
7
47.50
you'll,
have
functions.
First
thing
is:
we've
set
the
call
F
and
red
f
op
code
numbers
to
b0,
B1
I,
believe
that's
what
this
change
was
for.
A
A
B
D
B
The
the
last
section
is
kind
of
I
think
they
are
a
bit
lower
that
we
originally
proposed,
but
I
did
try
to
kind
of
analyze.
What's
like
micro,
micro
I,
don't
know
micro
instructions
they
actually,
then
the
implementation
should
do
and
yeah
based
that
on
the
so
they
click
Master.
You
like
to
give
give
some
consistency,
but
they
also
like
sophisticated
I
mean
they
have
I
think
lower
that
some
people
might
expect.
So
I'm
not
sure
this
is
not
controversial,
but.
A
H
D
A
Yeah,
that's
one
piece
of
feedback,
I've,
gotten
and
yeah.
You
know
we'll
talk
about
it
or
you
guys
will
talk
about
it
more
with
this
jump
table
instruction,
but
some
people
were
a
little
upset
that
the
relative
jumps,
because
we
can't
jump
to
the
dynamic
location
anymore,
was
more
expensive
for
their
optimized
by
code.
C
Yeah
we're
actually
talking
about
three
features
in
total
over
the
past,
like
two
weeks
so.
C
Ideally,
we
don't
want
to
put
all
of
them,
because
we
still
want
to
keep
the
surface
relatively
small,
but
I
could
see
you
know
the
tail
call
or
the
the
conditional
call
one
of
those
two
to
become
part
of
it.
I'm
leaning
towards
the
tail
call
and
the
jump
table
obviously
would
be
rather
useful
for
many
different
cases,
but
that
requires
more
analysis.
H
A
C
Yeah
my
plan
was
to
draft
up-
maybe
not
an
AIP,
but
at
least
a
spec
for
these
instructions,
and
we
want
to
have
some
preliminary
idea
before
next
all
could
have
next
week
yeah
whatever
you
want
to
propose
these
or
not.
A
A
Yeah
I
think
I,
don't
know
you
guys
can
weigh
in,
but
it
felt
like
the
way
that
the
eof
header
was
evolving
was
partially
due
to
the
way
that
they
were
written
and
the
anticipation
that
some
things
would
go
on
before
others.
But
if
we
think
about
them
all
as
the
atomic
unit
now
it
feels
like
it
makes
more
sense
to
have
the
code
section
size
just
be
an
array.
G
For
functions,
two
is
a
repeated
field.
The
code
Type
yeah
code's.
G
A
I,
don't
know
if
I
follow
there
are
there.
Currently
it's
allowed
to
have
multiple
code
sections
and
it
will
still
be
allowed
to
have
multiple
code
sections,
but
in
the
header
of
the
eof
container
each
section
is
like
an
individual
thing,
and
so
you
have
the
section
prefix
one
code,
and
then
you
have
the
size
of
the
code
and
I'm
proposing
that
you
have
instead
of
multiple
one
prefixes
code
size.
You
have
a
single
one
prefix
for
code
and
then
you
have
a
list
of
code
sizes,
each
two
bytes
and
there's
two
ways.
A
A
H
C
To
mix
the
type
in
the
code
and
what's
the
discussed
I
mean,
do
you
have
it
in
a
single
header.
B
Yeah
I
I
kind
of
proposed
that
but
I
didn't
actually
dig
into
like
I.
Think
this
kind
of
a
big
like
technically
makes
sense,
but
like
we
lose,
but
just
like
this,
like
one
level
of
abstraction
that
the
way
the
the
eof
headers
are
defined,
like
it's
very
simple,
that
it
does
the
kind
and
the
size
of
the
content.
B
So
the
type
sections
have
actually
the
types
in
the
content
and
or
code.
We
can't
do
it
so
yeah,
but
because,
like
we
always
require
the
the
type
and
the
codes
going
on
and
we
kind
of
matched.
So
we
can
actually
combine
these
two.
Like
this
I
think
number
of
options
you
can
do
it.
You
can
even
put
the
type
in
the
content
like
prefixing
the
code
that
may
be
also
annoying,
because
I
have
to
remember
that
the
first
two
bytes
means
something
different
than
the
code.
B
A
A
Okay,
I
don't
know
if
we
can
make
a
decision
on
that
here,
but
yeah
there's
lots
of
different
ways.
We
can
do
this
I
think
we
should
definitely
consider
yeah
different
different
ways
and
I.
Think
the
important
indicator
of
which
ways
are
better
would
be
like
the
parsing
complexity
of
it.
So
it
would
be
great
to
keep
the
parsing
complexity
low
and
also
keep
the
total
size
and,
like
you
know,
redundant
information
low,
but
I
would
rather
have
a
bit
of
redundant
information
if
it
pertains
like
Simplicity
of
parsing.
A
Okay
clarify
if
the
data
stack
has
less
than
color
stack,
Heights,
plus
the
code
sections
outputs,
then
execution
results
in
exceptional
halt.
What
happens
if
the
stack
height
is
larger
than
the
number.
B
B
Yeah,
that's
complicated
one,
okay
yeah,
so
it's
mostly
about
the
read
red
f
instruction
that
ends
the
the
function
execution,
that's
related
to
like
the
validation
as
well,
but
yeah
for
this
like
eof
functions,
EAP,
we
don't
have
the
strict
validation
yet
so
yeah
mostly
you
need
to
have
in
the
type
you
have,
the
number
of
outputs
specified
for
a
function,
and
so
you
need
at
least
this
number
of
outputs
on
the
stack
when
the
return
f
is
executed
and,
and
the
spec
says
that
it
has
to
be
at
least
this
number.
B
D
B
Unless
we
keep
it
like
this
and
like
somehow
it
goes,
but
I'm
not
sure,
maybe
you
can
discuss
it
later,
offline
or
okay.
We
kind
of
will
go
back
to
this
when
if
we
have
time
to
go
to
the
to
the
stack
validation,
because
it's
kind
of
repeated
there
as
well
and
I,
think
on
this
strict
validation.
B
What
we
end
up
ended
up
with
is
that
we
want
exactly
this
number
of
elements
on
the
stack
so
far,
so
you
can
kind
of
make
it
the
same
restriction
here
as
well,
so
not
like
it
has
been
above
or
equal,
but
it
has
to
be
precisely
equal
and
then
the
implementation
is
kind
of
trivial.
H
B
Yeah,
that's
that's
correct.
We
kind
of
aware
of
that,
but
I
think
the
kind
of
the
resolution
was
to
like
see
how
the
code
generation
would
handle
that
like
how
bad
it
will
be,
and
then
we
can.
H
D
A
B
G
And
16
Meg
should
be
enough
for
anyone.
C
But
it
does
kind
of
prevent
the
hybrid
optimization
of
having
like
a
lot
of
tiny
Hardware
functions.
I
mean
possibly.
This
is
yet
to
be
found
out
with
the
solidity
implementation.
You
know
how
many,
how
efficient
is
it
gas
wise
to
split
up,
because
currently,
solidity
already
has
an
insane
amount
of
helpers
in
the
code
generation
and
then
those
are
in
line
and
and
potentially
reduced
and
deduplicated
currently,
but
we
yet
to
see
you
know
what
strategy
would
work
the
best
with
the
function
sections
depending
on
the
gas
options
there.
H
Yeah,
the
duplication
may
end
up
generating
small
functions
in
large
quantities.
So
if
we
end
up
having
duplication
by
yeah
block
the
duplication
by
generating
functions
and
calling
them,
even
though
it's
just
the
tail
of
a
function
actually,
but
so
yeah
I'm
not
entirely
sure
how
many
functions
we
will
actually
end
up
with
on
the
average.
In
the
end.
H
A
B
B
A
A
G
We
don't
have
gas
costs
specified
for
college
for
return,
F
either,
which
I
think
it's
a
question
of
cost
there.
Those
seem
low,
I,
don't
know.
A
A
D
A
All
right
we've
got
13
minutes
left
as
well,
so
yeah.
Let's
just
keep
that
in
mind.
We
have
a
couple
more
things
to
get
to
54.50
and
I
think
we
should
definitely
talk
about
this
one,
since
it
has
some
of
the
most
criticism
right
now.
Okay,
anyways
reject
jump,
jump,
I,
jump
dust,
I,
mentioned
I
think
it
might
be
good
to
expand
the
rationale
a
little
bit
on
this.
Just
like
what
does
this
really
provide?
B
B
So
yeah
we
can
be
removing
trumpets
as
an
invalid.
We
can
kind
of
reassign
it
like
change.
The
name
I
think
we
can
consider
it
offline
and
the
same
for
the
the
PC
next
one
like
I,
had
it
somewhere
in
the
notes.
Okay,
so
you
will.
You
won't
be
able
to
observe
like
query
on
the
code,
but
we
didn't
do
any
black
analysis,
how
this
is
good
or
bad.
So,
let's
keep
it
for
now.
A
Okay,
yeah
sounds
good
reassign,
your
section
IDs
to
be
in
order.
That
makes
sense
to
me.
A
Sweet
make
type
section
mandatory,
I
I,
think
this
makes
a
lot
of
sense.
I
think.
The
reason
it
wasn't
mandatory
was
because
of
the
potential
of
different
things
going
at
different
times,
but
if
we
are
doing
them
all
at
once,
it
seems
like
extremely
unlikely
that
we'll
have
a
single
code
section
deployed.
C
Charts
from
Viper
left
some
comments
on
the
if
you're,
magicians
and
also
reached
out,
because
his
comments
were
not
answered,
and
this
was
from
a
buyback.
What
he
has
was,
why
even
enforce
a
code
section
for
data
contracts
yeah-
and
you
know,
in
that
case
I
mean
the
type
section
is-
is
again
just
an
overhead.
But
if
you
have
a
single
code
section,
the
type
section
definitely
is
an
overhead.
C
Well,
it
depends
on
the
validation.
Right
depends
on
the
next
section
here,
but
also
this
discussion.
Whether
we're
gonna
have
the
type
information
in
the
code
section
or
not.
C
Yeah
I
think
there's
a
lot
of
questions.
We're
interested
in
any
case
yeah,
but
the
the
optimizer
Community
definitely
would
ask
you
know
why
you
have
this.
If
it's
not
used.
B
A
G
A
D
G
A
A
C
You
know
I'm
personally,
in
favor
of
can
we
get
more
strict
to
make
parsing
easier,
so
optimizing
for
runtime
cost
yeah
at
the
expense
of
the
storage
cost?
C
But
you
know
maybe
this
is
something
which
can
be
also
floated
at
other
client
devs,
which
is
more
important.
Are
they
do
they
really
want
to
optimize?
For
you
know:
storage
cost.
Instead
from
like
a
design
perspective.
A
Yeah
I
think
I'm
on
the
same
page
as
you,
so
I
can
write
a
couple
different
ways
of
doing
that
and
look
at
the
differences
a
bit
and
yeah.
Let's
talk
about
it
again
later,
foreign
clarify
the
1024
stack
limit
still
applies.
I
think
this
makes
sense
and
yeah
just
a
simple
change
to
47.50.
Just
clarification:
okay,
six
minutes,
54.50
stock
validation,
yeah.
A
This
I've
heard
the
most
criticism
about
like
obviously
right
now,
it's
not
something
that
people
are
considering
as
much
as
part
of
this
like
full
eof,
Suite
I
realize
that
why
everyone's
call
feels
differently
and
like
we
want
to
do
this,
but
yeah,
it's
not
considered
for
the
next
devnet
right
now
and
Martin
has
probably
been
the
loudest
person.
Who's
had
criticism
of
this
specification
and
how
ready
it
is
ETC.
So
I
don't
know
if
people
have
thoughts
on
that.
F
Just
a
quick
question:
if
we
don't,
if
we
don't
end
up
cleaning
the
stack
on
a
terminating
instruction,
where
are
we
going
to
store
the
data?
That's
located
on
the
stack.
A
B
Yeah
so
like,
let
me
quickly
explain
when
you,
when
you
call
it
a
function,
then
you
get
like
the
subset
of
the
stack
space
available
and,
and
the
idea
is
that,
when
the
function
returns,
it
has
exactly.
It
leaves
on
this.
B
This
subject,
subsection
exactly
the
number
of
items
that
is
specified
in
the
function
type,
so
the
caller
know
exactly
how
much
items
will
be
in
the
stack
after
the
call.
It's
not
a
guess.
It's
like
kind
of
explicit,
and
it's
a
matter
if
this
is
verified
on
deploy
type
or
is
checked
at
runtime,
but
the
behavior
is
kind
of
a
bit
more
strict.
A
One
point
I
just
wanted
to
mention
is
that
I
think
you
know
with
respect
to
Martin,
something
that
would
make
him
feel
better
about.
These
things
is
if
we
had
more
motivation,
450
450
in
terms
of
what
you
can
do
with
compilation,
because
he
generally
feels
that
5450
probably
isn't
worth
it.
If,
like
the
only
thing,
it's
doing
is
reducing
the
number
of
Checks
In
The
Interpreter
Loop
for
underflow
overflow,
and
so
if
we
can
provide
some
motivation
that
this
makes
things
better
and
you
know
future
worlds.
That
would
probably
alleviate
his
concerns
for
that.
G
G
There's
always
you
know
multimodal
interpretation
too.
You
can
mix
your
compilation
and
your
inter
your
agitated
code
at
the
same
time,
but
I
mean
there's
also
the
the
some
people
feel
like,
especially
in
the
move
Community.
The
dispute
of
The
Interpreter
is
secondary.
The
data
access,
so
there's
we're
also
fighting
Upstream
against
that
yeah
is.
Is
there
anything
other
than
future
jitting
that
we
could
and
stack
reduction
that
we
could
pitch
for
that
foreign.
B
No
I
don't
think,
there's
like
much
more
to
to
find
here.
It's
like
it
simplifies
the
The
Interpreter
at
runtime,
but
the
the
the
whole
performance
gates
are
not
really
big
and-
and
like
my
kind
of
like
different
thing.
Thinking
about
is
that
we
we
do
need
to
to
do
code
validation
anyway,
and.
D
G
B
Adds
additional
paths
to
like
to
to
more
validation-
and
this
is
it's
a
bit
like,
like
I
kind
of
feel
like
how
how
much
we
can
push
it,
and
this
seems
to
be
like
the
final
step.
I,
don't
see
anything
about
that,
but
yeah
I
understand
this
concerns.
Maybe
it's
not
worth
it,
but
I
I
think
it's
like
either
we
created
here
or
like
we
will
not
be
able
to
do
it
anyway.
B
If
it
doesn't
go
in
the
first
suit,
like
it's,
definitely
not
worth
it
to
introduce
it
later
like
to
have
the
contracts
that
has
to
obey
it
and
the
contracts
that
doesn't
have
to
abide,
because
they
are
right,
you
have
one
but
yeah,
okay
and
yeah
I
did
I
did
put
like
newer
version
of
that,
like
it
has
the
text
back,
so
it
doesn't
have
to
follow
python
code
and
I
like
if
you
really
do
it
well
really
kind
of
advocated
for
it.
B
But
that's
not
my
intention,
but
you
can
kind
of
replace
the
the
previous
CIP
with
only
this
one.
But
that's
that's
mostly
like
how
to
organize
the
specification
for
it.
H
A
G
I
can
draft
up
a
doc
for
it,
but
if
we
could
require
that
any
instruction
following
a
terminal
instruction
must
have
been
referenced
by
a
prior
jump.
You
know
we
could
word
Smith
it.
We
can
do
single
pass
and
we
can
do
dead
code.
Checking
too.
A
A
Okay,
thanks
a
lot
everybody.
This
was
helpful
thanks
a
lot
it's
Apollo
Alex
for
coming
up
with
the
list
of
open
issues,
yeah
just
a
little
bit
of
work
to
do.
I'll,
oh
I,
guess
like
one
other
thing
is
that
Mario
Vega
has
been
working
on
some
more
cross-client
tests.
I
can
post
the
link
in
the
Discord
evm
Discord
channel.
So
if
you
are
a
client
developer
implementing
this,
there
will
be
some
more
tests
coming
out
soon.
A
Yeah
anyways,
looking
forward
to
hearing
the
outcome
of
your
guys's
conversation
with
solidity
and
yeah.
Let's
keep
chatting
in
the
evm
channel.