guilhermelawless / nano-dpow Goto Github PK

There are some use cases where someone would want to setup DPoW and not need to precache blocks. It can already be accomplished by simply not feeding any blocks via callback/websocket, but a specific precache_disabled mode would save on storage - no account/block storage necessary.

Suggested by @zhyatt (thanks!).

Simply discarding work received by clients is wasteful. Even if we don't reward those, we can still compare their work value with the available one and replace if higher.

A more conscious approach is to save multiple work values, and when work is requested, use the one immediately above the current active difficulty. This creates a soft dependency on more node functionality. If broken, we can rely on the service to request what they think is an appropriate difficulty. We can also use always that mode, which puts the burden of tracking active difficulty on the services.

Currently we are sending all requests to be queued up on the work server side, internally.

Under heavy service request load, all clients will get all hashes in the same order (more or less), which can lead to high latency for some services.

We can take a different approach by making a client-side set and popping a hash randomly from the set every time we have to send a work request.

• Google form for registration
• API for charging credits
• Consolidate purchases into a distribution accout by sweeping the accounts

To discuss and decide approach:

• [ ] Fee plan for services
• Fixed client payout or scale with available donation pool?

Services to-do:

• [ ] Service credit handling logic
• [ ] Provide automatic way to recharge credits

Clients to-do:

• Snapshot per-client work counters
• Compare current DB to last snapshot
• Script to payout each client automatically based on work completed

The configuration options have grown too much and ussing a file is preferable.

Implement a rate limiter per-service.

Add DPoW logo and other details.

Websocket must be tested thoroughly upon release of Nano node v19. A necessary enhancement: automatic reconnection upon failure.

The current authentication method requires services to store their user+password combination in a config file. There are many alternatives, the most interesting is probably token-based authentication:

1. Service asks for a token with their user+password combination. Token is valid until revoked either by the server or service.
2. Use an open standard like JWT to retrieve time-limited application tokens, valid for e.g. 1 hour. This is then the authentication sent for every work request.

Having received multiple reports of unexpected issues, such as receiving wrong work, a commit 638f22c has been pushed which disables precaching by default. This means all work is calculated on demand.

Benefits of disabling precache:

• No longer needing a connection to a Nano node
• Profoundly reduced complexity
• Avoiding calculating work that won't be used if the account is being used elsewhere

Disadvantages:

• Added latency for incoming requests

Since on demand work has been served with less than a second of latency, I don't see an issue with disabling precaching until the work difficulty increases substantially.

I don't expect to find the time to investigate the root of the problem. I would advise a complete re-write of the server with testing in mind, as this one is not ready for it.

Rough start:

If using internal management, suggest using Betsy and nothing else is necessary. If a pure integration is desired, then increasing the minimum receive is required.

1. RPC account_info -> grab the frontier (which will be the previous block to your send)
2. Ask DPoW for work using that hash (the frontier)
3. RPC Send with the given work

Alternative (advanced):

1. (Same)
2. RPC block_create
3. Work from DPoW
4. RPC process

For both cases there is an exception - if the account is not created yet, there will be no frontier. In this case the public key should be used, which can be grabbed from RPC account_key.

Finally, keep an eye on the CPU usage during your sends and receives to make sure there is no PoW being re-generated. This would not happen with the advanced method.

https://github.com/nanocurrency/nano-pow

To be described after the full API is released, and decide whether to use a PoW server or the library directly via FFI.

https://redis.io/topics/persistence#backing-up-redis-data

Luckily amqtt (a fork of hbmqtt) is still maintained and uses pretty much the same API.

Since there's no node directly attached, only callback/websocket, setup a way to determine how long it's been since the last block processed.

This can be displayed in an interface or checked with uptimerobot for a notification.

While not critical, it's good to have precaching.

Due to some reports of issues with difficulty scaling - specifically, that the resulting work would not meet the desired threshold - a commit has been pushed to disable difficulty scaling until the issues are resolved. bec7280

For now, all requested work is forced at 1x base difficulty.

I don't expect to find the time to investigate this. I would advise a complete re-write of the server with testing in mind, as this one is not ready for it. See also #44

Testing with the help of @BitDesert indicates linux (unknown which distros) will attempt a handshake for every request, and this adds about 200ms of latency. Windows performs as expected.

            time_namelookup:  0.004
                time_connect:  0.030
             time_appconnect:  0.248
            time_pretransfer:  0.248
               time_redirect:  0.000
          time_starttransfer:  0.275
                             ----------
 time_total: 0.275

Add a WSS endpoint for a persistent connection with services.

Initial tests show that if I request work without the "account" field (for example using betsy) then, there is no precache happening when the block is seen by DPoW.

https://docs.nano.org/integration-guides/work-generation/#difficulty-thresholds

Todo:

• Notify services and known DPoW server replicas of plan
• Update base difficulty, currently attached to https://github.com/Matoking/nanolib , potentially detach
• Temporarily clamp max difficulty rather than returning an error (add a hint in response)
• Lower the max multiplier to 1.0-2.0
• Update only when epoch 2 starts

Won't be covered for now:

• Allow requesting receive difficulty

Current interface at https://dpow.nanocenter.org/ , instead provide incremental stats via MQTT and maybe a complete update very ocasionally or on demand.

Linux Mint 19.3
dpow_client.py v1.1

$ python3 -V
Python 3.6.9

$ cat run_client.sh
#!/bin/sh

SERVER="127.0.0.1:7000"
PAYOUT="nano_someaddress"
OPTS=""

python3 dpow_client.py --payout "$PAYOUT" --server "$SERVER" $OPTS "$@"

$ sh run_client.sh
Traceback (most recent call last):
  File "dpow_client.py", line 205, in <module>
    dpow_client = DpowClient()
  File "dpow_client.py", line 56, in __init__
    "default_qos": 0
  File "/home/user/.local/lib/python3.6/site-packages/amqtt/client.py", line 127, in __init__
    "amqtt.client.plugins", context, loop=self._loop
  File "/home/user/.local/lib/python3.6/site-packages/amqtt/plugins/manager.py", line 52, in __init__
    self._load_plugins(namespace)
  File "/home/user/.local/lib/python3.6/site-packages/amqtt/plugins/manager.py", line 63, in _load_plugins
    plugin = self._load_plugin(ep)
  File "/home/user/.local/lib/python3.6/site-packages/amqtt/plugins/manager.py", line 73, in _load_plugin
    plugin = ep.load(require=True)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2323, in load
    self.require(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2346, in require
    items = working_set.resolve(reqs, env, installer, extras=self.extras)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 783, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (PyYAML 6.0 (/home/user/.local/lib/python3.6/site-packages), Requirement.parse('PyYAML<6.0.0,>=5.4.0'))

And sometimes (it is random):

Traceback (most recent call last):
  File "dpow_client.py", line 205, in <module>
    dpow_client = DpowClient()
  File "dpow_client.py", line 56, in __init__
    "default_qos": 0
  File "/home/user/.local/lib/python3.6/site-packages/amqtt/client.py", line 127, in __init__
    "amqtt.client.plugins", context, loop=self._loop
  File "/home/user/.local/lib/python3.6/site-packages/amqtt/plugins/manager.py", line 52, in __init__
    self._load_plugins(namespace)
  File "/home/user/.local/lib/python3.6/site-packages/amqtt/plugins/manager.py", line 63, in _load_plugins
    plugin = self._load_plugin(ep)
  File "/home/user/.local/lib/python3.6/site-packages/amqtt/plugins/manager.py", line 73, in _load_plugin
    plugin = ep.load(require=True)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2323, in load
    self.require(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2346, in require
    items = working_set.resolve(reqs, env, installer, extras=self.extras)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 783, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (websockets 9.1 (/home/user/.local/lib/python3.6/site-packages), Requirement.parse('websockets<9.0,>=8.0'))

$ ls ~/.local/lib/python3.6/site-packages | grep PyYAML
PyYAML-5.4.1.dist-info
PyYAML-6.0.dist-info
$ ls ~/.local/lib/python3.6/site-packages | grep websockets
websockets
websockets-8.1.dist-info
websockets-9.1.dist-info

I tried running the client in Ubuntu, I found that I needed to install the python3-hbmqtt package before it would run. It would be a good idea to add this package as a dependency in the readme alongside ocl-icd-libopencl1.

Once finished

Following merged PRs for v19 https://github.com/nanocurrency/nano-work-server