casper-node Documentation

repository·dev·Indexed 19 days ago

https://github.com/casper-network/casper-node

The reference implementation of the Casper Blockchain Protocol. This repository contains the core logic for running validator nodes, managing consensus, and handling network communication. It includes components such as the casper-execution-engine for Wasm runtime, casper-storage for the persistent data layer, and the casper-contract library for developing no_std smart contracts.

Tokens
87.8K
Snippets
264
Records
346
Agent score
63%

What's inside casper-node

  1. Use global-state-update-gen for emergency state updates

    dev

    global-state-update-gen is a tool used to generate files for manual global state changes in the event of a catastrophic network failure where normal deploys are impossible. It allows for applying changes via social consensus during an emergency upgrade.

    Common Parameters

    All subcommands support these flags:

    • -d, --data-dir: Path to the node's data directory (containing storage and global state database).
    • -s, --state-hash: The root hash of the global state to use as the base (typically the state root hash from the last block before the upgrade).
    • -h, --help: Prints help information.
  2. What is casper-validation?

    dev
    casper-validation is an automation tool designed to validate code by loading JSON fixtures. Each fixture contains a specific input and the expected output resulting from applying a particular operation. The tool ensures that the code's actual output matches the expected output defined in the fixture.
  3. Use `casper-types` in `no_std` environments

    dev

    The casper-types crate provides core types shared across the Casper network. It is designed to be compatible with no_std environments by using only the core and alloc crates.

    By default, the crate operates in no_std mode. However, enabling specific features will introduce dependencies that may affect compatibility with strict no_std environments:

    /* Default behavior is no_std using core and alloc */
  4. Understand the Binary Port Protocol communication model

    dev

    The Binary Port Protocol is a binary communication protocol used for interacting with Casper nodes. It operates over a long-lived TCP connection using a request-response model.

    Key constraints:

    • Sequentiality: You must not send a second request before receiving the complete response to the first request on a single TCP connection.
    • Envelopes: Both requests and responses are wrapped in envelopes containing metadata.
    • Versioning: The protocol uses versioning. The current supported version for both requests and responses is 1.
  5. Understand the resource categories for node-rs

    dev

    The node-rs project organizes its resource artifacts into three distinct categories based on the intended environment:

    • test: Artifacts used specifically by test fixtures.
    • production: Artifacts intended for use with released software.
    • local: Artifacts used when running a node outside of a production environment, typically for local development or testing.
  6. How the Faucet distribution mechanism works

    dev

    The faucet distributes tokens based on a ratio of the available_amount to the distributions_per_interval (referred to in logic as max_distributions_per_interval).

    Example Calculation:

    • Setup: available_amount = 100_000_000 motes; distributions_per_interval = 2.
    • User 1 Call: Receives 50_000_000 motes. Remaining: 50_000_000.
    • User 2 Call: Receives 50_000_000 motes. Remaining: 0.
    • User 3 Call: Receives 0 motes (no tokens available).

    Important Constraints:

    • distributions_per_interval, available_amount, and time_interval must all be greater than 0.
    • Calling the contract before set_variables has been executed will result in an error.