Skip to content

Commit 2a611f9

Browse files
committed
SNARK library: document with top-level comments
1 parent 3cee64a commit 2a611f9

File tree

6 files changed

+223
-0
lines changed

6 files changed

+223
-0
lines changed

snark/src/block_verify/mod.rs

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,34 @@
1+
//! # Block Verification State Machine
2+
//!
3+
//! This module implements the state machine for verifying blockchain block proofs
4+
//! within the Mina protocol. It manages the lifecycle of block verification requests
5+
//! and maintains verification state.
6+
//!
7+
//! ## Overview
8+
//!
9+
//! Block verification ensures that:
10+
//! - Block proofs are cryptographically valid
11+
//! - Block headers contain correct consensus information
12+
//! - Blockchain state transitions are legitimate
13+
//!
14+
//! ## State Machine
15+
//!
16+
//! The block verification process follows these states:
17+
//! - **Idle**: Ready to accept new verification requests
18+
//! - **Pending**: Verification in progress
19+
//! - **Success**: Block successfully verified
20+
//! - **Error**: Verification failed with error details
21+
//!
22+
//! ## Usage
23+
//!
24+
//! Block verification is typically initiated by:
25+
//! - Consensus mechanisms validating incoming blocks
26+
//! - Sync processes verifying historical blocks
27+
//! - Fork resolution comparing competing chains
28+
//!
29+
//! The verification process runs asynchronously in service threads to avoid
30+
//! blocking the main state machine.
31+
132
mod snark_block_verify_state;
233
pub use snark_block_verify_state::*;
334

snark/src/block_verify_effectful/mod.rs

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,31 @@
1+
//! # Block Verification Service Layer
2+
//!
3+
//! This module provides the effectful (side-effect) operations for block verification,
4+
//! separating the heavy cryptographic computations from the main state machine logic.
5+
//!
6+
//! ## Architecture Separation
7+
//!
8+
//! This effectful layer handles:
9+
//! - **Asynchronous Operations**: CPU-intensive proof verification
10+
//! - **Service Interactions**: Integration with verification backends
11+
//! - **Thread Management**: Non-blocking execution of verification tasks
12+
//! - **Error Handling**: Detailed verification failure reporting
13+
//!
14+
//! ## Service Interface
15+
//!
16+
//! The [`SnarkBlockVerifyService`] trait defines the interface for:
17+
//! - Initiating block verification requests
18+
//! - Receiving verification results via callbacks
19+
//! - Managing verification queue and priorities
20+
//!
21+
//! ## Integration Pattern
22+
//!
23+
//! The effectful pattern ensures that:
24+
//! 1. State machine remains deterministic and pure
25+
//! 2. Heavy computations don't block the main thread
26+
//! 3. Verification results flow back through events
27+
//! 4. System stays responsive during proof verification
28+
129
mod snark_block_verify_effectful_actions;
230
pub use snark_block_verify_effectful_actions::*;
331

snark/src/lib.rs

Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,75 @@
1+
//! # SNARK Verification Orchestration
2+
//!
3+
//! The SNARK crate provides zero-knowledge proof verification capabilities for the Mina Rust node,
4+
//! orchestrating the verification of blocks, transactions, and SNARK work through a Redux-style
5+
//! state machine architecture.
6+
//!
7+
//! ## Overview
8+
//!
9+
//! This crate handles three main types of proof verification:
10+
//! - **Block Verification**: Validates blockchain blocks and their proofs
11+
//! - **Transaction Verification**: Verifies user commands and zkApp transactions
12+
//! - **Work Verification**: Validates SNARK work proofs from workers
13+
//!
14+
//! ## Architecture
15+
//!
16+
//! The crate follows the Mina node's Redux architecture pattern with:
17+
//! - **State**: [`SnarkState`] - Centralized verification state
18+
//! - **Actions**: [`SnarkAction`] - Events triggering verification operations
19+
//! - **Enabling Conditions**: [`redux::EnablingCondition`] - Guards preventing invalid state transitions
20+
//! - **Reducers**: Pure functions managing state transitions
21+
//! - **Effects**: Service interactions for actual proof verification
22+
//!
23+
//! ## Core Components
24+
//!
25+
//! ### Verification State Machine
26+
//!
27+
//! Each verification type maintains its own state machine:
28+
//! - [`block_verify`] - Block proof verification state machine
29+
//! - [`user_command_verify`] - User command verification state machine
30+
//! - [`work_verify`] - SNARK work verification state machine
31+
//!
32+
//! ### Effectful Operations
33+
//!
34+
//! Heavy cryptographic operations run in separate service threads:
35+
//! - [`block_verify_effectful`] - Block verification services
36+
//! - [`user_command_verify_effectful`] - Transaction verification services
37+
//! - [`work_verify_effectful`] - Work verification services
38+
//!
39+
//! ## Configuration
40+
//!
41+
//! The [`SnarkConfig`] contains verifier indices and SRS (Structured Reference String)
42+
//! parameters required for proof verification. These are network-specific and loaded
43+
//! during initialization.
44+
//!
45+
//! ## Integration
46+
//!
47+
//! The SNARK crate integrates with:
48+
//! - **Ledger**: Uses cryptographic primitives from the ledger crate
49+
//! - **Kimchi**: Leverages the Kimchi proving system for verification
50+
//! - **Node**: Provides verification services to the main node
51+
//!
52+
//! ## Example Usage
53+
//!
54+
//! ```rust,no_run
55+
//! use snark::{SnarkConfig, SnarkState};
56+
//!
57+
//! // Initialize SNARK state with configuration
58+
//! let config = SnarkConfig { /* ... */ };
59+
//! let state = SnarkState::new(config);
60+
//!
61+
//! // The state machine handles verification requests through actions
62+
//! // dispatched by the main node's Redux store
63+
//! ```
64+
//!
65+
//! ## Performance Considerations
66+
//!
67+
//! - Proof verification is CPU-intensive and runs asynchronously
68+
//! - Verifier indices and SRS parameters are cached for reuse
69+
//! - Multiple verification operations can run concurrently
70+
//!
71+
//! For detailed API documentation, see the individual module documentation.
72+
173
use kimchi::mina_curves::pasta::Vesta;
274

375
mod merkle_path;

snark/src/merkle_path/mod.rs

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,27 @@
1+
//! # Merkle Path Verification Utilities
2+
//!
3+
//! This module provides utilities for computing and verifying Merkle tree paths,
4+
//! which are essential for account existence proofs in the Mina ledger.
5+
//!
6+
//! ## Overview
7+
//!
8+
//! Merkle paths enable:
9+
//! - **Account Verification**: Proving an account exists in the ledger
10+
//! - **State Consistency**: Validating ledger state transitions
11+
//! - **Efficient Proofs**: Compact proofs of inclusion without full ledger
12+
//!
13+
//! ## Key Function
14+
//!
15+
//! [`calc_merkle_root_hash`] computes the root hash from an account and its Merkle path,
16+
//! allowing verification that the account is part of a specific ledger state.
17+
//!
18+
//! ## Usage in Verification
19+
//!
20+
//! This is commonly used in:
21+
//! - Transaction verification (ensuring account exists)
22+
//! - SNARK proof generation (ledger state proofs)
23+
//! - Account state validation in zkApps
24+
125
use ark_ff::fields::arithmetic::InvalidBigInt;
226
use mina_p2p_messages::{bigint::BigInt, v2::MerkleTreeNode};
327
use poseidon::hash::params::get_merkle_param_for_height;

snark/src/user_command_verify/mod.rs

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,34 @@
1+
//! # User Command Verification State Machine
2+
//!
3+
//! This module handles the verification of user commands and zkApp transactions
4+
//! within the Mina protocol. It manages cryptographic proof validation for
5+
//! transactions before they are included in blocks.
6+
//!
7+
//! ## Overview
8+
//!
9+
//! User command verification validates:
10+
//! - **Payment transactions**: Simple value transfers between accounts
11+
//! - **Delegation commands**: Stake delegation operations
12+
//! - **zkApp transactions**: Complex smart contract interactions with zero-knowledge proofs
13+
//!
14+
//! ## Verification Process
15+
//!
16+
//! The verification process includes:
17+
//! - Signature validation for transaction authorization
18+
//! - Proof verification for zkApp transactions
19+
//! - Account state consistency checks
20+
//! - Fee and nonce validation
21+
//!
22+
//! ## Performance
23+
//!
24+
//! Transaction verification is batched for efficiency:
25+
//! - Multiple transactions verified concurrently
26+
//! - Failed verifications reported with detailed errors
27+
//! - Successful transactions forwarded to the transaction pool
28+
//!
29+
//! This module is critical for maintaining network security by ensuring
30+
//! only valid transactions are propagated and included in blocks.
31+
132
mod snark_user_command_verify_state;
233
pub use snark_user_command_verify_state::*;
334

snark/src/work_verify/mod.rs

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,40 @@
1+
//! # SNARK Work Verification State Machine
2+
//!
3+
//! This module manages the verification of SNARK work proofs submitted by
4+
//! external SNARK workers. It validates computational work that helps maintain
5+
//! the blockchain's security and scalability.
6+
//!
7+
//! ## Overview
8+
//!
9+
//! SNARK work verification handles:
10+
//! - **Transaction SNARK proofs**: Proofs for transaction validity
11+
//! - **Merge proofs**: Proofs combining multiple transaction proofs
12+
//!
13+
//! ## SNARK Worker Ecosystem
14+
//!
15+
//! The Mina protocol relies on a decentralized network of SNARK workers who:
16+
//! - Compute zero-knowledge proofs for transactions
17+
//! - Submit completed work to block producers
18+
//! - Receive fees for successful proof generation
19+
//!
20+
//! ## Verification Pipeline
21+
//!
22+
//! Work verification follows this process:
23+
//! 1. **Reception**: SNARK work received from workers or peers
24+
//! 2. **Validation**: Cryptographic proof verification
25+
//! 3. **Integration**: Valid work added to the SNARK pool
26+
//! 4. **Rewards**: Workers compensated for successful work
27+
//!
28+
//! ## Economic Incentives
29+
//!
30+
//! This module supports the economic model where:
31+
//! - SNARK workers are paid fees for valid proofs
32+
//! - Invalid work is rejected without compensation
33+
//! - The network maintains decentralized proof generation
34+
//!
35+
//! The verification process is essential for Mina's scalability, enabling
36+
//! the blockchain to maintain constant size regardless of transaction volume.
37+
138
mod snark_work_verify_state;
239
pub use snark_work_verify_state::*;
340

0 commit comments

Comments
 (0)