People sometimes ask "Is Sovrin decentralized?" given that it relies on a permissioned ledger. Of course, the question is raised in an attempt to determine whether or not an identity system based on a permissioned ledger can make a legitimate claim that it's self-sovereign. But whether or not a specific system is decentralized is just shorthand for the real questions. To answer the legitimacy question, we have to examine the reasons for decentralization and whether or not the system in question adequately addresses those reasons.

This excellent article from Vitalik Buterin discusses the meaning of decentralization. Vitalik gives a great breakdown of different types of decentralization, listing architectural decentralization, political decentralization, and logical decentralization.

Of these, logically decentralized systems are the most rare. Bitcoin and other decentralized ledgers are, in fact, logically centralized. There's one ledger. But the architecture (no infrastructural central point of failure) and politics (no one controls them) of Bitcoin are decentralized. But of course, these aren't binary options. There's a spectrum.

For example, while it's true that Bitcoin miners aren't centrally controlled in some aspects (e.g. who can use them, who can verify transactions), there are points of control such as the code itself. No one person has control but many have a lot more than others. I'm not saying this to throw shade on Bitcoin. Rather, I'm making the point that not even Bitcoin is completely governed by technology. There's some balance between the business, technical, and legal agreements that make up any functioning decentralized system.

The more important question about decentralization is: does the level of decentralization serve the goals of the system. There are several good reasons for going to the effort of creating a decentralized system:

• Avoiding common mode failure—This is one of the most frequently stated reason for decentralization. An architecture built from many parts is less likely to fail if one of them fails. Of course, this assumes that the many components are put together combined in a way that makes this possible. And it also assumes that the failure isn't due to something they're all susceptible to (otherwise known as the monoculture problem).
• Resisting attacks—Attacking a decentralized system requires taking on many components in a coordinated manner. Lack of central control points makes attacking decentralized systems much more expensive.
• Avoiding collusion—Collusion is, as Vitalik puts it "coordination that we don’t like." When participants in the system conspire to cheat or gain an unfair advantage, we call it collusion.

So, rather than asking "Is Sovrin decentralized?", we might ask how the Sovrin network avoids common mode failure, resists attacks, and makes collusion difficult.

Is Sovrin Resilient to Common Mode Failures?

There are many kinds of common mode failures, but there are techniques we can use to avoid them. Sovrin is built on a distributed ledger that is readable and writable by nodes on the network. These nodes are operated by organizations of different types, industry affiliations, and size. They are spread out around the globe. Nodes are operated on different hardware, in different kinds of data centers, with different operating systems. There are no secret nodes. Everyone running a node is known. The code is open source.

There are several shortcomings currently: First, there is only one implementation. Second, most of the development is being done by one company. Both of these will be remedied over time as Sovrin becomes more self-sufficient.

Is Sovrin Resistant to Attacks?

Some attacks are mundane and can be handled using the same techniques as are used for common mode failures. One of the more sophisticated kinds of attacks that decentralized systems face are known byzantine faults. Sovrin is resilient to Byzantine failure because of the underlying consensus protocol of the ledger. Byzantine fault tolerance protects the network from coercion attacks and asymmetric information attacks.

Does Sovrin Resist Collusion?

One of the core principles of Sovrin is diffuse trust—the idea that no single node, person, or organization has to be trusted in order to trust Sovrin. Diffuse trust also ensures that many parties have to agree to take action. This shows up in the consensus protocols for the network as well as the decisions about what code to release. There are no purely technical solutions to collusion. Ultimately every decentralized system has some level of governance that backstops the technology to resist collusion. Transparency and diversity are tools that help systems resist collusion. As Vitalik says:

This third kind of decentralization, decentralization as undesired-coordination-avoidance, is thus perhaps the most difficult to achieve, and tradeoffs are unavoidable. Perhaps the best solution may be to rely heavily on the one group that is guaranteed to be fairly decentralized: the protocol’s users.

Sovrin Foundation's role is to support users. Sovrin Foundation is not an industry association for just this reason. We must be vigilant in making decisions that discourage collusion of all kinds.

Power and Self-Sovereignty

You might look at the preceding questions and think "Ok, I get that Sovrin uses decentralization to protect itself from failure, attack, and collusion. But I'm interested in decentralized systems that protect human freedom and autonomy." That's an important point that doesn't have to do with resilience so much as it does power.

One of the great advantages of blockchain-based systems is not just that they're architecturally decentralized for resilience, but politically decentralized for diffuse control. Bitcoin achieves this, for example, by allowing anyone to validate transactions on the network using a sophisticated proof of work algorithm to protect itself against Sybil attacks. We call these kinds of ledgers permissionless because anyone can read and write transactions on the ledger.

Sovrin supports broad participation through a combination of business process, technology, and legal agreement. Sovrin is "public" meaning anyone can initiate identity transactions that are validated using Sovrin's consensus algorithm. While validators on the Sovrin network are known (the definition of a permissioned ledger), they don't see inside the identity transactions and can't make judgments about which transactions to allow or disallow based on content. Validators who don't abide by the rules of the Sovrin network can be taken offline or replaced.

Sovrin does not have "identity providers" because anyone can be the source of their own identity. Sovrin's primary support for identity transactions uses something called a verifiable claim that works like a physical credential such as a driver's license of password. Sovrin's trust model for verifiable claims has four important and desirable properties that all underscore its support for autonomy:

1. Claims are decentralized and contextual—There is no central authority for all claims. Every party can be an issuer, an owner, and a verifier. The system can be adapted to any country, any industry, any community, any set of claims, or any set of trust relationships.
2. Verifiers do not need to contact issuers to perform verification—Claim verifiers (the people or organizations relying on a credential) don't have any technical, contractual, or commercial relationship with claim issuers (the people or organizations making the claim).
3. Verifiers make their own trust decisions about which credentials to accept—there's no central authority who determines what credentials are important or are used for what purpose.
4. Owners are free to choose which credentials to carry—People and organizations are in control of the claims made about them (just as they are with physical credentials) and determine what to share with whom.

All of this points to an incredible amount of autonomy and control by the people and organizations using Sovrin.

Perhaps the most important questions about Sovrin and decentralization is does it provide people and organizations with self-sovereignty. That's ultimately why the power question matters. Last October, I wrote in On Sovereignty:

Sovereignty is about relationships and boundaries. When we say a nation is sovereign, we mean that it can act as a peer to other sovereign states, not that it can do whatever it wants. Sovereignty defines a boundary, within which the sovereign has complete control and outside of which the sovereign relates to others within established rules and norms.

Self-sovereign identity describes the same situation. A self-sovereign identity system defines the things over which an entity (person or organization) has complete control along with the rules of engagement for its relations with other entities in the SIS system.

As the previous discussion makes clear, Sovrin not only defines those boundaries, but puts powerful choices in the hands of anyone using it about what personal information they share and how they share it. Sovrin is built from the ground up to use pairwise pseudonymous identifiers and support minimal disclosure as a means to protect sovereignty. This is an important point. While we often speak of privacy, we don't often link it to control. Privacy protects control and control protects privacy.

An Internet for Identity

Last August, I wrote about Sovrin being an Internet for identity. My point was that Sovrin is like the Internet is three important ways:

1. No one owns it.
2. Everyone can use it.
3. Anyone can improve it.

The Internet has shown tremendous resilience to attack while offering unprecedented access for everyone to publish and use information. Sovrin Foundation is working to make this same vision a reality for identity.

Some FAQs About Sovrin's Governance

The following questions and answers fill in some details that may be helpful in evaluating Sovrin as a decentralized identity system:

• Who decides who can use the Sovrin?—The Sovrin network is public. Anyone can use it.
• Who decides who can write to the ledger?—Sovrin is, currently, a permissioned ledger so that people can afford to create pairwise pseudonymous identifiers for every relationship they have. Consequently, Sovrin's ledger has a known set validator nodes who write transactions to the ledger and achieve consensus. Sovrin Foundation has legal agreements with the organizations who run validator nodes that control how they operate. The goal of Sovrin Foundation is to have stewards of different legal jurisdictions, industries, sizes, and structure to ensure broad representation and avoid monoculture.
• Who decides who can read from the ledger?—The Sovrin network architecture allows for observer nodes who can read, but not write, the ledger. The provisional Sovrin network does not have any observer nodes. Observer nodes will also be subject to the Sovrin Trust Framework.
• Who decides how code is updated?—The Sovrin Foundation has a Technical Governance Board (TGB) that makes decisions about what code validators and observers will run. The code is open sourced at the Hyperledger Indy project is the code that forms the basis of the Sovrin network, but validators run known builds that Sovrin Foundation's TGB authorizes.
• How is contention resolved?—Contention about transaction is resolved automatically by the code that validators run. Contention about code is first handled by the TGB with the Board of Trustees as the court of last resort. Ultimately validators could refuse to run code that makes certain changes that they disagree with. This could result in a fork of the ledger, as we've seen with other ledgers, but I think the formal structures embodied in the TGB and Board of Trustees make this less likely. The purpose of the Sovrin Trust Framework (PDF) is define how many of the most common points of contention are resolved or avoid them in the first place.

Photo Credit: Adler from Klappe (CC0)