3. Network, validators, and consensus

A valid signature tells the network who authorized a message. It does not tell distributed computers which transaction happened first or which fork to accept. This chapter adds the agreement layer.

The distributed-systems problem

Validators are in different locations. Messages take time to arrive, some machines stop, and two nodes may temporarily observe different histories. Solana needs a protocol that lets honest validators converge on one ledger.

Keep three jobs separate:

Proof of History -> helps establish verifiable order
Proof of Stake + Tower BFT -> weights votes and reaches agreement
Runtime -> executes transactions deterministically

Common misunderstanding

Proof of History is not a standalone replacement for consensus. It supplies a cryptographic ordering clock that works with validator voting and fork choice.

From RPC to leader

After a wallet signs a transaction:

1. An RPC or forwarding service receives it.
2. The transaction is routed toward the validator expected to lead an eligible slot.
3. The leader schedules transactions and records execution results in ledger entries.
4. Other validators receive those entries, replay the transactions, and verify the state changes.
5. Validators vote on the fork that follows protocol rules.

An RPC response that contains a signature means the submission was accepted by that endpoint. The application must still observe inclusion and commitment.

Slots, leaders, and epochs

A slot is an opportunity for a scheduled leader to produce ledger entries. A slot may also be skipped. Do not treat slot number as a perfect count of successful blocks.

An epoch is a larger protocol interval used for stake and schedule-related processes. Stake activation, deactivation, and leader planning follow protocol timing rather than happening as an ordinary instant database update.

Proof of History as a clock

Proof of History repeatedly hashes the previous output:

h1 = H(seed)
h2 = H(h1)
h3 = H(h2)
...

The sequence is quick to verify and inherently ordered because each value depends on the previous value. Events can be inserted into this sequence to provide evidence about order and passage.

The benefit is reduced coordination about time. Validators still need consensus to decide which ordered history is accepted when forks or partitions occur.

Proof of Stake

Validator votes are weighted by delegated stake. A SOL holder can delegate stake to a validator without simply transferring ownership to the validator operator.

Stake helps:

• assign economic weight to votes;
• make attacks costly;
• align delegators with validator operation;
• influence leader opportunities under protocol rules.

Stake does not automatically guarantee decentralization. Concentration across operators, infrastructure providers, software clients, or RPC services remains an architectural risk.

Tower BFT

Tower BFT is Solana’s PoH-aware voting mechanism. Validators vote on observed forks. Repeated votes build lockouts, making a switch to a conflicting fork progressively more constrained.

You do not need the full mathematics on the first pass. Remember the purpose:

PoH gives an ordered clock.
Tower BFT uses stake-weighted votes over that ordered history.
Lockouts encourage convergence on one fork.

Commitment levels are confidence choices

A transaction can be observed at several levels:

• processed: the queried node processed it.
• confirmed: the cluster has supplied stronger voting support.
• finalized: the transaction belongs to a rooted history under the queried node’s view.

Use commitment as part of a business policy:

UI spinner -> processed can be informative
normal user confirmation -> confirmed is often useful
high-value fulfillment -> stronger policy, reconciliation, and idempotency

No single word replaces operational risk management. Production systems may compare providers, preserve transaction signatures, reconcile balances, and prevent duplicate fulfillment.

RPC node versus validator

An RPC node serves application queries. A voting validator participates in consensus. One operator can run both roles, but the responsibilities differ.

When a dApp fails, identify the layer:

• client failure: transaction built or signed incorrectly;
• RPC failure: rate limit, stale read, unavailable method;
• leader/network failure: transaction not propagated or included;
• program failure: instruction rejected during execution;
• consensus incident: validators do not progress normally.

This separation prevents every error from being described vaguely as “the blockchain is down.”

Staking lifecycle

Conceptually:

create/fund stake account
  ↓
delegate to validator vote identity
  ↓
activation follows epoch rules
  ↓
active stake contributes weight and may receive rewards
  ↓
deactivate and later withdraw under authorized control

Returns depend on protocol conditions and validator characteristics. Staking is not a guaranteed return, and users should verify current rules before acting.

Check your understanding

Try to explain the difference between these statements:

• “The RPC accepted my transaction.”
• “The leader included my transaction.”
• “Validators confirmed my transaction.”
• “The transaction is finalized.”

Next, open the state the network is agreeing on in Accounts and state.