Zcash 开发者再提区块时间缩减：NU7 刚落地，又要把出块时间从 25 秒压到 20 秒

导语

Zcash 的网络升级墨迹未干，开发者已经把目光投向了下一轮参数调整。距离 NU7 升级在主网上线仅过去几天，Zcash 开发者 ValarDragon 和 Evan Forbes 于周日在社区治理论坛提交了一份新的 ZIP（Zcash Improvement Proposal）草案，提议将区块目标间隔从 25 秒进一步降至 20 秒，并希望该改动进入下一次社区投票、纳入即将到来的 NU7.1 网络升级。

这不是一次单纯的“提速”。提案方明确表示，缩短出块时间不会增加网络每日隐私交易的整体处理能力，也不会改变 Zcash 2100 万枚的供应上限与发行节奏。它的目标更聚焦：降低交易首次确认的等待时间，改善线下支付、交易所充值和跨链兑换的用户体验。在隐私公链正试图用更低延迟重新争取支付场景的当下，这场围绕“20 秒是不是最优解”的治理讨论，比参数本身更值得关注。

现象：NU7 刚把出块时间砍掉三分之二，开发者又要再降 20%

根据提交在 Zcash Community Forum 的提案，ValarDragon 和 Evan Forbes 把这次调整定位为 ZIP 218 的后续动作。ZIP 218 正是本轮 NU7 升级中把出块时间从 75 秒降至 25 秒的技术提案。换句话说，NU7 上线前，社区讨论的终点从来不是 25 秒，而只是“下一步”。

提案给出的理由与 ZIP 218 一脉相承：在 Zcash 上，每笔交易都要等待被打包进区块，即便区块几乎是空的。这种等待对线下 POS 支付、交易所充值，以及像 NEAR Intents 这类跨链兑换尤其不友好——做市商通常需要至少一次确认才会执行后续操作。把区块间隔从 25 秒压到 20 秒，能直接缩短“首次确认时间”，也能改善连续支付、新用户入门等场景的体验。

提案同时强调，这次改动是“纯延迟优化”（latency-only change），不会影响网络每天能处理的隐私交易总量。为了保持轻钱包的同步负载上限不变，提案会把屏蔽交易的动作限制（action limits）随出块时间同比例缩放，使每日最坏情况下的处理量维持原样。提案方测算，这样做带来的每日差异仅在 76KB 左右的区块头数据量。

从幅度上看，如果提案落地，Zcash 的出块时间将在不到一周内经历两轮下调：NU7 把 75 秒砍到 25 秒（降幅 67%），NU7.1 再降到 20 秒（再降 20%）。这意味着交易首次确认的理论等待时间将从约 25 秒进一步压缩，对时间敏感型应用而言，累积体验改善会比单次调整更明显。

背景：NU7 到底改变了什么

要理解这轮快速迭代，得先看清 NU7 的分量。Zcash 的 NU7 升级于 11 月 6 日（周五）在主网区块高度 3,543,405 激活，带来三件大事：

第一，出块时间从 75 秒降至 25 秒，这是 Zcash 自 2019 年 12 月 Blossom 升级（150 秒降至 75 秒）以来首次调整该参数。为保持每日发行量不变，每个区块的奖励被相应除以三，2100 万枚 ZEC 的供应上限和减半节奏不受影响。

第二，引入网络可持续机制（Network Sustainability Mechanism），将交易费用的 60% 暂时移出流通，用于从 2031 年 2 月左右开始的未来挖矿奖励，以此在区块奖励趋近于零后维持矿工激励。这一设计试图回答隐私工作量证明网络长期面临的“矿工收入从哪里来”问题。

第三，永久关闭 2016 年上线的初代屏蔽池 Sprout。由于 NU7 使 v4 交易失效，仍有约 1.22 万枚 ZEC 留在 Sprout 池中无法转移，即便持有者拥有正确的私钥。这部分“滞留资金”成为 NU7 落地后最直接的争议点。

从时间线看，NU7 激活后仅数日就出现新的出块时间提案，反映出 Zcash 社区对“支付可用性”的紧迫感。开发者在提案中直言：“成为 Zcash 里的‘cash’（现金），关键就是提升可用性。”

机制：20 秒安全吗？开发者拿孤儿率数据说话

出块越快，区块在网络中传播不及、形成“孤儿块”（orphan block）的概率就越高，这是缩短区块时间最核心的技术风险。提案方对此做了压力测试：在一个覆盖全球 12 个区域、共 80 个矿工的测试网络上，以 20 秒间隔打包完整的 2MB 区块，在最坏负载情况下测得的孤儿率，已经优于此前为 25 秒设定的安全基准。

作为参照，当初决定采用 25 秒时，实证实验的孤儿率为 4.68%，理论模型为 3.26%。提案方称，得益于 Zakura 和 Zebra 节点客户端的工程优化，20 秒方案已经满足此前为 25 秒设立的“就绪门槛”。社区讨论中还贴出一张截图显示，当前主网的实际孤儿率甚至低于升级前，开发者将其归因于节点软件的优化成效。

针对“更短出块时间是否会降低每次确认的安全性”这一质疑，提案的回应是：对抗少数算力攻击时，安全性随确认数呈指数增长，因此只需略微增加确认数即可维持同等安全；对抗经济或多数算力攻击时，关键指标是支付之上累积的区块奖励，而以单位时间计算，这一指标并未改变。提案也没有要求任何服务方降低自己的确认次数。

节点硬件方面，提案称不会带来实质性的硬件门槛提升。在被攻击的极端情况下，带宽需求增加约 25%，但同步所需带宽仅为约 100KB/s，CPU 要求并未上升。开发者还提到，当前 Zcash 主网峰值处理量约 80KB/s，调整后约为 100KB/s，“仍然是拨号上网都能承受的体量”。

影响：隐私公链的支付叙事，正在从“能不能用”转向“快不快”

这次提案表面上是 5 秒的参数之争，背后是 Zcash 在隐私公链赛道的位置焦虑。过去几年，隐私币的核心叙事长期停留在合规压力和交易所下架，而 NU7 之后，开发重心明显转向可用性与网络可持续性：更短的确认时间、可持续的矿工激励、更轻的钱包同步。

对交易所和跨链协议而言，更短的出块时间意味着充值确认和跨链兑换的等待成本下降，这直接影响用户体验和做市效率。对线下支付场景，首次确认时间的缩短是让 Zcash 真正接近“现金”体验的必要条件之一。

但也要看到，仅靠出块时间无法解决隐私公链的全部瓶颈。提案方自己也承认，真正的吞吐量提升要等到 Tachyon 等降低单笔屏蔽操作成本的技术落地，届时可以在不改变出块时间的前提下单独提高动作限制。提案方甚至建议，20 秒之后的下一个大动作应该是把最大区块大小翻倍，配合 Tachyon 实现屏蔽吞吐量翻倍。换句话说，20 秒只是延迟优化路径上的一个中间点，而非终点。

风险与后续观察

这次改动仍需走完整治理流程：进入社区投票、被纳入 NU7.1 升级、最终在主网激活。治理过程中，社区可能会继续追问一个更根本的问题：20 秒是否真的是当前条件下的最优解？论坛讨论中已有参与者提出，是否应该基于现有数据更精确地定位最优值，而不是凭经验取整——“是 17 秒更好，还是 21.4 秒更合适？”

需要关注的变量包括：社区投票结果与 NU7.1 的时间表；孤儿率在真实主网环境中的变化；以及更短的出块时间是否会对轻钱包同步和节点带宽造成未预期的压力。截至发稿，ZEC 报价约为 1223 美元，24 小时上涨约 1.18%，24 小时成交量约 8.02 亿美元，市值约 201.6 亿美元。

对持有者而言，这类参数调整通常不会改变资产属性或发行总量，但它折射出的方向值得留意：Zcash 正在把“支付可用性”重新摆到路线图的中心位置。而在 NU7 刚刚完成供应机制与屏蔽池重构的背景下，社区是否愿意在短时间内再次承担升级风险，将是这场治理博弈的关键看点。