Trusted Editorial content, reviewed by leading industry experts and seasoned editors. Ad Disclosure

Solana core developers have pushed a sweeping consensus overhaul, “Alpenglow” (SIMD-0326), into the ecosystem’s formal governance track, setting up a validator vote that, if approved, would replace TowerBFT and re-architect finality and validator incentives on mainnet-beta. The proposal’s authors—Quentin Kniep, Kobi Sliwinski, and Roger Wattenhofer—describe Alpenglow as “a major overhaul of Solana’s core consensus protocol,” designed to supplant “the existing Proof-of-History and TowerBFT mechanisms” with a design that targets block finalization “as low as 100–150 milliseconds.”

Voting Process For Solana ‘Alpenglow’ Starts

The governance post lays out a three-phase timeline: discussion through epochs 833–838, stake-weight capture in epoch 839, and a binding vote across epochs 840–842 using claimable vote tokens sent to “Yes,” “No,” or “Abstain” accounts. Passage hinges on a supermajority threshold: Yes must be at least two-thirds of Yes+No, with a 33% quorum that counts abstentions. As of today, Solana is in epoch 834, making the discussion window active and the vote window scheduled several epochs out.

At the heart of Alpenglow is Votor, a direct-vote, leader-pipelined finality protocol that shifts Solana away from on-chain vote transactions and heavy gossip toward off-chain vote exchange with local signature aggregation. Validators vote to notarize or skip blocks; leaders aggregate those votes eight slots later and submit compact proofs. The authors argue this design cuts latency dramatically and reduces bandwidth, while a “20+20” liveliness model aims to tolerate up to 20% adversarial and 20% unresponsive validators without halting progress. “Alpenglow… enables much lower latency, improved fault tolerance, and generally greater protocol efficiency,” the post asserts.

The upgrade also rewires validator economics. Because voting moves off-chain, the SIMD introduces a Validator Admission Ticket (VAT), a fixed per-epoch fee “initially set to 1.6 SOL per epoch,” burned to maintain an economic barrier roughly comparable to today’s on-chain vote-fee regime. Validators are “required to cast exactly one valid vote per slot”; conflicting votes are detectable, and persistent non-participation renders a validator ineligible for rewards and at risk of removal from the active set.

Leaders receive compensation equal to the per-slot vote rewards of the votes they aggregate, plus a flat bonus when they include fast-finalization/finalization certificates. In a follow-up thread post, Wattenhofer explains the 1.6 SOL figure as approximately 80% of current vote costs to ensure no operator is worse off at the “AlpenSwitch.”

If adopted, Alpenglow would make a visible semantic change at the client layer: the authors note that optimistic confirmation would be superseded by actual finality at sub-second timescales. The stated aim is to bring confirmation latencies in line with Web2 user expectations while tightening safety guarantees that were harder to formalize under TowerBFT. The proposal’s documentation points readers to a 50+ page white paper and independent analyses, but emphasizes that the initial rollout focuses on finalization and voting; a new data dissemination protocol, Rotor, would follow in a separate SIMD.

Governance mechanics for the vote mirror Solana’s prior advisory processes but with higher stakes. Vote tokens will be claimable via an adapted Merkle distributor; validators then send those tokens to the designated choice accounts during the epoch-bounded window. The foundation’s governance post states, “If the sum of Yes votes is equal to or greater than 2/3 of the total sum of Yes + No votes, the proposal will pass,” and “Abstain” contributes to quorum but not to the supermajority tally. Stake weights and a public tally script will be published for independent verification.

Community feedback has quickly homed in on operational risk and rollout discipline. One validator-oriented response urges the SIMD authors to embed “a testing, deployment and fallback plan” before a mainnet decision, likening the scope of change to other industry-scale protocol transitions. Others probe specifics around the VAT level, transaction expiry in a post-PoH world, leader equivocation handling, and effects on MEV auctions and client UX when slices of a block are ignored under certain failure modes. These threads underscore that while the performance headline—150 ms finality—is eye-catching, the vote will likely hinge on the comfort level with safety proofs, incentive edge-cases, and the migration path.

At press time, SOL traded at $181.89.

Featured image created with DALL.E, chart from TradingView.com

Editorial Process for bitcoinist is centered on delivering thoroughly researched, accurate, and unbiased content. We uphold strict sourcing standards, and each page undergoes diligent review by our team of top technology experts and seasoned editors. This process ensures the integrity, relevance, and value of our content for our readers.

Special thanks to Sacha Yves Saint-Leger & Joseph Schweitzer for review.

Sharding is one of the many improvements that eth2 has over eth1. The term was borrowed from database research where a shard means a piece of a larger whole. In the context of databases and eth2, sharding means breaking up the storage and computation of the whole system into shards, processing the shards separately, and combining the results as needed. Specifically, eth2 implements many shard chains, where each shard has similar capabilities to the eth1 chain. This results in massive scaling improvements.

However, there’s a less-well-known type of sharding in eth2. One which is arguably more exciting from a protocol design point of view. Enter sharded consensus.

Sharding Consensus

In much the same way that the processing power of the slowest node limits the throughput of the network, the computing resources of a single validator limit the total number of validators that can participate in consensus. Since each additional validator introduces extra work for every other validator in the system, there’ll come a point where the validator with the least resources can no longer participate (because it can no longer keep track of the votes of all of the other validators). The solution eth2 employs to this is sharding consensus.

Breaking it down

Eth2 breaks time down into two durations, slots and epochs.

A slot is the 12 second time-frame in which a new block is expected to be added to the chain. Blocks are the mechanism by which votes cast by validators are included on the chain in addition to the transactions that actually make the chain useful.

An epoch is comprised of 32 slots (6.4 minutes) during which the beacon chain performs all of the calculations associated with the upkeep of the chain, including: justifying and finalising new blocks, and issuing rewards and penalties to validators.

As we touched upon in the first post of this series, validators are organised into committees to do their work. At any one time, each validator is a member of exactly one beacon chain and one shard chain committee, and is called on to make an attestation exactly once per epoch – where an attestation is a vote for a beacon chain block that has been proposed for a slot.

The security model of eth2’s sharded consensus rests upon the idea that committees are more or less an accurate statistical representation of the overall validator set.

For example, if we have a situation in which 33% of validators in the overall set are malicious, there is a chance that they could end up in the same committee. This would be a disaster for our security model.

So we need a way to ensure that this can’t happen. In other words, we need a way to ensure that if 33% of validators are malicious, only about ~33% of validators in a committee will be malicious.

It turns out we can achieve this by doing two things:

1. Ensuring committee assignments are random
2. Requiring a minimum number of validators in each committee

For example, with 128 randomly sampled validators per committee, the chance of an attacker with 1/3 of the validators gaining control of > 2/3 committee is vanishingly small (probability less than 2^-40).

Building it up

Votes cast by validators are called attestations. An attestation is comprised of many elements, specifically:

• a vote for the current beacon chain head
• a vote on which beacon block should be justified/finalised
• a vote on the current state of the shard chain
• the signatures of all of the validators who agree with that vote

By combining as many components as possible into an attestation, the overall efficiency of the system is increased. This is possible since, instead of having to check votes and signatures for beacon blocks and shard blocks separately, nodes need only do the math on attestations to be informed about the state of the beacon chain and of every shard chain.

If every validator produced their own attestation and every attestation needed to be verified by all other nodes, then being an eth2 node would be prohibitively expensive. Enter aggregation.

Attestations are designed to be easily combined such that if two or more validators have attestations with the same votes, they can be combined by adding the signatures fields together in one attestation. This is what we mean by aggregation.

Committees, by their construction, will have votes that are easy to aggregate because they are assigned to the same shard, and therefore should have the same votes for both the shard state and beacon chain. This is the mechanism by which eth2 scales the number of validators. By breaking the validators up into committees, validators need only to care about their fellow committee members and only have to check very few aggregated attestations from each of the other committees.

Signature aggregation

Eth2 makes use of the BLS signatures – a signature scheme defined over several elliptic curves that is friendly to aggregation. On the specific curve chosen, signatures are 96 bytes each.

If 10% of all ETH ends up staked, then there will be ~350,000 validators on eth2. This means that an epoch’s worth of signatures would be 33.6 megabytes which comes to ~7.6 gigabytes per day. In this case, all of the false claims about the eth1 state-size reaching 1TB back in 2018 would be true in eth2’s case in fewer than 133 days (based on signatures alone).

The trick here is that BLS signatures can be aggregated: If Alice produces signature A, and Bob’s signature is B on the same data, then both Alice’s and Bob’s signatures can be stored and checked together by only storing C = A + B. By using signature aggregation, only 1 signature needs to be stored and checked for the entire committee. This reduces the storage requirements to less than 2 megabytes per day.

In summary,

By separating validators out into committees, the effort required to verify eth2 is reduced by orders of magnitude.

For a node to validate the beacon chain and all of the shard chains, it only needs to look at the aggregated attestations from each of the committees. In this way it can know the state of every shard, and every validator’s opinions on which blocks are and aren’t a part of the chain.

The committee mechanism therefore helps eth2 achieve two of the design goals established in the first article: namely that participating in the eth2 network must be possible on a consumer-grade laptop, and that it must strive to be maximally decentralised by supporting as many validators as possible.

To put numbers to it, while most Byzantine Fault Tolerant Proof of Stake protocols scale to tens (and in extreme cases, hundreds of validators), eth2 is capable of having hundreds of thousands of validators all contributing to security without compromising on latency or throughput.