--- title: "我們如何為 Solana 打造可擴展性設計" description: "我們從零重建 Solana 平台時如何處理可擴展性問題，以及如何為接下來的發展做好準備。" --- # 我們如何為 Solana 打造可擴展性設計 [Solana](https://www.alchemy.com/solana) 與其他區塊鏈不同。它的架構從第一天起就是為了將吞吐量推向硬體極限而設計——平行執行、內嵌計時機制、無需 mempool 的交易轉發——這些機制協同運作，實現每秒數千筆交易與亞秒級最終確認。隨著 Firedancer 已在主網上線，Alpenglow 也即將到來，這個上限即將大幅提升。 要打造能跟上這種步調的基礎設施，光靠快速的節點是不夠的。這需要在堆疊的每一層都以「明天的負載將遠超今天」為前提來設計。 這正是我們從頭重建 Solana 平台時，對可擴展性採取的做法——也是我們為下一步發展所做的布局。 ## Solana 的可擴展性模型有根本性的不同 許多區塊鏈基礎設施是圍繞 Ethereum 的執行模型設計的：循序交易處理、全域狀態樹，以及相對有限的資料輸出量。Solana 打破了這些假設。 Sealevel 是 Solana 的平行執行環境，要求每筆交易事先宣告其讀寫集合，使得不重疊的交易能在多個 CPU 核心上同時執行。Proof of History 將密碼學時鐘直接嵌入帳本中，消除了拖慢其他鏈共識速度的協調開銷。而 Gulf Stream 讓交易直接推送給下一個區塊生產者，而非滯留在 mempool 中，進一步縮短確認延遲。 結果是這個網路以極高速度產生大量資料——尖峰速度下每年超過 4 PB。要服務這些資料的基礎設施，不能只是套用不同 RPC schema 的 Ethereum。它需要針對 Solana 特有的資料型態、存取特性和規模來架構設計。 這樣的理解，塑造了我們所做的每一個決策。 ## 針對 Solana 資料特性進行架構設計 Solana 的資料特性帶來了一組特定的基礎設施挑戰。區塊龐大且密集。歷史查詢範圍極廣。開發者既需要隨機的單點查詢（依簽章取得單一交易），也需要大規模的循序掃描（走訪某地址的完整簽章歷史）。而這一切都必須在全球範圍內以低延遲完成。 我們在[另一篇技術文章](https://www.alchemy.com/blog/how-alchemy-built-the-fastest-archival-methods-on-solana)中詳細介紹了歸檔架構的技術細節——HBase 遷移、三重驗證的資料擷取、自我修復管線，以及讓我們在 `getTransaction` 上達到單一區域超過 100,000 RPS 的具體優化方式。這篇文章則要談這些決策背後的設計原則。 核心原則是：**將需要獨立擴展的關注點分離開來。** 傳統的 Solana 基礎設施將資料擷取、儲存和服務全部綁在單一的 validator 節點中。這種耦合意味著你無法輕易擴展讀取能力、無法在不停機數小時的情況下重啟服務，也無法在不動到整個堆疊的前提下優化儲存配置。 我們將系統拆解為多個獨立服務——能在數秒內啟動的輕量 RPC 伺服器、可細緻控制每個實例處理哪些資料類型的專用擷取器，以及專為 Solana 存取模式設計的儲存層。每一層都能按自身的條件擴展。當流量激增時，我們能在數秒內針對同一份資料層啟動額外的 RPC 實例。當需要新區域上線時，儲存層可以獨立於服務層進行複製。 ## 可靠性是可擴展性的前提 基礎設施領域有一種常見模式：團隊優化速度、撞上擴展瓶頸，然後才發現這個瓶頸其實是可靠性問題。連線中斷、資料不完整、負載下的靜默失敗，這些其實都是偽裝成可擴展性問題的可靠性問題。 我們從一開始就以此為前提來設計。我們的多區域架構包含 3 到 5 層的自主容錯移轉機制——若某個節點、機架或整個區域發生異常，流量會自動重新導向。 在資料完整性方面，每筆記錄都會寫入兩次、以程式化方式驗證，並持續掃描以確認完整性。若出現差異，我們的自我修復管線會自動重新擷取並修補缺口——每個區塊最多會交叉檢查 30 到 50 個相關地址。整個修復流程是全自動且持續運作的，而不是一個附帶警示的靜態監控儀表板。 Solana 上的資料完整性問題比多數人所認知的更棘手。資料量和產生速度之大，意味著即使是小小的缺口也會迅速累積——這是開發團隊常見的痛點，許多團隊都曾回報基礎設施供應商提供的資料有缺漏或不一致。這類問題平時難以察覺，直到開發者的應用程式因為某筆交易未被索引、或簽章歷史不完整而出問題時才會浮現。我們將正確性視為不可妥協的底線，而不是盡力而為。 結果是 99.99% 的正常運行時間，這背後是我們 8 年多來持續投入的營運嚴謹度——支撐像 Polymarket 選舉夜這樣的應用，以及 World 主網上線。這種等級的可靠性不是一項功能，而是讓其餘可擴展性成立的基礎。 ## 為 Solana 下一個吞吐量時代進行設計 Solana 目前的吞吐量以每秒數千筆交易計算。協定的發展藍圖指向數量級的提升，而若基礎設施沒有依照這個軌跡來架構，就會成為瓶頸。 Firedancer 是 Jump Crypto 以 C 語言寫成的獨立 validator 客戶端，已於 2025 年底在主網上線。在實驗室條件下，它已展示超過每秒 100 萬筆交易的能力。其模組化的 tile 架構、繞過核心（kernel-bypass）的網路處理，以及平行簽章驗證，代表了對 validator 軟體如何運用硬體的根本性重新思考。截至 2025 年底，Solana 約 21% 的質押量已運行 Firedancer，且採用速度正在加快。 除了 Firedancer 之外，Alpenglow 協定升級旨在重寫 Solana 的共識機制，將區塊最終確認時間縮短至約 150 毫秒。而像 SIMD-0370 這樣的提案，則會完全移除區塊層級的運算上限，讓區塊能依硬體實際可處理的能力擴展，而非受限於人為設定的軟體限制。 此外，由 [Light Protocol](https://www.alchemy.com/dapps/light-protocol) 開發的 [ZK](https://www.alchemy.com/blog/zero-knowledge-rollups) Compression，將允許使用零知識證明把多個帳戶狀態壓縮進單一鏈上帳戶。這解決了 Solana 日益嚴重的狀態儲存挑戰，並開啟了全新的應用程式設計模式。 我們的基礎設施在設計時已將這些升級納入考量。拆解後的架構意味著我們可以隨吞吐量需求成長而獨立擴展每一層。多區域部署則提供了在更大流量下處理全球流量所需的地理分佈。這使我們相對其他 [Solana RPC](https://www.alchemy.com/dapps/list-of/rpc-node-providers-on-solana) 供應商擁有 2 倍吞吐量優勢，而這只是起點，而非上限。 ## 可擴展基礎設施為建構者帶來的可能性 可擴展性直接決定了開發者能打造出什麼。過去八年來，我們一路支援建構者，從第一次 API 呼叫，到之後每一個轉折點。像 Circle、Robinhood 和 OpenSea 這樣的團隊，都是在 Alchemy 上從早期原型擴展到服務數億用戶的產品。 - 毫秒級的歸檔查詢，代表錢包能即時渲染完整的交易歷史。 - 以最新資料優先的查詢方式，省去了為了顯示用戶最新活動而掃描多年舊資料的需要。 - `getTokenLargestAccounts` 回傳 1,000 筆結果而非 20 筆，讓分析平台能對代幣分佈有更完整的視角。 - 原生無 gas 交易，消除了扼殺轉換率的入門摩擦。 - 100% 質押寫入，確保交易能送達實際的區塊生產者，提升確認的可靠性。 這些能力之所以存在，是因為我們把可擴展性視為第一原則。 ## 前方的路 Solana 正在快速演進。網路的容量會提升，而建構於其上的應用程式在規模擴大後也會有更高的要求。 我們的承諾是持續走在這條曲線之前——投入更低的延遲、更高的吞吐量、更深入的資料存取，以及能開啟目前尚不可行用例的新能力。基礎設施不應該是建構者在產品上必須妥協的原因。 我們所描述的一切，現在都已可使用。 - 從 [alchemy.com/solana](https://www.alchemy.com/solana) 開始 - [聯絡我們](https://www.alchemy.com/contact-sales) 以取得客製化基準測試、專屬定價或更多資訊。 ## 常見問題 ### Solana 的可擴展性與其他區塊鏈有何不同？ Solana 透過 Sealevel 執行環境進行平行交易執行、以 Proof of History 實現內嵌計時，並以 Gulf Stream 繞過 mempool，實現每秒數千筆交易與亞秒級最終確認，且尖峰速度下每年產生超過 4 PB 的資料。 ### Alchemy 拆解式的架構如何改善 Solana 上的可擴展性？ Alchemy 將資料擷取、儲存和服務拆解為各自獨立的服務，各自按自身條件擴展，讓 RPC 伺服器能在數秒內啟動、流量能在不停機的情況下擴展，新區域也能在不動到整個堆疊的前提下部署。 ### Firedancer 是什麼？它如何影響 Solana 的吞吐量？ Firedancer 是 Jump Crypto 以 C 語言寫成的獨立 validator 客戶端，已於 2025 年底在主網上線，在實驗室條件下透過模組化架構、繞過核心的網路處理和平行簽章驗證，展示出超過每秒 100 萬筆交易的能力。 ### Alchemy 如何在 Solana 這樣的規模下確保資料完整性？ 每筆記錄都會寫入兩次、以程式化方式驗證，並持續掃描以確認完整性，配合自我修復管線，自動重新擷取並修補任何缺口，每個區塊最多交叉檢查 30 到 50 個相關地址。 ### ZK Compression 是什麼？為何它對 Solana 很重要？ 由 Light Protocol 開發的 ZK Compression，允許使用零知識證明把多個帳戶狀態壓縮進單一鏈上帳戶，解決了 Solana 日益嚴重的狀態儲存挑戰，並帶來新的應用程式設計模式。 ### Alchemy 如何在 Solana 上實現更快的歸檔查詢？ 我們使用專為 Solana 存取模式優化的 HBase 儲存層，搭配以最新資料優先的查詢方式與多區域架構，在像 `getTransaction` 這類方法上，於單一區域內提供超過 100,000 RPS 的毫秒級歸檔查詢。 ### 是什麼讓 Alchemy 的 Solana 基礎設施在規模擴大後仍然可靠？ 具備 3 到 5 層自主容錯移轉機制的多區域架構、自動化的自我修復管線，以及持續的資料驗證，共同實現 99.99% 的正常運行時間，確保在節點、機架或整個區域發生異常時，流量能自動重新導向。 ### Alchemy 可擴展的基礎設施為開發者帶來哪些功能？ 毫秒級的歸檔查詢、以最新資料優先的查詢方式、`getTokenLargestAccounts` 回傳 1,000 筆結果而非 20 筆、原生無 gas 交易，以及能提升確認可靠性的 100% 質押寫入。