邊緣層如何讓 Alchemy 上的 RPC 更快
作者：Uttam Singh
每年有數兆美元的價值透過區塊鏈基礎設施流動。Solana 上的一筆 DeFi 兌換、Ethereum 上的一筆穩定幣轉帳、Polygon 上的一筆預測市場結算：這些交易都仰賴 RPC 呼叫在抵達節點前經過多層網路傳輸。當金融活動搬到鏈上執行時，這條路徑上的每一毫秒都關係到資金風險。
對於一個服務超過 100+ 條區塊鏈網路、每年處理數兆次請求的基礎設施供應商來說，使用者與資料中心之間的那一層，正是效能勝負的關鍵所在。那一層就是邊緣層（edge）。2025 年底，Alchemy 將其徹底重建。
RPC 延遲對鏈上金融為何重要？
區塊鏈的使用者與應用程式分布在全球各地。新加坡的交易機器人、法蘭克福的錢包應用、維吉尼亞州的 DeFi 協議後端：它們都會發出 RPC 呼叫來讀取區塊鏈狀態並提交交易。這些呼叫解析得越快，體驗就越好。
在 DeFi 中，延遲會直接轉化為執行品質。較慢的 eth_call 意味著過時的價格資料。延遲的交易提交意味著較差的成交或交易失敗。對錢包應用而言，每多出 100 毫秒的載入時間，都會削弱留住使用者在鏈上活動的體驗。
但延遲只是問題的一半。可靠性同樣重要。如果你的 RPC 供應商將所有流量都導向單一第三方 CDN，這個 CDN 就成為單點故障。一旦它故障，每個網路、每個客戶、每個請求都會一同中斷。
什麼是 Alchemy Edge Proxy？
可以把 Edge Proxy 想成 Alchemy RPC 基礎設施的大門。無論是讀取 Ethereum 狀態、查詢 Solana 帳戶，還是在 Base 上提交交易，每一個 API 請求都會先經過這個入口層，才會抵達後端的服務基礎設施。
多年來，Alchemy 一直使用一家主要的 CDN 作為這道大門。CDN 之所以成為業界普遍的選擇是有原因的：它們開箱即用地提供 DDoS 防護、地理路由、WAF 規則以及 SSL 終止。對大多數網頁應用來說，這套組合已經足夠。CDN 已經有二十年的時間，從電子商務到串流媒體，都是預設的入口層選擇，這個地位是它們應得的。
鏈上金融的需求不同。RPC 流量突發、對延遲敏感、地理上遍及全球，且在安全性上的要求也是一般網頁流量所沒有的。一個平行讀取三條鏈狀態的交易機器人，不在乎 CDN 能不能在 50 個城市快取一個行銷頁面。它在乎的是從發出 eth_call 到收到回應之間的時間。一個同步餘額的錢包，不需要針對 SQL injection 的 WAF 規則。它需要的是最近的邊緣節點，以及能在個位數毫秒內完成的 TLS 交握。一個在衍生品交易所結算部位的協議，無法容忍以第三方 CDN 的事故處理時間，作為自身正常運行時間的上限。
為了滿足這些需求，我們在裸機（bare metal）上建構了自訂的邊緣代理（edge proxy）：一個從頭開始、專為高吞吐量、低延遲的區塊鏈 RPC 流量設計的入口層。它運行在 Alchemy 自行掌控、遍布全球多個地區的基礎設施上，以我們可以依網路個別調校的等效或更強的防護，取代每一層 CDN 防護，並徹底移除關鍵服務路徑上對第三方的依賴。
結果就是目前正式上線中，速度最快的區塊鏈 RPC 入口層。
Alchemy Edge Proxy 如何運作？
Edge Proxy 架構由兩個核心元件組成，運行在分布於全球多個地區（美國東部、美國西部、歐洲中部、東南亞等）的專用裸機伺服器上。
Istio Ingress Gateway
第一個元件是以 Envoy 作為資料平面的 Istio Ingress Gateway。它負責 TLS 終止、連線管理與請求代理。Envoy 正是在 Lyft、Google Cloud 與 AWS App Mesh 負載下運作的同一套代理。它的非同步非阻塞 C++ 核心、HTTP/2 多工，以及預先建立的上游連線池，使其非常適合高吞吐量、低延遲的入口場景。
Edge Proxy Control Plane（EPCP）
第二個元件是一個自訂的控制平面，以 ext_authz filter 的形式與 Envoy 並行運作。對於每一個傳入的請求，EPCP 都會評估：
- 根據 URL、標頭以及目標區塊鏈網路，決定請求要路由到哪裡
- 針對該請求，哪些後端叢集可用（例如：archive node 叢集、AWS 託管服務、特定地區端點）
- 該請求是否因安全或合規原因而應被封鎖
- 本地地區中哪些網路是健康的（透過健康檢查判斷）
接著 EPCP 會注入路由標頭，告訴 Envoy 該將請求轉發到哪裡。這樣的設計讓熱路徑（hot path）維持快速（由 Envoy 處理代理），同時讓路由邏輯保持彈性且可動態設定。
請求生命週期
以下是一個典型成功請求在系統中的流程：
- 客戶端向
*.g.alchemy.com發送 RPC 請求。 - 基於地理位置的 DNS 將請求解析至最近的 Edge Proxy 地區。
- Istio Ingress Gateway 接收請求，並透過 ext_authz 傳遞給 EPCP。
- EPCP 驗證請求（OFAC 檢查、安全規則），判斷目標叢集，並回傳路由標頭。
- Istio 將請求轉發至對應的後端。
- 回應直接回傳給客戶端。
基於地理位置的 DNS 路由
Edge Proxy 採用基於地理鄰近性的 DNS 解析。這代表 DNS 層與鏈、網路無關：無論是針對 Ethereum mainnet 還是 Solana mainnet 的請求，都會解析到同一個區域性的 Edge Proxy。Edge Proxy 本身則在內部處理具網路感知能力的路由。
這樣的設計有幾項優勢：
- 無論最終需要哪條區塊鏈網路，DNS 解析與 TLS 交握都會在最近的邊緣位置完成。
- 新增區塊鏈網路無需任何 DNS 變更。
- 地區性健康檢查在 Edge Proxy 層級執行。若某個 Edge Proxy 地區變得不健康，DNS 會自動容錯移轉至次近的地區。
動態設定
Edge Proxy 會從我們內部的設定平台拉取路由設定。這使得執行期變更無需重新部署即可生效：
regions:
us-east:
enabled: true
routes:
"/v2":
verbs: ["POST"]
destination: archive-cluster
fallbackRegions:
- us-west
- eu-central
- apac-southeast
security:
ipsBanned: ["..."]
pathsBanned: ["..."]若某個地區需要排空流量、某個網路需要重新路由，或需要套用新的安全規則，設定更新會直接生效，無需碰觸正在運行的代理。
沒有 CDN 的情況下，安全模型如何運作？
移除對 CDN 的依賴，意味著需要從頭重建每一項安全防護。Edge Proxy 以分層方式取代 CDN 原有的防護：
關鍵在於：這些防護並不比 CDN 的防護來得弱，只是更具針對性。Alchemy 掌控每一層，可以依網路個別調整閾值，出問題時也不需要仰賴第三方的事故應變時程。
Alchemy Edge Proxy 帶來了什麼成果？
Edge Proxy 於 2025 年 10 月間，在三週內推廣至 100+ 條區塊鏈網路，且完全不需要客戶進行遷移。成效立即顯現。
延遲
客戶端的遙測資料在各種不同工作負載下，也顯示出相近幅度的改善，其中對延遲最敏感的工作負載獲益最大。
若需目前公開的供應商數據，可比較各鏈、各地區與常用方法的 RPC 延遲基準測試。
可靠性
在同一段時間窗口內，若仍使用先前以 CDN 為前端的架構，本應會受到上游事故的影響，而 Alchemy 的基礎設施則完全未受波及。
這與其他基礎設施方案相比如何？
處理區塊鏈 API 基礎設施入口流量，常見有三種做法：
這種自訂邊緣代理，結合了直連的延遲優勢與 CDN 的防護與流量彈性，同時避免了兩者各自的供應商依賴與成本隨流量增加的問題。
部分 RPC 供應商已推出不依賴 CDN 的邊緣方案，但這類上線通常要求客戶在停用期限前遷移至新的端點。Alchemy Edge Proxy 則在不需要客戶採取任何行動的情況下，帶來了同等或更高的效能提升。
在最快的區塊鏈基礎設施上構建
Alchemy 的 Edge Proxy 只是為全球金融活動需求打造的平台中的一環。尾端延遲最高提升 7.5 倍、支援 100+ 條網路、跨多個大洲的多地區佈局，以及無需任何操作的效能升級：這一切都是 Alchemy RPC 端點開箱即有的能力。
無論你在構建的是 DeFi 協議、錢包、支付應用，還是面向金融機構的鏈上基礎設施，效能與可靠性都是最基本的要求。歡迎查看完整支援鏈列表、深入閱讀 Alchemy 開發者文件，或是建立免費帳號開始構建。
Alchemy 電子報
搶先掌握最新發布消息
訂閱我們的電子報
取得 Alchemy 最新產品更新與資源
輸入您的電子郵件地址，即表示您同意接收我們的行銷通訊與產品更新。您了解 Alchemy 會依照我們的隱私權聲明處理所收到的資訊。您可以隨時取消訂閱。
