I recently found myself intrigued by the question of how to deal with a failed or obsolete blockchain system. My starting point was the phrase “blockchain bankruptcy,” but I broadened my thinking from there. I ended up being concerned about the general problem of gracefully ending a blockchain system.

First, we might ask: why do we care? It turns out that there are people who are putting official records like birth certificates, marriage certificates, and college degrees on blockchains. Even if those blockchain systems are replaced or abandoned at some point in the future, that kind of information will still be of interest. And so we can usefully ask: for a generic blockchain system, what does it mean to end gracefully?

The idea of bringing a system to an end is so common that it can be hard to see why there’s an issue. Intuitively, it seems like it should be easy to have a stable, inexpensive version of the stored state. For example, if we’re running a conventional database, we simply stop processing transactions, read out the final state onto some kind of permanent storage, and we are all done. Why doesn’t the same basic approach work for a blockchain?

Pretty much everything about a blockchain is different from a conventional database, which rules out the simple approach. By design, there’s no single controller of the blockchain, and there’s no quick way to simply “stop processing changes.” There’s no magic entry we can write into the data to say that we’re all done now. Instead, the data at the end of a blockchain is written by a semi-cooperative, semi-competitive joint effort by a self-selected community.

One of the problems with a system that’s reaching the end of its life is that the community engaged with the system is probably getting smaller. That’s a challenge because the soundness of a blockchain system is related to the size of the community. The usual argument is that good players “outweigh” the bad players. A shrinking community means that it’s easier for bad players to affect the system’s operation.

In addition to the problem of a shrinking community, we have to be aware that many blockchain systems are designed to use an unstable consensus. In a system with an unstable consensus, we know that the last block of the chain as seen by a particular player is contingent – it’s possible that most of the community has chosen a different last block. In fact, it’s possible that every block known by that player is wrong. All we really know in a system with unstable consensus is that older blocks are more likely to be correct and newer blocks are less likely to be correct.

So when is it possible to walk away from a blockchain system? Honest players can safely abandon a blockchain using unstable consensus, as long as it contains no information of any continuing interest. However, if that blockchain contains any information that might need to be preserved, it can never be abandoned by the honest players. Leaving the blockchain alone allows it to be rewritten by dishonest players.

What can we do to manage or mitigate this kind of problem? Well, for the details of the possibilities, you can read the technical paper I wrote on the subject.

In most cases, for most blockchain systems, the shutdown problem is hard. There is no straightforward way to declare that a history is finished and archived. If you do not care enough about the integrity of the data to keep working at it (and potentially recruiting others to assist you) then your history will potentially be corrupted or vanish.

This is a rather surprising conclusion when we consider how blockchains have been touted for their merits as public record systems. Those positive assessments have been focused on the steady state of a blockchain’s normal operation. When we consider the whole life cycle of the system including its shutdown, a blockchain is likely to be a poor choice for any situation where the information is of long-term interest.