A P2P solution for Nano PoW

Image for post
Image for post

Introduction

Problem:

Image for post
Image for post
Nano Whitepaper Data

However, equipment with less processing power requires more time to complete such work and, therefore, in this equipment, the transaction will not always be so instantaneous as expected. Smartphones, tablets or even simple computers can take more than 10, 20, 30 seconds for a single job. In some cases as embedded devices and other IoT devices can easily take more than 2 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 and does not require the user’s private key, this process can be isolated and delegated to third parties. Several Nano wallets make this 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.
There are also emerging services that charge a fee to offer their computational power. Although very useful and popular, such centralized solutions may not be the best alternative for a decentralized cryptocurrency.
A new model that we know recently is the Distrubuted Proof of Work. A paid API that connects the miners and senders in a centralized way.
But there is still a central point of failure. In addition to DPoW requiring registration of both users and workers, it requires a central server coordinating the mining pool and payments, it also requires the custody of funds.
Miners need to trust the coordinator, customers 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.

The objective of this article is to bring a totally decentralized solution to this problem of Nano’s PoW.

The P2P Solution:

Image for post
Image for post
Delegated Proof of Work — Diagram

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 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 the 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 because the previous block will be absent in the ledger.
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 word and no 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.

But in addition, such a mechanism can achieve greater efficiency in cases that require more than one transaction. Sender can require the node to make 1000 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 1001.

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!

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 dynamically. The increase demand from senders can lead to higher fees, while more competing workers tend to lower the fee.

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

Another interesting point that we can explore briefly here is a different technique of connecting the senders 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 a nano wallet (pay-to-fake-key), send it a specific amount, and then transact another specific value into a general register wallet. This creative technique may be better explained in the future. 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

Conclusion:

Thanks for reading! Share or donate if you liked it

Donations: nano_18eoa1k16d4n1b5hb8hwxm5mmgp6zny7owhn8omc5bgxjahxsyznob9u536t

Written by

Desenvolvedor, cripto-entusiasta e criptolibertário

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store