Technical review: October 27, 2026 (KST). Updated the consensus and commitment sections following Alpenglow's mainnet-beta activation.
Solana is a blockchain designed to execute many transactions on a shared ledger. Its architecture is best understood by separating ordering, agreement and execution. These solve different problems. Combining them into a single “speed” number conceals the trade-offs that matter to an application user.
1. From PoH ordering to Alpenglow consensus
Solana's earlier architecture combined Proof of History (PoH), which helped establish event order and elapsed time, with Tower BFT voting. PoH was not a standalone consensus mechanism. On October 21, 2026, Solana mainnet-beta migrated to Alpenglow, according to Anza. Its Votor consensus uses local timeouts and stake-weighted vote certificates to finalize blocks. Ordering events and agreeing on a valid history remain separate concepts.
A useful analogy is a meeting log. A log can establish when an item was recorded, while a separate voting procedure determines which decisions the participants accept. The log reduces coordination work, but it does not replace agreement. This analogy explains the roles; it is not a claim that blockchain consensus works exactly like an ordinary meeting.
2. Parallel execution depends on which accounts are used
A Solana transaction specifies the accounts its instructions read or write. That information lets the runtime identify work that can safely run concurrently. Transactions with conflicting account access cannot simply overwrite the same state at the same time. Shared read-only data is different from a shared writable account.
An original scheduling example: imagine four transactions. A updates Alice's account, B updates Bob's, C also updates Alice's, and D updates Carol's. Assuming no other conflicts, A, B and D can run concurrently; C must be ordered with A because they both change Alice's state.
| Transaction | State changed | Relevant conflict |
|---|---|---|
| A | Alice | C |
| B | Bob | None in this simplified set |
| C | Alice | A |
| D | Carol | None in this simplified set |
If each task took one unit of time and three execution lanes were available, this toy workload could take two rounds rather than four. If every task changed Alice's account, it would still need ordering across all four. Real execution has additional constraints and overhead. The example demonstrates why workload composition matters as much as processor count.
3. What commitment levels mean after Alpenglow
Solana RPC retains the processed, confirmed and finalized commitment labels. Under Alpenglow, confirmed and finalized both indicate consensus finality, as documented by Agave. Processed indicates that a node has processed a block, but does not itself establish finality. The older distinction between supermajority confirmation and finalization through maximum lockout applies to Tower BFT, the protocol used before the migration.
These labels answer a different question from how frequently blocks are produced. A wallet displaying quick progress is not evidence that a receiving service has credited the deposit. The service may wait for its chosen commitment level and complete its own processing.
For an everyday transfer, keep the transaction signature and examine both the chain result and the recipient's status. A signature identifies an attempt; it does not by itself prove successful execution. Solana's transaction documentation also explains that recent blockhashes expire, so an old transaction can fail to land even when the destination address is correct.
4. What a meaningful throughput comparison records
Our comparison method records the observation window, workload, measurement point, success criterion and confirmation level. “Transactions per second” without those details is incomplete. A laboratory maximum, submitted requests and successful user operations are different measurements.
- Workload: simple transfers, complex swaps and contended application accounts consume different resources.
- Counting rule: state whether vote transactions and unsuccessful attempts are included.
- Time: state whether the number is a peak second, an average hour or another interval.
- Outcome: pair throughput with latency, fees and the proportion of operations that achieved the intended result.
For example, a hypothetical service reporting 1,000 attempts per second with 90% successful completion handles 900 successful operations per second under that definition. A second service reporting 950 successful operations per second cannot be ranked below it merely because 950 is smaller than 1,000. First align the denominators and completion criteria.
5. More validators are not extra independent processing lanes
Validators participate in maintaining and agreeing on a shared ledger. Adding another validator is not equivalent to adding another independent shard that exclusively handles a new portion of transactions. Hardware, network communication, account contention, protocol limits and client implementation all affect capacity. A validator count alone does not determine a TPS ceiling.
Parallelism inside execution is therefore different from the number of organizations validating the chain. The first concerns how independent work is scheduled. The second concerns participation, distribution and the assumptions supporting consensus. Both matter, but they should be measured separately.
A reader's checklist for a “faster blockchain” claim
Ask what was measured, which software and network it describes, how success was defined, and whether another chain was tested on comparable work. Keep proposed upgrades separate from deployed behavior. Fixed claims about fees, finality or maximum capacity age quickly, so this guide emphasizes definitions instead of presenting one benchmark as a permanent property.
The architectural advantage to understand is the ability to schedule independent work efficiently. The limit to understand is that real applications create dependencies, compete for resources and still require agreement about the final ledger. That is a more useful basis for evaluating an application than treating one latency number as the whole user experience.
Primary technical references
- Anza: Alpenglow consensus and deployment status.
- Anza's October 21, 2026 mainnet-beta activation announcement.
- Legacy Solana validator documentation: synchronization and PoH before Alpenglow.
- Solana's development guide: account model and parallel execution.
- Solana Foundation transaction documentation.
- Agave: commitment status under Tower BFT and Alpenglow.
- Solana: transaction confirmation and expiration.
- Solana terminology.
The scheduling and throughput examples are deliberately simplified illustrations, not measurements of current mainnet performance. Report a technical correction.