Waves Fork Details

On 15 August we made a major release with Waves Node 0.7.5. Among other functionality, there was an update that made it possible to buy WAVES with other tokens even if you don't initially have any WAVES for the fee.

This feature actually affects blockchain-level transaction validation but unwittingly wasn't included in a list of features for delayed activation. It was consequently activated immediately after DEX was updated on 16 August. The first transaction with this property caused a fork: updated nodes accepted a block with it, whilst older ones started a new chain. Since the fork occurred the day after the release, most of the larger miners had already updated and the 0.7.x chain has outgrown the 0.6.x chain very quickly. We decided that the best course of action would be to engage remaining miners and exchanges to upgrade to version 0.7 ASAP.

Why is 0.6.x chain longer than 0.7.x?

In Waves, blocks are created on average every minute, so any chain should have approximately the same height, albeit with some random variation. The parameter that nodes use to distinguish the best chain is called the 'score'. The score is an attribute of each block, and the score of the chain is a sum of block score in this chain. Although some nodes are still on version 0.6.x and using the 0.6.x chain, its score is dramatically lower than the score of the 0.7.x chain.

Unfortunately, there is no simple way at this point to check the score of the current chain via a node's API, and many people have simply looked at the height instead and been confused. We are going to address this by adding a score attribute to the API. Currently, there is another way to compare two chains - every block has a BaseTarget attribute, which is inversely proportional to the score (the lower BaseTarget, the higher score). The present BaseTarget of the main chain is less than 100, and the 0.6.x chain has a BaseTarget of around 1,000, so the score of 0.7 blocks is around 10 times higher.

We therefore currently have one main chain with almost all of the generating power, whilst other chains have considerably lower scores. Nodes which are used for the official client use the correct chain, so no action needs to be taken here.

At the same time, all nodes which are still running on version 0.6.x do not work with the main chain and must be upgraded ASAP.

In order to avoid such situations in the future we will:

  • Announce exact dates for major releases and publish release notes well in advance

  • Communicate with major parties (e.g. exchanges) at least a week prior to update to confirm they are ready

  • Implement a consensus-changing feature activation protocol based on the number of miners signalling support for the feature

  • Promote pre-release versions to mainnet earlier (1-2 weeks before release)

This article was helpful for 4 people. Is this article helpful for you?