newsence
來源篩選

ERC-8176: Integrity Verification for ERC-7730

Ethereum Magicians

ERC-8176 introduces an integrity field for ERC-7730 descriptors, allowing wallets and auditors to verify the authenticity and correctness of human-readable transaction details through cryptographic signatures.

newsence

ERC-8176：針對 ERC-7730 的完整性驗證機制

Ethereum Magicians
大約 10 小時前

AI 生成摘要

ERC-8176 為 ERC-7730 描述檔定義了一個選用的完整性欄位，讓錢包業者與審計單位能透過加密簽章，獨立驗證交易細節描述檔是否正確且未經竄改。

大家好，我希望能徵求關於新草案 的回饋。

摘要

ERC-8176 為 ERC-7730 明文簽署描述檔（clear signing descriptor files）定義了一個選填的 integrity（完整性）欄位。它允許信任方——如錢包廠商、審計機構、註冊表營運商——使用 EIP-191（EOA）或 ERC-1271（合約）簽署，並以 CAIP-10 帳戶識別碼為鍵值，獨立證明描述檔的正確性。

問題

ERC-7730 描述檔告知錢包如何顯示人類可讀的交易細節。這些檔案可能源自註冊表、由錢包廠商打包，或從第三方 API 獲取。無論分發方式為何，目前都沒有機制可以驗證是誰審查並批准了特定的描述檔。接收描述檔的錢包無法區分經過仔細審計的檔案與被篡改或從未經過妥善審查的檔案。一個帶有細微誤導性的描述檔——例如隱藏代幣授權金額的描述檔——可能會在技術上看似有效的情況下欺騙終端用戶。

現有的保護措施仍有不足：

  • ERC-7730 上下文綁定 驗證了合約目標，但未驗證顯示內容的正確性
  • HTTPS 保護傳輸過程，而非內容的真實性
  • Git 簽署 一旦檔案透過 API 提供或獨立下載後便無法留存

方法

integrity 欄位是一個 JSON 映射表，其中每個鍵（key）是一個 CAIP-10 帳戶 ID，每個值（value）包含一個 signerType（“EOA” 或 “contract”）和一個 signature（簽署）。簽署訊息涵蓋了描述檔內容（排除 integrity 欄位本身）經由 RFC 8785 (JCS) 規範化後的 Keccak-256 哈希值。

多重簽署模型

多個參與方可以獨立簽署同一個描述檔，而不會影響彼此的簽署。由於 integrity 欄位不包含在哈希計算中，添加新的簽署者不會使現有的簽署失效。每個簽署都是獨立驗證的——一個失敗不會影響其他簽署。

信任策略（接受哪些簽署者、需要多少簽署者）則刻意留給各個錢包自行決定。

期待您的想法與回饋。