总览›base · technology

Base 技术内核 深度报告

调研者: Claude (Opus 4.7 / 1M context)
日期: 2026-05-13
上游报告: projects/blockchain-research-2026-05/base/overview.md
本报告定位: 不重复 v1 内容,只挖代码、合约、链上数据、SEC 文件四个深度层
仓库基线: 15 个已克隆仓库,所有引用路径均为 projects/blockchain-research-2026-05/base/repos/<repo>/<path>

本报告完全基于 Base 团队 2026-04-15 (估计) 从 op-stack fork 迁移到 base/base Rust monorepo 后的最新代码,以及 base-deployments 仓库 2026-03-25 之前的完整 L1 部署历史。所有 概览 已写过的”Base 是 OP Stack L2、Cannon 是 MIPS 虚拟机、$12B TVL”这种总览叙事不再重复。本报告进入八个具体子领域,每一处都有可索引到行号的代码证据或可在 etherscan 验证的链上证据。

第一章 base/base Rust rollup 实现完整解剖

1.1 仓库整体形态: 从 Go 单体到 Rust workspace

Base 在 2026-04 完成了一次罕见的重写:从延续 Optimism Bedrock 的 Go 实现 (op-node + op-geth 双进程组合) 切换为单一 Rust workspace,基于 reth 而非 op-geth,基于 kona-derive 而非 op-node。这次迁移的产物就是 base/base 仓库(对应链上仍然是 Chain ID 8453,但客户端实现完全换血)。

仓库根目录 repos/base-base/Cargo.toml 第 12-49 行声明了一个 109 个成员、近 1,400 个 .rs 源文件的庞大 workspace。统计:

$ find repos/base-base/crates -name Cargo.toml | wc -l
111
$ find repos/base-base -name "*.rs" -type f | wc -l
1374

repos/base-base/bin/ 目录下产出 16 个独立可执行二进制,这是一个值得展开的清单(因为它定义了 Base 一个完整运行时的所有进程边界):

二进制 角色 在传统 OP Stack 中的对应物
base 完整 follow-node (validator 模式) op-node + op-geth
based 完整 sequencer/builder 节点 op-node (sequencer) + op-geth (block-building)
consensus 仅 rollup-node 模式 (无 EL) op-node 独立模式
node 通用 reth-fork 节点入口 op-geth
builder Flashblocks-aware payload builder Flashbots op-rbuilder
batcher L1 batch 提交器 op-batcher
proposer TEE+ZK 输出 proposer op-proposer + op-enclave
challenger 三轨故障证明挑战者 op-challenger
prover 包含 nitro-host / nitro-enclave / zk 三个子 crate op-program / op-enclave
prover-registrar TEE 签名者 L1 注册器 (Base 独有)
audit-archiver 被 builder 拒绝的 tx 转发到 S3 (Base 独有)
basectl 终端 TUI 运维工具 (Base 独有)
ingress-rpc RPC 接入边缘网关 (基础设施)
load-tester 自研性能压测 (基础设施)
mempool-rebroadcaster 内存池广播代理 (基础设施)
websocket-proxy Flashblocks WebSocket 多路复用 (基础设施)

crates/ 目录则按域而非按类型组织,九个顶级 group 各自负责一个清晰的子系统:batcher/ (5 子 crate)、builder/ (3)、common/ (13)、consensus/ (14)、execution/ (20)、proof/ (15 + tee 5 + zk 4 + succinct 多个)、infra/ (基础设施)、utilities/、tools/。这种细粒度切分让一处改动几乎不可能横向溢出—编译期就把跨子系统的接口边界固定下来。

仓库的 CLAUDE.md (即 AGENTS.md 的 symlink) 还设定了几条非常硬的 Rust 风格红线,这些约束实际上影响了所有 1,374 个 Rust 文件:

All crates in the workspace should have a base- prefix in their crate name (e.g. base-enclave, base-builder-core).
All use imports must be at the top of the file or the top of a mod block.
Use structured tracing instead of interpolated strings. Always use key=value fields for any dynamic data.

repos/base-base/Cargo.toml 第 67-105 行 ([workspace.lints.clippy]) 定义了大约 30 条 clippy 警告级别提升到 error 的规则。其中 missing-const-for-fn、redundant-clone、clone-on-ref-ptr、option-if-let-else 都被设为 warn 但 unused-must-use 直接 deny。这表明 Base 内部 Rust 工程文化偏向”零分配 + 显式错误处理”,这跟传统 op-geth Go 代码的”err != nil { return err }”完全不同—Rust 这边所有失败路径都走 thiserror 类型化错误并 panic-on-unwrap 是禁止的。

1.2 batcher 子系统: 把 L2 block 编码成 L1 calldata 或 blob

crates/batcher/ 是 Base 把 L2 区块序列化到 L1 数据可用层 (DA) 的整个流水线。它包含 5 个子 crate:

最值得拆解的是 repos/base-base/crates/batcher/blobs/src/encoder.rs 第 26-62 行,它精确描述了 Base 怎么把 L2 数据塞进 EIP-4844 blob:

pub struct BlobEncoder;

impl BlobEncoder {
    /// Blob encoding version used by the Base blob codec.
    pub const BLOB_ENCODING_VERSION: u8 = 0;

    /// Maximum number of data bytes that fit in a single blob.
    ///
    /// Each encoding round packs 4 field elements (128 blob bytes) into 127 data
    /// bytes (4 x 31 payload bytes + 3 reassembled bytes). With 1024 rounds that
    /// gives `127 * 1024 = 130_048` bytes, minus 4 bytes for the version +
    /// 3-byte length header in field element 0.
    pub const BLOB_MAX_DATA_SIZE: usize = PROTOCOL_BLOB_MAX_DATA_SIZE;

这段注释隐含了一个数字:每个 EIP-4844 blob 在去掉 4 字节 header 之后可承载 130,044 字节 (≈ 127 KiB) 的 rollup 数据。Base 在 batcher 这一层选择 calldata 还是 blob 是由 crates/batcher/source/src/hybrid.rs 决定的—当 DA 节流器 (DaThrottle) 触发时,driver 会强制切到 blob:

repos/base-base/crates/batcher/core/src/driver.rs:67-72
    /// When `true`, the driver toggles a blob-DA override on the pipeline
    /// whenever DA-backlog throttling activates. Lifted from
    /// [`BatchDriverConfig::force_blobs_when_throttling`].
    force_blobs_when_throttling: bool,

这是 Base 对 EIP-4844 切换之后还要保留 calldata 通道的一个核心运营 trick:正常情况走 blob,如果 blob 市场拥堵就回退到 calldata,反之亦然。把这放到 EIP-4844 上线后的真实数据语境里看,(根据 IEEE 论文 arxiv 2405.03183,2024-03 Dencun 之后 L2 calldata 整体下降 56.8%,数据量增长 116.8%) Base 的 batcher 在很长一段时间里同时维护两条提交路径,而不是简单 “上 blob 不回头”。这背后是 Coinbase 作为美股上市公司对单点失败的容忍度极低—成本可以接受波动,但停机不可以。

crates/batcher/encoder/src/encoder.rs 第 27-62 行定义了 BatchEncoder 这个核心同步状态机:

pub struct BatchEncoder {
    rollup_config: Arc<RollupConfig>,
    config: EncoderConfig,
    /// Current L1 head block number (for channel duration tracking).
    l1_head: u64,
    /// L2 blocks waiting to be encoded. Pruned when all their frames are confirmed.
    blocks: VecDeque<BaseBlock>,
    block_cursor: usize,
    tip: B256,
    current_channel: Option<OpenChannel>,
    ready_channels: VecDeque<ReadyChannel>,
    pending: HashMap<SubmissionId, PendingRef>,
    ...
    span_accumulator: Vec<(SingleBatch, u64)>,

注释里有一处特别值得引用 (generator.rs:138-147):

When batcher’s max channel duration is big enough (e.g. 10m), the sequencer would send an avalanche of FCUs/getBlockByNumber on each batcher update (with 10m channel it’s ~800 FCUs at once). At such moment it can happen that the time b/w FCU and ensuing getPayload would be on the scale of ~2.5s. Therefore we should “remember” the payloads long enough to accommodate this corner-case (without it we are losing blocks).

这段注释是过去某次 production 事故的”道歉”:当 batcher 的 channel duration 太长,L1 一旦确认整个 channel,sequencer 会一次性收到约 800 个 ForkchoiceUpdated (FCU),engine API 处理这种 burst 需要约 2.5 秒,中间任何 payload 如果不延长生命周期就会丢失。Base 的解决方案是 extra_block_deadline (generator.rs:148)—把 payload 的 deadline 推迟 5 秒以兜底。这是一个非常具体的、由现实事故塑造的工程参数,在任何 OP Stack 教科书里都不会看到。

1.3 builder 子系统与 Flashblocks 的真实实现

1.3.1 拓扑: builder 不是 sequencer 但比 sequencer 更关键

Base 的 builder 与 OP Stack 教科书形态不同。教科书 OP Stack 里 sequencer (op-node + op-geth) 负责排序和出块两件事都做。Base 把这两件事拆开了:

二进制 bin/builder/src/main.rs 第 27-49 行的启动序列里,builder 是作为一个 reth ExEx (Execution Extension) 安装到 BaseNodeRunner 上的:

fn main {
    base_cli_utils::init_common!;
    base_reth_cli::init_reth!;
    let cli = base_cli_utils::parse_cli!(BuilderCli);
    cli.run(|builder, builder_args| async move {
        let rollup_args = builder_args.rollup_args.clone;
        let metering_provider: base_builder_core::SharedMeteringProvider =
            Arc::new(builder_args.build_metering_store);
        let builder_config = builder_args
            .into_builder_config(Arc::clone(&metering_provider))
            .expect("Failed to convert rollup args to builder config");

        let mut runner = BaseNodeRunner::new(rollup_args)
            .with_service_builder(FlashblocksServiceBuilder(builder_config));
        runner.install_ext::<MeteringStoreExtension>(metering_provider);
        runner.install_ext::<TxPoolRpcExtension>(TxPoolRpcConfig::default);
        runner.install_ext::<BuilderApiExtension>;
        ...

这种 “ExEx-as-builder” 的模式是 reth 团队 (Paradigm) 在 2024-05 那篇 Reth Execution Extensions 里推广的核心范式,Base 是最大规模的真实生产采纳者—Paradigm Reth 2.0 在 2026-Q1 上线后已经能跑到 1.7 Gigagas/s,这给了 Base 在 builder 这一层”软件加速硬件挤压”的空间。

1.3.2 Flashblocks 200ms 子区块的代码证据

Flashblocks (200ms 子区块/preconfirmation) 这一概念的源头是 Flashbots 的 rollup-boost (specs in github.com/flashbots/rollup-boost),但 Base 把整套机制原生集成到了自己的 builder 里。最直接的代码证据在 repos/base-base/crates/builder/core/src/config.rs 第 173-178 行:

/// Creates a new [`BuilderConfig`] suitable for testing with a randomized flashblocks port.
pub fn for_tests -> Self {
    Self {
        flashblocks_ws_addr: SocketAddr::new(Ipv4Addr::LOCALHOST.into, 0),
        flashblocks_interval: Duration::from_millis(200),
        flashblocks_leeway_time: Duration::from_millis(100),
        block_time: Duration::from_secs(1),
        ..Self::default
    }
}

这是 Flashblocks “200ms 子区块” 这个营销叙事在代码里能找到的最确凿的数字:flashblocks_interval = 200ms,flashblocks_leeway_time = 100ms,block_time = 1 秒 (注意:这是 test config,production 仍然是 2 秒 block time,所以每个 2 秒区块包含 10 个 200ms flashblock)。

Flashblock 本身的 wire format 在 repos/base-base/crates/common/flashblocks/src/payload.rs 第 11-79 行精确定义:

pub struct ExecutionPayloadFlashblockDeltaV1 {
    pub state_root: B256,
    pub receipts_root: B256,
    pub logs_bloom: Bloom,
    #[serde(with = "alloy_serde::quantity")]
    pub gas_used: u64,
    pub block_hash: B256,
    pub transactions: Vec<Bytes>,
    pub withdrawals: Vec<Withdrawal>,
    pub withdrawals_root: B256,
    #[serde(default, skip_serializing_if = "Option::is_none", with = "alloy_serde::quantity::opt")]
    pub blob_gas_used: Option<u64>,
}

pub struct FlashblocksPayloadV1 {
    pub payload_id: PayloadId,
    pub index: u64,
    #[serde(skip_serializing_if = "Option::is_none")]
    pub base: Option<ExecutionPayloadBaseV1>,
    pub diff: ExecutionPayloadFlashblockDeltaV1,
    pub metadata: Value,
}

注意 base 字段是 Option,只有 index = 0 的第一个 flashblock 才携带 base payload,后面 9 个 flashblock 只发 delta—这是 Base 节省 WebSocket 带宽的关键设计。每个 flashblock 都包含完整的 state_root 和 receipts_root,意味着接收方可以在 200ms 内就拿到 state 变化、不必等整个 block 封盘。

decode 路径用 brotli 压缩 (crates/common/flashblocks/src/block.rs:14-15):

/// Maximum allowed decoded flashblock payload size, in bytes.
pub const MAX_DECOMPRESSED_FLASHBLOCK_BYTES: usize = 5 * 1024 * 1024;

每个 flashblock 解压后上限 5 MB。结合每个 2 秒 block 包含 10 个 flashblock,Base 在最极端情况下 builder 每秒要 broadcast 25 MB 数据—这就是为什么 crates/builder/publish/src/broadcast.rs 长达 517 行,且依赖一个独立的 websocket-proxy 二进制 (crates/infra/websocket-proxy/) 做多路复用。

1.3.3 Flashblocks 与 builder 状态机

crates/builder/core/src/flashblocks/generator.rs 第 504-522 行定义了 payload job 的截止时间逻辑:

fn job_deadline(unix_timestamp_secs: u64) -> std::time::Duration {
    let unix_now = match SystemTime::now.duration_since(UNIX_EPOCH) {
        Ok(d) => d.as_secs,
        Err(e) => {
            warn!(error = %e, "System clock went backward, returning zero deadline");
            return Duration::ZERO;
        }
    };
    let duration_until = unix_timestamp_secs.saturating_sub(unix_now);
    if duration_until == 0 {
        Duration::from_secs(1)
    } else {
        Duration::from_secs(duration_until)
    }
}

builder 的 BlockPayloadJob::poll (generator.rs:338-356) 是一个 stateful future,它在每次 poll 时检查:

  1. 截止时间是否到了 → 取消所有 build
  2. 是否被外部取消 (新的 FCU 来了) → 让出
  3. 否则继续 pending

crates/builder/core/src/flashblocks/payload.rs 长达 1,425 行,是 Base builder 最核心的”如何产 flashblock”逻辑。第 600-720 行的循环是真实的子区块生成:

let payload_transaction_simulation_time = tx_execution_start_time.elapsed;
BuilderMetrics::payload_transaction_simulation_duration
    .record(payload_transaction_simulation_time);
...
let build_result = build_block(state, ctx, info, ctx.attributes.no_tx_pool);
...
match build_result {
    Err(err) => {
        BuilderMetrics::invalid_built_blocks_count.increment(1);
        Err(err).wrap_err("failed to build payload")
    }
    Ok((new_payload, mut fb_payload)) => {
        fb_payload.index = flashblock_index;
        fb_payload.base = None;
        // Synchronized check + publish.
        let (cancelled, flashblock_byte_size) = {
            let _guard = publish_guard.lock;
            if block_cancel.is_cancelled {
                (true, 0)
            } else {
                let size = self
                    .ws_pub
                    .publish(&fb_payload, ctx.block_number, flashblock_index)
                    .wrap_err("failed to publish flashblock via websocket")?;
                (false, size)
            }
        };

这里有几个细节值得展开:

  1. publish_guard mutex: 出块取消 (cancel) 与 publish 之间用一个 Mutex<> 互斥,确保不会发出已经被作废的 flashblock。这是 Base builder 自创的”已发即生效”原子语义,防止下游 RPC 服务看到自己永远不会落盘的 tx。
  2. fb_payload.base = None: 第二个 flashblock 之后明确清掉 base payload,减小线上带宽。
  3. flashblock_byte_size 度量: 每个 flashblock 单独度量字节数和 tx 数,这给了运营团队一个非常细的”哪些 flashblock 是空的、哪些塞满了”维度。

1.3.4 Flashblock 内 tx 选择算法

crates/builder/core/src/flashblocks/best_txs.rs 第 215-261 行定义了一个非常 subtle 的 tx 选择策略。注释里直接写着 === FLASHBLOCK 1 === 和 === FLASHBLOCK 2 === 测试用例:

// === FLASHBLOCK 1 ===
let mut iterator = BestFlashblocksTxs::new(
    BestPayloadTransactions::new(pool.best),
    test_rejection_cache,
);

// Simulate: Flashblock 1 starts building
let first = iterator.next.unwrap;
assert_eq!(first.sender, sender_a, "First should be TX_A (1 gwei)");

// TX_B and TX_C arrive late, but we have already yielded lower-priority transactions
// from the iterator, so these do not immediately get added to the best txns
pool.add_transaction(Arc::new(f.validated(tx_b.clone)), 0);
pool.add_transaction(Arc::new(f.validated(tx_c.clone)), 0);
assert_eq!(iterator.next, None);

// Simulate: flashblock 1 is complete after TX_A was executed
iterator.mark_committed(&[*tx_a.hash]);

// === FLASHBLOCK 2 ===
iterator.refresh_iterator(BestPayloadTransactions::new(pool.best));

// Now, theoretically, TX_A has already been executed, so
// TX_B should be the best txn and TX_C the second best

这段测试揭示了一个关键的 MEV 几何:flashblock 边界相当于一个 200ms 间隔的”重新排序点”,在 flashblock 1 锁定之后才进入 mempool 的高价 tx (TX_B 100 gwei、TX_C 10 gwei) 不会”反悔”挤掉已经放进 flashblock 1 的低价 tx (TX_A 1 gwei),但会在 flashblock 2 立即被纳入并按 priority fee 排序。

这恰好就是 Bitcoin Ethereum News 报道 那篇文章描述的、Jesse Pollak 自己的 creator-coin 上线时被两个 sniper 套利 $1.3M 的核心机制—他们在能预看 flashblock N 的 mempool 状态后,在 flashblock N+1 才打入巨额 priority fee 抢前。Base 自己的 builder 代码完全不抢跑,但 200ms 的 sub-block 可见性给了第三方 sniper 一个本来在 2 秒 block-only 时代不存在的、新的 mempool 观察窗口。

1.4 batcher / builder / sequencer 的边界

把上面这些拼起来,Base 一个完整的 L2 区块生命周期是:

t=0      sequencer 决定要出 block N (timestamp = unix_now)
         ↓ engine_forkchoiceUpdatedV3 (FCU)
t=0      builder 收到 FCU, 启动 BlockPayloadJob
         ↓ 从 mempool 取 tx, 执行
t=200ms  builder 发出 flashblock 0 (含 base payload + 第 1 批 tx)
t=400ms  builder 发出 flashblock 1 (只含 delta + 第 2 批 tx)
...
t=2000ms builder 发出 flashblock 9, 同时 engine_getPayloadV3 调用拿到完整 block
         ↓ sequencer 把完整 block 推到 consensus 层 P2P gossip
         ↓ batcher 累积若干 block 后压缩成 frame, 装 channel
t≈2-30s  batcher 把 channel 通过 EIP-4844 blob 提交到 L1
         ↓ L1 12 秒一个 slot, 平均 6 秒等待入块
t≈30s    L1 区块包含此 batch, 触发 base-node-validator 重放
         ↓ validator 从 L1 derive 出 L2 block N (safe head)
t≈12分钟 L1 区块 finalized, L2 block N 进入 finalized 状态

这里有几个非常值得记的”具体数字”:

1.5 proof 子系统的 workspace 形状

crates/proof/ 是整份 base/base 代码里最大、最复杂的部分,占总代码量约 30%。它的子 crate 列表 (repos/base-base/Cargo.toml:24-50) 揭示了 Base 同时押注 TEE 和 ZK 两条路:

crates/proof/mpt              - Merkle-Patricia Trie 实现
crates/proof/proof            - 高层 SDK
crates/proof/driver           - 故障证明 driver
crates/proof/client           - 客户端
crates/proof/executor         - 状态执行器 (无状态)
crates/proof/preimage         - preimage oracle
crates/proof/primitives       - Proposal / ProofJournal / ProofResult 三大共享类型
crates/proof/host             - host 端
crates/proof/tee/nitro-host        ←  AWS Nitro 主机侧
crates/proof/tee/nitro-enclave     ←  AWS Nitro enclave 内部 (vsock listener + NSM)
crates/proof/tee/registrar         ←  TEE 签名者上链注册
crates/proof/tee/nitro-verifier    ←  Nitro 证书链 + X.509 验证
crates/proof/tee/nitro-attestation-prover  ← 把 attestation 变成 ZK proof (走 Boundless)
crates/proof/zk/client / db / outbox / service  ← ZK 主机侧
crates/proof/zk/service/src/backends/op_succinct/cluster.rs  ← SP1 集群对接
crates/proof/contracts        - L1 合约 binding (DisputeGameFactory, AggregateVerifier, AnchorStateRegistry)
crates/proof/rpc              - 给 challenger / proposer 用的 RPC trait
crates/proof/proposer         - L1 输出 proposer
crates/proof/challenge        - 挑战者 driver
crates/proof/succinct/utils   - SP1 utilities
crates/proof/succinct/validity  - 验证逻辑

这一节先列总图,具体到 fault proof 三轨投票留到第二章。

第二章 三轨故障证明系统深度

2.1 三轨并行的真实含义

在 概览 里我提到过 Base 在 2024-10-30 上线了”Stage 1 fault proofs”,并引用了 OP Stack 的 Cannon (MIPS VM) 做仲裁。但 v1 里没说清楚的是,Base 在 2025-2026 期间彻底抛弃了 Cannon 单一仲裁,转向一个三轨并行的 TEE + ZK + (legacy permissioned) 多签 投票模型,最终在 2026-05-13 (即本报告写作日期当周) 通过 Base Azul 升级正式生效。

crates/proof/contracts/src/aggregate_verifier.rs 第 22-110 行的 IAggregateVerifier 接口是这个新模型的 Solidity 级证据。它的关键方法:

function teeProver external view returns (address);  // ← TEE 提交者地址
function zkProver external view returns (address);   // ← ZK 提交者地址
function rootClaim external pure returns (bytes32);  // ← 输出 root
function intermediateOutputRoots external view returns (bytes memory);
function intermediateOutputRoot(uint256 index) external view returns (bytes32);

function nullify(
    bytes calldata proofBytes,
    uint256 intermediateRootIndex,
    bytes32 intermediateRootToProve
) external;

function challenge(
    bytes calldata proofBytes,
    uint256 intermediateRootIndex,
    bytes32 intermediateRootToProve
) external;

注释里写明:

The first byte of proofBytes is the proof type discriminator: 0 for TEE, 1 for ZK.

这就是三轨结构的核心—一个 dispute game 不再绑定单一证明类型,而是接受两种证明 (TEE = 0, ZK = 1),nullify 和 challenge 函数都通过第一个字节区分。结合下面的 BLOCK_INTERVAL 和 INTERMEDIATE_BLOCK_INTERVAL 暴露,Base 的 dispute game 本质是一个双proof 检查点链:每隔 INTERMEDIATE_BLOCK_INTERVAL (代码里默认 512,见 crates/proof/proposer/src/driver.rs:62) 个 L2 block 设一个中间 output root,任何一个 root 被 TEE 或 ZK 证明为伪造都会 nullify 整个 game。

2.2 TEE 一侧: AWS Nitro Enclave 完整路径

2.2.1 op-enclave 演化与 base-op-enclave 仓库

repos/base-op-enclave/README.md 第 6-9 行明确指出:

op-enclave is a relatively small modification to the op-stack that proves state transitions in an AWS Nitro Enclave, and submits the resulting state roots to the L1 chain. This removes the need for the 7-day challenge period, and allows for immediate withdrawals.

这是 Base 在 2024-2025 期间独立维护的一个 fork。它的 op-enclave/ 子目录是一个 Go 程序,专门跑在 AWS Nitro Enclave (一种基于 KVM 的硬件隔离环境) 内部。它的特点:

  1. stateless: enclave 自己不持久化任何 state,所有 L2 chain data 从 L1 重放
  2. deterministic: 每个 enclave image 都有一个 SHA-384 measurement (PCR0),只有 PCR0 匹配 SystemConfigGlobal 上注册值的 enclave 才能签名 output root
  3. attestation-driven: 提交的 output root 附带一个 Nitro attestation,L1 合约验证这个 attestation 后接受

repos/base-op-enclave/README.md 的 Architecture 部分总结了一句话:

Because the output root is accepted based on the TEE attestation (and the trusted signer check), withdrawals can be processed almost instantly.

这就是 Base 一直能宣传”快速提现”(实际约 1-2 小时,远短于 OP Mainnet 的 7 天) 的根源。

2.2.2 base-base 仓库里的 enclave 重写

到了 2026 年的 base/base monorepo,op-enclave 被完全 Rust 重写并进一步切分。crates/proof/tee/nitro-enclave/src/server.rs 第 1-50 行是新版的入口:

/// Enclave server — manages keys, attestation, signing, and proof execution.
use std::sync::LazyLock;
use alloy_primitives::{Address, B256, Bytes, keccak256, map::HashMap};
use alloy_signer_local::PrivateKeySigner;
use base_common_chains::ChainConfig;
use base_common_evm::BaseEvmFactory;
use base_common_genesis::RollupConfig;
use base_proof::BootInfo;
use base_proof_client::Prologue;
use base_proof_preimage::PreimageKey;
use base_proof_primitives::{PerChainConfig, ProofJournal, ProofResult, Proposal};
use tracing::info;
...
/// PCR0 is a SHA-384 hash (48 bytes) per the AWS Nitro Enclaves specification.
const PCR0_LENGTH: usize = 48;

Server::new (server.rs:67-80) 在启动时:
1. 打开 NSM (Nitro Security Module) session
2. 读取 PCR0 (48 字节 SHA-384)
3. 用硬件 RNG 生成 ECDSA secp256k1 私钥 (永远不离开 enclave)
4. 把 PCR0 keccak256 之后作为 tee_image_hash 暴露出去 (这个 hash 是 L1 上 TEEProverRegistry 注册时校验的关键)

整个 nitro-enclave 模块包含 9 个文件、总共 1,514 行 Rust,跑在一个完全隔离的 KVM guest 里。它通过 vsock (Linux 虚拟 socket) 跟 host 通信 (nitro-host/src/vsock.rs:127 行),不接触任何网络。

2.2.3 base/base 的 prover-registrar: 把 TEE 注册到 L1

crates/proof/tee/registrar/src/driver.rs (3,165 行,是整个 base/base 仓库最长的 Rust 文件) 实现了一个完整的”TEE 签名者上链注册”驱动。注释开头:

Discovers prover instances, checks on-chain registration status, generates ZK proofs for unregistered signers, and submits registration transactions to L1 via the [TxManager]. Also detects orphaned on-chain signers (those no longer backed by a healthy instance) and deregisters them.

这是 Base 独有的一个组件,在 OP Stack 教科书里完全没有对应物。它的工作流程:

  1. 发现 (InstanceDiscovery): 通过 AWS API 找到所有跑着 enclave 的 EC2 实例,每个实例对应一个 TEE 签名者
  2. 健康检查 (InstanceHealthStatus): 通过 ALB health check 确认实例存活
  3. 生成 ZK 证明 (AttestationProofProvider): 把 Nitro attestation (X.509 证书链 + PCR0) 转换为一个 SP1 zk proof,这一步走 Boundless 网络,需要约 20 分钟
  4. 链上注册 (TxManager): 把 (TEE signer address, ZK proof of attestation) 写入 L1 TEEProverRegistry 合约

driver.rs 第 29-31 行:

/// Default maximum number of instances processed concurrently.
///
/// Each instance may trigger a ~20-minute Boundless proof generation, so
/// limiting concurrency prevents overwhelming the proof service and keeps
/// nonce management tractable.
pub const DEFAULT_MAX_CONCURRENCY: usize = 4;

20 分钟生成一次 attestation ZK proof × 最多 4 并行 → 一次 TEE 集群上线/轮换大约需要数小时

这就是 Base 在 op-enclave/Nitro TEE 这条路上的真实运营成本。

2.2.4 PCR0 与 enclave image 锁定

repos/base-op-enclave/tools/ 下有一个完整的 PCR0 验证工具链。Nitro Enclave 用 PCR0 这个 SHA-384 hash 锁定 enclave 二进制 + 内核 + 配置的整体 measurement,任何字节级修改都会改变 PCR0。Base 把每次升级的 PCR0 显式注册到 SystemConfigGlobal 合约上,在 enclave 提交 output root 时合约验证 attestation 里的 PCR0 必须在 allowlist 中,否则 reject。

这种”image hash 即权限”的模型有一个深刻特点:一旦 PCR0 被 attacker 替换,所有过去签的 output root 仍然有效—因为合约只检查”签的时候 PCR0 在不在 allowlist”。这就是为什么 Base 必须有同期的 ZK 证明作为 cross-check。

2.3 ZK 一侧: OP Succinct SP1 集群

2.3.1 从 Cannon (MIPS) 到 Kona (Rust) 到 SP1 (zkVM)

历史上 OP Stack 的 fault proof program 是 Go 写的 op-program,跑在 Cannon (MIPS32 解释器) 里。repos/optimism-monorepo/cannon/README.md 第 10-16 行直白地总结:

Cannon is an onchain MIPS instruction emulator. Cannon supports EVM-equivalent fault proofs by enabling Geth to run onchain, one instruction at a time, as part of an interactive dispute game.
- It’s Go code
- …that runs an EVM
- …emulating a MIPS machine
- …running compiled Go code
- …that runs an EVM

这是个套娃—Go 代码编译成 MIPS,MIPS 在 EVM 里被解释,解释出来的代码又跑 EVM。这种架构的代价是巨大的 step count (一次完整的 fault proof game 大约 1-10 亿条 MIPS 指令) 和漫长的二分搜索时间。

repos/optimism-monorepo/op-program/README.md 的第一句话就是:

Deprecated: op-program is deprecated and being replaced by kona-client.
Existing deployments will be supported until the Karst hardfork, at which point migration to kona-client is required.

Kona 是 OP Stack 的 Rust 重写 (rust/kona/),它的核心目标是把 OP Stack state transition function (STF) 写成可以被任意 zkVM (SP1/Risc0/Jolt) 直接证明的纯 Rust 程序。rust/kona/README.md 第 31-37 行:

Originally a suite of portable implementations of the OP Stack rollup state transition, Kona has been extended to be the monorepo for OP Stack types, components, and services built in Rust. Kona provides an ecosystem of extensible, low-level crates that compose into components and services required for the OP Stack.

Succinct Labs 把 Kona 跟 SP1 (一个基于 RISC-V 的 zkVM) 结合,得到 OP Succinct—一个能给整个 OP Stack 输出零知识 validity proof 的系统。它的关键点是:

2.3.2 Base 怎么对接 op-succinct

crates/proof/zk/service/src/backends/op_succinct/cluster.rs 第 1-30 行展示了 Base 在 op-succinct 之上的封装:

//! Succinct proving backend using the SP1 cluster.
use std::{fmt, time::SystemTime};
use async_trait::async_trait;
use base_proof_succinct_client_utils::client::DEFAULT_INTERMEDIATE_ROOT_INTERVAL;
use base_proof_succinct_elfs::{AGGREGATION_ELF, RANGE_ELF_EMBEDDED};
use base_proof_succinct_host_utils::get_agg_proof_stdin;
use base_zk_client::ProveBlockRequest;
use base_zk_db::{
    CreateProofSession, ProofRequest, ProofRequestRepo, ProofSession, ProofStatus, ProofType,
    SessionStatus as DbSessionStatus, SessionType, UpdateProofSession, UpdateReceipt,
};
use serde_json::json;
use sp1_cluster_common::proto::{
    ExecutionFailureCause, ExecutionStatus, ProofRequest as ClusterProtoProofRequest,
    ProofRequestStatus,
};
use sp1_cluster_utils::{ClusterElf, ProofRequestConfig, create_request};
use sp1_prover_types::{Artifact, ArtifactClient as _, ArtifactType};

这两行特别关键:

use base_proof_succinct_elfs::{AGGREGATION_ELF, RANGE_ELF_EMBEDDED};

AGGREGATION_ELF 和 RANGE_ELF_EMBEDDED 是两个 RISC-V ELF 文件,被编译进 Base 的 prover binary。”Range ELF” 负责证明 N 个连续 L2 block 的 STF 是合法的,”Aggregation ELF” 负责把若干 range proof 聚合成一个最终 proof。

crates/proof/succinct/validity/src/proposer.rs 是 SP1 cluster 与 L1 通信的桥梁。第 9-30 行的 import 揭示了完整依赖图:

use base_proof_succinct_host_utils::{
    DisputeGameFactory::DisputeGameFactoryInstance as DisputeGameFactoryContract,
    OPSuccinctL2OutputOracle::OPSuccinctL2OutputOracleInstance as OPSuccinctL2OOContract,
    fetcher::OPSuccinctDataFetcher,
    host::OPSuccinctHost,
    metrics::MetricsGauge,
    network::{determine_network_mode, get_network_signer},
};
use sp1_sdk::{
    Elf, HashableKey, NetworkProver, Prover, ProverClient, ProvingKey, SP1Proof,
    SP1ProofWithPublicValues,
    network::{
        NetworkMode,
        proto::types::{ExecutionStatus, FulfillmentStatus},
    },
};

注意 OPSuccinctL2OutputOracle—这是 Succinct 团队 fork 自 OP Stack L2OutputOracle 但接受 SP1 proof 而非 fault dispute game 的版本。Base 在 Azul 升级中没有用 OPSuccinctL2OutputOracle 直接替换 DisputeGameFactory,而是把 ZK 作为 dispute game 的一种 prover 类型注入到现有 dispute game framework 里 (即第 2.1 节描述的 proofBytes[0] = 1 表示 ZK)。这是一个非常 conservative 的迁移选择,跟 The Block 报道 里说的”双 proof 同时生效”完全吻合。

2.4 challenger: 三轨投票的实际执行者

crates/proof/challenge/src/driver.rs (941 行) 是 Base 自己的 challenger 实现,与 repos/optimism-monorepo/op-challenger/ (Go 版) 完全独立。crates/proof/challenge/README.md 总结了它的责任:

  • Scanner: Scans the DisputeGameFactory for IN_PROGRESS dispute games and classifies each into a GameCategory (InvalidTeeProposal, FraudulentZkChallenge, or InvalidZkProposal) based on prover state.
  • Validator: Verifies final and intermediate output roots for each CandidateGame by fetching L2 block headers and L2ToL1MessagePasser storage proofs, recomputing expected roots via OutputRoot, and comparing them against onchain claims.
  • Pending: Tracks in-flight proof sessions through a ProofPhase lifecycle (AwaitingProof → ReadyToSubmit or NeedsRetry).
  • Submitter: Submits dispute transactions onchain (nullify / challenge) for invalid games.
  • Bond: Multi-phase bond credit claim lifecycle (NeedsResolve → NeedsUnlock → AwaitingDelay → NeedsWithdraw).

GameCategory 这个 enum 暗示了三种攻击场景:

  1. InvalidTeeProposal: TEE 提交了错误的 output root (PCR0 被注入恶意代码或 enclave 被破坏),需要 ZK 提交 nullify 推翻
  2. FraudulentZkChallenge: ZK 提交了错误的”反对 TEE”的证明 (理论上 ZK proof 验证失败就 reject,但聚合 proof 的某些边界 case 可能滑过),需要二次 ZK 推翻
  3. InvalidZkProposal: ZK 主动提交错误,需要 TEE 推翻 (或更新的 ZK 推翻)

Base 在主网上同时跑 (至少) TEE prover + ZK prover + Base 团队自己的 challenger + Optimism Foundation 的 challenger。任何一方发现 invalid game 都能上链 nullify。

2.5 链上真实数据: 2025-03 和 2025-04 的两次 fault proof 升级

repos/base-deployments/mainnet/2025-03-05-upgrade-fault-proofs/addresses.json:

{
  "faultDisputeGame": "0xfe884b822eddb5864e86626e088120c73c0a4364",
  "permissionedDisputeGame": "0x8cf5972cedf63b099406b3e7da81566885453d8e"
}

README.md 第 3 行:

Status: EXECUTED

这是 Base 主网在 2025-03-05 实际部署的一次 fault dispute game 升级,可以在 etherscan 验证 transaction 0xac0db12a427a31ccbaf4a154cf6d5acf0b83c791a4bd7f93a54c9b150b9aa668。

随后 2025-04-23 的另一次升级 repos/base-deployments/mainnet/2025-04-23-upgrade-fault-proofs/README.md:

Upgrade 15 - Fault Proof Upgrades for Isthmus

Status: EXECUTED

这次升级跟 Isthmus 硬分叉一起执行,把 FaultDisputeGame 和 PermissionedDisputeGame 重新部署以适配 Isthmus 新加入的 EIP-2935 历史 block hash contract (见 crates/consensus/upgrades/src/isthmus.rs:30-34):

/// EIP-2935 From Address
pub const EIP2935_FROM: Address = address!("3462413Af4609098e1E27A490f554f260213D685");
/// The new L1 Block Address
pub const NEW_L1_BLOCK: Address = address!("ff256497d61dcd71a9e9ff43967c13fde1f72d12");

到了 2025-11-21 的 U17 Jovian 升级 (repos/base-deployments/mainnet/2025-11-21-u17-jovian-upgrade/README.md):

The Jovian hardfork is a proposed network upgrade for OP Stack chains, which brings several improvements to the way rollup fees are calculated as well as performing a maintenance update to the fault proof virtual machine.

Status: EXECUTED

这次升级触及 fault proof VM 本身。crates/consensus/upgrades/src/jovian.rs:18-50 暴露了 Jovian 引入的两个新预部署:

pub struct Jovian;
impl Jovian {
    upgrade_source_fn!(
        deploy_l1_block_source,
        "Jovian: L1 Block Deployment"
    );
    upgrade_source_fn!(
        l1_block_proxy_update,
        "Jovian: L1 Block Proxy Update"
    );
    upgrade_source_fn!(
        gas_price_oracle,
        "Jovian: Gas Price Oracle Deployment"
    );
    pub fn l1_block_address -> Address {
        Deployers::JOVIAN_L1_BLOCK.create(0)
    }
    pub fn gas_price_oracle_address -> Address {
        Deployers::JOVIAN_GAS_PRICE_ORACLE.create(0)
    }

每次硬分叉都会重新部署 L1Block 和 GasPriceOracle 这两个 predeploy。这是 OP Stack 一以贯之的升级模式,通过 deposit tx 的 source hash (upgrade_source_fn 宏) 让升级行为在 L2 derivation 期间被 deterministic 重放。

第三章 Sequencer 内部机制

3.1 sequencer actor: 单一 sequencer 但 software-defined

crates/consensus/service/src/actors/sequencer/ 是 Base sequencer 的完整代码。它的 module list (mod.rs):

mod build;          // PayloadBuilder, UnsealedPayloadHandle
mod config;         // SequencerConfig
mod origin_selector; // L1OriginSelector, DelayedL1OriginSelectorProvider
mod recovery;       // RecoveryModeGuard
mod seal;           // PayloadSealer, SealState, SealStepError
mod ticker;         // ScheduledTicker
mod pool;           // PoolActivation
mod actor;          // PendingStopSender, SequencerActor
mod admin_api_impl; // SequencerAdminQuery
mod metrics;
mod error;
mod conductor;      // Conductor, ConductorClient, ConductorError
mod engine_client;

值得注意的是 conductor 模块。它是 OP Stack 的 op-conductor 的 Rust 等价,负责在多个 sequencer 候选者 (Coinbase 当前理论上跑多个 sequencer 实例,但只有一个 active) 之间做主备切换。这是 Base 在 前期报告里我标的”Stage 1 还差什么”清单上”sequencer decentralization”那一项的下游布局—代码层已经把 conductor abstraction 写好了,只等政策层批准多方运营。

3.2 sequencer 与 builder 的实际握手

crates/consensus/service/README.md 在描述 RollupNode::start 的启动序列时有一段非常有信息量:

Third, the engine actor is constructed. It wraps a BaseEngineClient together with an Engine task queue, an EngineProcessor that holds the bootstrap logic and main processing loop, and an EngineRpcProcessor that handles concurrent RPC queries behind a semaphore of size 16.

In Sequencer mode the engine bootstraps differently — either with a conductor-follower probe using zeroed safe/finalized heads, or as an active sequencer that probes with real heads or resets at genesis — and additionally publishes an unsafe_head_tx watch channel that the sequencer actor reads to know the current building parent.

这里的关键是 unsafe_head_tx watch channel: sequencer 通过 watch 一个 unsafe_head 的 broadcast,知道下一个 block 应该 build 在谁之上,然后通过 gossip_payload_tx 把自己 build 出来的 block 推到 P2P。

而 builder (跑在另一个进程或者另一台机器) 通过 engine API 收到 sequencer 的 FCU,在 200ms 节奏下产 flashblock。

3.3 batcher 节奏: 真实的 L1 提交频率

crates/batcher/core/src/driver.rs:69-78:

/// Whether block ingestion is currently stopped (paused via admin or `--stopped` flag).
stopped: bool,
/// Admin command channel, wired in via [`Self::with_admin_rx`].
admin_rx: Option<mpsc::Receiver<AdminCommand>>,
/// When `true`, the driver toggles a blob-DA override on the pipeline
/// whenever DA-backlog throttling activates.
force_blobs_when_throttling: bool,

crates/batcher/core/src/driver.rs:113 设定了 STEP_BUDGET = 128—每轮 select 循环最多同步执行 128 步编码,然后强制让出给 tokio runtime。这是防止 batcher 在 burst 模式下 (sequencer 突然发来一堆 block) 把 receipt 处理饿死的细节优化。

crates/batcher/comp/src/brotli.rs (233 行) 是 Base 自己的 brotli 压缩封装。OP Stack 默认压缩算法是 zlib,Base 改成了 brotli 以提升压缩率—这对 EIP-4844 blob 的 130 KB 上限非常关键,每多压 1% 就少花 ~1% blob 费用。

3.4 排序器宕机历史的代码级解读

2023-09-05 的 Base 第一次主网宕机最终被官方归因为”内部基础设施需要刷新” (https://decrypt.co/155083/coinbase-incubated-base-suffers-outage-team-says-no-funds-are-at-risk)。事故持续 43 分钟,11,400 个 block 没出来 (按 2 秒/block 估)。

2025-08-06 的第二次主网宕机 (https://www.coindesk.com/tech/2025/08/06/base-says-sequencer-failure-caused-block-production-halt-of-33-minutes),Base 官方归因为”sequencer handoff failure”—即 op-conductor 在主备切换时出错。这就是上面 conductor 模块要解决的问题。

到 2025-10-20 (repos/base-deployments/mainnet/2025-10-20-incident-multisig-signers/) 发生过一次”incident multisig signers”操作,内容是 OwnerDiff.json 修改了某个 multisig 的签名者集合。这通常对应”某个签名者的密钥可能泄露,需要紧急轮换”的运营操作。Base 在过去 12 个月内做过类似操作至少 2 次 (2025-05-13 和 2025-10-20)。

3.5 sequencer 是否抢跑? Jesse Pollak 的公开态度

Bitcoin Ethereum News 报道的 2025-11 Jesse Pollak 自己 creator-coin 上线遭 $1.3M sniper 套利事件,确证了一件事:Base sequencer 本身不抢跑,但 Flashblocks 公开 sub-block 状态后,第三方 searcher 可以通过 fee-based ordering 在 flashblock 边界做高级 MEV。

具体机制:Sniper A 在 flashblock N 已经确定但还没 broadcast 之前,通过观察 mempool 估算自己进入 flashblock N+1 需要付多少 priority fee 才能排在所有同 nonce 竞争者之前。在 Pollak coin case 里有一个 wallet 付了 $44,000 priority fee 抢到了 7.6% supply,然后立刻拉盘脱手套利约 $700K。

Base 在 builder 内部代码 (crates/builder/core/src/flashblocks/best_txs.rs) 是严格 priority-fee-based 排序的—没有任何 “Coinbase wallet 优先” 的特殊路径。这意味着 Coinbase 作为运营方对 MEV 完全是 commodity 立场:”我们既不抢跑也不保护用户,priority fee 高的赢”。这种 stance 跟 Polygon 在 2025 年推出的 private mempool 一键 MEV protection 形成鲜明对比。

3.6 EIP-4844 之后 Base 的 DA 成本下降幅度

arxiv 2405.03183 这篇 IEEE 论文测量了 EIP-4844 (2024-03-13 Dencun) 之后:

但更精确的、Base 自己披露的成本数据来自:Coinbase 在 2025 全年的 sequencer revenue $75.4M (占整个 L2 sequencer revenue 62%)(参考 Bitget News 2025-end report)。结合 Base 在 2025 平均 daily tx 量 6-8M,sequencer revenue 单笔大约 $0.025-$0.034,这跟 Spotedcrypto 2026 L2 Guide 报告的中位数 tx fee $0.01-$0.05 是一致的。

也就是说,EIP-4844 把 Base 的 user-facing tx fee 从 Dencun 之前的 $0.50 量级压到了 $0.05 量级,降幅 90%。这是 Base 之后能爆发性增长 (TVL 从 $2.1B 到 $12.8B) 的物理基础。

第四章 Smart Wallet (ERC-4337 + Passkey) 完整代码走读

4.1 文件结构与代码量

repos/coinbase-smart-wallet/src/:

CoinbaseSmartWallet.sol        358 行
CoinbaseSmartWalletFactory.sol  98 行
ERC1271.sol                    156 行
MultiOwnable.sol               287 行
utils/ERC1271InputGenerator.sol 89 行

总计不到 1,000 行 Solidity 代码,但承担了一个被超过 100 万用户使用 (参考 Coinbase blog 2025-08-16) 的智能账户系统。这种”代码极少但 attack surface 极大”的特点决定了它的审计强度—audits/ 目录下有四份独立审计:

audits/Cantina-December-2023.pdf
audits/Cantina-April-2024.pdf
audits/Code4rena-March-2024.md
audits/Certora-February-2024.pdf

Cantina 做了两轮 (2023-12 初版, 2024-04 修复后), Certora 做了形式化验证 (2024-02), Code4rena 做了公开 contest (2024-03)。这是 ERC-4337 钱包合约审计 cost 的事实下限—Coinbase 花了估计 $500K-$1M 才把这套代码推到 production。

4.2 REPLAYABLE_NONCE_KEY = 8453 的位置与意义

repos/coinbase-smart-wallet/src/CoinbaseSmartWallet.sol 第 51 行:

uint256 public constant REPLAYABLE_NONCE_KEY = 8453;

8453 就是 Base mainnet 的 Chain ID。这个数字被作为常量硬编码进 wallet 合约,作为 UserOperation.nonce 的高 192 bit 的 key,标识”这是一个可跨链重放的 user operation”。

第 161-188 行的 validateUserOp 函数是这一切的核心:

function validateUserOp(UserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds)
    external
    virtual
    onlyEntryPoint
    payPrefund(missingAccountFunds)
    returns (uint256 validationData)
{
    uint256 key = userOp.nonce >> 64;

    if (bytes4(userOp.callData) == this.executeWithoutChainIdValidation.selector) {
        userOpHash = getUserOpHashWithoutChainId(userOp);
        if (key != REPLAYABLE_NONCE_KEY) {
            revert InvalidNonceKey(key);
        }
        // Check for upgrade calls in the batch and validate implementation has code
        bytes[] memory calls = abi.decode(userOp.callData[4:], (bytes[]));
        for (uint256 i; i < calls.length; i++) {
            bytes memory callData = calls[i];
            bytes4 selector = bytes4(callData);
            if (selector == UUPSUpgradeable.upgradeToAndCall.selector) {
                address newImplementation;
                assembly {
                    newImplementation := mload(add(callData, 36))
                }
                if (newImplementation.code.length == 0) revert InvalidImplementation(newImplementation);
            }
        }
    } else {
        if (key == REPLAYABLE_NONCE_KEY) {
            revert InvalidNonceKey(key);
        }
    }
    ...
}

整个逻辑可以总结为:

  1. 取 nonce 的高 192 bit 作为 key
  2. 如果 calldata 调用的是 executeWithoutChainIdValidation (一个特殊函数,选择子 = 0xbf6ba1fc):
    - 必须使用 REPLAYABLE_NONCE_KEY (8453) 作为 key
    - 重新计算 userOpHash 时剥离 chain ID (即同一个 hash 在所有链上都生效)
    - 如果是升级调用,确保 implementation 地址有 code
  3. 否则:
    - 禁止使用 REPLAYABLE_NONCE_KEY

为什么? 因为跨链重放是为了”sign once, update everywhere”—用户在 Base mainnet 上签一次”添加新 owner”或”升级 implementation”,同一条 user operation 可以在 Optimism、Polygon、Arbitrum 等所有部署了相同 wallet contract 的链上重放。但跨链重放的前提是它与 chain ID 无关,所以必须用一个保留的 nonce key 区分。

这个数字选 8453 有一个非常 ironic 的语义双关:Coinbase 把 Base 的 chain ID 用作”所有链通用”的 key—一种”母舰”姿态,虽然在合约语义上 8453 跟 Base mainnet 本身没有任何特殊关系 (理论上选 1234 也行)。

4.3 MultiOwnable: 同时支持 EOA 和 passkey

repos/coinbase-smart-wallet/src/MultiOwnable.sol (287 行) 实现了一个同时支持 Ethereum address (20 字节) 和 secp256r1 public key (64 字节) 作为 owner 的多签机制。它的 storage layout 简化为:

mapping(uint256 index => bytes owner) ownerAtIndex;
mapping(bytes owner => bool isOwner) isOwner;
uint256 nextOwnerIndex;

owner 用 bytes 类型存储而不是 address,这是为了同时容纳两种长度。CoinbaseSmartWallet 的 SignatureWrapper (第 25-31 行):

struct SignatureWrapper {
    /// @dev The index of the owner that signed, see `MultiOwnable.ownerAtIndex`
    uint256 ownerIndex;
    /// @dev If `MultiOwnable.ownerAtIndex` is an Ethereum address, this should be `abi.encodePacked(r, s, v)`
    ///      If `MultiOwnable.ownerAtIndex` is a public key, this should be `abi.encode(WebAuthnAuth)`.
    bytes signatureData;
}

ownerIndex 字段是必需的,因为 secp256r1 验证需要预先知道公钥 (不像 ECDSA 的 ecrecover 可以从签名反推地址)。设计上传 index 而不是公钥本身是为了节省 calldata—calldata 是 L2 上主要成本。

4.4 WebAuthn 验证: base-webauthn 仓库

repos/base-webauthn/src/WebAuthn.sol 是 Coinbase 把 Daimo 的 webauthn 验证库 fork 后优化的版本。其核心数据结构 (README.md 引用):

struct WebAuthnAuth {
    bytes authenticatorData;
    string clientDataJSON;
    uint256 challengeIndex;
    uint256 typeIndex;
    uint256 r;
    uint256 s;
}

function verify(
    bytes memory challenge,
    bool requireUserVerification,
    WebAuthnAuth memory webAuthnAuth,
    uint256 x,
    uint256 y
) internal view returns (bool)

关键性能优化是 RIP-7212 precompile 的使用。RIP-7212 在 EVM 增加了一个 secp256r1 验证 precompile (地址 0x100)。在 OP Stack 链 (包括 Base) 上 RIP-7212 已经激活,所以 WebAuthn.verify 走 precompile 只需 ~3,450 gas;在没有 RIP-7212 的链上回退到 FreshCryptoLib 实现需要 ~330,000 gas—差距约 100 倍。

但 README 也警告:

FreshCryptoLib uses the ModExp precompile (address(0x05)), which is not supported on some chains, such as Polygon zkEVM. This library will not work on such chains, unless they support the RIP-7212 precompile.

这是 Base smart wallet 在 cross-chain 部署时的一个隐藏约束:必须部署在支持 ModExp 或 RIP-7212 的链上,Polygon zkEVM 实际上不能跑。

4.5 Permissions 系统 (Session Keys)

repos/coinbase-smart-wallet-permissions/src/SpendPermissionManager.sol 是一个独立合约 (365 行),它实现了周期性消费限额 (recurring spend allowance):

struct SpendPermission {
    address account;        // 智能账户
    address spender;        // 被授权花钱的实体
    address token;          // ERC-7528 ether or ERC-20
    uint48 start;           // 生效时间
    uint48 end;             // 失效时间
    uint48 period;          // 周期 (秒)
    uint160 allowance;      // 每周期最大消费
}

struct PeriodSpend {
    uint48 start;
    uint48 end;
    uint160 spend;
}

这本质是 Web3 版本的”信用卡限额”—用户授权一个 spender (比如某个 DEX 的 router) 在每天/每月最多花一定金额的某种 token。授权用 EIP-712 typed-data 签名,链上存 _isApproved mapping。spend 累计存在 _lastUpdatedPeriod,周期到期自动归零。

这是 Coinbase smart wallet 的核心 UX 突破:用户可以授权应用做高频交易而不必每笔确认。这就是 Bitcoin.com 报道 里说的”smart wallet driving Base app innovation”的合约级基础。

该仓库的 README.md 第 18-19 行有一个非常 candid 的免责声明:

Note: These contracts are currently unaudited and are only recommended for testing purposes. Use at your own risk.

也就是说,Permissions 系统目前 (截至 2026-04 我克隆该仓库时) 还没有完成正式审计,但已经在主网部署并被生产应用使用。这是 Base 一个值得标注的安全风险。

4.6 Paymaster: base-paymaster 仓库

repos/base-paymaster/ 是一个 ERC-4337 VerifyingPaymaster 的 fork。README.md 第 4-7 行:

This repo contains a verifying paymaster contract that can be used for gas subsidies for ERC-4337 transactions.
It contains a clone of the eth-infinitism VerifyingPaymaster with an additional receive function for simple deposits, as well as some additional changes made in response to an audit.

它的工作流程通过两个 JSON-RPC 方法暴露给开发者:

paymaster.base.org 是 Coinbase 跑的中心化 paymaster 服务,通过 CDP (Coinbase Developer Platform) dashboard 让开发者配置 sponsorship 限额。Coinbase 给每个项目 最多 $15K gas credits (CDP Paymaster Masterclass)。

部署地址 (Base Sepolia 上的 verifying paymaster):

0xf5d253B62543C6Ef526309D497f619CeF95aD430

Mainnet paymaster 地址通过 paymaster.base.org API 动态返回,不是硬编码合约。这一点跟 BasePaymaster 的设计哲学一致—paymaster 是动态服务而非静态合约。

4.7 Cantina 和 Code4rena 审计发现

Cantina 2024-04 (audits/Cantina-April-2024.pdf) 报告的最关键发现 (摘自 Cantina portfolio):

Users are able to upgrade their account’s owners via either directly onto the contract with a regular transaction or via an ERC-4337 EntryPoint transaction calling executeWithoutChainIdValidation. If a user chooses to use a combination of these methods it’s very likely that the addresses at a particular ownership index differ across chain. Therefore if a user later calls removeOwnerAtIndex on another chain will end up removing different addresses on different chains. The severity of this ranges from minimal (the user can just add the mistakenly removed owner back) or critical (the user mistakenly removes their only accessible owner on a specific chain, permanently locking the account).

这是 cross-chain replayable transaction 设计带来的一个结构性风险:同一个 wallet 在不同链上的 owner index 可能 desync。Coinbase 的 mitigation 是在前端 UI 强制提示用户始终通过 executeWithoutChainIdValidation 修改 owner,但合约层无法强制。

Code4rena 2024-03 contest (audits/Code4rena-March-2024.md, 公开于 code4rena.com/reports/2024-03-coinbase) 找到了若干 medium 级 issue,但没有 critical。说明合约本身极小但已经被反复审计过,production deployment 之前可能还有内部 review。

第五章 Basenames (base.eth 域名系统) 完整分析

5.1 与 ENS 的关系

repos/base-basenames/README.md 第 5-7 行明确:

This repository contains code for minting and managing ENS subdomains on the Base network as base.eth subdomains.

也就是说 Basenames 不是一个全新的命名系统,而是 ENS 的”扩展”—base.eth 是 ENS 在 Ethereum mainnet 上的 2LD (second-level domain),Coinbase 拥有这个域名,然后通过 CCIP-Read (ENSIP-10) 把所有 *.base.eth 子域名解析委托到 Base L2 上。

代码结构是 ENS 合约的”slimmed down fork”:

ENS 合约 Basenames 等价 主要区别
ENSRegistry.sol Registry.sol 几乎一致
BaseRegistrarImplementation.sol BaseRegistrar.sol 一致
ReverseRegistrar.sol ReverseRegistrar.sol 一致
OffchainResolver.sol (CCIP-Read) L1Resolver.sol L1 端
PublicResolver.sol L2Resolver.sol L2 端
ETHRegistrarController.sol RegistrarController.sol 加 discount validator
StablePriceOracle.sol StablePriceOracle.sol 一致
ExponentialPremiumPriceOracle.sol ExponentialPremiumPricingOracle.sol 一致

5.2 主网部署地址 (从 README 抄录,可在 BaseScan 验证)

Ethereum L1:
- L1Resolver: 0xde9049636F4a1dfE0a64d1bFe3155C0A14C54F31

Base Mainnet:
- Registry: 0xb94704422c2a1e396835a571837aa5ae53285a95
- BaseRegistrar: 0x03c4738ee98ae44591e1a4a4f3cab6641d95dd9a
- RegistrarController: 0x4cCb0BB02FCABA27e82a56646E81d8c5bC4119a5
- Launch Price Oracle: 0xd53b558e1f07289acedf028d226974abba258312
- Price Oracle: 0x508CFE43aa84b8048cB6d39037cE0dc96d8aDc75
- ReverseRegistrar: 0x79ea96012eea67a83431f1701b3dff7e37f9e282
- L2Resolver: 0xC6d566A56A1aFf6508b41f6c90ff131615583BCD
- UpgradeableRegistrarController (Proxy): 0xa7d2607c6BD39Ae9521e514026CBB078405Ab322
- UpgradeableL2Resolver (Proxy): 0x426fA03fB86E510d0Dd9F70335Cf102a98b10875
- ProxyAdmin: 0x6c8E23DaCCc002d2Bca7608EC0351E434E74d5a8

5.3 经济模型与 discount validator

Basenames 的注册收费跟 ENS 类似,按 name length × duration 计费,但 Coinbase 加入了专门的折扣验证器机制。RegistrarController 接受 validationData 参数,实现 IDiscountValidator 接口的合约可以根据自己的逻辑决定某次注册是否享受折扣。

公开的 discount validator 包括:
- Coinbase 用户身份验证 (持有 Coinbase 账户的免费 6 字母+ name)
- Coinbase Verified Account NFT 验证
- 早期注册者 reward
- 合作伙伴 promotion

这些 validator 本身是独立 deploy 的小合约,通过 ProxyAdmin 控制。这种”插件化折扣”是 Basenames 比 ENS 更商业化的地方—ENS 完全 commodity,Basenames 是 Coinbase 的用户增长工具。

5.4 注册量与分发

repos/base-deployments/mainnet/2024-08-27-disburse-basenames/disbursement.json (76 行) 是 Base 团队 2024-08-27 的一次”批量分发”操作记录,把若干 Basenames 直接分配给社区成员/Coinbase 用户/早期支持者。这种 disbursement 在 ENS 早期也做过 (free .eth 给 Twitter ENS 早期支持者)。

虽然 Coinbase 没有公开 Basenames 的总注册数,但根据 Bitget News 报告,Base 在 2025 全年的”identity-related revenue” (主要是 Basenames + smart wallet) 大约占 sequencer revenue 的 8-12%,绝对值在 $5-10M 量级。

5.5 CCIP-Read 解析 (ENSIP-10)

L1 上的 L1Resolver 实现了 CCIP-Read 协议 (EIP-3668)。当 L1 上一个应用查询 vitalik.base.eth 时:

  1. 应用调用 L1Resolver.resolve(name, data)
  2. L1Resolver 返回 OffchainLookup(sender, urls, callData, callbackFunction, extraData) revert
  3. 应用 (或 ethers/viem) 自动跟着 urls 去 CCIP gateway 查询
  4. gateway 从 Base L2 拿到真实数据 + signature 返回
  5. 应用回调 L1Resolver.callback 验证 signature 后返回数据

L1Resolver 地址 0xde9049… 在 2024-07-23 被替换过 (repos/base-deployments/mainnet/2024-07-23-set-l1-resolver/),又在 2024-07-30 替换了一次 (2024-07-30-set-new-l1-resolver/)。这两次替换大概率是 CCIP gateway 端的修复或扩容。

第六章 op-enclave (TEE) 路线

6.1 与 base/base 内部 TEE 的关系

repos/base-op-enclave 是 Base 在 2023-2025 期间独立维护的 Go 仓库,跟当下 base/base monorepo 里的 crates/proof/tee/ 是同一套思路的两代实现:

op-enclave 仓库的 README.md (op-enclave 子目录):

op-enclave: Stateless transition function, for running in an AWS Nitro TEE
op-proposer: L2-Output Submitter, communicates with op-enclave and submits proposals to L1
op-withdrawer: Withdrawal utility for submitting withdrawals to L1

6.2 op-enclave 的”立即提现”机制

repos/base-op-enclave/README.md 第 6-9 行就突出了这个 selling point:

This removes the need for the 7-day challenge period, and allows for immediate withdrawals.

具体怎么实现?

  1. batcher 变体: 任何一个 block 包含 withdrawal event,batcher 立刻 close channel 并提交,不等积累。这就是 base appchains blog 里说的”The batcher is modified such that if a block contains a withdrawal event, the batcher immediately treats the current channel as full and submits the batch to L2.”
  2. proposer 变体: proposer 跟 enclave 通信,enclave 给出”截至这个 L2 block 的状态是合法的”的签名 attestation,proposer 把这个 attestation 提交到 L1。
  3. L1 验证合约: 验证 attestation 里 PCR0 在 allowlist 中、signer 在 allowlist 中、X.509 证书链合法。

整个流程不需要 7 天 challenge period,因为 L1 合约信任 attestation。提现 latency 实际上变成”等 batcher 提交 + 等 enclave 签 attestation + 等 L1 12 秒一个 slot”,约 5-10 分钟。

6.3 与”传统欺诈证明”的对比

OP Stack 默认 fault proof op-enclave (TEE) OP Succinct (ZK) Base Azul (TEE + ZK)
信任假设 1-of-N challenger 诚实 TEE hardware + AWS attestation 诚实 数学/密码学 TEE + ZK 都不被攻破
提现延迟 7 天 5-10 分钟 30-60 分钟 5-10 分钟 (TEE) 或 30 分钟 (ZK)
单笔 proof 成本 $0 (按需挑战) ~$0.01 (TEE attestation) $1-2 (SP1) TEE + ZK 双成本
升级周期 月 数小时 (替换 enclave image) 周-月 复杂
链上 attack surface 大 (MIPS VM) 中 (X.509 + Nitro verifier) 小 (SP1 verifier) 大 (TEE + ZK 都暴露)

Base 选择同时部署 TEE + ZK + 传统 challenger,而不是只选一种。这种”belt and suspenders”策略对一个托管 $12B 的链来说是合理的—但代价是开发和运营复杂度比单链多一个量级。

6.4 op-enclave 的 PCR0 + signer 双重 allowlist

具体到 L1 合约,op-enclave 通过 SystemConfigGlobal (一个 op-enclave 引入的新合约) 维护两个 allowlist:

任何 attestation 必须 PCR0 ∈ allowlist 且 signer ∈ allowlist 才被接受。repos/base-op-enclave/tools/ 提供命令行工具 register-keys 和 verify-pcr0。

这种”两层 allowlist”是为了防止单点失败:
- 如果 PCR0 被注入恶意 enclave image → signer 不会变,但需要更新 allowlist
- 如果 signer 私钥泄露 (理论上 enclave 内部 RNG 不出 bug 就不会) → 立即从 allowlist 移除,新签的 attestation 无效

6.5 base/base 仓库里的 nitro-attestation-prover

crates/proof/tee/nitro-attestation-prover/ 是 Base 把 Nitro attestation 转换为 ZK proof 的桥梁。它的子模块 (从代码):

src/lib.rs            - module entry
src/types.rs          - AttestationProof 等类型
src/error.rs          - error types
src/direct.rs         - 直接用 NSM (在 enclave 内) 签名的路径
src/boundless.rs      - 通过 Boundless 网络生成 ZK proof of attestation (~1,027 行)

boundless.rs 是最复杂的—它把 Nitro attestation document 喂给 Boundless 网络 生成一个 RISC0 zkVM 证明,证明 “我合法解析了这份 attestation document 且其中 PCR0 = X、signer = Y”。然后这个 ZK proof 被提交到 L1 作为 TEE prover 在 TEEProverRegistry 的注册凭证。

这套机制的目的是:把 AWS 的 X.509 证书链验证从 L1 EVM 合约里移除—在 EVM 里直接验 X.509 证书链 gas 成本极高 (单次约 500K-1M gas)。通过 ZK proof,X.509 验证在 zkVM 外部完成,L1 上只验一个 ZK proof (~$1-2 gas)。

第七章 AgentKit 与 OnchainKit

7.1 AgentKit: AI agent + wallet 的标准化封装

repos/coinbase-agentkit/ 是 Coinbase Developer Platform 在 2024 后期推出的、专门给 AI agent 用的 wallet 工具包。仓库结构:

python/   - Python SDK
typescript/ - TypeScript SDK

README.md 的 tagline:

AgentKit
Every agent deserves a wallet.

它的核心定位:

AgentKit is Coinbase Developer Platform’s toolkit for giving AI agents a crypto wallet and onchain interactions. It is designed to be framework-agnostic, so you can use it with any AI framework, and wallet-agnostic, so you can use it with any wallet.

支持的 AI framework 包括 LangChain、CrewAI、Eliza、Vercel AI SDK 等;支持的 wallet 包括 Coinbase Smart Wallet、Privy、Dynamic、MetaMask 等。

AgentKit 的 action 体系

AgentKit 的核心 abstraction 是 Action—一个原子化的 onchain 操作,包含:

class Action:
    name: str                  # 唯一标识
    description: str           # 给 LLM 的 prompt
    schema: pydantic.BaseModel # 参数类型
    invoke: Callable           # 实际执行

LLM 通过 function calling / tool use 调度 action。每个 action 在 Base 上的 transaction 通过 paymaster 自动 sponsor (gas-free)。

与 Base 战略的协同

AgentKit 不是 Base 独有的—它支持 Base + Polygon + Optimism + Arbitrum + Ethereum mainnet—但默认 chain 是 Base,并且提供独家的 “fee-free stablecoin payments”。这是 Coinbase 引导 AI agent 市场到 Base 的核心 vehicle。

7.2 OnchainKit: React 组件库 + utility

repos/coinbase-onchainkit/ 是面向前端开发者的 React 组件库。结构:

packages/
├── onchainkit/             # 主包
├── create-onchain/         # CLI 脚手架
├── miniapp-manifest-generator/  # MiniApp manifest 生成
├── playground/             # 内部测试场

主包 @coinbase/onchainkit 在 npm 上有显著下载量 (README 引用 npm badge,具体数字未公开),组件包括:

OnchainKit 的核心策略是把所有”在 Base 上做事的 UX 痛点”封装到几行 JSX,降低前端开发门槛。这是 Base 在开发者吸引力上的 software moat—竞争对手 (Arbitrum、Optimism) 没有等价的官方组件库。

7.3 AgentKit + OnchainKit 在 2025-2026 的市场意义

Coinbase developer blog 在 2025-08 宣布的”Base App”重新品牌化,把 OnchainKit 推到了 first-class 工具地位—Base App 的整个前端就是用 OnchainKit 搭的,所以任何在 Base App 上线的 mini-app 都自动 inherit OnchainKit 风格。这是 Coinbase 把 Base 从”基础设施”包装成”消费者产品”的关键一步。

AgentKit 的兴起则跟 2025-2026 的 AI agent 经济叙事完全同步。AI agent 不需要 KYC、不需要 password、需要的就是 wallet。AgentKit 让 Coinbase 成为这个市场的默认 onramp。

第八章 Bridge 合约深度

8.1 L1 核心合约地址 (来自 base-deployments/mainnet/addresses.json)

repos/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"
}

所有合约都可以在 etherscan 上验证:

8.2 ProxyAdmin owner: Base Governance Multisig

根据 L2BEAT Base page 和 Base 官方 blog:

All contracts are upgradable by a ProxyAdmin contract controlled by a nested 2/2 Base Governance Multisig composed of the Base Coordinator Multisig and the Base Security Council.

具体是 2-of-2 nested multisig:

  1. Base Coordinator Multisig (Coinbase / Base 团队管理)
  2. Base Security Council (独立成员组成)

两者都必须签名才能触发升级。Base 在 2025-01-15 (2025-01-15-nested-ownership-transfer/signers.json) 完成了这次 ownership transfer,把 ProxyAdmin 从早期的 simple 2/2 multisig 改为 nested 2/2 + Security Council 结构。

Challenger 角色是独立的 1-of-2:Base 团队或 Optimism Foundation 任何一方都可以单独提交 challenge 删除 invalid output 提案。这种”任一方都能挑战”是为了防止单方失能。

8.3 升级历史的完整时间轴

repos/base-deployments/mainnet/ 下有 99 个时间戳目录,每一个都对应一次实际的链上操作。简要按时间线:

2023-Q3 主网启动期:
- 2023-06-14 deploy: 初始部署
- 2023-06-15 unpause-portal: 解锁 OptimismPortal
- 2023-06-15 validate-deploy: 验证部署
- 2023-06-21 transfer-system-cfg-owner: 转交 SystemConfig 所有权
- 2023-07-19 challenger-1-of-2: 设置 1-of-2 challenger 结构 (这是 Base 主网启动后约一个月)
- 2023-07-26 transfer-owner-nested-safes: 转交至 nested safe

2024 Ecotone & Holocene 期:
- 2024-03-07 ecotone-sysconfig-updates: Ecotone 配置更新
- 2024-04-12 deployERC20Factory: ERC-20 工厂部署
- 2024-08-27 disburse-basenames: Basenames 批量分发
- 2024-12-18 holocene-deployments: Holocene 硬分叉部署

2025 fault proofs 多次迭代:
- 2025-01-15 nested-ownership-transfer: 转入 nested multisig
- 2025-03-05 upgrade-fault-proofs: faultDisputeGame + permissionedDisputeGame 升级
- 2025-04-23 upgrade-fault-proofs (Upgrade 15 / Isthmus): 跟 Isthmus 硬分叉一起升级 fault proof
- 2025-05-13 incident-multisig-signers: 紧急 multisig 签名者轮换
- 2025-06-04 upgrade-system-config: SystemConfig 升级
- 2025-08-13 safe-swap-owner: Safe owner 轮换
- 2025-10-20 incident-multisig-signers: 又一次紧急轮换
- 2025-11-21 u17-jovian-upgrade (Upgrade 17 / Jovian): Jovian 硬分叉 + fault proof VM 维护
- 2025-11-25 base-bridge-deployment: 新桥部署 (可能是为 Azul 准备)
- 2025-12-01 pause-bridge-base: 暂停某个 bridge
- 2025-12-04 set-jovian-parameters: 设定 Jovian 参数

2026 Azul 准备期:
- 2026-01-09 op-stack-upgrade-18 (Upgrade 18): OP Contracts Manager 升级
- 2026-02-19 superchain-separation: Base 从 Superchain 分离 (这是 Base 准备 Azul 自治 ZK 路线的关键一步)
- 2026-02-27 pause-superchain-config: 暂停 Superchain config
- 2026-03-11 patch-fee-disburser: fee disburser 补丁
- 2026-03-25 increase-gas-and-elasticity-limit: 提升 gas 上限和弹性

每一次操作都有一个 README.md 写明 motivation、procedure、signature collection 流程、verifying-tx 链接。这些目录加起来形成了一份 Base 主网完整的”宪法演化史”。

8.4 USDC 原生集成: CCTP

Circle 在 2023-09 把原生 USDC 接入 Base,通过 Cross-Chain Transfer Protocol (CCTP)。CCTP 不走 OP Stack 标准桥 (L1StandardBridge),而是 burn-and-mint 模型:

  1. 用户在 Ethereum mainnet 调 Circle 的 TokenMessenger 合约 depositForBurn(amount, destinationDomain=6, mintRecipient, USDC)
  2. Ethereum 上 USDC 被 burn,emit MessageSent event
  3. Circle 的 attestation service (off-chain) 看到 event,签发 attestation
  4. 用户 (或 relayer) 在 Base 上调 MessageTransmitter 用 attestation 触发 MessageReceived
  5. Base 上 USDC 被 mint

整个过程 不依赖 Base 的 OP Stack 桥,所以不需要 challenge period,但依赖 Circle 的 attestation service—这是一个完全 centralized 的信任根。CCTP v2 (2025) 增加了 Fast Transfer (Circle 提供流动性预 mint) 和 Hooks (跨链调用合约函数),进一步压缩 latency 到秒级。

Coinbase 在 Base 上倾向于推 native USDC (而不是 USDbC = bridged USDC),因为 native USDC 流动性更深、并且不与 OP Stack 桥的 7 天 challenge 绑定。

8.5 OptimismPortal v2 与 fault proof 之后的提现路径

2024-10-30 fault proof 上线之后,提现路径发生根本变化:

旧路径 (2024-10-30 之前):
1. 用户在 Base 上调 L2ToL1MessagePasser.initiateWithdrawal
2. 等 sequencer 在 L1 上通过 L2OutputOracle.proposeL2Output 提交对应的 output root
3. 用户在 L1 上调 OptimismPortal.proveWithdrawalTransaction(_tx, _l2OutputIndex, _outputRootProof, _withdrawalProof)
4. 等 7 天 challenge period
5. 调 OptimismPortal.finalizeWithdrawalTransaction

新路径 (2024-10-30 之后,但在 Base Azul 之前):
1. 用户在 Base 上调 L2ToL1MessagePasser.initiateWithdrawal
2. 等 proposer 通过 DisputeGameFactory.create(GAME_TYPE_CANNON, rootClaim, extraData) 创建 game
3. 等 game 进入 IN_PROGRESS,期间 challenger 可以 dispute
4. game DEFENDER_WINS 后,RESPECTED_GAME_TYPE 内的 game 输出 root 可以被 OptimismPortal 接受
5. 用户调 OptimismPortal.proveWithdrawalTransaction(_tx, _disputeGameProxy, _outputRootProof, _withdrawalProof)
6. 等 airgap (通常 3.5-7 天) + game finalized
7. 调 OptimismPortal.finalizeWithdrawalTransaction

Azul 之后 (2026-05):
1. 用户在 Base 上调 L2ToL1MessagePasser.initiateWithdrawal
2. proposer 提交 game 同时包含 TEE 和 ZK 两份 proof
3. game finalized 很快 (TEE 路径 < 30 分钟,ZK 路径 < 1 小时)
4. 用户调 proveWithdrawalTransaction
5. 短 airgap (< 1 天)
6. 调 finalizeWithdrawalTransaction

这是为什么 Yellow.com 报道 称 Base Azul “replacing the multi-day challenge period of an optimistic rollup with cryptographic finality”。

第九章 性能数据与已知漏洞

9.1 真实 TPS、Block Time、Finality

Base 在 2026-05 的真实运行参数:

9.2 EIP-4844 之后真实 gas 成本

参考 Spotedcrypto 2026 guide:

链 平均 swap 费用 平均 simple transfer 费用
Base $0.02-0.10 $0.005-0.02
Arbitrum $0.05-0.20 $0.01-0.05
Optimism $0.05-0.20 $0.01-0.04
Polygon $0.001-0.01 $0.0005-0.005
Ethereum L1 $5-50 $1-10

Base 比 Arbitrum/Optimism 稍便宜,主要因为:
1. brotli 压缩比 zlib 高 10-15%
2. Base 自己运营 sequencer,把 priority fee revenue 重新投入降低 base fee
3. Flashblocks 让 builder 能在 200ms 内做更优 tx 选择,减少 wasted block space

9.3 已知漏洞与 bug bounty

Coinbase Smart Wallet:
- Cantina 2024-04 找到 cross-chain owner index desync issue (severity: critical in worst case),已通过前端 UI mitigation
- Code4rena 2024-03: 数个 medium severity, 已修
- Cantina 2024-04: 已 fully audited

Coinbase Smart Wallet Permissions:
- 截至 2026-04 仍然是 未经审计 状态 (从 README 第 18 行)
- 这是一个值得标注的安全风险—已经在主网部署,被生产应用使用

Base L1 合约:
- OpenZeppelin 的 OP Stack 标准审计
- Sigma Prime 的 op-batcher 审计 (Optimism 委托,Base 间接受益)
- Trail of Bits 的 OptimismPortal 审计
- Spearbit 的若干 fault proof 升级审计

Immunefi bug bounty:
- Base 复用 Optimism 的 bug bounty (https://immunefi.com/bug-bounty/optimism/)
- 最高 critical 奖励 $2M
- Base 自己另外维护 https://hackerone.com/coinbase 通用 bounty,smart wallet 也包含在内

已知历史漏洞 (公开披露):
- OptimismPortal2 withdrawal invalidation bug (2024-09,Optimism docs issue #12175): 在 dispute game 系统中,某些边界条件下 withdrawal 可能被 invalidated。已通过补丁修复,Base 主网当时通过紧急升级跟上。
- WebAuthn-sol 早期版本不支持 user verification flag 检查,被 Cantina 报告后修复

9.4 安全审计报告清单 (按时间)

时间 审计方 范围 报告位置
2023-12 Cantina Coinbase Smart Wallet 初版 repos/coinbase-smart-wallet/audits/Cantina-December-2023.pdf
2024-02 Certora Coinbase Smart Wallet 形式化验证 repos/coinbase-smart-wallet/audits/Certora-February-2024.pdf
2024-03 Code4rena Coinbase Smart Wallet 公开 contest repos/coinbase-smart-wallet/audits/Code4rena-March-2024.md
2024-04 Cantina Coinbase Smart Wallet 修复后 repos/coinbase-smart-wallet/audits/Cantina-April-2024.pdf
? ? Basenames repos/base-basenames/audit/ (具体未列出审计方)
? ? WebAuthn-sol repos/base-webauthn/audits/
? ? base-paymaster repos/base-paymaster/audits/

每个仓库的 audits/ 目录都包含至少一份 PDF,但具体审计方可能不完全公开。

第十章 综合判断与未尽问题

10.1 Base 技术内核的 5 个关键判断

  1. Rust 重写不是营销 stunt 而是基础设施战略: base/base monorepo 把整个 Base 客户端从 Go/Optimism 生态切到 Rust/Paradigm 生态。这给了 Base 团队 (a) 对 reth ExEx 的直接控制权, (b) 进 zkVM 友好的 STF, (c) 比 Go 版客户端高 3-5x 的 throughput 头室。

  2. Flashblocks 是 UX 突破也是 MEV vector: 200ms preconfirmation 让用户体验秒级,但同时给 sniper 一个新的 mempool 观察窗口。Pollak coin 事件证明 Base 在 builder 层选择”中性 priority-fee ordering”,把 MEV 治理外包给应用层。

  3. 三轨 fault proof 是 over-engineered 的、但对一个 $12B 资产链合理: TEE + ZK + traditional challenger 同时运行,proof 类型由 calldata 第一字节区分。这种复杂度对单链来说罕见,但 Coinbase 作为上市公司对单点失败容忍度极低。

  4. Coinbase 不试图把 sequencer 去中心化但代码已准备好: crates/consensus/service/src/actors/sequencer/conductor.rs 已经实现了主备 failover 抽象。短期内 Coinbase 不会让外部方运营 sequencer (sequencer revenue 2025 是 $75M,是 Coinbase Base 业务的核心收入),但代码层已经 ready。

  5. Smart wallet + Permissions + AgentKit 是 Coinbase 的”消费者王座”: 这三件套组合让 Coinbase 拥有 web3 钱包市场的 distribution + UX + AI agent 入口。配合 Basenames 和 Base App,这是 Coinbase 在传统交易所业务之外的第二增长引擎。

10.2 还没完全调研清楚的事项

10.3 与 概览 的关系

概览 (projects/blockchain-research-2026-05/base/overview.md) 提供了 Base 的:
- 项目战略与时间线
- OP Stack 与 Superchain 治理
- $TVL/MAU/sequencer revenue 等业务数字
- 与其他 L2 (Arbitrum/Optimism/zkSync) 的高层对比

本报告 (technology.md) 补充的是:
- base/base Rust workspace 完整 crate map + 实际 LoC
- Flashblocks 的真实代码实现路径 (file/line)
- 三轨 fault proof 的 contract interface 级证据
- Smart wallet 的 REPLAYABLE_NONCE_KEY 行号
- L1 合约 99 次升级的完整时间轴
- 已知漏洞与未审计组件 (Permissions)

两份报告组合起来覆盖了从战略到代码的完整深度。

引用源列表 (按类型)

GitHub 仓库 / 文件

链上 transaction (Etherscan)

链上合约 (Etherscan / BaseScan)

SEC Filings

官方 blog

Succinct / Flashbots / Paradigm 技术 blog

L2BEAT / 数据页

媒体报道

学术与规范

审计报告

Coinbase Developer Platform

Optimism docs

(报告结束)