With version v1.6 of the Java Kernel, we’re rolling out some big changes for miners on the network that addresses some of the concerns we’ve been seeing on the network over the last few months. Let’s do a dive into what happened, and how the fixes in the upcoming release addresses this.

Note: This document only addresses changes intended for miners on the network, there are other changes included in this hardfork as well.

Jump directly to the bottom of the document for actions miners and mining pools need to take.

On fluctuating difficulty

A keen observer of the network would have seen fluctuating difficulty within the Aion historical difficulty calculations starting May of this year. We’ve tracked down the source of these oscillations down to a single address contributing a large amount of hash power via a mining pool on the network in a periodic nature. Doing some simple smoothing on difficulty leads us to this diagram, which indicates roughly a cycle of a few hours on and off:

At first glance, we suspect this is some form of coin-hopping behaviour on the part of the miner, fluctuations like this are not uncommon on networks with smaller hashrates. We have further reason to believe it is being done for economic gain due to the frequent movement of AION from the miners account into Binance. This is an assumption that will have an impact on our solution (as we’ll see later), we feel it’s a safe bet as nothing we’ve seen so far indicates byzantine behaviour by this individual.

Furthermore, regardless of the purpose of this attack. The implementation is flawed and results in something analogous to a discouragement attack in which the whole network (including this miner) loses due to their actions. Let’s examine why.

On Proof-of-Work Block Timestamps

Another observation one can make on the network is that block timestamps are not being targeted correctly. We’ve had periods of time in which the average timestamp (if we’re going by the dashboard view it’s a windowed moving average) of around 15–20 seconds. A quick glance as we’re I’m writing this document shows 14.6 seconds. Clearly, something is wrong! Grabbing historical data from the blockchain since May and doing a similar smoothing operation shows us that block times are also fluctuating in the same fashion as difficulty:

But this shouldn’t happen, if the difficulty adjustment scheme is correctly targetting a block time, then it should continually try to adjust towards that block time, even if there are fluctuations in the network. Additionally, we know that the Unity difficulty adjustment scheme is quite aggressive in adjustments, meaning that even fluctuations in mining power should be resolved quite quickly (within blocks).

We find the root cause to be in the timestamps themselves. Recall that a difficulty adjustment scheme optimizes (at each block, or every other block from the PoV of mining) for a target blocktime T by adjusting the difficulty upwards or downwards based on a formula that takes the last known block delta as input. The problem arises when a large number of blocks produced are timestamped incorrectly, meaning that the difficulty adjustment algorithm is adjusting based on false information provided by a miner. In this case, a large portion of blocks being submitted (again by this one miner), is being done so with one second block times, causing the difficulty adjustment scheme to think that the hashrate of the network is higher than it actually is. This results in a difficulty that is targetting an artificially inflated hashrate, and therefore over time, an increase in block time. It is trivial to see that this is occurring by examining the offending pools block time distribution.

So why not enforce restrictions on timestamps? Well,

• Proof-of-Work timestamp can’t be enforced, there is no protocol level check (outside of simple bounds checks) that force a miner to timestamp honestly within those bounds.
• Heuristic-based checks are too rigid to adapt to large fluctuations in the network, and often lead to nasty corner cases.

There are other issues related to this that we raised in the original Unity Interleave paper, that is out of scope for this document.

The Discouragement Attack

What this leads to is the discouragement attack we alluded to earlier: as our block rewards are a constant 4.5 AION, everyone miner on the network is now mining fewer blocks, therefore earning fewer coins on average (if we take it into consideration of coins/sec). Keep in mind that if the miner is economically rational this is a net loss for them as well when compared to timestamping correctly, as they are also mining fewer blocks.

The Fix

We already ruled out a protocol enforcement strategy, therefore our fix centers around an incentives-based approach. We found that a feasible way of incentivising change was to punish this timestamping behaviour (we dubbed this internally as +1 timestamp) through economic incentives.

The crux of the fix is an update to the block rewards formula that has historically (for the lifetime of the project) been static for both miners and stakers, the block rewards issuance is now based on the current block time and will adjust dynamically based on how long it took the mine the block.

The function we select is (where Δ represents the block time),

f(Δ) = (b/T)•k•Δ+b•(1-k)

• b = 4.5 AION (the static block issuance)
• T = the target block time (10 seconds)
• k = the slope of the curve, for which we arrived at k=0.4

The effects of this are:

• The attacker is punished accordingly, adopting +1 timestamping means artificially decreasing block rewards, and earns 60% of what they were earning before.
• The rest of the network is rewarded for timestamping correctly in the presence of +1 timestamping behaviour. As in the presence of higher block times, the payout of each block is more than the static 4.5 AION.
• The net issuance over a longer period of time (assuming we reach the target block time) is unchanged.

We will monitor the network after the change to see whether the changes are taking effect as we intended, and make further changes accordingly. Our desired outcome being that this incentivises correct timestamping, leading to a desired 10 second block time.

Actions for our miners & mining pools

We tried from an engineering POV to minimize impact and localize this fix. Hopefully, this document has given you a good insight into how the changes might impact you in the future. To ensure a smooth transition,

• As this is a hardfork change (block rewards cannot be changed otherwise), all mining pools and miners should update to the latest Aion Java Kernel implementation (v1.6).
• Mining pools should update their Aion Pool 3 software to the latest version (v0.1.2) to account for varying block rewards in their payouts.

Hope this was an informative read! See you all around.