2.5 最新比特币技术
随着区块链的不断发展，区块链技术也在飞速发展，不仅已经有了相对成熟的应用，还有一些原型应用也被提出，下面将介绍几个现在比较流行的在区块链中的应用。
2.5.1 IBLT
比特币系统（Bitcoin）需要矿工（或者说矿池）及全节点的分散化，以实现某些人认为的比特币核心属性：抗审查性（censorship resistance）。因此，区块大小的争议也意味着是一种权衡。更大的区块，允许比特币网络可以承载更多的交易，但也会带来更多的问题，它需要更多的时间来传播交易，虽然这有利于大矿工和矿池，但同时，增加的数据传递对于用户运行全节点而言，也是一种打击。
幸运的是，当前也存在着一些提议，它们可以提高比特币网络的效率，并降低更大区块将会产生的风险。而其中最有前途的创新，就是可逆式布鲁姆查找表（Invertible Bloom Lookup Table），或者简称为IBLT，如图2-2所示。
图2-2 IBLT原理示意图
这一概念首先是由Bitcoin Core和Bitcoin XT开发者加文·安德烈森（Gavin Andresen）提出的，那么这个可逆式布鲁姆查找表解决了什么问题呢？
通常情况下，所有的比特币交易，都是通过节点到节点来完成对等式网络交易的，然后通过个人节点的内存池（mempool，记录未确认的交易）进行存储。当一位矿工发现一个区块时，它包括（部分）区块中的交易，随后便会在同一对等网络中广播该区块。当然，这也意味着，区块中的所有交易，都有效地在网络上发送了两次：一次作为一笔交易，另一次则作为区块的一部分。可见，在区块中已经有了冗余。不过，大多数节点已经知道该区块包含的一些内容了。因为它们已经看到过了，如果我们能够优化它，那么就可以加快区块的广播速度。这也降低了中心化的压力，因为矿工们可以更快地将他们的区块弄出来。
其基本原理如下：首先，在一个区块中包含的所有交易，都会写入一个表（table）中，每一笔交易均会始于表上每一个不同的点。然而，存在的交易数远多于表的空间（room），所以它会导致令人绝望的重叠结果。这使得IBLT显得非常密集，但对于那些无法访问任何交易数据的人而言，IBLT是无法读取的，也是无法破译的。而那些拥有交易数据的人，则可以通过使用类似的逻辑，将他自己的交易填充到一个IBLT中，然后比较IBLT上的重叠交易数据。如果两个IBLT最终看起来完全一样，这就意味着所有的交易都是完全匹配的。即使这两个IBLT最终看起来并不是完全相同，但只要交易集是非常相似的，这就可能仍然是有用的。在这种情况下，这两个IBLT可以进行比较，采用这种方式，所有相同的交易就可以抵消掉一方。而IBLT中“剩余的”交易，往往可以用于重构丢失的交易。
2.5.2 隔离见证
每一个比特币交易，都可以分为两部分。第一部分是转账记录，第二部分是用来证明这个交易合法性（主要是签名）的。第一部分可称为“交易状态”，第二部分就是所谓的“见证”（witness）。如果你只关心每个账户的余额，那么转账记录就已经足够。只有部分人（主要是矿工）才有必要取得交易见证。
中本聪设计比特币时，并没有把两部分资料分开处理，因此导致交易ID的计算混合了交易和见证。因为见证本身包括签名，而签名不可能对其自身进行签名，因此见证可以由任何人在未得到交易双方同意的情况下进行改变，造成所谓的交易可塑性（malleability）。在交易发出后、确认前，交易ID可以被任意更改，因此基于未确认交易的交易是绝对不安全的。在2014年就曾有人利用这个漏洞大规模攻击比特币网络。
比特币核心开发员Pieter Wuille在2015年12月于香港提出的隔离见证（Segregated Witness，以下简称SW）软分叉解决了这个问题。SW用户在交易时，会把比特币传送到有别于传统的地址。当要使用这些比特币的时候，其签名（即见证）并不会记录为交易ID的一部分，而是进行另外处理。也就是说，交易ID完全是由交易状态来决定的，不会受见证部分的影响。这种做法有如下几个重要的结果。
可以用软分叉增加最大区块容量。因为旧节点根本看不到这些被隔离的见证，即使真实的区块已经超过了1MB，它们仍会以为没有超过限制而会接受区块。在整场有关区块容量的辩论中，最大的难点就是硬分叉。SW可以提供约2MB的有效区块空间而没有任何硬分叉风险。
从此以后，只有发出交易的人才可以改变交易ID，没有任何第三方可以做到。如果是多重签名交易，那么只有得到多名签名人的同意才能改变交易ID。这可以保证一连串的未确认交易的有效性，是双向支付通道或闪电网络所必须具备的功能。有了双向支付通道或闪电网络，二人或多人之间就可以从实际上进行无限次交易，而无须把大量零碎交易放在区块链上，从而大大降低区块空间压力。
轻量钱包可以变得更轻量，因为它们无须再接收见证数据。
可以大幅改善签名结构。在区块链上，曾经有一个超过5000个输入的交易，因为签署设计缺憾，需要半分钟才能完成检查。SW软分叉解决了这个问题。
2.5.3 闪电网络
比特币从诞生之日起就一直存在着若干个技术问题，比如交易处理能力，目前全网每秒只有7笔交易；其次是区块产生时间，现在大致是每10分钟出一个块；再其次是交易确认问题，一般建议在等待6个区块后才视为交易被确认，大额交易则建议等待更长时间；最后是容量，目前已经生成了40多万个区块，约60GB的数据量，且眼见的未来中只见增加不见减少。这些无疑会是区块链技术在实际应用中的一大障碍。
在闪电网络出现之前，虽然比特币社区也试图通过区块扩容、隔离见证等技术在一定程度上提高交易处理的能力，但这些方式并不能导致交易处理能力出现数量级的改善。至于前面提及的其他技术难题，也不是短时间内就能攻克的，比如，现存的PoW机制是万万动不得的，需要等待多个区块的确认也是不能触碰的底线，更麻烦的是，交易处理能力和区块链数据容量似乎是一对无可调和的矛盾。
因此，闪电网络提供了一个可扩展的微支付通道网络。交易双方若在区块链上预先设有支付通道，就可以多次、高频、双向地通过轧差方式实现瞬间确认的微支付。双方若无直接的点对点支付通道，只要网络中存在一条连通双方的、由多个支付通道构成的支付路径，则闪电网络也可以利用这条支付路径实现资金在双方之间的可靠转移。
闪电网络并没有试图解决单次支付的银货对付问题，其假设是单次支付的金额足够小，即使一方违约另一方的损失也非常小，风险可以承受。因此使用时必须注意“微支付”这个前提。多少资金算“微”，显然应该根据业务而定。
2.5.4 RSMC
闪电网络的基础是交易双方之间的双向微支付通道，RSMC（Recoverable Sequence Maturity Contract）定义了该双向微支付通道的最基本工作方式。
微支付通道中沉淀了一部分资金，也记录有双方对资金的分配方案。通道刚设立时，初始值可能是{Alice: 0.4, Bob: 0.6}，这意味着打入通道的资金共有1.0 BTC，其中Alice拥有0.4 BTC，Bob拥有0.6 BTC。通道的设立会记录在比特币区块链上。
假设稍后Bob决定向Alice支付0.1 BTC。双方在链下对最新余额分配方案{Alice: 0.5, Bob: 0.5}进行签字认可，并签字同意作废前一版本的余额分配方案{Alice: 0.4, Bob: 0.6}，Alice实际上就获得了0.5 BTC的控制权。如图2-3所示。
如果Alice暂时不需要将通道中现在属于她的0.5 BTC用作支付，那么她可以无须及时更新区块链上记录的通道余额分配方案，因为很可能一分钟后Alice又需要反过来向Bob支付0.1 BTC，此时他们仍然只需要在链下对新的余额分配方案达成一致，并设法作废前一版本的余额分配方案就行了。
图2-3 RSMC账户余额分配示意图
如果Alice打算终止通道并动用她的那份资金，那么她可以向区块链出示双方签字的余额分配方案。如果一段时间之内Bob不提出异议，那么区块链会终止通道并将资金按协议转入各自预先设立的提现地址。如果Bob能在这段时间内提交证据证明Alice企图使用的是一个双方已同意作废的余额分配方案，则Alice的资金将被罚并给到Bob。
2.5.5 HTLC
RSMC只支持最简单的无条件资金支付，HTLC（Hashed Timelock Contract）则进一步实现了有条件的资金支付，通道余额的分配方式也因此变得更为复杂。
通过HTLC，Alice和Bob可以达成这样一个协议：协议将锁定Alice的0.1 BTC，在时刻T到来之前（T以未来的某个区块链的高度来表述），如果Bob能够向Alice出示一个适当的R（称为秘密），使得R的Hash值等于事先约定的值H(R)，Bob就能获得这0.1 BTC；如果直到时刻T过去Bob仍然未能提供一个正确的R，那么这0.1 BTC将自动解冻并归还Alice。
由于到期时间T、提款条件H(R)、支付金额和支付方向的不同，同一个通道上可以同时存在多个活动的HTLC合约，再加上唯一的通过RSMC商定的无条件资金余额，余额分配方式会变得相当复杂。下面以图2-4为例来讲解这一大致流程。
图2-4 HTLC交易流程示意图
如图2-4所示，Alice想给Dave发送0.05 BTC，但Alice和Dave之间并没有微支付通道。Alice找到了一条经过Bob、Carol到达Dave的支付路径，该路径由Alice/Bob、Bob/Carol和Carol/Dave这样三个微支付通道串接而成。
此时，Dave生成了一个秘密R并将Hash(R)发送给Alice，Alice不需要知道R。
该交易的流程具体如下。
1）Alice和Bob商定一个HTLC合约：只要Bob能在“3”天内向Alice出示Hash正确的R，Alice就会支付Bob 0.052 BTC；如果Bob做不到，这笔钱将3天后自动退还Alice。
2）同样地，Bob和Carol商定一个HTLC合约：只要Carol能在“2”天内向Bob出示Hash正确的R，Bob就会支付Carol 0.051 BTC；如果Carol做不到，这笔钱到期后将自动退还Bob。
3）最后，Carol和Dave商定一个HTLC合约：只要Dave能在“1”天内向Carol出示Hash正确的R，Carol就会支付Dave 0.05 BTC；如果Dave做不到，这笔钱到期后将自动退还Carol。