Base 代码层深度分析

调研时点：2026-05-13
分析方法：从已克隆代码、deployment task 历史、官方 spec 三个维度交叉验证

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 不是”一个仓库一个 L2”——Base 是三层架构

读完所有仓库后，最关键的结构性发现是：截至 2026-05，Base 处于一个从 OP Stack 派生层往独立 Rust 实现层迁移的过渡期。三层并行存在：

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 在治理 / 升级权限上脱离 shared 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 行)  Fault Proof 版主桥
│   ├── 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/                    Fault Proof 系统
├── 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 小时（不可低于）—— 一天一次结算节奏
- 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 三个 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 上的费用打包桥接到一个 L1 钱包
2. 真正的”15% net profit / 2.5% gross revenue”分账逻辑发生在 L1 SmartEscrow 合约（见 §6.2）
3. 这个简洁性使得 FeeDisburser 合约升级很罕见，2023-08-28 部署后仅 2026-03-11 一次 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 上游的 Fault Proof 版主桥。值得记录的是其继承结构：

// OptimismPortal2.sol:36
contract OptimismPortal2 is
    Initializable,
    ResourceMetering,        // 1559-like 资源计量
    ReinitializableBase,     // 可重初始化（升级路径）
    ProxyAdminOwnedBase,     // ProxyAdmin owner 检查
    ISemver
{
    struct ProvenWithdrawal {
        IDisputeGame disputeGameProxy;  // Fault Proof 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 同时挑战，避免单个恶意 proof 卡死整个 withdrawal 通道。

2.3 ETHLockbox.sol —— Superchain 分离后的 ETH 集中存储

路径：base-contracts/src/L1/ETHLockbox.sol（10 KB）

这个合约是 OP Stack U16 升级（”Interop”）后引入的。在 Superchain 多链环境下，需要把所有链的 L1 ETH 集中到一个 lockbox 里，以支持原生 ETH 互操作。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 调整都是通过 multisig 调这里。

部署历史可以反推出 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 几乎每月一次。这是 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        ← Fault proof challenger
│   ├── consensus         ← Consensus 节点
│   ├── node              ← 全节点
│   ├── proposer          ← Output 提议者
│   ├── prover            ← Fault proof 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 已 locked）。

3.4 succinct ZK Prover 子 crate

来源：base-base/crates/proof/succinct/

这是 Base 集成 Succinct (SP1) ZK prover 的代码模块。意味着 Base 在 Cannon (FPVM) 之外，并行开发 ZK 故障证明路径。结合 Upgrade 18 的 “cannon+kona” 说法，Base 正在做 multi-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 是 reth 不是 geth，进一步印证。

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 的索引
        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 位 —— 当用户在 Base 上 sign 一笔 “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 在多链上 keep 同步 owner / config 不需要用户每条链都签一次。

4.3 双因子签名：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 结构

为什么用 ownerIndex 而不是直接传 public key？

“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 多设备同步场景（手机/电脑/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 两步式（类似 OP Portal 的 withdrawal 流程）
- ~15 分钟延迟 = root 在 Solana 端 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 — 给安全委员会加 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 把”嵌套 multisig”扁平化成”3-of-N EOA 直签”。这是治理简化（少一层嵌套，决策更快）但同时也是集中度上升（嵌套结构里 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 那两个 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 hardfork（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 / 安全委员会

2025-04 大约                               Stage 1 决战（Fault Proof 上线 + Security Council）
2025-07 大约                               Flashblocks 主网上线
2025-08-06                                Sequencer handoff 33-min 宕机
2025-08-13-safe-swap-owner                ← multisig 治理调整
2025-10-06-funding
2025-10-07-upgrade-to-U16a                ← U16 alpha
2025-10-20-incident-multisig-signers      ← incident 后调整 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 Fault Proof, 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
Fault Proof 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 个独立实体的具体名单 —— 官方 docs 提及但未列名。[需进一步确认]
Coinbase Smart Wallet 实际 MAU：搜索结果提到 EVM 链上 ~62M smart accounts 中 Coinbase Smart Wallet 与 Safe 领先，但未细分 Coinbase 自家数据。[需进一步确认]