Zcash持币者支持减半与25秒区块提议
来源发布日期: 2026-09-14 · 编辑分析发布日期: 2026-09-17
NU7投票对矿工意味着什么：提议支持、实际激活与奖励核算属于不同问题。
分析与实际影响
本节为本站分析及示例计算，与来源报道分开呈现。
这是投票结果，并非激活通知
9月14日的NU7持币者结果支持保留减半，并支持25秒区块提议。官方论坛还记录其他社区面板的意见。投票支持并不能证明网络升级已经激活。
先看投票使用的计量单位
按币数量加权的结果与参与人数衡量不同事物。本站假设两位参与者分别拥有一个和九个投票单位：相同的人数，因选择不同，可以代表加权结果的十分之一或十分之九。这不是对实际投票的重建。比较不同面板之前，应记录参加资格、权重、弃权处理，以及百分比采用的分母。不能把持币者偏好改写成所有用户、矿工或咨询成员都同意。保留这些区别，比一个笼统的全体共识标题更有用。若报告只给百分比而不提供投票单位，应先找回原始说明，再决定这些结果是否适合放在同一张比较表中。不同问题也可能存在不同有效参与范围，不能默默沿用另一题的分母。
更短区块间隔不等于矿机提速
对运营者而言，编辑提出的问题是共识变化怎样影响核算，而不是实体矿机是否突然计算得更快。假设一条链把目标间隔从75秒改为25秒，那么相同时间内目标区间数量变为三倍。但仅凭这个算术不能证明矿工币收入也变成三倍，因为每区间奖励、工作分配和其他规则同样重要。若假设系统维持总发行量不变，每区间奖励就需要相应调整。这是一般性情景，并非声称准确的NU7奖励规则已经上线。阅读新闻时，应把网络参数、硬件性能和收入账目分别看待；把它们都写成矿机收益提升，会跳过真正需要核对的条件。本站没有为任何Zcash设备宣称由投票带来的实测性能增益。
建立版本与兼容性记录
网络升级之前，运营者可以先登记矿池端点、节点版本、管理软件及准确矿机固件，而不必立即安装未经验证的镜像。应识别究竟哪个组件需要改变，并从负责该组件的维护者取得说明。不能默认节点更新就意味着每台ASIC也必须刷机。对自己控制的组件，应保留回退与观察计划。ASIC.tools没有测试NU7软件，本报道也不提供新固件文件或具体型号安装指令。记录中还应说明哪些系统由矿池或托管方维护，避免多个团队成员同时修改同一环节。把版本清单与正式维护通知放在一起，可以让后续检查集中在真实需要升级的组件，而不是依据新闻标题批量采取操作。
明确什么证据能说明激活
下一次更新应分别说明提议获得支持、代码发布、激活日程公布，以及网络实际运行。它们是不同证据层级。保留维护者通知并明确适用哪一条网络；测试网络的观察不能证明主网已经改变。日期如果仍有条件，就应保留条件。日历目标不是已经完成的部署。用这种框架，治理投票就不会被误认为计算器奖励输入已经立即变化。更新输入时，应依据所建模时段真正适用的规则。若存在多个软件版本，还需要记录哪个版本与哪个阶段对应，而不是只记录一个最新标签。这样新闻事实、准备工作和实际上线状态都能保持可追踪，后续报道也不会把同一项投票重新描述成第二次升级完成。
预算应独立于新闻标题
设备预算应采用已确认功率、运行时间和自己的电价，再分别建模币价与奖励假设。假设500 W设备运行20小时，就使用10 kWh电量，与治理提议受欢迎程度无关。更快的目标确认属于用户体验问题，硬件能源费用属于另一项问题。不能用代币价格变动或投票百分比代替针对自己场地的预算。本例是独立算术，不是某个Zcash设施的测量，也不是价格预测。预算表还应注明币种、费用单位和记录时间，避免把某天的市场价格与另一个时期的网络规则混在一起。对于自己尚未验证的假设，保留明确标签，比给出没有依据的精确回本日期更能帮助比较设备。
读者接下来应观察什么
有价值的后续应是维护者支持的范围、准备情况与激活说明，再加相关网络的运行报告。每个新主张应与九月投票记录比较，不应把同一次投票重复当作另一个新事件。持币者结果与咨询面板结果应分别标注。本文档案照片只展示电子硬件，并不是Zcash品牌矿机，也不是投票过程的现场。这篇文章没有声称新ASIC型号已经推出、特定固件已经发布，或主网区块间隔已经改变。若未来出现正式激活信息，应注明来源和适用版本，并让读者能够返回原来的治理记录核对从提议到实施的过程。媒体报道日期与投票结束日期同样应分开，不能因为新闻在较晚日期传播，就把原事件也改成那一天。
团队交接应保留的内容
内部交接时，应保存来源链接、事件日期、提议状态、负责软件的维护者，以及下一步仍需要什么证据。为版本清单指定负责人，并说明是否已经批准任何本地操作。团队成员应该能区分观察任务与安装任务。若没有激活通知，就让日期字段保持未确认，不要从乐观标题填入一个日期。矿池支持回复也应与记录一起保存，以便之后使用相同设备和端点比较变化。交接文件可以注明哪些结论来自公开公告，哪些来自自己观察，哪些仍属假设。如果日后某项输入改变，保留旧版本及变更原因，不要把历史投票和未来实施结果混成一份没有时间层次的说明。这样的记录有助于让下一篇新闻报道真实新增证据，而不是只换一个标题重复同一事实。
分别记录每个阶段
可以建立一张简明状态表，把提议、已公布的投票结果、已经合并的软件、计划激活以及实际观察到的网络行为分别列出。每一行都应有自己的日期和证据。支持投票结果的链接，不能同时证明激活日期。节点采用的版本和矿池提供的确认，也应单独保存。这样，即使新闻标题以后更新，早期提议也不会悄悄变成已经完成的运行变化。对尚无证据的字段，明确写成等待确认，比套用另一阶段的日期更可靠。维护人员可以按照这张表安排观察任务，并在取得新的公开证据后更新对应行。
来源: Zcash Community Forum / poll organizers ↗
挖矿计算器 ↗
