--- title: "Alchemy 如何為鏈上金融服務提供動力" description: "金融應用程式以毫秒為單位評斷優劣。以下說明 Alchemy 的 RPC、Cortex、webhooks 及專屬基礎設施如何支援鏈上借貸、交易、支付與市場數據。" --- # Alchemy 如何為鏈上金融服務提供動力 金融應用程式是以毫秒為單位來評判的。 當使用者查詢儲蓄餘額、送出交易、等待存款入帳，或在市場劇烈波動時盯著一筆借貸部位，一個過時的答案跟一個錯誤的答案代價是一樣的。底層的鏈是去中心化的，但上層的產品卻要符合使用者從其他金融應用程式已經習慣的標準。 金融正在上鏈，基礎設施的問題也隨之而來。無論是借貸、交易所、穩定幣帳戶、匯款、投資組合工具，還是市場數據，我們都提供金融產品與鏈之間的連接：低延遲讀取、可靠的交易執行、即時事件推送、用於歷史查詢的存檔數據，以及需要獨立資源的團隊可用的單租戶專屬容量。我們也公開了一份[即時延遲基準測試](https://www.alchemy.com/benchmarks)，比較我們的 EVM 端點與 QuickNode、dRPC、Infura 的表現,連同[測試方法](https://www.alchemy.com/blog/how-we-benchmark-rpc-performance)和[原始數據](https://www.alchemy.com/benchmarks/data.md)一併公開,所以這項效能宣稱是可以查證的,而不是需要你單方面相信的。 ## 為什麼基礎設施決定金融產品能否正常運作？ 每個上鏈的金融產品,在使用者操作與鏈的回應之間都跑著一個循環,而這個循環有截止時間。 借貸平台必須在計算借款人健康指數之前知道抵押品的當前價值。交易所需要獨立確認一筆存款已經結算,才能將金額計入客戶帳戶。支付應用程式必須送出一筆穩定幣轉帳、追蹤它,並顯示新的餘額,同時不需要讓客戶去了解什麼是 gas。市場數據供應商必須以足夠快的速度發布價格,讓讀取這些數據的協定能夠即時使用。 這個循環中任何一個環節出了問題,都會表現為產品的失敗,而不是基礎設施的失敗。一筆錯過的交易。一筆卡住不動的存款。一個悄悄出錯的餘額。客戶不會把這歸類為「RPC 降級」。 這就是為什麼像 [Aave](https://www.alchemy.com/case-studies/how-aave-runs-largest-lending-protocol-alchemy)、[Bitget](https://www.alchemy.com/case-studies/bitget-deposit-verification-alchemy)、[Pana](https://www.alchemy.com/case-studies/pana-stablecoin-remittances-alchemy)、[Polymarket](https://www.alchemy.com/case-studies/polymarket)、[RedStone](https://www.alchemy.com/case-studies/how-redstone-keeps-price-feeds-reliable-across-51-chains)、[Symphony](https://www.alchemy.com/case-studies/how-symphony-built-rewards-driven-savings-app-on-alchemy)、[Solflare](https://www.alchemy.com/case-studies/solflare)、0x、Zapper 和 Zerion 這些團隊,會把延遲與可靠性當作產品需求來看待,而不只是供應商合約中的一個項目。 ## RPC 延遲如何影響交易執行與交易表現？ [RPC](https://www.alchemy.com/rpc-api) 延遲決定了金融產品讀取狀態與送出交易的速度下限,因此它會直接反映在報價的即時性、存款入帳時間,以及交易是否能以使用者看到的價格成交。RPC 端點是應用程式用來讀取區塊鏈狀態與送出交易所呼叫的介面。它增加的每一毫秒,都是使用者要多等的一毫秒,而在市場波動時,這段延遲正是滑價與報價過時的來源。 最快的請求,不一定是送往最近那台機器的請求。節點健康狀況每分鐘都在變化,流量模式也會變動。一個龐大的歷史查詢和一個簡單的餘額查詢,對基礎設施的需求不同,不應該互相搶佔同一份容量。 [Cortex](https://www.alchemy.com/cortex) 是我們平台底層負責處理這件事的引擎。它會將每個請求導向目前狀態良好、且適合該特定方法的容量,並隨著狀況變化而動態調整,而不是依循一張固定的路由表。相較於我們先前的架構,官方公布的提升幅度是速度快 2.5 倍、可靠性提高 5 倍、吞吐量提高 500 倍。 對金融產品來說,這些工作都在使用者感受到任何事之前就已經完成。在交易爆量的時候,報價畫面仍能保持反應靈敏。團隊重建歷史數據時,不會拖慢客戶所依賴的即時查詢。當某條路徑開始劣化,請求會在客戶察覺之前就轉移出去。 [Aave](https://www.alchemy.com/case-studies/how-aave-runs-largest-lending-protocol-alchemy) 在超過 20 個網路上運行 DeFi 中規模最大的借貸協定,其借貸業務從不暫停,過時的狀態意味著使用者會誤判自己的部位。改用 Cortex 之後,Aave 的索引與回填工作負載速度提升了 3 到 5 倍。當 Aave 的 API 流量飆升到每秒約 7 萬次請求時,我們毫無異常地承接了下來。 ## 什麼樣的區塊鏈基礎設施才足夠可靠,能用於金融服務？ 對金融工作負載而言,可靠性同時代表兩件事:請求成功執行,而且回傳的答案完整且正確。一個快速但錯誤的答案,比一個緩慢的答案更糟。 我們透過[多鏈 RPC](https://www.alchemy.com/rpc-api) 提供讀寫服務,透過存檔數據支援歷史查詢,並透過即時事件系統在活動結算的當下傳遞資訊,涵蓋這整個面向。團隊也可以觀察並調查自己的區塊鏈流量,這正是大多數問題在客戶回報之前就被發現的方式。 [Bitget](https://www.alchemy.com/case-studies/bitget-deposit-verification-alchemy) 服務超過 1.25 億名使用者,並將我們作為存款與提款的獨立確認層。他們自己的節點承擔大部分工作負載,我們則作為第二個、獨立於他們的真實來源,用於任何涉及客戶資金的環節,這樣一來,某個系統中的錯誤或延遲就不會在無聲無息中導致帳戶被錯誤入帳或扣款。在最近 30 天的觀察期間,Bitget 在 9 個網路上向我們發送了超過 2500 萬次請求,零錯誤。 這種設計值得仿效。任何單一供應商,包括我們在內,對一個涉及資金流動的產品來說都是單點故障。Bitget 的做法是:自行架設節點,並針對出錯代價高昂的工作流程,保留第二條獨立的路徑。 對 [RedStone](https://www.alchemy.com/case-studies/how-redstone-keeps-price-feeds-reliable-across-51-chains) 而言,可靠性就是市場的公正性。RedStone 為借貸市場、永續合約、穩定幣、外匯貨幣對,以及代幣化的真實世界資產提供價格數據,並在 2025 年 2 月將我們選為新鏈啟動時的首選 RPC 供應商。自那之後,我們已處理超過 120 億次請求,目前有 51 條鏈在我們的節點上實際運行 RedStone 的流量。其歷史累計的價格推送紀錄是 2680 萬筆上鏈交易,成功率達 99.999%。對於清算引擎所讀取的數據來源來說,這個成功率正是市場能否正常清算與否的關鍵差別。 ## 如何讓產品即時與鏈保持同步？ 保持同步最可靠的方式,是讓鏈主動把事件推送給你,而不是自己去輪詢,這正是 webhook 的作用:當符合條件的鏈上事件發生時,立即觸發送往你服務端的 HTTP 回呼。以固定週期輪詢多條鏈,意味著你要麼付出持續查詢的成本,要麼接受延遲,而且還得自行建置並維運這套輪詢基礎設施。 [Alchemy Webhooks](https://www.alchemy.com/webhooks) 解決了這個問題。團隊只需訂閱他們關心的事件,就能在活動發生的當下,即時更新自己的帳本、通知,以及介面。傳遞方式是至少送達一次,因此你這端一次暫時性的失敗,不會導致事件遺失。 [Slingshot](https://www.alchemy.com/case-studies/slingshot-webhooks) 原本建置了跨鏈存款追蹤系統,分散在 40 個獨立的 Google Cloud 服務中,一套系統用於 EVM 鏈,另一套用於 Solana。改用 Webhooks 取代後,只用了大約 20 行程式碼、一週時間就完成,最終得到一個單一的即時存款系統,零漏接。 ## 如何在不讓使用者等待的情況下載入歷史活動記錄？ 即時事件讓帳本保持最新,而歷史記錄則是客戶打開應用程式時所看到的內容:過去的轉帳紀錄、投資組合分析、多年的活動歷史。這些內容的載入速度,必須跟即時餘額一樣快。 [Solflare](https://www.alchemy.com/case-studies/solflare) 使用我們的 Solana Archive Method,為超過 400 萬名活躍使用者提供歷史活動與投資組合分析。存檔查詢速度比 Solflare 測試過的其他供應商快上最多 20 倍,回應時間在 200 毫秒以內,這也是為什麼使用者打開應用程式時,看到的是完整財務歷史的載入畫面,而不是一個轉個不停的讀取圖示。 ## 如何讓金融產品不再受區塊鏈本身的摩擦所影響？ 面向客戶的目標是:讓鏈的存在對客戶而言完全無感。使用者應該能夠在不先購買原生代幣的情況下完成付款,透過他們熟悉的簽署流程為帳戶入金,並在不碰任何網路設定的情況下完成一次儲蓄操作。 [可編程帳戶](https://www.alchemy.com/smart-wallets)是一種能夠內建自身規則的錢包,讓應用程式可以在帳戶層級移動資金並執行花費限制,而不必把每個機制都丟給使用者處理。[Gas 代付](https://www.alchemy.com/gasless-transactions)讓應用程式代替客戶支付網路手續費,並以美元計費。結合可靠的交易送出與即時狀態更新,團隊可以自行設計想要的流程,而結算依然在鏈上完成。 目前這一層承載了 EVM 與 Solana 上約 85% 的免 gas 交易,正常運行時間達 99.99%,回應時間在 50 毫秒以內。 [Pana](https://www.alchemy.com/case-studies/pana-stablecoin-remittances-alchemy) 使用我們的 RPC 與 gas 代付服務,支援 Base 和 Ethereum 上的穩定幣匯款、卡片入金與結算。它在不到六個月內達到超過 20 萬名使用者,每天處理數萬筆穩定幣交易。 [Symphony](https://www.alchemy.com/case-studies/how-symphony-built-rewards-driven-savings-app-on-alchemy) 已處理超過 5 億美元的交易量,並在六個網路上運行。在最近 30 天的觀察期間,我們為 Symphony 處理了超過 80 萬次請求,在每條設定正確的主網上成功率達 100%。 ## 哪些金融團隊在 Alchemy 上建置產品,他們測到了哪些成果？ Aave', tooltip: "", icon: "", }, workload: { title: "Lending protocol data, API, and indexing across 20+ networks", tooltip: "", icon: "", }, result: { title: "Indexing and backfills 3-5x faster on Cortex; API spikes above ~70k requests/sec absorbed without incident", tooltip: "", icon: "", }, id: 0, }, { team: { title: 'Bitget', tooltip: "", icon: "", }, workload: { title: "Independent deposit and withdrawal confirmation for 125M+ users", tooltip: "", icon: "", }, result: { title: "25M+ requests across 9 networks in a 30-day window, zero errors", tooltip: "", icon: "", }, id: 1, }, { team: { title: 'RedStone', tooltip: "", icon: "", }, workload: { title: "Price feeds for lending, perps, stablecoins, FX, and tokenized RWAs", tooltip: "", icon: "", }, result: { title: "99.999% success rate across 26.8M onchain price-push transactions, lifetime; 51 chains served", tooltip: "", icon: "", }, id: 2, }, { team: { title: 'Slingshot', tooltip: "", icon: "", }, workload: { title: "Cross-chain deposit detection on EVM and Solana", tooltip: "", icon: "", }, result: { title: "Replaced 40 Google Cloud services with ~20 lines of code; zero missed deposits", tooltip: "", icon: "", }, id: 3, }, { team: { title: 'Solflare', tooltip: "", icon: "", }, workload: { title: "Solana historical activity and portfolio analytics for 4M+ active users", tooltip: "", icon: "", }, result: { title: "Archive queries up to 20x faster than other providers tested; sub-200ms responses", tooltip: "", icon: "", }, id: 4, }, { team: { title: 'Pana', tooltip: "", icon: "", }, workload: { title: "Stablecoin remittances, card funding, settlement on Base and Ethereum", tooltip: "", icon: "", }, result: { title: "200,000+ users in under six months; tens of thousands of stablecoin transactions daily", tooltip: "", icon: "", }, id: 5, }, { team: { title: 'Symphony', tooltip: "", icon: "", }, workload: { title: "Rewards-driven savings app across six networks", tooltip: "", icon: "", }, result: { title: "$500M+ transaction volume; 800k+ requests in 30 days at a 100% success rate on correctly configured mainnets", tooltip: "", icon: "", }, id: 6, }, ], }} /> ## 該如何評估一家基礎設施供應商是否適合金融工作負載？ 要求對方提供你可以自行重現的數字,然後用你自己的流量去驗證。供應商的行銷文宣不是基準測試,單一張截圖也不是。 在簽約之前,有四件事值得檢查。 ### 你所用方法在你所在地區的延遲 平均數會掩蓋真正重要的慢請求。用你產品實際依賴的方法,從你使用者所在的地區去測試,並看 p95,而不是平均值。我們的[基準測試方法](https://www.alchemy.com/blog/how-we-benchmark-rpc-performance)文件詳細說明了我們的測試方式,包括地區、逾時規則,以及什麼算是失敗,方便你對任何供應商複製同樣的測試設定。 ### 負載下的成功率,而非靜止狀態下的成功率 一個在基準狀態下很快、但在波動高峰時開始漏接請求的供應商,並不適用於金融場景。要以你預期的峰值進行壓力測試,然後再乘以兩倍去測。 ### 失效行為 當某個節點狀態劣化時會發生什麼事?流量轉移出去的速度有多快?在查看供應商的首頁之前,先查看它的[狀態頁面](https://status.alchemy.com/)與事故歷史。 ### 需要時的隔離性 共享端點會讓你的流量與其他人的流量混在一起。[Dedicated Clusters](https://www.alchemy.com/dedicated-clusters) 是單租戶架構,符合 SOC 2 Type II 規範,並可部署在離你的使用者或撮合引擎最近的區域。切換到共享 RPC 容量是選擇性的,用於承接超出叢集容量之上的流量。這一點對交易系統,以及任何不容許「吵雜鄰居」造成變數的工作負載來說,格外重要。 ## 為正在上鏈的金融體系而建置 在我們這裡建置產品的金融團隊,各自在解決不同的問題。有些在擴大信貸的普及性,有些在降低跨境支付的成本,有些則提供市場數據、交易工具、託管服務或投資組合智慧分析。 連結這些團隊的,是他們自己客戶對他們的要求:快速的回應、能夠順利完成的交易,以及一個真正值得託付資金的產品。隨著愈來愈多結算、交易與投資活動移到鏈上,這項標準會直接傳遞到底層的基礎設施上,因為客戶所體驗到的「付款已確認」或「餘額正確」,歸根究底,取決於這條鏈的連接是否穩固。 我們為團隊提供一個統一的基礎,涵蓋低延遲區塊鏈存取、具韌性的交易基礎設施、即時數據、單租戶專屬容量,以及可直接面向客戶的執行流程,並支援他們擴展到的每一條鏈。 Aave 自 2021 年起就在我們這裡運行其借貸流量,經歷了每一次網路擴展、每一個創紀錄的存款日,而它的使用者從來不需要知道我們的存在。這就是我們的工作。 [在 Alchemy 上建置金融產品。](https://www.alchemy.com/fintech) ## 常見問題 ### Alchemy 可靠嗎?它的正常運行時間紀錄如何? Alchemy 公布的正常運行時間為 99.995%,同時每年保障超過 1 兆美元的交易量,並在[狀態頁面](https://status.alchemy.com/)上公開事故歷史。經客戶驗證的證據包括 Bitget 在 9 個網路上發送 2500 萬次請求、零錯誤,以及 RedStone 99.999% 的價格推送成功率。 ### Alchemy Cortex 是什麼? [Cortex](https://www.alchemy.com/cortex) 是驅動 Alchemy 開發者平台的智慧型區塊鏈引擎。它會將每個請求導向適合該特定方法、且目前狀態良好的容量,並隨著節點健康狀況與流量的變化而動態調整,而不是依循靜態的路由規則。Alchemy 公布的結果是,相較於先前的架構,速度快 2.5 倍、可靠性提高 5 倍、吞吐量提高 500 倍。 ### RPC 延遲如何影響交易執行與交易表現? RPC 延遲決定了應用程式讀取鏈上狀態與送出交易的速度下限。延遲越高,報價就越容易過時,存款入帳越慢,交易成交價格也會比使用者看到的更差。對交易系統而言,你所在地區的 p95 延遲,比全球平均值更重要。 ### 我該期待企業級 RPC 供應商提供什麼樣的 SLA? Alchemy 的 Enterprise 方案附帶簽署的 SLA,正常運行時間與回應時間的承諾依合約個別協商,而不是以單一公開數字呈現。無論向哪家供應商詢問,都要問清楚四件事:正常運行時間數字、測量週期、排除條款,以及未達標時的補償機制。沒有這些內容的百分比,都不算是真正的 SLA。 ### 生產環境中只依賴單一 RPC 供應商有什麼風險? 對任何涉及資金流動的事物來說,單一供應商就是單點故障。Bitget 的做法是個不錯的範本:自行架設節點承擔大部分流量,並保留第二個獨立的供應商,作為存款、提款,以及任何出錯代價高昂的工作流程的另一個真實來源。 ### 哪個區塊鏈 API 提供最可靠的 webhook 傳遞? [Alchemy Webhooks](https://www.alchemy.com/webhooks) 保證至少送達一次,因此你這端一次暫時性的失敗不會變成事件遺失。Slingshot 原本橫跨 40 個 Google Cloud 服務的跨鏈存款追蹤系統,改用大約 20 行程式碼取代後,在 EVM 鏈與 Solana 上都實現了零漏接。 ### 選擇 RPC 供應商之前該如何進行基準測試? 用標準付費帳戶,針對你產品實際呼叫的方法,從你使用者所在的地區進行測試,不使用重試機制,並設定固定的逾時時間。回報 p95 數值,連同平均值一起呈現,並把成功率與延遲分開來看。Alchemy 的[基準測試方法](https://www.alchemy.com/blog/how-we-benchmark-rpc-performance)文件說明了一套你可以對任何供應商複製的測試設定。 ### 高流量穩定幣支付基礎設施,該選 Alchemy 還是 QuickNode? 兩者都在大規模承載生產環境的穩定幣工作負載。真正有意義的比較,是針對你所用方法的實測延遲、在你的流量高峰下的成功率,以及交易送出與 gas 代付是否來自跟你讀取請求相同的供應商。Alchemy 的[即時基準測試](https://www.alchemy.com/benchmarks)公開了相對於 QuickNode 的數字,測試方法與原始數據都完全公開。 ### 哪家供應商提供單租戶專屬節點與區域部署? [Alchemy Dedicated Clusters](https://www.alchemy.com/dedicated-clusters) 是單租戶架構,符合 SOC 2 Type II 規範,不與任何人共享流量或運算資源。它們可以部署在最靠近你的系統或使用者的區域,以降低延遲。切換到共享 RPC 容量是選擇性的,用於承接超出叢集容量之上的流量。