意見: データ可用性エンジンとしての Eth2
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下から引用しました
イーサリアム愛好家 (ID: ethfans)
イーサリアム愛好家 (ID: ethfans)
、著者: Casey Detrio、翻訳者および校正者: Min Min & A Jian、許可を得て Odaily によって複製されました。
編集者注: この記事の元のタイトルは「フェーズ 1 と完了: データ可用性エンジンとしての eth2」でした。出版時 (2019 年 4 月)、著者はフェーズ 2 に代わる Eth2.0 のロードマップを提案するつもりでした。つまり、データの可用性を確保するためにシャーディングのみを使用する場合、そのようなシステムは有用か、有用にするためにはどの部分を追加する必要があるか、ということです。驚くべきことに、著者は 1 年半前、zk-rollup のようなシステムでは、最下層が「状態遷移の実行とデータの可用性がアトミックにバインドされている必要がある」ことを保証する必要があることに気づきました。たとえそれが非常に単純なステートレス実行であっても、実行する能力、さらに (著者は推論の層を通しても指摘しました) ユーザー エクスペリエンスを確保するために、まだ欠けている主な部分は、データをシャーディングする方法の手順です。 （この 2 点の理解は、今日でも最先端、あるいは先進的であるとさえ言えます）。料金プロトコルはフェーズ 2 仕様にまだ含まれていません。
ちなみに、この記事の著者であるCasey Detrio氏はEwasmチームのメンバーで、これまでもフェーズ2に多くのアイデアを提供してきた人物ですが、彼もEth2は「Eth1のコントラクトが確実に実現できることを保証する」ということを核に設計されるべきだと考えています。 Eth2 が到着すると通常どおり実行されます」 .0。彼は過小評価されている開発者です。
現在、Eth1 スループットを制限するボトルネックは状態の増大です。したがって、イーサリアムをスケーリングしたい場合、論理的には、独立した状態の 1,000 個のシャードにより、スループットが 1,000 倍向上します。
ただし、Eth1.x ルートから、Eth1.x はストレージ (ストレージ) とトランザクション データ (TX データ) の 2 種類のリソースのコストを大幅に調整したいと考えています。現在、ストレージの価格は割安であり、トランザクション データの価格は高くなっています。これにより、dApp 開発者はコントラクトを作成する際にトランザクション データよりも多くのストレージを使用するようになり、ストレージがスループットのボトルネックになります。この問題に対して提案されている解決策は、ストレージの価格を引き上げ、トランザクション データの価格を下げることです。これらのコスト調整により、開発者はストレージよりもトランザクション データを使用するよう奨励されます (つまり、開発者はステートフルなコントラクトではなく、より多くのステートレス コントラクトを作成するようになります)。したがって、近い将来 (Eth1.x ロードマップが広く採用されれば)、Eth1 のスループットはストレージではなくトランザクション データによって制限されると予想されます。
スループットがトランザクション データによって制限されると仮定すると、Ethereum をスケーリングするために Serenity 上のシャードはステートフルである必要はありません。スループットがステートレス コントラクトからのトランザクション データによって制限されている場合、ステートレス シャードが 1000 個あるとスループットが 1000 倍増加します。
これは良さそうですが、シャーディングを通じて実装する必要があり、フェーズ 2 まで待つ予定です。同時に、フェーズ 1 をデータ可用性エンジンとして使用できます。データ可用性エンジンという用語が人気を集めているようです。それがどのように機能するかを考えてみましょう。
zk-rollup を例にとると、zk-rollup はデータの可用性によって制限されます。 Eth1 の zk-rollup コントラクトは、Eth2 をブリッジング可用性保証プロバイダーとして効果的に使用できますか?実行中にデータの可用性が保証できない場合 (つまり、SNARK プルーフの検証とステート ルートの更新)、プラズマのような zk-rollback システムが使用されることになります。このシステムは TPS を大幅に改善できますが、複雑なトレードオフが発生し、オペレーターの課題やプラズマなどの終了メカニズムに対処する必要があります。可用性の課題では、可用性を証明するために誰でもデータを提供できるため、ブリッジされた Eth2 シャードにデータを置くことが事態を容易にするかどうかは明らかではありません。
zk-rollup の別のバージョンである 500 TPS zk-rollup を使用すると、すべてがはるかに簡単になります。指定されたオペレーターは必要なくなり、いつでも誰でも中継者として機能し、SNARK プルーフを生成して状態を更新できます。実際、データの可用性の保証には常に状態の更新が伴います。これは、オペレーターの課題やプラズマのような終了メカニズムに対処する必要がないことを意味します。ただし、これには実行とデータの可用性の両方が同じトランザクション内で発生する必要がありますが、残念ながらブリッジされた可用性エンジンではこれを行うことができません。言い換えれば、ブリッジングは、zk-rollback のような不正証明システムには十分ですが、zk-rollup のような正当性証明システムには十分ではありません。結論として、レイヤー 2 での妥当性証明を簡素化するために、レイヤー 1 の可用性エンジンが持つ必要がある重要な機能は、データの可用性と状態遷移の実行が同時に確実にアトミックに発生することを保証することです。
おそらく私たちはこの認識に驚くべきではないでしょう。 (実行なしで) データの可用性だけが役立つのであれば、フェーズ 1 がゼロ以外の BLOB (バイナリ ラージ オブジェクト) の束の可用性を確保するためだけに開始されたと誰も異論はないだろうし、Eth2 が次の段階が本格的に始まります (PoS を除く)。データ可用性エンジンとしてフェーズ 1 に取り組んでいますが、まだ何も行われていないため、残念です。 (すごい、マスターコイン 2.0 を構築できる!)
では、なぜフェーズ 1 が実行と競合するのでしょうか?そうですね、ステートフルな実行を想定すると、各シャードは何らかのローカル状態を維持します。バリデーターが多くのローカル状態を維持する必要がある場合、バリデーターのシャッフルはさらに複雑になります。逆に、実装がない場合は、ローカルの状態について心配する必要はありません。 Validator シャッフルははるかに単純になり、データ BLOB を使用したシャードの構築に集中でき、シャードをより速く開始できます。
ただし、実行がステートフルであるとは想定しないでください。非常に単純なステートレス仮想マシンでそれを実行しようとするとどうなるでしょうか?
ビーコン チェーン状態に 3 つの新しいバリデーター フィールド (code、stateRoot、deployedShardId) があるとします。 process_deploy 関数もあります (process_transfer のすぐ下)。コードがデプロイされたら、検証者はアカウント残高が特定のしきい値（少なくとも 1 つの ETH がロックされている）を下回っていないことを確認する必要があります。コード内に自己破壊プログラム (SELFDESTRUCT) がない場合、ETH のこの部分は破壊されたものと同等となり、コードは永続的にデプロイされます。
ここで、グローバル状態のコードを持つアカウントがすでにいくつかあると仮定します。
次に、特定のデータ BLOB をシャードにパックしようとしますが、どのようにするのでしょうか?私の知る限り、フェーズ 1 シャード検証者にとって、どのデータ BLOB をシャード ブロックにパックするかを決定することはまだ未解決の問題です。これはフェーズ 1 仕様に詳しく記載されていないと仮定します。ユーザーが自分のデータ BLOB をシャードに詰め込みたい場合、方法は 2 つしかありません: (1) 検証者に連絡し、その支払いに送信する; (2) 自分自身が検証者になれば、(彼らがそうするときに)シャードのブロック提案者としてランダムに選択されます）データ BLOB をシャードにパックします。これらの方法はどちらも悪い考えです。
より良いアプローチは、物事をテーブルに上げ、バリデーターが取引合意を通じて現在のブロック提案者に支払うことを許可することです。その代わりに、ブロック プロポーザーはバリデーターのデータ BLOB をシャード チェーンにパッケージ化します。ただし、ビーコン チェーン ブロック操作 (バリデーター転送など) に最小容量要件がある場合、このアプローチは機能しません。 「データ可用性エンジンとしてのフェーズ 1」のユースケースは、バリデーターがデータ BLOB パッキングを優先できるトランザクション プロトコルがなければ不可能です (ビーコン チェーンにブリッジ経由で接続された eth1 コントラクトであっても、Truebit、Mastercoin 2.0、または以前に聞いた他のデータ可用性のユースケース)。とにかく、シャード プロポーザーが「実行なしのデータ可用性エンジン」モードでデータ BLOB をどのようにパックするかに関係なく、「単純なステートレス実行を使用するデータ可用性エンジン」モードにすることもできると仮定しましょう。
さて、特定のデータ BLOB をブロックにパックできるとしましょう。各ブロックは、実行を 1 つのトランザクションに制限します (たとえば、データ BLOB 全体が 1 つのトランザクションとして含まれる必要があります)。トランザクションがキーで署名されるか (トランザクション契約がある)、署名する必要がない (トランザクション契約がない) かはまだ明確になっていません。後者を想定すると、コードは独自の署名チェックを実装します (アカウントの抽象化と同様です。ブロック ガス制限はありますが、料金送金メカニズムがないため、ガス価格も GASPAY オペコードもありません)。 BLOB がトランザクションとして正常にデコードできた場合、データと現在の状態ルートを入力としてターゲット アカウント コードが実行されます。実行が成功した場合、返されるデータは新しいステート ルートです。
バリデーターアカウントの stateRoot を更新するにはどうすればよいですか?各シャード ブロックの BeaconState (ビーコン チェーン状態) の状態ルートを更新することはできません (ビーコン チェーン操作の数が厳密に制限されているため)。ただし、ビーコン チェーンの状態のフラグメンテーション フィールドはクロスリンクで更新されます。同じシャード上のすべてのアカウントの更新された状態ルートを取得し、それらが shard_state_root (シャード状態ルート) を取得するためにハッシュされると仮定します。 shard_state_root は、すでにフェーズ 1 デザインにある Crosslink_data_root に似ているように見えます (どちらも前のシャード ブロック コンテンツのハッシュに依存します)。
確かに、ビーコン チェーン ブロックがマイニングされるたびにすべてのシャード状態ルートが更新されるわけではないため、何らかのローカル状態が存在します。ただし、アカウントがグローバルの場合、状態ルート データは最小化されます。これは、シャッフル中にバリデータ間でシャード ブロック データを転送する必要があるのと似ています。
もちろん、ここでは多くの詳細は省略します。私が伝えたいのは、ステートレス実行の要件のほとんどはフェーズ 1 で満たされているようだということです。私の意見では、最大の問題は、ユーザーがチェーン上で BLOB をどのようにパッケージ化できるかがまだ明確になっていないことです (この問題が解決されない場合、フェーズ 1 はブリッジ ユーザビリティ エンジンになり得ません)。おそらくこれは最初の問題にすぎず、私が見落としている他の重大な問題があると思われます。私には何が欠けているのでしょうか？フェーズ 1 (または必要に応じてフェーズ 1.1) で、ユーザーがオンチェーンで BLOB を何らかの方法でパッケージ化できるようにする際に最も難しい点は何ですか?
