イーサリアムフェーズ 2 の進捗状況 (2019-12)

以太坊爱好者

特邀专栏作者

2019-12-17 09:00 (UTC+8)

この記事は約8647文字で、全文を読むには約13分かかります

イーサリアム 2.0 フェーズ 2 の作業は引き続き進んでいます。この記事では、現時点での最新の展開について説明します。

AI要約

イーサリアム 2.0 フェーズ 2 の作業は引き続き進んでいます。この記事では、現時点での最新の展開について説明します。

編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下から引用しました

イーサリアム愛好家 (ID: ethfans)

、著者: Will Villanueva、翻訳および校正: A Jian & Zeng Mi、Odaily が許可を得て転載。

イーサリアム 2.0 フェーズ 2 の作業は引き続き進んでいます。この記事では、現時点での最新の展開について説明します。フェーズ 2 の作業のほとんどは、イーサリアム財団の Ewasm チームと Quilt チームの共同作業で行われました。

この記事の各部分の内容は異なる分野を指している場合が多く、交差する部分も少ないため、お好みの部分を選択して読んでください。この記事を読む前に、次の資料を通じて Phase2 と実行環境提案 (EE) の背景知識を理解することを強くお勧めします。

Eth 2 フェーズ 2 とフェーズ 2 テストネットへの道 (これは Devcon 5 での講演と講演に使用されたスライドです)

EthHub によるイーサリアム 2.0 フェーズ 2 の詳細な解釈

Eth2 Phase2 を旅する (一部の知識ポイントは古い)

Ewasm 2.0: Eth2.0 における州の強制 (上級者向け)

最初のレベルのタイトル

フェーズ 2 に影響を与えるプロトコル層の変更

Vitalik の提案 2 は、提案 1 とステートレスプロトコルとしての Eth2 の新しい概念を改良したものです (このブログ投稿には「シャードチェーンにステートは必要ありません」というタイトルのセクションがあり、ステートレスとは何かについて簡単に説明しています)。

現在のフェーズ 2 の設計は、提案 2 のアイデアから大きく逸脱していません。歴史的には、ビーコンチェーンの負荷分散の概念が導入されたときに、提案の一部が変更されました。この負荷分散の考え方は、シャードチェーンを純粋なコンピューティングプロセスとして理解し、事前に指定されたシャードチェーン上で EE を動的に実行できるようにすることを提案しています。基本的に、このアイデアは、ビーコンチェーンで定義された負荷分散コントラクトを通じて、さまざまなシャードチェーンへのコンピューティング負荷のバランスをとろうとするものです。この設計コンセプトは非常に興味深いものであり、協調するリレーラーを通じて複数の異なるモードのクロスシャード同期トランザクションを実現できることを強調する価値があります。信頼できるものであれば、将来 (おそらくオンラインになった後) にこのツールをシャードチェーンに追加することができます。

最初のレベルのタイトル

Scout

私たちはプロトタイプの構築と実行環境の初期実装において大きな進歩を遂げました。まず、実行環境がステートレスモードで動作できることを確認する必要があります。この実行環境に必要な証明/証人データの量は多すぎますか?証明を使用して状態遷移を実行するには時間がかかりすぎますか?これらの疑問に答えるために、私たちは多くの実行環境を作成し、それらを使用してこれらの疑問を研究してきましたが、その前に、プロトタイプを構築するためのエンジン、Scout が必要です。

副題

Scout は、Ethereum 2.0 フェーズ 2 の実行プロセスプロトタイピングエンジン (もともと Alex Beregszaszi によって開発されました) であり、Ewasm API のラッパーを開発したため、開発者はそれを使用して実行環境のプロトタイプを構築し、ベンチマークテスト (ベンチマーク) を実行できます。また、アセンブリスクリプトと C++ ポートもあります。

副題

Eth1 に関連する EE

Eth1 から Eth2 への切り替えをサポートするには、Eth1 の状態遷移ルールを Eth2 の実行環境に作成する必要があります。この切り替えの主な課題は、Eth1 をステートレスモデルに変換し、次に EVM とトランザクション/アカウントモデルを実行環境に変換することです。以下で説明する EE は、Eth1 EE の前身です。最近、Eth1 EE 周りの開発に重点を置くワーキンググループが設立されました。彼らは初期の作業計画をまとめ、親切にも倫理研究フォーラムで自己紹介をしました。

無国籍メルケル・パトリシア・ツリー (SMPT) トークン

主なソース: Github、Devcon 5 での Sina Mahmoodi のプレゼンテーション

ステートレストークン EE の最初のプロトタイプは、Eth 1.0 のアーキテクチャを模倣することを目的としています。パリティのコードベースを使用して、Eth1 状態ツリー (Hexary Merkle-Patricia Trie) と RLP エンコードルールを実装します。また、リレーラーが一連のトランザクションに対して複数のプルーフを生成できるようにする、基本的なリレーラーの実装も組み込まれています。

ベンチマーク: 70 トランザクションおよび 5000 アカウント/リーフノード

Turbo Token

所要時間：5秒

証拠サイズ: 235 kb

執行の実行と証拠のサイズには依然として大幅な改善が必要ですが、これらの初期の結果からも進歩が明らかです。問題の 1 つは、Parity の Rust ライブラリを wasm コードにコンパイルすることに関係しており、その結果、多くの memcopy (メモリコピー) 操作やその他の非効率が発生しました。一般に、Rust を Web アセンブリにコンパイルするのは非常に難しいことがわかっています。また、署名検証項目に要した時間は 4 秒 (合計 5 秒中) でした。

主な情報: Turboproof の概要 (編集者注: 中国語訳については記事末尾のハイパーリンクを参照)、Turboproof Rust Github、Turbo Token Github、Guillaume Ballet の Devcon 5 スピーチ、Sina Mahmoodi の Devcon 5 スピーチ

Turbo Token モデルで使用される Turboproofs テクノロジーは、Eth1 ステートレスライトクライアントを実装するために Alexey Akhunov によって最初に研究されました。Eth1 データツリーのマルチプルーフを効率的に生成、マージ、シリアル化でき、単一操作 (シングルパス) も効率的にサポートします。データツリーを更新します。 Casey Detrio と Sina は、アセンブリスクリプトと Rust で最初の単一ブランチプロトタイプを開発し、ターボプルーフが十分に効率的であることを検証しました。最初に単一ブランチのプロトタイプで満足のいく結果を得た後、Casey は、アセンブリスクリプトを使用して、シンプルで最も基本的に使用可能なターボプルーフトークン EE を実装しました。 Sina Mahmoodi はこの実装をコピーし、Guillaume のターボプルーフの完全な Rust コードベースとジェネレーターを typescript に移植しました。

ベンチマーク: 70 トランザクションおよび 5000 アカウント/リーフノード

経過時間: 140 ミリ秒

証拠サイズ: 50 kb

EVMインタープリタEE

要約する

Eth1 EE をサポートするには、実行エンジンで (Web アセンブリが利用可能な) EVM インタープリターを開発する必要があります。 Hugo はプロトタイプを作成し、add および mul256 コントラクトを中心にテストしました。将来的には、このプロトタイプを改善するために、より多くの契約とベンチマークを導入する必要があります。

要約する

上記のすべての実験作業は、Eth1 実行環境の実装を作成することです。プロトタイピングの構築を開始しましたが、パフォーマンスに関して考慮すべき問題はまだたくさんあります。前述したように、ワーキンググループは最近、Eth1 EE の開発と Eth1 ステートレスモデルの作成に重点を置き始めました。

C Merkle Token

副題

Eth2を中心としたEE

このセクションでは、Eth1 -> Eth2 移行用に完全に開発されていない EE を紹介します。 Eth2 は、Eth1 で使用されるトランザクション、アカウント、およびアキュムレータモデルが最適ではないため、Eth1 のアカウントおよびトランザクションモデルとは異なる新しいアカウントベースの実行環境を使用します。さらに、楽観的ロールアップや ZK ロールアップなどのモデルも検討する必要があります。 Eth2 EE の設計空間は広く開かれており、以下に初期のアイデアとプロトタイプを示します。

主な情報: Github、Devcon 5 プレゼンテーション

Paul Dworzanski による、(スパースマークルツリーの代わりに) バイナリマークルツリーを使用したステートレスマークルトークンの C 実装。データツリーの検証と更新には最適なメモリ配分を使用し、独自のマルチプルーフ形式を整えます。このモデルの検証およびデータツリーの更新操作は 1 パス (シングルパス) で完了し (したがって、メモリコピー操作 (memcopy と複製) が回避されます)、Eth1 の 16 進データツリーで使用できる可能性が非常に高くなります。ただし、データツリー更新アルゴリズムが Eth1 データツリーで使用できるかどうかは明らかではありません (Eth1 ベースのモデルは一般に複数のパスを使用するため)。

ベンチマーク: 証明に関与した 222 アカウントのうち 40 アカウント

ZK Rollup

経過時間：20ms（署名検証を除く）

証拠サイズ: 25 kb

Shard Ether (Sheth)

現在、テストで使用されている実装はすでに最も効率的です。署名検証はベンチマークには含まれていませんが、余分に 30 ミリ秒しかかからないと推定されています。さらに、計算時間とサイズを削減するためのハッシュと証明のキャッシュなど、さらに多くの最適化ソリューションがあります。適応型ハッシュ長スキーム (ネットワークが成長するにつれてハッシュの長さが増加する) により、プルーフサイズをさらに削減することもできます。最後に、ハッシュ関数の実装が改善されると、計算時間が短縮されます。

主な情報: 一般的な ZK ロールアップの概要 (編集者注: 中国語訳については、記事の最後にあるハイパーリンク「ZK ロールアップとオプティミスティックロールアップ」を参照してください)、Devcon 5 のスピーチ、EE Stark Verifier の例、WASM Proof Verifier、Web Snarks

ZK ロールアップはレイヤー 2 拡張ソリューションであり、複雑な終了チャレンジメカニズムやロックメカニズムを使用しないため、既存のレイヤー 2 ソリューションでよくあるユーザーエクスペリエンスの問題を回避できます。ここにリストされている他のトークン転送スキームと比較して、ZK ロールアップはデータ可用性の要件を大幅に緩和します。ここにリストされている実装では、Web Snark を使用しています。Web Snark は、Snark 検証やその他のペアリング機能に使用できる wasm に実装されたジェネレーターです。 EE を開発するために、Jared はウェブスナークを適応させ、Groth16 証明を検証するための別の wasm ライブラリを開発しました。この EE はまだ初期のプロトタイプであり、引き続き開発する必要があります。

主なソース: Github、Matt Garnett の Devcon 5 講演、Internal Quilt 講演 (詳細)、SSZ 概要

Sheth は Eth2 コントラクト EE の前身です (Eth1 に基づいていますが、wasm/Eth2 により適したものにするために反復されています)。 Sheth は、Eth2 で使用される Simple Serialization Encoding 仕様 (SSZ) に基づいています。これは、スパースマークルツリースキームを使用し、ターボプルーフオペコードを借用しますが、読み取り、書き込み、および更新の要件を管理するために別の形式を使用します。 Diederik Loerakker の設計思想は、オフセットのリストを保存することによってデータツリー全体を走査する方法を決定することです。スパースマークルツリー証明の強みは、参照しているデータの全体的なインデックスをコンパイル時に静的に定義できることです。また、ノードが削除されたり、データツリーに挿入されたりすることがないため、状態の更新に必要なロジックも大幅に簡素化されますが、そのためにはいくつかの犠牲 (高強度のハッシュ計算) が必要になります。 Sheth には、リレーラーまたはステータスプロバイダーとして機能するコマンドラインクライアントも含まれています。

ベンチマーク: 50 アカウントと 50 トランザクション

証拠サイズ: 517 kb

SimpleUmbrella — Eth2 スマートコントラクト EE

主な資料：Eth Researchフォーラムでの提案、実行コードホスト機能PR

最初のレベルのタイトル

Ewasm - インタプリタ、コンパイラ、および計算メトリクス

副題

翻訳者

副題

通訳者

副題

計算メトリクス

Paul Dworzanski は、Devcon 5 の講演でこの領域を詳しく調査しました。計算を測定するために、wasm コントラクトがデプロイされ検証されるときに、use_gas 呼び出しは (EE またはアンブレラ EE で実行されているかどうかに関係なく) wasm バイトコードを挿入します。インジェクションと検証の複雑さは、間違いなく契約の導入コストに影響を与えます。現在のベンチマークでは、コンピューティングメトリクスを挿入した後、wasm コードの実行が 1.04 ～ 2.4 倍遅くなっていることが示されています。インジェクションプロセスとレジストリアセンブリのより良いパターンをベンチマークすることで、さらなる最適化が可能になります。

Lighthouse クライアントのフェーズ 1 および 2 プロトタイプまたはフェーズ 2 シミュレーション

私たちは、フェーズ 1 と 2 のクライアントが最終的にどのように構築されるのか、実装を開発しているチームがどのようにサポートされるのかをシミュレーションしたいと考えていました。また、この作業を使用して、現実世界の環境で複数のシャードにわたって実行される EE をシミュレートおよびテストしたいと考えています。 Devcon 5 中に、私は構築したシミュレーションについて講演しました。 Lighthouse クライアントで非常に単純なフェーズ 1 プロトタイプ (ネットワークコンポーネントは追加されていない) を開発/導入し、クライアントにフェーズ 2 Ewasm ランタイムを組み込みました。私たちは Sheth と対話し (Sheth はリレーラーおよび状態プロバイダーとして機能します)、Lighthouse で基本的な EE またはトークン転送をシミュレートできます。

Lighthouse クライアントは現在も積極的に開発されているため、Lighthouse クライアントのフォークを維持し、その上で開発するのは、当初考えていたよりも難しい可能性があることがわかりました。そこで、最初のプロトタイプの要素を取り入れて、Scout 内で抽象的なスタブバージョンを開発することにしました。引き続きビーコンチェーンとシャードチェーンの動作のシミュレーションを続けますが、実行環境の調査とシャード間のベンチマークに重点を置いているため、ロジックを大幅に簡素化できます。この部分の作業は、Quilt チームの 2 人の新しいメンバーによって管理されています。

最初のレベルのタイトル

ジョン・アドラーは、このトピックに関して非常に包括的な概要を書いています。彼の記事では、Eth2 提案の興味深い進化についても述べています。要約すると、Vitalik の最新のシャーディング簡素化提案は、そもそもリレーラーモデルで抱えていた問題の多くを解消します。ただし、状態プロバイダーがトランザクションをブロックプロデューサーに送信する方法や、ブロックプロデューサーがトランザクションバンドルを適切なマルチプルーフにどのように組み込むかについては、まだ多くの未解決の疑問があります。提案の 1 つは、プルーフマージスクリプトを使用して新しい実行環境をデプロイすることです。

最終的に、リレーラーまたは状態プロバイダーは、web3.js または ethers.js が接続されている RPC エンドポイントを継承します。複数の EE にわたるこれらの操作に対する一連の標準を策定することが重要です。

最初のレベルのタイトル

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

副題

非同期クロスシャードトランザクション
Vitalik の最新のフェーズ 0 および 1 の提案は、クロスシャードトランザクションとコンポーザビリティの両方にとって朗報です。新しい提案では、シャード間通話は 1 タイムスロット (6 秒) の遅延のみで完了できますが、以前の提案では、通話が完了するまでに 12 ～ 18 分の遅延を待つ必要がありました。したがって、シャード間での状態 (または eth) の転送は非常に高速になります。以前は、呼び出しを高速化するために楽観的なルートを使用したいと考えていましたが、これらのソリューションは非常に複雑であることがわかりました。
dApp 開発者の観点から見ると、クロスシャード呼び出しは、マルチスレッドプログラミングの非同期パラダイムとメソッドに従うだけで済みます。スマートコントラクトを作成する場合、HLL (Slodity) と DSL (Vyper) は、シャード間の動作を非同期パラダイムに抽象化するために必要なツールを提供する必要があります。スキーマ全体はおそらく次のようになります。
単純な非同期呼び出し (非同期待機、コールバックなど)

二相確認（原子性）

ロック - 読み取り/書き込み (コントラクトヤンキング)

EE または基礎となる契約でこれらのパターンをサポートする方法については、さらなる研究が必要です。上記のシミュレーション (および後述のオーケストレーションツール) は、これらのモデルを使用した実験の基礎を提供するはずですが、実際には、これは重要な研究分野であり、人々が喜んで参加してくれるのであれば、私たちはそうするでしょう。とても幸せになってください。この投稿で説明されているように、前処理および後処理の動作を下位レベルで指定すると、契約内の実行を一時停止し、その後継続するための合理的なフレームワークが提供される可能性があります。

シャード間トランザクションを同期する

以前、Vitalik は州の計画について議論する投稿を公開しました。これらのソリューションの本質はチェーン上のレイヤー 2 モードであり、フラグメンテーションはデータ可用性レイヤーとしてのみ使用されます。これらのモデル (つまり、以前は伝説的だった「遅延状態実行」モデル、「遅延実行」モデル、または「シャドウチェーン」) は、実際には、いわゆるオプティミスティックロールアップの前身です。オプティミスティックロールアップスキームのデータ可用性レイヤーとして複数のシャードを使用すると、シャード間でトランザクションを同期できるようになります。近い将来、このコンセプトに基づいたプロトタイプが開発されるかもしれません。

副題

本当にシャード間で呼び出しを行う必要があるのでしょうか?

さらなる研究に値するもう 1 つの観点は、Eth2 の本体はステートチャネル、オプティミスティックロールアップ、および zk ロールアップ (これらのスキームが成熟した後) に傾くべきであるということです。この考え方では、Eth2 自体がデータ可用性レイヤーであり、クロスシャード呼び出しは、これらのスキームをブリッジするとき、または出口チャレンジ/偽証明中にのみ使用されます。ロールアップは Eth1 または Eth2 実行環境の境界内で定義する必要がありますが、計算はエラー証明を送信する必要がある場合にのみオンチェーンで実行する必要があります。

最初のレベルのタイトル
フェーズ 2 ツールチェーン
研究を進めるために、開発者が使用する必要があるツールチェーンを提案します。上記の「Lighthouse のフェーズ 1 およびフェーズ 2 プロトタイプ」セクションで述べたように、シャード間で実行環境をテストおよび実行するための一連のシミュレーションを積極的に開発しています。ただし、スマートコントラクトの動作モードを最適化するには、多くのオーケストレーションツールを追加する必要があります。この投稿では、これらのツールについて詳しく説明します。
フェーズ 1 および 2 のシミュレーション
フェーズ 1 クライアントのランタイム環境を挿入します。