EIP-6969：构建 ERC 和 NFT 元数据的新构想

随着 NFT 和代币化资产的组合性和动态性日益增强，元数据已成为可扩展性、持久性和互操作性的瓶颈。当今的元数据实践——最常见的是通过 HTTP 提供的 JSON——都存在脆弱、难以版本化以及易于宕机的问题。一项非正式地被称为「EIP-6969」的新方向，正在探索未来十年 ERC 和 NFT 元数据应该如何构建：从设计之初就具备内容寻址、可验证、可升级和链感知能力。

本文将概述一种实用的「EIP-6969 风格」元数据架构，展示如何利用现有标准实现大部分功能，并解释为何在坎昆升级后、高吞吐量 L2 和模块化账户的世界中，这一点至关重要。

为何需要重新思考元数据

最初的 NFT 标准，包括基础的 ERC-721 和多代币 ERC-1155，都定义了一个 tokenURI，通常指向链下的 JSON。虽然这种方式很简单，但开发者和市场经常面临以下挑战：

• 依赖中心化 HTTP 端点导致脆弱性和链接失效。
• 不断演变的收藏品缺乏值得信赖的版本控制和来源追溯。
• 难以向索引器和用户界面（UI）传达元数据更新的信号。
• L1/L2 生态系统中跨链解析不一致。
• 创作者在版税和许可信号方面存在模糊性。

许多 EIP 已经解决了这些问题的一部分。例如，ERC-4906 增加了一个事件，用于向索引器发出元数据更新信号；EIP-2981 规范了版税信息；EIP-3668 (CCIP-Read) 实现了可信度最小化的链下读取；而 EIP-1014 (CREATE2) 则允许为注册表和解析器提供确定性的合约地址。与此同时，以太坊的坎昆-德内布升级（包括 EIP-4844）显著提高了 L2 的数据可用性，为更多的链上或半链上元数据方法打开了大门。

「EIP-6969 风格」元数据会是什么样子

可以将 EIP-6969 看作一个蓝图，而不是一个单一的接口，它结合了链上注册表、内容寻址的链下数据以及向钱包和市场的强大信号。

• 确定性的元数据注册表

  • 使用 CREATE2 在一个可预测的地址部署每个集合的「元数据注册表」。
  • 注册表存储模式承诺、默认解析器、备用策略和版本标签。
  • 实现跨链可复现的部署，减少模糊性和欺骗。

• 默认采用内容寻址存储

  • 通过哈希值而非可变 URL 来引用元数据；通过 IPFS 内容寻址 或 Arweave Permaweb 进行解析。
  • 可选的 HTTP 镜像用于提升性能，但始终以可验证的摘要为锚定。

• 可升级、可信号的元数据

  • 当代币级别或集合级别的元数据发生变化时，发出 ERC-4906 事件，实现可靠的刷新。
  • 在注册表中采用语义化版本控制，以标示模式更改或解析器升级。

• 可验证的链下解析

  • 对于无法完全存储在链上的数据，采用 CCIP-Read 实现可信度最小化的链下获取。
  • 使用 EIP-712 类型化数据签署元数据摘要；钱包和市场可以使用 EIP-1271 验证合约账户的签名。

• 链感知、多资源 URI

  • 在 URI 和注册表记录中纳入 CAIP-2 链标识符，以区分 L1 和 L2 变体，符合 CAIP-2 标准。
  • 倾向于「多资源」设计：主内容地址加上可选的镜像（例如，IPFS CID + HTTPS 网关 + Arweave TX）。

• NFT 和同质化 ERC 的可组合模式

  • 为属性结构、特性和媒体关系发布 JSON Schema 或 JSON-LD，以减少索引器的歧义；参考如 OpenSea 的元数据标准 等市场指南。
  • 支持角色感知视图（创作者 vs. 持有者 vs. 市场），同时为每个代币状态保持一个唯一的规范摘要。

• 可选的账户参与

  • 通过 EIP-6900 (模块化账户) 或代币绑定控制器（例如 EIP-6551）将元数据控制与智能账户集成，当创作者需要可编程的更新策略、许可门控或代币特定逻辑时。

如何利用现有 EIP 立即构建

在正式的 EIP 落地之前，大部分架构都可以通过成熟的标准和直接的模式来实现：

1. 使用 CREATE2 部署元数据注册表

   • 存储：
     • schemaHash（内容寻址的模式）
     • 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

   • 将规范的 JSON 固定在 IPFS 或 Arweave 上；在注册表记录中嵌入 CID/TX。
   • 镜像可以提高延迟，但客户端应信任摘要。

5. 发布模式

   • 以机器可读的模式（例如，JSON Schema）记录属性、媒体关系、动画和版本信息，并将模式哈希发布到注册表中。
   • 与市场预期的字段保持一致，例如 OpenSea 的元数据指南。

6. 版税和许可信号

   • 为版税实现 EIP-2981，并将许可引用作为模式的一部分公开，以保持法律元数据的便携性和可验证性。

有益的设计模式

• 两阶段解析

  • 第一阶段：读取链上注册表数据以获取版本、解析器和内容摘要。
  • 第二阶段：执行 CCIP-Read 或链下获取，根据解析器预期的签名者验证签名，并比较摘要。

• 跨链一致性

  • 在链特定注册表地址旁边使用 CAIP-2 标识符。市场和钱包可以区分代币属于哪个链的变体，从而改善跨链用户体验。

• 治理和恢复

  • 注册表更新应由明确定义的策略控制，最好是通过模块化账户（EIP-6900）或带有时间锁的角色。考虑分阶段更新，例如新的解析器或模式在延迟后生效。

• 缓存和重新验证

  • 客户端缓存内容寻址的载荷；在 ERC-4906 事件或版本更改时重新验证。这可以减少带宽，同时保持数据新鲜。

安全注意事项

• 信任边界

  • 清晰地区分「谁可以签署元数据」和「谁可以升级解析器」。使用不同的密钥并将它们发布到注册表中。

• 签名规范

  • 偏好使用 EIP-712 并进行域分离、链 ID、过期时间和随机数处理，以防止重放攻击和跨域混淆。

• 网关和镜像

  • 如果使用 HTTPS 镜像，请在客户端强制执行摘要检查。避免依赖网关的可用性来保证真实性；应依赖内容寻址。

• 向后兼容性

  • 保留传统的 tokenURI 以实现最低兼容性，但将其指向内容寻址的摘要，并包含注册表引用以供高级客户端使用。

对用户和市场意味着什么

对于收藏家而言，EIP-6969 风格的元数据意味着更少的损坏图片、更快的刷新速度和更清晰的来源追溯。对于市场而言，确定性的注册表和强大的信号可以减少链下推断，提高索引准确性，并减少关于版税或许可的争议。对于创作者而言，可编程的策略变得实用：在铸造后演进属性、分叉版本或通过模块化账户进行更新门控——而无需牺牲可验证性。

标准化的融合也有助于工具开发。索引器可以依赖 ERC-4906 事件。钱包可以使用 EIP-1271 验证签名。跨链 dApp 可以统一使用 CAIP-2 来呈现连贯的跨链集合。而通过 IPFS 或 Arweave 进行内容寻址，则能确保规范记录的防篡改性。

2025 年就绪路线图

• 开始将集合迁移到内容寻址 URI 并发布模式哈希。
• 添加一个简单的 CREATE2 注册表合约，并在更新时发出 ERC-4906 事件。
• 实现 CCIP-Read 以处理无法完全存储在链上的动态数据；使用 EIP-712 对载荷进行签名。
• 对于 L2 上的新铸造，利用坎昆支持的数据可用性（概述）将更多元数据存储在链上或 blob 中，并将链下载荷锚定到链状态。
• 如果需要可编程的升级策略，可以探索模块化账户控制（EIP-6900）。

结语和实用技巧

即使元数据正朝着可验证、内容寻址和模块化的设计发展，但有一个要素保持不变：签名是信任的根基。无论是发布模式更改的创作者，还是验证 CCIP-Read 载荷的市场，安全的 EIP-712 签名和密钥隔离都至关重要。

如果您偏好使用硬件钱包来加强密钥安全，OneKey 提供开源固件、强大的安全元件保护，并能顺畅支持现代签名流程（如 EIP-712），并且在主流 dApp 中有良好的应用。随着元数据架构越来越依赖清晰、可验证的签名——尤其是在 CCIP-Read 和通过 EIP-1271 进行基于合约的验证方面——拥有可靠、可审计的签名流程，对于创作者和收藏家来说都是一项实用的升级。

通过立即采用这些「EIP-6969 风格」的模式，整个生态系统可以使 ERC 和 NFT 元数据更加持久、可互操作且面向未来——为以太坊及其 L2 正在稳步交付的多链、高吞吐量世界做好准备。