xrpl-dev-portal/content/concepts/transactions/transaction-queue.ja.md

---
html: transaction-queue.html
parent: transactions.html
blurb: コンセンサスに至る前にトランザクションをどのようにキューに入れることができるか説明します。
labels:
  - トランザクション送信
---
# トランザクションキュー

`rippled`サーバーは、トランザクションキューを使用して[オープンレジャーコスト](transaction-cost.html#オープンレジャーコスト)を適用します。オープンレジャーコストにより、特定のレジャーの目標トランザクション数が設定され、オープンレジャーがこのサイズを超えると、必要なトランザクションコストが迅速に引き上げられます。`rippled`は引き上げられたトランザクションコストを支払うことができないトランザクションを無効にする代わりに、次のレジャーの構築に使用するトランザクションキューにそれらのトランザクションを入れようとします。

## トランザクションキューとコンセンサス

トランザクションキューは、コンセンサスプロセスで特定のレジャーバージョンに記録されるトランザクションと除外されるトランザクションを選択する際に、重要な役割を果たします。以下のステップでは、トランザクションキューと[コンセンサスプロセス](consensus.html)の関係を説明します。

[![トランザクションキューとコンセンサスの図](img/consensus-with-queue.ja.png)](img/consensus-with-queue.ja.png)

1. **コンセンサスラウンド1** - 各バリデータが、次のレジャーバージョンに記録するトランザクションセットを提案します。各バリデータは、現在提案されていないトランザクション候補のキューも保持します。

2. **コンセンサスラウンド2** - バリデータは後のラウンドで自身の提案からトランザクションを削除する場合、そのトランザクションをキューに追加します。

3. **コンセンサスラウンドN** - 十分な数のサーバーがトランザクションセットについて合意するまで、コンセンサスプロセスが継続されます。

4. **検証** - 複数のサーバーが、各々同一のレジャーを構築したことを確認し、そのレジャーが検証済みであると宣言します。

5. **次の提案の作成** - 各バリデータは、キューに入れられているトランザクションを最初に使用して、次のレジャーバージョンの提案を準備します。

6. **キューへの追加** - 次の提案レジャーがすでにいっぱいである場合は、着信トランザクションはその後のレジャーバージョンのキューに入れられます。（[オープンレジャーコスト](transaction-cost.html#オープンレジャーコスト)を支払うトランザクションは、次の提案レジャーが「いっぱい」であってもそのレジャーに追加されますが、このようにトランザクションが追加されるたびにオープンレジャーコストは急激に増加します。）

    このステップの後、プロセスが最初から繰り返されます。

**注記:** 技術的には、上記のプロセスで説明したステップのいくつかは並行して発生します。これは、各サーバーは常に新しいトランザクションに備えて待機しており、前のレジャーバージョンのコンセンサスプロセスの実行中に次のレジャー提案の準備を開始するためです。

## キューの制約事項

`rippled`サーバーはさまざまな経験則によるテストを行って「レジャーに追加される可能性がある」トランザクションを推定します。現行の実装では、以下のルールに基づいてキューに入れるトランザクションが決定されます。

- トランザクションは適切な形式で作成され、有効な署名によって[承認](transactions.html#トランザクションの承認)されている必要があります。
- `AccountTxnID`フィールドが指定されているトランザクションはキューに入れることができません。
- 1つの送信側アドレスには、同時に最大10個のトランザクションを入れることができます。
- トランザクションをキューに入れるには、送信者が以下のすべてを行うのに十分なXRPを保有している必要があります。[更新: rippled 1.2.0][]
    - キュー内のすべての送信者のトランザクションの`Fee`フィールドに指定されているXRP[トランザクションコスト](transaction-cost.html)の消却。キュー内のトランザクションの合計額は、アカウントの基本準備金（現時点では10 XRP）を超えることはできません。（トランザクションコストの支払いが最小額の0.00001 XRPを大幅に上回るトランザクションは、キューをスキップし、オープンレジャーに直接追加されます。）
    - キュー内のすべての送信者のトランザクションの送金を可能とするXRPの最大合計額の送信。
    - アカウントの[必要準備金](reserves.html)を確保するのに十分なXRPの保有。
- あるトランザクションが、送信側アドレスがトランザクションを承認する方法に影響する場合、同じアドレスからの他のトランザクションをそのトランザクションの後にキューに入れることはできません。[新規: rippled 0.32.0][]
- トランザクションに`LastLedgerSequence`フィールドが指定されている場合、そのフィールドの値は少なくとも **現在のレジャーインデックス+ 2**になります。

### 手数料の平均化

[新規: rippled 0.33.0][]

送信側アドレスのキューに1つ以上のトランザクションが入っている場合、その送信者はキューに入れられている既存のトランザクションをオープンレジャーに「プッシュ」するため、それらすべてのトランザクションのトランザクションコストの支払いをするのに十分なトランザクションコストが指定された新しいトランザクションを送信します。具体的には、新しいトランザクションは、そのトランザクション自体と、そのトランザクションより先にキュー内に入れられている同じ送信者からの各トランザクションの[オープンレジャーコスト](transaction-cost.html#オープンレジャーコスト)をカバーするのに十分なトランザクションコストを支払う必要があります。（オープンレジャーコストは、トランザクションがトランザクションコストを支払うたびに急激に増加することに留意してください。）トランザクションは他の[キューの制約事項](#キューの制約事項)にも従い、送信側アドレスはキュー内のすべてのトランザクションのトランザクションコストを支払うのに十分な額のXRPを保有している必要があります。

この機能により、特定の状況を回避できます。キュー内にある低コストのトランザクションを1つ以上送信した場合、同じアドレスから新しいトランザクションを送信するには、以下のいずれかを実行する必要があります。

* キュー内のトランザクションが検証済みレジャーに追加されるまで待機する。
* キュー内のトランザクションに[`LastLedgerSequence`フィールド](reliable-transaction-submission.html#lastledgersequence)が設定されている場合、それらのトランザクションが完全に無効化されるまで待機する。
* [キュー内のトランザクションを取り消す](cancel-or-skip-a-transaction.html)。このためには、同じシーケンス番号で、これらのトランザクションよりも高いトランザクションコストを指定した新しいトランザクションを送信します。

上記のどの操作も行われないと、トランザクションは理論上無期限にキューに入れられたままとなり、他の送信者はそれらよりもトランザクションコストが高いトランザクションを送信してキューに「割り込む」ことができます。署名済みのトランザクションは変更できないため、キュー内のトランザクションのトランザクションコストを増加して、トランザクションの優先度を上げることはできません。以前に送信されたトランザクションを無効にしたくない場合には、手数料の平均化が回避策となります。新しいトランザクションのトランザクションコストを増額して不足分を補えば、キュー内のトランザクションは即時にオープンレジャーに追加されます。

## キュー内の順序

トランザクションキュー内では、最も高いトランザクションコストを支払うトランザクションが一番になるようにトランザクションがランク付けされています。このランク付けはトランザクションの _絶対_ XRPコストではなく、 _[該当するトランザクションタイプの最小コスト](transaction-cost.html#特別なトランザクションコスト)に相対的な_ コストに基づいています。トランザクションコストが同額のトランザクションが複数ある場合は、サーバーが受信した順にランク付けされます。キュー内のトランザクションの順序にはその他の要因も影響します。たとえば、同一送信者からのトランザクションはその`Sequence`番号によりソートされ、順に送信されます。

キュー内のトランザクションの数が次のレジャーバージョンの予期サイズを超える場合には、キュー内のトランザクションの正確な順序に基づいて、次の処理レジャーバージョンに追加されるトランザクションが決定します。トランザクションの順序は**検証済みレジャー内でのトランザクションの実行順序には影響しません**。各検証済みレジャーバージョンでは、そのバージョンのトランザクションセットが[正規の順序](consensus-structure.html#検証の計算と共有)で実行されます。

**注記:**`rippled`がトランザクションをキューに入れるときに付与される暫定的な[トランザクション応答コード](transaction-results.html)は`terQUEUED`です。つまり、トランザクションは今後のレジャーバージョンで成功する見込みです。すべての暫定的な応答コードと同様に、トランザクションが検証済みレジャーに追加されるか、または[完全に無効であると示される](finality-of-results.html)までは、トランザクションの結果は最終的ではありません。


## 関連項目

- トランザクションコストが設けられている理由と、XRP Ledgerでのトランザクションコストの適用方法については、[トランザクションコスト](transaction-cost.html)を参照してください。
- コンセンサスプロセスによるトランザクション承認方法についての詳しい説明は、[コンセンサス](consensus.html)を参照してください。


<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}			
{% include '_snippets/tx-type-links.md' %}			
{% include '_snippets/rippled_versions.md' %}