mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-27 23:25:51 +00:00
Merge pull request #1279 from develoQ/translate-to-japanese
Translate to Japanese
This commit is contained in:
Rome Reginelli
157
content/concepts/consensus-network/invariant-checking.ja.md
Normal file
157
content/concepts/consensus-network/invariant-checking.ja.md
Normal file
@@ -0,0 +1,157 @@
|
||||
---
|
||||
html: invariant-checking.html
|
||||
parent: consensus-network.html
|
||||
blurb: 不変性チェックとは何か、なぜ存在するのか、どのように機能するのか、どのような不変性チェックが有効なのかを理解することができます。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
- セキュリティ
|
||||
---
|
||||
# 不変性チェック
|
||||
|
||||
不変性チェックは、XRP Ledgerの安全機能です。これは、通常のトランザクション処理とは別に、すべての取引において特定の「不変量」が真であることを保証する一連のチェックで構成されています。
|
||||
|
||||
多くの安全機能がそうであるように、私たちは不変性チェックが実際に何もする必要がないことを望んでいます。しかし、XRP Ledger の不変量は XRP Ledger のトランザクション処理に対するハードリミットを定義しているため、それを理解することは有用であり、万が一不変量チェックに違反したためにトランザクションが失敗した場合に問題を認識するために有用です。
|
||||
|
||||
不変性はトリガーされるべきではありませんが、まだ発見されていない、あるいは作成されてもいないバグからXRP Ledgerの整合性を確保するものです。
|
||||
|
||||
|
||||
## なぜ存在するのか
|
||||
|
||||
- XRP Ledgerのソースコードは複雑かつ膨大であり、コードが誤って実行される可能性が高いです。
|
||||
- トランザクションを誤って実行した場合のコストは高く、どのような基準でも許容されるものではありません。
|
||||
|
||||
具体的には、不正なトランザクションの実行により、無効または破損したデータが作成され、後にネットワーク上のサーバーを「動作不可能」な状態にすることで一貫してクラッシュさせ、ネットワーク全体を停止させる可能性があります。
|
||||
|
||||
不正なトランザクションの処理は、XRP Ledgerの信頼という価値を損なうことになリマス。不変性チェックは、信頼性という機能を付加するため、XRP Ledger 全体に価値を提供します。
|
||||
|
||||
|
||||
|
||||
## 仕組み
|
||||
|
||||
不変性チェッカーは、各トランザクションの後にリアルタイムで自動的に実行される第2層のコードです。トランザクションの結果がレジャーにコミットされる前に、不変性チェッカーはそれらの変更が正しいかどうかを検証します。もしトランザクションの結果がXRP Ledgerの厳格なルールに沿わない場合、不変性チェッカーはそのトランザクションを拒否します。このように拒否されたトランザクションは結果コード `tecINVARIANT_FAILED` を持ち、何の効果もなくレジャーに含まれます。
|
||||
|
||||
トランザクションを `tec` クラスのコードでレジャーに含めるには、何らかの最小限の処理が必要です。この最小限の処理でも不変条件に沿わない場合、トランザクションは `tefINVARIANT_FAILED` というコードで失敗し、レジャーには一切含まれません。
|
||||
|
||||
|
||||
## 有効な不変条件
|
||||
|
||||
XRP Ledgerは、各トランザクションについて、以下のすべての不変条件をチェックします。
|
||||
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L92 "ソース")
|
||||
|
||||
- [トランザクション手数料チェック](#トランザクション手数料チェック)
|
||||
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L118 "ソース")
|
||||
|
||||
- [XRPは作成されません](#XRPは作成されません)
|
||||
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L146 "ソース")
|
||||
|
||||
- [アカウントルートが削除されていない](#アカウントルートが削除されていない)
|
||||
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L173 "ソース")
|
||||
|
||||
- [XRPの残高確認](#XRPの残高確認)
|
||||
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L197 "ソース")
|
||||
|
||||
- [レジャーエントリ形式の一致](#レジャーエントリ形式の一致)
|
||||
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L224 "ソース")
|
||||
|
||||
- [XRPのトラストラインはありません](#XRPのトラストラインはありません)
|
||||
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L251 "ソース")
|
||||
|
||||
- [不正なオファーでない](#不正なオファーでない)
|
||||
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L275 "ソース")
|
||||
|
||||
- [0のエスクローでない](#0のエスクローでない)
|
||||
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h#L300 "ソース")
|
||||
|
||||
- [有効な新規アカウントルート](#有効な新規アカウントルート)
|
||||
|
||||
|
||||
### トランザクション手数料チェック
|
||||
|
||||
- **不変条件:**
|
||||
- [トランザクションコスト](transaction-cost.html)の金額は決してマイナスになってはならず、またトランザクションで指定されたコストより大きくなってはいけません。
|
||||
|
||||
|
||||
### XRPは作成されません
|
||||
|
||||
- **不変条件:**
|
||||
- トランザクションはXRPを生成してはならず、XRPを破棄するのみです[トランザクションコスト](transaction-cost.html)。
|
||||
|
||||
|
||||
### アカウントルートが削除されていない
|
||||
|
||||
- **不変条件:**
|
||||
- [アカウント](accounts.html)は、[AccountDeleteトランザクション][]によってのみレジャーから削除することができます。
|
||||
- AccountDelete が成功すると、常にちょうど1つのアカウントが削除されます。
|
||||
|
||||
|
||||
### XRPの残高確認
|
||||
|
||||
- **不変条件:**
|
||||
- アカウントのXRP残高はXRPの形式である必要があり、0未満または1000億XRPを超えることはできません。
|
||||
|
||||
|
||||
### レジャーエントリ形式の一致
|
||||
|
||||
- **不変条件:**
|
||||
- 変更されたレジャーの項目は形式が一致し、追加された項目は[有効なタイプ](ledger-object-types.html)である必要があります。
|
||||
|
||||
|
||||
### XRPのトラストラインはありません
|
||||
|
||||
- **不変条件:**
|
||||
- XRPを使用した[トラストライン](trust-lines-and-issuing.html)は作成できません。
|
||||
|
||||
|
||||
### 不正なオファーでない
|
||||
|
||||
- **不変条件:**
|
||||
- [オファー](offer.html#オファー)は負でない金額でなければならず、XRP同士であってはいけません。
|
||||
|
||||
|
||||
### 0のエスクローでない
|
||||
|
||||
- **不変条件:**
|
||||
- [エスクロー](escrow-object.html)エントリーは、0XRP以上1000億XRP未満を保有している必要があります。
|
||||
|
||||
|
||||
### 有効な新規アカウントルート
|
||||
|
||||
- **不変条件:**
|
||||
- 新しい[アカウントルート](accountroot.html)は、支払いの結果でなければなりません。
|
||||
- 新しいアカウントルートは、正しい開始[シーケンス](basic-data-types.html#アカウントシーケンス)を持たなければなりません。
|
||||
- 1つのトランザクションで複数の新しい[アカウント](accounts.html)を作成してはいけません。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **ブログ:**
|
||||
- [レジャーの保護: 不変性チェック](https://xrpl.org/blog/2017/invariant-checking.html)
|
||||
|
||||
- **リポジトリ:**
|
||||
- [Invariant Check.h](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.h)
|
||||
- [Invariant Check.cpp](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/app/tx/impl/InvariantCheck.cpp)
|
||||
- [System Parameters](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/SystemParameters.h#L43)
|
||||
- [XRP Amount](https://github.com/ripple/rippled/blob/develop/src/ripple/basics/XRPAmount.h#L244)
|
||||
- [Ledger Formats](https://github.com/ripple/rippled/blob/023f5704d07d09e70091f38a0d4e5df213a3144b/src/ripple/protocol/LedgerFormats.h#L36-L94)
|
||||
|
||||
|
||||
- **その他:**
|
||||
- [Authorized Trust Lines](authorized-trust-lines.html)
|
||||
- [XRPの特性](xrp.html#XRPの特性)
|
||||
- [トランザクションの残高変化の計算](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
185
content/concepts/consensus-network/negative-unl.ja.md
Normal file
185
content/concepts/consensus-network/negative-unl.ja.md
Normal file
@@ -0,0 +1,185 @@
|
||||
---
|
||||
html: negative-unl.html
|
||||
parent: consensus-network.html
|
||||
blurb: ネガティブUNLが部分的な停止時に台帳の耐障害性を向上させることを理解する。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# ネガティブUNL
|
||||
|
||||
_([NegativeUNL Amendment](known-amendments.html#negativeunl)が必要です。)_
|
||||
|
||||
ネガティブUNLは、XRPレジャーの[コンセンサスプロトコル](consensus.html)の機能で、バリデータの部分的な停止中にネットワークの前進を可能にする _liveness_ を向上させるものです。ネガティブUNLを使用すると、サーバーは現在オンラインかつ稼働中のバリデータに基づいて有効なUNLを調整するため、信頼できるバリデータが複数オフラインの場合でも、新しい [レジャーバージョン](ledgers.html) を _validated_ と宣言することができるようになるのです。
|
||||
|
||||
ネガティブUNLは、部分的な停止中に結果を確定するネットワークの能力を向上させる以外、ネットワークのトランザクション処理方法やトランザクションの結果に影響を与えることはありません。
|
||||
|
||||
## 背景
|
||||
|
||||
XRPレジャープロトコルの各サーバーは、UNL（Unique Node List）と呼ばれる、共謀しないよう信頼できるバリデータのリストを持ち、各サーバーは、信頼できるバリデータが十分に新しいレジャーバージョンに合意したときのコンセンサスに基づいて、レジャーバージョンの検証を独自に決定しています。(デフォルトの構成では、リップル社が十分にユニークで信頼性が高く、独立性が高いと考えるバリデータからなる、リップル社が署名した推奨UNLを使用しています)。標準的な定足数要件は、信頼できるバリデータの少なくとも80%が合意することである。
|
||||
|
||||
信頼できるバリデータの20%以上がオフラインになるか、ネットワークの残りの部分と通信できなくなると、ネットワークは定足数に達しないため、新しいレジャーの検証を停止する。これは、取引の結果が確定した後に変更されないようにするための設計上の選択である。このような状況では、残りのサーバーはまだオンラインであり、過去および暫定的なトランザクションデータを提供できるが、新しいトランザクションの最終的で不変の結果を確認することはできない。
|
||||
|
||||
しかしこれは、広く信頼されているバリデータがいくつかオフラインになった場合、ネットワークが前進しなくなる可能性があることを意味する。2020-10-06現在、リップル社が推奨するUNLには34人のバリデータがいるので、そのうち7人以上がオフラインになると、ネットワークの前進が止まってしまうことになります。さらに、1人または2人のバリデータが長期間オフラインになると、ネットワークは残りのバリデータ間の不一致の余地が少なくなり、コンセンサスの達成に時間がかかる可能性があります。
|
||||
|
||||
## 要約
|
||||
|
||||
ハードウェアのメンテナンス、ソフトウェアのアップグレード、インターネット接続の問題、標的型攻撃、人為的ミス、ハードウェアの故障、自然災害などの外部環境など、多くの原因でバリデータは一時的に利用できなくなる可能性があるため、多様なバリデータのセットで100%の稼働時間を維持を期待することは合理的ではありません。
|
||||
|
||||
「ネガティブUNL」とは、**オフラインまたは故障していると思われる信頼できる バリデータのリスト**であり、残存バリデータの総意として宣言されるものである。ネガティブUNLに含まれるバリデータは、新しいレジャーのバージョンがコンセンサスを得たかどうか を判断する際には無視される。
|
||||
|
||||
ネガティブUNL上のバリデータがオンラインに復帰し、一貫性のある検証投票を送信すると、 残りのバリデータはしばらくしてそのバリデータをネガティブUNLから削除します。
|
||||
|
||||
バリデータが一度に1つか2つオフラインになった場合、残りのバリデータはネガティブUNLを使用して、徐々に有効UNLを調整し、ネットワークが定足数を達成するのに _オンライン_ バリデータの80%しか必要としないようにすることができる。ネットワークが分断されるのを防ぐため、定足数はバリデータ _全体_ の60%以上というハードな最低値を持つ。
|
||||
|
||||
20%以上のバリデータが突然一度にオフラインになった場合、残りのサーバーは新しいレジャーを検証するのに必要な定足数を達成できないため、新しいレジャーを検証することができない。しかし、そのようなサーバーでも、コンセンサスラウンドを重ねることで暫定的な前進は可能である。時間が経つにつれて、残りのバリデータは暫定的なレジャーにネガティブUNLの変更を適用し、有効なUNLを調整し続ける。最終的に、この状況が続けば、ネットワークは暫定的なレジャーのバージョンから調整後のネガティブUNLを使用して、レジャーの検証を完全に再開することが可能である。
|
||||
スタンドアロンモードでは、サーバーはコンセンサスを使用しないので、ネガティブUNLは[スタンドアロンモード](rippled-server-modes.html)に影響を及ぼさない。
|
||||
|
||||
|
||||
## ネガティブUNLをテストに使用できるようにする
|
||||
|
||||
ネガティブUNL機能は現在[Devnet](parallel-networks.html)でテストすることが可能である。ネガティブUNL機能をテストするには、[XRPL Altnetへのrippledの接続](connect-your-rippled-to-the-xrp-test-net.html) にあるように `rippled.cfg` ファイルに `[features]` 節 を追加したり変更したりすることで可能です。
|
||||
|
||||
|
||||
|
||||
## 仕組み
|
||||
|
||||
ネガティブUNLは[コンセンサスプロセス](consensus.html) と密接に関連し、不利な状況下でもネットワークの継続性と信頼性を維持できるように安全策をとって設計されたものである。すべての信頼できるバリデータが正常に動作している場合、ネガティブUNLは使用されず、何の効果もない。一部のバリデータがオフラインまたは同期していないように見えるとき、ネガティブUNLルールは有効になる。
|
||||
|
||||
ネガティブUNLは意図的にゆっくりとした速度で変化するように設計されており、あるバージョンのレジャーの合意形成プロセスにおいて、どのネガティブUNLを適用すべきかという時間ベースの不一致を回避するためである。
|
||||
|
||||
|
||||
### 信頼性評価
|
||||
|
||||
ネットワーク上の各サーバーは、共謀しないように信頼するバリデータのリストであるUNLを持っています。(デフォルトでは、サーバーの正確なUNLはリップル社が公表している推奨バリデータリストに基づいて暗黙的に設定されます)。各サーバーは、信頼できるバリデータの「信頼性」を1つの指標で追跡します。それは、直近256件のレジャーのうち、バリデータの検証投票がサーバーの考えるコンセンサスと一致した割合です。言い換えれば
|
||||
|
||||
> 信頼性 = V<sub>a</sub> ÷ 256
|
||||
|
||||
V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過去256のレジャーに対して、1人のバリデータから受け取った検証票の総数である。
|
||||
|
||||
この信頼性指標は、バリデータの可用性 _及び_ バリデータの挙動を測定するものである。バリデータがネットワークの他の部分と同期しており、採点サーバと同じプロトコル規則に 従っている場合、そのバリデータの信頼性スコアは高くなるはずである。バリデータの信頼性スコアは、以下のような理由で低下することがある。
|
||||
|
||||
- バリデータ間のネットワーク接続が悪いため、バリデータの検証票がサーバーに届かない。
|
||||
- バリデータが動作を停止したり、過負荷になっている。
|
||||
- 様々な理由により、バリデータはサーバと同じプロトコルルールに従わない。可能性としては、設定ミス、ソフトウェアのバグ、意図的に[異なるネットワーク](parallel-networks.html)に従っている、または悪意ある行動などが考えられます。
|
||||
|
||||
バリデータの信頼性が **50%** 未満である場合、そのバリデータはネガティブUNLに追加される候補である。ネガティブUNLから削除するには、バリデータの信頼性が **80%** 以上でなければならない。
|
||||
|
||||
バリデータを含む各サーバーは、信頼できるバリデータ全員について独自に信頼性スコアを算出している。あるバリデータの信頼性について、サーバーが異なると結論が異なることがある。それは、そのバリデータの投票が一方のサーバーに届いて他方のサーバーに届かなかったり、特定のレジャーについて意見が異なることが多かったり少なかったりするためである。あるバリデータをネガティブUNLに追加または削除するには、信頼できるバリデータの総意として、あるバリデータが信頼性の閾値を超えるか下回るかに合意する必要がある。
|
||||
|
||||
**ヒント:** バリデータは自分自身の信頼性を追跡するが、自分自身をネガティブUNLに加えることは提案しない。バリデータの信頼性測定は、バリデータの投票がネットワークを通じて どの程度うまく伝わるかを考慮できないので、外部のサーバーからの測定値よりも 信頼性が低い。
|
||||
|
||||
|
||||
|
||||
### ネガティブUNLの変更
|
||||
|
||||
レジャーバージョンが256で均等に割り切れる場合、_フラグレジャー_ とみなされます。ネガティブUNLはフラグレジャーでのみ変更可能です。(フラグレジャーは、XRPレジャーメインネットで約15分に1回発生します。トランザクション量の少ないテストネットワークでは、もっと低頻度な場合があります)
|
||||
|
||||
各フラグレジャーは、以下の全ての変更が適用されます。
|
||||
|
||||
1. 前のフラグレジャーで予定されていたネガティブUNLの変更は、次のレジャーバージョンから有効となる。このフラグレジャーの検証のための合意プロセスそのものは、予定されていた変更を利用しない。
|
||||
|
||||
**注記:** これは、[トランザクション](transaction-basics.html)や[疑似トランザクション](pseudo-transaction-types.html)を行わずにレジャーの状態データを変更する唯一の機会です。
|
||||
|
||||
2. ネガティブUNLが満杯でない場合、各サーバーは信頼度50%未満のバリデータの中から、**最大1つ**のバリデータをネガティブUNLに追加することを提案する。
|
||||
3. ネガティブUNLが空でない場合、各サーバーはネガティブUNLから **最大1つ**のバリデータを削除することを提案する。サーバーがバリデータをネガティブUNLから削除することを提案できる理由は2つある。
|
||||
- バリデータの信頼度が80%を超えている。
|
||||
- 自身のUNLにそのバリデーターを持たない。(バリデータが永久に停止した場合、このルールは、サーバーの設定済み UNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが 削除されることを確実にする)。
|
||||
4. ネガティブUNLの変更案がコンセンサスに達した場合、その変更は次のフラグレジャーから適用される予定である。この方法で最大1つの追加と1つの削除をスケジュールすることができる。
|
||||
|
||||
ネガティブUNLにバリデータを追加したり削除したりする提案は[UNLModify pseudo-transactions][]の形式を取る。それぞれの擬似トランザクションは他の[擬似トランザクション](pseudo-transaction-types.html)と同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバーの総意として同じ変更を提案する必要がある。
|
||||
|
||||
ネガティブUNLの予定された有効な変更は、レジャーの状態データの中の[ネガティブUNLオブジェクト](negativeunl.html)に追跡される。
|
||||
|
||||
|
||||
### ネガティブUNLの制限
|
||||
|
||||
ネットワークが2つ以上のサブネットワークに分断されるのを防ぐために、ネガティブUNLは定足数要件をUNLエントリ全体の60%未満に減らすことができない。これを強制するために、サーバーはネガティブUNL上のバリデータ数がサーバーの設定済みUNL内のバリデータ数の25%(切り捨て)である場合、ネガティブUNLが "満杯 "になったと見なす。(この25%は、25%のバリデータが削除された場合、残りの75%のバリデータの 80%の合意は元の数の60%に等しいという計算に基づいている)。もしサーバーがネガティブUNLが一杯になったと判断した場合、ネガティブUNLへの新たな追加は提案されない。
|
||||
|
||||
|
||||
### 複数のバリデーター候補から選択する
|
||||
|
||||
信頼性の閾値に基づき、複数のバリデータがネガティブUNLに追加される候補となる可能性がある。一度に最大1つのバリデータをネガティブUNLに追加できるので、サーバーはどのバリデータを 追加するかを選択しなければならない。複数の候補がある場合、サーバーは以下のメカニズムでどの候補を提案するかを 選択する。
|
||||
|
||||
1. 親レジャーバージョンのレジャーハッシュを取得する。
|
||||
0. 各バリデータ候補の公開鍵を取得する。
|
||||
0. 候補のバリデータと親レジャーのハッシュの排他的論理和(XOR)を計算する。
|
||||
0. XOR演算の結果のうち、数値が最も小さいバリデータを提案する。
|
||||
|
||||
あるフラグレジャーのネガティブUNLから削除される候補が複数ある場合、サーバーは同じメカニズムでそれらの中から選択します。
|
||||
|
||||
このメカニズムには、いくつかの有用な特性があります。
|
||||
|
||||
- すべてのサーバーが容易に入手でき、かつ迅速に計算できる情報を使用する。
|
||||
- 信頼できるバリデータのスコアが多少異なっていても、ほとんどのサーバーは同じ候補を選択する。これは、どのバリデータの信頼度が「最低」なのか「最高」なのかについて、 サーバ間で見解の相違があったとしても同様である。これは、あるバリデータが信頼性の閾値より上か下かについて、各サーバが 意見を異にしている場合でさえも同様である。したがって、ネットワークは、どのバリデータを追加または削除するかについて、 合意が得られる可能性が高い。
|
||||
- レジャーバージョンごとに同じ結果が出るとは限りません。もしネガティブUNLへのある変更案が合意に至らなかったとしても、ネットワークは毎回その1つのバリデータの追加や削除を試みて失敗し続けることはない。ネットワークは、後のフラグ付きレジャーで別の候補をネガティブUNLに追加・削除することを試みることができる。
|
||||
|
||||
|
||||
### 検証のフィルタリング
|
||||
|
||||
[コンセンサスプロセスの検証ステップ](consensus.html#検証)では、親レジャーのネガティブUNLのバリデータを無効化します。各サーバーは無効化されたバリデータを取り除いた設定済みUNLからなる "有効UNL "を計算し、定足数を再計算します。(定足数は常に有効 UNL の 80% 以上、かつ設定 UNL の 60% 以上です)。無効化されたバリデータが検証票を送信した場合、サーバーは無効化されたバリデータの信頼性を計算するためにその票を追跡するが、あるバージョンのレジャーが合意に達したかどうかを判断するためにその票を使うことはありません。
|
||||
|
||||
**注記:** ネガティブUNLは、定足数を直接計算するのではなく、定足数の計算元となる信頼できるバリデータの合計を調整するものです。定足数はパーセンテージですが、投票数は整数であるため、信頼できるバリデータの合計を減らしても、定足数に達するために必要な投票数が変わるとは限りません。たとえば、総バリデータが15人である場合、80%はちょうど12人のバリデータである。これを14人に減らすと、80%は11.2人となり、定足数に達するには依然として12人の有効投票者が必要である。
|
||||
|
||||
ネガティブUNLは、提案されたトランザクションセットにどのトランザクションを含めるかを選択するなど、コンセンサスプロセスの他の部分には影響を与えない。これらのステップは常に設定されたUNLに依存し、その閾値は何人の信頼できるバリデータがコンセンサスラウンドに積極的に参加しているかに基づいている。ネガティブUNLにあるバリデータもコンセンサスプロセスに参加することができる。
|
||||
|
||||
### 例
|
||||
|
||||
次の例は、ネガティブUNLが合意形成プロセスにどのような影響を与えるかを示している。
|
||||
|
||||
1. サーバーのUNLが38人の信頼できるバリデータで構成されているとすると、80%の定足数は38人のうち少なくとも31人の信頼できるバリデータである。
|
||||
|
||||
{{ include_svg("img/negative-unl-01.svg", "Diagram: 通常の場合。ネガティブUNLは未使用、定足数は設定されたバリデータの80%である。") }}
|
||||
|
||||
2. MissingAとUnsteadyBという2人のバリデータがオフラインになったとする。(両者とも信頼度スコアは50%未満である。) レジャー _N_ の合意プロセスにおいて、残りのバリデータの多くがUnsteadyBをネガティブUNLに追加することを提案する。この動議は残りのバリデーターのうち少なくとも31人の定足数で可決され、 レジャー _N_はUnsteadyBを無効化する予定で有効になった。
|
||||
|
||||
{{ include_svg("img/negative-unl-02.svg", "Diagram: UnsteadyBは無効になる予定。") }}
|
||||
|
||||
|
||||
3. レジャー _N+1_ から _N+256_ については、コンセンサスプロセスをそのまま継続する。
|
||||
|
||||
4. 次のフラグレジャー _N+256_ では、UnsteadyBはレジャーの「予定」から「無効」リストへ自動的に移動する。また、MissingAがまだオフラインであるため、検証者の総意として、次のフラグレジャーでMissingAを無効化する予定とする。
|
||||
|
||||
{{ include_svg("img/negative-unl-04.svg", "UnsteadyBが無効化され、MissingAも無効化される予定。") }}
|
||||
|
||||
5. レジャー _N+257_ から _N+512_ について、定足数は37名中30名となった。
|
||||
|
||||
6. UnsteadyBがレジャー _N+270_ でオンラインに復帰。レジャー _N+270_ から _N+511_ に対してネットワークの他の部分と一致する検証票を送信し、信頼性スコアが80%以上となる。
|
||||
|
||||
{{ include_svg("img/negative-unl-06.svg", "Diagram: UnsteadyBがオンラインに戻るが、まだ無効化されている。") }}
|
||||
|
||||
7. 次のフラグレジャー _N+256_ では、予定通りMissingAが自動的に無効リストに移される。一方、UnsteadyBは信頼性スコアが向上したため、検証者の総意としてネガティブUNLから削除される予定である。
|
||||
|
||||
{{ include_svg("img/negative-unl-07.svg", "Diagram: MissingAを無効化し、UnsteadyBを再有効化する予定。") }}
|
||||
|
||||
8. レジャー _N+513_ から _N+768_ の場合、定足数は36人中29人である。MissingAがオフラインの間、UnsteadyBは安定的に検証結果を送り続ける。
|
||||
|
||||
9. フラグレジャー _N+768_ では、予定通りUnsteadyBが無効リストから自動的に削除されています。
|
||||
|
||||
{{ include_svg("img/negative-unl-09.svg", "Diagram: UnsteadyBを無効リストから削除。") }}
|
||||
|
||||
10. 最終的に、あなたはMissingAがおそらく戻ってこないと判断し、あなたのサーバーの設定されたUNLからそれを削除します。あなたのサーバーはそれ以降、各フラグレジャーからMissingAをネガティブUNLから削除することを提案し始める。
|
||||
|
||||
{{ include_svg("img/negative-unl-10.svg", "Diagram: MissingAを設定済みUNLから削除した後、ネガティブUNLからも削除することを提案する。 ") }}
|
||||
|
||||
11. バリデータ操作者が自分の設定したUNLからMissingAを削除すると、そのバリデータ操作者は ネガティブUNLからMissingAを削除するように投票する。十分な数のバリデータが投票した時点で、MissingAを削除する提案は合意に達し、MissingAはスケジュールされ、最終的にネガティブUNLから削除される。
|
||||
|
||||
{{ include_svg("img/negative-unl-11.svg", "Diagram: MissingAをネガティブUNLから削除。") }}
|
||||
|
||||
|
||||
### 関連項目
|
||||
|
||||
- **コンセンサス:**
|
||||
- [コンセンサスプロトコル](consensus.html)
|
||||
- **チュートリアル:**
|
||||
- [Testnetや別の並列ネットワークへ接続する](connect-your-rippled-to-the-xrp-test-net.html)
|
||||
- [バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)
|
||||
- **リファレンス:**
|
||||
- [negativeUNL オブジェクト](negativeunl.html)
|
||||
- [UNLModify pseudo-transaction][]
|
||||
- [ledger_entry メソッド][]
|
||||
- [consensus_info メソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
126
content/concepts/issued-currencies/demurrage.ja.md
Normal file
126
content/concepts/issued-currencies/demurrage.ja.md
Normal file
@@ -0,0 +1,126 @@
|
||||
---
|
||||
html: demurrage.html
|
||||
parent: issued-currencies.html
|
||||
blurb: (廃止) 一部の古いXRP Ledgerツールは、組み込み金利やマイナス金利を持つ通貨コードをサポートしていました。.
|
||||
status: removed
|
||||
---
|
||||
# デマレージ
|
||||
|
||||
**注意:** デマレージは非推奨の機能であり、継続的なサポートはありません。このページでは、旧バージョンのXRP Ledgerソフトウェアの過去の動作について説明します。
|
||||
|
||||
[デマレージ](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%9E%E3%83%AC%E3%83%BC%E3%82%B8) とは、保有資産にかかるマイナスの金利で、その資産を保有するためのコストを表すものです。 XRP Ledgerで発行された通貨のデマレージを表現するために、デマレージレートを示すカスタム[通貨コード](currency-formats.html#通貨コード) を使って追跡することができます。 これによって、様々なデマレージの量に対応した別々のバージョンの通貨が効果的に作成されます。クライアントアプリケーションは、通貨コードと一緒に年率でデマレージ通貨コードを表現することによって、これをサポートすることができます。例えば、以下のようになります。"XAU (-0.5%pa)".
|
||||
|
||||
## 通貨量の表記について
|
||||
|
||||
XRP Ledgerのすべての金額を継続的に更新するのではなく、有利子通貨や減耗通貨の金額を2種類の金額に分割する方法です。XRP Ledgerに記録される「レジャー値」と、人に見せる「表示値」の2種類に分けます。「レジャー値」は、ある一定時点、すなわち2000年1月1日午前0時の「リップルエポック」での通貨の価値を表しています。「表示値」は、リップルエポックからその時点までの連続した利息やデマレージを計算した後の時点（通常は現在時刻）での金額を表しています。
|
||||
|
||||
**ヒント:** デマレージはインフレに似ていると考えることができます。インフレの影響を受けたすべての資産の価値は時間とともに減少しますが、レジャーには常に2000年の値で金額が記録されます。これは実際のインフレを反映しているわけではなく、デマレージはむしろ一定の割合での仮想的なインフレのようなものです。
|
||||
|
||||
したがって、クライアントソフトウェアは2つの変換を適用する必要があります。
|
||||
|
||||
- ある時点の表示値を取り込み、レジャー値に変換して記録すること。
|
||||
- レジャー値を、ある時点の表示値に変換すること。
|
||||
|
||||
### デマレージの計算
|
||||
|
||||
通貨に関するデマレージの完全な計算式は以下の通りです。
|
||||
|
||||
```
|
||||
D = A × ( e ^ (t ÷ τ) )
|
||||
```
|
||||
|
||||
- **D** はデマレージ後の金額
|
||||
- **A** はグローバルレジャーに記録されたデマレージ前金額です。
|
||||
- **e** はオイラー数
|
||||
- **t** はリップルエポック（UTC2000年1月1日0時）からの経過秒数
|
||||
- **τ** は、e倍加時間の時間（秒）です。この値は［希望する金利から計算］（#e倍加時間の計算）されます。 <!-- SPELLING_IGNORE: τ -->
|
||||
|
||||
表示金額とレジャー金額の変換は、以下の手順で行います。
|
||||
|
||||
1. `( e ^ (t ÷ τ) )`の値を計算する。この数値を「デマレージ係数」と呼ぶ。デマレージ係数は常に現在時刻など特定の時刻からの相対値である。
|
||||
2. 変換する量に適用します。
|
||||
- レジャー値を表示値に変換する場合は、デマレージ係数を乗じる。
|
||||
- 表示値をレジャー値に変換する場合は、デマレージ係数で割ってください。
|
||||
3. 必要であれば、結果値が望ましい精度で表現できるように調整する。XRP Ledgerの[発行通貨形式](currency-formats.html#発行済み通貨の精度)により、レジャー値の精度は小数点以下15桁までとされています。.
|
||||
|
||||
|
||||
## 利子付き通貨コードフォーマット
|
||||
|
||||
[標準通貨コード形式](currency-formats.html#標準通貨コード)ではなく、正の金利や負の金利（Demurrage）を持つ通貨は、以下の形式の160ビット通貨コードを使用します。
|
||||
|
||||
|
||||
|
||||
1. 最初の8ビットは `0x01` でなければなりません。
|
||||
2. 次の24ビットはASCIIの3文字を表します。
|
||||
これはISO 4217のコードと予想されます。標準フォーマットのASCII文字と同じ文字をサポートしています。
|
||||
3. 次の24ビットはすべて「0」でなければなりません。
|
||||
4. 次の64ビットは通貨の金利で、IEEE754ダブルフォーマットで「[e-folding time](http://en.wikipedia.org/wiki/E-folding)」と表現される。
|
||||
5. 次の24ビットは予約されており，すべて`0`でなければなりません
|
||||
|
||||
### e倍加時間の計算
|
||||
|
||||
レジャー金額と表示金額の変換や、有利子/不利子通貨の通貨コードの計算には、「e倍加時間」としての金利が必要です。e倍加時間とは、ある数量が_e_（オイラー数）の倍数だけ増加するのにかかる時間のことである。慣例として、e倍加時間は数式では**τ**という文字で表記される。
|
||||
|
||||
ある年率パーセントの利息に対するe倍加時間の時間を計算すること。
|
||||
|
||||
1. 100%に金利を足すと、年利を適用した後の初期金額に対する割合が算出されます。デマレージには、マイナスの金利を使用します。例えば、0.5%のデマレージは-0.5%の金利となり、**99.5%**の残存率となります。
|
||||
2. パーセンテージを小数で表します。例えば、99.5%は**0.995**となります。
|
||||
3. その数値の自然対数をとります。例えば、**ln(0.995) = -0.005012541823544286** となります。(この数値は、当初の金利がプラスであればプラス、マイナスであればマイナスになります)。
|
||||
4. 1年間の秒数（31536000）を、前のステップの自然対数の結果で割ってください。例えば、**31536000 ÷ -0.005012541823544286 = -6291418827.045599** となります。この結果が、e倍加時間（秒）です。
|
||||
|
||||
**注記:** XRP Ledgerの利息・デマレージルールでは、慣習上、1年あたりの固定秒数（31536000）が使用されており、閏日や閏秒の調整は行われていません。
|
||||
|
||||
## クライアントサポート
|
||||
|
||||
利息通貨とデマレージ通貨をサポートするために、クライアントアプリケーションはいくつかの機能を実装する必要があります。
|
||||
|
||||
- レジャーやトランザクションデータから取得した通貨を減耗して表示する場合、クライアント側でレジャー値から表示値への変換が必要です。(デマレージでは、表示値はレジャー値より小さくなる)。
|
||||
|
||||
- デマレージ通貨の入力を受け付ける場合、クライアントは金額を表示形式からレジャー形式に変換する必要があります。(デマレッジの場合、ユーザー入力値よりレジャー値の方が大きい)。クライアントは、支払い、オファー、その他のトランザクションを作成する際に、レジャーの値を使用しなければなりません。
|
||||
|
||||
- クライアントは、金利やデマレージが発生する通貨と発生しない通貨、および金利やデマレージの利率が異なる通貨を区別する必要があります。クライアントは、[利子付き通貨コードフォーマット](#利子付き通貨コードフォーマット)を解析して、「XAU (-0.5% pa)」などの表示にできるようにしなければなりません。
|
||||
|
||||
### ripple-lib サポート
|
||||
|
||||
デマレージは ripple-lib のバージョン **0.7.37** から **0.12.9** まででサポートされていました。デマレージは、最近のほとんどのライブラリでは***サポートされていません***。
|
||||
|
||||
以下のコードサンプルは、互換性のあるバージョンのripple-libを使用して、レジャー値と表示値の変換を行う方法を示しています。また、[Ripple Demurrage Calculator](https://ripple.github.io/ripple-demurrage-tool/)も参照してください。
|
||||
|
||||
表示値からレジャー値に変換するには、`Amount.from_human()`を使用する。
|
||||
|
||||
```js
|
||||
// デマレージ通貨の表示金額を表す Amount オブジェクトを作成し、
|
||||
// 現在の日付を表すreference_dateを渡します。
|
||||
// (この場合、2017-11-04T00:07:50Zに、年0.5%の脱税で台帳値10 XAU。)。
|
||||
var demAmount = ripple.Amount.from_human('10 0158415500000000C1F76FF6ECB0BAC600000000',
|
||||
{reference_date:563069270});
|
||||
|
||||
// 発行者を設定します
|
||||
demAmount.set_issuer("rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh");
|
||||
|
||||
// get the JSON format for the ledger amount
|
||||
console.log(demAmount.to_json());
|
||||
|
||||
// { "value": "10.93625123082769",
|
||||
// "currency": "0158415500000000C1F76FF6ECB0BAC600000000",
|
||||
// "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh" }
|
||||
```
|
||||
|
||||
レジャー値から表示値へ変換する場合、
|
||||
|
||||
```js
|
||||
// レジャー値を持つ Amount オブジェクトを作成します。
|
||||
ledgerAmount = ripple.Amount.from_json({
|
||||
"currency": "015841551A748AD2C1F76FF6ECB0CCCD00000000",
|
||||
"issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
|
||||
"value": "10.93625123082769"})
|
||||
|
||||
// 表示金額を得るために現在時刻までの利息を適用する
|
||||
var displayAmount = demAmount.applyInterest(new Date());
|
||||
|
||||
console.log(displayAmount.to_json());
|
||||
|
||||
// { "value": "9.999998874657716",
|
||||
// "currency": "0158415500000000C1F76FF6ECB0BAC600000000",
|
||||
// "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh" }
|
||||
```
|
||||
Reference in New Issue
Block a user