引言
延續上一篇介紹交易從 RPC 節點傳送至 Leader 的內容，本篇將探討 Leader 在收到交易後如何驗證、更新並構建區塊。
區塊構建對區塊鏈網絡的效率和安全性至關重要。Solana 採用 連續區塊構建 和 Proof of History (PoH) 機制，大幅提升處理速度、擴展性和資源利用效率。本文將深入解析 Solana 的區塊構建流程，並說明 PoH 如何像一個「世界鐘」一樣協調所有節點的運作，確保網絡的同步和高效運行。
提醒讀者：如果您尚未閱讀過或想先了解 Solana 的基本運作流程，建議先參考「由 Transaction 的生命週期看 Solana 的底層架構」 ，這將有助於您更好地理解本篇深入探討的技術細節。
回顧：Solana 的領導者機制
Solana 的每個「時間槽」（slot）持續 400 毫秒，並且每個「領導者」（Leader）在其任期內會連續處理四個時間槽（總共 1.6 秒），然後再由下一個領導者接替。在成為領導者之前，節點會提前兩個時間槽停止接收新交易，專注於處理即將到來的工作量。在這段準備時間內，整個網路的流量會集中到這個即將成為領導者的節點，流量峰值甚至可以達到每秒數 GB。
1. 什麼是連續區塊構建？
在大多數區塊鏈中，區塊構建是以批次形式進行的。也就是說，當交易池中的交易數量達到一定數量後，才會開始將這些交易打包成區塊並添加到區塊鏈上。然而，Solana 採用了「連續區塊構建」的方式，這意味著它在處理交易時是持續進行的，而不是等待交易累積到一定數量後再開始處理。這種方法能夠大幅降低交易延遲時間，使得交易能夠更快地完成。
2. 交易處理的工作流程
當交易進入 Solana 的 交易處理單元（TPU） 後，首先經歷一系列的處理階段，確保交易的有效性和正確性，並最終由 Solana 的虛擬機（SVM）執行。以下是交易處理的具體步驟：
2.1 Fetch Stage：
- 交易首先通過 QUIC 協議進入 TPU。QUIC 是一種快速、可靠的傳輸協議，專門設計來高效處理網絡數據。這一階段確保交易能夠快速地傳送到 TPU 進行下一步處理。
2.2 SigVerify Stage：
- 在這個階段，系統會驗證交易的簽名，確保每筆交易簽名的有效性。同時，該階段也會檢查是否存在重複的交易，並將重複的交易過濾掉，保證每筆交易都是唯一且合法的。
2.3 Banking Stage：
- 驗證過的交易會進入「 Banking 階段」，『 Bank 』代表 Solana 區塊當前的狀態。每個區塊都有一個對應的「Bank」，用來存取和更新該區塊的狀態數據。
- 在這個階段，交易會被分組並提交到 Solana 虛擬機（SVM）進行執行。這些交易分組稱為「Entries」，每個「Entries」包含 64 個不衝突的交易。
- Solana 的並行交易處理能力使其能夠同時處理多個交易。這得益於 Solana 要求每個交易都列出所有將讀寫的帳戶，確保不同交易之間不會產生衝突。
2.4 執行和狀態更新：
- 在 SVM 執行交易邏輯之前，相關的帳戶會被鎖定，以防止其他交易在同時訪問和修改相同的帳戶。然後，系統會檢查交易是否是最近的（RecentBlockHash），並確保該交易未被重複處理。
- 當交易邏輯執行完成後，帳戶的狀態會被更新，並將這些變更記錄到區塊鏈中。
2.5 歷史證明（Proof of History）：
- 交易執行完成後，每個交易條目的哈希值會被發送到 Solana 的「歷史證明」中進行記錄，這確保了每筆交易的順序和一致性，最終確保網絡中所有節點達成共識。（可參考後續內容）
不衝突的交易 : 指那些在同一時間段內執行時，不會對相同帳戶進行同時的寫入操作，或不會出現一個交易寫入和另一個交易讀取相同帳戶數據的情況。
3. Proof of History : Solana的時鐘
在眾多區塊鏈技術中，Solana 以其極高的交易速度和可擴展性脫穎而出，而這一切的背後，是一個稱為 Proof of History (PoH) 的核心技術。PoH 不僅是 Solana 高效運作的基石，也是它在眾多區塊鏈中脫穎而出的秘密武器。
3.1 什麼是 Proof of History (PoH)?
Proof of History 是 Solana 的獨特時間戳技術，類似於每個驗證節點中的特殊時鐘，負責促進網絡中的同步。與常見的工作量證明（Proof of Work）不同，PoH 並不是一種共識算法，而是一種確保事件順序和時間流逝的可靠方法。它的作用之一是確保網絡中的領導者（Leader）能夠按照計劃進行工作。
3.2 PoH 如何解決傳統區塊鏈的挑戰？
隨著網絡規模擴大，節點間的通信開銷會增加，協調變得越來越困難。Solana 通過 PoH 的本地計算來減少節點間的通信，驗證者只需要一輪投票即可完成區塊的提交。這一過程中的消息會附帶可信的時間戳，確保驗證者無法過早開始構建區塊，必須等待特定時間後才能提交區塊。
3.3 PoH 的運作機制
PoH 依賴於 SHA256 哈希算法的獨特特性來實現其功能：
- 確定性：相同的輸入總是會產生相同的哈希值。
- 固定大小：無論輸入大小如何，輸出哈希總是 256 bits。
- 高效性：計算任何給定輸入的哈希值都很快。
- 原像抵抗性：從哈希輸出中找到原始輸入在計算上是不可行的。
- 雪崩效應：微小的輸入變化會導致顯著不同的哈希值。
- 碰撞抵抗性：找到兩個不同的輸入產生相同的哈希值是不可行的。
每個驗證節點內的 PoH 持續運行 SHA256 哈希算法，創建一條哈希鏈。每個哈希的輸入是前一個哈希的輸出，這樣的哈希鏈保證了結果必須按順序計算，未來的哈希結果無法提前知道。這種鏈條就像是一種「微型的工作量證明」，雖然生成這些哈希鏈需要時間，但其他驗證者可以快速平行地驗證這些哈希的正確性。
3.4 PoH 在實踐中的應用
在領導者期間，PoH 服務會接收並處理來自 Banking 階段的新交易「Entries」。這些交易「Entries」與當前的 PoH 哈希結合，生成下一個 PoH 哈希，這個過程同時充當時間戳，將交易條目插入哈希鏈，確保交易順序和時間流逝的記錄。
在一個區塊中，Solana 會產生 800,000 個哈希，並包含「ticks」= 「Empty Entries」 ，表示領導者的活動狀態和時間流逝。每個 tick 表示約 6.25 毫秒，每個區塊總共有 64 個 ticks，整個區塊時間為 400 毫秒。
3.5 PoH 的重要性
即使在驗證者不是當前的領導者時，他們也會持續運行 PoH 時鐘，這對於保持整個網絡的同步至關重要。PoH 的這種結構確保了 Solana 區塊鏈能夠以極高的速度和安全性運行，同時降低了節點間的通信開銷，這也是 Solana 能夠脫穎而出的關鍵原因。
Takeaways:
T1. 連續區塊構建：
Solana 採用了連續的區塊構建方式，能夠持續處理交易，而不是以批次進行，這大大降低了交易的延遲時間並加快了整體運行速度。
T2. 並行處理交易：
Solana 要求每筆交易列出其要讀寫的帳戶，這使得不同交易不會發生衝突，從而實現多筆交易的並行處理，最大化吞吐量並減少交易瓶頸。
T3. 歷史證明 (PoH)：
Solana 的 PoH 機制像一個「世界鐘」，確保所有節點保持同步，使網絡能夠高效運行，同時減少節點之間的通信開銷，提升安全性和共識效率。