V ゴッドが Serenity の設計原則を直接語り、この壮大なプロジェクトの背後にある創意工夫を理解させます。
編集者注: この記事は以下から引用しましたUnitimes(ID:Uni-times)編集者注: この記事は以下から引用しました

Eth1.0 チェーンの設計原則に関するドキュメントについては、以下を参照してください。
https://github.com/ethereum/wiki/wiki/Design-Rationale
副題
静寂の設計原則
▲ シンプルさ: 特に暗号経済 PoS と二次シャーディングは本質的に複雑であるため、プロトコルは意思決定において可能な限りシンプルさを追求する必要があります。これは次のことを行うため、非常に重要です。
(i) 開発コストを最小限に抑える、
(ii) 意図しない安全上の問題のリスクを軽減し、
(iii) プロトコル設計者がパラメータ選択の正当性をユーザーに納得させやすくします。
背景情報については、このリンク [1] に従ってください。特定のレベルの機能を達成したい場合、ある程度の複雑さは避けられません。複雑さの優先レベルは、レイヤ 2 プロトコルの複雑さ > クライアント実装の複雑さ > プロトコル仕様の複雑さです。
▲長期安定性: 理想的には、10 年以上プロトコルを変更する必要がないように下位レベルのプロトコルを構築し、必要なイノベーションを上位レベル (クライアント実装またはレイヤー 2 合意) で実装できるようにする必要があります。 。
▲ 十分性: プロトコル上にできるだけ多くのアプリケーション カテゴリを構築できる必要があります。
▲ライト クライアントの検証可能性: いくつかのセキュリティの前提条件 (例: ネットワーク遅延、攻撃者の予算限界、誠実な検証者が 1/n または少数のみ) を前提として、O© データを検証します (理想的にはビーコン チェーンのみを検証します)。 のクライアントは間接的な保証を取得できる必要があります。 51% 攻撃が発生した場合でも、システム全体のすべてのデータが利用可能で有効であること (注: これは「多層防御」の目標の 1 つです)。
副題
レイヤ 1 とレイヤ 2 の間の妥協点
読者は、私の過去 2 つの記事、「レイヤー 1 は短期的には革新的であるべきだが、長期的にはそれほど革新的ではない」[2] および「サイドチェーン vs プラズマ vs シャーディング [3]」を読むことができます。
どのようなブロックチェーン プロトコルの設計においても、レイヤー 1 (つまりコンセンサス層) により多くの機能を導入することと、より簡潔なレイヤー 1 プロトコルを構築してこれらの機能をレイヤー 2 (つまりアプリケーション) に構築できるようにすることには違いがあります。それぞれにトレードオフがあります。
Layer2 を支持する議論:
コンセンサス層の複雑さを軽減します (上記の「単純さ」を参照)。
プロトコル層を変更する必要性を減らします (上記の「長期安定性」を参照)。
-- 合意に達しないリスクを軽減します。-- プロトコルのガバナンスと政治的リスクに関する作業負荷の軽減
時間の経過とともに柔軟性が向上し、新しいアイデアを実装できるようになります。
Layer1 を支持する議論:
全員に新しいプロトコルへのアップグレードを強制するメカニズム (ハードフォークなど) の欠如によって進行が停滞するリスクを軽減します。
システム全体の複雑さが軽減される可能性があります。
Layer1 が十分に強力でない場合、Layer1 上で必要なパフォーマンスを備えた Layer2 システムを構築することは不可能です (前述の「豊富さ」を参照)
イーサリアム 2.0 の設計は、主にレイヤー 1 とレイヤー 2 の間のバランスを注意深く維持することに重点が置かれています。これには、(i) チューリング完全でステートリッチなコード実行、(ii) データの有効性と計算に関するスケーラビリティ、および (iii) プロトコルの実装にとって重要なブロック確認時間の高速化が含まれます。
(i) を実装しないと、堅牢な信頼モデルを備えたレイヤー 2 アプリケーションを構築することはできません。
(ii) がなければ、スケーラビリティは国家チャネルやプラズマなどのテクノロジーに限定されることになり、資金の拡張とロックアップ、および/または大規模な撤退に課題があります。
(iii) が達成されない場合、チャネル技術を使用せずに高速取引を実行する方法はなく、資金の促進やロック、および/または大規模なエグジットの点で課題があります。
しかし、イーサリアム 2.0 では、(i) プライバシー、(ii) 高水準プログラミング言語、(iii) スケーラブルな状態ストレージ、および (iv) 署名スキームなど、他のいくつかの機能も意図的にレイヤー 2 に残しました。これらの機能はレイヤー 2 に残されます。これは、これらの側面が急速な革新の分野であり、多くの既存のソリューションが異なる特性を持ち、より優れた新しいソリューションを得るには必然的にトレードオフが発生するためです。例えば:
プライバシー: リング署名 + 機密値対 ZK-SNARK および ZK-STARK、ロールアップ対 ZEXE など。
高級プログラミング言語: 宣言型プログラミングと命令型プログラミング、構文、形式的検証機能、型システム、保護機能 (算術式での不純な関数の使用の禁止など)、ネイティブにサポートされるプライバシー機能など。
署名スキーム: Schnorr 署名、BLS 署名、Lamport 署名など。
副題
見る:
https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51
副題
キャスパーを使用する理由
現在のプルーフ オブ ステーク (PoS) コンセンサス アルゴリズムは、主に次の 3 つのグループに分類されます。
サトシ・ナカモトにインスピレーションを得たプルーフ・オブ・ステークアルゴリズム(ピアコイン(ピアコイン)、NXT(フューチャーコイン)、ウロボロス(カルダノのコンセンサスアルゴリズム)、その他の実用的なアルゴリズムなど)
PBFT (Practical Byzantine Fault Tolerance) に触発された Proof-of-Stake アルゴリズム (Tendermint、Casper FFG、Hotstuff など)
CBC Casper (説明は [4] および [5] を参照)
後者の 2 つの陣営では、マージン デポジット (ステーキング) とスラッシュ (ステーキング) を使用するかどうか、またどのように使用するかという問題があります。 3 つのプルーフ オブ ステーク メカニズムはすべてプルーフ オブ ワーク (PoW) よりも優れていますが、この記事ではイーサリアム 2.0 で使用されているアプローチを擁護したいと思います。
斬撃
イーサリアム 2.0 はスラッシュ (デポジット ペナルティ) メカニズムを使用しており、不正行為が検出された検証者は罰せられます。最も軽い罰は誓約額の ~1% を破棄することであり、最も深刻な罰は検証者を破棄することです。預金。
私たちは次の理由から、Slashing メカニズムの使用を擁護します。
攻撃コストの増加: 私たちが確実にしたいのは、PoS チェーンに対する 51% 攻撃は攻撃者に非常に高額な料金 (攻撃からの回復に数億ドル相当など) を費やすことになるということです。これにより、攻撃/防御の計算が攻撃者にとって非常に不利になり、実際に攻撃が逆効果になる可能性があります。
検証者によってもたらされるジレンマを克服する: ノードが「正直な」動作から逸脱し始める最も現実的かつ直接的な方法は、過失です (検証者は検証に参加する必要があるのに検証に参加しない、または署名するときに署名するなど)。署名するべきではありませんなど)。バリデーターによって引き起こされるジレンマについては [6] で詳しく説明されており、ビットコイン SPV マイニング [7] はこれが起こった例であり、非常に深刻な結果につながります。不正なバリデータに対する検証ペナルティは、これらのジレンマを軽減するのに役立ちます。
マスター ノードとバックアップ ノードの両方を持つことが標準になると、攻撃者はブロックチェーン ネットワークを分割し、すべてのバリデーターのマスター ノードとバックアップ ノードに異なるブロックを送信させ、その結果 2 つの競合するゾーンが発生する可能性があります。スラッシュペナルティは、この操作を大幅に抑制するのに役立ち、これが発生するリスクを軽減します。
文章
コンセンサスアルゴリズムの選択
上記の PoS コンセンサス アルゴリズムの 3 つの陣営のうち、後者の 2 つの陣営 (つまり、PBFT と CBC Casper に触発されたコンセンサス アルゴリズム) だけが、これら 2 つのアルゴリズムにおいてファイナリティの概念を持っています。つまり、特定の領域でブロックが確認されます。この方法: 大部分のバリデーター (PBFT にヒントを得たアルゴリズムでは少なくとも 1/3 のバリデーターが必要、CBC Casper アルゴリズムでは少なくとも 1/4 のバリデーターが必要) が不正な動作をした場合にのみ、そのためブロックはスラッシュされた場合にのみ反転されます。
そして最初の陣営、ナカモトにインスピレーションを得た(最長連鎖ルール)コンセンサスアルゴリズムは、この意味で最終性を達成することができません。
Casper FFG を選択したのは、それが決定論を達成する際にプロトコルで使用できる最も単純なアルゴリズムであるという理由だけです。私たちは現在、イーサリアム 2.0 のフェーズ 3 で CBC Casper への切り替えを積極的に検討しています。
副題
シャーディング、あるいはなぜスーパーノードが嫌われるのでしょうか?
レイヤ 1 拡張の場合、シャーディングの主な代替手段の 1 つはスーパーノードを使用することです。スーパーノードでは、ノードが各トランザクションを個別に処理できるように、各コンセンサス ノードに強力なサーバーが必要です。
スーパーノードベースのスケーリングは、実装が簡単なため便利です。これは、より並列化された方法で構築するためにより多くのソフトウェア設計作業が必要になることを除けば、現在の多くのブロックチェーンで採用されているのと同じアプローチです。
以下の主な理由により、このスーパーノードの使用方法は選択しません。
検証プール集中化のリスク: スーパーノードベースのシステムでは、ノードの実行に高額の固定コストが必要となり、参加できるユーザーの数が制限されます。 「ほとんどの PoW および PoS 暗号通貨では、ノードを正常に実行できる 5 ~ 20 個のプール (マイニング プールまたは検証プール) によってコンセンサスが制御されている」と反論する人もいますが、問題は、それが中央集権圧力のリスクを無視していることです。深いポケットのあるプール。バリデーターの実行にかかる固定コストが報酬に比べて非常に高い場合、大規模なバリデーター プールは小さなバリデーター プールよりも低い料金を提供する可能性があり、そのため、これらの小さなバリデーター プールが混雑して統合へのプレッシャーを感じる可能性があります。シャーディング システムでは、より多くの ETH を誓約するバリデーターはより多くのトランザクションを検証する必要があるため、コストは固定されません。
クラウドでの集中化のリスク: スーパーノードベースのシステムでは、ユーザーが自宅でステーキングを行うことが不可能になるため、ほとんどのステーキングはクラウド コンピューティング環境で行われる可能性が高くなります。これにより、単一障害点が発生します。
検閲耐性の軽減: 高い計算量と帯域幅の要件がなければ、ユーザーがコンセンサスに参加することは不可能です。これにより、バリデータの検出と検閲が容易になります。
上で述べたこれらの集中化のリスクは、イーサリアムの超低レイテンシ (1 秒未満) を達成しようとせず、(比較的) 控えめなレイテンシを選択する理由でもあります。イーサリアム 2.0 システムでは、できるだけ少ないまたは多くの ETH を使用し、できるだけ少ないまたはできるだけ多くのコンピューティング能力を使用して参加することができます (ただし、ETH とコンピューティング能力に関して一貫性を保つ必要があります。つまり、少ない計算能力で大量の ETH をステーキングすることはできず、その逆も同様です)、固定コストは最小限に抑えられますが、このコストはステーキングする ETH の量に応じて増加します (一度ステーキングすると、ETH の数が 32,768 ETH を超えると、ほとんどの場合、すべてのシャード チェーンを検証します (注: 合計 1024 のシャード チェーンがあり、各バリデーター ID は 32 ETH をプレッジする必要があるため、1024*32=32,768))。
副題
セキュリティモデル
一般に、ブロックチェーンのセキュリティは、「ほとんどの参加者が正直である」という前提に依存していると考えられています。つまり、参加者の 50% 以上が確立された合意に正直に従い、個人の利益のために反逆の可能性を放棄するということです。
実際、(i) 参加者が「怠け者」でブロックを検証せずに署名する可能性があるため、「参加者の大多数が正直である」という仮定は非現実的です (Validator [9] および Bitcoin SPV マイニングによって引き起こされるフォーク [10] を参照) 、これは非常に一般的な脱北のケースですが、幸いなことに、(ii) ブロックチェーンは通常、独自のセキュリティ特性を維持するために、いくつかのセキュリティ モデルを通過します (参加者の大多数が正直であり続けるとは想定していません)。
共通かつ厳格なセキュリティ モデルは、調整されていない合理的多数派モデル (調整されていない合理的多数派) です。つまり、参加者は自分の利益に従って行動しますが、互いに協力する参加者の数は一定の割合を超えません (単純に言うと、 PoW チェーンでは、この割合は 23.2% です [11])。
もう 1 つのより厳格なセキュリティ モデルは最悪の場合のモデルです。つまり、1 人の参加者がコンピューティング能力または誓約の 50% 以上を制御している場合、このときの問題は次のようになります。
(1) この場合、検証者がチェーン全体を破壊しようとするときに非常に高いコストを支払うことを保証できますか?
(2) 無条件に守ることができる保証は何ですか?
PoS チェーンでは、スラッシュ (デポジットのスラッシュ) により、上記の最初の問題、つまり、攻撃者がチェーン全体を破壊しようとする場合、非常にコストがかかることが保証されます。断片化のないブロックチェーン (現在のイーサリアム 1.0 チェーンなど) では、すべてのブロックを検証する各ノードは、次の 2 つの保証を提供することで、上記の 2 番目の質問の要件を満たします: (i) 最長のチェーンが有効であること、および (ii)最長のチェーンも利用できます (「データ可用性」の重要性の理論的根拠については、このリンク [12] を参照してください)。
イーサリアム 2.0 では、シャーディング (シャーディング) を通じて多層防御を実装します。つまり、ほとんどのバリデーターが正直であり続けるというセキュリティ モデルに基づいて、ランダムに選択されたバリデーター委員会を組み合わせることで、有効性と可用性の保証を実現し、怠惰なバリデーターを防止します。 [9] すべてのデータをダウンロードして検証することなく、無効で使用できないチェーンを検出します。これにより、チェーンが大多数の PoS バリデーターによってサポートされている場合でも、クライアントは無効で使用できないチェーンを拒否できるようになります。
期待されるセキュリティ特性を以下の表に示します。

副題
Casperが設定したインセンティブメカニズム
基本報酬
各エポック (イーサリアム 2.0 では、生成される 64 ブロックごと (約 6.4 分) がエポックと呼ばれます) 中に、各バリデーターは「アテステーション」を実行する必要があります。つまり、チェーン ヘッド (head ) に対して投票と署名を行う必要があります (チェーン ヘッドは上のブロック)。検証者の「証拠」がチェーンヘッダーに含まれている場合、検証者に報酬が与えられます。この報酬は次の 5 つの部分で構成されます。
上部ブロックに「校正」を含めることで報酬が得られます。
正しいエポック チェックポイントを「証明」することに対する報酬 (注: 各エポックの最後のスロットはチェックポイント (チェックポイント) と呼ばれ、スロットはプロトコルによって設定されたブロックを生成するのに必要な時間 (6 秒))。
正しいチェーンヘッド (トップブロック) が識別されたことを「証明」した場合の報酬。
チェーン上にすぐに含まれる「証明」に対する報酬 (「証明」が 1 スロットの後に含まれる場合、検証者は全額の報酬を受け取ります。チェーン上の n スロットの後に含まれる場合、得られる報酬は 1/n になります)すべての報酬のうち);
正しいシャード ブロックが特定されたことを「証明」したことに対する報酬。
それぞれの場合において、実際の報酬は次のように計算されます。 B が基本報酬で、P が目的の「証明」操作を実行するバリデーターの割合である場合、必要な操作を実行するバリデーターには B*P が与えられますが、関連する操作を実行する必要があったバリデーターには B*P が与えられます。これを行わないバリデーターには、-B のペナルティが科せられます。この「集団報酬」メカニズムの目標は、「誰かがより良い行動をとれば、全員がより良い行動をする」ことであり、それによって破壊行為の要因を制限します。 (破壊行為の要因とその制限が重要である理由の説明については、この記事 [13] を参照してください)
上記のポイント 4 は例外であることに注意してください。この報酬は、バリデーターの行動ではなく、採用される「証明」の遅延によって決まり、罰せられるリスクはありません。
基本報酬 B 自体は次のように計算されます。ここで、D1...Dn はバリデーターのデポジットのサイズ、k は定数です。これは、(i) 固定報酬率の設定、つまり k*Di と、(ii) 固定の合計報酬の設定、つまり k*Di の 2 つの一般的なパターンの間の妥協点です。
(i) に対する主な議論は、このモデルがネットワークに 2 つの不確実性をもたらすということです。1 つは発行されたコインの総量が不確実で、もう 1 つは参加しているプレッジの総数が不確実であることです (なぜなら、固定報酬率が低すぎる場合、基本的にはノーです)。 1 人が参加することになり、ネットワーク全体が脅かされます。また、固定報酬率が高すぎると、参加する人が多すぎて、コインの流通量が予想外に多くなります)。
(ii) に対する主な議論は、このモデルではネットワークが「妨害攻撃」に対してより脆弱になるということです。詳細については [13] を参照してください。
ブロック提案者には、ブロックに「証明」を含めることで基本報酬の 1/8 が与えられます。これは、ブロック提案者ができる限り情報を聞き、できるだけ多くの情報を受け入れるように促すためです。
オンラインでの損益分岐点の時間
文章
(i) 役割を果たすオンライン検証者と、(ii) オフライン検証者という 2 種類の検証者がいると仮定します。前者のタイプの検証者が部分的に P で、基本報酬が B である場合、オンライン検証者は次の報酬を受け取ることが期待されます。報酬は: 上記の 1 番目、2 番目、3 番目、および 5 番目のケースの報酬 B*4P + 7/8*B*(P+(P*(1-P))/2+(P *(1-P)^2) /3+...) (バリデーターが存在しないため、「証明」がチェーン ヘッダーに含まれるのが遅れる可能性があるため) + ブロック提案者報酬 1/8*B*P 。検証者が欠席した場合(つまり、検証に参加しているはずなのに実際には検証しなかった場合)は、B*4 によって罰せられます。したがって、他のすべての検証者がオンラインの場合、検証者はオンラインの場合は B*5 の報酬を与えられ、オフラインの場合は B*4 のペナルティを課せられるため、検証者が ≥4/(4+5) ≈ 44.44% の間オンラインである場合、検証者は損益分岐点(損益分岐点)ができるようになります。 P=2/3 (つまり、オンライン検証者が全検証者の 2/3 を占める) の場合、オンラインであることに対する検証者の報酬は ≈B*(2/3*4.125+7/8*0.81 )≈B となります。 *3.46、またはオンライン時間が 53.6% 以上であるため、支払い残高に達します。
Inacivity leak
ただし、P が 2/3 より低い場合 (つまり、オンライン検証者の数が全体の 2/3 未満である場合)、オフライン検証者は「非アクティブ リーク」と呼ばれるペナルティを受けます。
イーサリアム 2.0 チェーンが 4 エポックを超えてファイナリティを達成できなかった場合、可能な最大報酬がゼロになるように追加のペナルティが追加されます (操作を正しく実行できなかった検証者にはペナルティが課せられます)。また、2 番目のペナルティが追加されます。ファイナリティを達成できなかったエポックの数に応じて比例的に増加します。これは、バリデーターの 1/3 以上がオフラインになった場合に、これらのオフラインのバリデーターがより厳しく罰せられるようにするためであり、このペナルティは時間の経過とともに指数関数的に増加します。
これには次の 3 つの効果があります。
オフラインのバリデーターは、現時点ではバリデーターのオフラインによって実際にブロックのファイナライズが妨げられるため、より厳しいペナルティが課せられます。
「反相関ペナルティ」の目標を達成します(以下で詳しく説明します)。
1/3 を超えるバリデーターが同時にオフラインになった場合、最終的にオンラインになるバリデーターの数が全体の 2/3 に回復することを確認してください。これは、オフラインのバリデーターのデポジットが減少すると、オフラインのバリデーターがシステムから追放されるためです。バリデーターのランク。
これは、バリデーターの 50% がオフラインの場合、ブロックは 21 日後に再び完了することを意味します。これは、21 日後には、すべてのオフラインのバリデーターがデポジットの 50% (16 ETH) を失い、バリデーターのデポジットが以下の場合に発生するためです。 16 ETH を超えると、彼はバリデーターのランクから追放されます。
文章
スラッシュと反相関ペナルティ
バリデーターが Casper FFG のスラッシュ条件に違反したことが判明した場合、そのバリデーターはペナルティを受けることになります (賭け金の一部を失う); 他のバリデーターがほぼ同時期にスラッシュされた場合 (具体的には、検証者が罰せられる 18 日前からその期間まで)検証者が検証者を終了した場合)、ペナルティは前のペナルティの 3 倍になります。これにはいくつかの目的があります。
バリデーターが他の多くのバリデーターと同時に不正行為を行った場合にのみ、バリデーターの動作がネットワークに実際の損害を与える可能性があるため、この場合のペナルティはより厳しくなります。
これにより、実際の攻撃には重くペナルティが課せられますが、悪意がない可能性のある個々のミスに対しては非常に軽いペナルティが課せられます。
これにより、誰もがバリデーターの最大のプールに参加することができなくなります。
BLS署名
文章
BLS 署名は集約に適しているため、BLS 署名を使用します。メッセージ M はキー k1 と k2 (対応する公開キー K1=G*k1、K2=G*k2、G は楕円曲線の基点) によって処理されます。の任意の 2 つの署名 S1 と S2 は、単純に楕円曲線点の加算 (S1+S2) によって集約できます。これにより、何千もの署名を生成でき、それぞれの限界コストは 1 データ ビット (集合署名内の特定の公開鍵の存在を示すため) と 1 回の楕円曲線加算の計算です。
当社は、バリデーターの住宅ローンメッセージの署名を所有権の証明として使用します。これには、署名キーや引き出しキーなどの他の重要な情報が指定されます。
副題
検証者のランダムな選択<- hash(seed,ランダム性を実現するために使用されるシードは、ブロック提案者が明らかにする必要がある値 (つまり、シード) を「混合」することによって実現されます。
new_data)) はブロックごとに更新されます。エスクロープルーフのサブキーと同様に、検証者の値は検証者が誓約を行った直後に決定され、第三者がサブキーを計算することはできませんが、リソースによってサブキーが公開されたときにそれを検証します(この仕組みはランダオと呼ばれることもあります)。
将来的には、VDF (Verifiable Delay Functions) を使用して、操作に対するランダムネス シードの堅牢性をさらに高める予定です。
文章
シャッフルバリデーター
各エポック中に、スワップオアノットシャッフル [13] を使用してバリデータをシャッフルし、責任を割り当てます。このアルゴリズムにより、次のことが保証されます。
シャッフルは順列であるため、各バリデーターは各エポック中に長期委員会のメンバーとして任命されます。
文章
架橋委員会
各エポック中に、各シャードはクロスリンク (クロスリンク) を実行します、つまり、シャード委員会からバリデーターの 2/3 をランダムに選択します (各シャード委員会の認証者の数は約 128 です)。最後のクロスリンクが署名されてからシャード内に保存されます (シャード内のクロスリンクが失敗する可能性があるため、ハッシュは最大でも最初の 64 エポックのデータを表すことができます。シャード内に連続したエポックが多数ある場合、最初のクロスリンクが失敗すると、ハッシュは最初のクロスリンクが失敗する可能性があります)。追いつくにはクロスリンクが複数回成功する必要があります)。
シャード委員会あたりのバリデーターの数は 128 に設定されています。これは、攻撃者が全バリデーターの 1/3 未満を制御しながら誤って委員会メンバーの 2/3 を制御することを防ぐための最小数であるためです。二項定理により、次の可能性があります。委員会メンバーの 2/3 を支配する攻撃者は 5.55*10^(-15)
各エポック (64 ブロック、約 6.4 分) ごとに、ビーコン チェーンは各シャード チェーンのシャード委員会を再編成します (つまり、バリデーターを中断します)。高速スクランブルバリデータの目的は、攻撃者がシャードチェーンを攻撃したい場合に、攻撃者がシャード委員会を迅速に破壊する (制御を奪う) 必要があることを保証することです。
文章
長期委員会
システムは約 27 時間ごとに、シャード チェーンごとに永続委員会を選択します。いつでも、イーサリアム 2.0 システムのすべてのバリデーターは、これらの長期委員会のいずれかのメンバーになります。長期委員会はシャード ブロックの提案を担当し、ユーザーにシャード ブロックに関するある程度の保証を提供します (シャード ブロックがクロスリンクに含まれるまで)。ライト クライアントは長期委員会に頼ることができます。 P2P ネットワークの安定性とライト クライアントの効率を維持するため、長期的な委員会の変更は比較的まれです (シャード委員会は約 6 分ごとに変更されます)。
ネットワークの安定性をさらに維持するために、すべてのバリデーターが同時に n 期間の長期委員会から n+1 期間の長期委員会にローテーションされるのではなく、各バリデーターのローテーションが行われます。 validator は、一定期間内のランダムな時点での次の Rotate まで遅延されます。
副題
LMD GHOST フォークの選択ルール
LMD GHOST フォーク選択ルールは、すべてのバリデーターからの情報を組み合わせて、通常の状況ではどのブロックも元に戻せないことを保証します。このフォーク選択ルールはすべてのバリデーターに依存しているため、攻撃者がバリデーターの 50% 以上を制御しない限り、ブロックを元に戻すことはできません。この場合、攻撃者はランダム性を操作して多くの利益を得ることができません。
副題
ビーコンチェーン/シャードチェーンの構造
イーサリアム 2.0 シャーディング システムの構造は、すべてのアクティビティを調整する中心的な「ビーコン チェーン」と 1024 のシャード チェーンで構成されます。各シャード チェーンは、クロスリンクを介してビーコン チェーンに定期的に接続されます。
このシャーディング構造の代替案:
(1) 委員会を通じてシャード ブロックに署名し、すべてのシャード ブロックをビーコン チェーンに直接入れます。
(2) ビーコン チェーンはありませんが、すべてのシャード チェーンは特定の構造を介して接続されています。
上記(1)の構造を放棄した理由は、シャードチェーンブロックに6秒の時間(スロット)を設定することが望ましいが、ビーコンチェーン上で6秒ごとに1024回のクロスリンクを実行すると、チェーンが破損してしまうためです。非常に高い負荷がかかります。
控訴の(2)の構造を放棄した理由は、ハブアンドスポークのビーコンチェーン構造が、どのような複雑な構造よりも実装および理解が容易であるためです。
シャードチェーンのデザイン
各シャードは半独立したチェーンであり、クロスリンクされた集合ブロックよりも高速にブロックを処理できます (目標 3 ~ 6 秒)。これにより、トランザクションは、ビーコン チェーンによって (クロスリンクによって) 確認される前に、シャードの長期委員会を通じてある程度の確認を迅速に得ることができます。
シャード チェーンの構造は、各ブロックがシャード委員会の各検証者によって証明されるようになっているため、検証が簡単になり、シャード ブロックのかなり高度な確認が保証されます。より低い値を扱う大部分のアプリケーションでは、単一の確認を信頼できる必要があります。
各エポックの開始時に、各シャード ブロックにはその親ブロックへのポインターとビーコン ブロックへのポインターが含まれます。ビーコン チェーンとシャード チェーン間のこの半密結合は、(i) シャード チェーンがその長期委員会に関する情報を確実に認識できるようにするためです (この情報はシャード チェーンによって生成されるため、ブロックはどのチェーンを決定するための実行可能な方法です)正規のビーコン チェーンです。
シャード チェーンの状態 (報酬、ペナルティ、履歴アキュムレーター) は、不正行為の証明で必要な場合にシャード チェーンの状態をビーコン チェーンに完全に配置できるようにするために、意図的にブロック サイズよりも小さくなるように設計されています (ただし、これは単にこの制限はフェーズ 2 で緩和され、個々の実行環境の状態はこのサイズによって制限されますが、すべての状態を組み合わせると非常に大きくなるため、不正行為の証明にはマークル証明が必要になります)。
クロスリンクされたデータ
クロスリンクには、最後のクロスリンク以降のシャード内のすべてのシャード ブロックを含むデータ構造のマークル ルートである data_root が含まれます。このクロスリンク データ構造 + ルートには複数のターゲットがあります。
どれが正規のシャード チェーン ブロックであるかをビーコン チェーンに知らせます。
不正行為の証拠を評価できる単純なバイト配列を作成します。
副題
バリデータのライフサイクル
誓約
検証者はトランザクションを送信することで ETH プレッジを実行し (このトランザクションは Eth1.0 チェーンにデプロイされたデポジット コントラクトの関数を呼び出します)、最後に Eth2.0 チェーンにプレッジ メソッドを追加します。検証者によるこのアクションにより、次のことが明確になります。
メッセージの署名に使用される秘密鍵に対応する公開鍵。
出金資格情報 (つまり、検証者が検証を完了したときに資金を引き出すために使用される公開鍵ハッシュ)
誓約金額
これらの値はすべて署名キーによって署名されます。署名キーを引き出しキーから分離する目的は、リスクの高い引き出しキーをより安全にすることであり (引き出しキーはオフラインであり、どの質権プールとも共有されません)、署名キーはメッセージに署名するために使用されます。各時代の間に。
預金契約は、すべての誓約のマークル ルートを保持します。バリデーターによって誓約されたマークルルートが (Eth1.0 データ投票メカニズムを介して) Eth2.0 チェーンに含まれると、Eth2.0 ブロックの提案者は誓約のマークル証明を提出し、誓約プロセスを開始できます。
アクティベーション
検証者がトランザクションを住宅ローン契約に送信すると、トランザクションは検証者登録テーブルにすぐに追加されますが、検証者は最初は非アクティブです。バリデーターは少なくとも 4 エポック後にのみアクティブ化されます。バリデーターが少なくとも 4 エポック (エポックあたり約 6.4 分) 待機する必要がある理由は、RANDAO が操作されないことを保証するためであり、多くのバリデーターが同時に参加した場合に発生します。つまり、N は 4 を超える可能性があります。
Eth2.0 内の既存の検証者の総数が |V| の場合、各エポック中に追加できる検証者の最大数は max(4, |V|/65536) になります。より多くの検証者が参加を希望する場合は、キューに入れる必要がありますが、システムは可能な限り高速に処理します。
やめる
バリデーターが Eth2.0 システムから撤退する場合 (自発的な終了メッセージの投稿またはスラッシュによる終了のいずれであっても)、バリデーターもシステムから撤退するためにキューに並ぶ必要があります。は、上で説明したように追加できる新しいバリデーターの最大数と同じです。
この新しい参加/終了キュー制限の理由は、システム内のバリデーターの総数が 2 つの時点の間で急激に変化しないようにするためです。これにより、バリデーターが十分な頻度でログインする限り (バリデーターの合計数が番号 ≥ 262144 の場合、検証者は 1 ~ 2 か月に 1 回ログインできることが保証されます)、イーサリアムの古いチェーンと新しいチェーンの間に確実性があることを保証できます。関連する原則については、[17] および [18] を参照してください。
お金を引き出す
バリデーターがキューを正常に抜け出すと、出金が可能になるまで約 27 時間の待機時間がかかります。この待機時間にはいくつかの影響があります。
これにより、バリデーターが不正な動作をした場合に、その不正な動作を捕捉してバリデーターをスラッシュする時間が確保されます。
これにより、システムにシャード報酬の最後の期間をそのバリデーターに配布する時間が与えられます。
これにより、Proof of Escrow へのチャレンジを開始する時間が与えられます。
フェーズ 0 では、バリデーターが「引き出し」を希望しても実際にはそうすることはできませんが、後のフェーズでは、バリデーターが引き出した資金を実行環境に転送できるようになります。
効果的なバランス
バリデーターの残高に基づくほとんどの計算では、バリデーターの「実効残高 (EB)」が使用されますが、唯一の例外は、バリデーターの残高を増減する計算です。検証者の残高 B が EB 未満、または EB+1.5 より高い場合に限り、EB が Floor(B) と等しくなるように調整されます。これは、有効残高があまり頻繁に変更されないようにし、各エポック中に状態を再計算するために必要なハッシュの量を減らすためです。平均して、更新する必要があるのは残高だけであり、各バリデーターが有効残高を更新する必要がある量は比較的少なくなります。
副題
フォーク機構
フォーク データ構造には、(i) 現在の「フォーク ID」、(ii) 以前の「フォーク ID」、および (iii) 2 つのフォークを切り替えたスロットが含まれています。現在のブロック高さのフォーク ID は、すべてのメッセージの有効な署名に影響を与えるため、あるフォーク ID で署名されたメッセージは、他のフォーク ID を使用した検証関数では無効になります。
フォークは、「フォーク スロット」に状態遷移を追加することで実行できます。署名検証機能は、メッセージが存在するスロットのフォーク ID を使用してメッセージを検証します。このフォーク ID は、以前のフォーク ID または現在のフォーク ID である可能性があります。
フォークに参加したくないユーザーがいる場合は、フォーク スロットのフォーク ID を変更しなかったチェーンに留まるだけです。両方のチェーンは引き続き存在でき、バリデーターはペナルティなしで両方のチェーンを自由に検証できます。
備考: 翻訳は削除されました
[1]:https://radicalxchange.org/blog/posts/2018-11-26-4m9b8b/
[2]:https://vitalik.ca/general/2018/08/26/layer_1.html
[3]:https://vitalik.ca/general/2019/06/12/plasma_vs_sharding.html
[4]:https://vitalik.ca/general/2018/12/05/cbc_casper.html
[5]:https://medium.com/@aditya.asgaonkar/casper-cbc-simplified-2370922f9aa6
[6]:https://eprint.iacr.org/2015/702.pdf
[7]:https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa
[8]:https://twitter.com/VitalikButerin/status/1145576103089602560
[9]:https://eprint.iacr.org/2015/702.pdf
[10]:https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa
[11]:https://arxiv.org/abs/1507.06183
[12]:https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
[13]:https://ethresear.ch/t/censorship-detectors-via-99-fault-tolerant-consensus/2878
[14]:https://github.com/ethereum/research/raw/master/papers/discouragement/discouragement.pdf
[15]:https://link.springer.com/content/pdf/10.1007%2F978-3-642-32009-5_1.pdf
[16]:https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_fork-choice.md
[17]:https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942
[18]:https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187


