Merge pull request #1801 from develoQ/ja-unl

[JA] Translating UNL-related pages
This commit is contained in:
Rome Reginelli
2023-03-10 16:16:14 -08:00
committed by GitHub
4 changed files with 136 additions and 27 deletions

View File

@@ -7,7 +7,7 @@ labels:
---
# ネガティブUNL
_([NegativeUNL Amendment](known-amendments.html#negativeunl)が必要です。)_
_([NegativeUNL Amendment](known-amendments.html#negativeunl)によって追加されました。)_
ネガティブUNLは、XRPレジャーの[コンセンサスプロトコル](consensus.html)の機能で、バリデータの部分的な停止中にネットワークの前進を可能にする _liveness_ を向上させるものです。ネガティブUNLを使用すると、サーバーは現在オンラインかつ稼働中のバリデータに基づいて有効なUNLを調整するため、信頼できるバリデータが複数オフラインの場合でも、新しい[レジャーバージョン](ledgers.html) を _validated_ と宣言することができるようになるのです。
@@ -17,7 +17,7 @@ _([NegativeUNL Amendment](known-amendments.html#negativeunl)が必要です。)_
XRPレジャープロトコルの各サーバーは、UNLUnique Node Listと呼ばれる、共謀しないよう信頼できるバリデータのリストを持ち、各サーバーは、信頼できるバリデータが十分に新しいレジャーバージョンに合意したときのコンセンサスに基づいて、レジャーバージョンの検証を独自に決定しています。(デフォルトの構成では、リップル社が十分にユニークで信頼性が高く、独立性が高いと考えるバリデータからなる、リップル社が署名した推奨UNLを使用しています)。標準的な定足数要件は、信頼できるバリデータの少なくとも80%が合意することである。
信頼できるバリデータの20%以上がオフラインになるか、ネットワークの残りの部分と通信できなくなると、ネットワークは定足数に達しないため、新しいレジャーの検証を停止する。これは、取引の結果が確定した後に変更されないようにするための設計上の選択である。このような状況では、残りのサーバーはまだオンラインであり、過去および暫定的なトランザクションデータを提供できるが、新しいトランザクションの最終的で不変の結果を確認することはできない。
信頼できるバリデータの20%がオフラインになるか、ネットワークの残りの部分と通信できなくなると、ネットワークは定足数に達しないため、新しいレジャーの検証を停止する。これは、取引の結果が確定した後に変更されないようにするための設計上の選択である。このような状況では、残りのサーバーはまだオンラインであり、過去および暫定的なトランザクションデータを提供できるが、新しいトランザクションの最終的で不変の結果を確認することはできない。
しかしこれは、広く信頼されているバリデータがいくつかオフラインになった場合、ネットワークが前進しなくなる可能性があることを意味する。2020-10-06現在、リップル社が推奨するUNLには34人のバリデータがいるので、そのうち7人以上がオフラインになると、ネットワークの前進が止まってしまうことになります。さらに、1人または2人のバリデータが長期間オフラインになると、ネットワークは残りのバリデータ間の不一致の余地が少なくなり、コンセンサスの達成に時間がかかる可能性があります。
@@ -32,15 +32,9 @@ XRPレジャープロトコルの各サーバーは、UNLUnique Node List
バリデータが一度に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ルールは有効になる。
@@ -62,7 +56,7 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
- バリデータが動作を停止したり、過負荷になっている。
- 様々な理由により、バリデータはサーバと同じプロトコルルールに従わない。可能性としては、設定ミス、ソフトウェアのバグ、意図的に[異なるネットワーク](parallel-networks.html)に従っている、または悪意ある行動などが考えられます。
バリデータの信頼性が **50%** 未満である場合、そのバリデータはネガティブUNLに追加される候補である。ネガティブUNLから削除するには、バリデータの信頼性が **80%** 以上でなければならない。
バリデータの信頼性が**50%**である場合、そのバリデータはネガティブUNLに追加される候補である。ネガティブUNLから削除するには、バリデータの信頼性が**80%**でなければならない。
バリデータを含む各サーバーは、信頼できるバリデータ全員について独自に信頼性スコアを算出している。あるバリデータの信頼性について、サーバーが異なると結論が異なることがある。それは、そのバリデータの投票が一方のサーバーに届いて他方のサーバーに届かなかったり、特定のレジャーについて意見が異なることが多かったり少なかったりするためである。あるバリデータをネガティブUNLに追加または削除するには、信頼できるバリデータの総意として、あるバリデータが信頼性の閾値を超えるか下回るかに合意する必要がある。

View File

@@ -0,0 +1,67 @@
---
html: negativeunl.html
parent: ledger-object-types.html
blurb: 現在オフラインと思われるバリデーターの一覧を表します。
labels:
- ブロックチェーン
---
# NegativeUNL
_([NegativeUNL amendment][]によって追加されました。)_
`NegativeUNL`オブジェクトタイプは、[ネガティブUNL](negative-unl.html)の現在の状態、つまり現在オフラインであると考えられる信頼できるバリデーションのリストを含んでいます。
各台帳のバージョンには、**最大1つの**`NegativeUNL`オブジェクトが含まれます。無効になっているか、無効になる予定のバリデータがない場合、台帳には`NegativeUNL`オブジェクトは存在しません。
## {{currentpage.name}} JSONの例
```json
{
"DisabledValidators": [
{
"DisabledValidator": {
"FirstLedgerSequence": 1609728,
"PublicKey": "ED6629D456285AE3613B285F65BBFF168D695BA3921F309949AFCD2CA7AFEC16FE"
}
}
],
"Flags": 0,
"LedgerEntryType": "NegativeUNL",
"index": "2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244"
}
```
`NegativeUNL`オブジェクトは、以下のフィールドを持ちます。
| 名前 | JSONの型 | [内部の型][] | 必須? | 説明 |
|:----------------------|:---------|:-----------|:------|:---------------------|
| `DisabledValidators` | 配列 | Array | いいえ | `DisabledValidator`オブジェクト(下記参照)は、現在無効になっている信頼できるバリデータを表すリストです。 |
| `Flags` | 数値 | UInt32 | はい | 真偽値フラグのビットマップ。NegativeUNLオブジェクトタイプにはフラグが定義されていないため、この値は常に`0`となります。 |
| `LedgerEntryType` | 文字列 | UInt16 | はい | `0x004E`は文字列`NegativeUNL`に対応し、このオブジェクトがNegativeUNLであることを意味します。 |
| `ValidatorToDisable` | 文字列 | Blob | いいえ | 次回のフラグレジャーで無効化される予定の信頼できるバリデータの公開鍵を表します。 |
| `ValidatorToReEnable` | 文字列 | Blob | いいえ | 次回のフラグレジャーで再有効化される予定のネガティブUNLの信頼できるバリデーターの公開鍵を表します。 |
## DisabledValidatorオブジェクト
`DisabledValidator`オブジェクトは無効化されたバリデータ一つ分を表します。JSONでは、`DisabledValidator`オブジェクトは`DisabledValidator`という1つのフィールドを持ち、そのオブジェクトは以下のフィールドを持つ別のオブジェクトを含んでいます。
| 名前 | JSONの型 | [内部の型][]| 説明 |
|:----------------------|:---------|:----------|:----------------------|
| `FirstLedgerSequence` | 数値 | UInt32 | バリデータがネガティブUNLに追加されたときの[レジャーインデックス][]を表します。 |
| `PublicKey` | 文字列 | Blob | バリデータのマスター公開鍵を16進数で表します。 |
## NegativeUNL IDのフォーマット
`NegativeUNL`オブジェクトのIDは、`NegativeUNL`のスペースキー(`0x004E`)のみのハッシュです。つまり、台帳上の`NegativeUNL`オブジェクトのIDは常に次のようになります。
```
2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244
```
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -0,0 +1,45 @@
---
html: unlmodify.html
parent: pseudo-transaction-types.html
blurb: 現在オフラインとみなされている信頼できるバリデーターのリストを変更します。
labels:
- ブロックチェーン
---
# UNLModify
_([NegativeUNL amendment][]によって追加されました)_
`UNLModify`[疑似トランザクション](pseudo-transaction-types.html)は[Negative UNL](negative-unl.html)の変更を示し、信頼できるバリデータがオフラインになったかオンラインに戻ってきたことを示します。
**注記:** 擬似トランザクションを送信することはできませんが、台帳を処理する際に擬似トランザクションを発見することがあります。
## {{currentpage.name}} JSONの例
```json
{
"Account": "",
"Fee": "0",
"LedgerSequence": 1600000,
"Sequence": 0,
"SigningPubKey": "",
"TransactionType": "UNLModify",
"UNLModifyDisabling": 1,
"UNLModifyValidator": "ED6629D456285AE3613B285F65BBFF168D695BA3921F309949AFCD2CA7AFEC16FE",
}
```
{% include '_snippets/pseudo-tx-fields-intro.md' %}
<!--{# fix md highlighting_ #}-->
| 名前 | JSONの型 | [内部の型][] | 説明 |
|:---------------------|:--------|:------------------|:----------------------|
| `TransactionType` | 文字列 | UInt16 | `0x0066`は文字列`UNLModify`にマッピングされ、このオブジェクトが`UNLModify`擬似トランザクションであることを表します。 |
| `LedgerSequence` | 数値 | UInt32 | この擬似トランザクションが出現する[レジャーインデックス][]です。これは、この擬似トランザクションを、同じ変更の他の出現と区別するものです。 |
| `UNLModifyDisabling` | 数値 | UInt8 | `1`の場合、この変更はネガティブUNLにバリデーターを追加することを意味します。0` の場合、この変更はネガティブ UNL からバリデータを削除することを意味します。(これらの値以外は使用できません) |
| `UNLModifyValidator` | 文字列 | Blob | 追加または削除するバリデータであり、そのマスター公開鍵で識別されます。 |
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -984,7 +984,6 @@ pages:
targets:
- en
# TODO: update translation
- md: concepts/consensus-network/negative-unl.ja.md
targets:
- ja
@@ -2447,10 +2446,12 @@ pages:
targets:
- ja
# TODO: translate
- md: references/protocol-reference/ledger-data/ledger-object-types/negativeunl.md
targets:
- en
- md: references/protocol-reference/ledger-data/ledger-object-types/negativeunl.ja.md
targets:
- ja
- md: references/protocol-reference/ledger-data/ledger-object-types/nftokenoffer.md
@@ -2790,10 +2791,12 @@ pages:
targets:
- ja
# TODO: translate
- md: references/protocol-reference/transactions/pseudo-transaction-types/unlmodify.md
targets:
- en
- md: references/protocol-reference/transactions/pseudo-transaction-types/unlmodify.ja.md
targets:
- ja
- md: references/protocol-reference/transactions/transaction-results/transaction-results.md