8.3 侧链：双向锚定与联邦侧链

8.3.1 侧链基本概念

侧链（Sidechain）是独立于主链（Mainchain，亦称母链）运行、但通过双向锚定（2-way peg）机制实现资产双向流转的独立区块链。其核心理念可概括为"主链存根、侧链创新"——主链保留资产价值与最终结算的权威性，侧链则自由探索新的共识算法、出块时间、虚拟机和隐私特性，而不必修改主链协议。

flowchart TB
    subgraph Mainchain["主链：价值锚定层"]
        A1["PoW / 主共识"]
        A2["$1亿资产锁仓"]
    end
    subgraph Sidechain["侧链：性能/创新层"]
        B1["自定义共识"]
        B2["快出块"]
        B3["智能合约"]
    end
    A1 <-- "双向锚定(2WP)" --> B1
    A2 -. "锁定/解锁" .-> B2
    B3 -. "铸造/销毁" .-> A2

侧链的安全模型与主链完全分离：它运行独立共识，出块由独立验证者负责，与主链状态无直接继承关系。这意味着一旦侧链共识被攻破，主链资产仍是安全的——前提是锁定在主链的多签或合约中的资产未被非法解锁。

【本节要点】

• 侧链是独立的区块链，通过双向锚定实现资产的双向流转。
• 安全模型与主链完全解耦，侧链自身的共识失败不会直接影响主链。
• 侧链的核心定位是"技术试验场"，允许在主链不硬分叉的前提下探索新特性。

8.3.2 双向锚定机制

双向锚定（2-way peg, 2WP）是侧链与主链之间的"经济桥梁"。以从主链向侧链转账为例，典型的资产流转流程包含四个阶段：

1. Lock（锁定）：用户在主链将一定数量的原生代币（如 BTC）发送至由托管方控制的特殊地址或合约。
2. Mint（铸造）：侧链确认锁定交易后，按 1:1 比例在侧链上铸造等量的锚定资产（如 SBTC）。
3. Burn（销毁）：用户在侧链上将锚定资产发送至销毁地址或销毁合约。
4. Unlock（解锁）：托管方或智能合约验证销毁交易后，在主链解锁并返还等量的原生代币。

sequenceDiagram
    actor U as 用户 Alice
    participant M as 主链
    participant B as 桥/托管方
    participant S as 侧链

    U->>M: 发送 1 BTC 至锁定地址
    M->>B: 交易确认（6+ 区块）
    B->>S: 验证锁定 + 提交 SPV/Merkle 证明
    S->>U: 铸造 1 SBTC
    Note over U,S: 在侧链使用 SBTC（低费用、快确认）
    U->>S: 烧毁 1 SBTC
    S->>B: 销毁确认
    B->>M: 执行解锁交易
    M->>U: 返还 1 BTC

理想的双向锚定要求严格的主链交易存在性证明（如 SPV 证明），以防止伪造的解锁请求。然而，将完整的主链区块头或 Merkle 证明提交到侧链存在两大困境：（1）主链数据量过大，侧链状态膨胀；（2）SPV 证明仍依赖侧链节点诚实接收和验证区块头，且无法防范重组攻击。因此，大多数实际部署的侧链方案退化为联邦托管模式。

【本节要点】

• 双向锚定的核心是 Lock→Mint→Burn→Unlock 的闭环流程。
• 去中心化的 SPV 桥面临数据可用性与重组风险，至今难以大规模落地。
• 联邦托管是现实中最常见的实现方式。

8.3.3 联邦侧链：以 Liquid Network 为例

联邦侧链（Federated Sidechain）不依赖密码学承诺证明，而是依赖一组预先选定的公证人（Functionary）运行节点并通过硬件安全模块（HSM, Hardware Security Module）进行多签授权来托管主链资产。

Liquid Network 是由 Blockstream 推出的比特币联邦侧链，核心特征包括：

graph LR
    subgraph BTCNet["Bitcoin 主链"]
        L["锁定 BTC"]
    end
    subgraph Liquid["Liquid Network"]
        F1[Functionary 1 + HSM]
        F2[Functionary 2 + HSM]
        F3[Functionary 3 + HSM]
        F4[...]
        F5[Functionary 15 + HSM]
        FM[出块 11-of-15 共识]
        FM2[解锁多签 m-of-n]
    end
    F1 & F2 & F3 & F4 & F5 --> FM
    L -. "管理密钥" .-> F1 & F2 & F3 & F4 & F5
    FM --> FM2
    FM2 -. "解锁请求" .-> L

在液态网络中，Functionary 通过各自的 HSM 参与共识与资产托管。HSM 私下生成并保管私钥碎片，节点无法直接导出私钥，这显著降低了单点泄露的概率。但本质上，L-BTC 的价值仍完全依赖于联邦成员的诚实与在线状态。

# P2SH 2-of-3 多签 redeem script 结构（概念展示）
# 实际液态网络使用更复杂的动态阈值与 HSM 内部签名
# 比特币脚本层面可简示为：
redeem_script = bytearray([
    0x52,                # OP_2 (需2个签名)
    0x21,                # 推送长度 33 字节
    # pubkey1: 33 bytes compressed
    0x02, 0x9f, 0xc3, 0x70, 0xe2, 0x79, 0xee, 0x79,
    0x68, 0x59, 0x33, 0x4e, 0xcc, 0x63, 0x36, 0x4e,
    0xca, 0x12, 0x89, 0x6a, 0xf2, 0x4a, 0x2a, 0x21,
    0x65, 0xcd, 0x5a, 0x21, 0x52, 0x8d, 0x45, 0x12,
    0x36, 0x6e,
    0x21,                # 推送长度 33 字节
    # pubkey2: 33 bytes compressed
    0x03, 0xab, 0x2e, 0xe3, 0x4e, 0xd4, 0xa1, 0x91,
    0x72, 0x12, 0x2a, 0xcc, 0x4e, 0x12, 0xbc, 0x61,
    0x2d, 0x8e, 0x1a, 0x44, 0x12, 0xab, 0x5c, 0x21,
    0xcd, 0x2a, 0x78, 0x12, 0x34, 0x45, 0x12, 0x56,
    0x78, 0x9a,
    0x21,                # 推送长度 33 字节
    # pubkey3: 33 bytes compressed
    0x03, 0xcd, 0x12, 0x34, 0x56, 0x78, 0x9a, 0xbc,
    0xde, 0xf0, 0x12, 0x34, 0x56, 0x78, 0x9a, 0xbc,
    0xde, 0xf0, 0x12, 0x34, 0x56, 0x78, 0x9a, 0xbc,
    0xde, 0xf0, 0x12, 0x34, 0x56, 0x78, 0x9a, 0xbc,
    0xde, 0xf0,
    0x53,                # OP_3 (总3个公钥)
    0xae,                # OP_CHECKMULTISIG
])
# 实际在液态网络中，脚本通常封装在 P2WSH 或 Taproot 输出中

【本节要点】

• Liquid Network 是比特币最重要的联邦侧链，使用 Functionary + HSM 架构。
• 出块依赖于 11-of-15 联邦共识，资产托管使用多签。
• 联邦侧链牺牲了无信任假设，换取了 1 分钟出块与保密交易（Confidential Transaction）等创新。

8.3.4 信任假设对比：侧链、联邦侧链与 Rollup 的安全谱系

理解扩容方案的关键维度之一，是明确安全依赖于哪些外部假设：

对于联邦侧链，假设每个 Functionary 被独立攻破的概率为 $p$，联邦共 $N$ 个节点，多签阈值为 $t$，则在对手无法串谋的前提下，联邦资产被攻破的近似概率为：

此公式在 $p \ll 1$ 时成立。例如，当 $N=15$、$t=5$、$p=0.1$（单节点独立被攻破概率 10%）时，$\binom{15}{5} \approx 3003$，$P_{\text{compromise}} \approx 3003 \times 10^{-5} \approx 0.03$。若 $p$ 上升至 0.3，$P_{\text{compromise}} \approx 3003 \times 0.00243 \approx 7.3$，已超出 1，说明公式在 $p$ 较大时仅提供定性参考，实际风险需将串谋攻击与社交工程学纳入威胁模型。

【本节要点】

• 安全谱系的核心差异在于"谁为状态有效性和资产托管背书"。
• 独立侧链的安全完全独立；联邦侧链依赖多签联邦的诚实多数；Rollup 依赖主链数据可用性与密码学证明。
• 联邦多签被攻破的概率随阈值设计指数下降，但无法归零。

8.3.5 局限性与现状

侧链与联邦侧链面临三大现实局限：

1. 流动性割裂（Liquidity Fragmentation）：BTC 锁定在 Liquid 后变为 L-BTC，但 L-BTC 的交易深度远低于主链 BTC，跨侧链套利与做市成本高昂。
2. 与 Rollup 的竞争：Rollup 继承了主链安全假设而无需引入新的信任方，在以太坊生态中已全面取代早期侧链思路。比特币侧链（如 Liquid、Rootstock/RSK、传统 Polygon PoS 链）虽仍有市场，但角色正逐渐从"扩容主角"退居为"功能补充"。
3. 桥的安全事件：大量跨链桥因本地侧链共识被攻破、联邦 HD 密钥泄露或智能合约漏洞导致资产被盗，累计损失已超数十亿美元。

【本节要点】

• 侧链的最大瓶颈不是技术，而是安全模型与信任假设的不可承受之重。
• 在以太坊，Rollup 已取代侧链成为扩容主路径；在比特币，侧链仍作为功能扩展存在。
• 跨链桥安全事件频发，提醒设计者：侧链不是主链的"安全副本"。

8.4 状态通道：闪电网络与雷电网络

8.4.1 状态通道核心思想

状态通道（State Channel）将高频、小额的多笔交易完全移至链下执行，仅在通道开启（Funding）和关闭（Settlement）时与主链交互。其直觉类比是酒吧记账本：酒客与老板之间每次点酒不立刻结算，而是记在小本本上，最终离店时一次性付清。

sequenceDiagram
    actor A as Alice
    actor B as Bob
    participant BC as 主链

    A->>BC: 开启通道：多签锁定 1.0 BTC
    BC-->>A: 通道就绪
    Note over A,B: 链下状态更新（0 费用、即时确认）
    A->>B: 签名新状态：Alice 0.8, Bob 0.2
    B->>A: 签名新状态：Alice 0.5, Bob 0.5
    A->>B: 签名新状态：Alice 0.3, Bob 0.7
    Note over A,B: ... 任意多笔
    B->>BC: 提交最新状态并关闭通道
    BC-->>A: 释放 0.3 BTC
    BC-->>B: 释放 0.7 BTC

状态通道的关键约束是：通道内的交易双方必须预先锁定资金，且所有链下状态更新必须以双方联合签名作为有效凭证。一旦任何一方想退出，只需将最新状态提交至主链即可结算。

【本节要点】

• 状态通道的精髓是"链下高频、链上最终结算"。
• 仅开启和关闭时上链，中间任意数量的更新均为链下签名交换。
• 天然适合高频、固定对手方或小额支付场景。

8.4.2 闪电网络概述

闪电网络（Lightning Network）是比特币状态通道的旗舰实现，由 Joseph Poon 与 Thaddeus Dryja 于 2015 年提出。其核心设计基于两个密码学构件：

• RSMC（Revocable Sequence Maturity Contract，可撤销序列成熟合约）：解决"若一方广播旧状态如何惩罚"的问题。
• HTLC（Hash Time-Locked Contract，哈希时间锁合约）：实现无需信任第三方的多跳支付路由。

通道开启时，双方各将资金发送至一个2-of-2 多签地址。谁也无法单独花费这笔资金，只有双方联合签名才能更新通道状态或最终解锁。

graph LR
    subgraph 链下通道["Alice ⟷ Bob 通道"]
        A1["Alice 0.5"] ---|2-of-2 多签| B1["Bob 0.5"]
    end
    F["Funding Tx<br/>锁定 1.0 BTC 至 P2WSH"]
    F --> 链下通道
    style 链下通道 fill:#e1f5fe

# 闪电网络 2-of-2 多签 Funding 输出（P2WSH 形式）
# witness script 保存在 witness 字段，脚本哈希嵌入输出
# 脚本结构：
funding_witness_script = bytes([
    0x52,   # OP_2（需要2个签名）
    0x21,   # 推送 Alice 压缩公钥（33字节）
    # <Alice_pubkey_33bytes>,
    0x21,   # 推送 Bob 压缩公钥（33字节）
    # <Bob_pubkey_33bytes>,
    0x52,   # OP_2（共2个公钥）
    0xae,   # OP_CHECKMULTISIG
])
# P2WSH 输出脚本：OP_0 <32-byte-SHA256(witness_script)>

【本节要点】

• 闪电网络是比特币的链下支付网络，基于 RSMC + HTLC 两大协议。
• 资金锁定在 2-of-2 多签地址中，双方必须联合签名才能动用。
• 闪电网络是"非托管"的：没有第三方能够冻结或盗取通道内资金。

8.4.3 RSMC：旧状态广播问题与可撤销机制

状态通道面临一个关键博弈问题：若 Alice 和 Bob 的通道内资金分配已从（0.5, 0.5）更新到（0.3, 0.7），但 Alice 恶意地在主链广播旧的承诺交易（0.5, 0.5），试图窃取本已属于 Bob 的 0.2 BTC，系统应如何防范？

RSMC 的解决方案是可撤销承诺：每一次状态更新时，双方都签署两份交易：

1. 新的承诺交易（Commitment Transaction），反映最新余额分配。
2. 对旧状态的"违约补救交易"（Breach Remedy Transaction），赋予对方在发现旧状态被广播时快速抢占全部资金的权利。

具体而言，每个承诺交易的输出中嵌入一个脚本，包含两条路径：

• 路径 A（正常结算）：Bob 签名 + OP_CHECKSEQUENCEVERIFY（CSV）延迟（如 144 个块）后可取回其份额。
• 路径 B（惩罚速拿）：若 Alice 广播了旧承诺，Bob 可在 CSV 解锁前使用 Alice 泄露的"可撤销密钥"立即取走通道内全部资金。

flowchart TD
    A["旧状态 C_n-1 承诺交易"] -->|"Alice 恶意广播"| B["进入确认期"]
    B --> C["CSV 延迟期"]
    C -->|"Bob 发现"| D["使用可撤销密钥"]
    D --> E["Bob 取走全部资金"]
    C -->|"无人在延迟期内申诉"| F["按旧状态结算"]
    style D fill:#f8bbd0
    style E fill:#ffcdd2

# RSMC 输出脚本条件分支示意（Alice 侧承诺输出）
# 允许 Bob 在延迟后取回，或 Alice 在更长的延迟后取回，
# 或如果此状态已被撤销，则 Bob 可用可撤销密钥立即取走全部资金
rsmc_output_script = """
    OP_IF
        # 路径：可撤销惩罚（Breach Remedy）
        <revocation_pubkey>
        OP_CHECKSIG
    OP_ELSE
        # 路径：正常结算
        <to_local_delay>
        OP_CHECKSEQUENCEVERIFY
        OP_DROP
        <local_delayed_pubkey>
        OP_CHECKSIG
    OP_ENDIF
"""
# 实际上闪电网络脚本更复杂，包含 HTLC 分支，此处展示核心逻辑

从博弈论角度看，Alice 广播旧状态的期望收益为：若成功，她获得 $\Delta$（余额差）；若被 Bob 发现并惩罚，她损失通道内全部资金 $C$。假设广播成功的概率为 $1-p$，被发现的概率为 $p$，则理性条件要求：

即

由于通道内总资金 $C$ 通常远大于单次欺诈收益 $\Delta$，且闪电网络鼓励节点全时段监控（或通过瞭望塔 Watchtower 代监控），$p$ 实际上趋近于 1。因此，理性参与者绝无动机广播旧状态。

【本节要点】

• RSMC 通过"可撤销密钥 + CSV 延迟 + 惩罚路径"解决旧状态广播问题。
• 广播旧状态的预期收益为负，博弈论上使欺诈无利可图。
• 惩罚机制要求节点能及时发现链上广播，这催生了"瞭望塔"服务。

8.4.4 HTLC 与多跳支付

若 Alice 与 Bob 有直接通道，双方可直接支付；但现实中期望每对支付方都直接建立通道既不经济也不现实。闪电网络通过 HTLC（Hash Time-Locked Contract，哈希时间锁合约） 实现多跳路由：Alice 可以经由中间节点 Carol、Dave 向无直接通道的 Bob 付款。

HTLC 的核心逻辑用比特币脚本表示为：收款方必须在时间锁 $T$ 到期前提供哈希 $H$ 的原像 $R$（满足 $H = \text{HASH}(R)$）才能解锁资金；否则资金退回给付款方。

OP_HASH160 <H> OP_EQUALVERIFY
OP_CHECKSIG
# 或结合时间锁分支：
# OP_IF <payment_hash> OP_EQUALVERIFY OP_CHECKSIG
# OP_ELSE <time_lock> OP_CHECKLOCKTIMEVERIFY OP_DROP <refund_pubkey> OP_CHECKSIG

多跳支付要求时间锁递减：Alice→Carol 的时间锁为 $t_1$，Carol→Dave 的时间锁为 $t_2$，Dave→Bob 的时间锁为 $t_3$，且满足：

即每一跳为下一跳留出充分的链上申诉窗口。当 Bob 使用原像 $R$ 从 Dave 处解锁后，$R$ 逐跳回传，所有中间节点同步完成结算；若某跳在超时前未收到原像，则上一跳可安全退款。这种设计保证了支付的原子性：

要么全部通道成功结算，要么全部退款，不存在中间状态。整个流程无需任何中间节点信任 Alice 或 Bob。

sequenceDiagram
    actor AL as Alice
    participant C as Carol
    participant D as Dave
    actor BO as Bob

    BO->>BO: 生成原像 R，计算 H=HASH(R)
    BO->>AL: 发送 invoice 包含 H
    AL->>C: 创建 HTLC：若 C 提供 R，则将 1 BTC 给 C（超时 t_1）
    C->>D: 创建 HTLC：若 D 提供 R，则将 1 BTC 给 D（超时 t_2 < t_1）
    D->>BO: 创建 HTLC：若 BO 提供 R，则将 1 BTC 给 BO（超时 t_3 < t_2）
    BO->>D: 提供 R，解锁并接收 1 BTC
    D->>C: 传递 R，解锁并接收 1 BTC
    C->>AL: 传递 R，解锁并接收 1 BTC
    Note over AL,BO: 所有 HTLC 同时原子完成

【本节要点】

• HTLC 通过"哈希原像 + 时间锁"实现无需信任的多跳支付。
• 时间锁逐跳递减，为每个中间人保留链上索赔窗口。
• 支付具有原子性：要么端到端成功，要么全部回滚退款。

8.4.5 闪电网络的局限性

尽管理论优雅，闪电网络在实践中仍面临结构性挑战：

1. 通道余额不平衡（Imbalance）：Alice→Bob 通道初始各投入 0.5 BTC。若 Alice 持续向 Bob 小额支付，最终 Alice 余额耗尽，通道单向饱和，无法继续向 Bob 付款。解决方案包括：Circular Payment（环状再平衡）、通过外部存款重新注资、或 splice-in/splice-out 技术将通道调整与链上交易合并。
2. 在线要求与瞭望塔：为防止对手广播旧状态，用户必须保持链上监控。离线用户可委托瞭望塔（Watchtower）代为监控，但这引入了轻微的服务依赖。
3. 路由复杂性与入站流动性：多跳支付需要通道图谱中存在从付款人到收款人的连续路径，且路径上每条通道都具备足够的入站容量（Inbound Liquidity）。新节点往往只有出站流动性，接收付款能力受限。

graph LR
    subgraph 通道余额不平衡
        A1["Alice 0.1"] ---|通道| B1["Bob 0.9"]
        A1 -. "已耗尽" .-> B1
    end
    subgraph 瞭望塔
        U["用户离线"]
        W["Watchtower"]
        U -. "委托惩罚权" .-> W
        W -->|监听链上广播| BC["区块链"]
    end

【本节要点】

• 余额不平衡、在线要求与路由复杂性是闪电网络的三大运营难题。
• 瞭望塔可缓解在线要求，但增加运维复杂度。
• 入站流动性不足是新节点加入支付网络的关键门槛。

8.4.6 雷电网络：以太坊版状态通道

雷电网络（Raiden Network）可以视为以太坊生态中的"闪电网络"，核心思想完全一致：链下签名状态更新、链上最终结算。但由于以太坊是账户模型而非比特币的 UTXO 模型，RSMC 与 HTLC 被改写为 Solidity 智能合约。

主要差异包括：

雷电网络的核心 Solidity 合约逻辑可示意如下：

// Raiden 风格通道合约简化示意（教学用，非生产代码）
contract PaymentChannel {
    address public participant1;
    address public participant2;
    uint256 public deposited1;
    uint256 public deposited2;
    uint256 public challengePeriod; // 挑战/申诉窗口
    uint256 public stateNonce;      // 最新有效状态序号
    mapping(bytes32 => bool) public withdrawn; // HTLC 原像记录

    event ChannelOpened();
    event ChannelSettled(uint256 finalBalance1, uint256 finalBalance2);

    // 开启通道：双方各自存入保证金
    function openChannel(address _p2) external payable {
        require(participant1 == address(0), "Already open");
        participant1 = msg.sender;
        participant2 = _p2;
        deposited1 = msg.value;
        emit ChannelOpened();
    }

    function joinChannel() external payable {
        require(msg.sender == participant2, "Not participant2");
        deposited2 = msg.value;
    }

    // 链下状态由双方签名：更新余额分配
    // updateState 仅在链上关闭或争议时调用
    function updateState(
        uint256 _nonce,
        uint256 _balance1,
        uint256 _balance2,
        bytes calldata sig1,
        bytes calldata sig2
    ) external {
        require(_nonce > stateNonce, "Nonce too old");
        bytes32 hash = keccak256(abi.encodePacked(_nonce, _balance1, _balance2));
        require(recover(hash, sig1) == participant1, "Invalid sig1");
        require(recover(hash, sig2) == participant2, "Invalid sig2");
        stateNonce = _nonce;
        deposited1 = _balance1;
        deposited2 = _balance2;
    }

    // 最终结算：在挑战期后按最新状态分配资金
    function settle() external {
        // 实际需检查 challengePeriod 已过且无异义
        payable(participant1).transfer(deposited1);
        payable(participant2).transfer(deposited2);
        emit ChannelSettled(deposited1, deposited2);
    }

    // 恢复公钥工具函数
    function recover(bytes32 hash, bytes calldata sig) internal pure returns (address) {
        // ECDSA 恢复逻辑
    }
}

雷电网络的优势在于以太坊图灵完备合约的灵活性，理论上可支持任意状态（不仅是支付）的链下更新。但这也带来了合约复杂度和安全风险：合约漏洞可能导致全部通道资金受损。

【本节要点】

• 雷电网络是闪电网络在账户模型上的对应物，核心思想相同但实现介质为智能合约。
• 以太坊账户模型使通道合约更灵活，但非 UTXO 模型使 HTLC 需以合约逻辑模拟。
• 比特币闪电网络与以太坊雷电网络共同验证了"状态通道"范式的跨链通用性。

8.4.7 适用边界与总结

状态通道并非万能。其适用边界可通过三约束判断：

1. 对手方固定：必须预先知道且锁定交易对手（或经由固定路由图）。
2. 交互固定：适用于反复交互的场景，单次支付建立通道不经济。
3. 金额范围：通道锁定资金上限限制了单笔最大支付额；过高金额不适合通道而适合主链直接结算。

graph TD
    Q1["需要扩容？"] -->|是| Q2["对手方/路由固定？"]
    Q2 -->|是| Q3["高频/中低频？"]
    Q3 -->|高频| A1["状态通道/闪电网络"]
    Q3 -->|中低频| A2["考虑 Rollup"]
    Q2 -->|否| A3["Rollup / 新公链"]
    Q1 -->|否| A4["主链直接交易"]
    style A1 fill:#c8e6c9
    style A2 fill:#fff9c4

在比特币世界，闪电网络是二层支付扩张的核心方案，已承载数万节点和数万 BTC 的流动性。在以太坊世界，由于 Rollup 已大幅降低了链上交易成本，纯支付通道的普及度不及闪电网络，但基于状态通道的通用状态通道方案（如 State Channels、Counterfactual）仍在特定高频交互场景（如游戏、即时支付）中保有价值。

下一节将介绍如何在不引入额外信任假设的前提下，实现主链级别的安全扩容——即 Rollup。Rollup 将交易执行移至链下，但将压缩后的交易数据或有效性证明提交至主链，从而在继承主链安全性与数据可用性保障的同时，达成数量级的吞吐量提升。

【本节要点】

• 状态通道的适用场景三约束：对手方固定、交互高频、金额适中。
• 比特币以闪电网络为主流二层支付网络；以太坊则更依赖 Rollup，状态通道为补充。
• 状态通道与侧链的关键区别在于：状态通道的安全性由主链脚本/合约保障，侧链则由独立共识保障。