部分決済(パーシャルペイメント)

XRPLのネイティブな決済機能でありながら、歴史的には取引所統合における周知の攻撃手法の原因ともなってきた機能を解説します。

部分決済とは何か

通常、XRPレジャーの決済は、指定された金額の全額を届けるか、まったく失敗するかのいずれかです。部分決済は(tfPartialPaymentフラグを設定することで有効化される)特定の決済モードであり、代わりに要求された金額よりも少ない金額を届けても成功として扱われるようにします。これは、クロスカレンシー決済のように、利用可能な流動性が要求された全額をサポートできない可能性がある正当なケースで有用であり、決済を完全に失敗させる代わりに、可能な範囲を届けることができます。

なぜこの機能が存在するのか

部分決済がなければ、薄い市場を経由するクロスカレンシー決済は、決済が送信されてから約定するまでの間に流動性がわずかに変化しただけでも完全に失敗する可能性があります。部分決済により、アプリケーションは「現時点で可能な限り届ける」という選択肢を受け入れられるようになり、これは特定の決済ルーティングのユースケースにとって真に有用です。

歴史的な悪用パターン

この柔軟性は、これを慎重に考慮していなかった取引所やサービスに対する、よく知られた攻撃ベクトルとなりました。この悪用パターンはおおよそ次のように機能しました。

攻撃者が、部分決済としてフラグ付けされた取引を使って取引所のアドレスにXRPを入金しますが、実際に送る額よりもはるかに大きい額を要求します。
脆弱な取引所の入金処理システムが、取引の要求済み/意図された金額フィールドを確認します — 実際に届けられたものを反映する**delivered_amount**フィールドではなく — そして、より大きく誤った数値に基づいて顧客のアカウントに入金します。
攻撃者は、実際に入金した額をはるかに超える額を入金されたことになります。

取引所ソフトウェアを構築していない人にとってもこれが重要な理由

この歴史を理解することは、2つの理由で有用な背景知識となります。

これは、ブロックチェーンアプリケーションセキュリティにおけるより広い教訓の具体的な例です。取引の実際に届けられた結果を常に検証すべきであり、送信者が主張するパラメータだけを見てはならないという原則は、XRPLに限らず広く一般化できます。
これは、正当な入金処理システムが、決済の要求金額ではなく、(検証済みのレジャーデータによって直接報告される、攻撃者が制御できない)delivered_amountフィールドを特に確認する理由を説明しています。これは現在、成熟したXRPL統合の取引所やサービス全体で標準的な実践となっている細部です。

現状

これはライブなプロトコルの脆弱性ではなく、既知の、よく理解された統合上の落とし穴です — XRPレジャー自体は設計どおりに正確に動作しています。リスクは完全に、受信側のアプリケーションが取引データをどう解釈するかを選択するかにあります。正しく実装された現代の入金処理システムはdelivered_amountを確認しており、このパターンにさらされることはありません。とはいえ、これはブロックチェーン統合セキュリティに関するより広範な議論において、今も頻繁に引き合いに出される事例研究です — アプリケーションレベル(プロトコルレベルではなく)の他のリスクの分類についてはSmart Contract and Sidechain Risks(英語)を参照してください。