ChainflowBreakpoint 2025: Scaling the Read Layer to 1M TPS
In December 2025, the global Solana community got together for Breakpoint - Solana's annual flagship event. The agenda was packed, and we heard many insightful talks and breaking news announcements from the stage. In this series, we'll recap some of the most interesting talks from Breakpoint 2025.Today we share Scott Hague's talk on scaling Solana to 1M TPS.The next frontier for high-throughput blockchains is not just about writing 1 million transactions per second. It's about reliably reading that flood of data without stalls, stale state, or astronomical infrastructure costs. Traditional RPC stacks — non‑voting validators with RPC bolt-ons — are hitting their limits. That creates latency, slot lag, and flaky behavior for latency‑sensitive apps like rug checks and market feeds.The core problem: reading at massive scaleIn practice, clients frequently hit silent failures or long delays when calling heavy RPC endpoints (for example, long getProgramAccounts queries on hot programs). Multiple clients competing for the same RPC resources only makes things worse: you get lagging slots, stale data, and complex leader tracking headaches.Three consequences stand out:High hardware and bandwidth costs from stacking expensive RPC servers.Poor UX for latency‑sensitive applications due to slow or stale reads.Fragile, custom indexing systems where teams rebuild the same tooling over and over.Rebuilding the RPC layer with three guiding principlesScalability, reliability, and performance.To solve these issues, the read layer must be decoupled from consensus. When the read layer is independent from voting and consensus, teams can scale reads horizontally on commodity cloud hardware without forcing validators to carry the weight of every client request.The solution has three practical implications:Independent scaling: Read infrastructure scales separately from consensus and voting, so you no longer need to provision expensive validator hardware just to handle RPC traffic.Microservice architecture: Decoupled services add redundancy at each layer, enabling consistent layer‑1 data delivery rather than a hierarchical queue where some clients wait behind others.Bandwidth efficiency: Optimizations reduce ingress and egress bills so high TPS does not mean massive network costs.Lantern: a local RPC optimized for your DAppRather than forcing every application to ingest the full Solana firehose or run bespoke indexers, Lantern acts as a local RPC tailored to the data needs of a single DApp. Think of it like having your database next to your application server but for blockchain state.Key features of Lantern:Selective streaming: Subscribe only to the accounts and data your app needs, not the entire blockchain state.Zero‑latency local calls: Stream selected data into your data center or edge instance and query it locally for instant responses.Full RPC compatibility: Supports standard RPC calls, WebSockets, Yellowstone streams, and (planned) webhooks. It also supports direct TPU transaction sending to help avoid toxic order flow.Minimal resource footprint: Lantern can run on commodity hardware — even a Raspberry Pi demo shows market data streams working smoothly.How Lantern actually worksLantern is built on three main components:Validator fleet and Firedancer tiles: Custom ingestion nodes capture layer‑1 data reliably and feed the ingestion engine.Scalable ingestion pipeline: A microservices pipeline processes incoming data and powers both public RPCs and private Lantern instances.Delta Stream: Instead of resending entire account payloads every update, Delta Stream transmits only the bytes that changed. That drastically reduces network demands.Delta Stream and intelligent subscription work together. If Lantern receives a request for data it hasn't cached yet, it automatically configures that subscription on the ingestion pipeline and begins streaming only the changes. The result is near zero touch setup for developers.Why Delta Stream mattersDelta Stream changes the bandwidth equation. Instead of needing a 10 Gbps pipe to keep up with full state updates, you can operate on a 100 Mbps connection by streaming only bytes that change. That reduces both infrastructure costs and egress bills.Performance and cost winsRealistic outcomes from deploying Lantern and the decoupled read architecture:Public RPCs: ~20% cost reduction compared to traditional RPC setups.Private RPCs: ~80–90% reduction in monthly costs versus typical private RPC servers.Resource and latency: Up to a 99% reduction in resource requirements and a 99% reduction in latency for locally served queries.That means no more paying thousands of dollars a month for RPC capacity you rarely use, and no more high‑latency lookups for critical UI and monitoring paths.Running Lantern in productionLantern is designed as a drop‑in replacement for existing RPC setups. It supports common interfaces and will fit most architectures with minimal changes. Deployment options include:Local instances co‑located with application servers for zero‑latency queries.Edge deployments on lightweight hardware (demonstrated on Raspberry Pi).Cloud instances using commodity VMs for easy horizontal scaling.If your app needs additional throughput, scale out more Lantern instances. The microservice ingestion layer and Delta Stream will handle the rest.Practical checklist for teamsTo move from a legacy RPC stack to a Lantern‑powered read layer, consider this checklist:Identify the account sets and program data your application truly needs.Deploy Lantern instances next to your app servers or edge nodes.Enable intelligent subscriptions for on‑demand data you haven’t preselected.Monitor bandwidth usage and scale Lantern horizontally if you need higher RPS/TPS.Use direct TPU transaction senders when order flow sensitivity matters.ConclusionScaling to 1M TPS is only meaningful if clients can read that data reliably and cheaply. Decoupling the read layer, embracing microservices, and streaming only the changes are practical steps that dramatically reduce latency and cost. Lantern brings the database‑next‑to‑server model to Web3, letting developers query local, tailored state with the same comfort as Web2 applications.For teams building latency‑sensitive tooling, market UIs, or on‑chain monitoring systems, a local, delta‑streaming RPC can remove a lot of operational pain and deliver better user experiences at a fraction of the cost.Watch full talk here:
