Nano How 4: Proof of Work
By: Nano Education
Tags: Fintech, Bitcoin, Nano, Blockchain, Features

Proof-of-Work

The term PoW was coined in 1999 though the concept behind it dates from a 1993 journal article. It was initially designed to combat email spam, forcing the sender to incur a computational burden in order to have its email not be immediately rejected by servers. In theory, scaling this computation to a large number of emails (the case of spam) would be impractical.

PoW was largely popularized by Bitcoin, the first decentralized cryptocurrency network. Its purpose is to prevent double-spending by having miners compete for the solution of a [nowadays] very difficult math problem, which requires a large number of blind attempts to complete.

There are several PoW functions available to use. For cryptocurrencies, the ones of interest can be categorized into two schemes:

Compute-bound, where faster processors (or graphics processors) can more quickly obtain the proof, and parallelize the computation.

Memory-bound, where the computation speed is bound by memory latency or bandwidth, which is expected to not evolve as quickly as processor speed.

Why

PoW in Nano is used only to discourage spam transactions. Without it, and given the asynchronous nature of Nano’s block-lattice, anyone would be able to push valid transactions to the network at a theoretically infinite rate, which would quickly saturate nodes in terms of bandwidth and other resources.

As such, and as we saw in a previous article, every block must contain a small proof.

A commonly asked question is, “Why do receive blocks require PoW?”. While the complete answer is more complex than what we intend to go on, it has been discussed in detail. Basically, it is used to discourage the creation of high depth forks in the network.

How it works

The ideal proof of work is a mathematical problem that is really hard to calculate but simple to verify.

Generating PoW — To generate, the system cycles through the same calculation with slightly different numbers each time, until it gets an answer that meets a difficulty threshold. This process can take millions of attempts, consuming time and resources.

— To generate, the system cycles through the same calculation with slightly different numbers each time, until it gets an answer that meets a difficulty threshold. This process can take millions of attempts, consuming time and resources. Verifying — Verifying the proof is a very quick process. The value of the proof is calculated and checked against a predefined difficulty threshold. When a block contains a proof with a value below the threshold, it is discarded by nodes in the network. If the proof is valid, then the block is processed.

Nano currently uses blake2b as its PoW hash function, a compute-bound algorithm, due to it being very fast to verify. It is noteworthy that this could change in the future should a more appropriate solution present itself.

In order to enforce a new proof for every block, the equation that the proof must satisfy depends on the previous block’s hash, as follows:

In this equation:

nonce is a random 64-bit value which is changed in order to try achieve a valid proof

is a random 64-bit value which is changed in order to try achieve a valid proof threshold is predefined in Nano with the value 0xffffffc000000000 .

As the equation depends on the previous block, there is the special case of the first block (open block) of any account, in which the account’s public key is used instead (read the first Nano How).

While generating a proof requires, on average, 67108864 nonces to be tried (hence the same number of hashes), in order to verify a proof only a single blake2b hash is performed. This means that if it takes one second, on average, to obtain a proof, it will take 14.9 nanoseconds to verify it (assuming it doesn’t take any time to start, which is a crude approximation).

Dynamic and Prioritized PoW

Up until version 18 (Dolphin) of the Nano node, all blocks were treated equally, in the sense that they were processed in random order or in the order that they arrived. However, in cases of a large transaction rate in the network, nodes might get overloaded and have a queue of blocks requiring confirmation by the network.

Since version 19 (Solidus), and with improvements in version 20 (Lydia), two new features were introduced: Dynamic PoW and PoW Prioritization.

Dynamic PoW is a simple, partially local process that takes place if a locally produced block has not confirmed after a few seconds. In this case, the node uses a new, higher threshold to re-generate the PoW for the block. This threshold is obtained from the average of the queue of blocks awaiting confirmation. With a higher difficulty, the block gets prioritized as a consequence of the next feature.

PoW Prioritization further discourages spamming the network, by prioritizing confirmation for blocks with the largest PoW difficulty value. It becomes increasingly difficult for an entity generating large amounts of blocks to update the difficulty of each one. On the other hand, a user requiring quick confirmation of their own block would have to re-generate PoW for a single block. This allows users to transact at normal speeds and circumventing the spam being sent by the attacker.

Casual users of the Nano network can spend additional time pre-computing their next PoW so that their transactions are prioritized, while larger services can use auxiliary services such as DPoW to provide PoW on demand for their transactions quickly.