摘要：

1. 运营 the Graph 是资源密集型的工作，因为它需要一个同步的以太坊存档节点。
2. 繁重的资源需求限制了 the Graph 节点可以放置的地理位置深度。
3. 粗糙的渗透会影响到客户端的延迟，从而影响用户体验。
4. 与区块链不同，在一个网络中拥有多个 the Graph 节点并不会显著提高其安全保障。攻击的代价主要是响应的索引器的质押。
5. 因此， the Graph 网络冗余度高，节点集中度高。这增加了客户端延迟，同时也带来了巨大的净货币成本，但不一定会提高网络安全性。
6. 另外，索引器只每个块间隔（大约 12 秒）更新一次索引。
7. 我们在 the Graph 的前面提议了一个缓存层：策展人（curator）和索引器可以在全局范围内创建和索引区块链，但可以订阅它们的缓存轻节点数量要多得多。
8. 缓存节点具有较低的存储需求，价格低廉，可以深入到地理位置，从而为客户端提供极低的延迟，同时与索引器保持同步。

the Graph 是以太坊和 IPFS 的开源查询协议。基于广泛流行的 GraphQL 查询语言，它为开发人员减少了麻烦，无需设置完整节点和编写脚本，从磁盘中的原始数据提取相关信息的。相反，the Graph 做了以太坊链上数据的索引，用类似 Truebit 的协议来激励正确的响应，给开发人员提供一个友好的查询接口。

资料来源：the Graph

在过去的几个月里，随着以太坊生态系统中 DeFi DApp 的激增， the Graph 经历了抛物线式增长，每天处理多达 2.2 亿个查询，每月处理 40 亿个查询。可以毫不夸张地说，尽管有很多人试图构建一个去中心化的 AWS，the Graph 是 web 3 中第一个获得显著吸引力的云计算服务（当然以太坊作为一台世界计算机除外）。

中心化云的危险

具有讽刺意味的是， the Graph 仅关注以太坊区块链和 IPFS 的特定请求，这也是它在 Web3 开发者中获得采用的最大优势。然而，到目前为止，它一直通过其托管服务来处理这些请求，这些服务很容易受到与单点故障（停机时间、DDoS 和有限扩展）相关的问题的影响。此外，the Graph 的中心化式端点的响应时间也相当长，这取决于用户到其服务器的距离。

以下列主机为例，其下行负载约为 86 Mbps （ https://uniswap.info ），它使用 the Graph 获取区块链数据。
Ookla 的速度测试

页面中的所有字段需要大约 10.5 秒的时间来填满对 the Graph 服务器发出的 10 秒请求，每个请求需要大约 250 毫秒才能返回响应。
每个 uniswapv2 请求都是一个 the Graph API 请求

这是我们在本文中多次提到的一个指标：对 the Graph 的中心化式端点的单个请求需要大约 250 毫秒（对于不需要响应的请求，它需要 227ms，而对于具有 287 B 响应的请求，则为 329 ms。大约 7 个请求需要 1.3 到 1.7 秒才能返回响应。）

反响

如今，dApp 的用户意识到他们是早期的采用者，他们热衷于测试新技术或挖矿，这大大抵消了用户体验的任何问题，但随着 web3 向大规模应用迈进，对于下一个 10 亿人，这种情况将不再适用。

为了更好地了解情况，以下是一些具体数字：

• 49% 的互联网用户希望网页在 2 秒或更短时间内加载
• 53% 的人会放弃一个需要加载 3 秒以上的网站
• 页面响应延迟 1 秒可导致转换率降低 7%

来源：ThinkWithGoogle

对于 uniswap.info 或者其他任何一个 DApp，这些统计数字远不能令人鼓舞！另一方面，如何加速运行速度很慢的网站是一个由来已久的问题。Facebook、亚马逊、Youtube 和其他几家大网站无须考虑用户的地理位置，就具备即时加载的功能。他们是怎么做到的呢？为了找到解决方案，我们在查询 the Graph 时，首先得确定导致延迟的请求-响应周期中的关键路径。

深入挖掘

一个简单的 PING 到 the Graph 的主机似乎表明网络延迟不是一个重要的因素，因为往返只有大约 5ms。

但是，IP 查找显示 api.thegraph.com 网站像许多其他站点一样，使用 Cloudflare 作为 CDN 服务。
来源：UltraTools

事实上，看看对 api.thegraph.com 发出的 OPTIONS （没有请求）和 POST （有请求）请求的响应时间之间的差异结果表明，客户端的处理时间只有 30ms，这表明剩余的 220ms 是由于 Cloudflare 的代理服务器和 the Graph 的源服务器之间的延迟造成的。这可能是因为 the Graph 只在全球一个位置运行服务器。

所以现在我们知道网络延迟是减慢 Graph API 响应的原因。然而，难道 CDN （在本例中是 Cloudflare）的工作不是减少这种网络延迟吗？

CDN 是什么？Web2 真的具备高速率吗？

CDN 服务将缓存服务器放置在全球多个位置以减少地理距离，从而减轻响应延迟和源服务器上的负载。

在没有 CDN 的情况下，Web 服务可采用以下方法之一：

1. Web 服务直接服务于一个或多个源服务器的请求，在没有分布式、复杂和昂贵的负载平衡设置的情况下，这些服务器通常只位于一个位置，从而增加了响应延迟
2. Web 服务可以弹性伸缩，根据需求自动提供容量，但通常对需求突然激增反应缓慢
3. Web 服务的过度资源调配会导致容量过大，从而导致平均成本更高，在突然出现峰值时可能仍然不够

在本地跨区域的 CDN 服务缓存常见请求以及互联网的幂律，规定了 20% 的数据占所有请求的 80%，从而避免了请求在使用低端但高度分布式的计算机，为源服务器提供服务的同时，需要访问源服务器。

来源：Digital Connect Mag

CDN 实际上是加速访问 Facebook、亚马逊和 YouTube 等网站的关键。如果地理分布是 CDN 提高 web 性能的原因，那么 the Graph 的去中心化网络是否可以解决它的延迟问题，这可能会很吸引人。

去中心化云是否能作为 CDN？

通常假设全局分布式去中心化网络是会自动提高性能的。然而，这里有一个非常可疑的假设——成本和无形的运营开销很高，会导致节点运营商们会集中在最适合他们的地方。

1. 定价：提供云服务的运营支出可能会很可观。每个磁盘访问和 CPU 周期都需要花费一个人的真金白银。短期内，此类费用可通过 VC 筹钱或通胀代币给予补贴。然而，从长期来看，这种服务的受益者预计将付出代价。
2. 资源需求：运行节点要支持 the Graph 网络，需要运行以太坊完整节点。不用说，作为 the Graph 网络上的索引器，资源密集，而且成本高昂，正如任何 the Graph 的测试网都会证明的那样。Balancer、Compound、Uniswap v2 子图要求运行消耗超过 5TB SSD 的以太坊存档节点，并且每月可能花费大约 500 美元，不包括带宽成本（Turbogeth 目前不支持 the Graph 查询）。

密集的磁盘访问和计算操作以及成本限制了 the Graph 节点可以放置的位置数，从而增加了用户的延迟。这件事情正发生在 the Graph 的测试网本身。

在 the Graph 的测试网中，在查询时在线并正确响应 ping 的大约 200 个节点中，90% 位于仅 3 个国家：美国、芬兰和德国，仅德国就占了 50% 的节点。此外，65% 的节点使用相同的 VPS 供应商，Hetzner Online。
按国家分布的 the Graph 的国家

the Graph 的测试网节点的 ISP 分布

但是，我们都知道，完美的去中心化定义模糊；低成本和良好的性能是大多数付费客户通常追求的。那么，这些指标是如何受到上述结果的影响的呢？

the Graph 网络中的 IP 列表如下：https://docs.google.com/spreadsheets/d/1qLb-D9sb0c9wvrIbMUMB63xnXh1DXmsPRfXh6UsSkk/edit?usp=sharing。让我们使用 time curl-L''-X OPTIONS-w“{time\u total}”来 ping 每个 IP 并检查 RTT。

结果将根据进行查询的主机位置而有所不同。以下是来自印度班加罗尔同一主机的结果，它导出了 the Graph 中心化端点的前 250ms 结果：

平均值：677.5912ms
中位数：546.472ms
标准偏差：498.6831ms

当然，以上不全是。与先前返回查询结果的 250ms 响应不同，占用的时间超过两倍的查询，只是一个 OPTIONS 请求，该请求不期望任何数据响应，因此不包括任何磁盘获取或处理时间。根据服务器的缓存配置和磁盘 /CPU 参数，此响应时间预计仅会增加有意义的请求。

不同位置的 10% 延迟

很明显，去中心化远非灵丹妙药。情况可能会好转，但还远不能保证一个由 the Graph 索引器组成的去中心化网络会自动降低网络的运行成本（包括补贴）或提高用户的性能。

用于 API 的 CDN

那为什么尽管 uniswap.info 使用了 Cloudflare，一个流行的、高度分布式的 CDN 提供商，但要加载这么长时间？细节之处最容易出问题。仔细观察响应头可以发现，Cloudflare 从不用于将查询请求缓存到 the Graph （“cfcache status:DYNAMIC”）。相反，Cloudflare 被要求始终将此类请求代理到源服务器。这是具有动态内容的网站所采用的常见策略，其中 Cloudflare 仅用于防止 DDoS。

它很容易缓存静态资产，如图像和视频。不出所料，互联网流量的很大一部分实际上是媒体。因此，CDN 在提高 web 和移动性能方面非常有效。

但是，传统的 CDN 无法缓存像通过 API 交付的内容那样频繁和不可预知的变化。它们基于与每个资产相关联的生存时间（TTL）来工作，在该时间之后，资产被清除并从源系统重新获取。如果 TTL 太小，则会经常查询原点，这正是我们开始解决的问题。如果 TTL 太大，将返回过时和不准确的结果。

在电子商务中，就像区块链 DApp 一样，和用户利益相关的信息是高度动态的。正如库存和定价在抢购期间频繁变化一样，每个区块高度的区块链数据也是如此。将这些动态内容留在源服务器上会减慢传输速度并增加基础设施成本，服务运营商将由托管提供商（或索引器）和仅代理 API 调用的 CDN 加倍收费。

用于 API 的 CDN 需要更高级和定制的工程。事实上，很少有传统的 CDN 公司为 API 提供缓存服务，那些做这业务的公司会收取高额费用。

Marlin Cache

Marlin Cache 基于一个简单的观察，即在任何时候，一小部分 dApps 比其他更受欢迎。例如，访问 Sushi 或 Rarible 的人络绎不绝。服务于此类请求的索引在每个块间隔（约 12 秒）只更新一次。因此，频繁查询的响应可以缓存在不同地理区域的本地缓存内，从而减少往返时间和源站的压力。

缓存是事件驱动的。节点维护对热点索引器的订阅。缓存中的数据会随着每个块更新。Marlin 中继确保在生成一个区块时，每个缓存的更新延迟限制在 500 毫秒左右，即使只有一个完整的节点支持 the Graph 网络（从以太坊矿工到完整节点的单向最坏情况延迟+从完整节点到缓存的延迟）。如果在全球范围内多了几个完整的节点，那么 500 毫秒的更新延迟可以减少到 250 毫秒。

注意这里提到的 250ms 延迟和 uniswap.info 之前指出的 250 毫秒延迟有所不同。一旦每个缓存根据最新的区块进行了更新，客户端的请求只需 5-10 毫秒就可以获取数据。这里的延迟表示用户端在产生新区块时将有 250 毫秒的延迟（由于任何系统在理论上的限制）。the Graph 和其他以太坊完整节点可以独立使用 Marlin 中继来减少这种延迟。

在大多数缓存命中的情况下，任何通过 Marlin Cache 的 CDN 到索引器的路由查询都可以将用户的响应时间从 230 毫秒到 1.5 秒降低到 5-10 毫秒。此外，为了方便集成，Web3 客户端像许多视频播放器可以把 CDN 域名和到索引器的域名作为备用 url 写到代码里，这样在缓存不命中时也不会有额外的时间损失。

你所激励的就是你得到的保证

我们可能会问 the Cache 是 the Graph 杀手还是 Filecoin 杀手。实际上都不是。 the Graph 激励子图的创建、子图的可检索性和响应的正确性。另一方面，Filecoin 或 Arweave 激励在网络中存储内容。理性的参与者在惩罚定义的约束下工作，同时试图最大化协议提供的激励。

the Cache 通过其邻近性的证明激励参与者在全球范围内深入地理图。该机制确保缓存在一定的时间限制内对请求作出响应，否则将面临随时间降级的风险。另一方面，响应的正确性仍然会被确保，因为它们需要证明任何子图的子图的响应都可以从索引器提供的相应子图的响应中导出。

the Cache 的激励措施鼓励分布在不同地理位置的低端节点（资源需求远低于运行以太坊完整节点）的运行，其唯一目的是更新、存储和服务热点 API 请求的响应。

总而言之，the Cache 与其他索引器的一些显著区别是：

（i） the Cache 节点只需要几兆字节的存储空间，这在大多数情况下都能容纳在 RAM 中，而不需要像 Infura、Graph 或 Pokt 网络这样的完整或归档节点。较低的资源需求使节点分布更加深入和本地化，从而减少了客户端的延迟。

（ii） the Cache 支持索引器没有提供的智能合约事件和余额、地址、存储监视程序。

（iii） the Cache 并不局限于任何特定的索引器或查询协议，可以使用更广泛的数据源和后端。

（iv） the Cache 提供从索引器提供的相应响应派生的响应加密证明。因此，相比于使用 fisherman 协议来检测损毁的响应，客户端可以立即拒绝不正确的响应。因此，缓存更偏向正确性，而非 Graph 的 fisherman 协议提供的可用性。在这两种情况下，客户端可以选择查询多个节点以获得更高的可靠性。

特征

Marlin Cache 在边缘通过预定义的自定义逻辑实现更快的响应时间。此功能直接或间接地使许多很酷的功能能够丰富 web 3.0 体验：

• 缓存：dApp 可以减少源站的负载和查询区块链的相关成本，同时也可以为用户提高响应能力
• 一致性：在全球低延迟连接的情况下，dApp 和 API 提供商可以不必担心为不同渠道和用户提供不一致的响应
• 设备优化：NFT 市场、游戏和一般基于 IPFS 的 dApp 可以实时地为用户优化内容，例如，通过向移动设备提供消耗较少带宽的低分辨率图像
• 个性化：根据地理和历史定制内容（例如，不在某些地区展示文化上不合适的艺术）可以提高 Web3 市场的参与度和转化率
• DDoS 防护：全球和深入定位的缓存服务器可以更有效地吸收请求，同时还可以更容易地检测恶意攻击
• 实时分析：艺术家、开发者和市场所有者可以更好地了解用户活动和参与度
• 实验性商业化模式：相比于直接向用户收费，通过以一种保护隐私的方式（例如，使用差异化隐私）收集用户数据的商业化模型也成为了可能

入门

简而言之，Marlin Cache 通过在用户旁边缓存数据，努力为 web3 dApp 提供类似 Web 2 的性能。如果您是一名开发人员，希望将区块链 API 请求中产生的 250 毫秒到 1.5 秒的延迟减少到 10 毫秒以下，请直接进入我们的文档，了解如何使用 the Cache，并在遇到查询时加入我们的 discord group。

通过我们的官方渠道确保您随时了解最新情况：
Twitter|Telegram Announcements|Telegram Chat|Discord|Website