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

Reviewed by Brady Werkheiser

---

上次更新时间：2024 年 2 月 15 日，阅读时长 8 分钟

04-data-accuracy-bored ape.mp4 来自 Rodney Manabat 在 Vimeo 上的作品

在 Picture-in-Picture 中播放

更多选项

赞

添加到稍后观看

分享

播放

显示控件

设置画中画全屏

在 Vimeo 上观看

质量自动

速度正常

一个知名的 NFT 团队因为向其用户展示冲突的信息而损失了成千上万的用户（上面例子）。

一个最大的 DeFi 协议因为排除那些为用户创建前端错误的 bug 而损失了 200 万美元。因为该协议无法准确找出根本原因，所以这个问题数周都未得到解决。

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

作为工程师、创始人、产品经理，甚至是用户，如果节点准确性还没有引起你的注意，那么你需要将其作为你的应用程序成功的首要任务。

一点背景

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

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

00-data-accuracy-node-overview_1.mp4 来自 Rodney Manabat 在 Vimeo 上的作品

在 Picture-in-Picture 中播放

更多选项

赞

添加到稍后观看

分享

播放

显示控件

设置画中画全屏

在 Vimeo 上观看

质量自动

速度正常

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

• 节点并不总是提供相同的数据 ➡️

• 用户不会总是得到他们期望的结果

NFT 没有及时出现在钱包中

通常，当用户收到他们无法理解的意外或冲突信息时，这是因为他们使用的节点之间缺乏准确性。

在 Alchemy，我们将准确性定义为当一个人与 dApp 交互并收到正确且一致的数据作为回报时的状态。

在本文中，我们将解释：

• 为什么准确性是 web3 特有的问题

• 使用单个节点解决准确性的局限性

• 使用负载均衡器解决准确性的局限性

• 缺乏准确性如何为应用程序带来广泛的问题

• Alchemy 的 Supernode 如何解决区块链准确性的秘诀

当一个人与 dApp 交互并收到正确且一致的数据作为回报时，准确性就存在了

在 web2 中，中心化系统使准确性成为一个容易解决的问题，因为信息只能来自一个来源。但是 web3 分布式系统会导致无数新的和复杂的问题，包括：

• 复杂的实现

• 确保信息传递到网络中最远的参与者的挑战（信息传递到网络中更远的节点确实需要更长的时间）

• 网络协调方面的挑战

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

• 提供糟糕的体验

• 失去客户

• 通过追溯修复问题来浪费时间和金钱

“你在 CryptoKitties 上能想到的每一个状态问题都发生了。如果节点不同步，用户体验和整个 dApp 都会一团糟。” - Eric Lin, Dapper

运行单个节点的问题

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

假设你正在运行你自己的单个节点，并且一个用户向你的 dApp 发出调用：

• 他们要求最新的区块

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

用户向你的 dApp 发出调用

✅ 这行得通！

但有一个陷阱。

它只能在一定程度上起作用。

通过单个节点运行流量会极大地抑制你的应用程序的可扩展性和可靠性：

• 可扩展性：如果你的 dApp 今天有 100 个用户，但使用需求使其扩展 10 倍，则一个节点将无法有效地管理增加的请求负载。

• 可靠性：如果你依赖于一个节点，那么当该节点出现故障时，你的 dApp 也会出现故障。而且由于节点通常不可靠，只有一个节点，你将获得比你需要的少得多的正常运行时间（我们已经测量到单个节点的正常运行时间在某些情况下低至 72%）。

你的团队花在节点维护上的时间就是他们无法花在为你的客户构建产品和体验上的时间。

“与 Alchemy 合作帮助我们节省了相当于三名全职工程师的工作量，否则他们将不得不一直专注于基础设施维护。”- Evgeny Yurtaev，Zerion 的 CEO 兼联合创始人

好的，所以你已经意识到一个节点不足以满足你的业务需求。那么你接下来会做什么？

使用负载均衡器的问题

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

负载均衡是一种水平扩展机制，最初在 web2 中使用。将负载均衡想象成在杂货店选择最短的队伍 - 负载均衡器会将你的 dApp 的流量引导到队列最短的节点。

01-data-accuracy-load-balancer-overview 来自 Rodney Manabat 在 Vimeo 上的作品

在 Picture-in-Picture 中播放

更多选项

赞

添加到稍后观看

分享

播放

显示控件

设置画中画全屏

在 Vimeo 上观看

质量自动

速度正常

请看下面的例子。

一个用户向你的 dApp 发出调用：

• 他们要求最新的区块

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

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

• 这次查询被路由到节点 B

• 通过节点 B，你的 dApp 告诉他们最新的区块是 4

02-data-accuracy-load-balancer 来自 Rodney Manabat 在 Vimeo 上的作品

在 Picture-in-Picture 中播放

更多选项

赞

添加到稍后观看

分享

播放

显示控件

设置画中画全屏

在 Vimeo 上观看

质量自动

速度正常

由于系统仍然通过单个节点路由每个请求，并且在任何给定时间点，该节点可能没有最新的信息，因此结果通常是不正确的。你的用户将被提供无法理解的冲突结果。

与单个节点可以维护的规模和可靠性相比，负载均衡可以创建更大的规模和可靠性，但这是以牺牲准确性为代价的。

当流量通过负载均衡器路由时，节点可能对以下信息有不同的看法：

• 最新区块

• 最近的交易

• 待处理的交易

这些问题可能意味着：

• 开发人员遇到不一致的数据

• 请求失败

• 应用程序失败

• 单个用户将看到同一请求的冲突结果

• 多个用户将看到同一请求的冲突结果

仍然不相信这是一个大问题吗？请继续阅读。

缺乏准确性如何导致重大问题

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

• Isaac 向一个去中心化交易所 (DEX) 询问：“DAO 代币还有吗？”

• DEX 的基础设施提供商将 Isaac 的请求路由到节点 A。

• 通过节点 A，DEX 告诉他：“是的，代币仍然可用。”

✅ 代币可用！

Isaac 去购买。

• DEX 的基础设施提供商将 Isaac 的请求路由到节点 B。

• 通过节点 B，DEX 告诉他：“交易失败。”

03-data-accuracy-dao-token 来自 Rodney Manabat 在 Vimeo 上的作品

在 Picture-in-Picture 中播放

更多选项

赞

添加到稍后观看

分享

播放

显示控件

设置画中画全屏

在 Vimeo 上观看

质量自动

速度正常

由于 DEX 使用的是一个跨节点进行负载均衡的基础设施提供商（一种非常常见的 web3 扩展机制），当 Isaac 确认代币仍然可用时，节点 A 返回的信息在这种情况下是过时的。

这强调了关键的一点：在给定的时间点，来自单个节点的信息（在使用负载均衡器时，信息总是来自单个节点）是不可靠的。

该节点可能没有最新的信息，如果该节点响应你的请求，你的交易（或后续交易）可能会失败或表现出意外的行为。

准确性问题会导致各种各样的失败状态

Isaac 遇到的情况是由于节点缺乏准确性而导致的众多失败状态之一。

让我们来看看更多的潜在失败状态：

1. 当应该只有一个事实结果时，智能合约执行返回冲突的答案。例如：

• 用户问：“谁拥有这只无聊猿？”

• API 返回：“Alice”

• 然后用户问：“告诉我 Alice 拥有哪些猿？”

• API 返回：“Alice 不拥有任何猿”

04-data-accuracy-bored ape.mp4 来自 Rodney Manabat 在 Vimeo 上的作品

在 Picture-in-Picture 中播放

更多选项

赞

添加到稍后观看

分享

播放

显示控件

设置画中画全屏

在 Vimeo 上观看

质量自动

速度正常

为什么会发生这种情况？对于依赖负载均衡器的基础设施，智能合约的状态，以及你执行它们时发生的情况，将取决于哪个节点处理该请求。

2. dApp 返回一个不正确的 "nonce"（每个来自任何给定钱包地址的单独交易的唯一标识符），导致后续交易失败。例如：

• 用户完成 nonce 为 100 的交易 1

• 用户问：“下一个 nonce 是什么？”

• API 返回：100（这应该是不可能的，因为 nonce 100 已经完成）

• 下一个交易将被自动拒绝

05-data-accuracy-nonce 来自 Rodney Manabat 在 Vimeo 上的作品

在 Picture-in-Picture 中播放

更多选项

赞

添加到稍后观看

分享

播放

显示控件

设置画中画全屏

在 Vimeo 上观看

质量自动

速度正常

为什么会发生这种情况？使用不准确的基础设施，待处理的交易最终可能只存在于单个节点上，因此当你尝试获取有关这些待处理交易的状态或发送它们的钱包的信息时，通常会返回丢失或误导性的数据。

这些失败状态是隐蔽的，无法理解，并且会严重影响你的应用程序的健康

可能会发生一些事情：

你可能会摄入不准确的数据，这些数据会破坏你的数据库，需要花费时间和精力来修复。

以 Origin 为例。RPC 错误和调试在他们的第一个基础设施提供商中很普遍，并且调试这些错误对他们的团队来说很耗时。

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

这些状态问题几乎不可能进行故障排除，一旦他们确定了根本原因，他们发现该问题已经损坏了他们的整个系统。

由于这些问题没有错误消息或失败代码，所以你 a) 无法在你的代码中主动考虑它们，并且 b) 会花费数小时来调试它们，这对于你的用户来说同样令人困惑：

从 Bakery swap 转移 NFT 时出错

用户可能会根据过时的数据发送交易，因此保证会失败；他们将因此损失 gas 费：

缺少 NFT

用户可能会在你的 dApp 上看到冲突的 UI，连续反映交易成功或不成功。他们会将此失败归因于你的 dApp 的前端体验：

NFT 在 4 小时后未显示在用户钱包中

用户可能会多付钱，因为他们认为交易没有成功开采，然后再次尝试；实际上，最初的交易确实通过了，但没有准确反映出来：

用户为失败的交易支付两次 gas 费

构建准确性

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

你需要与一个基础设施提供商合作，该提供商：

• 将准确性视为一个根本优先事项

• 拥有一个可持续的系统，不同于负载均衡，可以在你的 dApp 扩展时保持准确性

节点提供商的基准测试

我们已经编制了基准测试一些知名节点基础设施提供商的准确性的数据。也使用这个工具亲自测试准确性

在我们的测试中，我们总共查询 JSON RPC 方法 eth_blockNumber 约 1,072,000 次，以获取每个提供商在 24 小时内的最新区块号。这是一个用于基准测试数据不准确性的简单示例。还有许多其他示例往往会更频繁地失败，并且会造成更大的灾难。

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

注意：在我们的示例仪表板快照中，我们查询并记录单日的数据准确性。

*完整的方法细节在附录中。

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

“Alchemy 解决了之前出现的一致性问题，消除了 98% 的用户投诉，并显着改善了 Augur 的用户体验和采用。”-Augur CTO Alex Chapman

为了确保你的 dApp 和客户的准确性，Alchemy 投入了数十万个工程小时，并开发了数百项独特的创新，以创建 Alchemy Supernode，这是确保一致数据准确性的基本产品，具有多节点基础设施的可扩展性和可靠性优势。

Supernode 远不止是一堆连接的节点 - 事实上，这只是 Supernode 系统的一小部分。Supernode 是定制的、可扩展的和分布式系统的组合，这些系统本质上允许我们的 API 充当单个节点，从而解决了我们讨论的所有准确性问题。

这是如何工作的？

supernode-export-v4 来自 Rodney Manabat 在 Vimeo 上的作品

在 Picture-in-Picture 中播放

更多选项

赞

添加到稍后观看

分享

播放

显示控件

设置画中画全屏

在 Vimeo 上观看

质量自动

速度正常

我们已经构建了一个显式的一致性层，名为 Vox Nodi（节点之声）。Vox Nodi 的职责是保证我们正在帮助提供的任何区块链请求都将返回一致的结果。

它的工作原理本质上是在我们的基础设施上运行一个共识算法，其中基础设施的每个部分都可以对区块链的正确状态进行投票。

通过正确地路由和调整查询，该系统确保尽管各个节点在任何给定时间对交易数据都有不同的看法，但结果始终保持一致的准确。

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

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

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

影响与结论

在选择如何将你的 dApp 连接到区块链时，需要考虑许多不同的维度：提供商提供准确性的能力应该是你列表中的首要任务。

在 Alchemy，准确性是重中之重。立即免费开始使用 Alchemy。

-

附录

基准测试方法

在考虑准确性基准测试时，我们从第一性原理开始，并测试了最基本的以太坊 RPC 调用之一：eth_blockNumber。

作为复习，eth_blockNumber 返回以太坊网络的最新区块号，并且在去中心化网络中，区块号最高的区块包含最新的交易。

因此，在正常的网络条件下，从单个节点/节点提供商调用 eth_blockNumber 应该只返回升序的区块号。任何升序数据的不一致都表明存在回滚，或者当它更频繁地发生时，表明存在潜在的提供商数据不准确性。

请注意，这与“重组”不同，在“重组”中，一条新的最长链会替换节点上的现有数据。“重组”将始终具有至少与节点上已有数据一样多的区块，因此如果我们看到区块号向后退，我们可以明确地说这是由损坏的基础设施引起的。

为了理解我们如何衡量未对齐的数据，让我们假设在总共轮询 13 次 eth_blockNumber 后，我们有以下区块号序列。

我们如何衡量未对齐的数据

给定此序列，我们发现总共有 5 个错误，分别位于区块索引 6、7、9、10 和 11 处。这意味着在区块 6、7、9、10 和 11 处，返回的区块没有遵循预期的升序排列，证明存在一些潜在的数据准确性问题。

注意：一旦我们记录节点提供商位于区块号 2 上，我们假设随后的任何值 1 都是不正确的，并且等同于提供商时间旅行并提供当前区块值，该值晚了 1 个区块。类似地，一旦我们记录节点提供商位于区块号 3 上，则现在_未对齐_的是显示的所有实例区块 1 或 2。为了简化此基准测试，我们明确地衡量来自各个提供商本身的数据准确性，而不比较不同提供商之间的区块数据。

Supercharged | Alchemy | Substack

使用 Alchemy 的基础设施免费开始构建 web3 dApp 获取你的 API 密钥

📚 目录

---

• 一点背景
• 当一个人与 dApp 交互并收到正确且一致的数据作为回报时，准确性就存在了
• 运行单个节点的问题
• 使用负载均衡器的问题
• 缺乏准确性如何导致重大问题
• 构建准确性
• 影响与结论
• 附录

分享：

• 原文链接： alchemy.com/blog/data-ac...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～