Basics of blockchain for the IoT

Article By : Richard Quinnell

With the rise of Bitcoin, corporate interest in the underlying blockchain technology has risen dramatically. Confusion arises, however, because much of the discussion centers on cryptocurrency, which is only one approach to using blockchain. To determine an approach that makes sense for the IoT, developers must first strip blockchain to its basics and build from there.

区块链技术,本质上,提供了一个mechanism for a network of nodes to securely exchange information (called transactions) and mutually create a shared ledger documenting those transactions in a record that resists alteration. The basic process is simple, as shown inFigure 1below. A node securely informs all the others of a transaction, which they validate and add to their list of pending transactions. At some point a “publishing node” creates a data block containing none, some, or all the pending transactions, which it presents to the network. When the nodes reach a consensus that the proposed block is valid they add it to their copy of the shared ledger and remove the corresponding transactions from their pending list.

Each new block contains cryptographic links to the prior block added to the ledger, which in turn has links to its predecessor, continuing in an unbroken chain back to the first (genesis) block. The cryptographic links ensure that no block in the chain can be altered without detection, and the ledger’s many copies ensure there is no single point of failure that can destroy the ledger. Other mechanisms in blockchain’s technology ensure that all transactions get recorded, and that blocks linked to an incorrect copy of the ledger get rejected so that all functional copies of the ledger are identical.

While the overall operation of a blockchain implementation seems straightforward, there are many operational questions that must be resolved. How does a node join the network? What is the content of a transaction? How is it validated? Which nodes can publish a block? How often? What is its content? How do nodes reach a consensus on a block’s validity? What happens if there are several different blocks simultaneously awaiting validation? The blockchain developer’s answers to these questions will dictate their implementation’s operational effectiveness in its intended application. There are many options available for answering these questions; Bitcoin is simply one configuration of options developed for a cryptocurrency application and not even the only cryptocurrency blockchain.

One place to start in defining a blockchain implementation for a specific application is to answer the question of how a node joins the network. There are essentially two types of blockchain network: permissionless and permissioned. A permissionless blockchain, also called a public blockchain, places no restrictions on what nodes can join the network and all nodes can participate in validation and consensus efforts. This results in a highly decentralized and redundant configuration. Bitcoin is a permissionless blockchain network.

Permissioned networks, also called private blockchains, control what nodes can join, and which nodes are authorized to participate in validation and consensus. It is a less redundant and more centralized configuration than a public blockchain but can offer higher performance. Most enterprise and IoT applications of blockchain are likely to use permissioned network structures.

Regardless of the blockchain network’s configuration, their blocks have a similar structure. Before a node announces a transaction, it encrypts that transaction using its private key to digitally “sign” the message. It may distribute its public key with the transaction so that the other nodes can validate accurate receipt of the transaction record or nodes may already have a copy of the key so that they can validate authorized messages as well as reject unauthorized messages. The transaction itself can contain virtually any kind of data, but often also designates both the source and the destination of the data transfer.

One or more publisher nodes will combine a set of validated transactions into a block that is to be added to the chain and distribute the candidate block to the network. In addition to the transaction data, this block includes a header containing a cryptographic hash of the header from the prior block in the chain, a time stamp, and a cryptographic hash of the candidate block’s data. The header may also include a unique identifier called a nonce as well as other types of information the system may need.

Before a candidate block gets added to the chain, other nodes in the network must agree that it is valid, i.e., reach a consensus. Depending on the network configuration, nodes may not all participate in this consensus effort. In a blockchain designed for the IoT, for instance, there may be transaction-only nodes that do not maintain a copy of the chain or even other node’s transactions; they simply publish their data to the network. There may be lightweight nodes that keep copies of the headers only. Only full nodes, ones that validate and retain transactions, will retain a full copy of the blockchain. A full node may or may not be a publishing node, however, and may or may not participate in the consensus effort. The network’s configuration, especially that of a private blockchain network, determines which nodes take on what roles.

The method by which nodes validate a candidate block – the consensus mechanism – is one of the areas where blockchain designers have considerable freedom but it can also involve considerable complexity. A basic problem with a distributed ledger is that, in practice, some of the nodes in the network will be untrustworthy and will deliberately or accidentally generate bad information that could contaminate the ledger. This is a particular risk in permissionless networks like Bitcoin; there are no impediments to a bad actor entering the network and plenty of incentive to “cook the books.” But even in a permissioned network there is a risk that one or more nodes will be untrustworthy.

Fortunately, the attempt to reach a consensus on the validity of a block when some of the participants are trying to insert misinformation is a well-researched situation in information theory known as theByzantine General’s Problem. Many consensus mechanisms have arisen from this research, but four major types are being used in most blockchain implementations: Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), and the Practical Byzantine Fault Tolerance (PBFT) algorithms. Each has its strengths and weaknesses in terms of their ability to resist malign behavior, computational efficiency by publishers and full nodes, communications bandwidth requirements, and the like, but the first and fourth are particularly noteworthy.

PoW is the consensus mechanism used in Bitcoin. Essentially it requires a publishing node to solve a cryptographic puzzle before creating its candidate block. The puzzle is to determine a nonce to include in the block’s header so that the hash of that header satisfies a specific condition, such as having at least so many leading zeros. Solving this puzzle is a computationally intensive effort (the work) involving many trials using randomly generated nonce values until a satisfactory result is obtained. Once a node that is working on the puzzle has found its “golden nonce” it can publish its candidate block. Other nodes can then readily validate the result by conducting their own hash of the block’s data to verify that element of the header, and then hash the reconstructed block header using the candidate nonce to verify that the conditions are satisfied. First candidate block to be verified by a majority of full nodes wins, and nodes will add that block to the blockchain.

PoW functions as a secure consensus mechanism because the chances are exceedingly small that a bad actor can first alter the block data in a way that it generates the same data hash as the valid block data (a hash “collision”) andthengenerate a golden nonce for its corrupted block, before any other nodes can generate a valid block. It is so computationally intensive to generate a golden nonce, though, that Bitcoin provides an incentive to potential publishing nodes to ensure that they make the attempt. Such a publishing node (called a Bitcoin “miner”) will receive a payment (in newly minted Bitcoin) when it creates a block that wins the network’s agreement to add to the chain.

The PoW consensus mechanism wastes a lot of processing power in its effort to keep bad actors from contaminating the blockchain, however. While this may be an acceptable expense when there are millions of dollars at stake to protect in a public blockchain, it is seldom cost-efficient for the kinds of private blockchains that the IoT will likely utilize. A much more computationally efficient approach suitable for the more controlled environment of a private blockchain is thePBFT algorithm, a variant of which is used in theHyperledger Fabricavailable through the Linux Foundation as open source code.

In the PBFT algorithm the network’s publishing nodes form an ordered sequence, with one of the nodes temporarily serving as the leading node, a period known as a “view.” During its view, the leading node publishes its candidate block along with a “pre-prepare” message that contains its identification and blockchain status. The remaining nodes must then validate that block by comparing the block’s header and data hashes and blockchain status with their internally-generated copies. Nodes then broadcast their acceptance or rejection vote on the block in a “prepare” message to all other nodes.

When more than two thirds of the nodes report acceptance, each node then publishes a “commit” message acknowledging the successful vote and the node’s intent to add the block to its blockchain. When more than two thirds of the other nodes agree to commit, all nodes can go ahead and append the candidate block to their blockchain. Once a block has been successfully appended, the view changes and role of leading node moves to the next node in the sequence. Alternatively, if no consensus is achieved within a set time frame, nodes discard the candidate block, the view changes, and the next node in the sequence becomes the leading node to try again for consensus on a block.

With the PBFT algorithm, the network can quickly identify and isolate nodes that misbehave, even if the leading node is the bad actor. If a node too frequently rejects valid blocks or fails to achieve consensus whenever it is the leading node, other nodes can learn to ignore it as faulty or malicious. In a permissioned network, the system can even include a supervisory algorithm that can permanently remove a misbehaving node from the network.

这algorithm involves much less computation and executes much faster than the PoW approach because there are no puzzles to solve, only hashes to verify. Further, only one node at a time is authorized to publish candidate blocks, so there is no chance of an accidental “fork” in the chain that occur when different nodes adopt different (but valid) candidate blocks. Such forks can occur in Bitcoin due to the mining competition, should two successful candidates appear simultaneously, so Bitcoin must use additional algorithms to prune forks as they occur.

The major disadvantage of PBFT is the amount of message traffic associated with consensus. Because each full node must send its pre-commit and commit messages to all the other nodes, message count scales exponentially. For an IoT implementation, however, this might not be a significant limitation.

Consider a system in which several organizations (a consortium) mutually establish a permissioned blockchain network for tracking the handling of perishable goods requiring refrigerated storage and transport moving from source through warehouses to the final customer. Each handler (source, transportation provider, warehouse, distributor, retailer, etc.) maintains a publishing node for the blockchain. The end customer might also have a non-publishing node linked to the network for tracking the blockchain of their specific purchase.

IoT sensors monitor the goods, regularly sending their location and temperature information to each stakeholder’s node for creation and maintenance of blockchains tracking the goods. The publishing nodes participate in a PBFT consensus mechanism in forming the blockchain that records the movement and temperature history of goods all the way from source to customer. The result is a blockchain that, should problems arise or proof be required, provides all parties with a consistent and immutable record of what happened.

Such a network will not need a massive number of publishing nodes – only those stakeholders with contractual commitments to one another will require a consensus vote in maintaining the mutual ledger of the transactions. There may be other stakeholders that wish to maintain a copy, and so be connected to the network, but the traffic to them only scales linearly with the number of added nodes. A carefully-considered and well structured private blockchain using PBFT consensus thus can avoid bandwidth concerns.

The trick, of course, is to choose a network structure, consensus mechanism, communications scheme, block and header definition, and other such details to fit the blockchain’s operation to the application’s needs. There are many possible implementations, some of which are commercially available from blockchain-as-a-service (BaaS) providers such asAmazon,IBM,Microsoft, andothers. There is also open-source software, such as the Hyperledger Project, available to those seeking to develop a custom blockchain implementation.

At its most abstract, blockchain technology allows the creation and maintenance of a distributed, tamper-resistant, digital transaction record. This record is open to inspection by interested parties, but not alterable by them. Even though the transactions are viewable, the parties involved in the transaction may, depending on the blockchain’s configuration, be anonymous or identifiable. Properly configured and applied, a blockchain can help increase the trust in and efficiency of IoT interactions.

Rich Quinnellis an engineer, writer, and Global Managing Editor for the AspenCore Network.

Related articles:

• Building the IoT: connectivity and security
• The History of Blockchain and Its Role in the Enterprise Today
• IoT security: hardware vs software
• Blockchain Hardware Accelerator Addresses Security, Performance, and Decentralization
• Infineon debuts blockchain security starter kit
• The Intersection of Blockchain and Engineering