Proof of Stake vs Proof of Work: The Case of Transaction Finality

Consensus mechanisms – or rather called security mechanisms as Ben Edgington would argue here – are an essential part of public blockchain architecture. For its security, Bitcoin is famously relying on the Proof of Work mechanism. Ever since 2012, an alternative in the form of Proof of Stake (PoS) has been introduced. Its primary claim is to reduce energy consumption and lower hardware requirements for those nodes that participate in the production of blocks. While with Proof of Work (PoW) these nodes are called miners, in Proof of Stake they are generally referred to as validators.

As a matter of fact, PoS has been introduced as a better alternative to PoW, mainly because it “produces” less waste. While this assertion seems convincing at first sight, a more thorough examination of the argument invokes skepticism. As has been laid out elsewhere in detail, if we refer specifically to waste rather than pollution, Proof of Stake is by no means necessarily less wasteful, since instead of energy used, capital is locked up that cannot be used alternatively.

Ultimately, PoW uses energy/hardware directly and specifically, while PoS uses capital/liquidity vaguely and generally.

So, although PoS is still considered the better alternative to PoW in mainstream circles, multiple valid criticisms have been raised against the concept of PoS. These don’t outright prove that the concept is worthless but at least correct the notion that PoS is somehow fundamentally better than PoW. In this article, we will focus on a specific topic, the security aspects of PoW as well as PoS consensus related to transaction finality.

What is transaction finality?

When a Bitcoin transaction is broadcasted to the network and a miner includes it in a block, it is generally not considered “confirmed” until a few blocks are created on top of it. This is the case because, with Bitcoin, naturally small chain reorganizations in the form of forks happen every now and then. As a consequence of network latency, some nodes accept different blocks at the same block height, resulting in two blocks being created simultaneously. Also, Bitcoin’s history of transactions can diverge because some nodes don’t accept particular transactions or blocks in the case of a potential network delay or Sybil attack.

Since the history of the Bitcoin blockchain can be reorganized, a block and its relative transactions cannot be considered immediately “final”. Instead, Bitcoin is known to have probabilistic finality, meaning that while transaction reorganization is probabilistic, the probability of reversing transactions is a function of cost. For miners to reverse transactions, they have to produce an alternative history that is costly. The more blocks are built on top of a transaction, the more hash rate is required to create an alternative longest chain, lowering the probability of a reorganization.

As such, Bitcoin is commonly also said to have economic finality. Even if it’s theoretically always possible to reorganize the Bitcoin blockchain, the probability for this to happen is very low due to economic incentives, since it is much more economically attractive for a miner to make money producing valid blocks on the longest chain instead of trying to fork a competing chain.

The concept of deterministic finality

Being familiar with probabilistic or economic finality, one understands why the usually portrayed image of Bitcoin being immutable is not actually correct. Still, from a user perspective, probably irreversible transactions would seem to be more desirable. And in fact, there are protocols – mostly Proof of Stake ones – that claim to have deterministic finality, which means that once a transaction is included in a valid block and satisfies the relevant consensus rules, it can no longer be reversed, while also achieving faster transaction confirmation.

In order to achieve such deterministic finality within a blockchain, a vote within a set of network participants is required. Because of the voting mechanism, once blocks are final, it is not the longest chain rule (as in Bitcoin) that decides on the correct chain, but the correct chain is determined and approved by a set of network nodes, acting as the ultimate authorities and accomplishing finality through their vote.

Implementing deterministic finality in Proof of Work chains

In theory, a mechanism similar to deterministic finality could be implemented in PoW chains too, implying an exception to the selection rule of the longest chain. For example, it is possible to create checkpoints
for blocks at a specific height, so that nodes won’t reorganize the history up to that block even if they see an alternative longest chain.

Currently, in Bitcoin, the only checkpoints accepted are the ones configured locally by node maintainers themselves. On the protocol level, there are no checkpoints though. The reason being that implementing any kind of deterministic finality or checkpointing system at the protocol level would introduce an unwanted source of centralization, chain splits, or the risk of a stall of the network.

There is general acceptance that introducing any sort of deterministic finality mechanism in Bitcoin would be considered more a bug than a feature.

Centralization risks of this kind should be avoided since the focus of Bitcoin developers is stability, security, resilience, and decentralization
of the network rather than faster on-chain transaction speed. In general, Bitcoiners have always recognized that the goal of fast transaction confirmation would be achieved together with scalability through the implementation of a second layer (Lightning Network) by switching off-chain, rather than increasing block frequency, block size, or implementing a finality tool for faster confirmation.

Deterministic finality: A necessity for Proof of Stake

So, if deterministic finality is a force for centralization, why are Proof of Stake protocols going for it? The crux of the matter is: In Proof of Stakes, not having some kind of deterministic finality implemented on the consensus level poses security threats to the network, so it’s more a necessity than an option.

Let’s take a closer look at why this is: In Proof of Stake systems, it is theoretically possible that an entity has the power to rewrite the history of the chain without bearing significant costs. Therefore, some sort of mechanism for enforcing deterministic finality must be implemented in PoS systems.

In fact, with PoS creating blocks doesn’t require any cost or effort expressed in energy, rather it requires the cost of having coins at stake (immobilized capital). Nodes that have – or used to have – block creation privileges could use their power to propose an alternative chain to the network without having to bear any cost in the form of energy expenditure.

Such an attempt is generally called a “long-range attack”, in which the attackers may not bear any cost since they have “nothing at stake”. For example, a few malicious participants within the network might sell all their previously staked coins, so that they now have no economic disincentives in attacking the chain, and then create an alternative history from the moment in the past in which they had block creation privileges.

The problem with deterministic finality in PoS

In most Proof of Stake chains, the deterministic finality mechanism requires that two-thirds of the active participants of the network vote on the validity of blocks. If the vote is cast in advance as a requirement to create a valid block (e.g. Algorand) and one-third of the stakers are missing, then the chain stalls. Instead, if the vote is held after blocks are validated to finalize the chain up to a certain height (e.g. Polkadot, more in general Substrate), and some nodes are temporarily separated by the main network, they may end up finalizing a different chain, causing a permanent fork.

Because stalls or permanent forks may threaten the smooth functioning of the network and its convergence property, “slashing” conditions have been proposed for PoS systems. For example, in Ethereum 2.0 with CASPER, nodes get penalized for going offline. Again, this “solution” may introduce new tradeoffs. Out of fear of losing money due to slashing, stakers can be disincentivized from staking, for example in the case nodes become non-operational because of a DDoS attack. And the fewer the stakers, the more the network is centralized.

Conclusion: Is the security of Bitcoin PoW still unparalleled?

All PoS systems are still experimental pieces of software lending themselves to serious considerations about centralization and other tradeoffs. There is not a straightforward alternative technology ready to substitute PoW, which really has the same degree of decentralization the Bitcoin network has. That being said: for governance, we see some sort of staking mechanism to provide a valid use case. Distributing the ownership within a DAO could be such a use case. For a decentralized base layer blockchain though, we find it really hard to replace what is known as Bitcoin’s Nakamoto consensus in terms of security and decentralization. Nevertheless, for the sake of innovation and progress, it is worth exploring any possible way, from PoS to interesting PoS/PoW hybrids.