---
title: "歷史證明：記錄的排序、刻度、插槽和共識邊界"
description: "歷史證明是 Solana 的順序哈希鏈時鐘：它使生產者記錄的順序和計算計數可驗證，但不能獨立證明掛鐘時間、公平交易到達順序、分叉選擇或最終性。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 歷史證明：記錄的排序、刻度、插槽和共識邊界

> 僅供協定分析教育參考，不構成投資、驗證者營運、效能或安全建議。歷史證明參數、用戶端行為、領導者排程、投票、分叉選擇與確認規則可能因網路和軟體版本而變更。

<a id="answer"></a>

## 直接回答

歷史證明，或 PoH，是 Solana 的加密時鐘和帳本排序資料結構。生產者重複應用雜湊函數，以便每個輸出都依賴先前的輸出，定期記錄計數和狀態，並將交易衍生的資料混合到鏈中。驗證者可以重新計算這些轉換並確認該特定鏈記錄的順序。

PoH 不是獨立的共識演算法。它不會選擇規範分叉、形成質押加權共識、最終確定區塊，也不能證明交易在特定現實時間到達網路。Solana 將這套時鐘與領導者排程、交易執行、驗證者投票、分叉選擇及 Tower BFT 式鎖定結合。兩個分叉都可能包含內部有效的 PoH 序列；共識規則決定網路採用哪段歷史。

這項保證的範圍有限。如果條目在狀態 h2 之後承諾資料 d，缺少該承諾就無法計算後續狀態 h3 = H(h2 || d)。這表明生成者在計算 h3 前已知 d，並固定其相對於後續輸出的位置。它並不說明每個驗證者何時收到 d、領導者是否按到達順序納入交易、d 是否描述真實的外部事件，或該條目是否成為規範歷史的一部分。

生成是連續的，因為直到前一個雜湊存在才知道下一個輸入。已發布的邊界狀態允許驗證者並行重播單獨的有界段，但聚合雜湊工作仍然存在。因此，PoH 經常與可驗證的延遲函數進行比較，而 Solana 自己的 Tower BFT 解釋稱其為對該術語的寬鬆使用；正式的 VDF 通常具有評估和驗證接口，其驗證相對於順序評估相對的驗證相對。

<a id="mechanism"></a>

## 如何分析歷史證明

1. **明確網路與軟體環境。** 記錄網路、創世雜湊、Slot、紀元、Agave 或其他用戶端版本以及觀察時間。讀取 hashes_per_tick、ticks_per_slot、ns_per_slot 等實際生效的值；不要沿用舊文章或其他叢集的常數。
2. **重建哈希鏈。** 從受信任的前驅狀態開始，驗證每個條目的 num_hashes，產生的雜湊值和交易清單。在 Agave 的條目實作中，條目識別碼取決於前一個條目，並且當存在交易時，也取決於從其簽章派生的雜湊值。
3. **驗證刻度和槽位置。** 根據銀行和記錄器規則檢查刻度條目、預期雜湊計數、刻度高度和最大刻度高度。記錄器使用配置的 ticks_per_slot 將刻度高度映射到插槽中；時隙是協定間隔，而不是來自外部時脈的獨立證據。
4. **區分包容和到達。** 承諾證明輸入在其插入該序列之前是已知的。若要聲明下限，請識別先前 PoH 狀態的簽章反向引用。這兩個界限都不能證明全域首見順序、記憶體池公平性或可信的 UTC 時間戳記。
5. **將生成與驗證分開。** 測量一個依賴鏈上的順序生產，然後使用經過驗證的段邊界和可用核心測量重播。報告總哈希值、關鍵路徑延遲、聚合驗證器工作和邊界資料假設，而不是僅僅說驗證「快」。
6. **追蹤共識路徑。** 識別預定的領導者、銀行狀態、投票、鎖定、分叉選擇規則、固定或最終確定的狀態和承諾等級。一條有效的 PoH 鏈仍然可以屬於一個失敗的分叉，並且單獨一個較長的計數器並不是共識證書。
7. **強調對抗性和操作性案例。** 測試領導者模棱兩可、事務遺漏和重新排序、跳過插槽、分區、更快或校準錯誤的硬體、無效的滴答計數、延遲重播、帳本不可用、客戶端分歧以及相關操作員或基礎設施控制。

審查輸出應區分四個聲明：序列有效性、配置的協議時間、共識狀態和外部時間。說明哪些起始雜湊值和帳本資料是可信的，哪些雜湊值被重新計算，哪些投票或承諾證據被檢查，哪些觀察結果來自本地時鐘或第三方服務。

<a id="example"></a>

## 工作範例

### 1. 資料插入固定記錄位置

考慮 h1 = H(h0)，然後考慮 h2 = H(h1)。生產者插入交易衍生的承諾 d 併計算 h3 = H(h2 || d)，然後是 h4 = H(h3)。任何重播相同操作的人都可以驗證記錄的鍊是否在 h2 和 h3 之間提交了 d，並且 h4 取決於結果。

上限聲明很窄：生產者在計算 h3 之前就知道 d。如果簽署的交易本身引用了 h1，則驗證者還可以表明它是在了解早期狀態後形成的，並接受簽名和來源檢查。如果沒有這樣的反向引用，PoH 單獨不提供下限。這兩種情況都無法證明另一個節點首次收到交易的時間。

### 2. 分段重播可減少延遲，而不是聚合工作

假設記錄的間隔包含 1,000,000 個雜湊值，經過驗證的檢查點將其分為 10 個段，每段包含 100,000 個雜湊值。如果有足夠的內核，可以同時重播十個段，因此掛鐘驗證延遲可能接近一個段的持續時間加上開銷。

驗證者總共仍執行 1,000,000 次雜湊；檢查點暴露了獨立的起始狀態，但不會將鏈變成簡潔的證明。效能取決於硬體、調度、記憶體移動和邊界置信度。這就是為什麼並行 PoH 重播不應自動描述為每個正式 VDF 構造的有效驗證演算法。

### 3. 刻度和槽算術取決於配置

假設使用 hashes_per_tick = 100,000 和 ticks_per_slot = 8 進行說明性配置。然後，完全散列的插槽包含 100,000 * 8 = 800,000 散列，在每個配置的間隔之後帶有刻度邊界。更改任一參數都會更改映射；這個例子不是目前的主網常數。

Agave 也支援無法用這項簡化乘法概括的雜湊計數設定。審核者應取得 Bank 的實際欄位，並依用戶端規則驗證條目。把 Slot 或計數換算為秒還取決於目標時長校準和實際執行情況，而不只是密碼學驗證。

### 4. 記錄順序不等於到達順序或最終性

假設事務 A 在事務 B 之前到達領導者，但領導者記錄 B 接近計數 300,000，A 接近計數 450,000。有效的 PoH 證明 B 在產生的序列中先於 A。它並不能證明 B 先到達、排序是公平的或另一個領導者遵守相同的順序。

現在假設一個分區產生叉 X 和叉 Y，每個叉都有一個有效的序列。 PoH 驗證可以拒絕任一分叉上的畸形條目，但不會選擇 X 或 Y。領導者時間表、權益加權投票、鎖定、分叉選擇和請求的承諾等級決定共識結果；應用程式不得以 PoH 計數來取代確認或最終證據。

<a id="risks"></a>

## 風險和審查失敗

### 密碼和計時錯誤

- 將 PoH 稱為可信任掛鐘或獨立聲明雜湊計數可以證明 UTC 時間戳記。
- 說交易包含證明了全網接收時間、首見順序或外部資料的真實性。
- 假設順序產生可以防止生產者保留、省略或選擇何時插入已知資料。
- 將碰撞阻力單獨視為硬體速度、校準漂移或實現變異數的完整限制。
- 將平行段重播描述為零工作或作為不計算聚合雜湊的簡潔證明。
- 將 PoH 稱為正式的 VDF，而不說明要比較的構造、證明介面和驗證假設。
- 信任檢查點邊界、前驅哈希或下載的帳本片段，而不驗證其來源。

### 共識和協議錯誤

- 稱PoH共識、權益證明、Tower BFT、領導者選舉、分叉選擇和最終性相同的機制。
- 假設具有最高計數的有效序列必須是規範的，而不檢查投票和分叉選擇狀態。
- 將本地重播的條目視為已確認、已確定或最終確定，而不檢查所要求的承諾語義。
- 把歷史 hashes_per_tick、ticks_per_slot 或 Slot 時長當成普遍適用的目前常數。
- 重建順序時忽略跳過的槽、領導輪替、分區、模稜兩可和客戶端版本差異。
- 比較來自不相關分叉或起始狀態的計數，就好像它們屬於一個經過身份驗證的序列一樣。
- 假設交易的最近區塊哈希只是一個掛鐘時間戳而不是協議有效性上下文。

### 操作、效能和控制錯誤

- 僅對哈希生成進行基準測試，而忽略執行、簽名驗證、重播、頻寬和儲存。
- 將理論段並行性與 CPU、I/O 和記憶體爭用下觀察到的驗證器追趕等同起來。
- 忽略滴答驗證失敗、記錄器停頓、銀行延遲、帳本間隙、快照信任和損壞的狀態。
- 當用戶端、主機、網路、領導者基礎架構或控制共用時，將驗證者身分視為獨立的。
- 假設更快的硬體可以消除網路延遲、封包遺失、審查、拒絕服務或權益集中風險。
- 提供目標時隙持續時間、吞吐量估計或舊基準作為服務水準保證。

<a id="misconceptions"></a>

## 常見的誤解

- **PoH是Solana的完整共識演算法。** PoH 提供可驗證的記錄序列；驗證人投票、鎖定、分叉選擇和其他共識規則決定了網路遵循的歷史。
- **PoH 證明每筆交易的精確現實時間。** 它證明已驗證序列內的相依關係與計數；把序列映射到現實時間還需要設定與外部觀察。
- **PoH 保證交易排序公平。** 領導者可以在協定與資源限制內選擇、延遲、重排或省略輸入；PoH 只讓最終記錄的順序可稽核。
- **PoH是工作量證明挖礦的另一個名字。** 都使用哈希，但 PoH 的核心作用是順序時鐘，而不是獲勝作品選擇鏈的開放並行競賽。
- **任何有效的 PoH 序列都是最終序列。** 競爭的分叉可能各自在內部有效；確認和最終確定需要網路的共識證據。

<a id="related"></a>

## 相關主題

- [共識機制](/zh-tw/crypto/consensus-mechanism/)
- [權益證明](/zh-tw/crypto/proof-of-stake/)
- [驗證者](/zh-tw/crypto/validator/)
- [分叉選擇規則](/zh-tw/crypto/fork-choice-rule/)
- [區塊時間](/zh-tw/crypto/block-time/)

<a id="sources"></a>

## 來源

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST（瀏覽：2026-08-19）
- [Solana: A New Architecture for a High Performance Blockchain](https://solana.com/solana-whitepaper.pdf) - Solana（瀏覽：2026-08-19）
- [Tower BFT: Solana's High Performance Implementation of PBFT](https://solana.com/news/tower-bft--solana-s-high-performance-implementation-of-pbft) - Solana（瀏覽：2026-08-19）
- [Agave Entry Module](https://github.com/anza-xyz/agave/blob/master/entry/src/entry.rs) - Anza（瀏覽：2026-08-19）
- [Agave Proof-of-History Recorder](https://github.com/anza-xyz/agave/blob/master/poh/src/poh_recorder.rs) - Anza（瀏覽：2026-08-19）
- [Agave Bank Runtime](https://github.com/anza-xyz/agave/blob/master/runtime/src/bank.rs) - Anza（瀏覽：2026-08-19）
- [Transaction Confirmation and Expiration](https://solana.com/developers/cookbook/transactions/confirmation) - Solana（瀏覽：2026-08-19）
- [Verifiable Delay Functions](https://eprint.iacr.org/2018/601) - IACR 密碼學 ePrint 檔案（存取：2026-08-19）

Source: https://wiki.fcontext.com/zh-tw/crypto/proof-of-history/index.mdx