From 97a8761a63056499cfdced86beb9dab6b043d665 Mon Sep 17 00:00:00 2001 From: devportal-assistant Date: Mon, 17 Nov 2025 11:50:31 +0400 Subject: [PATCH 1/4] Docs: Add state storage migration guide to node setup --- zq2/docs/nodes/node.md | 106 +++++++++++++++++++++++++---------------- 1 file changed, 64 insertions(+), 42 deletions(-) diff --git a/zq2/docs/nodes/node.md b/zq2/docs/nodes/node.md index 43e03ed2..3ca09d5b 100644 --- a/zq2/docs/nodes/node.md +++ b/zq2/docs/nodes/node.md @@ -18,8 +18,7 @@ Users can set up a node and join the Zilliqa 2.0 mainnet, testnet or devnet by f - **Disk**: - 200 GB or more -We are running our Zilliqa 2.0 Nodes on Google Cloud Platform, GCP, -GCE VM `e2-highcpu-8` instance with 256 GB SSD (`pd-ssd`). +We are running our Zilliqa 2.0 Nodes on Google Cloud Platform, GCP, GCE VM `e2-highcpu-8` instance with 256 GB SSD (`pd-ssd`). ### [Software requirements](#software-requirements) @@ -28,11 +27,9 @@ GCE VM `e2-highcpu-8` instance with 256 GB SSD (`pd-ssd`). ### [Port-forwarding](#port-forwarding) -The following TCP ports need to be open to the internet for both inbound and -outbound. +The following TCP ports need to be open to the internet for both inbound and outbound. -_NOTE: We don't recommend to run Nodes behind a NAT, if you're doing so -and you are facing any traversal issue you might have to debug on your own._ +_NOTE: We don't recommend to run Nodes behind a NAT, if you're doing so and you are facing any traversal issue you might have to debug on your own._ #### Required @@ -52,53 +49,53 @@ To configure a node and join a Zilliqa 2.0 network, we provide the `z2` utility base. Follow the step by step guide to setup your node: 1. Cargo and Rust: You need to have Cargo and Rust installed on your system. - You can install them using [rustup](https://rustup.rs/). Once rustup is installed, - you can update Rust to the latest stable version. + You can install them using [rustup](https://rustup.rs/). Once rustup is installed, + you can update Rust to the latest stable version. 2. Install the following requirements: - ```bash - sudo add-apt-repository ppa:ethereum/ethereum && sudo apt update && \ - sudo apt install -y solc build-essential pkg-config libssl-dev cmake \ - protobuf-compiler - ``` + ```bash + sudo add-apt-repository ppa:ethereum/ethereum && sudo apt update && \ + sudo apt install -y solc build-essential pkg-config libssl-dev cmake \ + protobuf-compiler + ``` 3. Pick a directory. You'll need quite a lot of space. Let's call it `/my/dir`. 4. Clone [zq2](https://github.com/zilliqa/zq2) sourcecode into that directory to get `/my/dir/zq2`. 5. Build the code using `cargo build`. 6. Source the setenv file: - ```bash - source /my/dir/zq2/scripts/setenv - ``` - This will give you access to the `z2` tool (in `zq2/z2`). + ```bash + source /my/dir/zq2/scripts/setenv + ``` + This will give you access to the `z2` tool (in `zq2/z2`). 7. Generate the startup script and the configuration file for your node by running: - ```bash - z2 join --chain zq2-mainnet - ``` - _NOTE: You can replace zq2-mainnet with `zq2-testnet` or `zq2-devnet` depending on - which network you want your node to join._ - -8. (Optional) A Zilliqa node contains various performance and operational metrics compatible with the OpenTelemetry - protocol specification. If you want to export these metrics you can define a [collector](https://opentelemetry.io/docs/collector/) - endpoint with the `--otlp-endpoint` parameter in `z2 join` pointing to your own OpenTelemetry monitoring stack, for example: - ```bash - z2 join --chain zq2-mainnet --otlp-endpoint=http://localhost:4317 - ``` - _NOTE: For more details on testing and using the available OpenTelemetry - metrics refer to the [OpenTelemetry](monitoring/opentelemetry.md) page._ + ```bash + z2 join --chain zq2-mainnet + ``` + _NOTE: You can replace zq2-mainnet with `zq2-testnet` or `zq2-devnet` depending on + which network you want your node to join._ + +8. (Optional) A Zilliqa node contains various performance and operational metrics compatible with the OpenTelemetry + protocol specification. If you want to export these metrics you can define a [collector](https://opentelemetry.io/docs/collector/) + endpoint with the `--otlp-endpoint` parameter in `z2 join` pointing to your own OpenTelemetry monitoring stack, for example: + ```bash + z2 join --chain zq2-mainnet --otlp-endpoint=http://localhost:4317 + ``` + _NOTE: For more details on testing and using the available OpenTelemetry + metrics refer to the [OpenTelemetry](/monitoring/opentelemetry.md) page._ 9. Generate the node private key. - ```bash - openssl rand -hex 32 > node-private-key.txt - export PRIVATE_KEY=$(cat node-private-key.txt) - ``` - _NOTE: Please save the node key as described above. You may need it - in the future to restart the node to generate the BLS public - key of the node._ + ```bash + openssl rand -hex 32 > node-private-key.txt + export PRIVATE_KEY=$(cat node-private-key.txt) + ``` + _NOTE: Please save the node key as described above. You may need it + in the future to restart the node to generate the BLS public + key of the node._ 10. Now it's time to synchronize the node with the network. For networks created using Zilliqa 2, the node can be synchronized from the genesis. However, for networks such as mainnet and testnet that migrated from Zilliqa 1, the node must be synchronized from a checkpoint: >* Synchronization from a checkpoint. - This method leverages a predefined checkpoint block number and hash and the corresponding state imported from a checkpoint file. Historical states based on blocks prior to the checkpoint are unavailable. Before proceeding to the [start the node section](../nodes/node/#starting-your-node), configure the checkpoint settings according to the instructions in syncing-from-checkpoints. + This method leverages a predefined checkpoint block number and hash and the corresponding state imported from a checkpoint file. Historical states based on blocks prior to the checkpoint are unavailable. Before proceeding to the [start the node section](#starting-your-node), configure the checkpoint settings according to the instructions in syncing-from-checkpoints. >* Synchronization from the genesis. @@ -109,13 +106,13 @@ Please refer to [Syncing & Pruning](../nodes/passive-pruning.md) for information ### [Starting your node](#starting-your-node) Since only devnet nodes can sync from the genesis, all other nodes must be started from a checkpoint: -* start the node from a checkpoint:
 +* start the node from a checkpoint: ```bash chmod +x start_node.sh && \ ./start_node.sh -k $PRIVATE_KEY -p ``` -* start the node from the genesis:
 +* start the node from the genesis: ```bash chmod +x start_node.sh && \ ./start_node.sh -k $PRIVATE_KEY @@ -186,7 +183,6 @@ docker stop ``` Start your new node: - ```bash ./start_node.sh -k $PRIVATE_KEY ``` @@ -196,3 +192,29 @@ You can validate the version your node is running by calling the `GetVersion` AP ```bash curl --request POST --url http://localhost:4202 --header 'content-type: application/json' --data '{"method":"GetVersion","id":1,"jsonrpc":"2.0"}' ``` + +#### State Storage Migration from SQLite to RocksDB + +With the introduction of the `state_sync` feature, Zilliqa 2.0 nodes now use RocksDB for state storage, replacing the older SQLite database. This change significantly improves performance and reliability. Existing nodes running on SQLite will need to migrate their state storage to RocksDB. + +##### Manual Migration Process + +To manually migrate your node's state storage from SQLite to RocksDB, follow these steps: + +1. **Restore from a Checkpoint**: Ensure your node is configured to restore from a recent checkpoint. This will provide a consistent starting point for the migration. Refer to the [Syncing from a Checkpoint](#syncing-from-a-checkpoint) section for detailed instructions. + +2. **Enable `state_sync`**: In your node's configuration file (typically `config.json`), set the `db.state_sync` parameter to `true`. This flag activates the RocksDB state synchronization mechanism. + + ```json + { + "db": { + "state_sync": true + } + } + ``` + +3. **Start the Node**: Once `state_sync` is enabled and your node is configured to restore from a checkpoint, start your node as usual. The node will automatically begin replaying blocks from the checkpoint to populate the new RocksDB state database. This process might take some time depending on the size of the state and the number of blocks to replay. + +##### Lazy Migration + +Nodes that do not perform the manual migration will undergo a lazy migration process. In this scenario, the node will continue to operate using the SQLite database until a new state is generated. Upon the generation of a new state, the node will automatically switch to RocksDB for all subsequent state operations. While this approach requires no manual intervention, it might result in a temporary performance impact during the initial transition. From 3c66aa3215a1bbfe85b4510e9b1581dd47aec984 Mon Sep 17 00:00:00 2001 From: devportal-assistant Date: Mon, 17 Nov 2025 11:51:31 +0400 Subject: [PATCH 2/4] Update checkpoint documentation to reflect new .ckpt format and conversion script. --- zq2/docs/nodes/checkpoints/index.md | 92 +++++++++++++++++------------ 1 file changed, 53 insertions(+), 39 deletions(-) diff --git a/zq2/docs/nodes/checkpoints/index.md b/zq2/docs/nodes/checkpoints/index.md index 3a6819d3..1a13432f 100644 --- a/zq2/docs/nodes/checkpoints/index.md +++ b/zq2/docs/nodes/checkpoints/index.md @@ -13,60 +13,73 @@ You can find a list of checkpoints and hashes to download in the menu bar. Before proceeding, ensure you have completed the [Node Setup](../nodes/node.md#setting-up-your-node) section. -For **mainnet**, you will need the `zq2-mainnet.toml` configuration file and the `start_node.sh` script, both generated during the setup process. Similarly, for **testnet** and **devnet**, you will use the `zq2-testnet.toml` and `zq2-devnet.toml` configuration file. +For **mainnet**, you will need the `zq2-mainnet.toml` configuration file and the `start_node.sh` script, both generated during the setup process. Similarly, for **testnet** and **devnet**, you will use the `zq2-testnet.toml` and `zq2-devnet.toml` configuration files. The following steps apply to both networks. ### Step-by-Step Guide to Configure Checkpoints -1. **Ensure Proper Directory** - Navigate to the directory you created during the setup process, e.g., `/my/dir/zq2`. +1. **Ensure Proper Directory** + Navigate to the directory you created during the setup process, e.g., `/my/dir/zq2`. -2. **Download the Checkpoint File** +2. **Download the Checkpoint File** - Follow these steps to download the latest checkpoint file for your chosen network: + Follow these steps to download the latest checkpoint file for your chosen network: - - **Devnet** - Visit the public [checkpoint URL](https://checkpoints.zq2-devnet.zilliqa.com). + - **Devnet**: + Visit the public [checkpoint URL](https://checkpoints.zq2-devnet.zilliqa.com). - - **Testnet**: - Visit the public [checkpoint URL](https://checkpoints.testnet.zilliqa.com). + - **Testnet**: + Visit the public [checkpoint URL](https://checkpoints.testnet.zilliqa.com). - - **Mainnet**: - Visit the public [checkpoint URL](https://checkpoints.zilliqa.com). + - **Mainnet**: + Visit the public [checkpoint URL](https://checkpoints.zilliqa.com). - From the XML file at the respective URL: + From the XML file at the respective URL: - - Look for the `` tag, which contains the checkpoint file's name. The file follows the `block_num.dat` format (e.g., `000291600.dat`). + - Look for the `` tag, which contains the checkpoint file's name. The file follows the `block_num.ckpt` format (e.g., `0000291600.ckpt`). - - Copy the file name of the latest checkpoint from the topmost `` tag. For older checkpoints, explore the `previous/` directory. + - Copy the file name of the latest checkpoint from the topmost `` tag. For older checkpoints, explore the `previous/` directory. - - Download the checkpoint file using the `wget` command or paste the link in your browser: + - Download the checkpoint file using the `wget` command or paste the link in your browser: - ```bash - wget https://checkpoints.zq2-.zilliqa.com/ - ``` + ```bash + wget https://checkpoints.zq2-.zilliqa.com/ + ``` - Replace with `mainnet`, `testnet` or `devnet` based on your selected network. + Replace `` with `mainnet`, `testnet` or `devnet` based on your selected network. - _NOTE: Checkpoints are generated every 86400 blocks. The earliest checkpoint for the mainnet and testnet was generated at the switchover from Zilliqa 1. If the node does not need historical state it is recommended to use the latest checkpoint file to speed up synchronization. Keep in mind that the node can’t process RPC requests such as eth_getBalance on blocks that were produced before the checkpoint._ + _NOTE: Checkpoints are generated every 86400 blocks. The earliest checkpoint for the mainnet and testnet was generated at the switchover from Zilliqa 1. If the node does not need historical state it is recommended to use the latest checkpoint file to speed up synchronization. Keep in mind that the node can’t process RPC requests such as eth_getBalance on blocks that were produced before the checkpoint._ -3. **Configure Checkpoints in the Configuration File** - Open the respective configuration file (`zq2-mainnet.toml` or `zq2-testnet.toml`) and add the following lines to enable checkpoint settings: - ```toml - [nodes.load_checkpoint] - file = "xxxxx..." # File name of the checkpoint block. for eg: 3000.dat - hash = "xxxxx..." # Block hash corresponding to the file block (Remove '0x' prefix from hash if present) - ``` + ::: danger Incompatibility Warning + The new `.ckpt` checkpoint format is **incompatible** with the old `.dat` format. + If you have existing `.dat` checkpoints and need to use them, you must convert them to the new `.ckpt` format using the `scripts/convert-ckpt` utility provided in the Zilliqa repository. + ::: - `file` : This parameter specifies the name of the checkpoint or block number file, which - can be obtained from the public GCS bucket. It’s recommended to download the latest checkpoint - file from this source. + ### Checkpoint File Format - `hash` : The hash is used to verify the validity of the state data and ensure that no - tampering has occurred. You can obtain the block hash corresponding to the checkpoint height from the - public explorer of your chosen network. For example, if the downloaded - checkpoint file is 3000, you can use the `eth_getBlockByNumber` API to query the block hash: + The new checkpoint files are `ZIP64 archives` with a `.ckpt` extension. Each archive contains the following files: + + - `metadata.json`: Contains metadata about the checkpoint, such as the block number and hash. + - `block.bincode`: Encoded block data. + - `parent.bincode`: Encoded parent block data. + - `transactions.bincode`: Encoded transaction data. + - `state.bincode`: Encoded state data. + - `history.bincode`: Encoded historical data. + +3. **Configure Checkpoints in the Configuration File** + + Open the respective configuration file (`zq2-mainnet.toml` or `zq2-testnet.toml`) and add the following lines to enable checkpoint settings: + + ```toml + [nodes.load_checkpoint] + file = "xxxxxx..." # File name of the checkpoint block. for eg: 3000.ckpt + hash = "xxxxxx..." # Block hash corresponding to the file block (Remove '0x' prefix from hash if present) + ``` + + `file` : This parameter specifies the name of the checkpoint or block number file, which can be obtained from the public GCS bucket. It's recommended to download the latest checkpoint file from this source. + + `hash` : The hash is used to verify the validity of the state data and ensure that no tampering has occurred. You can obtain the block hash corresponding to the checkpoint height from the public explorer of your chosen network. For example, if the downloaded checkpoint file is 3000.ckpt, you can use the `eth_getBlockByNumber` API to query the block hash: ```bash curl --request POST --url https://api.zq2-mainnet.zilliqa.com/ \ @@ -74,11 +87,12 @@ The following steps apply to both networks. --data '{"method":"eth_getBlockByNumber","params":["0xBB8",false],"id":1,"jsonrpc":"2.0"}' \ | grep -o '"hash":"[^"]*"' | awk -F':' '{print $2}' | tr -d '"' ``` - Alternatively, you can retrieve the block hash directly from the public explorer of your chosen network by searching for the block number. - Refer to [block explorers](../endpoints.md#block-explorer) section for public explorer. - By this stage, your checkpoints settings should be specified in the configuration file. -4. **Launch the node** -Now the node is ready to launch. Follow the instructions in the [Start the Node](../nodes/node.md#starting-your-node) section to start your node. + Alternatively, you can retrieve the block hash directly from the public explorer of your chosen network by searching for the block number. + Refer to [block explorers](../endpoints.md#block-explorers) section for public explorer. + By this stage, your checkpoints settings should be specified in the configuration file. + +4. **Launch the node** + Now the node is ready to launch. Follow the instructions in the [Start the Node](../nodes/node.md#starting-your-node) section to start your node. **Note**: After starting a node from a checkpoint for the first time it typically takes approximately 1.5 hours to start syncing. During this time the node won’t respond to RPC requests. Please allow sufficient time for the process to complete. From 2bff6d5d342c1ce386dc9e587fef783d8de40cde Mon Sep 17 00:00:00 2001 From: devportal-assistant Date: Mon, 17 Nov 2025 11:54:35 +0400 Subject: [PATCH 3/4] Docs: Update unbonding period in Solo Staking section --- zq2/docs/staking/index.md | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/zq2/docs/staking/index.md b/zq2/docs/staking/index.md index 05a16e2a..000c3c79 100644 --- a/zq2/docs/staking/index.md +++ b/zq2/docs/staking/index.md @@ -11,9 +11,13 @@ it by unstaking and withdrawing part of their deposit. Note that the remaining deposit must be at least the required minimum. If a validator does not want to participate in the consensus anymore, they must unstake their entire deposit. +:::note +With the `deposit_v7` contract upgrade, the `withdrawal_period` (unbonding period) has been shortened from 1,209,600 seconds (14 days) to 461,680 seconds (approximately 5.3 days). This change was activated via a hard fork at mainnet block 13,514,400 and testnet block 17,010,000. +::: + # Delegated Staking -Alternatively, validators can operate staking pools, allowing users to delegate +Alternatively, validators can operate staking pools, allowing users to delegate stake to them. To set up a staking pool, they can use the reference implementation mentioned below or create and deploy their own smart contracts. @@ -25,27 +29,27 @@ The reference smart contracts currently support two variants of delegated stakin - Users receive a **non-rebasing Liquid Staking Token (LST)** upon delegation. - The tokens represent the delegator's share of the total stake delegated to the -staking pool. As the staking pool earns rewards, the value of the liquid staking -token will increase. The tokens are burned when the delegator withdraws their stake, + staking pool. As the staking pool earns rewards, the value of the liquid staking + token will increase. The tokens are burned when the delegator withdraws their stake in return for ZIL. ### 2. **Non-Liquid Staking** -- Users can withdraw their share of the rewards in ZIL regularly without unstaking -their principal amount. +- Users can withdraw their share of the rewards in ZIL regularly without unstaking + their principal amount. - Instead of withdrawing the accrued rewards, users can also stake the rewards to -increase their share of the total stake and their future rewards. Furthermore, they -can replace their registered address to make another wallet eligible for unstaking -and claiming rewards. + increase their share of the total stake and their future rewards. Furthermore, they + can replace their registered address to make another wallet eligible for unstaking + and claiming rewards. ## Setup by Depositing a Validator from Operator Funds -Node operators with sufficient funds to deposit the minimum stake required of validators can turn their node into a validator node as soon as it is synced, and join a staking pool later. Detailed instructions can be found [here](../staking/delegatedstaking.md). - +Node operators with sufficient funds to deposit the minimum stake required of validators +can turn their node into a validator node as soon as it is synced, and join a staking pool later. Detailed instructions can be found [here](../staking/delegatedstaking.md). ## Setup by Funding a Validator through Delegations Node operators who do not have the minimum stake required to run a validator node can launch a staking pool, collect delegated stake and deposit it to turn their node into a validator once the total delegated stake reaches the minimum required of validators. -Refer [here](../staking/delegatedstaking.md) for more information. \ No newline at end of file +Refer [here](../staking/delegatedstaking.md) for more information. From f8d78e066bde238ddaf0b0470ccd4fc0cf53ba08 Mon Sep 17 00:00:00 2001 From: devportal-assistant Date: Mon, 17 Nov 2025 11:55:39 +0400 Subject: [PATCH 4/4] Docs: Update node.md with new configuration parameters and sections --- zq2/docs/nodes/node.md | 37 +++++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/zq2/docs/nodes/node.md b/zq2/docs/nodes/node.md index 3ca09d5b..1d015852 100644 --- a/zq2/docs/nodes/node.md +++ b/zq2/docs/nodes/node.md @@ -7,8 +7,6 @@ title: Node setup Users can set up a node and join the Zilliqa 2.0 mainnet, testnet or devnet by following the instructions below -## Prerequisites - ### [Minimum hardware requirements](#minimum-hardware-requirements) - **CPU**: @@ -18,7 +16,7 @@ Users can set up a node and join the Zilliqa 2.0 mainnet, testnet or devnet by f - **Disk**: - 200 GB or more -We are running our Zilliqa 2.0 Nodes on Google Cloud Platform, GCP, GCE VM `e2-highcpu-8` instance with 256 GB SSD (`pd-ssd`). +We are running our Zilliqa 2.0 Nodes on Google Cloud Platform, GCP GCE VM `e2-highcpu-8` instance with 256 GB SSD (`pd-ssd`). ### [Software requirements](#software-requirements) @@ -45,8 +43,7 @@ be accessible via the internet. ### [Setting up your node](#setting-up-your-node) -To configure a node and join a Zilliqa 2.0 network, we provide the `z2` utility as part of the [zq2](https://github.com/Zilliqa/zq2/blob/main/) code -base. Follow the step by step guide to setup your node: +To configure a node and join a Zilliqa 2.0 network, we provide the `z2` utility as part of the [zq2](https://github.com/Zilliqa/zq2/blob/main/) code base. Follow the step by step guide to setup your node: 1. Cargo and Rust: You need to have Cargo and Rust installed on your system. You can install them using [rustup](https://rustup.rs/). Once rustup is installed, @@ -58,7 +55,7 @@ base. Follow the step by step guide to setup your node: protobuf-compiler ``` 3. Pick a directory. You'll need quite a lot of space. Let's call it `/my/dir`. -4. Clone [zq2](https://github.com/zilliqa/zq2) sourcecode into that directory to get `/my/dir/zq2`. +4. Clone [zq2](https://github.com/Zilliqa/zq2) sourcecode into that directory to get `/my/dir/zq2`. 5. Build the code using `cargo build`. 6. Source the setenv file: @@ -70,7 +67,7 @@ base. Follow the step by step guide to setup your node: ```bash z2 join --chain zq2-mainnet ``` - _NOTE: You can replace zq2-mainnet with `zq2-testnet` or `zq2-devnet` depending on + _NOTE: You can replace `zq2-mainnet` with `zq2-testnet` or `zq2-devnet` depending on which network you want your node to join._ 8. (Optional) A Zilliqa node contains various performance and operational metrics compatible with the OpenTelemetry @@ -137,14 +134,13 @@ the above request, then it is still processing the checkpoint file and has not started synchronizing yet. For additional details on `z2` and the `join` capability refer to: - - - ### [Becoming a Validator](#becoming-a-validator) Under the consensus mechanism introduced in Zilliqa 2.0, nodes can stake ZIL to secure -the network and promote themselves as validator nodes. In return, they receive a +the network and promote themselves as validator nodes. In return, they receive a share of the block rewards. Once you have sufficient $ZILs you can register your node as validator. @@ -169,14 +165,12 @@ z2 join --chain zq2-mainnet ``` _NOTE: Replace `zq2-mainnet` with the chain you are running on._ -To minimise the downtime of your node, we recommend pulling the new image locally before you stop your old node: - +To minimize the downtime of your node, we recommend pulling the new image locally before you stop your old node: ```bash docker pull asia-docker.pkg.dev/prj-p-devops-services-tvwmrf63/zilliqa-public/zq2:${ZQ_VERSION} # You can copy the new ZQ_VERSION from inside `start_node.sh` ``` Stop your existing node: - ```bash docker container ls # Identify the container ID of the existing node. This will look a 12 character hex-string (e.g. af6010f3f9ae). docker stop @@ -197,6 +191,8 @@ curl --request POST --url http://localhost:4202 --header 'content-type: applicat With the introduction of the `state_sync` feature, Zilliqa 2.0 nodes now use RocksDB for state storage, replacing the older SQLite database. This change significantly improves performance and reliability. Existing nodes running on SQLite will need to migrate their state storage to RocksDB. +- `db.state_sync` (boolean, default: `false`): Enables the state migration process from SQLite to RocksDB. Must be set to `true` on existing nodes to perform the migration. + ##### Manual Migration Process To manually migrate your node's state storage from SQLite to RocksDB, follow these steps: @@ -218,3 +214,20 @@ To manually migrate your node's state storage from SQLite to RocksDB, follow the ##### Lazy Migration Nodes that do not perform the manual migration will undergo a lazy migration process. In this scenario, the node will continue to operate using the SQLite database until a new state is generated. Upon the generation of a new state, the node will automatically switch to RocksDB for all subsequent state operations. While this approach requires no manual intervention, it might result in a temporary performance impact during the initial transition. + +### Performance Tuning + +The following parameters can be configured in your `zilliqa.toml` file for performance tuning: + +- `db.rocksdb_cache_size` (integer, default: `268435456`): Sets the block cache size for RocksDB in bytes. +- `slow_rpc_queries_handlers_count` (integer, default: `4`): Configures the number of threads in the Tokio runtime dedicated to handling slow RPC queries. + +_NOTE: The default values for `state_cache_size` and `db.conn_cache_size` have been reduced to prevent Out-Of-Memory issues._ + +### Jailing Mechanism + +- `max_missed_view_age` (integer, default: `600`): Defines the number of views of missed block history to retain for the jailing mechanism. + +### Caching + +- `REDIS_ENDPOINT` (environment variable): An optional endpoint for a Redis instance can now be provided to the node, used for caching purposes.