mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2026-08-23 03:00:56 +00:00
[JA] replace バリデーター to バリデータ
This commit is contained in:
@@ -22,7 +22,7 @@ name: よくある質問
|
||||
|
||||
#### XRP Ledger(XRPL)はRippleが所有するプライベートブロックチェーンですか?
|
||||
|
||||
いいえ。XRPLは分散型のパブリックブロックチェーンです。トランザクション処理やコンセンサスに影響を与えるような変更は、ネットワークバリデーターの80%以上の承認が必要です。Rippleはネットワークへの貢献者の一員ですが、その権利は他の貢献者たちと同じです。ネットワークには150以上のバリデーターが参加しており、うちデフォルトのユニークノードリスト(UNL)に登録されているものは35以上です。Rippleはこれらのうち[1つのノード](https://foundation.xrpl.org/2023/03/23/unl-update-march-2023/)を運営しています。
|
||||
いいえ。XRPLは分散型のパブリックブロックチェーンです。トランザクション処理やコンセンサスに影響を与えるような変更は、ネットワークバリデータの80%以上の承認が必要です。Rippleはネットワークへの貢献者の一員ですが、その権利は他の貢献者たちと同じです。ネットワークには150以上のバリデータが参加しており、うちデフォルトのユニークノードリスト(UNL)に登録されているものは35以上です。Rippleはこれらのうち[1つのノード](https://foundation.xrpl.org/2023/03/23/unl-update-march-2023/)を運営しています。
|
||||
ユニークノードリスト(UNL)に関しては[ユニークノードリスト(UNL)とは何ですか?](#ユニークノードリストunlとは何ですか)の項目を参照してください。
|
||||
|
||||
|
||||
@@ -67,7 +67,7 @@ UNLとは、ある参加者が共謀しないと信じるバリデータのリ
|
||||
|
||||
#### どのUNLを選択すればよいですか?
|
||||
|
||||
バリデータは誰でも実行できるため、信頼できるバリデータを選ぶ責任はネットワーク参加者にあります。現在、RippleとXRP Ledger財団が、過去の実績、証明された身元、責任あるITポリシーに基づき、高品質なバリデータの推奨デフォルトリストを公表していることが知られています。 しかし、すべてのネットワーク参加者は、自身が信頼できるバリデーターを選択することができ、上記の2つの発行者のいずれかに従う必要はありません。
|
||||
バリデータは誰でも実行できるため、信頼できるバリデータを選ぶ責任はネットワーク参加者にあります。現在、RippleとXRP Ledger財団が、過去の実績、証明された身元、責任あるITポリシーに基づき、高品質なバリデータの推奨デフォルトリストを公表していることが知られています。 しかし、すべてのネットワーク参加者は、自身が信頼できるバリデータを選択することができ、上記の2つの発行者のいずれかに従う必要はありません。
|
||||
|
||||
|
||||
#### RippleがそのUNLの採用を推奨しているなら、それは中央集権的なシステムを形成することにならないのですか?
|
||||
@@ -81,7 +81,7 @@ UNLとは、ある参加者が共謀しないと信じるバリデータのリ
|
||||
|
||||
ネットワークに参加するためにXRP Ledgerのサーバを運営する場合やバリデータを運営するための追加コストや手間は最小限です。つまり、ビットコインにおけるマイニング報酬のような追加のインセンティブは必要ありません。Rippleはバリデータを運用するための報酬としてXRP支払うことはしないため、そのようなインセンティブがバリデータの行動を歪めることはありません。
|
||||
|
||||
インセンティブがどのようにバリデーターの行動を歪めるかの例については、[miner extractable value (MEV)](https://arxiv.org/abs/1904.05234)をご覧ください。
|
||||
インセンティブがどのようにバリデータの行動を歪めるかの例については、[miner extractable value (MEV)](https://arxiv.org/abs/1904.05234)をご覧ください。
|
||||
|
||||
|
||||
#### 金融機関は、特定の制度上の基準や要件を満たすのに役立つトランザクションバリデータを設定できますか?
|
||||
|
||||
@@ -78,7 +78,7 @@ V<sub>a</sub>は、サーバ側のコンセンサス見解と一致した過去2
|
||||
2. ネガティブUNLが満杯でない場合、各サーバは信頼度50%未満のバリデータの中から、**最大1つ**のバリデータをネガティブUNLに追加することを提案する。
|
||||
3. ネガティブUNLが空でない場合、各サーバはネガティブUNLから**最大1つ**のバリデータを削除することを提案する。サーバがバリデータをネガティブUNLから削除することを提案できる理由は2つある。
|
||||
- バリデータの信頼度が80%を超えている。
|
||||
- 自身のUNLにそのバリデーターを持たない。(バリデータが永久に停止した場合、このルールは、サーバの設定済みUNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが削除されることを確実にする)。
|
||||
- 自身のUNLにそのバリデータを持たない。(バリデータが永久に停止した場合、このルールは、サーバの設定済みUNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが削除されることを確実にする)。
|
||||
4. ネガティブUNLの変更案がコンセンサスに達した場合、その変更は次のフラグレジャーから適用される予定である。この方法で最大1つの追加と1つの削除をスケジュールすることができる。
|
||||
|
||||
ネガティブUNLにバリデータを追加したり削除したりする提案は[UNLModify pseudo-transactions][]の形式を取る。それぞれの擬似トランザクションは他の[擬似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)と同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバの総意として同じ変更を提案する必要がある。
|
||||
@@ -91,7 +91,7 @@ V<sub>a</sub>は、サーバ側のコンセンサス見解と一致した過去2
|
||||
ネットワークが2つ以上のサブネットワークに分断されるのを防ぐために、ネガティブUNLは定足数要件をUNLエントリ全体の60%未満に減らすことができない。これを強制するために、サーバはネガティブUNL上のバリデータ数がサーバの設定済みUNL内のバリデータ数の25%(切り捨て)である場合、ネガティブUNLが"満杯"になったと見なす。(この25%は、25%のバリデータが削除された場合、残りの75%のバリデータの80%の合意は元の数の60%に等しいという計算に基づいている)。もしサーバがネガティブUNLが一杯になったと判断した場合、ネガティブUNLへの新たな追加は提案されない。
|
||||
|
||||
|
||||
### 複数のバリデーター候補から選択する
|
||||
### 複数のバリデータ候補から選択する
|
||||
|
||||
信頼性の閾値に基づき、複数のバリデータがネガティブUNLに追加される候補となる可能性がある。一度に最大1つのバリデータをネガティブUNLに追加できるので、サーバはどのバリデータを追加するかを選択しなければならない。複数の候補がある場合、サーバは以下のメカニズムでどの候補を提案するかを選択する。
|
||||
|
||||
@@ -125,7 +125,7 @@ V<sub>a</sub>は、サーバ側のコンセンサス見解と一致した過去2
|
||||
|
||||
[{% inline-svg file="/docs/img/negative-unl-01.ja.svg" /%}](/docs/img/negative-unl-01.ja.svg "Diagram: 通常の場合。ネガティブUNLは未使用、定足数は設定されたバリデータの80%である。")
|
||||
|
||||
2. MissingAとUnsteadyBという2人のバリデータがオフラインになったとする。(両者とも信頼度スコアは50%未満である。)レジャー _N_ の合意プロセスにおいて、残りのバリデータの多くがUnsteadyBをネガティブUNLに追加することを提案する。この動議は残りのバリデーターのうち少なくとも31人の定足数で可決され、レジャー _N_ はUnsteadyBを無効化する予定で有効になった。
|
||||
2. MissingAとUnsteadyBという2人のバリデータがオフラインになったとする。(両者とも信頼度スコアは50%未満である。)レジャー _N_ の合意プロセスにおいて、残りのバリデータの多くがUnsteadyBをネガティブUNLに追加することを提案する。この動議は残りのバリデータのうち少なくとも31人の定足数で可決され、レジャー _N_ はUnsteadyBを無効化する予定で有効になった。
|
||||
|
||||
[{% inline-svg file="/docs/img/negative-unl-02.ja.svg" /%}](/docs/img/negative-unl-02.ja.svg "Diagram: UnsteadyBは無効になる予定。")
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ Amendmentのコードがソフトウェアリリースに組み込まれた後
|
||||
256番目毎のレジャーは、**フラグ**レジャーと呼ばれます。フラグレジャーは特別な内容を持っているわけではありませんが、フラグレジャーの前後ではAmendment作業が行われます。
|
||||
|
||||
1. **フラグレジャー -1:** `rippled`バリデータが検証メッセージを送信するとき、彼らは自身でAmendmentへの投票も送信します。
|
||||
2. **フラグレジャー:** サーバは、信頼できるバリデーターからの投票を処理します。
|
||||
2. **フラグレジャー:** サーバは、信頼できるバリデータからの投票を処理します。
|
||||
3. **フラグレジャー +1:** サーバは`EnableAmendment`疑似トランザクションを挿入し、発生したと思われることに基づいてフラグを立てます。
|
||||
* `tfGotMajority`フラグは、そのAmendmentが80%超の支持を得ていることを意味します。
|
||||
* `tfLostMajority`フラグはAmendmentへの支持が80%以下になったことを意味します。
|
||||
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
---
|
||||
# Amendment投票機能の設定
|
||||
|
||||
バリデーターとして設定されたサーバは、[feature メソッド][]を使ってXRP Ledgerプロトコルの[Amendment](../../concepts/networks-and-servers/amendments.md)に投票することができます。(この方法には[管理者アクセス](../../tutorials/http-websocket-apis/build-apps/get-started.md#管理者アクセス権限)が必要です).
|
||||
バリデータとして設定されたサーバは、[feature メソッド][]を使ってXRP Ledgerプロトコルの[Amendment](../../concepts/networks-and-servers/amendments.md)に投票することができます。(この方法には[管理者アクセス](../../tutorials/http-websocket-apis/build-apps/get-started.md#管理者アクセス権限)が必要です).
|
||||
|
||||
例えば、「SHAMapV2」Amendmentに反対票を投じるには、以下のコマンドを実行します。
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
html: negativeunl.html
|
||||
parent: ledger-entry-types.html
|
||||
seo:
|
||||
description: 現在オフラインと思われるバリデーターの一覧を表します。
|
||||
description: 現在オフラインと思われるバリデータの一覧を表します。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
@@ -41,7 +41,7 @@ _([NegativeUNL amendment][]により追加されました。)_
|
||||
| `Flags` | 数値 | UInt32 | はい | 真偽値フラグのビットマップ。NegativeUNLオブジェクトタイプにはフラグが定義されていないため、この値は常に`0`となります。 |
|
||||
| `LedgerEntryType` | 文字列 | UInt16 | はい | `0x004E`は文字列`NegativeUNL`に対応し、このオブジェクトがNegativeUNLであることを意味します。 |
|
||||
| `ValidatorToDisable` | 文字列 | Blob | いいえ | 次回のフラグレジャーで無効化される予定の信頼できるバリデータの公開鍵を表します。 |
|
||||
| `ValidatorToReEnable` | 文字列 | Blob | いいえ | 次回のフラグレジャーで再有効化される予定のネガティブUNLの信頼できるバリデーターの公開鍵を表します。 |
|
||||
| `ValidatorToReEnable` | 文字列 | Blob | いいえ | 次回のフラグレジャーで再有効化される予定のネガティブUNLの信頼できるバリデータの公開鍵を表します。 |
|
||||
|
||||
## DisabledValidatorオブジェクト
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
html: unlmodify.html
|
||||
parent: pseudo-transaction-types.html
|
||||
seo:
|
||||
description: 現在オフラインとみなされている信頼できるバリデーターのリストを変更します。
|
||||
description: 現在オフラインとみなされている信頼できるバリデータのリストを変更します。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
@@ -36,7 +36,7 @@ _([NegativeUNL amendment][]により追加されました)_
|
||||
|:---------------------|:--------|:------------------|:----------------------|
|
||||
| `TransactionType` | 文字列 | UInt16 | `0x0066`は文字列`UNLModify`にマッピングされ、このオブジェクトが`UNLModify`擬似トランザクションであることを表します。 |
|
||||
| `LedgerSequence` | 数値 | UInt32 | この擬似トランザクションが出現する[レジャーインデックス][]です。これは、この擬似トランザクションを、同じ変更の他の出現と区別するものです。 |
|
||||
| `UNLModifyDisabling` | 数値 | UInt8 | `1`の場合、この変更はネガティブUNLにバリデーターを追加することを意味します。0` の場合、この変更はネガティブ UNL からバリデータを削除することを意味します。(これらの値以外は使用できません) |
|
||||
| `UNLModifyDisabling` | 数値 | UInt8 | `1`の場合、この変更はネガティブUNLにバリデータを追加することを意味します。0` の場合、この変更はネガティブ UNL からバリデータを削除することを意味します。(これらの値以外は使用できません) |
|
||||
| `UNLModifyValidator` | 文字列 | Blob | 追加または削除するバリデータであり、そのマスター公開鍵で識別されます。 |
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -81,7 +81,7 @@ XLSドラフトを作成した後、その変更にAmendmentが必要かどう
|
||||
|
||||
年に4回、`develop`で承認されたPRからリリース候補がビルドされます。このパッケージはTestnetとMainnet上のいくつかのノードにデプロイされます。リリース候補に問題がなければ、コードは`master`にマージされ、メインネット上のノードはこのビルドにアップグレードできます。
|
||||
|
||||
6. 新しいAmendmentは合意形成プロセスを経て、バリデーターがそのAmendmentを有効にするかどうかを投票します。
|
||||
6. 新しいAmendmentは合意形成プロセスを経て、バリデータがそのAmendmentを有効にするかどうかを投票します。
|
||||
|
||||
|
||||
## コードのフローチャート
|
||||
|
||||
@@ -720,9 +720,9 @@ fix1623 Amendmentは、固定金額の[CheckCashトランザクション][](`A
|
||||
| デフォルトの投票(最新の安定版) | はい |
|
||||
| Amendment前の機能は廃止? | いいえ |
|
||||
|
||||
丸め処理の影響により、Amendmentが過半数を達成した後、信頼できるバリデーターの80%にわずかに満たない賛成で有効になることがあるバグを修正しました。
|
||||
丸め処理の影響により、Amendmentが過半数を達成した後、信頼できるバリデータの80%にわずかに満たない賛成で有効になることがあるバグを修正しました。
|
||||
|
||||
この修正が適用されない場合、Amendmentが有効になるための最小閾値は、信頼できるバリデーターの204/256を丸めた値であり、これはその時の信頼できるバリデーターの数に依存します。例えば、36人中28人(約77.8%)のバリデータがあれば、補正は有効になりえます。この修正により、実際に必要な最小限のバリデーターの数は、信頼できるバリデーターの80%を下回ることはありません。
|
||||
この修正が適用されない場合、Amendmentが有効になるための最小閾値は、信頼できるバリデータの204/256を丸めた値であり、これはその時の信頼できるバリデータの数に依存します。例えば、36人中28人(約77.8%)のバリデータがあれば、補正は有効になりえます。この修正により、実際に必要な最小限のバリデータの数は、信頼できるバリデータの80%を下回ることはありません。
|
||||
|
||||
|
||||
### fixCheckThreading
|
||||
|
||||
@@ -3236,7 +3236,7 @@ msgid ""
|
||||
"FAQ) — Ripple runs 6 of these nodes."
|
||||
msgstr ""
|
||||
"いいえ、XRP "
|
||||
"Ledgerは分散型のパブリックブロックチェーンです。取引処理やコンセンサスに影響を与えるような変更は、ネットワークの少なくとも80%の承認が必要です。Ripple社はネットワークへの貢献者ですが、その権利は他の貢献者と同じです。バリデーションの面では、ネットワーク上に150人以上のバリデーターが存在し、35人以上がユニークノードリスト(FAQ全文の「ユニークノードリスト(UNL)とは何ですか」参照)に登録されており、Ripple社はこれらのノードのうち1つを運営しています。"
|
||||
"Ledgerは分散型のパブリックブロックチェーンです。取引処理やコンセンサスに影響を与えるような変更は、ネットワークの少なくとも80%の承認が必要です。Ripple社はネットワークへの貢献者ですが、その権利は他の貢献者と同じです。バリデーションの面では、ネットワーク上に150人以上のバリデータが存在し、35人以上がユニークノードリスト(FAQ全文の「ユニークノードリスト(UNL)とは何ですか」参照)に登録されており、Ripple社はこれらのノードのうち1つを運営しています。"
|
||||
|
||||
#: template/page-xrpl-overview.html.jinja:179
|
||||
msgid "Isn’t Proof of Work the best validation mechanism?"
|
||||
|
||||
Reference in New Issue
Block a user