Basics of blockchain for the IoT
Richard Quinnell - July 15, 2019
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.
Blockchain technology, essentially, provides a 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 in Figure 1
below. 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.
Figure 1 The essential operation of a blockchain is simple, but with many options available at each
stage.
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.
Figure 2 Each block's header includes a cryptographic hash of the previous block's header, thus
creating a chain that cannot be altered without detection. (Source: NIST)
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 transactiononly 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 the Byzantine 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") and then generate 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 the PBFT
algorithm, a variant of which is used in the Hyperledger Fabric available 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.
Figure 3 Message sequence and traffic for PBFT consensus algorithm
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.
This 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 as Amazon, IBM, Microsoft, and others.
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 Quinnell is 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