トランザクションコスト
XRP LedgerをスパムやDoS攻撃から守るため、各トランザクションでは少額のXRPが消却されます。この トランザクションコスト はネットワークの負荷とともに増加するように設計されており、故意または不注意にネットワークに過剰な負荷をかけると非常に高くつきます。
各トランザクションのトランザクションコストを支払う際には、消却するXRPの額を指定する必要があります。
現在のトランザクションコスト
ネットワークが標準のトランザクションに必要とする現在の最低トランザクションコストは0.00001 XRP（10 drop）です。これは負荷が通常より高くなると増加することがあります。
また、現在のトランザクションコストについてrippledに問い合わせることもできます。
特別なトランザクションコスト
一部のトランザクションには異なるトランザクションコストがあります。
| トランザクション | 負荷スケーリング前のコスト |
|---|---|
| Referenceトランザクション（ほとんどのトランザクション） | 10 drop |
| Key Resetトランザクション | 0 |
| マルチシグトランザクション | 10 drop × （1 + 署名の数） |
| フルフィルメントを伴うEscrowFinishトランザクション | 10 drop × （33 + （バイト単位のフルフィルメントサイズ ÷ 16）） |
| AccountDeleteトランザクション | 2,000,000 drop |
トランザクションコストの受取人
トランザクションコストは誰かに支払われるものではありません。XRPは取り消し不能で消却されます。XRPを新たに作ることはできないため、XRPの希少性が高まり、XRPの価値を高めることによって、すべてのXRP保有者に利益がもたらされます。
負荷コストとオープンレジャーコスト
FeeEscalation Amendmentが有効な場合、トランザクションコストには以下の2つのしきい値があります。
- トランザクションコストが
rippledサーバの負荷ベーストランザクションコストのしきい値を満たしていない場合、サーバはそのトランザクションを完全に無視します。（このロジックはAmendmentの有無にかかわらず基本的に変わりません。） - トランザクションコストが
rippledサーバのオープンレジャーコストのしきい値を満たしていない場合、サーバはそのトランザクションを後のレジャーのキューに入れます。
これによってトランザクションは大まかに以下の3つのカテゴリに分けられます。
- トランザクションコストが低く設定され、負荷ベーストランザクションコストによって拒否されるトランザクション。
- トランザクションコストが高く設定され、現在のオープンレジャーに組み入れられるトランザクション。
- その中間のトランザクション。後のレジャーバージョンのキューに入れられます。
ローカル負荷コスト
各rippledサーバには、現在の負荷に基づいてコストしきい値が保持されています。送信するトランザクションのFee値がrippledサーバの現在の負荷ベーストランザクションコストより低い場合、そのサーバはトランザクションの適用も中継もしません。（注記: 管理者接続を介してトランザクションを送信する場合、トランザクションがスケーリングされていない最低トランザクションコストを満たすかぎり、サーバはそのトランザクションを適用し、中継します。）トランザクションのFee値が大半のサーバの要件を満たさないかぎり、そのトランザクションがコンセンサスプロセスを完了する可能性は極めて低くなります。
オープンレジャーコスト
rippledサーバにはトランザクションコストを強制する2つ目のメカニズムがあり、 オープンレジャーコスト と呼ばれます。トランザクションがXRPによるオープンレジャーコスト要件を満たす場合のみ、そのトランザクションをオープンレジャーに含めることができます。オープンレジャーコスト要件を満たさないトランザクションは、次のレジャーのキューに入れられます。
新しいレジャーバージョンごとに、サーバは前のレジャーのトランザクション数に基づいてオープンレジャーに含めるトランザクション数のソフトリミットを選択します。オープンレジャーコストは、オープンレジャー内のトランザクション数がソフトリミットと等しくなるまでは、スケーリングされていない最低トランザクションコストと同じです。それを超えると、オープンレジャーコストはオープンレジャーに含まれるトランザクションごとに急激に増加します。次のレジャーでは、現行のレジャーにソフトリミットを超えるトランザクションが含まれていれば、サーバはソフトリミットを高くし、コンセンサスプロセスに5秒より時間が掛かる場合はソフトリミットを低くします。
オープンレジャーコストの水準は、絶対的なトランザクションコストではなく標準的なトランザクションコストに比例しています。標準よりも高い要件を持つトランザクションタイプ（マルチシグトランザクションなど）は、オープンレジャーコストを満たすために最低限のトランザクションコスト要件を持つトランザクションよりも多く支払う必要があります。
関連項目: rippledリポジトリー内のFee Escalationの説明。
キューに入れられたトランザクション
rippledが、サーバのローカル負荷コストは満たすがオープンレジャーコストは満たさないトランザクションを受け取った場合、サーバはそのトランザクションが後のレジャーに「含まれる可能性」を判断します。その可能性が高いと判断すれば、サーバはそのトランザクションをトランザクションキューに追加し、他のネットワークメンバーにトランザクションを中継します。そうでない場合、サーバはトランザクションを破棄します。トランザクションコストは検証済みレジャーに含まれるトランザクションにのみ適用されるため、サーバは、トランザクションコストを支払わないトランザクションにより生じるネットワーク負荷量を最低限に抑えようとします。
キューに入れられたトランザクションの詳細は、トランザクションキューをご覧ください。
Referenceトランザクションコスト
「Referenceトランザクション」とは、負荷スケーリング前のトランザクションコストという観点からは、最も安価な（無料ではない）トランザクションと言えます。ほとんどのトランザクションのコストはReferenceトランザクションと同じです。マルチシグトランザクションなど一部のトランザクションでは、このコストの数倍のコストが必要です。オープンレジャーコストが上昇する場合は、コスト水準はトランザクションの基本コストに比例します。
手数料レベル
手数料レベル は、トランザクションの最少コストと実際のコストとの相対的な差を表します。オープンレジャーコストは絶対的なコストではなく手数料レベルで評価されます。比較する場合は以下の表をご覧ください。
| トランザクション | drop単位の最少コスト | 手数料レベルでの最少コスト | drop単位で倍のコスト | 手数料レベルで倍のコスト |
|---|---|---|---|---|
| Referenceトランザクション（ほとんどのトランザクション） | 10 | 256 | 20 | 512 |
| 4つの署名を持つマルチシグトランザクション | 50 | 256 | 100 | 512 |
| Key Resetトランザクション | 0 | （事実上無限） | なし | （事実上無限） |
| 32バイトのプリイメージ付きのEscrowFinishトランザクション。 | 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単位の最低トランザクションコストをレポートします。この設計により、rippledでは整数のみでトランザクションコストの計算ができ、サーバ負荷の微調整も十分に行えます。実際のトランザクションコストの計算は以下のようになります。
drop単位の現在のトランザクションコスト = (base_fee × load_factor) ÷ load_base
トランザクションコストの指定
署名されたすべてのトランザクションのFeeフィールドには、トランザクションコストを含める必要があります。署名されたトランザクションのすべてのフィールドと同様に、このフィールドは署名の無効化を行わなければ変更できません。
通常、XRP Ledgerはトランザクションを署名された とおりに 実行します。（少なくとも、分散型コンセンサスネットワーク全体をコーディネートしてそれ以外のことを実行するのは難しいと思われます。）したがって、Feeフィールドに指定されたXRPの額が、ネットワーク内で指定されているどの現在の最低トランザクションコストをもはるかに上回っていたとしても、指定したとおりのXRPがすべてのトランザクションで消却されます。トランザクションコストでは、アカウントの準備金用に確保していたXRPも消却される場合があります。
トランザクションに署名する前に、現在の負荷ベースのトランザクションコストを調べることをお勧めします。負荷スケーリングが原因でトランザクションコストが高い場合は、低下するまで待つことができます。トランザクションをすぐに送信するつもりがない場合は、トランザクションコストにおける将来の負荷ベースの変動を考慮して、少し高めのトランザクションコストを指定することをお勧めします。
トランザクションコストの自動指定
オンラインでトランザクションに署名する場合は、Feeフィールドを省略できます。この場合、rippledまたはクライアントライブラリが現在の要件に照らしてピアツーピアネットワークの状態を確認し、トランザクションに署名する前にFee値を追加します。ただし、このようなトランザクションコストへの自動入力にはいくつかの欠点と制限事項があります。
- トランザクションに署名し、分散するまでの間にネットワークのトランザクションコストが上昇した場合、そのトランザクションは承認されない場合があります。
- 最悪の場合、トランザクションに
LastLedgerSequenceパラメーターが含まれているか、同じSequence番号を使用する新しいトランザクションによってそのトランザクションがキャンセルされない限り、トランザクションは明確に承認も拒否もされない状態のままとなってしまいます。ベストプラクティスについては、信頼できるトランザクションの送信をご覧ください。
- 最悪の場合、トランザクションに
- 署名するトランザクションの
Feeフィールドの正確な値は事前にわかりません。rippledを使用している場合は、signメソッドのfee_mult_maxパラメーターとfee_div_maxパラメーターを使用して、署名しようとしている負荷スケーリングに制限を設定することもできます。
- オフラインのマシンから現在のトランザクションコストを調べることはできません。
- マルチシグの場合、トランザクションコストの自動指定は行えません。
トランザクションコストと失敗したトランザクション
トランザクションコストの目的はXRP Ledgerピアツーピアネットワークを過度な負荷から保護することであるため、トランザクションが成功するかどうかにかかわらず、ネットワークに分散されるすべてのトランザクションにコストが適用されます。ただし、共有のグローバルレジャーに作用するため、トランザクションを検証済みレジャーに含める必要があります。したがって、rippledサーバはtecステータスコード（「tec」は「トランザクションエンジン - 請求手数料のみ」（Transaction Engine - Claimed fee only）を表します）で、失敗したトランザクションをレジャーに含めようとします。
トランザクションコストは、トランザクションが実際に検証済みレジャーに含められた場合に、送信者のXRP残高から差し引かれるだけです。このことは、トランザクションが成功するかtecコードとともに失敗するかにかかわらず適用されます。
トランザクションの失敗が確定である場合、rippledサーバによるネットワークへの中継は行われません。トランザクションは検証済みレジャーに含まれないため、誰のXRP残高にも影響することはありません。
不十分なXRP
rippledサーバが最初にトランザクションを評価するとき、送信側アカウントにXRPトランザクションコストを支払うのに十分なXRP残高がない場合は、エラーコードterINSUF_FEE_Bにてトランザクションを拒否します。これはter（再試行）コードであるため、トランザクションの結果が確定になるまで、rippledサーバはネットワークへの中継を行わずにトランザクションを再試行します。
トランザクションはすでにネットワークに配信されているけれども、アカウントにトランザクションコストを支払うのに十分なXRPがない場合は、結果コードtecINSUFF_FEEが発生します。この場合、アカウントからは可能なかぎりすべてのXRPが支払われるため、最終的に0 XRPになります。これは、rippledがトランザクションをネットワークに中継するかどうかを進行中のレジャーに基づいて判断するために起こります。しかしコンセンサスレジャーを作成するときにトランザクションは破棄されるか並べ替えられることになります。
Key Resetトランザクション
特殊なケースですが、アカウントのlsfPasswordSpentフラグが無効であるかぎり、そのアカウントはトランザクションコスト0でSetRegularKeyトランザクションを送信できます。このトランザクションにはアカウントの マスターキーペア による署名が必要です。このトランザクションを送信すると、lsfPasswordSpentフラグが有効になります。
この機能は、レギュラーキーが危害を受けた場合に、危害を受けたアカウントに使用可能なXRPがあるかどうかを気にすることなく、そのアカウントを復元できるように設計されています。このようにして、追加のXRPを送信する前にそのアカウントを再び管理できるようになります。
lsfPasswordSpentフラグは無効になります。このフラグを有効にするには、マスターキーペアによって署名されたSetRegularKeyトランザクションを送信します。アカウントでXRPの支払いが受け入れた場合、再び無効になります。
FeeEscalation Amendmentが有効な場合、Key Resetトランザクションの名目トランザクションコストがゼロであっても、rippledは他のトランザクションよりもKey Resetトランザクションを優先します。
トランザクションコストの変更
XRP Ledgerは、XRPの価値が長期的に変化することを見越して、最低トランザクションコストを変更するしくみを備えています。変更はすべて、コンセンサスプロセスによる承認が必要です。詳細は、手数料の投票をご覧ください。