誰もが理解できる「イーサリアム2.0フラグメンテーション設計」
編集者注: この記事は以下から引用しました炭素鎖値(ID:cc-value)編集者注: この記事は以下から引用しました
炭素鎖値(ID:cc-value)
炭素鎖値(ID:cc-value)
セブンイレブンで朝食を買うとき、レジが1人だとレジの長蛇の列に並ばないといけない、レジが2人だとすぐに2倍になる、レジが4人だとレジがないかもしれない並ぶ必要がある。これは、1 人の作業を複数の人に分散して効率を向上させるシャーディングの基本ロジックです。
イーサリアムの分散台帳の観点から見ると、シャーディング前はメインチェーンの台帳のみが存在し、1秒あたり約12～45件のトランザクションを処理でき、トランザクション量がこのデータより大きい場合はキューに入れる必要があります。シャーディングとは、1 つの台帳を 64 台の台帳に変換し、同時にトランザクションを処理させることであり、これは、セブンイレブンで 64 台のレジを開いて現金を受け取ることに相当します。
シャーディングのロジックは単純ですが、実装がこれほど難しいのはなぜでしょうか?台帳を 64 個の台帳に分割すると、多くの新たな問題に直面することになるため、シャーディング テクノロジが行う必要があるのは、それらを解決することです。この記事では、イーサリアム 2.0 のシャーディングとは何なのかを知るために、これらの質問から始めます。
副題
断片化する方法
1. トランザクションをシャードに割り当てる
シャードには、トランザクションと、トランザクションをブロックにパッケージ化するバリデーターが含まれています。シャードを完成させる最初のステップは、トランザクションとバリデーターをシャードに割り当てる方法を決定することです。まず割り当てトランザクションを見てみましょう。
3 つの村の話で理解してみましょう。漁村、狩猟村、農民村があり、村内や村間で頻繁に取引が行われますが、通貨はなく、誰もが口座を持っています。以前は 3 つの村の会計を 1 つの帳簿で管理していたため、少し遅かったのですが、現在は 3 つの会計帳に変更されており、どの会計をどの帳簿で管理しているのでしょうか。
台帳を3つ置き、取引が来てその前に行列がなければどの台帳に記録するという方法もありますが、そうすると各台帳に所有者のアカウント情報がないといけないという問題が発生します。私は列に並ぶためにあなたのところに行きますが、あなたは私のアカウントを持っていません。
このため、このシャーディング方法の主な問題の 1 つは、単一の台帳に保存されるデータの量を削減できないことです。このストレージ要件は、簿記に参加したいノードにとっては高いしきい値です。この方法では、次のことも必要です。一人の人が同じお金を同時に異なるシャードで使えるため、二重支出の問題を解決します。
もう一つの方法は、漁村に一つの台帳、オリオンの村に一つの台帳、農村に一つの台帳を持ち、その台帳には自分の村の口座情報のみを記載し、自分の村内での取引のみを記録する方法です。このようにして、3 つの台帳を同時に管理することができ、簿記効率が高く、保管要件が少なくなります。これはまさにイーサリアムで採用されているシャーディング方法です。ステート シャーディングです。各シャードは、自身のシャードに属するアカウント ステータスのみを保存します。実装に関しては、自然村によるシャーディングではなく、イーサリアムのユーザーがどのシャードに参加するかを選択します。
ステートシャーディングの最大の問題は、漁村の人々がオリオン村の人々と取引したい場合はどうなるかということです。漁村の台帳にはオリオンの村人の記載はなく、オリオン村の台帳にも漁師の記載はありません。実際、これはシャーディング テクノロジー、シャード間通信が直面する最大のテストです。この問題が完全に解決されると、イーサリアム 2.0 が使用できるようになります。この記事のパート II では、この問題に対するいくつかの解決策について説明します。
2. バリデーターをシャードに割り当てる
トランザクションを異なるシャードに配置した後、次に解決すべき問題は、簿記担当者をシャードに割り当てる方法、つまり検証者を割り当てる方法です。
イーサリアムには 64 個のシャードがあり、各シャードには 128 個の検証者がいます。シャードの検証者が固定または予測可能な場合、攻撃者はシャードを制御します。つまり、128 個の 2/3 を 1 つ購入するのは簡単です。 ?イーサリアムの解決策は、すべてのバリデーターからシャードのバリデーターをランダムに選択し、6.4 分 (1 エポックの長さ) ごとにバリデーターを変更することです。このように、攻撃者がシャード内のユーザーの 2/3 を制御できる確率は 1 兆分の 1 未満です (推論については参考資料 1 を参照)。
ビーコン チェーンの主なタスクの 1 つは、シャード チェーンに検証者を割り当てることであり、この作業で最も重要なことはランダム性の実現です。 1 つ目はランダム性の重要性、検証者をランダムに割り当てられないと台帳の安全性が保証できない、2 つ目はランダム性の難しさ、ブロックチェーン上でランダム性を実現するのは非常に難しい、ということが今のところ考えられます。実際にエンジニアリング実装と呼べる、実証済みのランダム アルゴリズムは存在しません。
イーサリアムの解決策は、RANDAO+VDF を使用して乱数を提供し、ランダム性を実現することです。 RANDAOをRAN（ランダム）とDAOに分解すると分かりやすいですが、グループ内の各人が独自に乱数を提案し、全員の乱数を組み合わせて最後に使用した乱数を生成することを意味します。他人が提供する数字を知ることは誰にも難しいため、最終的に組み合わされる数字を予測することも困難です。
ただし、RANDAO モデルには欠陥があります。つまり、最後の数字を提供した人には不正行為を行う機会があります。その人は、前のすべての人が提供した乱数の合計を知っており、自分で提供した数字を調整できます。最終的な結果を自分にとって有益なものにするためです。
この問題を解決するために、イーサリアムは VDF (Verifiable Delay Function) を導入しました。その機能は非常に単純で、最後に乱数を提供した人が、自分自身で乱数を提供する前に、それまでのすべての人の乱数の合計を計算することを防ぐことです。したがって、乱数を操作する方法はありません。 (RANDAO+VDF の詳しい紹介は参考資料 2 を参照)
3. シャードはリレーラーによって保存されます
回転台帳の検証者が新たな問題を引き起こすことに気づいたかどうかはわかりません。検証者はしばらく漁村に配属されて帳簿を保持し、しばらくの間オリオン村に配属されることになります。すべてのアカウント情報を手元に持っていない場合、アカウントをどのように保管すればよいですか?すべてのアカウント情報を持っている場合、彼は状態シャーディングなしで完全な台帳を再び保持していることになります。
この問題を解決するために、イーサリアムはステートレス クライアントという重要な新しい設計を提案しました。簡略化して理解すると、漁村の台帳は漁村に、オリオン村の台帳はオリオン村に置かれ、検証者は台帳を持たず、異なる村を走り回って検証するだけの役割を果たします。アカウントを保持します。
それでは、誰がさまざまな村の帳簿を保管するのでしょうか?イーサリアムは、さまざまなシャードのアカウント ステータスを保存する責任を負い、特定のシャードのみを提供できるリレーラー (ステータス プロバイダー) の役割を導入しました。リレーラーの仕事は理解するのが簡単ですが、サービスの料金をどのように支払うか、リレーラーの誠実さをどのように保証するか...これらの関連メカニズムの設計は、解決する必要がある新たな問題であり、コミュニティのガバナンスの問題でもあります。メンバーは議論に参加する必要があります。
ただし、トランザクションの開始後にトランザクションを証明できるように、各ユーザーにすべての古いアカウントを保存するよう要求することはできません。現時点では、シャードのすべてのアカウント ステータスを保存する「リレー」が必要です。ユーザーが要求を提起すると、ユーザーが取引の証人データを検証者に提供するのに役立ちます。
Vitalik Buterin は 3 月 11 日にステート ルートを多項式コミットメントに置き換えることを提案する記事を公開しました。このテクノロジーはここで使用されています。ゼロ知識証明法を使用してトランザクションの証明を提供します。これは、次の計算結果を提供すると理解できます。この方法では、関連するすべてのデータを検証のために検証者に直接提供するのではなく、証人データのサイズを大幅に削減し、さまざまなオーバーヘッドを効果的に削減できます。 (Vitalik の新しいメソッドの詳細については、参考資料 3 を参照してください。ステートレス クライアントの詳細については、参考資料 4 を参照してください。)
この時点で、台帳を複数の台帳に分割する、つまりシャードに分割する作業が完了します。
副題
シャード間のトランザクション
漁村の人々は漁村の人々とのみ取引し、オリオン村の人々はオリオン村の人々とのみ取引すれば、それぞれの村が独自の会計を保持できるため、新しい技術は必要ありません。 。しかし、漁村の人々がオリオン村の人々と取引したい場合はどうなるでしょうか? 異なる台帳はどのようにして相互に通信できるのでしょうか?これは、状態シャーディングが直面する最も厄介な問題です。
この問題を解決するには 2 つの方法があり、1 つは同期 (密結合)、もう 1 つは非同期 (疎結合) です。
漁村に A という人がいて、オリオン村に B という人がいるとします。A が B に 100 元を渡したいとします。同期とは、A が送金を開始すると、漁村とオリオン村の帳簿係がその金額を知っていることを意味します。会計者は台帳のAから100を減算し、オリオン村の簿記は台帳のBに100を足し、取引が完了すると、2つの村が同時に新しいブロックを生成します。
非同期とは、A が送金を開始すると、漁村の帳簿は A を 100 減らし、新しいブロックが生成されます。オリオン村の帳簿係は、後で何らかの方法でこのメッセージを受け取り、A のお金が実際に送金されたことを確認した後、減らされた場合、彼は自分の家計簿の B に 100 を追加し、トランザクションは完了しますが、2 つの村は新しいブロックを非同期で生成します。
同期方法は一見親しみやすく、トランザクション実行処理のルックアンドフィールも非シャーディングと同じですが、「連続的な状態変化」への対応が難しいという大きな問題が隠れています。それはどういう意味ですか？
AさんがBさんに100元だけ送金した場合、取引を聞いた後、漁村とオリオン村は全員がこのように口座を持っていることを簡単に確認でき、漁村の帳簿はAさんの100元減額され、オリオン村はB に 100 を加えます。簿記を完了します。ただし、A が 100 を B に転送し、次に B に 50 を転送すると、連続的な状態変化が発生しますが、A には合計 120 しかありません。
それぞれのバリデーターが単独で相手のバリデーターと通信を行うと、通信のオーバーヘッドが大幅に増大し、一定の成果を上げることが非常に困難になりますが、双方の村長を介して通信する場合には、それぞれの村が連携する必要があります。事前に合意形成を行い、村長が相手に明確な結果を伝えるという方法ですが、コストが嵩むだけでなく、イーサリアム自体の合意の仕組み自体が明確な結果（ファイナリティ）を得ることができないため、達成が困難です。
非同期方式は「待つ」だけなので状態変化が連続しても問題ありません 状態が確認できたら次のステップに進みます 100か50を引いた後、Bに100か50を足すかを決めます。
非同期アプローチの問題は、アトミックな障害です。トランザクションは実行されるか実行されないかのアトミックである必要がありますが、非同期方式では、トランザクションの一部が確認されても、他の部分が破棄される可能性があります。
例えば、漁村がAから100を引いたブロックは漁村のメインチェーンで最終的に確認されましたが、オリオン村がBに100を加えたブロックはオリオン村のサイドチェーンで最終的に放棄されました。原子障害は問題ですが、設計によって解決できます。この部分の詳細については、記事の最後にある参考文献 5 を参照してください。
イーサリアムはいくつかの非同期アーキテクチャ モデルについて議論しています。最新のものは、2019 年 10 月の DevCon 5 カンファレンスで Vitalik によって提案されました。基本的なアイデアは、ビーコン チェーンを使用して情報を送信することです: 各スロット (12 秒) で、スライス チェーンが生成する接続方法は下図のとおりであり、どのフラグメントも自身の新しいトランザクションをパッケージ化する際に、ビーコンチェーンを通じて他のすべてのフラグメントの情報を知ることができます。スロットは異なるシャード間では非同期です。
この方法では、クロスシャード トランザクションのレイテンシは短縮されますが、すべてのシャードの証拠データを保存する必要があるビーコン チェーンの要件が増加します。この方法では、クロスリンクされたリンクの数も増加します (当初は各エポックとして設計されていました)。 、6.4分、1回32ブロックのクロスリンク）、これにより関連するさまざまなオーバーヘッドが必然的に増加し、このため、イーサリアムのフラグメント数は1024から64に変更され、別の設計方向からリンクの総数を削減します。 (アーキテクチャの詳細については、参考資料 6 を参照してください)
現在のいくつかのシャーディング設計スキームから判断すると、同期モデルはシャードとシャード自体の間で通信する傾向があり、非同期モデルはサードパーティを介してシャード間で通信する傾向があり、前者はトラフィック制約の問題に直面し、後者は直面します。複数のオーバーヘッドのバランスの問題。クロスシャードトランザクションの設計と実装はまだ進行中であり、イーサリアム 2.0 が最終的にどのアーキテクチャを採用するかは不明です。
副題
シャード間のスマート コントラクト
シャーディングとクロスシャード トランザクションの導入後、イーサリアム 2.0 開発への道における究極のボスが登場します。それはクロスシャード スマート コントラクトです。クロスシャード トランザクションとクロスシャード スマート コントラクトの違いは、トランザクションにはグローバル変数のみがあるのに対し、スマート コントラクトにはローカル変数があることです。ローカル変数はどのような問題を引き起こすのでしょうか?
シャーディング後、イーサリアムには物理的な観点から見ると 64 個の台帳がありますが、抽象的な観点から見ると台帳は 1 つだけです。台帳は大きなツリーとして想像でき、ツリーの各葉にはアカウント ステータス データが保存されます。64 台帳は64本の木、そしてそれらの木の根がビーコンチェーンに与えられて新しい大きな木が形成され、64個の台帳が結合されて台帳が作成されます（これはおおよその比喩です）。
クロスシャード トランザクションでは、シャードが別のシャードのアカウント ステータスを知る必要がある場合、常にツリーをたどって状態を保存しているリーフを見つけ、自身のシャード アカウント ステータスを変更してトランザクションを完了できます。このツリーを通じて、さまざまなシャードが情報の通信を完了すると考えることができます。
しかし、シャード間のスマート コントラクトの場合、問題が発生します。このツリーのリーフに保存されているデータはすべてグローバル変数であり、ローカル変数はありません。あるシャードのスマート コントラクトが別のシャードのスマート コントラクトを呼び出すと、何が起こるでしょうか。ローカル変数に情報を渡しますか?木は彼らに奉仕することはできません。
現時点では、体系的なスマートコントラクトのクロスシャード設計スキームはありませんが、2 つの提案があります。1 つは、関連するスマートコントラクトを実行のために同じシャードに配置すること、つまり、スマートコントラクトのクロスシャードを排除することです。 SIMD (Single struction Stream Multiple Data Stream) テクノロジーの使用を提案し、スマート コントラクト自体を並行して実行できるようにします。
参考文献:
1.《 Minimum Committee Size Explained》イーサリアム 2.0 はフェーズ 2 でスマート コントラクトを導入します。つまり、スマート コントラクトのクロスシャーディングはフェーズ 2 まで実現されず、このステップを経て初めてイーサリアムが 2.0 時代に入ったと真に宣言できることになります。
3.《Using polynomial commitments to replace state roots》; 著者、梁志成
4.「イーサリアム 2.0: ランダム性」; 著者、ブルーノ・シュクヴォルク; 翻訳者、ジョニー・A・ジャン;
5.; 著者、ヴィタリック・ブテリン。「Eth2.0中継ネットワークと料金の仕組み」
6.《Eth2 shard chain simplification proposal》; 著者、ジョン・アドラー; 翻訳者、IAN LIU, A Jian;
7.「ブロックチェーンフラグメンテーションの概念と課題」; 著者、アレクサンダー・スキダノフ; 翻訳者、ジョニー・エコー・A・ジャン;
8.《Merge blocks and synchronous cross-shard state execution》; 著者、ヴィタリック・ブテリン。
