Cabinet
テクノロジーインサイト一覧へ戻る
2026.09.03

Base、Cobalt で EIP-8130 のネイティブAAを投入予定——バンドラもEntryPointも使わず、ERC-4337比でUSDC送金ガスを63.2%削減

Base、Cobalt で EIP-8130 のネイティブAAを投入予定——バンドラもEntryPointも使わず、ERC-4337比でUSDC送金ガスを63.2%削減

何が起きたか

Base の公式ドキュメントが維持するアップグレードトラッカーに、Cobalt の項目として「EIP-8130 によるネイティブアカウント抽象化の追加、B20 トークン規格の改善、動的ノードアップグレードの導入」が記載されている。Base Sepolia と Base Mainnet の両方が「2026年9月を目標」とされているが、ステータスは Planning であり、活性化タイムスタンプは未確定である。Base 自身が同ページで「確定した活性化タイムスタンプのない月表示は計画目標であり変更されうる」と注記している。ノードソフトウェアの要件も「Cobalt の日程が決まり次第、このページで公開する」とされている段階である。

Base Engineering は2026年7月17日のブログで、EIP-8130 を Base の Cobalt で launch し、その後年内に全 OP Stack チェーンへ展開する方針を示した。Optimism、大手取引所、WalletConnect と連携して EVM チェーン全体への普及を進めるとしている。開発者が事前検証できるよう、Base Vibenet という一時的な devnet が用意されている。ドキュメント上、EIP-8130 は「実験的であり、現在は vibenet devnet でのみ動作する」と明記され、参照実装のリポジトリにも「仕様は変更中でコードは未監査、本番利用不可」の警告が置かれている。

直近の Base は、4月から5月の Base V1 で op-node / op-geth 系のクライアントを切り離して base-reth-node と base-consensus に一本化し、6月の Beryl（Sepolia 6月18日、Mainnet 6月25日活性化）で B20 トークンと Reth V2 を導入してきた。Cobalt はその延長線上にあり、次の Denim では200ミリ秒のネイティブブロックが11月目標として置かれている。

設計上、何が変わるのか

ERC-4337 は、プロトコルを変更せずにスマートアカウントを実現するために、別系統のメンポール、バンドラ、EntryPoint コントラクトという外部インフラを積み上げた。機能は得られるが、それを使うアプリはこのスタックの運用コストと障害モードをまるごと引き受けることになる。EIP-7702 は EOA がコントラクトコードへ委任できるようにして簡素化したが、アカウントの検証は依然として元の単一の鍵に紐づく。

EIP-8130 は、この抽象化をチェーンの内側へ移す。新しいトランザクション型と、オンチェーンのシステムコントラクトの組み合わせで構成され、アカウントは「認可されたアクター」と「認証器（authenticator）」をシステムコントラクトに設定する。プロトコルは、IAuthenticator.authenticate(hash, data) を実装するオンチェーンの認証器コントラクトを使ってトランザクションを検証する。したがってスマートアカウントは、特別な経路ではなく通常のトランザクションとして送られる。

アカウントの実装は2種類が用意されている。DefaultAccount は最小限の構成要素で、executeBatch によるバッチ実行と ERC-1271 の isValidSignature を持ち、認可はすべて Keystore へ委ねる。これは EIP-7702 で委任する EOA の委任先としても単独デプロイされ、EOA はいつでも別の実装へ再委任できるためアップグレード用のラッパーを必要としない。もう一方の CanonicalHighRatePayerAccount は高頻度の支払い元向けで、実行中は自身の ETH の送出をロックし、ガス以外の残高減少を起こさないことと引き換えに、メンポールのレート制限を緩和される。各アカウントは、決定論的な CREATE2 アドレスに置かれた小さなプロキシが共有の実装シングルトンへ delegatecall する構造をとる。

効率の数値としては、ERC-4337 比で USDC 送金のガスが125,000から46,000へ（63.2%減）、トランザクションのバイト長が83.4%減と公表されている。Base のブログはこれを「1トランザクションあたりのエンドユーザーコストを2倍以上削減」と表現している。プロトコル側と協調設計できたことで、トランザクション形式を用途特化かつ最適化可能な形に保てたことが理由として説明されている。

Cobalt にはほかに2つの項目がある。Dynamic Upgrades は、Base ノードのアップグレード時刻を保持する Ethereum 上のスマートコントラクトを導入し、ノードがそれを照会して稼働中に変更を適用できるようにする仕組みである。ただし Cobalt では metrics-only モードでの展開に留まり、正常に機能するかのデータ収集が目的とされている。B20 の改善は、B20 建てでの手数料支払い、乗数更新のスケジューリング、transfer blocked の簡素化、Union / Intersect ポリシーの追加を含む。

想定される落とし穴

第一に、9月という数字は日程ではない。Base 自身が Planning 表記と注記で明示している。にもかかわらず二次記事では「9月に導入」と断定されがちで、これを前提に社内の移行計画を組むと、後ろ倒しでも前倒しでも齟齬が出る。ノード要件は日程確定後に公開される、という順序も押さえておく必要がある。

第二に、既存のスマートアカウント利用者には一度きりの移行手順がある。EOA（標準アカウント）はガススポンサーやバッチを自動的に利用できる一方、ERC-4337 のスマートアカウントを使っている場合は、低いガスコストと速い取り込みの恩恵を受けるために一度アップグレードが必要とされている。この差は、自社ユーザーのアカウント種別によって移行工数がまったく変わることを意味する。

第三に、ノード運用者にとっての作業は「バージョンを上げる」だけではない。Base の説明では、Cobalt 対応に加えて新しい複数の RPC メソッドへのアクセスを許可する必要がある。プロキシやAPIゲートウェイでメソッドをホワイトリスト方式で絞っている構成では、更新を忘れると新形式のトランザクションだけが通らない。

第四に、参照実装は未監査の作業中である。vibenet で動くことと、本番で資金を預けられることは別である。統合の設計検討は今から進めてよいが、監査済みのバージョンが出るまでは本番前提の実装を固定しないほうがよい。

【技術インサイトとアクション】

  1. アカウント抽象化を「外付けインフラ」から「プロトコル機能」へ移すと、アプリ側が抱えていた運用コストと障害モードがチェーン側へ移る。これはバンドラ運用やペイマスタ実装を自社で持っているチームにとって、資産だったものが不要な重複になりうるという意味である。同じ転換は他のOP Stackチェーンにも順次波及する見込みで、自社のAA関連コードの寿命を見直す局面にある。 ［プロダクト側・コントラクト開発者］ 今四半期内に、自社が保有するバンドラ／ペイマスタ／EntryPoint連携コードの棚卸しを行い、EIP-8130 が本番化した場合に不要になる範囲と、残す必要がある範囲を切り分けておく。
  2. 「対応した」の定義が層ごとに違う。今回はノードのバージョン更新に加えて、新規RPCメソッドの許可という別レイヤの作業が伴う。ネットワーク境界でメソッドを絞る構成は、プロトコル変更のたびにこの種の見落としを生む。 ［インフラ・ノード運用者］ Cobalt の活性化タイムスタンプが公表され次第、ノード更新と同時にRPCゲートウェイのメソッド許可リストを見直す作業をチェックリスト化し、テストネットで新形式トランザクションの疎通を確認する。
  3. 計画目標と確定日程を書き分けないと、後で全部が疑わしくなる。Base のように公式が Planning と明記しているケースでは、社内資料もその区別を保ったまま伝えるべきである。 ［全員］ 社内共有時は、Base 公式トラッカーのステータス表記（Planning / Live）と参照日をそのまま併記し、日程が確定したら差分を明示して再共有する運用にする。

【引用：出典】

本記事は公開情報に基づく技術解説であり、投資助言を目的としたものではありません。