Anyone who has some knowledge about blockchain technology knows what goes on during transactions. There are different blockchains, but in most cases, there are two stages to every transaction — signing and broadcasting. Firstly, the transaction gets signed before being sent off to the nodes, which receive it before running validation checks.
The transaction pool’s primary responsibility is to ensure that transactions are valid. In many cases, it has been found that the validity of a particular transaction is not hard-wired to its corresponding code in the pool but rather determined at runtime. Further, it checks all transactions and removes those deemed invalid or expired mortality transactions after multiple iterations.
The runtime calls Validate_transaction to ensure a valid signature and nonce to return a result. However, since this function is called in isolation — errors such as the same output being spent twice are not caught by validate_transaction.
While it’s true that Validate_transaction does not check if callers will call pallets, it could still be used as a DoS vector.
That said, Validate_transaction should insist on providing relevant information for nodes (pools) to order and prioritize transactions — rejecting all invalid or out-of-date transactions outright. This function will be called regularly, which means that even if one transaction went through successfully, its dependents might not after validate_transaction fails them because of the ordering issue.
If the transactions in the pool are valid, they are sorted into two groups:
Ready Queue — This contains transactions ready to be included in a new block. For runtimes built with FRAME, 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 in the ordered queue are included in the chain.
How are 5ire Transaction Pools Unique?
5ire aims to address the issue of scalability by breaking down transactions into multiple pools. It also speeds up transactions by running them simultaneously through a series of intertwined chains — this means that even if there are overlaps, they’re happening at different times, so it doesn’t affect how fast or slow any individual transaction will go.
More information about 5ireChain can be found by clicking on the following links:
Website: https://5ire.org
White paper: https://bit.ly/3Qcsmor
LinkedIn: https://www.linkedin.com/company/5ireChain
Twitter: https://twitter.com/5irechain
Discord: http://discord.gg/5ire
Telegram: https://t.me/OfficialFireChain
Facebook: https://www.facebook.com/5irechain
Instagram: https://www.instagram.com/5irechain
