Hyperledger Fabric 1.2 -- 介绍

介绍

有些内容我并没有按照官方文档的原文翻译，更多的是做个记录。

单个企业没有必要使用 BFT（byzantine fault tolerant）, 可以考虑使用 CFT (crash fault tolerant)。

• 共识机制可插拔，
• 身份管理协议可插拔：如 LDAP, OpenID Connect, OpenID Connect 这个之前应该是没有的
• 秘钥管理协议或加密算法库：

Fabric 的组成模块：

• 可插拔的 ordering 服务建立共识：交易排序和广播 blocks 到 peers
• 可插拔的 membership service provider : 用 加密身份 关联网络中的实体（entites）
• 一个可选的 peer-to-peer gossip 服务，通过向其他 peer ordering 服务来广播区块输出
• 智能合约(Smart contracts "chaincode") 运行在一个隔离的容器环境内（如 docker），可以使用标准的编程语言但是它们没有权限直接访问账本。
• 账本支持配置多种数据库管理系统（DBMSs）
• 可插拔的背书和验证机制实施可以依据每个应用配置
• 没有 "一个区块链可以统治所有人"( noe blockchain to rule them all), Hyperledger fabric 可以使用多种方式，根据不同行业企业的不同要求来实现

permissionless and permissioned

• permissionless： 依靠 mined . byzantine fault tolerant (BFT), PoW

• permissioned: CFT, BFT, not require costly mining

• 因为所有的参与方都不是匿名的，所以如果其中一个参与方提交恶意代码，可以通过 身份标识 识别并按照 治理机制 进行事件处理。

Smart Contracts

在 Hyperledger Fabric 中智能合约被称为 chaincode。

作为受信任的分布式应用程序，从区块链获得其安全性/信任以及 peers 之间的基本共识。它是区块链应用程序的业务逻辑

怎么验证（验证的机制是什么样的），谁负责验证，验证的结果要不要同步到所有的 参与方，怎么同步，同步过去后，参与方要不要验证，参与方又怎么验证，参与方的验证需要同步给其它 参与方吗？
验证智能合约应该是 system chaincode 的功能

应用智能合约时有 三个关键点

• 多个智能合约可以同时运行在同一个网络中
• 他们支持动态部署（in many cases by anyone ）
• application code 应该被视为 不受信任的，甚至可能是恶意的。

大多数现有的具有智能合约能力的区块链平台遵循共识协议 -- order-execute (订阅执行) 架构

• 验证和订阅（orders） transactions 然后广播到所有的 peer 节点。
• 每一个 peer 按顺序执行 transactions

domain specific language: Solidity 产生的原因是什么

进一步说，因为所有的 transactions 需要按顺序在所有的节点上执行，性能和扩展性会被限制。事实上，为了确保整个系统的弹性，在网络的每个节点上执行智能合约代码时需要复杂的措施来保护整个系统不会执行可能恶意的合约。

一个新的方法

fabric 为 transaction 介绍了一个新的架构, 我们称它为 execute-order-validate。它通过将事务流分为三个步骤来解决订单执行模型面临的弹性，灵活性，可伸缩性，性能和机密性挑战：

• 执行一个 transaction 并检查它的正确性，从而对它进行背书
• order transactions 通过（可插拔）的共识协议
• 在 committing 他们到账本之前，验证 transactions 依赖的应用指定的背书策略

这个设计根源来自于 order-execute 范例 (order-execute paradigm)，它是在 Fabric 执行 transactions 这种设计与订单执行范例完全不同，因为 Fabric 在达成 order 的最终协议之前执行 transaction。

在 Fabric 中，应用程序的 背书策略(endorsement policy) 指定的一个 peer 节点或多个 peer 节点需要保证正确执行给定的智能合约。因此，每个 transaction 只需要由满足 transaction 的 背书策略 所必需的 peer 节点的子集(subset)来执行（背书）。这允许并行执行，从而提高系统的整体性能和规模。第一阶段也消除了任何非确定性(eliminates any non-determinism)，因为在 ordering 之前可以滤除不一致的结果。

支持 标准的编程语言(standard prgramming languages) 来写智能合约，现在支持 Go 和 Node.js，下一步会支持包括 Java 在内的其他编程语言。

隐私性和保密

就像我们之前讨论过的那样，在公共的，无权限的区块链网络，采用 pow 作为它的共识模型，交易在每个节点上执行。这意味着没有人能确认他们自己的合约，也不能确认他们执行的交易数据。代码实现的每一笔 transaction，在网络的每个节点上都是可用的。在这种情况下，我们已经用合约和数据的保密性替换了 PoW。

在一些商用/企业用例中，如果整个业务关系都是透明的，那每个人都想获取最优惠的价格。

为了提高其隐私(privacy) 和机密性能(confidentiality capabilities)，Fabric 增加了对私有数据的支持，并且正在开发未来可用的零知识证明（ZKP）。更多关于这一点，因为它变得可用。

可插拔的共识机制

目前使用的是 Kafka 和 Zookeeper

后期会使用 Raft 共识机制

Note also that these are not mutually exclusive. A Fabric network can have multiple ordering services supporting different applications or application requirements.

另请注意，这些并不相互排斥。 Fabric 网络可以具有多种 ordering 服务，支持不同的应用或应用要求。

性能和可扩展性

区块链平台的性能会被很多因素影响，如交易大小，区块大小，网络带宽，硬件的限制等。Hyperledger 社区的性能和规模工作组目前正在开发一套测试草案(a draft set of measures)，以及一个名为 Hyperledger Caliper 的基准测试框架的相应实现。

---

Hyperledger Fabric 架构和性能的评估