[PIP-0002]: Migration from BTC-Style Difficulty Adjustment Algorithm to ASERT

[andrepatta]

Summary

This PR implements the difficulty adjustment algorithm described in PIP-0002, migrating Parallax from the original Bitcoin-style 2016-block DAA to ASERT (Absolutely Scheduled Exponentially Rising Targets). The goal is to make block times more stable and predictable under volatile network hashrate, while reducing miner gaming opportunities and improving long-term network reliability.

Motivation

The current BTC-style DAA only adjusts every 2016 blocks and responds poorly to sudden hashrate swings. This has already caused long block intervals and unstable chain progression during periods of low mining participation. ASERT solves this by adjusting difficulty on every block. The algorithm reacts smoothly and immediately to changes in network hashrate, preventing multi-hour slowdowns and oscillations. This proposal was discussed with the community in GitHub Discussion #3.

Benefits

• Much faster response to hashrate drops and surges.
• Smooth difficulty curve with no oscillation windows.
• Stronger reorg resistance.
• More predictable block intervals, improving user experience and fee market behavior.

Philosophical Tradeoff

Migrating from the classic Bitcoin-style DAA to ASERT is not only a technical change but also a philosophical one. The Bitcoin DAA is intentionally conservative: it accepts long periods of slow or fast blocks as a natural consequence of decentralized mining dynamics. This design reflects a philosophy that the protocol should intervene as little as possible in short-term market behavior. Difficulty adjustments happen infrequently and only after long, deterministic windows. This conservatism creates stability in a historical sense, even if short-term block times become inconsistent.

ASERT takes a different approach. It prioritizes real-time responsiveness, smooth adjustment, and protection against miner-driven oscillations. It treats consistent block intervals as a core part of user and developer experience, and it smooths out volatility rather than allowing it to propagate for thousands of blocks. This aligns with a philosophy that a modern Proof-of-Work chain should not suffer multi-hour stalls simply because mining participation temporarily drops.

Adopting ASERT means embracing the view that predictable block timing, network usability, and security against timestamp manipulation are more important than preserving the exact mechanical behavior inherited from Bitcoin’s historical design. Some purists may view the BTC-style DAA’s inertia as a virtue, while others see ASERT's per-block feedback loop as a more evolved and resilient model for a contemporary PoW network.

Consensus Impact

This is a consensus-breaking change. All non-upgraded nodes will diverge from the canonical chain at the activation height. Therefore, the activation block height must be announced in advance, and all miners and node operators must upgrade before that point.

Implementation Details

• Introduces ASERT into Parallax’s consensus engine as described in PIP-0002.
• Uses the block immediately before activation as the anchor block (anchor height = activation height - 1). Its timestamp and target define the baseline for all ASERT calculations.
• Computes heightDelta and timeDelta to derive the exponential deviation from ideal schedule using fixed-point math with a 2^16 radix.
• Uses the polynomial approximation coefficients from the proposal to compute the multiplier for the next target.
• Includes test vectors and validation checks for correctness.

Testing

• Added unit tests to verify ASERT calculations against expected difficulty values.
• Simulated chains with rapid hashrate swings to ensure block interval stability.
• Verified backward compatibility at activation height and correct anchor derivation.

Rollout Plan

• Activation block height TBA.
• Anchor block = activation height - 1.
• Require all full nodes and miners to upgrade before activation.

Conclusion

ASERT provides a stronger and more stable foundation for Parallax in its current stage of network growth. The change removes the fragility observed under BTC-style DAA and ensures predictable block intervals even with shifting miner participation. This PR is ready for review and community approval.

[andrepatta]

Proposed activation block height: 17610

[Yarchikee]

Proposed activation block height: 17610

Good job, keep going 👍

[coolpooltop]

I think we should wait. There will be a reduction in difficulty soon and it will be seen there.

[andrepatta]

I think we should wait. There will be a reduction in difficulty soon and it will be seen there.

I tend to agree with this view. But also need to take into account that we're loosing hashrate daily. With current hashrate the next DAA window will be reached in 2 to 3 months from now.

My ideal scenario is to (hopefully) get past 18144 without these changes and postpone this migration to a later height. Not sure that's possible though.

I wont push these changes for at least a few days and I want to gather feedback from the community about it as it's a controversial topic.

Thanks for expressing your opinion here. Cheers!

[PlMem]

This idea is such a good thing!

I took a really quick look of the code and found one moment.
https://github.com/microstack-tech/parallax/blob/2aa979fa417d802ba2b30142603c14d314049242/consensus/xhash/consensus.go#L272-L296
I think, there is a potential risk if blockchain will reorg right after fork activation (likely to happen, since it is a hardfork). If it will happen, cached anchor block will become invalid, but since init flag already set, anchor won't be recomputed and node will calc diff from invalid ParentTime and Target.
Thus, it will lead to the blockchain split into 2 (or more) parts.
Please, correct me if i am wrong and this risk has already been covered.

[andrepatta]

This idea is such a good thing!

I took a really quick look of the code and found one moment.

https://github.com/microstack-tech/parallax/blob/2aa979fa417d802ba2b30142603c14d314049242/consensus/xhash/consensus.go#L272-L296

I think, there is a potential risk if blockchain will reorg right after fork activation (likely to happen, since it is a hardfork). If it will happen, cached anchor block will become invalid, but since init flag already set, anchor won't be recomputed and node will calc diff from invalid ParentTime and Target.
Thus, it will lead to the blockchain split into 2 (or more) parts.
Please, correct me if i am wrong and this risk has already been covered.

Yes, you are correct. I'm working on a "reorg aware" activation as we speak. Feel free to propose a solution too!

The chance of a reorg deep enough to hit the activation block is very unlike though. This need to be fixed nonetheless.

Thanks.

[andrepatta]

This should fix deep reorgs past cached anchor block @PlMem.

[oyb811026]

Please activate

[PlMem]

This should fix deep reorgs past cached anchor block @PlMem.

Yes, solution is great.
Only thing that i can propose now, that we can hard-protect only N blocks after the fork, and then recheck it only each Mth block to slightly improve performance by reducing DB lookups. However, as far as I can guess without direct benchmarking, in this context it is just overkill.

[andrepatta]

This should fix deep reorgs past cached anchor block @PlMem.

Yes, solution is great. Only thing that i can propose now, that we can hard-protect only N blocks after the fork, and then recheck it only each Mth block to slightly improve performance by reducing DB lookups. However, as far as I can guess without direct benchmarking, in this context it is just overkill.

I don't think we need to worry about excessive DB lookups at the moment. At current state, it queries the DB up to three times at CalcDifficulty call and then caches the necessary attributes, and once per CalcDifficulty call to determine if a reorg happened.

At some point in the future we can consider the anchor block immutable once the chain tip is further above the activation height, and then hard code the attributes required to calculate next target in ASERT (anchor difficulty and anchor parent time).

[PlMem]

This should fix deep reorgs past cached anchor block @PlMem.

Yes, solution is great. Only thing that i can propose now, that we can hard-protect only N blocks after the fork, and then recheck it only each Mth block to slightly improve performance by reducing DB lookups. However, as far as I can guess without direct benchmarking, in this context it is just overkill.

I don't think we need to worry about excessive DB lookups at the moment. At current state, it queries the DB up to three times at CalcDifficulty call and then caches the necessary attributes, and once per CalcDifficulty call to determine if a reorg happened.

At some point in the future we can consider the anchor block immutable once the chain tip is further above the activation height, and then hard code the attributes required to calculate next target in ASERT (anchor difficulty and anchor parent time).

I totally agree with you.
One DB lookup won't affect performance that much to think about it now (especially while network has 10 minutes block time). It was just an idea like "what else can be done at the moment in this direction".

Good job!
Waiting for merge and activation.

[andrepatta]

We migrate to ASERT if network hashrate remains below 25GH/s until December 12th, with activation early next week.

[andrepatta]

We lost half of the network hashrate in the last couple days and we're well bellow the 25GH/s threshold.

I'm going to anticipate the merging of this PR as I won't be available during xmas holidays (23th - 30th) and would be good to have this activated when I'm still around just in case.

Activation at block height 17560 which we should reach in a few days. I think there's plenty of time for mining pools and exchanges to upgrade.