TL;DR domain bundle transaction range adjustment was broken. While trying to fix it, I found we may not need it
A bundle is a set of transactions in a domain.
Each time slot operators of a domain hold a stake-weighted VRF election of the leader, who gets to select transactions from a predefined range and submit a bundle for inclusion into the consensus chain.
A transaction range is a range of sender IDs (out of all possible sender IDs) whose transactions this operator can include in their bundle. Example: if all possible IDs were letters A-Z, one operator’s range could be K-P. Limiting the tx pool available to each operator at each slot is a means of countering MEV and minimizing duplication of transactions across bundles. If there is no tx available in that range at the moment, the operator will not produce a bundle (with one exception, which is outside of the scope of this post).
Tx Range Adjustment
Dynamic transaction range adjustment is a mechanism that aims at stabilizing latency under variations in the operator set. It measures the number of bundles produced in a time interval, compares it to the expected number and adjusts the tx range accordingly. If bundles produced were too few, the range should increase so that more transactions can be picked in each bundle, and if bundles produced were too many, the range would shrink to avoid duplication.
Below I’m going to explain why it doesn’t work.
Assume that there are enough txs, so that every time an operator is elected, they produce a bundle with the txs in their range. Suppose we expect 600 slots in one interval before adjustment. By virtue of our VRF election, where each operator’s chance is equal to their percentage in total stake, we would roughly get 1 operator elected per slot, so ~600 bundles in 600 slots. It may happen we get less, so the range would increase, or more, so it would decrease. However, VRF elections are independent of one another and independent within intervals, and the tx range has no effect on bundle production whatsoever and would fluctuate.
Now assume that transactions happen to be few, so quite often, an operator can’t produce a bundle, so naturally, bundles are fewer than expected. If this situation is prolonged, the tx range will converge to the maximum value and stay there. When tx demand picks up, we move to case 1 and fluctuate around the same limit.
Note that the same happens if some operators are offline and don’t produce bundles when elected.
In this case, when producing a bundle, an operator can’t include all of the transactions available to him due to weight (gas) limits. From the point of view of bundle production, this will be the same as case 1, but transactions will wait in the pool longer. So, in this case, tx range adjustment doesn’t affect tx latency.
Currently, domain configuration file with which the domain is instantiated contains
target_bundles_per_block parameters aimed to control the latency of the domain. These 2 values are, in reality, derivatives of one another. Moreover, they have no effect on the analysis above as it always ends up in one of the three cases. Smaller
target_bundles_per_block artificially slow down the domain, and the latency of the consensus chain caps bigger values.
I conclude that tx range adjustment is unnecessary, as are the
target_bundles_per_block domain config fields.
I do think we should have a limited tx range per operator, but we need to select a reasonable static value (more on this later).