XRP Ledger、条件付きでロック解除される支払いをテスト — Smart Escrow Devnetが第9版リリースに到達
重要ポイント
- •10月5日、RippleXのスタッフソフトウェアエンジニアMayukha Vadariが第9版Smart Escrow Devnetリリースを発表。wasm.devnet.rippletest.netエンドポイントの廃止に伴い、テストはwasm-devnet.dev.ripplex.ioの新しいインフラストラクチャへ移行した。
- •Smart Escrowは、エスクロー作成時に小さなWebAssemblyプログラムを添付するよう設計されており、カスタムの事前定義ルールが満たされた場合にのみロックされた資金を解放できる。
- •第9版リリースではWebAssembly統合がC++からRustに移行され、ガス会計、エラー処理、検証が単一のエントリーポイントに統合され、ホスト関数呼び出しで30%から50%の改善が見込まれる。
- •Smart Escrowコードは、外部呼び出し、ファイル、メモリ、計算に制限のある制限されたサンドボックスで実行されなければならず、バイトコードを含むすべてのエスクローには、ユーザーがロックされた資金を回収できるようCancelAfter時刻を含める必要がある。
- •この機能は引き続きドラフトのXLS-0100提案であり、稼働中のレジャー機能ではない。メインネットへの到達には、正式なバリデータによるアメンドメントと、さらなる実装およびセキュリティレビューが必要となる。

XRP Ledgerで提案されているSmart Escrow機能は、テスト段階が前進した。10月5日、XRPLプログラマビリティを担当するRippleXのスタッフソフトウェアエンジニアであるMayukha Vadariが、第9版Smart Escrow Devnetリリースを発表した。彼女のリリースノートによると、テストネットワークは新しいインフラストラクチャに移行し、廃止されたwasm.devnet.rippletest.netのエンドポイントをwasm-devnet.dev.ripplex.ioに置き換えた。提案されている機能により、レジャー上のエスクロー支払いは、限定的なカスタムルールに従うことが可能になる。
新しいDevnetがSmart Escrowに広範なテスト環境を提供
アドレスの変更は今回のアップデートの一部にすぎない。開発者には、コントラクト、ウォレット、ライブラリ、ノード設定を同一のルールのもとで実行できる共有環境が必要だ。この作業は、ロックされた資金の解放可否をコードが判断する場合に特に重要となる。
Vadari氏は、チームがフレームワークとコードを強化している間、プロジェクトはレビューとテストの段階にあると述べた。Devnetは、Smart Escrowがメインネットでの採用を検討される前に、互換性やセキュリティの問題を発見する場を提供する。
Smart Escrow、ロックされた資金にプログラマブルな条件を追加
XRPLはすでに、シンプルな解放条件を備えたエスクロー支払いをサポートしており、この機能は2017年半からメインネットで提供されている。資金は設定した時間の経過後、または必要な暗号学的フルフィルメントが提供された時に利用可能となる。これらのルールは単純な取り決めには適しているが、アプリケーションによっては、指定された承認者、検証済みのイベント、あるいは複数の条件の組み合わせチェックが必要になる場合がある。
購入者が販売者のためにXRPをロックするケースを考えてみよう。エスクローは指定された公証人が配送を確認した後にのみ解放され、期限が設けられており、確認が行われない場合は購入者が資金を回収できる。Smart Escrowはこうしたケースのために設計されている。エスクロー作成時に小さなWebAssemblyプログラムが添付され、誰かが完了を試みた際に実行される。プログラムは合意されたルールを評価し、解放を進められるかどうかを判断する。
XRP Ledgerへの変更提案は、公開されているXLS(XRP Ledger Standard)提案として文書化されている。XLS-0100 Smart Escrows仕様には、コンプライアンスホールドやマイルストーン支払いから、トークンのベスティング、オークションの仕組み、オラクルベースの条件まで、考えられる用途が列挙されている。いずれのユースケースも同じ核心的な考え方に依拠している。資金を解放するルールは、資金がロックされる前にエスクローに書き込まれるというものである。
制限はネットワークと資金を保護するために設計されている
支払いをめぐってコードを実行するあらゆるシステムには、明確な限界が必要だ。すべてのXRPLバリデータがエスクロー完了時に同じ結果に到達しなければ、ネットワークはレジャーの状態について合意できなくなる。
そのため、Smart Escrowのコードは制限された環境で実行される。外部サービスの自由な呼び出しやファイルへのアクセスはできず、メモリと計算量にも制限が課される。これらの境界により、出来栄えの悪いコントラクトが過剰なリソースを消費したり、バリデータ間で矛盾する結果を生み出したりすることを防ぎ、資金が閉じ込められるのを防ぐことを目的としている。
また提案では、バイトコードを含むすべてのSmart EscrowにCancelAfter時刻を含めることを義務付けている。これにより、条件が満たされない場合、相手方が行動しない場合、またはコードに誤りがある場合に、ユーザーはロックされた資金を回収する手段を得られる。
RippleのSmart Escrow開発者ライブラリには、すでに公証人承認、資格情報チェック、オラクルデータ、NFT所有権に関する例が含まれている。これらの例は開発者がテストできるルールの種類を示しており、Devnetは基盤システムがそれらを一貫して処理するかどうかを明らかにする。
第9版リリース、ルールを支える仕組みを更新
第9版リリースでは、ネットワークがSmart Escrowコードを実行する仕組みが再編成された。Vari氏によると、WebAssembly統合はC++からRustに移行され、ガス会計、エラー処理、検証チェックが単一のエントリーポイントを通じて処理されるようになったという。リリースノートでは、ホスト関数呼び出しで30%から50%の改善が見込まれるとしており、これはエスクローロジックの構築・テストを行う開発者にとって重要な技術的指標である。WebAssembly自体はXRP Ledgerをはるかに超えて利用されているサンドボックス化されたコード形式であり、Polkadot、NEAR、複数のCosmosベースのチェーンがスマートコントラクトに採用しており、Rustはそのターゲット言語として最も一般的なものの一つだ。
ソフトウェアライブラリにも変更が加えられた。開発者は非推奨となったオールインワンパッケージから、共通用途とエスクロー専用に分割されたライブラリへ移行し、新しいDevnetに対してアプリケーションを再テストするよう求められている。ローカルでコンパイルできるコントラクトであっても、ネットワーク、そのトランザクション形式、および周辺ツールと連携して動作する必要がある。
これが今回のリリースの実務上の価値である。複数のインフラストラクチャが連携しなければ現れない問題を発見するための、より安定した環境をチームに提供する。
条件付きエスクローは自動化された支払いを補完する可能性
制御された解放ルールは、Rippleのドル連動ステーブルコインであるXRPとRLUSDでのAI支払いに関するXRP Ledgerの取り組みを補完するものにもなり得る。エージェントが支払いを準備し、Smart Escrowがすでにエスクローに預けられた資金の移動を許可する状況を定義するといった形だ。
この役割分担により、資金解放の条件を曖昧にすることなく、アプリケーションは定型ステップを自動化する余地を得られる。ウォレット、支払い要求、エスクローがそれぞれ異なる役割を担うため、問題が発生した場合にどの時点で判断が行われたかを特定しやすくなる。
Smart Escrowにはまだメインネットへの道が必要
Smart Escrowは依然としてドラフト提案であり、稼働中のXRP Ledger機能ではない。実装版には、正式なアメンドメント(バリデータが支持を示し、広範な合意形成後にのみアップグレードが有効化される、レジャーのプロトコル変更採用の仕組み)に加え、さらなる実装とセキュリティレビュー、そしてメインネット有効化プロセスが必要となる。
第9版Devnetビルドは、開発者が提案されたルールをテストするためのより優れた場所を提供する。その進捗は、移行の成功、セキュリティ上の発見、そして機能がメインネットへの道を進むにつれてのXRPLコミュニティ全体の反応によって測られることになるだろう。
この記事は情報提供のみを目的としたものであり、投資助言を構成するものではない。Smart Escrowは開発中であり、その仕様、スケジュール、メインネットへの道のりは変更される可能性がある。