Stellar(XLM)主网激活Protocol 28 “Adapter”,开启合约数据迁移路径

Protocol 28 已在主网生效

Stellar (XLM) 主网已于2026年9月16日17:00(UTC)正式运行代号 “Adapter” 的 Protocol 28 升级,为存储在账本上的智能合约数据打开了可行的迁移路径。这次改动面向的是 区块链 上的 Soroban 开发者和节点基础设施,而非日常的钱包与支付用户。行情层面,现货交易中尚无证据表明此次激活与 Stellar (XLM) 价格存在确定的因果关系。此前我们对 XLM 技术面的跟踪显示,该代币曾突破其 50周移动均线,目标指向0.2227美元,但本次升级是网络事件,不是价格事件。Stellar 发展基金会围绕三项核心改进提案构建这一版本:CAP-86、CAP-85 和 CAP-83,官方软件版本文档将 Protocol 28 主网构建的日期标注为9月16日。Soroban 是直接内嵌在 Stellar 网络中的智能合约平台,而非独立的 侧链,它执行的是编译为 WebAssembly 的 Rust 程序。

Adapter 之前,合约从账本读取数据要求完全匹配:结构体的每一个字段都必须以键的形式存在,且不能出现任何多余的键。缺失一个字段或多出一个字段,读取都可能直接失败。CAP-86 放宽了这一约束,引入支持稀疏匹配的宿主函数,容忍缺失或新增的字段。这样一来,旧存储可以分阶段迁入新数据结构,而不是一次性切换、全部作废。

CAP-85 解决的是另一个瓶颈。它支持由外部管理的可执行代码引用:一批共享同一程序的合约,只需切换一个引用即可整体升级,不必逐一替换每个实例。这在大规模部署中避免了版本混杂的合约集群,但开发者仍需自行核对新代码与旧数据的兼容性,这部分工作无法省略。

CAP-83 作用于 共识机制 层面:验证人可以在完整交易集到达之前开始投票,同时配套一套丢弃程序,将迟到或未通过有效性校验的交易集剔除,以缓解数据传播造成的出块停滞。并行下载交易集的功能将在主网切换后分阶段上线。验证人运营者被建议检查时钟同步,而直接读取账本的索引器和数据管道则必须能够处理新的账本值类型。

Soroban SDK v28 与 Stellar 的11年

开发者工具在9月30日跟上节奏。Soroban Rust SDK 的28版本当天发布,Stellar 官方 Build on Stellar 账号在 X 上确认了发布,摘要署名为 Stellar 首席软件工程师 Leigh McCulloch。SDK v28 支持 Protocol 28,包含构建系统变更以及合约数据迁移的新行为。发布说明指出,对大多数合约而言,这次变更只意味着重新编译一次,别无其他。其功能清单包括 Spec Shaking v2:SDK 对规范(spec)的发布方式引入死代码消除,SDK 本身会为所有内容生成条目,随后 stellar-cli 构建过程再剔除合约用不到的条目。其余新增覆盖稀疏发布的事件、可执行代码引用,以及可在测试中原生上传的合约。迁移支持落在了关键位置:一个结构体在账本上以按字段名作为键的映射形式存储,v28 让合约即使在其字段与最初写入时不一致的情况下也能读取该映射。

@BuildOnStellar · X 帖子

X 上确认了发布.

在 X 上查看

这一天也是网络的11岁生日。Stellar 生态 的历史比其账本更长:网络于2015年9月30日上线,产品负责人 Tomer Weller 指出,这个周年属于 “新” Stellar 网络,更早的2014年版本运行时使用的代码是 STR。近期进展指向真实世界场景:网络的代币化现实世界资产持有人已突破22,000名,而 MoneyGram 在哥伦比亚的 Visa 稳定币卡试点 等部署仍在沿着这一方向推进。

需要手动执行的那一步迁移

对照官方发布文档来读,上述两条线索指向同一条主线:合约数据会在网络的整个生命周期中改变形态。Protocol 28 的官方说明将主网版本日期定为2026年9月16日,要求基于 Soroban Rust SDK 28.0.0 重新编译,并指示开发者先复现旧状态、验证新合约能够读取旧状态,之后再调用迁移完成指令。近期压力落在节点运营者身上:索引器和数据管道必须处理新的账本值类型,验证人时钟同步也需逐一检查。网络上的企业级工作,包括 U.S. Bank 的 USBDC 稳定币测试,说明了可升级合约数据在规模化场景下的价值。这次变更中保持不变的,是那个手动环节:数据不会自行完成迁移。