►
From YouTube: PEEPanEIP#63: Kiln - The Merge Testnet & Goreli shadow forking with Marius and Parithosh J.
Description
Topics covered
-----------------------------
1:13 - Guest intro (Marius)
1:39 - Guest intro (Pari)
2:30 - What is the Merge?
2:55 - Devnets
4:17 - How did Kintsugi do?
5:40 - Where are we now?
6:40 - What is the Kiln testnet for?
8:14 - Bad block generator?
11:00 - Shadow forking
17:10 - Testing plan: Hive
20:13 - Kurtosis
22:57 - How can you help the testing efforts?
28:10 - Where do I ask for help?
30:30 - The path to the Merge
33:14 - Q&A
33:20 - #TestingTheMerge
36:55 - How long will Kiln be run until the first test network (Görli etc) gets forked?
37:58 - How long before each subsequent test network is forked?
40:44 - How likely are spec changes after Kiln v2? Or will Kiln essentially be the mainnet spec testnet?
43:45 - Role of public offering like Kurtosis & Chaos engineering?
46:55 - What’s the benefit of changing features between testnet compared to sticking with the same features until the launch?
52:02 - Merge timeline
Resources:
-----------------
The beacon chain genesis will only be Friday, March 11, 2022 at 14:00 UTC. The PoW chain has already started and we expect the PoW phase to last ~a week.
You can find the files and bootnodes here here: https://github.com/eth-clients/merge-testnets/tree/main/kiln
We have tooling up already: https://kiln.themerge.dev/
The eth2.0-deposit-cli should already work and launchpad will be announced in the coming days.
Client teams are still working on releases, so the doc is a bit unfinished, but you can find info on versions and how to run them here: https://notes.ethereum.org/qrDBhhydTsyKFmGaBl2COQ?view
We'd definitely appreciate community help is getting the guides up and running. In the meantime, feel free to use our public RPC to deploy your smart contracts.
- Slides - https://docs.google.com/presentation/d/1HNOyMI4AhwYdpssa07moWZgh-VGTy75oR4JUWu0fSXQ/edit#slide=id.p
- Kiln milestone - https://notes.ethereum.org/@timbeiko/kiln-milestones
- Merge devnet 4 - https://notes.ethereum.org/D5xK4XrmTb6MKGudf_hcrg
- Goerli shadow forking - https://twitter.com/vdwijden/status/1484255125170532358
- Claim your Kintsugi POAP - check your chat logs on https://chat.blockscan.com/start with your Kintsugi deposit address to claim your Kintsugi POAP
Related tweets
- https://twitter.com/parithosh_j/status/1501679135973945355
- https://twitter.com/vdWijden/status/1501853162688421888
Follow at Twitter
-----------------------------------------------
MariusVanDerWijden @vdWijden | parithosh @parithosh_j | Pooja Ranjan @poojaranjan19
Merge Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqoLxXqZqT4hcYhoHoP6w12
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
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-herders
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Welcome
to
another
informational
episode
of
penny
penn
educational
video
series,
where
they
discuss
an
ethereum
improvement
proposal,
upcoming
upgrades
and
the
basics
of
ethereum
blockchain,
I'm
puja
ranjan,
and
today
we
are
going
to
discuss
kiln
demerged,
test
net
and
goalie
shadow
forking.
To
talk
on
the
topic.
Our
guests
are
testing
wizards
of
ethereum,
marius
and
paritos.
A
And
we
also
have
a
good
on-call
attendance.
I
see
some
researchers
from
kth
royal
institute
of
technology.
They
recently
published
a
research
paper
on
chaos,
engineering
and
are
looking
forward
to
contribute
in
merge
testing.
We
are
joined
by
a
few
members
so
guys
if
you
would
like
to
quickly
introduce
yourself.
C
B
A
Thank
you
for
the
introduction.
I
remember
in
december,
2021
paritosha
and
proto
joined
us
to
talk
about
the
kinzuki,
with
the
public
testnet
launch
and
from
the
last
consensus
layer
meeting.
It
is
known
that
soon
we
will
have
another
public
test
net
with
kiln
v1
specs.
The
timing
can't
be
better
than
this,
and
I
hope
with
this
talk,
we
will
learn
about
canon
test
net
specs
and
how
to
participate.
A
B
Sounds
good,
so
hey
everyone,
let's
just
start
with
a
brief
slide
on
what
the
merge
is
to
begin
with.
We
have
mainnet
ethereum
today
and
we
have
mainnet
beacon
chain
today.
The
merge
is
the
idea
of
combining
these
two
individual
chains
to
have
an
execution
and
consensus
layer
so
that
we
have
the
unified
ethereum
going
forward,
and
the
consensus
in
the
ethereum
of
the
future
would
be
proof
of
stake.
B
B
B
B
This
was
with
the
kinsuki
specs
that
we
launched
back
then
the
testnet
itself
had
really
well.
We
had
a
transaction
browser
that
mario
said
developed
that
triggered
two
three
edge
cases
that
led
to
multiple
client
bugs.
I
think
there
wasn't
a
single
client
that
didn't
have
something
or
the
other
going
on,
and
that
was
great.
That's
exactly
what
we
wanted
kinsuki
to
do
to
find
edge
cases
and
that
worked
out
really
well.
For
us.
B
B
Also,
kinsuki
allowed
all
the
client
teams
to
merge
their
merge
code
base,
which
till
then
was
in
different
branches
onto
their
stable
branches
or
their
developer
branches.
So
to
say-
and
this
is-
this
is
a
good
sign-
a
lot
of
cleanup
happened.
They
were
able
to
continue
testing
on
kinsuki
and
it's
a
great
step
in
the
right
direction.
B
I've
just
put
some
brief
stats
there.
We
actually
had
over
a
million
transactions,
500
000
blocks
a
ton
of
addresses
that
were
created
so
on
all
metrics
kinsuki
was
doing
quite
well,
and
that
brings
us
to
where
we
are
right
now.
So,
as
we
said,
16
december
was
when
kitsuki
was
launched.
Kiln
should
be
about
the
10th
of
march.
B
We
should
have
almost
all
fans
participating
and
we
have
the
spec
versions
that
are
required
to
join
the
tesla
and
kiln
will
be
the
last
public
test
net
that
we
will
have
before
we
start
merging
the
existing
public
test
nets
like
rinka
b
robson
golly
seboya
stay
tuned
into
the
to
the
alcord
app
calls
to
figure
out
when
those
things
would
happen,
as
well
as
what's
the
status
of
each
of
those
test
nets,
but
that's
why
kiln
is
really
really
important.
Watch
out
on
twitter
to
join
it.
B
B
B
One
of
the
big
things
that
will
be
added
in
kiln
is
the
implementation
of
jwt
based
authentication
so
between
the
engine
api,
as
well
as
the
consensus
layer
now
you're
going
to
have
an
added
layer
of
authentication
and
and
hopefully
again,
if
nothing
goes
wrong.
This
will
be
the
last
test
net.
We're
also
aiming
to
have
a
really
long
proof
of
work
phase
so
that
whoever
wants
to
join
can
run
their
miners
can
deploy
all
of
their
contracts
and
actually
see
what
happens
during
the
transition
as
well.
B
In
the
past
test
nets
it
spin
a
bit
tight,
like
configs,
were
released
and
like
if
they
were
released
at
2
pm,
then
the
merge
happened
at
9
10
pm,
and
then
people
just
were
dealing
with
post
merch
test
net.
Now
we
want
to
give
you
a
couple
days
to
actually
play
around
with
the
proof
of
work
test
net
before
it
goes
through
the
merge
and
then
you're
gonna
have
a
post
merge
test
net.
B
C
C
Basically,
it's
it's
code
to
create
and
sign
bad
blocks.
So
whenever
we
get
so
so,
that's
in
the
new
in
the
new
proof
of
stake
mechanism,
there's
some
mechanism
on
how
to
get
how
to
know
who's
the
next
signer
and
when
this
next
signer
or
when
this
next
block
producer,
gets
the
message
that
he
should
produce
a
block.
C
He
takes
some
of
the
transaction
that
that
he
has
locally
puts
them
in
a
block
executes
the
block,
signs
the
block
and
then
sends
the
block
to
all
all
the
other
participants,
and
this
blockbed
block
generator
basically
takes
this
fully
verified
and
final
block
and
then
modifies
it,
and
we
use
some
randomness
to
create
really
interesting
blocks.
For
example,
we
we
replace
the
the
field
for
for
the
gas
limit.
C
We
replace
the
field
for
the
gas
limit
with
some
extraordinary
value,
and
then
this
should
this
block
should
be
rejected
by
the
network
or
we
replace
a
field
with
a
zero
value
or
what's
what
what
triggered
the
most
bugs
was
replacing
a
field
with
another
valid
value.
So,
for
example,
you
replace
the
the
hash
of
a
block
with
the
previous
hash,
and
this
due
to
some
some
bugs
in
in
caching.
C
So,
basically,
when
we,
when
we
fork
a
test
net,
we
know
okay,
this
test
net
is
going
to
to
fork.
At
that
point,
everyone
has
the
same
software,
no
one
keeps
mining
the
chain,
and
but
what
we
can
do
is
is
pretend
that
all
the
nodes
will
stop
at
a
certain
point
and
then
continue
on
the
proof
of
stake
chain,
and
we
will
just
ignore
the
proof
of
work
chain
that
that
that
works,
that
that
the
public
uses.
C
So,
for
example,
what
we
did
was
we
create
created
the
girl,
like
we,
we
shadowfork
that
girly
chain.
Basically,
we
went
and
deployed
a
contract
on
gurley
with
all
the
validators
and
all
the
addresses
for
the
validators
and
everything,
and
then
once
the
td
ttd
was
hit,
then
our
nodes,
those
nodes
that
we
configured
to
to
follow
the
proof
of
stake
chain
after
a
certain
block.
C
Since
some
of
our
nodes
are
still
connected
to
the
other
nodes
on
gurley,
we
will
also
still
get
some
of
the
transactions
that
that
are
executed
on
girlie.
They
might
be
in
in
a
different
ordering,
and
some
of
them
might
fail
because
of
that,
because
the
state
will
differ
slightly
from
what's
on
gurley,
but
we
can
have
like
real
transaction
load,
and
so
we
plan
to
also
do
this
with
a
mainnet.
C
Of
course,
we
cannot
just
go
on
mainnet
and
then
deposit
create
the
deposit,
a
different
deposit
contract
and
deposit,
multiple
thousands
or
millions
of
ether
in
it,
because
if
we
do
that
on
on
gurley,
it's
fine
because
gurley
eath
is
basically
basically
abundant.
But
we
cannot
do
that
on
mainnet.
So
there
are
versions
of
the
of
the
deposit
contract
that
work
either
with
esc
20
tokens
or
that
even
work.
Without
a
token.
C
So
you
can
just
say:
hey,
I'm
going
to
send
my
32
eth,
but
you're
not
actually
sending
anything,
and
this
is
the
validator
that
I'm
going
to
that.
I
want
to
add
to
to
the
chain
and
this
shadow
forking,
it's
especially
useful
for
for
testing
sync,
because
on
these,
these
def
nets
and
test
nets
that
we
spin
up.
We
don't
have
that
much
state.
C
Basically,
they
they
they,
we
start
them.
They
run
for
a
couple
of
weeks.
They
run
for
a
couple
of
months,
maybe
but
no
one,
no
one
like
really
uses
them,
but
the
real
test
nets
and
the
especially
especially
mainnet,
is
used
quite
quite
a
lot
and
so
the
state
of
so
the
state
is
all
the
contracts,
all
the
transact,
all
the
all
the
addresses
all
the
accounts.
C
So
the
optimistic
sync
is
a
new
feature
in
the
consensus
layer
because
basically
they
need
to
synchronize
the
chain
forward
up
to
the
newest
head
without
without
the
execution
layer
being
able
to
verify
the
blocks,
and
this
is
because
the
execution
layer
takes
a
long
time
to
execute
all
of
the
blocks.
So
the
the
the
consensus
layer
will
just
sync
to
the
sync
to
the
to
the
head
and
then
tell
us
hey.
This
is
the
head.
Please
try
to
sync
to
this
so
that
the
consensus
layer
will
tell
the
execution
layer.
C
Please
please
sync
to
this,
and
then
we
will
start
syncing
up
to
this
point
and
if
we
cannot
verify
it
because
some
block
in
between
was
invalid,
for
example,
then
we
say
hey.
We
cannot
do
this
and
then
the
consensus
layer
has
to
find
another
chain,
that's
actually
valid
so
and
because,
because
kenzugi
or
or
the
these
merch
definites,
they
don't
really
have
much
state.
They
have
like.
C
C
Yeah
and
then
we
had,
we
have
also
some
other
ideas
for
testing
we're,
doing
we're
doing
we're
doing
like
manual
tests,
we're
doing
these
test
nets-
and
we
also
have
hive
hive
is
a
is
a
really
cool
platform
for
integration
and
regression.
Testing
we've
been
using
this
in
in
eth1
or
in
the
execution
layer.
For
for
a
couple
of
years
now
we
actually
develop
also
developed
this
platform
and
it
has
different
types
of
tests.
C
We
have
static
test
cases,
so,
for
example,
we
have
test
cases
like
execute
a
transaction
with
a
random
op
code.
The
random
opcode
is
new
after
the
merge,
and
so
we
can.
We
can
have
test
cases
that
verify
that
this
that
this
random
op
code
is
implemented
correctly
or
we
have
things
like
create
a
contract
and
then
in
the
same
transaction
self-destruct
the
contract.
C
So
we
have
different
synchronization
mechanisms.
We
have
the
full
sync:
we
used
to
have
the
fast
sync.
We
have
the
snap
sync
in
guest.
Now
we
have
the
we
used
to
have
the
warp
sync
in
open
ethereum,
so
we
made
sure
that
that
different
clients
can
synchronize
from
each
other
and
we
also
have
synchronization
tests
post
merge.
So
that's
that's
really
cool
and
it's
it's
really
nice
for
execute.
C
So
so
right
now
we
only
have
the
we
have
a
big
test
suit
for
test
suite
for
for
execution,
layer,
clients
around
45
tests,
and
we
there's
also
something
for
the
combination
of
execution,
layer
and
consensus
layer,
client,
but
this
is
currently
still
being
developed,
and
the
cool
thing
is
that
whenever
we
do
a
release
or
whenever
we
we
push
to,
I'm
not
sure
what
the
what
the
condition
actually
is.
If
someone
pushes
to
master
something,
these
tests
are
ran
automatically
and
can
prevent
regressions.
C
The
idea
behind
this
is,
you
can
spin
up
different
different
dockerized
clients
and
they
connect
to
each
other
and
they
they
run
some
test
net
configuration
and
they
can
be
used
for
one
of
tests.
They
can
also
be
used
for
regression
tests
and
one
really
nice
thing
is
you:
can
you
can
do
it
in
your
ci?
C
You
can
you
are
able
to
simulate
load,
you
can
have
a
transaction
spammer
you,
you
can
have
block
spammers,
you
can
have
network
network
spamming,
we
can
simulate
periods
of
non-finalization,
so
we
can
say:
okay,
we
are
going
to
split
or
we
are
going
to
shut
off
60
of
the
network
or
we
can
say.
Okay,
we
are
going
to
cut
the
network
exactly
in
half
one
of
the
one
of.
C
B
Yes,
just
to
clarify
those
are
all
the
network.
Stuff
is
the
future
plans,
but
we're
hoping
that
we
can
start
testing
those
sooner
rather
than
later,
and
also
the
scheduled
ci
based
run
is
awesome
because
before
we
even
think
about
touching
mainnet,
we're
gonna
have
at
least
a
couple
hundred
private
destinations
go
through
the
merge.
So
you
can
be
really
really
sure
that
a
combination
of
clients
will
be
able
to
do
it.
C
Yes,
exactly,
that's
that
and
that's
that's!
That's
really
cool
like
the
more
often
we
we
test
this
transition,
the
better,
I
think
that's
the
one
of
the
big
risks
is
during
during
this
merge
transition
and
if
we
can
run
it
as
much
as
possible
with
a
different
client
combinations,
then
it's
it's
really
nice.
C
I
recently
started
this
testing
the
merge
effort
and
we
had
a.
We
had
a
test
program
for
for
kinsugi
and
we
want
to
do
another
test
public
testing
program
for
the
kiln
test
net.
We
have
some.
We
we
like
we,
we
collected
and
brainstormed
some
example
test
scenarios
in
the
document
that's
linked
there,
and
these
are
things
like
we
want
to.
C
C
B
Is
just
a
small
shout
out
in
case
anyone
is
still
on
the
fence
as
to
how
difficult
it
is
to
join
the
test
nets.
The
folks
at
staker
eats
docker
atm
on
arm.
I
have
all
written
guides
made
predefined
images,
auto
tools.
I
think
the
theme
on
arm
guys
even
have
an
ami
on
aws.
So
it's
as
easy
as
launching
whatever
you
call
launching
an
instance
on
aws
and
you
suddenly
have
all
the
tooling
required
to
join
the
testnet.
B
C
So
yeah
exactly
and
I
I
believe
if
staker
also
did
at
least
one
video
on
how
to
do
it,
and
so
it's
I
think
it's
it's
it's
pretty
nice.
I
can
probably
join
the
network
in
like
10
to
15
minutes.
I
think
someone
less
experienced
can
can
probably
it
it's
at
most
half
an
hour.
If,
if
you
want
to
join
it
and
you
will
learn
a
great
deal
and
it's
it's
really
nice.
C
Raphael
yeah
right
so
peritosis
is
taking
care
of
the
infrastructure
of
like
the
the
the
boot
nodes
and
and
the
the
nodes
most
of
the
nodes
running
running
the
consensus
and
raphael
is
taking
care
of
things
like
a
block
explorer
the
the
public,
rpc
and
and
stuff
like
this.
So
it's
it's,
it's
they're
doing
really
great
work
and
it's
really
easy
to
so.
B
C
C
The
testing
the
merge
channel,
where
the
there's
a
lot
of
discussion
going
on,
and
if
you
have
more
specific
questions,
then
in
the
r
d
discord
server
we
have
the
testing
channel.
We
have
different
testing
channels
so
make
sure
you
are
in
the
merge
section,
the
testing
channel
and
you
can
ask
your
questions.
There.
B
A
C
C
Yes,
yes,
that's
that's
better,
and
after
kiln
we
are
depending
on
how
kiln
kill
goes
we
already
and
and
also
like.
There
might
be
some
small
spec
changes
and,
depending
on
what
these
spec
changes
are,
we
might
need
another
round
of
test
nets,
but
we're
also
looking
into
how
and
when
to
when
to
merge
or
transition
the
test
nets.
The
the
the
big
test
nets
like
gurley
and
rinkeby,
robson
sepulia
over
to
proof-of-stake,
and
after
these
are
done,
then
we
can
merge
the
mainnet
and
the
yeah.
C
A
Well,
thank
you
so
much
for
the
presentation
and
I'm
amazed
to
see
that
the
amount
of
effort
that
is
being
put
behind
the
scene
to
build
a
safe
network
for
public
use,
kudos
to
the
entire
client
deaths
and
testing
team
for
this
work,
and
I
would
also
like
to
mention,
apart
from
the
respect
for
the
development,
related
work,
different
development
related
skills.
I'm
a
big
fan
of
maurice
and
paritos
tweeting
skill.
I
mean
if
we
have
to
create
memes.
Why
not
positive
hashtag
testing
the
merge.
C
B
A
C
Some
of
them
didn't
didn't,
really
didn't
really
do
stuff,
but
quite
a
quite
a
few
of
them
actually
ran
notes,
send
transactions
interacted
with
the
network
and
and
did
their
part
of
for
testing
the
merchant
making
our
lives
easier
and
that's
really
great
community
effort.
So
thank
you
for
everyone
already
participating
and
testing
the
merch
and
looking
forward
to
round
two
and
kiln.
A
Of
course,
I
I
can
say
this
for
sure,
because
I
I
mean
I
have
been
actively
involved
in
upgrades
and
everything,
but
I
actually
missed
out
this
hashtag
and
one
of
my
interns
who
actually
documented
after
then
looking
into
marius
and
paris
hackmd
file,
he
said
ma'am.
We
want
to
make
it
hashtag
testing
the
merge,
because
that's
what
the
event
is
all
about.
That's
what
the
motion
is
all
about.
So
I'm
happy
that
people
are
joining
in.
A
A
B
Who
I'm
not
even
sure
if
we've
decided
in
which
order
we
want
to
fork
the
test
nets
yet
so
gurley
might
not
be
first,
it
might
be
robston
or
one
of
the
whichever
test
that
we
like
the
least.
I
guess
just
that
way,
but
I
I
would
say
we're
gonna
run
it
up
until
we
have
no
more
braking
changes
for
kill
for
the
spec.
A
B
C
C
They
companies
usually
like
to
run
like
to
run
validators
and
like
to
set
up
the
infrastructure,
and
then
they
run
it
for
like
half
a
year
or
six
months,
nine
months
or
something
like
this,
and
then
they
forget
about
it
and
then
one
day,
their
infrastructure
crashes,
and
they
just
don't
bring
it
back
back
up.
So
we
we
need
to
make
sure
that
these
test
nets
that
are
like
bigger
test
nets
like
girly,
that
they
are
actually
being
run
by
by
people
that
really
care
about
it.
B
Most
likely
for
gurley,
we
probably
merge
it
with
prata,
where
we
have
all
the
different
client
teams
running
a
bunch
of
validators,
but
then
we'd
probably
have
to
onboard
the
execution
clan
teams
as
well
such
the
theodon
validators.
I
don't
know,
there's
like
a
bunch
of
open
questions
that
still
revolve
around.
Like
figuring
out
finer
points.
A
Yeah
right,
I
think
one
of
their
edited
representatives
at
248.
He
did
mention
that
the
question
was
like.
Would
it
be
like
previous
fortnightly
basis
and
it
sounds
like
more
or
less
yes,
yeah,
probably
yeah.
Thank
you.
Moving
on.
My
next
question
is
about
specs.
I
understand
the
ken
public
test
net
is
kiln.
V1,
spec
and
v2
is
already
out
there.
So
a
question
from
redditor
user
named
blackout24
is
how
likely
our
spec
changes
after
kin,
v2
or
will
kiln
essentially
be
the
main
expectation.
B
C
C
B
B
Oh
there's
actually
one
other
small
point:
mario's
mentioned
that
two
would
be
able
to
communicate
to
ask
for
the
current
status.
That's
this
heartbeat
functionality,
at
least
for
home
stakers.
That
should
give
you
a
bit
more
calmness,
because
both
your
execution
and
consensus
layer
will
talk
to
each
other
and
make
sure
that
they
are
set
up
properly.
A
My
next
question
is
about
tools
and
infrastructure.
I
remember
the
presentation
to
talk
about
some
of
the
tools
around
and
being
a
cat
header.
I'm
also
aware
of
some
of
the
initiatives
that
are
being
done
by
the
ethereum
foundation
and
client
teams
in
terms
of
making
this
information
more
public,
such
as
a
community
meeting,
and
all
I'm
trying
to
understand
the
the
community
participation
in
terms
of
tools
that
they
are
bringing
us.
For
example,
we
talked
about
kurtosis.
A
B
So
one
of
the
nice
things
about
the
kurtosis
tool
is
that
it's
an
ethereum
merge
module.
This
is
its
own
github
repo
and
you
can
write
tests
for
it.
So
if
anyone
is
interested
in
getting
involved,
writing
tests
using
that
module
would
be
one
of
the
most
high
impact
things
that
you
can
do
to
help
us.
B
But
besides
that,
yeah
of
course
run
it
locally.
If
you
guys
notice
that
clients
aren't
behaving
properly,
then
please
do
report
it.
They
have
a
functionality
where
you
can
just
dump
all
the
logs
at
once.
So
you
can
just
upload
one
file,
one
zip
file
to
us,
and
then
we
have
a
complete
idea
of
what
your
state
was.
C
A
Well,
thank
you.
I
mean
like
this
seems
really
interesting,
that
the
research
and
the
tools
that
are
also
brought
up
by
the
community
to
help
out-
and
I
think
that
concludes
all
the
lists
that
we
have
received
from
the
reddit,
and
I
see
some
questions
are
already
there
in
the
chat
alita
more.
If
you
have
microphone,
would
you
like
to
go
ahead
and
share
that.
A
C
So
the
benefit
is
that
we
don't
have
to
like
spend
six
months,
thinking
about
the
specification
and
then
just
start
implementing
it.
So
the
the
specification
right
now
is
pretty
solid.
There's
like
minor
changes,
for
example,
this
renaming
of
random
to
prefer
endow,
is
something
that
could
have
been
done
or
could
have
been
just.
We
could
have
just
not
do
it
until
the
merge,
but
I
think
it's
it's
nice
to
to
change
it
and
we
are
still
able
to
do
these
changes.
C
B
C
Yeah
and
like
we,
we
we
wouldn't,
we
wouldn't
do
less
test
testing
if
the
changes
would
be
the
same.
Basically,
the
the
the
changes
also
force
us
to
to
do
more
testing,
because
because
we,
whenever
there's
a
spec
change,
we
test
all
the
things
that
we
previously
tested
again
and
then
and
then
we
also
test
the
new
changes
so
so
yeah.
B
Ketosis
would
also
be
something
that
would
help
us
build
integration
tests
to
make
sure
that
there's
no
regression
in
the
ci
also
chaos
engineering
would
be
a
cool
thing
to
have
some
tools
working
on
that
over
the
long
term,
so
that
we
can,
if
we
find
something,
still
fix
it
post
much
right
and
that's
also
one
of
the
points
just
because
the
merge
is
done
doesn't
mean
the
testing
would
stop.
We'd
still
want
to
test
from
as
many
avenues
as
possible
to
make
sure
that
we're
not
messing
up
mainnet.
C
Yeah
yeah
and
I
think,
like
the
the
important
part
after
the
merge,
is
not
the
merge
transition
anymore,
but
so,
but
we
will
we
will
modify.
We
will
either
like
leave
the
tools
as
this
and
just
focus
them
more
on
the
post
match
part
or
we
will
just
modify
them
in
a
way
that
they
will
already
start
with
a
merged
test
network
and
then
and
then
go
from
there.
But
these
things
like
splitting
splitting
the
network
or
shutting
down
validators
or
introducing
lag
or
between
validators.
C
D
C
The
I
think,
the
the
the
graphic
that
we
have
is
a
bit
outdated.
So
we
have
the
the
difficulty
format
yeah
the
difficulty
bomb
by
june
july,
and
we
hope
right
now.
The
plan
is
not
to
not
to
delay
the
difficulty
bomb
and
have
the
merge
by
then,
but
we
cannot
be
sure
if,
if
like
the
most
important
thing
is
security
and
if
we
take,
if
we
need
three
more
months
or
six
more
months
to
get
this
thing
out
securely,
then
we
would
rather
take
this.
C
A
That's
totally
understandable,
I
mean
the
effort
that
that
is
being
put
here
should
should
be
in
in
the
right
direction.
We
don't
want
to
rush
things
just
to
end
up
breaking
it
out,
so
yeah
taking
time
is
a
good
thing.
All
right
are
talking
about
time.
We
are
very
close
to
the
end
of
the
meeting.
So
if
anyone
else
has
any
final
question
for
guest
speakers
today,.
C
C
We
need
you
guys
to
go
to
kiln,
publish
your
publish,
your
dap,
make
sure
everything
works,
make
sure
every
everything
works
before
the
merge
make
sure
every
everything
works
after
the
merge
make
sure
all
these
so
that
there
aren't.
There
aren't
many
changes
that
you
that
you
have
to
take
a
look
at,
but
it's
it's.
It's
crazy
important
that
you
that
you
do
the
only
like
one
change
that
is
still
coming.
That's
not
really
spec
right
now
is
changing
the
semantics
around
get
block
by
number.
C
So
you
can
query
the
node
for
the
finalized
block,
so
you
know
that
this
block
cannot
be
reorgged
and
yeah,
but
the
the
spec
for
that
is
is
not
really
out
yet.
So
that's
one
of
the
changes
that
that's
still
going
to
to
be
done,
but
if
your
smart
contract
depends
on
the
difficulty
op
code,
then
you
really
need
to
need
to
check
if
it
will
not
work
after
the
merge,
because
we
reuse
the
op
code
that
is
currently
difficulty
for
the
random
op
code
and
so
yeah.
You
need
to.
C
You
need
to
be
careful
with
this
and
yeah
if
you,
if
you
want
to
just
do
some
good,
if
you
want
to
be
part
of
this
community,
if
you
want
to
get
started
in
in
in
core
development,
I
think
testing
is
the
is
the
best
way
to
do
it.
It's
it's
pretty
easy
and
you
can
get
started
doing
very
simple
tasks
and
you
can
learn
quite
a
lot
about
the
architecture
about
what's
going
on
and
so
yeah.
B
Join
us
definitely
and
if
you're,
at
some
hackathon
and
you're
looking
for
a
test
net
to
deploy
something
on
use,
can
easiest
don't
bother
with
those
girlies
ring
to
be
whatever
it's
hard
to
get
tested.
Either
we
have
a
nice
faucet,
it's
almost
always
up.
If
that's
not
enough
hit
up
hit.
One
of
us
up
we'll
make
your
wheels
problem
at
all.
If
your
hackathon
organizer
reach
out
we'll
give
you
a
bunch
of
ether
to
hand
out
we
can,
we
can
work
out.
B
All
of
that
also
one
other
thing:
trent
and
tim
organize
a
merge
community
call,
I
think,
once
a
month
or
something
like
that.
So
if
you're
part
of
the
infrastructure
provider
group
or
tooling
or
whatever-
and
you
have
questions,
feel
free
to
join
those,
if
you
have
concerns,
feel
free
to
join
those
yeah
just
join
participate.
A
That's
right,
that's
the
goal
here
and
yes,
all
these
meetings
at
the
community
meeting
are
available
on
a
helium
card
holders.
Youtube
that's
organized
once
a
month
and
one
point
that
monies
mentioned
about
using
the
difficulty
opcode.
So
we
had
recorded
this
episode
with
the
mikhail
kalaninen
for
eip
439.
I
believe-
and
it's
it's
like
he
has
tried
to
explain
it
in
a
very
good
way
and
of
course,
people
if
you
are
using
it,
stop
using
it
and
reach
out
to
developers
for
any
help
or
support.
You
need.
A
Having
said
that,
I
strongly
believe
sharing
information
is
a
key
to
public
engagement
and
availability,
offer
details,
help
in
community
participation
for
this
decentralized
world.
So,
on
behalf
of
ethereum
categories,
I
thank
all
the
guest
participants
and
especially
to
marius
and
baritos
for
taking
out
time
to
talk
about,
kill
and
the
merch
testnets.
A
If
this
helped
help
others
hit
like
and
share
increase
the
reach.
Should
you
have
any
question
share
it
with
us?
Leave
it
on
comment
or
reach
us
on
ech
discard
subscribe
to
ech
youtube
channel.
If
you
haven't
done
it
already
see
you
next
time
with
another
interesting
talk
till
then
keep
watching
keep
sharing
your
love
with
helium
chat
headers.