摘要:

  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 的協議來激勵正確的響應,給開發人員提供一個友好的查詢接口。

解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場資料來源: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 獲取區塊鏈數據。
解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場Ookla 的速度測試

頁面中的所有字段需要大約 10.5 秒的時間來填滿對 the Graph 服務器發出的 10 秒請求,每個請求需要大約 250 毫秒才能返回響應。
解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場每個 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%

解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場來源:ThinkWithGoogle

對於 uniswap.info 或者其他任何一個 DApp,這些統計數字遠不能令人鼓舞!另一方面,如何加速運行速度很慢的網站是一個由來已久的問題。Facebook、亞馬遜、Youtube 和其他幾家大網站無須考慮用戶的地理位置,就具備即時加載的功能。他們是怎麼做到的呢?爲了找到解決方案,我們在查詢 the Graph 時,首先得確定導致延遲的請求-響應週期中的關鍵路徑。

深入挖掘

一個簡單的 PING 到 the Graph 的主機似乎表明網絡延遲不是一個重要的因素,因爲往返只有大約 5ms。
解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場

但是,IP 查找顯示 api.thegraph.com 網站像許多其他站點一樣,使用 Cloudflare 作爲 CDN 服務。
解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場來源:UltraTools

事實上,看看對 api.thegraph.com 發出的 OPTIONS (沒有請求)和 POST (有請求)請求的響應時間之間的差異結果表明,客戶端的處理時間只有 30ms,這表明剩餘的 220ms 是由於 Cloudflare 的代理服務器和 the Graph 的源服務器之間的延遲造成的。這可能是因爲 the Graph 只在全球一個位置運行服務器。

解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場

所以現在我們知道網絡延遲是減慢 Graph API 響應的原因。然而,難道 CDN (在本例中是 Cloudflare)的工作不是減少這種網絡延遲嗎?

CDN 是什麼?Web2 真的具備高速率嗎?

CDN 服務將緩存服務器放置在全球多個位置以減少地理距離,從而減輕響應延遲和源服務器上的負載。

在沒有 CDN 的情況下,Web 服務可採用以下方法之一:

  1. Web 服務直接服務於一個或多個源服務器的請求,在沒有分佈式、複雜和昂貴的負載平衡設置的情況下,這些服務器通常只位於一個位置,從而增加了響應延遲
  2. Web 服務可以彈性伸縮,根據需求自動提供容量,但通常對需求突然激增反應緩慢
  3. Web 服務的過度資源調配會導致容量過大,從而導致平均成本更高,在突然出現峯值時可能仍然不夠

在本地跨區域的 CDN 服務緩存常見請求以及互聯網的冪律,規定了 20% 的數據佔所有請求的 80%,從而避免了請求在使用低端但高度分佈式的計算機,爲源服務器提供服務的同時,需要訪問源服務器。

解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場來源: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。
解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場按國家分佈的 the Graph 的國家

解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場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 參數,此響應時間預計僅會增加有意義的請求。

解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場不同位置的 10% 延遲

很明顯,去中心化遠非靈丹妙藥。情況可能會好轉,但還遠不能保證一個由 the Graph 索引器組成的去中心化網絡會自動降低網絡的運行成本(包括補貼)或提高用戶的性能。

用於 API 的 CDN

那爲什麼儘管 uniswap.info 使用了 Cloudflare,一個流行的、高度分佈式的 CDN 提供商,但要加載這麼長時間?細節之處最容易出問題。仔細觀察響應頭可以發現,Cloudflare 從不用於將查詢請求緩存到 the Graph (“cfcache status:DYNAMIC”)。相反,Cloudflare 被要求始終將此類請求代理到源服務器。這是具有動態內容的網站所採用的常見策略,其中 Cloudflare 僅用於防止 DDoS。

解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場

它很容易緩存靜態資產,如圖像和視頻。不出所料,互聯網流量的很大一部分實際上是媒體。因此,CDN 在提高 web 和移動性能方面非常有效。

但是,傳統的 CDN 無法緩存像通過 API 交付的內容那樣頻繁和不可預知的變化。它們基於與每個資產相關聯的生存時間(TTL)來工作,在該時間之後,資產被清除並從源系統重新獲取。如果 TTL 太小,則會經常查詢原點,這正是我們開始解決的問題。如果 TTL 太大,將返回過時和不準確的結果。

在電子商務中,就像區塊鏈 DApp 一樣,和用戶利益相關的信息是高度動態的。正如庫存和定價在搶購期間頻繁變化一樣,每個區塊高度的區塊鏈數據也是如此。將這些動態內容留在源服務器上會減慢傳輸速度並增加基礎設施成本,服務運營商將由託管提供商(或索引器)和僅代理 API 調用的 CDN 加倍收費。

用於 API 的 CDN 需要更高級和定製的工程。事實上,很少有傳統的 CDN 公司爲 API 提供緩存服務,那些做這業務的公司會收取高額費用。

Marlin Cache

Marlin Cache 基於一個簡單的觀察,即在任何時候,一小部分 dApps 比其他更受歡迎。例如,訪問 Sushi 或 Rarible 的人絡繹不絕。服務於此類請求的索引在每個塊間隔(約 12 秒)只更新一次。因此,頻繁查詢的響應可以緩存在不同地理區域的本地緩存內,從而減少往返時間和源站的壓力。
解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場

緩存是事件驅動的。節點維護對熱點索引器的訂閱。緩存中的數據會隨着每個塊更新。Marlin 中繼確保在生成一個區塊時,每個緩存的更新延遲限制在 500 毫秒左右,即使只有一個完整的節點支持 the Graph 網絡(從以太坊礦工到完整節點的單向最壞情況延遲+從完整節點到緩存的延遲)。如果在全球範圍內多了幾個完整的節點,那麼 500 毫秒的更新延遲可以減少到 250 毫秒。

注意這裏提到的 250ms 延遲和 uniswap.info 之前指出的 250 毫秒延遲有所不同。一旦每個緩存根據最新的區塊進行了更新,客戶端的請求只需 5-10 毫秒就可以獲取數據。這裏的延遲表示用戶端在產生新區塊時將有 250 毫秒的延遲(由於任何系統在理論上的限制)。the Graph 和其他以太坊完整節點可以獨立使用 Marlin 中繼來減少這種延遲。

解析 Marlin 如何優化 the Graph,提供個性化 NFT 交易市場

在大多數緩存命中的情況下,任何通過 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

來源鏈接:www.marlin.pro