驗證帳本
客戶、供應商或審計方如何獨立驗證一個 Open Tally 帳本——離線驗證器、公開端點與精確的驗證流程。
整個構造的意義所在：不信任運營方的對手方，依然能查帳。 本頁以 linkex.ai 實例為對象描述驗證；流程屬於協議，對任何實例都成立。
貫穿全程的前提：你不需要相信 linkex 的任何一句話，也不需要帳號。你需要的是 curl、驗證器，以及——鏈上那一段——任意一個公開的 Base 區塊瀏覽器。
驗證器
驗證用一個零依賴、完全離線的命令行驗證器（linkex-verify，約 3.7 MB 的單一靜態二進制）。離線是設計要求而非便利：一個會悄悄聯網的驗證器，可以被接電話的那一方欺騙。這個工具：
- 驗證單條證據包（
-bundle）或整個期間（-period），逐項報告 PASS / FAIL / SKIPPED，每個跳過都附原因——跳過的檢查絕不計為通過； - 在每個結果旁邊印出該檢查不確立什麼；
- 支持嚴格模式（
-strict）、釘住 TSA 信任根（-tsa-roots）與機器可讀輸出（-json）； - 退出碼：
0全部可跑檢查通過，1有失敗，3（加-strict）有檢查未能運行。
開源
驗證器、回執規範與一致性向量以 Open Tally 名義發布——GitHub org
opentallyprotocol、npm scope
@opentally。linkex.ai 的對手方今天直接獲得這套工具；
公開發布請關注該 org。你也可以自行實現一個驗證器——
規範正是為此而寫，而且那是更強的立場：你不必信任運營方遞給你的二進制。
第 0 步：釘住時間戳根證書
在一切之前，取時間戳機構的根證書並核對指紋：
curl -sLo digicert-g4.pem https://cacerts.digicert.com/DigiCertTrustedRootG4.crt.pem
openssl x509 -in digicert-g4.pem -noout -fingerprint -sha256
# 55:2F:7B:DC:F1:A7:AF:9E:6C:E6:72:01:7F:4F:12:AB:F7:72:40:C7:8E:76:1A:C2:03:D1:D9:D2:0A:C8:99:88這一步不是可選的，且原因本身很有教益。不帶 -tsa-roots 時，驗證器回退到宿主系統的信任庫——同一枚有效的 DigiCert 令牌在 Linux 上驗證通過、在 macOS 上被拒。同一份數據、同一個程序，結論取決於誰在提問。當結論不該取決於哪台機器提問時，釘根證書是前提，不是優化。下面每條命令都帶 -tsa-roots digicert-g4.pem。
三分鐘：核一筆具體的帳
爭議通常是關於某一筆的。這是最短路徑：
# 1) 找到你關心的流與序號範圍
curl -s "https://linkex.ai/api/receipt/commitments?page_size=50" | less
# 2) 取那一筆的證據包
curl -sf "https://linkex.ai/api/receipt/bundle?stream=ch:10&seq=2" -o receipt.json
# 3) 驗——從這裡起完全離線
./linkex-verify -bundle receipt.json -tsa-roots digicert-g4.pem證據包攜帶該回執及其前後鄰（鏈連續性因此可查）、完整密鑰歷史、所屬期間承諾與 Merkle 包含性證明——驗證所需的一切，無需再訪問 linkex 的任何系統。
讀結果：
0 failed是要看的那一個數。 任何failed都意味著 linkex 的記錄與它自身的密碼學承諾不符——把驗證器的完整輸出發給 linkex；那是他們那邊的事故。skipped不是passed。 報告會解釋每個跳過。特別地，供應側的包按設計跳過零售拆解——第七項檢查解釋了為什麼對供應商而言6 passed, 1 skipped就是滿分。
十分鐘：核一個期間
curl -sf "https://linkex.ai/api/receipt/period?stream=ch:10&sample=200" -o period.json
./linkex-verify -period period.json -tsa-roots digicert-g4.pem這會檢查整個期間的承諾鏈、密鑰歷史與時間戳令牌，外加一份帶包含性證明的抽樣回執。關於樣本要懂兩件事：
- 樣本是抽出來的，不是挑出來的。 種子是該期間最後一個承諾的哈希——一個在抽籤可能發生之前就已被簽名並固定在時間上的值——抽籤規則公開，你可以自行復算任意回執的成員資格。linkex 若塞入一條未被抽中的回執，Merkle 包含性直接 FAIL。
- 結論不是 PASS，而是印出的漏檢概率。 報告會說明「這樣大小的樣本漏掉一條被篡改回執的概率是多少」。要更強的界？提高
sample，或協商一次限定範圍的全量披露。完整語義見證明包。
連組裝也不信：自己拼包
上面兩步中，包是 linkex 組裝的。如果連組裝過程都不想信，就只用兩個原始公開端點與公布的 jq 配方：
curl -s "https://linkex.ai/api/receipt/commitments?stream=ch:10&page_size=200&include_tokens=1" > c.json
curl -s "https://linkex.ai/api/receipt/keys" > k.json
jq -n --slurpfile c c.json --slurpfile k k.json -f period-bundle.jq > mine.json
./linkex-verify -period mine.json -tsa-roots digicert-g4.pem配方（period-bundle.jq）隨交付物提供，且由 linkex 自己的 CI 實際執行，不可能與端點的響應形狀漂移。自拼的包只覆蓋承諾層——證明帳本完整、已簽名、已固定時間，但不證明回執寫的是什麼（那需要抽樣回執，見上）。兩條路徑互補，都請保留。
然後核到鏈上
對任何已錨定的窗口，從透明頁出發，按五步流程一路走到 Base 上一筆已確認的交易——最後兩步直接對照公鏈，全程與 linkex 無關。
完整流程，按序
釘住 TSA 根證書
取時間戳機構根證書並核對指紋（上面第 0 步）。
驗承諾與時間固定
承諾簽名、承諾鏈、對照你釘住的根驗 RFC 3161 令牌，以及——已錨定窗口——Base 上的鏈上錨。
驗你的回執
對披露給你的回執：對照公開密鑰歷史驗簽、序號連續性、哈希鏈連續性、Merkle 包含——大規模用抽樣，限定範圍則逐筆。
重算金額
按回執內部記錄的單價、價目版本與計量參數重算每筆披露的金額，與你收到的帳單比對。
遇到問題
- 某項
failed——把驗證器的完整輸出發給 linkex。記錄與其自身承諾不符，該由他們立即解釋。 - 某項
skipped而你需要它——先讀跳過原因；若確屬你有權獲得而未提供的，請提出。 - 端點返回
4XX——響應體會點名該改哪個參數（例如stream is required, e.g. stream=ch:42）；端點就是照著自我解釋建的。
如果你爭議某一筆收費，索取單條爭議證明包——幾秒鐘內離線驗完。對話從一份雙方都能查驗的共同工件開始，而不是兩張表格。