ERC：鏈上明文簽署

「盲簽」是乙太坊現狀的寫照：用戶批准他們無法有效解讀的交易，並信任請求應用程式能準確描述他們授權的內容。2025 年 2 月，Bybit 遭受了約 15 億美元的損失，原因在於 Safe 多簽簽署者批准了一項交易，該交易與顯示內容相反，替換了錢包實作並將控制權轉移到攻擊者控制的地址。現有的方法——如 ERC-7730 等經過策展的離線註冊表——為少數知名合約帶來了明文簽署，但它們依賴第三方策展，僅涵蓋最著名的協議，且無法擴展到每天部署的海量長尾合約。

任何解決方案都必須滿足三個要求。去信任化 (Trustlessness)：顯示內容僅由數學和合約邏輯驗證——無需信任任何一方。去中心化 (Decentralization)：任何開發者都可以發布自己的顯示規範，無需註冊表、無需策展人，也無需審核門檻。安全性 (Security)：顯示內容必須在加密層面上與執行綁定，而非可以被替換的建議性元數據。

我們提出了 鏈上明文簽署 (Onchain Clear Signing) —— 一種定義在三個相互依存的 ERC 之上的明文簽署架構，旨在滿足上述要求。合約開發者將顯示規範直接嵌入其合約代碼中。函式選擇器 (function selector) 被擴展了一個顯示識別碼，將顯示內容與鏈上執行綁定，無需外部註冊表。交易請求將顯示規範與調用數據 (calldata) 一併攜帶，使得即使在離線硬體錢包上也能進行完整驗證。目標是讓明文簽署成為每個新部署合約的基本預期。

---

架構

該架構建立在三個層級之上：一個定義數據含義的語義類型系統、一個將顯示與執行綁定的鏈上強制機制，以及一個將顯示規範傳遞給錢包的傳輸層。

[Onchain Clear Signing Specification] 定義了類型系統和顯示識別碼。開發者編寫顯示規範，描述函式的調用數據應如何被解讀和顯示，並將其直接嵌入合約中。每個規範都由一個緊湊的 32 位元組摘要唯一識別，任何設備都可以在沒有網絡訪問的情況下，根據規範本身在本地計算出該摘要。

[Onchain Clear Signing Verification] 定義了合約如何將其顯示規範與自身的執行綁定。函式選擇器被擴展了一個 32 位元組的顯示識別碼；合約在部署時承諾預期的識別碼，並在每次調用時進行驗證，確保用戶批准的顯示內容就是與該執行綁定的顯示內容。如果識別碼不匹配，交易將會回退 (revert)。這將顯示規範從建議性元數據轉變為強制的執行前提條件——「顯示即法律」 (display is law)。

[wallet_sendTransaction] 定義了傳輸方式。dApp 將顯示規範與交易請求打包在一起——這是一種推播模型 (push model)，消除了簽署時對實時網絡的依賴。無需查詢註冊表，也沒有可能失效或被攻破的外部服務。此方法適用於離線硬體。

顯示規範具有組合性。一個調用多簽、再調用交換合約的智能帳戶會獨立渲染每一層——錢包會定位每個嵌套調用的顯示規範，完整渲染它們，並在用戶簽署前呈現組合後的結果。這對帳戶抽象具有直接影響：錢包不需要內建對每個智能帳戶入口點或執行框架的知識。任何嵌入了顯示規範的合約，無論如何被調用，都是完全可渲染且可驗證的。

---

交易流程

dApp
│
│ wallet_sendTransaction(tx, display_spec) (傳輸)
▼
錢包
├─ 使用顯示規範渲染調用數據 (規範)
├─ 根據合約列表驗證指定地址 [選填] (規範)
├─ 在本地計算並驗證顯示識別碼 (規範)
└─ 用戶批准渲染後的顯示內容
│
│ clearCall(display_identifier || selector || calldata) (驗證)
▼
合約
└─ 驗證識別碼與承諾值匹配 → 執行 (驗證)

每一層的驗證都是獨立的；層與層之間互不信任。顯示識別碼不匹配會導致錢包在提交前拒絕。如果提交的調用沒有有效的識別碼（完全繞過錢包），則會在合約端回退。該機制會帶來微小且固定的 Gas 開銷：加在調用數據前的 32 位元組顯示識別碼會增加調用數據成本，而鏈上驗證則為執行貢獻了恆定的成本。

---

合約列表：社交層

加密綁定保證了執行與承諾的顯示規範相符。但它並不保證合約的身份——惡意合約可以承諾對其自身惡意行為進行準確顯示。

主要的攻擊向量是針對合法合約的交易，但其參數將權限委託給惡意地址——例如，在 ERC-20 代幣上執行 approve(maliciousSpender, maxAmount)。為了防止這種情況，該架構包含了合約列表 (Contract Lists)：經過策展的合約地址與已驗證合約身份的映射，遵循與代幣列表 (Token Lists) 相同的模型。

顯示規範使用類型化格式（地址、代幣、合約）指定哪些地址需要驗證。當錢包遇到標記為需要驗證的地址時，它會檢查受信任的合約列表，如果地址未被識別，則停止渲染。合約列表可以由錢包提供商、DAO、安全委員會發布，或由用戶在本地維護。完整細節請參閱 Onchain Clear Signing Specification。

---

徵求回饋

這三個 ERC 目前處於構思階段。我們計劃在處理完社群回饋後提交至 EIP 存儲庫。我們正在徵求以下方面的回饋：

架構。 該設計在何處可能會失效或產生意料之外的複雜性？

整合。 您預計會遇到哪些採用阻力？對於 dApp：構建時的工具負擔。對於錢包：受限設備上的渲染引擎複雜性。對於合約：Gas 開銷和代理 (proxy) 兼容性。

安全性。 是否有我們尚未處理的攻擊向量？

格式覆蓋。 您的使用場景中是否有缺失的類型或渲染需求？

向後兼容性。 不可升級合約的遷移路徑。請參閱 Onchain Clear Signing Verification ERC 中的向後兼容性章節以了解建議的選項。

早期採用。 如果您正在開發錢包、dApp 或合約並希望成為早期採用者，請告知我們。

感謝閱讀——期待參與討論。

連結與圖片

2026 年 2 月 18 日 AllWalletDevs #38 簡報

  [github.com](https://github.com/Kalapaja/clear-signing)

GitHub - Kalapaja/clear-signing

透過在 GitHub 上建立帳戶來為 Kalapaja/clear-signing 的開發做出貢獻。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/erc-onchain-clear-signing/28068)