状態の有効性とデータの可用性
シャード化された 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] です。 これは消去コードを使用して、複数のシャードが存在する場合でもブロックをまたがって利用できるようにします。 シャードはデータを完全に失います。残念ながら、彼らの具体的なアプローチには次のことが必要です すべてのシャードが他のすべてのシャードからブロックをダウンロードすることは法外です 高価な。 長期的な可用性は、参加者がいないため、それほど差し迫った問題ではありません。 システムでは、すべてのチェーンのすべてを検証できることが期待されます。
シャードの場合、シャード プロトコルのセキュリティは次のように設計する必要があります。 たとえ一部のシャード内の古いブロックが壊れたとしてもシステムが安全である方法 完全に利用不可。
状态有效性和数据可用性
分片 blockchain 的核心思想是大多数参与者操作或 使用网络无法验证所有分片中的块。因此，每当 任何参与者都需要与他们通常无法进行的特定分片进行交互 下载并验证分片的整个历史记录。 然而，分片的分区方面带来了巨大的潜力 问题：没有下载和验证特定的整个历史记录 分片参与者不一定能确定分片的状态 5 除第 2.5.3 小节外，本节先前发布于 https://near.ai/ 碎片2。如果您之前阅读过，请跳至下一部分。
它们相互作用是一些有效的块序列的结果，并且这种序列 区块确实是分片中的规范链。一个不存在的问题 存在于非分片 blockchain 中。 我们首先将针对已提出的这个问题提出一个简单的解决方案 通过许多协议，然后分析这个解决方案如何破坏以及什么 已经尝试解决这个问题。 2.1 验证者轮换 状态有效性的朴素解决方案如图 5 所示：假设我们假设 整个系统有数千个 validator 的数量级，其中 不超过 20% 是恶意的或会失败（例如未能 在线生成区块）。那么如果我们采样 200 validators，概率 超过 1 个 3 出于实际目的，失败可以假设为零。 图5： 采样 validators 1 3是一个重要的门槛。有一系列共识协议，称为 BFT 共识协议，保证只要少于 1 3 个 参与者失败了，要么是崩溃了，要么是以某种违反规则的方式行事 协议，达成共识。 假设诚实的 validator 百分比，如果当前集合 分片中的 validators 为我们提供了一些块，天真的解决方案假设 该块是有效的，并且它是建立在 validator 所认为的基础上的 当他们开始验证时该分片的规范链。 validators 从前一组 validator 中学习了规范链，它们由相同的 假设建立在作为规范链头部的区块之上 在那之前。通过归纳，整个链都是有效的，并且因为没有 validator 集合 在任何产生分叉的点，简单的解决方案也可以确定当前 chain 是分片中唯一的链。可视化见图 6。
图6： 每个区块都通过 BFT 共识最终确定的 blockchain 如果我们假设 validators 可以是 自适应地损坏，这不是一个不合理的假设6。适应性地 损坏具有 1000 个分片的系统中的单个分片的成本要低得多 而不是破坏整个系统。因此，协议的安全性随着分片数量的增加而线性下降。确定其有效性 一个区块，我们必须知道，在历史上的任何时刻，系统中都没有分片 大多数 validator 串通一气；有了适应性强的对手，我们不再有 这样的确定性。正如我们在 1.5 节中讨论的，串通 validators 可以行使 两种基本的恶意行为：创建分叉和产生无效区块。 恶意分叉可以通过与信标链交叉链接的区块来解决，信标链通常被设计为具有比信标链更高的安全性 分片链。 然而，产生无效块是一个更严重的问题。 具有挑战性的问题需要解决。 2.2 状态有效性 考虑图 7，其中 Shard #1 已损坏并且恶意行为者产生了 无效区块 B。假设在该区块 B 中，有 1000 个 token 被铸造出来 爱丽丝账户上的空气。然后，恶意行为者会生成有效的区块 C（在 感觉 C 中的交易被正确应用）在 B 之上，混淆 无效块 B，并向分片 #2 发起跨分片交易 将这 1000 个 token 转入 Bob 的帐户。从这一刻起，不当行为 创建的 token 驻留在分片 #2 中完全有效的 blockchain 上。 解决这个问题的一些简单方法是： 6阅读 这个 文章 为了 详情 上 如何 适应性 腐败 可以 是 携带 输出： https://medium.com/nearprotocol/d859adb464c8. 对于 更多 详情 上 适应性 腐败， 读 https://github.com/ethereum/wiki/wiki/Sharding-FAQ# 我们正在使用什么安全模型图7： 来自具有无效块的链的跨分片交易 1. 对于分片 #2 的 validators 来验证交易所在的块 已启动。即使在上面的例子中这也不起作用，因为块 C 似乎是完全有效的。 2. 对于分片 #2 中的 validators，验证发起交易的区块之前的大量区块。自然地，对于 由接收分片验证的任意数量的块 N 恶意 validators 可以在无效块之上创建 N+1 个有效块 产生的。 解决这个问题的一个有前途的想法是将分片排列成 无向图，其中每个分片都连接到其他几个分片，以及 只允许相邻分片之间的跨分片交易（例如，这就是 Vlad Zamfir 的分片本质上是有效的7，Kadena 的分片也使用了类似的想法 Chainweb [1])。如果分片之间需要跨分片交易 不是邻居，此类事务通过多个分片路由。在这个设计中 每个分片中的 validator 预计会验证其分片中的所有块 以及所有相邻分片中的所有块。考虑下图 有 10 个分片，每个分片有 4 个邻居，并且没有两个分片需要更多 跨分片通信的跳数少于图 8 所示。 分片 #2 不仅验证其自己的 blockchain，还验证 blockchain 所有邻居，包括 1 号分片。因此，如果 Shard #1 上有恶意行为者 试图创建一个无效的块 B，然后在其上构建块 C 并发起跨分片交易，这样的跨分片交易不会走 自从分片 #2 将验证分片 #1 的整个历史以来， 会导致它识别无效的块B。 7在此处阅读有关设计的更多信息：https://medium.com/nearprotocol/37e538177ed9
图8： 类链网系统中无效的跨分片交易将 被发现 虽然破坏单个分片不再是一种可行的攻击，但破坏一个分片 碎片很少仍然是一个问题。在图 9 中，对手破坏了两个分片
1 和分片 #2 成功执行到分片 #3 的跨分片交易
来自无效区块 B 的资金： 图9： 类链网系统中无效的跨分片交易将 不被检测到 分片 #3 验证分片 #2 中的所有块，但不验证分片 #1 中的所有块，并且 无法检测恶意块。 妥善解决状态有效性有两个主要方向：
和计算的密码证明。 2.3 渔夫 第一种方法背后的想法如下：每当块头 出于任何目的（例如交叉链接到 信标链，或跨分片交易），有一段时间 任何诚实的 validator 都可以提供该块无效的证据。那里 是各种结构，可以非常简洁地证明这些块是 无效，因此接收节点的通信开销要小得多 比收到一个完整的块。 只要存在至少一个诚实的 validator ，就可以使用这种方法 分片，系统是安全的。 图10： 渔夫 这是当今提议的协议中的主要方法（除了假装问题不存在之外）。 然而，这种方法有两个 主要缺点： 1. 对于诚实的validator来说，挑战期需要足够长 识别一个块已生成，下载它，完全验证它，并准备 如果块无效则提出挑战。 引入这样一个时期将 显着减慢跨分片交易的速度。 2. 挑战协议的存在创造了新的攻击向量 当恶意节点发送带有无效挑战的垃圾邮件时。一个显而易见的解决方案 解决这个问题的方法是让挑战者存入一定数量的 token 如果挑战有效则返回。这只是部分解决方案，因为它 对于对手向系统发送垃圾邮件（并烧毁 存款）进行无效挑战，例如阻止有效的挑战来自诚实的 validator 的挑战。这些攻击是 称为悲伤攻击。 有关解决后一点的方法，请参阅第 3.7.2 节。 2.4 简洁的非交互式知识论证 多分片损坏的第二种解决方案是使用某种加密结构，允许人们证明某种计算（例如 因为从一组交易中计算一个块）被正确执行。 这种结构确实存在，例如zk-SNARKs、zk-STARKs 和其他一些， 有些目前在 blockchain 协议中积极用于私人支付， 最值得注意的是 ZCash。这些原语的主要问题是它们 众所周知，计算速度很慢。例如。 Coda 协议，使用 zk-SNARK 特别是为了证明 blockchain 中的所有块都是有效的，如 的采访表明，每笔交易可能需要 30 秒才能创建证明 （现在这个数字可能更小）。 有趣的是，证明不需要由受信任方计算，因为 该证明不仅证明了其所构建的计算的有效性，而且证明了 证明本身的有效性。因此，此类证明的计算可以分开 一组参与者之间的冗余度明显低于实际情况 执行一些无需信任的计算所必需的。它还允许参与者 他们计算 zk-SNARK 在特殊硬件上运行，而不降低 系统的去中心化。 除了性能之外，zk-SNARK 的挑战还包括： 1. 依赖于研究较少且测试较少的密码原语； 2.“有毒废物”——zk-SNARK 依赖于一个可信的设置，其中一个组 的人执行一些计算，然后丢弃中间结果 该计算的值。如果程序的所有参与者都串通 并保留中间值，可以创建假证明； 3. 系统设计引入额外的复杂性； 4. zk-SNARK 仅适用于可能计算的子集，因此协议 使用图灵完备的 smart contract 语言将无法使用 SNARKs 证明链的有效性。 2.5 数据可用性 我们要讨论的第二个问题是数据可用性。一般节点 操作特定的 blockchain 分为两组：完整节点， 那些下载每个完整区块并验证每笔交易的人，以及 Light 节点，仅下载区块头并使用 Merkle 证明作为部分的节点 他们感兴趣的状态和交易，如图 11 所示。
图11： 默克尔树 现在，如果大多数全节点串通，他们可以生成一个区块，有效或 无效，并将其 hash 发送到轻节点，但绝不泄露完整内容 块的。他们可以通过多种方式从中受益。例如， 考虑图 12： 图 12： 数据可用性问题 共有三个区块：前一个 A，是由诚实的 validators 产生的； 当前 B 有 validator 串通；下一个C也将被生产 由诚实的 validators 提供（blockchain 位于右下角）。 你是一个商人。当前块（B）接收块的validators 来自之前的 validator 的 A，计算出您收到资金的区块，并向您发送了该区块的标头，其中包含状态的 Merkle 证明 你有钱（或者发送这笔钱的有效交易的 Merkle 证明） 给你）。确认交易完成后，您即可提供服务。 然而，validators 永远不会将块 B 的全部内容分发给 任何人。因此，块 C 的诚实 validators 无法检索该块，并且 要么被迫停止系统，要么在 A 之上构建，剥夺你作为 金钱商人。 当我们将相同的场景应用于分片时，完整和分片的定义 轻节点通常适用于每个分片：每个分片中的 validators 每下载一次 阻止该分片并验证该分片中的每笔交易，但其他 系统中的节点，包括那些将分片链状态快照到 信标链，仅下载标头。因此分片中的 validator 是 该分片的有效完整节点，而系统中的其他参与者， 包括信标链，作为轻节点运行。 为了使我们上面讨论的渔夫方法发挥作用，诚实的validators 需要能够下载与信标链交叉链接的块。 如果恶意 validators 交叉链接无效块的标头（或使用它来 发起跨分片交易），但从未分发过区块，诚实的人 validators 无法制定挑战。 我们将介绍解决这个问题的三种方法，这些方法相互补充 彼此。 2.5.1 监护权证明 最迫切需要解决的问题是区块一次是否可用 它被出版了。 一个提议的想法是让所谓的公证人进行轮换 分片之间比 validators 更频繁，其唯一的工作就是下载 阻止并证明他们能够下载它。他们可以是 轮换更频繁，因为他们不需要下载整个状态 分片的，与 validator 不同，后者不能频繁轮换，因为它们 每次旋转时都必须下载分片的状态，如图所示 13. 这种幼稚方法的问题是无法在以后证明 公证人是否能够下载该块，因此公证人 可以选择始终证明他们能够下载该块而无需 甚至试图找回它。解决此问题的一种方法是公证人提供 一些证据或抵押一定数量的 token 来证明该区块是 下载了。这里讨论了一种这样的解决方案：https://ethresear.ch/t/ 1 位聚合友好托管债券/2236。 2.5.2 纠删码 当特定的轻节点收到一个区块的 hash 时，增加该节点的 确信该块可用，它可以尝试下载一些随机的 块的碎片。这不是一个完整的解决方案，因为除非轻节点 共同下载恶意区块生产者可以选择的整个区块
图 13： 验证者需要下载状态，因此无法轮换 经常 保留未由任何轻节点下载的块部分， 从而仍然使该块不可用。 一种解决方案是使用一种称为纠删码的结构来使其成为可能 即使只有部分块可用，也可以恢复整个块，如图所示 如图 14 所示。 图 14： Merkle tree 建立在纠删码数据之上 Polkadot 和 Ethereum Serenity 都围绕这个想法进行设计 为轻节点提供一种合理确信区块可用的方法。 Ethereum Serenity 方法在 [2] 中有详细描述。2.5.3 Polkadot 的数据可用性方法 在 Polkadot 中，与大多数分片解决方案一样，每个分片（称为平行链）将其块快照到信标链（称为中继链）。假设有 2f + 1 中继链上的 validators。平行链区块的区块生产者，称为 整理者，一旦生成了平行链区块，就计算该区块的纠删码版本，该版本由 2f +1 个部分组成，这样任何 f 个部分就足够了 重建块。然后，他们将一份零件分发给 validator 上的每个 validator 中继链。特定中继链 validator 只会在中继链上签名 块，如果它们对每个被快照的平行链块都有自己的部分 这样的中继链区块。因此，如果中继链区块具有来自 2f + 1 的签名 validators，只要不超过 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 署名も検証します)、同期のみを行います。 最後のスナップショット ブロックからのメイン チェーン ブロック。
Nightshade
3.1 从分片链到分片块 具有分片链和信标链的分片模型非常强大，但是 具有一定的复杂性。特别需要执行分叉选择规则 分别在每个链中，分片链和信标中的分叉选择规则 链必须以不同的方式构建并单独测试。 在 Nightshade 中，我们将系统建模为单个 blockchain，其中每个 块逻辑上包含所有分片的所有交易，并更改 所有分片的完整状态。然而，实际上，没有参与者下载 完整状态或完整逻辑块。相反，网络的每个参与者仅 维护与验证交易的分片相对应的状态，并且块中所有交易的列表被分为物理部分 块，每个分片一个块。 在理想条件下，每个块每个分片仅包含一个块 块，它大致对应于分片链的模型，其中 分片链产生区块的速度与信标链相同。然而， 由于网络延迟，某些块可能会丢失，因此实际上每个块 每个分片包含一个或零个块。有关如何操作的详细信息，请参阅第 3.3 节 块被生产出来。 图 16： 左侧有分片链且其中一条链具有 块在右侧分成块
3.2 共识 今天 blockchain 达成共识的两种主要方法是 最长（或最重）的链，其中具有最多工作量或权益的链 用于构建它被认为是规范的，并且 BFT，其中每个块都有一些 validator 组达成 BFT 共识。 在最近提出的协议中，后者是更占主导地位的方法， 因为它提供了立即的最终性，而在最长的链中需要更多的块 构建在块的顶部以确保最终性。常常为了有意义的事 安全性 构建足够数量的区块所需的时间 时间顺序。 在每个区块上使用 BFT 共识也有缺点，例如： 1. BFT 共识涉及大量的沟通。同时 最近的进展允许在线性时间内达成数量上的共识 参与者的数量（例如 [4]），每个块的开销仍然是明显的； 2. 所有网络参与者都参与BFT是不可行的 每个区块达成共识，因此通常只有随机抽样的参与者子集才能达成共识。原则上，随机采样的集合可以是： 自适应损坏，理论上可以创建分叉。系统 要么需要建模才能为此类事件做好准备，因此仍然 除了 BFT 共识之外，还有一个分叉选择规则，或者被设计为关闭 在这样的事件中。值得一提的是，有些设计，比如 Algorand [5]，显着降低自适应损坏的概率。 3. 最重要的是，如果出现以下情况，系统就会停止运行 1 所有参与者中有 3 名或以上 离线。因此，任何临时的网络故障或网络分裂都可能导致系统完全瘫痪。理想情况下，系统必须能够持续 只要至少一半的参与者在线（最重的 即使不到一半的参与者在线，基于链的协议也会继续运行，但这种属性的可取性更有争议 社区内）。 一种混合模型，其中使用的共识是某种最重的共识 链，但一些块使用 BFT 最终性小工具定期完成，保持了两种模型的优点。这样的 BFT 最终性小工具是 Casper FFG [6] 用于 Ethereum 2.0 8，Casper CBC（请参阅 https://vitalik. ca/general/2018/12/05/cbc_casper.html）和 GRANDPA（参见 https:// medium.com/polkadot-network/d08a24a021b5) 用于 Polkadot。 Nightshade 采用最重链共识。 特别是当一个块 生产者生产一个区块（参见第 3.3 节），他们可以收集签名 其他区块生产者和 validator 证明前一个区块。参见部分 3.8 了解如何聚合如此大量的签名的详细信息。重量 8另请参阅 Justin Drake 的白板会议，深入了解 Casper FFG，以及它如何与 GHOST 最重链共识集成：https://www. youtube.com/watch?v=S262StTwkmo一个区块的总权益就是所有签名者的累积权益 包含在块中。链的权重是块权重的总和。 在最重链共识之上，我们使用了一个最终性小工具，该小工具使用 完成区块的证明。为了降低系统的复杂度， 我们使用一个最终性小工具，它不会以任何方式影响分叉选择规则， 相反，只引入额外的削减条件，这样一旦一个块被 由最终性小工具最终确定，除非有很大比例，否则分叉是不可能的 总股份被削减。 Casper CBC 就是这样一个最终结果小工具，我们 目前模型考虑的是 Casper CBC。 我们还致力于一个名为 TxFlow 的独立 BFT 协议。当时 撰写本文档时，尚不清楚是否会使用 TxFlow 来代替 Casper 加拿大广播公司。然而，我们注意到，最终性小工具的选择很大程度上与设计的其余部分正交。 3.3 区块生产 在 Nightshade 中有两个角色：区块生产者和 validators。 在任何 点系统包含 w 个区块生产者，在我们的模型中 w = 100，并且 wv validators，在我们的模型中 v = 100, wv = 10, 000。该系统是权益证明系统， 这意味着区块生产者和 validators 都有一定数量的内部 货币（称为“tokens”）锁定时间远远超过 他们花时间履行构建和验证链的职责。 与所有权益证明系统一样，并非所有 w 区块生产者也不是 所有 wv validator 都是不同的实体，因为无法强制执行。每个 然而，w 区块生产者和 wv validators 确实有一个单独的 股份。 系统包含 n 个分片，在我们的模型中 n = 1000。正如中提到的 第 3.1 节，在 Nightshade 中，没有分片链，而是所有区块生产者和 validator 都在构建一个 blockchain，我们将其称为 主链。主链的状态被分成n个分片，每个区块 生产者和 validator 在任何时刻都只在本地下载了一个子集 对应于分片的某个子集的状态，并且仅处理和 验证影响状态这些部分的交易。 要成为区块生产者，网络参与者需要锁定一些大的区块 数量 tokens（股份）。网络的维护是分周期完成的， 其中纪元是一段以天为单位的时间段。 参加者 在特定时期开始时，w 最大的赌注是区块 那个时代的生产者。每个区块生产者都被分配给 sw 分片（比如 sw = 40，这将使 sww/n = 每个分片有 4 个区块生产者）。街区 生产者下载纪元之前分配给他们的分片的状态 开始，并在整个纪元中收集影响该分片的交易， 并将它们应用到国家。 对于主链上的每个区块 b 和每个分片 s，都有一个 将区块生产者分配给 s，s 负责生产与 b 相关的部分 到碎片。 b 中与 shard s 相关的部分称为 chunk，包含 b 中包含的分片交易列表以及 merkle结果状态的根。 b 最终只会包含一个非常小的标头 块，即所有应用交易的 Merkle 根（参见部分 3.7.1 了解具体细节），以及最终状态的 merkle 根。 在文档的其余部分中，我们经常提到区块生产者 负责在特定时间为特定分片生成块 作为块生产者。区块生产者始终是区块生产者之一。 块生产者和块生产者根据以下方式轮换每个块： 到固定的时间表。区块生产者有订单并重复生产 按该顺序块。 例如。 如果有 100 个区块生产者，则第一个区块 生产者负责生产区块 1、101、201 等，第二个是 负责生产2、102、202等）。 由于块生产与块生产不同，需要维护 状态，对于每个分片，只有 sww/n 块生产者维护状态 每个分片，相应地只有那些 sww/n 块生产者轮流创建 大块。例如。上面的常量被分配给四个区块生产者 每个分片，每个块生产者将每四个块创建一次块。 3.4 确保数据可用性 为了确保数据可用性，我们使用类似于 Polkadot 的方法 2.5.3 节中描述。一旦区块生产者产生了一个区块，他们就会创建 它的纠删码版本，具有最佳 (w, ⌊w/6 + 1⌋) 块代码 块。 然后，他们发送一块纠删码块（我们称这些块为 块部分，或只是部分）到每个块生产者。 我们计算一棵默克尔树，其中包含作为叶子的所有部分，并且 每个块的标头包含该树的默克尔根。 这些部件通过 onepart 消息发送到 validators。每一条这样的消息 包含块头、部分序号和部分内容。的 消息还包含产生该区块的区块生产者的签名 chunk 和merkle路径来证明该部分对应于header 并由适当的区块生产者生产。 一旦区块生产者收到主链区块，他们首先检查是否 块中包含的每个块都有 onepart 消息。如果没有，则块 在检索到丢失的 onepart 消息之前不会进行处理。 一旦收到所有 onepart 消息，区块生产者就会获取 来自对等体的剩余部分并重建它们所持有的块 国家。 区块生产者不会处理主链区块，如果至少有一个 块中包含的块没有相应的 onepart 消息，或者如果对于至少一个分片，他们无法维护其状态 重建整个块。 对于可用的特定块，该块的 ⌊w/6⌋+1 就足够了 生产者有自己的部分并为他们服务。因此，只要数量 恶意行为者不超过⌊w/3⌋没有超过一半区块的链 构建它的生产者可能有不可用的块。图 17： 每个块包含每个分片一个或零个块，并且每个块 是擦除编码的。纠删码块的每个部分都被发送到指定的 区块生产者通过特殊的 onepart 消息 3.4.1 对付懒惰的区块生产者 如果区块生产者有一个区块缺少 onepart 消息，那么他们 可能会选择仍然在其上签名，因为如果该块最终在链上 将使区块生产者的奖励最大化。区块没有风险 生产者，因为事后无法证明区块生产者没有 onepart 消息。 为了解决这个问题，我们在创建块时让每个块生成器 为未来编码块的每个部分选择一种颜色（红色或蓝色），并存储 编码之前块中指定颜色的位掩码。每一个部分 然后消息包含分配给该部件的颜色，并且在以下情况下使用该颜色 计算编码部分的默克尔根。如果块生产者偏离 从协议中，可以很容易地证明这一点，因为默克尔根不会 对应于 onepart 消息，或者 onepart 消息中的颜色 对应于merkle根将与块中的掩码不匹配。 当区块生产者签署区块时，它们会包含所有区块的位掩码 他们收到的红色部分是块中包含的块。出版一个 不正确的位掩码是一种可削减的行为。如果区块生产者还没有收到 onepart 消息，他们无法知道消息的颜色，并且 因此，如果他们试图盲目地签署协议，就有 50% 的机会被削减 块。 3.5 状态转换申请 块生产者仅选择要包含在块中的交易，但是 当它们生成块时不应用状态转换。相应地，
块头包含之前默克尔化状态的默克尔根 应用块中的事务。 仅当包含该块的完整块时才应用事务 已处理。参与者仅处理一个块，如果 1. 前一个区块被接收并处理； 2.对于每个块，参与者不维护他们拥有的状态 看到了 onepart 消息； 3. 对于每个块，参与者确实维护状态，因为他们有 完整的块。 一旦块被处理，对于参与者的每个分片 维护状态，他们应用交易并计算新状态 在应用交易后，它们就准备好生产 下一个块的块（如果它们被分配给任何分片），因为它们有 新默克尔化状态的默克尔根。 3.6 跨分片交易和收据 如果一笔交易需要影响多个分片，则需要连续进行 在每个分片中单独执行。完整的交易被发送到第一个分片 受影响，并且一旦交易包含在此类分片的块中，并且 在块包含在块中之后应用，它会生成所谓的收据 交易，即路由到交易需要的下一个分片 被处决。如果需要更多步骤，则执行收据交易 生成新的收据交易等。 3.6.1 收据交易生命周期 理想的是，收据交易应用于紧随其生成的块之后的块中。收据交易仅 区块生产者收到并应用前一个区块后生成 维护原始分片，并且需要在 下一个块的块由目的地的块生产者生成 碎片。因此，收据必须从源分片传送到 这两个事件之间的短时间内的目标分片。 令 A 为最后产生的区块，其中包含生成收据 r 的交易 t。令 B 为下一个生成的块（即具有 A 的块） 它的前一个块）我们想要包含 r。设 t 在分片 a 中，r 为 在碎片 b. 收据的生命周期（也如图 18 所示）如下： 制作并保存收据。分片的块生产者 cpa a 接收区块 A，应用交易 t 并生成收据 r。注册会计师 然后将所有此类生成的收据存储在其索引的内部持久存储中 通过源分片 ID。分发收据。一旦 cpa 准备好生成块 块 B 的分片 a，它们获取通过应用分片 a 的块 A 中的交易而生成的所有收据，并将它们包含到 shrad 的块中 块 B 中的 a。一旦生成这样的块，cpa 就会生成其纠删码 版本和所有相应的 onepart 消息。 cpa 知道哪些区块生产者维护哪些分片的完整状态。对于特定的区块生产者 bp cpa 包括在 A 块中应用交易产生的收据 对于具有 bp 关心的任何分片作为其目的地的分片 a 当他们在块 B 中分发分片 a 的块时，在 onepart 消息中 （见图 17，显示了 onepart 消息中包含的收据）。 收到收据。请记住，参与者（区块生产者和 validators）在收到 onepart 消息之前不会处理区块 对于块中包含的每个块。因此，当任何特定参与者应用块 B 时，他们拥有对应于的所有 onepart 消息 B 中的块，因此它们拥有包含分片的所有传入收据 参与者将状态维持为目的地。 当应用 特定分片的状态转换，参与者应用两个收据 他们在 onepart 消息中为分片收集的信息，以及所有 包含在块本身中的事务。 图 18： 收据交易的生命周期 3.6.2 处理过多的收据 有可能针对某个特定分片的收据数量 特定块太大而无法处理。例如，考虑图 19， 每个分片中的每笔交易都会生成一个针对分片 1 的收据。 到下一个块时，分片 1 需要处理的收据数量为 与处理时所有碎片组合处理的负载相当 前一个块。
图 19： 如果所有收据都针对同一个分片，则该分片可能没有 处理它们的能力 为了解决这个问题，我们使用了类似于 QuarkChain 9 中使用的技术。 具体来说，对于每个分片，最后一个块 B 和该分片中的最后一个分片 s 记录应用收据的块。当新分片出现时 创建后，收据首先从 B 中的剩余分片中应用， 然后在 B 之后的块中，直到新块已满。正常情况下 负载均衡的情况下，一般会导致所有收据 正在应用（因此最后一个块的最后一个分片将被记录为 每个块），但在负载不平衡的时候，以及特定的 分片收到不成比例的大量收据，这种技术使他们能够 进行处理，同时遵守所包含交易数量的限制。 请注意，如果这种不平衡负载持续较长时间，则延迟 收据创建直到应用程序可以无限期地继续增长。一 解决这个问题的方法是删除任何创建收据的交易 处理延迟超过某个常量（例如一个时期）的分片。 考虑图 20。到了区块 B，分片 4 无法处理所有收据， 因此它只处理来自区块 A 中最多分片 3 的收据，并且 记录下来。在区块 C 中，包含区块 B 中最多分片 5 的收据，并且 然后到了块 D，分片赶上了，处理所有剩余的收据 B 块和 C 块的所有收据。 3.7 块验证 为特定分片生成的块（或在具有分片链的模型中为特定分片链生成的分片块）只能由 9查看 QuarkChain 的白板片段：https://www.youtube.com/watch? v=opEtG6NM4x4，其中讨论了跨分片交易的方法等 东西图 20： 延迟收据处理 维持状态的参与者。他们可以是区块生产者，validators， 或者只是下载状态并验证分片的外部见证人 他们存储资产。 在本文档中，我们假设大多数参与者无法存储 大部分分片的状态。不过值得一提的是， 存在分片 blockchain ，其设计假设为 大多数参与者确实有能力存储状态并验证大部分 分片，例如 QuarkChain。 由于只有一小部分参与者拥有验证分片的状态 块，有可能自适应地破坏具有 状态，并应用无效的状态转换。 提出了多重分片设计，每隔几次采样 validators 天，以及一天之内分片链中任何拥有超过 2/3 的区块 立即考虑分配给此类分片的 validator 的签名 最终。通过这种方法，自适应对手只需要破坏 2n/3+1 分片链中的 validators 来应用无效状态转换，其中， 虽然可能很难实现，但对于公众来说安全水平还不够 blockchain。 正如第 2.3 节中所讨论的，常见的方法是在为任何具有状态的参与者（无论是 它是一个区块生产者、validator 或外部观察者）来挑战其有效性。这些参与者被称为渔民。为了让渔民能够 挑战无效区块，必须确保这样的区块可供使用 他们。 Nightshade 中的数据可用性将在第 3.4 节中讨论。 在 Nightshade 中，一旦生成了一个块，这些块就不会被验证 除了实际的块生产者之外的任何人。特别是，区块生产者 建议该块自然不具有大多数分片的状态，并且无法验证这些块。当下一个区块产生时，它包含多个区块生产者和 validator 的证明（参见第 3.2 节）， 但由于大多数区块生产者和 validator 不维护状态 对于大多数分片来说，只有一个无效块的区块将收集超过一半的证明，并且将继续处于最重的状态 链。 为了解决这个问题，我们允许任何维持以下状态的参与者 一个分片，用于针对该分片中产生的任何无效块在链上提交挑战 碎片。 3.7.1 状态有效性挑战 一旦参与者检测到特定块无效，他们需要提供该块无效的证明。由于大多数网络参与者不维护无效块所在分片的状态 产生后，证明需要有足够的信息来确认该块是 无状态无效。 我们设置单个事务的状态量（以字节为单位）的限制 Ls 可以累积读取或写入。任何触及 Ls 以上的交易 状态被认为是无效的。请记住 3.5 节中的块 特定区块B中仅包含要应用的交易，但不包含 新的状态根。块B中的块包含的状态根是状态 在应用此类事务之前，但在应用事务之后 块 B 之前同一分片中的最后一个块。恶意行为者 希望应用无效的状态转换将包括不正确的状态根 在块 B 中，它与应用产生的状态根不对应 前一个块中的交易。 我们扩展块生产者在块中包含的信息。 它不是只包含应用所有事务后的状态，而是 在应用每个连续的交易集之后包括一个状态根 共同读取和写入 Ls 个字节的状态。 有了这些信息对于 渔夫提出了一个挑战，即状态转换应用不正确 足以找到第一个这样的无效状态根，并且只包含 Ls 字节 受最后一个状态根（之前是 valid）和带有默克尔证明的当前状态根。那么任意参与者 可以验证段中的事务并确认该块是 无效。 类似地，如果块生产者尝试包含读取的事务 并写入超过 Ls 个字节的状态，对于挑战来说，包含就足够了 它与默克尔证明接触的第一个 Ls 字节，这足以 应用交易并确认有一个时刻尝试 读取或写入的内容超出 Ls 字节。
3.7.2 渔民和快速跨分片交易 正如 2.3 节中所讨论的，一旦我们假设分片块（或分片 具有分片链的模型中的块）可能无效并带来挑战 期间，它会对最终结果产生负面影响，从而影响跨分片通信。在 特别是，任何跨分片交易的目标分片都无法确定 在挑战期结束之前，原始分片块或块是最终的 （见图 21）。 图 21： 在申请收据之前等待挑战期 以使得跨分片交易的方式来解决这个问题 Instantinious 是指目标分片不等待挑战期 源分片交易发布后，应用收据交易 立即，然后将目标分片与源分片一起回滚 如果后来发现原始块或块无效（见图 22）。这非常自然地适用于 Nightshade 设计，其中碎片 链不是独立的，而是分片块全部发布 一起在同一个主链区块中。如果发现任何块无效， 包含该块的整个块被认为是无效的，并且构建在其上的所有块 其顶部。见图 23。 上述两种方法都提供原子性，假设挑战 周期足够长。我们使用后一种方法，因为在正常情况下提供快速的跨分片交易比 由于其中之一的状态转换无效，目标分片回滚 源碎片，这是极其罕见的事件。 3.7.3 隐藏 validators 挑战的存在已经大大降低了 自适应损坏，因为要使用无效的状态转换后完成一个块图 22： 立即应用收据并回滚目的地 链如果源链有无效块 图 23： 茄属渔夫挑战 适应性对手需要腐蚀所有参与者的挑战期 维护分片的状态，包括所有 validator。 估计此类事件的可能性极其复杂，因为没有 sharded blockchain 已经存在足够长的时间来尝试任何此类攻击。我们认为这种可能性虽然极低，但仍然足够 对于预计执行数百万笔交易的系统来说很大 经营全球金融业务。 这种信念有两个主要原因： 1. 权益证明链的大多数 validator 和矿工
工作量证明链主要受到财务上行的激励。如果 适应性强的对手为他们提供的钱多于预期回报 从诚实经营的角度来看，可以合理地预期许多 validator 将接受该提议。 2. 许多实体对权益证明链进行专业验证，并且 预计任何连锁店的大部分股权都将被 来自此类实体。此类实体的数量对于 适应性强的对手能够亲自了解他们中的大多数人并拥有 很好地理解了他们的本性被腐蚀了。 我们通过隐藏哪些 validator 分配给哪个分片，进一步降低了自适应损坏的概率。这个想法是 与 Algorand [5] 隐藏 validators 的方式非常相似。 值得注意的是，即使 validator 被隐藏，如 Algorand 中所示 或者如下所述，自适应腐败在理论上仍然是可能的。同时 适应性对手不知道将创建或验证的参与者 一个块或一个块，参与者自己确实知道他们将执行 这样的任务并有它的密码证明。 这样，对手就可以 传播他们的腐败意图，并向任何愿意提供的参与者支付费用 这样的密码学证明。然而我们注意到，由于对手不 知道分配给他们想要破坏的分片的 validator，他们 别无选择，只能将他们破坏特定分片的意图传播给 整个社区。到那时，这对任何诚实的人来说都是经济上有利的 参与者启动一个验证该分片的完整节点，因为有一个很高的 该分片中出现无效块的机会，这是一个机会 创建挑战并收集相关奖励。 为了不泄露分配给特定分片的 validator，我们这样做 如下（见图 24）： 使用 VRF 获取任务。在每个纪元的开始 validator 使用 VRF 获取分配给 validator 的分片的位掩码。 每个 validator 的位掩码将具有 Sw 位（请参阅第 3.3 节了解定义 的 Sw）。然后 validator 获取相应分片的状态，并且 在收到的每个块的纪元期间验证对应的块 分配给 validator 的分片。 对块而不是块进行签名。由于分片分配是隐藏的，因此 validator 无法在块上签名。相反，它总是在整个 块，因此不会透露它验证的分片。具体来说，当 validator 接收到一个块并验证所有块时，它要么创建一条消息 证明 validator 分配到的所有分片中的所有块都是 有效（不以任何方式表明这些分片是什么），或者一条消息 如果任何块无效，则包含无效状态转换的证明。请参阅 有关如何聚合此类消息的详细信息，请参阅第 3.8 节，有关如何聚合此类消息的详细信息，请参阅第 3.7.4 节 有关如何防止 validators 捎带消息的详细信息 其他 validators，以及第 3.7.5 节了解如何奖励和惩罚的详细信息 validators 应该成功地发生无效状态转换挑战。图 24： 将 validator 隐藏在茄属植物中 3.7.4 提交-揭示 validators 的常见问题之一是 validator 可以跳过下载状态并实际验证块和块，而是 观察网络，查看其他 validator 提交的内容并重复他们的 消息。遵循这种策略的 validator 不提供任何额外的 网络安全，但收取奖励。 此问题的常见解决方案是为每个 validator 提供一个证明 他们实际上验证了该块，例如通过提供唯一的跟踪 应用状态转换，但这样的证明显着增加了成本 的验证。 图 25： 提交-揭示
相反，我们让 validators 首先提交验证结果（或者 证明块有效性的消息，或无效证明 状态转换），等待一定的时间，然后才显示实际的验证结果，如图25所示。提交时间与 揭示期，因此懒惰的 validator 无法模仿诚实的 validator。 此外，如果不诚实的 validator 提交了一条证明 分配的块的有效性，并且至少有一个块是无效的，一旦 显示该块无效，validator 无法避免削减，因为， 正如我们在第 3.7.5 节中所示，在这种情况下不被削减的唯一方法 是呈现一条消息，其中包含无效状态转换的证明 匹配提交。 3.7.5 应对挑战 如上所述，一旦 validator 接收到带有无效块的块， 他们首先准备无效状态转换的证明（参见第 3.7.1 节），然后 致力于这样的证明（见 3.7.4），并在一段时间后揭示挑战。 一旦揭示的挑战被包含在区块中，就会发生以下情况： 1. 从包含该块的块中发生的所有状态转换 无效块，直到包含所揭示的挑战的块得到 无效。包含已揭示挑战的区块之前的状态 被认为与包含该块的块之前的状态相同 无效块。 2. 在一定的时间内，每个 validator 必须揭示其位掩码 他们验证的分片的数量。由于位掩码是通过 VRF 创建的，如果 他们被分配到具有无效状态转换的分片，他们 无法避免暴露它。任何无法显示位掩码的 validator 假设已分配给分片。 3. 在这段时间内发现分配给分片的每个 validator， 确实提交了包含以下内容的块的某些验证结果 无效块并且没有揭示无效状态转换的证明 与他们的提交相对应的内容被削减。 4. 每个validator得到一个新的分片分配，并安排一个新的epoch 一段时间后开始，足以让所有 validator 下载 状态，如图 26 所示。 请注意，从 validator 显示分配给它们的分片那一刻起 直到新纪元开始，系统的安全性都会降低，因为 分片分配被揭示。网络参与者需要保留它 在此期间使用网络时请谨记。 3.8 签名聚合 为了让拥有数百个分片的系统能够安全运行，我们希望 10、000 或更多 validator 的顺序。正如第 3.7 节中所讨论的，我们希望每个图 26： 应对挑战 validator 发布对特定消息的提交和平均签名 每个块一次。即使提交消息相同，聚合这样的 BLS 签名并对其进行验证的成本将高得令人望而却步。但是 当然，validator 中的提交和显示消息并不相同， 因此我们需要某种方法来聚合这些消息和签名 以便稍后快速验证的方式。 我们使用的具体方法如下： 验证者加入区块生产者。区块生产者是已知的 在纪元开始之前的某个时间，因为他们需要一些时间来下载 纪元开始之前的状态，与 validator 不同，区块生产者是 没有隐藏。每个区块生产者都有 v 个 validator 插槽。验证者提交 向区块生产者提出链下提案，将其纳入其 v 之一 validators。如果区块生产者希望包含 validator，他们会提交 包含来自 validator 的初始链外请求的交易，以及 区块生产者的签名，使 validator 加入区块生产者。 请注意，分配给区块生产者的 validator 不一定是 验证区块生产者为其生成块的相同分片。 如果一个 validator 申请加入多个区块生产者，仅来自 第一个区块生产者将会成功。 区块生产者收集提交。区块生产者不断收集来自 validator 的提交和显示消息。一旦累积了一定数量的此类消息，区块生产者就会计算默克尔 这些消息的树，并向每个 validator 发送 merkle 根和 他们的消息的默克尔路径。 validator 验证路径并登录 默克尔根。然后，区块生产者在区块链上累积 BLS 签名 来自 validators 的 merkle 根，并且仅发布 merkle 根和 累计签名。区块生产者还签署了该区块的有效性 使用廉价的 ECDSA 签名进行多重签名。如果多重签名没有 匹配提交的默克尔根或参与的 validator 的位掩码，这是可削减的行为。同步链时，参与者 可以选择验证来自 validators 的所有 BLS 签名（这非常昂贵，因为它涉及聚合 validators 公钥），或者仅验证来自区块生产者的 ECDMA 签名，并依赖于以下事实： 区块生产者没有受到挑战和削减。 使用链上交易和默克尔证明来应对挑战。它 可以注意到，如果没有，那么泄露来自 validators 的消息是没有价值的。 检测到无效的状态转换。仅包含实际内容的消息 需要揭示无效状态转换的证明，并且仅针对此类消息 需要证明它们与之前的提交相匹配。该消息需要 被披露有两个目的： 1. 真正启动链回滚到之前的那一刻 无效状态转换（参见第 3.7.5 节）。 2. 证明 validator 并未试图证明该信息的有效性 无效块。 无论哪种情况，我们都需要解决两个问题： 1. 实际提交并未包含在链上，仅包含在链上的merkle根 提交与其他消息聚合。 validator 需要使用 区块生产者提供的默克尔路径及其原始承诺 证明他们致力于挑战。 2. 有可能分配给无效分片的所有validator 状态转换恰好被分配给损坏的区块生产者 正在审查他们。为了解决这个问题，我们允许他们提交他们的揭露 作为链上的常规交易并绕过聚合。 后者仅适用于无效状态转换的证明，即 极其罕见，因此不应导致垃圾邮件块。 需要解决的最后一个问题是区块生产者可以 选择不参与消息聚合或故意审查特定的 validator。我们通过制作区块使其在经济上处于不利地位 生产者奖励与分配给他们的 validator 数量成正比。我们 还请注意，由于纪元之间的区块生产者很大程度上相交（因为 它始终是拥有最高赌注的前 w 参与者），validators 可以 很大程度上坚持与相同的区块生产者合作，从而降低风险 被分配给过去审查过他们的区块生产者。 3.9 快照链 由于主链上的区块产生非常频繁，因此下载 完整的历史可能很快就会变得昂贵。而且，由于每 区块包含大量参与者的 BLS 签名，仅聚合公钥来检查签名可能会变得令人望而却步 也很贵。 最后，因为在任何可预见的未来 Ethereum 1.0 可能仍然是一个 最常用的 blockchain 中，有一种有意义的方式来转移资产
要求接近 Ethereum，今天验证 BLS 签名以确保 Ethereum 一侧的近块有效性是不可能的。 Nightshade 主链中的每个区块都可以选择包含 Schnorr 包含此类 Schnorr 的最后一个块的标头上的多重签名 多重签名。我们将此类块称为快照块。第一个块 每个纪元必须是一个快照块。在研究这样的多重签名时， 区块生产者还必须累积 validator 的 BLS 签名 在最后一个快照块上，并按照与中所述相同的方式聚合它们 第 3.8 节。 由于区块生产者集在整个时期内保持不变，因此验证 假设在没有任何情况下，只有每个时期中的第一个快照块就足够了 指出很大一部分区块生产者和 validator 串通并创建 叉子。 纪元的第一个块必须包含足以计算的信息 该纪元的区块生产者和 validators。 我们称主链中只包含快照的子链为 阻止快照链。 创建 Schnorr 多重签名是一个交互式过程，但由于我们 只需要很少执行，任何流程，无论效率如何低下 就足够了。 Schnorr 多重签名可以在 Ethereum 上轻松验证， 从而为执行跨blockchain的安全方式提供关键原语 沟通。 与近链同步只需下载所有快照 块并确认 Schnorr 签名正确（也可以选择验证 validator 的各个 BLS 签名），然后仅同步 主链区块来自最后一个快照区块。
結論
このドキュメントでは、シャード化された blockchain を構築するアプローチについて説明しました。 既存のアプローチの 2 つの主要な課題、つまり状態の妥当性をカバーしました。 データの可用性。次に、Nightshade というシャーディング デザインを提案しました。 NEAR プロトコルを強化します。 デザインは進行中です。コメント、質問、フィードバックがありましたら このドキュメントについては、https://near.chat. にアクセスしてください。
结论
在本文档中，我们讨论了构建分片 blockchain 的方法和 克服了现有方法的两个主要挑战，即状态有效性 和数据可用性。然后我们提出了 Nightshade，一种分片设计 赋予 NEAR 协议权力。 设计正在进行中，如果您有意见、问题或反馈 对于本文档，请转至 https://near.chat.