合约用的是哪种钟：ERC-6372 时钟披露接口

“锁仓 30 天""快照在治理投票前取得""按小时结算”——这些承诺里藏着同一个问题：合约到底用什么在数时间？有的合约用区块高度，有的用秒级时间戳，两者在以太坊主网上大致换算得通，换到以太坊的某条第 2 层网络上就经常对不上。ERC-6372（Contract clock）给合约加了一个自报计时方式的接口，状态为 Review（评审中），创建于 2023 年 1 月 25 日。本文只解释机制，不构成任何投资建议。

两个只读函数

按规范，符合标准的合约必须实现两个函数。clock() 返回一个 uint48 的当前时点值，它必须是随链”单调不减”的函数——常见的选择是 block.timestamp（秒级时间戳）或 block.number（区块高度）。CLOCK_MODE() 返回一段机器可读的描述字符串，格式像网址查询参数：用时间戳时返回 mode=timestamp；用当前链区块号时返回 mode=blocknumber&from=default；引用别的链的区块号时则带上该链的 CAIP-2 标识。这样程序可以先问钟，再解读那个时点数字。

为什么跨链时代钟会变歪

规范举的例子正是多链环境：某些第 2 层网络的出块间隔不固定，区块高度与真实经过的时间不成比例。拿按区块计时的合约到出块忽快忽慢的链上，“2000 个区块的锁定期”可能是一小时也可能是三天。反过来，用时间戳计时的合约受矿工对秒级时间戳的宽容度影响，也存在小偏差。一个不披露钟的合约等于逼调用方猜，而猜错一次的代价往往是提前解锁失败、错过快照、或者以为到期了其实没有。

对 NFT 玩家最实际的三个场景

1. 空投或治理快照：先读合约声明的快照口径是”某区块”还是”某时刻”，再去对应的区块浏览器查那个口径下的真实世界时间，别用另一个口径套。
2. 租赁、锁仓与归属（vesting）：查询返回值时要对照 CLOCK_MODE 的说明换算，跨链部署的合约尤其要确认它数的是哪条链的块。
3. 委托投票类代币（如依赖 ERC-6372 的 ERC-5805）：查历史投票权用的时点索引，索引单位就是合约自己的钟。

标准现状与实操建议

ERC-6372 仍在评审中，大量现存合约不会主动披露计时方式。拿不到 CLOCK_MODE 时，退一步的做法是读合约源码里 clock 相关实现、或者比较历史快照值随真实时间增长的速率来倒推口径，并把判断依据和核验当日期记下来。一个能自报时钟的合约，本质上是对”我们的规则可以被机器验证”多走了一步；没这个接口的合约也未必有问题，只是核验成本转移给了你。

哪些合约最需要披露钟

规范的例子点名三类：执行延迟操作的 Timelock、治理投票合约、以及用快照记录历史状态（投票权、质押余额）的代币。对 NFT 玩家，第三种最贴身——NFT 治理快照、租赁到期结算、归属释放计划都靠”钟”定义什么时候算数。还有一个跨链细节：CLOCK_MODE 允许合约声明自己引用的是另一条链的区块号（返回值里带 CAIP-2 链标识），这类”跨链读块”的设置一旦存在，核验历史快照就必须去那条链上找对应区块，而不是在主网浏览器里翻。反过来说，凡是不实现 clock 与 CLOCK_MODE 的合约，标准流程就是把它当作不披露计时方式处理：读源码确认，并记下你判断所依据的实现位置与核验当日日期。

计时口径是核验链上承诺时最容易忽略的一环，凡是涉及”多久之后”的机制都建议确认单位；本文仅为机制科普，不构成投资建议。