在0xArc,我們需要獲取每個鏈上的每一條資料,包括過去、現在和未來。因此,我們的資料倉庫規模達到數百TB。為了獲取這些資料,我們已經進行了數十億次RPC呼叫,每月繼續進行數億次跨多個區塊鏈網路的呼叫。不幸的是,我們發現RPC呼叫節點的成功率平均約為80%,價格也存在10倍的波動!本文分享了我們的一些發現,希望對社群其他人有所幫助。
節點如何工作
在討論數字之前,瞭解加密貨幣中節點行業的工作原理很重要,這樣我們就可以正確理解我們正在討論的內容。雖然每個人都能執行自己的節點,並遵循去中心化的完美原則,但事實是,執行節點是複雜的,需要專業知識。因此,我們將這一責任委託給了節點提供商。這個圖表是基於2024年加密貨幣中商業節點行業的工作方式。
總的來說,你有執行在特定節點實現(geth/reth/erigon)上的完整或歸檔節點,這些節點由Alchemy或Quicknode等提供商託管在每個支援的區塊鏈網路上。作為RPC消費者,你最終訪問所有這些內容。
最佳節點選擇
當你分解這個邏輯鏈時,你有4個主要維度會極大地影響效能:
你發出RPC請求的鏈:每個鏈的節點網路表現不同,活躍程度也不同。
你呼叫的方法:這取決於你是在進行完整節點還是歸檔節點呼叫,以及節點客戶端實現。
你使用的提供商:託管節點供你訪問的實體。
你何時呼叫節點:節點效能隨著上述所有維度的變化而變化,並非恆定。
能夠檢測和理解這些資料可能很有挑戰性。然而,在0xArc,這是我們的工作,因為我們進行了數十億次RPC呼叫,並仔細監控我們接觸的所有內容。效能、可靠性和成本對我們至關重要。我們在大多數市場參與者之前就知道某條鏈或某個RPC提供商出現故障。以下是我們在本文中將要研究的資料背景:
日期範圍:2024年8月1日至10月20日
請求數:1,492,103,937
成功數:1,171,952,063
失敗數:320,793,140
平均成功率:78.5%
為了正確理解超過10億行資料發生的情況,我們需要從多個維度對其進行切片和分析。幸運的是,我們知道這些維度是什麼,正如我上面提到的。
接下來的文章將展示效能如何在每個維度上以不可預測的方式發生變化的獨特例項。
鏈路效能
假設你正在構建一個依賴於與各種網路互動的跨鏈應用程式。你的節點效能將根據你呼叫的鏈以及呼叫的時間而顯著不同。
第一個圖顯示了每天每個鏈的平均成功率,這是跨所有提供商和方法彙總的結果。如你所見,從圖表中可以看出,每個月鏈的平均成功率都有很大差異。我們不確定這可能是由什麼原因造成的,但我們可以看到,8月份Polygon呼叫的成功率平均為60%,但最近幾周已經上升到80%以上。
在評估這些資料時,需要注意的一個關鍵警示是:"Polygon是一個糟糕的鏈,RPC呼叫平均只有70%的成功率"。這是在大約2.5個月的時間內,跨所有鏈、所有提供商和所有方法的加權平均成功率。當我們深入研究這些維度中的任何一個時,資料都會發生顯著變化。
這是同樣的圖表,但只涵蓋了17天的時間,並按單一提供商進行了過濾。如你所見,圖表要平滑得多,與整體彙總有所不同。
如果我們發現某個單一提供商表現良好,那麼我們為什麼不一直依賴於他們呢?下一節將更細緻地解決這個問題。
提供商效能
這個下一個圖表我簡化了,因為我想避免出現太多線條。每一個都代表一個主要的RPC提供商網路,其成功率是跨所有鏈和方法彙總的結果。如你從下面的圖表中看到的,橙色提供商相對於其他提供商是最可靠的,差異相當驚人!
再次,顯而易見的可能就是"使用橙色提供商",因為它表現良好。不幸的是,這也並不太管用。當我們只看橙色提供商在以太坊上的效能時,歸檔節點方法的效能可能會出現戲劇性下降。如你所見,在將近一個月的時間裡,在我們上面所謂的"最佳提供商"上,歸檔節點的效能都非常糟糕。
所以,如果我們要追求某些方法的最佳效能,我們需要更仔細地觀察。
方法效能
下面的最終圖表顯示,各種方法的成功率在月度之間發生了相當大的變化。根據你是在呼叫完整節點還是歸檔節點,你的效能會有很大不同。我們在上面針對單個鏈上的單個提供商看到了這一點,但現在我們有了一個更廣泛的視角。
如果我們平均這些資料,我們會得到下面按方法劃分的平均成功率,以及顯示歸檔節點與非歸檔節點呼叫比例的面積圖。從這種方式來看,你會意識到節點的不可靠性是多麼嚴重,尤其是當你跨多個維度進行衡量時。許多時候,節點提供商使用有限時間框架內的華麗營銷數字來推廣他們的效能。直到你大規模地攻擊他們,才能看到真實的指標。
最佳策略
那麼,選擇節點的最佳方式是什麼?一種論點可能是隻使用我們上面提到的橙色提供商,但當他們的系統開始失敗並出現大幅下降時,你的下游系統也會因為他們而失敗。
避免這種情況的一種方法是在系統中設定備用提供商。但是,這些備用提供商需要手動維護,並透過次優路由增加延遲。理想情況下,你希望以動態、智慧的方式擁有這些路由的效能資料,而不是在程式碼庫中使用靜態的if/else子句。
更讓事情變得更加複雜的是,每個提供商在每個鏈和方法上的定價都在變化。這些差異可能高達每種方法/鏈10倍的成本。突然,10-20%的效能差異最終會讓你付出更多!每個提供商都想讓你鎖定在一個年度計劃或每月配額中,這會產生額外的成本。幾乎沒有提供商是純使用量付費的,這意味著你必須對一個單一的提供商下注 - 沒有任何資料!一個表面上"簡單"的服務,實際上在仔細檢查時表現差異很大。
如果你正在為RPC付費或考慮你的基礎設施的可靠性,讓我們探討如何最大化跨鏈和提供商的效能。請聯絡我們,瞭解我們的發現或看看我們如何為您提供幫助。
目前正在為RPC付費,想了解如何提高可靠性
是一個RPC提供商,想知道你的節點表現如何
正在考慮註冊RPC服務,想得到一些建議
直接透過這封電子郵件或傳送電子郵件至k@0xarc.io與我聯絡,我們可以安排時間進行交流。
