Zcash 5.1.0 区块验证性能优化与钱包变更解析zcashd 批量验证、Groth16/Halo 2 多线程与-preferredtxversion实务指南【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash本文以 Zcash 5.1.0 发布说明 为主体系统解读zcashd在区块验证、交易构造、RPC 接口与钱包层面的核心变更Sapling/Orchard 组件的批量验证与多线程优化、-preferredtxversion交易版本偏好参数、getrawtransaction的 Orchard 详情输出以及dumpwallet禁用等弃用策略。读完本文你将掌握 5.1.0 引入的验证流水线原理、相关配置参数的源码级语义以及升级节点与钱包时需要关注的兼容性要点。一、版本定位与主题概览Zcash 5.1.0 是继 5.0.0NU5 网络升级、Orchard 全面激活之后的第一个维护版本其主题非常集中把已验证有效的性能优化技术推广到更多 Sapling 与 Orchard 组件上同时收紧钱包与 RPC 层的实现细节。它不引入新的网络升级因此对运行 5.0.0 的节点属于低风险升级但对内部实现尤其是钱包存储与线程锁有不可忽视的调整。从源码结构看5.1.0 期间的改动横跨多个子系统区块验证src/main.cpp、交易构造src/transaction_builder.cpp、src/wallet/wallet_tx_builder.cpp、RPCsrc/rpc/rawtransaction.cpp、挖矿模板src/miner.cpp以及钱包src/wallet/rpcwallet.cpp。本文按发布说明的章节逐一展开并补充对应源码依据。二、更快的区块验证Sapling 与 Orchard 的批量验证与多线程2.1 背景区块验证为什么慢zcashd的区块校验流程ConnectBlock链式更新逻辑源自 Bitcoin Core绝大部分是单线程的。这决定了 Zcash 的区块验证性能天花板受限于单核。发布说明明确指出这一结构性限制来自链更新逻辑的继承实现因此优化思路不是重写整个校验流程而是把计算密集、彼此独立的密码学检查剥离出来并行化/批量化。在 5.1.0 之前zcashd已经具备两类针对性优化透明输入上的 ECDSA 签名通过多线程检查Orchard Action 上的 RedPallas 签名通过批量验证batch validation检查。2.2 5.1.0 新增的优化范围5.1.0 把上述技术推广到了 Sapling 与 Orchard 的更多密码学组件组件签名/证明采用的优化手段Sapling SpendRedJubjub 签名批量验证Sapling Spend / OutputGroth16 证明批量验证 多线程Orchard ActionHalo 2 证明批量验证 多线程Orchard ActionRedPallas 签名批量验证5.0.0 已引入继续保留这里的批量验证核心思想是把同批次内多个签名/证明的验证方程合并成单个校验利用椭圆曲线群上的线性组合将大量标量乘法的代价摊薄从而显著降低总体验证开销。验证不再是对每个交易单独调用一次而是把整个区块内的 Sapling bundle、Orchard bundle 分别排入一个批次最后一次性完成验证。2.3 源码级证据验证队列的建立在 src/main.cpp 的ContextualCheckShieldedInputs中可以看到这一流水线的直接实现Sapling bundle 通过sapling::init_batch_validator(true)初始化验证器src/main.cpp随后对每个交易的 Sapling bundle 调用QueueAuthValidation将其排入待验证队列src/main.cppOrchard bundle 同样通过orchard::init_batch_validator初始化并调用QueueAuthValidation入队src/main.cpp区块级验证入口还会在 IB 场景下显式禁用/启用批量验证器src/main.cpp说明批量验证在初始区块下载IBD与正常同步场景下有不同的策略考量。CheckTransaction的注释也印证了分工src/main.cppSprout 的 JoinSplit 证明由verifier.VerifySprout逐个校验而 Sapling 与 Orchard 的 zk-SNARK 证明则分别交由librustzcash_sapling_check_{spend,output}与orchard::AuthValidator::Batch处理。2.4 性能效果与线程控制发布说明给出的实测数据是在 Ryzen 9 5950X CPU 上历史区块的最坏情况验证时间下降了约 80%。这一数字来自官方在 5.1.0 中新增的ConnectBlock基准测试bench 中使用了区块 1708048 与 1723244 两个样本见 changelog 中 AddConnectBlockbenchmark 相关提交属于开发团队针对真实历史区块的测量结果。对于需要手动干预的场景线程数可通过环境变量控制RAYON_NUM_THREADS8 zcashdRAYON_NUM_THREADS来自 Zcash 所用的 Rust 并行计算库 rayon。它同时影响两类场景验证Groth16Sapling与 Halo 2Orchard证明的批量验证与多线程检查生成花销资金时即创建交易构造上述证明的过程。如果不设置rayon 默认使用与逻辑 CPU 数量一致的线程池在共享宿主机或小内存 VPS 上适当调低该值可以避免证明验证/生成与节点其他工作争抢 CPU。三、选项处理-preferredtxversion交易版本偏好3.1 参数语义5.1.0 新增命令行参数-preferredtxversion当一笔交易不包含必须使用特定版本才能表达的组件时节点优先以指定版本创建该交易。最典型的使用场景是向后兼容zcashd -preferredtxversion4设置-preferredtxversion4后只要交易不含 Orchard 组件Orchard 只能存在于 V5 交易中节点就会创建 V4 交易这对**接收方仍在使用旧版钱包尚未升级以解析 V5 交易**的场景非常有用——发送方主动降级交易版本避免接收方钱包无法解析。3.2 源码实现默认值定义在 src/main.hDEFAULT_PREFERRED_TX_VERSION ZIP225_TX_VERSION即默认偏好 V5ZIP225_TX_VERSION 5见 src/primitives/transaction.h支持的版本集合为SUPPORTED_TX_VERSIONS {SAPLING_TX_VERSION, ZIP225_TX_VERSION}src/main.h即当前共识层只接受 V4 与 V5 两种交易版本解析与校验在 src/init.cpp通过GetArg(-preferredtxversion, ...)读取若取值不在支持集合内启动时报Invalid value for -preferredtxversionversion并拒绝启动实际构造交易时src/transaction_builder.cpp 与 src/wallet/wallet_tx_builder.cpp 均按nPreferredTxVersion ZIP225_MIN_TX_VERSION判断是否回退到 V4只要交易不含 Orchard 组件且偏好版本为 V4就构造 V4 交易一旦涉及 Orchard强制使用 V5挖矿侧同样遵循该偏好BlockAssembler在矿工地址非 Orchard 且偏好 V4 时采用 V4 模板src/miner.cpp。3.3 测试佐证RPC 测试 qa/rpc-tests/mempool_nu_activation.py 与 qa/rpc-tests/coinbase_funding_streams.py 都以-preferredtxversion4启动节点验证了该参数在真实节点流程中的可用性。注意版本差异本文描述的是 5.1.0 引入时的行为。在后续版本如 6.3.0中-preferredtxversion的默认值已发生变更参见 release-notes-6.3.0.md如需在较新版本中复现 5.1.0 的默认偏好需显式传参。四、RPC 接口变更4.1getblocktemplate跳过证明与签名检查getblocktemplate是矿工获取候选区块模板的接口。5.1.0 起该 RPC 在构造模板时不再执行证明与签名检查。这一改动之所以安全是因为模板中的交易全部来自本地内存池mempool而每笔交易在进入内存池时AcceptToMemoryPool已经完成了完整校验。重复在模板构造阶段做同样的密码学检查只会浪费 CPU。其实现位于 src/miner.cpp 的BlockAssembler::CreateNewBlock对应 changelog 中 miner: Disable proof and signature checks in CreateNewBlock 提交。对矿工的实际收益是出块模板的生成延迟更低尤其是内存池中屏蔽交易shielded transaction较多时避免了在出块路径上重复验证 Groth16/Halo 2 证明。4.2getrawtransaction与decoderawtransaction输出 Orchard 详情此前这两个 RPC 对交易内 Orchard 组件的细节几乎是黑盒。5.1.0 起二者会输出完整的 Orchard action 信息对应 changelog 中 Add orchard_bundle FFI、use orchard_bundle ffi in getrawtransaction、add valueBalanceOrchard to getrawtransaction output 等提交。Orchard bundle 的 JSON 结构由 src/rpc/rawtransaction.cpp 的TxActionsToJSON与TxOrchardBundleToJSON生成主要字段包括bundle 级actionsaction 数组、valueBalanceZAT 计量已通过ValueFromAmount转为 ZEC 精度、valueBalanceZat原始 ZAT 整数action 级每个 action 一个对象cv承诺值、nullifier花费 nullifier、rkSpend 验证公钥、cmx输出承诺、ephemeralKey、encCiphertext加密密文、outCiphertext输出密文、spendAuthSig花费授权签名当交易不含任何 action时flags、anchor、proof、bindingSig等字段不会输出src/rpc/rawtransaction.cpp这与空 bundle 无这些字段的共识语义保持一致。这一改动使区块浏览器、审计工具与钱包开发者可以通过标准 RPC 直接解析 Orchard 组件无需依赖内部反序列化。配套测试见 qa/rpc-tests/wallet_orchard.pychangelog 中 Test getrawtransaction in wallet_orchard.py。五、钱包Wallet变更5.1 重扫Rescan性能提升5.1.0 对 NU5含 Orchard之后区块的重扫性能做了小幅优化单账户钱包整体重扫时间在 Ryzen 9 5950X 上降低约 6%。发布说明同时承认面对区块内塞满屏蔽输出的最坏情况未来仍需进一步优化。5.2cs_main锁与UpdatedTransaction信号这是 5.1.0 中对下游开发者最重要的内部改动CWallet::UpdatedTransaction信号不再在持有cs_main锁时被调用。背景cs_main是保护链状态的主锁几乎所有与链相关的关键路径都要竞争它。此前在持锁状态下触发钱包信号会导致在大钱包节点上 RPC 长时间阻塞。修复后信号在锁外派发cs_main的持有时间显著缩短。下游兼容警示发布说明原话凡是重新连接了NotifyTransactionChanged钱包信号的分叉代码不得再在该信号回调中访问由cs_main保护的全局变量否则会造成数据竞争或死锁。5.3ThreadNotifyWallets崩溃修复部分 5.0.0 节点在启动一段时间后会因以下错误退出ThreadNotifyWallets: Failed to read block X while notifying wallets of block disconnects根因是区块回滚disconnect通知阶段读取区块数据失败。5.1.0 会先尝试自动修复若修复无果则在关闭前明确提示用户需要执行重索引reindex。这避免了此前静默异常退出、原因不明的糟糕体验。5.4 不再存储 Merkle 分支此前每个钱包交易都会持久化一条 Merkle 分支Merkle branch用于证明交易存在于区块中——但该数据从未被用于任何超过昂贵的健全性检查之外的目的。5.1.0 起钱包不再存储它减小了钱包数据库体积、降低写放大。版本兼容注意如果将一个 5.1.0 创建/升级后的钱包放回旧版本节点加载旧节点会因缺少 Merkle 分支导致检查失败此时会自动触发重扫来重建数据、避免失败。因此跨版本回退钱包文件时需留意重扫带来的时间开销。六、弃用Deprecated策略6.1 本版本开始默认禁用dumpwalletdumpwalletRPC 自 5.1.0 起默认禁用但仍可通过-allowdeprecateddumpwallet重新启用。官方给出的禁用理由非常明确dumpwallet不适合作为备份手段——它不返回用于派生屏蔽地址的任何密钥信息即不包含 Sapling/Orchard 的屏蔽密钥用它备份等于漏掉了最关键的私钥材料。正确的替代方案是zcash-cli z_exportwallet filenamez_exportwallet会完整导出包含屏蔽密钥在内的全部钱包密钥材料。6.2 本版本开始新标记为弃用wallettxvjoinsplit作用范围控制gettransactionRPC 返回的已弃用vjoinsplit属性的可用性本版本中该功能仍然默认可用属于宣布弃用阶段若希望立即关闭可设置-allowdeprecatednone这会同时关闭全部已弃用特性按发布说明策略至少经过 3 个次版本发布后该特性将默认禁用届时必须显式传-allowdeprecatedwallettxvjoinsplit才能继续使用。对应源码gettransaction中输出vjoinsplit的逻辑位于 src/wallet/rpcwallet.cppRPC 帮助文本中已标注(DEPRECATED)同文件 src/wallet/rpcwallet.cpp。6.3-allowdeprecated机制小结-allowdeprecatedfeature参数支持多次指定-allowdeprecateda -allowdeprecatedb合法取值由GetAllowableDeprecatedFeatures()提供见 src/init.cpp 的参数帮助文本。汇总 5.1.0 的弃用矩阵特性状态处置方式dumpwalletRPC默认禁用临时启用-allowdeprecateddumpwallet长期方案改用z_exportwalletwallettxvjoinsplitgettransaction的vjoinsplit字段默认可用已宣布弃用提前关闭-allowdeprecatednone3 个次版本后默认禁用七、升级与运维建议综合上述变更从 5.0.0 升级到 5.1.0 时建议关注以下几点验证性能升级后最坏情况区块验证时间在官方基准Ryzen 9 5950X上下降约 80%高配机器默认配置即可受益共享 CPU 环境可调低RAYON_NUM_THREADS限制验证/证明生成的并发度。交易版本偏好若你的业务存在大量旧版钱包接收方可配置-preferredtxversion4让节点在无 Orchard 组件时输出 V4 交易注意该参数默认值为 5V5且后续版本中默认值有调整跨版本部署需复核。矿池/矿工getblocktemplate不再重复验证模板内交易的证明与签名出块延迟更低无需任何配置改动即可生效。钱包备份立即检查是否仍在用dumpwallet做备份——它不含屏蔽密钥必须改用z_exportwallet。钱包数据兼容5.1.0 钱包不再存储 Merkle 分支若需用旧版本节点加载 5.1.0 钱包会触发自动重扫请预留时间与磁盘 IO。分叉/下游代码若你维护zcashd的下游分叉并接入了NotifyTransactionChanged信号务必确认回调中不再访问cs_main保护的全局状态否则 5.1.0 的锁序调整可能引入新的竞态问题。八、延伸阅读完整发布说明原文doc/release-notes/release-notes-5.1.0.md批量验证实现ContextualCheckShieldedInputssrc/main.cpp、Sapling/Orchard 验证器初始化src/main.cpp交易版本参数默认值src/main.h、启动解析src/init.cpp、构造期应用src/transaction_builder.cppOrchard RPC 输出TxOrchardBundleToJSONsrc/rpc/rawtransaction.cpp弃用特性dumpwallet标记禁用src/wallet/rpcwallet.cpp、vjoinsplit字段输出src/wallet/rpcwallet.cpp相关测试qa/rpc-tests/mempool_nu_activation.py、qa/rpc-tests/wallet_orchard.py后续版本的默认值演进doc/release-notes/release-notes-6.3.0.md【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Zcash 5.1.0 区块验证性能优化与钱包变更解析：zcashd 批量验证、Groth16/Halo 2 多线程与 `-preferredtxversion` 实务指南
Zcash 5.1.0 区块验证性能优化与钱包变更解析zcashd 批量验证、Groth16/Halo 2 多线程与-preferredtxversion实务指南【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash本文以 Zcash 5.1.0 发布说明 为主体系统解读zcashd在区块验证、交易构造、RPC 接口与钱包层面的核心变更Sapling/Orchard 组件的批量验证与多线程优化、-preferredtxversion交易版本偏好参数、getrawtransaction的 Orchard 详情输出以及dumpwallet禁用等弃用策略。读完本文你将掌握 5.1.0 引入的验证流水线原理、相关配置参数的源码级语义以及升级节点与钱包时需要关注的兼容性要点。一、版本定位与主题概览Zcash 5.1.0 是继 5.0.0NU5 网络升级、Orchard 全面激活之后的第一个维护版本其主题非常集中把已验证有效的性能优化技术推广到更多 Sapling 与 Orchard 组件上同时收紧钱包与 RPC 层的实现细节。它不引入新的网络升级因此对运行 5.0.0 的节点属于低风险升级但对内部实现尤其是钱包存储与线程锁有不可忽视的调整。从源码结构看5.1.0 期间的改动横跨多个子系统区块验证src/main.cpp、交易构造src/transaction_builder.cpp、src/wallet/wallet_tx_builder.cpp、RPCsrc/rpc/rawtransaction.cpp、挖矿模板src/miner.cpp以及钱包src/wallet/rpcwallet.cpp。本文按发布说明的章节逐一展开并补充对应源码依据。二、更快的区块验证Sapling 与 Orchard 的批量验证与多线程2.1 背景区块验证为什么慢zcashd的区块校验流程ConnectBlock链式更新逻辑源自 Bitcoin Core绝大部分是单线程的。这决定了 Zcash 的区块验证性能天花板受限于单核。发布说明明确指出这一结构性限制来自链更新逻辑的继承实现因此优化思路不是重写整个校验流程而是把计算密集、彼此独立的密码学检查剥离出来并行化/批量化。在 5.1.0 之前zcashd已经具备两类针对性优化透明输入上的 ECDSA 签名通过多线程检查Orchard Action 上的 RedPallas 签名通过批量验证batch validation检查。2.2 5.1.0 新增的优化范围5.1.0 把上述技术推广到了 Sapling 与 Orchard 的更多密码学组件组件签名/证明采用的优化手段Sapling SpendRedJubjub 签名批量验证Sapling Spend / OutputGroth16 证明批量验证 多线程Orchard ActionHalo 2 证明批量验证 多线程Orchard ActionRedPallas 签名批量验证5.0.0 已引入继续保留这里的批量验证核心思想是把同批次内多个签名/证明的验证方程合并成单个校验利用椭圆曲线群上的线性组合将大量标量乘法的代价摊薄从而显著降低总体验证开销。验证不再是对每个交易单独调用一次而是把整个区块内的 Sapling bundle、Orchard bundle 分别排入一个批次最后一次性完成验证。2.3 源码级证据验证队列的建立在 src/main.cpp 的ContextualCheckShieldedInputs中可以看到这一流水线的直接实现Sapling bundle 通过sapling::init_batch_validator(true)初始化验证器src/main.cpp随后对每个交易的 Sapling bundle 调用QueueAuthValidation将其排入待验证队列src/main.cppOrchard bundle 同样通过orchard::init_batch_validator初始化并调用QueueAuthValidation入队src/main.cpp区块级验证入口还会在 IB 场景下显式禁用/启用批量验证器src/main.cpp说明批量验证在初始区块下载IBD与正常同步场景下有不同的策略考量。CheckTransaction的注释也印证了分工src/main.cppSprout 的 JoinSplit 证明由verifier.VerifySprout逐个校验而 Sapling 与 Orchard 的 zk-SNARK 证明则分别交由librustzcash_sapling_check_{spend,output}与orchard::AuthValidator::Batch处理。2.4 性能效果与线程控制发布说明给出的实测数据是在 Ryzen 9 5950X CPU 上历史区块的最坏情况验证时间下降了约 80%。这一数字来自官方在 5.1.0 中新增的ConnectBlock基准测试bench 中使用了区块 1708048 与 1723244 两个样本见 changelog 中 AddConnectBlockbenchmark 相关提交属于开发团队针对真实历史区块的测量结果。对于需要手动干预的场景线程数可通过环境变量控制RAYON_NUM_THREADS8 zcashdRAYON_NUM_THREADS来自 Zcash 所用的 Rust 并行计算库 rayon。它同时影响两类场景验证Groth16Sapling与 Halo 2Orchard证明的批量验证与多线程检查生成花销资金时即创建交易构造上述证明的过程。如果不设置rayon 默认使用与逻辑 CPU 数量一致的线程池在共享宿主机或小内存 VPS 上适当调低该值可以避免证明验证/生成与节点其他工作争抢 CPU。三、选项处理-preferredtxversion交易版本偏好3.1 参数语义5.1.0 新增命令行参数-preferredtxversion当一笔交易不包含必须使用特定版本才能表达的组件时节点优先以指定版本创建该交易。最典型的使用场景是向后兼容zcashd -preferredtxversion4设置-preferredtxversion4后只要交易不含 Orchard 组件Orchard 只能存在于 V5 交易中节点就会创建 V4 交易这对**接收方仍在使用旧版钱包尚未升级以解析 V5 交易**的场景非常有用——发送方主动降级交易版本避免接收方钱包无法解析。3.2 源码实现默认值定义在 src/main.hDEFAULT_PREFERRED_TX_VERSION ZIP225_TX_VERSION即默认偏好 V5ZIP225_TX_VERSION 5见 src/primitives/transaction.h支持的版本集合为SUPPORTED_TX_VERSIONS {SAPLING_TX_VERSION, ZIP225_TX_VERSION}src/main.h即当前共识层只接受 V4 与 V5 两种交易版本解析与校验在 src/init.cpp通过GetArg(-preferredtxversion, ...)读取若取值不在支持集合内启动时报Invalid value for -preferredtxversionversion并拒绝启动实际构造交易时src/transaction_builder.cpp 与 src/wallet/wallet_tx_builder.cpp 均按nPreferredTxVersion ZIP225_MIN_TX_VERSION判断是否回退到 V4只要交易不含 Orchard 组件且偏好版本为 V4就构造 V4 交易一旦涉及 Orchard强制使用 V5挖矿侧同样遵循该偏好BlockAssembler在矿工地址非 Orchard 且偏好 V4 时采用 V4 模板src/miner.cpp。3.3 测试佐证RPC 测试 qa/rpc-tests/mempool_nu_activation.py 与 qa/rpc-tests/coinbase_funding_streams.py 都以-preferredtxversion4启动节点验证了该参数在真实节点流程中的可用性。注意版本差异本文描述的是 5.1.0 引入时的行为。在后续版本如 6.3.0中-preferredtxversion的默认值已发生变更参见 release-notes-6.3.0.md如需在较新版本中复现 5.1.0 的默认偏好需显式传参。四、RPC 接口变更4.1getblocktemplate跳过证明与签名检查getblocktemplate是矿工获取候选区块模板的接口。5.1.0 起该 RPC 在构造模板时不再执行证明与签名检查。这一改动之所以安全是因为模板中的交易全部来自本地内存池mempool而每笔交易在进入内存池时AcceptToMemoryPool已经完成了完整校验。重复在模板构造阶段做同样的密码学检查只会浪费 CPU。其实现位于 src/miner.cpp 的BlockAssembler::CreateNewBlock对应 changelog 中 miner: Disable proof and signature checks in CreateNewBlock 提交。对矿工的实际收益是出块模板的生成延迟更低尤其是内存池中屏蔽交易shielded transaction较多时避免了在出块路径上重复验证 Groth16/Halo 2 证明。4.2getrawtransaction与decoderawtransaction输出 Orchard 详情此前这两个 RPC 对交易内 Orchard 组件的细节几乎是黑盒。5.1.0 起二者会输出完整的 Orchard action 信息对应 changelog 中 Add orchard_bundle FFI、use orchard_bundle ffi in getrawtransaction、add valueBalanceOrchard to getrawtransaction output 等提交。Orchard bundle 的 JSON 结构由 src/rpc/rawtransaction.cpp 的TxActionsToJSON与TxOrchardBundleToJSON生成主要字段包括bundle 级actionsaction 数组、valueBalanceZAT 计量已通过ValueFromAmount转为 ZEC 精度、valueBalanceZat原始 ZAT 整数action 级每个 action 一个对象cv承诺值、nullifier花费 nullifier、rkSpend 验证公钥、cmx输出承诺、ephemeralKey、encCiphertext加密密文、outCiphertext输出密文、spendAuthSig花费授权签名当交易不含任何 action时flags、anchor、proof、bindingSig等字段不会输出src/rpc/rawtransaction.cpp这与空 bundle 无这些字段的共识语义保持一致。这一改动使区块浏览器、审计工具与钱包开发者可以通过标准 RPC 直接解析 Orchard 组件无需依赖内部反序列化。配套测试见 qa/rpc-tests/wallet_orchard.pychangelog 中 Test getrawtransaction in wallet_orchard.py。五、钱包Wallet变更5.1 重扫Rescan性能提升5.1.0 对 NU5含 Orchard之后区块的重扫性能做了小幅优化单账户钱包整体重扫时间在 Ryzen 9 5950X 上降低约 6%。发布说明同时承认面对区块内塞满屏蔽输出的最坏情况未来仍需进一步优化。5.2cs_main锁与UpdatedTransaction信号这是 5.1.0 中对下游开发者最重要的内部改动CWallet::UpdatedTransaction信号不再在持有cs_main锁时被调用。背景cs_main是保护链状态的主锁几乎所有与链相关的关键路径都要竞争它。此前在持锁状态下触发钱包信号会导致在大钱包节点上 RPC 长时间阻塞。修复后信号在锁外派发cs_main的持有时间显著缩短。下游兼容警示发布说明原话凡是重新连接了NotifyTransactionChanged钱包信号的分叉代码不得再在该信号回调中访问由cs_main保护的全局变量否则会造成数据竞争或死锁。5.3ThreadNotifyWallets崩溃修复部分 5.0.0 节点在启动一段时间后会因以下错误退出ThreadNotifyWallets: Failed to read block X while notifying wallets of block disconnects根因是区块回滚disconnect通知阶段读取区块数据失败。5.1.0 会先尝试自动修复若修复无果则在关闭前明确提示用户需要执行重索引reindex。这避免了此前静默异常退出、原因不明的糟糕体验。5.4 不再存储 Merkle 分支此前每个钱包交易都会持久化一条 Merkle 分支Merkle branch用于证明交易存在于区块中——但该数据从未被用于任何超过昂贵的健全性检查之外的目的。5.1.0 起钱包不再存储它减小了钱包数据库体积、降低写放大。版本兼容注意如果将一个 5.1.0 创建/升级后的钱包放回旧版本节点加载旧节点会因缺少 Merkle 分支导致检查失败此时会自动触发重扫来重建数据、避免失败。因此跨版本回退钱包文件时需留意重扫带来的时间开销。六、弃用Deprecated策略6.1 本版本开始默认禁用dumpwalletdumpwalletRPC 自 5.1.0 起默认禁用但仍可通过-allowdeprecateddumpwallet重新启用。官方给出的禁用理由非常明确dumpwallet不适合作为备份手段——它不返回用于派生屏蔽地址的任何密钥信息即不包含 Sapling/Orchard 的屏蔽密钥用它备份等于漏掉了最关键的私钥材料。正确的替代方案是zcash-cli z_exportwallet filenamez_exportwallet会完整导出包含屏蔽密钥在内的全部钱包密钥材料。6.2 本版本开始新标记为弃用wallettxvjoinsplit作用范围控制gettransactionRPC 返回的已弃用vjoinsplit属性的可用性本版本中该功能仍然默认可用属于宣布弃用阶段若希望立即关闭可设置-allowdeprecatednone这会同时关闭全部已弃用特性按发布说明策略至少经过 3 个次版本发布后该特性将默认禁用届时必须显式传-allowdeprecatedwallettxvjoinsplit才能继续使用。对应源码gettransaction中输出vjoinsplit的逻辑位于 src/wallet/rpcwallet.cppRPC 帮助文本中已标注(DEPRECATED)同文件 src/wallet/rpcwallet.cpp。6.3-allowdeprecated机制小结-allowdeprecatedfeature参数支持多次指定-allowdeprecateda -allowdeprecatedb合法取值由GetAllowableDeprecatedFeatures()提供见 src/init.cpp 的参数帮助文本。汇总 5.1.0 的弃用矩阵特性状态处置方式dumpwalletRPC默认禁用临时启用-allowdeprecateddumpwallet长期方案改用z_exportwalletwallettxvjoinsplitgettransaction的vjoinsplit字段默认可用已宣布弃用提前关闭-allowdeprecatednone3 个次版本后默认禁用七、升级与运维建议综合上述变更从 5.0.0 升级到 5.1.0 时建议关注以下几点验证性能升级后最坏情况区块验证时间在官方基准Ryzen 9 5950X上下降约 80%高配机器默认配置即可受益共享 CPU 环境可调低RAYON_NUM_THREADS限制验证/证明生成的并发度。交易版本偏好若你的业务存在大量旧版钱包接收方可配置-preferredtxversion4让节点在无 Orchard 组件时输出 V4 交易注意该参数默认值为 5V5且后续版本中默认值有调整跨版本部署需复核。矿池/矿工getblocktemplate不再重复验证模板内交易的证明与签名出块延迟更低无需任何配置改动即可生效。钱包备份立即检查是否仍在用dumpwallet做备份——它不含屏蔽密钥必须改用z_exportwallet。钱包数据兼容5.1.0 钱包不再存储 Merkle 分支若需用旧版本节点加载 5.1.0 钱包会触发自动重扫请预留时间与磁盘 IO。分叉/下游代码若你维护zcashd的下游分叉并接入了NotifyTransactionChanged信号务必确认回调中不再访问cs_main保护的全局状态否则 5.1.0 的锁序调整可能引入新的竞态问题。八、延伸阅读完整发布说明原文doc/release-notes/release-notes-5.1.0.md批量验证实现ContextualCheckShieldedInputssrc/main.cpp、Sapling/Orchard 验证器初始化src/main.cpp交易版本参数默认值src/main.h、启动解析src/init.cpp、构造期应用src/transaction_builder.cppOrchard RPC 输出TxOrchardBundleToJSONsrc/rpc/rawtransaction.cpp弃用特性dumpwallet标记禁用src/wallet/rpcwallet.cpp、vjoinsplit字段输出src/wallet/rpcwallet.cpp相关测试qa/rpc-tests/mempool_nu_activation.py、qa/rpc-tests/wallet_orchard.py后续版本的默认值演进doc/release-notes/release-notes-6.3.0.md【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考