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

html, parent, blurb, labels

html	parent	blurb	labels
transaction-cost.html	transactions.html	トランザクションコストとはトランザクション送信のために償却される少額のXRPで、これによってレジャーがスパムから保護されます。トランザクションコストの適用方法について説明します。	手数料 トランザクション送信

トランザクションコスト

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の価値が長期的に変化することを見越して、最低トランザクションコストを変更するしくみを備えています。変更はすべて、コンセンサスプロセスによる承認が必要です。詳細は、手数料の投票を参照してください。

関連項目

• コンセプト:
  • 準備金
  • 手数料投票
  • トランザクションキュー
• チュートリアル:
  • 信頼できるトランザクションの送信
• リファレンス:
  • [feeメソッド][]
  • [server_infoメソッド][]
  • FeeSettingsオブジェクト
  • [SetFee疑似トランザクション][]

{% include '_snippets/rippled-api-links.md' %} {% include '_snippets/tx-type-links.md' %} {% include '_snippets/rippled_versions.md' %}