Open Tally 是什麼？
可驗證 AI 用量記帳的開放協議——簽名回執、防篡改鏈、期間承諾、第三方時間固定與確定性重算。
Open Tally 是一個可驗證 AI 用量記帳的開放協議。 實現它的閘道對每一筆可計費 AI 呼叫簽發一張密碼學回執；回執成鏈、鏈成期間承諾、承諾被第三方固定在時間上。任何一方——客戶、供應商、審計方——都能用開源工具離線復驗全部帳目，而不需要信任記帳的人。
為什麼需要一個協議？
AI 用量計費在兩個方向上都是單方面聲明：
- 對下游（客戶、代理商）：閘道報的用量與金額無法被獨立核實。
- 對上游（模型供應商）：供應商的帳單與閘道自己的計量對不上時，沒有中立的證據基礎——只剩談判。
Open Tally 用證據取代「信任 + 抽查 + 仲裁」。核心設計承諾：
- 每筆可計費事件——包括失敗的——都獲得一張簽名回執。 漏掉一筆，序號上就留下空洞。
- 回執按渠道構成哈希鏈。 改動任何一筆，鏈在那一環斷開。
- 每期間的回執聚合成 Merkle 承諾，承諾自身再成鏈。
- 承諾哈希被第三方固定在時間上——RFC 3161 時間戳機構與公鏈，兩條互不相關的信任路徑。一經固定，重寫歷史在密碼學上不可行。
- 金額可確定性重算——依據每張回執簽名內容中記錄的單價、價目版本與計量參數。
- 以上全部可由對手方離線驗證——用一個零依賴的開源驗證器；且規範精確到對手方可以自行實現驗證器，全程無需閱讀運營方的代碼。
帳本的形狀
每一層應對一種不同的攻擊：
| 層 | 防禦 |
|---|---|
| 帶序號的簽名回執 | 偽造或漏記個別事件 |
| 哈希鏈 | 悄悄修改歷史回執 |
| Merkle 期間承諾 | 整期重發、把空洞抹平 |
| 承諾鏈 | 丟棄或重排期間 |
| 第三方時間固定 | 事後重寫歷史——即使是運營方自己 |
這五層之下是同一個地基：規範化序列化——同一內容只有唯一的字節表示，哈希與簽名承諾的因此是內容本身，而非格式上的偶然。回執先講它，因為上面每一個構造都依賴它。
證據是分層的，每層說明自己的射程
生產帳本裡有數億張回執。Open Tally 不假裝對手方會全部下載，而是把證據分層，每層明確聲明覆蓋範圍：
| 層 | 規模 | 確立 |
|---|---|---|
| 期間包——承諾鏈、密鑰歷史、時間戳令牌 | O(承諾數)：一條流一個月僅數 MB，與流量無關 | 簽名、序號連續、鏈連續與時間固定——覆蓋整個期間 |
| 抽樣回執——按公開確定性規則抽出，各帶 Merkle 證明 | O(樣本量) | 被抽集合的包含性，且報告印出漏檢概率 |
| 單條證據包——一張回執、其前後鄰與證明 | 約 6 KB | 該筆的全部檢查 |
抽樣規則公開，種子是在抽籤可能發生之前就被固定的值，運營方無法挑選好看的樣本——詳見證明包。
「可驗證」在此的精確含義
驗證不是氛圍，而是六項具體檢查，每項都同時聲明 PASS 證明什麼與不證明什麼。檢查 1/3/4/5 回答完整性（有沒有被改）；檢查 2 回答完備性（有沒有缺失）；檢查 6 回答可重算性（錢是否從記錄的價格推得出）。
協議對自己的信任模型與殘餘缺口同樣直白——密碼學保證「記下來的改不了」，但它本身無法保證「記下來的就是真的」。後一半是實現方的工程責任，也是本站為 linkex.ai 實例記錄的內容之一。
協議組成
回執
規範化序列化、回執信封、失敗回執、分段與選擇性披露、分段代際。
序號、鏈與承諾
回執如何成為防篡改、顯空洞的帳本——含精確的哈希構造。
時間錨定
RFC 3161 時間戳與 Base 鏈上錨定：為何兩者都要、如何把錨核到鏈上。
六項檢查
完整的驗證語義。
命名與開放性
Open Tally 是協議；linkex 是實現它的產品。協議規範與驗證工具以開源形式發布於 GitHub org opentallyprotocol 與 npm scope @opentally。閘道產品本體不要求開源——協議的意義正在於：你不需要看記帳人的代碼，也能查他的帳。 回執規範附帶一致性向量套件（確切的輸入字節、期望輸出字節與其 SHA-256），正是為了讓獨立實現無需參照運營方的實現就能證明自己寫對了。