v3.17.0

安全与稳定性加固

本版本为安全加固版本，结合第三方安全审计结果，对核心模块进行了系统性加固：

  • 交易池：交易提交与验证路径的并发安全和对象生命周期修复；nonce 校验逻辑加固；交易准入检查强化（含拒绝 to 字段非法的交易）；交易哈希校验强化

  • 共识（PBFT / rPBFT / Sealer）：共识消息签名与权限校验强化；消息解码边界检查；视图切换与分叉处理加固；资源用量上限与去重防护

  • 网关与 P2P：网络消息解码边界校验；TLS 会话生命周期修复；优化大规模连接建立/断开场景下可能影响共识出块的多个问题

  • 执行器与调度器：gas 计量与错误路径处理修正；合约部署权限检查加固；执行调度的并发与提交原子性修复

  • 区块同步 / 选主 / 基础组件：同步请求限容；etcd 选主的异常恢复与校验；压缩数据解压上限防护

  • Web3 兼容性：EOA nonce 与块内交易顺序解耦

相关修复的完整列表见 GitHub Release 与代码仓库 ChangeLog.md。

版本功能变更说明

自 v3.17.0 起，以下功能将有变更，请使用相关功能的用户提前规划迁移。下文中「移除」指自 v3.18.0 起相关编译选项与功能代码不再随版本发布；「不再维护」指相关代码仍保留在版本中，但不再进行适配、优化与问题修复：

  • WASM / WBC-Liquid 合约执行：WITH_WASM 编译选项及 WBC-Liquid 合约的部署与执行支持将在 v3.18.0 中移除；Solidity / EVM 合约不受影响

  • 网关 Redis 分布式限流：节点配置 config.ini 中 [flow_control] 配置节的 enable_distributed_ratelimit、enable_distributed_ratelimit_cache、distributed_ratelimit_cache_percent 配置项及 [redis] 配置节将在 v3.18.0 中移除；节点本地限流（令牌桶）能力保持不变

  • 轻节点（Light Node）：WITH_LIGHTNODE 编译选项及轻节点功能将在 v3.18.0 中移除

  • TiKV 存储：将移除 WITH_TIKV 编译选项，TiKV 分布式存储自 v3.18.0 起不再维护；RocksDB 存储保持不变

  • Max 版本部署形态：经过长期的生产实践、性能分析及版本迭代后，当前 Air 版本能以更低的机器与运维成本提供不低于 Max 版本的性能与完整的功能，故 Max 版本（BcosMaxNodeService、BcosExecutorService 等微服务部署形态）自 v3.18.0 起不再维护；Air / Pro 版本保持不变，新部署建议使用 Air 版本。详细说明与迁移方案见下节

关于 Max 版本不再维护的说明

Max 版本是 FISCO BCOS v3.0 发布时主推的部署形态之一：将节点拆分为网关、RPC、共识/调度、执行、存储（TiKV）等独立微服务，期望通过存算分离与水平扩容支撑更大规模的业务。经过多个版本的实践与性能分析，我们确认这一架构的实际收益与其成本不匹配，决定不再维护。主要依据如下：

性能上限没有提高，反而更低。 区块链节点是强耦合系统：每个区块的处理都要经过共识、执行、落盘的同步交互，交易执行期间对合约状态的每次读写都要访问存储。Max 将这些进程内的函数调用拆成跨服务的网络 RPC，每次交互都增加了序列化与网络往返开销——执行与存储分离后，状态读写延迟从内存/本地磁盘量级上升到网络量级，直接拉低了单链吞吐上限。而共识本身要求所有节点全序执行同一批交易，拆分服务并不能把这条串行路径并行化。因此，将进程内交互拆分为跨服务调用，并不能提高单链的吞吐上限。

机器成本明显更高。 一个 Max 节点的最小部署包括多个 Tars 服务实例加上 TiKV/PD 集群，占用多台机器；Air 节点是单个进程。达到同等吞吐，Max 需要的硬件资源数倍于 Air。

运维成本明显更高。 Max 部署需要维护 Tars 框架与 TiKV 两套基础设施，多个服务组件需要版本对齐、独立监控与扩缩容，故障定位需要跨服务追踪；任一服务或中间件故障都会影响出块，故障面远大于单进程。

业界对微服务架构的反思与此一致。 近年来多个大型工程团队公开回归单体架构：Amazon Prime Video 团队（2023）将音视频监控服务从分布式微服务/Serverless 架构改回单体进程，成本下降约 90%；Google 的 Service Weaver 论文（Towards Modern Development of Cloud Applications，HotOS 2023）指出按微服务边界拆分部署带来性能与正确性成本，主张以模块化单体开发、按需部署；Segment（2018）也曾公开其从微服务回迁单体的实践。业界共识是：微服务解决的是组织扩展性问题（多团队独立开发、独立发布），而不是性能问题。区块链节点由单一团队交付、模块间强耦合、必须整体升级（共识要求所有节点行为一致），不具备从微服务拆分中获益的前提条件。

综上，Air 版本以更低的机器与运维成本提供了不低于 Max 的性能与完整的功能，可以完全替代 Max。

存量 Max 部署的迁移方案：通过区块同步逐步迁移。在现有链中加入 Air 版本节点（先作为观察节点），Air 节点从创世块开始同步并重放区块，数据追平最新块高后，将其加入共识委员会，再逐个下线原 Max 节点；重复该过程直至全部替换完成，迁移过程中链持续正常出块，无需停链。具体操作（添加观察节点、节点角色变更）参见节点管理文档。若在迁移中遇到问题，可通过社区渠道（GitHub Issue、微信群）获取支持。

兼容性说明

兼容版本

需要升级的链的“数据兼容版本号（compatibility_version）”为如下版本时：

  • 3.4.x ~ 3.16.x：数据完全兼容当前版本，直接替换二进制即可完成升级

  • 3.3.x、3.2.x、3.1.x、3.0.x：支持通过替换二进制进行灰度升级，若需使用当前版本的新特性，需升级数据兼容版本号，操作见版本升级指南

  • 3.0-rc x：数据不兼容，无法升级，可考虑逐步将业务迁移至3.x正式版

  • 2.x：数据不兼容，2.x版本仍持续维护，可考虑升级为2.x的最新版本

重要

本版本包含随数据兼容版本号（compatibility_version）3.17.0 启用的共识协议变更与 bugfix 开关。必须待全网所有节点完成二进制替换并重启后，再将 compatibility_version 提升至 3.17.0；提升后链即按新逻辑运行，不支持回退到旧版本二进制混跑。

本版本新增的 bugfix 开关

以下开关随 compatibility_version 升级至 3.17.0 自动开启，从低版本升级且未提升版本号时保持关闭，与旧版本行为一致：

Bugfix 开关 说明
bugfix_auth_check 合约部署与调用的权限检查加固
bugfix_v1_error_handling 执行器错误路径的 gas 计量与状态返回修正
bugfix_gas_payment_balance_precheck 交易执行前的余额预检查
bugfix_precompiled_feature_gate 预编译合约按 feature 开关门控
bugfix_evm_storage_status EVM 存储操作状态返回值修正
bugfix_statestorage_hash_v3_17 状态存储哈希计算修正
bugfix_nonce_ordering Web3 EOA nonce 与块内交易顺序解耦

实验功能

v3.17.0 未新增实验功能。本节说明实验功能开关的通用操作方式；各版本已有的 feature 开关及其默认状态，见 feature and bugfix list。

效果：通过feature开关控制实验功能的开启

操作：升级节点可执行程序后，通过控制台命令setSystemConfigByKey <feature名> 1 开启对应实验功能，具体操作见文档升级方法部分

注意事项：

  • feature操作不可逆，打开后不可关闭

  • 需确认所有可执行程序版本相同后，再进行feature开启操作

组件兼容性

各组件（控制台、SDK、WeBASE 等）的推荐版本与最低版本，以 兼容性说明文档 为准。

升级方法

该操作仅支持将3.x版本升级为本版本，不支持3.0-rc或2.x的升级。

查询数据兼容版本号（compatibility_version）

用控制台 进行查询，如当前返回的版本为3.16.0

[group0]: /apps>  getSystemConfigByKey compatibility_version
3.16.0
替换节点二进制

需将所有节点 的二进制逐步替换为当前版本。为了不影响业务，替换过程能够以灰度方式进行，逐个替换并重启节点。替换过程中，当前的链仍然会以旧的数据兼容版本号的逻辑继续执行。当所有节点二进制替换完成并重启后，需用控制台修改数据兼容版本号为当前版本。

设置数据兼容版本号（compatibility_version）

用控制台 设置数据兼容版本号，如当前版本为3.17.0。

[group0]: /apps>  setSystemConfigByKey compatibility_version 3.17.0
{
    "code":0,
    "msg":"success"
}

注：若开启权限治理功能，需要使用 setSysConfigProposal 命令

设置成功，再次查询，得到当前版本已升级为3.17.0

[group0]: /apps>  getSystemConfigByKey compatibility_version
3.17.0

当前链已经完成升级，至此，链开始以新的逻辑继续运行，并支持了新的特性。