Bitget 如何使用 Alchemy 為交易所的 1.25 億用戶提供服務

當加密貨幣交易所要確認使用者的存款是否確實上鏈時,沒有「大概」的空間。Bitget 是一個服務超過 1.25 億使用者的全球交易所與 web3 生態系統,將存款與提款驗證視為關鍵的金融基礎設施。為了消除這條驗證路徑上的單點故障,Bitget 導入了 Alchemy 業界領先的 RPC APIs。

設置方式:多層次存款驗證

Bitget 的大部分區塊鏈讀取作業都在自建節點上執行,讓團隊能直接掌控核心基礎設施。在涉及使用者資金移動的流程中,Bitget 將這種掌控力與獨立確認機制搭配使用:由第三方節點供應商交叉驗證自家節點回傳的資料,唯有在多個來源一致時,存款才會入帳。

隨著 Bitget 規模擴大,團隊決定強化這層確認機制的穩健性。有兩個因素形塑了團隊的需求:

• 自建的全節點只保留近期區塊的短暫區間,大約是最近 128 個區塊,因此單靠這些節點無法提供團隊重建舊交易或從區塊中擷取內部交易所需的歸檔與追蹤資料。
• 現有的第三方供應商在流量尖峰時會回傳速率限制錯誤,而這正是存款確認最關鍵的時刻。

為了同時提升這兩方面的水準,Bitget 導入了 Alchemy,看中的是其效能與可靠性,能在 Bitget 最敏感的工作流程上維持快速且穩定的確認。

解決方案:備援且可靠的基礎設施

Bitget 的架構刻意採用備援設計:自建節點承擔大部分流量,並由兩個獨立的第三方供應商確認涉及使用者資金的資料。整體分為三層:

獨立驗證層

Bitget 將存款與提款確認流量導向 Alchemy,作為對照自家節點的平行檢查。當兩個獨立來源一致時,交易所便能有信心地將存款入帳。若其中一個來源被限流或資料不同步,另一個來源仍能回應。正是這一層,消除了 Bitget 原本要解決的單一供應商風險。

歸檔與追蹤層

由於 Bitget 自家節點只保留短暫的區塊區間,團隊仰賴 Alchemy 的歸檔深度與追蹤方法來重建交易細節並擷取內部交易,使用的呼叫包括 trace_block、debug_traceBlockByNumber、eth_getBlockReceipts 和 eth_getLogs。這些是其自建基礎設施在結構上無法提供的資料。

多鏈覆蓋層

Bitget 透過單一供應商驗證跨越廣泛且持續成長的多個網路上的活動,包括 BNB Smart Chain、Bitcoin、Base、Arbitrum、zkSync 等,並由 Alchemy 的 Bitcoin API 支援涵蓋最難妥善營運的非 EVM 鏈。亞太區的覆蓋範圍也是決策的一環,Alchemy 在東京的據點正好對應 Bitget 大部分流量的來源地。

成果:30 天內超過 2500 萬次請求,零錯誤

在最近 30 天的期間內,Bitget 透過 Alchemy 在 9 個網路上處理了超過 2500 萬次請求。導入 Alchemy 後,Bitget 讓存款驗證的關鍵路徑不再依賴單一節點來源,而是由獨立來源交叉確認,藉此提升了安全標準。

最終,Bitget 選擇 Alchemy 的原因在於:

• 鏈與區域覆蓋範圍: 單一供應商即可涵蓋多條 EVM 鏈與 Bitcoin,包括自建節點無法提供的歸檔與追蹤資料,以及貼近 Bitget 流量來源的亞太區覆蓋。
• 大規模下的可靠性: 在確認使用者資金這項工作負載上,供應商已證明能在數千萬次請求規模下保持可靠。
• 妥善處理困難的基礎設施: 追蹤與內部交易方法、Bitcoin RPC,以及高吞吐量支援——這些都是節點基礎設施中自行營運難度較高的部分。
• 文件與支援: 在評估與整合過程中,擁有直接且回應迅速的合作關係。

使用 Bitget 信賴的同一套區塊鏈基礎設施來驗證使用者資金,開始建置。立即開始,或聯繫我們的團隊。