Shared Ledger Technology and the snapshot problem

I’ve talked before about how user trust in service providers is still necessary for Shared Ledger Technology (SLT), but I think the question about trust in central third parties is harder to analyse.

By “central third party” I mean anyone who vouches for the overall safety and reliability of a payment system. Even coins and notes are vouched for: the State promises the note or coin is legal tender and will hold its value, and that’s why we use them. All payment systems need central institutions: reserve banks, clearing houses, self-regulators, card schemes and so on. Even if we don’t know they exist, they indirectly give us the confidence to use the system, because their existence means our bank or other service provider has confidence in the system. Until Bitcoin, central institutions were indispensable to payment networks.

The original Bitcoin paper is an elegant proof of a breakthrough idea: that cryptographic methods, including the proof of work consensus protocol, allow trust in such human institutions to be completely replaced by trust in the technology. We can all do our own thing, relying on nobody but our computers to vouch for the system. Bitcoin is a live experiment in the theorem

This is genuinely brilliant. And yet, it has a problem – the “snapshot” problem. By this I mean it controls random variability by designing for a specific point in time when all variables can be known, but makes no allowance for variability over time. And that, I think, is where the theorem falls down.

Central payments institutions exist principally to grapple with evolution and change. If everything was a steady state, the job would be largely set and forget. Let’s take an example from APCA’s own experience as a payments self-regulator. We keep the rule books and standards under which $20 billion or so of electronic payments pass between payment institutions and their customers every day. If nothing changes in the environment, this takes zero effort. The system is genuinely self-regulating in a classic mutual sense: each player knows its access to the system depends on playing by the rules, and so they nearly all do, nearly all of the time.

But what if the government changes the applicable law? What if a new player comes along who does not look like a traditional participant, so the rules and protocols don’t quite fit, but has a legitimate need to join the system? What if we need to improve the functionality so we can all serve users better? There are also “Black Swan” events that are unprecedented and anticipated by nobody – like a financial crash or the advent of a radically new technology. At APCA, we have a governance framework that enables network participants to consider the new information, have their say, and ultimately make a binding collective decision on what will change in the network. It is pretty much what we do.

More generally, I have never known a time when payments systems are not evolving, hopefully for the better, but at least to fix problems and deal with threats and issues.

I acknowledge the genius of SLT as a means of removing reliance on any central third party. The problem is it inherently assumes that we have attained nirvana – that having achieved Bitcoin, nothing will ever change. That, I am afraid, does not compute.

Next blog, I want to talk a little more about the implications of this, and suggest a future line of inquiry for SLT.

Coming Up:

Part 1: We need to talk about Bitcoin’s trust issues: the founding principle of Bitcoin and why trust is a bad thing
Part 2: Why Shared Ledger Technology won’t free us from human fallibility: does a shared ledger really remove trust from the equation?
Part 3: The ‘Snapshot Problem’: how does a shared ledger react to a changing environment?
Part 4: Conclusion: the irony of bitcoin and the future of shared ledger technology