BNB Chain拟开放毫秒时间戳：报价期限更细，成交速度为何未必改变

BNB Chain的Jenner升级再次进入资讯视野，焦点是让合约读到毫秒级区块时间。Odaily在2026年11月2日23时28分报道了BEP-706，而官方10月22日的升级指南已经解释了它的用途。对报价和拍卖应用，更细的时间读数确实有用；但读者若由此推导出交易会更快成交、预言机价格会更准，便跨过了这次改动实际覆盖的范围。判断价值，应从一笔带截止时间的报价如何被执行开始。

报价期限变细，承担价格风险的人才可能受益

做市商签出一份短时有效的报价，承诺在指定期限内按约定价格成交。价格在链外变化，报价却要等交易进入区块后才能执行。BEP-706提案举出的具体需求是，报价有效期可能只有几百毫秒，而合约原来通过block.timestamp取得的时间只有秒级精度。同一秒内出现的多个区块，可能拥有相同的秒级时间读数，合约无法借这个字段区分它们在秒内的位置。

这会影响截止条件的表达。若应用把期限向上取整，实际允许成交的窗口就可能宽于做市商原先愿意承担的期限；向下取整又会让仍有经济意义的报价提前失效。做市商可以用更宽的价差补偿风险，用户也可能因此获得较差报价。这是一条合理的机制链条，但只能说明精度问题可能进入报价成本，不能证明某个平台已经因它提高了价差。

BEP-706改善的是合约判断截止时点所使用的读数，不保证报价交易在截止前被打包。用户签名、网络传输、排序和执行仍然占用时间。即使合约能区分更细的时间，交易排到执行位置时已经过期，仍会失败；更严格地拒绝过期报价甚至可能让失败数量增加。业务效果要同时观察价差、成功成交率与失败交易成本，不能只展示计时单位从秒变成毫秒。

这里的示意把报价传递与链上判断分开。若报价提供方因此愿意给出更紧的价格，且用户成功成交后的总成本确实下降，才出现可验证的收益。若链外延迟一直主导失败，改进时间读数仍有工程价值，却未必改变用户最终支付的成本。相关应用入口可通过下方资料继续了解，是否支持新功能需以各自公告为准。

Binance全球顶级交易所 v3.22.4

类型：金融理财大小：306.2M语言：多国语言[中文]时间：11-2评分：10.0

0x70读取已有区块信息，旧合约不会自动换单位

官方提案说明，BSC区块头此前已经携带毫秒时间信息，客户端能够读取，但EVM原有时间指令只返回整秒。BEP-706新增地址为0x70的预编译入口，将正在执行的区块时间以毫秒形式返回。它把共识已经处理的信息交给合约使用，不需要另外接入一只外部时钟。返回值是自Unix纪元以来的毫秒数，提案规定用32字节无符号整数表示。

接入的第一道问题是单位，而非显示位数

官方保留block.timestamp的秒级行为，让存量合约继续按原单位计算。开发者必须显式调用新入口，才能取得毫秒值。这种设计避免大量既有期限判断在升级后突然改变意义，也意味着某条链支持新入口，与某个应用已使用它，是两件需要分别核实的事。用户界面出现更精细的倒计时，同样不能证明结算合约已更换读数来源。

应用迁移时，要一起核对签名消息中的期限、后端生成的时间、合约比较的数值以及前端显示。若签名仍以秒计，合约却直接拿毫秒时间与之比较，业务含义会错位；反过来则可能留下远超预期的有效窗口。这里讨论的是接入风险，没有证据表明特定平台已经发生这种错误。合理的验收对象应是完整成交路径，而非一次读取函数成功返回。

提案还明确，激活前目标地址没有代码，行为遵循空账户调用规则。调用端因此不能只把底层调用未报错当成取得正确时间；还需检查返回数据的长度、网络是否支持以及解码结果是否符合预期。是否启用新路径，最好由明确的网络和版本配置控制，避免升级前后或多链部署间出现静默差异。这是由接口边界推导出的工程要求，不是已经观察到的漏洞事件。

更精细的区块时钟，仍由验证者提供

BEP-706的安全章节给出了最容易被新闻标题压缩掉的限定：时间戳来自验证者，受现有共识规则约束，提供的保证并不强于今天的block.timestamp。它增加分辨率，保留原有信任模型。官方升级指南也直接说明，这次改动不会改变区块速度。把读数精度写成吞吐扩张，或把毫秒时间当成绝对准确的现实世界时钟，都超出了来源证据。

下面将官方安全章节中的一句话作原文摘录排版，非网页截图。它适合放在接口说明之后，因为同一个返回值既要回答“能读多细”，也要回答“能信到什么程度”。

拍卖尤其需要这个区别。合约可以更细地表达截止时点，却仍要面对交易能否及时进入区块、区块内排序如何决定和时间在协议允许范围内如何取值。若业务希望证明某份订单在链外某一瞬间已提交，仅靠执行区块的时间无法补足这条证据；它记录的是区块上下文，不是用户发送消息的独立收据。更精细的读数能减少取整误差，不能自行证明先到先得。

价格新鲜度也需要检查价格自己的时间

预言机应用可用毫秒时间更细地检查数据是否过期，但检查能力受价格源本身的更新时间、发布节奏和时间字段单位限制。若数据只按较慢节奏更新，合约多取得几位时间读数，不会让底层价格自动刷新。将阈值设得很窄，可能拒绝仍符合业务用途的数据；放得太宽，又难以约束陈旧价格风险。阈值应随数据源和交易用途确定，不能从“支持毫秒”直接推出统一设置。

只有报价系统、数据源与结算路径的时间口径相互匹配，精度增加才有机会转化为经济收益。同样的功能，对依赖很短签名窗口的应用可能有价值，对期限很长的普通转账流程则未必构成实质改进。读者查阅相关工具时，也应分别核实支持网络、合约版本和功能生效条件。

欧易okx交易所 v6.195.1

类型：金融理财大小：549.4M语言：中文时间：11-1评分：10.0

升级前就可能变化的，是模拟调用的时间上下文

官方10月22日指南还列出一个容易被主网日期讨论遮住的兼容点：Reth端点升级到相关客户端版本后，部分RPC覆盖参数的变化立即适用，包括Jenner激活之前。对于eth_call、eth_estimateGas以及文档列出的跟踪和模拟方法，若提供blockOverrides.prevRandao，需要用32字节十六进制值编码0至999的毫秒余数；time字段仍然按秒处理。只覆盖time，会把毫秒余数重置为零。

这意味着团队不能把测试工作全部推迟到分叉当天。若模拟环境的秒内时间与实际执行上下文不一致，边界报价在模拟中有效、实际中过期，或出现相反结果，都可能干扰对业务逻辑的判断。这个风险应通过构造期限前后和同秒不同区块的测试条件来检查，同时保留所用客户端、RPC参数和响应。一次普通报价模拟成功，不能替代截止边界的核验；本文未对任何服务开展实测。

截至本次资料核验，官方公告页仍把主网列为2026年11月下旬、具体时间待公布，并保留版本尚待发布的表述；10月22日博客则已提及可用的Reth测试网版本，并要求主网时间另行确认。两页信息更新程度不同，不能拼成一个已经确认的主网激活时间。仓库提案页头仍标为Draft，也应与升级指南的纳入说明分别记录。应用方应跟踪对应客户端的正式发布和自己使用网络的生效配置。

对于BNB价值判断，这次改动最多先建立应用体验改善的可能路径。要形成更进一步的需求结论，还需看到采用新入口的实际应用、成功交易后的成本变化及持续使用。仅凭一项预编译被纳入升级，无法估算新增交易量或代币需求。眼下最值得核对的证据是一组真实报价在接入前后的执行结果，以及其中因时间边界拒绝的比例；没有这些数据，保持对功能边界的准确理解，比把精度升级换算成价格预期更有用。

资料来源

BNB Chain Jenner升级指南

BNB Chain Jenner升级时间表

BNB Chain BEP-706提案

Odaily 11月2日BEP-706报道