Hyperledger Fabric 2.0 官方文档中文版 第2章 Hyperledger Fabric v2.0的新增功能
Hyperledger Fabric 2.0 官方文档中文版 第2章 Hyperledger Fabric v2.0的新增功能总目录2.Hyperledger Fabric v2.0的新增功能智能合约的去中心化管理用于协作和共识的新链码应用模式私有数据增强外部链码发射器提高CouchDB性能的状态数据库缓存基于Alpine的docker镜像样本测试网络升级到Fabric v2.0总目录第1章 引言
Hyperledger Fabric 2.0 官方文档中文版 第2章 Hyperledger Fabric v2.0的新增功能
总目录
第1章 引言
第2章 Hyperledger Fabric v2.0的新增功能
第3章 关键概念
第4章 入门
第5章 开发应用程序
第6章 教程(上)
第6章 教程(下)
第7章 部署生产网络
第8章 操作指南
第9章 升级到最新版本
2.Hyperledger Fabric v2.0的新增功能
Fabric v2.0是自1.0版以来的第一个Hyperledger Fabric主要版本,它为用户和运营商提供了重要的新功能和更改,包括对新应用程序和隐私模式的支持、围绕智能合约的增强管理以及操作节点的新选项。
保持不变的是能够根据自己的条件升级网络组件,支持从v1.4.x开始的滚动升级,并且只有在成员组织准备就绪时才能启用新功能。
让我们来看看Fabric v2.0版本的一些亮点…
智能合约的去中心化管理
FabricV2.0为智能合约引入了去中心化管理,它提供了一个新的流程,用于在节点上安装链码并在通道上启动它。新的Fabric链码生命周期允许多个组织在链码的参数(如链码背书策略)上达成一致,然后才能使用它与账本交互。新模型在以前的生命周期中提供了一些改进:
- 多个组织必须同意链码的参数:在Fabric的1.x版本中,一个组织能够为所有其他通道成员设置链码的参数(例如背书策略),这些成员只有权拒绝安装链码,因此不能参与调用它的事务。新的Fabric链码生命周期更加灵活,因为它既支持集中式信任模型(如前一个生命周期模型的信任模型)也支持分散式模型,需要足够数量的组织在链码在通道上激活之前就背书策略和其他细节达成一致。
- 更谨慎的链码升级过程:在以前的链码生命周期中,升级事务可能由单个组织发出,这会给尚未安装新链码的渠道成员带来风险。新的模式只允许在足够数量的组织批准升级后才能升级链码。
- 更简单的背书政策和私人数据收集更新:Fabric 生命周期允许您更改背书策略或专用数据收集配置,而无需重新打包或重新安装链码。用户还可以利用新的默认背书策略,该策略需要来自通道上大多数组织的背书。在通道中添加或删除组织时,此策略将自动更新。
- 可检查的链码包:Fabric生命周期将链代码封装在易于阅读的tar文件中。这使得检查链码包和跨多个组织协调安装变得更加容易。
- 使用一个包在一个通道上启动多个链码:上一个生命周期使用安装chaincode包时指定的名称和版本定义了通道上的每个链码。现在,您可以使用单个链码包,并在同一通道或不同通道上以不同的名称多次部署它。例如,如果您想跟踪不同类型的资产在它们自己的链码“副本”中。
- 链码包不需要在通道成员之间完全相同:组织可以为自己的用例扩展链码,例如为了组织的利益执行不同的验证。只要所需数量的组织背书具有匹配结果的链码交易记录,交易将被验证并提交到账本。这也允许组织在自己的时间表上单独推出小补丁,而不需要整个网络以锁定步骤进行。
使用新的链码生命周期
对于现有的Fabric部署,您可以继续在Fabric v2.0中使用先前的链码生命周期。新的链码生命周期只有在通道应用功能更新到v2.0时才会生效。有关新的链代码生命周期的概述,请参阅Fabric 链码生命周期概念主题。
用于协作和共识的新链码应用模式
支持新链码生命周期管理的分散式达成一致的方法也可以用于您自己的链码应用程序中,以确保组织在将数据事务提交到账本之前同意它们。
- 自动检查:如上所述,组织可以向链码函数添加自动检查,以在批准交易建议之前验证附加信息。
- 去中心化协议:人工决策可以被模型化为跨越多个交易的链码流程。链码可能要求来自不同组织的参与者在分类账交易中表明他们的协议条款和条件。然后,最终的链码方案可以验证来自所有单个交易方的条件是否满足,并在所有渠道成员之间最终“结算”业务交易。有关以私有方式指示条款和条件的具体示例,请参阅私有数据文档中的资产转移场景。
私有数据增强
Fabric v2.0还支持使用和共享私有数据的新模式,而无需为可能要进行交易处理的所有通道成员组合创建私有数据集合。具体地说,您可能希望跨集合共享私有数据,而不是在多个成员的集合中共享私有数据,其中每个集合可能包含一个组织,或者可能包含一个组织以及一个管理者或审计员。
Fabric v2.0中的一些增强功能使这些新的私有数据模式成为可能:
- 共享和验证私有数据:当私有数据与非集合成员的通道成员共享,或与包含一个或多个通道成员的另一个私有数据集合共享时(通过向该集合写入密钥),接收方可以使用GetPrivateDataHash() 链码API来验证私有数据是否与以前事务中从私有数据创建的链上哈希匹配。
- 集合级别背书策略:现在可以选择使用一个背书策略来定义私有数据集合,该策略覆盖集合中键的链码级背书策略。此特性可用于限制哪些组织可以向集合中写入数据,并支持前面提到的新的链代码生命周期和链代码应用程序模式。例如,您可能有一个链码背书策略,该策略要求大多数组织背书,但对于任何给定的事务,您可能需要两个事务处理组织在其自己的私有数据集合中分别为其协议背书。
- 每个组织的隐式集合:如果您想利用每个组织的私有数据模式,那么在Fabric v2.0中部署链代码时甚至不需要定义集合。隐式特定于组织的集合可以在没有任何预先定义的情况下使用。
要了解有关新的私有数据模式的更多信息,请参阅私有数据(概念性文档)。有关私有数据收集配置和隐式集合的详细信息,请参阅私有数据(参考文档)。
外部链码发射器
外部链码启动器特性使操作员能够使用他们选择的技术来构建和启动链码。不需要使用外部构建器和启动器,因为默认行为以与使用Docker API的先前版本相同的方式构建和运行链代码。
- 消除Docker守护进程依赖:Fabric的早期版本要求节点能够访问Docker守护进程,以便构建和启动链码—由于节点进程所需的特权,这在生产环境中可能并不理想。
- 容器的替代品:链码不再需要在Docker容器中运行,可以在操作员选择的环境(包括容器)中执行。
- 外部生成器可执行文件:操作员可以提供一组外部生成器可执行文件来覆盖节点如何构建和启动链码。
- 链码作为外部服务:传统上,链码由节点发起,然后连接回节点。现在可以将链码作为外部服务运行,例如在Kubernetes pod中,节点可以连接到它并利用它执行链码。有关详细信息,请参见链码作为外部服务。
请参阅外部生成器和启动器以了解有关外部链码启动器功能的更多信息。
提高CouchDB性能的状态数据库缓存
- 在使用外部CouchDB状态数据库时,在背书和验证阶段的读取延迟一直是性能瓶颈。
- 在Fabric v2.0中,新的节点缓存用快速的本地缓存读取替换了许多这些昂贵的查找。可以使用core.yaml属性配置缓存大小
基于Alpine的docker镜像
从v2.0开始,Hyperledger Fabric Docker 镜像将使用Alpine Linux,一个面向安全的轻量级Linux发行版。这意味着Docker镜像现在要小得多,提供更快的下载和启动时间,同时在主机系统上占用更少的磁盘空间。alpine linux从一开始就考虑到了安全性,而Alpine发行版的最低限度本质极大地降低了安全漏洞的风险。
样本测试网络
fabric samples存储库现在包括一个新的结构测试网络。测试网络构建为模块化和用户友好的示例结构网络,使测试应用程序和智能合约变得容易。除了cryptogen之外,网络还支持使用证书颁发机构部署网络的能力。
有关此网络的更多信息,请查看使用Fabric测试网络。
升级到Fabric v2.0
一个主要的新版本带来了一些额外的升级考虑。不过,请放心,支持从v1.4.x到v2.0的滚动升级,这样网络组件就可以一次升级一个,而不需要停机。
升级文档已经进行了大量的扩展和修改,现在文档中有一个独立的主页:升级到最新版本。在这里,您将找到有关升级组件和更新通道功能级别的文档,以及升级到v2.0的注意事项和升级到v2.0的注意事项的具体说明。
参考自Hyperledger Fabric官方文档
如有侵权,请联系作者删除,谢谢!
If there is infringement, please contact the author to delete, thank you!
更多推荐
所有评论(0)