編集者注: この記事は以下から引用しましたアンビラボ (ID:secbitlabs)、許可を得てOdailyによって転載されました。

編集者注: この記事は以下から引用しました

アンビラボ (ID:secbitlabs)

、許可を得てOdailyによって転載されました。

イーサリアムもパフォーマンスを向上させるためにさまざまな方法を試みており、2.0 のリリース前夜には暗号化を「試しました」。イーサリアム2.0は「分散システム＋暗号」をベースとしたパブリックチェーンとなるが、この暗号とは署名やプライバシーに使われる部分を指すのではなく、高性能システムの中核となる部分を指す。

この観点から、イーサリアムを破壊するのは他者ではなく、イーサリアム自体であると言えるかもしれません。分散システム設計という単一のアイデアから飛び出し、分散システム + 暗号の組み合わせ設計の道を歩み始めました。

この記事では、分散システム設計がイーサリアム 2.0 の暗号化設計とどのように組み合わされて、パブリック チェーンのパフォーマンスのブレークスルーを達成するかを紹介します。

副題

状態シャーディング: 単一台帳から複数台帳へ

ブロックチェーンは分散型台帳であり、ブロック ノードはアカウントを管理するマイナーであり、トランザクションを台帳に書き込む責任があります。簿記の権利をめぐって競争することに加えて、ブロック生産者の最も重要な仕事、あるいは彼ら自身の仕事は、パックした取引が合法かどうかをチェックすることです。ブロック生成ノードは台帳を保持しており、トランザクションの送信者がお金を持っているかどうかを確認するだけでよいため、この作業を完了するのは難しくありません。

非断片化パブリック チェーンの場合、すべてのノードが同じ台帳を保持し、簿記の競合を防ぐために、一度に帳簿を保持できるブロック生成ノードは 1 つだけです。イーサリアムは、実際に台帳を複数の台帳に分割するステート シャーディングを提案しています。このようにして、一部のノードは 1 番目の台帳にアカウントを保持し、一部のノードは 2 番目の台帳にアカウントを保持します... (現金の 7-11 に相当)プラットフォームが複数のレジに増加し、複数のノードが同時に会計を保持し、パブリック チェーン全体のパフォーマンスが質的に向上します。

しかし、ブロックを生成するノードと台帳/シャードの関係を修正すると、たとえば、4 つのノード a、b、c、d が No.1 台帳を担当していることが判明した場合、悪者は購入するだけで済みます。 a、b、c、d の一部は台帳を破壊する可能性があり、パブリック チェーンのパフォーマンスは向上しますが、セキュリティは同じ割合で低下します。

イーサリアムが提供する解決策は、ブロック生成ノードが台帳を取得しないこと、つまり、ブロック生成ノードがアカウントを保持するための台帳を必要としないことです。

これにより、ノードがどのシャードに割り当てられても、すぐに簿記（ブロック生成）を開始できることと、シャードの台帳の取得と同期にほとんど時間がかからないことの 2 つの大きなメリットが得られます。異なるシャード間を簡単に移動できること、2 つ目は、ブロック生成ノードが台帳を保存する必要がなく、高度なハードウェア構成も必要ないことです。32ETH を抵当に入れる人は誰でもバリデーターになれるため、イーサリアム PoS の分散化に非常に役立ちますそしてパブリックチェーン全体のセキュリティ。

しかし、新たな問題が浮上します。ブロックプロデューサーが台帳を持っていない場合、トランザクション送信者が十分な資金を持っているかどうかをどのようにして知ることができるのでしょうか?ここで暗号化が登場します。

副題

ベクトルのコミットメント: クエリから証明まで

台帳なしでアカウントを維持できるというのは信じられないことのように聞こえますが、考え方は単純です。以前は、ノードには台帳があり、トランザクションが発生すると、その台帳を調べてトランザクションが合法かどうかを確認していました。将来、ノードには台帳がなく、トランザクション送信者がトランザクションを送信するときは、暗号証明を提出する必要があります (区別するために、以下の文では暗号証明を証拠と呼びます)。トランザクションが暗号証明であることを証明できます。法律上の。

なぜブロック生成ノードは証明を通じて特定のトランザクションが合法であるかどうかを判断できるのでしょうか?ここには暗号化の 2 つの重要な概念が関係しており、1 つ目は「メンバー証明」と呼ばれます。これは、個人がグループの一員であることを証明するプロセスを指します。特定のアカウント状態が台帳状態全体の一部であることが証明できれば、ブロック生成ノードは当然このアカウント状態を信じ、これをトランザクションの合法性を判断するための基礎として使用できます。

2 つ目は「ベクター コミットメント」と呼ばれるもので、グループがどれほど大きくても、グループを 1 つの数字のみに圧縮し、個人がその数字の背後にあるグループに属していることを示すメンバーシップの証明を与えることができます。 、グループ内の個人の位置を証明し、証明書を更新できます。

下図はマークルツリーで、最下層のリーフノードにはアプリケーションデータが格納され、その他の非リーフノードには子ノードのハッシュ値が格納されます。緑色のノードとすべての黄色のノードの値がわかっている場合は、下から上に 3 つのハッシュ演算を実行して、マークル ツリーのルートの値 (6c0a) を取得できます。

次に、検証者がツリー ルート (6c0a) の値を持っている場合、証明プロバイダーは緑色のノードの値と黄色のノードのすべての値を検証者への証明として受け取り、検証者は次の計算を行うことができますか?緑のノードの値がこのマークル ツリーにあるかどうかを判断するには、ハッシュ値を 3 回? 6c0a に等しいか?答えは「はい」です。これは、マークル ツリーへのグリーン ノードのメンバーシップの証明であり、ベクトル コミットメントとして行われます。これは、ビットコイン SPV ノード (簡易支払い検証) の仕組みとほとんど同じです。

以下の図に示すように、SPV ノードは完全なブロック/台帳を保存するのではなく、必要に応じて各ブロックにマークル ツリーのルートを保存します (マークル ツリーのリーフ ノードはブロック内のすべてのトランザクションを保存します)。トランザクションが存在する場合、完全なノードはトランザクションの証明を求められます。これは、上記の緑のノードと黄色のノードの値のパッケージ (マークル パス) に似ており、SPV ノードは合計を計算します。これらの値のハッシュ その値が自分の手持ちのマークルツリーのルートの値と等しいかどうか 等しい場合、そのトランザクションはマークルツリーのメンバーである、つまりトランザクションが存在することを意味します。

画像の説明

SPV ノードはメンバーシップ証明を通じてトランザクションが存在するかどうかを判断します. 証明システムは 3 つの部分で構成されます: ノードは短い要約 (ツリー ルート) を持ちます; 証明プロバイダーは証明を与えます; ノードは証明を計算して、それが一致するかどうかを確認します。独自のハンドマッチでの要約。

ここまでで、クエリ思考から実証思考への「帳簿のない当座預金」は完了し、次に達成したいのは「帳簿のない会計」です。

イーサリアム 2.0 シャード上のブロック生成ノードの場合、その証明システムも抽象、証明、検証の 3 つの部分で構成されますが、トランザクション送信者 (完全なノードではなく) によって与えられた証明を使用して、新しいかどうかを判断する必要があります。 (古い取引が存在するかどうかではなく) 取引は合法であり、この判断を会計の基礎として使用します。

副題

ステートレス: 元帳の証明から行動の証明へ

村民の間で毎日 3 件の取引しか行われない小さな村を想像してください。村長は台帳の会計を管理する責任があります。 A さんは今、5 元を B さんに送金したいと考えています。伝統的な考え方は非常に単純です。村長は A さんの口座に 5 元があるかどうかを確認し、あれば、この新しい取引を書き留めます。

ここで考え方を変えます。今朝、A が B に 5 元を送金したいとします。そして、昨日の朝、A の口座に 10 元があることを村長が知っているとします。そのとき、A が昨日の 3 つの取引が自分に関係がないことを証明できれば、次のようになります。そうですか? 今朝、彼の口座にはまだ 10 ドルが残っているということですか?このように、村長は台帳を確認せずにこの新しい取引を書き留めることができるでしょうか？答えは「はい」です。

A が昨日取引を行った場合はどうなるでしょうか?非常に簡単です。この時点では、A は取引がないことを証明するのではなく、昨日 1 回だけ取引があり、その取引にかかった費用は 3 元であることを証明します。村長はまだ 7 元があることを知っているので、記録することができます。新しいトランザクション。

この考え方の変化は非常に重要であり、理解する必要がありますが、これが「無国籍」の謎です。台帳を保持していない SPV ノードでも、実際にはトランザクションをクエリするときに台帳または状態を使用する必要があることを見つけるのは難しくありませんが、状態はそれ自体で保存されるのではなく、ノード全体にアクセスして状態を取得します。この状態の証明 ; しかし、この新しいアイデアの下では、状態の役割を「動作証明」に完全に置き換えることができ、このチェーンはステートレスな方法で設計できます。 （注：「行動証明」という言葉には出典がなく、わかりやすくするために著者が説明したものです）

無国籍を実現するにはどうすればよいでしょうか？行動証拠の助けを借りて簿記を完了するにはどうすればよいですか?会員認証の方法は今でも変わりません。マークル ツリーを使用してこのメ​​ンバーシップ証明を完了できますか?理論的には可能ですが、「ステートレス」アプリケーション シナリオの場合、それを使用するオーバーヘッドが高すぎます。この記事では、台帳なしの簿記のための集約可能なサブベクトルコミットメントによるメンバーシップの証明を紹介します。

Aggregated Subvector Commitments (aSVC) は、Alin Tomescu、Ittai Abraham、Vitalik Buterin (イーサリアム)、Justin Drake (イーサリアム スクエア)、Dankrad Feist (イーサリアム)、Dmitry Khovratovich による論文「ステートレス暗号通貨のための集約されたサブベクトル コミットメント」に基づく最近の研究成果です。 (イーサリアム)。その作業プロセスは次のとおりです。

1. シャーディングの初期化、つまり帳簿作成時のアカウントの初期状態を決定します。シャードが確立されたときに 100 個のアカウントがあり、これらのアカウントには初期残高があるとします。i 番目のアカウントを表すために v(i) を使用する必要があります。これは、(アドレス i, 残高 i などの値のペア) ); use V すべての口座を表し、(アドレス1,残高1)(アドレス2,残高2)...(アドレス100,残高100)といった値の集合です。

同時に 2 つの値を生成する必要があります。最初の値は c と呼ばれ、V へのコミットメントであり、すべてのアカウントと現時点でのシャードのアカウントの残高を表します。ブロック生成ノードは c を手に持ちます (マークル木のルートと比較するとわかりやすい)。これは将来の検証のためにまとめられます。

2 番目のものは π(i) と呼ばれます。これは、v(i) が V のメンバーであり、i 番目の口座を表し、口座の残高が総勘定元帳 V にあることの証明です。各アカウントは、将来トランザクションを送信するときにブロック ノードに送信される証明である独自の π(i) を保持し、保持するだけです。

初期化フェーズでは、コミットメントと証明の生成には初期の「状態」が必要です。

2. 最初のトランザクション。アカウント i はシャード全体の最初のトランザクションを開始します。このとき、π(i) とトランザクションをブロック ノードに送信する必要があり、ブロック ノードは π(i) を計算して結果が c と一致するかどうかを確認します。それらが一致する場合、送信者のアカウントの残高がどれくらいであるかを信頼でき、これを送信者が送信したトランザクションが合法であるかどうかを判断するために使用できます。

3. 次が重要なポイントです。c と π(i) を更新します。

c (台帳全体に対するコミットメント) は状態に応じて生成されなくなり、最初のトランザクションの前の c と最初のトランザクションによって引き起こされる残高変更を使用して生成されます; π(i) (アカウント自体の証明) ではありません状態に応じて生成され、最初のトランザクションが発生する前のπ(i)と最初のトランザクションによるアカウントの変更で生成されます。

c と π(i) の更新が完了すると、ブロック生成ノードはすべてのユーザーの新しい残高を約束できる新しいコミットメント (新しい c) を持ち、アカウントも新しい証明 (新しい π(i) を持ちます)新しいバランスを証明します))。

類推すると、各トランザクションは c を 1 回変更し、すべての π(i) を 1 回変更しますが、この変更は状態データには依存せず、古い c と π(i)、および前のトランザクションに依存します。新しいトランザクションを検証する必要がある場合、ブロック生成ノードは常に最新の c を保持しており、c と、アカウント。

この時点で、ようやく「台帳がなくてもアカウントを保持できる」ことが実現するのですが、ブロックプロデューサーにとってもアカウントにとっても、彼らが手にしているのは台帳の状態ではなく、ある種の暗号証拠です。ステートレス性とシャーディングは完全に一致しているように見えますが、ステートレス性はシャーディングのための設計ではなく、パブリック チェーンのための設計であることにも言及する必要があります。

aSVC の設計目標は、メンバーシップの効率的な証明となり、上記のプロセスにおける通信オーバーヘッドと計算オーバーヘッドを削減して、このスキームをステートレス ブロックチェーンの実装に使用できるようにすることです。論文の観点から見ると、aSVC スキームを使用すると、c と π(i) のサイズはわずか数十バイトであり、π(i) の更新時間は O(1)、検証時間も O( 1). 複数の証明を 1 つの O(1) 証明に集約することをサポートします。このオーバーヘッドの低い実装は、まさに aSVC のすべてです。ただし、イーサリアム研究者フォーラムでの Vitalik の議論と同様に、aSVC にはまださらなる最適化が必要です。

記事の最後には全文の簡単な要約が記載されています。分散システムの状態シャーディング設計が、暗号化のメンバーシップ証明設計と組み合わされて、イーサリアム 2.0 のパフォーマンスのブレークスルーを達成します。

1. 安全のため、イーサリアム 2.0 のステート シャーディングでは、ブロック生成ノードをランダムに割り当てる必要があります。

2. ブロック生成ノードに台帳が必要な場合、台帳の同期が新たなパフォーマンスのボトルネックとなり、台帳のストレージも PoS の分散化に影響します。

4. 1 つ目の考え方の変更: 台帳を調べる方法から台帳を証明する方法に変更します。これは暗号化を利用して行う必要があります。

5. 第二の発想の転換：台帳の状態を証明する方法から取引行為を証明する方法に変更し、台帳のないステートレス・簿記を実現する。これは暗号化を利用して行う必要があります。

6. 暗号化用のツールは数多くありますが、目的がある場合は、アプリケーションの要件に応じて適切なツールを選択して組み合わせてソリューションを形成し、ソリューションを最適化する必要があります。

副題

イースターエッグ: 集約可能なサブベクトルの約束

この記事では、aSVC の動作を自然言語で説明していますが、興味がある場合は、aSVC の API 定義を参照すると、より明確に理解できます。以下の図に示すように、最初の赤いボックスは初期化中にコミットメント c を生成し、2 番目の赤いボックスはトランザクションに従って c を更新し、最初の緑色のボックスは初期化中に証明 π(i) を生成します。 2 番目の緑色のボックスはトランザクションが π(i) を更新するためのもので、青色のボックスは検証に c と π(i) を使用するブロック ノードです。

上記のプロセスでは、中心的な作業は、トランザクションによって引き起こされた変更に従って、古い c を新しい c に変更し、古い π(i) を新しい π(i) に変更することです。更新を完了できる必要があるだけでなく、この更新のオーバーヘッドも許容できる必要があります。これが、aSVC が解決する必要がある重要な問題です。 c の更新を例として、aSVC がどのように更新するかを紹介しましょう。

上で述べたように、c が約束するのは V であり、c から新しい c へは、実際には、約束 V から新しい V を約束することになります。 V の場合、一連の点で構成されます。(アドレス 1、残高 1) が 1 つの点、(アドレス 2、残高 2) が別の点です...(アドレス 100、残高 100) が 100 番目の点です。

ラグランジュ補間の助けを借りて、この一連の点を多項式に変えることができます (多項式で表される曲線はこれらすべての点を通過します)。これは、一連の点へのコミットメントを多項式へのコミットメントに変えることができることを意味します。 ; c から新しい c へは、1 つの多項式をコミットしてから別の多項式をコミットすることと同じです。https://eprint.iacr.org/2020/527.pdf。