要理解为什么会发生 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 文档内存在以下内容:
