Solana

In brief

Anatoly Yakovenko proposed Proof of History (PoH) as a way to verify order and the passage of time between events. The project’s whitepaper describes PoH as a sequential hash chain that can sit alongside a consensus algorithm such as proof of stake — not as a standalone consensus mechanism. The live network launched as Mainnet Beta in March 2020. Validators produce blocks on a leader schedule. Programs are stateless executable accounts; state lives in separate data accounts. Tokens are mint accounts and token accounts under a Token Program, not a new custom contract per asset by default. Fees combine a per-signature base fee with optional compute-unit priority fees. Decentralization here is multidimensional: many validators, a rotating leader, client diversity still in progress, and a history that includes well-documented outages.

Why Solana was proposed

Yakovenko’s whitepaper, Solana: A new architecture for a high performance blockchain, argues that public blockchains usually have no shared clock. Each node has a local clock. If a message is accepted or rejected by timestamp, there is no guarantee that every other node makes the same choice. PoH is offered as a ledger with a verifiable duration between events and a verifiable message order, so nodes can rely on recorded time without trusting one another’s clocks.

The abstract is explicit about the division of labor: PoH encodes the passage of time into an append-only structure. When used alongside proof of work or proof of stake, it can reduce messaging overhead in a Byzantine-fault-tolerant replicated state machine. The paper also sketches a proof-of-stake algorithm and a streaming Proof of Replication. Throughput numbers in that paper (including a 710,000 transactions-per-second figure on a 1 Gbps network with then-current hardware) are an analysis of a proposed design, not a measurement of today’s mainnet.

The design goal is high throughput and low latency on one global state machine, not a copy of Ethereum’s account/EVM model with the gas limit turned up.

People and timeline

Yakovenko is the author of the whitepaper (affiliation on the PDF: anatoly@solana.io). Messari’s project history describes a late-2017 draft on Proof of History, a February 2018 internal testnet and paper with Greg Fitzgerald, and a company that became Solana Labs. The early project name “Loom” was dropped to avoid confusion with Loom Network. Raj Gokal is widely listed as a co-founder.

This article does not treat Solana Labs as the operator of the chain. Labs, Anza (which maintains the Agave validator client that descended from Solana Labs’ software), Firedancer and independent validators are different roles.

Mainnet Beta opened in March 2020. Messari supports the month. Several secondary timelines assign 16 March to the first block, but the official explorer does not expose a timestamp for block 0; this article therefore does not assert an exact day or invent a more precise corporate “go live” ceremony.

The network has remained in a long “beta” label in some official language even after years of production use. That is branding and caution, not a claim that the chain is still a testnet.

Proof of History is not consensus

PoH is a verifiable delay sequence. The whitepaper’s description:

• Take a collision-resistant hash function (the example is SHA-256).
• Feed a starting value in, take the output, feed that output back in, and repeat.
• Record the count and the output at intervals.
• Because the next hash cannot be predicted without running the previous step, a long sequence is evidence that real time passed between index 0 and index 300.
• External data can be mixed into the sequence, which timestamps that data as existing before the next hash.

Verification can be parallelized (different cores check different segments). Generation of a single sequence is inherently sequential.

Anza’s Tower BFT design document states the relationship in one sentence: the cluster generates a source of time via a verifiable delay function called Proof of History. The unit of time is a slot. Each slot has a designated leader that may produce a block. A leader is not required to produce a block for its slot.

Tower BFT is the vote-and-lockout consensus algorithm. Validators sign votes for blocks. Voting on a fork incurs a lockout (measured in slots) during which the validator should not vote on a conflicting fork. New votes double previous lockouts. The design aims to make rollback of older votes increasingly expensive. A threshold check is meant to stop a validator locking itself onto a minority fork. Fork choice weights recent votes by stake and walks toward the heaviest child.

Solana’s 2019 “Tower BFT” explainer called Tower a PoH-optimized version of PBFT that uses PoH as the network clock. Independent explainers (for example Helius’s consensus article) make the same split: PoS for economic security, PoH for ordering/time, Tower BFT for voting and finality.

Do not describe PoH as “Solana’s consensus algorithm.” It is a clock and an ordering device that consensus consumes.

Validators, leaders and slots

A validator is a node that votes, and that can be scheduled as leader. Stake is delegated in SOL. Leader rotation is deterministic from the validator set and stake, so the cluster can know who should produce which slot. The whitepaper’s network picture is: users send messages to the current leader; the leader sequences them into the PoH stream, executes, and publishes; verifiers re-execute and vote.

This is still a replicated state machine. Fast block times do not remove the need for other validators to check the leader. A faster PoH ASIC does not automatically rewrite finalized history; Tower’s lockouts are designed so that vote depth grows exponentially while hardware speedups are linear (Anza’s “PoH ASIC resistance” section).

Finality on Solana is not Bitcoin’s “wait for six blocks” story and not Ethereum’s epoch-justification story. Confirmations deepen as votes stack. Optimistic confirmation is a separate, additional notion used by some clients and RPC providers. This article does not treat any single confirmation count as universal user advice.

Accounts, programs and the runtime

Solana stores all state in a key-value map. Each key is a 32-byte address (an Ed25519 public key or a PDA). Each value is an account with the same five fields: lamports, data, owner, executable flag, rent epoch.

Rules that matter:

• Only the owner program may modify an account’s data or debit its lamports.
• Any program may credit lamports to a writable account.
• Accounts must hold a minimum lamport balance (rent-exempt minimum) proportional to their size to remain on-chain.

A program is an account whose data is sBPF bytecode and whose executable flag is true. Official docs: programs are stateless. All mutable state is in separate data accounts passed by instructions. Programs compile via LLVM to Solana Bytecode Format. They may be upgradeable under loader-v3 until the upgrade authority is revoked.

This is the opposite of the default Ethereum picture, where a contract’s code and storage share one address.

Sealevel is Solana’s name for scheduling non-overlapping transactions in parallel. Parallelism is possible when transactions declare disjoint writable accounts. Two transfers that touch the same token account still serialize. Parallel execution is a runtime property, not “every transaction happens at once.”

Transactions and fees

A transaction contains signatures and a message: account keys, a recent blockhash, and compiled instructions. Official limits include a 1,232-byte packet size and a recent blockhash valid for 150 slots. All instructions in a transaction are atomic: if one fails, all state changes revert. Fees are still charged on failure.

Fees, from Solana’s fee docs:

• Base fee: 5,000 lamports per signature. Split 50% burned, 50% to the validator.
• Prioritization fee: optional, ceil(compute_unit_price × compute_unit_limit / 1,000,000) lamports, 100% to the validator.
• Compute units meter execution. Documented defaults: 200,000 CU per ordinary instruction, 1,400,000 CU maximum per transaction.

SOL is the native asset. It pays fees, is staked, and can be transferred without a token account. Lamports are the fractional unit. SOL is not an SPL token; wrapped SOL in a token account is a different representation used when a program expects the Token Program interface.

Tokens: not an ERC-20 per mint

On Solana, fungible and non-fungible assets are data accounts owned by a Token Program (the original program, or Token-2022 / Token Extensions). Official docs:

• A mint account is the global definition of an asset: supply, decimals, mint authority, freeze authority.
• A token account holds an amount of one mint for one owner.
• An associated token account is a PDA derived from owner + mint, used as the default token account for that pair.

A wallet that “holds USDC” on Solana owns a token account for the USDC mint. It does not hold a mapping inside a custom USDC contract the way an Ethereum ERC-20 does. Freeze and mint authorities, if not revoked, are real powers. Token-2022 adds optional extensions (transfer hooks, confidential transfers, and others) on top of the original instruction set.

NFTs on Solana are typically mints with supply 1 and zero decimals, plus metadata accounts — still Token Program state, not ERC-721.

Program Derived Addresses

A PDA is a 32-byte address derived from a program ID and seeds, forced off the Ed25519 curve so that no private key exists. Only the deriving program can “sign” for it, via invoke_signed during a cross-program invocation. Associated token accounts are the everyday example. PDAs are how programs own accounts and act as authorities without storing a key.

This is not an Ethereum contract account, and it is not a seed phrase.

Decentralization, outages and what not to claim

Solana’s performance goals come with operational history. Solana Foundation reported that the network was offline for 17 hours on 14 September 2021 after bot traffic contributed to unbounded queue growth, validator crashes and a consensus stall. Its October 2022 performance report lists three further block-production outages that year: about seven hours on 30 April, about four and a half hours on 1 June, and six hours 19 minutes beginning 30 September. An Anza post-mortem reports another approximately five-hour finalization halt on 6 February 2024, caused by an infinite recompilation loop triggered by a legacy loader program. These were availability failures. They do not prove that the network “never works,” nor do they by themselves settle every question about decentralization.

Decentralization is not a single axis:

• Validators and stake can be numerous and still concentrated.
• Leaders rotate, but scheduling and networking still privilege well-connected nodes.
• Clients: Agave is maintained by Anza. Jump Crypto’s Firedancer project describes a from-scratch validator implementation, while Frankendancer combines Firedancer components with Agave runtime and consensus code. Client diversity is still a work in progress, and common-client bugs can remain a network-wide risk even when stake is spread.
• Labs, Foundation, Anza influence software and narrative; they do not have a Bitcoin-style “rewind this payment” button for ordinary transfers.

Solana is not Ethereum-but-faster. It is a different account model, a different virtual machine, a different fee market, and a different consensus-plus-clock design. Applications, wallets and token standards do not port by renaming “gas” to “lamports.”