v2.0 Alpha 新功能

有关 Alpha release 的一句话概要

Hyperledger v2.0 的 Alpha release 版本允许用户可以尝试两种非常棒的功能 — 全新的 Fabric chaincode 生命周期以及 FabToken。Alpha release 正在被用来为用户提供关于这些新能力的一个预览,这并不代表她可以被用于生产环境。另外现在还没有对于 v2.0 Alpha release 的升级支持,也没有任何从 Alpha release 到未来的 v2.x 版本的升级支持的打算。

Fabric chaincode 生命周期

Fabric 2.0 Alpha 引入了对 chaincode 的去中心化的管理,带来了一个在你的 peers 安装一个 chaincode 并且在一个 channel 中启动 chaincode 的新流程。这个全新的 Fabric chaincode 生命周期在一个 chaincode 能够被用于同账本进行交互之前,允许多个组织对于一个 chaincode 的参数达成协议,比如 chaincode 背书策略。这个新的模型相对于以前的生命周期而言,提供了多个改进:

  • 多个组织必须同意一个 chaincode 的参数: 在 Fabric release 1.x 版本中,一个组织有能力为所有的 channel 成员设置一个 chaincode 的参数(比如背书策略)。新的 Fabric chaincode 生命周期变得更加灵活,因为她及支持中心化的信任模型(就像之前的生命周期模型),同时也支持在一个背书策略起作用前,必须要有足够有效的数量的组织同意这个背书策略的这种去中心化的模型。

  • 更安全的 chaincode 升级流程: 在以前的 chaincode 生命周期中,升级的交易可以有单独的一个组织来发起,这就为尚未安装新的 chaincode 的 channel 成员带来了风险。新的模型允许一个 chaincode 只有当有效数量的组织已经批准了这个升级之后才会被升级。

  • 更简单的背书策略更新: Fabric 生命周期允许你能够改变一个背书策略而不需要必须打包或者重新安装 chaincode。用户也可以利用一个新的必须要求 channel 上的主要成员提供背书的默认策略。这个策略会在组织被添加到或者从 channel 中被移除的时候自动被更新。

  • 可检查的 chaincode 包: Fabric 生命周期将 chaincode 打包成了更容易阅读的 tar 文件。这使其更容易来检查 chaincode 包,并且在多个组织间协调安装。

  • 在一个 channel 上使用一个包来启动多个 chaincode: 之前的生命周期使用一个在 chaincode 包被安装的时候所指定的名字和版本来定义 channel 上的每个 chaincode。现在你可以使用不同名字的同一个 chaincode 包并且可以把它多次的部署到相同或者不同的 channel 上去。

使用新的 chaincode 生命周期

使用下边的教程来开始新的 chaincode 生命周期:

限制以及局限性

在 v2.0 Alpha release 中的新的 Fabric chaincode 生命周期功能还没有彻底完成。特别的,要注意下边这些在 Alpha release 中的局限性:

  • 尚未支持 CoachDB 索引

  • 通过新的生命周期定义的 chaincodes 还不能通过服务发现被找到

这些限制会在 Alpha release 之后被解决。

FabToken

Fabric 2.0 Alpha 也为用户提供了在 Fabric channels 上非常简单就能将资产表现为 tokens 的能力。FabToken 是一个 token 管理系统,它使用了由 Hyperledger Fabric 提供的身份及成员的基础设施,使用一个 Unspent Transaction Output(UTXO)的模型来发行、交易以及赎回 tokens。

  • Using FabToken:这个操作指南提供了一个关于在一个 Fabric 网络上如何使用 tokens 的详细的概览。这个指南也包含了一个如何使用 token CLI 来创建和交换 tokens 的例子。

Alphine 镜像

从 v2.0 开始,Hyperledger Fabric 镜像将会使用 Alphine Linux,一个面向安全的、轻量的 Linux distribution。这意味着 Docker 镜像现在更小了,提供了更快的下载和启动时间,并且在 host 系统上占用更小的磁盘空间。Alphine Linux 是彻底的安全优先的设计,并且 Alphine distribution 的极简主义本质很大程度的减小了安全缺陷的风险。

Raft 排序服务

在 v1.4.1 中被引入,Raft 是一个崩溃容错 fault tolerant (CFT) 排序服务,基于一个在 etcd 中的 Raft 协议的实现。Raft 遵循一个 “leader 和 follower” 模型,一个 leader 节点被选举出来(每个 channel)并且它的决定会被复制给 followers。Raft 排序服务应该比基于 Kafka 的排序服务更简单的设置并管理,并且他们的设计允许分布世界各地的组织来为一个去中心化的排序服务贡献节点。

Release notes

Release notes 提供了转换到新的 release 的更详细的信息,也包括了一个关于全部 release change log 的链接。