标签：建立 通信 ann 标准 编辑 不能 核心 处理 vpd
HyperLeger Fabric开发（三）——HyperLeger Fabric架构商业应用的一个重要的需求是私密×××易，为此Fabric设计了通道（Channel）来提供成员之间的隐私保护。通道是部分网络成员之间拥有独立的通信渠道，在通道中发送的交易只有属于通道的成员才可见，因此通道可以看作是Fabric的网络中部分成员的私有通信子网。
通道由排序服务管理。在创建通道的时候，需要定义通道的成员和组织、锚节点（anchor peer）和排序服务节点，一条与通道对应的区块链会同时生成，用于记录账本的交易，通道的初始配置信息记录在区块链的创世区块中，可以通过增加一个新的配置区块来更改通道的配置信息。
每个组织可以有多个节点加入同一个通道，组织内的节点中可以指定一个锚节点或多个锚节点（增强系统可靠性，避免单点故障）。组织的锚节点代表本组织与其它组织的节点交互，从而发现通道中的所有节点。另外，同一组织的节点会选举或指定主导节点（leading peer），主导节点负责接收从排序服务发来的区块，然后转发给本组织的其它节点。主导节点可以通过特定的算法选出，可以保证在节点数量不断变动的情况下仍能维持整个网络的稳定性。
在Fabric网络中，可能同时存在多条彼此隔离的通道，每条通道包含一条私有的区块链和一个私有账本，通道中可以实例化一个或多个链码，以操作区块链上的数据。Fabric是以通道为基础的多链多账本系统。
Fabric区块链网络包括客户端（Client），网络节点（Peer），CA（Certificate Authority）节点和排序节点（Orderer）。
客户端的主要作用是与Fabric区块链交互，实现对区块链的操作。区块链操作分为管理类和链码类的两种，管理类操作包括启停节点和配置网络等；链码类操作主要是链码的生命周期管理，如安装、实例化以及调用链码。最常用的客户端是命令行客户端（CLI），此外是用Fabric SDK开发的应用客户端。用户通过不同的客户端使用Fabric网络的功能。
Peer节点是区块链去中心化网络中的对等节点，按照功能主要分为背书节点（Endorser）和确认节点（Committer，记账节点）。背书节点主要对交易提案进行校验、模拟执行和背书；确认节点主要负责检验交易的合法性，并更新和维护区块链数据和账本状态。在实际部署中，背书节点和确认节点既可以部署在同一物理节点上，也可以分开部署。
排序节点（Orderer）主要职责是对各个节点发来的交易进行排序。在并发的情况下，各个节点交易的先后时序需要通过排序节点来确定并达成共识。排序节点按照一定规则确定交易顺序后，发给各个记账节点，把交易持久化到区块链的账本中。排序节点支持互相隔离的多个通道，使得交易只发送给相关的记账节点（Peer）。
CA节点主要给Fabric网络中的成员提供基于数字证书的身份信息，可以生成或取消成员的×××书（certificate）。在成员身份明确的基础上，Fabric可以实现权限控制的管理。
Fabric网络的组件往往归属于不同的组织，在组织之间形成对等的去中心化网络。每个组织通常拥有自己的客户端、网络节点和CA节点，并且可以根据需要创建一个或多个不同的类型节点。排序节点不属于某个组织的实体，属于组织共同维护的节点。
Fabric区块链的架构设计如下：
HyperLeger Fabric v1.0版本的架构包括三大部分:身份管理（Identity）、账本和交易（Ledger | Transactions），智能合约（Smart Contact）。
为了方便应用开发，Fabric提供不同的SDK，对服务端的链码开发，目前提供Go、Java或者Node.js语言的SDK；对客户端应用开发，目前提供Node.js、Java语言、Go语言版本的SDK。Fabric提供了RESTAPI，对于开发者，可以通过CLI快速去测试链码，或者去查询交易状态。在区块链网络里，节点和链码会发送事件来触发一些监听动作，方便与其它外部系统的集成。
Fabric是目前为止在设计上最贴近联盟链思想的区块链。联盟链考虑到商业应用对安全、隐私、监管、审计、性能的需求，提高准入门槛，成员必须被许可才能加入网络。Fabric的身份管理（Identity）为整个区块链网络提供身份管理、隐私、保密和可审计的服务。身份管理通过公钥基础设施PKI和去中心化共识机制使得非许可的区块链变成许可制的区块链。
Fabric区块链中，采用数字证书机制负责对网络中的成员身份进行管理，CA节点实现了PKI服务。
PKI（Public Key Infrastructure）是综合多种密码学手段来实现安全可靠传递消息和身份确认的一个框架和规范。通常，PKI包括三部分：CA（Certification Authority）负责证书的颁发和作废，接收来自RA的请求； RA（Registration Authority）负责对用户身份进行验证，校验数据合法性，负责登记，审核通过则发给CA；证书数据库用于存放证书，一般采用LDAP目录服务，标准格式采用X.500系列。
CA是PKI体系最核心的组件，主要完成对公钥的管理。密钥有两种类型：用于签名和用于加解密，对应称为签名密钥对和加密密钥对。 用户基于PKI体系要申请一个证书，一般可以由CA来生成证书和私钥，也可以自己生成公钥和私钥，然后由CA来对公钥进行签发。
Fabric使用建立在HTTP/2上的P2P协议来管理分布式账本，采取可插拔的方式来根据具体需求来设置共识协议，比如PBFT，Raft，PoW和PoS等。
Fabric网络的数据以分布式账本的形式存储。账本由一系列有顺序和防篡改的记录组成，记录包含着数据的全部状态改变。账本中的数据项以键值对的形式存放，账本中所有的键值对构成了账本的状态，称为世界状态（World State）。
每个通道中有唯一的账本，通道的账本由通道中所有成员共同维护，每个记账节点上都保存所属通道的账本的一个副本，因而是分布式账本。对账本的访问需要通过链码实现对账本键值对的增加、删除、更新和查询等操作。
账本由区块链和状态数据库两部分组成。
区块链是一组不可更改的有序的区块（数据块），记录着全部交易的日志。每个区块中包含若干个交易的数据，不同区块所包含的交易数量可以不同。区块之间用哈希链（Hashed-link）关联：每个区块头包含本区块所有交易的哈希值，以及上一个区块头的哈希值。链式结构可以确保每个区块的数据不可更改，以及每个区块之间的顺序关系不可更改。因此，区块链的区块只可以添加在链的尾部。
状态数据库记录了账本中所有键值对的当前值，相当于对当前账本的交易日志做了索引。链码执行交易的时候需要读取账本的当前状态，从状态数据库可以迅速获取键值的最新状态。
如果没有状态数据库，要获得某个键值时，需要遍历整个区块链中和该键值相关的交易，效率非常低，因此，读取状态数据库可以认为是快速定位和访问某个键值的方法。另外，当状态数据库出现故障的时候，可以通过遍历账本重新生成。
当一个区块附加到区块链尾部的时候，如果区块中的有效交易修改了键值对，则会在状态数据库中作相应的更新，确保区块链和状态数据库始终保持一致。
区块链的数据块以文件形式保存在各个节点中。状态数据库可以是各种键值数据库，Fabric缺省使用LevelDB ，同时支持CouchDB选项。CouchDB除了支持键值数据外，也支持JSON格式的文档模型，能够做复杂的查询。
Fabric区块链的交易分两种，部署交易和调用交易。
部署交易把链码部署到Peer节点上并准备好被调用，当一个部署交易成功执行时，链码就被部署到各个背书节点上。
调用交易是客户端应用程序通过Fabric提供的API调用先前已部署好的某个链码的某个函数执行交易，并相应地读取和写入KV数据库，返回是否成功或者失败。
Fabric上的智能合约（Smart Contract）称为链码（ChainCode），是一段代码，用于处理网络成员所同意的业务逻辑。Fabric链码和底层账本是分开的，升级链码时并不需要迁移账本数据到新链码当中，真正实现了逻辑与数据的分离。
链码可采用Go、Java、Node.js语言编写。链码被编译成一个独立的应用程序，Fabric用Docker容器来运行链码，容器里的base镜像都是经过签名验证的安全镜像，包括OS层和开发链码的语言、runtime和SDK层。一旦链码容器被启动，就会通过gRPC与启动链码的Peer节点连接。
业务通道，即共识网络或区块链网络，由不同的节点构成。节点是区块链的通信实体，是一个逻辑概念，不同类型的节点可以运行在同一台物理服务器上。节点可能部署在云上或者本地，可能来自不同的公司或者组织。排序服务提供了供Peer节点订阅的主题（如发布-订阅消息队列），每个主题是一个通道。Peer节点可以订阅多个通道，并且只能访问自己所订阅通道上的交易。
在区块链网络中有两种类型的节点：Peer节点和Orderer节点。
Peer节点：链码部署在Peer节点（背书节点）上，对账本进行读写操作。一个Peer节点可以充当多种角色，如背书节点（endorser），确认节点（committer）。一个区块链网络中会有多个Peer节点。
Orderer节点：对交易进行排序，批量打包交易，生成区块，发给Peer节点（记账节点）。一个区块链网络中会有多个Orderer节点，共同提供排序服务。排序服务可以以多种不同的方式实现，从一个中心化的服务（被用于开发和测试，如Solo）到分布式协议（如Kafka）。
排序服务提供了通向客户端和Peer节点的共享通信通道，提供了包含交易的消息广播服务（broadcast和deliver）。客户端可以通过通道向通道内的所有节点广播（broadcast）消息，通道可以向连接到通道的所有节点投递(deliver)消息。
排序服务支持多通道。客户端和Peer节点可以连接到一个具体的通道，并通过通道发送和接收消息。多通道使得Peer节点可以基于应用访问控制策略来订阅任意数量的通道；应用程序在指定Peer节点的子集中架设通道，Peer节点组成提交到该通道交易的相关者集合，而且只有通道内的Peer节点可以接收包含相关交易的区块，与其它交易完全隔离，实现数据隔离和保密。
此外，Peers的子集将私有块提交到不同的账本上，允许它们保护这些私有交易，与其它Peer子集的账本隔离开来。应用程序根据业务逻辑决定将交易发送到1个或多个通道。
Peer 1，2和N订阅红色通道，并共同维护红色账本；Peer 1和N订阅蓝色通道并维护蓝色账本；Peer 2和peer N在黑色通道上并维护黑色账本。每个通道都有一个相关的账本，通常，不涉及所有Peer节点的账本为子账本，另一种是系统账本，即全账本。
目前通道分为系统通道（System Channel）和应用通道（Application Channel）。排序节点通过系统通道来管理应用通道，用户的交易信息通过应用通道传递。
通道由排序服务节点负责管理，同时排序服务节点还负责对通道中的交易进行排序。在通道中一般包含有若干成员（组织），若两个网络实体的×××书能够追溯到同一个根CA，则认为这两个实体属于同一组织。此外，通道中的每个组织都会有一个或以上的锚节点，锚节点负责与其它组织交换共享账本的数据。
创建通道的时候定义了成员，只有通过成员MSP验证的实体，才能够加入到通道并访问通道数据。
通道的配置信息都被打包到一个区块中，并存放在通道的共享账本中，成为通道的配置区块，配置区块除了配置信息外不包含其它交易信息。通道可以使用配置区块来更新配置，因此在账本中每新添加一个配置区块，通道就按照最新配置区块的定义来修改配置。通道账本的首个区块一定是配置区块，也称为创世区块（Genesis Block）。
通道CLI客户端可以使用命令对通道进行管理。
peer channel create: 用于创建通道，主要参数有-c, -f, -o分别用于指定通道ID, configtx的路径和orderer的地址。
peer channel fetch：抓取通道中的特定区块，通过-c和-f参数来指定通道ID和orderer地址。
peer channel join：加入通道，通过-b参数指定初始区块。
peer channel list：列出peer加入的通道。
peer channel update ：签名并且发送configtx以升级通道配置，需要通过-c, -f, -o参数分别指定通道ID, configtx的路径以及排序节点的地址。
在通道创建后，通道相关的配置以区块的形式存在于通道的账本中。如果需要修改通道的配置，可通过生成新的配置区块去更新。修改通道配置的步骤如下：
A、通过SDK或CLI获得最新的配置区块。
B、编辑配置区块。
C、计算配置更新量。
D、为配置区块添加配置更新量。
E、SDK或CLI签名并发送配置区块。
若新的配置区块通过验证，则通道配置以最新配置区块为准。
Fabric v1.0的交易流程如下：
区块链的账本由Peer节点维护，并不是由排序服务集群维护，所以，只有Peer节点（背书节点和确认节点）包含完整的区块链信息，而排序服务集群只负责对交易进行排序，只保留处理过程中的一部分区块链信息。Hyperledger Fabric网络中的节点是一个逻辑的概念，并不一定是一个台物理设备，但对于生产环境，为了系统架构的解耦，提高扩展性以及通过主机隔离提高安全性，Peer节点不能和排序服务节点部署在一台机器上，而背书节点和确认节点可以部署在同一台机器上。背书节点校验客户端的签名，然后执行智能合约代码模拟交易。交易处理完成后，对交易信息签名，返回给客户端。客户端收到签名后的交易信息后，发给排序服务节点排序。排序服务节点将交易信息排序打包成区块后，广播发给确认节点，写入区块链中。
客户端应用程序利用SDK（Node.js，Java，Python）构造交易提案（Proposal）。交易提案是一个调用智能合约功能函数的请求，用来确认哪些数据可以读取或写入账本。
客户端把交易提案发送给一个或多个背书节点，交易提案中包含本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等。
SDK将交易提案打包为可识别的格式（如gRPC上的protobuf），并使用用户的加密凭证为该交易提案生成唯一的签名。
背书节点（endorser）收到交易提案后，验证签名并确定提交者是否有权执行操作。背书节点将交易提案的参数作为输入，在当前状态KV数据库上执行交易，生成包含执行返回值、读操作集和写操作集的交易结果（此时不会更新账本），交易结果集、背书节点的签名和背书结果（YES/NO）作为提案的结果返回给客户端SDK，SDK解析信息判断是否应用于后续的交易。
客户端应用程序（SDK）验证背书节点签名，并比较各节点返回的提案结果，判断提案结果是否一致以及是否参照指定的背书策略执行。
客户端收到各个背书节点的应答后，打包到一起组成一个交易并签名，发送给排序服务节点。
排序服务节点对接收到的交易进行共识排序，然后按照区块生成策略，将一批交易打包到一起，生成新的区块，调用deliver API投递消息，发送给确认节点。
确认节点收到区块后，会对区块中的每笔交易进行校验，检查交易依赖的输入输出是否符合当前区块链的状态，完成后将区块追加到本地的区块链，并修改K-V状态数据库。
Fabric联盟链的开发人员主要分为三类：底层开发者负责系统部署与维护；组织管理者负责证书、MSP权限管理、共识机制等；业务开发者负责编写链码、创建维护通道、执行交易等。
Fabric区块链开发流程主要包括智能合约编写，通过SDK调用智能合约，订阅各类事件。
开发者创建客户端应用和链码，链码被部署到区块链网络的背书节点上。通过链码来操作账本，当客户端调用一个交易时，实际上是在调用链码中的一个实现业务逻辑的函数方法，并对账本进行get, put, delete操作。客户端应用提供用户交互界面，并提交交易到区块链网络上。
HyperLeger Fabric开发（三）——HyperLeger Fabric架构
标签：建立 通信 ann 标准 编辑 不能 核心 处理 vpd
原文地址：http://blog.51cto.com/9291927/2315587
