Today, decentralized networks use lots of different consensus mechanisms, but it all started with proof-of-work (PoW). We’ll take you through the story of how it came into being, how it operates and why it’s still used as one of the core algorithms in Web3.
In the beginning, proof-of-work wasn’t conceived as a foundation for decentralized networks. It had nothing to do with cryptocurrencies at all, and was in fact designed to help protect users of “shared resources” from various kinds of abuse. The creators of the concept, which was put forward back in 1993, offered a solution that would restrict access to a given resource by requiring participants to carry out complex calculations. It was also established that the results of these calculations would be easily and quickly verifiable.
The first version that was suitable for practical implementation was proposed only five years later, when Adam Back created the Hashcash project, the main task of which was to combat spam. The idea involved using cryptography to make it harder to send mass emails. Before sending each email, senders must carry out complex calculations – find such a value of x that the SHA(x) hash would contain N leading zero bits – and include the result (proof-of-work) in the message header.
In order for the letter to reach the recipient, it must be verified that the sender has solved the cryptographic problem. This can be done very quickly with a one-time SHA-1 calculation using a label that has been prepared in advance. This label is generated by the sender before they begin solving the problem and becomes publicly available to all participants in the system. As a result, sending a couple of letters doesn’t cause any issues, but to run a mass email campaign you’ll need some serious computing power.
Sounds familiar, right? This concept was used in 2008 by Satoshi Nakamoto to create Bitcoin and its proof-of-work blockchain.
How PoW blockchains work
At the core of Nakamoto’s idea (it remains unknown whether they are a real person or a group of developers) was the goal of creating a decentralized electronic cash system independent of third parties. It would allow money to be sent directly, without intermediaries such as banks.
Information about transactions is stored in a registry which is distributed among the system’s participants. The sequencing process involves packing the transactions into blocks, which are of a limited size. Each block must contain information about the previous block. To do this, all of the relevant data (transactions, the previous block’s hash, the timestamp etc.) are converted into a unique code known as a hash. This is done using a hash function, which in the case of Bitcoin is called SHA-256. Special “full nodes” are responsible for managing the chains, while miner nodes are involved in the creation of new blocks.
It's important to recognize here that the hash function works in such a way that the same hash will always be obtained from a given data set. Even the smallest change results in a different hash.
As we said earlier, miners must calculate a block’s hash in order to add it to the chain. This isn’t particularly time-consuming in and of itself, so in order to prevent the computational problem from being solved too quickly, the network adjusts the computational difficulty every 2,016 blocks. This represents a period of roughly two weeks. It is done to ensure that the block mining time is around ten minutes, which provides for the stable operation of the blockchain.
So how does this work in practice? Miners receive blocks as inputs and calculate the hash. The network, however, requires that the hash is lower than a certain figure. Hang on – didn’t we say earlier that the hash can’t be changed? So how does this work? This is where the nonce – number only used once – comes in. It is added to blocks and changed by miners during calculations, resulting in a different hash. Miners then compare the resulting hash with the computational difficulty target, and if the hash value is greater, they change the nonce again and recalculate the hash. This process is repeated until a match is achieved (the result must be equal to or less than the target hash value), and can happen millions of times.
To give you a clearer picture of the scale of the task, look at the following number:
This is the number of possible combinations in the SHA-256 hash. It’s equivalent to the number of stars in the universe, 115 billion times over.
The transaction chain
Now let’s look at a standard transaction to see how all of this works. Let’s say we’re sending funds to somebody in the form of BTC. After we have generated and signed the transaction with our private key, it is sent to the network. The full node verifies that it is correct and, if there are no issues, allows it to continue through the networks. Other nodes also carry out verification checks and put it in the queue of unconfirmed transactions (mempool).
Miners collect transactions from the mempool (selecting the ones that will bring them a large commission first of all), pack them into a block, and begin to perform calculations. When one of the miners solves the problem, the full nodes check the solution and, if it is correct, the miner receives a reward. At this point, the block is considered “mined” and added to the blockchain, while information about it is sent to all network participants. After that, the miners start working on the next block. At the same time, the more blocks that are included in the blockchain after the block containing our transaction, the higher the level of its confirmation.
To put it simply, for a transaction to be considered legitimate, most nodes in the network must agree that the block containing it has been calculated correctly.
Is all of this unavoidable?
Nakamoto wasn’t the first person (or people) to set out to create a decentralized system, but he is the first to have seen fit to use the proof-of-work consensus mechanism. Without it, it would be impossible to solve the problem of double spending, which arises when a sender spends the same funds twice before the system confirms the transaction. Miners check transactions for double spending each time they receive them from the mempool.
It is true that, on a PoW blockchain, two miners can mine the same block. This is not necessarily a malicious act, and may well happen if both miners complete a calculation almost simultaneously and one of them doesn’t receive the information that the block has already been mined in good time. In this case, a parallel chain appears, originating from the erroneous block. To get rid of the wrong "branch", the consensus mechanism compares the two blockchains while giving precedence to the longer version.
Problems and limitations
The biggest problem with PoW – at least in its purest form – is scalability. For example, the throughput of the Bitcoin blockchain is about 7 transactions per second, which is quite low. Because of this, the mempool fills up during peak load times, and transactions with low processing fees can get stuck for several hours or even days. At first glance, you might think that the easiest way to increase speeds would be to make blocks larger so that more transactions can fit into them, or to simply mine them faster.
But you can’t increase the block size without consequence: a lot of computing power would be required to create them and, as a result, only large miners or mining pools would remain in the network, reducing decentralization.
If you shorten the processing time, there is a risk that the network nodes will not be able to reach consensus before the next block appears. Because of this, the number of “branches” of the blockchain would increase and make double spending possible.
All of this is encapsulated in the concept of the blockchain trilemma, which holds that decentralized networks can only provide two of their three core benefits at the same time – decentralization, security and scalability. To solve this in the context of PoW, blockchain layers are used. They operate “on top” of the main system and increase transaction processing speeds.
Additionally, new consensus protocols are being developed that work alongside PoW. For example, Kaspa uses PoW as a network security mechanism, while blocks are packed into a directed acyclic graph rather than a blockchain, allowing miners to work on different blocks in parallel.
There is also a more prosaic issue: the more computing power a blockchain accumulates, the higher the complexity of calculations and the greater the energy needs when it comes to mining.