Confirm Transaction

Transaction pool

The transaction pool contains all transactions (signed and unsigned) broadcasted to the network that has been received and validated by the local node. There is an exceptional case that the network is overloaded with transactions, and the transactions are not put into the pool.

Validity

The transaction pool checks for transaction validity. Example validity checks are:

• Checking if the Transaction Index (nonce) is correct.

• Checking if the account has enough funds to pay for the associated fees.

• Checking if the signature is valid.

The transaction pool also regularly checks the validity of existing transactions within the pool. A transaction will be dropped from the pool if it is found to be invalid or is an expired mortal transaction. Take an example of unsigned transactions which are put into the pool and waiting for signing before being checked for validity. If it hasn’t been signed for a certain period of time (also called time-out), it will be automatically canceled by the system. In case it is signed, the transaction must be charged with a fee before it is included in the block.

Sorting

If the transaction is valid, the transaction queue sorts transactions into two groups:

• Ready Queue - Contains transactions that can be included in a new pending block. It means that these transactions are used to construct a block. The transactions must follow the exact order in the ready queue since transactions in the front of the queue have a higher priority and are more likely to be successfully executed in the next block.

• Future Queue - Contains transactions that may become valid in the future. For example, a transaction may have a nonce that is too high for its account. This transaction will wait in the future queue until the preceding transactions are included in the chain.

It is noted that when nodes pick and include transactions in a new pending block, transactions can be overridden with a new one that is charged with a higher fee.

As to revenue sharing, there are 2 types of tnx: tnxs from whitelisted smart contract address and tnxs from unwhitelisted smart contract address. Both of them come into the future queue. Then based on the criteria of agreeing on sharing revenue with the network:

• The tnxs from whitelisted smart contract address will be put into the ready queue first.

• The tnxs from unwhitelisted smart contract address is held in the future queue for a default delay time before being put into the ready queue.

Transaction Dependencies

The ValidTransaction struct defines the requires and provides parameters to build a dependency graph of transactions. Together with priority (discussed below), this dependency graph allows the pool to produce a valid linear ordering of transactions.

For runtimes built with FRAME, the nodes order transactions with an account-based system. Every signed transaction needs to contain a nonce, which is incremented by 1 every time a new transaction is made. For example, the first transaction from a new account will have nonce = 0 and the second transaction will have nonce = 1.

As a result, all transactions coming from a single sender will form a sequence in which they should be included.

Transaction Priority

Transaction priority in the ValidTransaction struct determines the ordering of transactions that are in the ready queue. If a node is the next block author, it will order transactions from high to low priority in the next block until it reaches the weight or length limit of the block.

For runtimes built with FRAME, priority is defined as fee that the transaction is going to pay. For example:

• If we receive 2 transactions from different senders (with nonce=0), we use priority to determine which transaction is more important and included in the block first.

• If we receive 2 transactions from the same sender with an identical nonce, only one transaction can be included on-chain. We use priority to choose the transaction with a higher fee to store in the transaction pool.