状态通道也算是一种比较热门的扩容方案，状态通道解决方案通过将链下交互和链上清算隔离开，能够在保障一定程度的非中心化和资产安全性的同时，实现速度更快、费用更低的交易。状态通道作为一种链下扩容方案，从一般到特殊分为通用状态通道、状态通道和支付通道三个层次。状态通道面临的主要问题包括路由问题、通道平衡问题、节点离线问题以及保证金锁定问题。

通过设计合理的路由策略可以将状态通道扩展为网络结构，目前的方案有哈希时间锁合约、虚拟通道和元通道。通道平衡问题的主要解决思路有背压路由算法和链下重新平衡方案。节点离线问题的主要解决思路是引入第三方来监督链下状态，并加以经济激励。保证金锁定问题的解决思路是从流动性资金供应商那里吸收闲散资金、共享资金池。

相比于链上扩容方案，状态通道巧妙地将链上和链下的职能分开，采用该方案无需改变公链结构，结合链上的安全性和非中心化特性以及链下的扩展性，但从整体生态来说，由于链上链下通信过程中可能存在的问题，依然属于安全性、非中心化和扩展性的一种新平衡。相比于其他链下扩容方案，状态通道的隐私性较好，可做到即时性，尤其适合于固定双方的高频互动，其劣势在于需要中间节点“垫付”资金、要求节点实时在线或需引入第三方来监督

状态通道（State Channel）是区块链链下（off-chain）扩容方案之一，目前有众多知名项目都采用了状态通道技术方案。

一. 状态通道概述

状态通道中的状态指的是区块链账本当前的样子，包括账户名称（或 UTXO 模型的地址）、余额（或 UTXO 模型下的未花费交易输出）、合约数据等。状态通道是在两方或多方之间开辟一条链下通道来进行状态交换，以实现较低的手续费和即时到账等特性。

利用状态通道交易的流程一般为：

1.交易方在链上锁定一定量的资产，在区块链上记录并开辟状态通道；
2.在通道内进行相互交易和状态更新，但不提交到链上；
3.当任一方想要关闭通道时，提交最终状态到区块链上进行清算。若另一方有异议，可在规定时间内申请链上仲裁
状态通道的扩容原理主要是链下交互、链上清算，避免将每一笔小额交易都放在链上进行，只需要把最终的状态提交到链上即可，减轻了链上的工作量。当双方均无异议可以很快完成清算，实现即时终结性（Instant Finality），此外由于在通道内进行链下交易，可实现较快的交易速度、较低的手续费，以及较好的隐私性。

当某一方试图欺诈，提交有利于自己的非最终状态上链时，另一方可以通过提交带有时间戳的最新状态向链上申诉，坐实后欺诈者会面临被没收抵押物的惩罚。但这要求状态通道的用户实时在线，

如果某一方长时间离线，链上清算会强制执行，从而可能造成损失。这种情况下一般会引入第三方来监督是否有欺诈现象发生，但这需要设计出合理的第三方经济激励机制。

状态通道方案比较适合参与方在相对较长的时间里需多次交换状态、对单次转账的交易手续费比较敏感等场景

二. 状态通道的三个层级

状态通道作为一种链下扩容方案，从一般到特殊主要分为通用状态通道（Generalized State Channel）、状态通道（State Channel）和支付通道（Payment Channel）三个层级。

1 通用状态通道
通用状态通道是模块化、标准化的状态通道开发框架，实例化之后即成为状态通道或支付通道。开发人员无需很熟悉状态通道的相关技术细节也可以很容易地开发基于状态通道的应用，用户也可在不执行任何链上操作的情况下在通道内安装、运行和终止 DApp。

典型的项目有 Counterfactual（基于链下状态通道建立应用的开发架构）、Celer Network（layer-2 扩展平台，帮助开发者快速构建和运行非中心化应用。）。

2 状态通道
状态通道是在链下进行状态交互的通道。通过将链上的图灵完备智能合约放到链下执行，来实现状态交换和链下扩容的目的。例如基于状态通道开发的围棋游戏，就是在链下不断进行状态的交换。

典型的项目有 Perun Network（支持链下智能合约的执行）、FunFair（基于状态通道的对赌游戏）。

3.支付通道
支付通道属于状态通道在支付领域内的具体应用。交易双方在状态通道内可多次进行账务往来，直到通道关闭时上链清算。链下转账快速无手续费，当一方尝试在上链清算时进行欺诈，会有仲裁和惩罚机制来确保双方的资产安全。

典型的项目有闪电网络（BTC 的状态通道支付网络）、Raiden（以太坊版的闪电网络）、Trinity（Neo 版的闪电网络）Liquidity Network（基于 NOCUST 协议的支付通道网络）

三. 状态通道存在的问题

为了将支付通道扩展为支付网络，在已开辟的状态通道上通过路由节点建立两个陌生节点的连接无疑是比较经济的。正如六度人脉理论阐释的那样，我们可以借助六度人脉和世界上其他任何人建立联系。目前主要有如下三种路由方案：

1.1. 哈希时间锁合约（HTLC，Hashed-Time Lock Contract）
代表项目：闪电网络

发送方向接收方发送 BTC 到 1/2 多重签名地址，如果接收方不能在合约规定的时间内通过“签名+哈希密文”的方式将 BTC 解锁，那么 BTC 就会退还给发送方。

如图所示，A 想通过 B、C 向 D 发送 1 个 BTC。D 作为接收方，首先生成一个随机私钥 r（相当于钥匙）和公钥 R（相当于锁），然后将 R 发送给 A。

A 和 B 首先搭建了哈希时间锁合约，R 就是其中的“锁”，这里的“时间”是 3 天，“哈希密文”就是只有 D 才知道的私钥 r。这个合约意味着只要 B 能在 3 天之内获得私钥 r 来解锁 R，就可以得到A 在智能合约里发送的 1 个 BTC，否则这 1 个 BTC 就会退还给 A。

B 需要获得私钥 r 来解锁 R，按照同样的思路，B 和 C 的智能合约规定，只要 C 能在 2 天之内获得私钥 r 来解锁 R，就可以得到B 在智能合约里发送的 1 个 BTC，否则这 1 个 BTC 就会退还给 B。

最后 C 和 D 的智能合约也是如此，只要 D 能在 1 天之内用私钥 r 来解锁 R 就可以获得这 1 个 BTC。相当于 D 是用私钥 r 换取了C“垫付”的 1 个 BTC，C 拿到私钥 r 后再用它解锁并换取了 B“垫付”的 1 个 BTC，之后 B 用 r 解锁了 A 的 1 个 BTC。

也就是说，D 首先生成了“锁”和对应的“钥匙”，然后锁依次传到 A、B、C；D 收到 BTC 后，“钥匙”依次传到 C、B、A。这样几个节点无需相互信任就实现了从 A 到 D 的安全转账。实际操作中，中间节点会收到额外的服务费作为经济激励（这也意味着经过的中间节点越多，手续费越高）。