ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-28 07:35:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

move @i18n/ja/concepts to @i18n/ja/docs/concept

Browse Source
This commit is contained in:
tequ
2024-02-26 13:23:32 +09:00
parent 7a868ad9a9
commit b94ee6af06
87 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
@i18n/ja/docs/concepts/transactions/fees.md Normal file
View File

@@ -0,0 +1,35 @@
---
html: fees.html
parent: transactions.html
seo:
description: レジャーを悪用から守る中立的な手数料（誰にも支払われません）や、ユーザーが互いから徴収できる手数料など、XRP Ledgerで許可されている手数料のタイプについて説明します。
labels:
- 手数料
---
# 手数料（曖昧さの回避）
XRP Ledgerは分散型レジャーであり、暗号技術により保護され、サーバーで構成される分散型ピアツーピアネットワークで運用されます。つまり、Rippleを含め誰もネットワークアクセス料を要求できません。
ただしXRP Ledgerのルールには、レジャーを悪用から保護するための中立的な手数料を含む各種手数料が設定されています。この中立的な手数料の受取先はありません。また、XRP Ledgerの内外でユーザーはさまざまな方法で相互に手数料を徴収できます。
## レジャー内部
### 中立的な手数料
_**トランザクションコスト**_（トランザクション手数料とも呼ばれます）は、トランザクションの送信にあたって消却される極わずかな額のXRPです。このコストはネットワークへの負荷に比例して増減するため、ピアツーピアネットワークをスパムから保護します。詳細は、[トランザクションコスト](transaction-cost.md)を参照してください。
_**必要準備金**_ は、アカウントが保有する必要があるXRPの最小額です。これは、アカウントがレジャーで所有するオブジェクトの数に比例して増加します。これにより、ユーザーが不注意または悪意によってレジャーのサイズを増やすことを防ぎます。詳細は、[準備金](../accounts/reserves.md)を参照してください。
### オプションの手数料
_**送金手数料**_ は、イシュアーが発行する通貨を、そのイシュアーがXRP Ledger内の他のアドレスに送金する場合に請求できる手数料であり、そのパーセンテージは任意に設定されます。詳細は、[送金手数料](../tokens/transfer-fees.md)を参照してください。
_**トラストラインクオリティ**_ は、アカウントがトラストラインの残高を額面価格よりも高い価格または低い価格で評価できるようにする設定です。この設定により、手数料が発生するような状況になることがあります。トラストラインクオリティは、トラストラインに関連付けられていないXRPには適用されません。
## レジャー外部
XRP Ledgerには前述の手数料しか組み込まれていませんが、この他にもレジャーに関連した手数料を請求する方法を考案することが可能です。たとえば、一般的に金融機関は、XRP Ledgerへの資金の送金やXRP Ledgerからの資金の受領に関して、手数料を顧客に請求します。
その他にもさまざまな手数料を設定できます。企業はクライアントアプリケーションへのアクセス、XRP Ledger以外のアカウント、取引所サービス（特にXRP Ledgerの分散型取引所内ではなくプライベートマーケットでXRPを購入する場合）、およびその他のさまざまなサービスの管理の手数料を請求できます。金融機関と取引を行う前に、必ず手数料一覧を確認してください。

21
@i18n/ja/docs/concepts/transactions/finality-of-results/canceling-a-transaction.md Normal file
View File

@@ -0,0 +1,21 @@
---
html: canceling-a-transaction.html
parent: finality-of-results.html
seo:
description: 送信済みのトランザクションのキャンセルがいつどのように可能か説明します。
labels:
- トランザクション送信
---
# トランザクションの取消し
XRP Ledgerの重要かつ意図的な機能の1つに、トランザクションが検証済みレジャーに組み込まれると、即時に最終的なトランザクションになるという機能があります。
ただし、検証済みレジャーにまだ記録されていないトランザクションは、無効に設定することで実質的に取り消すことができます。通常は、同じアカウントから同じ`Sequence`値を指定した別のトランザクションを送信することになります。置換トランザクションが何もしないようにしたい場合は、オプションを指定せずに[AccountSetトランザクション][]を送信します。
たとえば、シーケンス番号が11、12、13の3つのトランザクションを送信しようとしたときに、トランザクション11が何らかの理由で失われるか、またはトランザクション11にネットワークに伝達するのに十分な[トランザクションコスト](../transaction-cost.md)がない場合には、オプションを指定せずシーケンス番号11を指定したAccuontSetトランザクションを送信すれば、トランザクション11を取り消せます。このトランザクションは（新しいトランザクション11のトランザクションコストを消却する以外は）何も行いませんが、トランザクション12と13を有効にできます。
この方法により、異なるシーケンス番号のトランザクションの内容が実質的に重複することを防げるため、トランザクション12と13の番号を変更して再送信するよりも望ましい方法です。
つまり、オプションが指定されていないAccountSetトランザクションは標準的な「[no-op](http://en.wikipedia.org/wiki/NOP)」トランザクションです。
{% raw-partial file="/docs/_snippets/common-links.md" /%}

60
@i18n/ja/docs/concepts/transactions/finality-of-results/index.md Normal file
View File

@@ -0,0 +1,60 @@
---
html: finality-of-results.html
parent: transactions.html
seo:
description: トランザクション結果が最終的かつ不変になるタイミングについて説明します。
labels:
- トランザクション送信
- ブロックチェーン
---
# 結果のファイナリティー
トランザクションがコンセンサスレジャーに適用される順序は、[レジャー](../../ledgers/index.md)がクローズされ、そのトランザクションセットが[コンセンサスプロセス](../../consensus-protocol/index.md)によって承認されるまで確定されません。最初に成功したトランザクションはその後で失敗する可能性があり、最初に失敗したトランザクションはその後で成功する可能性があります。さらに、あるラウンドでコンセンサスプロセスによって拒否されたトランザクションは、後のラウンドでコンセンサスに達する可能性があります。
検証済みレジャーには、失敗したトランザクション（`tec`結果コード）だけでなく、成功したトランザクション（`tes`結果コード）も含まれる可能性があります。それ以外の結果のトランザクションはレジャーに含まれません。
結果コードがそれ以外の場合は、結果が最終的なものかどうかを判断するのは困難です。次の表は、トランザクションの結果がいつ確定するかをまとめたものです。この内容は、トランザクション送信からの結果コードに基づいています。
| 結果コード | ファイナリティー |
|:----------------|:-----------------------------------------------------------|
| `tesSUCCESS` | 検証済みレジャーに含まれる場合は確定 |
| すべての`tec`コード | 検証済みレジャーに含まれる場合は確定 |
| すべての`tem`コード | 確定（トランザクションが有効になるようにプロトコルが変更される場合を除く） |
| `tefPAST_SEQ` | 検証済みレジャーに同じシーケンス番号の別のトランザクションが含まれている場合は確定 |
| `tefMAX_LEDGER` | 検証済みレジャーにトランザクションの`LastLedgerSequence`フィールドよりも大きい[レジャーインデックス][レジャーインデックス]があり、検証済みレジャーにそのトランザクションが含まれていない場合は確定 |
他のトランザクション結果は確定でない可能性があります。その場合、トランザクションはその後に成功または失敗する可能性があります（特に、条件の変更によってトランザクションの適用を妨げる原因がなくなった場合）。例えば、まだ存在していないアカウントにXRP以外の通貨を送信しようとしても失敗しますが、別のトランザクションで送信先アカウントを作成するのに十分なXRPを送信すれば成功します。サーバーは、一時的に失敗した署名付きのトランザクションを保存してから、事前に確認せずに後でそれを正常に適用する場合があります。
## 未確定の結果はどのように変更できますか?
最初にトランザクションを送信すると、`rippled`サーバーはそのトランザクションを現在のオープンレジャーに暫定的に適用し、その結果から暫定的な[トランザクションの結果](../../../references/protocol/transactions/transaction-results/transaction-results.md)を返します。ただし、トランザクションの最終結果は、暫定的な結果とは大きく異なる場合があります。考えられる理由を以下に示します。
- トランザクションは、後のレジャーバージョンまで延期されるか、検証済みレジャーに取り込まれない場合があります。ほとんどの場合、XRP Ledgerでは、すべての有効なトランザクションをできるだけ早く処理するという原則に従います。ただし、次のような例外があります。
- 提案されたトランザクションが[コンセンサスラウンド](../../consensus-protocol/index.md)の開始時点で過半数のバリデータに中継されていない場合は、残りのバリデータがトランザクションを取得して有効であることを確認する時間を確保できるように、次のレジャーバージョンまで延期される場合があります。
- アドレスが同じシーケンス番号を使用して2つの異なるトランザクションを送信する場合、それらのトランザクションのうち最大1つが検証されます。そのようなトランザクションが異なるパスのネットワーク経由で中継される場合、サーバーによっては、他の競合するトランザクションが先に過半数のサーバーに到達したために、暫定的に成功したトランザクションが失敗する可能性があります。
- ネットワークをスパムから保護するには、すべてのトランザクションでXRPの[トランザクションコスト](../transaction-cost.md)を消却し、XRP Ledgerピアツーピアネットワーク全体に中継する必要があります。ピアツーピアネットワークの負荷が大きいためにトランザクションコストが増加する場合、暫定的に成功したトランザクションは、コンセンサスを達成するのに十分なサーバーに中継されないか、後で[キューに入れられる](../transaction-queue.md)可能性があります。
- 一時的なインターネットの停止または遅延により、`LastLedgerSequence`フィールドで設定されたトランザクションの指定有効期限内であっても、提案されたトランザクションが正常に中継されない場合があります。（トランザクションに有効期限が設定されていない場合、トランザクションは有効状態を維持し、後で成功する可能性がありますが、独自の方法では望ましくない場合があります。詳細は、[信頼できるトランザクションの送信](../reliable-transaction-submission.md)を参照してください。)
- 上記の要因が2つ以上同時に発生する場合もあります。
- 通常、[トランザクションが決済済みレジャーに適用される順序](../../ledgers/index.md)は、それらのトランザクションが現在のオープンレジャーに一時的に適用された順序とは異なります。そのため、関連するトランザクションに応じて、一時的に成功したトランザクションが失敗したり、一時的に失敗したトランザクションが成功したりする場合があります。以下に例を示します。
- 2つのトランザクションでそれぞれ、同じ[オファー](../../tokens/decentralized-exchange/offers.md)を[分散型取引所](../../tokens/decentralized-exchange/index.md)で完全に使用する場合、どちらか一方が先に成功すると、もう一方は失敗します。それらのトランザクションが適用される順序は変わる可能性があるため、成功したトランザクションが失敗したり、失敗したトランザクションが成功したりする可能性があります。オファーは部分的に実行できるため、成功する可能性もありますが、程度は異なります。
- [分散型取引所](../../tokens/decentralized-exchange/index.md)で[オファー](../../tokens/decentralized-exchange/offers.md)を使用することで[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)は成功したが、別のトランザクションが同じオーダーブックでオファーを使用または作成した場合、クロスカレンシー支払いは仮に実行されたときとは異なる為替レートで成功する場合があります。[Partial Payment](../../payment-types/partial-payments.md)では、別の金額を送金することもできます。
- 送金元に十分な資金がないために一時的に失敗した[Paymentトランザクション][]は、必要な資金を送金する別の取引が正規の順序で先に行われることにより、後で成功する可能性があります。逆も同様です。一時的に成功したトランザクションは、必要な資金を送金するトランザクションが標準的な順序に入れられたものの先に来なかったために失敗する可能性があります。
**ヒント:** 上記の理由により、XRP Ledgerに対してテストを実行しており、同じデータに影響する複数のアカウントがある場合、必ずトランザクション間のレジャーが閉じられるまでお待ちください。[スタンドアロンモード](../../networks-and-servers/rippled-server-modes.md#スタンドアロンモード)のサーバーに対してテストを実行する場合は、[レジャーを手動で閉じる](../../../infrastructure/testing-and-auditing/advance-the-ledger-in-stand-alone-mode.md)必要があります。
## 関連項目
- [トランザクションの結果の確認](look-up-transaction-results.md)
- [トランザクション結果のリファレンス](../../../references/protocol/transactions/transaction-results/transaction-results.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

455
@i18n/ja/docs/concepts/transactions/finality-of-results/look-up-transaction-results.md Normal file
View File

@@ -0,0 +1,455 @@
---
html: look-up-transaction-results.html
parent: finality-of-results.html
seo:
description: 以前に送信したトランザクションの結果を確認します。
labels:
- 支払い
- 開発
---
# トランザクションの結果の確認
XRP Ledgerを効果的に使用するには、[トランザクション](../index.md)の結果を次のように把握することが重要です。トランザクションは成功したか？トランザクションは何を遂行したか？失敗した場合は、なぜか？
XRP Ledgerは共有システムとなっていて、すべてのデータが公開された形で正確に記録され、データはそれぞれ新しい[レジャーバージョン](../../ledgers/index.md)で安全に更新されます。誰もが任意のトランザクションの結果を確認し、[トランザクションメタデータ](../../../references/protocol/transactions/metadata.md)によってその実行内容を確認できます。
このドキュメントでは、トランザクションの結果がもたらされた理由を把握する方法について、詳細に説明します。エンドユーザー向けには、トランザクションの処理内容を表示するとわかりやすいです。例えば、[XRPチャートを使用して、記録されたトランザクションについての説明を英語で参照](https://xrpcharts.ripple.com/#/transactions/)できます。
## 前提条件
これらの手順で説明されているトランザクションの結果を理解するには、以下が必要となります。
- 理解する対象となるトランザクションがわかっている。トランザクションの[識別用ハッシュ][]がわかっていれば、それによりトランザクションを検索できます。また、最近のレジャーで実行されたトランザクションまたは特定のアカウントに最後に影響を及ぼしたトランザクションを確認することもできます。
- 信頼できる情報と、トランザクションの送信日時に関する必要な履歴を提供する`rippled`サーバーにアクセスできる。
- 最近送信したトランザクションの結果を確認する場合、トランザクションの送信時に使用したサーバーがネットワークと同期されていれば、そのサーバーにアクセスできるだけで十分です。
- 古いトランザクションの結果については、[全履歴を記録するサーバー](../../networks-and-servers/ledger-history.md#すべての履歴)を使用できます。
**ヒント:** この他にも、[Data API](../../../references/data-api.md)やエクスポートされた他のデータベースを使用するなど、XRP Ledgerからトランザクションのデータを照会する方法があります。ただし、これらのインターフェイスは正式なものではありません。このドキュメントでは、最も直接的で信頼できる結果を得るために、`rippled` APIを直接使用してデータを確認する方法を説明します。
## 1. トランザクションステータスの取得
トランザクションが成功したか失敗したかを確認するには、2つの問いが必要です。
1. トランザクションが検証済みレジャーに記録されたか。
2. 記録されていた場合、結果としてレジャーの状態はどのように変化したか。
検証済みレジャーにトランザクションが記録されていたかどうかを確認するには、通常、トランザクションが記録されている可能性のあるすべてのレジャーにアクセスする必要があります。最も簡単で確実な方法は、[全履歴を記録するサーバー](../../networks-and-servers/ledger-history.md#すべての履歴)でトランザクションを検索する方法です。[txメソッド][]、[account_txメソッド][]またはその他の`rippled`からのレスポンスを使用します。コンセンサスにより検証されたレジャーバージョンがこのレスポンスに使用されていることを示す`"validated": true`を検索します。
- 結果に`"validated": true`がない場合は、その結果は一時的である可能性があり、トランザクションの結果が最終的なものであるかどうかを知るには、レジャーが検証されるまで待機する必要があります。
- 結果に目的のトランザクションが含まれていない場合、または`txnNotFound`エラーが返される場合は、サーバーにある利用可能な履歴に保存されているどのレジャーにもそのトランザクションはありません。ただし、このことだけでトランザクションが失敗したかどうかを判断できないことがあります。サーバーに保存されていない検証済みレジャーバージョンにトランザクションが記録されている、または今後検証されるレジャーにトランザクションが記録されている場合があるためです。以下を把握することで、トランザクションが記録されるレジャーの範囲を制限することができます。
- トランザクションが記録されている可能性のある最古のレジャー。つまり、**トランザクションを初めて送信した _後に_ 最初に検証されるレジャー**。
- トランザクションが記録されている可能性のある最新のレジャー。つまり、トランザクションの`LastLedgerSequence`フィールドで定義されるレジャー
以下の例では、成功したトランザクションが[txメソッド][]によって返され、検証済みレジャーバージョンに記録されています。わかりやすくするために、JSONレスポンスのフィールドの順序を並べ替え、一部を省略しています。
```json
{
"TransactionType": "AccountSet",
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"Sequence": 376,
"hash": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
... (省略) ...
"meta": {
"AffectedNodes": [
... (省略) ...
],
"TransactionResult": "tesSUCCESS"
},
"ledger_index": 46447423,
"validated": true
}
```
この例では、rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnというアドレスを持つ[アカウント](../../accounts/index.md)が、[シーケンス番号][] 376を使用して、[AccountSetトランザクション][]を送信したことを示しています。トランザクションの[識別用ハッシュ][]は`017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567`で、その[結果](../../../references/protocol/transactions/transaction-results/transaction-results.md)は`tesSUCCESS`です。トランザクションは、検証済みのレジャーバージョン46447423に記録されたため、結果は最終的なものです。
### ケース: 検証済みレジャーに記録されていない
**トランザクションが検証済みレジャーに記録されていない場合は、共有XRP Ledgerの状態には _いかなる_ 影響も及ぼしません。** 今後レジャーに記録されるトランザクションの失敗が[_最終的_](index.md)となる場合、その失敗が将来影響を及ぼすことはありません。
トランザクションの失敗が最終的でない場合は、 _将来の_ 検証済みレジャーに記録される可能性があります。トランザクションを現在のオープンレジャーに適用して得た暫定的な結果から、トランザクションが最終レジャーに及ぼすと思われる影響を事前に確認できます。ただし、実際の結果は[さまざまな要因](index.md#未確定の結果はどのように変更できますか)によって変わる場合があります。
### ケース: 検証済みレジャーに記録されている
トランザクションが検証済みレジャーに記録 _されている_ 場合、[トランザクションメタデータ](../../../references/protocol/transactions/metadata.md)にはトランザクションの処理結果として、レジャーの状態に対して行われたすべての変更を網羅したレポートが含まれます。メタデータの`TransactionResult`フィールドには、以下のような、結果を要約した[トランザクション結果コード](../../../references/protocol/transactions/transaction-results/transaction-results.md)が含まれます。
- コード`tesSUCCESS`は、トランザクションが、おおよそ成功したことを示します。
- `tec`-クラスコードは、トランザクションが失敗したことを示します。このことがレジャーの状態に及ぼす影響は、XRP[トランザクションコスト](../transaction-cost.md)を消却し、場合によっては[有効期限切れのオファー](../../tokens/decentralized-exchange/offers.md#オファーの有効期限)の削除および[Payment Channelの閉鎖](../../payment-types/payment-channels.md#payment-channelのライフサイクル)などのブックキーピングを行うことだけです。
- どのレジャーにもその他のコードは表示されません。
結果コードは、トランザクションの結果の要約にすぎません。トランザクションの実行内容を詳しく理解するには、トランザクションの指示とトランザクションの実行前のレジャーの状態に照らして残りのメタデータを確認する必要があります。
## 2. メタデータの解釈
トランザクションメタデータは、以下に示すフィールドをはじめとして、トランザクションがレジャーに適用された方法を _正確に_ 示します。
{% partial file="/docs/_snippets/tx-metadata-field-table.md" /%}
ほとんどのメタデータは、[`AffectedNodes`配列](../../../references/protocol/transactions/metadata.md#affectednodes)に含まれています。この配列で探す対象は、トランザクションのタイプによって異なります。ほぼすべてのトランザクションが、送金元の[AccountRootオブジェクト][]を変更してXRP[トランザクションコスト](../transaction-cost.md)を消却し、[アカウントのシーケンス番号](../../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)を増やします。
**情報:** このルールの例外として[疑似トランザクション](../../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)があります。このトランザクションは実在するアカウントから送信されないため、AccountRootオブジェクトを変更しません。その他の例外として、AccountRootオブジェクトの`Balance`フィールドを変更せずに、AccountRootオブジェクトを変更するトランザクションがあります。[Free Key Resetトランザクション](../transaction-cost.md#key-resetトランザクション)の場合、送金元のXRP残高は変わりません。トランザクションによって消却される金額と同額のXRPをアカウントが受け取る場合（ただし、このようなことはほとんどありません）、そのアカウントの正味残高は変わりません。（XRPを受領したアカウントに関係なくトランザクションコストはメタデータの別の場所に反映されます。）
以下は、上記のステップ1からのレスポンス全文例です。レジャーに対して行われた変更を把握できるか確認してください。
```json
{
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"Fee": "12",
"Flags": 2147483648,
"LastLedgerSequence": 46447424,
"Sequence": 376,
"SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
"TransactionType": "AccountSet",
"TxnSignature": "30450221009B2910D34527F4EA1A02C375D5C38CF768386ACDE0D17CDB04C564EC819D6A2C022064F419272003AA151BB32424F42FC3DBE060C8835031A4B79B69B0275247D5F4",
"date": 608257201,
"hash": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
"inLedger": 46447423,
"ledger_index": 46447423,
"meta": {
"AffectedNodes": [
{
"ModifiedNode": {
"LedgerEntryType": "AccountRoot",
"LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
"FinalFields": {
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"AccountTxnID": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
"Balance": "396015164",
"Domain": "6D64756F31332E636F6D",
"EmailHash": "98B4375E1D753E5B91627516F6D70977",
"Flags": 8519680,
"MessageKey": "0000000000000000000000070000000300",
"OwnerCount": 9,
"Sequence": 377,
"TransferRate": 4294967295
},
"PreviousFields": {
"AccountTxnID": "E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF",
"Balance": "396015176",
"Sequence": 376
},
"PreviousTxnID": "E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF",
"PreviousTxnLgrSeq": 46447387
}
}
],
"TransactionIndex": 13,
"TransactionResult": "tesSUCCESS"
},
"validated": true
}
```
この[no-opトランザクション](canceling-a-transaction.md)によって行われた _唯一_ の変更は[AccountRootオブジェクト][]の更新で、送金元のアカウントは以下のように表されています。
- `Sequence`値は376から377に増えます。
- このアカウントのXRPの`Balance`は、`396015176`から`396015164`（[XRPのdrop数][]）に変わります。残高から差し引かれた12dropは[トランザクションコスト](../transaction-cost.md)で、このトランザクションの`Fee`フィールドに指定されています。
- このトランザクションが、このアドレスから送信された最新のトランザクションとなったことを反映して[`AccountTxnID`](../../../references/protocol/transactions/common-fields.md#accounttxnid)が変わります。
- このアカウントに影響を及ぼした以前のトランザクションは、レジャーバージョン46447387で実行されたトランザクション`E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF`で、`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドに指定されています。（このことは、アカウントのトランザクション履歴をさかのぼる際に役立つ場合があります。）
**注記:** メタデータには明示的に示されませんが、トランザクションがレジャーオブジェクトを変更すると、必ずそのオブジェクトの`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドが現在のトランザクションの情報で更新されます。同じ送金元の複数のトランザクションが1つのレジャーバージョンに含まれている場合、最初のトランザクション以降の各トランザクションは、これらすべてのトランザクションを記録するレジャーバージョンの[レジャーインデックス](../../../references/protocol/data-types/basic-data-types.md#レジャーインデックス)を値とする`PreviousTxnLgrSeq`を提供します。
rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnのアカウントの`ModifiedNode`エントリーが`AffectedNodes`配列の唯一のオブジェクトであるため、このトランザクションの結果として、このレジャーに対してその他の変更は行われませんでした。
**ヒント:** トランザクションによってXRPが送信または受信される場合、送金元の残高の変動額はトランザクションコストと合算され、`Balance`フィールドの正味金額は1回で変更されます。例えば、1XRP（1,000,000drop）を送信し、トランザクションコストで10drop消却した場合、メタデータには`Balance`が1,000,010（XRPのdrop数）減少したと示されます。
### 汎用的なブックキーピング
ほぼすべてのトランザクションにより、以下のような変更が行われます。
- **シーケンスとトランザクションコストの変更:** 送金元のシーケンス番号を増やし、トランザクションコストの支払いに使用するXRPを消却するために、[前述のとおりどのトランザクション（疑似トランザクションを除く）も、送金元の`AccountRoot`オブジェクトに変更を加えます](#2-メタデータの解釈)。
- **アカウントのスレッド化:** オブジェクトを作成する一部のトランザクションでは、目的の受取人または宛先のアカウントの[AccountRootオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)も変更し、そのアカウントに関連する何らかの要素が変更されたことを示します。このアカウントを「タグ付け」する手法で、オブジェクトの`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドのみを変更します。これにより、これらのフィールドに指定されたトランザクションの「スレッド」を追跡することで、アカウントが保持するアカウントのトランザクション履歴を効率よく検索することができます。
- **ディレクトリーの更新:** レジャーオブジェクトを作成または削除するトランザクションは、多くの場合[DirectoryNodeオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md)を変更して、どのオブジェクトが存在しているかを追跡します。また、トランザクションによって、アカウントの[所有者準備金](../../accounts/reserves.md#所有者準備金)に反映されるオブジェクトが追加されると、所有者の[AccountRootオブジェクト][]の`OwnerCount`が増加します。オブジェクトを削除すると、`OwnerCount`が減少します。
アカウントの`OwnerCount`を増やす例:
```json
{
"ModifiedNode": {
"FinalFields": {
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
"Balance": "9999999990",
"Flags": 0,
"OwnerCount": 1,
"Sequence": 2
},
"LedgerEntryType": "AccountRoot",
"LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
"PreviousFields": {
"Balance": "10000000000",
"OwnerCount": 0,
"Sequence": 1
},
"PreviousTxnID": "B24159F8552C355D35E43623F0E5AD965ADBF034D482421529E2703904E1EC09",
"PreviousTxnLgrSeq": 16154
}
}
```
多くのトランザクションのタイプで、[DirectoryNodeオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md)が作成または変更されます。これらのオブジェクトは、ブックキーピングに使用します。アカウントが所有するすべてのオブジェクト、またはすべてのオファーを追跡して、同じ為替レートで通貨を交換します。トランザクションがレジャーに新しいオブジェクトを作成した場合、トランザクションは既存のDirectoryNodeオブジェクトにエントリーを追加するか、別のDirectoryNodeオブジェクトを追加してディレクトリーの別のページを表さなければならないことがあります。トランザクションがレジャーからオブジェクトを削除した場合、トランザクションは不要となった1つ以上のDirectoryNodeオブジェクトを削除しなければならないことがあります。
新しいオファーディクトリーを表すCreatedNodeの例:
```json
{
"CreatedNode": {
"LedgerEntryType": "DirectoryNode",
"LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
"NewFields": {
"ExchangeRate": "4E11C37937E08000",
"RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
"TakerPaysCurrency": "0000000000000000000000004254430000000000",
"TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
}
}
},
```
トランザクションメタデータを処理する際に探すその他の項目は、トランザクションのタイプによって異なります。
### 支払い
[Paymentトランザクション][]はXRP間の直接トランザクション、[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)、または[（XRP以外の）トークン](../../tokens/index.md)での直接トランザクションを表します。トークンからXRPへのトランザクション、またはXRPからトークンへのトランザクションなど、XRP間の直接トランザクション以外はすべて[partial payment](../../payment-types/partial-payments.md)が可能です。
XRPの額は、`AccountRoot`オブジェクトの`Balance`フィールドで追跡されます。（XRPは[Escrowオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/escrow.md)および[PayChannelオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/paychannel.md)にも存在する可能性がありますが、Paymentトランザクションがそれらに影響を及ぼすことはありません。）
支払いでいくら支払われたかを確認するには、必ず[delivered_amountフィールド](../../payment-types/partial-payments.md#delivered_amountフィールド)を使用する必要があります。
支払いにLedgerEntryTypeが`AccountRoot`の`CreatedNode`が含まれている場合は、その支払いによってレジャーの[新しいアカウントへの資金供給](../../accounts/index.md#アカウントの作成)が行われたことを意味します。
#### トークンでの支払い
トークンを利用する支払いは、多少複雑です。
トークン残高の変更は、[トラストライン](../../tokens/fungible-tokens/index.md)を表す[RippleStateオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)にすべて反映されます。一方の当事者のトラストラインで残高が増加すると、相手側当事者の残高は同じ額だけ減少すると考えられます。このことは、メタデータには、RippleStateオブジェクトの共有`Balance`に対する1回の変更としてのみ記録されます。この変更が「増加」または「減少」のどちらで記録されるかは、どちらのアカウントのアドレスが数値として大きいかによって決まります。
1回の支払いは、複数のトラストラインとオーダーブックで構成される長い[パス](../../tokens/fungible-tokens/paths.md)をたどる場合があります。間接的に当事者間を接続する複数のトラストラインの残高を変更するプロセスを[Rippling](../../tokens/fungible-tokens/rippling.md)と呼びます。トランザクションの`Amount`フィールドに指定された`issuer`に応じて、支払先アカウントに結び付けられている複数のトラストライン（`RippleState`アカウント）で支払額を分割することもできます。
**ヒント:** 変更されたオブジェクトがメタデータに表示される順序は、支払いを処理するときにこれらのオブジェクトにアクセスした順序とは必ずしも一致しません。`AffectedNodes`メンバーを並べ替えて資金がレジャーまでたどったパスを再構成すると、支払いの実行の詳細を把握しやすくなります。
クロスカレンシー支払いでは、[オファー](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)の一部または全額を消費して、通貨コードとイシュアーが異なる通貨間で変更が行われます。トランザクションで`Offer`タイプの`DeletedNode`オブジェクトが示される場合は、全額が消費されたオファーを示しているか、または処理の時点で[期限切れになるか、または資金化されない](../../tokens/decentralized-exchange/offers.md#オファーのライフサイクル)ことがわかったオファーを示している可能性があります。トランザクションで`Offer`タイプの`ModifiedNode`が示される場合は、オファーの一部が消費されたことを示します。
[トラストラインの`QualityIn`および`QualityOut`設定](../../../references/protocol/transactions/types/trustset.md)は、トラストラインの一方の側におけるトークンの金額に影響を与える可能性があるため、残高の数値の変化は、送金元におけるその通貨の額と異なります。`delivered_amount`は、受取人による評価額でいくら送金されたのかを示します。
送金額と受取額が[トークンの精度](../../../references/protocol/data-types/currency-formats.md#トークンの精度)の範囲外である場合は、一方のトランザクションで0に丸められる金額が、他方から引き出される可能性があります。そのため、両当事者が、お互いの残高に10<sup>16</sup>倍の差があるときに取引をすると、丸めることによって少額のトークンが「作成」または「消却」される可能性があります。（XRPは丸められないので、XRPではこの状況は発生しません。）
[パス](../../tokens/fungible-tokens/paths.md)の長さに応じて、クロスカレンシー支払いのメタデータは _長く_ なります。例えば、[トランザクション8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B](https://xrpcharts.ripple.com/#/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B)では、rHaaans...が発行した2.788 GCBを送金しXRPを支払いますが、2人のイシュアーのUSDを経由し、2つのアカウントにXRPを支払います。r9ZoLsJからのEURをETHと交換する資金供給されていないオファーを削除し、変更された合計17の異なるレジャーオブジェクトのブックキーピングを行います。
### オファー
[OfferCreateトランザクション][]では、成立した額や、トランザクションが`tfImmediateOrCancel`などのフラグを使用したかどうかによって、レジャーにオブジェクトが作成される場合と作成されない場合があります。トランザクションがレジャーのオーダーブックに新しいオファーを追加したどうかを確認するには、LedgerEntryTypeが`Offer`の`CreatedNode`エントリーを探します。例:
```json
{
"CreatedNode": {
"LedgerEntryType": "Offer",
"LedgerIndex": "F39B13FA15AD2A345A9613934AB3B5D94828D6457CCBB51E3135B6C44AE4BC83",
"NewFields": {
"Account": "rETSmijMPXT9fnDbLADZnecxgkoJJ6iKUA",
"BookDirectory": "CA462483C85A90DB76D8903681442394D8A5E2D0FFAC259C5B0C59269BFDDB2E",
"Expiration": 608427156,
"Sequence": 1082535,
"TakerGets": {
"currency": "EUR",
"issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
"value": "2157.825"
},
"TakerPays": "7500000000"
}
}
}
```
タイプ`Offer`の`ModifiedNode`は、成立し、かつ一部が消費されたオファーを示します。1つのトランザクションで多数のオファーを消費できます。2種類のトークンを交換するオファーが、[オートブリッジング](../../tokens/decentralized-exchange/autobridging.md)によってXRPを交換するオファーを消費することもあります。両替取引のすべてまたは一部をオートブリッジングできます。
LedgerEntryTypeが`Offer`の`DeletedNode`は、すべて消費された成立オファー、処理の時点で[期限切れになるか、または資金化されない](../../tokens/decentralized-exchange/offers.md#オファーのライフサイクル)ことがわかったオファー、または新しいオファーを発行する過程でキャンセルされたオファーを示すことができます。キャンセルされたオファーは識別できます。これは、キャンセルされたオファーを発行した`Account`は、そのオファーを削除するトランザクションの送信元であるためです。
削除されたオファーの例:
```json
{
"DeletedNode": {
"FinalFields": {
"Account": "rETSmijMPXT9fnDbLADZnecxgkoJJ6iKUA",
"BookDirectory": "CA462483C85A90DB76D8903681442394D8A5E2D0FFAC259C5B0C595EDE3E1EE9",
"BookNode": "0000000000000000",
"Expiration": 608427144,
"Flags": 0,
"OwnerNode": "0000000000000000",
"PreviousTxnID": "0CA50181C1C2A4D45E9745F69B33FA0D34E60D4636562B9D9CDA1D4E2EFD1823",
"PreviousTxnLgrSeq": 46493676,
"Sequence": 1082533,
"TakerGets": {
"currency": "EUR",
"issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
"value": "2157.675"
},
"TakerPays": "7500000000"
},
"LedgerEntryType": "Offer",
"LedgerIndex": "9DC99BF87F22FB957C86EE6D48407201C87FBE623B2F1BC4B950F83752B55E27"
}
}
```
オファーでは、両方のタイプの[DirectoryNodeオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md)を作成、削除、変更して、オファーの発行者と、どのオファーがどのような為替レートで利用可能になっているのかを追跡できます。一般的に、ユーザーがこのブックキーピングに細かな注意を払う必要はありません。
削除するオファーがなかった場合でも、[OfferCancelトランザクション][]には、コード`tesSUCCESS`が含まれる可能性があります。トランザクションが実際にオファーを削除したことを確認するには、LedgerEntryTypeが`Offer`の`DeletedNode`を探します。削除されていなかった場合は、そのオファーは以前のトランザクションによってすでに削除された可能性があります。またはOfferCancelトランザクションで、`OfferSequence`フィールドに誤ったシーケンス番号が使用された可能性があります。
OfferCreateトランザクションが、タイプが`RippleState`の`CreatedNode`を示す場合は、取引で受け取ったトークンを保持するために、[オファーがトラストラインを作成した](../../tokens/decentralized-exchange/offers.md#オファーとトラスト)ことを示しています。
### Escrow
成功した[EscrowCreateトランザクション][]は、レジャーに[Escrowオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/escrow.md)を作成します。LedgerEntryTypeが`Escrow`の`CreatedNode`エントリーを探します。`NewFields`には、escrowに預託されたXRPと同じ`Amount`と、指定したその他のプロパティが示されます。
成功したEscrowCreateトランザクションは、送金元から同じ額のXRPを引き出します。最終的なフィールドの`Account`がトランザクションの指示にある`Account`のアドレスと一致する、LedgerEntryTypeが`AccountRoot`の`ModifiedNode`を探します。XRPの`Balance`は、（トランザクションコストの支払いのためにXRPが消却されたのに加えて）XRPがescrowに預託されたため減少します。
成功した[EscrowFinishトランザクション][]は、受取人の`AccountRoot`を変更して（`Balance`フィールドの）XRP残高を増やし、`Escrow`オブジェクトを削除し、escrow作成者の所有者数を減らします。escrow作成者、受取人および終了者をすべて異なるアカウントにしても、同じアカウントにしてもかまわないため、結果としてLedgerEntryTypeが`AccountRoot`の`ModifiedNode`オブジェクトが _1～3個_ になる可能性があります。XRPがescrowの最初の作成者に返されることを除けば、成功した[EscrowCancelトランザクション][]は極めて類似しています。
EscrowFinishは、escrowの条件を満たす場合にのみ成功し、EscrowCancelはEscrowオブジェクトの期限が前のレジャーの閉鎖時刻よりも前である場合にのみ成功します。
Escrowトランザクションでは、関係する送金元の所有者準備金やアカウントのディレクトリーを調整するために通常の[ブックキーピング](#汎用的なブックキーピング)も行われます。
次に示すコードの抜粋では、r9UUEX...の残高が10億XRP増加し、その所有者の数が1人減少しています。これは、そのアカウントからの自分自身へのescrowが正常に終了したためです。[第三者がescrowを完了した](https://xrpcharts.ripple.com/#/transactions/C4FE7F5643E20E7C761D92A1B8C98320614DD8B8CD8A04CFD990EBC5A39DDEA2)ため`Sequence`番号は変更されません。
```json
{
"ModifiedNode": {
"FinalFields": {
"Account": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
"Balance": "1650000199898000",
"Flags": 1048576,
"OwnerCount": 11,
"Sequence": 23
},
"LedgerEntryType": "AccountRoot",
"LedgerIndex": "13FDBC39E87D9B02F50940F9FDDDBFF825050B05BE7BE09C98FB05E49DD53FCA",
"PreviousFields": {
"Balance": "650000199898000",
"OwnerCount": 12
},
"PreviousTxnID": "D853342BC27D8F548CE4D7CB688A8FECE3229177790453BA80BC79DE9AAC3316",
"PreviousTxnLgrSeq": 41005507
}
},
{
"DeletedNode": {
"FinalFields": {
"Account": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
"Amount": "1000000000000000",
"Destination": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
"FinishAfter": 589075200,
"Flags": 0,
"OwnerNode": "0000000000000000",
"PreviousTxnID": "D5FB1C7D18F931A4FBFA468606220560C17ADF6DE230DA549F4BD11A81F19DFC",
"PreviousTxnLgrSeq": 35059548
},
"LedgerEntryType": "Escrow",
"LedgerIndex": "62F0ABB58C874A443F01CDCCA18B12E6DA69C254D3FB17A8B71CD8C6C68DB74D"
}
},
```
### Payment Channel
Payment Channelの作成時に、LedgerEntryTypeが`PayChannel`の`CreatedNode`を探します。また、送金元の残高の減少を示す、LedgerEntryTypeが`AccountRoot`の`ModifiedNode`も探す必要があります。アドレスが送金元に一致することを確認するために`FinalFields`の`Account`フィールドを探し、XRP残高の変化を確認するために`Balance`フィールドの差異を確認します。
[fixPayChanRecipientOwnerDir Amendment](/resources/known-amendments.md#fixpaychanrecipientownerdir)が有効な場合は、メタデータは宛先のアカウントの[所有者ディレクトリー](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md)を変更して、新しく作成されるPayment Channelをリストで示す必要もあります。これにより、アカウントがオープンPayment Channelの受取人である場合に、そのアカウントが[削除される](../../accounts/deleting-accounts.md)ことを防ぎます。（fixPayChanRecipientOwnerDir Amendmentが有効になる前にPayment Channelが作成された場合は、アカウントを削除できます。）
Payment Channelの閉鎖を要求する方法は、Payment Channelの不変の`CancelAfter`時刻（作成時にのみ設定されます）以外にもいくつかあります。トランザクションでChannelの閉鎖をスケジュールする場合は、そのChannel用にLedgerEntryTypeが`PayChannel`の`ModifiedNode`エントリーがあり、`FinalFields`の`Expiration`フィールドには閉鎖時刻が新たに追加されています。以下の例は、送金元がクレームを清算せずにChannelを閉鎖するよう要求した場合に`PayChannel`に対して行われる変更を示します。
```json
{
"ModifiedNode": {
"FinalFields": {
"Account": "rNn78XpaTXpgLPGNcLwAmrcS8FifRWMWB6",
"Amount": "1000000",
"Balance": "0",
"Destination": "rwWfYsWiKRhYSkLtm3Aad48MMqotjPkU1F",
"Expiration": 608432060,
"Flags": 0,
"OwnerNode": "0000000000000002",
"PublicKey": "EDEACA57575C6824FC844B1DB4BF4AF2B01F3602F6A9AD9CFB8A3E47E2FD23683B",
"SettleDelay": 3600,
"SourceTag": 1613739140
},
"LedgerEntryType": "PayChannel",
"LedgerIndex": "DC99821FAF6345A4A6C41D5BEE402A7EA9198550F08D59512A69BFC069DC9778",
"PreviousFields": {},
"PreviousTxnID": "A9D6469F3CB233795B330CC8A73D08C44B4723EFEE11426FEE8E7CECC611E18E",
"PreviousTxnLgrSeq": 41889092
}
}
```
### TrustSetトランザクション
TrustSetトランザクションは、[`RippleState`オブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)として表される[トラストライン](../../tokens/fungible-tokens/index.md)を作成、変更、または削除します。1つの`RippleState`オブジェクトに、関与する両当事者の設定が含まれます。これには両当事者の制限や[Ripplingの設定](../../tokens/fungible-tokens/rippling.md)などがあります。トラストラインの作成と変更によって[送金元の所有者準備金と所有者ディレクトリーの調整](#汎用的なブックキーピング)も行われます。
以下の例は、**rf1BiG...** が**rsA2Lp...** によって発行されたUSDを最大110 USDまで保持するという新しいトラストラインを示します。
```json
{
"CreatedNode": {
"LedgerEntryType": "RippleState",
"LedgerIndex": "9CA88CDEDFF9252B3DE183CE35B038F57282BC9503CDFA1923EF9A95DF0D6F7B",
"NewFields": {
"Balance": {
"currency": "USD",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
"value": "0"
},
"Flags": 131072,
"HighLimit": {
"currency": "USD",
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"value": "110"
},
"LowLimit": {
"currency": "USD",
"issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"value": "0"
}
}
}
}
```
### その他のトランザクション
その他のほとんどのトランザクションは、特定のタイプのレジャーエントリーを作成し、[送金元の所有者準備金と所有者ディレクトリーの調整](#汎用的なブックキーピング)を行います。
- [AccountSetトランザクション][]は、送金元の既存の[AccountRoot object][]を変更し、指定されたとおりに設定とフラグを変更します。
- [DepositPreauthトランザクション][]は、特定の送金元の[DepositPreauthオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/depositpreauth.md)を追加または削除します。
- [SetRegularKeyトランザクション][]は、送金元の[AccountRootオブジェクト][]を変更し、指定されたとおりに`RegularKey`フィールドを変更します。
- [SignerListSetトランザクション][]は、[SignerListオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)を追加、削除、または置換します。
### 疑似トランザクション
[疑似トランザクション](../../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)にもメタデータがありますが、これらのトランザクションは通常のトランザクションのすべてのルールに従うとは限りません。これらのトランザクションは、実在のアカウントには関連付けられていないため（この`Account`の値は、[base58エンコード形式の数字の0](../../accounts/addresses.md#特別なアドレス)です）、レジャーのAccountRootオブジェクトを変更して`Sequence`シーケンス番号を増やしたり、XRPを消却したりしません。疑似トランザクションは、特別なレジャーオブジェクトに対して特定の変更のみを行います。
- [EnableAmendment疑似トランザクション][]は、[Amendmentレジャーオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/amendments.md)を変更して、有効なAmendment、過半数の支持を得ている保留中のAmendment、および保留中の期間を追跡します。
- [SetFee疑似トランザクション][]は、[FeeSettingsレジャーオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)を変更して、[トランザクションコスト](../transaction-cost.md)および[必要準備金](../../accounts/reserves.md)のベースレベルを変更します。
## 関連項目
- **コンセプト:**
- [結果のファイナリティー](index.md) - トランザクションの成功また失敗が最終的なものとなるタイミングを判断する方法。（簡単な説明: トランザクションが検証済みレジャーにある場合は、その結果とメタデータは最終的なものです。）
- **チュートリアル:**
- [信頼できるトランザクションの送信](../reliable-transaction-submission.md)
- [WebSocketを使用した着信ペイメントの監視](../../../tutorials/http-websocket-apis/monitor-incoming-payments-with-websocket.md)
- **リファレンス:**
- [レジャーオブジェクトタイプのリファレンス](../../../references/protocol/ledger-data/ledger-entry-types/index.md) - レジャーオブジェクトの使用可能なすべてのタイプのフィールド
- [トランザクションのメタデータ](../../../references/protocol/transactions/metadata.md) - メタデータフォーマットとメタデータに表示されるフィールドの概要
- [トランザクションの結果](../../../references/protocol/transactions/transaction-results/transaction-results.md) - トランザクションのすべての結果コードを掲載した表一覧
{% raw-partial file="/docs/_snippets/common-links.md" /%}

149
@i18n/ja/docs/concepts/transactions/finality-of-results/transaction-malleability.md Normal file
View File

@@ -0,0 +1,149 @@
---
html: transaction-malleability.html
parent: finality-of-results.html
seo:
description: トランザクションが想定とは異なるハッシュを持つようにどのように変更される可能性があるか注意してください。
labels:
- セキュリティ
- トランザクション送信
---
# トランザクション展性
署名後のトランザクションを、署名に使用されたキーを使用せずに変更できる場合、そのトランザクションには「展性がある」ことになります。XRP Ledgerでは、署名付きトランザクションの**機能性**は変更できませんが、場合によっては第三者がトランザクションの署名と識別用ハッシュを変更できる _可能性があります_ 。
展性のあるトランザクションは元のハッシュでのみ実行できると想定して、脆弱なソフトウェアが展性のあるトランザクションを送信した場合、トランザクションの状況を把握できなくなる可能性があります。最悪の場合、不正使用者がこの点を悪用して脆弱なシステムから資金を盗むことが可能です。
XRP Ledgerのメインネット上では、**マルチ署名**トランザクションのみが、必要以上の署名がある場合、または承認された署名者が必要以上の追加署名を提供する場合に、変更可能です。優れた運用セキュリティはこれらの問題から保護することができます。ガイドラインについては[マルチシグの展性の緩和対策](#マルチシグの展性の緩和対策)をご覧ください。
2014年以前は、デフォルトの署名アルゴリズムであるsecp256k1曲線を使用したECDSAの特性により、単一署名トランザクションを不正に変更することができました。レガシー署名ツールとの互換性のため、2020-07-03に[RequireFullyCanonicalSig Amendment][]が有効になるまでは、変更可能な単一署名トランザクションを作成して提出することが可能でした。(Ed25519鍵で署名されたトランザクション(cryptographic-keys.html#署名アルゴリズム)は、この問題に対して脆弱ではありませんでした)。
## 背景
XRP Ledgerでは、以下の条件に該当しない場合にはトランザクションを実行できません。
- 署名自体を除く[トランザクションのすべてのフィールド](../../../references/protocol/transactions/common-fields.md)に署名がなされている。
- トランザクションの署名に使用されるキーペアが、[そのアカウントの代理としてトランザクションを送信することが承認されている](../index.md#トランザクションの承認)。
- 署名は _正規_ であり、トランザクションの指示に一致している。
署名付きフィールドに変更を加えると、どれほど小さな変更であっても署名が無効となるため、署名自体を除き、トランザクションのいかなる部分にも展性が生じることはありません。ほとんどの場合、署名自体を変更すると常に署名が無効になりますが、以下で説明するような特定の例外があります。
署名はトランザクションの識別用ハッシュの計算に使用されるデータの1つであるため、展性のあるトランザクションを変更すると、ハッシュ値が変わります。
### 代替secp256k1署名
「正規」であるためには、ECDSAアルゴリズムとsecp256k1曲線（デフォルト）を使用して作成された署名が以下の要件を満たしている必要があります。
- 署名が適切な[DERエンコードデータ](https://en.wikipedia.org/wiki/X.690#DER_encoding)である必要があります。
- 署名ではDERエンコードデータ外部に埋め込みバイトがあってはなりません。
- 署名を構成する整数はマイナスであってはならず、またsecp256k1係数以下でなければなりません。
一般に、あらゆる標準ECDSA実装ではこれらの要件が自動的に処理されます。ただしsecp256k1では、展性を防ぐにはこれらの要件では不十分です。したがってXRP Ledgerでは、同様の問題がない「完全に正規である」署名という概念を採用しています。
ECDSA署名はRおよびSと呼ばれる2つの整数で構成されています。secp256k1係数はNと呼ばれ、すべてのsecp256k1署名の定数です。具体的にはNは値`0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`です。署名`(R,S)`では、署名`(R, N-S)`（Sの位置にN-Sを使用）も有効です。
このように、 _完全に_ 正規である署名を使用する場合には、2つの有効な値のうちどちらを使用するかを選択し、もう一方が無効であることを宣言する必要があります。XRP Ledgerの作成者は、2つの有効な値（`S`と`N-S`）のいずれか _小さい方_ を任意に選択すると決めました。トランザクションが選択された（小さな）値`S`を使用し、正規トランザクションとなるためのすべての標準ルールに準拠している場合、このトランザクションは _完全に正規_ であるとみなされます。
[RequireFullyCanonicalSig Amendment][]（2020年に有効）では、すべてのトランザクションは_完全正規(fully canonical)な_署名のみを使用しなければなりません。
2014年から2020年の間、XRP Ledgerは常に完全な正規署名を生成するわけではないレガシーソフトウェアと互換性がありましたが、トランザクションの脆弱性から互換性のあるソフトウェアを保護するために、トランザクションに[**tfullyCanonicalSig`**](../../../references/protocol/transactions/common-fields.md#global-flags)と呼ばれるフラグを使用していました。このフラグは互換署名ソフトウェアがデフォルトで有効にしており、トランザクションが有効であるために _完全正規な_ 署名を使用することを要求していました。[RequireFullyCanonicalSig Amendment][]が有効になったので、このフラグは必要なくなりましたが、いずれにせよ有効にしても害はありません。
### マルチシグの展性
マルチシグの明示的で重要な機能として、さまざまな設定によってトランザクションを有効にできるという機能があげられます。たとえば、5人の署名者のうち3人の署名者の署名によってトランザクションを承認できるようにアカウントを設定できます。ただしこの場合、有効なトランザクションにはいくつかのバリエーションが存在する可能性があり、識別用ハッシュは各バリエーションごとに異なります。
以下のケースはすべて、トランザクション展性の問題につながる可能性があります。
- トランザクションへの署名を1つ以上を削除しても、まだその定数を満たすのに十分な数の署名がある場合。第三者が署名を削除し、署名なしでトランザクションを再送信できる可能性があります。
- すでに定数に達しているトランザクションに有効な署名を追加できる場合。このような署名を作成できるのは、送信側アカウントの権限のある署名者だけです。
- 定数を維持しながら、あるトランザクションの署名を、別の有効な署名に置き換えることができる場合。このような署名を作成できるのは、送信側アカウントの権限のある署名者だけです。
権限のある署名者に意図的な悪意がない場合でも、混乱や不適切な調整が原因で、複数の署名者が同じトランザクションの異なる有効バージョンを送信することがあります。
#### マルチシグの展性の緩和対策
**適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。** 通常、以下のような適切な運用セキュリティ対策に従っていれば、マルチシグでのトランザクション展性の問題を防ぐことができます。
- 必要な数以上の署名を収集しない。
- 必要な数の署名を収集した後でトランザクションを作成する当事者を任命するか、または署名者が事前に定義された順序でトランザクション指示に署名して次に渡せるように「チェーン」を指定する。
- マルチシグリストに不要な署名者または信頼できない署名者を追加しない。これは、これらの署名者のキーに関連付けられている`weight`の値が、トランザクションの承認には不十分である場合にも該当する。
- トランザクションが異なるハッシュまたは想定外の署名セットを使用して実行される可能性に対処できるよう備える。アカウントから送信されたトランザクションを注意深く監視する（[account_txメソッド][]などを使用）。
- アカウントの`Sequence`番号を監視する（[account_infoメソッド][]などを使用）。この番号は、アカウントがトランザクションを正常に送信するたびに1ずつ増えますが、それ以外の状況で増えることはありません。番号が想定した番号と一致しない場合は、最近のトランザクションを調べてその原因を確認します。（展性のあるトランザクションの他にも、このような状況が発生することがあります。たとえばトランザクションを送信するように別のアプリケーションを設定する場合などです。不正使用者が秘密鍵にアクセスした可能性もあります。あるいは、アプリケーションでデータが失われ、送信済みのトランザクションが忘れられた可能性もあります。）
- トランザクションを再度作成してマルチシグにする場合は、目的の処理がまだ実行されていないことを手動で確認している場合を除き、`Sequence`番号を変更 _しないでください_ 。
- 署名前にtfFullyCanonicalSigフラグが有効であることを確認する。
セキュリティ強化のため、上記のガイドラインにより何重もの保護対策が講じられます。
## 展性のあるトランザクションを使用した悪用
XRP Ledgerとのインフターフェイスに使用するソフトウェアから展性のあるトランザクションが送信されると、不正使用者がソフトウェアをだましてトランザクションの最終結果を確認できなくし、（最悪の場合）同額の支払いを複数回送金させることが可能になります。
シングルシグネチャーを使用していて、tfFullyCanonicalSigフラグを常に有効にしている場合には、このような悪用に対し脆弱ではありません。マルチシグを使用していて、署名者が必要な数を超える署名を提供する場合には脆弱になります。
### 悪用シナリオの流れ
脆弱なシステムを悪用するプロセスは、以下のような順で進みます。
1. 脆弱なシステムが、tfFullyCanonicalSigを有効にせずにトランザクションを生成し署名する。
承認された署名者が悪意のある、あるいは無責任な場合、その署名者の署名が含まれていないにもかかわらず追加される可能性がある場合、そのトランザクションも脆弱になる可能性があります。
2. システムは脆弱なトランザクションの識別用ハッシュを確認し、そのハッシュをXRP Ledgerネットワークに送信し、検証済みレジャーバージョンにそのハッシュが記録されるのを監視し始めます。
3. 不正使用者は、トランザクションが確定する前にそのトランザクションがネットワークを通じて伝搬することを確認します。
4. 不正使用者が脆弱なトランザクションの代替署名を計算します。
異なるトランザクション指示の署名を作成する場合とは異なり、この場合は大量の計算処理は不要です。最初に署名を生成する場合よりもかなり短い時間で完了する可能性があります。
あるいは、その署名がまだトランザクションの一部でない承認された署名者は、脆弱なトランザクションの署名リストに自分の署名を追加することができます。送信者のマルチシグの設定によっては、これはトランザクションから他の署名を削除する代わりに、あるいはそれに加えて行われるかもしれません。
改ざんされた署名により、異なる識別用ハッシュが生成されます。（ネットワークに送信する前にハッシュを計算する必要はありませんが、ハッシュがあれば後でトランザクションのステータスを容易に確認できることを理解しています。）
5. 不正使用者が改ざんした（完全に正規ではない可能性のある）トランザクションをネットワークに送信します。
これにより、当初送信されたトランザクションと、不正使用者によって送信された改ざんバージョンが「競争」します。この2つのトランザクションが同時に記録されることはありません。いずれのトランザクションも有効ですが、`Sequence`番号をはじめ厳密に同一のトランザクションデータを含んでいるので、検証済みレジャーに記録できるのは常にいずれか1つになります。
ピアツーピアネットワークのサーバーは、どちらが「最初に到着した」トランザクションであるか、またはどちらが元の送信者が意図したトランザクションであるかを認識できません。ネットワーク接続での遅延やその他の偶発的な事象により、バリデータはコンセンサス提案をファイナライズする時点で、いずれかのトランザクションだけを認識する結果になる可能性があります。この場合、いずれかのトランザクションが「競争に勝った」ことになります。
もし不正使用者がピアツーピアネットワークで適切に接続しているいくつかのサーバーを乗っ取れば、これらのサーバーがバリデータとして信頼されていなくても、非正規トランザクションを確定できる確率を高めることができます。
脆弱なシステムからのトランザクションを唯一受信したサーバーを不正使用者が乗っ取った場合、不正使用者はネットワークの他の部分に配信されるバージョンを容易に制御できるようになります。
6. 不正ユーザーのトランザクションがコンセンサスに達し、検証済みレジャーに記録されます。
この時点でトランザクションは実行されており、このトランザクションを無効にすることはできません。その影響（XRPの送金など）は最終的です。本来のトランザクションは、その`Sequence`番号がすでに使用されているために有効ではなくなります。
XRP Ledgerでのトランザクションの影響は、本来のバージョンが実行された場合とまったく同じです。
7. 脆弱なシステムは、予期しているトランザクションハッシュを認識せず、トランザクションが実行されなかったという誤った結論に達します。
トランザクションに`LastLedgerSequence`フィールドが含まれている場合は、指定されたレジャーインデックスを経過した後でこの状況が発生します。
トランザクションで`LastLedgerSequence`フィールドが省略されている場合は、別の意味で誤っている可能性があります。つまり、同じ送信者からの他のトランザクションでは同じ`Sequence`番号が使用されていない場合、トランザクションはその後、時間の経過に関係なく、理論上成功します。（詳細は、[確実なトランザクションの送信](../reliable-transaction-submission.md)を参照してください。）
8. 脆弱なシステムは、トランザクションが失敗したと想定してアクションを実行します。
たとえば、XRP Ledgerで送金されていないと判断した資金についての責任を果たすため、システムで顧客の残高に返金します（または単に引き落としを行いません）。
さらに、脆弱なシステムがトランザクションを置き換えるために新しいトランザクションを生成し、ネットワークの現在の状態に基づいて新しい`Sequence`、`LastLedgerSequence`、および`Fee`パラメーターを選択し、その一方でトランザクションの残りの部分は本来のトランザクションと同じ状態で維持することがあります。この新しいトランザクションにも展性がある場合、システムは何度も同じように悪用される可能性があります。
## 関連項目
- **コンセプト:**
- [トランザクション](../index.md)
- [結果のファイナリティー](index.md)
- **チュートリアル:**
- [トランザクションの結果の確認](look-up-transaction-results.md)
- [信頼できるトランザクションの送信](../reliable-transaction-submission.md)
- **リファレンス:**
- [基本的なデータ型 - ハッシュ](../../../references/protocol/data-types/basic-data-types.md#ハッシュ)
- [トランザクションの共通フィールド](../../../references/protocol/transactions/common-fields.md#グローバルフラグ)
- [トランザクションの結果](../../../references/protocol/transactions/transaction-results/transaction-results.md)
- [シリアル化フォーマット](../../../references/protocol/binary-format.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

222
@i18n/ja/docs/concepts/transactions/index.md Normal file
View File

@@ -0,0 +1,222 @@
---
html: transactions.html
parent: concepts.html
seo:
description: トランザクションは、XRP Ledgerの変更を可能にする唯一の手段です。トランザクションの形態とその使用方法について説明します。
labels:
- トランザクション送信
- 支払い
---
# トランザクション
_トランザクション（取引）_ は、XRP Ledgerを変更する唯一の方法です。[コンセンサスプロセス](../consensus-protocol/index.md)に従って署名され、送信され、検証済みのレジャーバージョンに承認された場合にのみ、トランザクションは最終的なものになります。レジャーのルールによっては、_[疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)_ も生成されます。このトランザクションは署名も送信もされませんが、コンセンサスによって承認されなければならないことは同様です。失敗したトランザクションであっても、スパム対策の[トランザクションコスト][]を支払のためXRPの残高が変わるため、レジャーに記録されます。
トランザクションで行えることは、送金だけではありません。XRP Ledgerのトランザクションは、さまざまな[支払いタイプ](../payment-types/index.md)に対応しているだけでなく、[暗号鍵](../accounts/cryptographic-keys.md)のローテーション、その他の設定の管理、およびXRP Ledgerの[分散型取引所](../tokens/decentralized-exchange/index.md)での取引にも使用されます。[トランザクションタイプの詳細なリスト](../../references/protocol/transactions/types/index.md)については、[`rippled` APIリファレンス](../../references/http-websocket-apis/index.md)を参照してください。
### トランザクションの識別 <a id="identifying-transactions"></a>
署名付きトランザクションには、それを識別する固有の`"hash"`があります。トランザクションを送信すると、サーバーのレスポンスでハッシュが返されます。[account_txコマンド](../../references/http-websocket-apis/public-api-methods/account-methods/account_tx.md)を使用して、アカウントのトランザクション履歴でトランザクションを検索することもできます。
だれでも最終的なステータスを確認として[ハッシュによってトランザクションを調べる](finality-of-results/look-up-transaction-results.md)ことができるため、トランザクションハッシュは「支払いの証明」として使用することができます。
{% raw-partial file="/docs/_snippets/setfee_uniqueness_note.md" /%}
## 請求コストの正当化
失敗したトランザクションに対しても[トランザクションコスト](transaction-cost.md)が発生するのは不公平に思えるかもしれませんが、正当な理由から`tec`クラスのエラーが存在します。
* 失敗したトランザクションの後に送信するトランザクションでは、シーケンス値の番号を変更する必要はありません。失敗したトランザクションをレジャーに組み込むと、トランザクションのシーケンス番号が順に使われ予想される順序が保持されます。
* ネットワーク全体にトランザクションを拡散されられると、ネットワークの負荷が増大します。トランザクションコストを強制することにより、攻撃者が失敗したトランザクションでネットワークを乱用することが難しくなります。
* トランザクションコストは実際には非常に少額であるため、大量のトランザクションを送信している場合を除き、ユーザーに害を及ぼすことはありません。
## トランザクションの承認
分散型XRP Ledgerでは、デジタル署名によって、トランザクションが一定のアクションを起こすが承認されていることが証明されます。署名されたトランザクションのみがネットワークに送信され、検証済みレジャーに含まれます。署名付きトランザクションは不変です。その内容は変更できず、他のトランザクションでこの署名を使用することはできません。 <!-- STYLE_OVERRIDE: is authorized to -->
トランザクションは、次のいずれかの署名によって承認できます。
* 送信元アドレスと数学的に関連付けられている、マスター秘密鍵による単一の署名。[AccountSetトランザクション][]を使用して、マスターキーペアを無効または有効にできます。
* アドレスに関連付けられているレギュラー秘密鍵と一致する単一の署名。[SetRegularKeyトランザクション][]を使用して、レギュラーキーペアを追加、削除、または置き換えることができます。
* アドレスが所有する署名者のリストと一致する[マルチシグ](../accounts/multi-signing.md)。[SignerListSetトランザクション][]を使用して、署名者のリストを追加、削除、または置換することができます。
署名の種類に関係なく、あらゆるタイプのトランザクションを承認できます。ただし、次の例外があります。
* マスター秘密鍵だけが[マスター公開鍵](../../references/protocol/transactions/types/accountset.md)を無効にできます。
* マスター秘密鍵だけが[凍結機能を永続的に放棄](../tokens/fungible-tokens/freezes.md#no-freeze)できます。
* アドレスからトランザクションに署名する最後の方法を削除することはできません。
マスターキーとレギュラーキーペアについて詳しくは、[暗号鍵](../accounts/cryptographic-keys.md)を参照してください。
<!--{# Add this reference after signatures concept doc is published. For more information about signatures, see [Understanding Signatures](concept-signatures.html). #}-->
## トランザクションへの署名とトランザクションの送信
XRP Ledgerにトランザクションを送信するには、いくつかの手順を実行する必要があります。
1. [未署名のトランザクションをJSON形式](#未署名のトランザクションの例)で作成します。
2. 1つ以上の署名を使用して[トランザクションを承認](#トランザクションの承認)します。
3. `rippled`サーバーにトランザクションを送信します。トランザクションが適切に作成されている場合、サーバーはそのトランザクションを現行バージョンのレジャーに暫定的に適用し、そのトランザクションをピアツーピアネットワークの他のメンバーに中継します。
4. [コンセンサスプロセス](../consensus-protocol/index.md)によって、次の検証済みレジャーに含まれる暫定的なトランザクションが決定されます。
5. `rippled`サーバーはそれらのトランザクションを正規順序で前のレジャーに適用し、それらの結果を共有します。
6. 十分に[信頼できるバリデータ](../networks-and-servers/rippled-server-modes.md#バリデータ)がまったく同じレジャーを作成した場合、そのレジャーは _検証済み_ であると宣言され、そのレジャーの[トランザクションの結果](../../references/protocol/transactions/transaction-results/transaction-results.md)は不変となります。
XRP決済の送信に関する対話型チュートリアルについては、[Send XRP](../../tutorials/tasks/send-xrp.md)を参照してください。
### 未署名のトランザクションの例
JSON形式の未署名の[Paymentトランザクション][]の例を次に示します。
```json
{
"TransactionType" : "Payment",
"Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
"Amount" : {
"currency" : "USD",
"value" : "1",
"issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
},
"Fee": "12",
"Flags": 2147483648,
"Sequence": 2,
}
```
XRP Ledgerは、トランザクションオブジェクトが送信元アドレス（`Account`内）フィールドによって承認されている場合にのみ、トランザクションを中継して実行します。これを安全に行う方法については、[安全な署名の設定](secure-signing.md)を参照してください。
## 署名付きトランザクションBlobの例
トランザクションに署名すると、ネットワークに送信できるバイナリーBlobが生成されます。この場合、`rippled`の[submitコマンド](../../references/http-websocket-apis/public-api-methods/transaction-methods/submit.md)を使用します。署名付きBlobと同じトランザクションの例を示します。このトランザクションは、WebSocket APIを使用して送信されています。
```json
{
"id": 2,
"command": "submit",
"tx_blob" : "120000240000000461D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000F732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74483046022100982064CDD3F052D22788DB30B52EEA8956A32A51375E72274E417328EBA31E480221008F522C9DB4B0F31E695AA013843958A10DE8F6BA7D6759BEE645F71A7EB240BE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
}
```
## メタデータを含む実行済みトランザクションの例
トランザクションが送信されたら、APIを使用して（例えば、[txコマンド](../../references/http-websocket-apis/public-api-methods/transaction-methods/tx.md)を使用して）トランザクションのステータスを確認できます。これにより、トランザクションの指示、その結果、およびそれを実行する過程で行われたすべての変更の[メタデータ](../../references/protocol/transactions/metadata.md) が表示されます。
**注意:** トランザクションが結果コード`tesSUCCESS`で**検証済み**のレジャーに表示されない限り、トランザクションの成功は確定ではありません。関連項目: [結果のファイナリティー](finality-of-results/index.md)
`tx`コマンドのレスポンスの例:
```json
{
"id": 6,
"status": "success",
"type": "response",
"result": {
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"Amount": {
"currency": "USD",
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"value": "1"
},
"Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
"Fee": "10",
"Flags": 2147483648,
"Sequence": 2,
"SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
"TransactionType": "Payment",
"TxnSignature": "3045022100D64A32A506B86E880480CCB846EFA3F9665C9B11FDCA35D7124F53C486CC1D0402206EC8663308D91C928D1FDA498C3A2F8DD105211B9D90F4ECFD75172BAE733340",
"date": 455224610,
"hash": "33EA42FC7A06F062A7B843AF4DC7C0AB00D6644DFDF4C5D354A87C035813D321",
"inLedger": 7013674,
"ledger_index": 7013674,
"meta": {
"AffectedNodes": [
{
"ModifiedNode": {
"FinalFields": {
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"Balance": "99999980",
"Flags": 0,
"OwnerCount": 0,
"Sequence": 3
},
"LedgerEntryType": "AccountRoot",
"LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
"PreviousFields": {
"Balance": "99999990",
"Sequence": 2
},
"PreviousTxnID": "7BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E",
"PreviousTxnLgrSeq": 6979192
}
},
{
"ModifiedNode": {
"FinalFields": {
"Balance": {
"currency": "USD",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
"value": "2"
},
"Flags": 65536,
"HighLimit": {
"currency": "USD",
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"value": "0"
},
"HighNode": "0000000000000000",
"LowLimit": {
"currency": "USD",
"issuer": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
"value": "100"
},
"LowNode": "0000000000000000"
},
"LedgerEntryType": "RippleState",
"LedgerIndex": "96D2F43BA7AE7193EC59E5E7DDB26A9D786AB1F7C580E030E7D2FF5233DA01E9",
"PreviousFields": {
"Balance": {
"currency": "USD",
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
"value": "1"
}
},
"PreviousTxnID": "7BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E",
"PreviousTxnLgrSeq": 6979192
}
}
],
"TransactionIndex": 0,
"TransactionResult": "tesSUCCESS"
},
"validated": true
}
}
```
## 関連項目
- **コンセプト:**
- [支払いタイプ](../payment-types/index.md)
- **チュートリアル:**
- [安全な署名の設定](secure-signing.md)
- [XRPの送金](../../tutorials/tasks/send-xrp.md)
- [トランザクションの結果の確認](finality-of-results/look-up-transaction-results.md)
- [WebSocketを使用した着信ペイメントの監視](../../tutorials/http-websocket-apis/monitor-incoming-payments-with-websocket.md)
- [トランザクションの取り消しまたはスキップ](finality-of-results/canceling-a-transaction.md)
- [信頼できるトランザクションの送信](reliable-transaction-submission.md)
- **リファレンス:**
- [トランザクションの共通フィールド](../../references/protocol/transactions/common-fields.md)
- [トランザクションのタイプ](../../references/protocol/transactions/types/index.md)
- [トランザクションのメタデータ](../../references/protocol/transactions/metadata.md)
- [account_txメソッド][]
- [txメソッド][]
- [submitメソッド][]
- [submit_multisignedメソッド][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}

528
@i18n/ja/docs/concepts/transactions/reliable-transaction-submission.md Normal file
View File

@@ -0,0 +1,528 @@
---
html: reliable-transaction-submission.html
parent: transactions.html
seo:
description: XRP Ledgerにトランザクションを送信することができるシステムを構築し、最終結果を素早く安全に受け取ります。
labels:
- トランザクション送信
- 開発
---
# 信頼できるトランザクションの送信
XRP Ledgerを使用する金融機関やその他のサービスは、ここで説明するベストプラクティスを使用し、迅速で確認可能な方法で、トランザクションが検証または拒否されるようにする必要があります。信頼できる（ローカルで運営されている）`rippled`サーバーにトランザクションを送信してください。
本書で説明されているベストプラクティスを使用すると、アプリケーションはアーカイブ中にトランザクションをXRP Ledgerに送信できます。
1. [べき等性](https://en.wikipedia.org/wiki/Idempotence) - トランザクションは、一度のみ処理するか、またはまったく処理しないようにします。
2. 検証可能性 - アプリケーションはトランザクションの最終結果を判断できます。
ベストプラクティスを導入しないと、アプリケーションに以下のエラーが発生する可能性があります。
1. 誤って実行されなかったトランザクションを送信する。
2. 暫定的なトランザクションを、最終的で不変の結果として誤判断する。
3. レジャーに以前に適用されたトランザクションの正式な結果を検出できない。
こういったタイプのエラーは、深刻な問題に繋がる可能性があります。例えば、以前のPaymentトランザクションを検出できないアプリケーションは、誤ってトランザクションを再送信してしまい、元の支払いが重複してしまう可能性があります。したがって、本書で説明するテクニックを使用し、アプリケーションが正式なトランザクション結果に基づいてアクションをとることが非常に重要です。
## 背景
XRP Ledgerプロトコルは、ネットワークのすべてのサーバーで共有されるレジャー（台帳）を提供します。[コンセンサスと検証のプロセス](../consensus-protocol/index.md)を通じ、ネットワークはトランザクションがレジャーに適用される（または除外される）順序に同意します。
正しい形式のトランザクションを信頼できるXRP Ledgerサーバーに送信すると、数秒で検証または拒否されます。ただし、正しい形式のトランザクションであっても迅速に検証も拒否もされないことがあります。このような特殊なケースは、アプリケーションがトランザクションを送信した後にグローバル[トランザクションコスト](transaction-cost.md)が増加すると発生することがあります。トランザクションに指定された額よりもトランザクションコストが増加すると、そのトランザクションは次回の検証済みレジャーに含まれません。後日、グローバルトランザクションコストが下がった場合には、そのトランザクションは後のレジャーに含まれます。トランザクションに有効期限が指定されていない場合には、レジャーへの追加はいつになるか分かりません。
電源やネットワークに障害が発生した場合には、送信済みトランザクションのステータスの検出時にさらに多くの問題に直面します。アプリケーションは、トランザクションの適切な送信と、その後の正式結果の適切な受信の両方に十分な注意を払う必要があります。
### トランザクションのタイムライン
XRP Ledgerには、[HTTP / WebSocket API](../../references/http-websocket-apis/index.md)や[クライアントライブラリ](../../references/client-libraries.md)など、トランザクションを送信するためのAPIがいくつかあります。使用するAPIにかかわらず、トランザクションは以下のようにレジャーに適用されます。
1. アカウント所有者は、トランザクションを作成して署名します。
2. 所有者は、トランザクション候補として、そのトランザクションをネットワークに送信します。
- 形式が正しくないトランザクションや無意味なトランザクションはただちに拒否されます。
- 形式が正しいトランザクションは、暫定的に成功し、後で失敗することもあります。
- 形式が正しいトランザクションは、暫定的に失敗し、後で成功することもあります。
- 形式が正しいトランザクションは、暫定的に成功し、後で少々異なった形で成功することもあります。（例えば、別のオファーが使用され、暫定的な結果よりも良い（または悪い）両替レートになることがあります。）
3. コンセンサスと検証を通じ、トランザクションがレジャーに適用されます。ネットワークの伝達のコストを適用するために、一部の失敗したトランザクションも適用されることがあります。
4. 検証されたレジャーにはそのトランザクションが含まれ、その結果がレジャーの状態に反映されます。
- トランザクション結果は暫定的なものではなくなり、成功または失敗の結果は最終的かつ不変のものとなります。
**注記:** `rippled`を介してトランザクションを送信すると、送信コマンドから返される成功ステータスコードによって、`rippled`サーバーがトランザクション候補を受信したことが示されます。このトランザクションは、検証されたレジャーに適用される場合とされない場合があります。
APIは、現在の進行中のレジャーにトランザクション候補を適用した結果に基づいて、暫定的な結果を返すことがあります。アプリケーションでは、この結果を、トランザクションの最終的な*不変の*結果と混同してはなりません。不変の結果は、検証済みのレジャーだけにあります。アプリケーションは、トランザクション結果を含むレジャーが検証されるまで、トランザクションのステータスを繰り返し照会する必要があります。
トランザクションの適用時に、`rippled`サーバーは、*最後に検証されたレジャー*を使用します。これは、すでにネットワーク全体によって検証されたトランザクションに基づくレジャーの状態のスナップショットです。コンセンサスと検証のプロセスは、新しいトランザクションのセットを、最後に検証されたレジャーに正規の順序で適用します。その結果、新しい検証済みレジャーが出来上がります。この新しい検証済みレジャーバージョンとその前のバージョンによって、レジャー履歴が形成されます。
レジャーの各バージョンにはレジャーインデックスが付けられており、前のレジャーバージョンのレジャーインデックスよりも1つ大きい値になります。また、各レジャーには識別用のハッシュ値があります。これは、レジャーの内容から決定される固有の値です。進行中のレジャーには多数のバージョンが存在することがあります。その場合、レジャーインデックスは同じですが、ハッシュ値が異なります。検証できるのは、1つのバージョンのみです。
各検証済みレジャーには、トランザクションが適用される正規の順序があります。この順序は、レジャーの最終的なトランザクションセットに基づいて決定されます。これと異なり、各`rippled`サーバーの進行中のレジャーでは、トランザクションの受信時に増分計算されます。トランザクションを暫定的に実行する順序は、新しい検証済みレジャーを構築するためにトランザクションを実行する順序とは通常異なります。これが、トランザクションの暫定的な結果が最終結果とは異なる可能性がある理由の1つです。例えば、ある支払いが、同じオファーを使用する別の支払いの前と後のどちらで実行されるかによって、最終的な為替レートが異なることがあります。
### LastLedgerSequence
`LastLedgerSequence`は、省略可能な[全トランザクションに適用されるパラメーター](../../references/protocol/transactions/common-fields.md)です。このパラメーターはXRP Ledgerに対して、トランザクションを特定のレジャーバージョンで検証する必要があること、またはトランザクションを特定のレジャーバージョンの前に検証する必要があることを指示します。XRP Ledgerは、レジャーインデックスがトランザクションの`LastLedgerSequence`パラメーターよりも大きいトランザクションをレジャーバージョンに含めることは決してありません。
`LastLedgerSequence`パラメーターを使用すれば、トランザクションが迅速に確認されず、将来のレジャーに含まれるような好ましくないケースを防止できます。`LastLedgerSequence`パラメーターは、各トランザクションに指定する必要があります。自動プロセスでは、最後に検証されたレジャーインデックスよりも4つ大きい数値を使用して、トランザクションが予測可能な方法で、かつ迅速に検証または拒否されるようにします。
トランザクションの送信時に、`LastLedgerSequence`を明示的に指定する必要があります。
## ベストプラクティス
次の図は、トランザクションの送信と結果の判断に推奨されるフローを示します。
[![信頼できるトランザクションの送信フローチャート](/docs/img/reliable-tx-submission.svg)](/docs/img/reliable-tx-submission.svg)
### 信頼できるトランザクションの送信
トランザクションを送信するアプリケーションでは、以下のベストプラクティスを使用し、プロセス終了やその他の問題が発生した場合でも信頼性が高い方法でトランザクションを送信する必要があります。アプリケーションが最終的で検証済みの結果に基づいて処理できるように、アプリケーションのトランザクション結果を確認する必要があります。
送信と確認は別々の異なる手続きであり、本書の説明に基づいてこれを実装することができます。
1. 送信 - トランザクションがネットワークに送信され、暫定的な結果が戻されます。
2. 確認 - 検証済みレジャーを確認し、正式な結果が判断されます。
### 送信
送信が完了する前に電源障害やネットワーク障害が発生する可能性に備え、送信前にトランザクションの詳細を[保持](https://en.wikipedia.org/wiki/Persistence_%28computer_science%29)しておきます。再起動時に、保持された値により、トランザクションのステータスを確認することが可能になります。
送信プロセスは次のとおりです。
1. トランザクションを生成して署名します
- `LastLedgerSequence`パラメーターを指定します
2. 以下を保存して、トランザクション詳細を保持しておきます
- トランザクションハッシュ
- `LastLedgerSequence`
- 送信者のアドレスとシーケンス番号
- 送信時における最新の検証済みレジャーインデックス
- 必要に応じて、アプリケーション固有のデータ
3. トランザクションを送信します
### 確認
通常の操作中に、アプリケーションは、送信されたトランザクションのステータスをハッシュによって確認できます。または、使用するAPIによっては、トランザクションが確認（または拒否）されたときにその通知を受信できます。この通常操作は、ネットワーク障害や電源障害などによって中断されることがあります。そのような中断が発生した場合には、アプリケーションは信頼性の高い方法で、中断前にネットワークに送信された（または送信されなかった）可能性のあるトランザクションのステータスを確認する必要があります。
再起動時、または最新の検証済みレジャーの確認時の例を示します（擬似コード）:
```
For each persisted transaction without validated result:
Query transaction by hash
If (result appears in any validated ledger)
# Outcome is final
Persist the final result
If (result code is tesSUCCESS)
Application may act based on successful transaction
Else
The transaction failed (1)
If appropriate for the application and failure type, submit with
new LastLedgerSequence and Fee
Else if (LastLedgerSequence > newest validated ledger)
# Outcome is not yet final
Wait for more ledgers to be validated
Else
If (server has continuous ledger history from the ledger when the
transaction was submitted up to and including the ledger
identified by LastLedgerSequence)
# Sanity check
If (sender account sequence > transaction sequence)
A different transaction with this sequence has a final outcome.
Manual intervention suggested (3)
Else
The transaction failed (2)
Else
# Outcome is final, but not known due to a ledger gap
Wait to acquire continuous ledger history
```
#### 失敗のケース
2つのトランザクション失敗のケース（疑似コードの（1）と（2））の間の違いは、トランザクションが検証されたレジャーに含まれていたかどうかです。いずれのケースにおいても、失敗の処理には十分な注意が必要です。
- 失敗のケース（1）では、トランザクションはレジャーに含まれ、[XRPトランザクションコスト](transaction-cost.md)は消却されましたが、それ以外には何も起こりませんでした。この原因としては、流動性の欠如、適切でない[パス](../tokens/fungible-tokens/paths.md)、またはその他の状況が考えられます。多くの場合、このような失敗の場合には、同様のトランザクションをすぐに試すと同じ結果が出ることが多いです。状況が変わるのを待ってから送信すると、別の結果が得られることがあります。
- 失敗のケース（2）では、トランザクションは検証済みレジャーには含まれないため、何も起こらず、トランザクションコストも消却されませんでした。これは、XRP Ledgerの現在の負荷に対してトランザクションコストが低すぎる、`LastLedgerSequence`が早すぎる、または不安定なネットワーク接続などの状況が原因である可能性があります。
- 失敗のケース（1）と異なり、このケースでは`LastLedgerSequence`のみを変更（または`Fee`も変更）するだけで、新しいトランザクションが成功する可能性があります。元のトランザクションと同じ`Sequence`番号を使用します。
- また、トランザクションが成功しないのはレジャーのステータスが原因である可能性もあります。例えば、トランザクションに署名するために使用されたキーペアが送信アドレスで無効になっている場合などです。トランザクションの暫定的な結果が[`tef`-class code](../../references/protocol/transactions/transaction-results/tef-codes.md)の場合には、修正をしない限りそのトランザクションが成功する可能性は低くなります。
- 失敗のケース（3）は、予期しない状態を表します。トランザクションが未処理の場合、最新の検証済みレジャーにある送信元アカウントの`Sequence`番号を確認する必要があります。（[account_infoメソッド][]を使用して確認できます。）最新の検証済みレジャーにあるアカウントの`Sequence`値がトランザクションの`Sequence`値より大きい場合、同じ`Sequence`値を持つ別のトランザクションが検証済みレジャーに含まれています。システムがこの別のトランザクションを認識していない場合、予期しない状態となり、その原因が特定されるまで処理を停止しなければならなくなります。そうしないと、システムが同じ目標を達成するために複数のトランザクションを送信する可能性があります。行う必要のある手順は、具体的な原因によって変わります。考えられる原因と手順は次のとおりです。
- 前回送信したトランザクションに[展性](finality-of-results/transaction-malleability.md)があり、実際に検証済みレジャーに含まれていたが、予想と異なるハッシュだった場合。この問題は、`tfFullyCanonicalSig`フラグが含まれないフラグのセットを指定した場合か、必要以上の署名者によってマルチシグされたトランザクションであった場合に起こる可能性があります。これに該当する場合は、その異なるハッシュとトランザクションの最終結果を保存し、通常のアクティビティーを再開します。
- トランザクションを[キャンセル](finality-of-results/canceling-a-transaction.md)して置き換えたため、置き換え後のトランザクションが代わりに処理された場合。障害から復旧しようとしている場合、置き換え後のトランザクションでレコードが失われている可能性があります。その場合、当初確認していたトランザクションは恒久的に失敗し、置き換え後のトランザクションの最終結果が検証済みレジャーバージョンに記録されます。両方の最終結果を保存し、他に欠落したトランザクションや置き換えられたトランザクションがないか確認してから、通常のアクティビティーを再開します。
- アクティブ/パッシブフェイルオーバー構成で、トランザクション送信側のシステムが2台以上あり、パッシブシステムがアクティブシステムで障害が発生したと誤って認識してアクティブになったが、元のアクティブシステムも引き続きトランザクションを送信していた場合。システム間の接続をチェックして、そのうちの1台だけがアクティブであることを確認します。アカウントのトランザクション履歴を確認し（[account_txメソッド][]を使用するなど）、検証済みレジャーに含まれていたすべてのトランザクションの最終結果を記録します。`Sequence`番号が同じ別のトランザクションはすべて完全に失敗しています。それらの最終結果も保存します。すべてのシステムの差異の調整を行い、システムが同時にアクティブになった原因となる問題を解決したら、通常のアクティビティーを再開します。
**ヒント:** [`AccountTxnID`フィールド](../../references/protocol/transactions/common-fields.md#accounttxnid)を使用すると、このような状況で冗長的なトランザクションが成功しないように防ぐことができます。
- 不正使用者に秘密鍵を使われてトランザクションを送信された場合。その場合は、可能であれば[キーペアをローテーション](../../tutorials/tasks/manage-account-settings/change-or-remove-a-regular-key-pair.md)して、送信された他のトランザクションを確認します。また、ネットワークを監査して、その秘密鍵が大規模な侵入やセキュリティ侵害に関係していたかどうかを判断する必要があります。キーペアのローテーションに成功して、不正使用者がアカウントやシステムにアクセスできなくなったら、通常のアクティビティーを再開します。
#### レジャーのギャップ
サーバーに、トランザクションが最初に送信されてから、レジャーが`LastLedgerSequence`によって識別された時点までを含む、継続したレジャー履歴がない場合には、トランザクションの最終結果を得られない可能性があります。（サーバーにないレジャーバージョンに結果が含まれている場合、成功したか失敗したかが分かりません。）
`rippled`サーバーにリソース（CPU/RAM/ディスクIO）の余裕がある場合には、不足しているレジャーバージョンを自動的に取得します。ただし、取得しようとするレジャーが[保管する履歴の設定期間](../networks-and-servers/ledger-history.md)よりも古い場合には取得されません。ギャップのサイズや、サーバーのリソース使用率に基づき、不足しているレジャーバージョンの取得には数分かかります。[ledger_requestメソッド][]を使用して、履歴レジャーバージョンを取得するようにサーバーにリクエストできます。しかし、そうしても、サーバーに設定された履歴範囲外のレジャーバージョンからのトランザクション結果は検索できない場合があります。
あるいは、`s2.ripple.com`にあるRippleの完全履歴サーバーなど、必要なレジャー履歴を含む別の`rippled`サーバーを使用して、トランザクションのステータスを検索することもできます。この目的には、信頼できるサーバーのみを使用してください。不正なサーバーは、トランザクションのステータスや結果について偽の情報を提供するようにプログラムされている可能性があります。
## 技術的応用
トランザクションの送信および確認のベストプラクティスを実施するには、アプリケーションで以下を実行する必要があります。
1. 署名するアカウントの次のシーケンス番号を判断します
* 各トランザクションにはアカウント固有の[シーケンス番号](../../references/protocol/data-types/basic-data-types.md#アカウントシーケンス)があります。これにより、アカウントによって署名されたトランザクションの実行順序が保証され、再送信しても同じトランザクションがレジャーに二重に適用されることがなくなります。
2. `LastLedgerSequence`を決定します
* トランザクションの`LastLedgerSequence`は、最後の検証済みレジャーインデックスから計算されます。
3. トランザクションを生成して署名します
* 送信前に、署名されたトランザクションの詳細を保持します。
4. トランザクションを送信します
* 初期の結果は暫定的なものであり、変化する可能性があります。
5. トランザクションの最終結果を判断します
* 最終結果は、レジャー履歴における不変部分です。
アプリケーションでのこれらのアクションの実行方法は、アプリケーションが使用するAPIによって異なります。アプリケーションでは、以下のインターフェイスを使用できます。
1. [HTTP / WebSocket API](../../references/http-websocket-apis/index.md)
2. [クライアントライブラリ](../../references/client-libraries.md)
3. 任意の数の他のソフトウェアAPI
### rippled - トランザクションの送信と確認
#### アカウントシーケンスの判断
`rippled`には、最後に検証されたレジャーでのアカウントのシーケンス番号を知るための[account_infoメソッド][]があります。
JSON-RPCリクエスト:
```json
{
"method": "account_info",
"params": [
{
"account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
"ledger_index": "validated"
}
]
}
```
レスポンスの本文:
```json
{
"result": {
"validated": true,
"status": "success",
"ledger_index": 10266396,
"account_data": {
"index": "96AB97A1BBC37F4F8A22CE28109E0D39D709689BDF412FE8EDAFB57A55E37F38",
"Sequence": 4,
"PreviousTxnLgrSeq": 9905632,
"PreviousTxnID": "CAEE0E34B3DB50A7A0CA486E3A236513531DE9E52EAC47CE4C26332CC847DE26",
"OwnerCount": 2,
"LedgerEntryType": "AccountRoot",
"Flags": 0,
"Balance": "49975988",
"Account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W"
}
}
}
```
この例では、最後に検証されたレジャーの時点において（リクエストの`"ledger_index": "validated"`と、レスポンスの`"validated": "true"`を参照）、アカウントのシーケンスは**4**です（`"account_data"`の`"Sequence": 4`を参照）。
アプリケーションが、このアカウントで署名された3つのトランザクションを送信する場合には、4、5、6のシーケンス番号を使用します。各トランザクションの検証を待たずに複数のトランザクションを送信するには、アプリケーションで継続的なアカウントシーケンス番号を使用します。
#### 最後に検証されたレジャーの判断
[server_stateメソッド][]は、最後に検証されたレジャーのレジャーインデックスを返します。
リクエスト:
```json
{
"id": "client id 1",
"method": "server_state"
}
```
レスポンス:
```json
{
"result": {
"status": "success",
"state": {
"validation_quorum": 3,
"validated_ledger": {
"seq": 10268596,
"reserve_inc": 5000000,
"reserve_base": 20000000,
"hash": "0E0901DA980251B8A4CCA17AB4CA6C3168FE83FA1D3F781AFC5B9B097FD209EF",
"close_time": 470798600,
"base_fee": 10
},
"server_state": "full",
"published_ledger": 10268596,
"pubkey_node": "n9LGg37Ya2SS9TdJ4XEuictrJmHaicdgTKiPJYi8QRSdvQd3xMnK",
"peers": 58,
"load_factor": 256000,
"load_base": 256,
"last_close": {
"proposers": 5,
"converge_time": 3004
},
"io_latency_ms": 2,
"fetch_pack": 10121,
"complete_ledgers": "10256331-10256382,10256412-10268596",
"build_version": "0.26.4-sp3-private"
}
}
}
```
この例では、最後の検証済みレジャーインデックスは10268596（レスポンスの`result.state.validated_ledger`の下）です。この例では、レジャー履歴にギャップがあることも示されています。ここで使用されたサーバーは、ギャップの間（レジャー10256383から10256411）に適用されたトランザクションに関する情報を提供することはできません。その部分のレジャー履歴を取得するよう設定されていれば、最終的にサーバーで取得できます。
#### トランザクションの生成
`rippled`には、トランザクション送信に備えて準備するための[signメソッド][]があります。このメソッドは信頼できる`rippled`インスタンスにのみに渡すことができるアカウントの機密情報を必要とします。この例では、10 FOO（架空の通貨）を別のXRP Ledgerアドレスに発行します。
リクエスト:
```json
{
"method": "sign",
"params": [
{
"offline": true,
"secret": "s████████████████████████████",
"tx_json": {
"Account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
"Sequence": 4,
"LastLedgerSequence": 10268600,
"Fee": "10000",
"Amount": {
"currency": "FOO",
"issuer": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
"value": "10"
},
"Destination": "rawz2WQ8i9FdTHp4KSNpBdyxgFqNpKe8fM",
"TransactionType": "Payment"
}
}
]
}
```
アプリケーションは、`tefPAST_SEQ`エラーを防ぐため、`account_info`への以前の呼び出しで判明した`"Sequence": 4`を使用しています。
また、アプリケーションが`server_state`から取得した最後の検証済みレジャーに基づく`LastLedgerSequence`にも注意してください。バックエンドアプリケーションでは、*「最後の検証済みレジャーインデックス + 4」*を使用することをお勧めします。または、*「現行のレジャー + 3」*の値を使用します。`LastLedgerSequence`の計算が誤りで、最後の検証済みレジャーの番号よりも小さい場合には、そのトランザクションは`tefMAX_LEDGER`エラーで失敗します。
レスポンス:
```json
{
"result": {
"tx_json": {
"hash": "395C313F6F11F70FEBAF3785529A6D6DE3F44C7AF679515A7EAE22B30146DE57",
"TxnSignature": "304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C753",
"TransactionType": "Payment",
"SigningPubKey": "0267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC5",
"Sequence": 4,
"LastLedgerSequence": 10268600,
"Flags": 2147483648,
"Fee": "10000",
"Destination": "rawz2WQ8i9FdTHp4KSNpBdyxgFqNpKe8fM",
"Amount": {
"value": "10",
"issuer": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
"currency": "FOO"
},
"Account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W"
},
"tx_blob": "12000022800000002400000004201B009CAFB861D4C38D7EA4C68000000000000000000000000000464F4F0000000000AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A68400000000000271073210267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC57446304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C7538114AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A831438BC6F9F5A6F6C4E474DB0D59892E90C2C7CED5C",
"status": "success"
}
}
```
トランザクションを送信する前に、アプリケーションでトランザクションのハッシュを保持しておきます。`sign`メソッドの結果の`tx_json`の下にハッシュが含まれます。
#### トランザクションの送信
`rippled`には、署名されたトランザクションの送信を可能にする、[submitメソッド][]があります。これは、`sign`メソッドで返された`tx_blob`パラメーターを使用します。
リクエスト:
```json
{
"method": "submit",
"params": [
{
"tx_blob": "12000022800000002400000004201B009CAFB861D4C38D7EA4C68000000000000000000000000000464F4F0000000000AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A68400000000000271073210267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC57446304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C7538114AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A831438BC6F9F5A6F6C4E474DB0D59892E90C2C7CED5C"
}
]
}
```
レスポンス:
```json
{
"result": {
"tx_json": {
"hash": "395C313F6F11F70FEBAF3785529A6D6DE3F44C7AF679515A7EAE22B30146DE57",
"TxnSignature": "304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C753",
"TransactionType": "Payment",
"SigningPubKey": "0267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC5",
"Sequence": 4,
"LastLedgerSequence": 10268600,
"Flags": 2147483648,
"Fee": "10000",
"Destination": "rawz2WQ8i9FdTHp4KSNpBdyxgFqNpKe8fM",
"Amount": {
"value": "10",
"issuer": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
"currency": "FOO"
},
"Account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W"
},
"tx_blob": "12000022800000002400000004201B009CAFB861D4C38D7EA4C68000000000000000000000000000464F4F0000000000AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A68400000000000271073210267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC57446304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C7538114AC5FA3BB28A09BD2EC1AE0EED2315060E83D796A831438BC6F9F5A6F6C4E474DB0D59892E90C2C7CED5C",
"status": "success",
"engine_result_message": "The transaction was applied.",
"engine_result_code": 0,
"engine_result": "tesSUCCESS"
}
}
```
これは**初期**結果です。最終結果は検証済みのレジャーのみにあります。`"validated": true`フィールドがないことが、これが**不変の結果ではない**ことを示しています。
#### トランザクションの確認
トランザクションの結果を取得するために、トランザクションが署名された時に生成されるトランザクションハッシュが[txメソッド][]に渡されます。
リクエスト:
```json
{
"method": "tx",
"params": [
{
"transaction": "395C313F6F11F70FEBAF3785529A6D6DE3F44C7AF679515A7EAE22B30146DE57",
"binary": false
}
]
}
```
レスポンス:
```json
{
"result": {
"validated": true,
"status": "success",
"meta": {
"TransactionResult": "tesSUCCESS",
"TransactionIndex": 2,
"AffectedNodes": [...]
},
"ledger_index": 10268599[d],
"inLedger": 10268599,
"hash": "395C313F6F11F70FEBAF3785529A6D6DE3F44C7AF679515A7EAE22B30146DE57",
"date": 470798270,
"TxnSignature": "304402202646962A21EC0516FCE62DC9280F79E7265778C571E9410D795E67BB72A2D8E402202FF4AF7B2E2160F5BCA93011CB548014626CAC7FCBEBDB81FE8193CEFF69C753",
"TransactionType": "Payment",
"SigningPubKey": "0267268EE0DDDEE6A862C9FF9DDAF898CF17060A673AF771B565AA2F4AE24E3FC5",
"Sequence": 4,
"LastLedgerSequence": 10268600,
"Flags": 2147483648,
"Fee": "10000",
"Destination": "rawz2WQ8i9FdTHp4KSNpBdyxgFqNpKe8fM",
"Amount": {
"value": "10",
"issuer": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W",
"currency": "FOO"
},
"Account": "rG5Ro9e3uGEZVCh3zu5gB9ydKUskCs221W"
}
}
```
このレスポンス例には、`"validated": true`があります。これは、トランザクションが検証済みレジャーに含まれていること、つまりトランザクション結果が不変であることを示しています。さらに、メタデータには、トランザクションがレジャーに適用されたことを示す`"TransactionResult": "tesSUCCESS"`が含まれています。
レスポンスに`"validated": true`が含まれていない場合には、結果は暫定的であり変化する可能性があります。最終結果を取得するには、アプリケーションで`tx`メソッドを再度呼び出し、ネットワークでさらに多くのレジャーバージョンを検証できるよう十分な時間をかけます。`LastLedgerSequence`で指定されたレジャーが検証されるまで待たなければならない場合もありますが、そのトランザクションが以前の検証済みレジャーに含まれている場合には、その結果はその時点で不変です。
#### 不明のトランザクションの確認
[txメソッド][]への呼び出しに`txnNotFound`エラーが返された場合には、アプリケーションで対処する必要があります。
```json
{
"result": {
"status": "error",
"request": {
"transaction": "395C313F6F11F70FEBAF3785529A6D6DE3F44C7AF679515A7EAE22B30146DE56",
"command": "tx",
"binary": false
},
"error_message": "Transaction not found.",
"error_code": 24,
"error": "txnNotFound"
}
}
```
`txnNotFound`結果コードは、トランザクションがどのレジャーにも含まれていない場合に発生します。ただし、`rippled`インスタンスに完全なレジャー履歴がない場合や、そのトランザクションが`rippled`インスタンスにまだ伝達されていない場合にも発生します。これにどのように対処すべきかを判断するため、アプリケーションはさらに照会を行う必要があります。
[server_stateメソッド][]（最後の検証済みレジャーを判断するために先に使用する）は、`result.state.complete_ledgers`のもとにレジャー履歴が完全かどうかを示します。
```json
{
"result": {
"status": "success",
"state": {
"validation_quorum": 3,
"validated_ledger": {
"seq": 10269447,
"reserve_inc": 5000000,
"reserve_base": 20000000,
"hash": "D05C7ECC66DD6F4FEA3A6394F209EB5D6824A76C16438F562A1749CCCE7EAFC2",
"close_time": 470802340,
"base_fee": 10
},
"server_state": "full",
"pubkey_node": "n9LJ5eCNjeUXQpNXHCcLv9PQ8LMFYy4W8R1BdVNcpjc1oDwe6XZF",
"peers": 84,
"load_factor": 256000,
"load_base": 256,
"last_close": {
"proposers": 5,
"converge_time": 2002
},
"io_latency_ms": 1,
"complete_ledgers": "10256331-10256382,10256412-10269447",
"build_version": "0.26.4-sp3-private"
}
}
}
```
このトランザクションの例では、その時点の最後の検証済みレジャーに基づいて`LastLedgerSequence` 10268600を指定し、4を足します。不明のトランザクションが完全に失敗したかどうかを判断するには、`rippled`サーバーに、10268597から10268600のレジャーが必要です。サーバーの履歴にそれらの検証済みレジャーが存在し、**かつ**`tx`が`txnNotFound`が返される場合には、そのトランザクションは失敗であり、今後のレジャーに含めることはできません。この場合、アプリケーションのロジックで、同じアカウントシーケンスと更新された`LastLedgerSequence`を使用して代わりのトランザクションを作成して送信することが可能です。
サーバーは、指定された`LastLedgerSequence`よりも小さい値の最後の検証済みレジャーインデックスをレポートする場合があります。その場合、`txnNotFound`に、（a）送信されたトランザクションがまだネットワークに配布されていないこと、または（b）トランザクションがネットワークに配布されたものの、まだ処理されていないことを示します。最初のケースに対処するために、アプリケーションは再度同じ署名済みのトランザクションを送信できます。トランザクションには固有のアカウントシーケンス番号がつけられているため、処理されるのは一度のみです。
最後に、サーバーにトランザクション履歴のギャップが1つ以上存在する場合があります。上記のレスポンスに示される`completed_ledgers`フィールドは、このrippledインスタンスの10256383から10256411のレジャーが不足していることを示しています。このトランザクションの例では、（トランザクションの送信時点と`LastLedgerSequence`に基づいて）トランザクションは10268597から10268600のレジャーのみに含まれるため、このギャップはここでは関係ありません。ただし、必要範囲のレジャーが不足している場合には、`txnNotFound`の結果が不変の結果であるかどうかを判断するために、アプリケーションは別のrippledサーバーに照会する（またはこのサーバーによって不足しているレジャーが取得されるまで待つ）必要があります。
## その他のリソース
- [トランザクションのフォーマット](../../references/protocol/transactions/index.md)
- [トランザクションコスト](transaction-cost.md)
- [トランザクション展性](finality-of-results/transaction-malleability.md)
- [XRP Ledgerコンセンサスプロセスの概要](../consensus-protocol/index.md)
- [コンセンサスの原理とルール](../consensus-protocol/consensus-principles-and-rules.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

152
@i18n/ja/docs/concepts/transactions/secure-signing.md Normal file
View File

@@ -0,0 +1,152 @@
---
html: secure-signing.html
parent: transactions.html
seo:
description: 安全にトランザクションを送信できる環境を設定します。
labels:
- セキュリティ
- 開発
---
# 安全な署名
[トランザクション](index.md)をXRP Ledgerに送信するには、[秘密鍵](../accounts/cryptographic-keys.md)のセキュリティを損なわない方法でトランザクションにデジタル署名する必要があります。（他の人があなたの秘密鍵にアクセスできる場合、その人はあなたと同じようにあなたのアカウントを操作できるため、すべての資金が盗まれたり消却されたりする可能性があります。）このページでは、トランザクションに安全に署名できる環境の設定方法について説明します。
**ヒント:** ネットワークにトランザクションを送信していない場合は、Rippleが運用しているサーバーなど、信頼できる公開サーバーを安全に使用して、着信トランザクションの監視やその他のネットワークアクティビティの読み取りを行うことができます。XRP Ledgerのすべてのトランザクション、残高、データは公開されています。
セキュリティのレベルが異なるさまざまな構成があるため、状況に応じて適したものは異なります。次の中からニーズに最適なものを選択してください。
- [`rippled`をローカルで実行](#ローカルでrippledを実行する)または[同じLAN内で実行](#同じlan内でrippledを実行する)
- ローカル署名を行える[クライアントライブラリを使用](#ローカル署名機能のあるクライアントライブラリを使用する)
- XRP Ledgerの署名に対応した[専用の署名デバイスを使用](#専用の署名デバイスを使用する)
- 信頼できる[リモート`rippled`マシンに接続するために安全なVPNを使用](#リモートrippledサーバーに対して安全なvpnを使用する)
<!-- Source for all diagrams in this article: https://drive.google.com/drive/u/0/folders/1MFkzxtMYpS8tzdm-TjWbLSVgU0zAG9Vh -->
## 安全でない構成
<!-- TODO: translate diagrams -->
[{% inline-svg file="/docs/img/insecure-signing-options.svg" /%}](/docs/img/insecure-signing-options.svg "安全でない構成の図")
外部のソースからあなたの秘密鍵にアクセスできる構成は危険で、不正使用者によってあなたのすべてのXRP（およびあなたのXRP Ledgerのアドレスにあるすべてのもの）が盗まれる可能性があります。そのような構成の例としては、インターネット経由で他の人の`rippled`サーバーの[signメソッド][]を使用する構成や、秘密鍵をインターネットを経由してプレーンテキストで自己所有サーバーに送信する構成などがあります。
秘密鍵の秘匿性は常に保持する必要があります。自分にメールで送信したり、人の目に触れるところで入力したりしてはいけません。秘密鍵を使用しないときは、決してプレーンテキストではなく、暗号化された形式で保存する必要があります。セキュリティと利便性のバランスは、アドレスの保有額によっても変わります。さまざまな目的に合わせてさまざまなセキュリティ構成の複数のアドレスを使用することをお勧めします。
<!-- Note: I'd link "issuing and operational addresses" for an explanation of hot/cold wallet security, but it's particularly gateway/issued-currency centric, which is not appropriate for this context. -->
## ローカルでrippledを実行する
[{% inline-svg file="/docs/img/secure-signing-local-rippled.svg" /%}](/docs/img/secure-signing-local-rippled.svg "署名にローカルrippledサーバーを使用する構成の図")
この構成では、トランザクションを生成するマシンで`rippled`を実行します。 秘密鍵はマシンから出ていかないため、マシンへのアクセス権がない人は秘密鍵にアクセスできません。もちろん、マシンのセキュリティ保護に関する業界標準のプラクティスに従ってください。この構成を使用するには、次の手順を実行します。
1. [`rippled`をインストール](../../infrastructure/installation/index.md)します。
ローカルマシンが[`rippled`の最小システム要件](../../infrastructure/installation/system-requirements.md)を満たしていることを確認します。
2. トランザクションに署名する必要がある場合は、`localhost`または`127.0.0.1`のサーバーに接続します。シングル署名の場合は[signメソッド][]、マルチシグの場合は[sign_forメソッド][]を使用します。
[構成ファイルの例](https://github.com/XRPLF/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1050-L1073)では、ローカルループバックネットワーク上（127.0.0.1）のポート5005でJSON-RPC（HTTP）、ポート6006でWebSocket（WS）の接続をリッスンし、接続されるすべてのクライアントを管理者として扱っています。
**注意:** 署名に[コマンドラインAPI](../../references/http-websocket-apis/api-conventions/request-formatting.md#コマンドライン形式)を使用する場合は、コマンドラインでないクライアントで[Websocket APIやJSON-RPC APIを使用](../../tutorials/http-websocket-apis/get-started.md)する場合よりもセキュリティが弱くなります。コマンドライン構文を使用すると、秘密鍵がシステムのプロセスリストで他のユーザーに見える可能性があり、シェル履歴にプレーンテキスト形式でキーが保存される可能性があります。
3. サーバーの使用中は、稼働状態と最新状態を維持して、ネットワークと同期されるようにしておく必要があります。
**注記:** トランザクションを送信していないときは`rippled`サーバーをオフにすることが _可能_ ですが、再び起動したときにネットワークとの同期に最大15分かかります。
## 同じLAN内でrippledを実行する
[{% inline-svg file="/docs/img/secure-signing-lan-rippled.svg" /%}](/docs/img/secure-signing-lan-rippled.svg "署名にLAN経由でrippledサーバーを使用する構成の図")
この構成では、署名するトランザクションを生成するマシンと同じプライベートローカルエリアネットワーク（LAN）内の専用マシンで`rippled`サーバーを実行します。この構成では、`rippled`を実行する専用の1台のマシンを使用しながら、中程度のシステムスペックの1台以上のマシンでトランザクションの指示を組み立てることができます。自己所有のデータセンターやサーバールームがある場合に魅力的な選択肢です。
この構成を使用するには、`rippled`サーバーをLAN内の`wss`および`https`接続を受け入れるように設定します。[証明書ピンニング](https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning)を使用する場合は自己署名証明書を使用できます。あるいは、社内や既知の認証局が署名した証明書を使用できます。[Let's Encrypt](https://letsencrypt.org/)などの一部の認証局は無料で証明書を自動発行しています。
<!--{# TODO: link api-over-lan.html with the detailed instructions when those are ready #}-->
必ず、マシンのセキュリティ保護に関する業界標準のプラクティスに従ってください。例えば、ファイアウォール、ウイルス対策、適切なユーザー権限を使用するなどです。
## ローカル署名機能のあるクライアントライブラリを使用する
[{% inline-svg file="/docs/img/secure-signing-client-library.svg" /%}](/docs/img/secure-signing-client-library.svg "ローカル署名機能のあるクライアントライブラリを使用する構成の図")
この構成では、使用するプログラミング言語で、署名を組み込んだクライアントライブラリを使用します。ローカル署名を実行できるライブラリの一覧は、[クライアントライブラリ](../../references/client-libraries.md)を参照してください。
### 署名ライブラリのセキュリティベストプラクティス
署名ライブラリのセキュリティを最適化するために、次のベストプラクティスを使用してください。
* 使用する署名ライブラリが、署名アルゴリズムを適切かつ安全に実装 していることを確認してください。例えば、ライブラリがデフォルトのECDSAアルゴリズムを使用する場合、[RFC-6979](https://tools.ietf.org/html/rfc6979)に記述されているように、決定論的なnoncesも使用すべきです。
上記のすべての公開ライブラリは、業界のベストプラクティスに従っています。
* クライアントライブラリを最新の安定版に更新してください。
* セキュリティ強化のため、[Vault](https://www.vaultproject.io/)などの管理ツールから秘密鍵を読み込みます。
### ローカル署名の例
以下は、以下の言語とライブラリを使用して、ローカルでトランザクションに署名する方法の例です。
* **JavaScript** / **TypeScript** - [`xrpl.js`](https://github.com/XRPLF/xrpl.js)
* **Python** - [`xrpl-py`](https://github.com/XRPLF/xrpl-py)
* **Java** - [`xrpl4j`](https://github.com/XRPLF/xrpl4j)
{% tabs %}
{% tab label="JavaScript" %}
{% code-snippet file="/_code-samples/secure-signing/js/signPayment.js" language="js" /%}
{% /tab %}
{% tab label="Python" %}
{% code-snippet file="/_code-samples/secure-signing/py/sign-payment.py" language="py" /%}
{% /tab %}
{% tab label="Java" %}
{% code-snippet file="/_code-samples/secure-signing/java/SignPayment.java" language="java" /%}
{% /tab %}
{% /tabs %}
## 専用の署名デバイスを使用する
[{% inline-svg file="/docs/img/secure-signing-dedicated-hardware.svg" /%}](/docs/img/secure-signing-dedicated-hardware.svg "専用の署名ハードウェアの使用の図")
専用の署名デバイスが各社から販売されており、例えば[Ledger Nano S](https://www.ledger.com/products/ledger-nano-s)は、秘密鍵をデバイスから出さずに使ってXRP Ledgerトランザクションに署名できます。すべてのタイプのトランザクションに対応していないデバイスもあります。
この構成の設定は、特定のデバイスによって異なります。場合によっては、署名デバイスと通信するためにマシンで「マネージャー」アプリケーションを実行する必要があります。そのようなデバイスの設定と使用方法については、メーカーの手順を参照してください。
## リモートrippledサーバーに対して安全なVPNを使用する
[{% inline-svg file="/docs/img/secure-signing-over-vpn.svg" /%}](/docs/img/secure-signing-over-vpn.svg "VPNを経由してリモート`rippled`に安全に接続する構成の図")
この構成では、コロケーション施設や遠隔地のデータセンターなどにあるリモートでホストされている`rippled`サーバーを使用し、暗号化されたVPNを使用してそのサーバーに接続します。
この構成を使用するには、[プライベートLANで`rippled`を実行](#同じlan内でrippledを実行する)するための手順に従いますが、VPNを使用してリモート`rippled`サーバーのLANに接続します。VPNの設定手順は環境によって異なり、このガイドでは説明しません。
## 関連項目
- **コンセプト:**
- [暗号鍵](../accounts/cryptographic-keys.md)
- [マルチシグ](../accounts/multi-signing.md)
- **チュートリアル:**
- [rippledのインストール](../../infrastructure/installation/index.md)
- [レギュラーキーペアの割り当て](../../tutorials/tasks/manage-account-settings/assign-a-regular-key-pair.md)
- [信頼できるトランザクションの送信](reliable-transaction-submission.md)
- [パブリック署名の有効化](../../infrastructure/configuration/enable-public-signing.md)
- **リファレンス:**
- [signメソッド][]
- [submitメソッド][]
- [xrpl.jsリファレンス](https://js.xrpl.org/)
- [`xrpl-py`リファレンス](https://xrpl-py.readthedocs.io/)
- [`xrpl4j` Reference](https://javadoc.io/doc/org.xrpl/)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

53
@i18n/ja/docs/concepts/transactions/source-and-destination-tags.md Normal file
View File

@@ -0,0 +1,53 @@
---
html: source-and-destination-tags.html
parent: transactions.html
seo:
description: 送信元タグと宛先タグを使用して、多目的アドレスからの、または多目的アドレスへの支払いを行います。
labels:
- 支払い
- アカウント
- セキュリティ
---
# 送信元タグと宛先タグ
_送信元タグ_と_宛先タグ_は、XRP Ledgerの[支払い](../payment-types/index.md)機能で、多目的アドレスからの支払いや多目的アドレスへの支払いの特定の目的を示すことができます。送信元タグと宛先タグは、台帳上の直接的な機能を持ちません。送信元タグと宛先タグは、台帳外のシステムがどのように支払いを処理すべきかについての情報を提供するだけです。トランザクションでは、送信元タグも宛先タグも 32ビット符号なし整数の形式です。
宛先タグは、支払いの受取人または宛先を示します。例えば、[取引所](../../use-cases/defi/list-xrp-as-an-exchange.md) や [ステーブルコインの発行者](../../use-cases/tokenization/stablecoin-issuer.md)アドレスへの支払いは、宛先タグを使用して、そのビジネス自体のシステム内で支払額を与信するユーザを表すことができます。店舗・業者への支払いは、その支払いがどの商品を購入するのかを表すことができます。
送信元タグは、支払いの送信者または送信元を示します。最も一般的なのは、受取人に対する返金時の送信先として送信元タグを使用することです。返金する場合は、受領した支払いの送信元タグを返金支払いの宛先タグとして使用する必要があります。
顧客に、別のインターフェースを使用してXRP Ledgerアドレスからトランザクションを送受信する機能を提供することを、_ホストされたアカウント_の提供と呼びます。ホストされたアカウントでは通常、顧客ごとに送信元タグと宛先タグを使用します。
**ヒント:** [Xアドレス](https://xrpaddress.info/)は、従来のアドレスとタグを組み合わせて、両方をエンコードして1つのアドレスにしたものです。顧客に入金アドレスを示す場合、顧客にアドレスとタグの2つの情報を管理させるよりも、Xアドレスを使用する方が顧客にとって簡単かもしれません。(Xアドレスのタグは、送信時には送信元タグとして、受信時には宛先タグとして機能します)。
## 理由
他の分散型台帳では、顧客ごとに異なる入金アドレスを使用するのが一般的です。XRP Ledgerでは、支払いを受け取るためには、そのアドレスは入金され有効化済みの[アカウント](../accounts/index.md)でなければなりません。XRP Ledgerで他と同じアプローチを用いると、ネットワーク内の全てのサーバのリソースを無駄に消費し、各アドレスに対して[準備金](../accounts/reserves.md)の金額を無制限に確保しなければならな苦なり、大きなコストがかかります。
送信元タグと宛先タグは、入金と支払いを個別の顧客にマッピングする、より軽量な方法を提供します。
## ユースケース
ビジネスにおいては、複数の目的で送信元タグと宛先タグを使用する場合があります：
- 顧客アカウントへの直接マッピング
- 返金された支払いを、その支払いを行った支払元にマッピング
- 期限切れの見積もりへの支払いのマッピング
- 顧客が特定の入金に対して生成できる使い捨てタグの提供
プライバシーを保護しながらタグの重複を防ぐために、ビジネスでは利用可能なタグの全範囲を目的ごとに分割し、その範囲内でタグを予測不可能な順序で割り当てることができます。例えば、[SHA-256](https://ja.wikipedia.org/wiki/SHA-2)のような暗号ハッシュ関数を使用し、[剰余演算](https://ja.wikipedia.org/wiki/剰余演算)を使用して出力を関連するセクションのサイズにマッピングします。安全のため、新しいタグを使う前に古いタグとの衝突をチェックしてください。
タグを番号順に割り当てると、顧客のプライバシーが損なわれます。XRP Ledgerのトランザクションはすべて公開されているため、番号順でタグを割り当てると、タグとユーザのアドレスの対応を推測したり、使用されているタグに基づいてユーザのアカウントに関する情報を導き出したりすることが可能になります。
## タグの必須化
複数の顧客口座への支払いを受け取る可能性があるXRP Ledgerアドレスにとって、宛先タグなしで支払いを受け取ることは問題です。どの顧客に入金すべきかがすぐに分からないため、手作業が必要になったり、誰が受取人であったかを特定するために送金者とやり取りをしなければならなくなったりします。このようなケースを減らすために、[`RequireDest`設定を有効にする](../../tutorials/tasks/manage-account-settings/require-destination-tags.md)ことができます。そうすることで、もしユーザが支払先にタグを設定し忘れた場合、XRP Ledgerはその支払いを拒否します。その後、ユーザはそのタグを使って再度支払いを行うことができます。
## 関連項目
- [宛先タグの必須化](../../tutorials/tasks/manage-account-settings/require-destination-tags.md)
- [支払いのタイプ](../payment-types/index.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

179
@i18n/ja/docs/concepts/transactions/transaction-cost.md Normal file
View File

@@ -0,0 +1,179 @@
---
html: transaction-cost.html
parent: transactions.html
seo:
description: トランザクションコストとはトランザクション送信のために償却される少額のXRPで、これによってレジャーがスパムから保護されます。トランザクションコストの適用方法について説明します。
labels:
- 手数料
- トランザクション送信
---
# トランザクションコスト
XRP LedgerをスパムやDoS攻撃から守るため、各トランザクションでは少額の[XRP](../../introduction/what-is-xrp.md)が消却されます。この _トランザクションコスト_ はネットワークの負荷とともに増加するように設計されており、故意または不注意にネットワークに過剰な負荷をかけると非常に高くつきます。
各トランザクションのトランザクションコストを支払う際には、[消却するXRPの額を指定](#トランザクションコストの指定)する必要があります。
## 現在のトランザクションコスト
ネットワークが標準のトランザクションに必要とする現在の最低トランザクションコストは**0.00001 XRP**（10 drop）です。これは負荷が通常より高くなると増加することがあります。
また、[現在のトランザクションコストについて`rippled`に問い合わせる](#トランザクションコストの問い合わせ)こともできます。
### 特別なトランザクションコスト
一部のトランザクションには異なるトランザクションコストがあります。
| トランザクション | 負荷スケーリング前のコスト |
|-----------------------|--------------------------|
| [Referenceトランザクション](#referenceトランザクションコスト)（ほとんどのトランザクション） | 10 drop |
| [Key Resetトランザクション](#key-resetトランザクション)| 0 |
| [マルチシグトランザクション](../accounts/multi-signing.md)| 10 drop × （1 + 署名の数） |
| [フルフィルメントを伴うEscrowFinishトランザクション](../../references/protocol/transactions/types/escrowfinish.md)| 10 drop × （33 + （バイト単位のフルフィルメントサイズ ÷ 16）） |
| [AccountDeleteトランザクション](../accounts/deleting-accounts.md)| 2,000,000 drop |
## トランザクションコストの受取人
トランザクションコストは誰かに支払われるものではありません。XRPは取り消し不能で消却されます。XRPを新たに作ることはできないため、XRPの希少性が高まり、XRPの価値を高めることによって、すべてのXRP保有者に利益がもたらされます。
## 負荷コストとオープンレジャーコスト
[FeeEscalation Amendment][]が有効な場合、トランザクションコストには以下の2つのしきい値があります。
* トランザクションコストが`rippled`サーバーの[負荷ベーストランザクションコストのしきい値](#ローカル負荷コスト)を満たしていない場合、サーバーはそのトランザクションを完全に無視します。（このロジックはAmendmentの有無にかかわらず基本的に変わりません。）
* トランザクションコストが`rippled`サーバーの[オープンレジャーコストのしきい値](#オープンレジャーコスト)を満たしていない場合、サーバーはそのトランザクションを後のレジャーのキューに入れます。
これによってトランザクションは大まかに以下の3つのカテゴリーに分けられます。
* トランザクションコストが低く設定され、負荷ベーストランザクションコストによって拒否されるトランザクション。
* トランザクションコストが高く設定され、現在のオープンレジャーに組み入れられるトランザクション。
* その中間のトランザクション。[後のレジャーバージョンのキューに入れられます](#キューに入れられたトランザクション)。
## ローカル負荷コスト
各`rippled`サーバーには、現在の負荷に基づいてコストしきい値が保持されています。送信するトランザクションの`Fee`値が`rippled`サーバーの現在の負荷ベーストランザクションコストより低い場合、そのサーバーはトランザクションの適用も中継もしません。（**注記:** [管理者接続](../../tutorials/http-websocket-apis/get-started.md)を介してトランザクションを送信する場合、トランザクションがスケーリングされていない最低トランザクションコストを満たすかぎり、サーバーはそのトランザクションを適用し、中継します。）トランザクションの`Fee`値が大半のサーバーの要件を満たさないかぎり、そのトランザクションが[コンセンサスプロセス](../consensus-protocol/index.md)を完了する可能性は極めて低くなります。
## オープンレジャーコスト
`rippled`サーバーにはトランザクションコストを強制する2つ目のメカニズムがあり、 _オープンレジャーコスト_ と呼ばれます。トランザクションがXRPによるオープンレジャーコスト要件を満たす場合のみ、そのトランザクションをオープンレジャーに含めることができます。オープンレジャーコスト要件を満たさないトランザクションは、[次のレジャーのキューに入れられます](#キューに入れられたトランザクション)。
新しいレジャーバージョンごとに、サーバーは前のレジャーのトランザクション数に基づいてオープンレジャーに含めるトランザクション数のソフトリミットを選択します。オープンレジャーコストは、オープンレジャー内のトランザクション数がソフトリミットと等しくなるまでは、スケーリングされていない最低トランザクションコストと同じです。それを超えると、オープンレジャーコストはオープンレジャーに含まれるトランザクションごとに急激に増加します。次のレジャーでは、現行のレジャーにソフトリミットを超えるトランザクションが含まれていれば、サーバーはソフトリミットを高くし、コンセンサスプロセスに5秒より時間が掛かる場合はソフトリミットを低くします。
オープンレジャーコストの水準は、絶対的なトランザクションコストではなく[標準的なトランザクションコストに比例](#手数料レベル)しています。標準よりも高い要件を持つトランザクションタイプ（[マルチシグトランザクション](../accounts/multi-signing.md)など）は、オープンレジャーコストを満たすために最低限のトランザクションコスト要件を持つトランザクションよりも多く支払う必要があります。
関連項目: [`rippled`リポジトリー内のFee Escalationの説明](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md)。
### キューに入れられたトランザクション
`rippled`が、サーバーのローカル負荷コストは満たすが[オープンレジャーコスト](#オープンレジャーコスト)は満たさないトランザクションを受け取った場合、サーバーはそのトランザクションが後のレジャーに「含まれる可能性」を判断します。その可能性が高いと判断すれば、サーバーはそのトランザクションをトランザクションキューに追加し、他のネットワークメンバーにトランザクションを中継します。そうでない場合、サーバーはトランザクションを破棄します。[トランザクションコストは検証済みレジャーに含まれるトランザクションにのみ適用される](#トランザクションコストと失敗したトランザクション)ため、サーバーは、トランザクションコストを支払わないトランザクションにより生じるネットワーク負荷量を最低限に抑えようとします。
キューに入れられたトランザクションの詳細は、[トランザクションキュー](transaction-queue.md)を参照してください。
## Referenceトランザクションコスト
「Referenceトランザクション」とは、負荷スケーリング前の[トランザクションコスト](transaction-cost.md)という観点からは、最も安価な（無料ではない）トランザクションと言えます。ほとんどのトランザクションのコストはReferenceトランザクションと同じです。[マルチシグトランザクション](../accounts/multi-signing.md)など一部のトランザクションでは、このコストの数倍のコストが必要です。オープンレジャーコストが上昇する場合は、コスト水準はトランザクションの基本コストに比例します。
### 手数料レベル
_手数料レベル_ は、トランザクションの最少コストと実際のコストとの相対的な差を表します。[オープンレジャーコスト](#オープンレジャーコスト)は絶対的なコストではなく手数料レベルで評価されます。比較する場合は以下の表を参照してください。
| トランザクション | drop単位の最少コスト | 手数料レベルでの最少コスト | drop単位で倍のコスト | 手数料レベルで倍のコスト |
|-------------|-----------------------|----------------------------|----------------------|---------------------------|
| Referenceトランザクション（ほとんどのトランザクション） | 10 | 256 | 20 | 512 |
| 4つの署名を持つ[マルチシグトランザクション](../accounts/multi-signing.md) | 50 | 256 | 100 | 512 |
| [Key Resetトランザクション](transaction-cost.md#key-resetトランザクション) | 0 | （事実上無限） | なし | （事実上無限） |
| 32バイトのプリイメージ付きの[EscrowFinishトランザクション](../../references/protocol/transactions/types/escrowfinish.md)。 | 350 | 256 | 700 | 512 |
## トランザクションコストの問い合わせ
`rippled` APIには、ローカル負荷ベースのトランザクションコストを問い合わせる方法が2つあります。`server_info`コマンド（人を対象とする）と`server_state`コマンド（マシンを対象とする）です。
[FeeEscalation Amendment][]が有効である場合、[feeメソッド][]を使用してオープンレジャーコストを確認することができます。
### server_info
[server_infoメソッド][]は、`validated_ledger.base_fee_xrp`と同様に、前のレジャー時点のスケーリングされていない最低XRPコストを10進XRPの形式でレポートします。トランザクションを中継するために必要な実際のコストをスケーリングするには、その`base_fee_xrp`値に同じレスポンス内の`load_factor`パラメーターを掛けます。このパラメーターは、サーバーの現在の負荷レベルを表します。つまり、次の式になります。
**XRP単位の現在のトランザクションコスト = `base_fee_xrp` × `load_factor`**
### server_state
[server_stateメソッド][]は、`rippled`の内部負荷計算の内容をそのままの表示形式で返します。この場合、有効負荷率は`load_base`に対する`load_factor`の割合です。`validated_ledger.base_fee`パラメーターは、[XRPのdrop](../../references/protocol/data-types/basic-data-types.md#通貨額の指定)単位の最低トランザクションコストをレポートします。この設計により、`rippled`では整数のみでトランザクションコストの計算ができ、サーバー負荷の微調整も十分に行えます。実際のトランザクションコストの計算は以下のようになります。
**drop単位の現在のトランザクションコスト = (`base_fee` × `load_factor`) ÷ `load_base`**
## トランザクションコストの指定
署名されたすべてのトランザクションの[`Fee`フィールド](../../references/protocol/transactions/common-fields.md)には、トランザクションコストを含める必要があります。署名されたトランザクションのすべてのフィールドと同様に、このフィールドは署名の無効化を行わなければ変更できません。
通常、XRP Ledgerはトランザクションを署名された _とおりに_ 実行します。（少なくとも、分散型コンセンサスネットワーク全体をコーディネートしてそれ以外のことを実行するのは難しいと思われます。）したがって、`Fee`フィールドに指定されたXRPの額が、ネットワーク内で指定されているどの現在の最低トランザクションコストをもはるかに上回っていたとしても、指定したとおりのXRPがすべてのトランザクションで消却されます。トランザクションコストでは、アカウントの[準備金](../accounts/reserves.md)用に確保していたXRPも消却される場合があります。
トランザクションに署名する前に、[現在の負荷ベースのトランザクションコストを調べる](#トランザクションコストの問い合わせ)ことをお勧めします。負荷スケーリングが原因でトランザクションコストが高い場合は、低下するまで待つことができます。トランザクションをすぐに送信するつもりがない場合は、トランザクションコストにおける将来の負荷ベースの変動を考慮して、少し高めのトランザクションコストを指定することをお勧めします。
### トランザクションコストの自動指定
オンラインでトランザクションに署名する場合は、`Fee`フィールドを省略できます。この場合、`rippled`または[クライアントライブラリ](../../references/client-libraries.md)が現在の要件に照らしてピアツーピアネットワークの状態を確認し、トランザクションに署名する前に`Fee`値を追加します。ただし、このようなトランザクションコストへの自動入力にはいくつかの欠点と制限事項があります。
* トランザクションに署名し、分散するまでの間にネットワークのトランザクションコストが上昇した場合、そのトランザクションは承認されない場合があります。
* 最悪の場合、トランザクションに`LastLedgerSequence`パラメーターが含まれているか、同じ`Sequence`番号を使用する新しいトランザクションによってその[トランザクションがキャンセル](finality-of-results/canceling-a-transaction.md)されない限り、トランザクションは明確に承認も拒否もされない状態のままとなってしまいます。ベストプラクティスについては、[信頼できるトランザクションの送信](reliable-transaction-submission.md)を参照してください。
* 署名するトランザクションの`Fee`フィールドの正確な値は事前にわかりません。
* `rippled`を使用している場合は、[signメソッド][]の`fee_mult_max`パラメーターと`fee_div_max`パラメーターを使用して、署名しようとしている負荷スケーリングに制限を設定することもできます。
* オフラインのマシンから現在のトランザクションコストを調べることはできません。
* [マルチシグ](../accounts/multi-signing.md)の場合、トランザクションコストの自動指定は行えません。
## トランザクションコストと失敗したトランザクション
トランザクションコストの目的はXRP Ledgerピアツーピアネットワークを過度な負荷から保護することであるため、トランザクションが成功するかどうかにかかわらず、ネットワークに分散されるすべてのトランザクションにコストが適用されます。ただし、共有のグローバルレジャーに作用するため、トランザクションを検証済みレジャーに含める必要があります。したがって、`rippled`サーバーは[`tec`ステータスコード](../../references/protocol/transactions/transaction-results/transaction-results.md)（「tec」は「トランザクションエンジン - 請求手数料のみ」（Transaction Engine - Claimed fee only）を表します）で、失敗したトランザクションをレジャーに含めようとします。
トランザクションコストは、トランザクションが実際に検証済みレジャーに含められた場合に、送信者のXRP残高から差し引かれるだけです。このことは、トランザクションが成功するか`tec`コードとともに失敗するかにかかわらず適用されます。
トランザクションの失敗が[確定](finality-of-results/index.md)である場合、`rippled`サーバーによるネットワークへの中継は行われません。トランザクションは検証済みレジャーに含まれないため、誰のXRP残高にも影響することはありません。
### 不十分なXRP
`rippled`サーバーが最初にトランザクションを評価するとき、送信側アカウントにXRPトランザクションコストを支払うのに十分なXRP残高がない場合は、エラーコード`terINSUF_FEE_B`にてトランザクションを拒否します。これは`ter`（再試行）コードであるため、トランザクションの結果が[確定](finality-of-results/index.md)になるまで、`rippled`サーバーはネットワークへの中継を行わずにトランザクションを再試行します。
トランザクションはすでにネットワークに配信されているけれども、アカウントにトランザクションコストを支払うのに十分なXRPがない場合は、結果コード`tecINSUFF_FEE`が発生します。この場合、アカウントからは可能なかぎりすべてのXRPが支払われるため、最終的に0 XRPになります。これは、`rippled`がトランザクションをネットワークに中継するかどうかを進行中のレジャーに基づいて判断するために起こります。しかしコンセンサスレジャーを作成するときにトランザクションは破棄されるか並べ替えられることになります。
## Key Resetトランザクション
特殊なケースですが、アカウントの[lsfPasswordSpentフラグ](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)が無効であるかぎり、そのアカウントはトランザクションコスト`0`で[SetRegularKey](../../references/protocol/transactions/types/setregularkey.md)トランザクションを送信できます。このトランザクションにはアカウントの _マスターキーペア_ による署名が必要です。このトランザクションを送信すると、lsfPasswordSpentフラグが有効になります。
この機能は、レギュラーキーが危害を受けた場合に、危害を受けたアカウントに使用可能なXRPがあるかどうかを気にすることなく、そのアカウントを復元できるように設計されています。このようにして、追加のXRPを送信する前にそのアカウントを再び管理できるようになります。
[lsfPasswordSpentフラグ](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)は無効になります。このフラグを有効にするには、マスターキーペアによって署名されたSetRegularKeyトランザクションを送信します。アカウントでXRPの[支払い](../../references/protocol/transactions/types/payment.md)が受け入れた場合、再び無効になります。
[FeeEscalation Amendment][]が有効な場合、Key Resetトランザクションの名目トランザクションコストがゼロであっても、`rippled`は他のトランザクションよりもKey Resetトランザクションを優先します。
## トランザクションコストの変更
XRP Ledgerは、XRPの価値が長期的に変化することを見越して、最低トランザクションコストを変更するしくみを備えています。変更はすべて、コンセンサスプロセスによる承認が必要です。詳細は、[手数料の投票](../consensus-protocol/fee-voting.md)を参照してください。
## 関連項目
- **コンセプト:**
- [準備金](../accounts/reserves.md)
- [手数料投票](../consensus-protocol/fee-voting.md)
- [トランザクションキュー](transaction-queue.md)
- **チュートリアル:**
- [信頼できるトランザクションの送信](reliable-transaction-submission.md)
- **リファレンス:**
- [feeメソッド][]
- [server_infoメソッド][]
- [FeeSettingsオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/feesettings.md)
- [SetFee疑似トランザクション][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}

77
@i18n/ja/docs/concepts/transactions/transaction-queue.md Normal file
View File

@@ -0,0 +1,77 @@
---
html: transaction-queue.html
parent: transactions.html
seo:
description: コンセンサスに至る前にトランザクションをどのようにキューに入れることができるか説明します。
labels:
- トランザクション送信
---
# トランザクションキュー
`rippled`サーバーは、トランザクションキューを使用して[オープンレジャーコスト](transaction-cost.md#オープンレジャーコスト)を適用します。オープンレジャーコストにより、特定のレジャーの目標トランザクション数が設定され、オープンレジャーがこのサイズを超えると、必要なトランザクションコストが迅速に引き上げられます。`rippled`は引き上げられたトランザクションコストを支払うことができないトランザクションを無効にする代わりに、次のレジャーの構築に使用するトランザクションキューにそれらのトランザクションを入れようとします。
## トランザクションキューとコンセンサス
トランザクションキューは、コンセンサスプロセスで特定のレジャーバージョンに記録されるトランザクションと除外されるトランザクションを選択する際に、重要な役割を果たします。以下のステップでは、トランザクションキューと[コンセンサスプロセス](../consensus-protocol/index.md)の関係を説明します。
[![トランザクションキューとコンセンサスの図](/docs/img/consensus-with-queue.ja.png)](/docs/img/consensus-with-queue.ja.png)
1. **コンセンサスラウンド1** - 各バリデータが、次のレジャーバージョンに記録するトランザクションセットを提案します。各バリデータは、現在提案されていないトランザクション候補のキューも保持します。
2. **コンセンサスラウンド2** - バリデータは後のラウンドで自身の提案からトランザクションを削除する場合、そのトランザクションをキューに追加します。
3. **コンセンサスラウンドN** - 十分な数のサーバーがトランザクションセットについて合意するまで、コンセンサスプロセスが継続されます。
4. **検証** - 複数のサーバーが、各々同一のレジャーを構築したことを確認し、そのレジャーが検証済みであると宣言します。
5. **次の提案の作成** - 各バリデータは、キューに入れられているトランザクションを最初に使用して、次のレジャーバージョンの提案を準備します。
6. **キューへの追加** - 次の提案レジャーがすでにいっぱいである場合は、着信トランザクションはその後のレジャーバージョンのキューに入れられます。（[オープンレジャーコスト](transaction-cost.md#オープンレジャーコスト)を支払うトランザクションは、次の提案レジャーが「いっぱい」であってもそのレジャーに追加されますが、このようにトランザクションが追加されるたびにオープンレジャーコストは急激に増加します。）
このステップの後、プロセスが最初から繰り返されます。
**注記:** 技術的には、上記のプロセスで説明したステップのいくつかは並行して発生します。これは、各サーバーは常に新しいトランザクションに備えて待機しており、前のレジャーバージョンのコンセンサスプロセスの実行中に次のレジャー提案の準備を開始するためです。
## キューの制約事項
`rippled`サーバーはさまざまな経験則によるテストを行って「レジャーに追加される可能性がある」トランザクションを推定します。現行の実装では、以下のルールに基づいてキューに入れるトランザクションが決定されます。
- トランザクションは適切な形式で作成され、有効な署名によって[承認](index.md#トランザクションの承認)されている必要があります。
- `AccountTxnID`フィールドが指定されているトランザクションはキューに入れることができません。
- 1つの送信側アドレスには、同時に最大10個のトランザクションを入れることができます。
- トランザクションをキューに入れるには、送信者が以下のすべてを行うのに十分なXRPを保有している必要があります。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.0" %}更新: rippled 1.2.0{% /badge %}
- キュー内のすべての送信者のトランザクションの`Fee`フィールドに指定されているXRP[トランザクションコスト](transaction-cost.md)の消却。キュー内のトランザクションの合計額は、アカウントの基本準備金（現時点では10 XRP）を超えることはできません。（トランザクションコストの支払いが最小額の0.00001 XRPを大幅に上回るトランザクションは、キューをスキップし、オープンレジャーに直接追加されます。）
- キュー内のすべての送信者のトランザクションの送金を可能とするXRPの最大合計額の送信。
- アカウントの[必要準備金](../accounts/reserves.md)を確保するのに十分なXRPの保有。
- あるトランザクションが、送信側アドレスがトランザクションを承認する方法に影響する場合、同じアドレスからの他のトランザクションをそのトランザクションの後にキューに入れることはできません。{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.32.0" %}新規: rippled 0.32.0{% /badge %}
- トランザクションに`LastLedgerSequence`フィールドが指定されている場合、そのフィールドの値は少なくとも **現在のレジャーインデックス+ 2**になります。
### 手数料の平均化
{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.33.0" %}新規: rippled 0.33.0{% /badge %}
送信側アドレスのキューに1つ以上のトランザクションが入っている場合、その送信者はキューに入れられている既存のトランザクションをオープンレジャーに「プッシュ」するため、それらすべてのトランザクションのトランザクションコストの支払いをするのに十分なトランザクションコストが指定された新しいトランザクションを送信します。具体的には、新しいトランザクションは、そのトランザクション自体と、そのトランザクションより先にキュー内に入れられている同じ送信者からの各トランザクションの[オープンレジャーコスト](transaction-cost.md#オープンレジャーコスト)をカバーするのに十分なトランザクションコストを支払う必要があります。（オープンレジャーコストは、トランザクションがトランザクションコストを支払うたびに急激に増加することに留意してください。）トランザクションは他の[キューの制約事項](#キューの制約事項)にも従い、送信側アドレスはキュー内のすべてのトランザクションのトランザクションコストを支払うのに十分な額のXRPを保有している必要があります。
この機能により、特定の状況を回避できます。キュー内にある低コストのトランザクションを1つ以上送信した場合、同じアドレスから新しいトランザクションを送信するには、以下のいずれかを実行する必要があります。
* キュー内のトランザクションが検証済みレジャーに追加されるまで待機する。
* キュー内のトランザクションに[`LastLedgerSequence`フィールド](reliable-transaction-submission.md#lastledgersequence)が設定されている場合、それらのトランザクションが完全に無効化されるまで待機する。
* [キュー内のトランザクションを取り消す](finality-of-results/canceling-a-transaction.md)。このためには、同じシーケンス番号で、これらのトランザクションよりも高いトランザクションコストを指定した新しいトランザクションを送信します。
上記のどの操作も行われないと、トランザクションは理論上無期限にキューに入れられたままとなり、他の送信者はそれらよりもトランザクションコストが高いトランザクションを送信してキューに「割り込む」ことができます。署名済みのトランザクションは変更できないため、キュー内のトランザクションのトランザクションコストを増加して、トランザクションの優先度を上げることはできません。以前に送信されたトランザクションを無効にしたくない場合には、手数料の平均化が回避策となります。新しいトランザクションのトランザクションコストを増額して不足分を補えば、キュー内のトランザクションは即時にオープンレジャーに追加されます。
## キュー内の順序
トランザクションキュー内では、最も高いトランザクションコストを支払うトランザクションが一番になるようにトランザクションがランク付けされています。このランク付けはトランザクションの _絶対_ XRPコストではなく、 _[該当するトランザクションタイプの最小コスト](transaction-cost.md#特別なトランザクションコスト)に相対的な_ コストに基づいています。トランザクションコストが同額のトランザクションが複数ある場合は、サーバーが受信した順にランク付けされます。キュー内のトランザクションの順序にはその他の要因も影響します。たとえば、同一送信者からのトランザクションはその`Sequence`番号によりソートされ、順に送信されます。
キュー内のトランザクションの数が次のレジャーバージョンの予期サイズを超える場合には、キュー内のトランザクションの正確な順序に基づいて、次の処理レジャーバージョンに追加されるトランザクションが決定します。トランザクションの順序は**検証済みレジャー内でのトランザクションの実行順序には影響しません**。各検証済みレジャーバージョンでは、そのバージョンのトランザクションセットが[正規の順序](../consensus-protocol/consensus-structure.md#検証の計算と共有)で実行されます。
**注記:**`rippled`がトランザクションをキューに入れるときに付与される暫定的な[トランザクションレスポンスコード](../../references/protocol/transactions/transaction-results/transaction-results.md)は`terQUEUED`です。つまり、トランザクションは今後のレジャーバージョンで成功する見込みです。すべての暫定的なレスポンスコードと同様に、トランザクションが検証済みレジャーに追加されるか、または[完全に無効であると示される](finality-of-results/index.md)までは、トランザクションの結果は最終的ではありません。
## 関連項目
- トランザクションコストが設けられている理由と、XRP Ledgerでのトランザクションコストの適用方法については、[トランザクションコスト](transaction-cost.md)を参照してください。
- コンセンサスプロセスによるトランザクション承認方法についての詳しい説明は、[コンセンサス](../consensus-protocol/index.md)を参照してください。
{% raw-partial file="/docs/_snippets/common-links.md" /%}