Block Verification 是統整區塊鏈資訊重要的一步，總不能領導者說了算吧！如同議會審查政府一樣，當政府想要改變現在國家狀態時，議會要檢查政府推出來的方案是否正確，對其進行投票，當獲得大部分議員的投票後才通過決策，改變國家現狀。讀完本章您將會了解 Solana 的節點如何驗證從 Turbine Tree傳過來的交易， Solana 的驗證機制有什麼優點，以及投票究竟是什麼？
提醒讀者：如果您尚未閱讀過或想先了解 Solana 的基本運作流程，建議先參考 **由 Transaction 的生命週期看 Solana 的底層架構 ，**這將有助於您更好地理解本篇深入探討的技術細節。
如同領導者是用 TPU 處理交易，驗證者是用 Transaction Validation Unit (TVU) 來處理交易並投票。 TVU 首先會透過 Shred Fetch Stage 去獲取從 Turbine Tree 傳來的 shreds，並進入 Shred Verify Leader Sig Stage 做簽名驗證，需要確保這些 shreds 的發送人是當下的領導者（因為每個驗證者自己都會有一個 PoH 時鐘，所以每個驗證者自己會知道當下的領導者是誰）確定發送人沒有問題之後，就進入 Retransmit Stage 將這包 shreds 透過 Turbine Tree 往下傳送，再進入 Replay Stage。
Replay Stage 首先會將 shreds 還原成 entry（或稱為 block），如此便可以得到一串交易跟領導者執行完這串交易後的 bank 狀態，而驗證者也會在自己的 bank 中執行這一連串交易並檢查是否自己的最終狀態與領導者的最終狀態相同。如果相同，就會對此 block 投票表示贊同並更新自己的 bank 狀態。
但這邊要特別注意驗證者在「執行一串交易並檢查最終狀態」的過程並不是像領導者一樣執行完交易1再執行交易2再執行交易3…而是平行化的處理每一筆交易。因為其實 block 裡面包含的是領導者的 bank 經過每一筆交易後狀態的 hash 值，且這些 hash 值是連續的，即第 i 個 hash 是由第 i-1 個 hash 計算出來的結果，所以驗證者在「已經拿到所有交易的 hash 值 」以及「有多顆核心」的情況下，可以一次同步計算 hash 之間的正確性（如下圖）。如此一來就達到「領導者生產區塊很慢，但驗證者可以很輕易驗證區塊」的特性，這也是為什麼 Solana 出塊的速度這麼快，因為領導者只需要不斷地出塊就好，驗證結果之後驗證者可以一次傳回來。
flowchart LR
Validators:::fix --core1--> hash100[Hash
100] --sha256--> Hash101[Hash
101]
Validators --core2--> hash101[Hash
101] --sha256--> Hash102[Hash
102]
Validators --core3--> hash102[Hash
102] --sha256--> Hash103[Hash
103]
Validators --core3--> hash103[Hash
103] --sha256--> finalState[Final
State]
finalState --> Leader
%% style %%
classDef fix min-width:280px
而所謂的投票其實就是發送一筆交易給領導者，他會跟其他一般的交易走一樣的流程被處理，所以驗證者也需要支付手續費，這是驗證者需要為自己投票負責的其中一個成本。而由於這些投票交易數量非常龐大且通常與使用者無關，所以在 Solscan 上會隱藏這些交易，但只要打開設定就可以看到在一個 slot 中究竟有多少投票的交易了（如下圖）～
