```
- Ensure that `/some/local/dir/arbitrum` already exists otherwise the directory might be created with `root` as owner, and the Docker container won't be able to write to it
diff --git a/arbitrum-docs/partials/_glossary-partial.md b/arbitrum-docs/partials/_glossary-partial.md
index c335a7678..1f268453e 100644
--- a/arbitrum-docs/partials/_glossary-partial.md
+++ b/arbitrum-docs/partials/_glossary-partial.md
@@ -110,7 +110,7 @@ A distributed digital ledger that is used to record transactions and store data
A cryptographic scheme that allows multiple signatures to be aggregated and compacted into one efficiently verifiable, constant-sized signature. Used in the Arbitrum AnyTrust Protocol for the Data Availability Committee (DAC)'s signatures.
-### BOLD {#bold}
+### BoLD {#bold}
Short for "Bounded Liquidity Delay"; latest version of the Arbitrum Challenge protocol designed to eliminate delay attack vectors (see here for more). Not currently on mainnet.
diff --git a/arbitrum-docs/partials/_troubleshooting-building-partial.md b/arbitrum-docs/partials/_troubleshooting-building-partial.md
index 48e79f379..e856b3a5e 100644
--- a/arbitrum-docs/partials/_troubleshooting-building-partial.md
+++ b/arbitrum-docs/partials/_troubleshooting-building-partial.md
@@ -408,7 +408,7 @@ When querying the receipt of a Classic transaction on a Nitro node, there's some
-To get the exact fees paid, you can query a Classic node, which will return all the exact information.
+To get the exact fees paid, you can query a Classic node, which will return all the accurate information in an object called feeStats. That object will contain all the information split into the four different gas fields: prices, unitsUsed and paid (which is price * unitsUsed).
diff --git a/arbitrum-docs/partials/_troubleshooting-orbit-partial.md b/arbitrum-docs/partials/_troubleshooting-orbit-partial.md
index ec40595fa..bd8c7358f 100644
--- a/arbitrum-docs/partials/_troubleshooting-orbit-partial.md
+++ b/arbitrum-docs/partials/_troubleshooting-orbit-partial.md
@@ -129,7 +129,7 @@ Similar to bridges and block explorers, there are many third-party indexing solu
### Can I increase the maximum contract size for my Orbit chain?
-Yes, but only on testnets for now. You can use our Orbit SDK (available for deployments on testnet), and configure the parameters MaxCodeSize and MaxInitCodeSize when calling prepareNodeConfig.
+Yes, Orbit supports an increased smart contract size limit of up to 96kB. You can use our Orbit SDK and configure the parameters MaxCodeSize and MaxInitCodeSize when calling prepareNodeConfig. Note that the smart contract size limit parameters can't be changed via upgrade after deployment.
diff --git a/arbitrum-docs/run-arbitrum-node/arbos-releases/arbos30.md b/arbitrum-docs/run-arbitrum-node/arbos-releases/arbos30.md
index 76e007531..7a2d1833d 100644
--- a/arbitrum-docs/run-arbitrum-node/arbos-releases/arbos30.md
+++ b/arbitrum-docs/run-arbitrum-node/arbos-releases/arbos30.md
@@ -7,28 +7,32 @@ author: dlee
:::caution Note to Orbit chains
-Upgrading your Orbit chain to ArbOS 30 or deploying a new Orbit chain with ArbOS 30 is **not yet supported or encouraged**. This page will be updated with requirements, upgrade instructions, and associated details when available. When ArbOS 30 Bianca is ready for Orbit mainnet adoption and all requirements have been formally tagged and published, Orbit chain owners and RaaS teams will need to follow [these instructions to upgrade](../../launch-orbit-chain/how-tos/arbos-upgrade.md). When the time comes, Orbit chain owners will need to upgrade their Nitro node versions, deploy new versions of [`nitro-contracts`](https://github.com/OffchainLabs/nitro-contracts) (using the [Orbit action contracts](https://github.com/OffchainLabs/orbit-actions)), set a new Wasm module root, and perform any ArbOS 30 Bianca specific configurations or actions.
+Upgrading your Orbit chain to ArbOS 30 or deploying a new Orbit chain with ArbOS 30 is **not yet supported or encouraged**. This page will be updated with requirements, upgrade instructions, and associated details when available. When ArbOS 30 Bianca is ready for Orbit mainnet adoption and all requirements have been formally tagged and published, Orbit chain owners and RaaS teams will need to follow [these instructions to upgrade](../../launch-orbit-chain/how-tos/arbos-upgrade.md). When the time comes, Orbit chain owners will need to upgrade their Nitro node versions, deploy new versions of [`nitro-contracts`](https://github.com/OffchainLabs/nitro-contracts) (using the [Orbit action contracts](https://github.com/OffchainLabs/orbit-actions)), set a new Wasm module root, and perform any ArbOS 30 Bianca specific configurations or actions.
:::
ArbOS 30 Bianca will be shipped as a Nitro release, which will be available on Docker hub. For Arbitrum One and Arbitrum Nova, the ArbOS 30 Bianca upgrade requires a governance vote to activate and so this release of Nitro will be a mandatory upgrade for Arbitrum One and Nova node operators if the on-chain DAO vote for the upgrade proposal passes. The Arbitrum docs will remain the canonical home for information regarding ArbOS releases, with more details found on the [ArbOS Software Releases Overview page](./01-overview.md).
### Requirements:
+
- A minimum Nitro version of 3.0.0, but the exact version is yet to be tagged and released.
- An upgrade to a new, unreleased version of [`nitro-contracts`](https://github.com/OffchainLabs/nitro-contracts)
- The setting of a new Wasm module root (that will be added here when available)
### High-level description of ArbOS 30 changes
+
ArbOS 30 Bianca is a major upgrade for Arbitrum chains and ArbOS upgrades can be seen as Arbitrum’s equivalent of a hard fork - more can be read about the subject over in [Arbitrum ArbOS upgrades](https://forum.arbitrum.foundation/t/arbitrum-arbos-upgrades/19695). Please note that ArbOS 30 Bianca is an upgrade that builds upon [ArbOS 20 Atlas](./arbos20.md).
ArbOS 30 Bianca brings many features, improvements, and bug fixes to Arbitrum chains. The full list of changes can be found in the Nitro release notes for [Nitro 3.0.0](https://github.com/OffchainLabs/nitro/releases/tag/v3.0.0) or higher (as Nitro 3.0.0 is the first Nitro version that adds support for ArbOS 30 Bianca). Highlighted below are a few of the most impactful and critical features that are introduced with ArbOS 30:
-- Activation of [Stylus](../../stylus/stylus-gentle-introduction.md) on Arbitrum chains through the addition of a new WebAssembly-based virtual machine that runs alongside the EVM. Stylus enables developers to write smart contracts in new programming languages that compile down to WASM, like Rust, that are more efficient and safer than Solidity smart contracts while retaining complete interoperability.
+
+- Activation of [Stylus](../../stylus/stylus-gentle-introduction.md) on Arbitrum chains through the addition of a new WebAssembly-based virtual machine that runs alongside the EVM. Stylus enables developers to write smart contracts in new programming languages that compile down to WASM, like Rust, that are more efficient and safer than Solidity smart contracts while retaining complete interoperability.
- Adoption of [RIP-7212](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md), a precompile for verifying the [`Secp256r1 or P-256 curve`](https://www.nervos.org/knowledge-base/what_is_secp256r1) on Arbitrum chains. Adding support for this precompile allows account abstraction wallets to cheaply verify a type of signature widely used in passkeys and secure enclaves.
-- V0 support for Arbitrum Nitro node snap sync, enabling a Nitro node to sync from a snapshot already accepted from L1 through the propagation of blockstate from other nodes in the network.
+- V0 support for Arbitrum Nitro node snap sync, enabling a Nitro node to sync from a snapshot already accepted from L1 through the propagation of blockstate from other nodes in the network.
- A change to the transaction fee router contracts on Arbitrum Nova to allow for fees collected to be automatically sent to the ArbitrumDAO Treasury on Arbitrum One. Currently, the ArbitrumDAO receives Arbitrum Nova transaction fees are sent to a ArbitrumDAO controlled address that requires a consitutional proposal to move, which is less efficient. This change is specific to Arbitrum Nova and is not expected to impact Orbit chains.
### Reference links for ArbOS 30 Bianca
-- [Nitro v3.0.0 release notes](https://github.com/OffchainLabs/nitro/releases/tag/v3.0.0). Note that this is the *first* version that supports ArbOS 30 Bianca, but Nitro 3.0.0 is not the *required* version. The final, required version of Nitro for ArbOS 30 Bianca is unreleased but will be shared here on this page when available.
+
+- [Nitro v3.0.0 release notes](https://github.com/OffchainLabs/nitro/releases/tag/v3.0.0). Note that this is the _first_ version that supports ArbOS 30 Bianca, but Nitro 3.0.0 is not the _required_ version. The final, required version of Nitro for ArbOS 30 Bianca is unreleased but will be shared here on this page when available.
- [AIP: Activate Stylus and Enable Next-Gen WebAssembly Smart Contracts (ArbOS 30)](https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970)
- [AIP: Support RIP-7212 for Account Abstraction Wallets (ArbOS 30)](https://forum.arbitrum.foundation/t/aip-support-rip-7212-for-account-abstraction-wallets-arbos-30/23298)
- [AIP: Nova Fee Router Proposal (ArbOS 30)](https://forum.arbitrum.foundation/t/aip-nova-fee-router-proposal-arbos-30/23310)
diff --git a/arbitrum-docs/run-arbitrum-node/more-types/02-run-validator-node.md b/arbitrum-docs/run-arbitrum-node/more-types/02-run-validator-node.md
index 7ee7d114e..a43e3b939 100644
--- a/arbitrum-docs/run-arbitrum-node/more-types/02-run-validator-node.md
+++ b/arbitrum-docs/run-arbitrum-node/more-types/02-run-validator-node.md
@@ -57,6 +57,7 @@ Here we describe different strategies that validators follow and provide instruc
```shell
docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum @latestNitroNodeImage@ --parent-chain.connection.url=https://l1-mainnet-node:8545 --chain.id=42161 --node.staker.enable --node.staker.strategy=Defensive --parent-chain.wallet.password="SOME SECURE PASSWORD"
```
+- For Orbit chains, you need to set the `--chain.info-json=` flag instead of `--chain.id=`
- To verify validator is working, this log line shows the wallet is setup correctly:
```shell
INFO [09-28|18:43:49.367] running as validator txSender=0x... actingAsWallet=0x... whitelisted=true strategy=Defensive
@@ -66,3 +67,10 @@ Here we describe different strategies that validators follow and provide instruc
- `txSender` and `actingAsWallet` should both be present and not `nil`
- The log line `validation succeeded` shows that the L2 block validator is working
- The log line `found correct assertion` shows that the L1 validator is working
+
+#### Orbit chains: grant whitlelist
+
+- You need to be the chain owner to include a new validator address in the allowlist:
+- Find your `upgradeExecutor` contract address.
+- Send transactions to the `executeCall` method of the`upgradeExecutor` contract and set the `target` address to your Rollup contract's address, set the `targetCalldata` to `0xa3ffb772{Your new allowlist validator address}`. (`0xa3ffb772` is the signature of `setValidator(address[],bool[])`)
+- Call your Rollup contract's `isValidator(address)` and check the result.
diff --git a/arbitrum-docs/run-arbitrum-node/nitro/01-build-nitro-locally.md b/arbitrum-docs/run-arbitrum-node/nitro/01-build-nitro-locally.md
index d243a1d43..2bb97024d 100644
--- a/arbitrum-docs/run-arbitrum-node/nitro/01-build-nitro-locally.md
+++ b/arbitrum-docs/run-arbitrum-node/nitro/01-build-nitro-locally.md
@@ -24,7 +24,7 @@ This how-to assumes that you're running one of the following operating systems:
#### For [Debian](https://docs.docker.com/engine/install/debian)/[Ubuntu](https://docs.docker.com/engine/install/ubuntu)
-```bash
+```shell
for pkg in docker.io docker-doc docker-compose podman-docker containerd runc; do sudo apt-get remove $pkg; done
# Add Docker's official GPG key:
sudo apt-get update
@@ -51,7 +51,7 @@ Depending on whether your Mac has an Intel processor or Apple silicon, download
After installing docker, you might want to be able to run it with your current user instead of root. You can run the following commands to do so.
-```bash
+```shell
sudo groupadd docker
sudo usermod -aG docker $USER
newgrp docker
@@ -61,7 +61,7 @@ For troubleshooting, check Docker's section in [their documentation](https://doc
### Step 2. Download the Nitro source code
-```bash
+```shell
git clone --branch @nitroVersionTag@ https://github.com/OffchainLabs/nitro.git
cd nitro
git submodule update --init --recursive --force
@@ -69,7 +69,7 @@ git submodule update --init --recursive --force
### Step 3. Build the Nitro node Docker image
-```bash
+```shell
docker build . --tag nitro-node
```
@@ -83,7 +83,7 @@ If you want to build the node binaries natively, execute steps 1-3 of the [Build
#### For Debian/Ubuntu
-```bash
+```shell
apt install git curl build-essential cmake npm golang clang make gotestsum wabt lld-13 python3
npm install --global yarn
ln -s /usr/bin/wasm-ld-13 /usr/local/bin/wasm-ld
@@ -93,7 +93,7 @@ ln -s /usr/bin/wasm-ld-13 /usr/local/bin/wasm-ld
Install [Homebrew](https://brew.sh/) package manager and add it to your `PATH` environment variable:
-```bash
+```shell
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
echo "export PATH=/opt/homebrew/bin:$PATH" >> ~/.zprofile && source ~/.zprofile
```
@@ -102,37 +102,37 @@ echo "export PATH=/opt/homebrew/bin:$PATH" >> ~/.zprofile && source ~/.zprofile
Install essentials:
-```bash
+```shell
brew install git curl make cmake npm go gvm golangci-lint wabt llvm gotestsum
npm install --global yarn
sudo mkdir -p /usr/local/bin
sudo ln -s /opt/homebrew/opt/llvm/bin/wasm-ld /usr/local/bin/wasm-ld
```
-### Step 5. Configure node [16.19](https://github.com/nvm-sh/nvm)
+### Step 5. Configure node [18](https://github.com/nvm-sh/nvm)
#### For Debian/Ubuntu
-```bash
+```shell
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash
source "$HOME/.bashrc"
-nvm install 16.19
-nvm use 16.19
+nvm install 18
+nvm use 18
```
#### For MacOS
-```bash
+```shell
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
-nvm install 16.19
-nvm use 16.19
+nvm install 18
+nvm use 18
```
### Step 6. Configure Rust [1.73](https://www.rust-lang.org/tools/install)
-```bash
+```shell
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"
rustup install 1.73
@@ -142,29 +142,29 @@ rustup target add wasm32-wasi --toolchain 1.73
cargo install cbindgen
```
-### Step 7. Configure Go [1.20](https://github.com/moovweb/gvm)
+### Step 7. Configure Go [1.21](https://github.com/moovweb/gvm)
#### Install Bison
##### For Debian/Ubuntu
-```bash
+```shell
sudo apt-get install bison
```
##### For MacOS
-```bash
+```shell
brew install bison
```
#### Install and configure Go
-```bash
+```shell
bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)
source "$HOME/.gvm/scripts/gvm"
-gvm install go1.20
-gvm use go1.20 --default
+gvm install go1.21
+gvm use go1.21 --default
curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.54.2
```
@@ -172,20 +172,20 @@ If you use zsh, replace `bash` with `zsh`.
#### Install foundry
-```bash
+```shell
curl -L https://foundry.paradigm.xyz | bash
foundryup
```
### Step 8. Start build
-```bash
+```shell
make
```
### Step 9. Produce binaries
-```bash
+```shell
make build
```
@@ -193,7 +193,7 @@ make build
To run your node using the generated binaries, use the following command from the `nitro` folder, with your desired parameters
-```bash
+```shell
./target/bin/nitro
```
@@ -207,6 +207,6 @@ ERROR[05-21|21:59:17.415] unable to find validator machine directory for the on-
Try add flag:
-```bash
+```shell
--validation.wasm.allowed-wasm-module-roots={WASM_MODULE_ROOT}
```
diff --git a/arbitrum-docs/stylus/concepts/stylus-cache-manager.md b/arbitrum-docs/stylus/concepts/stylus-cache-manager.md
new file mode 100644
index 000000000..cd563906b
--- /dev/null
+++ b/arbitrum-docs/stylus/concepts/stylus-cache-manager.md
@@ -0,0 +1,40 @@
+---
+title: 'Stylus caching strategy'
+description: 'A conceptual overview of the Stylus caching strategy and `CacheManager` contract, and explaining its functionality.'
+sme: mahsa-moosavi
+target_audience: 'Developers deploying smart contracts using Stylus.'
+sidebar_position: 3
+---
+
+Stylus is designed for fast computation and efficiency. However,
+the initialization process when entering a contract can be resource-intensive and time-consuming.
+
+This initialization process, if repeated frequently, may lead to inefficiencies. To address this, we have implemented a caching strategy. By storing frequently accessed contracts in memory, we can avoid repeated initializations. This approach saves resources and time, significantly enhancing the speed and efficiency of contract execution.
+
+**Note that Stylus smart contracts will need to be re-activated once per year (365 days) or whenever a upgrade to Stylus (which will always involve an ArbOS upgrade), even if they are in the cache. This re-activation can be done using [`cargo-stylus`](https://github.com/OffchainLabs/cargo-stylus), a cargo subcommand for building, verifying, and deploying Arbitrum Stylus WASM contracts in Rust.**
+
+
+
+import PublicPreviewBannerPartial from '../partials/_stylus-public-preview-banner-partial.md';
+
+
+
+## CacheManager contract
+
+The core component of our caching strategy is the [`CacheManager` contract](https://github.com/OffchainLabs/stylus-contracts/blob/c51ab1dc90f543caf579600162f77e053984b8cd/src/chain/`CacheManager`.sol). This smart contract manages the cache, interacts with precompiles, and determines which contracts should be cached. The `CacheManager` can hold approximately 4,000 contracts in memory.
+
+The `CacheManager` defines how contracts remain in the cache and how they compete with other contracts for cache space. Its primary purpose is to reduce high initialization costs, ensuring efficient contract activation and usage. The contract includes methods for adding and removing cache entries, querying the status of cached contracts, and managing the lifecycle of cached data.
+
+### Key features
+
+The `CacheManager` plays a crucial role in our caching strategy by keeping a specific set of contracts in memory rather than retrieving them from disk. This significantly reduces the activation time for frequently accessed contracts. The `CacheManager` contract is an on-chain contract that accepts bids for inserting contract code into the cache. It then calls a precompile that loads or unloads the contracts in the `ArbOS` cache, which follows the on-chain cache but operates locally in the client and marks the contract as in or out of the cache in the `ArbOS` state.
+
+The cache operates through an auction system where dApp developers submit bids to insert their contracts into the cache. If the cache is at capacity, lower bids are evicted to make space for higher bids. The cache maintains a minimum heap of bids for `codeHashes`, with bids encoded as `bid << 64 + index`, where `index` represents the position in the list of all bids. When an insertion exceeds the cache's maximum size, items are popped off the minimum heap and deleted until there is enough space to insert the new item. Contracts with equal bids will be popped in a random order, while the smallest bid is evicted first.
+
+To ensure that developers periodically pay to maintain their position in the cache, we use a global decay parameter computed by `decay = block.timestamp * _decay`. This inflates the value of bids over time, making newer bids more valuable.
+
+### Cache access and costs
+
+During activation, we compute the contract's initialization costs for both non-cached and cached initialization. These costs take into account factors such as the number of functions, types, code size, data length, and memory usage. It's important to note that accessing an uncached contract does not automatically add it to the `CacheManager`'s cache. Only explicit calls to the `CacheManager` contract will add a contract to the cache. If a contract is removed from the cache, calling the contract becomes more expensive unless it is re-added.
+
+To see how much gas contract initialization would cost, you need to call `programInitGas(address)` from the [ArbWasm precompile](https://github.com/OffchainLabs/nitro/blob/d906798140e562500beb9005d2503b0272852298/precompiles/ArbWasm.go). This function returns both the initialization cost when the contract is cached and when it is not.
diff --git a/arbitrum-docs/stylus/how-tos/debugging-stylus-tx.mdx b/arbitrum-docs/stylus/how-tos/debugging-stylus-tx.mdx
new file mode 100644
index 000000000..2624ef9cc
--- /dev/null
+++ b/arbitrum-docs/stylus/how-tos/debugging-stylus-tx.mdx
@@ -0,0 +1,174 @@
+---
+title: 'How to debug Stylus transactions using Cargo Stylus Replay'
+description: 'This how-to explains how to perform trace calls and use GDB to replay and debug Stylus transactions, providing detailed analysis and troubleshooting.'
+author: mahsamoosavi
+sme: mahsamoosavi
+target_audience: 'Developers deploying smart contracts using Stylus'
+content_type: how-to
+sidebar_position: 2
+---
+
+import PublicPreviewBannerPartial from '../partials/_stylus-public-preview-banner-partial.md';
+
+
+
+Debugging smart contracts can be challenging, especially when dealing with complex transactions. The `cargo-stylus-replay` crate simplifies the debugging process by allowing developers to replay Stylus transactions. This tool leverages GDB to provide an interactive debugging experience, enabling developers to set breakpoints, inspect state changes, and trace the execution flow step-by-step. This capability is crucial for identifying and resolving issues, ensuring that smart contracts function correctly and efficiently.
+
+### Overview
+
+Cargo Stylus is a tool designed to simplify the development and debugging process for smart contracts written in Rust for the Stylus execution environment. One of its powerful features is the `cargo-stylus-replay` crate, which provides essential functionalities for developers:
+
+1. **Trace transactions**: Perform trace calls against Stylus transactions using Ethereum nodes' `debug_traceTransaction` RPC. This feature enables developers to analyze the execution flow and state changes of their transactions in a detailed manner.
+2. **Debugging with GDB**: Replay and debug the execution of a Stylus transaction using the GNU Debugger (GDB). This allows developers to set breakpoints, inspect variables, and step through the transaction execution line by line, providing an in-depth understanding of the transaction's behavior.
+
+### Replaying transactions
+
+**Note:** Currently, this has only been tested on Linux, x86 systems with GDB installed.
+
+#### Requirements
+
+- **Rust** (version 1.77 or higher)
+- **Crates**: `cargo-stylus`, `cargo-stylus-replay`, `cargo-stylus-check`
+- **GNU Debugger (GDB)**
+- **[Cast](https://book.getfoundry.sh/cast/)** (an Ethereum CLI tool)
+- **Local Arbitrum Sepolia node** with tracing endpoints enabled or a [local Stylus dev node](https://arbitrum-docs-ncyp5gty1-offchain-labs.vercel.app/run-arbitrum-node/run-local-dev-node)
+
+`cargo-stylus-replay` allows users to debug the execution of a Stylus transaction using [GDB](https://sourceware.org/gdb/) against the Rust source code.
+
+### Installation and setup
+
+1. **Install the required crates and GDB**: First, let's ensure that the following crates are installed:
+
+```sh
+cargo install cargo-stylus cargo-stylus-replay cargo-stylus-check
+```
+
+Install GDB if it's not already installed:
+
+```sh
+sudo apt-get install gdb
+```
+
+2. **Deploy your Stylus contract**: For this guide, we demonstrate how to debug the execution of the `increment()` method in the [stylus-hello-world](https://github.com/OffchainLabs/stylus-hello-world) smart contract. In Rust, it looks something like this, within `src/lib.rs`:
+
+```sh
+#[external]
+impl Counter {
+ ...
+ /// Increments number and updates its value in storage.
+ pub fn increment(&mut self) {
+ let number = self.number.get();
+ self.set_number(number + U256::from(1));
+ }
+ ...
+}
+```
+
+Set your RPC endpoint to a node with **tracing enabled** and your private key:
+
+```sh
+export RPC_URL=...
+export PRIV_KEY=...
+```
+
+and deploy your contract:
+
+```sh
+cargo stylus deploy --private-key=$PRIV_KEY --endpoint=$RPC_URL
+```
+
+You should see an output similar to:
+
+```sh
+contract size: 4.0 KB
+wasm size: 12.1 KB
+contract size: 4.0 KB
+deployed code at address: 0x2c8d8a1229252b07e73b35774ad91c0b973ecf71
+wasm already activated!
+```
+
+3. **Send a transaction**: First, set the address of the deployed contract as an environment variable:
+
+```sh
+export ADDR=0x2c8d8a1229252b07e73b35774ad91c0b973ecf71
+```
+
+And send a transaction using `Cast`:
+
+```sh
+cast send --rpc-url=$RPC_URL --private-key=$PRIV_KEY $ADDR "increment()"
+```
+
+4. **Replay the transaction with GDB**: Now, we can replay the transaction with cargo stylus and GDB to inspect each step of it against our source code. Make sure GDB is installed and that you are on a Linux, x86 system.
+ Also, you should set the transaction hash as an environment variable:
+
+```sh
+export TX_HASH=0x18b241841fa0a59e02d3c6d693750ff0080ad792204aac7e5d4ce9e20c466835
+```
+
+And replay the transaction:
+
+```sh
+cargo stylus replay --tx=$TX_HASH --endpoint=$RPC_URL
+```
+
+GDB will load and set a breakpoint automatically at the `user_entrypoint` internal Stylus function.
+
+```sh
+[Detaching after vfork from child process 370003]
+
+Thread 1 "cargo-stylus-re" hit Breakpoint 1, stylus_hello_world::user_entrypoint (len=4) at src/lib.rs:38
+38 #[entrypoint]
+(gdb)
+```
+
+5. **Debugging with GDB**: Now, set a breakpoint at the `increment()` method:
+
+```sh
+(gdb) b stylus_hello_world::Counter::increment
+Breakpoint 2 at 0x7ffff7e4ee33: file src/lib.rs, line 69.
+```
+
+Then, type `c` to continue the execution and you will reach that line where `increment` is called:
+
+```sh
+(gdb) c
+```
+
+Once you reach the `increment` method, inspect the state:
+
+```sh
+Thread 1 "cargo-stylus-re" hit Breakpoint 2, stylus_hello_world::Counter::increment (self=0x7fffffff9ae8) at src/lib.rs:69
+69 let number = self.number.get();
+(gdb) p number
+```
+
+### Trace a transaction
+
+For traditional tracing, `cargo stylus` supports calls to `debug_traceTransaction`. To trace a transaction, you can use the following command:
+
+```sh
+cargo stylus trace [OPTIONS] --tx
+```
+
+Options:
+
+```sh
+ -e, --endpoint RPC endpoint [default: http://localhost:8547]
+ -t, --tx Tx to replay
+ -p, --project Project path [default: .]
+ -h, --help Print help
+ -V, --version Print version
+```
+
+Run the following command to obtain a trace output:
+
+```sh
+cargo stylus trace --tx=$TX_HASH --endpoint=$RPC_URL
+```
+
+This will produce a trace of the functions called and [ink](https://docs.arbitrum.io/stylus/concepts/stylus-gas#ink-and-gas) left along each method:
+
+```sh
+[{"args":[0,0,0,4],"endInk":846200000,"name":"user_entrypoint","outs":[],"startInk":846200000},{"args":[],"endInk":846167558,"name":"msg_reentrant","outs":[0,0,0,0],"startInk":846175958},{"args":[],"endInk":846047922,"name":"read_args","outs":[208,157,224,138],"startInk":846061362},{"args":[],"endInk":845914924,"name":"msg_value","outs":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"startInk":845928364},{"args":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"endInk":227196069,"name":"storage_load_bytes32","outs":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"startInk":844944549},{"args":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1],"endInk":226716083,"name":"storage_cache_bytes32","outs":[],"startInk":226734563},{"args":[0],"endInk":226418732,"name":"storage_flush_cache","outs":[],"startInk":226486805},{"args":[],"endInk":226362319,"name":"write_result","outs":[],"startInk":226403481},{"args":[],"endInk":846200000,"name":"user_returned","outs":[0,0,0,0],"startInk":846200000}]
+```
diff --git a/arbitrum-docs/stylus/reference/testnet-information.md b/arbitrum-docs/stylus/reference/testnet-information.md
index 30a8945a0..9eab87960 100644
--- a/arbitrum-docs/stylus/reference/testnet-information.md
+++ b/arbitrum-docs/stylus/reference/testnet-information.md
@@ -21,10 +21,10 @@ Stylus is undergoing major upgrades, and some improvements are expected to requi
This table provides an overview of the available public RPC endpoints for the Stylus testnet and necessary details to interact with them.
-| Name | RPC URL | Chain ID | Block explorer | Underlying chain | Sequencer feed URL | Sequencer endpoint⚠️ |
-| -------------------------------- | -------------------------------------- | -------- | -------------------------------------------- | ---------------- | ------------------------------------- | ------------------------------------------------ |
-| Arbitrum Sepolia | https://sepolia-rollup.arbitrum.io/rpc | 421614 | https://sepolia.arbiscan.io | Sepolia | wss://sepolia-rollup.arbitrum.io/feed | https://sepolia-rollup-sequencer.arbitrum.io/rpc |
-| Stylus testnet (v2-deprecated) | https://stylusv2.arbitrum.io/rpc | 13331371 | https://stylusv2-explorer.arbitrum.io/ | Arbitrum Sepolia | wss://stylusv2.arbitrum.io/feed | https://stylusv2-sequencer.arbitrum.io/rpc |
+| Name | RPC URL | Chain ID | Block explorer | Underlying chain | Sequencer feed URL | Sequencer endpoint⚠️ |
+| ------------------------------ | -------------------------------------- | -------- | -------------------------------------------- | ---------------- | ------------------------------------- | ------------------------------------------------ |
+| Arbitrum Sepolia | https://sepolia-rollup.arbitrum.io/rpc | 421614 | https://sepolia.arbiscan.io | Sepolia | wss://sepolia-rollup.arbitrum.io/feed | https://sepolia-rollup-sequencer.arbitrum.io/rpc |
+| Stylus testnet (v2-deprecated) | https://stylusv2.arbitrum.io/rpc | 13331371 | https://stylusv2-explorer.arbitrum.io/ | Arbitrum Sepolia | wss://stylusv2.arbitrum.io/feed | https://stylusv2-sequencer.arbitrum.io/rpc |
| Stylus testnet (v1-deprecated) | https://stylus-testnet.arbitrum.io/rpc | 23011913 | https://stylus-testnet-explorer.arbitrum.io/ | Arbitrum Sepolia | wss://stylus-testnet.arbitrum.io/feed | https://stylus-testnet-sequencer.arbitrum.io/rpc |
:::caution
diff --git a/arbitrum-docs/stylus/stylus-quickstart.md b/arbitrum-docs/stylus/stylus-quickstart.md
index 1e83dc4ca..b92bf000e 100644
--- a/arbitrum-docs/stylus/stylus-quickstart.md
+++ b/arbitrum-docs/stylus/stylus-quickstart.md
@@ -50,7 +50,7 @@ If you’re using [MetaMask](https://metamask.io/), simply click the dropdown at
The Stylus testnet settles directly to the [Arbitrum Sepolia](/build-decentralized-apps/03-public-chains.md#arbitrum-sepolia) testnet. Follow these steps to acquire testnet ETH on the Stylus testnet:
-1. Navigate to [https://bwarelabs.com/faucets/arbitrum-stylus-testnet](https://bwarelabs.com/faucets/arbitrum-stylus-testnet).
+1. Navigate to [https://bwarelabs.com/faucets/arbitrum-sepolia](https://bwarelabs.com/faucets/arbitrum-sepolia).
2. Enter your wallet address into the text field.
3. Click `Claim` and optionally follow the second step to receive extra testnet tokens.
4. You should now have Sepolia ETH on the Stylus testnet.
diff --git a/website/package.json b/website/package.json
index 92c3797a7..89bf17867 100644
--- a/website/package.json
+++ b/website/package.json
@@ -6,7 +6,7 @@
"docusaurus": "docusaurus",
"install_sdk_dependencies": "cd ../arbitrum-sdk && yarn install && cd ../website",
"generate_precompiles_ref_tables": "ts-node src/scripts/precompile-reference-generator.ts",
- "start": "docusaurus start",
+ "start": "yarn clear && yarn install_sdk_dependencies && docusaurus start",
"build_translation": "yarn ts-node ./src/scripts/move-untranslated-files.ts",
"build": "yarn install_sdk_dependencies && docusaurus build",
"swizzle": "docusaurus swizzle",
diff --git a/website/sidebars.js b/website/sidebars.js
index 9377a7e6d..e6cdc043f 100644
--- a/website/sidebars.js
+++ b/website/sidebars.js
@@ -58,7 +58,7 @@ const sidebars = {
},
{
type: 'doc',
- label: 'Block numbers and time',
+ label: 'Block gas limit, numbers and time',
id: 'build-decentralized-apps/arbitrum-vs-ethereum/block-numbers-and-time',
},
{
@@ -324,6 +324,13 @@ const sidebars = {
// q: why use an anchor html tag here?
// a: see note at end of file
},
+ {
+ type: 'html',
+ value:
+ '',
+ // q: why use an anchor html tag here?
+ // a: see note at end of file
+ },
{
type: 'doc',
id: 'launch-orbit-chain/concepts/anytrust-orbit-chain-keyset-generation',
@@ -428,6 +435,11 @@ const sidebars = {
id: 'stylus/stylus-quickstart',
label: 'Quickstart (Rust)',
},
+ {
+ type: 'doc',
+ id: 'stylus/concepts/stylus-cache-manager',
+ label: 'Stylus caching strategy',
+ },
{
type: 'html',
value:
@@ -440,6 +452,12 @@ const sidebars = {
label: 'Testnets',
id: 'stylus/reference/testnet-information',
},
+ {
+ type: 'link',
+ label: 'Stylus by example',
+ href: 'https://stylus-by-example.org/',
+ },
+
{
type: 'category',
label: 'Gas and ink',
@@ -490,6 +508,11 @@ const sidebars = {
label: 'Reduce the size of WASM binaries',
id: 'stylus/how-tos/optimizing-binaries',
},
+ {
+ type: 'doc',
+ label: 'Debug Stylus transactions',
+ id: 'stylus/how-tos/debugging-stylus-tx',
+ },
{
type: 'link',
label: 'Rust crate docs',
diff --git a/website/src/css/partials/_variables.scss b/website/src/css/partials/_variables.scss
index 4be91b5da..ad232fc4c 100644
--- a/website/src/css/partials/_variables.scss
+++ b/website/src/css/partials/_variables.scss
@@ -12,7 +12,7 @@
--arbitrum-primary-button-bg: black;
--arbitrum-primary-button-text: white;
--stylus-brand-color-dark: #b70458;
- --stylus-brand-color: #E3066E;
+ --stylus-brand-color: #e3066e;
--ifm-color-primary: #007bdd;
--ifm-color-primary-dark: #295f78;
--ifm-color-primary-darker: #275771;
diff --git a/website/src/resources/globalVars.js b/website/src/resources/globalVars.js
index dcd3d92cc..d434dd6ee 100644
--- a/website/src/resources/globalVars.js
+++ b/website/src/resources/globalVars.js
@@ -14,7 +14,7 @@ const sepoliaForceIncludePeriodBlocks = 5760;
const globalVars = {
// Node docker images
- latestNitroNodeImage: 'offchainlabs/nitro-node:v2.3.4-b4cc111',
+ latestNitroNodeImage: 'offchainlabs/nitro-node:v3.1.0-7d1d84c',
latestClassicNodeImage: 'offchainlabs/arb-node:v1.4.5-e97c1a4',
// Node snapshots (taken around April 20th, 2013)
@@ -31,7 +31,7 @@ const globalVars = {
// Nitro Github references
nitroRepositorySlug: 'nitro',
- nitroVersionTag: 'v2.3.4',
+ nitroVersionTag: 'v3.1.0',
nitroPathToPrecompiles: 'precompiles',
nitroContractsRepositorySlug: 'nitro-contracts',
diff --git a/website/static/building-faqs.json b/website/static/building-faqs.json
index 9ef5ac664..a90563868 100644
--- a/website/static/building-faqs.json
+++ b/website/static/building-faqs.json
@@ -21,7 +21,7 @@
{"question": "What is the WASM module root?","answer": "\nThe WASM module root is a 32 byte hash, which is a merkelization of the Go replay binary and its dependencies.\n
\n\n\nThe replay binary is much too large to post on-chain, so this hash is set in the L1 rollup contract to determine the correct replay binary during fraud proofs.\n
\n\n\nYou can find more information in How to customize your Orbit chain's behavior.\n
\n\n\n\n
\n\n","key": "what-is-the-wasm-module-root"},
{"question": "Why do I get a \"gas required exceeds allowance\" when trying to estimate the gas costs of a request?","answer": "\nDuring an eth_estimateGas call the actual request will be simulated on the node, so if the transaction reverts or if there aren't enough funds in the wallet that's making the call (usually the from parameter), the eth_estimateGas request will return the error gas required exceeds allowance.\n
\n\n\nMake sure you have enough funds in your wallet, and the gas fields of the request (if you're using them) are correctly set.\n
\n\n","key": "why-do-i-get-a-gas-required-exceeds-allowance-when-trying-to-estimate-the-gas-costs-of-a-request"},
{"question": "How can I verify that an L2 block has been processed as part of a specific RBlock?","answer": "\nIf you want to verify that the latest confirmed (or created) assertion has processed a specific L2 block, you can follow these steps:\n
\n\n\n- From the rollup contract, obtain the latest confirmed (or created) Rblock through the function
latestConfirmed (or latestNodeCreated). In this context, we refer to RBlocks as \"nodes\". \n- Obtain the node information through
getNode \n- Find the
NodeCreated event that was emitted when that node was created. \n- In that NodeCreated event, there's an
assertion property that contains the state of the chain before processing the specified blocks, and after processing them. Get the afterState.globalState property \n- That value contains a bytes32Vals array with the latest L2 block hash processed in the first element.
\n
\n\nYou can find an example script in our arbitrum-tutorials repository.\n
\n\n","key": "how-can-i-verify-that-an-l2-block-has-been-processed-as-part-of-a-specific-rblock"},
-{"question": "Why is the fee of some Classic transactions slightly different than the multiplication of gasLimit and effectiveGasPrice?","answer": "\nGas prices in Classic transactions worked a bit differently than in Nitro transactions. Classic transactions handled four different prices: L1 fixed, L1 calldata, L2 computation and L2 storage. You can see all those prices in the Advanced TxInfo of Arbiscan (here's an example).\n
\n\n\nWhen querying the receipt of a Classic transaction on a Nitro node, there's some calculation done to get an effectiveGasPrice that is close to (but not exactly) what those four prices represent. That's why if you multiply the gasLimit by the effectiveGasPrice you might end up with a transaction fee that is slightly different than the actual fee paid.\n
\n\n\nTo get the exact fees paid, you can query a Classic node, which will return all the exact information.\n
\n\n\n\n
\n\n","key": "why-is-the-fee-of-some-classic-transactions-slightly-different-than-the-multiplication-of-gaslimit-and-effectivegasprice"},
+{"question": "Why is the fee of some Classic transactions slightly different than the multiplication of gasLimit and effectiveGasPrice?","answer": "\nGas prices in Classic transactions worked a bit differently than in Nitro transactions. Classic transactions handled four different prices: L1 fixed, L1 calldata, L2 computation and L2 storage. You can see all those prices in the Advanced TxInfo of Arbiscan (here's an example).\n
\n\n\nWhen querying the receipt of a Classic transaction on a Nitro node, there's some calculation done to get an effectiveGasPrice that is close to (but not exactly) what those four prices represent. That's why if you multiply the gasLimit by the effectiveGasPrice you might end up with a transaction fee that is slightly different than the actual fee paid.\n
\n\n\nTo get the exact fees paid, you can query a Classic node, which will return all the accurate information in an object called feeStats. That object will contain all the information split into the four different gas fields: prices, unitsUsed and paid (which is price * unitsUsed).\n
\n\n\n\n
\n\n","key": "why-is-the-fee-of-some-classic-transactions-slightly-different-than-the-multiplication-of-gaslimit-and-effectivegasprice"},
{"question": "How can I update the information of my bridged token on Arbiscan?","answer": "\nIf you have a native-L1 token that was bridged to L2 via the standard gateway, you might find that you can't claim ownership of the L2 contract of your token as it was generated by another contract.\n
\n\n\nTo update its information on Arbiscan (logo, socials, etc.), you can open a ticket through Arbiscan support system and request them to replicate the information of your token on L1 to L2.\n
\n\n\n\n
\n\n","key": "how-can-i-update-the-information-of-my-bridged-token-on-arbiscan"},
{"question": "Why does my transaction revert with InvalidFEOpcode when using Foundry?","answer": "\nFoundry and other similar development tools that enable chain forking, do not support Arbitrum precompiles. If your transaction is calling a precompile, it is likely that it will revert with InvalidFEOpcode.\n
\n\n\nTo rule out that possibility, it is recommended to send the transaction with a different tool.\n
\n\n\n\n
\n\n","key": "why-does-my-transaction-revert-with-invalidfeopcode-when-using-foundry"},
{"question": "Why do I receive an \"intrinsic gas too low\" error when sending a transaction even with a high gas price?","answer": "\nThe error intrinsic gas too low usually refers to not providing enough gas to pay for the L1 component of the transaction fees. This is usually a problem related to not setting a high enough gas limit (instead of gas price), due to how Arbitrum handles gas. You can find more information in the article Understanding Arbitrum: 2-dimensional fees and the page How to estimate gas.\n
\n\n\n\n
\n\n","key": "why-do-i-receive-an-intrinsic-gas-too-low-error-when-sending-a-transaction-even-with-a-high-gas-price"},
diff --git a/website/static/building-orbit-faqs.json b/website/static/building-orbit-faqs.json
index e6513d5f5..9cb263dee 100644
--- a/website/static/building-orbit-faqs.json
+++ b/website/static/building-orbit-faqs.json
@@ -11,7 +11,7 @@
{"question": "Is there any cross-chain bridging solution between two Orbit chains?","answer": "\nThere is currently no Orbit-to-Orbit native bridging solution, other than going through the parent chain (if they share the same parent chain). However, there are many third-party bridges that have expressed interest in supporting Orbit chains.\n
\n\n\n\n
\n\n","key": "is-there-any-crosschain-bridging-solution-between-two-orbit-chains"},
{"question": "Is there an official block explorer for Orbit chains?","answer": "\nOrbit chains deployments usually come with an open-source blockscout explorer by default, but there are many third-party solutions that have expressed interest in supporting Orbit chains.\n
\n\n\n\n
\n\n","key": "is-there-an-official-block-explorer-for-orbit-chains"},
{"question": "Is there any indexing solution that supports Orbit chains?","answer": "\nSimilar to bridges and block explorers, there are many third-party indexing solutions that have expressed interest in supporting Orbit chains.\n
\n\n\n\n
\n\n","key": "is-there-any-indexing-solution-that-supports-orbit-chains"},
-{"question": "Can I increase the maximum contract size for my Orbit chain?","answer": "\nYes, but only on testnets for now. You can use our Orbit SDK (available for deployments on testnet), and configure the parameters MaxCodeSize and MaxInitCodeSize when calling prepareNodeConfig.\n
\n\n\n\n
\n\n","key": "can-i-increase-the-maximum-contract-size-for-my-orbit-chain"},
+{"question": "Can I increase the maximum contract size for my Orbit chain?","answer": "\nYes, Orbit supports an increased smart contract size limit of up to 96kB. You can use our Orbit SDK and configure the parameters MaxCodeSize and MaxInitCodeSize when calling prepareNodeConfig. Note that the smart contract size limit parameters can't be changed via upgrade after deployment.\n
\n\n\n\n
\n\n","key": "can-i-increase-the-maximum-contract-size-for-my-orbit-chain"},
{"question": "How can I modify Nitro to force posting an invalid assertion and test the fraud proof mechanism?","answer": "\nForcing an invalid assertion in the chain is not supported at the moment. However, if you're building Nitro locally, you can run the following test that goes through the whole rollup/challenge mechanism:\n
\n\n```shell\ngo test ./system_tests/ -tags=challengetest -run=TestChallenge\n\n```\n\n\n
\n\n","key": "how-can-i-modify-nitro-to-force-posting-an-invalid-assertion-and-test-the-fraud-proof-mechanism"},
{"question": "What fee collectors can be configured on my chain?","answer": "\nThere are 4 fee types that can be configured on an Orbit chain:\n
\n\n\n- L2 base fee: L2 execution fees corresponding to the minimum base price of the chain. This is paid to the infraFeeAccount, which can be set by calling
ArbOwner.setInfraFeeAccount(). \n- L2 surplus fee: L2 execution fees above the minimum base price (in the case of congestion). This is paid to the networkFeeAccount, which can be set by calling
ArbOwner.setNetworkFeeAccount(). \n- L1 base fee: Relative fees for posting a transaction on the parent chain. This is paid ultimately to the fee collector of the active batch poster. The batch poster can be set by calling
SequencerInbox.setIsBatchPoster() on the parent chain. And a different fee collector for that batch poster can be specified by calling ArbAggregator.setFeeCollector(). \n- L1 surplus fee: Any extra fees rewarded to the batch poster. This is paid to a specific L1RewardRecipient, which can be set by calling
ArbOwner.setL1PricingRewardRecipient() \n
\n\nMore detailed information about fees can be found in the L1 fees and L2 fees pages.\n
\n\n\nInformation about the precompiles methods can be found in the Precompiles reference page.\n
\n\n","key": "what-fee-collectors-can-be-configured-on-my-chain"}
]
\ No newline at end of file
diff --git a/website/static/glossary.json b/website/static/glossary.json
index 5dd7bb880..d87422759 100644
--- a/website/static/glossary.json
+++ b/website/static/glossary.json
@@ -21,7 +21,7 @@
"batch":{"title":"Batch","text":"\nA group of Arbitrum transactions posted in a single transaction on the Underlying Chain into the Fast Inbox by the Sequencer.\n
"},
"blockchain":{"title":"Blockchain","text":"\nA distributed digital ledger that is used to record transactions and store data in a secure, transparent, and tamper-resistant way, notably in cryptocurrency protocols. \n
"},
"bls-signature":{"title":"BLS Signature","text":"\nA cryptographic scheme that allows multiple signatures to be aggregated and compacted into one efficiently verifiable, constant-sized signature. Used in the Arbitrum AnyTrust Protocol for the Data Availability Committee (DAC)'s signatures.\n
"},
-"bold":{"title":"BOLD","text":"\nShort for \"Bounded Liquidity Delay\"; latest version of the Arbitrum Challenge protocol designed to eliminate delay attack vectors (see here for more). Not currently on mainnet. \n
"},
+"bold":{"title":"BoLD","text":"\nShort for \"Bounded Liquidity Delay\"; latest version of the Arbitrum Challenge protocol designed to eliminate delay attack vectors (see here for more). Not currently on mainnet. \n
"},
"bridge":{"title":"Bridge","text":"\nA set of smart contracts for sending Cross-chain messages between blockchains. Every Arbitrum chain includes a bridge to/from its Parent chain. \n
"},
"cap-finance":{"title":"CAP Finance","text":"\nWidely considered the most degen community on Arbitrum.\n
\n\n
\nCAP is a decentralized trading protocol. It's designed to be fast and easy to use by anyone.\n
"},
"chain-owner":{"title":"Chain Owner","text":"\nAn entity (i.e., a smart contract) with affordance to carry out critical upgrades to an Arbitrum chain's core protocol; this includes upgrading protocol contracts, setting core system parameters, and adding and removing other chain owners.\n
"},