作者：shew
摘要欢迎来到GCCResearch专栏的“加密公地悲剧”系列。
在这个系列中，我们将聚焦那些加密世界中处于关键节点却逐渐失范的“公共物品”。它们是整个生态的基础设施，但往往面临激励不足、治理失衡、甚至逐渐中心化的困境。加密技术所追求的理想和现实中的冗余稳定性，正在这些角落里经历严峻的考验。
本期，我们聚焦以太坊生态中最为“出圈”的应用之一：Polymarket及其数据索引工具。尤其是今年以来，围绕特朗普胜选、乌克兰稀土交易的预言机操控、泽连斯基西服颜色的政治赌注等事件，使得Polymarket多次成为舆论焦点，它所承载的资金规模和市场影响力更是让这些争议变得不容忽视。
然而，这个代表“去中心化预测市场”的产品，它的关键基础模块——数据索引，真的实现了去中心化吗？为什么像TheGraph这样的公共基础设施未能承担起预期的角色？一个真正可用、可持续的数据索引公共物品，又应具备怎样的形态？
一、一个中心化数据平台宕机引发的连锁反应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的关系要回答上述问题，我们需要先了解一些技术概念。
SubGraph是一个开发框架，开发者可以使用该框架编写代码来读取并汇总链上数据，并且使用某些方法将这些数据读取并显示到前端。TheGraph是较早的去中心化数据检索平台，该平台开发了使用AssemblyScript编写的SubGraph框架，开发者可以使用subgraph框架编写程序来捕获合约事件并将这些合约事件写入到数据库中，之后用户可以利用Graphql方法读取这些数据或者直接利用SQL代码读取数据库。我们一般将运行SubGraph的服务提供商称为SubGraph运营商。TheGraph和Goldsky实际上都是SubGraph的托管商。因为SubGraph只是一个开发框架，该框架开发出的程序需要在服务器内运行。我们可以看到Goldsky文档内存在以下内容:这里可能有读者好奇为什么SubGraph存在多个运营商？
这是因为SubGraph框架其实只是约定了数据的如何从区块内读取和写入数据库。
对于数据如何流入SubGraph程序以及最终的输出结果写入到哪种数据库其实都没有进行实现，这些内容需要SubGraph运营商自己实现。
一般来说，SubGraph运营商都会进行节点修改等实现更快的速度，不同的运营商（如TheGraph，Goldsky）存在不同的策略和技术方案。
TheGraph目前使用了Firehouse技术方案，该技术方案引入后，TheGraph可以实现比过去更加快速的数据检索，而Goldsky并没有对外开源公开其SubGraph运行的核心程序。
正如上文所述，TheGraph是一个去中心化的数据检索平台，以Unisawpv3subgraph为例，我们可以看到存在大量的运营商为Uniswapv3提供数据检索，为次我们也可以将TheGraph视为一个SubGraph运营商的集成平台，用户可以将自己编写的SubGraph代码发送给TheGraph，然后TheGraph内部存在一些运营商可以帮助用户检索数据。
Goldsky的收费模式对于Goldsky这种集中化平台而言，Goldsky存在一个简单的计费标准，基于使用资源的计费，这是互联网中最常见的SaaS平台的计费方式，大部分技术人员对对在这种方式十分熟悉。下图展示了Goldsky的价格计算器:
TheGraph的收费模式TheGraph则有一套完全与常规计费方式不同的费用方案，这套费用方案与GRT的代币经济学有关，下图展示了GRT的整体代币经济学：
每当DApp或钱包向某个Subgraph发起请求，所付的QueryFee会被自动拆分：1%烧毁、约10%流入该Subgraph的策展池（Curator/开发者），其余≈89%按指数返利机制打给提供算力的Indexer及其Delegator。Indexer要先自质押≥100kGRT才能上线；若返回错误数据将被惩罚（slashing）。Delegator把GRT委托给Indexer，按比例分得上述89%的大头。Curator（通常就是开发者）通过Signal在自家Subgraph的债券曲线上质押GRT；Signal数越高，越能吸引Indexer分配资源。社区经验建议自筹5k–10kGRT可保证数个Indexer接单。与此同时，策展人还能拿到那10%Royalty。TheGraph的按次查询费：
在TheGraph后台内注册APIKEY，并使用该APIKEY请求TheGraph内运营商检索的数据，这部分请求是按照请求次数收费，开发者需要预先在平台内存入一部分GRT代币作为API请求的开销。
TheGraph的Signal质押费：
对于SubGraph的部署者，需要TheGraph平台内的运营商帮助检索数据，按照上面提到的收益分配方式，需要告诉其他参与者我的查询服务更好，可以分到更多钱，就需要质押GRT，类似于打广告以及给自己担保有收益，大家才会来。
测试的时候，开发者可以免费将SubGraph部署到TheGraph平台，此时TheGraph官方会帮助用户进行一些检索，提供一个用于测试的免费额度，并无法用于生产环境。如果开发者认为SubGraph在TheGraph官方的测试环境内运行良好，就可以将其发布到公开网络内等待其他运营商参与检索。开发者不能直接向某一个运营商付费，并获得检索的保障，而是让多个运营商竞相提供服务，避免形成单点依赖这。这个过程需要使用GRT代币对自己的SubGraph进行策展(Curating)操作（也可以被称为Signal操作），也就是开发者向自己部署的SubGraph内质押一定数量的GRT，但质押的GRT数量到达一定量级（此前咨询的数据是10000GRT)时，运营商才加入SubGraph的检索工作。
糟糕收费体验，难倒开发者和传统会计对于大部分的项目开发者而言，使用TheGraph其实是一件相对麻烦的事情，购买GRT代币对于Web3项目而言还算容易，但是对已部署的SubGraph进行Curating操作等待运营商的过程就是相当低效的环节。这一环节至少存在以下两个问题:
质押GRT数量和吸引运营商所需时间的不确定性问题。笔者在过去部署SubGraph时直接咨询了TheGraph的社区大使确定了质押GRT的数量，但是对于大部分开发者而言，这一数据并不好获得，另外质押充足的GRT后，运营商介入检索也需要一段时间成本核算和会计的复杂性问题。由于TheGraph使用代币经济学机制设计收费标准，这对大部分开发者而言使成本计算变得复杂。更实际的问题是，如果企业要对该笔支出进行会计核算，会计可能也无法理解这部分成本构成。“赞的，还是中心化的好？”显然，对于大部分开发者而言，直接选择Goldsky是更加简单的事情，计费方式所有人都可以理解，同时只要付费几乎可以立即可用，不确定性大幅度降低，这也导致了区块链数据索引与检索服务上，出现了依赖于单一产品的情况。
显然TheGraph复杂的GRT代币经济学影响了TheGraph的广泛应用。代币经济学可以具有复杂性，但是显然这些复杂性并不应该暴露给用户，比如GRT的策展质押机制就不应该暴露给用户，TheGraph更好的手段是直接给用户一个简化的付费页面。
上述对TheGraph的贬低并不是我个人的观点，知名智能合约工程师与Sablier项目创始人PaulRazvanBerg也曾在推文内表达这一观点。该推文提到发布SubGraph和GRT计费的用户体验是极其糟糕的。
三、一些现存的解决方案对于数据检索单点故障如何解决，上文内其实已经提到了一点，即开发者可以考虑使用TheGraph服务，只是流程会较为复杂，开发者需要买入GRT代币进行质押策展和支付API费用。
目前，EVM生态内存在大量数据检索软件，具体可以参考Dune编写的TheStateofEVMIndexing或rindexer编写的EVM数据检索软件汇总，另一个较新的讨论可以参考此推文。
此文并不会讨论Glodsky的产生问题的具体原因，因为目前根据Glodsky报告内的内容，Glodsky知道具体的原因，但是只准备向企业级用户披露具体原因。这意味任何第三方都无法在目前知道Glodsky到底发生何种故障。根据其报告内容可以推测，可能是检索后的数据写入数据库时出现了问题，在这份简要报告内，Glodsky提及数据库无法正常访问，在与AWS合作后才获得了数据库的访问权。
在本节中，我们主要介绍其他的解决方法:
ponder是一个简单、开发体验较好且部署简便的数据检索服务软件，开发者可以自行租用服务器部署local-first是一个有趣的开发理念，该理念呼吁开发者即使在缺失网络的情况下仍可为用户提供良好体验。在存在区块链的情况下，我们可以在某种程度上放宽local-first的限制，保证用户在可以连接区块链时就可以获得良好体验。ponder此处笔者为什么推荐使用ponder而不是其他软件？具体原因包含以下几点:
Ponder没有供应商依赖。最初ponder是个人开发者构建的项目，所以相比于其他企业提供的数据检索软件，ponder只需要用户填入以太坊RPCURL和postgres数据库链接即可Ponder提供良好的开发体验，笔者在过去曾多次使用ponder进行开发，由于ponder是由typescript编写，同时核心库主要依赖viem，开发体验非常优秀Ponder具有更高的性能当然也会存在一些问题，ponder目前其实仍处于快速开发时期，开发者可能会遇到由于版本破坏性更新导致之前项目无法运行的情况。考虑到本文并不是一篇技术入门文章，所以本文不会进一步讨论ponder的开发细节，具有技术背景的读者可以自行阅读文档。
ponder更有趣的细节是目前ponder也开始了部分商业化，但是ponder的商业化途径与非常契合上一篇文章内讨论的“隔离理论”。
在此处，我们简单介绍“隔离理论”。我们认为公共物品的公共性使其可以服务任意多用户，所以只要对公共物品收费就会导致部分用户不再使用公共物品，此时社会利益并不是最大化的(经济学术语描述为“不再是帕累托最优”)。理论上，公共物品可以对每一个人进行区别定价来征收费用，但是区别定价所花费的成本极有可能大于区别定价带来的盈余。所以公共物品免费开放的原因是并不是公共物品应该是天然免费，而是任何征收固定费用的行为都会导致社会利益受损，并且目前没有一种廉价的方法可以对每一个人进行区别定价。隔离理论提出了一种可以在公共物品内定价的方法，即通过某一种方法将一部分同质人群隔离出来，对这部分同质人群征收费用。首先，隔离理论不会阻挡所有人对公共物品的免费享用，但是隔离理论提出了一种方法对部分人群征收费用。
ponder就是用了类似隔离理论的方法：
首先，ponder的部署仍需要一定的知识，开发者在部署过程中需要提供RPC、数据库等外部依赖。同时在部署完成后，开发者需要持续运维ponder应用，比如使用proxy系统进行负载均衡避免数据请求影响ponder在后台线程内检索链上数据。这些对于一般的开发者来说都稍有复杂。目前ponder在内测全自动部署服务marble，用户只需要将代码交付给该平台就可以实现自动部署。显然这是一种对“隔离理论”的应用，这些不愿意自己运维ponder服务的开发者被隔离出来，这些开发者可以通过付费获得ponder服务的简化部署。当然，marble平台的出现也没有影响其他开发者免费使用ponder框架并且自托管部署。
ponder和Goldsky的受众？
ponder这种完全没有供应商依赖的公共物品比其他依赖供应商的数据检索服务在开发小型项目时更加流行。某些运营有大型项目的开发者并不一定选择ponder框架，因为大型项目往往要求检索服务具有充分的性能，Goldsky等服务提供商往往提供了充分的可用性保障。两者都存在一些风险点，从最近的Goldsky事件来看，开发者最好自行维护一套自己的ponder服务，以随时应对可能的第三方服务宕机。以及使用ponder时可能要考虑RPC返回数据的有效性问题，不久前safe就报告了一次因为RPC返回错误数据导致检索器崩溃的情况。虽然没有直接证据表明Goldsky事件也与RPC返回无效事件有关，但笔者怀疑Goldsky可能也遇到了类似事件。
local-first开发理念Local-first是过去几年一直被人讨论的话题。简单来说，Local-first要求软件具有以下功能:
离线工作跨客户端协同目前大部分与local-first相关的技术讨论都会涉及到CRDT(Conflict-freeReplicatedDataType)技术，所谓CRDT是一种无冲突的数据格式，该格式允许用户在多端操作时自动合并冲突以保持数据的完整性。一种简单的看法是可以将CRDT视为一种带有简单共识协议的数据类型，在分布式情况下，CRDT可以保证数据的完整性和一致性。
但在区块链开发中，我们可以放宽上述Local-first对软件要求的限制。我们仅要求在没有项目开发者提供的后端索引数据时，用户在前端仍可以保持最低限度的可用性。同时，local-first对跨客户端协同的要求实际上已经由区块链解决了。
在DApp的场景下，local-first理念可以这样实现：
缓存关键数据：前端应该缓存用户的重要数据，如余额、持仓信息等，即使索引服务不可用，用户仍能看到最后已知的状态。降级功能设计：当后端索引服务不可用时，DApp可以提供基础功能，比如在数据检索服务不可用时，部分数据可以考虑直接利用RPC读取链上数据，可以保证用户看到已有部分数据的最新情况这种local-first的DApp设计理念能够显著提高应用的韧性，避免在数据检索服务崩溃后的应用无法使用。在不考虑易用性的情况下，最好的local-first应用应该是要求用户在本地运行节点，然后使用类似trueblocks的工具在本地检索数据。关于去中心化检索或本地检索的一些讨论，可以参考推文Literallynoonecaresaboutdecentralizedfrontendsandindexers。
四、写在最后Goldsky六小时宕机事件为生态敲响了警钟。虽然区块链本身具有去中心化和抗单点故障的特性，但构建在其上的应用生态系统仍然高度依赖中心化的基础设施服务。这种依赖为整个生态系统带来了系统性风险。
本文简单介绍了早有盛名的去中心化检索服务TheGraph为什么在如今并没有被广泛使用，特别讨论了GRT代币经济学带来的一些复杂性。最后，本文讨论了如何构建更加健壮的数据检索基础设施，笔者鼓励开发者使用ponder自托管的数据检索开发框架作为应急响应选项，同时也介绍ponder良好的商业化路径。最后，本文讨论local-first的开发理念，鼓励开发者构建在无数据检索服务下仍可使用的应用。
从目前来看，不少Web3的开发者都意识到了数据检索服务的单点故障问题，GCC希望更多开发者关注这一基础设施，并尝试构建去中心化的数据检索服务或者设计一套框架使得DApp前端在无数据检索服务的情况仍可运行。
