Release v0.0.7 (#490)

.github/CONTRIBUTING.md

@@ -165,20 +165,4 @@ The documentation website content has [its own readme](../website/README.md).
 
 ### New Devnet version release
 
-To release a new version, follow these steps:
-
-1. Increment the semver in Cargo.toml of those Devnet crates that have changed. Use `scripts/check_crate_changes.sh` for this.
-
-2. Add a documentation entry for the incoming version by running:
-
-   ```
-   npm run docusaurus docs:version <VERSION>
-   ```
-
-3. Create a PR styled after [this one](https://github.com/0xSpaceShard/starknet-devnet-rs/pull/473).
-
-4. The publishing of crates and Docker images is done automatically in CI when merged into the main branch.
-
-5. When the CI workflow is done, create a git tag of the form `vX.Y.Z`, push it and create a GitHub release with notes describing changes since the last release.
-
-6. Attach the [binary artifacts built in CI](https://circleci.com/docs/artifacts/#artifacts-overview) to the release. Use `scripts/fetch_ci_binaries.py` to fetch all artifacts of a CI workflow.
+To release a new version, check out the [release docs](../RELEASE.md).

Cargo.toml

@@ -92,9 +92,9 @@ cairo-lang-syntax = "=2.6.0"
 cairo-lang-utils = "=2.6.0"
 
 # Inner dependencies
-starknet-types = { version = "0.0.5", path = "crates/starknet-devnet-types", package = "starknet-devnet-types" }
-starknet-core = { version = "0.0.6", path = "crates/starknet-devnet-core", package = "starknet-devnet-core" }
-server = { version = "0.0.6", path = "crates/starknet-devnet-server", package = "starknet-devnet-server" }
+starknet-types = { version = "0.0.6", path = "crates/starknet-devnet-types", package = "starknet-devnet-types" }
+starknet-core = { version = "0.0.7", path = "crates/starknet-devnet-core", package = "starknet-devnet-core" }
+server = { version = "0.0.7", path = "crates/starknet-devnet-server", package = "starknet-devnet-server" }
 
 # Dependabot alerts
 zerocopy = "0.7.31"

RELEASE.md

@@ -0,0 +1,20 @@
+# Version release
+
+To release a new Devnet version, follow these steps:
+
+1. Increment the semver in Cargo.toml of those Devnet crates that have changed. Use `scripts/check_crate_changes.sh` for this.
+
+2. Add a documentation entry for the incoming version by running:
+
+   ```
+   $ cd website
+   $ npm run docusaurus docs:version <VERSION>
+   ```
+
+3. Create a PR styled after [this one](https://github.com/0xSpaceShard/starknet-devnet-rs/pull/473).
+
+4. The publishing of crates, Docker images and documentation website is done automatically in CI when the PR is merged into the main branch.
+
+5. When the CI workflow is done, create a git tag of the form `vX.Y.Z`, push it and create a GitHub release with notes describing changes since the last release.
+
+6. Attach the [binary artifacts built in CI](https://circleci.com/docs/artifacts/#artifacts-overview) to the release. Use `scripts/fetch_ci_binaries.py` to fetch all artifacts of a CI workflow.

crates/starknet-devnet-core/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "starknet-devnet-core"
-version = "0.0.6"
+version = "0.0.7"
 edition.workspace = true
 repository.workspace = true
 license-file.workspace = true

crates/starknet-devnet-server/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "starknet-devnet-server"
-version = "0.0.6"
+version = "0.0.7"
 edition = "2021"
 repository.workspace = true
 license-file.workspace = true

crates/starknet-devnet-types/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "starknet-devnet-types"
-version = "0.0.5"
+version = "0.0.6"
 edition = "2021"
 description = "Starknet types for the devnet"
 repository.workspace = true

crates/starknet-devnet/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "starknet-devnet"
-version = "0.0.6"
+version = "0.0.7"
 edition = "2021"
 repository.workspace = true
 license-file.workspace = true

scripts/check_crate_changes.sh

@@ -3,14 +3,14 @@
 set -eu
 
 if [ $# -ne 1 ]; then
-    echo "$0: <VERSION>"
+    >&2 echo "$0: <VERSION>"
     exit 1
 fi
 
 version="$1"
 
 echo "The crates that need a semver increment since git revision '$version' are:"
 
-git diff "$version" --stat | grep -o -E 'crates/[^/]*' | uniq
+git diff "$version" --name-status | grep -o -E 'crates/[^/]*' | uniq
 
 echo "Note that this does not reflect dependency changes in Cargo.toml or changes that one Devnet crate may have had on another!"

scripts/compile_binary.sh

@@ -5,7 +5,7 @@ set -euo pipefail
 CROSS_VERSION="v0.2.5"
 
 if [ $# != 1 ]; then
-    echo "Error: $0 <TARGET>"
+    >&2 echo "Error: $0 <TARGET>"
     exit 1
 fi
 TARGET="$1"
@@ -25,7 +25,7 @@ Linux*)
     compiler_command="/tmp/cross"
     ;;
 *)
-    echo "Unsupported kernel: $kernel_name"
+    >&2 echo "Unsupported kernel: $kernel_name"
     exit 1
     ;;
 esac

website/versioned_docs/version-0.0.7/account-impersonation.md

@@ -0,0 +1,81 @@
+# Account impersonation
+
+:::info
+
+This page is about account impersonation. To read about account class selection and deployment, click [here](./predeployed).
+
+:::
+
+Devnet allows you to use impersonated account from mainnet/testnet. This means that a transaction sent from an impersonated account will not fail with an invalid signature error. In the general case, a transaction sent with an account that is not in the local state fails with the aforementioned error. For impersonation to work, Devnet needs to be run in [forking mode](./forking.md).
+
+:::warning Caveat
+
+- Only `INVOKE` and `DECLARE` transactions are supported. `DEPLOY_ACCOUNT` transaction is not supported, but you can create an `INVOKE` transaction to UDC.
+- Overall fee, for transactions sent with an impersonated account, will be lower compared to normal transactions. The reason is that validation part is skipped.
+- The most common way of sending a transaction is via starknet-rs/starknet.js or starkli. Trying to send with an account that **does not** exist even in the origin network will return an error:
+  - In transaction construction, if account nonce is not hardcoded, Devnet is queried and returns `ContractNotFound`.
+  - Otherwise the nonce fetching part is skipped and `InsufficientAccountBalance` is returned.
+
+:::
+
+Users can disable account impersonation by starting Devnet with CLI flag `--disable-account-impersonation` or by setting environment variable `DISABLE_ACCOUNT_IMPERSONATION`. Every subsequent JSON-RPC impersonation request will return an error. This feature can be used in CTFs to prevent participants from easily solving the task.
+
+## 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": {}
+}
+```

website/versioned_docs/version-0.0.7/api.md

@@ -0,0 +1,45 @@
+# API
+
+## Starknet API
+
+Unlike Pythonic Devnet, which also supported Starknet's gateway and feeder gateway API, Devnet in Rust supports Starknet's JSON-RPC API. 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-rs/releases).
+
+The JSON-RPC API is reachable via `/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/`)
+
+## Devnet API
+
+Devnet has many other functional features which are available via their own endpoints, which are all mentioned throughout the documentation.
+
+## Config API
+
+To retrieve the current configuration of Devnet, send a `GET` request to `/config`. 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.
+
+```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_strk": 100000000000,
+  "data_gas_price_wei": 100000000000,
+  "data_gas_price_strk": 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,
+    "request_body_size_limit": 2000000
+  },
+  "blocks_on_demand": false,
+  "lite_mode": false
+}
+```

website/versioned_docs/version-0.0.7/balance.md

@@ -0,0 +1,41 @@
+# 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 `POST` request to `/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 `WEI`.
+
+The value of `amount` is in WEI and needs to be an integer (or a float whose fractional part is 0, e.g. `1000.0` or `1e21`)
+
+```
+POST /mint
+{
+    "address": "0x6e3205f...",
+    "amount": 500000,
+    "unit": "WEI" | "FRI"
+}
+```
+
+Response:
+
+```
+{
+    "new_balance": 500000,
+    "unit": "WEI" | "FRI",
+    "tx_hash": "0xa24f23..."
+}
+```
+
+## Check balance
+
+Check the balance of an address by sending a `GET` request to `/account_balance`. The address should be a 0x-prefixed hex string; `unit` defaults to `WEI` and `block_tag` to `latest`.
+
+```
+GET /account_balance?address=<ADDRESS>[&unit=<FRI|WEI>][&block_tag=<latest|pending>]
+```

website/versioned_docs/version-0.0.7/blocks.md

@@ -0,0 +1,66 @@
+# Blocks
+
+Devnet starts with a genesis block (with a block number equal to 0). In forking mode, the genesis block number will be equal to the forked block number plus one.
+
+A new block is generated based on the pending block, once a new block is generated the pending block is restarted. By default, a new block is generated with each new transaction, but you can also [create an empty block by yourself](#create-an-empty-block).
+
+## Creating blocks on demand
+
+If you start Devnet with the `--blocks-on-demand` CLI option, you will enable the possibility to store more than one transaction in the pending block (targetable via block tag `"pending"`).
+
+Once you've added the desired transactions into the pending block, you can send a `POST` request to `/create_block`. This will convert the pending 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 pending block.
+
+In case of demanding block creation with no pending transactions, a new empty block will be generated.
+
+The creation of the genesis block is not affected by this feature.
+
+```
+POST /create_block
+```
+
+Response:
+
+```
+{'block_hash': '0x115e1b390cafa7942b6ab141ab85040defe7dee9bef3bc31d8b5b3d01cc9c67'}
+```
+
+## Create an empty block
+
+To create an empty block without transactions, `POST` a request to `/create_block`:
+
+```
+POST /create_block
+```
+
+Response:
+
+```
+{"block_hash": "0x115e1b390cafa7942b6ab141ab85040defe7dee9bef3bc31d8b5b3d01cc9c67"}
+```
+
+## Abort blocks
+
+This functionality allows simulating block abortion that can occur on mainnet.
+
+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.
+
+E.g. 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.
+
+Aborted blocks can only be queried by block hash. Aborting the blocks in forking origin and already aborted blocks is not supported and results in an error.
+
+```
+POST /abort_blocks
+{
+    "starting_block_hash": BLOCK_HASH
+}
+```
+
+Response:
+
+```
+{
+    "aborted": [BLOCK_HASH_0, BLOCK_HASH_1, ...]
+}
+```