运营theGraph是资源密集型的工作，因为它需要一个同步的以太坊存档节点。
繁重的资源需求限制了theGraph节点可以放置的地理位置深度。
粗糙的渗透会影响到客户端的延迟，从而影响用户体验。
与区块链不同，在一个网络中拥有多个theGraph节点并不会显著提高其安全保障。攻击的代价主要是响应的索引器的质押。
因此，theGraph网络冗余度高，节点集中度高。这增加了客户端延迟，同时也带来了巨大的净货币成本，但不一定会提高网络安全性。
另外，索引器只每个块间隔更新一次索引。
我们在theGraph的前面提议了一个缓存层：策展人和索引器可以在全局范围内创建和索引区块链，但可以订阅它们的缓存轻节点数量要多得多。
缓存节点具有较低的存储需求，价格低廉，可以深入到地理位置，从而为客户端提供极低的延迟，同时与索引器保持同步。
theGraph是以太坊和IPFS的开源查询协议。基于广泛流行的GraphQL查询语言，它为开发人员减少了麻烦，无需设置完整节点和编写脚本，从磁盘中的原始数据提取相关信息的。相反，theGraph做了以太坊链上数据的索引，用类似Truebit的协议来激励正确的响应，给开发人员提供一个友好的查询接口。
资料来源：theGraph
在过去的几个月里，随着以太坊生态系统中DeFiDApp的激增，theGraph经历了抛物线式增长，每天处理多达2.2亿个查询，每月处理40亿个查询。可以毫不夸张地说，尽管有很多人试图构建一个去中心化的AWS，theGraph是web3中第一个获得显著吸引力的云计算服务。
中心化云的危险
具有讽刺意味的是，theGraph仅关注以太坊区块链和IPFS的特定请求，这也是它在Web3开发者中获得采用的最大优势。然而，到目前为止，它一直通过其托管服务来处理这些请求，这些服务很容易受到与单点故障相关的问题的影响。此外，theGraph的中心化式端点的响应时间也相当长，这取决于用户到其服务器的距离。
CEX当前ETH交易量是DEX的2.5倍:6月13日消息，链上分析公司Crypto Quant联合创始人兼CEO Ki YoungJu发推称，与DEX超越CEX的说法相反，CEX当前ETH的交易量是DEX的2.5倍。[2023/6/13 21:33:00]
以下列主机为例，其下行负载约为86Mbps，它使用theGraph获取区块链数据。
Ookla的速度测试
页面中的所有字段需要大约10.5秒的时间来填满对theGraph服务器发出的10秒请求，每个请求需要大约250毫秒才能返回响应。
每个uniswapv2请求都是一个theGraphAPI请求
这是我们在本文中多次提到的一个指标：对theGraph的中心化式端点的单个请求需要大约250毫秒
反响
如今，dApp的用户意识到他们是早期的采用者，他们热衷于测试新技术或挖矿，这大大抵消了用户体验的任何问题，但随着web3向大规模应用迈进，对于下一个10亿人，这种情况将不再适用。
为了更好地了解情况，以下是一些具体数字：
49%的互联网用户希望网页在2秒或更短时间内加载
53%的人会放弃一个需要加载3秒以上的网站
页面响应延迟1秒可导致转换率降低7%
来源：ThinkWithGoogle
对于uniswap.info或者其他任何一个DApp，这些统计数字远不能令人鼓舞！另一方面，如何加速运行速度很慢的网站是一个由来已久的问题。Facebook、亚马逊、Youtube和其他几家大网站无须考虑用户的地理位置，就具备即时加载的功能。他们是怎么做到的呢？为了找到解决方案，我们在查询theGraph时，首先得确定导致延迟的请求-响应周期中的关键路径。
万事达卡改变CEX.IO支付处理规则 将只能向美元欧元和英镑提款:从北京时间29日凌晨4点开始，万事达将改变CEX.IO平台支付处理的规则。为了能够向万事达卡取款，用户需要重新提交信用卡信息进行验证。验证完成后，存款和提款都将再次可用。用户需注意，验证后只能以美元提款。使用万事达卡的客户若需提取另一种货币（欧元或英镑），将有必要提供20欧元或15英镑的一次性最低存款。万事达卡其他货币的提款将被禁用。存款成功后，您将可以用其余资金提取存款。[2018/3/1]
深入挖掘
一个简单的PING到theGraph的主机似乎表明网络延迟不是一个重要的因素，因为往返只有大约5ms。
但是，IP查找显示api.thegraph.com网站像许多其他站点一样，使用Cloudflare作为CDN服务。
\n
来源：UltraTools
事实上，看看对api.thegraph.com发出的OPTIONS和POST请求的响应时间之间的差异结果表明，客户端的处理时间只有30ms，这表明剩余的220ms是由于Cloudflare的代理服务器和theGraph的源服务器之间的延迟造成的。这可能是因为theGraph只在全球一个位置运行服务器。
所以现在我们知道网络延迟是减慢GraphAPI响应的原因。然而，难道CDN的工作不是减少这种网络延迟吗？
CDN是什么？Web2真的具备高速率吗？
CDN服务将缓存服务器放置在全球多个位置以减少地理距离，从而减轻响应延迟和源服务器上的负载。
在没有CDN的情况下，Web服务可采用以下方法之一：
比特比黄金上线CEX.IO:CEX.IO宣布推出比特币黄金交易。上线的交易包括BTG/美元，BTG/欧元，以及BTG/ BTC。[2017/12/9]
Web服务直接服务于一个或多个源服务器的请求，在没有分布式、复杂和昂贵的负载平衡设置的情况下，这些服务器通常只位于一个位置，从而增加了响应延迟
Web服务可以弹性伸缩，根据需求自动提供容量，但通常对需求突然激增反应缓慢
Web服务的过度资源调配会导致容量过大，从而导致平均成本更高，在突然出现峰值时可能仍然不够
在本地跨区域的CDN服务缓存常见请求以及互联网的幂律，规定了20%的数据占所有请求的80%，从而避免了请求在使用低端但高度分布式的计算机，为源服务器提供服务的同时，需要访问源服务器。
来源：DigitalConnectMag
CDN实际上是加速访问Facebook、亚马逊和YouTube等网站的关键。如果地理分布是CDN提高web性能的原因，那么theGraph的去中心化网络是否可以解决它的延迟问题，这可能会很吸引人。
去中心化云是否能作为CDN？
通常假设全局分布式去中心化网络是会自动提高性能的。然而，这里有一个非常可疑的假设——成本和无形的运营开销很高，会导致节点运营商们会集中在最适合他们的地方。
定价：提供云服务的运营支出可能会很可观。每个磁盘访问和CPU周期都需要花费一个人的真金白银。短期内，此类费用可通过VC筹钱或通胀代币给予补贴。然而，从长期来看，这种服务的受益者预计将付出代价。
资源需求：运行节点要支持theGraph网络，需要运行以太坊完整节点。不用说，作为theGraph网络上的索引器，资源密集，而且成本高昂，正如任何theGraph的测试网都会证明的那样。Balancer、Compound、Uniswapv2子图要求运行消耗超过5TBSSD的以太坊存档节点，并且每月可能花费大约500美元，不包括带宽成本。
密集的磁盘访问和计算操作以及成本限制了theGraph节点可以放置的位置数，从而增加了用户的延迟。这件事情正发生在theGraph的测试网本身。
在theGraph的测试网中，在查询时在线并正确响应ping的大约200个节点中，90%位于仅3个国家：美国、芬兰和德国，仅德国就占了50%的节点。此外，65%的节点使用相同的VPS供应商，HetznerOnline。
按国家分布的theGraph的国家
\n
theGraph的测试网节点的ISP分布
但是，我们都知道，完美的去中心化定义模糊；低成本和良好的性能是大多数付费客户通常追求的。那么，这些指标是如何受到上述结果的影响的呢？
theGraph网络中的IP列表如下：https://docs.google.com/spreadsheets/d/1qLb-D9sb0c9wvrIbMUMB63xnXh1DXmsPRfXh6UsSk28/edit?usp=sharing。让我们使用timecurl-L'<URL>'-XOPTIONS-w“{time\\utotal}”来ping每个IP并检查RTT。
结果将根据进行查询的主机位置而有所不同。以下是来自印度班加罗尔同一主机的结果，它导出了theGraph中心化端点的前250ms结果：
平均值：677.5912ms
中位数：546.472ms
标准偏差：498.6831ms
当然，以上不全是。与先前返回查询结果的250ms响应不同，占用的时间超过两倍的查询，只是一个OPTIONS请求，该请求不期望任何数据响应，因此不包括任何磁盘获取或处理时间。根据服务器的缓存配置和磁盘/CPU参数，此响应时间预计仅会增加有意义的请求。
很明显，去中心化远非灵丹妙药。情况可能会好转，但还远不能保证一个由theGraph索引器组成的去中心化网络会自动降低网络的运行成本或提高用户的性能。
用于API的CDN
那为什么尽管uniswap.info使用了Cloudflare，一个流行的、高度分布式的CDN提供商，但要加载这么长时间？细节之处最容易出问题。仔细观察响应头可以发现，Cloudflare从不用于将查询请求缓存到theGraph。相反，Cloudflare被要求始终将此类请求代理到源服务器。这是具有动态内容的网站所采用的常见策略，其中Cloudflare仅用于防止DDoS。
它很容易缓存静态资产，如图像和视频。不出所料，互联网流量的很大一部分实际上是媒体。因此，CDN在提高web和移动性能方面非常有效。
但是，传统的CDN无法缓存像通过API交付的内容那样频繁和不可预知的变化。它们基于与每个资产相关联的生存时间来工作，在该时间之后，资产被清除并从源系统重新获取。如果TTL太小，则会经常查询原点，这正是我们开始解决的问题。如果TTL太大，将返回过时和不准确的结果。
在电子商务中，就像区块链DApp一样，和用户利益相关的信息是高度动态的。正如库存和定价在抢购期间频繁变化一样，每个区块高度的区块链数据也是如此。将这些动态内容留在源服务器上会减慢传输速度并增加基础设施成本，服务运营商将由托管提供商和仅代理API调用的CDN加倍收费。
用于API的CDN需要更高级和定制的工程。事实上，很少有传统的CDN公司为API提供缓存服务，那些做这业务的公司会收取高额费用。
MarlinCache
MarlinCache基于一个简单的观察，即在任何时候，一小部分dApps比其他更受欢迎。例如，访问Sushi或Rarible的人络绎不绝。服务于此类请求的索引在每个块间隔只更新一次。因此，频繁查询的响应可以缓存在不同地理区域的本地缓存内，从而减少往返时间和源站的压力。
缓存是事件驱动的。节点维护对热点索引器的订阅。缓存中的数据会随着每个块更新。Marlin中继确保在生成一个区块时，每个缓存的更新延迟限制在500毫秒左右，即使只有一个完整的节点支持theGraph网络。如果在全球范围内多了几个完整的节点，那么500毫秒的更新延迟可以减少到250毫秒。
注意这里提到的250ms延迟和uniswap.info之前指出的250毫秒延迟有所不同。一旦每个缓存根据最新的区块进行了更新，客户端的请求只需5-10毫秒就可以获取数据。这里的延迟表示用户端在产生新区块时将有250毫秒的延迟。theGraph和其他以太坊完整节点可以独立使用Marlin中继来减少这种延迟。
在大多数缓存命中的情况下，任何通过MarlinCache的CDN到索引器的路由查询都可以将用户的响应时间从230毫秒到1.5秒降低到5-10毫秒。此外，为了方便集成，Web3客户端像许多视频播放器可以把CDN域名和到索引器的域名作为备用url写到代码里，这样在缓存不命中时也不会有额外的时间损失。
你所激励的就是你得到的保证
我们可能会问theCache是theGraph杀手还是Filecoin杀手。实际上都不是。theGraph激励子图的创建、子图的可检索性和响应的正确性。另一方面，Filecoin或Arweave激励在网络中存储内容。理性的参与者在惩罚定义的约束下工作，同时试图最大化协议提供的激励。
theCache通过其邻近性的证明激励参与者在全球范围内深入地理图。该机制确保缓存在一定的时间限制内对请求作出响应，否则将面临随时间降级的风险。另一方面，响应的正确性仍然会被确保，因为它们需要证明任何子图的子图的响应都可以从索引器提供的相应子图的响应中导出。
theCache的激励措施鼓励分布在不同地理位置的低端节点的运行，其唯一目的是更新、存储和服务热点API请求的响应。
总而言之，theCache与其他索引器的一些显著区别是：
theCache节点只需要几兆字节的存储空间，这在大多数情况下都能容纳在RAM中，而不需要像Infura、Graph或Pokt网络这样的完整或归档节点。较低的资源需求使节点分布更加深入和本地化，从而减少了客户端的延迟。
theCache支持索引器没有提供的智能合约事件和余额、地址、存储监视程序。
theCache并不局限于任何特定的索引器或查询协议，可以使用更广泛的数据源和后端。
theCache提供从索引器提供的相应响应派生的响应加密证明。因此，相比于使用fisherman协议来检测损毁的响应，客户端可以立即拒绝不正确的响应。因此，缓存更偏向正确性，而非Graph的fisherman协议提供的可用性。在这两种情况下，客户端可以选择查询多个节点以获得更高的可靠性。
特征
MarlinCache在边缘通过预定义的自定义逻辑实现更快的响应时间。此功能直接或间接地使许多很酷的功能能够丰富web3.0体验：
缓存：dApp可以减少源站的负载和查询区块链的相关成本，同时也可以为用户提高响应能力
一致性：在全球低延迟连接的情况下，dApp和API提供商可以不必担心为不同渠道和用户提供不一致的响应
设备优化：NFT市场、游戏和一般基于IPFS的dApp可以实时地为用户优化内容，例如，通过向移动设备提供消耗较少带宽的低分辨率图像
个性化：根据地理和历史定制内容可以提高Web3市场的参与度和转化率
DDoS防护：全球和深入定位的缓存服务器可以更有效地吸收请求，同时还可以更容易地检测恶意攻击
实时分析：艺术家、开发者和市场所有者可以更好地了解用户活动和参与度
实验性商业化模式：相比于直接向用户收费，通过以一种保护隐私的方式收集用户数据的商业化模型也成为了可能
入门
简而言之，MarlinCache通过在用户旁边缓存数据，努力为web3dApp提供类似Web2的性能。如果您是一名开发人员，希望将区块链API请求中产生的250毫秒到1.5秒的延迟减少到10毫秒以下，请直接进入我们的文档，了解如何使用theCache，并在遇到查询时加入我们的discordgroup。
通过我们的官方渠道确保您随时了解最新情况：
Twitter：https://twitter.com/MarlinProtocol
TelegramAnnouncementChannel：https://t.me/MarlinProtocolAnn
TelegramChatGroup：https://t.me/MarlinProtocol
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。