@samcoding
L2開発ツールチェーン 2026 — op-rethとEIP-8130への世代交代
2026年のイーサリアムレイヤー2開発環境の鍵は、生産性とガス効率の最大化にあります。従来の重いGoクライアントフォークや複雑なオフチェーンインフラに代わり、Rustベースの実行エンジンとプロトコルレイヤーのネイティブアカウント抽象化が新たな開発標準として定着しました。特にop-gethの終了とEIP-8130の導入は、ロールアップノードの運用と実戦的なトランザクション設計のあり方を根本から変えています。本稿では、こうしたツールチェーン世代交代の背景を整理し、ビルダーが今すぐアーキテクチャに反映すべき実務的な変更点を解説します。
op-gethの終焉とop-reth・kona-clientの時代
2026年7月8日に適用されたKarstハードフォークを皮切りに、OPスタックのエコシステムで長らく標準となっていたGo言語ベースのクライアントであるop-gethとop-programのサポートが完全に終了しました。すでに2026年5月末に公式技術サポートは終了していましたが、今回のハードフォーク有効化以降は、旧型クライアントを実行するとメインチェーンとの同期ができず、取り残されることになります。したがって、ノード運営者だけでなくローカル環境でテストノードを構築するビルダーも、今後はRustベースの高性能クライアントであるop-rethと、Rust実装の証明システムであるkona-clientの体制へ完全に移行する必要があります。
実行環境がこのように変更された背景には、性能改善に加え、新しい紛争ゲームタイプ「CANNON_KONA」の導入により欠陥証明システムが高度化したことがあります。開発者がローカルテストノードやアーカイブノードを構築する際に直面する最初の実質的な問題は、従来のop-gethが使用していたデータベースフォーマットとop-rethのフォーマットに互換性がないという点です。op-gethはLevelDBやPebbleエンジンを使用する一方、op-rethは超高速データベースであるMDBXフォーマットを採用しているため、既存のデータディレクトリを再利用することはできません。スナップショットを再ダウンロードするか、ジェネシスブロックから完全に同期し直す必要があります。
ターミナルでのノード実行環境も、以下のようにRustパッケージ構成に合わせて変更されます。
# 과거: Go 기반의 op-geth 실행 예시
op-geth \
--datadir ./data \
--rollup.sequencerhttp=https://mainnet-sequencer.optimism.io \
--http
# 현재: Rust 기반의 op-reth 실행 예시 (최소 v2.3.3 버전 필요)
op-reth node \
--chain optimism \
--rollup.sequencer https://mainnet-sequencer.optimism.io \
--http \
--http.api eth,net,web3,debug,engine上記のop-rethノードを正常に稼働させるには、合意クライアントであるop-nodeとの間でJWTセキュリティ認証を通じた1対1の通信設定を完了させる必要があります。また、ネットワークアップグレードを管理するL2コントラクトマネージャーモジュールが追加されたため、ローカル開発環境でも新しいプロトコルルールを含むv2.3.3以上のop-rethイメージを利用してDocker Compose構成を更新することが必須となります。
EIP-8130とEIP-8140 — バンドラー不要のネイティブAAの到来
従来のスマートコントラクトアカウントを実装する際に不可欠だった複雑なオフチェーンインフラが、ついにブロックチェーン実行エンジン内部に統合されます。Baseは、2026年9月に予定されているCobaltアップグレードを通じて、EIP-8130とEIP-8140をReth V2実行エンジンに直接統合し、ネイティブアカウント抽象化の時代を開きます。この重要な変更により、既存のERC-4337方式でボトルネックとなっていたオフチェーンバンドラーやエントリポイントコントラクトへの依存関係を完全に排除できます。
[ERC-4337 흐름]
사용자 서명 -> [오프체인 번들러] -> [엔트리포인트 컨트랙트] -> [스마트 계정] -> 트랜잭션 실행
(대체 메모풀 필요, 가스 시뮬레이션 오버헤드 발생)
[EIP-8130 (0x79) 흐름]
사용자 서명 -> [Reth V2 실행 엔진] (AccountConfiguration 시스템 컨트랙트로 즉시 검증) -> 트랜잭션 실행
(번들러와 엔트리포인트 완전 우회, O(1) 속도로 처리)EIP-8130では、新しいネイティブトランザクションタイプ「0x79」が導入されます。この方式では、トランザクション検証をEVM仮想マシンのスマートコントラクト呼び出しではなく、実行エンジン内部で直接行います。バンドラーを通さずに仮想マシンレベルで署名を検証するため、トランザクションのバイトサイズが83.4%削減され、ガス代計算の誤差やネットワーク混雑時にトランザクションがキャンセルされるといった、長年のユーザーエクスペリエンス上の課題が解決されます。
開発者はすでに専用テストネットの「Base Vibenet」でこの性能向上を直接確認できます。ベンチマークの結果、従来のERC-4337と比較して、通常のUSDC送金ガス代は約63.2%削減（125,000から46,000ガス）、パスキーベースのガス代肩代わり送金も60.3%削減（173,000から68,700ガス）されました。検証コストが通常のEOAに近いレベルまで下がることで、ガス制限予測失敗のリスクなしに、超高速で動作するオンチェーンAIエージェントの決済フローを円滑に設計できるようになりました。
WASMとzkVMへ拡張されるスマートコントラクト開発
EVMの演算速度とメモリ制限を克服しようとする試みは、マルチ仮想マシン構造を通じて実戦的なツールチェーンに統合されました。ArbitrumのStylusは、従来のEVMと対等な位置でWebAssembly（WASM）を実行する補助仮想マシンを実行エンジンに直接組み込みました。これにより、ビルダーはRustを活用して高性能なスマートコントラクトを作成し、WASMファイルとしてコンパイルしてオンチェーンにデプロイできるようになりました。WASMの高い演算効率のおかげで、複雑な暗号学的演算は従来のEVM比で10倍から100倍、メモリ使用コストは100倍から500倍削減されます。ゼロ知識証明に不可欠なPoseidonハッシュなど、EVMではガス代の負担が大きかった数学的演算ループもRustで最適化すれば1万単位の極少量のガスで処理可能であり、これらの高性能コントラクトは既存のSolidityコントラクトと制限なくトークンをやり取りして相互作用できます。
ゼロ知識証明ロールアップ陣営も、複雑な仮想マシン回路設計の限界を超えるため、汎用仮想マシンアーキテクチャへ急速に舵を切っています。代表例としてScrollは、Euclidアップグレードを通じて、これまで自社開発してきたHalo2ベースのzkEVM回路を廃止し、汎用RISC-V仮想マシンであるOpenVMプルーバーを導入しました。過去には特定のガス制限内でトランザクションの回路制限を手動で検証する複雑なプロセスが強制されていましたが、汎用zkVM体制への転換により、複雑さに制限されないゼロ知識証明生成をサポートします。
これと同時に、ステート保存構造も従来のZKフレンドリーなツリーであるzkTrieから、イーサリアム標準規格のMerkle Patricia Trie（MPT）へと正常に回帰しました。OpenVMの強力な証明性能により、標準MPTを直接証明することが可能になったため、外部DAppがL2ステート証明を扱う際の互換性コストが大幅に減少しました。これにデータ可用性オーバーヘッドの最適化が加わり、シーケンサーのボトルネックが完全に解消され、1秒という迅速なブロックタイムを確保することに成功しました。ビルダーにとっては、単なるコンパイルの最適化を超えて、演算密度に合わせたWASMと、検証制限を撤廃したzkVMという強力なインフラが提供されたと言えます。
2026年のL2ビルダーが備えるべき3つの行動指針
2026年のレイヤー2エコシステムは、インフラの複雑性を低減し、実行エンジン自体の性能を極限まで引き上げる方向へ進化しています。ビルダーが実務上のアーキテクチャに今すぐ反映すべき第一歩は、ローカル開発およびテスト環境の実行クライアントをop-rethとkona-clientベースへ転換し、Karstハードフォーク環境との整合性を合わせることです。
次に、既存のERC-4337ベースの重いオフチェーンバンドラーへの依存を排除し、EIP-8130の0x79トランザクション規格をサポートする次世代SDKへの移行を準備する必要があります。最後に、StylusやOpenVMのようなマルチ仮想マシンのトレンドに合わせ、Solidityだけに頼らず、Rustを活用して演算効率を最大化するスマートコントラクト設計の資産を蓄積していくことが重要です。
参考リンク