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 101st 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.
| Blockchain | Architecturally
Decentralized? |
Decentralized
Data |
Procedurally
Decentralized* |
Politically Decentralized |
| Bitcoin | YES | NO | 3 | YES |
| Ethereum | YES | NO | 3 | YES |
| Bitcoin Cash | YES | NO | 2 | YES |
| EOS | YES | NO | 12 | NO |
| Litecoin | YES | NO | 3 | YES |
*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:
- 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/
- 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