The CHIP is fairly mature now and ready for implementation, and I hope we can all agree to deploy it in 2024. Over the last year I had many conversation about it across multiple channels, and in response to those the CHIP has evolved from the first idea to what is now a robust function which behaves well under all scenarios.

The other piece of the puzzle is the fast-sync CHIP, which I hope will move ahead too, but I'm not the one driving that one so not sure about when we could have it. By embedding a hash of UTXO snapshots, it would solve the problem of initial blockchain download (IBD) for new nodes - who could then skip downloading the entire history, and just download headers some last 10,000 blocks UTXO snapshot, and pick up from there - trustlessly.

The main motivation for the CHIP is social - not technical, it changes the "meta game" so that "doing nothing" means the network can still continue to grow in response to utilization, while "doing something" would be required to prevent the network from growing. The "meta cost" would have to be paid to hamper growth, instead of having to be paid to allow growth to continue, making the network more resistant to social capture.

Having an algorithm in place will be one less coordination problem, and it will signal commitment to dealing with scaling challenges as they arise. To organically get to higher network throughput, we imagine two things need to happen in unison:

• Implement an algorithm to reduce coordination load;
• Individual projects proactively try to reach processing capability substantially beyond what is currently used on the network, stay ahead of the algorithm, and advertise their scaling work.

Having an algorithm would also be a beneficial social and market signal, even though it cannot magically do all the lifting work that is required to bring the actual adoption and prepare the network infrastructure for sustainable throughput at increased transaction numbers. It would solidify and commit to the philosophy we all share, that we WILL move the limit when needed and not let it become inadequate ever again, like an amendment to our blockchain's "bill of rights", codifying it so it would make it harder to take away later: freedom to transact.

It's a continuation of past efforts to come up with a satisfactory algorithm:

• Stephen Pair & Chris Kleeschulte's (BitPay) median proposal (2016)
• imaginary_username's dual-median proposal (2020)
• this one (2023), 3rd time's the charm? :)

To see how it would look like in action, check out back-testing against historical BCH, BTC, and Ethereum blocksizes or some simulated scenarios. Note: the proposed algo is labeled "ewma-varm-01" in those plots.

The main rationale for the median-based approach has been resistance to being disproportionately influenced by minority hash-rate:

By having a maximum block size that adjusts based on the median block size of the past blocks, the degree to which a single miner can influence the decision over what the maximum block size is directly proportional to their own mining hash rate on the network. The only way a single miner can make a unilateral decision on block size would be if they had greater than 50% of the mining power.

This is indeed a desirable property, which this proposal preserves while improving on other aspects:

• the algorithm's response is smoothly adjusting to hash-rate's self-limits and actual network's TX load,
• it's stable at the extremes and it would take more than 50% hash-rate to continuously move the limit up i.e. 50% mining at flat, and 50% mining at max. will find an equilibrium,
• it doesn't have the median window lag, response is instantaneous (n 1 block's limit will already be responding to size of block n),
• it's based on a robust control function (EWMA) used in other industries, too, which was the other good candidate for our DAA

Why do anything now when we're nowhere close to 32 MB? Why not 256 MB now if we already tested it? Why not remove the limit and let the market handle it? This has all been considered, see the evaluation of alternatives section for arguments: https://gitlab.com/0353F40E/ebaa/-/blob/main/README.md#evaluation-of-alternatives