原作者：Zhixiong Pan
原作者：
「イーサリアム上海アップグレードサミット」イベントでは、イーサリアムエコシステムの全く異なる4つの拡張ソリューションチームを招き、イーサリアムの最先端技術についてお話しいただきました。
特に EOF と EIP-4844 は、おそらく次のアップグレード (カンクン) に含まれるでしょう。さらに、分散型シーケンサーとモジュール型ブロックチェーンの物語も、研究者がより懸念している新しい方向性です。
これら 4 つのチームは、ゼロ知識証明の分野に注力している (特に zkEVM)、WASM と動的拡張に注力している、Move 言語とモジュール化に注力している、汎用ストレージに注力しているなど、それぞれの特徴があります。さらに、他の技術的な詳細にも多くの違いがあります。
Dorothy Liu from AltLayer
Jolestar from Rooch Network
Qi Zhou from EthStorage
Ye Zhang from Scroll
TLDR
このディスカッションに参加しているのは次のとおりです。
EOF アップグレードはアプリケーション開発者にはあまり影響を与えませんが、ロールアップと zkEVM にはある程度の影響を与えます。 EOF がアップグレードの次の段階に入るかどうかについては、まだ議論があるかもしれません。
分散型シーケンサー向けのいくつかのソリューション: Byzantine Fault Tolerance (BFT)、MEV オークション、共有シーケンサー (Flashbot)、VDF など。さらに、公平な仕分けは公平ではない可能性があり、アプリケーションには異なる戦略を採用する必要があります。
EIP-4844 の目的は、容量を拡張することではなく、Blob とそのデータ ハッシュを含む、将来の Danksharding に必要な一連の概念を実現することです。これらの概念を事前に実装して、ダンクシャーディングの実装時に契約のアップグレードが必要ないようにします。 EIP-4844 は、現在のイーサリアム データ オンチェーン方式に比べて大幅な改善はもたらさず、それらがもたらす帯域幅は基本的に同じ桁です。
モジュラー ブロックチェーンについては人によってまったく異なる視点があります。ファット アプリケーションの時代には、最も重要なデータ層であるより多くの選択肢が提供される必要があると考える人もいます。
ハードコア学習教材
以下は、OpenAI Whisper によって翻訳され、GPT-4 によって処理されたディスカッションの全文です。一部の調整と削除が含まれています。
Zhixiong Pan：
トピック 1: EOF (イーサリアム オブジェクト フォーマット)
イーサリアム オブジェクト フォーマット (EOF) は当初、上海アップグレードで実装される予定でしたが、現在は延期されています。 EOF の本質は、EVM のバイトコード機能とスマート コントラクトの将来のアップグレードに役立つ、イーサリアムのセルフバイトコードのプレデータ構造を提供することです。
Dorothy Liu：
このアップグレードは、レイヤー 2 またはロールアップ エコロジー全体により大きな影響を及ぼしますか?特に、ロールアップ エコロジーは基本的にイーサリアムのレイヤー 1 にいくつかのスマート コントラクトをデプロイすることになるため、このアップグレードはレイヤー 2 に関連する技術的な選択とパスに影響を与えるのでしょうか?
AltLayer チームの見解では、EOF はそれほど重要なイノベーションではありません。これは EVM のパッケージング モデルに対する重要な改善ですが、Solidity 言語の記述には直接影響しません。したがって、アプリケーション開発や開発全般の観点から見ると、この変更による影響はほとんどなく、多くの開発者でもこの点を理解していない可能性がありますが、問題は発生しません。
ただし、Rollup の場合、Rollup は本質的にイーサリアムの実行層であるため、その影響は非常に大きくなります。イーサリアムが変更されると、それに応じてロールアップを調整する必要があります。 zkEVM は技術的に比較的難しいため、この EOF 変更は zkEVM に大きな影響を与える可能性があります。 EVM 互換性分類では Type-3 に該当するため、より高い互換性を追求するにはさらなる努力が必要です。書き直しや大幅な変更が必要になる場合もあります。
Ye Zhang:
ただし、オプティミスティック ロールアップ プロジェクトを行っている私たちにとって、WASM で書かれているか EVM で書かれているかにかかわらず、タイプ 1 互換、つまり EVM と完全な互換性があります。したがって、私たちにとっては難易度は非常に低いです。多少の修正は必要ですが、難易度はかなり低いです。さらに、私たち自身の実稼働証明書はすべて WASM 内にあるため、私たちにとって実際の影響は大きくありません。
まず、EOF は確かに重要な技術開発だと思います。 EVM コアはそれほど頻繁にアップグレードされないため、zkEVM を頻繁に変更する必要はないという以前の意見がありました。しかし、最近の EOF では、EVM のコア ロジックを変更する他のアップグレードが行われる可能性があり、実際に zkEVM に影響を与えることになります。ただし、現時点では EOF には前方互換性があるため、以前の契約との一定の互換性がまだ残っています。少なくとも既存の契約と開発者にとって、直接的な影響は比較的小さいです。今後も注意が必要な点はあるかもしれませんが、少なくとも当社のレイヤー1契約に関しては大きな影響はないと考えられます。レイヤ 2 では、影響の程度は EOF をどの程度サポートするかによって異なります。レイヤ 1 の EVM と完全に一致させたい場合は EOF をサポートする必要があるため、確かに少し遅れます。
実際、zkEVM の開発時に、EOF のコア アップグレードに注目しましたが、これは予想よりも簡単でした。 zkEVM 全体を構築する際にモジュール設計を採用したため、オペコードを簡単に更新できます。 EOF の主な変更点は、バージョン管理とオペコードを追加することです。必要なのは、これらの新しいオペコードを実装し、回路にいくつかのラベルと変数を追加するなど、バージョン管理で適切な作業を行うことだけです。これらの変更はオペコード レベルで行われ、いくつかの回路の追加が必要になります。さらに、EOF はバイトコード展開に関するいくつかのチェックも実行します。これは、zkEVM のサブサーキット (バイトコード回路) に影響します。この回路では、入力ハッシュをチェックし、対応するバイトコードを出力する必要があります。この時点で確認する必要がある場合は、この回路にいくつかの制約を追加する必要がある場合があります。
Qi Zhou：
全体として、変更は必要ですが、完全なリファクタリングが必要になるほどではないと思います。イーサリアムは現在、zkEVM を非常に重要な地位に導き、彼ら自身がいくつかの重要な技術開発を主導しています。 Vitalik と EIP コア チームの一部のメンバーも、zkEVM に対するこのアップグレードの影響を理解するために私たちと連絡を取るなど、zkEVM チームの進捗状況を懸念していることを私は知っています。レイヤ 1 の各アップグレードには特定のリスクが伴うため、以前は各アップグレードは元に戻せない可能性があると考えられていました。したがって、アプリケーションや既存の技術への影響を少なくするために、レイヤー 1 はできるだけ安定していることが望まれ、決済レイヤーは安定しているほど良いと考えられます。レイヤー2では、さまざまなイノベーションを実行できます。ただし、レイヤー 1 を変更する必要がある場合は、レイヤー 2 もそれに応じて調整でき、特に大きな変更はないと思います。ただし、変更を実装し、場合によっては監査する必要があるため、多少の遅れが生じることは確実です。監査プロセスが完了するまでにさらに時間がかかる場合があるため、通常は変更をできるだけ少なくする必要があります。ただし、これらの変更はシステム全体に致命的な影響を与えるものではなく、重大な問題を引き起こすものではないと考えています。
EVM オブジェクト フォーマット (EOF) に関しては、イーサリアム コミュニティでも以前の議論で多くの関連トピックが取り上げられていることに気付きました。特に上海でのアップグレード中、イーサリアムはアップグレードプロセス全体に対していくつかの異なる態度をとっていることがわかります。たとえば、Danksharding の創設者である Dankrad は EOF についてある種の疑念を抱いています。彼らは、EOF は開発者にとって大きな変化はありませんが、主にコントラクトのセキュリティを向上させると考えています。この点で、彼らは今がイーサリアム拡大の最も重要な段階ではないと感じています。実際、EOF は拡張計画全体のほんの一部にすぎないため、この点に関しては多くの論争がありました。
しかし、なぜ今アップグレード プランに EOF を含める必要があるのでしょうか?それは、EOF が非常に長い間、おそらく 4 ～ 5 年、あるいは以前の社内議論ではそれよりも長く提起されてきたからです。 EOF を分析した結果、ダンクラッド氏の指摘のいくつかに非常に同意します。 EOF は、動的ジャンプの比較的危険な操作をキャンセルするなど、イーサリアム コントラクト全体に一定のセキュリティをもたらしますが、実際には、多数のイーサリアムの実際の操作とコントラクトの作成のプロセスにおいて、コンパイラーは根本的なエラーが発生しやすい問題を引き起こします。避けられる。したがって、近年同様の開発プロセスの飛躍による異常な契約執行は発生していません。
Jolestar:
EOFがカンクンのような次のアップグレード段階に入るのかどうかについては、イーサリアムのレイヤー2コンピューティング層に一定の影響を与える可能性を考慮すると、多少の議論はあるのではないかと個人的には考えています。次に説明する EIP-4844 と比較すると、EOF に関する見解の相違はさらに多くあります。
EVM Object Format (EOF) に関しては、主に 2 つの最適化が行われます。まず、スマート コントラクト コードの検証を開始し、展開時にそれを検証します。これはパフォーマンス向上に非常に効果的です。現在、多くのプロジェクトでは、展開フェーズでコード検証を実行するこの方法が採用されています。 2 番目に、EOF は拡張機能を提供します。今回のアップデートでは大きな変更は生じないかもしれませんが、この拡張メカニズムが提供されると、将来的には多くの拡張ニーズが発生する可能性があります。現時点では、革新的な拡張を求めるか、互換性を求めるかという選択を迫られるかもしれません。これは、事実上すべてのソフトウェア システムにとって常にジレンマです。
このように、EOF は実際に将来の変化への扉を開きます。たとえば、特定のレイヤー 2 機能を実装するために、新しいバージョンを追加したり、いくつかの新しい機能をスマート コントラクト コードに追加したりすることができます。このとき、レイヤー 1 との互換性に影響が出る可能性があります。このような変更は確かに非常に物議を醸す可能性があります。しかし、私の観点からは、まだ完全な凍結ではなく、この段階でも革新と進化が優先されるべきだと思います。もちろん、レイヤー 1 の場合、これは別の次元であり、レイヤー 1 とレイヤー 2 の判断は異なる可能性があります。
Zhixiong Pan：
トピック 2: 分散型シーケンサー (シーケンサー)
現時点では、ほとんどのレイヤ 2 ネットワークのシーケンサはまだ初期段階にあり、そのほとんどは単一のシーケンサです。一部のプロジェクトでは、将来的に分散型シーケンサーにアップグレードする予定です。
現在、分散型シーケンサーの合理的な設計はありますか?
レイヤ 2 ネイティブ トークンは分散型シーケンサーの要件となる可能性がありますか? Optimism/Arbitrum などは、独自のトークンを持っていますが、ガバナンス トークンとしてのみ使用できます。
Qi Zhou:
では、他に注目に値する最先端または初期の分散型シーケンサー ソリューションにはどのようなものがあるでしょうか?
最近、Arbitrum のシーケンサーなど、いくつかの関連トピックを検討しました。 Arbitrum コミュニティは、多数のノード (10,000 接続など) が Sequencer に接続して最新のトランザクション情報とアービトラージを取得するという大きな問題に直面しています。私たちは、このシーケンサーがニューヨーク証券取引所に似ているのではないかと社内でよく冗談を言いました。ニューヨーク証券取引所の近くには、光ファイバーを介して取引データを迅速に取得し、定量的な操作を実行するための定量ロボットが多数あるためです。このシーケンサー モデルにより、私たちは非常に集中化されたシステムに堕落するのでしょうか?
Dorothy Liu:
Sequencerの分散化をどう実現するかは非常に重要な課題だと思います。私が思いつく解決策としては、プルーフ オブ ステーク (POS) メカニズムを借用し、レイヤー 2 ネイティブ トークンをプルーフ オブ ステークとして使用することが考えられます。このようにして、イーサリアムで最近進行中の安全なリーダー選挙と同様のシーケンサーのローテーションを実現できます。これらのテクノロジーを組み合わせれば、この問題を解決するための成熟した方法が見つかると思います。
この質問により、Arbitrum と Optimism の開発の歴史に関する私の個人的な観察のいくつかを共有できます。昨年の初めにChainlink主催のRollupに関するイベントに参加するためアムステルダムに行ったのですが、その時はArbitrum、Optimism、zkSync、Metisの4チームが招待されていました。彼らの議論の焦点は主に拡張とパフォーマンスです。私は彼らに、コンセンサス レイヤーに関する見解と、ロールアップにコンセンサス レイヤーを追加する必要があるかどうかについて非公開で尋ねました。現時点では拡張のみを検討しているとのこと。楽観主義は当初この問題を考慮していなかったので、今さら変えることはできません。
私たちの観点から見ると、私たちはプロジェクトの最初から分散型シーケンサーを設計しました。私たちは、分散型シーケンサーを使用して、2 つの Dark Forest ゲームと 2 つの NFT Minting キャンペーンをイーサリアム メインネット上で直接実行しました。私たちの意見では、これは技術的な問題ではなく、歴史的発展の遺産です。稼働中のシステムのエンジンをどのように変更するかは、新しいプロジェクトが最初から完全に計画されていた場合よりも困難になるでしょう。
トークンの発行に関しては、Arbitrum と Optimism が独自のトークンがなくても運営できることを証明しました。トークンを持ちたい場合は、斬撃などのデザインが必要になる場合があります。私たちは来月、市場初の分散型シーケンサー ネットワークとなる分散型シーケンサー ネットワークをリリースします。その際、ステーキングやスラッシュなどのデザインもいくつかご用意させていただきます。
Ye Zhang:
最後にMEVですが、Sequencerとの2つの問題でございますが、両者の間には関係性がございます。分散型シーケンサーネットワークは、MEV の問題をある程度解決できる可能性があります。ただし、この問題は完全には解決されない可能性があります。現在、Arbitrum チームはランダム性の改善を追加するなど、いくつかの方法を実装していますが、これらの問題を完全に解決することはできません。また、将来的に発表されるハードウェアまたはその他の MEV ソリューションを提案する可能性もあります。
私たちはシーケンサーについて多くの研究を行ってきました。具体的なソリューションはまだ発表していませんが、設計に取り組んでいることは間違いありません。現在、主に 2 つの方向性があります。 1 つ目は、Tendermint を使用して以前の集中型シーケンサーに代わるリーダーを選択するなど、ビザンチン フォールト トレランス (BFT) に基づくスキームです。このアプローチでは、ステーキングとスラッシュが必要で、場合によっては PoS 用に独自のトークンを発行したり、他の再ステーキングや同様のメカニズムと組み合わせたりする必要があります。 BFT の利点は、非常に高速な事前確認を提供し、良好なユーザー エクスペリエンスを維持できることです。
2 番目のより有望なソリューションは、MEV オークション (オークション) です。楽観主義は最初に MEV オークションの概念を提案しました。つまり、最も高い価格を付けた人がブロックを生産する権利を得ることができます。ただし、このソリューションの欠点は、ユーザーが MEV ロボットの料金を高すぎる可能性があることです。
同様のスキームには、Justin Drake によって提案された Base Rollup が含まれます。その中心的なアイデアは、レイヤー 1 バリデーターを再利用してレイヤー 2 ブロックを生成することです。このようにして、レイヤー 1 ブロックとレイヤー 2 ブロックを構築するバリデーターは、レイヤー 1 ブロックを構築するときにレイヤー 2 検証トランザクションをレイヤー 1 ブロックに入れることができるため、全体の入札額が大きくなり、レイヤー 1 ブロックが最初に含まれるようになります。 。この方式の利点は、レイヤ 1 のインセンティブメカニズムとの整合性が高いことですが、欠点は、BFT のような事前確認がないため、ユーザーエクスペリエンスが低下する可能性があることです。
したがって、現在最も有望な方向性は、レイヤー 1 バリデータの再利用に基づくスキームと、BFT に基づくスキームです。レイヤ1バリデータを再利用しながら事前確認を提供するなど、こうした方向での課題解決に取り組んでいます。
分散型シーケンサーについてもいくつかの方向性があり、例えばFlashbotsなどがShared Sequencer（シェアードシーケンサー）と呼ばれる方式を提案しており、OptimismのSuperchainも同様の設計となっている。シーケンサーの共有の中心的なアイデアは、固定されたシーケンサーのセットを使用して複数のチェーンでトランザクションを処理し、クロスチェーン MEV を実現し、クロスチェーン UI のエクスペリエンスを向上させることです。ただし、この設計はまだ初期段階にあり、シーケンサー ノードの圧力やクロスチェーン トランザクションのアトミック性など、いくつかの重要な問題がまだ解決されていません。
共有シーケンサーは、分散型ネットワークを実行するのに十分な容量がない可能性がある多くの特定のアプリケーション シナリオ (小規模なリアルタイム アセット アプリケーションなど) にとって、将来的に価値がある可能性があります。ただし、大規模なリアルタイム アセット アプリケーションの場合、共有シーケンサーを使用するよう説得するのは困難な場合があります。
Flashbots は、情報取得によってもたらされる本質的な MEV 問題を解決し、ユーザーに一定の価値をもたらすために、プライバシー分散ネットワークを構築することで共有シーケンサーを実装しようとしています。ただし、スキームが完全に公開されていないため、上記の問題を克服できるかどうかを評価することは困難です。正統性の高い MEV プレーヤーとして、Flashbot の提案を公開した後、詳細に評価していきます。
トークンの必要性に関しては、主に使用されるコンセンサスアルゴリズムに依存すると思います。 BFTアルゴリズムを採用する場合はTokenが必要となる可能性が高いですが、既存のLayer 1 Validatorをベースとした方式を採用する場合は、他人のリソースを再利用できるため、必ずしもTokenが必要ではない可能性があります。こうすることで、価値の源泉は誰が賭けているのかということになり、MEV はネットワークバリデーターに直接送られるようになります。したがって、レイヤ 2 が MEV の付加価値をどのように考えるかが決定要因となります。
Tarun Chitra: Ordering So Fair It Ain't Fair Ordering
MEV の扱いに関しては、公正な順序付けによって MEV 問題をある程度解決できるという議論がありますが、実際には MEV 問題を緩和するだけかもしれません。優先順位を巡ってさまざまなボットが依然として競合している可能性があるため、状況は従来の商社の状況と似ています。ある程度のランダム性が導入されていますが、これはまだ完全には解決されていません。実際、MEV に関するある研究では、公平なランキングは不公平であると指摘されています。研究者らは、攻撃モデルを構築することで、公平なランキングの場合、ユーザー エクスペリエンスが悪化する可能性があることを証明しました。したがって、真の公平性を実現するには、アプリケーションごとに異なる並べ替え戦略を採用する必要がある場合があります。
興味深い実験もたくさんあります。たとえば、トランザクションは暗号化技術 (VDF など) によって暗号化され、トランザクションが確認された後に復号化されます。このように、取引の内容を事前に予測することは不可能です。さらに、タイムロックなどの方法もあります。つまり、私たちはこれらのソリューションにも注目し、改善しています。大まかな方向性はある程度出ていますが、それぞれの方向性にはさまざまな問題があります。したがって、計画を決定する前に厳密な分析を行い、計画の安定性を確保したいと考えております。シーケンサーには値の流れなど多くの問題があり、まだ完璧な解決策はないと考えています。これが、シーケンサーに関する研究を後回しにした理由です。
現在、分散型シーケンサーは検閲耐性に有益である可能性があるという一般的な感覚があります。しかし、今日の議論でも述べたように、実際にはブリッジングによって、トランザクションが第 2 層で強制されることを保証することができます。さらに、ほとんどの橋の設計では、トランザクションを含めないと 1 日何らかの形で影響を受ける可能性があると規定されています。ただし、ほとんどの分散型金融 (DeFi) は次の瞬間にあなたを清算し、その後直接あなたの取引を拒否する可能性があり、ユーザーに悪い経験をもたらす可能性があります。したがって、リアルタイムの検閲防止はユーザーと DeFi にとって非常に重要です。
もう 1 つの問題は、マイナー抽出可能値 (MEV) の問題です。たとえば、Arbitrum は現在、集中型シーケンサーを使用する先着順ポリシーを実装しています。人々の以前の指摘は、私が MEV で利用されていると知ったら、私はネットワークから離れるかもしれない、ということでした。その結果、人々はネットワークの正当性を信じられなくなります。しかし、大きな問題は、ネットワークが始まり、ネットワーク効果が徐々に現れてくることです。たとえば、単一のシーケンサー、エコロジーがある程度の規模に発展すると、課金を開始したり、MEV を検討し始めたりすると、ユーザーは実際に非常に依存するようになりました。他のプラットフォームに移行することは困難です。したがって、脅威は数年以内に来る可能性があり、彼らは潜在的な脅威である MEV を突然実装し始めます。
さらに、コンプライアンスの問題もあります。トークンが Proof of Stake (PoS) に関連付けられている場合、特定のコンプライアンス リスクに直面する可能性があります。たとえば、中央集権化を行っているときに、国からシリアライザーのシャットダウンや特定の問題の修正を求められた場合、分散化にはある程度のメリットがある可能性があります。
Jolestar：
したがって、私たちは非常に徹底的な分析を実施し、この方向に多くのエネルギーを投資しました。聴衆の中にプロトコル研究に興味のある方がいらっしゃいましたら、ぜひご参加ください。この分野の人材を募集しており、詳細な分析は後ほど公開します。
シーケンサーとしての BFT の導入については、全員がコンセンサスに達しました。実際、レイヤー 2 に BFT コンセンサスを導入する必要があります。私たちが注目するのは、このコンセンサスが何を決定するかということです。それが結果を直接決定するのであれば、それに直接決定させればよいのです。レイヤ 2 にはスケーラビリティを提供したいので、シーケンサを別の角度から検討します。私たちの主な目的は何ですか?一つは安全のためです。レイヤ 2 スキームでは、シーケンサーと、プロポーザーまたは同様の証明者または zk などの他のスキームでは、それらは異なる役割を果たします。 Sequencer と Proposer は運用状況では分離されており、不正行為をしたい場合は共同で不正行為を行う必要があります。たとえば、Sequencer はトランザクションを非表示にし、Proposer は偽のルートを作成します。役割が分離され、異なる組織が引き受ける場合、セキュリティは保証されます。
シーケンサーがレイヤー 1 に送信される前に、トランザクションの順序がシーケンサーによって調整される可能性があり、不正行為の余地が存在する可能性があります。この問題を解決するために、Sequencer に Sequence Prove と呼ばれる不正証明と同様の証明を提供させます。あなたは、コミットメントを与えて、トランザクションを適切な立場に置くことを正当化します。最後のリンクの順序がコミットメントと矛盾している場合、シーケンサーは異議を申し立てられ、罰せられる可能性があります。
最後に、BFT 投票を本当に導入したい場合は、トランザクションの結果ではなく、トランザクションの順序を決定する必要があります。既存のコンセンサスメカニズムは、最終的な実行結果の投票を決定するものであり、ブロックチェーンのトランザクション順序を決定するものではありません。したがって、この場合は、順序または公平性を重視したコンセンサスを導入し、トランザクションの順序について全員が投票できるようにする必要があるかもしれません。これは私たちが現在模索している方向性であり、Sequencer による分散化の解決策です。
Zhixiong Pan：
トピック 3: EIP-4844 (プロト ダンクシャーディング)
EOF に加えて、プロトコル層のアップグレードと拡張のもう 1 つの重要な実装は EIP-4844 であり、特に層 2 チームと密接に関連しています。今年の初めに KZG の Ceremony が開始されましたが、プロトコル層の追加には時間がかかる可能性があります。ロールアップ、ZK ロールアップ、または拡張の方向性について、レイヤー 2 チームが EIP-4844 を統合するのにどれくらい時間がかかると思いますか?
Jolestar：
EIP-4844 の統合に関して、どのような困難に遭遇すると思いますか?さらに、EIP-4844 の使用が GAS または全体的な拡張に及ぼす影響を推定しましたか?
私の理解では、EIP-4844 の統合は元のロールアップ スキームからあまり変わっていません。私たちは、より高い TPS とより低い料金のソリューションを探してきましたが、EIP-4844 だけに依存するだけではこの問題を解決できません。実際、これはトランザクション タイプである BLOB タイプを追加するだけですが、全体のブロック サイズ制限は引き続きベース レイヤーによって制限されます。数十万または 100,000 近くの TPS を持つ理想的なレイヤー 2 を実現したい場合でも、最初のレイヤーのトランザクションをブロックに直接配置することはできません。
Dorothy Liu：
したがって、私たちの現在の目標は、コストが低く、使いやすく、スループットが高いプロトコルの中から選択するために、さまざまなプロトコルを構成できるモダリティを実装することです。
まず、EIP-4844 アップグレードは、OP にとって統合するのが比較的簡単でしたが、zkEVM はより難しい可能性があります。 Zhang Ye は、このアップグレードについて専門的な回答を提供します。また、Monad と呼ばれるプロトコルを共有したいと思います。その創設者は Keone という名前で、Twitter で彼をフォローできます。ジャンプの開発者である Keone は、計算の才能を持つ数学の天才です。彼は Twitter に EIP-4844 プロトコルの開始に関する予測を投稿し、Arbitrum の TPS は約 160 まで増加する可能性があると予測しましたが、この数字が重要かどうかは見る人次第です。彼の計算方法に改善の余地があるかどうかは議論の余地がありますが、EIP-4844 はある程度までしかパフォーマンスを向上させることができず、最終的には依然として EIP-4844 とロールアップの組み合わせに依存しており、改善するには複数のロールアップが必要になる可能性があると考えられます。パフォーマンス。 EIP-4844 自体はあまり解決しません。
Ye Zhang:
私たちにとって、私たちが提供するサービスは「サービスとしてのロールアップ」と呼ばれています。Zhang Ye 氏が述べたように、多くのアプリケーション (ゲームや DeFi プロトコルなど) は高いスループットを必要とし、構成要件が高くない場合は、巻き上げる。これらのロールアップは分散型シーケンサー ネットワークを共有し、証明者ネットワークと検証者ネットワークも分散型になります。これは現在のサービス提供の前提であり、来月中に詳細をお知らせする予定です。したがって、既存の EIP-4844 や単一のロールアップ ソリューションではすべての問題を解決することはできず、重要なのは、さまざまなプロジェクトやアプリケーション シナリオにサービスを提供するために多数のロールアップに依存することであると考えています。
EIP-4844に関しては現在取り組んでいます。 EIP-4844 はデータコストの一部を確実に削減します。最近 Twitter で Polygon と zkSync のデータコストについて議論がありました。私たちと Polygon は現在、トランザクションの生データをオンチェーンで直接使用しています。 Optimism と Arbitrum はチェーンにアップロードされる前にある程度圧縮されますが、zkSync と StarkWare はよりスペースを節約する State Diff モードを使用します。同じアカウントでの高頻度の操作の場合、State Diff により多くのスペースが節約される可能性があります。誰かが State Diff を使用した後に zkSync のデータを分析したところ、実際にある程度のコストを節約できることがわかりました。ただし、EIP-4844 またはシャーディングの後でデータのコストがさらに削減された場合でも、チェーン トランザクションの元のデータを直接アップロードすることを好みます。これにより、他のユーザーがデータを確認した後、より迅速にトランザクションを実行し、より強力な保証を得ることができるからです。
データコストが低くなった後、いくつかの圧縮アルゴリズムを追加することで、State Diff と同様の効果が得られる可能性があると期待しています。ただし、現在はトランザクションの生データを使用することを好みます。 EIP-4844 が私たちに与える影響に関しては、2 つの部分に影響します。1 つは私たちのブリッジ (ブリッジ)、私たちは EIP-4844 に基づく新しいブリッジ設計の検討を開始しており、ある程度の影響はあるでしょう、そして新しい仕様が必要です書かれます。他の部分は回路 (Circuit) 内にあります。新しい形式では以前のデータに直接アクセスできず、小さなコミットメント (Commitment) のみにアクセスできるため、回路内でこのコミットメントのオープン性を証明する必要があります。回路には確かにオーバーヘッドがありますが、それは実行可能であると考えています。
Qi Zhou：
EIP-4844 を実装すると、データが別の曲線上にあり、ネイティブ データと同じ形式ではない可能性があるため、ドメインの問題が発生します。ずっと前に、Vitalik は同等性を証明するという概念を提案しましたが、ドメインが異なる場合には依然としていくつかの問題が存在することが後にわかりました。 Dankrad と Vitalik は、サーキットに献身的なオープン性を組み込む洗練された方法を提案しています。この変更は決定的であり、時間がかかると考えていますが、特に複雑で実現可能なものではありません。レイヤ 1 がこの変更を実装するタイミングを調整する必要があり、それに応じて調整します。それまでは、引き続き現行システムに注力していきます。
私たちは EIP-4844 について多くの調査を行いました。実際、EIP-4844 の目的は容量を拡張することではなく、バイナリ ラージ オブジェクト (blob) とそのデータ ハッシュを含む、将来のダンクシャーディングに必要な一連の概念を実現することです。データ ハッシュにはコントラクト内でアクセスでき、これらの概念は事前に実装されているため、Danksharding の実装時にコントラクトのアップグレードは必要ありません。 EIP-4844 は、現在のイーサリアム データ オンチェーン方式に比べて大幅な改善をもたらすものではありませんが、EIP-4844 がもたらす帯域幅は基本的に同程度であると予備的な推定を行っています。
ただし、Danksharding の仕様によれば、スループット レベルは約 20 倍高くなります。したがって、EIP-4844 で 100 TPS の速度を達成すると仮定すると、Danksharding を使用すると、理論的には 2000 TPS、あるいはそれ以上に達することができます。 Vitalik Buterin 氏や Danksharding チームを含むイーサリアム コミュニティは、EIP-4844 のアップグレードについて非常に懸念しています。なぜなら、一度アップグレードされれば、イーサリアムの次のメジャー アップグレードでは契約システム全体をアップグレードする必要がないからです。
当社のストレージ契約は EIP-4844 向けに直接設計されており、開発の実装とストレージの証明の点では実際にはより簡単になる可能性があります。 EIP-4844 が提供する Danksharding を使用すると、システムは実際に事前計算されており、私たちにとって非常に使いやすい保存方法です。
ZK や Optimism などのテクノロジーには、特にデータの受け渡し方法に関して課題が生じる可能性があります。 Ethereum には、BLOB データを CoreData に再送信できる、ランダム評価方法を含むいくつかのツールがすでにあります。これらのトランザクションが正しいことを証明するには、いくつかの課題が必要です。
EIP-4844 上のデータ BLOB に対するさまざまな操作を容易にするために、OpenZeppelin ライブラリと同様のいくつかの共通ライブラリを提供する予定です。これにより、監査とガス消費の点でセキュリティと効率の利点がもたらされます。
要約すると、EIP-4844 は革新的であり、イーサリアムのデータ層全体の運用に大きな可能性を秘めています。 EIP-4844 に興味がある方は、このテクノロジーの使用方法をよりよく理解するために、イーサリアム関連のコードとパラメーターの設計を学ぶことをお勧めします。
Zhixiong Pan：
トピック 4: モジュラーブロックチェーン
Jolestar:
最後のトピックは、モジュラー ブロックチェーンについてお話します。これはパブリック チェーン自体と密接に関係するホットなトピックであり、新しいトレンドと言えます。昨年初めから1年以上が経過しましたが、現時点での大きな見方としては、ブロックチェーンが徐々に階層化され、合意、実行、DA、決済などのさまざまなレベルが形成されるのではないかということです。このような背景から、レイヤー 2 プロトコルはより大きな課題と競争に直面するのか、業界全体の競争環境は大きく変化するのかどうか。
モジュラー ブロックチェーンはレイヤー 2 の考え方を進化させたものだと思います。レイヤ 2 では実行をレイヤ 1 からレイヤ 2 に移動しましたが、なぜ異なるモジュールを逆アセンブルして、異なるシステムに実行させることができないのでしょうか。従来の分散システムを例にすると、別の視点が導入されますが、従来の分散システムには Zookeeper と Raft と呼ばれるコンセンサス層があり、このコンセンサス層はブロックチェーンのレイヤー 1 に相当します。ただし、ブロックチェーンのレイヤー 1 は従来のコンセンサスレイヤーとは異なり、ブロックチェーンのレイヤー 1 でプログラムを実行できます。そこで現在、Zookeeper でプログラムを実行していますが、グローバル コンセンサスの実行効率が遅すぎることがわかり、拡張するには Zookeeper を削除する必要があります。
もう 1 つの観点は、アプリケーションの観点からです。アプリケーションを構築するときは、Zookeeper や MySQL など、アプリケーション機能を完成させるためにさまざまなシステム コンポーネントを選択します。実際、私たちはアプリケーションを構築しているのですが、MySQL が Zookeeper を拡張しているわけではありません。このモジュール式ブロックチェーンのアイデアは、新しい視点、つまり、既存のレイヤー 1 リソースとストレージおよび実行機能を組み合わせて基本的な DApp を構築する方法を導入することができます。
Dorothy Liu:
この新しい視点は、既存のパブリック チェーンや制作システムのコンポーネントと矛盾しません。私たちは、開発者はまず、決定性と検証可能性を確保するために、アプリケーションを構築するために適切な言語を選択する必要があると考えています。拡張性を高めるために Move 言語を選択しました。開発者はこの言語を使用してアプリケーションを構築し、分散化を実現する方法を検討します。最初は完全に分散化できないかもしれませんが、分散化する能力が必要です。たとえば、トランザクションを公開して、誰でも検証できるようにすることができます。まだ一元化されていますが、少なくとも検証可能です。その後、約束として、セキュリティを確保するためにプロトコルをプラグインできます。この段階的な完了メカニズムにより、集中型アプリケーションに新しい開発パスが提供されます。
私は Jolestar の見解に非常に同意しており、昨年以来、業界がファット プロトコルとシン アプリケーションからファット アプリケーションとシン プロトコルへと進化していることに気づきました。現在、焦点は分散型ユートピアと技術進歩の追求から実用的な応用シナリオに移っています。ゲームやソーシャルネットワーキングなどの新しいアプリケーションがますます登場するにつれ、イーサリアムの拡張や特定の技術的方向性の進歩だけではなく、ブロックチェーンアプリケーションが何を達成できるかに誰もがより注目するようになりました。イーサリアムは重要な L1 ですが、さまざまな L1 の出現により、マルチチェーン時代のトレードオフは誰もが喜んで受け入れます。
ロールアップ指向の企業またはチームとして、私たちはイーサリアム コミュニティにサービスを提供するだけではありません。私たちは、さまざまな用途のニーズを満たすために、分解して組み合わせたレゴ テクノロジー ソリューションを構築したいと考えています。一部のアプリケーションではより大きなブロック制限が必要になる場合があり、一部のゲーム会社では Solana VM と互換性のある L2 が必要な場合があり、誰かが Celestia に DA を搭載するか、EigenLayer と互換性を持たせたい場合もあります。私たちは、組み合わせ可能なソリューションを提供し、ニーズに応じてさまざまなアプリケーション向けにソリューションをカスタマイズしたいと考えています。 L1 をイーサリアム、BNB チェーン、さらには Solana、または独自のビーコン層に配置することができます。セキュリティの観点から、証明をイーサリアム上に置くことは非常に重要ですが、トランザクション本体（トランザクションオントロジー）は必ずしもイーサリアム上に置く必要はありません。イーサリアムの取引主体から離れることでコストが大幅に削減されます。
Qi Zhou:
このファットアプリケーションの時代において、私たちは最適化の方向性だけではなく、アプリケーションごとに最適な拡張ソリューションをいかに提供するかに重点を置いています。 zkEVM と OP の間の議論については、両方の側をサポートできます。私たちは zkEVM の証明者コストに焦点を当てています。たとえば、Scroll は証明者を実行するために月に 10,000 ドルを費やす必要があるかもしれませんが、これはゲーム メーカーにとっては高すぎる可能性があります。より安価な証明者ソリューションが必要であるため、コンピュータを使用した証明者ソリューションを提供し、さまざまなニーズに応じてさまざまな技術ソリューションを提供できます。これが私たちの解決策です。
歴史的な観点から見ると、私はモジュール化が向かう方向に同意します。これには、ネットワークおよびコンピュータ アーキテクチャの OSI 層が含まれます。イーサリアムまたはブロックチェーンを世界のコンピューターとして考えると、その役割をより適切に果たすために既存のコンピューターシステムから学ぶことができます。各コンポーネントには莫大な市場価値があるため、たとえばイーサリアムのレイヤー 1 は、基本的なコンピューティング能力と限られたストレージ容量を備えた初期の CPU と比較できます。一方、DA は記憶に似ています。
メモリと CPU の間でデータを転送するには、データのハッシュとプリコンパイルが必要です。 Coredata はレジスタに似ており、GPU などの高性能コンピューティング デバイスなどのモジュラー プラグインも必要です。ブロックチェーンネットワークでは、DAとゼロ知識証明によって計算データの通信が実現されます。さらに、メモリからハードディスクにデータをコピーするには大量のストレージが必要です。最後に、現在使用している MetaMask や Web3 プロトコルと同様の、マウス、キーボード、モニターなどのデバイスも必要です。
成熟したコンピュータ システムと描画経験から教訓を得て、私たちは将来のコンピュータ世界システムを想像することができます。もちろん、ハードディスクを他のレイヤー 1 デバイスなどの他のコンピューターに接続することもできます。ただし、レイヤー 1 に優れた DA レイヤーとメモリがない場合、データの送信とストレージの速度と帯域幅が大幅に制限されます。
Ye Zhang：
コンピューターは、非常に重要な部品である CPU とメモリがなければ起動できません。これらの基本コンポーネントを適切に配置すると、GPU、ディスプレイ、ハードドライブなどのデバイスを組み合わせることができます。 EthStorage および Web3 プロトコルを開発するとき、私たちは複数のチェーンをサポートし、他のネットワークにアクセスするためのモジュラー アプローチを採用しました。これらのネットワークは、基本的な実行層と DA 層を備えている限り、他の層 1 または層 2 であってもかまいません。レイヤ 2 にアクセスすると、EthStorage は実際にはある程度レイヤ 3 になります。これは、将来の世界のコンピューターまたはブロックチェーンの全体的なアーキテクチャに関する私たちのビジョンです。
モジュラーブロックチェーンは現在、実行とデータの分離という非常に重要な物語だと思います。しかし、少なくとも私たちにとっては、現時点でもイーサリアムが最も重要なデータレイヤーであると考えています。ロールアップの定義については、様々なロールアップが登場しているため、様々な解釈があります。現在、ほとんどのコミュニティで受け入れられている定義は、イーサリアムのセキュリティを継承するために、少なくともレイヤー 1 にデータを公開する必要があり、プルーフを公開しない場合でも、イーサリアムにデータを公開する必要があるということです。なぜなら、ほとんどの人は、データがチェーンにアップロードされている限り、他のノード、フルノード、ライトノードのいずれを介しても、少なくとも 1 つの決定的な結果が得られ、それを最終化する必要があると考えているからです。
さまざまなロールアップに関して、彼らの主な考え方は、結果を信じるかどうかはあなた自身の選択、つまりフル ノードかライト ノードの選択によって決まるということです。たとえば、Optimistic Rollup は「私はあなたに挑戦します」と言い、zkRollup は「私は常にあなたの正しさを証明してきました」と言います。実際、これらのロールアップはすべて、ポイントを確立し、私があなたのデータを信頼するかどうか、そして私があなたの資金があなたから橋渡しされることを信頼するかどうかを判断するためのものです。
したがって、少なくとも私たちにとっては、私たちのプラットフォームが常にイーサリアムのデータ層を信頼し、ロールアップを行うことを主張することを望んでいます。また、データシャーディングのプロセスを進めるためにも熱心に取り組んでいきます。注目すべき唯一のことは、それがいつ起こるか、そしてどれくらいの時間がかかるかというタイミングだと思います。それまでは経過措置を取る必要があるのでしょうか？これは主に、データ シャーディングのタイムラインの推定に依存します。達成までに 5 年かかると見積もった場合、いくつかの中間段階が存在する可能性があります。しかし、それが妥当な時間枠内で実現すると考えるのであれば、私たちは依然としてこの方向に固執するでしょう。
過度のモジュール化は良いことではないかもしれません。以前にレイヤー 2 の状況を観察したとき、レイヤー 2 は 9 つしかなく、それぞれが独自のセキュリティ属性 (コントラクトをアップグレードできるかどうか、シーケンサーが分散型であるかどうか、オープンソースであるかどうかなど) を持っていました。監査済みです。レイヤ 2 の場合、これらのセキュリティ プロパティは注意が必要です。たとえば、契約をアップグレードできる場合、準拠していないロールアップが何か悪いことをした場合、即座に発見される可能性があります。一般の人々がさまざまなロールアップの特性とそれらの間のトレードオフを理解しておらず、すでに 100 個のロールアップから選択できる場合、セキュリティ上の問題が発生する可能性があります。したがって、最終的には、絶対的なセキュリティを提供し、誰もが自分のプロパティに対して一定の保証を持ち、同時に優れた構成可能性を備えた主要なロールアップがまだいくつか存在する可能性があると思います。これに基づいて、一部のアプリケーション層のレイヤー 2 を並行して開発するか、その上にレイヤー 3 を展開するかにかかわらず、レイヤー 2 への負担を軽減することができます。
このとき、他のデータ レイヤーや他の方法を使用することも選択でき、コミュニティが合意に達する限り、独自のアイデアに従って革新することができます。
