Solana's Surge: The Emergence of the Ethereum Killer
TechFlow Selected TechFlow Selected
Solana's Surge: The Emergence of the Ethereum Killer
Can Solana really surpass Ethereum?
Navigating Web3 tides with focused insightsAuthor: Sal Qadir, Research Analyst at Galaxy
Translation: Chief Villager of Elephant Mountain, Carbon Value
Recently, the Solana ecosystem has shown strong performance driven by DePin trends and meme coins. The price of its native token SOL broke through $100 on December 24. DEX trading volume on Solana briefly surpassed Ethereum, sparking widespread claims that "Solana has overtaken Ethereum."
Can Solana truly surpass Ethereum?
To gain a deeper understanding of Solana’s core architecture and future development, I reviewed past research materials on Solana and found this Galaxy report particularly insightful, comprehensive, and data-rich. It offers a panoramic view of Solana from inception to future roadmap—a perspective rarely seen elsewhere. Below is a curated version of this in-depth report originally published by Galaxy in 2022, provided for reader reference and learning.
Introduction
Solana is a fast, low-latency, proof-of-stake Layer 1 blockchain with a differentiated technical architecture and growing usage across multiple dApps. Although fundamental design constraints limit its resilience and centralization remains evident, proposed technical fixes and upgrades from the protocol team may alleviate or resolve these issues. Nonetheless, over the past 12 months, Solana has successfully distinguished itself among other Layer 1 blockchains, challenging Ethereum’s position as the leading smart contract platform in the crypto space.
Solana’s unique scaling approach contrasts sharply with most other Layer 1s—achieving theoretical throughput of up to 50,000 transactions per second (TPS) with consistently low and fixed transaction fees. From a developer standpoint, Solana prides itself on achieving composability without relying on modular stacks, Layer 2s, or sharding. This report provides an in-depth assessment of Solana, revealing the favorable conditions enabling it to capture and maintain market share within the Layer 1 landscape.
Market Cap and Total Value Locked
Daily Active Users (Paying Users) on Solana Since January 1, 2021
SOL Price in USD Since Mainnet Launch
Background & History
Who is Anatoly Yakovenko?
Anatoly Yakovenko founded Solana while working as an engineer in San Francisco, California. He spent much of his career at Qualcomm, where he applied his expertise in application engineering to solve complex hardware optimization challenges. Renowned for his technical acumen, his most notable achievement was designing high-performance DSP software powering Google Tango—the first mobile device to support smartphone augmented reality. In 2017, a friend working on deploying deep learning hardware into the cloud sparked his initial interest in cryptocurrency (unsurprisingly, such specialized hardware shares many similarities with Solana validator nodes). Together, they used powerful computers to mine Bitcoin profitably after covering initial capital costs. As Anatoly delved into proof-of-work mining research, he began questioning why proof-of-work was necessary, what made it slow, and how it could be improved.
One evening in 2017, Anatoly explored single-threaded mining—that became his “red pill” moment. He reasoned that instead of measuring electricity consumption intrinsic to proof-of-work mining, time itself could be measured. Anatoly believed linking cryptographic network security to physical constants like electricity or time was crucial for long-term reliability. His epiphany came when he realized sequential hashing could guarantee a required duration between two events. He later described this concept as “Proof-of-History” (PoH), publishing his findings in a whitepaper draft in November 2017. By February 2018, Anatoly, together with Greg Fitzgerald, launched the Solana testnet and official whitepaper.
A Qualcomm colleague, Stephen Akridge, suggested modifying Solana’s architecture to leverage GPU-parallelized signatures for verification. Stephen’s contribution not only validated the strengths of Anatoly’s initial protocol design but also motivated him to fully commit to the project. Beyond Greg and Stephen, Anatoly recruited Raj Gokal and three other seasoned experts from Apple and Qualcomm to form Solana Labs. Initially named Loom, the team faced naming confusion with the Ethereum L2 network Loom. They ultimately rebranded as Solana, named after Solana Beach in Southern California, where the team lived and worked.
Growing Through the Bear Market
Solana Labs was established in early 2018 under the visionary leadership of Anatoly. The team’s mission was to advance Solana from proof-of-concept to a production-grade, permissionless blockchain. The challenge was raising funds during the difficult climate of 2018—shortly after the ICO bubble burst and Bitcoin prices plummeted, leaving many investors cold toward blockchain/crypto startups. Solana Labs co-founder and COO Raj Gokal described in an FTX podcast how the team struggled to stand out amid fierce competition—Dfinity (now ICP) had just raised $100 million, while Avalanche Labs was founded by Cornell professor Emin Gun Sirer based on a novel consensus protocol. To some, Solana appeared merely as another Layer 1 obsessed with vanity metrics like TPS. At the time, the Twitter-based crypto community favored privacy and interoperability startups over scalability. Fortunately, Anatoly convinced a friend he met playing underwater hockey to become an early investor, who then introduced the Solana team to two additional supporters.
The team raised $20 million through private token sales to qualified investors. Early backers included Multicoin Capital, 500 Startups, and a founder from Race Capital. The Solana testnet’s ability to sustain 250,000 high-frequency transactions per second impressed these investors. The private sale was announced as a Series A round in late 2019. While fundraising, the team also built Tour de SOL, a public testnet (most Solana co-founders are avid cyclists). By March 2020, Solana conducted a $1.76 million public token auction on CoinList and launched its mainnet beta.
Technical Architecture
Solana's Blockchain and the Speed of NASDAQ
When initially developing Solana, Anatoly drew inspiration from his personal fascination with algorithmic electronic trading. As an ordinary end-user accessing popular platforms like Interactive Brokers via API, he was frustrated by intermediaries with superior capital and infrastructure front-running his trades. He envisioned Solana offering average users a fair competitive environment against powerful institutions. Long-term, Solana aims to achieve the scale and responsiveness of NASDAQ on-chain. Indeed, early seed-stage investment documents from Solana Inc. stated: “Solana’s blockchain and the speed of NASDAQ.” Anatoly’s design decisions for Solana emphasize speed and information flow rather than use cases like “store of value,” which dominate other blockchains like Bitcoin.
Key factors differentiating Solana from nearly all other Layer 1 blockchains are: 1) Hardware; 2) Physical passage of “wall-clock” time; 3) Composability. These three attributes collectively form the foundational pillars of Solana’s tech stack.
First and foremost, Solana heavily relies on hardware advancements to address challenges posed by software-level protocol progress, ensuring its speed and scale improve alongside ongoing hardware improvements. Moore’s Law, which governed CPU transistor density, has slowed over the past five years but continues progressing. More importantly, AI/ML fields are driving breakthroughs in GPU/parallel processing capabilities with no near-term slowdown in sight. The Solana team believes software-level advances (such as Ethereum’s 2.0 upgrades) are notoriously difficult due to the limited number of individuals capable of safely implementing protocol-level changes. Regardless of their pace of underlying protocol progress, the Solana team bets that the computer hardware industry will continue advancing year after year. This ensures Solana’s base-layer scalability can ride the wave of hardware industry progress, setting it apart from other Layer 1s whose scaling roadmaps primarily depend on software design improvements.
The second foundational concept in Solana’s technical architecture is time. Solana decouples time from state update consensus. Because every transaction on Solana carries a timestamp, transactions can be streamed in real-time as they occur. This differs from most other blockchains, which batch timestamps within each block’s transactions. Separating time from state updates allows validators to pre-process blocks for higher throughput, as transaction ordering follows a global clock.
Notably, the broader blockchain development/research community (outside Solana) rarely acknowledges time as a useful invariant for scaling distributed ledgers. One prominent example of time-based scaling appears in telecommunications (a natural fit given Solana’s founding team background). Specifically, since the 2G era, TDMA has been foundational to cellular networks. Details of TDMA operation fall outside this report’s scope, but it essentially leverages limited resources (radio frequency bandwidth) by slicing bandwidth into time slots created by a global clock, enabling more devices to connect without additional network resources. Without this critical time-based cellular expansion method, ubiquitous mobile broadband today would not exist. Below is a simplified diagram of TDMA operation.
Simplified TDMA Diagram
Doubling Down on Monolithic Architecture
Finally, the third key concept underpinning Solana’s technology is composability. Composability refers to Solana’s deliberate design as a monolithic blockchain. While Solana views its monolithic path as a killer feature, this choice represents a contrarian bet in the broader crypto landscape. Other chains like Ethereum and NEAR see monolithic architecture as a barrier to long-term scalability. Competing Layer 1s are exploring various solutions such as modular scaling (advanced by projects like Celestia and Evmos in Ethereum), Layer 2 scaling (advanced by Starkware and Aztec in Ethereum), and various forms of sharding (on Ethereum’s roadmap, already implemented in NEAR Protocol).
The design trade-offs between these technical approaches warrant separate discussion. Nevertheless, Solana refuses to deviate from its monolithic architectural vision. The Solana team believes optimizing composability makes building applications atop a monolithic global state elegant. They argue developers won’t face burdens from multiple shards or Layer 2 systems when writing smart contracts requiring different fragments of Solana’s state. For instance, if an app developer wants to create an atomic swap between SPL tokens on an NFT platform and SPL tokens in a DeFi app, they can easily do so thanks to Solana’s global state. If the same developer were to write such a contract for sharded state, they might need extra logic to check which shard each part of the swap resides on, increasing transaction complexity.
As blockchain applications grow increasingly complex and interwoven, development complexity on modular/sharded systems could multiply. From an end-user perspective, even though Layer 1 is the same chain, applications built on one Layer 2 protocol may lack native interoperability with those built on another (e.g., two independent apps built on Optimism or Arbitrum, both Layer 2s for Ethereum). Solana places high value on end-user experience, viewing modular/Layer 2/sharding as a “last resort” rather than a “necessary evil.” It’s worth emphasizing that Solana’s thinking, though well-intentioned, starkly contrasts with the roadmaps of nearly all other current Layer 1s. How burdensome user experience will be for large-scale utilization across multiple Layer 2s remains unsettled. Most Layer 1s today remain monolithic—only time will tell how each blockchain’s scaling approach withstands high usage. Solana has made reasonable guesses about crypto’s non-monolithic future and remains committed to preserving the simplicity of global state enabled by composable monolithic architecture.
Avoiding the EVM
The Ethereum Virtual Machine (EVM) is a computation engine serving as the runtime environment for Ethereum smart contracts. Developers use the EVM to build decentralized applications (DApps) on Ethereum. Its purpose is managing “state” on permissionless Ethereum.
Simplified EVM Diagram
Many other Layer 1s and sidechains (e.g., Avalanche, Binance Smart Chain, Harmony, Polygon) treat EVM compatibility as a core feature. This is because numerous DApps running on EVM already have Solidity codebases, making migration to EVM-compatible chains relatively simple. These EVM-compatible alternative Layer 1s also benefit from existing developer tools (Hardhat, Truffle, Remix) and user interface/user experience tools (MetaMask, Coinbase Wallet).
Conversely, Solana was designed to run on LLVM rather than the EVM. LLVM is a standard compiler toolchain separating human-readable code (like Rust) from assembly (low-level code optimized for hardware). Practically, one can imagine an LLVM-based deployment pipeline as source code → LLVM → assembly. Solana made this architectural choice for two key reasons: 1.) Solana is designed for hardware optimization, whereas Solidity/EVM inherently lacks hardware optimization support. 2.) Programming languages like Rust allow writing extremely fast low-level code widely adopted in developer communities and theoretically easier for experienced developers to audit. According to the 2020 Stack Overflow Developer Survey, over 65,000 developers ranked Rust as the most-loved programming language for the fifth consecutive year (by a significant margin).
However, the cost of this decision is a shortage of blockchain-specific developers familiar with Rust, making talent recruitment from competing crypto companies/protocols often difficult. Some view this positively, arguing Solana’s developer community is less mercenary and more dedicated to the ecosystem, as their skill set applies only to Rust-based blockchain projects.
The high-level technical decisions described above serve as the “why” behind Solana’s eight core innovations detailed below.
Solana’s Eight Core Innovations
Proof-of-History (PoH) as a Pre-consensus Clock: Proof-of-History is neither a consensus protocol nor a Sybil resistance mechanism. Instead, PoH is a high-frequency, verifiable delay function (VDF). A VDF is a function producing unique outputs sequentially, with verification vastly faster than generation. In other words, generating VDF outputs takes time sequentially, but verification can happen in parallel. In Solana’s PoH, the VDF is essentially a SHA256 hash function running in a constant loop. It works by initially inputting an arbitrary value (e.g., the word “Solana”) into the SHA256 function, then feeding each hash output back as input for the next SHA256 iteration. Repeating this process confirms the elapsed time to produce the final output is genuine, as hashes cannot be generated in parallel—each depends on the previous hash. This sequentially hashed data structure enables Solana to efficiently create a global “wall-clock,” allowing all transactions on the Solana blockchain to reference this clock to prove transaction order.
In short, Proof-of-History:
SHA256 runs as fast as possible on a single core, each output becoming the next input.
The Solana network samples this repeating cycle, recording iteration count and state.
Information can be inserted into the PoH cycle along with hashes and states, guaranteeing message sequence.
Proof-of-History Diagram
Tower BFT Byzantine Fault Tolerance: Tower BFT is essentially Solana’s consensus mechanism. It refers to Solana’s implementation of Practical Byzantine Fault Tolerance (PBFT). As a refresher, Byzantine Fault Tolerance describes methods for solving the Byzantine Generals Problem—coordinating attacks between two geographically separated generals communicating only via messengers. Fault-tolerant systems aim to prevent bad actors from spreading misinformation or intercepting “messengers” before reaching destinations.
In Solana’s system, Tower BFT innovates upon traditional BFT systems: validators vote on a block (call this initial vote X), and in the subsequent two blocks, validators only vote on blocks stemming from “X.” Each time a validator votes for a block originating from “X,” this “rollback timeout” doubles. Thanks to PoH, each validator can verify block information, allowing them to discard blocks inconsistent with Solana’s history. Nodes on the network only earn inflation rewards within maximum voting lockup durations. This helps ensure validators’ economic interests align with forks receiving majority network votes.
Blocks
In Tower BFT, liveness (the ability to always add new blocks) is prioritized over consistency (potential fork count in final blocks) (see diagram). Tower BFT differs from standard PBFT implementations by relying on PoH as a global clock before consensus. This reduces latency and messaging overhead—common drawbacks of traditional PBFT. Under Tower BFT, validators vote within fixed time intervals (slots) of hash values or “epochs.” Typically, one slot equals 400 milliseconds (though slot duration changes with hardware improvements). As previously mentioned, each subsequent slot doubles the wall-clock time (also known as timeout) the network must delay to “unfold” potential votes.
For example, if each Solana validator voted 38 times in the past 15 seconds (15,000 ms / 400 ms = ~38 slots), the network’s timeout would effectively be ~3,400 years. (2^38*400)/1000/60/60/24/365. This BFT method assumes exponential timeout growth as blocks are produced. Unlike “proof-of-work,” once a supermajority of validators vote on a PoH hash, that hash cannot be rolled back. Finality is therefore not probabilistic.
Under Tower BFT, the network can compute timeouts asynchronously without peer-to-peer communication. Each validator’s vote contains a small piece of verifiable information (tied to PoH). If other validators observe proposed votes containing information unverifiable by PoH, those votes are discarded immediately. This explains why the “wall-clock” enabled by PoH, separate from the BFT mechanism itself, is crucial to Solana’s scalability approach.
BFT
Gulf Stream Mempool-less Forwarding Protocol: In a mempool, unconfirmed transactions idle awaiting network processing. Under Bitcoin or Ethereum-style mempool structures, transactors paying higher fees (or tips) incentivize network miners or validators to confirm their transactions faster and remove them from the mempool. Mempool size and blockchain confirmation costs represent supply-demand dynamics for block space on a specific blockchain.
Consider Solana: suppose Solana validators could manage a theoretical “mempool” of 100,000 transactions (Solana doesn’t literally use a mempool). Under these parameters, assuming 50,000 TPS throughput, Solana validators could clear this mempool within seconds. However, this oversimplification ignores the importance of blockchain propagation. In most blockchains, mempool transactions propagate via gossip protocols—peer-to-peer communication methods transmitting data across distributed node networks. Gossip protocols work well thanks to advanced techniques like Bloom filters, helping nodes propagate transactions more efficiently. This efficiency stems from Bloom filters using hash functions to identify whether an element is definitively absent from a given data structure (constant time). Yet, as blockchain throughput increases, computing costs for Bloom filters may become prohibitively expensive due to the massive number of hash calculations per instantiation. Therefore, the Solana team adopted a fundamentally different block propagation approach compared to most other blockchains.
Solana Transaction Workflow
Gulf Stream describes Solana’s unique transaction propagation method—pushing transaction caching and forwarding to the network edge. Because validators know transaction order and future leaders, they can execute transactions in advance. Thus, leader validators can switch faster (similar to relay runners starting their leg before teammates pass the baton). The innovation enabling Gulf Stream is the known leader schedule (again using the relay race analogy, teams predetermine each member’s running order). This leader schedule regenerates every epoch (approximately every 2 days), meaning transactions are sent directly to current and next leaders rather than randomly propagated like in Ethereum’s mempool. Most blockchains lack this specific leader principle. Beyond enabling pre-execution and seamless leader transitions, this method reduces validator memory load (no need to track unconfirmed transactions) and shortens confirmation times. Key risks of Gulf Stream include: 1) increased validator collusion risk (leaders are predetermined, though the Solana team considers this negligible due to Solana’s fast block times); 2) spam susceptibility, as Gulf Stream is mempool-less—spam transactions go directly to leaders.
Sealevel Parallel Smart Contracts: Sealevel is a virtual machine enabling simultaneous execution of smart contracts on a blockchain with shared state. In contrast, EVM-compatible blockchains are single-threaded—only one smart contract can modify blockchain state at a time. Sealevel’s parallel execution engine is powered by its core validators, allowing transactions to execute simultaneously on blockchains with shared state. Sealevel operates similarly to an operating system technique called “scatter-gather.” Developers on the Solana ecosystem must declare upfront the state they’ll read/write. While this adds development complexity, it allows Solana to parallelize any non-overlapping smart contracts. Ultimately, Sealevel uses Berkeley Packet Filters to hand off transaction execution to hardware level. Leveraging the Sealevel VM, Solana can concurrently execute transactions reading identical state and simultaneously execute non-overlapping transactions.
First Batch
Second Batch
Turbine Block Propagation Protocol: Turbine’s block propagation method draws heavily from platforms like BitTorrent. Turbine works by breaking data stored in blocks into smaller packets. The current block leader divides block data into packets no larger than 64KB, sending each packet to different validators. Upon receiving a packet, a validator forwards it to neighboring nodes, who then propagate it further down. Additionally, Turbine accounts for potentially dishonest nodes that might send incorrect data or withhold transmission. To address this, leaders generate Reed-Solomon erasure codes. Erasure codes allow each validator to reconstruct entire data chunks even if not all packets are received. If leaders transmit 30% of packets using erasure codes, the network can lose any 30% of packets without losing the data chunk. Leaders can adjust this percentage based on observed packet loss rates from previous data chunks.
Pipeline
Pipeline (Transaction Processing Unit for Validation Optimization): Pipelining refers to hardware-level optimizations enabling Solana to split input data streams into distinct processes running on different hardware. Pipelining leverages message queues supported by Rust channels to construct a three-stage pipeline.
Solana Pipeline
In the first stage, data is fetched and sent to kernel-level blocks. Specifically, kernel space passes data to the next GPU stage, where signatures can be verified in parallel. Once signatures are verified, the GPU transfers data to the CPU for the next banking stage. Meanwhile, kernel space has already fetched the next data set and retrieves data from the central processor to write onto the blockchain, sending it to other blocks.
An analogy helps explain this concept—dishwashing. Typically, dishwashing involves multiple stages: rinsing, sanitizing, drying, storing. Instead of one person completing each step sequentially, the first person rinses dirty dishes and stores clean, dry ones. But they pass dishes to someone else solely responsible for sanitizing. Perhaps this person can simultaneously soap/sanitize many dishes using a basin full of clean soapy water (a rough analogy for GPU parallelization). Finally, a third person focuses on drying these dishes and returns washed dishes to the first person for proper storage.
Cloudbreak Horizontally Scalable Account Database: Cloudbreak enables Solana to leverage concurrent reads/writes at the hardware level. Rather than relying on traditional databases for this goal (which is very difficult), Solana borrowed principles from operating systems to build a different type of database. Architecturally, Cloudbreak handles account data as follows:
-
Account and fork indexes stored in RAM
-
Accounts are memory-mapped
-
Each memory map stores accounts from a single proposed fork
-
Maps randomly distributed across SSDs
-
Leverages copy-on-write semantics
-
Writes added to random memory maps within the same fork
-
Index updated after each write completes
The Solana team had to build all query and data manipulation tools from scratch rather than rely on generic database abstractions. Consequently, the Solana network computes Merkle roots for state updates of a given fork through sequential reads horizontally scaled across SSDs. Even when Solana exceeds 10 million accounts (too much data to store entirely in RAM), Cloudbreak supports one million reads/writes per second on a single SSD.
Archivers Distributed Ledger Storage: Archivers are best viewed as lightweight clients that don’t download Solana’s full ledger. This is critical because Solana generates approximately 4 petabytes of data annually—only large validators with substantial storage capacity can store all this data. Archivers enable more nodes to store Solana’s historical data, reducing centralization risk. Essentially, archivers perform the same role as transaction-validating validators—they download portions of Solana’s ledger and provide Proofs of Replication (ProReps) to the broader validator set to confirm they’re not acting maliciously.
Solana’s Real-World Performance
Voting vs Non-Voting Transactions on Solana from Jan 1, 2022 to Present
Objective evaluation of Solana’s performance as a scalable blockchain requires considering factors that could invalidate “apples-to-apples” comparisons with other blockchains. For instance, Solana’s whitepaper claims theoretical throughput of 710,000 TPS. However, at the time of writing, Solana’s website shows average TPS around 1,500 over the past six hours. Thus, there’s roughly a 500x gap between Solana’s ideal future and current reality. Taking Solana’s self-reported TPS at face value is problematic because it counts internal consensus messages as transactions—an unusual practice among other blockchains. On Solana, consensus messages are called “voting transactions”—they involve validators with voting accounts processing vote registration, vote collection, and signing new votes. Transactions involving interactions with DApp smart contracts on Solana are called “non-voting” transactions (most other blockchains only count “non-voting” transactions in their TPS metrics). According to Dune Analytics, from March 2, 2022 to April 3, 2022, voting transactions accounted for 80–90% of all Solana transactions. Therefore, subtracting “consensus overhead” from Solana’s reported ~1,500 TPS yields a true TPS of approximately 300 non-voting transactions per second (though this is a moving target).
Auto MM
According to Dragonfly Capital research, Solana’s true scalable performance exceeds rival Layer 1s by 10–25x, but does not reach the frequently reported 100x or 1000x if surface-level metrics are taken literally. Dragonfly normalized blockchain performance across networks by conducting AMM trades on testnets using fully packed blocks. While imperfect, this benchmark certainly allows better cross-Layer 1 comparison than various chains’ claimed figures. While Solana’s actual performance based on these benchmarks (~272 Orca swaps per second) pales compared to its whitepaper’s theoretical 710,000 TPS, it remains an incredible figure relative to other protocols (like Ethereum’s 12–15 TPS limit). From a scalability perspective, this highlights Solana’s technology as seemingly best-in-class (for now). Still, other non-EVM chains (like NEAR) may achieve high “real-world throughput.”
Solana Transaction Processing Units
Combining all concepts described thus far, here’s a theoretical overview of a Solana transaction lifecycle:
Pre-transaction: During development, Solana smart contract developers explicitly declare a list of all accounts a transaction interacts with—critical for Solana to parallelize state changes via Sealevel.
Dapp sends transaction to user wallet (e.g., Phantom) for signing
User signs transaction with private key, paying a 0.000005 SOL fee (this number is currently fixed and deterministic)
Dapp sends user-signed transaction to Solana RPC server via sendTransaction HTTP API call
RPC server reads validator schedule (changes every 2 days) and forwards transaction as UDP packet
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@galaxyhq
