►
From YouTube: EOF Implementers Meeting 10
Description
A
B
A
D
A
E
A
E
C
F
Maybe
so,
today,
I
actually
I
recently
around
the
state.
Just
on
the
ev1
and
I
found
a
couple
of
actually
there's
six
Stacks.
It's
six
tests
failed,
but
those
that
are
related
only
to
two
different
two
different
issues.
One
is
that
probably
get
does
not
burn
all
the
gas
when
the
when
the
inevality
you
have
construct
is
being
deployed
by
the
create
instruction,
create
op
code
and
the
second
one
is
related
to
call
F
and
the
plug
that.
F
Let
me,
let
me
remind
a
minute.
It
looks
that
okay
I,
don't
remember
now
it's
it's
in
our
chart
described,
but
one
is
related
to
that
not
burning
all
the
gas
and
the
second
one
is
related
to
okay,
yeah
I,
remember
so
so
with
colf.
For
some
reason
for
a
couple
one
test,
the
get
implementation
throws
the
stack
Overflow
exception
when
it
should
not
be
from
there
so
yeah
and
that's
cool.
A
E
A
E
Yeah
I
can
give
a
brief,
update,
I
think
in
the
last
call,
or
maybe
the
the
one
before
that
we
kind
of
agreed
that
we
will
make
a
PR
to
the
EIP
to
describe
the
changes
to
the
eips
to
describe
the
changes,
and
we
actually
haven't
done
that.
Instead,
we
duplicated
the
unified,
spec
and
and
added
all
the
changes
to
it.
E
So
it
is
the
the
final
version
we
think
we
should
be
going
towards
which
includes
non-observability
of
code
and
gas,
which
implies
these
new
create
instructions.
We
do
have
two
different
create
instructions.
We
have
create
three
which
I
believe
we
already
kind
of
extensively
discussed
and
create
four,
which
is
this
new
version
taking
init
code
from
the
transaction
and
this
transaction,
the
change
we
have
in
the
transactions.
E
E
B
My
concern
that
was
my
comment
on
there.
My
concern
is:
if
we
ban
Legacy
from
calling
eof
delegate
call,
is
it
anything
that
operates
through
a
proxy?
An
upgradable
proxy
will
be
locked
out
of
eof.
They
will
have
to
continue
to
use
Legacy
and
that
puts
a
barrier
in
the
idea
of
getting
as
many
people
to
let
to
migrate
to
eof
as
possible.
B
So
that's
that's
my
concern
with
blocking
it
from
going
into
eof
leaving
eof.
It's
demonstrated
because
you
could
leave
eof
and
do
self-destruct
through
a
little
proxy.
You
know
a
little
nothing,
but
a
self-destruct
contract
and
get
away
with
it,
but
I'm
not
seeing
you
know,
since
we're
taking
away
features
from
eof
and
not
adding
them.
B
A
Right
yeah
I'm
generally
in
favor
of
trying
to
avoid
unknown
unknowns.
But
it
seems
like
in
this
case,
because
this
is
a
pretty
strong
use
case,
being
able
to
have
your
upgradable
contract
plan
to
eof,
and
maybe
we
should
consider
relaxing
that
restriction
unless
we
find
some
more
concrete
evidence
that
it's
not
a
safe
thing
to
do.
E
A
A
Are
there
any
outstanding
questions,
still
I
think
on
the
agenda.
You
said
you
wanted
to
talk
about
whether
it
was
still
an
idea
that
these
things
should
be
rolled
out
separately,
as
in
like
an
elf
one,
first
and
then
uf2,
adding
a
bunch
of
the
Banning
of
it
code.
Introspection
or
doing
just
all
of
the
eof
features
that
you
spec'd
out
in
one
go.
Should
we
talk
about
that.
E
E
E
We
need
to
decide
on
the
limits
and
the
cost
of
that
I
have
some
ideas:
how
to
determine
the
limit.
You
know
based
on
whole
data,
repricing,
eips
and
4844,
but
yeah
we
haven't
done
the
work
on
that.
Yet
so
that's
like
one
bigger
piece
missing
determining
the
the
limits
and
cost
of
the
Senate
code
list.
E
Yeah
I
mean
I
think
last
time
we
just
decided
that
the
the
create
transaction
you
know
regarding
the
nonce
and
we
always
include
the
the
transaction,
even
if
it's
it
has
invalid
the
UF
code
and
following
that,
we
don't
want
to
validate
this
right
that
the
transaction
level
we
only
want
to
validate
that
the
time
it's
used.
Otherwise,
the
cost
would
be
also
insane.
A
A
Its
entirety
yeah
and
it's
because
it's
accessible
as
part
of
the
block
execution
has
to
be
propagated
with
the
block,
whereas
The
Blob
data.
The
reason
it
can
be
cheaper
is
because
it's
only
receiving
like
the
hash
of
the
data
I
mean
I.
Guess
the
nodes
have
to
propagate
it
anyways.
So
there
could
be
a
debate
on
why
the
Bob
gas
is
going
to
be
that
much
cheaper.
E
E
A
E
There
one
I
mean
basically
it's
just
the
last
question:
the
the
Creator
contract,
but
this
kind
of,
in
conjunction
conjunction
with
the
the
hashing
question,
yeah
I,
don't
think
we
can
I
think
that
you
know
the
cost
of
of
the
net
codes
in
the
transaction,
that
that
is
something
we
can
research
async
and
come
up
with
some
price
and
agree
on
it.
But
this
hashing
probably
requires
more
brainstorming
and
coordination
hashing
at
the
Creator
contract.
B
C
E
E
Yeah
I
mean
I,
responded
to
this
I.
Don't
think,
there's
a
need
to
keep
it,
but
if
you
keep
it
the
code,
you
know
the
implementation,
it
wouldn't
be.
Like
A,
New,
Path
I
mean
not
necessarily
and
as
we
discussed
in
in
Edelweiss,
this
could
be.
The
6364
tool
could
be
removed
later
without
a
breaking
change
to
eof,
and
maybe
for
that
reason
it's
it's
fine,
just
to
keep
it
to
reduce
the
scope,
but
I
don't
have
a
strong
opinion.
Okay,.
C
B
A
D
B
So,
for
me
it's
a
scheduling
thing
it's
a
question
of
when
4844
is
actually
going
to
ship.
If
it's
looking
at
a
Q4
minute
activation,
you
know
I
think
we
could
conceivably
get
mega
ready
by
then.
If
we
push
hard
but
I
think
another
option
we
want
to
consider
is:
if
4844
is
looking
at
the
Q3
banded
activation,
particularly
early
Q3,
as
in
we
start
talking
finalizing
tests
and
closing
out
scope
just
as
soon
as
the
current
hard
Fork,
not
Cancun
yeah
as
soon
as
Shanghai
ships.
B
B
A
It
could
become
the
lead
for
Prague
because
vertical
trees.
It's
unclear
where
things
are
at
with
that.
The
last
that
I've
heard
from
some
people
is
that
the
numbers,
the
performance
is
still
like
two
to
three
x
too
far
away
from
where
it
needs
to
be
so
it's
something
that
we
could
like
realistically
be
looking
at
doing
early
to
next
year.
As
the
leading
thing,
the
leading
part
of
the
fork,
but
yeah
I
guess,
like
generally
I,
also
like
the
idea
of
doing
eof
all
in
one
go.
A
My
biggest
fear
is
the
test.
Surface
of
that,
it
already
felt
whenever
we
were
trying
to
close
down
to
the
original
eel
of
one
for
Shanghai,
that
testing
scope
was
starting
to
reach
the
limits
of
what
was
feasible
and
now
we're
at
age
50.
On
top
of
that,
it's
probably
just
a
function
of
how
much
time
we
can
put
into
testing,
but
it's
something
that
I
do
worry
about
a
little
bit.
B
B
That's
December
plus
that
gets
adds
all
the
features
and
turns
everything
off
that
would
be
needed
in
endgame
and
get
testing
and
working
on
that
and
get
solidity
validating
some
of
our
assumptions,
because
I
think
we
would
need
to
put
in
the
I
mean
the
problem.
There
is
I
mean
the
whole
in
how
you
introduce
eof
into
it
into
into
the
entire
system.
We
wouldn't
want
to
have
the
old
Legacy
pass
I
mean
I
like
the
idea
of
being
able
to
get
multiple
steps
to
get
at
least
testing
written
against
it.
A
Yeah
I
I
feel,
like
generally,
it
seems
more
efficient,
even
if
it
takes
longer
to
get
to
testing
to
just
do
all
of
The
Upfront
development
and
then
Focus
hard
on
testing.
Rather
than
having
this
back
and
forth,
where
you
implement
some
stuff,
the
price
of
tests
influence
more
stuff
rights
and
tests.
I
think
that
ends
up
taking
longer
I,
don't
know
if
Mario
has
any
anything
to
add
to
that
perspective,
or
maybe
a
different
perspective.
G
Oh
well,
I
haven't
been
looking
at
the
Earth
recently,
but
yes,
so
far.
My
thoughts
are
that
it's
already
quite
complex
to
make
an
effective
test
case
for
UF,
so
adding
more
stuff
I
think
it
definitely
is
gonna
complicated
testing
a
lot
but
I
mean
I,
haven't
seen
the
most
recent
changes
to
the
eof,
so
I
might
be
wrong,
but
yeah
from
my
past
experience
writing
tests
on
yeah.
It
was
complex
already.
A
B
E
E
But
definitely
concerned
about
the
size
of
this,
because
even
the
December
version
was
quite
Hefty
and
unfortunately
this
would
go
outside
of
the
boundary
of
the
evm
with
the
transaction
change,
which
I
think
is
the
biggest
worry
for
me.
I
think
every
single
other
change
just
staying
within
the
evm.
E
Even
just
thinking
about
all
these
discussions
on
how
many
resources
are
allocated
to
any
of
these
changes
on
the
client
teams-
and
you
know
so
far
because
we
were
within
the
evm,
the
people
working
on
evm
and
each
of
the
client
teams
were
kind
of
separate.
So
there
was
little
overlap
in
other
changes
and
once
you
get
to
like
changing
transaction
types,
maybe
there's
like
a
bigger
argument
that
this
takes
away
resources
from
you
know
other
proposals
which
you
know
maybe
people
think
are
more
important
than
UF.
E
If
we
do
end
up
splitting,
however,
then
I
would
still
include
the
data
of
codes
in
the
first
rowlet,
because
those
are
relatively
simple
and
I
would
try
to
include
most
of
the
changes
you
know
regarding
observability
like
the
X.
Well,
yeah
I
mean
that's
the
hard
part,
but
with
including
the
data
upcodes
and
removing
the
xcode
and
x
and
opcodes.
E
E
C
C
B
So
if
we
do,
the
two-step
I
do
like
the
idea
that
we
do
everything
but
to
create
op
codes,
and
so
we
have
a
fully
functional
within
the
system
and
the
transaction
changes,
because
I
can
see
that
the
full
SSD
transaction
changes
would
slip
out
of
Cancun
just
to
get
4844
in.
It
might
be
a
major
focus
of
Prague,
so
that
would
slip
strip
in
very
well,
because
then
we
could
activate
create
four.
In
fact,
we
could
probably
even
ship
create
three
with
it
there's
a
possibility.
We
could
do
that.
C
B
Think
that's
a
huge
use
case
that
we
need
to
be
able
to
to
get
to,
but
I
think
there's
enough
use
case
without
those
huge
use
cases
that
we
could.
You
know,
put
it
out
there
and
show
that
you
know
these
last
pieces
coming
in
and
the
next
release,
because
it
you
know,
requires
integration
with
the
with
the
transaction
formats,
but
that
it
will
be.
You
know,
fully
functional
there
and
it
can
get
people
who
are
really
interested
in
doing
things
like
like
saving
gas
size
and
saving
contract.
B
Size
I
mean
getting
rid
of
jump
dust,
some
of
the
stats
they
brought
up
from
from
the
solidity
team,
as
you
say,
20
space
just
getting
rid
of
jump
desk
alone,
which
increases
in
effect
the
amount
of
data
you
could
put
into
a
single
Mega
contract.
So
if
you
could
delegate
into
those
contracts,
you
would
have
you
know
less
need
for
the
diamond
pattern
without
having
to
increase
the
sizes.
I
still
think,
there's
even
without
create
I,
still
think.
B
There's
there's
value
to
be
shipped
in
two
halves,
but
at
the
same
time
I'm
not
you
know,
I
would
support
either
approach.
I'm
not
opposed
to
to
going
Mega
eof,
but
I
think
you
know,
honestly,
the
the
scheduling
that's
going
to
come
up
in
the
next
ACD
I
think
is
really
going
to
drive
more
of
it
than
anything.
A
That
makes
sense,
I
think
I
generally
agree,
so
it
seems
like
the
takeaway,
for
the
most
part
here
is
to
focus
on
Mega
eof,
try
and
see
if
it's
possible
to
make
this
change
happen.
All
is
one
unit
and
I
guess
in
the
back
of
our
minds,
keep
an
eye
out
for
things
that
we
might
be
able
to
push
into
like
a
later
release.
A
H
Would
emphasize
the
need
for
test
cases
right
because
we
depend
on
these
test
cases
a
lot
to
verify
the
implementations
that
we're
working
on
and
merging
these
implementations
to
our
Master
Branch.
So
before
we
have
a
working
test
cases
all
these
drafts,
that
are,
we
are
working
on
or
whatever
they
are
just
drafts
right
and
they
remain
drafts
in
our
eyes
till
we
pass
certain
Hive
tests.
We
we
pass
certain
sorry
we
pass
certain
ethereum
tests
and
and
stuff
like
that,
so
I
think
it
it's
worth.
Thinking
about
that.
A
Yeah
no
I
agree.
It's
just
that
to
generate
those
tests,
we
need
to
have
a
reference
implementation
built.
Essentially,
so
that's
yeah
kind
of
the
place
that
we
need
to
get
to.
I.
Think
that
the
implementation
is
the
people
been
working
on
are
emotionally
targeted
on
eof
1.1
and
you
haven't
really
started
working
on
the
UF
Mega
eof
yet,
but
it
seems
like
that's
sort
of
The
Next
Step.
A
E
Yeah
I
think
the
more
annoying
part
is
the
the
test
thing
yeah
in
regards
to
you
know
what
yeah,
what
four
can
have
to
to
choose
any
of
this
I
think
what
we're
going
towards
is
to
Implement
all
of
these
or
Cancun
in
the
tests,
and
if,
during
the
process,
it
turns
out
that
we
need
to
reduce
the
scope,
then
we
move
like
the
create
tests
to
a
different
Fork,
yeah
I'm,
not
sure.
If
doing
anything
else
seems
to
be
an
Overkill.
A
E
H
A
Would
you
want
to
set
like
a
Target
dates
where
you
expect
to
have
you
know?
An
initial
set
of
test
cases
filled
like?
Is
that
something
that
we
could
say
that
this
time
next
month
like
it,
doesn't
have
to
be
super
comprehensive
and
test
every
educates?
But
this
time
next
month
we
have
the
specification
quote:
unquote,
Frozen,
so
that
we
know
what
we're.
E
Yeah
I,
don't
know
the
answer
personally,
but
I
really
hope
we
should.
We
should
have
some
some
basic
tests
soon,
I
would
say
the
the
priority
now
is
to
fix
the
current
state
test
to
to
pass
the
tvm1,
and
after
that
we
can.
We
can
look
into
new
test
cases,
but
this
reminded
me
one
more
question
mark
regarding
this
spec,
which
came
up
today,
is
the
header
with
the
embedded
containers
and
from
a
is
packed
wise.
It
makes
sense
to
make
them
optional
from
implementation.
E
E
B
B
A
A
G
I
I
don't
know
I
think
it
seems
question
similar
to
how
implementations
should
be
organized
like
whether
they
replace
the
audio
of
information
completely
or
or
make
a
separate,
Branch
I
think
this
new
spec
is
kind
of
an
extension
really
and
it
can
be
separate,
so
it's
not
difficult
to
have
them
separately
and
build
the
second
one
like
the
big
one
on
top
of
the
old
one.
So
I
don't
know
it
I
think
it's
up
to
you
regarding
this.