数据准确性：Web3 中鲜为人知的普遍问题

一个知名的 NFT 团队因为向用户展示了相互矛盾的信息而流失了数万用户(见上例)。

一个最大的 DeFi 协议因排查前端错误的 bug 而损失了 200 万美元。由于该协议无法定位根本原因，这个问题数周都没有得到解决。

这两种情况都源于同一个问题：节点基础设施缺乏准确性，而这在 Web3 中是一个普遍存在的问题。

作为工程师、创始人、产品经理，甚至是用户，如果节点准确性还没有进入你的视野，你需要把它列为优先事项，这样你的应用才能取得成功。

一些背景信息

区块链由以点对点网络方式通信的节点运行。正是这种结构性特点实现了去中心化，这是 web3 的基本价值主张之一：不依赖中心化的中介，而是由数千个节点通过无需信任地相互传播信息来记录交易。

为了向用户提供正确且一致的结果，节点网络必须就区块链的最新状态达成一致。这在点对点网络中是极具挑战性的，因为信息不会同时到达每个节点。

这意味着当一个人与依赖节点提供数据的 dApp 交互时：

• 节点提供的数据并不总是一致的 ➡️
• 用户得到的结果并不总是他们期望的

通常情况下，当用户收到无法解释的、意外或相互矛盾的信息时，是因为他们所使用的节点之间缺乏准确性。

在 Alchemy，我们将准确性定义为用户与 dApp 交互并得到正确且一致的数据这一状态。

在本文中，我们将解释：

• 为什么准确性是一个 web3 特有的问题
• 用单个节点解决准确性问题的局限性
• 用负载均衡器解决准确性问题的局限性
• 缺乏准确性会如何给应用带来广泛问题
• Alchemy 的 Cortex 引擎如何解决区块链准确性问题

当用户与 dApp 交互并得到正确且一致的数据时，准确性才成立

在 web2 中，[中心化系统让准确性成为一个容易解决的问题](https://ethereum.org/en/developers/docs/web2-vs-web3/#:~:text=Web2 refers to the version,that run on the blockchain)，因为信息只能来自一个来源。但 web3 的分布式系统带来了大量新的、复杂的问题，包括：

• 实现复杂
• 确保信息传递到网络中最远的参与者存在困难(信息传递到网络中较远的节点确实需要更长时间)
• 网络协调方面的困难

所有这些挑战都可能导致一组节点之间缺乏准确性，进而导致：

• 提供有缺陷的体验
• 流失客户
• 花费时间和金钱去追溯修复问题

运行单个节点的问题

如果数据准确性问题源于多个节点之间的通信，你可能会决定自己运行一个单独的节点。

假设你自己运行着一个单独的节点，一个用户向你的 dApp 发起了一次调用：

• 他们请求最新区块
• 你的节点告诉他们最新区块是 4

✅ 这样是可行的！

但这里有个问题。

它只在一定程度上是可行的。

让所有流量都经过单个节点会大大限制你的应用的可扩展性和可靠性：

• 可扩展性：如果你的 dApp 今天有 100 个用户，但使用量需求增长了 10 倍，一个节点将无法有效处理增加的请求负载
• 可靠性：如果你依赖一个节点，那么当这个节点宕机时，你的 dApp 也会随之宕机。而且由于节点出了名地不可靠，只用一个节点，你的正常运行时间将远低于所需水平(我们测得的单节点正常运行时间在某些情况下低至 72%)。

你的团队花在节点维护上的时间，就是他们本可以用来为客户构建产品和体验的时间。

好，既然你已经意识到单个节点不足以满足你的业务需求，那么接下来你可能会怎么做？‍

使用负载均衡器的问题

你可能想尝试使用一个通过负载均衡器管理多个节点流量的基础设施提供商；这是 web3 中非常常见的基础设施设计。

负载均衡是一种水平扩展机制，最初应用于 web2。可以把负载均衡想象成在超市里选择最短的队伍——负载均衡器会把你的 dApp 流量引导到排队人数最少的节点。‍

看看下面这个例子。

一个用户向你的 dApp 发起了一次调用：

• 他们请求最新区块
• 通过节点 A，你的 dApp 告诉他们最新区块是 2

然后，用户再次询问以确认：

• 这次查询被路由到了节点 B
• 通过节点 B，你的 dApp 告诉他们最新区块是 4

由于该系统仍然是将每个请求路由到单个节点，而在任何给定时刻，该节点都可能没有最新信息，所以结果往往是不正确的。你的用户将会看到相互矛盾、无法解释的结果。

负载均衡比单个节点能提供更高的可扩展性和可靠性，但这是以牺牲准确性为代价的。

当流量通过负载均衡器路由时，节点之间可能对以下信息存在差异：

• 最新区块
• 最近的交易
• 待处理交易

这些问题可能导致：

• 开发者遇到不一致的数据
• 请求失败
• 应用程序故障
• 同一个用户对同一请求看到相互矛盾的结果
• 多个用户对同一请求看到相互矛盾的结果

还不相信这是个大问题？接着往下看。

缺乏准确性如何造成重大问题

假设 Isaac 想加入一个 DAO，为此他需要购买该 DAO 的代币。

• Isaac 询问一个去中心化交易所(DEX)："DAO 代币还有吗？"
• 该 DEX 的基础设施提供商将 Isaac 的请求路由到了节点 A。
• 通过节点 A，该 DEX 告诉他："是的，代币还有。"

✅ 代币还有！

Isaac 前去购买。

• 该 DEX 的基础设施提供商将 Isaac 的请求路由到了节点 B。
• 通过节点 B，该 DEX 告诉他："交易失败。"

由于该 DEX 使用的基础设施提供商是在多个节点间做负载均衡(一种非常常见的 web3 扩展机制)，当 Isaac 确认代币还有时，节点 A 返回的信息在这种情况下是过时的。

这凸显了一个关键点：在给定的时刻，来自单个节点的信息——而使用负载均衡器时信息始终来自单个节点——是不能被依赖的。

那个节点可能没有最新信息，如果正是这个节点响应了你的请求，你的交易(或后续交易)很可能会失败或出现意外行为。

准确性问题会导致各种各样的故障状态

Isaac 遇到的情况只是由节点不准确导致的众多故障状态之一。

我们再来看几个可能的故障状态：

1. 智能合约执行返回相互矛盾的答案，而本应只有一个确定的结果。例如：

• 用户问："这只 Bored Ape 的所有者是谁？"
• API 返回："Alice"
• 然后用户问："告诉我 Alice 拥有哪些 ape？"
• API 返回："Alice 一个都没有"‍

为什么会这样？在依赖负载均衡器的基础设施中，智能合约的状态，以及执行它们时发生的结果，会因处理请求的节点不同而不同。

2. dApp 返回了错误的"nonce"(任意给定钱包地址每笔交易的唯一标识符)，导致后续交易失败。例如：

• 用户用 nonce 100 完成了交易 1
• 用户问："下一个 nonce 是多少？"
• API 返回：100(这本应是不可能的，因为 nonce 100 已经完成了)
• 下一笔交易将被自动拒绝

为什么会这样？在不准确的基础设施中，待处理交易可能最终只存在于单个节点上，所以当你试图获取这些待处理交易或发送它们的钱包的状态信息时，返回的数据往往是缺失或误导性的。

这些故障状态隐蔽难察、无法解释，并会严重影响你应用的健康状况

可能发生的一些情况：

你可能会摄入不准确的数据，这会污染你的数据库，需要花费时间和精力去修复。

以Origin为例。他们最初的基础设施提供商经常出现 RPC 错误和调试问题，调试这些错误耗费了他们团队大量时间。

他们发现，一个节点回答了一个请求，但这个节点比回答另一个请求的节点落后了几个区块。

这些状态问题几乎无法排查，一旦他们确实找到了根本原因，就发现这个问题已经污染了他们的整个系统。

因为这些问题没有错误信息或失败代码，你 a) 无法在代码中提前预判，b) 在问题发生时需要花费数小时去调试；这对你的用户来说也同样令人困惑：

**用户可能会基于过时数据发送交易，而这些交易注定会失败；他们因此会损失 gas 费用：**‍

用户可能会在你的 dApp 上看到相互矛盾的界面，先后显示某笔交易成功或未成功。他们会把这个问题归咎于你的 dApp 的前端体验：

用户可能会因为以为交易没有成功上链而多付费、再次尝试；而实际上原来的交易已经上链了，只是没有被准确反映出来：

为准确性而构建

如果现在还不够清楚的话：在区块链网络中，不准确的基础设施会对你的 dApp 和用户产生非常负面的影响。

你需要与这样的基础设施提供商合作：

• 把准确性视为一项基本优先事项
• 拥有一套不同于负载均衡、可持续的系统，能够在你的 dApp 扩展时维持准确性

对节点提供商进行基准测试

我们整理了一些数据，对几家知名节点基础设施提供商的准确性进行了基准测试。你也可以用这个工具自行测试准确性。

准确性只是评估提供商的一个方面。你还可以在 Alchemy 的RPC provider benchmarks中比较当前延迟、成功率和失败请求数。

在我们的测试中，我们调用 JSON RPC 方法 eth_blockNumber 共约 1,072,000 次，以在 24 小时内从每个提供商获取最新区块号。这只是基准测试数据不准确性的一个简单例子。还有很多其他情况，往往失败得更频繁、更严重。

注 在我们的示例仪表盘截图中，我们对单日的数据准确性进行了查询和记录。

*完整的方法论细节见附录。

你可以做些什么来获得准确的数据？

为了确保你的应用和客户能获得准确性，Alchemy 投入了数十万个工程小时，开发了数百项独特的创新，打造出Alchemy 的 Cortex 引擎，它在提供多节点基础设施的可扩展性和可靠性优势的同时，确保数据准确性的一致性。

Cortex 远不止是一堆连接在一起的节点——事实上，那只是 Cortex 引擎的一小部分。Cortex 结合了自研的、可扩展的分布式系统，本质上使我们的 API 能够表现得像单个节点一样运作，从而解决了我们之前讨论的所有准确性问题。

这是如何实现的？

我们构建了一个明确的一致性层，叫做 Vox Nodi(节点之声)。Vox Nodi 的职责是保证我们所服务的任何区块链请求都返回一致的结果。

其实现方式本质上是在我们的基础设施上运行一种共识算法，基础设施的每个组成部分都可以对区块链的正确状态进行投票。

通过正确地路由和调整查询，这个系统确保了尽管不同节点在任何给定时刻对交易数据有不同的视图，返回的结果始终保持一致准确。

简而言之，Vox Nodi 保证对我们 API 的任何请求都能快速、可靠地返回，且数据 100% 准确。

而 Cortex 仍然使开发者能够无限且可靠地扩展，因为响应每个请求的不是单个节点，而是一个完整的、分布式的区块链引擎。

简而言之，它不是负载均衡器。

影响与结论

在选择如何将你的 dApp 连接到区块链时，有许多不同的维度需要考虑：提供商提供准确性的能力应该是你清单上的第一位。

在 Alchemy，准确性是首要任务。立即开始免费使用 Alchemy。

附录

基准测试方法论

在思考如何对准确性进行基准测试时，我们从第一性原理出发，测试了最基本的 Ethereum RPC 调用之一：eth_blockNumber。

简单回顾一下，eth_blockNumber 返回 Ethereum 网络的最新区块号，在去中心化网络中，区块号最大的区块包含了最新的交易。

因此，在正常的网络条件下，从单个节点/节点提供商调用 eth_blockNumber 应该只返回递增的区块号。任何不递增的不一致情况，都表明存在回滚，或者，如果发生得更频繁，则表明提供商可能存在数据不准确的问题。

请注意，这与"reorg(重组)"不同，重组是指新的最长链替换了节点上已有的数据。"重组"后的链长度总是至少等于节点上已有的数据长度，所以如果我们看到区块号倒退，就可以明确地判定这是由基础设施故障造成的。

为了理解我们如何衡量数据不一致，假设我们在总共轮询 eth_blockNumber 13 次后得到了以下区块号序列。

根据这个序列，我们发现在区块索引 6、7、9、10 和 11 处共有 5 个错误。这意味着在区块 6、7、9、10 和 11 处，返回的区块号没有遵循预期的递增顺序，证明存在某种潜在的数据准确性问题。

注：一旦我们记录到节点提供商已到达区块号 2，我们就假定之后任何返回值为 1 的情况都是错误的，相当于该提供商"时间倒流"，返回了滞后 1 个区块的_当前_区块值。同样地，一旦我们记录到节点提供商已到达区块号 3，此后任何出现的区块 1 或 2 都属于_不一致_。为了简化这项基准测试，我们明确只衡量各个提供商自身的数据准确性，而不对不同提供商之间的区块数据进行交叉比较。