Hyperledger Fabric 学习 什么是区块链 什么是区块链在我们没有接触的时候,只知道它是一个去中心化的存储方式.当我们发生交易,或者动作的时候我们会将记录通知给所有参与者共同维护,达到去中心化的进行存储.并且我们会将记录使用加密技术保证记录一旦添加到了账本中就无法修改(无法修改的账本就可以追溯信息根源)这个也就是区块链有时候被称为证明系统. 区块链使用场景 多方参与 跨机构数据共享需求 能够除本增收 提高工作效率 智能合约 智能合约也就是我们说的链码,我们可以通过智能合约访问我们的

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

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

HyperLedger:超级账本项目 一.Fabric中的节点 1.节点术语 [1].Orderers: 提供共识服务的网络节点,例如,使用Kafka或PBFT [2].Peers:     维护账本的网络节点,通常在Hyperledger Fabric中担任背书或者记账角色. [3].Comitter:     检查交易的合法性,最终将交易提交到区块链中. 2.Orderers & Peers & Comitter节点关系 Orderers & Peers & Comit

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

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

之前介绍了使用官方脚本自动化启动一个Fabric网络,并且所有的证书都是通过官方的命令行工具cryptogen直接生成网络中的所有节点的证书.在开发环境可以这么简单进行,但是生成环境下还是需要我们自定义对网络中的节点的证书进行配置. 所以在本文中,将会详细介绍一个从手动生成证书一直到启动网络的整体步骤.本文只交代整体的搭建步骤.对于Fabric-Ca的讲解不在本文的范围内,将在另一篇文章中说明. 正篇文章也是根据官方的文档进行的.但是由于官方的文档尚未完工,也是好多没有交代清楚的,并且有些地方是

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

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

死磕hyperledger fabric源码|Order节点概述 文章及代码:https://github.com/blockchainGuide/ 分支:v1.1.0 前言及源码目录 Orderer排序节点这块内容主要包括了节点启动流程.Broadcast广播交易服务.Orderer共识排序服务以及Deliver区块分发服务.其相关源码目录文件如下: /orderer |-common ​ |-blockcutter:交易切割打包模块 ​ |-bootstrap:引导启动模块,生成创世块 ​

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

转载地址:http://www.cnblogs.com/lxblog/archive/2012/09/20/2695397.html 前一篇我们演示了基于SSL的WCF 对客户端进行用户名和密码方式的认证,本篇我们演示一下服务器端对客户端采用X.509证书的认证方式是如何实现的. 项目结构及服务代码和前两篇代码是基本一样的,为了大家看着方便,再从头到尾进行一下演示. 一.制作证书: 本次制作证书和第一篇略有不一样,主要为了演示证书的信任链关系,我们首先创建一个证书作为证书认证中心(CA)的根证书

转载地址:http://www.cnblogs.com/lxblog/archive/2012/09/12/2682372.html 一.WCF中的安全方式 说到安全就会涉及到认证,消息一致性和机密性,WCF的安全方式分为两种,即传输安全和消息安全. 传输安全和消息安全的区别:传输安全提供点对点的安全: 比如 A 提供服务,B和C直接连接到A,这时候A与B 及 A与C直接的传输是安全的,如果B通过C连接到A,那么A与B直接是安全的,B与C之间是不安全的.消息安全:是把安全机制都应用在消息级别上面

顾名思义,物化节点是一类可缓存元组的节点.在执行过程中,很多扩展的物理操作符需要首先获取所有的元组后才能进行操作(例如聚集函数操作.没有索引辅助的排序等),这时要用物化节点将元组缓存起来.下面列出了PostgreSQL中提供的物化节点. 物化节点概述 物化节点需要有元组的缓存结构,以加快执行效率或实现特定功能(例如排序等).物化节点的功能种类多样,实现过程也不尽相同,缓存的方式也有所不同,主要使用了 tuplestore来进行缓存.tuplestore使用Tuplestorestate数据结构

openssl创建私钥,获取公钥,创建证书都是比较简单的,就几个指令,很快就可以搞定,之所以说简单,是因为证书里面的基本参数配置不需要我们组装,只需要将命令行里面需要的几个参数配置进去即可.但是呢,用java代码,原生创建证书,其实需要我们了解的内容就要稍微多点,去填充创建证书里面的所需要的参数,逐行填充. openssl证书的格式默认是PEM的,即Privacy Enhanced Mail,说白了,就是将创建后的证书元素数据经过Base64编码,然后添加类似----BEGIN CERTIFIC

目录 简要说明 安装环境说明 部署 生成相关证书 证书类型说明 安装cfssl证书生成工具 生成CA证书 生成Kubernetes master节点使用的证书 生成kubectl证书 生成kube-proxy证书 生成token及kubeconfig 生成token文件 生成http basic认证文件 生成用于kubelet认证使用的bootstrap.kubeconfig文件 生成kube-proxy使用的kube-proxy.kubeconfig文件 部署etcd 部署master kub

最近在学习WCF X.509证书验证,想实现使用证书实现服务端和客户端的双向认证,实现原理是利用了数字证书包含的一对非对称密钥来实现数字签名及加密.所谓非对称密钥是采用两个密钥将加密和解密能力分开:一个公钥和一个私钥,公钥可解密私钥加密的信息,私钥也可以解密公钥加密的信息,前者用于数字签名后者用于信息加密,但从一个密钥是不可能分析出另一个密钥.利用非对称密钥的特点,我们将私钥签名的证书安装在服务端,把公钥签名的证书放在客户端,就可以实现使用证书实现服务端和客户端的双向认证.具体步骤如下: [1]

上一篇我们介绍了kubernetes集群架构以及系统参数配置,参考:二进制搭建kubernetes多master集群[开篇.集群环境和功能介绍] 下面本文etcd集群才用三台centos7.5搭建完成. etcd1:192.168.80.4 etcd2:192.168.80.5 etcd3:192.168.80.6 一.创建CA证书和密钥 kubernetes 系统各组件需要使用 TLS 证书对通信进行加密,本文档使用 CloudFlare 的 PKI 工具集 cfssl 来生成 Certifi

一.部署kubelect 二进制包准备 将软件包从linux-node1复制到linux-node2.linux-node3中去 [root@linux-node1 ~]# cd /usr/local/src/kubernetes/server/bin/ [root@linux-node1 bin]# cp kubelet kube-proxy /opt/kubernetes/bin/ [root@linux-node1 bin]# scp kubelet kube-proxy 192.168.

.net环境下须要p12文件,下面是生成p12过程 1.$ openssl x509 -in aps_development.cer -inform der -out PushChatCert.pem 2.$ openssl pkcs12 -nocerts -out PushChatKey.pem -in PushChatKey.p12 3.$ cat PushChatCert.pem PushChatKey.pem > ck.pem 4.$ openssl pkcs12 -export -in

一.证书目录解析   通过cryptogen生成所有证书文件后,以peerOrgannizations的第一个组织树org1为例,每个目录和对应文件的功能如下:   ca: 存放组织的根证书和对应的私钥文件,默认采用EC算法,证书为自签名.组织内的实体将基于该证书作为证书根. tlsca:存放组织tls连接用的根证书和私钥文件.(TLS是传输层安全协议,其实就是SSL,现在叫TLS了) msp:存放代表该组织的身份信息.        admincerts:组织管理员的身份验证证书,被根证书签名