[JA] replace バリデーター to バリデータ

This commit is contained in:
tequ
2024-03-26 17:25:45 +09:00
parent d3af48ea9d
commit 3946387ebd
9 changed files with 16 additions and 16 deletions

View File

@@ -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)をご覧ください。
#### 金融機関は、特定の制度上の基準や要件を満たすのに役立つトランザクションバリデータを設定できますか?

View File

@@ -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は無効になる予定。")

View File

@@ -27,7 +27,7 @@ Amendmentのコードがソフトウェアリリースに組み込まれた後
256番目毎のレジャーは、**フラグ**レジャーと呼ばれます。フラグレジャーは特別な内容を持っているわけではありませんが、フラグレジャーの前後ではAmendment作業が行われます。
1. **フラグレジャー -1:** `rippled`バリデータが検証メッセージを送信するとき、彼らは自身でAmendmentへの投票も送信します。
2. **フラグレジャー:** サーバは、信頼できるバリデータからの投票を処理します。
2. **フラグレジャー:** サーバは、信頼できるバリデータからの投票を処理します。
3. **フラグレジャー +1:** サーバは`EnableAmendment`疑似トランザクションを挿入し、発生したと思われることに基づいてフラグを立てます。
* `tfGotMajority`フラグは、そのAmendmentが80%超の支持を得ていることを意味します。
* `tfLostMajority`フラグはAmendmentへの支持が80%以下になったことを意味します。

View File

@@ -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に反対票を投じるには、以下のコマンドを実行します。

View File

@@ -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オブジェクト

View File

@@ -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" /%}

View File

@@ -81,7 +81,7 @@ XLSドラフトを作成した後、その変更にAmendmentが必要かどう
年に4回、`develop`で承認されたPRからリリース候補がビルドされます。このパッケージはTestnetとMainnet上のいくつかのードにデプロイされます。リリース候補に問題がなければ、コードは`master`にマージされ、メインネット上のノードはこのビルドにアップグレードできます。
6. 新しいAmendmentは合意形成プロセスを経て、バリデータがそのAmendmentを有効にするかどうかを投票します。
6. 新しいAmendmentは合意形成プロセスを経て、バリデータがそのAmendmentを有効にするかどうかを投票します。
## コードのフローチャート

View File

@@ -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

View File

@@ -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 "Isnt Proof of Work the best validation mechanism?"