►
From YouTube: EOF Implementers Meeting 9
Description
A
Cool
okay,
hello:
good
morning,
everybody
Welcome
to
the
eof
implementers
call
number
nine:
let's
go
ahead
and
get
started
with
some
client
updates.
Is
anybody
have
anything
to
share
since
the
last
time
we
spoke.
B
Basically
we're
starting
to
test
out
its
T8
and
software
and
getting
some
feedback
from
the
testing
team.
It
runs
against
the
execution,
client,
specs
and
just
running
around
some
of
the
undocumented
Corners
that
we're
encountering
and.
C
D
A
E
A
E
And
we
also
have
I
believe
Andre
is
on
the
call,
so
he
could
expand
on
it,
but
I
think
we
have
a
mostly
finished
implementation
of
the
2.0
stuff
in
regards
to
create
I.
I
can
give
some
updates
later
on
on
the
call,
but
we
did
a
number
of
like
back
and
forth
in
in
terms
of
the
design,
but
I
think
you're
Nearing.
E
A
F
F
I
know
that
I'm
an
adjusted
to
the
latest
changes
of
here
but
I
I,
don't
know
details
to
be
honest.
So
maybe
we
can
go
back
when
he
fix
audio.
A
E
Yeah
I
don't
have
anything,
but
the
solid
team
had
the
off-site
thing
in
last
week
or
this
week,
which
probably
is
more
about
planning
and
I,
expect
you
to
get
more
feedback
from
them
starting
next
week.
You
know
when
once
they
finish
with
offsite
and
all
that.
A
A
E
You
know
with
the
evm
plus
they
may
have
read
our
minds,
which
has
it
either
wise.
We
were
thinking
about
renaming
UF
to
evm
next
or
EDM
Plus,
but
we
are
too
slow
to
make
a
decision
and
announce
it
on
Twitter,
so
I
guess
they.
They
picked
up
the
evm
plus
name
instead
and
Craig.
What
is
evm,
plus
it's
nothing
to
do
with
evm.
As
far
as
I
know
it's
it's
awesome.
A
Hey
I'm
in
is
here
Mike
working
now.
G
Okay
for
never
mind,
we
implemented
a
draft
for
v1.1
and
for
jump
F
just
to
be
ready
and
currently
trying
to
see
how
virtual
will
be
easily
integrated
into
what
we
have
right
now
and
we
kind
of
have
some
opinions
when
it
comes
to
what
has
been
discussed
and
what
we
try
to
implement.
Hopefully,
we'll
discuss
them
later.
This
call.
A
Okay,
spec
updates.
E
Actually,
there's
one
thing:
Hugo
from
our
team
is
working
on
changing
the
with
your
NPR
moving
everything
to
Cancun,
because
with
that
he
can't
refill
every
single
test
to
to
Cancun
because
they're
currently
set
to
Shanghai.
So
what
the
goal
is
that
the
the
test?
Suite
there's
no
changes
to
the
semantics.
E
It's
just
changing
the
evm
version
from
Shanghai
to
Cancun
and
for
that
yeah.
If
you
go
exchanging
to
go
with
your
MPR
and
that's
I,
think
I
mean
he's
finished
with
that
and
he
started
to
refill
the
test
and
he
will
push
them
to
the
testing
speed.
A
E
I
think,
since
the
the
last
the
US
called
two
weeks
ago,
since
then,
we
had
two
or
three
internal
discussion
holes
in
epsilon,
just
to
align
at
least
ourselves,
in
what
we
would
like
to
propose
regarding
the
changes,
and
we
took
a
look
at
the
outstanding
PRS
and
the
eip's
repo,
as
well
as
made
up
our
minds
regarding
the
the
flex
field,
which
we
just
discussed
in
the
last
call
and
I.
Think
we
also
kind
of
made
up
our
minds
in
regards
to
the
1.1
changes
and
the
2.0
changes.
E
A
E
Okay,
okay,
so
this
is
the
the
first
PR
it's
about
changing
how
the
table
size
in
rgmv
works,
and
you
have
internally
think
that
this
is
a
good
change
and
we
would
like
to
have
it.
We've
made
some
verification
verifications
to
them
to
the
pr
I
think
it
would
be
good
to
get
like
a
final
decision
on
testicle.
Is
anybody
against
emerging
test
change,
I,
think
Dano
and
at
least
Deno
commented
on
it?
So
probably
then
it
was
there
were
what
this
changes
I'm,
not
sure
what
everyone
else.
A
Yeah
I
think
she
did
I
thought
we
discussed
something
kind
of
like
this.
I
don't
know
if
it
was
just
specifically
our
jump
V,
but
it
feels
a
little
weird
to
have
the
table
size
be
plus
one.
The
actual
value
encoded
in
the
Opera
operand.
B
B
So
that's
you
know
it
does
look
a
little
bit
like
plus
one,
but
that's
just
the
old
zero
one
based
indexing.
It's
there's
no
clean
way
to
allow
what
we
need
to
do,
which
is
to
allow
256
table
with
with
fall
through
for
a
for
an
out
of
range
number
for
a
256-bit
without
having
this
weirdness
with
it.
But
it's
not
too
weird.
E
So
the
reason
we
are
leaning
towards
having
this
is
I
mean
exactly.
As
you
say,
the
initial
design
was
Guided
by
you
know:
spec
simplification
and
really
from
the
evm
implementer
side,
and
the
proposed
change
is
done
from
the
evm
user
side
and
it's
clearly
seems
to
be
a
really
useful
feature
to
be
able
to
to
have
256
locations,
because
then
you
can
have
a
very
simple
jump
table
and
especially
for
having
a
jump
table
for
implementing
evm
within
the
VM
and
I
think
we
we
feel
like
that.
E
B
E
And
this
is
a
more
complex
Topic
in
the
sense
that
it
would
be
nice
to
have
I
will
on
the
call
okay
he's
on
the
corner,
but
also
with
the
eof
1.1
and
2.0
changes.
This
kind
of
becomes
obsolete
around
the
fringes.
E
E
So,
with
the
the
1.1
I
mean
I
can
share
the
document
again.
We
discussed
this
I
think
the
first
call
after
a
device,
and
let
me
just
share
that
link
again.
E
Okay,
so
this
was
the
the
roll
admin
so
basically
with
the
UF
1.1,
which
is
the
other
version
we
want
to
roll
out
that
won't
allow
contract
creation
within
us,
so
we
are
removing
the
create
and
create
two
instructions
from
UF
code
and
and
the
only
way
we
enable
creating
UF
contracts
is
through
creation
transactions.
E
E
However,
Legacy
evm
code
cannot
create
UF
code
through
create
and
create
two
instructions
and
I
think
currently,
there
have
been
like
multiple
ways:
I,
don't
remember
what
the
1.0
actually
does
do.
We
then
eof
creation
from
Legacy
or
not,
but
I
think
at
some
point
we
did
want
to
Bennett.
E
So
the
final
proposal
is
that
Legacy
evm
code
cannot
create
eof
contracts
with
Creator,
create
2.
UF
code
cannot
use
Creator
create
two
euf
code
cannot
be
used
in
a
create
transaction,
I
mean
it
can,
but
it
cannot
return
anything.
So
it's
pretty
much
useless,
and
that
remains
that
the
Legacy
evm
code
in
the
create
transaction
is
the
one
which
creates
eof
contracts,
and
at
that
point
it
can
inspect
the
UF
contracts
because
it
uses
the
same
old
return
mechanism.
E
But
if
you
like
that,
any
other
option
is
just
way
too
complicated
for
not
many
benefits
and
the
only
only
way
to
avoid
any
of
that,
like
intermediate
complication,
is
going
straight
to
2.0,
yeah
I'm,
not
sure.
If
any
of
this
made,
like
complete
sense
to
you,
listening
because
I'm
a
bit
tired
and
really
better
explained
today,
but
maybe
I
will
yeah.
A
D
B
E
Yes,
it
is
only
the
create
transaction
that
the
reason
we
want
to
burn
existing
Legacy
code
using
the
create
doc
code,
because
then
you
can
just
have
proxies
right
and
right
that
definitely
defeats
any
any
kind
of
banning
of
introspection.
So
the
only
one
is
the
the
create
transaction
which
it
feels
like
it's
a
smaller
surface
area.
B
E
B
Right
well,
I
mean
get
rid
of
so
we
have
a
legacy
contract
and
it
does
a
legacy,
create
ban
it
from
deploying
users
create
op
code
Banning
that
sequence
from
creating
eof
code,
so
eof
can
only
be
created
from
a
contract,
create
transaction.
H
Yeah
I
mean
to
be
precise,
it's
you
will
have
Legacy
evm
code
as
they
need
code
in
a
create
transaction,
and
the
result
of
that
will
be
eof
contract
right.
B
H
Only
they
need
code
will
be
will
be
used
yeah.
The
Legacy
will
be
used
in
other
unit
code,
so
we
don't
have
to
design
it
for
eof.
We
also
thought
that
maybe
it's
only
temporary
solution
until
we
have
the
proper
creation
for
UF
but
I,
don't
know
like
I,
think
it's
debatable.
If
we
want
to
later
remove.
Also
this
this
workaround
or
not,
I
I,
don't
see
it's
like
super
harmful,
actually,
because
this
init
code
will
never
end
up
and
it's
kind
of
like
ephemeral
in
this
way.
B
B
I
B
E
For
the
call
but
I
didn't
manage
to
I
would
like
to
add,
however,
that
as
we
progress
with
the
2.0,
there
is
a
slight
chance
that
maybe
the
2.0
design
will
end
up
being
simple
enough.
That
we
could
just
go
with
it
directly
and
we
don't
need
the
intermediate
step
right.
I
E
We
we
can
back
towards
some
of
those
or
you
know,
split
up
the
2.0
partially,
but
until
that
is
figured
out,
I
think
this
is
the
the
option
we
are
leaning
towards.
E
The
the
other
major
option
we
we're
looking
at
is
that
it's
a
create
transaction
with
eof
in
its
code.
But
then
you
need
to
modify
some
of
the
semantics
and
it's
just
too
hairy
it's
it's.
It
doesn't
seem
to
work
the
the
risk
and
and
overhead
having
those
like.
You
know,
special
semantics
and
then
switching
to
2.0
right.
So,
in
short,
I
think
what
we're
leaning
towards
is.
Either
we
go
with
this
option
or
we
go
2.0
directly.
A
G
G
E
Mean
the
the
2.0
could
be
also
staged.
You
know
that
I
mean
the
design
space
is
still
open
and
and
I
think
we
could
actually
go
without
like
a
create
transaction
and
only
have
like
this
deploy
deployer
contract
and
all
that-
and
you
know
this
could
be
stage
that
only
some
of
them
is
introduced
in
Cancun
yeah.
G
I
was
gonna
say
that,
from
our
point
of
view,
we
would
prefer
to
do
them
all
at
once,
not
separated
like
this,
since
we
found
it
pretty
annoying
and
hairy,
as
we
said
before,
to
introduce
that
special
context
for
certain
op
codes
to
behave
like
other
opticals,
as
it
is
mentioned
in
the
document,
and
we
didn't
like
it
to
be
honest
and
it
will
it
felt
like
extra
overhead
and
experimental
stuff
to
keep
in
mind
while
implementing
this
stuff
and
yeah.
That's
our
stands
on
it.
We
would
prefer
to
do
it
all
at
once.
E
E
It
is
just
a
sheer
number
of
changes
and
we
don't
know
the
these
size
yet
right,
because
2.0
isn't
fully
designed.
E
And
and
to
to
that
end,
Epsilon
is
having
an
off-site
at
eat
Porto
next
week,
and
we
hope
to
get
more
clarity
on
the
2.0
discussion.
So
I
think
it
will
be.
The
next
implementary
call
will
be
like
a
good
time
to
to
see
the
complexity
of
2.0
and
where
we
could
just
go
directly
to
2.0.
E
H
F
And
you
will
have
this
extra
version
forever
in
evm,
when
we
know
that
we
want
to
change
it
in
future.
It's
like
strange
a
bit
that
we
already
doing
two
versions.
E
D
H
Yeah
I
kind
of
agree
like
this
is
like
one
one
point
of
view,
but
on
the
other
hand,
we
most,
we
have
like
most
of
the
things
done
for
1.1
and
we
can
continue
implementation
and
testing
of
this
part.
Why?
We
kind
of
also
think
that
2.0
is,
is
a
bit
more
into
design
phase,
so
yeah
just
just
to
be
able
to
do
some
stuff
in
parallel.
That's
I
think
that's
my
interpretation.
Why
it's
going
this
way.
It
also
depends
how
much
time
we
actually
have
to
for
the
first
shipment.
A
E
E
But
yeah
I
agree,
I
mean
2.0
and
done.
That's
that's
an
exciting
option,
Okay.
So
with
this
in
in
2.0,
with
the
create
instruction.
One
result
of
that
is
that
we
actually
don't
care
about
the
nons,
the
account
notes,
so
it
becomes
like
irrelevant
and
since
we
don't
have
the
old
create
instruction
which
dumps
the
nons,
we
can
fully
ignore
the
nulls,
and
now
we
can
probably
you
know
with
this
context.
E
We
can
talk
about
the
the
pr
regarding
the
the
nonce
changes
and
maybe
Pavel
wants
to
discusses,
because
it's
his
PR
and
I
don't
fully
I.
Don't
really
get
you
know
what
status
we
are
in.
There
have
been
a
number
of
changes,
whether
we
bumped
the
loans,
whether
we
bump
the
nons.
Maybe
probably,
if
you
want
to
explain
the
pr.
H
The
spec
how
it
was
was
kind
of
like
unclear
how
it's
supposed
to
work
and
the
nouns
is
bumped
when
you,
when
you
do
a
creation
of
a
contract
using
Create
distractions,
and
this
is
kind
of
yeah.
You
have
to
decide
like
what
kind
of
failure
make
it
to
stick.
The
nose,
Bob's
the
stick
or
like
what
kind
of
failure
of
the
contract
creation
happens
before
the
analysis
bump.
But
kind
of
this
is
always
messy,
because
this
spec
is
kind
of
chain
of
different
checks
and
different
modifications.
H
But
anyway,
the
specification
of
the
UF
wasn't
clear
what?
When
it's
supposed
to
happen?
H
And
now
we,
if
you
go
to
the
create
transaction,
the
nouns
is
always
bumped,
because
this
is
kind
of
relevant
how
transactions
work
and
we
decided
that
in
it
like
init
code.
Failure
during
create
transaction
is
is
not
like,
doesn't
make.
The
transaction
valid
is
kind
of
registered
on
the
blockchain,
which
means,
even
if
the
init
code
fails.
H
The
the
nouns
is
already
bumped
and
and
like
decision
for
the
create
instruction
was
to
to
to
match
this
Behavior
as
well,
in
a
sense
that
we
bump
the
nouns
for
the
for
the
sender
of
the
create
instruction,
and
then
we
check
if
the
init
code,
validation
is,
is
good
and
if
it's
not
the
the
north
remains
increased.
So
that's
was
that's
the
clarification.
There
is
a
kind
of
the
other
way
of
doing
this
and
there
was
some
back
and
forth
between
different
implementations,
but
not
going
into
like
historical
historical
aspects
of
that
yeah.
H
This
is
more
or
less
the
clarification
and
I
think
on
our
side.
We
are
happy
with
that.
I
mean
I
would
be
happy
with
whatever
decision,
but
we
need
to
make
one.
So
this
is.
This
is
what
it
the
request
does,
and
this
kind
of
mostly
affects
the
current
test
we
already
have,
if
we,
if
we
quickly
just
disable
or
like
reject
the
create
instruction
in
the
year
of
code,
this
this
this
this,
this
issue
kind
of
go
away
and
we
don't
have
to
care
about
it.
H
So
I
think
this
is
all
also
wow
I.
Don't
know
it's
like
this
is
always
kind
of
alternative
option.
How
to
solve
it,
but
I
think
I
would
like
personally.
I
would
just
like
take
make
the
the
modification,
and
we
will
make
sure
that
evm
implementation
and
GAP
implementation
and
this
the
generated
tests
are
in
sync
with
that
and
whatever
we
will
remove
some
of
the
tests
later.
I
think
it's
it's
not
something.
We
will
be
really
sorry
about.
B
B
Do
we
require
them
always
to
come
up
with
a
new
with
a
new
Hash,
a
new
solve
for
the
hash,
relying
them
using
stuff
like
the
type
stamp
operation
for
the
hash?
Or
is
there
a
way
to
say
just
give
me
a
different
hash.
B
Right
I
mean
you
could
always
use
different.
You
could
use,
you
could
use
an
operation
to
give
you
random
values.
I
mean.
Is
that
what
we
want
to
present
as
the
best
thing
to
get
new,
because
you
also
lose
deterministic
contracts,
you
you
don't
have
a
deterministic
address.
This
is
especially
problematic
for
things
like
developer
tools,
who
want
to
do
the
same
contract
three
times
in
a
row
and
get
the
same
three
results
in
a
row
without
having
to
provide
the
same
three
notices
in
a
row.
B
B
I
mean
I
like
the
idea
of
a
fully
deterministic
address
coming
out,
but
I
think
we
need
to
handle
a
situation
where
the
people
creating
it
don't
care
what
the
salt
is,
and
they
don't
want
to
rely
on.
You
know
what,
if
they
want
to
do
multiples
of
the
same,
they
don't
care
what
it
is,
but
they
want
repeatable,
which
is
kind
of
a
paradox.
E
You
know,
because
of
like
code
size
limits
a
lot
of
the
like
defy
projects
where
you
need
to
deploy
a
pool.
All
of
that
is
happening
with
you
know,
with
external
transactions,
unitop
is
only
one
exception,
with
the
factory
contract
and
I.
B
Well,
maybe
not
costumes
like
boot
camp
people,
people
who
are
like
switching
from
from
writing
database
applications
to
writing
smart
contracts.
You
know
the
the
people
who
aren't
as
as
enfranchised
and
smart
Contracting
evm,
so
it
might
be
surprising
for
them
I
mean.
Maybe
we
just
need
to
establish
patterns
and
communicate
this
better.
B
It's
I,
don't
think
we
need
to
resolve
it
today
is
but
I
think
it's
something
we
need
to
keep
in
mind
of
people
who
want
to
create
contracts
and
don't
care
what
the
address
is.
Maybe
we
do
just
socialize
using
pre-brand
out
as
as
the
hash
and
just
deal
with
the
fact
that
in
tests
environments
you
might
get
different
results
and
that
they'll
have
to
figure
out
how
to
reduce
their
entropy,
which
is
a
problem
they
need
to
figure
out
anyway,
for
a
good
repeatable
system.
E
So
I
think
there's
like
a
distinction
between
like
two
different
use
cases,
one
where
the
you
know
the
programmer
wants
to
do
some
of
that
creation,
and-
and
maybe
they
don't
know
any
better,
and
the
second
is
the
testing
in
front
of
of
Frameworks
and
I
would
imagine
that
Foundry
has
so
many
cheat
codes
for
everything.
I
would
be
surprised
if
there
is
no
cheat
code
for
finding
the
last
Creator
the
contract
address,
and
maybe
most
of
the
testing
actually
works.
E
B
E
Yeah
I
would
say
the
short
answer
is
that
we
haven't
looked
into
this
and
then
he
helps
would
be
appreciated.
You
know,
looking
more
into
to
the
question
you
asked.
B
E
I
would
say
the
state
of
the
artist
the
pr.
Let
me
just
push
the
link.
B
We're
going
to
implementation
first
route
rather
than
the
specification
first
route.
E
B
B
E
E
E
Maybe
under
the
specification
section
in
it,
we
can
put
like
UF,
1.1
and
2.0
it's
a
subheading
and
that
could
that
could
be
a
good
way
to
to
find
these.
E
Yeah,
actually,
with
the
the
create
three,
we
did
had
one
question
but
yeah.
Let's,
let's
move
on
and
then
we
can
Circle
back.
So
the
last
piece
is
regarding
the
flags
on
the
last
Implement
there's
call.
We
had
a
link
to
discussion
whether
we
should
have
flags
as
a
flex
field
in
the
type
section
or
not
and
I
think
we
were
torn.
There
seemed
to
have
been
you
know.
Some
reason
said
it's
maybe
useful,
but
a
lot
of
people
argued
that
it
isn't.
E
The
two
extra
use
cases
beyond
the
non-returning
function,
which
was
discussed
was
the
Purity
level,
which
I
think
is
still
like
a
good
idea,
but
I,
don't
think
we're
gonna
have
any
time
to
properly
investigate
it,
and
maybe
making
a
decision
based
on
on
this
unconfirmed
idea
is,
is
probably
bad,
and
so
the
only
remaining
reason
was
whether
we
should
Mark
in
it
code
with
this
flag
or
not,
and
there
there
have
been
some
reasons
why
this
could
be
useful.
E
But
as
we
went
down
some
of
these
creatory
discussions,
we
realized
that
it
wouldn't
be
sufficient
to
have
the
flag.
It
wouldn't
be
enough
to
fully
determine
and
the
the
main
reason
for
that
is
10
init
code
other
functions
and
if
it
can
collab
your
functions,
should
those
be
marked
in
its
code
as
well
or
not,
and
this
discussion
was
quite
long.
But
what
we
ended
up
concluding
is
that
the
init
code
is
a
flag,
doesn't
seem
to
be
a
good
enough
solution.
E
So
our
proposal
is
to
not
have
the
flex
field
and
they
haven't
agreed
on
what
is
the
special
value
for
the
non-returning
function,
but
we
would
like
to
have
a
special
value
to
you
to
Mark
a
non-returning
function,
and
this
value
would
go
into
the
number
of
outputs
and
the
two
options
we
discussed
is
0ff.
E
So
all
bit
set
or
0x81,
which
means
the
top
bit
set
in
the
lowest
bit
set,
and
this
option
would
would
signal
that
the
top
bit
means
that
we
are
talking
about
flags,
and
you
know
we,
we
choose
the
first
flag
yeah,
that's
our
proposal
to
choose
either
zoof
or
zero
x81,
and
we
won't
have
a
special
Flex
field.
B
I
B
E
Yeah
this
was
the
the
document
we
discussed
last
time
and
out
of
this
yeah,
it's
a
use,
special
value
0ff
or
we
use
Reserve
bits
as
Flags.
So
that's
the
0x81,
yeah
I
think
out
of
the
Epsilon
team.
It
was
only
me
who
was
leaning
towards
having
like
a
dedicated
Flex
field
with
pick
bit
packing.
E
Everybody
else
was
leaning
towards
not
having
it.
So
you
know
that
means
from
Epsilon.
We
say
we
don't
want
to
have
the
flex
field
on
Tesco
I
think
we
should
make
a
final
decision
on
this
call.
E
Yeah
I
mean
the
question
is
through
FFF
or
or
81,
which
is
the
value
we
are
going
for,
I'm,
not
sure
Pavel,
because
Pablo
or
Andrea
you,
you
guys
had
a
strong
opinion.
So
maybe
you
want
to
you
know:
what's
it
now.
H
I
H
A
Yeah,
that's
fair
I
I
do
like
zero
x81
for
the
forward
compatibility,
the
ability
to
change
it
add
more
things.
A
I
don't
know
if
that
is
the
case
for
the
the
xeroxff,
because
I
think
0xff
is
just.
This
is
a
value,
because
output
is
only
one
one
byte.
B
But
zero
x81
applies
to
me
is
that
we
might
use
all
the
space
from
negative
one
to
negative
127
if
you're
looking
at
a
signed
in
approach
to
it,
whereas
oxf
means
we're
just
working
from
255
down
I'm
taking
up
spaces
as
we
go
so
I
think
81
would
be
a
bit
clearer
and
that
we
intend
to
have
more
special
values
in
the
future.
A
E
A
A
I
know
you
said
you
wanted
to
Circle
back
and
talk
about
eof2.
There
was
one
other
thing
that
we
mentioned:
I'm,
forgetting
it
now
do
you
remember.
A
E
It
was
becoming
too
noisy,
yeah
I
think
what
we
were
arguing,
whether
we
should
go
directly
to
2.0
or
not,
and
the
2.0.
E
What
it
involves
is
the
create
codes,
the
return,
some
kind
of
a
return
or
code
and
a
create
transaction
or
some
kind
of
a
a
create
pre-compiled.
So
to
say.
E
And
I'm
personally
leaning
towards
more
of
having
the
the
create
pre-compile
option,
because
that
means
we
don't
actually
need
a
new
transaction
type
and
that
likely
reduces
the
surface
area,
which
then
increases
the
likelihood
that
we
can
roll
this
out.
At
the
very
same
time,
the
the
risk
with
having
new
transaction
types
I
see
is
that
you
know
we're
going
Beyond
just
evm
changes
into
you
know
many
more
layers
which
seems
to
be
risky.
E
A
A
One
of
those
things
is
trying
to
figure
out
what
the
transaction
format
looks
like
going
forward
and
there's
a
couple
different
camps
but
yeah
trying
to
change
those
things
all
at
once,
while
adding
new
transaction
types,
it
will
be
pretty
challenging,
but
it
might
also
be
useful,
at
least
just
something.
That's
part
of
the
discussion
trying
to
think
if
eof
did
have
a
new
transaction
format
does
that
transaction
format
fits
nicely
within
the
world
of
the
SSC
transactions
that
that's
being
proposed.
A
J
Who
Among
Us
is
is
deeply
enough
involved
in
the
SSC
discussions
to
the
liaison
on
that.
B
So
for
me,
if
we're
gonna
do
by
what's
currently
called
pre-compiles,
it
opens
up
a
can
of
worms
because
there's
a
pre-compiles
we
could
always
used
to
do
through
evm
code,
but
now
we
got
something
we
can't
do
through
evm
code
and
we're
publishing
system
barriers.
I
mean
I'm
fine
with
that,
but
it's
it's
newground
that
we
should
make
sure
we
do
correctly.
A
E
So
yeah
the
the
pre-compile
I
mean
yeah
I
may
have
been
a
tiny
bit
misleading.
So
even
the
pre-compile
option
requires
some
changes
to
the
transaction
format,
but
not
as
severe
as
introducing
like
a
special
create
transaction
I
mean
all
of
this
is
written
down
in
in
this
uf2
document,
but
I
do
understand.
The
document
is
long
and
confusing
so
likely
it
may
not
be
clear
enough
what
is
being
meant,
but
some
of
that
is
under
this
heading.
E
In
short,
what
this
means
that
we
would
have
another
kind
of
create
instruction
like
create
four
or
whatever,
which
gets
the
init
code
from
a
transaction
context,
and
the
change
we
would
need
to
do
to
the
transaction
formats
is
the
way
we
have.
You
know
like
the
blob
blob
data
in
the
in
the
4844
transactions.
E
We
could
have
another
list
of
of
blobs,
and
these
are
init
codes,
init
code,
blobs
and
this
new
create
instruction
would
take
an
index
and
index
into
which
which
of
these
init
code
blobs
is
being
used
from
the
current
transaction
context.
E
So
that
would
be
the
you
know
the
the
size
of
the
changes-
and
this
is
against
the
option
where
we
introduced,
like
a
special,
create
transaction
type
and
the
the
main
reason
I'm,
leaning
towards
is
just
the
complexity
of
having
a
new
transaction
type,
but
also
for
more
for
compatibility
reasons,
because
it
seems
that
now
transaction
types
are
proliferating.
There's
just
you
know
a
new
transaction
type
every
single
year
and
this
doesn't
seem
to
be
a
sustainable
path.
E
If
we
would
end
up
with
proposing
this
option,
I
would
actually
go
strong
in
the
you
know.
Ssd
discussions
to
state
that
this
new,
like
4844
transaction
type,
is
only
for
in
contract
interaction.
It
cannot
be
used
for
any
kind
of
creation,
and
it
will
have
these
like
init
code
blobs
as
well,
and
in
that
Paradigm
we
only
have
the
Legacy
transaction
types
which
are
as
complex
as
they
are
today.
A
We're
a
couple
of
minutes
over
time
now
we
should
probably
wrap
this
up.
Any
last
comments.
A
E
Okay,
including
comment
I,
think
in
the
next
next
implementary
call.
We
should
dedicate
it
to
the
eof
2.0
discussions
and
I
think
we
will
work
hard
from
Epsilon
to
actually
post
a
document
before
that.
E
But
let
me
know
if,
if
you
have
any
any
other
like
strong
opinion
and
we
shouldn't
pursue
like
this,
you
know-
transaction
Direction.
I
was
explaining.