Hyperledger是Linux基金会领导的区块链技术项目集合，由成员捐赠的众多开源项目组成，其中最广为开发者熟知的当属由Digital Asset和IBM最初主导开发和贡献的Fabric项目。Fabric作为首个超级账本项目，其流行度之高，以至于在很多上下文语境中，当我们单独讨论Hyperledger或超级账本时，基本上指的都是Fabric项目。
但是，作为一个旨在推广区块链技术的项目集合，Hyperledger还包含很多其他优秀的区块链开发框架和工具箱。由于公开的资料（特别是中文资料）特别少，项目官网上的介绍也比较概略，现有的消息源大多也是照搬官网上的信息，很多国内开发者对这些项目了解的不多。
本文希望通过详细地逐一介绍这些框架和工具各自的特色，并且跟大家都比较熟悉的Fabric进行对比，帮助开发者更多地了解Hyperledger项目族，在做方案评估和技术选型的时候也能够更加游刃有余。
Hyperledger Sawtooth
当前状态：Active
在通常的理解中，一个大的顶层项目所包含的子项目往往作为相互独立的模块承担不同的功能，最终共同对外提供完整的能力。但是在Hyperledger中，其实包含了很多相似的项目，他们虽然有各自的优势和特点，但是也存在着一定的功能重合和竞争关系。正如Fabric来自于IBM，Hyperledger Sawtooth来自于Intel捐赠的Sawtooth Lake项目。
区块链项目的核心是其共识算法，比如比特币网络采用工作量证明算法（Proof of Work，PoW）；以太坊目前采用PoW，将来会逐步替换成权益证明算法（Proof of Stake，PoS）；Fabric支持多种可插拔的共识算法，目前默认采用基于Kafka的排序策略。与Fabric类似，Sawtooth也支持可插拔的共识策略，但是默认采用流逝时间证明算法（Proof of Elapsed Time，PoET），这也是其区别于其他区块链框架的特色。
所谓共识，即分布式网络中的节点争抢记账权的过程，与依赖计算能力或者网络带宽的算法不同，在PoET中，每个参与节点都会启动一个定时器等待随机长的时间，最先超时的节点获得记账权。因为既不需要复杂的计算过程，又不会随着网络节点数的增多带来额外的带宽压力，所以PoET算法有着非常好的性能，可以支持很大规模的网络，这也让Sawtooth成为Hyperledger项目中理论上可扩展性最好的框架。虽然设计上非常简单，但是要实现上述简单的算法，却面临一个非常棘手的问题：如何保证每个参与节点诚实地等待了随机长的时间，而无法为了在共识过程中取胜而作弊呢？Intel给出的答案是自家CPU特有的扩展指令集Intel Software Guard Extensions（Intel SGX）。SGX简单地说就是通过CPU硬件提供一种在受保护环境中运行可信任代码，并且对外提供审计查询能力的技术。
在智能合约部分，Fabric的Chaincode现在完整支持Go和JavaScript，在Sawtooth中也有类似的概念，叫做Transaction Processor，目前完整支持Python、Go和JavaScript，不久会加入对Rust、Java和C++等的支持。原生的Fabric Chaincode对外提供基于gRPC的接口，而Transaction Processor则对应有REST API接口。
除此之外，在Hyperledger的三种区块链框架（Fabric，Sawtooth和Iroha）中，Sawtooth也是唯一一个支持非受限（Permissionless）网络类型，也即公有链的框架。
综上，Sawtooth作为一个完整的企业级区块链技术框架，在某些方面有着自己独特的优势，可以说是Fabric强有力的竞争对手。
Hyperledger Iroha
当前状态：Active
从其名字就可以看出，这是一个明显具有日系血统的框架。Iroha项目来自Soramitsu，Hitachi，NTT Data和Colu等日系公司的捐赠，是一个基于C++实现的区块链框架，最初被设计用来在移动平台上实现数字资产和数字身份的管理。
相比于其他两个平台，Iroha显得非常轻量，因为开发者不需要（也不能）自己实现智能合约，而是可以通过平台预先提供的命令和查询指令轻松地完成诸如创建数字资产、注册账户和转移资产等操作，这使得Iroha成为Hyperledger中最易上手的框架，开发者能够简单快速地创建自己的区块链应用。不过，从另一个角度来说，不能通过实现智能合约进行扩展也限制了平台的使用场景。此外，在Iroha中有完善的基于角色的访问控制（RBAC），与之相比，Sawtooth的数据完全裸奔和Fabric不够灵活的Channel机制在企业级应用场景中就显得比较简陋了。
在共识算法上，Iroha自己中规中矩地实现了基于实用拜占庭容错算法（PBFT）的YetAnother Consensus（YAC）和基于Kafka的排序服务。平台对外暴露了gRPC接口，由于不需要额外去完成智能合约的部分，任何实现了其协议的客户端都能够跟平台进行交互，所以Iroha几乎支持所有主流的开发语言，在Android和iOS等移动平台上也可以部署。
总结一下，Iroha项目是一个强调开箱即用的轻量级的专精移动化平台和数字资产及数字身份管理的区块链开发平台，有着完善的访问控制机制，是一个非常有特色的开发框架。
Hyperledger Burrow
当前状态：Incubation
Hyperledger Burrow项目是由Monax和Intel共同捐赠的，其核心组件是参考以太坊的智能合约运行环境Ethereum Virtual Machine（EVM）标准实现的解释器，可以兼容运行针对以太坊网络开发的智能合约。相较于以太坊项目采用的GNU GPL/LGPL开源许可协议，Burrow采用了对商业使用更加友好的Apache协议。
Burrow项目的目标是构建一个通用的智能合约运行和开发平台，类似于JVM的定位。
值得指出的是，Burrow可以作为一种Transition Processor的实现运行在我们上面提到的Hyperledger Sawtooth平台上。
Hyperledger Indy
当前状态：Incubation
Hyperledger Indy是由Sovrin基金会捐赠的开源项目，是基于区块链不可篡改的特性实现的身份和凭据管理平台。在现实世界中，我们通过提供诸如驾照、身份证、学历证明、机票这样的文件凭据来证明自己的身份，这些身份信息最终被存储在不同的系统中，我们的个人信息和隐私也随着这些信息的流通暴露在整个互联网上。Indy项目旨在通过区块链、数字加密和零知识证明等技术提供一种既能随时随地向任何人或者组织甚至是机器证明我们的真实身份，又能让个人信息和隐私安全地、长期地掌握在我们自己手中的方案。
在Hyperledger网站上，Indy被归类为Framework。但与其说它是一种区块链技术框架，不如说它是一个典型的区块链应用，它是如此的重要和典型以至于我们在很多场景中重复地（很可能错误地）实现它。为了减少重复劳动，共享可复用的成果，Indy项目将自己定位成一种参考实现（RI），只要是涉及身份和凭据管理的场合，我们都可以使用、部分使用或者借鉴它，即使并不是在Hyperledger的生态中。
Hyperledger Caliper
当前状态：Incubation
随着区块链技术和概念的火爆，各种框架和方案层出不穷，但是对大家在评估和比较时普遍关注的性能指标，各家都有自己的标准和用例，在横向比较时参考价值很低。为了提供一种比较通用的、客观的量化指标，华为主导开发和捐赠了Hyperledger Caliper项目。该项目通过定义一组标准的测试场景和用例，提供诸如每秒处理的事务数（TPS）、事务响应延迟和系统资源使用率等衡量区块链系统性能的参数。
Hyperledger Cello
当前状态：Incubation
Hyperledger Cello项目也是由IBM捐赠的，主要是为方便快速地在虚拟机、云环境或者容器集群上大规模部署、监控和管理区块链平台及应用提供了一套脚本和工具。
其名称Cello（大提琴）源自Playing （all） Chains的美好愿景，虽然目前暂时只支持Fabric后端。
Hyperledger Explorer
当前状态：Incubation
Hyperledger Explorer是由IBM，Intel和DTCC发起和捐赠的项目，主要用于在Web界面上可视化地展示和查询区块链的区块、交易、网络状态、节点状态等信息。
目前暂时只支持Fabric后端。
Hyperledger Composer
当前状态：Incubation
Hyperledger Composer仍然是由IBM主导开发和捐赠的项目，主要目的是通过提供一组现代化的工具链，封装底层的技术细节，简化区块链应用的开发过程，帮助应用开发者专注自己的业务本身，快速完成原型构建和系统上线。
Composer基于学习门槛较低、受众广泛的JavaScript语言来开发，使用者只需要通过配置文件和脚本文件定义好自己的业务模型、交互逻辑和权限控制等要素，就能快速部署一套提供REST接口的区块链系统，整个过程甚至不需要关心区块链技术的细节，就像开发普通的业务系统一样。Composer还提供了一套开箱即用的基于浏览器和在线云服务的IDE，方便开发者进行快速的迭代和验证。
必须指出的是，目前Composer暂时只支持Fabric后端，并且IBM在最近宣布停止对其新特性的开发，转而投入更多精力到Fabric项目中，在Fabric 1.4及以后的版本中，我们很有可能会看到Composer的影子。尽管前途未卜，但是Composer的设计迎合了当下流行的云原生的概念，是将来的趋势，非常适合配合云服务来使用，所以还是强烈建议未体验过它的读者亲自试用一下。
Hyperledger Quilt
当前状态：Incubation
通过之前的介绍也可以看出，当下的区块链方案实在太多，即使在Hyperledger项目内部也不能达成一致，而且不同的方案之间几乎不能互通，如果照此发展下去，很有可能演变成圣经中巴别塔一样的结局，得到众多烟囱似的系统。为了解决跨链（或者用更流行的说法，跨价值网络）的信息交换问题，Stefan Thomas和Evan Schwartz发起成立了Interledger W3C Community Group，发明并实现了Interledger协议（ILP）的最初版本。Quilt是ILP协议的Java实现，对应的还有使用JavaScript实现的Interledger.js。
值得注意的是，ILP协议的主要用途是解决跨网络的价值交换，类似于不同货币系统之间的兑换和转账，并没有涵盖区块链的全部应用场景，比如溯源和存证。
Hyperledger Fabric
当前状态：Active
因为Fabric相关的介绍和资料已经比较丰富，所以本文在此不再做赘述。
综全文所述，由于区块链技术还处在摸索和快速发展期，Hyperledger中的很多项目暂时还不太适合大规模地应用到生产环境中。Fabric作为较早出现的技术框架，其开发的活跃度、代码的成熟度、功能特性的完成度以及周边生态的支持都已经达到了较高的水平。甲骨文PaaS平台也提供了基于并兼容Fabric的区块链云服务，除了提供Fabric项目最新稳定版本的所有能力，我们还针对企业级应用在安全性、可靠性、易用性和一些功能上做了很多增强，欢迎感兴趣的读者与我们取得联系。
作者简介
宋晓寒，甲骨文PaaS专家团队高级咨询顾问，负责甲骨文云平台产品和解决方案的咨询和推广。有通信、智能硬件、物联网以及零售供应链领域多年的从业经历，目前主要关注跨平台移动化开发、智能制造和机器学习等方向。您可以通过xiaohan.song@oracle.com与他取得联系。
扫描二维码或点击阅读原文
快速预约精选云解决方案演示
