本文翻译自Fabric官方文档，如有需更正之处，请读者指出，英文原地址为https://hyperledger-fabric.readthedocs.io/en/release-2.0/whatsnew.html
Fabric v2.0是v1.0以来的第一个Hyperledger Fabric主要版本，Fabric v2.0为用户和操作员带来了一些重要的新特性和改变，包括对新应用和私有模式的支持、围绕智能合约的增强型治理、以及用于操作节点的新选项。
保持不变的是，您可以根据自己的条件升级网络组件，支持从v1.4.x进行滚动升级，并且仅在成员组织准备就绪时才可以启用新功能。
接下来让我们来看一下Fabric v2.0版本的一些亮点……
一、智能合约的去中心化治理
Fabric v2.0引入了智能合约的去中心化治理，并且提供了一种在peer节点上安装chaincode、在channel上启动chaincode的新过程，新的Fabric chaincode生命周期允许在chaincode和账本交互前，多个组织间就chaincode的一些参数达成一致，比如chaincode背书策略。新模型在以前的生命周期基础上提供的一些改进如下：
- 必须经多个组织同意chaincode的参数
在Fabric v1.x版本中，一个组织可以为channel上所有其他成员设置某一个chaincode的参数（比如实例背书策略），其他成员有权拒绝安装chaincode，也就不能参与调用这个chaincode的交易。新的Fabric chaincode生命周期更加灵活，因为它既支持中心化信任模型（例如之前的生命周期模型），也支持去中心化模型，需要在chaincode于channel上生效之前，有足够数量的组织就背书策略和一些其他细节达成一致。
- 更加具有商讨性的chaincode升级过程
在先前的chaincode生命周期中，升级交易可能由单个组织发布，这给尚未安装新chaincode的channel成员带来了风险。新模型只有在足够数量的组织批准升级后才允许升级chaincode。
- 更简单的背书策略和私有数据收集更新
Fabric生命周期使您可以无需重新打包或重新安装chaincode，就可以更改背书策略和私有数据收集配置。用户还可以利用新的默认背书策略，该背书策略需要channel上大多数组织的背书。在从channel上添加或删除组织时，该背书策略也会自动更新。
- 可检查的chaincode package
Fabric生命周期将chaincode打包到易于阅读的tar文件中。这使得检查chaincode package和协调跨多个组织的安装变得更加容易。
- 使用一个package在channel上启动多个chaincode
先前的生命周期用安装chaincode package时指定的名称和版本，来定义channel上每个chaincode。现在，你可以使用单个chaincode package，并在同一个channel或不同channel上以不同的名称多次部署它。例如，如果您想在自己的chaincode副本中跟踪不同类型的资产。
- chaincode package在channel的各个成员间不必相同
组织可以针对自己的用例扩展chaincode，例如为了组织的利益执行不同的验证。只要所需数量的组织给具有匹配结果的chaincode交易背书，该交易将会被验证并提交到账本。这也使组织可以按自己的时间表单独推出较小的修复程序，而无需整个网络步调一致。
关于使用新的chaincode生命周期的说明
对于现有的Fabric部署，你可以继续将之前的chaincode生命周期与Fabric v2.0一起使用。只有当channel应用功能更新到v2.0的时候，新的chaincode生命周期才会生效。有关新chaincode生命周期的完整详细信息，参见Chaincode for Operators教程。
二、用于协作和共识的新chaincode应用模式
新的chaincode生命周期管理所基于的相同的去中心化达成协议的方法，也可以被用于你自己的chaincode应用中，以确保组织在提交账本之前同意数据交易。
Fabric v2.0中的一些增强功能使得这些新的私有数据模式成为可能：
- 共享和验证私有数据
当私有数据与不是集合一员的channel成员共享，或者与包含一个或多个channel成员的另一个私有数据集合共享（通过向该集合写入key）时，接收方可以利用GetPrivateDataHash() chaincode API，来验证私有数据是否与先前交易中的私有数据创建的链上哈希匹配。
- 集合级别的背书策略
现在，可以选择使用背书策略来定义私有数据集合，该策略可以覆盖集合中key的chaincode级别的背书策略。这个特性可以用来限制哪些组织可以将数据写入集合，这也使得前面提到的新chaincode生命周期以及chaincode应用模式成为可能。例如，你可能有一个要求大多数组织进行背书的chaincode背书策略，但是对于任何给定的交易，你可能需要两个交易组织在他们自己的私有数据集合中单独背书其协议。
- 隐式的按组织收集
如果你想利用按组织的私有数据模式，在Fabric v2.0中部署chaincode时，你甚至不需要定义集合。隐含特定于组织集合可以直接使用，而无需任何前期定义。
要了解有关新的私有数据模式的更多信息，请参阅Private data（conceptual documentation）。有关私有数据集合的配置和隐式集合的详细信息，请参阅Private data（reference documentation）。
四、外部chaincode启动器
外部chaincode启动器特性使操作员可以使用自己选择的技术来构建和启动chaincode。不需要使用外部构建器和启动器，因为默认行为以与使用Docker API的先前版本相同的方式构建和运行chaincode。
- 消除docker守护进程的依赖性
先前版本的Fabric要求peer节点有权访问Docker守护进程以构建和启动chaincode——在生产环境中，可能不希望peer节点拥有这些特权。
- 容器的替代方案
不再需要在docker容器中运行chaincode了，而是可以在操作员选择的环境中执行（包括容器）。
- 外部构建器的可执行性文件
操作员可以提供一组外部构建器可执行文件，以覆盖peer节点构建和启动chaincode的原本方案。
- chaincode作为外部服务
传统上，chaincode由peer节点启动，然后再连接回peer节点。现在可以将chaincode作为外部服务运行，例如在Kubernetes pod中，peer节点可以连接它并用于chaincode执行。有关更多信息，请参阅Chaincode as an external service。
请参阅External Builders and Launchers以了解有关外部chaincode启动器特性的更多信息。
五、状态数据库缓存提高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部署网络的功能。
有关此网络的更多信息，请参阅Using the Fabric test network。
八、升级到Fabric v2.0
这个主要的新版本带来了一些其他升级注意事项。不过请放心，它支持从v1.4到v2.0的滚动升级，所以可以一次不停机地升级网络组件。
升级文档已经进行了很大的扩展和改进，现在在文档中有一个独立的主页：Upgrading to the latest release。在这里，你将找到有关升级组件和更新channel功能级别的文档，以及有关升级到v2.0的注意事项，Considerations for getting to v2.0。
九、发行说明
发行说明为使用新版本的用户提供了更多详细信息。具体请查看新的Fabric v2.0版本发布的更改和弃用。详见Fabric v2.0.0 release notes。
