DOCSEARCHbyAlgolia
Submit Docs

librustzcash

repository·main·Indexed 19 days ago

https://github.com/zcash/librustzcash

A collection of Rust crates providing low-level and high-level primitives for interacting with the Zcash protocol. It includes tools for transaction construction (including PCZT), address management, wallet backend frameworks, and protocol constants. Key components include zcash_protocol, zcash_client_backend, zcash_keys, and zcash_address. Note: These crates cannot be used to verify Zcash consensus validity; a Zcash consensus node must be used for that purpose.

Tokens
65.3K
Snippets
199
Records
330
Agent score
64%

What's inside librustzcash

  1. Overview of Light Wallet Protocol implementations

    main

    The Zcash Light Wallet protocol is implemented across various servers and clients. Use these references to find compatible software or existing libraries:

    Servers

    • Lightwalletd (Go): A common server implementation.
    • Zaino (Rust): A Rust-based server implementation.

    Clients

    CLI and Dev Tooling

    • Zingo Lib CLI (Rust)
    • Zcash dev-tool (Rust)
    • zcash_client_backend (Rust crate)

    Light Wallets

  3. Overview of zcash_history Merkle Mountain Ranges (MMR)

    main

    The zcash_history crate provides a specialized implementation of Merkle Mountain Ranges (MMR) designed specifically for Zcash.

    Key design characteristics include:

    • Zero-cache and minimal DB callbacks: The implementation avoids internal caching. Instead, the calling side is responsible for pre-loading MMR nodes from the database. For an append operation, the caller should pre-load approximately log2(tree length) nodes; for a deletion, approximately twice that amount.
    • Cross-language logic reuse: It is designed to share logic between Rust and C++ clients within the librustzcash ecosystem.
    • Low memory footprint: The implementation aims for close to zero memory consumption.

  6. What is the pczt library?

    main
    The pczt library implements the Partially Created Zcash Transaction (PCZT) format. This format allows the logical steps of creating a Zcash transaction to be distributed across different entities. The entity roles in PCZT are inspired by Bitcoin's BIP 174 (Partially Signed Bitcoin Transaction) and BIP 370 (PSBT Version 2), but include additional roles specific to the Zcash protocol.

  7. Overview of the zcash crate

    main
    The zcash crate serves as a top-level entry point that re-exports APIs from various specialized crates within the librustzcash ecosystem. Because it is a re-export crate, its API surface is subject to significant changes in future releases. Developers should look to the specific sub-crates (such as zcash_address, zcash_encoding, or zcash_protocol) for stable, granular functionality.

  9. Overview of librustzcash Crates

    main

    The librustzcash repository is a collection of Rust crates for working with the Zcash protocol. The crates are organized into several functional groups:

    Zcash Protocol

    • zcash_protocol: Provides constants, common types, consensus parameters, bounded value types (Zatoshis, ZatBalance), and memo types.
    • zcash_transparent: Contains Bitcoin-derived transparent transaction components, including transparent addresses and support for transparent parts of PCZT construction.
    • zcash_primitives: Core utilities for transaction handling, including the primary transaction data type, transaction builders, proving, signing, serialization, and low-level fee types.
    • zcash_proofs: Implements the Sprout circuit and proving system.

    Keys, Addresses & Wallet Support

    • zcash_address: Handles parsing and serialization of Zcash addresses (unified, fvk, and ivk containers) without protocol-specific dependencies.
    • zip321: Handles parsing and serialization for ZIP 321 payment requests.
    • zcash_keys: Manages Spending Keys, Viewing Keys, and Addresses, including protocol-specific, Unified, and Sapling types, as well as ZIP 32 key/address derivation.
    • pczt: Provides data types and interfaces for Partially Constructed Transaction (PCZT) construction.
    • zcash_client_backend: A wallet framework providing storage APIs, chain scanning, light client protocol support, fee calculation, and high-level transaction construction.
    • zcash_client_sqlite: An implementation of zcash_client_backend using SQLite for storage.
    • zcash_pool_migration: A backend-agnostic engine for migrating funds between value pools (e.g., Orchard → Ironwood), handling note-split planning and migration scheduling.

    Utilities & Common Dependencies

    • f4jumble: Encoding for Unified addresses.
    • zcash_encoding: Bitcoin-derived transaction encoding utilities.
    • equihash: Implementation of the Proof-of-Work protocol.
    • zcash_history: Implements the ZIP 221 Merkle Mountain Range over per-block metadata, used for FlyClient proofs.

  10. Overview of zcash_proofs

    main

    The zcash_proofs crate provides the implementation of the Sprout zk-SNARK circuit and the necessary APIs for creating and verifying Sprout proofs.

    Note on Sapling: This crate does not define Sapling circuits. Sapling circuits have been moved to the sapling-crypto crate. While zcash_proofs retains helpers for loading Sapling proving parameters from disk, it no longer contains the circuit definitions themselves.

  12. Overview of the zcash_pool_migration engine

    main

    The zcash_pool_migration crate provides a backend-agnostic engine designed to migrate Zcash wallet funds between different value pools (such as the Orchard to Ironwood migration).

    Key capabilities include:

    • Planning: Splitting notes into self-funding denominations.
    • Transaction Construction: Building and signing migration transactions as PCZTs.
    • Scheduling: Organizing transactions by block height.
    • State Management: Persisting migration state through a wallet backend.

    Note for Integrators: The engine handles the planning and signing logic, but the consuming application is responsible for broadcasting the resulting transactions and reporting the outcomes.