Welcome to our third lesson. In our previous session, you successfully set up your development environment and used the Solana CLI to interact with the Devnet. You learned how to inspect live on-chain accounts, observing the key differences between data accounts (like your wallet) and program accounts.
Today, we're going to look under the hood of the Solana network. Having seen what an account is, we will now explore how the network processes transactions to change an account's state. This lesson covers Solana's runtime—the machinery of validators, slots, and epochs that drives the blockchain forward—and its transaction economics, including the crucial concepts of compute units and fees. For a security researcher, this foundational knowledge is non-negotiable. It's the basis for understanding everything from network performance and censorship resistance to sophisticated economic and denial-of-service attacks.
Let's begin with a high-level map of a transaction's journey.
1. The Rhythm of the Network: Slots, Epochs, and Leaders
Unlike a simple client-server model, a decentralized network requires a way for thousands of independent computers (validators) to agree on the state of the world. Solana achieves this through a carefully orchestrated rhythm, defined by specific units of time and a rotating cast of leaders.
The fundamental unit of time in Solana is a slot, which is a period of roughly 400 milliseconds. In each slot, a single designated leader has the opportunity to produce a block. A large number of slots are grouped together into an epoch. Leader selection happens at the beginning of each epoch: a schedule is created that assigns a specific validator to be the leader for a short, consecutive sequence of slots. This leader schedule is determined through a stake-weighted, pseudorandom process, ensuring that validators with more SOL staked (either their own or delegated to them) are chosen more frequently, but the order is unpredictable.
To get a detailed understanding of this process, please read the following section from a technical deep dive into Solana's block production.
How Solana Builds Blocks: A Technical Deep Dive - ruggero.io
This article by Ruggero Auteri provides an excellent, in-depth look at Solana's internal workings. We'll start with the section that describes the network's core timekeeping and leadership structure.
Please read the first section, Time Units, Leaders, and Schedule Assignment. As you read, focus on understanding: The relationship between slots and epochs. The role of a leader and how long their turn typically lasts. How the leader schedule is determined and why stake-weighting is important. The concept of Gulf Stream, where transactions are proactively forwarded to upcoming leaders.
This rapid, scheduled rotation of leaders is a core design choice. It prevents any single validator from having prolonged control over transaction inclusion, which is a key property for censorship resistance. The Gulf Stream mechanism is also a critical optimization, ensuring that when a validator's turn to lead arrives, it already has a queue of transactions ready to process, minimizing downtime.
2. The Validator's Work: Block Production and Validation
Every validator in the Solana network is capable of performing two primary roles, determined by the leader schedule. When it's a validator's turn to be the leader, it runs in Leader Mode; otherwise, it operates in Validator Mode.
At the heart of this entire process is Proof of History (PoH). PoH is not a consensus mechanism like Proof of Work or Proof of Stake, but rather a verifiable source of time. It's a continuous hash chain that provides a cryptographic record of the passage of time and the order of events. This allows Solana to timestamp and order transactions before they are sent to the rest of the network for consensus, which is a major source of its efficiency.
Let's explore how these pieces fit together.
The Leader's Pipeline: Transaction Processing Unit (TPU)
When a validator is the leader, its Transaction Processing Unit (TPU) is responsible for creating a block. This involves several stages:
- Fetch Stage: Ingesting transactions from users, bots, and other validators.
- SigVerify Stage: Verifying the cryptographic signatures on transactions in parallel.
- Banking Stage: Executing the logic of the transactions. This is where Solana's parallel processing engine, Sealevel, shines. Because transactions declare which accounts they will read from and write to, the Banking Stage can execute many non-conflicting transactions simultaneously.
- Broadcast Stage: As transactions are executed and bundled into "entries," they are broken into small pieces called shreds and broadcast to the rest of the network using a protocol called Turbine.
This process is a continuous pipeline. The leader doesn't wait to build a full block before sending it; it streams the shreds out as soon as parts of the block are processed.
The Validator's Pipeline: Transaction Validation Unit (TVU)
While one leader is producing a block, all other validators are running their Transaction Validation Unit (TVU) to receive, verify, and replay the leader's work.
- Shred Fetch & Verify: The TVU collects shreds from the network via Turbine and verifies they were signed by the correct leader.
- Replay Stage: The validator reconstructs the block from the shreds and re-executes the same transactions in the same order. The goal is to arrive at the exact same resulting state as the leader. If the results match, the validator considers the block valid.
- Voting: The validator then creates and broadcasts a special vote transaction to signal its agreement on the validity of that block. The network reaches consensus when a block receives votes from validators representing a supermajority (>2/3) of the total stake.
The following resources provide a deep dive into this intricate machinery.
How Solana Builds Blocks: A Technical Deep Dive - ruggero.io
We will continue with the article by Ruggero Auteri to understand the technical details of the TPU and TVU pipelines.
Please read the following sections: Start with Proof of History to understand how PoH provides a trustless timeline. Next, read about the leader's role in the TPU section. Pay attention to the stages and the concept of parallel execution in the Banking Stage. Then, see the other side of the coin in the TVU section. Focus on how it mirrors the leader's work. Finally, read the section on Shreds and Turbine to understand how block data is efficiently broadcast.
To hear these concepts explained from a developer's perspective, the following video from the Solana team provides excellent context, particularly on the Banking Stage.
Solana Validator Educational - Transaction Lifecycle
This "Solana Validator Educational" video offers a practical walkthrough of the transaction lifecycle from the validator's point of view.
First, watch the segment on leader processing, which describes how the network layer (QUIC) and signature verification work to prevent spam. Next, watch the detailed explanation of the banking stage. This covers how blocks are built from transactions and recorded using PoH. Finally, get an overview of Turbine and how it broadcasts shreds as soon as they are processed, rather than waiting for a full block.
3. Transaction Economics: Compute Units and Fees
Now that you understand the mechanics of how a transaction gets processed, let's turn to the economics. How much does it cost, and what resources does it consume? This is where Compute Units and fees come in.
Coming from an EVM background, you might be tempted to equate Solana's Compute Units (CUs) with Ethereum's "gas." While they both measure computational work, their roles in the fee market are fundamentally different.
-
Compute Units (CUs): Every instruction in a Solana transaction consumes CUs. A single transaction has a default budget of 200,000 CUs and cannot exceed 1.4 million CUs. A whole block also has a CU limit (currently 48 million). The primary purpose of CUs is not to calculate a fee, but to act as a safeguard. They prevent transactions from running forever (halting problem) and protect the network from computational Denial-of-Service attacks. If a transaction exceeds its CU budget, it fails, but the fee is still paid.
-
Base Fees: This is the critical difference from the EVM. Solana's base transaction fee is not calculated based on compute usage. Instead, it's a simple, deterministic fee based on the number of signatures required by the transaction. At the time of writing, this is 5,000 lamports (0.000005 SOL) per signature. A simple SOL transfer needs one signature, so it costs 5,000 lamports. An instruction that requires signatures from three different accounts will cost 15,000 lamports.
-
Priority Fees: If the base fee isn't tied to compute, how do you get your transaction processed when the network is busy? This is where optional priority fees come in. Users can add a priority fee to their transaction, specified in micro-lamports per CU. The validator's Banking Stage uses this to prioritize which transactions to execute first. A transaction with a higher priority fee will be processed before one with a lower fee, all else being equal.
The following resource explains this distinction clearly.
Introduction to Solana Compute Units and Transaction Fees
This article from RareSkills provides a concise and clear explanation of Solana's transaction fee model and how it differs from the EVM.
First, read the introduction, which sets up the core comparison with Ethereum. Next, read the section on Compute unit optimization. Pay close attention to the statement that computational resources do not affect the fee. Finally, skim through the code demonstration. You don't need to understand the Anchor/TypeScript code yet (we'll cover that in a future module). The crucial part is the result: the diff (the fee paid) is 5000n lamports in both the simple and the complex examples. The compute units consumed changes, but the fee does not. This is the key takeaway.
This model has important implications for security research. While optimizing CUs won't save you money on the base fee, it is still critical:
- Complexity: The CU limit dictates how much logic you can fit into a single transaction.
- Priority: The total priority fee is
(micro-lamports per CU) * (CU budget). A larger CU budget on your transaction means you'll pay a higher total priority fee for the same rate, making your transaction more attractive to validators. This has led to an incentive structure where users often request more CUs than they need to get ahead in the queue. - DoS Vectors: An attacker can craft transactions that consume a large number of CUs for a low fee, potentially filling up block space and preventing other, more economically useful transactions from being included. Understanding the block's total CU limit is key to analyzing these types of attacks.
The discussion in the following video clip sheds more light on the practical realities of CUs and priority fees inside the validator.
Solana Validator Educational - Transaction Lifecycle
Let's return to the "Solana Validator Educational" video for a discussion on how validators actually use this economic information.
Watch the segment from the discussion on CU prioritization. This part covers: How priority queues in the banking threads are ordered by priority fees. The challenge that CUs are often mis-priced by users. The fact that a transaction's priority is based on requested CUs, not actual CUs used. How this creates opportunities for validators to develop more sophisticated scheduling logic, a competitive advantage.
Conclusion
In this lesson, we took a deep dive into the Solana runtime. You learned that the network operates on a rhythm of slots and epochs, with stake-weighted leaders chosen to produce blocks. We explored the dual pipelines of a validator: the Transaction Processing Unit (TPU) for leaders and the Transaction Validation Unit (TVU) for verifiers, all synchronized by the Proof of History clock.
We also demystified Solana's transaction economics. You now know that base fees are determined by the number of signatures, not computation. Compute Units (CUs) serve as a safety and resource-limiting mechanism, while optional priority fees create a market for transaction inclusion during periods of high demand.
This knowledge forms the bedrock for analyzing Solana programs and protocols. When you investigate a potential vulnerability, you must consider it not just in isolation, but within the context of this dynamic, highly parallel, and economically driven system.
In our next lesson, we will apply this newfound knowledge. We will learn how to use a block explorer to analyze a real Solana transaction, dissecting it to identify its instructions, the accounts it touches, its signers, and its cost.