As concepts go, the idea of “decentralization” is not only core to the blockchain ethos and culture, it describes a principle of secure computing that’s highly disruptive to today’s widely prevalent status quo of centralized architectures.

The best way to understand the main benefit of decentralized computing architectures is to reflect on how our decades-long reliance on centralized systems has exposed their inherent weaknesses. The reason that a majority of the systems we use today are classified as centralized systems is for one or both of the following reasons. 

• Machine Centralization: The system (or network of integrated systems) is made available to its end-users as a central computing infrastructure. Such consolidated computing infrastructures can range from a single physical or virtual system (eg: a single web server) to a collection of systems that combine to deliver an integrated user experience. This category of “physical” centralization includes those systems that are hosted as virtual machines with the major infrastructure-as-a-service (IaaS) cloud providers.
• Operational Centralization: Each of the involved systems is ultimately operated and governed by a single controlling party or group of parties. 

The grand majority of internet users encounter both forms of centralized systems on a daily basis. In some cases, the centralized nature of the systems they’re working with is a hybrid; both machine and operational. When a virtual machine is hosted in one of the various IaaS clouds, the machine and the IaaS provider represent centralized points through which some or all aspects of the system(s) can be controlled. For example, both the operator of the machine itself and the provider of the IaaS cloud have a significant amount of centralized influence over the system’s end-user outcomes.

One of the key benefits of centralized systems is that, as IT professionals often put it, there’s a single throat to choke when something goes wrong. When a central stock market trading authority perceives automated stock trading to be spiraling out of control, it can use the equivalent of a system kill switch to halt the trading for one, some or all stocks. For end-users of most centralized systems (ecommerce sites, social media, entertainment, etc.), it’s a major comfort to know that a central entity (eg: a person, IT department, automated process, etc.) will assist with the recovery process in the event that their credentials such as user IDs and passwords are lost or in need of a reset. 

However, along with the benefits of centralized computing come some downsides. When a system’s operation is under the control of a central entity, that party or group of parties is typically afforded unilateral authority to operate the system in whatever manner it sees fit. Even if that way is unpopular with the end-users of those systems. For example, the operators of some of today’s largest social networks have established a well-known pattern of disabling end-user accounts whose behavior was mistakenly deemed to be in violation of certain community guidelines. The operators of these social networks are free to make unilateral decisions regardless of the impact or opinions of their end-users.

In his Sept 10, 2024 testimony to the US House of Representatives Subcommittee on Digital Assets, Financial Technology and Inclusion, Coin Center Director of Research Peter Van Valkenburgh alluded to a more insidious consequence of centralized systems; the sacrifice of privacy (invariably for the benefit of the operator of the centralized system).  

“The pattern is clear,” said Valkenburgh in that testimony. “Initially, we have privacy in our day-to-day affairs, but we have to be in person, as in a cash payment or a face-to-face conversation. Then technologies emerge that scale human action, but we lose privacy protections: a telephone call, a bank wire.” In other words, when we rely on centralized systems for communications, banking, and other day to day activities, the operators of those centralized systems typically cull as much information as they can from each interaction in order to form personal and business profiles that they later monetize or use to their benefit. 

Even worse is the access that government organizations could gain to those centralized personal and business profiles through subpoenas or other jurisdiction-specific means. In the course of building end-user profiles and profitable businesses, the operators of these centralized systems have already taken care of some of the most difficult heavy lifting for litigious or meddlesome government organizations. 

For example, according to StatCounter.com, Apple’s iOS accounted for 49% of mobile operating system usage in the United Kingdom in January 2025, amounting to a significant amount of operational centralization given Apple’s control over the smartphone and tablet OS market. Seeking to leverage that operational centralization, in February 2025, the UK Government “demanded to be able to access encrypted data stored by Apple users worldwide in its cloud service” according to the BBC. Although Apple’s web site says that it believes privacy to be “a fundamental human right,” there is still the possibility that Apple will acquiesce to the government request thereby subjecting the privacy of about half of UK mobile phone users to a single operating system update. 

But the most glaring downside of centralized computing – one that has historically and demonstrably been the achilles heel of centralized systems – is the extent to which they offer a central point of potential vulnerability – often referred to as a central “attack surface” – to malicious actors. In the case of a centralized machine, that could be a vulnerability in that machine’s hardware or software. In the case of operational centralization, it could involve a vulnerability in the organization that governs the system. For example, numerous breaches over the course of computing history have involved compromises to something other than the targeted system itself. For example, the theft of a system engineer’s credentials to an adjacent system. These attack surfaces represent single entry points through which a trove of secrets and other sensitive information can be harvested. 

In an exploit that involved 1 out of every 2 Americans, it came to light in January 2025 that the personal information of over 190 million people was exfiltrated during an attack on the systems operated by the UnitedHealth-owned tech company Change Healthcare. According to a timeline of the attack published by TechCrunch, the “hackers initially broke in using the stolen username and password of a ‘low-level customer support employee,’ which wasn’t protected with multi-factor authentication.” A legal filing by the State of Nebraska also accused “Change Healthcare of having poorly segmented IT systems, which allowed the hackers to travel freely between servers once inside the company’s firewall.”

The Bitcoin Breakthrough

To computer scientists, it probably comes as no surprise that the world of computing has evolved under a mainly centralized approach. For as long as there have been centralized systems, computer scientists have wrestled with the idea of democratizing that power; distributing it to a network of systems in a way that no single machine or operator can exercise control over the collective function or end-user outcomes. Nor would it represent a single point of potential compromise through which all of the system’s sensitive data could be maliciously exfiltrated.

But along with Bitcoin’s debut in 2009 came the introduction of the underlying blockchain technology (aka distributed ledger technology or DLT). It was not just a technological innovation that colloquially amounted to the first time anyone could “send and receive value to and from anyone in the world using nothing more than a computer and an internet connection…without the need to trust a middleman” in a way that is “available to anyone [regardless of their nationality, race, religion, gender, sex or creditworthiness] and not owned by any single entity” (as Van Valkenburgh phrased it in earlier testimony to the US Senate). It was a breakthrough for the computer science of distributed computing (especially given Bitcoin’s reliability over slow, unreliable networks) and brought with it a new zeitgeist of decentralized applications.

The reference model-cum-elevator pitch for blockchain was (then) and still is about the disintermediation of the centralized middlemen – banks, governments, and other interlocutors – that exercised an extraordinary amount of control over the world’s financial railways and stations. In contrast to traditional money and wire transfers, with Bitcoin, Alice can send money to Bob without the involvement of a single financial institution. Eventually, the groundswell of public distributed ledgers such as Algorand, Cardano, Hedera, and Ripple (all founding members of the DeRec Alliance)  inspired an entire category of innovation known as Decentralized Finance or DeFi, the most classic example of which are exchanges where cryptocurrencies are swapped for one another without the assistance, oversight, or risk associated with any central controlling party or machine.

Building on the nearly limitless potential of decentralization, the Decentralized Recovery (DeRec) Protocol is another real world example of how the benefits of decentralized architectures can overcome or complement the weaknesses in today’s largely centralized approaches to the management of end-user credentials and other important secrets. 

As promising as distributed ledger technology is, one of the greatest barriers to viral adoption is the fear that an end-user’s loss or misplacement of their blockchain account credentials will result in the irrecoverable forfeiture of any monies connected to that account. As demonstrated by some highly publicized losses, that fear is well-founded. One key disadvantage of decentralized public ledgers is that there’s no central help desk to contact when you find yourself locked out of your blockchain account. Given that 100 percent of end-users have at one time or another successfully used a lost-password routine to regain access to an online account, the idea that no such safety net exists for public blockchain accounts is particularly unnerving to both novice and experienced end-users.

As a result, blockchain experts are quick to offer prescriptive advice to blockchain account holders on how best to weave their own safety nets. Left to this advice and their own devices, end users will resort to anything from hiding the information under their mattresses to using password managers to consolidating their cryptocurrency holdings with centralized exchanges that, like banks, have a help desk but that also must be trusted as custodians of your money. Unfortunately, public blockchain users who trusted FTX to be that custodian learned the hard way about the risks that go with such centralized safety nets.

Alternatively, the DeRec Protocol is unique in the way it offers a standard, decentralized safety net with which any lost or misplaced credentials (or any secret) can be recovered without incurring the risks associated with centralized approaches or sloppy management of personal secrets. The DeRec Protocol is 100 percent agnostic in that it can work for any credential or secret regardless of that secret’s association with any specific entity or service (see What Types of Secrets Can Be Protected with the DeRec Protocol?).

How does it do this? For an in-depth explanation of how exactly the DeRec Protocol works, please read What is Decentralized Recovery? But, in a nutshell, instead of relying on a central entity to aid in the protection or recovery of a lost or misplaced secret, the DeRec Protocol first protects that secret by splitting it into dissimilar encrypted fragments known as “DeRec Shares” (see our FAQ: What is a DeRec Share?) and then distributing those shares across a group of unrelated systems known as DeRec Helpers (see our FAQ: What is a DeRec Helper?). The reason the fragments are referred to as “shares” is because the DeRec Protocol relies on another standard known as Shamir’s Secret Sharing (SSS). According to the Wikipedia, SSS is an “algorithm for distributing private information (the “secret”) among a group. The secret cannot be revealed unless a quorum of the group acts together to pool their knowledge. To achieve this, the secret is mathematically divided into parts (the “shares”) from which the secret can be reassembled only when a sufficient number of shares are combined.”

As opposed to a centralized system where a secret must be shared with some central party or service as a part of protecting that secret from loss, the group dynamic of the DeRec Protocol infers that it is a decentralized technology where the secret is never shared with a central entity. In fact, it is never shared in its entirety with any entity. Furthermore, with the DeRec Protocol, the DeRec Helpers to which the DeRec Shares are distributed have no knowledge of who the other Helpers are, how many Helpers exist, nor do they have any means to decrypt the Shares in their possession.  

Should a secret that’s been protected with the DeRec Protocol become lost or misplaced, the owner of the secret (see our FAQ: What is a DeRec Owner?) can recall the Shares from the Helpers and reassemble that secret from those fragments (after first decrypting them, which only the owner of the secret can do). 

There’s a lot more to how the protocol works. For example, Helper redundancy is baked into the protocol in a way that the recovery process won’t fail due to the unanticipated inaccessibility of a single Helper. Also, it’s important to note that protocol itself is not an application. It’s an open source technology that developers can freely build into their new or existing applications in a way that those applications can participate in DeRec workflows. For example, as an addition to its existing credential management feature set, a web service could offer its end users the ability to protect their credentials with the DeRec Protocol. Meanwhile, large service providers (eg: wireless carriers) could provide a helper-as-a-service feature in order to expand their lists of subscriber benefits (see our FAQ: What is a DeRec Helper-as-a-Service (dHaaS)?)

Most importantly, for decades, the art of protecting and recovering secrets has relied on a centralized concept known as “shared secrets”. As innovations go, not only does the DeRec Protocol demonstrate why it’s unnecessary to share secrets in order to protect them, it proves how the application of a decentralized architecture to a legacy use case can actually eliminate the longstanding weaknesses that were originally introduced through traditional centralized approaches.