Stellar的Bell升级临近测试网投票，但收款系统可能在网络升级之前就需要做决定。Coinranking在2026年10月30日报道，Protocol 30测试网投票安排在11月3日17时UTC，主网投票安排在11月23日同一时间，生效仍以验证者批准为条件。对钱包和托管方而言，准备工作不能只看节点是否在线：一套能读取新账本、却不认识新地址的系统，仍可能把正常付款留在业务账户之外。[3]
能读到账本，仍可能收不进一笔款
TokenPost在10月24日关于发布清单的报道中，给出了一个值得单独检查的版本差异：JavaScript SDK v16.4.0可以解码Protocol 30账本，但不支持W地址；v17.3.0才支持这种地址。该报道还提醒，较旧SDK可能无法解码修改后的账本头，自定义XDR解码器也可能需要调整。[4]这份清单反映的是报道时点，不能当作11月1日的最新发布状态；它揭示的兼容性拆分，却能直接指导一次接入审查。
“可以继续读取区块”和“可以完整处理客户付款”，应当由两组证据分别证明。前者主要回答数据能否进入系统，后者还包括地址校验、客户识别、入账规则与异常处理。只在监控面板观察节点高度，可能看不到业务层已经拒绝新地址；只做一笔旧地址转账，也覆盖不到新格式经过表单、数据库和清算程序时的变化。
假设一个托管平台已经更换上游节点，但网站的提现地址校验库仍停留在旧格式。这时，链上服务正常和客户无法提交目的地址可以同时发生。另一个相反的情景是，前端允许保存新地址，后台批量任务却按旧长度截断或拒绝记录。这些是需要测试的故障路径，并非对某个平台已发生故障的断言。升级是否准备妥当，要用这类跨组件案例来检验。
图为TokenPost已核验报道的原文摘录排版，非网页截图；所列版本能力对应2026年10月24日报道，未冒充当前发布清单。
W地址把客户识别带进支付路径
按TokenPost的说明，W地址把智能合约地址和64位标识结合，允许一个合约区分不同客户的付款。Coinranking对CAP-84的报道也写到，一个合约地址可以服务多位客户，交易的客户标识会出现在事件流里。[4][3]业务上的收益是减少收款入口的碎片化；代价是客户归属更依赖系统对地址和事件的完整解释。
理解这个变化，可以从一笔共享入口收款开始。平台需要保存客户给出的目的信息，构造付款，读取执行结果，并把结果映射回正确的内部账户。若某个环节只保留合约地址而丢掉区分客户的信息，即使资产到达正确合约，也不足以让后端自动确定应给谁记账。这里讨论的是接入方应验证的业务约束，不是在断言协议会丢失标识。
因此，测试数据不能只有“转账成功”这一列。一次可复查的测试，应保存输入地址、解析后的字段、交易标识、相关事件和内部账户结果，并让另一个处理程序能够重放。两名客户使用同一合约入口的情景尤其有用：付款先后顺序改变、重复收到通知或服务中途重启时，归属关系仍应保持一致。这样才有机会发现那些单笔成功测试遗漏的问题。
相关下载： Binance全球顶级交易所 v3.22.3大小：306.0M
历史账本重放也值得纳入验收。实时处理通过，只能说明当前这条在线路径可用；备份恢复、审计导出和补账程序可能使用另一套SDK或自定义解码器。若日常服务已认识新格式，而恢复工具仍无法读取新账本，系统就会在真正需要恢复时失去一致的账务证据。这个风险来自依赖没有同步升级，而不能用“主节点已经更新”来排除。
概念插图：同一收款入口需要保留区分客户的完整信息，不代表实际产品界面或已观测到的故障。
安全能力与计时精度，各自有明确边界
合约验签能力，不等于所有账户已经迁移
Bell的另一项内容是CAP-87。Coinranking把它描述为在智能合约内部加入ML-DSA后量子签名验证能力，并指出经典账户的后量子签名者仍要等待未来协议变化。TokenPost也强调，网络交易签名继续使用Ed25519，这次变化针对的是合约检查。[3][4]把这项能力写成整条网络所有账户已经完成后量子迁移，会超出两份报道支持的范围。
对接入团队而言，合约具备一种验证能力，并不会自动替业务决定谁能签名、如何更换密钥以及怎样处理恢复权限。如果某个产品计划使用新能力，就需要披露具体合约、调用方式和权限配置，再提供实际验证记录。若产品仍沿用原有授权路径，新协议提供的工具也不能被直接当作这个产品已经实现的安全收益。
毫秒记录，尚不能证明更短到账时间
CAP-88让账本关闭时间具有毫秒级精度，两份报道都明确说，这项调整本身不会使账本自动关闭得更快。[3][4]更细的读数有助于区分先后，但读数精细与处理速度是不同属性。业务测量仍应从同一个事件起点出发，例如请求被接收时刻，再比较链上结果可见和内部账户可用的时刻。
如果新旧版本的监控系统采用不同取整方法，报表中的等待时间甚至可能发生纯统计变化。一个接入方若宣称升级带来更快到账，需要说明样本、网络条件与失败请求的处理口径，不能只展示几笔更细的时间戳。这是评价未来性能主张的证据要求，本次尚未取得足以证明实际提速的测量数据。
把测试网投票当作一次完整演练的起点
11月3日和11月23日17时UTC，对应UTC+8的次日凌晨1时，分别是11月4日和11月24日。这里列的是报道中的投票安排，既不保证日期不变，也不等于提前宣布升级已经生效。[3][4]团队安排人员值守、测试窗口和对外通知时，应同时标明原始时区，并以临近投票的官方状态为准。
相关下载： 欧易okx交易所 v6.195.1大小：549.4M
测试网阶段可以先让代表性的业务路径经过同一套发布候选配置：普通付款、新格式地址收款、重复通知和账本重放各自留下结果。遇到失败时，保存原始输入与错误位置，比只贴一张“交易失败”的截图更能确定问题落在协议、接口还是内部账务。测试通过后，还需核对主网准备部署的组件是否与测试配置一致；测试网上的成功不能替另一个版本组合背书。
发布清单是依赖审查的入口，最终验收对象是一笔付款经过的完整路径。TokenPost当时提到部分工具仍处于候选或待发布状态，这些描述在后续可能已经改变。[4]本次未能读取Stellar官方指南全文，也未取得截至11月1日逐项验证的最新版本状态，因此不把旧报道里的版本号列作统一安装要求。部署前需要重新确认实际版本说明及其支持范围。
这次升级对XLM的意义，也应沿着真实使用继续观察。能服务更多客户的合约入口、可供开发者使用的新验签方式，都是产品可能采用的能力；协议新增能力本身，还不能证明业务已经采用，更不能直接推出代币价格反应。下一阶段更有解释力的证据，是哪些产品开放了支持、多少实际付款走过新路径，以及异常记录能否被准确恢复。这样的结果出现以后，才有条件讨论接入成本究竟下降了多少。
用户评论