5ire ecosystem supports multiple chains that may branch out from the main chain and can progress separately only to be merged again in the future. This repeating process of creating smaller chains and merging them forms the base of the 5irechain and its scalabilty. In order to support this, the ecosystem uses multiple transaction pools. There is one transaction pool per chain having a unique serial number. A transaction is included in exactly one of these transaction pools. If there are ntransaction pools, then a transaction trwill go to one of these pools depending upon the first log nbits of the hash value of public key of the sender in tr. That is to say that, if the numeric value of the first log nbits of the hash value of the public key of the sender in tr is k, then the transaction trwill go to pool k. Let, there be n distinct transaction pools. These pools have numbers between 0 and n−1. When a new transaction T_x appears, it goes to the pool F(T_x)∈[0,n-1]. Here,
Here, 〖PT〗_x is the public key of the transaction sender.
The process of adding transactions to transaction pools has been depicted in Figure 1 Figure 3. In this figure, there are five distinct transaction pools having ids between 000 and 100. A new transaction T18 appears in the network. First, the public key of the sender of the transaction is hashed using a standard hash function, e.g. SHA-256. Then the first three bits of the hash output is chosen. The transaction goes into the pool whose id matches the first three bits of the hash output. In Figure 1, the first three bits of the hash output is 011, hence, the transaction T18 is added to the pool 011. Figure 4 shows how the transactions will be stored in different pools based on the starting bits of the hash of transactions. This will allow us to validate the concurrent blocks without overlapping transactions.