Course 11, Lesson 11: Horizontal vs. Vertical Scaling

Where XRPL Can Still Scale Vertically:

Component	Current Typical	Available 2025	Improvement
CPU	8-16 cores	64-128 cores	4-8x
RAM	64 GB	512 GB - 1 TB	8-16x
Storage IOPS	100K-200K	1M+ (Optane)	5-10x
Network	1 Gbps	100 Gbps	100x

Theoretical Improvement from Vertical Scaling:

• Consensus (64% of time): Cannot be improved by faster hardware
• Parallel operations (36% of time): Can improve 4-8x

Maximum speedup = 1 / (0.64 + 0.36/8) = 1.47x

Even with infinitely fast hardware for non-consensus operations, throughput improves by less than 50% because consensus dominates.

Hard Limits:

1. Consensus Bound: 64% of transaction time is consensus, which requires network round-trips regardless of local hardware speed

2. Memory Wall: Once working set exceeds CPU cache, memory latency becomes dominant. Even with 1 TB RAM, access patterns matter more than size.

3. Single-Thread Consensus: The consensus algorithm has sequential dependencies that prevent parallelization within a single ledger.

4. Diminishing Returns: Hardware price/performance improvements of 2x every 2-3 years are slower than traffic growth rates for successful applications.

Practical Ceiling Estimate:

• Maximum sustainable TPS: ~3,000-4,000 (2-2.5x current)
• Maximum burst TPS: ~5,000-6,000
• Cost: $10,000-50,000 per validator node

Beyond this, vertical scaling hits fundamental limits.

---

In traditional systems, horizontal scaling follows this pattern:

Request → Load Balancer → Server 1 (handles request independently)
                       → Server 2 (handles request independently)
                       → Server 3 (handles request independently)

Each server handles different requests, and coordination happens after the fact.

In blockchain systems:

Transaction → All Validators → Consensus → All Validators Apply

Every validator must process every transaction. Adding validators doesn't increase throughput—it increases redundancy and potentially decreases throughput (more nodes to reach consensus).

Where Horizontal Scaling Cannot Help:

Operation	Why Not Parallelizable
Consensus	All validators must agree on order
State Updates	Dependencies between transactions
Total Ordering	Global sequence required
Finality	Every node must apply same changes

---

Sharding divides the network state into partitions (shards), each processed by a subset of validators. In theory:

Shard 1: Accounts A-M → Validators 1-50 → 1,500 TPS
Shard 2: Accounts N-Z → Validators 51-100 → 1,500 TPS
                                           ─────────
                                Total:     3,000 TPS

With N shards, throughput theoretically scales to N × single-shard TPS.

Reality is messier. Consider a payment from account A (Shard 1) to account Z (Shard 2):

Technical Challenges:

1. DEX Order Matching: Orders can match across any currency pair. How do you shard an order book where XRP/USD and XRP/EUR and USD/EUR all interact?

2. Pathfinding: Cross-currency payments find paths through arbitrary trust lines. Paths routinely span accounts that would be in different shards.

3. Global State Dependencies: Account reserves, network fees, and amendment voting require global consensus.

4. Liquidity Fragmentation: Sharding order books fragments liquidity, worsening execution quality.

Economic Challenges:

1. Validator Incentives: With sharding, validators only secure a fraction of the network. Does this change their incentive structure?

2. Security Guarantees: Each shard has fewer validators. A 150-validator network split into 3 shards has only 50 validators per shard—lower Byzantine fault tolerance.

3. Complexity Cost: Sharding adds attack surface, failure modes, and operational complexity.

Aspect	Status	Timeline
Research	Ongoing, no concrete proposal	-
Technical Feasibility	Possible but complex	3-5 years to design
Implementation	Would require major protocol changes	5-10 years to deploy
Adoption	Would require network-wide consensus	Years after implementation

Bottom Line: Sharding is not coming to XRPL soon. Anyone claiming otherwise isn't being realistic about the technical and coordination challenges involved.

---

Layer 2 solutions move transactions off the main chain while inheriting its security guarantees:

Layer 1 (XRPL): Settlement, Security, Finality
                    ↑
            Periodic Settlement
                    ↑
Layer 2: High-Volume, Fast, Cheap Transactions

XRPL already has payment channels—a native Layer 2 solution.

State channels extend payment channels to arbitrary state:

1. Lock state on-chain (deposit, escrow)
2. Off-chain state updates (signed by both parties)
3. Either party can close channel with latest state
4. Dispute resolution: Submit to chain if disagreement

Sidechains are separate blockchains that can transfer assets to/from XRPL:

XRPL (Main Chain)
    ↑
  Bridge (Federated or Trustless)
    ↓
Sidechain (Higher throughput, different rules)

Sidechain Trade-offs:

Aspect	Federated Bridge	Trustless Bridge
Security	Trust federation	Cryptographic proofs
Speed	Fast	Slower (proof verification)
Complexity	Simpler	Complex
Failure Modes	Federation compromise	Proof system bugs

• XRPL sidechain functionality exists
• EVM sidechain in development
• Adoption remains limited
• Bridge security is unsolved at scale

Security Inheritance:

Solution	Security Level	Assumption
Main Chain	Full XRPL security	N/A
Payment Channels	Full (eventually)	Parties monitor chain
State Channels	Full (eventually)	Parties or watchtowers monitor
Federated Sidechain	Trust federation	Federation is honest
Trustless Sidechain	Cryptographic	Proof system is sound

---

Real applications often combine approaches:

Architecture: Tiered by Transaction Type

Tier 1 (Layer 1 - XRPL):
├── Large settlements (>$10,000)
├── Trust line changes
├── DEX orders (price discovery)
└── Regulatory-required finality

Tier 2 (Payment Channels):
├── Recurring payments between known parties
├── Micropayment streaming
├── High-frequency API billing
└── Gaming micro-transactions

Tier 3 (Off-Chain):
├── Transaction batching
├── Internal ledger entries
├── Pending/unconfirmed balances
└── Non-financial operations

High-Performance Exchange Scaling:

User Deposits (Layer 1):
User → XRPL Deposit Address → Exchange Hot Wallet
(Full XRPL security, ~4 second finality)

Internal Trading (Off-Chain):
User A ←→ Exchange Database ←→ User B
(Instant, free, unlimited throughput)

User Withdrawals (Layer 1):
Exchange Hot Wallet → User → XRPL Settlement
(Full XRPL security, ~4 second finality)

Settlement Between Exchanges (Layer 1 or Payment Channel):
Exchange A ←→ XRPL ←→ Exchange B
(Periodic net settlement reduces transaction count)

Result: Exchanges routinely handle 100,000+ trades per second using off-chain order books, with only deposits/withdrawals touching Layer 1.

Scaling-Ready Architecture Principles:

1. Abstract the Settlement Layer

// Implementations
class XRPLSettlement implements SettlementProvider
class PaymentChannelSettlement implements SettlementProvider
class SidechainSettlement implements SettlementProvider

- Reads can scale horizontally (multiple stock nodes)
- Writes must go through consensus
- Cache reads aggressively, optimize writes carefully

- Aggregate multiple logical operations into single transactions
- Net positions before settling
- Periodic settlement windows

- Identify transaction types suitable for Layer 2
- Design user experience that abstracts settlement layer
- Build monitoring for multi-layer operations

---

There is no free lunch in blockchain scaling. Every approach involves trade-offs:

Approach	What You Gain	What You Give Up
Vertical	Simplicity	Hard ceiling, cost
Horizontal Read	Read throughput	Write unchanged
Sharding	Write throughput	Simplicity, possibly security
Layer 2	Performance	Some finality, complexity
Sidechains	Features	Security model changes

The right choice depends on your specific requirements, not on marketing claims about "unlimited scaling."

---

Estimated Time: 3-4 hours

---

What This Tests: Understanding of cross-shard transaction challenges and XRPL's use case requirements.

What This Tests: Understanding of hybrid architectures and Layer 1 vs. off-chain operations.

What This Tests: Quantitative analysis of scaling approaches using performance engineering fundamentals.

What This Tests: Understanding of security trade-offs in Layer 2 solutions.

What This Tests: Practical application of Layer 2 solutions to real use cases.

---

---

Next Lesson: Sidechains & Federated Scaling — Deep dive into multi-chain architecture and cross-chain performance

---

Course 11, Lesson 11 of 15 • XRPL Performance & Scaling