If you have been following the Nano project, you have almost certainly come across discussions regarding the Proof-of-Work required for transactions. While Nano uses a form of Delegated-Proof-of-Stake to reach consensus, the Proof-of-Work is still a key part of the network. Let’s take a look at what Proof-of-Work is, how it is used on the Nano network and possible improvements that can be made in the future.

What is Proof of Work?

In a Proof-of-Work (PoW) system, computers compete to solve advanced algorithms in order to verify cryptographic hashes. Proof-of-Work is an economic measure and can be used for a variety of reasons, typically to deter denial of service attacks or Sybil attacks by requiring some work from the service requester, usually meaning processing time by a computer.

The difficulty of the work computers must perform is adjustable. Cryptocurrencies such as Bitcoin require massive amounts of computing power in order to verify transactions, in Nano, the Proof-of-Work difficulty is very low.

Why is Proof-of-Work so Important for the Nano?

When you send an e-mail, you typically do so for free. Because there is no cost, you are able to send a massive amount as spam, flooding a user’s inbox. A similar thing happens with Nano. Since there are no fees to transact on the network, an attacker could theoretically send a large number of transactions at no cost, filling the network and rendering it unusable. To combat this, before a transaction takes place a small Proof-of-Work is required.

Because of the Proof-of-Work needed to send transactions and the high throughput of the Nano, it is difficult for a user with low computational power to spam enough transactions to disrupt the network. However, since the Proof-of-Work is static, an attacker could pre-compute transactions and spam the network. Because the owner of an account is the only entity who can add blocks to their account-chain (aside from an Epoch block), sequential blocks can be computed, along with their PoW, before being broadcast to the network. Here the attacker generates a myriad of sequential blocks of minimal value over an extended period of time. Eventually, the attacker broadcasts the transactions, performing a Denial of Service (DoS) by flooding the network.

Solving pre-computed spam attacks is difficult. The system must make sending transactions unproductive for an attacker, but should also not interfere with regular users operating on the network.

Issue from GitHub

Dynamic Proof of Work

There are many proposals from the community/devs about various forms of Dynamic Proof of Work. Let’s look at some of them.

This one suggests the representative nodes can increase required block threshold under spam attack attempt and keep it easy in usual situations. In this case, the attacker will have to pre-compute a high Proof-of-Work to make the attack, making it more expansive and practically unfeasible.

This one suggests something like:

All > 0.1% voters choose a PoW difficulty, combined with a rounded Unix-timestamp. The sequence, if change votes are needed, then signs: Ed25516(difficult || Unix-time || sequence). When the nodes agree with the values, the node creates a PoW using all signatures as part of the derivation. So, something like Blake2(size = 8, message = Nonce || AllVotersSignatures || previous)

In this case, the only way to pre-compute the PoW is predicting the signature of all nodes, which is not possible.

Cuckoo Cycle: Memory Bandwidth Bound PoW Mining

Cuckoo is a Proof of Work algorithm that focuses more on memory use rather than raw computing power. Unlike normal PoW, which requires maxing out the capacity of your CPU, a memory-bound approach requires enough computing power to saturate the memory of your computer.