Demystifying Blockchain: Sifting Through Benefits, Examples and Choices

You have likely heard that blockchain will disrupt everything from banking to retail to identity management and more. You may have seen commercials for IBM touting the supply chain tracking benefits of blockchain.[i] It appears nearly every industry is investing in, adopting, or implementing blockchain. Someone has probably told you that blockchain can completely transform your business! Is this hype or could blockchain really have such a dramatic impact? In this analysis, we will explore both real-world and contrived examples for implementing this quickly developing technology. We will also explain the two key benefits blockchain provides, as well as when to look elsewhere for the appropriate solution. We will explain the primary distinguishing features of major blockchains to help you choose which, if any, is best for you.

Who Uses Blockchain?

Cryptocurrencies may be the best-known example of blockchain use, but they are not the only ones. American Express launched a blockchain linked to its membership rewards program in May 2018.[ii] This program has a lot of similarities to traditional currency exchanges and points reward systems. However, integrating the points rewards system into a blockchain can provide additional data beyond the transactions. American Express uses it to provide insight into partner offerings, while partners receive similar insight into customer behavior. The data associated with that transaction is valuable to both the rewards program owner and the partners that facilitate the rewards. Product manufacturers can use a blockchain system in this manner to accept rewards purchases through their own channels, while the program owner can get more visibility on stock keeping data. Data sharing to all parties can be simplified, enriching the entire ecosystem.[iii]

Not only financial institutions invest in blockchain. The energy sector is also developing plans. LO3 Energy is working on changing the way energy is distributed, particularly in local areas.[iv] Using this technology, they can facilitate energy trading between consumers, reducing inefficiencies and reliance on nonlocal sources. Siemens announced additional investment into LO3 Energy in December 2017. Together they will work to establish microgrid communities and local energy marketplaces.[v] Blockchain does not just store records of energy transactions; it can also facilitate and enforce business rules, creating automated execution of transactions between users.

Even your future commute may be positively impacted by blockchain technology. The auto industry is investing in blockchain in a big way. On May 2, 2018, the Mobile Open Blockchain Initiative announced a consortium of car manufacturing–related partners to standardize blockchain use in the industry.[vi] That announcement listed several upcoming projects:

Vehicle identity, history, and data tracking
Supply chain tracking, transparency, and efficiency
Autonomous machine and vehicle payments
Secure mobility ecosystem commerce
Data markets for autonomous and human driving
Car sharing and ride hailing
Usage-based mobility pricing and payments for vehicles, insurance, energy, congestion, pollution, and infrastructure

Many of these projects are related to data management. This is an obvious application because blockchain is a data-centric structure. Ford was recently awarded a patent related to the partnership.[vii] In the patent the company proposed a system for vehicle-to-vehicle cooperation to marshal traffic.

Figure 1: Image of traffic congestion from Ford’s patent application. Source: Ford Global Technologies.

To decrease congestion, each vehicle can communicate with each other to coordinate movement, improving traffic flow. The system also allows vehicles to collaborate based on priority. If the driver is in a hurry, then vehicles can coordinate traffic flow to the speed of that individual. One beneficial application could be for emergency responders.

Blockchain is still in its infancy but has already taken hold in certain industries. You do not need to be a programmer to understand its value. There are many use cases, some of which are not obvious until you understand exactly what blockchain is and which problems it solves. Applying blockchain to the right problem could have a significant impact on your success. Applying blockchain to the wrong problem may reduce your efficiency and waste time and resources.

What is Blockchain?

Rather than explain blockchain with technical jargon such as nonces, hash functions, merkle trees, and other complex concepts, let’s instead begin with a simple business analogy.

Four companies agree to a business opportunity to design, print, deliver, and sell 2020 New Year’s holiday cards. Each company is responsible for its own portion of the product. If the product is designed, printed, delivered, and sold by December 31, they stand to make a significant profit. However, if any one of the companies backs out or fails to deliver on its task, then the entire project fails—resulting in a significant loss.

Suppose, after agreeing to ship the cards, the delivery company receives a new, more lucrative offer. The profit from the opportunity offsets any loss from the holiday cards. Its priority changes accordingly. The three remaining companies now must deal with the consequences of one undependable member failing to fulfill its agreement. How can they come to an agreement when they depend on others yet cannot trust them to follow through?

This is the problem that blockchain solves. Rather than depending on a central authority such as a government for validation and enforcement, blockchain solves this problem in a decentralized way. It removes the need to trust the contributors or any authority. It is called a trustless network, meaning that no trust is needed because everything can be verified by any member. How does the concept of a trustless system work?

The agreement to contribute is called consensus. If even one member does not agree, whether for malicious purposes or through miscommunication, consensus is broken. It is the primary function of blockchain to guarantee consensus as well as immutability of the data. Consensus is gained through the consensus algorithm requiring a proof or voting threshold. We will discuss specific census algorithms and how they work later.

Blockchain can be thought of as a ledger of data, so ensuring the data cannot be tampered with (immutability) enables the verification of the ledger state. No one can go back and alter the books. Traditionally, the ledger is seen as a record of financial transactions. However, the concept applies to any type of data. One can just as easily store documents, images, log files, or other items in a blockchain. Even decentralized programs, also known as smart contracts, can be stored. Smart contracts enable the execution of code on the blockchain, but the code itself and its output are just a special type of data.

Figure 2: A simplified blockchain storing recipe instructions. The Previous Hash and Stuff fields generate the Hash field. This hash becomes part of the next record.

A blockchain has only two basic requirements:

A verifiable chain of blocks
A consensus model

Blocks simply store data. In our example, a block stores the agreements of the four companies. For cryptocurrencies this data is currency transactions. For a fresh-produce delivery company, the data might be sensor logs to verify proper handling and environmental controls. In certain unobvious implementations, even seemingly intangible objects such as the rules, assets, and user choices in a collectable card game can be stored as blocks.[viii]

Just because a block contains data does not make it trustworthy. Each block, more specifically its data, needs to be independently verified by all clients to ensure consensus. This concept requires data immutability. If a client cannot verify the block, then it must trust some authority, ultimately breaking the tenet of decentralization. Again, to avoid technical jargon, all we need to understand is that blocks can be uniquely identified by a hash. Think of a hash as a unique identification number that is not assigned, but rather calculated. Every client can calculate the same hash of the same block using the same algorithm. If any data changes, even a single character, the hash changes completely. By calculating and storing the hash, all parties can verify that the data has not changed. (In principle, there is a small chance, depending on the hashing function used, that more than one block could be identified with the same hash. However, the likelihood is so incredibly small that a brute-force attempt on current SHA-256 hashes would take longer than the age of the universe.)

We can verify an entire “chain” of blocks as well. Because the hash of any block is just data, it can be added to the data of the next block. By adding the hash of one block to the next, we can interlink the data of all blocks. The data of any block is dependent on all previous data in the chain. If anyone tampers with data in any previous block, the hash of that block changes as does its parent block’s hash, continuing all the way up the chain. Without needing to independently verify the data of every block, we can calculate each hash and verify the integrity of all data.

However, knowing the data has not changed is not enough to ensure the original data is still intact. For example, a disgruntled employee may wish to create their own blockchain and remove items from the record. In a centralized system, we could restrict write access to trusted parties, such as a database administrator. In a decentralized system, in which multiple companies or individuals are involved, limitations make that level of control impractical. There are a few ways to come to a consensus, but there are two primary categories for decentralized blockchains:

Nakamoto-style consensus (lottery)
Byzantine fault tolerance (voting)

The first category is Nakamoto-style consensus, named after the author of the first blockchain paper.[ix] This method is akin to using a lottery system with some verifiable “cost” associated. Because cryptocurrency is the most common implementation of blockchain, the cost is historically based on the processing power required to mine cryptocurrency, but it could also be storage space or time, among other resources.

The second method of consensus is Byzantine fault tolerance, a model based on current networking fault-tolerance research. As much as a lottery is analogous to the Nakamoto model, so is voting to the Byzantine fault-tolerance model. Each model has its pros and cons, which are important to understand when choosing a consensus model. We will describe major consensus implementations later in this analysis.

Both Nakamoto style and Byzantine fault tolerance consensuses have several implementations to choose from. Regardless of which implementation we choose, once a consensus is made these blocks can be chained together creating a single ledger of immutable data. Multiple chains may exist, but only one chain is agreed upon. Additional chains can be made by happenstance or by malicious actors, but only one chain will be considered correct by the network.

The following image shows a failed attack against a proof-of-work consensus model from a simulator. The green nodes all agree to use the longest chain, based on the consensus model. Bad actors, illustrated as red nodes, are unable to break the consensus of other members due to the high processing cost in the proof-of-work model. Notice the green, or “honest,” nodes all agree on the latest block simply by choosing the longest chain with the most work.

Figure 3: A proof-of-work simulation showing consensus despite malicious actors.

Comparing use Cases: the Good and the Bad

Data within blocks are similar to records in a database. Many scenarios can be accomplished by using traditional databases and in some cases are better suited to doing so. When is using a blockchain appropriate and when is it not? We can boil this question down to two principles:

Decentralization of owners
Lack of trust

Any system that requires centralization and tight control is not a good candidate for blockchain. In many cases we could make it work, but we would be better off looking elsewhere. A centralized system relies on some authority deciding what is valid. It can be streamlined to be incredibly efficient. By using a blockchain we must either give up that authority, losing efficiency, or maintain the authority, breaking key benefits of blockchain. There are also some gray areas where a balance must be met. Let’s take a look at good and bad use cases and compare them.

Decentralization: the good

Alice owns a hospital that serves thousands of patients a week. The medical staff need to have a clear picture of every patient’s medical history to make effective and safe decisions. When patients come in for the first time they are asked routine medical questions that are entered into their records. When the patients return, the records are retrieved and reviewed by the staff. However, patients sometimes have difficulty remembering key details or leave out important information. The hospital can request information from their previous providers. That may prove impractical in a time-sensitive scenario or when the patients are unable to assist. The patients might have one or more providers they have forgotten, leaving the staff ignorant of some medical history.

This is an example of the decentralization principle. Alice’s hospital has no control over any medical data not in its possession. That data is dependent on the accuracy of the patients and other medical practitioners. Alice also has no control over the other practitioners. She is dependent on their timely cooperation. Each entity needs to ensure the data is up to date and accurate while not being held accountable by the other. Who gets the final say on the entirety of the medical history? How does Alice know if she has it all? There are certainly centralized solutions to the problem, but the decentralized nature of the patients’ data flow lends itself well to a blockchain solution. Some solutions for this problem are already underway.[x]

Decentralization: the bad

Bob is the owner of a chain of restaurants in the Dallas area. To encourage customers to return, he has introduced a rewards system; customers can earn points by spending money at any of his restaurants. They can use the points to pay or reduce their next bill. As a bonus, he would like the points to be transferable to other patrons. Recognizing the similarities between his point system and cryptocurrencies, Bob implements a blockchain to track the distribution and transfer of the points. Members can join his blockchain network when they earn points. They can spend points by submitting the changes to the network. Bob does not even require names for the points. As long as the owners keep their account keys, they can freely transfer the points to anyone.

This scenario is deceptively similar to cryptocurrency implementations and the American Express rewards system. However, the similarities have confused Bob. His customers and individual restaurants are considered to be decentralized. However, Bob is the owner of all the restaurants and gets to make all business decisions for them. This is not a decentralization of owners but of management. In the American Express rewards program, each partner has its own agency. American Express does not control them or their actions. This is an example of a decentralization of owners. Furthermore, Bob’s customers are also not independent of Bob. If Bob decides to serve only pizza, then customers will have limits on what they can order. Bob is an authority in the entire system even if the pieces have varying degrees of autonomy. He can certainly allow managers to supply their own menu, but they are accountable to him. The system Bob envisions fails the decentralization principle.

Could Bob implement his point system anyways? Certainly. However, he fails to gain many of the advantages of using blockchain while losing the efficiency and agility of a traditional database implementation. Instead of blockchain, he could load points onto a rewards card that anyone could carry. The database can track the current balance of the card. Each restaurant can check the database before approving any purchases with points. This is a simple and effective system that has already been proven to be fairly robust. Bob’s case may not be a good candidate, but simple changes could change that. What if Bob did not own all the restaurants? What if the points could be used by partners such as hotel chains? These new features remove Bob as a central authority—making a much better case for a blockchain solution.

Trust: the good

Carol owns a grocery store and wants to buy only the freshest produce from her suppliers. However, sometimes she does not see the quality of the product until it is stocked, well after accepting delivery. Her suppliers maintain that the quality of the produce is good and any issues should have been raised at the time of delivery. They disagree who is at fault for the low-quality produce. It could be improper storage by the farmers, oversight of the goods by the shippers, or failure to check the goods by Carol’s grocery staff. To solve this issue, Carol and her suppliers created a blockchain network to track the handling of the produce. Storage sensors measure the moisture and heat of the storage unit as well as timestamps from the farm to final delivery. When the produce switches hands, a new record on the blockchain indicates the change and new storage sensor data collection begins.

Carol does not trust that produce is delivered in good condition. The suppliers do not trust that Carol stores the produce correctly. If each entity could validate proper storage, trust would not be required. Carol could decide, with limited inspections, whether to accept the produce based on its storage record. The farmers could prevent unreasonable returns based on faulty temperature control during shipping. This scenario fits the trust principle of among the participants. Additional measurements such as weight and images of the produce at various stages could also be added for further verification. If we suppose that the suppliers service many grocery stores and Carol buys from multiple suppliers, then we have an even stronger case for the decentralization principle as well.

Trust: the bad

Ted wants to create a sports card trading network. Users need to prove they legitimately own the cards. By registering the card in a blockchain, all users can track who owns which card and verify ownership if someone claims to own a rare or valuable card. Ted creates a blockchain to maintain the ownership data. When someone trades a card, the records are updated to reflect the change.

At first glance, this scenario is similar to Carol’s produce problem. A physical item must be delivered, and details are stored in the blockchain. However, Carol has the option to verify log data before she accepts the delivery. If there is a disagreement, the log data can justify who is at fault and they assume the cost. Ted, however, wants to track the physical object. Any disagreement will be about the delivery and location, not the quality of delivery and storage. If Ted delivers a card, the network trusts that he will update the records accordingly. If the network is updated, both the buyer and seller trust that the card was delivered. Data within this trading system cannot be independently verified. If there is a disagreement, there is no recourse within the network. The physical location of the card is important as well as the timing of both the physical and blockchain transactions. In Carol’s system, only the log data and the sum of the log data that needs to be verified are important. She answers the question, “Did you deliver the produce to spec?” Only then does a transaction happen. Carol’s recourse is not to accept the delivery. In Ted’s scenario, the card may be registered in the wrong hands—with no ability to correct the network.

Could a similar system work for Ted? Absolutely. One solution is to step into some gray area and add a little trust to the system. However, any required trust creates dependencies, so our goal is to reduce reliance on a trust model as much as possible. If Ted worked with digital trading cards instead of physical cards, he could reduce the trust factor to zero. The entire system could be contained in the network, eliminating any need for trust. If he must maintain physical cards, then he could learn from examples in the diamond industry. Beginning early in 2018, the diamond industry implemented blockchain to track 100 diamonds from mine to retail with a limited amount of trust .[xi] Each entity was required to upload data at each milestone, creating a method of verification. Trust in this case was reduced, but not eliminated, and allowed multiple stakeholders visibility into the diamonds in their possession. Ted could take a similar route to require a proof-of-delivery stage for a valid trade transaction. The harder the proof of delivery is to fake, the less trust the system needs. Any data coming from outside the network requires some form of trust. Ted can balance his needs for physical tracking against added trust in outside delivery verifications.

Holiday cards

How does the holiday card example fare with the decentralization and trust principles? It should be clear that the four companies have their own agency. They do not answer to the same management or boards of directors. The lack of centralization indicates blockchain could provide value that a traditional database could not. The trust principle is a bit more difficult to pin down, however. Certainly, they lack trust that each will do the job they were contracted to do. However, there are additional trust issues they may be concerned with. Can each party actually perform their obligations? Who is tracking the profits? If one party fails its part of the contract, how do the others recover? Each of these issues could be addressed using a blockchain implementation. To cover them all would be a massive undertaking, particularly in these early stages of the technology. Asset tracking could be resolved much like the diamond-tracking system we discussed. Financials could be tracked similarly to popular cryptocurrency implementations. Contract breach penalties could be built into the business logic using smart contracts—assuming the legal hurdles can be surmounted. What remains is the ability to gauge whether the obligations can be met in the first place. Each company could load relevant resources into a blockchain to be checked by another. This, unfortunately, requires a lot of trust that the data is entered correctly. Further work could be done to reduce this trust gap but those systems need to be designed and proven to be viable in major transactions.

Blockchain Options

You have determined you have a good case for blockchain. Now what? Do you build your own? Do you piggyback off current infrastructure such as Bitcoin scripts or Ethereum contracts? Create your own tokens? There are pros and cons to each. Fortunately, demand has created markets that can simplify your implementation. Which type of blockchain do you need?

Public, private, permissioned

There are three primary types of blockchain: public, private, and permissioned. A public blockchain is the best known. Bitcoin, Ethereum, and most other cryptocurrencies fall into this category. They are generally open to the public without restrictions. Private blockchains are not open to the public. The contributors to the network are well defined, with no outside entities allowed. Organizations may build a private blockchain in house or with a select group to solve a business need. Permissioned blockchains are provided to the public with a set of rules. Nodes are clearly identified, reducing anonymity. Access is provided only by invitation or request. Permissioned blockchains may have additional rules on the allowed behaviors of individuals or groups of nodes.

Public

Public blockchains are good for set-and-forget solutions, particularly if you are not much concerned with who participates in the network. You could build your own or quite easily fork a current blockchain. Technologies such as Ethereum smart contracts have a lot of support and even developing standards for enterprise-ready development. A major drawback to public blockchain is the lack of control of the network behavior and uploaded data. There are ways to partially resolve these concerns, but they can become complicated and limit the options of which technologies you can use. The most common public blockchain technologies are Bitcoin, with limited script support extension, and Ethereum, with more flexible smart contract support.

Pros

Improved security due to network participation, particularly on Nakamoto-style consensus models
The network is likely to remain active regardless of personal contribution
Lots of current implementations that can be used or learned from

Cons

The network is likely to remain active regardless of personal contribution
Lack of control over the network’s future
Internal behaviors and data are visible and difficult to hide

Private

If you are developing a private blockchain, you may be better served using a database solution. Why? Private blockchains lose most of the security benefits of blockchain while assuming the complexities and speed reduction. They do gain more privacy with internal activity, but those benefits can also be gained in a permissioned blockchain and certainly with control of your own database. One notable exception to this advice is internal testing and prototyping. If you are prototyping, testing, experimenting, or otherwise learning about blockchain technologies, private blockchains can be your personal sandbox. For example, you could compile your own Ethereum network with a hardcoded difficulty rating to privately test new contracts you are developing. You may even wish to create a private blockchain for staging and plan to open it to others in the future. From this perspective, some may choose to accept a security reduction in the short term to ensure long-term reliability.

From a security perspective, it is false to assume that only trusted parties can contribute to a private blockchain. Through use of phishing, botnets, and cloud services, malicious attackers could gain entry to your private blockchain and perform attacks such as Sybil and 51% attacks.[xii] Due to the inherent lack of scale in private networks, these attacks may not only be possible, but also relatively cheap. This type of targeted attack on a private blockchain has not been publicly observed; however, similar attacks have been performed against smaller public blockchains.[xiii] If you choose the private blockchain route there are simple ways to achieve this without reinventing the wheel. One way is to clone any number of blockchain solutions such as Ethereum and configure the clients to connect to a custom network. You may wish to implement additional protection to authenticate valid users while relying on the readily available core technology.

Pros

Improved control over the network’s future
Internal activity and data can be designated to trusted participants
Required features can be tailored to business needs

Cons

Severely reduced security due to lack of adoption
Slower than any similar database solution
Code and network maintenance

Permissioned

Permissioned blockchains strike a balance between public and private blockchains. The best known permissioned blockchain is Hyperledger Fabric, a blockchain framework implementation.[xiv] Hyperledger Fabric enables organizations to maintain some control over their segment of the blockchain while gaining many benefits of broader adaptation. Each segment can control its own consensus model to govern their data, in this case through channels.[xv] This framework is seen as one of the most mature implementations of blockchain with enterprise-ready business solutions.[xvi] Other solutions include Hyperledger Sawtooth, Quorum, and Stellar, which are used by various companies.[xvii] [xviii] Forbes lists 50 top public companies investing in blockchain.[xix]

Pros

Improved control over the network’s future
Participants can be vetted based on the network’s needs
Provides most of the benefits of public blockchains with trade-offs in increased trust

Cons

Requires some trust in a central authority or consortium
Potentially reduced security based on adaptation
Requires commitment to keep your network segment active

Proof of work

Any agreement requires a consensus on the facts. Blockchain maintains what amounts to record entries that all participants agree on. The method on which participants agree to these records is called the consensus algorithm. Most consensus algorithms expend a finite resource to prove that work was required to write to the ledger. For every additional block in the blockchain, increasing resources are spent. This measurement is additive because each block must be computed separately. By knowing the difficulty of the work being done on each block, participants can calculate how much work was done on an entire chain. The longest chain is always considered the active chain. Thus, in a short time, participants will gain a consensus in which the records that make up the longest chain are agreed upon.

Proof-of-work is the most common consensus model. It was the first proof proposed in Satoshi Nakamoto’s paper “Bitcoin: A Peer-to-Peer Electronic Cash System.”[xx] The primary resource used in a proof-of-work algorithm is processing power, initially by the CPU. The most common implementation is based on the SHA-256 hashing algorithm. Each block is hashed using SHA-256, with the goal that the resulting hash is smaller than a target number. This number is chosen based on the speed with which the network mines blocks. If a block has a hash that is lower than or equal to the target number, then it is valid and can be appended to a chain. Lower targets create higher difficulty ratings on each block. These ratings are used to determine which chain used the most resources and is, therefore, the active one. In the following proof-of-work below, the difficulty rating represents a number preceded with five zeros. Any number with fewer than five zeros is bigger than the target and is invalid. The “header hash” of the block is used for this comparison. In lay terms, proof-of-work creates a mathematical problem and turns it into a lottery-like system. The winner is whoever solves the problem first. It offers the bonuses of controlling the speed of writing to the blockchain and enabling users to choose the same blockchain.

Figure 4: Hashing results from a proof-of-work simulator. A valid header hash starts with five zeros.

One of the primary criticisms of proof-of-work is its wasteful consumption of energy. Bitcoin’s implementation consumes enough energy to power 6.7 million households.[xxi] This consumption directly relates to cost when implementing your own blockchain solution. Researchers have sought alternatives to avoid excessive resource costs. This has led to several other consensus models.

Figure 5: Bitcoin power consumption compared to VISA transactions power consumption. Source: Digiconomist.

Proof of elapsed time (PoET)

Proof of elapsed time was first implemented in Hyperledger Sawtooth, originally developed by Intel. It is an example of a consensus model that does not require excess resource use or energy to form a consensus. Much like proof-of-work, it falls into the category of a Nakamoto consensus. The voting system is based on a random wait time; the node with the shortest wait time creates the next block of the chain.

In most cases it is impossible to guarantee a node has both chosen a random wait time and waited the indicated amount. However, using a trusted execution environment could resolve this issue. To properly implement a secure trusted environment, specialized hardware is required. Intel, using Software Guard Extensions (SGX), can execute machine instructions in a secure trusted environment called an enclave. The SGX instruction set in modern Intel processors enables trusted execution.[xxii] Key functionality such as the random number generator and wait time can be executed inside the secure enclave. They prevent attackers, even with local access, from altering the machine instructions, preserving the integrity of the results. By using certificates and signatures, others can further validate that the output did indeed run within the secure enclave.

The main benefit of using PoET instead of other Nakamoto consensus algorithms is that its resource use is low, reducing costs. By using a random wait time instead of processing cycles, the actual power consumption is minimized. However, this comes with two drawbacks:

Hardware requirements
Required third-party trust

Although the PoET documentation lists only SGX, other platforms exist, including AMD, ARM, and RISC-V.[xxiii] As of this writing, however, no major PoET implementation for these platforms is available, leaving SGX as the only current option. Due to this limitation, only modern Intel processors can participate in a PoET network. Mixed trusted execution environments are not guaranteed for the future. This is entirely dependent on whether a trust mechanism is ever developed between platforms.

PoET also requires third-party trust. In the case of SGX, nodes must trust Intel’s implementation of their secure trusted environment as well as Intel’s services. For code to be validated, the secure container must be confirmed as well. The process requires trust in the Intel Attestation Service (IAS). In the case of self-attestation, the IAS API must show the container has previously been enabled. If self-attestation was not previously enabled, then the API will be called to verify the retrieval of the attestation verification report. Both routes require a trusted response from IAS.

Figure 6: Remote attestation flow.[xxiv]

Practical Byzantine fault tolerance[xxv].

Practical Byzantine fault tolerance takes a different approach, with lessons learned from work in distributed systems. Byzantine fault tolerance was initially designed to measure the dependability of distributed systems. As we discussed earlier, it is more like a voting system than a lottery. Rather than every node spending a resource to prove work, consensus is gained by a leader choosing transaction orders. Validation peers then communicate to one another until there is a consensus on the chosen transactions. Leaders are chosen by validation peer votes, enabling any faulty or malicious leaders to be removed by the network. This model has a few benefits over a resource-based model such as proof-of-work. The primary benefit is the limitation of resource use, a major criticism of many other consensus models. However, this benefit comes at some cost:

Reduced resistance against attacks
Lack of anonymity
Increased traffic

A well-known attack against many blockchain implementations is the 51%, or majority, attack. By controlling more than 50% of the network, an attacker can change the historical records in the ledger as well as assert some control over new blocks being mined. Byzantine fault tolerance, by comparison, requires only one-third of the replication nodes to be compromised.[xxvi] Byzantine fault tolerance sacrifices some security for speed and efficiency, reducing the threshold an attacker needs to meet to compromise the network. Essentially, if an attacker can control one-third of the transaction replication, they can break the validity of the transactions or prevent a valid consensus altogether.

Figure 7: Practical Byzantine fault tolerance. Source: Altoros.

A second compromise with using Byzantine fault tolerance is anonymity. The nature of this model requires node identity to be known so leaders can be chosen and removed if necessary. This precludes public blockchain implementations and suggests permissioned blockchain is a better fit.

The replication nodes also generate extensive network traffic. When the leader decides on the valid transaction, each replication node waits on a designated number of consistent responses from other nodes. This creates a significant amount of network traffic that may be manageable only for small blockchain networks. The network requirements for large implementations become unmanageable in a Byzantine fault tolerance system. Each node must wait until two-thirds of the nodes agree, with every node broadcasting to each other. Permissioned blockchains reduce the communications to subsets of nodes, easing the network requirements to participate.

Proof of stake

Proof-of-Stake consensus takes a route similar to Byzantine fault tolerance’s and benefits from many of the latter’s properties. At its core, proof of stake is a voting system in which ownership of a token provides more weight to the block-creation mechanism. This algorithm claims significant advantages over proof-of-work including security, reduced risk of centralization, and energy efficiency.[xxvii] Proof of stake avoids wasting resources by limiting resource use such as processing power and offers the advantage of producing faster transactions than similar proof-of-work systems. Proof of stake’s integrity is based on the assumption that most users will behave honestly. This may not always be a valid assumption, as observed in a “P + epsilon attack,” in which a malicious user provides bonus rewards to buy votes. The attacker structures the reward so that it is always more profitable to vote with the attacker than otherwise.[xxviii] There have been some implementations and proposals to mitigate these types of attacks, such as the “slasher” method, which penalizes certain behaviors.[xxix] Major implementations of proof of stake include Peercoin and EOS, with future migration plans for Ethereum.[xxx]

Federated Byzantine agreement (Stellar consensus protocol)

When a node hears a statement a sufficient number of times, it assumes the statement is true and any contradiction comes from a faulty node. The agreeing nodes are called a quorum; a portion of the quorum is a quorum slice. In a traditional Byzantine fault tolerance algorithm such as practical Byzantine fault tolerance, the quorum and the quorum slice are interchangeable because the nodes that broadcast the original statements are predefined as leaders that participating nodes agree on. By allowing for the slice, individual nodes can come to an agreement about a particular statement without regard for the entire network. Each individual node can make its agreements based on arbitrary criteria if the statement comes from a sufficient number of other nodes. Agreements can be shared across nodes if there is a quorum intersection between the two nodes (an overlapping node between quorum slices). In other words, if my friend trusts you, then I’ll trust you too.

Figure 8: Chart of anonymity and trust between proof-of-work, proof-of-stake, and federated and non-federated Byzantine fault tolerance consensuses.[xxxi]

Conclusion

New technologies can be confusing, and the excitement can lead to many overexaggerated claims. Blockchain, though it holds a lot of promise, is not “one size fits all” for every problem. Many problems can be adequately solved at low cost using well-understood database implementations. The value of blockchain truly shines when the implementation space has two key elements:

Decentralization of owners
Lack of trust

It is not enough to have decentralized locations. A single business can have decentralized assets such as branches or organizational structures. There needs to be a clear separation of control between the entities. Databases have long proven capable of working across geographies. However, blockchain can provide a mechanism of agreement when central databases are difficult, if not impossible, to implement.

Any system with assumed trust is also not a good candidate for blockchain. Even if a central database is not an option, an interface to retrieve data and synchronize databases can still be magnitudes of times faster than blockchain. You simply need to trust the data has not been tampered with now or in the future. If the other parties have incentives, such as economic advantages, then trust is diminished and blockchain may help surmount the trust hurdle.

Determining which blockchain to use is not easy. If you simply want to release digital incentives such as rewards points, then tokens built on top of cryptocurrencies could work. If you require complicated rules, then smart contract–supported networks such as EOS and Ethereum may be what you need. Flexibility, privacy and enterprise-ready support can be found on various Hyperledger frameworks. Even privately built blockchains are a reasonable option in some scenarios. Your choice of Nakamoto-style consensus or Byzantine fault tolerance, coupled with concerns for privacy, speed, and scale will help guide your decision. It is important to remain informed of what blockchain can and cannot do. Databases should be your first choice until you can show both decentralization and lack of trust issues. Choosing blockchain for its strengths can transform your business in a positive way. Implementing blockchain where it does not fit could have devastating effects on a business’ ability to scale quickly and operate effectively.

———————————————————————————-

[i] https://www.ispot.tv/ad/doiE/ibm-blockchain-smart-supply-chain

[ii] https://www.coindesk.com/american-express-upgrades-rewards-program-hyperledger-blockchain/

[iii] https://www.americanbanker.com/news/has-amex-found-a-data-gold-mine-with-its-rewards-blockchain

[iv] https://lo3energy.com/

[v] https://www.siemens.com/press/en/pressrelease/?press=/en/pressrelease/2017/energymanagement/pr2017120121emen.htm

[vi] https://docs.wixstatic.com/ugd/bd1fb8_4e16d895b37e4b2a9d4dafdbb82cef2a.pdf

[vii] http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=1&p=1&f=G&l=50&d=PTXT&S1=9,928,746.PN.&OS=pn/9,928,746&RS=PN/9,928,746

[viii] https://novablitz.com

[ix] https://bitcoin.org/bitcoin.pdf

[x] https://medicalchain.com/en/

[xi] https://www.debeersgroup.com/media/company-news/2018/de-beers-group-successfully-tracks-first-diamonds-from-mine-to-r