Expand description
Nominated Proof of Stake Config
Structs§
- The numbers configured here could always be more than the maximum limits of staking pallet to ensure election snapshot will not run out of memory. For now, we set them to smaller values since the staking is bounded and the weight pipeline takes hours for this single pallet.
- The number of eras that historical staking data is kept in storage. This depth determines how far back the system keeps records of staking events and rewards for historical queries and audits. Older data beyond this depth will be pruned to save storage.
- The maximum number of controllers that can be included in a deprecation batch when deprecated staking controllers are being phased out. This helps manage the process of retiring controllers to prevent overwhelming the system during upgrades.
- This value is set to 90% of the maximum allowed block length for normal transactions. It ensures that miner solutions do not consume too much block space, leaving enough room for other transactions.
- The maximum weight (computational limit) allowed for miner operations in a block. This ensures that the block has enough space left for miner operations while maintaining a limit on overall block execution weight.
- This priority level determines the order in which unsigned transactions are included in blocks relative to other transactions.
- A source of random balance for NposSolver, which is meant to be run by the OCW election miner.
- The number of blocks before an off-chain worker repeats a task. Off-chain workers handle tasks that are performed outside the main blockchain execution, such as fetching data or performing computation-heavy operations. This value sets how frequently these tasks are repeated.
- The reward curve used for staking payouts. This curve defines how rewards are distributed across validators and nominators, typically favoring higher stakes but ensuring diminishing returns as stakes increase. The curve is piecewise linear, allowing for different reward distribution models.
- Virtual reward pool wallet
- This deposit ensures that larger signed transactions incur higher costs, reflecting the increased resource consumption they require. It is set to 10 milliANLOG per byte.
- This percentage increase applies to deposits for multiple or repeated signed transactions. It is set to 10%, meaning that each additional submission after the first will increase the required deposit by 10%. This serves as a disincentive to spamming the system with repeated submissions.
- This deposit ensures that users have economic stakes in the submission of valid signed transactions. It is currently set to 1 ANLOG, meaning participants must lock 1 ANLOG as
- This phase determines the time window, in blocks, during which signed transactions can be submitted. It is calculated as the duration of one the four epochs during an era.
- This represents the fixed reward given to participants for submitting valid signed transactions. It is set to 1 ANLOG token, meaning that any participant who successfully submits a signed transaction will receive this base reward.
- The number of eras after a slashing event before the slashing is enacted. This delay allows participants to challenge slashes or react to slashing events. It is set to 1/3 of the BondingDuration.
- Configuration of benchmarking bounds
- This phase determines the time window, in blocks, during which unsigned off-chain transactions can be submitted. Like the signed phase, it is calculated as the duration of one the four epochs during an era.
Constants§
- Upper limit on the number of NPOS nominations.
- Maximum number of iterations for balancing that will be executed in the embedded OCW miner of election provider multi phase.