Zcash基金会发布Zebra 7.0.0版本，支持NU7主网升级
Zcash基金会已发布Zebra 7.0.0版本，正式支持NU7主网升级。基金会提醒节点运营商必须在区块高度3,543,405（预计于11月5日左右）之前完成升级。
核心摘要
为确保留在共识链上，主网运营商必须在激活前完成升级。Zebra 6.4.x系列版本将在升级前数天停止运行。NU7引入了25秒的出块时间，同时保留了既定的ZEC每日发行计划。基金会表示，Zebra 7.0.0版本包含对五项安全公告的修复。
主网运营商必须及时升级
Zcash基金会在10月22日的公告中强调，主网运营商必须安装此次升级以保持在共识链上，而较旧的6.4.x版本将在激活前几天自动停止服务。“所有主网运营商必须在高度3,543,405（约11月5日）之前升级，以留在共识链上。”
基金会列出了该版本的主要功能，包括：25秒出块、网络可持续性机制（Network Sustainability Mechanism），以及对五项安全漏洞的修复。
Zebra 6.4.x 面临更早的停机通知
基金会在10月6日的工程更新中指出，Zebra 6.4.x版本的预期停机时间约为11月2日。开发者将软件的操作周期从15周缩短至12周，以确保在计划中的网络升级之前停止服务。
在同一份更新中，工程团队表示，过期计算和同步估算已根据每个区块高度的实际出块时间进行了调整。如果没有这一调整，更快的出块速度可能导致软件比预期更早停止运行。
NU7测试网与主网激活细节
基金会确认，NU7已于10月4日在区块高度4,465,026处进入公共测试网阶段。测试网的激活引入了共识更改，供用户在主网部署前进行观察。
此前报道指出，开发人员在10月20日的ZIP编辑者会议后确定了主网激活高度。截至当时的报告截止点，该更改仍等待整合到部署规范中。目前的ZIP-259文本已将主网区块高度列为3,543,405。其兼容性规则规定，升级后的节点在激活后将断开与广播旧网络协议版本的节点的连接。
规范警告称，不受支持的软件可能会继续在线并遵循非NU7的共识分支，但并未明确说明仍有多少运营商使用不兼容的软件。
Zcash旨在加快确认速度而不增加发行量
ZIP-218将新的目标出块时间设定为25秒，低于此前的75秒。提案作者指出，支付、交易所存款和跨链操作均受确认等待时间的影响。
该提案不建议客户端减少确认次数。其在讨论回滚风险时区分了不同的安全模型，包括基于攻击者挖矿份额的模型和基于逆转支付经济成本的模型。
基金会在10月2日的候选版本说明中表示，每日计划的发行量保持不变，因为软件会将计划的区块奖励除以三，并调整剩余的减半间隔。其描述保留了四年一次的减半时间表和2100万ZEC的供应上限。因此，更快的出块并不意味着计划的每日挖矿补贴会翻三倍。
九月的持币者投票结果显示，约99.9%的参与者支持缩短出块间隔，98.9%支持保留减半机制。近240万ZEC参与了投票，根据9月16日发布的覆盖结果，这约占快照时合格Ironwood余额的66%。投票于9月14日关闭，当时记录了8月24日主网区块3,459,350时的余额。资格取决于在该快照时在Ironwood钱包中持有的可花费屏蔽资金。
NU7将交易费重定向至未来挖矿奖励
基金会的候选版本说明描述了一种分配机制：60%的交易费退出流通进入储备金，矿工保留剩余的40%。
在网络可持续性机制下，储备资金可以通过未来的区块奖励逐步返还。10月21日的激活报道指出，主网区块8,939,664（预计将于2031年2月左右）将是重新发行的起始点。
持币者在九月的投票中以约96.6%的支持率 favor 了这一时间点。部署规范将重新发行高度与NU7激活高度分开列出。
10月2日的技术解释向矿池提供了相关指示。由于coinbase交易依赖于选定的交易费和父区块的储备金，矿工应请求新的区块模板，而不是自行更改其交易集或前一个区块。
基金会描述了针对单个矿池的限制以及跨矿池共享的预算。其工程更新表示，这些限制旨在保护轻量级钱包免受垃圾信息的干扰，尤其是在网络出块频率提高的情况下。
ZIP-218将共享的屏蔽预算设定为每区块330个动作，并辅以单独的矿池限制。其作者估计，这些变化将最坏情况下的每日轻量级钱包同步带宽从271兆字节减少到169兆字节，降幅约为37%。
提案指出存在另外的隐私权衡。更频繁的出块使观察者能够获得更精细的时间信息，这些信息可以与来自网络或应用程序的观察相结合。其作者表示，新限制并不能防止流量分析或消除拒绝服务风险。
Sprout资金面临独立的支出截止日期
10月5日的测试网报道描述了影响Sprout资金（Zcash最初的屏蔽池）的另一项NU7变更。禁用版本4事务意味着除非持有者在激活前转移资金，否则激活后将无法花费这些资金。
ZIP-259规定，该禁令适用于所有版本4事务，包括纯透明事务和Sapling事务。离线签署的保存事务同样需要激活检查。
规范指出，版本5和6保持其现有结构，但其签名承诺于共识分支标识符。未更改的事务格式并不能保证事务在激活后仍然有效。
