Today we are announcing Proof of Work difficulty updates in the upcoming Athena V21 release which involves two changes: adding the ability to split work generation difficulty between block types and making updates to work difficulty thresholds. The work difficulty updates will be an increase for send and change blocks by 8 times, and a reduction for receive blocks to 1/8 current work levels.
Read on for more details on why and how this decision was made, along with additional changes being evaluated for work generation over the long term.
Why implement a difficulty increase now?
These changes are needed because the current difficulty level was set over 4 years ago and advances in CPU and GPU power since then have made work generation increasingly cheap, lowering the threshold for a Quality of Service attack on the network. As mentioned in the last PoW algorithm research update, we’ve been looking at work increases in the short term due to higher risks with implementing a new algorithm.
With no strong economic incentive to drive expenditure required for the development of specialized hardware, the main concern today is focused on GPU and CPU capabilities. The goal is to tune the difficulty in a way that adds additional network protection while maintaining a reasonable effort level for average users and services on the network.
Although getting this balance right will involve multiple changes over time, the current changes are aimed at providing some short term protection while longer term strategies are researched, designed and implemented.
How did we decide on the increases?
We’ve been discussing this difficulty change directly with engaged service providers on the network since late last year, and more recently with the wider Nano community on the forums and in various Discord channels. Based on feedback and benchmarks outlined below, we feel we have found the right balance between increases to the cost and generation time, and user experience from an individual, person-to-person level up to heavier-use services like payment processors and wallets.
We are adding the ability to require different work difficulty levels based on block types to help shape work generation costs for different use cases. With Athena, we will be simultaneously increasing the send and change block difficulty by 8x and reducing the receive (which can include a change of representative) to 1/8x the current difficulty.
Based on these changes, if work for both a send and a receive are done, together they represent about 4x more difficulty vs. a send and receive block today, but these will impact different network participants in different ways.
CPU and GPU Benchmarks
We did some rough benchmarking of work generation across various CPUs and GPUs to get an approximate range of performance. This included GPUs such as GTX 1070, GTX 1080Ti, Vega 64, and miscellaneous CPU versions.
Current difficulty estimates:
- Common consumer GPUs: 3–5 work/s ≈ 0.2–0.4 s/work
- Common consumer CPUs: 0.1–1 work/s ≈ 1–10 s/work
With the V21 work changes the typical efforts with new difficulty are expected to roughly be:
Send and change blocks
- Common consumer GPUs: 0.4–0.6 work/s ≈ 2–3 s/work
- Common consumer CPUs: 0.01–0.1 work/s ≈ 8–80 s/work
- Common consumer GPUs: 24–40 work/s ≈ 0.03–0.05 s/work
- Common consumer CPUs: 0.8–8 work/s ≈ 0.1–1 s/work
In addition to local and cloud CPU/GPUs, testing 8x work on the Distributed Proof-of-Work (DPoW) network resulted in work generation times around 1s on average.
At these new levels a typical user will still be able to have send work easily pre-cached between transactions and if needed, it can be generated on-demand quickly using a common GPU. Services doing more receive-heavy volume will also have a reduced burden in managing their funds.
What about pre-cached work?
Work values can still be pre-cached for accounts with V21 and by default the developer wallet in the node will be configured to do so at the 8x send/change block level. This allows the work to be sufficient regardless of the block required.
This same pre-cache approach is recommended to other wallets and services for a few reasons:
- This provides the best user experience to avoid delays when using wallets
- Many users pull money into their wallets in bulk (fewer receives) and spend money with merchants/payment processors in smaller transactions (more sends), so optimizing for the more frequent sends is beneficial to typical users
- Merchants and payment processors often batch or bulk perform receives into their hot wallets, which allows them to take advantage of the lower 1/8x work for receive blocks since these are done in quick succession and not pre-cached
To help ensure this change is easy to make for integrations, alongside the release we will be upgrading our documentation to provide best practices for work pre-caching outside the node.
Does this require epoch distribution?
A distribution of epoch blocks will be required to transition all accounts to generating and validating at the new work thresholds. Support for a new epoch version was added in V20 of the node, but was not setup to change account behavior at that time. With V21 the new epoch v2 blocks will upgrade accounts to the new work requirements.
Details on the timing of epoch distribution will be communicated closer to the release of V21 and will depend on enough voting weight on the network being upgraded before it is completed. See Network Upgrades documentation for more details on epoch and other network upgrade mechanisms.
What else can be done?
The Athena V21 changes are a step in the right direction for work generation tuning and we will continue improving on these through upcoming releases. A big thanks goes out to our community and active services for generating lots of interesting discussions about other approaches and longer term items to investigate.
Here are a few forum topics to dive into if you’re curious what other work generation discussions are happening:
If you have any feedback or thoughts on the work changes, please join us to discuss on Discord or in the forums. We’re looking forward to delivering this helpful change in the Athena V21 node release soon!