A Distributed Lock Manager (DLM for short) is a service that arbitrates access to some shared resource.

DLMs are conceptually very similar to non-distributed lock managers from multi-threaded operating systems (except they are distributed of course). This is the component that grants access to files, devices, memory regions etc. Lock managers may be classified according to certain criteria:

• optimistic or pessimistic
• voluntary or preemptive.

In pessimistic scenario we assume that there are many more agents trying to access the resource than there are resources. We can be sure that almost always there will be a conflict, so the intention to grab the resource has to be announced before it is accessed. This is like the very familiar way of programming with locks. The obvious cost of this approach is the overhead of announcements.

Optimistic scenario assumes that agents are few and resources are plenty, so there is very little probability of conflict. Therefore the optimal implementation announces the use of a resource after it is grabbed. If two agents happened to take the same resource at once, some recovery procedure is invoked. The recovery procedure may be costly, but it is very rarely called. This is essentially transaction-based programming, rarely used in general-purpose programming languages but very common in databases.

Voluntary lock managers assume that each agent will quietly wait in queue and not try to use the resource it has not been granted access. Recently this style of programming emerged in the form of asynchronous routines known from Python and Javascript. An asynchronous routine is kind of like a thread, that means other coroutines may run in parallel, however the waiting points are exactly defined by the await keyword. Only one routine is accessing the system, all others are sleeping. If all routines are cooperating, the system may achieve high efficiency, however this assumption usually holds only within a single application.

Preemptive lock managers do not assume that agents cooperate. Instead, the agent violating the access right will be stopped from doing so, for instance by freezing it or by generating some error signal. Such actions generate overhead, moreover agents waste time waiting, however this approach is much better suited for heterogenous systems were intra-application cooperation can not be assumed. In computer systems preemption is usually enfoced by hardware.

What about blockchains?

Blockchain may be understood as a distributed database. To access it, some arbitration is needed.

In Bitcoin-like blockchains the whole of data is protected as a single resource. There may be only one writer, and that happens to be the winning miner. Conflict is almost unavoidable (in fact, Bitcoin is encouraging conflict between miners), yet surprisingly the implementation follows the optimistic pattern. Each miner writes some data with disregard of all others and appends it at the tip of the chain. Then, the priority is determined using Proof of Work. The fastest miner wins. Every other miner has then to download the winning block, which is equivalent of the recovery procedure.

Bitcoin assumes that every miner is selfish, so we can not hope for any cooperation. Since blockchain is distributed, no hardware or central server may be used to enforce restrictions, instead cryptographic techniques are used.

Can we do it better?

We can think of a different implementation of blockchain where the lock manager strategy is either pessimistic, or voluntary, or both.

In Bitcoin, a miner has to show its strength by solving the partial hash inversion puzzle. This takes up lots of electric power. What if miners did not invert hashes but simply declared that they are able to do so? A sample implementation may work as follows:

1. All miners taking part in the turn announce their hashing power.
2. One of them will likely declare the greatest number. If everybody is fine with that, the miner with the greatest number wins.
3. If not, another miner may challenge the pretender. The miners resort then to actual Proof of Work.

Since doing Proof of Work costs money, rational miners will try to avoid it, thus declaring a big number only when they believe they have a chance to defend it. Like in animal kingdom, threatening opponents with fight may be a better strategy than an actual fight.

The essence of this approach is that the willingness to commit a block is declared before it happens. So it is a pessimistic strategy, taking into account that there are other users of the blockchain.

Under normal circumstances other users adjust their actions and acknowledge the winner of the round. This is a voluntary cooperation strategy. If some miner violates it, a fork happens, which must be resolved using the standard Proof of Work. This reduces the efficiency of the blockchain, but it does not compromise security. Under normal circumstances all nodes cooperate and blockchain works fast, only when consensus violation happens (which costs the attacker electric power) the blockchain defaults to slower mode.

What next?

The clear analogies between blockchains and Distributed Lock Managers allow us to apply some optimizations. I expect more effort on that goal from different teams in the future.