►
From YouTube: EOF Implementers Meeting 8
Description
A
Hi
everyone-
this
is
eof
implementers
call
number,
eight
and
I
think
this
will
be
a
short
one,
because
a
lot
of
people
are
often
on
holidays
I.
Think,
usually
we
go
through
around
just
to
see
what
everyone
did.
A
B
We've
had
we
have
your
F1
implemented.
We
haven't
done
much
movement
on
1.1
waiting
for
some
of
the
specs
to
settle
for
exactly
what
needs
to
be
implemented.
In
the
interim,
we've
got
out
of
the
CNN
tool
implemented,
which
should
help
getting
reference
tests.
B
I
know,
Dimitri
was
pretty
excited.
We
saw
the
first
PR
come
through.
B
It's
not
quite
ready
yet
there's
some
packaging
issues,
but
that's
we've
been
focusing
on
getting
working
so
that
if
things
get
wherever
I
think
he's
gonna
Blended
first,
they
can
get
tested
first,
rather
than
having
to
wait
for
the
get
implementation,
and
it
seems
like
we're
all
settling
on
the
t8n
tool
for
the
interface
rather
than
the
retest
death
interfaces,
because
the
testing
team
has
been
pointing
never
mind
and
evm1
that
tool
instead
of
standing
up
the
RPC
server.
B
So
that
should
improve
the
testing
story
when
we
get
to
final
implementation,
to
provide
better
vectors
for
us
to
do
differential
testing
against
and
also
so
that
any
client
with
the
correct
answers
can
create,
can
fill
the
tests.
So
that's
what
we've
been
doing
the
past
couple
of
weeks.
B
Right
right
in
Cancun:
well,
it's
it's
targeted
at
Cancun,
even
though
the
tests,
the
reference
tests,
still
Target
Shanghai.
That
needs
to
be
fixed.
So
if
you
target
Cancun
eof
V1
should
be
turned
on
ready
to
test
I'm
sure,
there's
differences
in
there.
We
just
haven't,
you
know
done
a
full
differential
run.
So.
C
We
didn't
merge
it
yet,
since
we
are
still
doing
some
optimizations
and
some
trying
some
stuff
out
when
it
comes
to
UF,
v1.1
and
or
your
V2,
we
still
haven't
started
on
that
stuff,
still
waiting
to
see
what
what
happens
and
what
we
decide
and
yeah.
That's
mostly.
It.
D
But
I
actually
would
like
to
ask
you
Alex.
One
thing
is
that
like,
since
we
have
eof1
and
eof
1.1,
when
we
are
going
to
the
hard
Fork,
it's
gonna
be
1.1,
it's
not
going
to
be
one
correct,
so
we're
gonna
go
right
away
with
eof
1.1
without
the
first
version.
D
Okay,
just
making
sure
because
yeah
then
I
would
ask
what
is
the
status
of
the
spec
or
finalization
of
the
spec
of
eof
1.1?
Is
there
anything
to
discuss
about
the
spec
of
1.1
I?
Obviously
we
don't
have
probably
enough
attendance
to
discuss
a
lot
of
things,
but
yeah.
A
Yeah,
there's
there's
definitely
a
lot
to
discuss.
I
mean,
let
me
give
just
a
brief
update
from
Epsilon
and
then
we
can
jump
into
the
discussions.
A
So
from
Epsilon
I
mean
just
starting
with
evm1,
they
also
fully
emerged,
T8
and
support
which
yeah
I
think
it's
it's
not
like.
100
Complete,
because
things
like
supporting
the
logs
Bloom
filter
that
is
being
implemented
currently
there's
a
PR
for
it
and
there's
also
work
for
the
b11r,
but
the
currently
merged
version
is
already
capable
of
filling
tests.
Eof
tests,
however,
the
complete
I
mean
the
big
eof
support
is
a
merging
to
evm1.
A
That
is
the
next
goal
to
be
merged
and
then
evm1
could
also
be
used
to
field
tests,
but
since
Basu
has
it
implemented,
maybe
basically
is
the
best
client
currently
just
affiliof
tests
separately.
To
this
we
have
a
PR
on
which
Android
is
working,
which
is
basically
EOS
2.0,
so
it's
APR
for
create
tree
and
the
return
contract,
and
the
goal
of
this
is
just
to
have
a
working
implementation
to
discover
any
any
issues
we
didn't
really
think
about,
and
we
in
fact
we
did
find
some
cases
like.
A
We
need
error
handling
when
the
auxiliary
data
is
larger
than
what
would
fit
into
the
data
section.
So
I
think
it.
It
is
a
useful,
a
way
to
to
prototype
test
and
get
more
data
on
it
and
then
separately
outside
of
evm1.
A
We
did
a
complete
review
of
the
checklist
and
updated
the
status
of
every
single
client
and
also
the
testing
suite
and
regarding
the
testing
speed
from
our
side,
it
seems
to
be
like
mostly
complete.
Vr7
is
submitted
for
every
single
EIP,
including
54.50
I.
Think
the
last
two
is
this:
4750
and
5450
tests
haven't
been
merged
yet,
but
PR's
exist
with
the
test
cases
we
wanted
to
have
for
them.
A
So
from
that
perspective
we
kind
of
consider
lucky
with
one
almost
complete,
with
the
exception
of
at
least
one
discussion,
which
is
the
type
section
Flags,
and
for
that
I
posted
a
document
with
a
number
of
different
proposals
had
to
accomplish
that.
The
main
point
for
this
type
section
of
flags
is
to
support.
Non-Returning
functions,
I
mean
that
is
the
immediate
need.
A
We
want
to
fill
because
that
feature
has
been
requested
from
solidity,
but
as
part
of
this
discussion,
it
opens
up
the
door
to
support
more
flags
and
some
ideas.
We
discussed
that
we
could
have
pure
Purity
level
so,
like
pure
view,
functions
and
beyond
that
I
don't
well
yeah
the
other
option,
the
other
like
feature.
We
thought
about
that.
Maybe
one
could
Mark
any
code,
but
that
seems
to
be
even
less
useful.
A
The
point
is
that
we
are
unsure
whether
anything
like
Purity
makes
sense
or
any
anything
else
could
make
sense,
and
that's
why
we
would
like
to
discuss
this.
This
document
and
I
think
this
is
the
likely
the
last
discussion
needed
to
close
down
eof1
and
and
then
we
can
move
on
to
to
1.1,
for
which
no
proper
spec
access,
but
my
plan
was
to
to
modify
to
create
a
copy
of
the
unified
spec
and
modify
it
to
you
know
to
include
the
the
changes.
A
The
the
alternative
is
to
have
like
one
document
which
just
describes
the
differences
to
eof1,
but
we
already
have
such
documents
so
I'm
not
sure
what
is
the
best
option.
Having
like
you
know,
a
diff
or
having
like
this
complete
UF,
1.1,
unified,
spec
and
I
kind
of
bled
into
like
discussions
apart
from
the
updates
but
yeah,
should
we
discuss
these
like
to
be
your
questions,
or
do
you
guys
have
any
any
questions
to
the
updates?
I
gave.
A
Yeah,
the
the
non-returning
functions
means
that
a
given
function
wouldn't
be
returning
to
the
color,
and
the
significance
is
that
right
now
we
need
to,
if
you
are
so
by
calling
you
need
to
to
make
sure
that
the
the
Kohli
has
exact
number
of
outputs,
because
the
the
the
outputs
are
validated
and
the
main
use
case
solidity
has
is
have
like
an
error
handling
function
and
they
want
to
share
this
error
handling
function
across
a
number
of
other
functions
and
the
colors
likely
have
very
different
number
of
outputs
and
in
the
current
system
they
cannot
really
share
the
same.
A
They
can't
really
easily
share
the
same
error
handling
functions
so
that
that's
the
the
main
use
case.
When
we
Mark
a
function
on
returning,
then
the
the
number
of
outputs
are
don't
need
to
be
validated.
D
A
No
I
just
didn't
understood
what
what
app
could
you
refer
to
or.
D
Like
yeah
for
me
it,
the
question
is:
if
we
can
use
an
unreturning
function
as
a
like
terminating
instruction,
that
would
really
complicate
the
code
that
we
use
for
validation
to
validate
that
the
code
ends
with
the
terminating
function
instruction,
because
that
means
that
if
we
have
a
call
method
instruction
at
the
very
end,
we
have
to
check
that
the
call
is
calling
an
unreturning
function,
and
if
it's
not,
then
we
will
like
say
that
it's
not
valid,
which
increases
the
complexity
of
the
validation
operation.
D
Is
that
something
that
we
would
like
really
would
like
to
introduce
or
allow
or
or
do
we
just
say?
No,
we're
not
gonna.
Allow
call
function,
call
to
be
a
terminating
instruction,
and
that
means
that
after
it
we
will
have
to
do
return
or
something.
A
No,
so
we
have
another
instruction
which
was
part
of
4750,
but
it
has
been
removed
and
moved
into
another
VIP,
which
is
to
jump
if
jump,
to
function
and
that's
the
way
you
would
use
non-returning
functions,
you
would
jump
to
them
and,
and
so
the
jump
f
is,
is
basically
a
terminating
instruction
got.
A
So,
as
you
can
see
in
the
without
having
like
this
non-returning
flag,
let's
say
you
call
into
a
function
and
that
jumps
to
another
one
and
where
you
jumped
returns
this
this
target
function
has
to
have
the
same
number
of
outputs
as
the
first
one
right.
A
That's
the
current
case
and
introducing
this
non-returning
flag
removes
this
requirement.
B
But
if
it's
not
returning,
it
wouldn't
have
any
return
values
anyway
with
it.
Well,
you
could
have
multiple
people
jump
into
it
then
I
get
it
then
now.
So
if
one
question
I
have
is
if
these
flags
are
there,
if
you
have
a
non-returning
function
and
you
don't
flag,
it
is
that
a
validation
error
or
is
it
an
option
to
flag
one
that
matches
it
or
do
all
functions
that
match
the
case
have
to
have
the
flag.
B
A
B
Now,
okay,
so
that's
that's
one
thing:
I
would
want
to
clarified
in
this
spec
that
the
flags,
whether
or
not
the
flags
have
to
be
put
on
functions
that
match
the
standards
or
if
they
may
be
put
on
the
functions
that
match
the
standards,
because
if
it's
May,
that
simplifies
the
issue
for
the
compiler
and
if
it's
a
must
I
mean
if
it's
all
done
ahead
of
time
and
we're
not
analyzing
it.
B
You
know
that's
it's,
it
could
possibly
be
quadratic
for
the
compiler,
but
who
cares
about
people
with
radic
for
the
compiler,
because
you
can
always
cancel
it
as
long
as
it's
linear
for
validation,
so.
A
A
A
A
D
A
So
share
that
document
in
the
chat
here
but
I
associate
it
I.
Think
last
week,
sometime
on
Discord
and
the
short
answer
is
we
don't
know
if
anything,
so
we
like
fairly
certain
and
the
non-returning
flag,
makes
sense
somehow
indicating
it,
but
we're
unsure.
If
anything
else
really
makes
sense,
we
I
mean
like
this.
Purity
stuff
is
something
we
identified
as
like,
potentially
maybe
useful
and
I
think.
A
The
main
discussion
we
have
been
going
around
is
what
to
anticipate
and
how
much
effort
do
we
need
to
put
into
forward
compatibility
and-
and
they
came
up
with
a
number
of
different
options
had
to
to
represent
this.
If
we
want
to
support
multiple
Flags,
if
we
only
want
to
support
this
non-returning
feature,
we
already
kind
of
have
an
answer
to
that.
We
kind
of
have
a
special
value
in
the
outputs,
because
we
already
restrict
the
the
outputs
to
seven
bits.
A
So
we
could
We
have
basically
two
options
there.
We
just
use
like
a
reserved
value
like
0ff
for
the
outputs,
or
we
could
treat
the
the
top
bit
as
a
signal
and
then
use
the
the
bottom
seven
bits
just
like
a
bit
a
bit
set,
and
so
one
example
is.
We
could
have
the
value
81
and
hex,
which
is
the
top
bit
set,
and
the
lowest
bit
set
to
signal
that
this
is
non-returning,
and
then
we
still
have
options
together
like
Flags
in
the
outputs.
A
B
So
a
couple
of
uses
I
could
see
for
these
flags,
but
this
is
only
an
eof
world
would
be
for
like
each
call.
When
you
set
the
static
flag,
you
can
verify
it
along
the
way
you
can
do
quicker.
Approving
that
the
call
is
going
to
be
static,
we
could
require
the
static
plaid
for
some
of
those.
Similarly,
for
just
in
time,
compilation
of
the
code,
you
can
look
at
the
flags
to
make
assumptions
about
the
compilations.
B
My
question
is:
is
it
worth
imposing
that
analysis
on
everyone?
When
only
you
know
hypothetical
implementations
would
be
using
these
flags?
Is
this
the
return
of
the
the
bloom
bits
in
the
receipt,
so
I
think
it's
it's
cool
but
I'm
I'm
concerned
about
the
utility.
A
Also
just
to
make
sure,
even
if
we
think
that
this
Purity
makes
sense,
I
don't
think
we
would
introduce
this
feature
in
you
know
1.1
or
2.0
or
anytime
soon.
We
would
just
want
to
make
sure
that
the
header
is
forward
compatible
to
support
us.
C
I
have
a
few
questions.
First,
this
Purity
thing
that
all
the
other
flags
aren't
they
compiler
specific,
like
the
compiler
needs
them
to
emit
specific
code
or
optimized
code,
but
should
they
be
visible
to
the
VM
if
we
might
not
be
in
need
and
then
and
also
the
other
question
is
what
happens
after
running
a
non-terminating
functions
function?
Do
we
just
stop
interpretation?
The
batch
code?
If
so,
doesn't
a
function
section
ending
with
a
stop-up
code?
Do
the
same
thing.
A
Yeah
I'm
just
going
to
briefly
answer
if
anybody
else's
other
opinions
than
give
it
after
select
this
topic
of
code,
wherever
the
stop
code
is
that
just
terminates
execution
successfully
with
not
returning
anything
in
the
written
buffer
or
written
data
buffer,
the
non-returning
functions
I
mean
if
they're
working
on
returning.
A
It
just
means
that
they're
not
returning
to
the
caller.
They
have
to
be
terminating.
They
have
to
have
like
a
terminating
instruction
at
the
end,
so
they
still
have
to
clearly
stop
execution
and
regarding
the
the
purity,
if
we
would
have
Purity
Flags
in
the
type
section
that
would
have
to
be
enforced
by
validation,
and
what
that
means
is
that
those
given
code
sections
couldn't
use
Specific
Instructions.
A
D
I
mean
like
about
the
view,
and
the
pure,
like
I,
understand
the
appeal.
But
again
what
is
the
use
case
like
what
what
benefit
will
they
bring
to
the
AVM.
A
I
would
say
it's
more
like
a
security.
I
mean
two
two
cases
where
it
helps
it's.
It
could
help
with
security,
and
it
could
also
help
it
execution
time
because
one
could
translate
different
functions.
A
Yeah
I
see
I
mean
you
said:
eot
yeah,
exactly
I
mean
if,
if
you
know
that
some
of
these
don't
really
touch
States,
you
may
yeah,
you
may
have
like
more
efficient
options.
A
I
mean
to
be
honest,
we
haven't
really
explored
like
the
concrete
usefulness.
It
does
seem
to
be
useful,
but
just
stating
again
the
main
reason
we
discuss
this,
whether
we
want
to
be
future
compatible
and
have
a
flex
field.
First
of
all,
and
if
none
of
these
make,
if
you
don't
want
to
be
feature
compatible,
then
we
should
just
choose
the
easy
option:
have
a
special
value
for
the
non-returning
functions.
E
A
Yeah,
so
anybody
has
like
any
other
hunch
if
any
another
flag
would
be
useful.
Generally,
apart
from
the
ones
we
discussed
any
other
feature
which
could
be
enabled
reflex.
A
You
mean
like
use,
reverts
or
have
unexpected
failures.
You
know
like
out
of
gas
or.
A
B
Yeah
I'm
weakly
against,
because
I'm
concerned
about
the
the
effort,
return
ratio
that
we're
going
to
get
out
of
this
I'm,
not
seeing
what
critical
spaces
is
opening
up
that
can
only
ever
be
opened
up
now,
because,
if
we
needed
to,
we
could
get
another
format
where
we
could
put
flags
at
a
different
section
that
we
could
add
later,
rather
than
having
to
put
it
into
the
type
3
section,
not
type.
Three
like
the
client
three
data,
so
I'm
hesitant
to
get
fully
on
board
with
this.
B
B
A
B
Yeah
and
you
know
creating
space
for
things
that
we
might
have
I'm
afraid
we're
going
to
wind
up
with
something
like
you
know
the
bloom
bits
again
in
the
receipt,
something
that
sounded
like
a
good
idea
that
no
one
ever
actually
implemented
that
you
know
are
continuing
to
impose
restrictions
on
us
as
we
go
forward.
D
And
I
can
right
now
after
I
heard
his
argument,
I
kinda
agree
and
the
whole
idea
of
bof
is
that
upgrades
can
be
virgined
and
contracts
can
be
virgined
and
since
everything
is
Virgin,
what
what
preventing
us
from
just
introduced
these
new
flags
that
are
needed
later
on
with
the
new
version,
and
we
can
easily
upgrade
old
contracts
into
new
contracts
with
this
version
with
these
flags,
because
we
can
probably
introspect
the
code
and
see
that
like
this
function
does
not
return
and
we
can
flag
it
in
that
case,
if
needed,
but
yeah
basically.
D
We
can
also
check
like
if
we're
gonna
have
a
pure
flag
or
a
view
flag.
We
can
check
what
type
of
instructions
are
executed
inside
this
function,
and
if
there
is,
if
these
fun
app
codes
are
not
used,
then
we
can
mark
it
with
these
flags
also,
so
the
upgrade
path
is
clear
and
there
is
no
need
to
include
it
from
now.
B
A
A
I
kind
of
agree
that
we
have
the
the
flags,
or
this
exact
reason
that
we
can
make
upgrades.
A
But
at
the
same
time,
reflecting
to
the
past
couple
of
months,
it
seems
to
to
be
a
lot
of
pushback
in
terms
of
having
multiple
versions.
So
maybe
that
just
means
you
know
we.
The
version
is
really
just
the
Last
Resort,
and
you
know
for
things
like
this.
A
A
Maybe
the
system
isn't
perfect.
Yet.
D
D
I'm
I'm
pretty
sure
it
goes
against.
The
whole
idea
of
eof,
like
the
whole
idea,
is
that
we
we
want
to
have
things
be
clear
as
if
it's
this
specific
version,
then
it
has
these
specific
set
of
handling
of
instructions
and
validations,
etc,
etc,
etc,
and
that
anything
that
changes
it
needs
a
virgin
bump
that
that
was
the
premise.
As
far
as
I
knew
I
don't
know.
B
D
A
B
The
pushback
that
I
recall
from
from
the
offside
interop
is
that
they
want
a
future
world
where
clients
only
need
to
have
one
version
of
the
evm
for
a
current
Fork
I
mean
they're
not
doing
any
historical
validation.
They
can
get
rid
of
it
and
remove
it.
So
we're
going
to
be
stuck
with
at
least
two
because
of
legacy
and
eof,
but
they
don't
want
to
have
like
five,
because
it's
worth
the
four
different
versions
of
eof.
B
So
that's
the
reason
why
they
want
the
pushback
so
that
so
that
at
a
current
Fork
there's
only
the
eof
version
and
the
Legacy
version.
So
so
we
would.
If
we
were
to
do
a
breaking
change,
we
would
need
to
have
some
sort
of
a
a
transpilation
that
we
could
point
at
the
old
contracts
to
bring
them
into
new
States.
B
So
that's
some
of
the
pushback
against
just
adding
an
inversion.
Is
they
don't
want
out
of
control
code
growth,
like
we've
experienced
with
the
current
Legacy
version
of
of
the
evm?
We've
got
basically
on
nine
versions
that
you
need
a
tweak
and
and
configure
your
evm
to
be
able
to
validate
all
stuff
back
in
the
previous
history.
B
Once
they
saw
the
previous
history
version,
then
you
don't
need
night
versions,
but
then
you
know
they
don't
get
rid
of
the
thing
where
they
still
have
to
have
two
versions
of
the
evm.
So
they
want
to
try
and
put
a
lid
on
that.
That's
that's
where
some
of
the
the
desires
to
not
have
multiple
versions
at
the
same
time
and
I
think
the
compromise
we're
willing
to
make
is
there's
not
multiple
versions
of
eof.
E
Adding
a
pure
is
is
compatible.
We
don't
need
to
to
bump
the
version,
because
if
something
isn't
marked
pure,
it
doesn't
matter
that
it
is
in
fact
pure.
Adding
a
pure
flag
later
just
allows
us
to
check
that
something
that
the
author
claimed
to
be
pure
was
in
fact
pure,
but
it
has
no
effect
on
what
went
before
so
yeah
as
much
as
possible.
We
can
add
new
features
without
without
breaking
anything.
B
But
the
concern
I
have
is,
if
you
care
about
peer,
you're,
probably
doing
analysis
anyway,
and
you
could
get
the
answer
that
it's
pure
without
the
flag.
So
why
are
we
requiring
everyone
to
calculate
and
validate
pure
when
the
utility
cases
for
the
pure
flag
exist?
If
you're
not
existing,
are
kind
of
small
I'm
concerned
that
we're
pushing
work
on
everyone
for
something
that
only
one
implementation
might
benefit
from
and
then,
by
my
benefit,
I
mean
they
could
actually
calculate
it
themselves,
since
they
already
care
about
that
data.
B
E
Yeah
I
don't
know,
but
it's
more
like
stating
the
number
of
arguments
to
a
function
you're
just
stating
part
of
the
interface
that
you
can
check,
checking
it
checking
it
at
validation
time.
Otherwise,
you
can
do
for
optimization
purposes,
but
not
for
checking
the
interface
and
I.
Don't
I,
don't
know
how
far
we
might
want
to
go
with
that,
but
anything
that
you
can
specify
about
the
interface
to
be
checked.
A
validation
time
increases
the
type
safety
of
your
program.
B
Right,
but
in
the
case
of
function,
arguments
we're
actually
matching
up
to
make
sure.
Well,
let's
make
sure
that
we
have
this
many
on
the
stack
before
we
proceed,
so
that
count
has
an
impact
on
the
interpretation
time,
whereas
the
impact
of
a
pure
in
theory
has
no
impact
on
the
interpretation
time.
B
I
don't
see,
I
I
would
need
to
be
presented
with
some
some.
How
would
this
make
The
Interpreter
better?
How
would
this
make
a
you
know?
I
definitely
make
an
aot
compile
better
because
you
know
even
in
the
eot
compiled,
because
you
still
have
to
keep
in
the
message
frame
the
link
to
the
state
well
for
a
period
you
can
get
rid
of
it
to
the
state,
but
for
like
read
only
you
know
it.
What,
where
is
the
advantage
of
this?
E
I,
don't
know
that
it
adds
anything.
It's
it's
just
type
safety
at
validation
time.
You
don't
need
the
number
of
arguments
you
can
check
it
validation
time
that
the
stack
is
okay
without
stating
up
front
what
the
number
of
arguments
is.
You
can
just
check
at
validation
time
that
you
use
the
arguments
consistently.
So
any
of
this
is
a
matter
of
what
do
we
want
to
State
in
the
program
itself
to
type
check
and
validation
time
and
pure
sounds
useful.
E
I,
don't
have
a
strong
opinion
on
whether
we
should
have
Pierre
I'm.
Just
saying
that's,
the
point
of
it
is,
as
I
said,
there
might
be
other
points,
but
that's
the
main
one.
A
Your
reasoning
is
it's
correct
that
you
know
if
I'm
going
to
be
push
the
burden
on
everyone,
even
if
nobody
uses
the
feature
but
I
think
like
this
pure
and
view
is
actually
a
bad
example
for
that,
because
we
do
need
to
do
code,
validation
of
each
of
the
code
sections
and
what
this
flag
would
do,
it's
just
reduced
the
number
of
accepted
instructions
in
the
validation
run,
so
in
that
sense
it
doesn't
actually
put
like
extra
burden
on
the
VM,
because
the
validation
has
to
be
done
anyway,
but
yeah.
A
Otherwise.
I
definitely
agree
that
we
shouldn't
really
add
features
which
the
VM
wouldn't
benefit
from.
C
Yeah
I
was
just
gonna
say
that
I
kind
of
agree
with
you,
since
these
validations
for
pure
and
for
View
and
other
stuff
can
be
done.
They
would
be
done
once
they
will
not
be
done
twice
at
runtime
or
even
if
they
are
not
included
as
Flags
like
if
the
VM
implementer
needs
to
know.
If
a
function
section
is
a
pure
function
section,
they
don't
need
a
flag
to
verify
it,
because
the
flag
would
be
just
I
kind
of
went
the
case
of
to
to
validate
whether
the
compiler
is
telling
the
truth.
C
A
So
I
think
the
the
entire
debate,
whether
to
have
Flags
or
not
goes
back
to
this
one
premise:
whether
we
can
have
flags
and
then
introduce
features
without
bumping.
The
UF
version
right,
because
if
he,
if
he
cannot,
then
there's
no
point
having
like
a
forward
compatible
field.
C
C
To
be
honest,
this
feels
like,
like
a
very
primitive
effective
system,
that
we
are
trying
to
add
to
the
byte
code
here,
pure
total
or
whatever
other
effects
that
can
be
added,
but
I,
don't
think
the
VM
will
benefit
from
them,
since
we
can
just
verify
them.
If
our
VM
has
some
specific
implementations
that
are
interested
in
six
units,
so
we
don't
need
to
impose
them
on
everyone
to
have
to
validate
these
functions
or
these
flags,
while
we
know
that
only
certain
ones
will
need
it,
because
they
have
some
specific
technological
stuff.
D
To
so,
to
clarify
what
I'm
saying
is
that
if
a
client
is
seeing
a
benefit
in
having
in
defining,
if
this
function
is
pure
or
if
it's
view,
then
they
can
simply
while
validating
the
function,
check
the
op
codes
and
if
it
accesses
memory
and
load,
it's
a
view,
and
if
it
doesn't,
then
it's
a
pure,
and
in
that
case
they
can
flag
it.
But
without
imposing
this
on,
everyone
is
that
what
you're
trying
to
say,
Amen.
C
D
A
So
there's
one
more
use
case.
We
thought
about
is
the
init
code
marking
a
code
section
which
is
used
as
init
code,
and
there
have
been
like
a
number
of
different
designs
on
how
even
this
contract
creation
like
in
uf2,
would
could
work
and
with
these
Factory
contracts
you
could
definitely
have
like
multiple
edit
codes
in
the
same
container.
A
You
know
which
direction
we're
going
to
go
with
this
and
from
that's
that
reason,
just
having
just
mandating
their
that
the
first
code
section
is
in
a
code
is
good
enough,
but
there's
one
other
site
to
this
is
had
to
actually
finalize
the
creation
within
the
init
code
and
in
Legacy
we
just
used
return
op
code
to
return
the
entire
code.
A
A
So
The
Current
Designs
have
a
new
instruction
called
return
contract
which
take
a
memory
area
for
auxiliary
data
which
gets
appended
to
the
container
and
and
sorry
that
this
was
so
long-winded,
but
the
the
one
problem
or
like
it's,
not
the
big
problem,
but
just
one
thing
we
we
need
to
do
is
check
whether
we
are
in
an
init
code
context,
because
outside
of
that,
this
return
data
return
contract
should
not
be
valid.
So
if
we
would
have
this
init
code
as
a
flag,
then
we
could
easily
easily
validate
that
this
return.
D
B
We
were
also
contemplating
making
eof
quote
to
a
forward
compatible
that
doesn't
require
a
version
bump.
So
that's
part
of
the
design
space
that
we're
trying
to
keep
available
so
that
all
the
byte
codes
are
still
the
same.
It's
just
suddenly.
You
can
now
use
these
new
OP
codes
that
are
introduced
if
you
follow
the
rules,
so
there
is
also
a
path
for
keeping.
You
know
forward,
compatible
changes
that
don't
require
a
bump,
like
we've
been
doing
forever
in
the
Legacy
evm.
B
So
one
of
my
concerns
about
this
is
one
of
the
discussions
we
had
about
the
space
we
wanted
for
create
was
we
wanted
zero
ability
to
put
op
codes
in
memory,
because
that
has
I've
been
doing
a
little
bit
of
ZK
research?
That
has
a
very
positive
impact
if
the
execution
and
the
logic
are
entirely
separate,
so
I
mean
maybe
we
need
to
keep
it
open
just
in
case
it
has
for
net
code
and
just
do
the
bit
packing
and
don't
use
any
of
the
flags.
B
That
might
be
the
solution
that
we
have
here,
but
I'm
skeptical
of
some
of
the
flags
but
the
in
a
code
flag.
We
might
need
that
space
we
might
not
and
that
everyone's
going
to
use
a
net
code,
but
I'm
I'm
still
in
favor
of
solutions
that
involve
by
code
never
hitting
operational
memory.
That
would
make
things
a
lot
better
for
the
ZK
world,
but
I
think
might
open
up
new
possibilities,
but
that's
a
discussion
we're
going
to
have
in
a
much
future
date.
B
B
So
I
think
I
think
the
possibility
of
the
net
code,
flag,
I,
think,
is
a
strong
argument
to
the
possibility
of
a
pure
and
static
flag,
so
that
I
think
there's
there's
a
case
where
we
need
to
keep
the
Flags
open
but
not
specify
any
of
them
in
the
1.1
version.
But
just
outline
these
are
the
things
we're
considering,
but
we're
not
committed
to
shipping
any
of
them.
Yet.
A
Yeah
exactly
I
mean
we
wouldn't
Define
any
of
them.
We
only
have
five
minutes
left,
I
think
maybe
the
best
way
forward,
because
we
didn't
had
a
number
of
people
like
we
have
been
like
active
previously
on
this
call.
Maybe
we
shouldn't
do
a
final
decision
on
this
today
anyway,
so
I
would
suggest
that
you
know
all
of
you
just
think
about
this.
You
can
leave
comments
on
the
document
as
well
and
then
maybe
on
the
next
call.
A
We
should
be
in
a
position
to
make
a
final
decision
on
this,
but
there's
one
last
topic:
I
think
we
can
fit
into
the
three
minutes.
What
is
the
best
way
for
the
US
1.1
spec
and
the
number
of
options
I
see?
Is
we
just
create
the
diff
just
State?
You
know
how
it
changes
from
uf1.
A
Another
option
is
that
we
take
a
copy
of
this
unified
spec
and
just
modify
it.
So
it
has
everything
clearly
what
1.1
would
look
like,
and
then
you
know
whether
any
of
these
should
be
an
EIP
or
not.
So
what's
the
what's
the
view?
What
direction
should
we
go?.
E
I'm
not
sure
what
document
you're
referring
to
at
this
point,
but
I'd
really
like
to
see
a
meta
EIP
pulling
this
all
together,
because
we
have
a
lot
of
hack,
MD
sort
of
scattered
around.
It
seems
and
I
I
can't
always
find
them
and
I
can't
always
can't
always
use
them
effectively
because
I'm,
not
in
the
organization.
B
In
addition
to
a
meta,
EIP,
I
would
kind
of
be
in
favor
of
going
back
and
changing
the
eips
I
mean
these
never
shipped
in
a
proof
fashion.
So
they're
not
finalized
stuff
like
we
would
be
increasing
the
scope
of
what
operations
are
invalid,
we'll
be
adding
entries
to
it.
I
think
we
just
go
back
and
edit
that
e
to
add
it
to
it.
B
As
far
as
as
far
as
the
differential
and
people
who
are
curious
about
the
history
can
just
go
back
to
the
get
the
GitHub
and
look
at
the
state
of
the
spec
at
a
certain
time.
So
that's
you
know.
Maybe
in
the
comment
stream,
we
could
Point
them
to
a
static
copy
of
the
markdown
to
say
here's
what
the
meta-eat
looked
like
at
this
point
in
time
for
those
interested
but
I,
don't
think
we
need
to
keep
this
rejected
version
in
the
in
the
eip's
because
it
wasn't
ever
fully
shipped
and
finalized.
B
But
you
know
if
we
want
to
do
a
new
one
that
specifies
the
changes
on
top
of
those
three
eats.
That's
a
viable
path
too
or
five
heaps
are
ever
going
to
eat
through
this.
A
Yeah
I
think
the
only
reason
we
haven't
just
gone
and
changed
it,
because
we've
seen
a
value,
and
maybe
this
is
wrong,
but
we've
seen
value
that
the
the
clients
who
started
to
work
on
EOS
one.
They
can
complete
that
work
with
the
test,
Suite
as
it
is,
and
the
eips
and
and
then
then
maybe
it's
easier
to
once.
Everybody
is
on
on
the
same
page
just
to
modify
the
IPS
and
roll
out
the
the
UF
1.1
changes.
A
A
Yeah
I
think
baseball
is
not
affected,
that
much
because
basically
merged
everything,
but
we're
getting
that
in
mind.
What
would
you
are
you
guys
planning
to
merge
to
the
current
set
of
PR's,
which
is
uf1
or
if
you
do
like
this
1.1,
then
you
would
just
keep
them
open
and
then
do
the
changes
there.
What
is
the
plan.
C
D
Yeah
so
like
the
idea
is
that
we
don't
really
like
to
merge
stuff
if
it
is
not
tested
on
the
ethereum
tests,
consensus
tests,
etc,
etc.
So
we
keep
everything
in
a
PR
in
a
branch
we
keep
updating
it.
If
eorf
V
1.1
the
spec
is
finalized,
then
we
will
implement
the
changes
and
then
we
can
then
test
everything
once
the
tests
are
finalized,
it's
always
for
for
nevermind.
It's
all.
The
bottleneck
is
always
ethereum
tests.
In
my
opinion,
if
these
are
finalized,
then
we
can
move
a
lot
quicker.
In
my
opinion,.
A
Okay,
then,
since
we
are
like
on
the
top,
there,
I
think
my
suggestion
is
then
that
we're
gonna
probably
create
a
single
PR
on
the
eip's
repo
and
not
merge
it,
which
has
all
the
changes
and
we
can.
We
can
discuss
the
the
changes
there
and
hopefully
all
the
consensus
tests
are
or
execution
tests
are
merged
suit
enough
with
5450,
and
at
that
point
we
can
just
record.
A
And
so
if
people
want
to
test
for
uf1,
they
can
still
do
that
and
we
can
start
merging
the
IPS
at
that
point.
Does
that
sound
like
a
plan.