打造應用程式可靠性：Web3 成功的關鍵

許多團隊的 web3 應用程式注定失敗。

為什麼？

因為應用程式完全依賴節點，而節點極難維護。以下是部分原因：

1. 節點可靠性無法憑空建立；可靠性必須同時兼顧節點的可擴充性與資料準確性
2. 節點的設計初衷並非全規模的正式環境解決方案
3. 節點被期望要做的事情太多
4. 節點需要全職維護
5. 節點的效能取決於能否成功應對時間難以預測的網路升級或硬分叉

這些複雜因素讓節點難以管理與維護。

但有兩個架構面向能大幅提升節點可靠性，也就是使用者在需要時能成功與你的應用程式互動的能力：

• 異質性（Heterogeneity）：多樣且互補的系統，能夠處理不同類型的請求
• 冗餘性（Redundancy）：備援系統，讓其中一個系統故障時，其他系統仍能運作

在 web3 中，缺乏可靠性可能帶來嚴重後果。

以一個使用不可靠基礎設施的知名 NFT 交易平台 為例……

他們的平台並不穩定，導致：

• 沉重的工程負擔
• 使用者體驗下降
• 單一季度內超過 190 小時的停機時間

造成的影響是什麼？損失了 600 萬美元的營收。

別讓這種事發生在你身上。

本文將說明：

1. 為何維持節點可靠性如此困難
2. 常見的節點基礎設施模式，以及它們為何會失敗
3. Alchemy 如何應對可靠性挑戰，並在規模化下建立可靠性

為何維持節點可靠性如此困難

在 web3 中，可靠性特別難以維持，主要有五個原因：

(1) 節點可靠性無法憑空建立；可靠性必須同時兼顧節點的可擴充性與資料準確性

要打造功能完善的應用程式，你需要可靠性，同時結合可擴充性與資料準確性。

• 可擴充性：當應用程式的流量擴大 10 倍、100 倍、1000 倍或更多時，仍能持續與區塊鏈互動的能力。
• 資料準確性：應用程式向每一位使用者都回傳正確且一致資料的狀態。

(2) 節點的設計初衷並非全規模的正式環境解決方案‍

節點最初的設計是供個人在個人使用與小規模場景中運行。雖然成本不低（每月 1000 美元），但對於這種有限的使用情境，節點能夠創造足夠的可靠性，並維持：

• 可擴充性；請求量是可預測且可控制的，限制了可擴充性相關的風險
• 資料準確性；因為只有一個節點，節點之間不會出現資料不一致的問題

然而，開發環境並非正式環境，而正式環境需要非常不同的工具。

(3)** **節點被期望要做的事情太多

節點被期望能做無數件事，例如執行點對點軟體、作為可擴充的資料庫、執行任意程式碼等等。

而節點對於自己該做或不該做什麼，並沒有任何「立場」。

綜合起來，這造成了兩個主要後果：

• 可擴充性；隨著請求量增加而擴充規模時，你需要啟動新的節點；而每個新節點都必須具備完整的那一長串功能，造成沉重的低效與成本（同樣地，即使是最便宜的方案，運行一個節點每月也要花費 1,000 美元）。
• 邊緣案例；由於節點缺乏基本的保護機制，單一查詢就可能讓整個節點癱瘓。

(4) 節點需要全職維護

平均每 5 天，節點就可能出現以下問題：

• 記憶體洩漏
• 資料儲存問題
• CPU 滿載
• 對等連線不穩定
• 內部資料庫損毀
• 交易廣播問題
• 錯誤與回歸問題
• 每 6 個「穩定版本」就有 1 個有問題

每個問題都需要花費大量時間診斷、排除與修復，這意味著投入在前端使用者體驗上的時間將大幅減少。

(5) 節點的效能取決於能否成功應對時間難以預測的網路升級或硬分叉

網路升級與硬分叉的時程是由協定決定，而非由你決定。每一次都需要大量的事前準備，一旦出錯，就可能導致節點崩潰，造成嚴重後果。

常見的基礎設施架構模式，以及它們為何會失敗

要建立可靠的節點基礎設施本質上就很有挑戰性，而許多常見的 web3 架構在建立可靠性方面成效不佳：

運行單一節點

這種做法設定較為簡單，但存在單點故障的風險，既缺乏異質性，也缺乏冗餘性。單一節點的正常運行時間最低可測得僅 72%，而擴充單一節點的效率也極差。

運行一個節點並搭配備援

這種做法比單一節點多提供了些許冗餘性，但仍然缺乏異質性（系統缺乏多樣性），而且往往一個導致第一個節點癱瘓的請求，也會讓第二個節點一併癱瘓。可擴充性的問題依然存在，而且你還引入了資料準確性的問題，因為節點會回傳不同的回應——大多數系統都無法保證每個節點都處於同一個區塊頭（甚至同一條鏈）。

‍在一組節點之間進行負載平衡

這種模式能創造更多的冗餘性，但仍然缺乏異質性。資料準確性與可擴充性的問題依然存在（一連串的重試就能讓整組節點全部癱瘓）。

節點經常故障，而且修復起來非常、非常麻煩。

如果現在還不夠清楚的話：許多用來連接區塊鏈的「解決方案」並未充分提供異質性或冗餘性，也因此最終會失敗。而失敗會帶來嚴重的後果。

節點故障後，可能需要數天或數週的時間才能恢復運作。這些問題成本高昂、難以解決，需要整個團隊全力投入。

2019 年，BlockCypher 嘗試應對 Ethereum 的 Constantinople 硬分叉。他們遇到資料遺失的錯誤，卻無法診斷出根本原因。他們因此經歷了超過一個月的停機時間，最終幾乎得從頭重來。

別讓這種事發生在你身上 ;)

你的 web3 基礎設施越具異質性與冗餘性，就越可靠。

Alchemy 如何在規模化下建立可靠性

Alchemy 的 Cortex 引擎結合了客製化、可擴充且分散式的系統，能實現可靠性與可擴充性，同時讓我們的 API 表現得如同單一節點，藉此確保資料準確性。

Cortex 透過可擴充且多樣化的系統，同時達成冗餘性與異質性

以冗餘且異質的系統，減少對節點的資料請求

Web2 基礎設施藉由將資料儲存從伺服器中移除、建立外部儲存中心，來創造可靠性與可擴充性。

然而，由於節點架構本身的獨特性質，將資料儲存從節點中移除幾乎是不可能的事。

為了創造可靠性與可擴充性，Alchemy 的 Cortex 引擎採用一種稱為「次級基礎設施（secondary infrastructure）」的進階架構，來複製節點的資料。

Cortex 的協調層 Vox Nodi 持續執行系統檢查，確保次級基礎設施擁有最新的資料，因此任何資料請求（例如區塊號碼、交易日誌、交易收據）都能準確無誤。

透過優先將請求路由至次級基礎設施，節點得以受到保護，其「工作負載」也因此降低。

大多數請求都能由次級基礎設施處理，只有邊緣案例才會被路由至節點。

舉個例子：

使用者想取得不同資料類型與區塊的資訊：

• 使用者 1 要求取得截至區塊 82 的交易（Transactions）資料
• 使用者 2 要求取得區塊 85 的日誌（Logs）資料
• 使用者 3 要求取得區塊 92 的區塊（Blocks）資料

使用者 1 的請求可由次級基礎設施系統處理。（重要的是，如果這類請求直接打到節點，節點就會崩潰，而次級基礎設施系統則能順暢地處理這個負載）。

使用者 2 的請求同樣也可由次級基礎設施處理。

使用者 3 的請求則無法透過次級基礎設施處理，因為該系統尚未取得區塊 92 的最新區塊資料。使用者 3 的請求因此將改由節點處理。

在這個例子中，使用者 1、2、3 的體驗完全相同。無論請求是由次級基礎設施回應，還是直接由節點回應，停機時間上並沒有差異。但透過優先將請求路由至次級基礎設施系統，節點得以受到保護，其「工作負載」也因此降低。

以冗餘且異質的系統執行程式碼

由於 Ethereum Virtual Machine (EVM) 是圖靈完備的，你可以要求節點執行程式碼。而由於節點無法自我規範，任意的請求隨時都有可能讓整組節點癱瘓。

為了防範這種情況，Alchemy 會對我們系統先前已回應過的所有請求進行去重與儲存。

這意味著只有真正全新且獨特的請求才需要在節點上運行，其餘絕大多數的請求都可以由這些儲存系統來執行。

異質節點，針對不同請求做特化處理

除了次級基礎設施系統之外，Alchemy 還透過不同類型的節點增加異質性。在少數次級基礎設施無法回應請求的例外情況下，系統會預設改用可擴充性最高的節點。

Alchemy 運行多種類型的節點，包括：

• Light（輕量）： 只下載區塊標頭，也就是在網路上交易所需的最少資料。輕量節點能有效率地與網路互動，並節省大量的頻寬與儲存空間，但其限制在於無法存取完整資料。
• Full（完整）：具備驗證網路上區塊正確性所需的一切，並能與任何智慧合約互動、部署自己的合約。完整節點需要相當可觀的運算與頻寬資源。
• Archive（歸檔）： 比完整節點更進一步。完整節點會清除不再需要用來驗證的條目，而歸檔節點則會保留一切（額外多出數 TB 的資料）。這些詳盡資料在更有效率地查詢資訊時非常好用，在少數應用情境中也很方便，但在大多數情況下都嫌過度。
• Debug（除錯）： 除錯節點比歸檔節點走得更遠，儲存的資訊量是所有節點類型中最多的，讓你能夠極其詳細地逐步檢視智慧合約的執行過程。

不同節點類型各有其獨特性質，擅長處理不同的事情，因此若某個節點無法回應請求，其他節點很可能依然健康且適合處理該請求。

舉例來說，如果有請求要取得可能尚未記錄在次級基礎設施中的最新資料，該請求就能被路由至快速節點，而歸檔節點則能因此受到「保護」，因為在歸檔節點的資料中篩選會耗費明顯更高的成本。

為了更容易依需求啟動新節點，Cortex 引擎會為節點建立「快照（snapshot）」，這樣建立新節點時，系統就能從最近的「檢查點（checkpoint）」開始，大幅縮短同步過程所需的時間。

異質客戶端，降低錯誤造成的影響

最後，Alchemy 運行多種不同的 Ethereum 客戶端實作，包括 geth、Erigon 與 Parity。這實際上讓後端維護工作量增加為三倍，但對於實現異質性而言，這麼做的價值相當大：這些客戶端同時出現相同錯誤的機率基本上是零。

透過冗餘性與異質性建立可靠性

在 Alchemy，我們投入了數十萬小時打造 Cortex——一套從零開始就設計為具異質性與冗餘性的複雜系統，大幅提升了我們的容錯能力，確保我們能可靠地回應任何區塊鏈請求。

我們花了好幾年時間，才打造出這套讓這種可靠性成為可能的複雜、相互依存的系統。要在可靠性上做到可控，是極具挑戰性的工作，但善用可靠的基礎設施，對你應用程式的成功至關重要。

在評估基礎設施選項時，你應該最先問供應商的問題之一是：「你們的基礎設施具備多少異質性與冗餘性？你能提供什麼證據，證明你們系統的可靠性？」

公開的 RPC 供應商基準測試有助於評估延遲、成功率與失敗請求，並可與供應商對其架構的說法相互對照。

你的應用程式能否成功，取決於這個選擇。讓我們知道我們能如何幫上忙！