Rippleは、XRP Ledgerバージョン3.0.0をリリースし、バリデーターとノードオペレーターに対して混乱を避けるため速やかにアップグレードするよう呼びかけました。これは単なるアップグレードではありません。トークンエスクローに関する根本的な技術的問題を修正するものだからです。
これは、XRPLにおける決済およびスケジュール取引に使用される主要な機能の1つです。エンタープライズアプリケーションの開発に携わる人々は、エスクローを信頼の重要な柱の1つと考えてきました。
こちらも読む:XRPLのQ2、XRP時価総額上昇の中、RLUSDの採用が154%の記録を達成
しかし、エスクローは常にXRPL決済サービスの不可欠な部分でした。長い間、XRPの使用のみをサポートしてきました。しかし、これは企業がXRPL上で独自のトークンを発行する場合、高度な機能を活用することが難しいことを意味していました。
XLS-85トークンエスクローと呼ばれる提案は、IOUや多目的トークンなどの発行資産に対するエスクローサービスを導入しました。
多目的トークンは、トークン化において特に重要です。これらは代替可能トークンと非代替性トークンの組み合わせであり、大量のメタデータも含んでいます。
XRPL開発者は、多目的トークンを高コンプライアンス環境向けのソリューションとして挙げています。これは、外部のスマートコントラクトを使用せずにルールやライフサイクルを含めることができるためです。
オリジナルのトークンエスクロー設計の内部テスターは、送金手数料を含むMPTに関する問題を発見しました。この問題は、エスクロープロセスの完了とトークンのアンロード後に発生しました。
100トークンがアンロックされ、1トークンの送金手数料がある場合、受取人は実際に99トークンを受け取りました。
問題は発行者の会計処理にありました。Ledgerは、発行者のLockedAmountを当初エスクローされた100全体ではなく、99だけ減少させました。したがって、1トークンがロック状態のままでした。最終的に、この小さな問題が蓄積され、ネットワーク上の供給量に不一致をもたらす可能性があります。
XRPLインフラストラクチャを追跡する専門家は、トークンネットワークにおける最小の会計上の不一致の危険性と、それがそのようなネットワークへの信頼をどのように損なう可能性があるかを常に強調してきました。
この問題は、TokenEscrowV1修正案で解決されました。この修正案では、総エスクローロジックが純配信から分離されています。エスクローが完了すると、LockedAmountは以前にロックされた値全体だけ減少します。
送金手数料は独立して処理されるため、純価値のみが供給量に影響します。トークンがロック状態のままになることはなく、総供給量の値は正確に保たれます。
こちらも読む:AnodosによるNext-Gen XRPLウォレットがオンボーディングを簡素化し、ユーザーに報酬を提供


