►
From YouTube: EOF Devnets Breakout Room
Description
A
Okay,
so
we're
recording
we'll
upload
this
to
YouTube.
After
for
people,
it's
not
live
stream,
though
I
guess
yeah.
The
the
main
purpose
of
this
call,
just
based
on
the
conversation
in
the
last
awkward
Dev
I,
think,
is
to
try
and
figure
out
what's
the
best
path
forward
for
eof
and
how
do
we
kind
of
get
started?
Working
on
that
I
think
there
was
a
lot
of
discussion
on
accordance
about
whether
we
want
to
do
kind
of
one
big
eof
release,
or
you
know
split
it
up.
A
It
seems
like
people
would
rather
have
one,
but
the
risk
there
is
that
if
it's
too
big,
it
might
not
make
it
into
Shanghai.
Although
some
people
were
optimistic
that
maybe
we
can
make
one
big
eof
version
and
get
it
into
Shanghai
I
think
the
the
biggest
probably
objection
by
client
thieves
is
like
the
idea
of
like
changing
the
version
too
often.
B
C
C
They
don't
deliver
much
and
we
would
like
to
have
a
complete
package
with
with
some
benefits
and,
to
my
mind,
we
also
need
to
add
one
extra
Eep
to
completely
disable
Dynamic
jumps
and
to
verify
that
we
can
compile
solidity
contracts
without
Dynamic
jumps,
and
that
would
be
a
selling
feature
of
uof
because
without
it
without
disabling
Dynamic
jumps,
then
it's
not
clear.
What
is
the
win
of
eof,
so
I
kind
of
how
I
understood
it
and
I
I
concur.
C
Mario's
point
is
that
it
doesn't
make
sense
to
have
a
somewhat
intermediate
version
of
eof.
Erf1
that
doesn't
doesn't
give
any
benefits,
just
introduces
a
new
format,
but
then
we'll
have
uof2,
which
will
presumably
deliver
benefits.
But
then
there
is
no
no
urgent
need
no
urgent
pressure
to
have
some
kind
of
intermediate
version
without
any
benefits.
That's
my
take.
D
E
C
And
and
I
would
like
to
add
at
least
how
I
see
it,
maybe
because
I
don't
know
anything
about
solidity,
but,
to
my
mind,
the
the
trickiest
bit
is
actually
implementing
it
in
solidity
and
if
we
have
verified
that
we
that
it
works.
Fine
in
solidity,
then
on
the
client
side
and
we
have
like
a
a
complete
complete
spec,
then
maybe
it's
not
that
difficult
to
add
it
into
into
El
the
clients,
but
perhaps
I'm
wrong.
Perhaps
it's
not
that
difficult
on
the
solidity
side.
F
Yeah
I,
like
I'm
like
a
bit
more
optimistic
right
now
so
I
kind
of
expected
that
we
actually
decide
that
we
don't
any
of
that
in
Shanghai,
because
there's
no
space
for
it
and
there's
like
two
two
major
features
that
people
want
to
be
in
the
next
hard
work
so
yeah
at
least
I'm
glad.
There's
some
people
interested
still
in
this
and
we
can
work
it
on
on
a
on
the
side,
kind
of
and
one
one
comment
about
solidity.
C
But
I
guess,
if
you
don't
have
Dynamic
jumps
for
eof,
maybe
if
it's
still
possible,
if
it's,
if
solidity
is
still
fine
with
it,
then
the
the
the
the
benefit
of
eif
would
be
easier.
Verification
and
probably
some
speed
gains
because
there
won't
be
any
jump.
Check,
jump
desk,
check,
analysis
and
stuff
like
that.
So
there
will
be
a
small
gain.
F
Yeah,
well,
it's
it's
not
directly
for
them,
because
it
doesn't
really
matter
like
technically
if
they
like
use
the
existing
jobs
on
the
new
jumps
like
how
they
generate
codes
like
they
will
like
do
the
same
kind
of
thing,
but
all
right
not
really
something.
That's
changed
the
code
generation
right.
So
maybe
it
will
be
a
bit
cheaper,
but
this
is
not
like
exactly
like
answered
how
much
cheaper
that
will
be
if
the
Johnson
keeper.
A
B
Yeah
I
would
say
their
position
is
a
bit
more
subtle
than
that.
Just
to
answer
like
Andrew's
question,
whether
the
first
just
like
the
the
format
change
would
give
any
benefit
to
solidity.
It
doesn't,
but
it
also
doesn't
require
any
major
changes.
In
fact,
that
EIP
was
already
implemented
last
year
in
solidity
and
it's
fairly
small.
B
The
the
main
benefit
it
brings
is
rather
from
trying
to
verify
evm
code,
so
it
could
be
useful
for
for
l2s
and
since
it
doesn't
really
introduce
any
like
gas
reductions
to
the
user
side.
Any
speed
benefits
it
gives
to
the
client
comes
as
a
benefit
because
there's
no
reduced
gas,
so
it
technically
could
speed
up
coins
in
a
minuscule
percentage.
B
Now,
regarding
the
full
set
of
features
that
I
think
does
bring
benefits
to
solidity
on
two
sides.
What
we
discussed
it
can
reduce
some
of
the
pressure
on
the
code
layout
generator
because
right
now
they
have
to
move
around
like
the
return
address
on
the
stack
and
it
can
also
depending
on
what
gas
prices
we
end
up
deciding
on,
because
the
gas
prices
for
the
function
section
isn't
actually
decided.
Yet
it
could
bring
I
mean.
B
First
of
all,
it
should
be
at
least
the
same
cost
as
it
is
today
in
the
worst
case,
but
likely
it
could
bring
some
or
more
benefits
on
the
gas
side
and
it
could
also
bring
stumps
like
code,
size
reduction
and
implementing
all
this
in.
In
solidity,
it's
not
inherently
complex,
but
it
will
take
a
tiny
bit
of
time
because,
of
course,
the
team
is
kind
of
overloaded
with
other
work.
B
D
G
E
I
think
there
is
two
things
here:
one
is
introducing
new
up
codes,
basically
static,
jumps
and
call
of
the
function,
and
second
thing
is
object:
format,
basically
enforcing
those
things
to
basic,
using
only
those
things
and
removing
all
jobs.
So
first
step
would
be
introducing
all
those
OP
codes.
So
this
way
the
compiler
and
everybody
work,
karate
can
use
it
and
then
the
second
step
is
introducing
format.
G
E
A
C
Andrew,
how
I
see
it
in
in
terms
of
the
implementation?
It's
absolutely
fine
to
move
step
by
step
so
yeah.
The
first
natural
step
is
to
introduce
the
new
OP
codes
and
the
the
new
called
f
redf,
whatever
instructions.
But,
to
my
mind
it
should
be
a
kind
of
a
parallel
stream
of
work
so
that
they
dedicated
stream
of
work
to
uof,
and
we
do
not
release
it
into
into
a
main
net
hard
Fork.
Until
we
we
we
have
the
the
last
bit,
namely
disabling
Dynamic
jumps.
C
And
that's
your
format
is
version
one
and
because
Mario's
concern
was
which
I
share
is
that
there
is,
if
we
introduce
some
uif
format,
version
one
which
has
Dynamic
jumps,
then
we'll
have
to
support
that
forever
and
I
would
rather
avoid
doing
that.
So
in
terms
of
yeah
in
terms
of
implementation,
absolutely
move
step
by
step,
but
in
terms
of
adopting
it
as
a
mainnet
mainnet
update,
then
I
would
go
for
one
for
the
whole
package.
E
E
Maybe
we
should
First
Step,
introducing
our
codes,
leave
it
for
the
for
the
while
and
then
introduce
object
format
after
that.
That's
that's
the
point.
So
if
we
have
time
to
bundle
them
all
together,
great
it
makes
a
lot
of
sense.
Format
is
basically
how
it
makes
a
lot
of
sense
yeah,
but
that's
just
one
of
the
possible
Parts,
nothing
more.
A
B
You
cannot
increase
any
of
these
up
codes
without
the
format
because
they
rely
on
immediates
and
if
you
don't
use
immediates
for
them,
then
you
go
back
to
the
the
original
problem
of
having
them
efficiently.
So
they
definitely
depend
on
the
format.
You
cannot
go
the
other
way
around
and
and
what
Greg
was
explaining,
that
the
validation
algorithms
we
have
it
depends
on
not
having
Dynamic
jumps
in
order,
for
you
know
the
function,
sections
to
properly
operate.
A
I
Hey
I
was
just
wondering:
is
anybody
not
in
favor
of
the
end
goal
of
of
achieving
all
of
these
separate
parts,
because
I
mean
what
I'm
hearing
all
of
this,
both
in
the
all
core
devs
call,
and
in
this
call
as
well,
is
really
saying?
Well,
hey?
Can
we
divide
this
thing
into
parts?
Do
we
want
to
do
a
step
on
the
way
or
do
we
want
the
whole
thing?
A
So
I
think
the
question
is,
though,
assume
assuming
we
all
want
that
that
end
goal.
How
strongly
do
we
feel
about
trying
to
get
something
in
Shanghai?
Basically-
and
this
is
probably
where,
like
there's
there's
differences
in
opinion
like
yeah,
you
see
the
chat,
is
there
so
I,
don't
know,
maybe
a
way
that
that
kind
of
phrase
this
is
like.
What's
you
know,
what's
the
minimal
set
that
that
that
people
would
want
to
see
in
Shanghai?
What's
like,
maybe
a
stretch
goal
in
a
way
yeah?
A
Because
and
and
is
we
already
have
basically
a
minimal
set
than
Shanghai,
which
is
just
35,
40
and
36
pests,
70
I
think
the
the
the
code
validation
but
yeah?
Is
there
more
like
I
guess?
Is
there
more?
We
would
want
beyond
that,
even
as
a
minimal
set
and
then
what's
the
if
we
could
get.
You
know
the
whole
thing
in
what
does
that
entail.
C
K
J
Yeah
I
think
it's
been
a
while,
since
we've
really
made
like
substantial
changes
to
the
evm
and
Shanghai
is,
in
my
opinion,
the
right
time
to
do
it.
We
don't
have
like
huge
changes
going
into
it
right
now,
maybe
4844
but
I'm,
guessing
that
444
is
going
to
not
be
ready
until
later
next
year,
and
so,
if
we
do
Shanghai
early
in
the
year,
then
it's
basically
just
withdrawals.
J
So
that's
the
right,
like
we
have
availability
to
ship.
This
and
most
of
it's
already
done
in
terms
of
like
specifications,
and
we
just
need
some
implementation
to
test
it.
So
I
would
rather
have
the
full
set
to
deprecate.
The
dynamic
jumps
I
mean.
Is
anybody
against
the
full
set
to
do
this
like?
Are
we
still
debating
whether
to
do
that
versus
the
current
CF
isolated.
L
J
A
C
Yeah,
like
my
preference,
would
be
my
kind
of
personal
preference.
How
I
see
it
is
that
we
can
keep
Shanghai
a
small
and
deliver
withdrawals
there
and
also
solve
the
issue
of
synchronizing
El
and
cl
updates
and
then
have
two
parallel
streams
occur
on
top
of
Shanghai,
eof
and
and
4844
block
transactions.
So
how
I
see
it?
We
could
create
two
two.
Maybe
two
provisional
updates
like
to
provisional
hard,
forks,
uif
and
blob
transactions
and
because
eof
what
we
want
to
do.
C
We
want
to
deliver
a
a
number
of
Eeps,
so
we
want
to
synchronize.
We
chips
go
in
and
so
on.
So
it's
it's
it's.
It
can
be
a
dedicated
hard
fork
or
it
can
be
end
up
merging
with
the
the
work
on
block
transactions.
But
what
I
would
do
I
would
separate
the
two
and
have
two
two
parallel
streams
of
work
because
they
are
independent
of
each
other.
They
might
progress
with
different
speed,
but
when
we
realize
that
okay,
we're
done
with
uof
and
block
transactions
are
not
done,
then.
J
C
J
J
Because
there's
so
many
things
being
slated
right
now
to
go
into
future
Forks
like
we
have
4844,
we
have
vertical
trees,
we
have
data
availability
sampling.
We
have
all
these
things
that
people
are
wanting
to
do
and
eof
is
not
going
to
like
overtake
something
like
a
vertical
and
so
I
think.
The
best
that
we
can
do
is
ship
it
in
with
another
Fork.
C
Well,
the
thing
is
that
you,
you
kind
of
if
the
the
the
the
the
the
the
this
work
is
quite
independent,
one
is
heavily
on
the
EDM
side
and
the
other
is
touches
the
different
layers,
mostly
so,
if
it
can
be
even
a
smaller
group
of
people
working
on
the
eof,
but
I
would
like
to
verify
that.
Okay,
we
have
a
working
solidity
compilation
into
the
full
eof
format
that
works.
We
can
compile
smart
contracts
into
eof
fine,
then
you
can
say:
oh
okay,
it's
ready.
C
So
let's
merge
it
with
another
hard
Fork.
That's
no
problem,
because
the
bulk
of
the
work
is
is
done
already,
so
it
doesn't
have
to
be
a
dedicated.
It's
just
the
timing.
The
time.
My
point
is
that
we
need
to
decouple
the
timing,
but
then
we
can
we
when
we
are
ready,
we
can
couple
it
with
something
else.
I.
J
Just
don't
understand
like
how
what
you're
describing
is
different
than
what's
been
happening
for
the
last
three
years,
because
I
think
that
there
has
been
a
parallel
track
of
people
working
on
these
things
and
they
have
been
developing
this
and
specifying
it
like
exactly
like
you're
saying
and
now
we're
coming
to
that
point,
where
we
want
to
couple
it
with
a
fork
and
I.
Think
Shanghai
is
like
the
perfect
Fork
to
couple
it
with.
A
Right
but
I
guess
maybe
like
the
the
just
like
zoom
out
a
little
bit
I
think
you
know
the
4-h4
people
would
say
the
same
thing
or
it's
like
I.
Think
the
similarity
there's
this
other
effort.
That's
trying
to
get
this
in
Shanghai,
so
I,
don't
know,
is
the
and
then
what
we've
landed
on
basically
on
the
CL
side
is
that
we
have
this
this.
This
withdrawals
fork
and
then,
on
top
of
it
we're
prototyping
4844
and
we
might
choose
to
release
them
at
the
same
time.
A
M
Yes,
so
two
things
from
from
another
mind
perspective:
we
already
implemented
the
the
eaps
for
let's
say
simple,
eof
or
at
least
are
partially
implemented
like
being
tested,
and
we
have
capacity
to
pay
attention
to
leave
and
implement
the
whole
thing
for
Shanghai
whenever
that
would
be
in
the
end,
but
there's
a
question
of
testing
it,
because
we
are
touching
more
and
more
things,
so,
complexity
of
testing,
Rises
and
that's
the
main
concern
of
mine.
Can
we
like
guaranteed,
stay
being
stable
and
secure
on
the
release
yeah?
M
That
being
said,
this
has
full
support
of
another
mind
and
we
want
to.
We
want
to
prototype
it.
We
want
to
be
included,
and
we
want
to
see
it
through
whether
earlier
or
later,
one
more
thing,
Greg
directly
can
we
can
you
reach
out
to
me
or
I
can
reach
out
to
you
about
code
generation.
We
have
actually
one
very
interesting
proof
of
concept
in
never
mind
of
generating
a
native
code
from
bytecode
like
dynamically
and
I.
Would
maybe
this
would
interest
you
and
yeah?
That's
that's
it
for
me.
N
Yeah
one
suggestion
from
from
me
is
that
how
about
if
some
client
teams
like
as
as
Lucas
said
Netherland
is
all
for
for
aof?
Obviously,
but
if,
if
some
client
teams
are
feeling
hesitant
about
implementing
the
full
aof
for
Shanghai,
what
if
we
can
like?
Okay
put
in
the
plan
that
before
Shanghai
and
the
devnets,
we
will
test
eof
a
couple
of
the
IPS
that
are
in
the
URF
spec.
N
And
these
are
a
must,
even
if
they
are
not
included
in
Shanghai,
but
they're
a
must
for
devnets
and
in
devnets.
We
will
include
them,
but
for
Shanghai
we
want,
and
that
will
push
the
clients
to
implement
these
ones.
And
then
once
the
spec
is
finalized
for
the
other
ones.
The
clients
can
work
on
them
and
the
full
eof
can
be
included
in
the
next
Fork,
not
in
Shanghai.
Just
just
an
idea.
N
A
Think
the
thing
we
I
would
try
and
avoid
is
be
in
a
spot
where
the
code
is
just
very
coupled
and
then
we
need
to
remove
it
from
Shanghai,
basically
so
like.
If,
because
in
the
past,
we've
seen
consensus
issues
on
maintenance
caused
by
removing
eips
that
are
activated
together.
So
that
would
be
my
only
my
only
like
concern.
There
is
like,
if
we're
unsure
about
the
scope,
then
maybe
just
separating
it
like
you,
could
imagine
a
basic
definite.
A
A
F
D
D
F
Okay,
that's
like
two
I
think
so
I
think
we
can
go
with
this,
like
as
a
like,
like
first
sets
of
pictures,
because
it's
already
there
and
like
people
can
join
if
they
are
late,
and
we
can
already
start
like
doing
something
with
this.
But
I
like
for
the
like
first
feature
set.
I
was
actually
considering
also
adding
Pro
zero
because
that's
evm
related
and
there's
one
that
has
additional
costs
for
proportional
to
the
Eid
code,
size
and.
F
A
A
O
O
F
I
can
answer
this
yeah
I.
Think,
like
your
feelings,
are
right
and
I
agree
with
this,
so
we
mostly
like
dump
it
as
a
like
prototype.
So,
like
people
like
to
be
noticed
that
we
kind
of
also
working
on
this,
that's
why
it's
like
this
is
like
in
the
Prototype
State
and
that's
that's
not
even
the
first
prototype.
It's
like
the
second
iteration
that
we
internally
were
working
on.
That's
why
it's
like
python
code
describing
more
or
less
what
we
don't
and
there's.
F
F
F
A
I
think
yeah
I
think
if
it's
not
fully
specified
like
and
given
time
teams
have
pretty
small
resources
like
we
can
always
do
multiple
devnets
right
like
we
don't
have
to
do
everything
at
once.
My
gut
feeling
would
be
trying
to
add
4200
and
47.50
first,
and
that
gives
the
Epsilon
team
some
time
to
specify
54.50
in
parallel
and
also
like
a
easier
Target
for
for
find
teams
to
reach.
That
might
be
a
better
way.
I,
don't
know
how
crime
teams
feel
about
that.
F
So,
like
finish,
this
one
I
think
like
we
kind
of
invite
people
to
like
take
a
look
on
this
and
maybe
try
to
understand
what
we
mean
by
it,
and
we
also
will
try
to
like
explain
what
we
mean
by
by
this,
like
what
the
benefits
are
like,
maybe
like
next
week
or
two
but
I
wouldn't
schedule
it
for
any
development
at
this
point,
and
it's
also
not
required
to
get
rid
of
dynamic
jumps.
So
it's
kind
of
not
like
needed
for
that.
F
A
Okay,
so
if
we
have
this,
then
as
like
a
sort
of
spec
for
the
devnet,
which
is
35
40,
36
70
4200
47.50,
what's
the
best
way
to
implement
it,
do
we
just
want
to
extend
Shang
dong
and
add
to
eips
I
know,
teams
are
starting
to
work
on
withdrawals
as
well,
so
like?
Is
it
better
to
just
have
a
devnet,
that's
built
on
top
of
withdrawals,
yeah
I,
just
recline
teams
like
what's
the
best
way
to
do
it?
O
Would
we
need
to
do
a
reset
of
shangdong,
because
I
know
there
there
was
chatter
on
their
Discord
are
doing
it
this
weekend?
Do
we
set
a
date
where
we're
going
to
turn
on
the
two
new
eats
I
mean
I?
Think
qingdong
is
a
good
solution
to
get
this.
You
get
something
running
where
people
can
work
together
and
validate
code
together
on
a
test
Network.
A
F
So
like
this,
this,
like
assuming
it
will
continue
running
for
some
time
this
one
one,
nice
feature
one
nice
thing
we
can
do
about.
It
is
to
to
deploy
static,
jumps
and
the
thing
is
they
are
backwards
compatible
with
the
current
eof
that
is
deployed,
so
we
can
test
if
that
works
nicely,
I'm,
not
sure
if
we
even
need
hard
work,
or
maybe
even
coordination
would
be
enough.
Like
we
said
like
from
this
date,
clients
actually
have
it
implemented,
I,
don't
know
what
is.
O
So
4200
and
47.50
static,
relative
Junction
functions,
I
view
those
as
forward
compatible.
We
don't
have
to
reset
the
system
if
we
suddenly
start
accepting
it
at
one
date,
because
everything
that
is
valid
before
it
is
also
valid
under
the
future.
So
it's
it's
just
increasing
the
scope
and
clients
there
aren't
up
to
date
will
just
fall
behind
until
they
implement
it.
Yeah.
F
F
A
F
That's
that's
eof
functions
and
that
will
require
the
version
bump.
So
there
are
two
two
ways
we
can
do
it.
We
can
do
with
the
EOS
version
bump,
so
we
can
test
it
out
or
we
can
just
reset
the
test
net
with
the
new
eof1
but
have
more
features
but
I
think
that
would
be
we'll
need
to
like
start
from
from
scratch.
So
I
don't
know
like
you
actually
have
a
lot
of
questions.
How
this
track
does
not
operate.
C
Yeah,
my
kind
of
in
Aragon,
we
don't
have
any
implementation
of
EOS.
So
from
our
point
of
view,
we
definitely
would
like
to
separate
tests
test
nets
for
Shanghai
core,
like
withdrawals
and
whatever
goes
into
Shanghai
and
EOL,
because
if
we
do
them
in
a
single
test
now
that
that
that
would
slow
down
withdrawals
for
Aragon
from.
H
N
M
I
have
a
question
about
state
of
testing
apart
from
devnets
I,
see
that
as
a
good,
very
good
integration
testing
and
very
good
practical
testing.
But
from
implementing
point
of
view,
the
various
useful
tests
are
Hive
test
ethereum
tests
and
are
there
any
test
vectors
being
prepared
there
for
any
of
those
cips?
Or
maybe
we
have
it
already
in
some
PRS.
D
M
D
F
Yeah
so
like
for
that
first
we
have
state
tests,
that's
kind
of
like
I,
don't
know
almost
ready,
so
we
can.
You
can
use
it
there
in
the
prequest
for
tests
test
repo.
We,
like
ethereum
JS,
actually
found
an
Embark
in
the
test,
so
we
have
to
fix,
but
so
far
it
looks.
Okay
and
and
the
next
one
is
actually
to
get
tests
for
the
eof
functions.
F
F
Like
one
of
the
issues
that
we're
not
allowed
to
merge
these
to
the
main
tests,
because
they
are
not
like
decided
if
they're
going
to
Shanghai,
so
they
are
living
somewhere
else
and
I,
don't
know
how
to
make
somewhere
else
to
be
brought
to
the
hive
testing.
So,
like
all
of
this,
like
moving
parts,
that's
that's
kind
of
the
problem.
I
think.
A
K
A
A
D
So
my
opinion
is:
if
we
want
to
create
a
hard
work
on
Shandong,
we
should
decide
how
we
want
to
Fork
it
by
timestamp
or
by
block
number,
and
maybe
it
will
be
easier
just
to
restart
shutdown
on
this
stage.
It's
not
like
big
damage,
because
we
did
it
a
few
times
so
I
think
maybe
the
better
will
be
start
restart
the
Shandong
when
we
Implement
these
features.
A
A
I
agree
like
not
having
to
deal
with
the
timestamp
stuff
is
probably
good.
If
we
restart
chengdong,
do
we
want
to
have
one
or
two
different
hard
Forks
on
it
like
do
we
want
eof
to
be
part
of
the
same
hard
Fork
as
all
of
the
rest
of
Shanghai,
or
do
we
want
to
separate
it
in
the
code
so
that
it's
easier
to
not
turn
eof
on
in
the
case
where
it
wasn't
part
of
Shanghai.
N
I
think
the
the
other
eips
that
are
included
in
Shandong
already
are
fine
and
are
already
implemented
from
our
site.
So
we
don't
have
a
problem
with
them
being
included
with
whatever
eof
eips.
We
want
to
add
into
Shandong
so
that
I
believe
it's
it's
it's
it's.
It's
fine
to
just
stick
with
Shandong
for
any
eof
testing
and
just
include
the
same
here.
Ips,
okay,.
A
H
L
A
C
Well
from
for
Aragon,
the
strong
preference
is
to
have
to
restart
changdon
without
any
uif
eaps
concentrate
on,
but
but
have
withdrawals,
and
it's
like
concentrate
on
withdrawals
testing
and
make
sure
that
withdrawals
and
Shanghai
go
work.
Fine
and
have
a
a
fork
later
or
maybe
a
parallel
test
net.
So
I'm
like.
L
C
A
O
O
A
My
preference
would
be
for
us
to
have
devnets
that
are
building
towards
what's
actually
included
and
then
separate
devnets
that
build
for
stuff,
that's
like
CFI
or
on
on
defense,
and
that's
kind
of
why
I
think
it
would
make
sense
to
like
refactor
shangdong,
because
then
you
can
have
regardless.
You
know
if
we
decide
to
include
something
next
week
say
we
decided
1153
was
included
or
BLS
was
included
that
becomes
part
of
Shanghai
core.
A
We
like
changed
that
set
of
VIPs
there
and
then,
if
you
know,
we
have
something
like
eof,
we
just
build
it
on
top
with
the
4844
stuff.
We
also
build
it
on
top
and
then
at
the
point
where,
where
these
get
included,
we
decide
to
like
yeah.
We
decide
to
merge
them
together,
but
that
would
mean
it's
a
bit
more
work
now
for
trying
teams,
but
I
think
it
might
put
us
in
a
spot
where
it's
easier
to
like
add
and
remove
stuff.
J
But
also
yeah
I
would
also
prefer
to
try
and
minimize
the
number
of
configs
we
Define.
So
okay,
like
maybe
one
extra
one,
is
okay
but,
like
generally
I,
think
I,
you
know.
I
would
also
just
be
happy
to
have
like
a
core
Shanghai
and
continue
building
on
this
and
whenever,
if
and
whenever
we
happen
to
remove
things,
we
can
cross
that
bridge
and
remove
them.
I.
Don't
think
that
that's
going
to
be
like
you
know,
a
huge
amount
of
work.
A
A
Well,
I
think
from
Awkward
as
it's
like
well
you're,
going
to
want
some
withdrawals
devnet
as
soon
as
possible,
and
then
the
question
is
like
what
else
should
be
part
of
that,
so
that's
kind
of
where
I
want
to
make
sure
we
don't
like
diverge
too
much
here
because
it's
like.
If,
if
on
one
hand,
we
have
people
implementing
withdrawals,
that's
actually
the
main
thing
we
want
to
like
prioritize.
J
I
mean,
from
my
perspective
on
guests:
that's
yeah,
pretty
straightforward
for
us,
but
I
think
that
we
have
maybe
a
bit
more
of
eof
implemented
in
smaller
clients.
So
it's
a
little.
It's
a
little
less
work
in
that
front
yeah,
but
like
if
I
was
the
only
one
making
a
decision.
I
would
just
say
to
have
the
next
test
not
have
everything
slated
for
Shanghai,
including
the
full
Elf,
including
the
trolls
right,
but
we.
P
Yeah
I
was
gonna,
say
why
don't
we
just
Target
a
test
net,
that's
for
the
CFI
erps
and
then,
if
the
U.S
stuff
is
ready,
we
can
add
it
I
guess
the
concern
is
it's
going
to
be
complicated
to
like
have
that
optionality
in
the
clients,
but
I?
Don't
think
we
should
like
walk
it.
Just
for
this
other
work
stream,
I.
P
J
A
But
we
can
have
it
together
once
it's
done
and
we
decide
like
and
I
guess
the
thing
I
really
want
to
avoid
is
say
it
takes
us
an
extra
week
to
implement
like
I,
don't
know
some
EOS
EIP.
You
don't
want
that
to
delay
the
withdrawals,
work
right
like
or
whatever's
already
included.
So
that's
the
risk
I
see
with
just
bundling
them
is.
A
O
O
So
as
far
as
officially
pulling
things
out
of
shingdong
into
Shanghai,
when
they're
proven
I
think
that
shouldn't
be
too
terribly
hard,
especially
if
it's,
if
it's
all
of
shangdong
on
top
of
all
of
Shanghai
it'll,
be
really
easy.
So
we
pick
and
choose
out
of
Shing
qingdong,
depending
upon
the
features
that
it
might
get
harder.
K
F
A
O
A
I
guess
yeah
just
because
we're
already
we're
already
kind
of
over
time,
it
seems
like
maybe
the
lowest
friction
thing
to
do
in
the
next
couple
weeks
is
to
try
and
just
add
4200
and
47.50
to
shangdong
whether
we
restarted
or
hard
Fork
it
or
not.
You
know
that
doesn't
really
matter
and
then
maybe
just
get
into
that
spot
where
we
have
that
implemented
in
clients
interoperating
on
shangdong.
A
C
A
Right
well,
withdrawals
is
not
in
shengdong,
yet
right
so
like
it's
possible
to
implement
and
I
believe
test
withdrawals
without
qingdong
I
know,
Marius
was
working
on
some
stuff
there,
because
I
agree.
I
agree
like
this,
like
basically
withdrawals
should
take
priority
over,
like
all
the
other
sort
of
prototype
stuff.
C
A
A
D
A
Let
me
see
things
okay,
but
that
means
we
should
reset
shangdong
because
it
means
let
me
actually
write
this
down.
Super
quick
and
I
can
be
so
you
have
Shanghai
core
which
would
have
these
VIPs.
Sorry
I'll
share
my
screen
in
like
in
one
second,
but
just
to
make
sure
we're
all
on
the
same
page
about
this
and
then
shangdong
and.
A
A
A
D
A
No
I,
just
no
but
I
mean
that,
like
in
the
Genesis
file,
you
sort
of
have
you
know
the
like
Shanghai
core
activation
at
like
block
zero
and
then
maybe
you
have
shangdong
activated
like
block
one
or
whatever
or
I.
Don't
know
if
I
some
clients
can
put
them
at
the
same
block
but
then
and
then
the
the
484
Ford
test
net
is
just
like
this
right.
So
but
this
is
like
shangdong
I.
C
A
K
C
A
C
A
Correct
so
you
have
three
test:
Nets
yeah.
You
have
Shanghai
core
shangdong
and
444
Shanghai
Court,
just
activates
this
stuff
and
then
but
then
the
200
test
Nets.
They
activate
it,
but
they're
almost
like
two
different
Forks.
They
just
activate
one
after
the
other
or
if
it's
other
easier
to
bundle
it
all
together
in
one
fork.
That's
fine
as
well,
but
the
CL
clients
are
like
doing
4844
this
way,
basically
where
they
activate
Shanghai
core
and
then
the
the
the
the
the
oh
does.
H
A
A
N
No
because
it
will
be
a
totally
different
devnet,
so
you
don't
need
to
remove
anything.
There
will
be
different
config
files
for
each
devnet,
that's
it
so
it
you
won't
need
to
fork
or
do
anything.
You
will
have
one
con
one
config
file
for
Shanghai,
including
includes
the
first
four
and
another
config
file
that
includes
the
first
three
plus
the
the
four
from
Shandong
that
you
are
listing
and
okay
for
4844.
You
would
have
the
first
three
plus
four,
eight
four
four
and
that's
it.
A
N
From
Shandong
experience
because
we
had
to
run
a
CL
client
for
Shandong
as
well,
we
had
also
like
a
separate
config
file
for
the
CL
clock
configurations.
So
it's
it's!
It's
not
that
for
each
test
net
you
need
to
Fork.
No,
it's
it's
not
like
that
for
one
test
net,
you
have
one
config
file
period,
so.
A
A
H
A
A
A
Okay,
I
think
yeah
I
think
we're
good,
then.
So
in
terms
of
next
steps,
client
teams
can
start
looking
at
for
200
47.50
and
then
on
all
core
devs.
We
can
figure
out
the
right.
The
right,
devnet,
config
and
I'll
I'll
write
something
up
and
share
it
in
the
agenda,
so
that
yeah,
it's
teams
have
have
the
chance
to
review.