Alpenglow: Solana's Largest Protocol Upgrade Ever | Brennan Watt, Anza

This episode of Lightseed offers a deep dive into Alpenglow, Solana's most ambitious protocol upgrade yet, exploring how it aims to revolutionize transaction finality and what this means for the network's future scalability and economic landscape.

Episode Introduction

This episode unpacks Alpenglow, Solana's groundbreaking protocol upgrade poised to deliver 100x faster transaction finality, fundamentally reshaping Solana's performance and competitive edge.

What is Anza?

• Anza, the software development firm where Brennan Watt serves as VP of Core Engineering, spun out from Solana Labs about a year and a half ago. This move included the entire core dev protocol team.
• Brennan explains this was part of “that kind of decentralization ethos and creating some healthy tension between kind of different players in the ecosystem.”
• Anza is best known for developing and maintaining the Agave client, the validator client software run by the vast majority of the Solana network.
• The company's core mission is to enhance the Solana base layer, focusing on scalability, high performance, and robust liveness—the property of a blockchain to continuously process transactions and add new blocks.

Alpenglow Overview: The Promise of Fast Finality

• The headline benefit of Alpenglow is a potential 100x improvement in transaction finality time. Finality refers to the assurance that a transaction, once confirmed, is irreversible and permanently part of the blockchain.
• Brennan Watt highlights issues with Solana's current consensus mechanism, Tower BFT (Byzantine Fault Tolerance). He notes it's "really hard to just prove from a mathematical level" and has required numerous "band-aid" fixes for fork selection.
• Currently, Solana's finality is 12.8 seconds, derived from a 32-deep tower of blocks multiplied by 400-millisecond slot times. While Solana offers "optimistic confirmation" for faster user feedback (around 1 second), true finality takes longer, which is critical for exchanges and services handling off-ramps.
• Alpenglow introduces "out-of-band finality," meaning finality is decoupled from Solana's fixed slot times. Instead, it becomes more a function of "the latency of the internet" as validators observe and exchange votes directly.
  • Strategic Implication: For investors, significantly faster finality could enhance Solana's appeal for high-frequency trading, payment systems, and other applications demanding near-instant settlement, potentially driving network adoption and token value.

Alpenglow: Enhancing Safety and Security

• Beyond speed, Brennan emphasizes Alpenglow's safety and security improvements, which he describes as "just as important."
• A key difference is that Alpenglow requires validators to wait for "certifications" (proof of sufficient votes) before considering a fork valid and publishing a block.
  • Tower BFT (current system): Validators optimistically build on what they perceive as the best fork, hoping votes will catch up.
  • Alpenglow: Introduces "hard cuts" where, despite optimistic pipelining, a block isn't fully published or considered valid until a supermajority of stake (e.g., 80% for finalization) has voted for it.
• This approach aims to drastically simplify fork selection because "you don't really see forking in Alpenglow." The decision becomes more binary: a block is either certified and good, or it's not.
  • Researcher Insight: The shift to a more synchronous certification model before block propagation could reduce network instability and simplify the state machine, making it easier to reason about and formally verify network safety.

Understanding Current Solana Block Building (Pre-Alpenglow)

• Jack Cuban prompts a discussion on Solana's current block production. Brennan explains:
  • One leader is scheduled at a time to produce blocks.
  • Transactions are sent to the leader via various paths (RPCs, Jito, or directly to the TPU - Transaction Processing Unit).
  • The leader bundles transactions into a block and streams it out in "slices" or "shreds" (smaller batches of transactions) rather than waiting for a full block. This is crucial for Solana's performance.
  • Proof of History (PoH) runs in the background, a verifiable delay function (VDF) that involves continuous hashing. PoH creates a cryptographic clock, providing a verifiable passage of time and ordering of events, with "ticks" (hashes) included in blocks.

The Role of Erasure Coding in Solana's Block Propagation

• Jack asks for more detail on how blocks, cut into "shreds," are broadcast.
  • Brennan explains that erasure coding (specifically, Reed-Solomon codes) is used to ensure all nodes receive all block data efficiently and reliably, even with packet loss or some malicious nodes.
    • A block slice (e.g., 32 data shreds, roughly 32KB) is encoded to generate additional "coding shreds" (e.g., 32 coding shreds, creating 100% overhead).
    • Out of the total (e.g., 64 shreds), a node only needs to receive a subset (e.g., any 32 shreds) to reconstruct the entire original data.
    • "As long as you know like roughly half or 2/3... I'm going to observe all of those blocks," Brennan states. A repair mechanism also exists for nodes to request specific missing shreds.
    • Technical Note: Erasure coding is a method of data protection where data is broken into fragments, expanded and encoded with redundant data pieces, and then stored across different locations. It allows for the reconstruction of data even if some fragments are lost.

Current Solana Voting and Finality Mechanism (Pre-Alpenglow)

• Continuing the explanation of the current system:
  • Nodes receive block shreds, optimistically replay transactions as they arrive, and eventually assemble the full block.
  • After verifying a block, validators vote on it. These votes are currently actual transactions included in subsequent blocks.
  • Other validators observe these vote transactions. If enough votes are seen for a block, it's "optimistically confirmed."
  • The Tower BFT system involves validators building a "tower" of confirmed blocks. When this tower reaches a certain height (32 blocks), the oldest block at the bottom (the "root") is considered finalized.
  • Brennan clarifies the primary role of Proof of History (PoH) today: "The fundamental thing that Proof of History does today is say, 'hey, next leader, when are you allowed to skip?'" It prevents malicious leaders from front-running and provides a protocol for when to skip a delinquent leader.

Alpenglow's Fault Tolerance: The "20+20 Resiliency" Trade-off

• Alpenglow proposes a shift in fault tolerance assumptions.
• Brennan introduces the "20+20 resiliency" model: the system is designed to tolerate up to 20% of stake behaving maliciously and an additional 20% of stake being offline.
  • This contrasts with the traditional BFT assumption of tolerating up to 1/3 (33.3%) malicious actors.
  • Finality thresholds under Alpenglow:
    • 1-round finality: If 80% of the cluster's stake votes affirmatively on a block, it's finalized in one round of voting. This is projected to take approximately 100 milliseconds, based on current network geography and latency.
    • 2-round finality: If 60% of stake votes affirmatively, a second round of voting occurs. If 60% is observed again, the block is finalized. Brennan notes, "this two-round voting may actually at times be faster than the single-round voting... it truly does depend on like geographically where are the actual nodes."
    • Strategic Implication: This nuanced approach to finality, prioritizing speed based on real-world network conditions rather than a fixed threshold, could offer a more consistently fast user experience. Researchers should monitor how these dynamic thresholds perform under various network loads and distributions.

Likelihood of Hitting Finality Thresholds

• Brennan expresses high confidence that "the vast vast majority of the time you're going to hit 100 millisecond finalization."
• The system will inherently use whichever method (1-round at 80% or 2-round at 60%) achieves finality faster for a given block. The primary goal is the fastest possible finality.

Security Considerations of the 20+20 Model

• Jack raises the concern that moving from 33% to 20% malicious tolerance might seem like a security reduction.
• Brennan states he is "not concerned," citing the immense economic cost of acquiring 20% of Solana's total staked SOL. He argues the focus is on practical threats like well-funded groups conducting DDoS or economic attacks, rather than extreme, less probable scenarios.
• He believes the difference between 20% and 33% doesn't practically change the affordability of an attack for most potential adversaries. "I don't think it's turning the needle where someone says, 'Ah, all of a sudden it's affordable for me to attack the network.'
  • Investor Insight: While the percentage is lower, the absolute economic security (dollar value required to attack) remains extremely high. Investors should weigh this against the performance gains.

Liveness Risks with Alpenglow

• Brennan acknowledges that "anytime you're making a big change like that especially to something as critical as consensus like there's risk."
• Anza's approach involves rigorous testing in various environments before mainnet deployment. However, the transition period, upgrading the engine "while we're running the race," is inherently the riskiest.
• He also contextualizes Solana's past liveness issues by highlighting the sheer volume of transactions processed since the last major outage (over 100 billion total, or ~10 billion successful state-altering non-vote transactions), suggesting a high degree of "Lindy" (robustness proven through survival and stress).
  • Researcher Note: The phased rollout and monitoring during the transition will be critical. Studying the network's behavior during this period can offer valuable insights into managing large-scale upgrades in live, high-value blockchain networks.

Why Proof of History is No Longer Essential / The Shift to Local Clocks

• Brennan clarifies that Solana doesn't require perfectly synchronized atomic clocks across all nodes. The need is for a rough understanding of time to determine if a leader is too slow and should be skipped.
• Proof of History (PoH) currently serves this by having the next leader produce a sequence of hashes to prove they waited an appropriate amount of time before attempting to produce a block. This is computationally expensive.
• Alpenglow replaces this with a decentralized system of "skip votes."
  • Each validator uses its local clock to determine if a leader is overdue (e.g., waited 400ms).
  • They cast a skip vote. Consensus among these votes (e.g., if 80% of the cluster agrees the leader was too slow) allows the next leader to proceed.
  • "It's still very much a consensus mechanism," Brennan notes, but based on aggregated local clock observations rather than a single leader's PoH.
  • Technical Insight: This shift leverages the collective observation of time passage by many nodes, potentially offering greater resilience to individual node clock drift or manipulation than relying on a single PoH producer for skip logic.

Vote Transactions Going Away: Economic and Throughput Implications

• Alpenglow proposes moving validator votes off-chain.
  • Economic Impact:
    • Currently, vote transactions incur costs for validators (Brennan estimates roughly 1 SOL per day for smaller validators), which can be significant.
    • With Alpenglow, these votes become "out of band" and essentially free for validators, which is a "big boon" for the long tail of smaller operators.
    • Crucially, an aggregated summary of votes, or a "certificate," proving the voting outcome, will still be recorded on-chain. This maintains provability and aids developers in understanding network decisions.
  • IBRL (Input Block Rate Limiting) and Network Throughput:
    • Vote transactions currently constitute the majority of transactions and data in a Solana block (consuming roughly half a megabyte per block every 400ms).
    • Removing these from blocks significantly reduces the amount of data that needs to be propagated, freeing up network bandwidth. Brennan mentions the certificate is "less than a thousand bytes," a massive reduction.
    • This is vital for improving IBRL, as network bandwidth is a primary constraint on how many transactions the network can process.
    • Actionable Insight: Reducing validator operational costs could improve network decentralization by making it more viable for smaller entities to participate. Increased throughput from freed-up block space could lead to lower transaction fees during congestion and support more applications.

Network Latency: The Real Bottleneck

• Referencing a chart from the "Scaler Die" presentation, Jack points out that network latency, not consensus computations, is the dominant factor in overall transaction processing time.
• Brennan concurs: "Network is what's really driving how you can tweak these timings." He notes that compute is "almost free" in comparison, and disk I/O is often mitigated by hot data residing in memory.
• Optimizing for network latency involves balancing block size, erasure coding schemes, and node geographical distribution, all while maintaining decentralization.

Future Rewards for Relays and Voters Post-Alpenglow

• With vote transactions moving off-chain, the question of incentivizing correct voting and data relay arises.
• Brennan emphasizes a "markets and incentives all the way down" philosophy.
• While current voting is tied to inflation rewards, incentives for other crucial activities like data relay via Turbine (Solana's block propagation protocol) or repair (fetching missing block data) are "a little more handwavy."
  • Alpenglow aims to make these incentives more explicit, but Brennan admits, "I'm not sure exactly what that's going to look like in the end." Key challenges include measuring the value provided by relayers and distinguishing honest network issues from adversarial behavior.
  • Researcher Focus: The design of these new incentive mechanisms will be critical for maintaining network health and performance. It's an area ripe for economic modeling and game-theoretic analysis.

Current Incentives for Running Relays on Solana

• Today, relays are often run by entities with a strong economic incentive for fresh data, such as traders who benefit from low-latency state updates.
• Brennan also acknowledges that some relay activity might be associated with "nefarious activities" like observing transaction flow for MEV (Maximal Extractable Value) opportunities.
• Anza's philosophy is to observe such "out-of-protocol" innovations and, where beneficial, pull them "in-protocol" to enhance transparency and security for all network participants.

MEV, Sandwich Attacks, and Alpenglow's Role

• Jack asks about strategies for addressing parasitic MEV, like sandwich attacks, where an attacker front-runs and back-runs a victim's trade to profit from price slippage.
• Brennan outlines a multi-step plan that Alpenglow facilitates:
  1. Ship Alpenglow (for faster finality and other improvements).
  2. Move to asynchronous execution of transactions.
  3. Re-evaluate multi-dimensional fees.
  4. Implement multiple concurrent leaders.
• He believes multiple concurrent leaders are key: "A lot of the problem when you look at sandwiching today comes back to the fact that we have one leader at a time." A single leader has a temporary monopoly on transaction ordering.
• With multiple leaders producing blocks simultaneously, it becomes much harder for any single leader to censor transactions or guarantee a sandwich attack, as other leaders would likely include the transaction to earn fees. This creates a more competitive and censorship-resistant environment.
  • Strategic Consideration: If successful, this approach could significantly reduce certain forms of MEV on Solana, improving the trading experience for users and potentially making Solana a more attractive platform for DeFi.

Alpenglow's Ambitious Timeline

• While Jack mentions an early 2026 timeline, Brennan expresses a more aggressive target: "We would love to be standing on the stage in Abu Dhabi at Breakpoint and talking about how it's doing on mainnet." Breakpoint is Solana's annual conference, typically held late in the year (e.g., Q4). This implies a target of late 2024 or early 2025.
• He acknowledges this is "incredibly aggressive" but that the team is already far along with local testing.

Alpenglow's Impact on MEV Capture Dynamics

• Faster finality and improved IBRL are Anza's primary levers for influencing the MEV landscape.
• Brennan argues that a faster, lower-latency system benefits everyone by allowing quicker oracle updates and a more synchronized global state view.
• While sophisticated actors will always seek an edge, "the faster we can construct the chain to shrink slot times, increase the number of transactions that can get in to reduce congestion... the better it is for everyone."
• The philosophy is that even if per-trade MEV opportunities shrink, the overall economic activity and volume will increase, benefiting validators and the ecosystem. He also distinguishes between parasitic MEV and beneficial MEV (e.g., arbitrage, liquidations).

Solana's Core Experiment: Low Fees, High Throughput

• Brennan affirms Jack's characterization of Solana as an experiment in achieving significant economic value for validators through massive throughput and low fees, rather than high individual transaction fees. This experiment, he implies, has been successful so far.

Anza's Shift: From Defensive to Offensive

• Brennan agrees with Jack's observation that 2024 felt more "defensive" (addressing network congestion, stabilizing) while 2025 looks more "offensive" (proactive upgrades like Alpenglow).
• He notes that crises (like the "TrumpCoin launch" which heavily stressed the network) are effective for rallying the team to solve immediate problems. The current stability allows for more "intentional" development and tackling future challenges.
  • Brennan Watt: "For the first time, I think some of the problems were not quite in the core client, but maybe some of the surrounding infra is where we had some more issues."

Alpenglow and Fire Dancer: Collaboration and Competition

• Fire Dancer is an independent Solana validator client being developed by Jump Crypto, aiming for extremely high performance.
• Brennan describes the relationship as healthily competitive and collaborative. Fire Dancer benefits from Agave's battle-hardened experience, while Agave can learn from Fire Dancer's fresh perspectives.
• Alpenglow's design, particularly its simplification of consensus (e.g., removing PoH's core timing role), could make implementation easier for the Fire Dancer team. However, coordinating development timelines for such major protocol changes across multiple client teams is a challenge.
  • Investor Note: A multi-client ecosystem is generally seen as positive for network resilience. The interplay between Agave and Fire Dancer, especially around major upgrades like Alpenglow, will be important to watch.

The ETH Zurich Research Team's Integration at Anza

• The research team that developed the foundational ideas for Alpenglow, hailing from ETH Zurich (a top European university, coincidentally not related to Ethereum), initially published a paper critical of some aspects of Solana's then-current design.
• Anatoly Yakovenko (Solana co-founder) engaged with them, leading to them joining Anza.
• Brennan praises their "big brains" and expertise in "provably correct" systems, which is invaluable for designing robust protocols.
• He stresses the importance of this team being integrated within Anza, working on the production client, rather than being a detached academic unit. This ensures their research is pragmatic and aligned with shipping functional code. "It's a huge part of our identity to ship iterate learn in production."

Governance for Alpenglow: A Maturing Process

• Solana's governance for protocol changes has evolved. Brennan outlines three tiers:
  1. Client-specific improvements: Handled internally by client teams (low friction).
  2. Protocol-level changes affecting all clients: Managed via the SIMD (Solana Improvement Document) process, requiring consensus among client development teams.
  3. Economic changes to the protocol: Require a formal governance vote by all validators, weighted by stake (e.g., SIMD-0092 regarding priority fee distribution).
• Alpenglow is a protocol change (requiring SIMD approval) and has economic implications (e.g., reduced vote costs for validators). While it might go to a full governance vote, Brennan anticipates strong support due to its benefits.
  • Researcher Insight: Solana's governance model is adapting to a multi-client, higher-stakes environment. The handling of Alpenglow will be a key test of this evolving framework.

Common Misconceptions About Solana

• Brennan notes that many disagreements stem from misunderstandings or comparing metrics across blockchains without full context (e.g., Solana's TPS often including vote transactions, which Alpenglow will change).
• He cautions against "philosophers larping as distributed systems engineers" and emphasizes that the "real alpha is always on GitHub" – the code and its actual performance matter most.

Other Exciting Developments at Anza for 2025

• Beyond Alpenglow, Anza is working on several key improvements:
  • Doubling Block Limit: A primary enabler is shifting block retransmission from kernel syscalls to XDP (eXpress Data Path), a Linux kernel technology allowing high-performance packet processing in user space. This reduces data copies and CPU overhead.
  • Reducing Slot Times: Alpenglow's efficiencies (especially with vote aggregation) are expected to enable significantly shorter slot times, with a target of around 200 milliseconds (down from 400ms).
  • Networking Efficiency: Ongoing work to reduce unnecessary network traffic, like a 25% reduction in gossip traffic with the recent 2.2 client rollout.
  • Scheduler Bindings: Brennan calls this "the alpha right there," potentially as impactful as Alpenglow. This involves creating hooks or APIs allowing third parties to implement custom transaction scheduling logic without forking the entire Agave client. This could unlock innovations in MEV optimization, transaction filtering for compliance, application-specific sequencing, and more.
  • Strategic Implication: Scheduler bindings could foster a new ecosystem of specialized block builders or schedulers on Solana, similar to MEV-Boost on Ethereum but potentially more integrated and flexible. This is a critical area for AI researchers interested in on-chain scheduling and resource allocation.

The 400ms Slot Time: Not Sacred

• The current 400ms slot time is not immutable. Brennan explains it was a practical choice around which many parameters were set.
• Shorter slot times offer faster feedback and a fresher network state view. The main challenge is managing the overhead associated with block boundaries and leader handoffs, which occur more frequently with shorter slots. Alpenglow's reduction in vote overhead is key to making shorter slot times viable.
• Faster slot times could also lead to faster epochs (the period over which validator sets and staking rewards are calculated, currently ~2 days), which would mean shorter unbonding periods for staked SOL.
  • Investor Action: Shorter unbonding periods would increase SOL liquidity and reduce the opportunity cost of staking, potentially attracting more stakers and institutional capital.

Conclusion: The Road Ahead for Solana and Anza

Brennan Watt's insights reveal Alpenglow as more than just a speed upgrade; it's a foundational shift enabling a cascade of further improvements to Solana's efficiency, economics, and developer ecosystem. He encourages listeners to engage with the technical details via whitepapers and blog posts, emphasizing that the true progress is visible in the open-source development on GitHub.

Reflective and Strategic Conclusion

Alpenglow signifies a major leap in Solana's quest for high performance and scalability, with faster finality and reduced overhead paving the way for shorter slot times and enhanced network capacity. Crypto AI investors and researchers should closely monitor Alpenglow's rollout and the development of features like scheduler bindings, as these will create new opportunities for sophisticated on-chain strategies and applications.