Merge pull request #2956 from OffchainLabs/tw-612-speed-limit-to-gas-target

docs: tw-512-speed-limit-to-gas-target

Author: pete-vielhaber

docs/build-decentralized-apps/reference/03-chain-params.mdx

@@ -11,6 +11,6 @@ displayed_sidebar: buildAppsSidebar
 | Dispute window       | Time for assertions to get confirmed during which validators can issue a challenge                        | @@arbOneDisputeWindowBlocks=45818@@ blocks (~ @@arbOneDisputeWindowDays=6.4@@ days )        | @@novaDisputeWindowBlocks=45818@@ blocks (~ @@novaDisputeWindowDays=6.4@@ days)         | @@sepoliaDisputeWindowBlocks=20@@ blocks (~ @@sepoliaDisputeWindowMinutes=4.0@@ minutes)      |
 | Minimum bond amount  | Amount of funds required for a validator to propose assertion on the parent chain                         | @@arbOneBaesStakeEth=3600@@ ETH                                                             | @@novaBaesStakeEth=1@@ ETH                                                              | @@sepoliaBaesStakeEth=1@@ Sepolia ETH                                                         |
 | Force-include period | Period after which a delayed message can be included into the inbox without any action from the Sequencer | @@arbOneForceIncludePeriodBlocks=5760@@ blocks / @@arbOneForceIncludePeriodHours=24@@ hours | @@novaForceIncludePeriodBlocks=5760@@ blocks / @@novaForceIncludePeriodHours=24@@ hours | @@sepoliaForceIncludePeriodBlocks=5760@@ blocks / @@sepoliaForceIncludePeriodHours=24@@ hours |
-| Gas speed limit      | Target gas/sec, over which the congestion mechanism activates                                             | @@arbOneGasSpeedLimitGasPerSec=7,000,000@@ gas/sec                                          | @@novaGasSpeedLimitGasPerSec=7,000,000@@ gas/sec                                        | @@sepoliaGasSpeedLimitGasPerSec=7,000,000@@ gas/sec                                           |
+| Gas target           | Target gas/sec, over which the congestion mechanism activates                                             | @@arbOneGasSpeedLimitGasPerSec=7,000,000@@ gas/sec                                          | @@novaGasSpeedLimitGasPerSec=7,000,000@@ gas/sec                                        | @@sepoliaGasSpeedLimitGasPerSec=7,000,000@@ gas/sec                                           |
 | Gas price floor      | Minimum gas price                                                                                         | @@arbOneGasFloorGwei=0.01@@ gwei                                                            | @@novaGasFloorGwei=0.01@@ gwei                                                          | @@sepoliaGasFloorGwei=0.1@@ gwei                                                              |
 | Block gas limit      | Maximum amount of gas that all the transactions inside a block are allowed to consume                     | @@arbOneBlockGasLimit=32,000,000@@                                                          | @@novaBlockGasLimit=32,000,000@@                                                        | @@sepoliaBlockGasLimit=32,000,000@@                                                           |

docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbGasInfo.mdx

@@ -118,7 +118,7 @@
           Implementation
         </a>
       </td>
-      <td>GetGasAccountingParams gets the rollup's speed limit, pool size, and block gas limit</td>
+      <td>GetGasAccountingParams gets the Rollup's gas target, pool size, and block gas limit</td>
     </tr>
     <tr>
       <td>
@@ -320,7 +320,7 @@
           Implementation
         </a>
       </td>
-      <td>GetGasBacklog gets the backlogged amount of gas burnt in excess of the speed limit</td>
+      <td>GetGasBacklog gets the backlogged amount of gas burnt in excess of the gas target</td>
     </tr>
     <tr>
       <td>

docs/for-devs/dev-tools-and-resources/partials/precompile-tables/_ArbOwner.mdx

@@ -294,7 +294,7 @@
           Implementation
         </a>
       </td>
-      <td>SetSpeedLimit sets the computational speed limit for the chain</td>
+      <td>SetSpeedLimit sets the computational gas target for the chain</td>
     </tr>
     <tr>
       <td>

docs/how-arbitrum-works/01-inside-arbitrum-nitro.mdx

@@ -97,9 +97,9 @@ The canonical bridge architecture comprises asset contracts on both chains, gate
 
 Fees accumulate across the transaction lifecycle to fund processing and security. Arbitrum's dual-fee model separates child chain gas fees, which cover EVM computation and storage with [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)-style dynamic pricing targeting 7,000,000 gas per second on Arbitrum One, adjusting for congestion, from Parent chain calldata fees. Parent chain calldata fees account for Ethereum data posting based on compressed batch contributions and apply only to Sequencer submissions. For comprehensive details on how parent chain pricing works, including the adaptive pricing algorithm and cost apportionment, see the [Parent chain pricing deep dive](/how-arbitrum-works/deep-dives/parent-chain-pricing.mdx). For a complete breakdown of how fees are calculated and collected, including both parent and child chain components, refer to the [Gas and fees deep dive](/how-arbitrum-works/deep-dives/gas-and-fees.mdx).
 
-A gas speed limit protects infrastructure by capping throughput at 7,000,000 gas per second for Arbitrum One and Nova. Exceeding this triggers [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) fee escalations to prevent node overloads and maintain liveness. This limit prioritizes high-value transactions during peaks while deterring spam, ensuring that validators and the Sequencer stay operational for optimal performance, even though parent contracts handle ultimate security.
+A gas target protects infrastructure by capping throughput at 7,000,000 gas per second for Arbitrum One and Nova. Exceeding this triggers [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) fee escalations to prevent node overloads and maintain liveness. This limit prioritizes high-value transactions during peaks while deterring spam, ensuring that validators and the Sequencer stay operational for optimal performance, even though parent contracts handle ultimate security.
 
-Fee calculation during execution involves assessing child chain gas via EVM standards, estimating parent chain batch impact, applying current pricing, and collecting `ETH` totals. This model covers all costs effectively, with the speed limit reinforcing security by keeping validation in sync.
+Fee calculation during execution involves assessing child chain gas via EVM standards, estimating parent chain batch impact, applying current pricing, and collecting `ETH` totals. This model covers all costs effectively, with the gas target reinforcing security by keeping validation in sync.
 
 ### Step 8: Advanced features
 

docs/how-arbitrum-works/deep-dives/arbos.mdx

@@ -81,7 +81,7 @@ For more details about darent chain pricing, see [Parent chain pricing](/how-arb
 
 ### [`l2PricingState`](https://github.com/OffchainLabs/nitro/blob/fa36a0f138b8a7e684194f9840315d80c390f324/arbos/l2pricing/l2pricing.go#L14)
 
-The child chain pricing state tracks child chain resource usage to determine a reasonable child chain gas price. This process considers various factors, including user demand, the state of Geth, and the computational <a data-quicklook-from="speed-limit">speed limit</a>. The primary mechanism for doing so consists of a pair of pools, one larger than the other, that drain as child chain–specific resources are consumed and filled as time passes. Parent chain-specific resources, such as parent chain `calldata`, are not accounted for in the pools since they do not directly impact the computational workload of network actors. Instead, the design of the speed limit mechanism regulates execution resources to ensure consistent system performance and synchronization.
+The child chain pricing state tracks child chain resource usage to determine a reasonable child chain gas price. This process considers various factors, including user demand, the state of Geth, and the computational gas target. The primary mechanism for doing so consists of a pair of pools, one larger than the other, that drain as child chain–specific resources are consumed and filled as time passes. Parent chain-specific resources, such as parent chain `calldata`, are not accounted for in the pools since they do not directly impact the computational workload of network actors. Instead, the design of the gas target mechanism regulates execution resources to ensure consistent system performance and synchronization.
 
 While much of this state is accessible through the [`ArbGasInfo`](/build-decentralized-apps/precompiles/02-reference.mdx#arbgasinfo) and [`ArbOwner`](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner) precompiles, most changes are automatic and happen during [block production](https://github.com/OffchainLabs/nitro/blob/fa36a0f138b8a7e684194f9840315d80c390f324/arbos/block_processor.go#L77) and the [transaction hooks](/how-arbitrum-works/deep-dives/geth.mdx#hooks). Each transaction in an incoming message removes the parent chain component of the gas it consumes from the pool. Afterward, the message's timestamp [informs the pricing mechanism](https://github.com/OffchainLabs/nitro/blob/fa36a0f138b8a7e684194f9840315d80c390f324/arbos/block_processor.go#L336) of the time passed as ArbOS [finalizes the block](https://github.com/OffchainLabs/nitro/blob/fa36a0f138b8a7e684194f9840315d80c390f324/arbos/block_processor.go#L350).
 
@@ -105,7 +105,7 @@ Child chain gas fees work very similarly to gas on Ethereum. The amount of gas i
 
 The child chain basefee is set by a version of the "exponential mechanism" widely discussed in the Ethereum community and shown to be equivalent to Ethereum's EIP-1559 gas pricing mechanism.
 
-The algorithm compares gas usage against the [speed limit](/how-arbitrum-works/deep-dives/gas-and-fees.mdx#the-speed-limit) parameter —the target amount of gas per second that the chain can sustainably handle over time. (The speed limit on Arbitrum One is 7,000,000 gas per second.) The algorithm tracks a gas backlog. Whenever a transaction consumes gas, it gets added to the backlog. Whenever the clock ticks a second, the speed limit is subtracted from the backlog, but the backlog can never go below zero.
+The algorithm compares gas usage against the [gas target](/how-arbitrum-works/deep-dives/gas-and-fees.mdx#the-gas-target) parameter —the target amount of gas per second that the chain can sustainably handle over time. (The gas target on Arbitrum One is 7,000,000 gas per second.) The algorithm tracks a gas backlog. Whenever a transaction consumes gas, it gets added to the backlog. Whenever the clock ticks a second, the gas target is subtracted from the backlog, but the backlog can never go below zero.
 
 Intuitively, if the backlog grows, the algorithm should increase the gas price to slow gas usage because usage is above the sustainable level. If the backlog shrinks, the price should decrease again because usage has been below the sustainable limit, so more gas usage can be welcomed.
 
@@ -123,13 +123,13 @@ Because a call to `redeem` consumes all the call's gas, doing multiple calls req
 
 Gas estimation for retryable submissions is possible via the [`NodeInterface`](/build-decentralized-apps/nodeinterface/02-reference.mdx) and similarly requires the auto-redeem attempt to succeed.
 
-## The speed limit
+## The gas target
 
 The security of Nitro chains depends on the assumption that when one <a data-quicklook-from="validator">validator</a> creates an <a data-quicklook-from="assertion">assertion</a>, other validators will check it and respond with a correct assertion and a <a data-quicklook-from="challenge">challenge</a> if it is wrong. This assumption requires that the other validators have the time and resources to check each assertion and issue a timely challenge quickly. The Arbitrum protocol accounts for this when setting deadlines for assertions.
 
-This approach sets an effective speed limit on execution of a Nitro chain: in the long run, the chain cannot make progress faster than a validator can emulate its execution. If assertions are published faster than the speed limit, their deadlines will get farther and farther into the future. Due to the Rollup protocol's limit on how far a deadline can be in the future, this will eventually slow new assertions, thereby enforcing the effective speed limit.
+This approach sets an effective gas target on execution of a Nitro chain: in the long run, the chain cannot make progress faster than a validator can emulate its execution. If assertions are published faster than the gas target, their deadlines will get farther and farther into the future. Due to the Rollup protocol's limit on how far a deadline can be in the future, this will eventually slow new assertions, thereby enforcing the effective gas target.
 
-Being able to set the speed limit accurately depends on estimating the time required to validate an assertion with some accuracy. Any uncertainty in estimating validation time will force us to lower the speed limit to be safe. We do not want to lower the speed limit, so we try to enable accurate estimation.
+Being able to set the gas target accurately depends on estimating the time required to validate an assertion with some accuracy. Any uncertainty in estimating validation time will force us to lower the gas target to be safe. We do not want to lower the gas target, so we try to enable accurate estimation.
 
 ## Stylus-specific differences
 

docs/how-arbitrum-works/deep-dives/gas-and-fees.mdx

@@ -72,7 +72,7 @@ Child chain gas fees work very similarly to gas on Ethereum. A transaction uses
 
 The child chain basefee is set by a version of the "exponential mechanism" which has been widely discussed in the Ethereum community, and which has been shown equivalent to Ethereum's EIP-1559 gas pricing mechanism.
 
-The algorithm compares gas usage against a parameter called the [speed limit](#the-speed-limit) which is the target amount of gas per second that the chain can handle sustainably over time. (Currently the <a data-quicklook-from="speed-limit">Speed Limit</a> on Arbitrum One is @@arbOneGasSpeedLimitGasPerSec=7,000,000@@ gas per second.) The algorithm tracks a gas backlog. Whenever a transaction consumes gas, that gas is added to the backlog. Whenever the clock ticks one second, the speed limit is subtracted from the backlog; but the backlog can never go below zero.
+The algorithm compares gas usage against a parameter called the [gas target](#the-gas-target) which is the target amount of gas per second that the chain can handle sustainably over time. (Currently the gas target on Arbitrum One is @@arbOneGasSpeedLimitGasPerSec=7,000,000@@ gas per second.) The algorithm tracks a gas backlog. Whenever a transaction consumes gas, that gas is added to the backlog. Whenever the clock ticks one second, the gas target is subtracted from the backlog; but the backlog can never go below zero.
 
 Intuitively, if the backlog grows, the algorithm should increase the gas price, to slow gas usage, because usage is above the sustainable level. If the backlog shrinks, the price should decrease again because usage has been below the below the sustainable limit so more gas usage can be welcomed.
 
@@ -90,13 +90,13 @@ Because a call to [`redeem`](/build-decentralized-apps/precompiles/02-reference.
 
 Gas estimation for Retryable submissions is possible via the [NodeInterface](/build-decentralized-apps/nodeinterface/02-reference.mdx) and similarly requires the auto-redeem attempt to succeed.
 
-### The Speed Limit
+### The gas target
 
 The security of Nitro chains depends on the assumption that when one <a data-quicklook-from="validator">validator</a> creates an assertion, other validators will check it, and respond with a correct assertion and a <a data-quicklook-from="challenge">challenge</a> if it is wrong. This requires that the other validators have the time and resources to check each assertion quickly enough to issue a timely challenge. The Arbitrum protocol takes this into account in setting deadlines for assertions.
 
-This sets an effective speed limit on execution of a Nitro chain: in the long run the chain cannot make progress faster than a validator can emulate its execution. If assertions are published at a rate faster than the speed limit, their deadlines will get farther and farther in the future. Due to the limit, enforced by the Rollup protocol contracts, on how far in the future a deadline can be, this will eventually cause new assertions to be slowed down, thereby enforcing the effective speed limit.
+This sets an effective gas target on execution of a Nitro chain: in the long run the chain cannot make progress faster than a validator can emulate its execution. If assertions are published at a rate faster than the gas target, their deadlines will get farther and farther in the future. Due to the limit, enforced by the Rollup protocol contracts, on how far in the future a deadline can be, this will eventually cause new assertions to be slowed down, thereby enforcing the effective gas target.
 
-Being able to set the speed limit accurately depends on being able to estimate the time required to validate an assertion, with some accuracy. Any uncertainty in estimating validation time will force us to set the speed limit lower, to be safe. And we do not want to set the speed limit lower, so we try to enable accurate estimation.
+Being able to set the gas target accurately depends on being able to estimate the time required to validate an assertion, with some accuracy. Any uncertainty in estimating validation time will force us to set the gas target lower, to be safe. And we do not want to set the gas target lower, so we try to enable accurate estimation.
 
 ## Total fee and gas estimation
 

docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/06-gas-optimization-tools.mdx

@@ -10,7 +10,7 @@ To configure gas behavior on an Arbitrum chain using the [Chain SDK](https://git
 
 Below is a breakdown of each specified parameter, including its role, typical defaults (based on Arbitrum One), and how to configure it. Note that changes may require careful consideration to avoid impacting chain performance, user experience, or security. For example, setting limits too high could lead to state bloat or slower block processing.
 
-## Gas speed limit
+## Gas target
 
 - **Description**: This is the target gas consumption rate per second that the chain can sustainably handle. It influences the congestion mechanism: if gas usage exceeds this limit, the base fee rises to throttle demand; if below the limit, the cost decreases (down to the floor). ArbOS uses this to update gas pools and enforce dynamic per-block gas limits.
 - **Default**: 7,000,000 gas/second.
@@ -28,7 +28,7 @@ Refer to the [Chain parameters](/build-decentralized-apps/reference/03-chain-par
 
 ## Block gas limit
 
-- **Description**: This limits the maximum amount consumable by all transactions in a single L2 block—for execution, not for the parent chain data availability (DA) fee charge. It helps control block size and processing time. In practice, ArbOS enforces a dynamic limit based on the speed limit and gas pools, but this sets a hard cap.
+- **Description**: This limits the maximum amount consumable by all transactions in a single L2 block—for execution, not for the parent chain data availability (DA) fee charge. It helps control block size and processing time. In practice, ArbOS enforces a dynamic limit based on the gas target and gas pools, but this sets a hard cap.
 - **Default**: 32,000,000 gas per block.
 - **Configuration**: Call the [`setMaxTxGasLimit(uint256 newLimit)`](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner) method on the [`ArbOwner` precompile](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner), where `newLimit` is the desired max gas. This method is described as setting the block limit, although technically it may focus on per-transaction limits; in practice, it caps block usage.