Why Web3 Can’t Read — ForkLog

# Why Web3 Can’t Read

Just a few years ago, the industry debated how to increase blockchain throughput. Today, many networks already process tens of thousands of transactions, and some claim hundreds of thousands. However, it turned out that writing data to a blockchain is only half the job. You still need to find it, index it, verify it, and deliver it to applications.

So, in some places, the speed of data generation has started to outstrip the infrastructure’s ability to process it. How the blockchain is changing in response—ForkLog has looked into it.

The faster, the longer it takes

About ten years ago, blockchain development was described through the so-called scalability trilemma. According to this concept, networks have to make compromises between security, decentralization, and performance. But in 2026, it becomes clear that even if the throughput problem can be solved partially, a new challenge emerges.

A blockchain by itself has no user interfaces. That role is taken on by various applications. And they, in turn, must constantly receive data:

• address balances;
• transaction history;
• the state of smart contracts;
• events and logs;
• market analytics;
• data for risk management;
• cross-network messages.

The faster the network works, the more of this kind of data needs to be processed

Among users, a common misconception persists: if information is written to the blockchain, it must be easy to get. In practice, it’s exactly the opposite. Reading “raw” data directly from the blockchain in real time is a slow, expensive, and technically complex process. In the Web3 ecosystem, an intermediate infrastructure layer is widely used—it connects wallets to dapp applications.

For example, in order for a wallet app to show a user’s balance within a fraction of a second, it reaches out to RPC providers, indexers, analytics platforms, cache servers, specialized databases, and so on.

The process works like this:

1. Data collection: Special programs continuously “read” the blockchain as new blocks appear.
2. Indexing (structuring): They parse (break down) this data and distribute it into classic, very fast databases (for example, PostgreSQL or ClickHouse). There, it’s structured in a convenient format: “Address — a list of all its tokens.”
3. Instant response: The wallet receives a ready-made, filtered response from cache in milliseconds.

In practice, most popular Web3 applications operate through an additional layer of information processing. Imagine that the blockchain processes 50,000 operations per second, and millions of wallets simultaneously send RPC requests to update their screens. The provider servers can’t handle that load. Reading, indexing, and sorting data for the user is an extremely complex computational task. Indexers and data-access services often lag behind the network’s current state by several blocks, because processing, structuring, and delivering data take additional time. And it’s not just about “outdated infrastructure,” although that certainly exists. It’s about a deeper architectural conflict between Web2 and Web3

Users and applications interact with the blockchain as actively and frequently as they do with instant-response servers in everyday internet use. When you scroll a social media feed, the app makes thousands of requests per second to a server to update likes, comments, and images. In Web2, trading bots can poll exchange servers millions of times per minute. Google or Amazon servers can easily handle this because they’re centralized—data, roughly speaking, sits in one massive database, from which it can be instantly copied to thousands of mirror servers worldwide.

A blockchain is built differently; it isn’t hardware-ready for that. Until recently, the main bottleneck in blockchain speed was math and cryptography. You had to get thousands of computers around the world to quickly agree (reach consensus) that a transaction is valid. Developers solved this problem by “teaching” machines to perform parallel execution and by separating consensus and execution. For example, Solana, Monad, and Aptos support parallel execution of independent transactions, unlike Ethereum’s classic sequential model. At the same time, Monad especially clearly separates agreeing on the transaction order and its subsequent execution, while in Solana and Aptos parallelism is implemented via runtime architecture and state-based conflict management.

As a result, you can approve tens of thousands of transactions per second (TPS). But that’s where the trap lies.

Historically, a blockchain performed four functions at once:

• transaction execution;
• consensus;
• data storage;
• providing access to data.

An increase in performance simultaneously increases the load on all four of these functions. The system starts generating data faster than the infrastructure can read it, creating what’s known as an indexer gap.

In the documentation of Helius, one of the largest infrastructure providers in the Solana ecosystem, it’s explicitly noted that the blockchain’s sequential structure is well suited for ensuring data integrity and high throughput, but it makes historical queries slow and inefficient. Therefore, most companies have no choice but to build their own indexers and separate databases on top of the blockchain.

ChainScore Labs analysts call the indexer gap one of the key problems in the Solana ecosystem. Based on their assessment, traditional indexing approaches cope poorly with a network architecture where high block frequency and parallel transaction execution create an enormous stream of data.

The outcome is this: the network can confirm transactions almost instantly, but applications need significantly more time to process the consequences of those transactions.

Web3 speeds hit basic physics (and not only that)

More precisely—processor throughput, hard drives, and network cables. It turned out that blockchain scalability is not the same as the scalability of the infrastructure around it. And this has to be addressed as quickly as possible

Let’s imagine a network with 100,000 TPS. You don’t just need to record the transaction, but also:

• maintain state;
• update indexes;
• respond to wallet requests;
• serve bots;
• serve analysts;
• serve search engines;
• serve AI agents.

That’s why high throughput creates resource competition between consensus, transaction execution, and infrastructure services built on top of the network.

The parallel development of some technologies involved forces this problem to be solved right now. For humans, a delay of seconds or even minutes can be quite tolerable. For AI agents, trading systems, and autonomous services—there’s no tolerance. If a machine makes decisions based on on-chain data, outdated information means an error, lost opportunity, or direct financial loss.

At the same time, Ethereum Foundation in updated 2026 documentation states that archival nodes require between 3 and 12 TB of disk space, and initial syncing can take up to a month even on sufficiently powerful equipment. The limiting factors are SSD speed, memory capacity, and CPU performance.

Moreover, Geth developers separately describe the old archival storage model, where the Ethereum database size could exceed 20 TB, and syncing could take months. That’s exactly why a new path-based state storage architecture had to be created.

So yes—hardware, processors, network bandwidth, CPU—are real physical constraints in the race to grow information. But they’re not the only ones. Modern servers are already capable of processing huge volumes of data. The real question is: how much do thousands of independent participants in the network have to pay for it?

For example, if full participation in the ecosystem requires tens of terabytes of SSDs, hundreds of gigabytes of RAM, and expensive communication channels, then the number of infrastructure operators inevitably drops. That’s how new centralization emerges.

In theory, you can process the data, but you won’t be able to make it both cheap and decentralized at the same time. The cost of processing information starts rising faster than the cost of the transactions themselves.

How the market responded

The participants in this race already understand that the winners will be the networks that can turn transactions into usable information faster, cheaper, and more reliably. And over the current year, the market unexpectedly shifted its focus toward the transition to modular blockchains.

If the first generation of networks tried to do all tasks at once, the new generation splits responsibilities across specialized layers. Instead of one network, there are separate layers:

• execution layer — the execution (or transaction processing) level;
• settlement layer — the settlement (finalization) level;
• consensus layer — the consensus level;
• data availability layer — the data availability level.

Developers compare this process to the evolution of data centers. Back then, one server handled all functions at once. Today, computation, data storage, and network services scale independently of each other

One of the fastest-growing directions in the market has become DA networks. At first glance, the idea sounds strange: why create a separate blockchain for temporary storage of another blockchain’s data? But that’s exactly what happens. In a modular architecture, transaction execution and data storage can exist separately. A rollup publishes data to an external DA layer rather than to the main network. This significantly reduces the cost of scaling and increases throughput.

A few years ago, RPC was considered just a technical detail. Today, it’s one of the most important elements of crypto infrastructure. In May 2026, Triton One together with Solana Foundation released an updated announcement for RPC 2.0—this is a new approach to building a data-reading architecture in the network

The core idea is to separate access to the network’s current state from its history. To do this, two independent modules are introduced: one indexes account state in real time, and the second optimizes handling historical data. Instead of fully scanning the blockchain, the system forms adaptive indexes for specific application requests, reducing latency and processing cost.

So Triton and Solana aim to eliminate a set of systemic constraints: expensive and inefficient monolithic architectures of RPC nodes, a narrow set of JSON-RPC standard requests, and developers’ dependence on their own or proprietary solutions for working with data. In the new reading model, scaling happens separately from consensus, and access to history becomes faster thanks to columnar storage and pre-sorted data.

The project builds on tools already implemented in the ecosystem—including streaming data from validators (Geyser, Yellowstone gRPC) and solutions for processing history. All infrastructure is distributed as open source, and its development is coordinated with participation from Solana Foundation.

As a result, Solana is effectively trying to move from a “universal” RPC toward a modular, specialized data infrastructure—one that is said to reduce barriers for developers and make working with blockchain data as convenient as with traditional databases.

Does modularity solve the problem?

If Solana manages to standardize the reading layer, it could strengthen its position as a network with developed application infrastructure—not just high throughput. But at the same time, it increases competition with independent RPC providers and infrastructure platforms, which will have to either adapt to the new standard or offer additional services on top of it.

A modular architecture removes some infrastructure constraints, but moves them into other layers of the system. It’s clear there’s a drive to reduce cost and simplify access to data, without which DeFi, NFTs, wallets, analytics, and compliance tools can’t work. However, it seems that the very nature of Web3 is built around a cascade effect of added complexity: solving one problem inevitably creates new challenges.

The new setup will unambiguously require a more complex infrastructure layer: with indexers, storage, cache, separate pipelines, and new points of failure. Instead of a single simple RPC layer, the ecosystem could end up with several parallel implementations, incompatible optimizations, and even greater dependence on infrastructure providers. In that case, a formally open architecture doesn’t necessarily mean a truly open and convenient access model for everyone.

For now, we’re at the stage where the market has shifted from competition over who can retrieve data from the network better to competition over who will create products on top of that data first. Who will pay for it—and how much—will likely become clear soon