gas-limiter: split bundle and mempool into independent per-address pools

[avalonche]

Summary

Split the per-address gas limiter into two independent pools — one for public-mempool txs and one for bundle txs (including backruns) — each with its own capacity and refill rate. Also relabels the existing tx-simulation duration histogram with kind and result labels so latency can be sliced by source and EVM outcome.

Why

Today bundle txs and mempool txs share one per-address budget, so a limit tight enough to deter bundle abuse also throttles ordinary users.

What changed

• New GasLimiters { mempool, bundle } holder owns one limiter per source. Routing by transaction metadata

New CLI flags

• --gas-limiter.bundle-max-gas-per-address (default 10000000)
• --gas-limiter.bundle-refill-rate-per-block (default 1000000)

The existing --gas-limiter.enabled, --gas-limiter.max-gas-per-address, --gas-limiter.refill-rate-per-block only manages mempool limits. A single gas_limiter_enabled toggle turns both pool limits on together.

[akundaz]

Today bundle txs and mempool txs share one per-address budget, so a limit tight enough to deter bundle abuse also throttles ordinary users.

Ordinary users will never max their budgets, so they would never be affected.

Other concerns:

• Revert protection doesn't apply to txs from eth_sendRawTransaction, so a throttling mechanism just targeting them is unnecessary
• If someone is hitting the limits by using reverted txs, I don't see why we should allow them to send eth_sendRawTransaction txs freely

I would like to see data on if we're actually throttling txs from eth_sendRawTransaction, that would help convince me that something like this is a good idea.

[julio4]

Today bundle txs and mempool txs share one per-address budget, so a limit tight enough to deter bundle abuse also throttles ordinary users.

Ordinary users will never max their budgets, so they would never be affected.

Other concerns:

• Revert protection doesn't apply to txs from eth_sendRawTransaction, so a throttling mechanism just targeting them is unnecessary

I would like to see data on if we're actually throttling txs from eth_sendRawTransaction, that would help convince me that something like this is a good idea.

Valid concerns however I think that framing the public mempool and bundle mempool with separate budgets is the correct model, as they are very different resources from the builder perspective (because of revert protection). Even if we're not harming ordinary users yet, it is a good precaution in case we ever need to be more aggressive with bundle rate limiting.

• If someone is hitting the limits by using reverted txs, I don't see why we should allow them to send eth_sendRawTransaction txs freely

This is not an issue if we consider them separate resources. Users hitting bundle limits will not send the same volume of orders through eth_sendRawTransaction, and even if they do they'll have to pay for it making it meaningful economic activity.

[akundaz]

I think that framing the public mempool and bundle mempool with separate budgets is the correct model, as they are very different resources from the builder perspective (because of revert protection)

I don't agree with this. The resource we are protecting is the builder's compute budget. So it doesn't matter what the source of a tx is.

Users hitting bundle limits will not send the same volume of orders through eth_sendRawTransaction, and even if they do they'll have to pay for it making it meaningful economic activity

Then this begs the question, why have limits for txs sent through eth_sendRawTransaction at all?

I want to reiterate though the important piece we're missing here is actually data on order flow from eth_sendRawTransaction being throttled, or when it may be at risk of being throttled.

[SozinM]

Then this begs the question, why have limits for txs sent through eth_sendRawTransaction at all?

Agree, eth_sendRawTransaction limiting must be removed, as it already have proper handling mechanism (on chain gas)

[avalonche]

The scope of this change is not whether we should be adding limits to eth_sendRawTransaction, but having more granular control on the limits between existing eth_sendRawTransaction limits and bundles. We can target limits on bundles much more aggressively, though I agree eth_sendRawTransaction limiting is probably not needed