Solana v1.17 到 v2.0CHANGELOG 变更史解读、发布通道策略与升级注意事项全解析【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana本文以 Solana 仓库根目录下的 CHANGELOG.md 为主体解读 Solana 的变更记录规范、edge/beta/stable 三条发布通道策略以及 v1.17 → v1.18 → v2.0 三个版本区间的具体变更与升级注意事项并结合仓库源码CLI 参数定义、调度方法枚举、快照启动策略实现等逐条印证这些变更的实际落地方式帮助共识验证者、RPC 运营者和 DApp 开发者判断哪些变更需要修改自己的部署配置或依赖。变更记录的总体结构Keep a Changelog 格式与语义化版本CHANGELOG.md 开篇即声明其编写规范所有值得注意的变更都会记录在该文件中格式基于Keep a Changelog约定Added / Changed / Upgrade Notes等分类式条目项目遵循语义化版本Semantic Versioning即主版本.次版本.修订号的升级规则项目还维护一份“向后兼容性策略”用于界定哪些变更属于破坏性变更。文件头部列出了三条发布通道各通道拥有自己版本的 changelog 副本通道版本说明edgev2.0本仓库当前 CHANGELOG.md 所记录的通道betav1.18beta 分支的 changelogstablev1.17stable 分支的 changelog这一“一通道一分支、一分支一份 changelog”的组织方式与文件末尾“维护流程”章节中“在多个分支添加条目时尽量使用相同措辞以便版本间 diff”的要求相互呼应——每个通道分支上的 changelog 在合并时保持文字一致降低跨版本比对成本。v2.0.0Unreleased当前 edge 通道的两项变更CHANGELOG.md 中[2.0.0] - Unreleased小节目前记录了两条 Changes1.central-scheduler成为--block-production-method的默认值从 2.0 起验证者产块的事务调度默认方法由线程本地多迭代器切换为中央调度器central scheduler。源码层面可以印证这一点在 core/src/validator.rs 中定义了产块方法枚举pub enum BlockProductionMethod { ThreadLocalMultiIterator, #[default] CentralScheduler, }#[default]属性标注在CentralScheduler上即编译期默认值已经是中央调度器CLI 侧则在 validator/src/cli.rs 注册了--block-production-method参数其可选取值和帮助文案均由BlockProductionMethod::cli_names()与cli_message()动态生成cli_message()中会直接打印默认值Switch transaction scheduling method for producing ledger entries [default: {}]因此用户执行solana-validator --help时即可看到当前构建的默认调度方法。2.solana-rpc-client-api依赖base640.22Changelog 指出solana-rpc-client-api中的RpcFilterError依赖base640.22下游用户可能需要升级到base640.22。在 rpc-client-api/Cargo.toml 中可以看到base64 { workspace true }即该 crate 的base64版本由 workspace 统一锁定这正是 v2.0 workspace 将版本提升到 0.22 后对下游产生传递性影响的原因。对于直接依赖solana-rpc-client-api的客户端开发者若自身也依赖base64需要确认版本统一到 0.22 以避免链接冲突。v1.18.0变更清单与升级注意事项逐条解读1.18.0 是变更量最大的一个次版本changelog 分为Changes与Upgrade Notes两部分。以下按原文档条目完整继承并补充源码佐证。Changes1新增changelog标签的 GitHub 检查CI 侧新增了针对changelog标签的自动化检查配合下文“更新规范”中“在实现变更的同一个 PR 中更新日志”的要求强制变更必须留下记录。2--use-snapshot-archives-at-startup默认值改为when-newest该参数决定验证者启动时何时使用快照归档snapshot archives。其完整实现在 ledger/src/use_snapshot_archives_at_startup.rs 中UseSnapshotArchivesAtStartup枚举定义了三档策略语义直接体现在注释中Always只要使用快照归档就会解包并覆盖磁盘上已有的状态带来解包的重运行时开销Never只使用磁盘上已有的快照状态若磁盘上没有状态则启动失败WhenNewest#[default]即 1.18 起的新默认值仅当快照归档比磁盘上的本地快照状态更新时才使用归档——典型场景是节点停机期间下载了更新的归档重启时即以新归档启动磁盘上没有本地状态时也走归档。启动时的实际判断逻辑在 ledger/src/bank_forks_utils.rs 中Always映射为trueNever映射为falseWhenNewest则取决于本地最新 bank 的快照时间比较。参数在 validator/src/cli.rs 注册默认值由use_snapshot_archives_at_startup::cli::default_value()提供与枚举的#[default]保持一致。3solana-ledger-tool的默认值仍保持always同一小节紧跟一条例外说明solana-ledger-tool的该参数默认值仍是always。源码同样印证ledger/src/use_snapshot_archives_at_startup.rs 专门提供了default_value_for_ledger_tool()返回Always并在 ledger-tool/src/main.rs 处作为 CLI 默认值使用。这一差异符合工具定位ledger-tool 常作为无本地状态的一次性诊断/操作工具运行必须依赖归档重建状态。4新增central-scheduler选项--block-production-method1.18 首次引入central-scheduler选项2.0 才将其升为默认见上文。对应的统一调度器基础设施位于仓库的unified-scheduler-pool、unified-scheduler-logic等 crate验证者通过--block-production-method central-scheduler即可在 1.18 上先行启用。5Borsh 升级至 v1序列化框架 Borsh 更新到 v1。配套的 Upgrade Note 明确指出solana-program与solana-sdk默认支持 Borsh v1仅对 v0.10 和 v0.9 保留有限的向后兼容程序开发者应升级到 Borsh v1。6新增allow_commission_decrease_at_any_time特性门feature gate该特性允许在 epoch 后半段也降低投票账户的佣金绕开commission_updates_only_allowed_in_first_half_of_epoch特性的限制。按 changelog 的“值得记录”标准新增 feature gate 本身就属于必须记录的变更。7getSignaturesForAddress始终按区块包含顺序返回签名本地账本存储经过更新RPC 接口getSignaturesForAddress现在总是按签名被包含进区块的顺序block-inclusion order返回结果改善了此前结果顺序不稳定的问题。8simulateTransaction返回innerInstructionsRPC 的simulateTransaction现在在json/jsonParsed编码下返回innerInstructions指令内部再调用的内嵌指令便于客户端观察跨程序调用链。9Bigtable 上传新增entries表存储 entry 摘要上传到 Bigtable 的数据现在包含每个 slot 的 entry 摘要数据存储在新的entries表中。仓库中storage-bigtable、storage-proto两个 crate 负责这一上传链路见 storage-bigtable/README.md 对该链路的说明。10--signerCLI 参数禁止多值--signer不再接受以逗号分隔的多个值强制用户为每个签名重复出现--signer一次消除多签名解析的歧义。11新部署的默认账户大小改为程序精确大小新程序部署时账户默认大小从“程序大小的两倍”改为程序本身的精确大小。这意味着若程序将来要升级到更大的版本必须先通过solana program extend扩展程序账户否则升级会因空间不足失败。12gossip_service::get_client()接口变更gossip_service::get_client()的接口签名发生变化gossip_service::get_multi_client()被移除。这是库级别的破坏性接口变更依赖 gossip client 的下游 crate 需要适配。Upgrade Notes1.18 升级须知Borshsolana-program、solana-sdk默认切换到 Borsh v1对 v0.10/v0.9 有限兼容程序开发者应升级依赖Bigtable自运营 Bigtable 实例的运营者必须在升级 warehouse 节点之前先手动创建entries表否则上传会失败。v1.17.0changelog 诞生与首个重启加速参数[1.17.0]小节记录了 changelog 机制本身的首次落地Added a changelog本变更日志自 1.17 起开始维护这也解释了为何 stable 通道v1.17的 changelog 内容极简新增--use-snapshot-archives-at-startup参数用于加速验证者重启。即 1.17 引入该参数1.18 将其默认值调整为when-newest形成“先有参数、再改默认”的渐进式演进路径。贡献者如何更新这份 ChangelogCHANGELOG.md 后半部分是一份面向多类读者贡献者、共识验证者运营者、RPC 运营者、DApp 开发者的编写规范完整继承如下。什么样的变更值得记录Noteworthy一条变更满足以下任意一条即必须记录新增 feature gate实现了某个 SIMDSolana Improvement Document修改了公共 API改变了验证者 / RPC 的常规运行配置改变了命令行参数修复了受公众关注的 bug显著提升了性能由外部贡献者提交。以 1.18 的条目为例几乎每一条都精确命中上述标准central-scheduler命中“命令行参数”allow_commission_decrease_at_any_time命中“feature gate”Borsh v1 命中“公共 API/SDK 行为”gossip_service::get_client()命中“公共 API”。更新操作规范Instructions同一 PR 原则在实现变更的那个 PR 中同时更新本日志若变更横跨多个 PR则在使功能代码完备的那个 PR 中更新Unreleased 段落原则在每一个合并目标分支的[Unreleased]段落中添加条目——Changes部分写变更描述若变更需要验证者/RPC 运营者改配置或需要 DApp/客户端开发者改代码则同时写Upgrade Notes关联溯源链接到相关的 feature gate 议题或 SIMD多分支同词若在多个分支都添加条目尽量使用相同措辞便于不同版本日志之间的 diff 比对。维护者如何维护这份 Changelog文件末尾给出了维护流程与发布通道策略直接对应创建新的发布分支时次版本发布如 v1.18 → 新建分支在 master 上提交对 changelog 的更新更新 edge、beta、stable 三条通道的链接创建新小节vx.y1.0 - Unreleased即下一个次版本对应 edge 通道去掉vx.y.0小节的Unreleased标注即它正式成为已发布版本。从该提交创建vx.y分支将该提交打标签vx.y.0。创建新的补丁发布时同分支内的补丁版本在发布分支上提交 changelog 更新去掉vx.y.z小节的Unreleased标注在顶部新增vx.y.z1 - Unreleased小节。将新提交打标签作为新发布版本。这套“分支 通道、小节 版本、Unreleased 标注 未发布状态”的三要素模型保证了任意时刻打开任意分支的 changelog都能清楚知道哪些变更已随哪个版本发布、哪些还在路上。小结如何根据这份 Changelog 做升级决策跑 edgev2.0 方向的验证者注意--block-production-method默认已变为central-scheduler如需回退可显式传thread-local-multi-iterator取值来自 core/src/validator.rs 的枚举变体跑 1.18 的验证者默认快照启动策略为when-newest若希望严格复用磁盘状态或强制从归档重建可用--use-snapshot-archives-at-startup never/always显式指定自运营 Bigtable 者务必先建entries表再升级程序/客户端开发者优先处理 Borsh v1 升级与base640.22 对齐v2.0 下由solana-rpc-client-api传递而来程序账户大小变化要求把solana program extend纳入升级预案贡献者凡命中“Noteworthy”八条之一的变更必须在同一 PR 中更新目标分支的[Unreleased]段落并附上 feature gate/SIMD 链接。以上所有条目均可在 CHANGELOG.md 原文及其引用的源码路径中复核本文未引入任何仓库之外的性能或兼容性结论。【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考