Execution Model
This page describes the execution model, the data structures, and the life cycle of Kaia smart contracts.
Execution Model
Transactions can be generated by platform APIs as described in Platform API Specification. These transactions are sent to Consensus Nodes (CNs) to be stored in a block. The CNs check whether each received transaction is valid. Valid transactions are stored in the transaction pool; otherwise, they are discarded. A CN selects the executable transactions in the current block in its transaction pool and executes them one by one.
To execute a transaction, the sender must pay some amount of KAIA as a transaction fee. This transaction fee in KAIA is calculated based on gas and a multiplier, i.e., unit price. A gas is the fundamental unit of computation. Every operation executed on a Kaia node consumes a predefined amount of gas. The exact amount of KAIA required for the transaction is calculated by the formula illustrated in Transaction Fees. The transaction can fail if the sender submits a transaction accompanied by insufficient gas. A transaction can also fail if the sender's account has an insufficient balance.
When a transaction is executed successfully, it is included in the current block. A CN gathers transactions until it reaches block gas limit or block time limit. Then, the CN makes a block with the transactions. This step requires filling several fields in the block. For example, it must calculate the hash values of transactions, receipts, state, etc. After all required fields have been completed, the CN generates a block hash.
When block generation is complete, the block is propagated to all the other CNs. The other CNs all verify the propagated block and reach consensus on the verification results by using the BFT consensus algorithm. When the verification process completes successfully by the majority of CNs, the block is stored in the blockchain. Because the BFT consensus algorithm satisfies the immediate finality property, the block is final and will never be removed. After a block is finalized, the execution of all the transactions in that block are irreversibly guaranteed, and their execution results can be returned to the sender if requested.
Enhanced Randomness in Block Proposer and Committee Selection
Kaia has implemented a new mechanism to introduce verifiable on-chain randomness in the block proposer and committee selection processes. This mechanism involves two new fields in the block header: randomReveal
and mixHash
.
In this system, block proposers generate and commit to random values. The randomReveal
field in a block contains the proposer's signature, generated using a specific signature scheme, and is calculated based on the current block number being proposed. The mixHash
is then computed using this revealed random value along with other block data, creating a source of randomness for the network.
The block proposer and committee selection processes utilize this generated randomness. The use of this randomness aims to make the selection processes more unpredictable and fair, enhancing the overall security of the network. One particular use case for this mechanism is allowing block proposers to remain private until the previous block is completed, adding an extra layer of security to the network.
The execution flow creates a cycle where each block's randomness influences future block proposer and committee selections. This introduces an element of unpredictability to these processes while maintaining their verifiability.
It's important to note that while this randomness is used in selection processes, rewards are still distributed at the end of block mining by directly modifying states, based on staking amounts. The randomness determines which validators are selected to be part of the committee that receives rewards, not the amount of rewards distributed.
Several security considerations are crucial to this mechanism:
- To prevent replay attacks, each
randomReveal
value must be unique for each block. - Block proposers must honestly generate and submit their
randomReveal
to prevent manipulation of themixHash
. - Proposers must keep their
randomReveal
secret until the block proposal to prevent prediction and potential manipulation by other participants. - The
randomReveal
must be properly signed and validated to prevent tampering.
This mechanism aims to introduce unpredictability in the block creation and committee selection processes while maintaining verifiability. It's important to note that while this system provides a framework for enhanced randomness, the specific implementations of proposer and committee selection algorithms using this randomness may evolve over time as the network develops and improves.
Restrictions on Transaction Execution
Kaia Mainnet and Kairos Testnet currently have the following restrictions on the transaction execution:
- You can set gasPrice of the transaction, but it means it's the most you can pay. The actual gasPrice will be determined by network. For more detailed information, see gas price overview
- A transaction which has bigger execution cost than the computation cost limit will be discarded. Please refer to computation cost
- As of the Shanghai hardfork, there is an additional gas cost for contract creation based on the length of the initcode, charged at 2 gas for every 32-byte chunk of initcode.