シャーディングの基本

シャーディングへの最も単純なアプローチから始めましょう。このアプローチでは、代わりに 1 つの blockchain を実行する場合は、複数を実行し、そのようなそれぞれを blockchain と呼びます。 「シャード」。各シャードには独自の validator のセットがあります。ここと以下で使用します 一般用語「validator」は、トランザクションを検証する参加者を指し、 Proof of Work などのマイニング、または投票ベースのいずれかによってブロックを生成します。 1このセクションは以前 https://near.ai/shard1. で公開されたものです。以前に読んだことがある方は、 次のセクションに進んでください。

機構。ここでは、シャードがそれぞれのシャードと通信しないと仮定します。 その他。 この設計は単純ではありますが、シャーディングにおける最初の主要な課題の概要を説明するには十分です。 1.1 バリデーターのパーティショニングとビーコンチェーン システムが 10 個のシャードで構成されているとします。最初の課題は、それぞれの シャードには独自の validator があり、各シャードの安全性は 10 倍低くなります。 チェーン全体。したがって、X validators の非シャード チェーンがハードフォークすることを決定した場合 シャード チェーンに分割し、X validator を 10 個のシャードに分割します。各シャードは現在 X/10 validator しかなく、1 つのシャードを破損する場合は破損するだけで済みます。 validator の総数の 5.1% (51% / 10) (図 1 を参照)、 図1: validator をシャード間で分割する ここで 2 番目の点がわかります。各シャードの validator を選択するのは誰ですか? validator の 5.1% を制御しても、validator の 5.1% がすべて制御されている場合にのみ有害です。 同じシャード内にあります。 validator が検証するシャードを選択できない場合 では、validator の 5.1% を管理する参加者がすべてを取得できる可能性は非常に低いです。 validator が同じシャード内にあるため、侵害する能力が大幅に低下します。 システム。 今日のほぼすべてのシャーディング設計は、何らかのランダム性のソースに依存しています。 validator をシャードに割り当てます。 blockchain のランダム性自体は非常に難しいトピックであり、このドキュメントの範囲外です。今のところ、あると仮定しましょう 使用できるランダム性のソース。 validator の課題については、 詳細についてはセクション 2.1 を参照してください。 ランダム性と validator 割り当ての両方で、次のような計算が必要です。 特定のシャードに固有です。その計算では、事実上すべての既存の 設計には、操作の実行を担当する別の blockchain があります。 ネットワーク全体のメンテナンスに必要です。ランダムに生成するだけでなく、番号を付けてシャードに validator を割り当てると、これらの操作は多くの場合、 シャードからの更新の受信とそれらのスナップショットの取得、処理が含まれます。 Proof-of-Stake システムでのステークとスラッシュ、およびその際のシャードのリバランス 機能がサポートされています。このようなチェーンは、Ethereum ではビーコン チェーン、リレーと呼ばれます。 PolkaDot のチェーンと Cosmos の Cosmos ハブ。 このドキュメントでは、このようなチェーンをビーコン チェーンと呼びます。 ビーコン チェーンの存在は、次の興味深いトピックにつながります。 二次シャーディング。 1.2 二次シャーディング シャーディングは、数に応じて無限に拡張できるソリューションとして宣伝されることがよくあります。 ネットワーク操作に参加しているノードの数。理論的には可能ですが、 このようなシャーディング ソリューション、ビーコンの概念を持つソリューションを設計する チェーンには無限の拡張性はありません。その理由を理解するには、ビーコンが チェーンは、validators を割り当てるなど、何らかの簿記計算を行う必要があります。 シャード、またはシャード チェーン ブロックのスナップショット。これは数に比例します。 システム内のシャードの数。ビーコン チェーン自体は単一の blockchain であるため、 計算は、それを操作するノードの計算能力によって制限されます。 シャードの数は当然限られています。 ただし、シャード化されたネットワークの構造により、乗算的な効果が得られます。 ノードの改善に影響します。任意の ネットワーク内のノードの効率が向上し、 トランザクション処理時間が短縮されます。 ビーコン チェーン内のノードを含め、ネットワークを運用しているノードが、 4 倍高速になると、各シャードは 4 倍多く処理できるようになります トランザクションが増加すると、ビーコン チェーンは 4 倍のシャードを維持できるようになります。 システム全体のスループットは 4 × 4 = 16 倍に増加します — したがって、二次シャーディングという名前が付けられます。 シャードの数を正確に測定することは困難です 現在は実行可能ですが、予見可能な将来にスループットが向上する可能性は低いです。 blockchain ユーザーのニーズは二次シャーディングの制限を超えるでしょう。 このような大量のシャードを安全に運用するには膨大な数のノードが必要です これは、すべてのノードを実行しているノードの数よりも桁違いに多い可能性があります。 今日はblockchainが結合されました。 1.3 状態シャーディング これまで、正確に何が分離され、何が分離されないのかをあまり明確に定義できませんでした ネットワークがシャードに分割されるとき。具体的には、blockchain 内のノード 3 つの重要なタスクを実行します。1) トランザクションを処理するだけでなく、 また、2) 検証されたトランザクションと完了したブロックを他のノードに中継する、および 3) ネットワーク台帳全体の状態と履歴を保存します。この３つそれぞれが タスクにより、ネットワークを運用するノードに対する要件が増大します。1. トランザクションを処理する必要があるため、より多くの計算能力が必要になります。 処理されるトランザクション数の増加。 2. トランザクションとブロックを中継する必要があるため、中継されるトランザクション数の増加に伴い、より多くのネットワーク帯域幅が必要になります。 3. データを保存する必要があるため、状態が大きくなるにつれて、より多くのストレージが必要になります。重要なのは、処理能力やネットワークとは異なり、ストレージ要件はトランザクション レート (処理されるトランザクションの数) に関係なく増加することです。 1 秒あたり) は一定のままです。 上記のリストから、ストレージ要件は次のように見えるかもしれません。 時間の経過とともに増加する唯一のものであるため、最も差し迫ったもの たとえ 1 秒あたりのトランザクション数が変わらなかったとしても、実際には 今日最も差し迫った要件は計算能力です。全体の状態 この記事の執筆時点では Ethereum は 100 GB で、ほとんどのノードで簡単に管理できます。 ただし、Ethereum が処理できるトランザクションの数は約 20、つまり注文数です。 多くの実際の使用例に必要な大きさよりも小さい。 Zilliqa は、処理をシャード化しますが、ストレージはシャード化しない最もよく知られたプロジェクトです。 処理のシャーディングは、各ノードが全体を持っているため、より簡単な問題です。 状態。コントラクトが自由に他のコントラクトを呼び出し、任意のデータを読み取ることができることを意味します。 blockchain から。確実に更新するには慎重なエンジニアリングが必要です 複数のシャードから状態の同じ部分を更新しても競合しません。で これらに関して、Zilliqa は比較的単純なアプローチを採用しています2。 処理をシャーディングせずにストレージをシャーディングすることが提案されましたが、 極めて珍しい。したがって、実際にはストレージのシャーディング、つまり状態シャーディングでは、 ほとんどの場合、処理のシャーディングとネットワークのシャーディングを意味します。 実際には、状態シャーディングの下で、各シャード内のノードがそれぞれのノードを構築します。 のローカル部分のみに影響を与えるトランザクションを含む独自の blockchain そのシャードに割り当てられているグローバル状態。 したがって、validator は シャードはグローバル状態のローカル部分を保存し、実行するだけで済みます。 したがって、中継されるのは、州の一部に影響を与えるトランザクションのみです。これ パーティションは、すべての計算能力、ストレージ、およびストレージの要件を直線的に削減します。 ネットワーク帯域幅は増加しますが、データの可用性やデータの可用性などの新たな問題が生じます。 クロスシャード トランザクションについては、以下で説明します。 1.4 クロスシャードトランザクション これまで説明したシャーディング モデルはあまり役に立ちません。 シャードは相互に通信できません。複数のシャードと同等です。 独立したblockchain。シャーディングが利用できない現在でも、 さまざまな blockchain 間の相互運用性に対する大きな需要があります。 ここでは、各参加者が 1 つのシャードにのみアカウントを持っている単純な支払いトランザクションのみを考えてみましょう。から送金したい場合は、 2彼らのアプローチに関する当社の分析はここでご覧いただけます: https://medium.com/nearprotocol/ 8f9efae0ce3b同じシャード内のアカウント間でトランザクションを処理できます。 完全にそのシャード内の validator によって行われます。ただし、シャードに存在するアリスの場合は、

1 は、validators ではなく、シャード #2 に存在するボブに送金したいと考えています。

シャード #1 (ボブのアカウントに入金することはできません) または validator シャード #2 (アリスの口座から引き落とすことはできません) は、全体を処理できます。 取引。 クロスシャード トランザクションには 2 つのアプローチがあります。 • 同期: クロスシャードトランザクションを実行する必要があるときは常に、 に関連する状態遷移を含む複数のシャード内のブロック トランザクションはすべて同時に生成され、複数のシャードの validator が連携してそのようなトランザクションを実行します。3 • 非同期: 複数のシャードに影響を与えるクロスシャードトランザクション これらのシャード内で非同期に実行され、「Credit」シャードが実行されます。 「デビット」シャードがその部分を実行したという十分な証拠が得られたら、その半分を返します。このアプローチは、次の理由によりより普及する傾向があります。 シンプルさとコーディネートのしやすさ。このシステムは現在、Cosmos、Ethereum セレニティ、ニア、嘉手納などで提案されています。これに関する問題 このアプローチは、ブロックが独立して生成される場合、複数のブロックのうちの 1 つが孤立する可能性がゼロではないため、 トランザクションは部分的にのみ適用されます。 2 つの要素を描いた図 2 を考えてみましょう。 両方でフォークが発生したシャードとシャード間のトランザクション それはブロックAとX’に対応して記録されました。チェーンA-Bの場合 および V'-X'-Y'-Z' は、対応するシャード内で正規になります。 取引は完全に完了しました。 A'-B'-C'-D' と V-X が正規になった場合、 その後、トランザクションは完全に放棄されますが、これは許容されます。しかし、もし、 たとえば、A-B と V-X が正規になり、トランザクションの一部が終了し、もう 1 つは破棄され、アトミック性の障害が発生します。私たち 第 2 部では、フォーク選択ルールとコンセンサスの変更について説明する際に、提案されたプロトコルでこの問題がどのように対処されるかを説明します。 シャード化プロトコル用に提案されたアルゴリズム。 チェーン間の通信は、シャード化された blockchain の外部でも役立つことに注意してください。 も。チェーン間の相互運用性は、多くのプロジェクトが抱える複雑な問題です。 解決しようとしています。シャード化された blockchains では、問題は多少簡単になります。 ブロック構造とコンセンサスはシャード間で同じであり、調整に使用できるビーコン チェーンがあります。ただし、シャード化された blockchain では、 すべてのシャード チェーンは同じですが、グローバル blockchains エコシステムでは さまざまなターゲット ユースケース、分散化を伴うさまざまな blockchain が多数あります そしてプライバシーの保証。 一連のチェーンが異なるプロパティを持つシステムを構築しますが、 十分に類似したコンセンサスとブロック構造を使用し、共通のビーコン チェーンを使用すると、異種の blockchain のエコシステムが可能になります。 3 ほとんどの 詳しい 提案 知られている に の 著者 の これ 文書 です マージ ブロック、 説明した ここで： https://ethresear.ch/t/ マージブロックと同期クロスシャード状態実行/1240図2: 非同期クロスシャードトランザクション 動作中の相互運用性サブシステム。このようなシステムには validator 回転機能が搭載されていない可能性が高いため、セキュリティを確保するために追加の対策を講じる必要があります。両方 Cosmos と PolkaDot は実質的にそのようなシステムです4 1.5 悪意のある行為 このセクションでは、validator に悪意を与える可能性がある敵対的な動作を確認します。 シャードを破壊できた場合は、実行してください。古典的なアプローチを確認します セクション 2.1 でシャードの破損を避けるため。 1.5.1 悪意のあるフォーク 一連の悪意のある validator がフォークの作成を試みる可能性があります。そうではないことに注意してください 基礎となるコンセンサスがBFTであるかどうかは関係なく、十分な数が破損します validators を使用すると、常にフォークを作成できるようになります。 ネットワーク全体の 50% 以上が破損するよりも、単一のシャードの 50% 以上が破損する可能性が大幅に高くなります (後で説明します)。 これらの確率については、セクション 2.1 で詳しく説明します)。セクション 1.4 で説明したように、 クロスシャードトランザクションには、複数のシャードにおける特定の状態変化が含まれます。 このような状態変更を適用するシャード内の対応するブロックは、 すべて完了している（つまり、対応する選択されたチェーンに表示されている） シャード）、またはすべてが孤立する（つまり、対応するシャードの選択されたチェーンに表示されない）。一般的にシャードが破損する可能性が高いため、 4Zaki Manian によるCosmos の記事を参照してください: https://forum.cosmos.network/ t/polkadot-vs-cosmos/1397/2 と、この文書の最初の著者によるツイートの嵐: 詳細な比較については、https://twitter.com/AlexSkidanov/status/1129511266660126720 二人のうち

無視できるものではありません。シャード validator 間でビザンチン的な合意に達した場合、または多くのブロックが合意に達した場合でも、フォークが発生しないと想定することはできません。 状態の変化とともにブロックの上に生成されます。 この問題には複数の解決策がありますが、最も一般的な解決策は時折発生するものです。 最新のシャード チェーン ブロックをビーコン チェーンに架橋します。 フォーク シャード チェーンの選択ルールは、常に次のチェーンを優先するように変更されます。 クロスリンクされ、シャード固有のフォーク選択ルールのみをブロックに適用します。 最後の相互リンク以降に公開されました。 1.5.2 無効なブロックの承認 validator のセットは、状態遷移関数を誤って適用するブロックを作成しようとする可能性があります。たとえば、アリスがいる状態から始めます。 には token が 10 個あり、ボブには token が 0 個ある場合、ブロックには次のようなトランザクションが含まれる可能性があります。 アリスからボブに 10 token を送信しますが、最終的にはアリスが次の状態になります。 図 3 に示すように、0 token 個で、ボブの token 個は 1000 個です。 図3: 無効なブロックの例 従来の非シャード blockchain では、そのような攻撃は不可能です。 ネットワークの参加者はすべてのブロックを検証し、そのようなブロックは 無効な状態遷移は他のブロックプロデューサーの両方によって拒否されます。 ブロックを作成しないネットワークの参加者。たとえ悪意があったとしても、 validators は、そのような無効なブロックの上に、次の速度よりも速くブロックを作成し続けます。 正直な validator は正しいチェーンを構築するため、無効なチェーンが含まれます。 ブロックが長くても、すべての参加者が blockchain は、いかなる目的であっても、すべてのブロックを検証し、すべてのブロックを破棄します 無効なブロックの上に構築されます。 図 4 には 5 つの validator があり、そのうち 3 つは悪意のあるものです。彼らは 無効なブロック A’ を作成し、その上に新しいブロックを構築し続けました それの。 2 つの正直な validator は A' を無効として破棄し、その上に構築していました図4: 非シャード blockchain で無効なブロックを作成しようとしました 既知の最後の有効なブロックを抽出し、フォークを作成します。数が少ないので 正直フォークの validator のチェーンは短くなります。ただし、クラシックな非シャード blockchain では、目的を問わず blockchain を使用するすべての参加者は、 受信したすべてのブロックを検証し、状態を再計算する責任があります。 したがって、blockchain に興味がある人は誰でも、A’ に気づくでしょう。 は無効であるため、B'、C'、および D' もすぐに破棄されます。 チェーン A-B を現在最長の有効なチェーンとして指定します。 ただし、シャード化された blockchain では、すべてのシャード上のすべてのトランザクションを検証できる参加者はいないため、それを確認する何らかの方法が必要です。 blockchain のシャードの履歴のポイントに無効なブロックは含まれていませんでした。 フォークとは異なり、ビーコン チェーンには検証する能力がないため、ビーコン チェーンへのクロスリンクは十分な解決策ではないことに注意してください。 ブロック。そのシャード内に十分な数の validator が存在することのみを検証できます。 ブロックに署名しました (したがって、その正確性が証明されました)。 この問題の解決策については、以下のセクション 2.2 で説明します。

状態の有効性とデータの可用性

シャード化された blockchains の中心的な考え方は、ほとんどの参加者が操作または ネットワークを使用すると、すべてのシャード内のブロックを検証できません。このように、いつでも 参加者は通常はできない特定のシャードと対話する必要があります シャードの履歴全体をダウンロードして検証します。 ただし、シャーディングのパーティショニングの側面により、大きな可能性が高まります。 問題: 特定の履歴全体をダウンロードして検証しないと 参加者は、シャードの状態がどのような状態であるかを必ずしも確信できるわけではありません。 5このセクションは、サブセクション 2.5.3 を除き、https://near.ai/ で以前に公開されました。 シャード2。すでに読んでいる場合は、次のセクションに進んでください。

それらの相互作用は、ブロックの有効なシーケンスの結果であり、そのシーケンスは of block は確かにシャード内の正規チェーンです。そうならない問題 シャード化されていない blockchain に存在します。 まず、この問題に対して提案されている簡単な解決策を紹介します。 多くのプロトコルで解析し、このソリューションがどのように壊れるか、何が壊れるかを分析します。 それに対処する試みがなされてきました。 2.1 バリデーターのローテーション 状態の妥当性に対する素朴な解決策を図 5 に示します。 システム全体には数千個の validator があり、そのうち 悪意のあるもの、またはそうでなければ失敗するものは 20% 未満です (たとえば、 オンラインでブロックを生成します)。次に、200 validator をサンプリングすると、確率は 1つ以上の 実用的な目的での 3 つの失敗はゼロであると想定できます。 図5: validators をサンプリングしています 1 3 は重要なしきい値です。と呼ばれるコンセンサスプロトコルのファミリーがあります。 BFT コンセンサス プロトコル。1 未満である限りそれを保証します。 3の 参加者は、クラッシュするか、何らかの方法でルールに違反する動作をすることによって失敗します。 議定書では合意が得られます。 この正直な validator パーセンテージを仮定すると、現在のセットが シャード内の validators はいくつかのブロックを提供します。素朴な解決策では次のように仮定します。 ブロックが有効であり、validator が信じているものに基づいて構築されていること 検証を開始したときのそのシャードの正規チェーン。 validator さん 以前の validator セットから正規チェーンを学習しました。 正規チェーンの先頭であるブロックの上に構築された仮定 その前に。帰納法により、チェーン全体が有効になり、validator のセットがないため、 フォークが生成されたどの時点でも、単純な解決策では、現在の チェーンはシャード内の唯一のチェーンです。視覚化については、図 6 を参照してください。

図6: BFT コンセンサスを介して最終化された各ブロックを含む blockchain validator が次の可能性があると仮定すると、この単純な解決策は機能しません。 適応的に破損しますが、これは不合理な仮定ではありません6。適応的に 1,000 個のシャードがあるシステム内の 1 つのシャードを破損する方が大幅にコストが安くなります システム全体を破壊するよりも。したがって、プロトコルのセキュリティはシャードの数に応じて直線的に低下します。有効性について確実性を持たせるためには、 ブロックである場合、歴史のどの時点においても、システム内のシャードにはブロックが存在しないことを知っておく必要があります。 validator の大多数が共謀している。適応的な敵対者にとって、私たちはもはや そのような確実性。セクション 1.5 で説明したように、共謀した validator は、行使できる可能性があります。 2 つの基本的な悪意のある動作: フォークの作成と無効なブロックの生成。 悪意のあるフォークは、ブロックがビーコン チェーンにクロスリンクされることで対処できます。ビーコン チェーンは一般に、ビーコン チェーンよりも大幅に高いセキュリティを持つように設計されています。 シャードチェーン。 ただし、無効なブロックの生成はさらに重要です。 取り組むべき困難な問題。 2.2 状態の有効性 図 7 では、シャード #1 が破損し、悪意のある攻撃者によって生成されたものを考えてみましょう。 無効なブロック B。このブロック B で 1000 個の token が薄いブロックから鋳造されたとします。 アリスのアカウントで放送します。次に、悪意のある攻撃者は有効なブロック C を生成します ( C のトランザクションが正しく適用されていることを意味します）B の上に重ねて難読化します 無効なブロック B を削除し、シャード #2 へのクロスシャード トランザクションを開始します。 これら 1000 token をボブのアカウントに転送します。この瞬間から、不適切な 作成された token は、シャード #2 の完全に有効な blockchain に存在します。 この問題に対処する簡単なアプローチは次のとおりです。 6読む これ 記事 のために 詳細 に どうやって 適応的な 汚職 できる なる 運ばれた アウト: https://medium.com/nearprotocol/d859adb464c8. のために もっと見る 詳細 に 適応的な 汚職、 読む https://github.com/ethereum/wiki/wiki/Sharding-FAQ# 私たちが運用しているセキュリティモデルとは何ですか図 7: 無効なブロックを持つチェーンからのクロスシャード トランザクション 1. シャード #2 の validator について、トランザクションの送信元のブロックを検証します。 が開始されます。ブロック C があるため、上記の例でもこれは機能しません。 完全に有効であると思われます。 2. シャード #2 の validator については、トランザクションが開始されるブロックに先行する多数のブロックを検証します。当然のことながら、 受信シャードによって検証された任意の数のブロック N validators は、無効なブロックの上に N+1 個の有効なブロックを作成できます。 生産された。 この問題を解決する有望なアイデアは、シャードを配置して 各シャードが他のいくつかのシャードに接続されている無向グラフ、および 隣接するシャード間のクロスシャードトランザクションのみを許可します（例：これが方法です） Vlad Zamfir のシャーディングは基本的に機能し7、同様のアイデアが嘉手納のシャーディングでも使用されています。 チェーンウェブ [1])。シャード間でシャード間トランザクションが必要な場合は、 隣接するシャードではないため、そのようなトランザクションは複数のシャードを介してルーティングされます。このデザインでは 各シャードの validator は、シャード内のすべてのブロックの両方を検証することが期待されます 隣接するすべてのシャード内のすべてのブロックも同様です。以下の図を考えてみましょう 10 個のシャードがあり、それぞれに 4 つの隣接シャードがあり、それ以上を必要とする 2 つのシャードはありません 図 8 に示すシャード間通信の場合は 2 ホップよりも短くなります。 シャード #2 は、自身の blockchain だけでなく、次の blockchain も検証しています。 シャード #1 を含むすべての近隣者。したがって、悪意のある攻撃者がシャード #1 にいた場合、 無効なブロック B を作成し、その上にブロック C を構築しようとしています。 クロスシャードトランザクションを開始すると、そのようなクロスシャードトランザクションは実行されません シャード #2 がシャード #1 の履歴全体を検証しているため、 これにより、無効なブロック B が識別されます。 7デザインの詳細については、こちらをご覧ください: https://medium.com/nearprotocol/37e538177ed9

図 8: チェーンウェブのようなシステムにおける無効なクロスシャード トランザクションにより、 検出される 単一のシャードを破損することは実行可能な攻撃ではなくなりましたが、 シャードがほとんどないという問題が残っています。図 9 では、敵が両方のシャードを破損しています

1 とシャード #2 はシャード #3 へのクロスシャード トランザクションを正常に実行します

無効なブロック B からの資金を使用: 図9: チェーンウェブのようなシステムにおける無効なクロスシャード トランザクションにより、 検出されない シャード #3 はシャード #2 のすべてのブロックを検証しますが、シャード #1 のブロックは検証しません。 悪意のあるブロックを検出する方法はありません。 状態の妥当性を適切に解決するには、主に 2 つの方向があります。

そして暗号による計算の証明。 2.3 漁師 最初のアプローチの背後にある考え方は次のとおりです。 あらゆる目的（チェーンへのクロスリンクなど）でチェーン間で通信されます。 ビーコン チェーン、またはクロスシャード トランザクション）、次の期間があります。 正直な validator であれば、ブロックが無効であるという証拠を提供できます。そこに ブロックが存在するという非常に簡潔な証明を可能にするさまざまな構造です。 無効であるため、受信ノードの通信オーバーヘッドははるかに小さくなります。 フルブロックを受信するよりも。 このアプローチは、少なくとも 1 つの正直な validator が存在する限り、 シャード、システムは安全です。 図 10: 漁師 これは、現在提案されているプロトコルの中で (問題が存在しないふりをすることを除けば) 主流のアプローチです。 ただし、このアプローチには次の 2 つの点があります。 主な欠点: 1. 正直な validator にとって、チャレンジ期間は十分に長い必要があります ブロックが生成されたことを認識し、ダウンロードし、完全に検証し、準備する ブロックが無効な場合のチャレンジ。 このような期間を導入すると、 シャード間のトランザクションが大幅に遅くなります。 2. チャレンジプロトコルの存在が新たな攻撃ベクトルを生み出す 悪意のあるノードが無効なチャレンジでスパムを送信した場合。明らかな解決策 この問題には、挑戦者にある程度の token を預けさせる必要があります。 チャレンジが有効な場合は返されます。これは部分的な解決策にすぎません。 敵対者がシステムにスパムを送信する（そして焼き付ける）ことが依然として有益である可能性があります。 デポジット) に無効なチャレンジが含まれる場合 (たとえば、有効なチャレンジを防ぐため)正直な validator からの挑戦です。これらの攻撃は、 グリービングアタックと呼ばれます。 後者の点を回避する方法については、セクション 3.7.2 を参照してください。 2.4 知識に関する簡潔な非対話型議論 複数のシャードの破損に対する 2 番目の解決策は、特定の計算 (たとえば、 トランザクションのセットからブロックを計算するなど) は正しく実行されました。 このような構造は実際に存在します。 zk-SNARK、zk-STARK、その他いくつか、 一部は今日、プライベートな支払いのためにblockchainプロトコルで積極的に使用されています。 最も注目すべきはZCashです。このようなプリミティブの主な問題は、 計算が遅いことで有名です。例えば。 zk-SNARK を使用する Coda プロトコル 特に、blockchain 内のすべてのブロックが有効であることを証明するためであると、ある論文では述べられています。 証拠を作成するのに 1 件の取引につき 30 秒かかる可能性があるというインタビューの結果 (この数字はおそらく今ではもっと小さくなっているでしょう)。 興味深いことに、証明は信頼できる当事者によって計算される必要はありません。 この証明は、その目的で構築された計算の正当性を証明するだけでなく、 証明そのものの有効性。したがって、そのような証明の計算は分割できます。 冗長性が従来よりも大幅に低い参加者のセットの間で行われます。 トラストレス計算を実行するために必要です。参加者も可能です zk-SNARK を計算して、特殊なハードウェア上で実行するために、 システムの分散化。 zk-SNARK には、パフォーマンス以外にも次のような課題があります。 1. 研究が少なく、テストもあまり行われていない暗号プリミティブへの依存。 2. 「有毒廃棄物」 — zk-SNARK は、グループが連携する信頼できるセットアップに依存しています。 の人々が何らかの計算を実行し、中間計算を破棄します。 その計算の値。手続き参加者全員が共謀した場合 中間値を保持すると、偽の証明を作成できます。 3. システム設計に余分な複雑さが導入される。 4. zk-SNARK は可能な計算のサブセットに対してのみ機能するため、プロトコル チューリング完全な smart contract 言語では使用できません チェーンの正当性を証明するためのSNARK。 2.5 データの可用性 2 番目の問題については、データの可用性について触れます。一般にノード 特定の blockchain を操作するノードは、フル ノード、 すべての完全なブロックをダウンロードし、すべてのトランザクションを検証するものと、ライト ブロックヘッダーのみをダウンロードし、パーツにマークル証明を使用するノード 図 11 に示すように、関心のある状態とトランザクションを確認します。

図 11: マークルツリー フルノードの大多数が結託した場合、有効または無効のブロックを生成できるようになりました。 無効であり、その hash をライト ノードに送信しますが、完全な内容は決して公開しないでください ブロックの。そこから利益を得ることができるさまざまな方法があります。たとえば、 図 12 を考えてみましょう。 図 12: データの可用性の問題 3 つのブロックがあります。前の A は、正直な validators によって生成されます。 現在の B には validator が共謀しています。そして次のCも生産されます 正直なvalidatorsによるものです（blockchainは右下隅に描かれています）。 あなたは商人です。現在のブロック (B) の validator がブロックを受信しました 以前の validator から、お金を受け取るブロックを計算しました。そして、そのブロックのヘッダーを状態のマークル証明とともに送信しました。 お金を持っていること（またはお金を送金する有効な取引のマークル証明） あなたへ）。取引が完了したと確信してサービスを提供してください。 ただし、validator はブロック B の完全なコンテンツを配布することはありません。 誰でも。そのため、ブロック C の正直な validator はブロックを取得できません。 システムを停止させるか、A の上に構築することを強いられ、 お金の商人。 同じシナリオをシャーディングに適用すると、フルとシャーディングの定義は次のようになります。 ライト ノードは通常、シャードごとに適用されます: 各シャードの validators のダウンロード間隔 そのシャード内でブロックし、そのシャード内のすべてのトランザクションを検証しますが、その他の システム内のノード (スナップショット シャード チェーンの状態を含むノードも含む) ビーコン チェーンでは、ヘッダーのみをダウンロードします。したがって、シャード内の validator は次のようになります。 そのシャードのノードが効率的にフルになる一方で、システム内の他の参加者は、 ビーコンチェーンを含め、ライトノードとして動作します。 上で説明した漁師のアプローチが機能するには、正直なvalidators ビーコンチェーンにクロスリンクされたブロックをダウンロードできる必要があります。 悪意のある validator が無効なブロックのヘッダーをクロスリンクした場合 (またはそれを使用した場合) クロスシャードトランザクションを開始します）が、ブロックを配布することはありませんでした。 validator には課題を作成する方法がありません。 この問題に対処するための 3 つのアプローチを説明します。 お互いに。 2.5.1 保管証明 解決すべき最も差し迫った問題は、ブロックが一度利用できるかどうかです。 それは出版されています。 提案されたアイデアの 1 つは、いわゆる公証人を交代で配置することです。 シャード間での使用頻度は、 ブロックして、ダウンロードできたという事実を証明します。それらは可能です 状態全体をダウンロードする必要がないため、より頻繁にローテーションされます 頻繁にローテーションできない validator とは異なり、シャードの 図に示すように、シャードが回転するたびにシャードの状態をダウンロードする必要があります 13. この素朴なアプローチの問題は、後で証明することが不可能であることです。 公証人がブロックをダウンロードできたかどうかにかかわらず、公証人は ブロックをダウンロードすることなくブロックをダウンロードできたことを常に証明することを選択できます。 それを取り戻そうとしたとしても。これに対する解決策の 1 つは、公証人が提供するものです。 ブロックがあったことを証明する何らかの証拠、またはある程度の token を賭ける ダウンロードされました。そのようなソリューションの 1 つがここで説明されています: https://ethresear.ch/t/ 1 ビット アグリゲーションに優しいカストディ ボンド/2236。 2.5.2 消去コード 特定のライト ノードがブロックの hash を受信すると、ノードの ブロックが利用可能であるという確信があれば、いくつかのランダムなダウンロードを試みることができます ブロックの破片。これは完全な解決策ではありません。 悪意のあるブロック作成者が選択できるブロック全体をまとめてダウンロードする

図 13: バリデーターは状態をダウンロードする必要があるため、ローテーションできません 頻繁に ライトノードによってダウンロードされなかったブロックの部分を差し控えるため、 したがって、ブロックは引き続き使用できなくなります。 1 つの解決策は、イレイジャー コードと呼ばれる構造を使用して、それを可能にすることです。 図に示すように、ブロックの一部しか利用できない場合でも、ブロック全体を復元するには 図 14 に示します。 図 14: Merkle tree イレイジャーコーディングされたデータの上に構築 Polkadot と Ethereum Serenity は両方とも、このアイデアに基づいた設計を行っています。 ライトノードがブロックが利用可能であることを十分に確信できる方法を提供します。 Ethereum Serenity アプローチについては、[2] で詳しく説明されています。2.5.3 Polkadot のデータ可用性に対するアプローチ Polkadot では、ほとんどのシャード ソリューションと同様に、各シャード (パラチェーンと呼ばれます) がそのブロックのスナップショットをビーコン チェーン (リレー チェーンと呼ばれます) に作成します。 2f + 1があるとします。 リレーチェーン上のvalidator。パラチェーンブロックのブロックプロデューサーは、と呼ばれます コレーターは、パラチェーン ブロックが生成されると、任意の f 部分が十分になるように、2f +1 個の部分で構成されるブロックの消失符号化バージョンを計算します。 ブロックを再構築します。次に、各 validator に 1 つのパートを配布します。 リレーチェーン。特定のリレー チェーン validator はリレー チェーンにのみ署名します スナップショットが作成される各パラチェーン ブロックのパートがある場合は、ブロックします。 そんなリレーチェーンブロック。したがって、リレー チェーン ブロックに 2f + 1 からの署名がある場合、 validator 件、そのうち f 件以下がプロトコルに違反しない限り、それぞれ パラチェーン ブロックは、validators からパーツをフェッチすることで再構築できます。 プロトコルに従うもの。図 15 を参照してください。 図 15: Polkadot のデータの可用性 2.5.4 長期的なデータの可用性 上で説明したすべてのアプローチは、ブロックが すでに出版されており、現在も入手可能です。ブロックは後で使用できなくなる可能性があります さまざまな理由で: ノードがオフラインになる、ノードが意図的に履歴を消去する データ、その他。 この問題に対処する注目に値するホワイトペーパーは、Polyshard [3] です。 これは消去コードを使用して、複数のシャードが存在する場合でもブロックをまたがって利用できるようにします。 シャードはデータを完全に失います。残念ながら、彼らの具体的なアプローチには次のことが必要です すべてのシャードが他のすべてのシャードからブロックをダウンロードすることは法外です 高価な。 長期的な可用性は、参加者がいないため、それほど差し迫った問題ではありません。 システムでは、すべてのチェーンのすべてを検証できることが期待されます。

シャードの場合、シャード プロトコルのセキュリティは次のように設計する必要があります。 たとえ一部のシャード内の古いブロックが壊れたとしてもシステムが安全である方法 完全に利用不可。

Nightshade

3.1 シャードチェーンからシャードチャンクへ シャード チェーンとビーコン チェーンを使用したシャーディング モデルは非常に強力ですが、 にはある種の複雑さがあります。特に、フォーク選択ルールを実行する必要があります。 各チェーンで個別に、シャード チェーンとビーコンでのフォーク選択ルール チェーンは別々に構築し、個別にテストする必要があります。 Nightshade では、システムを単一の blockchain としてモデル化します。 ブロックにはすべてのシャードのすべてのトランザクションが論理的に含まれており、 すべてのシャードの全体状態。ただし、物理的には、参加者は誰もダウンロードしません。 完全な状態または完全な論理ブロック。代わりに、ネットワークの各参加者のみが トランザクションを検証するシャードに対応する状態を維持し、ブロック内のすべてのトランザクションのリストが物理的なトランザクションに分割されます。 チャンク、シャードごとに 1 つのチャンク。 理想的な条件下では、各ブロックにはシャードごとに 1 つのチャンクが含まれます。 ブロック。これは、シャード チェーンを含むモデルにほぼ対応します。 シャード チェーンは、ビーコン チェーンと同じ速度でブロックを生成します。ただし、 ネットワークの遅延により、一部のチャンクが欠落している可能性があるため、実際には各ブロックが欠落している可能性があります。 シャードごとに 1 つまたはゼロのチャンクが含まれます。方法の詳細については、セクション 3.3 を参照してください。 ブロックが生成されます。 図 16: 左側にシャード チェーンがあり、1 つのチェーンが 右側のブロックに分割されたブロック

3.2 コンセンサス 今日のblockchainのコンセンサスへの主要なアプローチは 2 つあります。 最も長い (または最も重い) チェーン。その中で最も多くの作業またはステークを持つチェーン ビルドに使用されたものは正規とみなされ、BFT ではブロックごとにいくつかの validator のセットが BFT のコンセンサスに達しました。 最近提案されたプロトコルでは、後者のアプローチがより有力です。 これは即時的な最終性を提供しますが、最長のチェーンではより多くのブロックが必要となるためです。 ファイナリティを保証するためにブロックの上に構築されます。多くの場合、意味のあることを目的として セキュリティ上、十分な数のブロックが構築されるまでに時間がかかります。 時間の順序。 各ブロックで BFT コンセンサスを使用すると、次のような欠点もあります。 1. BFT コンセンサスにはかなりの量のコミュニケーションが必要です。その間 最近の進歩により、数の点で直線的な時間内に合意に達することが可能になりました 参加者の数 (例: [4] を参照) であっても、ブロックあたりのオーバーヘッドは依然として顕著です。 2. すべてのネットワーク参加者が BFT に参加することは不可能です。 したがって、通常はランダムに抽出された参加者のサブセットのみがコンセンサスに達します。ランダムにサンプリングされたセットは、原則として次のようになります。 適応的に破損し、理論上はフォークが作成される可能性があります。システム どちらもそのようなイベントに備えてモデル化する必要があるため、 BFT コンセンサス以外にフォーク選択ルールがある、またはシャットダウンするように設計されている このようなイベントでダウンします。いくつかのデザインについて言及する価値があります。 Algorand [5] により、適応型破損の可能性が大幅に減少します。 3. 最も重要なのは、次の場合にシステムが停止することです。 参加者全員のうち3名以上が オフライン。したがって、一時的なネットワーク障害やネットワークの分裂により、システムが完全に停止する可能性があります。理想的には、システムは継続的に動作できる必要があります。 参加者の少なくとも半数がオンラインである限り動作します (最も重い チェーンベースのプロトコルは、参加者の半分未満がオンラインであっても動作し続けますが、この特性が望ましいかどうかについては議論の余地があります。 コミュニティ内）。 使用されるコンセンサスが最も重いものであるハイブリッド モデル チェーンですが、一部のブロックはBFT フィナリティ ガジェットを使用して定期的にファイナライズされ、両方のモデルの利点が維持されます。このようなBFT フィナリティ ガジェットは、 Ethereum 2.0 8、Casper CBC で使用される Casper FFG [6] (https://vitalik. を参照) ca/general/2018/12/05/cbc_casper.html) および GRANDPA (https:// を参照) Medium.com/polkadot-network/d08a24a021b5) Polkadot で使用されます。 Nightshade は最も重いチェーンのコンセンサスを使用します。 特にブロックのとき プロデューサーはブロックを生成し (セクション 3.3 を参照)、ブロックから署名を収集できます。 他のブロックプロデューサーと前のブロックを証明するvalidator。セクションを参照 このような多数の署名がどのように集約されるかについては、3.8 を参照してください。重量 8Casper の詳細な概要については、Justin Drake とのホワイトボード セッションもご覧ください。 FFG、およびそれが GHOST の最も重いチェーンのコンセンサスとどのように統合されるかについては、こちらをご覧ください: https://www. youtube.com/watch?v=S262StTwkmoブロックの賭け金は、署名が行われたすべての署名者の累積賭け金となります。 ブロックに含まれています。チェーンの重みはブロックの重みの合計です。 最も重いチェーンのコンセンサスの上に、次のようなフィナリティ ガジェットを使用します。 ブロックを完成させるための証明書。システムの複雑さを軽減するには、 フォーク選択ルールにまったく影響を与えないフィナリティ ガジェットを使用します。 その代わりに、ブロックが一度ブロックされると、追加のスラッシュ条件が導入されるだけです。 フィナリティ ガジェットによってファイナライズされるため、よほど大きなパーセンテージが得られない限りフォークは不可能です 賭け金の合計が削減されます。 Casper CBC は非常にフィナリティの高いガジェットであり、 現在、Casper CBC を念頭に置いたモデルです。 また、TxFlow と呼ばれる別の BFT プロトコルにも取り組んでいます。当時 この文書を書いている時点では、Casper の代わりに TxFlow が使用されるかどうかは不明です CBC。ただし、フィナリティ ガジェットの選択は設計の残りの部分とほぼ直交していることに注意してください。 3.3 ブロック生産 Nightshade には、ブロック プロデューサーと validator という 2 つの役割があります。 いずれにしても システムには w ブロックプロデューサーが含まれている点、モデルでは w = 100、および wv validators、私たちのモデルでは v = 100、wv = 10,000。システムはプルーフ・オブ・ステークです。 つまり、ブロックプロデューサーとvalidatorの両方がいくつかの内部 通貨 (「tokens」と呼ばれます) は、 チェーンの構築と検証という職務の遂行に費やす時間。 すべての Proof of Stake システムと同様、すべての W ブロックプロデューサーがブロックするわけではありません。 それを強制することはできないため、すべての wv validator は異なるエンティティになります。それぞれ ただし、w ブロックプロデューサーと wv validator には別個の 賭け金。 システムには n 個のシャードが含まれており、このモデルでは n = 1000 です。で述べたように セクション 3.1 で説明したように、Nightshade にはシャード チェーンはなく、代わりにすべてのブロック プロデューサーと validator が単一の blockchain を構築しています。 メインチェーン。メインチェーンの状態は n 個のシャードに分割され、各ブロックは プロデューサーと validator は、現時点では、ローカルにダウンロードしたのは、 シャードの一部のサブセットに対応し、プロセスとのみに対応する状態 州のこれらの部分に影響を与えるトランザクションを検証します。 ブロックプロデューサーになるために、ネットワークの参加者はいくつかの大きなロックを行います。 token の金額 (ステーク)。ネットワークのメンテナンスはエポック単位で行われます。 ここで、エポックは数日程度の期間です。 参加者 特定のエポックの開始時に最大の賭け金が得られるブロックは、 その時代のプロデューサー。各ブロックプロデューサーは sw シャードに割り当てられます (たとえば、 sw = 40、これにより、sww/n = 4 シャードあたりのブロックプロデューサーになります）。ブロック プロデューサーは、エポック以前に割り当てられているシャードの状態をダウンロードします。 が開始され、エポック全体を通じてそのシャードに影響を与えるトランザクションを収集します。 そしてそれらを状態に適用します。 メインチェーン上の各ブロック b およびすべてのシャード s には、次のいずれかが存在します。 b に関連する部分を生成する責任がある s にブロック生成者を割り当てます。 シャードに。シャード s に関連する b の部分はチャンクと呼ばれ、 b に含まれるシャードのトランザクションのリストとマークル結果の状態のルート。 b には最終的には非常に小さなヘッダーのみが含まれます。 チャンク、つまり適用されたすべてのトランザクションのマークル ルート (セクションを参照) 正確な詳細については 3.7.1 を参照)、最終状態のマークル ルート。 ドキュメントの残りの部分では、ブロック プロデューサーについてよく言及します。 特定のシャードに対して特定の時間にチャンクを生成する役割を果たします。 チャンクプロデューサーとして。チャンクプロデューサーは常にブロックプロデューサーの 1 つです。 ブロックプロデューサーとチャンクプロデューサーは、次のように各ブロックをローテーションします。 固定スケジュールに。ブロックプロデューサーは命令を受けて繰り返し生産します。 この順序でブロックします。 例えば。 ブロックプロデューサーが 100 人いる場合、最初のブロック プロデューサーはブロック 1、101、201 などの生成を担当し、2 番目はブロックです。 2、102、202など）の制作を担当。 チャンク生成はブロック生成と異なりメンテナンスが必要となるため、 状態、および各シャードについてのみ sww/n ブロックプロデューサーが状態を維持します シャードごとに、それに対応して、それらの sww/n ブロックプロデューサーのみがローテーションして作成されます。 塊。例えば。上記の定数と 4 つのブロック プロデューサーが割り当てられたもの 各シャード、各ブロックプロデューサーは 4 ブロックごとにチャンクを作成します。 3.4 データの可用性を確保する データの可用性を確保するために、Polkadot と同様のアプローチを使用します。 セクション 2.5.3 で説明されています。ブロックプロデューサーがチャンクを生成すると、 の最適な (w, ⌊w/6 + 1⌋) ブロック コードを使用したその消失符号化バージョン チャンク。 次に、消去符号化されたチャンクの 1 つの部分を送信します (このような部分を チャンク部分、または部分のみ）を各ブロックプロデューサーに送信します。 すべての部分を葉として含むマークル ツリーを計算します。 各チャンクのヘッダーには、そのようなツリーのマークル ルートが含まれます。 パーツは onepart メッセージを介して validator に送信されます。そういったメッセージ一つ一つが チャンクヘッダー、パートの序数、およびパートの内容が含まれます。の メッセージには、ブロックを作成したブロックプロデューサーの署名も含まれています。 チャンクとその部分がヘッダーに対応することを証明するマークル パス 適切なブロックプロデューサーによって生成されます。 ブロックプロデューサーがメインチェーンブロックを受け取ると、まず、それらがメインチェーンブロックであるかどうかを確認します。 ブロックに含まれるチャンクごとに 1 つのパート メッセージが含まれます。そうでない場合はブロック 欠落している onepart メッセージが取得されるまで処理されません。 すべての onepart メッセージが受信されると、ブロックプロデューサーは 残りの部分をピアから取得し、ピアが保持するチャンクを再構築します。 状態。 少なくとも 1 つのメイン チェーン ブロックの場合、ブロック プロデューサーはメイン チェーン ブロックを処理しません。 ブロックに含まれるチャンクに対応する onepart メッセージがない場合、または状態を維持する少なくとも 1 つのシャードについては、 チャンク全体を再構築します。 特定のチャンクを利用可能にするには、ブロックの ⌊w/6⌋+1 だけで十分です 生産者は自分の役割を持ち、それを提供します。したがって、その数が続く限り、 悪意のあるアクターは ⌊w/3⌋ ブロックの半分を超えるチェーンを超えない それを構築するプロデューサーは、使用できないチャンクを持つ可能性があります。図 17: 各ブロックにはシャードごとに 1 つまたはゼロのチャンクが含まれており、各チャンクには 消去符号化されています。 Erasure Code チャンクの各部分は、指定されたアドレスに送信されます。 特別な onepart メッセージを介してプロデューサーをブロックする 3.4.1 遅延ブロックプロデューサーへの対処 ブロックプロデューサーに onepart メッセージが欠落しているブロックがある場合、 ブロックがチェーン上に存在することになった場合、まだ署名することを選択する可能性があります。 ブロックプロデューサーの報酬を最大化します。ブロックのリスクはありません ブロックプロデューサーが持っていなかったことを後で証明することは不可能であるため、プロデューサー ワンパートメッセージ。 これに対処するために、チャンクを作成するときに各チャンクをプロデューサーにします。 今後エンコードされるチャンクの各部分の色 (赤または青) を選択し、保存します エンコード前のチャンク内の割り当てられた色のビットマスク。それぞれのパート メッセージにはパーツに割り当てられた色が含まれており、その色は次の場合に使用されます。 エンコードされた部分のマークルルートを計算します。チャンクプロデューサーが外れると プロトコルから、マークルルートが存在しないため、それは簡単に証明できます。 onepart メッセージ、または onepart メッセージの色に対応します。 マークル ルートに対応するものは、チャンク内のマスクとは一致しません。 ブロックプロデューサーがブロックに署名するとき、すべてのブロックのビットマスクが含まれます。 ブロックに含まれるチャンクとして受け取った赤い部分。の出版 不正なビットマスクはスラッシュ可能な動作です。ブロックプロデューサーが 一部のメッセージでは、メッセージの色を知る方法がありません。 したがって、彼らが盲目的に署名しようとすると、切りつけられる可能性が50％あります。 ブロック。 3.5 状態遷移アプリケーション チャンクプロデューサーは、チャンクに含めるトランザクションを選択するだけですが、 チャンクを生成するときに状態遷移を適用しません。これに対応して、

チャンクヘッダーには、以前のメルケル化状態のマークルルートが含まれます チャンク内のトランザクションが適用されます。 トランザクションは、チャンクを含む完全なブロックが存在する場合にのみ適用されます。 処理されます。参加者は次の場合にのみブロックを処理します。 1. 前のブロックが受信され、処理されました。 2. 各チャンクについて、参加者はその状態を維持しません。 onepart メッセージを確認しました。 3. 各チャンクについて、参加者は状態を維持します。 完全なチャンク。 ブロックが処理されると、参加者が参加するシャードごとに 状態を維持し、トランザクションを適用して新しい状態を計算します トランザクションが適用された後の時点で、トランザクションを生成する準備が整います。 次のブロックのチャンク（シャードに割り当てられている場合）。 新しいメルケル化国家のマークルルート。 3.6 クロスシャードトランザクションと領収書 トランザクションが複数のシャードに影響を与える必要がある場合は、連続して影響を与える必要があります。 各シャードで個別に実行されます。トランザクション全体が最初のシャードに送信されます 影響を受け、トランザクションがそのようなシャードのチャンクに含まれると、 チャンクがブロックに含まれた後に適用され、いわゆるレシートが生成されます。 トランザクション。トランザクションが必要な次のシャードにルーティングされます。 処刑される。さらに多くの手順が必要な場合は、受領トランザクションの実行 新しい領収書トランザクションなどを生成します。 3.6.1 受信トランザクションの有効期間 レシートトランザクションは、それが生成されたブロックの直後のブロックで適用されることが望ましい。受け取り取引のみです 前のブロックがブロックプロデューサーによって受信および適用された後に生成されます 元のシャードを維持しており、 次のブロックのチャンクは宛先のブロックプロデューサーによって生成されます 破片。したがって、受領書はソースシャードからシャードに通信される必要があります。 これら 2 つのイベントの間の短い時間枠で宛先シャードを作成します。 A を、レシート r を生成するトランザクション t を含む、最後に生成されたブロックであるとします。 B を次に生成されるブロック (つまり、A を持つブロック) とします。 その前のブロック)、r を含めたいとします。 t をシャード a と r に含めます。 シャード内 b. 図 18 にも示されているレシートの有効期間は次のとおりです。 領収書の作成と保管。シャードのチャンクプロデューサーの CPA a はブロック A を受け取り、トランザクション t を適用し、レシート r を生成します。公認会計士 次に、作成されたすべてのレシートをインデックス付きの内部永続ストレージに保存します。 ソースシャードIDによって異なります。領収書を配布します。 CPA がチャンクを生成する準備ができたら、 ブロック B のシャード a、ブロック A からシャード a のトランザクションを適用することによって生成されたすべてのレシートをフェッチし、それらをシュラッドのチャンクに含めます。 ブロック B 内の a。そのようなチャンクが生成されると、cpa はその消去符号化を生成します。 バージョンと、対応するすべての onepart メッセージ。 cpa は、どのブロックプロデューサーがどのシャードの完全な状態を維持しているかを知っています。特定のブロックプロデューサーの場合 bp cpa には、ブロック A のトランザクションを適用した結果生じた入金が含まれます bp が宛先として気にしているシャードのいずれかを含むシャード a の場合 ブロック B のシャード a のチャンクを配布したときの onepart メッセージ内 (onepart メッセージに含まれるレシートを示す図 17 を参照)。 領収書の受け取り。参加者 (ブロック プロデューサーと validator の両方) は、onepart メッセージを取得するまでブロックを処理しないことに注意してください。 ブロックに含まれるチャンクごとに。したがって、特定の参加者がブロック B を適用するまでに、参加者は、以下に対応するすべての onepart メッセージを取得します。 B にチャンクがあるため、シャードを含むすべての受信レシートが存在します。 参加者は目的地としての状態を維持します。 適用するときは、 特定のシャードの状態遷移の場合、参加者は両方のレシートを適用します onepart メッセージ内のシャード用に収集したものと、すべての チャンク自体に含まれるトランザクション。 図 18: 領収書トランザクションの有効期間 3.6.2 多すぎる領収書の処理 特定のシャードをターゲットとする受信の数が、 特定のブロックが大きすぎて処理できません。たとえば、図 19 を考えてみましょう。 各シャードの各トランザクションは、シャード 1 を対象とするレシートを生成します。 次のブロックまでに、シャード 1 が処理する必要があるレシートの数は次のとおりです。 処理中にすべてのシャードが結合して処理された負荷に相当します 前のブロック。

図 19: すべてのレシートが同じシャードをターゲットにしている場合、シャードには それらを処理する能力 これに対処するために、QuarkChain 9 で使用されているのと同様の技術を使用します。 具体的には、各シャードの最後のブロック B とその中の最後のシャード s レシートが適用されたブロックが記録されます。新しいシャードが作成されるとき 作成されると、レシートは B の残りのシャードから順に適用されます。 次に、B に続くブロックで、新しいチャンクがいっぱいになるまで続けます。正常時 バランスのとれた負荷がある状況では、通常、すべての受信が発生します。 適用されます (したがって、最後のブロックの最後のシャードが記録されます) 各チャンク)、負荷のバランスが取れていない時間帯、および特定の シャードは不釣り合いに多くのレシートを受け取りますが、このテクニックにより、シャードは次のことが可能になります。 含まれるトランザクション数の制限を尊重しながら処理されます。 このような偏荷重が長時間続くと、 アプリケーションが無限に成長し続けるまで、レシートの作成は行われません。 1 つ これに対処する方法は、 ある定数 (1 エポックなど) を超える処理遅延があるシャード。 図 20 を考えてみましょう。ブロック B により、シャード 4 はすべてのレシートを処理できなくなります。 したがって、ブロック A のシャード 3 までの受信のみを処理します。 それを記録します。ブロック C には、ブロック B のシャード 5 までのレシートが含まれており、 その後、ブロック D までにシャードが追いつき、残りのすべてのレシートを処理します。 ブロック B とブロック C からのすべてのレシート。 3.7 チャンクの検証 特定のシャード用に生成されたチャンク (またはシャード チェーンを含むモデル内の特定のシャード チェーン用に生成されたシャード ブロック) は、 9QuarkChainを使用したホワイトボードのエピソードはこちらでご覧ください: https://www.youtube.com/watch? v=opEtG6NM4x4: クロスシャード トランザクションへのアプローチなどが説明されています。 物図 20: 領収書の処理が遅れている 状態を維持する参加者。これらはブロックプロデューサー、validators、 または、状態をダウンロードしてシャードを検証した外部の証人だけ 彼らは資産を保管します。 この文書では、参加者の大多数がデータを保存できないことを想定しています。 シャードの大部分の状態。ただし、言及する価値があります。 次のことを前提として設計されたシャード化された blockchain が存在すること ほとんどの参加者は、ほとんどの状態を保存し、検証する能力を持っています。 QuarkChain などのシャード。 参加者の一部だけがシャードを検証する状態を持っているため、 チャンクを持っている参加者だけを適応的に破損させることが可能です。 状態を変更し、無効な状態遷移を適用します。 数回ごとに validator をサンプリングする複数のシャーディング設計が提案されました 2/3 を超えるシャード チェーン内のブロックは 1 日以内に削除されます。 そのようなシャードに割り当てられた validator の署名が直ちに考慮されます 最後。このようなアプローチでは、適応型の敵対者は 2n/3+1 を破壊するだけで済みます。 シャード チェーン内の validator の無効な状態遷移を適用します。 実現するのは難しいと思われますが、一般の人々にとってセキュリティのレベルは十分ではありません blockchain。 セクション 2.3 で説明したように、一般的なアプローチは、状態 (状態に関係なく) を持つ参加者に対してブロックが作成された後、一定の時間枠を許可することです。 それはブロックプロデューサー、validator、または外部オブザーバーです) の正当性に異議を唱えます。このような参加者はフィッシャーマンと呼ばれます。漁師ができるようになるためには、 無効なブロックに異議を唱える場合は、そのようなブロックが利用可能であることを確認する必要があります。 彼ら。 Nightshade でのデータの可用性については、セクション 3.4 で説明します。 Nightshade では、ブロックが生成されると、チャンクは検証されませんでした。 実際のチャンクプロデューサー以外の誰でも。特に、ブロックプロデューサーは、 ブロックには自然にほとんどのシャードの状態が存在しないことを示唆し、チャンクを検証できませんでした。次のブロックが生成されると、そのブロックには複数のブロック生成者の証明書 (セクション 3.2 を参照) と validator が含まれます。 ただし、ブロックプロデューサーとvalidatorの大部分は状態を維持しないため ほとんどのシャードでも、無効なチャンクが 1 つだけあるブロックは、半分以上の認証を収集し、最も重いブロックに残り続けます。 チェーン。 この問題に対処するために、次の状態を維持する参加者を許可します。 シャードで生成された無効なチャンクに対してオンチェーンでチャレンジを送信するためのシャード 破片。 3.7.1 状態の有効性のチャレンジ 参加者が特定のチャンクが無効であることを検出したら、そのチャンクが無効であるという証拠を提供する必要があります。ネットワーク参加者の大多数は、無効なチャンクが含まれるシャードの状態を維持しないため、 証明には、ブロックが正しいことを確認するのに十分な情報が必要です。 状態がなければ無効です。 単一トランザクションが実行できる状態量 (バイト単位) の制限 Ls を設定します。 累積的に読み取りまたは書き込みができます。 Ls を超えるトランザクション 状態は無効とみなされます。セクション 3.5 で述べたチャンクを思い出してください。 特定のブロック B には、適用されるトランザクションのみが含まれますが、 新しい状態のルート。ブロック B のチャンクに含まれるステート ルートはステートです。 そのようなトランザクションを適用する前、ただしトランザクションを適用した後は root にアクセスします。 同じシャード内のブロックの前の最後のチャンク B. 悪意のある攻撃者 無効な状態遷移を適用しようとすると、不正な状態ルートが含まれる可能性があります 適用の結果生じるステートルートに対応しないブロック B 内 前のチャンク内のトランザクション。 チャンクプロデューサーがチャンクに含める情報を拡張します。 すべてのトランザクションを適用した後の状態を単に含めるのではなく、 連続する各トランザクション セットを適用した後の状態ルートが含まれます。 Ls バイトの状態をまとめて読み書きします。 この情報をもとに、 漁師は、状態遷移が誤って適用されるという課題を作成します。 最初の無効な状態ルートを見つけて、その Ls バイトだけを含めるには十分です。 最後のステート ルート (以前のステート ルート) 間のトランザクションによって影響を受けるステート 有効）とマークル証明付きの現在の状態ルート。その後、参加者全員が セグメント内のトランザクションを検証し、チャンクが有効であることを確認できます。 無効です。 同様に、チャンクプロデューサーが以下のトランザクションを含めようとした場合、 Ls バイトを超える状態を書き込みます。チャレンジには、以下を含めるだけで十分です。 マークル証明と接触する最初の Ls バイト。これで十分です。 トランザクションを適用し、次の処理が実行される瞬間があることを確認します。 Ls バイトを超えるコンテンツの読み取りまたは書き込みが行われます。

3.7.2 漁師と高速クロスシャードトランザクション セクション 2.3 で説明したように、シャード チャンク (またはシャード) が シャード チェーンを含むモデル内のブロック）が無効になり、問題が発生する可能性があります その間、それはフィナリティに悪影響を及ぼし、したがってシャード間の通信に悪影響を及ぼします。で 特に、シャード間トランザクションの宛先シャードは確実ではありません。 元のシャード チャンクまたはブロックは、チャレンジ期間が終了するまで最終的なものとなります (図 21 を参照)。 図 21: レシートを適用する前にチャレンジ期間を待っています クロスシャードトランザクションを行う方法でこれに対処する方法 瞬時とは、宛先シャードがチャレンジ期間を待たないことです。 ソースシャードトランザクションが公開された後、レシートトランザクションを適用します すぐにロールバックしますが、その後、ソースシャードとともに宛先シャードをロールバックします。 元のチャンクまたはブロックが後で無効であることが判明した場合のシャード (図を参照) 22）。これは、シャードが含まれる Nightshade のデザインにも非常に自然に当てはまります。 チェーンは独立していませんが、代わりにシャード チャンクがすべて公開されます 同じメインチェーンブロック内に一緒に。いずれかのチャンクが無効であることが判明した場合、 そのチャンクを含むブロック全体が無効とみなされ、その上に構築されたすべてのブロックが無効と見なされます。 その頂上。図 23 を参照してください。 上記のアプローチは両方とも、チャレンジを前提としてアトミック性を提供します。 期間が十分に長い。通常の状況下では高速なクロスシャード トランザクションを提供する方が不便さを上回るため、後者のアプローチを使用します。 いずれかの無効な状態遷移により、宛先シャードがロールバックします。 ソースシャード、これは非常にまれなイベントです。 3.7.3 validator を非表示にしています 課題の存在により、すでに次のような可能性が大幅に減少しています。 無効な状態遷移ポストでチャンクを終了するため、適応的な破損が発生します。図 22: 領収書をただちに適用し、宛先をロールバックする ソースチェーンに無効なブロックがあった場合はチェーン 図 23: ナイトシェイドでの漁師チャレンジ 適応的な敵対者がすべての参加者を堕落させるために必要なチャレンジ期間 すべての validator を含む、シャードの状態を維持するもの。 このようなイベントが発生する可能性を推定することは非常に複雑です。 シャード化された blockchain は、そのような攻撃が試行されるのに十分な期間存続しています。我々は、その可能性は極めて低いとはいえ、それでも十分にあると主張する。 数百万のトランザクションを実行することが予想されるシステムとしては大規模であり、 世界規模の金融業務を運営します。 この考えには主に 2 つの理由があります。 1. Proof-of-Stake チェーンおよびマイナーの validator のほとんど

Proof-of-Work チェーンは主に財務上の好転によって奨励されます。もし 適応的な敵対者は、期待される利益よりも多くの資金を提供します 正直に動作することから、多くの validator が発生することが予想されます。 申し出を受け入れるでしょう。 2. 多くの企業が Proof-of-Stake チェーンの検証を専門的に行っており、 どのチェーンでも株式の大部分が そのような実体から。そのようなエンティティの数は、 適応的な敵対者として、彼らのほとんどを個人的に知り、 彼らが腐敗する傾向があることをよく理解しています。 どの validator がどのシャードに割り当てられているかを非表示にすることで、適応型破損の可能性を減らすためにさらに一歩進んでいます。アイデアは Algorand [5] が validator を隠す方法とほぼ同じです。 Algorand のように、validator が隠蔽されている場合でも注意することが重要です。 あるいは、以下で説明するように、適応的な破損は理論的には依然として可能です。その間 適応型の敵対者は、作成または検証する参加者を知りません。 ブロックでもチャンクでも、参加者自身が自分が実行することを知っています。 そのようなタスクを実行し、その暗号による証明を持っています。 したがって、敵は、 腐敗させる意図をブロードキャストし、提供してくれる参加者に報酬を支払う そのような暗号証明。ただし、敵はそうではないため、 破損させたいシャードに割り当てられている validator を知っている場合、 特定のシャードを破壊する意図をブロードキャストする以外に選択肢はありません。 コミュニティ全体。その時点で、正直な人にとっては経済的に有益です。 参加者は、そのシャードを検証する完全なノードをスピンアップします。 そのシャードに無効なブロックが出現する可能性があり、これは チャレンジを作成し、関連する報酬を集めます。 特定のシャードに割り当てられている validator を公開しないようにするには、 以下のとおりです (図 24 を参照)。 VRF を使用して割り当てを取得します。各エポックの開始時にそれぞれ validator は VRF を使用して、validator が割り当てられているシャードのビットマスクを取得します。 各 validator のビットマスクには Sw ビットがあります (定義についてはセクション 3.3 を参照してください) スイス）。次に、validator は対応するシャードの状態をフェッチし、 エポック中に、受信したブロックごとに、対応するチャンクを検証します validator が割り当てられているシャードに。 チャンクではなくブロックにサインオンします。シャードの割り当ては隠蔽されているため、validator はチャンクに署名できません。代わりに、常に全体に署名します ブロックするため、どのシャードを検証するかは明らかにされません。具体的には、validator がブロックを受信してすべてのチャンクを検証すると、メッセージが作成されます。 これは、validator が割り当てられているすべてのシャード内のすべてのチャンクが 有効 (それらのシャードが何であるかをまったく示さずに)、または次のようなメッセージ いずれかのチャンクが無効な場合、無効な状態遷移の証明が含まれます。を参照してください。 このようなメッセージがどのように集約されるかについてはセクション 3.8、詳細についてはセクション 3.7.4 を参照してください。 validators が次からのメッセージに便乗するのを防ぐ方法の詳細 その他のvalidator、および報酬と罰の詳細についてはセクション 3.7.5 を参照してください。 validators は、無効な状態遷移チャレンジが実際に成功した場合に発生します。図 24: Nightshade で validator を隠す 3.7.4 コミットと公開 validators に関する一般的な問題の 1 つは、validator が状態のダウンロードと実際のチャンクとブロックの検証をスキップし、その代わりに ネットワークを観察し、他の validator が送信した内容を確認し、その内容を繰り返します。 メッセージ。このような戦略に従う validator は、追加の機能を提供しません。 ネットワークのセキュリティを確保しますが、報酬も収集します。 この問題の一般的な解決策は、validator ごとに証明を提供することです。 たとえば独自のトレースを提供するなどして、ブロックを実際に検証したこと 状態遷移を適用する必要がありますが、そのような証明はコストを大幅に増加させます 検証の。 図 25: コミットと公開

代わりに、validators を最初に検証結果にコミットします (どちらか チャンクの有効性を証明するメッセージ、または無効であることの証明 状態遷移)、図 25 に示すように、一定期間待機してから初めて実際の検証結果が表示されます。コミット期間は次の期間と交差しません。 公開期間があるため、怠惰な validator は正直な validator をコピーできません。 さらに、不正な validator が、 割り当てられたチャンクの有効性、および少なくとも 1 つのチャンクが無効になった場合 チャンクが無効であることが示されているため、validator はスラッシュを回避できません。 セクション 3.7.5 で示すように、そのような状況で斬られないようにする唯一の方法 無効な状態遷移の証拠を含むメッセージを提示することです。 コミットと一致します。 3.7.5 課題への対処 上で説明したように、validator が無効なチャンクを含むブロックを受信すると、 彼らはまず無効な状態遷移の証明を準備します (セクション 3.7.1 を参照)。 そのような証明に取り組み（3.7.4 を参照）、一定期間後に課題を明らかにします。 公開されたチャレンジがブロックに含まれると、次のことが起こります。 1. を含むブロックから発生したすべての状態遷移。 公開されたチャレンジが含まれるブロックが取得されるまで無効なチャンク 無効化された。公開されたチャレンジを含むブロック前の状態 を含むブロックの前の状態と同じとみなされます。 無効なチャンク。 2. 一定期間内に、各 validator はビットマスクを公開する必要があります 彼らが検証したシャード。ビットマスクは VRF 経由で作成されるため、 それらは無効な状態遷移のあるシャードに割り当てられていました。 それを明らかにすることは避けられない。ビットマスクを明らかにできないvalidator シャードに割り当てられていると想定されます。 3. この期間後にシャードに割り当てられていることが判明した各 validator、 を含むブロックの検証結果にコミットしました。 無効なチャンクであり、無効な状態遷移の証拠は明らかにされませんでした コミットに対応する部分はスラッシュされます。 4. 各 validator には新しいシャードが割り当てられ、新しいエポックがスケジュールされます すべての validator がダウンロードするのに十分な時間が経過した後に開始します。 図 26 に示す状態。 validator が割り当てられたシャードを明らかにした瞬間から注意してください。 新しいエポックが始まるまで、システムのセキュリティは低下します。 シャードの割り当てが明らかになります。ネットワークの参加者はそれを保管する必要があります その間ネットワークをご利用になる際はご注意ください。 3.8 署名の集約 数百のシャードを含むシステムが安全に動作するには、 10,000 validator 以上の注文。セクション 3.7 で説明したように、それぞれが必要です。図 26: 課題への対処 validator 特定のメッセージに対するコミットと署名を平均して公開します ブロックごとに 1 回。たとえコミットメッセージが同じであっても、そのようなメッセージを集約すると、 BLS 署名とその検証には法外な費用がかかるでしょう。でも 当然のことながら、コミット メッセージとリビール メッセージは validator 間で同じではありません。 したがって、そのようなメッセージと署名を 1 つのファイルに集約する何らかの方法が必要です。 これにより、後で迅速に検証できるようになります。 私たちが使用する具体的なアプローチは次のとおりです。 ブロックプロデューサーに参加するバリデーター。ブロックプロデューサーは既知です エポックが始まる少し前に、ダウンロードするのに時間がかかるため、 エポックが開始する前の状態であり、validator とは異なり、ブロックプロデューサーは 隠蔽されていない。各ブロックプロデューサーには v validator スロットがあります。バリデーターが送信する ブロックプロデューサーへのオフチェーンの提案で、ブロックプロデューサーの 1 つとして含めることができます。 validator秒。ブロックプロデューサーがvalidatorを含めたい場合は、 validator からの最初のオフチェーンリクエストを含むトランザクション、および validator をブロック プロデューサーに参加させるブロック プロデューサーの署名。 ブロックプロデューサーに割り当てられた validator は必ずしも ブロックプロデューサーがチャンクを生成するのと同じシャードを検証します。 もし validator は複数のブロックプロデューサーの結合に適用されます。ブロックプロデューサーからのトランザクションのみです。 最初のブロックプロデューサーが成功します。 ブロックプロデューサーはコミットを収集します。ブロック プロデューサーは、validator からコミット メッセージとリビール メッセージを常に収集します。このようなメッセージが一定数蓄積されると、ブロックプロデューサーはマークルを計算します。 これらのメッセージのツリーを作成し、各 validator にマークル ルートと 彼らのメッセージへのマークルパス。 validator はパスを検証し、サインオンします。 マークルルート。次に、ブロックプロデューサーは BLS 署名を validators からマークル ルートを取得し、マークル ルートと 積み上げたサイン。ブロックプロデューサーは、ブロックの有効性にも署名します。 安価な ECDSA 署名を使用したマルチ署名。マルチ署名が機能しない場合 送信されたマークル ルート、または参加している validator のビットマスクと一致する場合、これはスラッシュ可能な動作です。チェーンを同期するとき、参加者は validators からのすべての BLS 署名を検証することを選択できます (validators の公開鍵の集約が必要なため、非常にコストがかかります)、またはのみを検証することもできます。ブロックプロデューサーからの ECDMA 署名を使用し、次の事実に依存します。 ブロックプロデューサーは異議を申し立てられず、切り捨てられました。 オンチェーントランザクションとマークルプルーフをチャレンジに使用します。それ そうでない場合、validators からのメッセージを公開しても意味がないことに注意してください。 無効な状態遷移が検出されました。実際の内容を含むメッセージのみ 無効な状態遷移の証拠は、そのようなメッセージに対してのみ明らかにされる必要があります。 それらが前のコミットと一致することを示す必要があります。メッセージには次のことが必要です 次の 2 つの目的で公開されます。 1. 実際にチェーンのロールバックを開始して、直前の時点に戻します。 無効な状態遷移 (セクション 3.7.5 を参照)。 2. validator が、 無効なチャンクです。 いずれの場合も、次の 2 つの問題に対処する必要があります。 1. 実際のコミットはチェーンに含まれておらず、マークルルートのみがチェーンに含まれていました。 他のメッセージと集約されたコミット。 validator は、 ブロックプロデューサーによって提供されるマークルパスとその元のコミット 彼らがその挑戦に真剣に取り組んでいることを証明します。 2. シャードに割り当てられているすべての validator が無効である可能性があります。 状態遷移は破損したブロックプロデューサーに割り当てられているため、 彼らを検閲しているのだ。それを回避するために、私たちは彼らが公開を提出することを許可します オンチェーン上の通常のトランザクションとして、集約をバイパスします。 後者は、無効な状態遷移の証明にのみ許可されます。 非常にまれであるため、ブロックのスパム送信にはならないはずです。 対処する必要がある最後の問題は、ブロックプロデューサーが次のことを行うことができるということです。 メッセージ集約に参加しないことを選択するか、特定の validator を意図的に検閲します。ブロック化することで経済的に不利になります プロデューサーの報酬は、割り当てられた validator の数に比例します。私たち また、エポック間のブロックプロデューサーが大部分で交差していることにも注意してください（ 常に最も高い賭け金を持つ上位 2 人の参加者です)、validator は次のことができます 同じブロックプロデューサーとの連携にほぼ固執するため、リスクが軽減されます。 過去に検閲を行ったブロックプロデューサーに割り当てられたことについて。 3.9 スナップショットチェーン メインチェーン上のブロックは非常に頻繁に生成されるため、ダウンロード 完全な履歴はすぐに高価になる可能性があります。また、 ブロックには多数の参加者の BLS 署名が含まれており、署名をチェックするための公開鍵の集合だけでも法外な量になる可能性があります。 高価でもあります。 最後に、予見可能な将来において Ethereum 1.0 は 1 のままになる可能性が高いため、 最も使用されている blockchain から資産を転送する有意義な方法を備えています。

Ethereum に近いことが要件であり、現在、BLS 署名を検証して確実にしています。 Ethereum 側のニアブロックの有効性は不可能です。 Nightshade メインチェーンの各ブロックには、オプションで Schnorr を含めることができます。 このような Schnorr を含む最後のブロックのヘッダーの多重署名 マルチシグネチャ。このようなブロックをスナップショット ブロックと呼びます。の最初のブロック すべてのエポックはスナップショット ブロックである必要があります。このようなマルチシグネチャの作業中に、 ブロックプロデューサーは、validators の BLS 署名も蓄積する必要があります。 最後のスナップショット ブロックで、で説明したのと同じ方法でそれらを集計します。 セクション3.8。 ブロックプロデューサーセットはエポック全体を通じて一定であるため、検証 何もしないと仮定すると、各エポックの最初のスナップショット ブロックだけで十分です。 ブロックプロデューサーとvalidatorの大部分が共謀して作成されたことを指摘する フォーク。 エポックの最初のブロックには、計算に十分な情報が含まれている必要があります ブロックプロデューサーとエポックのvalidator。 スナップショットのみを含むメインチェーンのサブチェーンを呼び出します。 スナップショット チェーンをブロックします。 Schnorr マルチ署名の作成は対話型のプロセスですが、 どんなに非効率なプロセスであっても、頻繁に実行するだけで済みます。 十分でしょう。 Schnorr マルチ署名は Ethereum で簡単に検証できます。 したがって、クロスblockchainを安全に実行するための重要なプリミティブが提供されます。 コミュニケーション。 Near チェーンと同期するには、すべてのスナップショットをダウンロードするだけで済みます ブロックし、Schnorr 署名が正しいことを確認し (オプションで validator の個々の BLS 署名も検証します)、同期のみを行います。 最後のスナップショット ブロックからのメイン チェーン ブロック。

結論

このドキュメントでは、シャード化された blockchain を構築するアプローチについて説明しました。 既存のアプローチの 2 つの主要な課題、つまり状態の妥当性をカバーしました。 データの可用性。次に、Nightshade というシャーディング デザインを提案しました。 NEAR プロトコルを強化します。 デザインは進行中です。コメント、質問、フィードバックがありましたら このドキュメントについては、https://near.chat. にアクセスしてください。