Back to Blog

Table of Contents

Highlights

Quantumglow: Will Solana’s Performance Survive Quantum Computing?

Written By

Quentin Kniep, Kobi Sliwinski, and Roger Wattenhofer

July 30, 2026

A powerful quantum computer would pose a grave threat to internet security. Many cryptographic primitives, such as digital signatures, could be attacked and broken by a quantum computer. Solana’s Alpenglow is no exception. Even if quantum computing is not practical yet, we want to be ready.

Many cryptographic primitives on which Alpenglow relies have quantum-proof alternatives. However, such alternatives come with severe performance concessions. Naive replacement of the affected parts of Alpenglow would cripple the protocol, and Solana’s state-of-the-art performance would suffer.

Do we have to accept that quantum resilience carries a hefty price tag? No! We present Quantumglow: a post-quantum adaptation of Alpenglow. Quantumglow features a similar state-of-the-art performance as Alpenglow, despite a radical shift in cryptographic primitives, and even though digital signature aggregation is avoided entirely. It turns out that a blockchain protocol can marry today’s speed with futuristic security!

Size Matters

Naively replacing Alpenglow's elliptic-curve signatures (EdDSA and BLS) with post-quantum signatures fails for two reasons.

The first is size. Alpenglow was built around signatures small enough that a vote, a shred, or a certificate fits in a single network packet. Post-quantum signatures are much bigger. The smallest option on track to standardization (Falcon-512) is 666 bytes. Other alternatives run into kilobytes, so they stop fitting. Quantumglow works around this constraint by removing signatures as much as possible. Quantumglow only ever sends a large post-quantum signature alongside a small amount of data.

Rather than reach for an off-the-shelf post-quantum signature, we propose a hash-based (XMSS-style) signature scheme tailored specifically to Quantumglow that we dub Ax (short for Alpenglow XMSS):

Hash-based signatures rely only on the security of hash functions, which is about as conservative of an assumption as possible. A few integration tricks pay off handsomely: validators exchange and cache each other's one-time public keys in advance, so signatures can omit the usual Merkle paths, and some messages (like skip and finalize votes) carry no real payload at all, so the signature shrinks to revealing a single secret value. The result is the strongest quantum-safe security we can get with a single packet.

Quantumglow authenticates blocks without signing every piece. Alpenglow's dissemination layer, Rotor, normally has the leader sign every slice and attach that signature to each shred. With big signatures, the overhead balloons:

By leveraging authenticated channels for data dissemination, Quantumglow is able to drop the per-shred signature in favor of a single block commitment: a short signed message committing to the entire payload of a block. A validator accepts a block only after receiving the matching block commitment. We show that under these changes leader equivocation stays just as hard as before. We use the Rotor infrastructure to disseminate the block commitment:

Trouble with Aggregates

The second problem is the hard one: aggregate signatures. In Alpenglow a certificate is a single compact signature (192 bytes) and a bitmap that represents a whole quorum of validators, thanks to BLS aggregation. The only part that grows is the bitmap (1 bit per validator) indicating who signed.

There is currently no post-quantum alternative with constant size aggregates. The candidates all grow with the number of signers (10s to 100s of KB) and involve slow (seconds!) aggregation. In the most compact options even verification is unacceptably slow. Quantumglow doesn't fight that battle. It sidesteps aggregation entirely by changing how the protocol communicates.

Certificates of Alpenglow combine a few important properties. How Quantumglow is able to preserve them in its more nuanced cert architecture sits at the core of our contribution, and explaining the new mechanic in detail would be too heavy for this article. Instead, we try to paint the intuition behind the design.

Quantumglow’s certs become local protocol events, rather than network messages. Without aggregation, a certificate can't be exchanged as a small network message, so in Quantumglow certificates stop being something nodes send, and become something nodes record locally once they have enough evidence. The gap left by certificate broadcast is filled by a new, lightweight message type called approval. Validators broadcast a single-signer approval once they see enough votes, or enough other approvals:

Performance and resilience are two critical aspects of the role certificates play in Alpenglow. Quantumglow splits the job between two types of local cert events. One type of certs is as fast as Alpenglow’s certificates, and ensures the state-of-the-art performance we need. A second type of certs is slower, but necessary to maintain the robustness. The aforementioned approval message mechanic facilitates the interplay between votes and the two cert types. Readers familiar with distributed systems may recognize similarities to Bracha-style reliable broadcast.

Fast When It Counts

In some executions of the protocol, the approval broadcast induces an extra communication step. However, such executions are only caused by serious misbehavior or network problems. This means that in normal operation of the protocol, a block can still be fast-finalized the moment 80% of stake votes to notarize it, with no additional approval round. As a result of the careful interplay between two types of certificates, Quantumglow finalizes blocks with the same latency as Alpenglow, while the extra round might appear in the slower fallback execution paths. Also the communication cost is comparable to Alpenglow. Our simulation of the average protocol finality latency is shown in the chart:

Crucially, other than upgrading the cryptography, the security assumptions didn’t change from Alpenglow, and Quantumglow enjoys the same safety and liveness properties. 

Takeaway

Post-quantum security doesn't have to mean a slower, clunkier protocol. By rethinking how blocks are authenticated and how agreement is recorded, Quantumglow keeps Alpenglow's defining speed while standing ready, should quantum computing’s threat materialize.

To briefly summarize the concrete changes to the protocol primitives:

  • BLS votes ➞ Alpenglow-tailored signature scheme Ax

  • BLS aggregation ➞ new approval mechanic off the hot path

  • Certificates as messages ➞ local only cert pools

  • Certificate events ➞ divided between two types

  • Per-shred signatures ➞ separate block commitment + symmetric authentication

The full description, with formal definitions, proofs, and signature comparisons, is in Section 5 of v1.2 of the Alpenglow whitepaper. The paper also includes a number of other improvements since v1.1.

The updated Alpenglow White Paper v1.2 (July 29, 2026)