Layer2 | 状态通道 State Channel

在上一篇文章中，我们介绍了区块链发展的新思潮，并且在这一新思潮下催生出的二层扩展技术发展，即 Layer2 方案。接下来我们将会为大家着重讲述「链下」扩容技术之一的状态通道及相关项目简介。

状态通道 State Channel

我们先来谈谈状态通道，举一个例子方便大家理解。

Alice 和 Bob 一起玩一个划拳游戏。Alice 赢了可以从 Bob 那里得到 1 块钱，而如果 Alice 输了需要给 Bob 1 块钱，反之亦然。

如果这个游戏是在以太坊主链上运行，我们通常的方法是 Alice 和 Bob 一起创建一个智能合约，每当划拳游戏开始的时候，他们向智能合约发起一个交易，当其中一个玩家赢了的时候，智能合约会执行规则付给赢家 1 块钱。

这个很清晰，也很简单，但是在以太坊上还是效率太低了。因为这个只局限 Alice 和 Bob 之间的交易需要整个以太坊来处理。而且每次玩家需要操作的时候，都必须支付 Gas 费用，他们必须等待几个块之后才能开始行动，这个对于来玩游戏是很不友好的。

那么我们在这里可以不可以设计出一种系统，尽可能的减少 Alice 和 Bob 在链上的操作？

是可以的。

Alice 和 Bob 能在链下更新游戏的状态，同时有必要可以恢复到以太坊主链的状态的这种系统，就叫做状态通道，它实现的过程可以概括为以下几个步骤：

1. 打开状态通道
   1. 质押资产
   2. 建立一个去中心化的制衡机制
2. 在链下发送交易
   1. 对状态签名并发送
   2. 双方确认状态的改变
3. 关闭状态通道

具体过程

首先，我们在以太坊上创建一个智能合约，这个是一个类似法官的角色，Alice 和 Bob 为两个参与游戏的玩家。然后 Alice 和 Bob 开始玩游戏。

Alice 创建并签署了一个描述她第一次操作的交易，并且把这个交易发给了 Bob，Bob 签了名之后，把签名版本发了回去，并且自己保留了一个副本，然后 Bob 创建并签署了他第一次操作的交易，把这个发送给了 Alice ，Alice 也对交易进行了签名，再发回去，并且为自己保留了一个副本。

每次他们都能更新当前的游戏状态，每个交易包含一个声明，这意味着后面的交易总是能知道每个操作发生的顺序。

这个其实暂时还没有任何事情发生在链上，他们只是在网站上互相发送交易，没有任何东西传到区块链上。但是所有的游戏交易都能发送到智能合约上，它们都是有效的区块链交易。

我们可以把这个看成是两个人互相写在一系列区块链认证的支票，实际上没有钱存入银行或者取出，但每个人都有一堆可以随时存入的支票。

当 Alice 和 Bob 结束游戏之后，他们需要向法官提交最终的状态来关闭这个通道，这样只付一笔交易的费用。

假设最后划拳游戏经过了很多轮，Alice 合计赢了 5 局，那么 Bob 要给 Alice 5 块钱。法官合约保证这个最终的状态是双方都签过名的，经过一段时间挑战期之后，确保没有人能够合法的修改这个结果，合约就会向 Alice 付 5 块钱。

挑战期

而需要「挑战期」的原因是防止玩家作恶。

如果 Bob 发送给法官的是更早的状态，没有发送最终的真实状态，由于法官只是一个智能合约，它是无法知晓这个是不是最新的状态的，那么 Alice 的资产就会受到损失。

所以我们有挑战期，让 Alice 有向法官合约证明 Bob 游戏状态作恶的机会。

比方说，如果 Bob 发送的是更早的状态，那么 Alice 是保留过这个状态的副本的，她可以把这个状态提交给法官合约。法官合约通过查看声明就能判断 Alice 发送的状态是最新的，拒绝 Bob ，并且罚没掉 Bob 的押金。
 

优缺点

而通过描述过程，我们可以发现状态通道有以下几个特点。

优点

• 状态通道具有良好的隐私性

不管在状态通道上发生了多少的瞬时交易，这些交易都是在通道内部发生的，并没有广播和记录在链上，其他人不会知道，所以具有非常好的隐私性。

• 即时终结性

只要状态双方都签署了状态更新，这个状态就可以被认为是最终状态，大家可以随时退出。

• 适合长时间多状态更新

状态通道特别适合那些需要长时间里交换许多状态更新的参与者，因为在部署合约的时候，创建的状态通道有一个初始成本，而一旦部署完毕，状态通道的边际成本就接近于零。

缺点

• 每打开和关闭一个状态通道都需要一个链上交易

打开状态通道如果只给发 1 笔交易，这样会很不合算，因为还需要在链上做其他的两笔交易，它不适合低频操作。

• 状态通道的参与者要保持随时在线

由于挑战期的存在，状态通道的参与者需要一直在线，如果不在线，资产就有可能损失掉，我们平常用 imToken 做转账，等待几个区块的确认就好了，需要一直在线对于参与者来说确实是一件很不友好的事情。

• 比较适合具有一组确定参与者的应用程序

因为状态通道的法官合约始终需要知道作为通道的一部分的实体（地址），当我们需要添加和删除成员的时候，每次都需要更改合约，重新建一条通道，这个也是很麻烦的一个点。

接下来我们讲讲通过状态通道实现的项目，帮助大家来理解其应用。

闪电网络（Lighting network）

这个是比特币网络的微支付通道，已经做了很多年了，但是由于比特币本身对于脚本和智能合约的支持非常的差，它的解锁和锁定的流程设计的非常的复杂，所以这个项目一直发展很缓慢。

雷电网络（ Radien Network ）

这个是以太坊上的微支付通道，叫做雷电网络，和闪电网络类似。由于以太坊支持智能合约，所以它比闪电网络要简单很多，发展也快很多。

雷电网络借鉴了闪电网络的技术理念，关键技术也和闪电网络一致，包括 RSMC、HTLC 等技术。

它们出众的地方在于，你不必与每个想要与之交易的特定人员都开通一个状态通道，你可以打开一个连接着更大的状态通道网络的通道，这样的话你可以向任何连接在这个状态通道网络上的人付款，并且不需与额外的费用。

参与者越多，网络处理转账能力越高。但是在网络建立初期，由于支付通道很少，所以需要有人多主动建立中介点，才能让整个网络更有价值。

Sprites

它引入了经济模型，给保持状态通道的用户提供经济激励，以使他们能够保持状态通道。

A 和 B 交易、B 和 C 交易时需要创立状态通道，它们交易完之后都会把状态通道关掉，而当下次 A 和 C 需要交易的时候，还需要另外建立状态通道。

如果我们能通过经济激励的模式把 A 和 B、B 和 C 之间的状态通道给保持住，那么下次 A 和 C 交易，就可以以 A 和 B、B 和 C 的状态通道作为跳板，进项交互。那么它们就不需要再建了。

这就是 Sprites 在做的事情 ，提供了经济激励鼓励大家维护状态通道，让其能够帮别人去做交互。

Counterfactual

它做的事情是 Generalize State Channel。

我们之前提的都是 Payment 的状态通道，如果是一个基于游戏的状态通道，像下五子棋、卡牌，它的退出的时候，法官的智能合约相对会写的很复杂，工程实现方面更难。

而 Counterfactual 做的就是把法官这一层给 Generalize 了，只要你做完一次状态通道的 Open，它就可以适应于各种应用，各种退出的方式。它抽象化了状态通道的打开和退出机制，通过通用模块化的实现，允许大家更方便的使用状态通道。

Liquidity Network

Liquidity Network 旨在解决以太坊支付速度的问题，它相对于闪电网络和雷电网络做了很多优化。

雷电网络是两方之间的一个单向通道交易。而 Liquidity Network 采用了 Hub 的网络拓扑结构，用户可以加入到任意一个 Hub 中，通过 Hub 与其它用户进行交易和支付转账，实现了多方之间的双向通道交易。

在之前的状态方案当中，如果 A 要发给 C，他们之间没有建立通道，但 A 和B、B 和 C 都有建立通道，那 A 可以付费给 B 来「借道」完成与 C 的交易，如果中间环节过多的话，“借道费”都也是一笔不小的开支。而由于 Liquidity Network 采用了 Hub 的结构，所以 A 如果要发给 C，就不再需要通过 B 了，也就不存在「借道费」的概念了。

而且在 Liquidity 里面，利用 REVIVE 的押金再平衡算法，解决了雷电网络通道之间资金独立，不能自动平衡的问题。

比方说在雷电网络中，如果 A 给 B 发交易，然后 B 给 C 发交易，假设 B 的余额是 0，那么 A 发给 B 之后，B 不能直接发交易给 C，它必须跟 C 建立支付通道，并且充值足够的钱（大于交易金额），才能和 C 交易，显得很麻烦。

而 Liquidity 通过 REVIVE 技术可以直接让 B 和 A 交易完之后，立即和 C 交易 ，大大增加了交易的效率。

FunFair

FunFair 是一个由以太坊智能合约支持的去中心化游戏平台，其通过一对一的状态通道（ Fate Channel ）建立了一个 P2P 的赌场，旨在实现在线区块链博弈的公平公正，解决「赌场」游戏高费用和低信任度的问题。

SpankChain

SpankChain 是一个基于以太坊的，成人娱乐平台，其现有产品包括 Vynos，一种点对点微支付处理钱包，它已经为成人参与者建立了单向支付通道（ 其 ICO 的时候使用的就是状态通道）

 

延伸阅读：

Layer2 | 区块链发展新思潮
Layer2 | 状态通道 State Channel 
Layer2 | Plasma 框架 
Layer2 | 链下计算 
Layer2 | 链间通信 ​​​​​​​

转载于:https://my.oschina.net/u/3919161/blog/2992526