EIP-6969：ERC 和 NFT 中繼資料建構的新思路

隨著 NFT 和代幣化資產的組件化和動態性日益增強，中繼資料已成為擴展性、持久性和互通性的瓶頸。當今的中繼資料實踐——最常見的是透過 HTTP 服務的 JSON——都非常脆弱、難以版本控制，且容易出現停機。一個被非正式稱為「EIP-6969」的新方向，正在探索未來十年 ERC 和 NFT 中繼資料的建構方式：從設計上就要能夠內容定址、可驗證、可升級，並且鏈感知。

本文概述了「EIP-6969 風格」中繼資料的務實架構，展示了如何利用現有的標準實現其中大部分功能，並解釋了為何這在 Cancun 升級後、高吞吐量 L2 和模組化帳戶的世界中至關重要。

為何需要重新思考中繼資料

原始的 NFT 標準，包括基礎的 ERC-721 和多代幣 ERC-1155，定義了一個 tokenURI，該 URI 通常解析為鏈下的 JSON。雖然這很簡單，但開發者和市場參與者經常面臨以下問題：

• 依賴中心化 HTTP 端點時的脆弱性和連結失效（link rot）。
• 對於不斷演變的收藏品，缺乏可信的版本控制和來源證明。
• 難以向索引器和使用者介面（UI）發出中繼資料更新的信號。
• L1/L2 生態系統間不一致的多鏈解析。
• 對創作者而言，權利金和授權信號模糊不清。

已有好幾個 EIP 解決了這個難題的一部分。例如，ERC-4906 增加了一個事件，用於向索引器發出中繼資料更新的信號；EIP-2981 標準化了權利金資訊；EIP-3668 (CCIP-Read) 實現了信任最小化的鏈下讀取；而 EIP-1014 (CREATE2) 則允許註冊表和解析器使用確定性合約地址。同時，以太坊的 Cancun-Deneb 升級（包含 EIP-4844）實質性地改善了 L2 的數據可用性，為更多鏈上或半鏈上中繼資料方法打開了大門。

「EIP-6969 風格」的中繼資料可能長怎樣

將 EIP-6969 視為單一介面不如將其視為一個藍圖，它結合了鏈上註冊表、內容定址的鏈下數據，以及向錢包和市場的強大信號傳遞。

• 確定性的中繼資料註冊表

  • 使用 CREATE2 以可預測的地址部署每個收藏品的「中繼資料註冊表」。
  • 註冊表儲存 Schema 的承諾、預設解析器、備用策略和版本標籤。
  • 實現跨鏈可重現的部署，減少歧義和偽造。

• 預設的內容定址儲存

  • 透過哈希而非可變 URL 來引用中繼資料；透過 IPFS 內容定址 或 Arweave Permaweb 解析。
  • 可選的 HTTP 鏡像用於提高效能，但始終錨定在可驗證的摘要上。

• 可升級、有信號的中繼資料

  • 當代幣級或收藏品級的中繼資料變更時，發出 ERC-4906 事件，實現可靠的重新整理。
  • 在註冊表中使用語義版本控制（semantic versioning）來標記 Schema 變更或解析器升級。

• 可驗證的鏈下解析

  • 採用 CCIP-Read 進行信任最小化的鏈下獲取，適用於無法完全儲存在鏈上的數據。
  • 使用 EIP-712 類型數據簽署中繼資料摘要；錢包和市場可以使用 EIP-1271（用於合約帳戶）來驗證簽章。

• 鏈感知、多資源 URI

  • 在 URI 和註冊表記錄中納入 CAIP-2 鏈識別符，以消除 L1 與 L2 變體的歧義，這與 CAIP-2 一致。
  • 偏好「多資源」設計：主要的內容地址加上可選的鏡像（例如，IPFS CID + HTTPS gateway + Arweave TX）。

• 適用於 NFT 和同質化 ERC 的可組件 Schema

  • 發布 JSON Schema 或 JSON-LD，用於定義屬性結構、特徵屬性和媒體關聯，以減少索引器的歧義；請參閱市場指南，例如 OpenSea 的中繼資料標準。
  • 支援角色感知視圖（創作者 vs. 持有者 vs. 市場），同時為每個代幣狀態保留單一規範摘要。

• 可選的帳戶參與

  • 當創作者需要針對更新、授權閘道或代幣特定邏輯進行可程式化策略時，透過 EIP-6900 (模組化帳戶) 或代幣綁定控制器（例如 EIP-6551）將中繼資料控制與智能帳戶整合。

如何使用現有 EIP 在今天建構這一切

在正式的 EIP 推出之前，大部分架構都可以使用經過驗證的標準和簡單的模式來實現：

1. 使用 CREATE2 部署中繼資料註冊表

   • 儲存：
     • schemaHash（內容定址的 Schema）
     • resolver（合約或 CCIP 端點）
     • version（semver 字串）
     • fallbacks（多資源 URI 陣列）
   • 透過 ERC-165 進行介面檢測。

2. 透過 CCIP-Read 解析代幣中繼資料

   • 鏈上方法返回一個選擇器，指示客戶端從獲准的來源獲取鏈下數據。
   • 鏈下負載返回中繼資料以及 EIP-712 簽章；客戶端針對 EOA 的公鑰或 EIP-1271 合約進行驗證。

3. 在中繼資料更新時發出 ERC-4906 事件

   • 對於具有特徵演變或動態藝術的 NFT 收藏品，觸發 MetadataUpdate(tokenId) 或 BatchMetadataUpdate(fromTokenId, toTokenId)。

4. 在所有地方使用內容定址 URI

   • 在 IPFS 或 Arweave 上釘選規範化的 JSON；將 CID/TX 嵌入註冊表記錄中。
   • 鏡像可以提高延遲，但客戶端應信任摘要。

5. 發布 Schema

   • 在機器可讀的 Schema（例如 JSON Schema）中記錄屬性、媒體關聯、動畫和版本資訊，並將 Schema 的哈希發布到註冊表中。
   • 與市場預期的數據字段保持一致，例如 OpenSea 的中繼資料指南。

6. 權利金和授權信號

   • 為權利金實施 EIP-2981，並將授權參考作為 Schema 的一部分公開，以保持法律中繼資料的可移植性和可驗證性。

有回報的設計模式

• 兩階段解析

  • 第一階段：讀取鏈上註冊表數據，獲取版本、解析器和內容摘要。
  • 第二階段：執行 CCIP-Read 或鏈下獲取，根據解析器預期的簽署者驗證簽章，並比較摘要。

• 多鏈一致性

  • junto con las direcciones de registro específicas de la cadena. Los mercados y las billeteras pueden desambiguar a qué variante de cadena pertenece un token, mejorando la experiencia de usuario multiplataforma.
  • 與特定鏈的註冊表地址一起使用 CAIP-2 識別符。市場和錢包可以消除代幣所屬鏈變體的歧義，從而改善跨鏈使用者體驗。

• 治理和恢復

  • 註冊表更新應受定義完善的政策控制，最好透過模組化帳戶（EIP-6900）或時間鎖定的角色。考慮分階段更新，例如一個新的解析器或 Schema 在延遲後生效。

• 快取和重新驗證

  • 客戶端快取內容定址的負載；在 ERC-4906 事件或版本變更時重新驗證。這可以減少帶寬，同時保持數據新鮮。

安全性考量

• 信任邊界

  • 清楚地區分「誰可以簽署中繼資料」與「誰可以升級解析器」。使用獨立的密鑰並將其發布到註冊表中。

• 簽章衛生

  • 偏好使用帶有域分隔、鏈 ID、過期時間和隨機數的 EIP-712，以防止重放攻擊和跨域混淆。

• 閘道和鏡像

  • 如果使用 HTTPS 鏡像，則在客戶端強制執行摘要檢查。避免依賴閘道的可用性來確保真實性；依賴內容定址。

• 向後兼容性

  • 保留舊版 tokenURI 以實現最低程度的兼容性，但將其指向內容定址的摘要並包含註冊表參考，以供高級客戶端使用。

這對使用者和市場意味著什麼

對於收藏家而言，EIP-6969 風格的中繼資料意味著更少的損壞圖像、更快的刷新速度和更清晰的來源證明。對於市場而言，確定性的註冊表和強大的信號能夠減少鏈下推斷，提高索引準確性，並減少關於權利金或授權的爭議。對於創作者而言，可程式化策略變得實際可行：鑄造後演進特徵、分支版本，或透過模組化帳戶進行更新——而不會犧牲可驗證性。

標準的匯聚也有助於工具的發展。索引器可以依賴 ERC-4906 事件。錢包可以使用 EIP-1271 驗證簽章。多鏈 dApps 可以對齊 CAIP-2，以呈現連貫的跨鏈收藏品。而透過 IPFS 或 Arweave 進行內容定址，則能確保規範記錄防篡改。

2025 年就緒路線圖

• 開始將收藏品遷移到內容定址 URI 並發布 Schema 哈希。
• 添加一個簡單的 CREATE2 註冊表合約，並在更新時發出 ERC-4906 事件。
• 實施 CCIP-Read，用於無法完全鏈上存在的動態數據；使用 EIP-712 簽署負載。
• 對於 L2 上的新鑄造品，利用 Cancun 啟用數據可用性（概述）將更多中繼資料儲存在鏈上或 blob 中，並將鏈下負載錨定在鏈狀態上。
• 如果需要可程式化的更新策略，請探索模組化帳戶控制（EIP-6900）。

結語與實用技巧

即使中繼資料正在朝著可驗證、內容定址和模組化的設計發展，一個永恆的要素仍然存在：簽章是信任的根源。無論您是發布 Schema 變更的創作者，還是驗證 CCIP-Read 負載的市場，安全的 EIP-712 簽章和密鑰隔離都是必不可少的。

如果您偏好使用硬體錢包以獲得更強的密鑰安全性，OneKey 提供開源韌體、穩健的安全元件保護，並在熱門 dApps 中提供對現代簽章流程（如 EIP-712）的流暢支援。隨著中繼資料架構越來越依賴清晰、可驗證的簽章——尤其是在使用 CCIP-Read 和透過 EIP-1271 進行基於合約的驗證時——在工作流程中擁有可靠、可審核的簽章，對於創作者和收藏家來說都是實用性的升級。

透過今天採用這些「EIP-6969 風格」的模式，生態系統可以使 ERC 和 NFT 的中繼資料更加持久、可互通且面向未來——為以太坊及其 L2 正在穩步交付的多鏈、高吞吐量世界做好準備。