ETH2.0 が登場しますが、Casper をまだ知りませんか? （二）
存在する存在するVitalik のオリジナル論文で Casper FFG を紹介しました。これは PoS を使用して PoW によって生成されたブロックを確認し、システムのセキュリティを向上させますが、これは単なる過渡的な解決策であり、純粋な PoS はイーサリアム 2.0 の Casper プロトコルで使用されます。 , この記事では、イーサリアム2.0で使用されるCasperプロトコルについて紹介します。
副題
まず、イーサリアム 2.0 のアーキテクチャがどのようなものかを見てみましょう. 図 1 に示すように、イーサリアム 2.0 には、PoS Casper を通じて生成されるビーコン チェーンと呼ばれるメイン チェーンが存在します。ビーコン チェーンの下には 1024 のシャードがあり、各シャードは独立してデータを処理できます。
画像の説明
図 1 イーサリアム 2.0 のアーキテクチャ
図1からわかるように、イーサリアム2.0とイーサリアム1.0は2つのチェーンとなり、2.0シャード実現後も1.0はイーサリアム2.0のシャードとして動作し続けます。前回の記事で、ステークを抵当にすることでPoSコンセンサスに参加するバリデーターになれることを紹介しましたが、イーサリアム2.0へスムーズに移行するために、イーサリアム1.0のステークを抵当に入れてイーサリアム2.0のバリデーターになる方法をCasper An氏が解説します。対処する必要がある重要な問題。
バリデーターになるには、ユーザーはまずイーサリアム 1.0 の特別な契約にトランザクションを送信して、一定量の ETH (現在の最小値は 32ETH) を担保にする必要があります。その後、ユーザーはトランザクションの証明を取得します。図 2 に示すように、この証明をイーサリアム 2.0 に示すことにより、ユーザーは検証に合格した後にバリデーターになります。画像の説明
図 2 イーサリアム 1.0 での ETH の抵当がイーサリアム 2.0 の検証プロセスになるユーザーの住宅ローン取引の正確性を検証するために、イーサリアム 2.0 は現在のイーサリアム 1.0 のブロック情報と、住宅ローン契約の現在のすべての取引で構成されるマークルのルート ハッシュを保存する必要があります。完全なマークル ツリーの証明により、通貨取引の正当性を検証できます。検証されたユーザーはイーサリアム 2.0 のバリデーターになります。
副題
Ethereum 2.0におけるCapserのブロック生成プロセス
前回の記事では、Casper が PoW を通じてブロックを生成し、PoS を使用してブロックを完成させることを紹介しました。したがって、純粋な PoS Casper にとって解決する必要がある問題は、ブロックをどのように生成するかということです。プロトコル プロセスを正式に導入する前に、いくつかの定義を明確にしましょう。
バリデーターのコレクション: V = V1 ... Vn、各バリデーターが同じステークを持っていると仮定します。
スロット: 基本的な時間単位。現在 6 秒に設定されています。
エポック: 64 スロットがエポックを形成します。
画像の説明
図 3 イーサリアム 2.0 の Casper コンセンサスプロセス
1. 各エポックの開始時に、乱数発生器によって乱数が生成され、検証セット V が平均 64 の部分に分割されて、S1、S2、...、S64 が得られます。
2. エポックでは、各スロット i は、ステップ 1 で生成された乱数に従って候補ブロックを提出するための Si のバリデーターを選択し、候補ブロックを提出するバリデーターをスロット i に提案者_i として書き込み、提出された候補ブロックを B_i に書き込みます。 。
3. 各スロット i について、proposer_i を除く Si の残りの検証者が B_i に投票し、その投票が証明書として書き込まれます。5. 各スロット i について、スロット i のブロック (B_i) を受信した後、または 3 秒待機した後、proposer_i を除く Si の残りのバリデーターは、現在のチェーンの先頭を自分のビューに公開します。
LMD GHOST（Lastest Message Driven GHOST）
副題
この新しい最適チェーン選択アルゴリズムを紹介する前に、イーサリアム 1.0 - GHOST の最適チェーン選択アルゴリズムを思い出してください。 GHOST アルゴリズムの主なアイデアは、ブロックチェーンの場合、時間遅延と悪意のあるノードの存在により多くのフォークが生成され、フォークが見つかったときにサブツリーの合計難易度の最大値が最適なチェーンとして選択されるというものです。図 4 に示すように、
画像の説明
図4 GHOSTプロトコル
PoW プロトコルの GHOST プロトコルには問題はありませんが、PoS プロトコルは当然ながら Lang Range 攻撃の影響を受けます。つまり、攻撃者は少量の資金を使って、かつて多額の株式を保有していたアカウントを購入することができます。しかし、現在は空であるため、過去に戻って過去の位置でトランザクションを実行すると、フォークによって不正なブロックが大量に生成され、GHOST プロトコルはシステムのセキュリティを保証できなくなります。図 5 に示すように:画像の説明
図 5: ラング範囲
攻撃者は過去の位置に黄色のブロックを生成します。サブツリー B の合計難易度は 10 で、紫色のブロックが最適チェーン上の点になります。投票前にトークンを抵当に入れる必要がありますが、自分のトークンを償還した後、攻撃者はトークンが没収されることを心配することなく、バリデーター時代に無謀に行動できます。
したがって、この問題を解決するために、イーサリアム 2.0 は新しいアルゴリズム、LMD GHOST (Lastest Message Driven GHOST) を設計しました。 LMD GHOST の主なアイデアは、フォークのあるチェーンの場合、チェーンの先頭を見つける過程でフォーク ポイントに遭遇したときに、現在のエポックでより多くのバリデーターをサポートするサブツリーを選択することです。契約の主なプロセスは次のとおりです。
フォーク付きチェーンの場合:
2、M=[M1,…,1. H は作成ブロックに等しい。
Mn] は Validator からの最新ニュースです。
3. M で最も多くのサポートを持つ子ノードを選択し、それを H に設定します。
4. 子ノードがなくなるまで手順 (2 ～ 3) を繰り返します。
ここまでイーサリアム 2.0 の Casper がどのようにブロックを生成するかを紹介しましたが、次は候補ブロックを最終的に決定する方法です。
副題
ブロック確認
前回の記事では、正当化チェックポイントと確定チェックポイントについて説明しましたが、確定チェックポイントより前のノードが最終的に確定します。一言で言えば、イーサリアム 2.0 の Casper は各エポックをチェックポイントと見なし、チェックポイントの正当化および最終化ステータスを決定するためにチェックポイントに認証投票を行います。正当化および最終化を決定するコア ロジックは、上記で説明したものと似ています。次に、ブロックがどのようにして両端揃え状態と確定状態になるかを説明します。
ブロックを正当化する方法Casper はエポックを 64 個のスロットに分割し、最後のスロットを epoch_boundary_slot と呼び、そのハッシュを epoch_boundary_hash としてエポックを表し、エポックをチェックポイントとみなします。チェーンにマップを維持させます。これを justified_hashes と呼びます。ストレージ形式は次のとおりです。
。構成証明にlatest_justified_hashが含まれている場合にのみ、2つのフィールドepoch_boundary_hash（前のエポックの最小スロットを持つブロックのハッシュ）とlatest_justified_hash（epoch_boundary_hashによって参照されるjustified_hashエポックの最新ブロックのハッシュ）を検証器の構成証明に追加します。 justified_hashes のスロットと等しい 最新のハッシュを使用する場合にのみ、この証明書は正当です。チェーンは最新の正当化されたハッシュを追跡するため、同じepoch_boundary_hashを選択すると、同じlatest_justified_hashに投票します。次に、エポック境界中に状態がどのように遷移するかを見てみましょう。チェーンについて、最後の 4 つのエポックの epoch_boundary_block B1、B2、B3、B4 を仮定します。ここで、B4 はエポックの最新の epoch_boundary_block であり、それらのスロットは B1_slot、B2_slot、B3_slot、B4_slot、B3_slot = B4_slot - 64、と書かれています。等バリデーターの 2/3 以上が epoch_boundary_block として B4 を選択した場合、次のようにします。
justified_hashes を追加しました。
epoch_boundary_block が正当化される条件は、バリデータの 2/3 以上が構成証明 epoch_boundary_hash でそのブロックを指していることです。ブロックが justified_hashes に含まれている場合、ブロックは正当化され、ブロックがすでに正当化されていることを証明する状態になります。 justified はチェーン上位に記録されます。
ブロックを完成させる方法
位置調整された状態を確認した後の次のステップは、ブロックをファイナライズ状態に移行させる方法を決定することです。
B4 と B3 が justified_hashes にある場合、epoch_boundary_block として B4 に投票した証明は、B3 をlatest_justified_hash として選択し、B3 を確定します。
B4、B3、および B2 が justified_hashes にある場合、epoch_boundary_block の証明として B4 に投票し、latest_justified_hash として B2 を選択し、B2 を確定します。
B3、B2、および B1 が justified_hashes にある場合、epoch_boundary_block の証明として B3 に投票し、latest_justified_hash として B1 を選択し、B1 を確定します。とすると、epoch_boundary_blockをh(t)、latest_justified_hashをh(s)とみなすと、ブロックの確認処理が理解しやすくなります。
副題
その他の小さなこと
Casper を完全に動作させるためには、まだ解決しなければならない小さなことがいくつかありますが、スペースが比較的短いので、まとめてみましょう。
ペナルティ条件
Noting at Stake 攻撃を防ぐために、ユーザーは PoS の Validator になるためのトークンを抵当に入れます。Validator が違法に動作する場合、悪者による悪行を防ぐために、抵当に入れられたトークンは没収されます。バリデーターのペナルティ条件は次のとおりです。
1. 同じバリデーターは、同じエポック内で 2 つの異なる証明書を発行することはできません。 2. 同じ Validator が 2 つの証明書を発行することはできません。それらの epoch_boundary_block はそれぞれ t1 と t2、latest_justified_hash は s1 と s2、および s1
このペナルティ条件は前回の記事のペナルティ条件と同じです。
バリデータの交換条件
dynasty(B) は、ブロック B からジェネシス ブロックまでの確定されたエポックの数を示します。 1/64 バリデーターは 2 つの王朝間で交換できます。
フォーク選定条件
最後にファイナライズされたブロックから順に LMD GHOST を実行します。
