XRP 账本提议的 Smart Escrow 功能在测试阶段取得进展。10 月 5 日，专注于 XRPL 可编程性的 RippleX 资深软件工程师 Mayukha Vadari 宣布了第九次 Smart Escrow Devnet 发布。根据她的发布说明，测试网络已迁移至新基础设施，以 wasm-devnet.dev.ripplex.io 取代已退役的 wasm.devnet.rippletest.net 端点。该提议功能将允许账本上的托管支付遵循受限的自定义规则。

新的 Devnet 为 Smart Escrow 提供更广泛的测试环境

地址变更只是此次更新的一部分。开发者需要一个共享环境，使其合约、钱包、库和节点配置能够在同一套规则下运行——当代码参与到锁定资金是否可以释放的决策时，这项工作尤为重要。

Vadari 表示，在团队持续加固框架和代码的同时，该项目仍处于审查和测试阶段。Devnet 为发现兼容性和安全问题提供了场所，之后 Smart Escrow 才能被考虑部署到主网。

Smart Escrow 为锁定资金增加可编程条件

XRPL 已支持带有简单释放条件的托管支付，主网自 2017 年底起便提供这一功能。资金可以在设定时间后变为可用，或在有人提供所需的密码学凭证时释放。这些规则适用于简单的安排，但应用可能需要一个指定的审批人、一个经过验证的事件，或多个条件共同校验。

设想一位买家为卖家锁定 XRP：只有在指定公证人确认交付后，托管才会释放，同时设有截止期限，若确认始终未到达，买家可以取回资金。Smart Escrow 正是为这类场景而设计。创建托管时会附加一个小的 WebAssembly 程序，当有人尝试完成托管时该程序便会运行。程序评估约定的规则，并判断释放是否可以进行。

对 XRP 账本的提议变更以公开的 XLS（XRP Ledger Standard）提案形式记录。XLS-0100 Smart Escrows 规范列出了可能的用途，涵盖合规冻结、里程碑付款、代币归属、拍卖机制以及基于预言机的条件。每个用例都依赖同一个核心理念：释放资金的规则在资金被锁定之前就已写入托管合约。

限制措施旨在保护网络和资金

任何围绕支付运行代码的系统都需要明确的限制。每个 XRPL 验证节点在托管完成时必须得出相同的结果，否则网络将无法就账本状态达成一致。

因此，Smart Escrow 代码在受限环境中运行。它不能自由调用外部服务或访问文件，并受到内存和计算方面的限制。这些边界有助于防止编写不善的合约消耗过多资源或在验证节点之间产生相互冲突的结果同时旨在避免资金被困。

该提案还要求每个包含字节码的 Smart Escrow 都必须设置 CancelAfter 时间。当条件无法满足、交易对手未能履约或代码存在错误时，用户将有一条取回锁定资金的途径。

Ripple 的 Smart Escrow 开发者库已包含涉及公证人审批、凭证校验、预言机数据和 NFT 所有权的示例。这些示例展示了开发者可以测试的规则类型，而 Devnet 则用于检验底层系统能否一致地处理这些规则。

第九次发布更新了规则背后的运行机制

第九次发布重组了网络运行 Smart Escrow 代码的方式。Vadari 表示，WebAssembly 集成已从 C++ 迁移至 Rust，将 gas 计量、错误处理和验证检查统一到单一入口。她的发布说明估计主机函数调用性能提升 30% 至 50%，这一技术指标与构建和测试托管逻辑的开发者密切相关。WebAssembly 本身是一种沙盒化的代码格式，其应用远超 XRP 账本——Polkadot、NEAR 以及多条基于 Cosmos 的链都在其上运行智能合约——而 Rust 是针对该格式最常用的语言之一。

软件库同样发生了变化。开发者被要求弃用已废弃的一体化软件包，转而采用独立的通用库和托管专用库，然后针对新的 Devnet 重新测试其应用。本地编译通过的合约仍需与网络、其交易格式及配套工具协同工作。

这正是此次发布的实际价值：它为团队提供了一个更稳定的环境，用以发现只有在多个基础设施组件协同工作时才会出现的问题。

条件托管可以与自动化支付互补

受控释放规则还可以与 XRP 账本在 XRP 和 RLUSD（Ripple 的美元挂钩稳定币）AI 支付方面的工作形成互补。代理可以准备支付，而 Smart Escrow 则可定义已存入托管的资金在何种情况下允许移动。

这种分工让应用得以将常规步骤自动化，同时不会使资金释放条件变得模糊。钱包、支付请求和托管各自承担不同的角色，当出现问题时更容易定位决策发生在哪个环节。

Smart Escrow 仍需一条通往主网的路径

Smart Escrow 仍是一项草案提案，而非已上线的 XRP 账本功能。正式版本需要经过正式修订——即账本采用协议变更的机制，验证节点表明支持态度，升级只有在获得广泛共识后才会激活——此外还需进一步的实现和安全审查，随后进入主网激活流程。

第九次 Devnet 构建为开发者提供了测试提议规则的更好场所。随着该功能迈向可能的主网路径，其进展将通过成功的迁移、安全发现以及更广泛的 XRPL 社区的反馈来衡量。

本文仅供参考，不构成投资建议。Smart Escrow 仍在开发中，其规范、时间表和通往主网的路径可能发生变化。