My Journey into Post-Quantum Infrastructure

The Paraxiom Validator Node

Introduction

Hi, I’m Edwin Kofi Afful, a Computer Science & Engineering student from Ghana with a strong interest in Quantum Computing, Post-Quantum Cryptography (PQC), and secure distributed systems.

As the world moves toward the Quantum Era, many of the cryptographic systems we rely on today (like RSA and ECC) will eventually become insecure. This project is my hands-on attempt to understand how future systems can remain secure in the presence of powerful quantum computers.

Project Overview

• Network: Paraxiom QuantumHarmony Testnet
• Role: Validator Node Operator
• Main Focus: Post-Quantum Cryptography and secure infrastructure

I deployed and currently maintain a validator node on the Paraxiom QuantumHarmony Testnet.

This is not a typical blockchain setup. The network integrates NIST-standardized post-quantum cryptographic algorithms, making it an early experiment in building quantum-resistant digital infrastructure.

Technologies & Cryptography Explored

Through this project, I worked with the following technologies:

• SPHINCS+ — Stateless, hash-based digital signatures
• Falcon-1024 — Lattice-based cryptography for identity verification
• Ed25519 — Modern cryptographic identities for peer authentication
• Substrate — Blockchain framework used by the network
• Docker & Docker Compose — For deploying and managing the node

The Challenge: The Great Migration

I joined the network during a major cryptographic migration in December 2025.

What Went Wrong

Although my node started without errors, it could not connect to the rest of the network:

• No peer connections
• No block synchronization
• Node stuck in Idle (0 peers)

Error seen in the logs:

At first glance, everything looked fine — but the node was completely isolated.

Diagnosis

After carefully reading the logs and going through the network documentation, I figured out the issue.

• The network had moved from RSA-based node identities to Ed25519 identities
• My node was still trying to connect using old peer IDs
• Because of this mismatch, the handshake with the bootstrap nodes always failed

In simple terms, my node was trying to connect using an expired identity, so the network rejected it.

How I Fixed It

To solve the problem, I did the following:

1. Checked the logs to find the new Ed25519 peer IDs of the bootstrap nodes (Alice, Bob, and Charlie)
2. Manually edited the docker-compose.yml file
3. Overrode the default bootnode configuration so the node would connect using the updated identities

Result

After applying these changes:

• The node immediately discovered peers
• Block synchronization started successfully
• More than 8,000 blocks were synced
• The node became fully connected and stable

📸 Live Proof of Validator Status

Snapshot showing full synchronization at Block #9,531 with active P2P connections.

📟 Terminal Sync Logs

Real-time log output confirming active block propagation and peer connectivity (3 peers).

Observation: The logs confirm the node is operating in PoC: simulated mode, managing the consensus stream without physical quantum hardware attached

From Watcher to Validator

Once the node was fully synced, I didn’t want to just observe the network. I wanted to take part in securing it.

Key Rotation

Using the node’s RPC API, I performed a key rotation to generate a secure validator identity.

The keys were stored in the local keystore and allowed my node to:

• Sign blocks
• Participate in consensus
• Help secure the network

Post-Quantum Session Keys Generated

I successfully rotated the session keys, generating a concatenated public key bundle containing the Falcon-1024 and SPHINCS+ keys.

Evidence of active key rotation (Output Log):

jsonrpc id result
------- -- ------
2.0      1 0xe4f9667724e284c832eb03abfbaf198a26779562ee143cc2f0016bd27e016032... [TRUNCATED]