Solana 架構：SOL 高速背後的 8 大創新

準確性說明：網路性能、驗證者數量、手續費、協議功能、錢包支援以及第三方整合會隨時間變化。請將過往數據視為歷史快照，並查閱目前的原始來源文件。

Solana 架構通常通過其早期技術資料中的八個設計理念來解釋。其中一些仍是核心，而另一些則是歷史提案或已演進，因此本文區分了原始模型與目前的實現方案。

早期的 Solana 資料將架構歸納為旨在支援高吞吐量執行的八個理念。由於目前的性能、實現所有權、軟體組件和組織角色都在不斷演進，因此本文將「八大創新」框架視為一個歷史性的解釋模型，而非完整的現行規範。

關鍵要點

Solana 的架構建立在八大支柱之上，每個支柱都解決了特定的性能瓶頸：

1. 歷史證明 (PoH)：在共識運行前為事件標註時間戳的密碼學時鐘
2. Tower BFT：在投票中使用 PoH 時間戳的共識機制
3. Turbine：將區塊分解為較小封包的區塊傳播技術
4. Gulf Stream：基於預定領導者的交易轉發協議
5. Sealevel：並行智能合約執行運行時
6. Pipelining：階段式交易處理
7. Cloudbreak：為並發訪問設計的帳戶資料庫
8. Archivers：一個歷史性的分佈式存儲提案

性能說明： 歷史理論 TPS、目標插槽時間、確認、最終性、基礎費用和優先級費用是不同的衡量指標。請驗證目前的日期指標及其背後的方法論。

誠實的權衡： Solana 自 2020 年 3 月主網上線以來曾發生過有記錄的網絡停機，且其驗證者硬體要求（建議 128+ GB RAM）產生了去中心化壓力。這些是已知的架構權衡，而非偶發問題。

Solana 旨在解決的問題

區塊鏈傳統上面臨著一個根本性的約束：區塊鏈三元悖論（Blockchain Trilemma）。這個由 Vitalik Buterin 推廣的概念指出，一個網路最多只能同時實現三個屬性中的兩個。這三個屬性分別是可擴展性（高吞吐量）、安全性（抵禦攻擊的能力）和去中心化（分佈式控制）。可以將其想像成一個三角形，將一個角推得越遠，總會將另外兩個角拉向內側。Bitcoin 的處理速度約為 7 TPS，出塊時間為 10 分鐘，以犧牲吞吐量為代價優先考慮安全性和去中心化。Ethereum 在加入擴容解決方案之前，其基礎層的處理速度約為 15–30 TPS，同樣優先考慮安全性和去中心化。

Anatoly Yakovenko 曾是 Qualcomm 的分佈式系統工程師，他以不同的方式應對這一約束。2017 年 11 月，他發表了一篇題為《歷史證明：區塊鏈的時鐘》的白皮書，描述了一種密碼學計時機制，可以顯著減少共識算法中的通訊開銷。Greg Fitzgerald 作為聯合創始人兼首席技術官加入，他們共同構建了後來成為 Solana 的協議。他們共同創立的營利性公司 Solana Labs 領導核心協議的開發。Solana 基金會則是位於日內瓦的獨立非營利實體，負責資助生態系統補助金、驗證者去中心化計劃和教育倡議。

Solana 的八大支柱架構旨在這些三元悖論的約束內，盡可能推高可擴展性的邊界。該設計刻意接受了較高的驗證者硬體要求，作為實現高吞吐量的代價。Solana 並未解決三元悖論；它只是在可擴展性軸上佔據了一個異常激進的倉位。這些權衡是有實際代價的，詳情請見下方的架構權衡章節。

Solana 的八大架構支柱：概覽

歷史上的八部分框架涵蓋了歷史證明、Tower BFT、Turbine、Gulf Stream、Sealevel、Pipelining、Cloudbreak 和 Archivers。不應假設每一項目前仍是獨立部署的子系統，特別是 Archivers 提案。

1. 歷史證明 (Proof of History)：一種順序 SHA-256 哈希鏈，在執行共識之前創建可驗證的時間戳記錄
2. Tower BFT：一種經過 PoH 增強的拜占庭容錯共識機制，利用 PoH 時間戳進行高效投票
3. Turbine：一種受 BitTorrent 啟發的區塊傳播協議，將區塊分解為名為 shreds 的小型糾刪碼封包
4. Gulf Stream：一種無內存池的交易轉發協議，將交易直接路由給即將上任的驗證者領導者
5. Sealevel：一種並行智能合約執行運行時，可同時運行數千個互不衝突的程式
6. Pipelining：一種交易驗證優化 (TVO) 系統，通過四個並發硬體階段處理交易
7. Cloudbreak：一個水平擴展的帳戶資料庫，使用內存映射文件來支援並發讀寫
8. Archivers：一個關於分佈式帳本存儲的歷史提案，使用了複製證明概念

各個支柱將在下方章節中深入探討。

歷史證明 (PoH)：Solana 的計時引擎

歷史證明 (PoH) 是一種順序 SHA-256 哈希鏈，在共識運行之前創建可驗證、按時間排序的事件記錄，作為整個網路的共享密碼學時鐘。PoH 不是 Solana 的共識機制；該角色屬於 Tower BFT。PoH 是讓 Tower BFT 變得快速的計時層。

可以將 PoH 想像成一個密碼學秒錶，證明事件之間流逝了多少時間，而不需要網路上的每個驗證者先相互校對時鐘。在傳統的區塊鏈網路中，驗證者必須在每一輪共識期間相互交換時間戳消息，這增加了通訊開銷，且開銷隨驗證者數量的增加而增長。PoH 完全消除了這種交換。

從技術上講，PoH 是一個順序 SHA-256 哈希鏈，其中每個輸出都成為下一次計算的輸入。由於 SHA-256 在這種鏈式形式下無法並行化，鏈的長度就是經過時間的防竄改記錄。產生 N 個哈希鏈的驗證者顯然花費了計算 N 個順序哈希操作所需的時間。不存在捷徑。Anatoly Yakovenko 於 2017 年 11 月的白皮書《歷史證明：區塊鏈的時鐘》中首次描述了這一機制 Proof of History: A Clock for Blockchain.

PoH 的運作方式類似可驗證延遲函數 (VDF)：這是一項需要可預測的循序時間來計算，但幾乎可以立即驗證的運算。這種運算時間與驗證時間之間的不對稱性，正是 PoH 具備實用性的原因。驗證者可以廣播 PoH 輸出，任何觀察者都能在幾微秒內驗證其真實性，儘管產生該輸出需要實際耗費時間。學術研究人員和協定分析師將認可這一特性是 PoH 安全屬性的理論基礎。

透過建立可驗證的排序參考，PoH 可以減少某些時間協調工作。它並未移除共識訊息傳遞，也不直接保證特定的時段 (Slot)、確認或最終確定時間。

一項關鍵的澄清：Solana 有時被描述為「歷史證明區塊鏈」，暗示 PoH 取代了權益證明 (PoS)。這是錯誤的。Solana 在其經濟安全層面上是一個權益證明區塊鏈。驗證者質押 SOL 作為抵押品，並因不誠實行為面臨罰沒 (Slashing)。PoH 是加密時鐘，使透過 Tower BFT 實作的 Solana PoS 共識機制變得更快、更高效。這兩個層級都是必要的；兩者相輔相成，不可互相取代。

Tower BFT：Solana 的共識機制

Tower BFT 是 Solana 的共識機制：它是實用拜占庭容錯 (pBFT) 的 PoH 增強變體，使用 PoH 時間戳記記錄作為共享時鐘，允許驗證者在不交換時鐘同步訊息的情況下對帳本狀態進行投票。

拜占庭容錯 (BFT) 描述了分佈式系統的一種特性，即即使某些參與者的行為具有惡意或不可預測，系統也能正確達成共識，該名稱源於分佈式運算中的拜占庭將軍問題。傳統的 pBFT 演算法需要節點之間進行大量的訊息傳遞以建立共同的時間觀，這使得它們在大規模應用中不切實際。Tower BFT 以 PoH 記錄取代了這些訊息傳遞。驗證者已經共享了 PoH 時鐘；他們不需要協商時間戳記。

驗證者是質押 SOL、驗證交易、在被選為領導者時產生區塊並對帳本狀態投票的網絡參與者。他們在分叉上進行呈指數級增長的時間鎖定投票。驗證者在特定分叉上投票的時間越長，如果該分叉被放棄，它面臨透過罰沒（移除質押代幣以懲罰不誠實或不一致行為的懲罰機制）損失 SOL 的風險就越大。這種投票鎖定機制為誠實參與創造了強大的經濟激勵，而不需要額外的通訊輪次。

Tower BFT 可容忍高達三分之一的驗證者集合表現出拜占庭行為。如果少於三分之一的驗證者採取惡意行動，網絡就能達成正確的共識。這一門檻遵循拜占庭將軍問題的數學要求，最初由 Lamport、Shostak 和 Pease 於 1982 年正式提出。研究人員的共識演進線索為：pBFT (Castro and Liskov, 1999) 建立了基礎演算法；隨後包括 HotStuff 和 Tendermint 在內的變體對其進行了改進；Tower BFT (2017) 則更進一步，透過 PoH 消除時鐘同步開銷。

目標時段時間絕不能被視為最終性保證。應用程式應區分已處理 (Processed)、已確認 (Confirmed) 和已最終確定 (Finalized) 的承諾層級，並根據其風險模型選擇確認規則。

Turbine：大規模區塊傳播

以理論上 65,000 TPS 的速度向每個驗證者廣播完整區塊會產生頻寬瓶頸，且該瓶頸隨網絡規模線性增長。Turbine 解決此問題的方式與 BitTorrent 解決大檔案分發的方式相同：透過將數據分解成小塊並將傳播負載分散到整個網絡。

Turbine 是 Solana 的區塊傳播協定，靈感來自 BitTorrent 的分片分發模型。Turbine 並非由一位領導者同時向每位驗證者廣播完整區塊，而是將區塊分解為稱為「Shreds」的小型糾刪碼數據包，並透過樹狀結構的驗證者網絡進行分發。

Shreds 經過糾刪碼處理以實現冗餘。傳播樹中的每個節點接收 Shreds 的子集，將其重新傳輸到下一層，並從接收到的子集重建完整區塊。糾刪碼意味著即使某些 Shreds 在傳輸中遺失，仍可從剩餘的數據包重建區塊。頻寬需求隨網絡規模呈對數增長而非線性增長，因為每個驗證者僅處理總區塊數據的一小部分。

擴大驗證者集合不會按比例增加每個節點的頻寬需求。一個擁有 2,000 個驗證者的網絡並不要求每個驗證者處理比中心化系統多 2,000 倍的頻寬。傳播樹分散了負載。Turbine 的 Shred 結構對於驗證者營運商規劃數據接收和區塊重建能力至關重要。

Gulf Stream：無內存池交易轉發

Gulf Stream 使用領導者感知的轉發機制，而非傳統的共享全域內存池。這改變了排隊模型，但並未消除擁塞或交易排序激勵。

在以太坊上，未確認的交易在內存池中等待：這是等待被納入區塊的未確認交易共享池。在需求高峰期間，此池會成為擁塞、費用攀升和最大可提取價值 (MEV) 的來源，MEV 是指在交易最終確定前，透過在內存池中重新排序、插入或審查交易而提取的利潤。以太坊用戶出價更高的 Gas 費用以優先處理其交易，這就是為什麼費用在高峰使用期間歷史上曾達到 $5–$50+ 的原因。

此設計利用 Solana 已知的領導者排程將交易轉發給即將上任的領導者，而非將其廣播到傳統的全域池。驗證者可以在輪到他們產生區塊之前預先處理交易，這可能會減少排隊延遲，同時將擁塞、費用競爭、掉單和 MEV 作為單獨的問題處理。

領導者感知的交易轉發改變了交易到達預定領導者的方式，但它並未消除擁塞、優先費競爭、MEV、掉單或驗證者資源壓力。目前的基礎費用和優先費應直接衡量，而非轉換為固定的美元金額。

內存池的缺失改變了在 Solana 上構建的開發者的交易提交模式。交易具有可預測的轉發路徑，能夠在完全最終確定前實現樂觀確認。Solana 上的 MEV 空間大大小於以太坊，儘管並非為零；質押加權的交易排序創造了其自身的動態，去中心化應用程式 (dApp) 設計者在構建前應予以研究。

Sealevel：並行智能合約執行

Sealevel 是 Solana 的並行智能合約執行運行環境，是執行鏈上程式（Solana 對以太坊所謂智能合約的稱呼）的引擎。與以太坊的 EVM 每次依序執行一個合約不同，Sealevel 在可用的 GPU 和 CPU 核心上同時執行數千個不衝突的程式。

以太坊的 EVM 處理智能合約就像超市裡的單一結帳通道：一次處理一筆交易，每位顧客都在前一位顧客後面等待。Sealevel 同時開啟二十個結帳通道，並行運行不衝突的交易。這是 Solana 的吞吐量在基礎層超過以太坊的主要架構原因。

並行處理之所以可能，是因為 Solana 的程式設計模型要求每筆交易在提交時就聲明它將讀取和寫入哪些帳戶（儲存 Solana 上數據的狀態對象）。Sealevel 會分析這些帳戶訪問列表，以識別不衝突的交易：觸及完全不同帳戶的交易可以同時運行，而不會產生衝突的狀態更改。共享帳戶的交易必須按順序執行。Sealevel 運行時會使用此聲明來調度跨可用硬件核心的並行或順序執行。

鏈上程式主要以 Rust 編寫，編譯成 Berkeley Packet Filter (BPF) 字節碼，並由 Sealevel 運行時執行。跨 GPU 和 CPU 核心的並行執行是使 65,000 TPS 理論值在硬件層面上可行的原因。

開發者注意事項

當你在 Solana 上部署程式時，你必須在交易提交時聲明你的程式將讀取和寫入的所有帳戶。此帳戶訪問列表不是可選項；它是 Sealevel 用於調度並行執行的機制。省略或錯誤聲明帳戶會導致交易失敗。

與其他程式共享狀態（寫入相同帳戶）的程式無法從並行處理中受益，並且將始終按順序執行。請盡可能設計你的程式帳戶結構以最小化共享狀態。具有狹窄、不重疊帳戶訪問模式的程式能從 Sealevel 的並行調度器中獲得最大的益處。

Anchor 框架是一個基於 Rust 的工具包，它提供了簡化常見程式模式的宏和抽象，是 Solana 程式最廣泛使用的開發工具包。有關帳戶模型、程式派生地址和 Sealevel 運行時的完整文檔，請參閱 Solana 開發者文檔.)

管道化：交易驗證如同裝配線

汽車裝配線不會先完成一輛車的製造，然後才開始下一輛。每個工位（焊接、噴漆、內裝）同時處理不同的汽車。Solana 通過交易驗證優化 (TVO) 將相同的邏輯應用於區塊鏈交易驗證。

Solana 中的管道化是指 TVO，即將 CPU 管道架構應用於區塊鏈交易處理。交易驗證過程分為四個離散階段，每個階段由單獨的硬件單元處理並並行運行。當一批交易通過一個階段時，下一批交易已進入前一個階段。

這四個階段是：

1. 獲取 (Fetch)：內核空間單元從網絡檢索傳入的交易數據
2. 簽名驗證 (SigVerify)：GPU 並行驗證批次中的加密簽名
3. 銀行 (Banking)：CPU 處理交易邏輯、檢查帳戶餘額並更新帳戶狀態
4. 寫入確認 (Write Confirmation)：磁盤寫入最終確定的狀態變更

當批次 A 在銀行階段時，批次 B 在簽名驗證階段，批次 C 正在獲取。沒有硬件會空閒等待前一批次完成。這種連續的分階段處理消除了處理階段之間原本會限制吞吐量的 CPU 空閒時間。

管道化是三大支柱之一，與 Sealevel 和 Gulf Stream 一起，共同產生了 Solana 的總交易處理能力。Solana 通過讓每個處理組件始終在工作，而不是讓任何階段在批次之間空閒，從相同的硬件中提取更多的吞吐量。

Cloudbreak：水平擴展的帳戶數據庫

Cloudbreak 是文件系統，它讓 Solana 的並行處理器能夠同時讀寫帳戶數據而無需排隊。沒有它，存儲層將序列化所有帳戶讀寫操作，Sealevel 的並行優勢將在數據庫邊界蒸發。

Cloudbreak 是 Solana 的水平擴展帳戶數據庫：儲存網絡上每個帳戶狀態的數據結構。它使用內存映射文件和針對 SSD 優化的數據結構，來支持跨多個線程的並發讀寫。

帳戶分佈在多個可並行訪問的數據結構中。操作系統的內存映射 I/O 允許 Cloudbreak 將駐留在磁盤上的帳戶數據視為 RAM 中的數據，消除尋道延遲並啟用線程級別的併發訪問。當 Sealevel 調度 10,000 筆並行交易時，Cloudbreak 可以處理 10,000 次同時發生的帳戶讀寫操作，而無需將請求序列化到隊列中。

數據庫架構和執行運行時是相互依存的：沒有對方，兩者都無法提供吞吐量。Cloudbreak 的 I/O 模式需要高性能 NVMe SSD。標準的旋轉硬盤無法維持 Cloudbreak 並發訪問模型所需的隨機讀寫吞吐量。理解 Cloudbreak 的帳戶模型對於 Solana 程式設計至關重要：所有狀態都存在於離散的帳戶對象中，程式對這些帳戶執行無狀態操作，並且帳戶佈局的決定直接影響運行時的讀寫性能。

Archivers：歷史存儲提案

Archivers 概念出現在 Solana 的早期架構資料中，但除非有當前的原始來源證據，否則不應將其呈現為目前已部署的生產子系統。

早期設計資料提出 Archivers（在某些描述中也稱為 Replicators），作為輕量級參與者，存儲部分歷史分類賬數據並證明存儲。這解釋了分類賬增長的原始方法，但不應在沒有當前原始來源確認的情況下，將其描述為活躍的、帶有獎勵的生產網絡。當前的分類賬保留和歸檔基礎設施必須單獨記錄。

隨著所有八個架構支柱到位，組合系統產生的性能基準將 Solana 與大多數其他公鏈區分開來，這將在下一節中量化。

Solana 性能基準：TPS、費用和區塊最終確定性

歷史理論基準中的約 65,000 TPS 是 Solana 在最佳實驗條件下的理論最大值，而不是持續的實際運行數字。對於任何將這些數字用於投資分析或系統設計的人來說，區別很重要。

比較性能時，請使用當前原始資料和一致的測量方法。

真實世界的主網吞吐量由於多種原因低於理論最大值。在正常需求下，並非所有交易時段都會完全填滿。垃圾信息過濾機制會在低質量交易到達銀行階段之前將其拒絕。網絡狀況會影響傳播時間。接近理論上限需要持續的峰值需求，並結合驗證節點集中的硬件利用率，這些條件在特定的高流量事件期間才會發生，而不是持續不斷。

Solana 的吞吐量表現源自多種協同運作的架構來源。 PoH 提供了一個可驗證的排序參考，可以減少時間協調的開銷。 Sealevel 可並行執行非衝突的工作。 領導者感知轉發可以在區塊時段開啟前預先緩存交易，減少一些傳統內存池的排隊，但不會消除網絡延遲。

以太坊的 Layer-2 生態系統（包括 Arbitrum 和 Optimism）以及未來的分片升級，將以太坊的有效吞吐量提升到遠超其基礎層的水平。 在評估兩個平台用於特定用例時，任何完整的比較都應考慮到這種擴展的容量。

從架構到應用：Solana 的設計如何實現真實用例

Solana 的架構選擇為其上構建的應用程序產生具體、可衡量的結果，而非抽象的性能數字。

NFT： Solana 通常較低的費用和並行執行可以支持高吞吐量的鑄造，但優先費用、應用程序成本、擁塞、失敗和資產標準仍然很重要。 Gulf Stream 並未消除費用競爭。

DeFi： Solana 的運行時可以並行處理非衝突交易，而通常較低的費用可以支持頻繁的互動。 實際的交換延遲和成本包括路由、滑點、優先費用、失敗的交易、程序計算和市場狀況。 Gulf Stream 並未消除 MEV 或前端運行風險。

GameFi 和小額交易： 通常較低的費用可以支持小額價值操作，但總體應用程序成本和失敗的交易仍然很重要。 應使用當前數據分別比較以太坊 L1 和 L2 的成本。

支付： 基於 Solana 的支付應用程序可以針對快速用戶反饋，但錢包批准、樂觀確認、根節點最終性、商家風險承受能力和鏈下操作是獨立的階段。 信用卡授權不等於公共區塊鏈結算。

實現這些應用程序的相同架構選擇也伴隨著記錄在案的權衡，下一節將不加緩和地檢視這些權衡。

架構權衡：網絡可靠性、去中心化和速度

自 2020 年 3 月主網啟動以來，Solana 經歷了記錄在案的網絡中斷，主要是由於機器人生成的交易洪流淹沒了驗證節點的內存，導致驗證節點退出共識。

網絡中斷

Solana 的高吞吐量設計以最小的預過濾處理交易，這會造成特定的漏洞。 當機器人向網絡發送垃圾交易時，在交易到達過濾階段之前，驗證節點可能會耗盡可用內存，導致共識停滯。 主要記錄在案的中斷包括 2021 年 9 月一次持續約 17 小時的中斷，由機器人驅動的 IDO 事件的交易量激增引發，以及 2022 年 1 月一次與驗證節點過量重複交易相關的中斷。 2022 年和 2023 年還發生了其他較短的中斷。

Solana Labs 實施了兩種主要的架構緩解措施。 QUIC 網絡協議取代了 UDP 用於交易接收，提供了連接級流量控制，限制了任何單一來源可以提交的交易數量。 基於質押權重的服務質量 (QoS) 優先考慮來自具有較大 SOL 質押的驗證節點的交易轉發，使得來自低質押來源的垃圾交易洪水效果減弱。 計算單元的費用市場在高流量下會產生針對垃圾交易的經濟阻力。 自這些緩解措施部署以來，中斷頻率已有所下降。 對於需要持續高可用性的應用程序而言，中斷歷史仍然是一個已知的風險因素。

驗證節點中心化疑慮

Solana 驗證節點需要重要的硬件。 根據 Solana 基金會驗證節點文檔,)，推薦的規格包括 128GB 以上的 RAM、高性能 NVMe SSD 和高帶寬互聯網連接。 請在閱讀時驗證當前規格，因為要求會隨著協議升級而演變。 這些要求遠超以太坊驗證節點參與 PoS 共識所需的條件。

硬件門檻將驗證節點的潛在池限制在需要大量資本投資的運營商。 硬件要求服務於一個真實的工程目的：它們是當前吞吐量目標所依賴的。 它們也是更廣泛驗證節點參與的真實障礙。 Solana 基金會資助驗證節點去中心化計劃和為較小型運營商提供的贈款，但性能目標與硬件成本之間的緊張關係是設計的結構性特徵，而不是附帶的政策問題。

區塊鏈三元悖論定位

Solana 並未消除區塊鏈三元悖論。 其架構代表了一種故意選擇，優先考慮可擴展性和維護安全性，同時接受更高的驗證節點硬件要求，這對去中心化造成壓力。 以太坊優先考慮去中心化和安全性，通過 Layer-2 解決方案解決可擴展性問題。 比特幣以最小吞吐量為代價，優先考慮安全性和去中心化。 每個鏈都在同一三元悖論內佔據不同的工程位置，沒有一種配置可以同時最大化這三個維度。

中斷歷史、驗證節點硬件要求造成的中心化壓力以及三元悖論定位是任何嚴格技術評估 Solana 網絡的關鍵輸入。

Solana 與 Ethereum 和 Bitcoin：架構比較

歷史基準測試顯示，Solana 的基礎層吞吐量表現優於以太坊主網，但測量結果並非可比。 PoH 提供預共識排序，Sealevel 同時運行非衝突的工作，領導者感知轉發改變了交易路由。 常被引用的約 65,000 和約 15-30 TPS 數字是過時的、依賴於方法的參考點，而非永久網絡屬性。

吞吐量和執行模型

以太坊的 EVM 順序執行智能合約，每個區塊一次。 Sealevel 同時執行數千個非衝突的智能合約。 這是 TPS 差距的主要來源。 以太坊通過 Layer-2 擴展來解決吞吐量問題：Rollup，包括 Arbitrum 和 Optimism，在鏈下處理交易並將壓縮後的批次在以太坊基礎層進行結算，大大提高了有效容量。 Solana 的方法是在 Layer-1 上進行水平擴展，避免了 Layer-2 架構為開發人員和用戶帶來的額外複雜性。

開發者平台比較

以太坊的開發者生態系統（Solidity、EVM 工具、成熟的 DeFi 協議以及多年的審計代碼）比 Solana 的更大、更成熟。 Solana 的 Rust 和 Sealevel 模型提供了更高的基礎層吞吐量和更低的費用，但需要理解賬戶模型以及賬戶訪問聲明要求，這在以太坊上沒有直接對應。 吞吐量和費用是約束條件的應用程序非常適合 Solana 的架構。 優先考慮 EVM 兼容性、最廣泛的開發者人才庫或最大的基礎層去中心化的應用程序，更適合以太坊基礎層或其 L2 生態系統。

比特幣作為第三個參考點

比特幣的架構優先考慮安全性和去中心化，而非吞吐量。 比特幣的 TPS 約為 7，區塊時間為 10 分鐘，不適合高頻應用程序。 其工作量證明共識在設計上是計算密集型的：通過能源消耗而不是經濟質押來確保安全。 Solana 和以太坊都提供比特幣本身不原生支持的可編程智能合約平台。 比特幣的架構定位使其成為一個不同的系統類別，而不是應用程序部署的直接競爭對手。

如需跨五個維度的完整數據比較，請參閱上方效能基準測試表。

關於 Solana 架構的常見問題

Solana 中的歷史證明 (Proof of History) 是什麼？

歷史證明 (PoH) 是一個順序性的 SHA-256 哈希鏈，可在共識機制運行前創建一個可驗證、按時間順序排列的事件記錄。它充當驗證者網絡之間的共享密碼時鐘，讓驗證者無需交換時間戳記消息即可處理交易。PoH 並非 Solana 的共識機制，而是由 Tower BFT 處理共識，並將 PoH 的時間戳記作為其共享時間參考。

歷史資料引用了理論和觀察到的 TPS 範圍，但實際吞吐量取決於交易組合、投票記帳、過濾、擁塞、驗證者軟體和測量方法。請使用當前的第一手資料並定義所計算的內容。

Solana 由 Anatoly Yakovenko 和 Greg Fitzgerald 共同創立。Yakovenko 曾是高通公司的工程師，負責過分散式系統和時鐘同步方面的工作，他於 2017 年 11 月的白皮書中首次描述了歷史證明機制。Solana Labs，這家由他們共同創辦的營利性開發公司，領導了協議工程。總部位於日內瓦的獨立非營利組織 Solana Foundation，則支持生態系統的發展。

幾個架構層級促成了效能差異。PoH 提供了一個可驗證的排序參考，可以減少部分協調開銷；Sealevel 並行運行不衝突的工作；領導者感知轉發改變了交易如何到達計劃好的驗證者。歷史 TPS 數據取決於測量方法，不應被視為任一網絡的永久屬性。

早期資料將架構分為歷史證明、Tower BFT、Turbine、Gulf Stream、Sealevel、Pipelining、Cloudbreak 和 Archivers。這是一個歷史性的解釋框架，而非證明每個命名項目——尤其是 Archivers——至今仍是一個獨立部署的子系統。

Tower BFT 是 Solana 基於 PoH 插槽和不斷增加的投票鎖定所建立的權益加權投票和分叉選擇機制。請勿假設某種特定的自動削減執行方式或均等地計算驗證者：拜占庭閾值是權益加權的，安全性和可用性假設需要更精確的處理。

Gulf Stream 描述了領導者感知交易轉發，而不是傳統的全局內存池。它可能減少某些隊列，但並不能消除優先費用競爭、擁塞、交易丟失、MEV 或前端運行風險。應從實施文件中驗證當前的網絡行為。

Sealevel 是 Solana 的並行智能合約執行運行環境。與一次執行一個合約的以太坊 EVM 不同，Sealevel 可在可用的 CPU 和 GPU 核心上同時運行數千個不衝突的程序。通過要求每筆交易在提交時聲明它將訪問哪些帳戶，就可以實現並行，從而使運行環境能夠識別不衝突的操作並同時調度它們。

是的。Solana 使用權益證明 (PoS) 作為其經濟安全層。驗證者質押 SOL 作為抵押品，並面臨因不誠實或不一致行為而被削減的懲罰。歷史證明是一個獨立的加密計時機制，它使得 Solana 的 PoS 共識更快。PoH 並不取代 PoS；它增強了基於 PoS 的共識機制 Tower BFT 的效率。

Solana 已記錄的網絡中斷主要由機器人生成的交易洪流引起，這些洪流使驗證者內存過載，導致驗證者失去共識。該架構的高吞吐量設計以最少的預過濾處理交易，這使其容易受到大量垃圾訊息攻擊。Solana Labs 實施了 QUIC 網絡和權益加權 QoS 作為架構緩解措施，減少了中斷頻率。請參閱架構權衡部分瞭解具體的記錄事件。

核心架構差異在於執行模型（並行 Sealevel vs. 順序 EVM）、交易路由（無內存池的 Gulf Stream vs. 全局內存池）、程式語言（Rust vs. Solidity）和基礎層吞吐量（約 65,000 TPS 理論值 vs. 約 15-30 TPS）。兩個區塊鏈都使用權益證明來確保經濟安全。以太坊龐大的開發者生態系統和 Layer-2 選項能很好地服務於 EVM 兼容項目；Solana 的基礎層吞吐量和費用結構則適合交易量和成本是主要限制的應用。

沒有完全的區塊鏈三元悖論解決方案；Solana 而是進行權衡。該架構優先考慮可擴展性並保持安全性，同時接受更高的驗證者硬體要求，這對去中心化造成了可衡量的壓力。這是區塊鏈三元悖論中的一個特定工程立場，而不是消除了它。與其他主要區塊鏈相比，Solana 在可擴展性軸上的立場異常激進。

Solana 鏈上程序主要用 Rust 編寫，編譯為 Berkeley Packet Filter (BPF) 字節碼，並由 Sealevel 運行環境執行。C 和 C++ 也受支持。Anchor 框架是一個基於 Rust 的工具包，提供宏和抽象來簡化常見的程序模式，是目前使用最廣泛的開發工具包。有關當前生態系統工具，請參閱 Solana 開發者文檔。

Solana 交易成本包含基礎費用，可能還包含優先級和與計算相關的費用。美元價值隨 SOL 價格變動，而擁塞和應用程式行為則會影響總執行成本。Gulf Stream 並未消除費用競爭。

截至撰寫本文時，Solana 擁有超過 1,000 個活躍驗證者。請透過Solana Foundation 驗證者統計數據.)驗證當前數量和分佈。驗證者需要大量的硬體投資，包括 128GB 以上的 RAM 和高性能 NVMe SSD，這比大多數其他權益證明鏈的入門門檻更高，也是持續去中心化擔憂的主要來源。

在 Bybit 上探索 SOL

讀者可以查看當前 SOL 市場資訊)或SOL/USDT 現貨市場.)。這些連結提供市場准入，並不代表 Solana、錢包或第三方協議適合所有讀者。

Solana 的架構結合了多項相互關聯的設計決策。PoH 提供排序參考，Sealevel 並行化不衝突的執行，領導者感知轉發改變交易路由，而 Pipelining、Cloudbreak 和 Turbine 則處理處理、儲存和傳播。記錄的網絡中斷歷史和驗證者資源要求，應與效能優勢放在同一個技術評估範圍內。

對於選擇平台的開發者而言，Solana 提供了所有主要生產級區塊鏈中最高的基礎層吞吐量和最低的交易費用之一。與以太坊的 EVM 相比，帳戶模型和 Rust 的要求增加了設計的複雜性。帳戶訪問聲明要求改變了您建構程式狀態的方式，而平行執行模型則獎勵那些最小化共用狀態的程式設計。

對於研究人員而言，Anatoly Yakovenko 最初的 Proof of History: A Clock for Blockchain (2017 年 11 月) 仍然是 PoH 設計的基礎主要來源。Solana Labs 在 docs.solana.com 維護目前的架構文件。Solana Foundation 在 solana.org/validators 發布驗證者網絡統計數據。即時網絡數據可透過 Solana Beach 取得。

了解 Solana 的八個架構支柱後，您現在就能夠根據自己的標準評估該網絡的性能聲明、權衡取捨及其長期發展軌跡。

免責聲明： 本文僅供參考及教育目的。不構成財務建議、投資建議，或買賣、持有 SOL 或任何其他加密貨幣的推薦。所有績效數據如有變動，恕不另行通知。在做出投資決策前，請諮詢合格的財務顧問。

相關閱讀

• Solana Proof of History
• Solana Consensus Mechanism
• SolanaVM
• Solana Speed