XLMStellar 协议 30 升级“Bell”测试网已上线：基础设施重塑与合规挑战
在计划好的验证者投票通过后，Stellar 的 Protocol 30 升级（代号“Bell”）于 11 月 3 日在测试网上线。目前，网络拥有直至 11 月 23 日 17:00 UTC 的时间窗口，要求钱包、交易所、托管商和索引器做好主网投票的准备。
Bell 升级包含三项核心变更：多路复用合约地址（muxed contract addresses）、Soroban 合约内的后量子签名验证，以及毫秒级账本时间戳。Stellar 开发基金会（SDF）将此发布定位为面向企业规模智能账户的基础工作。然而，对于在 Stellar 网络上结算代币化资金和稳定币流的机构而言，此次升级的实际影响比其宣传口径更为具体且深远：其中两项变更改变了外部系统必须解析的数据格式。这才是规划工作的重点所在。
在结算链上，协议升级的价值往往不在于它们增加了什么功能，而在于新代码与旧工具碰撞时会破坏什么。Bell 升级直接改变了账本头部的格式。
三项变更，仅此三项
SDF 在其公告中以一句话概括了本次发布：“它旨在使智能账户准备好以企业规模运行，并启动两个长期目标的工作：量子安全签名和更快的账本。”
这句话背后的三个提案分别是：CAP-88（毫秒级账本时间）、CAP-84（多路复用合约地址）和 CAP-87（合约中的 ML-DSA 签名验证）。没有第四项内容，也没有费用市场或共识机制的变更。验证者使用与处理交易集相同的可信验证者集合和阈值进行投票；XLM 持有者不参与投票。
发布工程始于 10 月 16 日，当时 Stellar Core v30.0.0 作为稳定版本发布，随后发布了 Horizon、RPC、Galexie 及维护中 SDK 的 Protocol 30 版本。测试网投票于 11 月 3 日进行，主网投票定于 11 月 23 日，两者均在 UTC 时间 17:00。SDF 表示，用于在主网投票前武装节点器的命令将通过验证者渠道提前分发。
CAP-84：为托管商解决多路复用合约地址问题
Stellar 多年来一直支持多路复用账户（muxed accounts）。一个多路复用账户是一个带有附加标识符的 Stellar 账户，允许交易所向每位客户分配独特的存款地址，同时资金汇入同一个账户，由交易所在链下追踪所有权。这是支付业务运行的标准总库模型。
然而，智能账户（即合约而非密钥对）此前没有等效方案。持有客户余额的合约无法区分 incoming payments，因此 workaround 是为每个客户部署一个合约。SDF 对此局限性的描述直白而严厉：这种方法适用于十个客户，但不适用于一百万个客户。
CAP-84 将 64 位标识符附加到合约地址上，并以新的格式书写，该格式以 “W” 开头，标识符记录在转账事件中。现在，一个合约可以服务 18,446,744,073,709,551,616 个不同的标识符（即 64 位字段的全范围），而无需为每个终端用户部署单独的合约。
命名背后有一段小的工程趣闻。SDF 负责钱包的高级工程经理 Jake Urban 表示：“这是一个倒过来的 M。”他们曾考虑复用 “M”，但决定使用不同的类型，以便开发人员始终清楚自己正在处理的数据类型。
这带来了两个运营后果：
- 钱包、交易所和托管商必须在验证、显示和存储逻辑中接受 “W” 地址类型。
- 希望接收此类付款的合约开发者必须使用接受多路复用变体的地址参数，因为纯地址参数会拒绝它。
权衡是否将客户余额合并到单一智能账户中的银行和托管商，现在有了支持的路径。这正是机构代币化项目在承诺大规模交易量之前所要求的底层设施。
量子安全，但仅限于合约内部
CAP-87 为 Soroban（网络的智能合约环境）添加了三个主机函数，用于验证符合 NIST FIPS 204 标准中定义的 44、65 和 87 参数集的 ML-DSA 签名。验证在 Stellar Core 内部运行，而不是在合约代码中运行，这使得调用成本保持低位，并且意味着实现只需针对官方测试向量编写和测试一次，而不需要由每个合约作者重复实现。
这是一步切实的进展，但也具有局限性。SDF 的常见问题解答直接回答了显而易见的问题：“Bell 让 Stellar 具备后量子安全性了吗？没有。它让智能合约能够验证 ML-DSA 签名，从而使合约账户可以选择加入量子安全的授权。网络交易签名仍为 Ed25519。”经典账户的原生后量子签名器留待未来的协议变更，这意味着绝大多数 Stellar 账户（即密钥对而非合约）今天不受影响。
这一发展方向在整个行业中共鸣。Starknet 的代币持有者在 10 月以 93.52% 的投票率探索成为独立的后量子 Layer 1。相比之下，Stellar 的方法更为渐进：首先交付验证原语，让合约账户选择加入，并在标准和托管商依赖的硬件密钥管理准备就绪之前，保持账户模型不变。
可能导致故障的变更
CAP-88 是读者需要反复阅读的部分。它改变了账本头部以携带毫秒级时间戳的格式。SDF 在其升级指南中直言不讳：“Bell 改变了账本头部的格式，因此任何读取账本数据的东西都需要理解这种格式。”
任何解码 StellarValue、LedgerHeader、LedgerCloseMeta 或 SCP 历史的消费者，都必须转向 Protocol 30 XDR 定义，否则将在未知的联合分支上失败。SDF 对 SDK 用户的指示没有任何委婉语：“在本周期中，SDK 升级不是可选的。”较旧的 SDK 可能会错误地解码 Protocol 30 账本，或者根本无法解码。
对于假设整秒的任何事物来说，还有更细微的破坏。现有的 closeTime 字段未更改，仍报告整秒数，等于向下舍入的毫秒值，时间边界、可索赔余额谓词和合约时间戳保持整秒语义。被削弱的是“一个账本至少等于一秒”的假设。连续的账本现在可以在同一个整秒内关闭，因此建立在“一个账本之后”意味着“一秒之后”的逻辑需要审查。对于运行定时锁定结算逻辑的支付业务来说，这是一次代码审查，而非配置更改。
时钟为何对结算台至关重要
9 月的 Adapter 发布（Protocol 28）将主网账本关闭时间从约 5.7 秒缩短至 5 秒，削减了约 12.3%。CAP-88 并未延续这一曲线。它移除的是由整秒时间戳带来的一秒下限，这阻碍了诸如 4.5 秒等目标的实现，并使亚秒级关闭时间在原则上成为不可能。算术很简单：在五秒的节奏下，网络每天产生 17,280 个账本；在 4.5 秒下，它将产生 19,200 个，约增加 11%。Bell 使这种算术变得可行。但它本身并不执行这一变化。
这项工作的商业逻辑可见于 Stellar 的机构管道。网络已被推向受监管资产结算和代币化基金基础设施，这也是本文跟踪的主题之一，例如 DTCC 的代币化服务已与 34 种证券和一批华尔街参与者一起上线。更快的最终性和合约内的每客户寻址对该受众的重要性不同于零售交易者：它们缩短了抵押品处于未结算状态的时间窗口，并允许一个合约容纳许多客户的余额而不破坏对账。
既非升级故事，也非价格故事
XLM 尚未定价这些内容。根据 CoinGecko 数据，截至 11 月 4 日 UTC 时间 20:16，该代币交易价格约为 $0.1657，24 小时内上涨 2.1%，但 7 天内下跌 3.9%，30 天内下跌 23.1%，30 天范围为 $0.1621 至 $0.2156。在主网投票前三周，该代币处于该范围的底部。
这种背离不应被解读为对 Bell 的判决。协议升级很少单独推动代币价格，也没有证据表明测试网激活或其缺失解释了 XLM 的 10 月跌幅，这与 Binance 黑客事件和中选民波动后山寨币的整体撤退相吻合。价格显示的是市场不会提前为基础设施买单。希望升级在商业上产生影响的持有者必须等待交易量，而不是等待投票。
11 月 23 日之前必须发生的事
工作按角色清晰划分：
- 验证者：安装 Stellar Core v30.0.0 并等待武装命令。
- 交易所和托管商：升级 SDK 并添加对提取到多路复用合约地址的支持。
- 钱包和入口：在验证、显示和存储中添加 W 地址。
- 索引器、浏览器和分析管道：在没有 SDK 的情况下解码原始账本数据的任何人，必须在投票前更新 XDR 定义。
- 合约团队：无需更改现有合约（它们在升级后继续工作），但希望使用 ML-DSA 功能的团队必须针对 Protocol 30 Soroban SDK 重建，并使用匹配或更新的 Stellar CLI。
SDF 明确指出，该指南仅供参考，运营商有责任在每次投票前测试自己的集成。这一警告值得重视。Bell 是在承载真实支付量的链上进行的一次格式变更，故障模式并非戏剧性的停机，而是解码器返回错误数据，或在激活后的第一个账本上，钱包拒绝解析存款地址。
主网投票本身可能失败或推迟；日期是计划中的投票，而非交付保证。如果验证者批准，第一个 Protocol 30 账本就是网络上每个集成要么理解新头部，要么不理解的那一刻。三周足以升级 SDK。但这审计假设“一个账本意味着一秒”的结算逻辑的时间并不多。
常见问题解答 (FAQ)
Stellar 的 Bell 升级何时在主网上线？
验证者将于 2026 年 11 月 23 日 UTC 时间 17:00 进行投票。只有当该投票达到 Stellar 的共识阈值时，升级才会生效，因此该日期是计划中的投票，而非保证的激活。
Protocol 30 是否使 Stellar 具备量子安全性？
否。Bell 为 Soroban 添加了 ML-DSA 签名验证，使合约账户可以要求后量子授权。经典账户的网络交易签名仍为 Ed25519，原生后量子签名器计划在未来的协议变更中推出。
钱包和交易所是否需要为 Protocol 30 升级？
是。SDF 表示，由于账本头部格式发生变化，本周期中的 SDK 升级不是可选的。钱包、入口和托管商还必须在验证、显示和存储中接受用于多路复用合约地址的新 W 地址类型。
Bell 会让 Stellar 的速度超过五秒吗？
仅凭自身不能。CAP-88 移除了由整秒时间强加的一秒下限，为后续步骤中 4.5 秒的关闭时间等目标铺平了道路。本次升级未改变五秒的节奏。
CAP-84 中的多路复用合约地址是什么？
一种携带 64 位标识符的合约地址，以新的 “W” 开头格式书写。它允许一个智能合约为许多客户持有余额，同时转账事件中的标识符告诉操作员是谁的付款。
主要来源：Stellar 开发基金会的 Bell 公告、Protocol 30 升级指南，以及 CAP-84、CAP-87 和 CAP-88 规范。价格数据：CoinGecko，2026 年 11 月 4 日 UTC 时间 20:16。
本文仅供信息参考，不构成投资建议。协议升级日期取决于验证者投票，可能会发生变化。
交易所
交易所排行榜
24小时成交排行榜
人气排行榜
交易所比特币余额
交易所资产透明度证明
去中心化交易所
资金费率
资金费率热力图
爆仓数据
清算最大痛点
多空比
大户多空比
币安/欧易/火币大户多空比
Bitfinex杠杆多空比
ETF追踪
索拉纳ETF
瑞波币ETF
香港ETF
比特币持币公司
加密资产反转
以太坊储备
HyperLiquid钱包分析
Hyperliquid鲸鱼监控
大额转账
链上异动
比特币回报率
稳定币市值
期权分析
新闻
文章
财经日历
专题
钱包
合约计算器
账号安全
资讯收藏
自选币种
我的关注