►
From YouTube: EOF Breakout Room #3
Description
A
Sweet,
let's
go
ahead
and
get
started.
Then
the
agenda
is
here:
I've
got
some
notes
on
my
end
of
some
things:
I
want
to
go
over.
Maybe
the
best
place
to
start
would
be
to
just
get
some
updates
from
client
teams
who
are
implementing
eof.
A
I
guess
I
could
go
ahead
for
guests
really
fast.
Not
much
has
happened
on
the
get
implementation
side
since
the
last
breakout
room
I've
mostly
been
trying
to
help
iron
out
a
couple
of
the
last
small
questions
with
respect
to
the
spec
most
of
the
Eeps
are
implemented
already,
and
the
questions
that
we
still
have
are
more
regarding,
like
the
format
of
the
container,
and
so
it's
yeah
I
haven't
really
had
a
chance
to
integrate
any
of
the
other
small
changes
that
we've
been
making
just
waiting
to
get
the
container
format
ironed
out.
B
B
All
the
small
eof
changes
integrated
as
long
as,
along
with
all
the
the
Shanghai
stuff
I
haven't
done
too
much
on
the
big
eof
ones
yet,
partly
because
they're
still
kind
of
flux
with
some
of
the
requirements,
Diego's
got
started
on
relative
jumps.
I've
got
started
on
some
of
the
container
stuff
and
the
stack
validation
messages
and
updates
to
the
validator.
So
that's
not
really
going
to
have
any
far-reaching
effects.
So
that's
where
we're
at
mostly
the.
B
Down
and
get
a
committed
version
before
we
can
go
too
much
further.
A
Yep
that
makes
sense
another
mind.
Any
updates.
D
Yeah
I'm
actually
not
involved
in
it
directly
yet
I'm,
just
going
and
working
on
the
OS
and
apes
are
in
in
work.
Some
are
in
the
review
phase.
It's
just
work
in
progress
and
I
joined
here
more
to
just
get
more
context
about
eof
and
and
don't
have
the
exact
knowledge
to
share.
A
E
E
This
has
been
already
discussed
with
ergon
team,
and
today
we
started
trying
to
make
ergon
think
with
a
sangong,
and
currently
we
got
stuck
at
the
3
000
block
and
we
are
trying
to
deal
with
it
and
make
it
a
and
make
it
sink
up.
The
let's
block.
A
Got
it
okay,
great
thanks
for
that
update
any
testing
updates.
Oh
Danna
forgot.
B
To
mention
the
faces
yeah,
the
rest
of
that
done
last
week,
excellent.
A
A
I
think
Mario's
not
here,
but
he's
been
working
on
some
cross-client
tests
and
I've
been
trying
to
get
them
filled,
but
because
some
things
are
in
flux,
we've
changed
the
op
code
recently
for
call
off
and
red
f
yeah
it's
difficult
to
get
everything
targeted
on
the
exact
same
thing,
so
yeah,
I,
think
by
all
core
devs
next
week.
We'll
have
those
tests
fields
for
people
to
start
running.
F
Sure
I
mean
a
lot
has
been
happening.
So,
first
of
all,
there
is
the
checklist
which
has
been
updated
to
contain
a
matrix
of
the
implementations
and
links
to
pretty
much
everything.
It
also
has
some
kind
of
a
motivation
on
the
top,
which
should
be
extended
to
explain
the
application
layer
effects
better
as
well,
and
then
we
spent
quite
a
bit
of
time
with
with
it
team,
as
well
as
with
the
like
client
to
go
through
the
checklist
items
as
well
as
brainstorm
on
the
header
format.
F
Regarding
the
the
header,
the
I
mean
a
lot
of
this
discussion
took
place
like
a
year
ago,
but
the
difference
is
back.
Then
we
had
these
different
ufeips
in
succession,
and
you
know
we
weren't
back
like
a
year
year
and
a
half
ago,
we
aren't
hoping
that
all
of
them
could
go
live
at
the
same
time.
F
We
we
wanted
them
to
go,
live
at
the
same
time,
but
you
know,
given
the
the
velocity
of
of
all
cores,
it
didn't
seem
to
be
possible
at
the
time,
and
so
a
lot
of
things
were
designed
to
be
built
on
top
of
each
other,
and
that
may
not
be
you
know
the
the
best
solution,
and
now
we
have
the
opportunity
to
actually
have
all
of
these
at
the
same
time,
and
it
felt
like
a
good
timing
to
review
had
to
improve
the
header
with
that
in
mind
and
Matt
shared,
like
a
document
on
on
where
we
established
the
goals,
calls
and
metrics
how
what
kind
of
properties
are
are
valuable
in
the
header
and
that's
like
the
the
next
big
thing
we
want
to
finalize
during
next
week
and
I
think
this
this
will
be
done
before
all
devs
and
the
goal
would
be
that
you
know
there
wouldn't
be
really
any
changes
coming
from
ourselves
after
next
all
core
Dev.
F
It
would
be
only
just
you
know,
minor
changes
as
discovered
through
implementation
and
testing.
So
that
would
be
the
goal.
Yeah
I.
Think
one
more
update
is
that
we
have
been
working
on
a
unified,
UF
spec
I
I
called
it
spec.
F
But
it's
it's
at
this
point
not
for
replacing
the
eips,
rather
as
an
aid
to
show
the
extent
of
changes
in
a
single
document
and
in
that
document
the
the
changes
look
way
smaller
than
if
you
look
at
the
eips,
because
just
the
format
requirements
of
the
eips
is
way
more
strict
requires
a
lot
more
details,
and
so
this
spec
would
would
it
doesn't
look
as
scary
as
the
five
eips
and
maybe
a
final
update
on
from
the
solidity
side.
F
We
had
a
lengthy
discussion
at
this
point
almost
two
weeks
ago,
so
the
Monday
after
the
last
breakout
call
when
we
had
a
full
day
of
discussions
with
solidity
and
we
went
through
all
of
the
IPS
and
the
features
and
the
effects
on
solidity
and
that
there
was
also
something
which
made
an
effect
on
on
some
of
the
changes
we
submitted
during
the
week,
and
they
also
solidly
put
all
of
the
changes
onto
the
roadmap
and
they
they
are
implementing
everything.
F
During
this
year,
I
mean
practically
within
the
next
three
weeks
and
they
want
to
have
a
full
support
before
Christmas
I.
Think
that's
the
long
update.
A
That's
great,
that's
great
news,
yeah
I
guess
one
thing
I
just
wanted
to
extend
upon.
That
is
just
to
emphasize
that
we
are
really
trying
to
get
all
of
these
things
in
a
very
solidified
place
before
all
core
devs
next
week,
I'm,
not
sure
some
people,
maybe
May,
realize
this
or
some
people
who
may
not
but
to
say
explicitly.
A
This
is
the
last
all
chord
devs
of
2022
and
most
likely
we're
going
to
come
out
of
it
with
a
very
clear
picture
of
what
Shanghai
will
look
like
and
so
I
think
it's
extremely
important
that
we
come
into
that
with
a
A.
You
know
full
and
complete
spec.
It
would
be
great
to
come
in
with
some
tests
and
I'm
happy
to
like
update
the
implementation.
A
If
we
can
come
to
agreement
on
this
call
in
like
early
next
week
on
some
of
the
like
last
small
things
that
need
to
be
decided,
I
think
it's
important
to
just
emphasize
overall
that
the
changes
that
we're
talking
about
are
relatively
small,
like
all
of
the
core
pieces
of
eof,
that
dips
on
team
has
been
working
on
for
last
year
or
two
is
solid.
A
We're
just
bike
shedding
a
little
bit
on
like
what
does
this
exact
container
look
like
and
we're
trying
to
think
about
how
to
be
like
the
most
future
compatible
with
other
changes
that
my
people
might
want
to
do
so
I
think
Holger
I'm,
not
sure
if
I
missed
you
in
the
client
updates.
But
if
you
want
to
just
give
a
quick
update
on
what
ethereum
JS
has
been
up
to
with
respect
to
eof,
please
go
ahead.
G
Yeah
sure
yeah,
so
so,
yeah
crmjs
is
we
don't
really
have
kind
of
like
concrete
progress
updates,
so
we
have
got
so
this
base
based
your
faips.
We've
got
ready
for
quite
some
time
and
kind
of
like
for
a
couple
of
months
already
and
and
now
we
are
looking
at
at
the
moment-
we're
looking
in
the
industry,
other
erps
and
from
our
team.
G
We
want
to
do
the
implementations
on
that
and
I
guess
we
will
so
he
he's
planning
to
to
take
in
like
four
weeks
for
that.
So
we
would
like
to
be
ready
early
January
with
a
UF
implementation,
as
they
are
now
in
in
the
current
EIP
Forum,
so
that
would
be
kind
of
like
the
the
implementation
update
from
from
our
side.
A
Okay,
great
thanks
for
that
update,
I,
think
the
next
best
thing
to
do
is
to
just
start
going
through
the
checklist
that
the
Epsilon
team
has
been
working
on
and
we
can
see
like
maybe
more
explicitly
what
things
have
been
merged
and
changed,
and
what
questions
are
still
open
and
then
I
think
that's
going
to
naturally
lead
us
to
talking
about
some
of
these
last
few
questions
about
the
container
format.
A
Does
that
sound
good?
Does
anybody
have
anything
else
they
want
to
talk
about,
for
that
we
can
try
and
wrap
it
up
with
a
few
last
things
like
some
talk
about
some
test
net
goals,
talk
about
some
General
other
goals
for
ACD,
but
if
there's
anything
else,
please
let
me
know
right
now.
H
I
mean
there's
one
thing:
we
would
ideally
like
to
have
in
solidity,
which
is
additionally
one
EIP.
That
is
no
bother
for
the
clients,
probably
which
is
663,
which
is
unlimited
swaps
and
depths,
but
I'm
not
sure
whether
we
have
any
chance
to
get
that
at
this
point,
but
then
bring
it
up,
because
we
really
would
want
that
but
yeah
and
it
depends
on
the
IP
in
this
part
of
it.
In
that
sense.
But.
A
I,
don't
know
if
anybody
has
like
an
initial
thought
on
this
call
about
whether
or
not
they
would
be
open
to
also
having
663
like
663
does
not
require-
or
it's
not
like
necessarily
part
of
big
eof,
but
it
does
require
the
elf
environment
to
have
an
immediate
I.
Think
most
people
in
this
call
are
like
more
amendable
to
changing
the
evm,
so
we're
kind
of
preaching
to
the
choir.
But
if
anybody
has
a
thought,
please
share.
I
This
is
this:
is
the
six
six
with
663
be
enabled
across
the
entire
evm,
or
are
you
just
didn't
want.
A
A
C
B
A
Well,
they
still
would
be
a
hard
Fork.
It's
just
that
we
wouldn't
need
to
change
anything
about
the
eof.
We
would
need
to
bump
elf
in
any
way
it.
A
All
right,
yeah,
so
basically
My
worry,
is
I'm
afraid
to
go
to
all
cordoves
the
last
awkward
of
2022
and
asked
to
against
extend
the
scope,
because
I
think
that
we're
not
coming
from
the
strongest
place
with
eof
right
now
and
from
evm
changes
like
I
think
there's
still
a
very
real
possibility
that
we
don't
get
eof
in
Shanghai.
We
don't
get
any
evm
or
we
get
very
few
evm
changes
in
Shanghai
yeah,
so
I
I
feel
like
we
should
focus
on
on
at
least
just
getting
eofm.
H
H
A
Okay
feel
free
to
post
any
updates,
or
you
know,
considerations
in
the
evm
channel
and
Discord.
In
the
meantime,.
J
And
I
think
if
you're,
if
you
do,
want
it
to
be
discussed
on
like
an
Excel
courtes,
and
you
think
this
is
really
important.
I
would
post
something
on
the
alcordev's
Discord
like
today
or
Monday
to
let
people
know
I,
think
if,
like
we
show
up
Thursday
and
no
one's
like
thought
about
663
in
two
years,
there's
probably
no
way
it
happens
in
Shanghai.
J
But
maybe,
if,
like
people
have
like
the
weak,
the
kind
of
debate,
it
then
kind
of
think
through
it,
then
I
I
think
there's
just
like
a
bigger
chance,
but
yeah
I
think.
If,
if
it's
the
first
time
people
hear
about
it
on
Thursday
people
will
just
say
like.
A
Okay,
cool
great
amazing:
let's
start
looking
at
this
checklist,
I'm
gonna
share
my
screen
and
we
can
just
start
going
through
some
of
these
things.
So.
F
Maybe
you
want
to
refresh
it
because
I
was
making
something:
okay,
so
I'm,
not
sure
right.
When
did
you
know
that.
A
Okay,
so
this
is
where
we've
sort
of
been
tracking
the
open
questions.
We've
been
checking
things
off
so
for
the
General
open
question,
we're
considering
using
a
different
set
of
op
codes,
because
we
can
have
all
the
op
codes
for
UF
be
consecutive
rather
than
right
now,
they're
split
across
b0,
B1
and
I.
Think
like
five
E,
five
F
or
something
does
anyone
have
any
strong
feelings
about
making
those
consecutive.
L
B
A
F
C
F
I
mean
right
now
it
is
proposed
Ruby,
but
it
turned
out
two
stories
also
also
proposed
for
for
the
same
slot.
F
Yeah
t-store
tilo,
there's
B3,
B4
and
swapped.
It
was
also
on
that,
but
yeah
I
mean
any
of
these
can
be
changed.
Yeah.
F
Yeah
I
think
that
the
motivation
with
this
e
range-
what's
that
there's
already
like
this
special
EF
and
there
were
I,
mean
I
I,
guess
the
the.
F
A
K
C
F
Maybe
actually
one
one
comment,
the
probably
the
call
F
and
red
f
they
shouldn't
be
where
they
are,
they
shouldn't
be
in
the
F
range.
They
should
be
next
to
the
jumps,
because
you
know
despite
them
called
call
they're
not
working
like
they're,
not
prosecant
calls
they're
within
the
same
account
so
I
think
at
the
very
least,
we
should
probably
move
Cole,
F
and
redf
next
to
the
to
jump
so
into
the
B
range
or
if
you
decide
to
move
all
of
them
to
the
E
range.
F
A
J
A
A
Okay,
let's
keep
going
consider
merging
36.70
and
5450
into
a
single
spec
condition
on
54
50
being
accepted.
I
think
5450
has
been
accepted
and
I
think
that
this
is
something
that
we're
going
to
do
right.
F
Yeah
one
comment
on
that
is
3670
has
some
some
rules
which
are
then
and
then
implemented
in
a
much
nicer
way,
and
sometimes
implicitly,
with
5540
and
and
and
now
we
are
removing
some
things
from
the
motivation
in
36
17
to
make
54.50
easier.
The
net
outcome
is
that
whatever
is
in
the
motivation
is
still
applicable
just
because
it's
split
into
like
two
eips,
it's
not
clear
enough,
so
it
would
make
a
lot
of
sense
just
to
merge
the
two
together.
A
A
And
there
was
some
discussion
about
considering
create
transactions
with
the
invalid
eof
init
code
invalid.
We
discuss
a
little
bit
on
Discord
I,
don't
know
if
anybody
has
any
last
comments
on
it.
I
think
where
it
stands
now.
Is
that
we're
okay?
Nobody
feels
super
strongly
about
either
direction,
but
generally
it
doesn't
feel
like
it's
necessary
to
create
a
validity
requirement
of
transactions
based
on
eof
we're
at
because
this
is
an
operation
that
the
user
knows
beforehand
before
signing
a
transaction
that
it's
going
to
be
invalid.
C
A
We
yeah
this
was
done
last
call
I,
think
and
now
we're
discussing
knots
terminating
in
the
last
instruction
I
think
we
have
discussed
this
a
bit
and
it's
probably
going
to
be
merged.
It's
pending
on
one
last
update.
A
A
Yeah
I
see
I,
think
Alex
probably
marked
this
out.
Did
you
want
to
have
a
comment
on
this
I
think
it
was
pebble,
Pablo,
okay,
yep,
so
we're
just
gonna
stick
with
the
currently
specified
offset
from
plus
three
forward.
A
This
is
merge
this
morning,
specifying
our
jump.
V
I
think
this
was
another
strong
request
from
the
solidity
team,
but
also
generally,
it's
very
small
addition
to
47.50
or
sorry
4200
and
it
it
substantially
improves
the
dealing
with
function
tables
which
basically,
every
smart
contract
has
to
deal
with.
A
So
I
think
that
this
is
in
a
pretty
good
place.
If
you
haven't
taken
a
look
at
the
newly
updated
4200
there
is
that
edition
of
our
jump,
V
47.50
we've
got
elf
functions,
and
this
is
where
we
start
really
getting
into
the
questions
about
the
UF
header
I'm,
trying
to
see
if
there's
anything,
it's
not
related
to
the
eof
header
that
we
should
discuss.
E
H
A
B
A
There's
been
some
debate
for
Rhett
F
on
whether
it
should
clean
the
stack
up
for
the
user,
I'm,
not
sure
if
anybody
wants
to
share
where
that
discussion
currently
is
I.
Think
last
I
heard
there
were
people
were
leaning
towards
cleaning
the
stock.
H
A
F
Way
to
determine
would
be
once
we
have,
hopefully
in
the
next
one
or
two
weeks
in
implementation.
In
solidity,
then
we
can
measure
the
impact
of
this
on
some
code
bases
and
that
could
be
a
data
point
to
to
make
a
final
decision
on
it.
F
And
yeah
I
would
probably,
if
there's
like
a
measurable
difference
between
the
two
and
no
major
downside
to
have
it
done
by
the
evm.
Then
we
should
go
with
that,
but
yeah
it
will
depend
on
the
the
numbers.
A
A
Lift
the
requirement
of
the
last
instruction:
this
is
one
less
check
to
have
an
implementation.
I
think
that
this
is
the
pr
that
we
had.
F
Yeah
so
I
think
I
mean
Pablo
would
be
able
to
explain
because
he
made
that
the
pr
called
new
algorithm
standard
yeah,
so
that
I
think
we'll
ensure
that
there
is
a
there's
always
a
terminating
instruction,
but
it's
not
in
the
control
flow.
But
it's
not
requiring
to
be.
You
know
the
last
instruction
in
the
in
the
section
so
I
believe
it.
It
probably
allows
that
code
in
that
sound,
but
yeah
I'm
not
really
sure.
A
C
A
Hopefully
I
think
like
we're
trying
to
break
into
three
main
categories,
one
like
the
container
definition
and
the
validation
that
can
be
done
related
to
The
Container,
and
so
that's
sort
of
just
checking
that
everything
is
well
formed,
and
so
this
is
still
in
flux
a
bit
but
basically
like
once
we
have
this
complete
you'll
be
able
to
very
easily
see
like
this
is
exactly
what
the
container
looks
like
it's
concatenating,
a
header
and
a
body.
The
header
is
looks
like
this.
The
body
looks
like
this.
A
So
we're
kind
of
imagining
that,
from
an
implementer's
point
of
view,
you're
going
to
start
implementing
this
and
you
have
this
evm
construct
that
can
execute
code,
and
so
this
is
going
to
outline
the
things
that
need
to
be
modified
about
that
construct
when
executing
an
eof
context,
and
so
you
know,
there's
the
basic
stuff
like
execution
starts
at
the
First
Flight
of
the
code
section,
not
the
first
bite
of
the
container.
The
instruction
jump
dust
is
a
no
op.
A
Now
you
can't
use
call
code
self-destruct,
Jump
Jump
by
like
all
the
things
that
are
modified
and
there's
not
that
many
and
then
the
new
Behavior
again,
there's
not
that
many
we've
got
CR
jumps
from
4200
and
we've
got
the
call
F
and
red
f
subroutine
things
from
47.50,
and
this
just
defines
like
very
simply
like
how
much
gas
does
it
cost?
What
does
it
pop
from
the
stack?
How
does
it
manipulate
the
PC
these
things?
M
Okay,
let
just
yes
just
one
thing:
is
there
like
a
specific
time
that
we're
planning
to
finalize
all
these
eips
because,
like
right
now,
all
these
eips
are
implemented
in
our
client,
but
as
PRS,
and
once
we
finish
the
implementation,
we
start
the
review
process.
Then
there
is
more
changes
that
comes
into
the
aips
that
are
happening
recently.
So
is
there
like
a
specific
date
or
time
or
are
we
leaving
it
floating
and
we
we
really
have
to
keep
track
of
all
these
changes
and
keep
implementing
them
till
the
last
moment.
A
We're
gonna,
have
it
like
I,
won't
say
finalize,
because
there
might
be
some
small
things
that
come
out
like
maybe
people
decide
they
want
to
like
change
the
gas
price
slightly
or
there's
like
a
small
check
that
needs
to
be
removed,
but,
like
generally
we're
looking
for
like
a
freeze
early
next
week
for
the
specs,
so
that
way
like
client
implementations,
don't
have
anything
changing
from
out
from
under
them
sounds
good
great.
A
A
Basically,
this
came
out
of
a
couple
of
these
questions
from
the
checklist,
mainly
from
this
question
about
redefining
the
code
section
header
to
be
an
array
of
code
sizes.
The
way
that
we
have
is
specified
now
this
is
the
oh.
This
is
the
unified
spec.
The
way
we
have
this
specified
now
this
is
the
status
quo.
We
have
the
kind
type,
the
type
section
being
an
optional,
and
then
we
have
code
where
there's
at
least
one
like,
maybe
many
and
each
time
you
define
the
size
of
the
code
segment.
A
You
have
to
also
say
client
code,
and
this
just
ends
up
adding.
You
know
a
lot
of
extra
bites,
it's
kind
of
weird
for
the
parser,
and
so
we've
been
thinking
about
like
how
to
improve
these
things
again,
because
a
lot
of
these
eaps
were
written
in
a
way
that
they
could
be
included
notatomically
on
their
own.
We
have
these
quirks
like
kind.
A
Might,
the
the
type
kind
might
be
an
optional
now
that
there's
all
going
together,
I
think
some
things
are
becoming
obvious
and
for
one
that's
that,
because
if
you
have
more
than
one
code
search
and
you
have
to
define
the
type
signature
for
that
section,
that
almost
means
like
certainly
every
single
eof
container-
is
going
to
have
this
as
a
this
as
a
header
field,
and
so
making
it
a
required
field
makes
sense.
It's
you
know
much
more
likely
that
it
will
be
there
than
not.
A
So
that's
what
we
have
for
the
status
quo,
there's
a
few
different
options
that
we
have
the
first
one
is
array
of
code
sections.
This
most
most
of
the
first
couple
here
drop
this
concept
of
kind,
so
you
don't
have
any
kind
of
identifier
for
this,
the
section
information.
So
this
immediately,
you
have
the
type
section
size,
there's
nothing,
that's
trying
to
Define
it
by
like
a
prefix,
byte
and
the
way
the
parser
would
interpret
this.
Is
it
just
knows
that
it
has
a
fixed
location
in
the
header
at
by
four?
A
This
is
where
the
section
size
is
bytes,
four
and
five
and
then
similar
the
code
section
size
is
begins
to
be
a
list
here,
they're
just
like
concatened
u16s,
and
you
can
determine
like
how
many
of
those
there
are
based
on
this
type
section
size
divided
by
two
and
then
we
have
an
optional,
and
this
is
like
Up
For
Debate
a
little
bit,
but
we
have
an
optional
data
size
section
here
and
so,
whenever
you're
implying
the
parser
for
this,
like
you
already
know
exactly
where
the
type
section
size
is,
you
know
exactly
how
many
code
sections
there's
going
to
be,
and
then
you
can
just
check.
A
Are
you
either
at
a
terminating
byte
or
are
you
at
the
kind
of
data
and
then
read
the
data
section
size?
That
is
one
proposal.
There
was
another
somewhat
similar
proposal
where
you
know.
Instead
of
each
of
these
be
in
their
own
section,
we
actually
sort
of
combine
the
code
sections
with
the
the
the
code
sections
with
the
type
section.
So
here
we
Define
like
okay.
This
is
the
number
of
code
sections.
A
A
It's
first,
you
have
to
type
information,
that's
the
first
three
bytes,
and
then
you
have
the
code
after
that,
and
so
this
has
some
nice
advantages
that,
like
there's
like
really
good
locality
of
the
type
information,
the
code
section,
but
then
some
disadvantages
that
you
have
to
always
remember
that
the
executable
code
doesn't
start
in
the
code
section
until
the
third
byte,
and
so
that
feels
you
know
a
little
weird
to
have
to
remember
that
we've
got
this
section
combines
with
arrays
I.
Think
Alex
added
this.
A
This
one
and
I
feel
like
this
is
probably
the
one
that
I
I'm
feeling
like
most
strongly
about
in
a
positive
way.
It's
very
similar
to
the
original,
like
eof
definition.
Basically,
the
there's
a
few
like
Alternatives
that
he
proposes,
but
the
main
thing
here
is
that
we
continued
having
these
kind
these,
like
kind
prefixes.
A
If,
in
the
future,
we
want
to
add
new
Fields,
it's
not
something
that
we
have
to
like
really
bump
the
version
for
we
just
need
to
be
able
to
interpret
a
different
kind
type
after
the
data
section
kind
and
then
last
has
been
discussed
a
little
bit
on
Discord
and
in
some
of
these
calls,
maybe
but
a
multi-level
header.
This
is
where
we
separate
the
header
into
static
components
and
dynamic
components
showing
this
one.
A
There's
like
questions
about
whether
you
want
this
two-layer
thing.
I
think
you
know
I'm
curious.
If
your
comments
about
it
but
I
think,
like
generally,
the
section
comes
with
arrays
is
probably
the
best
approach
and
I
realized
like
maybe
we
should
have
gone
over
like
some
of
the
goals
before
I
like
started.
Diving
into
all
of
these
I
can
just
like
leave
this
up
here.
A
A
A
Any
of
the
client
teams
implementing
this.
What
are
your
thoughts
on
the
different
proposals?
How
do
you
feel
in
general
about
these
goals
for
the
eof
container
thoughts
on
how
to
make
a
decision
on
the
UF
container?
We
had
an
idea
there
about
implementing
a
couple
of
these
in
this
ufrs
and
evaluating
them
against
a
few
different
types
of
contracts
that
you
might
see.
B
A
B
If
the
sections
were
all
required
and
all
in
a
fixed
order,
that
would
really
simplify
things.
That's
probably
the
only
goofiest
part
of
it.
A
Yeah
and
that's
kind
of
like
how
I
was
feeling
about
things,
and
then
we
had
it.
We
were
I
was
talking
with
Alex
the
other
day
and
he
was
explaining
that
some
of
the
motivation
for
these
sections
was
to
be
similar
to
you
know
learnings
from
how
webassembly
and
codes
their
header
sections
I,
don't
know
if
you
want
to
expand
on
that.
Alex.
F
And
I
think
the
motivation,
if
you
scroll
up,
would
would
explain
that,
but
I
can
pick
out.
You
know
the
goals
the
extensibility
describes,
some
of
it,
but
yeah
I
can
highlight
a
few
of
these
pfts,
which
is
even
webassembly,
has
a
version
field,
but
they
don't
expect
to
bump
the
version
field
and
I
think
the
same
Rule
and
logic
applies
to
us.
F
You
know
we
don't
really
want
to
bump
the
diversion
field
of
eof
and
therefore
we
want
to
to
make
the
header
design
in
a
way
that
it
is
extensible
without
bumping
the
version
field
and
then
the
other
like
strong
motivation
is,
is
I,
think
size
based
because
we
are
rather
short
on
size
in
and
and
the
evm
itself
in
the
accounts,
and
now
with
adding
like
a
lot
of
small
helper
functions,
I
think
it's
important
that
the
the
header
defining
those
functions
will
not
be
too
significant
and
the
observation
we
had
that
a
lot
of
they're
like
two
kinds
of
functions,
at
least
two
different
kinds
of
functions
which
would
exist
in
a
in
a
contract.
F
The
one
kind
is
a
lot
of
different
helpers
which
may
have
a
similar
signature.
They
may
have
a
similar
or
exact
same
number
of
inputs
and
outputs,
and
then
you
would
have
a
lot
of
other
functions
which
could
do
anything
else
and-
and
we
want
to
to
make
sure
that
we
don't
base
too
much
space
for
the
metadata.
The
type
information
for
all
of
these
functions,
because
that
would
that
could
defeat
the
purpose
of
using
small
helpers
so
that
that's
like
I,
think
the
two
two
important
codes
regarding
the
header.
M
A
F
I
think
the
main
I
mean
this.
One
I
have
no
idea.
Okay,
but
yeah
I
mean
we
want
the
fixed
order
in
a
case.
A
Okay,
so
I
mean
in
that
case,
if
we
have
the
fixed
order,
then
that
would
basically
give
the
property
that
Dano
was
requesting.
We
have
and
we
have
like
the
extensibility,
because
we
have
the
type
kind,
but
we're
also
enforcing
that
you
know.
First,
we
have
the
type
section
then
the
code
section,
then
the
data
section,
and
so
with
this
eof
version,
one
for
this
Shanghai
Fork.
You
could
write
the
parser
in
a
fixed
manner
other
than
like
reading
a
dynamic
amount
of
number
of
code
sections.
F
F
Yeah
I
mean
just
to
just
to
comment
regarding
you
know
the
the
District
ordering
I
mean
there
was
there
was
a
An
Origin
goal
as
well
and,
like
the
probably
first
version
of
the
3540
EIP.
Even
has
this
alternative
header
parser,
which
only
looks
at
you
know
a
few
bytes.
It's
not
not
the
loop,
honest.
F
Was
always
an
idea
we
wanted
to
to
have
got.
A
A
We're
we're
trying
to
modify
the
container
format
slightly
to
accept
an
array
of
code
sections,
and
so
that's
kind
of
the
root
of
a
lot
of
these
different
attempts
here,
but
they're
all
extremely
similar
for
the
most
part
and
it's
difficult
to
you
know
we're
trying
to
compare
it
on
many
different
axes
as
well.
A
A
F
Do
you
want
to
talk
briefly
about
the
evaluation
criteria?
You
know
which
you
showed
there
for
the
wrap,
if
there's
anything
missing
any
yeah?
Are
there
any
comments
to
this.
F
A
If
you're
not
familiar
with
how
vertical
trees
are
going
to
work,
it's
sort
of
like
chunking
the
accounts
in
128
by
chunks,
and
so
that
means
that,
like
you're
not
going
to
be
able
to
store
code
as
like
larger
than
128
byte
chunk
and
right
now,
the
way
that
it's
specified
is
that
the
first
byte
of
each
code
chunk
actually
points
to
the
index
in
which
code
begins,
because
what
you
can
have
is
you
could
have
a
immediate
from
a
push
extend
across
the
boundary
of
a
chunk,
and
so
the
first,
like
you
know,
31
up
to
31,
bytes
or
so
of
a
chunk
might
be
immediate
push
data,
and
you
won't
be
able
to
know
that
without
reading
the
previous
chunk.
A
Okay,
two
minutes
left.
Let's
talk
about
hasnats.
Let's
talk
about
timing,
I
think
we
mentioned
the
beginning
of
the
call.
Next
Thursday
is
a
pretty
hard
deadline
for
at
spec
completion
and
we're
working
hard
on
making
that
happen,
hopefully
maybe
even
like
Tuesday
or
Wednesday
in
terms
of
actually
like
starting
to
get
interoperability.
I.
Think
it's
pretty
important
that
we
do
this
this
month
and,
of
course,
like
it,
matters
a
bit
like
what
happens
on
the
call
on
Thursday.
A
If
the
call
on
Thursday
the
outcome
is
that
the
UF
does
not
go
into
Shanghai,
then
you
know
we
probably
have
like
less
pressure
to
make
that
happen,
but
like
assuming
those
things
like
go
forward,
there
are
already
withdrawal
test
Nets.
One
of
the
big
complaints
about
eof
is
that
it
might
slow
withdrawals
down
and
we
should
like
be
actively
showing
them.
That's
not
the
case.
A
A
I'm
just
like
coming
from
my
perspective
with
the
Geth
implementation,
it
feels
like
it's,
you
know
once
the
spec
is
there
and
it's
solid
I
think
it's
like
less
than
one
week
amounts
of
work,
because
I
already
have
all
the
Eeps
more
or
less
implemented.
Modulo
like
these
small
changes,
so
for
me,
I
think
yeah
in
two
weeks
would
be
able
to
run
a
test.
None
is
that
something
that
other
clients
would
be
expect
to
be
able
to
participate
in.
C
B
Depends
on
what
else
we
got
on
our
stack
for
basic,
but
two
weeks
where
we're
at
it's
worth,
shooting
for.
H
A
Okay,
that
sounds
good
we're
at
time,
but
yeah.
Let's
keep
chatting
in
the
evm
channel,
we're
gonna
be
working
to
get
the
specs
finalized
and
as
soon
as
they're
in
that
place,
we'll
be
sure
to
let
the
client
teams
know
so
that
you
can
start
finishing
those
last
couple
pieces
and
yeah
on
Thursday,
we'll
figure
out
what
the
situation
in
Shanghai
is
and
decide
when
to
start
opening
a
cross-client
test
net.
I
think
that
you
know
the
before
the
end
of
this
year
is
critical.
We
can
discuss
like
what
the
exact
date
is.
A
I
think,
like
you
know,
maybe
like
two
two
and
a
half
weeks
time
from
today
would
be
a
you
know:
a
reasonable
optimistic
goal
to
shoot
for
so
yeah.
Let's
I'll
keep
you
guys
posted
and
let's
see
how
things
shake
out
next
week
and
yeah
we'll
also
be
working
on
cross-client
tests
so
that,
before
the
test
net,
people
will
be
able
to
run
a
bunch
of
those
and
make
sure
that,
like
generally
they're
that
you
know
all
the
implementations
are
are
kind
of
in
the
places
that
we
expect
them
to
be.