EIP-7987からL1 zkEVMまで:イーサリアムL1の拡張進化の道

イーサリアム未来五年最重要なことは何ですか?

L1のスケーラビリティ。

今月より、ヴィタリック・ブテリンとイーサリアム財団は、複数の主要なテーマについて重い発言を続けています:EIP-7987提案(この提案は以前コミュニティによってEIP-7983と呼ばれ、正式番号はEIP-7987)は単一の取引に上限を設定しようとし、L1 zkEVMは正式に実験段階に入ったこと、さらにはブロックのガス上限の引き上げに至るまで、イーサリアムのL1拡張が加速し、実現のスピードが上がっていることを示しています。

言い換えれば、L2エコシステムが段階的な成果を上げた後、イーサリアムはL1の拡張パスに再び焦点を当てる時期に来ています——ロールアップはすでに十分速いですが、L1はさらに軽く、強く、統一されることができます。

この記事では、この一連のアップデートの背後にある技術的な流れを整理し、イーサリアム L1 プランが次の大規模な拡張をどのように実現するかを簡単に話します。

01 ###、分割してマージし、L2からL1に再度開始します

2020年にVitalik Buterinが「Rollupを中心にしたロードマップ」を発表して以来、Rollupはイーサリアムのスケーラビリティの核心戦略となり、ArbitrumやOptimismなど一連のL2プロジェクトを生み出し、「イーサリアムの新大陸」となりました。

しかし、Rollup の問題はここにあります。『ERC-7786を理解する:イーサリアムエコシステムが「統一」時代に大きな一歩を踏み出すのか?』という記事が述べているように、現在広義の意味での L2 は数百にも上ります。これにより、大量の取引と価値が L2 上でますます断片化され、同時に L1 のデータ可用性と最終決済層としての役割もますます重要になっています。

これにより、L1 はますます重い運用負荷を受けることが避けられなくなります。例えば、高 Gas 取引(blob 提交や zkProof 検証など)は、L1 ノードの計算と検証の負担を大幅に増加させ、状態空間の膨張はノードの同期効率やチェーン上のストレージコストにも影響を与えます。また、イーサリアムのブロックパッキング時間の変動が激化し、安全性や検閲抵抗のリスクも潜んでいます。

! EIP-7987からL1 zkEVMへ:イーサリアムL1スケーリングへの道

ソース: L2Beat

結局、過去数年のL2の発展の軌跡は、「壁を作る歴史」の一部でもある——各社のRollupが流動性の防壁を自ら築き、ユーザーと資産を自社のエコシステムにロックインしようと努力している。これらの高い壁は局所的な効率を生み出したが、エーテル全体としての流動性と統一性を弱体化させている。

正に「合久必分、分久必合」と言われるように、イーサリアムはL2からL1への再構築という大きな周期の転換点にあります。ある意味では、これは「L2を中心に」という段階的な修正でもあります。

ネット全体の使用体験を、数十の断片的なチェーンの盛り合わせではなく、統一されたエコシステムのようにすることを意味します。これは、将来的にはL1/L2間の資産移転、状態共有、およびアプリケーション切り替えが、単一のチェーン上でのようにスムーズで感知できないものであるべきです。

そのため、Based RollupからePBS、そしてL1 zkEVMに至るまで、イーサリアム財団のプロトコル研究チームと開発者コミュニティは、セキュリティと分散化を犠牲にすることなく、メインネットがより強力な実行能力、可用性、外部攻撃に対する耐性を持つように、L1レベルの構造的最適化を体系的に推進しています。

02、EIP-7987&zkEVM:メインネットにスケーラビリティの遺伝子を注入

現在、市場で最も注目されている二つのコアスケーリング改革案は、それぞれ EIP-7987 提案と L1 zkEVM であり、リソーススケジューリングの最適化から実行層の再構築に至る二つの重要な次元を代表しています。

1.EIP-7987:単一取引のガス上限を制限し、ブロックリソースの混雑を緩和する

まず、イーサリアムの単一取引のガス上限を1677万に設定するEIP-7987提案を推奨します。これは今月初めにヴィタリック・ブテリンとトニ・ヴァールシュテッターによって共同で提案されました。核心的な考え方は、単一取引に1677万の最大ガス上限を設定することです(注意:この上限は各ブロックの総ガスリミットとは直接的な関係がありません)。

誰もが知っているように、イーサリアムネットワークでは、すべての取引(送金や契約の相互作用を問わず)に一定量のGasを消費する必要があります。また、各イーサリアムブロックのGasリミット容量は固定されており、つまりスロット数が限られているということです。これは、単一の取引のGas消費が過剰になると、ブロックの取引リソースを占有しやすくなることを意味します。

! EIP-7987からL1 zkEVMへ:イーサリアムL1スケーリングへの道

ソース: Github

例えば、ある高負荷の取引(例えば、zkProof検証や大規模なコントラクトの展開など)は、一つの取引でブロックスペースの大部分を消費することが多いため、この提案の目的は、単一の高ガス操作(例えば、zkProof検証や大規模なコントラクトの展開)が全体のブロックリソースを圧迫し、ノードの検証の混雑を引き起こすことをできるだけ避けることです。特に、並行実行環境やライトノードの同期に影響を与えます:

上限を設定することで、一部の超大型取引を分割させ、単一の取引が過剰なリソースを占有するのを避けることができる。また、取引の実行中に制限条件を導入し、取引がブロックに入る前にその上限を超えた場合は、検証段階で拒否される。

そのほか、単一取引のGas上限だけでなく、イーサリアムブロックの上限調整も進行中です。7月21日、ヴィタリック・ブテリンはツイートで「ほぼ50%のステーキング者がL1のGas上限を4500万に引き上げることを支持している」と述べ、現在Gas上限は3730万に引き上げられ始めています。

理論的には、ブロックのガス上限の拡大は、確かにイーサリアムのメインネットのパフォーマンスを大幅に向上させるが、過去にはイーサリアムがL2などのルートで大きな発展を遂げる中で、これに対してずっと慎重であった——イーサリアムのガスリミットの拡大を振り返ると、2019年9月にイーサリアムネットワークのガスリミットが800万から1000万に増加した後、今年までの6年間でガスリミットが800万から3600万にしか増加していないことがわかる。

そして今年に入ってから、イーサリアムエコシステムはGas Limitに対する公開議論の態度が明らかに「攻撃的」になっており、EIP-9698提案では「2年ごとに10倍に引き上げる」ことを提案しており、2029年にはGas Limitを36億に引き上げ、現在の100倍になる。

! EIP-7987からL1 zkEVMへ:イーサリアムL1スケーリングへの道

ソース: Etherscan

この一連の調整は、イーサリアムがメインネットの拡張に対する現実的な考慮を反映しているだけでなく、間もなく到来するzkEVM実行レイヤーのアップグレードに向けて計算リソースの基盤を築いています。

2.L1 zkEVM:ゼロ知識証明を用いたメインネット再構築実行アーキテクチャ

zkEVM は常にイーサリアムを拡張する「終局」の一つと見なされており、その核心的な設計思想は、イーサリアムのメインネットが ZK 回路の検証をサポートできるようにすることです。これにより、各ブロックの実行は検証可能な零知識証明を生成し、他のノードによって迅速に確認されることができます。

具体的な利点には、ノードが各取引を再実行する必要がなく、zkProofを検証するだけでブロックの有効性を確認できることが含まれます。これにより、全ノードの負担が軽減され、ライトノードやクロスチェーン検証者に対する親和性が向上し、セキュリティの境界や改ざん耐性も強化されます。

現在、L1 zkEVM の構想も加速して実現されており、今月 10 日にイーサリアム財団が L1 zkEVM リアルタイム証明標準を発表しました。これは、ゼロ知識証明技術のルートを全面的に採用するための第一歩として、イーサリアムメインネットが徐々に zkEVM 検証メカニズムをサポートする実行環境に移行することを意味します。

公開されたロードマップに基づいて、イーサリアム L1 zkEVM は1年以内にローンチされ、zk-proof の簡潔さを利用してイーサリアムを安全に拡張し、徐々に ZK 証明メカニズムをイーサリアムプロトコルの各層に統合します。これは、イーサリアムにとって、長年の関連技術の蓄積と実装の集中した実践検証でもあります。

これは、イーサリアムのメインネットが単なる決済層ではなく、自己検証能力を持つ実行プラットフォーム、いわゆる「検証可能な世界コンピュータ」となることを意味します。

! EIP-7987からL1 zkEVMへ:イーサリアムL1スケーリングへの道

総じて言えば、EIP-7987がミクロなスケジューリングで実行効率を向上させる一方で、L1 zkEVMはマクロなアーキテクチャで質的変化を実現します。これにより、10倍から100倍の実行性能の向上が期待され、イーサリアムのメインネットの「価値捕獲能力」を再構築することが可能です。

決済レイヤーとしてのみ存在していたL1は、検証可能な実行エンジンへと進化し、ユーザー、資産、流動性の接続入口をより多く担うことになる。また、SolanaやMonadなどの高性能新しいブロックチェーンとの競争に対しても、より対処できる能力を持つことになる。

もちろん、取引処理と実行アーキテクチャ自体に加えて、イーサリアムはより広範なリソース管理とガバナンスメカニズムにおいても全面的な革新を行っています。

03、L1の拡張の他の組み合わせ技

EIP-7987 と zkEVM の他に、イーサリアムはメインネットレイヤーのスケーリングアップグレードを複数の基盤モジュールから全面的に強化し、高性能、低いハードル、強い公平性を備えたオンチェーン実行環境を徐々に構築しています。

例えば、イーサリアム財団はePBSと呼ばれるアーキテクチャの最適化を推進しており、ブロック提案者(Proposer)とブロックビルダー(Builder)の役割を完全に分離することを計画しています。これは、MEVの抽出の不均衡や構築権の独占などの問題を体系的に解決することを目的としており、メカニズムの面からブロック生成の公平性、検閲耐性、透明性を強化します。

さらに重要なのは、ePBSがもう一つの重要なコンポーネントであるFOCILと深く統合されていることです。FOCILの核心的な目標は、ライトノードがオンラインで完全な状態を維持することなく、ブロックとトランザクションの実行結果を検証できるようにすることです。これがePBSと組み合わさることで、将来のイーサリアムの提案、構築、検証プロセスは明確な「三権分立」の構造を形成し、プロトコルの柔軟性を大幅に向上させることになります。

同時にこの組み合わせは、プライバシー取引、ライトノード、モバイルウォレットなどのシーンにより多くの可能性を提供し、参加のハードルを下げています。これは、イーサリアムが徐々に「モジュラーコンセンサスアーキテクチャ」へと向かっていることを示しており、分散型システムにより強いコンポーザビリティと制度的柔軟性をもたらします。

別の過小評価されているが、長期的に非常に価値のあるスケーリングパスは、無状態クライアント(Stateless Ethereum)アーキテクチャである。核心的な考え方は、ノードが「全チェーン状態」に依存することを徹底的に軽減することであり、witness(状態証明)メカニズムを導入することで、ノードは現在の取引に関連するデータのみをダウンロードして検証すればよく、同期と検証コストを大幅に削減できる。

そのため、EFは bloatnet.info と呼ばれる視覚化ツールを推進しており、状態の膨張がネットワークに与える不均衡な負担を定量的に示し、将来の状態のクリーンアップ、簡素化メカニズム、状態の賃貸モデルをサポートする基盤を提供しています。

そのほか、以前のイーサリアム研究チームは、Beam提案についても重点的に検討しており、計算、ストレージ、呼び出しなどのリソースタイプごとに独立した価格曲線を設定することを目指しています。目標は、イーサリアムにより精緻なリソース価格設定メカニズムを導入し、イーサリアムを「単次元課金システム」から「多次元リソース市場」へと変革することであり、これは従来のクラウドコンピューティングのリソーススケジューリングシステムに類似しています。

04、最後に書く

事実を求めて言えば、Rollupのスケーリングが主流となり、アカウントの抽象化が徐々に普及している今日、多くの人々はスケーリングの希望を「オフチェーン実行 + メインネット決済」のL2モデルに全て託しているかもしれません。

しかし現実は、L1の進化は決して止まらず、代替することはできない。

L2はより多くのユーザーを受け入れ、実行スペースを解放できます。一方、L1は統一決済、安全なアンカーとリソース管理の基盤を提供します。両者が協調して進化することで、真に持続可能で高性能、グローバルに通用するWeb3の価値ネットワークを構築できるのです。

未来のイーサリアムは、L1とL2の協調進化を実現することで、真の統一された世界コンピュータに向かうことが可能です。

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