You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/build-decentralized-apps/02-how-to-estimate-gas.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,7 +22,7 @@ Multiplying the value obtained from `eth_estimateGas` by the child chain gas pri
22
22
23
23
Alternatively, to obtain the gas limit for your transaction, you can call `NodeInterface.gasEstimateComponents()` and then use the first result, which is `gasEstimate`. Next, to find the total cost, you need to multiply this amount by the child chain gas price, which is available in the third result, `baseFee`.
24
24
25
-
Note that when working with parent to child chain messages (also known as [retryable tickets](/how-arbitrum-works/deep-dives/l1-to-l2-messaging.mdx)), you can use the function [`L1ToL2MessageGasEstimator.estimateAll()`](https://github.com/OffchainLabs/arbitrum-sdk/blob/main/src/lib/message/L1ToL2MessageGasEstimator.ts#L215) of the Arbitrum SDK or [`NodeInterface.estimateRetryableTicket()`](https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.8.0@@/nodeInterface/NodeInterface.go#L120) to get all the gas information needed to send a successful transaction.
25
+
Note that when working with parent to child chain messages (also known as [retryable tickets](/how-arbitrum-works/deep-dives/l1-to-l2-messaging.mdx)), you can use the function [`L1ToL2MessageGasEstimator.estimateAll()`](https://github.com/OffchainLabs/arbitrum-sdk/blob/main/src/lib/message/L1ToL2MessageGasEstimator.ts#L215) of the Arbitrum SDK or [`NodeInterface.estimateRetryableTicket()`](https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.9.3@@/nodeInterface/NodeInterface.go#L120) to get all the gas information needed to send a successful transaction.
Throughout this and other pages, we note that the block number of a chain does not match the value obtained from `block.number`. When using `block.number` in a smart contract, the value obtained will be the block of the first non-Arbitrum ancestor chain. That is:
@@ -22,7 +24,7 @@ As with Ethereum, Arbitrum clients submit transactions, and the system executes
22
24
23
25
Once in the chain's core inbox contract, transaction processing occurs in order. Generally, some time will elapse between when a message is put into the inbox (and timestamped) and when the contract processes the message and carries out the transaction requested by the message.
24
26
25
-
Additionally, since the calldata of Arbitrum transactions (or the DAC certificate on <adata-quicklook-from="arbitrum-anytrust-chain">AnyTrust</a>chains) is posted to Ethereum, the gas paid when executing them includes a component for the parent chain to cover the costs of the batch poster.
27
+
Additionally, since the calldata/blobs of Arbitrum transactions (or the DAC certificate on <adata-quicklook-from="arbitrum-anytrust-chain">AnyTrust</a>chains) is posted to Ethereum, the gas paid when executing them includes a component for the parent chain to cover the costs of the batch poster.
26
28
27
29
This page explains the implications of this mechanism for the block gas limit, block numbers, and the time assumptions associated with transactions submitted to Arbitrum.
28
30
@@ -42,7 +44,7 @@ A single Ethereum block can include multiple Arbitrum blocks; however, an Arbitr
42
44
43
45
### Ethereum (or parent chain) block numbers within Arbitrum
44
46
45
-
Accessing block numbers within an Arbitrum smart contract (i.e., `block.number` in Solidity) will return a value _close to_ (but not necessarily exactly) the block number of the first non-Arbitrum ancestor chain at which the sequencer received the transaction.
47
+
Accessing block numbers within an Arbitrum smart contract (i.e., `block.number` in Solidity) will return a value _close to_ (but not necessarily exactly) the block number of the first non-Arbitrum ancestor chain where the sequencer received the transaction.
46
48
47
49
The "first non-Arbitrum ancestor chain" is:
48
50
@@ -73,15 +75,14 @@ A client that queries an Arbitrum node's RPC interface (e.g., transaction receip
txnReceipt.l1BlockNumber => Approximate block number of the first non-Arbitrum ancestor chain
78
79
*/
79
80
```
80
81
81
82
The Arbitrum block number can also be retrieved within an Arbitrum contract via [ArbSys](/build-decentralized-apps/precompiles/02-reference.mdx#arbsys) precompile:
82
83
83
84
```solidity
84
-
ArbSys(100).arbBlockNumber() // returns Arbitrum block number
85
+
ArbSys(100).arbBlockNumber() // returns Arbitrum block number
85
86
```
86
87
87
88
### Example
@@ -94,7 +95,13 @@ The following example illustrates timings on a chain that settles to Ethereum (s
_\***The chain's `block.number`:** updated to sync with Ethereum's `block.number` approximately every minute. Thus, over time, it will, like Ethereum's `block.number`, average to ~12 seconds per block._
98
+
<VanillaAdmonitiontype="info">
99
+
100
+
txnReceipt.blockNumber => Arbitrum block number
101
+
102
+
\_\***The chain's `block.number`:** updated to sync with Ethereum's `block.number` every 13 to 15 seconds (occasionally longer).
103
+
104
+
</VanillaAdmonition>
98
105
99
106
_\*\***Chain's block number from RPCs:** note that this can be updated multiple times per Ethereum block (this lets the sequencer give sub-Ethereum-block-time transaction receipts.)_
0 commit comments