Understanding Solana: Architecture, Account Model and Transactions — part 1
Solana is a high-performance blockchain designed for speed, scalability, and low-latency transactions. Its architecture introduces several…
Solana is a high-performance blockchain designed for speed, scalability, and low-latency transactions. Its architecture introduces several innovations that make it stand out from traditional blockchains like Ethereum and other EVM chains.
In this series, we’ll cover the foundational concepts that every developer or enthusiast should understand:
Core Architecture: How Solana achieves high throughput with Proof of History, Tower BFT, and parallel transaction processing.
Account Model: The unique way Solana handles state and programs through accounts.
Transactions: The structure, execution flow, and authorization model for Solana transactions.
In this post, we will start with Core Architecture and cover the fundamentals of solana before diving deeply into implementations.
Core Architecture
In this section we will have a quick overview of the Solana core architecture and understand the principles it is working on.
Proof of History (PoH)
PoH is one of Solana’s key innovations, introduced by Anatoly Yakovenko, the founder of Solana Labs. It’s built around a simple but powerful idea: in a distributed system, knowing the precise order of events is as important as the events themselves.
To achieve this, Solana uses a Verifiable Delay Function (VDF) its a cryptographic function that takes a measurable amount of time to compute and whose output can be efficiently verified. Each validator continuously hashes the previous output along with new data, producing a sequence of hashes that acts as a cryptographic timestamp for events. It provides provable and immutable record of time showing exactly when each event occurred relative to others.
This design allows for fast finality, meaning that once a block is added to the Blockchain, it is considered finalized and cannot be undone.
Verifiable Delay Function (VDF)
Traditional blockchains like Bitcoin and Ethereum rely on block intervals or external timestamps to order transactions, which limits scalability. Solana solves this by embedding time directly into the ledger using a Verifiable Delay Function (VDF).
The VDF is a cryptographic function that takes a fixed amount of time to compute and can be quickly verified. Validators continuously run this function, hashing the previous output to produce a chain of hashes, each representing a precise moment in time. This sequence creates a cryptographic clock that allows anyone to prove when an event occurred relative to others, without relying on external sources.
When transactions are submitted, they reference specific points in this PoH sequence. Validators can instantly verify when they happened, enabling parallel verification and faster consensus. In Solana’s case, PoH works hand-in-hand with Tower BFT, a Proof of Stake based consensus mechanism that finalizes blocks in milliseconds.
The VDF’s role in PoH addresses several critical aspects of Blockchain technology:
Verifiability: It ensures the Blockchain’s historical record is transparent, immutable, and accessible for public verification. This builds trust and reduces reliance on computationally intensive processes.
Decentralization: Multiple nodes can generate and validate timestamps concurrently, preventing any single entity from controlling the timestamp generation. This enhances the network’s security and reliability.
Efficiency: By providing a reliable temporal order of events without the need for energy-intensive consensus algorithms like Proof of Work (PoW), PoH with VDF improves transaction processing efficiency, speeds up consensus, and reduces transaction fees.
Tower BFT
Tower BFT is Solana’s consensus algorithm built on top of Proof of Stake and tightly integrated with Proof of History. It’s a customized version of Practical Byzantine Fault Tolerance (PBFT), optimized to leverage PoH’s cryptographic clock. (We wont cover the full process here, the full process can be read here)
In traditional PBFT systems, validators must constantly communicate to agree on the order of transactions, a process that limits scalability. Tower BFT reduces this communication overhead by using PoH as a trusted source of time. Since every validator can verify when an event occurred, they don’t need to exchange as many messages to reach agreement.
Each validator votes on the state of the ledger and locks in its vote for a certain number of “slots.” Changing that vote later would require violating its own lockout, so honest behavior is strongly incentivized. As validators continue to build on confirmed blocks, their lockout durations increase exponentially, making finality fast and irreversible.
In essence, PoH provides the timeline, and Tower BFT builds consensus on top of it, allowing Solana to finalize blocks in milliseconds while maintaining security and decentralization.
How it works all together
Cryptographic Timestamping: At the heart of PoH is cryptographic timestamping, which uses a sequential hash function. This function takes an input (the current state of the Blockchain and a random seed) and produces a unique, irreversible output(hash). This hash serves as a verifiable timestamp.
Generating a Hash Chain: Solana creates a hash chain by applying the hash function iteratively to the output of the previous hash. Each step represents a tick, with the number of hash operations indicating the time elapsed. This results in a continuous, verifiable record of time used to sequence transactions.
Recording Transactions: When a transaction is made, it’s sent with the most recent hash observed. Validators confirm its validity and timing by ensuring it references a hash within the current PoH sequence. This proves the transaction happened at a specific moment.
Consensus: Once transactions are timestamped using Proof of History, they move through Solana’s Proof of Stake (PoS)-based consensus mechanism called Tower BFT. Validators, who stake SOL to participate in the process, are responsible for validating transactions and maintaining network security in exchange for rewards. Thanks to PoH’s built-in timekeeping, Tower BFT can reach agreement on the order of transactions extremely fast, enabling Solana to process thousands of transactions per second.
Verifiable Delay Function (VDF): At the heart of Proof of History lies the VDF, a cryptographic process that enforces a measurable passage of time between events. Before producing a block, a leader must compute the next hash in this sequence, which depends on the output of the previous one. This ensures that each step can only be generated sequentially, it cannot be skipped or parallelized. By continuously appending new hashes derived from prior states, Solana creates a chain of verifiable timestamps that proves the exact order of transactions, preventing anyone from recreating or reordering historical data.
Parallel transaction processing
In most blockchains (like Ethereum), transactions are processed sequentially one after another because each transaction might modify shared state (like balances or contract data). This ensures consistency but limits throughput, since the network can only handle as many transactions per second as a single thread can process.
Solana takes a different approach with parallel transaction execution, powered by its runtime called Sealevel.
Sealevel allows Solana to analyze transactions before execution to determine which ones can safely run at the same time. Each transaction must declare:
Which accounts it will read, and
Which accounts it will write to.
If two transactions don’t overlap on writable accounts, they can be executed in parallel across multiple CPU cores or GPUs.
For example:
Transaction A updates Account X.
Transaction B reads Account Y.
Since these accounts don’t conflict, both can be processed simultaneously.
This model transforms block validation from a single-threaded bottleneck into a highly parallelized process. Combined with Proof of History (for ordering) and Tower BFT (for consensus), Sealevel allows Solana to achieve massive throughput, tens of thousands of transactions per second without sacrificing determinism or consistency. (More about SeaLevel can be found here)
Up Next
In the next part, we’ll dive into Solana’s Account Model, how all state, programs, and data are organized within accounts and how it differs from Ethereum’s contract model.


I couldn’t find part 2 in the main list, the 3rd blog references part2 on the first line but redirects to Medium 🤔