ReceiptOS：為自主代理工具調用提供可驗證的執行收據

ReceiptOS — 代理工具調用的可驗證執行收據

摘要

隨著自主代理（Autonomous Agents）和工具調用系統變得越來越普遍，我們正缺失一個基本的原語：可驗證執行收據（verifiable execution receipts）。

如今，當一個代理調用工具（API、插件、合約、鏈外服務）時，沒有標準化的方式來證明：

執行了什麼

使用了哪些輸入

返回了什麼輸出

結果是否被篡改

ReceiptOS 是一個用於生成和驗證執行收據的極簡框架——這些收據是經過加密簽名的工具調用記錄，可以在鏈外或鏈上進行驗證。

---

問題

代理系統（大型語言模型、副駕駛、自主工作流）高度依賴工具執行：

API 調用

合約交互

外部服務

本地腳本

然而，目前的模型是基於信任的，而非可驗證的。

這導致了多個問題：

缺乏可審計性

你無法可靠地重建代理實際執行了什麼。

無完整性保證

輸出可能在未被察覺的情況下被修改。

缺乏可組合性

工具結果無法被其他系統安全地重用或驗證。

缺乏標準接口

每個系統記錄執行的方式各不相同（或者根本不記錄）。

---

核心理念

ReceiptOS 引入了一個簡單的原語：

每次工具調用都會生成一份簽名收據。
一份收據包含：

工具標識符

輸入負載（哈希或結構化數據）

輸出負載（哈希或結構化數據）

時間戳

執行上下文（可選）

簽名

示例（簡化版）：

{
"tool": "price_oracle.getETHUSD",
"input_hash": "0xabc...",
"output_hash": "0xdef...",
"timestamp": 1710000000,
"signature": "0x..."
}

該收據隨後可以：

在本地驗證

在代理之間傳遞

在鏈上錨定（可選）

在更高級別的工作流中作為證明使用

---

為什麼這很重要

這不僅僅是日誌記錄——它是代理執行的信任層。

它實現了：

確定性重放（具有匹配的輸入/輸出）

篡改檢測

跨代理驗證

自主系統的審計追蹤

可組合的工具輸出

換句話說，它將工具調用轉化為可驗證的工件（verifiable artifacts）。

---

與以太坊 / EVM 的關係

存在多個自然的集成點：

ERC 風格的驗證器接口

合約可以驗證收據（例如 isValidReceipt(...)）。

帳戶抽象 / 智能錢包

收據可用作代理驅動錢包的執行證明。

鏈外 → 鏈上橋接

收據為外部計算提供了一個極簡的證明層。

標準化潛力 (ERC/EIP)

統一的收據架構 + 驗證接口可能成為共享的原語。

---

設計原則

極簡 — 架構小巧，無沉重依賴

確定性 — 可重現的哈希/簽名

可組合 — 收據可以鏈接

傳輸無關 — 適用於任何代理/工具系統

驗證優先 — 驗證是核心原語，而非事後補救

---

當前狀態

已實現 MVP（命令行界面 + 極簡 API）

基礎流程：簽名、驗證、鏈式驗證

演示：

篡改檢測

重放檢測

收據鏈接

下一步：

→ 定義穩定的架構並探索標準化路徑

---

開放性問題

收據驗證是否應標準化為 ERC 接口？

在仍允許可組合性的前提下，最小的架構是什麼？

收據應如何在鏈上錨定（如果需要的話）？

我們是否需要針對不同工具類別進行域分離（domain separation）？

這如何與現有的簽名標準（EIP-1271, ERC-7913）交互？

---

討論

尋求以下方面的反饋：

此原語在協議 / 生態系統層面是否實用

它應如何與 EVM 標準集成

向 ERC/EIP 方向發展是否有意義

如果有需要，我可以分享 MVP 倉庫和示例。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/receiptos-verifiable-execution-receipts-for-agent/28103)