►
Description
Topics covered
-------------------------
01:21 - Guest Introduction(Mario Vega)
02:00 - Guest Introduction(Pari)
02:59 - Mario Vega's Presentation
03:21 - What EIPs are included in Shapella?
05:42 - What are the Key Changes?
11:56 - What has been challenging to test?
15:03 - What tools are we using to test Shapella?
17:25 - Spec tests
18:46 - Hive Tests
20:31 - Pari's Presentation
20:31 - What changes were needed to support the testing?
22:31 - Kurtosis Tests
24:10 - Shadow Forks & Testnets
26:20 - What uses what?
29:57 - How did testing happen for Shapella?
32:24 - New-ish tools you can re-use
35:04 - Timeline Flowchart
38:46 - How can i help #TestingTheWithdrurge?
40:52 - What is the Plan to simulate the test to have overall upgrade process?
41:53 - What is the Key Feature and What about the client performing there?
45:18 - Thoughts on Substantial discussion on withdrawal commitment to better support light client
47:36 - fork version
52:25 - Talk on define Payload Request
53:45 - Is Changes Effect Timeline
55:09 - Talks on Interop sessions
58:19 - to Ethereum Community
Resources:
-----------------
Slides - https://docs.google.com/presentation/d/1w9gKvFiPDrOMZawnmM6aTWYItpvpxBIrISRmZHJi4Sg/edit?usp=drivesdk
PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Questions for Guests - https://docs.google.com/forms/d/e/1FAIpQLSdsmujnH_ncIlSEJ23s9jzXAKwfpTGNeJqjREWPloBbkJVQTA/viewform
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow at Twitter
Parithosh Jayanthi | Mario Vega | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/
A
A
Today
we
will
learn
about
the
progress
made
on
Shanghai
and
capella
test
net
tooling,
and
roadmap
Shanghai
and
kapela,
together
known
as
shapila,
is
the
next
planned
ethereum
upgrade
to
provide
an
overview
on
the
topic
we
are
joined
by
testing
team,
Legends,
parito,
Shanti
and
Mario
Vega.
Welcome
to
the
show,
Perry
and
Mario.
A
C
Yeah,
of
course,
so
yeah,
my
name
is
Mario
I'm
from
I'm
a
computer
programmer
from
Mexico,
currently
I'm
working
as
a
test
engineer
for
the
different
foundation,
and
my
main
job
is
to
yeah
basically
test
all
the
common
upgrades
for
ethereum
I,
think
working
for
the
foundation
for
the
past
year
and
a
half
so
I
participated
on
the
merch
testing.
Quite
a
lot
and
yeah
we're
following
up
with
testing
for
Shanghai
and
the
all
the
upcoming
the
different
upgrades
awesome.
B
Hey
I'm
paitosh
I'm,
a
devops
engineer
at
the
ethereum
foundation
and
I
joined
something
like
two
years
ago.
At
this
point,
I
used
to
work
in
the
devops
field
at
a
different
blockchain
company
and
one
day,
I
kind
of
saw
a
tweet
that
Justin
was
hiring
for
a
new
team,
so
keep
up
on
Twitter
I
think
it
helps
so
I
just
emailed
him
about
the
position
and
interviewed
and
two
years
later,
I'm
here,
I
mainly
help
with
setting
up
test
Nets
and
coordinating
between
client
teams,
for
whatever
needs
to
happen
for
the
next
vlog.
A
C
So
yeah
our
names
are
Mario
and
party,
so
we
are
going
to
present
a
little
bit
about
how
they
Shanghai
kabella.
Efforts
for
testing
are
going
at
the
moment,
mainly
on
desk
Nets
and
devnets,
and
and
all
other
testing
Frameworks
that
we
have
so
yeah
I.
Think
the
first
thing
that
we
are
going
to
cover
is
What
enhancements
and
operates,
are
included
in
this
new
new
upgrade
and
there
are.
C
C
So
it
will
be
cheaper
for
them
to
do
transactions
in
in
in
in
in
in
their
same
block
and
to
push
the
same
instruction
with
some
isana
is
basically
an
enhancement
to
make
a
cheaper
stack
operations
in
the
in
the
in
the
evm.
And
basically
this
is
an
operation
that
happens
a
lot
with
the
number
zero
a
lot.
C
So
the
push
the
instruction
is
just
something
that
has
been
missing
from
the
evm
for
for
a
long
time,
and
now
it's
going
to
be
included
and
The
Limited
meter
in
it,
a
code
is
basically
just
limiting
how
big
the
init
code
or
the
initialization
code
for
the
smart
contracts
it
can
be,
and
we-
and
we
have
also
upgrades
to
the
consensus
layer
and
somewhere
somewhere
in
between
the
most
important
one,
is
the
second
withdrawals.
This
is
an
upgrade
to
both
the
Bitcoin
chain
and
the
execution
layer.
C
So,
basically,
this
is
an
outbreak
of
interaction.
We
are
finally
going
to
have
withdrawals
from
the
of
the
balances
of
the
exceeding
balances
or
for
full
balances
from
the
Bitcoin
chain
into
the
execution
layer
and
I.
I
will
talk
more
about
this
a
little
bit
after
and
also
there's
an
important
upgrade
to
the
beacon
chain,
which
is
the
BLS
execution
withdrawal
professional
base,
which
is
a
necessary
update
to
be
able
to
tell
from
the
beacon
chain
to
the
execution
layer.
C
It's
basically
just
moving,
either
from
the
beginning
to
exhibition
layer
where
it
can
be
moved
spent
or
do
whatever
the
evaluators
wants.
What
to
do
it.
So
the
two
kinds
are:
we
are
full
withdrawals
and
bicycle
withdrawals.
They,
the
the
partial
controls,
are
basically
something
that
will
happen
automatically
for
the
validators.
C
So
if
you
have
been
validating
for
for
for
whatever
amount
of
time,
you
have
been
online
at
testing
participating
in
the
same
committee
and
proposing
blocks,
you
potentially
have
a
a
positive
balance
in
your
account
in
your
invalidor
account.
So
with
the
partial
withdrawals.
What
will
happen
is
that
the
excess
amount
over
the
32e
that
you
have
will
be
automatically
pushed
for
you
into
the
execution
layer.
So
that
excess,
which
is
not
being
used
right
now,
can
now
be
used
and
yeah
yeah.
C
It
can
be
spent
in
whatever
form
you
want
you
can.
You
can
actually
interact
Now
using
that
that
access
balance
or
it
may
be
even
submit
a
new
validator
if
you
have
enough
partial
layouts
and
also
the
full
withdrawals,
which
is
basically
the
operation
of
removing
the
entire
balance
from
your
validator,
are
into
the
execution
layer
chain
and
the
entirety
to
it.
Plus
the
access
will
be
available
for
the
validators
have
that
have
already
stopped
validating.
C
The
validator
can
tell
the
location
the
address
of
the
execution
account
where
the
balance
should
end
up
in,
and
this
can
be
either
an
externally
owned
account
just
like
a
wallet
or
a
preferably
a
hardwood
wallet
or
a
code
search
wallet
or
it
can
be
a
smart
contract,
whatever
whatever
needs
their
balance
to
end
up.
This
is
this
is
the
way
that
is
going
to
happen.
C
Another
another
important
part
of
this
work
is
that
we
historically,
the
the
forks
have
been
triggered
on
this
tissue
layer
by
block
height
or,
for
example,
on
London
and
Breyer.
We
had
a,
for
example,
a
l
block,
one
million
the
this,
the
execution
layer
will
operate
to
this
new
consensus
mechanism
or
whatever,
and
also
on
the
merge.
We
had
another
different
kind
of
operator
which
is
which
was
on
like
total
difficulty,
and
this
was
done
because
of
security
reasons
and
yeah.
It
was
it
was.
C
These
were
the
only
two
operate
mechanisms,
but
now
we
have
there
one,
which
is
by
time,
because
the
Big
Chain
always
knows
what
the
time
is.
Now
we
can
use
this
information
on
the
execution
layer
to
also
operate,
and
this
is
particularly
important
because
on
this
specific
operator
is
the
first
time
that
we
have
to
upgrade
at
the
very
same
time,
starting
from
from
Shanghai
and
capella.
C
We
have
to
have
a
coordination
between
the
Bitcoin
clients
and
the
execution
clients,
because,
if
the,
if
the
bigger
chain
upgrades
but
not
the
execution
layer,
it
is
possible,
it
would
be
possible
to,
for
example,
they
can
change
to
tell
the
execution
layer
to
withdraw
something,
but
the
if
the
execution
chain
has
not
updated.
It
will
not
know
what
to
do
so.
It's
very
important
to
keep
this
upgrade
in
sync,
and
this
is
something
that
has
to
be
tested,
also
very
truly
another
other
changes
on
the
execution
layer.
C
C
You
could
not
sync
the
the
execute
layer,
clients,
if
you
don't
know
what
the
balances,
how
the
balances
were
accrued
on
on
these
withdrawals-
and
this
is
also
important,
because
you
can
also
prove
that
that
I
withdraw
a
certain
withdrawal
happen
and
you
can
prove
it
inside
as
more
a
smart
contract
by
having
the
block
header,
hash
and
all
that
sort
of
stuff.
So
it's
very
important
to
have
this
information
also
and
also
yeah.
C
As
I
already
mentioned,
the
Smart
Control
installation
code
is
now
limited,
which
is
separate
requisite
for
the
eof,
which
is
an
upcoming
work,
so
yeah.
There
are
a
lot
of
change
challenges
to
test
on
this
upgrade,
and
one
of
the
most
important
challenges
to
test
is
that
the
withdrawals
are
only
initiated
from
the
beacon
chain.
This
information
that
only
retention
has
because
they
have
the
state
of
the
validator.
They
know
all
the
information
about
balances.
C
So
it's
it's
very
important
for
this
to
be
initiated
from
the
beginning
and
translate
it
into
the
execution
chain.
The
way
that
is
this
is
done
is
to
is
via
the
engine
API,
which
was
truly
tested
for
the
marsh,
but
now
it
will
include
also
the
information
of
the
withdrawals.
So
this
is
something
that
needs
to
be
tested
very
easily
and
all
the
interactions
and
but
the
engine
API
itself
needs
to
be
tested,
and
we
are
using
various
different
metal
values
to
to
test
this
using
Hive
using
the
devnet
and
yeah.
C
C
This
requires
a
lot
of
inter
interoperability
testing,
also
because
you
need
you
need
to
test
that
the
beacon
chain
fully
activates
the
the
fork
and
also
the
execution
client,
which
is
a
complicated
things
test.
But
for
this
we
used
also
Hive
Wheels
and
all
kinds
of
different
tests
for
for
this
to
be
to
be
able
to
test
this
correctly
and
also
the
the
test,
the
state
test,
because
we
also
have
evm,
operates
into
the
into
this
into
this
work
so
yeah.
C
We
we
had
to
operate
the
weight
of
the
the
tools.
The
tool
chain
works
for
the
state
desk,
because
we
now
have
a
new
field
on
the
Block
header.
This
is
something
that
had
to
be
tested
and
also
implemented
on
all
the
tools
and
all
the
testing,
the
Frameworks
that
we
have,
and
another
thing
is
the
complicated
we
are
destinars
that
can
happen
rears
on
the
Bitcoin
chain
are
something
that
is
very,
very
unlikely.
It's
very,
very
it's
something
that
almost
never
happens,
but
still.
C
We
also
have
all
decline,
combinations
to
be
tested
on
devnets,
on
testnets
and
on
hive,
and
this
is
something
that
was
a
very
challenging
and
was
challenging
on
the
emergency
challenges
today,
because
yeah,
those
combination
needs
to
be
need
to
be
properly
tested.
The
tools
that
we
are
using
are
a
wide
range
of
tools.
For
example,
we
have
the
local
interrupt
devnets.
This
is
something
that
also
we
have
for
the
for
the
margin
we
are
reproducing
now
and
it's
very
important,
because
these
are
the
first
steps.
C
C
We
are
also
reusing
it
now
and
to
test
literally
about
apparatus
will
explain
a
little
bit
more
about
that,
and
height
is
one
of
the
two
tools
that
has
been
very
important
to
test
in
the
merge
and
right
now
also,
and
we
we
have
a
different
Suites
of
tests,
either
for
only
the
execution
clients
or
for
the
interoperability
between
the
execution,
clients
and
the
consensus.
Clients,
which
is
very
important
and
I,
will
talk
a
little
bit
more
about
how
in
a
bit
and
also
these
factors
yeah.
C
This
is
something
that's
that's
that
we
already
have
in
in
place
for
the
consistent
specters.
These
are
consensus,
layer,
client
only
tests,
and
these
are
really
really
special,
because
they
are
generated
using
a
python
framework
that
the
consensus
layer,
clients
have
and
I
will
talk
a
little
bit
more
about
this
in
a
bit.
We
also
have
the
the
original
status,
which
is
the
entire
set
of
tests
that
are
used
to
test
the
consensus
between
the
execution
clients.
C
The
status
is
a
very
big
set
of
tests
and
we
keep
adding
tests
this.
We
have
added
test
for
withdrawals
and
for
all
the
Apes
evm
enhancements
that
are
included
into
this
work.
We
also
have
added
a
bunch
of
tests
on
the
on
the
status.
We
also
have
a
new
kind
of
execution
inspectors
which
is
basically
similar
to
status,
but
it's
now
python
based-
and
it's
like
the
next
iteration-
that
we
want
to
also
include
into
our
tool
set
of
tests
and
yeah.
C
Eventually,
public
business
will
will
happen
we'll
upgrade
before
we
have
the
maintenance
upgrade,
which
is
very
important
for
us
to
test
stability
and
all
that
so
yeah.
With
respect
this,
we
have
two
flavors,
as
I
already
mentioned.
Basically,
the
the
the
consensus
factors
is
is
a
very
special
set
of
tests
because
for
the
consensus
layer
we
have,
the
entire
spec
is
original
in
Python.
C
So
this
allows
the
consensus
test
to
be
written
alongside
within
the
implementation
of
the
of
the
consensus
algorithm
in
general,
so
we
have
every
fork
in
there.
We
have
a
a
long
set
of
tests
for
for
the
consensus
kinds
which
are
automatically
generated
for
for
the
for
the
consensus
clients,
and
these
are
basically
just
files.
There
are
outputs
to
this
Python
scripts
and
these
are
consumed
by
the
Constitutional
kinds,
and
this
helps
to
test
that
the
the
client
has
implemented
the
spec
correctly.
C
They
are
able
to
generate
test
pictures
that
are
that
can
also
be
consumed
by
all
execution
clients
to
make
sure
that
the
that
the
their
implementation
is
correct
and
yeah
and
I'm
gonna
talk
a
little
bit
of
high
test
height
is
basically
a
this
interoperability
tool
that
is
used
to
test
and
testing
between
multiple
clients.
At
the
same
time,
so
there
are
a
lot
of
advantages
to
this.
Hi,
basically,
is
a
definite
that
is
very,
very
short-lived,
but
also
on
top
of
being
very
shortly,
it's
very
deterministic
on
what
it
does.
C
It
does
have
a
very
specific
set
of
steps
to
reproduce,
not
only
the
happy
pad
test
cases,
but
also
very
bad
scenarios,
so
we
have
a
range
of
tests.
For
example,
we
have
a
simple
Chapel
upgrade
in
this
in
life,
where
everything
happens
correctly
and
everything
goes
well,
but
we
also
have
a
reorg
tests.
For
example,
if
we
we
can
produce
a
specific
steps
to
produce
a
real
or
exactly
happening
at
the
time
of
the
fork.
C
So
this
is
very
important
and
because
it
helps
to
make
reproducible
scenarios
that
the
kind
developers
can
use
to
not
not
only
find
the
box
but
also
test
the
fixes
to
this
box
that
we
find.
So
this
is
very,
very
important
and
it's
kind
of
different
from
testness,
but
it's
also
very,
very
important
to
have
to
have
this
and
I
I
I
have
posted
the
link
here.
B
B
We
wanted
to
be
able
to
start
all
the
clients
such
that
the
merge
was
already
done,
and
the
main
reason
for
this
is
that
the
TTD
merge
transition
tests
are
extremely
hard
to
coordinate,
because
you
don't
know
how
much
difficulty
is
done.
There's
you
have
to
set
up
like
a
proof
of
work
chain.
You
have
to
set
up
a
proof
of
stake
chain.
You
have
to
merge
it,
and
all
of
this
has
to
happen
before
you
can
even
actually
start
your
tests,
which
at
some
point
just
becomes
too
tedious.
B
B
So
we
had
this
nice
trick
earlier
that
we
used
for
shadow
Fox,
which
was
when
the
consensus
engine
was
changing
from
proof
of
work
to
proof
of
stake.
We
were
kind
of
changing
it
into
our
own
Beacon
chain,
rather
than
the
main
Beacon
chain.
So
that's
how
we
achieved
Shadow
Fox,
but
the
problem
now
is
that
the
merge
has
happened.
There's
no
transition
anymore.
So
we
couldn't
do
this
switch.
B
B
So
there's
another
testing
Suite
that
we
hadn't
spoken
about
earlier.
It's
called
kurtosis
kurtosis
is
sort
of
like
local
test.
That's
that
anyone
can
run.
You
provide
a
Json
config
that
says:
I
want
client
ABC
paired
with
each
other.
I
want
four
of
them
with
these
Genesis
parameters
and
then
ketosis
will
just
make
it
happen.
The
idea
is
that
it
only
asserts
the
happy
case,
so
we
just
use
it
to
make
sure
that
interop
works.
B
The
nice
new
thing
is
ketosis
now
has
a
goal
library,
so
we
could
also
write
code
tests
with
it,
so
you
can
use
it
as
just
a
go
test
that
spins
up
a
test
net.
In
the
background,
you
can
deploy
your
contracts
in
it
and
if
that
you
can
assert
a
certain
condition
such
as
did
my
contract
break
the
network
after
X
blocks
and
if
it
fails,
then
you
just
get
a
failure
on
your
code
test.
B
B
However,
you
would
like
so
we're
trying
to
do
it
with
vocal
test
Nets
with
for
844
with
withdrawals,
so
you
have
different
test
Suites
and
all
of
them
rely
on
like
the
same
core
process
package
to
start
the
test
net
and
run
it
through,
hopefully
in
like
the
next
month
or
so.
This
starts
getting
more
Limelight
and
more
usage
and
the
big
one
was
the
shadow
Fox.
B
So
now
that
we
already
have
a
merge
chain,
we
have
to
figure
out
how
to
kind
of
fork
that
much
chain
into
our
side
chain,
so
to
say
so.
The
strategy
we
kind
of
settle
down
is
spin
up
a
bunch
of.
In
this
example,
girly
notes
wait
until
all
the
curly
notes
are
at
the
same
head,
then
we
we
turn
off
the
girly
beaconode
and
because
the
beacono
doesn't
exist
on
the
on
our
subset
of
nodes,
it
stalls
our
chain
they're,
all
at
the
same
head.
They
just
can't
progress.
B
B
B
Most
of
the
tooling
has
also
been
updated
and
I'll
actually
show
you
what
tooling
we
used
and
how
we've
kind
of
organized
things
to
make
it
a
bit
easier
in
the
future
for
for
reuse,
so
to
say
and
yeah
we're
going
to
be
continuing
to
do
a
lot
more
Shadow
folks,
over
the
next
couple
of
weeks,
there's
a
main
net
Shadow
for
planned
for
next
week.
I'll
show
you
the
timeline
before
Chapel
hits
me
in
that
later
on,
so
what
users
watch?
B
This
was
also
a
bit
of
restructuring
that
we
had
to
do
over
the
last
couple
of
months
and
we're
trying
to
follow
this
General
pattern.
So
on
the
top
layer,
you
have
base
CLI
tools.
They
just
do
one
thing:
they
do
one
thing
really
well:
for
example,
each
two
valve
tools
generates
keys,
so
test
match.
Genesis,
you
give
it
configs,
it
generates
a
beacon
chain.
Genesis
State
cclr
can
parse
the
Genesis
State.
B
So
one
example
is
we
maintain
the
ethereum
Genesis
generator,
which
just
has
some
Python
scripts
to
create
El
Genesis
files,
it
Imports
all
the
above
mentioned,
base
layer
tools
to
generate
CL,
Genesis
files
and
then
there's
just
a
bunch
of
bash
scripts
to
parse.
What
you
want.
That's
pretty
much.
It
doesn't
do
anything
else.
You
can
start
this
as
a
Docker
container.
It
opens
a
web
port
in
case
you
want
to
fetch
it
over
the
network.
B
Otherwise
it
writes
the
file
with
a
volume
Mount,
it's
a
real,
easily
generic
and
can't
really
go
wrong
with
it.
We're
using
this
with
ketosis
tests,
which
I
mentioned
earlier,
was
also
a
wrapper
for
I
want
to
test
night
with
this
config.
Can
you
make
it
happen
and
the
same
way
we
have
ethereum
Helen
charts,
which
is
I,
have
a
kubernetes
cluster
and
I
want
these
nodes?
Can
you
start
it
for
me?
B
So
we
have
these
two
wrapper
layers
sort
of,
and
then
the
next
layer
is
the
external
reuse
layer
so
to
say
or
a
deployment
layer,
and
this
includes
consensus
deployment
ansible.
That
is
a
base
level.
Ansible
Playbook
system
role
system
that
just
tells
you
I
want
a
test
net.
Can
you
set
it
up
and
then
based
on
how
you
configure
the
variables
you
get
specific
test
Nets?
So
what
we've
done
for
for
testing
is
we
have
this
base
thing
and
we
just
Fork
it.
We
forked
it
once
for
the
merge
test
match.
B
We've
opted
for
withdrawal
test,
Nets
virtual
test,
Nets
4844
for
Shandong,
all
of
them
reuse
the
same
base,
ansible
playbooks
and
we're
trying
on
a
future
upgrade
to
make
it
even
more
modular
so
by
taking
the
whole
concept
of
ethereum
nodes
out
of
ansible
and
making
its
own
collection.
So
you
can
reuse
it
as
you
want
we're
just
trying
to
make
it
another
Apple.
B
So
this
is
kind
of
the
overview
how
we're
going
for
every
time.
For
example,
if
I
take
a
the
example
of
the
next
update,
so
I
forget
the
name,
but
it
starts
with
the
D.
Let's
just
call
the
next
ethereum
update,
so
it
kind
of
start
off
at
the
base
layer
we'd
make
sure
that
the
Genesis
configs
there
can
be
updated.
B
Then
we'd
update
the
wrapper.
So
that's
whatever
wrapper
values.
You
have
work,
read
Fork
the
consensus
deployment
ansible
again,
so
you
have,
for
example,
for
it
for
four
test
net
repo
and
that
four
eight
four
four
test
net
repo
would
have
configs
for
specific
test.
Nets
that
we're
doing
so.
When
there's
like
two
three
steps,
you
kind
of
have
this
reusability
as
well
as
upgradability,
and
you
can
keep
up
with
every
test
net
in
the
future
without
having
to
you
know,
start
from
the
scratch
and
have
to
rework
everything.
B
And
how
did
testing
happen
for
chappella
with
a
lot
of
effort,
because
what
Chapala
was
wasn't
really
clear
until
like
a
couple
weeks
ago?
So
it
is
very
hard
to
test
something
when
you
don't
know
what
you're
testing
and
the
what
you're
testing
has
changing
specs
in
changing
client
teams
and
changing
requirements.
B
It's
a
lot
of
moving
pieces.
So
the
way
we
kind
of
did
this
was
with
a
lot
of
help
and
with
a
lot
of
parallelization.
So
the
eof
test
nets,
for
example,
Shandong
and
all
of
its
iterations,
were
purely
handled
by
the
ethereum.js
team
and
G11
Tech
amazing
job
there.
They
were
doing
all
the
Outreach.
They
were
doing
the
setup
they
basically
Fork
the
consensus
deployment,
ansible
I
helped
them
with
the
initial
setup,
and
then
they
just
ran
with
it.
B
The
4844
test
stats
have
been
taken
care
of
by
the
guys
from
consensus,
slash
optimism
and
their
devops
teams
done
a
phenomenal
job
with
making
sure
I
think
we've
had
three
death
pads
so
far
and
we're
slowly
starting
to
help
with
perhaps
the
fourth
devnet
or
with
some
interrupt.net.
So
we
can
also
start
getting
our
hands
dirty
for
the
next
work
and
Barnabas
from
the
devops
team
was
working
a
lot
on
the
withdrawals
test
Nets.
B
So
we
kind
of
kept
these
parallel
test
net
tracks
that
just
enabled
one
specific
feature,
and
then
once
we
decided
what
was
going
to
chappella,
we
collapsed
them
into
one
test
net
and
that's
I
think
how
we
would
also
proceed
in
the
future.
Just
have
parallel
test
Nets
with
one
specific
feature
and
then
once
there's
more
clarity
from
all
core
devs
or
whatever
decision
making
process.
Then
we
would
just
collapse
them
into
one
testing
track
to
hit
me
net.
B
I
would
like
to
think
that
some
of
the
results
of
the
testing
went
into
framing
what
goes
into
shupala
I
I
think
some
of
it
does
for
sure.
But
you
can
never
tell
fuzzing
found
a
lot
of
bugs
between
different
client,
implementations
and
or
spec
changes.
A
huge
shout
out
to
Marius.
We
extensively
use
his
TX
first
tool
that
he
keeps
updated
for
every
Fork,
I
think
even
just
last
week
it
broke
it
created
black
bad
blocks
in
devnet
2,
which
was
devnet
too.
B
It
it's
it's
the
one
fuzzing
tool
you
just
keep
deploying
it
and
it
keeps
throwing
out
bugs,
which
is
awesome.
Okay
and
just
a
link
of
new
ish
tools.
Some
of
them
have
existed
for
a
few
months
already,
but
I
just
wanted
to
highlight
them
as
well.
So
we
have
a
checkpoint
sync
provider,
so
checkpoint
C.
You
might
see
that
all
over
the
Internet,
when
you're
trying
to
sync
test
net
or
if
you're,
trying
to
even
say
v-net.
B
Nowadays
we
have
a
matrix
exporter
and
we
have
a
generic
Matrix
exporter
as
well
as
an
address
tracker
now.
So
if
you
want
to
run
something
locally,
that
just
gives
you
an
alert
when
your
balance
is
below
a
certain
number.
You
can
use
our
address
Matrix
exporter.
Now
it
it's
all
tying
into
Prometheus
grafana.
So
it's
just
the
base
layer
that
we're
hydrating
on
the
chances
generator
tool
that
I
mentioned
earlier
so
freely
available.
Please
PRS,
4K
use
it.
However,
you
like
we
have
our
ansible
playbooks
and
that's
the
one.
B
We
fought
for
deploying
all
the
test
Nets
and
we
are
starting
a
new
ansible
collection
and
the
idea
of
the
collection
is
it
can
do.
One
thing
really
well
like
one
thing
is:
I
want
a
Lighthouse
note
or
I
want
a
whatever
node
and
we're
trying
to
kind
of
pull
it
out
of
consensus
deployment
ansible
so
that
we
can
have
its
own
thing
and
use
it
in
the
future,
and
people
can
just
Fork
it.
You
can
use
it
for
me
at
night.
B
You
can
use
it
wherever
you
want
and
it's
easier
to
set
same
defaults.
When
you
have
that
separation.
We
have
our
Helen
charts
in
case
your
kubernetes
house,
and
you
want
to
use
those.
We
have
the
Google.
Kurtosis
tests
still
needs
a
bit
of
work,
but
it's
already
at
a
place
where
people
can
think
of
using
it,
and
we
have
a
new
project
which
is
a
peer-to-peer
monitor.
B
All
of
us
work
on
most
of
these
tools
and
yeah.
That's
feel
free
to
Fork
anything
or
create
issues
whatever
you
want
to
and
now
coming
to
the
meat
of
it.
So
we
started
off
with
the
Shandong
test
net
in
October
that
was
largely
eof
test
net.
There
was
no
withdrawals
there.
There
was
no
I,
don't
even
think
it
had
some
of
the
smaller
ehips
that
made
it
into
chappella
now,
but
it
was
mainly
eof
testing
and
they
got
a
lot
of
public
eyes
on
it.
A
lot
of
bugs
were
found.
B
People
were
really
getting
excited
about
what
you
can
do
with
it,
and
the
tmjs
team
did
a
phenomenal
job
with
that
and
from
then
there
were
a
lot
of
local
devnets
that
I
wouldn't
even
try
and
mentioned
where
we
were
trying
to
figure
out.
If
postmogenesis
can
work,
if
share
Postman
shadowfox
can
work
or
whatever
actually
interrupt
works.
All
of
it
then
Barnabas
setup
withdrawal,
devnet
0
as
well
as
one.
So
both
of
these
were
the
first
iterations
of
the
withdrawal
test
Nets
we
did
not
include
eof
in
them.
B
B
If
I'm
not
wrong,
where
various
had
this
transaction
that
had
caused
some
some
bad
blocks
to
be
produced,
but
thankfully
everything
was
fixed
and
nice
and
we
sunsetted
that-
and
there
was
a
small
minus
spec
change
where
we
wanted
to
have
the
B
to
ghee.
Agree
change
and
that
was
included
along
with
the
restart
of
which
three
and
that's
the
current
state,
we're
planning
withdrawal,
devnet
4
already
potentially
for
next
week
and
we're
thinking
of
doing
something-
that's
mainnet
size,
because
we
want
to
also
try
and
see
how
it
would
work.
B
If
so
many
PLS
changes
were
submitted
at
the
same
time
can
nodes
keep
up
what
type
of
cash
would
they
need?
What?
How
does
that
Network?
Actually
look,
and
next
week,
there's
also
a
main
nutshadow
for
planned,
so
that
was
we.
This
would
be
midnight
Shadow
for
one.
The
notes
are
already
syncing
and
or
already
synced,
it's
yeah.
B
That's
that's
a
whole
host
of
notes
there
and
you
might
have
noticed
most
of
these
were
still
devnets
or
test
Nets
that
you
had
to
be
quite
technical
to
get
into,
and
we
want
to
try
and
offer
something
similar
to
how
we
had
killed
now
kinsuki
over
the
merge
testing
efforts.
So
we
call
that
Xiang,
and
this
is
more
of
a
public
test
net.
B
B
B
Take
part
in
the
public
test,
Nets
we're
hoping
for
some
information
over
the
next
week,
I'd
say
or
two
weeks
at
the
latest
make
deposits
withdraw
convert.
Tell
us
if
you
notice
anything
funky,
make
sure
your
favorite
explorers
work.
If
you
make
a
withdrawal
and
no
Explorer
shows
that
you
really
make
a
withdrawal
yeah
try,
try
everything
out
and
please
like
tutorials
and
guides.
B
We
definitely
need
people
doing
these
things
safely
and
in
a
relatively
controlled
environment.
So
we
hopefully
spend
the
next
couple
of
months
making
this
as
nicely
user
experience
for
people
as
possible,
and
thank
you
join
us
in
testing.
Any
of
these
feature
sets
and
follow
the
Mario
and
myself
on
Twitter
and
thank
you.
A
Superb
talk,
I
mean
we
learned
about
the
activation
process.
Challenges
along
with
the
other
key
features
explained
like
really
well.
Sometimes
it
is
hard
to
share
the
technical
progress
in
simple
English
as
an
ethereum
character.
I
think
it
is
important
to
communicate
it
to
the
community
where
things
are
in
the
language
that
they
would
understand.
So
thank
you
both
for
all
the
efforts
behind
this
presentation
and,
of
course,
behind
the
testing
that
you
guys
are
already
doing
well.
A
A
It
is
good
to
know
like
with
all
those
devnets
coming
up
in
between
there
were
a
bit
of
confusion
like
what's
going
on,
what's
going
on
either
side
and
what's
going
on
CL
side,
so
good
to
know
that
they
were
always
in
sync,
but
my
next
question
is
related
to
withdrawal.
Of
course,
withdrawal
is
the
center
of
the
shop
alarm
great
you
mentioned
about
devnet,
3
and
like
it
has
been
recently
launched.
How
do
you
think
clients
are
performing
there?
A
B
C
This
interaction
between
the
consensus
player-
it
was
an
expedition
layer
was
way,
but
it
was
just
recently
very
recently
changed
to
have
been
Direction
and
also
so
information
start
also
in
the
execution
layer
blockchain
as
a
way.
So
this
was
a
change
that
yeah
there
were
a
lot
of
changes
in
the
Tooling
in
the
in
the
in
the
different
test,
Nets
in
all.
Also,
we
have
in
the
engine
API
Everything
Changes
very
very
recently,
so
yeah,
it's
the
the
mean.
C
The
reason
I
would
say,
is
just
to
have
the
the
same
format,
because
we,
if
we
want
to
operate
the
right
now
there
was
an
issue
I
think
because
how
the
information
was
stored
and
it
was
not
coherent
between
the
the
declines.
So
there
were,
there
were
some
ideas
that
the
tools
could
have
issues
so
yeah,
just
standardize.
Everything
have
the
same
unit
in
in
both
things
it
was.
It
was.
That
was
the
reason.
B
Yeah
and
thankfully
the
change
was
not
too
bad.
All
the
clients
implemented
it
seemingly
profitable.
We
haven't
had
any
real
issues
on
devnet3,
it's
been
quite
stable,
I
think
that
was
one
a
couple
of
bad
blocks
produced
by
I'm,
gonna,
say
ethereum
JS,
but
I
think
they
already
even
found
the
bug
and
fixed
it.
So
it
was
definitely
not
a
critical
issue
there.
B
It's
been
growing
surprisingly
smooth.
So
that's
also
why
we
kind
of
have
the
confidence
to
say:
let's
do
devnet
for
at
mainnet
scale
and
let's
do
mainnet
shadow
of
work
already
next
week.
Let's
do
more
of
these
things
that
are
stressing
the
clients-
and
these
are
not
let's
just
test
if
the
feature
Works
to
begin
with,
because
it
acid
withdrawals
it
works
on
the
devnets.
So
we
can,
we
can
stress
them
now.
A
I
think
the
confidence
from
testers
gives
a
lot
of
confidence
to
the
community
overall
So
yeah.
Thank
you
for
answering
that
question.
My
next
question
is
maybe
a
kind
of
follow
up
with
that.
So
recently
we
noticed
substantial
discussion
on
withdrawal
commitment
to
better
support
like
clients.
What
are
your
thoughts
on
that
and
where
we
are
on
that
like?
Are
they
included
in
V3
or
do
we
have
plans
for
Habit
in
V4.
C
I
think
so,
because
there
was
a
proposal
to
change
from,
we
currently
have
the
format.
That's
the
just
the
rlp
hash
in
the
execution
layer,
block
headers,
and
there
was
a
proposal
to
change
that
from
from
that
format
to
the
format
that
is
used
on
the
consensus
very
class,
which
is
as
SSC
and
yeah
that
that
would
have
been
a
much
bigger
change.
So
I
think
it
was
decided
on
last
algorithm
so
that
it
was
not
going
to
be
or
or
it
wasn't
called
I'm
not
sure.
C
B
It
also
seemed
like
there
was
strong
interest
in
moving
in
that
direction,
but
just
didn't
I
think
no
one
wanted
to
hurry
it
and
just
push
it
at
this
point,
which
is
also
a
great
sign.
Anything
that
is
going
to
delay.
Withdrawals
is
being
taken,
look
at
with
like
multiple
microscopes,
which
is
which
is
great,
because
that
means
everyone's
committed
to
delivering
on
delivering
withdrawals
on
time
or
not
adding
unnecessary
delays
to
it.
A
Of
course,
at
this
point,
if
El
client
team
comes
up
with
a
new
proposal,
that
would
be
a
big
challenge
for
everyone,
including
the
client,
implementers
and
testing
team,
so
good
to
know
that
there
is
a
strong
agreement
in
moving
in
this
direction,
but
not
having
it
considered,
for
particularly
this
upgrade
very
well.
My
next
question
is
about
capella
testing.
So
there
was
this
discussion
on
the
ux
Improvement
of
stakers,
like
bls2
execution,
I'm
sure
if
this
has
been
resolved.
C
I
I
think
I
can
start
with
the
the
ux
issue.
So
basically,
at
the
point
of
this,
when
the
spec
has
started,
there's
a
a
process
that
goes
into
the
signature
generation
process
that
we
have
the
this
BLS
signature,
which
is
signed
with
certain
characteristics
of
the
beacon
chain,
which
includes
the
Genesis
evaluators
root,
but
also
the
fork
the
version
of
the
fork.
C
C
B
Which
is
great,
I,
think
yeah,
definitely
and
I.
Think
the
next
point
that
was
about
how
it's
gossiped
and
when
it's
accepted
to
be
gossiped.
That's
still
an
open
discussion
as
far
as
I
understand,
but
there's
two
large
approaches.
The
first
one
is
allow
anyone
to
submit
it
before
the
fork
happen
means,
but
it
re.
So
it
stays
on
your
local
node.
It
doesn't
go
anywhere
else
and
the
moment
the
fork
happens,
then
you
start
broadcasting
these
changes
and
then
the
second
approach
is:
don't
accept
it
at
all.
B
Until
the
fork
happens
and
then
you
start
broadcast,
then
you
accept
as
well
as
immediately
broadcast
it.
So
there's
some
pros
and
cons
for
both
of
them.
I
think
the
first
approach
or
the
second
approach
might
even
want
to
add
like
a
white
list,
so
that
people
aren't
just
spamming
the
entire
any
Beacon
note.
They
see
this
payment
with
the
change.
B
The
main
reason
this
is
even
a
thought
is
that
when
the
beacon
chain
launched
the
default
credentials,
most
of
the
stakers
had
was
0x0,
which
means
they
do
not
have
it's
a
BLS
withdrawal
address.
It's
not
in
each
one.
Withdrawal
address,
but
something
like
I
want
to
say
a
year
in
it
was
added
everywhere.
So
the
staking
deposit,
CLI
Etc
and
a
lot
of
people
did
set
each
one
withdrawal
address,
so
they
have
0x01
addresses
and
I.
B
So
after
0x0
some
people
might
have
lost
their
keys,
they
might
have
lost
a
mnemonic,
they
might
have
had.
Something
might
have
happened,
so
there's
a
lot
of
people
who
are
desperate
and
a
lot
of
hackers
who
are
desperate
to
immediately
get
the
change
in,
because
this
0x0
to
0x1
is
a
one-time,
non-reversible
change.
So
if
the
hacker
gets
that
change
in
first,
that's
there
it's
their
withdrawal
address.
B
If
you
get
your
change
in
first,
it's
yours,
which
is
I,
think
why
a
lot
of
care
is
being
given
into
thinking,
which
is
the
best
approach
such
that
nodes.
Don't
just
blow
up
or
perhaps
even
having
like
a
limited
cash
or
having
a
white
listed
address
or
having
a
I'm,
not
sure
what
the
perfect
strategy
is,
but
I
think
that's
the
the
reasoning
for
whatever
discussion
is
happening
and
that's
context
at
least.
A
That
is
very,
very
dumb.
I
know.
The
gossiping
is
something
that
client
deaths
may
be
able
to
take
care
of.
But
having
this
option
available
for
speakers
like
to
sign
it
offline
is
a
great
to
have
I
hope
we
get
that
too,
and
that
help
people
who
have
started
it
like
at
the
at
the
very
beginning,
as
you
mentioned,
that
may
have
lost
it,
get
a
solution
to
that
all
right.
A
My
next
question
is
about
engine
API,
so
a
few
changes
has
been
merged
to
engine
API
recently,
including
unify
failure,
mode
for
mismatch,
structure
version
and
a
bunch
of
cleanups
and
I.
Think
in
the
last
oil
code,
consensus
called
a
new
change
was
suggested.
Can
you
maybe
talk
a
little
bit
about
that
which
is
Define,
payload
bodies,
request
and
where
we
are
with
that.
C
Yeah
so
yeah.
Basically,
this
has
changed
to
the
engine
API
and,
as
previous
changes
to
the
engineer
API.
This
is
one
of
the
one
of
the
places
where
we
are
testing.
This
is
something
Hive
that's
to
it.
At
the
moment,
the
focus
is
on
the
the
the
engine.
Api
changes
that
are
considered
for
interaction,
for
example.
C
Right
now,
the
most
important
API
change
that
is
tested
on
hive
is
the
the
one
that
controls
the
actual
withdrawals
between
the
two
clients
and
the
the
rest
of
the
of
the
changes
are
living
added
and
before
we
are
clearly
adding
tests
for
every
all
of
the
changes
but
yeah.
Basically,
this
is
this
is
a
working
progress
in
the
in
this
aspect
of
the
engine.
Api
tests.
C
Well,
I
think
I
think
if,
if
it's,
if
it's
a
critical
change,
for
example,
if
we're
changing
something
inside
of
the
the
main
change
of
of
the
communication
of
the
CL
on
video
yeah,
that's
definitely
going
to
be
push
push
back
to
the
to
them
to
the
probably
next
next
version
of
the
India
in
the
API.
We
have
different
versions
for
each
of
the
of
the
methods
that
the
engine
API
has.
C
We
have
version
one
version,
two
for
example,
which
one
includes
withdrawals
a
newer
one
and
the
other
one
doesn't
so
in
the
future.
It
will
be
possible
to
just
increase
the
version
with
new
features,
but
I.
Think
at
this
point
it's
it's
I,
don't
I,
don't
see
this
effect,
changing
anymore,
with
newer
new
new
additions.
I
wouldn't
think
that
will
happen
at
this
point.
Yeah.
A
To
know
that
the
people
don't
have
to
wait
any
further,
it
is
going
as
per
plant
talking
about
plants.
I
know,
interrupt
definitive
plan
and
interrupt
sessions
are
going
to
be
happening
soon.
Maybe
if
you
can
talk
a
little
bit
more
about
interrupt
session
with
respect
to
shopping
like
when
it
is
where
it
is,
and
what
we
are
planning
to
test
the
most
over
there
yeah.
B
Think
Mario's
already
has
some
fun
ideas
for
how
to
fuss
it
and
try
to
break
it
down.
If
it
breaks
down.
We
kind
of
have
a
backup
idea
that
I
actually
don't
know
why
we
didn't
necessarily
try
this
before,
but
we
want
to
just
make
backups
of
nodes
once
they're
done
the
main
net
nodes
and
then
just
restore
the
backup.
So
we
don't
have
to
bother
fetching
state
from
anywhere
we
just
kind
of
stored
the
backup
locally
and
then
just
erase
everything.
B
B
B
B
They
would
have
to
start
with
post
capella
Genesis,
and
it's
probably
a
really
good
idea
to
start
doing
that
right
now,
so
that
by
the
time
it's
probably
mature,
so
it
would
be
the
most
accurate
way
of
testing
so
yeah
there's,
hopefully
a
4844
test
net
people
can
interact
with
over
the
maybe
the
end
of
next
week
and
there
would
be
Shadow
Fox
people
can
see,
and
hopefully
a
public
test
net
that
people
can
interact
with.
Immediately
after
interview.
A
Yeah,
of
course,
I
mean
we
would
like
developers
to
get
focused
on
testing
and
release
of
the
minute,
but
at
the
same
time
we
want
them
to
be
sane
as
well.
So
a
little
bit
vacation
is
also
fine.
All
right.
It's
a
time
to
wrap
up
anything
else
that
you
would
like
to
share
with
the
ATM
Community
feel.
B
C
Also
also
join
the
public
test
Nets.
It's
amazing
that
people
can
join
and
just
test
everything
with
us
at
the
same
time
yeah.
So,
yes,
everyone
is
very
welcome
to
to
join
and
send
their
withdrawals
to
the
validators
on
the
on
the
distance
right
that
the
test
validators
so
yeah,
it's
gonna,
be
amazing.
A
Those
are
some
encouraging
words,
I
hope
many
people
join
us
for
testing
and
Mario.
We
appreciate
you
taking
our
time
to
talk
about
testing
and
tooling
part
of
the
upcoming
upgrade
and
sharing
the
roadmap.
I
hope
this
is
comforting
for
people
eagerly
waiting
to
see
the
upgrade
activated
on
the
main
net.
A
On
this
note,
thanks
to
our
Channel
subscriber
for
watching
and
listening
to
this
special
episode
on
shapela
upgrade
check
out
description
for
Shanghai
kapella
playlist
to
follow
other
eips
and
related
talk
on
this
upgrade.
Should
you
have
any
question
on
this
or
any
other
proposal?
Let
us
know
at
Catholic,
Discord
ethereum
Caterers
are
collecting
users
suggestions
for
client
Improvement.
If
you
run
an
ethereum
node,
please
take
out
time
to
share
your
response.