QNet Blockchain: Reward System Complete

1. Sharded Ping Architecture

Implemented 256-shard system for deterministic Light node pinging. Full/Super nodes ping assigned Light nodes every 4-hour window, collect dual-signed attestations (both Light node + Pinger sign with Dilithium).

Scales to millions of nodes with LRU eviction (100K active Light nodes per shard).

2. Lazy Rewards System

All node types (Light, Full, Super) accumulate rewards automatically:
- Pool 1: Base emission — divided equally among ALL eligible nodes
- Pool 2: Transaction fees (70% Super / 30% Full / 0% Light)
- Pool 3: Activation bonus (Phase 2)

Claim anytime — no missed windows, no gas.

3. FCM V1 API Migration

Upgraded from legacy FCM to V1 API with OAuth2 + Service Account authentication. Only Genesis nodes send push notifications. Rate limited to 500 req/sec with 55-min token caching.

4. Storage & Persistence

All critical data now persisted in RocksDB: attestations, heartbeats, pending rewards, reputation history, transaction index by address.

5. P2P Gossip Sync

Light node registrations now gossip across entire network. Full/Super nodes also broadcast registration on API calls. System events propagate via P2P.

6. Production Fixes

- Light node reputation fixed at 70 (immutable)
- Parallel Merkle hashing with rayon
- Removed all TODO/placeholder stubs
- Grace period (3 min) before marking nodes offline

20 files changed, +4802/-2256 lines

https://github.com/AIQnetLab/QNet-Blockchain/commit/bf978f50874802e2fc6ad0d5bd4fa1071b62f0e7

QNet Blockchain: Security & Storage Architecture Overhaul

1. REST API & Security Layer

Complete rewrite of the API security layer. Implemented comprehensive IP-based rate limiting system with configurable limits per endpoint type - transactions, activations, reward claims, light node operations all have separate quotas. Added WebSocket real-time event system with subnoscription channels for blocks, accounts, contracts, mempool and specific transactions. WebSocket connections are now rate-limited to prevent connection flood DDoS (max 5 per IP, 10K total per node with automatic cleanup on disconnect).

New Smart Contract API with full WASM support: deploy contracts, call methods, query state, estimate gas. All state-changing operations require dual signature verification - Ed25519 from client plus Dilithium for quantum resistance.

Critical fix in signature verification - the verify_ed25519_client_signature function was constructing messages internally instead of accepting them as parameters, causing all transaction signatures to fail validation. Now properly verifies actual signed message content.

2. API Reference Documentation

Created comprehensive API documentation covering all REST endpoints, JSON-RPC methods, WebSocket subnoscriptions, rate limiting policies, error codes and authentication flows. Includes examples for every endpoint with request/response formats.

3. Storage Architecture

Implemented tiered storage system based on node type. Light nodes store only block headers with automatic FIFO rotation keeping footprint under 100MB. Full nodes maintain 30-day sliding window with aggressive pruning (~500GB). Super nodes keep complete blockchain history (~2TB).

Added graceful degradation - when disk space drops below threshold, nodes automatically switch to lower storage tier (Super→Full→Light) to keep running instead of crashing.

Removed lossy Pattern Recognition compression that was causing data loss - transactions compressed with it couldn't be reconstructed. Now using only Zstd-3 lossless compression giving ~50% space reduction. Pattern Recognition kept only for statistics collection.

Implemented EfficientMicroBlock format storing only transaction hashes in the block structure, with full transaction data stored and indexed separately. Added transaction pruning for old data, state snapshot management, and background recompression of old blocks to higher Zstd levels.

4. P2P Network & Reputation

Reworked reputation event system - removed SuccessfulResponse and FastResponse bonuses that were being abused. Renamed ValidBlock to FullRotationComplete awarding +2.0 for completing full 30-block producer rotation instead of per-block rewards. Reduced ConsensusParticipation from +2.0 to +1.0.

Implemented 6-strike progressive jail system: 1 hour → 24 hours → 7 days → 30 days → 3 months → 1 year. Critical attacks (database substitution, chain fork, storage deletion) result in permanent ban.

Added jail persistence with SHA3-256 integrity hashes for tamper detection. Jail status survives node restarts and synchronizes across network via ReputationSync messages. Implemented blacklist system with soft bans for network issues and hard bans for Byzantine behavior.

5. Mobile Push Service

New unified push notification service supporting FCM, APNs and UnifiedPush for open-source Android. Implements smart polling where Light nodes wake up only ~2 minutes before their calculated ping slot instead of constant 15-minute intervals. Handles background fetch, notification permissions, token management and fallback mechanisms.

6. Mobile Wallet Screens

Enhanced wallet interface with improved transaction history, balance display, send/receive flows and QR code scanning. Better error handling and loading states.

7. Mobile Wallet Manager

Wallet management component handling multiple wallets, key derivation, backup/restore and secure storage integration.

8. Mobile App Core

App initialization, navigation setup, theme configuration and global state management updates.

9. Activation Validation

Removed mock DHT hash propagation - the existing system provides full functionality without it. Fixed cache hit rate calculation to use actual statistics instead of hardcoded value. Cleaned up unused DhtClient code.

10. Consensus Reputation

Core jail logic implementation with progressive strike system. Critical attack detection for permanent bans. Jail synchronization methods for network-wide consistency. Release logic restoring reputation to minimum 10% allowing passive recovery.

11. Node Core

Added nonce validation before mempool insertion preventing DoS attacks via invalid transaction flooding. Changed recompression interval from 10K to 14.4K blocks (4 hours). Updated storage calls to use unified tiered storage path.

35 files changed, +8728/-1499 lines

https://github.com/AIQnetLab/QNet-Blockchain/commits/testnet

Development Report | Key Commits

November 27-29

P2P Optimizations for Scalability

Commit [ed5ce1d](https://github.com/AIQnetLab/QNet-Blockchain/commit/ed5ce1dd62f268de3d6ec57c0ca37fbc50ab8cc1) - v2.19.19

Performance Optimizations
- Use Turbine block propagation for ALL network sizes (not just >10 peers)
- Implement Kademlia K-neighbors for heartbeat routing (K=3)
- Add exponential backoff for failover (3s → 6s → 12s → 24s → 30s max)
- Add gossip_to_k_neighbors() method for DHT-based message propagation
- CPU savings ~35ms per heartbeat via registry validation

Security (NIST FIPS 204 compliant)
- Heartbeat validation via active_full_super_nodes registry
- Timestamp validation (±5 min) prevents replay attacks
- Blocks/Certificates/ActiveNodeAnnouncement still use Dilithium
- Dedupe mechanism prevents duplicate heartbeat processing

Architecture
- Priority channels: Blocks use separate block_tx channel (implicit priority)
- Gossip fanout reduced from 5 to 3 for heartbeats
- Re-gossip uses Kademlia K-neighbors instead of random selection

8 files changed, +157/-47 lines


Node Privacy & Anonymization

Commit [33eca60](https://github.com/AIQnetLab/QNet-Blockchain/commit/33eca6092df9b0a9a77faf779db89e812f57164b)

Privacy Fixes
- Replace all raw IP logging with get_privacy_id_for_addr() pseudonyms
- Fixed ~30 locations where peer_addr/peer_ip/ip were printed directly
- All logs now show node_XXXXXXXX or genesis_node_XXX instead of IPs

Affected Areas
- send_network_message(): Message sending logs
- broadcast_block(): Block broadcast error logs
- Genesis block sending logs
- Certificate sending/receiving logs
- Sync background task logs
- Consensus message logs
- Peer discovery and connection logs
- External IP announcement logs

Architecture Confirmed
- node_id (genesis_node_001, node_154_38_160_39) used for consensus/producer selection
- Pseudonyms (node_XXXXXXXX) used ONLY for log privacy
- No impact on producer selection — uses real node_id, not pseudonyms
- Light nodes: IP never exposed, communicate via Push notifications
- Full/Super nodes: IP visible only to direct TCP peers, not broadcast
- Genesis nodes: IPs are public by design (bootstrap nodes)

1 file changed, +306/-90 lines


Simplified Fork Resolution & Security Enhancements

Commit [c6f2e3e](https://github.com/AIQnetLab/QNet-Blockchain/commit/c6f2e3e782b5aad8468e71b29127b90389add718)

Fork Resolution
- Simplified fork recovery to three clear cases (network ahead / same height / we're ahead)
- Added MIN_PEERS_FOR_RESYNC = 3 threshold for same-height fork decisions

Security Enhancements
- Reputation manipulation detection in ActiveNodeAnnouncement handler
- Consensus message timestamp validation (±5 minutes tolerance)
- Consensus signature format pre-validation (reject empty/short signatures)

P2P Improvements
- Dual peer lookup for Genesis nodes (check both DashMap and RwLock storage)
- Added else branch for empty peers during P2P initialization

6 files changed, +748/-374 lines


QRC-20 Tokens, Macroblock Sync, Snapshot API

Commit [5c5a474](https://github.com/AIQnetLab/QNet-Blockchain/commit/5c5a4742d6504af0d43ca29e485412cdf18fc1c3)

Token Ecosystem
- Add ContractVM with GLOBAL_TOKEN_REGISTRY for QRC-20 token persistence
- Fix get_tokens_for_address to load from RocksDB storage (survives restarts)
- Add get_all_contract_addresses and add_contract_to_list to storage
- Fix handle_contract_call to use real ContractVM

Macroblock Sync
- Add handle_macroblock_request for peer requests
- Add handle_macroblocks_batch for batch processing
- Add sync_macroblocks for full synchronization

Snapshot API
- Add GET /api/v1/snapshot/latest — latest snapshot
- Add GET /api/v1/snapshot/{height} — snapshot by height

Token API
- Deploy, info, balance, tokens_for_address endpoints
- Fix validate_activation_codes_static for all node types (light/full/super/genesis)

11 files changed, +2384/-307 lines

QNet - QUIC Transport

Why QUIC over HTTP?

HTTP/TCP limitations in blockchain:
- 2-3 RTT handshake overhead per connection
- Head-of-line blocking: single lost packet blocks entire stream
- No native multiplexing: requires multiple connections
- TLS as separate layer adds latency

QUIC advantages:
- 0-RTT reconnection: critical for peer churn in P2P networks
- Stream multiplexing: parallel block/transaction propagation without blocking
- Connection migration: peers can change IP without reconnection
- Integrated TLS 1.3: encryption at protocol level

Industry adoption

Solana migrated to QUIC in 2022 for transaction ingress. Sui and Aptos use QUIC natively. Monad building on QUIC for high-throughput EVM. Performance-focused chains converge on this protocol.

Expected impact

Based on Solana's migration data:
- Handshake latency: ~60% reduction (3 RTT to 1 RTT)
- Block propagation: ~20-30% improvement due to multiplexing
- Connection stability: improved under network churn

23 files changed, +4872/-1559 lines

https://github.com/AIQnetLab/QNet-Blockchain/commit/e816b4fbef6b8b2daa593d89f8c7201ee27e2fcf

After switching from HTTP to QUIC for P2P communication between nodes, some edge-cases appeared that I'm actively fixing now.
Already fixed: block propagation issues, memory leaks, node synchronization on startup.
Once the network is fully stabilized, I'll demonstrate receiving rewards through the mobile app.

QNet - Network Debugging & Reputation Overhaul

Complete rewrite of the reputation system from P2P gossip to blockchain-based deterministic model. Previously reputation was synchronized via network messages which was vulnerable to Sybil attacks and caused desync between nodes. Now reputation is calculated exclusively from on-chain data - SlashingEvents and AutomaticJails are stored directly in MacroBlock ConsensusData. All nodes replay blocks on startup to rebuild identical reputation state.

The transition from HTTP to QUIC transport continues. Current focus: fixing chunk loss in SHRED protocol, implementing retransmit mechanism for missing chunks, rate limiting with Semaphore to prevent burst overload, and resolving sync deadlocks. Added adaptive timeout based on network lag and LRU eviction for phantom peers.

Comprehensive test suite written covering API integration, stress testing, network partitions, chaos engineering, and consensus validation. Tests will be executed on testnet in coming days.

Work in progress. Testnet debugging ongoing.

https://github.com/AIQnetLab/QNet-Blockchain/commits/testnet/

QNet Benchmark Results - VERIFIED

Test Configuration:
- Nodes: 5 Genesis nodes (1 shard)
- Network: Production P2P (QUIC + TCP)
- Cryptography: Ed25519 + CRYSTALS-Dilithium3 (hybrid)

Results:
- Peak TPS: 91,156
- Average TPS: 88,845
- Total TX: 2,560,000
- Success Rate: 100%
- Errors: 0
- Duration: 28.8 seconds
- Avg Latency: 0.015 ms

Verification:
1. Real Ed25519 signatures (verified in logs)
2. Real SHA3-256 hashing
3. Full P2P broadcast via SHRED protocol
4. Real mempool processing
5. Real block inclusion

Public API:
curl http://162.244.25.114:8001/api/v1/benchmark/results

Source Code (open):
- Transaction generation: benchmark . rs:506-565
- Signature: Ed25519 (ed25519-dalek)
- Hash: SHA3-256 (sha3)

Sharding Scalability

This test used only 1 shard out of 256 possible.

QNet supports linear horizontal scaling with up to 256 parallel shards:

Scaling (256 shards max):
1 shard → 88,845 TPS ✅ verified
8 shards → ~720K TPS
32 shards → ~~2.9M TPS
64 shards → ~5.8M TPS
128 shards → ~11.5M TPS
256 shards → ~23M TPS

Estimated Real TPS accounts for ~80% efficiency due to cross-shard communication overhead

Summary

QNet achieves 91,000+ TPS per shard with linear scaling up to ~23 million TPS at full 256-shard deployment.

All transactions include:
- Full cryptographic signatures (Ed25519 + optional Dilithium3)
- SHA3-256 hashing
- P2P network propagation
- Consensus validation
- Block finality (~1 second)

Test Environment:
- Server: VPS with AMD EPYC 6 vCPU, 16GB RAM, SSD

QNet: 91,000 TPS on a single shard

Tech stack breakdown:

- Gulf Stream: direct TX forwarding to block producer (0 hops vs 3)
- Pre-Execution: speculative TX processing 3 blocks ahead
- Bincode: binary serialization, 50x faster than JSON
- DashMap: lock-free concurrent mempool
- Batch processing: 10K TX per lock instead of 1
- SHRED Protocol: Reed-Solomon erasure coding for 99.9% delivery
- QUIC transport: UDP-based, sub-millisecond latency
- Ed25519 batch verification: 2-3x faster signature checks

Single shard handles more than 99% of real-world demand. 256 shards available for horizontal scaling.

Tested on standard VPS (6 vCPU, 16GB RAM) with full P2P network, cryptographic signatures, and block propagation.

I'm not sure if sharding will ever be needed in practice — the network's throughput is already extremely high. But if QNet ever needs to handle a colossal number of transactions, the architecture is ready for that scenario.

My goal was to build the most modern, high-performance network possible. Essentially, I built a spaceship for the price of a bag of chips — and that thought keeps me warm at night.

For months I've been improving and optimizing every aspect of the architecture. As some of you know, over the past 2.5 months I've had only 1 day off. I spend up to 16 hours a day on this project. I've been working on QNet for over 9 months now, and the testnet launch is finally within reach.

There are probably still bugs and blind spots I haven't discovered yet — that's exactly why I'll be ordering a professional security audit to ensure there are no vulnerabilities or issues before mainnet.

Yesterday's benchmark results made me incredibly happy, but there's still a lot of work ahead. I know the website has been unstable and eventually crashed completely — I'll fix that. The priority now is the mobile app, which everything depends on. I'll be testing the node reward distribution system and finishing the explorer so users can view transactions on the network.

I'll be back with good news as soon as possible. Until then, I don't see the point in cluttering the feed with noise.

Once again — thank you all for your support and belief in this project.