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 仍在開發中，其規格、時程與主網部署路徑可能有所變動。