Distributed Ledgers: Shared control, not shared data

In the context of distributed ledgers, I have noticed that many commentators and consultants confuse shared control of data with the sharing of data itself. The difference is crucial, and this common simplification misses the most important aspect of distributed ledgers.

In this post I discuss three ideas:

1. Sharing of data vs shared control of data
2. Control of data by rules vs by power
3. Enforcement of rules by participants

1. Sharing of data vs shared control of data

We know how to share data

• “This is a great use case for blockchain [sic] because we can share the data.”
• “Many parties need to access the data in real-time, so we are going to use blockchain [sic]”

No! Well, not really! We know how to share data: we’ve been doing it for ages. We do it through GUIs (screens) when people want to read data with their eyes, or APIs (data pipes) if other systems need to access the data. We control access to data, and privileges (read/write/edit/delete) using authentication, eg usernames and passwords.

Shared data: We know how to do that.

Shared control is a new concept

Distributed ledger technology isn’t about sharing data, it’s about the shared control of data.

Specifically, I don’t mean control over reading the data; but about who can change and add to the data, and how they have authority to do it. As Richard Brown notes in his excellent blog:

“Distributed ledgers – or decentralised databases – are systems that enable parties who don’t fully trust each other to form and maintain consensus about the existence, status and evolution of a set of shared facts”

2. Control of data by rules vs by power

Single entities use power to control data

Before distributed ledgers, data was controlled by single entities: She who controls the computer can edit the data. These entities can make changes to the data they hold by asserting their power over the hardware and software. There may also be legal and contractual terms binding the entity to behave in a certain way to its users.

Facebook is a good example: I upload a picture to Facebook’s computers, and tell Facebook which friends should be able to see it, and I expect Facebook to do roughly what I think it will do. Ultimately though, and ignoring some legal and ethical aspects, Facebook controls my data and can unilaterally evolve it (add to it, delete it, modify it) and I am unable to do anything about it. Of course, I feel that I have control, but ultimately it is still Facebook who owns and controls my data.

In the financial world, a stock exchange is a good example: A buyer and a seller can agree to trade and request the stock exchange to log it, but it is up to the stock exchange what it ultimately does, both from a technical and for a contractual and legal point of view. Technically, the stock exchange can do whatever it wants with the data.  Legally, the stock exchange can unilaterally alter the trade details after the fact – this is called “breaking a trade” and happens more often that you might think, but usually for good reasons.

With distributed ledgers, control is by rules (a constitution?)

Conversely, with distributed ledgers, there is a set of rules that specifies what new information is considered valid or not, and how participants should react to it. This set of rules could be thought of as a constitution.

Sometimes called the blockchain rules, network rules, or the rules of the ledger, these are pre-agreed technical rules about how new data is handled. Participants are subject to this constitution of rules when they create or join a distributed ledger network.

Of course technically, participants are free to ignore the rules and create or propagate invalid data, but the other participants in the network will not accept invalid data if they are playing by the rulebook.

For example in bitcoin, one rule is the limit to the amount of data in one block of transactions. Another is the rule to submit a hash with a specific pattern, in order to create a valid block. A third is you can’t spend a bitcoin that you don’t have.

In a private distributed ledger network, one rule could be that no transaction is valid unless a minimum of three participants approve it with their digital signatures; or for a certain asset one specific party needs to sign every transaction (for example, a central bank signing every cash transaction). A participant in a private network may also have legal contractual commitments to the other participants, such as service level agreements.

The key point is that the evolution of data in a distributed ledger network is that at a technical level, there are rules about how data is handled. Before distributed ledgers, single entities had total control over their data, and commitments were made only at the legal contractual / terms-of-service level.

Distributed Ledgers control data evolution at a technical level

3. Enforcement of constitution by participants

Participants individually validate data according to their copy of the constitution

Distributed ledgers including blockchains create agreements between untrusting participants. Because no participant can fully trust that others are following the same rules, each participant must individually validate each new piece of information they receive, and check if it abides by the rules – ie that it is constitutional. If it’s valid, they accept it, and perhaps propagate it to others, else they reject it.

In this way the participants act as a committee that enforces the constitution of the network. The innovation is that the committee controls what happens to the data: there is no “higher power” who can unilaterally evolve the data.

In the bitcoin network, participants are not obliged to identify themselves or agree to provide a level of service, so if one party does behave badly there is no legal recourse. So bitcoin is sometimes described as an anarchic network. Each bitcoin network participant needs to validate all bitcoin transactions themselves.

In a private distributed ledger network, often the participants are self-identified known businesses, and they may want to agree to some contractual terms before participating. So there is legal recourse possible if a participant goes rogue and tries to disrupt the network. Even so, no business will 100% trust another business, so they still individually validate and approve new data.

New information is deemed valid only if relevant participants agree

This is known as “consensus”. Depending on how the network is set up, some or all participants need to agree on the validity of new data before it becomes part of the consensus-agreed ledger.

In bitcoin, currently there are about 5,000 participants (nodes) that store a full copy of the bitcoin blockchain and validate and propagate new transactions and blocks. A majority need to agree on the state of the blockchain before there is general comfort that a change has happened. If one participant disagrees, well, either everyone else has got it wrong, or he’s not reading his constitution correctly, or he’s missing something. At this point he has one view of the world, whereas the other nodes have a different view. This is called a fork.

In some private distributed ledgers, a smaller subset of participants could be sufficient for consensus, such as two parties to a trade, and perhaps a notary. There isn’t always a need for the entire ledger to be agreed upon by all participants, and consensus could be at the level of the individual piece of data, such as a trade, rather than at the level of the whole network.

But individual participants can still lie to their users

Of course, there’s nothing to stop an individual participant from showing their users an altered version of their data, while simultaneously showing the unedited version to the other participants in the network.

You need to trust your participant

This means that consumers can only “trust the ledger” if they can access multiple participants to cross-validate – or become a participant themselves.

Conclusion

Data sharing is a solved problem and is a misleading distraction from the core innovation of distributed ledgers: shared control of data.

With a distributed ledger, data is controlled by a committee of participants following and enforcing a constitution of technical rules, rather than by a single participant who makes commitments via a Terms-of-Service legal contract.

Distributed ledgers can be useful if the evolution of data should be controlled by multiple parties instead of a single controlling entity.

Data governance in single-entity databases vs public blockchains vs private distributed ledger networks