►
From YouTube: ESPA Module 3A - Architecture Pt. 1
Description
Alex Fox (Architecture Lead) with PiKNiK discusses Architecture Part 1 (of 2) at the Enterprise Storage Provider Accelerator (ESPA) bootcamp week that took place in February 2022. This discussion includes introduction to the Filecoin specifications, back-ups, business continuity, high availability, servers, networking and security.
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
A
We
expected
them
to
store
the
data
that
they
send
us
and
maintain
it
over
time.
We
need
to
store
it
somewhere,
safe,
ensure
there
are
no
flip
bits,
that's
what
we're
expected
to
do,
but
on
a
decentralized
network
we
are
not
and
should
not
be
trusted
to
just
do
that.
Instead,
we
we
have
to
prove
to
the
network
that
we're
actually
meeting
our
obligations,
so
the
farcoin
spec.
A
The
specifications
is
a
comprehensive
document
that
defines
how
a
storage
provider
interacts
with
the
farcoin
network
and
how,
specifically,
we
prove
to
the
network
that
we're
meeting
our
applications,
it's
hosted
at
spec.filecoin.io
and
it's
quite
wordy,
but
it's
the
important
base
for
how
we
architect,
our
actual
storage
providers
at
the
most
fundamental
level.
The
entire
architecture
of
a
file
coin
storage
provider
is
bounded
by
at
the
spec
storage
providers,
systems
that
we
architect
and
build
have
to
meet.
A
That
requires
requirements,
and
if
we
do
fail
to
meet
the
requirements,
then
there
are
penalties
defined
in
spec
that
we
are
subject
to
a
well-architected
and
well-rounded
storage
provider.
Won't
incur
these
penalties,
but
their
presence
serves
a
valuable
function
to
the
network,
in
that
it
decentralizes
the
trust,
because
a
storage
client
knows
that
any
rational
storage
provider
is
going
to
avoid
incurring
these
penalties
and
as
storage
providers.
We
avoid
incurring
the
penalties
by
constantly
proving
to
the
network,
that
we
are
meeting
our
obligations
to
store
the
client's
data
and
to
protect
its
integrity
over
time.
A
Proof
of
replication
is
a
procedure
by
which
a
storage
miner
can
prove
to
the
farcoin
network
that
they
have
created
a
unique
copy
of
some
piece
of
data
on
the
network's
behalf.
So
that's
the
data
the
client
sent
to
us.
We
we
prove
we
we've
received
it
in
one
piece
and
prefer
application.
That's
always
used
in
the
far
con
system
to
to
generate
this
little
data.
A
A
The
proof
of
replication
is
the
initial
proof
that
we've
received
the
data
and
then
proof
of
space
time,
we'll
check
that
we
are
maintaining
a
copy
in
good
order
for
the
full
duration
of
the
deal.
So
we
need
to
perform
the
window
proof
of
space
time.
It's
called
window
post
for
short
on
a
a
random
subset
of
the
data.
A
So
the
hardware
has
to
effectively
have
the
continuous
ability
to
do
this.
There's
no
shortcuts
to
doing
it.
The
other
proof
of
space
time
that
we
perform
is
called
winning
proof
of
space
or
winning
post,
and
it's
another
audit
check
on
the
integrity
of
the
client's
data.
That's
performed
at
random
intervals,
whereas
window
post
happens
same
time
every
day.
A
A
The
bulk
of
responsibility
for
ensuring
that
our
storage
provider
is
not
slashed
by
the
network
falls
on
the
shoulders
of
the
software
that
we
use
to
interact
with
the
farcoid
network.
So,
even
though
it
sounds
quite
severe,
there
were
maybe
subject
penalties
most
of
the
time
we
we
don't
have
to
worry
about
it,
because
it's
actually
just
taking
care
of
forest.
It's
just
making
sure
that
we're
we're
doing
what
we've
agreed
to
do
network
protects
itself
from
anyone
writing
their
own
software.
A
A
A
So
in
that
sense
we
we
don't
really
need
to
be
that
concerned,
then
about
computing
winning
post,
because
nothing
bad
will
actually
happen.
If
we
don't
do
it,
but
the
difference
here,
though,
is
when,
when
we,
when
we
do
submit
winning
posts
to
the
network
within
that
30
second
window,
then
we
will
receive
a
fill
reward.
It's
called
the
block
reward,
and
so,
if
nothing
happens,
then
we
haven't
received
that
reward,
we're
incentivized
to
perform
the
winning
post
to
get
the
reward.
A
If
the,
if,
when
you
post,
is
the
carrot
really
dangled
in
front
of
us
to
make
sure
we're
performing
our
obligations
as
also
window
post
is
the
stick
that
punishes
us?
If
we
do
not
keep
both
in
mind
again,
both
are
just
taken
care
of
by
the
software
that
we
use
generally.
If
it's
architected
correctly,
we
don't
have
to
worry
about
it,
but
this
will
stop
anyone
just
playing
fast
and
loose
and
losing
people's
data,
or
anything
like
that.
A
So,
with
the
farcoin
specification
in
mind,
let's
move
on
to
the
practical
implementation
of
the
spec
using
lotus,
which
I'm
sure
has
been
talked
about.
It's
currently
the
most
feature
complete
implementation
of
the
falcon
protocol
and
in
practice
it's
what
is
is
the
the
main
one
that
that
is
used
to
store
client
data.
At
the
moment,
it's
seeing
the
most
development,
it's
the
most
advanced
software
right
now.
A
A
They
can
be
run
on
multiple
different
machines,
anything
from
one
machine
to
multiple
racks
of
servers,
it's
all
possible,
depending
on
the
aim
of
the
storage
provider,
how
much
throughput
we're
looking
for
what
capacity
we
want,
how
efficient
we
want
it
to
be,
and
this
is
why
we
can
innovate
compared
to
other
storage
providers,
because
maybe
we
have
a
better
idea
about
about
how
to
build
our
servers.
That's
more
efficient!
A
If,
if
so,
we
just
need
to
run
the
parts
of
lotus
on
on
appropriate
servers,
and
we
can.
We
can
realize
that
efficiency.
It's
important
to
size
the
different
parts
of
the
hardware
appropriately,
depending
depending
on
what
we're
going
for.
If
we
want
to
be
able
to
store
deals
more
quickly
or
if
we
want
to
be
able
to
just
store
more
storage,
it
will
determine
really
where
the
priorities
are
with
how
we
size
the
equipment
for
these
different
components.
A
A
Perhaps
we're
receiving
data
from
clients
on
hard
drives
through
the
mail.
Then
maybe
we
wouldn't
need
such
a
big
internet
connection.
We
could
just
optimize
that
way
and
we
just
need
the
ability
to
read
those
drives
quickly.
Whatever
the
priorities
are,
then
that's
that's.
What
needs
to
be
considered.
A
A
So
it's
important
there
that
we
have
well
reliable
hardware
to
make
sure
those
calculations
are
correct,
so
maybe
graphics,
cards
with
ecc
memory,
error,
correcting
memory,
servers
with
error,
correcting
memory
and
enterprise
grade
hardware.
It's
all
a
good
idea,
just
to
make
sure
there's
no
errors
in
the
software
that
would
result
in
impossible
penalties
or
problems
down
the
line
and
problems
for
the
clients.
A
The
miner
also
contains
the
lotus
markets
component
and
that
can
be
run
inside
the
e
minor
process,
or
it
can
be
split
out
to
run
separately.
The
markets
process
is
responsible
for
essentially
advertising
the
storage
providers,
the
rest
of
the
network.
It
allows
clients
to
find
the
storage
provider
and
then
send
their
data
in
online.
A
A
When
clients
want
their
data
back,
then
they
can
make
retrieval
deals
happening
through
the
markets
process
again
that
will
coordinate
that
deal
and
send
the
data
to
them,
and
because
it's
connected
to
the
internet
for
security
and
to
reduce
the
risk
to
the
proving
functions
performed
by
the
main
miner,
because
possible
software
hardware
issues
and
to
provide
increased
performance
for
markets.
It's
a
good
idea
to
run
it
on
a
on
separate
hardware.
A
Generally,
good
practice
just
keeps
things
separate
means
we
can
have
those
separate
processes
running
the
best
they
can
and
not
interfering
with
each
other
so
depending
on
requirements,
depending
on
how
important
that
is.
Maybe
we're
not
actually
looking
to
accept
that
many
deals.
Maybe
one
machine
makes
sense
and
we're
just
saving
money,
or
maybe
we
want
to
accept
a
lot
of
deals.
A
The
workers
connect
to
the
vector
the
miner,
and
just
essentially,
when
the
miner
receives
data
it
needs
to
perform
ceiling
on
the
data.
It
will
send
it
over
to
the
worker
to
do
the
actual
ceiling,
so
the
amount
of
worker
machines
we
have
amount
of
worker
processes.
We
have
running
that
determines
how
much
data
throughput
we
can
have
how
many
client
deals
we
can
seal
at
the
same
time.
A
So
it's
very
important
to
scale
that
appropriately.
If
we
scale
it
too
high,
it
could
be
wasteful,
but
it
all
depends
on
on
the
the
the
aims
and
it's
really
where
we
need
to
optimize.
If
we,
if
we
really
want
to
seal
data
quickly,
so
again
could
be
maybe
one
machine,
two
machines
or
it
could
be
multiple
racks
in
a
data
center.
A
If
we
want
to
seal
peppy
bytes
per
day
and
we'll
be
looking
at
a
lot
of
machines,
the
ceiling
processes
that
we
complete
when
we
receive
data,
I'm
saying
we
complete,
we
don't
really
have
to
do
anything
once
we've
set
the
data
update
software,
just
does
it,
but
it's
what
we
have
to
size:
the
hardware
for
splits
up
into
a
few
different
steps
that
have
different
requirements
and
it's
possible
to
run
these
on
on
an
all-in-one
machine.
But
then,
if
we
split
these
steps
out
into
their
own
machines,
it
can
be
more
optimal.
A
Each
sector
can
contain
a
deal
from
one
client,
maybe
a
deal
from
another
clients
put
all
in
one
in
one
sector
and
it
will
get
sealed
together
in
one
132,
gig
64
gig
chunk
to
then
be
proven
and
put
onto
the
network
that
the
ad
piece
part
takes
a
few
minutes.
So
I
haven't
put
it
on
slide.
But
it's
if
we're
really
splitting
out
everything.
A
One
will
use
four
cpu
calls
for
around
three
hours
per
32
gigabytes
of
data
that
we're
seeing
consumes
around
65
gigs
of
ram
and
uses
around
460
gigs
of
high
throughput
storage.
This
could
be
anything
but
in
practice
usually
nvme
storage
is
used
to
provide
the
required
throughput.
If
it's
slower,
then
it's
just
going
to
slow
this
in
process
down.
A
So
we
generally
need
to
look
for
storage
devices
that
are
capable
of
high
endurance,
so
they
usually
advertise
having
a
high
drive
rights
per
day
rating
dwpd,
and
it's
mainly
due
to
the
amount
of
data
being
written
during
pc1
because
of
every
32
gigs
of
data
we
store
it
is
using
460,
gigs
or
so
or
more
to
do
the
computation.
It's
only
temporary,
but
it'll
have
written
that
data
and,
of
course,
somewhere
around
the
disk.
A
So
we
just
can't
use
off-the-shelf
consumer
components,
they'll
just
wear
out,
but
if
we
use
enterprise
class
hardware,
then
it's
no
problem
in
the
last
five
years,
plus
just
something
to
keep
in
mind.
If
you
use
the
fuse
suspiciously,
cheap
storage
drives
that
are
really
meant
for
storing
some
games
on
or
something.
Then
then,
then,
you
can
run
into
problems,
but
if
using
some
some
hardware
that
basically
has
these
specs,
then
it's
perfectly
capable
of
holding
up
some
drives.
A
A
We're
looking
at
cards
designed
for
workstations
or
data
center
use.
Generally,
it's
discouraged
to
use
gaming
cards
in
data
center
settings
various
reasons.
Okay,
there's
a
point
after
pre-commit
two
called
weight
seed,
and
it's
not
on
here
essentially
because
it's
it's
enforced
by
the
network.
It's
not
a
point
where
any
computation
happens.
It's
just
waiting
for
security
reasons
on
the
network.
No,
no
computation
happens
it's
just
about
just
over
an
hour
where
we
just
have
to
wait
before
we
can
start
the
commit
to
part
then
commit
to
start
c2.
A
The
commit
to
part
of
ceiling
doesn't
use
its
own
scratch
space
like
pre-commit
one
and
pre-commit
two.
It
doesn't
need
the
the
nvme
storage,
but
it
does
use
a
powerful
graphics
card
so
similar
to
pc2
it
just
uses
card
to
efficiently
perform
the
computations
required
to
generate
the
proofs
that
get
submitted
to
the
blockchain.
It
also
uses
quite
a
reasonable
amount
of
system
memory
for
commit
to
so
it's
pretty
much
pretty
intensive
on
on
gpu
and
ram,
and
we
have
to
keep
this
in
mind
when
we're
choosing
the
size
of
our
system.
A
So
here's
some
examples
of
what
you
can
expect
for
your
money,
starting
at
around
five
thousand
dollars.
We
we
can
get
an
all-in-one
machine,
it
can
do
the
you
can
run
the
file
coin,
node
falcon
miner,
the
logis
node
miner,
the
perform
the
ceiling
processes
all
into
one
machine
and
get
usually
get
256
gigabytes
per
day
for
ceiling
capacity.
In
that
we're
looking
at
at
least
128
gigs
of
ram
in
that
and
some
nvme
drives.
A
It's
really
it's
more
suitable
for
testing
purposes
or
a
really
small
scale:
storage
provider-
and
it's
very
limited
in
throughput
and
expandability.
But
you
could
add
machines
to
it
later,
but
it's
the
smallest
system
that
a
storage
provider
would
realistically
look
at
running
on
the
network.
If
we
move
up
to
around
thirty
thousand
dollars,
then
we're
able
to
split
out
the
the
lotus
miner
and
the
lotus
markets
processes
into
their
own
dedicated
machines
and
have
a
dedicated
worker
machine,
that's
responsible
for
completing
the
the
ceiling
tasks.
A
If
we
looking
to
spend
around
a
hundred
thousand
dollars,
then
we
can
further
increase
the
ceiling,
performance
and
efficiency
through
the
use
of
dedicated
machines
for
all
of
the
different
ceiling
processes,
and
benjamin
has
a
video
on
this
topic
and
he
will
be
presenting
part
two
of
this
architecture-
presentation
in
module
3b.
So
he
may
have
something
to
say
about
that
as
well.
A
If
we're
going
beyond
to
that,
then
we're
looking
at
creating
enterprise
scale
systems,
really
where
we've
got.
You
know
more
enterprise
style,
high
availability
and
reliability,
we're
looking
at
more
like
around
750
000
and
above
for
an
enterprise
grade
system,
and
for
that
we
can.
We
can
have
high
availability
hover
the
lotus
nodes,
multiple
minor
processes
to
run
separate
storage
providers,
spread
out
that
way
and
increase
the
the
ceiling
capacity.
A
We
just
have
a
load
of
ceiling
hardware
that
is
sitting
under
utilized
most
of
the
time,
but
then,
if
we
have
multiple
pebbly
bytes
with
hard
drives
sitting
around,
but
the
no
no
way
to
seal
to
them
quickly,
then
those
drives
are
going
to
be
under
utilized.
So
we
should
match
up
the
amount
of
storage
we
have
with
the
hardware
that
we
have
available
to
seal
onto
them.
A
A
So
all
the
usual
considerations
apply
when
making
backups
of
linux
servers.
Lotus
is
almost
always
going
to
be
run
on
linux
server
these
days
and
you'd
back
back
it
up
in
the
normal
ways,
specifically
to
lotus
it's
important
to
back
up
the
lotus
miner,
specifically
the
metadata
in
the
lotus
miner.
It
contains
information
about
the
tasks
it's
running
on
the
sectors
that
it's
stored
and
generally
we
want
to
just
restore
that
state
a
lot
of
it's
on
the
blockchain
but
practical
purposes.
We
don't
just
want
to
risk
losing
it.
A
We
want
to
be
able
to
get
it
back
straight
away,
so
the
loads
of
miner
has
a
command
built
in
to
perform
the
backup
pretty
easy
to
use
just
need
to
run.
It
it'll
create
a
file
that
we
then
store
on
a
separate
server
somewhere
else.
If
we
need
it,
we
can
reinstall
loads
of
miner.
We
can
bring
that
back
up
back,
but
that
is
only
the
metadata
in
the
miner.
It's
not
the
actual
storage
medium.
That's
a
separate
issue,
the
lotus
node
itself,
which
is
what
keeps
us
in
sync
with
the
blockchain.
A
If
we
do
lose
that
we
can
just
create
a
new
locus
node
and
it
can
resynchronize
with
blockchain,
so
that's
not
too
great
a
problem.
It's
mainly
time
really
taken
to
do
that.
We
want
to
make
sure
we
can
do
this
in
enough
time
that
we
meet
client
obligations.
We
don't
get
subject
to
any
penalties
and
the
only
consideration
really
in
the
loads
is
node.
A
We
usually
have
the
private
keys
for
the
wallets
that
are
in
use,
so
at
least
the
control
wallets
in
use
for
the
miners.
Those
specifically
do
have
to
be
backed
up
somewhere,
because
if
we
lose
those,
if
we,
if
we
only
have
one
copy-
and
we
don't
have
those
anymore-
then
we've
just
lost
those
wallets
and
we've
lost
all
the
fill
in
the
wallets.
We
need
to
have
those
backed
up
separately,
there's
no
possible
way
to
retrieve
the
filter.
Those
wallets
contain
if
we
do
lose
those
files.
A
But
if
the
private
keys
for
the
wallets
are
stored
in
an
insecure
way,
then
they
could
fall
into
the
wrong
hands
that
could
lead
to
the
fill
they
contain
being
stolen.
We
can't
just
back
this
data
up
anywhere.
We
have
to
consider
backing
it
up
somewhere
securely.
We
want
to
make
sure
there's
a
copy
somewhere,
but
we
don't
want
anyone
else
to
get
a
hold
of
those
wallets.
A
Backup
should
also
be
tested
as
well,
because
they
need
to
work
when
when
you
need
them,
so
it's
good
practice
just
to
check
that
they're
being
made
correctly
now
and
again,
just
make
sure,
maybe
run
a
restore
command
just
make
sure
it
does
actually
restore
what
you
expect
and
then
I
think
nothing's
been
lost.
The
actual
storage
requirements
for
backing
the
metadata
up
of
the
lotus
miner
and
the
keys
for
the
wallet.
It's
not
not
great,
I
mean
really.
You
could
just
do
this
onto
one
large
flash
drive
or
one
separate
machine.
A
A
Maybe
well
I
mean
there's
various
available,
maybe
an
object
store
or
some
some
kind
of
storage
system
that
is
able
to
provide
the
assurances
they
need
that
it
won't
lose
data.
It's
got
less
overhead
than
the
simple
one-to-one
copy
of
all
the
data,
but
there's
that
potential
risk
I
mean
it's
one:
administrative
domain:
someone
could
run
the
wrong
command,
delete
everything
in
practice,
though
it's
it's
often
it's
often
done
should
be
considered
how
feasible
it
is
to
move
large
amounts
of
data
off-site.
A
If
we
are
doing
backups
off-site,
we
could
use
network
connections,
any
high
bandwidth
network
connections
or
we
might
physically
move
drives,
and
the
strategy
employed
by
a
storage
provider
does
depend
heavily
on
their
individual
circumstances
and
risk
tolerance.
It
depends
on
the
data
you're
storing
and
what
the
clients
expect.
A
Then
business
continuity,
the
considerations
for
business
continuity
again
depend
on
the
circumstances
and
priorities
of
a
storage
provider.
The
potential
scenarios
that
are
going
to
interrupt
the
critical
business
functions
should
be
identified
and
plans
should
be
drawn
up
to
recover
those
affected
business
functions
and
processes.
A
Currently,
it's
under
continuous
improvements.
Protocol
labs
are
not
working
on
this
various
tickets
open,
but
currently,
what
we're
looking
at
is
running
multiple
lotus
nodes
to
maintain
synchronization
with
the
farcoid
network
and
if
you
place
a
load
balancer
in
front
of
those
nodes,
maybe
standard
software
like
hyproxy
or
a
hardware
load
balancer,
and
that
can
fail
over
between
them.
If
one
fails,
the
other
one
can
be
ready
to
take
over
and
that
will
keep
continuous
node
surface
available.
Keep
us
synchronized
at
the
chain.
A
A
The
backup
and
restore
command
allows
us
to
do
this,
but
the
market's
facility
in
lotus
is
scheduled
to
be
revamped
to
provide
significant,
scalability
and
availability
improvements.
It
should
gain
a
more
highly
available
feature
set
at
that
point.
We're
expecting
that
in
not
too
distant
future.
It
should
gonna
be
a
lot
of
improvements
coming
the
lotus
workers
themselves
are
resilient
and
if
one
worker
fails,
another
worker
can
restart
the
task
that
the
failed
one
was
working
on.
A
A
A
We
might
look
at
virtual
machines,
maybe
a
useful
tool
to
split
resources
of
the
larger
machine
into
separate
units
that
provide
consistency
to
performance
and
sealing
processes
and
in
the
same
vein,
maybe
containerized
processes
that
will
do
similar
for
technical
reasons.
Lotus
is
more
able
to
use
resources
efficiently
when
using
virtual
machines
at
the
moment.
A
So
I'd
recommend
to
use
virtual
machines
if
there's
a
desire
to
virtualize
the
components
but
there's
some
again
outstanding
issues
open
on
lotus
is
github
repository
where
pl
we're
looking
at
fixing
this
improving
upon
this
area
as
well,
so
should
be
able
to
get
more
efficient
containers.
As
well
in
the
not
too
distant
future,
then
the
networking
considerations-
the
market
node-
needs
to
be
reachable
from
the
internet
and
should
be
on
a
server
that
has
a
public
publicly
writable
ip
address
or
sitting
behind
a
router,
that's
capable
of
forwarding
a
port
to
it.
A
It's
up
to
the
individual
storage
provider.
Maybe
security
considerations
kick
in
there,
but
it's
more
performance
if
it
is
accessible
and
the
bandwidth
requirements
of
the
of
the
network
depends
on
the
ceiling
process
is
employed.
We
have
to
take
this
into
account
because
we're
spreading
our
ceiling
processes
over
multiple
machines.
We
have
to
send
a
lot
of
data
between
those
machines,
maybe
multiple
hundreds
of
gigabytes
of
cache
between
pc1
and
pc2,
particularly
that's
quite
bad
with
intensive.
So
maybe
we
need
40
gig
hundred
gig
links,
security.
A
Again,
if
someone
accesses
the
keys
for
the
wallet,
then
they
could
take
the
fill
in
the
wallet.
So
it's
really
important
to
secure
that
machine.
The
set
of
people
authorized
to
access
the
machines
in
the
storage
provider
both
physically
and
over
the
network
should
be
limited
to
the
smallest
set
required.
A
It
should
be
considered
what
appropriate
legal
precautions
we
can
take.
Maybe
contracts
mdas
to
protect
the
particular
design
of
the
network
of
the
storage
provider
itself,
and
maybe
other
precautions
like
background
checks
on
staff,
any
anyone.
Anyone
with
access
the
communication
between
the
components
and
loads
is
extremely
sensitive
and
vulnerable,
because
it's
currently
unencrypted,
so
the
components
of
the
storage
provider
should
only
be
connected
together
on
a
private
network,
definitely
not
over
the
internet
currently,
unless
employing
some
kind
of
vpn
technology
to
encrypt
that
traffic
by
default.
It's
just
unencrypted.
A
When
we're
sending
money
between
the
falcon
wallets,
it's
easy
to
make
a
typo,
and
maybe
we
want
processes
in
place
where
there's
a
you
know,
a
check
or
some
kind
of
process
where
that
can't
happen.
Where
that's
made,
you
know,
there's
there
are
checks,
we
don't
just
type
in
the
wrong
number
and
suddenly
send
things
the
wrong
way,
because
if
we
send
fargo
into
the
wrong
wallet,
then
we
can't
get
it
back.
We
have
to
make
sure
this
is
correct.
It's
unrecoverable!
A
If
we
stop
the
miner,
while
it's
performing
the
proof
computations
like
window
post
winning
post.
Well,
it's
this
time
limits
on
when
those
can
be
submitted
to
change.
So
it
could
result
in
that
proof
never
being
submitted
to
the
network,
and
then
we
would
incur
the
associated
penalties
or
loss
of
opportunities
by
not
having
the
reward
from
winning
post.
A
If
we
stop
the
markets
node,
when
the
client's
updating
on
downloading
data
then
well,
we
may
lose
business
if
we
lose
out
on
deals
or
we
can
end
up
with
reputational
damage.
If
clients
start
saying
well,
it
keeps
going
offline
and
we
just
don't
trust
that
storage
provider
anymore.
It's
not
a
good
service,
I'm
just
going
to
make
sure
it
stays
on
and
then
questions.
That's
the
end
of
my
presentation,
so
part
two
will
be
hosted
by
benjamin
and
thank
you
for
listening.