►
From YouTube: ESPA Module 3F - Initializing Storage Provider’s Miner
Description
Joe Hoang (Software Engineer) with PiKNiK discusses initialization of a storage provider's miner at the Enterprise Storage Provider Accelerator (ESPA) bootcamp week that took place in February 2022.
Data is growing at an incredible speed and much of this data is archived and/or simply lost by enterprises. Our program will accelerate net-new Enterprise Storage Providers into the ecosystem, using a Web3 protocol with an impressive incentive model called Filecoin.
Learn more at:
Sign-up: https://web3espa.io
Landing Page: https://m.fil.org/espa-bootcamp
Follow ESPA:
Twitter: https://twitter.com/web3ESPA
LinkedIn: https://www.linkedin.com/company/web3espa/
A
Hi,
my
name
is
joe
hong
and
I'm
a
software
engineer
at
picnic
by
espa.
I
also
function
as
a
system
administrator
and
today
I'll
be
going
over
module,
3f,
initializing
storage
providers
node
so
first
before
we
get
into
that.
I
just
want
to
mention
the:
u
limit.
So
what
is
the?
U
limit?
The?
U
limit
is
a
command
that
allows
you
to
allocate
or
restrict
the
amount
of
resources
available
to
a
process.
A
Now
the
lotus
process,
both
the
daemon
and
the
market
node
and
the
miner-
are
all
very
intensive
processes
that
will
utilize
as
many
resources
as
you're
able
to
give
it.
So
it's
important
to
allocate
as
much
as
possible
as
it
is
a
24
7
process.
The
bottom.
I
gave
an
example
of
how
to
run
a
command
in
the
terminal:
u
limit
dash
n
and
then
the
number
1
million
24
000..
A
That
number
is
just
an
arbitrary
number
given
out
by
the
filecoin
community
and
it's
higher
than
any
amount
of
resources.
These
process
will
ever
use.
Next,
let's
discuss
the
lotus
daemon
node
before
you
can
actually
initialize
your
miner
and
go
through
the
steps
needed
before
doing
that.
You
first
have
to
connect
to
the
actual
blockchain
that
is
done
through
the
lotus,
daemon
node,
and
you
can
set
it
up
with
the
command.
A
I
give
it
down
at
the
bottom
by
connecting
to
the
blockchain
you're
able
to
send
the
messages
required
by
initializing
the
miner
that
finally
announces
to
the
network
that
hey
you're
finally
alive
and
ready
to
give
give
storage
before
we
get
into
initializing
the
miner.
The
first
thing
you
have
to
do
before
that
is
creating
your
wallets.
Now,
there's
two
required
wallets
that
the
miner
will
be
using
the
first
one
is
the
owner
wallet,
which
is
a
non-bls
wallet
and
the
second
one
is
a
worker
wallet
which
is
a
bls
wallet.
A
That
begs
the
question
of
what
exactly
is
bls.
In
simple
terms,
the
bls
is
just
a
cryptographic
signature
that
is
provided
to
these
wallets,
to
ensure
authorization
when
using
them
for
the
owner
wallet.
That's
just
the
central
location
for
all
of
your
fail.
This
field
won't
need
to
be
used,
and
it's
also
where
fail
from
the
miner
goes
when
you
withdraw
from
it.
So,
yes,
miner
will
have
its
own
wallet
separate
from
the
owner
wallet,
the
other
required
one
being
the
worker
wallet.
A
This
one
is
the
one
that
holds
fill
that
is
required
by
your
workers
during
the
sealing
process
during
their
ceiling,
once
they're
done,
they'll
have
to
submit
a
message
to
the
blockchain
announcing
that
they
have
finished
and
each
message
will
have
a
gas
feed
that
will
pull
from
this
wallet
exactly.
That
is,
however,
unless
you
create
the
other
three
wallets
that
are
recommended
by
picnic.
These
three
wallets
are
kind
of
like
subsections
of
the
worker
wallet,
those
being
the
post
wallet,
the
pre-commit
wallet
and
the
commit
wallet.
A
The
post
wallet
is
responsible
for
messages
sent
during
window
posts
and
winning
posts.
Two
very
important
processes,
if
you
recall
the
winning
post,
is
how
you
win
your
block,
rewards
and
the
window
post
is
how
you
keep
your
power
and
make
sure
you
don't
slash
and
lose
your
fill
as
such.
This
wallet
should
always
have
fill
in
it,
even
though
the
post
messages
do
not
cost
very
much.
You
should
always
ensure
that
there
is
a
good
amount
of
fail
in
here
to
ensure
your
messages
reach.
The
blockchain
next
is
the
pre-commit
wallet.
A
The
pre-commit
wallet
will
be
handled
by
the
pc1
workers
and
the
pc2
workers
and
those
are
to
send
your
pre-commit
messages.
And,
lastly,
you
have
the
commit
wallet
used
by
the
c2
to
send
the
messages
that
it
requires
during
the
commit
process.
Three
of
these
wallets
will
be
bls
wallets,
similar
to
the
worker
wallet
and
the
pre-commit
wallet,
and
the
commit
wallet
are
only
needed
when
actively
sealing
sectors,
otherwise
they
don't
need
fill
in
them
at
all.
A
When
doing
your
deals
and
then
in
general,
there'll
be
a
faster
window
post
as
each
sector
doesn't
have
to
be
read
as
long
when
it's
half
the
size
on
the
right
size,
we
have
the
pros
of
a
64
gigabyte
sector,
first,
one
being
that
you
have
a
shorter
window
post
period
as
long
as
you're,
not
doing
it
24
7..
This
is
because
each
window
post
partition,
is
only
about
2
300
sectors.
Large.
So
if
your
sectors
are
twice
the
size,
that
means
each
partition
can
handle
twice
the
amount
of
ceiling
space.
A
Now
this
benefit
does
eventually
go
away.
Once
you
reach
a
size
large
enough
that
you're
doing
window
post
24
7.,
if
you
recall
a
deadline,
is
approximately
30
minutes.
So
in
a
day,
there's
only
48
total
deadlines.
If
we
take
the
sector
size
and
the
amount
of
partitions
and
do
the
math
at
64
gigabytes
per
sector,
2300
sectors
per
partition
and
48
partitions
per
day.
A
That
gives
you
about
seven
pips
before
you
reach
maximum
partitions
and
then
for
32
gibbs,
you
just
half
that
for
three
and
a
half
pips,
once
you
reach
that
that
size
for
your
miner,
node
you'll
be
doing
window
post
24
7.
next,
for
the
pros
of
64
gibbs,
there's
going
to
be
lower
total
messages
sent
when
you're
sealing.
This
is
just
because,
since
the
sector
sizes
are
doubled,
you
have
to
send
half
as
many
messages
to
get
the
same
amount
of
power.
A
However,
there
is
a
new
feature
known
as
message
batching,
where
you
can
send
multiple
messages
at
once
for
and
only
pay
the
gas
fee
ones,
so
that
has
also
lessened
this
advantage
and
then,
lastly,
more
data
can
be
stored
in
each
sector,
so
you
don't
have
to
split
up
large
files
as
much.
For
example,
let's
say
you
get
a
deal
from
a
customer
that
is
exactly
128
gbytes
in
size
with
a
64
gigabyte
sector
size.
You
only
have
to
split
up
into
two
files
and
with
the
32
you
have
to
split
up
into
four
files.
A
Now
that
we've
gone
over
the
last
parameter,
we
can
finally
get
into
the
actual
initialization.
So
by
now
hopefully,
you've
created
your
owner
wallet
with
the
non-vls
address.
You've
created
your
worker
wallet
with
the
bls
address
and
hopefully,
you've
created.
The
three
recommended
wallets
that
were
discussed
earlier.
You've
also
decided
on
your
sector
size,
so
you
can
go
ahead
and
run
the
initialization
command
with
an
example
that
I
gave
at
the
bottom,
with
the
parameters
owner
the
worker
and
the
sector
size.
A
Now,
please
bear
in
mind
that
this
is
a
one-time
command
again,
once
you
set
these,
it
is
unable
to
be
changed,
no
matter
what,
unless
you
want
to
spin
up
a
completely
new
node
now
I
also
want
to
give
a
brief
mention
to
the
fact
that
your
initialization
time
will
also
determine
very
very
roughly
when
your
first
window
post
will
be
now.
The
goal
is
that
you're
going
to
grow
large
enough,
that
you'll
be
doing
window
post
24
7,
so
it
doesn't
matter
that
much,
however
it'll
be
kind
of
important
in
the
beginning.
A
When
you
want
to
monitor
your
window
post
and
hopefully
you
won't
have
to
wake
up
at
3
to
4
a.m,
just
to
watch
it.
So
now
that
we've
created
and
initialized
the
miner,
I
just
want
to
go
over
the
fact
that
there
are
lotus
configurations
that
you'll
need
to
configure
here.
I
gave
a
chart
that
just
has
a
brief
list
of
the
available
configs,
such
as
the
api
settings,
ceiling,
settings,
etc,
etc.
A
full
non-exhaustive
list
can
be
found
on
the
internship
documents.
However,
even
those
do
not
go
over
every
single
one.
A
So
now
that
we
finally
initialized
just
want
to
do
a
brief
recap
on
how
to
start
your
miner,
so
first
you'll
want
to
set
the
u
limit
for
your
lotus
daemon
screen.
If
you
remember
the
u-limit
was
the
amount
of
resources
available
to
it.
It
also
needs
as
much
as
possible.
You
can
go
ahead
and
start
your
lotus
daemon
and
begin
your
sync
to
the
chain.
I
should
mention
here
that
if
you
do
decide
to
sync
from
the
very
beginning
of
the
chain,
it
could
take
a
few
days
before
the
process
is
finished.
A
So
if
you
go
ahead
and
go
to
the
internship
documents,
we
do
discuss
how
you
can
import
the
latest
snapshot.
So
you
don't
have
to
go
through
that
and
it
can.
The
process
can
go
down
to
around
two
hours
after
the
lowest
daemon
screen
is
set
up
and
you're
connected
to
the
chain,
go
ahead
and
set
the?
U
limit
for
your
lotus
minor
screen,
and
then
you
can
finally
run
the
final
command.
Lotus
dash
miner
run
and
begin
your
storage
providing
journey.
A
Thank
you
for
tuning
in
today
that
was
module,
3f
initializing,
a
storage
provider
node.