ネガティブUNL

(NegativeUNL Amendmentによって追加されました。)

ネガティブUNLは、XRP Ledgerのコンセンサスプロトコルの機能で、バリデータの部分的な停止中にネットワークの前進を可能にする liveness を向上させるものです。ネガティブUNLを使用すると、サーバは現在オンラインかつ稼働中のバリデータに基づいて有効なUNLを調整するため、信頼できるバリデータが複数オフラインの場合でも、新しいレジャーバージョンを validated と宣言することができるようになるのです。

ネガティブUNLは、部分的な停止中に結果を確定するネットワークの能力を向上させる以外、ネットワークのトランザクション処理方法やトランザクションの結果に影響を与えることはありません。

背景

XRP Ledgerプロトコルの各サーバは、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はスタンドアロンモードに影響を及ぼさない。

仕組み

ネガティブUNLはコンセンサスプロセスと密接に関連し、不利な状況下でもネットワークの継続性と信頼性を維持できるように安全策をとって設計されたものである。すべての信頼できるバリデータが正常に動作している場合、ネガティブUNLは使用されず、何の効果もない。一部のバリデータがオフラインまたは同期していないように見えるとき、ネガティブUNLルールは有効になる。

ネガティブUNLは意図的にゆっくりとした速度で変化するように設計されており、あるバージョンのレジャーの合意形成プロセスにおいて、どのネガティブUNLを適用すべきかという時間ベースの不一致を回避するためである。

信頼性評価

ネットワーク上の各サーバは、共謀しないように信頼するバリデータのリストであるUNLを持っています。(デフォルトでは、サーバの正確なUNLはリップル社が公表している推奨バリデータリストに基づいて暗黙的に設定されます)。各サーバは、信頼できるバリデータの「信頼性」を1つの指標で追跡します。それは、直近256件のレジャーのうち、バリデータの検証投票がサーバの考えるコンセンサスと一致した割合です。言い換えれば

信頼性 = V_a ÷ 256

V_aは、サーバ側のコンセンサス見解と一致した過去256のレジャーに対して、1人のバリデータから受け取った検証票の総数である。

この信頼性指標は、バリデータの可用性及びバリデータの挙動を測定するものである。バリデータがネットワークの他の部分と同期しており、採点サーバと同じプロトコル規則に従っている場合、そのバリデータの信頼性スコアは高くなるはずである。バリデータの信頼性スコアは、以下のような理由で低下することがある。

バリデータ間のネットワーク接続が悪いため、バリデータの検証票がサーバに届かない。
バリデータが動作を停止したり、過負荷になっている。
様々な理由により、バリデータはサーバと同じプロトコルルールに従わない。可能性としては、設定ミス、ソフトウェアのバグ、意図的に異なるネットワークに従っている、または悪意ある行動などが考えられます。

バリデータの信頼性が50%である場合、そのバリデータはネガティブUNLに追加される候補である。ネガティブUNLから削除するには、バリデータの信頼性が80%超でなければならない。

バリデータを含む各サーバは、信頼できるバリデータ全員について独自に信頼性スコアを算出している。あるバリデータの信頼性について、サーバが異なると結論が異なることがある。それは、そのバリデータの投票が一方のサーバに届いて他方のサーバに届かなかったり、特定のレジャーについて意見が異なることが多かったり少なかったりするためである。あるバリデータをネガティブUNLに追加または削除するには、信頼できるバリデータの総意として、あるバリデータが信頼性の閾値を超えるか下回るかに合意する必要がある。

ヒント

バリデータは自分自身の信頼性を追跡するが、自分自身をネガティブUNLに加えることは提案しない。バリデータの信頼性測定は、バリデータの投票がネットワークを通じてどの程度うまく伝わるかを考慮できないので、外部のサーバからの測定値よりも信頼性が低い。

ネガティブUNLの変更

レジャーバージョンが256で均等に割り切れる場合、フラグレジャー とみなされます。ネガティブUNLはフラグレジャーでのみ変更可能です。(フラグレジャーは、XRP Ledgerメインネットで約15分に1回発生します。トランザクション量の少ないテストネットワークでは、もっと低頻度な場合があります)

各フラグレジャーは、以下の全ての変更が適用されます。

前のフラグレジャーで予定されていたネガティブUNLの変更は、次のレジャーバージョンから有効となる。このフラグレジャーの検証のための合意プロセスそのものは、予定されていた変更を利用しない。
注記
これは、トランザクションや疑似トランザクションを行わずにレジャーの状態データを変更する唯一の機会です。
ネガティブUNLが満杯でない場合、各サーバは信頼度50%未満のバリデータの中から、最大1つのバリデータをネガティブUNLに追加することを提案する。
ネガティブUNLが空でない場合、各サーバはネガティブUNLから最大1つのバリデータを削除することを提案する。サーバがバリデータをネガティブUNLから削除することを提案できる理由は2つある。
- バリデータの信頼度が80%を超えている。
- 自身のUNLにそのバリデータを持たない。(バリデータが永久に停止した場合、このルールは、サーバの設定済みUNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが削除されることを確実にする)。
ネガティブUNLの変更案がコンセンサスに達した場合、その変更は次のフラグレジャーから適用される予定である。この方法で最大1つの追加と1つの削除をスケジュールすることができる。

ネガティブUNLにバリデータを追加したり削除したりする提案はUNLModify pseudo-transactionsの形式を取る。それぞれの擬似トランザクションは他の擬似トランザクションと同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバの総意として同じ変更を提案する必要がある。

ネガティブUNLの予定された有効な変更は、レジャーの状態データの中のネガティブUNLオブジェクトに追跡される。

ネガティブUNLの制限

ネットワークが2つ以上のサブネットワークに分断されるのを防ぐために、ネガティブUNLは定足数要件をUNLエントリ全体の60%未満に減らすことができない。これを強制するために、サーバはネガティブUNL上のバリデータ数がサーバの設定済みUNL内のバリデータ数の25%(切り捨て)である場合、ネガティブUNLが"満杯"になったと見なす。(この25%は、25%のバリデータが削除された場合、残りの75%のバリデータの80%の合意は元の数の60%に等しいという計算に基づいている)。もしサーバがネガティブUNLが一杯になったと判断した場合、ネガティブUNLへの新たな追加は提案されない。

複数のバリデータ候補から選択する

信頼性の閾値に基づき、複数のバリデータがネガティブUNLに追加される候補となる可能性がある。一度に最大1つのバリデータをネガティブUNLに追加できるので、サーバはどのバリデータを追加するかを選択しなければならない。複数の候補がある場合、サーバは以下のメカニズムでどの候補を提案するかを選択する。

親レジャーバージョンのレジャーハッシュを取得する。
各バリデータ候補の公開鍵を取得する。
候補のバリデータと親レジャーのハッシュの排他的論理和(XOR)を計算する。
XOR演算の結果のうち、数値が最も小さいバリデータを提案する。

あるフラグレジャーのネガティブUNLから削除される候補が複数ある場合、サーバは同じメカニズムでそれらの中から選択します。

このメカニズムには、いくつかの有用な特性があります。

すべてのサーバが容易に入手でき、かつ迅速に計算できる情報を使用する。
信頼できるバリデータのスコアが多少異なっていても、ほとんどのサーバは同じ候補を選択する。これは、どのバリデータの信頼度が「最低」なのか「最高」なのかについて、サーバ間で見解の相違があったとしても同様である。これは、あるバリデータが信頼性の閾値より上か下かについて、各サーバが意見を異にしている場合でさえも同様である。したがって、ネットワークは、どのバリデータを追加または削除するかについて、合意が得られる可能性が高い。
レジャーバージョンごとに同じ結果が出るとは限りません。もしネガティブUNLへのある変更案が合意に至らなかったとしても、ネットワークは毎回その1つのバリデータの追加や削除を試みて失敗し続けることはない。ネットワークは、後のフラグ付きレジャーで別の候補をネガティブUNLに追加・削除することを試みることができる。

検証のフィルタリング

コンセンサスプロセスの検証ステップでは、親レジャーのネガティブUNLのバリデータを無効化します。各サーバは無効化されたバリデータを取り除いた設定済みUNLからなる"有効UNL"を計算し、定足数を再計算します。(定足数は常に有効UNLの80%以上、かつ設定UNLの60%以上です)。無効化されたバリデータが検証票を送信した場合、サーバは無効化されたバリデータの信頼性を計算するためにその票を追跡するが、あるバージョンのレジャーが合意に達したかどうかを判断するためにその票を使うことはありません。

注記

ネガティブUNLは、定足数を直接計算するのではなく、定足数の計算元となる信頼できるバリデータの合計を調整するものです。定足数はパーセンテージですが、投票数は整数であるため、信頼できるバリデータの合計を減らしても、定足数に達するために必要な投票数が変わるとは限りません。たとえば、総バリデータが15人である場合、80%はちょうど12人のバリデータである。これを14人に減らすと、80%は11.2人となり、定足数に達するには依然として12人の有効投票者が必要である。

ネガティブUNLは、提案されたトランザクションセットにどのトランザクションを含めるかを選択するなど、コンセンサスプロセスの他の部分には影響を与えない。これらのステップは常に設定されたUNLに依存し、その閾値は何人の信頼できるバリデータがコンセンサスラウンドに積極的に参加しているかに基づいている。ネガティブUNLにあるバリデータもコンセンサスプロセスに参加することができる。

例

次の例は、ネガティブUNLが合意形成プロセスにどのような影響を与えるかを示している。

サーバのUNLが38人の信頼できるバリデータで構成されているとすると、80%の定足数は38人のうち少なくとも31人の信頼できるバリデータである。

MissingAとUnsteadyBという2人のバリデータがオフラインになったとする。(両者とも信頼度スコアは50%未満である。)レジャー N の合意プロセスにおいて、残りのバリデータの多くがUnsteadyBをネガティブUNLに追加することを提案する。この動議は残りのバリデータのうち少なくとも31人の定足数で可決され、レジャー N はUnsteadyBを無効化する予定で有効になった。

レジャー N+1 から N+256 については、コンセンサスプロセスをそのまま継続する。
次のフラグレジャー N+256 では、UnsteadyBはレジャーの「予定」から「無効」リストへ自動的に移動する。また、MissingAがまだオフラインであるため、検証者の総意として、次のフラグレジャーでMissingAを無効化する予定とする。

レジャー N+257 から N+512 について、定足数は37名中30名となった。
UnsteadyBがレジャー N+270 でオンラインに復帰。レジャー N+270 から N+511 に対してネットワークの他の部分と一致する検証票を送信し、信頼性スコアが80%以上となる。

次のフラグレジャー N+256 では、予定通りMissingAが自動的に無効リストに移される。一方、UnsteadyBは信頼性スコアが向上したため、検証者の総意としてネガティブUNLから削除される予定である。

レジャー N+513 から N+768 の場合、定足数は36人中29人である。MissingAがオフラインの間、UnsteadyBは安定的に検証結果を送り続ける。
フラグレジャー N+768 では、予定通りUnsteadyBが無効リストから自動的に削除されています。

最終的に、あなたはMissingAがおそらく戻ってこないと判断し、あなたのサーバの設定されたUNLからそれを削除します。あなたのサーバはそれ以降、各フラグレジャーからMissingAをネガティブUNLから削除することを提案し始める。

バリデータ操作者が自分の設定したUNLからMissingAを削除すると、そのバリデータ操作者はネガティブUNLからMissingAを削除するように投票する。十分な数のバリデータが投票した時点で、MissingAを削除する提案は合意に達し、MissingAはスケジュールされ、最終的にネガティブUNLから削除される。