「イーサリアム 2.0 シャーディング設計」は誰でも理解できる

セブンイレブンで朝食を買うとき、レジ係が一人しかいない場合は、会計のために長い列に並ばなければなりません。レジ係が 2 人いれば、チェックアウトの速度は 2 倍になります。レジ係が4人いれば、列に並ぶ必要はないかもしれません。これは、1 人の作業を複数の人に分割して効率を向上させるというシャーディングの基本的なロジックです。

Ethereum の分散型台帳の観点から見ると、シャーディング以前は、1 秒あたり約 12 ～ 45 件のトランザクションを処理できる台帳はメイン チェーンの 1 つだけでした。トランザクション量がこれより大きくなると、キューが必要になり、ネットワークが混雑することになります。シャーディングにより、1 つの元帳が 64 個の元帳に変換され、トランザクションを同時に処理できるようになります。これは、7-11 に 64 台のレジがあるのと同等です。

シャーディングのロジックはシンプルですが、実装がなぜ難しいのでしょうか?会計のために元帳を 64 の元帳に分割すると多くの新しい問題が発生するため、シャーディング技術はそれらの問題を解決するために設計されています。この記事では、これらの質問から始めて、Ethereum 2.0 のシャーディングが何であるかを明らかにします。

01 シャードする方法

1. トランザクションをシャードに割り当てる

シャードには、トランザクションと、トランザクションをブロックにパッケージ化するバリデーターが含まれます。シャーディングを完了するための最初のステップは、トランザクションとバリデータをシャードに割り当てる方法を決定することです。まず、割り当て取引について見てみましょう。

3つの村の物語を使って理解しましょう。漁村、狩猟村、そして農家の村があります。村内および村間では頻繁に取引が行われていますが、通貨はなく、全員が帳簿をつけています。以前は、1 冊の帳簿に 3 つの村の会計を記録していましたが、少し時間がかかりました。現在は3冊の帳簿に変更されていますが、どの帳簿にどの口座を記録すればよいのでしょうか？

1 つの方法は、そこに 3 つの元帳を配置し、取引が発生すると、誰もいない元帳に記録するというものです。しかし、これにより、各元帳に全員のアカウント情報がなければならないという問題が発生します。そうでないと、私があなたのキューに来たときに、あなたは私のアカウントを持っていないことになります。

このため、このシャーディング アプローチの主な問題は、単一の元帳に保存されるデータの量を削減できないことであり、このストレージ要件は、簿記に参加したいノードにとって高いハードルとなります。このアプローチでは、人が同時に異なるシャードで同じお金を使う可能性があるため、二重支出の問題も解決する必要があります。

もう一つの方法は、漁村に1冊の帳簿、狩猟村に1冊の帳簿、そして農村に1冊の帳簿を持つというものです。各帳簿には、その村の口座情報のみが記載され、その村内の取引のみが記録されます。この方法では、3 つの元帳で同時にアカウントを記録できるため、会計効率が高く、ストレージ要件が低くなります。これはまさに Ethereum が採用しているシャーディング方法、つまり各シャードが自身のシャードに属するアカウント ステータスのみを保存するステート シャーディングです。実装の面では、Ethereum では、自然な村ごとにシャーディングするのではなく、ユーザーがどのシャードに参加するかを選択できるようになっています。

ステート シャーディングの最大の問題は、漁村の人々が狩猟村の人々と取引したい場合どうなるかということです。漁村の帳簿には猟村出身者の記載はなく、猟村の帳簿にも漁村出身者の記載はない。実際、シャーディング技術が直面している最大の課題は、シャード間の通信です。この問題が完全に解決されると、Ethereum 2.0 が使用できるようになります。この記事の第 2 部では、この問題に対するいくつかの解決策について説明します。

2. バリデータをシャードに割り当てる

トランザクションを異なるシャードに配置した後、次に解決すべき問題は、アカウント管理者を特定のシャードに割り当てる方法、つまりバリデーターを割り当てる方法です。

Ethereum には 64 個のシャードがあり、それぞれに 128 個のバリデーターがあります。シャードのバリデータが固定されていたり予測可能であったりすると、攻撃者がシャードを制御すること、つまり 128 のうち 2/3 を買収することが容易になります。どうすればよいでしょうか? Ethereum の解決策は、すべてのバリデーターからシャードのバリデーターをランダムに選択し、6.4 分 (エポックの長さ) ごとにバリデーターを交換することです。この方法では、攻撃者がシャード内の 2/3 のユーザーを制御できる可能性は 1 兆分の 1 未満です (推論プロセスについては参考文献 1 を参照)。

ビーコン チェーンの主なタスクの 1 つは、シャード チェーンにバリデーターを割り当てることです。この作業で最も注意すべき点は、ランダム性の実装です。 1 つ目はランダム性の重要性です。バリデータをランダムに割り当てることができない場合、元帳のセキュリティは保証されません。 2 つ目はランダム性の難しさです。ブロックチェーン上でランダム性を実現することは非常に困難です。エンジニアリング実装と呼べる、真に証明されたランダム アルゴリズムは存在しないと言えます。

Ethereum のソリューションは、RANDAO+VDF を使用して乱数を提供し、ランダム性を実現することです。 RANDAOをRAN（ランダム）とDAOに分解すると理解しやすいです。これは、グループ内の各人が独自に乱数を提案し、その後、すべての乱数を組み合わせて、最終的に使用される乱数を生成することを意味します。他人が提供した数字を誰も知ることは難しいため、最終的な合計数を予測することも困難です。

しかし、RANDAO モデルには欠陥があり、最後の数字を提供する人が不正行為をする機会があります。つまり、最後の数字を提供する人は、前のすべての人が提供した乱数の合計を知っており、最終結果が自分に有利になるように提供する数字を調整することができます。

この問題を解決するために、イーサリアムは VDF (検証可能な遅延関数) を導入しました。これは、乱数を最後に提供する人が自分の番号を提供する前に以前のすべての乱数の合計を計算することを防ぎ、乱数を操作できないようにする単純な機能です。 （RANDAO+VDFの詳しい紹介については、参考文献2を参照してください）

3. リレーによるシャードストレージ

元帳検証者のローテーションによって新たな問題が発生することに気付きましたか。検証者は、漁村のアカウントを管理するよう割り当てられることもあれば、狩猟村のアカウントを管理するよう割り当てられることもあります。すべてのアカウント情報を持っていないとしたら、どうやってアカウントを管理できるのでしょうか?すべてのアカウント情報を持っている場合、完全な元帳を持つことになり、状態シャーディングを実現できなくなります。

この問題を解決するために、Ethereum はステートレス クライアントという重要な新しい設計を提案しました。簡単に言えば、漁村の帳簿は漁村に保管され、狩猟村の帳簿は狩猟村に保管されます。バリデーターは会計帳簿を保持しておらず、会計を記録するためにさまざまな村の間を行ったり来たりすることだけを担当しています。

では、各村の帳簿は誰が管理するのでしょうか? Ethereum では、さまざまなシャードのアカウント ステータスを保存する責任があり、特定のシャードにのみサービスを提供できるリレーヤー (状態プロバイダー) の役割が導入されています。リレーヤーの仕事は理解しやすいですが、彼らのサービスに対してどのように支払いをし、彼らの誠実さをどのように確保するか...これらの関連するメカニズムの設計は解決する必要がある新しい問題であり、コミュニティのメンバーが議論に参加する必要があるガバナンスの問題でもあります。

ステートレス クライアントの実際の状況は、上記で説明したよりもはるかに複雑です。 「トランザクション」自体の構造はシャーディング前とは異なります。有効であることを証明する証人データを添付する必要があります。 1.0 では、バリデーターは新しいトランザクションを検証するために古いアカウントを自分で保存する必要があると考えられます。 2.0 では、トランザクションは古いアカウントを自分で持参し、検証のためにバリデーターに渡す必要があります。

ただし、トランザクションを開始した後にそれを証明できるように、すべてのユーザーに古いアカウントをすべて保存するように要求することはできません。このとき、シャードのすべてのアカウント ステータスを保存する「リレー」が必要になります。ユーザーが要求を出す限り、ユーザーはバリデーターにトランザクション証人データを提供することができます。

Vitalik Buterin 氏は 3 月 11 日に、状態ルートの代わりに多項式コミットメントを使用することを提案する記事を公開しました。ここではこの技術が使われています。ゼロ知識証明を使用してトランザクションの証明を提供します。これは、検証のために関連するすべてのデータを検証者に直接提供するのではなく、データの計算結果を検証者に提供して検証することとして理解できます。この方法により、証人データのサイズが大幅に削減され、さまざまなオーバーヘッドが効果的に削減されます。 (Vitalik の新しい方法の詳細な紹介については、参考文献 3 を参照してください。ステートレス クライアントの詳細な紹介については、参考文献 4 を参照してください)

このステップで、1つの元帳を複数の元帳に分割する作業、つまりシャーディングが完了します。

02 クロスシャードトランザクション

漁村の人々が漁村の人々とのみ取引し、狩猟村の人々が狩猟村の人々とのみ取引する場合、各村は独自の口座を保持するだけでよく、これには新しいテクノロジーは必要ありません。しかし、漁村の人々が狩猟村の人々と貿易をしたい場合はどうなるでしょうか?異なる帳簿はどのようにして相互に通信できるのでしょうか?これは、状態シャーディングが直面する最も困難な問題です。

この問題を解決するには 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 が B に 100 を送金し、次に B に 50 を送金すると、連続的な状態変化が発生しますが、A が保有する合計金額は 120 元のみです。現時点では、両村が相手方がどのように会計を行っているかを確認することは困難である。

各バリデーターが他のバリデーターと通信する場合、通信オーバーヘッドが大幅に増加し、特定の結果に到達することが非常に困難になります。双方の村長を通じてコミュニケーションがとられる場合、それぞれの村が事前に合意形成を行い、その後村長が相手方に明確な結果を伝えることになります。オーバーヘッドが増加するだけでなく、Ethereum のコンセンサス メカニズム自体が明確な結果 (ファイナリティ) に到達できないため、これを実現することも困難です。

非同期メソッドは「待機」するアプローチであるため、継続的な状態の変化によって問題が発生することはありません。あなたの状態が判明したら、次のステップに進みます。漁村が A の勘定を記録し終えた後、狩猟村は A が 100 を減算したか 50 を減算したかを確認し、B に 100 を追加するか 50 を追加するかを決定します。

非同期アプローチ自体の問題は、アトミック障害です。トランザクションは、実行されるかされないかのどちらか一方にアトミックであるはずですが、非同期方式では、トランザクションの一部は確認されても、他の部分は破棄される可能性があります。

例えば、漁村がAから100を減算したブロックは漁村のメインチェーン上で最終的に確定しましたが、狩猟村がBに100を加えたブロックは狩猟村のサイドチェーン上で最終的に放棄されました。アトミック性の失敗は問題ですが、設計によって解決できます。この部分の詳細な紹介については、記事の最後にある参考文献 5 を参照してください。

非同期方式のもう 1 つの問題は、時間のオーバーヘッド、通信のオーバーヘッド、およびストレージのオーバーヘッド、つまり、シャード間のトランザクションを完了するために必要な待機時間とリソースです。異なるシャード間で情報が送信される方法によって、これらのオーバーヘッドの量が決まります。さまざまな種類のオーバーヘッドは相互に関連しており、同時に達成することは困難であるため、設計時の目標はバランスをとることです。 Ethereum 2.0 の将来のパフォーマンスは、情報の送信方法によって決まります。

Ethereum では、いくつかの非同期アーキテクチャ モデルについて議論されています。最新のものは、2019 年 10 月の DevCon 5 カンファレンスで Vitalik によって提案されました。基本的な考え方は、ビーコン チェーンを使用して情報を送信することです。各スロット (12 秒) で、シャード チェーンはブロックを生成し、ビーコン チェーン ブロックと相互リンクします。接続方法は下図の通りです。このようにして、どのシャードも、独自の新しいトランザクションをパッケージ化するときに、ビーコン チェーンを通じて他のすべてのシャードの情報を知ることができます。異なるシャード間の非同期スロット。

この方法では、シャード間のトランザクションの待機時間が短縮されますが、すべてのシャードの証明データを保存する必要のあるビーコン チェーンの要件が増加します。この方法では、クロスリンクの数も増えます (元の設計では、エポックごとに 1 回、つまり 6.4 分と 32 ブロックごとにクロスリンクすることになっていました)。そのため、さまざまな関連するオーバーヘッドが必然的に増加します。このため、Ethereum シャードの数は 1024 から 64 に変更され、別の設計方向からのリンクの総数が削減されました。 （このアーキテクチャの詳細な紹介については、参考文献6を参照してください）

現在のいくつかのシャーディング設計スキームから判断すると、同期モデルではシャードが相互に通信する傾向が強く、非同期モデルではシャードが相互に通信せず、サードパーティを介して通信する傾向が強いと言えます。前者は通信量の問題に直面し、後者は複数のオーバーヘッドのバランスをとる問題に直面します。クロスシャードトランザクションの設計と実装はまだ進行中であり、Ethereum 2.0 が最終的にどのアーキテクチャを採用するかはまだ定かではありません。

03 クロスシャードスマートコントラクト

シャーディングとクロスシャードトランザクションの導入後、Ethereum 2.0 開発への道における究極のビッグボス、クロスシャード スマート コントラクトが登場しました。クロスシャード トランザクションとクロスシャード スマート コントラクトの違いは、トランザクションにはグローバル変数のみがあるのに対し、スマート コントラクトにはローカル変数がある点です。ローカル変数はどのような問題を引き起こす可能性がありますか?

シャーディング後、Ethereum には物理的な観点から見ると 64 個の元帳がありますが、抽象的な観点から見ると元帳は 1 つだけです。元帳を大きな木として想像すると、木の各葉にはアカウント ステータス データが保存され、64 個の元帳は 64 個の木になります。これらのツリーのルートをビーコン チェーンに渡すと、新しい大きなツリーが形成され、64 個の元帳が 1 つの元帳に結合されます (これは単なる大まかな比喩です)。

クロスシャードトランザクションでは、あるシャードが別のシャードのアカウントステータスを知る必要がある場合、常にツリーをたどってステータスを格納するリーフを見つけ、自分のシャードのアカウントステータスを変更してトランザクションを完了することができます。このツリーを通じて、異なるシャードが相互に通信できると考えられます。

しかし、クロスシャードのスマート コントラクトの場合、問題が発生します。このツリーの葉に格納されるデータはすべてグローバル変数であり、ローカル変数はありません。あるシャード上のスマート コントラクトが別のシャード上のスマート コントラクトを呼び出す場合、2 つのコントラクトはどのようにしてローカル変数の情報を渡すのでしょうか?木は彼らに何のサービスも提供できません。

また、クロスシャードトランザクションはグローバル変数、つまり第 1 レベルのステータスのみを確認する必要があり、クロスシャードスマートコントラクトはローカル変数、つまり第 2 レベルのステータスも確認する必要があることもわかります。クロスシャードトランザクションとクロスシャードスマートコントラクトの設計の難しさは、同じ桁ではありません。

今のところ、クロスシャード スマート コントラクトの体系的な設計はありませんが、2 つの提案があります。 1 つは、関連するスマート コントラクトを同じシャードに入れて実行することです。つまり、シャード間のスマート コントラクトの必要性を排除することです。もう 1 つは、SIMD (単一命令複数データ) テクノロジを使用して、スマート コントラクトを並列に実行できるようにすることです。

Ethereum 2.0 はフェーズ 2 でスマート コントラクトを導入します。つまり、クロスシャード スマート コントラクトはフェーズ 2 まで実現されません。このステップを踏んで初めて、Ethereum は真に 2.0 時代に入ることができます。

1. 委員会の最小規模についての説明著者、梁志成; https://medium.com/@chihchengliang/minimum-committee-size-explained-67047111fa20

2. Ethereum 2.0: ランダム性;著者、ブルーノ・シュクヴォルツ;翻訳、ジョニー、アジアン; https://ethfa​​ns.org/posts/two-point-oh-randomness

3. 多項式コミットメントを使用して状態ルートを置き換える (Vitalik Buterin 著)

4. 「Eth2.0 のリレー ネットワークと手数料市場」、John Adler 著、IAN LIU と Ajian 訳、https://ethfa​​ns.org/posts/relay-networks-and-fee-markets-in-eth-2

5. ブロックチェーン シャーディングの権威あるガイド: 概念と課題著者: Alexander Skidanov;翻訳：Jhonny、Echo、Ajian https://ethfa​​ns.org/posts/the-authoritative-guide-to-blockchain-sharding-part-1

6. Eth2 シャードチェーンの簡素化提案。著者、ヴィタリック・ブテリン; https://notes.ethereum.org/@vbuterin/HkiULaluS

7. ETH 2.0 エンジニアガイド著者: ジェームズ・プレストウィッチ;翻訳: Aisling、Qiqi、stormpang、Ajian; https://ethfa​​ns.org/posts/what-to-expect-when-eths-expecting

8. Vitalik Buterin によるブロックのマージと同期クロスシャード状態実行 https://ethresear.ch/t/merge-blocks-and-synchronous-cross-shard-state-execution/1240