Base 出块缩到 200 毫秒，写死区块数的合约要出事

Base 的出块时间，从 2 秒变成了 200 毫秒。

11 月 5 日 18:00 UTC，Denim 升级在 Base 主网激活。以前每两秒一个正式区块，现在每秒五个，每个都有自己的哈希、状态根和交易收据，也各自走一遍 unsafe、safe、finalized 的完整生命周期。顺手退场的还有 Flashblocks——那个「提前告诉你交易大概成了」的预确认机制没了，pending 这个 RPC 标签一并作废。Base 的说法很直白：正式区块已经够快，不需要预告了。

但 Denim 真正改的不是出块速度，是时间。

block.number 快进十倍，timestamp 没动

每个区块仍精确间隔 200 毫秒，由协议强制，不看排序器的表。但 block.timestamp 还是整秒递增，五个区块共用一个秒值。

于是同一秒里 block.number 能跳 5 格。任何把「区块数」当「时长」用的合约，实际时间都缩到十分之一：

• block.number - start >= N 这类时间锁、冷却期、退出延迟，提前十倍触发；
• 按区块算的归属和释放计划，十倍速跑完；
• 每区块重置一次的限速器，变成每秒重置五次，等效额度直接乘十；
• 治理投票窗口按区块算的缩成十分之一，包括 ERC20Votes 默认拿 block number 当 clock 的实现。检查点数据没错，错的是你对窗口长度的预期。

最难受的是写死成 immutable 常量的那些：升级能改，常量改不了，只能迁移。

Uniswap V3 那种 TWAP 倒还好，累加器按秒加权，价格不会错。但固定 observation cardinality 能覆盖的墙钟历史只剩一半，长周期的 observe() 会更早撞上 OLD 回滚——不报错的地方最危险。

毫秒精度藏在第二笔交易里

以太坊区块头只有秒级 timestamp，Base 不想改 header，于是加了一笔元数据 deposit，固定在 tx[1]，带毫秒位，但只允许 0、200、400、600、800。完整时间 = 秒 × 1000 + 毫秒位，相邻区块必须差 200，不能跳格。

聪明，也别扭：一个区块的真实时间藏在第二笔交易里，节点漏验这笔 deposit，整块作废。

我的看法

Base 今年第四次独立升级，前面 Azul、Beryl、Cobalt 都在加功能，这次改的是底层语义。200 毫秒出块对支付、交易、GameFi 确实有意义，状态更新更密，时间可预期。但代价是 Base 把一次「时间单位迁移」扔给了整个生态，而且是悄悄扔的：协议层看不出异常，出事的是那些读起来毫无问题的老合约。

还有一笔账没人算：区块数涨十倍，RPC 调用、日志订阅、索引成本跟着涨十倍，最后还是会以某种形式回到用户身上。

如果你在 Base 上跑合约，今天就能做一件事：grep 一遍 block.number，看它是被当编号用，还是被当时钟用。前者没事，后者要么改成 block.timestamp，要么准备迁移。别等清算逻辑提前十倍触发那天，才发现自己写的是区块，不是秒。

免责声明：以上内容仅供娱乐交流，不构成任何投资建议。DYOR。

#cryptocurrencies #blockchain #pickful