A Distributed Ledger Technology (DLT) is a decentralized log of records, the ledger, managed by multiple, usually autonomous, participants (also called users or subjects), across multiple nodes. A blockchain is a type of DLT where transactions are recorded according to an immutable order obtained by means of cryptographic hash functions that chain the blocks in which transactions are recorded. Since DLT gained attention through the diffusion of the blockchain, it is common practice to use the term blockchain even when talking about other types of DLT.
1. Blockchain and DLT Background
A Distributed Ledger Technology (DLT) is a decentralized log of records, the ledger, managed by multiple, usually autonomous, participants (also called users or subjects), across multiple nodes (for more details, see
[1]). At each instant of time, the ledger represents a unique state that is updated by atomic transaction; this update is essentially the appending of a new record to the ledger. Unlike a centralized database, a distributed ledger is decentralized; there is no need for a central authority or intermediary for processing, validating, and/or authenticating transactions.
A
blockchain is a type of DLT where transactions are recorded according to an immutable order obtained by means of cryptographic hash functions that chain the blocks in which transactions are recorded. Since DLT gained attention through the diffusion of the blockchain, it is common practice to use the term blockchain even when talking about other types of DLT. For this reason, in the rest content, the same common practice will be adopted . The most common blockchains can be abstracted as key-value stores. For example, in a blockchain implementing a cryptocurrency, keys are
addresses (also called
accounts), while values are the balances of their
wallets. In this scenario, a transaction is an operation that transfers cryptocurrency from one wallet to another. People call
pending transactions those that are generated by users but are not (yet) processed by the blockchain. A
confirmed transaction is an immutable transaction that was successfully processed by the blockchain. The state of the blockchain is a totally ordered sequence of confirmed transactions. For efficiency reasons, transactions are not confirmed one-by-one but aggregated into
blocks. Pending transactions are confirmed when a new block is hl
created (or hl
mined). The mining of a new block requires:
- (1) selecting a subset of pending transactions;
- (2) ordering them;
- (3) verifying that all transactions of the block, considered in the chosen order, comply with certain consensus rules (which depends also on the application domain).
The evaluation of the performance of blockchain is a complex task that requires one to compare technologies with fairly different approaches (e.g., permissionless vs. permissioned blockchain) in search of appropriate trade-offs, the most important of which are well captured in the blockchain trilemma. As an example, it is possible to gain fairly good scalability in permissioned blockchain where a limited number of nodes can participate in the consensus, thus limiting the complexity of permissionless blockchain where every node can participate. However, this improvement in performance is clearly paid in terms of decentralization.
Recent works such as
[2][3] are first attempts to provide a systematic survey of the performance of different blockchain approaches. While a number of performance metrics could potentially be considered in discussion, but only two of the most relevant will be focused in here: latency and transactions
throughput.
The
latency of a blockchain network is the time between the submission of a transaction to the network and the first confirmation of acceptance by the network in the blockchain. In certain technologies based on proof-of-work, after the first confirmation, the transaction becomes “more final” as more blocks are added beyond the initial confirmation. However, in the
IoT case, the first confirmation is usually enough. In particular, when the IoT application involves micropayments, the cost of undoing on confirmation is much higher than the obtained advantage. For example, vehicle rental applications
[4][5] may be based on micropayments, as well as the Helium
[6] ecosystem.
The
transactions throughput of a blockchain is the number of transactions handled per second, usually denoted by TPS.
Table 1 in
[2] shows that regardless of the adopted technology, in fairly limited evaluation environments that can only provide an upper bound on the performance, the latency is between about 0.1 s and 361 s, and the transactions throughput is between about 5 TPS and 6000 TPS. These numbers are in line with some other available performance evaluations
[7] where Bitcoin performs 7 TPS,
Ethereum 20, and Visa roughly 24,000 TPS.
Table 1. Classification of the applications in shown Table 2.
Latency requirements are clearly application dependent. However, many applications require some sort of
interaction with a human (e.g., a payment should be confirmed before the scooter is unlocked), which provides a guideline for latency. In the following, a latency comparable to the one necessary are considered equivalent to perform a payment by a credit/debit card, which involves the authorization of the card issuer, to be
low latency. In processing credit cards transactions, 5 s is considered an upper bound; however, 10 is still tolerable. Similarly, people consider the current throughput of credit card circuits, namely an order of tens of thousands of TPS, to be a high transactions throughput. In this case, this constraint is also relaxed, considering a high throughput of the order of thousands of TPS to be satisfactory.
According to the above considerations, the applications considered in Table 2 can be classified as shown in Table 1. Note that applications with low (bounded) throughput are rare, since IoT technology is pervasive and tends to scale to a large number of IoT devices, unless there is some intrinsic limit in the application domain. any relevant application that requires low latency and is not throughput demanding is impossible to find.