Eth2 Beacon Chain 初のハードフォーク「HF1」の目的: ライトクライアントのサポート、Beacon Chainの改善、シャーディングやマージを見据えたハードフォークのテスト
HF1とは（TL;DR）
Ethereum 2.0 Beacon Chainの初のハードフォークとなるHF1（仮称）が提案された。
HF1の主な目的は次の3つ。
ライトクライアントのサポート
Beacon Chainの改善
ハードフォークのテスト
ライトクライアントのサポート
ライトクライアントは、処理能力が低いコンピュータでも動かせる軽量のブロックチェーンクライアントのことである。スマートフォンのようなモバイルデバイスや、Webブラウザ上で動かすことが想定されている。ライトクライアントがあれば、より安全なウォレットの作成が可能になる。例えばMetamaskはノードプロバイダーのInfuraに依存しているが、その依存が必要無くなる。 HF1では、Eth2ライトクライアントのためにsync committeeを追加する。sync committeeの目的は、チェーンのヘッド（先頭）を小さなオーバーヘッドで決定することである。オーバーヘッドの具体的なデータサイズは、ヘッドを追うために1日あたり20kB以下、一つのブロックを検証するために500kB以下と見積もられており、これらは小さい。
cipepser.icon ヘッドとblock headerは別のものです？
minaminao.icon です。headはcanonical chainの最新のブロックです。
cipepser.icon あざます！
nrryuya.icon > ヘッドを決定というよりは、（既にコンセンサスで選ばれたヘッドを）検証できるようにするという感じ
sync committeeは、約27時間ごとに1,024のバリデータがランダムに選ばれる。選ばれたバリデータたちは、現在のヘッドをアテステーションする署名を公開する。ライトクライアントは、公開されたアテステーションを元にヘッドを特定する。ちなみにアテステーションはLightClientUpdateというオブジェクトに含まれてブロードキャストされ、sync committeeのバリデータが報酬を得るためにBeacon Chainに書き込まれる。
cipepser.icon ライトクライアントは署名とヘッドだけを同期してる？
minaminao.icon ライトクライアントは、ヘッダー、sync committeeに関する情報、ファイナリティを受信＆保持します(詳細)。"同期"という意味だと、ライトクライアントはフルノードから情報を受信するが、その情報を他のライトクライアントに共有しない設計になるのかな、と予想してます。 Beacon Chainの改善
主に5つの改善が行われる。
計算コストの削減
アテステーションを行うバリデータへの報酬を計算する方法を変更することで、Merkleツリーのアップデートを低コストで行えるようになる。
処理の簡素化
バリデータ集合の変更とペナルティの計算を、1エポックごとに行うのではなく64エポックごとに行うように変更することで、空のエポックが続く場合への対処が簡単になるという。
「空のエポックが続く場合」とは、例えば、あるブロックの次のブロックが1,024スロット（32エポック）後であり、その間のスロットにはブロックが存在しなかったようなケースである。
cipepser.icon （為念）1エポック = 32スロットですよね？
minaminao.icon ですね
cipepser.icon もともとは1エポックごとにバリデータ集合を作り、スロットごとにそのバリデータ集合からバリデータ（のサブセット）が選出される感じでしたっけ？:chimpan: でもそうなるとブロックが存在しないとはいったい...？
minaminao.icon 各スロットごとに1つのバリデータがブロックプロポーザーとして選出されるのですが、ブロックが存在しないケースは、プロポーザーがブロックを生成しなかったり、ネットワークが遅延して全く届かなかったりした場合ですね
cipepser.icon エポックがバリデータの集合＋ペナルティを計算する単位時間かと思ってましたが、64エポックになると理解を改める必要がある？
minaminao.icon そうなりますねー
nrryuya.icon > Epochがその単位時間というより、Casper FFGの単位時間ですね
cipepser.icon fmfm
inactivity leakの軽減
inactivity leakとは、バリデータがオフラインでコンセンサスに貢献しない期間に応じて与えられるペナルティである。inactivity leakが無いと、オフラインのバリデータが1/3を超えてしまったらファイナリティが得られなくなってしまう。 inactivity leakの計算式をオフラインの時間の二次関数に応じたペナルティに変ることで、ただ単にネットワークへの接続が不安定なだけのhonestなノードへのペナルティを減らせる。
34% attackの対策
34% attackとは、各スロットに割り当てられたバリデータの34%を攻撃者が制御できる場合にフォークチョイスを攻撃者が望むものに変える攻撃である。 https://gyazo.com/bff56ae834f979f0693a61d174beb642
例を示す。スロットに割り当てられたバリデータ数をmとする。n+1スロットで攻撃者はBブロックとアテステーションを公開しなかったとする。結果的にn+1スロットでbeacon blockが作られず空になった場合、n+2スロットで攻撃者がBブロックのフォークを支持すれば、そのフォークのスコアは0.68mになる。正常なバリデータは、n+2スロットでAに繋がる新しいCブロックを作成するが、そのスコアは0.66mであり、攻撃者が支持するフォークに負ける。
提案されている対策は、フォークチョイスをブロックの木ではなく、(ブロック, スロット)のタプルの木で行うことである。スロットn+1のアテステーションは(BLANK, n+1)へカウントされるようになり、n+2スロットでの(BLANK, n+1)を含むフォークの支持率は、1.32mになる。
balance attackの対策
ハードフォークのテスト
今後予定されている、スケーラビリティを改善するための「sharding」や、現行のEthereumチェーンとEth2 Beacon Chainを結合する「merge」などの大規模なハードフォークを見据えて、ハードフォーク自体のテストをする必要がある。今回のHF1の内容はそれらと比べると変更点が小さく、テストに適したハードフォークとなっている。 cipepser.icon コミュニティ的にはHF1にポジなんですか？
minaminao.icon このHF1の内容はdevs' callでEth2研究者･開発者たちに承認済みなので、その会に出席した人たちはポジだと思います。