在Fabric中,尽管所有对等节点/peer都是相同的,但它们可以根据网络的配置方式承担多个角色:(①②是主要的节点类型) ①提交节点: 通道中的每个对等节点都是一个提交节点.它们接收生成的交易区块,随后这些区块在被提交到节点的账本副本之前先被验证. ②背书节点: 具有智能合约的每个对等节点都可以是背书节点.要真正成为一个背书节点,客户端应用程序必须使用对等节点上的智能合约来生成经过数字签名的交易响应.智能合约的背书策略标识了哪些组织中的节点应该在交易被提交节点的账本副本接受之前对交易进行背书.

7:Fabric多节点集群生产启动 7.1.多节点服务器配置 在生产环境上,我们沿用4.1.配置说明中的服务器各节点配置方案. 我们申请了五台生产服务器,其中四台服务器运行peer节点,另外一台服务器运行orderer节点,为其它四个节点提供排序服务. 虚拟机具体参数如下表所示: 名称 ip 节点标识 节点Hostname Organization(组织机构) Server1 10.130.116.8 orderer orderer.example.com Orderer Server2 10.

hyperledger fabric各类节点及其故障分析   1.Client节点 client代表由最终用户操作的实体,它必须连接到某一个peer节点或者orderer节点上与区块链网络通信.客户端向endorser提交交易提案,当收集到足够背书后,向排序服务广播交易,进行排序,生成区块.但是该节点的故障不会影响区块链网络的正常运行. 2.CA节点 CA节点是hyperledger 1.0的证书颁发机构,由服务器(fabric-ca-service)和客户端组件(fabric-ca-clien

八:判断实例是否客观下线 当前哨兵一旦监测到某个主节点实例主观下线之后,就会向其他哨兵发送"is-master-down-by-addr"命令,询问其他哨兵是否也认为该主节点主观下线了.如果有超过quorum个哨兵(包括当前哨兵)反馈,都认为该主节点主观下线了,则当前哨兵就将该主节点实例标记为客观下线. 注意,客观下线的概念只针对主节点实例,而与从节点和哨兵实例无关. 1:发送"is-master-down-by-addr"命令 "is-master-do

6.1.平台特定使用的二进制文件配置 该方案与Hyperledger Fabric 1.0 从零开始(五)--运行测试e2e类似,根据企业需要,可以控制各节点的域名,及联盟链的统一域名.可以指定单独节点的访问,生成指定的公私钥.证书等文件.具体的参数配置可以参考generateArtifacts.sh文件,可执行自动化生成,也可以按照该脚本里的命令手动生成. 参照3.1.运行fabric-samples的问题说明,首先我们在/opt/gopath/src/github.com/hyperledg

Fabric区块链网络的组成  区块链网络结构图 区块链网络组成 组成区块链网络相关的节点 节点是区块链的通信主体,和区块链网络相关的节点有多种类型:客户端(应用).Peer节点.排序服务(Orderer)节点.CA节点 客户端(应用程序)节点 客户端必须连接到某一个Peer节点或者排序服务节点才可以与区块链网络通信. Peer节点 Peer节点主要负责通过执行链码(chaincode)实现对账本的读写操作 所有的Peer节点都是记账节点(Committer),负责维护状态数据和账本的副本 部

1.Client节点 client代表由最终用户操作的实体,它必须连接到某一个peer节点或者orderer节点上与区块链网络通信.客户端向endorser提交交易提案,当收集到足够背书后,向排序服务广播交易,进行排序,生成区块.但是该节点的故障不会影响区块链网络的正常运行. 2.CA节点 CA节点是hyperledger 1.0的证书颁发机构,由服务器(fabric-ca-service)和客户端组件(fabric-ca-client)组成.CA节点接收客户端的注册申请,返回注册密码用于用户登

一个新节点通过已知的节点加入到网络中,此时,它所知的网络节点信息是非常有限的,需要通过节点发现获知更多的节点,建立起足够的连接.另外,当一个新节点加入到网络时,原有网络节点也需要通过节点发现感知到新节点的加入. 分布在各地的网络节点总是会有上线离线的变化,有这就需要Fabric网络必须动态维护一个节点成员列表,这就需要节点成员管理. 一.节点发现与成员管理 1. 节点发现 一个节点要加入Fabric网络,必须要知道至少一个已知Fabric节点作为启动节点. 相关配置如下: # Gossip re

安装文档:http://www.cnblogs.com/studyzy/p/7437157.html 安装上面的文档安装成功,但是过程中遇到一些问题. 一.go的源码包可能下载不下来,因为被墙,go官方提供了以下的安装方式,可以直接apt安装golang-1.9 $ sudo add-apt-repository ppa:gophers/archive $ sudo apt update $ sudo apt-get install golang-1.9-go Note that golang-

Orderer 节点启动通过 orderer 包下的 main() 方法实现,会进一步调用到 orderer/common/server 包中的 Main() 方法. 核心代码如下所示. // Main is the entry point of orderer process func Main() { fullCmd := kingpin.MustParse(app.Parse(os.Args[1:])) // "version" command if fullCmd == ver

手动部署单机单节点 之前发布过官方的e2e部署方案,由于环境或是访问权限等各种问题,还是有相当一部分码友无法成功跑起来,故此,本章将来一次纯手动操作的集群部署. 主要需要的步骤如下: 1:环境整理 2:环境部署 3:源码安装 4:生成证书文件 5:orderer节点处理 6:peer节点处理 7:channel创建加盟 8:chaincode安装部署实例化.测试 本次不再分章,一章写完. 环境整理 这一步并非必须,但鉴于docker容器的实际情况,理论上linux内核需要在3.10及以上.有朋友

Hyperledger Fabric动态配置Raft节点 最近看官方文档发现新的共识算法etcdRaft允许动态添加或删除排序节点,所以也花了一天时间操作了以下,写篇文章把整个过程记录一下. 初始网络本文设置了4个Orderer节点,1个Peer节点(用于更新配置文件以及测试用),然后动态添加第五个Orderer节点. 本文分成两个部分: 第一部分是手动通过Fabric-CA生成每一个节点的证书文件 第二部分是更新Fabric网络配置添加新的Orderer节点. 本文基于Fabric v2.0.

Fabric 1.4 源码分析 Endorser背书节点 本文档主要介绍fabric背书节点的主要功能及其实现. 1. 简介 Endorser节点是peer节点所扮演的一种角色,在peer启动时会创建Endorser背书服务器,并注册到本地gRPC服务器(7051端口)上对外提供服务,对请求的签名提案消息执行启动链码容器.模拟执行链码.背书签名等流程.所有客户端提交到账本的调用交易都需要背书节点背书,当客户端收集到足够的背书信息之后,再将签名提案消息.模拟执行的结果以及背书信息打包成交易信息发给

注意:在对Service Fabric的节点做操作之前,请务必确认是否是种子节点(Seed Node)且当前节点的数量是否与SF的持久层要求的数量一致. 可靠性级别是 Service Fabric 群集资源的一个属性. 对于各个节点类型,此属性的配置必须相同. 该属性控制群集系统服务的复制因子,是群集资源级别的设置.可靠性级别决定了主节点类型必须具有的节点数下限. 可靠性层可以采用以下值: 白金:运行包含 7 个目标副本集和 9 个种子节点的系统服务. 金:运行包含 7 个目标副本集和 7 个种

在HyperLedger/Fabric发布0.6的时候,公司就已经安排了一个团队研究这一块,后来也请IBM的专家组过来培训了一批人,不幸的是,这批人后来全走了,然后没过多久1.0就发布了.自从2017年7月HyperLedger/Fabric发布了1.0正式版后(可以参考:Hyperledger Fabric 1.0发布:基于区块链的开源分布式账本),公司领导就更加关注这个领域.然后,就安排我一个人来接手,我主要是做Android和iOS方向的开发,偶尔客串一下java后台服务开发,对linux

在HyperLedger/Fabric发布0.6的时候,公司就已经安排了一个团队研究这一块,后来也请IBM的专家组过来培训了一批人,不幸的是,这批人后来全走了,然后1.0就发布了.自从2017年7月HyperLedger/Fabric发布了1.0正式版后(可以参考:Hyperledger Fabric 1.0发布:基于区块链的开源分布式账本),公司领导就更加关注这个领域,就安排我一个人来接手,培训的机会也没有了.我主要是做Android和iOS方向的开发,也做java后台服务开发,对zookee

fabric 共识机制 由于fabric是分布式的系统,因此需要共识机制来保障各个节点以相同的顺序状态保存账本,达成一致性. 在当前fabric1.4版本中,存在三种共识机制,分别是solo,kafka,etcdraft.交易的共识包括3个阶段的处理:提议阶段.打包阶段和验证阶段. 1.Solo 共识模式 Solo共识模式指网络环境中只有一个排序节点,从Peer节点发送来的消息由一个排序节点进行排序和产生区块:由于排序服务只有一个排序节点为所有Peer节点服务,没有高可用性和可扩展性,不适合用于

前言 在Hyperledger Fabric无系统通道启动及通道的创建和删除中,我们已经完成了以无系统通道的方式启动 Hyperledger Fabric 网络,并将链码安装到指定通道.但目前为止,实验中的 orderer 服务都是通过单独的排序组织来维护且只有一个,那能不能不要排序组织而使用普通组织来运行维护多个 orderer 服务呢?当然是可以的,本文将在之前的实验基础上,启动一个没有 orderer 组织的 Fabric 网络,网络中包含三个组织且每个组织运行维护着一个 Raft 协议的

虽然Service Fabric的Java支持版本还没有正式发布,但是Service Fabric本身的服务管理.部署.升级等功能是非常好用的,那么Java的开发者可以如何利用上Service Fabric的这个功能呢?答案很简单,其实只要利用Service Fabric的Deploy Guest Executable就好了,也就是说Service Fabric是允许部署一个或者多个独立运行的exe,并且运行在Service Fabric的节点中的.详细的信息可以参看官方的这个文档: https

5:启动Fabric多节点集群 5.1.启动orderer节点服务 上述操作完成后,此时各节点的compose配置文件及证书验证目录都已经准备完成,可以开始尝试启动多机Fabric集群. 首先启动orderer节点,切换至orderer.example.com服务器,即前文指定的10.130.116.8服务器,执行如下命令进入启动docker进程: docker-compose -f docker-compose-orderer.yaml up -d 运行完毕后我们可以使用docker ps看到