企业及区块链应用要求
- 网络是准入的
- 高吞吐量
- 低延迟
- 交易保证隐私与机密
Fabric 特点
- 高度模块化；使得平台可以适用不同的行业：供应链，银行，金融，保险，医疗，人力资源等
- 第一个支持通用编程语言编写smart contracts：Java，Go
- 网络要求是permissioned
- 共识协议可插拔，可以适用不同的环境
- 没有token，减少被攻击的风险，不需要挖矿可以降低成本
Fabric的模块
- 可插拔的ordering service，主要负责对事物顺序进行排序并共识
- 可插拔的membership service，负责把用户实体和密码身份相对应
- 可选择的点对点gossip协议
- 在Docker内运行的智能合约。智能合约不能直接访问账本状态
- 账本支持多种数据库
- 可插拔的背书和验证策略
Permissioned vs Permissionless Blockchains
在permissionless的环境中，用户是匿名的，任何虚拟用户都可以参与协议。并且permissionless的区块链中，一般会设置token来激励矿工
在permissioned的环境中，用户的身份是可辨认的，并且可以不依赖于POW机制，而是使用传统的crash fault tolerant (CFT) 或者是 byzantine fault tolerant (BFT)共识协议
Smart Contracts
智能合约在Fabric中也可以称为chaincode，是一个可信的分布式应用，它的安全基础源自底层区块链和共识协议。关于智能合约，有三点需要注意
- 网络中可能同时运行多个智能合约
- 智能合约可以被动态部署（在任何时刻被任何人部署）
- 每个智能合约都可能是恶意的
目前大多数智能合约平台都遵循一种order-execute的架构，协议总的来说分成两步
- 验证并对事务排序，向所有节点广播
- 所有节点按顺序执行事务
不管是以太坊这种permissionless的平台，还是像 Tendermint，Chain，Quorum这种permissioned平台，应用的都是这种order-execute架构。但是这种架构要求智能合约必须是确定性的，如果结果是不确定的，那么共识是无法达成的。为了解决这个问题，许多平台使用非标准的，或者是domain-specific语言（例如solidity），从而避免产生非确定性的操作。但这种方法阻碍了智能合约的更广泛的应用。因为这要求程序员学习一门新的语言，而且可能导致许多程序错误。
此外，由于所有事物都要被所有节点顺序执行，这大大限制了系统的性能和可扩展性。智能合约在实际运行中需要一些复杂的检查，使得系统能不受恶意合约的威胁。
新架构
在Fabric中采用的是一种新架构，execute-order-validate，分成三步：
- 执行一个事务，验证后对事务进行背书
- 通过共识算法对事务进行排序
- 验证事务通过了指定的背书策略
这种设计和order-execute架构的根本区别在于，Fabric是先执行事务，再进行排序。Fabric中需要一些节点对事务的执行做背书，这些节点需要事先在背书策略中指定好。所以，每一个事务只需要全网中一部分节点（事先指定好的背书节点）执行就可以。这种方式可以允许并行处理，并提高系统的性能和可扩展性。同时，第一步操作也解决了order-execute中不能处理非确定性事务的问题，因为不一致的结果在排序之前就会被过滤掉。
正因为Fabric解决了非确定性事务的问题，所以Fabric是第一个支持标准编程语言的，在1.1.0版本中，智能合约支持GO和Node.js，在之后的版本中可能会支持JAVA。
隐私保护和机密性
正如我们之前所讨论的，在一个公开的、permissionless的区块链平台中，事务会在所有节点上运行。所以，不管是合约本身，还是合约所处理的交易数据都不是保密的。每一个事务都是全网可见的。在这种情况下，我们用合约和数据的机密性换来了拜占庭容错。
然而，机密性的的缺失在很多企业级应用中是一个很严重的问题。举例来说，在一个供应链网络中，一些顾客可能会被给予给优惠的价格来促进销量或是为了巩固合作关系。如果所有的合约和交易都是透明可见的，那么这种商业关系是不可能维持的，因为每个人都想要最优惠的价格。
为了解决隐私和机密性，不同的区块链平台利用了各种各样的方法，每种都有各自的优缺点。
数据加密是实现机密性的一种方法，但是在permissionless的环境中，密文同样会出现在所有的节点视野中。给定足够的时间和计算资源，密文总会被破解。在许多应用场景中，企业是不会冒这种信息被泄露的风险。
零知识证明是另外一种可行的方法。但是计算零知识证明需要耗费大量的时间和计算资源。这会造成性能下降 。
在permissioned的环境中，人们可以利用其它形式的共识方案。人们可以探索如何使得机密信息只在授权用户中传递。在Fabric中，机密性通过channel结构实现。简单来说，参与者可以相互组建一个channel。可以把channel想象成网络的覆盖层。只有channel中的用户可以访问合约和数据。
可插拔的共识
在Fabric中，对事务的排序与执行事务和维持账本在逻辑上是解耦的。具体来说，共识机制可以根据具体的部署方案和信任假设来挑选。在目前的版本中，Fabric提供的CFT共识包括Kafka和Zookeeper。在接下来的版本中，还会提供Raft和BFT共识。
性能和可扩展性
区块链平台的性能受到很多方面的影响，比如说交易大小，区块大小，网络大小以及硬件条件。超级账本社区目前正在开发一整套关于性能和可扩展性的测量框架和工具，称为Hyperledger Caliper。
IBM研究院的一个研究小组发表了一篇 peer reviewed paper，评估了超分账本的结构和性能。这篇文章对Fabric的体系结构进行了深入的讨论，并对平台的性能评估进行了报告。
研究团队所做的基准测试工作为Fabric v1.1.0的发布带来了大量的性能改进，使该平台的整体性能与v1.0.0版本相比，增加了一倍以上。
