引入Marlin作为缓存以降低the Graph的成本提高其速度,打开个性化NFT交易市场

Link to original article: https://www.marlin.pro/blog/introducing-marlin-as-a-cache-to-accelerate-and-cheapen-the-graph-and-personalize-nft-marketplaces/

摘要

  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 的协议来激励正确的响应,给开发人员提供一个友好的查询接口。

Daily Query Volume - The Graph
资料来源: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 获取区块链数据。

SpeedTest by Ookla
Ookla的速度测试

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

Uniswapv2 request is a Graph API request
每个 uniswapv2 请求都是一个 the Graph API请求

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

反响

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

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

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

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

深入挖掘

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

Ping to Graph Host

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

The Graph's IP Lookup
来源: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%,从而避免了请求在使用低端但高度分布式的计算机,为源服务器提供服务的同时,需要访问源服务器。

CDN
来源: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。

Distribution by country of the Graph’s testnet nodes
按国家分布的 the Graph 的国家
Distribution by ISP of the Graph’s testnet nodes
the Graph 的测试网节点的ISP分布

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

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

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

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

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

客户端地址

RTT

班加罗尔

296ms

美国(西海岸)

140ms

新加坡

361ms

不同位置的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比其他更受欢迎。例如,访问SushiRarible的人络绎不绝。服务于此类请求的索引在每个块间隔(约12秒)只更新一次。因此,频繁查询的响应可以缓存在不同地理区域的本地缓存内,从而减少往返时间和源站的压力。

Marlin Cache

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

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

Marlin - Distribution Layer

在大多数缓存命中的情况下,任何通过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协议来检测损毁的响应,客户端可以立即拒绝不正确的响应。因此,缓存更偏向正确性,而非Graphfisherman协议提供的可用性。在这两种情况下,客户端可以选择查询多个节点以获得更高的可靠性。

特征

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

(i) 缓存:dApp可以减少源的负载和查询区块链的相关成本,同时也可以为用户提高响应能力

(ii)一致性:在全球低延迟连接的情况下,dApp和API提供商可以不必担心为不同渠道和用户提供不一致的响应

(iii)设备优化:NFT市场、游戏和一般基于IPFS的dApp可以实时地为用户优化内容,例如,通过向移动设备提供消耗较少带宽的低分辨率图像

(iv)个性化:根据地理和历史定制内容(例如,不在某些地区展示文化上不合适的艺术)可以提高Web3市场的参与度和转化率

(v) DDoS防护:全球和深入定位的缓存服务器可以更有效地吸收请求,同时还可以更容易地检测恶意攻击

(vi)实时分析:艺术家、开发者和市场所有者可以更好地了解用户活动和参与度

(七)实验性商业化模式:相比于直接向用户收费,通过以一种保护隐私的方式(例如,使用差异化隐私)收集用户数据的商业化模型也成为了可能

入门

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

通过我们的官方渠道确保您随时了解最新情况:

Twitter | Telegram Announcements | Telegram Chat | Discord | Website

Stay connected

Subscribe to our newsletter.