尧图网页设计 
Zcash 1.1.1 版本发布说明深度解析Sapling 网络升级共识准备、v4 交易格式与 zcash-cli 参数隐私【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash本文基于 Zcash 仓库的 1.1.1 正式版发布说明系统解读该版本承载的三项核心能力Sapling 网络升级的共识层代码准备、激活后强制启用的 v4 交易格式以及zcash-cli -stdin参数隐私机制与 scriptSig 的 SIGHASH 类型解码。读者阅读后将理解 1.1.1 在 Zcash 网络升级时间线上的位置、如何用-nuparams在 regtest 下手动激活 Sapling、如何安全地通过标准输入传递钱包口令以及如何读懂交易scriptSig.asm中新增的签名哈希类型标注并结合仓库源码确认这些行为背后的实现。版本定位1.1.1 是通往 Sapling 主网激活的过渡版本1.1.1 是 Zcash 在 Overwinter 与 Sapling 两大网络升级之间的关键过渡版本。它的核心使命是把 Sapling 网络升级的共识代码准备工作完整合入按照 ZIP 243 与 Sapling 协议规范Sapling spec定义的规则共识层已经具备识别、解析并验证 Sapling 交易的能力。与此同时钱包与 RPC 层面的 Sapling 支持仍在开发中按发布说明所述预计在后续数周内合入 master。从当前仓库的源码可以印证这一点src/consensus/upgrades.cpp中的NetworkUpgradeInfo表仍然保留着当时引入的各个网络升级分支 IDbranch ID定义其中 Overwinter 为0x5ba81b19、Sapling 为0x76b809bb见 upgrades.cpp。CurrentEpoch/CurrentEpochBranchId等函数upgrades.cpp正是依据当前区块高度是否达到某升级的激活高度来决定网络当前所处的 epoch进而选择对应的签名哈希等共识规则——这套安全升级约定正是从 Overwinter 开始引入、Sapling 继续沿用的机制。Sapling 网络升级的共识层准备测试网临时激活与参数策略由于 Sapling 的最终参数仍由 Sapling MPC 多方计算在生成中1.1.1 采取了临时方案Sapling 将于测试网高度 252500 以占位参数dummy parameters激活。这次激活是临时的测试网将在 2.0.0 版本中被回滚届时主网与测试网将统一使用同一套正式参数。这对测试用户有两个直接提醒若想继续测试 Overwinter 相关功能应在测试网上继续运行1.1.0之后再升级到 2.0.0在 2.0.0 回滚测试网时Sapling 的分支 ID 会随之改变因为 Zcash 遵循 Overwinter 引入的安全升级约定因此 1.1.1 中用于手动激活的-nuparams配置值届时也会变化。regtest 模式下手动激活 Sapling发布说明给出了在 regtest 模式下于指定高度激活网络升级的方法-nuparams5ba81b19:HEIGHT -nuparams76b809bb:HEIGHT其中5ba81b19是 Overwinter 分支 ID76b809bb是 Sapling 分支 IDHEIGHT是希望该升级生效的区块高度。从当前仓库的init.cpp可以看到-nuparamshexBranchId:activationHeight被明确标注为 regtest-only 配置项init.cpp其解析逻辑遍历mapMultiArgs[-nuparams]把用户指定的激活高度写入对应升级的nActivationHeightinit.cpp。随后NetworkUpgradeState会在nHeight nActivationHeight时判定该升级为UPGRADE_ACTIVEupgrades.cpp。这也解释了为何测试网需要运行参数获取命令使用测试网或 regtest 节点的用户必须提前下载 Sapling 测试网参数。按发布说明源码构建用户执行./zcutil/fetch-params.sh --testnet二进制包 / Debian 用户执行zcash-fetch-params --testnet参数下载脚本位于 zcutil/fetch-params.sh其目标是把验证密钥等参数文件放置到节点运行时读取的位置供 Sapling 证明与验证逻辑使用。主网行为提醒1.1.1 仍按升级前规则运行由于当时 Sapling 主网激活高度尚未确定1.1.1 即使在将来 Sapling 于主网激活之后行为仍与其他 pre-Sapling 版本一致——即1.1.1 节点不会自动开始执行 Sapling 共识规则。想要跟随主网 Sapling 网络升级的用户必须从 1.1.1 升级到后续版本。这一必须在激活前完成升级的约束是 Zcash 网络升级流程的常规要求。Sapling 激活后的 v4 交易格式发布说明明确指出一旦 Sapling 激活所有交易必须使用新的 v4 格式包括 coinbase 交易。所有创建新交易的 RPC 方法如createrawtransaction、getblocktemplate在区块高度达到 Sapling 激活高度后都会生成 v4 交易。从 changelog 可以看到这一改动在源码侧的落地路径Adjust consensus rules to require v4 transactions from Sapling activation——共识规则要求 v4Implement basic Sapling v4 transaction parser——实现基础 v4 解析器Add Sapling v4 transactions to IsStandard——把 v4 交易纳入标准交易判定Update CreateNewContextualCMutableTransaction to create Sapling transactions——交易构造入口生成 Sapling 交易Expire Overwinter transactions before the Sapling activation height——在激活高度之前让 Overwinter 交易过期避免跨升级边界的不一致。与 v4 格式配套的还有交易大小上限的提升。changelog 中 Raise 100kB transaction size limit from Sapling activation 与 Rename MAX_TX_SIZE to MAX_TX_SIZE_AFTER_SAPLING 对应到当前源码consensus.h 中定义MAX_TX_SIZE_AFTER_SAPLING MAX_BLOCK_SIZE即 Sapling 激活后不再沿用旧版的 100 kB 交易上限main.cpp 中通过static_assert保证块大小 升级后交易上限 升级前交易上限的约束关系并用GetSerializeSize(tx, ...) MAX_TX_SIZE_AFTER_SAPLING判定bad-txns-oversize。针对新上限的边界测试位于 test_checktransaction.cpp分别构造序列化大小为MAX_TX_SIZE_AFTER_SAPLING - 1、MAX_TX_SIZE_AFTER_SAPLING与MAX_TX_SIZE_AFTER_SAPLING 1的交易并断言验证结果同文件 还用GetValidTransaction(0x5ba81b19)构造 Overwinter epoch 下的合法交易来配合测试。changelog 中另有 Benchmark the largest valid Sapling transaction in validatelargetx 与 Add test of Sapling transaction size boundary说明新上限经过基准与回归测试双重验证。此外与 Sapling 相关的还有两条安全约束coinbase 交易不能包含 shielded spend 或 output以及交易必须有非空输出——这两条在 main.cpp 的 no-sink-of-funds 检查中仍有体现tx.vout.empty() tx.vJoinSplit.empty() tx.GetSaplingOutputsCount() 0且无 Orchard 输出时拒绝。zcash-cli用-stdin保护敏感参数RPC 命令行客户端新增-stdin参数用于从标准输入逐行读取额外参数直到 EOF 或 Ctrl-D。典型用法是解锁钱包$ src/zcash-cli -stdin walletpassphrase mysecretcode 120 ^D (Ctrl-D)第一行mysecretcode是钱包口令第二行120是解锁秒数。发布说明强烈建议将-stdin用于私钥、口令这类敏感信息因为命令行参数会出现在进程表中系统上任何用户通常都能读取——而标准输入则不会暴露在进程列表中。从当前仓库的 bitcoin-cli.cpp 可以看到完整的实现细节帮助文本明确说明其用途Read extra arguments from standard input, one per line until EOF/Ctrl-D (recommended for sensitive information such as passphrases)且特别注明当首个额外参数是walletpassphrase时第一行口令不会被回显bitcoin-cli.cppCommandLineRPC中当-stdin开启且首个参数为walletpassphrase时调用SetStdinEcho(false)关闭终端回显bitcoin-cli.cpp随后循环std::getline(std::cin, line)把每行追加为 RPC 参数bitcoin-cli.cppSetStdinEcho在 POSIX 下通过tcgetattr/tcsetattr操作ECHO标志位在 Windows 下通过GetConsoleMode/SetConsoleMode操作ENABLE_ECHO_INPUTbitcoin-cli.cpp并且对非终端输入做了兼容处理非终端时 stdin 本身不会回显不算错误。这一改动源自 Bitcoin Core 的 Input-from-stdin mode for bitcoin-cli PR1.1.1 将其引入 Zcash 并配套更新了发布说明。scriptSig 的 asm 表示新增 SIGHASH 类型解码改动内容与影响范围此前交易输入的scriptSig.asm属性会把 DER 签名原样以十六进制呈现1.1.1 起只要签名携带了合法且已定义的哈希类型hash typeasm表示就会在末尾追加解码出的哈希类型名称。影响面覆盖所有输出 scriptSig 汇编表示的地方RPCgetrawtransactionRPCdecoderawtransactionREST/rest/tx/JSON 格式REST/rest/block/JSON 格式且包含扩展交易详情时zcash-tx -json发布说明给出的示例对比同一签名从304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001变为304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL]可见原来末尾的签名哈希类型字节01即SIGHASH_ALL被替换为可读的[ALL]DER 签名主体保持不变。源码实现这一行为由 core_write.cpp 的ScriptToAsmStr实现类型解码表mapSigHashTypes覆盖全部 6 种已定义哈希类型ALL、ALL|ANYONECANPAY、NONE、NONE|ANYONECANPAY、SINGLE、SINGLE|ANYONECANPAYcore_write.cpp函数通过fAttemptSighashDecode参数控制是否尝试解码。对 push 数据先做CheckSignatureEncoding校验沿用SCRIPT_VERIFY_STRICTENC的编码约束校验通过后取出数据最后一字节查表命中则把该字节替换为[类型名]core_write.cpp关键在于调用方只对可能包含签名的 scriptSig开启该参数decodescriptRPC 的汇编输出没有变化正是因为它被配置为专门处理scriptPubKey而非 scriptSig 脚本如注释所述scriptPubKey 应传false。这也解释了为什么发布说明强调decodescript输出不变——它处理的对象与 scriptSig 汇编表示的场景不同。zcash-tx -json与bitcoin-tx工具侧则有配套的sighashOptions表ALL/NONE/SINGLE及各自ANYONECANPAY组合见 bitcoin-tx.cpp用于签名时的哈希类型解析方便对账验证。Changelog 关键条目解读除上述三大特性外1.1.1 的 changelog 还包含若干值得关注的底层改进按主题归纳如下序列化体系重构Pieter Wuille 等引入prevector类型、COMPACTSIZE包装器、CSizeComputer优化序列化器、unique_ptr/shared_ptr的序列化支持并逐步移除nType/nVersion从 Zcash 专用序列化代码中的使用。changelog 中 Jack Grigg 的 GetSerializeSize changes in Zcash-specific codeRemove nType and nVersion from Zcash-specific codeHandle usage of prevector for CScript 等条目正是 Zcash 侧对这一重构的适配。地址与密钥编码拆分将 Bech32 参考代码与测试引入为后续 Sapling 地址格式铺路、把地址/密钥编解码从 base58 拆分出独立的key_io模块并引入CZC*各类封装。Sapling 侧则新增SpendDescription/OutputDescription数据结构、valueBalance共识规则、{Encode,Decode}PaymentAddress等接口以及 Track net value entering and exiting the Sapling circuit 的净值跟踪逻辑。Sapling 默克尔树与 nullifier 集合新增 Sapling merkle tree 实现与回归测试向量将锚点anchor相关代码从 Sprout 专用泛化为SPROUT/SAPLING双树支持如GetBestAnchor(SAPLING)、PushSaplingAnchor并把 Sprout/Sapling nullifier 缓存与映射按类型区分命名。证明与签名验证接入 librustzcash 的 Groth16 证明与验证、检查 Sapling Spend/Output 证明与签名、实现 ZIP 243 定义的 Sapling 签名哈希并更新 sighash 测试同时实现同笔交易内不得出现重复 Sapling nullifier的检查。RPC 与工具增强createrawtransaction支持按输入设置 sequence number 与可选 locktimegetblock增加 verbosity 级别以可选返回完整交易详情回移 Bitcoin PR #8704uacomment配置参数按 BIP-0014 向 user agent 追加注释并限制总长度统一使用EXIT_系列符号常量替换魔法数字退出码。内存与健壮性OOM 时不再抛出std::bad_alloc而是立即终止并在终止前尽量输出日志prevector分配失败同样先记录再终止。升级与操作要点小结测试网/regtest 用户升级 1.1.1 前先获取 Sapling 测试网参数源码构建./zcutil/fetch-params.sh --testnet二进制/Debianzcash-fetch-params --testnet。regtest 手动激活使用-nuparams5ba81b19:HEIGHT -nuparams76b809bb:HEIGHT在指定高度同时激活 Overwinter 与 Sapling注意这些分支 ID 在 2.0.0 回滚测试网后会变化。主网用户Sapling 主网激活高度当时未定1.1.1 不会自动跟随主网 Sapling 激活届时必须升级到后续版本才能遵循 Sapling 共识规则。参数隐私涉及钱包口令、私钥等敏感信息的 RPC 调用一律改用zcash-cli -stdin从标准输入读取避免参数出现在进程表。交易调试解析交易时可通过getrawtransaction/decoderawtransaction/zcash-tx -json的scriptSig.asm直接看到签名哈希类型如[ALL]decodescript因面向 scriptPubKey 而不受影响。相关文件索引发布说明原文 release-notes-1.1.1.md 与候选版 release-notes-1.1.1-rc1.md升级参数与分支 ID upgrades.cpp-nuparams解析 init.cppCLI 标准输入实现 bitcoin-cli.cppSIGHASH 解码 core_write.cpp交易大小上限 consensus.h 与校验 main.cpp相关测试 test_checktransaction.cpp。【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Zcash 1.1.1 版本发布说明深度解析：Sapling 网络升级共识准备、v4 交易格式与 zcash-cli 参数隐私
Zcash 1.1.1 版本发布说明深度解析Sapling 网络升级共识准备、v4 交易格式与 zcash-cli 参数隐私【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash本文基于 Zcash 仓库的 1.1.1 正式版发布说明系统解读该版本承载的三项核心能力Sapling 网络升级的共识层代码准备、激活后强制启用的 v4 交易格式以及zcash-cli -stdin参数隐私机制与 scriptSig 的 SIGHASH 类型解码。读者阅读后将理解 1.1.1 在 Zcash 网络升级时间线上的位置、如何用-nuparams在 regtest 下手动激活 Sapling、如何安全地通过标准输入传递钱包口令以及如何读懂交易scriptSig.asm中新增的签名哈希类型标注并结合仓库源码确认这些行为背后的实现。版本定位1.1.1 是通往 Sapling 主网激活的过渡版本1.1.1 是 Zcash 在 Overwinter 与 Sapling 两大网络升级之间的关键过渡版本。它的核心使命是把 Sapling 网络升级的共识代码准备工作完整合入按照 ZIP 243 与 Sapling 协议规范Sapling spec定义的规则共识层已经具备识别、解析并验证 Sapling 交易的能力。与此同时钱包与 RPC 层面的 Sapling 支持仍在开发中按发布说明所述预计在后续数周内合入 master。从当前仓库的源码可以印证这一点src/consensus/upgrades.cpp中的NetworkUpgradeInfo表仍然保留着当时引入的各个网络升级分支 IDbranch ID定义其中 Overwinter 为0x5ba81b19、Sapling 为0x76b809bb见 upgrades.cpp。CurrentEpoch/CurrentEpochBranchId等函数upgrades.cpp正是依据当前区块高度是否达到某升级的激活高度来决定网络当前所处的 epoch进而选择对应的签名哈希等共识规则——这套安全升级约定正是从 Overwinter 开始引入、Sapling 继续沿用的机制。Sapling 网络升级的共识层准备测试网临时激活与参数策略由于 Sapling 的最终参数仍由 Sapling MPC 多方计算在生成中1.1.1 采取了临时方案Sapling 将于测试网高度 252500 以占位参数dummy parameters激活。这次激活是临时的测试网将在 2.0.0 版本中被回滚届时主网与测试网将统一使用同一套正式参数。这对测试用户有两个直接提醒若想继续测试 Overwinter 相关功能应在测试网上继续运行1.1.0之后再升级到 2.0.0在 2.0.0 回滚测试网时Sapling 的分支 ID 会随之改变因为 Zcash 遵循 Overwinter 引入的安全升级约定因此 1.1.1 中用于手动激活的-nuparams配置值届时也会变化。regtest 模式下手动激活 Sapling发布说明给出了在 regtest 模式下于指定高度激活网络升级的方法-nuparams5ba81b19:HEIGHT -nuparams76b809bb:HEIGHT其中5ba81b19是 Overwinter 分支 ID76b809bb是 Sapling 分支 IDHEIGHT是希望该升级生效的区块高度。从当前仓库的init.cpp可以看到-nuparamshexBranchId:activationHeight被明确标注为 regtest-only 配置项init.cpp其解析逻辑遍历mapMultiArgs[-nuparams]把用户指定的激活高度写入对应升级的nActivationHeightinit.cpp。随后NetworkUpgradeState会在nHeight nActivationHeight时判定该升级为UPGRADE_ACTIVEupgrades.cpp。这也解释了为何测试网需要运行参数获取命令使用测试网或 regtest 节点的用户必须提前下载 Sapling 测试网参数。按发布说明源码构建用户执行./zcutil/fetch-params.sh --testnet二进制包 / Debian 用户执行zcash-fetch-params --testnet参数下载脚本位于 zcutil/fetch-params.sh其目标是把验证密钥等参数文件放置到节点运行时读取的位置供 Sapling 证明与验证逻辑使用。主网行为提醒1.1.1 仍按升级前规则运行由于当时 Sapling 主网激活高度尚未确定1.1.1 即使在将来 Sapling 于主网激活之后行为仍与其他 pre-Sapling 版本一致——即1.1.1 节点不会自动开始执行 Sapling 共识规则。想要跟随主网 Sapling 网络升级的用户必须从 1.1.1 升级到后续版本。这一必须在激活前完成升级的约束是 Zcash 网络升级流程的常规要求。Sapling 激活后的 v4 交易格式发布说明明确指出一旦 Sapling 激活所有交易必须使用新的 v4 格式包括 coinbase 交易。所有创建新交易的 RPC 方法如createrawtransaction、getblocktemplate在区块高度达到 Sapling 激活高度后都会生成 v4 交易。从 changelog 可以看到这一改动在源码侧的落地路径Adjust consensus rules to require v4 transactions from Sapling activation——共识规则要求 v4Implement basic Sapling v4 transaction parser——实现基础 v4 解析器Add Sapling v4 transactions to IsStandard——把 v4 交易纳入标准交易判定Update CreateNewContextualCMutableTransaction to create Sapling transactions——交易构造入口生成 Sapling 交易Expire Overwinter transactions before the Sapling activation height——在激活高度之前让 Overwinter 交易过期避免跨升级边界的不一致。与 v4 格式配套的还有交易大小上限的提升。changelog 中 Raise 100kB transaction size limit from Sapling activation 与 Rename MAX_TX_SIZE to MAX_TX_SIZE_AFTER_SAPLING 对应到当前源码consensus.h 中定义MAX_TX_SIZE_AFTER_SAPLING MAX_BLOCK_SIZE即 Sapling 激活后不再沿用旧版的 100 kB 交易上限main.cpp 中通过static_assert保证块大小 升级后交易上限 升级前交易上限的约束关系并用GetSerializeSize(tx, ...) MAX_TX_SIZE_AFTER_SAPLING判定bad-txns-oversize。针对新上限的边界测试位于 test_checktransaction.cpp分别构造序列化大小为MAX_TX_SIZE_AFTER_SAPLING - 1、MAX_TX_SIZE_AFTER_SAPLING与MAX_TX_SIZE_AFTER_SAPLING 1的交易并断言验证结果同文件 还用GetValidTransaction(0x5ba81b19)构造 Overwinter epoch 下的合法交易来配合测试。changelog 中另有 Benchmark the largest valid Sapling transaction in validatelargetx 与 Add test of Sapling transaction size boundary说明新上限经过基准与回归测试双重验证。此外与 Sapling 相关的还有两条安全约束coinbase 交易不能包含 shielded spend 或 output以及交易必须有非空输出——这两条在 main.cpp 的 no-sink-of-funds 检查中仍有体现tx.vout.empty() tx.vJoinSplit.empty() tx.GetSaplingOutputsCount() 0且无 Orchard 输出时拒绝。zcash-cli用-stdin保护敏感参数RPC 命令行客户端新增-stdin参数用于从标准输入逐行读取额外参数直到 EOF 或 Ctrl-D。典型用法是解锁钱包$ src/zcash-cli -stdin walletpassphrase mysecretcode 120 ^D (Ctrl-D)第一行mysecretcode是钱包口令第二行120是解锁秒数。发布说明强烈建议将-stdin用于私钥、口令这类敏感信息因为命令行参数会出现在进程表中系统上任何用户通常都能读取——而标准输入则不会暴露在进程列表中。从当前仓库的 bitcoin-cli.cpp 可以看到完整的实现细节帮助文本明确说明其用途Read extra arguments from standard input, one per line until EOF/Ctrl-D (recommended for sensitive information such as passphrases)且特别注明当首个额外参数是walletpassphrase时第一行口令不会被回显bitcoin-cli.cppCommandLineRPC中当-stdin开启且首个参数为walletpassphrase时调用SetStdinEcho(false)关闭终端回显bitcoin-cli.cpp随后循环std::getline(std::cin, line)把每行追加为 RPC 参数bitcoin-cli.cppSetStdinEcho在 POSIX 下通过tcgetattr/tcsetattr操作ECHO标志位在 Windows 下通过GetConsoleMode/SetConsoleMode操作ENABLE_ECHO_INPUTbitcoin-cli.cpp并且对非终端输入做了兼容处理非终端时 stdin 本身不会回显不算错误。这一改动源自 Bitcoin Core 的 Input-from-stdin mode for bitcoin-cli PR1.1.1 将其引入 Zcash 并配套更新了发布说明。scriptSig 的 asm 表示新增 SIGHASH 类型解码改动内容与影响范围此前交易输入的scriptSig.asm属性会把 DER 签名原样以十六进制呈现1.1.1 起只要签名携带了合法且已定义的哈希类型hash typeasm表示就会在末尾追加解码出的哈希类型名称。影响面覆盖所有输出 scriptSig 汇编表示的地方RPCgetrawtransactionRPCdecoderawtransactionREST/rest/tx/JSON 格式REST/rest/block/JSON 格式且包含扩展交易详情时zcash-tx -json发布说明给出的示例对比同一签名从304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001变为304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL]可见原来末尾的签名哈希类型字节01即SIGHASH_ALL被替换为可读的[ALL]DER 签名主体保持不变。源码实现这一行为由 core_write.cpp 的ScriptToAsmStr实现类型解码表mapSigHashTypes覆盖全部 6 种已定义哈希类型ALL、ALL|ANYONECANPAY、NONE、NONE|ANYONECANPAY、SINGLE、SINGLE|ANYONECANPAYcore_write.cpp函数通过fAttemptSighashDecode参数控制是否尝试解码。对 push 数据先做CheckSignatureEncoding校验沿用SCRIPT_VERIFY_STRICTENC的编码约束校验通过后取出数据最后一字节查表命中则把该字节替换为[类型名]core_write.cpp关键在于调用方只对可能包含签名的 scriptSig开启该参数decodescriptRPC 的汇编输出没有变化正是因为它被配置为专门处理scriptPubKey而非 scriptSig 脚本如注释所述scriptPubKey 应传false。这也解释了为什么发布说明强调decodescript输出不变——它处理的对象与 scriptSig 汇编表示的场景不同。zcash-tx -json与bitcoin-tx工具侧则有配套的sighashOptions表ALL/NONE/SINGLE及各自ANYONECANPAY组合见 bitcoin-tx.cpp用于签名时的哈希类型解析方便对账验证。Changelog 关键条目解读除上述三大特性外1.1.1 的 changelog 还包含若干值得关注的底层改进按主题归纳如下序列化体系重构Pieter Wuille 等引入prevector类型、COMPACTSIZE包装器、CSizeComputer优化序列化器、unique_ptr/shared_ptr的序列化支持并逐步移除nType/nVersion从 Zcash 专用序列化代码中的使用。changelog 中 Jack Grigg 的 GetSerializeSize changes in Zcash-specific codeRemove nType and nVersion from Zcash-specific codeHandle usage of prevector for CScript 等条目正是 Zcash 侧对这一重构的适配。地址与密钥编码拆分将 Bech32 参考代码与测试引入为后续 Sapling 地址格式铺路、把地址/密钥编解码从 base58 拆分出独立的key_io模块并引入CZC*各类封装。Sapling 侧则新增SpendDescription/OutputDescription数据结构、valueBalance共识规则、{Encode,Decode}PaymentAddress等接口以及 Track net value entering and exiting the Sapling circuit 的净值跟踪逻辑。Sapling 默克尔树与 nullifier 集合新增 Sapling merkle tree 实现与回归测试向量将锚点anchor相关代码从 Sprout 专用泛化为SPROUT/SAPLING双树支持如GetBestAnchor(SAPLING)、PushSaplingAnchor并把 Sprout/Sapling nullifier 缓存与映射按类型区分命名。证明与签名验证接入 librustzcash 的 Groth16 证明与验证、检查 Sapling Spend/Output 证明与签名、实现 ZIP 243 定义的 Sapling 签名哈希并更新 sighash 测试同时实现同笔交易内不得出现重复 Sapling nullifier的检查。RPC 与工具增强createrawtransaction支持按输入设置 sequence number 与可选 locktimegetblock增加 verbosity 级别以可选返回完整交易详情回移 Bitcoin PR #8704uacomment配置参数按 BIP-0014 向 user agent 追加注释并限制总长度统一使用EXIT_系列符号常量替换魔法数字退出码。内存与健壮性OOM 时不再抛出std::bad_alloc而是立即终止并在终止前尽量输出日志prevector分配失败同样先记录再终止。升级与操作要点小结测试网/regtest 用户升级 1.1.1 前先获取 Sapling 测试网参数源码构建./zcutil/fetch-params.sh --testnet二进制/Debianzcash-fetch-params --testnet。regtest 手动激活使用-nuparams5ba81b19:HEIGHT -nuparams76b809bb:HEIGHT在指定高度同时激活 Overwinter 与 Sapling注意这些分支 ID 在 2.0.0 回滚测试网后会变化。主网用户Sapling 主网激活高度当时未定1.1.1 不会自动跟随主网 Sapling 激活届时必须升级到后续版本才能遵循 Sapling 共识规则。参数隐私涉及钱包口令、私钥等敏感信息的 RPC 调用一律改用zcash-cli -stdin从标准输入读取避免参数出现在进程表。交易调试解析交易时可通过getrawtransaction/decoderawtransaction/zcash-tx -json的scriptSig.asm直接看到签名哈希类型如[ALL]decodescript因面向 scriptPubKey 而不受影响。相关文件索引发布说明原文 release-notes-1.1.1.md 与候选版 release-notes-1.1.1-rc1.md升级参数与分支 ID upgrades.cpp-nuparams解析 init.cppCLI 标准输入实现 bitcoin-cli.cppSIGHASH 解码 core_write.cpp交易大小上限 consensus.h 与校验 main.cpp相关测试 test_checktransaction.cpp。【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考