链下扩容方案深度解析：State Channels及比特币闪电网络

2025-07-27 11:41:17

链下扩容深度解析

作者：Cobo Ventures

1. 扩容的必要性

区块链的未来愿景是去中心化、安全性和可扩展性，但通常只能实现其中两个,这被称为区块链的不可能三角问题。多年来,人们一直在探索如何解决这一难题,如何在保证去中心化和安全性的前提下,提高区块链的吞吐量和交易速度,即解决扩容问题,是当前区块链发展过程中的热点话题之一。

区块链的去中心化、安全性和可扩展性定义:

去中心化:任何人都可以成为节点参与区块链系统的生产和验证,节点数量越多,去中心化程度越高,确保网络不受少数大型中心化参与者控制。
安全性:为获取区块链系统控制权所付出的成本越高,安全性越高,链就可以抵抗较大比例参与者的攻击。
可扩展性:区块链处理大量交易的能力。

比特币网络的第一次重大硬分叉就源于扩容问题。随着用户数量和交易量增多,每个区块上限为1MB的比特币网络开始面临拥堵问题;2015年开始,比特币社区就扩容问题存在分歧,一方是支持扩大区块的扩容派,另一方是支持使用隔离见证Segwit方案的小区块派。2017年8月1日,扩容派自行开发至8MB的客户端系统开始运行,导致比特币历史上第一次重大硬分叉,同时诞生了新币种BCH。

以太坊网络也选择牺牲了部分可扩展性来保障网络的安全性和去中心化。虽然以太坊网络未像比特币网络通过限制区块大小来限定交易量,而是变相转变为对单一区块可容纳的燃料费设置上限,但目的都是为了实现无信任共识并确保节点的广泛分布。

从2017年的CryptoKitties,DeFi summer、再到后来GameFi和NFT等链上应用的兴起,市场对吞吐量需求不断增加,但即使是图灵完备的以太坊每秒也只能处理15-45笔交易(TPS),这导致交易成本不断增加,结算时间变长,大部分Dapps难以承受运行成本,整个网络对于用户而言也变得又慢又贵,区块链扩容问题亟待解决。理想的扩容方案是:在不牺牲去中心化和安全性的前提下,尽可能提高区块链网络的交易速度和交易吞吐量。

2. 扩容方案的类别

我们按照"是否改变一层主网"作为标准,把扩容方案分为链上扩容和链下扩容两大类。

2.1 链上扩容

核心概念:通过改变一层主网协议达到扩容效果的解决方案,目前的主要方案是分片。

链上扩容有多种方案,此篇文章不展开,简要列举两种方案:

方案一是扩大区块空间,即增加每个区块打包的交易数量,但这会提高对高性能节点设备的要求,提高节点的加入门槛,降低了"去中心化"程度。
方案二是分片,将区块链账本分成若干部分,不再是每个节点参与所有记账,而是由不同分片即不同节点负责不同记账,并行计算可以同时处理多个交易;这样可降低节点计算压力和加入门槛,提高交易处理速度和去中心化程度;但这意味着全网算力被分散,会降低整个网络的"安全性"。

改变一层主网协议的代码可能会产生难以预料的负面影响,因为底层任何细微的安全漏洞都会严重威胁整个网络的安全性,网络可能会被迫进行分叉或中断修复升级。例如,2018年的Zcash的通胀漏洞事件:Zcash的代码是基于比特币0.11.2版本代码修改的,2018年一位工程师发现其底层代码存在高危漏洞,即代币可无限增发,随即团队花了8个月的时间进行秘密修补,漏洞修复后才公开这一事件。

2.2 链下扩容

核心概念:不改变现有一层主网协议的扩容解决方案。

链下扩容方案又可以细分为Layer2和其他方案:

3. 链下扩容的方案

3.1 State Channels

3.1.1 概要

状态通道规定只有在通道打开、关闭或解决纠纷时,用户才需要与主网进行交互,并把用户与用户的交互放在链下进行,以此来降低用户交易的时间和金钱成本,并且实现交易次数不受限制。

状态通道是简单的P2P协议,适合"基于回合的应用程序",例如,两人国际象棋游戏。每个通道都由主网上运行的多签智能合约管理,该合约控制存入通道的资产,验证状态更新,并仲裁参与者之间的争议(根据带有签名和时间戳的欺诈证明)。参与者在区块链网络部署合约后,存入一笔资金并锁定,双方签名确认后,通道正式开通。通道允许参与者之间进行不限次数的链下免费交易(只要他们的转账净值不超过存入的代币总额)。参与者轮流发送状态更新给对方,等待对方的签名确认。一旦对方签名确认,这笔状态更新就算完成。正常情况下,双方同意的状态更新不会上传主网,只有在出现争议或关闭通道时,才会依赖主网确认。需要关闭通道时,任一参与者可在主网提出交易请求,如果退出请求获得全员一致签名批准,则链上立即执行,即智能合约根据通道最终状态下每个参与者的余额,分发剩余的锁定资金;如果其他参与者没有签名批准,则所有人需等待"挑战期"的结束才能收到剩余资金。

综上,状态通道方案可以大大减少主网计算量,提升交易速度,降低交易成本。

3.1.2 时间线

2015/02,Joseph Poon和Thaddeus Dryja发布了闪电网络白皮书草案。
2015/11,Jeff Coleman首次系统性总结了State Channel的概念,提出比特币的Payment Channel是State Channel概念中的一个子案例。
2016/01,Joseph Poon和Thaddeus Dryja正式发表白皮书《The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments》提出比特币闪电网络的扩容方案Payment Channel(支付通道),该方案仅用于处理比特币网络上的转账支付。
2017/11,第一个基于Payment Channel框架下的有关State Channel的设计规范Sprites被提出。
2018/06,Counterfactual提出了一个非常详细的Generalized State Channels设计,这是第一个完全与状态通道相关的设计。
2018/10,文章Generalised State Channel Networks提出State Channel Networks和Virtual Channels的概念。
2019/02,状态通道的概念扩展到N-Party Channels,Nitro是首个基于该想法建立的协议。
2019/10,Pisa为了解决所有参与者需要持续在线的问题,拓展了Watchtowers的概念。
2020/03,Hydra提出Fast Isomorphic Channels。

3.1.3 技术原理

图1展示的是传统链上的工作流程:Alice和Bob与部署在主网上的智能合约进行交互,用户通过向链上发送交易来改变智能合约的状态。缺点是会带来上面讨论的时间和成本问题。

图2展示的是大多数状态通道协议遵循的一般工作流程:乐观情况下,Alice和Bob需要执行与之前相同的操作,但这次他们使用状态通道,而不是与链上合约进行交互。

第一步,Alice和Bob通过从其个人EOA存入资金到链上合约地址(交互1,2),这些资金被锁定在合约中,直到通道关闭时才将余额返回给用户;二人签名确认后,二人之间的状态通道正式开通。
第二步,Alice和Bob通过该通道理论上可在链下开展不限次数的交易(蓝色虚线),参与者通过加密的签名消息相互通信(而不是与区块链网络通信)。双方用户都需要对每笔交易进行签名,以防止双花作恶。通过这些消息,他们提出自己账户的状态更新,并接受对方提出的状态更新。
第三步,如果Alice想关闭通道结束和Bob之间的交易,Alice需要向合约提交自己账户的最终状态(交互3),如果Bob签名批准,合约则会根据最终状态将锁定的资金释放返回对应用户(交互4,5)。如果Bob未响应签名,合约则会在挑战期结束后将锁定的资金释放返回对应用户。

图3显示的是悲观情况下状态通道的工作流程:起初,两个参与者存入资金(交互1,2),然后开始交换状态更新(蓝色虚线)。假设在某个时间点,Bob在他的轮次中不响应Alice发送来的状态更新签名(交互3),此时,Alice可以通过向合约提交自己最后一次的有效状态来发起挑战(交互4),这个有效状态也包含了Bob之前的签名,从而证明最后一笔交易已经收到Bob的批准,最后状态已经收到Bob的确认。然后,合约允许Bob在一段时间内通过将下一个状态提交给合约进行响应;如果Bob响应,则二人可以继续在状态通道内进行交易;如果Bob在该时间段内没有响应,则合约自动关闭状态通道并将资金返回给Alice(交互5)。

3.1.4 优缺点

优点:

瞬时确定性
极低的费用
隐私性好
可扩展性高
灵活性强

缺点:

需要所有参与方持续在线
不适合复杂计算
建立通道的前期成本高
扩展性差
需要预存锁定资金

3.1.5 应用

比特币闪电网络

概述:

闪电网络是比特币网络的小额支付通道,其整体技术演变经历:2/2多签构建单向支付通道,增加RSMC(Revocable Sequence Maturity Contract)后可构建双向支付通道,再增加HTLC(Hash Time Lock Contract)后可连接支付通道拓展到多人支付,最终构建支付网络即闪电网络。通过链下小额支付通道,然后借助中间人构成交易网络,可以解决比特币网络扩容问题。闪电网络的整体使用遵循着"存款(建立通道)→闪电网络交易(更新通道状态)→退款/结算(结束通道)"的流程;理论上闪电网络每秒可以处理一百万笔交易。

时间线: