*3.2. Transaction Throughput*

The number of transactions processed by blockchain ledger is important for implementing decentralized applications where micro-payments should be exploited (e.g., Energy Sector, Media Services, etc.). Micro-payments are online transactions involving small amounts of money. These small amounts of money are often used in exchange for

different goods or services, and most of the time require many transactions over a period. The problems that arise by integrating the micro-payments are the high cost accumulated as a result of the mining fees paid for each transaction and the congestions problems at the level of the Protocol and Network Tier due to the small size of the block. The most promising solutions analysed are the Sharding, Sidechains, and Payment Channels (see Table 7).


**Table 7.** Transaction scalability solutions.

Sharding can be considered a suitable solution for increasing the transaction throughput as well as the storage [120]. Both improvements come because of introducing clusters of nodes responsible for specific categories of transactions. Higher transaction throughput may be provided by delegating the transactions to a different category of nodes and parallelizing the validation of these transactions. An issue arises when increasing the number of shards and transactions. When a transaction is sealed by a shard, it may reference a transaction that is not in the log of transactions of that shard. As a result, each time such a transaction needs to be validated, a cross-shard communication is required to issue Merkle Proofs of the referenced transaction. Consequently, increasing the number of shards and transactions will also introduce a communication overhead that may impact the scalability of the solution. More exact evaluations of the overhead introduced will be possible only after these currently researched solutions will offer a full specification and deployment on the public networks.

Sidechains [121,122] are proposed as alternatives for increasing the scalability of blockchain ledgers. A side chain is processing transactions in parallel with the main chain. The transactions of the sidechains are always rooted in a locking transaction in the main chain. Once proof of a locking transaction is made on the side chain, the actors may start using the assets by transacting on the side chain. To return to the main chain, proof of the latest state from the sidechain must be made to unlock the coins on the main chain. There are different reasons for connecting to side chains: testing new functionalities, extending the main chain functionalities (e.g., RootStock [123] enabling smart contract execution), or moving business-specific implementation to another less expensive chain (e.g., Plasma as a tree of sidechains [62]). In either case, moving part of the transactions from the main chain to side chains can lead to an improvement in the transaction throughput.

The sidechain implementation offers an alternative to sharding by fully relying on the information stored on the side chain and integrating with the main chain only when locking and unlocking the coins. This solution may offer some improvements to the underlying chain, by taking over some of the transitioning load. However, from a scalability perspective, the transaction throughput is still limited since the side chain is most of the time a blockchain ledger with the same constraints as any Protocol and Network Tier solutions. Additionally, some issues regarding the overall security of the systems need to be considered. Upon returning to the main chain, the transactions validated by the side chains are valid even if the validators' network of the side chain differs from the ones of the main chain.

The Payment Channels mainly implemented in Lightning Network solutions [124] are one of the best choices for improving transaction throughput. The mechanisms of the Lightning Networks were firstly defined for Bitcoin in [124], and future implementations have followed for other networks: Raiden for Ethereum [125] or Bolt for Zcash [126]. The Payment Channels aim to combine all the small payments into one large paymen<sup>t</sup> at the

end of a service period. The Lightning Network provides a point-to-point network that runs on top of the blockchain network as depicted in Figure 5.

**Figure 5.** Scalability Tier—Payment Channels Mechanism.

It relies on hash time locks and cryptographic secrets to ensure the reliability of offchain payments. The nodes in the Lightning Network exchange cryptographic signed transactions among them. They represent the payments exchanged between nodes offline. At any point, the payments can be deployed on the main chain to securely redeem the associated coins. Whenever two parties aim at exchanging many micro-transactions, the first step is to open a channel between them, represented on the blockchain as an opening transaction that locks the maximum amount of money that the two parties could transact off-chain. The transaction opening is signed by both parties involved. To unlock it both parties need to agree on the spending of the amount. Afterward, the parties will continue to exchange messages off-chain, namely, commitment transactions, which are designed as fail-safe mechanisms against cheating off-chain. Whenever a transfer occurs, determining a change in balances, each party creates one commitment transaction specifying the updated balances, signs it, and sends it offline to the other party. Upon receiving the commitment any party can successively sign it and publish it on-chain to redeem the coins or can wait and make other off-chain transfers and return only with a future commitment transaction on-chain. To prevent any party to return to the chain with a deprecated and more favorable commitment transaction, secret-locking and time-locking mechanisms are incorporated. They provide a fail-safe mechanism such that any party acting fraudulently risks losing all the money in favor of the other channel party.

The benefit of transferring over a route is the reduction of the cost associated with the opening transactions required on-chain each time a channel is required with a specific party. For sending the transactions through a path that requires intermediary parties (hop nodes) to route the messages, additional security mechanisms are required to ensure the correct delivery of the transacted assets. For successfully issuing a routed transfer, a commitment transaction is exchanged between every two parties involved in the path channels. Hash Time-Locked Contracts [127] have been defined over the previously presented mechanism, to prevent the intermediary to unlock the routed commitments before the receiver can confirm the payment. Upon confirmation, a proof is issued by the recipient and sent to the intermediary to unlock the hash-locked commitment. If the proof is not provided during an established period (time lock) then the intermediary will no longer be able to claim the payment.

The Payment Channels offers the best scalability solution. It is implemented without relying on any third parties and provides higher transaction throughput, promising millions of transactions per second. However, once the network has many users it is more difficult to find a viable route between two parties. The most desired topology of the lightning network would be a completely decentralized network. In this case, each node has connections with other nodes, together forming a mesh of channels that are part of a connected graph. However, to be able to route money from one point to another, all the nodes from the path need to have at least the same amount of money as the one requested by the initiator. Taking advantage of this issue motivates some actors of the system to open channels with a larger number of parties and fuel the channels with enough money to be able to route and connect different parts of the network, acting like large routing hubs in exchange for small fees.
