Anyone familiar with blockchain technology understands how transactions are processed. In most blockchain systems, the transaction pool contains all transactions (signed and unsigned) that are broadcasted to the network. These transactions then get received and validated by the local node.
Validation
It’s the primary job of the transaction pool to check for transaction validity. Often, the case is that the transaction’s validity is not hard-wired to the transaction pool; rather, it is defined by the runtime.
The transaction pool also does timely checks of the validity of existing transactions within the pool. After several iterations, a transaction gets dropped from the pool if it is found to be invalid or happens to be an expired mortal transaction.
It is important to note that the validate_transaction is called from the runtime to ensure a valid signature and nonce to return a result. But, remember that validate_transaction is called in isolation, so it will not catch errors such as the same output being spent twice.
Although it is possible, validate_transaction does not check whether calls to pallets will succeed. It is a potential DoS vector since all transactions in the network will be passed into validate_transaction.
The validate_transaction function should insist on providing the necessary data for the pool to order and prioritize transactions and instantly reject all transactions that turn out to be invalid or outdated. The function will be called regularly, potentially many times, for the same transaction. It is also possible that validate_transaction may fail a dependent transaction that would successfully go through execute_block if executed in the correct order.
Sorting
If the transactions in the pool are valid, they are sorted into two groups:
Ready Queue — This contains transactions that are ready to be included in a new block. For runtimes built with FRAME, it is essential that transactions must follow the exact order they are placed in the ready queue.
Future Queue — This has transactions that have a chance of becoming valid in the future. For instance, a transaction may have a nonce that is too high for its account. Such transactions will wait in the queue until the transactions ahead of them in the ordered queue are included in the chain.
Although it’s possible to create a custom runtime to eliminate the queues’ strict transaction queuing system. This would allow full nodes to apply different strategies on transaction propagation and block inclusion.
In contrast to such processes, the 5ire transaction pools address scalability and speed up transaction processing.
How Transaction Pools Make 5ire Unique — 5ire addresses the problem of scalability by using different transaction pools. Existing blockchains use a single transaction pool where all transactions are stored with every node. 5ire distributes the transactions based on wallet addresses, and each transaction pool serves unique addresses. This helps in concurrently processing the transactions through nested chains without worrying about transactions overlapping, thus increasing the speed of transactions.
More information about 5ireChain can be found by clicking on the following links:
Website: https://5ire.org
LinkedIn: https://www.linkedin.com/company/5ireChain
Twitter: https://twitter.com/5irechain
YouTube: https://youtube.com/c/5ireChainOfficial
Discord: https://discord.gg/5ire
Telegram: https://t.me/OfficialFireChain
