链下扩容深度解析

1. 扩容的必要性

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

让我们先笼统地定义区块链的去中心化、安全性和可扩展性:

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

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

同样,以太坊网络也是选择牺牲了一部分可扩展性,用来保障网络的安全性和去中心化;虽然以太坊网络并未像比特币网络一样通过限制区块大小来限定交易量,而是变相转变为对单一区块可容纳的燃料费设置上限,但是目的都是为了实现 Trustless Consensus 并确保节点的广泛分布(无论取消还是提高限额都会淘汰很多带宽、存储和计算量不足的较小节点)。

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

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 多签构建单向支付通