加密公地悲剧系列：Polymarket 的数据索引之殇

撰文：shew

摘要

欢迎来到 GCC Research 专栏的「加密公地悲剧」系列。

在这个系列中，我们将聚焦那些加密世界中处于关键节点却逐渐失范的「公共物品」。它们是整个生态的基础设施，但往往面临激励不足、治理失衡、甚至逐渐中心化的困境。加密技术所追求的理想和现实中的冗余稳定性，正在这些角落里经历严峻的考验。

本期，我们聚焦以太坊生态中最为「出圈」的应用之一：Polymarket 及其数据索引工具。尤其是今年以来，围绕特朗普胜选、乌克兰稀土交易的预言机操控、泽连斯基西服颜色的政治赌注等事件，使得 Polymarket 多次成为舆论焦点，它所承载的资金规模和市场影响力更是让这些争议变得不容忽视。

然而，这个代表「去中心化预测市场」的产品，它的关键基础模块——数据索引，真的实现了去中心化吗？为什么像 The Graph 这样的公共基础设施未能承担起预期的角色？一个真正可用、可持续的数据索引公共物品，又应具备怎样的形态？

一、一个中心化数据平台宕机引发的连锁反应

2024 年 7 月，Goldsky 发生了长达六小时的宕机事故（ Goldsky 是一家面向 Web3 开发者的实时区块链数据基础设施平台，提供索引、子图与流式数据服务，帮助快速构建数据驱动的去中心化应用），导致以太坊生态系统的很大一部分项目陷入瘫痪，比如 DeFi 前端无法显示用户的仓位以及余额数据，预测市场 Polymarket 无法显示正确的数据，无数项目在前端用户看来似乎已经完全无法使用。

这在去中心化应用的世界里本不应该发生。毕竟，区块链技术的设计的最初目的不就是消除单点故障吗？Goldsky 事件暴露了一个令人不安的事实：虽然区块链本身已经尽可能实现了去中心化的，但是构建在链上的应用使用的基础设施往往包含了大量的中心化服务。

究其原因，区块链数据索引与检索属于「非排他、非竞争性」的数字公共产品，使用者往往期望免费或极低费率，但其背后却需要持续投入高强度的硬件、存储、带宽与运维人力。缺乏可持续盈利模式时，就会出现赢家通吃的集中化格局：只要一家服务商在速度和资本上取得先发优势，开发者便倾向把所有查询流量导向该服务，从而重新形成单点依赖。Gitcoin 等公益项目已反复强调，「开源基础设施能创造数十亿美元价值，但作者却往往无法靠它偿还房贷」 。

这警醒我们，去中心化世界迫切需要通过公共产品资助、再分配或社区驱动的举措来丰富 Web3 基础设施的多样性，否则会出现中心化的问题。我们呼吁 DApp 开发者构建本地优先的产品，也呼吁技术社区在 DApp 设计时考虑数据检索服务失效的情况，保证用户在无数据检索基础设施的情况下仍可以与项目交互。

二、你在 Dapp 看到的数据，是从哪儿来的

要理解为什么会发生 Goldsky 这样的事件，我们需要深入了解 DApp 在幕后的工作机制。对普通用户而言，DApp 通常只由两部分构成：链上合约和前端页面。大部分用户已经习惯使用 Etherscan 等工具查找链上交易状态，并在前端获取必要信息，同时使用前端发起交易与合约交互。但这些在用户前端显示的数据究竟从何而来？

不可或缺的数据检索服务

假设读者正在构建一个借贷协议，该协议需要显示用户的持仓情况以及每个仓位的保证金和债务状况。一个朴素的想法是前端直接从链上读取这些数据。但在实践中，借贷协议的合约不允许使用户地址查询仓位数据，合约会提供使用仓位 ID 查询仓位的具体数据的函数。所以假如我们要在前端显示用户的仓位情况，那么我们需要把当前系统内所有的仓位都检索出来，然后查找那些仓位属于当前用户。这就像要求某人手动搜索数百万页账本来查找特定信息——技术上可行，但极其缓慢且低效。事实上，前端是很难完成这一检索流程的，大型 DeFi 项目的检索即使在服务器上直接依靠本地节点执行数据检索任务往往也需要长达数小时的时间。

因此，我们必须引入基础设施来加速数据获取。Goldsky 等公司正是向用户提供这些数据索引服务。下图展示了数据索引服务可以为应用提供的数据类型。

在此处，可能有读者好奇以太坊生态内似乎存在一个去中心化的数据检索平台 TheGraph，该平台与 Goldsky 有哪些联系？以及为什么大量的 DeFi 项目没有使用更加去中心化的 TheGraph 而是使用 Goldsky 作为数据提供商？

TheGraph / Goldsky 与 SubGraph 的关系

要回答上述问题，我们需要先了解一些技术概念。

1. SubGraph 是一个开发框架，开发者可以使用该框架编写代码来读取并汇总链上数据，并且使用某些方法将这些数据读取并显示到前端。

2. TheGraph是较早的去中心化数据检索平台，该平台开发了使用 AssemblyScript 编写的 SubGraph 框架，开发者可以使用 subgraph 框架编写程序来捕获合约事件并将这些合约事件写入到数据库中，之后用户可以利用 Graphql 方法读取这些数据或者直接利用 SQL 代码读取数据库。

3. 我们一般将运行 SubGraph 的服务提供商称为 SubGraph 运营商。 TheGraph 和 Goldsky 实际上都是 SubGraph 的托管商。因为 SubGraph 只是一个开发框架，该框架开发出的程序需要在服务器内运行。我们可以看到 Goldsky 文档内存在以下内容:

这里可能有读者好奇为什么 SubGraph 存在多个运营商？

这是因为 SubGraph 框架其实只是约定了数据的如何从区块内读取和写入数据库。

对于数据如何流入 SubGraph 程序以及最终的输出结果写入到哪种数据库其实都没有进行实现，这些内容需要 SubGraph 运营商自己实现。

一般来说，SubGraph 运营商都会进行节点修改等实现更快的速度，不同的运营商（如 TheGraph，Goldsky ）存在不同的策略和技术方案。

TheGraph 目前使用了 Firehouse 技术方案，该技术方案引入后，TheGraph 可以实现比过去更加快速的数据检索，而 Goldsky 并没有对外开源公开其 SubGraph 运行的核心程序。

正如上文所述，TheGraph 是一个去中心化的数据检索平台，以 Unisawp v3 subgraph为例，我们可以看到存在大量的运营商为 Uniswap v3 提供数据检索，为次我们也可以将 TheGraph 视为一个 SubGraph 运营商的集成平台，用户可以将自己编写的 SubGraph 代码发送给 TheGraph，然后 TheGraph 内部存在一些运营商可以帮助用户检索数据。

Goldsky 的收费模式

对于 Goldsky 这种集中化平台而言，Goldsky 存在一个简单的计费标准，基于使用资源的计费，这是互联网中最常见的 SaaS 平台的计费方式，大部份技术人员对对在这种方式十分熟悉。下图展示了 Goldsky 的价格计算器:

TheGraph 的收费模式

TheGraph 则有一套完全与常规计费方式不同的费用方案，这套费用方案与 GRT 的代币经济学有关，下图展示了 GRT 的整体代币经济学：

1. 每当 DApp 或钱包向某个 Subgraph 发起请求，所付的 Query Fee 会被自动拆分：1 % 烧毁、约 10 % 流入该 Subgraph 的策展池（Curator / 开发者），其余≈ 89 % 按指数返利机制打给提供算力的 Indexer 及其 Delegator。

2. Indexer 要先自质押≥ 100 k GRT 才能上线；若返回错误数据将被惩罚（slashing）。Delegator 把 GRT 委托给 Indexer，按比例分得上述 89 % 的大头。

3. Curator（通常就是开发者）通过 Signal 在自家 Subgraph 的债券曲线上质押 GRT；Signal 数越高，越能吸引 Indexer 分配资源。社区经验建议自筹 5 k–10 k GRT 可保证数个 Indexer 接单。与此同时，策展人还能拿到那 10 % Royalty。

TheGraph 的按次查询费：

在 TheGraph 后台内注册 API KEY，并使用该 API KEY 请求 TheGraph 内运营商检索的数据，这部分请求是按照请求次数收费，开发者需要预先在平台内存入一部分 GRT 代币作为 API 请求的开销。

TheGraph 的 Signal 质押费：

对于 SubGraph 的部署者，需要 TheGraph 平台内的运营商帮助检索数据，按照上面提到的收益分配方式，需要告诉其他参与者我的查询服务更好，可以分到更多钱，就需要质押 GRT，类似于打广告以及给自己担保有收益，大家才会来。

测试的时候，开发者可以免费将 SubGraph 部署到 TheGraph 平台，此时 TheGraph 官方会帮助用户进行一些检索，提供一个用于测试的免费额度，并无法用于生产环境。如果开发者认为 SubGraph 在 TheGraph 官方的测试环境内运行良好，就可以将其发布到公开网络内等待其他运营商参与检索。开发者不能直接向某一个运营商付费，并获得检索的保障，而是让多个运营商竞相提供服务，避免形成单点依赖这。这个过程需要使用 GRT 代币对自己的 SubGraph 进行策展 (Curating) 操作（也可以被称为 Signal 操作），也就是开发者向自己部署的 SubGraph 内质押一定数量的 GRT，但质押的 GRT 数量到达一定量级（此前咨询的数据是 10000 GRT) 时，运营商才加入 SubGraph 的检索工作。

糟糕收费体验，难倒开发者和传统会计

对于大部份的项目开发者而言，使用 TheGraph 其实是一件相对麻烦的事情，购买 GRT 代币对于 Web3 项目而言还算容易，但是对已部署的 SubGraph 进行 Curating 操作等待运营商的过程就是相当低效的环节。这一环节至少存在以下两个问题:

1. 质押 GRT 数量和吸引运营商所需时间的不确定性问题。笔者在过去部署 SubGraph 时直接咨询了 TheGraph 的社区大使确定了质押 GRT 的数量，但是对于大部份开发者而言，这一数据并不好获得，另外质押充足的 GRT 后，运营商介入检索也需要一段时间

2. 成本核算和会计的复杂性问题。由于 TheGraph 使用代币经济学机制设计收费标准，这对大部分开发者而言使成本计算变得复杂。更实际的问题是，如果企业要对该笔支出进行会计核算，会计可能也无法理解这部分成本构成。

「赞的，还是中心化的好？」

显然，对于大部份开发者而言，直接选择 Goldsky 是更加简单的事情，计费方式所有人都可以理解，同时只要付费几乎可以立即可用，不确定性大幅度降低，这也导致了区块链数据索引与检索服务上，出现了依赖于单一产品的情况。

显然 TheGraph 复杂的 GRT 代币经济学影响了 TheGraph 的广泛应用。代币经济学可以具有复杂性，但是显然这些复杂性并不应该暴露给用户，比如 GRT 的策展质押机制就不应该暴露给用户，TheGraph 更好的手段是直接给用户一个简化的付费页面。

上述对 TheGraph 的贬低并不是我个人的观点，知名智能合约工程师与 Sablier 项目创始人 Paul Razvan Berg 也曾在推文 内表达这一观点。该推文提到发布 SubGraph 和 GRT 计费的用户体验是极其糟糕的。

三、一些现存的解决方案

对于数据检索单点故障如何解决，上文内其实已经提到了一点，即开发者可以考虑使用 TheGraph 服务，只是流程会较为复杂，开发者需要买入 GRT 代币进行质押策展和支付 API 费用。

目前，EVM 生态内存在大量数据检索软件，具体可以参考 Dune 编写的The State of EVM Indexing 或 rindexer 编写的EVM 数据检索软件汇总，另一个较新的讨论可以参考此推文。

此文并不会讨论 Glodsky 的产生问题的具体原因，因为目前根据 Glodsky 报告 内的内容，Glodsky 知道具体的原因，但是只准备向企业级用户披露具体原因。这意味任何第三方都无法在目前知道 Glodsky 到底发生何种故障。根据其报告内容可以推测，可能是检索后的数据写入数据库时出现了问题，在这份 简要报告内，Glodsky 提及数据库无法正常访问，在与 AWS 合作后才获得了数据库的访问权。

在本节中，我们主要介绍其他的解决方法:

1. ponder 是一个简单、开发体验较好且部署简便的数据检索服务软件，开发者可以自行租用服务器部署

2. local-first 是一个有趣的开发理念，该理念呼吁开发者即使在缺失网络的情况下仍可为用户提供良好体验。在存在区块链的情况下，我们可以在某种程度上放宽 local-first 的限制，保证用户在可以连接区块链时就可以获得良好体验。

ponder

此处笔者为什么推荐使用 ponder 而不是其他软件？具体原因包含以下几点:

1. Ponder 没有供应商依赖。最初 ponder 是个人开发者构建的项目，所以相比于其他企业提供的数据检索软件，ponder 只需要用户填入以太坊 RPC URL 和 postgres 数据库链接即可

2. Ponder 提供良好的开发体验，笔者在过去曾多次使用 ponder 进行开发，由于 ponder 是由 typescript 编写，同时核心库主要依赖 viem，开发体验非常优秀

3. Ponder 具有更高的性能

当然也会存在一些问题，ponder 目前其实仍处于快速开发时期，开发者可能会遇到由于版本破坏性更新导致之前项目无法运行的情况。考虑到本文并不是一篇技术入门文章，所以本文不会进一步讨论 ponder 的开发细节，具有技术背景的读者可以自行阅读文档。

ponder 更有趣的细节是目前 ponder 也开始了部分商业化，但是 ponder 的商业化途径与非常契合上一篇文章内讨论的「隔离理论」。

在此处，我们简单介绍「隔离理论」。我们认为公共物品的公共性使其可以服务任意多用户，所以只要对公共物品收费就会导致部分用户不再使用公共物品，此时社会利益并不是最大化的 ( 经济学术语描述为「不再是帕累托最优」)。理论上，公共物品可以对每一个人进行区别定价来征收费用，但是区别定价所花费的成本极有可能大于区别定价带来的盈余。所以公共物品免费开放的原因是并不是公共物品应该是天然免费，而是任何征收固定费用的行为都会导致社会利益受损，并且目前没有一种廉价的方法可以对每一个人进行区别定价。隔离理论提出了一种可以在公共物品内定价的方法，即通过某一种方法将一部份同质人群隔离出来，对这部分同质人群征收费用。首先，隔离理论不会阻挡所有人对公共物品的免费享用，但是隔离理论提出了一种方法对部分人群征收费用。

ponder 就是用了类似隔离理论的方法：

1. 首先，ponder 的部署仍需要一定的知识，开发者在部署过程中需要提供 RPC 、数据库等外部依赖。

2. 同时在部署完成后，开发者需要持续运维 ponder 应用，比如使用 proxy 系统进行负载均衡避免数据请求影响 ponder 在后台线程内检索链上数据。这些对于一般的开发者来说都稍有复杂。

3. 目前 ponder 在内测全自动部署服务marble，用户只需要将代码交付给该平台就可以实现自动部署。

显然这是一种对「隔离理论」的应用，这些不愿意自己运维 ponder 服务的开发者被隔离出来，这些开发者可以通过付费获得 ponder 服务的简化部署。当然，marble 平台的出现也没有影响其他开发者免费使用 ponder 框架并且自托管部署。

ponder 和 Goldsky 的受众？

1. ponder 这种完全没有供应商依赖的公共物品比其他依赖供应商的数据检索服务在开发小型项目时更加流行。

2. 某些运营有大型项目的开发者并不一定选择 ponder 框架，因为大型项目往往要求检索服务具有充分的性能，Goldsky 等服务提供商往往提供了充分的可用性保障。

两者都存在一些风险点，从最近的 Goldsky 事件来看，开发者最好自行维护一套自己的 ponder 服务，以随时应对可能的第三方服务宕机。以及使用 ponder 时可能要考虑 RPC 返回数据的有效性问题，不久前 safe 就报告了一次因为 RPC 返回错误数据导致检索器崩溃的情况。虽然没有直接证据表明 Goldsky 事件也与 RPC 返回无效事件有关，但笔者怀疑 Goldsky 可能也遇到了类似事件。

local-first 开发理念

Local-first 是过去几年一直被人讨论的话题。简单来说，Local-first 要求软件具有以下功能:

1. 离线工作

2. 跨客户端协同

目前大部份与 local-first 相关的技术讨论都会涉及到 CRDT(Conflict-free Replicated Data Type) 技术，所谓 CRDT 是一种无冲突的数据格式，该格式允许用户在多端操作时自动合并冲突以保持数据的完整性。一种简单的看法是可以将 CRDT 视为一种带有简单共识协议的数据类型，在分布式情况下，CRDT 可以保证数据的完整性和一致性。

但在区块链开发中，我们可以放宽上述 Local-first 对软件要求的限制。我们仅要求在没有项目开发者提供的后端索引数据时，用户在前端仍可以保持最低限度的可用性。同时，local-first 对跨客户端协同的要求实际上已经由区块链解决了。

在 DApp 的场景下，local-first 理念可以这样实现：

1. 缓存关键数据：前端应该缓存用户的重要数据，如余额、持仓信息等，即使索引服务不可用，用户仍能看到最后已知的状态。

2. 降级功能设计：当后端索引服务不可用时，DApp 可以提供基础功能，比如在数据检索服务不可用时，部分数据可以考虑直接利用 RPC 读取链上数据，可以保证用户看到已有部分数据的最新情况

这种 local-first 的 DApp 设计理念能够显著提高应用的韧性，避免在数据检索服务崩溃后的应用无法使用。在不考虑易用性的情况下，最好的 local-first 应用应该是要求用户在本地运行节点，然后使用类似 trueblocks 的工具在本地检索数据。关于去中心化检索或本地检索的一些讨论，可以参考推文Literally no one cares about decentralized frontends and indexers。

四、写在最后

Goldsky 六小时宕机事件为生态敲响了警钟。虽然区块链本身具有去中心化和抗单点故障的特性，但构建在其上的应用生态系统仍然高度依赖中心化的基础设施服务。这种依赖为整个生态系统带来了系统性风险。

本文简单介绍了早有盛名的去中心化检索服务 TheGraph 为什么在如今并没有被广泛使用，特别讨论了 GRT 代币经济学带来的一些复杂性。最后，本文讨论了如何构建更加健壮的数据检索基础设施，笔者鼓励开发者使用 ponder 自托管的数据检索开发框架作为应急响应选项，同时也介绍 ponder 良好的商业化路径。最后，本文讨论 local-first 的开发理念，鼓励开发者构建在无数据检索服务下仍可使用的应用。

从目前来看，不少 Web3 的开发者都意识 到了数据检索服务的单点故障问题，GCC 希望更多开发者关注这一基础设施，并尝试构建去中心化的数据检索服务或者设计一套框架使得 DApp 前端在无数据检索服务的情况仍可运行。