Casper 2.0_Zug（ザグ）コンセンサス
Zug（ザグ）コンセンサスのメカニズム
ここでは、Casper v2.0におけるZugコンセンサスのメカニズムについて掘り下げていきます。
Highway
CasperLabsにて開発されたHighway（ハイウェイ）コンセンサスプロトコルは、1.0 メインネットにデプロイされた最初のインハウスコンセンサスプロトコルでした。
Concept
Highwayの特徴的な機能は、バリデータがどのeraに何回参加しているかを管理するパラメータを動的に代替えすることで、バリデータ毎に変化させることが可能となっている”速度”でした。
Highwayの限界値
Highwayは、とても複雑かつ不透明です。プロトコルの内部状態を進化させる方法について直感的なものの開発は困難です。また、バリデータの”速度”を変化させることは有利性を制限しているようでもあり、実際では、保守的な考えに基づき最大”速度”（i.e. block time）に設定されていました。
Zug（ザグ）
Highwayの限界を考慮し、よりシンプルなプロトコルであるZugが開発されました。内部状態はかなりシンプルになっており、同じ数のバリデータがより少ないメッセージかつ即座にコンセンサスに到達することを可能としています。
Zugの仕様
Zugのプロトコルをまとめると、下記となります。
- 毎回、その回でのリーダーが新しいブロック, Bを提案します。
- 全てのバリデータが、echoメッセージをBの署名を用いてブロードキャストし作成します。
- 適切なブロックBが67%のバリデータからechoを受信した際に、
- 次の回が開始されます。次のリーダーは、Bのchildを提案できます。
- 全てのバリデータは、 yesの投票メッセージのブロードキャストと署名をします。
- 制限時間内に処理されなかった場合、代わりにバリデータはnoを投票します。
- 67%のバリデータからnoの投票が行われた場合も、次の回が開始されます。次のリーダーは、それより前のブロックからchildを提案でき、この回はスキップします。
- 67%のバリデータからyesの投票が行われた場合、Bがファイナライズされ全てのancestors（祖先）も一緒に実行します。（通常は、次の回はこの時点で既に開始されています。）
提案（proposal）、投票（vote）そしてechoはブロードキャストされる為、正しいノードが1つのメッセージを受け取ると結果的に全てのノードがそれを受け取ります。正直なバリデータは、回毎に1つのechoもしくは投票を送信します。34%のバリデータがdouble-sign（2度の署名）を行わない限り、その回での最大ブロックは、67%のechoを獲得し、安全確保の為、ファイナライズされたブロックがスキップされることはないはずです。67%のechoが提案用にある以上、次の回は開始されZugが止まることはありません。十分なechoが獲得できず全員がnoを投票した場合も、次の回が開始されます。
バリデータセットのサイズによる影響
Zugはより小さいコミュニケーションの余剰を持っている為、バリデータセットのサイズが大きくなることはあり得ます。
Summary
Zugプロトコルの適用は、効率性や拡張性という観点でCasper Networkの飛躍を表現しています。