To understand that, the process of adding a block to the chain has to be examined. The prerequisite for adding a block to the chain is the computation of the block header of the new block. In order to compute the block header, the node has to first verify transactions that it wants to be included in the new block, and build the corresponding Merkle root. The purpose of the nonce lies in the rationale of the proof-of-work mechanism, which is to aggravate the process of blockbuilding. The reason for that is, that in a decentralized network, where potentially everyone can find a new block to the chain, too many new blocks would be built and propagated at a time, resulting in inconsistent blockchains across the network.
Therefore, blockchain protocols require the hash of a block header to meet a certain condition in order to complicate the building of blocks. That is, blockchain protocols only accept blocks with a block header that is smaller than a certain threshold. In other words, the header hash must have a predefined number of leading zeros. Hash functions are deterministic, which means that they always produce the same output, given the same input data. Therefore, in order to vary the output of the header hash so that it meets the precondition, the input needs to be modified as well. As illustrated in the above figure, the nonce is essentially a variable that can be adjusted in order to obtain the desired block header.
Since the output of a hash function is one-directional, the problem cannot be resolved mathematically, and therefore has to be obtained by pure brute force methods, i.e. the nonce has to be guessed. In order to obtain a desired block header, nodes run programs that modify the nonce to find the desired block header via trial and error. For a single computer, the preconditions set by typical proof-of-work blockchains would take years to solve. As every node in the blockchain network, however, works on solving its own proof-of-work problem in the pursuit of adding a block, the CPU of a network can be accumulated. Hence, depending on the protocol, the average time a network needs to find a suitable nonce usually ranges from several minutes to an hour. Given the case a node finds a nonce that satisfies the block header prerequisites, it adds the block onto its block-chain and shares the block with the network. The nodes in the network validate the block and, if successful, append it to their blockchain. Since the blockchain now has a new block and, accordingly a new block header, every node will stop their proof-of-work be-cause the hash pointer they use is not up-to-date anymore. Therefore, nodes dissolve the block they have been working on and start over with building a new block, taking the block header of the recently added block as the hash pointer input. In this way, the blockchain is continuously updated and impliedly consented by the network.
In the improbable case of a simultaneous blockbuilding, i.e. two or more nodes finding a suitable nonce at the same time, nodes will add the block that reaches them first to their blockchain. In such a situation, different nodes will work on different blockchains. Even though this is not desirable, it is hardly avoidable in a system where speed is the determinant of successful blockbuilding. In order to solve this problem, the blockchain protocol stipulates that the longest blockchain is always the valid one. This ensures, that now that nodes work on different blockchains, nodes will accept the longer blockchain once a new valid block is found and disseminated to the network, even though it might not include the block they have already added to their blockchain. To put it simply, the recent blockchain always includes the blocks that have been created the fastest. Proof-of-work can be therefore seen as a race. Each and every node in the network participates in the race in the pursuit of adding a new block. Disregarding valid blocks in order to include own (potentially fraudulent) blocks would be irrational as the longest chain always wins, which is why every node has an interest to always work on the most recent chain in order to be able to add a block to it. This is the very mechanism that renders blockchains so secure. To effectively forge the system, an attacker would theoretically have to control more than 50 percent of the computing power of the system. In a public network, that incentivizes its participants to play by the rules, however, this is highly improbable. In fact, the Bitcoin blockchain has proven to be remarkably secure since its inception.
The proof-of-work consensus algorithm described above is by far not the only way with which blockchain architectures achieve consensus. A lot of alternatives have emerged that claim to solve the issues of proof-of-work, which are abundant. Most notably, the solution of the proof-of-work problems require considerable amounts of computing power and thus, energy (the featured image for this article depicts one of the server farms that are used to mine cryptocurrencies that work with proof-of-work). Proof-of-stake, one of the most relevant alternatives to proof-of-work suggests that validation of blocks should depend on the ‘stake’ a node holds in the blockchain, e.g. how many coins of a cryptocurrency a node holds. This comes with several other implications, which will not be elaborated on here. A later episode might deal with different consensus algorithms and their advantages and disadvantages.