Development Phases
The go-blockchain package is being developed in 9 phases, from foundational types through to a fully operational node. Each phase builds on the previous and has clear deliverables and test criteria.
Phase 0: Config + Types
Status: Active
Delivers:
config/package:ChainConfigstruct with all chain parameters,MainnetandTestnetpre-defined instancesconfig/hardfork schedule:HardForkstruct,MainnetForksandTestnetForksslices,VersionAtHeight()lookuptypes/package: Fundamental types (Hash,PublicKey,SecretKey,KeyImage,Signatureas[32]byte/[64]bytealiases)types/address:AccountPublicAddressstruct, base58 encode/decode with Keccak-256 checksum, prefix validationtypes/block and transaction structs:BlockHeader,Block,TransactionPrefix,Transaction, input/output variant typeswire/varint: CryptoNote varint encoding (7-bit, MSB continuation)difficulty/initial: LWMA difficulty calculation stub with test vectors- Wiki pages populated
Dependencies: None (stdlib only).
Test criteria:
go test ./...passes with race detectorgo vet ./...clean- Address encode/decode round-trips match C++ output
- Config constants match
currency_config.h.in+default.cmakeexactly - Varint encoding matches CryptoNote reference vectors
Phase 1: Wire Format + Serialisation
Delivers:
wire/package: Consensus-critical binary serialisation for all block and transaction types- Serialisation must be bit-identical to C++ output for the same input
- Variant type serialisation (tagged unions for inputs, outputs, signatures, extras)
- Block hash computation (header hash + miner tx hash + Merkle root)
- Transaction hash computation (prefix hash)
Dependencies: Phase 0 (types, config).
Test criteria:
- Serialise/deserialise actual mainnet block hex blobs and verify round-trip
- Serialise/deserialise actual mainnet transaction hex blobs
- Computed block and transaction hashes match C++ node output
- Tree hash for Merkle root matches reference vectors
Phase 2: CGo Crypto Bridge
Delivers:
- Build system for
libcryptonotefrom cleaned C++ source crypto/package with CGo wrappers:- Hash functions:
cn_fast_hash(Keccak-256),tree_hash - Key derivation:
generate_key_derivation,derive_public_key,derive_secret_key - Stealth addresses: one-time key generation and detection
- Key images:
generate_key_image - Ring signature verification: classic CryptoNote (
check_ring_signature)
- Hash functions:
- Build tags:
//go:build cgofor real crypto, stubs without - Memory-safe wrappers (no C pointers leak to Go heap)
Dependencies: Phase 0 (types).
Test criteria:
- Key derivation output matches C++ for known test vectors
- Key image generation matches C++ for known keypairs
- Ring signature verification accepts valid sigs, rejects invalid
- No memory leaks under
-raceand CGo sanitiser
Phase 3: RPC Client
Delivers:
rpc/package: JSON-RPC 2.0 client for daemon and wallet APIs- Daemon client:
getinfo,getheight,getblocktemplate,submitblock,gettransactions,getblockheaderbyheight,getblockheaderbyhash - Wallet client:
getbalance,getaddress,transfer - Binary endpoint support for fast sync (
getblocks.bin) - Integration with the
coreCLI:core chain status,core chain info
Dependencies: Phase 0 (types, config), Phase 1 (wire, for binary endpoints).
Test criteria:
- Successful RPC calls against a running C++ testnet node
- Correct deserialisation of all response types
- Error handling for connection failures and invalid responses
Phase 4: Difficulty + Consensus Rules
Delivers:
difficulty/package: Full LWMA difficulty algorithm for both PoW and PoSconsensus/package:- Block reward calculation (fixed 1 LTHN)
- Fee policy (0.01 LTHN default, fee burn)
- Block validation rules per hardfork version
- Timestamp validation (median check, future limit)
- Transaction validation rules (input/output counts, version checks, decoy set size)
Dependencies: Phase 0 (config, types), Phase 1 (wire), Phase 2 (crypto for hash verification).
Test criteria:
- Difficulty calculation matches C++ output for first 1,000 mainnet blocks
- Block reward returns correct value at all hardfork boundaries
- Timestamp validation accepts/rejects correctly against median window
- Fee policy matches C++ node behaviour
Phase 5: P2P Protocol
Delivers:
p2p/package: Levin binary protocol implementation- 33-byte header encoding/decoding
- Epee portable storage serialisation for payloads
COMMAND_HANDSHAKE(1001): connection establishment with network ID and sync dataCOMMAND_TIMED_SYNC(1002): periodic state exchangeCOMMAND_PING(1003): connectivity verificationNOTIFY_NEW_BLOCK(2001): block propagationNOTIFY_OR_INVOKE_NEW_TRANSACTIONS(2002): transaction propagationNOTIFY_REQUEST_GET_OBJECTS(2003) +NOTIFY_RESPONSE_GET_OBJECTS(2004): object fetchNOTIFY_REQUEST_CHAIN(2006) +NOTIFY_RESPONSE_CHAIN_ENTRY(2007): chain sync
- Peer list management (white list, grey list, 70% preference)
- IP blocking after 10 failures (24-hour block)
- Connection lifecycle management (timeouts, idle kill)
Dependencies: Phase 0 (config, types), Phase 1 (wire).
Test criteria:
- Successful handshake with a C++ node
- Receive and parse new block notifications
- Chain sync downloads at least 100 blocks from a C++ peer
- Peer list grows via handshake exchanges
- Invalid handshakes (wrong network ID) are rejected
Phase 6: Blockchain Storage
Delivers:
chain/package: Persistent blockchain database- Block and transaction storage (LMDB or Pebble backend, behind interface)
- Output index: global output index mapping
- Key image tracking: spent/unspent state
- Chain state: current height, top block hash, cumulative difficulty
- Chain reorganisation: detect and switch to a heavier chain
- Checkpoint system for fast initial sync
- Alternative block tracking (max
CURRENCY_ALT_BLOCK_MAX_COUNT= 43,200)
Dependencies: Phase 0-2 (types, wire, crypto), Phase 4 (consensus for validation).
Test criteria:
- Store and retrieve 10,000 blocks without data loss
- Key image double-spend detection works correctly
- Chain reorg correctly switches to a heavier fork
- Database survives crash recovery (write-ahead log)
Phase 7: Wallet
Delivers:
wallet/package:- Account key generation: seed phrase (mnemonic) to spend key + view key derivation
- Output scanning: using view key to detect owned outputs in blocks
- Balance calculation: sum of unspent, owned outputs
- Transaction construction:
- Input selection (age-based, amount-based)
- Decoy ring construction (random output selection via RPC)
- Output generation (stealth addresses)
- Fee calculation
- Signing via CGo crypto bridge (NLSAG for v1, ZC_sig/CLSAG for v2+)
- Wallet file encryption (ChaCha8)
- Payment ID handling (standard and integrated addresses)
- Auditable wallet support
Dependencies: Phase 0-2 (types, wire, crypto), Phase 3 (RPC for output selection), Phase 4 (consensus for fee policy).
Test criteria:
- Seed phrase generates identical keys to C++ wallet
- Output scanning detects all owned outputs in test blocks
- Constructed transactions are accepted by a C++ node
- Wallet file encrypts and decrypts correctly
Phase 8: Full Node
Delivers:
- Complete integration: P2P + chain storage + RPC server + mempool + wallet
- CLI commands:
core chain serve-- Run a full node (P2P + RPC)core chain mine-- PoW miningcore chain stake-- PoS stakingcore wallet create-- Create new walletcore wallet balance-- Show balancecore wallet transfer-- Send fundscore wallet stake-- Delegate stake
- Mempool management:
- Transaction validation before acceptance
- Expiration handling (
CURRENCY_MEMPOOL_TX_LIVETIME= 4 days) - Fee-based prioritisation
- Block template construction (for both PoW and PoS)
- Full chain sync from genesis against C++ network
- Checkpoint verification
Dependencies: All prior phases.
Test criteria:
- Go node syncs fully with the C++ testnet
- Go node mines a valid PoW block accepted by C++ peers
- Go node stakes a valid PoS block accepted by C++ peers
- Go wallet sends a transaction accepted by C++ nodes
- Go node serves RPC requests compatible with existing tooling
Phase Dependency Graph
Phase 0: Config + Types
|
+--- Phase 1: Wire Format
| |
| +--- Phase 3: RPC Client
| | |
| +--- Phase 5: P2P Protocol
| |
+--- Phase 2: CGo Crypto Bridge
|
+--- Phase 4: Difficulty + Consensus
| |
| +--- Phase 6: Blockchain Storage
|
+--- Phase 7: Wallet
|
+--- Phase 8: Full Node (integrates all)