Eth2.0の中継ネットワークと料金メカニズム
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)著者: John Adler、翻訳者および校正者: IAN LIU & A Jian、Odaily が許可を得て転載。
背景
背景
リレーネットワークに入る前に、イーサリアムの主なボトルネック（またはボトルネックの欠如）の 1 つである状態を確認してみましょう。
イーサリアムでは、状態はアカウント残高、契約コード、および契約ストレージ コンテンツの集合を指します (ビットコインでは、状態は UTXO の集合を指します)。トランザクションが実行されるたびに、状態 (約 45 GB の非圧縮データ) が読み書きされます。以前は、イーサリアム コンピューティング モデルの本来の拡張性のなさに疑問の声が上がっていましたが、現在では、状態の読み取りと書き込みがトランザクション実行のコストのボトルネックになっており、ディスクの I/O パフォーマンスがトランザクション実行のボトルネックになっています。イーサリアムのフルネットワーク ノードの制約。
ステートフル パラダイム (ステートフル パラダイム) に従ってトランザクションを実行できるようにするには、フル ノードはすべてのステートが常にアクセス可能な場所 (メモリ、スワップ領域など) に配置されていることを確認する必要があることに注意してください。これが単一のブロックチェーンのシナリオに適用される場合、これはかろうじて許容できるかもしれませんが、断片化と断片化に関する委員会の再編成に直面すると、この要件は非常に不合理になります。検証者がシャード チェーンに割り当てられるたびに、シャード上のすべての状態を同期する必要があると想像してください。このときのブロック サイズがシャード ブロック サイズと等しいことを除けば、このシステムは単一のブロックチェーンと同等になります *シャードの数。
副題
シャーディングとステートレスクライアント
ステートレス クライアント パラダイム (以前は「ストレージレス」として知られていました) では、バリデーターは圧縮されたブロックチェーン状態テーブル (アキュムレーターと呼ばれることが多い) を保存するだけで済み、トランザクション実行の負担が大幅に軽減されます。通常、アキュムレータのサイズは一定ですが (例: 状態のマークル ツリー ルート値)、サイズが対数になる場合もあります。
ステートレス クライアントの本質は、各トランザクションに、トランザクションの実行に必要なすべての情報が含まれる現在のアキュムレータの監視データ (監視) が伴うことです。イーサリアムでは、スパース マークル ツリー (SMT、スパース マークル ツリー) をアキュムレータとして使用すると、トランザクションに関係するすべての状態要素をマークル ツリー ブランチに含めることができます。
他のアプリケーションでは、ステートレス クライアントは、ビーム同期の原理であるイーサリアム ノードの初期同期時間を短縮できます。
備考: Merkle アキュムレータよりもパフォーマンスの良い暗号アキュムレータ (RSA アキュムレータなど) がいくつかありますが、そのようなアキュムレータは信頼できる初期化が必要であるか、未検証の最先端の暗号化技術を使用しているため、運用システムに導入するのは安全ではありません。しばらく時間がかかる。
しかし、ステートレス クライアントには独自の課題があります。Merkle アキュムレータが使用されると、完全な実行が終了するたびに監視の有効期限が切れてしまいます。モデルが各トランザクションに個別の監視を含めることを要求し、これらのトランザクションを順番に実行する場合、後のトランザクションの監視データは古くなり、前の各トランザクションの完了に応じて独自の監視を更新できる必要があります。幸いなことに、これらのマークル アキュムレータの証人を更新するには、ゼロ ハッシュのオーバーヘッド アプローチが必要です。証人データをトランザクションの「大きな袋」に付属物として追加できれば、各トランザクションに属する個々の証人を更新する必要はありません。または、複数のプルーフに統合することもできます (マルチプルーフ)。
すべてのユーザーがフル ノードを維持し、監視ステータスをリアルタイムで更新する場合、ステートレス クライアント システムをすぐに採用できます。残念ながら、シャード環境では、これはすべてのユーザーが自分のシャード上ですべての状態を維持する必要があることを意味し、これは非現実的であるだけでなく、上で述べたように、より大きなサイズのブロックを作成することと同じことになります。 。
この問題を解決するために、ここではリレーラー (状態プロバイダーとも呼ばれる) の概念が導入されています。中継者は、ユーザーが必要とする証人を提供する責任を負い、ユーザーにサービス料金を請求します。ユーザーとは異なり、リレーラーはサービスを 1 つのシャードに集中できますが、リレーラーはユーザーがいつ状態を必要とするかを予測できないため、監視者、つまりユーザーのリアルタイムのストレージ状態 (いわゆる状態プロバイダー) が時間内に更新されるようにする必要があります。入手する。
副題
中継ネットワークと料金相場の提案
イーサリアム 2.0 フェーズ 2 の設計空間は非常に大きく、実行モードについては多くの提案が行われています。各提案は、リレー ネットワーク メカニズムと組み合わせた支払いを通じて、ユーザー間でトランザクションを転送し、提案者をより適切にブロックする方法を表現しています。この章では、さまざまなプロトコルをできるだけ簡潔かつ包括的に要約し、中継ネットワークと料金メカニズムにおけるそれらの類似点と相違点の分析に焦点を当てます。
コレーター提案 (非推奨)
これはフェーズ 2 の初期提案であり、シャード チェーンの構成要素を提案者、照合者、実行者の 3 つの部分に分割しています。一部のプロポーザーはトランザクションを収集してブロックにパッケージ化する (照合とも呼ばれます) ことを担当し、一部のプロポーザーは照合をチェーンに送信する (ブロックに変換する) ことを担当し、最後に実行者が提案された照合に基づいて新しい状態ルートを与えます。 。
この提案は十分に検討されたことがなく、したがって料金支払いメカニズムについても検討されていませんでした。他の要因とは別に、この提案は、利益を最大化するためにユーザーが同時に提案者、照合者、執行者になることを奨励するインセンティブメカニズムにより放棄されました。
Phase 1 and Done
Casey Detrio 氏は、先駆的なブログ投稿「フェーズ 1 と完了: データ可用性エンジン - イーサリアム 2.0」の中で次のように強調しました: フェーズ 1 では、状態の断片化を必要とせずにデータをブリッジするために、可能な限り少ない実行フラグメントを追加できます。このスキームでは、シャードは次の 2 つのことを行うことができます: 1) データを認証する (つまり、一連のトランザクションをマークル ツリーなどの認識されたデータ構造に挿入する); 2) 認可されたデータのゼロ知識証明の検証などの単純なステートレス操作を実行します。
データ ブロック ハンドラーは、コントラクトをビーコン チェーンにアップロードすることで定義できます (コントラクトは将来「プリコンパイル」に変換され、その後「実行環境」になります)。クライアントによって解析されるかどうかは、プロトコル全体の内容によって異なります。
「フェーズ 1 と完了」では、料金支払いメカニズムに関するほとんどの疑問が回避されています。支払いメカニズムの問題は以前の提案にも存在し、今後も存在し続けるためです。そのため、提案では代わりに、それを Eth2 の長期使用として定義しようとしています。 .0. 変更は最小限で、すぐに判明する予定です。別の提案は、イーサリアム 1.x の契約を通じて料金を支払うことです (ブロック提案者がイーサリアム 2.0 上で処理済みの利用可能なデータ ブロックを提供し、その後、提案者に支払います) が、これはイーサリアム 2.0 のユーザビリティに大きく依存するため、疑わしいです。イーサリアム 1.x 上。
Phase 2 Proposal 1
デトリオの調査に続いて、ヴィタリック・ブテリンはフェーズ 2 の具体的な新しい提案、つまりフェーズ 2 提案 1 を提案しました。この提案では、実行スクリプト (当初は「ビーコン チェーン コントラクト」と呼ばれていました) がビーコン チェーンに保存され、ETH は (手数料を支払うために) 実行スクリプトに入金でき、ビーコン チェーンから離れることはありません。各シャードの状態と実行は完全に独立しています。
これらの名前は誤解を招く可能性があることに注意してください。実行スクリプトは、トランザクションを実行する仮想マシンを定義するルールであり、今日イーサリアムで見られるスマート コントラクトではありません。スクリプトを実行するには、クライアントが解析、測定、エンコード (ewasm コードなど) できる方法でデータ モデルとオペコードを定義する必要があります。
料金を支払うために、各実行スクリプトは本質的にレイヤー 2 システムであり、検証者はその内部支払いメカニズムを「知る」ことができません。これは設計上の欠陥ではなく、意図的なものです。シャード検証者がさまざまな料金メカニズム (さまざまな通貨が関係する可能性があります) を解析して計算する必要がある場合、これは間違いなく実装の難しさと経済メカニズムの大幅な複雑化につながります。 、悪用される可能性のある、または完全に使用不能になる可能性があるさらなる弱点を導入します。多くの場合、「経済的抽象化」に対する議論は、台本に従って料金の種類を定義するこのタイプの実行モデルに対しても使用できます (訳者注: 「経済的抽象化」は、「経済的抽象化」とも呼ばれています。プロトコル層は、ユーザーと検証者が手数料の支払いにどのトークンを使用するかをカスタマイズできるようにします（これによりネイティブ トークンの価値が失われると考える人もいます）。
バリデーターはスクリプトの実行から直接料金を徴収できないため、他の手段でサービス料金を取得する必要があります。これは特別な (つまり、祀られているタイプの) 実行スクリプトを使用して行われ、誰でも次のロジックを含むトランザクションを送信できます: 「特定の実行スクリプトを使用したこのデータが、特定のシャードの特定のタイムスロットにパッケージ化されている場合、私はこれを支払います」 「このデータ ブロックを記録した人への料金」。ここでの操作はすべてリレーラー (オペレーターとも呼ばれる) によって行われます。リレーラーは、暗号化されていない共通の実行スクリプトに従って指定されたユーザー トランザクションを収集する責任があります。料金は、ルールに従うと、シャード内のブロック提案者 (ビルダー) に、組み込まれた実行スクリプトに従ってパッケージ化されたトランザクションの対価が支払われます。
William Villanueva のブログ「A Journey Through Phase 2 of Ethereum 2.0」には、これまでのフェーズ 2 提案の完全な要約が記載されています。
Phase 2 Proposal 2
Detrio の以前の作業に触発されて、V God は再びフェーズ 2 提案 2 を提案しました。これは、提案 1 を簡素化し、シャード チェーン上の状態を削除し、ビーコン チェーンを使用してさまざまなシャードと実行環境 (以前は実行環境、EE と呼ばれていました) を追跡することを目的としています。実行スクリプト) 異なる状態のルート。
この設計の利点は、アキュムレータの形式を尊重する (祀る) 必要がある以前の提案とは異なり、異なる実行環境で独自のアキュムレータ (例: スパース マークル ツリー、赤黒ツリー、暗号アキュムレータなど) を選択できることです。 。
ここで、一般的なトランザクション フローは次のとおりです。ユーザーはトランザクションを作成して中継者に送信します。中継者は、ユーザーが支払いを受け取る必要があるときに証人 (マークル アキュムレータを使用している場合はマークル ブランチの形式で) を追加します。次に、リレーラーは複数のトランザクションをパッケージ化してブロック プロポーザーにまとめて送信し、プロトコルの組み込みメカニズムを通じてそれらに支払いを行うことで、プロポーザーがトランザクションのバッチを次の (シャード) ブロックにパッケージ化できるようにします。ここでの「プロトコルに組み込まれた仕組み」とは、提案 1 と同様に、すべての検証者が認識できる上位 EE (enshrined EE) を指します。
検証者にとって、このスキームは負担をある程度軽減しますが、上記の操作には依然としてある程度のシャーディング状態が必要であり、提案ではユーザーと中継者間のプロトコル内料金支払いメカニズムが設計されていないため、まだ解決されていません。中継ネットワークの問題。第一に、支払いを行うためにプロトコル外の手段を使用すると、ユーザーのプライバシーが弱くなり、第二に、ユーザーと中継者が確実にハンドインできるようにする完全なオフチェーン システム (別の外部ブロックチェーンに依存しない) を作成する方法が明確ではありません。 -hand お金は 1 つの手で受け渡されます (つまり、トランザクションのアトミック性)、3 番目に、支払いに合意外の手段を使用する潜在的な高いリスク、および中継者になるために必要な高い計算能力 (次のような場合があるため)リレーラーは EE またはシャードにサービスを提供したいと考えており、証人を生成できるようにするにはすべての状態を保存する必要があります)、集中化の問題が発生する可能性があります。最悪の場合、EE またはシャード間に少数の「ゲートキーパー」リレーしか残らない可能性があります。ユーザーとイーサリアム 2.0 ネットワークによる。
トランザクションバッファプールモードに戻る
Vitalik氏は新しい提案の中で、中継者がブロック提案者に条件付きで支払うことを許可するには、支払いのアトミック性を確保するために重い二重コミットメント方法が必要であるため、すべての問題を解決するには手数料市場EEを使用する方がよいと述べた。この提案では、EE は独自の残高を持ちます。 EE は一連のトランザクションを実行した後、領収書を出力し、料金の支払いを担当する上位 EE (祀られている EE) が、このデータに基づいて EE アカウントからブロック提案者にイーサリアムを送金します。したがって、料金を支払っている上位の EE は、以前の受領書を「遡って」、送金を処理することができます。 EE アカウントのリチャージは中継者 (または他の関係者) の責任となる場合があります。
この提案の利点は、中継者とブロック提案者の間で支払いを調整するために複雑な方法を使用する必要がないことですが、ユーザーが中継者とどのようにやり取りすべきかについては規定しておらず、支払いチャネルの使用を推奨しているだけです。 。
Villanueva 氏は、元の提案に基づいて、トランザクション バッファ プール モデルへの回帰を提案しました。この場合、リレーラーは状態プロバイダーとして機能する必要があるだけで、トランザクションをパッケージ化せずに証人を提供するだけです。ブロック提案者 (より一般的にはシャード検証者) はバッファー プールと、トランザクションをパッケージ化するために必要な証人データを維持します。各 EE は異なるアキュムレータを選択できるため、ブロック提案者が 2 つ以上の証人を統合できるように、EE は事前に証人をマージする固定方法を宣言する必要があります (複数のマークル ブランチを 1 つのマークル マルチ証明に統合するなど)。
状態プロバイダーは監視 (通常はマークル ブランチの形式) を提供するだけでよいため、このタスクにはすでに多くの役割 (ライト クライアント サーバーなど) が用意されています。より多くのライトクライアントサーバーを奨励して、より便利なツールとより低いコストを証人に提供することができ、これは高い信頼性を実現するのに大いに役立ちます。それでも、ユーザーにとって、摩擦の多い支払いチャネルを使用して州のプロバイダーに料金を支払わなければならないのは頭の痛い問題だ。
フェーズ 2 の代替アーキテクチャ
少し前に、Vitalik はシャーディング状態を完全に削除することを目的として、フェーズ 2 の代替アーキテクチャを提案しました。重要な点は、完全でステートフルで表現力豊かな状態遷移エンジン (EVM など) がビーコン チェーンに追加されていることです。このエンジンは、EE の状態ルートを追跡する「スケジューラー」として機能します。スケジューラの設計により、マルチシャード トランザクションの実行も可能になります。シャードとタイムスロットを所定の順序でチェックして、同じ EE へのシャードにわたる複数のトランザクションが正しく実行されていることを確認します (実行前状態と実行後状態のルートをチェックすることによって)。 、無効なシャード ブロックや順序が正しくないシャード ブロックは無視されます）。
この提案の料金支払いメカニズムは以前の提案から変更されていませんが、ディスパッチャーは EE 残高管理とレシート消費を処理する十分な能力を備えているため、特定の支払い料金 EE が存在する必要はなくなりました。
シャードチェーンの簡素化の提案
DevCon 5 カンファレンスで、Vitalik は、Near プロトコルのシャーディング ブロックである Nightshade の設計に触発された、イーサリアム 2.0 アーキテクチャの大幅な再構築を発表しました。新しい提案では、各シャード チェーンに独立したフォーク選択ルールの実行を要求する代わりに、ブロックとクロスリンクをインターリーブして、ブロックとクロスリンクをより高速に生成します。シャード内のブロックはビーコン チェーンに続きます。ブロックは一緒に生成され、すべてのシャードはクロスリンクされます。すべてのビーコン チェーン ブロックに接続されます (通常の状況下)。このアーキテクチャではシャードのクロスリンク数が増加し、クロスリンク数の増加に応じてシャード数が 1024 から 64 に減少し、同時に各シャードのスループットも向上し、システム ボリューム全体のスループットは元のレベルのままです。
前述の思考モードの根本的な変更により、料金市場がよりシンプルになります。シャードの数が大幅に削減されるため、シャード間の通信が簡素化され、ユーザーは各シャードにイーサを直接保管し、受信者によるブロック支払いを直接提案できます（ EE を介して領収書を出力する前述の提案を介して再度)。
副題
思い出させる
イーサリアム 2.0 のリレー ネットワーク/料金市場に関する上記の議論は完全ではありません。
ユーザー、中継者、ブロック提案者にとって、誰もが適切な支払いインセンティブとサービスを必要としています。ユーザーは料金を支払うことで必要な証人を得ることができ、中継者は証人を提供するために料金を請求し、ブロック提案者はトランザクションをパッケージ化するために料金を請求します。中継者がブロック提案者に支払う方法 (または EE を通じて間接的に) は契約で宣言できますが、ユーザーはトランザクションがパッケージ化されていることを確認しながら証人データを取得したいと考えており、支払い方法はそれほど単純ではありません。
ユーザーにとって、優れた支払い方法とは、摩擦が少なく、異なるリレーラー間で簡単に切り替えられるものである必要があります。ただし、外部ブロックチェーンの支払いチャネルによっては、前払いデポジットと外部チェーンの稼働要件があり、理想的には、ユーザーの支払いの問題は契約内で解決できます。
前の点からの続きとして、中継者がユーザーを検閲することが困難になるはずです。残念ながら、証人は埋め込みアクセス リストから取得されるため、中継者がブラックリストに登録されるのを防ぐ方法はありません。
バリデーターは各 EE 内の支払い方法を「理解」する必要はありません。これは非常に複雑であり、展開と効率的な市場の確立にとって大きな障壁となるからです。
ユーザーには完全なノードを維持する義務はありません (たとえば、必要な監視を維持する必要はありません)。この提案はライトクライアントに非常に優しいものにしたいと考えています。
要約する
要約する
昨年を振り返ると、中継ネットワークと料金市場の調査を何度も繰り返し、検証者の負担を軽減し、アクセスフリーを確保しながら、ユーザーとライトノードに優れたユーザーエクスペリエンスを提供することに全力で取り組んでいます。可能な限りセックスにアクセスしてください。今後、フェーズ 2 の提案がさらに増え、イーサリアム 2.0 のあらゆる側面がさらに改善され、完成されることを期待しています。
注: 原文へのリンク:https://medium.com/
