# トランザクションコスト

XRP LedgerをスパムやDoS攻撃から守るため、各トランザクションでは少額の[XRP](/ja/docs/introduction/what-is-xrp)が消却されます。この *トランザクションコスト* はネットワークの負荷とともに増加するように設計されており、故意または不注意にネットワークに過剰な負荷をかけると非常に高くつきます。

各トランザクションのトランザクションコストを支払う際には、[消却するXRPの額を指定](#%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%B3%E3%82%B9%E3%83%88%E3%81%AE%E6%8C%87%E5%AE%9A)する必要があります。

## 現在のトランザクションコスト

ネットワークが標準のトランザクションに必要とする現在の最低トランザクションコストは**0.00001 XRP**（10 drop）です。これは負荷が通常より高くなると増加することがあります。

また、[現在のトランザクションコストについて`rippled`に問い合わせる](#%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%B3%E3%82%B9%E3%83%88%E3%81%AE%E5%95%8F%E3%81%84%E5%90%88%E3%82%8F%E3%81%9B)こともできます。

### 特別なトランザクションコスト

一部のトランザクションには異なるトランザクションコストがあります。

| トランザクション | 負荷スケーリング前のコスト |
|  --- | --- |
| [Referenceトランザクション](#reference%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%B3%E3%82%B9%E3%83%88)（ほとんどのトランザクション） | 10 drop |
| [Key Resetトランザクション](#key-reset%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3) | 0 |
| [マルチシグトランザクション](/ja/docs/concepts/accounts/multi-signing) | 10 drop × （1 + 署名の数） |
| [フルフィルメントを伴うEscrowFinishトランザクション](/ja/docs/references/protocol/transactions/types/escrowfinish) | 10 drop × （33 + （バイト単位のフルフィルメントサイズ ÷ 16）） |
| [AccountDeleteトランザクション](/ja/docs/concepts/accounts/deleting-accounts) | 2,000,000 drop |


## トランザクションコストの受取人

トランザクションコストは誰かに支払われるものではありません。XRPは取り消し不能で消却されます。XRPを新たに作ることはできないため、XRPの希少性が高まり、XRPの価値を高めることによって、すべてのXRP保有者に利益がもたらされます。

## 負荷コストとオープンレジャーコスト

[FeeEscalation Amendment](/ja/resources/known-amendments#feeescalation)が有効な場合、トランザクションコストには以下の2つのしきい値があります。

* トランザクションコストが`rippled`サーバの[負荷ベーストランザクションコストのしきい値](#%E3%83%AD%E3%83%BC%E3%82%AB%E3%83%AB%E8%B2%A0%E8%8D%B7%E3%82%B3%E3%82%B9%E3%83%88)を満たしていない場合、サーバはそのトランザクションを完全に無視します。（このロジックはAmendmentの有無にかかわらず基本的に変わりません。）
* トランザクションコストが`rippled`サーバの[オープンレジャーコストのしきい値](#%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%83%AC%E3%82%B8%E3%83%A3%E3%83%BC%E3%82%B3%E3%82%B9%E3%83%88)を満たしていない場合、サーバはそのトランザクションを後のレジャーのキューに入れます。


これによってトランザクションは大まかに以下の3つのカテゴリに分けられます。

* トランザクションコストが低く設定され、負荷ベーストランザクションコストによって拒否されるトランザクション。
* トランザクションコストが高く設定され、現在のオープンレジャーに組み入れられるトランザクション。
* その中間のトランザクション。[後のレジャーバージョンのキューに入れられます](#%E3%82%AD%E3%83%A5%E3%83%BC%E3%81%AB%E5%85%A5%E3%82%8C%E3%82%89%E3%82%8C%E3%81%9F%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3)。


## ローカル負荷コスト

各`rippled`サーバには、現在の負荷に基づいてコストしきい値が保持されています。送信するトランザクションの`Fee`値が`rippled`サーバの現在の負荷ベーストランザクションコストより低い場合、そのサーバはトランザクションの適用も中継もしません。（**注記:** [管理者接続](/ja/docs/tutorials/http-websocket-apis/build-apps/get-started)を介してトランザクションを送信する場合、トランザクションがスケーリングされていない最低トランザクションコストを満たすかぎり、サーバはそのトランザクションを適用し、中継します。）トランザクションの`Fee`値が大半のサーバの要件を満たさないかぎり、そのトランザクションが[コンセンサスプロセス](/ja/docs/concepts/consensus-protocol)を完了する可能性は極めて低くなります。

## オープンレジャーコスト

`rippled`サーバにはトランザクションコストを強制する2つ目のメカニズムがあり、 *オープンレジャーコスト* と呼ばれます。トランザクションがXRPによるオープンレジャーコスト要件を満たす場合のみ、そのトランザクションをオープンレジャーに含めることができます。オープンレジャーコスト要件を満たさないトランザクションは、[次のレジャーのキューに入れられます](#%E3%82%AD%E3%83%A5%E3%83%BC%E3%81%AB%E5%85%A5%E3%82%8C%E3%82%89%E3%82%8C%E3%81%9F%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3)。

新しいレジャーバージョンごとに、サーバは前のレジャーのトランザクション数に基づいてオープンレジャーに含めるトランザクション数のソフトリミットを選択します。オープンレジャーコストは、オープンレジャー内のトランザクション数がソフトリミットと等しくなるまでは、スケーリングされていない最低トランザクションコストと同じです。それを超えると、オープンレジャーコストはオープンレジャーに含まれるトランザクションごとに急激に増加します。次のレジャーでは、現行のレジャーにソフトリミットを超えるトランザクションが含まれていれば、サーバはソフトリミットを高くし、コンセンサスプロセスに5秒より時間が掛かる場合はソフトリミットを低くします。

オープンレジャーコストの水準は、絶対的なトランザクションコストではなく[標準的なトランザクションコストに比例](#%E6%89%8B%E6%95%B0%E6%96%99%E3%83%AC%E3%83%99%E3%83%AB)しています。標準よりも高い要件を持つトランザクションタイプ（[マルチシグトランザクション](/ja/docs/concepts/accounts/multi-signing)など）は、オープンレジャーコストを満たすために最低限のトランザクションコスト要件を持つトランザクションよりも多く支払う必要があります。

関連項目: [`rippled`リポジトリー内のFee Escalationの説明](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md)。

### キューに入れられたトランザクション

`rippled`が、サーバのローカル負荷コストは満たすが[オープンレジャーコスト](#%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%83%AC%E3%82%B8%E3%83%A3%E3%83%BC%E3%82%B3%E3%82%B9%E3%83%88)は満たさないトランザクションを受け取った場合、サーバはそのトランザクションが後のレジャーに「含まれる可能性」を判断します。その可能性が高いと判断すれば、サーバはそのトランザクションをトランザクションキューに追加し、他のネットワークメンバーにトランザクションを中継します。そうでない場合、サーバはトランザクションを破棄します。[トランザクションコストは検証済みレジャーに含まれるトランザクションにのみ適用される](#%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%B3%E3%82%B9%E3%83%88%E3%81%A8%E5%A4%B1%E6%95%97%E3%81%97%E3%81%9F%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3)ため、サーバは、トランザクションコストを支払わないトランザクションにより生じるネットワーク負荷量を最低限に抑えようとします。

キューに入れられたトランザクションの詳細は、[トランザクションキュー](/ja/docs/concepts/transactions/transaction-queue)をご覧ください。

## Referenceトランザクションコスト

「Referenceトランザクション」とは、負荷スケーリング前の[トランザクションコスト](/ja/docs/concepts/transactions/transaction-cost)という観点からは、最も安価な（無料ではない）トランザクションと言えます。ほとんどのトランザクションのコストはReferenceトランザクションと同じです。[マルチシグトランザクション](/ja/docs/concepts/accounts/multi-signing)など一部のトランザクションでは、このコストの数倍のコストが必要です。オープンレジャーコストが上昇する場合は、コスト水準はトランザクションの基本コストに比例します。

### 手数料レベル

*手数料レベル* は、トランザクションの最少コストと実際のコストとの相対的な差を表します。[オープンレジャーコスト](#%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%83%AC%E3%82%B8%E3%83%A3%E3%83%BC%E3%82%B3%E3%82%B9%E3%83%88)は絶対的なコストではなく手数料レベルで評価されます。比較する場合は以下の表をご覧ください。

| トランザクション | drop単位の最少コスト | 手数料レベルでの最少コスト | drop単位で倍のコスト | 手数料レベルで倍のコスト |
|  --- | --- | --- | --- | --- |
| Referenceトランザクション（ほとんどのトランザクション） | 10 | 256 | 20 | 512 |
| 4つの署名を持つ[マルチシグトランザクション](/ja/docs/concepts/accounts/multi-signing) | 50 | 256 | 100 | 512 |
| [Key Resetトランザクション](/ja/docs/concepts/transactions/transaction-cost#key-reset%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3) | 0 | （事実上無限） | なし | （事実上無限） |
| 32バイトのプリイメージ付きの[EscrowFinishトランザクション](/ja/docs/references/protocol/transactions/types/escrowfinish)。 | 350 | 256 | 700 | 512 |


## トランザクションコストの問い合わせ

`rippled` APIには、ローカル負荷ベースのトランザクションコストを問い合わせる方法が2つあります。`server_info`コマンド（人を対象とする）と`server_state`コマンド（マシンを対象とする）です。

[FeeEscalation Amendment](/ja/resources/known-amendments#feeescalation)が有効である場合、[feeメソッド](/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/fee)を使用してオープンレジャーコストを確認することができます。

### server_info

[server_infoメソッド](/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/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メソッド](/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/server_state)は、`rippled`の内部負荷計算の内容をそのままの表示形式で返します。この場合、有効負荷率は`load_base`に対する`load_factor`の割合です。`validated_ledger.base_fee`パラメーターは、[XRPのdrop](/ja/docs/references/protocol/data-types/basic-data-types#%E9%80%9A%E8%B2%A8%E9%A1%8D%E3%81%AE%E6%8C%87%E5%AE%9A)単位の最低トランザクションコストをレポートします。この設計により、`rippled`では整数のみでトランザクションコストの計算ができ、サーバ負荷の微調整も十分に行えます。実際のトランザクションコストの計算は以下のようになります。

**drop単位の現在のトランザクションコスト = (`base_fee` × `load_factor`) ÷ `load_base`**

## トランザクションコストの指定

署名されたすべてのトランザクションの[`Fee`フィールド](/ja/docs/references/protocol/transactions/common-fields)には、トランザクションコストを含める必要があります。署名されたトランザクションのすべてのフィールドと同様に、このフィールドは署名の無効化を行わなければ変更できません。

通常、XRP Ledgerはトランザクションを署名された *とおりに* 実行します。（少なくとも、分散型コンセンサスネットワーク全体をコーディネートしてそれ以外のことを実行するのは難しいと思われます。）したがって、`Fee`フィールドに指定されたXRPの額が、ネットワーク内で指定されているどの現在の最低トランザクションコストをもはるかに上回っていたとしても、指定したとおりのXRPがすべてのトランザクションで消却されます。トランザクションコストでは、アカウントの[準備金](/ja/docs/concepts/accounts/reserves)用に確保していたXRPも消却される場合があります。

トランザクションに署名する前に、[現在の負荷ベースのトランザクションコストを調べる](#%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%B3%E3%82%B9%E3%83%88%E3%81%AE%E5%95%8F%E3%81%84%E5%90%88%E3%82%8F%E3%81%9B)ことをお勧めします。負荷スケーリングが原因でトランザクションコストが高い場合は、低下するまで待つことができます。トランザクションをすぐに送信するつもりがない場合は、トランザクションコストにおける将来の負荷ベースの変動を考慮して、少し高めのトランザクションコストを指定することをお勧めします。

### トランザクションコストの自動指定

オンラインでトランザクションに署名する場合は、`Fee`フィールドを省略できます。この場合、`rippled`または[クライアントライブラリ](/ja/docs/references/client-libraries)が現在の要件に照らしてピアツーピアネットワークの状態を確認し、トランザクションに署名する前に`Fee`値を追加します。ただし、このようなトランザクションコストへの自動入力にはいくつかの欠点と制限事項があります。

* トランザクションに署名し、分散するまでの間にネットワークのトランザクションコストが上昇した場合、そのトランザクションは承認されない場合があります。
  * 最悪の場合、トランザクションに`LastLedgerSequence`パラメーターが含まれているか、同じ`Sequence`番号を使用する新しいトランザクションによってその[トランザクションがキャンセル](/ja/docs/concepts/transactions/finality-of-results/canceling-a-transaction)されない限り、トランザクションは明確に承認も拒否もされない状態のままとなってしまいます。ベストプラクティスについては、[信頼できるトランザクションの送信](/ja/docs/concepts/transactions/reliable-transaction-submission)をご覧ください。
* 署名するトランザクションの`Fee`フィールドの正確な値は事前にわかりません。
  * `rippled`を使用している場合は、[signメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/signing-methods/sign)の`fee_mult_max`パラメーターと`fee_div_max`パラメーターを使用して、署名しようとしている負荷スケーリングに制限を設定することもできます。
* オフラインのマシンから現在のトランザクションコストを調べることはできません。
* [マルチシグ](/ja/docs/concepts/accounts/multi-signing)の場合、トランザクションコストの自動指定は行えません。


## トランザクションコストと失敗したトランザクション

トランザクションコストの目的はXRP Ledgerピアツーピアネットワークを過度な負荷から保護することであるため、トランザクションが成功するかどうかにかかわらず、ネットワークに分散されるすべてのトランザクションにコストが適用されます。ただし、共有のグローバルレジャーに作用するため、トランザクションを検証済みレジャーに含める必要があります。したがって、`rippled`サーバは[`tec`ステータスコード](/ja/docs/references/protocol/transactions/transaction-results)（「tec」は「トランザクションエンジン - 請求手数料のみ」（Transaction Engine - Claimed fee only）を表します）で、失敗したトランザクションをレジャーに含めようとします。

トランザクションコストは、トランザクションが実際に検証済みレジャーに含められた場合に、送信者のXRP残高から差し引かれるだけです。このことは、トランザクションが成功するか`tec`コードとともに失敗するかにかかわらず適用されます。

トランザクションの失敗が[確定](/ja/docs/concepts/transactions/finality-of-results)である場合、`rippled`サーバによるネットワークへの中継は行われません。トランザクションは検証済みレジャーに含まれないため、誰のXRP残高にも影響することはありません。

### 不十分なXRP

`rippled`サーバが最初にトランザクションを評価するとき、送信側アカウントにXRPトランザクションコストを支払うのに十分なXRP残高がない場合は、エラーコード`terINSUF_FEE_B`にてトランザクションを拒否します。これは`ter`（再試行）コードであるため、トランザクションの結果が[確定](/ja/docs/concepts/transactions/finality-of-results)になるまで、`rippled`サーバはネットワークへの中継を行わずにトランザクションを再試行します。

トランザクションはすでにネットワークに配信されているけれども、アカウントにトランザクションコストを支払うのに十分なXRPがない場合は、結果コード`tecINSUFF_FEE`が発生します。この場合、アカウントからは可能なかぎりすべてのXRPが支払われるため、最終的に0 XRPになります。これは、`rippled`がトランザクションをネットワークに中継するかどうかを進行中のレジャーに基づいて判断するために起こります。しかしコンセンサスレジャーを作成するときにトランザクションは破棄されるか並べ替えられることになります。

## Key Resetトランザクション

特殊なケースですが、アカウントの[lsfPasswordSpentフラグ](/ja/docs/references/protocol/ledger-data/ledger-entry-types/accountroot)が無効であるかぎり、そのアカウントはトランザクションコスト`0`で[SetRegularKey](/ja/docs/references/protocol/transactions/types/setregularkey)トランザクションを送信できます。このトランザクションにはアカウントの *マスターキーペア* による署名が必要です。このトランザクションを送信すると、lsfPasswordSpentフラグが有効になります。

この機能は、レギュラーキーが危害を受けた場合に、危害を受けたアカウントに使用可能なXRPがあるかどうかを気にすることなく、そのアカウントを復元できるように設計されています。このようにして、追加のXRPを送信する前にそのアカウントを再び管理できるようになります。

[lsfPasswordSpentフラグ](/ja/docs/references/protocol/ledger-data/ledger-entry-types/accountroot)は無効になります。このフラグを有効にするには、マスターキーペアによって署名されたSetRegularKeyトランザクションを送信します。アカウントでXRPの[支払い](/ja/docs/references/protocol/transactions/types/payment)が受け入れた場合、再び無効になります。

[FeeEscalation Amendment](/ja/resources/known-amendments#feeescalation)が有効な場合、Key Resetトランザクションの名目トランザクションコストがゼロであっても、`rippled`は他のトランザクションよりもKey Resetトランザクションを優先します。

## トランザクションコストの変更

XRP Ledgerは、XRPの価値が長期的に変化することを見越して、最低トランザクションコストを変更するしくみを備えています。変更はすべて、コンセンサスプロセスによる承認が必要です。詳細は、[手数料の投票](/ja/docs/concepts/consensus-protocol/fee-voting)をご覧ください。

## 関連項目

- **コンセプト:**
  - [準備金](/ja/docs/concepts/accounts/reserves)
  - [手数料投票](/ja/docs/concepts/consensus-protocol/fee-voting)
  - [トランザクションキュー](/ja/docs/concepts/transactions/transaction-queue)
- **チュートリアル:**
  - [信頼できるトランザクションの送信](/ja/docs/concepts/transactions/reliable-transaction-submission)
- **リファレンス:**
  - [feeメソッド](/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/fee)
  - [server_infoメソッド](/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/server_info)
  - [FeeSettingsオブジェクト](/ja/docs/references/protocol/ledger-data/ledger-entry-types/feesettings)
  - [SetFee疑似トランザクション](/ja/docs/references/protocol/transactions/pseudo-transaction-types/setfee)