Merge pull request #517 from OffchainLabs/chain-params

chain params page and global vars

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
 

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).

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                                                        |

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@ 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...
 
@@ -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.
 

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.
 

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
 

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',

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;