文章目录
区块链扩容的两个层次
-
Layer 1 （链上）
对共识算法和区块链架构（分片）的改进。在链上的改进对可扩展性的提高能力非常有限。 -
Layer 2 （链下）
在主链之外建立外围或第二层交易网络（例如，状态通道、侧链、DAG）。
Example 1：闪电网络——状态通道在比特币上的实现
闪电网络可以说是Layer 2最有名的扩展项目了。
适用场景
高频、小额交易。
核心概念
-
RSMC（Recoverable Sequence Maturity Contract）
类似于准备金机制，保障了两方的直接交易可以在链下进行。
双方都预存一部分资金到“微支付通道”里，之后每次交易，就对交易后的资金分配方案共同进行确认，同时签字作废旧的版本。当需要提现时，将最终交易结果写到区块链网络中，被最终确认。（可以看到，只有在提现时候才需要通过区块链）。
任何一个版本的方案都需要经过双方的签名认证才合法。任何一方在任何时候都可以提出提现，提现需要提供一个双方都签名过的资金分配方案（意味着肯定是某次交易后的结果）。在一定时间内，如果另外一方提出证明表明这个方案其实之前被作废了（非最新的交易结果），则资金罚没给质疑成功方。这就确保了没人会拿一个旧的交易结果来提现。
另外，即使双方都确认了某次提现，首先提出提现一方的资金到账时间要晚于对方，这就鼓励大家尽量都在链外完成交易。 -
HTLC（Hashed Timelock Contract）
HTLC就是一种就是限时转账，保证了任意两人之间的转账都可以通过支付通道完成。微支付通道是通过 Hashed Timelock Contract 来实现的。通过智能合约，双方约定转账方先冻结一笔钱，并提供一个哈希值，如果在一定时间内有人能提出一个字符串，使得它哈希后的值跟已知值匹配（实际上意味着转账方授权了接收方来提现），则这笔钱转给接收方。
交易流程
- 双方建立支付通道
- 资金上链
- 链下白条交易
- 关闭链下通道
- 1. 双方建立支付通道
-
2. 资金上链
Bob和Coffeeshop都把资金存入到链上地址，Bob存入0.05BTC，Coffeeshop存入0BTC。只有通道关闭时，链上的资金才会被释放，用户才能真正拥有该资金。
支付通道的建立是在链上完成的，因此需要一定的交易费。
这是一个双向的支付通道。所谓通道，其实就是双方之间的签名地址和分配状态。交易双方可以在链下通道内完成多次交易，将交易余额上链。这样众多微小的交易就变成了交易集，大大降低了最终发布到链上的交易数量。
支付通道的建立过程引入了“2-of-2双重签名地址”：
该地址就是需要双方的签名才能进行转账的地址。 其中，第二个2表示总签名数，第一个2表示拿到几个数有效。这里指的是总签名数为2个，一笔交易拿到2个签名后有效。2-of-3指的就是总签名数为3个，拿到其中2个签名后有效。
-
3. 链下白条交易
Bob和Coffeeshop之间的交易在链下进行，可以是多次交易。他们在建立的支付通道内通过相互在白条上签名来完成交易。每次交易，双方都保存一份相同的带有双方签名的白条。保存的白条是处理后续交易，解决交易纠纷的关键。 -
4. 关闭链下通道
任何一方都可以申请关闭链下支付通道来进行交易结算。比如BoB 可以拿着白条：Bob 0.045 BTC| Coffeeshop 0.005 BTC，到链上申请关闭链下支付通道，并进行交易结算，结算完成后 Bob 可以拿到 0.045 BTC，Coffeeshop 拿到 0.005 BTC。
如何防止交易方作弊？
如果Bob实际上买了10杯咖啡，双方真正的余额是Bob 0 BTC| Coffeeshop 0.05 BTC。如果此时Bob想作弊，拿着第一次交易的白条Bob 0.045 BTC| Coffeeshop 0.005 BTC到链上去申请结算，就会发生诈骗的情况。
闪电网络给出的解决方案是RSMC（Recoverable Sequence Maturity Contract）。RSMC规定有效交易必须是经双方共同签字确认的资金分配方案，且将之前的版本签字确认作废。这里如果Bob提出关闭交易通道进行结算，他向区块链出示双方签字的余额分配方案，如果Coffeeshop在规定时间内未提出异议，那么区块链才会中止双方的支付通道并将资金按协议转入各自的提现地址。而如果Coffeeshop在规定时间内提出了异议，并向区块链提交了证据证明Bob提交的是一个双方已同意作废的余额分配方案，那么Bob的资金将被没收给Coffeeshop。
（这里有一个缺陷，那就是在这个超时机制中，用户需要在给定时间内保持一次在线。在线问题是闪电网络的一个缺陷）。
另外，RSMC还规定了资金到账顺序。为了鼓励双方尽可能多地在该通道内进行交易，RSMC规定：主动关闭方资金到账时间晚于对方。
双人通道=>多人通道
即用户之间的多跳支付。
Alice 和 Bob 已经建立"支付宝"支付通道，Bob 和 Carol 已经建立"微信"支付通道。如果 Alice 给 Carol 之间要进行交易，有两种方案，第一种是 Alice 和 Carol 再建立一条“Apple”支付通道，另外一种方案是通过 Alice 和 Carol 通过 Bob 进行多跳支付。
中继者的条件：
- 在可以连接发送方和接收方的支付路径中
-
指向接受方向的通道内押金大于交易额
在这里，Bob如果想当Alice和Carol的中继，那么他在与Carol的“微信”通道上必须有大于Alice和Carol交易额的押金额。这是因为，为了防止中继不诚实，闪电网络中采用中继“垫付”的方式来进行多跳交易。 （在这里，Carol 就和 Alice 约定一个“谜题”，如果 Alice 从 Bob 哪里收到的 “答案”能够解开“谜题”，就说明 Bob 真正的把资金给了 Carol）步骤如下：
- Alice 把“谜题”和转账信息给了 Bob。
- Bob 和 Carol 进行协商转账，如果 Carol 把“答案”告诉 Bob，Bob 就把钱给 Carol 转过去。
- Alice 和 Bob 进行了同样的协商转账，如果 Bob 把“答案”告诉 Alice，Alice 就把钱给 Bob 转过去。
可以看出，在这个过程中，Bob是先进行了垫付才收到的Alice的转账，这就避免了Bob收了Alice的钱而不转给Carol的作弊行为。
为什么闪电网络支持的是高频小额交易？
原因就在于其“垫付”机制和资金预存机制。
多跳支付过程中，中继先垫付了资金，然后才收到发送方的转账，也就是说，发送方要给接收方转账，要动用整条价值传输链路上的资金。在只有一个中间人 Bob 的时候，Alice 和 Bob 的资金都被动用了。如果有 10 个中间人，那么动用的资金量就是 Alice 直接支付给 Carol 的 11 倍。
另外，预存到通道中的资金数额直接决定了它可以进行的交易上限。因此闪电网络只支持高频小额交易而不支持大额交易，大额交易需要在支付通道中预存的保证金更大。
多人通道=>支付网络
既然多人之间可以建立状态通道，那么推广开来，在更多人之间就可以建立起一个支付网络来。现在闪电网络也已上线。下图就是闪电网络主网，它有 2934 个参与者，参与者之间建立 8041 个一对一的支付通道。目前上面的流通资金量还是非常少的，只有 81 个比特币。
其实从图中可以看出，还是有几个比较大的中心化节点的。
闪电网络总结
优点：
- 扩展性的提高
- 交易时间的缩短
- 没有链上交易费用
缺点：
-
中继问题
有偿中继。 -
抵押问题
交易双方在这个微通道中必须先预存一定数量的保证金，由区块链产生的智能合约（资金分配方案）进行监督评判，这使得大量流动资金滞留在通道中。
通道之内允许交易的金额上限（与存入“多重签名地址”的资金金额强相关）：闪电网络的通道里允许交易的金额上限和存入“多重签名地址”的资金金额是强相关的。 A转账给B，然后B转账给C，假设B之前的余额是0，那么A无论给B转多少币，B也无法发给C。因为B必须和C重新建立支付通道，即必须重新抵押大于交易金额的币。另外，如果在一个通道里只抵押了1 BTC，是没办法参与到“高达”1.1BTC的多跳支付场景的。
保证金锁定在通道中：除此之外，抵押的金额在状态通道关闭之前，是一直处于锁定状态的。那么到底A要分配多少给B，B又分配多少给C呢？这就涉及到是预分配的问题了，事先很难确定用量。另外，抵押金额是锁定的，你不仅仅不可以提币，也不可以充值。假设你On-Chain钱包里有很多币，但是状态通道里的币用完了以后，你也需要先关闭通道再重新开；假设你On-Chain钱包里没有足够的币，你也必须等待状态通道关闭后才能拿出抵押的部分。 -
在线问题
A在申请关闭支付通道时，如果B不在线，协议就只能要求A在申请关闭支付通道后，允许B先转出余额，然后A再转。这个过程是设置了超时机制的，在这个机制下，假设B突然发生不幸，就无法先转出余额，那么这也意味着A永远都无法转出自己的那部分余额了。 -
中心化问题（在闪电网络中也不是个问题）
微支付通道有向中心化中介演变的倾向。即，将来变成若干个大型的中介通道（比如某大机构可以锁入更多的资金到闪电网络中，由此提供充沛的流动性，那么大家就都会纷纷和他建立起通道来，这个机构就变成了一个中心化的枢纽）。但大家要明白，首先绝对的去中心化未必可取，其次，这种方案的交易双方并不需要信任中介、不需要到中介处存钱，其资金安全受到比特币区块链的充分保护。这种优势是传统中心化中介所不具备的。
Example 2：Liquidity network
Liquidity抛弃了双人通道的概念，转而直接引入了多人间链下交易的枢纽（N-party Hub），而且多个枢纽间可以互联组成整个网络。
Liquidity.Network的强大之处在于：
- 可以是多方交易通道，也可以是双向交易通道；
- 交易通道中的发送和接收都无需中继（基于Hub网络结构，路径在Hub层发挥的作用主要是实现去中心化和信息冗余方面的高效互连。A直接发给C就行了，不需要B中转）；
- 没有闪电网络类似的在线要求；
- 状态通道的抵押金额锁定，缩小了4464倍。
枢纽：
枢纽不再是个封闭的两人世界，而像一个开放的信用合作社，任何人都可以加入某个特定的枢纽。枢纽的概念也有点像交易所，一个去中心化的交易所，平时都在交易所中进行交易，每个交易之间也会通过特殊的通道进行连接，组成一个全球的交易网络。但是与交易所不同的是，枢纽并没有一个中心化的机构掌握金钱，并且支付行为是在链下发送的，而不是在链上进行的。
枢纽减少路由的压力（假设大部分枢纽都含有成百上千个用户可以自给自足）。而且枢纽之间也可以互联，如果同一个用户同时加入了连接成环的多个枢纽，那么抵押进这些枢纽的金额可以在彼此之间动态调整。这个想法是从创始人早先的一个研究成果Revive引申而来的。REVIVE是运用在传统的双人支付通道中的一个押金再平衡的协议，使用了线性规划做优化计算。比如下图里是一个最简单的例子，三个人ABC每人都拥有100钱，通过双向支付通道形成了一个环，但是通道内的金额分配非常不平衡:
AC之间，AB之间和BC之间各自拥有了一条通道。在AC通道里，当前A账面上有100，C啥都没有，而AB通道里，A啥都没有，但是B有100。如果这时候A要再给B转50，或者有个多跳支付交易希望通过AB通道来走（比如画面外的一个付款人付给A以50，A付给B以50，B再付给画面外的最终收款人50），这里一个比较容易想到的思路就是：把AC通道中属于A的100里50通过“动态调整”放到AB通道里给A使用。
动态调整流程如下：
随机在ABC中选取一个领导者来引导这个再平衡的过程，期间三个通道需要全部冻结，通过每个人的偏好和当前的需要构建出一系列的链下支付交易，交给所有人签字，都通过后，就强制原子性交易执行。比如在上面这个例子里，再平衡的结果可以是让A转给C以50，C转给B以50，B再转给A以50。这个时候ABC每个人依旧每人拥有100钱，谁也没多谁也没少，不过在每个通道内的所有账本上都有50了。
关于锁定金额4464倍的解释：
整个网络内需要锁定的资金可以只是最近十分钟内的平均交易额度，而不是所有交易金额加起来的总和。举个例子，假设100个用户之间会发生各式各样的支付交易，月平均交易量达100BTC：对于闪电网络来说，那么参与其中的每个人都要押入100BTC，总共需要将一万个BTC锁定到闪电网络中。同样情况下，对Liquidity来说，将时间缩短到十分钟，那么平均交易量也就缩小了4464倍（4464 = 31天 * 24小时 * 60分钟 / 10分钟，话说官方还是有点“小无耻”的，白皮书里也是直接算一个月31了，毕竟这样数据最好看），于是所需要的抵押总额也就缩小了4464倍（其实看下去就会发现押金什么的感觉已经不重要了）。
Example 3：Celer network
CelerNetwork的分层技术架构：
受互联网非常成功的分层抽象原则的启发，我们将Celer Network设计为一个的简洁的分层架构，将复杂的离线操作网络分解为分层模块。这种架构大大降低了系统设计，开发和维护的复杂性，并且能够快速演变为每个单独的组件。我们将每层接口的集体规范称为cStack（分层结构，清晰的界面。减少系统设计，开发和维护的复杂性。使每个组件的快速演变成为可能。），包括以下部件构造：cChannel：广义状态通道和侧链套件。在网络通道上支持通用依赖DAG的快速状态转换。灵活的结构最大限度地提高流动性利用率。cRoute：具有透明通道平衡的可证明最佳状态（例如，小额支付）路由。 与最先进的解决方案相比，吞吐量提高了15倍。cOS：支持离线功能的应用程序的开发框架。提供通用的设计模式，并处理脱链状态的操作，存储，跟踪和非链状态的争议。cApps：在Celer Network上运行应用程序生态系统。通过区块链系统保证信任，隐私或权力下放，从而扩展到每秒数十亿次交易。
在Celer Network中，最终用户通过cChannel连接到Celer节点的去中心化且无信任的网络，实现广义状态信道功能。在Celer节点中，cRoute用于在最终用户之间优化和无信任地路由广义状态（例如，有条件支付）。对于用户来说，连接到Celer Network就像连接到互联网，在那里你可以与谷歌，Facebook或任何其他互动。一旦连接到Celer Network，基于cOS的所有cApp将可供用户安装并以大规模和低成本使用。Celer Network目前具有较高人性化设计，高度可扩展和低成本的优点。
Reference
https://www.jianshu.com/p/b75a6ee8c7cf
https://www.jianshu.com/p/4f0d0d1c6749
</div>