## Solana 的共識機制：

### 舊版：Tower BFT + Proof of History

### 1. Solana 的共識機制是 **混合式**

- 核心是 **Proof of History（PoH）**：用一連串的 hash 計算當作「時間證明」
- 配合 **Tower BFT（類似 PBFT 的改良版）** 來確保節點投票一致

### 2. Proof of History（PoH）

- PoH 不是共識機制本身，而是一個「**時間排序層**」（verifiable delay function, VDF），目的是給整個網路一個「大家都能驗證的共同時間軸」。
- 區塊鏈節點在**缺乏同步時鐘**下很難知道「事件誰先誰後」。
- PoH 的貢獻是：**將所有事件嵌入一個「可驗證、不可篡改」的哈希鏈裡，作為共識之前的順序依據。**

2.1 PoH 的技術原理：

- PoH 以 **SHA-256 或 Blake3** 等不可逆雜湊函數連續運作為基礎：

H_0 = 初始種子(seed)
H_1 = Hash(H_0)
H_2 = Hash(H_1)
H_3 = Hash(H_2)
...
H_n = Hash(H_{n-1})

這是一個單線程、無法平行的「時間證明序列」，因為每一步都依賴前一步輸出。

2.2 時間證明特性：

- PoH 製造者每過一段固定計算時間就**記錄一個 hash**
- 可在特定 hash 號碼（slot）上嵌入事件（如交易、區塊產生）
- Slot

在 Solana 中，**slot 就是一個「區塊時間單位」**，大約每 400 毫秒一次。

機制上：

- 每個 slot 對應 PoH 中的一段 hash 計算（比如一萬次 hash = 一個 slot）
- 每個 slot 有可能由某個 Leader 製作區塊
- 若該 slot 被跳過（沒有成功產出區塊），網路會自動前進到下一個 slot

在 PoH 中的意義：

- 每筆交易對應一個 slot 編號（slot number）
- 所有節點都知道：「第 X slot 是在哪個 hash 序列點發生的」，可用來對齊事件順序

- 所有人都可以快速驗證「這個 hash 是按順序算出來的，沒有造假」

範例流程：

1. 節點 A 開始連續計算哈希（PoH 序列）
2. 在第 1000 個 hash 時插入一筆交易 tx_1
3. 在第 1010 個 hash 時插入一筆交易 tx_2
4. 廣播這個序列給所有人（這稱為 PoH Recorder）

其他節點收到序列後：

- 驗證連續 hash、slot 對應關係與交易位置、簽名與格式一致

### 3. Tower BFT（Byzantine Fault Tolerance）

3.1 拜占庭問題簡述：

- 系統中有多個節點
- 一部分節點可能惡意、傳遞錯誤訊息（拜占庭節點）
- 要**設計一個演算法讓誠實節點仍能就事件達成一致**

理論結論（在同步網路中）：

- 想容忍 f 個拜占庭節點，需要至少 n ≥ 3f + 1 的節點總數
- 也就是說，**最多可以容忍三分之一節點作惡**。

3.2 核心概念：**Vote Lockout（投票鎖定）**

1. 每個節點會對特定 PoH slot 上的提案「投票」
2. 一旦你對某個 slot 高度投票且達成 quorum（達到 2/3 多數）：
- 你就「鎖定」這個 slot 為你的最終版
- 未來不能再對更早的 slot 投票（**避免分叉**）
3. 投票邏輯簡化公式（概念）

假設節點 A 已對 slot 100 投票成功（鎖定）

那麼直到 slot 110（等待期過後），它只能對 slot ≥ 100 的提案投票

若你亂跳回 slot 95 投票 → **違反鎖定 → 失去罰金**

這樣設計是為了避免**投票反悔與雙重簽名（double voting）**，從而**提高鏈的最終性保障**。

4. Lockout 的設計帶來：
- **安全性**（不能亂改決策）
- **最終性**（一旦超過 2/3 多數，就永遠不能回頭）
- **高效能**（因為利用 PoH 已排序好的順序作為基礎）

Tower BFT vs 傳統 PBFT 差異

| 項目 | PBFT | Tower BFT |
| --- | --- | --- |
| 時間處理 | 無全局時間觀 | 建立於 PoH 時序 |
| 通訊複雜度 | 每輪需全員互傳 | 節點根據 PoH 位置自行投票 |
| 最終性機制 | 多輪溝通達共識 | Slot 鎖定（Vote Lockout） |

### **新版：Alpenglow 共識機制**

### 4. 背景問題：PoH + Tower BFT 雖快但有三大問題：

1. **驗證成本高**：節點需要下載整段 PoH hash 序列 → 資源吃緊
2. **同步性差**：新節點或觀察節點要同步狀態很花時間
3. **資料容量膨脹**：每筆交易與歷史都需鏈接在一長串哈希鏈裡

### 5. Alpenglow 核心概念：Succinct Commitments + Quorum Voting

**5.1 Succinct Commitment** （簡潔承諾）

- 是一種極短的資料摘要，可以用來「承諾」某些特定資訊存在，但不必顯示出該資訊本身。之後只要給一個「證明（witness）」就能讓任何人快速驗證這個承諾是否正確。

→一個小而不可偽造的加密摘要，「壓縮整個歷史、整筆交易、整個狀態」為一個小的代碼，為一段資料的承諾，**大家只要信這個代碼，就不用一直重新計算全資料了**。

1. **建立 Commitment（承諾）**
- 把一段資料（例如交易列表、區塊狀態）做哈希運算或建構一個類似 Merkle Tree或更複雜的代數結構
- 最終得到一個小的 hash / polynomial value / fingerprint
- 這個值就是你「承諾的摘要」，不可逆、不可造假
2. **發布 Commitment**
- 將這個小值（比如 32 bytes）放到區塊或共識訊息裡廣播出去
- 所有人只需儲存這個小摘要
3. **日後驗證（提供 witness）**
- 有人來說：「某筆交易 txA 是在你當初承諾的資料裡面」
- 他提供一個 **witness**：這筆交易、以及對應的 Merkle branch 或 polynomial proof
- 所有人用 Commitment + Witness → 可以快速算出是否真的存在

| 特徵 | Merkle Tree | Succinct Commitment（泛稱） |
| --- | --- | --- |
| 資料結構 | Binary Hash Tree | 可用多種代數結構，如 polynomial commitment |
| 驗證效率 | 快 | 有些更快、更小、更彈性 |
| 支援資料型態 | 樹狀交易資料 | 更通用，例如虛擬機狀態、任意計算結果 |
| 節點負擔 | 輕量但還需哈希鏈 | 可壓得更小、驗證更快 |
| 舉例 | Bitcoin 的 SPV （Simplified Payment Verification）證明 | Ethereum zk-SNARK proof、Alpenglow 承諾 |

5.3 State Witness

- 定義：State Witness 是**輔助性資料結構，用來證明某筆資料（例如一筆交易、一個狀態變化）存在於某個 succinct commitment 中的證明資料**。
- 告訴驗證者：「某筆帳戶資料、某個交易、某個狀態變數，確實存在於這棵狀態樹裡。」
- 它 **不會自己給出結論**，還要搭配：
- 狀態轉換邏輯、root hash 、過去區塊的共識規則等，才能「驗證」它。
- 像是「把你需要的東西都準備好，你自己算一遍就能驗證有沒有問題。」
- 類似 Merkle Tree 中的「Merkle Proof」
- Merkle Tree 中某筆資料的 Merkle 路徑（Merkle proof）就是一種 state witness，但還需要root hash 才能完成驗證。

Alpenglow的應用

- 當一個區塊被壓縮成 succinct commitment（例如 hash C1）
- 未來若有人要證明：「某筆交易 tx1 在 C1 中」
- 他只需附上一個 witness（例如：tx1 + 對應 Merkle 分支或承諾結構）
- 驗證者根據 witness 和 commitment，就可以**快速驗證該交易的存在性與合法性**

5.4 Quorum Voting

- 定義：Quorum Voting 是指在共識系統中，**當一組節點中達到某個門檻比例的同意，就可以視為「通過」的投票機制**。
- 傳統拜占庭容錯（BFT）共識中，常見的門檻是「超過 2/3 的節點簽署」
- 在 Solana 的 Alpenglow 裡：
- 節點根據他們所見的 succinct commitment 進行簽名
- 當超過 2/3 的節點都對這個 commitment 投下「同意票」
- 那麼這筆交易（或區塊）就被認定為達成共識（finalized）
- 「Quorum」原意是「法定人數」，在共識中表示「夠多的節點參與同意這個決定」
- 避免少數節點就能操縱決策 → 強化去中心化與安全性

### 6. Solana新舊機制比較

關鍵改善點：

| 問題類型 | PoH 機制 | Alpenglow 機制 |
| --- | --- | --- |
| 同步新節點 | 必須重跑整段 hash 序列 | 僅需驗證承諾與小量證明 |
| 觀察者負擔 | 下載全狀態 + 歷史 | 僅驗證 succinct commitment |
| fork 對抗力 | 依賴鎖定與過去序列 | 快速驗證哪個承諾獲多數簽名 |

PoH + Tower BFT vs Alpenglow 比較表

| 項目 | PoH + Tower BFT | Alpenglow |
| --- | --- | --- |
| **時間排序依據** | PoH hash 序列 | 預設共識節奏 + 承諾區間 |
| **資料驗證方式** | 驗證整段哈希鏈 + 投票 | 驗證 succinct commitment + 小量 witness |
| **最終性達成方式** | 投票 + lockout 延遲確認 | 快速簽章聚合，獲 2/3 即 finality |
| **新節點同步負擔** | 下載 PoH 全歷史並重播 | 僅需下載最新 commitment 並驗證 |
| **觀察者參與成本** | 高 | 低 |
| **Fork 抵抗力** | 靠投票與鎖定防分叉 | 基於簽名數量快速判定主鏈 |
| **可擴展性與未來性** | 遇到 hash 鏈膨脹問題 | 支援 sharding、模組化，設計為未來可擴展協議 |
| **核心演算法特性** | 線性 hash 運算 + 鎖定 | 非交互式承諾驗證 + 聚合簽章 |
| **驗證資料大小** | 很大（全鏈狀態） | 小（承諾 + 證明） |

1. Anza簡報訪談摘要

Solana 推出全新共識機制「Alpenglow」，目標是大幅降低交易延遲、簡化節點驗證負擔，為鏈上應用帶來近乎 Web2 的使用者體驗。根據官方與測試數據，Alpenglow 成功將交易延遲縮短 **超過 98%**，理論上可達 **400 毫秒以下**，與 **VISA** 等傳統金融系統的處理速度相當，成為區塊鏈領域少數能接近 Web2 即時反應水準的公鏈架構。

Alpenglow 的核心技術是 **succinct commitments**（簡潔承諾），透過加密承諾壓縮區塊與交易資訊，使節點無需下載完整歷史即可驗證狀態，有效降低全節點與觀察節點的同步成本。這種共識設計在不犧牲安全性的前提下，讓更多設備能輕量參與驗證與共識，有助於區塊鏈實現高擴展與去中心化的平衡。特別值得注意的是，Alpenglow 的驗證與簽章機制並非直接在區塊鏈上執行，而是部分在 **Web2 架構環境中完成後提交鏈上結果**，這種設計也成為其實現極低延遲的技術關鍵之一。

儘管 Alpenglow 帶來顯著的性能優化，**目前仍無法直接解決 Solana 過去曾多次出現的服務中斷問題**。這些中斷主要來自於節點實作的單點瓶頸與過度集中等基礎層問題。Solana 團隊也坦言，**真正針對可用性與穩定性的大規模優化，將仰賴另一個正在開發中的驗證客戶端 Firedancer**。Firedancer 將以 C 語言重寫 Solana 驗證器邏輯，目標是大幅提升處理效能與系統抗錯能力，預計於未來主網推出。

Alpenglow 是 Solana 在共識設計上的重要升級，讓其在延遲與可用性上更接近傳統金融網路，並鋪設了進一步強化可用性與抗錯性的基礎。