4.md

fabric超级账本

[toc]

Hyperledger fabric.cn地址

相比较以太坊公链，需要使用gas手续费，联盟链fabric是不需要手续费的，就相当于会员制，同样超级账本可以达到隐私保护

Fabric架构和框架

Fabric 具有高度模块化和可配置的架构，可为各行各业的业务提供创新性、多样性和优化，其中包括银行、教育、金融、保险、医疗保健、人力资源、供应链甚至数字音乐分发。

支持通用编程语言编写智能合约（如 Java、Go 和 Node.js）的分布式账本平台，

目前的fabric支持python

Fabric 平台也是许可的，这意味着它与公共非许可网络不同，参与者彼此了解而不是匿名的或完全不信任的。也就是说，尽管参与者可能不会完全信任彼此（例如，同行业中的竞争对手），但网络可以在一个治理模式下运行，这个治理模式是建立在参与者之间确实存在的信任之上的，如处理纠纷的法律协议或框架。

它支持可插拔的共识协议，使得平台能够更有效地进行定制，以适应特定的业务场景和信任模型。例如，当部署在单个企业内或由可信任的权威机构管理时，完全拜占庭容错的共识可能是不必要的，并且大大降低了性能和吞吐量。在这种的情况下，崩溃容错（Crash Fault-Tolerant，CFT）共识协议可能就够了，而在去中心化的场景中，可能需要更传统的拜占庭容错（Byzantine Fault Tolerant，BFT）共识协议。

Fabric 可以利用不需要原生加密货币的共识协议来激励昂贵的挖矿或推动智能合约执行。不使用加密货币会降低系统的风险，并且没有挖矿操作意味着可以使用与任何其他分布式系统大致相同的运营成本来部署平台。

这些差异化设计特性的结合使 Fabric 成为当今交易处理和交易确认延迟方面性能较好的平台之一，并且它实现了交易的隐私和保密以及链码

---

智能合约的去中心化治理

Fabric v2.0 引入了智能合约的去中心化治理，它为您在 Peer 节点上安装和启动链码提供了一个新的流程。新的 Fabric 链码生命周期支持多个组织在链码和账本交互之前协商链码的参数，例如链码背书策略。和以前的生命周期相比，新的模式有几个改进:

• 多个组织必须认同链码参数 在 Fabric 1.x 版本中，一个组织可以为通道中的所有其他成员设置链码的参数（例如背书策略），这些成员只能拒绝安装链码，因此不能参与和该链码相关的交易。新的 Fabric 链码生命周期更加灵活，它既支持中心化的信任模型（如以前的生命周期模型），也支持去中心化的模型，去中心化的模型要求在链码在通道上变为活动状态之前，要有足够数量的组织就背书策略和其他细节达成一致意见。
• 更周密的链码升级过程 在以前的链码生命周期中，升级交易可能由单个组织发起，这会给尚未安装新链码的通道成员带来风险。新的模式要求只有在足够数量的组织批准升级后才能升级链码。
• 更简单的背书策略和私有数据集合更新 Fabric 生命周期支持在不重新打包或重新安装链码的情况下，更改背书策略或私有数据集合配置。用户还可以利用新的默认背书策略，该策略要求获得通道上大多数组织的背书。在通道中添加或删除组织时，会自动更新此策略。
• 可查验的链码包 Fabric 生命周期将链码封装在可读性更强的 tar 文件中。这使得检查链码包和跨多个组织协调安装变得更加容易。
• 使用一个包在通道上启动多个链码 以前的生命周期在安装链码包时，会使用打包时指定的名称和版本定义通道上的链码。您现在可以使用同一个链码包，以不同的名称在同一通道或不同通道上多次部署它。例如，如果您想在链码的“副本”中跟踪不同类型的资产。
• 通道成员之间的链码包不需要为同一个 组织可以自己扩展链码，例如为了他们组织的利益执行不同的验证。只要有所需数量的组织的链码执行结果匹配并为交易背书，该交易就会被验证并提交到帐本中。这还允许组织按照自己的时间单独推出小的修补程序，而不需要整个网络同步进行。

使用新的链码生命周期

对于现有的 Fabric 部署，您可以继续使用 Fabric v2.0 之前的链码生命周期。新的链码生命周期只有在通道应用程序功能更新到 v2.0 时才会生效。关于新的链码生命周期完整细节教程请参考 chaincode4noah

用于协作和共识的新链码应用程序模式

支持新的链码生命周期管理的相同的去中心化的达成协议的方法也可以用于您自己的链码应用程序中，以确保组织在数据交易被提交到帐本之前同意它们。

• 自动检查 如上所述，组织可以在链码功能中添加自动检查，以便在背书交易提案之前验证附加信息。
• 去中心化协议 人们的决定可以通过链码中的多个交易来建模。链码可能要满足来自不同组织的参与者在账本交易中的协议和条件。然后，最终的链码提案可以验证所有交易者的条件是否得到满足，并最终“解决”所有通道成员之间业务交易。有关私有条件的具体示例，请参见资产转移场景文档 私有数据。

私有数据增强

Fabric v2.0 还启用了使用和共享私有数据的新模式，不需要为所有想要进行交易的通道成员组合创建私有数据集合。具体地说，您不是在多个成员的集合中共享私有数据，而是可能想要跨集合共享私有数据，其中每个集合可能包括单个组织，也可能是带有一个监管者或审计师的组织。

Fabric v2.0 中的几个增强使得这些新的私有数据模式成为可能:

• 共享和验证私有数据 当私有数据与不是集合成员的通道成员共享时，或者与包含一个或多个通道成员的另一个私有数据集合共享时（通过向该集合写入密钥），接收方可以利用链码的 GetPrivateDataHash() API 验证私有数据是否与以前交易中创建的私有数据在链上哈希相匹配。
• 集合级别的背书策略 现在可以选择使用背书策略来定义私有数据集合，该背书策略会覆盖集合内键的链码级的背书策略。该特性可用于限制哪些组织可以将数据写入集合，并且正是它启用了前面提到的新的链码生命周期和链码应用程序模式。例如，您可能有一个链码背书策略，该策略要求大多数组织背书，但对于任何给定的交易，您可能需要两个交易处理组织在它们自己的私有数据集合中单独背书它们的协议。
• 每个组织的隐式集合 如果您想利用每个组织的私有数据模式，那么在 Fabric v2.0 中部署链码时甚至不需要定义集合。不需要任何前期定义就可以使用隐式的特定组织集合。

外部链码启动器

外部链码启动器功能使运营者能够使用他们选择的技术构建和启动链码。默认构建和运行链码的方式与之前的版本相同，都是使用 Docker API，但是使用外部构建器和启动器就不必这样了。

• 消除 Docker 守护进程依赖 Fabric 以前的版本要求 Peer 节点能够访问 Docker 守护进程，以便构建和启动链码，但是 Peer 节点进程所需的特权在生产环境中可能是不合适的。
• 容器的替代品 不再要求链码在 Docker 容器中运行，可以在运营者选择的环境（包括容器）中执行。
• 可执行的外部构建器 操作员可以提供一组可执行的外部构建器，以覆盖 Peer 节点构建和启动链码方式。
• 作为外部服务的链码 传统上，链码由 Peer 节点启动，然后连接回 Peer 节点。现在可以将链码作为外部服务运行，例如在 Kubernetes pod 中，Peer 节点可以连接到该 pod，并利用该 pod 执行链码。了解更多信息请查看 将链码作为外部服务 。

了解更多关于外部链码启动功能请查看 外部构建器和启动器 。

用于提高 CouchDB 性能的状态数据库缓存

• 在使用外部 CouchDB 状态数据库时，背书和验证阶段的读取延迟历来是性能瓶颈。
• 在 Fabric v2.0 中，用快速的本地缓存读取取代了 Peer 节点中那些耗费资源的查找操作。可以使用 core.yaml 文件中的属性 cachesize 来配置缓存大小。

基于 Alpine 的 docker 镜像

从 v2.0 开始，Hyperledger Fabric Docker 镜像将使用 Alpine Linux 作为基础镜像，这是一个面向安全的轻量级 Linux 发行版。这意味着现在的 Docker 镜像要小得多，这就提供了更快的下载和启动时间，以及占用主机系统上更少的磁盘空间。Alpine Linux 的设计从一开始就考虑到了安全性，Alpine 发行版的最小化特性大大降低了安全漏洞的风险。

示例测试网络

fabric-samples 仓库现在包括一个新的 Fabric 测试网络。测试网络被构建为模块化的和用户友好的示例 Fabric 网络，这使测试您的应用程序和智能合约变得容易。除了 cryptogen 之外，该网络还支持使用 CA（Certificate Authorities） 部署网络。