fil_actors_runtime_v9/runtime/policy.rs
1// Copyright 2019-2022 ChainSafe Systems
2// SPDX-License-Identifier: Apache-2.0, MIT
3
4use std::collections::HashSet;
5
6use fvm_shared::clock::ChainEpoch;
7use fvm_shared::sector::{RegisteredPoStProof, RegisteredSealProof, StoragePower};
8use num_traits::FromPrimitive;
9use serde::{Deserialize, Serialize};
10
11// The policy itself
12#[derive(Debug, PartialEq, Eq, Clone, Serialize, Deserialize)]
13pub struct Policy {
14 /// Maximum amount of sectors that can be aggregated.
15 pub max_aggregated_sectors: u64,
16 /// Minimum amount of sectors that can be aggregated.
17 pub min_aggregated_sectors: u64,
18 /// Maximum total aggregated proof size.
19 pub max_aggregated_proof_size: usize,
20 /// Maximum total replica update proof size.
21 pub max_replica_update_proof_size: usize,
22
23 /// The maximum number of sector pre-commitments in a single batch.
24 /// 32 sectors per epoch would support a single miner onboarding 1 EiB of 32 GiB sectors in 1 year.
25 pub pre_commit_sector_batch_max_size: usize,
26 /// The maximum number of sector replica updates in a single batch.
27 pub prove_replica_updates_max_size: usize,
28
29 /// The delay between pre-commit expiration and clean up from state. This enforces that expired pre-commits
30 /// stay in state for a period of time creating a grace period during which a late-running aggregated prove-commit
31 /// can still prove its non-expired pre-commits without resubmitting a message
32 pub expired_pre_commit_clean_up_delay: i64,
33
34 /// The period over which all a miner's active sectors will be challenged.
35 pub wpost_proving_period: ChainEpoch,
36 /// The duration of a deadline's challenge window, the period before a deadline when the challenge is available.
37 pub wpost_challenge_window: ChainEpoch,
38 /// The number of non-overlapping PoSt deadlines in each proving period.
39 pub wpost_period_deadlines: u64,
40 /// The maximum distance back that a valid Window PoSt must commit to the current chain.
41 pub wpost_max_chain_commit_age: ChainEpoch,
42 /// `WPoStDisputeWindow` is the period after a challenge window ends during which
43 /// PoSts submitted during that period may be disputed.
44 pub wpost_dispute_window: ChainEpoch,
45
46 /// The maximum number of sectors that a miner can have simultaneously active.
47 /// This also bounds the number of faults that can be declared, etc.
48 pub sectors_max: usize,
49
50 /// Maximum number of partitions that will be assigned to a deadline.
51 /// For a minimum storage of up-to 1 EiB, we need 300 partitions per deadline.
52 /// `48 * 32 GiB * 2349 * 300 = 1.00808144 EiB`
53 /// So, to support up-to 10 Eib storage, we set this to 3000.
54 pub max_partitions_per_deadline: u64,
55
56 /// Maximum number of control addresses a miner may register.
57 pub max_control_addresses: usize,
58
59 /// `MaxPeerIDLength` is the maximum length allowed for any on-chain peer ID.
60 /// Most Peer IDs are expected to be less than 50 bytes.
61 pub max_peer_id_length: usize,
62
63 /// `MaxMultiaddrData` is the maximum amount of data that can be stored in `Multiaddr`s.
64 pub max_multiaddr_data: usize,
65
66 /// The maximum number of partitions that may be required to be loaded in a single invocation.
67 /// This limits the number of simultaneous fault, recovery, or sector-extension declarations.
68 /// With 48 deadlines (half-hour), 200 partitions per declaration permits loading a full EiB of 32 GiB
69 /// sectors with 1 message per epoch within a single half-hour deadline. A miner can of course submit more messages.
70 pub addressed_partitions_max: u64,
71
72 /// Maximum number of unique "declarations" in batch operations.
73 pub declarations_max: u64,
74
75 /// The maximum number of sector infos that may be required to be loaded in a single invocation.
76 pub addressed_sectors_max: u64,
77
78 pub max_pre_commit_randomness_lookback: ChainEpoch,
79
80 /// Number of epochs between publishing the pre-commit and when the challenge for interactive `PoRep` is drawn
81 /// used to ensure it is not predictable by miner.
82 pub pre_commit_challenge_delay: ChainEpoch,
83
84 /// Look-back from the deadline's challenge window opening from which to sample chain randomness for the challenge seed.
85
86 /// This lookback exists so that deadline windows can be non-overlapping (which make the programming simpler)
87 /// but without making the miner wait for chain stability before being able to start on PoSt computation.
88 /// The challenge is available this many epochs before the window is actually open to receiving a PoSt.
89 pub wpost_challenge_lookback: ChainEpoch,
90
91 /// Minimum period before a deadline's challenge window opens that a fault must be declared for that deadline.
92 /// This lookback must not be less than `WPoStChallengeLookback` lest a malicious miner be able to selectively declare
93 /// faults after learning the challenge value.
94 pub fault_declaration_cutoff: ChainEpoch,
95
96 /// The maximum age of a fault before the sector is terminated.
97 pub fault_max_age: ChainEpoch,
98
99 /// Staging period for a miner worker key change.
100 /// Finality is a harsh delay for a miner who has lost their worker key, as the miner will miss Window PoSts until
101 /// it can be changed. It's the only safe value, though. We may implement a mitigation mechanism such as a second
102 /// key or allowing the owner account to submit PoSts while a key change is pending.
103 pub worker_key_change_delay: ChainEpoch,
104
105 /// Minimum number of epochs past the current epoch a sector may be set to expire.
106 pub min_sector_expiration: i64,
107
108 /// Maximum number of epochs past the current epoch a sector may be set to expire.
109 /// The actual maximum extension will be the minimum of `CurrEpoch + MaximumSectorExpirationExtension`
110 /// and `sector.ActivationEpoch + sealProof.SectorMaximumLifetime()`
111 pub max_sector_expiration_extension: i64,
112
113 /// Ratio of sector size to maximum deals per sector.
114 /// The maximum number of deals is the sector size divided by this number (`2^27`)
115 /// which limits 32 GiB sectors to 256 deals and 64 GiB sectors to 512
116 pub deal_limit_denominator: u64,
117
118 /// Number of epochs after a consensus fault for which a miner is ineligible
119 /// for permissioned actor methods and winning block elections.
120 pub consensus_fault_ineligibility_duration: ChainEpoch,
121
122 /// The maximum number of new sectors that may be staged by a miner during a single proving period.
123 pub new_sectors_per_period_max: usize,
124
125 /// Epochs after which chain state is final with overwhelming probability (hence the likelihood of two fork of this size is negligible)
126 /// This is a conservative value that is chosen via simulations of all known attacks.
127 pub chain_finality: ChainEpoch,
128
129 /// Allowed post proof types for new miners
130 pub valid_post_proof_type: HashSet<RegisteredPoStProof>,
131
132 /// Allowed pre-commit proof types for new miners
133 pub valid_pre_commit_proof_type: HashSet<RegisteredSealProof>,
134
135 // --- verifreg policy
136 /// Minimum verified deal size
137 pub minimum_verified_allocation_size: StoragePower,
138 /// Minimum term for a verified data allocation (epochs)
139 pub minimum_verified_allocation_term: i64,
140 /// Maximum term for a verified data allocation (epochs)
141 pub maximum_verified_allocation_term: i64,
142 /// Maximum time a verified allocation can be active without being claimed (epochs).
143 /// Supports recovery of erroneous allocations and prevents indefinite squatting on `Datacap`.
144 pub maximum_verified_allocation_expiration: i64,
145 // Period of time at the end of a sector's life during which claims can be dropped
146 pub end_of_life_claim_drop_period: ChainEpoch,
147
148 // --- market policy ---
149 /// The number of blocks between payouts for deals
150 pub deal_updates_interval: i64,
151
152 /// Numerator of the percentage of normalized circulating
153 /// supply that must be covered by provider collateral
154 pub prov_collateral_percent_supply_num: i64,
155
156 /// Denominator of the percentage of normalized circulating
157 /// supply that must be covered by provider collateral
158 pub prov_collateral_percent_supply_denom: i64,
159
160 /// The default duration after a verified deal's nominal term to set for the corresponding
161 /// allocation's maximum term.
162 pub market_default_allocation_term_buffer: i64,
163
164 // --- power ---
165 /// Minimum miner consensus power
166 pub minimum_consensus_power: StoragePower,
167}
168
169impl Policy {
170 pub fn mainnet() -> Self {
171 Policy {
172 max_aggregated_sectors: policy_constants::MAX_AGGREGATED_SECTORS,
173 min_aggregated_sectors: policy_constants::MIN_AGGREGATED_SECTORS,
174 max_aggregated_proof_size: policy_constants::MAX_AGGREGATED_PROOF_SIZE,
175 max_replica_update_proof_size: policy_constants::MAX_REPLICA_UPDATE_PROOF_SIZE,
176 pre_commit_sector_batch_max_size: policy_constants::PRE_COMMIT_SECTOR_BATCH_MAX_SIZE,
177 prove_replica_updates_max_size: policy_constants::PROVE_REPLICA_UPDATES_MAX_SIZE,
178 expired_pre_commit_clean_up_delay: policy_constants::EXPIRED_PRE_COMMIT_CLEAN_UP_DELAY,
179 wpost_proving_period: policy_constants::WPOST_PROVING_PERIOD,
180 wpost_challenge_window: policy_constants::WPOST_CHALLENGE_WINDOW,
181 wpost_period_deadlines: policy_constants::WPOST_PERIOD_DEADLINES,
182 wpost_max_chain_commit_age: policy_constants::WPOST_MAX_CHAIN_COMMIT_AGE,
183 wpost_dispute_window: policy_constants::WPOST_DISPUTE_WINDOW,
184 sectors_max: policy_constants::SECTORS_MAX,
185 max_partitions_per_deadline: policy_constants::MAX_PARTITIONS_PER_DEADLINE,
186 max_control_addresses: policy_constants::MAX_CONTROL_ADDRESSES,
187 max_peer_id_length: policy_constants::MAX_PEER_ID_LENGTH,
188 max_multiaddr_data: policy_constants::MAX_MULTIADDR_DATA,
189 addressed_partitions_max: policy_constants::ADDRESSED_PARTITIONS_MAX,
190 declarations_max: policy_constants::DECLARATIONS_MAX,
191 addressed_sectors_max: policy_constants::ADDRESSED_SECTORS_MAX,
192 max_pre_commit_randomness_lookback:
193 policy_constants::MAX_PRE_COMMIT_RANDOMNESS_LOOKBACK,
194 pre_commit_challenge_delay: policy_constants::PRE_COMMIT_CHALLENGE_DELAY,
195 wpost_challenge_lookback: policy_constants::WPOST_CHALLENGE_LOOKBACK,
196 fault_declaration_cutoff: policy_constants::FAULT_DECLARATION_CUTOFF,
197 fault_max_age: policy_constants::FAULT_MAX_AGE,
198 worker_key_change_delay: policy_constants::WORKER_KEY_CHANGE_DELAY,
199 min_sector_expiration: policy_constants::MIN_SECTOR_EXPIRATION,
200 max_sector_expiration_extension: policy_constants::MAX_SECTOR_EXPIRATION_EXTENSION,
201 deal_limit_denominator: policy_constants::DEAL_LIMIT_DENOMINATOR,
202 consensus_fault_ineligibility_duration:
203 policy_constants::CONSENSUS_FAULT_INELIGIBILITY_DURATION,
204 new_sectors_per_period_max: policy_constants::NEW_SECTORS_PER_PERIOD_MAX,
205 chain_finality: policy_constants::CHAIN_FINALITY,
206
207 valid_post_proof_type: HashSet::<RegisteredPoStProof>::from([
208 RegisteredPoStProof::StackedDRGWindow32GiBV1,
209 RegisteredPoStProof::StackedDRGWindow64GiBV1,
210 ]),
211 valid_pre_commit_proof_type: HashSet::<RegisteredSealProof>::from([
212 RegisteredSealProof::StackedDRG32GiBV1P1,
213 RegisteredSealProof::StackedDRG64GiBV1P1,
214 ]),
215
216 minimum_verified_allocation_size: StoragePower::from_i32(
217 policy_constants::MINIMUM_VERIFIED_ALLOCATION_SIZE,
218 )
219 .unwrap(),
220 minimum_verified_allocation_term: policy_constants::MINIMUM_VERIFIED_ALLOCATION_TERM,
221 maximum_verified_allocation_term: policy_constants::MAXIMUM_VERIFIED_ALLOCATION_TERM,
222 maximum_verified_allocation_expiration:
223 policy_constants::MAXIMUM_VERIFIED_ALLOCATION_EXPIRATION,
224 end_of_life_claim_drop_period: policy_constants::END_OF_LIFE_CLAIM_DROP_PERIOD,
225 deal_updates_interval: policy_constants::DEAL_UPDATES_INTERVAL,
226 prov_collateral_percent_supply_num:
227 policy_constants::PROV_COLLATERAL_PERCENT_SUPPLY_NUM,
228 prov_collateral_percent_supply_denom:
229 policy_constants::PROV_COLLATERAL_PERCENT_SUPPLY_DENOM,
230 market_default_allocation_term_buffer:
231 policy_constants::MARKET_DEFAULT_ALLOCATION_TERM_BUFFER,
232
233 minimum_consensus_power: StoragePower::from(
234 policy_constants::MAINNET_MINIMUM_CONSENSUS_POWER,
235 ),
236 }
237 }
238
239 pub fn calibnet() -> Self {
240 Policy {
241 minimum_consensus_power: StoragePower::from(
242 policy_constants::CALIBNET_MINIMUM_CONSENSUS_POWER,
243 ),
244 ..Policy::mainnet()
245 }
246 }
247}
248
249pub mod policy_constants {
250 use fvm_shared::clock::ChainEpoch;
251 use fvm_shared::clock::EPOCH_DURATION_SECONDS;
252
253 use crate::builtin::*;
254
255 /// Maximum amount of sectors that can be aggregated.
256 pub const MAX_AGGREGATED_SECTORS: u64 = 819;
257 /// Minimum amount of sectors that can be aggregated.
258 pub const MIN_AGGREGATED_SECTORS: u64 = 4;
259 /// Maximum total aggregated proof size.
260 pub const MAX_AGGREGATED_PROOF_SIZE: usize = 81960;
261 /// Maximum total aggregated proof size.
262 pub const MAX_REPLICA_UPDATE_PROOF_SIZE: usize = 4096;
263
264 /// The maximum number of sector pre-commitments in a single batch.
265 /// 32 sectors per epoch would support a single miner onboarding 1 EiB of 32 GiB sectors in 1 year.
266 pub const PRE_COMMIT_SECTOR_BATCH_MAX_SIZE: usize = 256;
267
268 /// The maximum number of sector replica updates in a single batch.
269 /// Same as `PRE_COMMIT_SECTOR_BATCH_MAX_SIZE` for consistency
270 pub const PROVE_REPLICA_UPDATES_MAX_SIZE: usize = PRE_COMMIT_SECTOR_BATCH_MAX_SIZE;
271
272 /// The delay between pre-commit expiration and clean up from state. This enforces that expired pre-commits
273 /// stay in state for a period of time creating a grace period during which a late-running aggregated prove-commit
274 /// can still prove its non-expired pre-commits without resubmitting a message
275 pub const EXPIRED_PRE_COMMIT_CLEAN_UP_DELAY: i64 = 8 * EPOCHS_IN_HOUR;
276
277 /// The period over which all a miner's active sectors will be challenged.
278 pub const WPOST_PROVING_PERIOD: ChainEpoch = EPOCHS_IN_DAY;
279 /// The duration of a deadline's challenge window, the period before a deadline when the challenge is available.
280 pub const WPOST_CHALLENGE_WINDOW: ChainEpoch = 30 * 60 / EPOCH_DURATION_SECONDS; // Half an hour (=48 per day)
281 /// The number of non-overlapping PoSt deadlines in each proving period.
282 pub const WPOST_PERIOD_DEADLINES: u64 = 48;
283 /// The maximum distance back that a valid Window PoSt must commit to the current chain.
284 pub const WPOST_MAX_CHAIN_COMMIT_AGE: ChainEpoch = WPOST_CHALLENGE_WINDOW;
285 // WPoStDisputeWindow is the period after a challenge window ends during which
286 // PoSts submitted during that period may be disputed.
287 pub const WPOST_DISPUTE_WINDOW: ChainEpoch = 2 * CHAIN_FINALITY;
288
289 /// The maximum number of sectors that a miner can have simultaneously active.
290 /// This also bounds the number of faults that can be declared, etc.
291 pub const SECTORS_MAX: usize = 32 << 20;
292
293 /// Maximum number of partitions that will be assigned to a deadline.
294 /// For a minimum storage of up-to 1 EiB, we need 300 partitions per deadline.
295 /// `48 * 32GiB * 2349 * 300 = 1.00808144 EiB`
296 /// So, to support up-to 10 Eib storage, we set this to 3000.
297 pub const MAX_PARTITIONS_PER_DEADLINE: u64 = 3000;
298
299 /// Maximum number of control addresses a miner may register.
300 pub const MAX_CONTROL_ADDRESSES: usize = 10;
301
302 /// `MaxPeerIDLength` is the maximum length allowed for any on-chain peer ID.
303 /// Most Peer IDs are expected to be less than 50 bytes.
304 pub const MAX_PEER_ID_LENGTH: usize = 128;
305
306 /// `MaxMultiaddrData` is the maximum amount of data that can be stored in `multiaddr`s.
307 pub const MAX_MULTIADDR_DATA: usize = 1024;
308
309 /// The maximum number of partitions that may be required to be loaded in a single invocation.
310 /// This limits the number of simultaneous fault, recovery, or sector-extension declarations.
311 /// With 48 deadlines (half-hour), 200 partitions per declaration permits loading a full EiB of 32 GiB
312 /// sectors with 1 message per epoch within a single half-hour deadline. A miner can of course submit more messages.
313 pub const ADDRESSED_PARTITIONS_MAX: u64 = MAX_PARTITIONS_PER_DEADLINE;
314
315 /// Maximum number of unique "declarations" in batch operations.
316 pub const DECLARATIONS_MAX: u64 = ADDRESSED_PARTITIONS_MAX;
317
318 /// The maximum number of sector infos that may be required to be loaded in a single invocation.
319 pub const ADDRESSED_SECTORS_MAX: u64 = 25_000;
320
321 pub const MAX_PRE_COMMIT_RANDOMNESS_LOOKBACK: ChainEpoch = EPOCHS_IN_DAY + CHAIN_FINALITY;
322
323 /// Number of epochs between publishing the pre-commit and when the challenge for interactive `PoRep` is drawn
324 /// used to ensure it is not predictable by miner.
325 pub const PRE_COMMIT_CHALLENGE_DELAY: ChainEpoch = 150;
326
327 /// Lookback from the deadline's challenge window opening from which to sample chain randomness for the challenge seed.
328
329 /// This lookback exists so that deadline windows can be non-overlapping (which make the programming simpler)
330 /// but without making the miner wait for chain stability before being able to start on PoSt computation.
331 /// The challenge is available this many epochs before the window is actually open to receiving a PoSt.
332 pub const WPOST_CHALLENGE_LOOKBACK: ChainEpoch = 20;
333
334 /// Minimum period before a deadline's challenge window opens that a fault must be declared for that deadline.
335 /// This lookback must not be less than `WPoStChallengeLookback` lest a malicious miner be able to selectively declare
336 /// faults after learning the challenge value.
337 pub const FAULT_DECLARATION_CUTOFF: ChainEpoch = WPOST_CHALLENGE_LOOKBACK + 50;
338
339 /// The maximum age of a fault before the sector is terminated.
340 pub const FAULT_MAX_AGE: ChainEpoch = WPOST_PROVING_PERIOD * 42;
341
342 /// Staging period for a miner worker key change.
343 /// Finality is a harsh delay for a miner who has lost their worker key, as the miner will miss Window PoSts until
344 /// it can be changed. It's the only safe value, though. We may implement a mitigation mechanism such as a second
345 /// key or allowing the owner account to submit PoSts while a key change is pending.
346 pub const WORKER_KEY_CHANGE_DELAY: ChainEpoch = CHAIN_FINALITY;
347
348 /// Minimum number of epochs past the current epoch a sector may be set to expire.
349 pub const MIN_SECTOR_EXPIRATION: i64 = 180 * EPOCHS_IN_DAY;
350
351 /// Maximum number of epochs past the current epoch a sector may be set to expire.
352 /// The actual maximum extension will be the minimum of `CurrEpoch + MaximumSectorExpirationExtension`
353 /// and `sector.ActivationEpoch+sealProof.SectorMaximumLifetime()`
354 pub const MAX_SECTOR_EXPIRATION_EXTENSION: i64 = 540 * EPOCHS_IN_DAY;
355
356 /// Ratio of sector size to maximum deals per sector.
357 /// The maximum number of deals is the sector size divided by this number (`2^27`)
358 /// which limits 32 GiB sectors to 256 deals and 64 GiB sectors to 512
359 pub const DEAL_LIMIT_DENOMINATOR: u64 = 134217728;
360
361 /// Number of epochs after a consensus fault for which a miner is ineligible
362 /// for permissioned actor methods and winning block elections.
363 pub const CONSENSUS_FAULT_INELIGIBILITY_DURATION: ChainEpoch = CHAIN_FINALITY;
364
365 /// The maximum number of new sectors that may be staged by a miner during a single proving period.
366 pub const NEW_SECTORS_PER_PERIOD_MAX: usize = 128 << 10;
367
368 /// Epochs after which chain state is final with overwhelming probability (hence the likelihood of two fork of this size is negligible)
369 /// This is a conservative value that is chosen via simulations of all known attacks.
370 pub const CHAIN_FINALITY: ChainEpoch = 900;
371
372 pub const MINIMUM_VERIFIED_ALLOCATION_SIZE: i32 = 1 << 20;
373 pub const MINIMUM_VERIFIED_ALLOCATION_TERM: i64 = 180 * EPOCHS_IN_DAY;
374 pub const MAXIMUM_VERIFIED_ALLOCATION_TERM: i64 = 5 * EPOCHS_IN_YEAR;
375 pub const MAXIMUM_VERIFIED_ALLOCATION_EXPIRATION: i64 = 60 * EPOCHS_IN_DAY;
376 pub const END_OF_LIFE_CLAIM_DROP_PERIOD: ChainEpoch = 30 * EPOCHS_IN_DAY;
377
378 /// `DealUpdatesInterval` is the number of blocks between payouts for deals
379 pub const DEAL_UPDATES_INTERVAL: i64 = EPOCHS_IN_DAY;
380
381 /// Numerator of the percentage of normalized circulating
382 /// supply that must be covered by provider collateral
383 pub const PROV_COLLATERAL_PERCENT_SUPPLY_NUM: i64 = 1;
384
385 /// Denominator of the percentage of normalized circulating
386 /// supply that must be covered by provider collateral
387 pub const PROV_COLLATERAL_PERCENT_SUPPLY_DENOM: i64 = 100;
388
389 pub const MARKET_DEFAULT_ALLOCATION_TERM_BUFFER: i64 = 90 * EPOCHS_IN_DAY;
390
391 pub const CALIBNET_MINIMUM_CONSENSUS_POWER: i64 = 32 << 30;
392 pub const MAINNET_MINIMUM_CONSENSUS_POWER: i64 = 10 << 40;
393}