Overview

This release includes a major reworking of the batcher-sequencer DA throttling feature (allowing for smoother control of transaction and block size limits), a new admin RPC method to flush the batcher (causing it to submit a transaction as soon as possible) as well as several performance enhancements and bugfixes.

Sequencer throttling changes

The old batcher supported only a very simple form of throttling: once a threshold of DA backlog was reached, it would fully throttle the sequencer and other block builders. This would often lead to a clunky user experience, as throttling kicks in fully at once, and then eases fully once the backlog dips below the threshold.

This release introduces three new throttling controllers to allow for more smooth throttling behavior than this step controller. The three new controllers are linear, quadratic, and a PID-like controller (experimental, not recommended). The new default throttling controller is quadratic.

Instead of throttling getting activated at a single threshold, like the old step controller, there is now a lower and upper threshold at which throttling starts and then continually increases in intensity as the backlog grows. The intensity curve is determined by the throttling controller (linear, quadratic, step (old behavior), PID (experimental)). Throttling at the lower threshold is weak and at the higher threshold strong. Please review the defaults by running ./op-batcher --help.

Another important change is that the throttling threshold now takes all pending data into account, that is, all channels that are currently being submitted, the pending open channel that is currently being built, and the pending blocks that still need to be added to the pending channel. Before, throttling only took into account the pending blocks, which means that it may have triggered much too late if a high --max-pending-tx value was set (default: 1), which is common among high-throughput chain operators.

Please read the new throttling documentation carefully to understand the new behavior and how to tweak it, if necessary.

What's Changed

• op-batcher: improve default throttle parameters by @sebastianst in #17148
• op-batcher: overhaul throttling flags by @geoknee in #17032
• op-batcher: set throttling defaults by @geoknee in #16957
• fix(op-batcher): introduce unsafe_da_bytes metric for driving the throttling controller by @geoknee in #16950
• op-batcher: decrement pending bytes metrics when pruning pending blocks by @geoknee in #16940
• feat(op-batcher): add admin rpc to flush the batcher by @geoknee in #16837
• op-batcher: more consistent use of throttle multiplier and max threshold in logging by @geoknee in #16820
• feat(op-batcher): make max throttle threshold more visible in logs and API by @geoknee in #16804
• op-batcher: always use blobs while throttling by @joshklop in #16773
• feat(op-batcher): Enhanced DA Throttling with multiple control mechanisms by @tobidae-cb in #16588
• perf(op-batcher): start publishing and throttling sooner when loading a backlog of blocks by @geoknee in #16648
• perf(op-batcher): discard channel compressor after frames generated by @geoknee in #16597
• fix(op-batcher): remove duplicate check by @chuwt in #16696

New Contributors

• @tobidae-cb made their first contribution in #16588
• @chuwt made their first contribution in #16696

Full Changelog: op-batcher/v1.14.0...op-batcher/v1.15.0

🚢 Docker Image https://us-docker.pkg.dev/oplabs-tools-artifacts/images/op-batcher:v1.15.0