|
| 1 | +# CLAUDE.md |
| 2 | + |
| 3 | +This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. |
| 4 | + |
| 5 | +## Project Overview |
| 6 | + |
| 7 | +**dash-spv** is a Rust implementation of a Dash SPV (Simplified Payment Verification) client library built on top of the `dashcore` library. It provides a modular, async/await-based architecture for connecting to the Dash network, synchronizing blockchain data, and monitoring transactions. |
| 8 | + |
| 9 | +## Architecture |
| 10 | + |
| 11 | +The project follows a layered, trait-based architecture with clear separation of concerns: |
| 12 | + |
| 13 | +### Core Modules |
| 14 | +- **`client/`**: High-level client API (`DashSpvClient`) and configuration (`ClientConfig`) |
| 15 | +- **`network/`**: TCP connections, handshake management, message routing, and peer management |
| 16 | +- **`storage/`**: Storage abstraction with memory and disk backends via `StorageManager` trait |
| 17 | +- **`sync/`**: Synchronization coordinators for headers, filters, and masternode data |
| 18 | +- **`validation/`**: Header validation, ChainLock, and InstantLock verification |
| 19 | +- **`wallet/`**: UTXO tracking, balance calculation, and transaction processing |
| 20 | +- **`types.rs`**: Common data structures (`SyncProgress`, `ValidationMode`, `WatchItem`, etc.) |
| 21 | +- **`error.rs`**: Unified error handling with domain-specific error types |
| 22 | + |
| 23 | +### Key Design Patterns |
| 24 | +- **Trait-based abstractions**: `NetworkManager`, `StorageManager` for swappable implementations |
| 25 | +- **Async/await throughout**: Built on tokio runtime |
| 26 | +- **State management**: Centralized sync coordination with `SyncState` and `SyncManager` |
| 27 | +- **Modular validation**: Configurable validation modes (None/Basic/Full) |
| 28 | + |
| 29 | +## Development Commands |
| 30 | + |
| 31 | +### Building and Running |
| 32 | +```bash |
| 33 | +# Build the library |
| 34 | +cargo build |
| 35 | + |
| 36 | +# Run the SPV client binary |
| 37 | +cargo run --bin dash-spv -- --network mainnet --data-dir ./spv-data |
| 38 | + |
| 39 | +# Run with custom peer |
| 40 | +cargo run --bin dash-spv -- --peer 192.168.1.100:9999 |
| 41 | + |
| 42 | +# Run examples |
| 43 | +cargo run --example simple_sync |
| 44 | +cargo run --example filter_sync |
| 45 | +``` |
| 46 | + |
| 47 | +### Testing |
| 48 | + |
| 49 | +**Unit and Integration Tests:** |
| 50 | +```bash |
| 51 | +# Run all tests |
| 52 | +cargo test |
| 53 | + |
| 54 | +# Run specific test files |
| 55 | +cargo test --test handshake_test |
| 56 | +cargo test --test header_sync_test |
| 57 | +cargo test --test storage_test |
| 58 | +cargo test --test integration_real_node_test |
| 59 | + |
| 60 | +# Run individual test functions |
| 61 | +cargo test --test handshake_test test_handshake_with_mainnet_peer |
| 62 | + |
| 63 | +# Run tests with output |
| 64 | +cargo test -- --nocapture |
| 65 | + |
| 66 | +# Run single test with debug output |
| 67 | +cargo test --test handshake_test test_handshake_with_mainnet_peer -- --nocapture |
| 68 | +``` |
| 69 | + |
| 70 | +**Integration Tests with Real Node:** |
| 71 | +The integration tests in `tests/integration_real_node_test.rs` connect to a live Dash Core node at `127.0.0.1:9999`. These tests gracefully skip if no node is available. |
| 72 | + |
| 73 | +```bash |
| 74 | +# Run real node integration tests |
| 75 | +cargo test --test integration_real_node_test -- --nocapture |
| 76 | + |
| 77 | +# Test specific real node functionality |
| 78 | +cargo test --test integration_real_node_test test_real_header_sync_genesis_to_1000 -- --nocapture |
| 79 | +``` |
| 80 | + |
| 81 | +See `run_integration_tests.md` for detailed setup instructions. |
| 82 | + |
| 83 | +### Code Quality |
| 84 | +```bash |
| 85 | +# Check formatting |
| 86 | +cargo fmt --check |
| 87 | + |
| 88 | +# Run linter |
| 89 | +cargo clippy --all-targets --all-features -- -D warnings |
| 90 | + |
| 91 | +# Check all features compile |
| 92 | +cargo check --all-features |
| 93 | +``` |
| 94 | + |
| 95 | +## Key Concepts |
| 96 | + |
| 97 | +### Sync Coordination |
| 98 | +The `SyncManager` coordinates all synchronization through a state-based approach: |
| 99 | +- Header sync via `HeaderSyncManager` |
| 100 | +- Filter header sync via `FilterSyncManager` |
| 101 | +- Masternode list sync via `MasternodeSyncManager` |
| 102 | +- Centralized timeout handling and recovery |
| 103 | + |
| 104 | +### Storage Backends |
| 105 | +Two storage implementations via the `StorageManager` trait: |
| 106 | +- `MemoryStorageManager`: In-memory storage for testing |
| 107 | +- `DiskStorageManager`: Persistent disk storage for production |
| 108 | + |
| 109 | +### Network Layer |
| 110 | +TCP-based networking with proper Dash protocol implementation: |
| 111 | +- Connection management via `TcpConnection` |
| 112 | +- Handshake handling via `HandshakeManager` |
| 113 | +- Message routing via `MessageHandler` |
| 114 | +- Multi-peer support via `PeerManager` |
| 115 | + |
| 116 | +### Validation Modes |
| 117 | +- `ValidationMode::None`: No validation (fast) |
| 118 | +- `ValidationMode::Basic`: Basic structure and timestamp validation |
| 119 | +- `ValidationMode::Full`: Complete PoW and chain validation |
| 120 | + |
| 121 | +### Wallet Integration |
| 122 | +Basic wallet functionality for address monitoring: |
| 123 | +- UTXO tracking via `Utxo` struct |
| 124 | +- Balance calculation with confirmation states |
| 125 | +- Transaction processing via `TransactionProcessor` |
| 126 | + |
| 127 | +## Testing Strategy |
| 128 | + |
| 129 | +### Test Organization |
| 130 | +- **Unit tests**: In-module tests for individual components |
| 131 | +- **Integration tests**: `tests/` directory with comprehensive test suites |
| 132 | +- **Real network tests**: Integration with live Dash Core nodes |
| 133 | +- **Performance tests**: Sync rate and memory usage benchmarks |
| 134 | + |
| 135 | +### Test Categories (from `tests/test_plan.md`) |
| 136 | +1. **Network layer**: Handshake, connection management (3/4 passing) |
| 137 | +2. **Storage layer**: Memory/disk operations (9/9 passing) |
| 138 | +3. **Header sync**: Genesis to tip synchronization (11/11 passing) |
| 139 | +4. **Integration**: Real node connectivity and performance (6/6 passing) |
| 140 | + |
| 141 | +### Test Data Requirements |
| 142 | +- Dash Core node at `127.0.0.1:9999` for integration tests |
| 143 | +- Tests gracefully handle node unavailability |
| 144 | +- Performance benchmarks expect 50-200+ headers/second sync rates |
| 145 | + |
| 146 | +## Development Workflow |
| 147 | + |
| 148 | +### Working with Sync |
| 149 | +The sync system uses a monitoring loop pattern: |
| 150 | +1. Call `sync_*()` methods to start sync processes |
| 151 | +2. The monitoring loop calls `handle_*_message()` for incoming data |
| 152 | +3. Use `check_sync_timeouts()` for timeout recovery |
| 153 | +4. Sync completion is tracked via `SyncState` |
| 154 | + |
| 155 | +### Adding New Features |
| 156 | +1. Define traits for abstractions (e.g., new storage backend) |
| 157 | +2. Implement concrete types following existing patterns |
| 158 | +3. Add comprehensive unit tests |
| 159 | +4. Add integration tests if network interaction is involved |
| 160 | +5. Update error types in `error.rs` for new failure modes |
| 161 | + |
| 162 | +### Error Handling |
| 163 | +Use domain-specific error types: |
| 164 | +- `NetworkError`: Connection and protocol issues |
| 165 | +- `StorageError`: Data persistence problems |
| 166 | +- `SyncError`: Synchronization failures |
| 167 | +- `ValidationError`: Header and transaction validation issues |
| 168 | +- `SpvError`: Top-level errors wrapping specific domains |
| 169 | + |
| 170 | +## MSRV and Dependencies |
| 171 | + |
| 172 | +- **Minimum Rust Version**: 1.80 |
| 173 | +- **Core dependencies**: `dashcore`, `tokio`, `async-trait`, `thiserror` |
| 174 | +- **Built on**: `dashcore` library with Dash-specific features enabled |
| 175 | +- **Async runtime**: Tokio with full feature set |
| 176 | + |
| 177 | +## Key Implementation Details |
| 178 | + |
| 179 | +### Storage Architecture |
| 180 | +- **Segmented storage**: Headers stored in 10,000-header segments with index files |
| 181 | +- **Filter storage**: Separate storage for filter headers and compact block filters |
| 182 | +- **State persistence**: Chain state, masternode data, and sync progress persisted between runs |
| 183 | +- **Storage paths**: Headers in `headers/`, filters in `filters/`, state in `state/` |
| 184 | + |
| 185 | +### Async Architecture Patterns |
| 186 | +- **Trait objects**: `Arc<dyn StorageManager>`, `Arc<dyn NetworkManager>` for runtime polymorphism |
| 187 | +- **Message passing**: Tokio channels for inter-component communication |
| 188 | +- **Timeout handling**: Configurable timeouts with recovery mechanisms |
| 189 | +- **State machines**: `SyncState` enum drives synchronization flow |
| 190 | + |
| 191 | +### Debugging and Troubleshooting |
| 192 | + |
| 193 | +**Common Debug Commands:** |
| 194 | +```bash |
| 195 | +# Run with tracing output |
| 196 | +RUST_LOG=debug cargo test --test integration_real_node_test -- --nocapture |
| 197 | + |
| 198 | +# Run specific test with verbose output |
| 199 | +cargo test --test handshake_test test_handshake_with_mainnet_peer -- --nocapture --test-threads=1 |
| 200 | + |
| 201 | +# Check storage state |
| 202 | +ls -la data*/headers/ |
| 203 | +ls -la data*/state/ |
| 204 | +``` |
| 205 | + |
| 206 | +**Debug Data Locations:** |
| 207 | +- `test-debug/`: Debug data from test runs |
| 208 | +- `data*/`: Runtime data directories (numbered by run) |
| 209 | +- Storage index files show header counts and segment info |
| 210 | + |
| 211 | +**Network Debugging:** |
| 212 | +- Connection issues: Check if Dash Core node is running at `127.0.0.1:9999` |
| 213 | +- Handshake failures: Verify network (mainnet/testnet/devnet) matches node |
| 214 | +- Timeout issues: Node may be syncing or under load |
| 215 | + |
| 216 | +## Current Status |
| 217 | + |
| 218 | +This is a refactored SPV client extracted from a monolithic example: |
| 219 | +- ✅ Core architecture implemented and modular |
| 220 | +- ✅ Compilation successful with comprehensive trait abstractions |
| 221 | +- ✅ Extensive test coverage (29/29 implemented tests passing) |
| 222 | +- ⚠️ Some wallet functionality still in development (see `PLAN.md`) |
| 223 | +- ⚠️ ChainLock/InstantLock signature validation has TODO items |
| 224 | + |
| 225 | +The project transforms a 1,143-line monolithic example into a production-ready, testable library suitable for integration into wallets and other Dash applications. |
0 commit comments