專屬區塊鏈基礎設施的運作原理

大多數正式環境的工作負載在共享區塊鏈RPC infrastructure上都能正常運作。但有一小部分無法。例如某交易台，其與 sequencer（rollup 的交易排序服務）之間的往返延遲，決定了訂單能否被納入下一個區塊。或是某安全公司，其模擬引擎需要執行自訂的 EVM tracer，而共享供應商不會提供這種託管方式。又或是某受監管的金融科技公司，其合規團隊不會核准與其他客戶工作負載共用硬體。

對這些工作負載而言，答案是dedicated blockchain infrastructure。

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

這項區別，正是 dedicated 對少數特定工作負載而言值得投入成本的原因，也是共享基礎設施對其他所有人而言仍是正確預設選項的原因。真正該問的問題不是 dedicated 是否比較好，而是你的工作負載是否已經超出共享基礎設施所設計要處理的範圍。

什麼是 dedicated blockchain infrastructure？

Dedicated blockchain infrastructure 是一個單租戶的 RPC 與索引叢集：由一批區塊鏈節點、路由基礎設施和資料服務組成，並運行在為單一工作負載保留的硬體上。預設情況下，其 API 介面與共享基礎設施相同，因此現有整合無需修改程式碼即可移植。客製化是在此介面之上擴充，而非取代它：包括自訂 tracer 與 binary、可選擇的地區，以及以容量計費而非按請求計費。

一個典型的叢集包含：

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

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

什麼時候工作負載需要 dedicated infrastructure？

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

自訂 tracer 與 binary

EVM tracer 是用來檢測交易執行過程的函式。它們會擷取內部呼叫追蹤、儲存讀取、struct log 與 revert 原因。標準 tracer，例如 callTracer 與 prestateTracer，能滿足大多數分析需求。但安全工具、模擬引擎與鑑識平台需要更多：客製化的 JavaScript tracer，以符合它們內部的 schema，或是經過修改的 geth 與 erigon binary，以揭露共享供應商從不對外提供的執行狀態。

在共享主機上執行這些工具，對主機或租戶而言都不安全。這正是模擬與安全供應商採用 dedicated 叢集的原因。

地區限制的延遲

對大多數應用程式流量而言，多幾跳的網路傳輸幾乎無感。但對每秒發出數十次請求、且在意每一次延遲的工作負載而言，客戶端、節點與 sequencer 之間的實體距離，可能決定一筆交易是否能及時納入區塊。

高頻交易、oracle feed，以及 MEV searcher（透過交易排序方式從中擷取價值的機器人），都在這些微小的差距上競爭。Dedicated 叢集讓客戶能將節點池部署在與 sequencer 或消費端相同的地區。

法規上的隔離要求

某些合規框架要求單租戶運算環境。SOC 2 Type II 中關於客戶資料隔離的控制項目、某些銀行與券商的監理制度，以及大型金融機構內部的風險審查，往往都會指向同一項要求：不能有其他客戶的工作負載運行在同一台主機上。

共享基礎設施本質上就是設計為讓多個客戶運行在相同主機上。Dedicated infrastructure 則不是如此。

無上限的查詢範圍

共享 RPC 供應商會限制 eth_getLogs 的範圍，以保護叢集免受 query bomb 影響。對於讀取使用者近期交易的錢包來說，這樣的限制沒有問題，這也是為什麼大多數分析類工作負載會改用具索引的 Data API，而非直接使用原始的 eth_getLogs。

但對於需要掃描大範圍歷史原始 log 的區塊瀏覽器、索引器與鏈上分析團隊而言，這項限制就成了瓶頸。Dedicated 叢集可以解除此限制，因為這項限制存在的目的是保護其他租戶，而在單租戶叢集上並不存在需要保護的其他租戶。

以下提供快速判斷參考：

如果一個工作負載不符合這四種 dedicated 模式的任何一種，共享基礎設施幾乎總是更便宜、更簡單，也能更快上線。

Dedicated 叢集如何運作？

Dedicated 叢集的架構取決於六項選擇：誰會與你共用同一台機器、機器部署在哪裡、需要多少台、它們如何就狀態達成共識、執行什麼軟體，以及計費方式。

單租戶隔離

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

這種隔離帶來的實際意義在於它排除了哪些風險。共享主機上的吵雜鄰居無法拖累客戶的尾端延遲，因為根本沒有鄰居。其他租戶的側通道洩漏也無法波及客戶的處理程序。合規審查人員可以直接指出一項有文件記錄的控制措施，而不必只是說「我們相信供應商會把工作負載分開」。

區域部署

客戶端到 RPC 節點的延遲，受限於網路距離。對大多數應用程式流量而言，這幾乎無感。但對於發出頻繁、延遲敏感請求的工作負載而言，將節點部署得更靠近堆疊、使用者、sequencer 或驗證者，可能就是產品是否有競爭力的關鍵差異。

Dedicated 叢集讓客戶可以自行選擇地區。常見的做法是為每個主要使用者所在地區部署一個叢集，或是為特定 rollup 部署一個與 sequencer 同地區的叢集。這樣的取捨在於營運面：地區越多，需要監控、修補與付費的叢集也越多。大多數工作負載只需要一到兩個地區。

N+1 冗餘與 failover

Dedicated 叢集運行的容量是客戶目標容量再加一台備援節點。若有任何節點效能下降或重啟，流量會自動轉移到備援節點，客戶不會察覺任何異狀。這就是 N+1 模式，是任何需要在單一節點故障時仍維持可用性的服務所採用的標準架構。

較難處理的問題是，當負載超出叢集容量時該怎麼辦。有兩種真實情境會觸發這個狀況：鏈壅塞，即因為鏈上活動繁忙而導致叢集請求量激增，以及客戶端流量激增，例如活動、行銷或某項整合上線所導致。一個依穩定狀態負載規劃的叢集，在大規模流量激增時可能會被限速。

有兩種架構上的解法。一種是依尖峰負載來規劃叢集容量，這代表大部分時間都要為閒置容量付費。另一種是自動 failover 至共享基礎設施：當叢集達到飽和時，流量會溢出到供應商的共享機群，而不是回傳 429 錯誤。客戶端使用的仍是相同的 API、相同的驗證方式，以及相同的回應格式。Failover 是效率較高的做法，但這要求 dedicated 供應商同時也要營運一流水準的共享基礎設施。

區塊層級的一致性

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

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

自訂 tracer 與 binary

在 dedicated 執行環境中，客戶可以執行自訂的 JavaScript tracer、部署經修補的 geth 版本、更換 client，或修改共享供應商全域固定不變的 client 設定。共享供應商無法開放這項功能，因為變更 client 版本或設定會影響同一主機上的每一個租戶。

這正是模擬、鑑識與分析類產品得以建構的能力基礎。這些產品的價值來自於擷取標準 tracer 介面無法揭露的執行狀態。若沒有 dedicated 執行環境，這類產品根本無法存在。

以容量計費

共享基礎設施依請求計費，通常是每次呼叫收取一定的運算單位，較重的方法會有倍數加成。Dedicated infrastructure 則是依叢集計費：不論客戶發出多少請求，每月固定收取所承諾容量的費用。

這種計費模式適合負載尖峰可預測、且在共享架構下大量消耗運算單位的工作負載。在 dedicated 叢集上，只要工作負載尚未觸及叢集上限，額外請求的邊際成本就是零。超過某個特定工作負載的門檻後，以容量計費甚至在不考慮 dedicated 所帶來其他能力的情況下，就可能比按請求計費更划算。

什麼時候共享基礎設施才是正確的預設選項？

在共享與 dedicated infrastructure 之間做選擇時，有三件事需要考量。若想深入了解其中的取捨，可參考我們關於如何在 Node RPC 與 Dedicated Clusters 之間做選擇的總覽文章。

Dedicated 本身不會讓 RPC 堆疊更快

底層的 RPC 堆疊是相同的，因此在系統負載較輕時做單一請求的效能測試，並不能反映完整情況。當叢集部署得更靠近工作負載時，dedicated 能改善延遲；而在持續高負載下，隔離能保護 P99（最慢 1% 的請求），這時 dedicated 能提升穩定性與可預測性。

若想查看目前各供應商共享 RPC 效能的公開比較，可參考 Alchemy 的 RPC provider benchmarks。

多地區的共享架構，其存活能力可能勝過單地區的 dedicated 架構

單一地區的雲端服務中斷，若發生在單地區的叢集上會造成明顯影響，但對全球分散式的共享機群而言幾乎無感。務實的部署方式，是在關鍵地區採用 dedicated，同時以共享架構作為全域預設方案。

四種模式的判斷標準相當嚴格

如果工作負載不符合自訂執行環境、地區需求、法規隔離，或查詢範圍上限這四種情況中的任何一種，共享基礎設施會更便宜、更簡單，通常也更可靠。轉向 dedicated 通常是被迫的選擇，而非單純的偏好。

Alchemy 如何支援 dedicated blockchain infrastructure？

大多數工作負載一開始就採用共享架構，並持續使用下去。我們的 RPC API 與 Data API 運行在與 dedicated 相同的 Cortex 平台上，提供免費方案，無需簽約，也沒有最低使用量要求。只要從控制台取得 API 金鑰，幾分鐘內就能開始發送請求。

當工作負載符合四種模式之一——自訂 tracer、地區需求、法規隔離，或查詢範圍上限——Alchemy Dedicated Clusters 便能在相同的基礎設施上，提供單租戶的專屬容量。我們支援自訂 tracer 與 binary、地區化部署、具自動 failover 至共享架構的 N+1 冗餘、區塊層級的一致性、從第一天起就提供的 Grafana 儀表板，以及符合 SOC 2 Type II 標準、適用於受監管環境的基礎設施。計費是根據所配置的容量，而非按請求使用量計算，因此負載可預測的團隊能依固定的每月基礎設施成本進行規劃。

Dedicated 叢集是相同的基礎設施，只是範圍限定給你的工作負載。如果共享基礎設施能滿足需求，就繼續使用共享架構即可。如果你的工作負載屬於少數無法適用共享架構的情況，歡迎聯絡我們的團隊。

常見問題

Dedicated blockchain infrastructure 與共享 RPC 有什麼差別？

共享 RPC 讓多個客戶共用同一套受管理的機群。Dedicated blockchain infrastructure 則是將執行環境、容量與資料路徑保留給單一工作負載使用。API 介面可以維持相同，但 dedicated 額外提供單租戶隔離、客製化執行環境選項、地區化部署，以及以容量計費的方式。

Dedicated infrastructure 是否等同於私有 RPC 端點？

不一定。私有 RPC 端點可能只是指共享基礎設施上，為特定客戶提供的專屬 URL 或存取政策。Dedicated infrastructure 則更進一步：節點池與相關執行環境完全保留給單一客戶的工作負載使用。

什麼情況下團隊應避免使用 dedicated infrastructure？

當工作負載不需要自訂 binary、法規隔離、特定地區部署，或異常龐大的原始查詢範圍時，就應避免使用 dedicated infrastructure。在這些情況下，共享 RPC 通常更簡單、更便宜、彈性更高，也能更快上線。

Dedicated 與共享基礎設施可以同時並用嗎？

可以。大多數使用 Dedicated Clusters 的團隊都採取混合架構：針對有硬性需求的鏈或工作負載使用 dedicated，其餘則使用共享 RPC。由於兩者的 API 相同，在兩者之間搬移工作負載，主要只是端點與路由設定上的調整。

Dedicated 叢集的計費方式是什麼？

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

Dedicated 叢集需要多久才能佈建完成？

佈建所需時間取決於鏈、client、地區與設定內容。若需求屬於標準規格，某些叢集可以快速部署完成。若涉及較複雜的設定，例如自訂 binary、特殊硬體，或新的地區，則需要更多規劃時間。