In today’s financial system multiple institutions provide and maintain systems with overlapping functionality. These systems are regularly in conflict, and require slow, expensive and difficult reconciliation. As Richard Gendal Brown explains in his article entitled How to explain the value of replicated, shared ledgers from first principles:
“[T]he banks themselves have to spend a lot of time and money developing systems that […] spend even more time and money checking with each other to make sure their systems agree on common facts.”
The two primary reasons that these institutions each have their own systems in the first place, instead of a shared system, is to avoid both a single point of failure, and a single point of control. Each institution, or division within an institution, replicates the efforts of other parties to store the state of their clients’ and customers’ accounts. Again, from Richard Gendal Brown:
So we have two interesting phenomena: deposit-makers have to trust their banks to be good for the money and to account for things correctly. And the banks themselves have to spend a lot of time and money developing systems that all do pretty much the same thing – and then spend even more time and money checking with each other to make sure their systems agree on common facts.
Each ledger imperfectly replicates the functionality of others. However, the naive solution of centralizing the functionality, and avoiding this replication, reintroduces the single point of failure and the single point of control. The solution is duplication without replication. That is, the data is copied (for redundancy), but the process of copying is not directional. There is no master database which is merely backed up (i.e. replicated); rather, the network is decentralized.
Duplication without replication, however, requires decentralized consensus, in which there is no server/client (master/slave) relationship between ledgers, but in which each copy of the ledger is a node in a peer-to-peer system. This consensus system is called trust-minimized (or alternatively, “trustless”), because it lacks a single point of control. It is also more robust and resilient than a traditional system, because it is multi-polar and readily scaled.
The authorization and authentication protocols of a decentralized system are fundamentally different from those of a traditional database system, in which there is a gatekeeper party that alone acts on behalf of clients to modify the system state. In a distributed ledger, any party on the network, by contrast, can publish data to the ledger (instant sharing of data), but the effects of those data are limited by the rules of the protocol. Authorization, rather than being a function that is added onto the system at the end, is built in to the lowest level of the stack.
