hyperledger

一、搭建基础环境 参考：https://www.cnblogs.com/sky-cheng/p/12150822.html 二、下载Hyperledger Fabric 源代码 查看$GOPATH环境变量 [root@localhost home]# echo $GOPATH /home/go 在/home/go下建立如下目录 [root@localhost home]# mkdir -p /home/go/src/github.com/hyperledger [root@localhost home]# 进入新建的目录，下载Fabric源代码 [root@localhost home]# cd /home/go/src/github.com/hyperledger/ [root@localhost hyperledger]# git clone https://github.com/hyperledger/fabric.git 正克隆到 'fabric'... remote: Enumerating objects: 12, done. remote: Counting objects: 100% (12/12), done. remote: Compressing objects: 100% (11/11), done. remote: Total 125935 (delta

参考： https://blog.csdn.net/li_jiachuan/category_8094510.html identity owner（我们自己） claims（关于identity owner的不同类型的assertions，在数字身份业界中的称呼） issuer（颁发者，可信机构） verifier（验证者，需要相信claims的个人或公司） verifiable claims（定义、交换和验证数字凭证的一个标准的方式） Decentralized identifier，DID（去中心化的身份标识） PKI的问题 PKI的本质问题是它很笨重，昂贵并且是中心化的 当今浏览器中使用的PKI依赖于一些数量（几百个）certificate authorities（CAs）作为roots of trust。 从声誉好的CAs那里获得certificates是需要花费时间和精力的。能够称为一个CA被描述为有执照来印钱，因为这些中心化的roots of trust被构建到了浏览器和其他的软件当中。这就是为什么大多数的数字证书（digital certificates）是由公司购买的，而不是个人。这个对于个人来讲太难应用。 更糟糕的是，在我们的数字信任基础设施（digital trust infrastructure）中插入了这样一个中间人会造成危险

在fabric中，共识过程意味着多个节点对于某一批交易的发生顺序、合法性以及它们对账本状态的更新结构达成一致的观点。满足共识则意味着多个节点可以始终保证相同的状态，对于以同样顺序到达的交易可以进行一致的处理。 具体来看，fabric中的共识包括背书、排序和验证三个环节的保障。 我们先来研究下背书策略。 一.什么是背书策略 chaincode在实例化的时候，需要指定背书策略。这里的背书策略就是需要什么节点背书交易才能生效。 发起交易的时候，发起端（一般是SDK），需要指定交易发给哪些节点进行背书验证（fabric不会自动发送），而是由sdk发送。发送后等待背书节点的返回，收集到足够的背书后将交易发送给orderer（排序节点或称共识节点）进行排序打包分发。最后，当每个Peer接受到block数据后，会对其中的交易进行验证，如果交易不符合背书策略，就不会在本地生效，所以真正验证背书是在这一步。 二.Endorsement policy 设计 背书策略有两个主要组成部分： 主体（principal）：P定义了期望的签名来源实体 门槛（thshold gate）：T有两个参数：整数t（阈值）和n个主体，表示从这n个主体中获取t个签名 例如： T(2, 'A', 'B', 'C')表示需要A、B、C中任意2个主体的签名背书 T(1, 'A', T(2, 'B', 'C')