►
From YouTube: EOF Breakout Room #5
Description
B
C
C
E
F
A
A
But
it's
not
the
current
situation,
and
and
because
of
that,
like
traditionally,
you
just
upend
this
data
to
the
like
init
code
and
and
then
the
code
running
inside
the
init
code,
just
knows
where
the
data
is
and
so
on,
but
like
the
kind
of
ugly
ugly
aspect
of
that
is
that
now
the
contract
that
creates
another
contract
needs
to
kind
of
reprocess
dlf
and
usually
patch
the
the
data
size.
The
data
section
size
in
the
UF
container,
so
it
means
that
it
needs
to
manipulate
the
aif
format.
A
A
B
Next
steps
are
for
resolving
this
because
it
seems
like
there's
two
main
pause
for
dealing
with
the
construction
arguments
and
one
is
like,
as
you
describe,
manipulating
the
data
size
and
adding
The
Constructor
in
the
data
section
and
the
other.
It's
I
guess
there's
three,
then
the
other
one
is
appending
the
constructed
DNA
code
and
then
the
last
one
is
changing,
how
create
works
and
the
last
one's
sort
of
out,
because
it's
too
large
of
a
change.
A
My
understanding
solidity
can
handle
this.
This
thing
right
now
it
just
like
this
additional
code
that
will
do
the
patching
and
so
on,
and
that
works
I
think
most
of
the
cases,
the
things
that
probably
don't
work
is
to
pre-computing
create
two
addresses
with
some
like
not
look
starting
size
arguments.
So,
for
example,
if
the
Constructor
of
the
create
two
takes
an
array,
it's
really
complicated,
or
maybe
it's
it's
impractical
to
like
pre-compute
it,
but
I
I
might
be
wrong
about
some
details.
A
D
I'm
afraid
those
use
cases
are
gonna,
be
pretty
big
and
it's
gonna
be
a
pretty
big
limitation
to
require
all
of
your
init
code
to
fit
inside
the
container.
We
need
to
find
the
size
of
the
container
dynamically.
This
is
I
think
this
is
an
important
thing.
We
need
to
get
fixed
before
we
ship
it.
We
needed
I.
Think
we
my
opinion
is
we
should
do
it.
We
need
to
do
to
get
it
fixed,
whether
we
allow
create
a
knit
code
to
not
have
a
size
limitation
or
we
change
the
size.
D
Limitations
to
The
Container
must
be
at
least
the
same
or
larger
than
the
data
section
would
apply
or
or
something
we
need
to
do.
Something
create
would
be
another
way
to
do
it,
but
that
is
that
that
even
would
even
go
beyond
Cancun
I.
Don't
think
they
have
the
time
to
Define
that
well
and
get
people
on
board
with
it.
That's
like
a
one
two
year
out
solution
there,
but
I,
don't
think
that
I
think
we
need
to
get
it
fixed.
So
we
can
have
arbitrary
array
data
for
a
Constructor.
E
A
A
Think
I
agree
this
like
this,
like
some
issues
with
it
and
we
might
not
even
know
like
what
exactly
kind
of
issues
we
will
have
with
that,
and
one
more
thing
which
is
kind
of
related
is
also
the
fact
that
we
now
expect
The
Return
of
the
of
the
init
code
execution
to
be
also
eof
format
right,
which
means
the
the
like
returning
empty
empty
code.
It's
not
it's
not
valid
in
this
case
and
I.
D
I
think
I've
seen
that
used
before,
where
people
just
want
to
execute
a
string
of
evm
code
and
I'll
leave
a
contract
to
wrap
a
new
transaction.
So
I
think
it's
I,
don't
know
if
we
need
to
support
it
through
eof.
But
if
we're
going
to
make
features
that
are
eof
only,
then
we
might
need
to
start
considering
how
to
handle
an
empty
create
from
that.
We.
B
E
E
D
E
D
F
F
E
F
D
B
Well,
I
think
the
imprint
on
state
of
having
Code,
Zero
versus
and
quote-unquote
empty
eof
container
is
negligible
because
we're
only
going
to
store
one
version
of
the
code
hash.
So
as
long
as
most
people
are
deploying
in
the
UF
containers
after
they
run
their
code,
then
it's
you
know
not
really
going
to
be
any
overhead.
D
D
A
I
think
I
might
have
like
presented
it
wrongly,
because
I
think
the
original
use
case
was
using
self-destruct
in
the
end.
But
I
saw
a
comment
that,
like
returning
cavities
like
equivalent
but
I,
think
yeah
I
missed
the
known.
The
nouns
thing,
so
mostly
the
daily
people
is
that
this
init
code
that
creates
another
contracts
or
do
other
stuff,
and
in
the
end
of
that
it
served
the
tracks.
So
then,
the
contract
is
not
created.
B
B
Yeah
I
think
we
should
continue
debating
this
question
of
if
we
should
allow
zero
code
contracts
to
be
deployed.
Offline
I
do
want
to
try
and
resolve
this
question
about
what
to
do
with
Constructor
values.
For
the
init
code,
it
doesn't
seem
like
it's
very
good
consensus
I'm,
like
currently
leaning
towards
making
no
change
unless
we
could
present.
B
Like
a
really
clear
example,
that's
going
to
make
things
much
harder
if
we
have
to
put
the
Constructor
in
the
data
section,
we
can
always
do
a
change
in
the
future
to
allow
extra
data
after
the
init
code
container
like
we
were
discussing,
but
we
can't
easily
in
the
future,
say
that's
no
longer
allowed.
So
unless
there
is
a
good
example
right
now
of
like
this
is
going
to
not
be
possible
by
putting
the
Constructor
in
the
data
section,
I
think
that
we
should
leave
it
as
is
and
then
decide
again
in
the
future.
C
D
F
C
B
B
D
F
D
B
D
D
A
So
warning
wouldn't
like
not
help
at
all
so
yeah
I'm,
like
my
I
I
know,
my
view
is
like
I
would
like
to
spend
a
bit
more
time
on
it
like
thinking
about
how
the
contracts
are
created
and
limit
the
like
observability
of
the
code,
which
I
think
the
current
current
situations
kind
of
go
a
bit
into
the
other
direction.
So
like
the
fact
that
salinity,
like
the
evm
code,
needs
to
understand
eof
format,
I
think
that's
that's
a
bit
like
yeah
the
opposite.
What
I
would
like
to
see
somewhere?
A
D
A
Yeah
yeah,
but
that's
that's
like
that
leaks.
Some
information
about
the
code
you're
having
right
so
I
guess
ideally
like
true
VM,
cannot
like
snip
anything
out
of
that
I'll
accept
data
which
which,
for
for
the
other
word,
is
just
like
stream
of
bytes,
and
we
never
assume
will
actually
modify
data,
because
why
would
you
but
the
rest?
At
least
you
would
yeah
I.
Guess
that's
like
this!
This
italic
idea
that
you
can't
expect
it
so
yeah.
A
B
B
H
B
F
H
B
I
B
Great
so
I
think
with
respect
to
testing.
Overall,
we
really
need
to
at
least
get
some
test
Suite
published
and
released
so
that
all
the
clients
can
run
them
and
we
at
least
sort
of
have
like
a
baseline
of
what
everyone
is
targeting
and
implemented
Etc
so
that
we
can
try
and
do
a
past
net
in
the
next.
B
You
know
couple
days,
I
think
we
should
really
have
something
some
sort
of
test
net
before
all
core
devs,
because
that
was
part
of
the
stipulation
that
January,
plus
all
the
clients
to
implemented
elf
and
obviously
you
know
we're
still
going
to
be
working
on
testing
and
differential
fuzzing
and
improving
all
these
things
over
the
next
couple
weeks.
But
as
a
like
a
good
faith
effort.
I
think
it
would
be
great
to
get
a
test,
Suite
released
and
start
a
test
net.
J
G
J
B
G
Yeah
I
think
I
I
would
agree,
that's
the
most
probably
valuable
signal
and
then
also
the
test
net
bits
there
might
be
like
it
might
be
worth
discussing.
Do
we
want
to
have
just
one
broader
test,
snap
for
client
teams
to
join
versus
like
an
eof
only
one
and
I
feel
like
yeah.
If
we
have
that
conversation
on
all
core
devs
it'll
inform
what
what
we
do
here.
B
Okay,
that
sounds
good.
Let's,
let's
focus
on
that:
let's
focus
on
getting
a
test
Suite
before
all
core
devs,
so
we
can
get
an
idea
of
like
where
clients
teams
are
and
then
you
know
ourselves
right
now
we
can
say
we're
sort
of
planning
on
doing
a
test
now
next
week,
but
that's
going
to
depend
depending
on
the
conversation
that
happens
on
Thursday
at
awkward
dose
Andrew.
K
C
C
B
B
G
I
B
Great
I
also
put
on
the
agenda
just
to
mention
the
cof
parse
tool,
I
think
unfortunately,
Martin
has
had
to
go,
but
Martin
has
been
doing
some
fuzzling
with
the
eof
parse
tool
found
a
handful
of
Errors
I.
Think
Danica
you've
also
been
doing
some
differential,
fuzzing
I,
don't
know
if
you
want
to
make
a
comment
on
how
that's
been
going
so.
D
D
I
think
we
use
similar
things
to
the
transaction
tests
for
eof
contracts,
because
the
only
question
we
have
for
you
know
a
very
large
Corpus
is:
is
this
accepted
or
not,
and
the
Alternatives
make
a
very
large
Corpus
of
blockchain
tests
or
a
general
State
tests,
which
are
very
heavy
to
calculate
when
the
only
question
we
want
is:
are
they
getting
the
stack,
validation,
correct,
so
I'm
wondering
if
we
should
use
our
findings
from
submerging
to
create
a
new?
You
know,
transaction
test
type
set?
That
is
just
for
the
eof
foreign.
D
B
Yeah
I
think
that
makes
sense
to
me.
It
seems
to
fit
pretty
nicely
in
line
with
the
new
transaction
test
that
Martin
had
worked
on
sometime
last
year,
and
this
does
seem
like
it
to
me.
That
would
be
a
pretty
good
fit
I.
Don't
think
this
is
something
that
we're
going
to
make
happen
for
Shanghai,
I,
think
yeah,
it's
something
that
we
should
aspire
to
after
Shanghai
I,
don't
know
if
you
think
differently
on
that.
G
B
Yeah,
if
you
want
to
make
a
proposal,
I
think
that
we
can
definitely
get
something
going.
I,
don't
know
how,
like
the
integration
will
be
with
some
of
the
official
test
repos,
but
we
can
definitely
do
something
ad
hoc
by
Austria
and
then
talk
about
it
there
and
decide
how
to
you
know,
merge
it
officially
into
like
the
testing
Suites
that
we
have.
I
D
No
execution
just
to
continue
look
at
the
container,
we
would
run
code,
validation,
we'd,
run,
stack,
validation
and
the
question
is:
is
it
valid
or
is
it
invalid
is
the
real
only
output
and
we
might
need
to
put
it
against
different
Forks?
If
we
change
this,
we
might
need
to
put
against
different
use
cases
like.
Is
it
a
net
code
we'll
want
a
comment
saying
why
we
expect
this
one
to
fail
or
what's
interesting
about
it?.
B
J
D
B
A
A
B
A
B
I
think
that
we
just
need
to
get
this,
get
a
testing
Suite
released
and
figure
out
what
the
client
test
pass
rate
is
for
each
of
them.
So
we
can
basically
come
on
and
say
you
know.
This
is
how
clients
are
doing
with
eof
testing,
so
people
will
sort
of
get
an
idea
of
what
the
status
of
that
is
and
I'm
guessing,
like.