By Jeff Stollman

Principal scientist, Rocky Mountain Technical Marketing, Inc.

As I pointed out in a previous blog on decentralization, there is a great zeal in the blockchain community around the notion of decentralizing everything.  It is viewed by many in the community as a guiding principal that is vital for any blockchain solution.   But the term is used so differently in so many contexts, that it is hard to understand the vision of these enthusiasts.  And, I suspect, that much of this enthusiasm is misplaced.

I will attempt to demystify the term by revealing my ?? tenets of decentralization.

Tenet #1:  Decentralization is not an end in itself.

Decentralization is not an end; it is a means to an end.  Even the most outspoken advocates of decentralization will likely agree that they decentralization is important because it serves at least one of the following purposes:

Transforms the blockchain a trusted intermediary

Serves as a security control to make corruption of the database more difficult

Makes governance of the process more democratic.

Corollary 1A:  Blockchain solutions should not be rated based on decentralization; instead they should be rated on their ability to achieve their goals.

Contrary to many popular opinions these ends can be met using approaches other than decentralization.  Decentralization is a control technique.  But is is only one of many.  If the above goals are met, does it matter if decentralization is used as the tool?

Corollary 1B:  If the goals for which decentralization is employed can be met without it, decentralization may not be necessary.

Tenet #2:  Decentralization is not a single characteristic.

In my blockchain glossary blog, I deconstruct the concept of decentralization into the following independent dimensions:

Architectural Decentralization: the redundancy of the architecture of a data system that provides it with the resiliency to continue operations if at least one node containing at least some of the data becomes inoperable or compromised.

Data Decentralization:  the requirement that there be more than one nodes to represent the full content of a blockchain. If there are many nodes, but each node contains a complete copy of the data, the data is not decentralized.

Procedural Decentralization:  the requirement that more than one independent validator is required to validate new transactions added to the system

Political Decentralization:  the requirement that power to make and change rules for the system (governance) be distributed among the independent stakeholders of the system

There are likely other components that I just haven’t thought about yet.  I welcome your suggestions on these others.

Corollary 2A:  A blockchain can be decentralized along one dimension, but not another.

The different dimensions listed above are independent of one another.  Being decentralized along one dimension does not imply decentralization along any of the others.

Tenet #3:  Most blockchains might not be decentralized.

Once we understand that decentralization is not a single characteristic, and we further grasp Corollary 2A that being decentralized in one dimension can be independent of being decentralized along another dimension, concluding that any blockchain is “decentralized” becomes complicated.  To qualify as decentralized, do all qualities have to be met?  If not what are the rules for making such a determination?  My personal belief is that talking about the broad term “decentralization” is a fool’s errand.  We need to be specific about which dimension we are talking about in order to have a meaningful exchange of ideas.  Each one should be considered a topic unto itself.  Perhaps we need to remove the term decentralization from our vocabulary and find substitute terms for each of its various dimensions.

Table 1 provides a comparison of popular blockchains based on the four components of decentralization described in Tenet #2.

Table 1:  Component decentralization for five popular blockchains.

*Minimum number of colluding parties (typically mining pools) needed for a successful 51% attack, based on current mining distribution.  The higher the number, the more decentralization exists.

From Table 1, it can be seen that the popular blockchains included in the table are all architecturally decentralized.  But none of them decentralize their data.  In the blockchains selected, each node has a complete copy of every transaction.  This may be beneficial for transactions that are public records such as land titles.  It can become problematic when transactions involve personal or confidential data.  The pseudonymity of being able to hide ones identity behind a complex account number is commonly broken.  The tracking down of Dread Pirate Roberts by the FBI to bring down the Silk Road is a good example.  The US government’s recent blacklisting of account numbers of Iranians stealing and laundering money is another.  [See “US Blacklists Bitcoin Addresses of Iranians Behind SamSam Ransomware”]

You will have to draw your own conclusion whether the ability of three parties to control a blockchain constitutes decentralization.  In the case of all of the blockchains, except EOS, mining pools have grown so large that it only takes two or three of them to collude in order to carry out a successful 51% attack.  Such attacks have already been successful on some smaller blockchains.  [See Hertig, Alyssa:  “Blockchain’s Once-Feared 51% Attack Is Now Becoming Regular” Coindesk.com  08 JUN, 2018]

While I show in the table that all but EOS are politically decentralized, this point can be argued.  Most of the public blockchains allow anyone to participate in governance decisions.  But in reality, only a handful of developers are typically making decisions for the “silent majority” of stakeholders.

Corollary 3A:  It doesn’t matter if a blockchain is decentralized.

What matters is that a blockchain meets its stated objectives for its stakeholders of availability, integrity, fairness, and confidentiality (when applicable).  If it uses decentralization as a tool to achieve one or more of its objectives, so be it.  But if it achieves the same end using another approach, does it really matter if it is not decentralized?

By Jeff Stollman, principal consultant, RMTMinc.com

After spending several years working in the blockchain ecosystem, I am continuously amazed at how much energy we waste talking past one another because we lack a common understanding of the terms that we use.  Much vitriol is expended in debates in which parties may be in furious agreement, but are so lost in their own personal definitions of terms that they don’t recognize their agreement.  Still others hold zealously to certain opinions that cannot be supported if they took the time to define their terms.  Instead, they use broad terms such as “decentralization” in multiple ways during the same conversation, dancing between the definitions as it suits them to make their points, never realizing that they are talking in circles.

In an effort to save us from ourselves, I believe that there is a need to develop a common set of definitions.  These will allow us to continue moving forward, rather than continuous chasing our tails.  What I propose below is a straw man.  I don’t claim that these definitions are “right” by some divine power invested in me.  (I haven’t known it all since I was 17.  And that was half a century ago.)  I welcome feedback from others who would prefer their own definitions.  In the end, the community, as a whole, will decide.  But if we don’t start the conversation now, we will continue to lose time and energy in fruitless controversy.

Bitcoin

1.  An application that generates and tracks the movement of its namesake cryptocurrency. Bitcoin employs a variety of techniques and technologies to propagate its ecosystem. These include

 1.  Blockchain technology to make the log of Bitcoin transactions tamper evident

 2.  Proof of Work (PoW) to incentivize participation in a consensus mechanism to validate new transactions.

 3.  Block Creation that bundles transactions into groups that can be validated together to increase throughput

 4.  Mining is an incentive program built into Bitcoin that creates new cryptocurrency tokens and disseminates them to those who participate in the PoW validation process. The incentive system served to bootstrap Bitcoin.  The offer of financial incentives served to broaden interest and participation in validating transactions.  Increased participation in validation serves to increase the integrity of the Bitcoin application.   It also served to increase interest and participation in using the Bitcoin application generally.  Only 20 million Bitcoins have been set aside for mining.  Mining rewards will terminate once these have been awarded to validators.  At that point, validators may substitute transaction fees to justify their investment of time and equipment in the ongoing validation of new transactions.

 5.  Distributed copies of the Bitcoin transaction log to

 1.  Provide business continuity resilience should one or more nodes lose connectivity to the network

 2.  Enhance tamper resistance by creating more copies of the log that need to be consistently altered to falsify existing records

 3.  A second consensus mechanism to compare copies of the transaction log in order to discover and repair versions that are out of sync with the majority of copies.

Blockchain

1.  A cryptographically linked list in which each new record contains a cryptographic hash of its predecessor and is “signed” (i.e., its own has begins with a particular numeric sequence such as 0000). In this way, if a record is corrupted, its hash will change and all succeeding records will evidence this inconsistency because their hashes will no longer begin with the designated numeric sequence.

2.   The explanation of blockchain given in the Bitcoin whitepaper is: “A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post.  The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash.  Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.”

3.  A second cryptographic technology which can also provide tamper evidence similar to that provided by blockchain is called Directed Acyclic Graph (DAG). DAG solutions are technically not blockchains, but because they provide the same ability to rapidly show that a record has been tampered with, they are often implied in references to “blockchain.”  Think of blockchain as a pliers and DAG as a wrench.  Each tools works differently, but both can be used to unscrew a bolt.

Decentralization

1.  A vague, generally undefined term, that people associate with blockchain solutions. In fact, the term can be decomposed into several different features including the following:

Architectural Decentralization

 1.  The redundancy of the architecture of a data system that provides it with the resiliency to continue operations if at least one node containing at least some of the data becomes inoperable or compromised.

Data Decentralization

 1.  The requirement that there be more than one nodes to represent the full content of a blockchain. If there are many nodes, but each node contains a complete copy of the data, the data is not decentralized.

Procedural Decentralization

 1.  The requirement that more than one independent validator is required to validate new transactions added to the system

Political Decentralization

 1.  The requirement that power to make and change rules for the system (governance) be distributed among the independent stakeholders of the system

2.  Contrary to popular misconception, the various forms of decentralization described above are techniques to achieve certain goals.  They are not a goals in themselves.  To pursue decentralization for its own sake, unnecessarily constrains potential solutions.

Directed Acyclic Graph (DAG)

1.  DAG is a mapping technique. When applied to transaction recording systems, it can map transactions that occur in only one direction.  For example, Manufacturer M1 ships 10 widgets each to Distributors D1 and D2.  Then Distributor D1 ships 5 widgets each to Retailer R1 and Retailer R2.  Distributor D2 ships 5 widgets each of Retailer R2 and R3.  A graph of this would look something like this:

2.  The graph above is directed: it moves from left to right only.  And it is acyclic:  it does not not cycle back on itself.  This particular DAG is a special case.  It can be recorded in a single blockchain transaction record as a sequential list.

3.  Blockchains typically use a validation technique the requires each new block to be validated based on the preceding block. Assuming for simplicity that each transaction is its own block, validation in a blockchain would look like the illustration below:

4.  As seen in the illustration the validation of Transaction T2 is based on the preceding block Transaction T1. Similarly,  T3 is based on T2, etc.

5.  Solutions that tout themselves as DAGs typically validate the transaction based on the concurrence of the transacting parties. They do not require third-party validator.  This eliminates the cost of mining.  It also allows transactions to be validated in parallel, rather than in serial.  This gives them greater throughput — a shortcoming of many of today’s blockchain solutions.  A validation mapping illustration for a simple DAG is shown below.

6.  This approach does present the potential for “double spend.” That is, in the supply chain graphic above, there needs to be a way to keep Distributor D1 from shipping 5 units each to Retailers R1, R2, and R3 (a total of 15 units), when he has received only 10 units from Manufacturer M1.  Different DAG solutions resolve this problem in different ways.

Disintermediate

1.  Removing intermediaries from a process.

2.  Disintermediation is viewed by many as a goal of blockchain.  It is a false goal.  Blockchain does not remove intermediaries, it substitutes them.  By using Bitcoin for payment, banks can be bypassed.  Their role as a trusted intermediary is replaced by the Bitcoin blockchain.  Transacting using Bitcoin (or other cryptocurrencies) still includes intermediary transaction fees, just as banks do.  Bitcoin transaction fees may be lower than those currently offered by banks, but that is merely because it offers competition.  In addition, because the entire world does not accept Bitcoin for payment, those transacting in Bitcoin also incur fees from exchanges to convert fiat currencies into Bitcoin to make the payment transactions.  And the payee pays a similar fee to convert Bitcoin back to fiat currencies useful for its own expenses.

Distributed Ledger Technology

1.  This is a popular term that has no clear definition. Some people use it as a synonym for “blockchain.”  Others use it explicitly to distinguish an implementation from being a blockchain.  Perhaps this is just a marketing statement:  solution providers want to distance themselves from the hype around the term “blockchain” in order to be taken more seriously.  But I have witnessed many people getting quite heated in debating whether a solution a blockchain or distributed ledger technology as if there is a clear and obvious distinction.

2.  On its face, the term suggest that a ledger is used. This is a common feature of a blockchain solution, because a blockchain transaction record is a ledger of all of the transactions.  Arguably, a Directed Acyclic Graph may also be a ledger.  While a DAG may not be a single serial listing of the transactions, it does still record them all.

3.  A second feature of the term is that it is distributed. This suggests that either complete copies of the ledger are stored in multiple locations or that pieces of the ledger are stored in multiple places.  There is no clear consensus on this, but most solutions that call themselves distributed ledgers technology store full copies of the ledger in multiple locations.  As I have noted in my definition of “blockchain”, even though most current blockchains do store their ledgers in multiple locations, this is not a mandatory requirement for creating a cryptographically linked list.  Rather it is a preferred embodiment of many solutions that use blockchain’s cryptographically linked list.

Governance

1.  The collection of rules that determine how a community operates.

2.  These rules can include

 –   Who gets to participate in the community

 –   What rights each party has

 –   What rights each party has in any decision-making process including both the development of the initial rules and any subsequent modifications to them.

 –   How decision (voting) power is apportioned among stakeholders. (E.g., is voting power apportioned by one-party-one-vote, by transaction volume, hashing power, some combination, etc.)

Hash

1.  A cryptographic technique that creates a unique one-way transformation of data. Any data can be hashed (text, graphics, audio, video).  And the same data will always yield the same hash.  Hashes typically have a fixed length (e.g., 256 or 512 characters).  While it is extremely difficult to reverse a hashing function and reproduce the original from the hash, hashes are an effective way to ensure the authenticity of data.  For example, if two copies of a document have the same hash they can be assumed to be identical.  If even one character is off, they will have substantially different hashes.

Hashing power

1.  A measure of the computing power of a device or group of devices for solving hash-related problems used in certain transaction validation techniques. To achieve procedural decentralization, it is important that hashing power be distributed among independent participants.  The distribution of hashing power is more relevant than the distribution of participants because one participant (such as a mining pool) may be running enough devices to take over the network even if there are hundreds of smaller participants engaged in validation.

Independent

1.  Non-colluding. Independence refers to the distinct motivation of each party.  Independent parties operate without collusion.  They may have the same values and motivations, but operate for their own account.

2.  Merely having a large number of participants does not matter if they are not independent. While Bitcoin (and other “blockchain” applications, as well)  may have many miners participating in its consensus mechanisms (thousands in the case of Bitcoin), many have aligned with mining collectives that operate as one.  As few as three of these pools have the power to conduct a 51% attack on the system.

Intermediary

1.  An entity that provides trust among parties transacting on a network. (The term network does not refer to the connectivity that facilitates the interactions.  e., it is not the “network” layer – Layer 3 — in the classic Open Systems Interconnect stack.)

2.  An intermediary may be

 1.  the owner of the network (e.g., a corporation such as Amazon or eBay or a non-profit foundation)

 2.  an independent party (e.g., an accounting firm that verifies a corporation’s financial reports to its shareholders

 3.  stakeholders in the network (e.g., miners on the Bitcoin or Ethereum network)

 3.  As per item 2.3 above, a blockchain, itself, can serve as an intermediary.

Node

1.  A computing device that stores all or part of the transaction data in a system.

2.  Depending on the particular technology underlying the application, nodes may also participate in the validation of new transactions and/or maintaining the consensus version of the already recorded transactions.

Smart Contract

1.  A computer program stored on a blockchain that executes rules that follow the pattern IF->THEN,ELSE.

 1.  For example, the program may represent an agreement between Alice and Bob such that IF Alice sends Bob a widget, THEN $5 will be transferred from Bob’s account to Alice’s account, ELSE no funds transfer will take place.

 2.  Though the word “contract” is included in the term, it may not be a legally binding agreement.

3.  It’s usefulness comes from the fact that the events are firmly enforced by the computer code. There is no wiggle room.

 1.  In the example transaction above, the smart contract could also require that Bob place $5 in escrow to ensure that as soon as Alice verifies shipment (or receipt is verified by Bob, perhaps through his signature on a shippers tablet) the funds are transferred.

 4.  Because the smart contract is stored on the blockchain, any tampering with the computer code can be promptly detected.

 1.  But writing smart contracts that are “bulletproof” is difficult. Millions of dollars have been stolen by exploiting flaws in smart-contract computer code.  These thefts do not require modification of the code, merely exploitation of their flaws.  Translating human intention into code can be challenging, depending on the complexity of the terms being encoded.

51% Attack

1.  The validation protocols used for most blockchain (and DAG) solutions are vulnerable to a 51% attack. These means that if 51% of the participants (as measured by their hashing power) collude, they can take control of the system and create false records and/or modify past records.

2.  Successful 51% attacks have already been conducted on some smaller blockchain networks.

3.  Larger networks are also vulnerable when large numbers of validators band together into mining pools, reducing the number of independent validators.

By Jeff Stollman

Principal scientist, Rocky Mountain Technical Marketing, Inc.

The Myth

Decentralization is a term that is hard to separate from blockchain.  To many in the current blockchain ecosystem decentralization is a mandatory requirement for any blockchain-based solution, regardless of the solution’s purpose.  In his article, Cutting Through the Blockchain Hype, Andreas Antonopoulos asserts, “Decentralization is the lens through which blockchain systems must be evaluated.”[1]  There seems to be an almost religious belief that decentralization serves a higher purpose.  It is viewed as a political necessity that creates a more just and fair world.  It is presumed to create trust through its mere existence.[2]

Unfortunately, there is no agreed-upon definition of “decentralization.”  And much debate is wasted with various parties talking past each other — each assigning a different, but undefined, meaning to the term.  In fact, the meaning of the undefined term used by the same person often changes in mid-conversation.

One of the reasons for this lack of clarity is that decentralization of a blockchain application does not constitute a single characteristic.  It is like the term “vegetable.”   If one claims that “vegetables are good for your health,” what does that really mean?  One definition of “vegetable” is “all edible plant matter.”[3]   Are nuts good for someone with a nut allergy?  Is wheat good for you if you have celiac disease?  To judge the value of the statement requires more specificity (which vegetable?) and/or more context (whose health?).  Similarly, when we talk about the value of decentralization for blockchain solutions, we need to know which aspect of decentralization we are referring to and in what context (which application?) we are considering it for.

In this paper, I will first attempt to define decentralization by breaking it down into component parts — the various forms that decentralization can take in a blockchain environment.  Second, I assess whether current blockchains actually achieve decentralization.  Third, I dispute the assumption that decentralization is necessary to create trust.  Finally I argue that decentralization alone is not sufficient to create trust.

1.    Defining “Decentralization”

One of the reasons that there is so much confusing emotion around the topic of decentralization is that it is typically treated to as if it represents a single aspect of a blockchain solution.  In fact, it is composed of several distinct components.  And it is the conflation of these distinct elements into an all-encompassing term that creates much of the confusion.  Just as we can break vegetables into components such as carrots, peanuts, tomatoes, and tomato greens, we can break down  decentralization into at least the following four separate components:

1. Architectural decentralization

2. Data decentralization

3. Procedural decentralization

4. Political decentralization

I will attempt to define each of these separately below.

[NOTE:  I acknowledge that this is just a starting point.  Others may be able to deconstruct the term differently.  But deconstruction is necessary if we are to ever come to a meeting of the minds.  So consider this a straw man for which I welcome your feedback.]

Architectural decentralization

I define architectural decentralization as the redundancy of the architecture that provides a blockchain solution with the resiliency to continue operations if at least one node[4] becomes inoperable or compromised.  Public blockchains such as Bitcoin and Ethereum have thousands of active nodes and will continue to operate without impairment even if several hundred nodes withdraw from their networks or lose power (e.g., prompted by a hurricane that knocks out power and network infrastructure along the entire US East Coast).

There is no defined minimum number of nodes that need to be operating for a blockchain solution to be considered decentralized.  Obviously one node provides no redundancy.  Two nodes provides a minimal level of resiliency, but more nodes is typically better.  There is no magic number.  The marginal benefit of adding another node drops off significantly after a small handful of nodes (as long as they are geographically and organizationally distributed).  For example, adding a third node increases decentralization by 50%, while adding a 101^st node increases decentralization by only 1%.

Architectural resiliency is not unique to blockchain data structures.  Current business continuity practices distribute vital data stored in traditional databases by keeping copies in multiple data centers that are geographically dispersed.  Depending on the criticality of the data, it may be stored in two or three different locations.  Maintaining two copies of business-critical information is quite common.  Seldom does the number of copies exceed three.

Data decentralization

I define data decentralization as the number of nodes required to represent the full content of a blockchain. Decentralization of data can help keep confidential data confidential because decentralized data nodes hold only portions of the data so that, by themselves, they are insufficient to expose confidential information.

Data can be decentralized by storing certain critical data off the blockchain.  But often the information that actors desire to keep confidential is the very data that needs to be tracked on the blockchain for the solution to provide value.  Often an important value of a blockchain solution is to create a single source of truth that can be agreed to by all stakeholders.  But if critical information is not stored on the blockchain, this single source of truth may no longer provide the desired value.

For example, the pharmaceutical industry is developing a track-and-trace solution to help identify counterfeit products before they become a public-health problem.  An efficient way to do this is to have all trading partners contribute their purchasing and sales data to a centralized database to create a “single source of truth.”  This would allow any stakeholder (including the FDA and law enforcement) to rapidly trace the path of a serialized product through the supply chain to verify its authenticity.  But trading partners in the industry want to maintain the confidentiality of their purchasing and sales histories.  Publicly disclosing this proprietary information to their competitors would jeopardize their competitive position.  But storing this information off-chain in their own data centers or encrypting it on the blockchain would severely hamper the ability of stakeholders to verify the authenticity of a product as well as their ability to identify counterfeits or recall compromised or substandard products.

Another way to protect confidential data is to store it on the blockchain but to also break up the data into shards that, by themselves include insufficient data to recreate the confidential information.  Different shards could be stored on different nodes so that no node (or particular groups of nodes) can piece together what they are not supposed to see.  But the overall blockchain code (or certain “super” nodes) may have the ability to put together the necessary shards to ensure the integrity of each block and its component transactions.  This is similar to a RAID 5 solution of adding resiliency to data storage.[5]   However, sharding is a new technology that is not proven in actual use.  Typically, every full node contains a complete copy of the entire blockchain data structure.  This is done intentionally to allow every node to “audit” the contents of the blockchain.

Procedural decentralization

I define procedural decentralization as the number of independent validators participating in the validation of new blocks.  Decentralization of validators reduces the likelihood that validators will collude for their own benefit at the expense of the integrity of the blockchain.  As with architectural decentralization, more is better – as long as each validator is operating independently.  But similar to architectural decentralization, the marginal value of adding one more validator drops off rapidly as more validators are added.  What is more important than numbers is that each validator acts independently.  Obviously a small handful of independent (non-colluding) nodes is sufficient.  But because collusion becomes more difficult the larger the number, larger numbers are beneficial – especially for public, permissionless blockchains.[6]

Political decentralization

I define political decentralization as the distribution of power in the governance structure of the blockchain:  who makes the rules and who approves changes to them.  Perhaps it would be better described as “democratization”, rather than “decentralization.”  But rather than “one man, one vote,” many blockchains that claim to be politically decentralized give some parties more power than others.  In Bitcoin, the more hashing power you provide, the more powerful your vote can become.

Political decentralization is desirable to prevent hegemony of one powerful entity or group of entities over the rest of the stakeholders of the blockchain.  Bitcoin has no “official” governing body.  In theory, anyone can have a voice in the continuing flow of changes that are being added to the basic Bitcoin infrastructure (originally defined in a white paper by Satoshi Nakamoto).  Some blockchains have designated governing bodies.  For example, Ethereum and Tezos are managed by Swiss foundations.  On the other side of political decentralization, some private blockchains are governed by a single enterprise.  Maersk, partnered with IBM, has recently implemented a blockchain (TradeLens) for the tracking of ocean freight.  But, because Maersk controls the blockchain solution, its competitors have been reluctant to join.  As Michael Wight notes in an article published on theblockchainland.com, “How would you feel about providing support to your rivals? Not good.”[7]  TradeLens is politically centralized.

2.    Is Decentralization Being Achieved?

Despite the best of intentions, current blockchains held up as prime examples of decentralization actually fall short of this goal.  We will look at how some popular blockchains rate using the four components described above.

Table 1 summarizes how selected popular blockchains stack up in each of the four defined categories of decentralization.  What the table makes clear is that calling any one of these blockchains “decentralized” is an inappropriate pronouncement.  None of them decentralize data.  And depending on your view of their vulnerability to a 51% attack, it is unclear whether any of them are procedurally decentralized.

I suggest that the relevant question isn’t whether a blockchain solution is decentralized; It is, instead, whether the components for which decentralization is important in a particular blockchain solution are truly decentralized.  This would require a separate assessment, based on the unique requirements for each solution.

Table 1:  Component decentralization for five popular blockchains.

*Minimum number of colluding parties (typically mining pools) needed for a successful 51% attack, based on current mining distribution.  The higher the number, the more decentralized the blockchain should be.

Even though my assessment of decentralization for the listed blockchains makes them appear very similar, your mileage will vary.  Other evaluators will have differing opinions.  For this reason, I provide some additional clarifying discussion of how I arrived at the ratings in Table 1 for each form of decentralization,

Architectural decentralization

Architectural decentralization is typical of all public blockchains.   With thousands of nodes, the major blockchains will be unaffected by the loss of several hundred nodes if a country outlaws its use or a disaster causes a regional outage.

Architectural decentralization may be less for a politically centralized blockchain such as Walmart’s lettuce and spinach blockchain.  This system runs on the IBM Food Trust blockchain.  But “IBM believes that a few dozen nodes are necessary to establish a trusted chain of data.”[8]  Presumably, these nodes will be spread across IBM’s global data centers to provide sufficient geographic decentralization to survive political restrictions or natural disasters.

It is safe to conclude that – overall — most current blockchains are architecturally decentralized.

Data decentralization

Most popular blockchains are not decentralized in terms of data.   It is common practice to centralize all the data in each copy of the data structure.  This is true of Bitcoin, Bitcoin Cash, Ethereum, Neo, and EOS, among others.  For this reason, I am not familiar with any current blockchains that decentralizes its data.

To avoid this centralization of data some designers of new private blockchain solutions are considering keeping much of their data off-chain.  Blockchain solutions such as Mediledger merely contain pointers to the location of the actual data.[9]  This can provide better confidentiality of data.  However, on the flip side, if the data are not accessible in its many off-chain locations, it may become problematic for the system to prevent double-spending of a cryptocurrency or double selling or a single asset.  The blockchain might not contain sufficient information to verify that a selling party has the asset that s/he is offering to sell.

Another possible solution is data sharding in combination with a distributing file system such as the Inter-Planetary File System (IPFS).[10]  If, rather than storing entire files, a blockchain spread its data in various shards stored on a distributed peer-to-peer file system, it is conceivable that the blockchain could still verify ownership of assets and still maintain confidentiality and decentralization.  I am aware of no such system in existence today.  And achieving a reasonable throughput would be a challenge for such a system, because of the latency required to continuously reassemble shards to verify new transactions.

Procedural decentralization

One of the clever design characteristics included in the original Bitcoin white paper is the creation of an incentive system to reward participants for good behavior.  Any node in the system is free to participate in the block validation process.[11]   The process is established to ensure that only correct transaction data is added to the blockchain.  The Proof-of-Work (PoW) system proposed in the Bitcoin white paper[12] that validates new blocks is capable of doing this even when some of the validators are bad actors[13].  The system establishes a competition to validate each new block.  And as long as a majority of nodes concur with the node that validates the new block, the block is added to the blockchain.

Blockchains that use PoW to validate new blocks are susceptible to a 51% attack.  That is, if more than 51% of the nodes[14] participating in the validation process are bad actors, they have the power to corrupt the integrity of the data being added.  If 51% of the participating nodes are nefarious, they can remove a transaction, alter a transaction, or fabricate a transaction that is included in a new block as it is added to the chain.[15]

Notionally, a 51% attack becomes harder when there are more nodes participating in the process because it takes more nefarious nodes to overwhelm the PoW process.  Blockchains with only a few participating nodes can be taken over by a bad actor who establishes multiple new nodes to participate in the process.  If there are only 49 nodes participating, s/he can set up 51 new nodes and dominate the results.

One way to defeat a 51% attack is to offer a reward for participation in the validation process.  This incentive increases the number of participating nodes, making it harder for a bad actor to overwhelm the system.  Blockchains that use PoW often offer rewards (e.g., newly minted tokens) for participation.

Validating blocks in exchange for new tokens is called “mining.” And the PoW process includes an assumption that nodes are operating independently, so that the likelihood of hundreds of nodes colluding is small.  But this “reasonable” assumption did not anticipate mining collectives.  An unintended consequence of mining rewards has subjected even blockchains with thousands of participants – such as Bitcoin – to the risk of a 51% attack because of the growth of mining pools.

In order to compete effectively in obtaining mining rewards, individuals have banded together to form mining pools.  Pooling their nodes increases the possibility that their pool will solve the problem, bringing in a more steady stream of income to be shared than if they acted individually.  But pooling also gives whomever is running the pool a lot of power.  As shown in Figure 1, certain pools have grown so large that only two or three of them need
collude to coopt the integrity of the blockchain.[16]

For smaller blockchains, 51% attacks have already occurred, resulting in the theft of millions of dollars.[17]

Creating a block validation protocol that includes ten “independent” validators who would each have 10% of the validating power would appear to provide a more robust validation scenario than currently exists for Bitcoin.  It would take collusion of six parties for a 51% attack rather than collusion among only three of the larger mining pools.

Because of the vulnerability of even large blockchains to a 51% attack, it is debatable whether most blockchains are procedurally decentralized.  The determination becomes a numbers game:  how many “independent” validator nodes does it take before a blockchain is considered “decentralized”?  For the blockchain solutions displayed in Table 1, I leave this conclusion to the reader.

Political decentralization

Another problem that occurs in blockchains results from the governance rules established to operate them.  When establishing a new blockchain, a set of rules is established that define their operations and participation.  These terms and conditions specify such things as who can use the blockchain, what form of block validation it will use, who can be a validator, what the rewards are for validation, what the format is for each transaction and for each block, voting rights, etc.  But people frequently change their minds.  And blockchains – particularly public blockchains – are often under pressure from certain groups of members to alter their operations.  The inability to achieve consensus leads to a civil war within a blockchain community that often results in one group seceding (“forking”) from the main system and starting their own new system.

We have already witnessed the forking of the two largest blockchains.  When a dispute arose over increasing the block size to increase throughput and reduce transaction fees, Bitcoin split into two blockchains – each with its own rules and cryptocurrency:  Bitcoin (BTC) and Bitcoin Cash (BCH).  Ethereum experienced a major dispute over how to treat the theft of millions of dollars from a smart contract issued by a Distributed Autonomous Organization (DAO) establishing an investment fund.  This caused Ethereum to split into two blockchains with separate currencies:  Ether (ETH) and Ethereum Cash (ETC).  There is now a plan to further fork Bitcoin Cash.  And it is unclear what will happen to Ethereum when it eventually migrates from the PoW validation approach to the more efficient Proof of Stake (PoS)[18].

Other blockchain communities are in the midst of governance battles.  Tezos founders have been alienated from the foundation established to run their blockchain.  And the EOS blockchain community is rethinking the power afforded to its designated group of block validators.

Blockchain governance suffers from the same issues as does political governance.  Because governance is a qualitative process undertaken by people, it is always in flux.  This has been going on for the history of mankind as we witness on the political front where wars and revolutions are always underway somewhere on our planet.

Code as Governance

One solution that many decentralization zealots imagine can solve the governance failure problem described above is to embed the governance rules in computer code – thus making them hard-coded and independent to the whims and political winds of human opinion.  Some supporters of this approach claim that “code is more trustworthy than people” because it is fixed and not subject to these human whims.

While it is true that code can maintain a fixed set of rules, the notion of “code as governance” overlooks a basic reality that any experienced software developer recognizes:  all code requires maintenance.  Whether the updates are to fix bugs, adapt to new requirements (including government regulations), or to add features not initially imagined, sophisticated software applications are not static.  Recently, a bug was found in the Bitcoin Core code that put the currency at serious risk[19].  Fortunately it was fixed before damage was done.  But it emphasized the point that code is not static.  For this reason “code as governance” eventually devolves into the same governance problem described above:  having humans voting to approve changes, with the risk that alienated members will secede.

It is arguable what the best form of governance is.  The argument has been at the core of political philosophy for thousands of years.  And it is equally unclear whether decentralization of power is being achieved by any government or any blockchain.  A popular belief in the West is that democracy – for all of its failings – is better than centralized power.  But it is unclear that the result is more than shifting power from one group to another.  If you are a Bitcoin holder, did anyone ask you if it was OK to implement the patch of the recently discovered vulnerability?  You may trust the handful of Bitcoin Core developers who make these decisions.  And, thusfar, their decisions may be in the best interest of the broader Bitcoin community.  But Bitcoin has already experienced one major fork.  So it has not solved the governance problem.

3.    Is Decentralization Necessary To Create Trust

Advocates of decentralization typically believe that decentralization is a mandatory condition to ensure trust.  Several argue that the trust born of decentralization can lead to better outcomes in trust situations such as the Prisoner’s Dilemma.

The Prisoner’s Dilemma is a game-theory construct that is often used by the police when they capture several people involved in a crime.  Having limited physical evidence as to who the guilty parties are, the police will isolate their prisoners.  They will make an offer to each one that if they confess and give up their colleague, they will be given a lesser sentence in exchange for their cooperation.  If none of the prisoners confesses, there is a likelihood that they will all go free from lack of evidence.   This is the best outcome from the prisoners’ point of view.  But if one of their compatriots confesses and betrays them, the prisoner who fails to confess will face the full sentence.  Assuming two prisoners, the options boil down to the following:

If A and B both remain silent, neither will go to prison.

If A betrays B but B remains silent, A will be sentenced to one year in prison and B will serve three years in prison (or vice versa)

If A and B each betray the other, each of them serves two years in prison

The best outcome for the prisoner participants is Scenario 1.  But the typical outcome is that at least one of them breaks down, leading to prison terms for both of them.   The interesting part of this result is that pursuing individual reward logically leads both of the prisoners to betray when they would get a better reward if they both kept silent..

In society, we are often faced with similar dilemmas where the attainment of the best outcome requires trust, but the trust is not there.  If A & B could trust each other, they would follow Scenario 1 and both be better off.  Blockchain adherents argue that the trust provided by decentralized blockchains provides improved opportunities for collaboration that will achieve the optimal outcome (Scenario 1 above).

While I agree that increasing trust between A & B may yield this benefit, I do not believe that decentralization is a necessary condition to achieving trust.  Trust can be achieved in centralized systems, as well.  We leverage trust every day in common activities that involve strangers.  For example,

• When we purchase fuel for our vehicles, we trust that the liquid we fill our tanks with is authentic gasoline. We don’t need a large number of validators to test the fuel for us.
• When we make an online purchase and pay with a credit card we trust that the item will be shipped to us and will perform as advertised. If it is not received, or does not work, we often further trust that the vendor from which we made the purchase will rectify the problem.    Failing that, we rely on recourse from the credit card issuer to help us resolve the problem.

As the above examples illustrate, trusting third parties who are strangers to us does not require decentralization.  Mechanisms including reputation systems and third-party enforcement (whether or not by government law enforcement) can often provide sufficient levels of trust to induce the use of a system.  People freely trade on stock exchanges around the world.  Most of these use third-party enforcement that includes both private entities (clearinghouses) and public entities (law enforcement) to create sufficient trust to allow tens of trillions of dollars of transactions in the world each year.[20]  And bond markets, which are more opaque, still manage to support transactions of a similar magnitude.[21]  As well, as we discuss below, decentralization may not be sufficient to ensure trust.

4.    Is Decentralization Sufficient To Create Trust

In previous sections we broke down decentralization in terms of the components of a blockchain system.  In this section we take a different look at decentralization from the perspective of the outcomes of a blockchain system.  Looking at blockchains from an output perspective, the concept of decentralization breaks down into three components:

Decentralization of Power

Decentralization of Duties

Decentralization for Availability

I address each of these separately below.

Decentralization of Power

One of the most strident arguments stressed by blockchain advocates is that blockchain will bring about a redistribution of power from a single entity that currently maintains hegemony over a system to “the community” at large.  It is presumed that decentralizing ownership will reduce hegemony.  In some cases, this may well be true.  But decentralization of power also creates inefficiency.  It therefore becomes valuable to optimize the decentralization of power, rather than merely maximize it.

Certainly, when a for-profit business has full control over a system, it is likely to be tempted to maximize profits.  And maximizing profits typically comes at the expense of the system’s customers/users.  Telecom providers such as AT&T, and Verizon are always looking for opportunities to increase the prices they charge for their services and/or decrease the services they provide for their current price.  For example, these carriers used to offer unlimited data plans, but now offer plans with caps, and charge a premium when the cap is exceeded.  And because there are only a few providers of such services, many users feel that they have no real choice in the service and pricing options available to them.  Industries such as telecom and cable TV are able to exercise a form of monopoly power.  [More specifically, the power that they exercise is “oligopoly” power, because there are a handful of service providers to choose from.]  But this small group doesn’t offer much choice.  Each offers a limited set of “take it or leave it” plans.  There is no negotiation available to consumers.  If we don’t take the plan from Vendor A, our alternative is to take a similar plan from one of the others.

But decentralized systems do not necessarily solve this problem.  Bitcoin is widely considered a highly decentralized blockchain.  It is architecturally decentralized; it has no owner.  There is no entity that controls Bitcoin.  Yet, many changes have been made to Bitcoin.  Because there is no governance body, who approves the changes?  If you are a holder of Bitcoin, did someone ask you for your opinion?  In fact, while Bitcoin is clearly used by a diverse group of people around the globe, a small group of developers – five, in fact – are responsible for most of the changes to the code.[22]  They have no official authority to do this.  But these people — whom you likely do not know — are making the decisions.  While “officially” I may have a “say” in changes made to the Bitcoin system, I don’t actually have a “vote.”  There is no formal mechanism to ensure that my opinion is heard and counted.  And different Bitcoin constituencies often have opposing views on changes.  Miners want small block sizes in order to have more blocks to mine – a source of income for them.  Users want large block sizes to keep mining costs down, lowering their transaction costs.  If the developers and miners behind Bitcoin decide to change the Bitcoin system, members of the Bitcoin community typically have only the choice to either accept the change or find another blockchain system that might better suit their needs.  It isn’t much different than the choice between carriers for internet and TV programming.

On the other hand, what if a blockchain is administered by a non-profit foundation whose sole purpose is to ensure that the system serves its members according to its mission statement?  The foundation explicitly outlines the voting rights of each member.  Such a system would be considered centralized.  It is operated by the foundation.  But the foundation itself, is established to serve it members, not to retain profits.  Wouldn’t such a “centralized” plan reduce hegemony?  And wouldn’t it be likely to operate more efficiently than a decentralized system without a clear administrator?  The SWIFT banking network is a good example of this.  And it does not currently even use blockchain technology.  But its centralized governance structure works for its members.

[Blockchain zealots will argue that while SWIFT works well for the banks that us it, it is slow and costly to consumers.  I heartily agree.  But from a consumer perspective, SWIFT has operated as a monopoly.  But among its banking customers, it has operated as an effective and trusted processor of international payments.  Now, with the threat of competition from alternative solutions (most of them blockchain-based), SWIFT may have the creativity to adapt its efficiency and pricing to remain competitive.  Building a new blockchain-based system to compete with SWIFT may offer a more cost-effective solution for consumers, but such a system will still need governance, and will still require some level of fees to support the infrastructure.]

Decentralization of Duties

Decentralization of duties is used to ensure that specified processes are being followed consistently to protect the integrity of a system.  If one party validates all of the blocks in a blockchain, there would be a strong incentive to falsify certain records for personal gain.  “Separation of duties” is a security control that seeks to limit the scope of any party’s duties so that they cannot act alone to degrade the integrity of a system.  Including many “independent” parties in this separation of duties further reduces the opportunity for collusion.

Bitcoin implemented separation of duties by requiring a consensus of block validators (a.k.a. miners) before a new block is added to the chain.  Bitcoin’s implementation also allowed anyone who wanted to participate to establish a full node and contribute to the validation of new blocks as they are added to the blockchain.  This “permissionless” system achieves separation of duties for the critical block validation activity, subject to the 51%-attack problem described above.  But this is not the only way to achieve the necessary separation.  And other methods may not be as vulnerable to a 51% attack.

One method currently being tested by some new blockchains is Delegated Proof of Stake (DPoS).  Blockchains, including Steemit, EOS, and BitShares are using this process for block validation.  In this approach, a small group of validators is selected to perform the validation.  They may be selected by votes of the other users.  They may be selected based on their willingness to post a high bond (stake) that they forfeit if they are found to be approving falsified blocks.  And their selection may rotate to prevent any one party from being able to falsify enough records to cover their trail.[23]  Such a system could not only be designed to avoid a 51% attack, it is more efficient to operate and would not require the massive use of electricity currently required by most PoW models.

Another efficient method of achieving separation of duties is to assign designated agents to validate all blocks.  Further separation can be attained by designating agents who have no personal stake in the activity on the blockchain.  Such a system may lack decentralization of governance.  It might require a centralized administrator to hire the independent agents.  A blockchain administrator may hire three different companies to provide this service to provide separation of duties.  Each company may be required to post a bond to insure their integrity.  Their contracts would be recompeted periodically to incentivize them to act honestly to be consider for follow-on work.  By selecting validating agents from firms that would face significant reputational damage if their agents were discovered to be falsifying records, agents would have an additional incentive to act honorably.  An additional layer of separation could be added through the hiring of an independent auditor to periodically audit both the data and the procedures used by the validators.  Wouldn’t such a centralized governance system be trustworthy?

Decentralization for Availability

By distributing the information stored in a blockchain across multiple independent nodes, blockchain systems avoid the architectural vulnerability of having a single point of failure.  But mass distribution is not necessary to achieve a security control to avoid a single point of failure.  Many enterprises today have large databases the contents of which are considered critical to their mission.  These systems utilize various off-the-shelf technologies to ensure both the availability and integrity of their data.  The security controls used include maintaining off-site archives and multiple copies of the data stored in geographically distributed locations (to avoid being brought down by a regional disaster such as a hurricane or war).  These are commonly used controls.  They are effective in removing a single point of failure without having to massively decentralize the database.  And their total cost of ownership is much lower than having hundreds of member nodes storing copies of the data.

A further benefit of using these industry best practices instead of publicly distributed copies of the data is that it affords better control of confidential data that may be stored on a blockchain.  If anyone can get a copy of blockchain data, adversaries may do so and apply advanced data analytics to blockchain metadata to decipher confidential data that may put people or jobs at risk.  Keeping copies of data distributed among known nodes operated by an independent administrator provides both failure and confidentiality protection.

Conclusion

There is widespread belief within the blockchain community that decentralization is a fundamental objective in blockchain applications.  Many blockchain advocates express this belief with great vehemence and even suggest that decentralization alone is a good reason to create blockchain applications.  This believer community often attacks developers of blockchain applications that do not adhere to their undefined notion of decentralization as a fundamental requirement of their solutions.  Yet, it is questionable that even pervasive applications such as Bitcoin – the mother of blockchain applications – actually achieve full decentralization.  Furthermore, a review of certain blockchain applications and business models suggests that decentralization is neither necessary nor sufficient to create the level of trust desired by the users of blockchain applications.

For further reading, I suggest the following:

1. Vili Lehdonvirta: “The blockchain paradox: Why distributed ledger technologies may do little to transform the economy”  https://www.oii.ox.ac.uk/blog/the-blockchain-paradox-why-distributed-ledger-technologies-may-do-little-to-transform-the-economy/
2. Andrew T:  “The Word ‘Blockchain’ is a ‘Semantic Wasteland’ that We Should Abandon”  https://bitcoinexchangeguide.com/the-word-blockchain-is-a-semantic-wasteland-that-we-should-abandon/

[1] Antonopoulos, Andreas M:  Cutting Through the Blockchain Hype, Distributed, issue #3.

[2] See for example:   Dixon, Chris: “Why Decentralization Matters”, Medium,  https://medium.com/@cdixon/why-decentralization-matters-5e3f79f7638e  and Antonopoulos, Andreas:  “Decentralization and the Architecture of Trust” https://www.reddit.com/r/Bitcoin/comments/7dyuon/decentralization_and_the_architecture_of_trust/ .

[3] See https://en.wikipedia.org/wiki/Vegetable

[4] A “node” is a computer that includes an executing version of the blockchain application and a current copy of its data.

[5] For an explanation of RAID 5, see https://searchstorage.techtarget.com/definition/RAID-5-redundant-array-of-independent-disks

[6] A “permissionless blockchain” is one in which any node can act as a validator.  No permission from some authority is necessary to become a validator.

[7] Wight, Michael:  “Maersk and IBM Struggling to Find Partners”  https://theblockchainland.com/2018/10/30/maersk-and-ibm-struggling-to-find-partners/

[8] Banker, Steve:  “Blockchain Gains Traction in the Food Supply Chain”  FORBES, 25 JUL, 2018, https://www.forbes.com/sites/stevebanker/2018/07/25/blockchain-gains-traction-in-the-food-supply-chain/#1d67b9201cf9

[9] See https://www.mediledger.com/solution-protocols

[10] See the IPFS white paper:  https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf

[11] Block validation is the process of reviewing and approving each new block of transactions to validate that they are both legitimate and accurate before the block is added to the blockchain.

[12] See the Bitcoin white paper:  https://bitcoin.org/bitcoin.pdf

[13] Proof of Work is the block validation technique used by Bitcoin and many other popular blockchains.  The PoW system requires nodes to compete to earn the reward for being selected to add the next block.  To compete, nodes are required to solve a complex mathematical problem.  The first node to solve it validates the block and adds it to the blockchain.  At least 51% of all competing nodes must concur with the validation of the “winner” before the block is added.

[14] Technically, an adversary needs 51% of the “hashing power” of the validating nodes.  Because some nodes are more powerful than others, this may end up being more of less than 51% of the actual number of nodes.

[15] For further discussion of a 51% attack, see https://www.investopedia.com/terms/1/51-attack.asp

[16] For a more detailed explanation of 51% attack vulnerabilities, see “51`% Attach” https://www.investopedia.com/terms/1/51-attack.asp

[17] Hertig, Alyssa:  “Blockchain’s Once-Feared 51% Attack Is Now Becoming Regular” Coindesk.com  08 JUN, 2018, https://www.coindesk.com/blockchains-feared-51-attack-now-becoming-regular/

[18] Proof of Stake (PoS) is an alternative block validation technique to PoW.  In PoS, any node seeking to obtain the reward for added the next block must post a bond (called a “stake”).  If they post an illegitimate block that fails to be supported by the other competing nodes, they lose their stake.  This provides an incentive for them to act ethically.

[19] Smith, Kieran:  “Crisis averted:  threatening bitcoin bug removed from client”, Brave New Coin, 24 SEP 2018, https://bravenewcoin.com/insights/crisis-averted-threatening-bitcoin-bug-removed-from-client?utm_source=BNC%20Newsletter&utm_campaign=e4c5159760-EMAIL_CAMPAIGN_2018_09_26_03_24&utm_medium=email&utm_term=0_83439a8472-e4c5159760-245193217

[20] See https://data.worldbank.org/indicator/CM.MKT.TRAD.CD?view=chart

[21] See https://www.statista.com/statistics/535277/volume-of-global-bond-trading/

[22] See Hearn, Mike:  “On Block Sizes” Medium, 02 NOV 2015, https://medium.com/@octskyward/on-block-sizes-e047bc9f830

[23] For more information on DPOS, see Larimer, Dan: “DPOS Consensus Algorithm – The Missing White Paper” https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper

By Jeff Stollman

Blockchain technology appears to be ideally suited as an underlying technology for a wide variety of software tools to improve operations within a supply chain. While this novel technology presents wide-ranging opportunities to improve supply chains in almost every industry, it poses a serious threat to the 3PLs who stand in the middle of most supply chains. The threat to 3PLs is not the disintermediation that is a source of concern to “middlemen” in many industries. Rather, it arises from the instantiation of dozens of unique supply-chain solutions and the resources required to 3PLs to support them.

The Promise of Blockchain for the Supply Chain

Blockchain technology facilitates the creation of an immutable transaction log. Such a log provides a number of innovative solutions applicable to the supply chain. Because of all the potential benefits that blockchain technology can provide, a multitude of firms have initiated widespread development of blockchain solutions for various industry supply chains to enhance visibility and to reduce the time and cost of moving both finished goods and their components through the supply chain.

Chain of custody

One of the most important functions provided by the blockchain is the creation of an immutable transaction log. If the transactions being recorded document transfer of custody (or ownership), this results in the creation of an immutable chain-of-custody log. Such a log is ideal for identifying the source and dispersion of goods including currency, commercial products, artwork, and even legal evidence. Such a log supports the identification of the source of authentic, counterfeit, and gray-market goods. If we record all transactions in the widget industry and find that distributor A has purchased 50 authentic widgets from their manufacturer and later sells 51 widgets to retailer B, where did this 51st unit come from? Absent a “loaves and fishes” miracle, there is reason to be suspicious of the distributor, or its sources. The problem may be as simple as an administrative error. But a blockchain application can be programmed to alert users (including regulators) when such suspicious events occur, prompting further investigation to definitively resolve what happened. For unique one-of-a-kind products (including serialized products), the blockchain’s immutability further provides a reliable source of truth, identifying the provenance of each individual package. It can identify not only products with inauthentic serial numbers, but also products that duplicate legitimate serial numbers.

Component Integrity

Similar to the tracking a final product as it moves downstream from maker to consumer, a blockchain transaction log can also track upstream transactions of components and ingredients to ensure that each of the components within a system meets the specifications of the manufacturer. It can also be used to verify that the sources of such components use fair labor practices, and comply with health, safety, and environmental laws. This allows producers of brand-name products to avoid both the legal and reputational risks that can arise from sourcing products from less vigilant or unscrupulous suppliers.

Trade finance

Trade finance is another area where blockchain has the potential to save time, disintermediate certain “middle-man” functions, and save money. By placing various trade information on an immutable blockchain, the data can be accessed by appropriate parties to verify the existence, ownership, and the provenance of goods without requiring mountains of paperwork by intermediate inspectors, customs agents, etc. As a result, products move through customs barriers rapidly, reducing the time payments for products are held in suspense. The faster processing enabled by the blockchain may even preclude the need for obtaining intermediate trade financing for products in transit.

Government processes

Governments are notorious for requiring massive amounts of paperwork in various serial processes where customers or constituents have to go from agency to agency and re-prove some fact (e.g., a person’s identity or authorization; or the national provenance of an imported good), accumulating various sign-offs to complete certain transactions – especially in international trade. If these facts were logged on an immutable blockchain record, the facts could easily be reviewed and accessed by each authorizing agency concurrently and the effort and time invested in dealing with such bureaucracy could be reduced.

The Threat of Blockchain to Third-party Logistics Firms (3PLs)

Blockchain is a nascent technology. But it has already been recognized as having wide-ranging applications to various industry supply chains. Many technologists are devising unique infrastructure, tools, and processes to support blockchain’s range of applications. Developers include traditional information-technology firms, startups, and firms who depend on the supply chain to bring their products to market, as well as 3PLs, themselves. As a result, in the early stages of blockchain solution development, a plethora of unique solutions are being brought to market. For example,

• — Everledger has developed a system for tracking the chain-of-custody of diamonds
• — Peer Ledger is developing a system for tracking the chain-of-custody of refined minerals
• — RMTM is developing a system for tracking the chain-of-custody of pharmaceuticals
• — Maersk is developing a system for tracking and expediting marine shipping paperwork
• — IBM is developing a system for tracking the chain-of-custody of food products
• — Seven European banks are collaborating to develop a novel trade-finance platform.

The number and variety of solutions threatens the efficiency of 3PLs. These various systems are being developed independently and have no inherent interoperability. As conveyers of almost all products on the market, 3PLs sit in the middle of most of these solutions. If the handbag industry devises its solution, the shoe industry develops another solution, the pharmaceutical industry comes up with its own solution, and yet other solutions are used to address import/export paperwork and trade finance, 3PLs may find themselves obliged to support multiple diverse supply-chain solutions – each of which has its own procedures and interfaces. The chain-of-custody solution is also much more complex for 3PLs than for their clients. Shippers frequently need only record receipt of a package and then its ongoing shipment. 3PLs, on the other hand, have to track pickup, receipt at a local distribution center, multiple transfers to other vehicles and distribution centers, and eventual drop off at a destination. Many 3PLs already have their own systems for internal tracking and transparency while goods are in their hands. These systems go a long way toward providing transparency in the chain-of-custody within the 3PL’s environment. But these systems are just another standalone system that will need to be integrated into larger supply-chain systems. And this integration may be non-trivial. Most current 3PL tracking systems rely on an identity label generated by the 3PL itself upon receipt of a package. This label is not correlated to the contents of the package. The 3PL can report that package/pallet ‘12345’ is at distribution center 32, but it cannot tell the shipper which of six packages/pallets destined for the same customer ‘12345’ is. Is it the one containing the emergency medicines or the one containing cough drops? In addition, some industry blockchain solutions may require information above and beyond what is currently tracked in the 3PL’s own system, such as verification of manufacturer-generated serial numbers whose format can vary from industry to industry, and, sometimes, from firm to firm. Supporting the volume and variety of these new systems will be costly to 3PLs. For all the benefits that will accrue to shippers, these systems will create new inefficiencies for the 3PLs that serve them. 3PL firms may need to develop expertise in each system and have these experts available throughout the firm’s network on a 24×7 basis to support multiple shipper-designed solutions. Because a single truck or container load may include products from a wide variety of industries, it may be impossible to concentrate this expertise efficiently. Accordingly, each distribution center may need to have expertise to support each of the systems required by the 3PL’s diverse clientele. In fact, these skills may be necessary at the driver level to effectively verify receipt of packages at both pickup and drop-off. How to Address the Threat 3PLs need to be proactive, and recognize that this future disruption also represents a rare opportunity for forward-thinking companies. By taking action now, a 3PL can become a transformation leader of the next iteration of logistics. It can use this impending crisis to expand market share in the transition to Logistics 4.0. To become a leader in the next major transformation of the logistics field, RMTM believes that innovative firms need to become recognized experts in the new technology and drive the transformation. This process requires the following four steps:

1. Develop the skills

The first step to becoming a leader in Logistics 4.0 is to develop the skills necessary to support the transformation. Firms will need to gain an understanding and expertise in blockchain technology. As observed by Greg Aimi, Gartner’s director of supply chain research, “Today, global operational transparency requirements and digital business drivers from their shipper customers are just going to increase the need for 3PLs to be top dogs when it comes to tech and innovation.”

A small-scale pilot should be developed. The experience of building a working model will allow participants to delve into the details of the technology in order to gain a comprehensive understanding of the power and flexibility of blockchain technology and what it can and cannot accomplish. Furthermore, the experience will highlight most of the hurdles that will need to be overcome – both technically and politically — to develop a comprehensive solution.

One way to jump-start this effort and to reduce a firm’s investment is to form strategic partnerships with blockchain providers. But such partners must be selected carefully. Many current blockchain developers are hammers looking for nails. They view the world through a single porthole and lack the broader vision of leveraging blockchain technology in the various contexts with which it will interact.

It is not necessary at this stage to develop THE solution that will ultimately carry the industry into the next level of logistics. But just working with the technology will allow firms to begin to develop the rare skills needed to work with blockchain solutions – whether internally or externally developed. Because these skills are likely to be in short supply, fostering in-house capabilities will prepare 3PLs to cope with this new process paradigm.

2. Understand the tools

Blockchain technology today has a wide range of shortcomings. But this is true for most nascent technologies. No one today is using Java 1.0. No one today is using SSL 1.0. Technology evolves. Technologists identify shortcomings and develop solutions to fill the gaps.

Not all gaps will be filled. This is not unique to blockchain solutions. We still don’t have a good system for high-assurance digital authentication more than two decades after the deployment of Public Key Infrastructure (PKI) and more than a decade after the development of Security Assertion Markup Language (SAML).

Currently, a plethora of new blockchains are being implemented. The original Bitcoin blockchain remains healthy and proven, but newer blockchains such as Ethereum and Hyperledger offer new benefits a variety of additional benefits. But beyond the blockchain core, additional tools are being devised that offer enhanced confidentiality and improved querying. And as the vision of the future of logistics evolves, it will become clear that certain new tools will also need to be developed.

Leading logistics firms will be involved in the development of tools to fill these gaps, further building up their intellectual capital and establishing thought leadership. Additionally, it is vital that 3PLs know what tools are being developed by others that can immediately fill remaining gaps, without the costs and risks of internal development.

3. Formulate the vision

Once basic blockchain skills have been developed, and an understanding of the wide range of tools available and under development, firms should be watching developments in the field from the myriad startups and pilots being conducted by others. These will lead to the evolution of a vision that could become the unifying vision for the logistics community.

4. Foster Collaboration

Collaboration is the key to success in the supply chain. Leveraging the thought leadership gained from internal explorations of the technology, firms need to drive collaboration with customers and selective competitors alike. Even the best solution will be unsuccessful without widespread support from the rest of the industry. And enough competitors will need to support the effort for it to carry through and become an industry standard. The intellectual capital already developed will help the firm maintain its leadership in this collaboration.

As Gartner’s Ami points out, the next generation of logistics “mandates a transition in the roles and responsibilities of tomorrow’s logistics professional from being a master of logistics execution to a master of provider orchestration; and it puts an importance on the relationship between customer and 3PL.”

About the Author

Jeff Stollman, principal consultant at RMTM, is a technology futurist who reviews new technologies with particular emphasis on separating the reality from the hype and forecasting the unintended consequences they present. He has been working with blockchain technology since January 2015 and has designed several blockchain applications to gain a deeper understanding of the technology’s promise and shortcomings.

By Jeff Stollman and Martin Mateev

Background

In 2013, the US Congress passed the Drug Supply Chain Security Act (DSCSA) . This act mandated that Food and Drug Administration (FDA) drive the pharmaceutical industry (manufacturers, re-packagers, distributors, and dispensers) to develop a capability to allow the FDA to gain visibility into the industry supply chain to reduce the amount of counterfeit, gray-market, and diluted products in the market. These products not only are responsible for detrimental impacts to the public health (including deaths), but also cost the legitimate drug industry billions of dollars in lost revenue annually.

While the industry fully supports the goals of DSCSA, Members are rightfully concerned that providing the FDA with the visibility to track products through the supply-chain risks exposing proprietary sales data that could have a significant impact on their competitiveness.

In order to comply with the US FDA regulatory mandate to provide supply-chain traceability 2023, the industry has been reviewing several solution approaches. This paper explores the pros and cons of each of these approaches.

Analysis

DSCSA requires that supply-chain Members record and provide Transaction Data for changes in ownership of pharmaceuticals covered by the Act. Transaction data includes the following:

1. “the proprietary or established name or names of the product;
2. “the strength and dosage form of the product;
3.  “the National Drug Code (NDC) number of the product;
4.  “the container size;
5.  “the number of containers;
6.  “the lot number of the product;
7.  “the date of the transaction;
8.  “the date of the shipment, if more than 24 hours after the date of the transaction; “the business name and address of the person from whom ownership is being transferred; and “the business name and address of the person to whom ownership is being transferred.” The Act does not require Dispensers to track their sales to end customers. This shortcoming means that once products are manufactured and introduced into the supply chain, a solution that only meets the minimal requirements of the law will limit the ability to remove (“de-commission”) packages from the record once they are disseminated to end customers.  This loophole allows a Dispenser to sell the same package multiple times to end consumers.  Because the sale to end customers is not recorded, there is no way to detect these multiple sales that use the same package ID.  This enables the introduction of counterfeit, gray market, and/or diluted product into the market in this last step in the supply chain.

By combining the Transaction Data for a particular drug package (or group of packages), the FDA gains visibility to the entire path the package has taken through the supply chain. When a suspicious package is identified (e.g., a dispensed drug that fails to offer expected relief is determined to be counterfeit or diluted), the FDA can use this Transaction Data to look upstream to determine where the package entered the supply chain.  This provides investigators with a starting point to determine the source of the Suspicious Product.

Similarly, when a drug recall is required, the Transaction Data allows for discovering of the downstream path or a batch of products to rapidly and efficiently inform targeted downstream supply-chain Members of the recall.

Providing this information is straightforward. Providing this information while maintaining the confidentiality of proprietary sales data creates a more difficult problem.

Three general approaches to solving this problem are currently under consideration:

1.  Single, centralized SQL database
2.  Separate databases for each supply-chain Member
3.  Centralized, disseminated, encrypted, blockchain database.

Each of these is discussed separately below.

1. Single, centralized SQL database

If the only mission were providing visibility to the upstream and downstream paths a package takes from manufacture to dispensing, having supply-chain Members merely contribute transaction data to a centralized database is an easy solution. The FDA could create a portal and prescribe a format for supply-chain Members to submit their data and the resulting database would be simple and cost-effective. The FDA could query this database, as needed, to track and trace any package (or group of packages both upstream and downstream and meet all of the objectives of DSCSA

But, while creating a single, centralized [SQL] database is the most simple solution, supply-chain Members fear that such a database would put the confidentiality of the proprietary sales data in jeopardy. Some of the most secured Government databases have been breached by adversaries ranging from political hackers to organized crime.  Outsiders accessing the database could not only expose the data and/or threaten to disclose it for ransom, changing the competitive dynamics of the market, but once breached, adversaries could alter the data, masking suspicious transactions by providing a false upstream supply chain.  Such a loss of data integrity would complicate any forensic investigation to detect the source of Suspicious Packages and extend the time that the public may be exposed to health risk

The industry has insufficient faith in the ability of the Government to keep such a database secure from such breaches. And this lack of faith is not unique to ownership of the data by the Government.  The industry’s reticence would not be changed were the database to be maintained by a commercial enterprise.

Because the industry is unlikely to ever be willing to risk exposing this vital competitive information, this solution is unlikely to ever be implemented.

2. Separate databases for each supply-chain Member

In order to provide supply-chain Members with the confidence that their proprietary data will not be exposed, they have offered a decentralized “breadcrumb” solution. In this solution, each company maintains its own Transaction Data.  As such, each company would record both its transactions with its immediate upstream suppliers and downstream customers.  And they would keep their data in their own databases under their own security.  They already do this today, since most of the Transaction Data is stored in the companies’ ERP systems. We call this approach the “breadcrumb” model because, like a trail of breadcrumbs, it requires the FDA to proceed serial from one Member database to another in order to cobble together the complete path that a product of interest has taken.

In order to implement this solution, an extract from the ERP system would be placed in a company portal. The portal would be set up to allow the FDA to access the data.  In order to track a package on its trip throughout the supply chain, the FDA would start by reviewing the manufacturer’s database which would identity the Distributor(s) to which the package(s) was sold.  They would then go to the Distributor’s database in order to determine which Dispenser(s) received the package.  Potentially, there could be other steps in the chain and the FDA would have to serially interrogate each system to determine how the packages were disseminated through the supply chain.  Similarly, packages could be tracked upstream in this same serial fashion to track its provenance

While this solution is viable in concept, as a practical matter, it is extremely complex. And this complexity will result in the loss of valuable time when the public health is at stake

This complexity manifests itself in several ways. First, having separate databases for each transaction puts data integrity at risk.  If Manufacturer A’s database claims that it sold 50 packages to Distributor B and Distributor B’s database documents that it received 100 packages, there is no implicit reconciliation.  The disparity will not be recognized until an investigation, triggered by an external event.  And by the time this external event occurs, there may be a significant public health crisis pressuring the FDA to rapidly reconcile this transaction (which may, by now, be weeks, months, or years old), but the investigation will take time.

Second, there is the database problem. With thousands of Members of the supply chain, there would be thousands of databases to interrogate for widely disseminated products.  Even if the schema for the database was standardized across the industry, it is unlikely that all would use the same underlying database product (e.g., Oracle version 11 or version 12c, IBM DB2, Microsoft SQL Server, etc.).  This could result in compelling the FDA to create multiple queries to interrogate each of the different databases.  Mandating a specific database product imposes the requirement on each Member to purchase the database and maintain skills to administer the database.  And the thousands of Members may have different maintenance schedules.  After interrogating Manufacturer A’s database to learn that a particular package was sold to Distributor B, the FDA might discover that Distributor B’s database is unavailable because of either routine or emergency maintenance.

Third, each firm will have to maintain its own Identity and Access Management (IAM) system to authenticate and authorize FDA agents seeking to access their database.  This not only presents a similar problem as the brand and intricacies of negotiating each unique IAM system, it imposes a burden on each Member to maintain and support such a system.

Fourth, there is the customer support requirements of maintaining such a system for access by the FDA. Will smaller firms have to establish a 24×7 help desk to support emergency ad hoc queries of their database when a toxin has been discovered  in a product that they may have innocently sold that has resulted a public health panic?

The FDA currently opposes this solution approach.

3. Centralized, disseminated, encrypted, blockchain database.

A centralized, disseminated, encrypted, blockchain solution has the potential to reconcile the confidentiality shortcomings of the single, centralized SQL database and the practical limitations of the “breadcrumb” model.

The database is centralized meaning that all transactions are recorded in it. But it is also disseminated meaning that the entire database can be distributed globally to provide higher levels of security.  It is not necessary that supply-chain members each maintain a copy of the database in order to interact with the system.  And, in fact, the proposed solution is structured so that no member maintains a copy of the database

This approach creates a centralized database similar to the first approach, but uses a new technology called blockchain to overcome the limitations of the standard, SQL-type database.

Many who recognize the term “blockchain” know that it is the technology that underlies Bitcoin. But Bitcoin is only one implementation of blockchain technology.  And this robust technology supports a robust variety of alternative implementations.

In the currently envisioned approach tailored explicitly to address the requirements and concerns of the pharmaceutical industry, blockchain technology offers the following capabilities:

It uses a unique and robust encryption technology that has not been broken in over a decade while protecting the alluring $8 billion of value in the Bitcoin ecosystem. This encryption masks the identities of the parties involved in each transaction.
It includes integrity checks that verify concurrence of both the seller and the buyer before Transaction Data is added to the database.  Records are reconciled before they are entered, removing this issue from consideration.
It is highly tamper resistant. The encryption used protects the integrity of the data, not merely its confidentiality. Additionally, the database is replicated in multiple environments and uses a consensus mechanism to resolve conflicts. If an adversary does find a way to hack and alter one version of the database, this “outlier” will be thrown out because it will be outvoted by the other versions that consistently present the true version.
Besides the level of confidentiality created by encryption of certain data (e.g., buyer and seller names are hashed), the solution architecture isolates the database from direct access. The database is inaccessible to both supply-chain Members and Regulators/Law Enforcement. The contents of the database can only be interrogated using pre-defined reports. And rules for requesting these reports impose further access requirements. Supply-chain Members are restricted to request information only about transactions to which they are a party. (And they should already have this information in their internal ERP systems, limiting their need to request such reports. ) The FDA will have the rights to submit report requests for any transaction or group of transactions. But even they do not have direct access to the underlying database. They can only request reports previously agreed to by FDA and the industry. And access rules can also limit who at FDA is authorized to request which report. In this way, disgruntled employees or “entrepreneurial” employees looking to resell information will be limited to how much they can accumulate.
By continuously tracking all inventory throughout the supply chain, the system facilitates the immediate dissemination of product recall notices to all inventory holders without having to disclose the names of these parties to the manufacturer.
Similarly, the system has the ability to automatically alert all inventory holders when a particular batch of product is approaching (or has reached) expiration.
Summary

Solving the track-and-trace problem to comply with DSCSA is a non-trivial problem. And the impacts of exposing supply-chain Member confidential competitive data (in approach 1) or delayed FDA response to a public health crisis (in approach 2) are substantial.  The “blockchain” solution (approach 3) has yet to be proven, but holds the promise of a solution that will significantly reduce the likelihood of both types of exposure.  It warrants further investigation and potentially, an industry pilot.