Concept of Transaction
A transaction is a single instruction composed by an external actor with a Conflux account, and this instruction is cryptographically signed using the sender account’s private key. A transaction can involve a simple transfer of CFX (the native currency of Conflux), a transfer of tokens (such as ERC20 or ERC721), a deployment of a new smart contract, or an execution of a function on an existing smart contract. Transactions are the only way to store or update data on the blockchain.
Generally speaking, a transaction contains:
Who send the transaction: A
fromfield in an unsigned transaction or the transaction signature fields indicating the signer. This tells the network who is responsible for initiating the transaction and who will pay for the fees.
What this transaction will do, including:
Who will be the transaction receiver or which smart contract to interact with(
tofield). This specifies the destination address of the transaction, which can be either user account or a smart contract that can execute some logic or empty to create a contract.
How much native token will be send(
valuefield). This indicates how much CFX (the native token of Conflux) will be transferred from the sender to the receiver. If the receiver is a smart contract, this value can also be used as an input parameter for its logic.
How to interact with a smart contract(
datafield). This contains additional information for calling a smart contract function or deploying a new smart contract. It can encode the name and arguments of the function to be invoked or the bytecode of the new contract to be created.
Transaction fee information, including:
Field(s) indicating base transaction fee (
gasin both spaces, and extra
storageLimitfield in core space). These fields is determine according to how much computational resources are required to execute the transaction and (in core space) how much storage space are occupied by its effects.
Field indicating how much "tip" sender is willing to pay to miner(
gasPricefield). This field allows senders to adjust their priority in getting their transactions packed by miners. A higher
gasPricemeans a higher chance of being included in a block sooner.
Field indicating when or where the transaction is "valid" (
noncein both spaces, and
epochHeightin core space).
chainIdprevents a transaction being executed on another chain and
noncefield ensures the sent transactions are executed in the expected order.
epochHeightfield sets an expiration time for the transaction based on the epoch number (a concept similar to "block number" in Ethereum). A transaction can only be executed within an epoch range associated with
Transactions go through several stages from the time they are constructed to the time they are finally confirmed on the chain. A good understanding of these stages will help users and developers better identify problems with sending transactions and ultimately ensure that transactions are successfully confirmed.
The following are the main stages of a transaction from construction to confirmation.
Transaction construction: This is the stage where users or developers create a transaction with all the necessary fields and parameters and get it signed. The transaction object can be created using various tools or libraries, such as Fluent Wallet, Conflux SDK, etc. The transaction will be encoded into a hex string as "rawTransaction" before it is sent.
Broadcast: This is the stage where users or developers send their signed transaction to a Conflux node via RPC or WebSocket. The node will validate the transaction and broadcast it to other nodes in the network if it passes the validation. The node will also return a transaction hash (a unique identifier) to the sender for tracking purposes.
Packed into a block -> Mined: This is the stage where miners select transactions from their mempool (a pool of pending transactions) and include them in their blocks. Miners will prioritize transactions with higher
gasPrice. Once a block containing a transaction is mined, it will be propagated to other nodes in the network.
Deferring 5 epochs -> Executed: This is the stage where transactions are executed by nodes after being deferred for 5 epochs (about 5 seconds). This means that nodes will run the logic of the transactions and update their state accordingly. The execution results of each transaction will be recorded in a receipt, which contains information such as status (success or failure), gas used, logs and events emitted by smart contracts and can be retrieved using transaction hash.
Waiting for about 50 epochs -> Confirmed: This is the stage where transactions are confirmed by nodes after being executed for about 50 epochs (about 50 seconds). A transaction is executed does not mean that the status of the transaction will not change anymore. Due to the structure of blockchain, the blockchain may fork or shift the main chain due to the arrival or creation of new blocks, which may revert certain transactions. A confirmed transaction means that it has been included in a "deep" enough block and has a extremely low probability of being reverted.
Waiting for PoS chain Finalization -> Finalized: This is the final stage where transactions are finalized after specific PoW block being referenced by Conflux's PoS chain. Conflux's PoS chain periodically refers a stable PoW block to provide finality for transactions. A finalized transaction means that it has zero probability of being reverted unless the attacker possesses more than 67% of the CFX staked in PoS. It takes approximately 4-5 minutes to finalize a transaction since it is included in a block (after CIP-113 activation).