# 为什么 Web3 读不懂
再过几年，行业还在争论如何提升区块链的吞吐量。如今，许多网络已经能够处理数万笔操作，甚至有些宣称能达到数十万。然而事实表明，把数据写入区块链只是任务的一半。接下来还需要把数据找出来、进行索引、校验，并交付给应用程序。
因此，在某些地方，数据生成速度开始超过基础设施的处理能力。ForkLog 已经梳理了区块链如何因此而变化。
大约十年前，区块链的发展通常用所谓的可扩展性三难困境来描述。根据这一概念，网络被迫在安全性、去中心化和性能之间寻找折中。但到 2026 年，情况变得愈发清晰：即便吞吐量问题能够在一定程度上被解决，又会出现新的挑战。
区块链本身并没有用户界面。这个角色由各类应用承担。而它们又必须持续获取数据：
网络运行得越快，就需要处理越多此类数据。
在用户中存在一种常见误解：只要信息被写入区块链，就意味着可以轻松获取。实际上恰恰相反。从区块链直接在实时读取“原始”数据，这是一个缓慢、昂贵且在技术上很复杂的过程。在 Web3 生态系统中，广泛存在一个中间基础设施层，用来把钱包连接到 dapp 应用。
例如，一个钱包应用要让用户在数秒之内看到余额，它会向 RPC 提供方、索引器、分析平台、缓存服务器、专业数据库等发起请求。
整个过程如下：
实际上，大多数主流 Web3 应用都通过额外一层信息处理来运行。想象一下：如果区块链每秒处理 50 000 笔操作，而数百万钱包同时发送 RPC 请求以刷新屏幕。提供方的服务器无法承受这种负载。为了让用户获得可用数据，需要读取、索引并排序——这是一项极为复杂的计算任务。索引器和数据访问服务往往会比网络的最新状态落后几个区块，因为数据的处理、结构化与交付都需要额外时间。问题不只是“过时的基础设施”（当然，这种情况也确实存在），更是 Web2 与 Web3 的架构之间存在深层的冲突。
用户与应用与区块链的交互活跃程度和频率，几乎与熟悉的互联网、并带有即时响应的方式一样。当你刷社交媒体信息流时，应用会在每秒向服务器发起数千次请求，用来更新点赞、评论和图片。Web2 中的交易机器人每分钟可能会向交易所服务器发起数百万次轮询。Google 或 Amazon 的服务器能够轻松承受，因为它们是中心化的：数据基本都存放在一整个超大数据库中，然后可以立即复制到全球成千上万台服务器镜像上。
区块链的工作方式不同，它在硬件层面并不为此类操作做好准备。直到不久前，区块链速度的主要障碍仍是数学计算和密码学。需要让全世界成千上万台计算机快速达成一致（共识），即确认某笔交易是有效的。开发者通过“教会”机器进行并行执行，并把共识与执行拆分，从而解决了这一问题。例如 Solana、Monad 和 Aptos 支持对彼此独立的交易进行并行执行，这区别于以太坊的经典顺序模型。与此同时，Monad 尤其明确地拆分了交易顺序的协商与随后执行，而在 Solana 和 Aptos 中，并行性则通过 runtime 架构与基于状态的冲突管理来实现。
最终，你可以批准每秒数万笔交易（TPS）。但这里就存在一个陷阱。
从历史上看，区块链同时承担四项功能：
性能的提升会同时增加对这四项功能的负载。系统生成数据的速度快于基础设施读取数据的速度，从而形成所谓的 indexer gap。
在 Helius 的文档中——它是 Solana 生态系统中最大的基础设施提供方之一——明确指出，区块链的顺序结构适合保障数据完整性并提供较高的吞吐量，但会使历史查询变得缓慢且不高效。因此，大多数公司被迫在区块链之上构建自己的索引器和独立的数据库。
ChainScore Labs 的分析师将 indexer gap 称为 Solana 生态系统的关键问题之一。他们认为，传统的索引方式难以适配网络架构：高频出块与交易并行执行会制造出巨大的数据流。
于是会产生这样的效果：网络可以几乎即时地确认操作，但应用程序处理这些操作的后果需要更长得多的时间。
更准确地说，是卡在处理器、硬盘和网络电缆的吞吐能力上。事实表明，区块链的可扩展性并不等于其周边基础设施的可扩展性。并且必须尽快解决这个问题。
假设有一个 100 000 TPS 的网络。它不仅要把交易写入，还要：
因此，高吞吐量会在共识、交易执行以及网络之上的基础设施服务之间制造资源竞争。
参与其中的部分技术并行演进，迫使我们现在就要解决这个问题。对人类来说，延迟以秒甚至分钟计可能还可以接受。对 AI 代理、交易系统和自动化服务而言则不行。如果机器基于链上数据做决策，那么过时的信息就意味着错误、失去机会，甚至直接的财务损失。
与此同时，Ethereum Foundation 在更新的 2026 年文档中指出：归档节点需要 3 到 12 TB 的磁盘空间，而即使在相当强大的设备上，初始同步也可能要花到一个月。限制因素来自 SSD 的速度、内存容量以及处理器性能。
此外，Geth 的开发者还单独描述了旧的归档存储模型：当时以太坊数据库大小可能超过 20 TB，同步要花上数月。正因如此，才不得不创建新的基于路径（path-based）的状态存储架构。
也就是说，是的，“硬件”、处理器、网络吞吐能力、CPU——这些都是在争夺信息增长时的真实物理限制。但这并不是全部。现代服务器已经能够处理巨量数据。问题在于：成千上万的网络独立参与方，为了做到这件事，需要付出多少成本？
例如，如果要在生态系统中全面参与，需要数十 TB 的 SSD、数百 GB 的 RAM、昂贵的通信链路，那么基础设施运营商的数量不可避免地会减少。于是就会出现新的中心化。
从形式上讲，处理数据是可以做到的，但无法同时做到便宜且去中心化。信息处理的成本开始增长得比交易本身的成本更快。
竞赛中的参与者已经明白：最终会赢的那些网络，将能够更快、更便宜、更可靠地把交易转化为可用的信息。而就在今年，市场的关注点出现了意外转向：转向模块化区块链。
如果第一代网络试图把所有任务同时完成，那么新一代会把职责在专门化的各个层之间拆分。于是，不再只有一个网络层次，而是出现了独立的层：
开发者把这个过程类比为数据中心的演化。过去，一个服务器同时承担所有功能。今天，计算、数据存储和网络服务可以独立于彼此进行扩展。
市场增长最快的方向之一是 DA 网络。乍一看这个想法很奇怪：为什么要为另一个区块链的数据临时存储创建一个独立的区块链？但事情正是如此。在模块化架构里，交易执行和数据存储可以彼此独立。Rollup 会把数据发布到外部的 DA 层，而不是主网络。这样可以显著降低扩展成本，并提升吞吐量。
再过几年前，RPC 还被视为一个技术细节。如今，它已经成为加密基础设施中最重要的组成部分之一。到 2026 年 5 月，Triton One 联合 Solana Foundation 发布了更新的 RPC 2.0 公告——这是一种新的网络读取数据架构方式。
其核心思想在于：把对网络当前状态的访问与其历史记录分离。为此引入两个相互独立的模块：一个实时索引账户状态，另一个优化对历史数据的处理。系统不再对整个区块链进行全量扫描，而是针对具体应用请求生成自适应索引，从而降低延迟并减少处理成本。
因此，Triton 和 Solana 试图消除一系列系统性限制：昂贵且低效的 RPC 节点单体架构、JSON-RPC 标准请求的狭窄集合，以及开发者对自有或专有数据处理方案的依赖。在这种新模型下，读取可以独立于共识进行扩展，而通过使用列式存储和预排序数据，历史访问也会变得更快。
该项目依托生态系统中已落地的工具——包括从验证者进行数据流式传输（Geyser、Yellowstone gRPC）以及用于处理历史的解决方案。整套基础设施以开源形式分发，其发展由 Solana Foundation 参与协调。
最终，Solana 实际上试图从“通用型”RPC 转向模块化且专门化的数据基础设施，据称这应当降低开发者门槛，并让与区块链数据的交互在便利性上接近传统数据库。
如果 Solana 能够把读取层标准化，这可能会巩固其作为拥有成熟应用级基础设施的网络地位，而不仅仅是高吞吐的网络。但同时，这也会加强与独立 RPC 提供方和基础设施平台的竞争：它们要么适配新的标准，要么在其基础上提供额外服务。
模块化架构消除了部分基础设施限制，但也会把这些限制转移到系统的其他层里。降低成本、简化数据访问的诉求是明确的：没有数据，DeFi、NFT、钱包、分析和合规工具都无法运作。然而，Web3 的本质似乎已经内置了“级联式复杂化”的效果：解决一个问题必然会带来新的挑战。
新的方案显然需要更复杂的基础设施外挂机制：包括索引器、存储、缓存、独立的数据管线，以及新的故障点。生态系统可能会获得多个并行的实现，而不是单一、简单的 RPC 层，并产生不兼容的优化，同时对基础设施提供方的依赖会进一步加深。在这种情况下，形式上的开放架构并不一定意味着对所有人都是真正开放且易用的访问模型。
目前我们仍处于这样的阶段：市场从“谁更擅长从网络中取数”转向“谁会先基于这些数据做出产品”。至于谁、以及为此付多少钱——可能很快就能知道。
118.37万 热度
23.23万 热度
77.03万 热度
18.68万 热度
23.79万 热度
为什么 Web3 不会读——ForkLog
再过几年，行业还在争论如何提升区块链的吞吐量。如今，许多网络已经能够处理数万笔操作，甚至有些宣称能达到数十万。然而事实表明，把数据写入区块链只是任务的一半。接下来还需要把数据找出来、进行索引、校验，并交付给应用程序。
因此，在某些地方，数据生成速度开始超过基础设施的处理能力。ForkLog 已经梳理了区块链如何因此而变化。
越快，越久
大约十年前，区块链的发展通常用所谓的可扩展性三难困境来描述。根据这一概念，网络被迫在安全性、去中心化和性能之间寻找折中。但到 2026 年，情况变得愈发清晰：即便吞吐量问题能够在一定程度上被解决，又会出现新的挑战。
区块链本身并没有用户界面。这个角色由各类应用承担。而它们又必须持续获取数据：
网络运行得越快，就需要处理越多此类数据。
在用户中存在一种常见误解：只要信息被写入区块链，就意味着可以轻松获取。实际上恰恰相反。从区块链直接在实时读取“原始”数据，这是一个缓慢、昂贵且在技术上很复杂的过程。在 Web3 生态系统中，广泛存在一个中间基础设施层，用来把钱包连接到 dapp 应用。
例如，一个钱包应用要让用户在数秒之内看到余额，它会向 RPC 提供方、索引器、分析平台、缓存服务器、专业数据库等发起请求。
整个过程如下：
实际上，大多数主流 Web3 应用都通过额外一层信息处理来运行。想象一下：如果区块链每秒处理 50 000 笔操作，而数百万钱包同时发送 RPC 请求以刷新屏幕。提供方的服务器无法承受这种负载。为了让用户获得可用数据，需要读取、索引并排序——这是一项极为复杂的计算任务。索引器和数据访问服务往往会比网络的最新状态落后几个区块，因为数据的处理、结构化与交付都需要额外时间。问题不只是“过时的基础设施”（当然，这种情况也确实存在），更是 Web2 与 Web3 的架构之间存在深层的冲突。
用户与应用与区块链的交互活跃程度和频率，几乎与熟悉的互联网、并带有即时响应的方式一样。当你刷社交媒体信息流时，应用会在每秒向服务器发起数千次请求，用来更新点赞、评论和图片。Web2 中的交易机器人每分钟可能会向交易所服务器发起数百万次轮询。Google 或 Amazon 的服务器能够轻松承受，因为它们是中心化的：数据基本都存放在一整个超大数据库中，然后可以立即复制到全球成千上万台服务器镜像上。
区块链的工作方式不同，它在硬件层面并不为此类操作做好准备。直到不久前，区块链速度的主要障碍仍是数学计算和密码学。需要让全世界成千上万台计算机快速达成一致（共识），即确认某笔交易是有效的。开发者通过“教会”机器进行并行执行，并把共识与执行拆分，从而解决了这一问题。例如 Solana、Monad 和 Aptos 支持对彼此独立的交易进行并行执行，这区别于以太坊的经典顺序模型。与此同时，Monad 尤其明确地拆分了交易顺序的协商与随后执行，而在 Solana 和 Aptos 中，并行性则通过 runtime 架构与基于状态的冲突管理来实现。
最终，你可以批准每秒数万笔交易（TPS）。但这里就存在一个陷阱。
从历史上看，区块链同时承担四项功能：
性能的提升会同时增加对这四项功能的负载。系统生成数据的速度快于基础设施读取数据的速度，从而形成所谓的 indexer gap。
在 Helius 的文档中——它是 Solana 生态系统中最大的基础设施提供方之一——明确指出，区块链的顺序结构适合保障数据完整性并提供较高的吞吐量，但会使历史查询变得缓慢且不高效。因此，大多数公司被迫在区块链之上构建自己的索引器和独立的数据库。
ChainScore Labs 的分析师将 indexer gap 称为 Solana 生态系统的关键问题之一。他们认为，传统的索引方式难以适配网络架构：高频出块与交易并行执行会制造出巨大的数据流。
于是会产生这样的效果：网络可以几乎即时地确认操作，但应用程序处理这些操作的后果需要更长得多的时间。
Web3 的速度卡在了普通的物理层面（不止如此）
更准确地说，是卡在处理器、硬盘和网络电缆的吞吐能力上。事实表明，区块链的可扩展性并不等于其周边基础设施的可扩展性。并且必须尽快解决这个问题。
假设有一个 100 000 TPS 的网络。它不仅要把交易写入，还要：
因此，高吞吐量会在共识、交易执行以及网络之上的基础设施服务之间制造资源竞争。
参与其中的部分技术并行演进，迫使我们现在就要解决这个问题。对人类来说，延迟以秒甚至分钟计可能还可以接受。对 AI 代理、交易系统和自动化服务而言则不行。如果机器基于链上数据做决策，那么过时的信息就意味着错误、失去机会，甚至直接的财务损失。
与此同时，Ethereum Foundation 在更新的 2026 年文档中指出：归档节点需要 3 到 12 TB 的磁盘空间，而即使在相当强大的设备上，初始同步也可能要花到一个月。限制因素来自 SSD 的速度、内存容量以及处理器性能。
此外，Geth 的开发者还单独描述了旧的归档存储模型：当时以太坊数据库大小可能超过 20 TB，同步要花上数月。正因如此，才不得不创建新的基于路径（path-based）的状态存储架构。
也就是说，是的，“硬件”、处理器、网络吞吐能力、CPU——这些都是在争夺信息增长时的真实物理限制。但这并不是全部。现代服务器已经能够处理巨量数据。问题在于：成千上万的网络独立参与方，为了做到这件事，需要付出多少成本？
例如，如果要在生态系统中全面参与，需要数十 TB 的 SSD、数百 GB 的 RAM、昂贵的通信链路，那么基础设施运营商的数量不可避免地会减少。于是就会出现新的中心化。
从形式上讲，处理数据是可以做到的，但无法同时做到便宜且去中心化。信息处理的成本开始增长得比交易本身的成本更快。
市场如何回应
竞赛中的参与者已经明白：最终会赢的那些网络，将能够更快、更便宜、更可靠地把交易转化为可用的信息。而就在今年，市场的关注点出现了意外转向：转向模块化区块链。
如果第一代网络试图把所有任务同时完成，那么新一代会把职责在专门化的各个层之间拆分。于是，不再只有一个网络层次，而是出现了独立的层：
开发者把这个过程类比为数据中心的演化。过去，一个服务器同时承担所有功能。今天，计算、数据存储和网络服务可以独立于彼此进行扩展。
市场增长最快的方向之一是 DA 网络。乍一看这个想法很奇怪：为什么要为另一个区块链的数据临时存储创建一个独立的区块链？但事情正是如此。在模块化架构里，交易执行和数据存储可以彼此独立。Rollup 会把数据发布到外部的 DA 层，而不是主网络。这样可以显著降低扩展成本，并提升吞吐量。
再过几年前，RPC 还被视为一个技术细节。如今，它已经成为加密基础设施中最重要的组成部分之一。到 2026 年 5 月，Triton One 联合 Solana Foundation 发布了更新的 RPC 2.0 公告——这是一种新的网络读取数据架构方式。
其核心思想在于：把对网络当前状态的访问与其历史记录分离。为此引入两个相互独立的模块：一个实时索引账户状态，另一个优化对历史数据的处理。系统不再对整个区块链进行全量扫描，而是针对具体应用请求生成自适应索引，从而降低延迟并减少处理成本。
因此，Triton 和 Solana 试图消除一系列系统性限制：昂贵且低效的 RPC 节点单体架构、JSON-RPC 标准请求的狭窄集合，以及开发者对自有或专有数据处理方案的依赖。在这种新模型下，读取可以独立于共识进行扩展，而通过使用列式存储和预排序数据，历史访问也会变得更快。
该项目依托生态系统中已落地的工具——包括从验证者进行数据流式传输（Geyser、Yellowstone gRPC）以及用于处理历史的解决方案。整套基础设施以开源形式分发，其发展由 Solana Foundation 参与协调。
最终，Solana 实际上试图从“通用型”RPC 转向模块化且专门化的数据基础设施，据称这应当降低开发者门槛，并让与区块链数据的交互在便利性上接近传统数据库。
模模块化是否真的能解决问题？
如果 Solana 能够把读取层标准化，这可能会巩固其作为拥有成熟应用级基础设施的网络地位，而不仅仅是高吞吐的网络。但同时，这也会加强与独立 RPC 提供方和基础设施平台的竞争：它们要么适配新的标准，要么在其基础上提供额外服务。
模块化架构消除了部分基础设施限制，但也会把这些限制转移到系统的其他层里。降低成本、简化数据访问的诉求是明确的：没有数据，DeFi、NFT、钱包、分析和合规工具都无法运作。然而，Web3 的本质似乎已经内置了“级联式复杂化”的效果：解决一个问题必然会带来新的挑战。
新的方案显然需要更复杂的基础设施外挂机制：包括索引器、存储、缓存、独立的数据管线，以及新的故障点。生态系统可能会获得多个并行的实现，而不是单一、简单的 RPC 层，并产生不兼容的优化，同时对基础设施提供方的依赖会进一步加深。在这种情况下，形式上的开放架构并不一定意味着对所有人都是真正开放且易用的访问模型。
目前我们仍处于这样的阶段：市场从“谁更擅长从网络中取数”转向“谁会先基于这些数据做出产品”。至于谁、以及为此付多少钱——可能很快就能知道。