DEV Community

Cover image for We rewrote a live blockchain in Rust
TechnoL0g
TechnoL0g

Posted on

We rewrote a live blockchain in Rust

#blockchain #cryptography #web4 #pq

We rewrote a live blockchain in Rust, made it quantum-resistant, and removed third parties from its network. Here’s why and how. (SmartHoldem PQ + NETFORY / WEB4)

SmartHoldem is a DPoS chain that has been producing a block every 8 seconds for years (past block #11,930,000). Over the last months, we transitioned its core from Node.js to a high-performance Rust node (sth-core), added post-quantum signatures (ML-DSA-44, the NIST FIPS 204 standard) without a hard fork, implemented a BFT finality gadget, and rebuilt the peer-to-peer layer on QUIC. Now, wallets interact directly with nodes no HTTP servers, no domains, and no intermediary relay companies. Here is the technical breakdown.

1. Why rewrite a live, working blockchain?

Two primary factors drove this architecture transition: system performance and future cryptographic security.

Performance & Efficiency: The legacy node relied on Node.js, PostgreSQL, and required a full weekend to sync from genesis. The new Rust implementation utilizes an embedded key-value engine (Sled), syncs in a fraction of the time, verifies signatures in parallel, and operates efficiently on low-resource hardware like a €4 VPS or Raspberry Pi. It maintains 100% bit-for-bit database compatibility with ~50k wallets, wire protocol JSON, and API endpoints, allowing old and new nodes to seamlessly forge blocks in the same consensus rounds.

Post-Quantum Preparedness: Blockchains secured solely by classical ECDSA/secp256k1 (Bitcoin, Ethereum, etc.) face a long-term cryptographic expiry date. A sufficiently powerful quantum computer running Shor's algorithm will be able to derive private keys from exposed public keys. On most UTXO/account models, public keys are revealed the moment an outgoing transaction is made. Upgrading the cryptographic foundation today prevents future vulnerabilities.

2. Quantum Shield: Post-quantum signatures without a hard fork

To avoid breaking backward compatibility or forcing a network-wide "flag day," we engineered an additive hybrid signature scheme:

  • ML-DSA-44 Support: Wallets can register an ML-DSA-44 public key (FIPS 204, the lattice-based standard approved by NIST in 2024).

  • Dual-Signature Scheme: Once registered, nodes enforce dual signatures on all outgoing transactions: classic secp256k1 and post-quantum ML-DSA. Compromosing one scheme alone is insufficient to compromise the account. This hybrid model aligns with IETF/NIST transition recommendations.

  • Consensus Protection: Blocks forged by PQ-enabled delegates carry post-quantum signatures, protecting both state balances and block production.

  • Zero Forced Migration: Unmodified legacy wallets continue functioning as usual without mandatory upgrades.

Trade-off: PQ transactions increase payload size (~3 KB vs ~200 bytes). Block dynamic fee models and mempool advisors were updated to handle larger signature footprints smoothly.

3. Finality: Deterministic settlement via BFT

Standard DPoS provides fast block times but, like most longest-chain consensus models, only offers probabilistic finality. We added a deterministic finality gadget:

  • Delegates broadcast signed votes after every block.

  • When 2/3 of active delegates sign off on a block at a given height, nodes issue a finality certificate and freeze state reorgs below that height.

  • Certificates are compact, verifiably light, and allow new nodes syncing the chain to identify settled state instantly without trusting third-party snapshots.

4. WEB4 Architecture: Direct P2P networking for dApps

Modern "Web3" dApps often rely on centralized infrastructure HTTP gateways (api.provider.com), TLS certificates, CDNs, and load balancers. If the central gateway goes down, the dApp loses ledger connectivity.

Our answer is WEB4 via NETFORY: a native peer-to-peer communication stack where identity is a cryptographic key rather than a domain name.

  • Ed25519 Identity: Every network node is identified by its public key.

  • QUIC Transport: Powered by iroh for multiplexed, encrypted, NAT-traversing connections. Devices behind carrier-grade NATs establish direct peer-to-peer connections via hole-punching.

  • REST-over-QUIC & Push Streams: Wallets communicate using MessagePack framing directly over P2P QUIC streams. Subscriptions push block events to wallets in real-time, eliminating HTTP polling overhead.

  • E2E Encrypted Services: On top of this network layer, NETFORY runs decentralized file storage and an end-to-end encrypted messenger (X25519 + AES-256-GCM) with key discovery on-chain.

5. Full Network Autonomy & Self-Sovereign Discovery

To ensure total independence from external infrastructure, we implemented a fully self-reliant discovery and transport protocol:

  1. Decentralized Relays (n1): Community-operated fallback relays handle encrypted traffic routing when direct NAT hole-punching is unavailable.

  2. Signed Address Book: Nodes exchange cryptographically signed records (public_key, ip:port, relay_info) via gossip protocols and RPC. First-contact peer discovery requires no DNS lookups.

  3. Mainline DHT Integration: Nodes publish discovery records as BEP-44 mutable items to the global BitTorrent DHT. This leverages millions of distributed nodes for bootstrap discovery without central servers.

  4. Censorship Resilience: Network gateways can act as bootstrap nodes for peers operating in restricted network environments, ensuring uninterrupted DHT access.

6. What's Next

  • Service Nodes: Introducing masternode tiers backed by cryptographically proven uptime records.

  • On-Chain Order Books: Enhancing native token engine features with expanded UI interfaces.

  • Browser-Native DHT: Moving client-side wallets toward direct DHT discovery to minimize reliance on bridge gateways.

The entire stack is fully open-source and specified under SmartHoldem Improvement Proposals (SHIPs):

TechnoL0g, SmartHoldem / NETFORY

Top comments (0)