撰文：Chakra Research
除了第一辑所提到的原生扩容方案，比特币的另一类扩容之路采用的是在比特币之上额外建立一层协议，称之为 Layer 2。Layer 2 方案最关键的有两点，安全的双向桥接与继承比特币的共识安全性。
侧链（Sidechain）
侧链概念的起源最早可以追溯到 2014 年 blockStream 提交的《Enabling Blockchain Innovations with Pegged Sidechain》，是一种较为朴素的扩容方案。
工作原理
侧链是与主链完全独立运行的区块链，有自己的共识协议，可以作为主链创新的实验场。当侧链发生恶性事件时，损害完全局限于侧链本身，对主链不产生任何影响。侧链可以使用 TPS 更高的共识协议，增加链上的编程能力，实现 BTC 的增强。
侧链可以通过 two-way peg 或 one-way peg 去实现比特币在不同区块链之间的转移，当然实际上 BTC 只能停留在 Bitcoin 网络上，所以我们需要一种锚定机制来使得侧链中的 BTC 与 Bitcoin 网络的 BTC 产生联系。
one-way peg 要求用户将主网上的 BTC 发送到不可用的地址进行销毁，随后将在侧链上得到对应数量的 BTC，但是过程无法反转。two-way peg 是对 one-way peg 的进一步升级，让 BTC 能够在主链与侧链之间来回移动。与发送到不可用地址销毁不同，two-way peg 会将 BTC 通过多签等控制脚本进行锁定，在侧链上铸造新的 BTC。当用户想要回到主网，则将侧链上的 BTC burn 掉，在主网释放原先锁定的 B TC。
one-way peg 的实现与 two-way peg 相比，要简单得多，因为无需管理 Bitcoin 网络上的相关状态，但是通过 one-way peg 生成的侧链资产，可能一文不值，因为缺乏反向的锚定机制。
对于主链的锁定交易与侧链上的销毁交易的验证，有不同的方案与不同的安全等级。最简单的是采用多签参与者的外部验证，但是中心化风险较高，更优的选择是采用 SPV Proof 实现去中心化的验证。当然，由于比特币主网缺乏必要的编程能力，无法进行 SPV 验证，只能选取其他方式，通常是多签托管。
问题与思路
侧链为人所诟病的问题主要有两点：
资产跨链对验证者的依赖：由于比特币主网尚且无法实现智能合约，无法通过去信任的合约逻辑来处理资产的跨链转移，从侧链跨回比特币时，需要依赖一组验证人完成操作，存在信任假设，有欺诈风险。
侧链无法继承主链安全性：侧链完全独立于主网运行，无法继承主网的安全性，可能发生恶意区块重组等事件。
对此，侧链的思路包括依赖权威（联盟型）、依赖经济安全（PoS）、依赖去中心化的比特币矿工（Merged Mining）、依赖硬件安全模块（HSM），Bitcoin 上的资金托管与侧链的区块生产可以由不同角色负责，进而引入更复杂的安全机制。
案例介绍
Liquid
最初出现的侧链形式是联盟侧链，由事先选取的多个实体担任验证者，同时负责主网资金的托管与侧链的出块。
Liquid 是联盟侧链的代表，由 15 个参与方担任验证者，不公开私钥管理方式，验证通过需要 11 个签名。Liquid 侧链上的出块也由 15 个参与方共同维护，低节点数的联盟链能够实现较高的 TPS，达成扩容目标，主要的应用范围是 DeFi。
联盟侧链的方式具有显著的中心化安全风险。
Rootstock (RSK)
RSK 也由 15 个节点担任主网资金托管方，验证通过仅需 8 个签名。与 Liquid 的区别在于，多签密钥交由硬件安全模块 HSM 管理，根据 PoW 共识签署 peg-out 指令，防止持有密钥的验证人直接操纵托管资金。
在侧链共识方面，RSK 采用 Merged Mining，借助主网算力来保障侧链上交易的安全性，当合并挖矿算力比例占主网比例较高时，可以较好地防止侧链上的双花攻击。RSK 对 Merged Mining 做出了改进，以保障低哈希率下侧链的安全性，采用分叉感知型方法，对分叉行为进行链下共识干预，降低双花几率。
然而，Merged Mining 使得矿工的激励发生变化，并且加剧了 MEV 的风险，最终可能动摇系统的稳定性。长远来看，Merged Mining 可能会增加挖矿的中心化。
Stacks
Stacks 通过将侧链的区块哈希提交至比特币区块中，将 Stacks 链历史锚定到比特币，拥有了比特币相同的 Finality，Stacks 的分叉只能由 Bitcoin 的分叉引起，提升了抗双花能力。
sBTC 引入了新的代币 STX 与激励模型，采用质押桥方式，允许最多 150 个主网验证者。所谓质押桥，验证者需要质押 STX 代币以获取批准存款与取款的权限。质押桥的安全性严重依赖于质押资产的价值，在质押资产价值剧烈波动时，BTC 跨链的安全性容易受损。如果质押资产的价值低于跨链资产的价值，则验证者有作恶的动机。
还有一些侧链提案正在社区中被广泛讨论。
Drivechain
最受关注的是 Paul Sztorc 在 2015 年提出的 Drivechain，方案中的关键技术已经被分配 BIP 300（挂钩机制） 与 BIP 301（盲合并挖矿）。BIP 300 详细定义了新增一条侧链的逻辑，激活新侧链与通过矿工信号激活软分叉类似。BIP 301 让比特币矿工在无需验证具体交易内容的情况下，成为侧链的区块生产者。
比特币矿工同时负责取款交易的批准，矿工首先需要在自己所挖出块的 coinbase 交易中创建一个 OP_RETURN 输出，来提议一笔提款交易，之后各矿工可以对该提议进行表决，每个块挖出时都可以对提议提支持或反对票。一旦一笔提款交易超过阈值（13150 个区块），提款交易正式执行，获得比特币主链确认。
实际上，矿工完全控制着 Drivechain 上的资金，如果出现资金被盗事件，用户只能通过 UASF （用户激活的软分叉）来自救，但这非常难达成共识。此外，Drivechain 中矿工的独特地位加剧了 MEV 的风险，这已经在以太坊中验证过了。
Spacechain
Spacechain 另辟蹊径，使用 Perpetual 1 way peg（P1WP），用户燃烧 BTC 以获得 Spacechain 上的 token，直接跳过了资金安全问题。该 token 只能用于拍卖 spacechain 上的 block space，而不存在任何价值存储作用。
为保证侧链的安全，Spacechain 采用盲合并挖矿，由其他用户使用 ANYPREVOUT（APO）公开出价竞争构建区块的权利，比特币矿工只需在区块中承诺 Spacechain 的区块头，无需验证侧链区块。不过，Spacechain 的启动需要 Covanent 的支持，现在比特币社区仍在讨论软分叉添加 Covanent 操作码的必要性。
总的来讲，Spacechain 通过比特币上竞拍出块的功能，能够实现一个拥有比特币相同的去中心化与抗审查属性，与更多可编程性的侧链。
Softchain
Softchain 是 Spacechain 作者 Ruben Somsen 提出的 2wp 侧链提案，使用 PoW FP 共识机制来保障侧链的安全性。在一般的情况下，比特币的全节点只需要下载 softchain 的区块头，验证工作量证明。当出现分叉时，下载孤块与对应的 UTXO 集合承诺，验证区块的有效性。
对于 2wp 机制，peg-in 时在主链上创建一个存款交易，softchain 上引用该主链交易来获取资金；peg-out 时则在 softchain 创建一个提款交易，主链上引用该交易来取回 BTC，而取款过程需要等待一个很长的挑战期过后，才能够完成。具体的 peg-in，peg-out 机制需要软分叉支持，因此该方案被称为 Softchain。
Softchain 方案对比特币主网的全节点造成了额外的验证成本，Softchain 的共识分裂有可能影响主网共识的达成，成为比特币主网的可能攻击手段。
闪电网络（Lightning Network）
闪电网络于 2015 年发布白皮书，2018 年正式上线，作为比特币上的 Layer2 p2p 支付协议，旨在将大量小额、高频的交易转移到链下处理，长时间内被认为是比特币网络最 promising 的扩容方案。
核心模块
Lightning Network 的实现，离不开比特币中几个重要的模块，它们共同保障了闪电网络交易的安全性。
首先是预签名交易。预签名交易是在 SegWit 升级之后才变得安全可用的。SegWit 将签名与其余交易数据分离，解决了潜在的循环依赖、第三方交易篡改、第二方交易篡改等问题。闪电网络链下计算安全性的保障，是通过对方给出的不可撤销的承诺保障的，而该承诺是通过预签名交易来实现的。收到对方给出的预签名交易后，用户可以随时将该交易广播至链上，完成承诺的兑现。
其次是多重签名。双方进行链下资金的频繁转移，需要一个载体，这个载体需要两方都保有一定的控制权，所以需要多重签名，一般使用 2/2 多签，这保证资金的转移必须在双方的共同同意下才能进行。
但是 2/2 多重签名会产生活性问题，即对方不配合的情况下，用户无法从多签地址中转移任何资产，导致原有资金的损失。时间锁能够解决活性问题，通过预先签署一个带时间锁的返还资金的合约，能够保证即使在一方失活的情况下，另一方也能够收回初始资金。
最后是哈希锁，能够为起到连接多个状态通道，构建网络的效果，哈希的原象将作为沟通媒介，协调多个实体间的正确运行。
运行流程
双向通道
使用闪电网络进行交易的双方首先需要在比特币上打开一个双向的支付通道，双方可以在链下进行任意数量的交易，待所有交易完成后，提交最新状态至比特币链上完成结算，关闭支付通道。
具体来说,支付通道的实现涉及以下几个关键步骤:
创建多签地址。通道的双方首先需要创建一个 2-of-2 的多签地址,作为通道的资金锁定地址。双方各自持有一个签名私钥,同时提供自己的公钥。
初始化通道。双方在链上广播一笔交易,将一定数量的比特币锁定到多签地址中,作为通道的初始资金。这笔交易被称为通道的「锚点」交易。
更新通道状态。在通道内进行支付时,双方通过交换预签名交易的方式更新通道的状态。每次更新都会生成一个新的「承诺交易」,代表当前的资金分配状态。承诺交易有两个输出,分别对应双方的资金份额。
广播最新状态。通道的任何一方都可以随时将最新的承诺交易广播到区块链上,以提取自己的资金份额。为了防止对方广播旧的状态,每个承诺交易都有一个相应的「惩罚交易」,如果对方作弊,自己就可以获得对方的全部资金。
关闭通道。当双方决定关闭通道时,他们可以合作生成一个「结算交易」,将最终的资金分配状态广播到区块链上。这样,锁定在多签地址中的资金就被释放回双方的个人地址。
链上仲裁。如果双方在关闭通道时无法达成一致,任何一方都可以单方面广播最新的承诺交易,启动链上仲裁流程。如果在一定时间内 ( 如 1 天 ) 没有异议,资金就会按照承诺交易的分配发送给双方。
支付网络
支付通道之间可以彼此连接成为网络，支持多跳路由，通过 HTLC 实现。HTLC 是以哈希锁作为直接条件，带时间锁的签名支付作为后备条件，在时间锁到期之前用户间可以围绕哈希的原像进行交互。
当两个用户间没有直接通道时，可以借助路由间的 HTLC 完成支付。整个过程中哈希原像 R 起到了关键的纽带作用，确保了支付的原子性。同时，HTLC 的时间锁设置为沿途递减，确保每一跳都有足够的时间来处理和转发支付。
存在的问题
从本质上讲，闪电网络通过 p2p 的状态通道规避了资产桥接的外部信任假设，同时利用时间锁脚本提供了资产的最终保障，能够提供故障保护。在对方失去活性不配合的情况下，可以完成单方面的退出。因此，闪电网络在支付场景有很高的使用价值，但同时也存在许多局限性，主要包括：
通道容量限制。闪电网络中的支付通道容量受到初始锁定资金的限制，无法支持超过通道容量的大额支付。这可能限制了某些应用场景，如大宗商品交易等。
在线与同步。为了及时接收和转发支付，闪电网络的节点需要保持在线状态。如果节点长时间离线，可能错过一些通道状态更新，导致状态不同步。这对于个人用户和移动设备来说可能是一个挑战，也增加了节点运营的成本。
流动性管理。闪电网络的路由效率依赖于通道的流动性分布。如果资金分布不均衡，可能导致一些支付路径失效，影响用户体验。管理通道的流动性平衡需要一定的技术和资金成本。
隐私泄露。为了找到可用的支付路径，闪电网络的路由算法需要一定程度地了解通道的容量和连通性信息。这可能泄露一些用户的隐私，如资金分布、交易对手等。支付通道的开启与关闭也可能暴露出相关参与者的信息。
RGB
RGB 协议的最初构想受到 Peter Todd 提出的客户端验证与一次性密封概念启发，于 2016 年由 Giacomo Zucco 提出，是一种可拓展、保护隐私的比特币二层协议。
核心思想
客户端验证
区块链的验证过程，是将由交易组成的区块向全体广播，让每个节点都计算区块中的交易，完成验证。这实际上造就了一种公共物品，即全网的节点帮助每个提交交易的个人完成了验证，而用户提供 BTC 作为手续费作为帮助验证的激励。客户端验证更加以个体为中心，状态验证不由全局执行，而是由参与特定状态转换的个体作为验证，只有在产生交易的各方各自验证状态转换的有效性，这显著提升了隐私，也减轻了节点的负担，提高了可拓展性。
一次性密封
点对点的状态转换存在一种隐患，用户收集不到完整的状态转换历史，就可能被欺诈，出现双重花费的情况。一次性密封是为了解决该问题所提出的，通过一个特殊的仅能够被使用一次的对象，确保双花情况不发生，提高安全性。比特币的 UTXO 就是最合适的一次性密封对象，由比特币的共识机制与全网算力保证，因此 RGB 资产能够继承比特币的安全性。
加密承诺
一次性密封需要与加密承诺结合起来，才能够保证用户明确状态转换的发生，避免双花攻击的出现。所谓承诺，就是向他人告知某件事已经发生，且之后无法修改，但是不需要暴露具体的事件，直到需要验证的时刻，我们可以使用哈希函数来进行承诺。在 RGB 中，承诺的内容就是状态的转换，通过 UTXO 的花费，RGB 资产的接受方会收到状态转移的信号，进而再通过资产的花费方在链下传送的具体数据对照承诺进行验证。
工作流程
RGB 利用比特币的共识保障双花安全性与抗审查行，而所以状态转移的验证工作都移交至链下，仅由接受支付的客户端进行验证。
对于 RGB 资产的发行方，需要通过发起一笔交易来创建 RGB 合约，其中的具体信息的承诺会存储在 Taproot 交易中某个支出条件的 OP_RETURN 脚本中。
当 RGB 资产的持有者想要进行花费时，需要从资产的接收者获取相关信息，创建一笔 RGB 交易，并将该 RGB 交易的详情进行承诺，将承诺值放置进资产接收者指定的 UTXO 中，并发出一笔交易，花费原先的 UTXO 并创建接收方指定的 UTXO。当资产的接收者观察到原先存储 RGB 资产的 UTXO 被花费，就可以通过比特币交易中的承诺验证 RGB 交易的有效性，一旦验证有效，则认为自己确实接收到了 RGB 资产。
对于 RGB 资产的接收者，需要由支付方提供合约的初始状态与状态转换规则、每次转移使用的比特币交易、每个比特币交易所承诺的 RGB 交易、以及每个比特币交易有效性的证据，由接收者的客户端根据这些数据验证验证 RGB 交易的有效性。其中，比特币的 UTXO 作为容器，保存着 RGB 合约的状态，每个 RGB 合约的转移历史都可以表示为一个有向无环图，RGB 资产的接收者只能获取与自己持有 RGB 资产有关的历史，而无法获取其他的分支。
优势与不足
轻量化验证
与区块链的完整验证相比，RGB 协议大幅降低了验证的成本，用户无需遍历所有的历史区块来获取到最新状态，而只需同步与自己接收资产相关的历史记录，即可验证交易的有效性。
这种轻量化的验证使得点对点的交易更加容易，进一步摆脱了对中心化服务提供商的需求，提高了去中心化水平。
可拓展性
RGB 协议仅需通过一个哈希的承诺来继承比特币的安全性，通过 Taproot 脚本的方式，几乎不产生额外比特币链上空间的消耗，这使得资产的复杂编程性成为可能。由于使用 UTXO 作为容器，RGB 协议在具备自然的并发性，不同转移分支上的 RGB 资产不会彼此阻塞，可以同时花费。
隐私性
不同于一般的协议，RGB 资产中只有资产的接收方能够获取到 RGB 资产的历史转移情况，一旦完成花费也无法获取未来的转移情况，这显著保证了用户的隐私性。RGB 资产的交易与比特币 UTXO 的转移也不存在关联，旁人无法在比特币链上获取到 RGB 交易的痕迹。
此外，RGB 还支持盲化支出，支付方也无法明确 RGB 资产会支付到哪个 UTXO 中，进一步提升了隐私性，也增强了抗审查能力。
不足
当 RGB 资产经历多次转手后，新接收资产的用户将被迫验证冗长的转移历史，导致较为沉重的验证负担，验证的时间可能较长，丧失了快速确认的能力。对于区块链中保持运行的节点而言，由于始终同步最新状态，每次收到新区快验证状态转移的时间反而是有限的。
社区正在讨论复用历史计算的可能，recursive ZK Proof 有机会实现恒定时间与大小的的状态验证。
卷叠（Rollup）
概述
Rollup 是以太坊生态在探索多年后得出的最佳扩容解决方案，从状态通道到 Plasma 最后演进到 Rollup。
Rollup 是一条独立的区块链，在比特币链外收集交易，将多笔交易打包成一个批次并执行，并将这个批次的数据与状态承诺提交到主链上，实现了链下交易处理和状态更新。为了最大程度实现扩容，Rollup 在现阶段通常采用中心化的排序器，提升执行效率，但同时不损失安全性，因为安全性是由主链上对 Rollup 状态转换的验证保证的。
随着以太坊生态 Rollup 方案的成熟，比特币生态也开始了对于 Rollup 的尝试。然而，比特币与以太坊最关键性的差异在于编程能力的不足，无法在链上进行构建 Rollup 所需的计算，这使得当前人们只能尝试实现主权 Rollup 与 OP Rollup。
分类
根据状态转移的验证方式不同，Rollup 可以分为两大类，Optimistic Rollup 与 Validity Rollup (ZK Rollup)。
Optimistic Rollup 采用乐观验证方式，每次交易批次提交后的争议期内，任何人都可以检查链下数据，对有问题的交易批次提出异议，提交欺诈证明到主链上，对 Sequencer 罚没。争议期过后如果没有有效的欺诈证明，则认为交易批次有效，状态更新在主链上被确认。
Validity Rollup 用 Validity Proof 完成验证，Sequencer 使用零知识证明算法为每个交易批次生成一个简洁的有效性证明，证明该批次的状态转移是正确的每次更新需要向主链提交交易批次的有效性证明，主链对证明进行验证后理解确认状态更新。
Optimistic Rollup 的优点是实现相对简单，对主链的修改较少。但它的交易确认时间较长 ( 取决于异议期 )，而且需要较高的数据可用性。Validity Rollup 交易确认快，不依赖异议期，而且交易数据可以保持隐私，但是生成和验证零知识证明需要较高的计算开销。
Celestia 还提出了一种主权 Rollup 的概念，Rollup 的交易数据发布到专门的 DA 层区块链，负责数据可用性，而主权 Rollup 本身负责执行与结算。
探索与讨论
比特币上的 Rollup 尚处于早期阶段，由于记账模型与编程语言上和以太坊的差异，很难直接照搬以太坊的实践经验，比特币社区正在积极探索创新的方案。
主权 Rollup
2023 年 3 月 5 日，Rollkit 宣布成为第一个支持比特币主权 Rollup 的框架，主权 Rollup 的构建者可以通过 Rollkit 在比特币上发布可用性数据。
Rollkit 受到 Ordinals 启发，通过 Taproot 交易来发布数据。一个通过公共内存池标准的 Taproot 交易可以包含最多 390 KB 的数据，由矿工直接发布的非标准 Taproot 交易可以包含接近 4 MB 的任意数据。
Rollkit 实际的工作是为主权 Rollup 提供了向比特币上读写数据的接口，为客户提供中间件服务，将比特币变为 DA 层。
主权 Rollup 的想法遭到了许多质疑，许多反对者声称比特币上的主权 Rollup 不过是将比特币作为公告板，完全无法继承比特币的安全性。事实上，如果仅向比特币提交交易数据，只能改善活性，即所有用户都能通过比特币获取到相应数据进行验证，而安全性只能由主权 Rollup 自己定义，无法继承。此外，比特币上的区块空间非常宝贵，提交全量的交易数据可能不是一个好的决定。
OP Rollup & Validity Rollup
尽管许多比特币二层项目称自己为 ZK Rollup，其本质上更接近一种 OP Rollup，只不过过程中涉及到 Validity Proof 技术，然而比特币的编程能力尚不足以支持直接的 Validity Proof 验证。
当前，比特币的操作码集合非常有限，甚至无法直接计算乘法，对 Validity Proof 的验证需要对操作码的扩充，也很大程度上依赖于递归契约的实现，社区正在热议的包括 OP_CAT, OP_CHECKSIG, OP_TXHASH 等。当然，如果能直接添加一个 OP_VERIFY_ZKP，也许我们不需要其他任何修改，但这显然不太可能。此外，对于堆栈大小的限制，也阻碍了在比特币脚本中验证 Validity Proof 的努力，许多尝试正在探索中。
所以 Validity Proof 如何工作？多数项目通过将交易批次的 statediff 与 Validity Proof 通过 铭刻的形式发布到比特币上，并采用 BitVM 进行乐观验证。BitVM 桥在这里取代传统的多签方案，桥的 Operator 会组成一个 N 人的联盟，对用户的存款进行调度。用户进行存款前，会要求联盟对即将生成的 UTXO 进行预签名，确保存款只能被其中的 Operator 合法地领取。获得预签名后，BTC 会被锁定到一个 N/N 多签的 Taproot 地址。
当用户发出提款请求，Rollup 会将带有 withdrawl Root 的 Validity Proof 发送到比特币链上，Operator 先自掏腰包满足用户的提款需求，之后通过 BitVM 合约验证有效性。如果每个 Operator 都认为证明有效，则通过多签对 Operator 给予报销；只要有任何人认为存在欺诈行为，会进行挑战流程，错误的一方会被 slash。
这个过程实际就与 OP Rollup 同出一辙，信任假设是 1/N，只要有一个验证者是诚实的，协议就是安全的。
不过，该方案的技术落地层面，可能存在难度。在以太坊的 OP Rollup 项目中，Arbitrum 经过了多年的开发，现在的 Fraud Proof 仍为许可制节点提交；Optimism 直至近期才宣布支持 Fraud Proof，实现难度可见一斑。
而对于 BitVM 桥中预签名的操作，在比特币 Covanent 的支持下，可以更高效地实现，这块仍等待社区共识。
从安全属性来讲，通过提交 Rollup 区块哈希至比特币获取了抗重组与抗双花性，又利用乐观桥带来了 1/N 的安全假设，不过桥的抗审查性还可以等待进一步提高。
结语：Layer 2 不是万能解药
总览如此多种 Layer 2 方案，我们很容易发现每种方案能够完成的任务都是有限的。在特定的信任假设下，Layer 2 能够实现的效果很大程度上取决于 Layer 1——也就是比特币原生的能力。
没有 SegWit 升级与时间锁，闪电网络无法顺利构建；没有 Taproot 升级，RGB 的承诺无法顺利提交；没有 OP_CAT 与其他 Covanent，比特币上的 Validity Rollup 不可能顺利构建……
很多 Bitcoin Maxi 认为比特币永远不应该更改，不应该增加新的功能，所有缺陷都让 Layer 2 去解决，这是办不到的，Layer 2 不是万能解药。我们需要一个功能更加强大的 Layer 1，才能够构建出更加安全、高效、可拓展的 Layer 2。
下一篇，我们将介绍比特币上提高可编程性的尝试，敬请期待。
