Blockchain-based IOT solutions are well suited for simplifying business processes while reducing overall costs and security threats. As an example, IoT can exploit blockchain technology to build trust among untrusted devices or federated IoT areas, reduce infrastructure costs, and accelerate data exchanges.
Currently, connections among non-trusted devices pass through remote nodes (e.g., cloud systems) even if IoT devices are within a few meters from each other. This brings a number of significant disadvantages such as high maintenance costs, weakness for supporting time-critical IoT applications [1], security and trust issues.
Adopting a standardized blockchain model among the billions of devices envisioned in the IoT domain [2] would significantly reduce the costs associated with centralized and remote data and computation centers. While the literature offers some examples of blockchain deployment in IoT [3], up to now there is no de facto standard solution. Due to the massive number of devices and resource constraints, deploying blockchain in IoT while maintaining a good balance of the triad performance-scalability-reliabilty is particularly challenging. The optimal blockchain architecture has to scale to many IoT devices and it should be able to process a high throughput of transactions.
Every Blockchain solution is a tradeoff of performance, scalability and reliability
To this, consensus algorithms assume a central role since they are the groundbase of any existing Blockchain and define how transactions are validated. While the initial rationale behind Blockchain was its capability to ensure consensus among untrusted parties in a public and freely accessible network, further developments have broadened the plethora of transaction validation as well as the means of access restriction and blockchain node organization (private, federated, distributed, or public) in order to shape the triad performance-scalability-reliability according to the particular needs of a certain domain. IoT is not an exception. In the following paragraphs, the current state of the art in blockchain consensus is presented before discussing ongoing standardization efforts related to blockchain deployment in IoT federated networks.
The most classic consensus mechanism, which is also the one implemented by the most popular and oldest digital currency (Bitcoin) is the Proof of Work (PoW). In PoW, nodes willing to participate in the creation of new blocks of transactions for the chain (namely miners) solve computationally hard problems in order to be granted such permission. Since various miners (honest or not) might attempt to add blocks to the chain, PoW relies on the concept of the longest chain as the most trustworthy. This poses the following problems:
- Computational power means powerful calculators consuming energy but having just one miner per block being successful
- Block generation time is a tradeoff between speed and security
- The added blocks have to be validated by the entire blockchain network, resulting in small throughput
Last but not least, PoW is a game of brute force without any binding rules, which we could compare, in history, to those times when the strongest army would win. This means that the rationale of a decentralized system is not necessarily true. The recent hashwar that brought to the hard fork of Bitcoin Cash (BCH) into BCH ABC and BCH SV has revived this point of discussion showing the inherent lack of democracy that PoW has.
In PoS, blocks to be added to the blockchain are selected by a voting procedure involving all blockchain nodes that have a stake.Their voting power is related to their stake. This means that no energy is wasted in a computational task ending in itself. In case of a fork, nodes decide which fork to support. Due to this last point, a well-known problem of this consensus mechanism is the so called “Nothing at Stake,” where nodes can vote for both sides of every fork that happens without any computational effort required, thus mining the credibility of the blockchain.
Concerning PoS democracy, while a stake of more than 50% would allow control of the blockchain, it is believed that such a big stake amount is hard (yet not impossible) to own. Nevertheless, voting power modifications of PoS are considered, where weighting the stake by other properties, such as the time a certain stake has been owned, is used. While all these countermeasures might improve security, they are strictly related to the domain of interest and the way stakes are used by blockchain nodes.
In DPoS, token owners vote to elect delegates to validate blocks on their behalf. The voting power is dependent on the number of tokens and the votes can be redirected at any time. The number of delegates depends on the blockchain but are usually in the range of dozens. As an example, EOS Blockchain has 21 delegates also called block producers. Blocks are delivered by block producers in a shuffled order. By apriori selecting block producers, the blockchain can be designed to run more efficiently and with higher throughput and lower block production times (in the fraction of seconds) without the drawbacks found in PoW and PoS. Indeed, in DPoS block producers collaborate to make blocks instead of competing like in PoW and PoS. In addition, the EOS Blockchain does not charge nodes for transactions, but rather considers their stakes as determining the amount of network, cpu, and RAM power that nodes can use.
In PoA, transactions are validated by approved accounts (the authorities). This allows high throughput (as in the case of DPoS) but with an oligarchic rather than democratic approach. For this reason, PoA finds its best application in private blockchains where apriori trusted nodes are used because of the scalability and performance benefits, despite the lack of decentralization.
Proof-of-Weight is a general term used to refer to consensus algorithms leveraging on some kind of node property that determines their power in the consensus procedure. It can thus be considered as a further generalization of PoS and PoW. Indeed the weight could be the stake or the computational power, but also something different that is related to the specific application domain of the blockchain. As an example, the concept of trustworthiness in the Social Internet of Things [4] could be used.
BFT consensus algorithms apply solutions derived from the Byzantine generals problem to the Blockchain. In the Byzantine generals problem, a certain number of generals are separated by distance and have to pass messages through the enemy zone in order to communicate and converge to an agreement on whether to attack the enemy or not. A partial agreement would result in a defeat (namely a fault). Some of the consensus algorithms found in the literature derive from BFT. As an example, in Practical Byzantine Fault Tolerance (PBFT), groups of nodes share a leader who is elected using an election algorithm. If the leader fails, a new leader will be elected and a new group is created. This consensus mechanism typically requires multiple rounds among nodes to reach an agreement, which leads to huge communication overhead and limits scalability and its use in a public Blockchain in which the choice of leaders could be problematic.
DAGs use a form of consensus that handles transactions asynchronously and in which every node willing to make transactions can do so by validating previous transactions. This theoretically opens up to a number of transactions per second, which is not upper-bounded. The most well-known consensus algorithm in DAG is the Tangle, which is used in the IOTA implementation. In the Tangle, in order to send a transaction, two previous transactions that have been received need to be validated. This policy strengthens the validity of transactions as more transactions are added to the Tangle. However, if not many transactions are made and a single node can generate one third of the total transactions, it could take over which validations are labeled as true. For this reason, IOTA uses the concept of a “coordinator” that checks the validity of transactions in the booting phase during which not many nodes participate. The good thing about Tangle is that it is designed with IoT micro-transactions in mind. However, it does not provide an architecture or data structure to decentralize IoT and it is not Turing complete, meaning that scripts and smart contracts are not allowed.
Consensus algorithms for the Blockchain
The IEEE 1931.1 Working Group is currently working on the definition of an Internet standard for technical and functional interoperability of federated IoT systems for Real-Time Onsite Operations Facilitation (ROOF) that operate and function in a secure, semi-autonomous, and decentralized manner. Blockchain technology can play a key role in accomplishing this goal and is thus being investigated by the Working Group [5].
From ROOF’s perspective, the Things in an IoT application should be able to operate and cooperate within the context of a local environment in a secure and independent manner. In other words, each local IoT network deployment should be able to act autonomously and connect to other federated networks when needed or for added value. Blockchain fits perfectly in this context.
Each federated network should respond to their specific requirements. Some federated networks could be more or less restricted in terms of access and data retrieval from the outside; some could even decide to use consensus algorithms suitable for realtime applications or for IoT devices with constrained computational capabilities such as PoA or DPoS, which would leave the role of interfacing with the “public blockchain” and the other federated networks to one or a set of trusted nodes. Other federated networks in which IoT entities are untrusted and dynamically join and leave the network would be more likely to leverage on other consensus mechanisms, such as a Proof-of-Weight, based on the trustworthiness of devices or on how long that device has been part of the federated network.
Blockchain architecture in the ROOF context [5]
Yet, the problem of connecting all these federated networks with different blockchain requirements (i.e., blockchain interoperability) remains. One area that is showing promise in this sense is the use of sidechains [6]. Sidechains allow for a specific use case to be addressed, while still being able to interoperate with the outside blockchain world by creating ways in which one blockchain or sidechain can successfully communicate with another blockchain or sidechain in a “workflow” configuration. The main threat regarding this point and thus a key point to tackle in order to advance the state of the art, is that the amount of work it requires to achieve interoperability between an ever-growing number of federated chains as use cases and applications in the IoT domain grow.
Computationally complex consensus mechanisms are not suitable for IoT scenarios and the resources needed to reach consensus must be wisely allocated. A federated network made of different interoperable blockchains responding to the specific domain requirement and interacting by means of gateways or sidechains to the public blockchain network is more likely to become the standard for blockchain deployment in the IoT. Although DPoS currently looks like the most promising for transactions in a public federated blockchain, none of the current consensus algorithms are yet to be deployed in IoT as a standard adoption and the characteristics of each consensus algorithm need to be further evaluated and optimized in order to fit the IoT application domain.
Alessio Meloni (meloni@ieee.org) is with the Department of Electrical and Electronic Engineering at the University of Cagliari, Italy. His research interests include the Internet of Things, Smart Grids, Blockchains, and embedded systems for the IoT. He is a member of IEEE P1931.1 WG.