Sahara Blockchain Validator Guide

This comprehensive guide provides detailed instructions for setting up and operating a validator node on the Sahara Blockchain network. Validators play a critical role in securing the network through our Tendermint-based Proof of Stake consensus mechanism.

Initial Validator Set

The initial validator set for Sahara will comprise professional node operators and established institutions with demonstrated experience in blockchain infrastructure management. This model prioritizes network stability and security during the critical early phases of the network.

Selected validators must meet rigorous criteria including:

• Proven track record in validator operations

• Substantial technical infrastructure and security capabilities

• 24/7 operational monitoring and support

• Geographic distribution for network resilience

• Strong institutional reputation and accountability

Role of Validators

Validators on the Sahara Blockchain are responsible for:

1. Block Production: Proposing new blocks and validating transactions

2. Network Security: Staking SAHARA tokens as collateral for honest operation

3. Transaction Finality: Ensuring rapid and definitive transaction confirmation

4. Network Governance: Participating in on-chain governance decisions

Validators earn rewards for these essential functions while risking their staked tokens through a slashing mechanism that penalizes malicious or negligent behavior.

Phased Decentralization Plan

As the network matures and demonstrates consistent stability, Sahara will implement a phased transition toward a fully permissionless validator set. This gradual approach ensures that decentralization occurs without compromising network security or performance.

Phase 1: Professional Node Operators

• Limited set of experienced professional validators

• Focus on network stability and security

• Implementation of monitoring and performance metrics

Phase 2: Expanded Participation

• Introduction of additional qualified validators

• Establishment of clear performance requirements

• Development of robust slashing conditions

Phase 3: Permissionless Operation

• Open validator participation with stake requirements

• Full implementation of economic security measures

• Community governance of network parameters

This measured approach to validator decentralization aligns with Sahara's vision of creating a robust, decentralized infrastructure for AI development while ensuring the network maintains the highest standards of security and reliability throughout its evolution.

Validator Requirements

Hardware Specifications

Minimum Requirements (Testnet):

• CPU: 8 cores, preferably Intel Xeon or AMD EPYC

• RAM: 32GB

• Storage: 2TB NVMe SSD

• Network: 100Mbps symmetric connection, unlimited data

Recommended Production Requirements:

• CPU: 32 cores, Intel Xeon or AMD EPYC

• RAM: 128GB ECC memory

• Storage: 8TB NVMe SSD (RAID configuration recommended)

• Network: 1Gbps symmetric connection, unlimited data

• Backup Power: UPS and redundant power

System Requirements

• Operating System: Ubuntu 22.04 LTS (recommended)

• Docker v24.0.0 or later

• Properly configured firewall

• SSH access restricted to key authentication

Staking Requirements

For the testnet phase, validators need a minimum stake of 1000 SAHARA test tokens.

Initial Setup

Server Preparation

Here we suggest a setup using docker, you can adjust to your preferred method..

• Setup a Linux server with docker installed.

• Install the jq command line tool.

It’s used by some commands we showed later. It's not required since you can use other alternative commands.

• Pull sahara docker image from [TBD]

Configuration

You can get an example configuration from: https://github.com/SaharaLabsAI/setup-testnet-node .

Configure Your Node

Edit the following files to customize your node configuration

# adjust related seetings

chain-data/config/config.toml:

#
moniker = "your-name"
# Set proper external IP (replace with your server's public IP)
external_address = "tcp://<your-public-ip>:26656"

# Configure P2P settings
max_num_inbound_peers = 100
max_num_outbound_peers = 40


# For validators we recommend use state sync to restore application state to the latest state. So the validator node can be up in a short time(1-2hours)
[satesync]
enable = true
rpc_servers = "https://testnet-cos-rpc1.saharalabs.ai,https://testnet-rpc2.saharalabs.ai"
trust_height = # set it to the latest height
trust_hash = "" # the hash could be fetch using cli
# curl https://testnet-cos-rpc1.saharalabs.ai/commit?height={blockHeight} | jq '.result.signed_header.commit.block_id.hash'`
trust_period = "168h0m0s"

Node Operation

Start Your Node

docker compose up -d 

Sync Your Node

Monitor the sync status of your node:

docker compose logs -f –tail 10 |grep finalize

Your node must be fully synced to the latest block before proceeding

Create Validator

First, create a wallet and obtain testnet tokens:

# Create a new wallet key
saharad keys add <your-key-name>

# Or recover an existing wallet
saharad keys add <your-key-name> --recover

Visit the Sahara Tesnet Faucet at https://faucet.saharalabs.ai/ to request test tokens.

Once your node is synced and you have test tokens, create your validator:

Prepare the validator-info.jason file:

cat validator-info.json
{
        "pubkey": {"@type":"/cosmos.crypto.ed25519.PubKey","key":"{your validator key}"},
        "amount": "100000000000000000000usah",
        "moniker": "validator-name",
        "identity": "optional identity signature (ex. UPort or Keybase)",
        "website": "validator's (optional) website",
        "security": "validator's (optional) security contact email",
        "details": "validator's (optional) details",
        "commission-rate": "0.1",
        "commission-max-rate": "0.2",
        "commission-max-change-rate": "0.01",
        "min-self-delegation": "100"
}

saharad tx staking create-validator ./validator-info.json --chain-id=sahara-test-1    --gas="auto"  --gas-prices="100000000000usah" --keyring-backend test  --from {your-validator-key-name}

Verify Your Validator

Check that your validator is active:

# View your validator details
saharad query staking validator $(saharad keys show <your-key-name> --bech=val -a)

# Check if your validator is in the active set
saharad query tendermint-validator-set | grep $(saharad tendermint show-validator)

Backup Procedures

It’s recommended to perform disk backup using snapshots. You can also backup the data directory of your node. Please keep in mind the keys folder should be stripped before sending the backup to other parties.

Upgrade Procedures

When network upgrades are announced, follow these steps:

1. Join the Sahara validator Slack and Discord channels for upgrade announcements

2. Download and compile the new binary before the upgrade height

3. Test the new binary on a testnet node if possible

4. Prepare for the upgrade by backing up your data

5. When the upgrade height is reached, stop your node, replace the binary, and restart

Security Best Practices

Server Security

• Keep your node private and only open necessary ports

• Backup your data

• Setup firewall rules to block suspicious connections

Key Management

Use an HSM or hardware wallet (e.g., Ledger) for managing validator keys in production environments.

For testing environments:

• Keep your mnemonic backup offline and secure

• Use a dedicated machine for key management

• Never share your private keys or mnemonic phrase

Sentry Node Architecture

For enhanced security on mainnet, implement a sentry node architecture:

1. Set up multiple sentry nodes that connect to the public network

2. Configure your validator to only connect to your sentry nodes

3. Keep your validator node behind a firewall, inaccessible from the public internet

FAQ

Q: What is the minimum stake required to become a validator?

A: During the testnet phase, the minimum self-delegation is 1000 SAHARA test tokens. For mainnet, this requirement will be higher and announced before launch.

Q: How are rewards distributed?

A: Validator rewards are distributed automatically at the end of each block. You can claim your rewards manually using the saharad tx distribution withdraw-rewards command.

Q: What happens if my validator goes offline?

A: If your validator misses a significant number of blocks (currently set at 10,000 blocks, approximately 14 hours), it will be "jailed" and removed from the active set. You’ll need to submit an unjail transaction.

Q: How can I increase my chances of being selected to produce blocks?

A: Block production opportunities are proportional to your total stake (self-delegated plus delegated tokens). Increasing your stake and maintaining reliable infrastructure improves your chances.

Q: Can I change my commission rate after creating my validator?

A: Yes, you can adjust your commission rate within the limits specified during validator creation. The commission-max-change-rate parameter defines how much you can change it per 24-hour period.

Q: How do I backup my validator private keys?

A: Your validator consensus key is stored in ~/.sahara/config/priv_validator_key.json. Back up this file securely. For your operator key (used for transactions), securely store the mnemonic phrase generated when you created the key.

---

For additional support, join our validator community channels on Slack or reach out to the Sahara BD team via the official communication channels.

Preview: Working with AI Assets

⚠️ Important Notice: The following code examples and interfaces are previews of planned functionality for the Sahara Protocol. These contracts are under active development, have not been audited, and are not ready for production use. The final implementation may differ significantly from these examples.

Overview of AI Asset Management

The Sahara Protocol introduces a comprehensive framework for managing AI assets on-chain. This preview demonstrates how developers will be able to interact with different types of AI assets through our smart contract interfaces and SDK.

Asset Types and Registration

The protocol recognizes three fundamental types of AI assets, each with specific metadata requirements and relationship capabilities:

• Datasets represent structured collections of training, validation, or testing data. These form the foundation of AI model development and carry specific metadata about data composition, collection methods, and usage rights.

• Models encompass both base models and their derivatives. The protocol maintains clear lineage between models and their training data, ensuring proper attribution and revenue distribution.

• Pipelines represent complex AI workflows that may combine multiple models and datasets. These assets can capture sophisticated processing chains while maintaining clear provenance.

Example: Asset Registration

Here's a preview of how asset registration might work in the protocol:

// PREVIEW - Interface subject to change
interface IAIAssetRegistry {
    struct AssetMetadata {
        string name;
        string description;
        AssetType assetType;
        address creator;
        uint256 creationDate;
        bytes32 contentHash;
    }

    function registerAsset(
        AssetMetadata memory metadata
    ) external returns (uint256 assetId);
}

Example: Relationship Tracking

The protocol will maintain clear relationships between AI assets:

// PREVIEW - Interface subject to change
enum RelationType {
    TRAINED_ON,      // Links model to training data
    FINETUNED_FROM,  // Tracks model lineage
    DERIVED_FROM,    // General derivation
    GENERATED_BY     // Links outputs to models
}

Example: Licensing and Revenue

Preview of the licensing interface:

// PREVIEW - Interface subject to change
interface ILicenseManager {
    struct LicenseTerms {
        bool commercialUse;
        bool derivativesAllowed;
        uint256 royaltyRate;
        uint256 duration;
    }

    function createLicense(
        uint256 assetId,
        LicenseTerms memory terms
    ) external returns (uint256 licenseId);
}

Future SDK Integration

The protocol will include a comprehensive SDK for deploying and managing AI assets:

// PREVIEW - SDK interface subject to change
const sahara = require('@sahara/sdk');

async function deployModel(modelId, config) {
    const deployment = await sahara.deploy.model({
        modelId: modelId,
        resources: {
            cpu: "4",
            memory: "16Gi",
            gpu: "1"
        },
        scaling: {
            minReplicas: 1,
            maxReplicas: 5
        }
    });
   
    return deployment.endpoint;
}

Next Steps

We encourage developers to:

1. Review these example interfaces to understand our planned functionality

2. Join our Discord to provide feedback on the proposed design

3. Follow our GitHub repository for updates as we move toward testnet release

4. Sign up for our developer newsletter for announcements about preview releases

Remember: These examples represent planned functionality and will evolve significantly before production release. We're sharing them to give developers early insight into how the protocol will work and to gather community feedback during the development process.