撰文：Beosin
Bitcoin（BTC）作为全球首个加密货币，自 2009 年问世以来，逐渐成为数字资产和去中心化金融的基石。然而，随着用户数量和交易量的增加，BTC 网络的问题日益显现，主要表现为以下几点：
- 高交易费用：当比特币网络拥堵时，用户需要支付更高的费用以确保交易能尽快被确认。
- 交易确认时间：比特币区块链平均每 10 分钟生成一个新区块，这意味着链上交易通常需要等待多个区块确认才能被视为最终确认。
- 智能合约的局限性：比特币的脚本语言功能有限，难以实现复杂的智能合约。
本文中，我们将闪电网络（Lightning Network）、侧链（Sidechains）、Rollup 等技术统称为 BTC Layer2 扩容解决方案，它们在实现快速、低费用交易的同时，保持了 BTC 网络的去中心化和安全性。Layer2 技术的引入可以提升交易速度和降低交易成本，优化用户体验和扩展网络容量，为 BTC 的未来发展提供了重要的技术支持和创新方向。
闪电网络
闪电网络最早的概念叫「支付通道」，其设计思路是通过交易替换的方式不断更新未确认的交易状态，直到最终将其广播到比特币网络上为止。中本聪在 2009 年创造比特币时，就已经提出了支付通道的想法，并在 Bitcoin 1.0 中包含了支付通道的代码草稿，这一草稿允许用户在交易被网络确认之前更新交易状态。然而，直到《The Bitcoin Lightning Network: Scalable Off-Chain Instant Payment》白皮书的发布，闪电网络才真正诞生并进入大众视野。
如今，支付通道和闪电网络的实现方案已经非常成熟。截至目前，闪电网络共有 13,325 个节点，49,417 条通道，总质押的 BTC 数量达到 4,975。
https://1ml.com/
在闪电网络中，保证用户资产在转移过程中的安全性是十分重要的。下面将根据网络节点的规模阐述闪电网络是如何运作以及如何保护用户资产安全性。
双方用户向比特币主网提交两笔交易：一笔用于开启通道，一笔用于关闭通道。大致分为以下三步：
1. 通道开启：
首先，参与双方用户将比特币质押到闪电网络在 BTC 上的多重签名钱包中。一旦比特币被成功质押并锁定，支付通道即开启，双方可以在此通道中进行链下交易。
2. 链下交易：
一旦通道开启，用户之间的所有转账交易都将在闪电网络中进行处理，并且这些链下交易不受次数限制。当然，这些交易不需要立即提交到比特币主网，而是通过闪电网络的链下机制即时完成。
这种链下处理方式显著提高了交易速度和效率，避免了比特币主网的拥堵和高额交易费用。
3. 通道关闭与账本结算：
当任意一方的用户决定退出通道时，将进行最终的账本结算。这一过程确保通道中的所有资金按最新状态进行分配。同时，双方用户将从多重签名钱包中提取结算后的余额，该余额反映了通道关闭时的实际资金分配。最终，通道会将最终状态的账本交易提交到比特币主网。
闪电网络的优势在于：
- 交易速度提升。闪电网络允许用户在链下进行交易，这意味着交易可以在几乎瞬间完成，不需要等待区块确认时间。这样可以实现秒级别的交易速度，极大提升了用户体验。
- 隐私性增强。闪电网络的链下交易不需要在比特币主链上公开记录，这提高了交易的隐私性。只有通道的开启和关闭需要在主链上记录，因此用户的交易行为不会完全公开。
- 微支付支持。闪电网络非常适合处理小额支付（微支付），如内容付费、物联网设备支付等。传统的比特币交易因手续费较高，不适合频繁的小额支付，而闪电网络则解决了这个问题。
闪电网络面临的挑战：
- 网络流动性问题：闪电网络依赖于预先在通道中锁定的比特币。这意味着用户必须提前在他们的支付通道中存入足够的比特币，以便进行交易。流动性不足可能导致支付失败，特别是在较大的支付时。
- 路由问题：找到从支付发送方到接收方的有效路径可能是一个复杂的问题，尤其是在网络规模较大的情况下。随着网络节点和通道的增加，确保支付顺利完成的难度也增加。
- 资金托管信任问题：节点可能会遇到恶意攻击，用户需要信任他们所连接的节点不会试图窃取资金。节点是否可以防止私钥泄露
- 技术标准和互操作性：不同的闪电网络实现之间需要有一致的技术标准和协议，以确保互操作性。目前，多个开发团队在开发闪电网络的不同实现，这可能导致兼容性问题。
- 隐私问题：虽然闪电网络提高了比特币交易的隐私性，但交易信息仍可能被追踪或分析。此外，网络节点运营者可以看到通过其节点的交易，从而可能泄露某些隐私信息。
闪电网络的安全性直接影响比特币的链下扩展能力和用户资金的安全。因此除了公链的通用审计项（具体见本文末尾附录）以外，闪电网络还需要关注以下重要安全风险点：
- 通道拥堵：检查闪电网络系统的设计的全面性，是否会因为悲伤攻击导致通道拥堵。
- 通道干扰：检查闪电网络通道结构的安全性，是否会遭受通道干扰攻击。
- 通道资产锁定与解锁：审查闪电网络中资产锁定和解锁的过程，确保在开通或关闭支付通道时，资金在链上和链下的转移是安全和可靠的。
- 状态更新与关闭：评估通道的状态更新流程和强制关闭（force-close）机制，确保在出现异常情况时，能够正确识别并执行最新状态。
- 时间锁与哈希锁合约（HTLC）：评估 HTLC 的实施，确保时间锁和哈希锁条件能够正确执行，防止因时间窗口问题导致的资金损失。
- 区块链时间戳依赖：评估闪电网络对比特币区块链时间戳的依赖性，确保链上和链下时间能够正确协调，防止时间攻击。
- 路由算法安全：检查路由算法的效率和安全性，防止用户隐私暴露和恶意路由操控风险。
- 通道存储与数据恢复：检查通道的存储机制和数据恢复策略，确保在节点故障或意外断线时能够恢复通道状态，避免资金丢失。
侧链
与闪电网络不同，侧链（Sidechain）是一种独立的区块链，与主链（如 BTC 区块链）平行运行，并通过双向锚定（Two-Way Peg）与主链进行互操作。侧链的目的是在不改变主链协议的前提下，实现更多功能和提高扩展性。
侧链作为独立的区块链，拥有自己的共识机制、节点和交易处理规则。它可以根据特定应用场景的需求，采用不同于主链的技术和协议。通过双向锚定机制（2WP），侧链与主链实现通信，确保资产在两者之间自由、安全地转移。双向锚定机制（2WP）运行机制大致如下：
- 用户在主链上锁定 BTC，受信任的机构 1 获取并使用 SPV 验证 2 确保用户锁定交易的是否确认。
- 受信任机构会在侧链上发行等值的代币给用户。
- 用户在自由交易过后，在侧链上锁定剩余的代币。
- 受信任的机构在验证交易合法性过后，于主链解锁并释放相应价值的 BTC 给用户。
注 1: 受信任的机构在双向锚定机制中扮演关键角色，负责管理资产的锁定和释放。这些机构需要具有高度的信誉和技术能力，以确保用户资产的安全。
注 2: SPV 验证允许节点在不下载完整区块链的情况下，验证特定交易的有效性。SPV 节点只需下载区块头，并通过 Merkle Tree 验证交易是否包含在区块中。
侧链的代表性项目：
CKB（Nervos Network）
Nervos Network 是一个开源的公共区块链生态系统，旨在利用 BTC 的 POW 共识机制的安全性和去中心化优势，同时引入更具可扩展性和灵活性的 UTXO 模型来处理交易。其核心为 Common Knowledge Base（CKB），是基于 RISC-V 构建，使用 PoW（工作量证明）作为共识的 Layer 1 区块链。其将 UTXO 模型拓展为 Cell 模型，使其可存储任何数据，支持任何语言编写脚本从而作为智能合约在链上执行。
Stacks
Stacks 通过其 PoX（Proof of Transfer）机制，将每个 Stacks 区块与比特币区块连接。为了开发智能合约，Stacks 设计了专门的 Clarity 编程语言。在 Clarity 中，get-burn-block-info? 函数允许传入比特币区块高度并获取该区块的头部哈希。同时，burn-block-height 关键字能够获取比特币链的当前区块高度。这两个功能使得 Clarity 智能合约能够读取比特币基础链的状态，从而使比特币交易可以作为合约触发器。通过自动执行这些智能合约，Stacks 扩展了比特币的功能。
有关 Stacks 的详细分析，可阅读 Beosin 之前的研究文章：《什么是 Stacks？BTC 二层网络 Stacks 可能面临哪些挑战？》
侧链的优势在于：
- 侧链可以采用不同的技术和协议，进行各种实验和创新，而不会影响主链的稳定性和安全性。
- 侧链可以引入主链不具备的功能，例如智能合约、隐私保护、代币发行等，丰富区块链生态系统的应用场景。
侧链面临的挑战：
- 侧链具有独立的共识机制，可能不如 BTC 主链那样安全。如果侧链的共识机制较弱或存在漏洞，可能会导致 51% 攻击或其他形式的攻击，影响用户资产的安全。BTC 主链的安全性依赖于其庞大的算力和广泛的节点分布，而侧链可能无法达到同样的安全标准。
- 双向锚定机制的实现需要复杂的加密算法和协议，如果其中存在漏洞，可能导致主链和侧链之间的资产转移出现问题，甚至可能导致资产丢失或被盗。
- 为了在速度和安全之间找到平衡，大多数侧链的中心化程度比主链更高。
Layer2 是一个完整的区块链系统，因此公链的通用审计项也适用于侧链，具体见本文末尾附录。
此外，由于其特殊性，侧链还需要进行一些额外的审计：
- 共识协议安全性：审查侧链的共识协议（如 PoW、PoS、DPoS）是否经过充分验证和测试，是否存在潜在的漏洞或攻击向量，如 51% 攻击、长程攻击等。
- 共识节点安全性：评估共识节点的安全性，包括密钥管理、节点防护和冗余备份，防止节点被攻破或滥用。
- 资产锁定与释放：审查侧链与主链之间的资产双向锚定机制，确保锁定和释放资产的智能合约是安全可靠的，防止出现双花、资产丢失或锁定失败的情况。
- 跨链验证：检查跨链验证的准确性和安全性，确保验证过程是去中心化和防篡改的，防止验证失败或恶意验证。
- 合约代码审计：深入审计侧链上运行的所有智能合约，检测可能存在的漏洞或后门，尤其是在处理跨链操作时的合约逻辑。
- 升级机制：检查智能合约的升级机制是否安全，是否有适当的审计和社区共识流程，防止恶意升级或合约篡改。
- 节点间通信：检查侧链节点之间的通信协议是否安全，是否使用加密通道防止中间人攻击或数据泄露。
- 跨链通信：检查侧链与主链之间的通信通道，确保数据的完整性和真实性，防止通信被劫持或篡改。
- 时间戳与区块时间：验证侧链的时间同步机制，确保区块生成时间的一致性和准确性，防止时间差导致的攻击或区块回滚。
- 链上治理安全性：审查侧链的治理机制，确保投票、提案和决策过程的透明性和安全性，防止恶意控制或攻击。
- 代币经济审计：检查侧链的代币经济模型，包括代币分配、激励机制和通胀模型，确保经济激励不会导致恶意行为或系统不稳定。
- 费用机制：检查侧链的交易费用机制，确保其与主链和侧链用户的需求匹配，防止费用操控或网络拥堵。
- 资产安全性：审计链上资产的管理机制，确保资产的存储、转移和销毁过程安全可靠，不存在未授权访问或盗窃的风险。
- 密钥管理：检查侧链的密钥管理策略，确保私钥的安全性和访问控制，防止密钥泄露或被盗用。
Rollup
Rollup 是一种 Layer2 扩展解决方案，旨在提高区块链的交易吞吐量和效率。它通过将大量交易打包（「Rollup」）并在链下处理，只将最终结果提交到主链，从而大幅减少主链的负担。
Rollup 主要分为 zk-Rollup 和 op-Rollup。但是与 ETH 不同的是，由于 BTC 的图灵不完备性，无法在 BTC 上使用合约进行零知识证明验证。传统的 zk-Rollup 解决方案无法在 BTC 上进行实现。那么如何使用 zk-Rollup 实现 BTC Layer2？接下来以 B² Network 项目为例：
为了在 BTC 上完成零知识证明验证，B² Network 创建了 Taproot 脚本，其同时结合了 zk-Rollup 的零知识证明验证以及 op-Rollup 的激励挑战。其运行机制大致如下：
- B² Network 首先将所有用户发起的交易进行 Rollup。
- 使用排序器对 Rollup 交易排序后，将 Rollup 交易使用去中心化存储进行保存并同时交由 zkEVM 进行处理。
- zkEVM 同步 BTC 链状态后，处理合约执行等交易，将结果合并打包发送到聚合器。
- Prover 生成零知识证明并发送到聚合器，经聚合器聚合交易以及证明发送到 B² Nodes。
- B² Nodes 进行零知识证明的验证并根据去中心化存储里的 Rollup 数据创建 Taproot 脚本。
- Taproot 是一个 value 为 1 satoshi 的 UTXO，其数据结构中的 B² Inscription 存储了所有的 Rollup 数据，Tapleaf 中存储了所有的证明的 verify 数据。通过激励挑战机制后，其将作为基于 zk 证明验证的承诺被发送到 BTC。
Rollup 的优势在于：
- Rollup 继承了主链的安全性和去中心化特性。通过定期将交易数据和状态提交到主链，确保了数据的完整性和透明性。
- Rollup 能够无缝集成到现有区块链网络中，如以太坊，使开发者可以轻松利用其优势，而无需大幅修改现有的智能合约和应用。
- Rollup 通过将大量交易在链下处理并打包成一个批次提交到主链，大幅提升了交易处理能力，使得每秒交易数量（TPS）显著增加。
- Rollup 交易只需在链下处理，大幅减少了链上交易所需的计算资源和存储空间，从而显著降低了用户的交易费用。
Rollup 面临的挑战：
- 如果链下数据不可用，用户可能无法验证交易和恢复状态。
- Rollup 交易需要批量处理并最终提交到主链，可能会导致结算时间较长。尤其在 op-Rollup 中，存在争议期，用户可能需要等待较长时间才能最终确认交易。
- ZK Rollup 虽然提供更高的安全性和即时确认，但其计算和存储需求较高，生成零知识证明需要大量的计算资源。
由于采用的方案为 Rollup，其重点安全审计项与 ETH Layer2 基本一致。
其他（Babylon）
除了传统的 BTC Layer2 以外，近来还有一些全新概念的与 BTC 生态相关的第三方协议，例如 Babylon：
Babylon 的目标是将 2100 万 BTC 转化为去中心化的质押资产。不像 BTC 的其它 Layer2，Babylon 没有对 BTC 链扩容。其本身是一条独特的链，具有特殊的 BTC 抵押协议，主要目的是为了和 PoS 链对接，抵押 BTC 为 PoS 链提供更强的安全性，解决诸如来自链中远端的攻击风险和中心化的问题。
架构分为三层：
- 比特币层：这是 Babylon 的坚实基础，利用比特币众所周知的安全性来确保所有交易都超级安全，就像在比特币网络上一样。
- 巴比伦层：Babylon 的核心是 Babylon 层，这是一个将比特币与各种权益证明（PoS）链连接起来的定制区块链。它处理交易，运行智能合约，并确保整个生态系统中的一切都顺利进行。
- PoS 链层：顶层由多个 PoS 链组成，每个 PoS 链都因其独特的优势而被选中。这赋予了 BabylonChain 惊人的可扩展性和灵活性，让用户可以享受不同 PoS 区块链的最佳功能。
运作方式是使用在 BTC 链上签署最终的区块来保护 PoS 链。这实质上是通过额外的签名轮次扩展了基础协议。最后 +1 轮中的这些签名具有一个独特的特征：它们是可提取的一次性签名（EOTS）。目的是把 PoS 检查点集成到 BTC 上，解决 PoS 的长时间解绑期和远程攻击问题。
Babylon 的优势在于：
- 使 PoS 的解绑期变快
- 由于质押了 BTC，价格与 BTC 挂钩，能够减轻对应 PoS 网络的通胀压力
- 为 BTC 收益开启了新的途径
Babylon 面临的挑战：
- 质押回报率等经济设计对 BTC 质押积极性影响较大
- 缺乏 PoS 链之间的奖励一致性规定
第三方协议根据其实现的不同，所关注的安全点也不一致，仅以 Babylon 为例，需要注意的部分安全审计项如下：
- 智能合约安全：BTC 上的质押合约通过 UTXO 脚本实现，需要关注其安全性。
- 签名算法安全：合约中使用签名管理用户的质押，其算法安全性关系到签名的生成与校验。
- 协议经济模型设计：协议的经济模型在奖励和惩罚等方面是否设置合理，是否会导致用户资产损失。
附录：
公链 & Layer2 通用审计项
- 整数溢出：检查整数上溢和整数下溢
- 死循环：检查程序的循环判断条件是否合理
- 无限递归调用：检查程序递归调用的退出条件是否合理
- 竞争条件：检查在并发状态下，对共享资源的访问操作
- 异常崩溃：检查能让程序主动退出的异常抛出代码
- 除 0 漏洞：检查是否有除以 0 的情况
- 类型转换：检查类型转换是否正确，转换过程中是否丢失重要信息
- 数组越界：检查是否访问超出数组界限的元素
- 反序列化漏洞：检查反序列化过程中有没有问题
- 功能实现安全：检查各 RPC 接口实现是否存在安全隐患，是否与 RPC 接口功
- 能设计相符
- 敏感 RPC 接口权限设置是否合理：检查敏感 RPC 接口的访问权限设置
- 加密传输机制：检查是否用加密传输协议，比如 TLS 等
- 请求数据格式解析：检查对请求数据的格式解析过程
- 钱包解锁攻击：节点解锁其钱包的时候，被 RPC 请求窃取资金
- 传统 Web 安全：检查是否存在以下漏洞：跨站点脚本 （XSS） / 模板注入 /
- 第三方组件漏洞 / HTTP 参数污染 / SQL 注入 / XXE 实体注入 / 反序列
- 化漏洞 / SSRF 漏洞 / 代码注入 / 本地文件包含 / 远程文件包含 / 命令执行注入等传统漏洞
- 网络节点身份认证和识别机制：检查是否存在节点身份识别机制，节点身份识别机制能否被绕
- 路由表污染：检查路由表是否能够被随意插入或覆盖数据
- 节点发现算法：检查节点发现算法是否均衡且不可预测，比如距离算法不平衡等问题
- 连接数占用审计：检查 p2p 网络连接节点数的限制和管理是否合理
- 日蚀攻击：评估日食攻击的成本与危害，必要时提供量化分析
- 女巫攻击：评估投票共识机制，分析投票资格检查策略
- 窃听攻击：检查通信协议是否泄露隐私
- 异形攻击：评估节点是否能识别同类链节点
- 时间劫持：检查节点的网络时间计算机制
- 内存耗尽攻击：检查大内存消耗的地方
- 硬盘耗尽攻击：检查大文件存储的地方
- socket 压力攻击：检查链接数量的限制策略
- 内核句柄耗尽攻击：检查内核句柄创建的限制，比如文件句柄等
- 持续性的内存泄露：检查内存泄露的地方
- 哈希算法安全性：检查哈希算法的抗碰撞性
- 数字签名算法安全性：检查签名算法安全性，算法实现的安全性
- 加密算法安全性：检查加密算法安全性，算法实现的安全性
- 随机数生成器安全性：检查关键随机数生成算法是否合理
- BFT 实现安全：评估 BFT 算法的实现安全性
- 分叉选择规则：检查分叉选择规则以确保安全性
- 中心化程度检测：鉴别系统设计中是否存在过度中心化设计
- 激励机制审计：评估激励机制对安全性的影响
- 双花攻击：检查共识是否可以防御双花攻击
- MEV 攻击审计：检查区块打包节点的 MEV 对链公平的影响
- 区块同步过程审计：检查同步过程中的安全问题
- 区块格式解析过程审计：检查格式解析过程中的安全问题，比如解析错误导致奔溃
- 区块生成过程审计：检查区块生成过程中的安全问题，包括 Merkle tree root 构建方式是否合理
- 区块校验过程审计：检查区块签名内容项及验证逻辑是否充分
- 区块确认逻辑审计：检查区块确认算法及实现是否合理
- 区块哈希碰撞：检查区块哈希碰撞的构造方式，及碰撞时的处理是否合理
- 区块处理资源限制：检查孤儿区块池、验证计算、硬盘寻址等资源限制是否合理
- 交易同步过程审计：检查同步过程中的安全问题
- 交易哈希碰撞：检查交易哈希碰撞的构造方式，及碰撞时的处理
- 交易格式解析：检查格式解析过程中的安全问题，比如解析错误导致奔溃
- 交易合法性校验：检查各类型交易签名内容项及验证逻辑是否充分
- 交易处理资源限制：检查交易池、验证计算、硬盘寻址等资源限制是否合理
- 交易延展性攻击：交易是否可以改变内部字段 ( 比如 ScriptSig) 从而改变交易 hash 而不影响交易的有效性
- 交易重放攻击审计：检查系统对交易重放的检测
- 合约字节码校验：检查虚拟机校验合约的过程的安全问题，比如整数溢出、死循环等
- 合约字节码执行：检查虚拟机执行字节码的过程的安全问题，比如整数溢出、死循环等
- gas 模型：检查交易处理 / 合约执行的各原子操作对应的手续费是否与资源消耗成正比
- 日志记录的完整性：检查关键信息是否被日志记录
- 日志记录的安全性：检查处理日志的过程中，是否因处理不当造成安全问题，比如整数溢出等
- 日志包含隐私信息：检查日志是否包含密钥等隐私信息
- 日志存储：检查日志是否记录过多内容，导致节点资源消耗
- 节点代码供应链安全：检查所有第三方库、组件及公链框架对应版本的已知问题
