Stellar发展基金会为11月24日的Bell协议30投票设定运营商软件要求

激活前的三类工作

Bell协议30升级进入投票前的准备阶段。Stellar发展基金会在10月23日更新了Bell升级指南,逐类运营商明确了网络激活前所需的软件版本,并把一项独立的工作量加在交易所、钱包以及直接读取账本数据的服务商身上。指南将基础设施与开发工具分别配对到受支持的版本,同时要求每一个运营商自行测试其集成环境,这一步骤与验证人投票被基金会刻意分开处理。测试网投票定在11月4日,主网投票定在11月24日,但两个日期均可能调整,升级能否落地最终取决于验证人的批准。基金会此举针对一个现实落差:验证人投票决定协议30是否激活,而交易所或钱包日常运行的软件版本,才决定其用户能否无感地度过这次变更。指南本身不改动网络上的任何东西,它只是把提案拆解成一份按服务划分的软件与数据格式清单。

对处于变更下游的各方而言,指南划出了三条责任线。运营热钱包基础设施的交易所与托管机构,需要确认自己能向新的W格式合约地址发起提币。钱包与资产发行方则要核验接收地址输入、处理转账记录的相关功能。直接读取账本数据的服务,包括索引器、区块浏览器和分析工具,面对的是另一项义务:协议30会在账本头中引入一种新的数值格式,仍基于现有XDR定义构建的解码器,可能在激活后无法读出账本数据。XDR是Stellar网络用来表示交易和账本数据的格式,这也是基金会要求受影响的团队在投票之前而非之后刷新定义的原因。

W格式地址与XDR解码

最直观的变化是以'W'开头的合约地址格式。每个智能合约地址附带一个64位标识符,单个合约由此可以区分来自众多不同客户的入金。SDK更新让新地址变得可读,但应用代码同样要跟上:凡是校验、展示或存储钱包地址的逻辑,以及读取转账目标的代码,都必须接受W格式。硬件钱包的显示屏也属于这一组。相比之下,已有的智能合约在升级后继续正常运行,是否采用新的合约功能由各开发者自行决定。

基金会列出的必需版本包括:stellar-core v30.0.0,Horizon、RPC与Galexie均为v30.0.0,JavaScript SDK为v17.3.0,Go SDK为v0.8.0。16.x维护版本v16.4.0可以读取新账本,但无法处理W地址,因此任何需要W支持的服务必须升级到v17.3.0。Horizon与RPC端点负责把账本暴露给应用,对于通过这些API查询链上数据而非直接解析原始XDR的服务来说,两者对齐到v30.0.0尤为关键。Soroban Rust SDK的30.0.0-rc.1也进入了名单,稳定版本预计在主网投票前发布,而面向协议30的Stellar CLI构建在指南更新时仍未完成。除地址之外,Bell还带来两项能力:面向智能合约的ML-DSA签名验证,以及毫秒级的账本时间记录。网络交易签名仍停留在Ed25519,时间戳的变化本身也不会缩短账本生成的间隔。需要强调的是,两项准备工作彼此独立:转账测试通过,不代表解码器能扛住新的账本头。

对照发行说明本身来看,协议30属于增量式变更:既有合约可以平稳度过激活期,是否采用新功能是开发者的选择。真正的风险在链下,在协议改动完全触及不到的代码里。到11月24日投票时仍未完成迁移的解码器或地址校验器,才是需要盯住的故障点,而非验证人的数量。W地址方案让单个合约能够区分众多客户的入金,指向的是把传统金融结算搬到Stellar(XLM)上的托管与交易所通道,与Stellar上首笔机构回购的结算、以及DTCC规模达30万亿美元的代币化服务是同一赛道,后者计划于2027年上线。尚未完成的Stellar CLI构建与未发布的稳定版Soroban SDK,给运营商留下一个到主网投票为止的收尾窗口,激活之后才迁移的服务,将面对一份其工具从未被设计去解析的账本。