►
From YouTube: EOF Breakout Room #4
Description
A
Cool
okay:
everyone
welcome
to
the
fourth
breakout
room
of
eof.
We've
got
some
things
on
the
agenda
to
discuss.
I
think
the
main
stuff
is
to
talk
about
the
open,
spec
questions,
but
I
think
it
would
be
good
to
just
start
with
updates
from
various
people.
So,
let's
maybe
start
with
client
team
updates.
B
So
basically,
we
have
the
five
VIPs
in
a
functional
first
pass
implemented.
I
haven't
heard
any
update
on
changing
the
eof
container,
so
I
went
with
the
UF
container
specified
in
the
unified
spec
I.
Don't
know
you
know,
there's
a
lot
of
PRS
flying
around
as
to
what
the
final
state
of
the
eof
container
is,
but
the
relative
jumps
in
the
function
calls
would
be
relatively
uneffective
if
the
container
format
was
changed
again,
so
I've
been
trying
to
copy
over
test
vectors
from
other
clients
trying
to
get
a
unified
test.
B
Vector
again,
you
know
that
good
I'm
making
them
in
such
a
way
that
they
didn't
rely
on
the
container
as
far
as
you
know,
being
able
to
test
what's
going
on
with
stuff.
Like
return
f,
that's
the
tricky
one
because
you
got
to
do
the
code.
Sections
have
that
logic
built
in,
but
relative
jumps
is
all
within
one
code
run,
so
that's
apparently
isolated.
So
so
that's
our
status.
We're
ready
to
you
know,
start
interrupting
and
see.
A
Okay,
awesome
great
Aragon
is
anyone
here.
A
Okay,
I
can
go
I,
guess
for
guess:
I
have
Rewritten
our
implementation
of
eof
pretty
much.
You
know
partially
just
to
try
and
a
couple
of
different
approaches
for
things,
but
also
to
iron
out
the
unified
spec.
So
I've
implemented
the
unified
spec
from
scratch
in
guess,
and
yeah
I've
replaced
my
PR.
So
if
you've
been
looking
at
the
eof,
bundled
PR
and
guess
that
now
has
that
code
instead
of
the
older
code,
the
tests
are
still
sparse,
but
I
will
be
working
on
tests
mostly
for
the
next
week.
C
I
could
just
speak
quickly
for
the
work
that
we've
done
on
Aragon.
It's
essentially
been
tracking
your
guest
changes
and
maintaining
those
that's
the
general
status.
D
A
Great
is
any
compiler
teams
here
or
anyone
who
has
updates
from
the
compiler
work.
A
Okay,
great:
what
is
the
timeliner
plans?
Do
you
think.
C
Completely
tippity
we've
just
started
so
okay,
but
it
looks
like
the
volume
you
know.
The
the
volume
of
changes
will
be
fairly
small
to
it.
The
real
problem
is
testing,
because
that
depends
on
high
evm.
You
are
nowhere.
A
I
see
okay,
I
might
mention
this
to
the
pi
AVM
team.
A
E
I
can't
give
an
update
from
solidity,
so
solidity
has
a
while
ago
merged,
at
least
like
the
base
scaffolding,
to
support
turning
the
eof
on
and
off,
and
then
there
are
a
number
of
PRS
which
haven't
been
merged
yet,
but
they
are
actively
worked
on.
E
There
is
a
PR
for
the
container
format
which
is
tested
against
evm1.
There
is
another
one
for
static
jumps
and,
as
of
yesterday,
there
is
also
a
working
implementation
of
function,
sections
without
using
jump,
if
only
just
call
it
and
rediff,
and
they
are
seeing
I
mean
they
in
the
first
version.
E
They
have
to
disable
all
the
optimization
stages,
because
those
need
to
be
updated,
but
with
the
optimization
stages
disabled,
they
are,
which
also
means
there's
no
deduplication
of
code
they're,
seeing
a
slight
code
increase,
which
is
expected
without
the
duplication,
but
at
the
same
time
they
are
seeing
measurable
gas
savings
already
and
keep
in
mind.
This
is
without
having
any
kind
of
optimizations.
A
Great
thanks
for
that
update,
I!
Guess,
that's
probably
our
two
compilers
here,
okay,
so
spec
updates.
Does
anybody
from
the
Epson
team
want
to
give
an
update
about
where
you
guys
are
at
I
listed
a
couple
things
on
the
agenda
of
things?
I
know
that
are
still
open
that
we've
been
discussing,
but
would
be
happy
to
hear
what
you
guys
have
been
up
to
the
last
week
or
two.
F
So
this
week,
I
I
did
merge.
Some
of
the
changes
that
were
kind
of
under
review
for
longer.
F
F
and
that's
not
to
be
in
conflict
and
doesn't
have
like
redundant
checks.
F
And
yeah
I
think
that's,
that's
mostly
it
and
the
other
world
mostly
editorial.
What
is
missing
is
this.
The
the
main
container
format,
obviously
I,
think
we'll
spend
some
time
today
on
it
and
I
plan
to
reach
like
the
last
one,
which
is
the
stack
validation
but
I
kind
of
stopped
on
the
jump,
F
and
redef,
which
has
changed
the
semantics.
Okay,
maybe
I
should
mention
that
there's
a
additional
functional
change,
but
this
happened
when
I
was
actually
offline.
F
Let's
say
so,
I'm
sure
how
much
this
was
discuss
previously
yeah,
but
like
both
of
them
jump.
Every
death
are
specified
in
the
way
that
they
require
automatic
stack
cleanup
to
be
performed
as
a
part
of
instruction
and
I.
Think
this,
like
this
small
issues
with
this,
how
this
is
done
so
that's
mostly
like
I,
had
some
concerns
about
it
and
that
mostly
stopped
me
from
reaching
the
last
EAP
actually.
F
I'm
just
browsing
the
the
issue
list,
so
I
think,
like
that's
mostly
reflects
the
the
current
status.
So
mostly,
the
container
format
is
not
it's
not
finalized,
and
this
stack
of
validation
doesn't
expect
to
be
like
chain
functional
functionally,
but
yeah.
The
the
IP
needs
bigger
update
in
terms
of
just
the
text.
A
Sounds
good
thanks
for
that
update?
Do
we
want
to
start
talking
about
the
header
format,
or
do
we
want
to
jump
and
talk
about
the
stock,
clearing
for
jump
up
and
right
off?
First.
A
I
guess
we
can
talk
about
the
header
format
first,
if
that's
okay,
honestly
I'm,
not
sure
what
has
really
transpired
since
we
last
talked
about
it
two
weeks
ago
on
this
call,
it
seems,
like
you
know,
bases
implemented
the
this
unified
spec
version
of
the
header
format,
I've
implemented
the
unified
spec
version
of
the
format.
A
F
So
how
how
do
you,
how
do
I
think
about
it?
Is
that,
like
I
think,
like
the
basic
option
is,
do
we
want
a
strict
format,
that's
kind
of
predefined,
where
the
values
are
in
the
on
different
offsets
in
the
container,
so
that
that's
like
I
think
it
should
be
simple
to
to
pass
and
like
yeah
like
efficient
in
terms
of
how
many
buys
it
uses.
But,
like
the
trade-off,
is
you
you,
you
lose
all
the
flexibility
to
be
like
new
stuff
about
it
later,
without
breaking
the
the
compatibility
with
with
client
formed.
F
So
that's
like
I
think
one
of
all
the
options
we
have
and
the
other
one
is
just
to
improve
what
we
currently
have.
So
we
keep
the
differences
mostly.
Do
we
want
to
have
something
like
section
kind
as
a
buy?
That
indicates
what's
follows.
So
that's
this
kind
of
extension
point
for
later,
but
we
actually
can
skip
that
as
well
and
with
with
the
the
section
kind
kind
by
it,
I
think
we're
going
to
improve
what
we
currently
have
by
introducing
arrays
instead
of
individual
sections.
F
F
F
Mostly,
like
you
have
a
section
client
which
says
the
code
section
but
like
instead
of
have
individual
sizes,
you
just
have
array
of
sizes.
So
most
of
this
you
have
like
single
code
section,
but
it's
it's
separated
by
the
by
the
size
values
into
partitions.
However,
we
call
it,
but
it's
like
it
also
has
some
additional
benefits.
So
it
kind
of
guarantees
by
design
that
the
code
section
so
like
this
partitions
of
code
will
be
adjusted.
F
It's
not
like
you
can
split
code
sections
with
with
data
sections
and
so
on,
like
in
on,
in
general
view
right,
I
think
it's
nice,
so
it
mostly
it
saves
you
the
this,
like
linear
redundancy
that
you
repeat
the
same
byte
all
the
time,
but
you
have
some
this,
this
additional
bytes.
That
kind
of
I
think
we
could
live
with
without
it
if
we
really
want
to
but
yeah
that's
kind
of
the
trade-off.
F
So
there's
like
some
fixed
number
of
additional
bytes
in
the
header
that
will
be
placed
so
that's
kind
of
as
the
original
EOS
was
designed,
but
yeah
so
I
think
that's
that's
mostly
how
I
understand
it
either?
We
really
go
really
fixed
format
as
like
IP
I.
Don't
know
something
like
that
right.
So
like
it's
like
two
bytes.
Are
there
the
offset
and
and
that's
it
or
we
go
with
a
bit
more
fancy.
But
it's
not
it's
not
more
fancy
that
the
UF
originally
proposed.
It's
kind
of
improved
version
of
it.
A
Right,
I
guess
like
one
like
threat
of
conversation
that
has
transpired
in
the
last
week
or
two:
is
this
post
by
vitalik
and
I?
Think
that
you
know
one
takeaway
from
this
post?
Is
that
it's
like
you
know,
it
seems
like
a
very
important
thing
to
not
have
many
eof
versions
like
we're
talking
like
maximum
two,
but
most
likely
like
one
elf
version,
and
so
what
we
do.
We
should
really
consider
about
like
the
forward
compatibility.
A
A
F
B
F
A
So
I
guess:
what
should
we
do
to
make
a
decision
on
this
we're
like
kind
of
getting
to
the
point
where
it's
really
important,
to
make
the
decision,
so
clients
can
Implement
and
start
testing
and
we
can
be
ready
for
this,
like
January
fifth
deadline
and
it
doesn't
seem
like
a
lot
of
new
information-
has
come
out
on
this
header
format
in
the
last
two
weeks.
So
do
we
have
the
ability
to
make
a
decision
now
or
do
we
need
to
acquire
more
information
to
make
it
in
the
next
couple
days.
F
So
I'm
I'm
also
kind
of
in
the
favor
of
having
this
more
flexible
one
like
more
generic
format.
That
leaves
some
space
for
extensions.
F
So
if
I
think
nobody
protests
in
the
sense
that
we
want
to
kind
of
save
every
last
bite
of
the
format
so
that
the
storage
on
the
the
codes
on
chain
is
like
minimal,
so
I
think
I
would
also
go
with
a
bit
more
flexible
and
if
that's
the
decision,
I
think
we
can
sort
it
with
with
Matt
offline
I.
Think
even
today,
that's.
A
F
Because
I
don't
think,
there's
like
much
much
friction
points
in
the
exact
design,
so
so
yeah.
If
that's
we
go.
If
we
go
with
this
decision,
then
we
can
kind
of
propose,
like
present
kind
of
like
single
variant
of
that
for
review.
Probably
today
or
tomorrow,
that's
kind
of
my
understanding.
A
Okay,
that
sounds
good.
Dano
has
a
question
same
question
as
Moody,
but
for
SSD
I
think
the
same
answer,
probably
simplicity,.
G
Well,
I
I
certainly
prefer
a
more
flexible
format
so
far
as
the
forward
compatibility
issue,
we
we
really
shouldn't
need
very
many
future
version
bumps.
If
we
do
this
right.
G
Right
because
adding
an
OP
code
doesn't
change
the
version
that
op
code
never
would
have
gotten
through
the
validator
and
various
other
changes
are
like
that.
One
of
the
few
things
that
would
require
a
version
bump
would
be
if
we
tightened
up
the
validator
to
give
stronger,
very
stronger
guarantees
which
would
break
would
break
previous
code.
That
couldn't
be
those
guarantees.
D
A
I
I
posted
the
anchor
to
The
Container
format
and
unified
spec.
We
can
take
this
offline
and
you
know
maybe
change
like
a
slight
thing
there,
but
if
anybody
on
the
call
has
comment
on
this
format
right
now,
it
would
be
good
to
say
something
otherwise,
we'll
post
a
you
know,
finalized
version
to
review
later
today
or
tomorrow.
F
Yeah
I'm,
starting
like
the
the
question
about
rotov
quickly,
I
I
I
didn't
fully
explore
that
for
sure
so,
but
what
can
I
say?
I
think
I'm,
not
sure
it's
it's.
It's
like
right
time
to
kind
of
explore
it,
but
yeah
I
think
someone
can
kind
of
present
example
how
that
would
look
like
I
think
that
would
be
fine
as
well,
but
I
can't
really,
if
that
helps
or
not,
for
what
we
considered
is
something
else
like
having
very
link
number
encoding.
F
So
whatever
you
have
a
size
somewhere
in
the
in
the
code
or
I,
guess
mostly
for
the
sizes
and
indexes
all
of
that,
like
we
have
fixed
number
of
bytes
that
can
be
replaced
with
the
like
variolic
number
of
coding,
which
are
relatively
simple,
but
and
so
sometimes
it
can
say
if
you
want
byte,
sometimes
you
can
add
you.
One
byte
depends
like
on
the
context,
but
if
you
have
small
numbers
most
of
the
time
I
guess
it
can
reduce
the
two
byte
sizes
to
one
byte,
with
some
additional
complexity
added.
F
So
that's
right
kind
of
this.
This
question
showed
up
some
like
some
number
of
times,
especially
when
you
consider
you
have,
because,
with
the
fixed
sizes
yeah
we
fixed
sizes
of
numbers,
you
can
you
kind
of
have
to
pick
the
right
size
at
the
like
very
first
moment
right.
F
So,
for
example,
if
you
want
what
we
discussed,
for
example,
that
the
call
F
is
it
supposed
to
have
like
one
byte
index
or
two
byte
index,
and
with
this
like
variatic
encoding,
you
can
kind
of
Shuffle
it
because
it
will
handle
like
small
numbers
as
one
by
byte
and
coding
and
like
bigger
numbers,
one
other
two
byton
coding
yeah,
but
the
most
deck
would
kind
of
skeptical.
We
want
to
introduce
complexity.
So
that's
why
that
wasn't
officially
anywhere.
E
So
maybe
because
this
is
recorded,
but
the
all
the
the
chat
text
isn't,
a
lot
of
conversation
has
happened
there
regarding
the
proposal
of
one
and
choosing
product
for
SSD
and
I
wanted
to
add
that
initially
we
did
instead
of
like
a
fixed
length
field,
we
did
consider
using
lab128
but
then
rejected
the
idea
because
we
felt
like
even
that
would
be
too
much.
E
Complexity
and
clients
would
argue
against
that
for
Northland
savings,
and
if
that
argument
is
correct,
then
doing
product
buff
or
SSD
seems,
like
you
know,
even
way
more
complexity.
A
A
Okay,
moving
on,
let's
chat
about,
let's
chat
about
this
stack,
cleanup
question
for
red,
f
and
jump
f,
maybe
Paul
or
Alex.
You
can
give
a
overview
of
this.
F
Like
to
my
understanding,
I
kind
of
that's
like
my
last
two
days
to
to
digging
into
the
the
specification
of
this
specific
aspect
is
that
both
the
the
instructions
need
to
kind
of
balance.
The
stack
at
some
point,
like
jump,
F
kind
of
do
it
before
the
call,
because
it's
like
the
beginning
of
the
color
Reserve,
do
it
and
the
command,
but
they
they
kind
of
have
like
specified.
F
The
exact
stack
height
is
expected
in
the
call
on
on
the
end
of
the
call,
and
they
need
to
move
the
some
top
stack
items
to
this
position
in
this
way.
So
I
kind
of
see
like
two
issues
with
it
like
on
technical
level,
is
it's.
It
might
be
like
complex
in
the
sense
like
a
bit
time
consuming
operation,
because
you
can
have
functions
that
return
over
like
200
arguments
or
like
receive
200
arguments.
That
means
if
the
stack
is
unbalanced.
F
F
F
So,
like
probably
most
of
the
use
cases
will
not
do
it,
but
you
can
kind
of
you
need
kind
of
design
for
the
worst
case
anyway,
and
the
second
one
I'm
not
sure
I
can
like
fully
explain
but
seems
to
be
like
the
reason
is
it's
there.
Maybe
some
other
people
can
comment,
but
I
will
do
an
introduction.
F
Is
that
it
like
provides
some
usability
to
use
this,
but
it
means
like
for
for
compilers
mostly,
but
it
feels
to
me,
like
it
kind
of
bundles
it
with
on
the
way
that
maybe
it
reduces
issues
in
some
other
place.
F
This
is
related
to
the
fact
it
depends
on
the
like
formally
specified
number
of
outputs,
but
some
of
the
functions
doesn't
really
have
number
of
outputs
because
they
never
return
because
they
just
terminate
execution,
and
so
in
this
way
you
have
like
pathological
option
to
create
multiple
instructions,
but
having
exactly
the
same
code,
but
formally
they
may
might
be
defined
like
returning
different
number
of
outputs
and,
and
sometimes
that
might
be
needed
to
actually
be
more
useful
on
the
color
side.
B
So
my
concern
with
it
is
it's
a
variable
execution
time
for
such
a
low
gas
costed
function.
If
we
were
to
allow
the
stacks
to
be
cleaned
up,
you
know
you
have
a
500
item
stack
and
you're
passing
200
items
to
copy
that's
at
a
minimum,
200
copies
and
another
300
writes
if
you
want
to
be
safe
and
allow
the
stack-
and
so
that's
highly
variable
for
something
that
costs
only
three
and
four
gas.
A
H
Yeah
I
think
it
was
actually
added
to
the
spec
after
discussions
with
us
and
the
reason
for
us
get
heading
in
that
direction
was
fear
of
code
reduplication
becoming
harder
with
eof
in
general,
because
we
don't
have
cross
functional
gems
and
then
in
some
Corner
cases,
these
the
specification
of
not
having
to
clean
up
the
stack
helps
there,
but
given
that
we
now
have
an
initial
implementation
of
the
UI
functions,
even
though
it's
incomplete
because
it
doesn't
have
the
relative
jumps
yet
and
the
code
size
increase
is
not
as
much
as
I
would
have
feared.
A
Okay,
that's
good
perspective.
Yeah
I,
don't
know
what
people
think
about
that.
I
think
you
know,
generally
it's
better
to
obviously
ship
a
little
bit
less
and
later
on.
Add
things
on
because
we
can
easily
do
that
in
eof,
then
shipping,
something
like
Jump
app
that
doesn't
have
quite
have
the
exact
characteristic.
Do
we
want
that?
We
want.
G
Yeah
I've
I
have
never
liked
the
automatic
cleanup
feature,
for
the
reasons
probably
gave
us
and
some
others.
If
it's
explicit
it's
much
easier
to
know
that
it's
correct
both
for
the
author
of
the
code
and
the
validator,
and
for
just
specifying
what
we
mean
by
correct
yeah.
We
can
all
we
can
always
add
a
cleanup
op
code
later.
That
does
what
we
realize
that
it
really
needs
to
do
right,
probably.
F
F
So
kind
of
my
problem
is
that
I
think
would
be
nice
to
spend
like
a
bit
and
especially
now,
like
solidity
is
starting
to
actually
having
like
partial
implementation,
and
they
can
deliver
a
lot
of
useful
data
for
experiments
and
like
yeah,
just
like
yeah,
like
even
evaluating
design
decisions,
but
I
feel
like
we
don't
have
free
time
to
do
it
so
I
guess
we
need
to
make
a
decision
in
like
one
or
two
days
about
what
exactly
do
with
it.
F
G
H
Mean
one
of
the
cases
we
wanted
to
get
with
this
originally
would
be
to
to
be
able
to
outline
reverting
helpers,
but
that
the
current
spec
even
doesn't
allow,
but
that
we
also
needed
to
be
able
to
mark
functions
as
never
returning
with,
for
example,
255
outputs,
meaning
that
it
never
returns
as
another
special
case
which
was
never
considered.
So
without
that
that
case
even
vanishes
and
then
I'm
not
sure
there
is
actually
use
cases
for
the
cleanup.
F
Maybe
some
logs
then
exits,
and
this
kind
of
it
seems
like
simple
use
case,
but
it
doesn't
fit
EOS
very
well
if
you
have
really
strict
function,
handling
for
different
reasons,
but
we
kind
of
wanted
to
maybe
improve
the
UF
design
in
the
way
that
it's,
it
fits
better.
F
The
use
case-
yeah
that's
one
thing
and
the
second
one
is
something
I
I
started
thinking
about,
just
by
renaming
the
Telco
app
to
Jump
app
that
you
can
actually
have
some
different
form
of
control
flow
using
only
Jump
apps
which,
because
it
allows
you
to
jump
around
as
a
kind
of
fancy
jump
but
I
think
even
the
the
rename
of
that
which
I
think
was
a
very
good
one
kind
of
allowed
me
to
to
think
differently.
How
can
we
use
this
instructions
so
yeah?
That's
more
more
or
less
my
comment
about
it.
H
Maybe
a
bit
more
specific
about
the
duplication.
Part
I
mean
yeah.
What
we
do
in
code
generation
in
the
end
is
deduplicating
code
when
we
have
blocks
that
are
identical
and
jump
to
from
different
locations
and
before
UF
we
can
just
yeah
have
several
places
and
jump
to
the
same
code
and
UF
doesn't
allow
that
anymore.
So
that's
why
we
were
worried
that
without
that
kind
of
50
duplication
code,
size
would
blow
up
too
much.
But
the
first
experimental
results
indicate
that
it's
not
as
bad
as
feared.
H
H
H
So
yeah,
depending
on
how
jump
that
is
specified,
for
example,
for
reward
helpers,
we
would
need
to
First
clean
up
a
stack
and
then
jump
which
is
probably
depending
on
the
situation
more
code
than
the
deduplication
would
actually
gain
us.
So
that's
that
was
the
reasoning
but
yeah.
As
I
said
it's
the
code.
Size
increase
doesn't
turn
out
to
be
as
bad
as
I
feared.
So
maybe
this
we
could
live
without
optimizing
for
these
cases,
at
least
in
the
first
version.
G
F
Yeah,
the
reason
is
that
if
you
have
to
have
different
functions
that
want
to
have
additional
helper
like
shared
helper,
which
is
like
third
function,
if
the
place
you
want
to
jump
F
to
it,
have
different
stack
Heights,
you
can't
reuse
the
same
one,
although
it
actually
would
work,
because
this
helper
never
actually
returns.
F
So
it
doesn't
matter
how
much
outputs
it
returns,
but
the
number
of
outputs,
the
helper
declares,
which
can
be
zero
and
number
of
inputs
kind
of
have
to
balance
the
stack,
maybe
I'm
missing
something,
but
you
really
need
to
draw
it
to
figure
out.
What's
going
on,
but
at
least
there's
some
like
additional
restrictions
like.
D
A
Is
there
a
way
that
we
can
do
this
because
I
think
now?
Red
f
won't
have
the
stack
cleanup
and
we
need
to
have
this
future
compatible.
So
we
won't
be
able
to
modify
redf
in
the
future
to
have
stack
cleanup.
So
is
there
a
way
of
doing
jump,
F
or
tail
call
F
in
combination
with
some
move,
op
code
that
people
feel
would
you
know,
solve
the
problems
they're
trying
to
solve.
G
If
we
have
a
spec
for
jump,
F
that
does
solve
the
helper
problem
and
I
guess
would
need
a
dynamic
gas
cost.
Then
it'd
be
nice
to
get
it
in
now,
because
Cancun's
been
promised
for
the
summer.
But
we
know
what
our
track
record
is
for
delivering
upgrades
on
any
schedule.
So.
G
G
Those
are
the
the
two
sides
to
it,
but
I
I
would
be
happy
if
we
really
have
a
solid
spec
to
go
with
it
sure.
A
I'm
I'm,
just
like
worried
we're
getting
to
the
place
where
we
need
to
settle
this
back
down
and
if
we
don't,
then
there's
like
a
possibility
that
an
eof
doesn't
happen
at
all.
That's
right
and
so
I
would
I
would
rather
be
forward
compatible
with
a
future
jump
f
and
since
solidity
doesn't
seem
to
be
pushing
without
hard
for
jump
F
in
this
first
version,
I
think
it
would
be
good
to
consider
tabling
it.
A
F
Yeah
I'm
not
really
good,
fast
thinker,
but
I,
think
that
that's
the
kind
of
the
restricted
version
of
job
F,
which
is
kind
of
like
diffused,
call
and
read
return,
read
F
like
if
you
put
this
to
instructions
next
to
each
other
in
the
code,
that's
kind
of
I
think
it
works,
except
that
it
cannot
overflow
the
call
stack,
but
that's
so
I
think
that's
that's
not
really
problematic
to
be
included.
F
This
way,
I'm
not
sure
how
much
this
is
useful,
though,
if
we
can
do
it
better
later,
I
think
we
can
but
I'm
also
guessing
here,
because
we
can
always
introduce
the
instructions.
F
So
I
guess
you
can.
You
can
then
specify
it
as
we
want
I
think
it
doesn't
really
matter
so
much
I.
F
B
They
have
there's
no
stack
coming
up
on
it
and
we
can
introduce
a
stack,
cleanup,
op
code
if
needed,
because
you're
gonna
per
stack,
validation,
you're,
going
to
know
what
your
stack
looks
like
at
that
point
anyway,
and
with
a
stack,
cleanup,
op
code,
it's
easier
to
price,
because
you
have
the
extent
and
how
many
you're
keeping
is
part
of
the
call
in
it.
So
we
could
scale
the
cost
up
appropriately,
just
by
looking
at
the
operation
and
not
looking
at
the
stack.
B
So
that's
if
it,
you
know,
if
an
implementer's
opinion
matters
I,
think
that's
what
I
would
prefer
seeing
to
solve.
Some
of
the
security
concerns.
F
I
mean
I
I,
don't
have
any
problem
with
Jump
app
and
treat
f
without
stuck
cleanup.
I
think
that's
I
mean
unless
I
find
something
when
I
actually
start
writing
the
exact
text
for
it.
But
it
looks.
It
looks
okay
to
me
to
have
three
of
these
instructions
for
function,
manipulation
and
yeah.
They
can
be
I
either
enriched
with
stack
clean
up
later,
because
I
think
we
can
yeah.
We
can.
We
can
like
kind
of
break
it
with
backwards
compatibility.
A
F
A
Yeah
Daniel:
do
you
have
any
comments
on
how
useful
this
would
be
if
the
jump
F
in
redf
don't
do
the
stack
cleanup,
but
we
have
a
separate
op
code
that
performs
the
operation
I,
think
that
would
give
the
same
behavior.
H
B
H
A
Yeah
I
think
I'm
pretty
positive
on
that:
okay,
yeah,
probably
systems
up
I
think
we
should
do
that.
I
think
we
should
Reserve
that,
should
we
reserve
only
one
like
is
there
any
other
like?
Should
we
reserve
three
places
there
at
the
end?
Is
there
another
Paul
says
Max
it
at
200.?
B
H
I
mean
so
far
we're
basically
in
the
amount
of
16
because
of
the
stack
height,
the
accessibility
anyways.
So
if
in
Cancun
we
consider
663,
then
we
can
fix
all
this,
but
it
doesn't
need
to
be
fixed
before
and
before
that.
128
would
be
enough.
I
think.
A
So
right
now
we're
talking
about
reserving
the
upper
byte
of
sorry,
which
I'll
code
were
we
talking
here.
G
Sorry,
I
I'm
still
much
in
favor
of
keeping
return
f
as
simple
as
possible
and
having
any
cleanup
go
to
a
separate
op
code
that
we
can
design
more
carefully.
A
Yeah
so
I
think
the
proposal
right
now
is
to
reserve
the
upper
byte
in
the
type
section
of
outputs
and
so
for
now,
we'll
require
a
maximum
of
128
outputs
for
the
function
and
at
some
later
points
maybe
Cancun.
We
can
either
open
it
up
or
make
a
decision
on
how
to
use
that
upper
band
of
outputs,
and
we
will
specify
a
deep
pop
memo
type
of
op
code.
I.
A
A
Okay,
we
have
nine
minutes
left
there's
a
few
more
things
to
talk
about.
I
mentioned
this
one
little
thing
that
kind
of
came
up
when
I
was
reviewing
some
of
the
proposed
test
vectors
for
eof.
There
is
some
discussion
about
disallowing
unreachable
code.
That's
not
in
the
spec
right
now.
It's
not
part
of
the
validation
spec
as
far
as
I'm
aware.
A
Okay,
that
seems
pretty
convincing,
that's
something
we
need
to
put
into
the
Eeps
and
the
unified
spec,
because
it's
not
there
yet,
but
we
can
get
those
updated.
G
G
You
know
how
do
you
know
that
without
traversing
the
code
and
if
nothing
there
is,
if
nothing,
there
is
not
executable,
you
don't
have
to
you.
Don't
have
to
do
that.
G
This
is
a
question
because
I'm
lost
in
specs
I
think,
some
of
which
aren't
up
to
date.
Yet
we
have
the
max
height
field
now,
which
I
don't
see
in
the
call
F
spec
yet
and
I'm,
not
clear
on
whether
the
author
of
the
routine
fills
that
in
or
it's
getting
filled
in
by
the
validator.
A
G
A
Dano
says
red
f,
with
an
empty
return:
stack
is
an
exception.
Correct
I,
don't
think
it's
possible
to
have
an
empty
return,
stack
red
Earth
in
section
zero
in
section
zero.
Before
you
start
the
execution,
you
actually
push
all
zeros
onto
the
return
stack.
B
F
H
A
A
Thanks
five
minutes
left
two
more
things
to
discuss:
I
wanted
to
take
a
moment
to
just
talk
about
the
timeline
for
eof
and
Shanghai
I.
Think
most
people
here
were
on
all
core
devs
or
kind
of
aware
that
we're
sort
of
sprinting
towards
this
January
5th,
all
core
Dev
State,
that's
the
first
one
in
2023
and
they've,
requested
that
we
have
eof
implemented
in
clients
and
that's
kind
of
like
the
first
gate
of
that.
A
A
Yeah
I
would
have
much
rather
be
doing
this
in
the
fall
or
the
summer,
but
we
have
this
chance
of
shipping,
eof
and
I
think
we
need
to
take
advantage
of
it,
and
so
I
will
be
available
as
much
as
I
can.
If
anybody
has
questions
or
things
that
need
to
be
done,
I
can
try
and
do
it.
A
Yeah
I
think
it
sounds
like
most
people
have
implemented
eof
and
we're
just
trying
to
finish
these
last
few
things.
I
think
if
we
can
have
these
spelled
out
in
the
spec
tomorrow
end
of
the
day
that
you
know
will
give
people
a
week
and
a
half
of,
like
you,
know,
sort
of
holiday
working
time
to
try
and
resolve
a
couple
of
those
things.
A
I'll
try
and
be
working
on
tests,
hopefully
by
the
next
eof
call,
which
I
think
we
scheduled
for
the
29th
of
December
I'll
have
to
double
check
the
Discord,
we'll
have
cross-client
tests
that
we
can
start
verifying,
and
then
that
will
give
us
a
couple
days.
The
beginning
of
2023
for
client
implementers
to
review
the
status
of
the
test
and
resolve
to
some
of
those
things
and
I
think
if
we
come
into
that
for
January
5th,
that's
a
good
place
to
come
into
the
last
thing.
To
just
mention
is
this
post
by
vitalik
I?
A
Think
a
lot
of
people
have
seen
it,
but
just
if
you
haven't
I
would
take
a
look.
Basically,
metallic
is
making
a
case
that,
if
we're
going
to
upgrade
the
evm,
there
are
new
possibilities
that
we
could
have
if
we
make
certain
decisions,
and
this
possibility
that
he's
interested
in
is
forced
upgrading
code
that
hasn't
been
possible.
A
Really,
that's
wouldn't
be
possible,
with
the
currently
specified
eof
version,
due
to
the
fact
that
we
can
introspect
code
and
so
he's
proposing,
maybe
Banning
op
codes
that
allow
for
code
introspection,
unfortunately,
that
it
means
a
lot
of
op
codes
would
be
altered
or
banned.
We
would
have
to
change
how
Legacy
contracts
call
these
op
codes
into
eof
contracts,
I.
Think
it's
like
it's
a
relatively
big
change
and
I
think
that
that's
going
to
get
discussed
on
this
all
core
devs
and
I'm.
Not
really
sure
what
the
outcome
of
that
will
be.
I.
A
Don't
think
that
there's
much
that
we
can
do
in
the
time
between
now
and
then
to
resolve
the
questions
that
vitalik
has
raised
and
I
think.
The
best
thing
that
we
can
do
is
come
to
all
core
devs
on
January
5th,
with
big
eof
and
clients
and
cross-client
tests
and
stuff,
and
then
see
how
important
people
feel
one
thing
that
we
might
be
able
to
do
that
doesn't
really
resolve
any
changes
or
it
doesn't
require.
A
Any
changes
is
to
sort
of
make
this
commitment
to
people
that
code
introspection
is
actually
similar
to
the
gas
schedule
you
shouldn't
be
using
it
in
you,
shouldn't
be
using
it
in
contracts,
with
the
assumption
that
it's
never
going
to
change.
A
We
can
make
the
commitment
that,
obviously,
if
you
call
a
contract,
it's
going
to
return
the
same
value
forever,
but
if
you
call
code
size
on
that
contract,
it
might
change.
That's
like
one
possibility.
Another
possibility
is
just
being
extremely
ruthless
with
banning
all
of
those
OP
codes
and
maybe
adding
things
back
in
as
we
find
a
solution,
but
yeah
that's
sort
of
the
status
with
that
again
I
think
maybe
we
should
focus
on
the
big
UF
implementations
before
we
spend
too
much
time
thinking
about
how
to
resolve
those
concerns.
A
E
E
Some
of
the
early
documents
have
tests
explained
and
data
copy
would
be
used
for
the
data
section.
Obviously,
if
any
of
this
introspection
stuff
is
removed,
you
would
need
to
have
something
like
that,
ideally
because
a
lot
of
contracts
depend
on
so-called
immutable
variables
which
are
encoded
in
in
such
a
way
and
loaded
with
the
code
copy.
Currently.
So
for
that
you
would
need
data
copy,
but
I
guess
this
is
more
like
a
a
usability
question.
E
However,
the
the
second
point
is,
even
if
you
disable
introspection
from
within
the
UF
UF
code
outside
from
Legacy
code
can
still
be
inspected,
and
you
cannot
I
mean
you
can
only
give
like
verbal
commitments
there
that
you
shouldn't
do
that,
but
if
people
start
to
do
that
and
rely
on
that,
will
that
mean
that
all
of
this
was
for
nothing,
because
you
still
cannot
update
it.
E
So
I
think
that's
like
a
bigger
meta
question,
but
personally
I
mean
I'm
interested
in
restricting
stuff
and
we
actually
had
these
to
some
extent
discussed
last
year.
It's
a
way
before
you
know
it
came
up
last
week,
but
we
felt
like
it
would
be
like
a
an
immense
amount
of
changes
and
hence
we
didn't
fully
explore
it
at
the
time.
H
C
Yeah
just
to
ask
about
testnet
just
thinking
it
would
be
very
useful
to
have
a
full
eof
test
net
sooner
rather
than
later.
Obviously
you
know
if
the
specs
are
still
moving
a
little
bit,
maybe
not
so
great,
but
just
the
thought
that
we
should
really
move
on
that
soon.
A
I
personally
feel
that
cross-client
testing
is
a
higher
priority
than
test
Nets.
It
would
resolve
like
I.
Think,
there's,
like
you
know,
less
interoperability,
things
to
concern
with,
because
it's
not
changing
like
any
of
the
networking
blockchain
structure
more
or
less
it's
something
we
want
to
do
ASAP
but
in
my
mind,
like
order.
Our
operation
right
now
is
finalized.
A
Spec
work
on
cross-client
tests
and
test
nut,
I
think
cross-client
tests
and
testnet
can
be
done
mostly
in
parallel,
but,
like
personally,
I
will
be
working
more
on
testing
specifically
if
we
can
get
this
spec
finalized
in
the
next
day
or
two,
and
you
know,
people
want
to
help
run
this
house
at
end
of
next
week
like
let's
do
it,
but
that's
where
my
mind
is
or
three
minutes
over
time.
Any
last
comments.
A
Agreed,
we
definitely
want
to
be
doing
a
test
net
by
the
next
UF
call,
which
I
believe
is
January,
29th,
I'm,
really
sorry
or
sorry.
December
29th
I'm,
really
sorry
that
we're
doing
yeah
breakout
rooms
this
time
of
year
but
I'll,
be
there
there'll,
be
time
to
discuss
any
questions
or
comments
that
have
come
up
and
hopefully
we'll
have
test
out
by
then
anything
else.
A
Great
thanks
a
lot
everybody
please
yeah
share
any
comments
or
questions
in
the
evm
channel
on
Discord,
we'll
work
on
finalizing
the
spec
I
think
that
there
were
about
three
or
four
decisions
that
we've
like
roughly
made
we'll
send
an
update
with
yeah
that
stuff
being
resolved
here
soon.