墨汁マガジンVol.509「イーサリアム2.0でBeacon Chainがフォークした場合の問題を図解で理解する」

イーサリアム2.0のステーキングは、デポジットコントラクトがデプロイされたことで多くの注目を集めています。一方で、イーサリアム2.0自体の理解は乏しく、32ETHをステーキングしてバリデータとなった場合のリスクについてはよく知られていません。

本稿では2020年11月11日に起きたGethのマイノリティフォーク事件を例に、イーサリアム2.0のステーキングにおいて同様のことが起きた場合の影響とリスクについて詳しく解説を行います。

墨汁マガジン「 図解で理解するイーサリアムGethフォーク(分裂)事件 責任の所在はどこにあるのか？」を参照してください。

イーサリアム2.0バリデータのペナルティ

イーサリアム2.0にはDAOとしてネットワークを継続してファイナリティを付与するため、イーサリアム2.0のコンセンサスに参加しない場合、ペナルティであるInactivity LeakかPartial Slashingを受けることになります。イーサリアム2.0のコンセンサスアルゴリズムであるCasper FFGでは、

「大口または委託サービスほど高いペナルティを受け、32ETHごとに分散するインセンティブ設計」

がされています。今回の例で見るにはこれらを前提にバリデータのリスクを理解する必要があるのです。

ETH2バリデータのプロポーザーとコミッティ

まず簡単にイーサリアム2.0のバリデータについておさらいしておきましょう。イーサリアム2.0ではバリデータに”複数の役割”があり、Casper FFGでは全てのバリデータがコンセンサスに参加を行います。イーサリアム2.0ではブロックを生成するのはマイナーがASICやGPUを使用して演算するのではなく、バリデータからブロック