Performance Analysis of Quantum-Secure Digital Signature Algorithms in Blockchain

Technical Summary: Performance Analysis of Quantum-Secure Digital Signature Algorithms in Blockchain

Problem Statement
The long-term security of public blockchains relies heavily on the hardness assumptions of their underlying digital signature schemes. Current deployments, such as Bitcoin and Ethereum, utilize elliptic-curve cryptography (ECC), specifically ECDSA or Schnorr signatures over secp256k1. These schemes are vulnerable to Shor's algorithm, which can efficiently solve the discrete logarithm problem on large-scale quantum computers. This creates a "store now, decrypt later" risk, where adversaries could harvest current transaction data and forge signatures once quantum capabilities are realized. While post-quantum cryptography (PQC) offers solutions, existing literature primarily focuses on cryptographic properties and micro-benchmarks (standalone library performance). There is a gap in understanding how these schemes behave when integrated into actual blockchain systems, where costs are influenced by transaction volume, block size, and validation latency.

Methodology
To address this gap, the author developed a local, single-node blockchain prototype designed to isolate the impact of digital signature algorithms on system performance. The prototype implements an account-based model similar to Ethereum but omits consensus and networking layers to focus strictly on cryptographic overhead.

• System Design: The system uses a factory pattern to abstract the signature scheme, allowing for transparent switching between algorithms without altering application logic (wallets, transactions, blocks).
• Algorithms Evaluated: The study focuses on four lattice-based signature schemes:
  • CRYSTALS-Dilithium (ML-DSA): Standardized by NIST (ML-DSA-44, 65, 87).
  • Falcon: NIST-standardized (Falcon-512, 1024).
  • Hawk: A newer lattice-based scheme (Hawk-512, 1024).
  • HAETAE: Evaluated via standalone micro-benchmarks only, as its reference implementation was incompatible with the prototype's MSVC toolchain.
• Experimental Workflow:
  1. Key Generation: 100 iterations per scheme to measure generation time.
  2. Transaction Signing: Creation of 1,000 transactions per block, measuring average signing time.
  3. Block Validation: Repeated validation (100 times) of a 1,000-transaction block to measure total block validation time and derive per-transaction verification latency.
  4. Metrics: Data collected includes key/signature sizes, serialized transaction/block sizes, and timing metrics (in microseconds) for key generation, signing, and verification.

Key Contributions

1. Prototype Implementation: The paper presents a blockchain-like prototype that separates application logic from the underlying signature technique, enabling a fair comparison of quantum-secure algorithms in a system context.
2. Integrated Benchmarking: It outlines a methodology that combines micro-benchmark data (keygen, sign, verify) with blockchain-level metrics (validation latency, block creation size), moving beyond isolated library tests.
3. Comparative Analysis: The work provides a detailed performance comparison of ML-DSA, Falcon, and Hawk within a blockchain environment, extending the analysis to include HAETAE via standalone testing.

Experimental Results
The experiments were conducted on a Windows x86_64 environment using the liboqs library for ML-DSA and Falcon, and reference implementations for Hawk and HAETAE.

• Size Metrics (Storage/Bandwidth):
  • ML-DSA: Exhibits the largest data footprint. For a 1,000-transaction block, sizes range from ~5.1 MB (ML-DSA-44) to ~9.9 MB (ML-DSA-87).
  • Falcon: Offers significantly more compact signatures. A Falcon-512 block is approximately 2.5 MB, and Falcon-1024 is ~4.9 MB.
  • Hawk: Provides the most compact signatures among the integrated schemes. Hawk-512 results in a block size of ~2.65 MB, with signatures (555 bytes) smaller than both Falcon and ML-DSA at comparable security levels.
• Timing Metrics (Performance):
  • Key Generation: ML-DSA is the fastest (sub-millisecond), while Falcon is the slowest (5.7 ms for Falcon-512, 16.8 ms for Falcon-1024) due to complex lattice sampling. Hawk falls in between.
  • Signing: Hawk is the fastest signer (0.03 ms for Hawk-512), followed by Falcon (0.21 ms) and ML-DSA (0.28 ms).
  • Verification: This is the critical metric for validating nodes. Hawk-512 (0.047 ms) and Falcon-512 (0.052 ms) are significantly faster than ML-DSA variants (0.10 ms to 0.23 ms).
  • Block Validation: For a 1,000-transaction block, validation times ranged from ~47 ms (Hawk-512) to ~234 ms (ML-DSA-87).
• HAETAE (Standalone): Micro-benchmarks indicate HAETAE has smaller keys and signatures than ML-DSA but larger than Falcon/Hawk. Verification times (0.07–0.16 ms) place it between the faster Falcon/Hawk variants and the slower ML-DSA-87.

Significance and Claims
The paper modestly claims that there is no single post-quantum scheme that dominates all performance and size metrics. Instead, the choice depends on specific trade-offs:

• ML-DSA offers the simplest design and NIST standardization but incurs higher storage and verification costs.
• Falcon and Hawk provide superior performance in terms of verification speed and data compactness, which is crucial for high-throughput blockchains and nodes with bandwidth constraints. However, they come with higher implementation complexity (especially Falcon's key generation) and, in the case of Hawk, a lack of standardization.
• HAETAE shows promise for size efficiency but requires further integration work to be fully evaluated in a blockchain context.

The author concludes that practitioners must balance implementation complexity, size overhead, and verification latency when selecting a post-quantum signature for blockchain migration. The study highlights that while ML-DSA is a viable standard, schemes like Falcon and Hawk may offer more attractive trade-offs for verification-heavy workloads.

Limitations and Future Work
The paper acknowledges that the prototype is a single-node system without networking or consensus, meaning it does not capture block propagation delays or peer-to-peer bandwidth constraints. Future work aims to extend the prototype to a multi-node environment, evaluate diverse workloads (e.g., smart contracts), and integrate HAETAE by porting it to the current toolchain or moving to a Linux environment. Additionally, future studies will consider memory usage and energy consumption on embedded devices.