手数料投票

手数料投票

バリデータは基本トランザクションコストの変更と必要準備金の変更に投票することができます。バリデータの設定がネットワークの現在の設定と異なる場合、バリデータはその設定をネットワークに定期的に読み込みます。バリデータの定足数が変更に同意した場合、その後、有効な変更を適用できます。バリデータは、様々な理由、特にXRPの価格の長期的な変更に適応するために、これを行うことがあります。

rippled バリデータのオペレーターは、rippled.cfg フィルの [voting] 節でトランザクションコストと必要準備金を設定できます。注意: 不十分な要件は、Rippleピアツーピア・ネットワークをDoS攻撃にさらす可能性があります。設定できるパラメータは次のとおりです:

パラメータ 説明 推奨値
reference_fee リファレンス・トランザクション(可能な限り最も安いトランザクション)を送信するために破壊されなければならないXRPの量(drop)。(1 XRP = 100万 drop)実際のトランザクションコストはこの値の数倍で、各々のサーバーの負荷に基づいて動的に調整されます。 10 (0.00001 XRP)
account_reserve アカウントが準備金として保有しなければならないXRPの最小金額(drop)。これは、レジャー内に新しいアカウントを作るために送金できる最少額です。 20000000 (20 XRP)
owner_reserve アドレスがレジャー内に所有しているオブジェクトのために、あといくらのXRP(drop)を保有しなければならないか。 5000000 (5 XRP)

投票プロセス

各256番目のレジャーは、「フラグ」レジャーと呼ばれます。(フラグレジャーは、ledger_index の256の剰余が0になるように定義される。)フラグレジャーの直前のレジャーでは、アカウント準備金またはトランザクションコスト設定が現在のネットワーク設定と異なる各バリデータが、そのレジャー・バリデーションと平行して「投票」メッセージを配信し、バリデータが好む値を示します。

フラグレジャーそれ自体では何も起こりませんが、バリデータは信頼する他のバリデータからの投票を受け取り、考慮します。

他のバリデータの投票数を数えた後、各バリデータは、自分の設定とそのバリデータが信頼する多数のバリデータの設定との間で妥協を試みます。(例えば、あるバリデータが最小トランザクションコストを10から100に引き上げたいが、ほとんどのバリデータが10から20に増やしたい場合、そのバリデータはコストを20に引き上げる変更で解決します。しかし、そのバリデータは決して10より小さく100より大きい値に決めることはありません。)妥協が可能な場合、バリデータはフラグレジャーに続くレジャーの提案に、SetFee 疑似トランザクションを挿入します。同じ変更をしたい他のバリデータは、同じレジャーに対するそれらの提案に、同じ SetFee 疑似トランザクションを挿入します。(既存のネットワーク設定と一致する設定が一致するバリデータは何もしません。)SetFee 疑似トランザクションがコンセンサス・プロセスを生き延びて検証されたレジャーに含まれると、SetFee 疑似トランザクションによって示された新たなトランザクションコストおよび準備金の設定は、次のレジャーから有効になります。

要約すると:

  • Flag ledger -1: バリデータが投票を送信する。
  • Flag ledger: バリデータはどの SetFee を含めるか投票を集計して決定します。(もしあれば)
  • Flag ledger +1: バリデータは、それらが提案するレジャーに SetFee 疑似トランザクションを挿入します。
  • Flag ledger +2: SetFee 疑似トランザクションがコンセンサスに達すると、新しい設定が有効になります。

注意:

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