- 区块链
【免费下载链接】parity-ethereum
The fast, light, and robust client for Ethereum-like networks.
本文基于 docs/CHANGELOG-2.0.md（Parity-Ethereum 2.0 系列完整变更日志）整理。该文档记录了 Parity 客户端在 2018 年 7 月至 10 月间的 2.0.0 → 2.0.9 共 10 个版本的关键演进：客户端更名、Parity Wallet 与 DApps 子系统移除、EIP 系列（145/1014/1052/1234/1283）与 Constantinople 硬分叉支持、交易队列（Transaction Queue）重构、Warp 同步与快照机制改进等。结合当前仓库源码（ethcore/res/ethereum/foundation.json、parity/cli/mod.rs、ethcore/engines/authority-round/src/lib.rs 等）进行深度佐证，帮助开发者理解 2.0 系列的技术脉络、升级注意事项与关键配置参数。
EOL 提示：Parity Ethereum 2.0 已于2018-11-15达到 End-of-Life（EOL），本文内容属于历史版本技术存档，仅供理解当时的设计决策与升级路径使用。
一、2.0 大版本的背景：一次"减负式"架构重构
1.1 客户端更名：从 Parity 到 Parity-Ethereum
v2.0.0 的首要变化是命名：客户端正式更名为Parity-Ethereum，以区别于同一团队推出的 Parity-Bitcoin、Parity-Polkadot 等其他软件（PR #9052 的构建脚本与 parity 主程序目录均以 parity-ethereum 为基准组织。
1.2 大范围功能裁减：Wallet、DApps、安装包、校验方式全面调整
2.0.0 是一次"主动瘦身"的破坏性版本，文档明确列出以下 breaking changes，升级前必须逐条核对：
| 变更项 | 说明 | 对应 PR |
|---|---|---|
| 移除公共节点（Public Node）与用户界面（Parity Wallet） | 钱包与 UI 从客户端中完全移除，如需继续使用请使用独立的 Parity-JS/shell 桌面应用 | #8758、#8783、#8641 |
| DApps 子系统完全移除 | 客户端不再内置 DApps 托管与注入逻辑，相关权限设置也一并删除 | #9017、#9107 |
| Windows / macOS 不再提供安装包与系统托盘 | 只能从镜像获取二进制；macOS 用户建议使用 homebrew tap | #8778 |
| Linux 不再提供 deb / rpm 包 | 由社区自行打包维护（如 Arch Linux 社区包） | #8887 |
| MD5 校验和全面替换为 SHA256 | 官网与发布物均使用 SHA256 | #8884 |
废弃 CLI 参数从--help中隐藏 | 旧参数仍可用但不再显示，以抑制继续使用 | #8967 |
从源码结构可以印证 DApps 移除的结果：当前仓库的 RPC 层（rpc/src/v1）已没有任何 dapps 相关的 RPC 模块，AccountProvider中也取消了按 dapps 策略返回账户的逻辑——正如 v2.1.0 文档所述，"JSON-RPC 中所有可用账户都会被返回，与请求来源无关"。
1.3 库化与 C 接口：Parity-Ethereum 作为库
v2.0.0 的另一重要变化是Parity-Ethereum 作为库（library）提供 API，可用于运行全节点与轻节点，并提供一个C 接口（#8412 即暴露了 ethcore 的公共 API，而 evmbin 等工具则展示了如何将核心组件作为库复用来构建独立二进制。
二、Constantinople 硬分叉支持：2.0.7 / 2.0.8 的核心主线
2.1 分叉时间表与强制升级要求
v2.0.7（2018-10-11）宣布引入Constantinople支持，文档给出的分叉计划为：
- Ropsten 测试网：区块
4_230_000（2018-10-14，Constantinople） - POA Core 主网：区块
5_329_160（2018-10-22，CORE HF 2） - Kovan 测试网：区块
9_200_000（2018-10-25，Constantinople + KIP-{4,6}）
文档明确：运行上述任一网络的节点，升级到 2.0.7 或 2.1.2 是强制性的。而 v2.0.8（2018-10-16）则是一个修复 Constantinople 共识问题的关键安全版本——文档特别强调："无论你连接的是哪个计划启用 EIP-1283 的网络（如 Ropsten、Kovan、Ethereum），都必须升级"。这正是因为 v2.0.8 引入了EIP-1283 的 SSTORE 净 Gas 计量修复（见下文）。
2.2 Constantinople 涉及的 EIP 清单与源码印证
文档列出了 2.0.7 中为 Constantinople 实现的 EIP 系列，逐一对应源码如下：
| EIP | 内容 | 仓库中的落地位置 |
|---|---|---|
| EIP-1234 | 推迟难度炸弹 + 区块奖励降至 2 ETH | ethcore/engines/ethash/src/lib.rs |
| EIP-1052 | EXTCODEHASH操作码 | ethcore/machine/src/executive.rs（EXTCODEHASH 执行） |
| EIP-1014 | CREATE2操作码（含 transition 配置标志） | ethcore/evm/src（CREATE2 解释执行） |
| EIP-145 | EVM 位位移指令（SHL/SHR/SAR） | ethcore/evm/src/instructions.rs |
| EIP-1283 | SSTORE 净 Gas 计量（不依赖 dirty maps 的实现） | ethcore/machine/src/externalities.rs（sstore_clears_refund等） |
| KIP-4 / KIP-6 | WASM 运行时支持create2与gasleft | ethcore/wasm/src/runtime.rs |
以主网链规约 ethcore/res/ethereum/foundation.json 为例，可以直观看到 Constantinople 在链规约中的表达方式：
{ "name": "Ethereum", "engine": { "Ethash": { "params": { "blockReward": { "0x0": "0x4563918244f40000", "0x42ae50": "0x29a2241af62c0000", "0x6f1580": "0x1bc16d674ec80000" }, "difficultyBombDelays": { "0x42ae50": "0x2dc6c0", "0x6f1580": "0x1e8480", "0x8c6180": "0x3d0900" } } } }, "params": { "eip145Transition": "0x6f1580", "eip1014Transition": "0x6f1580", "eip1052Transition": "0x6f1580", "eip1283Transition": "0x0" } }解读这段配置：
0x6f1580=7_280_000，正是以太坊主网 Constantinople 激活区块号；blockReward采用按区块号映射的多值结构：0x0（5 ETH）→0x42ae50（Byzantium，3 ETH）→0x6f1580（Constantinople，2 ETH），这正是文档所说"Allow zero chain id in EIP155 signing process"时期同步引入的multi blockReward设计；difficultyBombDelays同样是多值映射，对应 EIP-1234 对难度炸弹的阶段性延迟；- 测试链规约 ethcore/res/ethereum/constantinople_test.json 中，上述四个 EIP 的 transition 全部为
0x0（即创世即启用），用于在测试环境全量开启 Constantinople 特性。
2.3 EIP-1283 的共识修复与 signed sstore refund（2.0.8）
v2.0.8 的关键修复是"Use signed 256-bit integer for sstore gas refund substate"（PR #9746）。EIP-1283 的净 Gas 计量引入了一个共识层面极易出错的点：SSTORE 的退款（refund）累计值可能为负，若使用无符号整数表示会造成溢出并导致区块状态不一致。改用 signed 256-bit 整数后，退款子状态能够正确表达"净退款为负"的场景，从而修复了 Constantinople 早期实现中的共识问题——这就是文档强调"升级是强制性的"的根本原因。
三、交易队列（Transaction Queue）重构：升级 1.x 用户的必读
文档专门为"从 1.10.9 及更早版本直接升级"的用户列出了交易队列实现的重要变化：
3.1 按发送者限流（per-sender limit）
- 交易池现在限制每个发送者的交易数量，对应 CLI 参数
--tx-queue-per-sender； - 本地交易也必须遵守该限制。文档建议：在做基准测试或需要一次性发送大量交易时，通过 CLI 提高该限制。
CLI 定义位于 parity/cli/mod.rs：
--tx-queue-per-sender=[LIMIT] Maximum number of transactions per sender in the queue. By default it's 1% of the entire queue, but not less than 16.即默认值为整池大小的 1%，下限 16 笔。
3.2 池满时的优先级变化
文档提醒第二个行为变化：
若交易池已满，从网络收到的、但发起账户是你持有私钥的交易，不再自动获得更高优先级进入池中。
应对方案有两种：
- 运行更大的池（
--tx-queue-size，默认8192，见 parity/cli/mod.rs）； - 直接通过节点的
eth_sendRawTransaction提交交易（本地路径仍享有优先）。
3.3 相关的交易队列参数总览
结合 parity/cli/mod.rs 与配置文件 parity/cli/tests/config.full.toml，2.0 系列交易队列相关的核心参数如下：
| 参数 | 默认值 | 说明 |
|---|---|---|
--tx-queue-size=[LIMIT] | 8192 | 队列中等待被打包的交易数量上限 |
--tx-queue-per-sender=[LIMIT] | 队列的 1%（≥16） | 每个发送者的交易数上限 |
--tx-queue-strategy=[S] | gas_price | 交易排序策略（按 gas 价格优先） |
--tx-queue-no-early-reject | false | 禁用"低于最低有效 gas 价即提前拒绝"的优化，允许本地交易在池满时仍可入池，但代价是每笔交易都需要额外的 ecrecover |
--tx-queue-mem-limit=[MB] | — | 交易队列内存上限，0表示不限制 |
--tx-queue-no-unfamiliar-locals | false | 通过 JSON-RPC（HTTP/WebSocket）发送的本地交易，若发送账户未知则视为"外部"交易 |
其中--tx-queue-no-early-reject是 v2.0.0 时期新增（PR #9143），配合"本地交易不丢弃、不同发送者的本地交易永不丢弃"（#9002）等策略，共同构成了 2.0 系列更精细的本地交易保护机制。
3.4 其他交易相关改进
v2.0.0 还包含一批交易处理相关的优化，文档均有提及：
- 允许 EIP-155 签名过程中 chain id 为 0（v2.0.9，PR #9792）；
- 事务 RLP 大小超限（300 kB）返回错误而不是静默处理（#8473）；
- "最近被拒绝"缓存用于交易队列（recently rejected cache，#9005）；
- 交易传播窗口扩展为未来 4 个区块，并移除每包最多 64 笔交易的限制，改为按 8MB 包大小控制（v2.0.3，#9265）。
四、Gas 目标与上限默认值调整（2.0.5 起）
v2.0.5 起，文档明确两项默认值变更：
- 默认
gas_floor_target提高到8_000_000- 默认
gas_cap提高到10_000_000
在 parity/cli/mod.rs 中可以看到对应定义：
ARG arg_gas_floor_target: (String) = "8000000" ARG arg_gas_cap: (String) = "10000000"这两个参数分别控制区块的 gas 下限目标（矿工尽力将区块填充至该水位）与单区块 gas 上限（打包交易时的硬性上限），2.0.5 将其整体抬升以适配当时不断增长的网络需求（PR #9564）。
五、Warp 同步（快照同步）机制的增强
2.0 系列对 Warp sync（基于快照的快速同步）做了多项实质性改进，文档列举如下：
5.1 可恢复（resumable）Warp 同步
v2.0.0 引入：Warp 同步可恢复——客户端重启后，已下载的快照分块（chunks）会保留，无需从头开始；同时，节点会将自己已下载的快照分享给其他节点（seeding）（#8544）。
5.2 强制 Warp 屏障：--warp-barrier
v2.0.0 新增--warp-barrier [blocknumber]标志，用于强制只进行 warp 同步（#8228）。CLI 帮助文本（parity/cli/mod.rs）描述为：
--warp-barrier=[NUM] When warp enabled never attempt regular sync before warping to block NUM.即：启用后，节点在 warp 到指定区块之前绝不尝试常规同步。在 parity/configuration.rs 中，该参数被直接透传至网络配置：
warp_barrier: self.args.arg_warp_barrier,5.3 随机抓取快照分块的修复
v2.0.0 修复了 "Don't fetch snapshot chunks at random"（#9088（快照的 chunk 写入与读取、进度跟踪均在service.rs、io.rs中）。
六、多线程快照创建：--snapshot-threads（2.1 系列前瞻）
虽然--snapshot-threads的正式发布说明出现在 v2.1.0 的变更日志中，但其源码实现与本 2.0 系列共享同一代码路径（PR #9239），且在 2.0.x 维护周期内已并入主线，值得一并说明：
- 默认线程数：物理 CPU 核数的一半（下限 1）；
- CLI 参数：
--snapshot-threads=[NUM]，帮助文本为 "Enables multiple threads for snapshots creation."（parity/cli/mod.rs）； - 配置结构：
SnapshotConfiguration.processing_threads，默认实现见 ethcore/snapshot/src/lib.rs：
pub struct SnapshotConfiguration { /// If `true`, no periodic snapshots will be created pub no_periodic: bool, /// Number of threads for creating snapshots pub processing_threads: usize, } impl Default for SnapshotConfiguration { fn default() -> Self { SnapshotConfiguration { no_periodic: false, processing_threads: ::std::cmp::max(1, num_cpus::get_physical() / 2), } } }- 执行逻辑：
take_snapshot中线程数被限制在1..=SNAPSHOT_SUBPARTS之间，状态分区（state subparts）按thread_idx..SNAPSHOT_SUBPARTS.step_by(num_threads)的方式分摊给各 worker 线程并行分块（ethcore/snapshot/src/lib.rs）。相关配置在 parity/configuration.rs 中接入 CLI。
七、PoA / Aura 引擎相关修复
7.1 空步骤（empty steps）相关（2.0.x 维护期）
v2.0.4 修复了"在启用 empty steps 的 PoA 网络中，不报告跳过的 primaries"（#9435）；v2.0.1 则为 Aura 难度验证增加了更宽松的处理（"Be more graceful on Aura difficulty validation"，#9164），并附带了rejects_step_backwards、proposer_switching、rejects_future_block、reports_skipped、verify_empty_seal_steps等一组测试。
注：完整的strict empty steps严格校验（拒绝重复/乱序的空步骤）在 v2.1.10 中才作为
strict_empty_steps_transition正式启用，但其核心验证逻辑（按步骤号升序、去重、parent_hash 与签名校验）已沉淀在 ethcore/engines/authority-round/src/lib.rs，并配有should_reject_duplicate_empty_steps、should_reject_unordered_empty_steps等回归测试。
7.2 区块奖励合约（block reward contract）
v2.0.0 支持了链上合约计算区块奖励（#8419 等合约资源与 ethcore/machine/src 中的区块奖励应用逻辑（block_reward相关代码）即为佐证。v2.1.x 进一步将其泛化为blockReward多值配置与blockRewardContractCode（#9480），允许链直接内嵌奖励合约字节码而无需维护内置多值方案。
八、轻客户端（Light Client）与 RPC 改进
8.1 eth_coinbase 行为修正
v2.0.4 修复：eth_coinbase现在为轻客户端提供真实账户（此前固定返回零地址）（#9383）。同时统一了全节点与轻节点的错误处理：全节点在无账户时返回错误而非零地址。注意 v2.1.0 文档特别提醒：轻客户端与全客户端在此行为上仍存在差异——轻客户端在找不到账户时返回0x0地址，而全客户端返回错误。
8.2 轻模式下的 eth_getLogs 支持
v2.0.3 为轻客户端增强了eth_getLogs（#9186（on_demand 请求与 provider 逻辑）。
8.3 eth_getWork 的同步状态检查
v2.0.3 起，eth_getWork在节点未同步完成时返回错误（#9193 / #9210），避免矿工在未同步状态下获取无效工作；v2.0.4 进一步将其限定为warp 同步中也返回错误（"Only check warp syncing for eth_getWork"，#9484）。
8.4 其他 RPC 相关
net_version缓存 network_id，避免重复获取同步读锁（v2.0.5，#9544）；net_peerCount使用小写十六进制格式输出（同 PR）；- RPC 请求大小上限可配置（"Add option for user to set max size limit for RPC requests"，#9010）；
- 本地调用（local calls）的 gas 上限被限制（#8943）；
- 交易哈希补全到
trace_replayBlockTransactions结果（#8883）； - 区块 0 在查询中被视为合法（"Block 0 is valid in queries"，#8891）。
九、网络与 P2P 层的稳健性改进
v2.0.x 在 P2P 层投入了大量稳定性工作，文档重点提及：
9.1 发现协议（Discovery）优化
v2.0.5 的 "Improve P2P discovery"（#9526）包含一系列关键调整：
- 主同步期间不移除 discovery peer；
- 更频繁地刷新发现表，节点不足时提高发现频率；
- 提前启动首次发现；
- 新增 PingPong 回合并校验 pong 包的 echo hash；
- FindNode 请求跟踪超时，对失败的 ping 采用指数退避重试（指数退避逻辑在 v2.0.0 的 PR #8771 中已实现）；
- 只有收到 pong 后才把节点加入路由表——这是对"未确认端点存活即入表"问题的直接修复。
相关代码位于 util/network-devp2p/src（UDP 发现、节点表排序）与 util/network/src。
9.2 分叉与同步问题修复
- 修复与分叉区块之后链上节点的连接问题（#8710）；
- 允许从难度低于本地同步难度的 peer 下载旧区块（v2.0.3，#9226）；
- 防止导入队列满时重启同步（#9381）；
- 修复 Kademlia XOR 距离计算错误（#8589）；
- 处理 UselessPeer 断连（#8686）；
- 同步响应与请求的对应校验（"Verify block syncing responses against requests"，v2.1.2 同步回 2.0.x，#9670）。
十、发行与分发（Distribution）相关变更
v2.0.7 的发布说明列出以下二进制分发层面的弃用，对运维部署有直接影响：
arm*目标不再由 parity 提供二进制，请考虑自行（交叉）编译；i*86目标不再提供二进制，请考虑升级操作系统；- Snapcraft 不再维护，请直接使用二进制或发行版仓库。
此外，v2.0.0 起：
- Windows/macOS 安装器与系统托盘被移除（#8778）；
- Linux deb/rpm 打包脚本删除（#8887）；
- 发布物校验从 MD5 切换为 SHA256（#8884）。
Docker 方面，v2.0.0 起 Dockerfile 统一更名路径为 parity-ethereum（#9248 下保留有 alpine/centos/ubuntu 等多个目标的 Dockerfile）。
十一、2.0 系列版本一览表
| 版本 | 日期 | 性质 | 核心内容 |
|---|---|---|---|
| v2.0.0 "Ethereum" | 2018-07-18 | beta | 客户端更名 Parity-Ethereum；移除 Wallet/DApps/UI；库化与 C 接口；交易队列重构；Warp 同步可恢复；--warp-barrier；EIP150/160/161 移入公共参数 |
| v2.0.1 | 2018-07-27 | beta | Aura 难度验证宽松化；移除 node-health；修复 UserDefaults 解析；禁用本地交易 per-sender 限制 |
| v2.0.3 | 2018-09-01 | beta | 移除 dapp 权限设置；eth_getWork 同步检查；轻客户端 eth_getLogs 增强；交易传播 4 块窗口 |
| v2.0.4 | 2018-09-11 | beta | 轻客户端 eth_coinbase 真实账户；修复 Windows 快照恢复；warp 同步中的 eth_getWork 检查 |
| v2.0.5 | 2018-09-18 | stable | 2.0 系列标记稳定；P2P 发现优化；gas_floor_target→8M、gas_cap→10M；WS 端口低危问题 |
| v2.0.6 | 2018-09-20 | stable | 无功能变更（纯版本回退合并） |
| v2.0.7 | 2018-10-11 | stable | 引入 Constantinople（EIP-1234/1052/1014/145/1283）；arm/i*86/Snapcraft 分发弃用 |
| v2.0.8 | 2018-10-16 | stable | 关键安全版本：修复 EIP-1283 SSTORE 退款共识问题（signed 256-bit） |
| v2.0.9 | 2018-10-29 | stable | 性能与稳定性修复；允许 EIP-155 chain id 为 0；ropsten 分叉检查点更新 |
十二、升级注意事项速查（面向 2.0 用户）
综合全文，向 2.0.x 用户给出以下升级要点：
- 运行 Ropsten / POA Core / Kovan 的节点：至少升级到2.0.7；运行计划启用 EIP-1283 的任意网络，必须升级到 2.0.8（共识级修复）。
- 1.10.9 及更早版本直接升级：务必阅读交易队列变化——per-sender 限制、本地交易优先级调整，必要时调大
--tx-queue-per-sender或--tx-queue-size，或改用eth_sendRawTransaction提交。 - 自定义链规约需迁移：EIP150/EIP160/EIP161 分叉配置从 Ethash 参数段迁入common params 段（#8614）；主网规约 foundation.json 是迁移后的标准范例。
- 依赖 Wallet/DApps 的工作流：2.0.0 起必须改用独立钱包应用，客户端本身不再提供 UI 与 DApps 托管。
- 校验下载物：2.0.0 起使用 SHA256 而非 MD5。
- 架构升级：
arm*、i*86、Snapcraft 分发已弃用，请改用官方二进制、发行版仓库或自行编译（可参考仓库构建说明）。
结语
Parity-Ethereum 2.0 系列是项目历史上的一个关键转折：它用一次大规模"减负"（移除 UI/DApps/公共节点）换来更纯粹的客户端定位，同时完成了 Constantinople 硬分叉的完整支持与交易队列、同步机制、快照机制的深度重构。透过 docs/CHANGELOG-2.0.md 的逐版本记录，再结合当前仓库的链规约与 CLI 定义，可以清晰地还原当时每个设计决策背后的动机——这些历史版本虽然已 EOL，但其沉淀的架构思路（如 multi blockReward、strict empty steps、resumable warp sync）至今仍可在仓库源码中检索研读。
- 区块链
【免费下载链接】parity-ethereum
The fast, light, and robust client for Ethereum-like networks.
相关推荐
Moshi 2.x 迁移升级指南：从 1.x 到 2.0 的破坏性变更、值类支持与版本演进全解析
Moshi 2.x 迁移升级指南：从 1.x 到 2.0 的破坏性变更、值类支持与版本演进全解析 Moshi 是 Square 出品的现代 JSON 库，同时面
序列化深入解读 Vault 系列版本演进：从 2.0 大版本到 1.16 的 CHANGELOG 全透视
深入解读 Vault 系列版本演进：从 2.0 大版本到 1.16 的 CHANGELOG 全透视 导读 HashiCorp Vault 是一款面向机密管理、加
后端密钥管理认证鉴权身份认证应用安全NLog 6.x 版本演进与核心改进全解析：从 AOT 支持到高性能日志架构
NLog 6.x 版本演进与核心改进全解析：从 AOT 支持到高性能日志架构 本文以仓库根目录 CHANGELOG.md https://link.gitcod
后端运维观测
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
