Intermediate
Transaction Fees
Welcome to our tutorial on Klaytn transaction fees. In the world of blockchain, transaction fees are a necessary component of maintaining the network and incentivizing node operators to validate and process transactions. In Klaytn, transaction fees are a key aspect of how the network functions and are used to pay for the computational resources required to validate and execute transactions. In this tutorial, we will explore the concept of Klaytn transaction fees in detail, including how they are calculated, how they are used, and their impact on the network. Whether you are a developer, researcher, or simply a blockchain enthusiast, this tutorial will provide valuable insights into the inner workings of Klaytn transaction fees and how they play a role in the functioning of the Klaytn network.
In Klaytn, transaction fees are a necessary component of maintaining the network and incentivizing node operators to validate and process transactions.
Transaction fees in Klaytn are calculated based on the amount of computational resources required to validate and execute a transaction. Each operation performed by a smart contract, such as a function call or storage read/write, costs a certain amount of gas. The total cost of a transaction is the sum of the gas costs of all the operations performed by the smart contract. The gas price is determined by the market, and it fluctuates based on the demand for computational resources on the network.
Transaction fees are paid in KLAY, the native token of the Klaytn network. The sender of a transaction must include enough KLAY to cover the transaction fees when sending a transaction. The transaction fees are then distributed to the node operators who validate and process the transaction, as a reward for their work.
Transaction fees serve several important functions in the Klaytn network:
-
They incentivize node operators to validate and process transactions, as they earn a reward for their work in the form of transaction fees.
-
They help to prevent spamming and denial of service attacks by making it expensive for malicious actors to flood the network with unnecessary transactions.
-
They help to ensure that the network has sufficient resources to process all the transactions by adjusting the gas price based on the demand for computational resources.
The impact of transaction fees on the network is mainly focused on the cost of performing transactions for the users, as well as the distribution of rewards for the node operators. High transaction fees can make it more expensive for users to perform transactions, which can discourage the use of the network. On the other hand, low transaction fees can make it less profitable for node operators to validate and process transactions, which can lead to a shortage of computational resources on the network.
In summary, Klaytn transaction fees are a key aspect of how the network functions, they are used to pay for the computational resources required to validate and execute transactions and they serve several important functions such as incentivizing node operators, preventing spamming and denial of service attacks and ensuring network resources.
The transaction fee for the current Klaytn virtual machine (KLVM) is calculated as follows:
(Transaction Fee) := (Gas Used) * (Base Fee)
-
The
Gas Used
is computed by KLVM based on the gas cost of the opcode and the intrinsic gas cost. -
Base Fee
is the actual gas price used for the transaction. It has the same meaning as theEffective Gas Price
.
This calculated transaction fee is subtracted from the sender’s or fee payer’s account balance, depending on the transaction.
Gas and Base Fee Overview
Gas
Every action that changes the state of the blockchain requires gas. When a node processes a user’s transaction, such as sending KLAY, using KIP-7 tokens, or executing a contract, the user has to pay for the computation and storage usage. The payment amount is decided by the amount of gas
required.
Gas
is a measuring unit representing how much calculation is needed to process the user’s transaction.
Dynamic Gas Fee Mechanism
Since the Klaytn v1.9.0 hard fork, a dynamic gas fee mechanism has replaced the existing fixed fee policy. Dynamic gas fee policy provides a stable service to users by preventing network abuse and storage overuse. The gas fee changes according to the network situation. Seven parameters affect the base fee(gas fee)
:
-
PREVIOUS_BASE_FEE: Base fee of the previous block
-
GAS_USED_FOR_THE_PREVIOUS_BLOCK: Gas is used to process all transactions of the previous block
-
GAS_TARGET: The gas amount that determines the increase or decrease of the base fee (30 million at the moment
-
MAX_BLOCK_GAS_USED_FOR_BASE_FEE: Implicit block gas limit to enforce the max basefee change rate (60 million at the moment)
-
BASE_FEE_DELTA_REDUCING_DENOMINATOR: The value to set the maximum base fee change to 5% per block (20 at the moment, can be changed later by governance)
-
UPPER_BOUND_BASE_FEE: The maximum value for the base fee (750 ston at the moment, can be changed later by governance)
-
LOWER_BOUND_BASE_FEE: The minimum value for the base fee (25 ston at the moment, can be changed later by governance)
Base Fee
The basic idea of this algorithm is that the base fee
would go up if the gas used exceeds the base gas and vice versa. It is closely related to the number of transactions in the network and the gas used in the process. There is an upper and lower limit for the base fee
to prevent the fee from increasing or decreasing indefinitely. There is also a cap for the gas and an adjustment value for the fluctuation to prevent abrupt changes in the base fee
. The values can be changed by governance.
(BASE_FEE_CHANGE_RATE) = (GAS_USED_FOR_THE_PREVIOUS_BLOCK – GAS_TARGET)
(ADJUSTED_BASE_FEE_CHANGE_RATE) = (BASE_FEE_CHANGE_RATE) / (GAS_TARGET) / (BASE_FEE_DELTA_REDUCING_DENOMINATOR)
(BASE_FEE_CHANGE_RANGE) = (PREVIOUS_BASE_FEE) * (ADJUSTED_BASE_FEE_CHANGE_RATE)
(BASE_FEE) = (PREVIOUS_BASE_FEE) + (BASE_FEE_CHANGE_RANGE)
The base fee
is calculated for every block; there could be changes every second. Transactions from a single block use the same base fee
to calculate transaction fees. Only transactions with a gas price higher than the block base fee
can be included in the block. Half of the transaction fee for each block is burned (BURN_RATIO = 0.5, cannot be changed by governance).
NOTE: An important feature that sets Klaytn apart from Ethereum’s EIP-1559 is that it does not have tips. Klaytn follows the First Come, First Served(FCFS) principle for its transactions.
Transaction Replacement
Klaytn currently does not provide a way to replace a transaction using the unit price but may support different methods for transaction replacement in the future. Note that in Ethereum, a transaction with a given nonce can be replaced by a new one with a higher gas price.
Klaytn’s Gas table
Basically, Klaytn is keeping compatibility with Ethereum. So Klaytn’s gas table is pretty similar to that of Ethereum. But there are some features unique to Klaytn that require several new constants.
Common Fee
Item |
Gas |
Description |
---|---|---|
G_zero |
0 |
Nothing paid for operations of the set Wzero |
G_base |
2 |
Amount of gas to pay for operations of the set Wbase |
G_verylow |
3 |
Amount of gas to pay for operations of the set Wverylow |
G_low |
5 |
Amount of gas to pay for operations of the set Wlow |
G_mid |
8 |
Amount of gas to pay for operations of the set Wmid |
G_high |
10 |
Amount of gas to pay for operations of the set Whigh |
G_blockhash |
20 |
Payment for BLOCKHASH operation |
G_extcode |
700 |
Amount of gas to pay for operations of the set Wextcode |
G_balance |
700 |
Amount of gas to pay for a BALANCE operation |
G_sload |
800 |
Paid for a SLOAD operation |
G_jumpdest |
1 |
Paid for a JUMPDEST operation |
G_sset |
20000 |
Paid for an SSTORE operation when the storage value is set to non-zero from zero |
G_sreset |
5000 |
Paid for an SSTORE operation when the storage value’s zeroness remains unchanged or is set to zero |
G_sclear |
15000 |
Refund given (added into refund counter) when the storage value is set to zero from non-zero |
R_selfdestruct |
24000 |
Refund given (added into refund counter) for self-destructing an account |
G_selfdestruct |
5000 |
Amount of gas to pay for a SELFDESTRUCT operation |
G_create |
32000 |
Paid for a CREATE operation |
G_codedeposit |
200 |
Paid per byte for a CREATE operation to succeed in placing code into state |
G_call |
700 |
Paid for a CALL operation |
G_callvalue |
9000 |
Paid for a non-zero value transfer as part of the CALL operation |
G_callstipend |
2300 |
A stipend for the called contract subtracted from Gcallvalue for a non-zero value transfer |
G_newaccount |
25000 |
Paid for a CALL or SELFDESTRUCT operation which creates an account |
G_exp |
10 |
Partial payment for an EXP operation |
G_expbyte |
50 |
Partial payment when multiplied by dlog256(exponent)e for the EXP operation |
G_memory |
3 |
Paid for every additional word when expanding memory |
G_txcreate |
32000 |
Paid by all contract-creating transactions |
G_transaction |
21000 |
Paid for every transaction |
G_log |
375 |
Partial payment for a LOG operation |
G_logdata |
8 |
Paid for each byte in a LOG operation’s data |
G_logtopic |
375 |
Paid for each topic of a LOG operation |
G_sha3 |
30 |
Paid for each SHA3 operation |
G_sha3word |
6 |
Paid for each word (rounded up) for input data to a SHA3 operation |
G_copy |
3 |
Partial payment for *COPY operations, multiplied by words copied, rounded up |
G_blockhash |
20 |
Payment for BLOCKHASH operation |
G_extcodehash |
700 |
Paid for getting keccak256 hash of a contract’s code |
G_create2 |
32000 |
Paid for opcode CREATE2 which bahaves identically with CREATE but use different arguments |
Precompiled Contracts
Precompiled contracts are special kinds of contracts that usually perform complex cryptographic computations and are initiated by other contracts.
Item |
Gas |
Description |
---|---|---|
EcrecoverGas |
3000 |
Perform ECRecover operation |
Sha256BaseGas |
60 |
Perform sha256 hash operation |
Sha256PerWordGas |
12 |
|
Ripemd160BaseGas |
600 |
Perform Ripemd160 operation |
Ripemd160PerWordGas |
120 |
|
IdentityBaseGas |
15 |
|
IdentityPerWordGas |
3 |
|
ModExpQuadCoeffDiv |
20 |
|
Bn256AddGas |
150 |
Perform Bn256 elliptic curve operation |
Bn256ScalarMulGas |
6000 |
|
Bn256PairingBaseGas |
45000 |
|
Bn256PairingPerPointGas |
34000 |
|
VMLogBaseGas |
100 |
Write logs to node’s log file – Klaytn only |
VMLogPerByteGas |
20 |
Klaytn only |
FeePayerGas |
300 |
Get feePayer’s address – Klaytn only |
ValidateSenderGas |
5000 per signature |
Validate the sender’s address and signature – Klaytn only |
The total gas of those items which has XXXBaseGas and XXXPerWordGas (e.g. Sha256BaseGas, Sha256PerWordGas) are calculated as
TotalGas = XXXBaseGas + (number of words * XXXPerWordGas)
ValidateSenderGas have to be paid per signature basis.
TotalGas = number of signatures * ValidateSenderGas
Blake2f gas cost is calculated based on the below formula. input
is the input of the blake2f call.
Gas = uint64(binary.BigEndian.Uint32(input[0:4]))
Account-related Gas Table
Item |
Gas |
Description |
---|---|---|
TxAccountCreationGasPerKey |
20000 |
Gas required for a key-pair creation |
TxValidationGasPerKey |
15000 |
Gas required for a key validation |
TxGasAccountUpdate |
21000 |
Gas required for an account update |
TxGasFeeDelegated |
10000 |
Gas required for a fee delegation |
TxGasFeeDelegatedWithRatio |
15000 |
Gas required for a fee delegation with ratio |
TxGasCancel |
21000 |
Gas required to cancel a transaction which has a same nonce |
TxGasValueTransfer |
21000 |
Gas required to transfer KLAY |
TxGasContractExecution |
21000 |
Base gas for contract execution |
TxDataGas |
100 |
Gas required per transaction’s single byte |
Gas for payload data is calculated below
GasPayload = number_of_bytes * TxDataGas
Gas Formula for Transaction Types
TxType |
Gas |
---|---|
LegacyTransaction |
TxGas + PayloadGas + KeyValidationGas |
ValueTransfer |
TxGasValueTransfer + KeyValidationGas |
ValueTransferMemo |
TxGasValueTransfer + PayloadGas + KeyValidationGas |
AccountUpdate |
TxGasAccountUpdate + KeyCreationGas + KeyValidationGas |
SmartContractDeploy |
TxGasContractCreation + PayloadGas + KeyValidationGas |
SmartContractExecution |
TxGasContractExecution + PayloadGas + KeyValidationGas |
Cancel |
TxGasCancel + KeyValidationGas |
KeyValidationGas is defined as below based on the key type,
Key Type |
Gas |
---|---|
Nil |
N/A |
Legacy |
0 |
Fail |
0 |
Public |
0 |
MultiSig |
(number of signatures – 1) * GasValidationPerKey (15000) |
RoleBased |
Based on keys in the role used in the validation |
KeyCreationGas is defined below based on the key type,
Key Type |
Gas |
---|
Key Type |
Gas |
---|---|
Nil |
N/A |
Legacy |
0 |
Fail |
0 |
Public |
GasCreationPerKey (20000) |
MultiSig |
(keys) * GasCreationPerKey |
RoleBased |
Gas fee calculated based on keys in each role. e.g., GasRoleTransaction = (keys) GasCreationPerKey GasRoleAccountUpdate = (keys) GasCreationPerKey GasRoleFeePayer = (keys) * GasCreationPerKey |