Deploying a smart contract is to generate a CreateSmartContract type transaction, which can be initiated through the fullnode API wallet/deploycontract. Following the creation, the next step is to sign and broadcast the transaction:
The transaction structure of different types of transactions remains consistent, with variations found in the rawdata content, particularly within the contract parameter value field.
In the contract deployment transaction, the contract parameter value encompasses the following details:
owner_address: address of the contract owner, i.e., the Contract deployer's address
new_contract: specifics of the new smart contract
origin_address: address of the smart contract owner
contract_address: address of the smart contract
ABI: ABI of the smart contract
bytecode: bytecode of the smart contract
call_value: amount of RAM sent to the smart contract
consume_user_resource_percent: user energy payment percentage
name: the name of the smart contract
origin_energy_limit: limit of the owner’s energy consumption for each transaction, in PIP
call_token_value: amount of PRC10 token sent to the newly created smart contract
token_id: PRC10 token ID
Smart contract invocation and query
triggersmartcontract
The PIP call is to generate a Trigger Smart Contract type transaction. You can create a triggering contract call transaction through the full node API wallet/trigger smart contract, after the transaction is created, it needs to be signed, then broadcasted to the entire PVM.
function parameter: the encoded parameter value of PRC method.
In this example, there are two parameters that should be passed in, namely address and uint256 type. For details on how to encode and decode the parameters, please refer to Parameter Encoding and Decoding chapter fee_limit: The upper limit of the energy consumed by the transaction that the caller is willing to undertake, please refer to the description of PIP limit call_value: amount of RAM that send to the smart contract
After the above command is executed successfully, the following results will be returned, including a contract calling transaction: transaction:
The contract parameter value in the contract call transaction contains the following:
owner_address: caller address
contract_address: contract address data: The contract function selector and its parameters, the first 4 bytes are the contract function selector, which is the first 4 bytes of the result obtained by performing the Keccak-256 operation on the contract function name and parameters, which is used for the virtual machine to find the function. The remaining bytes of data are the parameters of the function. For details on encoding and decoding, please refer to the Parameter Encoding and Decoding chapter. call_value: amount of PRC that send to the smart contract token_id: The token id of the PRC10 token sent to the contract call_token_value: amount of PRC10 token sent to the smart contract
trigger constant contract
To invoke the constant function of the contract through the full node api wallet/trigger contract cause it is a query operation and does not need to be chained, so no signature and broadcast are required
argument: The parameters to be passed in the contract method. For details on encoding and decoding, please refer to the chapter on parameter encoding and decoding.
constant_result: It is the result of querying the contract. In this example, the return value is of type uint256. For details on how to encode and decode the return value, please refer to the Parameter Encoding and Decoding chapter.
consume_user_resource_percent
Contract invocation requires payment of a certain resource fee. In order to encourage users to conduct contract transactions and reduce their invocation costs, the Pollux network supports contract deployers to share part of the contract invocation fee. When deploying the contract, the user's energy payment ratio can be set through the parameter consume_user_resource_percent.
The user energy payment ratio is the ratio of the energy paid by the user for smart contract execution. For example, if the user energy payout ratio is set to 60, the user pays 60% of the energy required for contract execution, and the developer (contract deployer) pays the remaining 40% of the energy. This parameter can only be an integer between 0 and 100 (inclusive 0 and 100). Developers are advised to appropriately increase the user's energy payment ratio to prevent users from attacking the contract and exhausting the contract owner's account resources.
After the contract is successfully deployed, the user energy payment ratio can also be modified. For example, the contract owner can modify it through the fullnode HTTP API wallet/updatesetting.
Note: Although the contract developer may need to share a certain percentage of the energy cost of the contract invocation, when the energy of the developer's account is not enough to pay for the part he or she needs to undertake, or the energy of the developer's account consumed by this invocation exceeds the value of origin_energy_limit, the rest is borne by the caller.
feelimit
The feelimit refers to 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). Currently, the upper limit of the energy cost that can be set is 15000 PRC. If the feelimit is set greater than 15000PRC, an error will be occurred.
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;
Before deploying the contract to the mainnet, it is best to set a reasonable feelimit. For example, when deploying large contracts or running complex functions, a larger feelimit is necessary. However, due to the existence of contract execution timeouts, infinite loops in contracts, illegal operations, and transfers to non-existing accounts, a relatively low feelimit would be the better option.