56 lines
2.5 KiB
Markdown
56 lines
2.5 KiB
Markdown
|
# Raúl's notes
|
|||
|
|
|
|||
|
|
## Storage mining
|
|||
|
|
|
|||
|
|
The Storage Mining System is the part of the Filecoin Protocol that deals with
|
|||
|
|
storing Client’s data, producing proof artifacts that demonstrate correct
|
|||
|
|
storage behavior, and managing the work involved.
|
|||
|
|
|
|||
|
|
## Preseals
|
|||
|
|
|
|||
|
|
In the Filecoin consensus protocol, the miners' probability of being eligible
|
|||
|
|
to mine a block in a given epoch is directly correlated with their power in the
|
|||
|
|
network. This creates a chicken-and-egg problem at genesis. Since there are no
|
|||
|
|
miners, there is no power in the network, therefore no miner is eligible to mine
|
|||
|
|
and advance the chain.
|
|||
|
|
|
|||
|
|
Preseals are sealed sectors that are blessed at genesis, thus conferring
|
|||
|
|
their miners the possibility to win round elections and successfully mine a
|
|||
|
|
block. Without preseals, the chain would be dead on arrival.
|
|||
|
|
|
|||
|
|
Preseals work with fauxrep and faux sealing, which are special-case
|
|||
|
|
implementations of PoRep and the sealing logic that do not depend on slow
|
|||
|
|
sealing.
|
|||
|
|
|
|||
|
|
### Not implemented things
|
|||
|
|
|
|||
|
|
**Sector Resealing:** Miners should be able to ’re-seal’ sectors, to allow them
|
|||
|
|
to take a set of sectors with mostly expired pieces, and combine the
|
|||
|
|
not-yet-expired pieces into a single (or multiple) sectors.
|
|||
|
|
|
|||
|
|
**Sector Transfer:** Miners should be able to re-delegate the responsibility of
|
|||
|
|
storing data to another miner. This is tricky for many reasons, and will not be
|
|||
|
|
implemented in the initial release of Filecoin, but could provide interesting
|
|||
|
|
capabilities down the road.
|
|||
|
|
|
|||
|
|
## Catch-up/rush mining
|
|||
|
|
|
|||
|
|
In catch-up or rush mining, miners make up for chain history that does not
|
|||
|
|
exist. It's a recovery/healing procedure. The chain runs at at constant
|
|||
|
|
25 second epoch time. When in the network mining halts for some reason
|
|||
|
|
(consensus/liveness bug, drand availability issues, etc.), upon a restart miners
|
|||
|
|
will go and backfill the chain history by mining backdated blocks in
|
|||
|
|
the appropriate timestamps.
|
|||
|
|
|
|||
|
|
There are a few things worth highlighting:
|
|||
|
|
* mining runs in a hot loop, and there is no time for miners to gossip about
|
|||
|
|
their blocks; therefore they end up building the chain solo, as they can't
|
|||
|
|
incorprate other blocks into tipsets.
|
|||
|
|
* the miner with most power will mine most blocks.
|
|||
|
|
* presumably, as many forks in the network will appear as miners who mined a
|
|||
|
|
block + a fork filled with null rounds only (for miners that didn't win a
|
|||
|
|
round).
|
|||
|
|
* at the end of the catch-up, the heaviest fork will win the race, and it may
|
|||
|
|
be possible for the most powerful miner pre-disruption to affect the
|
|||
|
|
outcome by choosing the messages that go in their blocks.
|