diff --git a/Cargo.lock b/Cargo.lock index ca8d41a94..0347e3deb 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -7368,7 +7368,7 @@ dependencies = [ [[package]] name = "starknet-devnet" -version = "0.8.0-rc.3" +version = "0.8.0" dependencies = [ "anyhow", "axum", @@ -7393,7 +7393,7 @@ dependencies = [ [[package]] name = "starknet-devnet-core" -version = "0.8.0-rc.3" +version = "0.8.0" dependencies = [ "alloy", "blockifier", @@ -7427,7 +7427,7 @@ dependencies = [ [[package]] name = "starknet-devnet-server" -version = "0.8.0-rc.3" +version = "0.8.0" dependencies = [ "anyhow", "async-trait", @@ -7457,7 +7457,7 @@ dependencies = [ [[package]] name = "starknet-devnet-types" -version = "0.8.0-rc.3" +version = "0.8.0" dependencies = [ "ahash", "apollo_compilation_utils", diff --git a/Cargo.toml b/Cargo.toml index 0f8e9565f..b185ff97e 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -111,9 +111,9 @@ cairo-lang-syntax = "=2.17.0" cairo-lang-utils = "=2.17.0" # Inner dependencies -starknet-types = { version = "0.8.0-rc.3", path = "crates/starknet-devnet-types", package = "starknet-devnet-types" } -starknet-core = { version = "0.8.0-rc.3", path = "crates/starknet-devnet-core", package = "starknet-devnet-core" } -server = { version = "0.8.0-rc.3", path = "crates/starknet-devnet-server", package = "starknet-devnet-server" } +starknet-types = { version = "0.8.0", path = "crates/starknet-devnet-types", package = "starknet-devnet-types" } +starknet-core = { version = "0.8.0", path = "crates/starknet-devnet-core", package = "starknet-devnet-core" } +server = { version = "0.8.0", path = "crates/starknet-devnet-server", package = "starknet-devnet-server" } # Dependabot alerts zerocopy = "0.8.27" diff --git a/crates/starknet-devnet-core/Cargo.toml b/crates/starknet-devnet-core/Cargo.toml index e83771653..417347cbc 100644 --- a/crates/starknet-devnet-core/Cargo.toml +++ b/crates/starknet-devnet-core/Cargo.toml @@ -1,6 +1,6 @@ [package] name = "starknet-devnet-core" -version = "0.8.0-rc.3" +version = "0.8.0" edition = { workspace = true } repository = { workspace = true } license-file = { workspace = true } diff --git a/crates/starknet-devnet-server/Cargo.toml b/crates/starknet-devnet-server/Cargo.toml index a59799dc6..a53e6e29b 100644 --- a/crates/starknet-devnet-server/Cargo.toml +++ b/crates/starknet-devnet-server/Cargo.toml @@ -1,6 +1,6 @@ [package] name = "starknet-devnet-server" -version = "0.8.0-rc.3" +version = "0.8.0" edition = { workspace = true } repository = { workspace = true } license-file = { workspace = true } diff --git a/crates/starknet-devnet-types/Cargo.toml b/crates/starknet-devnet-types/Cargo.toml index 222effd5e..b9ef5edea 100644 --- a/crates/starknet-devnet-types/Cargo.toml +++ b/crates/starknet-devnet-types/Cargo.toml @@ -1,6 +1,6 @@ [package] name = "starknet-devnet-types" -version = "0.8.0-rc.3" +version = "0.8.0" edition = { workspace = true } description = "Starknet types for the devnet" repository.workspace = true diff --git a/crates/starknet-devnet/Cargo.toml b/crates/starknet-devnet/Cargo.toml index 88361724b..40a331184 100644 --- a/crates/starknet-devnet/Cargo.toml +++ b/crates/starknet-devnet/Cargo.toml @@ -1,6 +1,6 @@ [package] name = "starknet-devnet" -version = "0.8.0-rc.3" +version = "0.8.0" edition = { workspace = true } repository = { workspace = true } license-file = { workspace = true } diff --git a/website/versioned_docs/version-0.8.0-rc.0/proofs.md b/website/versioned_docs/version-0.8.0-rc.0/proofs.md deleted file mode 100644 index e6dfe6047..000000000 --- a/website/versioned_docs/version-0.8.0-rc.0/proofs.md +++ /dev/null @@ -1,143 +0,0 @@ -# Transaction proofs and proof modes - -This page describes the Devnet-specific transaction proof flow introduced in Starknet v0.14.2 and the `--proof-mode` configuration. - -## Important distinction: storage proofs vs transaction proofs - -- `starknet_getStorageProof` is still not supported in Devnet. -- `starknet_proveTransaction` is a separate Devnet extension for proving/validating `INVOKE v3` transaction payloads in a Devnet-oriented way. -- If you are looking for Merkle-Patricia storage proofs, this page is **not** about that feature. - -## Proof modes - -Proof behavior is controlled by `--proof-mode` (or env var `PROOF_MODE`). - -### Mode summary - -| Mode | CLI value | What `starknet_proveTransaction` does | How `starknet_addInvokeTransaction` treats `proof` and `proof_facts` | -| ------ | ------------------ | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | -| Full | `full` | Not implemented yet | Rejects with unsupported action | -| Devnet | `devnet` (default) | Returns a deterministic mock proof + proof facts | If both fields are present, verifies them; if one is missing or verification fails, rejects; if both are absent, accepts | -| None | `none` | Disabled / unsupported | Ignores incoming `proof` and `proof_facts` for invoke txs | - -### Why this exists - -`devnet` mode is a practical mode for local testing: - -- You can request a proof for a specific `INVOKE v3` payload. -- You can later attach that proof to a transaction and exercise proof-aware flows. -- Verification is deterministic and lightweight, intended for development workflows rather than real on-chain proving. - -## Configuration - -### CLI - -```bash -starknet-devnet --proof-mode devnet -``` - -```bash -starknet-devnet --proof-mode none -``` - -```bash -starknet-devnet --proof-mode full -``` - -### Environment variable - -```bash -PROOF_MODE=devnet starknet-devnet -``` - -### Docker - -```bash -docker run --rm -p 5050:5050 \ - -e PROOF_MODE=devnet \ - shardlabs/starknet-devnet-rs -``` - -## RPC: `starknet_proveTransaction` - -### Request shape - -`starknet_proveTransaction` accepts: - -- `block_id` -- `transaction` (a broadcasted `INVOKE v3` transaction payload) - -Example: - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "method": "starknet_proveTransaction", - "params": { - "block_id": "latest", - "transaction": { - "type": "INVOKE", - "version": "0x3", - "sender_address": "0x1234", - "calldata": ["0x1", "0x2"], - "signature": [], - "nonce": "0x0", - "resource_bounds": { - "l1_gas": { "max_amount": "0x0", "max_price_per_unit": "0x0" }, - "l1_data_gas": { "max_amount": "0x0", "max_price_per_unit": "0x0" }, - "l2_gas": { "max_amount": "0x0", "max_price_per_unit": "0x0" } - }, - "tip": "0x0", - "paymaster_data": [], - "account_deployment_data": [], - "nonce_data_availability_mode": "L1", - "fee_data_availability_mode": "L1" - } - } -} -``` - -### Response shape - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": { - "proof": "", - "proof_facts": [ - "0x...", - "0x...", - "0x...", - "0x...", - "0x...", - "0x...", - "0x...", - "0x..." - ] - } -} -``` - -`proof_facts` length is expected to be 8 in devnet mode. - -## Mode-specific behavior details - -### `devnet` mode (default) - -- `starknet_proveTransaction` is enabled. -- Invoke handling rules: - - both `proof` + `proof_facts` present and valid → accepted - - both present but invalid → rejected - - only one present → rejected - - both absent → accepted - -### `none` mode - -- Proof fields on invoke transactions are ignored. - -### `full` mode - -- Full proving/verification is not implemented yet. -- Endpoints and transactions requiring full verification return unsupported-action errors. diff --git a/website/versioned_docs/version-0.8.0-rc.1/account-impersonation.md b/website/versioned_docs/version-0.8.0-rc.1/account-impersonation.md deleted file mode 100644 index 951860c27..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/account-impersonation.md +++ /dev/null @@ -1,92 +0,0 @@ -# Account impersonation - -:::info - -This page is about account impersonation. To read about account class selection and deployment, click [here](./predeployed). - -::: - -## Introduction - -Devnet allows you to impersonate an account that exists on the Starknet mainnet or testnet. This is achieved by skipping the validation step of transactions for all or some accounts, on a running Devnet via JSON-RPC. - -A transaction sent from an impersonated account will not fail with an invalid signature error, which is what happens in the general case of locally absent accounts. For impersonation to work, Devnet needs to [fork](./forking.md) the network that has the desired account. - -:::warning Caveat - -- Only `INVOKE` and `DECLARE` transactions are supported. `DEPLOY_ACCOUNT` transaction is not supported, but you can create an `INVOKE` transaction to UDC. -- Due to the validation step being skipped, the overall fee of transactions sent with an impersonated account will be lower than regular transactions. -- Trying to send a transaction with an account that **does not** even exist in the origin network returns an error: - - `ContractNotFound` if, during transaction preparation, you do not specify a nonce value, leading to the implicit querying of Devnet for the nonce. - - `InsufficientAccountBalance` or similar if the nonce is supplied in the transaction; this happens because the token balance of a non-existent contract is 0 indeed insufficient. - -::: - -## Tips - -- The impersonated account may have had all or a part of its funds used up on the origin network. You may need to give it more funds via [minting](./balance.md). -- If you're defining a new account in your Starknet client application (starknet.js, starknet.rs, starkli...), you may need to specify a private key for it. Since the signature validation is skipped, you may provide a dummy key. - -## API - -Account impersonation follows JSON-RPC method specification. Each method returns an empty response: - -### devnet_impersonateAccount - -Impersonates a specific account address nonexistent in the local state. - -```js -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_impersonateAccount", - "params": { - "account_address": "0x49D36570D4E46F48E99674BD3FCC84644DDD6B96F7C741B1562B82F9E004DC7" - } -} -``` - -### devnet_stopImpersonateAccount - -Stops the impersonation of an account previously marked for impersonation. - -```js -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_stopImpersonateAccount", - "params": { - "account_address": "0x49D36570D4E46F48E99674BD3FCC84644DDD6B96F7C741B1562B82F9E004DC7" - } -} -``` - -### devnet_autoImpersonate - -Enables automatic account impersonation. Every account that does not exist in the local state will be impersonated. - -```js -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_autoImpersonate", - "params": {} -} -``` - -### devnet_stopAutoImpersonate - -Stops the effect of [automatic impersonation](#devnet_autoimpersonate). - -```js -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_stopAutoImpersonate", - "params": {} -} -``` - -## Preventing impersonation - -If you want to learn about completely preventing impersonation from being activated on your Devnet, click [here](./restrictive.md). diff --git a/website/versioned_docs/version-0.8.0-rc.1/api.md b/website/versioned_docs/version-0.8.0-rc.1/api.md deleted file mode 100644 index 7ee0c5e6a..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/api.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -sidebar_position: 3 ---- - -# API - -## JSON-RPC API - -Both Starknet's and Devnet's JSON-RPC API are reachable at `/rpc` and `/`. E.g. if spawning Devnet with default settings, these URLs are functionally equivalent: `http://127.0.0.1:5050/rpc` and `http://127.0.0.1:5050/`. The difference between these two groups of methods is their prefix: `starknet_` (e.g. `starknet_getNonce`) and `devnet_` (e.g. `devnet_mint`). - -### Starknet API - -Unlike Pythonic Devnet, which also supported Starknet's gateway and feeder gateway API, Devnet in Rust supports [Starknet's JSON-RPC API](https://github.com/starkware-libs/starknet-specs/tree/master/api), including [WebSocket support](#websocket). - -Due to how Devnet internally works, the method `starknet_getStorageProof` is not applicable, and thus not supported. - -Devnet also provides a proof-related extension method `starknet_proveTransaction`. For supported modes, behavior, and usage examples, check [Transaction proofs and proof modes](./proofs). - -Since JSON-RPC v0.6.0, to find out which JSON-RPC version is supported by which Devnet version, check out the [releases page](https://github.com/0xspaceshard/starknet-devnet/releases). - -### Devnet API - -Devnet has many additional features available via JSON-RPC. The RPC methods are documented throughout the documentation in their corresponding pages, but are also aggregated [here](https://github.com/0xSpaceShard/starknet-devnet/blob/main/website/static/devnet_api.json). - -#### Healthcheck - -To check if a Devnet instance is alive, send an HTTP request `GET /is_alive`. If alive, Devnet will reply with a `200 OK` and an appropriate message. This is the only special functionality not provided as part of the JSON-RPC API. - -### WebSocket - -The whole [Starknet](#starknet-api) and [Devnet](#devnet-api) JSON-RPC API, including [WebSocket subscription methods](https://github.com/starkware-libs/starknet-specs/blob/v0.9.0/api/starknet_ws_api.json) can be accessed via the WebSocket protocol, using text or binary messages. Devnet listens for new WebSocket connections at `ws://:/ws` (notice the protocol scheme). E.g. using [`wscat`](https://www.npmjs.com/package/wscat) on the same computer where Devnet is spawned at default host and port: - -``` -$ wscat -c ws://127.0.0.1:5050/ws -Connected (press CTRL+C to quit) -> { "jsonrpc": "2.0", "id": 0, "method": "starknet_subscribeNewHeads" } -< {"id":0,"result":2935616350010920547,"jsonrpc":"2.0"} -``` - -#### WebSocket persistence - -[Restarting](./dump-load-restart#restarting) and [loading](./dump-load-restart#loading) do not affect Devnet's WebSocket connections, but remove all subscriptions. - -## Interacting with Devnet in JavaScript and TypeScript - -To spawn Devnet and interact with it using the [Devnet API](#devnet-api), you can use [`starknet-devnet-js`](https://github.com/0xSpaceShard/starknet-devnet-js/). This can be especially useful in achieving [L1-L2 communication](./postman.md). - -To interact with Devnet using the [Starknet API](#starknet-api), use [starknet.js](https://www.starknetjs.com/). - -## Config API - -To retrieve the current configuration of Devnet, as specified via [CLI](running/cli.md) and later requests, send a `JSON-RPC` request with method name `devnet_getConfig`. Example response is attached below. It can be interpreted as a JSON mapping of CLI input parameters, both specified and default ones, with some irrelevant parameters omitted. So use `starknet-devnet --help` to better understand the meaning of each value, though keep in mind that some of the parameters have slightly modified names. The exact values may have changed and should not be referenced. - -```json -{ - "seed": 4063802897, - "total_accounts": 10, - "account_contract_class_hash": "0x61dac032f228abef9c6626f995015233097ae253a7f72d68552db02f2971b8f", - "predeployed_accounts_initial_balance": "1000000000000000000000", - "start_time": null, - "gas_price_wei": 100000000000, - "gas_price_fri": 100000000000, - "data_gas_price_wei": 100000000000, - "data_gas_price_fri": 100000000000, - "l2_gas_price_wei": 100000000000, - "l2_gas_price_fri": 100000000000, - "chain_id": "SN_SEPOLIA", - "dump_on": "exit", - "dump_path": "dump_path.json", - "state_archive": "none", - "fork_config": { - "url": "http://rpc.pathfinder.equilibrium.co/integration-sepolia/rpc/v0_7", - "block_number": 26429 - }, - "server_config": { - "host": "127.0.0.1", - "port": 5050, - "timeout": 120, - "restricted_methods": null - }, - "block_generation": null, - "lite_mode": false, - "eth_erc20_class_hash": "0x046ded64ae2dead6448e247234bab192a9c483644395b66f2155f2614e5804b0", - "strk_erc20_class_hash": "0x046ded64ae2dead6448e247234bab192a9c483644395b66f2155f2614e5804b0" -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.1/balance.md b/website/versioned_docs/version-0.8.0-rc.1/balance.md deleted file mode 100644 index db9cf475f..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/balance.md +++ /dev/null @@ -1,65 +0,0 @@ -# Account balance - -Other than using prefunded predeployed accounts, you can also add funds to an account that you deployed yourself. - -Separate tokens use separate ERC20 contracts for minting and charging fees. These are the token contracts predeployed by Devnet and the addresses where they are located: - -- ETH: `0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7` -- STRK: `0x04718f5a0fc34cc1af16a1cdee98ffb20c31f5cd61d6ab07201858f4287c938d` - -## Mint token - Local faucet - -By sending a `JSON-RPC` request with method name `devnet_mint` for a token, you initiate a transaction on that token's ERC20 contract. The response contains the hash of this transaction, as well as the new balance after minting. The token is specified by providing the unit, and defaults to `FRI` (the unit of `STRK`). - -The value of `amount` is in WEI or FRI. The precision is preserved if specifying an integer or a float whose fractional part is zero (e.g. `1000.0`, `1e21`). If the fractional part is non-zero, the amount is truncated to the nearest integer (e.g. `3.9` becomes `3` and `1.23e1` becomes `12`). - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_mint", - "params": { - "address": "0x6e3205f...", - "amount": 500000, - "unit": "WEI" | "FRI" - } -} -``` - -Result: - -``` -{ - "new_balance": 500000, - "unit": "WEI" | "FRI", - "tx_hash": "0xa24f23..." -} -``` - -In case of a reverted minting request, an error is returned containing the stringified revert reason and the hex string of the hash of the reverted transaction for further inspection: - -``` -{ - "tx_hash": "0x123..." - "revert_reason": "Something happened" -} -``` - -## Check balance - -Check the balance of an address by sending a `JSON-RPC` request. The address should be a 0x-prefixed hex string; `unit` defaults to `FRI` (the unit of `STRK`) and `block_id` to `latest`. - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_getAccountBalance", - "params": { - "address": "0x6e3205f...", - "unit": "WEI" | "FRI", - "block_id": - } -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.1/blocks.md b/website/versioned_docs/version-0.8.0-rc.1/blocks.md deleted file mode 100644 index 91e7db154..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/blocks.md +++ /dev/null @@ -1,182 +0,0 @@ -# Blocks - -## State commitment - -Block states are not committed in a Merke-Patricia trie or a similar tree-like structure. Block roots are therefore set to 0. - -## Genesis block - -By default, Devnet starts with a genesis block labelled with number zero. In [forking mode](./forking), the genesis block number is equal to the forked block number plus one. - -## Limits - -To read more about block limits, see [this](./intro#limits). - -## Creating blocks on transaction - -If you start Devnet with `--block-generation-on transaction`, a new block is generated with each new transaction. This is the default block generation regime. This mode also supports [empty block creation](#request-new-block-creation). - -## Creating blocks on demand - -If you start Devnet with the `--block-generation-on demand` CLI option, you will enable the possibility to store more than one transaction in the pre-confirmed block (targetable via block tag `"pre_confirmed"`). - -Once you've added the desired transactions into the pre-confirmed block, you can [request new block creation](#request-new-block-creation). This will convert the pre-confirmed block to the latest block (targetable via block tag `"latest"`), giving it a block hash and a block number. All subsequent transactions will be stored in a new pre-confirmed block. - -In case of demanding block creation with no pre-confirmed transactions, a new empty block will be generated. - -The creation of the genesis block is not affected by this feature. - -The specifications of a block-creating request can be found [below](#request-new-block-creation). - -## Automatic periodic block creation - -If started with the `--block-generation-on ` CLI option, Devnet will behave as in [`demand` mode](#creating-blocks-on-demand), but new blocks will be mined automatically every `` seconds. Consider this example of spawning Devnet at moment `t`: - -```bash -# t -$ starknet-devnet --block-generation-on 10 - -# t + 1s -# user: send tx1 - -# t + 4s -# user: send tx2 - -# t + 10s -# Devnet: block automatically generated, contains tx1 and tx2 - -# t + 12s -# user: send tx3 - -# t + 14s -# user: invoke empty block creation -# Devnet: generated block contains tx3 - -# t + 20s -# Devnet: block automatically generated, contains no txs (manual creation did not restart the counter) -``` - -## Request new block creation - -To request the creation of a new block, send: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_createBlock" -} -``` - -Result: - -``` -{"block_hash": "0x115e1b390cafa7942b6ab141ab85040defe7dee9bef3bc31d8b5b3d01cc9c67"} -``` - -The newly created block will contain all pre-confirmed transactions, if any, since the last block creation. - -## Timestamp manipulation - -To affect the timestamp of the newly created block, check out [this page](./starknet-time#set-time) - -## Block abortion - -This functionality allows simulating block abortion that can occur on mainnet as a consequence of e.g. block reorganization. Aborted blocks and their transactions are removed from Devnet's memory. - -:::note - -Block abortion is only supported if Devnet is started in the `--state-archive-capacity full` mode. - -::: - -You can abort blocks and revert transactions from the specified block to the currently latest block. Newly created blocks after the abortion will have accepted status and will continue with numbering where the last accepted block left off. - -The state of Devnet will be reverted to the state of the last accepted block. - -### Example - -Assume there are 3 accepted blocks numbered 1, 2 and 3. Upon receiving a request to abort blocks starting with block 2, the blocks numbered 2 and 3 are aborted and their transactions reverted. The state of network will be as it was in block 1. Once a new block is mined, it will be accepted and it will have number 2. - -### Limitations - -Aborted blocks can only be queried by block hash. Devnet does not support the abortion of: - -- blocks in the forking origin (i.e. blocks mined before the forked block) -- already aborted blocks -- Devnet's genesis block. - -### Websocket subscription notifications - -On block abortion, a `starknet_subscriptionReorg` notification will be sent to all websocket subscribers requiring so according to [JSON-RPC websocket API specification](https://github.com/starkware-libs/starknet-specs/blob/v0.8.0/api/starknet_ws_api.json#L236). The `starting_block` of the orphaned chain is the successor of the new latest block and the `ending_block` of the orphaned chain is the block that was latest before aborting. One reorg notification is sent per subscription, not per websocket, meaning that if a websocket has n subscriptions, it will receive n reorg notifications, each with its own subscription ID. - -If a socket has subscribed to transaction status changes of a transaction `tx1` using `starknet_subscribeTransactionStatus` and the block holding `tx1` gets aborted, a `starknet_subscriptionTransactionStatus` notification shall NOT be sent. The socket shall have to rely on handling `starknet_subscriptionReorg`. - -### Request and response - -To abort, send: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_abortBlocks", - "params": { - "starting_block_id": BLOCK_ID - } -} -``` - -Result: - -``` -{ - "aborted": [BLOCK_HASH_0, BLOCK_HASH_1, ...] -} -``` - -:::note - -When aborting the currently `pre_confirmed` block, it is mined and aborted as latest. - -::: - -## Accepting blocks on L1 - -This functionality allows simulating block acceptance on L1 (Ethereum). It merely marks the requested blocks and their transactions as `ACCEPTED_ON_L1`. It is only supported on blocks that are `ACCEPTED_ON_L2` and fails for all others, including blocks already `ACCEPTED_ON_L1`. In case of [forking](./forking), blocks on forking origin cannot be affected by this feature. - -:::note - -This functionality does not actually perform actions on L1. - -::: - -### Example - -Assume Devnet has mined blocks with numbers: 0 (origin), 1, 2 and 3. If this feature is invoked with `starting_block_id={"block_number": 2}`, blocks 0, 1 and 2 shall be `ACCEPTED_ON_L1` and block 3 shall remain `ACCEPTED_ON_L2`. If after that another block (number 4) is mined, and this feature is invoked with `starting_block_id="latest"`, blocks 0, 1, 2, 3 and 4 shall be `ACCEPTED_ON_L1`. If a new block is mined after that (number 5), it shall be `ACCEPTED_ON_L2`. - -### Request and response - -To accept a block and its transactions on L1, send: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_acceptOnL1", - "params": { - "starting_block_id": BLOCK_ID - } -} -``` - -Result: - -``` -{ - "accepted": [BLOCK_HASH_0, BLOCK_HASH_1, ...] -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.1/dump-load-restart.md b/website/versioned_docs/version-0.8.0-rc.1/dump-load-restart.md deleted file mode 100644 index 7735dc212..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/dump-load-restart.md +++ /dev/null @@ -1,144 +0,0 @@ -# Dump, load, restart - -## Dumping - -To preserve your Devnet instance for future use, these are the options: - -- Dumping on exit (handles Ctrl+C, i.e. SIGINT; doesn't handle SIGKILL): - -``` -$ starknet-devnet --dump-on exit --dump-path -``` - -- Dumping after each block: - -``` -$ starknet-devnet --dump-on block --dump-path -``` - -- Dumping on request, which requires providing `--dump-on request` on startup. You can also dump on request if you specified any of the other `--dump-on` modes. - -### Dumping on request - -You can request dumping via JSON-RPC. An optional file path can be provided in the request or on startup via `--dump-path ` (the HTTP request parameter takes precedence). If no dumping path is specified, the dump is included in the response body. This means that if you request dumping via [`curl`](https://curl.se/), it will be printed to STDOUT, which you can then redirect to a destination of your choice. - -``` -$ starknet-devnet --dump-on [--dump-path ] -``` - -- No body parameters: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_dump" -} -``` - -- With a custom path: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_dump", - "params": { - // optional; defaults to the path specified via CLI if defined - "path": - } -} -``` - -## Loading - -To load a preserved Devnet instance, the options are: - -- Loading on startup (note the argument name is not `--load-path` as it was in Devnet-py): - -``` -$ starknet-devnet --dump-path -``` - -- Loading on request, which replaces the current state with the one in the provided file. It can be done via JSON-RPC: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_load", - "params": { - "path": - } -} -``` - -### Loading disclaimer - -Currently, dumping produces a list of reproducible Devnet actions (state-changing requests and transactions). Conversely, loading is implemented as the re-execution of transactions from a dump. This means that timestamps of `StarknetBlock` will be different on each load. This is due to the nature of Devnet's dependencies, which prevent Devnet's state from being serialized. - -Dumping and loading are not guaranteed to work across versions. I.e. if you dumped one version of Devnet, do not expect it to be loadable with a different version. - -If you dumped a Devnet utilizing one class for account predeployment (e.g. `--account-class cairo0`), you should use the same option when loading. The same applies for dumping a Devnet in `--block-generation-on demand` mode. - -Loading does not affect WebSocket connections, but removes all WebSocket [subscriptions](./api#websocket). - -## Restarting - -Devnet can be restarted by making a `JSON-RPC` request with method name `devnet_restart`. All deployed contracts (including predeployed), blocks and storage updates will be restarted to the original state, without the transactions and requests that may have been loaded from a dump file on startup. - -Restarting does not affect WebSocket connections, but removes all WebSocket [subscriptions](./api#websocket). - -### Restarting and L1-L2 messaging - -If you're doing [L1-L2 message exchange](./postman), restarting will by default not affect Devnet's connection with L1 nor the L1->L2 message queue. The effect that L1-L2 messages may have had on Devnet before restarting shall be reverted, including any L2 contracts used for messaging. Also, calling [`flush`](./postman#flush) will not have new messages to read until they are actually sent. If you wish to re-process the already-seen L1->L2 messages when you restart, make them accessible again by setting the `restart_l1_to_l2_messaging` parameter shown below. If you set this flag: - -- you will need to [reload the L1-side messaging contract](./postman#load) -- the L1->L2 messages won't be restarted in the sense of being deleted, but access to them shall be regained via [`flush`](./postman#flush) -- the L2->L1 message queue is restarted regardless of the flag - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_restart", - "params": { - // optional parameter, defaults to false - "restart_l1_to_l2_messaging": true | false - } -} -``` - -## Docker - -To enable dumping and loading with dockerized Devnet, you must bind the container path to the path on your host machine. - -This example: - -- Relies on [Docker bind mount](https://docs.docker.com/storage/bind-mounts/); try [Docker volume](https://docs.docker.com/storage/volumes/) instead. -- Assumes that `/path/to/dumpdir` exists. If unsure, use absolute paths. -- Assumes you are listening on `127.0.0.1:5050`. - -If there is `mydump` inside `/path/to/dumpdir`, you can load it with: - -``` -docker run \ - -p 127.0.0.1:5050:5050 \ - --mount type=bind,source=/path/to/dumpdir,target=/path/to/dumpdir \ - shardlabs/starknet-devnet-rs \ - --dump-path /path/to/dumpdir/mydump -``` - -To dump to `/path/to/dumpdir/mydump` on Devnet shutdown, run: - -``` -docker run \ - -p 127.0.0.1:5050:5050 \ - --mount type=bind,source=/path/to/dumpdir,target=/path/to/dumpdir \ - shardlabs/starknet-devnet-rs \ - --dump-on exit --dump-path /path/to/dumpdir/mydump -``` diff --git a/website/versioned_docs/version-0.8.0-rc.1/examples.md b/website/versioned_docs/version-0.8.0-rc.1/examples.md deleted file mode 100644 index 5704af4da..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/examples.md +++ /dev/null @@ -1,3 +0,0 @@ -# Examples - -Usage examples relying on the [`starknet-devnet-js`](https://github.com/0xspaceShard/starknet-devnet-js) library can be found [here](https://github.com/0xSpaceShard/starknet-devnet-js/tree/master/test). diff --git a/website/versioned_docs/version-0.8.0-rc.1/forking.md b/website/versioned_docs/version-0.8.0-rc.1/forking.md deleted file mode 100644 index 8fa081264..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/forking.md +++ /dev/null @@ -1,47 +0,0 @@ -# Forking - -To interact with contracts deployed on mainnet or testnet, you can use forking. Simulate the origin and experiment with it locally, making no changes to the origin itself. - -``` -$ starknet-devnet --fork-network [--fork-block ] -``` - -The value passed to `--fork-network` should be the URL to a Starknet JSON-RPC API provider. Specifying a `--fork-block` is optional; it defaults to the `"latest"` block at the time of Devnet's start-up. All calls will first try Devnet's state and then fall back to the forking block. - -:::note How it works - -When you send a request to a forked Devnet instance, it first queries Devnet's local state, then tries the forking origin. Forking is not a step simply performed on Devnet startup, but happens continuously while the Devnet instance is alive. - -::: - -## Upstream caching - -By default, Devnet does not cache responses from the fork upstream network. However, you can enable caching to improve performance and reduce the number of requests sent to the origin by using the `--fork-upstream-caching` flag: - -``` -$ starknet-devnet --fork-network --fork-upstream-caching -``` - -:::tip Performance improvement - -Enabling upstream caching can significantly improve performance by reducing redundant requests to the fork origin. - -::: - -## Forking and ACCEPTED_ON_L1 - -Assume you have run Devnet as a fork from an origin at a block that is not yet `ACCEPTED_ON_L1`, but only `ACCEPTED_ON_L2`. If in your state queries you specify `block_id: "l1_accepted"`, and there are no local blocks marked as `ACCEPTED_ON_L1`, Devnet will assume the forking block has become `ACCEPTED_ON_L1`. - -Read more about marking blocks as `ACCEPTED_ON_L1` on Devnet: [link](./blocks#accepting-blocks-on-l1). - -## Account impersonation - -[Here](./account-impersonation) you can read more about acting as an account deployed on the origin. - -## Deploying an undeclared account - -[Here](./predeployed#deploying-an-undeclared-account) you can read about deploying an account not declared on Devnet. - -## Checking forking status - -To see if your Devnet instance is using forking or not, [fetch the current configuration](./api#config-api), and check the `url` property of its `fork_config` property. If Devnet is forked, this property contains the string of the origin URL specified on startup. diff --git a/website/versioned_docs/version-0.8.0-rc.1/gas.md b/website/versioned_docs/version-0.8.0-rc.1/gas.md deleted file mode 100644 index fcff305bb..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/gas.md +++ /dev/null @@ -1,55 +0,0 @@ -# Gas price modification - -## On Devnet startup - via CLI - -All gas prices (L1 gas, L1 data gas, L2 gas) can be specified on startup, via their respective CLI params. Check `starknet-devnet --help | grep price` for more info. - -## On a running Devnet - via JSON-RPC - -The `devnet_setGasPrice` RPC method allows users to modify the current gas prices on a running Devnet. This feature is particularly useful for testing purposes and for adjustments needed after forking to align with the forked network's gas prices. All parameters are optional, allowing you to choose which ones you want to set. A boolean flag `generate_block` indicates whether a new block should be generated immediately after setting the gas prices. - -### Explanation - -The modified gas prices take effect starting with the next block that is generated. - -### generate_block - -- When set to `true`, a new block will be generated immediately after the gas prices are set. This ensures that the changes take effect right away and are reflected in the devnet state without waiting for the next block generation. -- When set to `false` (or omitted), the gas prices will be set, but the changes will not be immediately committed to the devnet state until the next block is generated through the usual block generation process. - -### JSON-RPC Request - -The following JSON-RPC request can be used to set gas prices (all properties optional): - -```json -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_setGasPrice", - "params": { - "gas_price_wei": 1000000, - "data_gas_price_wei": 10000, - "gas_price_fri": 10000, - "data_gas_price_fri": 10000, - "l2_gas_price_wei": 1000000, - "l2_gas_price_fri": 10000, - "generate_block": false, - } -} -``` - -## Response - -The expected response from the server will mirror the request gas parameters, confirming the modification of gas prices: - -```json -{ - "gas_price_wei": 1000000, - "data_gas_price_wei": 10000, - "gas_price_fri": 10000, - "data_gas_price_fri": 10000, - "l2_gas_price_wei": 10000, - "l2_gas_price_fri": 10000 -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.1/historic-state.md b/website/versioned_docs/version-0.8.0-rc.1/historic-state.md deleted file mode 100644 index f2358c680..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/historic-state.md +++ /dev/null @@ -1,9 +0,0 @@ -# Historic state support - -With state archive capacity set to `full`, Devnet will store full state history, enabling its querying by block hash or number. The default mode is `none`, where no old states are stored and only the latest is available for querying. - -``` -$ starknet-devnet --state-archive-capacity -``` - -All RPC endpoints that support querying the state at an old (non-latest) block only work with state archive capacity set to `full`. diff --git a/website/versioned_docs/version-0.8.0-rc.1/intro.md b/website/versioned_docs/version-0.8.0-rc.1/intro.md deleted file mode 100644 index 7d498fb75..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/intro.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Intro - -:::danger Difference disclaimer - -- Devnet should not be used as a replacement for the official testnet. After testing on Devnet, be sure to test on testnet (alpha-sepolia)! -- Devnet does not organize state data into Merkle-Patricia tries or similar tree-like structures, so: - - Calling the `starknet_getStorageProof` RPC method shall always result in `STORAGE_PROOF_NOT_SUPPORTED`. - - Block roots are set to 0. -- The pre-confirmed block is equivalent to the old pending block, except that its transactions are not `ACCEPTED_ON_L2` but `PRE_CONFIRMED`. -- By default, a new block is mined for each new transaction. - - This can be modified by directing all new transactions into a pre-confirmed block, and at some point triggering block creation. - - Transactions in a pre-confirmed block cannot be replaced by sending a transaction with a higher free from the same account. - - Read more about transitioning a transaction [from `PRE_CONFIRMED` to `ACCEPTED_ON_L2`](./blocks#creating-blocks-on-demand). -- Block hashes on devnet differ from mainnet because some mainnet block fields are unavailable to devnet, resulting in different hash outputs despite using the same hashing algorithm. -- Transactions are never automatically `ACCEPTED_ON_L1`, unless the user performs an action. - - Read more about transitioning a transaction [from `ACCEPTED_ON_L2` to `ACCEPTED_ON_L1`](./blocks#accepting-blocks-on-l1). -- `RECEIVED` and `CANDIDATE` statuses are not used in Devnet. -- In Starknet 0.14.1, field `migrated_compiled_classes` was introduced to the `state_diff`. In devnet, this field will always be empty: - - When starting devnet without forking there is nothing to migrate - - In forking mode, there is no RPC support to fetch compiled class hashes from origin, so it is impossible for devnet to determine which classes have to be migrated - -::: - -You may now proceed with [running Devnet](./running/install) and checking out the multitude of features listed in the sidebar on the left. - -# Limits - -As mentioned [here](https://docs.starknet.io/tools/limits-and-triggers/), "Starknet currently has a number of limits in place in order to keep the network stable and optimized for the best performance." Devnet uses the limits defined on that page and, for block-level limits, values defined [here (provided by the Blockifier team)](https://github.com/0xSpaceShard/starknet-devnet/blob/main/crates/starknet-devnet-core/src/utils.rs). The block-level limits are considered only when executing transactions, not when constructing the blocks themselves. I.e. if a transaction's usage of a resource exceeds its defined block-level limit, it will be reverted; but if the cumulative usage of all transactions in a block of one resource exceeds the block limit, the block will still be generated. diff --git a/website/versioned_docs/version-0.8.0-rc.1/lite.md b/website/versioned_docs/version-0.8.0-rc.1/lite.md deleted file mode 100644 index 9075f886c..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/lite.md +++ /dev/null @@ -1,22 +0,0 @@ -# Lite mode - -To run Devnet in a minimal lite mode, provide the flag: - -``` -$ starknet-devnet --lite-mode -``` - -Steps skipped in lite mode: - -- **Calculating block hash**: Block hash is simplified and derived from the block number instead of computing the full cryptographic hash -- **Calculating block commitments**: Skips computation of transaction commitment, event commitment, state diff commitment, and receipt commitment - -In lite mode, blocks are still created and transactions are executed normally, but the computationally expensive cryptographic operations for generating block hashes and commitments are bypassed. This improves performance for development and testing scenarios where these values are not required. - -This is useful if your use-case doesn't need the functionalities above, such as when: - -- Testing transaction execution logic -- Running integration tests that don't verify block hashes or commitments -- Rapid prototyping and development iteration - -The extent of what is affected by lite mode may be expanded in the future. diff --git a/website/versioned_docs/version-0.8.0-rc.1/metrics.md b/website/versioned_docs/version-0.8.0-rc.1/metrics.md deleted file mode 100644 index 4c03cf6bc..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/metrics.md +++ /dev/null @@ -1,197 +0,0 @@ -# Metrics - -Starknet Devnet can expose Prometheus-compatible metrics for monitoring and observability. This feature allows you to track RPC calls, block creation, transactions, and upstream forking calls. - -## Enabling Metrics - -To enable metrics, start Devnet with the `--metrics-host` parameter: - -```bash -$ starknet-devnet --metrics-host -``` - -By default, the metrics server will listen on port `9090`. You can customize the port with the `--metrics-port` parameter: - -```bash -$ starknet-devnet --metrics-host 127.0.0.1 --metrics-port 8080 -``` - -Or using environment variables: - -```bash -$ METRICS_HOST=127.0.0.1 METRICS_PORT=8080 starknet-devnet -``` - -If running with Docker: - -```bash -$ docker run -e METRICS_HOST=0.0.0.0 -e METRICS_PORT=9090 -p 9090:9090 shardlabs/starknet-devnet-rs -``` - -## Accessing Metrics - -Once the metrics server is running, you can access the metrics endpoint at: - -``` -http://:/metrics -``` - -For example: - -```bash -$ curl http://127.0.0.1:9090/metrics -``` - -The metrics are exposed in Prometheus text format, which can be scraped by Prometheus or other compatible monitoring systems. - -## Available Metrics - -### RPC Metrics - -#### `rpc_call_duration_seconds` - -**Type:** Histogram - -**Description:** Duration of RPC calls in seconds - -**Labels:** - -- `method`: The RPC method name (e.g., `starknet_getBlockWithTxs`, `starknet_call`) - -**Buckets:** 0.00005, 0.0001, 0.00025, 0.0005, 0.001, 0.0025, 0.005, 0.01, 0.015, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0 seconds - -#### `rpc_call_count` - -**Type:** Counter - -**Description:** Total number of RPC calls - -**Labels:** - -- `method`: The RPC method name -- `status`: Either `success` or `error` - -### Starknet Core Metrics - -#### `starknet_transaction_count` - -**Type:** Counter - -**Description:** Total number of transactions in Starknet - -This counter is incremented when a transaction is added to the network and decremented when blocks are aborted. - -#### `starknet_block_count` - -**Type:** Counter - -**Description:** Total number of blocks in Starknet - -This counter is incremented when a new block is created and decremented when blocks are aborted. - -#### `starknet_block_creation_duration_seconds` - -**Type:** Histogram - -**Description:** Duration of block creation in seconds - -**Buckets:** 0.00005, 0.0001, 0.00025, 0.0005, 0.001, 0.0025, 0.005, 0.01 seconds - -This metric tracks how long it takes to generate a new block and transition from the pre-confirmed state. - -### Upstream Forking Metrics - -These metrics are only relevant when running Devnet in [forking mode](./forking.md). - -#### `starknet_upstream_call_duration_seconds` - -**Type:** Histogram - -**Description:** Duration of upstream forking origin calls in seconds - -**Labels:** - -- `method`: The RPC method called on the upstream network -- `status`: Either `success` or `error` - -**Buckets:** 0.001, 0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0 seconds - -#### `starknet_upstream_call_count` - -**Type:** Counter - -**Description:** Total number of upstream forking origin calls - -**Labels:** - -- `method`: The RPC method called on the upstream network -- `status`: Either `success` or `error` - -These metrics help monitor the performance and reliability of interactions with the forked network. - -## Integrating with Prometheus - -To scrape these metrics with Prometheus, add the following job to your `prometheus.yml` configuration: - -```yaml -scrape_configs: - - job_name: 'starknet-devnet' - static_configs: - - targets: ['localhost:9090'] -``` - -Adjust the target address to match your Devnet metrics server configuration. - -## Example Queries - -Here are some example PromQL queries you can use: - -### Average RPC call duration by method - -```promql -rate(rpc_call_duration_seconds_sum[5m]) / rate(rpc_call_duration_seconds_count[5m]) -``` - -### RPC call rate by method - -```promql -rate(rpc_call_count[5m]) -``` - -### RPC error rate - -```promql -rate(rpc_call_count{status="error"}[5m]) / rate(rpc_call_count[5m]) -``` - -### Block creation rate - -```promql -rate(starknet_block_count[5m]) -``` - -### Transaction throughput - -```promql -rate(starknet_transaction_count[5m]) -``` - -### Upstream call error rate (forking mode) - -```promql -rate(starknet_upstream_call_count{status="error"}[5m]) / rate(starknet_upstream_call_count[5m]) -``` - -### 95th percentile block creation time - -```promql -histogram_quantile(0.95, rate(starknet_block_creation_duration_seconds_bucket[5m])) -``` - -## Visualization with Grafana - -You can visualize these metrics using Grafana by: - -1. Adding Prometheus as a data source -2. Creating dashboards with panels using the PromQL queries above -3. Setting up alerts based on metric thresholds diff --git a/website/versioned_docs/version-0.8.0-rc.1/postman.md b/website/versioned_docs/version-0.8.0-rc.1/postman.md deleted file mode 100644 index 88e49f7de..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/postman.md +++ /dev/null @@ -1,193 +0,0 @@ -# L1-L2 interaction via Postman - -Postman is a Starknet utility that allows testing L1-L2 interaction. It is **unrelated** to the [Postman API platform](https://www.postman.com/). To use it, ensure you have: - -- an L1 node (possibilities listed [below](#l1-network)) -- a Devnet instance (acting as L2 node) -- a [loaded](#load) messaging contract - - this is an L1 contract for exchanging messages between L1 and L2 - - you can deploy a new instance or specify the address of an old one -- an L1 contract that can interact with the messaging contract -- an L2 contract that can interact with the messaging contract - -There are two internal message queues: one for L1->L2 messages, another for L2->L1 messages. When there are messages in a queue, you will need to [flush](#flush) to transmit the messages to their destinations. - -You can use [**`starknet-devnet-js`**](https://github.com/0xSpaceShard/starknet-devnet-js) to assist you in the above listed actions. [**This example**](https://github.com/0xSpaceShard/starknet-devnet-js/blob/master/test/l1-l2-postman.test.ts), especially the `it("should exchange messages between L1 and L2")` test case should be of most help. The required contracts are configured and deployed in the `before` block. Alternatively, you can directly send requests to the endpoints specified below. - -## Load - -```json -// JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanLoad", - "params": { - "network_url": "http://localhost:8545", - "messaging_contract_address": "0x123...def", // optional - "deployer_account_private_key": "0xe2ac...583f" // optional - } -} -``` - -Loads an L1 `MockStarknetMessaging` contract instance, potentially deploying a new one, which is used for message exchange between L1 and L2. - -### L1 network - -The `network_url` parameter refers to the URL of the JSON-RPC API endpoint of the L1 node you've run locally, or which is publicly accessible. Possibilities include, but are not limited to: - -- [**Anvil**](https://github.com/foundry-rs/foundry/tree/master#anvil) -- [**Sepolia testnet**](https://sepolia.etherscan.io/) -- [**Ganache**](https://www.npmjs.com/package/ganache) -- [**Geth**](https://github.com/ethereum/go-ethereum#docker-quick-start) -- [**Hardhat node**](https://hardhat.org/hardhat-network/#running-stand-alone-in-order-to-support-wallets-and-other-software) - -### Messaging contract deployment - -Here's how the rest of the parameters should be used, depending on your L1 network: - -- If your L1 network already has a messaging contract deployed that you wish to use, populate `messaging_contract_address` with its address. - - The provided address shall be checked by asserting that there indeed is contract code deployed at that address, without any ABI assertions. -- If your L1 network does not have such a contract, or you simplify wish to deploy a new instance, leave out the `messaging_contract_address` property. - - If your L1 network is a local testnet (e.g. Anvil) with the default mnemonic seed and a default set of predeployed accounts, you don't have to specify anything else—a new messaging contract shall be deployed using a predeployed account. - - Otherwise (e.g. on the Sepolia testnet or an Anvil with a custom mnemonic seed) you are expected to populate `deployer_account_private_key` with the private key of a funded account. This property is not applicable if `messaging_contract_address` is specified. - -:::note L1-L2 with dockerized Devnet - -L1-L2 communication requires extra attention if Devnet is [run in a Docker container](./running/docker.md). The `network_url` argument must be on the same network as Devnet. E.g. if your L1 instance is run locally (i.e. using the host machine's network), then: - -- on Linux, it is enough to run the Devnet Docker container with `--network host` -- on Mac and Windows, replace any `http://localhost` or `http://127.0.0.1` occurrence in the value of `network_url` with `http://host.docker.internal`. - -::: - -:::info Dumping and Loading - -Loading a messaging contract is a dumpable event, meaning that, if you've enabled dumping, a messaging-contract-loading event will be dumped. Keep in mind that, if you rely on Devnet deploying a new contract, i.e. if you don't specify a contract address of an already deployed messaging contract, a new contract will be deployed at a new address on each loading of the dump. Read more about dumping [here](./dump-load-restart#dumping). - -::: - -## Flush - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanFlush" -} -``` - -Goes through the newly enqueued messages since the last flush, consuming and sending them from L1 to L2 and from L2 to L1. Use it for end-to-end testing. Requires no body. Optionally, set the `dry_run` boolean flag to just see the result of flushing, without actually triggering it: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanFlush", - "params": { "dry_run": true } -} -``` - -:::note - -A running L1 node is required if `dry_run` is not set. - -::: - -:::info Dumping and Loading - -Flushing is not dumpable, meaning that, if you've enabled dumping, a flushing event will not itself be re-executed on loading. This is because it produces L2 messaging events that are themselves dumped. No L1-side actions are dumped, you need to take care of those yourself. Read more about dumping [here](./dump-load-restart#dumping). - -::: - -## Disclaimer - -This method of L1-L2 communication testing differs from how Starknet mainnet and testnets work. Taking [**L1L2Example.sol**](https://github.com/MikeSpa/starknet-test/blob/6a68d033cd7ddb5df937154f860f1c06174e6860/L1L2Example.sol#L46) (originally from Starknet documentation, no longer available there): - -```solidity -constructor(IStarknetCore starknetCore_) public { - starknetCore = starknetCore_; -} -``` - -The constructor takes an `IStarknetCore` contract as argument, however for Devnet's L1-L2 communication testing, this has to be replaced with the logic in [**MockStarknetMessaging.sol**](https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/starknet/testing/MockStarknetMessaging.sol): - -```solidity -constructor(MockStarknetMessaging mockStarknetMessaging_) public { - starknetCore = mockStarknetMessaging_; -} -``` - -## Mock transactions - -### L1->L2 - -:::note - -A running L1 node is **not** required for this operation. - -The L2 target entrypoint must be an `l1_handler`. - -::: - -Sends a mock transactions to L2, as if coming from L1, without the need for running L1. The target L2 contract's address must be provided to `l2_contract_address` and the `entry_point_selector` must refer to a public method of the target contract. The method must be annotated with `l1_handler`, otherwise an `ENTRYPOINT_NOT_FOUND` error may be returned. The `l1_transaction_hash` property is optional and, if provided, enables future `starknet_getMessagesStatus` requests with that hash value provided. - -In regular (non-mocking) L1-L2 interaction, `nonce` is determined by the L1 Starknet contract. In this mock case, it is up to the developer to set it. - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanSendMessageToL2", - "params": { - "l2_contract_address": "0x00285ddb7e5c777b310d806b9b2a0f7c7ba0a41f12b420219209d97a3b7f25b2", - "entry_point_selector": "0xC73F681176FC7B3F9693986FD7B14581E8D540519E27400E88B8713932BE01", - "l1_contract_address": "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512", - "payload": [ "0x1", "0x2" ], - "paid_fee_on_l1": "0x123456abcdef", - "nonce": "0x0", - "l1_transaction_hash": "0x000abc123", // optional - } -} -``` - -Result: - -```js -{ "transaction_hash": "0x0548c761a9fd5512782998b2da6f44c42bf78fb88c3794eea330a91c9abb10bb" } -``` - -### L2->L1 - -Sends a mock transaction from L2 to L1. The deployed L2 contract address `from_address` and `to_address` must be valid. - -It is a mock message, but only in the sense that you are mocking an L2 contract's action, which would normally be triggered by invoking the contract via a transaction. So keep in mind the following: - -:::note - -A running L1 node is required for this operation. - -::: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanConsumeMessageFromL2", - "params": { - "from_address": "0x00285ddb7e5c777b310d806b9b2a0f7c7ba0a41f12b420219209d97a3b7f25b2", - "to_address": "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512", - "payload": ["0x0", "0x1", "0x3e8"], - } -} -``` - -Result: - -```js -{"message_hash": "0xae14f241131b524ac8d043d9cb4934253ac5c5589afef19f0d761816a9c7e26d"} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.1/predeployed.md b/website/versioned_docs/version-0.8.0-rc.1/predeployed.md deleted file mode 100644 index 7b502999c..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/predeployed.md +++ /dev/null @@ -1,87 +0,0 @@ -# Predeployed contracts - -Devnet predeploys: - -- two [UDCs](https://docs.openzeppelin.com/contracts-cairo/udc) - - on the same addresses as Starknet mainnet/testnet - - a legacy instance serving only the `deployContract` entrypoint - - a UDC 2 instance serving both `deployContract` and `deploy_contract` entrypoints -- two [ERC20 (fee token)](https://docs.openzeppelin.com/contracts-cairo/erc20) contracts - - on the same addresses as Starknet mainnet/testnet - - one for STRK - - one for ETH -- a set of predeployed funded accounts - - not a feature of Starknet mainnet/testnet. - -The set of accounts can be controlled via [CLI options](./running/cli): `--accounts `, `--initial-balance `, `--seed `. - -## Predeployed account preservation - -:::note - -Once you shut down your Devnet, the predeployed account you used ceases to exist. This may be a problem with tools such as `starkli` which hardcode your account details in a local file. One option then is to delete your account entry from `starkli`'s account file. Another option is to spawn the same account on next Devnet startup. To do this, you can use: - -- the `--seed ` CLI option which always predeploys the same set of accounts if using the same `` (the seed is logged on startup) -- the [dump and load feature](./dump-load-restart) - -::: - -## Account class selection - -Choose between predeploying Cairo 0 (OpenZeppelin 0.5.1) or Cairo 1 (default; OpenZeppelin 1.0.0) accounts by using: - -``` ---account-class [cairo0 | cairo1] -``` - -Alternatively, provide a path to the [Sierra artifact](https://github.com/starkware-libs/cairo#compiling-and-running-cairo-files) of your custom account using: - -``` ---account-class-custom -``` - -## Predeclared account classes - -Both Cairo 0 and Cairo 1 versions of OpenZeppelin account are always predeclared, regardless of the chosen predeployment variant. If you specify `--predeclare-argent` on startup, the latest regular and multisig Argent account variants will also be predeclared. All predeclared classes can be used in DEPLOY_ACCOUNT transactions. - -## Deploying an undeclared account - -If you want to deploy an instance of an account contract class not predeclared on Devnet, you can use [forking](./forking). Just fork an origin network which has the needed class already declared, e.g. the Sepolia testnet. Why? Because new versions of wallets like ArgentX and Braavos tend to be declared on testnet/mainnet soon after release. - -## How to get predeployment info? - -### Logged on startup - -The startup log includes: - -- the hash values of predeclared classes -- the addresses of predeployed contracts -- the keys and initial balance of predeployed account contracts - -### API - -Account class info can be found in the response to [config request](api#config-api). - -Predeployed account details can be retrieved in JSON format by sending a `JSON-RPC` request. With the additional query parameter `with_balance` set to `true`, ETH and STRK balances at the pre-confirmed state will be provided, in WEI and FRI, respectively: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_getPredeployedAccounts" -} -``` - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_getPredeployedAccounts", - "params": { - // optional; defaults to false - "with_balance": true | false - } -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.1/proofs.md b/website/versioned_docs/version-0.8.0-rc.1/proofs.md deleted file mode 100644 index e6dfe6047..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/proofs.md +++ /dev/null @@ -1,143 +0,0 @@ -# Transaction proofs and proof modes - -This page describes the Devnet-specific transaction proof flow introduced in Starknet v0.14.2 and the `--proof-mode` configuration. - -## Important distinction: storage proofs vs transaction proofs - -- `starknet_getStorageProof` is still not supported in Devnet. -- `starknet_proveTransaction` is a separate Devnet extension for proving/validating `INVOKE v3` transaction payloads in a Devnet-oriented way. -- If you are looking for Merkle-Patricia storage proofs, this page is **not** about that feature. - -## Proof modes - -Proof behavior is controlled by `--proof-mode` (or env var `PROOF_MODE`). - -### Mode summary - -| Mode | CLI value | What `starknet_proveTransaction` does | How `starknet_addInvokeTransaction` treats `proof` and `proof_facts` | -| ------ | ------------------ | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | -| Full | `full` | Not implemented yet | Rejects with unsupported action | -| Devnet | `devnet` (default) | Returns a deterministic mock proof + proof facts | If both fields are present, verifies them; if one is missing or verification fails, rejects; if both are absent, accepts | -| None | `none` | Disabled / unsupported | Ignores incoming `proof` and `proof_facts` for invoke txs | - -### Why this exists - -`devnet` mode is a practical mode for local testing: - -- You can request a proof for a specific `INVOKE v3` payload. -- You can later attach that proof to a transaction and exercise proof-aware flows. -- Verification is deterministic and lightweight, intended for development workflows rather than real on-chain proving. - -## Configuration - -### CLI - -```bash -starknet-devnet --proof-mode devnet -``` - -```bash -starknet-devnet --proof-mode none -``` - -```bash -starknet-devnet --proof-mode full -``` - -### Environment variable - -```bash -PROOF_MODE=devnet starknet-devnet -``` - -### Docker - -```bash -docker run --rm -p 5050:5050 \ - -e PROOF_MODE=devnet \ - shardlabs/starknet-devnet-rs -``` - -## RPC: `starknet_proveTransaction` - -### Request shape - -`starknet_proveTransaction` accepts: - -- `block_id` -- `transaction` (a broadcasted `INVOKE v3` transaction payload) - -Example: - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "method": "starknet_proveTransaction", - "params": { - "block_id": "latest", - "transaction": { - "type": "INVOKE", - "version": "0x3", - "sender_address": "0x1234", - "calldata": ["0x1", "0x2"], - "signature": [], - "nonce": "0x0", - "resource_bounds": { - "l1_gas": { "max_amount": "0x0", "max_price_per_unit": "0x0" }, - "l1_data_gas": { "max_amount": "0x0", "max_price_per_unit": "0x0" }, - "l2_gas": { "max_amount": "0x0", "max_price_per_unit": "0x0" } - }, - "tip": "0x0", - "paymaster_data": [], - "account_deployment_data": [], - "nonce_data_availability_mode": "L1", - "fee_data_availability_mode": "L1" - } - } -} -``` - -### Response shape - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": { - "proof": "", - "proof_facts": [ - "0x...", - "0x...", - "0x...", - "0x...", - "0x...", - "0x...", - "0x...", - "0x..." - ] - } -} -``` - -`proof_facts` length is expected to be 8 in devnet mode. - -## Mode-specific behavior details - -### `devnet` mode (default) - -- `starknet_proveTransaction` is enabled. -- Invoke handling rules: - - both `proof` + `proof_facts` present and valid → accepted - - both present but invalid → rejected - - only one present → rejected - - both absent → accepted - -### `none` mode - -- Proof fields on invoke transactions are ignored. - -### `full` mode - -- Full proving/verification is not implemented yet. -- Endpoints and transactions requiring full verification return unsupported-action errors. diff --git a/website/versioned_docs/version-0.8.0-rc.1/restrictive.md b/website/versioned_docs/version-0.8.0-rc.1/restrictive.md deleted file mode 100644 index 595f2ffb7..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/restrictive.md +++ /dev/null @@ -1,36 +0,0 @@ -# Restrictive mode - -The `--restrictive-mode` argument enables a restrictive mode for Devnet, allowing you to specify methods that are forbidden during execution. This option ensures that certain operations are restricted, enhancing control over Devnet's behavior. When a user sends a request to one of the restricted methods, Devnet will return either a JSON-RPC error with code -32604 or, if the method was targeted directly via the HTTP endpoint, a response with status 403. - -## Default restricted methods - -When no methods are specified, the following default methods will be restricted, together with their HTTP endpoint counterparts (if any): - -- devnet_mint -- devnet_load -- devnet_restart -- devnet_createBlock -- devnet_abortBlocks -- devnet_impersonateAccount -- devnet_autoImpersonate -- devnet_getPredeployedAccounts - -## Usage - -### With default methods - -``` -$ starknet-devnet --restrictive-mode -``` - -### With a list of methods - -:::note - -Devnet will fail to start if any of the methods/routes are misspelled. - -::: - -``` -$ starknet-devnet --restrictive-mode devnet_dump devnet_config -``` diff --git a/website/versioned_docs/version-0.8.0-rc.1/running/_category_.json b/website/versioned_docs/version-0.8.0-rc.1/running/_category_.json deleted file mode 100644 index 17c529a24..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/running/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Running", - "position": 2, - "link": { - "type": "generated-index" - } -} diff --git a/website/versioned_docs/version-0.8.0-rc.1/running/cli.md b/website/versioned_docs/version-0.8.0-rc.1/running/cli.md deleted file mode 100644 index f34634578..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/running/cli.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -sidebar_position: 2.3 ---- - -# CLI options - -Configure your Devnet instance by specifying CLI parameters on startup. To read more about HTTP and logging configuration, check out the [server config](../server-config) page. - -## Help - -Check out all the options with: - -``` -$ starknet-devnet --help -``` - -Or if using dockerized Devnet: - -``` -$ docker run --rm shardlabs/starknet-devnet-rs --help -``` - -## Environment variables - -Every CLI option can also be specified via an environment variable: - -``` -$ = = starknet-devnet -``` - -To see the exact variable names, use [`--help`](#help). - -### Precedence - -If both a CLI argument and an environment variable are passed for a parameter, the CLI argument takes precedence. If none are provided, the default value is used. E.g. if running Devnet with the following command, seed value 42 will be used: - -``` -$ SEED=10 starknet-devnet --seed 42 -``` - -### Docker - -If using dockerized Devnet, specify the variables like this: - -``` -$ docker run \ - -e = \ - -e = \ - ... \ - shardlabs/starknet-devnet-rs -``` - -## Load configuration from a file - -If providing many configuration parameters in a single command becomes cumbersome, consider loading them from a file. By relying on [environment variables](#environment-variables), prepare your configuration in a file like this: - -```bash -export SEED=42 -export ACCOUNTS=3 -... -``` - -Assuming the file is called `.my-env-file`, then run: - -```bash -$ source .my-env-file && starknet-devnet -``` - -To run in a subshell and prevent environment pollution (i.e. to unset the variables after Devnet exits), use parentheses: - -```bash -$ ( source .my-env-file && starknet-devnet ) -``` - -### Docker - -To load environment variables from `.my-env-file` with Docker, remove the `export` part in each line to have the file look like this: - -``` -SEED=42 -ACCOUNTS=3 -... -``` - -Then run: - -``` -$ docker run --env-file .my-env-file shardlabs/starknet-devnet-rs -``` - -## Proof-related configuration - -Devnet exposes a dedicated proof-mode switch: - -```bash -starknet-devnet --proof-mode -``` - -Equivalent environment variable: - -```bash -PROOF_MODE= -``` - -Mode behavior summary: - -- `devnet` (default): mock proof generation + verification flow is enabled. -- `none`: proof fields are ignored on invoke transactions. -- `full`: reserved for fully verified proofs (currently not implemented). - -For complete examples and RPC payloads, see [Transaction proofs and proof modes](../proofs). diff --git a/website/versioned_docs/version-0.8.0-rc.1/running/docker.md b/website/versioned_docs/version-0.8.0-rc.1/running/docker.md deleted file mode 100644 index e4f011670..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/running/docker.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -sidebar_position: 2.2 ---- - -# Run with Docker - -Devnet is available as a Docker image ([Docker Hub link](https://hub.docker.com/r/shardlabs/starknet-devnet-rs/)). To download the `latest` image, run: - -```text -$ docker pull shardlabs/starknet-devnet-rs -``` - -Supported platforms: linux/amd64 and linux/arm64 (also executable on darwin/arm64). - -Running a container is done like this (see [port publishing](#container-port-publishing) for more info): - -```text -$ docker run -p [HOST:]:5050 shardlabs/starknet-devnet-rs [OPTIONS] -``` - -## Docker image tags - -All of the versions published on crates.io for starknet-devnet are available as docker images, which can be used via: - -``` -$ docker pull shardlabs/starknet-devnet-rs: -``` - -:::note - -The `latest` docker image tag corresponds to the last published version on crates.io. - -::: - -### Accessing Devnet fixes before release - -Commits to the `main` branch of this repository are mostly available as images tagged with their commit hash (the full 40-lowercase-hex-digits SHA1 digest): - -``` -$ docker pull shardlabs/starknet-devnet-rs: -``` - -If a fix has been merged into the `main` branch of Devnet's code repository, you can access it before its inclusion in an official release. Just inspect the [`main` commit list](https://github.com/0xSpaceShard/starknet-devnet/commits/main) and copy the full SHA digest of the commit containing the fix (or preferably the latest commit) which has a green check ✔️ symbol next to the commit date (which indicates the image indeed exists). Some revisions may not have a corresponding Docker image, but these are not supposed to be bugfixes. - -### Zero-seeded set of accounts - -By appending the `-seed0` suffix, you can use images which [predeploy funded accounts](../predeployed) with `--seed 0`, thus always predeploying the same set of accounts: - -``` -$ docker pull shardlabs/starknet-devnet-rs:-seed0 -$ docker pull shardlabs/starknet-devnet-rs:latest-seed0 -``` - -## Container port publishing - -### Linux - -If on a Linux host machine, you can use [`--network host`](https://docs.docker.com/network/host/). This way, the port used internally by the container is also available on your host machine. The `--port` option can be used (as well as other CLI options). - -```text -$ docker run --network host shardlabs/starknet-devnet-rs [--port ] -``` - -### Mac and Windows - -If not on Linux, you need to publish the container's internally used port to a desired `` on your host machine. The internal port is `5050` by default (probably not your concern, but can be overridden with `--port`). - -```text -$ docker run -p [HOST:]:5050 shardlabs/starknet-devnet-rs -``` - -E.g. if you want to use your host machine's `127.0.0.1:5050`, you need to run: - -```text -$ docker run -p 127.0.0.1:5050:5050 shardlabs/starknet-devnet-rs -``` - -You may ignore any address-related output logged on container startup (e.g. `Starknet Devnet listening on 0.0.0.0:5050`). What you will use is what you specified with the `-p` argument. - -If you don't specify the `HOST` part, the server will indeed be available on all of your host machine's addresses (localhost, local network IP, etc.), which may present a security issue if you don't want anyone from the local network to access your Devnet instance. - -## Development note - -Due to internal needs, images with arch suffix are built and pushed to Docker Hub, but this is not mentioned in the user docs as users should NOT be needing it. - -This is what happens under the hood on `main`: - -- build `shardlabs/starknet-devnet-rs--amd` -- build `shardlabs/starknet-devnet-rs--arm` -- create and push joint docker manifest called `shardlabs/starknet-devnet-rs-` - - same for `latest` diff --git a/website/versioned_docs/version-0.8.0-rc.1/running/install.md b/website/versioned_docs/version-0.8.0-rc.1/running/install.md deleted file mode 100644 index 3aa379e26..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/running/install.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -sidebar_position: 2.1 ---- - -# Install and run - -## Requirements - -Any of the approaches below that mention `cargo` require you to have [installed Rust](https://www.rust-lang.org/tools/install). You might also need to install `pkg-config` and `make`. - -The required Rust version is specified in `rust-toolchain.toml` in the project root and handled automatically by `cargo`. - -## Install an executable binary - -Installing an executable binary is achievable with `cargo install` via [crates.io](https://crates.io/) or [github.com](https://github.com). This approach downloads the crate, builds it in release mode and copies it to `~/.cargo/bin/`. To avoid needing to compile and wait, check the [pre-compiled binary section](#fetch-a-pre-compiled-binary-executable). - -### Remove Pythonic Devnet - -If in the past you installed [Pythonic Devnet](https://github.com/0xSpaceShard/starknet-devnet), be sure to remove it to avoid name collision of the old and the new executable - if by no other means, then by `rm $(which starknet-devnet)`. - -### Install from crates.io - -``` -$ cargo install starknet-devnet -``` - -### Install from GitHub - -- Use the `--locked` flag to ensure using the dependencies listed in `Cargo.lock` in the project root. -- Preferably familiarize yourself with the `cargo install` command ([docs](https://doc.rust-lang.org/cargo/commands/cargo-install.html#dealing-with-the-lockfile)). - -``` -$ cargo install --git https://github.com/0xSpaceShard/starknet-devnet.git --locked -``` - -### Install with `asdf` - -- Run the following to add the `starknet-devnet` plugin - -``` -$ asdf plugin add starknet-devnet -``` - -- Show all installable versions: - -``` -$ asdf list-all starknet-devnet -``` - -- Install latest version: - -``` -$ asdf install starknet-devnet latest -``` - -- Install specific version: - -``` -$ asdf install starknet-devnet 0.2.0 -``` - -Check [asdf guide](https://asdf-vm.com/guide/getting-started.html) for more instructions on how to install & manage versions. - -### Install with starkup - -[Starkup](https://github.com/software-mansion/starkup) is a tool for installing and managing Starknet-related tools, including starknet-devnet. To run starkup itself: - -``` -$ curl --proto '=https' --tlsv1.2 -sSf https://sh.starkup.sh | sh -``` - -Starkup uses `asdf` underneath to manage tool versions. After installation, you can use standard ASDF commands to manage starknet-devnet. - -Make sure to restart your terminal or source your shell configuration file after installation to have starknet-devnet available in your PATH. - -### Run the installed executable - -When `cargo install` or another installation method finishes, follow the output in your terminal. If properly configured, you should be able to run Devnet with: - -``` -$ starknet-devnet -``` - -## Fetch a pre-compiled binary executable - -If you want to save time and skip project compilation on installation, since Devnet v0.0.5, the Assets section of each [GitHub release](https://github.com/0xSpaceShard/starknet-devnet/releases) contains a set of platform-specific pre-compiled binary executables. Extract and run with: - -``` -$ curl -sSfL https://github.com/0xSpaceShard/starknet-devnet/releases/download// | tar -xvz -C -$ /starknet-devnet -``` - -## Run from source - -To install the project from source, after [git-cloning](https://github.com/git-guides/git-clone) the [Devnet repository](https://github.com/0xSpaceShard/starknet-devnet), running the following command will install, build and start Devnet: - -``` -$ cargo run -``` - -Specify optional CLI params like this: - -``` -$ cargo run -- [ARGS] -``` - -For a more optimized performance (though with a longer compilation time), run: - -``` -$ cargo run --release -``` diff --git a/website/versioned_docs/version-0.8.0-rc.1/server-config.md b/website/versioned_docs/version-0.8.0-rc.1/server-config.md deleted file mode 100644 index e9e5b5c33..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/server-config.md +++ /dev/null @@ -1,77 +0,0 @@ -# Server config - -To read generally about ways to configure your Devnet instance, check out the [CLI section](./running/cli.md). - -## Host and port - -Specify the host and the port used by the server with `--host
` and `--port ` CLI arguments. If running with Docker, check out the [port publishing docs](./running/docker#container-port-publishing). - -## Logging - -By default, the logging level is `INFO`, but this can be changed via the `RUST_LOG` environment variable. - -All logging levels: `TRACE`, `DEBUG`, `INFO`, `WARN`, `ERROR` - -To specify the logging level and run Devnet on the same line: - -``` -$ RUST_LOG= starknet-devnet -``` - -or if using dockerized Devnet: - -``` -$ docker run -e RUST_LOG= shardlabs/starknet-devnet-rs -``` - -By default, logging of request and response data is turned off. -To see the request and/or response body, additional levels can be specified via the `RUST_LOG` environment variable: `REQUEST` for request body, `RESPONSE` for response body. - -:::note - -Logging request and response requires at least logging level `INFO`. - -For example, the following two commands will log request and response data with log level `INFO`. - -``` -$ RUST_LOG="REQUEST,RESPONSE" starknet-devnet -``` - -``` -$ RUST_LOG="REQUEST,RESPONSE,INFO" starknet-devnet -``` - -::: - -## Timeout - -Specify the maximum amount of time an HTTP request can be served. This makes it possible to deploy and manage large contracts that take longer to execute. - -``` -$ starknet-devnet --timeout -``` - -## Size limits - -There is no HTTP request size limit, but take care when declaring large classes! Devnet is supposed to follow the limits specified in [Starknet chain Info](https://docs.starknet.io/resources/chain-info/#current_limits). - -If, however, you need to customize the limits, you may rely on the following CLI parameters on Devnet startup: - -- `--maximum-contract-class-size ` -- `--maximum-contract-bytecode-size ` -- `--maximum-sierra-length ` - -The default upper limits configured in Devnet can be found [among constants](https://github.com/0xSpaceShard/starknet-devnet/blob/main/crates/starknet-devnet-core/src/constants.rs#L121). - -## API - -Retrieve the server config by sending a `JSON-RPC` request with method name `devnet_getConfig` and extracting its `server_config` property. - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_getConfig" -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.1/starknet-time.md b/website/versioned_docs/version-0.8.0-rc.1/starknet-time.md deleted file mode 100644 index 341e6d70a..000000000 --- a/website/versioned_docs/version-0.8.0-rc.1/starknet-time.md +++ /dev/null @@ -1,70 +0,0 @@ -# Starknet time - -Block and state timestamp can be manipulated by setting the exact time or setting the time offset. By default, timestamp methods `devnet_setTime` and `devnet_increaseTime` of JSON-RPC API generate a new block. This can be changed for `devnet_setTime` by setting the optional parameter `generate_block` to `false`. This skips immediate new block generation, but will use the specified timestamp whenever the next block is supposed to be generated. - -All values should be set in [Unix time seconds](https://en.wikipedia.org/wiki/Unix_time). After [startup](#start-time), the time progresses naturally. - -## Set time - -The following sets the exact time and generates a new block: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_setTime", - "params": { - "time": TIME_IN_SECONDS - } -} -``` - -The following doesn't generate a new block, but sets the exact time for the next generated block: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_setTime", - "params": { - "time": TIME_IN_SECONDS, - "generate_block": false - } -} -``` - -Warning: block time can be set in the past which might lead to unexpected behavior! - -## Increase time - -Increases the block timestamp by the provided amount and generates a new block. All subsequent blocks will keep this increment. - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_increaseTime", - "params": { - "time": TIME_IN_SECONDS - } -} -``` - -:::note Increment example - -Imagine a block is generated with timestamp `T1`, some time passes (let's call this interval `T_passed`), and you call increase_time with `T_inc` as the argument, which immediately mines a new block at `T2`. `T2` should equal `T1 + T_passed + T_inc`. - -::: - -## Start time - -Devnet's starting timestamp can be defined via CLI by providing a positive value of [Unix time seconds](https://en.wikipedia.org/wiki/Unix_time) to `--start-time`: - -``` -$ starknet-devnet --start-time -``` - -If provided, this timestamp shall be used in mining the genesis block. The default value is the current Unix time. diff --git a/website/versioned_docs/version-0.8.0-rc.2/account-impersonation.md b/website/versioned_docs/version-0.8.0-rc.2/account-impersonation.md deleted file mode 100644 index 951860c27..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/account-impersonation.md +++ /dev/null @@ -1,92 +0,0 @@ -# Account impersonation - -:::info - -This page is about account impersonation. To read about account class selection and deployment, click [here](./predeployed). - -::: - -## Introduction - -Devnet allows you to impersonate an account that exists on the Starknet mainnet or testnet. This is achieved by skipping the validation step of transactions for all or some accounts, on a running Devnet via JSON-RPC. - -A transaction sent from an impersonated account will not fail with an invalid signature error, which is what happens in the general case of locally absent accounts. For impersonation to work, Devnet needs to [fork](./forking.md) the network that has the desired account. - -:::warning Caveat - -- Only `INVOKE` and `DECLARE` transactions are supported. `DEPLOY_ACCOUNT` transaction is not supported, but you can create an `INVOKE` transaction to UDC. -- Due to the validation step being skipped, the overall fee of transactions sent with an impersonated account will be lower than regular transactions. -- Trying to send a transaction with an account that **does not** even exist in the origin network returns an error: - - `ContractNotFound` if, during transaction preparation, you do not specify a nonce value, leading to the implicit querying of Devnet for the nonce. - - `InsufficientAccountBalance` or similar if the nonce is supplied in the transaction; this happens because the token balance of a non-existent contract is 0 indeed insufficient. - -::: - -## Tips - -- The impersonated account may have had all or a part of its funds used up on the origin network. You may need to give it more funds via [minting](./balance.md). -- If you're defining a new account in your Starknet client application (starknet.js, starknet.rs, starkli...), you may need to specify a private key for it. Since the signature validation is skipped, you may provide a dummy key. - -## API - -Account impersonation follows JSON-RPC method specification. Each method returns an empty response: - -### devnet_impersonateAccount - -Impersonates a specific account address nonexistent in the local state. - -```js -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_impersonateAccount", - "params": { - "account_address": "0x49D36570D4E46F48E99674BD3FCC84644DDD6B96F7C741B1562B82F9E004DC7" - } -} -``` - -### devnet_stopImpersonateAccount - -Stops the impersonation of an account previously marked for impersonation. - -```js -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_stopImpersonateAccount", - "params": { - "account_address": "0x49D36570D4E46F48E99674BD3FCC84644DDD6B96F7C741B1562B82F9E004DC7" - } -} -``` - -### devnet_autoImpersonate - -Enables automatic account impersonation. Every account that does not exist in the local state will be impersonated. - -```js -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_autoImpersonate", - "params": {} -} -``` - -### devnet_stopAutoImpersonate - -Stops the effect of [automatic impersonation](#devnet_autoimpersonate). - -```js -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_stopAutoImpersonate", - "params": {} -} -``` - -## Preventing impersonation - -If you want to learn about completely preventing impersonation from being activated on your Devnet, click [here](./restrictive.md). diff --git a/website/versioned_docs/version-0.8.0-rc.2/api.md b/website/versioned_docs/version-0.8.0-rc.2/api.md deleted file mode 100644 index 7ee0c5e6a..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/api.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -sidebar_position: 3 ---- - -# API - -## JSON-RPC API - -Both Starknet's and Devnet's JSON-RPC API are reachable at `/rpc` and `/`. E.g. if spawning Devnet with default settings, these URLs are functionally equivalent: `http://127.0.0.1:5050/rpc` and `http://127.0.0.1:5050/`. The difference between these two groups of methods is their prefix: `starknet_` (e.g. `starknet_getNonce`) and `devnet_` (e.g. `devnet_mint`). - -### Starknet API - -Unlike Pythonic Devnet, which also supported Starknet's gateway and feeder gateway API, Devnet in Rust supports [Starknet's JSON-RPC API](https://github.com/starkware-libs/starknet-specs/tree/master/api), including [WebSocket support](#websocket). - -Due to how Devnet internally works, the method `starknet_getStorageProof` is not applicable, and thus not supported. - -Devnet also provides a proof-related extension method `starknet_proveTransaction`. For supported modes, behavior, and usage examples, check [Transaction proofs and proof modes](./proofs). - -Since JSON-RPC v0.6.0, to find out which JSON-RPC version is supported by which Devnet version, check out the [releases page](https://github.com/0xspaceshard/starknet-devnet/releases). - -### Devnet API - -Devnet has many additional features available via JSON-RPC. The RPC methods are documented throughout the documentation in their corresponding pages, but are also aggregated [here](https://github.com/0xSpaceShard/starknet-devnet/blob/main/website/static/devnet_api.json). - -#### Healthcheck - -To check if a Devnet instance is alive, send an HTTP request `GET /is_alive`. If alive, Devnet will reply with a `200 OK` and an appropriate message. This is the only special functionality not provided as part of the JSON-RPC API. - -### WebSocket - -The whole [Starknet](#starknet-api) and [Devnet](#devnet-api) JSON-RPC API, including [WebSocket subscription methods](https://github.com/starkware-libs/starknet-specs/blob/v0.9.0/api/starknet_ws_api.json) can be accessed via the WebSocket protocol, using text or binary messages. Devnet listens for new WebSocket connections at `ws://:/ws` (notice the protocol scheme). E.g. using [`wscat`](https://www.npmjs.com/package/wscat) on the same computer where Devnet is spawned at default host and port: - -``` -$ wscat -c ws://127.0.0.1:5050/ws -Connected (press CTRL+C to quit) -> { "jsonrpc": "2.0", "id": 0, "method": "starknet_subscribeNewHeads" } -< {"id":0,"result":2935616350010920547,"jsonrpc":"2.0"} -``` - -#### WebSocket persistence - -[Restarting](./dump-load-restart#restarting) and [loading](./dump-load-restart#loading) do not affect Devnet's WebSocket connections, but remove all subscriptions. - -## Interacting with Devnet in JavaScript and TypeScript - -To spawn Devnet and interact with it using the [Devnet API](#devnet-api), you can use [`starknet-devnet-js`](https://github.com/0xSpaceShard/starknet-devnet-js/). This can be especially useful in achieving [L1-L2 communication](./postman.md). - -To interact with Devnet using the [Starknet API](#starknet-api), use [starknet.js](https://www.starknetjs.com/). - -## Config API - -To retrieve the current configuration of Devnet, as specified via [CLI](running/cli.md) and later requests, send a `JSON-RPC` request with method name `devnet_getConfig`. Example response is attached below. It can be interpreted as a JSON mapping of CLI input parameters, both specified and default ones, with some irrelevant parameters omitted. So use `starknet-devnet --help` to better understand the meaning of each value, though keep in mind that some of the parameters have slightly modified names. The exact values may have changed and should not be referenced. - -```json -{ - "seed": 4063802897, - "total_accounts": 10, - "account_contract_class_hash": "0x61dac032f228abef9c6626f995015233097ae253a7f72d68552db02f2971b8f", - "predeployed_accounts_initial_balance": "1000000000000000000000", - "start_time": null, - "gas_price_wei": 100000000000, - "gas_price_fri": 100000000000, - "data_gas_price_wei": 100000000000, - "data_gas_price_fri": 100000000000, - "l2_gas_price_wei": 100000000000, - "l2_gas_price_fri": 100000000000, - "chain_id": "SN_SEPOLIA", - "dump_on": "exit", - "dump_path": "dump_path.json", - "state_archive": "none", - "fork_config": { - "url": "http://rpc.pathfinder.equilibrium.co/integration-sepolia/rpc/v0_7", - "block_number": 26429 - }, - "server_config": { - "host": "127.0.0.1", - "port": 5050, - "timeout": 120, - "restricted_methods": null - }, - "block_generation": null, - "lite_mode": false, - "eth_erc20_class_hash": "0x046ded64ae2dead6448e247234bab192a9c483644395b66f2155f2614e5804b0", - "strk_erc20_class_hash": "0x046ded64ae2dead6448e247234bab192a9c483644395b66f2155f2614e5804b0" -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.2/balance.md b/website/versioned_docs/version-0.8.0-rc.2/balance.md deleted file mode 100644 index db9cf475f..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/balance.md +++ /dev/null @@ -1,65 +0,0 @@ -# Account balance - -Other than using prefunded predeployed accounts, you can also add funds to an account that you deployed yourself. - -Separate tokens use separate ERC20 contracts for minting and charging fees. These are the token contracts predeployed by Devnet and the addresses where they are located: - -- ETH: `0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7` -- STRK: `0x04718f5a0fc34cc1af16a1cdee98ffb20c31f5cd61d6ab07201858f4287c938d` - -## Mint token - Local faucet - -By sending a `JSON-RPC` request with method name `devnet_mint` for a token, you initiate a transaction on that token's ERC20 contract. The response contains the hash of this transaction, as well as the new balance after minting. The token is specified by providing the unit, and defaults to `FRI` (the unit of `STRK`). - -The value of `amount` is in WEI or FRI. The precision is preserved if specifying an integer or a float whose fractional part is zero (e.g. `1000.0`, `1e21`). If the fractional part is non-zero, the amount is truncated to the nearest integer (e.g. `3.9` becomes `3` and `1.23e1` becomes `12`). - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_mint", - "params": { - "address": "0x6e3205f...", - "amount": 500000, - "unit": "WEI" | "FRI" - } -} -``` - -Result: - -``` -{ - "new_balance": 500000, - "unit": "WEI" | "FRI", - "tx_hash": "0xa24f23..." -} -``` - -In case of a reverted minting request, an error is returned containing the stringified revert reason and the hex string of the hash of the reverted transaction for further inspection: - -``` -{ - "tx_hash": "0x123..." - "revert_reason": "Something happened" -} -``` - -## Check balance - -Check the balance of an address by sending a `JSON-RPC` request. The address should be a 0x-prefixed hex string; `unit` defaults to `FRI` (the unit of `STRK`) and `block_id` to `latest`. - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_getAccountBalance", - "params": { - "address": "0x6e3205f...", - "unit": "WEI" | "FRI", - "block_id": - } -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.2/blocks.md b/website/versioned_docs/version-0.8.0-rc.2/blocks.md deleted file mode 100644 index 91e7db154..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/blocks.md +++ /dev/null @@ -1,182 +0,0 @@ -# Blocks - -## State commitment - -Block states are not committed in a Merke-Patricia trie or a similar tree-like structure. Block roots are therefore set to 0. - -## Genesis block - -By default, Devnet starts with a genesis block labelled with number zero. In [forking mode](./forking), the genesis block number is equal to the forked block number plus one. - -## Limits - -To read more about block limits, see [this](./intro#limits). - -## Creating blocks on transaction - -If you start Devnet with `--block-generation-on transaction`, a new block is generated with each new transaction. This is the default block generation regime. This mode also supports [empty block creation](#request-new-block-creation). - -## Creating blocks on demand - -If you start Devnet with the `--block-generation-on demand` CLI option, you will enable the possibility to store more than one transaction in the pre-confirmed block (targetable via block tag `"pre_confirmed"`). - -Once you've added the desired transactions into the pre-confirmed block, you can [request new block creation](#request-new-block-creation). This will convert the pre-confirmed block to the latest block (targetable via block tag `"latest"`), giving it a block hash and a block number. All subsequent transactions will be stored in a new pre-confirmed block. - -In case of demanding block creation with no pre-confirmed transactions, a new empty block will be generated. - -The creation of the genesis block is not affected by this feature. - -The specifications of a block-creating request can be found [below](#request-new-block-creation). - -## Automatic periodic block creation - -If started with the `--block-generation-on ` CLI option, Devnet will behave as in [`demand` mode](#creating-blocks-on-demand), but new blocks will be mined automatically every `` seconds. Consider this example of spawning Devnet at moment `t`: - -```bash -# t -$ starknet-devnet --block-generation-on 10 - -# t + 1s -# user: send tx1 - -# t + 4s -# user: send tx2 - -# t + 10s -# Devnet: block automatically generated, contains tx1 and tx2 - -# t + 12s -# user: send tx3 - -# t + 14s -# user: invoke empty block creation -# Devnet: generated block contains tx3 - -# t + 20s -# Devnet: block automatically generated, contains no txs (manual creation did not restart the counter) -``` - -## Request new block creation - -To request the creation of a new block, send: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_createBlock" -} -``` - -Result: - -``` -{"block_hash": "0x115e1b390cafa7942b6ab141ab85040defe7dee9bef3bc31d8b5b3d01cc9c67"} -``` - -The newly created block will contain all pre-confirmed transactions, if any, since the last block creation. - -## Timestamp manipulation - -To affect the timestamp of the newly created block, check out [this page](./starknet-time#set-time) - -## Block abortion - -This functionality allows simulating block abortion that can occur on mainnet as a consequence of e.g. block reorganization. Aborted blocks and their transactions are removed from Devnet's memory. - -:::note - -Block abortion is only supported if Devnet is started in the `--state-archive-capacity full` mode. - -::: - -You can abort blocks and revert transactions from the specified block to the currently latest block. Newly created blocks after the abortion will have accepted status and will continue with numbering where the last accepted block left off. - -The state of Devnet will be reverted to the state of the last accepted block. - -### Example - -Assume there are 3 accepted blocks numbered 1, 2 and 3. Upon receiving a request to abort blocks starting with block 2, the blocks numbered 2 and 3 are aborted and their transactions reverted. The state of network will be as it was in block 1. Once a new block is mined, it will be accepted and it will have number 2. - -### Limitations - -Aborted blocks can only be queried by block hash. Devnet does not support the abortion of: - -- blocks in the forking origin (i.e. blocks mined before the forked block) -- already aborted blocks -- Devnet's genesis block. - -### Websocket subscription notifications - -On block abortion, a `starknet_subscriptionReorg` notification will be sent to all websocket subscribers requiring so according to [JSON-RPC websocket API specification](https://github.com/starkware-libs/starknet-specs/blob/v0.8.0/api/starknet_ws_api.json#L236). The `starting_block` of the orphaned chain is the successor of the new latest block and the `ending_block` of the orphaned chain is the block that was latest before aborting. One reorg notification is sent per subscription, not per websocket, meaning that if a websocket has n subscriptions, it will receive n reorg notifications, each with its own subscription ID. - -If a socket has subscribed to transaction status changes of a transaction `tx1` using `starknet_subscribeTransactionStatus` and the block holding `tx1` gets aborted, a `starknet_subscriptionTransactionStatus` notification shall NOT be sent. The socket shall have to rely on handling `starknet_subscriptionReorg`. - -### Request and response - -To abort, send: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_abortBlocks", - "params": { - "starting_block_id": BLOCK_ID - } -} -``` - -Result: - -``` -{ - "aborted": [BLOCK_HASH_0, BLOCK_HASH_1, ...] -} -``` - -:::note - -When aborting the currently `pre_confirmed` block, it is mined and aborted as latest. - -::: - -## Accepting blocks on L1 - -This functionality allows simulating block acceptance on L1 (Ethereum). It merely marks the requested blocks and their transactions as `ACCEPTED_ON_L1`. It is only supported on blocks that are `ACCEPTED_ON_L2` and fails for all others, including blocks already `ACCEPTED_ON_L1`. In case of [forking](./forking), blocks on forking origin cannot be affected by this feature. - -:::note - -This functionality does not actually perform actions on L1. - -::: - -### Example - -Assume Devnet has mined blocks with numbers: 0 (origin), 1, 2 and 3. If this feature is invoked with `starting_block_id={"block_number": 2}`, blocks 0, 1 and 2 shall be `ACCEPTED_ON_L1` and block 3 shall remain `ACCEPTED_ON_L2`. If after that another block (number 4) is mined, and this feature is invoked with `starting_block_id="latest"`, blocks 0, 1, 2, 3 and 4 shall be `ACCEPTED_ON_L1`. If a new block is mined after that (number 5), it shall be `ACCEPTED_ON_L2`. - -### Request and response - -To accept a block and its transactions on L1, send: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_acceptOnL1", - "params": { - "starting_block_id": BLOCK_ID - } -} -``` - -Result: - -``` -{ - "accepted": [BLOCK_HASH_0, BLOCK_HASH_1, ...] -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.2/dump-load-restart.md b/website/versioned_docs/version-0.8.0-rc.2/dump-load-restart.md deleted file mode 100644 index 7735dc212..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/dump-load-restart.md +++ /dev/null @@ -1,144 +0,0 @@ -# Dump, load, restart - -## Dumping - -To preserve your Devnet instance for future use, these are the options: - -- Dumping on exit (handles Ctrl+C, i.e. SIGINT; doesn't handle SIGKILL): - -``` -$ starknet-devnet --dump-on exit --dump-path -``` - -- Dumping after each block: - -``` -$ starknet-devnet --dump-on block --dump-path -``` - -- Dumping on request, which requires providing `--dump-on request` on startup. You can also dump on request if you specified any of the other `--dump-on` modes. - -### Dumping on request - -You can request dumping via JSON-RPC. An optional file path can be provided in the request or on startup via `--dump-path ` (the HTTP request parameter takes precedence). If no dumping path is specified, the dump is included in the response body. This means that if you request dumping via [`curl`](https://curl.se/), it will be printed to STDOUT, which you can then redirect to a destination of your choice. - -``` -$ starknet-devnet --dump-on [--dump-path ] -``` - -- No body parameters: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_dump" -} -``` - -- With a custom path: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_dump", - "params": { - // optional; defaults to the path specified via CLI if defined - "path": - } -} -``` - -## Loading - -To load a preserved Devnet instance, the options are: - -- Loading on startup (note the argument name is not `--load-path` as it was in Devnet-py): - -``` -$ starknet-devnet --dump-path -``` - -- Loading on request, which replaces the current state with the one in the provided file. It can be done via JSON-RPC: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_load", - "params": { - "path": - } -} -``` - -### Loading disclaimer - -Currently, dumping produces a list of reproducible Devnet actions (state-changing requests and transactions). Conversely, loading is implemented as the re-execution of transactions from a dump. This means that timestamps of `StarknetBlock` will be different on each load. This is due to the nature of Devnet's dependencies, which prevent Devnet's state from being serialized. - -Dumping and loading are not guaranteed to work across versions. I.e. if you dumped one version of Devnet, do not expect it to be loadable with a different version. - -If you dumped a Devnet utilizing one class for account predeployment (e.g. `--account-class cairo0`), you should use the same option when loading. The same applies for dumping a Devnet in `--block-generation-on demand` mode. - -Loading does not affect WebSocket connections, but removes all WebSocket [subscriptions](./api#websocket). - -## Restarting - -Devnet can be restarted by making a `JSON-RPC` request with method name `devnet_restart`. All deployed contracts (including predeployed), blocks and storage updates will be restarted to the original state, without the transactions and requests that may have been loaded from a dump file on startup. - -Restarting does not affect WebSocket connections, but removes all WebSocket [subscriptions](./api#websocket). - -### Restarting and L1-L2 messaging - -If you're doing [L1-L2 message exchange](./postman), restarting will by default not affect Devnet's connection with L1 nor the L1->L2 message queue. The effect that L1-L2 messages may have had on Devnet before restarting shall be reverted, including any L2 contracts used for messaging. Also, calling [`flush`](./postman#flush) will not have new messages to read until they are actually sent. If you wish to re-process the already-seen L1->L2 messages when you restart, make them accessible again by setting the `restart_l1_to_l2_messaging` parameter shown below. If you set this flag: - -- you will need to [reload the L1-side messaging contract](./postman#load) -- the L1->L2 messages won't be restarted in the sense of being deleted, but access to them shall be regained via [`flush`](./postman#flush) -- the L2->L1 message queue is restarted regardless of the flag - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_restart", - "params": { - // optional parameter, defaults to false - "restart_l1_to_l2_messaging": true | false - } -} -``` - -## Docker - -To enable dumping and loading with dockerized Devnet, you must bind the container path to the path on your host machine. - -This example: - -- Relies on [Docker bind mount](https://docs.docker.com/storage/bind-mounts/); try [Docker volume](https://docs.docker.com/storage/volumes/) instead. -- Assumes that `/path/to/dumpdir` exists. If unsure, use absolute paths. -- Assumes you are listening on `127.0.0.1:5050`. - -If there is `mydump` inside `/path/to/dumpdir`, you can load it with: - -``` -docker run \ - -p 127.0.0.1:5050:5050 \ - --mount type=bind,source=/path/to/dumpdir,target=/path/to/dumpdir \ - shardlabs/starknet-devnet-rs \ - --dump-path /path/to/dumpdir/mydump -``` - -To dump to `/path/to/dumpdir/mydump` on Devnet shutdown, run: - -``` -docker run \ - -p 127.0.0.1:5050:5050 \ - --mount type=bind,source=/path/to/dumpdir,target=/path/to/dumpdir \ - shardlabs/starknet-devnet-rs \ - --dump-on exit --dump-path /path/to/dumpdir/mydump -``` diff --git a/website/versioned_docs/version-0.8.0-rc.2/examples.md b/website/versioned_docs/version-0.8.0-rc.2/examples.md deleted file mode 100644 index 5704af4da..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/examples.md +++ /dev/null @@ -1,3 +0,0 @@ -# Examples - -Usage examples relying on the [`starknet-devnet-js`](https://github.com/0xspaceShard/starknet-devnet-js) library can be found [here](https://github.com/0xSpaceShard/starknet-devnet-js/tree/master/test). diff --git a/website/versioned_docs/version-0.8.0-rc.2/forking.md b/website/versioned_docs/version-0.8.0-rc.2/forking.md deleted file mode 100644 index 8fa081264..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/forking.md +++ /dev/null @@ -1,47 +0,0 @@ -# Forking - -To interact with contracts deployed on mainnet or testnet, you can use forking. Simulate the origin and experiment with it locally, making no changes to the origin itself. - -``` -$ starknet-devnet --fork-network [--fork-block ] -``` - -The value passed to `--fork-network` should be the URL to a Starknet JSON-RPC API provider. Specifying a `--fork-block` is optional; it defaults to the `"latest"` block at the time of Devnet's start-up. All calls will first try Devnet's state and then fall back to the forking block. - -:::note How it works - -When you send a request to a forked Devnet instance, it first queries Devnet's local state, then tries the forking origin. Forking is not a step simply performed on Devnet startup, but happens continuously while the Devnet instance is alive. - -::: - -## Upstream caching - -By default, Devnet does not cache responses from the fork upstream network. However, you can enable caching to improve performance and reduce the number of requests sent to the origin by using the `--fork-upstream-caching` flag: - -``` -$ starknet-devnet --fork-network --fork-upstream-caching -``` - -:::tip Performance improvement - -Enabling upstream caching can significantly improve performance by reducing redundant requests to the fork origin. - -::: - -## Forking and ACCEPTED_ON_L1 - -Assume you have run Devnet as a fork from an origin at a block that is not yet `ACCEPTED_ON_L1`, but only `ACCEPTED_ON_L2`. If in your state queries you specify `block_id: "l1_accepted"`, and there are no local blocks marked as `ACCEPTED_ON_L1`, Devnet will assume the forking block has become `ACCEPTED_ON_L1`. - -Read more about marking blocks as `ACCEPTED_ON_L1` on Devnet: [link](./blocks#accepting-blocks-on-l1). - -## Account impersonation - -[Here](./account-impersonation) you can read more about acting as an account deployed on the origin. - -## Deploying an undeclared account - -[Here](./predeployed#deploying-an-undeclared-account) you can read about deploying an account not declared on Devnet. - -## Checking forking status - -To see if your Devnet instance is using forking or not, [fetch the current configuration](./api#config-api), and check the `url` property of its `fork_config` property. If Devnet is forked, this property contains the string of the origin URL specified on startup. diff --git a/website/versioned_docs/version-0.8.0-rc.2/gas.md b/website/versioned_docs/version-0.8.0-rc.2/gas.md deleted file mode 100644 index fcff305bb..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/gas.md +++ /dev/null @@ -1,55 +0,0 @@ -# Gas price modification - -## On Devnet startup - via CLI - -All gas prices (L1 gas, L1 data gas, L2 gas) can be specified on startup, via their respective CLI params. Check `starknet-devnet --help | grep price` for more info. - -## On a running Devnet - via JSON-RPC - -The `devnet_setGasPrice` RPC method allows users to modify the current gas prices on a running Devnet. This feature is particularly useful for testing purposes and for adjustments needed after forking to align with the forked network's gas prices. All parameters are optional, allowing you to choose which ones you want to set. A boolean flag `generate_block` indicates whether a new block should be generated immediately after setting the gas prices. - -### Explanation - -The modified gas prices take effect starting with the next block that is generated. - -### generate_block - -- When set to `true`, a new block will be generated immediately after the gas prices are set. This ensures that the changes take effect right away and are reflected in the devnet state without waiting for the next block generation. -- When set to `false` (or omitted), the gas prices will be set, but the changes will not be immediately committed to the devnet state until the next block is generated through the usual block generation process. - -### JSON-RPC Request - -The following JSON-RPC request can be used to set gas prices (all properties optional): - -```json -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_setGasPrice", - "params": { - "gas_price_wei": 1000000, - "data_gas_price_wei": 10000, - "gas_price_fri": 10000, - "data_gas_price_fri": 10000, - "l2_gas_price_wei": 1000000, - "l2_gas_price_fri": 10000, - "generate_block": false, - } -} -``` - -## Response - -The expected response from the server will mirror the request gas parameters, confirming the modification of gas prices: - -```json -{ - "gas_price_wei": 1000000, - "data_gas_price_wei": 10000, - "gas_price_fri": 10000, - "data_gas_price_fri": 10000, - "l2_gas_price_wei": 10000, - "l2_gas_price_fri": 10000 -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.2/historic-state.md b/website/versioned_docs/version-0.8.0-rc.2/historic-state.md deleted file mode 100644 index f2358c680..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/historic-state.md +++ /dev/null @@ -1,9 +0,0 @@ -# Historic state support - -With state archive capacity set to `full`, Devnet will store full state history, enabling its querying by block hash or number. The default mode is `none`, where no old states are stored and only the latest is available for querying. - -``` -$ starknet-devnet --state-archive-capacity -``` - -All RPC endpoints that support querying the state at an old (non-latest) block only work with state archive capacity set to `full`. diff --git a/website/versioned_docs/version-0.8.0-rc.2/intro.md b/website/versioned_docs/version-0.8.0-rc.2/intro.md deleted file mode 100644 index 7d498fb75..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/intro.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Intro - -:::danger Difference disclaimer - -- Devnet should not be used as a replacement for the official testnet. After testing on Devnet, be sure to test on testnet (alpha-sepolia)! -- Devnet does not organize state data into Merkle-Patricia tries or similar tree-like structures, so: - - Calling the `starknet_getStorageProof` RPC method shall always result in `STORAGE_PROOF_NOT_SUPPORTED`. - - Block roots are set to 0. -- The pre-confirmed block is equivalent to the old pending block, except that its transactions are not `ACCEPTED_ON_L2` but `PRE_CONFIRMED`. -- By default, a new block is mined for each new transaction. - - This can be modified by directing all new transactions into a pre-confirmed block, and at some point triggering block creation. - - Transactions in a pre-confirmed block cannot be replaced by sending a transaction with a higher free from the same account. - - Read more about transitioning a transaction [from `PRE_CONFIRMED` to `ACCEPTED_ON_L2`](./blocks#creating-blocks-on-demand). -- Block hashes on devnet differ from mainnet because some mainnet block fields are unavailable to devnet, resulting in different hash outputs despite using the same hashing algorithm. -- Transactions are never automatically `ACCEPTED_ON_L1`, unless the user performs an action. - - Read more about transitioning a transaction [from `ACCEPTED_ON_L2` to `ACCEPTED_ON_L1`](./blocks#accepting-blocks-on-l1). -- `RECEIVED` and `CANDIDATE` statuses are not used in Devnet. -- In Starknet 0.14.1, field `migrated_compiled_classes` was introduced to the `state_diff`. In devnet, this field will always be empty: - - When starting devnet without forking there is nothing to migrate - - In forking mode, there is no RPC support to fetch compiled class hashes from origin, so it is impossible for devnet to determine which classes have to be migrated - -::: - -You may now proceed with [running Devnet](./running/install) and checking out the multitude of features listed in the sidebar on the left. - -# Limits - -As mentioned [here](https://docs.starknet.io/tools/limits-and-triggers/), "Starknet currently has a number of limits in place in order to keep the network stable and optimized for the best performance." Devnet uses the limits defined on that page and, for block-level limits, values defined [here (provided by the Blockifier team)](https://github.com/0xSpaceShard/starknet-devnet/blob/main/crates/starknet-devnet-core/src/utils.rs). The block-level limits are considered only when executing transactions, not when constructing the blocks themselves. I.e. if a transaction's usage of a resource exceeds its defined block-level limit, it will be reverted; but if the cumulative usage of all transactions in a block of one resource exceeds the block limit, the block will still be generated. diff --git a/website/versioned_docs/version-0.8.0-rc.2/lite.md b/website/versioned_docs/version-0.8.0-rc.2/lite.md deleted file mode 100644 index 9075f886c..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/lite.md +++ /dev/null @@ -1,22 +0,0 @@ -# Lite mode - -To run Devnet in a minimal lite mode, provide the flag: - -``` -$ starknet-devnet --lite-mode -``` - -Steps skipped in lite mode: - -- **Calculating block hash**: Block hash is simplified and derived from the block number instead of computing the full cryptographic hash -- **Calculating block commitments**: Skips computation of transaction commitment, event commitment, state diff commitment, and receipt commitment - -In lite mode, blocks are still created and transactions are executed normally, but the computationally expensive cryptographic operations for generating block hashes and commitments are bypassed. This improves performance for development and testing scenarios where these values are not required. - -This is useful if your use-case doesn't need the functionalities above, such as when: - -- Testing transaction execution logic -- Running integration tests that don't verify block hashes or commitments -- Rapid prototyping and development iteration - -The extent of what is affected by lite mode may be expanded in the future. diff --git a/website/versioned_docs/version-0.8.0-rc.2/metrics.md b/website/versioned_docs/version-0.8.0-rc.2/metrics.md deleted file mode 100644 index 4c03cf6bc..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/metrics.md +++ /dev/null @@ -1,197 +0,0 @@ -# Metrics - -Starknet Devnet can expose Prometheus-compatible metrics for monitoring and observability. This feature allows you to track RPC calls, block creation, transactions, and upstream forking calls. - -## Enabling Metrics - -To enable metrics, start Devnet with the `--metrics-host` parameter: - -```bash -$ starknet-devnet --metrics-host -``` - -By default, the metrics server will listen on port `9090`. You can customize the port with the `--metrics-port` parameter: - -```bash -$ starknet-devnet --metrics-host 127.0.0.1 --metrics-port 8080 -``` - -Or using environment variables: - -```bash -$ METRICS_HOST=127.0.0.1 METRICS_PORT=8080 starknet-devnet -``` - -If running with Docker: - -```bash -$ docker run -e METRICS_HOST=0.0.0.0 -e METRICS_PORT=9090 -p 9090:9090 shardlabs/starknet-devnet-rs -``` - -## Accessing Metrics - -Once the metrics server is running, you can access the metrics endpoint at: - -``` -http://:/metrics -``` - -For example: - -```bash -$ curl http://127.0.0.1:9090/metrics -``` - -The metrics are exposed in Prometheus text format, which can be scraped by Prometheus or other compatible monitoring systems. - -## Available Metrics - -### RPC Metrics - -#### `rpc_call_duration_seconds` - -**Type:** Histogram - -**Description:** Duration of RPC calls in seconds - -**Labels:** - -- `method`: The RPC method name (e.g., `starknet_getBlockWithTxs`, `starknet_call`) - -**Buckets:** 0.00005, 0.0001, 0.00025, 0.0005, 0.001, 0.0025, 0.005, 0.01, 0.015, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0 seconds - -#### `rpc_call_count` - -**Type:** Counter - -**Description:** Total number of RPC calls - -**Labels:** - -- `method`: The RPC method name -- `status`: Either `success` or `error` - -### Starknet Core Metrics - -#### `starknet_transaction_count` - -**Type:** Counter - -**Description:** Total number of transactions in Starknet - -This counter is incremented when a transaction is added to the network and decremented when blocks are aborted. - -#### `starknet_block_count` - -**Type:** Counter - -**Description:** Total number of blocks in Starknet - -This counter is incremented when a new block is created and decremented when blocks are aborted. - -#### `starknet_block_creation_duration_seconds` - -**Type:** Histogram - -**Description:** Duration of block creation in seconds - -**Buckets:** 0.00005, 0.0001, 0.00025, 0.0005, 0.001, 0.0025, 0.005, 0.01 seconds - -This metric tracks how long it takes to generate a new block and transition from the pre-confirmed state. - -### Upstream Forking Metrics - -These metrics are only relevant when running Devnet in [forking mode](./forking.md). - -#### `starknet_upstream_call_duration_seconds` - -**Type:** Histogram - -**Description:** Duration of upstream forking origin calls in seconds - -**Labels:** - -- `method`: The RPC method called on the upstream network -- `status`: Either `success` or `error` - -**Buckets:** 0.001, 0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0 seconds - -#### `starknet_upstream_call_count` - -**Type:** Counter - -**Description:** Total number of upstream forking origin calls - -**Labels:** - -- `method`: The RPC method called on the upstream network -- `status`: Either `success` or `error` - -These metrics help monitor the performance and reliability of interactions with the forked network. - -## Integrating with Prometheus - -To scrape these metrics with Prometheus, add the following job to your `prometheus.yml` configuration: - -```yaml -scrape_configs: - - job_name: 'starknet-devnet' - static_configs: - - targets: ['localhost:9090'] -``` - -Adjust the target address to match your Devnet metrics server configuration. - -## Example Queries - -Here are some example PromQL queries you can use: - -### Average RPC call duration by method - -```promql -rate(rpc_call_duration_seconds_sum[5m]) / rate(rpc_call_duration_seconds_count[5m]) -``` - -### RPC call rate by method - -```promql -rate(rpc_call_count[5m]) -``` - -### RPC error rate - -```promql -rate(rpc_call_count{status="error"}[5m]) / rate(rpc_call_count[5m]) -``` - -### Block creation rate - -```promql -rate(starknet_block_count[5m]) -``` - -### Transaction throughput - -```promql -rate(starknet_transaction_count[5m]) -``` - -### Upstream call error rate (forking mode) - -```promql -rate(starknet_upstream_call_count{status="error"}[5m]) / rate(starknet_upstream_call_count[5m]) -``` - -### 95th percentile block creation time - -```promql -histogram_quantile(0.95, rate(starknet_block_creation_duration_seconds_bucket[5m])) -``` - -## Visualization with Grafana - -You can visualize these metrics using Grafana by: - -1. Adding Prometheus as a data source -2. Creating dashboards with panels using the PromQL queries above -3. Setting up alerts based on metric thresholds diff --git a/website/versioned_docs/version-0.8.0-rc.2/postman.md b/website/versioned_docs/version-0.8.0-rc.2/postman.md deleted file mode 100644 index 88e49f7de..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/postman.md +++ /dev/null @@ -1,193 +0,0 @@ -# L1-L2 interaction via Postman - -Postman is a Starknet utility that allows testing L1-L2 interaction. It is **unrelated** to the [Postman API platform](https://www.postman.com/). To use it, ensure you have: - -- an L1 node (possibilities listed [below](#l1-network)) -- a Devnet instance (acting as L2 node) -- a [loaded](#load) messaging contract - - this is an L1 contract for exchanging messages between L1 and L2 - - you can deploy a new instance or specify the address of an old one -- an L1 contract that can interact with the messaging contract -- an L2 contract that can interact with the messaging contract - -There are two internal message queues: one for L1->L2 messages, another for L2->L1 messages. When there are messages in a queue, you will need to [flush](#flush) to transmit the messages to their destinations. - -You can use [**`starknet-devnet-js`**](https://github.com/0xSpaceShard/starknet-devnet-js) to assist you in the above listed actions. [**This example**](https://github.com/0xSpaceShard/starknet-devnet-js/blob/master/test/l1-l2-postman.test.ts), especially the `it("should exchange messages between L1 and L2")` test case should be of most help. The required contracts are configured and deployed in the `before` block. Alternatively, you can directly send requests to the endpoints specified below. - -## Load - -```json -// JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanLoad", - "params": { - "network_url": "http://localhost:8545", - "messaging_contract_address": "0x123...def", // optional - "deployer_account_private_key": "0xe2ac...583f" // optional - } -} -``` - -Loads an L1 `MockStarknetMessaging` contract instance, potentially deploying a new one, which is used for message exchange between L1 and L2. - -### L1 network - -The `network_url` parameter refers to the URL of the JSON-RPC API endpoint of the L1 node you've run locally, or which is publicly accessible. Possibilities include, but are not limited to: - -- [**Anvil**](https://github.com/foundry-rs/foundry/tree/master#anvil) -- [**Sepolia testnet**](https://sepolia.etherscan.io/) -- [**Ganache**](https://www.npmjs.com/package/ganache) -- [**Geth**](https://github.com/ethereum/go-ethereum#docker-quick-start) -- [**Hardhat node**](https://hardhat.org/hardhat-network/#running-stand-alone-in-order-to-support-wallets-and-other-software) - -### Messaging contract deployment - -Here's how the rest of the parameters should be used, depending on your L1 network: - -- If your L1 network already has a messaging contract deployed that you wish to use, populate `messaging_contract_address` with its address. - - The provided address shall be checked by asserting that there indeed is contract code deployed at that address, without any ABI assertions. -- If your L1 network does not have such a contract, or you simplify wish to deploy a new instance, leave out the `messaging_contract_address` property. - - If your L1 network is a local testnet (e.g. Anvil) with the default mnemonic seed and a default set of predeployed accounts, you don't have to specify anything else—a new messaging contract shall be deployed using a predeployed account. - - Otherwise (e.g. on the Sepolia testnet or an Anvil with a custom mnemonic seed) you are expected to populate `deployer_account_private_key` with the private key of a funded account. This property is not applicable if `messaging_contract_address` is specified. - -:::note L1-L2 with dockerized Devnet - -L1-L2 communication requires extra attention if Devnet is [run in a Docker container](./running/docker.md). The `network_url` argument must be on the same network as Devnet. E.g. if your L1 instance is run locally (i.e. using the host machine's network), then: - -- on Linux, it is enough to run the Devnet Docker container with `--network host` -- on Mac and Windows, replace any `http://localhost` or `http://127.0.0.1` occurrence in the value of `network_url` with `http://host.docker.internal`. - -::: - -:::info Dumping and Loading - -Loading a messaging contract is a dumpable event, meaning that, if you've enabled dumping, a messaging-contract-loading event will be dumped. Keep in mind that, if you rely on Devnet deploying a new contract, i.e. if you don't specify a contract address of an already deployed messaging contract, a new contract will be deployed at a new address on each loading of the dump. Read more about dumping [here](./dump-load-restart#dumping). - -::: - -## Flush - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanFlush" -} -``` - -Goes through the newly enqueued messages since the last flush, consuming and sending them from L1 to L2 and from L2 to L1. Use it for end-to-end testing. Requires no body. Optionally, set the `dry_run` boolean flag to just see the result of flushing, without actually triggering it: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanFlush", - "params": { "dry_run": true } -} -``` - -:::note - -A running L1 node is required if `dry_run` is not set. - -::: - -:::info Dumping and Loading - -Flushing is not dumpable, meaning that, if you've enabled dumping, a flushing event will not itself be re-executed on loading. This is because it produces L2 messaging events that are themselves dumped. No L1-side actions are dumped, you need to take care of those yourself. Read more about dumping [here](./dump-load-restart#dumping). - -::: - -## Disclaimer - -This method of L1-L2 communication testing differs from how Starknet mainnet and testnets work. Taking [**L1L2Example.sol**](https://github.com/MikeSpa/starknet-test/blob/6a68d033cd7ddb5df937154f860f1c06174e6860/L1L2Example.sol#L46) (originally from Starknet documentation, no longer available there): - -```solidity -constructor(IStarknetCore starknetCore_) public { - starknetCore = starknetCore_; -} -``` - -The constructor takes an `IStarknetCore` contract as argument, however for Devnet's L1-L2 communication testing, this has to be replaced with the logic in [**MockStarknetMessaging.sol**](https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/starknet/testing/MockStarknetMessaging.sol): - -```solidity -constructor(MockStarknetMessaging mockStarknetMessaging_) public { - starknetCore = mockStarknetMessaging_; -} -``` - -## Mock transactions - -### L1->L2 - -:::note - -A running L1 node is **not** required for this operation. - -The L2 target entrypoint must be an `l1_handler`. - -::: - -Sends a mock transactions to L2, as if coming from L1, without the need for running L1. The target L2 contract's address must be provided to `l2_contract_address` and the `entry_point_selector` must refer to a public method of the target contract. The method must be annotated with `l1_handler`, otherwise an `ENTRYPOINT_NOT_FOUND` error may be returned. The `l1_transaction_hash` property is optional and, if provided, enables future `starknet_getMessagesStatus` requests with that hash value provided. - -In regular (non-mocking) L1-L2 interaction, `nonce` is determined by the L1 Starknet contract. In this mock case, it is up to the developer to set it. - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanSendMessageToL2", - "params": { - "l2_contract_address": "0x00285ddb7e5c777b310d806b9b2a0f7c7ba0a41f12b420219209d97a3b7f25b2", - "entry_point_selector": "0xC73F681176FC7B3F9693986FD7B14581E8D540519E27400E88B8713932BE01", - "l1_contract_address": "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512", - "payload": [ "0x1", "0x2" ], - "paid_fee_on_l1": "0x123456abcdef", - "nonce": "0x0", - "l1_transaction_hash": "0x000abc123", // optional - } -} -``` - -Result: - -```js -{ "transaction_hash": "0x0548c761a9fd5512782998b2da6f44c42bf78fb88c3794eea330a91c9abb10bb" } -``` - -### L2->L1 - -Sends a mock transaction from L2 to L1. The deployed L2 contract address `from_address` and `to_address` must be valid. - -It is a mock message, but only in the sense that you are mocking an L2 contract's action, which would normally be triggered by invoking the contract via a transaction. So keep in mind the following: - -:::note - -A running L1 node is required for this operation. - -::: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanConsumeMessageFromL2", - "params": { - "from_address": "0x00285ddb7e5c777b310d806b9b2a0f7c7ba0a41f12b420219209d97a3b7f25b2", - "to_address": "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512", - "payload": ["0x0", "0x1", "0x3e8"], - } -} -``` - -Result: - -```js -{"message_hash": "0xae14f241131b524ac8d043d9cb4934253ac5c5589afef19f0d761816a9c7e26d"} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.2/predeployed.md b/website/versioned_docs/version-0.8.0-rc.2/predeployed.md deleted file mode 100644 index 7b502999c..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/predeployed.md +++ /dev/null @@ -1,87 +0,0 @@ -# Predeployed contracts - -Devnet predeploys: - -- two [UDCs](https://docs.openzeppelin.com/contracts-cairo/udc) - - on the same addresses as Starknet mainnet/testnet - - a legacy instance serving only the `deployContract` entrypoint - - a UDC 2 instance serving both `deployContract` and `deploy_contract` entrypoints -- two [ERC20 (fee token)](https://docs.openzeppelin.com/contracts-cairo/erc20) contracts - - on the same addresses as Starknet mainnet/testnet - - one for STRK - - one for ETH -- a set of predeployed funded accounts - - not a feature of Starknet mainnet/testnet. - -The set of accounts can be controlled via [CLI options](./running/cli): `--accounts `, `--initial-balance `, `--seed `. - -## Predeployed account preservation - -:::note - -Once you shut down your Devnet, the predeployed account you used ceases to exist. This may be a problem with tools such as `starkli` which hardcode your account details in a local file. One option then is to delete your account entry from `starkli`'s account file. Another option is to spawn the same account on next Devnet startup. To do this, you can use: - -- the `--seed ` CLI option which always predeploys the same set of accounts if using the same `` (the seed is logged on startup) -- the [dump and load feature](./dump-load-restart) - -::: - -## Account class selection - -Choose between predeploying Cairo 0 (OpenZeppelin 0.5.1) or Cairo 1 (default; OpenZeppelin 1.0.0) accounts by using: - -``` ---account-class [cairo0 | cairo1] -``` - -Alternatively, provide a path to the [Sierra artifact](https://github.com/starkware-libs/cairo#compiling-and-running-cairo-files) of your custom account using: - -``` ---account-class-custom -``` - -## Predeclared account classes - -Both Cairo 0 and Cairo 1 versions of OpenZeppelin account are always predeclared, regardless of the chosen predeployment variant. If you specify `--predeclare-argent` on startup, the latest regular and multisig Argent account variants will also be predeclared. All predeclared classes can be used in DEPLOY_ACCOUNT transactions. - -## Deploying an undeclared account - -If you want to deploy an instance of an account contract class not predeclared on Devnet, you can use [forking](./forking). Just fork an origin network which has the needed class already declared, e.g. the Sepolia testnet. Why? Because new versions of wallets like ArgentX and Braavos tend to be declared on testnet/mainnet soon after release. - -## How to get predeployment info? - -### Logged on startup - -The startup log includes: - -- the hash values of predeclared classes -- the addresses of predeployed contracts -- the keys and initial balance of predeployed account contracts - -### API - -Account class info can be found in the response to [config request](api#config-api). - -Predeployed account details can be retrieved in JSON format by sending a `JSON-RPC` request. With the additional query parameter `with_balance` set to `true`, ETH and STRK balances at the pre-confirmed state will be provided, in WEI and FRI, respectively: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_getPredeployedAccounts" -} -``` - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_getPredeployedAccounts", - "params": { - // optional; defaults to false - "with_balance": true | false - } -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.2/restrictive.md b/website/versioned_docs/version-0.8.0-rc.2/restrictive.md deleted file mode 100644 index 595f2ffb7..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/restrictive.md +++ /dev/null @@ -1,36 +0,0 @@ -# Restrictive mode - -The `--restrictive-mode` argument enables a restrictive mode for Devnet, allowing you to specify methods that are forbidden during execution. This option ensures that certain operations are restricted, enhancing control over Devnet's behavior. When a user sends a request to one of the restricted methods, Devnet will return either a JSON-RPC error with code -32604 or, if the method was targeted directly via the HTTP endpoint, a response with status 403. - -## Default restricted methods - -When no methods are specified, the following default methods will be restricted, together with their HTTP endpoint counterparts (if any): - -- devnet_mint -- devnet_load -- devnet_restart -- devnet_createBlock -- devnet_abortBlocks -- devnet_impersonateAccount -- devnet_autoImpersonate -- devnet_getPredeployedAccounts - -## Usage - -### With default methods - -``` -$ starknet-devnet --restrictive-mode -``` - -### With a list of methods - -:::note - -Devnet will fail to start if any of the methods/routes are misspelled. - -::: - -``` -$ starknet-devnet --restrictive-mode devnet_dump devnet_config -``` diff --git a/website/versioned_docs/version-0.8.0-rc.2/running/_category_.json b/website/versioned_docs/version-0.8.0-rc.2/running/_category_.json deleted file mode 100644 index 17c529a24..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/running/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Running", - "position": 2, - "link": { - "type": "generated-index" - } -} diff --git a/website/versioned_docs/version-0.8.0-rc.2/running/cli.md b/website/versioned_docs/version-0.8.0-rc.2/running/cli.md deleted file mode 100644 index f34634578..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/running/cli.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -sidebar_position: 2.3 ---- - -# CLI options - -Configure your Devnet instance by specifying CLI parameters on startup. To read more about HTTP and logging configuration, check out the [server config](../server-config) page. - -## Help - -Check out all the options with: - -``` -$ starknet-devnet --help -``` - -Or if using dockerized Devnet: - -``` -$ docker run --rm shardlabs/starknet-devnet-rs --help -``` - -## Environment variables - -Every CLI option can also be specified via an environment variable: - -``` -$ = = starknet-devnet -``` - -To see the exact variable names, use [`--help`](#help). - -### Precedence - -If both a CLI argument and an environment variable are passed for a parameter, the CLI argument takes precedence. If none are provided, the default value is used. E.g. if running Devnet with the following command, seed value 42 will be used: - -``` -$ SEED=10 starknet-devnet --seed 42 -``` - -### Docker - -If using dockerized Devnet, specify the variables like this: - -``` -$ docker run \ - -e = \ - -e = \ - ... \ - shardlabs/starknet-devnet-rs -``` - -## Load configuration from a file - -If providing many configuration parameters in a single command becomes cumbersome, consider loading them from a file. By relying on [environment variables](#environment-variables), prepare your configuration in a file like this: - -```bash -export SEED=42 -export ACCOUNTS=3 -... -``` - -Assuming the file is called `.my-env-file`, then run: - -```bash -$ source .my-env-file && starknet-devnet -``` - -To run in a subshell and prevent environment pollution (i.e. to unset the variables after Devnet exits), use parentheses: - -```bash -$ ( source .my-env-file && starknet-devnet ) -``` - -### Docker - -To load environment variables from `.my-env-file` with Docker, remove the `export` part in each line to have the file look like this: - -``` -SEED=42 -ACCOUNTS=3 -... -``` - -Then run: - -``` -$ docker run --env-file .my-env-file shardlabs/starknet-devnet-rs -``` - -## Proof-related configuration - -Devnet exposes a dedicated proof-mode switch: - -```bash -starknet-devnet --proof-mode -``` - -Equivalent environment variable: - -```bash -PROOF_MODE= -``` - -Mode behavior summary: - -- `devnet` (default): mock proof generation + verification flow is enabled. -- `none`: proof fields are ignored on invoke transactions. -- `full`: reserved for fully verified proofs (currently not implemented). - -For complete examples and RPC payloads, see [Transaction proofs and proof modes](../proofs). diff --git a/website/versioned_docs/version-0.8.0-rc.2/running/docker.md b/website/versioned_docs/version-0.8.0-rc.2/running/docker.md deleted file mode 100644 index e4f011670..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/running/docker.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -sidebar_position: 2.2 ---- - -# Run with Docker - -Devnet is available as a Docker image ([Docker Hub link](https://hub.docker.com/r/shardlabs/starknet-devnet-rs/)). To download the `latest` image, run: - -```text -$ docker pull shardlabs/starknet-devnet-rs -``` - -Supported platforms: linux/amd64 and linux/arm64 (also executable on darwin/arm64). - -Running a container is done like this (see [port publishing](#container-port-publishing) for more info): - -```text -$ docker run -p [HOST:]:5050 shardlabs/starknet-devnet-rs [OPTIONS] -``` - -## Docker image tags - -All of the versions published on crates.io for starknet-devnet are available as docker images, which can be used via: - -``` -$ docker pull shardlabs/starknet-devnet-rs: -``` - -:::note - -The `latest` docker image tag corresponds to the last published version on crates.io. - -::: - -### Accessing Devnet fixes before release - -Commits to the `main` branch of this repository are mostly available as images tagged with their commit hash (the full 40-lowercase-hex-digits SHA1 digest): - -``` -$ docker pull shardlabs/starknet-devnet-rs: -``` - -If a fix has been merged into the `main` branch of Devnet's code repository, you can access it before its inclusion in an official release. Just inspect the [`main` commit list](https://github.com/0xSpaceShard/starknet-devnet/commits/main) and copy the full SHA digest of the commit containing the fix (or preferably the latest commit) which has a green check ✔️ symbol next to the commit date (which indicates the image indeed exists). Some revisions may not have a corresponding Docker image, but these are not supposed to be bugfixes. - -### Zero-seeded set of accounts - -By appending the `-seed0` suffix, you can use images which [predeploy funded accounts](../predeployed) with `--seed 0`, thus always predeploying the same set of accounts: - -``` -$ docker pull shardlabs/starknet-devnet-rs:-seed0 -$ docker pull shardlabs/starknet-devnet-rs:latest-seed0 -``` - -## Container port publishing - -### Linux - -If on a Linux host machine, you can use [`--network host`](https://docs.docker.com/network/host/). This way, the port used internally by the container is also available on your host machine. The `--port` option can be used (as well as other CLI options). - -```text -$ docker run --network host shardlabs/starknet-devnet-rs [--port ] -``` - -### Mac and Windows - -If not on Linux, you need to publish the container's internally used port to a desired `` on your host machine. The internal port is `5050` by default (probably not your concern, but can be overridden with `--port`). - -```text -$ docker run -p [HOST:]:5050 shardlabs/starknet-devnet-rs -``` - -E.g. if you want to use your host machine's `127.0.0.1:5050`, you need to run: - -```text -$ docker run -p 127.0.0.1:5050:5050 shardlabs/starknet-devnet-rs -``` - -You may ignore any address-related output logged on container startup (e.g. `Starknet Devnet listening on 0.0.0.0:5050`). What you will use is what you specified with the `-p` argument. - -If you don't specify the `HOST` part, the server will indeed be available on all of your host machine's addresses (localhost, local network IP, etc.), which may present a security issue if you don't want anyone from the local network to access your Devnet instance. - -## Development note - -Due to internal needs, images with arch suffix are built and pushed to Docker Hub, but this is not mentioned in the user docs as users should NOT be needing it. - -This is what happens under the hood on `main`: - -- build `shardlabs/starknet-devnet-rs--amd` -- build `shardlabs/starknet-devnet-rs--arm` -- create and push joint docker manifest called `shardlabs/starknet-devnet-rs-` - - same for `latest` diff --git a/website/versioned_docs/version-0.8.0-rc.2/running/install.md b/website/versioned_docs/version-0.8.0-rc.2/running/install.md deleted file mode 100644 index 3aa379e26..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/running/install.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -sidebar_position: 2.1 ---- - -# Install and run - -## Requirements - -Any of the approaches below that mention `cargo` require you to have [installed Rust](https://www.rust-lang.org/tools/install). You might also need to install `pkg-config` and `make`. - -The required Rust version is specified in `rust-toolchain.toml` in the project root and handled automatically by `cargo`. - -## Install an executable binary - -Installing an executable binary is achievable with `cargo install` via [crates.io](https://crates.io/) or [github.com](https://github.com). This approach downloads the crate, builds it in release mode and copies it to `~/.cargo/bin/`. To avoid needing to compile and wait, check the [pre-compiled binary section](#fetch-a-pre-compiled-binary-executable). - -### Remove Pythonic Devnet - -If in the past you installed [Pythonic Devnet](https://github.com/0xSpaceShard/starknet-devnet), be sure to remove it to avoid name collision of the old and the new executable - if by no other means, then by `rm $(which starknet-devnet)`. - -### Install from crates.io - -``` -$ cargo install starknet-devnet -``` - -### Install from GitHub - -- Use the `--locked` flag to ensure using the dependencies listed in `Cargo.lock` in the project root. -- Preferably familiarize yourself with the `cargo install` command ([docs](https://doc.rust-lang.org/cargo/commands/cargo-install.html#dealing-with-the-lockfile)). - -``` -$ cargo install --git https://github.com/0xSpaceShard/starknet-devnet.git --locked -``` - -### Install with `asdf` - -- Run the following to add the `starknet-devnet` plugin - -``` -$ asdf plugin add starknet-devnet -``` - -- Show all installable versions: - -``` -$ asdf list-all starknet-devnet -``` - -- Install latest version: - -``` -$ asdf install starknet-devnet latest -``` - -- Install specific version: - -``` -$ asdf install starknet-devnet 0.2.0 -``` - -Check [asdf guide](https://asdf-vm.com/guide/getting-started.html) for more instructions on how to install & manage versions. - -### Install with starkup - -[Starkup](https://github.com/software-mansion/starkup) is a tool for installing and managing Starknet-related tools, including starknet-devnet. To run starkup itself: - -``` -$ curl --proto '=https' --tlsv1.2 -sSf https://sh.starkup.sh | sh -``` - -Starkup uses `asdf` underneath to manage tool versions. After installation, you can use standard ASDF commands to manage starknet-devnet. - -Make sure to restart your terminal or source your shell configuration file after installation to have starknet-devnet available in your PATH. - -### Run the installed executable - -When `cargo install` or another installation method finishes, follow the output in your terminal. If properly configured, you should be able to run Devnet with: - -``` -$ starknet-devnet -``` - -## Fetch a pre-compiled binary executable - -If you want to save time and skip project compilation on installation, since Devnet v0.0.5, the Assets section of each [GitHub release](https://github.com/0xSpaceShard/starknet-devnet/releases) contains a set of platform-specific pre-compiled binary executables. Extract and run with: - -``` -$ curl -sSfL https://github.com/0xSpaceShard/starknet-devnet/releases/download// | tar -xvz -C -$ /starknet-devnet -``` - -## Run from source - -To install the project from source, after [git-cloning](https://github.com/git-guides/git-clone) the [Devnet repository](https://github.com/0xSpaceShard/starknet-devnet), running the following command will install, build and start Devnet: - -``` -$ cargo run -``` - -Specify optional CLI params like this: - -``` -$ cargo run -- [ARGS] -``` - -For a more optimized performance (though with a longer compilation time), run: - -``` -$ cargo run --release -``` diff --git a/website/versioned_docs/version-0.8.0-rc.2/server-config.md b/website/versioned_docs/version-0.8.0-rc.2/server-config.md deleted file mode 100644 index e9e5b5c33..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/server-config.md +++ /dev/null @@ -1,77 +0,0 @@ -# Server config - -To read generally about ways to configure your Devnet instance, check out the [CLI section](./running/cli.md). - -## Host and port - -Specify the host and the port used by the server with `--host
` and `--port ` CLI arguments. If running with Docker, check out the [port publishing docs](./running/docker#container-port-publishing). - -## Logging - -By default, the logging level is `INFO`, but this can be changed via the `RUST_LOG` environment variable. - -All logging levels: `TRACE`, `DEBUG`, `INFO`, `WARN`, `ERROR` - -To specify the logging level and run Devnet on the same line: - -``` -$ RUST_LOG= starknet-devnet -``` - -or if using dockerized Devnet: - -``` -$ docker run -e RUST_LOG= shardlabs/starknet-devnet-rs -``` - -By default, logging of request and response data is turned off. -To see the request and/or response body, additional levels can be specified via the `RUST_LOG` environment variable: `REQUEST` for request body, `RESPONSE` for response body. - -:::note - -Logging request and response requires at least logging level `INFO`. - -For example, the following two commands will log request and response data with log level `INFO`. - -``` -$ RUST_LOG="REQUEST,RESPONSE" starknet-devnet -``` - -``` -$ RUST_LOG="REQUEST,RESPONSE,INFO" starknet-devnet -``` - -::: - -## Timeout - -Specify the maximum amount of time an HTTP request can be served. This makes it possible to deploy and manage large contracts that take longer to execute. - -``` -$ starknet-devnet --timeout -``` - -## Size limits - -There is no HTTP request size limit, but take care when declaring large classes! Devnet is supposed to follow the limits specified in [Starknet chain Info](https://docs.starknet.io/resources/chain-info/#current_limits). - -If, however, you need to customize the limits, you may rely on the following CLI parameters on Devnet startup: - -- `--maximum-contract-class-size ` -- `--maximum-contract-bytecode-size ` -- `--maximum-sierra-length ` - -The default upper limits configured in Devnet can be found [among constants](https://github.com/0xSpaceShard/starknet-devnet/blob/main/crates/starknet-devnet-core/src/constants.rs#L121). - -## API - -Retrieve the server config by sending a `JSON-RPC` request with method name `devnet_getConfig` and extracting its `server_config` property. - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_getConfig" -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.2/starknet-time.md b/website/versioned_docs/version-0.8.0-rc.2/starknet-time.md deleted file mode 100644 index 341e6d70a..000000000 --- a/website/versioned_docs/version-0.8.0-rc.2/starknet-time.md +++ /dev/null @@ -1,70 +0,0 @@ -# Starknet time - -Block and state timestamp can be manipulated by setting the exact time or setting the time offset. By default, timestamp methods `devnet_setTime` and `devnet_increaseTime` of JSON-RPC API generate a new block. This can be changed for `devnet_setTime` by setting the optional parameter `generate_block` to `false`. This skips immediate new block generation, but will use the specified timestamp whenever the next block is supposed to be generated. - -All values should be set in [Unix time seconds](https://en.wikipedia.org/wiki/Unix_time). After [startup](#start-time), the time progresses naturally. - -## Set time - -The following sets the exact time and generates a new block: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_setTime", - "params": { - "time": TIME_IN_SECONDS - } -} -``` - -The following doesn't generate a new block, but sets the exact time for the next generated block: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_setTime", - "params": { - "time": TIME_IN_SECONDS, - "generate_block": false - } -} -``` - -Warning: block time can be set in the past which might lead to unexpected behavior! - -## Increase time - -Increases the block timestamp by the provided amount and generates a new block. All subsequent blocks will keep this increment. - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_increaseTime", - "params": { - "time": TIME_IN_SECONDS - } -} -``` - -:::note Increment example - -Imagine a block is generated with timestamp `T1`, some time passes (let's call this interval `T_passed`), and you call increase_time with `T_inc` as the argument, which immediately mines a new block at `T2`. `T2` should equal `T1 + T_passed + T_inc`. - -::: - -## Start time - -Devnet's starting timestamp can be defined via CLI by providing a positive value of [Unix time seconds](https://en.wikipedia.org/wiki/Unix_time) to `--start-time`: - -``` -$ starknet-devnet --start-time -``` - -If provided, this timestamp shall be used in mining the genesis block. The default value is the current Unix time. diff --git a/website/versioned_docs/version-0.8.0-rc.3/account-impersonation.md b/website/versioned_docs/version-0.8.0-rc.3/account-impersonation.md deleted file mode 100644 index 951860c27..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/account-impersonation.md +++ /dev/null @@ -1,92 +0,0 @@ -# Account impersonation - -:::info - -This page is about account impersonation. To read about account class selection and deployment, click [here](./predeployed). - -::: - -## Introduction - -Devnet allows you to impersonate an account that exists on the Starknet mainnet or testnet. This is achieved by skipping the validation step of transactions for all or some accounts, on a running Devnet via JSON-RPC. - -A transaction sent from an impersonated account will not fail with an invalid signature error, which is what happens in the general case of locally absent accounts. For impersonation to work, Devnet needs to [fork](./forking.md) the network that has the desired account. - -:::warning Caveat - -- Only `INVOKE` and `DECLARE` transactions are supported. `DEPLOY_ACCOUNT` transaction is not supported, but you can create an `INVOKE` transaction to UDC. -- Due to the validation step being skipped, the overall fee of transactions sent with an impersonated account will be lower than regular transactions. -- Trying to send a transaction with an account that **does not** even exist in the origin network returns an error: - - `ContractNotFound` if, during transaction preparation, you do not specify a nonce value, leading to the implicit querying of Devnet for the nonce. - - `InsufficientAccountBalance` or similar if the nonce is supplied in the transaction; this happens because the token balance of a non-existent contract is 0 indeed insufficient. - -::: - -## Tips - -- The impersonated account may have had all or a part of its funds used up on the origin network. You may need to give it more funds via [minting](./balance.md). -- If you're defining a new account in your Starknet client application (starknet.js, starknet.rs, starkli...), you may need to specify a private key for it. Since the signature validation is skipped, you may provide a dummy key. - -## API - -Account impersonation follows JSON-RPC method specification. Each method returns an empty response: - -### devnet_impersonateAccount - -Impersonates a specific account address nonexistent in the local state. - -```js -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_impersonateAccount", - "params": { - "account_address": "0x49D36570D4E46F48E99674BD3FCC84644DDD6B96F7C741B1562B82F9E004DC7" - } -} -``` - -### devnet_stopImpersonateAccount - -Stops the impersonation of an account previously marked for impersonation. - -```js -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_stopImpersonateAccount", - "params": { - "account_address": "0x49D36570D4E46F48E99674BD3FCC84644DDD6B96F7C741B1562B82F9E004DC7" - } -} -``` - -### devnet_autoImpersonate - -Enables automatic account impersonation. Every account that does not exist in the local state will be impersonated. - -```js -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_autoImpersonate", - "params": {} -} -``` - -### devnet_stopAutoImpersonate - -Stops the effect of [automatic impersonation](#devnet_autoimpersonate). - -```js -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_stopAutoImpersonate", - "params": {} -} -``` - -## Preventing impersonation - -If you want to learn about completely preventing impersonation from being activated on your Devnet, click [here](./restrictive.md). diff --git a/website/versioned_docs/version-0.8.0-rc.3/api.md b/website/versioned_docs/version-0.8.0-rc.3/api.md deleted file mode 100644 index 7ee0c5e6a..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/api.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -sidebar_position: 3 ---- - -# API - -## JSON-RPC API - -Both Starknet's and Devnet's JSON-RPC API are reachable at `/rpc` and `/`. E.g. if spawning Devnet with default settings, these URLs are functionally equivalent: `http://127.0.0.1:5050/rpc` and `http://127.0.0.1:5050/`. The difference between these two groups of methods is their prefix: `starknet_` (e.g. `starknet_getNonce`) and `devnet_` (e.g. `devnet_mint`). - -### Starknet API - -Unlike Pythonic Devnet, which also supported Starknet's gateway and feeder gateway API, Devnet in Rust supports [Starknet's JSON-RPC API](https://github.com/starkware-libs/starknet-specs/tree/master/api), including [WebSocket support](#websocket). - -Due to how Devnet internally works, the method `starknet_getStorageProof` is not applicable, and thus not supported. - -Devnet also provides a proof-related extension method `starknet_proveTransaction`. For supported modes, behavior, and usage examples, check [Transaction proofs and proof modes](./proofs). - -Since JSON-RPC v0.6.0, to find out which JSON-RPC version is supported by which Devnet version, check out the [releases page](https://github.com/0xspaceshard/starknet-devnet/releases). - -### Devnet API - -Devnet has many additional features available via JSON-RPC. The RPC methods are documented throughout the documentation in their corresponding pages, but are also aggregated [here](https://github.com/0xSpaceShard/starknet-devnet/blob/main/website/static/devnet_api.json). - -#### Healthcheck - -To check if a Devnet instance is alive, send an HTTP request `GET /is_alive`. If alive, Devnet will reply with a `200 OK` and an appropriate message. This is the only special functionality not provided as part of the JSON-RPC API. - -### WebSocket - -The whole [Starknet](#starknet-api) and [Devnet](#devnet-api) JSON-RPC API, including [WebSocket subscription methods](https://github.com/starkware-libs/starknet-specs/blob/v0.9.0/api/starknet_ws_api.json) can be accessed via the WebSocket protocol, using text or binary messages. Devnet listens for new WebSocket connections at `ws://:/ws` (notice the protocol scheme). E.g. using [`wscat`](https://www.npmjs.com/package/wscat) on the same computer where Devnet is spawned at default host and port: - -``` -$ wscat -c ws://127.0.0.1:5050/ws -Connected (press CTRL+C to quit) -> { "jsonrpc": "2.0", "id": 0, "method": "starknet_subscribeNewHeads" } -< {"id":0,"result":2935616350010920547,"jsonrpc":"2.0"} -``` - -#### WebSocket persistence - -[Restarting](./dump-load-restart#restarting) and [loading](./dump-load-restart#loading) do not affect Devnet's WebSocket connections, but remove all subscriptions. - -## Interacting with Devnet in JavaScript and TypeScript - -To spawn Devnet and interact with it using the [Devnet API](#devnet-api), you can use [`starknet-devnet-js`](https://github.com/0xSpaceShard/starknet-devnet-js/). This can be especially useful in achieving [L1-L2 communication](./postman.md). - -To interact with Devnet using the [Starknet API](#starknet-api), use [starknet.js](https://www.starknetjs.com/). - -## Config API - -To retrieve the current configuration of Devnet, as specified via [CLI](running/cli.md) and later requests, send a `JSON-RPC` request with method name `devnet_getConfig`. Example response is attached below. It can be interpreted as a JSON mapping of CLI input parameters, both specified and default ones, with some irrelevant parameters omitted. So use `starknet-devnet --help` to better understand the meaning of each value, though keep in mind that some of the parameters have slightly modified names. The exact values may have changed and should not be referenced. - -```json -{ - "seed": 4063802897, - "total_accounts": 10, - "account_contract_class_hash": "0x61dac032f228abef9c6626f995015233097ae253a7f72d68552db02f2971b8f", - "predeployed_accounts_initial_balance": "1000000000000000000000", - "start_time": null, - "gas_price_wei": 100000000000, - "gas_price_fri": 100000000000, - "data_gas_price_wei": 100000000000, - "data_gas_price_fri": 100000000000, - "l2_gas_price_wei": 100000000000, - "l2_gas_price_fri": 100000000000, - "chain_id": "SN_SEPOLIA", - "dump_on": "exit", - "dump_path": "dump_path.json", - "state_archive": "none", - "fork_config": { - "url": "http://rpc.pathfinder.equilibrium.co/integration-sepolia/rpc/v0_7", - "block_number": 26429 - }, - "server_config": { - "host": "127.0.0.1", - "port": 5050, - "timeout": 120, - "restricted_methods": null - }, - "block_generation": null, - "lite_mode": false, - "eth_erc20_class_hash": "0x046ded64ae2dead6448e247234bab192a9c483644395b66f2155f2614e5804b0", - "strk_erc20_class_hash": "0x046ded64ae2dead6448e247234bab192a9c483644395b66f2155f2614e5804b0" -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.3/balance.md b/website/versioned_docs/version-0.8.0-rc.3/balance.md deleted file mode 100644 index db9cf475f..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/balance.md +++ /dev/null @@ -1,65 +0,0 @@ -# Account balance - -Other than using prefunded predeployed accounts, you can also add funds to an account that you deployed yourself. - -Separate tokens use separate ERC20 contracts for minting and charging fees. These are the token contracts predeployed by Devnet and the addresses where they are located: - -- ETH: `0x49d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7` -- STRK: `0x04718f5a0fc34cc1af16a1cdee98ffb20c31f5cd61d6ab07201858f4287c938d` - -## Mint token - Local faucet - -By sending a `JSON-RPC` request with method name `devnet_mint` for a token, you initiate a transaction on that token's ERC20 contract. The response contains the hash of this transaction, as well as the new balance after minting. The token is specified by providing the unit, and defaults to `FRI` (the unit of `STRK`). - -The value of `amount` is in WEI or FRI. The precision is preserved if specifying an integer or a float whose fractional part is zero (e.g. `1000.0`, `1e21`). If the fractional part is non-zero, the amount is truncated to the nearest integer (e.g. `3.9` becomes `3` and `1.23e1` becomes `12`). - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_mint", - "params": { - "address": "0x6e3205f...", - "amount": 500000, - "unit": "WEI" | "FRI" - } -} -``` - -Result: - -``` -{ - "new_balance": 500000, - "unit": "WEI" | "FRI", - "tx_hash": "0xa24f23..." -} -``` - -In case of a reverted minting request, an error is returned containing the stringified revert reason and the hex string of the hash of the reverted transaction for further inspection: - -``` -{ - "tx_hash": "0x123..." - "revert_reason": "Something happened" -} -``` - -## Check balance - -Check the balance of an address by sending a `JSON-RPC` request. The address should be a 0x-prefixed hex string; `unit` defaults to `FRI` (the unit of `STRK`) and `block_id` to `latest`. - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_getAccountBalance", - "params": { - "address": "0x6e3205f...", - "unit": "WEI" | "FRI", - "block_id": - } -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.3/blocks.md b/website/versioned_docs/version-0.8.0-rc.3/blocks.md deleted file mode 100644 index 91e7db154..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/blocks.md +++ /dev/null @@ -1,182 +0,0 @@ -# Blocks - -## State commitment - -Block states are not committed in a Merke-Patricia trie or a similar tree-like structure. Block roots are therefore set to 0. - -## Genesis block - -By default, Devnet starts with a genesis block labelled with number zero. In [forking mode](./forking), the genesis block number is equal to the forked block number plus one. - -## Limits - -To read more about block limits, see [this](./intro#limits). - -## Creating blocks on transaction - -If you start Devnet with `--block-generation-on transaction`, a new block is generated with each new transaction. This is the default block generation regime. This mode also supports [empty block creation](#request-new-block-creation). - -## Creating blocks on demand - -If you start Devnet with the `--block-generation-on demand` CLI option, you will enable the possibility to store more than one transaction in the pre-confirmed block (targetable via block tag `"pre_confirmed"`). - -Once you've added the desired transactions into the pre-confirmed block, you can [request new block creation](#request-new-block-creation). This will convert the pre-confirmed block to the latest block (targetable via block tag `"latest"`), giving it a block hash and a block number. All subsequent transactions will be stored in a new pre-confirmed block. - -In case of demanding block creation with no pre-confirmed transactions, a new empty block will be generated. - -The creation of the genesis block is not affected by this feature. - -The specifications of a block-creating request can be found [below](#request-new-block-creation). - -## Automatic periodic block creation - -If started with the `--block-generation-on ` CLI option, Devnet will behave as in [`demand` mode](#creating-blocks-on-demand), but new blocks will be mined automatically every `` seconds. Consider this example of spawning Devnet at moment `t`: - -```bash -# t -$ starknet-devnet --block-generation-on 10 - -# t + 1s -# user: send tx1 - -# t + 4s -# user: send tx2 - -# t + 10s -# Devnet: block automatically generated, contains tx1 and tx2 - -# t + 12s -# user: send tx3 - -# t + 14s -# user: invoke empty block creation -# Devnet: generated block contains tx3 - -# t + 20s -# Devnet: block automatically generated, contains no txs (manual creation did not restart the counter) -``` - -## Request new block creation - -To request the creation of a new block, send: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_createBlock" -} -``` - -Result: - -``` -{"block_hash": "0x115e1b390cafa7942b6ab141ab85040defe7dee9bef3bc31d8b5b3d01cc9c67"} -``` - -The newly created block will contain all pre-confirmed transactions, if any, since the last block creation. - -## Timestamp manipulation - -To affect the timestamp of the newly created block, check out [this page](./starknet-time#set-time) - -## Block abortion - -This functionality allows simulating block abortion that can occur on mainnet as a consequence of e.g. block reorganization. Aborted blocks and their transactions are removed from Devnet's memory. - -:::note - -Block abortion is only supported if Devnet is started in the `--state-archive-capacity full` mode. - -::: - -You can abort blocks and revert transactions from the specified block to the currently latest block. Newly created blocks after the abortion will have accepted status and will continue with numbering where the last accepted block left off. - -The state of Devnet will be reverted to the state of the last accepted block. - -### Example - -Assume there are 3 accepted blocks numbered 1, 2 and 3. Upon receiving a request to abort blocks starting with block 2, the blocks numbered 2 and 3 are aborted and their transactions reverted. The state of network will be as it was in block 1. Once a new block is mined, it will be accepted and it will have number 2. - -### Limitations - -Aborted blocks can only be queried by block hash. Devnet does not support the abortion of: - -- blocks in the forking origin (i.e. blocks mined before the forked block) -- already aborted blocks -- Devnet's genesis block. - -### Websocket subscription notifications - -On block abortion, a `starknet_subscriptionReorg` notification will be sent to all websocket subscribers requiring so according to [JSON-RPC websocket API specification](https://github.com/starkware-libs/starknet-specs/blob/v0.8.0/api/starknet_ws_api.json#L236). The `starting_block` of the orphaned chain is the successor of the new latest block and the `ending_block` of the orphaned chain is the block that was latest before aborting. One reorg notification is sent per subscription, not per websocket, meaning that if a websocket has n subscriptions, it will receive n reorg notifications, each with its own subscription ID. - -If a socket has subscribed to transaction status changes of a transaction `tx1` using `starknet_subscribeTransactionStatus` and the block holding `tx1` gets aborted, a `starknet_subscriptionTransactionStatus` notification shall NOT be sent. The socket shall have to rely on handling `starknet_subscriptionReorg`. - -### Request and response - -To abort, send: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_abortBlocks", - "params": { - "starting_block_id": BLOCK_ID - } -} -``` - -Result: - -``` -{ - "aborted": [BLOCK_HASH_0, BLOCK_HASH_1, ...] -} -``` - -:::note - -When aborting the currently `pre_confirmed` block, it is mined and aborted as latest. - -::: - -## Accepting blocks on L1 - -This functionality allows simulating block acceptance on L1 (Ethereum). It merely marks the requested blocks and their transactions as `ACCEPTED_ON_L1`. It is only supported on blocks that are `ACCEPTED_ON_L2` and fails for all others, including blocks already `ACCEPTED_ON_L1`. In case of [forking](./forking), blocks on forking origin cannot be affected by this feature. - -:::note - -This functionality does not actually perform actions on L1. - -::: - -### Example - -Assume Devnet has mined blocks with numbers: 0 (origin), 1, 2 and 3. If this feature is invoked with `starting_block_id={"block_number": 2}`, blocks 0, 1 and 2 shall be `ACCEPTED_ON_L1` and block 3 shall remain `ACCEPTED_ON_L2`. If after that another block (number 4) is mined, and this feature is invoked with `starting_block_id="latest"`, blocks 0, 1, 2, 3 and 4 shall be `ACCEPTED_ON_L1`. If a new block is mined after that (number 5), it shall be `ACCEPTED_ON_L2`. - -### Request and response - -To accept a block and its transactions on L1, send: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_acceptOnL1", - "params": { - "starting_block_id": BLOCK_ID - } -} -``` - -Result: - -``` -{ - "accepted": [BLOCK_HASH_0, BLOCK_HASH_1, ...] -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.3/dump-load-restart.md b/website/versioned_docs/version-0.8.0-rc.3/dump-load-restart.md deleted file mode 100644 index 7735dc212..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/dump-load-restart.md +++ /dev/null @@ -1,144 +0,0 @@ -# Dump, load, restart - -## Dumping - -To preserve your Devnet instance for future use, these are the options: - -- Dumping on exit (handles Ctrl+C, i.e. SIGINT; doesn't handle SIGKILL): - -``` -$ starknet-devnet --dump-on exit --dump-path -``` - -- Dumping after each block: - -``` -$ starknet-devnet --dump-on block --dump-path -``` - -- Dumping on request, which requires providing `--dump-on request` on startup. You can also dump on request if you specified any of the other `--dump-on` modes. - -### Dumping on request - -You can request dumping via JSON-RPC. An optional file path can be provided in the request or on startup via `--dump-path ` (the HTTP request parameter takes precedence). If no dumping path is specified, the dump is included in the response body. This means that if you request dumping via [`curl`](https://curl.se/), it will be printed to STDOUT, which you can then redirect to a destination of your choice. - -``` -$ starknet-devnet --dump-on [--dump-path ] -``` - -- No body parameters: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_dump" -} -``` - -- With a custom path: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_dump", - "params": { - // optional; defaults to the path specified via CLI if defined - "path": - } -} -``` - -## Loading - -To load a preserved Devnet instance, the options are: - -- Loading on startup (note the argument name is not `--load-path` as it was in Devnet-py): - -``` -$ starknet-devnet --dump-path -``` - -- Loading on request, which replaces the current state with the one in the provided file. It can be done via JSON-RPC: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_load", - "params": { - "path": - } -} -``` - -### Loading disclaimer - -Currently, dumping produces a list of reproducible Devnet actions (state-changing requests and transactions). Conversely, loading is implemented as the re-execution of transactions from a dump. This means that timestamps of `StarknetBlock` will be different on each load. This is due to the nature of Devnet's dependencies, which prevent Devnet's state from being serialized. - -Dumping and loading are not guaranteed to work across versions. I.e. if you dumped one version of Devnet, do not expect it to be loadable with a different version. - -If you dumped a Devnet utilizing one class for account predeployment (e.g. `--account-class cairo0`), you should use the same option when loading. The same applies for dumping a Devnet in `--block-generation-on demand` mode. - -Loading does not affect WebSocket connections, but removes all WebSocket [subscriptions](./api#websocket). - -## Restarting - -Devnet can be restarted by making a `JSON-RPC` request with method name `devnet_restart`. All deployed contracts (including predeployed), blocks and storage updates will be restarted to the original state, without the transactions and requests that may have been loaded from a dump file on startup. - -Restarting does not affect WebSocket connections, but removes all WebSocket [subscriptions](./api#websocket). - -### Restarting and L1-L2 messaging - -If you're doing [L1-L2 message exchange](./postman), restarting will by default not affect Devnet's connection with L1 nor the L1->L2 message queue. The effect that L1-L2 messages may have had on Devnet before restarting shall be reverted, including any L2 contracts used for messaging. Also, calling [`flush`](./postman#flush) will not have new messages to read until they are actually sent. If you wish to re-process the already-seen L1->L2 messages when you restart, make them accessible again by setting the `restart_l1_to_l2_messaging` parameter shown below. If you set this flag: - -- you will need to [reload the L1-side messaging contract](./postman#load) -- the L1->L2 messages won't be restarted in the sense of being deleted, but access to them shall be regained via [`flush`](./postman#flush) -- the L2->L1 message queue is restarted regardless of the flag - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_restart", - "params": { - // optional parameter, defaults to false - "restart_l1_to_l2_messaging": true | false - } -} -``` - -## Docker - -To enable dumping and loading with dockerized Devnet, you must bind the container path to the path on your host machine. - -This example: - -- Relies on [Docker bind mount](https://docs.docker.com/storage/bind-mounts/); try [Docker volume](https://docs.docker.com/storage/volumes/) instead. -- Assumes that `/path/to/dumpdir` exists. If unsure, use absolute paths. -- Assumes you are listening on `127.0.0.1:5050`. - -If there is `mydump` inside `/path/to/dumpdir`, you can load it with: - -``` -docker run \ - -p 127.0.0.1:5050:5050 \ - --mount type=bind,source=/path/to/dumpdir,target=/path/to/dumpdir \ - shardlabs/starknet-devnet-rs \ - --dump-path /path/to/dumpdir/mydump -``` - -To dump to `/path/to/dumpdir/mydump` on Devnet shutdown, run: - -``` -docker run \ - -p 127.0.0.1:5050:5050 \ - --mount type=bind,source=/path/to/dumpdir,target=/path/to/dumpdir \ - shardlabs/starknet-devnet-rs \ - --dump-on exit --dump-path /path/to/dumpdir/mydump -``` diff --git a/website/versioned_docs/version-0.8.0-rc.3/examples.md b/website/versioned_docs/version-0.8.0-rc.3/examples.md deleted file mode 100644 index 5704af4da..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/examples.md +++ /dev/null @@ -1,3 +0,0 @@ -# Examples - -Usage examples relying on the [`starknet-devnet-js`](https://github.com/0xspaceShard/starknet-devnet-js) library can be found [here](https://github.com/0xSpaceShard/starknet-devnet-js/tree/master/test). diff --git a/website/versioned_docs/version-0.8.0-rc.3/forking.md b/website/versioned_docs/version-0.8.0-rc.3/forking.md deleted file mode 100644 index 8fa081264..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/forking.md +++ /dev/null @@ -1,47 +0,0 @@ -# Forking - -To interact with contracts deployed on mainnet or testnet, you can use forking. Simulate the origin and experiment with it locally, making no changes to the origin itself. - -``` -$ starknet-devnet --fork-network [--fork-block ] -``` - -The value passed to `--fork-network` should be the URL to a Starknet JSON-RPC API provider. Specifying a `--fork-block` is optional; it defaults to the `"latest"` block at the time of Devnet's start-up. All calls will first try Devnet's state and then fall back to the forking block. - -:::note How it works - -When you send a request to a forked Devnet instance, it first queries Devnet's local state, then tries the forking origin. Forking is not a step simply performed on Devnet startup, but happens continuously while the Devnet instance is alive. - -::: - -## Upstream caching - -By default, Devnet does not cache responses from the fork upstream network. However, you can enable caching to improve performance and reduce the number of requests sent to the origin by using the `--fork-upstream-caching` flag: - -``` -$ starknet-devnet --fork-network --fork-upstream-caching -``` - -:::tip Performance improvement - -Enabling upstream caching can significantly improve performance by reducing redundant requests to the fork origin. - -::: - -## Forking and ACCEPTED_ON_L1 - -Assume you have run Devnet as a fork from an origin at a block that is not yet `ACCEPTED_ON_L1`, but only `ACCEPTED_ON_L2`. If in your state queries you specify `block_id: "l1_accepted"`, and there are no local blocks marked as `ACCEPTED_ON_L1`, Devnet will assume the forking block has become `ACCEPTED_ON_L1`. - -Read more about marking blocks as `ACCEPTED_ON_L1` on Devnet: [link](./blocks#accepting-blocks-on-l1). - -## Account impersonation - -[Here](./account-impersonation) you can read more about acting as an account deployed on the origin. - -## Deploying an undeclared account - -[Here](./predeployed#deploying-an-undeclared-account) you can read about deploying an account not declared on Devnet. - -## Checking forking status - -To see if your Devnet instance is using forking or not, [fetch the current configuration](./api#config-api), and check the `url` property of its `fork_config` property. If Devnet is forked, this property contains the string of the origin URL specified on startup. diff --git a/website/versioned_docs/version-0.8.0-rc.3/gas.md b/website/versioned_docs/version-0.8.0-rc.3/gas.md deleted file mode 100644 index fcff305bb..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/gas.md +++ /dev/null @@ -1,55 +0,0 @@ -# Gas price modification - -## On Devnet startup - via CLI - -All gas prices (L1 gas, L1 data gas, L2 gas) can be specified on startup, via their respective CLI params. Check `starknet-devnet --help | grep price` for more info. - -## On a running Devnet - via JSON-RPC - -The `devnet_setGasPrice` RPC method allows users to modify the current gas prices on a running Devnet. This feature is particularly useful for testing purposes and for adjustments needed after forking to align with the forked network's gas prices. All parameters are optional, allowing you to choose which ones you want to set. A boolean flag `generate_block` indicates whether a new block should be generated immediately after setting the gas prices. - -### Explanation - -The modified gas prices take effect starting with the next block that is generated. - -### generate_block - -- When set to `true`, a new block will be generated immediately after the gas prices are set. This ensures that the changes take effect right away and are reflected in the devnet state without waiting for the next block generation. -- When set to `false` (or omitted), the gas prices will be set, but the changes will not be immediately committed to the devnet state until the next block is generated through the usual block generation process. - -### JSON-RPC Request - -The following JSON-RPC request can be used to set gas prices (all properties optional): - -```json -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_setGasPrice", - "params": { - "gas_price_wei": 1000000, - "data_gas_price_wei": 10000, - "gas_price_fri": 10000, - "data_gas_price_fri": 10000, - "l2_gas_price_wei": 1000000, - "l2_gas_price_fri": 10000, - "generate_block": false, - } -} -``` - -## Response - -The expected response from the server will mirror the request gas parameters, confirming the modification of gas prices: - -```json -{ - "gas_price_wei": 1000000, - "data_gas_price_wei": 10000, - "gas_price_fri": 10000, - "data_gas_price_fri": 10000, - "l2_gas_price_wei": 10000, - "l2_gas_price_fri": 10000 -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.3/historic-state.md b/website/versioned_docs/version-0.8.0-rc.3/historic-state.md deleted file mode 100644 index f2358c680..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/historic-state.md +++ /dev/null @@ -1,9 +0,0 @@ -# Historic state support - -With state archive capacity set to `full`, Devnet will store full state history, enabling its querying by block hash or number. The default mode is `none`, where no old states are stored and only the latest is available for querying. - -``` -$ starknet-devnet --state-archive-capacity -``` - -All RPC endpoints that support querying the state at an old (non-latest) block only work with state archive capacity set to `full`. diff --git a/website/versioned_docs/version-0.8.0-rc.3/intro.md b/website/versioned_docs/version-0.8.0-rc.3/intro.md deleted file mode 100644 index 7d498fb75..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/intro.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Intro - -:::danger Difference disclaimer - -- Devnet should not be used as a replacement for the official testnet. After testing on Devnet, be sure to test on testnet (alpha-sepolia)! -- Devnet does not organize state data into Merkle-Patricia tries or similar tree-like structures, so: - - Calling the `starknet_getStorageProof` RPC method shall always result in `STORAGE_PROOF_NOT_SUPPORTED`. - - Block roots are set to 0. -- The pre-confirmed block is equivalent to the old pending block, except that its transactions are not `ACCEPTED_ON_L2` but `PRE_CONFIRMED`. -- By default, a new block is mined for each new transaction. - - This can be modified by directing all new transactions into a pre-confirmed block, and at some point triggering block creation. - - Transactions in a pre-confirmed block cannot be replaced by sending a transaction with a higher free from the same account. - - Read more about transitioning a transaction [from `PRE_CONFIRMED` to `ACCEPTED_ON_L2`](./blocks#creating-blocks-on-demand). -- Block hashes on devnet differ from mainnet because some mainnet block fields are unavailable to devnet, resulting in different hash outputs despite using the same hashing algorithm. -- Transactions are never automatically `ACCEPTED_ON_L1`, unless the user performs an action. - - Read more about transitioning a transaction [from `ACCEPTED_ON_L2` to `ACCEPTED_ON_L1`](./blocks#accepting-blocks-on-l1). -- `RECEIVED` and `CANDIDATE` statuses are not used in Devnet. -- In Starknet 0.14.1, field `migrated_compiled_classes` was introduced to the `state_diff`. In devnet, this field will always be empty: - - When starting devnet without forking there is nothing to migrate - - In forking mode, there is no RPC support to fetch compiled class hashes from origin, so it is impossible for devnet to determine which classes have to be migrated - -::: - -You may now proceed with [running Devnet](./running/install) and checking out the multitude of features listed in the sidebar on the left. - -# Limits - -As mentioned [here](https://docs.starknet.io/tools/limits-and-triggers/), "Starknet currently has a number of limits in place in order to keep the network stable and optimized for the best performance." Devnet uses the limits defined on that page and, for block-level limits, values defined [here (provided by the Blockifier team)](https://github.com/0xSpaceShard/starknet-devnet/blob/main/crates/starknet-devnet-core/src/utils.rs). The block-level limits are considered only when executing transactions, not when constructing the blocks themselves. I.e. if a transaction's usage of a resource exceeds its defined block-level limit, it will be reverted; but if the cumulative usage of all transactions in a block of one resource exceeds the block limit, the block will still be generated. diff --git a/website/versioned_docs/version-0.8.0-rc.3/lite.md b/website/versioned_docs/version-0.8.0-rc.3/lite.md deleted file mode 100644 index 9075f886c..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/lite.md +++ /dev/null @@ -1,22 +0,0 @@ -# Lite mode - -To run Devnet in a minimal lite mode, provide the flag: - -``` -$ starknet-devnet --lite-mode -``` - -Steps skipped in lite mode: - -- **Calculating block hash**: Block hash is simplified and derived from the block number instead of computing the full cryptographic hash -- **Calculating block commitments**: Skips computation of transaction commitment, event commitment, state diff commitment, and receipt commitment - -In lite mode, blocks are still created and transactions are executed normally, but the computationally expensive cryptographic operations for generating block hashes and commitments are bypassed. This improves performance for development and testing scenarios where these values are not required. - -This is useful if your use-case doesn't need the functionalities above, such as when: - -- Testing transaction execution logic -- Running integration tests that don't verify block hashes or commitments -- Rapid prototyping and development iteration - -The extent of what is affected by lite mode may be expanded in the future. diff --git a/website/versioned_docs/version-0.8.0-rc.3/metrics.md b/website/versioned_docs/version-0.8.0-rc.3/metrics.md deleted file mode 100644 index 4c03cf6bc..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/metrics.md +++ /dev/null @@ -1,197 +0,0 @@ -# Metrics - -Starknet Devnet can expose Prometheus-compatible metrics for monitoring and observability. This feature allows you to track RPC calls, block creation, transactions, and upstream forking calls. - -## Enabling Metrics - -To enable metrics, start Devnet with the `--metrics-host` parameter: - -```bash -$ starknet-devnet --metrics-host -``` - -By default, the metrics server will listen on port `9090`. You can customize the port with the `--metrics-port` parameter: - -```bash -$ starknet-devnet --metrics-host 127.0.0.1 --metrics-port 8080 -``` - -Or using environment variables: - -```bash -$ METRICS_HOST=127.0.0.1 METRICS_PORT=8080 starknet-devnet -``` - -If running with Docker: - -```bash -$ docker run -e METRICS_HOST=0.0.0.0 -e METRICS_PORT=9090 -p 9090:9090 shardlabs/starknet-devnet-rs -``` - -## Accessing Metrics - -Once the metrics server is running, you can access the metrics endpoint at: - -``` -http://:/metrics -``` - -For example: - -```bash -$ curl http://127.0.0.1:9090/metrics -``` - -The metrics are exposed in Prometheus text format, which can be scraped by Prometheus or other compatible monitoring systems. - -## Available Metrics - -### RPC Metrics - -#### `rpc_call_duration_seconds` - -**Type:** Histogram - -**Description:** Duration of RPC calls in seconds - -**Labels:** - -- `method`: The RPC method name (e.g., `starknet_getBlockWithTxs`, `starknet_call`) - -**Buckets:** 0.00005, 0.0001, 0.00025, 0.0005, 0.001, 0.0025, 0.005, 0.01, 0.015, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0 seconds - -#### `rpc_call_count` - -**Type:** Counter - -**Description:** Total number of RPC calls - -**Labels:** - -- `method`: The RPC method name -- `status`: Either `success` or `error` - -### Starknet Core Metrics - -#### `starknet_transaction_count` - -**Type:** Counter - -**Description:** Total number of transactions in Starknet - -This counter is incremented when a transaction is added to the network and decremented when blocks are aborted. - -#### `starknet_block_count` - -**Type:** Counter - -**Description:** Total number of blocks in Starknet - -This counter is incremented when a new block is created and decremented when blocks are aborted. - -#### `starknet_block_creation_duration_seconds` - -**Type:** Histogram - -**Description:** Duration of block creation in seconds - -**Buckets:** 0.00005, 0.0001, 0.00025, 0.0005, 0.001, 0.0025, 0.005, 0.01 seconds - -This metric tracks how long it takes to generate a new block and transition from the pre-confirmed state. - -### Upstream Forking Metrics - -These metrics are only relevant when running Devnet in [forking mode](./forking.md). - -#### `starknet_upstream_call_duration_seconds` - -**Type:** Histogram - -**Description:** Duration of upstream forking origin calls in seconds - -**Labels:** - -- `method`: The RPC method called on the upstream network -- `status`: Either `success` or `error` - -**Buckets:** 0.001, 0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0 seconds - -#### `starknet_upstream_call_count` - -**Type:** Counter - -**Description:** Total number of upstream forking origin calls - -**Labels:** - -- `method`: The RPC method called on the upstream network -- `status`: Either `success` or `error` - -These metrics help monitor the performance and reliability of interactions with the forked network. - -## Integrating with Prometheus - -To scrape these metrics with Prometheus, add the following job to your `prometheus.yml` configuration: - -```yaml -scrape_configs: - - job_name: 'starknet-devnet' - static_configs: - - targets: ['localhost:9090'] -``` - -Adjust the target address to match your Devnet metrics server configuration. - -## Example Queries - -Here are some example PromQL queries you can use: - -### Average RPC call duration by method - -```promql -rate(rpc_call_duration_seconds_sum[5m]) / rate(rpc_call_duration_seconds_count[5m]) -``` - -### RPC call rate by method - -```promql -rate(rpc_call_count[5m]) -``` - -### RPC error rate - -```promql -rate(rpc_call_count{status="error"}[5m]) / rate(rpc_call_count[5m]) -``` - -### Block creation rate - -```promql -rate(starknet_block_count[5m]) -``` - -### Transaction throughput - -```promql -rate(starknet_transaction_count[5m]) -``` - -### Upstream call error rate (forking mode) - -```promql -rate(starknet_upstream_call_count{status="error"}[5m]) / rate(starknet_upstream_call_count[5m]) -``` - -### 95th percentile block creation time - -```promql -histogram_quantile(0.95, rate(starknet_block_creation_duration_seconds_bucket[5m])) -``` - -## Visualization with Grafana - -You can visualize these metrics using Grafana by: - -1. Adding Prometheus as a data source -2. Creating dashboards with panels using the PromQL queries above -3. Setting up alerts based on metric thresholds diff --git a/website/versioned_docs/version-0.8.0-rc.3/postman.md b/website/versioned_docs/version-0.8.0-rc.3/postman.md deleted file mode 100644 index 88e49f7de..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/postman.md +++ /dev/null @@ -1,193 +0,0 @@ -# L1-L2 interaction via Postman - -Postman is a Starknet utility that allows testing L1-L2 interaction. It is **unrelated** to the [Postman API platform](https://www.postman.com/). To use it, ensure you have: - -- an L1 node (possibilities listed [below](#l1-network)) -- a Devnet instance (acting as L2 node) -- a [loaded](#load) messaging contract - - this is an L1 contract for exchanging messages between L1 and L2 - - you can deploy a new instance or specify the address of an old one -- an L1 contract that can interact with the messaging contract -- an L2 contract that can interact with the messaging contract - -There are two internal message queues: one for L1->L2 messages, another for L2->L1 messages. When there are messages in a queue, you will need to [flush](#flush) to transmit the messages to their destinations. - -You can use [**`starknet-devnet-js`**](https://github.com/0xSpaceShard/starknet-devnet-js) to assist you in the above listed actions. [**This example**](https://github.com/0xSpaceShard/starknet-devnet-js/blob/master/test/l1-l2-postman.test.ts), especially the `it("should exchange messages between L1 and L2")` test case should be of most help. The required contracts are configured and deployed in the `before` block. Alternatively, you can directly send requests to the endpoints specified below. - -## Load - -```json -// JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanLoad", - "params": { - "network_url": "http://localhost:8545", - "messaging_contract_address": "0x123...def", // optional - "deployer_account_private_key": "0xe2ac...583f" // optional - } -} -``` - -Loads an L1 `MockStarknetMessaging` contract instance, potentially deploying a new one, which is used for message exchange between L1 and L2. - -### L1 network - -The `network_url` parameter refers to the URL of the JSON-RPC API endpoint of the L1 node you've run locally, or which is publicly accessible. Possibilities include, but are not limited to: - -- [**Anvil**](https://github.com/foundry-rs/foundry/tree/master#anvil) -- [**Sepolia testnet**](https://sepolia.etherscan.io/) -- [**Ganache**](https://www.npmjs.com/package/ganache) -- [**Geth**](https://github.com/ethereum/go-ethereum#docker-quick-start) -- [**Hardhat node**](https://hardhat.org/hardhat-network/#running-stand-alone-in-order-to-support-wallets-and-other-software) - -### Messaging contract deployment - -Here's how the rest of the parameters should be used, depending on your L1 network: - -- If your L1 network already has a messaging contract deployed that you wish to use, populate `messaging_contract_address` with its address. - - The provided address shall be checked by asserting that there indeed is contract code deployed at that address, without any ABI assertions. -- If your L1 network does not have such a contract, or you simplify wish to deploy a new instance, leave out the `messaging_contract_address` property. - - If your L1 network is a local testnet (e.g. Anvil) with the default mnemonic seed and a default set of predeployed accounts, you don't have to specify anything else—a new messaging contract shall be deployed using a predeployed account. - - Otherwise (e.g. on the Sepolia testnet or an Anvil with a custom mnemonic seed) you are expected to populate `deployer_account_private_key` with the private key of a funded account. This property is not applicable if `messaging_contract_address` is specified. - -:::note L1-L2 with dockerized Devnet - -L1-L2 communication requires extra attention if Devnet is [run in a Docker container](./running/docker.md). The `network_url` argument must be on the same network as Devnet. E.g. if your L1 instance is run locally (i.e. using the host machine's network), then: - -- on Linux, it is enough to run the Devnet Docker container with `--network host` -- on Mac and Windows, replace any `http://localhost` or `http://127.0.0.1` occurrence in the value of `network_url` with `http://host.docker.internal`. - -::: - -:::info Dumping and Loading - -Loading a messaging contract is a dumpable event, meaning that, if you've enabled dumping, a messaging-contract-loading event will be dumped. Keep in mind that, if you rely on Devnet deploying a new contract, i.e. if you don't specify a contract address of an already deployed messaging contract, a new contract will be deployed at a new address on each loading of the dump. Read more about dumping [here](./dump-load-restart#dumping). - -::: - -## Flush - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanFlush" -} -``` - -Goes through the newly enqueued messages since the last flush, consuming and sending them from L1 to L2 and from L2 to L1. Use it for end-to-end testing. Requires no body. Optionally, set the `dry_run` boolean flag to just see the result of flushing, without actually triggering it: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanFlush", - "params": { "dry_run": true } -} -``` - -:::note - -A running L1 node is required if `dry_run` is not set. - -::: - -:::info Dumping and Loading - -Flushing is not dumpable, meaning that, if you've enabled dumping, a flushing event will not itself be re-executed on loading. This is because it produces L2 messaging events that are themselves dumped. No L1-side actions are dumped, you need to take care of those yourself. Read more about dumping [here](./dump-load-restart#dumping). - -::: - -## Disclaimer - -This method of L1-L2 communication testing differs from how Starknet mainnet and testnets work. Taking [**L1L2Example.sol**](https://github.com/MikeSpa/starknet-test/blob/6a68d033cd7ddb5df937154f860f1c06174e6860/L1L2Example.sol#L46) (originally from Starknet documentation, no longer available there): - -```solidity -constructor(IStarknetCore starknetCore_) public { - starknetCore = starknetCore_; -} -``` - -The constructor takes an `IStarknetCore` contract as argument, however for Devnet's L1-L2 communication testing, this has to be replaced with the logic in [**MockStarknetMessaging.sol**](https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/starknet/testing/MockStarknetMessaging.sol): - -```solidity -constructor(MockStarknetMessaging mockStarknetMessaging_) public { - starknetCore = mockStarknetMessaging_; -} -``` - -## Mock transactions - -### L1->L2 - -:::note - -A running L1 node is **not** required for this operation. - -The L2 target entrypoint must be an `l1_handler`. - -::: - -Sends a mock transactions to L2, as if coming from L1, without the need for running L1. The target L2 contract's address must be provided to `l2_contract_address` and the `entry_point_selector` must refer to a public method of the target contract. The method must be annotated with `l1_handler`, otherwise an `ENTRYPOINT_NOT_FOUND` error may be returned. The `l1_transaction_hash` property is optional and, if provided, enables future `starknet_getMessagesStatus` requests with that hash value provided. - -In regular (non-mocking) L1-L2 interaction, `nonce` is determined by the L1 Starknet contract. In this mock case, it is up to the developer to set it. - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanSendMessageToL2", - "params": { - "l2_contract_address": "0x00285ddb7e5c777b310d806b9b2a0f7c7ba0a41f12b420219209d97a3b7f25b2", - "entry_point_selector": "0xC73F681176FC7B3F9693986FD7B14581E8D540519E27400E88B8713932BE01", - "l1_contract_address": "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512", - "payload": [ "0x1", "0x2" ], - "paid_fee_on_l1": "0x123456abcdef", - "nonce": "0x0", - "l1_transaction_hash": "0x000abc123", // optional - } -} -``` - -Result: - -```js -{ "transaction_hash": "0x0548c761a9fd5512782998b2da6f44c42bf78fb88c3794eea330a91c9abb10bb" } -``` - -### L2->L1 - -Sends a mock transaction from L2 to L1. The deployed L2 contract address `from_address` and `to_address` must be valid. - -It is a mock message, but only in the sense that you are mocking an L2 contract's action, which would normally be triggered by invoking the contract via a transaction. So keep in mind the following: - -:::note - -A running L1 node is required for this operation. - -::: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_postmanConsumeMessageFromL2", - "params": { - "from_address": "0x00285ddb7e5c777b310d806b9b2a0f7c7ba0a41f12b420219209d97a3b7f25b2", - "to_address": "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512", - "payload": ["0x0", "0x1", "0x3e8"], - } -} -``` - -Result: - -```js -{"message_hash": "0xae14f241131b524ac8d043d9cb4934253ac5c5589afef19f0d761816a9c7e26d"} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.3/predeployed.md b/website/versioned_docs/version-0.8.0-rc.3/predeployed.md deleted file mode 100644 index 7b502999c..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/predeployed.md +++ /dev/null @@ -1,87 +0,0 @@ -# Predeployed contracts - -Devnet predeploys: - -- two [UDCs](https://docs.openzeppelin.com/contracts-cairo/udc) - - on the same addresses as Starknet mainnet/testnet - - a legacy instance serving only the `deployContract` entrypoint - - a UDC 2 instance serving both `deployContract` and `deploy_contract` entrypoints -- two [ERC20 (fee token)](https://docs.openzeppelin.com/contracts-cairo/erc20) contracts - - on the same addresses as Starknet mainnet/testnet - - one for STRK - - one for ETH -- a set of predeployed funded accounts - - not a feature of Starknet mainnet/testnet. - -The set of accounts can be controlled via [CLI options](./running/cli): `--accounts `, `--initial-balance `, `--seed `. - -## Predeployed account preservation - -:::note - -Once you shut down your Devnet, the predeployed account you used ceases to exist. This may be a problem with tools such as `starkli` which hardcode your account details in a local file. One option then is to delete your account entry from `starkli`'s account file. Another option is to spawn the same account on next Devnet startup. To do this, you can use: - -- the `--seed ` CLI option which always predeploys the same set of accounts if using the same `` (the seed is logged on startup) -- the [dump and load feature](./dump-load-restart) - -::: - -## Account class selection - -Choose between predeploying Cairo 0 (OpenZeppelin 0.5.1) or Cairo 1 (default; OpenZeppelin 1.0.0) accounts by using: - -``` ---account-class [cairo0 | cairo1] -``` - -Alternatively, provide a path to the [Sierra artifact](https://github.com/starkware-libs/cairo#compiling-and-running-cairo-files) of your custom account using: - -``` ---account-class-custom -``` - -## Predeclared account classes - -Both Cairo 0 and Cairo 1 versions of OpenZeppelin account are always predeclared, regardless of the chosen predeployment variant. If you specify `--predeclare-argent` on startup, the latest regular and multisig Argent account variants will also be predeclared. All predeclared classes can be used in DEPLOY_ACCOUNT transactions. - -## Deploying an undeclared account - -If you want to deploy an instance of an account contract class not predeclared on Devnet, you can use [forking](./forking). Just fork an origin network which has the needed class already declared, e.g. the Sepolia testnet. Why? Because new versions of wallets like ArgentX and Braavos tend to be declared on testnet/mainnet soon after release. - -## How to get predeployment info? - -### Logged on startup - -The startup log includes: - -- the hash values of predeclared classes -- the addresses of predeployed contracts -- the keys and initial balance of predeployed account contracts - -### API - -Account class info can be found in the response to [config request](api#config-api). - -Predeployed account details can be retrieved in JSON format by sending a `JSON-RPC` request. With the additional query parameter `with_balance` set to `true`, ETH and STRK balances at the pre-confirmed state will be provided, in WEI and FRI, respectively: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_getPredeployedAccounts" -} -``` - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_getPredeployedAccounts", - "params": { - // optional; defaults to false - "with_balance": true | false - } -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.3/proofs.md b/website/versioned_docs/version-0.8.0-rc.3/proofs.md deleted file mode 100644 index 686d7eb67..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/proofs.md +++ /dev/null @@ -1,153 +0,0 @@ -# Transaction proofs and proof modes - -This page describes the Devnet-specific transaction proof flow introduced in Starknet v0.14.2 and the `--proof-mode` configuration. - -## Important distinction: storage proofs vs transaction proofs - -- `starknet_getStorageProof` is still not supported in Devnet. -- `starknet_proveTransaction` is a separate Devnet extension for proving/validating `INVOKE v3` transaction payloads in a Devnet-oriented way. -- If you are looking for Merkle-Patricia storage proofs, this page is **not** about that feature. - -## Proof modes - -Proof behavior is controlled by `--proof-mode` (or env var `PROOF_MODE`). - -### Mode summary - -| Mode | CLI value | What `starknet_proveTransaction` does | How `starknet_addInvokeTransaction` treats `proof` and `proof_facts` | -| ------ | ------------------ | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | -| Full | `full` | Not implemented yet | Rejects with unsupported action | -| Devnet | `devnet` (default) | Returns a deterministic mock proof + proof facts | If both fields are present, verifies them; if one is missing or verification fails, rejects; if both are absent, accepts | -| None | `none` | Disabled / unsupported | Ignores incoming `proof` for invoke txs | - -### Why this exists - -`devnet` mode is a practical mode for local testing: - -- You can request a proof for a specific `INVOKE v3` payload. -- You can later attach that proof to a transaction and exercise proof-aware flows. -- Verification is deterministic and lightweight, intended for development workflows rather than real on-chain proving. - -## Configuration - -### CLI - -```bash -starknet-devnet --proof-mode devnet -``` - -```bash -starknet-devnet --proof-mode none -``` - -```bash -starknet-devnet --proof-mode full -``` - -### Environment variable - -```bash -PROOF_MODE=devnet starknet-devnet -``` - -### Docker - -```bash -docker run --rm -p 5050:5050 \ - -e PROOF_MODE=devnet \ - shardlabs/starknet-devnet-rs -``` - -## RPC: `starknet_proveTransaction` - -### Request shape - -`starknet_proveTransaction` accepts: - -- `block_id` -- `transaction` (a broadcasted `INVOKE v3` transaction payload) - -Example: - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "method": "starknet_proveTransaction", - "params": { - "block_id": "latest", - "transaction": { - "type": "INVOKE", - "version": "0x3", - "sender_address": "0x1234", - "calldata": ["0x1", "0x2"], - "signature": [], - "nonce": "0x0", - "resource_bounds": { - "l1_gas": { "max_amount": "0x0", "max_price_per_unit": "0x0" }, - "l1_data_gas": { "max_amount": "0x0", "max_price_per_unit": "0x0" }, - "l2_gas": { "max_amount": "0x0", "max_price_per_unit": "0x0" } - }, - "tip": "0x0", - "paymaster_data": [], - "account_deployment_data": [], - "nonce_data_availability_mode": "L1", - "fee_data_availability_mode": "L1" - } - } -} -``` - -### Response shape - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": { - "proof": "", - "proof_facts": [ - "0x...", - "0x...", - "0x...", - "0x...", - "0x...", - "0x...", - "0x...", - "0x..." - ], - "l2_to_l1_messages": [ - { - "order": 0, - "from_address": "0x...", - "to_address": "0x...", - "payload": ["0x...", "0x..."] - } - ] - } -} -``` - -`proof_facts` length is expected to be 8 in devnet mode. - -`l2_to_l1_messages` contains L2→L1 messages extracted by simulating the transaction. If the simulation fails (e.g. insufficient balance), this array will be empty and the proof is still returned. - -## Mode-specific behavior details - -### `devnet` mode (default) - -- `starknet_proveTransaction` is enabled. -- Invoke handling rules: - - both `proof` + `proof_facts` present and valid → accepted - - both present but invalid → rejected - - only one present → rejected - - both absent → accepted - -### `none` mode - -- Proof field on invoke transactions is ignored; `proof_facts` are checked. - -### `full` mode - -- Full proving/verification is not implemented yet. -- Endpoints and transactions requiring full verification return unsupported-action errors. diff --git a/website/versioned_docs/version-0.8.0-rc.3/restrictive.md b/website/versioned_docs/version-0.8.0-rc.3/restrictive.md deleted file mode 100644 index 595f2ffb7..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/restrictive.md +++ /dev/null @@ -1,36 +0,0 @@ -# Restrictive mode - -The `--restrictive-mode` argument enables a restrictive mode for Devnet, allowing you to specify methods that are forbidden during execution. This option ensures that certain operations are restricted, enhancing control over Devnet's behavior. When a user sends a request to one of the restricted methods, Devnet will return either a JSON-RPC error with code -32604 or, if the method was targeted directly via the HTTP endpoint, a response with status 403. - -## Default restricted methods - -When no methods are specified, the following default methods will be restricted, together with their HTTP endpoint counterparts (if any): - -- devnet_mint -- devnet_load -- devnet_restart -- devnet_createBlock -- devnet_abortBlocks -- devnet_impersonateAccount -- devnet_autoImpersonate -- devnet_getPredeployedAccounts - -## Usage - -### With default methods - -``` -$ starknet-devnet --restrictive-mode -``` - -### With a list of methods - -:::note - -Devnet will fail to start if any of the methods/routes are misspelled. - -::: - -``` -$ starknet-devnet --restrictive-mode devnet_dump devnet_config -``` diff --git a/website/versioned_docs/version-0.8.0-rc.3/running/_category_.json b/website/versioned_docs/version-0.8.0-rc.3/running/_category_.json deleted file mode 100644 index 17c529a24..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/running/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Running", - "position": 2, - "link": { - "type": "generated-index" - } -} diff --git a/website/versioned_docs/version-0.8.0-rc.3/running/cli.md b/website/versioned_docs/version-0.8.0-rc.3/running/cli.md deleted file mode 100644 index f34634578..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/running/cli.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -sidebar_position: 2.3 ---- - -# CLI options - -Configure your Devnet instance by specifying CLI parameters on startup. To read more about HTTP and logging configuration, check out the [server config](../server-config) page. - -## Help - -Check out all the options with: - -``` -$ starknet-devnet --help -``` - -Or if using dockerized Devnet: - -``` -$ docker run --rm shardlabs/starknet-devnet-rs --help -``` - -## Environment variables - -Every CLI option can also be specified via an environment variable: - -``` -$ = = starknet-devnet -``` - -To see the exact variable names, use [`--help`](#help). - -### Precedence - -If both a CLI argument and an environment variable are passed for a parameter, the CLI argument takes precedence. If none are provided, the default value is used. E.g. if running Devnet with the following command, seed value 42 will be used: - -``` -$ SEED=10 starknet-devnet --seed 42 -``` - -### Docker - -If using dockerized Devnet, specify the variables like this: - -``` -$ docker run \ - -e = \ - -e = \ - ... \ - shardlabs/starknet-devnet-rs -``` - -## Load configuration from a file - -If providing many configuration parameters in a single command becomes cumbersome, consider loading them from a file. By relying on [environment variables](#environment-variables), prepare your configuration in a file like this: - -```bash -export SEED=42 -export ACCOUNTS=3 -... -``` - -Assuming the file is called `.my-env-file`, then run: - -```bash -$ source .my-env-file && starknet-devnet -``` - -To run in a subshell and prevent environment pollution (i.e. to unset the variables after Devnet exits), use parentheses: - -```bash -$ ( source .my-env-file && starknet-devnet ) -``` - -### Docker - -To load environment variables from `.my-env-file` with Docker, remove the `export` part in each line to have the file look like this: - -``` -SEED=42 -ACCOUNTS=3 -... -``` - -Then run: - -``` -$ docker run --env-file .my-env-file shardlabs/starknet-devnet-rs -``` - -## Proof-related configuration - -Devnet exposes a dedicated proof-mode switch: - -```bash -starknet-devnet --proof-mode -``` - -Equivalent environment variable: - -```bash -PROOF_MODE= -``` - -Mode behavior summary: - -- `devnet` (default): mock proof generation + verification flow is enabled. -- `none`: proof fields are ignored on invoke transactions. -- `full`: reserved for fully verified proofs (currently not implemented). - -For complete examples and RPC payloads, see [Transaction proofs and proof modes](../proofs). diff --git a/website/versioned_docs/version-0.8.0-rc.3/running/docker.md b/website/versioned_docs/version-0.8.0-rc.3/running/docker.md deleted file mode 100644 index e4f011670..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/running/docker.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -sidebar_position: 2.2 ---- - -# Run with Docker - -Devnet is available as a Docker image ([Docker Hub link](https://hub.docker.com/r/shardlabs/starknet-devnet-rs/)). To download the `latest` image, run: - -```text -$ docker pull shardlabs/starknet-devnet-rs -``` - -Supported platforms: linux/amd64 and linux/arm64 (also executable on darwin/arm64). - -Running a container is done like this (see [port publishing](#container-port-publishing) for more info): - -```text -$ docker run -p [HOST:]:5050 shardlabs/starknet-devnet-rs [OPTIONS] -``` - -## Docker image tags - -All of the versions published on crates.io for starknet-devnet are available as docker images, which can be used via: - -``` -$ docker pull shardlabs/starknet-devnet-rs: -``` - -:::note - -The `latest` docker image tag corresponds to the last published version on crates.io. - -::: - -### Accessing Devnet fixes before release - -Commits to the `main` branch of this repository are mostly available as images tagged with their commit hash (the full 40-lowercase-hex-digits SHA1 digest): - -``` -$ docker pull shardlabs/starknet-devnet-rs: -``` - -If a fix has been merged into the `main` branch of Devnet's code repository, you can access it before its inclusion in an official release. Just inspect the [`main` commit list](https://github.com/0xSpaceShard/starknet-devnet/commits/main) and copy the full SHA digest of the commit containing the fix (or preferably the latest commit) which has a green check ✔️ symbol next to the commit date (which indicates the image indeed exists). Some revisions may not have a corresponding Docker image, but these are not supposed to be bugfixes. - -### Zero-seeded set of accounts - -By appending the `-seed0` suffix, you can use images which [predeploy funded accounts](../predeployed) with `--seed 0`, thus always predeploying the same set of accounts: - -``` -$ docker pull shardlabs/starknet-devnet-rs:-seed0 -$ docker pull shardlabs/starknet-devnet-rs:latest-seed0 -``` - -## Container port publishing - -### Linux - -If on a Linux host machine, you can use [`--network host`](https://docs.docker.com/network/host/). This way, the port used internally by the container is also available on your host machine. The `--port` option can be used (as well as other CLI options). - -```text -$ docker run --network host shardlabs/starknet-devnet-rs [--port ] -``` - -### Mac and Windows - -If not on Linux, you need to publish the container's internally used port to a desired `` on your host machine. The internal port is `5050` by default (probably not your concern, but can be overridden with `--port`). - -```text -$ docker run -p [HOST:]:5050 shardlabs/starknet-devnet-rs -``` - -E.g. if you want to use your host machine's `127.0.0.1:5050`, you need to run: - -```text -$ docker run -p 127.0.0.1:5050:5050 shardlabs/starknet-devnet-rs -``` - -You may ignore any address-related output logged on container startup (e.g. `Starknet Devnet listening on 0.0.0.0:5050`). What you will use is what you specified with the `-p` argument. - -If you don't specify the `HOST` part, the server will indeed be available on all of your host machine's addresses (localhost, local network IP, etc.), which may present a security issue if you don't want anyone from the local network to access your Devnet instance. - -## Development note - -Due to internal needs, images with arch suffix are built and pushed to Docker Hub, but this is not mentioned in the user docs as users should NOT be needing it. - -This is what happens under the hood on `main`: - -- build `shardlabs/starknet-devnet-rs--amd` -- build `shardlabs/starknet-devnet-rs--arm` -- create and push joint docker manifest called `shardlabs/starknet-devnet-rs-` - - same for `latest` diff --git a/website/versioned_docs/version-0.8.0-rc.3/running/install.md b/website/versioned_docs/version-0.8.0-rc.3/running/install.md deleted file mode 100644 index 3aa379e26..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/running/install.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -sidebar_position: 2.1 ---- - -# Install and run - -## Requirements - -Any of the approaches below that mention `cargo` require you to have [installed Rust](https://www.rust-lang.org/tools/install). You might also need to install `pkg-config` and `make`. - -The required Rust version is specified in `rust-toolchain.toml` in the project root and handled automatically by `cargo`. - -## Install an executable binary - -Installing an executable binary is achievable with `cargo install` via [crates.io](https://crates.io/) or [github.com](https://github.com). This approach downloads the crate, builds it in release mode and copies it to `~/.cargo/bin/`. To avoid needing to compile and wait, check the [pre-compiled binary section](#fetch-a-pre-compiled-binary-executable). - -### Remove Pythonic Devnet - -If in the past you installed [Pythonic Devnet](https://github.com/0xSpaceShard/starknet-devnet), be sure to remove it to avoid name collision of the old and the new executable - if by no other means, then by `rm $(which starknet-devnet)`. - -### Install from crates.io - -``` -$ cargo install starknet-devnet -``` - -### Install from GitHub - -- Use the `--locked` flag to ensure using the dependencies listed in `Cargo.lock` in the project root. -- Preferably familiarize yourself with the `cargo install` command ([docs](https://doc.rust-lang.org/cargo/commands/cargo-install.html#dealing-with-the-lockfile)). - -``` -$ cargo install --git https://github.com/0xSpaceShard/starknet-devnet.git --locked -``` - -### Install with `asdf` - -- Run the following to add the `starknet-devnet` plugin - -``` -$ asdf plugin add starknet-devnet -``` - -- Show all installable versions: - -``` -$ asdf list-all starknet-devnet -``` - -- Install latest version: - -``` -$ asdf install starknet-devnet latest -``` - -- Install specific version: - -``` -$ asdf install starknet-devnet 0.2.0 -``` - -Check [asdf guide](https://asdf-vm.com/guide/getting-started.html) for more instructions on how to install & manage versions. - -### Install with starkup - -[Starkup](https://github.com/software-mansion/starkup) is a tool for installing and managing Starknet-related tools, including starknet-devnet. To run starkup itself: - -``` -$ curl --proto '=https' --tlsv1.2 -sSf https://sh.starkup.sh | sh -``` - -Starkup uses `asdf` underneath to manage tool versions. After installation, you can use standard ASDF commands to manage starknet-devnet. - -Make sure to restart your terminal or source your shell configuration file after installation to have starknet-devnet available in your PATH. - -### Run the installed executable - -When `cargo install` or another installation method finishes, follow the output in your terminal. If properly configured, you should be able to run Devnet with: - -``` -$ starknet-devnet -``` - -## Fetch a pre-compiled binary executable - -If you want to save time and skip project compilation on installation, since Devnet v0.0.5, the Assets section of each [GitHub release](https://github.com/0xSpaceShard/starknet-devnet/releases) contains a set of platform-specific pre-compiled binary executables. Extract and run with: - -``` -$ curl -sSfL https://github.com/0xSpaceShard/starknet-devnet/releases/download// | tar -xvz -C -$ /starknet-devnet -``` - -## Run from source - -To install the project from source, after [git-cloning](https://github.com/git-guides/git-clone) the [Devnet repository](https://github.com/0xSpaceShard/starknet-devnet), running the following command will install, build and start Devnet: - -``` -$ cargo run -``` - -Specify optional CLI params like this: - -``` -$ cargo run -- [ARGS] -``` - -For a more optimized performance (though with a longer compilation time), run: - -``` -$ cargo run --release -``` diff --git a/website/versioned_docs/version-0.8.0-rc.3/server-config.md b/website/versioned_docs/version-0.8.0-rc.3/server-config.md deleted file mode 100644 index e9e5b5c33..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/server-config.md +++ /dev/null @@ -1,77 +0,0 @@ -# Server config - -To read generally about ways to configure your Devnet instance, check out the [CLI section](./running/cli.md). - -## Host and port - -Specify the host and the port used by the server with `--host
` and `--port ` CLI arguments. If running with Docker, check out the [port publishing docs](./running/docker#container-port-publishing). - -## Logging - -By default, the logging level is `INFO`, but this can be changed via the `RUST_LOG` environment variable. - -All logging levels: `TRACE`, `DEBUG`, `INFO`, `WARN`, `ERROR` - -To specify the logging level and run Devnet on the same line: - -``` -$ RUST_LOG= starknet-devnet -``` - -or if using dockerized Devnet: - -``` -$ docker run -e RUST_LOG= shardlabs/starknet-devnet-rs -``` - -By default, logging of request and response data is turned off. -To see the request and/or response body, additional levels can be specified via the `RUST_LOG` environment variable: `REQUEST` for request body, `RESPONSE` for response body. - -:::note - -Logging request and response requires at least logging level `INFO`. - -For example, the following two commands will log request and response data with log level `INFO`. - -``` -$ RUST_LOG="REQUEST,RESPONSE" starknet-devnet -``` - -``` -$ RUST_LOG="REQUEST,RESPONSE,INFO" starknet-devnet -``` - -::: - -## Timeout - -Specify the maximum amount of time an HTTP request can be served. This makes it possible to deploy and manage large contracts that take longer to execute. - -``` -$ starknet-devnet --timeout -``` - -## Size limits - -There is no HTTP request size limit, but take care when declaring large classes! Devnet is supposed to follow the limits specified in [Starknet chain Info](https://docs.starknet.io/resources/chain-info/#current_limits). - -If, however, you need to customize the limits, you may rely on the following CLI parameters on Devnet startup: - -- `--maximum-contract-class-size ` -- `--maximum-contract-bytecode-size ` -- `--maximum-sierra-length ` - -The default upper limits configured in Devnet can be found [among constants](https://github.com/0xSpaceShard/starknet-devnet/blob/main/crates/starknet-devnet-core/src/constants.rs#L121). - -## API - -Retrieve the server config by sending a `JSON-RPC` request with method name `devnet_getConfig` and extracting its `server_config` property. - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_getConfig" -} -``` diff --git a/website/versioned_docs/version-0.8.0-rc.3/starknet-time.md b/website/versioned_docs/version-0.8.0-rc.3/starknet-time.md deleted file mode 100644 index 341e6d70a..000000000 --- a/website/versioned_docs/version-0.8.0-rc.3/starknet-time.md +++ /dev/null @@ -1,70 +0,0 @@ -# Starknet time - -Block and state timestamp can be manipulated by setting the exact time or setting the time offset. By default, timestamp methods `devnet_setTime` and `devnet_increaseTime` of JSON-RPC API generate a new block. This can be changed for `devnet_setTime` by setting the optional parameter `generate_block` to `false`. This skips immediate new block generation, but will use the specified timestamp whenever the next block is supposed to be generated. - -All values should be set in [Unix time seconds](https://en.wikipedia.org/wiki/Unix_time). After [startup](#start-time), the time progresses naturally. - -## Set time - -The following sets the exact time and generates a new block: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_setTime", - "params": { - "time": TIME_IN_SECONDS - } -} -``` - -The following doesn't generate a new block, but sets the exact time for the next generated block: - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_setTime", - "params": { - "time": TIME_IN_SECONDS, - "generate_block": false - } -} -``` - -Warning: block time can be set in the past which might lead to unexpected behavior! - -## Increase time - -Increases the block timestamp by the provided amount and generates a new block. All subsequent blocks will keep this increment. - -``` -JSON-RPC -{ - "jsonrpc": "2.0", - "id": "1", - "method": "devnet_increaseTime", - "params": { - "time": TIME_IN_SECONDS - } -} -``` - -:::note Increment example - -Imagine a block is generated with timestamp `T1`, some time passes (let's call this interval `T_passed`), and you call increase_time with `T_inc` as the argument, which immediately mines a new block at `T2`. `T2` should equal `T1 + T_passed + T_inc`. - -::: - -## Start time - -Devnet's starting timestamp can be defined via CLI by providing a positive value of [Unix time seconds](https://en.wikipedia.org/wiki/Unix_time) to `--start-time`: - -``` -$ starknet-devnet --start-time -``` - -If provided, this timestamp shall be used in mining the genesis block. The default value is the current Unix time. diff --git a/website/versioned_docs/version-0.8.0-rc.0/account-impersonation.md b/website/versioned_docs/version-0.8.0/account-impersonation.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/account-impersonation.md rename to website/versioned_docs/version-0.8.0/account-impersonation.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/api.md b/website/versioned_docs/version-0.8.0/api.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/api.md rename to website/versioned_docs/version-0.8.0/api.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/balance.md b/website/versioned_docs/version-0.8.0/balance.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/balance.md rename to website/versioned_docs/version-0.8.0/balance.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/blocks.md b/website/versioned_docs/version-0.8.0/blocks.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/blocks.md rename to website/versioned_docs/version-0.8.0/blocks.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/dump-load-restart.md b/website/versioned_docs/version-0.8.0/dump-load-restart.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/dump-load-restart.md rename to website/versioned_docs/version-0.8.0/dump-load-restart.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/examples.md b/website/versioned_docs/version-0.8.0/examples.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/examples.md rename to website/versioned_docs/version-0.8.0/examples.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/forking.md b/website/versioned_docs/version-0.8.0/forking.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/forking.md rename to website/versioned_docs/version-0.8.0/forking.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/gas.md b/website/versioned_docs/version-0.8.0/gas.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/gas.md rename to website/versioned_docs/version-0.8.0/gas.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/historic-state.md b/website/versioned_docs/version-0.8.0/historic-state.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/historic-state.md rename to website/versioned_docs/version-0.8.0/historic-state.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/intro.md b/website/versioned_docs/version-0.8.0/intro.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/intro.md rename to website/versioned_docs/version-0.8.0/intro.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/lite.md b/website/versioned_docs/version-0.8.0/lite.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/lite.md rename to website/versioned_docs/version-0.8.0/lite.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/metrics.md b/website/versioned_docs/version-0.8.0/metrics.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/metrics.md rename to website/versioned_docs/version-0.8.0/metrics.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/postman.md b/website/versioned_docs/version-0.8.0/postman.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/postman.md rename to website/versioned_docs/version-0.8.0/postman.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/predeployed.md b/website/versioned_docs/version-0.8.0/predeployed.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/predeployed.md rename to website/versioned_docs/version-0.8.0/predeployed.md diff --git a/website/versioned_docs/version-0.8.0-rc.2/proofs.md b/website/versioned_docs/version-0.8.0/proofs.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.2/proofs.md rename to website/versioned_docs/version-0.8.0/proofs.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/restrictive.md b/website/versioned_docs/version-0.8.0/restrictive.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/restrictive.md rename to website/versioned_docs/version-0.8.0/restrictive.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/running/_category_.json b/website/versioned_docs/version-0.8.0/running/_category_.json similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/running/_category_.json rename to website/versioned_docs/version-0.8.0/running/_category_.json diff --git a/website/versioned_docs/version-0.8.0-rc.0/running/cli.md b/website/versioned_docs/version-0.8.0/running/cli.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/running/cli.md rename to website/versioned_docs/version-0.8.0/running/cli.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/running/docker.md b/website/versioned_docs/version-0.8.0/running/docker.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/running/docker.md rename to website/versioned_docs/version-0.8.0/running/docker.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/running/install.md b/website/versioned_docs/version-0.8.0/running/install.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/running/install.md rename to website/versioned_docs/version-0.8.0/running/install.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/server-config.md b/website/versioned_docs/version-0.8.0/server-config.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/server-config.md rename to website/versioned_docs/version-0.8.0/server-config.md diff --git a/website/versioned_docs/version-0.8.0-rc.0/starknet-time.md b/website/versioned_docs/version-0.8.0/starknet-time.md similarity index 100% rename from website/versioned_docs/version-0.8.0-rc.0/starknet-time.md rename to website/versioned_docs/version-0.8.0/starknet-time.md diff --git a/website/versioned_sidebars/version-0.8.0-sidebars.json b/website/versioned_sidebars/version-0.8.0-sidebars.json new file mode 100644 index 000000000..145418b2d --- /dev/null +++ b/website/versioned_sidebars/version-0.8.0-sidebars.json @@ -0,0 +1,8 @@ +{ + "docSidebar": [ + { + "type": "autogenerated", + "dirName": "." + } + ] +} diff --git a/website/versions.json b/website/versions.json index 028509b63..22d8a332a 100644 --- a/website/versions.json +++ b/website/versions.json @@ -1,8 +1,5 @@ [ - "0.8.0-rc.3", - "0.8.0-rc.2", - "0.8.0-rc.1", - "0.8.0-rc.0", + "0.8.0", "0.7.2", "0.7.1", "0.7.0",