当一个单一的智能合约需要为成千上万的客户持有资金时，会发生什么？在 Stellar 网络上，答案一直有些尴尬。Stellar CAP-84 是一项协议提案，旨在通过“多路复用合约地址”（Muxed Contract Addresses）来填补这一空白。
其理念很简单：给合约地址附加一个 64 位 ID，从而使一个合约能够将许多链外余额区分开来。这一变更位于 Bell 协议第 30 版升级中，预计将于 2026 年 11 月接受验证者投票。
CAP 是核心 advancement 提案（Core Advancement Proposal），这是 Stellar 开发者用来建议更改基础协议的格式。该提案编号为 84，标题为《多路复用合约地址》。根据协议仓库的信息，该提案目前状态为“已接受”，创建于 2026 年 6 月 24 日，Stellar 开发基金会的 Jake Urban 被列为其所有者和作者。
要理解这一点，首先要从“多路复用账户”（Muxed Account）开始。多路复用账户是一个带有附加 ID 的 Stellar 账户。每个客户获得一个唯一的存款地址，但所有资金都汇入同一个账户。企业则在链下追踪谁拥有什么。交易所和出入金平台已经在使用这种模式。
智能账户此前没有对应的等效机制。智能账户由智能协议运行，而不是普通的密钥对，因此它可以设置自己的支出规则，例如通行密钥（passkeys）或多签。如果没有多路复用功能，持有客户资金的智能合约就无法区分 incoming payments（传入支付）。之前的变通方法是“每个客户一个合约”。
Stellar CAP-84 消除了这种变通方法。它赋予了协议地址与普通账户相同的 ID 功能。
该提案向协议添加了一种新的地址变体。它将协议 ID 与一个 64 位数字配对。
文本形式以字母 "W" 开头。基金会将 W 描述为倒置的 M，选择它是为了让开发人员能够快速区分这两种类型。
| 账户 (Account) | G | 标准密钥对账户 | 合约 (Contract) | C | 智能合约 | 多路复用账户 (Muxed account) | M | 带有 64 位 ID 的账户 | 多路复用合约 (Muxed contract) | W | 带有 64 位 ID 的合约 |
CAP 文本指出，W 有效载荷长度为 40 字节：包括 32 字节的合约 ID 和 8 字节的多路复用 ID。这使得它比正常的协议地址大 8 字节。规范称其对资源的影响可忽略不计。
当代币发送到 W 地址时，它会像往常一样落入底层协议。ID 随传输事件一起传递，位于一个名为 `to_muxed_id` 的字段内。接收应用程序读取该 ID 并为正确的客户记账。余额和授权保持不变。
官方升级指南将 Stellar CAP-84 视为任何处理地址的应用的操作事项。现有的协议保持兼容，交易层面不会发生破坏性变化。工作主要在于应用程序代码层面。
来自指南的关键点：
SDK：Protocol 30 SDK 包含 W 地址解析器。JavaScript SDK v17.3.0 支持它，而较旧的 v16.4.0 系列可以解码新账本，但会忽略 W 地址。 类型检查：验证、显示或存储地址的应用程序需要在类型检查中添加 W 变体，以便在应用程序的各个部分都能识别这些地址。 交易所和托管方：需要支持向 W 地址的提款，目前依赖 M 地址进行存款的团队可能会考虑 W 格式是否更适合他们的设置。 合约团队：用普通地址声明的函数会拒绝 W 地址；用 MuxedAddress 声明的函数则两者都接受。 索引器和浏览器：在升级之前需要更新 XDR 定义，否则解码器可能会失败。跟踪 SDK 升级截止日期的开发者会发现同样的警告重复出现。影响主要是操作性的。忽略 W 地址的加密钱包可能会拒绝有效的目的地，这是一个支持问题，而不是安全漏洞。
设计目的是狭窄且精确的。
仅限目的地：多路复用合约地址可以接收转账。发送端不进行多路复用。 仅限转账：支持涵盖 Stellar Asset Contract 的转账功能。铸造（Mint）和 `transfer_from` 曾被考虑但被推迟。 不用于存储：主机拒绝在协议存储键中使用多路复用合约地址，因为 ID 旨在用于链下路由。 无授权变更：多路复用地址在余额和权限方面与其基础合约行为一致。现有数据表明作者希望降低风险。该提案复制了早期提案 CAP-67 中的账户设计，因此 SDK 和索引器可以重用为 M 地址构建的逻辑。代价是范围受限。需要多路复用铸造或源端跟踪的团队可能需要等待后续的提案。
| 2026 年 10 月 16 日 | Stellar Core v30.0.0 稳定版本发布 | 2026 年 11 月 3 日 17:00 UTC | Testnet 升级投票 | 2026 年 11 月 23 日 17:00 UTC | Mainnet 升级投票 |
基金会表示日期可能会发生变化。每次升级仅在验证者批准后才生效。
有几项内容仍然开放。CAP 将其协议版本、测试用例和实施部分列为待定（TBD）。然而，Bell 公告将该变更置于 Protocol 30 中。W 地址的最终手续费定义也存在于 SEP-23 这一独立标准中。
采用情况是更大的未知数。在审查的官方页面中，没有任何主要加密交易所或托管方公开确认了对 W 的支持。企业是否大规模转向智能账户取决于产品，而不仅仅是协议本身。
公告也未提及 XLM 价格。任何市场影响都将是投机性的。
Stellar CAP-84 赋予智能合约一项多年来账户一直拥有的技巧：一个链上地址，对应多个链下客户。它看起来很小，但却消除了企业在智能合约中持有客户资金的一个实际障碍。
最引人注目的是其谨慎的范围。它复制了经过验证的设计，仅涵盖转账，并保留授权不变。不确定的是投票结果以及钱包和交易所添加 W 支持的速度。
声明：文章不代表币圈网立场和观点，不构成本站任何投资建议。内容仅供参考！
免责声明:本站所有内容仅供用户学习和研究,不构成任何投资建议.不对任何信息而导致的任何损失负责.谨慎使用相关数据和内容,并自行承担所带来的一切风险.