随着业务量的增加，比特币等公有链网络已经拥堵不堪，交易费节节攀升，对比传统金融结算系统已经没有速度上的优势。对于去中心化的系统，由于社区成员基于自己的利益考虑，无法达成一致，也就难以采用更高效的共识算法或更先进的系统架构。

因此，社区出现了闪电网络、雷电网络等链下或侧链的方案，试图解决交易性能低下的问题——这些技术并不提升区块链本身的共识性能，而是将交易放到区块链的外部进行。

** **

闪电网络（Lightning Network）

闪电网络（Lighting Network）指的是，A和B两人可以把比特币放到一个多重签名钱包中锁定（链下），然后进行交易签名更改双方各自能取回的比特币数量。交易参与方可以随时关闭交易通道，最后一笔经过签名且包含最新余额动态的交易最终将会被广播并写入比特币区块链（回归链上）。这个交易过程也可以在更多人之间进行，整个过程实际上不需要在主链确认，因为都是几方之间倒来倒去的”数字游戏“，因此交易速度会非常迅速。只有当关闭交易通道时，才会最终确定各自的余额并写进主链区块。

在闪电网络出现前，虽然比特币社区也试图通过区块扩容、隔离见证等技术在一定程度上增加交易处理能力，但这些方式并不能导致交易处理能力出现数量级的改善。以比特币区块链为后盾，在链下实现真正的点对点微支付交易，区块链处理能力的瓶颈被彻底打破，时延、最终性、容量甚至隐私问题也迎刃而解，这就是比特币“闪电网络”（Lightning Network）的思路。

闪电网络的关键技术有两个：RSMC和HTLC。前者解决了链下交易的确认问题，后者解决了支付通道的问题。

闪电网络的基础是交易双方之间的双向微支付通道，RSMC（Recoverable Sequence Maturity Contract）定义了该双向微支付通道的最基本工作方式。HTLC（Hashed Timelock Contract）进一步实现了有条件的资金支付，通道余额的分配方式也因此变得更为复杂。基于HTLC可以实现“闪电网络”。

尽管闪电网络本身可以基于任何合适的传统技术构建（例如中心化的服务器和传统数据库），闪电网络的支付通道也可能逐渐向少数大型中介集中，变成若干大型中介彼此互联、普通用户直连大型中介的形式，但这种方案仍然具有传统中心化方案不可比拟的优势，因为用户现在并不需要信任中介，不需要在中介处存钱才能转移支付，资金安全受到比特币区块链的充分保护。

闪电网络存在的问题：

  • 闪电网络的支付通道会导致一定程度的中心化。如果闪电网络存在，人们不会立即就信任它，短时间内不会有钱包或支付供应商支持它。

  • 使用闪电网络需要提前充值。闪电网络的运行需要用户和企业锁定在交易期间他们所需数目的比特币。对于小额交易不是问题，然而，如果按照闪电网络所建议的‘合理使用案例’中每个人在每6个月中只开启1个通道的话，这意味着该通道需要锁定这个用户在该时间段内所持有的最大数目的价值额度，这需要对链下网络的充分信任，还需要人们能预见将花费多少额度，以及何时花费。

  • 无法进行离线支付，A和B交易，如果B掉线了，就无法签名确认分配方案，交易失败。

** **

雷电网络（Raiden Network）

雷电网络（Raiden Network）是以太坊社区提出的自己的链下微支付通道解决方案，跟比特币的闪电网络的思路类似，但也有所发展，例如引入了较HTLC更为通用的“Smart Condition”等。

因为以太坊智能合约对报文格式没有特别的字段限制，使得Raiden得以为通道余额快照引入一个单增序号，极为轻松自然地解决了旧版本快照的识别和作废问题。

和闪电网络一样，双方需要在以太坊区块链上开设通道并各自锁定以太。这步动作可通过向Raiden智能合约发送一条双方签名认可的报文来实现。报文中的关键信息包括：双方公钥、双方锁定资产数量、双方签名。

此后的任何支付动作都可以发生在以太坊区块链外，参与双方只需要私下传递一系列报文。

** **

该如何提升性能？

以迅雷链为例，下面来解读下如何提升性能。首先从架构上优化，提出同构多链的框架。即系统由一条条相对独立（独立进行共识）的链组成，每条链有多个节点，每个节点被分配到其中一条链上，不同的账户数据被锚定在不同的同构链上，然后接入层将交易路由到发送方所在的链上进行区块打包与共识。系统中链的数量能够按业务需求动态增加。因此同构多链的架构首先保证了系统的可扩展性。

除了架构上优化使得并发处理性能提升，还应该保证分布式系统中的强一致性，并具备一定的容错和防拜占庭节点作恶的能力，因此每条链内的共识算法可以选择类 BFT 算法。在每一条单独的链上，使用实用拜占庭容错算法（PBFT）保证强一致性，而且一方面通过容错性，降低节点失效对整个分布式系统的影响，另一方面采用多次重试和更换失效节点机制，降低节点间长时间失效的概率，保证系统的可用性。为了解决PBFT算法网络消耗高的问题，对算法作出了一些优化，降低网络消耗，提高了算法的可用性。

与传统的PBFT算法类似，对于每一轮共识操作，又包括三个阶段：Propose，Prevote 和 Precommit。

当在某一轮达成共识(收到+2/3 的 Precommit 投票)后，就会进入对下一个高度的共识，从第 0 轮开始。下面简单介绍下详细的步骤：

首先介绍一个锁定区块的概念，表示在某个特定的高度和轮数，节点对某个块收到超过节点总数 2/3 的 Prevote 投票集合后，则此节点对于此高度此轮的区块进行锁定。也就是说，节点以锁定区块来表示对某一个区块的认可。

1）Propose 阶段：系统中所有验证人节点轮流作为提议者提出提议，而系统中非提议者的节点在收到提议后，就会进入 Prevote 阶段。如果当前节点此前存在已锁定区块，则还需要收集所有针对已锁定区块的 Prevote 投票。

2）Prevote 阶段：当节点进入到 Prevote 阶段后，每个节点广播自己的Prevote 投票。

具体的，如果当前区块高度或投票轮数高于此前已锁定的区块高度或轮数，则将原锁定的区块进行解锁。如果此时节点仍含有未解锁的区块，则对此锁定的区块投 Prevote 投票。或者如果节点收到合法的 Propose 区块，则对此区块投 Prevote 投票。

当阶段超时或者接收到大于 2/3 的针对某个块的投票后，则节点锁定此区块并进入。

3）Precommit 阶段：当节点存在已锁定区块，则对此区块投 Precommit 投票。当节点收到针对已锁定区块大于 2/3 的 Precommit 投票时，就可以将这个块 commit，并且进入针对下一个高度块的共识。

若 Precommit 阶段定时器超时，则节点保存已锁定区块，然后重新返回到 Propose 阶段。

各节点通过在以上阶段上循环，对区块进行一致性共识。与 PBFT 算法类似，迅雷链共识也经过了三阶段提交，但通过引入区块锁定操作，通过缓存待确认区块，降低�