Fabric 1.4源码分析 kafka共识机制 本文档主要介绍kafka共识机制流程.在查看文档之前可以先阅览raft共识流程以及orderer服务启动流程. 1. kafka 简介 Kafka是最初由Linkedin公司开发,是一个分布式.分区的.多副本的.多订阅者,基于zookeeper协调的分布式日志系统,一种高吞吐量的分布式发布订阅消息系统.kafka详细介绍可以参考这一篇博客.kafka介绍 2. kafka共识 kafka共识当中,每个orderer节点即是生产者Producer也

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

Fabric 1.4 源码分析 背书节点和链码容器交互 本文档主要介绍背书节点和链码容器交互流程,在Endorser背书节点章节中,无论是deploy.upgrade或者调用链码,最后都会调用ChaincodeSupport.LaunchInit()/Launch()以及ChaincodeSupport.execute()方法.其中Launch()方法启动链码容器,execute()方法调用链码. 1. 准备 ChaincodeSupport.Launch()首先进行判断,根据peer侧该版本链

☞ ░ 前往老猿Python博文目录 ░ 在Hyperledger Fabric区块链中,有背书节点进行背书,Hyperledger Fabric 使用背书策略来定义哪些节点需要执行交易. Hyperledger Fabric在区块链交易方面采取了一个新颖的思路,将智能 合约的执行与账本的更新分开使它可以提高交易吞吐量,支持更细粒度 的隐私控制,实现更灵活强大的智能合约.而这些特性得以实现的一个 关键因素就是在交易加入账本之前进行显式地交易背书. 1.背书 背书"这个词源来自银行票据业务,传统意

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

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节点接收客户端的注册申请,返回注册密码用于用户登

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

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

一个新节点通过已知的节点加入到网络中,此时,它所知的网络节点信息是非常有限的,需要通过节点发现获知更多的节点,建立起足够的连接.另外,当一个新节点加入到网络时,原有网络节点也需要通过节点发现感知到新节点的加入. 分布在各地的网络节点总是会有上线离线的变化,有这就需要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

在fabric中,共识过程意味着多个节点对于某一批交易的发生顺序.合法性以及它们对账本状态的更新结构达成一致的观点.满足共识则意味着多个节点可以始终保证相同的状态,对于以同样顺序到达的交易可以进行一致的处理. 具体来看,fabric中的共识包括背书.排序和验证三个环节的保障. 我们先来研究下背书策略. 一.什么是背书策略 chaincode在实例化的时候,需要指定背书策略.这里的背书策略就是需要什么节点背书交易才能生效. 发起交易的时候,发起端(一般是SDK),需要指定交易发给哪些节点进行背书验

以前从来没有写过博客,从这段时间开始才开始写一些自己的博客,之前总觉得写一篇博客要耗费大量的时间,而且写的还是自己已经学会的,觉得没什么必要.但是当开始用博客记录下来的时候,才发现有些学会的地方只是自己觉得已经学会了,还是有太多地方需要学习,眼高手低了,所以以后会养成写博客的好习惯,保持记录. 今天记录一下之前阅读过的源码:Peer节点背书提案过程. 1 起点 首先定位到core/endorser/endorser.go这个文件中的ProcessProposal()方法在第450行.其实对于Pe

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

Fabric 1.4 源码分析 committer记账节点 本文档主要介绍committer记账节点如何初始化的以及committer记账节点的功能及其实现. 1. 简介 记账节点负责验证交易和提交账本,包括公有数据(即区块数据,包括公共数据和私密数据hash值)与私密数据.在提交账本前需要验证交易数据的有效性,包括交易消息的格式.签名有效性以及调用VSCC验证消息的合法性及指定背书策略的有效性,接着通过MVCC检查读写集冲突并标记交易的有效性,最后提交区块数据到区块文件系统,建立索引信息并保存

背书策略 背书策略用于指导peer如何确定交易是否得到了的认可.当一个peer接收到一个事务时,它会调用与事务的Chaincode相关联的VSCC(验证系统链代码),作为事务验证流程的一部分,以确定交易的有效性.一个交易包含了一个或多个peer背书节点中的背书支持.VSCC的任务是做出以下决定: 所有的背书都是有效的(也就是说,它们是有效的签名,而不是预期的消息). 有适当数量的背书 背书来自预期的来源(s) 背书策略指的是第二和第三点其中的一种方式. CLI中的背书策略语法 在CLI中,使用一

手动部署单机单节点 之前发布过官方的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.

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

Membership Service Providers (MSP) 本文将介绍有关MSPs的设置和最佳实践的详细方案. Membership Service Providers (MSP)是一个旨在提供成员操作体系结构抽象的组件. 尤其是MSP抽象出发布和验证证书的所有加密机制.协议以及用户身份验证.MSP可以自定义身份概念,以及这些身份被管理的规则(身份验证)和认证加密(签名生成和验证). 一个Hyperledger Fabric区块链网络可以由一个或多个MSPs管理.这提供了成员操作的模块