九思札记 · 探索区块链 · AI

对应大纲 8.5–8.6：在掌握“可扩展性三难困境”与链上扩容（分片、侧链、状态通道）之后，本章深入探讨当前以太坊等公链最主流的两种扩容与跨链实践——Rollup（卷叠）与跨链桥/协议。

8.5 Rollup 技术：Optimistic Rollup 与 ZK Rollup

在前文提到“链上扩容”与“侧链”之后，我们介绍一种既保留主链安全、又大幅提升吞吐的技术路线：Rollup（通常译为“卷叠”或“汇总”）。Rollup 的核心思路是：将大量交易的执行放到链下，但把交易的数据和压缩后的状态承诺发布到 Layer 1（L1），从而继承 L1 的数据可用性（Data Availability，简称 DA）与结算安全。

8.5.1 Rollup 的定义、架构与 L1 安全保障

定义：Rollup 是一种 Layer 2（L2）扩容方案，在链下执行批量交易，仅将压缩后的交易数据（calldata）或 EIP-4844 blob 数据发布到 L1，同时定期向 L1 提交一个密码学状态根（State Root），由 L1 上的桥合约负责验证其有效性或管理挑战期。

核心组件：

Sequencer（排序器）：接收用户交易，在 L2 本地执行并排序，生成新区块。
L1 桥合约（Bridge Contract）：部署在以太坊主网上的智能合约，托管状态根、存款与提款，执行最终性验证。
数据可用性层（DA Layer）：将压缩交易数据发布到 L1，确保任何节点都可以通过 L1 数据重建完整 L2 状态。

graph TD
    A[用户交易] -->|发送| B[Sequencer / L2 节点]
    B -->|执行批量交易| C[L2 状态更新]
    B -->|发布压缩交易数据| D[L1 数据可用性层]
    B -->|提交新状态根| E[L1 桥合约]
    D -.->|数据可用性保证| E
    E -->|验证 / 挑战期管理| F[L1 安全性保障]

为什么要发布数据到 L1？ 如果只发布状态根而不发布原始交易数据，那么当 Sequencer 作恶或离线时，用户无法通过 L1 数据重建 L2 状态，也就无法“强制提款”或证明自身资产归属。因此，DA 是 Rollup 安全性的生命线。

要点总结：

Rollup = 链下执行 + L1 数据发布 + L1 状态验证/托管。
安全性来源于 L1 的数据可用性，而非侧链那样依赖独立共识。

8.5.2 Optimistic Rollup：乐观假设与欺诈证明

Optimistic Rollup（乐观卷叠） 的核心哲学是"无罪推定"：Sequencer 提交的状态根默认被视为有效，但设有一个挑战窗口（通常为约 7 天），期间任何验证者（Watcher）若发现无效的状态转移，可提交欺诈证明（Fraud Proof）挑战。

欺诈证明的演化：

单轮欺诈证明：挑战者提交矛盾状态根，L1 合约重算争议交易的执行，直接裁决对错。简单直接，但 L1 Gas 消耗较高。
多轮交互式欺诈证明（如 Arbitrum 的 BoL，Bisection of Logic）：

挑战者与 Sequencer 在链下（或链上交互）逐层二分查找，将争议范围从整个区块缩小到单条 EVM 指令。
最终只需在 L1 上执行单条指令并比对结果，即可判定胜负。
败方质押金被罚没，胜方获得奖励。

sequenceDiagram
    participant U as 用户
    participant S as Sequencer
    participant L1 as L1 桥合约
    participant V as 验证者
    U->>S: 提交交易
    S->>L1: 提交新状态根 + 压缩数据
    L1-->>V: 7 天挑战窗口开启
    alt 无挑战
        L1->>L1: 最终确认，允许提款
    else 验证者发起挑战
        V->>L1: 提交欺诈证明
        L1->>L1: 二分查找 / 重算指令
        L1->>S: 败方罚没
        L1->>V: 胜方奖励
    end

博弈论激励：

设 Sequencer 需要质押保证金 $B$ ，验证者挑战成本为 $C$ 。若挑战成功，Sequencer 被罚没 $B$ ，验证者获得奖励 $R$ （通常 $R > C$ ）:

\text{验证者利润} = \begin{cases} R - C > 0 & \text{（挑战成功，Sequencer 作恶）} \\ -C & \text{（挑战失败，Sequencer 诚实）} \end{cases}

只要至少存在一个诚实的验证者，Sequencer 作恶的预期收益为负。

代表项目：Arbitrum（多轮交互式欺诈证明）、Optimism（OP Stack，单轮非交互式）。

要点总结：

Optimistic Rollup 依赖经济激励和至少一个诚实验证者维护安全。
7 天挑战期的代价是提款到 L1 的延迟较长。

8.5.3 ZK Rollup：密码学有效性与零知识证明

ZK Rollup（零知识卷叠） 不走“信任+挑战”路线，而是让每个状态转移都附带一个密码学有效性证明（Validity Proof）。一旦证明被 L1 合约验证通过，状态即被视为最终确定，无需挑战窗口。

两种主流证明系统：

zk-SNARKs（如 Groth16、PLONK）：证明体积小（约 200–500 字节）、验证极快（毫秒级），但大多数方案需要可信设置（Trusted Setup），且部分在量子计算面前存在风险。
zk-STARKs（基于 FRI 多项式承诺）：无需可信设置，具有量子抗性，但证明体积较大（数十至数百 KB）、验证成本略高。

graph LR
    A[用户交易] --> B[聚合器 / Prover]
    B -->|生成 ZK 证明| C[zk-SNARK / zk-STARK]
    C -->|提交至| D[L1 验证合约]
    D -->|验证通过| E[状态即时最终化]

最简单的 ZK 验证接口（Solidity 示意）：

solidity

// 极简化示意：L1 验证合约调用zk-proof验证器
function submitBatch(
    bytes32 oldStateRoot,
    bytes32 newStateRoot,
    bytes calldata compressedTxData,
    uint256[8] calldata zkProof
) external {
    // 1. 验证 zk 证明
    require(verifier.verifyProof(zkProof, [oldStateRoot, newStateRoot]));
    // 2. 确认数据已在 L1 可用
    // 3. 更新状态
    stateRoot = newStateRoot;
    emit BatchFinalized(newStateRoot);
}

状态压缩公式：设旧状态为 $S_{old}$ ，执行压缩交易集合 $T = \{tx_1, tx_2, \dots, tx_n\}$ 后的新状态为 $S_{new}$ 。ZK Rollup 提交的证明本质上是：

\mathcal{P} : \text{Prove}\Big( H(S_{new}) = H\big( \Upsilon(S_{old}, T) \big) \Big)

其中 $H$ 为状态哈希函数， $\Upsilon$ 为状态转移函数，证明者用 ZK 电路（如 Circom、Noir、Halo2）证明此等式成立，但不泄露 $T$ 的细节。

代表项目：zkSync Era（zk-SNARKs）、StarkNet（zk-STARKs）、Scroll（zkEVM，字节码等效级）、Polygon zkEVM。

要点总结：

ZK Rollup 用密码学替代经济学实现安全性，提款延迟显著降低。
当前瓶颈在于证明生成（Proof Generation）的时间和计算成本。

8.5.4 Optimistic Rollup vs ZK Rollup 全面对比

特性维度	Optimistic Rollup	ZK Rollup
最终确认延迟	7 天挑战期（提款至 L1）	证明验证后即时（分钟级）
安全性假设	经济激励 + 至少 1 位诚实挑战者	密码学正确性 + 电路安全
L1 验证成本	低（默认接受）	中等（需验证 ZK 证明）
证明生成开销	无	高（CPU/GPU，数秒至数分钟）
EVM 兼容性	可直接运行 EVM 字节码	需要 zkEVM 电路等效（逐步完善）
数据压缩率	高（状态差异 + 压缩签名）	更高（SNARK 数据极紧凑）

Gas 节省示例：原始 L1 交易成本约为每笔 $C_{L1}$ ，Rollup 批量压缩后分摊至每用户的 L1 成本约为：

C_{\text{Rollup}} \approx \frac{\text{calldata\_gas(compressed\_batch)}}{n} \ll C_{L1}

批量越大， $n$ 越大，单用户分摊成本越低，通常可达到 10–100 倍 的吞吐量提升。

要点总结：

Optimistic 偏向“生态快速落地和 EVM 兼容”；ZK 偏向“密码学安全与即时最终性”。
两条路线正逐步互补，未来的混合方案可能是最优解。

8.6 跨链技术：哈希时间锁、公证人机制与中继

Rollup 解决了单链扩容，但区块链世界已经存在数千条公链与 L2，资产与信息的跨链流动成为刚需。

8.6.1 哈希时间锁（HTLC）与原子交换

哈希时间锁合约（Hash Time-Locked Contract，HTLC） 是最早实现无信任跨链交换的原语。

核心逻辑：

哈希锁（Hash Lock）：创建者生成一个秘密值 $s$ ，公布其哈希 $H(s)$ 作为锁定条件。只有知道 $s$ 的一方才能解锁资金。
时间锁（Time Lock）：如果在约定时间 $T$ 内未解锁，资金自动退回原主。

两方跨链原子交换流程：

Alice 在链 A 锁定 1 BTC，条件为 解锁需 H(s)，设定时间锁 $T_1$ 。
Bob 在链 B 锁定等值 ETH，条件为同一 H(s)，设定时间锁 $T_2 < T_1$ 。
Alice 在 $T_2$ 内用 $s$ 解锁链 B 的 ETH，此时 $s$ 在链上公开。
Bob 获得 $s$ ，解锁链 A 的 BTC。
若 Alice 未在 $T_2$ 内行动，Bob 可等待 $T_2$ 超时后安全退款。

sequenceDiagram
    participant A as Alice (链A)
    participant B as Bob (链B)
    A->>A: 生成秘密 s, 公布 H(s)
    A->>A: 锁定 1 BTC (条件: H(s), 时间 T1)
    B->>B: 锁定等值 ETH (条件: H(s), 时间 T2<T1)
    A->>B: 用 s 解锁 ETH
    B->>A: 用公开 s 解锁 BTC

原子性条件：

\text{Swap\_Success} \iff \text{secret\_revealed\_A} \land \text{secret\_revealed\_B}

\text{Swap\_Abort} \iff \text{timeout\_A} \land \text{refund\_A} \land \text{refund\_B}

原子交换不需要信任任何第三方，但要求双方同时在线，且汇率需在交换前约定，用户体验较差。

代码示意（简化版伪代码）：

solidity

// 链B 上的简化 HTLC（Solidity 示意）
contract HTLC {
    bytes32 public hashLock;
    uint256 public timeout;
    address public recipient;
    address public sender;

    constructor(bytes32 _hashLock, uint256 _timeout, address _recipient) payable {
        hashLock = _hashLock;
        timeout = _timeout;
        recipient = _recipient;
        sender = msg.sender;
    }

    function unlock(bytes32 secret) external {
        require(keccak256(abi.encode(secret)) == hashLock);
        payable(recipient).transfer(address(this).balance);
    }

    function refund() external {
        require(block.timestamp > timeout);
        payable(sender).transfer(address(this).balance);
    }
}

要点总结：

HTLC 实现了无第三方信任的跨链资产交换。
局限在于需要双方在线、汇率锁定、无法直接传递通用消息。

8.6.2 公证人机制与联邦门限签名桥

当需要持续流入/流出资产或传递消息时，纯 HTLC 不够灵活。跨链桥应运而生。

信任光谱：

信任级别	机制	信任假设
完全中心化	单一托管方（交易所）	完全信任托管方
联邦门限	t-of-n 多签 / 阈值签名	至少 n-t+1 个节点诚实
去信任	轻客户端 / ZK 桥	密码学 + 源链共识安全

联邦门限签名桥：由 $n$ 个独立验证者组成联邦，当 $t$ （ $t \leq n$ ）个节点签名即可批准跨链转账。例如 Ronin Network 早期采用 5/9 多签，Wormhole 使用 19/19 的 Guardian 网络。

安全边界：设单个验证者被攻破的概率为 $p$ ，则联邦失效概率为：

P_{\text{fail}} = \sum_{i=t}^{n} {n \choose i} p^i (1-p)^{n-i}

从工程上看， $t$ 通常设为 $2n/3$ 或大于 $n/2$ ，以确保即使少数节点被攻破，资金仍然安全。

graph TD
    A[源链资产锁定] -->|事件| B[联邦验证者 1..n]
    B -->|t-of-n 签名| C[多签合约/门限签名]
    C -->|铸造/释放| D[目标链对应资产]

关键风险：联邦桥的“安全天花板”取决于联邦节点的密钥管理。一旦节点密钥泄露或被社会工程攻破，资产可被直接提取。

要点总结：

联邦桥在便利性与去信任之间取得折中，是行业广泛采用的模式。
然而，联邦桥的安全事件频发，证明“人”仍是最大弱点。

8.6.3 中继链与轻客户端验证（以 Cosmos IBC 为例）

IBC（Inter-Blockchain Communication） 是 Cosmos 生态的跨链标准协议，其核心思想是：在链 A 上部署链 B 的轻客户端（Light Client），通过中继者（Relayer）传递区块头和默克尔/状态证明，实现链间消息验证。

IBC 生命周期示意：

sequenceDiagram
    participant ChA as 链 A
    participant Rel as Relayer（中继者）
    participant ChB as 链 B（轻客户端）
    ChA->>ChA: 发送跨链数据包
    ChA->>Rel: 传出区块头 + Merkle 证明
    Rel->>ChB: 提交链 A 轻客户端更新
    ChB->>ChB: 验证区块头与交易存在性证明
    alt 验证通过
        ChB->>ChB: 执行对应操作（转账/消息）
        ChB->>ChA: 返回确认或超时处理
    end

轻客户端不执行源链全部交易，仅验证区块头和交易存在性，大大降低了跨链验证成本。信任假设从“联邦节点诚实”下降为“源链共识安全”。

要点总结：

轻客户端桥比联邦桥更接近“去信任”，但实现复杂度高。
Relayer 作恶无法伪造证明（因为密码学验证失败会被合约拒绝），只能审查（延缓）消息传递。

8.6.4 跨链桥的安全记录：重大攻击与漏洞类型

跨链桥是区块链行业中被攻击金额最高的领域之一。主要漏洞类型包括：

私钥泄露 / 联邦节点被攻破

典型案例：Ronin Network（2022 年，6/9 验证者私钥被社工攻破，损失约 6.25 亿美元）。

智能合约逻辑漏洞

典型案例：Poly Network（2021 年，跨链合约权限验证漏洞，损失约 6.1 亿美元）；Nomad Bridge（2022 年，初始化根哈希错误，损失约 1.9 亿美元）。

验证者共谋 / 社会工程

典型案例：Wormhole（2022 年，Solana 侧签名验证绕过，损失约 3.2 亿美元）。

graph TD
    A[跨链桥安全漏洞] --> B[密钥/多签层]
    A --> C[智能合约层]
    A --> D[验证者共识层]
    A --> E[社会工程层]
    B --> B1[私钥泄露]
    B --> B2[门限不足被突破]
    C --> C1[逻辑错误]
    C --> C2[重入/权限绕过]
    D --> D1[验证者共谋]
    E --> E1[钓鱼/社工]

加固方向：

审计与形式化验证（Formal Verification）
逐步降低信任假设：从联邦桥 → 轻客户端桥 → ZK 桥
监控与紧急暂停机制

solidity

// 简化的多签校验（防御签名绕过）
function verifySignatures(bytes32 digest, bytes[] calldata signatures) internal view {
    address lastSigner = address(0);
    uint256 validCount = 0;
    for (uint i = 0; i < signatures.length; i++) {
        address signer = ecrecover(digest, ...);
        require(signer != lastSigner, "duplicate signature"); // 防御复制攻击
        require(isAuthorized[signer], "unauthorized");
        lastSigner = signer;
        validCount++;
    }
    require(validCount >= threshold, "insufficient signatures");
}

要点总结：

跨链桥历史上损失金额极高，是行业最脆弱的环节之一。
安全趋势是减少对人/联邦的信任，转向密码学和轻客户端验证。

本章小结

Rollup 不是侧链，而是继承 L1 安全性的信任最小化扩容路径。其核心是“链下执行 + L1 数据可用性 + L1 验证/托管”。
数据可用性（DA）是扩容的真正瓶颈，而非单纯计算。无论 Optimistic 还是 ZK 路线，必须在 L1 上发布可验证的数据，否则安全性将退化为侧链。
跨链桥是区块链生态中最脆弱的环节。从联邦多签到轻客户端验证再到 ZK 桥，行业正朝着“去信任化”方向演进，但完全安全的跨链互操作性仍是远未解决的难题。

本页目录

8.5 Rollup 技术：Optimistic Rollup 与 ZK Rollup

8.5.1 Rollup 的定义、架构与 L1 安全保障

8.5.2 Optimistic Rollup：乐观假设与欺诈证明

8.5.3 ZK Rollup：密码学有效性与零知识证明

8.5.4 Optimistic Rollup vs ZK Rollup 全面对比

8.6 跨链技术：哈希时间锁、公证人机制与中继

8.6.1 哈希时间锁（HTLC）与原子交换

8.6.2 公证人机制与联邦门限签名桥

8.6.3 中继链与轻客户端验证（以 Cosmos IBC 为例）

8.6.4 跨链桥的安全记录：重大攻击与漏洞类型

本章小结

评论

发表评论