はじめに
本記事は、過去にコンセンサス・ベイスが主宰していたオンラインサロンの記事です。記事は2017年~2018年にかけて執筆されたため、一部は、既に古くなっている可能性があります。あらかじめご了承ください。
今回の内容
EthereumはFrontier、Homestead、Metropolis、Serenityと名付けられた4回のメジャーアップデートにより段階的に進化しており、現在、Metoropolisの第一段階であるByzantiumが完了しています。
本記事では、この後に予定されているSerenityで導入されるProof of StakeであるCasperについて解説します。
ゴール
EthereumのProof of Stake実装であるCasperについて理解します。
ターゲット
Ethereumに興味がある方を対象としています。
前提知識
暗号通貨やブロックチェーン技術の基礎を前提知識とします。
Proof of Workの問題
Proof of Workの問題
Ethereumは現在、Ethashと呼ばれるProof of Workアルゴリズム（以下PoW）により、ブロック生成を行なっています。 PoWはブロック生成時にブロック生成者であるマイナーに報酬を与えることにより、経済合理性を働かせ、ネットワークを正常に稼働させることが可能となっています。
PoWは以前より以下の2点が問題だと指摘されていました。
マイニング時の電力消費による環境問題
1点目は計算に大量の電力を必要とし、環境問題を引き起こしている点です。
Ethereumはブロック生成に巨大なメモリを必要とすることで、専用計算機であるASICでブロック生成することができないように設計されており、表面上はPoWの問題を解決しているように見えます。
しかし、現実的にはGPUでのブロック生成が可能であったり、将来ASICが進化して可能になるといった懸念もあります。
51%攻撃の懸念
2点目は、高い計算能力を保持するマイナーが全体の計算量の50%よりも多くの計算量を持ってしまうと不正なトランザクションを行うことができる点です。これを通称「51%攻撃」と呼びます。
これらの問題点を解決するアルゴリズムとして、SerenityではProof of Stakeを導入する予定です。
Proof of Stake
Proof of Stakeの設計思想
Proof of Stake（以下PoS）は直訳で「賭け金による証明」という意味になります。
PoSは上記のPoWの問題点を解決するために考案されました。
PoSでは、ブロック生成者のことをバリデーターとよびます。バリデーターは保持している資産を賭け金にすることにより、ブロック生成の成功確率を変化させます。
賭け金が多ければ多いほどブロック生成の成功確率は上がりブロック生成のインセンティブを受け取ることができ、逆に賭け金が少ないバリデーターはブロックを生成することが困難になります。
PoSはPoWによる以下の2つの問題点を解決しています。
1点目はブロック生成時の電力消費を抑えられる点です。賭け金に基づいて計算することで、ブロック生成のために必要な計算は簡略化されます。
2点目は51%攻撃を避けることができる点です。
Ethereumネットワークですでに発行されている半数以上のETHを収集することは、よほどの財力や政治的能力がないと困難です。
とはいえ、Proof of Stakeも完璧というわけではなく、以下のような問題点があります。
富の集中化
PoSでは賭け金は多ければ多い方が多くの利益を得られます。
そうなると賭け金を供出できる資産が多い方が有利なので、資産は使われず貯蓄しようとする傾向（流動性の低下）が生じます。
これでは通貨としての基本機能が意味をなさなくなります。
多くの資産を持つユーザーにさらに資産が集中し、PoWよりもさらにひどい富の集中化が発生してしまいます。
Nothing at Stake
PoWの場合、マイナーは一番長いブロックチェーンに次のブロックをつけてマイニングするインセンティブが働きます。
通常マイナー達は、巨額の初期費用を投じてマイニングのための設備を整え、さらにランニングコストとして電気代を投資しているため、マイニングに成功せずブロックが生成されなかった場合にはその投資額が回収できず純粋な損失となります。
そして、マイナーの持つ計算力(ハッシュパワー)には限りxがあるため、多数のフォークを同時にマイニングせず、勝ちそうな一つのフォークをマイニングする方が報酬を得られる可能性が上がるわけです。
このような性質が、チェーンを攻撃するよりも、正常に維持する方向に行動した方がいいというインセンティブになっているわけです。 対してPoSの場合、賭け金はブロックが生成されない場合にも失われることはなく、そのまま返金されるだけです。
そのため、バリデーターはPoWの時のように、最も長いブロックチェーンを選んで承認するインセンティブはなく、むしろ全てのフォークしたブロックチェーンを承認するの方が理にかなっている、という状態が起きてしまいます。
承認作業のためにPoWのような演算コストがかからない（何も賭けていない）ため、正常に振る舞うインセンティブがなく、悪意のある振る舞い（複数のチェーンへの投票）を気軽に行うことができます。
また、チェーンが意図せず、または故意に分岐した状態を考えてみます。
バリデーターは賭け金をデポジットし、PoSの報酬を得ようとします。しかしどちらのチェーンも同じブロック高であれば、どちらが正しいチェーンかを判断することはできません。
悪意があろうがなかろうが、どちらのチェーンでも賭け金をデポジットすることが経済的合理性を持ってしまいます。
さらに長期的な問題として、このフォーク自体は賭け金を払うことができるバリデーターであれば、ブロックのどこからでもやり直すことが可能です。これではフォークした事態を収拾することは不可能です。
ロングレンジ攻撃(The Long-Range Attack)
ロングレンジ攻撃とは、攻撃者が勝手にフォークさせたチェーンを作り、正当なチェーンよりも自分たちのチェーンを長くすることで乗っ取ってしまう攻撃のことです。
ジェネシスブロックやその直後のブロックのような 、古く、すでにデポジットが引き出されているブロックからフォークさせたチェーンを作ることで、賭け金を失うリスクなしにチェーンを伸ばすことができるために起きるものです。
2つのCasper
Casperの仕様は2つ考えられています。Casper FFG(Friendly Finality Gadget)とCasper CBC(Correct By Construction)です。
2018年2月現在はテストネット上でFFGの検証が進められています。
Casperへの移行は段階的に行われる予定でまずはFFGが導入される予定です。その後の詳細な技術仕様はまだ決定していません。
Casper FFG
Casper FFG(Friendly Finality Gadget)はVitalikにより提案されている実装であり、PoWとPoSのハイブリッドなシステムです。
将来的にはPoWの部分をPoSのラウンドロビンにするなどの構想があります。
ブロックチェーンは常に分岐する可能性をはらんでいますが、Casperはこの分岐された状態から常に一つだけの正しいチェーンを採用する動作をとります。
効率良くチェーン採用を行うために100ブロック高ごとにPoSのチェックポイントを設けています。
チェックポイントの概念
通常のPoWでブロック生成を行い、チェックポイントでは賭け金をデポジットしたバリデーターが投票を行います。
バリデーターは同じブロック高でチェックポイントが2箇所あった場合に、どちらか一方にしか投票することはできず、他に投票している範囲内で二重に投票することはできません。
これらのどちらか一方でも違反したバリデーターは、デポジットした賭け金を没収されてしまいます。 チェックポイントでデポジットされた掛け金の2/3の投票があると、そのブロックは正当化されます。
しかしこれは仮の決定で、正当化したブロックまでが確定したチェーンと見なされるためには、さらに100ブロック高先のブロックが正当化される必要があります。
またバリデーターがデポジットした賭け金は4ヶ月間ほど引き出しが制限され、その間にバリデーターが先のルールに違反した場合も賭け金は没収されてしまいます。
この罰則を与える機能はSlasherと呼ばれ、ブロックチェーンのツリーを正しい方向に導きます。
図1：Casper FFGのチェックポイントツリー。破線はチェックポイント間に100ブロック存在することを示しています
図2：起点のrからb1, b2, b3とチェックポイントを正当化していきます。チェックポイント間にsupermajority linkが存在する場合は間のチェックポイントを飛ばして正当化することができます。
1）2つの競合するチェックポイント両方を確定することはできません。
2） Supermajority linkがチェックポイントを追加する際は、他のチェーンのチェックポイントに、そのチェックポイントの正当な親よりも先にリンクすることはできません。
図3：aのチェーンはbのチェーンの子にリンクすることはできません。
動的なバリデーターセットの有効化
バリデーターの集団（バリデーターセット）は変更可能である必要があります。 また、バリデーターセットは新たなバリデーターの参加と、既に参加中のバリデーターの脱退が可能でなければなりません。
このようなバリデーターの振る舞いを実現するために定義されたのがDynastyという概念です。
Dynastyを統治と訳すのが適切かどうかはわかりませんが、この概念によってバリデーターの参加タイミングを調整しています。
Dynastyとはそのチェーンにおける、チェックポイントの総数です。
とあるバリデーターが掛け金をデポジットした場合、その時点のDynastyの二つ先のチェックポイントからバリデーターがPoSの検証に入ることができます。
また賭け金を引き出す際も、その時点のDynastyの二つ先のチェックポイントでバリデーターセットから抜け出すことが可能です。
バリデーターセットはthe forward validator set とthe rear validator setに分類されます。
両者は基本的に多くのバリデーターが重複している状態ですが、著しくかけ離れた場合、the forward validator set とthe rear validator setによる投票で、縫い合わせ機構が働き、正しいチェーンを選択します。
図4：縫い合わせ機構が動作しない場合はこのような挙動が起きてしまいます。本来ならば、cとc’はブロック高が一緒なので、Slasherの対象となるはずですが、バリデーターセットが異なるため、Slasher機構が動作しません 。
まとめ
本稿では、PoWの問題を解決すべく導入されるPoSにも問題があること、その問題を解決するために2つのCasperが提唱されていることを確認し、Vitalikが進めているCasper FFGを解説しました。
次回は、もう一方のCasper CBCの解説と、Casperは何を解決しようとしているのかを再度確認し、Casper導入後の展望について解説します
参考
Casper the Friendly Finality Gadget https://arxiv.org/pdf/1710.09437.pdf Ethereum Casper 101 https://medium.com/@jonchoi/ethereum-casper-101-7a851a4f1eb0 The History of Casper — Chapter 1 https://blog.ethereum.org/2016/12/06/history-casper-chapter-1/ The History of Casper – Chapter 2 https://blog.ethereum.org/2016/12/07/history-casper-chapter-2/
