wip fix links fix 2 links trim and add topics Add checklist, rename sc subtopics Fix internal links Add DEX/AMM Add graphics reorg files reorg/rename Fix blurb Remove old JA files edits per review review changes rename output file name of index files to match the folder name Update output file and parent filenames add reusable links snippet fix broken links Update Ja file Move path.md to same location in i18n folder Revert naming for nft-collections page Rename to match files in En and Ja update links to reflect updated file name Rename nft-auctions under Ja folder and update links throughout Rename nftoken-authorized-minting and update links throughout Fix links Rename the nft-fixed-supply Ja file to match the reorg in English and update links Move nft-reserve-requirements file in Ja and update links Fix some more broken links Fix more broken links by renaming html files back Stablecoin reorg: fix various issues Remove nfts_by_issuer method (unreleased) page Remove redundant parent: attrs from config file Fix syntax highlighting of Authorizing Another Minter js Fix config/frontmatter errors
13 KiB
html, parent, blurb, labels
| html | parent | blurb | labels | ||
|---|---|---|---|---|---|
| paths.html | trust-lines-and-issuing.html | トークンによる支払いは、接続されているユーザーのパスとオーダーブックを通す必要があります。 |
|
パス
XRP Ledgerでは、トークンの支払いが送金元から受取人に届くまでにたどる中間ステップの道筋をパスによって定義します。パスは、XRP Ledgerの分散型取引所のオーダーを介して送金元と受取人を結び付けることで、複数通貨間の支払いを可能にします。また、負債を相殺するような複雑な決済もパスにより可能になります。
XRP Ledgerでは1つのPaymentトランザクションは複数のパスを使用でき、複数のソースの流動性を組み合わせて必要な額を送金することができます。そのため、トランザクションには使用可能なパスをまとめた パスセット が含まれます。パスセットの中のパスでは開始時と終了時には同一通貨が使用される必要があります。
XRPは任意のアドレスに直接送金できるため、XRP間のトランザクションではパスは使用されません。
パスのステップ
パスは、支払いの送金元と受取人を結ぶステップで構成されています。すべてのステップは次のいずれかを行います。
- 同一通貨の別のアドレスを通じたRippling
- オーダーブックでの通貨の取引
別のアドレスを通じたRipplingは、負債を移動するプロセスです。一般的なケースでは、ある当事者に対するイシュアーの債務が削減され、別の当事者に対する債務が増加します。Ripplingは、トラストラインで結ばれているすべてのアドレスの間で発生させることができます。Ripplingのその他の例については、NoRippleフラグについてを参照してください。
通貨取引ステップの場合、パスステップにより変換先の通貨が指定されますが、オーダーブックにはオファーの状態は記録されません。レジャーが検証されるまではトランザクションの正規の順序は最終的ではないため、トランザクションの検証が完了するまでは、トランザクションがどのオファーをとるかは不明です。(各トランザクションは最終レジャーでの実行時に利用可能なオファーの中から最適なオファーをとるため、経験に基づいて推測することができます。)
いずれのタイプのステップでも、中間アドレスでは取得する価値と失う価値はほぼ同等です。トラストラインから同じ通貨の別のトラストラインへ残高がripplingするか、または以前に出されたオーダーに基づいて通貨が交換されます。場合によっては、送金手数料、トラストラインクオリティ、または数値の丸め方が原因で、取得する価値と失われる価値が厳密に同等ではないことがあります。
技術詳細
Pathfinding
rippled APIではPathfindingに使用できるメソッドが2つあります。[ripple_path_findメソッド][]は、1回限りのパスセットの検索を実行します。[path_findメソッド][](WebSocketのみ)は、レジャーが閉鎖するか、またはサーバーがより適切なパスを検出するたびに、フォローアップ応答によって検索を拡大します。
署名時にrippledによりパスが自動的に入力されるようにするには、[signメソッド][]またはsubmitコマンド(署名と送信モード)への要求にbuild_pathフィールドを指定します。ただし、トラブルを回避するために、署名前にPathfindingを個別に実行し、結果を確認することが推奨されます。
注意: rippledは可能な限り低コストのパスを検出するように設計されていますが、常にこのようなパスを検出できるわけではありません。信頼できないrippledインスタンスが改ざんされ、利益目的でこの動作が変更される可能性もあります。パスに沿った支払いの実行にかかる実際のコストは、送信時とトランザクション実行時で異なることがあります。
パスの検出は、新しいレジャーが検証されるたびに数秒ごとに変化する非常に難しい課題であるため、rippledは完全に最適なパスを検出するようには設計されていません。ただし、いくつかの有効なパスを検出し、特定額の送金コストを推定することができます。
暗黙のステップ
規約として、パスのステップのいくつかはPaymentトランザクションのフィールドにより黙示的に示されます。これらのフィールドは、Account(送金元)、Destination(受取人)、Amount(通貨と納入額)、SendMax(通貨と送金額(指定されている場合))です。暗黙のステップは次のとおりです。
- パスの1番目のステップは、トランザクションの
Accountフィールドに定義されるとおり、トランザクションの送信者であると常に黙示されます。 - トランザクションに、そのトランザクションの送信者ではない
issuerが指定されているSendMaxフィールドが含まれている場合、そのイシュアーはパスの2番目のパスとして黙示されます。SendMaxのissuerが送信側アドレス である 場合、パスはその送信側アドレスから始まり、そのアドレスの特定の通貨のトラストラインのいずれかを使用できます。詳細は、SendMaxおよびAmountの特殊な値を参照してください。
- トランザクションの
Amountフィールドに、トランザクションのDestinationとは異なるissuerが指定されている場合、そのイシュアーはパスの最後から2番目のステップであると黙示されます。 - 最後に、トランザクションの
Destinationフィールドに定義されるとおり、パスの最終ステップはトランザクションの受信者であることが常に黙示されます。
デフォルトパス
明示的に指定されたパスの他に、トランザクションは デフォルトパス に沿って実行できます。デフォルトパスは、トランザクションの暗黙のステップを接続する最も簡単な方法です。
デフォルトパスは次のいずれかになります。
- トランザクションで(イシュアーに関係なく)1種類の通貨のみが使用される場合、デフォルトパスでは支払いが、関連するアドレスを通じてRipplingされると想定されます。このパスは、これらのアドレスがトラストラインで接続されている場合にのみ機能します。
SendMaxが省略されているか、またはSendMaxのissuerが送金元の場合、デフォルトパスが機能するためには送金元Accountから宛先Amountのissuerへのトラストラインが必要です。SendMaxとAmountに異なるissuer値が指定されており、そのいずれも送金元または受取人ではない場合、これらの2つのイシュアー間のトラストラインでRipplingが必要となるため、デフォルトパスは有用ではない可能性があります。一般にイシュアーが互いに直接信頼し合うことはお勧めしません。
- 複数通貨間のトランザクションの場合、デフォルトパスは支払元通貨(
SendMaxフィールドで指定)と宛先通貨(Amountフィールドで指定)の間でオーダーブックを使用します。
デフォルトパスを無効にするにはtfNoDirectRippleフラグを使用します。このケースでは、トランザクションに明示的に指定されたパスを使用してトランザクションを実行することだけが可能です。トレーダーはこのオプションを使用して裁定取引を実行できます。
パスの仕様
パスセットは配列です。パスセットの各要素は、個々の パス を表す別の配列です。パスの各要素は、ステップを指定するオブジェクトです。ステップのフィールドを次に示します。
| フィールド | 値 | 説明 |
|---|---|---|
account |
文字列 - アドレス | (省略可) 指定されている場合、このパスステップは指定されたアドレスを通じたRipplingを表します。このステップにcurrencyフィールドまたはissuerフィールドが指定されている場合は、このフィールドを指定しないでください。 |
currency |
文字列 - 通貨コード | (省略可) 指定されている場合、このパスステップはオーダーブックを通じた通貨の変換を表します。指定される通貨は新しい通貨を表します。このステップにaccountフィールドが指定されている場合は、このフィールドを指定しないでください。 |
issuer |
文字列 - アドレス | (省略可) 指定されている場合、このパスステップは通貨の変換を表し、このアドレスは新しい通貨のイシュアーを定義します。XRP以外のcurrencyのステップでこのフィールドが省略されている場合、パスの直前のステップがイシュアーを定義します。currencyが省略され、このフィールドが指定されている場合、イシュアーが異なる同名の通貨間でオーダーブックを使用するパスステップを示します。currencyがXRPの場合は省略する必要があります。このステップにaccountフィールドが指定されている場合は、このフィールドを指定しないでください。 |
type |
整数 | 廃止予定(省略可) 他にどのフィールドが指定されているかを示します。 |
type_hex |
文字列 | 廃止予定: (省略可)typeフィールドの16進数表現です。 |
要約すると、以下のフィールドの組み合わせが有効であり、またオプションでtype、type_hexのいずれかまたは両方を指定できます。
accountのみcurrencyのみcurrencyとissuer(currencyがXRP以外の場合)issuerのみ
パスステップでaccount、currency、issuerの各フィールドを上記以外の方法で指定することは無効です。
パスセットのバイナリシリアル化に使用されるtypeフィールドは、実際には1つの整数上でビット演算により作成されます。ビットの定義は次のとおりです。
| 値(16進数) | 値(10進数) | 説明 |
|---|---|---|
| 0x01 | 1 | アドレスの変更(Rippling):accountフィールドが指定されています。 |
| 0x10 | 16 | 通貨の変更:currencyフィールドが指定されています。 |
| 0x20 | 32 | イシュアーの変更:issuerフィールドが指定されています。 |
関連項目
- コンセプト:
- リファレンス:
- [Paymentトランザクション][]
- [path_findメソッド][](WebSocketのみ)
- [ripple_path_findメソッド][]
{% include '_snippets/rippled-api-links.md' %} {% include '_snippets/tx-type-links.md' %} {% include '_snippets/rippled_versions.md' %}

