Solana Unveiled: Transaction Lifecycle, Security Vulnerabilities, and Developer Insights

11 min readDec 13, 2024

Brief History of Solana

After reviewing Ethereum, it is time to take Solana, a popular blockchain ecosystem that supports smart contracts and decentralized applications (DApps). Solana was founded in 2017 by Anatoly Yakovenko with a vision to revolutionize the classical way of distributed systems. Yakovenko, being a computer scientist himself, identified the limitations of existing blockchain networks in terms of scalability and the consensus latency on the order of transactions.

In order to mitigate these issues, he introduced a new concept called Proof of History (PoH). This method introduced a missing piece to the puzzle of scalability in blockchain networks. Yakovenko believed that his blockchain, built on the PoH technique, has the potential to scale beyond its capacity, making it a useful platform for DApps and decentralized finance (DeFi) solutions.

How Solana Works?

While the Proof-of-Work (PoW) consensus method is safe, it can be sluggish, and Proof-of-Stake (PoS) Consensus algorithms encounter challenges in making the sequence of blocks without a reliable time source. Moreover, blockchains such as Ethereum count on centralized algorithms to create a median timestamp, which downgrades the advantages of decentralization. On the other hand, Solana’s Proof-of-History (PoH) solution resolves these challenges by making timestamps within the blockchain itself!

In a nutshell, POH allows Solana to orchestrate transactions recorded on its blockchain, allowing transactions to be processed in real-time offering fast completion. This feature also comes with some security compromises as we address them in this article. Moreover, we are going to look at the details of Solana, its nodes and actors, the transaction life cycle, and the disadvantages in terms of user experience and security in this ecosystem.

Proof of History

In order to understand how Solana works, let's get started with the core component of each blockchain network, aka consensus algorithm. Solana’s consensus mechanism combines Proof of History (PoH) and Tower Byzantine Fault Tolerance (BFT). PoH is a cryptographic clock that provides a timestamp and sequence of events, ensuring the chronological order of transactions without the need for extensive communication between nodes.

PoH uses a Verifiable Delay Function (VDF) to generate a hash chain of events, allowing nodes to agree on the time and order of events efficiently.

Tower BFT

Tower BFT is Solana’s implementation of Practical Byzantine Fault Tolerance (PBFT) optimized using PoH. It leverages the synchronized clock provided by PoH to reduce the communication overhead and latency typically associated with BFT consensus mechanisms. As a result, this combination allows Solana to achieve high throughput and low latency, handling thousands of transactions per second while maintaining security and decentralization.

Nodes and Actors in Solana

Now we have an overview of Solana’s consensus algorithm, so let's check out the other major components of the network. Solana’s network architecture is composed of various nodes and actors that collectively maintain the network’s integrity, performance, and scalability. The main types of nodes and actors include Validator Nodes, Leader Nodes, Archiver Nodes, and Clients as you can see in the following table:

Validator Nodes are the cornerstone of Solana. They are responsible for processing transactions, validating blocks, and participating in the consensus mechanism to secure the network. Validators execute transactions and add new blocks to the blockchain ledger. In order to effectively handle Solana’s throughput, validator nodes require high-performance hardware with significant computational resources, which could also be a downside for Solana. Additionally, validators must stake Solana’s native cryptocurrency (SOL) as collateral, aligning their interests with the network’s security and providing them with “skin in the game” sort of speak!

Leader Nodes are a subset of validator nodes designated to produce blocks during specific time intervals called “slots”. The selection of leaders is deterministic and is based on a combination of the validator’s stake weight and a random seed derived from the Proof of History (PoH) mechanism. During their assigned slots, leader nodes organize incoming transactions, execute them, and propose new blocks to the network. This role rotates among validators, ensuring decentralization and fairness in block production.

The other major nodes are Archiver Nodes. They serve as a distributed storage layer within Solana’s ecosystem. They are lightweight nodes tasked with storing segments of the blockchain’s historical data, thereby offloading this responsibility from validator nodes. Archivers participate in a Proof of Replication process, which allows them to prove that they are reliably storing their assigned data segments without the need to maintain the entire ledger. This approach enhances data availability and contributes to the network’s scalability by distributing storage requirements across many nodes.

Last but not least, we have Clients and Users that represent the end-users and external entities that interact with the Solana network. Clients initiate transactions and interact with DApps built on Solana. They use wallets or applications to construct and send transactions to the network. These transactions are then processed by validator nodes and incorporated into the blockchain. Users rely on the network’s performance and security to execute operations such as transferring SOL tokens, interacting with smart contracts, or participating in DeFi protocols.

Solana Account Model

One of the unique features of Solana, which distinguishes Solana from Ethereum is its account model! Solana uses a hybrid structure where accounts can store both data and executable code. Therefore, Solana enables each account to function as a standalone state machine capable of performing various operations and interacting directly with smart contracts. This is in stark contrast to Ethereum’s model, which distinguishes between externally owned accounts (EOAs) that cannot hold code, and contract accounts that can. In Ethereum, transactions change state and are not associated directly with account objects, whereas Solana’s accounts themselves hold state directly, which is a big difference!

Why Is the Cost of a Transaction Cheap?

This setup is especially useful for applications that demand quick state changes, such as trading platforms and gaming applications. In comparison, Ethereum’s account model, which requires calling externally stored contract code for modifications, can be slower and more gas-intensive, which becomes a bottleneck for high-throughput applications. This fundamental difference in how account states are managed and executed underpins Solana’s capability to perform faster and at a lower cost than Ethereum. In the following table, we summarize the account model of Solana.

Note that, in Solana, accounts have a maximum size of 10 Mega Bytes and the data stored on every account on Solana has the following structure known as the AccountInfo:

The AccountInfo for each account includes the following fields:

data: A byte array that stores the state of an account. If the account is a program (smart contract), this stores executable program code. This field is often referred to as the "account data".
executable: A boolean flag that indicates if the account is a program.
lamports: A numeric representation of the account's balance in lamports, the smallest unit of SOL (1 SOL = 1 billion lamports).
owner: Specifies the public key (program ID) of the program that owns the account.

It is interesting to know that, every account on Solana has a designated “owner”, specifically a program. Only the program designated as the owner of an account can modify the data stored on the account or deduct the lamport balance. It’s important to note that while only the owner may deduct the balance, anyone can increase the balance.

Life Cycle of Solana Transactions

Now we have enough information about Solana architecture and its account model, it is time to plunge into the life cycle of transactions in the Solana ecosystem. A transaction on the Solana blockchain undergoes several distinct stages from its initiation to final confirmation. These stages provide insight into how Solana achieves its high throughput and low latency. The following table summarizes the entire life cycle of Solana’s transactions:

1. Transaction Creation

This is the first stage of the transaction creation in Solana that involves specifying the desired operations, encapsulated in one or more instructions targeting various programs or smart contracts. Each transaction requires details about the involved accounts and the operations (data) to be executed.

Transaction = { Instructions, Signatures, RecentBlockhash }

const transaction = new Transaction().add(
  SystemProgram.transfer({
    fromPubkey: alicePublicKey,
    toPubkey: bobPublicKey,
    lamports: 5 * LAMPORTS_PER_SOL
  })
);

2. Transaction Signing

After creation, each transaction must be authenticated by signing it with the private keys of the involved parties. This ensures the transaction’s integrity and authorization within the network.

3. Transaction Submission

Once signed, the transaction is submitted to the Solana network through a node, typically using a Remote Procedure Call (RPC) server. This node acts as an entry point for the transaction into the network.

Submission Process:

RPC Server Interaction: Users interact with the network via RPC endpoints to submit transactions.
Endpoints: Common RPC methods include sendTransaction and simulateTransaction.

4. Transaction Propagation

The submitted transaction propagates across the network, aiming to reach the leader node designated for the current slot. Solana operates in discrete time intervals called slots, during which a specific validator acts as the leader to propose new blocks.

Propagation Mechanism:

Gossip Protocol: Solana utilizes a gossip protocol to disseminate transactions efficiently across validators.
Leader Election: The leader node for a slot is pre-determined based on the Proof of History (PoH) and validator stake.

5. Transaction Processing by Leader

The leader node is responsible for organizing and executing transactions within its designated slot. It updates the blockchain state accordingly by processing each transaction’s instructions. The processing steps are as follows:

Batching Transactions: The leader groups transactions into batches.
Executing Instructions: Each instruction is executed, modifying the state as needed.
State Transition: The state changes (e.g., transferring SOL from Alice to Bob) are applied to the ledger.

For example, a leader node can deduce 5 SOL from Alice’s account and credit it to Bob’s account.

6. Transaction Validation by Validators

Validators re-execute the transactions processed by the leader to ensure consistency and correctness across the network. This step guarantees that all validators agree on the state transitions. We have the following validation criteria:

Idempotency: Re-executing transactions should yield the same results.
State Consistency: Ensures that the global state remains consistent across all nodes.

7. Consensus and Block Finalization

As we mentioned earlier, Solana uses the Tower Byzantine Fault Tolerance (Tower BFT) algorithm, an optimized version of Practical Byzantine Fault Tolerance (pBFT), to reach consensus on the validity of proposed blocks. Validators must achieve a supermajority agreement to finalize a block.

The following three steps show what the consensus process looks like:

Proposal: The leader proposes a block containing the batched transactions.
Voting: Validators vote on the proposed block based on their stake.
Finalization: Once the cumulative votes meet or exceed two-thirds of the total stake, the block is finalized.

8. State Update and Confirmation

Following consensus, the blockchain state is globally updated to reflect the completed transactions. The updated state is then propagated to all validators, ensuring that the network remains synchronized.

In summary, Solana’s transaction lifecycle is meticulously engineered to support high throughput and low latency, making it suitable for applications requiring rapid transaction processing. By leveraging Proof of History and Tower BFT, Solana achieves efficient consensus and ensures the network’s security and scalability.

Security Vulnerabilities in Solana

While Solana is renowned for its high performance and scalability, it is not immune to vulnerabilities. Understanding these vulnerability vectors is essential for all of us, including developers, validators, and users, to safeguard the network against potential threats. The table summarizes the most significant vulnerabilities in Solana and discusses issues related to user experience and developer challenges:

Summary of Vulnerability Vectors in Solana

December 2021 DDoS Attack

In December 2021, Solana’s blockchain faced a significant Distributed Denial of Service (DDoS) attack that affected its performance over a 24-hour period. Although the network remained online, it experienced severe congestion, leading to delays in transaction processing. This attack involved overwhelming the network with a flood of transactions, which clogged the system and impeded legitimate operations.

September 2021 Outage During IDO

A similar issue occurred in September 2021 when Solana suffered a 17-hour outage. This outage was attributed to mass bot activity during an Initial DEX Offering (IDO) on Raydium, a Solana-based decentralized exchange. The influx of automated bots generated an excessive number of transactions, overwhelming the network and causing prolonged delays and partial outages.

Causes of the Network Disruption

The main factors contributing to Solana’s network congestion included:

Bot Activity During IDOs: Automated bots generated a flood of transactions during IDOs on platforms such as Raydium. This mass botting activity overwhelmed the network, leading to prolonged transaction delays and, in some instances, partial network outages.
High Throughput Exploitation: Solana’s architecture allows for processing tens of thousands of transactions per second. However, the lack of sufficient safeguards against an avalanche of requests meant that the network was ill-prepared for such exploitative tactics.
Inadequate Rate Limiting: The absence of effective rate-limiting mechanisms allowed a few sources to send a large volume of transactions, significantly exceeding what the network could handle at the time.

User Experience and Developer Challenges

Despite Solana’s technical prowess, certain aspects of user experience present challenges. During periods of high network activity, users may experience slower transaction confirmations and higher fees, which can significantly impact the usability of dApps. Additionally, recurrent outages and performance issues can erode user trust, making individuals hesitant to engage with Solana-based applications.

Developers working within the Solana ecosystem also face several challenges that can hinder adoption and innovation. For example, the Solana SDK is complex to navigate, especially for those transitioning from other blockchain platforms. This complexity can lead to longer development times and a steeper learning curve. Furthermore, Solana primarily uses Rust for smart contract development — a language known for its performance and safety but less widely adopted compared to languages like Solidity — potentially limiting the pool of available developers and increasing onboarding times. Limited documentation and developer tools, though improving, do not yet match the maturity of those available for more established platforms like Ethereum, making debugging and optimizing smart contracts more challenging.

References

Yakovenko, A., 2018. Solana: A new architecture for a high performance blockchain v0. 8.13. Whitepaper.

Pierro, G.A. and Tonelli, R., 2022, March. Can solana be the solution to the blockchain scalability problem?. In 2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER) (pp. 1219–1226). IEEE.

Song, H., Wei, Y., Qu, Z. and Wang, W., 2024. Unveiling Decentralization: A Comprehensive Review of Technologies, Comparison, Challenges in Bitcoin, Ethereum, and Solana Blockchain. arXiv preprint arXiv:2404.04841.

Tanaka, H., 2024. Blockchain Decentralization: Comprehensive Insights into Bitcoin, Ethereum, and Solana. Advances in Computer Sciences, 7(1), pp.1–5.

Ivanov, M. and Johnson, E., 2024. A Comprehensive Review of Decentralization Technologies in Bitcoin, Ethereum, and Solana. Advances in Computer Sciences, 7(1), pp.1–8.