Case Study 1: The Blockchain Trilemma in Practice

Comparing Solana's Outages to Ethereum's Congestion

Introduction

On February 25, 2023, Solana's network stopped producing blocks for approximately 20 hours. Validators could not reach consensus, transactions could not be processed, and billions of dollars in assets were temporarily inaccessible. It was the network's sixth major outage in under two years.

On May 1, 2022, the launch of Otherside — a metaverse project by Yuga Labs, creators of Bored Ape Yacht Club — caused Ethereum gas fees to spike above $450 for a single transaction. Users spent over $180 million in gas fees in a matter of hours. Many transactions failed, and the fees were not refunded. The network did not go down, but it became unusable for anyone not willing to pay hundreds of dollars per transaction.

Both events exposed real failures. But they were fundamentally different kinds of failure, rooted in fundamentally different design choices. Understanding why each failure occurred — and why the other platform would not have experienced the same failure mode — is one of the clearest ways to grasp the blockchain trilemma in practice.

Background: The Blockchain Trilemma

The blockchain trilemma, often attributed to Vitalik Buterin, states that a blockchain can optimize for at most two of three properties:

1. Decentralization: Many independent validators can participate without requiring expensive hardware or special permissions.
2. Security: The network is resistant to attacks, manipulation, and failure. It continues operating correctly even if some participants act maliciously.
3. Scalability: The network can process a high volume of transactions quickly and cheaply.

The trilemma is not a formal theorem — it is a practical observation that designing for one property tends to constrain the others. A blockchain that requires very powerful hardware to validate (sacrificing decentralization) can process more transactions (gaining scalability). A blockchain that processes transactions slowly and deliberately (sacrificing scalability) can allow anyone to validate with modest hardware (gaining decentralization).

Every blockchain project is, at its core, a decision about where to position itself within this trilemma.

Solana's Design Choices

Solana was designed from the ground up for performance. Its key architectural decisions include:

Proof of History (PoH): Before consensus even begins, Solana uses a cryptographic clock — a sequential hashing function — to timestamp and order transactions. This eliminates much of the communication overhead that slows other blockchains, because validators do not need to negotiate the order of transactions through message passing.

High hardware requirements: Running a Solana validator requires enterprise-grade hardware — multiple high-end CPUs, 512+ GB of RAM, high-speed NVMe storage, and a 1 Gbps (ideally 10 Gbps) internet connection. This is radically more demanding than Ethereum, where a validator can run on a consumer laptop with 16 GB of RAM and a standard broadband connection.

Parallel transaction processing: Solana's Sealevel runtime processes transactions in parallel across multiple CPU cores, unlike Ethereum's sequential EVM execution.

Tight coupling: Solana's architecture is a single, tightly integrated system. All validators run the same software and must keep pace with the network's high throughput. There is no separation between execution and consensus layers of the kind that Ethereum has implemented.

The result: Solana can process thousands of transactions per second at fees under a penny. But the validator set is small (roughly 1,800-2,000 validators, compared to Ethereum's 900,000+ validators), geographically concentrated, and operationally homogeneous. When a bug or edge case disrupts the system, it tends to disrupt the entire network simultaneously.

Solana's Outage Pattern

Solana's outages have followed a recognizable pattern:

1. Traffic spike or edge case triggers unexpected behavior — such as a bot flood, a popular NFT mint, or a specific transaction type that exposes a bug in the consensus code.

2. Validators fall out of consensus — because the tightly coupled system requires all validators to process the same transactions in the same order at the same speed, any disruption that causes validators to diverge leads to a consensus failure.

3. Block production halts — the network stops processing transactions entirely. Unlike Ethereum, where high demand causes high fees (but the network keeps running), Solana's failure mode is binary: it either works at full speed or it stops.

4. Coordinated restart required — because the validator set is small and well-known, the core team and validators can coordinate a restart, often through a Discord channel. The network resumes, typically within 4-20 hours.

The February 2023 outage was caused by a bug in the durable nonce functionality that created a divergence between validator states. The September 2021 outage was triggered by a bot-driven transaction flood during an IDO (Initial DEX Offering) that overwhelmed the network's capacity. The pattern is consistent: high throughput under normal conditions, catastrophic failure under edge conditions.

Ethereum's Design Choices

Ethereum made the opposite set of tradeoffs. Its key architectural decisions include:

Low validator hardware requirements: Post-Merge, an Ethereum validator needs a consumer CPU, 16-32 GB of RAM, and a 1-2 TB SSD. This is hardware that costs under $1,000. The low barrier to entry is a deliberate design choice to maximize decentralization.

Sequential execution: The EVM executes transactions sequentially, one at a time. This is slower than parallel execution but simpler and easier to reason about, reducing the surface area for consensus-breaking bugs.

Fee market (EIP-1559): When demand exceeds capacity, Ethereum does not fail — it raises prices. The base fee increases automatically as blocks fill up, pricing out users who are not willing to pay the current rate. This is economically harsh but operationally robust.

Separation of concerns: Ethereum has deliberately separated the execution layer (where transactions are processed) from the consensus layer (where blocks are finalized). This modular architecture makes the system more resilient to bugs in any single component.

The result: Ethereum processes only 15-30 transactions per second on its base layer and fees can become prohibitive during demand spikes. But the network has never experienced a full production outage since The Merge. It degrades gracefully — becoming expensive rather than unavailable.

The Otherside Mint: Ethereum's Failure Mode

The May 2022 Otherside mint demonstrated Ethereum's failure mode clearly:

1. Massive simultaneous demand: Tens of thousands of users attempted to mint Otherside NFTs within the same block window.

2. Gas fee auction: Because Ethereum uses a fee market, users competed by offering higher and higher gas fees. Priority fees (tips to validators) reached hundreds of dollars.

3. Failed transactions still charged fees: Users who submitted transactions that ultimately failed (because the NFTs sold out before their transaction was processed) still paid gas fees. Some users lost hundreds of dollars on failed transactions.

4. Network continued operating: Despite the chaos, Ethereum continued producing blocks every 12 seconds. Every other application on the network — DeFi protocols, other NFT platforms, stablecoin transfers — continued functioning, albeit at extremely high cost. The network was not down. It was expensive.

5. No coordinated intervention required: The situation resolved itself as the demand subsided. Gas fees returned to normal within hours. No restart, no Discord coordination, no validator intervention.

Comparing the Failure Modes

The critical distinction is between liveness failure and economic exclusion. Solana's outages are liveness failures — the network stops performing its core function. Ethereum's congestion events are economic exclusion — the network continues functioning but becomes too expensive for most users. Neither outcome is acceptable as a long-term state, but they represent different types of unacceptability.

The DeFi Liquidation Problem

One of the most revealing comparisons involves DeFi liquidations. In lending protocols, if a borrower's collateral drops below a certain threshold, the protocol needs to liquidate (sell) the collateral to maintain solvency. This is a time-critical operation.

On Ethereum during congestion: Liquidations still execute, but the gas cost is high. Liquidators (the bots and users who trigger liquidations in exchange for a reward) pay elevated fees, which reduces their profit margin. In extreme cases, the cost of executing a liquidation may exceed the reward, creating a temporary gap. But the mechanism continues functioning.

On Solana during an outage: Liquidations cannot execute at all. Collateral values may be dropping in real-time (since the underlying assets are traded on other platforms), but the Solana-based lending protocol cannot respond. If the outage lasts long enough and collateral values drop far enough, protocols can become under-collateralized — loans are worth more than the collateral backing them. This creates a solvency risk that does not exist on a network that degrades economically rather than operationally.

This is not a theoretical concern. During Solana outages, DeFi protocols have reported positions that would have been liquidated had the network been operational. The risk was real.

What Each Side Says

Solana advocates argue:

• Outages are engineering problems that get fixed with maturity. The internet had outages in its early years too.
• Between outages, Solana provides a radically better user experience — sub-second finality, near-zero fees.
• Ethereum's fee spikes are their own form of outage: if you cannot afford to transact, the network is effectively down for you.
• The validator restart mechanism, while not ideal, demonstrates the community's ability to coordinate and recover.

Ethereum advocates argue:

• A network that stops producing blocks has fundamentally failed at its core function. An expensive network is still a functioning network.
• The tight coupling that enables Solana's performance is an architectural liability, not just an engineering bug. Fixing individual outage causes does not fix the underlying fragility.
• Decentralization is not just a value — it is a security property. A network that can be restarted by a small group of validators through a Discord call is not decentralized in any meaningful sense.
• Ethereum's scaling roadmap (Layer 2 rollups) addresses cost without sacrificing base-layer reliability.

Analysis Questions

1. Liveness vs. cost: Which failure mode do you consider more severe — a network that stops entirely for 20 hours, or a network that becomes 100x more expensive than normal for 6 hours? Does your answer change depending on the use case (casual user vs. DeFi protocol vs. institutional settlement)?

2. The maturity argument: Solana advocates compare their outages to the early internet's reliability problems. Is this a valid comparison? What would need to be true about Solana's architecture for outages to decrease over time, and what would need to be true for them to be inherent to the design?

3. Decentralization's value: Ethereum's ability to continue operating during demand spikes is partly a function of its decentralized design — many diverse validators running on diverse hardware in diverse locations are harder to disrupt simultaneously. How much extra cost (in fees) is this resilience worth? Is there a principled way to answer this question?

4. The L2 resolution: Ethereum's answer to its cost problem is Layer 2 rollups. If L2s successfully reduce fees to Solana-like levels while inheriting Ethereum's base-layer security, does Solana's value proposition disappear? Or are there use cases where a single high-performance L1 is preferable to an L1+L2 stack?

5. DeFi implications: The liquidation analysis shows that Solana outages create solvency risk for on-chain lending protocols. Should DeFi protocols on Solana maintain larger collateral buffers to account for potential outage-related liquidation delays? What would the economic cost of such buffers be, and who would bear it?

Conclusion

The Solana vs. Ethereum comparison is not a story about which blockchain is "better." It is a story about engineering tradeoffs that have real consequences. Solana chose speed and low cost, accepting the risk of liveness failures. Ethereum chose decentralization and reliability, accepting the reality of economic exclusion during demand spikes. Both are working on their respective weaknesses — Solana through engineering improvements to reduce outage frequency, Ethereum through Layer 2 solutions to reduce costs.

The blockchain trilemma predicts that these tradeoffs are fundamental, not accidental. If that prediction holds, then the question is not which tradeoff is universally correct but which tradeoff is appropriate for which use case. A payment system that must never go down might prefer Ethereum's design. An application that must be cheap and fast for everyday users might prefer Solana's. The mature view is not to pick a winner but to understand why the tradeoff exists and what it implies for each specific application.

This case study demonstrates a principle that will recur throughout this book: in blockchain design, there are no free lunches. Every performance gain comes at a cost somewhere else in the system. The skill is in understanding where the cost is hidden.

Further Reading for This Case Study

• Solana Foundation post-mortem reports for each major outage (available on the Solana Status page and Solana Foundation blog)
• "Ethereum's Rollup-Centric Roadmap" by Vitalik Buterin (vitalik.eth.limo)
• Solana validator requirements documentation (docs.solana.com)
• EIP-1559 specification and fee market analysis
• Chapter 13 of this textbook: Consensus Mechanisms Compared