準備金

XRP Ledger は、スパムや悪意のある使用の結果として共有グローバル台帳が過度に大きくならないように、XRPでの必要準備金を適用します。目的は、現在の日用品レベルのマシンが常に現在のレジャーをRAMに収め、ディスク上の全レジャー履歴を常にディスクに収めることができるように、技術の向上に合わせてレジャーの増大を制限することです。

トランザクションを送信するには、アドレスは共有グローバル台帳に最小量のXRPを保持する必要があります。このXRPを他のアドレスに送ることはできません。新しいアドレスを作るためには、必要準備金を満たすための十分なXRPを送る必要があります。

現時点での最小の必要準備金は 20 XRP です。（これはレジャーに他のオブジェクトを有していないアドレスのコストです。）

ベースリザーブとオーナーリザーブ

必要準備金は2つの部分に分かれています。

• ベースリザーブは、レジャーのすべてのアドレスに必要な最少額のXRPです。現時点で 20 XRP（20000000 drops）です。
• オーナーリザーブは、アドレスがレジャー内で所有する各オブジェクトごとに増加する必要準備金です。現時点で、これは1アイテムにつき 5 XRP（5000000 drops）です。

オーナー・リザーブ

レジャー内の多くのオブジェクトは特定のアドレスによって所有され、そのアドレスの必要準備金にカウントされます。レジャーからオブジェクトを削除すると、オブジェクトは所有者の必要準備金にカウントされなくなります。

• オファーはそれらを発行したアドレスによって所有されています。トランザクションは、完全に消費されるか、または積み立て不足が判明したオファーを自動的に削除します。あるいは、所有者は、OfferCancel トランザクションを送信することによって、または OfferSequence パラメータを含む OfferCreate トランザクションを送信することによって、オファーを取り消すことができます。
• トラストラインは2つのアドレス間で共有されます。オーナーリザーブは、アドレスがコントロールするフィールドがデフォルト状態であるかどうかに応じて、1つまたは両方のアドレスに適用されます。詳細については、Contributing to the Owner Reserve を参照してください。
• 1つの SignerList は、メンバーの数に応じて、オーナーリザーブのために3～10個のオブジェクトとしてカウントされます。参照: SignerLists and Reserves
• オーナーディレクトリは、アドレスのオーナーリザーブに寄与するすべてのレジャー・ノードをリストします。ただし、オーナーディレクトリ自体は準備金に対してカウントされません。

オーナーリザーブのエッジケース

XRP Ledger は、OfferCreate トランザクションが資産を保持する意図の明示的なステートメントであるとみなします。そのようなトラストラインが存在しない場合、オファーを消費することにより、taker_pays 通貨の（上限 0、およびその上限を超える残高の）トラストラインが自動的に作成されます。ただし、オファーの所有者が新しいトラストラインの必要オーナーリザーブを満たすために十分なXRPを保持していない場合、そのオファーは積み立て不足とみなされます。参照: Lifecycle of an Offer

必要準備金を下回る

トランザクション処理中に、トランザクションコストは送信アドレスのXRP残高の一部を破棄します。これにより、アドレスのXRPが必要準備金を下回る可能性があります。

アドレスが現在の必要準備金よりも少ないXRPを保持している場合、XRPを他のノードに転送するトランザクションを送信したり、自身の準備金を増やすことはできません。それでも、そのアドレスはレジャー内に存在し続け、トランザクションコストを支払うのに十分なXRPを持っている限り、他のトランザクションを送信することはできます。必要準備金を満たすために十分なXRPを受け取った場合、またはそのアドレスのXRP保有額よりも必要準備金が少なくなった場合、そのアドレスはすべてのタイプのトランザクションを再び送信できるようになります。

Tip: アドレスが必要準備金を下回ったとき、追加のXRPまたは既存のトラストライン上のその他の通貨を得るために、新しい OfferCreate トランザクションを送信することができます。これらのトランザクションでは、新しいトラストラインやレジャー内に Offer ノードを作成することはできないため、既にオーダーブックにあるオファーを消費するトレードのみを実行することができます。

必要準備金の変更

XRP Ledger には、XRPの価値の長期的な変動に対して必要準備金を調整する仕組みがあります。すべての変更は、コンセンサス・プロセスによって承認されなければなりません。詳細については、Fee Voting を参照してください。

注意:

本ドキュメントは、リップル社が公式サイトで公開している『Reserves』を私が個人的に翻訳したものです。注意して頂きたいのは、当方は現役のエンジニアではありませんし、Rippleについての技術的な探求心があるわけでもありません。誤訳などの間違いがあるかもしれないため、公式サイトの英語で書かれた原文もあわせて読むことをお勧めします。