Transactions
Transactions Overview
A transaction in a blockchain platform is a message sent between nodes that changes the state of the blockchain. For example, when a transaction that sends 10 KAIA from Alice’s account to Bob’s is executed, Alice's balance decreases by 10 KAIA, and Bob's balance increases by 10 KAIA. Note that a transaction cannot be interleaved with another transaction because a transaction is an atomic operation. A typical blockchain transaction has components as shown below:
| Components | Description |
|---|---|
| value | The amount of KAIA in kei to be transferred. |
| to | The account address that will receive the transferred value. |
| input | Data attached to the transaction, used for transaction execution. |
| v, r, s | The cryptographic signature generated by the sender to let the receiver obtain the sender's address. |
| nonce | A value used to uniquely identify a sender’s transaction. If two transactions with the same nonce are generated by a sender, only one is executed. |
| gas | The maximum amount of transaction fee the transaction is allowed to use. |
| gasPrice | A multiplier to get how much the sender will pay in tokens. The amount of tokens the sender will pay is calculated via gas * gasPrice. For example, the sender will pay 10 KAIA for a transaction fee if gas is 10 and gasPrice is 10^18. Unit of KAIA is described here. |
Kaia Transactions
While typical Blockchain platforms provide a single transaction type, Kaia provides multiple transaction types that empower transactions with new capabilities and optimizations for memory footprint and performance.
Signature Validation of Transactions
In typical blockchain platforms, the address is derived from the public key which is derived again from the transaction signature. This is possible only if the address and the key pair are strongly coupled.
Since a key pair is decoupled from the address in Kaia, the sender address cannot be derived using the transaction signature. This is why Kaia transaction types except TxTypeLegacyTransaction have the field from. In Kaia, to validate a transaction, the AccountKey of from is obtained, and the obtained key is used to validate the transaction signature.
Fee Delegation
To provide businesses with the necessary flexibility in their business model design, Kaia provides a number of fee-delegated versions for its basic transaction types. These variants enable service providers to subsidize their end-user activities by paying for their transaction fees instead. Transaction fee subsidization can be further detailed by using transactions with the Ratio parameter, letting service providers designate the percentage of fees they would cover. Fee-delegation transactions require at least two signatures: one from the sender, and another from the fee payer.
SenderTxHash
SenderTxHash is a hash of a transaction without the fee payer's address and signature. The transaction hash of a fee-delegated transaction is not determined yet until the fee payer signs the transaction. To track a fee-delegated transaction, the sender should get the transaction hash derived from the complete transaction containing the signatures from both the sender and the fee payer. Since it is very hard for the sender to get the transaction hash, Kaia provides a SenderTxHash as well as the transaction hash. To find the complete fee-delegated transaction in the Kaia network, the sender generates the SenderTxHash and requests a transaction object via kaia_getTransactionBySenderTxHash. How to get the SenderTxHash depends on each transaction type, which is described in the description of each transaction type.
Each transaction type is described in detail: