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.

QNet Blockchain: Development Report

I expected to complete the reward system and full transaction functionality in a much shorter timeframe, but it turned out there were many more areas requiring optimization and fixes than initially anticipated.

One important architectural note: according to the new design, rewards for the current epoch are distributed at the end of the following epoch. This delayed distribution model ensures all validator commitments are properly verified on-chain before rewards are calculated.

The reward system and transactions are now nearly complete. The main reason this took so long is the testing cycle: after each build, I need to wait approximately 4 hours (one full epoch) to observe how the logic performs in practice, identify issues, make corrections, and repeat. This iterative process, while time-consuming, is essential for ensuring reliability.

Thank you all for your tremendous support and belief in this project.

Migration from Local Storage to On-Chain Logic

A significant architectural shift during this period was moving critical validator data from local node storage and P2P gossip to verifiable on-chain transactions:

HeartbeatCommitment Transactions
Previously, validator heartbeats were stored locally on each node and shared via P2P gossip. Now, nodes submit HeartbeatCommitment transactions directly to the blockchain. This ensures:
- Cryptographic proof of validator activity
- Immutable record on-chain
- No reliance on P2P message delivery for reward eligibility

PingCommitment Transactions
Validator ping proofs for Light node verification have been moved from local accumulation to on-chain PingCommitmentWithSampling transactions. Benefits include:
- Transparent and auditable ping records
- Elimination of local storage discrepancies between nodes
- Deterministic reward calculation based on blockchain state

On-Chain Node Registration
Node registration data is now recorded directly on the blockchain rather than maintained in local registries synchronized via gossip.

This migration eliminates trust assumptions, ensures all nodes have identical data for reward calculations, and provides full auditability of validator activity.

Cryptographic Standards: NIST FIPS 202 Compliance
Transaction signature verification has been migrated to SHA3-256 (Keccak) for full compliance with NIST FIPS 202 standards. The dual-hash strategy now uses:

- SHA3-256 for all transaction signatures and cryptographic operations
- Blake3 for Proof-of-History chains and internal performance-critical hashing

Additionally, the hybrid signature system combining Ed25519 (classical) with Dilithium3 (post-quantum) has been fully integrated for consensus-critical transactions including HeartbeatCommitment and PingCommitment.

Consensus Protocol Hardening

Multiple critical fixes were implemented to ensure deterministic consensus and prevent network forks:

- Epoch-Based Validator Set for deterministic producer selection
- Zero Fork Guarantee through 5-layer macroblock protection
- Per-round storage for commit-reveal consensus data, preventing round_override data loss
- Emergency producer rotation with strict synchronization checks
- Certificate extraction from VRF proofs for historical block validation
- Round-based failover with unified SHA3-512 entropy source

Explorer and Mobile Integration

Production infrastructure for blockchain exploration:

- PostgreSQL-based synchronization service with batch processing
- Embedded RocksDB indexing for high-performance queries
- Real-time WebSocket updates for transaction and block feeds
- Genesis account handling and QNC balance integration in mobile application
- Transaction type unification across Explorer UI

Security Improvements

- Replacement of all unsafe unwrap() calls with safe alternatives
- On-chain slashing architecture replacing P2P-based slashing
- Strict sync verification for emergency producer selection
- Certificate validation for all historical blocks

I started working on QNet from the beginning of March 2025. Almost every single day. And since the pump.fun launch (09/24/2025) I've had only 2 days off in 4 months.

This is not a token made in one evening. This is a full-fledged Layer-1 blockchain with its own network, consensus, cryptography, and applications.

Let me show you what exactly has been created.

PROJECT SCALE

~200,000 lines of code. 1,760 files. 108 unique mechanisms. Three programming languages: Rust, TypeScript, Python.

For comparison: a team of 5 senior developers would take 18-24 months with a budget of $1.5-3 million.

BLOCKCHAIN CORE

Written in Rust — 90,000 lines of code.

Main modules:
- node rs (23,017 lines) — main node logic, block processing, transactions, consensus
- unified_p2p.rs (19,173 lines) — P2P network between nodes, peer discovery, gossip protocol
- rpc rs (11,681 lines) — REST API for external applications
- qnet-consensus (10,500 lines) — BFT consensus with adaptive timeouts
- storage rs (6,099 lines) — RocksDB storage layer
- qnet-core (4,910 lines) — base data structures
- activation_validation.rs (2,786 lines) — node activation validation
- qnet-mempool (2,506 lines) — unconfirmed transaction pool
- quic_transport.rs (1,476 lines) — QUIC/TLS transport layer
- qnet-sharding (990 lines) — sharding into 256 parts

CRYPTOGRAPHY

Quantum-resistant algorithms:
- CRYSTALS-Dilithium3 — post-quantum digital signatures (NIST standard)
- Hybrid scheme Ed25519 + Dilithium — compatibility with current systems plus protection against quantum attacks
- Blake3 — hash functions for Proof-of-History

NETWORK STACK

- QUIC protocol — modern transport over UDP
- TLS 1.3 — encryption of all connections
- Bincode — binary data serialization
- Length-prefixed framing — reliable message delivery
- ACK mechanism — delivery confirmation for critical transactions
- Reed-Solomon erasure coding — data recovery with up to 30% packet loss

108 MECHANISMS

Transport: QUIC, TLS 1.3, Bincode, Port Offset, TCP Nodelay, Keepalive

Shred Protocol: Chunking 128KB, Reed-Solomon, Adaptive Redundancy, Parity Chunks, Producer Certificate, Priority Delivery, Max Block Size 21.76MB, Unicast Sync, Chunk Pacing

Routing: Kademlia DHT (K=20, α=3), XOR Distance Routing, Tree Propagation, Adaptive Fanout, Deterministic Chunk Targeting, Sorted Peers by Bucket

Flow Control: Batch Sending, Pacing Delay, Semaphore Limiting, Backpressure, Retry Cooldown, Timeout Management, Adaptive Backpressure, Congestion Control

Recovery: Chunk Cache, Repair Batching, Deduplication, Gap Detection, Parallel Download, Wave Sync, Retry Mechanism, Downloading Tracker, Pending Gap Queue, Retransmit Cache, Size-Based Batching, Macroblock Batching

Stage Pipeline: BROADCAST_RUNTIME, SIGVERIFY_RUNTIME, BANKING_RUNTIME, REPLAY_RUNTIME

Sharding: 256 Shards, Regional Clustering (EU, US, Asia), Lock-free DashMap, LRU Eviction, Adaptive Peer Limit

Security: Dilithium Signatures, Ed25519 Hybrid, Rate Limiting, Nonce Validator, Soft Blacklist, Hard Blacklist, Malicious Behavior Detection, Invalid Blocks Tracker, False Emergency Tracker, Emergency Confirmations, Race Condition Protection, Privacy ID Logging

Reputation: Reputation System, Consensus Score, Network Score, Reputation Migration, Qualified Producers Filter

Compression: Zstd for macroblocks, LZ4 for certificates, Bincode+Zstd for signatures

Parallelism: Parallel Executor Pipeline, Pre-Execution Cache, Dependency Analysis

Consensus: PoH (Blake3), Adaptive BFT Timeouts, Commit-Reveal Protocol

Networking: Gulf Stream TX Routing, Gossip Protocol, Health Ping, Peer Exchange Protocol, Bootstrap/Genesis Nodes, Heartbeat System, Peer Heights Tracking

Failover: Emergency Failover, Failover Deduplication, Emergency Stop Production, Auto-Recovery, Regional Failover, Strict Sync Check, Peer Sync Filtering

Certificates: Certificate Rotation, Certificate History Tracking, Hybrid Certificate (Ed25519+Dilithium), Certificate Cache with TTL

Maintenance: Auto-Cleanup 24h, Inactive Peer Cleanup, QUIC Idle Cleanup, Stale Node Timeout

Monitoring: RuntimeStats, Atomic Counters, Cache Actor, Load Balancing Metrics

Fees and Snapshots: Gas Price / Priority Fees, State Snapshots (IPFS), Max TX per Block (100K)

APPLICATIONS

70,000 lines of JavaScript/TypeScript.

Browser Wallet Extension - 43,800 lines:
Extension for Chrome, Edge, Firefox. Manifest V3. Support for Ed25519 and Dilithium signatures. Multi-network support. Secure seed phrase storage.

Mobile App - 12,687 lines:
React Native application for Android and iOS. Quantum signatures from mobile device. Push notifications. Ability to participate in the network from your phone.

Web Explorer - 11,158 lines:
Next.js 15 application. PostgreSQL synchronization. Real-time updates. Search by blocks, transactions, addresses.

Explorer Backend — 1,939 lines:
Sync service, database, rate limiting, monitoring, security middleware.

INFRASTRUCTURE

20,000 lines of Python.

infrastructure/qnet-node (11,737 lines) — API servers, economic model, discovery, security
development/noscripts (8,287 lines) — deployment, testing, benchmarks, monitoring

TECHNOLOGY STACK

Backend: Rust, Tokio (async runtime), Quinn (QUIC), RocksDB, Bincode, pqcrypto-dilithium

Frontend: Next.js 15, React 19, React Native 0.76, TypeScript, TailwindCSS, PostgreSQL

Infrastructure: Docker, Kubernetes, Prometheus, Grafana, TLS certificates

TOKENOMICS

Zero premine. Fair launch - everyone starts from zero. Rewards for running nodes. Ability to participate from mobile device.

QNet is a full-fledged Layer-1 blockchain with quantum-resistant cryptography. ~200,000 lines of production code. 108 enterprise-grade mechanisms. Mobile app, browser extension, web explorer.

Built by one person in 11 months of daily work.

When you ask "when?" - remember that this is not a copy of someone else's code. This is a unique blockchain being built with decades ahead in mind.

Architecture & Testnet Update

Removed the second reward pool where transaction fees were distributed among all super and full nodes - realized it was overcomplicating the architecture without adding real value. For the same reason, I removed full nodes entirely, leaving just two types: light nodes (which are essentially clients, not real nodes) and server nodes (super). Simpler is better.

Before launching the testnet, I still need to test user node registration - both server and mobile. Also need to verify how light node ping functionality works end to end.

Once all checks are done and final adjustments made, we can start full-scale testing. At launch, access will be Android-only. iOS support is coming - it just needs time. One thing at a time. Let's get to testnet first and go from there.

Note: the Explorer is live and showing current network data, but the chain will likely be reset several times before the official testnet launch as I make fixes and adjustments. All existing blocks, transactions, and balances will be wiped with each reset.

In the latest big update, I've completely replaced the previous block producer selection mechanism (QRDS) with Dilithium3-VRF - a verifiable random function based on post-quantum cryptography, NIST FIPS 204 (ML-DSA-65).

What this means in practice:
Previously, producer selection was deterministic - all nodes computed the same hash function from public data, and the result was predictable in advance. This created an attack vector: knowing the future producer, an adversary could target them before block creation.
Now each node privately evaluates a VRF using its secret key and a shared seed value. The result is unpredictable to everyone else, yet cryptographically verifiable - any network participant can confirm that the node genuinely had the right to produce the block, without knowing its private key. The winner is determined by the lowest VRF output among all claims, making result manipulation impossible.

In parallel, I'm working on the node activation mechanism. The key security requirement: the activation code is cryptographically bound to the wallet address that received it. This means that even if the code is intercepted, it cannot be used from a different wallet - during server-side activation, an XOR-encrypted binding between the code and the address is verified. The owner's mnemonic phrase is the only way to confirm the right to launch a node.

Not long ago I ran stress tests on the network that showed around 100K TPS - but the problem was that the network broke down afterwards, likely due to issues with the cryptographic signatures at the time.

Since then I reworked the signature system and ran new tests. Results:

- Peak TPS: 54,162
- Average TPS: 53,516
- Transactions: 978,664 out of 999,996 (97.9% success)
- Duration: 18.7 sec
- Errors: 0
- Latency avg: 0.081 ms
- Latency p99: 0.115 ms

The network runs flawlessly after the tests - all 5 nodes are synchronized, 0 forks, 0 errors.

It's possible to push TPS even higher, but that would require expanding the mempool and increasing block sizes, which could cause issues with block propagation and exchange between nodes due to their size. So I prefer to focus on finishing the node registration work for now.

Either way I'm happy with the current 54K TPS - that's an insane result for an L1 blockchain with post-quantum Dilithium3 signatures.

http://162.244.25.114:8001/api/v1/benchmark/results