Dynamic Proof-of-Work & Prioritization

Details of the upcoming Quality of Service feature

Zach Hyatt
May 30 · 6 min read
  • If pre-cache work doesn’t exist or is below the floor difficulty value (should only occur when work was generated for incorrect frontier hash), new work will be generated for the transaction with the threshold at the current active difficulty value.
  • If the block difficulty is lower, rework is triggered for the block at the higher current active difficulty. This work will be canceled if the block is subsequently confirmed during work generation. The resulting block will be republished to the network.
  • Depending on network conditions, once 75% (during low volume), 50% (during higher volume) or 25% (during highest volume) of active transactions are of this long unconfirmed type, the dropping of transactions will occur.
  • Transactions being dropped are calculated based on their “adjusted difficulty”. This adjustment takes into account the average difficulty seen across any chain of blocks, to prevent a series of lower difficulty blocks with a higher difficulty block at the end from getting dependently confirmed despite lower work levels.
  • When these dropping conditions are met, up to two of these long unconfirmed, lowest adjusted difficulty elections will be dropped off when a new election tries to be added in their place. This repeats until the percentage of active transactions isn’t over the applicable threshold (25%, 50% or 75%).
  • Any blocks you publish through the node wallet will not be dropped by your own node, but other nodes may drop them due to this feature. If this occurs and causes delays in confirmation, the node can either be set up to manually request a confirmation on the block again or wait for confirmation height checking of account frontiers (every 15 minutes, checking up to 256 unconfirmed frontiers), which will cause elections to be restarted.
  • “Watch only” accounts in the node wallet are not protected from having their transactions dropped out of the active transactions queue.
  • Confirmation times will increase as nodes must work through the backlog to vote and broadcast.
  • If the volumes are large enough to slow confirmation times to more than 5 seconds, node wallets that have published their own transactions will begin comparing the difficulty of work on those blocks. If too low, they will redo work at the current active difficulty level and republish.
  • As blocks are republished with more difficult work they will get prioritized higher in the queue to get confirmed more quickly. Unless spammers do rework on their blocks, they will not be as high a priority, allowing other blocks ahead of them. This will increase the confirmation times for the spam blocks but keep other transactions moving quickly towards confirmation.
  • If too many blocks linger in the active confirmation queue for too long, some of the lowest difficulty blocks will be dropped out to make room for others.
  • Single-account spam event note: as the more powerful nodes on the network confirm up the spam chain more quickly than others, they will be creating conditions where large sections of the chain could be confirmed together by the less powerful nodes that are working to catch up at a later time. This is because of confirmation of dependent elections where a higher block confirmed will result in all valid successor blocks to also be confirmed. This was added along with Confirmation Height in V19.

Nano

Nano is a secure global digital currency

Zach Hyatt

Written by

Bending tech for good

Nano

Nano

Nano is a secure global digital currency