Merge pull request #1801 from develoQ/ja-unl

[JA] Translating UNL-related pages

content/concepts/consensus-network/negative-unl.ja.md

@@ -7,9 +7,9 @@ labels:
 ---
 # ネガティブUNL
 
-_([NegativeUNL Amendment](known-amendments.html#negativeunl)が必要です。)_
+_([NegativeUNL Amendment](known-amendments.html#negativeunl)によって追加されました。)_
 
-ネガティブUNLは、XRPレジャーの[コンセンサスプロトコル](consensus.html)の機能で、バリデータの部分的な停止中にネットワークの前進を可能にする _liveness_ を向上させるものです。ネガティブUNLを使用すると、サーバーは現在オンラインかつ稼働中のバリデータに基づいて有効なUNLを調整するため、信頼できるバリデータが複数オフラインの場合でも、新しい [レジャーバージョン](ledgers.html) を _validated_ と宣言することができるようになるのです。
+ネガティブUNLは、XRPレジャーの[コンセンサスプロトコル](consensus.html)の機能で、バリデータの部分的な停止中にネットワークの前進を可能にする _liveness_ を向上させるものです。ネガティブUNLを使用すると、サーバーは現在オンラインかつ稼働中のバリデータに基づいて有効なUNLを調整するため、信頼できるバリデータが複数オフラインの場合でも、新しい[レジャーバージョン](ledgers.html) を _validated_ と宣言することができるようになるのです。
 
 ネガティブUNLは、部分的な停止中に結果を確定するネットワークの能力を向上させる以外、ネットワークのトランザクション処理方法やトランザクションの結果に影響を与えることはありません。
 
@@ -17,7 +17,7 @@ _([NegativeUNL Amendment](known-amendments.html#negativeunl)が必要です。)_
 
 XRPレジャープロトコルの各サーバーは、UNL（Unique Node List）と呼ばれる、共謀しないよう信頼できるバリデータのリストを持ち、各サーバーは、信頼できるバリデータが十分に新しいレジャーバージョンに合意したときのコンセンサスに基づいて、レジャーバージョンの検証を独自に決定しています。(デフォルトの構成では、リップル社が十分にユニークで信頼性が高く、独立性が高いと考えるバリデータからなる、リップル社が署名した推奨UNLを使用しています)。標準的な定足数要件は、信頼できるバリデータの少なくとも80%が合意することである。
 
-信頼できるバリデータの20%以上がオフラインになるか、ネットワークの残りの部分と通信できなくなると、ネットワークは定足数に達しないため、新しいレジャーの検証を停止する。これは、取引の結果が確定した後に変更されないようにするための設計上の選択である。このような状況では、残りのサーバーはまだオンラインであり、過去および暫定的なトランザクションデータを提供できるが、新しいトランザクションの最終的で不変の結果を確認することはできない。
+信頼できるバリデータの20%超がオフラインになるか、ネットワークの残りの部分と通信できなくなると、ネットワークは定足数に達しないため、新しいレジャーの検証を停止する。これは、取引の結果が確定した後に変更されないようにするための設計上の選択である。このような状況では、残りのサーバーはまだオンラインであり、過去および暫定的なトランザクションデータを提供できるが、新しいトランザクションの最終的で不変の結果を確認することはできない。
 
 しかしこれは、広く信頼されているバリデータがいくつかオフラインになった場合、ネットワークが前進しなくなる可能性があることを意味する。2020-10-06現在、リップル社が推奨するUNLには34人のバリデータがいるので、そのうち7人以上がオフラインになると、ネットワークの前進が止まってしまうことになります。さらに、1人または2人のバリデータが長期間オフラインになると、ネットワークは残りのバリデータ間の不一致の余地が少なくなり、コンセンサスの達成に時間がかかる可能性があります。
 
@@ -25,25 +25,19 @@ XRPレジャープロトコルの各サーバーは、UNL（Unique Node List）
 
 ハードウェアのメンテナンス、ソフトウェアのアップグレード、インターネット接続の問題、標的型攻撃、人為的ミス、ハードウェアの故障、自然災害などの外部環境など、多くの原因でバリデータは一時的に利用できなくなる可能性があるため、多様なバリデータのセットで100%の稼働時間を維持を期待することは合理的ではありません。
 
-「ネガティブUNL」とは、**オフラインまたは故障していると思われる信頼できる バリデータのリスト**であり、残存バリデータの総意として宣言されるものである。ネガティブUNLに含まれるバリデータは、新しいレジャーのバージョンがコンセンサスを得たかどうか を判断する際には無視される。
+「ネガティブUNL」とは、**オフラインまたは故障していると思われる信頼できるバリデータのリスト**であり、残存バリデータの総意として宣言されるものである。ネガティブUNLに含まれるバリデータは、新しいレジャーのバージョンがコンセンサスを得たかどうかを判断する際には無視される。
 
-ネガティブ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は[コンセンサスプロセス](consensus.html)と密接に関連し、不利な状況下でもネットワークの継続性と信頼性を維持できるように安全策をとって設計されたものである。すべての信頼できるバリデータが正常に動作している場合、ネガティブUNLは使用されず、何の効果もない。一部のバリデータがオフラインまたは同期していないように見えるとき、ネガティブUNLルールは有効になる。
 
 ネガティブUNLは意図的にゆっくりとした速度で変化するように設計されており、あるバージョンのレジャーの合意形成プロセスにおいて、どのネガティブUNLを適用すべきかという時間ベースの不一致を回避するためである。
 
@@ -56,17 +50,17 @@ XRPレジャープロトコルの各サーバーは、UNL（Unique Node List）
 
 V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過去256のレジャーに対して、1人のバリデータから受け取った検証票の総数である。
 
-この信頼性指標は、バリデータの可用性 _及び_ バリデータの挙動を測定するものである。バリデータがネットワークの他の部分と同期しており、採点サーバと同じプロトコル規則に 従っている場合、そのバリデータの信頼性スコアは高くなるはずである。バリデータの信頼性スコアは、以下のような理由で低下することがある。
+この信頼性指標は、バリデータの可用性 _及び_ バリデータの挙動を測定するものである。バリデータがネットワークの他の部分と同期しており、採点サーバと同じプロトコル規則に従っている場合、そのバリデータの信頼性スコアは高くなるはずである。バリデータの信頼性スコアは、以下のような理由で低下することがある。
 
 - バリデータ間のネットワーク接続が悪いため、バリデータの検証票がサーバーに届かない。
 - バリデータが動作を停止したり、過負荷になっている。
 - 様々な理由により、バリデータはサーバと同じプロトコルルールに従わない。可能性としては、設定ミス、ソフトウェアのバグ、意図的に[異なるネットワーク](parallel-networks.html)に従っている、または悪意ある行動などが考えられます。
 
-バリデータの信頼性が **50%** 未満である場合、そのバリデータはネガティブUNLに追加される候補である。ネガティブUNLから削除するには、バリデータの信頼性が **80%** 以上でなければならない。
+バリデータの信頼性が**50%**である場合、そのバリデータはネガティブUNLに追加される候補である。ネガティブUNLから削除するには、バリデータの信頼性が**80%超**でなければならない。
 
 バリデータを含む各サーバーは、信頼できるバリデータ全員について独自に信頼性スコアを算出している。あるバリデータの信頼性について、サーバーが異なると結論が異なることがある。それは、そのバリデータの投票が一方のサーバーに届いて他方のサーバーに届かなかったり、特定のレジャーについて意見が異なることが多かったり少なかったりするためである。あるバリデータをネガティブUNLに追加または削除するには、信頼できるバリデータの総意として、あるバリデータが信頼性の閾値を超えるか下回るかに合意する必要がある。
 
-**ヒント:** バリデータは自分自身の信頼性を追跡するが、自分自身をネガティブUNLに加えることは提案しない。バリデータの信頼性測定は、バリデータの投票がネットワークを通じて どの程度うまく伝わるかを考慮できないので、外部のサーバーからの測定値よりも 信頼性が低い。
+**ヒント:** バリデータは自分自身の信頼性を追跡するが、自分自身をネガティブUNLに加えることは提案しない。バリデータの信頼性測定は、バリデータの投票がネットワークを通じてどの程度うまく伝わるかを考慮できないので、外部のサーバーからの測定値よりも信頼性が低い。
 
 
 
@@ -81,9 +75,9 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
     **注記:** これは、[トランザクション](transaction-basics.html)や[疑似トランザクション](pseudo-transaction-types.html)を行わずにレジャーの状態データを変更する唯一の機会です。
 
 2. ネガティブUNLが満杯でない場合、各サーバーは信頼度50%未満のバリデータの中から、**最大1つ**のバリデータをネガティブUNLに追加することを提案する。
-3. ネガティブUNLが空でない場合、各サーバーはネガティブUNLから **最大1つ**のバリデータを削除することを提案する。サーバーがバリデータをネガティブUNLから削除することを提案できる理由は2つある。
+3. ネガティブUNLが空でない場合、各サーバーはネガティブUNLから**最大1つ**のバリデータを削除することを提案する。サーバーがバリデータをネガティブUNLから削除することを提案できる理由は2つある。
     - バリデータの信頼度が80%を超えている。
-    - 自身のUNLにそのバリデーターを持たない。(バリデータが永久に停止した場合、このルールは、サーバーの設定済み UNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが 削除されることを確実にする)。
+    - 自身のUNLにそのバリデーターを持たない。(バリデータが永久に停止した場合、このルールは、サーバーの設定済みUNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが削除されることを確実にする)。
 4. ネガティブUNLの変更案がコンセンサスに達した場合、その変更は次のフラグレジャーから適用される予定である。この方法で最大1つの追加と1つの削除をスケジュールすることができる。
 
 ネガティブUNLにバリデータを追加したり削除したりする提案は[UNLModify pseudo-transactions][]の形式を取る。それぞれの擬似トランザクションは他の[擬似トランザクション](pseudo-transaction-types.html)と同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバーの総意として同じ変更を提案する必要がある。
@@ -93,12 +87,12 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
 
 ### ネガティブUNLの制限
 
-ネットワークが2つ以上のサブネットワークに分断されるのを防ぐために、ネガティブUNLは定足数要件をUNLエントリ全体の60%未満に減らすことができない。これを強制するために、サーバーはネガティブUNL上のバリデータ数がサーバーの設定済みUNL内のバリデータ数の25%(切り捨て)である場合、ネガティブUNLが "満杯 "になったと見なす。(この25%は、25%のバリデータが削除された場合、残りの75%のバリデータの 80%の合意は元の数の60%に等しいという計算に基づいている)。もしサーバーがネガティブUNLが一杯になったと判断した場合、ネガティブUNLへの新たな追加は提案されない。
+ネットワークが2つ以上のサブネットワークに分断されるのを防ぐために、ネガティブUNLは定足数要件をUNLエントリ全体の60%未満に減らすことができない。これを強制するために、サーバーはネガティブUNL上のバリデータ数がサーバーの設定済みUNL内のバリデータ数の25%(切り捨て)である場合、ネガティブUNLが"満杯"になったと見なす。(この25%は、25%のバリデータが削除された場合、残りの75%のバリデータの80%の合意は元の数の60%に等しいという計算に基づいている)。もしサーバーがネガティブUNLが一杯になったと判断した場合、ネガティブUNLへの新たな追加は提案されない。
 
 
 ### 複数のバリデーター候補から選択する
 
-信頼性の閾値に基づき、複数のバリデータがネガティブUNLに追加される候補となる可能性がある。一度に最大1つのバリデータをネガティブUNLに追加できるので、サーバーはどのバリデータを 追加するかを選択しなければならない。複数の候補がある場合、サーバーは以下のメカニズムでどの候補を提案するかを 選択する。
+信頼性の閾値に基づき、複数のバリデータがネガティブUNLに追加される候補となる可能性がある。一度に最大1つのバリデータをネガティブUNLに追加できるので、サーバーはどのバリデータを追加するかを選択しなければならない。複数の候補がある場合、サーバーは以下のメカニズムでどの候補を提案するかを選択する。
 
 1. 親レジャーバージョンのレジャーハッシュを取得する。
 0. 各バリデータ候補の公開鍵を取得する。
@@ -110,13 +104,13 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
 このメカニズムには、いくつかの有用な特性があります。
 
 - すべてのサーバーが容易に入手でき、かつ迅速に計算できる情報を使用する。
-- 信頼できるバリデータのスコアが多少異なっていても、ほとんどのサーバーは同じ候補を選択する。これは、どのバリデータの信頼度が「最低」なのか「最高」なのかについて、 サーバ間で見解の相違があったとしても同様である。これは、あるバリデータが信頼性の閾値より上か下かについて、各サーバが 意見を異にしている場合でさえも同様である。したがって、ネットワークは、どのバリデータを追加または削除するかについて、 合意が得られる可能性が高い。
+- 信頼できるバリデータのスコアが多少異なっていても、ほとんどのサーバーは同じ候補を選択する。これは、どのバリデータの信頼度が「最低」なのか「最高」なのかについて、 サーバ間で見解の相違があったとしても同様である。これは、あるバリデータが信頼性の閾値より上か下かについて、各サーバが意見を異にしている場合でさえも同様である。したがって、ネットワークは、どのバリデータを追加または削除するかについて、合意が得られる可能性が高い。
 - レジャーバージョンごとに同じ結果が出るとは限りません。もしネガティブUNLへのある変更案が合意に至らなかったとしても、ネットワークは毎回その1つのバリデータの追加や削除を試みて失敗し続けることはない。ネットワークは、後のフラグ付きレジャーで別の候補をネガティブUNLに追加・削除することを試みることができる。
 
 
 ### 検証のフィルタリング
 
-[コンセンサスプロセスの検証ステップ](consensus.html#検証)では、親レジャーのネガティブUNLのバリデータを無効化します。各サーバーは無効化されたバリデータを取り除いた設定済みUNLからなる "有効UNL "を計算し、定足数を再計算します。(定足数は常に有効 UNL の 80% 以上、かつ設定 UNL の 60% 以上です)。無効化されたバリデータが検証票を送信した場合、サーバーは無効化されたバリデータの信頼性を計算するためにその票を追跡するが、あるバージョンのレジャーが合意に達したかどうかを判断するためにその票を使うことはありません。
+[コンセンサスプロセスの検証ステップ](consensus.html#検証)では、親レジャーのネガティブUNLのバリデータを無効化します。各サーバーは無効化されたバリデータを取り除いた設定済みUNLからなる"有効UNL"を計算し、定足数を再計算します。(定足数は常に有効UNLの80%以上、かつ設定UNLの60%以上です)。無効化されたバリデータが検証票を送信した場合、サーバーは無効化されたバリデータの信頼性を計算するためにその票を追跡するが、あるバージョンのレジャーが合意に達したかどうかを判断するためにその票を使うことはありません。
 
 **注記:** ネガティブUNLは、定足数を直接計算するのではなく、定足数の計算元となる信頼できるバリデータの合計を調整するものです。定足数はパーセンテージですが、投票数は整数であるため、信頼できるバリデータの合計を減らしても、定足数に達するために必要な投票数が変わるとは限りません。たとえば、総バリデータが15人である場合、80%はちょうど12人のバリデータである。これを14人に減らすと、80%は11.2人となり、定足数に達するには依然として12人の有効投票者が必要である。
 
@@ -130,7 +124,7 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
 
 {{ include_svg("img/negative-unl-01.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を無効化する予定で有効になった。
 
 {{ include_svg("img/negative-unl-02.svg", "Diagram: UnsteadyBは無効になる予定。") }}
 
@@ -161,7 +155,7 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
 
 {{ include_svg("img/negative-unl-10.svg", "Diagram: MissingAを設定済みUNLから削除した後、ネガティブUNLからも削除することを提案する。　") }}
 
-11. バリデータ操作者が自分の設定したUNLからMissingAを削除すると、そのバリデータ操作者は ネガティブUNLからMissingAを削除するように投票する。十分な数のバリデータが投票した時点で、MissingAを削除する提案は合意に達し、MissingAはスケジュールされ、最終的にネガティブUNLから削除される。
+11. バリデータ操作者が自分の設定したUNLからMissingAを削除すると、そのバリデータ操作者はネガティブUNLからMissingAを削除するように投票する。十分な数のバリデータが投票した時点で、MissingAを削除する提案は合意に達し、MissingAはスケジュールされ、最終的にネガティブUNLから削除される。
 
 {{ include_svg("img/negative-unl-11.svg", "Diagram: MissingAをネガティブUNLから削除。") }}
 

content/references/protocol-reference/ledger-data/ledger-object-types/negativeunl.ja.md

@@ -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' %}

content/references/protocol-reference/transactions/pseudo-transaction-types/unlmodify.ja.md

@@ -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' %}

dactyl-config.yml

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