►
From YouTube: EOF Implementers Meeting 7
Description
A
Hey
good
morning,
everybody
thanks
for
joining
us
for
the
UFL
owners
call
number
seven.
This
is
the
first
call
that
we've
had
in
a
few
weeks.
We
spent
some
time
a
few
of
us
in
person
at
the
interoper
event
in
Austria
and
yeah
did
some
work
on
eof
had
some
discussions
about
how
eof
fits
into
some
of
the
future
roadmap
ideas
and
so
I
think
it's
going
to
be
a
good
time
to
talk
about
what
happened.
A
You
know
at
that
event
and
then
what
people
have
been
up
to
for
the
past
two
weeks
or
so
since
we've
been
back
so
I
guess
to
get
started.
Let's
just
go
over
what
the
clients
have
been
up
to
at
the
interruptions
the
interrupt
yeah
I
know:
do
you
want
to
start
with
Basu.
B
Sure
so
we
had
basically
gotten
up
to
implementing,
what's
been
called
ufp1
and
we
were
engaged
in
the
reference
you
know
looking
into
starting
moving
some
of
the
reference
tests
over.
We
validated
some
of
the
reference
tests.
None
of
them
had
filled
properly
because
it's
still
a
very
fluid
spec.
So
that's
not
surprising.
So
I
did
differential
testing
against
I
think
the
other
most
complete
implementation
was
get
and
off
of
like
kinds,
clients
fork
and
I
did
differential
testing.
B
There
came
up
identical,
so
we
were
ready
to
ship
V1,
but
you
know
because
it
brings
us
we're
going
to
discuss
later
on.
I,
don't
think
it's
ready
to
ship
in
Shanghai
there's
at
least
two
issues
that
need
to
be
resolved
and
some
more
existential
issues
that
need
to
be
resolved
before
we
can
comfortably
go
ahead
with
it
unrelated
to
eof.
B
I've
got
our
evm
tool
implementing
I'm
working
on
having
a
different
t89
and
b11r,
so
it
can
become
a
full
partner
in
the
execution
test,
clients,
execution,
spec
tests,
that's
still
underway.
It's
not
complete,
there's
still
rough
corners,
and
you
know
not
even
guthren's
gifts
right
now,
because
they're
changing
some
of
the
M
Fields.
So
it's
you
know,
apart
from
the
course
on
there
right
now,.
A
B
Yeah
right
now,
the
issue
is
around
brief
base
fee
and
there's
no
current
base
fee
in
some
of
the
tests
that
come
out
and
I
just
need
to
read
in
what
the
SS
is
expecting
the
client
to
do
it.
When
that
happens,
and
then
just
making
basically
do
that
and
I
think
Jeff
is
in
the
same
boat
there.
They
fail
the
same
test.
Okay,.
A
Interesting:
okay,
cool
thanks
for
that
update.
Do
we
have
another
mind
here
or
Aragon.
A
Nothing
I
can
get
a
give
an
update
for
guests,
then
and
update
us
there's
not
too
much
of
an
update.
We,
you
know
we
spend
a
fair
bit
of
time
talking
about
eof
spec,
uf2
spec
in
Austria,
and
since
returning
I
haven't
spent
much
time
at
all
it.
A
You
know
working
on
a
deal
of
implementation,
I
think
there's
some
outstanding
small
issues
and
some
things
that
would
need
to
be
updated,
but
I've
just
been
focused
on
a
couple
of
different
things,
and
so
that's
been
on
the
back
burner
still
waiting
for
things
to
settle
a
little
bit
to
figure
out
what
we're
exactly
targeting.
So
we
can
get
back
to
the
place
where
we're
doing
differential
testing
a
much
against
a
bunch
of
clients.
D
C
Erotic
and
Anthony
can
speak
more
to
that,
but
Andre
has
been
working
on
the
create
three
implementation,
which
is
this.
Basically,
this
new
Contra
creation
model
or
getting
rid
of
them
product
observability
and
we
have
shared
these
documents
create
tree
is
one
of
the
instructions
between
contract
is
another.
One
and
Andre
has
been
working
on
implementing
this
in
evm1,
and
the
intention
was
that
implementing
it
gonna
give
us
some
we're
gonna
find
some
problems
with
the
design
and
I
mean
so
far.
It
seems
to
be
working.
C
It
did
help
us
Identify
some
edge
cases
which
we
need
to
describe
separately
to
that.
Just
as
of
yesterday,
t8n
transition
support
has
been
merged
into
evm1,
which
means
it
can
be
used
to
fill
tests,
and
so
we
will
be
able
to
once
we
have
this
create
three
stuff
implemented.
We
will
be
able
to
build
test
videos
and
that
should
really
accelerate
the
you
know
the
way
we
work
and
test
any
of
these
changes
across
the
clients.
A
B
So
my
concern
with
b11r
is
it's
very
tied
into
the
ethereum
chain
format
and
things
like
the
current
existing
Patricia
tree.
Would
it
be
possible
to
have
the
python
client
use
one
client
for
t8m
and
another
client
for
b11r?
Would
that
set
hybrid
to
discussed.
A
Yeah
I
mean
we,
we
could
have
the
we
could
add
the
ability
to
the
python
spec
python
testing
library
to
take
two
different
binaries,
but
I
wasn't
sure
what
you
meant
by
the
b11r
tool
is
tightly
coupled
with
like
the
Patricia
try,
because
it
should
really
just
be
like
Computing,
the
ROP
of
a
block
and
Computing
the
hash
over.
That.
B
Yeah,
maybe
I'm
thinking
of
t811,
so
many
numbers
in
these
yeah,
but
the
thought
that's
crossing
my
mind
is
you
know,
with
this
utility
of
this
for
likely
or
two
clients
they're
doing
novel
things
like
switching
their
switching
their
their
hash
tree
to
like
the
sparse
Markle
tree.
Is
there
a
way
to
make
these
tests
useful
for
the
layer,
twos
they're,
pushing
evm
compatibility,
so
we
can
run
a
test
on
and
say
no
you're,
not
here's
your
errors
or,
yes,
they
pass
the
tests
here,
have
a
cookie.
A
Yeah,
that
was
a
good
question.
We
should
think
more
about
that
for
sure.
I
do
think
that
you
know
a
lot
of
the
ways.
These
things
are
structured,
it's
something
that
we
can
support
with
relative
ease,
but
yeah,
it's
just
getting
to
the
point
where
we
might
be
boiling
the
ocean
to
support
everything
and
right
now
we
want
to
make
sure
that
we
are
supporting
L1.
A
C
I
think
the
update
I
have
from
Danielle
I
mean
this
is
the
second
hand,
update
Daniel
said
that
the
basically
implemented
everything
of
V1,
with
the
exception
of
our
jump,
V
and
yeah
I,
think,
and
they
also
worked
on
some
of
the
optimization
steps,
because
they're
the
easy
way
to
enable
UF
support
initially
was
just
to
disable
the
optimizer
just
to
get
everything
else
done,
but
they
got
as
far
as
re-enabling
the
optimizer
and
actually
extending
it
and
yeah.
C
The
the
result
is
that
both
code
size
and
gas
usage-wise,
there's
stinga
savings,
actually
I
think
they
haven't
done
anything
yet
this
year,
with
the
exception
of
Daniel
participating
in
in
Edelweiss
and
helping
in
the
create
discussions.
E
A
Okay,
yeah
great
spec,
updates
I,
know,
there's
a
lot
of
stuff
discussed
in
Italy's
du
Alex
and
Pavel
want
to
try
and
give
an
overview
about
the
things
that
we
discussed
with
respect
to
elf
one
and
these
ideas
about
eof2.
C
I
shared
a
document
just
at
the
time
of
the
call,
so
nobody
had
the
opportunity
to
read
it,
but
that
gives
a
and
summary
and
like
an
overview
of
what
we
could
do,
but
going
beyond
the
EOS
V1
but
I.
Think,
probably,
if
you're
on
the
call
you
are
in
the
best
position
to
summarize
the
status
of
eofv1
pack
changes
because
generally
we
we
wanted
to
lock
in
what
we
had
in
December
as
ufv1
and
any
further
changes.
I
mean
major
changes.
C
We
would
be
doing
under
eosc,
1.1
and
2.0,
and
the
reason
being
is
that
we
don't
want
to
influence
testing
and
break
testing.
C
D
Yeah
hi
I
think
the
one
was
mostly
missing
this,
like
one
one
thing
about
the
create:
how
how
we
handle
invalid
invalid
init
code
in
case
of
create
transaction,
create
instruction
so
yeah.
This
is
like
ongoing
for
longer,
but
I
try
to
like
get
a
piano
from
many
people
on
the
charts
and
I
think
the
we
kind
of
have
we.
D
We
have
a
solution
that
satisfies
most
of
the
people,
so
we
kind
of
went
to
the
process
of
updating
the
implementation,
tracking
tests
and
and
so
on,
and
this
is
kind
of
like
one
Edge
case
that
remains
there,
which
I
think
it's
fine.
But
it's
requires
some
additional
infrastructure
in
at
least
on
the
evm1
side,
and
we
didn't
tried
it
yet
how
how
complicated
it
makes
the
the
implementation
in
the
end.
D
Maybe
it
will
actually
simplify
it
in
many
cases,
but
we
didn't
try
it
yeah,
so
I
think
it's
a
bit
mess,
but
it's
always
with
the
create
and
call
instructions
that
everything
you
change.
It's
like
it's
like
series
of
20
or
more
different
tracks.
You
need
to
do
and,
depending
where
you
put
additional
checks,
and
how
do
you
modify
existing
the
security
effects?
D
D
So
this
is
the
status
and
I
think
we'll
go.
We
will
continue
with
that
and
maybe
we'll
try
to
evm1
this
time
as
a
like
first
implementation
to
fully
conform
with
the
test
and
spec,
but
also
yeah.
So
that's
kind
of
this
is
this:
is
it
and
I
I'm
not
really
prepared
for
like
the
the
1.1,
but
mostly
what
we
had?
What
we
wanted
to
do
is
to
include
some
changes
that
we
are
already
agreed
to
be
included,
but
we
didn't
just
not
disrupt
the
testing
of
existing
spec
I.
D
Think
there's
like
around
five
different
changes,
including
delegate,
call
restriction
and
some
minor
other
things.
I
don't
have
the
list
right
now,
however,
the
the
thing
we
we
also
discussed
during
this
interrupt
last
month.
D
So
it's
kind
of
it
kind
of
makes
the
all
this
struggle
to
create
semantic,
a
bit
wasted
in
the
sense
that
we'll
probably
disable
all
of
it,
but
maybe
with
that
will
like
be
useful
later
on
at
some
point.
So
that's
my
comment
about
it.
A
So
you're,
saying
by
disabling,
create
you're,
saying
disabling,
create
the
original
op
codes,
not
talking
about
the
the
new
ideas
with
create
like
the
transactions
and.
D
Yeah
I
didn't
fully
like
check
out
this
new
create
instruction.
Then
you
create
semantics.
D
If,
if
we
need
to
handle
all
the
edge
cases,
the
similar
way
or
maybe
some
of
that
cases
will
go
away-
I'm,
not
sure
about
that,
but
yeah
by
disabling
I
think
we
kind
of
ended
up
on
the
on
this
position
that
if
we
want
to
deploy
eof
in
two
phases-
and
so
we
want
this
new
fancy
create
semantics,
then
we
need
to
kind
of
disable
it
for
now
and
then
introduce
it
later
without
need
of
modifying
the
El
version,
so
yeah
more
or
less
there
will
be
only
option
to
create
eof
contracts
starting
from
a
transaction.
A
Yeah
makes
sense
any
questions
from
anybody
on
these
ideas.
Eof1
1.1,
B2.
B
So
1.1's
not
for
its
compatible
extension
of
one
right,
because
we're
removing
features
only
one
would
ship
one
or
one
point.
One
ship.
A
D
So
1.0
it's
it's
what
we
currently
have
in
the
aps
and
that's
what
we
would
be
like:
implementations,
we're
targeting
and
what
the
testing
are
done
for-
and
we
didn't
want
to
this.
This
disturb
this
because,
like
we
assumed
this
ongoing
implementations
efforts
and
ongoing
testing
efforts,
but
if,
if
like,
if
you
think
it's
it's
not
worth
the
continuing,
we
can
I
think
apply
additional
changes
to
that
and
like
kind
of
skip,
this
milestone,
I.
D
Think
the
from
my
perspective,
like
kind
of
buff
options,
I'm
fine,
I
I
was
a
bit
happy
about
having
some
Milestones.
Some
like
multiple
teams
could
confirm
they.
They
they
passed
all
the
tests,
and
this
is
what
we
had
but
I
think
like
I'm
I'm
open
to
going
yeah
to
selecting
one
of
the
dudes.
B
Yeah,
because
I
don't
think
we
have
a
good
infrastructure
to
set
a
basic
yet
to
ship,
both
1-0
and
1
1.,
without
changing
the
major
version
number
you
know
from
like
you
know,
true
forwards,
compatible
where
we
just
add
new
op
codes
and
admin
capabilities
and
increase
the
space
that
is
valid
contracts.
I
think
that's
easier
to
handle
inside
of
Basu.
But
to
have
you
know,
restrictions
would
require
separate.
B
B
So
you
know
it
would
just
mean
that
contracts
that
were
compiled
with
those
forbidden
features
would
suddenly
become
invalid
in
hyperledger
basic,
which
I
think
is
probably
okay,
because
all
the
contracts
that
don't
use
these
forbidden
features
should
just
transparently
come
in
if
you're
not
creating
stuff.
If
you're
not
using
EXT
copies
the
XT
code
series
of
operations
and
doing
gas
introspection,
it
should
just
well.
No,
it
won't
work
because
we're
changing
the
gas
on
the
gas
introspection.
So
there's
some
things
that
might
change
it
might
be
incompatible.
B
You
couldn't
do
cross-contract
calls,
which
is
kind
of
the
big
feature.
If
we
go
with
the
in
place,
change
of
call
just
dropping
the
gas
field.
C
So
I
was
kind
of
thinking
that
we
don't
necessarily
want
to
to
have
both
of
these
implemented.
At
the
same
time,
it
would
be
rather
because,
as
you
say,
they're
like
many
different
ways
to
enable
like
1.1
and
the
the
stainless
way
to
enable
it
is
with
an
actual
version,
one
right,
but
some
clients
may
be
able
to
do
it
with
like
enabling
a
you
know,
like
especially
IP
feature
whatever,
but
I
think
that's,
maybe
like
unnecessary
complications
and
how
I
was
looking
at.
This
is
more
in
terms
of
discussions.
C
I
think
at
this
point
we
need
to
spend
time
on
the
specification
of
what
this
1.1
would
be
as
opposed
to
jumping
the
gun
and
implementing
it
in
every
single
client.
So
I
think
we
have.
You
know
a
number
of
weeks
during
a
which
teams
can
keep
working
on
implementing
V1
completely
and
passing
the
test,
because
I
think
the
tests
are
like
mostly
done.
C
So
it's
really
just
a
matter
of
implementing
in
the
clients
and
parallel
to
that
people
who
are
like
more
involved
in
the
specification
of
1.1
can
work
ahead
and
and
finalize
that
and
then
you
know
in
a
few
weeks
time
we
can
just
jump
to
implementing
all
of
this
in
the
clients.
B
C
I
think,
assuming
we
can
nail
down
like
this
1.1
spec,
you
know
early
I
mean
I
will
put
it
after
eat
Denver,
because
obviously
that's
gonna
put
a
hit
into
this.
People
are
going
to
be
busy
with
the
Denver,
but
my
target
would
be
that
the
1.1
spec
should
be
pretty
clear
by
the
end
of
the
Denver
I.
Think
then
we're
like
on
a
good
track.
A
So
the
anticipation
is
still
to
try
and
have
this
elf
1.1
specification
used
to
propose
the
change
for
Cancun
rather
than
trying
to
propose
the
full
ufe2,
or
will
we
just
kind
of
go
into
the
conversation
like
here?
Is
this
1.1
spec?
C
I
have
the
and
I
shouldn't
be
the
only
one
like
giving
feedback
on
this,
but
my
feeling
is
that
V2,
given
the
the
sheer
number
of
changes
around
creation,
may
put
us
into
like
a
similar
position
as
we
were
pushing
High
that
it
may
be
just
you
know
too
big,
given
the
time
frame.
Yeah.
C
That
being
said,
I
think
we
do
have
to
be
proactive
for
getting
the
transaction
like
the
the
requirements
for
the
new
transaction
types,
because
there's
this
ongoing
discussion
of
the
sscification
of
you
know,
transaction
hashes
and
the
proposed
the
IP
for
that
I
think
it
has.
This
would
have
an
effect
on
that,
so
I,
don't
think
ufv2
SS
would
roll
out
in
Cancun,
but
I
think
we
have
to
do
as
much
as
possible
to
prepare
everything
else
to
be
compatible
with
the
V2
that
we
want
to
have.
B
A
Okay,
cool
yeah:
let's
just
stay
vigilant
on
these
changes
with
the
soc
transactions,
try
and
make
sure
that
what's
happening,
there
is
amenable
to
Future
changes
that
we
might
need
or
want
to
make
with
eofv2,
and
also
we
just
need
to
keep
in
mind
and
keep
an
eye
on
this
proposal
in
general
in
the
context
of
Cancun,
because
I
think
this
is
going
to
be
a
relatively
large
change
for
the
El
and
so
I.
A
Don't
know
if
it's
like
necessarily
competing
with
eof,
but
if
we
think
about
El
teams
having
a
finite
amount
of
resources
for
completing
changes
in
their
clients
for
Forks,
then
you
know
this
is
obviously
taking
a
piece
of
that
so
I
think
yeah.
It
would
pretty
much
be
impossible
to
do
the
soz,
4844
and
eof
in
the
same
Fork,
so
V
1.1
is
certainly
our
best
bud
in
that
situation.
A
C
If
we
have
the
time,
I
would
propose
to
maybe
go
through
this
document.
I
shared,
maybe
spend
like
five
minutes
just
on
this
1.1
yeah.
C
Could
you
by
any
chance
screen
share
it?
If
you
have
it
set
up.
A
C
Yeah,
so
on
on
the
introduction,
it's
just
a
summary
of
basically
what
we
discussed
already,
that
we
want
to
roll
eof
out
into
steps,
and
the
first
step
is
the
1.1,
where
eof
contracts
can
only
be
created
through
transactions
and
not
through
create
instructions,
and
then
the
V2
enables
the
contract
creation
and
then
I
have
three
different
sections
here.
What
the
individual
versions
mean
the
under
V1
I
I
meant
that
everything
what
we
have
today
but
I
also
included.
C
Yeah
I
I
wasn't
sure,
what's
the
the
actual
number,
okay
but
yeah,
all
of
that
is
included.
Okay,
okay
and
then
one
point.
One
is
the
the
interesting
one,
and
here
we
only
list
like
the
changes
which
are
different
to
V1,
so
it
regarding
creation,
yeah.
C
We
just
disallow
the
create
and
create
two
instructions
in
in
the
euf
container,
and
that
means
that,
of
course,
you
cannot
create
any
kind
of
accounts
from
an
euf
context,
but
we
still
want
to
keep
the
external
transactions
to
create
eof
accounts,
and
here
we
discussed
a
number
of
ways
how
to
actually
accomplish
this
and
I
think
we
ended
up
with
like
two
options,
which
seemed
the
most
reasonable
options:
the
first
one
and
it's
important
to
yeah.
C
Maybe
I
should
have
actually
listed
creation
and
introspection
in
the
other
order.
But
what's
important
is
we
not
only
disable
create
and
create
two,
but
also
X,
all
the
X
instructions,
xcode
instructions
and
the
code
instructions,
and
so
eof
init
code
wouldn't
be
able
to
use
code
copy
to
to
get
the
runtime
piece
and
so
to
get
around
this
problem
and
not
introduce
any
more
complexity.
C
A
C
So,
basically,
creation
today,
just
in
Legacy
creation
today
in
the
init
code
call
data
is
empty
and
code
copy
has
all
the
code,
including
any
of
the
the
Constructor
arguments
and
because
we
disabled
this
code
copy
instruction,
there's
no
way
to
get
that.
But
the
simple
trick
is
that
call
data
would
have
access
access
to
that.
So
that's
like
one
option
and
the
other
option
is
instead
of
having
euf
as
init
code.
C
We
would
actually
allow
Legacy
byte
code
to
create
eof
in
a
creation
transaction,
and
that
means
there's
no
special
handling
required,
but
I
think
it
kind
of
goes
against.
You
know
the
current
specs,
where
we
decided
that
Legacy
in
the
UF
they
cannot
create
each
other,
and
maybe
for
that
single
reason.
This
might
be
too
big
of
an
exception
and
the
special
euf
init
code
idea
is
the
better
direction
to
go.
A
I
mean
one
I,
don't
know,
I.
Think
one
slightly
strange
thing
about
the
especially
of
context
is
like
we're
changing
what
the
meaning
of
call
data
is
in
the
context
of
just
this
eof
creation
contract,
and
it
is
a
bit
of
a
you
know,
a
pretty
large
difference
from
how
it
operates
whenever
you're
just
doing
a
create
transaction
non-eof
and
because
the
query
transactions,
the
net
code,
is
very
ephemeral.
A
C
Yeah
I
would
say
for
the
first
part,
you
said
the
special
eof
context.
It
is
a
deviation
from
what
we
have
today,
but
it
is
actually
in
line
with
how
V2
would
operate,
because
in
V2-
and
that
is
a
extremely
long
document-
this
V2
design
space
but
I
would
suggest
you
know.
Whoever
has
the
time,
please
give
it
a
read.
It
has
a
lot
of
interesting
pieces,
but
it
is
super
long.
C
The
important
part
of
that
is
we
would
have
a
create
transaction
where
the
code
and
data
is
separate,
and
that
means
that
the
code
piece
would
have
the
init
code
and
the
data
would
be
just
call
data,
and
this
code
field
in
the
external
transaction
would
be
a
new
addition.
We
don't
have
that
today,
but
in
that
Paradigm
the
call
data
copy
in
V2
would
operate
as
it
operates.
You
know
into
special
case,
so
it's
kind
of
forward
compatible,
but
it
is
a
deviation
from
today.
A
C
Yeah
and
in
V2
this
still
happening
like
that,
but
in
V2
you
wouldn't
send
init
code
in
the
data
field.
You
would
send
in
it,
but
in
a
code
field.
A
C
That's
the
yeah,
that's
the
decision
we
made
it
just
doesn't
seem
to
be
possible
to
avoid
this.
If
you
want
this
intermediate
step
that.
C
And
then
introspection
I
mean
as
mentioned:
X
code
and
code
instructions
are
not
allowed
and
X
code
instructions
have
some
special
behavior
I
think
what
what
is
kind
of
clear
based
on
the
Edelweiss
discussions
that
X
could
copy
would
just
work,
but
it
wouldn't
copy
anything,
but
regarding
size
and
hash
we
had
two
options
and
we
we're
still
not
clear,
which
is
the
better
option.
C
C
C
That
being
said,
I
don't
think
accounts
can
ever
be
updated,
but
technically
they
could
I
mean
that's
the
goal
of
the
spending
introspection.
Another
idea
we
discussed
is
eof.
Accounts
would
just
operate
as
if
they
have
the
ef-00
as
a
code
and
then
code
sizing
code,
hash,
return,
values
based
on
ef00.
C
C
That
was
also
like
a
link
to
discussion,
but
I
think
we
ended
up
with
the
most
simplistic
option
that
we
just
disallowed
the
gas
op
code
and
the
call
instructions
get
the
gas
value
gas
argument
removed
and
we
just
pass
all
the
gas
over
to
the
the
collie
and
a
piece
of
this
discussion
has
been
what
happens
with
the
stipend
and
the
opinion
is
that
since
we
we
remove
this
option
to
to
change
it,
we
can
adjust
what
happens
with
the
stipend
without
any
changes
to
UF.
C
So
in
v,
v
1.1,
we
likely
would
just
leave
everything
this
is,
but
in
V2
we
could
get
rid
of
this
type
and
then
refine
more
things
around
gas,
okay
and
then
V2.
We
have
a
link
to
to
this
long
document,
but
there
have
been
three
different
discussions.
C
We
had
afterwards
which
are
not
covered
in
the
document,
and
there
was
like
an
interesting
discussion
regarding
how
to
do
contract
Creation
in
general,
and
one
idea
was
that
it
would
work
based
on
called
cloning,
and
if
you
would
have
that,
then
you
likely
would
need
a
way
to
insert
code
into
the
state
without
doing
any
kind
of
creation.
You
just
take
eof
codes
and
you
evaluate
that
it's
valid
and
just
place
it
as
at
an
account.
C
Nothing
else
happens,
then
you
can
clone
that
I
think
this
is
an
interesting
discussion
and
probably
we
have
to
look
into
this
once
we
spend
more
time
on
the
V2
idea.
C
Two
important
questions,
however,
because
I
think
those
really
drive
the
discussions
of
the
design,
whether
we
want
to
support
data
contracts
and
whether
we
want
to
support
solidity
immutables
or
if
you
don't,
then
we
kind
of
force,
people
to
use
storage,
and
the
answer
to
to
these
two
so
far
have
been
that
we
don't
want
data
contracts
and
we
want
to
support
immutables,
and
that
is
what
drove
the
design
describing
this
V2
design
space
document.
But
if
the
answer
to
these
are
different,
then
we
have
a
different
design.
Space,
yeah
I.
E
A
E
B
A
B
Unlike
Dennis,
the
the
assembly
output
that
he's
got
of
his
UF
containers,
it's
just
awesome
to
look
out
he's
posted
so
as
as
I've
requested
one
of
the
calls
we
need
to
have
a
separate
set
of
tests
just
to
judge
contract
validation
and
coming
up
with
the
reference
test.
There's
a
really
nicely
to
those,
and
if
you
look
in
the
filler
for
it,
it
was
a
really
nice
breakdown
of
of
what
they
look
like
and
I'm
like
tempted
to
see.
B
If
we
could
automate
generation
of
assembly
output
like
that,
it's
it's
truly
a
sight
to
behold.
Let's
see
we're
gonna
be
in
the
testing.
A
Was
it
in
the
testing,
Channel,
yeah
I
think
I
have
this
link?
Is
this
what
you're,
referring
to.
E
B
E
B
This
is
like
the
most
awesome
breakout
of
eof
I've
ever
seen.
It's.
D
B
B
So
I
mean
it's
a
lot
of
work,
just
to
get
a
bunch
of
tests
and
say
pass
fail,
but
when
you
don't
know,
what's
going
on
to
be
able
to
look
into
these
and
see,
why
is
it
failing?
What
is
it
supposed
to
look
like
in
your
code
for
future
implementers?
This
is
just
like.
I
mean
it's
just
this
is
stuff.
You
could
bring
into
a
college
classroom
to
teach
stuff
about
it.
It's
that
awesome.
A
A
B
A
Right,
yeah
and
so
I,
you
know,
don't
want
to
try
to
impose
too
many
restrictions
on
how
people
are
doing
testing
because
it's
important
to
get
it
done
and
at
the
end
of
the
day,
if
we
hand
write
these
things
and
it's
a
little
bit
of
extra
work,
it's
a
little
bit
extra
work.
Whatever
do
you
think
this
is
where
the
python
execution
spec
tests,
shine,
you're
able
to
derive
functions
that
generate
this
type
thing,
and
it's
much
easier
to
change.
C
So
I'm
not
sure
if
Hugo
has
a
working
mic,
Hugo
has
been
slowly
focusing
on
on
writing
tests.
Oh
you
cannot
unmute
them
and
I.
Think
right
now,
Hugo
is
still
doing
the
end
of
like
4750
test
cases.
I
think
that's
the
the
piece
which
gonna
be
close
to
completion,
probably
in
the
the
next
week
or
two
but
I,
don't
think
we
have
started
to
write
comprehensive
tests
for
54.50.
A
D
D
It's
Wonder
like
how
much
other
other
teams
are
going
to
like
do
tests
the
implementation
right
now,
if,
if
I
think,
if,
like
you
assume
that
you
will
not
spend
a
lot
of
time
on
it,
then
we
can
drop
some
changes
to
the
spec
in
this
into
this
1.1
Direction
I.
Think
if
you
need
more
time
to
actually
test
what
is
currently
expect
out,
then
we
can
move
it
further.
A
C
C
That
reason,
the
T8
and
supporting
evm1
seems
to
be
a
really
good
direction
right,
because
we
can
work
on
like
this
1.1
without
the
need
of
goiteria.
B
C
So
there's
actually
one
more
spec
point,
which
was
brought
up
by
Danielle
from
solidity
is
the
solidity
metadata
which
currently
is
at
the
very
end
of
contracts,
and
it
is
a
seaboard
encoded
metadata
where
the
training
two
bytes
are
the
length
of
the
preceding
content
and
that's
how
to
select
sourceify
can
dissect
contracts
and
see
what
the
solid
metadata
is
and
extract
information.
Out
of
that
with
you
know
the
data
section
and
the
I
think
the
Insight
was
that
it
just
seems
to
be.
C
The
in
in
an
ideal
scenario,
we
would
have
like
multiple
data
sections
or
we
would
have
custom
sections
or
whatnot,
where
something
on
the
application
layer
could
be
designated
as
State.
This
is
the
metadata,
because
this
metadata
stuff
does
some
kind
of
encoding
like
this
length,
which
really
should
be
delegated
in
an
ideal
case
to
The
Container
format.
C
B
C
Yeah
I
think,
if
it's
specific,
it's
a
specific
kind
of
section,
then,
and
in
the
V2
what
we
said
that
only
the
data
sections
have
the
data
copy
of
codes,
then
any
section
outside
of
that
won't
be
inspectable.
C
Yeah
I
think
the
the
concern
was
that,
at
least
with
the
ufv2
proposal,
we
have
this
auxiliary
data,
which
is
basically
the
data
you
can
send
from
init
code
to
be
appended
to
the
data
section
and
in
that
model
solidity
cannot
really
have
the
metadata
at
the
variant
anymore
because
you
would
need
to
insert
it
from
within
like
the
Constructor.
C
So
if
we
don't
have
a
special
section
or
anything,
then
what
solidity
will
do
they
will
place
the
metadata
at
the
beginning
of
the
data
section,
which
is
fine,
but
they
they
felt
like
that.
Maybe
maybe
separation
is
good.
C
Yeah
I
guess
that's
that's
one
option.
Another
is,
as
you
said,
multiple
data
sections
and
it's
still
up
to
I.
Think
the
multiple
data
sections
is
nice
in
one
way,
but
then
it
also
complicates
matters
for
the
init
code.
You
know
which
data
section
is
this
auxiliary
data
being
appended
to
obviously
the
last
one,
but
maybe
for
this
reason,
like
this
Bluetooth
data
sections,
it's
just
too
complicated,
yeah
I'm,
not
sure
I,
think
it's
really
just
that
it
would
be
nice
to
discuss
these.
C
You
know,
as
we
are
right
now,
I
know
that
we
are
like
finishing
in
two
minutes,
but
then
the
next
call
I
think
it
would
be.
The
discussion
points
I
would
propose
is
like
this
metadata
just
agreeing
on
something
which
maybe
we
do
what
we
do
right
now
and
the
V
1.1
questions
I.
Think
we
want
to
get
answers
to
that
on.
The
next
call.
B
A
A
B
We
could
yeah
I,
think,
oh,
it
is
on
the
calendar,
yeah
yeah.
Let's,
let's
discuss
it
then
and
have
people
think
about
it,
but
this
before
East
Denver,
so
we
won't
have
any
specs
to
push
around.
So
we
can
have
an
open
discussion
before
we
would
expect
to
have
any
specs
written,
which
I
think
would
probably
be
open
up
the
design
space.
So.