Base Azulとは？マルチプルーフと出金日数・ノード移行、Denimで変わった前提【2026年11月】

Base Azulは、Coinbaseが立ち上げたイーサリアムのL2「Base」が自ら設計した最初のネットワークアップグレードです。テストネットのBase Sepoliaで2026年4月20日、メインネットで2026年5月28日18:00（UTC）に有効化されました。発表時点のメインネット目標日は5月13日で、実際の適用はその15日後です。

中身は、出金の安全性を支える証明方式をTEE証明とZK証明の「マルチプルーフ」へ切り替えたこと、ノードをBase独自のbase-reth-nodeとbase-consensusに一本化したこと、EVMをイーサリアムのOsaka仕様にそろえたことです。Azulの説明だけでは足りない点もあります。2026年11月5日のDenimでブロック間隔が2秒から200ミリ秒になり、Azulで手を入れたFlashblocksは廃止されました。この記事では公式仕様とBase本番チェーンへの問い合わせ結果をもとに、Azulの変更点と、その後のアップグレードで上書きされた前提をまとめて整理します。

まとめ：Base Azulの要点と2026年11月時点の状況

• 適用日：Base Mainnetは2026年5月28日18:00 UTC（タイムスタンプ1779991200）。新ルールが効いた最初のブロックは46600927です。
• マルチプルーフ：L1上のAggregateVerifierが、AWS Nitro Enclaveで再実行したTEE証明と、SP1で生成するZK証明の1つまたは2つを検証します。
• 出金日数：標準ブリッジの確定期間は、6月25日のBeryl以降「単一証明5日／TEE＋ZKの二重証明1日」です。通常の提案はTEE証明だけなので、多くの出金は5日側になります。
• ノード：対応クライアントはbase-reth-nodeとbase-consensusだけです。Denim以降のメインネットはbase/base v1.5.1以上が必要です。
• EVM：1トランザクションのガス上限16,777,216、CLZ命令の追加、MODEXPの値上げと入力上限、secp256r1検証のガスが3,450から6,900へ倍増しました。
• Denim（11月5日）：200ミリ秒ごとの正規ブロックになり、Flashblocksは廃止されました。block.numberは以前の10倍の速さで進みます。
• 分散化の段階：ETHBEAT（旧L2BEAT）の判定は2026年11月13日時点でもStage 1です。

Azulの位置付けと適用スケジュール

Azul以前のBaseは、OP Stackの上流ハードフォーク（2025年12月2日のJovianまで）をそのまま採用してきました。Azulは公式ドキュメントが「Base’s first independent network upgrade」と呼ぶとおり、Baseが名前と仕様を自分で決めた最初のアップグレードです。2026年4月の発表記事は、それまでの2か月のクライアント入れ替えで空ブロックを1日約200件から約2件へ減らし、5,000 TPSの瞬間的な処理を複数回記録したと報告しています。

日付はdocs.base.orgのUpgradesページ（2026年11月13日取得）によるものです。Azulを伝えた2026年4月の記事や一部の解説には「5月13日」の日付が残っていますが、確定値は5月28日です。古い日付で作業計画を立てないよう注意してください。

マルチプルーフの仕組み：TEE証明とZK証明

BaseからイーサリアムへのL1出金は、L2の状態（一定区間のブロックをまとめたoutput root）がL1で「正しい」と確定してから実行されます。Azul以前は楽観的な不正証明方式で、全提案が7日の異議申し立て期間を負っていました。公式仕様は、すべての不正な提案に誰かが資金を出して異議を唱え続けなければならない点を「経済的な攻撃面」と呼び、Stage 2に向けた長期の解にはならないと説明しています。

証明の流れとAggregateVerifier

1. プロポーザー（proposer）が次のチェックポイント区間を決め、TEE証明を依頼します。
2. TEEプローバーがAWS Nitro Enclaveの中でそのL2ブロック区間を再実行し、エンクレーブ外に出ない鍵でoutput rootに署名します。
3. プロポーザーは結果を正規のL2状態と照合したうえで、保証金（bond）付きのAggregateVerifierゲームをL1に作ります。
4. チャレンジャーは誰でも運用でき、独自に再計算して不正な主張を見つけたら、ZK証明で異議を唱えます。成功すればTEE側の保証金を報酬として得ます。

ZKプローバーはSuccinctのzkVM「SP1」のプログラムでレンジ証明と集約証明を作り、L1ではSP1のGroth16検証器で確かめます。TEE経路は許可制、ZK経路はパーミッションレスという分担で、両者が食い違えばZK側がTEE側の主張を覆せます。ZK証明そのものの仕組みはゼロ知識証明（ZKP）の仕組みとzk-SNARKの実装解説で扱っています。

出金が1日になる条件と現在の日数

「Azulで出金が1日になった」という紹介は条件を落としています。2026年11月時点のProposerの仕様でも、プロポーザーが提案の作成に受け付けるのはTEEの証明結果だけで、ZKの結果は受け付けません。TEE証明だけの提案が通常経路で、1日の高速経路はZK証明が追加された提案に限られます。公式のProof Systemも、全rootの高速確定はプロポーザーがZKを直接組み込んだ後の話としています。

実際の所要時間は、確定期間に「Baseの状態がL1に提案されるまでの20〜60分程度」と、L1でのprove・finalizeの2トランザクションが加わります（Withdrawalsの仕様）。1日の経路を成立させるため、AzulではOptimismPortal2とAnchorStateRegistryが持っていた3.5日の遅延が外され、待ち時間はAggregateVerifier側に移されました。

ETHやUSDCをイーサリアムとBaseの間で移す経路

確定期間がかかるのは、標準ブリッジでBaseからイーサリアムへ戻す方向だけです。公式のBridge to Baseは、イーサリアムからBaseへの標準ブリッジのデポジットはこの期間を待たないと明記しています。

ETHをイーサリアムからBaseへ移す標準の窓口は、公式が案内するSuperbridgeかBrid.ggです。以前のbridge.base.orgは廃止されています。高速ブリッジは事業者の流動性で先に払い出すだけで、プロトコル上の確定期間は短くなりません。公式も「Baseのセキュリティを引き継がない」と書いているので、少額で試してから使うのが前提です。

USDCは別に考えます。Base上には、Circleが発行するネイティブUSDCと、標準ブリッジ経由のレガシートークンUSDbCが並んでいます。ティッカーではなくコントラクトアドレスで見分け、ネイティブUSDCをイーサリアムへ戻すならCCTP（Baseのドメイン番号は6）でバーン＆ミントします。仕組みと手数料はUSDC Bridge（CCTP）の仕組みと手数料で解説しています。

BaseのStage 1判定と分散化の制約

Azulは「Stage 2分散化への一歩」として発表されましたが、ETHBEATの集計API（ethbeat.org/api/scaling/summary、2026年11月13日取得）でBase ChainはStage 1のままです。ETHBEATは2026年11月4日にL2BEATから改称したサイトで、旧URLは恒久的に転送され、Stageの枠組みは変わっていません。TEE経路が許可制であることは公式仕様も認めています。9月30日のCobaltでは、TEE署名者の登録をRISC Zero・Boundlessの証明からL1上のAWS Nitroアテステーション検証（P-384ヒント方式）に移し、外部の証明サービスへの依存を外しました。Stageは運営からの独立度を測る指標で、セキュリティ評価そのものではありません。読み方はロールアップの仕組みと出金日数の比較で解説しています。

ノード運用者の移行：base-reth-nodeとbase-consensus

Azulに対応するのはbase-reth-node（実行クライアント）とbase-consensus（コンセンサスクライアント）だけです。op-node・op-geth・op-reth・nethermind・konaで動かしていたノードは、適用前に移行しなければ同期が止まります。配布元もリポジトリbase/nodeからbase/baseへ移りました。

実行クライアントの移行：OP Rethとop-geth・nethermindの手順差

OP Rethを使っていた場合は、最新版へ更新するだけでbase-reth-nodeに切り替わり、./reth-dataをそのまま使えます。op-gethとnethermindはサポート対象外になったため、古いデータを削除し、Rethのスナップショットから立ち上げ直します。

# base/node をクローンしたディレクトリの「親」で実行する
(cd node && docker compose down)
git clone https://github.com/base/base.git
cp node/.env.mainnet base/.env.mainnet
cd base
# 指定しないと base/reth-data が新しく作られ、既存データを使わない
export HOST_DATA_DIR="$(cd ../node/reth-data && pwd)"
docker compose config   # volumes の source が既存の reth-data か確認
docker compose up

公式のdocker-compose.ymlは実行層のデータを${HOST_DATA_DIR:-./reth-data}にマウントします。新しいリポジトリへ移っただけでは既存のreth-dataを見に行かないため、上のように絶対パスを渡してから起動します。

コンセンサス層の切り替えとDenim後のバージョン要件

op-nodeからbase-consensusへの切り替えは、.envにUSE_BASE_CONSENSUS=trueを設定し、環境変数の接頭辞をOP_NODE_からBASE_NODE_へ置き換えて再起動します。単純な置換で済まない変数があるため、独自設定を持つノードは公式のNode Upgrade Guideの対応表で確認してください。

Azulで移行を済ませたノードも、Denim以降は版の要件が変わっています。互換性の最低要件はメインネットがbase/base v1.5.1以上、Sepoliaがv1.5.0以上です。2026年11月6日公開のv1.5.4は200msブロックでの同期とブロック伝播の修正を含み、公式が更新を推奨しています。エンジンの既定値（--engine.persistence-thresholdが7から70ブロックなど）も変わるので、独自設定と合わせて確認します。あわせてRETH_FB_WEBSOCKET_URLや--flashblocks-urlなどFlashblocks用の設定は削除します。公式は、今後のリリースでこれらのフラグが消え、残したままだと起動に失敗しうると予告しています。2026年11月13日に公開RPC（mainnet.base.org）へweb3_clientVersionを問い合わせるとreth/v2.5.2-9e380dd/x86_64-unknown-linux-gnu/base/v1.5.4が返りました。

開発者が確認すべきAzulのEVM・RPC変更点

EVM側の変更は、イーサリアムのFusakaに含まれる実行層EIP（Osaka）をBaseへ持ち込むものです。多くのアプリはそのまま動きますが、次の表の「影響が出る例」に当てはまるコントラクトやバックエンドは見直しが必要です。

ガス上限とプリコンパイル料金の影響

EIP-7825の上限を超えるトランザクションは検証段階で拒否されます。巨大なコントラクトのデプロイや、1回で数千件を処理するエアドロップ・一括決済は分割してください。L1からのデポジットは対象外です。ブロックのガス上限はDenimで1ブロック4億から4,000万に下がりましたが、ブロックが10倍の頻度で作られるため、1秒あたりの処理枠は変わっていません。4,000万は通常トランザクション1件の上限16,777,216より大きいため、その上限をさらに下げる変更ではありません。ただし、同じブロックに収められる複数トランザクションの合計ガス量は減ります。

secp256r1（P-256）検証のプリコンパイル0x100は、2024年7月のFjordでRIP-7212として先に入っていたものを、L1のEIP-7951と同じ6,900ガスへそろえました。パスキー署名を検証するスマートウォレットは1回あたり3,450ガス増えるので、ガス見積もりを固定値で持っているリレイヤーやバンドラーは更新が必要です。Azulでは同時にFlashblocksの配信形式から残高・レシートの欄も削られましたが、Flashblocks自体がDenimで廃止されたため、今から対応する意味はありません。

CLZ命令の本番検証：Azul適用前後の実行結果

EVMの変更が本当にその時刻から効いたかは、公開RPCにeth_callを投げれば確かめられます。以下は「1をスタックに積んでCLZを実行し、結果を32バイト返す」だけの初期化コード0x60011e60005260206000f3を、適用直前と直後のブロックで実行した結果です（2026年10月8日実行）。

R=https://mainnet.base.org
for n in 0x2c712de 0x2c712df; do   # 46600926 と 46600927
  curl -s -X POST $R -H 'content-type: application/json' \
    -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_call\",\"params\":[{\"data\":\"0x60011e60005260206000f3\"},\"$n\"]}"
  echo
done

{"jsonrpc":"2.0","error":{"code":-32003,"message":"EVM error: NotActivated"},"id":1}
{"jsonrpc":"2.0","result":"0x00000000000000000000000000000000000000000000000000000000000000ff","id":1}

ブロック46600926（タイムスタンプ1779991199）では「NotActivated」で失敗し、次のブロック46600927（1779991201）では1の先頭ゼロビット数である255（0xff）が返りました。入力を0にすると仕様どおり256（0x100）が返ります。新命令をメインネットのどのブロックから使えるかは、この方法で確定できます。EIP-7910のeth_configは公開RPCでは「rpc method is unsupported」が返り、使うには自前ノードかプロバイダーの対応が必要でした。Solidityの開発環境づくりはSolidity入門の開発環境とSepoliaデプロイ手順、テストの組み方はHardhat 3の使い方が参考になります。

Denimで変わった前提：200msブロックとFlashblocks廃止

2026年11月5日18:00 UTC（日本時間6日3:00）のDenimで、Baseは2秒ごとに1ブロックから、1秒に5ブロックへ移りました。各ブロックが独自のハッシュ・状態ルート・レシートを持つ正規のブロックです。それまで1ブロックの途中経過を配信していたFlashblocksは役目を終えて廃止されました。Azulの記述を前提に作ったアプリやコントラクトは、ここで前提が崩れます。

block.numberを時間に換算するコントラクトの見直し

最も影響が大きいのは、ブロック数を時間の代わりに使うロジックです。公式の200ms Native Blocksは、block.numberが実時間で10倍速く進む一方、block.timestampは秒単位のままだと警告しています。

• 期間が10分の1に縮む：block.number - start >= Nで測るタイムロック・クールダウン、ブロック数で決めた期限、ブロック数ベースのベスティング。ERC20Votesを既定のclock()のまま使うガバナンスでは、投票期間も10分の1になります。
• 上限が10倍に緩む：ブロックが変わるたびにリセットされる1ブロックあたりの上限は、1秒あたりで見ると10倍になります。
• 参照できる過去が短くなる：BLOCKHASHで引ける直近256ブロックは、512秒分から51.2秒分になりました。過去のブロックハッシュを読むブリッジや証明の処理は見直しが必要です。

判断は単純で、アップグレードできるコントラクトはブロック数をblock.timestampの比較へ置き換えます。ガバナンスで変えられる値なら、期間は10倍、ブロックあたりの上限は10分の1に設定し直します。不変のコントラクトにブロック数が焼き込まれている場合は直せないので、影響を見積もって移行を計画するしかありません。block.timestampで経過秒を測るロジックは影響を受けません。ただし、Uniswap V3型TWAPでは観測値を書き込める頻度が増え、固定の観測件数で保持できる履歴時間が最短で従来の半分になるため、長期間の参照が失敗しないか確認が必要です。

Flashblocksの購読から正規ブロックへの移行先

Flashblocksの配信エンドポイントと購読メソッドは、データを返さなくなりました。公式のMigrate From Flashblocksが示す置き換え先は次のとおりです。

"pending"タグは今も受け付けられますが、最新の正規ブロックを指すだけで、事前確定の状態は返しません。Cobaltで入ったValidity Transactionsも、flashblock_indexの条件を付けたものは拒否されます。

適用ブロックの実測：53556127で何が変わったか

Denimの切り替わりも公開RPCで確かめられます。適用直前のブロックと直後の2ブロックについて、番号・秒単位のタイムスタンプ・新しいミリ秒フィールド・ガス上限を取り出したのが次の例です（2026年11月13日実行、jqが必要）。

R=https://mainnet.base.org
for n in 0x331339e 0x331339f 0x33133a0; do   # 53556126〜53556128
  curl -s -X POST $R -H 'content-type: application/json' \
    -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_getBlockByNumber\",\"params\":[\"$n\",false]}" \
  | jq -c '.result | {number, timestamp, timestampMs, gasLimit}'
done

{"number":"0x331339e","timestamp":"0x6aecc41f","timestampMs":null,"gasLimit":"0x17d78400"}
{"number":"0x331339f","timestamp":"0x6aecc421","timestampMs":"0x1a1acde20e8","gasLimit":"0x2625a00"}
{"number":"0x33133a0","timestamp":"0x6aecc421","timestampMs":"0x1a1acde21b0","gasLimit":"0x2625a00"}

10進に直すと読み取れることは3つです。直前のブロック53556126（タイムスタンプ1793901599）にはtimestampMsが無く、ガス上限は4億でした。適用後最初のブロック53556127は1793901601で、timestampMsは1793901601000、ガス上限は4,000万に変わっています。次の53556128は秒単位のタイムスタンプが同じ1793901601のまま、timestampMsだけが200増えました。

秒単位のtimestampが同じブロックが5つ続くので、ブロックの前後関係や経過時間をミリ秒で扱いたいオフチェーンの処理はtimestampMsを読みます。各ブロックの2番目のトランザクションは、BaseTimeプリデプロイ（0x4200000000000000000000000000000000000030）へミリ秒部分を書き込む、プロトコルが自動で入れるデポジットです。トランザクション数を数える集計では、これがブロックごとに1件増える点に注意してください。直近1,000ブロックのタイムスタンプ差は200秒で、適用前の1,000ブロックの2,000秒から10分の1になっていました。

メインネット前のセキュリティ検証：Immunefi監査コンペ

Azulのコードは、メインネット適用前にImmunefiの監査コンペで外部の研究者に公開されました。期間は2026年4月21日から5月4日、賞金プールは最大25万ドルで、USDC on Baseで支払われます。プールの総額は見つかった最も深刻な脆弱性の等級で決まり、Criticalが1件でもあれば25万ドル、Highなら12.5万ドルです。対象はRustとSolidityの約19万行でした。公式ランキングでは、1位のDeltaXVがCritical 2件を含む4件で45,845ドル、2位のQEDが9件で23,295ドル、3位のgzeonが3件で18,456ドルです。参加者ごとの件数には同じ脆弱性の重複報告が含まれうるため、合計しても脆弱性の数にはなりません。

Azul以降のアップグレード：Beryl・Cobalt・Everest

Azulで入った仕組みの一部は、その後のアップグレードで書き換わっています。Denimは上で扱ったので、それ以外の上書き点と次の予定を押さえておきます。

• Beryl（2026年6月25日）：Reth V2を基準の実行クライアントに採用し、単一証明の確定期間を7日から5日に短縮しました。ERC-20互換のトークンをノード内のRustプリコンパイルとして動かすB20も入っています。
• Cobalt（2026年9月30日）：オンチェーンの条件（残高・ストレージ・ブロック番号）が一致したときだけ取り込まれるValidity Transactionsを追加しました。アップグレード時刻をL1のコントラクトから読むDynamic Upgradesは、メインネットでは計測のみのモードです。
• Everest（日程未定）：EIP-8430で定義する新しいトランザクション型（0x79）のBase Transactionsを入れる計画です。一括実行、第三者によるガス代の肩代わり、トークンでのガス支払いを、バンドラーやペイマスターのコントラクト無しで扱います。2026年11月13日時点でSepolia・Mainnetとも日程はTBDです。

アプリ開発者が今すぐ手を付けるべきなのは、Denimのブロック数の扱いです。Everestに対応する予定のウォレットや送信基盤は、公開済みの仕様で影響範囲を確かめておき、日程の発表後に実装と検証の計画を確定します。

よくある質問

Base Azulはいつメインネットに適用されましたか？

2026年5月28日18:00 UTC（日本時間5月29日3:00）です。Base Sepoliaでは4月20日に有効化されました。発表時点の目標日だった5月13日から15日遅れての適用です。

Azulやその後のアップグレードで、既存のスマートコントラクトに変更は必要ですか？

Azul単体でも、gasLimitが16,777,216を超える通常トランザクション、各入力が1024バイトを超えるMODEXP呼び出し、MODEXP・secp256r1の料金変更に依存する処理などは確認が必要です。より広く影響するのは11月5日のDenimで、block.numberを時間として使うタイムロックや投票期間は10分の1に縮みます。

BaseからEthereumへの出金は何日かかりますか？

標準ブリッジのプロトコル上の確定期間は、TEEかZKの片方だけの証明なら5日、両方がそろった提案なら1日です。通常の提案はTEE証明だけなので、多くは5日です。これに提案待ちの20〜60分程度とL1でのトランザクション2回分が加わります。

Azulの適用でBaseはStage 2になりましたか？

なっていません。ETHBEAT（旧L2BEAT）の判定は2026年11月13日時点でStage 1です。AzulはStage 2に向けた証明方式の入れ替えという位置付けです。

Azulに対応していないノードクライアントはどれですか？

op-node・op-geth・op-reth・nethermind・konaです。OP Rethは更新するだけでbase-reth-nodeへ移れますが、op-gethとnethermindはRethスナップショットからの再構築が必要です。Denim以降のメインネットはbase/base v1.5.1以上を使います。

関連記事

• ブロックチェーンのロールアップとは？レイヤー2の仕組み・種類と手数料・出金日数の比較【2026年版】
• ゼロ知識証明（ZKP）とは？仕組み・具体例とzk-SNARKを実際に動かして解説
• USDC Bridge（CCTP）とは｜仕組み・手数料・送金時間と2026年12月のV1停止
• Solidity入門｜開発環境の作り方・基本構文・Sepoliaデプロイ手順【2026年10月】
• Hardhatとは？Hardhat 3の使い方：導入・テスト・デプロイとFoundryとの違い【2026年10月】