## Smart Contract Deployment
Deploying a smart contract is to create a `CreateSmartContract
` type transaction, which can be created through the fullnode api [`wallet/deploycontract
`](🔗), and after the creation, then to sign and broadcast the transaction:
The return result:
The [transaction structure](🔗) of different types of transactions are the same, but the content contained in `raw_data
` is different, which is mainly reflected in the `contract.parameter.value
` field of the transaction.
The `contract.parameter.value
` in the contract deployment transaction contains the following:
`
owner_address
`: address of contract owner, that is Contract deployer address`
new_contract
`: details of the new smart contractorigin_address:address of 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 TRX that send 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 consuming for each transaction, in sun
`
call_token_value
`: amount of TRC10 token sent to the newly created smart contract`
token_id
`: TRC10 token id
## Smart contract invocation and query
#### triggersmartcontract
The contract call is to create a `TriggerSmartContract
` type transaction. You can create a triggering contract call transaction through the fullnode api [`wallet/triggersmartcontract
`](🔗) , after the transaction is created, it needs to be signed, then broadcasted to the entire network.
参数说明:
contract_address:contract address
owner_address: caller address
function_selector:contract function
parameter:the encoded parameter value of contract 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 [feelimit](🔗)
call_value:amount of TRX 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 TRX that send to the smart contract
token_id:The token id of the TRC10 token sent to the contract
call_token_value:amount of TRC10 token sent to the smart contract
#### triggerconstantcontract
To invoke the constant function of the contract through the fullnode api [`wallet/triggerconstantcontract
`](🔗), because it is a query operation and does not need to be chained, so no signature and broadcast are required :
参数说明:
contract_address:contract address
owner_address:caller address
function_selector:triggered contract method
parameter: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.
The return result is as follows:
`
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 TRON 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 to the energy paid by the developer. 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 need 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 sun (1TRX = 1e6 sun). Currently, the upper limit of the energy cost that can be set is 10000 TRX, which is 1e10 sun. If the feelimit is set greater than 1e10, an error will be occurred.
When executing the contract, Energy is calculated and deducted one by one instruction. If the feeLimit 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, relatively low feelimit would be the better option.