【区块链】HyperLedger Besu简介

在调研区块链技术时了解到现在大部分区块链都是用GoLang、C或C++、Nodejs来写。但对于我这个忠实的Java信徒来说还是希望能够有Java的解决方案。那有没有原生就适配Java的SDK或者客户端呢？

有。

fabric-sdk-java就是专门为HyperLedger Fabric提供的Java端SDK接口，虽然维护（提交）的人少但是活跃度一直都维持着的。那我又会想，有没有整个客户端都是由Java写的呢（我承认到这里就有点执着了，想整套解决方案都用Java实现）？最终在HyperLedger全家桶中我发现了Besu。

这一年是2018年，我跟Besu的第一次相遇。

Besu整个客户端都是通过Java编写使用的是Vert.x技术，利用了EventLoop（事件循环）解决异步上链的性能问题（这因为eth1.0的BFT机制引发的，后面会详细说明）。平心而论，在使用Besu的过程中并没有感觉到它比其他以太坊客户端差。

1. Besu的前世今生

Besu本不属于HyperLedger原名Pantheon，由ConsenSys的PegaSys团队提供维护的开源产品，而之后加入Linux基金会的开源区块链组织（HyperLedger）因此正式将Pantheon改名为Besu。在收购了摩根大通Quorum后Quorum将作为ConsenSys的GoLang解决方案继续延伸。2018年底ConsenSys官网上提供的基于Besu的解决方案如下：

含有单独提供的Besu、Orion（现已有其他替代方案）、EthSigner（现已有其他替代方案）安装包，也有Besu Bundle以捆绑包的方式打包使用。如果您是不使用容器的情况下建议直接使用Besu Bundle来运行，因为所有的组件直接就整合完成一句脚本就可以简单运行起来。

但本次我将使用到Docker来进行整合所以会单独下载对应镜像后再整合。

2. PoA共识算法

2.1 Besu特有IBTF2.0共识算法

当初选择使用Besu的原因主要是对IBFT2.0共识算法感兴趣。目前所有基于PoA的共识算法来讲IBFT2.0在性能性和安全性上面取得了平衡。

其实，一般来说IBFT1.0共识算法已经足够理想了，但是在理论上会存在缺陷。通过与两组验证者达成共识，拜占庭提议者可以在区块链同一高度上分配不同的区块，例如，如果网络有5个验证器，则IBFT 1.0只需同意3个节点，即可将下一个块添加到区块链。如下所示：

拜占庭式提议者可以使用两组不同的验证器在不同的区块上达成共识，因此Besu开发团队提出了更为完善的IBFT2.0。

2.2 IBFT2.0特点

1. IBFT2.0由多个验证者组成验证者组，验证者能够通过投票来新增和删除验证者；
2. 整个区块链中必须运行至少2/3的验证者才能继续创建块；
3. IBFT2.0不允许派生，并且总会有一个主链。也就是说IBFT2.0能够在原生上解决双花问题，也不需要UTXO来解决；
4. 由于它采用的PoA的共识算法模式，因此采用的是数据签名来保证区块的正确性；
5. 由于IBFT2.0目前只有Besu能够支持，所以在项目应用上还需要多加考虑。毕竟Besu相比于Geth本来就是小众，社区和成熟度在国内都还在成长中，这要在实际项目中应用还需要长期的验证和考验；

2.3 Clique共识算法

除IBFT2.0外Clique是另一种PoA共识算法。相比于IBFT2.0，Clique的使用范围更广。目前几乎所有的以太坊客户端都支持Clique，它具备以下特点：

1. 它是一种确保容错能力的保护算法，它最多可以接受一半的验证器失败，公式为： N-(N/2+1)，推演节点如下图：

2. 它跟IBFT2.0一样使用数字签名来密封这些块并实现数据不变性，且每个区块仅由一个签名（即提议者的签名）密封；
3. 当以太坊GHOST协议整理出分叉时，Clique特别提供了最终的PBFT与PoA分析一致性；
4. 由于多个以太坊客户端都支持使用Clique共识算法，所以Clique组成的区块链网络是可以接入不同的客户端的。譬如：我用的是Besu，你用的是Geth，他用的是Go Quorum。Geth和Go Quorum都可以通过配置信息无缝接入到Besu的Clique网络中；

3. PoW共识算法

Besu中也提供了名为Ethash的PoW共识算法。但是一般来说企业应用不会使用PoW共识，哪怕私有链可以将gas limit变为0。因为企业应用一般来说都具备明确的接入节点信息和用户信息，在一般情况下上链的内容都应该是可控且清晰的。而PoW共识之所以要通过大量运算来保证区块的真实性原因在于在公链上无法得知接入人身份和目的，只能通过大量的算力来提高数据的安全性。安全性提高的代价就是资源被严重消耗。这些都与企业以成本控制为目的的理念相违背。因此PoW共识区块链很难在企业中使用甚至推广。

除此之外，PoW算法还具备以下几个缺点：

1. 算力被严重消耗；
2. 区块生成到后期难度会越来越大，这是因为区块的总量是有限的，剩余数量越少越难以发生碰撞；
3. 普遍存在双花问题，只能通过DAG（有向无环图）和UTXO来解决；
4. 只有节点数量庞大的时候才不会发生数据被重写的情况，这是因为要改写PoW节点数据至少要改写链上51%节点内数据。基于这种情况，如果区块链节点是3个的情况下，我只需要占领2个节点就可以篡改数据了。因此唯有节点量庞大的情况下数据在PoW节点中是安全的；

4. IBFT(伊斯坦布尔拜占庭容错算法)讲解

为什么要讲解IBFT？因为IBFT容错算法应该是区块链中主流的容错算法了。就选几个重点来说：

1. IBFT是建基于PBFT（实用拜占庭容错算法）修改优化的实现；
2. 诞生原因在于保证即时的确定性，也就是意味着一旦将交易结果添加到的区块中，就可以保证它始终是区块链的一部分；
3. 每个区块都需要一组验证者进行多轮投票才能达成共同协议，块上必须带有签名者的数字签名；
4. 可以容灾节点极限为总量的1/3，具体如下图：

；

5. 验证者节点公式为：floor(N/2)+1，一般建议验证者个数>=4；
6. IBFT使用三相共识机制“PRE-PREPARE”，“PREPARE”和“COMMIT”，这一点继承了原始PBFT，如下图：

在每个回合之前，都会从验证者池中挑选一个提议者（例如，以循环方式）。然后，提议者将提出一个新的整体提议，并将其与PRE-PREPARE消息一起广播。验证者从提议者接收到PRE-PREPARE消息后，进入PRE-PREPARED状态，然后广播PREPARE消息。此步骤是确保所有验证器都在相同的序列和相同的回合上工作。之后，接收到2F+1 PREPARE消息的验证器进入PREPARED状态，然后广播COMMIT消息。此步骤是告知其对等方它接受建议的块并将要插入到链中。最后，验证器等待2F+1的COMMIT消息进入COMMITTED状态，然后将块插入到链中；

5. 各项横向对比

5.1 算法对比

| 对比参数 | PoW
（Proof of Work 工作量证明） | PoA
（Proof-of-Authority 权威证明） | PoS
（Proof of Stake 权益证明） | PoET
（Proof-of-Elapsed-Time 经过时间证明） |
| --- | --- | --- | --- | --- |
| 实现原理 | 采用Hash地址碰撞来获得区块，所以全网挖矿需要耗费大量的资源和算力 | 区块网络中将出现验证者角色而不是单纯的账号角色。链上网络、区块、数据都必须经过验证者验证方可自动执行 | 权益证明模式就是一个根据所持有货币的量和时间，来发利息的一个模式。 | 这是一种依赖硬件的共识算法。在每个节点都能获得在网节点的基础上，通过上一区块Hash随机抽签选出出块人 |
| 硬件要求 | 要求CPU或GPU的浮点精度高，并且需要并行多路运算来计算区块Hash地址 | 硬件要求不高，与一般系统几乎无异，其中内存和磁盘空间根据使用技术的不同会略有差异 | 与PoW相比，虽然都需要挖矿，但是PoS不需要为了生成新区块而大量消耗电力，也在一定程度上缩短了共识达成的时间 | 采用 Intel® Software Guard Extensions (SGX) 来随机选出一个出块人（无法作弊） |
| 适用场景 | 由于安全性高适用于主网比特币的挖掘 | EEA（企业区块链模式）略微中心化，普遍适用于私有链与联盟链使用 | 由于算法存在漏洞，在币圈中已经基本被淘汰 | HyperLedger Sawtooth中使用到此算法，多配套PoW算法用作供应链溯源 |

除了上述的几个之外，还有PoC、DPoS等由于没有大规模使用所以就不再叙述了。综上所述可以看出基于PoA的共识算法应该是联盟链的首选。

5.2 客户端对比

从上表可以看出若要做成开源且完整的Java解决方案，没有比HyperLedger Besu更适合的了。

5.3 Clique与IBFT2.0对比

都是PoA共识，Clique和IBFT2.0各有优势，主要是看具体的业务场景。

6. 后话

其实个人觉得HyperLedger Besu区块链算是比较好部署和实施的区块链，当然在成熟度上面跟Geth还是无法比拟的，但是只要配置到位没有部署不起来的。所以如果出现无法部署的情况90%的可能性是因为配置文件出现问题了（经验之谈）。

另外，现在网上大部分的Besu教程都是教如何通过二进制版本来部署的，很少有直接Docker部署估计大部分Docker在于异地组网的问题导致的。大家都知道区块链是一个分布式账本，若无法解决异地部署将会毫无意义。使用二进制发行版来部署只要有一个对公IP就可以了，成功率高且不用担心网络延迟问题推荐初学者可以通过这种方式快速部署。

后面的分享我就不会过多介绍Besu概念性的东西了，主要说一下详细的实施过程告诉大家如何一步一步地搭建这个Besu区块链。