►
Description
Topics covered
-----------------------------
1:10 - Proto’s introduction
1:54 - Parithosh’s introduction
2:18 - The Merge testnet
2:25 - What is the merge?
3:14 - Spec versions
4:10 - EIP-3675
5:28 - EIP-4399
6:40 - Engine API
9:21- Summary of the year of working
11:35 - Where are we now?
12:20 - Devnets
14:50 - What are devnet achieving?
17:05 - What is Kintsugi testnet?
18:47 - How do I take part?
20:14 - How can you help the testing efforts?
21:55 - Where do I ask for help?
22:40 - The path to the Merge
25:35 - How do you see Rayonism similar or different to Amphora
27:29 - What was the main advantage of having the in person meeting to launch a testnet?
29:27 - Did Pithos testnet set up guide amplified the community participation in active devnet conversation?
32:07 - Are we expecting more public testnets after Kintsugi?
33:37 - How would you know this is the right time to move to the next staze?
35:11 - How can we get even more people involved in the testnet? Do you think bounties & POAPs will help?
37:00 - Was there a fix for the two miners problem? Is there a plan to rerun the scenario?
40:20 - Post Merge network upgrade structure
42:11 - EL and CL Public testnets after the Merge
43:25 - Is the plan to run the Merge on Ropsten before the difficulty bomb goes off next year? When will that decision be made whether to diffuse the bomb or go forward with the merge there?
45:25 - Shadow forking Gorli
Resources
------------------
Slides - https://docs.google.com/presentation/d/14EdDY7m80b6Fb8rcw-QJU_7u68rKV2825xDAzLQJyWE/edit#slide=id.p
Kintsugi testnet version information - https://notes.ethereum.org/@ExXcnR0-SJGthjz1dwkA1A/HkJ8Aolct
Connect to the Kintsugi Testnet - https://hackmd.io/dFzKxB3ISWO8juUqPpJFfw?view#Connect-to-the-Kintsugi-Testnet
Send a transaction over metamask - https://hackmd.io/@76u7HkGHS7-S8srG1WCWjg/rk86J3MKt
How to Join Ethereum Merge Kintsugi Testnet? - https://etherworld.co/2021/12/20/how-to-join-ethereum-merge-kintsugi-testnet/
Test ETH faucet - https://faucet.kintsugi.themerge.dev
Test explorer - https://explorer.kintsugi.themerge.dev/
Kintsugi specs - https://hackmd.io/@n0ble/kintsugi-spec
Milestones - https://notes.ethereum.org/@djrtwo/kintsugi-milestones
EIP-3675 with Mikhail Kalinin - https://youtu.be/zNIrIninMgg
Merging Ethereum with Paul Hauner - https://youtu.be/S1KFIVue248
The Merge Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqoLxXqZqT4hcYhoHoP6w12
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Follow at Twitter
-----------------------------------------------
Proto Lambda proto.eth | Parithosh Jayanthi @parithosh_j | William Schwab @William94029369 | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/EthCatHerders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herde...
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
A
Proto
is
our
first
time
guest
and
is
currently
working
on
ethereum
scaling
and
r
d,
and
you
already
met
with
paritos
on
the
talk
on
beacon
chain
metrics.
It's
always
fun
to
know
our
devs.
So
before
we
get
into
the
presentation,
may
I
request
proto
to
share
about
the
professional
history
and
how
you
find
ethereum
and
maybe
paritos
can
follow
with
a
quick
introduction
for
our
new
followers.
B
Sure,
yes,
around
the
start
of
ethereum
to
the
new
design
where
we
started
to
have
this
beacon
chain.
I
joined
the
ethereum
foundation
to
help
with
testing
optimizations,
and
what
drew
me
to
this
thing
is
that
we
could
finally
scale
ethereum
today,
I'm
working
on
different
kinds
of
skating
on
roll-ups,
but
this
past
year
we've
worked
on
lots
of
past
test
nets
and
what
I'm
trying
to
get
to
is
this,
this
niframa
with
proof
of
stake
and
sharding.
C
A
B
B
B
So
I'll
talk
a
little
bit
about
how
we
achieve
those.
If
you
can
go
to
the
next
slide,
there's
a
lot
to
add.
So
we
have
different
specs
for
consensus,
layer
for
the
exclusion
layer
and
the
communication
between
these
two
layers,
which
is
called
the
engine
api
and
as
part
of
the
execution
layer
we
have
eips
for
the
consensus
layer.
We
have
a
specs
repository
where
introduce
these
changes
and
you
can
follow
the
the
most.
The
very
latest
packs
on
this
link
here.
B
Spec.Merge.Wiki,
if
you
want
to
keep
up
to
that
these
things
they
change
every
other
week,
it's
hard
to
track,
but
we
try
and
bridge
between
all
the
client
implementers
to
have
them
all
join
the
same
testnet,
and
then
we
are
also
tracking
how
all
these
clients
are
doing,
how
far
how
long
they
are.
We
have
blind
milestones
and
then
we
can
go
to
the
next
slide
about
the
earpiece.
B
B
This
is
where
the
proof
of
work
stops
where
we
have
reached
a
maximum
amount
of
work
and
it
forces
the
system
to
move
to
a
proof
of
stack
and
then
there's.
This
erp
goes
indeed
in
depth.
How
this
transition
works
very
important
piece
for
test
nets,
we're
just
repeating
it
over
and
over
again
to
make
sure
it
works,
and
we
covered
all
the
excuses.
B
B
B
B
We
have
the
mix
hash,
so
we
use
the
same
header
field
and
through
the
same
minimal
change
you
can
also
detect
if
the
merge
happens
from
within
the
ethereum.
So
if
your
depth
is
affected
by
block
time
or
something
like
that,
this
is
definitely
something
you
could
use
and
right.
So
this
is
the
interesting
bit.
This
is
the
thing
we
are
we're
using
to
connect
these
two
layers
and
also
the
thing
that's
changed
the
most
and
we
hammered
it
down
from.
B
B
B
This
is
parallel
development
and
also
it
minimizes
the
the
risk
right,
because
we
have
existing
software,
that's
true
and
tested.
We
make
minimal
changes
to
combine
it
and
to
get
to
the
merge,
and
so
this
api
consists
of
filters,
updated,
says
where
we're
going
and
it's
if
you're
a
producer.
It
also
means
that
you
start
building
a
block
if
you're
next
up,
then
there's
a
method
to
fetch
the
production
work
and
then
there's
some
methods
to
add
to
the
to
the
local
chain
to
extend
your
your
chain
yeah.
B
B
B
Of
course,
there's
more
so
with
different
pieces
of
software,
you
can
have
the
execution
layer
and
consonants
layer,
sync
separately.
Paul
hunger
is
doing
really
great
work.
I'd
love
to
see
like
peeping
eip
about
this.
Eventually,
when
it's
ready
and
then
of
course,
we
need
to
really
double
down
on
testing.
That's
not
the
wrong
form,
but
there
are
also
other
forms
like
fuzzing
hive
and
mr
and
in
the
future
we
should
once
we
have
this
larger
test
net
and
maybe
another
test
net.
B
In
a
few
months,
we
need
infrastructure
to
get
ready,
so
everyone
needs
to
understand
how
they
run
this
double
layer
system,
excellent.
Okay,
so
I
thought
we're
close
to
the
end
of
the
year.
That
would
be
great
to
show
where
we
are
in
terms
of
this
whole
year.
We
have
lots
and
lots
of
dust
nuts,
not
grads.
It
was
vault.
B
It
started
for
the
merge
of
fermentism,
which
meant
this
relatively
hacky
solution.
It
was
a
hackathon
kind
of
thing
where
we
would
take
execution,
clients
and
consensus
clients,
pull
them
together
through
a
very
primitive
form
of
the
engine
api,
the
first
draft
and
disable
the
networking
layer
on
the
execution
side.
B
We
just
have
to
chain
move
and
be
able
to
process
transactions
the
bare
minimum
and
it
worked.
We
got
a
test
net
for
a
little
bit
less
than
a
week,
then
we
had
altered
development
and
london
development.
These
upgrades
on
mainnet
for
ethereum
and
ethereum
ii,
and
then
once
those
were
completed,
we
got
to
amphora.
B
This
was
an
event
increase
where
we
got
several
different
client
implementers
together
to
to
revisit
the
emerge
specs
and
to
work
on
this
interrupt.
This
idea
that
all
the
clients
could
talk
to
each
other
to
go
through
all
the
compatibility
issues-
and
this
is
where
paritars
comes
in
with
the
deployment
of
the
the
first
real
like
large,
does
not
first
and
forever,
and
then
we
really
realized
that
the
configuration
should
be
tweaked.
We
set
up
a
larger
one
called
beatles.
B
C
Thanks,
hey
so
just
to
recap:
we
started
off
in
the
beginning
of
the
for
more
or
less
like
the
middle
of
the
year
with
rhianism,
then
we
split
up
with
a
london
main
network.
Then
we
had
the
altair
hard
fork,
but
in
between
we
had
amphora
and
petos
testing
devnets,
and
you
can
also
see
how
the
spec
versions
are
changing
and
if
you're
ever
interested
in
looking
at
what
the
changes
were
or
how
development
actually
progressed,
you
can
go
through
the
different
spec
versions
yeah.
C
This
is
essentially
how
we
evolved
over
time
and
now
we're
at
almost
the
end
of
the
year
and
we're
looking
at
the
kintsubi
testnet
devnets,
what's
happening
with
the
dead
units.
We've
had
four
so
far,
my
seven
at
zero
to
three.
The
aim
of
the
devnets
was
to
go
through
the
transition,
often
and
try
different
combinations,
so
either
change
the
number
of
validators
try
to
try
different
type
of
transactions
in
one
of
them.
We
had
multiple
miners
change.
C
The
client
distribution
see
see
what
happens
basically,
and
this
was
happening
parallel
to
the
spec
changes,
so
each
devnet
also
sometimes
had
api
changes
sometimes
had
different
requirements
to
join
them.
So
different
clients
were
ready.
It
was
essentially
iterate
and
see
what
breaks
each
week
if
something
breaks,
try
and
fix
it.
For
the
next
week
we
started
off
initially
with
merge.net
zero
and
that
already
broke
with
an
edge
case
thanks
to
marios.
There's
he's
really
earned
the
name.
That's
not
destroyer.
By
now
or
devnet
destroyer
we're
still
investigating
it.
C
We're
gonna
definitely
try
and
recreate
that
a
bunch
more
times
and
add
it
as
a
static
testing
scenario
for
the
future,
because
that
devnet
was
broken.
We
relaunched
a
few
days
later,
the
devnet,
because
again
because
it
was
a
bug
with
geth,
but
it
worked
fine
after
relaunching
it
on
the
same
day,
merged
net
two
worked
quite
smoothly.
Actually,
this
is
when
it
started
getting
a
bit
more
confidence,
big
things,
weren't
changing
anymore.
There
were
more
iterative
changes.
C
We
around
this
time
is
when
testing
efforts
really
ramped
up
I'll
talk
a
bit
more
about
that
later
and
public
people
were
joining
in
merged.net
was,
I
think,
the
first
time
someone
outside
of
the
core
client
development
team
were
creating
validator
deposits.
They
were
running
their
own
deposits,
writing
their
own
documentation
and
really
being
a
part
of
the
devnet
merge.
Devnet
3
had
some
issues
in
the
middle.
C
We
did
find
some
some
bugs
with
different
client
combinations,
but-
and
there
was
a
communications
issue
in
the
beginning,
but
after
everything
was
updated,
it
was
stable,
we've
actually
finding
a
lot
more
bugs
with
our
tooling
rather
than
anything
else,
but
all
of
that
looks
a
lot
more
stable.
Now
now
one
might
question:
what
are
these
devnets
even
achieving?
C
Well
one
of
the
big
things
they
help
is
figuring
out
interrupt
between
different
client
combinations.
The
last
step
net
had
something
like
12
combinations
and
kinsuki
will
have
16
combinations,
so
we're
already
getting
to
a
lot
more.
I
think
the
maximum
number
of
combinations
we
have
right
now
is
25,
so
hopefully
the
next
public
test
night
we'd
actually
get
that
we
want
to
check
the
stability
of
the
network
in
different
scenarios.
C
It's
also
a
target
for
optimistic
sync,
the
one
that
proto
was
talking
about.
That
paul
is
working
hard
on
it's
useful
for
iterating
on
our
tooling,
because
merge
devnets
are
new.
We
also
need
new
ways
to
actually
look
at
if
the
devnet
is
working
or
broken,
or
how
do
we
debug
them
and
ideally
we'll
start
moving
towards
devnets
that
mirror
midnight
client
distributions
or
if
we
notice
certain
types
of
setups
are
more
common.
C
Again
thanks
to
mario's
who's
running
a
fussing
transaction
fuzzer,
we've
got
a
lot
of
activity
on
the
devnets
merge
that
net
three
particularly
right
now
has
over
a
hundred
thousand
transactions
over
50
000
blocks,
70,
something
thousand
addresses
has
20
000,
validators
and
so
far
between
90
and
95
participation
rate.
I
think
there's
like
one
client
combination
that
has
an
outstanding
buck,
but
that
they're
seriously
looking
into
it
and
that's
not
so
bad,
like
one
out
of
12,
has
an
issue.
C
We
were
able
to
find
config
bugs
tooling
bugs
some
issues
with
the
client
implementations.
There
were
a
lot
that
we
were
able
to
find
out
through
these
couple
of
templates.
Devnet
3
also
had
a
lot
of
public
participation
from
the
testing
the
merge
efforts-
and
I
will
talk
about
that
after
I
tell
you
about
kinsu.
C
So
kimsugi
is
our
first
attempt
or
our
first
attempt
with
the
new
specs
of
a
long-running
public
testnet.
It's
based
on
the
latest
specs
after
our
four
or
five
rounds
of
iteration.
Now
the
test
net
has
72
000
validators
with
a
12
client
combination.
I
think
that
was
a
bit
more.
Even
okay,
so
tenses
are
going
to
be
a
bit
confusing
because
the
test
net
launches
tomorrow,
but
the
video
for
everyone
else
will
come
out
next
week.
C
So
technically
I'm
talking
the
future
tense,
but
for
you
guys
it
will
be
in
the
past,
so
it
will
have
launched
by
the
time
you're
watching
this.
Our
main
idea
is
to
have
this
test
net
running
for
a
longer
duration
of
time,
at
least
central
image
and
maybe
end
of
jan,
depending
on
how
things
go
this
for
testing
all
of
your
smart
contracts.
Your
valid
data
infrastructures,
tooling
block
block
explorers
if
you're
an
rpc
provider.
C
What
you
need
to
change,
if
you
can
think
of
interesting
transactions,
try
them
out
if
you
can
think
of
attacks
on
different
clients,
try
them
out,
for
example,
barnaby
and
caspar
from
the
ethereum
robust
incentive
group.
They
tried
out
one
of
their
yoga
attacks
on
the
previous
steps
and
I'm
sure
they're
also
excited
to
try
that
on
this
net,
it'll
be
one
of
many
public
test
nets,
but
the
earlier
you
start,
the
the
head
start
and
the
earlier
you
break
something
the
more
easily
we
can
iterate.
C
C
I'll
have
a
static
link
and
I'm
sure
it'll
be
on
the
youtube
video
as
well.
We
have
a
basic,
add
network
to
metamask
button
that
sets
your
rpc
chain
id
so
from
there
on
you're,
interacting
with
the
new
chain,
and
you
can
question
okay,
but
I
need
some
sort
of
ether
to
interact
with
it
right.
So
we
have
a
faucet
just
go
in
there
paste
your
ethereum
as
and
you
will
get
50
test
net
ether,
maybe
a
test
net
ether.
C
We
can
tweak
that
based
on
how
much
you
you
might
need,
and
once
you
have
some
ether
make
your
transactions.
We
have
block
explorer.
So
it's
a
typical
transaction
block
explorer
that
we're
used
to
this
is
just
a
screenshot
from
an
older
test
net.
That's
why
it's
filled
with
different
information,
but
you
can
paste
your
address.
Have
a
look
at
it
view.
C
We
have
all
the
tooling
in
place,
and
we
even
have
a
document
with
a
bunch
of
testing
scenarios
that
you
that
we've
thought
of,
if
you
think
of
even
different
testing
scenarios,
fingers
or
edit
that
or
add
a
comment
whatever
and
you
could
question
okay,
who's
who's.
This
really
for
regular
users
feel
free
to
test
the
merge
chain.
If
you're
anxious
about
how
the
merge
will
change
ethereum
have
a
try
like
do
a
transaction
notice
that
nothing
changes
in
your
life
be
happy.
C
I
guess
for
the
technically
involved
people
we
have
a
lot
more
elaborate
tests,
for
you
feel
free
to
take
part,
have
a
look
write
documentation
for
whatever
you
do
share
that
with
whoever
we
definitely
need
to
improve.
Ux
of
our
tooling
we're
increasing
complexity
by
having
these
two
systems
interact
now,
so
it
would
be
great
to
also
have
new
tooling
that
helps
us
visualize
how
these
systems
are
interacting.
C
We're
also
lacking
a
lot
of
scripts
to
check
data
analysis
tools
of
how
things
are
happening
on
chain.
So,
if
you're
someone
who's
interested
in
that
help,
if
you're
someone
who's
good
with
writing
or
making
videos
help
document
stuff,
because
there's
there's
just
so
much
information
and
so
much
happening
that
we
we
need
ways
to
get
this
information
out.
So
it's
basically
everyone.
We
have
something
for
each
and
every
one
just
take
part.
C
If
not,
there's
the
ethereum
r
d
discord
server,
we
have
a
testing
channel
there
and
the
each
taker
community
has
been
super
helpful.
They
also
have
a
testing
channel
testing
the
merch
and
you
could
post
over
there
as
well
we're
usually
monitoring
a
combination
of
all
three.
We
apologize
for
not
super
fast,
but
hopefully
you're
also
involved
in
helping
answer
questions
for
other
people
so
and
just
to
give
you
an
overview
of
what
the
timeline
is.
Looking
like
we're
currently
q421,
we
have
devnets.
A
It
beautifully
provided
the
overview
of
most
of
the
works
that
that
were
done
for
the
merge,
like
upgrade
testnet
timeline
and
the
resources
thing
it
was
super
cool.
Well,
the
presentation
already
have
answered
most
of
the
questions
that
we
had,
but
I
have
a
few
more
if
I
can
go
back
to
the
realness
man
amphora.
A
B
Do
you
need
eyes
and
feedback
on
how
this
thing
works
and
the
earlier
you
start
the
better
really
like
we
started
realism
with
this
testnet
called
stacclaw,
which
is
glass.
It
was
it
it
fell
within
one
day,
then
we
started
another
test
testnet
it
worked
for
a
week
and
like
you
need
to
iterate,
and
things
will
like
it's.
The
prototype
things
will
all
go
wrong.
B
We
learn
from
it
and
then,
if
every
other
test,
not
after
we
only
improved
and
improved
and
improved
and
with
amphora,
we
opened
up
the
network
layer
on
the
execution
layer.
So
that
means
these
exclusion.
Clients
can
stay
sync,
so
this
means-
and
we
have
a
transaction
pool
as
well.
All
of
the
functionality
is
there
in
amfora
and
then
again
it
was
okay.
Now
we
have
the
fill
functionality
set.
A
C
A
A
That's
right
so
talking
about
amphora,
I
understand
like
amphora
was
like
in
person
meet.
I
don't
know
if
it
was
the
first
time
that
it
ever
happened
for
any
upgrade
like
both
the
consensus
layer
and
the
execution
layer
team
like
joined
together.
So
I'd
be
curious
to
understand
what
would
you
consider
as
the
biggest
advantage
of
having
the
in-person
meeting
for
a
test
net
launch.
B
Well
so
test
at
lunches.
There
are
rare
events,
it's
not
like
everyday
work
or
not
like
a
regular
call,
and
things
will
go
wrong
or
there
will
be
incompatibility
issues,
so
you
can
directly
discuss
these
and
have
a
much
better
chance
of
succeeding
and
especially
during
amphora.
This
was
this
week
to
just
set
up
as
many
local
test
nets
as
possible
to
go
through
these
interactions
between
clients,
tests
of
often
capture
what
a
client
in
isolation
does.
C
And
I
think
it
was
awesome
to
be
in
person
when
a
single
thing
broke.
You
could
just
point
at
someone
in
the
room
they're
right
there
to
help
out,
whereas
with
the
reality
of
ethereum
development
right
like
online
everyone's
all
over
the
world
and
trying
to
coordinate
a
quick
answer
for
like
a
two-minute
question
that
you
know,
the
exact
person
would
have
it,
but
then
the
wrong
time
zone,
and
they
might
only
reply
to
you
next
morning,
whereas
being
in
person
you're
like
yo,
did.
A
C
I
think
it
definitely
did.
It
was
also
extremely
surprising
because
it
was
the
first
time
I
was
involved
in
a
public
test
net
of
that
scale,
and
I
like
proto
and
I
looked
through
all
the
configs
and
we
launched
the
test
net
and
I
sort
of
everything
was
fine,
so
I
went
to
bed
and
the
next
day
morning
someone's
made
videos
walkthroughs,
there's
prs
with
fixes
for
some
docker
compose
files.
I
had
put
up
someone's
edited
the
readmes
to
make
them
nicer
like
I
did
not
expect
any
of
this.
C
I'm
I'm
hoping
that
that's
been
awesome
and
I
hope
that
continues
for
the
next
couple
of
test
nets
as
well.
It's
also
the
case
with
testing
the
knowledge
there's.
A
lot
of
people
now
who've
had
experience
with
running
clients
on
the
devnets
and
when
there's
questions,
they're
taking
ownership
and
asking
others
they're
taking
notion,
answering
the
questions
without
us
having
to
answer
each
question
individually.
A
C
Definitely-
and
it
was
like
some
really
small
things
that
at
least
eyes
developer,
don't
think
of,
for
example,
in
my
readme
I
just
had
a
line
that
says,
get
your
ip
address
and
put
it
in
this
variable
file.
It
didn't
occur
to
me
that
some
people
might
not
know
how
to
get
their
public
ip
address
right.
Yes,
yeah,
so
someone's
making
a
readme
to
a
pr
to
fix
the
readme
to
add
some
more
verbose
information.
It's
stuff
like
that,
also
helps
change.
The
mindset
as
to
who's
getting
involved
reduces
the
barrier
to
entry.
A
So,
moving
on
to
the
next
chestnut,
are
they
kimsuki?
So
many
versions
of
kensaki
are
already
nuked
and
I
was
thinking
that
the
version
three
and
the
fourth
test
net,
as
you
say,
like
v3
and
devnet
4,
would
be
the
last
devnet
which
I
think
is
still
right,
because
tomorrow
it's
going
to
be
the
public
destiny
out,
but
I'm
a
little
confused
by
one
of
your
statement
mentioning
that
this
is
one
of
the
many
test
nets.
What
does
the
that
mean
like?
Are
we
expecting
more
public
testness.
C
So
I
think
we're
gonna
stop
with
weekly
test
nets
until
the
end
of
the
holiday
season.
So
we
want
to
have
something
stable,
that
we
have
mature
documentation
for
that
people
can
test
on
and
we
keep
this
running
for
a
while.
But
at
the
end
of
that
we're
gonna
again
see
if
there's
stuff,
we
have
to
change
on
the
spec
and
then
try
and
go
back
to
a
weekly
cadence
again
just
go
through
the
merge
as
often
as
possible,
and
I
I
do
see
that
there'd
be
more
public
test.
That's
coming
before.
B
A
B
So
we
have,
I
think,
what
I
really
like,
that
during
the
consensus
school
and
the
awkward
of
school,
we
all
got
time
for
discussion
about
emerge
which
includes
spec
changes
and
test
notes
and
over
time
I
think
the
spec
changes
have
become
lesser
and
lesser
they're,
more
subtle.
Every
time
at
this
point,
they're
not
affecting
consensus
anymore.
C
And
we're
slowly
getting
close
stage
where
they're
stable
enough,
that
we
can
have
more
creative
testing
environments
to
try
and
break
them
also
have
a
lot
more
fuzzing
going
on.
I
think
the
longer
that
it
exists
in
that
phase
that
we've
thrown
everything
we
can
think
of
at
it
and
it
hasn't
broken
the
more
confident
we'd
feel
with
yeah
cool.
Let's
figure
out
I
mean.
A
B
I
mean
I
don't
think
I
have
to
convince
anyone
for
po-op
they're
they're
a
hit
in
the
firm
two
sphere.
At
least
I
would
say
yes,
we,
if
you
have
ideas
so
like
how
to
encourage
it,
then
open
the
discords
we
can
like.
We
have
these
channels
for
development,
but
we're
also
very
eager
to
hear
like
how
can
we
expand
the
testing
and
that
just
also
means
test
net
user
acquisition,
really,
where
the
more
crazy
things
users
can
deploy
or
try
on
our
just,
not
the
better
and
yeah.
A
C
Been
awesome,
his
first
transaction
so
far
haven't
broken
devnet
three,
but
they've
broken
two
tools
like
three
or
four
times
that
we
used
to
like
observe
big
explorers
and
stuff
like
that.
Just
because
oh
the
gas
limit
was
above
the
valuable
type
that
we're
using
or
this
was
different
and
then
suddenly
the
explorer
is
down
or
the
rpc
is
down.
So
it's
definitely
making
stuff
better.
A
C
So,
according
to
the
spec,
we
shouldn't
have
had
that
problem
and
we're
still
investigating
as
to
why
it
happened
and
what
the
scenario
was.
But
this
was
still
based
on
by
now
like
three
versions,
older
spec,
so
where
you
have
to
recreate
a
devnet
with
the
latest
spec,
try
the
exact
same
scenario
and
see
if
it
breaks
as
well.
Hopefully
we
can
narrow
it
down
and
figure
out,
what's
actually
going
on,
but
right
now
there's
no.
It
shouldn't
happen,
but
it's
happening.
B
I
think
we
can
separate
these
two
things.
We
have
the
emerge
transition
and
the
post
merge
testing,
and
I
would
like
everyone
to
to
pay
attention
to
both
that
every
testnet
that
launch
just
goes
to
a
transition
once
and
then
offers
the
the
post
merge
for
a
long
time.
So
I
think
we
as
developers
within
the
merge.
B
Also
for
testing,
I
think
the
the
shadow
fork
id
where
depth
developers
take
an
existing
testnet
create
their
own
version
by
extending
their
own
non-canonical
chain.
We
can
repeat
that
in
a
similar
way,
where
we
take
gordy
or
robstone
and
build
a
shadow
fork,
so
we
keep
the
proof
of
work
or
proof
of
authority,
that's
not
running,
but
we
also
start
forking
it
off
in
a
proof
of
stack
chain,
and
that
is
one
way
to
repeatedly
test
the
transition
on
larger
test
nuts,
with
like
real
behavior.
C
Exactly
and
we're
also
improving
some
of
our
tooling
rafael
from
the
ef,
for
example,
has
been
building
a
lot
of
spin
up
automated
test
nets.
So
we
can
just
hand
that
over
and
say
around
these
couple
of
commands,
you
have
a
test
running
in
like
10
minutes
and
such
tooling
helps
you
go
through
the
this
exact
merge
transition
a
lot
more
often
with
a
lot
less
manual,
interaction,
so
to
say.
A
A
So
that's
about
the
merge,
but
I
know
I
mean
my
next
question
is
about
future
upgrades
and
chestnuts,
so
it
may
be
a
little
early
to
learn
about
that,
but
I
know
the
community
is
also
curious
to
know
what's
next,
so
let's
talk
a
little
bit
about
the
post
merger,
starting
from
the
upgrades,
it
would
be
interesting
to
get
some
idea
about
network
upgrade
structure
after
the
merge.
Now
that
we
have
two
different
chains
work
running
in
parallel.
How
do
we
see
our
upcoming
upgrades.
B
B
This
affects
both
layers,
but
we
may
also
have
hard
forks
that
change
the
evm,
which
only
affects
the
execution
layer
and
so
there's
this
separation,
and
we
have
fork
scheduling
that
works
exactly
the
same
as
we
used
to
have
where
the
beacon
chain
or
the
consensus
layer
has
an
epoch
number
set
time
to
update
and
now
with
the
exclusion
layer,
things
may
change
a
little
bit
because
we
don't
rely
on
like
a
block
number
anymore.
You
can
use
the
beacon
chain
if
you
wanted
to
for
updates,
although
I
think
block-out
is
still
reasonable.
B
A
Right,
I
understand
the
last
upgrade
on
the
proof
of
work
chain
or
the
arrow
glacier
upgrade.
It
didn't
go
on
the
robson
or
any
of
the
public
testing.
But
I
remember
the
get
team
deploying
a
new
test
net,
not
sure
if
it
is
active
for
any
upgrade
testing
at
this
time
or
not,
and
also
on
the
consensus
layer
side.
There
was
this
discussion
of
discontinuing
the
piermont
testnet
and
maybe
continuing
with
raja
for
some
time.
A
A
So,
as
I
understand
the
arrow
glacier
that
was
deployed
on
december
9th
was
the
last
upgrade
related
to
difficulty
bomb
before
march,
and
my
understanding
is
that
we
do
not
expect
the
difficulty
bomb
to
show
up
before
the
merge.
We
actually
have
recorded
an
interesting
conversation
with
the
tj
rush,
who
actually
did
the
calculation
behind
the
difficulty
bomb
like?
A
How
is
it
calculated
and
why
did
developers
agree
to
push
it
till
june,
because
the
initial
proposal
for
4345
was
to
push
it
till
may
the
developers
have
already
considered
some
some
gap
that
that
should
be
there
in
case,
merge
is
delayed
by
a
month
or
two,
but
we
do
not
expect
the
difficulty
bomb
to
like
come
again
ever
on
the
network.
That's
my
understanding.
I
know
we
have
more
devs
here.
If
anyone
has
to
add
anything,
please.
A
B
C
True,
so
there's
one
more
thing
that
I
can
talk
about
so
marius
and
I
and
a
couple
of
others
are
already
planning
on
shadow
forking
girly,
for
example.
So
this
is
exactly
what
proto
was
speaking
about
earlier,
so
that
we
can
shadow
for
an
existing
testnet,
keep
doing
this
multiple
times.
So
we
have
like
a
non-canonical
merged
chain
that
would
definitely
help
with
testing.
So
we're
actively
going
to
go
down
that
route
and
see
see
how
much
testing
we
can
achieve
with
that.
A
B
So
I
think
the
interesting
part
is
here
is
that
dabs
do
this
all
the
time
where
they
plug
into
an
archive
note
and
split
off
a
chain
with
their
version
of
the
contracts?
Some
cheat
codes,
maybe
but
then
have
the
existing
layer
one
state
to
test
with-
and
this
is
also
for
the
merge-
just
really
valuable-
to
have
the
real
strength,
and
this
means
will
shadow
for
dust
nuts
and
maybe
also
shadow
fork.
May
not.
That
will
be
like
the
ultimate
test
before
we
go
live.
B
C
A
Yeah,
of
course,
like
whatever
is
here,
make
your
contribution
and
whatever
comes
up
next,
we
will
obviously
be
a
part
of
that.
I
just
want
to
make
a
mention
of
one
more
thing.
We
did
talk
about
optimistic
sinking.
Post
merge,
like
paul,
paul
honor
is
working
on
that
right,
so
we
did
an
episode
on
merging
ethereum
a
while
ago
with
paul,
and
he
did
talk
about
like
possible
scenarios.
A
A
B
A
A
A
On
monday,
you
have
to
assume
that
the
public
test
net
is
already
live
and
the
documentation
will
be
listed
in
the
description
section,
so
you
can
follow
and
do
the
setups
and
if
you
have
questions,
feel
free
to
come
back
with
your
questions
either
you
can
leave
it
in
the
comment
in
the
youtube
channel
itself
or
show
up
on
any
of
the
discords
that
we
mentioned
today.
It
would
be
really
interesting
to
see
participations
coming
from
community,
and
I
just
want
to
share
that
in
the
ethereum.
Cathode
is
discord
also.
A
I'd
like
to
thank
our
guest
one
more
time
for
sharing
these
information
about
the
test
net
and
also
talk
a
little
bit
about
what
we
can
expect
with
future
upgrades,
even
the
post
merch,
and
thank
you
to
all
the
participants
of
the
call
who
joined
and
added
a
lot
of
good
question.
Those
are
really
helpful.
A
A
So
if
you
like,
the
episode
please
hit
the
like
and
do
not
forget
to
share
with
community
members.
Guest
twitter
handles
slides
and
other
related
resources
are
already
added
in
the
description
section,
we'll
be
back
with
another
interesting
topic,
for
you
till
then
keep
watching
keep
sharing
your
love
with
your
freedom.