RSKIP517 – Block time-centric difficulty adjustment with uncle threshold

RSKIP
1

This thread introduces RSKIP517, a proposal to revise Rootstock’s difficulty adjustment mechanism to enable safer reductions in block time targets.

Motivation

The current difficulty algorithm was designed to maintain safe operation with a fixed block time and uncle production level. It achieves that goal under normal conditions, but exhibits two limitations when used to progressively shorten block intervals:

  1. Uncle rate conflation – The current design treats both main chain blocks and uncles as indicators of block frequency. This creates a feedback loop: reduced difficulty leads to higher uncle rates, which are misinterpreted as excess block production, triggering premature difficulty increases.
  2. Per-block sensitivity – Difficulty is adjusted based only on the latest block. Because block times follow an exponential distribution, this approach introduces persistent noise and a statistical bias that drifts the system away from the target.

These two effects make it difficult to lower block times without triggering instability.

Proposal

RSKIP517 addresses these issues by introducing a window-based difficulty update method. Rather than reacting to single-block samples, the algorithm computes average block time and uncle rate over the last NNN blocks. Uncle rate only influences difficulty when it crosses a specified threshold, allowing the system to prioritize main chain block timing while still preserving safeguards against instability.

This proposal builds upon the ideas in RSKIP77, which introduced smoothing via windows, but RSKIP517 further decouples uncle rate from regular difficulty adjustments.

It also replaces RSKIP491, addressing the same objective—progressively reducing block intervals—through a more robust adjustment mechanism. The open question from that thread regarding the impact on protocols remains, and further exploration is still encouraged.

For a higher-level overview of the motivation and proposed changes, see the accompanying article:
:open_book: Rootstock Blocks Getting Faster: Redefining Difficulty Adjustment

Open Questions for Discussion:

  1. What potential risks can we identify in reducing the block time to 20s?
  2. Apps/protocols that depends on block time?
    • PowPeg (source code)
    • FlyOver (LPs update # of blocks in UI, also source)
    • RootstockCollective DAO (do you know where to link it?)
    • Protocols like MoC and Sovryn (?.
1 Like
2

Seems like a great proposal. Way faster than Bitcoin L1, on par with Cardano and setting the stage for future improvements in the future. Any risks with implementing?

3

In terms of risks, the most immediate consideration is coordination with existing protocols. Many DeFi applications, bridges, and services rely on a fixed number of confirmations, assuming ~30s block times. With this change, the time-per-confirmation drops, so protocols may need to revisit their assumptions about finality and security thresholds. Good communication will be key here.

On the implementation side, we also need to be careful about classic edge cases in difficulty adjustment logic. For example, the historical off-by-one bug in Bitcoin’s difficulty adjustment mechanism (see Bitcoin StackExchange) is a good reminder to carefully validate transition conditions and boundary cases during testing.

Importantly, this RSKIP is just the first step. Our plan is to monitor its impact on uncle rates and network stability. If the results are positive, we intend to propose further reductions in the block time target.