# Welcome to Spicenet Validator Documentation

### Empowering the Backbone of Spicenet

Welcome to the official documentation for Spicenet validators. As a validator, you play a crucial role in maintaining the security, efficiency, and decentralization of the Spicenet blockchain. This guide will provide all the information you need to set up, run, and keep your Spicenet validator node.

### What is a Spicenet Validator?&#x20;

Spicenet validators are responsible for:

* 📥 Receiving and verifying batches of transactions &#x20;
* 🌐 Maintaining network state
* 🕵️‍♂️ Detect fraud
* 🛡️  Produce fraud proofs

Your participation as a validator is fundamental to the health and growth of the Spicenet ecosystem.

### Community and Support

Join our validator community:

* [Validator Discord Channel](https://discord.gg/MMD7z5mjcV)
* [Validator Forum](https://discord.gg/nZesEG7nKZ)
* [GitHub Issues](https://github.com/pepper-research/spicenet/issues)

### Stay Informed

Keep up with the latest validator-specific updates:

* Validator Changelog
* Upgrade Guides
* Governance Participation

We're thrilled to have you as part of the Spicenet validator community. Your role is vital in building a robust and decentralized future with Spicenet!


# 1.1 Role of Validators in Spicenet

Validators play a critical role in maintaining the integrity and efficiency of the Spicenet blockchain. As a Spicenet validator, your primary responsibilities are:

1. **Receiving and Verifying Batches of Transactions**: You'll be responsible for accepting incoming transaction batches and verifying their validity according to the network's rules.
2. **Maintaining Network State**: Validators are tasked with keeping an up-to-date record of the network's state, ensuring consistency across the blockchain.
3. **Detecting Fraud**: One of your key roles is to be vigilant in identifying any fraudulent activities or invalid transactions within the network.
4. **Producing Fraud Proofs**: When fraud is detected, validators are responsible for generating and submitting fraud proofs to the network, helping to maintain its integrity.

These specific responsibilities make Spicenet validators crucial for:

* Ensuring the accuracy and reliability of transactions
* Maintaining the overall security of the network
* Upholding the trustless nature of the blockchain


# 1.2 Validator Responsibilities in Detail

Let's delve deeper into each of these responsibilities:

1. **Receiving and Verifying Batches of Transactions**
   * Your node will continuously receive batches of transactions from the network.
   * You must verify each transaction in these batches to ensure they adhere to Spicenet's protocol rules.
   * This includes checking for correct signatures, sufficient balances, and adherence to any smart contract conditions.
2. **Maintaining Network State**
   * As transactions are processed, you'll update your local copy of the network state.
   * This state includes account balances, smart contract states, and other relevant blockchain data.
   * Ensuring your state matches that of other honest validators is crucial for network consensus.
3. **Detecting Fraud**
   * You'll need to run checks to identify any suspicious or invalid transactions.
   * This might involve looking for double-spends, invalid state transitions, or other protocol violations.
   * Prompt detection of fraud is vital to prevent any potential damage to the network.
4. **Producing Fraud Proofs**
   * If you detect fraudulent activity, you're responsible for creating a fraud-proof.
   * This proof is a cryptographic demonstration of the invalid state transition or transaction.
   * You'll submit this proof to the network, allowing other validators to verify the fraud and take appropriate action.


# 1.3 Requirements for Effective Validation

To effectively carry out these responsibilities, you'll need:

1. **Robust Hardware**: Capable of processing transaction batches quickly and maintaining an up-to-date state.
2. **High Uptime**: Your node should be operational 24/7 to continually receive and verify transactions.
3. **Updated Software**: Always run the latest version of Spicenet software to ensure compatibility and security.
4. **Network Connectivity**: A stable and fast internet connection is crucial for timely communication with the network.
5. **Technical Knowledge**: Understanding of blockchain technology, cryptography, and Spicenet's specific protocols.

In the following sections, we'll guide you through setting up your validator node and configuring it to effectively perform these crucial tasks on the Spicenet blockchain.


# 2.1 Validator Requirements

On Spicenet, validators are broadly classified into two categories:

1. Non-voting validators
2. Voting validators

### **Non-voting Validators**

Non-voting validators on Spicenet are more akin to full nodes. They:

* Cannot participate in network discourse, such as voting
* Cannot challenge state or generate fraud proofs
* Still have stake in the network and can be attributed for malicious behavior
* Come under a hierarchy below voting validators
* Garner lower rewards compared to voting validators due to their limited participation

Hardware Requirements for Non-voting Validators:

#### **Minimum:**

* 16GB RAM
* 8 Core CPU (no custom features required as of now)
* 500GB Storage
* Bandwidth: 500Mbps sustained bandwidth

#### **Recommended:**

* 32GB RAM
* 16 Core CPU (no custom features required as of now)
* 2TB Storage
* Bandwidth: 1Gbps sustained bandwidth

#### **Stake Requirements:** TBD (But will be subsidised by the Spicenet Foundation for initial validators)

{% hint style="info" %}
No GPU is required as Spicenet is not optimised for GPU yet. The only process that may require a GPU for faster throughput is a prover, which is not available for non-voting validators.
{% endhint %}

### **Voting Validators**

Voting validators on Spicenet are more akin to full validators. They:

* Can participate in active network discourse, such as voting
* Can challenge state and generate fraud proofs
* Have stake in the network and can be attributed for malicious behavior
* Come under a hierarchy above non-voting validators
* Have a specialised proving process attached to their software, allowing them to generate proofs of invalidity (fraud proofs)
* Garner higher block rewards for their increased participation in the network

Hardware Requirements for Voting Validators:

#### **Minimum:**

* 32GB RAM
* 16 Core CPU (no custom features required as of now)
* 1TB Storage
* Bandwidth: 500Mbps sustained bandwidth

#### **Recommended:**

* 64GB RAM
* 32 Core CPU (with preferably a higher clock rate, or a higher core CPU with a moderate clock rate, such as a 2x24 Core CPU)
* 2TB Storage
* Bandwidth: 1Gbps sustained bandwidth
* (Optional) GPU for running prover processes within the zkVM: recommended Nvidia 4070 (minimum) or 4080

#### **Stake Requirements:** TBD (But will be subsidized by the Spicenet Foundation for initial validators)


# 2.2 Setting Up Your Environment

### Operating System Setup

1. If you haven't already, install Ubuntu 20.04 LTS on your machine.
2. Update your system:

```bash
sudo apt update && sudo apt upgrade -y
```

### Installing Dependencies

1. Install necessary packages:

```bash
sudo apt install -y build-essential git curl
sudo apt install -y pkg-config libssl-dev clang postgresql
```

2. Install Rust:

```bash
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
```

3. Add Rust to your path:

```bash
source $HOME/.cargo/env
```

#### Setting Up Firewall

If you're using UFW (Uncomplicated Firewall), allow SSH connections:

```bash
sudo ufw allow ssh
```

We'll open specific ports for Spicenet later in the configuration process.


# 2.3 Installing Spicenet

### Using Binaries

Use our binaries to run the Spicenet validator node, download the latest version at

```
https://github.com/pepper-research/testnet-canary/releases
```

{% hint style="info" %}
Current version for validators is v0.1.1
{% endhint %}


# 3.1 Binaries Configuration

{% hint style="info" %}
This option can be found in our latest testnet repo [here](https://github.com/pepper-research/testnet-canary)
{% endhint %}

Once you have downloaded the required binaries from releases of the repo, we will be configuring it to work in a specific file system structure

* App
  * spicenet-ubuntu-latest
  * configs
    * celestia

`configs` can be found in the testnet repo at the root.

{% hint style="info" %}
Set up connection to celestia in the file `configs/celestia/rollup.toml` in the fields `celestia_rpc_address` and `celestia_rpc_auth_token`

&#x20;Make sure your celestia bridge node runs on the mocha testnet. Refer to celestia's guide on running and maintaining a celestial bridge node [here](https://docs.celestia.org/how-to-guides/bridge-node)
{% endhint %}

Run the binary with

```sh
chmod +x spicenet-ubuntu-latest
./spicenet-ubuntu-latest
```


# 3.2 Docker Configuration

{% hint style="info" %}
Docker for v0.1.1 will be coming soon
{% endhint %}

We have a pre-built docker image hosted on dockerhub. Pull the image with

```sh
docker pull spicenet/node:v0.1.0
```

The container needs volume on the host system to work uninterrupted, so the file structure should look like this&#x20;

* App
  * configs
    * celestia

`celestia_rollup_config.toml` and `test-data` can be found in the validator repo ([here](https://github.com/pepper-research/testnet-canary)) at the root.

Run the docker container with

```sh
docker run -it -v $(pwd):/app spicenet/node:v0.1.0 --da-layer celestia --rollup-config-path ./celestia_rollup_config.toml --genesis-config-dir ./test-data/genesis/celestia
```


# 3.3 Security Best Practices

### Key Management

1. Generate a new key pair for your validator:

```bash
./target/debug/sov-cli keys generate
```

2. Securely store your private key. Never share it or store it in plain text on your server.
3. Use hardware security modules (HSMs) for additional security if available.

### Node Security

1. Keep your operating system and all software up to date.
2. Use a firewall to restrict incoming connections:

   ```bash
   sudo ufw allow 12346/tcp
   sudo ufw enable
   ```
3. Disable root SSH access and use key-based authentication.

### Network Security

1. Use a VPN or private network for communication between your nodes if running multiple.
2. Implement DDoS protection if your node is publicly accessible.
3. Regularly monitor your node for unusual activity or performance issues.


# 4.1 Starting Your Node

To start your Spicenet validator node:

1. Navigate to your Spicenet directory:

```bash
cd /path/to/spicenet
```

2. Ensure that a Celestia node is running, as Spicenet uses Celestia for data availability. If you haven't started a Celestia node, you can do so with:

```bash
make start
```

This command starts a Celestia node as a container and creates the necessary configurations for your Spicenet node to connect to it.

3. Start the Spicenet node:

```
cargo run
```

4. When your node starts running, you'll see output similar to the following:

```
2023-10-02T15:30:10.123Z INFO  sov_rollup::runner] Starting Spicenet node...
2023-10-02T15:30:10.234Z INFO  sov_rollup::runner] Connecting to DA layer...
2023-10-02T15:30:10.345Z INFO  sov_rollup::runner] Successfully connected to DA layer
2023-10-02T15:30:10.456Z INFO  sov_rollup::runner] Initializing state...
2023-10-02T15:30:10.567Z INFO  sov_rollup::runner] State initialized. Current state root: 0x1a2b3c...
2023-10-02T15:30:10.678Z INFO  sov_rollup::runner] Node is ready to receive and process transaction batches
2023-10-02T15:30:15.789Z INFO  sov_rollup::runner] Received batch of 5 transactions
2023-10-02T15:30:15.890Z INFO  sov_rollup::runner] Processing transactions...
2023-10-02T15:30:16.001Z INFO  sov_rollup::runner] Batch processed. New state root: 0x4d5e6f...
2023-10-02T15:30:16.112Z INFO  sov_rollup::runner] Waiting for next batch...
```

This output indicates that:

* Your Spicenet node has started successfully
* It has connected to the Celestia Data Availability (DA) layer
* The initial Spicenet state has been set up
* The node is processing incoming transaction batches received from Celestia
* After processing each batch, a new Spicenet state root is calculated

5. Your Spicenet node will continue to run, receiving transaction batches from Celestia and processing them. The output will show ongoing activity, including:

* Receipt of new transaction batches from Celestia
* Processing of these batches on Spicenet
* Updates to the Spicenet state root after each batch is processed
* Any potential errors or warnings that might occur during the operation

Keep this terminal window open to maintain your Spicenet node's operation. You can open new terminal windows for interacting with your node or performing other tasks.


# 4.2 Monitoring Your Node

### Understanding Node Output

Your node will output logs that include:

* Current slot number
* Number of blobs processed
* State root hash
* Any errors or warnings

Example output:

{% code overflow="wrap" %}

```
[2023-06-15T10:30:15Z INFO  sov_rollup::runner] Slot 1234: Processed 5 blobs. New state root: 0x1a2b...
```

{% endcode %}

### Setting Up Monitoring Tools

1. Use Prometheus for metrics collection:
   * Install Prometheus
   * Configure it to scrape metrics from your Spicenet node
2. Set up Grafana for visualization:

   * Install Grafana
   * Create dashboards for key metrics like processed blobs, latency, and peer count


# 4.3 Performing Sanity Checks

After setting up your node, it's crucial to perform some sanity checks to ensure everything is working correctly. Let's go through the process of creating a token and checking balances.

### Creating a Test Tok (costs gas)

1. Open a new terminal tab and submit your first transaction by creating a token:

```bash
make test-create-token
```

2. Once the batch is submitted, you should see output containing the transaction hash. For example:

{% code overflow="wrap" %}

```
Your batch was submitted to the sequencer for publication. Response: "Submitted 1 transaction"
0: 0xfce2381221722b8114ba41a632c44f54384d0a31f332a64f7cbc3f667841d7f0
```

{% endcode %}

3. Use this transaction hash to query the REST API endpoint and fetch events belonging to the transaction:

{% code overflow="wrap" %}

```bash
curl -sS http://127.0.0.1:12346/ledger/txs/0xfce2381221722b8114ba41a632c44f54384d0a31f332a64f7cbc3f667841d7f0/events | jq
```

{% endcode %}

Replace the transaction hash with the one from your output.

4. You should see output similar to:

```json
{
  "data": [
    {
      "type": "event",
      "number": 0,
      "key": "token_created",
      "value": {
        "token-created": {
          "token_name": "sov-test-token",
          "coins": {
            "amount": 1000000,
            "token_id": "token_1zdwj8thgev2u3yyrrlekmvtsz4av4tp3m7dm5mx5peejnesga27ss0lusz"
          },
          "minter": {
            "User": "sov15vspj48hpttzyvxu8kzq5klhvaczcpyxn6z6k0hwpwtzs4a6wkvqwr57gc"
          },
          "authorized_minters": [
            {
              "user": "sov1l6n2cku82yfqld30lanm2nfw43n2auc8clw7r5u5m6s7p8jrm4zqrr8r94"
            },
            {
              "user": "sov15vspj48hpttzyvxu8kzq5klhvaczcpyxn6z6k0hwpwtzs4a6wkvqwr57gc"
            }
          ]
        }
      },
      "module": {
        "type": "moduleRef",
        "name": "Bank"
      }
    }
  ],
  "meta": {}
}
```

Note the <mark style="color:red;">`token_id`</mark> in the output. You'll need this for checking balances.

### Checking Balances (Gasless)

1. In a new terminal tab, run an RPC query to check the balance of your address:

{% code overflow="wrap" %}

```bash
curl -Ss http://127.0.0.1:12346/modules/bank/tokens/TOKEN_ID/balances/YOUR_ADDRESS | jq -c -M
```

{% endcode %}

Replace `TOKEN_ID` with the actual token ID and `ADDRESS` with the address you want to check.

2. You should see a response similar to:

{% code overflow="wrap" %}

```json
{"data":{"coins": {"amount": 1000000,"token_id": "token_1zdwj8thgev2u3yyrrlekmvtsz4av4tp3m7dm5mx5peejnesga27ss0lusz"}},"meta":{}}
```

{% endcode %}

this confirms that your address has received the newly created tokens.

By completing these sanity checks, you've verified that your node can create tokens, submit transactions, and query balances. This indicates that your Spicenet validator node is set up correctly and functioning as expected.

### Submitting Test Transactions

1. Generate a test transaction:

{% code overflow="wrap" %}

```bash
./target/debug/sov-cli transactions import from-file bank --max-fee 100000000 --path ./examples/test-data/requests/transfer.json
```

{% endcode %}

2. Submit the transaction:

{% code overflow="wrap" %}

```bash
./target/debug/sov-cli node submit-batch --wait-for-processing by-address YOUR_ADDRESS
```

{% endcode %}

Replace `YOUR_ADDRESS` with your actual address.

3. Verify the transaction by checking balances again.

By following these steps, you should now have a configured and running Spicenet validator node. Remember to regularly check for updates and maintain your node's security and performance.


# 5.1 Understanding Transaction Structure

In Spicenet, transactions are structured as part of the `CallMessage` enum. This structure defines the various types of operations that can be performed within the Spicenet ecosystem. Let's break down the `CallMessage` enum for the Bank module:

```rust
use sov_bank::CallMessage::Transfer;
use sov_bank::Coins;
use sov_bank::TokenId;
use sov_bank::Amount;

pub enum CallMessage<S: sov_modules_api::Spec> {
    CreateToken {
        salt: u64,
        token_name: String,
        initial_balance: Amount,
        mint_to_address: S::Address,
        authorized_minters: Vec<S::Address>,
    },
    Transfer {
        to: S::Address,
        coins: Coins,
    },
    Burn {
        coins: Coins,
    },
    Mint {
        coins: Coins,
        mint_to_address: S::Address,
    },
    Freeze {
        token_id: TokenId,
    },
}
```

Each variant of this enum represents a different type of transaction:

* `CreateToken`: Used to create a new token on the network.
* `Transfer`: Moves tokens from one address to another.
* `Burn`: Destroys a specified amount of tokens.
* `Mint`: Creates new tokens and assigns them to an address.
* `Freeze`: Prevents further minting or burning of a specific token.


# 5.2 Generating Transactions

To generate a transaction, you'll use the `sov-cli` tool. Let's go through the process of creating a transfer transaction:

1. Create a JSON file named `transfer.json` with the following content:

{% code overflow="wrap" %}

```json
{
  "transfer": {
    "to": "sov1zgfpyysjzgfpyysjzgfpyysjzgfpyysjzgfpyysjzgfpyysjzgfqve8h6h",
    "coins": {
      "amount": 200,
      "token_id": "token_1rwrh8gn2py0dl4vv65twgctmlwck6esm2as9dftumcw89kqqn3nqrduss6"
    }
  }
}
```

{% endcode %}

This JSON represents a transfer of 200 tokens to the specified address.

2. Use `sov-cli` to import the transaction:

{% code overflow="wrap" %}

```bash
./target/debug/sov-cli transactions import from-file bank --max-fee 100000000 --path ./transfer.json
```

{% endcode %}

This command imports the transaction into the local transaction pool. The `--max-fee` parameter sets the maximum gas fee you're willing to pay for this transaction.


# 5.3 Submitting Transactions

Once you've generated a transaction, you need to submit it to the network. Here's how:

{% code overflow="wrap" %}

```bash
./target/debug/sov-cli node submit-batch --wait-for-processing by-address YOUR_ADDRESS
```

{% endcode %}

Replace `YOUR_ADDRESS` with your actual Spicenet address.

This command submits all pending transactions in your local pool to the network. The `--wait-for-processing` flag ensures that the command doesn't return until the transactions have been processed by the network.

After submitting, you should see output similar to:

```
Submitted batch of 1 transactions.
Transaction hash: 0x1234...5678
Waiting for processing...
Transaction processed successfully.
```


# 5.4 Verifying Transactions

As a validator, one of your key responsibilities is to verify incoming transaction batches. This process involves:

1. Receiving transaction batches from the Celestia DA layer.
2. Verifying the validity of each transaction in the batch:
   * Check that the sender has sufficient balance for transfers.
   * Ensure the transaction is properly signed.
   * Verify that the transaction doesn't violate any network rules.
3. Updating the network state based on valid transactions.
4. Detecting any fraudulent activities and producing fraud proofs if necessary.

While the Spicenet node software handles much of this automatically, it's crucial to understand the process and monitor your node's performance in these tasks.


# 6.1 Using REST API

Spicenet provides a comprehensive REST API for interacting with your node. Here are some key endpoints and their usage:

1. Get events for a specific slot:

```bash
GET http://localhost:12346/ledger/events/{slot_number}
```

Example: `http://localhost:12346/ledger/events/17`

2. Get events for a specific transaction:

```
GET http://localhost:12346/ledger/txs/{tx_id}/events/{event_index}
```

Example: `http://localhost:12346/ledger/txs/50/events/0`

3. Get events with a specific key:

```
GET http://localhost:12346/ledger/batches/{batch_id}/txs/{tx_index}/events/{event_index}
```

Example: `http://localhost:12346/ledger/batches/10/txs/2/events/0`

To use these endpoints, you can use curl in your terminal or any HTTP client. For example:

```bash
curl -s http://localhost:12346/ledger/events/17 | jq
```

This will retrieve all events for slot 17 and format the JSON output for readability.


# 6.2 Using sov-cli

The `sov-cli` tool is your primary interface for interacting with your Spicenet node. Here are some common commands and their usage:

1. Generate a new key pair:

```
./target/debug/sov-cli keys generate
```

This will output a new public and private key pair. Make sure to securely store the private key.

2. List transactions in your local pool:

```
./target/debug/sov-cli transactions list
```

This shows all transactions that have been imported but not yet submitted to the network.

3. Query node status:

```
./target/debug/sov-cli node status
```

This provides information about your node's current state, including the latest processed slot and any pending transactions.

4. Get help on available commands:

```
./target/debug/sov-cli --help
```

This displays all available commands and their brief descriptions.

Remember to run these commands from the directory where `sov-cli` is located.


# 7.1 Rewards and Incentives

As a Spicenet validator, you'll earn rewards for:

1. Successfully receiving and verifying transaction batches
2. Maintaining the network state accurately
3. Detecting fraud and producing fraud proofs when necessary

The exact reward structure is determined by the network's governance and may change over time.


# 7.2 Slashing Conditions

Validators may face slashing (loss of staked tokens) for:

1. Extended downtime
2. Failing to detect and report fraud
3. Submitting invalid fraud proofs

Always ensure your node is properly configured and maintained to avoid slashing.


# 8.1 Routine Maintenance

1. Regularly update your operating system and security patches
2. Monitor disk space and prune old data if necessary
3. Keep an eye on your node's performance metrics
4. Backup your validator keys and config files regularly


# 8.2 Upgrading Your Node

When a new version of Spicenet is released:

1. Check the release notes for any breaking changes
2. Stop your node
3. Backup your data
4. Update the Spicenet software:

```bash
git pull
cargo build --release
```

5. Restart your node

Always test upgrades on a testnet before applying them to your mainnet validator.


# 9.1 Common Issues and Solutions


# 1. Node Won't Start

Symptoms:

* Error messages when trying to start the node
* The node process terminates immediately after starting

We will be covering possible causes and solutions for this problem.&#x20;


# Celestia Node Not Running

**Error: "Failed to connect to DA layer"**

**Solution:**

1. Check if Celestia node is running:

```bash
docker ps | grep celestia
```

2. If not running, start it:

```bash
make start
```

3. Verify Celestia node is synced:

{% code overflow="wrap" %}

```bash
docker exec -it celestia-node celestia bridge --node.store /home/celestia/bridge state
```

{% endcode %}


# Outdated Spicenet Version

**Error: "Incompatible protocol version"**

Solution:

1. Update Spicenet:

```bash
git pull origin main
cargo build --release
```

2. Restart your node


# Incorrect Configuration

**Error: "Failed to parse config file"**

**Solution:**

1. Check `rollup_config.toml`:

```bash
nano rollup_config.toml
```

2. Verify all fields are correctly set, especially `host`, `port`, and `da_layer` settings
3. Correct any misconfigurations and restart the node


# 2. Transactions Not Being Processed

Symptoms:

* Transactions remain pending for an extended period
* No new blocks are being produced

We will be covering possible causes and solutions for this problem.&#x20;


# Node Not Synced:

**Symptom:** Large gap between current time and last processed block time

**Solution:**

1. Check sync status:

```bash
curl -s http://localhost:12346/ledger/status | jq
```

2. If not synced, ensure a stable internet connection and wait for sync to complete
3. If sync doesn't progress, try restarting the node:

```
./target/release/sov-rollup restart
```


# Low Peer Count

**Symptom:** Few or no connected peers

**Solution:**

1. Check peer count:

```bash
curl -s http://localhost:12346/network/peers | jq length
```

2. If low, check your firewall settings and ensure the required ports are open
3. Add seed nodes manually if necessary (refer to network documentation for current seed nodes)


# Insufficient Gas

**Symptom:** Transactions stuck with "out of gas" errors

**Solution:**

1. Check gas prices:

```bash
curl -s http://localhost:12346/ledger/gas_price | jq
```

2. Adjust max gas settings in your transactions or wait for gas prices to decrease


# Poor Performance

Symptoms:

* High latency in transaction processing
* Node frequently falls behind in syncing


# Insufficient Hardware Resources

**Symptom:** High CPU, RAM, or disk usage

**Solution:**

1. Check resource usage:

```bash
top
```

2. Monitor disk I/O:

```
iostat -x 1
```

3. Upgrade hardware if consistently at capacity


# Network Issues

**Symptom:** High latency or packet loss

**Solution:**

1. Check network performance:

```bash
ping 8.8.8.8
```

2. Run a speed test to verify bandwidth
3. Contact your ISP if issues persist


# Suboptimal Spicenet Configuration:

**Symptom:** Node struggles with high transaction volume

**Solution:**

1. Review and optimize `rollup_config.toml` settings
2. Adjust batch size or processing parameters if necessary (consult Spicenet documentation for safe ranges)


# 9.2 Advanced Debugging Techniques

### 1. Analyzing Node Logs

Spicenet nodes output detailed logs that can be crucial for troubleshooting:

1. View real-time logs:

```bash
tail -f /path/to/spicenet/log/node.log
```

2. Search for error messages:

```bash
grep -i error /path/to/spicenet/log/node.log
```

3. Analyze log patterns:

```bash
awk '/pattern/ {print $0}' /path/to/spicenet/log/node.log
```

### 2. Monitoring System Resources

Use these commands to get a detailed view of system resource usage:

1. Overall system status:

```bash
htop
```

2. Disk usage:

```bash
df -h
```

3. Network statistics:&#x20;

```bash
netstat -tuln
```

### 3. Debugging Transaction Issues

If specific transactions are failing:

1. Retrieve transaction details:

```bash
curl -s http://localhost:12346/ledger/txs/TRANSACTION_HASH | jq
```

2. Check transaction status:

```
./target/debug/sov-cli transactions status TRANSACTION_HASH
```

3. Verify account balances:

{% code overflow="wrap" %}

```bash
curl -s http://localhost:12346/modules/bank/tokens/TOKEN_ID/balances/ADDRESS | jq
```

{% endcode %}


# 9.3 Seeking Help

If you're unable to resolve an issue:

1. Check the [Spicenet GitHub Issues](https://github.com/pepper-research/spicenet/issues) for similar problems and solutions.
2. Join the [Spicenet Discord](https://discord.gg/spicenet) and describe your issue in the #validator-support channel, including:
   * Detailed error messages
   * Relevant log snippets
   * Your node version (`./target/debug/sov-cli --version`)
   * Steps you've already taken to troubleshoot
3. If you suspect a bug, create a new GitHub issue with:
   * A clear title and description
   * Steps to reproduce the problem
   * Expected vs. actual behavior
   * Any relevant logs or error messages

Remember, when sharing logs or error messages, always remove any sensitive information like private keys or IP addresses.


# 10.1 Frequently Asked Questions

***Q: How much do I need to stake to become a validator?*** \
A: The minimum stake requirement is determined by network governance and may change. Check the current requirements on our website or Discord.

***Q: What happens if my node goes offline?*** \
A: Short periods of downtime may result in missed rewards. Extended downtime could lead to slashing of your stake.

***Q: How can I improve my chances of detecting fraud?*** \
A: Ensure your node is always up-to-date, well-maintained, and has sufficient resources to process transactions quickly. Stay informed about potential attack vectors and regularly check for any suspicious activity.


# 10.2 Community Support

* Join our [Discord server](https://discord.gg/spicenet) for community support
* Follow us on [Twitter](https://twitter.com/SpicenetOfficial) for updates
* Report issues on our [GitHub repository](https://github.com/pepper-research/spicenet)


