Adaptive Blocksize Limit Algorithm (ABLA)

Summary

ABLA recomputes the block size limit after every block, based on an exponentially weighted moving average of recent block sizes. The 32 MB limit stays as a “stand-by” floor; any increase is “a bonus on top of that, sustained by actual transaction load.” See ABLA.

Motivation

From the CHIP: “Needing to coordinate manual increases to Bitcoin Cash’s blocksize limit incurs a meta cost on all network participants. The need to regularly come to agreement makes the network vulnerable to social attacks.”

The algorithm changes the default. Today’s default is “do nothing until something is decided.” The new default is “adjust according to this algorithm (until something else is decided, if need be).” The CHIP aims for “minimal to no impact on the game theory and incentives that Bitcoin Cash has today.”

What it specifies

• A control function tracks block sizes with a forget factor. Its input is amplified by an asymmetry factor (ζ = 1.5), so the limit rises only under sustained load above a threshold and eases back when load drops.
• An elastic buffer adds headroom when the control function rises fast. The proposed buffer can “borrow” about a year of growth (for example, a quick 2× over a few months) and then decays with a half-life of about half a year.
• The limit is the control block size plus the buffer, never below 32 MB.

The CHIP models a spam attack by a miner with 50% of hashrate filling its own blocks. It would take about 1.5 years to double the limit and 2.5 more years for another +50%, while costs keep rising.

Current status

Accepted and activated on 15 May 2024. The stakeholder table records 60 approvals, 8 neutral and 4 disapprovals. The outreach counted non-responses as neutral.

The algorithm has not raised the limit in practice so far, because current blocks are far below 32 MB. The proposed Faster Blocks CHIP would rescale ABLA to 1/10 per block so throughput per minute stays the same.