Resource Model
Voting Rights, bandwidth, and energy are crucial system resources within the Pollux network. Among these, voting rights are employed for casting votes in favor of super representatives. Bandwidth serves as the metric to gauge the size of transaction bytes stored in the blockchain database. The greater the transaction size, the higher the consumption of bandwidth resources. Energy is the unit measuring the computational demand imposed by the Pollux Virtual Machine (PVM) during specific operations on the Pollux network. Given that the execution of smart contract transactions necessitates computing resources, each smart contract transaction mandates payment for the associated energy fee.
Voting Right
Before any account can vote for super representatives, it must acquire voting rights, known as Pollux Power (PP). Voting rights are acquired by staking POX . Staking POX not only secures bandwidth or energy but also grants voting rights simultaneously. A stake of 1POX results in the allocation of 1PP to the voter.
Voters have the flexibility to stake multiple times, and the voting rights accumulated through multiple stakes are aggregated and reflected in the voter's account. To inquire about the total number of voting rights owned by the account and the number of used voting rights, voters can utilize the wallet/get account resource interface.
For detailed instructions on how to stake, please refer to the Staking on Pollux Network chapter.
Bandwidth
All types of transactions within the Pollux network require the consumption of Bandwidth Points. Transactions are transmitted and stored in the Pollux network as byte arrays. Each byte in a transaction corresponds to one Bandwidth Point. Therefore, the Bandwidth Points needed for a transaction are equivalent to the number of transaction bytes.
In cases where the available bandwidth is inadequate, POX needs to be burned to cover the cost of Bandwidth Points:
How to get Bandwidth Points
Each external account is allocated 600 free bandwidth per day. Additional bandwidth can be acquired by staking POX. The distribution of bandwidth among users is proportionate to the amount of staked POX. The total fixed daily bandwidth supply for the entire network is 43,200,000,000.
The following formula can be employed to calculate the bandwidth obtainable by staking a specific amount of POX:
[ \text{Bandwidth Obtained} = \left( \frac{\text{Staked POX}}{\text{Total Staked POX in the Network}} \right) \times \text{Total Daily Bandwidth Supply} ]
You can obtain the total amount of POX staked for acquiring bandwidth throughout the entire network using the wallet/getaccountresource interface.
To stake POX and acquire bandwidth, you can initiate a FreezeBalanceV2Contract type of transaction. The following example illustrates how to create a FreezeBalanceContract type of transaction using wallet-cli:
Bandwidth Points Consumption
In addition to query operations, every transaction requires bandwidth consumption. The rules for bandwidth points consumption are as follows:
First, verify if the transaction initiator has sufficient bandwidth obtained through staking P . If sufficient, consume the staked POX bandwidth.
If the staked POX bandwidth is insufficient, check if the transaction initiator has enough free bandwidth. If yes, consume the free bandwidth.
If both staked POX bandwidth and free bandwidth are insufficient, then POX will be burned to cover the transaction's bandwidth cost at a unit price of 0.001POX per bandwidth.
Bandwidth Points Recovery
After the account's free bandwidth and the bandwidth obtained by staking POX are consumed, they will gradually recover within 24 hours.
Account Bandwidth Balance Query
First, utilize the node HTTP interface wallet/getaccountresource to fetch the current resource status of the account. After obtaining this information, calculate the bandwidth balance using the following formula:
{Bandwidth Balance} = {Total Bandwidth} - {Used Bandwidth} ]
Note: If the result returned by the interface does not contain the parameters in the above formula, it means that the parameter value is 0.
Energy
The execution of each instruction within a smart contract consumes a specific amount of energy during runtime. Contracts of varying complexity entail different energy consumption levels. As the contract is executed, the Energy is computed and deducted per instruction. In instances where the account's available energy is inadequate, POX needs to be burned to cover the corresponding energy costs.
How to get Energy
Energy can only be acquired by staking POX . Users collectively share a fixed amount of energy based on the number of staked POX. The daily fixed total energy supply for the entire network is 90,000,000,000.
The formula to calculate the energy obtained by staking a specific amount of POX is as follows:
{Energy Obtained} = {Staked POX}/{Total Staked POX in the Network}*{Total Daily Energy Supply}
Energy Consumption
When the contract is executed, Energy is computed and deducted on a per-instruction basis. The priority of account energy consumption is as follows:
Energy obtained by staking POX
Burn POX
First, the energy acquired through staking POX will be utilized. If this portion of energy proves insufficient, the account's POX will be systematically burned to cover the energy resources required for the transaction, based on a unit price of 0.00042 POX per energy.
If the contract exits due to a revert exception during execution, only the energy consumed by instructions already executed will be deducted. However, for abnormal contracts, such as contract execution timeouts or abnormal exits due to bugs, the maximum available energy for the transaction will be deducted. To control the maximum energy cost of the transaction, you can set the fee_limit parameter of the transaction.
Energy Recovery
After the account's energy resources are depleted, they will gradually recover within 24 hours.
Account Energy Balance Query
First call the node HTTP interface wallet/getaccountresource
to obtain the current resource status of the account, and then calculate the energy balance by the following formula:
Note: If the result returned by the interface does not contain the parameters in the above formula, it means that the parameter value is 0.
Dynamic Energy Model
The dynamic energy model serves as a resource-balancing mechanism within the Pollux network. It dynamically adjusts the energy consumption of each contract based on the resource occupancy of the contract. This dynamic adjustment aims to ensure a more rational allocation of energy resources on the chain, thereby preventing the excessive concentration of network resources on a few widely-used contracts. For additional information, please refer to the "Introduction to Dynamic Energy Model."
Principal
If a contract utilizes an excessive amount of resources within one maintenance cycle, a certain percentage of punitive consumption will be added in the subsequent maintenance cycle. As a result, users sending the same transaction to this contract will incur higher energy costs than before. However, when the contract utilizes resources more reasonably, the energy consumption generated by users calling the contract will gradually return to normal.
Each contract features an energy factor field, which denotes the increased ratio of the energy consumption of the smart contract transaction relative to the base energy consumption. The initial value of this field is set to 0. When the energy factor of the contract is 0, it signifies that the contract is utilizing resources reasonably, and there is no additional energy consumption for calling the contract. Conversely, when the energy factor is greater than 0, it indicates that the contract has gained popularity, and additional energy will be consumed when calling the contract. The energy factor of a contract can be queried through the getcontractinfo API.
The calculation formula for the final energy consumed by the contract invocation transaction is as follows:
The dynamic energy model introduces three parameters within the Pollux network, which collectively control the energy_factor field of a contract:
threshold:
Represents the threshold for the basic energy consumption of a contract. If, during a maintenance cycle, the basic energy consumption surpasses this threshold, the energy consumption of the contract will increase in the next maintenance cycle.
increase_factor:
If the basic energy consumption of the contract exceeds the threshold in a given maintenance cycle, the energy_factor will increase by a certain percentage according to the increase_factor in the subsequent maintenance cycle.
max_factor:
Denotes the maximum value that the energy_factor of the contract can reach. Even if the basic energy consumption exceeds the threshold, the energy_factor will not exceed this maximum value.
Additionally, there is a variable:
decrease_factor:
Set at 1/4 of the increase_factor. After the basic energy consumption of the contract falls below the threshold, the energy_factor will be reduced by a certain percentage according to the decrease_factor.
When the basic energy consumption of the contract exceeds the threshold during a maintenance cycle, the energy_factor increases in the next maintenance cycle. However, the increase is capped at max_factor. Conversely, when the basic energy consumption falls below the threshold, the energy_factor is reduced by a percentage determined by decrease_factor. The calculation formula is not provided in your message; if needed, please provide the calculation formula, and I can assist further.
When the basic energy consumption of a contract falls below the threshold in a maintenance cycle, the energy factor will decrease in the next maintenance cycle. However, the minimum value for the energy_factor will not be lower than 0. The calculation formula for this decrease is as follows:
where:
{new_energy_factor}) is the energy factor for the next maintenance cycle.
{old_energy_factor}) is the current energy factor of the contract.
{decrease_factor}) is the factor determining the percentage decrease.
This formula ensures that the energy_factor is reduced by a certain percentage but is limited to a minimum value of 0.
The dynamic energy model has been enabled on the main network, and the relevant parameters are set as follows:
threshold
:3,000,000,000increase_factor
:0.2max_factor
:1.2
Given the varying energy consumption of popular contracts in different maintenance cycles, it becomes essential to set the appropriate "fee_limit" parameter when calling the contract. Further details and guidance on setting the transaction fee limit can be found in the "set transaction feelimit" documentation.
API
The following table shows the relevant interfaces of the dynamic energy model and their descriptions:
Last updated