PoW Difficulty Adjustment Algorithm

Motivation

The network target for successful proof of work solutions is 11 per block. Currently there is no feedback mechanism between the amount of hash power on the network (and therefore the number of solutions per block) and the difficulty at which proof of work must be supplied. This leads to a situation where far too many correct solutions are supplied per block, which in turn bloats the blockchain with extra solutions.

It is therefore desired to introduce a difficulty adjustment algorithm to the network, such that it will retarget the difficulty and, over time, average out to 11 correct solutions per block.

Algorithm Selection

tl;dr: ASERTI3-2D as deployed on the Bitcoin Cash network.

The landscape today is not the landscape into which the original Bitcoin, the pioneer of PoW, launched. In that world, there was a single blockchain and all hashpower was concentrated on it. Even today, Bitcoin still attracts the overwhelming majority of hash power, so the assumptions made by Bitcoin’s DAA actually do still hold.

Forks and non-majority-hash networks have emerged over time. Miner behaviour is to switch hash over to any compatible network based on profitability in that moment, which itself is a function of coin price and network difficulty. This leaves networks in the situation where large amounts of hash can appear and disappear quickly; a situation not faced by Bitcoin itself, and not factored into Bitcoin’s DAA.

In 2020, the Bitcoin Cash network introduced the ASERTI3-2D algorithm designed to cope with the realities of a mulit-chain world with hash switching. This algorithm was extensively analysed before deployment, and has since had four years of battle testing in the wild. Whilst PoW is inherently a lottery and will never produce stable block times, ASERT has shown over time that it is comparable to classic Bitcoin (which operates under the initial single-chain-world and all-hash-on-one-chain assumptions) despite the presence of hash switching. For this reason, it has been selected as the DAA.

Parameter Mapping

ASERT was constructed with the following assumptions:

  • There is a stable target block time
  • Only the first solution matters per block
  • Blocks are solved and propagated once any solution is discovered
  • Actual block time is a function of hash power, difficulty, and random variance, and is one signal of hash power on the network

The scenario for AI-Block today is slightly different, in that block interval is fixed and regular. Today, the (permissioned and authoritative) mempool nodes control block production, producing mining candidates at a fixed and regular interval (30 seconds). A block is complete only when some target number of proof of work solutions have been collected from the mining community, today that number is 11.

A mapping function is therefore required to convert from AIBlock parameters to ASERT parameters:

  • If the difficulty is too low (active hash is high), AIBlock network will collect too many winning hashes, whereas ASERT operates on an actual block time earlier than the expected block time
  • If the difficulty is too high (active hash is low), AIBlock network will collect too few winning hashes, whereas ASERT operates on an actual block time later than the expected block time.

Several possible mapping functions spring to mind. The absolute simplest, however, performs a linear projection between cumulative hash count and time. Treating the activation as t = 0, the expected “time” for a block may be expressed as expected_time = block_height * target_hashes_per_block, whilst the actual block “time” may be expressed as the cumulative number of hashes since activation, actual_time = sum(winning_hashes_since_activation).

Keeping with this simple mapping function, the delta between expected and actual block “times” (hash counts) must be inverted. ASERT expects a low target to yield shorter block times, so actual block time will be less than expected block time, whereas in AIBlock network, too low a target will yield too many hashes, so mapped expected block time will be later than expected block time. The reverse holds for high difficulty.

The simplest possible mapping for this is to take diff = abs(expected_hashes - absolute_hashes) then either add or subtract diff from the expected hashes number, whichever operation matches the inverted sign of the delta between expected and absolute.

Activation

Activation refers to the point at which the new consensus rules for DAA take effect on the network. The simplest way to activate such a change is to hard-code a switch in the code based on block height.

1 Like

Review request

Can we please get links to the github repo? Also all amendments, updates, insights?