Comparison between Proof of Work & Proof of Stake

28.10.2015

Everyone who has looked at Bitcoin close enough probably understands that it’s a revolutionary achievement created by a legendary, forward thinking individual or group. Superficially, the revolutionary technology built within it has the ability to send money without any central authority, so you don’t need someone to issue your cash, it just exists – somewhat similar to gold.

But also, everyone who had time to dig a little deeper could see that Bitcoin technology goes far beyond money. Basically, what you have in Bitcoin is the first decentralized database in history, and value transfer is just one of many natural applications for it. A much broader range of data can be stored on the blockchain. Projects such as Couterparty, Tether, and Mastercoin utilize the decentralized nature of the Bitcoin blockchain database for a wide range of financial operations, including trading and crowdfunding.

Crypto 2.0 platforms, such as NXT, Eth, and Bitshares offer functionality beyond simple money transfer integrated into the core, not built on top of it. Second generation crypto platforms highlight the generic nature of a distributed blockchain database. The idea behind the blockchain approach is to create a decentralized database, which cannot be taken down by any individual player, and use it to store arbitrary data.

This article will provide a short entry-level description of the current methods to create and secure such a database, omitting technical details and focusing on the general picture.

Decentralized blockchain database

Let us use a constructive approach – so we need a decentralized database, which can be accessed and modified by all participating network nodes. The database should be consistent (all nodes see the exact same version of it), available (a node can write to it or read from it at all times), and partition-tolerant (if one node goes down it does not affect the database). But it turns out, and rigorously proven mathematically, that such a database cannot exist (CAP theorem). You can have two properties out of three, but not all of them. We cannot sacrifice availability or partition-tolerance, so we have to accept the fact that different nodes from time to time can see different versions of the blockchain database, commonly referred to as “forks”.

But we should find a recipe to eventually restore consistency so that all system nodes have the same version in front of them. That’s where the beauty of the “Blockchain” comes into play. The Blockchain decentralized database is not just an arbitrary database, all entries are formed into “blocks” and organized into a linear fashion. Each subsequent block is linked to its predecessor. A node has to have some “clout” in order to be able to add a database entry, while the process of writing to the database should use a certain resource as nodes process. By making a node “pay” something in order to be able to write to the database it serves two goals – prevention of spam nodes from polluting the network, and at the same time obtaining a recipe for choosing the “right” database in case of doubt – the database with the most blocks wins. In theory, more “resources” were used to build it, so it would be considered the correct chain.

On top of that we need to prevent centralization of the network, which can occur if a certain node had resources comparable to the resources of the rest of the network. If this were the case, such a node could effectively control what should and what should not be stored in the database.

So, to summarize, the process of building the database looks like this:

– Nodes send their data into the decentralized network for processing
– Nodes form the data to be added into blocks and attempt to add the formed blocks into the database.
– The database with the most added blocks is considered to be the “true” database, all nodes use it as a reference for adding new blocks.

So now we have to understand what kind of “resources” can be used in order to make writing into the blockchain database “difficult”, so that a single node wouldn’t be able to control the network, since its resources cannot beat the aggregated resources of the rest of the network.

Securing the blockchain

Since we deal with computer networks, one obvious choice is the computational power itself. In order to add a block to the blockchain, a node has to solve a complicated computational task, which makes it highly improbable for any one node to control the network. This is the Proof-of-Work concept – basically a node can check that the “miner” (node that added a new block to the blockchain) has actually executed the calculation.

In Bitcoin, nodes iterate through a parameter called “nonce”. This involvestrying to find a hash of the block header (a part of the blockchain entry which contains a link to the preceding block and summary of the Bitcoin transaction included in the block) which would be below a certain limit, tied to the current “Difficulty” parameter. This calculation can be done only in an interactive fashion and the Difficulty is set in such a way so it becomes really, well, difficult. Yet, checking the calculation is simple. Nodes can always check that the miner has found the correct nonce.

Bitcoin POW has spawned a whole new mining industry and created specialized hardware manufacturers. The resources spent on hashing Bitcoin blocks is enormous, and exceeds the computational power of the largest supercomputers by a wide margin. The calculations miners execute have no value outside the Bitcoin ecosystem, which makes many think that it could be used in some other, more useful way. Of course this is a matter of debate, since securing the Bitcoin blockchain might be a noble goal in itself. In any case some other possibilities should be considered.

Proof-of-Stake

Bitcoin is a decentralized money transfer system first and foremost. Its blockchain can be used for other goals too but it was obviously invented to be a “better money”.

Nodes send to one another a blockchain token (a certain value associated with a transactions inputs and outputs) which effectively creates the Bitcoin balance of a given node (in reality the Bitcoin database does not contain the balances, instead it contains transaction inputs and outputs). This gave Sunnyking, the creator of Peercoin cryptocurrency, the idea to use “stake”, a value locked to a transactions outputs, as a resource that determines which node gets to mine the next block. In the proof-of-stake approach, nodes also try to hash the data in such a way that the result is below a certain value, but Difficulty in this case is inversely proportional to the node balance of the blockchain token. So the more balance a node has the higher the probability for it to generate the next block. Since it does not seem likely for a single node to have more balance than the rest of the network this scheme seems to be very appealing, due to very low computational requirements and virtually no “wasted” computational resources.

At first glance, Proof-of-Stake seems to be a much better solution than Proof-of-work, but in reality it is not so simple. POW, besides wasting too much energy, it its current most popular realization also has a significant deficiency. Bitcoin miners organize into mining pools, and the pool operator can, in theory, control most of the networks hashing power. In this way, decentralization is lost and one big player can effectively control the network.

Yet, it also has clear advantages, POW miners spend electricity, a resource which is “external” to the network. POS miners, on the contrary, use an “internal” resource, namely their account balance, and spend much less computational “external” resources. This is the root of the famous Nothing-at-Stake problem, which makes POS systems to be inherently unstable in the eyes of many cryptocurrency enthusiasts. An attacker can try to fork the blockchain, i.e create a longer blockchain than the current one, spending no “real” resources, and he can even be aided by other miners, since they don’t spend any “real” resources either. By forking, an attacker can invalidate certain transactions and execute “double-spends” (pay a merchant, receive the goods, fork the blockchain, and replace a payment to the merchant by a payment to his own account in the “forked” blockchain).

The Nothing-at-Stake problem manifests itself in all attack vectors on POS systems. Attacks could be roughly broken down into two categories: short-range and long-range. In short-range attacks the most recent blocks are replaced, in long-range the attacker goes deeper, trying to replace the whole history of the network. He might go as far as the first “Genesis” block.

Short-range attacks

Let’s take a look at the short-range attack first. An attacker tries to fork the most recent blocks, by starting with a block that precedes them and building on top. The goal is to build a blockchain which is longer than the currently accepted one. Other mining nodes, seeing the attacker’s activity, might have an incentive to help him, since it wouldn’t cost anything to them – computational overhead is very low, and by mining on different blockchains they increase their chances of being on the right one.
It should be noted that in reality it wouldn’t be so easy as it looks in theory, since the majority of the network would continue to mine on the main chain, and needs a good deal of coordination and concerted effort from the attackers. But theoretically this attack is clearly possible.

The typical strategy in preventing short-range attacks consists in penalizing the bad-behaving node. POS systems have the benefit of being more deterministic than POW systems. Typically, the chance for a node to generate the next block in POS systems depends on node address, its balance, current difficulty, and timestamp. Search space is limited to a number of seconds between the adjacent blocks (since it’s the only parameter that changes). So it becomes possible to predict the next mining (or “forging” as it is said about POS systems) node, and penalize it in case it misbehaves, by not accepting its version of the blockchain. This is the way which is being developed in NXT cryptocurrency, one of the first second-generation coins.

Another approach is to make miners pledge a certain amount of network token prior to being able to forge a block. If a node sees that the miner has signed with his public key two competing blocks on two competing blockchains it reports it, and the collateral gets confiscated from the miner. This is the approach which Ethereum is going to take. Currently it’s not realized in any live cryptocurrency.

In most existing POS cryptocurrencies, centralized checkpoints are still used – that is the coin developer periodically confirming the correct version of the blockchain (Peercoin). This does not look very true to a decentralized nature of cryptocurrencies, but let us not forget about Bitcoin’s issues with centralized pools. Gigahash, the largest Bitcoin mining pool, voluntarily chooses not to control more than 50% of the network, although they could.

Long-range attacks

Now let’s take a look at long range attacks. This is where things get even more serious for POS, at least theoretically.

When going from the depth of the blockchain history, an attacker tries to replace the whole history of transactions. Since computational efforts are much less for POS systems, he can in theory, start from an old block and stack up the transactions in such a way that he is able to create a longer blockchain than the currently accepted one. He can even try to purchase private keys of old accounts, which had balance some time ago, and use them to forge his fork.

One way to prevent this would be to limit the depth starting from which network nodes can accept a new fork. In NXT, for example, if the fork has started longer than 720 blocks ago, it won’t be accepted by the network nodes. But in order to reject a fork, a node has to have a copy of the current blockchain, which is not the case for a new node who just joined.

There’s no “theoretical” way to prevent an attacker from feeding his fork to a new node now. He can successfully enforce his subjective view of the network history on new nodes. So some centralization seems to be unavoidable for now since trusted nodes have to provide the current blockchain to a new participant. This is called “weak subjectivity”, and seems to be quite an unavoidable measure for current POS theories.

What we would like to highlight now is the certain similarity between POS in POW systems regarding their security. Both approaches depend on the network developers good will and integrity. Many POS systems have been forked by developers, to re-wind history after successful attacks on the blockchain or even an exchange who had a significant amount of the currency in question. POS and POW supporters have been having heated debates for years, but they have a mostly theoretical nature. Reality proves that the developers role in securing the network is still very significant.

Personally I think that some mixture of POS and POW will be the most secure solution for future cryptocurrencies. In fact, this is the most common approach already. Many cryptocurrencies have a POW stage, which issues the currency by paying new coins to POW miners, and a POS stage which sets in when all the currency has been issued. Most industry-grade cryptocurrency will probably not do without POW – the Nothing-at-Stake mentality has taken its grip over cryptocurrency experts.

But POS systems will always be much easier to implement, and actually as secure as POW systems.