如何實施EIP-712進行安全簽名驗證？

EIP-712 概述和核心目的

1. EIP-712 定義了以太坊應用程序中類型化結構化數據哈希和簽名的標準。

2. 它使錢包能夠在簽名請求期間顯示人類可讀的域和消息字段，而不是原始的十六進製字符串。

3. 該規範通過域分隔符哈希引入域分離，防止跨不同 dApp 或鏈的簽名重放。

4. 每個簽名的有效負載都包含一個類型定義，必須在序列化和散列之前顯式聲明該類型定義。

5. 此結構確保確定性編碼，消除可選字段或動態數組排序的歧義。

域分隔符構建

1. 使用keccak256(encodeType(domainType) ||encodeData(domainValue))計算域分隔符。

2. 必填的域字段包括name 、 version 、 chainId 、 verifyingContract和可選的salt 。

3.名稱字段必須與 dApp 的註冊品牌名稱匹配，通常根據 ENS 或合約元數據進行驗證。

4. chainId強制鏈特定的有效性——以太坊主網上生成的簽名在 Polygon 或 Arbitrum 上無效，無需重新計算。

5. 即使所有其他輸入都正確，不匹配的域分隔符也會導致簽名驗證失敗。

類型化數據編碼過程

1. 每個類型聲明指定字段名稱、類型和嵌套依賴項，例如， Person(address wallet, string name) 。

2. 數組被編碼為單個元素的長度前綴串聯哈希，而不是指針或引用。

3. 字符串在哈希之前經過UTF-8字節轉換；不會自動應用截斷或標準化。

4. 地址字段被零填充為 32 字節，並在散列之前在內部被視為bytes20 。

5. 最終摘要將域分隔符、主要類型哈希和編碼消息數據組合成用於 ECDSA 簽名的單個keccak256輸出。

前端集成模式

1. MetaMask 等現代錢包公開了eth_signTypedData_v4 RPC 方法，該方法接受符合 EIP-712 的 JSON-RPC 有效負載。

2. 開發人員必須在調用簽名請求之前預先聲明 JavaScript 對像中的所有類型 - 運行時動態類型生成會破壞兼容性。

3. @ethersproject/hash等庫提供了計算域分隔符和客戶端類型化哈希的實用程序。

4. UI 層應完全按照類型架構中的定義呈現每個字段標籤和值，任何偏差都會使用戶感到困惑並破壞信任。

5. 簽名後不得修改簽名有效負載；即使空格的變化也會使密碼證明失效。

鏈上驗證機制

1. 智能合約使用ecrecover以及從輸入參數和域值導出的重構摘要來驗證簽名。

2. 像 OpenZeppelin 的ECDSA.recover這樣的 Solidity 庫簡化了恢復邏輯，但需要與前端行為匹配的精確摘要重建。

3. 傳遞給合約的域參數必須與簽名期間使用的域參數相同——不匹配會產生不正確的可恢復地址。

4. 消息數據必須在合約內部使用相同的類型定義進行反序列化；偏差會導致哈希不匹配。

5. 經過驗證的簽名可以控制關​​鍵操作，包括基於許可的代幣轉移、治理建議和鏈下訂單結算。

常見問題解答

問：EIP-712 簽名可以在具有相同名稱和版本的不同域之間重複使用嗎？答：不會。即使chainId或verifyingContract中的微小差異也會產生不同的域分隔符，從而導致跨域重用不可能。

問：在域結構中省略鹽字段是否安全？答：是的，允許省略，但這樣做會降低跨分叉或測試網部署相同合約時的唯一性保證。

問：EIP-712 支持遞歸類型定義嗎？答：不可以。循環或自引用類型違反了確定性編碼要求，並且在哈希計算期間會失敗。

問：如何處理 EIP-712 類型定義中的可變長度數組？ A：使用類似Person[] people 的語法；編碼器自動計算數組長度並在連接之前單獨對每個元素進行哈希處理。