Base コード層深度分析

調査時点：2026-05-13
リポジトリパス：./base/repos/（プロジェクトルート相対）
分析手法：クローン済みコード、デプロイ task 履歴、公式 spec の 3 つの次元からのクロス検証

0. リポジトリ一覧（クローン結果）

ローカルディレクトリ	GitHub パス	サイズ	性質
`base-node/`	`base-org/node`	3.4M	ノードオーケストレーション（Docker compose）、グルーコードのみ
`base-contracts/`	`base/contracts`	30M	L1 / L2 コントラクトソース、Base 自社開発の `FeeDisburser` を含む
`base-base/`	`base/base`	65M	Rust 実装の次世代 Base rollup（Flashblocks 含む）
`base-bridge/`	`base/bridge`	8.3M	Base ↔ Solana ブリッジ（非 ETH エコシステムブリッジ）
`base-deployments/`	`base/contract-deployments`	22M	本番デプロイ / アップグレード task の完全履歴（最も歴史的価値が高い）
`base-basenames/`	`base/basenames`	5.8M	base.eth サブドメイン（ENS 派生）
`base-paymaster/`	`base/paymaster`	2.0M	Coinbase Paymaster
`base-account-sdk/`	`base/account-sdk`	9.6M	Base Account SDK
`base-webauthn/`	`base/webauthn-sol`	1.2M	WebAuthn Solidity（Passkey サポートライブラリ）
`base-op-enclave/`	`base/op-enclave`	6.1M	OP Stack ステート遷移 AWS Nitro エンクレーブ PoC
`coinbase-smart-wallet/`	`coinbase/smart-wallet`	3.7M	Coinbase Smart Wallet 主コントラクト
`coinbase-smart-wallet-permissions/`	`coinbase/smart-wallet-permissions`	17M	Smart Wallet 権限モジュール（Session Keys 等）
`coinbase-onchainkit/`	`coinbase/onchainkit`	9.4M	Onchain dev kit React コンポーネント
`coinbase-agentkit/`	`coinbase/agentkit`	25M	AI Agent SDK（Coinbase 主推）
`optimism-monorepo/`	`ethereum-optimism/optimism`	189M	OP Stack monorepo 浅いクローン参照

未取得：
- base/node / base-org/node 同一リポジトリ（base-org にリダイレクト済み、正常にクローン）
- 公式 base/web / base/docs 等のフロントエンド系リポジトリは未クローン（プロトコル層と無関係）
- coinbase/smart-wallet-docs はドキュメントサイトのみ

1. Base リポジトリの全体アーキテクチャ（最重要結論）

1.1 Base は「1 リポジトリ 1 L2」ではない——Base は 3 層アーキテクチャ

全リポジトリを読み終えた後の最重要な構造的発見は：2026-05 時点、Base は OP Stack 派生層から独立した Rust 実装層への移行期にある。3 層が並列に存在する：

Layer A: オーケストレーション層  →  base-org/node           (Docker compose + ENV 設定、reth / geth / op-node をラップ)
Layer B: コントラクト層  →  base/contracts          (Solidity、自社開発の FeeDisburser/L1Block 等カスタムのみ; その他は OP を継承)
Layer C: プロトコル層  →  base/base               (Rust 実装、batcher / builder / proof / consensus フルセット、
                                              自社開発の Flashblocks パイプライン、OP Stack 主分枝を対標するが依存しない)

歴史的経路：
- 2023-08 ~ 2025：A 層 + B 層、C 層 = ethereum-optimism/optimism の Go 実装（独立フォークなし）
- 2025-2026：C 層で Rust 実装を着地開始、B 層では OP コントラクトを徐々に Base proxy 制御に置換
- 2026-02-19：「Superchain Separation」を実行（詳細は §6 参照）、Base はガバナンス / アップグレード権限において共有 Superchain config から離脱

1.2 base-org/node リポジトリ = ノード運用ラッパー（ソースコードではない）

出典：base-node/README.md:1-50 + base-node/docker-compose.yml

base-node/
├── .env.mainnet         # 80KB+ 本当の設定
├── .env.sepolia
├── docker-compose.yml   # supervisord + op-node + reth/geth/nethermind
├── geth/                # geth client コンテナ定義
├── reth/                # reth client コンテナ定義（デフォルト）
├── nethermind/          # nethermind client コンテナ定義
├── op-node-entrypoint
├── base-consensus-entrypoint
└── versions.json        # OP / client バージョンを固定

観察：
- このリポジトリは完全に Base ソースコードを含まない——OP Stack 上流のバイナリ（op-node、reth/geth/nethermind）をオーケストレーションして Base を稼働させるだけ
- デフォルト client は reth（Rust EVM 実行エンジン）であり geth ではない —— Base は client 選定において明らかに Rust に偏っている
- .env.mainnet は真の chain spec エントリ：Genesis Hash、L1 RPC、batcher inbox 等

1.3 base/contracts コントラクト構造

src/
├── L1/                            ← L1 上のブリッジ/システムコントラクト
│   ├── OptimismPortal2.sol        (674 行)  フォールトプルーフ版メインブリッジ
│   ├── SystemConfig.sol           (610 行)  rollup パラメータ設定
│   ├── L1StandardBridge.sol       (353 行)
│   ├── L1CrossDomainMessenger.sol
│   ├── L1ERC721Bridge.sol
│   ├── ETHLockbox.sol             (10 KB) — ⭐ Superchain Separation 後の ETH 集中ストレージ
│   ├── SuperchainConfig.sol       (8 KB)
│   ├── ResourceMetering.sol
│   ├── BalanceTracker.sol         (8 KB)
│   └── proofs/                    フォールトプルーフシステム
├── L2/                            ← L2 上のプリデプロイコントラクト
│   ├── L1Block.sol                (218 行)
│   ├── L2StandardBridge.sol
│   ├── L2CrossDomainMessenger.sol
│   ├── L2ToL1MessagePasser.sol
│   ├── L2ERC721Bridge.sol
│   ├── GasPriceOracle.sol         (297 行)
│   ├── FeeVault.sol               (8 KB)
│   ├── SequencerFeeVault.sol      ← シーケンサーのチップ収益
│   ├── BaseFeeVault.sol           ← Base fee 収益
│   ├── L1FeeVault.sol             ← L1 データコスト回収
│   ├── OperatorFeeVault.sol       ← Operator fee（未使用、詳細は下記）
│   ├── FeeDisburser.sol           (158 行) ⭐⭐⭐ Base 自社開発、定期的に収益を L1 にブリッジ
│   ├── OptimismMintableERC721.sol
│   ├── OptimismMintableERC721Factory.sol
│   └── WETH.sol
├── universal/                     ← クロスレイヤー共通基盤
│   ├── CrossDomainMessenger.sol
│   ├── StandardBridge.sol
│   ├── ProxyAdmin.sol
│   ├── Proxy.sol
│   ├── OptimismMintableERC20.sol
│   ├── OptimismMintableERC20Factory.sol
│   ├── OwnableManagedUpgradeable.sol
│   ├── ReinitializableBase.sol
│   ├── ProxyAdminOwnedBase.sol
│   ├── ERC721Bridge.sol
│   ├── WETH98.sol
│   └── CBMulticall.sol            ← Coinbase 自社開発 Multicall
├── cannon/                        ← Cannon 不正証明 VM
├── libraries/
├── legacy/                        ← ChugSplash 旧版互換
└── vendor/

出典：リポジトリ ls src/L1、ls src/L2、ls src/universal（base-contracts ルートで実行）

重要な観察：
- コントラクト名の 90% は OP Stack 上流と一致 —— Base は OP コントラクトを再利用
- 4 つのファイルのみが Base の真の自社開発 / 変更：FeeDisburser.sol、CBMulticall.sol、L1Block.sol（変更）、FeeVault.sol 派生の可能性
- OperatorFeeVault.sol は存在するが FeeDisburser で明示的にコメントアウトされ無視されている（”Base does not currently use it”）

2. Base 自社開発コントラクトの個別分析

2.1 FeeDisburser.sol —— Base 収益分配の核心

パス：base-contracts/src/L2/FeeDisburser.sol（158 行）
実デプロイ：base-deployments/mainnet/2023-08-28-deploy-revshare/ と 2026-03-11-patch-fee-disburser/ 参照

コアロジック

// ファイル：base-contracts/src/L2/FeeDisburser.sol:12-95
contract FeeDisburser is ISemver {
    uint32 public constant WITHDRAWAL_MIN_GAS = 35_000;
    address public immutable L1_WALLET;
    uint256 public immutable FEE_DISBURSEMENT_INTERVAL;
    uint256 public lastDisbursementTime;
    uint256 public netFeeRevenue;  // legacy、廃止済み

    constructor(address l1Wallet, uint256 feeDisbursementInterval) {
        if (l1Wallet == address(0)) revert ZeroAddress;
        if (feeDisbursementInterval < 24 hours) revert IntervalTooLow;
        ...
    }

主要パラメータ：
- FEE_DISBURSEMENT_INTERVAL：ハード下限 24 時間（これより低くできない）—— 1 日 1 回の決済リズム
- WITHDRAWAL_MIN_GAS = 35_000：L1 ウォレットへのクロスレイヤーブリッジの最小 gas

分配フロー（disburseFees 関数）

// FeeDisburser.sol:102-128
function disburseFees external virtual {
    if (block.timestamp < lastDisbursementTime + FEE_DISBURSEMENT_INTERVAL)
        revert IntervalNotReached;

    // Sequencer/Base/L1 の 3 つの FeeVault を一括で引き出し（OPERATOR はスキップ）
    _feeVaultWithdrawal(payable(Predeploys.SEQUENCER_FEE_WALLET));
    _feeVaultWithdrawal(payable(Predeploys.BASE_FEE_VAULT));
    _feeVaultWithdrawal(payable(Predeploys.L1_FEE_VAULT));

    uint256 feeBalance = address(this).balance;
    if (feeBalance == 0) { emit NoFeesCollected; return; }

    lastDisbursementTime = block.timestamp;

    // 全額を L1 ウォレットにブリッジ
    IL2StandardBridge(payable(Predeploys.L2_STANDARD_BRIDGE)).bridgeETHTo{
        value: address(this).balance
    }(L1_WALLET, WITHDRAWAL_MIN_GAS, bytes(""));

    emit FeesDisbursed(lastDisbursementTime, 0, feeBalance);
}

重大な設計上の意味：
1. FeeDisburser 自体は 15/85 分配を行わない —— L2 上のすべての fee をパッキングして L1 ウォレットにブリッジするだけ
2. 真の「15% net profit / 2.5% gross revenue」分配ロジックは L1 SmartEscrow コントラクトで発生（§6.2 参照）
3. このシンプルさにより FeeDisburser コントラクトのアップグレードは稀で、2023-08-28 のデプロイ後、2026-03-11 に 1 回 patch しただけ（詳細は base-deployments/mainnet/2026-03-11-patch-fee-disburser/ 参照）

2.2 OptimismPortal2.sol —— メインブリッジコントラクト（Base は変更していない）

パス：base-contracts/src/L1/OptimismPortal2.sol（674 行）

Base リポジトリにこのファイルがあるものの、内容は OP Stack 上流のフォールトプルーフ版メインブリッジをほぼ完全に再利用している。記録すべきはその継承構造：

// OptimismPortal2.sol:36
contract OptimismPortal2 is
    Initializable,
    ResourceMetering,        // 1559-like リソース計測
    ReinitializableBase,     // 再初期化可能（アップグレードパス）
    ProxyAdminOwnedBase,     // ProxyAdmin owner チェック
    ISemver
{
    struct ProvenWithdrawal {
        IDisputeGame disputeGameProxy;  // フォールトプルーフ game 参照
        uint64 timestamp;
    }
    uint256 internal immutable PROOF_MATURITY_DELAY_SECONDS;
    uint256 internal constant DEPOSIT_VERSION = 0;
    uint64 internal constant RECEIVE_DEFAULT_GAS_LIMIT = 100_000;
    ...
}

主要ストレージスロット（OptimismPortal2.sol:60-150）：
- mapping(bytes32 => bool) public finalizedWithdrawals — 最終化済み出金
- mapping(bytes32 => mapping(address => ProvenWithdrawal)) public provenWithdrawals — マルチ prover 設計
- mapping(bytes32 => address[]) public proofSubmitters — 各 withdrawal の全 prover を追跡

オリジナル OptimismPortal (V1) との差異（出典：コメント 107-114）：

“Original OptimismPortal contract only allowed one proof to be submitted for any given withdrawal hash. Fault Proofs version of this contract must allow multiple proofs for the same withdrawal hash to prevent a malicious user from blocking other withdrawals by proving them against invalid proposals.”

—— これは V1 から V2 へのコアセキュリティ改善：複数の prover が同時にチャレンジ可能にすることで、悪意ある 1 つの proof が withdrawal チャネル全体をブロックすることを防ぐ。

2.3 ETHLockbox.sol —— Superchain 分離後の ETH 集中ストレージ

パス：base-contracts/src/L1/ETHLockbox.sol（10 KB）

このコントラクトは OP Stack U16 アップグレード（”Interop”）後に導入されたもの。Superchain マルチチェーン環境下では、ネイティブ ETH の相互運用をサポートするために、全チェーンの L1 ETH を 1 つの lockbox に集約する必要がある。Base のデプロイ履歴：

2025-10-07-upgrade-to-U16a — U16 alpha にアップグレード（Interop 準備を含む）
2025-11-21-u17-jovian-upgrade — U17 Jovian
2026-01-09-op-stack-upgrade-18 — U18（cannon+kona fault proof + CGT v2 含む）

出典：base-deployments/mainnet/2026-01-09-op-stack-upgrade-18/README.md：

“Upgrade 18 is a proposed network upgrade for OP Stack chains, which introduces cannon+kona fault proof support (including an optional switch to Kona proofs as the respected game type) and introduces Custom Gas Token v2 (CGT v2) for chains that want to use a non-ETH native fee currency.”

2.4 SystemConfig.sol —— Rollup パラメータ制御センター

パス：base-contracts/src/L1/SystemConfig.sol（610 行）

主要パラメータ：batcherHash、gasLimit、scalar（fee scalar）、unsafeBlockSigner（P2P 署名アドレス）等。gas limit 調整は毎回、ここをマルチシグで呼び出すことで行う。

デプロイ履歴から Base の gas limit 調整頻度を逆算できる：

2024-03-26-increase-gas-limit
2024-04-01-increase-gas-limit
2024-05-28-increase-gas-limit
2024-05-30-increase-gas-limit
2024-06-17-increase-gas-limit
2024-06-25-update-gas-config
...
2025-10-28-increase-gas-and-elasticity-limit
2025-11-05-increase-gas-limit
2025-11-10-increase-gas-and-elasticity-limit
2025-12-08-increase-gas-and-elasticity-limit
2025-12-15-increase-min-base-fee
2026-01-20-update-basefee-da-footprint
2026-01-28-update-min-base-fee
2026-02-03-eip1559-denominator-increase
2026-02-17-update-min-base-fee
2026-03-25-increase-gas-and-elasticity-limit

—— 2024 年内に少なくとも 6 回 gas limit を調整；2025 H2 はほぼ毎月 1 回。これは Base のキャパシティ継続的引き上げのオンチェーン痕跡である。

3. base/base —— 次世代 Rust 実装（最重要な発見）

パス：base-base/（65MB Rust プロジェクト、Rust workspace を確立済み）

3.1 なぜこのリポジトリが重要か

出典：base-base/README.md、base-base/Cargo.toml、base-base/CLAUDE.md、base-base/docs/specs/

README.md:1-8 より引用：
```

Base

Base is a rollup built on Ethereum.
…
1-second and <1-cent transactions…
```

これは Base 自身が書いた完全な Rust rollup 実装である——Base が「OP Stack Go ノードのユーザー」から「独自プロトコル層のメンテナー」へ進化していることを意味する。これは 2026-02-18 あたらしい経済の報道と一致している：

“コインベース開発のL2「Base」、OPスタックから独自の統合スタックへ移行”

3.2 Rust workspace 構造

base-base/
├── bin/                  ← 17 個の独立実行バイナリ
│   ├── base              ← メインエントリ
│   ├── basectl           ← 制御ツール
│   ├── based             ← daemon
│   ├── batcher           ← Batcher サービス
│   ├── builder           ← Block builder
│   ├── challenger        ← フォールトプルーフ challenger
│   ├── consensus         ← Consensus ノード
│   ├── node              ← フルノード
│   ├── proposer          ← Output 提案者
│   ├── prover            ← フォールトプルーフ prover
│   ├── prover-registrar  ← Prover 登録
│   ├── ingress-rpc       ← 入境 RPC ゲートウェイ
│   ├── load-tester
│   ├── mempool-rebroadcaster
│   ├── audit-archiver
│   └── websocket-proxy
├── crates/               ← 8 個のライブラリ
│   ├── batcher/          (admin, blobs, comp, core, encoder, service, source)
│   ├── builder/          (core, metering, publish)
│   ├── consensus/        (cli, derive, disc, engine, gossip, peers, protocol,
│   │                       providers, rpc, safedb, service, sources, upgrades)
│   ├── execution/        (bundle, chainspec, cli, consensus, engine-tree, evm,
│   │                       exex, flashblocks, flashblocks-node, metering, node,
│   │                       payload, proofs, rpc, runner, trie, tx-forwarding,
│   │                       txpool, txpool-rpc, txpool-tracing)
│   ├── proof/            (challenge, client, contracts, driver, executor, host,
│   │                       mpt, preimage, primitives, proof, proposer, rpc, succinct)
│   ├── common/
│   ├── infra/
│   └── utilities/
├── docs/                 ← 完全な spec サイト
├── devnet/               ← ローカル開発ネット
├── etc/                  ← 設定例
└── baseup/               ← バージョン管理ツール（foundryup を模倣）

3.3 Flashblocks のコード層上の位置

出典：base-base/crates/execution/：

flashblocks/        ← コア Flashblocks ロジック
flashblocks-node/   ← Flashblocks-enabled node

flashblocks crate は payload / engine-tree と並列 —— Flashblocks は一時的なパッチではなく、execution 層の一等市民である。

Spec レベル（出典：base-base/docs/specs/pages/protocol/overview.md:59）：

“Produces Flashblocks every 200ms, committing to the ordering of transactions within the block as it is being built.”

順序制約（出典：検索 + 公式 blog）：

“Each 2-second block on the Base chain is formed after 10 different Flashblocks have been processed… once a Flashblock is built and broadcast, its transaction ordering is locked even if a transaction with a higher priority fee arrives later”

—— これはユーザー MEV 体験の根本的改善である：フロントランナーは、後から到着しても、より高い priority fee で前置することはできない（Flashblock が既にロックされているため）。

3.4 succinct ZK Prover サブ crate

出典：base-base/crates/proof/succinct/

これは Base が Succinct (SP1) ZK prover を統合するコードモジュールである。Cannon (FPVM) 以外に、Base が並行して ZK 不正証明パスを開発していることを意味する。Upgrade 18 の “cannon+kona” 表現と合わせると、Base は マルチ proof システムを構築している：

Cannon（上流 OP）
Kona（Rust-based fault proof program）
Succinct（SP1 ZK パス）

3.5 base/base の命名規約（Rust エンジニアリング）

出典：base-base/CLAUDE.md

“All crates in the workspace should have a base- prefix in their crate name (e.g. base-enclave, base-builder-core).”
“Binary crates (bin/) should contain minimal glue code. All meaningful logic belongs in library crates.”
“Use structured tracing instead of interpolated strings.”

—— これは Base エンジニアリングチーム（高確率で Reth/Paradigm からコア Rust 開発者を引き入れた）が、Reth のエンジニアリング文化を丸ごと持ち込んだことを示している。Base ノードのデフォルト client が geth ではなく reth であることも、これをさらに裏付ける。

4. Coinbase Smart Wallet コントラクト分析

パス：coinbase-smart-wallet/src/

src/
├── CoinbaseSmartWallet.sol         (358 行) ⭐ メインコントラクト
├── CoinbaseSmartWalletFactory.sol  (98 行)  CREATE2 factory
├── MultiOwnable.sol                (287 行) マルチ owner 管理
├── ERC1271.sol                     (156 行) ERC-1271 署名検証
└── utils/
    └── ERC1271InputGenerator.sol   (89 行)

4.1 重要なコード断片

出典：coinbase-smart-wallet/src/CoinbaseSmartWallet.sol

// CoinbaseSmartWallet.sol:22
contract CoinbaseSmartWallet is ERC1271, IAccount, MultiOwnable, UUPSUpgradeable, Receiver {

    // CoinbaseSmartWallet.sol:25-31
    struct SignatureWrapper {
        uint256 ownerIndex;     // MultiOwnable.ownerAtIndex への index
        bytes signatureData;    // ECDSA (r,s,v) または ABI-encoded WebAuthnAuth
    }

    // CoinbaseSmartWallet.sol:33-41
    struct Call {
        address target;
        uint256 value;
        bytes data;
    }

    // CoinbaseSmartWallet.sol:51 ⭐⭐⭐ クロスチェーン nonce key を Base メインネット chain ID にハードコード
    uint256 public constant REPLAYABLE_NONCE_KEY = 8453;

なぜ REPLAYABLE_NONCE_KEY = 8453 か？8453 = Base メインネット chain ID。この値はクロスチェーン replay の nonce key の上位 192 bit として使用される —— ユーザーが Base で “executeWithoutChainIdValidation” 呼び出し（add owner / upgrade implementation など）を署名すると、他のチェーン上の Smart Wallet インスタンスはその署名を直接 replay でき、再度署名する必要がない。

4.2 クロスチェーン replay 検証ロジック

出典：coinbase-smart-wallet/README.md

// 0xbf6ba1fc = bytes4(keccak256("executeWithoutChainIdValidation(bytes)"))
if (userOp.callData.length >= 4 && bytes4(userOp.callData[0:4]) == 0xbf6ba1fc) {
    userOpHash = getUserOpHashWithoutChainId(userOp);
    if (key != REPLAYABLE_NONCE_KEY) {
        revert InvalidNonceKey(key);
    }
} else {
    if (key == REPLAYABLE_NONCE_KEY) {
        // 逆方向も禁止：非 replay 呼び出しは replay nonce key を使えない
    }
}

—— これは Coinbase Smart Wallet の「sign once, replay everywhere」メカニズムの核心である。これにより Smart Wallet は複数のチェーン上で owner / config を同期し続けるためにユーザーが各チェーンで署名する必要がない。

4.3 2 要素署名：EOA + Passkey

出典：coinbase-smart-wallet/README.md + CoinbaseSmartWallet.sol

- Ethereum address owners → signatureData = abi.encodePacked(r, s, v)
- Passkey (secp256r1) owners → signatureData = abi.encode(WebAuthnAuth)
  ↑ base-org/webauthn-sol/src/WebAuthn.sol の WebAuthnAuth 構造を借用

なぜ public key を直接渡さずに ownerIndex を使うのか？

“We pass an ownerIndex rather than the public key itself to optimize for calldata, which is currently the main cost driver on Ethereum layer 2 rollups, like Base.”

—— つまり Base チーム自身が設計した Smart Wallet が、calldata コストにおいて Base L2 のために明示的に最適化されている。これはエンドツーエンドの協調設計の例である。

4.4 owners 上限

出典：MultiOwnable.sol

“Our smart wallet supports a practically unlimited number of concurrent owners (max 2^256). Each owner can transact independently, without sign off from any other owner.”

—— これはマルチシグとは明らかに異なる。Coinbase Smart Wallet は「いずれかの owner が独立して署名・発行可能」モデルであり、”M-of-N” ではない。これは Passkey マルチデバイス同期シナリオ（同一アカウントの携帯/PC/iPad）をサポートするためである。

5. Base ↔ Solana ブリッジ（base/bridge）

パス：base-bridge/
デプロイ task：base-deployments/mainnet/2025-11-25-base-bridge-deployment/
公式リリース日：2025-12-04（CoinDesk / Base 公式 blog）

5.1 リポジトリ構造

base-bridge/
├── base/      ← EVM 側 Solidity コントラクト
├── solana/    ← Solana 側 Rust プログラム
└── clients/   ← クロスチェーンメッセージリレークライアント

5.2 主要アーキテクチャ（出典：base-bridge/README.md）

“A bridge between Base and blockchains outside the Ethereum ecosystem. Currently has support for Solana.”
“After initiating on Base, wait ~15 minutes for an updated root to be posted to Solana and complete the transfer with prove + finalize steps”

特徴：
- シンプルな「burn してから mint」ではなく、prove + finalize の 2 ステップ式（OP Portal の withdrawal フローに類似）
- ~15 分の遅延 = Solana 側で root が commit される周期
- 二重検証：Coinbase ノード + Chainlink CCIP ノードが独立して署名する必要がある

5.3 これが意味するところ

戦略的に：Base は「ETH 系のみのブリッジ」のコンフォートゾーンを抜け出し、Solana を最重要のクロスエコシステム目標としている。
- Base が起点（Solana チーム主導ではない）
- 最初に統合された dApp は Zora、Aerodrome、Virtuals、Flaunch、Relay（出典：cryptoslate）
- 情報源では “vampire attack”（吸血鬼攻撃）と表現され、目的は Solana 上の流動性を吸い上げること

base-deployments/mainnet/2025-11-25-base-bridge-deployment/README.md 記載：

“Deploys the Base side of Base Bridge. This should be done after deploying the Solana bridge program since the program’s pubkey needs to be added to config.json.”

—— Solana 側を先にデプロイし、Base 側がそれに続いてデプロイされたことを示す。

6. Superchain 分離 task 深度分析（最重大イベント）

デプロイ task パス：base-deployments/mainnet/2026-02-19-superchain-separation/

6.1 task 内容（出典：README.md）

“This task executes our migration away from the shared Superchain configuration to a Base-owned configuration.”

7 件のトランザクションを含む（EXECUTED 済み）：

UpdateProxyAdminOwnerSigners — ProxyAdmin owner マルチシグの署名者を更新
UpdateCBSafeSigners — Coinbase signer Safe を更新、nested safe を EOA 直接署名に変更
UpgradeSystemConfig — SystemConfig をアップグレード（Superchain shared 設定から離脱）
UpgradeFeeDisburser — FeeDisburser をアップグレード（新分配ルールに対応）
TerminateSmartEscrow — OP collective の智能エスクローコントラクトを終了 (0x75ddb1... on Optimism mainnet)
WithdrawSmartEscrow — SmartEscrow から残余の未 vested OP token を引き出し
AddSecurityCouncilSigner — Security Council に signer を追加

6.2 TerminateSmartEscrow とは

出典：script/TerminateSmartEscrow.s.sol、script/WithdrawSmartEscrow.s.sol

// WithdrawSmartEscrow.s.sol:18-22
interface ISmartEscrow {
    function withdrawUnvestedTokens external;
    function contractTerminated external view returns (bool);
}
IERC20 public constant OP_TOKEN = IERC20(0x4200000000000000000000000000000000000042);

—— SmartEscrow は 2024-02-21 にデプロイ、2024-04-15 / 06-05 に redeploy されたコントラクト（base-deployments mainnet ディレクトリ参照）であり、vesting schedule に従って 118M OP token grant を Base に解放する役割を担っていた。2026-02-19 のこのトランザクションは直接：
1. escrow を terminated とマーク
2. 全ての未 vested OP を Coinbase L1 ウォレットに回収

意味：Base は Optimism Collective との OP token ロックアップ協定を早期終了した。これは通常、別れまたは再交渉のシグナルである。

6.3 CBSafeSigners の改造

出典：script/UpdateCBSafeSigners.s.sol:16-25

contract UpdateCBSafeSigners is MultisigScript {
    uint256 internal constant INTERIM_THRESHOLD = 1;
    uint256 public constant FINAL_THRESHOLD = 3;
    address public immutable OWNER_SAFE = vm.envAddress("CB_SIGNER_SAFE_ADDR");
    address public immutable SECURITY_COUNCIL = vm.envAddress("CB_SC_SAFE_ADDR");
    address public immutable CB_NESTED_SAFE = vm.envAddress("CB_NESTED_SAFE_ADDR");

    // フロー：
    // 1. OWNER_SAFE から SECURITY_COUNCIL を削除（一時的に threshold を 1 に）
    // 2. CB_NESTED_SAFE 内の全 EOA を OWNER_SAFE の直接 signer として追加
    // 3. CB_NESTED_SAFE を削除、threshold を FINAL_THRESHOLD=3 に調整

—— Base は「ネストされたマルチシグ」を「3-of-N EOA 直接署名」にフラット化した。これはガバナンスの簡素化（ネスト層が 1 つ減り、意思決定が速くなる）であると同時に、集中度の上昇でもある（ネスト構造では SC は独立した Safe だったが、現在は SC が削除されており、別の場所に移動した可能性がある）。AddSecurityCouncilSigner.s.sol と合わせて完全な絵を見る必要がある。

6.4 署名の複雑度（出典：README.md）

Signer Profile	Parts
Coinbase Signer	6 parts
Security Council Signer	4 parts
Optimism Signer	1
Optimism OP Mainnet Signer	1

—— 全体の分離を完了するには合計 12 件の署名が必要。これは多者ガバナンス構造が「別れ前」にもまだ通すべき手続きを通すことを示しているが、別れた後は OP の 2 つの signer は高確率で Base ガバナンスの意思決定に関与しなくなる。

7. Base の Predeploys アドレステーブル（デプロイ履歴より）

出典：base-deployments/mainnet/addresses.json

{
  "AddressManager":                      "0x8EfB6B5c4767B09Dc9AA6Af4eAA89F749522BaE2",
  "L1CrossDomainMessengerProxy":         "0x866E82a600A1414e583f7F13623F1aC5d58b0Afa",
  "L1ERC721BridgeProxy":                 "0x608d94945A64503E642E6370Ec598e519a2C1E53",
  "L1StandardBridgeProxy":               "0x3154Cf16ccdb4C6d922629664174b904d80F2C35",  ← ユーザーが最もよく使うブリッジ入口
  "L2OutputOracleProxy":                 "0x56315b90c40730925ec5485cf004d835058518A0",
  "OptimismMintableERC20FactoryProxy":   "0x05cc379EBD9B30BbA19C6fA282AB29218EC61D84",
  "OptimismPortalProxy":                 "0x49048044D57e1C92A77f79988d21Fa8fAF74E97e",  ← メインブリッジ
  "ProxyAdmin":                          "0x0475cBCAebd9CE8AfA5025828d5b98DFb67E059E",
  "SystemConfigProxy":                   "0x73a79Fab69143498Ed3712e519A88a918e1f4072",
  "SystemDictatorProxy":                 "0x1fE3fdd1F0193Dd657C0a9AAC37314D6B479E557"
}

Basenames コントラクト（L2 上、出典：base-basenames/README.md）：

Registry:                          0xb94704422c2a1e396835a571837aa5ae53285a95
BaseRegistrar:                     0x03c4738ee98ae44591e1a4a4f3cab6641d95dd9a
RegistrarController:               0x4cCb0BB02FCABA27e82a56646E81d8c5bC4119a5
ReverseRegistrar:                  0x79ea96012eea67a83431f1701b3dff7e37f9e282
L2Resolver:                        0xC6d566A56A1aFf6508b41f6c90ff131615583BCD
MigrationController:               0x8d5ef54f900c82da119B4a7F960A92F3Fa8daB43
UpgradeableRegistrarController:    0xa7d2607c6BD39Ae9521e514026CBB078405Ab322
UpgradeableL2Resolver:             0x426fA03fB86E510d0Dd9F70335Cf102a98b10875

8. Base アップグレード履歴タイムライン（deployment task から逆算）

base-deployments/mainnet/ ディレクトリの順序を基に、Base の実際のオンチェーンアップグレード履歴を整理：

2023 — ローンチと初期化期

2023-06-14-deploy                          初期デプロイ
2023-06-14-deploy-deterministic-proxy
2023-06-14-test-tx
2023-06-15-unpause-portal
2023-06-15-validate-deploy
2023-06-21-transfer-system-cfg-owner
2023-07-11-test-l2-safe
2023-07-17-test-l1-nested-safe
2023-07-19-challenger-1-of-2
2023-07-19-test-l2-nested-safe
2023-07-26-transfer-owner-nested-safes      ← ガバナンスマルチシグ経路の確立
2023-08-07-test-op-fee-nested-safe
2023-08-15-support-eas                      ← Ethereum Attestation Service サポート
2023-08-22-fee-vault-fix                    ← ローンチ後初の hotfix
2023-08-28-deploy-revshare                  ← ⭐ FeeDisburser 稼働

2024 — Bedrock/Ecotone/Fjord 時代

2024-02-21-setup-smart-escrow               ← OP token vesting 開始
2024-02-23-transfer-op
2024-03-05-pause-unpause-test
2024-03-07-ecotone-sysconfig-updates        ← Ecotone ハードフォーク（Dencun/EIP-4844 前夜）
2024-03-26-increase-gas-limit
2024-04-01-increase-gas-limit
2024-04-12-deployERC20Factory               ← ネイティブ USDC 経路の準備
2024-04-15-redeploy-smart-escrow
2024-04-17-upgrade-erc20-factory
2024-04-30-deployTempERC20Factory
2024-05-28-increase-gas-limit
2024-05-30-increase-gas-limit
2024-06-05-reredeploy-smart-escrow          ← Smart Wallet 公開日（2024-06-05）と同時期
2024-06-17-increase-gas-limit
2024-06-25-update-gas-config
...
（途中の複数回の gas 調整は省略）

2025 — Stage 1 / Flashblocks / Security Council

2025-04 頃                               Stage 1 達成（フォールトプルーフ稼働 + Security Council）
2025-07 頃                               Flashblocks メインネット稼働
2025-08-06                                Sequencer handoff 33 分停止
2025-08-13-safe-swap-owner                ← マルチシグガバナンス調整
2025-10-06-funding
2025-10-07-upgrade-to-U16a                ← U16 alpha
2025-10-20-incident-multisig-signers      ← インシデント後の signer 調整
2025-10-28-increase-gas-and-elasticity-limit
2025-11-05-increase-gas-limit
2025-11-10-increase-gas-and-elasticity-limit
2025-11-15-deploy-cb-multicall
2025-11-20-deploy-cb-multicall
2025-11-21-u17-jovian-upgrade             ← U17 Jovian
2025-11-25-base-bridge-deployment         ← ⭐ Base-Solana ブリッジデプロイ
2025-12-01-pause-bridge-base
2025-12-04-set-jovian-parameters
2025-12-08-increase-gas-and-elasticity-limit
2025-12-15-increase-min-base-fee

2026 — Superchain Separation + キャパシティ継続拡張

2026-01-09-op-stack-upgrade-18            ← ⭐ Cannon + Kona フォールトプルーフ、CGT v2
2026-01-20-update-basefee-da-footprint
2026-01-28-update-min-base-fee
2026-02-03-eip1559-denominator-increase
2026-02-17-update-min-base-fee
2026-02-19-superchain-separation          ← ⭐⭐⭐ Superchain との分離
2026-02-27-pause-superchain-config        ← 分離の締めくくり操作
2026-03-11-patch-fee-disburser            ← FeeDisburser 微調整
2026-03-25-increase-gas-and-elasticity-limit

9. OP Stack 上流との差分 diff（高レベル）

クローン済みの base-base、base-contracts vs optimism-monorepo の対比のみ：

指標	OP Stack 上流	Base カスタム
ノード実装	Go (op-node) + op-geth	reth (Rust) デフォルト + base/base Rust 代替実装
コンセンサス/derivation	Go	Rust (base-base/crates/consensus)
Batcher	Go (op-batcher)	Rust (base-base/crates/batcher + bin/batcher)
Block builder	op-geth	base-base/crates/builder + Flashblocks
フォールトプルーフ VM	Cannon (MIPS)	Cannon (互換) + Kona (Rust) + Succinct (ZK) 三系統並列
Sequencer サブブロック	なし	Flashblocks 200ms（base-base/crates/execution/flashblocks）
Fee 分配コントラクト	なし（chain operator 自己処理）	FeeDisburser.sol（24h disbursement）
クロスエコシステムブリッジ	なし	base/bridge → Solana（初の非 EVM 目標）
Smart Account	公式実装なし	coinbase/smart-wallet（ERC-4337 + passkey + 8453 クロスチェーン nonce key）
Identity	なし	basenames（ENS on Base）
Multicall	サードパーティ multicall3 経由	CBMulticall（Base 自社開発、独立コントラクト）
ガバナンス	shared Superchain config	Base-owned config（2026-02-19 以降）

10. 検証 / 再現説明

この分析を再現したい研究者は以下を実行できる：

# 重要：時間を節約するため、適切な深さのバージョンのみクローン
git clone https://github.com/base/base.git           # Rust impl、65MB
git clone https://github.com/base/contracts.git       # Solidity コントラクト、30MB
git clone https://github.com/base/contract-deployments.git  # アップグレード履歴、22MB
git clone https://github.com/base/bridge.git          # Solana ブリッジ
git clone https://github.com/coinbase/smart-wallet.git
git clone --depth 50 https://github.com/ethereum-optimism/optimism.git  # 参照

# 重要ファイルの cherrypick
cat base/contracts/src/L2/FeeDisburser.sol            # 158 行、分配コントラクト
cat coinbase/smart-wallet/src/CoinbaseSmartWallet.sol # 358 行、メインウォレット
cat base/base/docs/specs/pages/protocol/overview.md   # プロトコル概要
ls base/contract-deployments/mainnet/                  # 100+ アップグレード task タイムライン

11. 既知のギャップ（[要確認] とマーク）

Base の Q1-Q4 2024 + 2025 各四半期の Coinbase への沈下純利益 vs OP Collective への分配の具体的なドル額 —— 決算口径では Base 収益は “other transaction revenue” に混ざり、単独開示されていない。[要確認 Coinbase IR 各回の電話会議記録]
2026-02-19 Superchain Separation 後の Base と OP の関係が完全に切り離されているか —— TerminateSmartEscrow は OP token grant を終了したが、SystemConfig には Superchain 関連フックが残存する可能性がある。[要確認]
base/base Rust 実装 vs 現行 Go ノード —— Rust 実装が本番 sequencer として使用されているか、それとも依然として testnet/devnet 段階にあるか。[要確認]
Security Council 10 個の独立エンティティの具体的なリスト —— 公式ドキュメントは言及するも具体名は未掲載。[要確認]
Coinbase Smart Wallet の実際の MAU：検索結果では EVM チェーン上 ~62M smart accounts のうち Coinbase Smart Wallet と Safe が先行していると言及するが、Coinbase 自社データは細分化されていない。[要確認]