The maximum number of partitions that may be required to be loaded in a single invocation.
This limits the number of simultaneous fault, recovery, or sector-extension declarations.
With 48 deadlines (half-hour), 200 partitions per declaration permits loading a full EiB of 32GiB
sectors with 1 message per epoch within a single half-hour deadline. A miner can of course submit more messages.
The maximum number of sector infos that may be required to be loaded in a single invocation.
Epochs after which chain state is final with overwhelming probability (hence the likelihood of two fork of this size is negligible)
This is a conservative value that is chosen via simulations of all known attacks.
Number of epochs after a consensus fault for which a miner is ineligible
for permissioned actor methods and winning block elections.
Ratio of sector size to maximum deals per sector.
The maximum number of deals is the sector size divided by this number (2^27)
which limits 32GiB sectors to 256 deals and 64GiB sectors to 512
DealUpdatesInterval is the number of epochs between payouts for deals
Maximum number of unique “declarations” in batch operations.
The delay between pre commit expiration and clean up from state. This enforces that expired pre-commits
stay in state for a period of time creating a grace period during which a late-running aggregated prove-commit
can still prove its non-expired precommits without resubmitting a message
Minimum period before a deadline’s challenge window opens that a fault must be declared for that deadline.
This lookback must not be less than WPoStChallengeLookback lest a malicious miner be able to selectively declare
faults after learning the challenge value.
The maximum age of a fault before the sector is terminated.
Maximum total aggregated proof size.
Maximum amount of sectors that can be aggregated.
Maximum number of control addresses a miner may register.
MaxMultiaddrData is the maximum amount of data that can be stored in multiaddrs.
Maximum number of partitions that will be assigned to a deadline.
For a minimum storage of upto 1Eib, we need 300 partitions per deadline.
48 * 32GiB * 2349 * 300 = 1.00808144 EiB
So, to support upto 10Eib storage, we set this to 3000.
MaxPeerIDLength is the maximum length allowed for any on-chain peer ID.
Most Peer IDs are expected to be less than 50 bytes.
Maximum total aggregated proof size.
Maximum number of epochs past the current epoch a sector may be set to expire.
The actual maximum extension will be the minimum of CurrEpoch + MaximumSectorExpirationExtension
and sector.ActivationEpoch+sealProof.SectorMaximumLifetime()
Minimum amount of sectors that can be aggregated.
Minimum number of epochs past the current epoch a sector may be set to expire.
The maximum number of new sectors that may be staged by a miner during a single proving period.
Number of epochs between publishing the precommit and when the challenge for interactive PoRep is drawn
used to ensure it is not predictable by miner.
The maximum number of sector pre-commitments in a single batch.
32 sectors per epoch would support a single miner onboarding 1EiB of 32GiB sectors in 1 year.
The maximum number of sector replica updates in a single batch.
Same as PRE_COMMIT_SECTOR_BATCH_MAX_SIZE for consistency
Denominator of the percentage of normalized cirulating
supply that must be covered by provider collateral
Numerator of the percentage of normalized cirulating
supply that must be covered by provider collateral
The number of total possible types (enum variants) of RegisteredPoStProof
The number of total possible types (enum variants) of RegisteredSealProof
The maximum number of sectors that a miner can have simultaneously active.
This also bounds the number of faults that can be declared, etc.
Staging period for a miner worker key change.
Finality is a harsh delay for a miner who has lost their worker key, as the miner will miss Window PoSts until
it can be changed. It’s the only safe value, though. We may implement a mitigation mechanism such as a second
key or allowing the owner account to submit PoSts while a key change is pending.
Lookback from the deadline’s challenge window opening from which to sample chain randomness for the challenge seed.
This lookback exists so that deadline windows can be non-overlapping (which make the programming simpler)
but without making the miner wait for chain stability before being able to start on PoSt computation.
The challenge is available this many epochs before the window is actually open to receiving a PoSt.
The duration of a deadline’s challenge window, the period before a deadline when the challenge is available.
The maximum distance back that a valid Window PoSt must commit to the current chain.
The number of non-overlapping PoSt deadlines in each proving period.
The period over which all a miner’s active sectors will be challenged.