FeeLimit Parameter Setting
Fee Limit is a parameter of the smart contract transaction, which is used to set the upper limit of the energy cost that the caller is willing to undertake for the deployment or invocation of the smart contract, in RAM (1PRC = 1e6 RAM). The default value is 0. Currently, the upper limit of fee limit can be set is 15000 PRC.
When executing the contract, Energy is calculated and deducted one by one instruction. If the energy used is exceeded, the contract execution will fail, and the deducted Energy will not be refunded. Therefore, before deploying or calling the contract, it is recommended to set an appropriate fee limit to ensure the normal execution of smart contract transactions. The following describes how to estimate the energy consumption of smart contract transactions and set the fee limit parameter.
How to determine the Fee Limit parameter?
Due to the Dynamic Energy Model mechanism, the energy consumption of well-known contracts undergoes dynamic changes. Consequently, invoking the same contract function during various time periods can lead to varying energy consumption. As a result, transactions calling these prominent contracts must configure distinct fee limit parameters in different time frames. Here, we present three approaches for establishing fee limit:
Estimate power before each PRC call Before each PRC interaction is initiated, the overall power usage of the interaction is appraised through API, and the Fee Limit parameter of the interaction is established based on the estimated power consumed
Retrieve the contract energy_factor once per maintenance cycle. Initially, ascertain the fundamental energy consumption of a contract function using the trigger constant contract API or based on the contract's historical usage. Subsequently, obtain the energy_factor parameter of a contract during each maintenance cycle:
Establish fee limits based on the max_factor parameter. Initially, ascertain the fundamental energy consumption associated with a contract function by utilizing the trigger constant contract API or referencing past historical data from the contract. Subsequently, retrieve the max_factor parameter specific to the chain. The max_factor represents the highest allowable ratio for the energy penalty coefficient, ensuring that fluctuations in the energy consumption of prevalent contracts do not surpass this predetermined maximum ratio:
The advantage of the initial approach lies in the precision of the fee limit setting, yet it comes with the drawback of a more intricate operation where each transaction requires estimation. In contrast to the initial method, the alternative method sustains the accuracy of the fee limit setting while necessitating the acquisition of the energy_factor parameter for the contract in each maintenance cycle, which occurs every 6 hours. The third approach excels in simplicity, eliminating the need for frequent retrieval of the max_factor parameter. However, it should be noted that the calculated Fee Limit may exceed the actual energy cost, as the majority of contracts may not attain the max_factor in their energy_factor.
How to estimate energy consumption?
Developers can call wallet/triggerconstantcontract API to estimate the energy consumption value of calling contracts.
An example is listed as follows:
It returns:
The PP.result.result=true in the example stands for the successful execution of estimating operation, the value of PP.energy_used is the estimated energy consumption of the transaction, where the basic energy consumption value is (PP.energy_used — PIP.energy_penalty), and value of PP.energy_penalty is the additional energy consumption.
The PIP.triggerconstantcontract API can be used to estimate the energy consumption value of calling most smart contracts on the PRC, such as PRCDD, PRCDT, PRCC, PRCTUSD, etc. Meanwhile, in the Java-Pollux 4.7.0.1 version, a new API of wallet/estimateenergy is added. Compared to the existing wallet/triggerconstantcontract API, the new API will be more accurate in estimating the energy consumption of calling a small number of special contracts. But for FullNode, enabling the wallet/estimateEnergy API is optional. So please pay attention that when developers call wallet/estimateEnergy, if the error message shows that the node does not support this function when calling the new API (this node does not support estimate energy), it is recommended to continue using the wallet/triggerconstantcontract API to estimate energy consumption.
An example is listed as follows:
It returns:
The outcome.outcome = true in the illustration signifies the prosperous completion of estimating operation. The energy_needed holds the estimated energy consumption of the transaction, encapsulating both the fundamental energy consumption and supplementary energy consumption.
Last updated