Creating a network of networks, where multiple ledgers serve as anchors for credential definitions, has consequences for the overall system's ability to resist censorship. This post explores why.


SSI credentials are anchored on a distributed ledger. Sovrin Network is based on Hyperledger Indy. In Indy, the credential definition, a public DID, schema, and revocation registry are all stored on the ledger1.

On a purely technical level, because of how credential proofs and DID resolution works, it doesn't really matter which ledger these artifacts are anchored on since if I prove something to you from a credential I hold, then you can use the information in the credential proof to find its definition, schema, the DID of the issuer, and so on. Regardless of where the credential is anchored, the verifier can get everything they need to cryptographically determine the fidelity of the credential.

But, knowing whether to trust the issuer of the credential and the ledger the credential is anchored on is more difficult. This is a matter of provenance and is more about governance than the technical features of the protocols and software.

As a result, we can imagine a world where many ledgers serve as anchors for the credential definitions and the other artifacts necessary for credential exchange to be trusted. In Sovrin, this idea is called "Network of Networks" and it has many proponents. We might have questions about which of those ledgers to trust, but that's the subject of a different post and I think the answer lies in governance frameworks. The issue I want to address in this post is what is the impact of Network of Networks architecture on censorship resistance.


Censorship is the ability of one party to stop another from "speaking." I put that in quotes because I'm using the term "speak" in a very general sense. Speaking, on the Internet, is any activity which results in a packet being transmitted from one machine to another on someone's behalf. So, sending an email is speaking, but so is a simple ping, or even a ACK in a TCP three-way handshake.

In the world of credential exchange, you can censor issuers by restricting who can get a DID or write a credential definition. This is why supporting public writes is important. But you can also censor them by not allowing credential holders and verifiers to see the definitions they've written2.

I have found that when people talk about censorship resistance, the discussion often rests on the decentralized nature of distributed ledgers. This happens because decentralization offers good protection against some censoring activities, along with other benefits for adoption and incentives. For censorship, decentralization can remove intermediaries. In any system with intermediaries, the intermediary can censor anyone connecting through them.

A decentralized architecture reduces dependence on someone else to speak, and so is more resistant to censorship. Decentralization can also help with censorship by ensuring access to the ledger and that no single entity can disrupt the validation of new entries on the ledger. But decentralization alone isn't enough to create a network that resists censorship. Censorship resistance depends on how the decentralization is employed.

For an example of why this is so, let's talk for a minute about another feature that distributed ledgers are made to solve, the so-called double spend problem where a digital token is used more than once. Paradoxically, the way ledgers solve the double spend problem is to create a single ledger that everyone agrees on through eventual consistency. So, the users and validators on the ledger may be decentralized, but they are relying on a single, centralized artifact, the ledger.

A Network of Networks

I spoke of the network of networks model above. To understand that better, let's look at the Sovrin SSI Stack. This figure is modified from one's I've shared before in that layer one contains more than one DID directory (my name for the combination of a DID method and a DID repository like a ledger).

The Sovrin SSI Stack
The Sovrin SSI Stack (click to enlarge)

As I've said, the nature of DID resolution lets any agent at layer two resolve a DID, regardless of which DID Directory it is stored in. A Sovrin agent, based on Hyperledger Aries also uses the DID directory to discover credential definitions, schema, and revocation registries. Ideally, these DID directories are public utilities that are, at least, readable by anyone.

Anyone can use the open-source Indy code to create a fully functional DID directory. And people will, for reasons good and bad. As a consequence, there is not a single, shared ledger where credentials and public DIDs are anchored, but many.


If we filter this all through the lens of decentralization as an unalloyed good, then a network of networks seems like a wonderful idea. The logic is inescapable: more networks == more decentralization == more good. But a network of networks has consequences for censorship resistance that we may not like.

Suppose the country of Naruba decides that they need their own DID directory to feel comfortable that citizen's credentials are anchored in a ledger with validator nodes that are trusted entities inside the country. There's an element of trust here and different governments and organizations will have their own trust criteria.

Within a proper governance framework, Naruba's DID directory could be known to be trustworthy by other international players (a property I call "provenance"). Sovrin Foundation has plans to extend the Sovrin Governance Framework to support a network of networks model and provide the rules for establishing the provenance of DID directories functioning within the Sovrin ecosystem.

Now, imagine you're a business based in Naruba, anchoring credentials on the Naruba DID directory. Your credentials will be trusted within Naruba because the government has set up governance for the Naruba DID directory and told Narubians to trust it. Your credentials might be trusted outside of Naruba if the Naruba DID directory is operating within some governance framework that organizations outside Naruba trust. So far, so good.

The Emirate of Kunami and Naruba are not on friendly terms. In an effort to punish Narubian businesses and keep them from buying Kumani oil, the Emir declares that the Narubian DID directory is off limits and the country carefully blocks the nodes on the Narubian ledger so that it is not accessible from Kunami. As a result, Narubian oil refineries can no longer do business with Kumani oil suppliers. Because the entire world economy depends on SSI and verifiable credentials, this is devastating because there are no other mechanisms to validate the complex supply chain transactions.

Now imagine a different scenario where there's one, predominant ledger where credential definitions are anchored. In this world, when Kunami wants to block Narubian credentials, blocking access to the DID directory would also block credentials their own economy depends on. So, they're forced to try to attack credentials one-by-one. A single, trusted anchor for credential definitions protects everyone from censorship. If any actor can isolate their core credential definitions on a network that they control, they can censor other networks without too much impact on themselves. Large, mixed pools of credential definitions provide a sort of herd immunity for everyone against censorship.

Of course, you can't stop someone from standing up their own network and, in the case of a government, forcing their citizens to use it. But if businesses and agencies inside the country need to interact with others outside the country, they may need to anchor credentials off that nationalized ledger to do business and then they can't censor. So, whether or not the Kunami DID directory would facilitate censorship depends on whether or not the international community would recognize it as a trustworthy source. If others don't trust it, Kumani can't use it as a weapon.

Network of Networks Governance

Don't get me wrong. I understand the drive to create a DID directory controlled by a government or industry organization. And some of those reasons form the basis for gaining traction and getting the adoption necessary for SSI to become a dominant means of creating trustworthy connection on the Internet.

Consequently, Sovrin supports a Network of Networks model. Right now adoption is the most important thing. Over time, multiple DID directories will likely coalesce into a few large directories. In the meantime, shared governance and community activity will compensate for the danger of censorship that multiple DID directories can create.

What does that governance look like? In a Network of Networks world, censorship resistance depends on strong governance that champions and facilitates convergence and cooperation while tolerating independence and innovation. The ability to censor depends on a network's ability to ignore other networks in favor of themselves. Governance must be carefully designed so that cooperation and mutual support are incentivized. Governance may need to institute measures like staking and quadratic membership fees to discourage natural monopolies. Without strong measures people, organizations, and governments will at best lose confidence in the network and at worst be held hostage to it.

Care must be taken to ensure that no single network gets so large that others cannot ignore it, but it can ignore them. Alternatively, we have to ensure that that network is one that is governed by the SSI principles that are consistent with the mission of Identity for All. The Sovrin Governance Framework is a start, but there is much work to be done. The Governance Framework Working Group has begun early work on the governance structure of a network of networks. The conversation is not over, but has only just begun.


  1. For details, see What Goes on the Ledger (PDF)
  2. This can also impact credential holders, but the biggest way to censor credential holders is to control their wallet. That's the subject of a different, future post.

Photo Credit: Censorship from Bill Kerr (CC BY-SA 2.0)

Please leave comments using the sidebar.

Last modified: Tue May 12 09:07:14 2020.