Skip to content

Commit 4ace5f8

Browse files
catmcgeedatasalaryman
catmcgee
and
datasalaryman
authored
feat(blog) Upgrades blog & articles (#1468)
* larger tx sizes upgrade blog * restore /upgrades listing page * upgrades: use dynamic routes not file based routes * feat: add reduce slot times upgrade article * add social share and seo metadata to upgrade articles * feat(upgrades): add alpenglow article * add new cryptography schemes upgrade article * fix factual errors in reduced slot times article * keep approved wording for SIMD-525 * fix(upgrades): change alpenglow indexing status * fix(upgrades): fix spelling errors on alpenglow article * fix(upgrades): revise alpenglow article to reflect votor only * fix(upgrades): clarify voting mechanism in alpenglow * Update apps/web/content/upgrades/alpenglow.md Co-authored-by: Cat McGee <helloworld@mcgee.cat> * Update apps/web/content/upgrades/alpenglow.md Co-authored-by: Cat McGee <helloworld@mcgee.cat> * Update apps/web/content/upgrades/alpenglow.md Co-authored-by: Cat McGee <helloworld@mcgee.cat> * Update apps/web/content/upgrades/alpenglow.md Co-authored-by: Cat McGee <helloworld@mcgee.cat> * Update apps/web/content/upgrades/alpenglow.md Co-authored-by: Cat McGee <helloworld@mcgee.cat> * fix(upgrades): address review comments * fix(upgrades): clarify BLS syscall coverage * docs(upgrades): update new cryptography article * Clarify Alpenglow VAT and BLS pubkey ship in Agave 4.1 * Apply review suggestions: update timelines and wording on upgrade pages --------- Co-authored-by: Data Salaryman <datasalaryman@protonmail.com>
1 parent dee1a83 commit 4ace5f8

5 files changed

Lines changed: 470 additions & 0 deletions

File tree

‎apps/media/content/upgrades/alpenglow.mdx‎

Lines changed: 138 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,138 @@
1+
---
2+
title: Alpenglow
3+
description: >-
4+
Alpenglow begins Solana's next consensus upgrade with Votor, targeting roughly
5+
150ms finality while replacing vote transactions with direct validator votes
6+
and aggregate certificates.
7+
subtitle: Faster finality with Solana's next consensus protocol
8+
publishedAt: 2026-06-24T00:00:00.000Z
9+
status: published
10+
author: solana-foundation
11+
badges:
12+
- text: Under Development
13+
color: yellow
14+
variant: badge
15+
metrics:
16+
- value: 150ms
17+
label: Target finality
18+
- value: 20+20
19+
label: Adversarial plus offline stake model
20+
categories:
21+
- category: upgrades
22+
tags:
23+
- tag: announcements
24+
---
25+
26+
# Alpenglow Phase 1 - Votor
27+
28+
Q3 2026 • Solana Foundation
29+
30+
Solana is replacing its consensus protocol with Alpenglow, beginning with
31+
Votor. Alpenglow aims to simplify Solana consensus at network scale, improve
32+
performance, and provide faster finality. The target is roughly 150ms finality,
33+
compared with Solana's current roughly 400ms pre-confirmation latency and
34+
12.8-second TowerBFT finality.
35+
36+
A later Alpenglow phase is expected to replace Turbine with Rotor, a new block
37+
propagation protocol.
38+
39+
| | |
40+
| -------------------------------- | --------- |
41+
| Expected Mainnet Activation Date | Q3 2026 |
42+
| Devnet Activation | Agave 4.3 |
43+
| Breaking Change? | Yes |
44+
| Indexing Changes Required? | Yes |
45+
46+
## Technical Details
47+
48+
### Votor, Voting and Certificates
49+
50+
Voting on Alpenglow will work with a new voting algorithm called Votor. It can
51+
handle 20% of adversarial stake plus 20% of offline stake while still achieving
52+
consensus across the network.
53+
54+
TowerBFT needs a supermajority of greater than two-thirds of stake to achieve a
55+
confirmed status. Alpenglow is a marked improvement in terms of the overhead
56+
required to finalize a block.
57+
58+
Alpenglow will no longer use vote transactions. Votes are sent directly between
59+
validators, and observed votes and certificates are managed in a separate data
60+
structure called Pool, informing Votor and stored with Blokstor.
61+
62+
Voting proceeds in two rounds. In the fast path, a block can be finalized after
63+
one round if at least 80% of stake votes to notarize it. If that threshold is
64+
not reached, the protocol can continue into a second round, where certificates
65+
based on 60% stake thresholds determine notarization, finalization, or skipping.
66+
67+
There are five vote messages a validator can make:
68+
69+
- Notarization - Voting yes
70+
- Notarization fallback - Voting yes during the second round
71+
- Skip - Voting skip
72+
- Skip fallback - Voting skip for second round
73+
- Final - Voting to finalize the block
74+
75+
As voting happens, validators aggregate votes to one of the following quorum
76+
certificates depending on the vote state:
77+
78+
- Fast finalization - Received >= 80% of stake votes to notarize in first round.
79+
Finalize.
80+
- Notarization - Received only >= 60% to < 80% of stake votes in first round.
81+
Ready for second round.
82+
- Finalization - Received >= 60% of stake votes in the second round. Finalize.
83+
- Notarization fallback - Received >= 60% of stake votes that either vote
84+
notarize or notarize fallback in the second round
85+
- Skip - >= 60% of stake votes to either skip in the first or second round
86+
87+
### Alpenglow Community Cluster
88+
89+
After running several tests for months, validators and the core development team
90+
are testing the new consensus algorithm on a community cluster. This will ensure
91+
a smooth migration from the old consensus protocol to the new one. There are
92+
already issues that were identified by the initiative and core devs are working
93+
to ensure that the network does not experience downtime during the transition.
94+
95+
### Alpenglow SIMDs
96+
97+
Alpenglow is defined across several SIMDs. The original proposal introduces the
98+
new consensus protocol, while the follow-up SIMDs cover migration, vote account
99+
changes, fast leader handoff markers, and VAT implementation details.
100+
101+
| | |
102+
| ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------ |
103+
| [SIMD-0326](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md) | Alpenglow Consensus Protocol |
104+
| [SIMD-0337](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0337-parent-ready-update-marker.md) | Markers for Alpenglow Fast Leader Handover |
105+
| [SIMD-0357](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0357-alpenglow_validator_admission_ticket.md) | Alpenglow Validator Admission Ticket |
106+
| [SIMD-0384](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0384-alpenglow-migration.md) | Alpenglow Migration |
107+
| [SIMD-0387](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0387-bls-pubkey-management-in-vote-account.md) | BLS Pubkey Management in Vote Account |
108+
109+
**Shipping timeline:** Both the Alpenglow Validator Admission Ticket (VAT,
110+
SIMD-0357) and BLS Pubkey Management in Vote Account (SIMD-0387) ship in Agave
111+
4.3, estimated Q3 2026. Validator operators must create and register their BLS
112+
key onchain **before** the VAT feature gate is activated — otherwise their
113+
validator will not be admitted under Alpenglow consensus.
114+
115+
---
116+
117+
### Phase 2 - Rotor
118+
119+
Alpenglow in its next phase is expected to replace Solana Turbine with a new
120+
block propagation service called Rotor. It uses the same erasure coding idea and
121+
validator stake-adjusted bandwidth from Turbine. Rotor changes the block
122+
propagation plan from a tree of nodes to a single relay layer to minimize
123+
network latency. The plan is to make this upgrade at a later stage once Votor
124+
has already been adopted by the network.
125+
126+
## About This Upgrade
127+
128+
Alpenglow represents a fundamental change to Solana's consensus layer, the first major consensus upgrade since TowerBFT. Not only does it
129+
improve on TowerBFT, but it makes the network competitive while also being safe.
130+
131+
This is a collaborative effort on the part of validators and core developers to
132+
ensure that the chain continues to deliver for users.
133+
134+
Alpenglow makes changes to how Solana thinks about blockspace, finality, voting,
135+
and rewards. Once the migration is complete, Solana will be a very different
136+
protocol.
137+
138+
**Learn more:** [Solana Upgrades](/upgrades)

‎apps/media/content/upgrades/larger-transaction-sizes.mdx‎

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
---
2+
title: Larger Transaction Sizes
3+
description: >-
4+
Solana is raising the maximum transaction size from 1232 bytes to 4096 bytes
5+
via SIMD-0296 and the v1 transaction format, unlocking ZK proofs, large
6+
multisigs, and onchain signature schemes in a single atomic transaction.
7+
subtitle: Raising the maximum transaction size from 1232 to 4096 bytes
8+
publishedAt: 2026-06-09T00:00:00.000Z
9+
status: published
10+
author: solana-foundation
11+
badges:
12+
- text: "Target Mainnet: Q3 2026"
13+
color: green
14+
variant: text
15+
metrics:
16+
- value: "4096"
17+
label: Bytes per transaction, up from 1232
18+
- value: 3.3x
19+
label: More room for ZK proofs, multisigs, and batches
20+
categories:
21+
- category: upgrades
22+
tags:
23+
- tag: announcements
24+
---
25+
26+
# Larger Transaction Sizes
27+
28+
**June 9, 2026** • Solana Foundation
29+
30+
A major upcoming upgrade to Solana raises the maximum transaction size from 1232
31+
bytes to 4096 bytes. The size increase is defined in
32+
[SIMD-0296](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0296-larger-transactions.md)
33+
and delivered through the v1 transaction format introduced in
34+
[SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md).
35+
It unlocks workloads that previously could not fit inside a single transaction,
36+
including ZK proofs, large multisigs, and some onchain signature schemes.
37+
38+
The existing `v0` and `legacy` transaction formats continue to work as they do
39+
today, so applications and wallets that don't need the larger size will be
40+
unaffected. Applications that want to take advantage of it will need to update
41+
to `v1` transactions.
42+
43+
| | |
44+
| -------------------------------- | ------- |
45+
| Expected Mainnet Activation Date | Q3 2026 |
46+
| Devnet Activation | Q3 2026 |
47+
| Breaking Change? | No |
48+
| Indexing Changes Required? | Yes |
49+
50+
## Technical Details
51+
52+
### Size Limit
53+
54+
The new per-transaction size limit is 4096 bytes, up from 1232. The previous
55+
limit was set by Solana's conservative use of a 1280-byte MTU (Maximum
56+
Transmission Unit), which after overhead left 1232 bytes for transaction
57+
payload.
58+
59+
In 2022, QUIC became the default transaction ingestion protocol, which does not
60+
specify a maximum stream size, so the maximum transaction size can be raised.
61+
62+
The ceiling stays at 4096 rather than going larger as this matches the standard
63+
4 KiB memory page used by validator hardware, which keeps per-transaction memory
64+
handling cheap and avoids forcing a single transaction to span multiple pages.
65+
66+
Once a transaction exceeds the MTU, it has to be split across multiple QUIC
67+
frames, and a single dropped frame triggers a retransmit of the whole set. This
68+
makes larger transactions more expensive to receive reliably and puts more
69+
pressure on validator in-flight buffers. Keeping the transaction size under 4096
70+
avoids this problem.
71+
72+
A 4096-byte ceiling covers a meaningful share of the use cases that have relied
73+
on bundles, letting developers land them as individual atomic transactions
74+
instead. Because larger transactions consume more validator bandwidth, the
75+
scheduler is expected to require higher priority fees to land them than smaller
76+
transactions of equivalent priority.
77+
78+
### v1 Format Requirement
79+
80+
The larger size is only available in the `v1` transaction format. `v1`
81+
transactions are identified by a leading version byte of `129` and replace the
82+
`ComputeBudgetProgram` instructions with a configuration mask carried directly
83+
in the transaction header. `v1` does not support address lookup tables, but at
84+
4096 bytes the full address list can be included directly in most cases anyway.
85+
The full format is specified in
86+
[SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md).
87+
88+
The larger size enables transaction-level workloads that did not fit inside 1232
89+
bytes, including ZK proofs such as those used by
90+
[Confidential Transfers](https://solana.com/docs/tokens/extensions/confidential-transfer),
91+
Winternitz one-time signatures, nested multisigs often used by institutions, and
92+
signature schemes like BLS.
93+
94+
### Indexing Updates
95+
96+
The v1 format changes the byte layout of every field after the version byte. Any
97+
indexer or client that decodes raw transaction bytes will need to recognize the
98+
`129` version prefix and parse the new layout.
99+
100+
Transactions sent in `v0` or `legacy` formats continue to deserialize as they do
101+
today.
102+
103+
---
104+
105+
## About This Upgrade
106+
107+
Larger transaction sizes is a significant usability improvement for Solana developers.
108+
By raising the per-transaction byte limit to 4096 bytes, this upgrade lets
109+
developers land previously oversized workloads as single atomic transactions
110+
instead of stitching them together with address lookup tables or Jito bundles.
111+
In practice this also lowers cost and latency - there are fewer signatures to
112+
pay and one single confirmation rather than several chained transactions.
113+
114+
This upgrade addresses a practical ceiling that application teams have had to
115+
design around since the early days of Solana, and brings a whole new class of
116+
capabilities that we're looking forward to support.
117+
118+
**Learn more:** [Solana Upgrades](/upgrades)

‎apps/media/content/upgrades/new-cryptography.mdx‎

Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
---
2+
title: New Cryptography Schemes
3+
description: >-
4+
SIMD-0302 and SIMD-0388 add native syscalls for BN254 G2 arithmetic and
5+
BLS12-381 curve operations, making modern zero-knowledge proof systems and
6+
signature schemes dramatically cheaper to verify onchain.
7+
subtitle: Native syscalls for BN254 G2 and BLS12-381 curve operations
8+
publishedAt: 2026-06-09T00:00:00.000Z
9+
status: published
10+
author: solana-foundation
11+
badges:
12+
- text: Under Development
13+
color: yellow
14+
variant: badge
15+
metrics:
16+
- value: 10-20x
17+
label: Lower compute vs pure-BPF implementations
18+
- value: 128-bit
19+
label: Security level with BLS12-381
20+
categories:
21+
- category: upgrades
22+
tags:
23+
- tag: announcements
24+
---
25+
26+
# New Cryptography Schemes
27+
28+
Q4 2026 • Solana Foundation
29+
30+
Solana is expanding the cryptography it supports natively at the protocol level.
31+
Two proposals,
32+
[SIMD-0302](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0302-bn254-g2-syscalls.md)
33+
and
34+
[SIMD-0388](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0388-bls12-381-syscalls.md),
35+
add new elliptic curve operations as syscalls, making modern zero-knowledge
36+
proof systems and signature schemes dramatically cheaper to run onchain.
37+
38+
Today, programs that need curve operations beyond what the runtime provides have
39+
to implement them in BPF, which is slow and burns through compute budget. Native
40+
syscalls move that work into the validator, where it runs as optimized native
41+
code. SIMD-0302 estimates a 10-20x reduction in compute units compared to
42+
pure-BPF implementations.
43+
44+
| | |
45+
| -------------------------------- | ------- |
46+
| Expected Mainnet Activation Date | Q4 2026 |
47+
| Devnet Activation | Q4 2026 |
48+
| Breaking Change? | No |
49+
| Indexing Changes Required? | No |
50+
51+
## Technical Details
52+
53+
### BN254 G2 Arithmetic
54+
55+
Solana already provides syscalls for basic G1 group operations and pairing checks on
56+
the BN254 curve (also known as alt_bn128), the curve used by most Groth16 proofs
57+
today.
58+
[SIMD-0302](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0302-bn254-g2-syscalls.md)
59+
extends the existing `sol_alt_bn128_group_op` syscall with addition,
60+
subtraction, and scalar multiplication on G2 points.
61+
62+
Native G2 arithmetic enables:
63+
64+
- Batch Groth16 verification - multiple ZK proofs aggregated into a single
65+
verification call
66+
- KZG polynomial commitments - efficient multi-point opening proofs and batch
67+
verification
68+
- More advanced ZK systems that need G2 math for batch or direct verification
69+
70+
### BLS12-381 Support
71+
72+
[SIMD-0388](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0388-bls12-381-syscalls.md)
73+
introduces a new family of syscalls for the BLS12-381 curve, covering group
74+
operations in G1 and G2, point validation, pairings, and point decompression.
75+
76+
BLS12-381 is the modern standard for pairing-friendly curves. It achieves a
77+
128-bit security level, making it the right foundation for
78+
high-security protocols. It is already widely adopted across the industry,
79+
allowing Solana to be more composable with the rest of the crypto world.
80+
81+
### Supporting Alpenglow
82+
83+
BLS12-381 support also matters for [Alpenglow](/upgrades/alpenglow), Solana's
84+
upcoming consensus upgrade. Alpenglow votes are BLS signatures, and while the
85+
votes themselves are processed outside the normal transaction pipeline,
86+
validators register their BLS public keys with a regular onchain transaction.
87+
That registration must include a Proof of Possession, a cryptographic proof that
88+
prevents rogue-key attacks against aggregate signatures. When the vote program
89+
eventually moves to BPF, these syscalls are what will let it verify Proofs of
90+
Possession efficiently.
91+
92+
---
93+
94+
## About This Upgrade
95+
96+
Zero-knowledge cryptography is moving from research into production across the industry,
97+
powering private payments, identity, scaling, and interoperability.
98+
This upgrade makes Solana a first-class platform for that work. Proof systems
99+
that were previously too expensive to verify onchain now become practical, and
100+
developers get access to the best and most modern curves used across the broader
101+
cryptography ecosystem.
102+
103+
It also lays protocol groundwork: the BLS12-381 syscalls directly support the
104+
key registration flow for Alpenglow, Solana's next-generation consensus.
105+
106+
Together, these changes mean cheaper ZK verification, stronger security levels,
107+
and a runtime that keeps pace with the state of the art in applied cryptography.
108+
109+
**Learn more:** [Solana Upgrades](/upgrades)

0 commit comments

Comments
 (0)