Eclipse Mainnet: 他社の強みを活用した、イーサリアムのセキュリティと Solana の速度を備えたモジュール式レイヤー 2

作者: エクリプス

編集者: Deep Wave TechFlow

Eclipse Mainnet: 他社の強みを活用する Ethereum セキュリティと Solana 速度を備えたモジュラー Layer2

Eclipse Mainnet は、モジュラー アーキテクチャの最良の部分を組み合わせたユニバーサル レイヤ 2 です。

  • 決済層: イーサリアム - Eclipse はイーサリアムで決済し (つまり、検証ブリッジはイーサリアム上にあります)、ETH をガス トークンとして使用します。
  • 実行層: Solana 仮想マシン (SVM) - Eclipse は、実行環境として高性能 SVM を実行します。
  • データの可用性: Celestia - Eclipse は、スケーラブルなデータ可用性 (DA) のためにデータを Celestia に公開します。
  • 証明: RISC Zero - Eclipse は、不正行為のゼロ知識証明に RISC Zero を使用します (中間状態のシリアル化は必要ありません!)。

Eclipse Mainnet: 他社の強みを活用する Ethereum セキュリティと Solana 速度を備えたモジュラー Layer2

Eclipse のハイライトのほとんどは、さまざまなプロジェクトにアプリケーション固有のロールアップをデプロイすることにありましたが、イーサリアムには真のスケールを実現できるユニバーサルなレイヤー 2 が必要であることがこれまで以上に明らかになりました。ほとんどのアプリは、アプリ固有のチェーンをカスタマイズしてもメリットがありません。その結果、分離と複雑さが実際にユーザーと開発者のエクスペリエンスを悪化させる可能性があります。

モジュラー ロールアップのビジョンと、大規模なスケーリング、並列実行、共有状態を備えた単一チェーンの機能との間には、誤った二分法が存在することがよくあります。 「モジュラー」は「アプリケーション固有」と混同されることが多く、そのため、ロールアップは多くの断片化された低スループットのチェーンの世界を意味すると考えられます。

実行層: Solana の速度とスケール

Eclipse Mainnet は、Solana のようなクラス最高の実行環境を使用します。これにより、次のような大きな利点がもたらされます。

最適化された並列実行

SVM とその Sealevel ランタイムは、並列トランザクション実行のサポートで有名です。重複する状態に影響を与えないトランザクションは、逐次ではなく並列で実行できます。

これにより、プロセッサが低コストでコアを追加し続けるため、SVM はハードウェアに合わせて直接拡張できます。シングルスレッド ランタイム (今日の EVM など) は本質的に、コアあたりのコストの削減による恩恵を受けません。過去 10 年ほどにわたって、シングルスレッドのパフォーマンス向上は着実に減少しています。ほとんどすべての改善は依然としてコア数の増加によってもたらされるため、ワークロードの並列化ではこの傾向を活用することが重要です。

Eclipse Mainnet: 他社の強みを活用した Ethereum セキュリティと Solana 速度を備えたモジュラー Layer2

EVM を並列化する試みは非常に初期からいくつかありましたが、互換性を維持しながら EVM を追加すると、他のボトルネック (状態の増加など) に対処しないと最適ではないパフォーマンスが得られるなど、基本的なトレードオフが伴います。 (SVM のように) 状態の依存関係を事前に宣言するコントラクトは、最適な並列化を実現します。

ネイティブ料金市場

現在のほとんどの料金市場はグローバルであるため、1 つの人気のあるアプリがすべてのチェーン ユーザーの料金を引き上げることになります。 1 回の NFT ミントによって、チェーン全体が他のすべてに役に立たなくなることがあってはなりません。ネイティブ料金マーケットプレイスに関する Solana の素晴らしい取り組みにより、このアプリケーション間の状態競合の問題が解決されました。現在の実装では、スケジューラは競合のないトランザクションを優先し、競合のないトランザクションをより低い料金で続行できるようにします。長期的には、ネイティブ料金市場がプロトコル レベルで実装されるでしょう。これにより、単一のアプリケーションの料金の高騰がチェーンの他の部分に影響を与えなくなります。

Eclipse Mainnet: 他の強みを活用する Ethereum セキュリティと Solana 速度を備えたモジュラー Layer2

ネイティブ料金マーケットプレイスは、Solana 独自の並列化ランタイムの恩恵を受けています。ヒューリスティックを使用して EVM の州ホットスポットのネイティブ料金市場を実装しようとすると (つまり、事前に州アクセスを宣言しないと)、非効率が生じ、攻撃ベクトルが発生する可能性があります。

また、アプリがアプリ自体に固有の価値を簡単に取り込めるようにするための初期の研究も進行中ですが、今日ではアプリレベルの設計により多くの創造性が必要になることがよくあります。

州の成長管理

EVM がボトルネックとして順次実行に到達する前に、状態の増大がより差し迫ったボトルネックとなります。

状態にはマークル ツリーがないため、Solana では状態の更新ごとにマークル ツリーを更新するオーバーヘッドが発生しません。代わりに、各エポック (2.5 日) ごとに、状態全体がアーカイブされます。これは、ライブ アーカイブ (EVM など) よりも安価です。

さらに重要なのは、EVM には動的なアカウント アクセスがあります (つまり、トランザクションはオンデマンドであらゆる状態にアクセスできます)。この動的な状態ルックアップは、実行前に状態をメモリにロードできないことを意味します。 SVM では、各トランザクションは実行に必要なすべての状態を指定します。

したがって、状態のサイズは SVM の実行に影響しません。バリデーターがストレージ ディスクを 2 年ごとにアップグレードすると仮定すると、ネットワークは大きな問題が発生することなく、2 年ごとにスナップショットのサイズを安全に 2 倍にすることができます。

さらに、Helius のようなチームは、履歴データのアクセシビリティを積極的に改善し、圧縮を通じて状態サイズを削減しています。

EVM の互換性

Neon EVM は、任意の SVM チェーンにデプロイできる Ethereum 仮想マシン スマート コントラクトです。これにより、Eclipse Mainnet に完全な EVM 互換性 (EVM バイトコード サポートおよび Ethereum JSON-RPC を含む) がもたらされ、シングルスレッド EVM よりも優れたスループットが得られます。各 Neon EVM インスタンスには独自のネイティブ料金市場があるため、アプリケーションは独自のコントラクトを展開するだけで、UX、セキュリティ、流動性を損なうことなくアプリケーション チェーンのメリットを享受できます。

さらに、Solang コンパイラーは、Solidity スマート コントラクト コードを SVM バイトコードにコンパイルできます。

MetaMask スナップ

EVM ユーザーに非 EVM チェーンの使用を誘導することはこれまで大きな障壁でしたが、最近発表された MetaMask Snap はこの障壁を打ち破ります。 EVMユーザーはウォレットを切り替えることなくMetaMaskを使い続けることができます。優れた MetaMask Snaps 実装の構築に対する Drift のオープン ソースへの貢献のおかげで、エクスペリエンスは他の EVM チェーンとの対話に似ています。 Eclipse Mainnet ユーザーは、MetaMask でネイティブにアプリケーションと対話したり、Salmon などの Solana ネイティブ ウォレットを使用したりできるようになります。

ファイアダンサー

Firedancer は、Jump によって開発されている非常に期待されている Solana クライアントであり、ネットワークのスループット、回復力、効率を大幅に向上させるように設計されています。立ち上げ時には、コアの Solana クライアントに可能な限り近づける予定ですが、コードが稼働して安定したら Firedancer を採用する予定です。

#### 安全性

Solana は攻撃対象領域を大幅に減らして実行し、これまで何度も見てきた再入攻撃を防ぎます。具体的には、Solana ランタイムではプログラムの自己再帰のみが許可され、任意の再入可能なプログラム間呼び出しは許可されません。さらに、状態とコードが分離されるとステートレス コードが生成され、一般に効果的なテストが容易になります。

より簡単な証明

SVM はレジスタベースであり、命令セットは EVM よりもはるかに小さいため、ZK での SVM の実行の証明が容易になります。楽観的なロールアップの場合、レジスタベースの設計により、より単純なチェックポイント設定が可能になります。

決済層: イーサリアムのセキュリティと流動性

今日のメジャーロールアップと同様に、Eclipseメインネットはイーサリアムで解決されます。具体的には、これはイーサリアム上の検証ブリッジが Eclipse に直接統合されることを意味します。 Eclipse ノードはこのブリッジを調べて「正規チェーン」を決定します。このブリッジは、Eclipse に対して正しい順序付けを強制します。

これにより、ユーザーはイーサリアムから特定のセキュリティ プロパティを取得できるようになります。ブリッジはすべての Eclipse トランザクションを検証し、無効な状態がコミットされるのを防ぎます。さらに、特定の失敗の場合には、最終的な有効性と検閲への耐性が強制されます。 L2 の注文者が実行を停止したり、検閲を開始したりしても、ユーザーはブリッジを通じてトランザクションを強制的に含めることができます。

これらのセキュリティ特性により、有効かつ最適なライブラリは「イーサリアム L2」と呼ばれることがよくあります。 L2BEAT は、L2 を「イーサリアム レイヤー 1 からセキュリティを完全または部分的に取得するチェーンであり、ユーザーが資金を安全に保つために L2 バリデーターの誠実さに依存する必要がないようにします。」と定義しています。

イーサリアムの決済は、Eclipse MainnetのDeFiおよびNFT経済におけるイーサリアムのネイティブ資産の重要性を反映しています。 ETH は、ほとんどのユーザーにとって明らかに優先される最適な分散通貨であるため、ガス トークンとしても ETH を使用します。長期的には、手数料の抽象化により、ユーザーは任意のトークン (USDC など) で支払うことができるようになります。現在、Eclipse Mainnet には独自のトークンを発行する予定はありません。

データの可用性: Celestia の帯域幅と検証可能性

Eclipse Mainnet は、データの可用性 (データ公開またはデータ公開とも呼ばれます) に Celestia を使用します。 Celestia は、Eclipse の長期にわたるエコシステム パートナーです。

Eclipse Mainnet の目標スループットと料金は、残念ながら Ethereum の現在の帯域幅制限ではサポートされていません。これは、EIP-4844 (別名「Proto-danksharding」) 以降にも当てはまり、ブロックごとに ~0.375 MB の BLOB 領域が提供されます (ブロックごとの制限は ~0.75 MB)。

  • 基本圧縮 (トランザクションあたり最大 154 バイト) を使用した ERC-20 転送の場合、これはすべてのロールアップで最大 213 TPS に相当します。
  • 圧縮された交換 (トランザクションあたり最大 400 バイト) の場合、これはすべて合計すると最大 82 TPS に相当します。

これに対し、Celestia は今年末までに 2 MB ブロックを開始する予定です。十分なデータ可用性サンプリング (DAS) ライト ノードがオンラインになり、ネットワークが安定していることが証明されると、起動直後に BLOB 領域が 8 MB に増加すると予想されます。 DAS ライト ノードは 2 つの重要な機能を果たします。

  • Eclipse ブロック データが利用可能かどうかをユーザーが自分で確認できるようにします。
  • より多くの DAS ライト ノードがオンラインになると、DA 層が安全にスループットを向上させることができるため、ネットワーク全体を安全に拡張するのに役立ちます。

Celestia は、実稼働環境で DAS を有効にする最初の DA レイヤーになることが期待されています。これは、(既存のモノリシックブロックチェーンと同様に)ユーザー検証なしで委員会の誠実さの前提を再導入する従来のデータ可用性委員会(DAC)とは対照的です。

オフチェーン DA を使用してイーサリアムメインネットから任意のチェーンに資金をブリッジするユーザーには、固有のセキュリティの前提条件があります。特に、Celestia バリデーターは技術的にはトランザクション データを拒否できますが、データはイーサリアム ブリッジで利用可能であると主張できます。実際、Celestia のプルーフ・オブ・ステークのコンセンサスは、Celestia 自体によるデータの保留が罰せられることを意味しており、このリスクは非現実的であると考えています。

全体として、Celestia の DAS ライト ノード サポート、暗号経済的セキュリティ特性、および初日からの拡張性の高い DA スループットにより、今日の Eclipse メインネットにとって Celestia は明確な選択肢となっています。

また、EIP-4844以降のイーサリアムのDAスケーリングの進捗状況を監視する予定です。これまで考えられていたよりも早く高スループットの DA を提供する可能性のある新しい研究が発表されています (後者はより高度な分散ハッシュ テーブルを使用します)。イーサリアムがユーザーにより大きなスケールを提供する場合、イーサリアム DA への移行の可能性を評価します。

証明: RISC Zero ZK 不正証明 (中間状態のシリアル化は必要ありません!)

私たちの証明は、Anatoly の SVM 不正証明 SIMD に似ています。これ自体は、状態のシリアル化は高価であり、回避できるという John Adler の洞察に似ています。

具体的には、SVM にマークル ツリーを再導入することは避けたいと考えています。 SVM で各トランザクションの後にスパース マークル ツリーを挿入しようとしましたが、マークル ツリーを更新すると大幅なパフォーマンスの低下が発生しました。マークル ツリーを使用しないと、SVM ロールアップの基礎として既存の汎用ロールアップ フレームワーク (OP スタックなど) が除外され、より創造的な障害防止アーキテクチャも必要になります。

つまり、障害防止には次のことが必要です。

*トランザクション入力へのコミットメント、

  • トランザクション自体、および
  • トランザクションを再実行すると、チェーン上で指定された出力とは異なる出力が得られることを証明します。

入力コミットメントは通常、ロールアップ状態ツリーのマークル ルートを提供することによって実現されます。私たちのエグゼキューターは、各トランザクションの入力と出力 (アカウント ハッシュと関連するグローバル状態を含む) のリストと、各入力を生成したトランザクションのインデックスを公開します。トランザクションは Celestia で公開されるため、完全なノードはアカウントを独自の状態で自己抽出し、出力アカウントを計算し、イーサリアムでのコミットメントが正しいことを確認できます。

考えられる障害には主に 2 つのタイプがあります。

  • エラー出力 - この場合、ベリファイアは、SVM 実行の正しい出力のオンチェーン ゼロ知識証明を提供します。 RISC Zero を使用して SVM 実行のゼロ知識証明を作成します。これは、以前の BPF バイトコード実行の証明の続きです。これにより、これらのトランザクションをオンチェーン自体で実行することなく、決済契約の正確性を保証することができます。
  • 不正な入力 - この場合、バリデーターはオンチェーンの履歴データへの参照を公開し、入力状態が要求されたものと一致しないことを示します。 Celestia の Quantum Gravity Bridge を使用することで、当社の和解契約により、この履歴データが実際に詐欺であることが証明されます。

私たちは巨人の肩の上に立っています。今日のロールアップは業界全体の研究状況を前進させ、イーサリアムユーザーに L1 よりも低い料金を提供します。

しかし、大規模なスケールを必要とする最新テクノロジーを十分に活用できていません。最近の驚くべき進歩により、以前のロールアップでは必要であった次のようなトレードオフを行う必要がなくなり、事実上不利な立場に置かれました。

  • 高性能並列 VM (SVM など);
  • DAS ライトノードサポート (Celestia など) を備えた DA 拡張機能。
  • 証明インフラストラクチャの進歩により、どこでも実用的になります (RISC Zero など)。
  • コードのエコシステム (Neon や Solang など) とユーザー (MetaMask Snap など) 間の移植性の向上

私たちは他のチェーンが直面している制限から学び、長期的な拡張に最適な部分を選択できます。

将来的には 100 万個のアプリケーション固有のロールアップが作成されるという話もよく聞きます。

コンセンサスレベルのカスタマイズは、特定のアプリケーション (dYdX v4 など) にとって非常に価値があるため、チームがアプリケーション固有のロールアップを立ち上げるのを喜んで支援します。

ただし、このような状況はまれです。これが、ほとんどの新しいロールアップがまだ単純な EVM フォークである理由です。開発者の問題は、より多くのチェーンにわたって UX を断片化しても解決されません。今日の何百万ものチェーンで見られる主な使用例は、単により多くのコインを発行することであることが多いようです。現在、ほとんどのユースケースでは、テクノロジー スタックを完全にカスタマイズする必要はありません。

たとえ実際の需要が存在するとしても、多くのアプリケーション チェーンを競争力のある UX でサポートするために必要なインフラストラクチャは、(たとえ存在したとしても)何年もの間は整備されないでしょう。 Optimism のスーパーチェーン (OP スタック)、zkSync のハイパーチェーン (ZK スタック)、Arbitrum の Orbit チェーンなどはすべて、共有インフラストラクチャを備えた多くのチェーンのビジョンを持っています。これは、完全に分離されたチェーン (例: イーサリアムと Solana の間) ではなく、同じエコシステム内 (例: スーパーチェーン内の 2 つのチェーン間) のチェーン間操作に対して、よりスムーズな UX を提供することを目的としています。

しかし、現在の計画(存在するとしても)は、単一の共有国家と競合できるとは程遠い。さらに、エコシステム間の相互運用性の問題 (例: スーパーチェーンからハイパーチェーン) には対処していません。モジュール性を構築するということは、サイロを構築することを意味するべきではありません。

ユーザーが多くのチェーンでアカウントを維持するのはさらに複雑です。常にチェーンを横断したり、必要なガス トークンについて心配したりするのは、ユーザー エクスペリエンスを悪化させます。非常に多くのチェーンの運用と維持をインフラストラクチャプロバイダーに依存することは、より複雑で費用もかかります。

私たちはソラナのビジョンのシンプルさを常に賞賛してきました。最も価値のあるユースケースをサポートするスケールを備えた、高度に最適化された共有ステート マシン。これはロールアップ中心のロードマップと互換性がないと思われがちですが、実際はそうではありません。私たちは両方の長所を組み合わせたいと考えました。

この誤解は、今日のロールアップの大部分が元のシングルスレッド EVM を実行しており、初期のネットワーク効果を利用するためにほとんど変更されていないという事実によるものです。したがって、アプリケーション固有のロールアップを展開する理由として「プライベート ブロック スペース」が挙げられることがよくあります。チェーン上の他のアプリケーションは、いくつかのクレイジーなNFT鋳造のために価格が上昇するべきではありませんが、答えは独自のチェーンを構築することではありません。苦痛を伴う不必要なトレードオフ (複雑さ、コスト、ユーザー エクスペリエンスの悪化、流動性の断片化など) を余儀なくされます。最良の解決策は明らかです。州のホットスポットに対してネイティブの料金市場を持つ並列 VM を使用するだけです。これはまさに SVM がもたらすものです。

イーサリアムは暗号通貨の知的、社会、経済の中心地です。そのアキレス腱は常に拡大でした。データの可用性の拡大はまだ進行中であり、既存の L2 実行環境は SVM などの新しいイノベーションと競合できません。私たちは、現在の状況がこのまま続くと、活動が劇的に増加した場合にイーサリアムエコシステムが不意を突かれるのではないかと懸念しています。シングルスレッドの EVM とデータの可用性の制約により、すぐに高コストが再発する可能性がありますが、今回はロールアップの場合のみです。

私たちは、Eclipse Mainnet が、Solana のパフォーマンスとロールアップ中心のロードマップのセキュリティ、検証可能性、およびネットワーク効果を組み合わせた明白なソリューションであると信じています。

### 結論

イーサリアムの美しさは、常に革新していることです。ロールアップ中心のロードマップはこれを例示しており、実行とイノベーションを自由市場に委任しています。 L2 には、最高の新しい実行環境を実験しながら、イーサリアムのネットワーク効果と決済保証を活用する驚異的な能力があります。 Eclipse Mainnet は、このビジョンを自然に実装したものです。

いつかよりパフォーマンスの高い実行レイヤーが出現した場合、それが競争力のあるイーサリアム L2 として展開されるのを見て非常に興奮するでしょう。それまでは、SVM が標準のままです。

原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • 共有
コメント
0/400
コメントなし
いつでもどこでも暗号資産取引
qrCode
スキャンしてGateアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)