Storage Power Actor
-
State
reliable
-
Theory Audit
wip
-
Edit this section
-
section-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor
-
State
reliable
-
Theory Audit
wip
- Edit this section
-
section-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor
StoragePowerActorState
implementation
-
State
reliable
-
Theory Audit
wip
-
Edit this section
-
section-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor.storagepoweractorstate-implementation
-
State
reliable
-
Theory Audit
wip
- Edit this section
-
section-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor.storagepoweractorstate-implementation
type State struct {
TotalRawBytePower abi.StoragePower
// TotalBytesCommitted includes claims from miners below min power threshold
TotalBytesCommitted abi.StoragePower
TotalQualityAdjPower abi.StoragePower
// TotalQABytesCommitted includes claims from miners below min power threshold
TotalQABytesCommitted abi.StoragePower
TotalPledgeCollateral abi.TokenAmount
// These fields are set once per epoch in the previous cron tick and used
// for consistent values across a single epoch's state transition.
ThisEpochRawBytePower abi.StoragePower
ThisEpochQualityAdjPower abi.StoragePower
ThisEpochPledgeCollateral abi.TokenAmount
ThisEpochQAPowerSmoothed smoothing.FilterEstimate
MinerCount int64
// Number of miners having proven the minimum consensus power.
MinerAboveMinPowerCount int64
// A queue of events to be triggered by cron, indexed by epoch.
CronEventQueue cid.Cid // Multimap, (HAMT[ChainEpoch]AMT[CronEvent])
// First epoch in which a cron task may be stored.
// Cron will iterate every epoch between this and the current epoch inclusively to find tasks to execute.
FirstCronEpoch abi.ChainEpoch
// Claimed power for each miner.
Claims cid.Cid // Map, HAMT[address]Claim
ProofValidationBatch *cid.Cid // Multimap, (HAMT[Address]AMT[SealVerifyInfo])
}
StoragePowerActor
implementation
-
State
reliable
-
Theory Audit
wip
-
Edit this section
-
section-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor.storagepoweractor-implementation
-
State
reliable
-
Theory Audit
wip
- Edit this section
-
section-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor.storagepoweractor-implementation
func (a Actor) Exports() []interface{} {
return []interface{}{
builtin.MethodConstructor: a.Constructor,
2: a.CreateMiner,
3: a.UpdateClaimedPower,
4: a.EnrollCronEvent,
5: a.CronTick,
6: a.UpdatePledgeTotal,
7: nil, // deprecated
8: a.SubmitPoRepForBulkVerify,
9: a.CurrentTotalPower,
}
}
func (a Actor) Constructor(rt Runtime, _ *abi.EmptyValue) *abi.EmptyValue {
rt.ValidateImmediateCallerIs(builtin.SystemActorAddr)
st, err := ConstructState(adt.AsStore(rt))
builtin.RequireNoErr(rt, err, exitcode.ErrIllegalState, "failed to construct state")
rt.StateCreate(st)
return nil
}
The Power Table
-
State
reliable
-
Theory Audit
wip
-
Edit this section
-
section-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor.the-power-table
-
State
reliable
-
Theory Audit
wip
- Edit this section
-
section-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor.the-power-table
The portion of blocks a given miner generates through leader election in EC (and so the block rewards they earn) is proportional to their Quality-Adjusted Power Fraction
over time. That is, a miner whose quality adjusted power represents 1% of total quality adjusted power on the network should mine 1% of blocks on expectation.
SPC provides a power table abstraction which tracks miner power (i.e. miner storage in relation to network storage) over time. The power table is updated for new sector commitments (incrementing miner power), for failed PoSts (decrementing miner power) or for other storage and consensus faults.
Sector ProveCommit is the first time power is proven to the network and hence power is first added upon successful sector ProveCommit. Power is also added when a sector is declared as recovered. Miners are expected to prove over all their sectors that contribute to their power.
Power is decremented when a sector expires, when a sector is declared or detected to be faulty, or when it is terminated through miner invocation. Miners can also extend the lifetime of a sector through ExtendSectorExpiration
.
The Miner lifecycle in the power table should be roughly as follows:
MinerRegistration
: A new miner with an associated worker public key and address is registered on the power table by the storage mining subsystem, along with their associated sector size (there is only one per worker).UpdatePower
: These power increments and decrements are called by various storage actors (and must thus be verified by every full node on the network). Specifically:- Power is incremented at ProveCommit, as a subcall of
miner.ProveCommitSector
orminer.ProveCommitAggregate
- Power of a partition is decremented immediately after a missed WindowPoSt (
DetectedFault
). - A particular sector’s power is decremented when it enters into a faulty state either through Declared Faults or Skipped Faults.
- A particular sector’s power is added back after recovery is declared and proven by PoSt.
- A particular sector’s power is removed when the sector is expired or terminated through miner invocation.
- Power is incremented at ProveCommit, as a subcall of
To summarize, only sectors in the Active state will command power. A Sector becomes Active when it is added upon ProveCommit
. Power is immediately decremented when it enters into the faulty state. Power will be restored when its declared recovery is proven. A sector’s power is removed when it is expired or terminated through miner invocation.
Pledge Collateral
-
State
reliable
-
Theory Audit
wip
-
Edit this section
-
section-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor.pledge-collateral
-
State
reliable
-
Theory Audit
wip
- Edit this section
-
section-systems.filecoin_blockchain.storage_power_consensus.storage_power_actor.pledge-collateral
Pledge Collateral is slashed for any fault affecting storage-power consensus, these include:
- faults to expected consensus in particular (see
Consensus Faults), which will be reported by a slasher to the
StoragePowerActor
in exchange for a reward. - faults affecting consensus power more generally, specifically uncommitted power faults (i.e.
Storage Faults), which will be reported by the
CronActor
automatically or when a miner terminates a sector earlier than its promised duration.
For a more detailed discussion on Pledge Collateral, please see the Miner Collaterals section.