From e526f679c527df139629dafa67c9522a5347ae27 Mon Sep 17 00:00:00 2001 From: dzgoldman Date: Fri, 1 Sep 2023 15:13:59 -0400 Subject: [PATCH 1/4] add chain params --- arbitrum-docs/arbos/gas.mdx | 2 +- .../devs-how-tos/how-to-estimate-gas.mdx | 2 +- arbitrum-docs/for-devs/chain-params.mdx | 15 ++++ .../inside-arbitrum-nitro.mdx | 4 +- arbitrum-docs/sequencer.mdx | 2 +- arbitrum-docs/tx-lifecycle.mdx | 2 +- website/sidebars.js | 5 ++ website/src/resources/globalVars.js | 68 +++++++++++++++++++ 8 files changed, 94 insertions(+), 6 deletions(-) create mode 100644 arbitrum-docs/for-devs/chain-params.mdx diff --git a/arbitrum-docs/arbos/gas.mdx b/arbitrum-docs/arbos/gas.mdx index d45ead7ef..821f319ec 100644 --- a/arbitrum-docs/arbos/gas.mdx +++ b/arbitrum-docs/arbos/gas.mdx @@ -11,7 +11,7 @@ The L2 component consists of the traditional fees Geth would pay to stakers in a ## Gas Price Floor -The L2 gas price on a given Arbitrum chain has a set floor, which can be queried via [ArbGasInfo](/for-devs/dev-tools-and-resources/precompiles.mdx#arbgasinfo)'s `getMinimumGasPrice` method (currently 0.1 gwei on Arbitrum One and 0.01 gwei on Nova). +The L2 gas price on a given Arbitrum chain has a set floor, which can be queried via [ArbGasInfo](/for-devs/dev-tools-and-resources/precompiles.mdx#arbgasinfo)'s `getMinimumGasPrice` method (currently @arbOneGasFloorGwei@ gwei on Arbitrum One and @novaGasFloorGwei@ gwei on Nova). ## Estimating Gas diff --git a/arbitrum-docs/devs-how-tos/how-to-estimate-gas.mdx b/arbitrum-docs/devs-how-tos/how-to-estimate-gas.mdx index d23b6cba5..fcf92bf70 100644 --- a/arbitrum-docs/devs-how-tos/how-to-estimate-gas.mdx +++ b/arbitrum-docs/devs-how-tos/how-to-estimate-gas.mdx @@ -57,7 +57,7 @@ TXFEES = P * (L2G + ((L1P * L1S) / P)) We'll use one resource available in Arbitrum: the [NodeInterface](/arbos/gas.mdx#nodeinterfacesol). -- P (L2 Gas Price) ⇒ Price to pay for each gas unit. It starts at 0.1 gwei on Arbitrum One (0.01 gwei on Arbitrum Nova) and can increase depending on the demand for network resources. +- P (L2 Gas Price) ⇒ Price to pay for each gas unit. It starts at @arbOneGasFloorGwei@ gwei on Arbitrum One (@novaGasFloorGwei gwei on Arbitrum Nova) and can increase depending on the demand for network resources. - Call `NodeInterface.GasEstimateComponents()` and get the third element, `baseFee`. - L2G (Gas used on L2) ⇒ Gas used to compute the transaction on L2. This does not include the _“posting on L1”_ part of the calculations. The value of L2G will depend on the transaction itself, but having the data of the transaction, we can calculate it as follows: - Call `NodeInterface.GasEstimateComponents()` with the transaction data and subtract the second element (`gasEstimateForL1`, which estimates the L1 part of the fees) from the first (`gasEstimate`, which includes both the L1 and the L2 parts). diff --git a/arbitrum-docs/for-devs/chain-params.mdx b/arbitrum-docs/for-devs/chain-params.mdx new file mode 100644 index 000000000..c3e0b91eb --- /dev/null +++ b/arbitrum-docs/for-devs/chain-params.mdx @@ -0,0 +1,15 @@ +--- +title: 'Chain Parameters' +sidebar_label: Chain Params +description: Information about important system parameters for public Arbitrum chains +reader-audience: developers who want to build on Ethereum/Arbitrum +content-type: overview +--- + +| Param | Description | Arbitrum One | Nova | Arb Goerli | Arb Sepolia | +| -------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | +| Dispute Window | Time for until assertions get confirmed during which validaors can issue a challenge | @arbOneDisputeWindowBlocks@ blocks (~ @arbOneDisputeWindowDays@ days ) | @novaDisputeWindowBlocks@ blocks (~ @novaDisputeWindowDays@ days) | @goerliDisputeWindowBlocks@ blocks (~ @goerliDisputeWindowMinutes@ minutes) | @sepoliaDisputeWindowBlocks@ blocks (~ @sepoliaDisputeWindowMinutes@ minutes) | +| Base Stake | Amount of stake required for a validator to make an assertion | @arbOneBaesStakeEth@ ETH | @novaBaesStakeEth@ ETH | @goerliBaesStakeEth@ Goerli ETH | @sepoliaBaesStakeEth@ Sepolia ETH | +| Force-Include Period | Period after which a delayed message can be included into the inbox without any action from the Sequencer | @arbOneForceIncludePeriodBlocks@ blocks / @arbOneForceIncludePeriodHours@ hours | @novaForceIncludePeriodBlocks@ blocks / @novaForceIncludePeriodHours@ hours | @goerliForceIncludePeriodBlocks@ blocks / @goerliForceIncludePeriodHours@ hours | @sepoliaForceIncludePeriodBlocks@ blocks / @sepoliaForceIncludePeriodHours@ hours | +| Gas Speed Limit | Target gas/sec, over which the congestion mechanism activates | @arbOneGasSpeedLimitGasPerSec@ gas/sec | @novaGasSpeedLimitGasPerSec@ gas/sec | @goerliGasSpeedLimitGasPerSec@ gas/sec | @sepoliaGasSpeedLimitGasPerSec@ gas/sec | +| Gas Price Floor | Minimum gas price | @arbOneGasFloorGwei@ gwei | @novaGasFloorGwei@ gwei | @goerliGasFloorGwei@ gwei | @sepoliaGasFloorGwei@ gwei | diff --git a/arbitrum-docs/inside-arbitrum-nitro/inside-arbitrum-nitro.mdx b/arbitrum-docs/inside-arbitrum-nitro/inside-arbitrum-nitro.mdx index e3a6bdeaf..7a5c282fa 100644 --- a/arbitrum-docs/inside-arbitrum-nitro/inside-arbitrum-nitro.mdx +++ b/arbitrum-docs/inside-arbitrum-nitro/inside-arbitrum-nitro.mdx @@ -418,7 +418,7 @@ When we add a Sequencer, the operation of the inbox changes. - Only the Sequencer can put new messages directly into the inbox. The Sequencer tags the messages it is submitting with an Ethereum block number and timestamp. (ArbOS ensures that these are non-decreasing, adjusting them upward if necessary to avoid decreases.) - Anyone else can submit a message, but messages submitted by non-Sequencer nodes will be put into the "delayed inbox" queue, which is managed by an L1 Ethereum contract. - Messages in the delayed inbox queue will wait there until the Sequencer chooses to "release" them into the main inbox, where they will be added to the end of the inbox. A well-behaved Sequencer will typically release delayed messages after about ten minutes, for reasons explained below. - - Alternatively, if a message has been in the delayed inbox queue for longer than a maximum delay interval (currently 24 hours) then anyone can force it to be promoted into the main inbox. (This ensures that the Sequencer can only delay messages but can't censor them.) + - Alternatively, if a message has been in the delayed inbox queue for longer than a maximum delay interval (currently @arbOneForceIncludePeriodHours@ on Arbitrum One) then anyone can force it to be promoted into the main inbox. (This ensures that the Sequencer can only delay messages but can't censor them.) ### If the Sequencer is well-behaved... @@ -510,7 +510,7 @@ L2 gas fees work very similarly to gas on Ethereum. A transaction uses some amou The L2 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" which is the target amount of gas per second that the chain can handle sustainably over time. (Currently the speed limit is 7 million 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 "speed limit" which is the target amount of gas per second that the chain can handle sustainably over time. (Currently the speed limit on Arbitrum One is @arbOneGasSpeedLimitGasPerSec@ 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. 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. diff --git a/arbitrum-docs/sequencer.mdx b/arbitrum-docs/sequencer.mdx index a1dd9242e..72f74642b 100644 --- a/arbitrum-docs/sequencer.mdx +++ b/arbitrum-docs/sequencer.mdx @@ -27,7 +27,7 @@ First, they submit their L2 message via L1 into the delayed Inbox as described a Once in the delayed Inbox, we obviously can’t rely on the Sequencer to include the transaction in a batch. Instead, we can use `SequencerInbox`’s `forceInclusion` method. Once a message has been in the delayed Inbox for a sufficient amount of time, `forceInclusion` can be called to move it from the delayed Inbox into the core Inbox, at which point it’s finalized. Crucially, any account can call `forceInclusion`. -Currently, on Arbitrum One, this delay time between submission and force inclusion is roughly 24 hours, as specified by `maxTimeVariation.delayBlocks` / `maxTimeVariation.delaySeconds`. A force inclusion from L1 would directly affect the state for any unconfirmed L2 transactions; keeping conservatively high delay value ensures it should only be used under extraordinary circumstances. +Currently, on Arbitrum One, this delay time between submission and force inclusion is roughly @arbOneForceIncludePeriodHours hours, as specified by `maxTimeVariation.delayBlocks` / `maxTimeVariation.delaySeconds`. A force inclusion from L1 would directly affect the state for any unconfirmed L2 transactions; keeping conservatively high delay value ensures it should only be used under extraordinary circumstances. On top of the delay itself, the `forceInclusion` path has the downside of uncertainty around transaction ordering; i.e., while waiting for a message's max delay to pass, a malicious Sequencer could, in principle, directly post messages in front of it. However, there’s ultimately nothing the Sequencer can do to stop it from being included in the core Inbox, at which point its ordering is finalized. diff --git a/arbitrum-docs/tx-lifecycle.mdx b/arbitrum-docs/tx-lifecycle.mdx index 0d01a0958..c0a95cba5 100644 --- a/arbitrum-docs/tx-lifecycle.mdx +++ b/arbitrum-docs/tx-lifecycle.mdx @@ -56,7 +56,7 @@ The Sequencer will eventually post a batch of L2 transactions which includes our ##### 3a. What if the Sequencer never includes our transaction? -Even if the Sequencer never includes our transaction in a batch, the client can include it in the L2 by posting in the delayed inbox and then "force including" it after some delay period (currently ~24 hours on Arbitrum One). +Even if the Sequencer never includes our transaction in a batch, the client can include it in the L2 by posting in the delayed inbox and then "force including" it after some delay period (currently ~ @arbOneForceIncludePeriodHours@ hours on Arbitrum One). :::note diff --git a/website/sidebars.js b/website/sidebars.js index ec26dfcd9..ca7c9137c 100644 --- a/website/sidebars.js +++ b/website/sidebars.js @@ -295,6 +295,11 @@ const sidebars = { label: 'Smart contract addresses', id: 'for-devs/useful-addresses', }, + { + type: 'doc', + label: 'Chain Params', + id: 'for-devs/chain-params', + }, { type: 'doc', label: 'Precompiles', diff --git a/website/src/resources/globalVars.js b/website/src/resources/globalVars.js index 8f6b20334..fb33aeaa0 100644 --- a/website/src/resources/globalVars.js +++ b/website/src/resources/globalVars.js @@ -1,3 +1,15 @@ +const L1_BLOCK_TIME_SECONDS = 12.1; + +const arbOneDisputeWindowBlocks = 45818; +const novaDisputeWindowBlocks = 45818; +const goerliDisputeWindowBlocks = 20; +const sepoliaDisputeWindowBlocks = 20; + +const arbOneForceIncludePeriodBlocks = 5760; +const novaForceIncludePeriodBlocks = 5760; +const goerliForceIncludePeriodBlocks = 5760; +const sepoliaForceIncludePeriodBlocks = 5760; + const globalVars = { // Node docker images latestNitroNodeImage: 'offchainlabs/nitro-node:v2.0.14-2baa834', @@ -23,6 +35,62 @@ const globalVars = { nitroContractsRepositorySlug: 'nitro', nitroContractsCommit: 'v2.0.14', nitroContractsPathToPrecompilesInterface: 'contracts/src/precompiles', + + // gas floor + arbOneGasFloorGwei: '0.1', + novaGasFloorGwei: '0.01', + goerliGasFloorGwei: '0.1', + sepoliaGasFloorGwei: '0.1', + + // dispute window + arbOneDisputeWindowBlocks, + novaDisputeWindowBlocks, + goerliDisputeWindowBlocks, + sepoliaDisputeWindowBlocks, + + arbOneDisputeWindowDays: blocksToDays(arbOneDisputeWindowBlocks), + novaDisputeWindowDays: blocksToDays(novaDisputeWindowBlocks), + goerliDisputeWindowMinutes: blocksToMinutes(goerliDisputeWindowBlocks), + sepoliaDisputeWindowMinutes: blocksToMinutes(sepoliaDisputeWindowBlocks), + + // base stake + arbOneBaesStakeEth: 1, + novaBaesStakeEth: 1, + goerliBaesStakeEth: 1, + sepoliaBaesStakeEth: 1, + + // force include period + + arbOneForceIncludePeriodBlocks, + novaForceIncludePeriodBlocks, + goerliForceIncludePeriodBlocks, + sepoliaForceIncludePeriodBlocks, + + arbOneForceIncludePeriodHours: secondsToHours(86400), + novaForceIncludePeriodHours: secondsToHours(86400), + goerliForceIncludePeriodHours: secondsToHours(86400), + sepoliaForceIncludePeriodHours: secondsToHours(86400), + + // speed limit + arbOneGasSpeedLimitGasPerSec: '7,000,000', + novaGasSpeedLimitGasPerSec: '7,000,000', + goerliGasSpeedLimitGasPerSec: '3,000,000', + sepoliaGasSpeedLimitGasPerSec: '7,000,000', }; +function blocksToMinutes(blocks) { + return ((blocks * L1_BLOCK_TIME_SECONDS) / 60).toFixed(1); +} + +function blocksToHours(blocks) { + return ((blocks * L1_BLOCK_TIME_SECONDS) / (60 * 60)).toFixed(1); +} +function blocksToDays(blocks) { + return ((blocks * L1_BLOCK_TIME_SECONDS) / (60 * 60 * 24)).toFixed(1); +} + +function secondsToHours(seconds) { + return seconds / (60 * 60); +} + module.exports = globalVars; From f7ba5e8e84abdb67df457848339547fb6b530da9 Mon Sep 17 00:00:00 2001 From: dzgoldman Date: Fri, 1 Sep 2023 15:15:22 -0400 Subject: [PATCH 2/4] fix typo --- arbitrum-docs/sequencer.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arbitrum-docs/sequencer.mdx b/arbitrum-docs/sequencer.mdx index 72f74642b..8bdfdea2d 100644 --- a/arbitrum-docs/sequencer.mdx +++ b/arbitrum-docs/sequencer.mdx @@ -27,7 +27,7 @@ First, they submit their L2 message via L1 into the delayed Inbox as described a Once in the delayed Inbox, we obviously can’t rely on the Sequencer to include the transaction in a batch. Instead, we can use `SequencerInbox`’s `forceInclusion` method. Once a message has been in the delayed Inbox for a sufficient amount of time, `forceInclusion` can be called to move it from the delayed Inbox into the core Inbox, at which point it’s finalized. Crucially, any account can call `forceInclusion`. -Currently, on Arbitrum One, this delay time between submission and force inclusion is roughly @arbOneForceIncludePeriodHours hours, as specified by `maxTimeVariation.delayBlocks` / `maxTimeVariation.delaySeconds`. A force inclusion from L1 would directly affect the state for any unconfirmed L2 transactions; keeping conservatively high delay value ensures it should only be used under extraordinary circumstances. +Currently, on Arbitrum One, this delay time between submission and force inclusion is roughly @arbOneForceIncludePeriodHours@ hours, as specified by `maxTimeVariation.delayBlocks` / `maxTimeVariation.delaySeconds`. A force inclusion from L1 would directly affect the state for any unconfirmed L2 transactions; keeping conservatively high delay value ensures it should only be used under extraordinary circumstances. On top of the delay itself, the `forceInclusion` path has the downside of uncertainty around transaction ordering; i.e., while waiting for a message's max delay to pass, a malicious Sequencer could, in principle, directly post messages in front of it. However, there’s ultimately nothing the Sequencer can do to stop it from being included in the core Inbox, at which point its ordering is finalized. From e1426e60019b3909d9945b64613b6157a7f0573d Mon Sep 17 00:00:00 2001 From: dzgoldman Date: Fri, 1 Sep 2023 15:17:22 -0400 Subject: [PATCH 3/4] fix typos --- arbitrum-docs/devs-how-tos/how-to-estimate-gas.mdx | 2 +- arbitrum-docs/inside-arbitrum-nitro/inside-arbitrum-nitro.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arbitrum-docs/devs-how-tos/how-to-estimate-gas.mdx b/arbitrum-docs/devs-how-tos/how-to-estimate-gas.mdx index fcf92bf70..b1101fc3e 100644 --- a/arbitrum-docs/devs-how-tos/how-to-estimate-gas.mdx +++ b/arbitrum-docs/devs-how-tos/how-to-estimate-gas.mdx @@ -57,7 +57,7 @@ TXFEES = P * (L2G + ((L1P * L1S) / P)) We'll use one resource available in Arbitrum: the [NodeInterface](/arbos/gas.mdx#nodeinterfacesol). -- P (L2 Gas Price) ⇒ Price to pay for each gas unit. It starts at @arbOneGasFloorGwei@ gwei on Arbitrum One (@novaGasFloorGwei gwei on Arbitrum Nova) and can increase depending on the demand for network resources. +- P (L2 Gas Price) ⇒ Price to pay for each gas unit. It starts at @arbOneGasFloorGwei@ gwei on Arbitrum One (@novaGasFloorGwei@ gwei on Arbitrum Nova) and can increase depending on the demand for network resources. - Call `NodeInterface.GasEstimateComponents()` and get the third element, `baseFee`. - L2G (Gas used on L2) ⇒ Gas used to compute the transaction on L2. This does not include the _“posting on L1”_ part of the calculations. The value of L2G will depend on the transaction itself, but having the data of the transaction, we can calculate it as follows: - Call `NodeInterface.GasEstimateComponents()` with the transaction data and subtract the second element (`gasEstimateForL1`, which estimates the L1 part of the fees) from the first (`gasEstimate`, which includes both the L1 and the L2 parts). diff --git a/arbitrum-docs/inside-arbitrum-nitro/inside-arbitrum-nitro.mdx b/arbitrum-docs/inside-arbitrum-nitro/inside-arbitrum-nitro.mdx index 7a5c282fa..bf2d0d56e 100644 --- a/arbitrum-docs/inside-arbitrum-nitro/inside-arbitrum-nitro.mdx +++ b/arbitrum-docs/inside-arbitrum-nitro/inside-arbitrum-nitro.mdx @@ -418,7 +418,7 @@ When we add a Sequencer, the operation of the inbox changes. - Only the Sequencer can put new messages directly into the inbox. The Sequencer tags the messages it is submitting with an Ethereum block number and timestamp. (ArbOS ensures that these are non-decreasing, adjusting them upward if necessary to avoid decreases.) - Anyone else can submit a message, but messages submitted by non-Sequencer nodes will be put into the "delayed inbox" queue, which is managed by an L1 Ethereum contract. - Messages in the delayed inbox queue will wait there until the Sequencer chooses to "release" them into the main inbox, where they will be added to the end of the inbox. A well-behaved Sequencer will typically release delayed messages after about ten minutes, for reasons explained below. - - Alternatively, if a message has been in the delayed inbox queue for longer than a maximum delay interval (currently @arbOneForceIncludePeriodHours@ on Arbitrum One) then anyone can force it to be promoted into the main inbox. (This ensures that the Sequencer can only delay messages but can't censor them.) + - Alternatively, if a message has been in the delayed inbox queue for longer than a maximum delay interval (currently @arbOneForceIncludePeriodHours@ hours on Arbitrum One) then anyone can force it to be promoted into the main inbox. (This ensures that the Sequencer can only delay messages but can't censor them.) ### If the Sequencer is well-behaved... From c259b569d23f788473ca75b29f93535ddfbfc3d7 Mon Sep 17 00:00:00 2001 From: dzgoldman Date: Tue, 5 Sep 2023 11:44:09 -0400 Subject: [PATCH 4/4] use sentence casing --- arbitrum-docs/for-devs/chain-params.mdx | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arbitrum-docs/for-devs/chain-params.mdx b/arbitrum-docs/for-devs/chain-params.mdx index c3e0b91eb..bd2d9eb6e 100644 --- a/arbitrum-docs/for-devs/chain-params.mdx +++ b/arbitrum-docs/for-devs/chain-params.mdx @@ -1,6 +1,6 @@ --- -title: 'Chain Parameters' -sidebar_label: Chain Params +title: 'Chain parameters' +sidebar_label: Chain params description: Information about important system parameters for public Arbitrum chains reader-audience: developers who want to build on Ethereum/Arbitrum content-type: overview @@ -8,8 +8,8 @@ content-type: overview | Param | Description | Arbitrum One | Nova | Arb Goerli | Arb Sepolia | | -------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | -| Dispute Window | Time for until assertions get confirmed during which validaors can issue a challenge | @arbOneDisputeWindowBlocks@ blocks (~ @arbOneDisputeWindowDays@ days ) | @novaDisputeWindowBlocks@ blocks (~ @novaDisputeWindowDays@ days) | @goerliDisputeWindowBlocks@ blocks (~ @goerliDisputeWindowMinutes@ minutes) | @sepoliaDisputeWindowBlocks@ blocks (~ @sepoliaDisputeWindowMinutes@ minutes) | -| Base Stake | Amount of stake required for a validator to make an assertion | @arbOneBaesStakeEth@ ETH | @novaBaesStakeEth@ ETH | @goerliBaesStakeEth@ Goerli ETH | @sepoliaBaesStakeEth@ Sepolia ETH | -| Force-Include Period | Period after which a delayed message can be included into the inbox without any action from the Sequencer | @arbOneForceIncludePeriodBlocks@ blocks / @arbOneForceIncludePeriodHours@ hours | @novaForceIncludePeriodBlocks@ blocks / @novaForceIncludePeriodHours@ hours | @goerliForceIncludePeriodBlocks@ blocks / @goerliForceIncludePeriodHours@ hours | @sepoliaForceIncludePeriodBlocks@ blocks / @sepoliaForceIncludePeriodHours@ hours | -| Gas Speed Limit | Target gas/sec, over which the congestion mechanism activates | @arbOneGasSpeedLimitGasPerSec@ gas/sec | @novaGasSpeedLimitGasPerSec@ gas/sec | @goerliGasSpeedLimitGasPerSec@ gas/sec | @sepoliaGasSpeedLimitGasPerSec@ gas/sec | -| Gas Price Floor | Minimum gas price | @arbOneGasFloorGwei@ gwei | @novaGasFloorGwei@ gwei | @goerliGasFloorGwei@ gwei | @sepoliaGasFloorGwei@ gwei | +| Dispute window | Time for until assertions get confirmed during which validaors can issue a challenge | @arbOneDisputeWindowBlocks@ blocks (~ @arbOneDisputeWindowDays@ days ) | @novaDisputeWindowBlocks@ blocks (~ @novaDisputeWindowDays@ days) | @goerliDisputeWindowBlocks@ blocks (~ @goerliDisputeWindowMinutes@ minutes) | @sepoliaDisputeWindowBlocks@ blocks (~ @sepoliaDisputeWindowMinutes@ minutes) | +| Base stake | Amount of stake required for a validator to make an assertion | @arbOneBaesStakeEth@ ETH | @novaBaesStakeEth@ ETH | @goerliBaesStakeEth@ Goerli ETH | @sepoliaBaesStakeEth@ Sepolia ETH | +| Force-include period | Period after which a delayed message can be included into the inbox without any action from the Sequencer | @arbOneForceIncludePeriodBlocks@ blocks / @arbOneForceIncludePeriodHours@ hours | @novaForceIncludePeriodBlocks@ blocks / @novaForceIncludePeriodHours@ hours | @goerliForceIncludePeriodBlocks@ blocks / @goerliForceIncludePeriodHours@ hours | @sepoliaForceIncludePeriodBlocks@ blocks / @sepoliaForceIncludePeriodHours@ hours | +| Gas speed limit | Target gas/sec, over which the congestion mechanism activates | @arbOneGasSpeedLimitGasPerSec@ gas/sec | @novaGasSpeedLimitGasPerSec@ gas/sec | @goerliGasSpeedLimitGasPerSec@ gas/sec | @sepoliaGasSpeedLimitGasPerSec@ gas/sec | +| Gas price floor | Minimum gas price | @arbOneGasFloorGwei@ gwei | @novaGasFloorGwei@ gwei | @goerliGasFloorGwei@ gwei | @sepoliaGasFloorGwei@ gwei |