►
From YouTube: PEEPanEIP #116: Dencun Testing with Parithosh, Mario, Barnabas #ethereum #blockchain #testing #evm
Description
Resources:
-----------------
Devnet 8 specs - https://notes.ethereum.org/@ethpandaops/dencun-devnet-8
How to join - https://dencun-devnet-8.ethpandaops.io/
Slides - https://docs.google.com/presentation/d/1lGlPxga9QDVDeCEPT04DAFPhaehtKDP_/edit?usp=sharing&ouid=110450674004865651218&rtpof=true&sd=true
PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Dencun - https://www.youtube.com/playlist?list=PL4cwHXAawZxpnKFDl1KzGOKqwux5JaLlv
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow at Twitter
--------------------------
Parithosh Jayanthi @parithosh_j | Mario Vega @elbuenmayini | Barnabas Busa @BarnabasBusa | Pooja Ranjan @poojaranjan19
Topics covered
-------------------------
0:57 - Skip intro
1:27 - Meet Barnabas Busa
2:05 - Meet Mario Vega
2:46 - Meet Parithosh Jayanthi
4:06 - Introduction to Dencun Testing
6:19 - Testing flow
14:40 - What kind of test we will run?
18:53 - Execution Specs Tests (Python EVM Tests)
20:31 The Pytest generation flow
24:24 - What do these tests contain?
27:41 - PyTest for Cancun - EVM changes
31:08 - EIP-4844 tests
34:40 - Current state of Functional Testing for Cancun
35:55 - What is Kurtosis? Why do we care?
37:42 - Example of Kurtosis configuration
38:57 - Background - Kurtosis engine and how we interact?
39:50 - Interop issues identified with Kurtosis
40:35 - Dencun - Devnet 8
41:58 - Holesky Coming soon
42:10 - Inviting name ideas for public testnet
42:30 - End of presentation
43:28 - Q&A
43:50 - Testing sequence
45:01 - Testing EIP-7044 & EIP-7045
47:17 - When public testnet? Will it be Holeski?
50:00 - If the testnet is broken with 3/6, what will it going to be?
51:21 - Where are we with Execution specs? Are we ready for Dencun?
54:04 - What can be done to move forks faster?
59:32 - Testnet participation - how can solo validators can participate?
1:01:00 - How far do we see Goerli in the future?
1:02:34 - Success story & road blocker
1:06:12 - When Dencun?
1:07:20 - Message for the community
A
A
As
most
of
you
may
know,
Denco
is
a
next
planned
ethereum
Network
upgrade
currently,
clients
and
testing
teams
are
working
on
a
developer's
test
net,
also
known
as
devnet,
and
the
number
is
eight
to
share
more
about
then
contesting.
We
are
joined
by
ethereum
testing
team,
Mario,
Vega
and
Barnabas
Busa.
Thank
you
all
for
joining
us
on
p
penny.
C
Foundation
one
year
ago
and
I
have
joined
just
a
couple
of
months
before
the
merge
has
happened.
I've
been
working
in
the
sub
team
of
the
devops
team
of
the
interim
foundation
called
the
eat.
Pandavs
and
they've
been
primarily
responsible
for
testing
all
the
features
that
are
coming
to
the
ethereum
as
a
whole.
We
have
launched
multiple
test,
Nets
and
devnets,
since
I
was
responsible
for
launching
individual
testnet
and,
let's
see
I've
been
working
on
the
duncan.net
and
some
other
testing.
D
Hey
my
name
is
Mario
I
work
for
the
testing
team.
I
joined
the
EF
two
years
ago
now,
and
my
thing
job
is
to
basically
write
functional
testing
for
all
the
updates
and
the
at
the
up
and
the
upgrades
that
happened
through
the
new
ethereum
Forks
that
have
happened.
I
joined
before
the
marsh
and
wrote
depths
for
the
new
HD
clients,
also
against
those
clients
on
the
mark
and
also
on
Shanghai
and
now
on
Lincoln.
D
B
I'm
paritosh
I'm
also
on
the
same
team
as
Barnabas,
so
the
eat,
Panda,
Ops,
Team
and
most
of
the
work.
We
do
revolves
around
coordination
for
testing
so
knowing
which
tool
affects
what,
where
and
how
we
can
most
efficiently
spin
up
test.
Nets
and
of
late
we've
been
trying
to
refine
a
lot
of
our
processes
so
that
we
can
not
only
support
one
fork.
So
earlier
we
were
just
able
to
test
the
merge
or
test
withdrawals,
but
nothing
else.
A
A
B
B
B
So
with
all
of
this,
the
scope
of
testing
has
just
become
really
really
important,
and
today
we
want
to
give
you
a
bit
of
an
insight
into
what
tools
we're
using
to
achieve
this
and
how
we're
doing
it
and
at
the
same
time,
to
try
and
give
you
a
glimpse
into
how
we've
been
organizing
ourselves
to
support
more
than
one
fork
at
one
time.
So
today,
right
now
we
are
testing
Buckle,
we're
testing
the
nav,
we're
testing
a
bunch
of
feature
Forks.
B
So
we
have
this
one
EIP
I,
think
6110,
which
is
deposit,
processing,
workflow
changes,
and
we
have
a
bunch
of
devnets
for
that
and
I
see
that
plans
on
the
call.
So,
just
last
week
we
launched
tiny
test
net
with
him
about
whisk,
so
that's
another
upgrade
coming
up,
so
we
have
a
feature
for
for
that
and
we
also
have
vocal
testing
and
we
will
be
having
UF
testing
as
well
and,
as
you
can
see,
this
is
very
different
structure
from
how
we
had
in
the
past,
where
I
think
with
the
merge.
B
For
example,
we
had
everyone's
efforts
focused
on
the
merge,
but
right
now
we
have
a
lot
of
small
feature.
Folks
and
everything
needs
to
be
tested.
Well,
so
we
yeah.
Hopefully
this
desktop,
gives
you
a
bit
of
a
glimpse
into
how
that's
going
to
be
achieved
yeah.
So
this
is
kind
of
a
glimpse
into
a
testing
workflow.
How
do
we
try
to
bring
order
into
chaos
so,
as
with
everything
we
start
with
spec
releases,
so
this
is
kind
of
the
starting
point
when
we're
trying
to
get
involved.
B
Of
course,
there's
the
whole
EIP
process
before
that.
There's
there's
a
whole
bunch
of
thoughts
that
has
been
put
into
stuff
beforehand,
but
we
try
to
get
involved
once
it's
at
least
considered
stable
enough
that
it's
getting
into
the
tax
repo
and
by
the
spec
sleeper
I'm,
meaning
more
or
less
consensusly
aspects,
people
and
from
there
you,
the
client
teams
can
start
implementing
the
specification
as
defined
there,
and
they
would
tend
to
do
that
either
in
a
branch
or
a
fork.
B
So
that
was
already
fine
kind
of
our
first
got
you
you
can't
hard
code,
any
branch
or
any
repository
anywhere.
You
have
to
be
able
to
dynamically
build
everything.
Just
dynamically
refer
to
everything
actually
and
one
example
of
where
we
had
to
do.
This
is
client
teams
tend
to
build
Docker
Images,
slash
releases
just
for
their
Mainline,
slash,
potentially
and
unstable
release,
but
nothing
else.
B
So
we
had
to
set
up
our
own
builder
system
such
that
we
can
build
each
and
every
single
client,
irrespective
of
which
fork
or
which
branch
it
is,
and
that
took
a
decent
bit
of
time
to
actually
get
right.
There
was
someone
the
team
who
had
to
learn
basil
against
their
will.
God
bless
that
person,
but
it's
working
we're
using
it
stably
once
we
know
that
we're
targeting
a
certain
branch
of
fork.
B
We
also
add
it
to
a
config
and
it
gets
built
every
hour
so
that,
if
there's
a
change,
we're
able
able
to
easily
reference
that
change,
and
we
also
had
to
kind
of
standardize
our
naming
scheme.
So
all
the
images
we
have
have
a
certain
naming
scheme
which
tends
to
be
Branch,
slash
commit
so
that
at
first
glance
you
already
know
what
branch
am
I
talking
about.
What
commit
am
I
on
and
what
issue
do
I
have
with
that
commit
that
kind
of
makes
it
a
lot
easier
for
us
to
do
things.
B
Had
someone
been
paying
attention
to
hive,
so
one
thing
we
try
to
enforce
this
time
is
we're
not
going
to
go
ahead
with
devnets
until
people
are
passing
High
tests,
so
we
kind
of
stalled
devnet
progress
until
Hive
was
mostly
green
or
the
failures
were
acceptable
failures
or
known
failures
or
failures
that
we
knew
were
non-trivial
to
fix
this
already
caught
like
a
tunnels.
Hey
do
I,
have
a
certain
engine,
API
version
up
or
will
I
be
able
to
even
accept
this
request.
B
This
takes
care
of
a
lot
of
base
level
problems
that
we
were
always
watching
on
devnets
and
one
of
the
reasons
we
wanted
to
do
this
is
our
devnets
are
high
coordination
issue
and
it
takes
a
bunch
of
time
away
from
client
devs
to
debug
those
developments,
as
well
as
from
everyone
else
to
debug
those
devnets.
Whereas
Hyde
is
a
nice
clean
package,
you
can
download
the
logs.
You
know
what
you
give
in.
B
B
Barnabas
is
going
to
be
talking
about
that,
and
one
of
the
reasons
we
were
so
confident
about
its
launch
is
because
we
kind
of
saw
that
a
lot
of
issues
were
taken
care
of
by
Hive
already
and
what
wasn't
taken
care
of
by
Hive.
We
kind
of
used
local
distance
to
figure
it
out
this
time,
so
local
testnets
a
tool
we're
using
a
tool
called
kurtosis
to
do
this.
B
It's
implementing
tests
in
stellar
and
you
define
them
in
a
simple
Json
body
and
Barnabas
is
also
going
to
show
you
guys
an
example
of
this
later
on.
But
essentially,
what
you
can
do
is
you
can
have
a
mini
test
net,
go
through
a
certain
fork
and
see
how
the
network
is
going
to
react
and
the
reason
we
want
to
do.
This
is
not
that
I've
come
to
interrupt
testing,
but
we
also
want
to
do
local
interrupt
testing.
B
B
One
of
them
refuses
to
validate
all
the
time
the
network
is
80,
performant
and
because
there's
just
five
nodes,
it's
very
obvious,
which
one
is
missing
and
looking
through
the
logs,
it's
very
apparent
as
to
what
was
missing
so
and
we're
able
to
take
this
kurtosis
Json
body
and
share
it
with
the
client
teams.
So
it's
also
kind
of
a
reproducible
issue
that
everyone
is
going
to
face.
So
we
were
able
to
knock
out
a
lot
of
problems
in
no
time
and
the
kurtosis
test
Nets.
B
You
can
also
mess
with
the
time
and
you're,
basically
doing
it
locally,
so
you're
not
dependent
on
anyone.
So
you
can
do
100
runs
an
hour
if
you
want
and
then
just
skip
through
a
lot
of
the
issues
and
in
our
current
workflow.
We
do
this
a
bunch
of
times
until
we're
happy
with
the
result
and
once
we're
happy
with
the
result
is
when
we
commit
to
a
full-fledged
tablet
and
the
reason
we
want
a
full-fledged
devnet
is
that
client
teams
there's
some
issues
you
just
won't
find
with
local
devnets.
B
So
we
want
to
have
the
full-fledged
one
and
you
want
Community
involvement.
You
want
client
team
involvement,
you
want
external
people
to
sync
up
with
it.
You
want
a
stable
location
where
people
who
have
who
are
building
tooling
will
be
able
to
sync
to
it
and
so
on,
and
you
want
to
also
test
sync,
which
is
a
very
big
and
important
thing
that
so
that's
the
kind
of
approach
we
took
this
time
and
that's
where
we
are
right
now
with
internet
eight
and
once
we're
happy
with
the
stability
of
the
devnets.
B
We
kind
of
promote
them
to
attack
Nets,
so
think
about
Killen
as
a
network
that
we
had
or
kinsuki
as
a
network
that
we
had.
We
had
a
bunch
of
devnets
and
then
we
had
these
public
big
test
Nets.
So
we
will
be
having
that
fancoon
as
well,
and
these
public
test
Nets
are
also
kind
of
viewed
as
attack
Nets.
B
You
unleash
whatever
you
want
on
them
and
technically
they
shouldn't
break
and
once
we're
happy
with
that
stage,
we
graduate
to
shadowfox
and
the
reason
we
graduate
to
shadowfox
is
now
you're
simulating
a
real
Network
load.
You
would
be
forking
from
mainnet
or
you
would
be
focusing
from
girly
or
from
holski,
and
this
gives
us
an
idea
on
how
much
computational
resources
are
required
for
the
new
fork,
and
we
were
also
able
to
call
contacts
that
exists
on
me
net
Etc.
B
So
it's
a
really
important
test,
Suite
that
we
have,
and
finally,
we
move
on
to
the
actual
public,
that's
not
so
early
and
finally,
we
would
announce
a
main
net
main
update.
So
this
should
give
you
kind
of
an
idea
of
where
we're
going
with
testing
itself
and
the
whole
system
is
kind
of
built
such
that
we
can
not
only
support
the
main
Fork,
but
also
a
bunch
of
feature
Forks
without
any
delay.
So
with
the
feature
Fork.
B
Usually
it
stops
at
the
devnet
level
until
it
gets
included
into
kind
of
the
next
big
ethereum
fog,
and
once
it
does
that's
when
we
start
giving
it
attack
Nets,
that's
when
we
start
doing
Shadow,
forks
and
so
on.
So
it's
this
approach
of
not
stalling
things
until
we
actually
have
to
so
that
specs
can
be
really
cleaner.
They
can
already
go
through
a
bunch
of
iterations
before
they're,
even
committed
to
run
on
mainnet.
B
So
that's
kind
of
the
approach
where
slowly
converging
on
with
this
update
and
to
give
you
an
idea
of
what
kind
of
tests
we
run.
This
is
largely
written
with
Cancun
in
mind,
but,
of
course,
will
also
apply
to
everything
else,
so
we
have
a
bunch
of
evm
changes
and
for
evm
related
changes.
We're
going
to
have
a
lot
of
fussing.
We
have
the
execution
specs
that
Mario
is
going
to
talk
about.
We
have
fussy
VM
and
we
have
fuzzy
VM
and
a
few
other
tools
also
compare
how
the
evm
outputs
look
across
clients.
B
So
you
want
to
make
sure
that
you're
getting
the
same
result
from
whichever
client
you
use.
And
Hive,
of
course,
has
created
that
and
with
the
introduction
of
blobs
with
4844,
you
have
a
bunch
of
peer-to-peer
level
changes,
so
we're
hoping
that
devnets
are
saving
ratio
that
we're
able
to
send
spam
a
bunch
of
fuzzy
blobs
that
don't
really
make
sense
and
see
if
we
can
take
down
the
network.
Ideally,
you
never
can
and
we're
trying
this
new
style
of
chaos.
B
So
we
will
be
bringing
back
sync
test
coordinator
from
our
merge
testing,
Gates
and
we'll
be
using
a
lot
of
devnets.
So
the
ideas,
the
public
devnet,
is
open
for
everyone
to
sync
and
hopefully
enough
people
think
and
try
weird
ways
of
syncing
it
to
find
ways
that
it
breaks
and
one
of
the
other
things
we
changed
this
time
around
was
rather
than
waiting
for
all
the
clients
to
be
done
with
test
Nets
and
with
shadowfox
before
we
start
mebe
testing.
We
also
started
including
relays
and
started,
including
map
boost
kind
of
earlier
on.
B
B
So
we're
kind
of
splitting
that
testing
workload
into
two
halves:
one
half
including
the
relay
workflow
one
half
just
for
the
client
teams-
and
this
means
we
should
be
able
to
accelerate
the
entire
Meb
world's
Readiness
for
the
fork,
rather
than
kind
of
waiting
for
everything
to
be
done
and
then
waiting
for
that
to
happen,
and
we
have
a
bunch
of
tooling
changes.
This
is
probably
all
under
the
hood.
From
the
perspective
of
most
people,
the
car
doesn't
really
change,
but
we
had
a
new
engine,
so
we
switched
our
ansible
playbooks
work.
B
We
switched
how
we
spin
up
all
sorts
of
tooling,
so
we
have
kubernetes
for
a
lot
of
tooling
right
now,
at
least
from
a
workflow
perspective.
It
saves
us
a
lot
of
time.
We
no
longer
have
a
lot
of
manual
steps
that
we
used
to
do
in
the
past.
We
just
have
like
one
script,
that
does
everything
and
you
can
have
a
test
net
in
even
faster
than
what
it
was
before
and
along
with
kurtosis.
B
It
also
has
kubernetes,
plugin
and
partners
is
going
to
talk
a
lot
more
about
that
one
and
our
aim
is
to
use
the
both
Hive,
as
well
as
the
kurtosis
SDK,
to
add
regression
tests
for
issues
that
we've
seen,
and
the
idea
is
that,
if,
where
clients
are
not
going
to
stop
making
releases-
and
we
want
to
make
sure
that
if
we
found
a
bug
today,
it
doesn't
show
up
again
in
a
few
months.
Typically,
this
goes
in
half.
B
We
want
to
kind
of
play
around
and
see
if
ketosis
can
also
help
out
a
little
bit
in
some
scenarios
and
yeah.
For
most
of
these
things,
we
already
support
doing
it
for
two
or
three
Forks.
At
the
same
time,
we
already
support
doing
feature
or
Fox
like
feature
eips
in
parallel.
At
the
same
time,
and
with
that,
I
will
be
handing
it
over
to
Mario
and
he's
gonna
deep
dive
into
one
aspect
of
testing
that
he's
he's
working
on.
Yes,.
D
D
So
on
to
the
next
slide,
please
yeah!
This
is
basically
the
diagram
of
how
everything
is
put
together.
So
everything
starts
with
a
python
source
file.
So
when
we
are
writing
python
source
files,
we
take
into
account
the
state
of
the
Genesis
state
of
AE
test,
and
so
here
we
Define,
for
example,
the
counts,
the
code,
everything
that
will
go
into
executing
this
EIP
upgrades
so
for
each
year
to
upgrade.
We
have,
for
example,
one
special
new
OP
code
or
word
special
new
header
field
that
we
use
on
the
upgrade.
D
So
this
definition
of
this
function
file
now
gives
us
the
power
to
create
multiple
accounts,
create
multiple
balances
in
and
each
each
single
account
is
defined
in
a
manner
that
you
can
specifically
test
what
the
aeap
is
basically
wanted
to
test.
The
the
code
is
basically
the
smart
contracts,
for
example,
on
some
of
the
eaps
when
there's
new
upcomes
the
smart
contract
of
the
these
Accounts.
D
At
the
start,
they
contain
specific
goals
that
exercises
this
this
specific
new
OP
code
or,
for
example,
if
we
have
a
new
pre-compile,
also
there's
a
smart,
a
smart
contract
that
calls
into
this
pre-compile
and
saves
its
output
into
the
state
where
we
can
later
just
verify
it
and
that's
basically,
the
entire
functionality
of
these
methods
in
Python.
The
great
thing
about
this
of
having
everything
in
Python
and
having
python
is
that
basically,
we
can
parameterize,
so
we
can
parameterize
different
types
of
calling.
For
example,
we
have,
we
have
a
pre-compile.
D
We
can
parameterize
calling
with
the
Call
Log
code,
calling
with
the
delegate,
call
log
code
and
so
on
or
doing
this
call
with
different
amounts
of
gas
or
different
amount
of
value
inside
of
the
call-
and
this
mix
is
very
easy
just
to
test
all
the
possible
combinations
that
could
potentially
have
something
in
the
implementation
that
goes
wrong.
We
can
catch
this
with
all
these
parameters.
D
Inside
of
this
same
repo,
We
have
basically
just
the
fill
the
fill
command,
which
is
basically
it
takes
the
python
method,
the
python
function,
it
evaluates
what
happens
inside
and
then
it
uses
a
set
of
tools
that
are
required
to
to
put
together
the
picture.
That
is
the
output.
That
is
the
final
test.
One
of
these
tools
that
we
used
to
call
isolated.
D
For
example,
if
we
are
using
solidity
codes
into
our
our
python
test,
we
call
the
solidity
compiler
and
we
compile
the
code,
we
put
it
into
the
smart
contract
and
then
the
entire
account
is
finalized.
Normally
we
don't
use
Solita
compiler,
because
so
you
do
support
only
happens
very
near
to
the
to
the
fork
date.
So
what
we
do-
and
this
is
a
great
addition
to
the
python
test-
is
that
we
have
like
each
op
code
has
a
definition
inside
of
our
framework.
D
So
instead
of
writing,
for
example,
byte
code
in
hexadecimal
form,
we
have
now
a
really
nice
representation
of
each
op
code
inside
this
python
file
them
files.
Another
tool
that
we
call
is
a
transition
tool
which
is
basically
a
a
tool
that
each
of
the
clients
implement.
We
mainly
use
the
glitter
implementation,
but
we
can
use
any
nimbles,
nevermind
and
empty
Zoom.
Sorry
not
no,
never
mind
but
PC.
So
what
this
does?
We
feed
this
transition
tool
with
transactions
and
blocks
and
we
get
the
output
state.
D
So,
for
example,
in
the
case
we
are
testing
a
pre-compile.
We
feed
into
the
this
position
to
reflect
the
block
that
contains
transaction
that
makes
a
call
into
the
pre-compile
and
then
the
Coit
room's
implementation
will
tell
us
okay.
This
is
the
result
of
the
storage
that
you
with
this
transaction
that
called
this
new
pre-compile
that
comes
in
in
this
new
EIP,
and
we
get
this
the
output
and
this
this
goes
into
the
into
the
full
fixture
of
the
test
yeah.
Basically,
this
this
picture
then
goes
into
half.
D
So
I
will
talk
a
little
bit
in
the
next
slide
about
that
yeah.
So
here's
the
basically
the
one-to-one
relationship
of
what
happens
in
the
patent
tests
and
how
we
feed
this
into
hype,
because
in
high
we
not
only
test
the
ebm.
We
also
test
the
engine
API,
which
is
an
important
part
in
this
engine.
Api,
is
operated
on
every
single
Fork.
D
So
far,
we
start
with
the
with
the
pre-state,
basically,
which
is
what
we
defined
previously
in
our
accounts
or
smart
contracts
or
our
balances
and
everything
we
also
Define
the
starting
Fork
of
each
step.
So,
for
example,
we
can
start
a
test
on
Shanghai
or
we
can
start
it
on
Cancun
the
same
test.
It
gets
parameterized
into
every
single
Fork
from
the
introduction
point,
and
also
we
have
some
tests
that
start
on
one
fork
and
then
proceed
to
operate
inside
in
a
few
blocks
to
the
to
the
next
work.
D
The
one
example
is
in
this
Fork:
we
have
the
blood
blood
usage
that
is
included
in
header
blocks,
so
for
that
we
use
a
test
where
we
start
on
Shanghai,
but
on
block
number
10
or
time
slap
times
on
number
five,
five
or
something
we
upgrade
to
Cancun.
So
we,
the
kind
of
test
that
we
do
with
this,
is
that
we
test
that
the
starting
parameters
of
the
new
Fork
are
correct
and
decline
the
correct
parameters,
and
so
this
is
the
setup,
and
this
is
done
on
hive.
D
Once
we
get
this
fixture,
we
get
even
high.
We
produce
the
Json
Genesis
file.
That
is
basically
the
input
to
the
to
the
client
before
starting
the
client,
because
height
starts
the
client
as
if
it
was
running
in
mainnet
basically,
and
the
engine
API
part
is
what
the
consensus
client
uses
to
communicate
to
the
client.
D
So,
for
that
we
also
have
the
different
blocks
and
the
block
properties
and
the
transactions
this
comes
in
in
our
fixture
at
our
test
fixture
and
the
way
that
height
fits
it
into
the
into
the
engine
apis
by
using
engine
and
new
payload.
Basically,
it
fits
the
entire
block
and
I
just
the
way
that
the
consensus
client
would
do
it
on
mainnet,
and
then
it
specs
an
execution
result.
D
For
example,
if
we
have
a
good
blog
work
with
where
everything
on
the
EIP
is
executed
and
is
validated,
we
expect
that
the
engine
API
returns
us
anybody
response
and
whereas
we,
when
we
also
feed
invalid
blocks
into
the
engine
API,
we
expect
that
the
client
correctly
rejects
this
block
with
an
invalidated
team,
and
this
is
something
that
happens
every
single
time.
We
get
a
block
in
maintenance.
So
this
is
the
same
behavior
that
we
are
testing
here,
as
as
it
was
running
on
mainnet.
Only.
D
Finally,
we
also
have
the
post
State
and
on
our
tests
on
our
fixtures,
contained
storage
balances
and
also,
if
any
account
was
destroyed,
for
example,
which
is
very
important
for
the
self-destruct
EIP
that
we
have
in
this
in
Cancun,
and
we
verify
all
of
that
by
using
the
atrpc.
So,
basically,
when
we
have
finished
feeding
the
block
into
the
client
and
we
set
the
head
to
that
block,
we
then
proceed
to
use
the
esrpc
to
look
at
the
balances
require
the
request:
the
storages
request,
the
code
and
Etc
yeah.
D
This
is
basically
the
flow
that
high
follows
to
test
the
EIP
upgrades,
so
yeah,
so
I
wanted
to
give
an
overview
of
the
magnitude
of
changes
that
we
are
testing
on
Cancun
for
on
the
even
specifically,
so
it's
easily
I
think
one
of
the
most
evm
crowds
that
operates
that
I've
seen
and
that
I've
tested
in
the
recent
years.
So
we
have
five
eaps
that
affect
the
the
EDM
and
all
of
them
contain
different
qualities,
different
things
that
we
need
to
test.
D
Every
single
change
in
our
of
these
eaps,
for
example,
for
we
have
the
beacon
route
in
the
header,
which
introduces
a
new
header
field.
We
have
new
pre-deployed
code,
which
is
not
a
pre-compiled,
and
so
we
are
going
to
the
Pro
Deploy
on
the
contract,
and
then
we
are
going
to
use
that
to
update
the
state
in
that
contract.
D
So
this
is
very
different
from
what
we
have
been
doing
so
far,
which
is
just
deploying
a
pre-compile
at
the
time
of
the
fork,
we're
going
to
pre-deploy
code
into
mainnet
that
we
are
going
to
test.
So
this
had
a
lot
of
repercussions
to
the
test,
because
we
for
every
single
can
test
on
the
on
height.
We
had
to
update
the
pre-state
and
take
this
readable
into
consideration
so
and
also
we
also
have
the
first
ever
system
transaction,
which
is
basically
something
that
had
never
been
done
before
in
an
upgrade.
D
This
is
at
the
start
of
the
block.
We
have
we're
going
to
have
system
transactions
that
come
from
a
special
address
and
these
are
going
to
execute
a
spatial
code
Branch
into
this
pre-deployed
code.
So
this
this
is
the
first
for
a
fork,
so
we
had
to
test
this.
Also,
these
there
are
still
there
are
going
to
be
make
made
for
this.
For
this
specific
case
and
yeah,
it's
still
it's
still
testing
in
progress.
Also,
it
changes
to
the
engine
API,
because
we
have
now
a
new
health
field.
So
we
have
to
test
all
this.
D
This
change
this.
The
inclusion
of
this
new,
this
new
field
in
all
our
tests
and
copy
is
eip5656,
is
just
n
copy
is
the
new
up
code.
So
this
is
very
similar
to
what
we
have
been
testing
in
previous
works.
It's
just
a
new
up
code
that
copies
memory
from
one
place
into
another.
A
lot
of
tests
are
also
were
made
for
this.
We
have
eaps
67a,
which
is
the
self-destruct,
now
becomes
the
central.
D
So
this
is
another
first
for
a
fork
which
basically
operates
an
OP
code
that
was
already
existing
in
menu
and
converts
its
functionality.
So
before
we
had
self-destruct
and
you
can
sell
this
work
any
contract
at
any
point
in
time,
but
now
what
this
different
behavior
is
that
we
have
self-destructing
behavior.
Only
if
the
contract
was
deployed
on
the
same
transaction,
where
it
is
self-destructing,
otherwise
it
will
be
becoming
a
send-off
which
is
basically
just
sending
all
the
it
into
another
account
without
self-destructing.
D
So
the
repercussions
is
that
we
have
to
test
multiple
calls
in
the
insane
transaction
and
see
that
the
storage
does
not
pass
on
to
the
next
transaction.
Basically
and
yeah.
The
main
event
is
4844:
I
had
to
just
do
a
whole
slide
for
this,
because
there
are
so
many
changes
in
this
EIP
and
the
amount
of
tests
also
was
very,
very
important.
For
example,
we
have
a
new
pre-compile,
which
is
the
kcg
point
evaluation.
D
We
searched
cryptographic
test
vectors
from
the
the
consensus
specs
so
now,
basically,
we
are
producing
automatically
generated
and
test
cases
for
this
pre-compile,
but
we
also
test
we
had
to
test
also
the
ebm
factor
of
it.
So,
for
example,
we
are
calling
the
pre-compile
and
with
different
inputs
with
different
call
data
from
this
different
addresses
and
there's
a
lot
of
involvement
in
the
parameterization
it
comes
with.
This
parameterization
was
very
helpful.
We
did
not
have
this
before,
so
the
execution
inspectors
proved
to
be
very
helpful
in
this.
D
In
this
specific
case,
to
generate
automatic
test
vectors,
it
was
really
simplified,
as
in
contrast
to
the
way
the
tests
were
written
before
we
also
have
on
this
same
EIP.
We
have
a
new
opcode,
which
is
the
blob
hash,
and
basically,
we
obtain
information
from
the
transaction
with
the
treatment
section,
and
we
also
embed
that
into
the
output.
We
also
have
the
new
transaction
type,
which
is
type
number
three
for
blockchain
session.
D
This
is
a
special
type
of
transaction
that
includes
the
blobs
that
the
l2s
will
use
to
for
that
availability
and
there's
an
important
distinction
in
this
transaction
type,
which
is
we
have
now
to
transaction
flavors
of
the
same
type.
So
we
have
the
network
network
flavor
and
we
have
the
the
one
that
goes
into
the
block,
so
we
had
to
test.
We
actually
found
an
issue
where
one
of
the
clients
was
embedding
the
incorrect
flavor
of
this
type
of
transaction
into
the
block
which
resulted
in
any
value
block.
D
So
there
are
a
lot
of
nuances
that
went
into
the
details
when
we
were
implementing
the
test.
For
for
this,
we
also
have
two
new
hair
Fields,
so
it
includes
the
blood
gas
usage
basically
and
the
access
gas
and
the
access
blockcast
accumulator,
and
this
is
important
because
this
also
affects
the
pricing
of
this
special
new
type
of
transaction,
and
we
have
to
make
sure
that
every
single
client
respects
this.
D
This
new
header
field
increased
and
yeah
respect
all
the
modifications
to
the
hair
field
and
yeah,
as
I
mentioned,
also
new
blob
gas
pricing
that
went
out
there.
There
was
a
lot
of
consideration
in
testing
in
the
test
cases
that
we
did
for
this.
So
basically
it's
just
a
matter
of
introducing
a
lot
of
blobs
in
one
block
and
then
seeing
that
on
the
next
block,
the
correct
guess
for
blocks
was
priced
into
the
transaction
and
also
subtracted
from
the
balances
that
were
sent
and
we're
sending
these
transactions
and
so
yeah.
D
A
lot
of
different
exotic
test
cases
were
were
written
for
this
also,
and
on
top
of
all
of
that
also
introduces
a
lot
of
engine
API
changes,
because
we
have
now
the
version
3-
and
this
has
the
versioning
hashes
inside
of
the
engine
API
endpoint.
So
there's
a
lot
of
testing.
Also
Hive
was
a
very
important
point
for
testing
this,
mainly
because
on
the
execution
factors
we
don't
have
a
way
to
reach
the
engine
API,
but
High
dos.
D
So
we
had
to
come
up
with
a
new
way
of
writing
tests
that
also
introduces
changes
or
definitions
of
the
engine
API
that
I
could
read.
So
we
can
test
some
Excel
combinations
of
this
new
changes
to
the
endpoint
and
yeah
and
just
to
for
reference.
This
is
roughly
the
number
of
evm
tests
that
we
have.
This
is
not
everything,
but
just
to
get
get
an
idea.
D
It's
also
tested
into
hide,
and
so,
if,
if
anyone
wants
to
take
a
peek
into
the
test
and
to
get
a
better
idea
of
how
we
parameterize
the
test-
and
we
have
how
we
how
we
created
this
test,
please
follow
these
links
here.
You
will
see
every
single
test
that
we
have
introduced
into
Cancun
yeah
for
for
also
PRS,
are
welcome.
Please
go
inside.
Take
a
look,
take
a
deep
dive.
If
you
see
anything
that
you
would
like
to
I,
don't
know
or
maybe
just
to
mess
with
the
test.
C
Now
I
will
begin
to
talk
about
kurtosis.
So
kurtosis
is
our
next
step
of
testing
tool.
We've
been
using
criticism
for
quite
a
while
now
and
I
will
begin
with.
Why
do
we
even
care
about
kutus?
Is
why
don't
we
just
jump
straight
to
public
test
Nets
or
a
devnet?
So
the
main
benefit
is
a
very
fast
iteration,
so
you
can
spin
up
a
devnet
in
under
five
minutes,
and
all
of
this
testing
can
be
done
on
your
local
machine.
You
don't
need
to
spin
up
any
Cloud
instance.
C
You
don't
need
someone
else's
computer
to
run
these
tests
for
you,
you
can
just
do
your
stuff.
You
can
customize
also
your
own
local
testnet.
Any
way
you
want.
You
can
have
three
second
slot
times
you
can
have
20.
Second
slot
times
you
can
run
any
image
you
want.
You
can
run
any
combination
of
the
nodes
you
want
to
run.
So
it's
very,
very
customizable
and
very
very
scalable.
Also
so
scalability
comes
thanks
to
their
support
for
kubernetes.
C
So
kubernetes
allows
you
to
scale
up
to
a
very,
very
wide
range
of
notes,
so
you
can
run
100
nodes
on
a
cluster
of
10
physical
nodes,
so
this
enables
you
to
run
larger
test.
Nets
also
run
local
test
Nets
in
a
non-persistent
way.
So
you
need
to
have
a
large
SSD,
because
all
of
these
tests
will
be
staying
on
your
machine
in
Ram
and
once
the
distance
is
shut
down,
then
all
of
the
data
will
be
just
going
away.
C
Another
benefit
is
all
the
clients
are
supported,
so
we
can
test
every
single
client
with
every
other,
client
and
interior.
It
should
all
work
and
the
configuration
for
it
is
very
basic.
You
don't
need
to
have
any
knowledge
about
any
programming
languages
or
you
need
to
know,
is
read
the
configuration
file
and
you
can
get
started
so
here's
an
example
of
a
configuration
file.
C
As
I
mentioned,
it's
a
very
basic
Json
file,
where
you
will
Define
your
El
type,
which
in
this
case
will
be
a
gaff,
a
CL
type
Lighthouse,
so
in
the
first
participant
will
be
two
counts
of
gas
and
Lighthouse
pair,
and
after
that
you
will
have
another
mind
and
a
taco
pair,
and
that
will
just
create
one
instance
and
then
the
network
parameters
you
can
Define.
When
do
you
want
to
have
a
forecast
for
capella
or
the
NAB?
And
hopefully
all
the
future
force
will
be
also
supported,
and
this
Json
file
is
very
customizable.
C
You
can
that?
What?
Whichever
client
version
you
want,
you
can
override
memory
limits.
You
can
customize
resource
use
usage
per
client,
but
this
enables
you
to
automatically
scale
up
or
down
your
kubernetes
cluster
or
just
to
limit
your
each
of
the
client
pairs
to
a
specific
specific
resource
limit
here
is
an
example
of
like
how
fast
it
takes
to
spin
up
a
network.
It's
actually
just
looping
around
it's
a
gif,
but
it
really
is
as
fast
as
you
can
see
it
there.
C
So
there's
a
different
methods
to
interact
with
the
kratosis
cluster
or
the
ketosis
engine,
and
the
most
standard
way
is
using
the
CLI,
so
just
run
a
simple
CLI
command
and
it
will
Spring
everything
up
for
you.
Another
way
is
to
write
some
tests
in
go
and
then
you
can
interact
with
Equity
assist
SDK
and
then
the
criticism
engine
will
do
the
orchestration
for
you.
So
you
don't
have
to
deal
with
how
the
pods
or
the
containers
will
be
deployed
to
your
enclaves.
C
So
enclaves
are
the
bodies
that
will
hold
all
your
services
and
that
will
communicate
with
all
the
nodes
that
you
have
created.
Here's
a
couple
of
examples
that
we
have
found
using
kratosis
in
the
S
I
would
say
three
weeks.
We
have
found
multiple
interrupt
issues
with
prism
with
Netherland
gas.
We
have
found
out
that
one
of
the
measurement
config
was
wrong
using
our
Genesis
generator.
C
C
You
would
like
to
welcome
you
if,
if
you
would
like
to
Snapper
you'll
call
that
nature
stuff,
so
the
next
step
after
running
a
local
net
on
your
machine
is
when
we're
doing
a
devnet,
where
all
the
client
teams
will
participate
and
where
they
can
deploy
their
application
or
well.
We
will
deploy
their
application
and
you
can
actually
check
the
interop.
So
we
are
currently
at
the
8th
iteration
of
Dan
quint.net
yeah.
C
So
previously
it
was
all
about
the
4844
because,
as
Mario
and
Perry
mentioned
sorry
for
for
such
a
massive
VIP
that
we
we
had
to
make
sure
that
that
we
will
work
first
before
everything
else
comes
on
board.
So
this
is
the
first
one
where
we
include
all
the
eips
that
Mario
went
into
detail
with
and
currently
everything
looks
pretty
good.
C
We
have
a
couple
of
issues
on
the
prism
and
Nimble
side
on
the
princesses
layer,
and
then
the
execution
layer
will
have
some
issues
with
basically
a
new
one
but
I'm
sure
it
will
work
out.
So
you
can
find
this
pack
list
and
the
home
page
for
government
date
on
the
links
mentioned
on
this
side.
Oh
one,
quick
mention
about
our
next
public
test
net,
so
hoski
is
coming
soon.
Our
launch
is
now
scheduled
for
the
15th
of
September
and.
C
A
That
is
awesome.
Thank
you,
buddy
for
high
level
overview
of
the
evolution
of
testing
upgrades
and
tools.
Those
are
being
used,
Mario
for
a
high
testing
on
execution
layer.
It
was
really
interesting
to
know
about
1559,
like
gas
pricing
and
type
3
block
transaction
type,
I
believe
people
who
are
not
closely
following
4844
calls.
They
may
be
interested
in
learning
more
about
what
it
is
and
how
blobs
are
handling
all
those
things.
A
Those
were
earlier
handled
by
blogs
and
I
was
like
amazed
so
see
like
over
a
thousand
evm
tests
kudos
to
your
team,
and
thank
you
one
of
us
for
explaining
cryptosis
I,
really
love
the
icon
that
you
guys
have
used
for
Cancun
the
small
tree
and
everything
giving
a
beach
look,
and
it
was
a
nice
addition.
I
would
encourage
people
here
on
the
call.
If
they
have
any
question
you
can
perhaps
add
in
the
chat.
So
we
can
invite
you
to
take
your
question
in
the
meantime.
A
I
have
a
few
questions
from
the
presentation
that
we
have
today
I'm
just
a
little
curious
about
the
testing
sequence.
We
learned
that
team
are
trying
to
launch
the
Internet
only
after
the
spec
is
passing
the
hive
test.
So
what
are
the
sequence
for
the
other
like
attack,
Nets
and
Shadow
Fork?
Are
they
work
in
parallel
or
they
are
after
devnet
and
before
public
test
net.
B
So
typically
we'd
want
to
keep
that
after
devnets
and
before
public
test
Nets,
but
there
will
be
some
overlap.
For
example,
we
tend
to
use
marius's
transaction
fuzzer,
for
example,
to
attack
a
lot
of
our
debts,
but
that
also
is
already
built
into
curtosis.
So
there
is
some
overlap.
We
don't
keep
a
strict
sequencing
but
yeah.
Ideally
we
would
move
on
to
the
attack
net
Phase
One
Step
adds
a
stable.
B
It
also
went
all
over
the
place,
I
think
the
best
way
to
think
about
it
is
anything
that
needs
High
coordination.
We
try
to
push
towards
the
end
once
we're
more
confident
anything
that
needs
low
coordination,
something
that
one
two
people's
plus
client
teams
can
get
together
and
knock
out
that
we
try
to
move
that
earlier
on.
A
That
make
a
lot
of
sense.
Another
important
thing
that
we've
noticed
here
today
was
the
engagement
of
all
eips
I.
Remember
it
was
mentioned
in
one
of
the
dev
calls
that
the
devnet
8
will
be
Peach
full
featured
internet.
That
means
it
will
include
all
the
eips
those
are
getting
into
the
Denco
upgrade,
though
the
list
of
Misses
two
of
the
EIP
7044
and
7045,
which
I
believe
are
on
the
consensus
layer
and
not
on
the
execution
side.
D
I
guess
I
guess
I
can
respond
that
I
I
think
most
of
the
consensus
aspects.
They
contain
this
test
for
that
specific
change.
So
we
didn't
go
into
detail
of
how
the
consensus
changes
are
tested,
but
the
tests
are
isolated
in
the
consensus
spec.
Basically
so
this
evm
changes
are
constrained
to
the
the
execution
specs
repo
that
we
have,
but
the
other
the
the
consensus
eips
are
normally
tested.
Suspects.
A
B
Yeah,
we
definitely
will
be
including
everything
before
I'm
sure
there'll
be
a
definite
nine
before
we
go
into
a
public
test
net.
The
question
is
just
when
we
do
the
change
from
devnet,
8.9
I.
Think
in
the
past
the
answer
was
a
bit
easier,
because
devnets
would
break
faster,
I.
Think
now
that
we've
moved
a
lot
of
testing
earlier
to
the
cycle,
we
need
more
difficult
bugs
to
breed,
so
we
still
haven't
found
our
Rhythm
there.
A
That
is
good
to
know.
I
understand
it.
Things
are
getting
complicated,
must
agree
now,
like
like
we
had
chat
with
on
every
author
of
all
the
proposal,
those
are
getting
into
the
stencil
upgrade,
but
when
I'm
looking
at
it
from
a
bird's
eye
view
and
considering
the
testing
effort
that
you
guys
are
putting
in
I
must
have
to
congratulate
you
guys,
it's
really
different
from
all
other
upgrades
that
happened
in
the
past,
so
kudos
to
the
team
here
talking
about
the
public
test
net.
B
B
Let's
try
it
out
before
we
announce
holski
and
then
two
weeks
later,
we
still
haven't
finished
testing
testing
it,
because
we
wanted
to
find
out
how
many
validators
the
beacon
chain
can
handle
and
that's
a
big
problem
in
itself
which
we
underestimated
so
now
we're
playing
kind
of
catch
up
on
Cancun
testing
and
once
we're
done
with
this,
we
would
start
planning
the
next
public
Cancun
test
net.
But
I
don't
think
we
have
anything
to
announce
today.
On
that
topic
we
would
first
want
like
the
Kiln
style
public
test
net.
B
That
would
go
along
for
roughly
a
month,
and
if
we
like
the
stability
there,
then
we
would
propose
to
Fork
holski.
First,
that's
at
least
my
personal
opinion.
I,
don't
know
if
ACD
would
agree
with
that,
because
holski
would
have
such
a
large
validator
set
that
if
that
large,
valid
data
set,
is
able
to
handle
blobs
flawlessly.
B
That
introduces
a
ton
of
confidence
but
I
know
in
the
past.
We've
done
it
the
other
way
around
as
well.
So
we
do
the
simplest
test
net
first
and
then
we
do
the
most
difficult
test
at
last.
So
let's
see
there's
also
one
extra
issue
or
point.
We
have
to
figure
out
currently
all
the
devnets
work,
with
the
assumption
that
we
have
six
three
three
blobs
and
then
six
maximum.
B
We
don't
know
if
this
is
the
value
we're
going
to
go
with
mainnet
or
not
so
we're
trying
to
do
extensive
testing.
But
the
issue
is
that
most
of
the
tests
we're
doing,
don't
really
teach
us
if
mainnet
will
be
fine
with
this
size
or
not.
So
one
potential
option
is
since
girly
has
been
deprecated
to
fork
early
first
with
three
six
see
how
girly
reacts
if
it
fails.
Well,
it's
a
deprecated
test
net
and
we
know
not
to
do
that
on
mainnet.
If
it
succeeds,
then
we
learn
a
lot
about
how
it
succeeded.
B
What
implications
the
success
had.
Did
it
reduce
blocked,
increase
blog
proposal
latencies?
Did
it
increase
the
amount
of
time
that
the
attestation
State
propagate
and
so
on,
and
we
have
a
bunch
of
visibility
tools,
peer-to-peer
visibility,
tools
right
now
that
help
us
gather
this
information,
so
it
could
be
that
girly
happens.
First.
A
So,
just
out
of
curiosity
here,
I
remember
when
I
had
a
chat
with
Terence
about
4844.
Initially,
then
we
were
in
a
position
to
have
two
and
four
like
two
gloves
per
block
and
kind
of
four,
but
later
on
when
talking
to
gajendra
Singh.
It
went
to
three
and
six
now
that
we
are
talking
about
testing
here
and
we
just
discussed
that
there
could
be
a
possibility
of
breaking
it.
So
if
it
does
break
where
are
we
going
going
back
to
2
4
or
we
are
thinking
of
something
different.
B
Like
exactly
exactly
and
I
think,
there's
also
a
stream
of
thought
where
people
suggest.
Why
don't
we
just
do
two
four
to
begin
with.
We
know
it's
kind
of
safe
and
then
upgrade
to
three
six
later
on,
but
then
the
contrast
you're
leaving
some
scalability
on
the
table
for
a
few
months,
at
least,
and
even
if
it's
a
minor
change,
we
would
have
to
test
everything
for
the
next
Fork.
So
it
will
add
some
complexity
for
testing
down
the
line.
A
D
I
I
have
to
say
that
it's
continuously
it's
it's
never
done.
We
have
to
every
time
you
you
can
think
of
a
new
new
scenario
near
Edge
case.
It
comes
a
new
test,
and
so
we
are
trying
to
do
the
the
best
way
that
we
can
to
fully
test
the
spec
and
then
would
we
continue.
Adding
tests
daily,
I
think
one
of
the
main
difference,
I
think
is
going
that's
going
to
happen
between
now
and
the
actual
maintenance
is
well.
Two
things
is
the
the
4788
contains
a
the
pre-deployed.
D
That's
gonna
have
to
be
updated
because
we
are
going
to
deploy
bytecode
into
the
into
my
net.
So
there's
is
going
to
be
an
audit
on
that
and
that
by
code,
so
that's
probably
going
to
change,
and
so
when
that
changes
we
have
to
update
the
test.
But
this
is
now
really
easy,
because
the
python
test
makes
everything
so
parameterizable.
So
we
see
it's
not
a
big
deal.
The
other
thing
that's
probably
going
to
impact.
Also
the
tests
from
the
difference
between
now
and
a
minute
is
the
thrusted
setup
for
4844.
D
We
now
have
like
this
not
secure
version
in
the
test
Nets,
but
on
on
mainnet
we
are
preparing
the
the
ceremony
that
will
contain
the
final
trusted
setup.
So
that's
going
to
be
another
very
important
change
that
we
are
going
to
have
to
re
refill
all
the
tests
and
redeploy
and
recheck
with
every
client
that
everything
followed.
This
new
version
of
the
tests.
B
So
we
kind
of
have
the
exact
same
problem
on
the
test
net
testing
world
as
well.
Our
solution
was
also
pretty
similar,
so
we
have
this
fancy
big
Docker
container
tool
that
shoves
every
tool
into
one
nice
to
use
script.
It's
just
called
ethereum
Genesis
generator,
and
then
we
added
the
byte
code
there,
as
well
as
the
trusted
setup
file
at
that
level.
So,
even
from
our
perspective,
changing
it
is
changing
it
out
in
the
root
tool
and
then
making
a
release
and
then
everything
that
in
everything
else
will
just
inherit
it
from
there.
D
Yeah
we're
definitely
in
a
much
better
spot
and
testing
wise
everywhere.
We
are
making
everything
more
modular,
more
automated,
more
parameterizable,
more
and
very
easy
with
the
spec
changes
with
the
last
month,
or
so
there
were
a
lot
of
spec
changes
that
affected,
basically
all
the
tests
and
if
we
didn't
have,
for
example,
the
execution
spec
test
the
python
test,
it
would
have
been
a
much
bigger
effort.
I
mean
we
could
talk
about
several
weeks
after
just
trying
to
modify
everything.
C
Spicy
take
you
could
possibly
remove
some
of
the
client
teams
and
then
we
wouldn't
check
for
interrupt,
but
then
we
remove
client
diversity.
So
you
either
you
insulin,
you
lose
some.
So
if
you
want
client
diversity,
then
it
will
take
a
lot
of
interrupt
and
lots
of
time
to
move
forward
if
we
would
have
a
single
El
and
a
single
CL
I
think
all
of
these
tests
would
become
fraction
of
the
timing
and
we
wouldn't
have
nowhere
near
as
much
problems
as
we
face
right
now.
Also.
B
B
It's
mostly
going
to
work
and
a
lot
of
clients
would
already
have
like
a
reference
implementation
and
look
at
make
it
more
featureful.
So
maybe
that
stuff
all
helps
I
can
tell
you
for
one.
We
haven't
slowed
down
any
sort
of
testing
on
vocal
For
example.
We
as
far
as
I
know
the
eof
guys
are
coming
up
with
a
specification.
B
C
One
more
comment
on
this
is
criticism
is
able
to
help
us
test
things.
So
in
an
ideal
world,
where
criticism
is
fully
flashed,
we're
going
to
be
able
to
write
for
the
flash
tests
and
go
let's
say
put
it
in
a
CI
and
every
client
could
run
it
on
every
PR.
Let's
say
that
CI
job
and
it
would
be
able
to
test
latest
PRS
for
each
client
with
the
latest
of
every
other
Branch.
D
Yeah
and
from
the
effects,
specs
aspectives
I
think
one
of
the
most
yeah
the
the
time
consuming
task
is
updating
all
the
tools
that
we
use
to
generate
and
to
run
tests.
So
what
I
personally
want
to
see
of
us
focusing
on
the
on
the
on
the
future
Forks,
is
that
we
don't
depend
as
much
on
this
external
tools
and
we
are
more
coupled
with
the
spec
specifications.
For
example,
I
have
the
execution
apis
and
every
every
time
that
we
have
a
new
direct
directive
or
endpoint
in
the
engine
API.
D
We
have
to
upgrade
several
tools
or
wait
until,
for
example,
goiter
implements
the
changes
into
the
engine
API.
What
I
would
personally
want
to
focus
on
is
just
skipping
that
part
and
just
going
there
to
and
pull
all
the
changes
from
the
specs
repository
and
making
everything
more
more
yeah.
A
shorter
length
of
of
deployment
of
the
of
this
I
would
say.
B
B
A
I
hope
it
does
all
right.
I
really
remember
about
the
era
when
we
were
thinking
of
having
a
schedule
of
network
upgrade,
it
was
blocked
mostly
because
we
were
having
issues
with
testing
and
now
that
upgrades
are
being
tested
in
parallel.
We
are
getting
ready
for,
like
future
feature,
upgrade
I
think
it's
going
going
to
make
it
faster.
We
can
see
perhaps
two
or
more
than
two
upgrades
in
a
year.
So
that's
great.
A
My
next
question
is
about
participation
on
the
taskner
term,
I
understand
even
with
harlinsky
and
for
any
of
the
public
test
net
you
may
be
looking
for
validators
to
join
in.
There
could
be
a
set
of
pre-validated
validators
who
would
be
joining
the
network
for
testing,
but
I'm
curious
to
learn
about
solo
validators.
Do
we
have
thoughts
about
them
and
if
there
would
be
any
kind
of
documentation
made
available
available
for
them
to
participate
in
the
network.
B
Yeah
definitely
so
we
right
now
with
the
Genesis
State
I,
don't
think
we
have
any
individual
validators
on
that.
We
have
individuals
who
are
running
many
validators,
but
the
main
reason
for
that
is
with
1.4
million
validators
1.4
million
and
one
validator
is
not
changing
anything,
but
it
adds
a
ton
of
coordination
effort
on
our
side.
B
A
That
is
great
to
know.
I
have
recently
had
conversation
with
a
couple
of
staking
projects
those
are
coming
up
and
at
present
they
are
testing
their
project
on
garlic
test
net.
How
far
in
future,
do
we
see
Godly
around?
Is
there
a
recommendation
or
maybe
a
switch
instruction
from
Godly
to
any
other
testnet?
That
is
going
to
be
supported
for
a
longer
term
by
the
devops
and
testing
team.
B
B
As
far
as
I
can
tell
probably
dancoon
is
going
to
be
the
last
upgrade
girl
you
will
get
and
then
afterwards,
if
people
want
to
exit
their
validators
they're
free
to.
If
someone
wants
to
continue
validating
on
girly
they're
free
too,
if
someone
wants
to
coordinate
upgrades
on
girly,
it's
up
to
them,
it
just
won't
be
an
officially
supported
test
net.
A
D
Said
I'd
say
that
they're
they're
having
more
spec
changes
recently
than
in
any
other
Fork
from
personally.
For
me,
that
was
one
of
the,
because
you
have
to
not
only
understand
the
changes.
You
have
to
also
prepare
the
the
changes
to
the
test
and
also
deploy
the
test
and
also
run
them
again
all
together,
but
I
would
say
it
was
not
as
bad
because
we
were
not
preparing
this
time,
but
yeah
if
I
have
to
I
have
to
say
something
probably
probably
would
be
that.
But
it's
it's
not.
It
was
not
a
big
deal.
B
B
C
A
B
And
we
got
some
great
feedback
from
client
teams
that
they
appreciate
having
the
sheet,
but
they
can
just
reference.
Okay,
do
I,
need
this
EIP
in
or
do
I
need
this
commit
to
join
this
test
net
or
not,
and
that
drastically
reduces
the
number
of
oh
I
just
had
the
wrong
version
deployed,
and
we
just
wasted
some
time
deploying
the
test
net.
A
B
A
B
Think,
that's
always
the
hard
question.
I
think
my
answer
is
going
to
be
end
of
the
year
or
beginning
of
next
year
is
a
very
realistic
option
honestly
depends
on
what
we
find,
but
for
now
testing
is
I'm,
actually
very
impressed
with
how
stable
internet
it
has
been.
It's
been
live
for
over
a
week
and
I
kind
of
forgot.
It's
been
live
already,
which
is
great
news
for
a
devnet,
because
we
have
alerts
turned
on
and
if
it's
broken,
then
we
get
alerted
so
we're
moving
in
a
good
direction.
At
least.
A
B
Thank
you,
yeah
come
check
out
ketosis
come
check
out
Hive
execution
tests.
We
all
welcome
PR's
everywhere
we're
happy
to
onboard
you
on
the
testing
stack
if
you're,
truly
interested
and
please
take
part
in
holds
key,
keep
an
eye
out.
My
creative
validators
from
ugadi
tokolski
yeah
just
get
involved
and
we
need
a
new
name
for
the
test
net.
So
Reach
Out.
A
That
is
cool
very
well
buddy.
Thank
you
for
joining
us
on
people
eat
and
talking
about
then
contesting
updates.
We
look
forward
to
seeing
tested
proposals
on
the
main
net
with
jankun,
perhaps
by
the
end
of
this
year,
and
on
this
note,
thank
you
to
all
our
YouTube
viewers
for
watching
and
podcasts
subscriber
to
listen
to
this
special
episode.
Should
you
have
any
question
on
this
or
any
other
topic?
A
Let
us
know
check
out
the
description
for
more
information
for
links
to
other
proposals
that
we
have
discussed
in
this
series,
which
are
getting
into
Duncan,
upgrade
we'll
be
back
with
another
interesting
talk
until
next
time.
Keep
watching
keep
listening
and
keep
sharing
your
love
with
ethereum
caterers
cheers
foreign.