在实际环境中，我们放弃了以太坊，选择了Hyperledger

本文要点：

不久前，我们的团队探索了在生产环境中部署基于 Hyperledger 的区块链。 本文介绍了我们对其进行集成的尝试、我们遇到的问题以及帮助解决这些问题的技巧。 Hyperledger 框架中引入了一些重要更新以克服一些挑战，但仍有一些问题需要解决。

在本文的第一部分，我们将解释为什么我们决定使用区块链来解决业务问题，以及为什么我们选择 Hyperledger 框架而不是以太坊。 本文第二部分主要介绍基于Hyperledger的区块链架构以及该框架的实现技术。

为什么要使用区块链？

我们最初认为我们的业务不需要区块链。 毕竟，大多数公司通过诉诸集中设施或仲裁中心来解决信任问题。 所以我们花了很长时间才弄清楚我们是否特别需要一个区块链解决方案。

我们的平台是一个网络资源，公司可以在其中直接与开源团队合作，以减少开发时间和维护成本。 我们发现，对于某些客户来说，与开源维护者和主要合作者建立工作关系可能很困难。 由于项目时间和价格的增加，依靠内部开发人员或自由职业者的服务来微调开源代码的标准做法看起来并不理想。

我们的平台旨在通过为客户提供一个“入口点”和简单的界面来请求和共同资助 OSS 中新功能的开发来解决这种低效率问题。 为了使系统可持续发展，我们需要引入一种工具来鼓励开发人员满足客户需求。 经过深思熟虑，我们提出了“数字所有权”的概念。

这个概念相当简单：在我们平台上注册项目的人会收到数字“股票”，他们可以将自己转让给共同贡献者。 顾名思义，我们的股份使所有者能够获得与其所有权份额成比例的项目收入。 在该约束之上，我们添加了一条规则，即任何“外部”开发人员都可以创建所请求的功能，并且，如果客户接受该解决方案，开发人员将获得一定比例的项目库存。

我们希望开发者将我们的项目份额视为有价值的长期资产，这本身就意味着开发者相信这些份额不会消失。 基本上，我们有两个选择：要么在社区信任我们之前不引入该功能，要么构建一个无需信任的系统。 后者需要建立一个平台，即使母公司退出业务，资产也不受影响。

我们还计划将平台与多家合作机构进行整合，将开发任务外包给我们的平台，任务完成后自动收取费用。 理想情况下，我们会通过一些简单的注册过程（例如 API 集成）为组织提供进入我们网络的单一入口点。 我们的目标是使此过程尽可能简单，以避免所有法律合规性和文书工作。 经过一番质疑，我们认为区块链可以帮助我们实现这个愿景。

以太坊与超级账本的比较

以太坊是我们的首选，尽管我们对这个平台没有丰富的经验。 我们没有详细研究文档，就直接开始集成了。 乍一看，这似乎是一个简单的选择。 由于以下几个因素，我们选择尝试一下：

相反，有一些因素最终让我们打消了之前的想法，以太坊可能并不是最适合我们的选择：

其中一些问题有可能在以太坊世界的发展中得到缓解。 例如，GHOST 协议修改可能会有所帮助，但即使在这种情况下，当我们的大量交易正前往目的地时，如果主池的所有者突然决定其分支链比我们的长......。 ..那么，如果交易是通过公共（或共享使用）以太坊网络进行的，取消支付交易可能会让我们感到惊讶。

在极端情况下，我们甚至可能有一个合作者，其节点容量允许他们破坏整个网络，那么使用区块链就没有意义了。

了解网络成员是客户还是合作者对我们来说也很重要。 我们必须确认这一点。 以太坊网络不支持这个功能，所以我们需要在上面构建这个功能。 当然我们可以将我们的 VPN 集成到区块链中。 但是，如果我们向合作者提供访问权限，那么自然应该有一种方法来启用这种访问权限。 同时，我们希望控制谁可以访问我们的网络以及他们可以从中获得什么。

要记住的关键是，在业务用例中，企业节点的容量可能比私有节点具有明显的优势。 这就是我们选择使用 Hyperledger 框架的私有区块链的原因。

Hyperledger 还为我们提供了比以太坊更大的便利，让我们可以观察交易成本和 CPU 使用情况。

目前，Hyperledger Fabric 是最先进、最成熟的框架之一。 它还具有一些与众不同的功能。 许可架构确保当有人访问我们的区块链时，我们知道他们是否拥有证书颁发机构 (CA) 颁发的证书。 我们也喜欢它的确定性 PBFT 算法，它让我们 100% 确定一旦我们收到这样的通知，交易就已经完成。 在 docker 容器上进行测试也很容易。

我们正在尝试弄清楚我们是否需要拜占庭容错。 我们真的信任我们的合作者，他们真的信任我们吗？ 知道任何节点随时都可能开始向网络发送不正确的数据，我们自己能承受拜占庭将军问题吗？ 我们最终决定我们应该有这样的保护，而 Hyperledger 使它变得相当简单。

但我们仍然不确定，所以我们在私有网络中进行了一些测试，以将 Hyperledger Fabric 与以太坊进行比较。 我们编写了一个简单的合约，生成一个长数组，然后对其进行排序。 结果如下所示。 我们在图表中添加了 2 行（分别具有 1M 和 10M 元素）只是为了表明 Hyperledger 也在这里。 其实差别还是蛮大的，有些线条其实是看不出来的。

现在，让我们看看达成共识所需的时间。 我们采用了一个简单的空事务并将其放入一个由 8 台机器组成的集群中。 机器必须达成一致并返回确认：我们等待以太坊私有网络中的 6 次确认，以及 Hyperledger 网络中每个节点的确认。 在hyperledger集群中，速度还是比较快的。

需要注意的一件事是，我们在 Hyperledger Fabric 框架的 0.6 版上进行了测试； 今天最新版本是1.2.0，单节点负责维护交易秩序。 当时，如果我们将节点数量增加到 16 个，将速度提高到每秒 500 笔交易，网络将无法运行。 以这种速度，网络无法达成共识，直到收到新的交易请求。

超级账本架构

在我们继续之前，让我们看一下 Hyperledger 区块链的基本架构。

对等节点（Peer）：主节点，存储所有交易信息（在1.0版本中，分为背书节点（Endorser）和提交节点（Committer），用于确认交易和将交易记录到注册中心。）

应用（App）：发起交易的客户端，在Hyperbook SDK上可以换成自己的应用

CA：向用户提供证书，允许他们进行交易并从注册表中读取数据

Orderer：管理区块中的交易，并将区块传递给节点记录在账本中

Hyperledger 可以按角色区分节点。 特别是，有一个存储注册表的对等节点。 从 1.2 版开始，对等节点有多种子类型，但一般来说，对等节点负责存储注册信息和验证传入交易。 他们存储所有智能合约和链代码，批准传入交易并将它们保存在注册表中。

我们构建的应用程序位于前端。 它可以将交易信息发送到区块链，它可以使用会员证书登录区块链。 它还负责达成共识。

CA 颁发证书。 默认情况下，Hyperledger 可以通过组织属性来区分节点； 每个组织都有自己的根证书。 有了会员证书，我们可以分配权限来完成智能合约、更改网络配置、添加新节点，基本上我们想要的一切。 在最新的框架版本中，我们还可以为证书添加我们喜欢的任何属性，这样我们就可以更灵活地为系统参与者提供不同的权限集。

排序服务或“排序节点”是负责对区块中的交易进行排序的一系列节点。 这些排序者将交易信息收集到一个块中，并将该块发送给同行，以便他们可以将其提交给注册表。 它不存储智能合约，而是存储二进制文件中的分类账数据，用于引导新节点。 丢失此文件意味着丢失所有区块链数据。 订购者也做一些验证工作：检查散列和签名。

例如，我们的系统由以下元素组成：

目前，我们的区块链部署在四个真正的对等节点上，我们在 Kafka 上有 4 个排序节点。 我们最终需要 5 个，因为如果在此模式下使用排序服务，建议使用奇数个节点。 我们有大约 100 个客户端应用程序、1 个根 CA 和 1 个中间 CA。 在我们工作的前几个月，我们进行了 1000 多笔交易，但我们的系统允许我们在一秒钟内处理相同数量的交易。

合作者有自己的对等点，因此他们可以存储注册和验证交易，客户可以引用他们喜欢的任何对等点与区块链进行交互。

客户端应用程序通过提供由区块链信任的证书颁发机构（例如“组织 1”）的中间服务器颁发的证书来登录到区块链。 CA中间服务器由CA根服务器授权，CA根服务器不受区块链网络限制。 然后，客户端应用程序可以在可用策略框架内与对等节点进行交互，但要遵守限制和权限。 一旦任何对等节点确认了应用程序提交的交易，如果它使用任何共识算法，则交易被发送给排序者。 排序节点将这些交易提交给对等节点。 然后，应用程序可以等待来自同行的任意数量的确认，以确保交易记录在分类帐中。

在生产中实施 Hyperledger Fabric 是什么感觉？

也许我们首先注意到的是缺少管理面板。 如果没有 Kubernetes 或 Swarm，我们很难在生产模式下维护它，所以我们不得不编写大量的支持脚本。 希望 Cello 项目能让这一切变得更好。

在尝试实施此架构时，我们遇到了一些技术挑战。 首先，排序节点服务可以运行在两种模式下，即单机模式（solo mode）和Apache Kafka模式。 如果我们使用单体模式，如果不重构整个网络，就没有办法切换到可扩展模式。

其次，如果我们在 Kafka 上使用 orderer 服务，那么我们不能将它扩展到其他组织。 如果其他组织已经有自己的排序节点服务，那么我们需要就谁将负责管理区块中的交易达成协议。 这意味着，只有一个组织可以负责一个区块中的交易顺序，这会导致一些漏洞。 然而，一般来说，如果交易是有效的，那么它们在区块中的顺序并不那么重要。 如果有人改变了交易的顺序并且它们变得无效，它们可以简单地在区块中被标记为无效，我们的请求将返回“失败”。

CA（证书颁发机构）易于扩展。 每个组织都有一个根 CA，它可以向中间 CA 颁发任意数量的证书。 这很好，因为 CA 负责向网络添加新用户。 但是，这种证书吊销模型还不够完善。 首先以太坊的共识机制有四个版本，我们需要编写额外的链代码以请求多方签署已撤销的证书。 其次，即使我们将有关已撤销证书的信息添加到区块链中，该证书的前所有者仍然可以连接到对等方。 我们必须手动生成证书并将它们添加到对等点并对文件夹进行排序。 在分散结构中控制此类流程具有挑战性。

我们还需要记住，对注册表的所有查询都将返回网络的先前状态（即注册表具有事务性，即版本化语义），直到排序者创建了一个新块。 这意味着如果我们有一个业务流程由多个读取查询和一个考虑读取查询结果的写入查询组成，我们最好让它们异步。 因为在这种情况下，我们读取注册表的预期会与它的实际状态不一致。 通常，我们需要等待排序者形成一个块并将其发送到账本； 只有在那之后，假设状态已经改变，我们才能发送一个读取查询。

由于这些块不是根据 POW 协议创建的，我们可以为排序服务设置任何块创建频率。 在单一模式下，我们每秒最多创建一个块，但在 Apache Kafka 模式下，我们可以灵活地配置此参数。 但是请记住，如果我们减少创建新块的等待时间，那么我们的网络规模将会迅速增长。 磁盘空间也会被快速消耗，所以我们总是需要在交易确认速度和容量之间取得平衡。

共识机制是在交易层面实现的，因此我们可以指定交易需要遵循的要求才能在智能合约中生效。 例如，当我们在链码中引入一个新的智能合约时，我们可以设置它的确认程序，并设置需要多少参与者签署交易才能保持有效。

智能合约可以用多种语言编写以太坊的共识机制有四个版本，Golang 和 Java 是主要选择。 典型的智能合约具有最简单的结构。 智能合约中只需要使用两个简单的方法：一个是在设置或升级新的链代码时调用（init），另一个是在调用时调用（invoke）。 配置不同的策略来初始化新的智能合约并调用它。 一组用户可以负责更新智能合约，另一组用户可以负责其实施。 这里，我们考虑最简单的函数调用，将一个函数及其参数作为输入参数，根据函数名调用想要的方法。

在 Hyperledger 中存储数据可以看作是键值映射，称为 KV 存储。 使用 KV 存储是非常低级的。 使用 PutState() 方法，我们可以在 KV 存储中编程并使用 GetState() 从中读取。 但最有趣的是，我们可以使用证书属性来处理智能合约。 在下面的示例中，我们可以看到授权用户的公钥哈希如何用作其钱包的身份。 在第 395 行，我们得到一个哈希并将其用作 KV 存储的键。

虽然，我们仍在使用框架的 0.6 版本，但较新的版本包含一些重大改进，我们必须提到：

超级账本体验概述

从技术角度来看，该系统仍在开发中（非常强大）。 但是，存在一些技术问题，希望社区能够找到解决方案。 尽管如此，我们认为 Hyperledger 是希望在实际业务中实施区块链的公司的最佳选择之一。

在业务方面，由于这个框架，我们成功地实现了所需的数字所有权功能，这有助于我们激励开发团队从事开源项目。 该网络易于扩展并且没有父组织存在。 如果我们不在了，那么社区同意建立一个新的订购服务，一个更新通道，并且工作可以继续。

根据我们收到的反馈，此功能有助于平台的采用，因为我们的用户不需要信任我们并依赖我们开展业务的能力。 我们正在积极寻找合作伙伴移交节点，并计划在 2019 年初对我们的区块链进行首次技术集成。

关于作者

Maslov 是开源软件货币化平台 OpenGift Inc. 的首席执行官。 他还是 Hive 项目的负责人，该项目支持组织内的代码重用。 Yegor 在网络和移动领域拥有超过 15 年的软件开发经验，并且拥有广泛的技术创业背景。

Erokhin 是一名 DevOps 工程师，拥有超过 10 年的专业经验。 他曾在以下公司工作：Kaspersky、Sberband Technologies 和 Moscow Stock Exchange。

阅读英文原文：探索HyperLedger：成为框架早期采用者的经验

活动推荐

业务突飞猛进，许多软件开发领域进入成熟期。 在数据驱动和智能化的过程中，技术人员可以从哪些方面进行突破？ 2019年5月6日-8日，QCon与您相约北京国际会议中心，看看100+技术团队负责人有哪些实践探索。 点击“阅读原文”或识别二维码查看会议日程。 现在购票，限时立减10折，立减880元，团购更有优惠！ 如有疑问，请联系售票小姐 电话/微信：17310043226