Solana has promoted Quantumglow, a proposed post-quantum adaptation of Alpenglow designed to protect consensus while preserving the network’s fast finality.
Summary
- Quantumglow proposes changes to validator signatures and block authentication without announcing a deployment date.
- Anza published the underlying research in July, before Solana’s latest video explainer.
- Alpenglow’s mainnet activation is separate from the proposed post-quantum changes to its cryptography.
- Bitcoin’s BIP-360 targets exposed public keys, with additional signatures needed for more complete protection.
Solana Developers described the proposal in an Oct. 22 video post, presenting it as a way to secure agreement between validators against quantum attacks. Solana’s main account shared the explainer and said the network “has been early in quantum readiness and remains ahead in its preparation.”
Neither announcement supplied an activation date or identified a Quantumglow-specific Solana Improvement Document, known as a SIMD. The developer post described an adaptation under proposal, without announcing a deployed security upgrade.
The research predates the latest explainer. Anza published its Quantumglow overview on July 30, naming Quentin Kniep, Kobi Sliwinski and Roger Wattenhofer as its authors and directing readers to Section 5 of the updated Alpenglow whitepaper.
Quantumglow changes how validators authenticate agreement
Anza’s July overview identifies two obstacles to replacing Alpenglow’s existing cryptography. Post-quantum signatures take more space, while the compact signature aggregation used to prove validator agreement has no comparable ready replacement under the researchers’ requirements.
The authors propose Ax, short for Alpenglow XMSS, a hash-based signature scheme tailored to the protocol. Validators would exchange and cache one-time public-key material ahead of use, reducing the information that must accompany later signatures.
For block authentication, Anza describes a signed commitment covering the block payload, supported by authenticated communication channels. Its design removes the need to attach a large post-quantum signature to every piece of block data.
The accompanying distributed-quorum-signature research explains the second change. Kniep, Jakub Sliwinski and Wattenhofer describe moving certificates from messages sent across the network to events recorded locally after a node gathers enough evidence.
Their paper, submitted July 20, uses ordinary signatures and an approval-broadcast mechanism. It separates evidence supporting safety from evidence supporting liveness, the protocol’s ability to keep making progress.
The researchers say each message remains a constant size regardless of node count, although total communication grows quadratically. Their performance claim concerns the proposed design and its stated assumptions, without establishing a measured mainnet result.
Solana’s Alpenglow rollout has a separate activation record
Solana Foundation’s upgrade page identifies Alpenglow as live on mainnet following activation in epoch 1064 on Oct. 21. The Foundation lists approximately 150 milliseconds as its finality target, compared with 12.8 seconds for TowerBFT.
The Foundation records Alpenglow consensus beginning at slot 459,653,000, after a genesis block certified by votes from 446 of 654 validators. Its documentation separates the deployed Votor voting system from Rotor, a data-distribution component reserved for a later release.
Before that handoff, crypto.news previously reported the planned consensus migration and its operator requirements. The Oct. 19 coverage documented the need for compatible validator software and sufficient vote-account funding.
SIMD-0326 specifies the Votor portions of Alpenglow and references version 1.1 of its whitepaper. The proposal explicitly leaves Rotor for a separate SIMD, showing that the original consensus specification does not cover every component discussed in subsequent research.
Solana Foundation says Alpenglow leaves transaction execution, programs, and transaction fee mechanics unchanged. Its migration guidance states that ordinary users do not need to change how they sign, send, or approve transactions.
The removal of on-chain votes creates separate changes for analytics services. As detailed in Oct. 20 coverage of vote-transaction removal, the Foundation instructs explorers to reset metrics that counted validator votes alongside user transactions.
Wallet protection requires work beyond consensus
Anza’s April 27 security assessment identifies distinct quantum vulnerabilities in accounts, block propagation, consensus, and user-defined programs. Max Resnick and Sam Kim warn that an attacker capable of breaking Ed25519 could forge account signatures, while forged consensus votes could support conflicting confirmations.
Their checklist calls for work on account migration, transaction signature verification, networking and program-level cryptographic tools. The assessment makes no commitment to a single post-quantum signature scheme.
Early Falcon implementations formed another part of that preparation. April 28 coverage documented Anza and Firedancer testing the signature technology, with the teams describing it as an option for possible future activation.
Anza’s assessment describes a prototype migration proof that binds an existing account to a new post-quantum public key. The authors distinguish such account migration from optional vault programs, which cannot independently secure consensus, networking, or every application using vulnerable signatures.
Bitcoin’s BIP-360 addresses exposed keys
Bitcoin’s BIP-360 specification proposes Pay-to-Merkle-Root outputs through a soft fork, removing the key-path spending option used by Taproot. Its authors describe protection against attacks on public keys exposed for long periods.
The draft explicitly separates that protection from attacks conducted while a spending transaction waits for confirmation. Its authors say protection against those shorter exposures may require post-quantum signatures through a separate proposal.
BIP-360’s motivation describes quantum key recovery as deriving a private key from a public key by breaking the discrete logarithm assumption. The authors say the timing and eventual viability of a cryptographically relevant quantum computer remain unclear. Their proposal does not set a date when such an attack becomes practical or establish that present hardware can perform it.
The repository lists BIP-360 as a draft authored by Hunter Beast, Ethan Heilman, and Isabel Foxen Duke. Its abstract states that the proposed output type retains script-tree functionality while removing the quantum-vulnerable key-path spend.
Be the first to comment