交易團隊為什麼選擇 Alchemy 的低延遲 RPC
作者:Alchemy

一筆鏈上交易,從必須在價格變動之前送達的市場數據開始。接著訂單必須成交,即使交易量突然放大;資金也必須在事後與鏈上紀錄核對一致。
預測市場、交易所、DEX 基礎設施、交易應用程式和市場數據提供方,都在 Alchemy 上完成這項工作。他們選擇我們,是因為尖峰負載下的低延遲、所交易鏈上的可靠基礎設施,以及協助調校技術堆疊的工程師。
交易團隊為什麼選擇 Alchemy?
交易團隊選擇 Alchemy,是因為我們涵蓋這項工作的兩端:市場變動時的低延遲讀寫,以及資金結算時完整、可靠的紀錄,即使在交易量高峰也是如此。
可以把它看成交易公司的兩張桌子:前台需要速度,後台需要確定性。兩邊都透過 RPC 節點到達鏈上。RPC 節點是回應應用程式請求的伺服器,用來讀取區塊鏈數據並提交交易。
Alchemy 如何在真實負載下維持低延遲?
我們在規模上路由每一個請求,從而穩定地服務各個團隊;對尖峰極高的團隊,我們會圍繞他們的流量調整路由和容量。平台底層的引擎 Cortex 會在交易者察覺之前,把流量從已經變差的路徑上移開。
Polymarket 在測試了多家 RPC 提供方之後選擇了我們。2024 年美國總統辯論期間,它服務了超過 12.5 萬併發使用者;整個選舉期間,有 33 億美元的投注經過該平台。我們按 p99 延遲(最慢的 1% 請求)重新路由它的請求,並增加了兩組專用節點叢集。Cortex 把它關鍵數據擷取的延遲從約 250ms 降到了約 100ms。
「與 Alchemy 合作至關重要。親自支援、對我們功能需求的快速回應,以及對我們規模的關注——Alchemy 始終做得更多。他們不只是基礎設施提供方。他們是我們團隊的一部分。」
— Rodrigo,Polymarket 平台負責人 · 閱讀 Polymarket 案例研究
0x 為去中心化交易所以及自己的交易應用程式 Matcha 路由流動性。在測試了可用的平台之後,它認定我們是唯一可以依靠的一家。在 Alchemy 上,它在一秒內產生報價,正常運作時間為 99.9%。
Alchemy 如何讓交易基礎設施保持可靠?
我們運行交易團隊寧可不自己維運的那一層:Hyperliquid 上的 HyperEVM 節點、Solana gRPC 串流,以及交易所用於結算的存檔數據和 trace 數據。
Valantis 在 Hyperliquid 上建構交易產品。它自架的 HyperEVM 節點一週會當機好幾次,每次故障都可能讓交易者無法開倉或平掉定期定額(DCA)部位。遷到我們的 HyperEVM Node 之後,Valantis 回報 RPC 請求成功率為 100%。
「我們需要基礎設施正常運作,才能繼續專注於打造出色的交易體驗。Alchemy 給了我們更可靠的基礎,以及一個在我們需要時能迅速幫忙的團隊。」
— Deven Matthews,Valantis CEO · 閱讀 Valantis 案例研究
服務超過 1.25 億使用者的 Bitget,只有在獨立來源一致時才記入一筆入金,而我們是 9 個網路上的來源之一。它自己的全節點只保留大約最近 128 個區塊,因此依賴我們的存檔數據(完整鏈歷史)和 trace 方法(逐步重放交易)。30 天裡,Bitget 向我們發送了超過 2500 萬次請求,錯誤為零。
Alchemy 的團隊如何協助交易團隊調校基礎設施?
本文中的大多數團隊都把支援列為選擇我們的原因。我們的工程師直接處理問題,和每個團隊自己的工程師一起工作。
向交易終端和代理推送市場數據的 Struct,在選擇我們之前對多家提供方做了基準測試。它運行在我們的 Node API 和 WebSockets 上,並在增加網路時依靠我們的支援。
「與 Alchemy 合作,為 Struct 提供了我們的資料管線所需要的穩定性。再加上親手的開發者支援,我們就能把精力放在盡全力服務客戶上。」
— Elliot,Struct CEO · 閱讀 Struct 案例研究
在 Alchemy 上開始建構交易使用情境
我們為尖峰負載下的低延遲讀寫而建構,外加後台所依賴的存檔、trace 和串流數據,涵蓋你交易的每一條鏈。
常見問題
哪家 RPC 提供方最適合 Hyperliquid?
Alchemy 運行遵循標準 Ethereum 節點規格的 HyperEVM Node,因此既有服務可以遷過來,而不必換一套維運模式。Valantis 把它的 Hyperliquid 交易後端從自架節點一次遷移一個服務到 Alchemy,並回報此後 RPC 請求成功率為 100%。先用你自己的方法測試任何提供方。
Solana 交易應用程式在 RPC 提供方上應該看什麼?
在請求-回應式 RPC 之外,還要看 gRPC 串流。Alchemy 的 Solana gRPC 相容 Yellowstone,因此既有客戶端換一個 URL 就能遷過來。每個訂閱會扇出到多個上游節點,重新連線後會回補遺失的數據,端點運行在 US East、US West、EU Central 和 Asia-Pacific。
加密貨幣交易所為什麼會使用不止一家 RPC 提供方?
單一提供方就是使用者資金的單點故障。Bitget 運行自己的節點,只有在獨立來源一致時才記入入金,Alchemy 是這些來源之一。30 天裡,Bitget 向 Alchemy 發送了跨 9 個網路的超過 2500 萬次請求,錯誤為零。
哪些 RPC 提供方支援存檔和 trace 數據?
Alchemy 提供存檔數據,以及 trace_block 和 debug_traceBlockByNumber 等 trace 與 debug 方法。Trace API 可在隨用隨付和 Enterprise 方案中使用。標準全節點只保留最近的區塊,大約是最後 128 個,因此無法重建更早的交易。Bitget 用這些數據核對入金。
Alchemy 電子報
搶先掌握最新發布消息
訂閱我們的電子報
取得 Alchemy 最新產品更新與資源
輸入您的電子郵件地址,即表示您同意接收我們的行銷通訊與產品更新。您了解 Alchemy 會依照我們的隱私權聲明處理所收到的資訊。您可以隨時取消訂閱。
相關文章

推出 Dashboard AI 助理
Ask Alchemy 現已在 Dashboard 中上線。以日常語言即可除錯請求、查看用量並管理您的設定。

HyperCore 串流現已在 Alchemy 開放搶先體驗
透過 WebSocket 串流 Hyperliquid 訂單簿、最佳買賣報價與成交明細,使用的就是你目前用於 HyperEVM RPC 的同一個 Alchemy 帳戶與 API key。

Alchemy 如何為穩定幣支付提供動力
一筆付款要嘛到帳,要嘛沒到帳。本文介紹 Cash App、Slash、AllScale、Pana 與 Usual 如何在 Alchemy 上運行穩定幣支付的鏈上部分。