ヴィタリック：反相関のインセンティブを高めて分散型誓約をサポートする

By Vitalik Buterin, @vitalik.eth; Compiled by Song Xue, Golden Finance

プロトコルでより良い分散化を奨励する戦略の1つに、ペナルティの相関性があります。 つまり、参加者が（偶然も含めて）悪さをした場合、彼らと同時に悪さをした他の参加者（総ETHで測定）が多ければ多いほど、彼らが受ける罰は大きくなります。 この理論では、参加者が大規模であれば、たとえトークンを多くの名目上別々のアカウントに分散していたとしても、自分がコントロールするすべての「ID」全体でミスが再現される可能性が高くなります。

このテクニックは、イーサリアムの削減（そして間違いなく非活動リーク）メカニズムですでに使用されています。 しかし、非常に特殊な攻撃シナリオでのみ発生するエッジケースのインセンティブは、実際には発生しない可能性があり、分散化のインセンティブとしては不十分かもしれません。

この記事では、ほぼすべての検証者が少なくとも時折行っている、証明の見落としなどのより「ありふれた」失敗に、同様の反相関インセンティブを拡張することを提案しています。 この理論は、裕福な個人や誓約プールを含む大規模な誓約者が、多くの検証者を同じインターネット接続、あるいは同じ物理的なコンピュータ上で実行することを示唆しています。 そのような誓約者は、常に各ノードに別々の物理的なセットアップを持つことができますが、もしそうすることになれば、誓約のスケールメリットを完全に排除することになります。

健全性チェック: 同じ「クラスタ」内の異なるバリデータからのエラーは、実際には相関している可能性が高いのでしょうか?

次の2つのデータセットを組み合わせることで、これをチェックすることができます：(i)最近の期間の証明データで、各時間帯にどの検証者が証明されるべきであったか、そしてどの検証者が実際に証明されたかを示し、(ii)多くの検証者を含むクラスタ（例えば、"Lido", "Cisco）"、"Coinbase"、"Vitalik Buterin"）。 こちら、こちら、こちら。blank">こちら で前者のダンプを見つけ、こちら で後者のダンプを見つける。

次に、共通の失敗の総数を計算するスクリプトを実行します。同じクラスタ内のバリデータの2つのインスタンスが、証明のために同じタイムスロットを割り当てられ、そのタイムスロットで失敗します。

また、予想される共通の失敗も計算します。失敗がランダムな偶然の結果であった場合、「発生するはずであった」一般的な失敗の数。

たとえば、10台の検証機があり、1台はクラスタサイズ4で、他の検証機は独立していて、3台の検証機が失敗したとします。

ここには共通の失敗があります: 最初のクラスタの2番目と4番目のバリデータです。 そのクラスター内の4つのバリデータがすべて失敗した場合、6つの共通の失敗があり、6つの可能なペアごとに1つずつあります。

しかし、共通の失敗はいくつ「あるべき」だろうか？ これは難しい哲学的な質問です。

各失敗について、共通失敗の数は、タイムスロット内の他の検証者の失敗率にクラスタ内の検証者の数を掛けたものに等しいと仮定し、二重カウントを補正するためにそれを半分にします。

グローバル故障率を2乗して計算し、各クラスタについて[n*(n-1)]/2を乗じる。 これは[(3/10)^2]*6=0.54

各バリデータの失敗を履歴全体にわたってランダムに再分配する。

どの方法も完璧ではありません。 最初の2つの方法は、異なる品質設定のクラスタを考慮できていません。 例えば、タイムスロット8103681は、おそらくブロックの投稿が異常に遅いため、1つのタイムスロットに含まれない証明が多数あります。

このpythonの出力で「10216 ssfumbles」を見てください。

結局、3つのアプローチを実装しました。上記の最初の2つと、「実際の一般的な失敗」と「擬似的な一般的な失敗」を比較する、より複雑なアプローチです。ランダム検証者の失敗は、同じような失敗率になります。

私はまた、misses と misses を明確に区別しています。である。

ミス：検証者が現在の期間で証明を見逃しているが、前の期間で正しく証明した場合。color: rgb(0, 112, 192);">Miss: 検証者が現在の期間で証明を見逃しており、前の期間でも証明を見逃している場合。

目標は、2つの異なる現象を区別することです：(i)通常運用中のネットワーク障害、(ii)オフラインまたは長期的な障害。

また、最大カットオフとシングルスロットカットオフという2つのデータセットで同時にこの分析を行いました。 1つ目のデータセットでは、プルーフがまったく含まれていない場合のみ、バリデータが期間内に失敗したものとして扱う。 2つ目のデータセットでは、証明が1つのスロットに含まれていない場合に、バリデータが失敗したものとして扱う。

よくある失敗の期待値を計算する最初の2つの方法の結果を以下に示す。 ここでのSSfumblesとSSmissesは、単一のタイムスロットデータセットを使ったファンブルとミスです。

1つ目の方法では、効率化のためにより制限されたデータセットが使用されるため、実際の行は異なります。

「期待されるクラスタ」と「誤ったクラスタ」の列は、クラスタが無相関であり、上記の手法に基づいている場合、次のことを示しています。期待される(Expected)」列と「偽のクラスタ(False Cluster)」列は、クラスタが関連していない場合、上記の手法に基づいて、クラスタ内にどれだけの共通の失敗が「あるべき」かを示しています。 実際」の列は、実際にどれだけの共通の故障があるかを示している。 一貫して、クラスタ内に「相関のある失敗が多すぎる」という強い証拠が見られる。同じクラスタに属する2人の検証者は、異なるクラスタに属する2人の検証者よりも証明を見逃す可能性が有意に高い。

これをどのようにペナルティ・ルールに適用するか？

私は単純な議論をします：各スロットにおいて、現在ミスしているスロットの数を最後の32スロットの平均で割ったものをpとします。

このタイムスロット証明のペナルティはpに比例するはずです。

つまり、他の最近のスロットと比較して、スロットの証明に失敗した場合のペナルティは、そのスロットで失敗した検証者の数に比例すべきです。

このメカニズムの1つの良い特性は、簡単に攻撃されないということです：失敗すると、どのような場合でもペナルティが減ります。

それでは、実際に実行してみましょう。

basic:失敗1回につき1点(つまり現状と同じ)

basic_ss:同じですが、1つのスロットが含まれていないと失敗とみなされません。

excess:上記で計算されたpでpポイントのペナルティを課す

extra_ss:上記で計算されたpでpポイントのペナルティを課す、ミスとしてカウントされないためにはスロットを1つ含む必要がある

「基本」シナリオを使用した場合、「大」シナリオは、「基本」シナリオと「大」シナリオの2つのシナリオがあります。"basic "シナリオを使用すると、"large "シナリオは "small "シナリオに対して約1.4倍のアドバンテージがあります（シングルスロットのデータセットでは約1.2倍）。 エクストラ」シナリオでは、これは～1.3倍（シングル・タイムスロット・データセットでは～1.1倍）に低下する。 わずかに異なるデータセットを用いた他のいくつかの反復では、過剰処罰スキームは、「大物」の「小物」に対する優位性を一様に狭めている。

ここで何が起こっているのか？

スロットあたりの故障の数は少なく、通常は数十件程度です。 これは、ほとんどすべての「大きなシェア」よりもはるかに小さい。 実際、これは大規模なプレッジャーが1つのスロットでアクティブにするベリファイヤーの数よりも少ないのです（つまり、彼らの総在庫の1/32）。 大規模なプレッジャーが同じ物理コンピューターやインターネット接続で多くのノードを実行している場合、障害が発生するとそのすべてのバリデーターに影響が及ぶ可能性があります。

つまり、大規模な検証者がプルーフ・インクルージョンに失敗した場合、単独で現在のスロットの失敗率を変更し、その結果ペナルティが増加します。 小さな検証者はこのようなことはしない。

原理的には、大規模な利害関係者は、各検証者を別々のインターネット接続に置くことで、このペナルティ方式を回避できます。 しかしこれは、大規模な利害関係者が同じ物理インフラを再利用できるという規模の経済の利点を犠牲にすることになります。

さらなる分析

• 同じクラスタ内の検証者が同時に証明に失敗する可能性が高い場合、この影響の大きさを確認するための代替戦略を探します。

• 小規模な検証者に対する大規模な検証者の平均的な優位性を最小化する、理想的な（しかしオーバーフィッティングや利用不可能を避けるためにまだ単純な）報酬/ペナルティスキームを見つけようとする。

• そのようなインセンティブスキームのセキュリティ特性を実証することを試みる。理想的には、奇妙な攻撃（例えば、平均を操作するために特定の時間に戦略的にオフラインになる）のリスクが高すぎて割に合わない「設計空間領域」を特定することである。

• 地理的な場所によるクラスタリング。 これは、メカニズムが地理的な分散化をも促すかどうかを決定する可能性があります。

• （実行とビーコンの）クライアントソフトウェアによるクラスタリング。 これにより、メカニズムが少数のクライアントの使用にもインセンティブを与えることができるかどうかを判断できます。