Solana 承诺更快的最终结果。验证者现在必须证明它有效

Alpenglow is running through Solana’s testing networks, while mainnet still relies on its existing consensus. The proposed switch would change how validators agree that a block is final. A 150 millisecond target is a performance claim under conditions, not a promise that every user payment clears in that time.

Summary SIMD-0326 remains listed as pending mainnet activation in Anza’s validator schedule.

The tracker lists Agave 4.3.0 for Alpenglow and a lower 4.2.2 mainnet version floor.

The initial proposal brings Votor consensus but retains Turbine data propagation.

Alpenglow’s proposal describes a 20% adversarial plus 20% unresponsive stake model.

A September 28 feature activation window did not itself schedule Alpenglow’s mainnet switch.

Solana’s most consequential consensus change is moving through a sequence of validator tests. Anza’s feature gate tracker lists SIMD-0326, Alpenglow, among pending mainnet activations. It records testnet and devnet activation positions and identifies Agave 4.3.0 as the software version tied to the feature. The mainnet version floor shown in the same snapshot was 4.2.2, with 4.3.0 listed as the next expected floor. A planned version floor and a live consensus feature are different milestones.

The earlier testnet report described the shift into wider validator testing. A later devnet account noted both testing networks, while mainnet continued with its current consensus. That is the status against which any promised speed gain must be judged.

JUST IN: Solana’s biggest consensus upgrade, Alpenglow, enters testnet this week

The upgrade marks a major step toward modernizing Solana’s consensus system, with testing set to begin ahead of its potential mainnet deployment. pic.twitter.com/L4oAQU2nWp — crypto.news (@cryptodotnews) September 23, 2026

September 28 was a calendar trap

One schedule entry said mainnet feature activations would resume on September 28. It did not say Alpenglow itself would switch on that day. The tracker separately names Alpenglow as pending. Treating a date for resuming a queue of feature gates as a scheduled protocol cutover turned a process marker into a false deadline. A September 29 correction traced that confusion and said Anza had rejected the claimed launch date.

The distinction is material. Validators can adopt a software release containing dormant code without activating the feature. A version floor can rise after a stake threshold and epochs pass. A separate feature gate can enable the new behavior. Users who see a version number change on a dashboard have not thereby seen a faster finality protocol go live.

The correct news hook is that the testing and activation process is still open after the widely circulated date. A final mainnet window requires an explicit schedule, operator preparation and evidence from public testing. None of those steps is replaced by a social post describing an upgrade as imminent.

Votor changes votes, while Rotor waits

The SIMD-0326 proposal defines the initial move primarily around Votor, the new consensus mechanism. It explicitly leaves Rotor, the proposed data dissemination replacement, for a separate change and keeps the existing Turbine propagation initially. Marketing descriptions of a complete Alpenglow stack can blur that scope.

Consensus answers when enough validators have agreed on a block that it should be treated as final under the protocol. Data propagation answers how the block reaches those validators. Execution answers whether a transaction successfully ran. An app also waits for its RPC provider to report the outcome. A faster vote cannot eliminate every other delay in that path.

The 150 millisecond figure is best read as a finality objective under favorable network conditions, measured at the consensus layer. It is not an end-to-end checkout time for a user whose wallet must sign, submit, reach a leader, be included in a block, execute and return through an RPC service. A useful public benchmark should name its start and end points. A stopwatch started at block proposal is not comparable to one started when a customer presses Send.

The proposal replaces a voting arrangement with a different security and liveness tradeoff. It describes a 20 plus 20 model that can tolerate an adversarial share and a separate nonresponding share under stated assumptions. The authors explicitly note that one-round voting does not deliver the same 33% Byzantine threshold achievable by two-round designs. That admission belongs beside the speed claim, not in a footnote.

A two-column test prevents a misleading benchmark

One column should measure protocol finality from a validator’s view: elapsed time from a proposed block to a finalization certificate, including the distribution of slow outcomes. The second should measure a user’s confirmed transaction: submission through execution, inclusion, finality and the RPC response. The difference between those columns is the work the consensus headline does not measure.

Suppose a test reports 150 milliseconds for finalization after proposal, but transaction inclusion waits one 350 millisecond slot and RPC delivery takes another 100 milliseconds. The customer sees at least 600 milliseconds under those illustrative assumptions, before adding signing or retries. The calculation is 350 plus 150 plus 100. These are hypothetical timings, not measurements of Alpenglow in production. They show why a subsecond consensus figure need not be the same as a subsecond payment experience.

Median latency can hide the cases operators care about most. A validator stuck behind a poor network route, a temporary partition, a missing vote, or heavy replay work might see a long tail. Exchanges and payment providers generally build finality policies for rare bad conditions, not just a benchmark median. A credible rollout would publish percentile results, recovery behavior and the consequences of failed leaders.

The slot-time proposal is another variable. It seeks staged reductions from a 400 millisecond target toward 200 milliseconds. Slot interval and finality are related but distinct; claiming that every shorter slot proves Votor works confuses two upgrades. The earlier validator test account followed the protocol testing before this wider rollout.

Validators have to test the failure cases

A network’s happy path is the easiest environment in which to produce a fast number. A mainnet candidate must survive validators joining late, messages delayed across regions, software restarts, leader failures and conflicting views of the chain. The Alpenglow migration proposal addresses the handoff from the old voting state to the new one. A correct steady-state protocol can still be exposed by a poor transition.

Tests should show whether the cluster reaches one consistent final decision after a partition heals, how quickly it resumes if a meaningful share of stake goes offline, and whether nodes with different compatible versions report the same outcome. The testnet is valuable because validators with different infrastructure encounter conditions a controlled lab may miss. It cannot exactly reproduce the economic incentives and traffic of a live network.

You might also like: D3 offers priority access to new domains via Solana, Hyperliquid vaults

The client mix matters. Anza’s tracker marked Firedancer and Frankendancer as unsupported for the Alpenglow row in the observed snapshot. That is a compatibility status in a specific schedule, not a permanent claim about either client. A production migration must account for stake running each implementation or specify what those operators need to change.

Validator incentives are part of the test as well. Running a new voting protocol can alter bandwidth, hardware demands and participation costs. If smaller operators drop out because they cannot meet requirements, the faster network could end up with fewer independent participants. Actual operator counts and stake distribution after activation would test that tradeoff.

A fast certificate and a slow certificate serve different conditions

The protocol does not depend on one route always finishing in 150 milliseconds. SIMD-0326 defines fast finalization when validators representing 80% of stake notarize a block in one round. Its slower route relies on two rounds involving 60% of stake and both notarization and finalization certificates. A leader may fail to deliver a valid block in time, in which case validators can vote to skip that slot. The design includes certificates for skipped slots and a fallback path. A headline benchmark that measures only the 80% fast route would omit exactly the situations that make finality valuable.

The distinction can be put into a practical test. For every proposed slot in a day, count the share finalized with the fast certificate, the share using the slower path, and the share skipped. Give the median and 95th and 99th percentiles separately for each class. A fast median is useful, but an operator needs to know how frequently the network leaves the fast path and how long it then takes to recover. A payment service handling thousands of receipts a day may experience a long-tail event even if that event is rare for an individual transfer.

A certificate is a compact, verifiable record of stake-weighted agreement. It is not a vote by a fixed number of machines. Ten small validators cannot substitute for one validator representing a large amount of stake merely by outnumbering it. Reporting validator counts without stake distribution would therefore misstate the safety test. The correct figures are stake participating in each round, stake that is offline, and stake that disagrees. Those figures need timestamps because stake assignments and operator availability change.

The proposal says a directly finalized block also decides its ancestors: prior blocks in its chain become finalized and omitted slots are treated as skipped. That means a dashboard can show finality arriving in groups after a slow period. A measurement that averages those ancestors’ apparent completion times into one attractive number would be hard to compare with a user who waited through the pause. The test should retain each block’s original proposal time and certificate observation time.

The protocol authors do not claim the same adversarial threshold as every competing design. Their 20 plus 20 framing accepts a different balance between Byzantine faults and unresponsive stake in exchange for a shorter normal path. Whether that trade is acceptable is a governance judgment informed by threat modeling and performance evidence, not a matter settled by a single fastest-case demonstration. The unusually candid security section in SIMD-0326 makes it possible to report the trade without attributing motives to either side.

Switching consensus requires a shared starting block

The migration document addresses a problem that a speed chart cannot show. Old and new consensus cannot safely run as independent histories after the cutover. Validators must agree on the final old block that becomes the parent of the first Alpenglow block. The document calls that shared point the Alpenglow genesis block. If operators disagree on it, their subsequent finality certificates would refer to incompatible histories.

The proposed handoff begins after a feature activation slot, but the boundary used for migration sits 5,000 slots later. The extra interval is meant to avoid the start of an epoch. The process then waits for a block meeting a strong optimistic confirmation condition, with votes representing at least 82% of stake in the proposal’s specified pattern. Validators sign a genesis vote for a common ancestor block. An 82% genesis certificate gives them the evidence to switch. The arithmetic of those thresholds is part of the migration design, separate from Votor’s 80% fast finalization route after the switch.

A validator receiving the genesis certificate verifies its signatures against the relevant epoch’s BLS keys and broadcasts it. The plan then initializes Votor from the selected block and stops TowerBFT for later slots. It rolls back blocks after the selected genesis point and resets the associated state before processing new blocks. The document argues this rollback is safe because user transactions are not packed into those interim blocks. That claim deserves a test on the actual cluster; it is not something an app operator can verify from the finality headline alone.