P2PoW — Delegated Proof of Work

7 min readOct 13, 2019

A P2P solution for Nano PoW

Introduction

The Nano cryptocurrency is a great alternative to popular cryptocurrencies that are not very scalable. Because it has no artificial limits, it supports hundreds or thousands of transactions per second with zero fee and virtually instantly. Because there are no transaction fees or limits, Nano’s transaction potential depends only on node hardware and to discourage SPAM attacks Nano uses a verifiable Proof of Work system: For any transaction to be validated over the network, it must solve a exclusive mathematical puzzle, which requires computational resources from the user.

Problem:

Currently, this calculation requires processing, with greater efficiency for video cards (GPU) and good processors.

However, devices with less processing power requires more time to complete such work and, therefore, in this devices, the transaction will not always be so instantaneous as expected. Smartphones, tablets or even simple computers can take more than 30 seconds for a single work. In some cases as embedded and IoT devices can easily take more than 3 minutes per PoW.

After dynamic PoW has been implemented, in cases where the network is saturated the nodes will prioritize transactions that use a larger PoW. Although it better matches the demand of the network supply, still hindering spam attacks, it could also force other users to increase their own PoW transactions to be able to validate them, thus requiring even more processing and more time from them.

Fortunately, since PoW uses the last block hash and does not require the user’s private key, this process can be isolated and delegated to third parties.

Some Nano wallets make the PoW for the user on their own servers, free of charge. Although of great help, this kindness has its limitations. A growing demand for this type of service may require more and more resources and these developers will need to pay from their own pockets, depend on donations or charge their users. In addition, often without the economic incentive to manage a robust structure, these servers cannot react in the most efficient way to user demand. An economic incentive could enable a more reliable and flexible structure.

But this is not the biggest concern. Of particular concern is the centralization of so many users on so few servers that perform PoW.

A well-known service widely used by Nano wallets is the DPoW. A free API that connects nano wallets to multiple workers for the delegation of proof of work, encouraging workers with occasional small payments.

Despite its popularity, DPoW has relevant disadvantages:

Centralized
Permissioned
API offered only for non-commercial projects
Custody of funds

Workers need to trust the coordinator, users need to trust the coordinator, everyone still uses a centralized communication model for registration and API, based on central servers and DNS, which is more susceptible to human error, technical instability, regulations, prohibitions and hacker attacks. There are several central points of failure

There are also emerging services that charge a fee to offer their computational power. Although very useful, such centralized solutions may not be the best alternative for a decentralized cryptocurrency. Because in addition to having the same disadvantages mentioned above, users would be dependent on a single service at a time, since it is not economically viable to pay for multiple services if each proof of work can only be done for 1 service at a time.

The objective of this article is to bring a totally decentralized solution to these problems of Nano Proof of Work delegation.

The P2P Solution:

Nano accounts make sequentially linked block transactions. The block of every transaction uses the hash of the previous user block, concatenating it with the other transaction information and signing it. When the transaction is the first one on the account, the publick key is used. The PoW of every new transaction also uses the previous block. Therefore, without the previous block, there is no way to sign or create the PoW of a block, it is not possible to validate it in another way.
In Nano there is nothing to prevent a user from pre-compute their transactions and publish them long after. However, they will only be valid if, in addition to having a valid balance and signature, they have the correct block sequential order.
So, why not create a reward block that connects after the transaction block we want to make?
Consider the following image:

Alice wants to send 1 Nano to Bob.
For this she needs to do the Proof of Work of the transaction. But Alice’s hardware is simple and she doesn’t want to wait too long for PoW to finish.
So she creates the transaction, but doesn’t do the proof of work, instead he hires George to do it. Because George has a great equipment for it.
But George doesn’t want to have to trust Alice, because she might not pay him after work.
Alice also doesn’t want to pay and expect George’s work, because George may not do PoW after being paid.
So, to solve this problem, Alice signs another transaction of 0.001 Nano for George, but put this after Bob’s transaction.
Thus, the transaction for George can only be validated if the transaction for Bob is validated in the network first.
So George needs to do the Bob transaction PoW, the reward Pow and then broadcasting, only then he gets his reward.

Following the example, there is no way George can get his reward without first having the previous transaction validated by the network. If he tries to transmit PoW only from his reward, the network will consider the transaction invalid until the previous block (for Bob) is broadcasted.
George is also sure that he will not be fooled by Alice. All she needs to do is deliver the signed transactions to him, who will check their validity, checking the signatures and checking his node to see if Alice’s account really has that balance, so he won’t have to trust on Alice’s or a central entity to be assured that his work will be rewarded.

So George has a financial interest in being Alice’s Worker/Miner, Alice has an interest in her computational resource and both can trade safely.
Certainly, the worker will need to make at least two transactions in order to receive the reward of the latter, but with good hardware (such as a good GPU), can do this with tens of times more speed than the device of those who demand such a service, who may prefer to pay a small fee to have their transactions validated quickly than make their own PoW in a more time consuming way.

Not only ordinary users can benefit from P2PoW, but mainly big business such as exchanges and payment gateways.

In addition, such a mechanism can achieve greater efficiency in cases that require more than one transaction. Sender can require the node to make 100 transactions, for example, and place the proportional reward only on the last block. Thus, the total number of transactions necessary for the worker to receive his reward is 101.

The connection between sender and worker is established in a P2P way. We can make several connections with different workers, turning the PoW delegation into a competition similar to Bitcoins mining, whoever finishes PoW and does the broadcasting first wins the reward, which encourages workers to be as fast as possible and decreases the chances of the user being harmed by a slow worker.

Also, the existence of several of these workers can allow faster workers to charge higher fees to those who want to prioritize their transactions. And slower workers can compensate with lower fees. Senders and workers are free to negotiate at whatever fee they prefer and change it dynamically. The increase demand from users can lead to higher fees, while more competing workers tend to lower the fee.

The user will need to make a different reward transaction for each worker he chooses. After all, the nano address of each of them is different.

Another interesting point that we can explore briefly here is a different technique of connecting the users to the workers. Instead of the client software coming with a pre-defined list of trackers that shares the address of the peers to the others, we can use Nano transactions to identify participants.

Workers store their latest ipv4 / ipv6 within the representative field of a Nano transaction destined for a specific nano burn account, used as a “registration list”. In addition to facilitating the communication process and making the main trackers unnecessary, also eliminating certain attacks, this technique enables senders to check the transaction history of workers and possibly use as a criterion of reputation. Thus, in the case of many worker offerings, senders could save signatures and network usage by better filtering to which workers to delegate the process.

Worker API

Here is the Worker API (in python): https://github.com/anarkrypto/P2PoW

Web Demo:

Here you can see the active workers running the P2PoW protocol and test them. https://demo.p2pow.online

Conclusion:

Nano’s PoW can be a difficult task for many devices, delaying many transactions that should be instantaneous. Delegation to wallet servers and central API services can help, but creates the problems of centralization.
An efficient solution might be to connect P2P senders to workers who will compete among themselves to do the work of the desired transaction, in exchange for another reward transaction signed by the sender himself. Using Nano’s own system of sequential blocks we can guarantee irrevocability of the reward to the first worker to solve the PoW.
Therefore, this solution allows a decentralized delegation of the proof of work, ensuring a fast and secure transaction for any device.