專屬區塊鏈基礎設施的運作方式

大多數的生產工作負載在共享的區塊鏈 RPC 基礎設施上都能正常運作。但有一小部分工作負載不行。例如一個交易台,它與定序器(rollup 的交易排序服務)之間的往返延遲,決定了訂單能否進入下一個區塊。一家安全公司,其模擬引擎執行客製化的 EVM tracer,而沒有任何共享供應商願意提供這樣的主機。一家受監管的金融科技公司,其合規團隊不會核准與其他客戶工作負載共用的硬體。

對於這些工作負載,答案是專屬區塊鏈基礎設施。

Dedicated 是相同的基礎設施,但範圍限定在單一租戶上。相同的 RPC 堆疊、相同的資料服務、相同的 API,但容量、主機和執行環境都是你自己的。像 Blockaid 這樣的團隊使用 Alchemy Dedicated Clusters 來保護超過 3,120 億美元的資產,滿足其客戶所需的效能與一致性。

正是這個差異,使得 dedicated 對一小部分工作負載而言物有所值,也使得 shared 成為其他所有情況下的正確預設選擇。真正該問的問題不是 dedicated 是否比較好,而是你的工作負載是否已經超出了 shared 基礎設施設計上能處理的範圍。

什麼是專屬區塊鏈基礎設施?

專屬區塊鏈基礎設施是一個單租戶的 RPC 與索引叢集:一組區塊鏈節點、路由基礎設施,以及運行在為單一工作負載保留的硬體上的資料服務。預設情況下,其 API 介面與 shared 基礎設施相同,因此既有的整合無需修改程式碼即可移植。客製化是在這個介面上做延伸,而非取代:客製化 tracer 與 binary、可選擇的地區,以及以容量計價而非按請求計費。

一個典型的叢集包含:

• 一組該鏈的完整節點,依客戶的尖峰請求速率再加一個額外節點來配置容量,這樣在節點重啟時 failover 不會導致流量中斷,也就是所謂的 N+1 模式。
• 可選的 archive 節點,用於歷史狀態存取,能提供從創世區塊起的完整狀態,而不僅是近期區塊。
• 位於節點池前方的邊緣代理與負載平衡器,作為路由層,接收每一個請求並決定由哪個節點來處理。
• 一套可觀測性堆疊,通常是 Grafana 儀表板,顯示節點健康狀態、請求延遲和錯誤率。
• 當叢集容量未能因應流量突增時,可切換至 shared 基礎設施的 failover 路徑。

這個基礎設施的形態,與 shared 供應商內部運行的架構相同。差別在於租用方式。Dedicated 代表容量是專屬承諾給單一客戶的,執行環境由客戶自行配置,且資料路徑不會與任何其他客戶的工作負載共用。

什麼時候工作負載需要 dedicated 基礎設施?

有四種工作負載模式會超出 shared 基礎設施能處理的範圍。

客製化 tracer 與 binary

EVM tracer 是用來檢測交易執行過程的函式,能擷取內部呼叫追蹤、儲存讀取、struct log 和 revert 原因。標準的 tracer,例如 callTracer 和 prestateTracer,已能涵蓋大多數分析需求。但安全工具、模擬引擎和鑑識平台需要更多:符合其內部 schema 的客製化 JavaScript tracer,或是經修改的 geth 和 erigon binary,能揭露 shared 供應商從未揭露過的執行狀態。

在 shared 主機上執行這些程式,對主機和租戶而言都不安全。這正是模擬與安全供應商運行 dedicated 叢集的原因。

地區限定的延遲

對大多數應用流量而言,多幾個網路跳點是無感的。但對於每秒發出數十個請求、且在意每一次延遲的工作負載來說,客戶端、節點與定序器之間的實際物理距離,可能決定一筆交易能否及時上鏈。

高頻交易、oracle 資料饋送,以及 MEV 搜尋者(從交易排序方式中擷取價值的機器人),都在這些微小的差距上競爭。Dedicated 叢集讓客戶能將節點池部署在與定序器或消費端相同的地區。

監管隔離

某些合規框架要求單租戶運算。SOC 2 Type II 對客戶資料隔離的控制要求、某些銀行與券商法規,以及大型金融機構的內部風險審查,通常都會匯聚到同一個要求:不得有其他客戶的工作負載運行在同一台主機上。

Shared 基礎設施在設計上就是讓多個客戶共用同一批主機。Dedicated 基礎設施則不是。

無上限的查詢範圍

Shared RPC 供應商會限制 eth_getLogs 的範圍,以保護叢集免受查詢炸彈攻擊。這對於讀取使用者近期交易的錢包來說沒有問題,這也是為什麼大多數分析工作負載會改走索引化的Data API,而非使用原始的 eth_getLogs。

但對於需要掃描大量歷史範圍原始 log 的區塊瀏覽器、索引器和鏈上分析團隊來說,這個上限就成了瓶頸。Dedicated 叢集可以解除這個限制,因為該限制本來就是為了保護其他租戶而存在,而在單租戶叢集上,並沒有其他租戶需要保護。

以下提供快速判斷的參考:

如果工作負載不符合上述四種 dedicated 模式中的任何一種,shared 基礎設施幾乎總是更便宜、更簡單,而且部署速度更快。

Dedicated 叢集如何運作?

Dedicated 叢集的架構取決於六個選擇:誰會共用這台機器、機器位於哪裡、有多少台機器、它們如何就狀態達成共識、運行什麼軟體,以及計費方式。

單租戶隔離

單租戶意味著客戶的節點運行在專屬保留給該客戶工作負載的運算資源上。實務上,合規審查通常會要求提供工作負載隔離、存取控制、可稽核性與金鑰處理的相關文件。

隔離所帶來的實際意義,在於它排除了哪些風險。共享主機上的吵鬧鄰居無法拖累客戶的尾端延遲,因為根本沒有鄰居。另一個租戶的側通道洩漏無法觸及客戶的程序。合規審查人員可以指出一份記錄在案的控制措施,而不必仰賴「我們相信供應商會把工作負載分開」這種說法。

地區部署

客戶端到 RPC 節點的延遲受網路距離所限制。對大多數應用流量而言,這是無感的。但對於頻繁發出延遲敏感請求的工作負載來說,將節點部署得更靠近堆疊、使用者、定序器或驗證者,可能就是產品競爭力強弱的關鍵。

我們為 197 個國家的客戶提供服務,Dedicated Clusters 讓你把節點池部署在工作負載需要的地區,無論是每個主要使用者地理區域配置一個叢集,還是為特定 rollup 配置一個與定序器同地部署的叢集。這是一種營運上的取捨:地區越多,需要監控、修補和付費的叢集就越多。大多數工作負載只需要一到兩個。

N+1 冗餘與 failover

Dedicated 叢集運行客戶目標容量再加一個備用節點。若任何節點發生異常或重啟,流量會轉移到備用節點,客戶不會察覺。這就是 N+1 模式,是任何需要在單一節點故障時仍維持可用性的服務所採用的標準架構。

較難處理的問題是,當負載超出叢集容量時會發生什麼事。有兩種實際情況會觸發這個問題:鏈上壅塞,即叢集的請求量因為鏈本身繁忙而暴增;以及客戶流量突增,可能來自活動、事件或某個整合上線。一個依穩定狀態負載配置容量的叢集,在遇到大規模突增時可能會被限流。

有兩種架構上的解法。一是依尖峰負載來配置叢集容量,這意味著大部分時間都要為閒置容量付費。另一種是自動 failover 到 shared 基礎設施:當叢集達到飽和時,流量會溢出到供應商的 shared 機隊,而不是回傳 429 錯誤。客戶使用的 API、認證方式和回應格式都維持不變。Failover 是更有效率的模式,但這要求 dedicated 供應商同時也要營運第一流的 shared 基礎設施。

區塊精確一致性

負載平衡池中不同的節點,對於最新區塊的認知可能會有數百毫秒的落差。最快的節點看到的是區塊 N,最慢的節點可能還停留在 N-1。對於查詢餘額的錢包來說,這是無感的。但對於透過不同節點兩次讀取同一區塊、卻得到不一致狀態的交易機器人來說,這就是一個真實存在的錯誤。

區塊精確一致性代表叢集在整個節點池中回傳一致的鏈上狀態視圖,讓有狀態的客戶端不會讀到過期或衝突的資料。這裡的取捨在於,叢集同時要為正確性和速度做最佳化,這在工作負載需要根據最新鏈上狀態做決策時尤其重要。

客製化 tracer 與 binary

有了 dedicated 執行環境,客戶就能運行客製化的 JavaScript tracer、部署修補過的 geth 版本、更換 client,或修改 shared 供應商全域固定的 client 設定。Shared 供應商無法開放這樣的介面,因為改變 client 版本或設定會影響主機上的每一位租戶。

這正是模擬、鑑識和分析產品得以建立的基礎能力。它們的價值來自於擷取標準 tracer 介面無法揭露的執行狀態。沒有 dedicated 執行環境,這樣的產品就不會存在。

以容量計價

Shared 基礎設施按請求計費,通常以每次呼叫的運算單位計算,較重的方法會有倍數加成。Dedicated 基礎設施則以叢集計價:針對承諾的容量收取固定月費,不論客戶實際發送多少請求。

這種計價模式適合具有可預測尖峰負載、且在大規模使用下原本會大量消耗 shared 運算單位的工作負載。在 dedicated 叢集上,額外請求的邊際成本為零,直到工作負載觸及叢集的容量上限。超過某個依工作負載而定的門檻後,以容量計價可能會比按請求計費更划算,而這還沒算上 dedicated 所解鎖的其他能力。

什麼時候 shared 是正確的預設選擇?

在 shared 與 dedicated 基礎設施之間做決定時,有三件事很重要。如需更深入了解這些取捨,請參閱我們關於如何在 Node RPC 與 Dedicated Clusters 之間做選擇的概覽文章。

Dedicated 本身不會讓 RPC 堆疊更快

底層的 RPC 堆疊是相同的,因此在系統閒置狀態下所做的單一請求基準測試,並不能反映全貌。當叢集部署在更靠近工作負載的位置時,dedicated 會改善延遲;而當隔離機制在持續負載下保護 P99(最慢的 1% 請求)時,dedicated 會改善可預測性。

若想了解目前各供應商 shared RPC 效能的公開比較,可參閱 Alchemy 的 RPC 供應商基準測試。

多地區的 shared 可能比單地區的 dedicated 更能撐過故障

一場導致單一地區叢集全面中斷的區域雲端故障,對全球分散式的 shared 機隊幾乎不會造成影響。務實的部署方式,是在關鍵地區搭配 dedicated,並以 shared 作為全域預設。

四種模式的檢驗標準很嚴格

如果工作負載沒有觸及客製化執行環境、地區需求、監管隔離或查詢範圍上限這四項之一,那麼 shared 會更便宜、更簡單,通常也更可靠。轉向 dedicated 通常是被迫的結果,而不是出於偏好。

Alchemy 如何支援專屬區塊鏈基礎設施?

大多數工作負載一開始就使用 shared,並且會一直維持下去。我們的 RPC API 和 Data API 運行在與 dedicated 相同的 Cortex 平台上,提供免費方案,不需要簽約,也沒有最低使用量的要求。從儀表板取得 API 金鑰,幾分鐘內就能開始發送請求。

當工作負載觸及四種模式之一,無論是客製化 tracer、地區需求、監管隔離,還是查詢範圍上限,Alchemy Dedicated Clusters 都能在相同的基礎設施上提供單租戶容量。我們支援客製化 tracer 與 binary、地區部署、具備自動 failover 至 shared 的 N+1 冗餘、區塊精確一致性、從第一天起就有的 Grafana 儀表板,以及符合 SOC 2 Type II 規範的基礎設施,適用於受監管的環境。計價方式以已配置的容量為基準,而非按請求使用量計算,因此負載可預測的團隊可以依固定的月度基礎設施成本來規劃。

Dedicated 叢集就是相同的基礎設施,只是範圍限定在你的工作負載上。如果 shared 基礎設施能滿足需求,就繼續使用 shared。如果你的工作負載屬於少數無法使用 shared 的情況之一,歡迎與我們的團隊聯繫。

常見問題

專屬區塊鏈基礎設施與 shared RPC 有什麼差異?

Shared RPC 讓多個客戶在一個受管理的機隊上共同運行。專屬區塊鏈基礎設施則為單一工作負載保留執行環境、容量與資料路徑。API 介面可以維持不變,但 dedicated 額外提供單租戶隔離、客製化執行環境選項、地區部署,以及以容量計價的模式。

可以在專屬 Ethereum 節點上運行客製化 tracer 嗎?

可以。Dedicated 叢集是單租戶的,因此可以運行 shared 端點無法託管的客製化 tracer。除了標準的 callTracer 和 prestateTracer,dedicated 執行環境還能部署你自己的 JavaScript tracer,或經過修改的 geth 或 erigon binary,以揭露標準介面不提供的執行狀態。這正是安全、模擬和鑑識團隊運行 dedicated 的原因。他們的產品依賴 shared 基礎設施在全域固定的追蹤能力。

Dedicated 基礎設施跟私有 RPC 端點是一樣的嗎?

不一定。私有 RPC 端點可能只是指在 shared 基礎設施上,為特定客戶設置的專屬網址或存取政策。Dedicated 基礎設施則更進一步:節點池與相關執行環境都專屬保留給單一客戶的工作負載。

什麼時候團隊應該避免使用 dedicated 基礎設施?

當工作負載不需要客製化 binary、監管隔離、特定地區部署,或異常大量的原始查詢範圍時,就應該避免使用 dedicated 基礎設施。在這些情況下,shared RPC 通常更簡單、更便宜、彈性更高,而且部署速度更快。

Dedicated 和 shared 基礎設施可以同時運行嗎?

可以。大多數使用 Dedicated Clusters 的團隊,都採用混合架構:對有硬性需求的鏈或工作負載使用 dedicated,其餘則使用 shared RPC。由於兩者的 API 相同,在兩者之間移轉工作負載主要只是端點與路由上的決定。

Dedicated 叢集的計價方式是如何運作的?

Dedicated 叢集依已配置的容量計價,而非按請求使用量計費。價格取決於鏈、節點類型、吞吐量、地區,以及所包含的功能。對於持續性的高負載工作負載,固定容量計價通常比按請求計費更容易預估成本。

Dedicated 叢集的部署需要多久時間?

部署所需時間取決於鏈、client、地區與設定。當需求屬於標準規格時,某些叢集可以很快部署完成。而較複雜的設定,例如客製化 binary、特殊硬體或新地區,則需要更多規劃時間。