Skip to content

Commit 458af19

Browse files
Merge branch 'develop' of https://github.com/dashpay/dash into develop
2 parents d6c9252 + 3bac0a4 commit 458af19

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

47 files changed

+1529
-1103
lines changed

CLAUDE.md

Lines changed: 246 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,246 @@
1+
# Dash Core Development Guide
2+
3+
## Overview
4+
5+
Dash Core is the reference implementation for Dash, a cryptocurrency. It builds on top of Bitcoin Core, a codebase that
6+
is primarily written in C++20 (requiring at least Clang 16 or GCC 11.1). Dash Core uses the GNU Autotools build system.
7+
8+
## Directory Structure
9+
10+
- **Implementation** `src/` - C++20 codebase
11+
- `src/bench/` - Performance benchmarks (uses `nanobench`)
12+
- `src/fuzz/` - Fuzzing harnesses
13+
- `src/index/` - Optional indexes
14+
- `src/interfaces/` - Interfaces for codebase isolation and inter-process communication
15+
- `src/qt/` - Implementation of Dash Qt, the GUI (uses Qt 5)
16+
- `src/rpc/` - JSON-RPC server and endpoints
17+
- `src/util/` - Utility functions
18+
- `src/wallet/` - Wallet implementation (uses Berkeley DB and SQLite)
19+
- `src/zmq/` - ZeroMQ notification support for real-time event publishing
20+
- **Unit Tests**
21+
- `src/test/`, `src/wallet/test/` - C++20 unit tests (uses `Boost::Test`)
22+
- `src/qt/test/` - C++20 unit tests for GUI implementation (uses Qt 5)
23+
- **Functional Tests**: `test/functional/` - Python tests (minimum version in `.python-version`) dependent on `dashd` and `dash-node`
24+
25+
### Directories to Exclude
26+
27+
**Under any circumstances**, do not make changes to:
28+
- `guix-build*` - Build system files
29+
- `releases` - Release artifacts
30+
- Vendored dependencies:
31+
- `src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}`
32+
- `src/crypto/{ctaes,x11}`
33+
34+
**Unless specifically prompted**, avoid:
35+
- `.github` - GitHub workflows and configs
36+
- `depends` - Dependency build system
37+
- `ci` - Continuous integration
38+
- `contrib` - Contributed scripts
39+
- `doc` - Documentation
40+
41+
## Build Commands
42+
43+
### Setup and Build
44+
```bash
45+
# Generate build system
46+
./autogen.sh
47+
48+
# Build dependencies for the current platform
49+
make -C depends -j"$(( $(nproc) - 1 ))" | tail 5
50+
51+
# Configure with depends (use the path shown in depends build output)
52+
# Example paths: depends/x86_64-pc-linux-gnu, depends/aarch64-apple-darwin24.3.0
53+
./configure --prefix=$(pwd)/depends/[platform-triplet]
54+
55+
# Developer configuration (recommended)
56+
./configure --prefix=$(pwd)/depends/[platform-triplet] \
57+
--disable-hardening \
58+
--enable-crash-hooks \
59+
--enable-debug \
60+
--enable-reduce-exports \
61+
--enable-stacktraces \
62+
--enable-suppress-external-warnings \
63+
--enable-werror
64+
65+
# Build with parallel jobs (leaving one core free)
66+
make -j"$(( $(nproc) - 1 ))"
67+
```
68+
69+
## Testing Commands
70+
71+
### Unit Tests
72+
```bash
73+
# Run all unit tests
74+
make check
75+
76+
# Run specific test (e.g. getarg_tests)
77+
./src/test/test_dash --run_test=getarg_tests
78+
79+
# Debug unit tests
80+
gdb ./src/test/test_dash
81+
```
82+
83+
### Functional Tests
84+
```bash
85+
# Run all functional tests
86+
test/functional/test_runner.py
87+
88+
# Run specific test
89+
test/functional/wallet_hd.py
90+
91+
# Extended test suite
92+
test/functional/test_runner.py --extended
93+
94+
# Parallel execution
95+
test/functional/test_runner.py -j$(nproc)
96+
97+
# Debug options
98+
test/functional/test_runner.py --nocleanup --tracerpc -l DEBUG
99+
```
100+
101+
### Code Quality
102+
```bash
103+
# Run all linting
104+
test/lint/all-lint.py
105+
106+
# Common individual checks
107+
test/lint/lint-python.py
108+
test/lint/lint-shell.py
109+
test/lint/lint-whitespace.py
110+
test/lint/lint-circular-dependencies.py
111+
```
112+
113+
## High-Level Architecture
114+
115+
Dash Core extends Bitcoin Core through composition, using a layered architecture:
116+
117+
```
118+
Dash Core Components
119+
├── Bitcoin Core Foundation (Blockchain, consensus, networking)
120+
├── Masternodes (Infrastructure)
121+
│ ├── LLMQ (Quorum infrastructure)
122+
│ │ ├── InstantSend (Transaction locking)
123+
│ │ ├── ChainLocks (Block finality)
124+
│ │ ├── EHF Signals (Hard fork coordination)
125+
│ │ └── Platform/Evolution (Credit Pool, Asset Locks)
126+
│ ├── CoinJoin (Coin mixing)
127+
│ └── Governance Voting (Masternodes vote on proposals)
128+
├── Governance System (Proposal submission/management)
129+
└── Spork System (Feature control)
130+
```
131+
132+
### Key Architectural Components
133+
134+
#### Masternodes (`src/masternode/`, `src/evo/`)
135+
- **Deterministic Masternode Lists**: Consensus-critical registry using immutable data structures
136+
- **Active Masternode Manager**: Local masternode operations and BLS key handling
137+
- **Special Transactions**: ProRegTx, ProUpServTx, ProUpRegTx, ProUpRevTx for masternode lifecycle
138+
139+
#### Long-Living Masternode Quorums (`src/llmq/`)
140+
- **Quorum Types**: Multiple configurations (50/60, 400/60, 400/85) for different services
141+
- **Distributed Key Generation**: Cryptographically secure quorum formation
142+
- **Services**: ChainLocks (51% attack prevention), InstantSend, governance voting
143+
144+
#### CoinJoin Privacy (`src/coinjoin/`)
145+
- **Mixing Architecture**: Masternode-coordinated mixing sessions
146+
- **Denomination**: Uniform outputs for privacy
147+
- **Session Management**: Multi-party transaction construction
148+
149+
#### Governance (`src/governance/`)
150+
- **Governance Objects**: Proposals, triggers, superblock management
151+
- **Treasury**: Automated payouts based on governance votes
152+
- **Voting**: On-chain proposal voting and tallying
153+
154+
#### Evolution Database (`src/evo/evodb`)
155+
- **Specialized Storage**: Masternode snapshots, quorum state, governance objects
156+
- **Efficient Updates**: Differential updates for masternode lists
157+
- **Credit Pool Management**: Platform integration support
158+
159+
#### Dash-Specific Databases
160+
161+
- **CFlatDB**: A Dash-specific flat file database format used for persistent storage
162+
- `MasternodeMetaStore`: Masternode metadata persistence
163+
- `GovernanceStore`: Governance object storage
164+
- `SporkStore`: Spork state persistence
165+
- `NetFulfilledRequestStore`: Network request tracking
166+
- **CDBWrapper**: Bitcoin Core database wrapper extended for Dash-specific data
167+
- `CDKGSessionManager`: LLMQ DKG session persistence
168+
- `CEvoDb`: Specialized database for Evolution/deterministic masternode data
169+
- `CInstantSendDb`: InstantSend lock persistence
170+
- `CQuorumManager`: Quorum state storage
171+
- `CRecoveredSigsDb`: LLMQ recovered signature storage
172+
173+
### Integration Patterns
174+
175+
#### Initialization Flow
176+
1. **Basic Setup**: Core Bitcoin initialization
177+
2. **Parameter Interaction**: Dash-specific configuration validation
178+
3. **Interface Setup**: Dash manager instantiation in NodeContext
179+
4. **Main Initialization**: EvoDb, masternode system, LLMQ, governance startup
180+
181+
#### Consensus Integration
182+
- **Block Validation Extensions**: Special transaction validation
183+
- **Mempool Extensions**: Enhanced transaction relay
184+
- **Chain State Extensions**: Masternode list and quorum state tracking
185+
- **Fork Prevention**: ChainLocks prevent reorganizations
186+
187+
#### Key Design Patterns
188+
- **Manager Pattern**: Centralized managers for each subsystem
189+
- **Event-Driven Architecture**: ValidationInterface callbacks coordinate subsystems
190+
- **Immutable Data Structures**: Efficient masternode list management using Immer library
191+
- **Extension Over Modification**: Minimal changes to Bitcoin Core foundation
192+
193+
### Critical Interfaces
194+
- **NodeContext**: Central dependency injection container
195+
- **LLMQContext**: LLMQ-specific context and state management
196+
- **ValidationInterface**: Event distribution for block/transaction processing
197+
- **ChainstateManager**: Enhanced with Dash-specific validation
198+
- **Chainstate Initialization**: Separated into `src/node/chainstate.*`
199+
- **Special Transaction Serialization**: Payload serialization routines (`src/evo/specialtx.h`)
200+
- **BLS Integration**: Cryptographic foundation for advanced features
201+
202+
## Development Workflow
203+
204+
### Common Tasks
205+
```bash
206+
# Clean build
207+
make clean
208+
209+
# Run dashd with debug logging
210+
./src/dashd -debug=all -printtoconsole
211+
212+
# Run functional test with custom dashd
213+
test/functional/test_runner.py --dashd=/path/to/dashd
214+
215+
# Generate compile_commands.json for IDEs
216+
bear -- make -j"$(( $(nproc) - 1 ))"
217+
```
218+
219+
### Debugging
220+
```bash
221+
# Debug dashd
222+
gdb ./src/dashd
223+
224+
# Profile performance
225+
test/functional/test_runner.py --perf
226+
perf report -i /path/to/datadir/test.perf.data --stdio | c++filt
227+
228+
# Memory debugging
229+
valgrind --leak-check=full ./src/dashd
230+
```
231+
232+
## Branch Structure
233+
234+
- `master`: Stable releases
235+
- `develop`: Active development (built and tested regularly)
236+
237+
## Important Notes
238+
239+
- Use `make -j"$(( $(nproc) - 1 ))"` for parallel builds (leaves one core free)
240+
- Always run linting before commits: `test/lint/all-lint.py`
241+
- For memory-constrained systems, use special CXXFLAGS during configure
242+
- Special transactions use payload extensions - see `src/evo/specialtx.h`
243+
- Masternode lists use immutable data structures (Immer library) for thread safety
244+
- LLMQ quorums have different configurations for different purposes
245+
- Dash uses `unordered_lru_cache` for efficient caching with LRU eviction
246+
- The codebase extensively uses Dash-specific data structures for performance

doc/release-notes-6729.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
Notable Changes
2+
---------------
3+
4+
* Dash Core will no longer permit the registration of new legacy scheme masternodes after the deployment of the v23
5+
fork. Existing basic scheme masternodes will also be prohibited from downgrading to the legacy scheme after the
6+
deployment is active.
7+
8+
Updated RPCs
9+
----------------
10+
11+
* `protx revoke` will now use the legacy scheme version for legacy masternodes instead of the defaulting to the
12+
highest `ProUpRevTx` version.

0 commit comments

Comments
 (0)