►
From YouTube: Kurtosis testing: Breakout room meeting 19
Description
Agenda: https://github.com/ethereum/pm/issues/482
Meeting links:
- https://github.com/kurtosis-tech/eth2-merge-kurtosis-module
- https://github.com/skylenet/ethereum-genesis-generator
- https://github.com/skylenet/ethereum-genesis-generator/tree/goerli-shadow-fork
- https://github.com/skylenet/ethereum-genesis-generator
pari: If you have a client you want to build, use this repo: https://github.com/parithosh/merge-client-builds
pari: If you need permissions in that repo, lemme know
pari: curl --location --request POST 'http://http://173.230.149.32:8545' --header 'Content-Type: application/json' --data-raw '{ "jsonrpc":"2.0", "method":"eth_getBlockByNumber", "params":[ "latest", false ], "id":1 }'
- https://github.com/parithosh/nightly-kurtosis-test/blob/main/.github/workflows/kurtosis.yml
- https://github.com/kurtosis-tech/tx-fuzz
- https://docs.kurtosistech.com/
A
B
Yeah,
basically,
I
can
give
kind
of
like
a
little
bit
of
a
deeper
dive
into
kurtosis
for
those
who
are
interested
and
for
those
who
are
watching
this
in
the
future.
Just
as
really
quick,
I
guess
recap:
kurtosis-
is
a
platform
for
doing
development
and
testing
for
distributed
systems.
The
idea
behind
kurtosis
is
that
you
can
leverage
your
docker
engine.
D
E
A
B
Okay,
so
welcome
everybody
thanks
so
much
for
showing
up
to
our
little
little
working
session.
My
name
is
kevin.
I'm
the
cto
of
kurtosis,
you
might
know
me
as
amy
breese,
on
your
discord
channel,
because
I've
probably
bothered
every
single
one
of
you
on
your
discord.
Apologies
for
the
pest
drink
that
was
me
trying
to
get
everything
working
with
the
ethereum
module,
so
to
kind
of
give
a
quick
recap
about
what
crystal's
is
and
what
we're
doing.
B
B
I
guess
you'd
call
it,
which
contains
two
halves,
contains
the
execution
layer,
clients
up
to
your
specification
as
many
as
you
want,
with
various
different
flags
and
logging
levels
and
such
like
that
and
then,
after
the
execution
layer,
clients
are
up
and
running,
it
will
create
a
cl
clients,
a
cl
client
network,
and
then
that's
going
to
be
with
various
different
configuration
parameters
that
you
please.
In
order
to
get
things
working
and
then
after
you
have
both
of
these
running,
you
can
just
leave
the
network
running
and
it
will
eventually
perform
the
merge.
B
B
So
kurtosis
is
a
client
and
that
client
is
installed
by
a
package
manager
I'm
on
mac.
So
you
could
just
do
brew,
install
kurtosis
tech,
slash,
kryptosis
class.
I
believe
I'm
not
remembering
the
exact
incantation
right
now,
but
we
have
installation
docs
right
here,
I'll,
go
ahead
and
send
to
the
group
yeah.
Here
we
go
we're
just
text,
slash
tap,
slash,
kutosa
supply
and
that
will
get
you
kurtosis
on
your
machine.
B
B
So
once
you
have
once
you
have
critosis
installed
on
your
machine,
we
ask
you
to
make
a
an
election
about
whether
you'd
like
to
opt
into
our
metrics
program.
The
you
know
obviously
feel
free
to
make
whatever
choice
you
want
on
that.
We
use
the
metrics
only
for
product
analytics,
so
making
sure
that
we
know
what
what
things
people
are
using
and
what
things
are
worth.
Throwing
engineering
points
behind.
B
So
once
you
have
kurtosis
on
your
machine,
you
are
going
to
have
the
kurtosis
clyde
right
here
and
that
kurtosis
clay.
The
first
entry
point
that
you
work
with
with
the
ketosis
clay
is
enclaves,
so
enclaves
are
like
little
walled
gardens
that
you
put
your
distributed
networks
inside
of
and
very
concretely
what
this
is
is.
This
is
a
docker
network
under
the
covers
that
you
start
all
the
different
machines,
all
the
different
services
inside
of
and
I'm
a
big
drawer,
I
like
to
doodle.
B
B
So
inside
of
my
docker
engine,
I
have
created
a
docker
network
and
we
can
see
that
this
docker
network
corresponds
to
the
name
of
my
enclave
id
here.
So
kurtosis
provides
like
a
couple
of
tools
for
for
doing
things
with
enclaves
like
you
can
we
can
go
ahead
and
remove
this
enclave
as
well.
Kurtosis
will
go
ahead
and
do
that
and
if
you
had
any
services
inside
of
it,
it
would
blow
that
all
away.
B
So
that's
kind
of
the
the
enclave
concept,
so
enclaves
will
be
the
the
most
macro
unit
object
that
you'll
deal
with
so
now
for
the
ethereum
context.
We
have
a
module,
we
call
it.
Modules
in
kurtosis
are
like
packaged
set
of
instructions
to
the
kurtosis
engine.
So
once
you
have
an
enclave
of
course,
you
want
to
start
stuff
in
it
and
that
stuff
that
gets
started
are
going
to
be
containers.
B
Maybe
we
have
lighthouse,
and
maybe
we
got
nimbus
as
well,
and
you
would
start
all
these
services
inside
of
kurtosis,
and
you
could
do
this
manually,
so
we
do
have
an
sdk
for
communicating
with
the
engine.
So
you'd
have
a
little
bit
of
like
a
library
and
go
or
in
touchscript
that's
out
here
that
lives
in
whatever
code
you
want,
and
then
that
would
communicate
with
the
kurtosis
engine
and
you
could
basically
write
all
the
the
code
necessary
to
set
this
up.
B
But
then
you'd
have
to
have
that
code,
maybe
as
a
library
on
your
machine,
maybe
you'd
write
it
as
a
bash
script
as
a
bunch
of
client
commands,
it
gets
a
little
bit
unwieldy.
So
we
have
this
notion
of
modules,
which
very
concretely
are
a
little
tiny,
grpc
server
that
responds
to
one
command
which
is
execute,
and
that
is
a
container
as
well,
and
what
that
will
do
is
that
will
package
up
all
the
instructions
to
the
kurtosis
engine
so
that
all
this
stuff
is
encapsulated
inside
of
the
module?
B
Okay,
so
this
module
is
the
main
thing
that
we've
been
working
on.
It's
why
I've
showed
up
in
all
of
your
discords,
to
ask
questions
about
what
are
the
flags
necessary
in
order
to
start
all
these
various
different
nodes,
all
these
different
types
of
el
and
cl
clients,
so
a
module
is
a
kurtosis
because
it
ends
up
as
a
container
a
little
tiny,
grpc
server.
B
It
is
a
docker
image
which
means
that
we
can
distribute
it
via
docker.
So
in
this
case
we
have
the
kurtosis
tech,
slash,
eth2,
merge,
kurtosis
module,
and
so
this
is
the
docker
image
that
we
use
that
we
package
the
module.
Inside
of
so
you
can
run
a
module
with
kurtosis
module,
exec
and
ketosis
module.
Exec
will
create
a
new
enclave,
it
will
launch
the
module
inside
of
the
enclave
and
it
will
execute
that
module
so
fairly
straightforward.
B
Now,
where
things
get
a
little
more
complex,
is
that
modules
can
be
parameterized.
So
in
our
case
we
have
a.
We
have
configured
the
module
to
take
in
json
that
configures
its
behavior.
So
this
is
how
you
specify
the
number
of
participants
a
bunch
of
different
information
about
the
network
that
is
getting
started
up
like
how
many
validated
queues.
Do
you
want
like
what
different
app
box?
B
We
have
a
git
repo
that
contains
all
the
code
for
building
the
module
it's
written
in
go,
and
it
is
really
you
can
it's
a
very
fancy
set
of
instructions
for
to
the
kurtosis
engine.
That's
really
all
it's
doing
so.
This
particular
module
has
is
configured
for
json
and
these
will
be
the
all
the
different
parameters
that
you
can
pass
in.
So
if
you'd
like
to
start
your
bl
node
or
your
cl
node,
you
can,
for
example,
set
different
images
here.
B
You
can
set
various
different
command
line
parameters
if
you
wanted
to
set
arbitrary
parameters
same
thing
with
the
cls
as
well,
and
then,
of
course,
like
I
said,
we
have
all
that
networking
information
here
that
you
can
set
if
you'd
like
to
set
it.
So
none
of
this
is
required.
This
is
all
optional
and
we
have
defaults
associated
with
that.
B
B
B
B
So
what
I'm
doing
here
is
I'm
just
passing
the
execute
params
to
the
module
via
a
file
that
contains
the
configuration
that
I
want,
and
that
is
this
file
over
here.
So
I've
written
this
json
file,
I
like
to
keep
it
as
a
separate
file,
rather
than
putting
it
all
in
the
command
line,
because
when
I
get
json
highlighting
I
figure
out
if
I've
missed
a
comma
or
or
something
like
that,
but
again
you
could.
If
you
wanted,
you
could
just
pump
in
raw
json
right
here
so
to
see
what
this
is
doing.
B
B
If
I
come
over
to
a
new
tab
and
I
do
enclave
ls,
we
can
see
that
we
have
an
enclave
with
that
id
just
as
expected,
and
if
we
do
kurtosis
enclave
inspect
here
we
can
see
that
this
enclave
is
starting
to
get
stuff
inside
of
it.
So
we
have
one
module,
which
is
the
module.
The
eth2
merged.
Kurtosis
modular
contains
the
logic
that
we
expect
and
it's
starting
to
start
things
inside
of
it.
So
this
pre-launch
data
generator
service
is
actually
a
container
and
that
container
is
for
generating
el
and
cl
genesis
information.
B
Then,
if
we
come
back
to
the
module
logs
here,
we
can
see
that
we
have
the
parameters
that
we
started,
the
the
module
with
and
then
the
module
is
just
going
through
the
various
different
steps
necessary
to
set
up
the
network.
So
right
here
yep.
This
is
the
generation
step
concretely
under
the
covers.
What
the
module
is
doing
is
it
is
calling
that
pre-launch
data
generator
getting
an
el
genesis
file
and
then
we're
starting
to
add
the
el
clients,
which
in
this
case,
is
only
one
guest
client.
B
If
I
was
smart,
I
probably
would
have
flipped
the
weight
from
mining
flag
to
false,
which
would
which
would
speed
this
up
at
the
cost
of
breaking
the
network
slightly.
The
cl
clients
would
behave
a
little
bit
strangely,
but
in
your
your
production
tests
or
in
your
use
case
testing,
you
can
go
ahead
and
leave
this
as
true,
which
will
basically
say
wait
until
the
el
clients
are
producing
at
least
one
block
and
then
after
they
are
producing
one
block,
we
can
go
ahead
and
start
adding
the
cl
clients.
B
G
H
I
I
can
just
expand
on
my
comment
in
the
meantime.
Since
then,
the
entire
e2
module
is
just
a
docker
image
if
any
of
you
modify
any
of
it
at
whatever
time.
If
you
want
to
add
a
test
or
ovulate,
the
most
common
use
case
has
been
in
my
client.
I've
changed
to
flag,
so
I
need
to
change
the
flag
in
the
module.
You
can
just
compile
it
yourself
with
scripts,
build
sh
and
then
test
it
and
make
a
pr
for
them
and
then
punch
it
for
you.
B
A
B
A
B
B
B
B
Or
at
least
like
when
we've
started,
we
made
the
assumption
that
we
don't
know
anything
about
how
that
docker
image
is
getting
built
so
like
which
sub-package
it
would
be
in
and
inside
of
that,
I
actually
think
that's
a
really
cool
feature
and
it's
something
that
we
saw
like
a
complimentary
company
doing
where
they
basically
like
always
push
a
doctor
image
from
every
git
commit
but
but
yeah.
Currently
we
don't
do
that.
I
I'm
just
interjecting
that
there's
another
repo
where
I've
got
workflows,
for,
I
think
four
different
clients.
If
you
have
a
client,
you
want
to
build
that.
Isn't
a
part
of
those
workflows
just
make
a
pr
or
let
me
know-
and
I
can
add
them
and
the
ci
for
this
runs
nightly.
So
you
get
an
image
spit
out
at
2
a.m.
I
B
B
B
So
we
can
see
now
that
the
el
node
has
started
mining
and
now
we've
proceeded
over
to
the
cl
client
generously
generation.
So
that's
going
to
proceed
normally.
This
is
quite
a
bit
faster
because
my
cpu
isn't
maxed
out,
but
you
guys
can
play
around
with
that
on
the
machine
and
see
how
fast.
I
know
that
you
have
the
m1
machine
and
then
things
are
going
like
insanely
efficiently.
B
So
I
I
dream
of
getting
one
of
those
one
day
so
over
here
we
were
talking
about
having
dumping
enclave
information
so
usually,
if
something
goes
wrong.
For
example,
inside
of
cryptosis,
it's
very
useful
to
be
able
to
see
the
container
logs.
So
we
have
this
command,
which
is
ketosis,
enclave,
dump
and
kurtosis
has
the
abilities,
let's
see
enclave
output
here.
So
basically,
this
is
going
to
start
dumping
all
the
information
inside
of
the
enclave
out
to
this
output
here.
B
But
if
I
go
here,
we
can
see
that
everything
that
is
currently
inside
of
the
enclave
gets
spat
out
and
we
can
see
log
files
as
well
as
the
docker,
the
docker
container,
inspect
information,
and
this
is
super
useful.
On
my
end,
for
example,
like
say,
kurtosis
does
something
that
you
don't
expect
like.
There's
an
error,
a
bug
or
something
like
that.
If
you
can
provide
me
with
this
enclave
dump
output,
that
makes
things
a
lot
easier
for
my
site.
So
I
can
see
exactly
what
pentosis
was
doing
on
the
inside.
B
Here
and
you
go
ahead
and
you
can
get
a
bash
shell,
we
try
to
be
a
little
bit
better
than
docker
and
that
will
try
to
give
you
bash
first
before
you
do
sh,
so
you're
not
always
stuck
trying
to
like
land
up
in
the
asset,
shell
and
then.
Lastly,
you
have
logs
as
well,
and
if
you
wanted
to
say,
follow
the
logs,
then
we
would
go
ahead
and
start
tailing
logs
as
the
start
showing.
B
So
maybe
you
have
a
flag
change
that
needs
to
happen,
or
maybe
there's
some
sort
of
structural
change
to
the
way
that
the
service
is
launched
inside
of
kurtosis
module
inside
of
impul
we're
going
to
have
this
participant
network
and
I'll
show
you
guys
to
find
the
separately
afterwards.
So
inside
our
participant
network,
we
of
course
have
el
ncl
and
let's
say
we
wanted
to
modify
the
gef,
the
guest
node
right.
B
So
every
single
one
of
these
files,
they
have
just
a
bunch
of
constants
here,
corresponding
to
various
different
pieces
of
information
that
we
use
for
giving
or
launching
the
file
or
launching
the
client.
So
you
know
we
can
see
minor
awards,
accounts
and
port
numbers
and
that
sort
of
thing
we
have
a
map
of
used
ports
which
are
going
to
be
the
ports
that
are
exposed
for
the
container.
B
So
kurtosis
wants
you
to
tell
it
about
hey
what
are
the
ports
that
this
container
is
going
to
be
listening
on
and
the
reason
for
that.
Actually,
let
me
do
a
deviation
here.
The
reason
for
that
is
because,
if
we
come
back
to
this
kurtosis
enclave
inspect
here,
we'll
see
that
every
single
service
here
actually
has
local
host
port
bindings.
So
you
are.
These
services
are
running
inside
of
a
docker
network,
so
they
are
isolated
by
design,
so
they
can't
interfere
with
each
other.
B
So,
for
as
long
as
this
enclave
is
alive,
I
will
be
able
to
access
this
depth
node
via
by
these
various
ports
and
I'm
going
to
do
a
and
do
the
bad
demo
thing,
which
is
I'm
going
to
try
to
remember
a
a
command
off
the
top
of
my
head
and
all
right.
Maybe
you
can
you
can
help
me
with
this
one
if
I
wanted
to
get
the
death,
if
I
wanted
to
get
the
geth
block
number,
then
I
think.
B
B
B
B
So
this
is
all
just
various
goal
logic
in
order
to
define
basically
a
class
for
those
who
come
from
java-
and
this
is
the
real
meat
and
potatoes
of
what's
going
on.
So
this
each
of
these
launchers
implements
a
launch
interface
and
that
launching
interface
contains
a
bunch
of
information
that
the
node
can
use
in
order
to
start
out
so
enclave
context.
This
is
actually
the
handle
to
the
ketosis
engine
itself.
B
So
if
you
want
to
manipulate
the
the
contents
of
the
cryptozone
clay,
this
is
how
you
would
do
it
and
the
the
this
is
the
kurtosis
sdk.
We
have
the
image
that
the
user
has
requested
to
start
to
start
this
with
we
got
the
log
level.
We
got
the
global
log
level
as
well,
which
is
all
corresponds
to
the
this
guy.
So
all
these
different
parameters
get
piped
down
to
the
launcher.
B
So
every
every
time
you've
launched
a
service
inside
of
ketosis
ketosis
says:
hey.
Please
tell
me
how
to
start
this
container,
and
if
we
go
ahead
and
scroll
down
to
this
function,
we
can
see
that
this
is
a
function
which
returns
a
function
a
little
bit
confusing,
but
this
is
the
function
that
actually
has
starts.
Your
actual
starts,
your
actual
container.
B
All
this
stuff,
which
looks
kind
of
complex,
is
actually
just
sending
is
actually
just
initializing
the
file
system
on
the
container.
We're
not
super
happy
with
the
way
that
this
api
works.
So
I
would
say,
don't
don't
fuss
too
much
about
this?
We're
actually
going
to
be
simplifying
this
in
the
near
future
or
to
make
kubernetes
compatibility
work,
and
then
you
have
a
big
command
here
to
launch
the
actual
death
node.
B
We
add
a
couple
more
flags
like
if
this
is
a
boot
node,
for
example,
add
the
boot
nodes
flag,
pretty
standard,
and
then
we
go
ahead
and
tell
kurtosis
the
information.
So
we
say:
hey
this
container
is
going
to
use
those
ports
that
we
declared
up
top.
We
have
an
entry
point
override
in
this
particular
case,
which
is
you
know
if
you're
not
familiar
with
dockerfiles.
B
So
we
come
up
back
up
here
in
the
launch
function.
We
have
this
factory,
so
the
container
config
supplier,
and
then
we
just
give
it
ticker
toasts
and
that
will
we'll
go
ahead
and
create
our
node.
All
this
extra
stuff
is
just
go
ahead
and
making
sure
that
we
wait
for
the
thing
to
become
available
before
we
return
it
to
anybody
else.
B
B
These
extra
params
things,
so
you
could
add
it
right
there.
But
if
you'd,
like
everybody,
who's
testing
with
your
clients
to
get
that
that
upgrade,
then
you
can
go
ahead
and
actually
modify
the
each
to
merge
module
itself.
So
this
is
open
source.
First,
this
is
a
critosis
tech
youth
to
merge
module
right
here
and
then
you
can
go
ahead
and
find
your
launcher.
B
I
usually
usually
just
use
the
go
to
file
I'll,
go
for
a
launcher
and
we
can
see
there's
all
these
different
launchers
with
bezu
launcher
here.
There's
gap
launcher
prism,
nimbus,
restart,
et
cetera
and
scroll
down.
Every
single
one
of
them
has
this
big
long
flags
section
here
and
you
could
be
like?
Oh
you
know
what
I
just
want
to.
I
want
to
add
another
one
of
these
right
here.
Go
ahead
and
submit
a
pull
request.
B
We
have
ci
hooked
up
for
this
repo,
so
you
don't
have
to
worry
that
you're
going
to
accidentally
break
something
because
everything
will
be
really
groovy
and
actually
pari
has
been
submitting
a
couple
prs
very
kindly
to
make
sure
that
things
are
going
ahead
and
work
so
feel
free
to
feel
free
to
modify
these.
That
means
that
anybody
who
tests
with
your
with
your
client
will
basically
have
everything
good
to
go
and
working
and
party.
B
So,
lastly,
we
can
come
back
here
and
we
can
see
that
the
module
has
finished.
So
we
were
stuck
here.
This
took
about
10
minutes
in
on
my
machine
when
I'm
not
screen
sharing,
when
I
don't
have
gold
land
open
and
everything
like
that,
I
would
say
it
takes
probably
about
one
to
two.
So
I
promise
this
is
not
this
slow
normally
and
we
can
see
that
we're
just
adding
one
lighthouse
plant.
B
We
also
add
a
transaction
spammer
in
order
to
make
sure
there
is
some
load
on
the
network
marius
if
you're
on,
if
you're
online.
Thank
you
so
much
for
helping
me
with
that,
so
that
will
just
be
submitting
just
a
bunch
of
small
transactions.
We
have
a
couple
pre-initialized
accounts
in
the
genesis
and
it
just
moves
it
just
shuffles
stuff
between
them.
It's
not
really
doing
anything
useful,
but
it
is
adding.
Is
that.
I
B
So
I'll
add
that
too
so
that
gets
started
that
gets
started
with
princesses
and
if
that's
problematic,
for
you
guys
it
would
be
pretty
simple
to
just
add
a
flag
to
the
module
that
doesn't
add
the
stuff
pretty
much
anything
any
of
this
admin
stuff,
I
guess
you'd
say,
doesn't
get.
We
could
flag
it
off
if
you
wanted
to
and
then
lastly
just
a
couple
of
debugging
tools,
so
we
have
pokemon
as
well
as
prometheus
and
grafana.
B
B
Even
though
it
doesn't
doesn't
show
it,
but
I
use
this
for
the
epoch
a
lot
and
when
you
have
a
lot
of
clients,
it's
pretty
useful
to
see
if
everybody's
on
the
same
route,
because
when
it
is
reporting
roots,
I
think
there's
like
a
little
bit
of
delay
in
torque
monitor
show.
I
think
it
might
be
like
a
small
bug.
So
if
you
have
like
say
four
clients
going
on
here,
then
you
can
see
if
they're,
all
agreeing
on
the
same
four
or
not.
B
B
We're
going
to
you're
going
to
see
pure
information
and
you're
going
to
see.
Excuse
me,
actually.
I
need
to
take
this
dashboard
link
here
and
the
module
by
the
way
you
can
think
of
modules
like
functions,
so
they
took
in
the
json
parameters
and
they
spit
out
json
parameters
as
well,
and
these
are
just
kind
of
like
useful
things.
B
In
order
to
interact
with
the
module,
we
can
really
report
any
information
that
we
want
here,
there's
probably
going
to
be
a
world
in
the
future
where,
like
the
the
pre-funded
accounts
in
genesis,
are
also
reported
here.
That's
like
really
not
a
big
deal,
so
we
can
see
right
here
that
right
now,
we've
got
the
bug,
but
once
it's
going
to
be
working,
you're
gonna
be
able
to
see
all
the
different
clients
see
what
their
beacon
head
slot
is
see.
What
their
peers
are.
We've
got
el
peers
as
well.
B
If
you
wanna,
you
know,
if
you
have
the
desktop,
you
can
go
ahead
and
feel
free
to
do
logs
right
here
feel
free
to
use
the
keto
supply.
If
you
want
shell
back
and
forth,
we've
got
the
enclave
dump
in
order
for
you
to
dump
information
about
an
enclave
outwards.
Oh
one.
Other
thing
I
should
mention
is
that
we
actually
have
the
ability
to
attach
rebels
so.
B
Here
we
can
do
ketosis
new
and
then
add
this,
and
what
this
will
do
is
this
is
going
to
start
as
a
node
repel
as
a
container
running
inside
this
enclave.
So
you
can
start
interacting
with
stuff
directly.
So,
for
example,
if
there's
anything
you
didn't
that
you
weren't
able
to
do
through
these
ports,
you
can
go
ahead
and
do
it
from
directly
inside
of
the
enclave.
And
so
you
know
we
can
see
that
we
have
this
node
rifle
here.
We've
got
tab
complete
here.
B
And
then,
if
we
do
the
process,
repo
install
grab
the
enclave
id
grab
this
and
then
pump
in
the
package
name.
Kurtosis
will
actually,
in
the
background,
install
the
package
inside
of
the
your
replica.
So
then
it
will
be
become
available
to
you
and
you
can
start
using
that
inside
of
the
nova.
So
if
you
wanted
to
like
communicate
with,
if
you
wanted
to
communicate
with
the
services
inside
of
the
enclave
from
inside
the
enclave,
then
that
would
be.
That
would
be
like
that.
B
Each
of
these
enclaves
have
a
service
id
here,
which
is
the
first
part
of
this
without
the
without
the
stuff
after
here,
and
we
can
see
that
the
service
ids
are
already
available
right
here,
so
el
client,
zero,
client,
zero,
etc.
When
you
are
active
when
you
were
working
inside
the
enclave,
so
when
you
are,
when
you
are
not
going
through
these
ports,
you
can
actually
use
the
service
id
as
a
host
name.
So
I'm
not
super
familiar
with
javascript.
B
This
guy's
there
that's
a
real
pain,
okay,
so
that
was
that
was
kind
of
a
quick
overview,
we're
getting
we're
getting
close
to
the
end
here.
So
the
last
thing
I
want
to
give
you
guys
is
just
a
couple
bits
of
docs
in
order
to
make
your
life
working
with
qriklis
is
easier,
so
all
of
our
docs
are
found
at
docs.kurtosistech.com.
B
I'll
submit
to
the
chat,
so
we
have
everything
we
have
a
quick
start,
which
is
basically,
if
you
just
want
to
be
going
from
zero
with
kurtosis,
you
actually
run.
You
do
set
up
an
ethereum
network
and
you
actually
write
a
typescript
unit
test
against
that
ethereum
network.
We
have
the
installation
docs
that
I
went
ahead
and
showed
earlier.
We
have
temp
completion
on
kurtosis
as
well,
because,
basically,
it's
a
real
pain
to
remember
everything.
B
We
have
a
using
the
cly
docs,
so
basically,
all
the
common
operations
that
you
end
up
doing
inside
of
kurtosis.
You
can
go
ahead
and
use
this
as
your
reference
for
the
ply
everything
in
the
ply
as
well
takes
in
a
takes
in
a
h-flag,
so
we
have
the
closest
desk
age.
We
got
closest
enclave,
dash
h.
We
got
those
on
clear.h
all
this
different
stuff,
to
show
all
the
different
flags,
so
anything
that
you
need
for
that.
You
can
always
pass
in
the
dash
h
and
then
we
also
have
right
down
here.
B
We
have
documentation
for
the
actual
ketosis
sdk.
So,
just
in
case
you
want
to
use
a
contestant
sdk
like
let's
say
you
wanted
to
use
kurtosis
to
write
your
own
unit
tests.
You
could
go
ahead
and
see
how
this
is
done
here,
so
you
would
always
start
with
a
kurtosis
ketosis
context.
This
is
kind
of
like
the
top-level
connection
to
the
kryptosis
engine.
B
It's
what
allows
you
to
create
enclaves,
destroy
enclaves
that
sort
of
thing
and
then,
when
you
call
create
enclave,
you're,
going
to
get
back
an
unclaimed
context
and
that
enclave
context
is
what
we
saw
before
here,
and
that
has
a
bunch
of
enclave,
specific
information,
so
you
can
go
ahead
and
load
module.
In
this
case,
the
ethereum
2
merge
module.
B
If
you
wanted
to
set
up
kurtosis
inside
of
your
enclave
inside
of
a
unit
test
which
could
also
be
done
inside
of
ci,
if
you
wanted
and
unload
module
and
all
these
various
different
things,
you
could
add
a
service
if
you
wanted,
you
can
simulate
network
repartitions.
So
this
is.
This
is
one
of
our
let's
say
a
little
bit
more
advanced
features
is
that
we
could
actually
simulate
partitions
between
arbitrary
various
different
services
that
are
going
on
inside
of
the
network.
B
It's
here
yeah
here
we
go
so
we
have
a
discord.
We
have
a
merge
channel
on
the
discord
here,
so
we
got
the
youth,
merge,
feel
free
to
show
up
there
or
just
show
up
in
general.
Again
I
am
on
on
this
discord.
I'm
kevin
today
my
handle
is
new
bruce,
which
looks
like
this
or
you
can
just
have
mentioned
with
kevin
today.
B
If
you
had
any
problems
at
all,
please
please,
please
don't
hesitate
to
scream
and
let
us
know
we
are
a
startup,
so
we're
trying
to
make
sure
that
our
product
is
as
awesome
as
possible
and
we'll
make
sure
that
we're
responding
to
you
guys
pain
if
there's
any
pain
at
all
as
possible.
So
please
feel
free
to
shout
at
us,
makes
the
product
better
and
makes
you
guys
experience
better.
So
don't
be
shy
about
that.
I
B
Yeah,
so
so
we
we
started
kurtosis
actually
in
the
avalanche
ecosystem,
so
that's
kind
of
where
ketosis
started
and
how
it
grew
out
into.
So
when
we,
when
we
started
engaging
with
pari
and
folks,
the
it
sounds
like
the
hive
from
my
understanding
of
five
hive
is,
is
focused
a
lot
on
like
unit
tests,
it's
kind
of
like
or
not
necessarily
unit
test,
but
but
mocking
very
specific
things
in
order
to
do
very
specific
scenarios.
B
So
the
you
know
when
we
were
talking
through
the
high
code
base,
I
think
there
was
something
where
there
was
one
like
drop
certain
packets
to
simulate
like
block
delays,
if
I'm
not
mistaken,
so
hive.
As
I
understand
it,
fits
very
well
for
the
use
case
of
where
you
have
like
one
to
two
clients
where
one
of
those
might
be
one
of
those
might
be
mocked,
for
example,
and
kurtosis.
Right
now
is
doing
the
like,
I
guess
you'd
say
like
the
one
to
n.
So
you
could.
B
Yes,
actually,
your
so
if
you
use
the
hostname
as
the
as
the
connection
parameter
in
between
in
between
different
nodes,
you
can
stop
so,
and
you
would
just
do
this
with
the
kurtosis
sdk.
So
you
could
do
this
with
the
node
with
the
node
reple
or
you
could
do
this
without
the
go
rep
or
anything
any
or
go
sdk.
B
You
could
shut
down
one
of
the
running
services
and
then
tell
kurtosis
to
add
it
again
and
what
with
the
same
service
id
and
then
it
would
get
the
same
domain
name
and
then
all
the
traffic
that
was
previously
erroring
when
trying
to
connect
we'll
go
ahead
and
do
that
again.
It'll,
basically
like
the
connection,
will
heal
because
the
domain
name
will
exist
again.
So
that
would
be
your
use
case
for
being
able
to
like
pull
out
a
service
and
add
it
back.
B
C
B
It
actually
wouldn't
be
that
hard
to
build.
So
if
that's
something,
that's
super
useful
for
you,
I
don't
wanna.
I
don't
wanna
promise
like
in
the
next
couple
days,
but,
like
I
think,
like
maybe
in
like
two
weeks
time
or
so,
I
think
that
could
be
something
that
we
could
definitely.
We
could
definitely
build.
C
Yeah,
this
definitely
helps
also
the
the
dev
side
of
it
instead
of
yeah
the
the
main
objective,
which
is
the
ci.
I
guess-
and
also
I
was
wondering
I
still-
I
saw
that
in
your
json.
You
have
the
way
of
add
additional
parameters,
but
I
I
saw
during
your
presentation
that
is
not
possible
to
override
existing
parameters
coming
from
launcher
or
is
something
that
we
it's
possible
to
actually
specify
completely
new
set
of
parameters
and
overriding
everything.
B
So
this
is
going
to
depend
a
lot
on
the
type
of
client
that
the
binary
is
using,
so
the
some
of
the
clients.
I
know
that
if
you
just
add
new
parameters
at
the
end,
it
will
actually
keep
the
latest
parameter.
I
think
this
might
be
a
posix
thing,
so
you
could
just
add
extra
parameters
to
override,
but
I
know
some
of
them,
some
of
them
don't
yeah.
B
C
B
I
Yes,
I
guess
you
guys
can
see
my
screen
now,
okay,
so
what
I've
done
is
I've
taken
the
kurtosis
stuff
and
tossed
it
into
a
small
integration
test,
and
this
will
be
divided
into
two
parts.
So
the
first
part
is
the
merge
client
build,
because
there's
currently
some
clients
who
I
rely
on
to
provide
me
the
latest
image.
I
I
Let
me
just
show
you
the
workflow
for
get,
for
example.
So
there's
two
ways
you
can
use
this
first
one
is
you
either
manually
run
it
and
when
you
manually
done
it,
you
can
specify
which
branch
you
want
to
use,
or
it
just
runs
on
a
schedule
at
2
am
and
when
it
runs
on
a
schedule.
It
just
default,
builds
the
merge,
kiln
branch.
So
I'd
get
the
latest
get
image
from
the
merge
kiln
branch.
I
Then
this
ci
gets
triggered
at
3am
automatically,
and
I've
basically
listed
the
base
parts
of
everyone's
docker
hub
repo
and
then
there's
a
small
script.
That
says
fetch
latest
image
tag
along
with
what
the
base
image
is
so
it'll
go
there
it'll
fetch
the
latest
image
which,
if
you
recall,
would
have
just
been
pushed
from
the
previous
ci
and
then
tosses,
all
of
them
as
environment
variables.
I
Then
I've
taken
the
kurtosis
config
as
a
template
and
that
spits
out
the
untemp
like
the
templated
version.
Essentially
so
now
we
have
the
kurtosis
config
with
the
latest
images
and
then
it
just
runs
the
module
with
the
image
and
what
they've
done
is
there's
a
wait
for
finality
check
right
now.
That's
only
only
test
so
essentially
final
lap
finality
has
to
happen
by
epoch,
5,
which
is
one
epoch
later
than
the
best
case
scenario,
and
if
it
doesn't
happen,
it
fails
so
essentially
in
about
30-ish
minutes.
I
I
switched
out
the
the
deco
image
to
the
latest
and
taco's
already
implemented
the
renaming,
whereas
get
hasn't
so
tech
get
takuget
will
actually
break
and,
as
you
can
see,
that's
exactly
what
happens
if
you
go
to
the
ci
run,
you'll
see
that
the
final
finality
didn't
happen
in
32
minutes
and
because
we
want
to
later
figure
out
what
actually
happened.
If
you
watch
this
repo
every
time
it
fails,
you
get
an
email.
I
I
Let
me
just
show
you
what
that
looks
like
and,
for
example,
cl
client
0
is
tikku,
and
if
you
go
forward,
you
can
see.
Oh
yeah
look,
underwrap
response
thrown
take
was
basically
not
happy
and
then
figure
out
what
actually
happened.
It
just
does
some
cleanup
stuff,
I'm
running
everything
self-hosted
right
now,
I've
reverted
it.
So
it
will
work
again
and
when
it
works,
it
still
dumps
the
logs
in
case
you
want
to
have
a
look
at
what
happened
and
yeah.
I
If
you
guys
want
to
stress
test
this
or
have
your
own
cis,
doing
different
combinations
like
previous
version
plus
current
version
or
something
then
just
copy
out,
this
template
change.
Whatever
you
want
to
do,
and
you
can
have
your
own
integration
test,
I
would
need
I
guess
once
we
have
the
v2
spec
deployed.
This
would
be
a
lot
more
useful
because
currently,
since
we're
changing
the
spec,
this
will
break
a
bit,
but
maybe
in
a
week
or
two
it'll
actually
make
sure
we
don't
have
any
regressions
anymore.
B
And
one
thing
to
note:
that's
really
cool
is
that
you
did
the
you:
did
the
enclave
dump
at
the
end
of
the
ci
run.
We
found
this
to
be
super
useful.
So,
basically,
if
your
enclave
fails,
if
your
ci
fails,
then
you
basically
have
the
log
package
debug.
We
do
that
inside
of
our
own
internal
ci,
for
those
assemblies.
I
I
G
Okay,
so
kevin.
I
have
a
question
follow-up
question
with
regard
to
the
development
scenario
that
enrico
talked
about,
and
so
basically
everything
is
docker
network
right,
yes
behind
the
screens,
so
it
is
possible
that
you
know,
while
the
roses
is
running
and
has
its
enclave
up,
we
can
manually
spin
up
our
own
client
and
plug
it
in
the
network
and
sort
of
interface
it
with
other
nodes.
It
should
be
possible
right.
G
B
Yeah
totally
you
can,
you
can
do
this,
you
can
do
this
either
inside
or
outside.
If
you
want
like,
you
could
actually
run
so
for
the
near
the
near
foundation
that
we're
working
with
people
run
it
outside
of
kurtosis,
pretty
commonly
actually
so
you'll
have
the
network
running
inside
of
kurtosis
you'll?
Have
those
public
ports
on
your
host
machine
that
for
connecting
to
it?
And
then
you
can
just
tell
your
node,
that's
running,
say
like
outside
of
docker,
say:
hey,
please
like
connect
to
those
ports
and
then
it'll.