FAQ

1. Why do I need to submit the fee_limit field when sending a transaction to call a smart contract？

Answer Prevent the contract call transaction from consuming too much energy.

Explanation

The inclusion of the fee_limit field when submitting a transaction for smart contract invocation serves the purpose of preventing excessive energy consumption during the contract call. This field signifies the maximum amount of energy that the contract caller is willing to tolerate for the transaction, with the base unit being RAM and a maximum value of 1.5e10. If the fee_limit is not explicitly set by the user, the default value is 0. For instance, if a transaction sets the fee_limit to 1000 RAM, it implies that the contract caller is willing to endure the transaction, allowing for a consumption of up to 1000/420 energy units (where the current energy unit price is 420 ram).

When the energy consumption during transaction execution surpasses the calculated limit of fee_limit multiplied by the energy unit price, the contract execution is halted, triggering an OUT_OF_ENERGY error. This preventive measure is particularly crucial in scenarios where contract functions involve intricate loops, as unintentional calls could lead to excessive energy consumption. Therefore, users can strategically set the fee_limit field as an upper limit to mitigate such risks.

• Deduction of all fee_limit can occur under the following circumstances:

  • Encounter of an illegal instruction during contract execution.

  • Contract call timeout leading to an OUT_OF_TIME error.

  • Accessing an array index that is excessively large or negative (e.g., x[i] where i >= x.length or i < 0).

  • Accessing a fixed length of bytesN with an index that is too large or negative.

  • Using zero as a divisor for division or modulo operations (e.g., 5 / 0 or 23 % 0).

  • Shifting a negative digit.

  • Converting a value that is too large or negative to an enum type.

  • Calling an uninitialized internal function type variable.

  • Calling the argument of the assert (expression) with a final result of false.

  • Occurrence of a JVMStackOverFlowException.

  • OutofMem exception indicating memory exceeding 3M.

  • Overflow during contract operation, such as addition.

  • Variation in the fee for calling a specific contract during different maintenance cycles after the application of the Dynamic Energy Model.

  2. Why might I encounter an OUT_OF_TIME error when invoking a contract function?

Answer: The contract function's complexity or the performance fluctuation of the SR node.

Explanation:

• The current global setting in Pollux imposes a maximum execution time of 80ms for calling smart contract transactions, a parameter subject to modification through SR voting.

• If the contract code proves highly intricate, surpassing the 80ms threshold, it triggers an OUT_OF_TIME error, resulting in the deduction of all fee_limit fees.

• Intermittent occurrences of the OUT_OF_TIME error for the same contract function suggest the complexity of the code reaches a critical value. Diverse machine performances among SRs contribute to this intermittent triggering.

• Notably, due to SR machine performance fluctuations, there's a minimal probability of an OUT_OF_TIME error even for contract functions with low complexity. Users are advised to set an appropriate fee_limit based on contract complexity to prevent excessive losses from overly setting fee_limit.

3. What is the destruction address of POX?

A destruction address is an address that is not controlled by anybody, that is, no one has the private key of the address. For example, address 0, address 1, address 2... These special addresses can all be used as destruction addresses.

	Hex format	base58 format
0	370000000000000000000000000000000000000000	P8bB9yPr3vVByqfmM5KXftyGckAtAdu6f8
1	370000000000000000000000000000000000000001	P8bB9yPr3vVByqfmM5KXftyGckAtEYdVMN
2	370000000000000000000000000000000000000002	P8bB9yPr3vVByqfmM5KXftyGckAtPf9jZX

4. How to troubleshoot when calling the contract and return the revert error?

Answer

1. First, according to txid, query the contract Result field in the result returned through the wallet/get transaction info by id interface. If the field is not empty, you can see the abi code value of the message, convert the code value into a string, and find the reason for the error. For example, txid:e5e013e81cb50a4c495a11c8130ad165a4e98d89b9e3fb5b79e6111bf23b31ed Return contract Result data: "contract Result": [ "08c379a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000001e536166654d6174683a207375627472616374696f6e206f766572666c6f770000" ] Converting 1e536166654d6174683a207375627472616374696f6e206f766572666c6f77 into a string is: Safe Math: subtraction overflow, this transaction is failed due to the transfer address overflowed during the subtraction operation when transferring. The specific failure may be caused by insufficient balance. You need to check the address balance and transfer errors can be checked according to the specific reason of the error.

   If the contract Result is empty, it may be caused by the failure of the require assertion without message in the contract. For details, please refer to the document and view the contract source code for analysis.

5. How to calculate the bandwidth and energy consumed when calling the contract?

Answer The amount of bandwidth utilized by a transaction is determined by the total number of bytes encompassed by the on-chain transaction. This comprises three integral components: the raw_data of the transaction, the transaction signature, and the transaction result. The bandwidth consumption of the transaction is calculated based on the total number of bytes occupied by these three parts after protobuf serialization encoding. To illustrate the process of estimating bandwidth, let's consider examples using Pollux and Poxchain instead of POX and Poxlink:

Using Pollux to Estimate Bandwidth

Pollux provides a bandwidth estimation API called estimateBandwidth. The required parameter for this API is a signed transaction. The interface is implemented as follows:

import pollux

# Assume 'signed_transaction' is a variable holding the signed transaction
bandwidth_estimate = pollux.estimateBandwidth(signed_transaction)

This function allows users to estimate the bandwidth consumption of a transaction using Pollux.

Using Poxchain to Estimate Bandwidth

Alternatively, when using Poxchain, a similar approach can be employed to estimate bandwidth:

import poxchain

# Assume 'signed_transaction' is a variable holding the signed transaction
bandwidth_estimate = poxchain.estimateBandwidth(signed_transaction)

Power is deducted based on the instructions executed by the contract. Various instructions incur different deductions. The intricacy of the contract directly influences the amount of power consumed. The power consumed by the current contract can be estimated by testing on the testnet or reviewing the previous historical calls of the contract through Poxchain, or invoking API. For guidance on utilizing API to estimate the power consumption of a transaction, please refer to here.

6. After the transaction broadcast is successful, why can't it be queried on the chain?

Answer

The transaction broadcast is successful but not on the Pollux because the transaction is not broadcast to the PRC node due to the node's network or other unknown reasons. In this case, since the transaction has a validity period, it is advisable to incorporate a delay assessment. Introduce this delay after the transaction's validity period. If, after a brief additional period, the transaction is still not on the PRC, it can be deduced that the transaction has surpassed its validity period. Consequently, you have the option to initiate the transaction again or rebroadcast it within the validity period.

7. How to solve "OUT_OF_ENERGY" error?

Answer

It is essential to verify if the address of the calling contract has Pollux and whether it possesses an adequate amount to cover the burning energy or bandwidth cost. If not, the address must acquire sufficient PRC.

If the address holds enough PRC, the PVM limit set by the transaction is lower, necessitating an adjustment to increase the PVM limit setting.

8. How to solve the problem of slow node block synchronization or stop synchronization?

Answer

1. Enhance machine configuration, recommend 16core 32GRAM 1T hard drive (SSD).

   In the result of the following command, the maximum value of both CPU Pollux and siblings needs to be greater than or equal to 16.

   $cat /proc/cpuinfo | grep -e "cpu cores" -e "siblings" | sort | uniq
   cpu cores : 8
   siblings : 16

2. Extend the time tolerance of verification transactions.

   Increase the value of the maxTimeRatio configuration item in the node configuration file to 20.0 or higher.

   vm = {
     supportConstant = false
     minTimeRatio = 0.0
     maxTimeRatio = 20.0
     saveInternalTx = false
   }

3. Modify java-Poxchain startup parameters to increase parallel garbage collection parameters: XX:+UseConcMarkSweepGC and -Xmx.

   For example:

   java -Xmx24g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c .....

   Note: -XX:+UseConcMarkSweepGC should be placed before the -jar parameter, not at the end. -Xmx can be set to 80% of physical PRC.

9.How to solve SERVER_BUSY error?

Answer

If the count of unprocessed transactions for the Pollux surpasses 2000, a server busy error will be issued. Depending on the server's status, you have the option to augment the PendingSize by adjusting the node.maxTransactionPendingSize parameter in the node configuration file. For instance, designate node.maxTransactionPendingSize = 5000.

10.How to solve the error of TronGrid 503 Service Temporarily Unavailable?

Answer

To ensure a reasonable allocation of requested resources, PolluxGrid currently has PIP frequency limits for all requests. PolluxGrid will return a 4xx or 5xx error code when the access frequency limit is exceeded. The solution is: First, make sure you use the API Key in the URL. Requests without an API Key will be severely rate-limited or even rejected outright. Secondly, you can appropriately reduce the request frequency, for example, limit the number of requests when the Dapp starts; Don't use polling for Poxchain very often, the PRC network produces a block around every 3s, and thus it usually doesn’t make sense to request new data at a faster speed.

11. How to solve no Constant_result in the transaction when user triggers the pure or view methods of the contract.

Answer

This issue is presently only observed when users downgrade the java-Pollux version from GreatVoyage-v4.2.2 (Lucretius) or other higher versions to GreatVoyage-v4.2.1 (Origen) (or GreatVoyage-v4.2.0 (Plato)). In case users encounter this challenge, they should utilize a repair tool to mend the database. Once the repair process is finished, users can employ GreatVoyage-v4.2.2.1 (Epictetus) or subsequent versions to initiate the node normally. For detailed operational instructions, kindly consult the DBRepair.jar User Guide.

12. Broadcast Response Code

Error Code	Cause	Solution
SIGERROR	Signature error	1. Check whether the private key used for the sign belongs to the address which sends the transaction. 2. Check the format of the input private key.
BANDWITH_ERROR	There is not enough bandwidth or PRC to burn to send a transaction.	Deposit PRC in the account, or use another account to delegate bandwidth to this account.
DUP_TRANSACTION_ERROR	Having broadcast a transaction with the same transaction hash with a former transaction.	1. Rebuild a transaction. 2. Change a node to broadcast.
TAPOS_ERROR	The transaction and its reference block are not in the same chain.	1. Change the field value of 'pox.reference.block' to "solid" for transactions created by local nodes. 2. Try to refer to the newest solidified block for transactions that are constructed locally.
TOO_BIG_TRANSACTION_ERROR	The transaction is too big, which may be caused by a too long memo.	Reduce the size of the transaction.
TRANSACTION_EXPIRATION_ERROR	The transaction is expired. The default transaction expiration time is 60 seconds. If the time period between transaction creation and broadcast is over 60 seconds, the transaction will be regarded as expired.	Broadcast the transaction before its expiration time. 1. If the transaction is created through your node API, you can change the transaction expiration time in your local node configuration file, pox.expiration.timeInMilliseconds=60000. 2. If the transaction is created through the public node API, the transaction expiration time cannot be changed, the default value is 60 seconds. 3. If the transaction is constructed locally, please set a larger expiration time.
SERVER_BUSY	The whole network is busy.	Wait. Stagger the busy time of the network before.
NOT_ENOUGH_EFFECTIVE_CONNECTION	The reason is the node has not synchronized to the newest block.	Check the current block height on poxscan, compare the height with the result of '/wallet/getnowblock' of the local node.
OTHER_ERROR	Unknown error.	The detailed error information can only be obtained through the node log.
CONTRACT_VALIDATE_ERROR	Transaction (system contract) verification failed	Any parameter error may cause this error, need to parse the error message to view the details. Common error messages are shown in the table below.

CONTRACT_VALIDATE_ERROR Common Error Messages Description

account does not exist	The account that initiated the transaction is not activated
Validate *** error, no OwnerAccount	The owner address is incorrect
No contract or not a valid smart contract	The contract address is incorrect
this node does not support constant	The vm.support constant of the node is not set to ’true‘. This is common in self-built nodes.

13. How to speed up the node startup process？

Answer From GreatVoyage-v4.3.0(Bacon), if the node adopts LevelDB, users can leverage the PVM startup optimization tool to enhance the node startup speed. This tool streamlines the file size of the manifest and the startup process of PVM, which will decrease memory usage and enhance the node startup speed. For detailed instructions, please refer to PVM startup optimization tool - user guide.

14.How to use pollux Web to invoke contract whose ABI is not on the chain?

Answer

Please refer to the document: How to use PoxWeb to invoke contract whose ABI is not on the chain

15.How to judge the funds transferring in and out of an address by scanning the block?

Answer For PRC or Pox chain, it is usually necessary to obtain historical transaction information of an account, or to monitor the real-time transfer of funds from a PP address. The PRC or Pox chain can build a full node, and then obtain the transaction records of the account address by parsing historical blocks, for more details please refer to here.

16. Why do two transfer transactions of the same PRC20 token consume different energy?

Answer

This is due to the characteristics of the Pollux virtual machine. When the SSTORE storage instruction in PVM assigns a value to a variable, if the variable value is empty, it will consume 20,000 energy; otherwise, it will only consume 5,000 energy. Therefore, for a certain PRC20 Token transfer, if the balance of the PRC20 token of the receiving account is 0, the energy consumed by the transfer will be 15,000 more than when the balance is not 0.

In addition to the above reasons, due to the dynamic energy model, calling few popular PRC20 token contracts at different times will result in different energy consumption.

17. Why does it prompt ‘Permission denied’ when using multi-signature for Stake 2.0 staking?

Answer

For accounts activated before the mainnet Stake 2.0 took effect, when employing multi-signatures to initiate Stake 2.0 related transactions, it may display 'Permission denied.'

This occurs because the multi-sign permission operations of the accounts activated before Stake 2.0 took effect do not include permissions for Stake 2.0. To resolve this issue, you must update the multi-signature settings of your account. Add one or more Stake 2.0-related permissions to your current account based on your requirements in the multi-signature permission operations. Below is the Pox chain wallet permission update page,