DOCSEARCHbyAlgolia
Submit Docs

snarkOS Documentation

repository·staging·Indexed 26 days ago

https://github.com/provablehq/snarkos

A decentralized operating system for zero-knowledge applications and the backbone of the Aleo network. Version 4.8.1. It handles transaction verification, encrypted state storage, and BFT-based consensus. The project includes crates for account management (snarkos-account), CLI interaction (snarkos-cli), node display (snarkos-display), and a BFT node architecture featuring a memory pool, ledger services, and a rate-limiting consensus mempool.

Tokens
24.4K
Snippets
38
Records
203
Agent score
85%

What's inside snarkos

  4. Overview of snarkos-node-network

    staging

    The snarkos-node-network crate provides the networking foundation for snarkOS nodes. It is responsible for:

    • Peer Discovery: Finding other nodes in the network.
    • Connection Management: Handling active connections between peers.
    • Peer Pool Coordination: Managing the collection of available peers.
    • Bootstrap Peers: Facilitating initial connections via known bootstrap nodes.
    • Node Role Identification: Determining the role of a peer within the network.
    • Address Resolution: Resolving network addresses for peers.

  5. Overview of snarkos-utilities

    staging

    The snarkos-utilities crate provides shared primitives for building Aleo-related node components. It focuses on two main areas:

    1. Signal and Shutdown Handling: Provides primitives like SignalHandler, SimpleStoppable, and Stoppable to manage graceful shutdowns and system signals.
    2. Node Data Directory Management: Provides NodeDataDir to assist in locating node-specific configuration files, such as peer caches and proposal caches.

  8. Understand the snarkos-node-bft Primary role and Round Advancement

    staging

    The snarkos-node-bft crate implements a BFT-based memory pool. The Primary acts as a coordinator responsible for advancing rounds and broadcasting the anchor.

    Round advancement follows the Bullshark protocol and occurs once a quorum (n - f) of validators have submitted certificates for that round, subject to these conditions:

    • Even rounds: The elected leader's certificate must be present in the quorum. If absent, the node waits up to MAX_LEADER_CERTIFICATE_DELAY (currently 5 seconds) before advancing without it.
    • Odd rounds: Either at least f + 1 certificates from the current round must reference the previous even round's leader certificate (availability threshold), or n - f certificates must not (non-leader quorum). If neither is met, the node falls back to the MAX_LEADER_CERTIFICATE_DELAY timeout.

  9. Understand Block Locators in snarkos-node-sync-locators

    staging

    The snarkos-node-sync-locators crate provides block locators, which are data structures used by nodes to advertise the blocks they possess to other nodes. This facilitates blockchain synchronization across the network.

    Block Locator Structure

    A single block locator consists of:

    • Block Height: The position in the blockchain (starting at 0 for the genesis block).
    • Block Hash: A hash used to verify consistency among locators from different nodes.

    BlockLocators Collection

    The BlockLocators struct organizes multiple locators into two distinct maps:

    1. checkpoints: A map of block heights to block hashes.
    2. recents: A map of block heights to block hashes.

    This crate also provides functionality to:

    • Construct block locators.
    • Validate locators for well-formedness and consistency.
    • Serialize and deserialize locators to and from bytes.

  10. Understand the snarkos-node-consensus mempool architecture

    staging

    The snarkos-node-consensus crate manages a rate-limiting mempool for incoming transmissions (solutions or transactions) and constructs blocks from batches confirmed by the BFT layer. It uses a two-tier architecture to prevent overloading BFT workers:

    Tier 1: Consensus Inbound Queues

    Incoming transmissions are first placed in inbound queues where they are checked for duplicates but not fully verified:

    • Solutions Queue: An LRU cache (capacity: 1024).
    • Transactions Queue: Separate queues for deployments (capacity: 1024) and executions (capacity: 1024), both using priority sub-queues based on priority fees.

    Tier 2: Worker Ready Queues

    The BFT layer uses multiple workers, each with its own ready queue. Transmissions in this queue are verified and ready for batch proposals.

    Transmission Movement

    Consensus periodically (every MAX_BATCH_DELAY_IN_MS) moves transmissions from inbound queues to workers if:

    1. Workers have capacity (less than MAX_TRANSMISSIONS_TOLERANCE unconfirmed transmissions).
    2. The transmission is assigned to a worker via its ID hash.
    3. The worker successfully verifies the transmission (using check_solution_basic() for solutions or check_transaction_basic() for transactions).

  11. Use snarkos-node-router-messages for router message types

    staging
    The snarkos-node-router-messages crate defines the specific message types required for communication within the snarkos-node-router crate. Developers building or extending components that interact with the snarkos-node-router should use this crate to ensure message compatibility.