尧图网站建设 
Zcash 1.1.0 版本解析Overwinter 升级、mempooltxinputlimit 弃用与 NODE_BLOOM 服务位【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash版本背景与导读Zcash 1.1.0 是该项目在 2018 年年中发布的一个重要里程碑版本。本版本的三个核心变化分别对应了网络升级的推进、历史技术债的清理以及 P2P 协议的标准化Overwinter 网络升级定档主网激活高度确定为 347500这是 Zcash 自 2016 年主网上线以来的第一次网络升级-mempooltxinputlimit启动弃用流程在 Overwinter 激活前继续生效激活后将被忽略为后续彻底移除铺路引入NODE_BLOOM服务位按照 BIP 111 的规范让节点可以显式宣告自己对 Bloom 过滤器的支持能力。阅读本文后你将掌握 Overwinter 升级在源码中的激活机制与参数定义、-mempooltxinputlimit从引入到弃用的完整生命周期以及NODE_BLOOM服务位和-enforcenodebloom配置项的底层实现逻辑。以下内容以本仓库 release-notes-1.1.0.md 为主体并结合 src/chainparams.cpp、src/consensus/upgrades.cpp、src/main.cpp、src/init.cpp 等源码进行纵深佐证。Overwinter 网络升级主网激活高度 347500为什么 Overwinter 是一次里程碑式升级Overwinter 是 Zcash 部署的第一次网络升级。升级的核心内容包括引入支持交易过期transaction expiry的 v3 交易格式、解决从 Bitcoin 继承的二次哈希quadratic hashing问题并为后续更复杂的升级如 Sapling建立分叉保护机制replay protection。值得注意的是consensus.h 中定义了 Overwinter 交易的版本上下限/** The minimum allowed Overwinter transaction version (network rule) */ /** The maximum allowed Overwinter transaction version (network rule) */也就是 v3 交易版本自此成为新的网络规则约束。源码中的激活参数定义在 chainparams.cpp 中主网参数明确写入了 Overwinter 的激活高度和协议版本consensus.vUpgrades[Consensus::UPGRADE_OVERWINTER].nProtocolVersion 170005; consensus.vUpgrades[Consensus::UPGRADE_OVERWINTER].nActivationHeight 347500; consensus.vUpgrades[Consensus::UPGRADE_OVERWINTER].hashActivationBlock uint256S(0000000003761c0d0c3974b54bdb425613bbb1eaadd6e70b764de82f195ea243);而 upgrades.cpp 中的NetworkUpgradeInfo表则为每个升级定义了分支 IDbranch ID与名称{ .nBranchId 0x5ba81b19, .strName Overwinter, .strInfo See https://z.cash/upgrade/overwinter/ for details., },这里的 branch ID0x5ba81b19是 Overwinter 的共识分支标识用于在交易签名中提供重放保护确保升级后的交易无法在旧链上被重放。每个升级对应一个独立的 branch ID这与 IsConsensusBranchId 的实现相呼应——节点通过该函数校验收到的 branch ID 是否为已知共识分支。激活状态的判定逻辑在 upgrades.cpp 中CurrentEpoch()根据当前区块高度遍历所有升级返回当前所处的一致性时代int CurrentEpoch(int nHeight, const Consensus::Params params) { for (auto idxInt Consensus::MAX_NETWORK_UPGRADES - 1; idxInt Consensus::BASE_SPROUT; idxInt--) { if (params.NetworkUpgradeActive(nHeight, Consensus::UpgradeIndex(idxInt))) { return idxInt; } } // Base case return Consensus::BASE_SPROUT; }IsActivationHeight()upgrades.cpp则精确判断某个高度是否为某一升级的激活高度其核心就是nHeight params.vUpgrades[idx].nActivationHeight。从源码结构可以看到Overwinter 之后还有 Sapling419200、Blossom653600等后续升级这正体现了 Zcash 以固定激活高度驱动网络升级的设计模式。升级注意事项对于运行 zcashd 节点的用户来说主网高度 347500预计 2018 年 6 月 25 日左右出块意味着必须升级到 1.1.0 或之后的版本否则在 Overwinter 激活后将无法跟上主链升级后节点的协议版本将随时代切换而提升Overwinter 对应协议版本 170005交易过期机制的引入意味着钱包需要处理交易过期状态旧版本钱包产生的交易在升级后可能被新规则拒绝。-mempooltxinputlimit的弃用从应急补丁到功成身退选项的由来二次哈希性能问题-mempooltxinputlimit在 1.0.10 版本中引入其背景是 Zcash 从 Bitcoin 继承而来的二次哈希问题quadratic hashing当矿工构造区块时对包含大量透明输入transparent inputs的交易进行哈希验证的代价随输入数量呈平方级增长导致矿工挖矿性能受损。该选项通过限制进入内存池mempool的交易的最大透明输入数量来缓解这个问题。这一历史功能在 release-notes-1.0.10.md 中有明确记载Add option mempooltxinputlimit so the mempool can reject a transaction based on the number of transparent inputs. Check mempooltxinputlimit when creating a transaction to avoid local mempool rejection.同时钱包侧的z_shieldcoinbaseRPC 调用也引用该选项当limit参数设为 0 时将使用-mempooltxinputlimit的默认值50来限制一次屏蔽的 coinbase UTXO 数量参见 payment-api.md 与 shield-coinbase.md 的说明。为什么可以弃用随着 Bitcoin Core 代码库中多项性能优化被合并进 Zcash二次哈希问题得到了显著缓解。更重要的是Overwinter 升级本身包含了解决该问题的方案升级后一笔 1000 个输入的交易其验证耗时将与 10 笔各 100 个输入的交易相当——验证成本不再随输入数量呈平方级增长。因此这个应急性质的限制参数已经失去存在价值。过渡期的行为约定本版本1.1.0明确约定在 Overwinter 激活高度347500之前-mempooltxinputlimit继续强制生效Overwinter 激活之后该选项将被忽略未来版本将在 Overwinter 激活后彻底移除该选项。对应提交 Ignore -mempooltxinputlimit once Overwinter activates 正是这一逻辑的落地。事实上后续在 2.1.1 版本中该选项被正式移除见 release-notes-2.1.1.md 中的 Remove option mempooltxinputlimit。对于运维人员的操作建议如果你此前依赖-mempooltxinputlimit来防御大输入交易应确认 Overwinter 激活后的节点行为——该参数将自动失效但同时二次哈希问题已被根治无需再配置其他替代参数。NODE_BLOOM服务位P2P 协议能力的显式宣告BIP 111 的背景BIP 111参见 bips.md 中关于 BIP111 的更新记录定义了一个服务位service bit让节点能够显式地通告自己支持 Bloom 过滤器Bloom filters——这是 SPV 轻客户端常用的交易过滤机制。在此之前节点是否支持 Bloom 过滤是隐式的这给协议演进带来了困扰。BIP 111 同时提升了协议版本使新节点能够识别那些虽然允许 Bloom 过滤但没有宣告新服务位的旧节点。源码实现在 protocol.h 中定义了服务位常量// NODE_BLOOM means the node is capable and willing to handle bloom-filtered connections. NODE_BLOOM (1 2),在 init.cpp 中节点是否声明该服务位由-peerbloomfilters配置项控制if (GetBoolArg(-peerbloomfilters, DEFAULT_PEERBLOOMFILTERS)) nLocalServices | NODE_BLOOM;默认值定义在 main.hstatic const bool DEFAULT_PEERBLOOMFILTERS true; static const bool DEFAULT_ENFORCENODEBLOOM false;版本门槛170004 与 NO_BLOOM_VERSION本版本对NODE_BLOOM的执行策略是仅对发送协议版本170004的对等节点强制检查。version.h 中定义了该门槛常量//! filter* commands are disabled without NODE_BLOOM after and including this version static const int NO_BLOOM_VERSION 170004;在 main.cpp 中当本地节点未开启NODE_BLOOM时对filterload/filteradd命令的处理逻辑为else if (!(nLocalServices NODE_BLOOM) (strCommand filterload || strCommand filteradd)) { if (pfrom-nVersion NO_BLOOM_VERSION) { LOCK(cs_main); Misbehaving(pfrom-GetId(), 100); return false; } else if (GetBoolArg(-enforcenodebloom, DEFAULT_ENFORCENODEBLOOM)) { pfrom-fDisconnect true; return false; } }这里体现了两种保护层级对于协议版本170004的节点未声明NODE_BLOOM却发送过滤命令会被视为违规行为Misbehaving增加违规分数 100对于更旧的节点仅在显式开启-enforcenodebloom时才断开连接属于可选的宽松策略。与此同时本地节点自身若声明了NODE_BLOOM默认-peerbloomfilters1则 main.cpp 中正常的filterload处理流程会加载 Bloom 过滤器并开启交易中继pfrom-fRelayTxes true。SPV 客户端的适配建议官方在版本说明中给出的建议是SPV 客户端应检查节点报告的协议版本——对于版本 170004 及以上的节点必须验证其是否声明了NODE_BLOOM服务位再决定是否建立 Bloom 过滤连接。下一大版本将移除仅对 170004 强制这一过渡性限制届时所有版本的节点都需严格遵守该服务位约定。版本演进中的其他亮点1.1.0 还包含若干值得关注的基础设施改进可从 Changelog 部分梳理Rust 构建链硬化depends: Explicitly download and vendor Rust dependencies、Make Rust compilation mandatory即 Rust 依赖被显式下载并 vendor 化且 Rust 编译成为强制步骤——这为后续 Zcash 将更多密码学组件迁移到 Rust 奠定了构建基础依赖版本升级Boost 升级到 1.66.0、OpenSSL 升级到 1.1.0h并移除了 Boost 库的-mt后缀对应多次Remove -mt suffix提交Merkle 树与序列化优化Optimise serialization of MerklePath、使用uint64_t替代size_t作为序列化索引类型消除了std::vectorbool的歧义提升了跨平台一致性内存池与交易过期过期交易不再增加对等节点的违规分数Set ban score for expired txs to 0并记录移除过期交易时的 txid 日志RPC 新增z_listunspent由 Simon Liu 实现Closes #2910. Add z_listunspent RPC call用于列出钱包持有的未花费 notez_listreceivedbyaddress增强返回 JoinSplit 与 JoinSplitOutput 的索引dbwrapper 重构leveldbwrapper文件更名为dbwrapper.*CLevelDB*系列类名重命名并补充了迭代器相关测试构建与测试工具链新增用于启用 ASan/UBSan 与 TSan 的 configure 参数、支持通过环境变量在zcutil/build.sh中传入 configure 标志以及自动化回归auto-senescence通知改进。这些改动大多可在仓库源码中得到印证例如 dbwrapper 相关文件已按重构后的命名存在于 dbwrapper.cpp、dbwrapper.hz_listunspent等 RPC 的测试则散见于 qa/rpc-tests 目录下的钱包相关测试脚本中。总结Zcash 1.1.0 是一次承上启下的版本它敲定了 Overwinter 主网激活高度让网络第一次完成有规划的硬分叉升级它通过 Overwinter 内置的二次哈希解决方案正式启动了-mempooltxinputlimit的弃用流程它按照 BIP 111 引入NODE_BLOOM服务位为 P2P 层的 Bloom 过滤能力提供了显式、可协商的协议基础。同时Rust 强制编译、依赖升级、dbwrapper 重构等工程化改进也为后续 Sapling 及更远期升级铺平了道路。对于开发者与节点运营者本版本的三个关键词可以概括为升级到 1.1.0否则无法跟随 Overwinter 主网、理解-mempooltxinputlimit的过渡期行为激活前生效、激活后失效、适配NODE_BLOOM服务位检查SPV 客户端需按 170004 协议版本门槛校验。相关实现细节可继续深入 src/chainparams.cpp、src/consensus/upgrades.cpp、src/main.cpp 与 src/init.cpp 等源码文件查阅。【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Zcash 1.1.0 版本解析：Overwinter 升级、mempooltxinputlimit 弃用与 NODE_BLOOM 服务位
Zcash 1.1.0 版本解析Overwinter 升级、mempooltxinputlimit 弃用与 NODE_BLOOM 服务位【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash版本背景与导读Zcash 1.1.0 是该项目在 2018 年年中发布的一个重要里程碑版本。本版本的三个核心变化分别对应了网络升级的推进、历史技术债的清理以及 P2P 协议的标准化Overwinter 网络升级定档主网激活高度确定为 347500这是 Zcash 自 2016 年主网上线以来的第一次网络升级-mempooltxinputlimit启动弃用流程在 Overwinter 激活前继续生效激活后将被忽略为后续彻底移除铺路引入NODE_BLOOM服务位按照 BIP 111 的规范让节点可以显式宣告自己对 Bloom 过滤器的支持能力。阅读本文后你将掌握 Overwinter 升级在源码中的激活机制与参数定义、-mempooltxinputlimit从引入到弃用的完整生命周期以及NODE_BLOOM服务位和-enforcenodebloom配置项的底层实现逻辑。以下内容以本仓库 release-notes-1.1.0.md 为主体并结合 src/chainparams.cpp、src/consensus/upgrades.cpp、src/main.cpp、src/init.cpp 等源码进行纵深佐证。Overwinter 网络升级主网激活高度 347500为什么 Overwinter 是一次里程碑式升级Overwinter 是 Zcash 部署的第一次网络升级。升级的核心内容包括引入支持交易过期transaction expiry的 v3 交易格式、解决从 Bitcoin 继承的二次哈希quadratic hashing问题并为后续更复杂的升级如 Sapling建立分叉保护机制replay protection。值得注意的是consensus.h 中定义了 Overwinter 交易的版本上下限/** The minimum allowed Overwinter transaction version (network rule) */ /** The maximum allowed Overwinter transaction version (network rule) */也就是 v3 交易版本自此成为新的网络规则约束。源码中的激活参数定义在 chainparams.cpp 中主网参数明确写入了 Overwinter 的激活高度和协议版本consensus.vUpgrades[Consensus::UPGRADE_OVERWINTER].nProtocolVersion 170005; consensus.vUpgrades[Consensus::UPGRADE_OVERWINTER].nActivationHeight 347500; consensus.vUpgrades[Consensus::UPGRADE_OVERWINTER].hashActivationBlock uint256S(0000000003761c0d0c3974b54bdb425613bbb1eaadd6e70b764de82f195ea243);而 upgrades.cpp 中的NetworkUpgradeInfo表则为每个升级定义了分支 IDbranch ID与名称{ .nBranchId 0x5ba81b19, .strName Overwinter, .strInfo See https://z.cash/upgrade/overwinter/ for details., },这里的 branch ID0x5ba81b19是 Overwinter 的共识分支标识用于在交易签名中提供重放保护确保升级后的交易无法在旧链上被重放。每个升级对应一个独立的 branch ID这与 IsConsensusBranchId 的实现相呼应——节点通过该函数校验收到的 branch ID 是否为已知共识分支。激活状态的判定逻辑在 upgrades.cpp 中CurrentEpoch()根据当前区块高度遍历所有升级返回当前所处的一致性时代int CurrentEpoch(int nHeight, const Consensus::Params params) { for (auto idxInt Consensus::MAX_NETWORK_UPGRADES - 1; idxInt Consensus::BASE_SPROUT; idxInt--) { if (params.NetworkUpgradeActive(nHeight, Consensus::UpgradeIndex(idxInt))) { return idxInt; } } // Base case return Consensus::BASE_SPROUT; }IsActivationHeight()upgrades.cpp则精确判断某个高度是否为某一升级的激活高度其核心就是nHeight params.vUpgrades[idx].nActivationHeight。从源码结构可以看到Overwinter 之后还有 Sapling419200、Blossom653600等后续升级这正体现了 Zcash 以固定激活高度驱动网络升级的设计模式。升级注意事项对于运行 zcashd 节点的用户来说主网高度 347500预计 2018 年 6 月 25 日左右出块意味着必须升级到 1.1.0 或之后的版本否则在 Overwinter 激活后将无法跟上主链升级后节点的协议版本将随时代切换而提升Overwinter 对应协议版本 170005交易过期机制的引入意味着钱包需要处理交易过期状态旧版本钱包产生的交易在升级后可能被新规则拒绝。-mempooltxinputlimit的弃用从应急补丁到功成身退选项的由来二次哈希性能问题-mempooltxinputlimit在 1.0.10 版本中引入其背景是 Zcash 从 Bitcoin 继承而来的二次哈希问题quadratic hashing当矿工构造区块时对包含大量透明输入transparent inputs的交易进行哈希验证的代价随输入数量呈平方级增长导致矿工挖矿性能受损。该选项通过限制进入内存池mempool的交易的最大透明输入数量来缓解这个问题。这一历史功能在 release-notes-1.0.10.md 中有明确记载Add option mempooltxinputlimit so the mempool can reject a transaction based on the number of transparent inputs. Check mempooltxinputlimit when creating a transaction to avoid local mempool rejection.同时钱包侧的z_shieldcoinbaseRPC 调用也引用该选项当limit参数设为 0 时将使用-mempooltxinputlimit的默认值50来限制一次屏蔽的 coinbase UTXO 数量参见 payment-api.md 与 shield-coinbase.md 的说明。为什么可以弃用随着 Bitcoin Core 代码库中多项性能优化被合并进 Zcash二次哈希问题得到了显著缓解。更重要的是Overwinter 升级本身包含了解决该问题的方案升级后一笔 1000 个输入的交易其验证耗时将与 10 笔各 100 个输入的交易相当——验证成本不再随输入数量呈平方级增长。因此这个应急性质的限制参数已经失去存在价值。过渡期的行为约定本版本1.1.0明确约定在 Overwinter 激活高度347500之前-mempooltxinputlimit继续强制生效Overwinter 激活之后该选项将被忽略未来版本将在 Overwinter 激活后彻底移除该选项。对应提交 Ignore -mempooltxinputlimit once Overwinter activates 正是这一逻辑的落地。事实上后续在 2.1.1 版本中该选项被正式移除见 release-notes-2.1.1.md 中的 Remove option mempooltxinputlimit。对于运维人员的操作建议如果你此前依赖-mempooltxinputlimit来防御大输入交易应确认 Overwinter 激活后的节点行为——该参数将自动失效但同时二次哈希问题已被根治无需再配置其他替代参数。NODE_BLOOM服务位P2P 协议能力的显式宣告BIP 111 的背景BIP 111参见 bips.md 中关于 BIP111 的更新记录定义了一个服务位service bit让节点能够显式地通告自己支持 Bloom 过滤器Bloom filters——这是 SPV 轻客户端常用的交易过滤机制。在此之前节点是否支持 Bloom 过滤是隐式的这给协议演进带来了困扰。BIP 111 同时提升了协议版本使新节点能够识别那些虽然允许 Bloom 过滤但没有宣告新服务位的旧节点。源码实现在 protocol.h 中定义了服务位常量// NODE_BLOOM means the node is capable and willing to handle bloom-filtered connections. NODE_BLOOM (1 2),在 init.cpp 中节点是否声明该服务位由-peerbloomfilters配置项控制if (GetBoolArg(-peerbloomfilters, DEFAULT_PEERBLOOMFILTERS)) nLocalServices | NODE_BLOOM;默认值定义在 main.hstatic const bool DEFAULT_PEERBLOOMFILTERS true; static const bool DEFAULT_ENFORCENODEBLOOM false;版本门槛170004 与 NO_BLOOM_VERSION本版本对NODE_BLOOM的执行策略是仅对发送协议版本170004的对等节点强制检查。version.h 中定义了该门槛常量//! filter* commands are disabled without NODE_BLOOM after and including this version static const int NO_BLOOM_VERSION 170004;在 main.cpp 中当本地节点未开启NODE_BLOOM时对filterload/filteradd命令的处理逻辑为else if (!(nLocalServices NODE_BLOOM) (strCommand filterload || strCommand filteradd)) { if (pfrom-nVersion NO_BLOOM_VERSION) { LOCK(cs_main); Misbehaving(pfrom-GetId(), 100); return false; } else if (GetBoolArg(-enforcenodebloom, DEFAULT_ENFORCENODEBLOOM)) { pfrom-fDisconnect true; return false; } }这里体现了两种保护层级对于协议版本170004的节点未声明NODE_BLOOM却发送过滤命令会被视为违规行为Misbehaving增加违规分数 100对于更旧的节点仅在显式开启-enforcenodebloom时才断开连接属于可选的宽松策略。与此同时本地节点自身若声明了NODE_BLOOM默认-peerbloomfilters1则 main.cpp 中正常的filterload处理流程会加载 Bloom 过滤器并开启交易中继pfrom-fRelayTxes true。SPV 客户端的适配建议官方在版本说明中给出的建议是SPV 客户端应检查节点报告的协议版本——对于版本 170004 及以上的节点必须验证其是否声明了NODE_BLOOM服务位再决定是否建立 Bloom 过滤连接。下一大版本将移除仅对 170004 强制这一过渡性限制届时所有版本的节点都需严格遵守该服务位约定。版本演进中的其他亮点1.1.0 还包含若干值得关注的基础设施改进可从 Changelog 部分梳理Rust 构建链硬化depends: Explicitly download and vendor Rust dependencies、Make Rust compilation mandatory即 Rust 依赖被显式下载并 vendor 化且 Rust 编译成为强制步骤——这为后续 Zcash 将更多密码学组件迁移到 Rust 奠定了构建基础依赖版本升级Boost 升级到 1.66.0、OpenSSL 升级到 1.1.0h并移除了 Boost 库的-mt后缀对应多次Remove -mt suffix提交Merkle 树与序列化优化Optimise serialization of MerklePath、使用uint64_t替代size_t作为序列化索引类型消除了std::vectorbool的歧义提升了跨平台一致性内存池与交易过期过期交易不再增加对等节点的违规分数Set ban score for expired txs to 0并记录移除过期交易时的 txid 日志RPC 新增z_listunspent由 Simon Liu 实现Closes #2910. Add z_listunspent RPC call用于列出钱包持有的未花费 notez_listreceivedbyaddress增强返回 JoinSplit 与 JoinSplitOutput 的索引dbwrapper 重构leveldbwrapper文件更名为dbwrapper.*CLevelDB*系列类名重命名并补充了迭代器相关测试构建与测试工具链新增用于启用 ASan/UBSan 与 TSan 的 configure 参数、支持通过环境变量在zcutil/build.sh中传入 configure 标志以及自动化回归auto-senescence通知改进。这些改动大多可在仓库源码中得到印证例如 dbwrapper 相关文件已按重构后的命名存在于 dbwrapper.cpp、dbwrapper.hz_listunspent等 RPC 的测试则散见于 qa/rpc-tests 目录下的钱包相关测试脚本中。总结Zcash 1.1.0 是一次承上启下的版本它敲定了 Overwinter 主网激活高度让网络第一次完成有规划的硬分叉升级它通过 Overwinter 内置的二次哈希解决方案正式启动了-mempooltxinputlimit的弃用流程它按照 BIP 111 引入NODE_BLOOM服务位为 P2P 层的 Bloom 过滤能力提供了显式、可协商的协议基础。同时Rust 强制编译、依赖升级、dbwrapper 重构等工程化改进也为后续 Sapling 及更远期升级铺平了道路。对于开发者与节点运营者本版本的三个关键词可以概括为升级到 1.1.0否则无法跟随 Overwinter 主网、理解-mempooltxinputlimit的过渡期行为激活前生效、激活后失效、适配NODE_BLOOM服务位检查SPV 客户端需按 170004 协议版本门槛校验。相关实现细节可继续深入 src/chainparams.cpp、src/consensus/upgrades.cpp、src/main.cpp 与 src/init.cpp 等源码文件查阅。【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考