信任模型與邊界

一個驗證協議的可信度來自對自身極限的精確。以下是 Open Tally 的極限，說得與保證一樣直白——規範用了不成比例的篇幅寫「不證明什麼」，本頁刻意照做：把邊界藏在文檔末尾，等於把它藏起來。

完備性的殘餘缺口

本協議的機制證明「已簽發的回執未被刪除或篡改」。它們不證明「每一筆真實發生的事件都簽發了回執」。 任何以簽發為起點的機制都做不到：機制從簽發那一刻開始，而一個從未進入 sequencer 的事件不會留下空洞。

密碼學無法閉合這個缺口。它從兩個方向被收窄：

• 實現側工程——在 linkex.ai 實例中，扣費與回執出站事件在同一個數據庫事務內提交，不存在「錢動了、帳沒排」的窗口；閘道還用自己的 tokenizer 與上游報數並行計量、持續對帳（實例保證）。
• 系統之外的證據——你自己的呼叫日誌、你自己的閘道計數、或獨立計量。帳本的可驗證性讓「與外部證據對帳」變得便宜，而這正是它的用途。

協議選擇記錄這個缺口而不是粉飾它。評估任何 Open Tally 實例的對手方，都應該恰恰追問這些捕獲工程的問題——並且不要把任何一個 PASS 讀作「帳目與現實完備相符」。

PASS ≠ 為真

• 有效簽名證明誰簽的、簽後未改——不證明簽的內容正確。
• 序號連續證明已簽發的沒有被移除——不證明一切都被簽發了。
• 確定性重算證明總額由回執內記錄的價格推得——不證明那些價格與合同相符。價格正確性屬於對照合同與價目表的對帳：帳本支持這個商務流程，不取代它。
• 更廣地說：一張通過驗證的回執是「該記錄自簽發起未被修改」的佐證性證據。它本身不證明底層服務已交付，也不證明產出這些數字的計量正確——計量的誠實性是實例的工程性質，由獨立交叉計數承擔，不由簽名承擔。

時間固定只朝前，且兩條腿並不相同

RFC 3161 令牌與鏈上錨證明內容自固定時刻起未變。它們無法追溯地證明內容在那一刻就是對的。其價值是單調的：承諾固定得越早、越規律，任何造假可能發生的窗口就越小。

兩個機制的信任假設也不同，這正是協議兩者都用的原因：

• 時間戳令牌建立在單一機構之上——持有 TSA 密鑰的人原則上能簽出任意時間的令牌。保證的成色取決於那一方，也取決於驗證方是否釘住 TSA 的根證書、而不是信任自己操作系統碰巧信任的東西。
• 公鏈錨把那個單一方換成鏈的共識——但錨定有起始時刻：在它之前簽發的承諾只有令牌固定。

兩者都把內容固定在某個時刻；它們抵禦的不是同一個對手。

抽樣給出的是界，不是排除

大規模期間驗證使用按公開確定性規則抽出的回執樣本。驗過的樣本給未被發現的篡改劃了一個概率界——不是把它降為零，且驗證器印出實際的漏檢概率，而不是只給 PASS 這個詞。十萬條裡抽一千條，十條被篡改的情況約九成會被漏掉；結論是那個數字，不是那行綠色。完整語義見證明包。

密鑰保管，如實陳述

在 linkex.ai 實例中，Ed25519 簽名密鑰以一把存放於數據庫之外的主密鑰在靜態時加密——單有數據庫轉儲只能得到密文，攻擊者需要攻破兩個系統而非一個。這不是 HSM，實例也不聲稱它是：主密鑰對簽名進程可讀，能讀到進程環境的人依然能解密。比加密本身更要緊的是兩條 fail-closed 行為：解不開的密鑰會讓簽名停止——絕不鑄造替代密鑰，因為第二把密鑰會讓公開密鑰歷史說不清哪把密鑰簽了哪些回執；存儲的密鑰若推不出其存儲的指紋，一律拒絕。

運營方的自我約束是系統的一部分

可驗證性約束的是帳本；它本身約束不了運營方的配置。誠實的實例因此在操作層面約束自己——linkex.ai 的做法：配置變更寫入 append-only 審計日誌、危險開關需兩人（maker-checker）覆核、讀取也留痕、以及上述 fail-closed 密鑰處理。這些措施按實例記錄，因為它們是實例性質，不是協議性質。

這一切實際買到什麼

誠實的總結：Open Tally 把「信我」變成「查我」——對捕獲時刻之後的一切；並把捕獲時刻本身做到工程所能及的最小、最受審計。 爭議不再是兩張各執一詞的表格，而是一份雙方都能機器復驗、邊界精確已知的共同證據基礎。