Hyperledger
Hyperledger is an open source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration, hosted by The Linux Foundation, including leaders in finance, banking, IoT, supply chain, manufacturing and technology.
https://www.hyperledger.org/
https://www.hyperledger.org/projects/fabric
Hyperledger fabric
- 模块化
- 可扩展
- 超安全
Hyperledger fabric的革命性在于, 他提供了一种组织之间互相信任的机制, 让所有的数据和信息变化变得可信, 并且这种信任是不需要依赖任何一个中央机构.
Hyperledger fabric不是一个普通的软件或者框架 解决普通问题
hyperledger fabric是一个全新的解决问题的方式.
解决的最重要的问题, 如何在不信任的个体和组织中引入信任机制.
这种信任机制可以创建更高效的商业模式, 你不需要关心中间人, 信任和安全问题
一句话描述, hyperledger fabric是基于区块链的企业级分布式账本技术,通过智能合约解决多个组织之间的信任问题.
在案例中, 你会对上面这句话有更加深刻的体会.
几个名词回顾
Hyperledger:
由linux基金会孵化的区块链技术
Hyperledger Fabirc:
第一个孵化出来的商用的DLT 框架
Hyperledger composer:
一个在DLT框架上创建商业应用的工具
理解hyperledger fabric 1.1的基本概念和软件架构
能根据企业业务情况,分析hyperledger fabric的应用场景
熟悉hyperledger fabric的关键组件: peer, ordering service, ca和msp
能够建立测试网络,使用node sdk编写应用程序
能够使用nodejs编写链码(智能合约)
能够参与到hyperledger fabric开源项目的讨论和开发中
测验1:
hyperledger是什么
A. linux基金会孵化重点项目
B. DLT 框架
C. DLT 工具集
在DLT中分布式存储的是什么
A. 数据
B. 账本(book of records)
C. 技术
D. 资产
资产(assert)代表了什么
A. 价值
B. 账本
C. 转账信息
资产的变更会生成什么到DLT中
A. 价值(value)
B. 实体(entry)
C. 转账(transaction)
传统公有链能否解决下面的DLT问题 不能
- 隐私
- 机密
- 标准化
hyperledger用独特的共识协议:有个order(排序)节点进行验证,
数据完整性和安全性
hyperledger是一个分布式系统.
没有单点故障, 没有单点的信息存放,
每个节点都保存了全部的数据.
所有的节点都保存了一致的区块链数据, 不可篡改.
每个节点存放了所有的转账记录(账本)
假设你的商业模式是使用hyperledger记录某个资产的所有者,
因为某种原因, 你错误的登记了这个资产的所有人.
在hyperledger里面你没法把这个错误的记录删除.
你的做法只能是创建一个新的记录,标记之前的记录是错误的.
在区块链系统里面,没有删除的概念, 所有对数据的添加和修改都会被记录.
blockchain 记录了数据变化的过程.
每一笔transaction都会导致数据的变化, 变化后的状态叫世界状态(world state)
因为所有的node节点都保存了所有的transaction, 这些transaction都是一致的,
所以所有的node节点的世界状态也是一致的.
这个账本是由密码学签名保证.
所以说hyperledger 区块链技术重建信任.
hyperledger为什么特别适合企业级开发(business)
- premissioned network 授权网络
access control 访问控制
- confidential transaction 交易安全
transaction 是可以控制可见性的
- no cryptocurrency 无数字货币
没有旷工, 低成本, 验证操作灵活.
- programmable 可编程
chaincode (smart contract 智能合约)
使用hyperledger可以创建私有链, 可以创建联盟链, 甚至我们可以用hyperledger创建公有链.
只要node节点处于相同的网络节点, 他们可以互相发现, 我们就可以使用hyperledger 来让他们达成共识协议.
所以hyperledger的应用场景非常广泛, 在任何行业,任何应用场景都可以找到可以落地的需求.
最后再补充说一下 hyperledger 没有51%攻击.没有挖矿的概念, 因为hyperledger 采用了独特的共识协议,
每个共识协议的参与者都是由CA来认证的.
测试题
关于企业级商业化分布式账本技术(DLT)特点说法正确的是:(ABCD)
A. 需要是授权网络
B. 转账操作要安全可信
C. 没有挖矿的概念
D. 可编程
请你设计一套数字货币系统,可以实现转账和交易, 从技术角度下面的什么技术可以使用?(AB)
A. 以太坊
B. hyperledger
Assets, chaincode& ledger
- assets : 有价值的东西, 可以被交易的东西
json表示
- chaincode
transaction | business logic
- ledger
记录所有的transaction
所有的参与者都保存了ledger
超级账本:
- 记录全部的transaction -> 查找交易历史 快
- 记录当前 world states -> 查找当前余额/归属者 快
hyperledger如何解决现实生活中的问题
来看一下hyperledger fabric为什么有广泛的应用场景
有两个公司 A 和 B
交换一些东西(资产) 文档, 数字资产, 版权,健康记录,集装箱,房屋,车辆等... 他们交换一些东西
通常情况 a和b 互不信任.
两个公司都有自己的server 自己的服务器.
每周或者每月对账. 如果对账成功, 棒棒哒,
但是在现实生活中,他们从来都不匹配.
不同的软件,不同的技术栈,不同的操作人员.总总因素导致数据不匹配.
不匹配没关系, 对账啊.
如果你有个供应链 , 有10个组织, 之间怎么对账,怎么交流?
传统解决方案:
共同信任同一个中央机构.
问题:
- 花钱,好多好多钱
- 所有机构都要共同信任一个中央机构
- 最主要的问题, 中央机构出了问题? 这个事情是会发生的. 传统的技术目前没办法解决这个问题。
避免中央机构出问题, 超级复杂的审批流程.硬件级别访问控制.操作人员背景调查...数据篡改问题依然存在
新的解决方案:
所有数据在每个节点同步, 通过智能合约描述商业流程.
hyperledger 保证数据实时同步, 所有的node节点保存同步的数据.
如果有人修改了自己的数据. 所有其他的party就能立刻发现数据错误了.
即使一个很牛逼的黑客, 如果能把所有node节点的数据都修改了. 但数据会校验失败.
节点就会发现数据错误,存在问题.
数据的更新靠smart contract链码, 链码描述了transaction操作是否可以执行.
code is law. 链码执行可以指定背书策略, 某个机构可以执行什么策略.
smart contract可以用java或者nodejs,go语言去编写, 任何负责的业务逻辑都可以用编程语言去描述.
hyperledger inforce trust between partys. 所有人都确信他们的数据是正确的, 没有被篡改的数据.
这就是hyperledger. 一个商业级别 能解决社会问题的, 区块链框架.
hyperledger 解决了人与人,机构与机构之间的信任问题, 通过chaincode 实现价值转移.
授权网络和MSP和CA
business ineract with known entities
以太坊属于匿名网络. hpyerledger是实名制的网络
每个operation在hyperledger网络 必须拥有数字签名. update, 查询, insert, 或者获取metadata. 都需要数字签名.数字签名遵循x.509标准. fabric ca是一个高质量的工具, 帮助我们自动生成证书.
ca可以为不同的用户生成不同的证书, 每个用户可以拥有不同的attribute(属性), 在属性里面可以添加角色,账户id,account number等等.
你可以添加任意的信息.
hyperledger fabric 的chaincode可以获取用户的证书, 根据证书的类型决定某个智能合约是否可以执行.
比如说只有管理员可以安装链码, 普通用户只能查询.
fabric ca就是生成ca和创建账户的工具. 可以根据自己的安全策略来管理用户.
这个证书有效期是多久,分发策略是什么,都可以通过fabric ca来控制.
fabirc ca支持链式继承, 假如某个证书被黑客攻陷, 上一级别的ca可以很容易作废这个证书.
通过ca认证, 我们可以查询每一笔交易的参与者,并且参与者无法抵赖. 这个特性是密码学保证的
hyperledger的组件是可插拔的, 你完全可以不实用fabric ca,
你可以自己建立一套认证体系,用于管理用户.
设置用户属性,签名transaction.
但是fabric ca是一个非常高质量,企业级的组件, 推荐大家使用.
MSP只是一个接口,Fabric-CA是MSP接口的一种实现。
MSP是Membership Service Provider - 是可插拔的接口,它用于支持各种认证体系结构,为membership orchestration architecture提供抽象层。 MSP抽象提供:
具体的身份格式
用户证书验证
用户证书撤销
签名生成和验证
而 Fabric-CA 用于生成证书和密钥,以真正的初始化MSP。 Fabric-CA是用于身份管理的MSP接口的默认实现。
msp 定义
who you are 你是谁
which network you are 你在什么网络
msp的证书是由fabric ca来颁发的
每个peer都需要msp的证书
每个order都需要msp的证书.
现在需要明确的概念是, 只有拥有相同msp的 peer才可以互相发现 互相通讯
MSP ID 是一个名字定义一组证书,说明你是谁你在哪个网络.
使用hyperledger fabirc sdk的时候 经常需要指定mspid
所以这个概念要注意.
Node和peer,client,orderer
node是区块链的通讯终端
在以太坊中所有的node都是相同的
但是在hyperledger中node分为三种
- client 实例化transaction的(cli , node sdk, java sdk)
- peer 用来存储和同步ledger的数据
- orderer 用来排序分发transaction的
一个peer是ledger和blockchain存储的位置,
是blockchain 的ledger存储的位置, 在生产环境中有多个peer,
peer决定是否update的ledger. 一个peer会属于不同的channel.
每个channel都在peer里面,但是是完全隔离的.
一个peer可以控制多个channel
peer背书ledger的更新,最后强调一下peer是ledger和blockchain存储的位置,
peer互相发现,互相同步
order提供排序服务. 在数据被提交到ledger之前, 必须先交给order服务,
order服务创建block区块, 这些区块被签名和验证, 所有的transaction都在block里面
order做好了block之后,把数据发给peer, peer接收到block之后就把数据写入自己的ledger里面.
在hyperledger区块链中,挖矿的工作,共识的达成是有orderer节点来完成的,orderer负责避免双花,生成区块.
Hyperledger项目实战--场景分析
省区块链渔政管理系统
在内水、近海从事捕捞业的单位和个人,必须按照捕捞许可证关于作业类型、场所、时限和渔具数量的规定进行作业。不得在禁渔区和禁渔期进行捕捞,不得使用禁用的渔具、捕捞方法和小于规定的最小网目尺寸的网具进行捕捞。急功近利,竭泽而渔,非法捕捞水产品,破坏国家对水产资源的管理制度,危害水产资源的存留和发展。因此,必须依法对非法捕捞水产品的犯罪予以惩罚。
“仅仅抓非法捕捞,治标不治本。只有立足源头,从非法捕捞、收购、贩卖的每一个环节实施‘全链条’打击,才能从根本上遏制非法捕捞犯罪行为,保护资源环境。”
我们的目标是使用hyperledger 消除非法、未报告和无管制的捕捞活动。
我们将使用一个真实世界的例子, 通过hyperledger区块链 实现一个透明清晰的管理 :渔业供应链。
我们将描述如何改进渔业领域的各个过程, 从源头,王大壮捕小黄鱼,到她的小黄鱼在餐厅B结束的过程。
在这段时间里,我们将有其他相关方参与,比如监管机构核实数据的有效性和小黄鱼 捕获量的可持续性。
我们将使用hyperledger fabric的框架来跟踪这个过程的每一部分。现在,有两个问题你需要注意和思考:
1。网络中 众多的参与者,是如何交互的,以及如何进行事务的。
2。王大壮卖给餐馆A和餐馆B的小黄鱼的价格不同,如何在保持所有数据在网络中同步备份, 监管机构和餐馆可以确认装运小黄鱼是可持续和合法来源,但又不需要暴露全部的细节。
让王大壮和餐馆老板之间能保持足够的隐私, 这都是我们需要设计和关心的问题
hyperledger的channel
每个channel可以理解成独立的hyperledger fabric的实例
channel是hyperledger fabirc里面一个非常重要的概念, 在其他的区块链系统里面是没有channel的概念的
每个channel可以理解成独立的hyperledger fabric的实例, 所有的channel是完全独立的.
一个channel不会依赖于其他的channel,不同的channel之间是不会交换数据的.
不同的channel会有不同的规则,策略,智能合约,他们是完全独立的.
channel 可以理解成private subnet, 有点类似微信的群.
http://hyperledger-fabric.readthedocs.io/en/release-1.1/fabric_model.html#privacy-through-channels
http://hyperledger-fabric.readthedocs.io/en/release-1.1/channels.html
http://hyperledger-fabric.readthedocs.io/en/release-1.1/channel_update_tutorial.html
举个例子: 3个parties 渔民王大壮 ,餐馆A, 餐馆B, 他们都有一些流程
如果他们在同一个channel, 可以看到全部的数据, 执行chaincode,
但是现实情况, 王大壮卖给餐馆A的小黄鱼价格,是私有数据不想让餐馆B看到.
通过王大壮和餐馆A创建一个channel, 餐馆B就看不到他们的数据.
餐馆B甚至都无法知道 A和c之间有channel的存在
channel控制了谁可以看到数据,谁可以操作数据. 当然王大壮创建的channel,渔业主管部门可以加入进来,对交易进行审计.
你创建hpyerledger fabric网络的时候, 一定需要创建了一些peer,
peers 默认什么事情都不做, peer要加入到channel, 才能有blockchain, update ledger.
peer创建后 要加入到对应的channel. 创建和加入channel的操作很简单,sdk里面有工具叫configtx. 我们实操课会详细讲解.
新的peer加入,必须得到当前channel里面的peer的批准.
跟qq群一样. 很容易理解. 不是说某个peer一看, 哇,这有一个channel我去加入进去. 不是随便可以加入的.要满足加入的策略才行.
举个例子: a和B之间有一个channel, 现在c想加入进去, 只要a和b都同意,通过工具更新channel的配置文件后, c就可以加入进去了.
同理, 我们也可以把某个peer从channel里面移除出去. 这就是channel , 道理很简单,功能却很强大.
最后再说一下一些技术上的细节,这些细节在我们实际操作的时候会验证, 某个peer在加入一个channel的时候,
首先这个channel要是存在的,使用的工具叫configtx. 在创建channel的时候一般都要指定,允许哪些人,哪些peer加入到channel里面 修改channel配置,需要使用configtxlator工具
一个peer可能加入多个channel
一个channel 可能有多个peer
不同的channel是独立的,数据不会混淆
什么是chaincode
chaincode 就是智能合约 是应用程序, 是代码 是你的business logic, 他的作用是用来更新账本数据的.
sdk发起一个transaction, peer执行这个chaincode
chaincode可以用nodejs java和go编写, 在hyperledger里面,只要想读取和更新数据就必须通过chaincode的来完成
https://www.npmjs.com/package/fabric-shim
chaincode必须属于某个channel
因为ledger是属于某个channel的
chaincode操作的是ledger
当你执行一个操作的时候,你需要出示你的权限(ca), 明确在哪个channel, 执行哪个chaincode, 执行chaincode的什么函数, 函数的参数是什么.
在一个channel里面可以定义一个chaincode,也可以定义多个chaincode, 看你们公司的业务逻辑.
chaincode需要在某个channel的 每个peer上安装
如果某个channel里面有3个peer , 你只在2个peer上安装chaincode, 最后会导致第三个peer的数据和其他peer的数据不一致.
那第三个peer就会变成一个无效节点,无法搭乘共识,无法获取数据.
Chaincode的生命周期
chaincode需要先安装, 然后必须要实例化, 实例化chaincode会启动docker容器. 在这个容器里面运行chaincode.
- 安装 install
- 实例化 init
- 调用 invoke
chaincode的背书策略
http://hyperledger-fabric.readthedocs.io/en/release-1.1/endorsement-policies.html
实例化chaincode需要指定背书策略. 背书策略是hpyerledger中一个很强大的功能.
是所有的peer都要验证,还是大多数peer同意, 还是至少一个peer同意, 通过and或者or 这样的关键字定义背书策略.
假设你的业务有10个不同的chaincode, 就可以有10个不同的背书策略. 有的代码要所有的节点同意才可以执行,
有的逻辑需要至少有一个节点同意就可以执行. 这样就非常非常的灵活.
chaincode总结
- 每个peer可以属于多个channel
- 每个channel有独立的ledger
- 每个channel可以有一个或者多个的chaincode
- 每个chaincode可以有不同的背书策略
这种可扩展,灵活的设计,让hyperledger可以适用于任何业务场景.
hyperledger的工作流程
这一讲,我们讲解一下hyperledger的工作流程, 背书和模拟执行.
这个图第一眼看起来有点复杂,但是我解释完毕后, 你一定会觉得非常容易理解, 并且整个过程非常具有逻辑性.
这实际上是最精简的一个案例, 一个组织, 3个peer节点, 在同一个网络, 同一个channel上.
sdk , nodejs java go , 命令行cli, 什么sdk都行.
你现在要执行一个更新账本的操作, 例如要修改捕捞出来的小黄鱼的归属者.
这个更新叫 transaction proposal , 一个修改账本的提案, 我想修改peer节点记录的小黄鱼的归属者.
peer 先接收到 proposal, 会模拟执行. 模拟执行. 拿着当前的versoion的ledger去模拟执行. 例如1.0版本账单 小黄鱼归王大壮
要注意的是每一个peer都有一个ledger(账本)的拷贝. 每个peer都有一份拷贝.这个数据在peer节点的硬盘里面存放着.
模拟执行会产生一个读写集(read write set),具体读写集的内容为, 某个key要被update成什么, update后的version是什么
2.0版本小黄鱼归xxx. 这个模拟操作是由一个或者多个peer都会模拟执行的.
每个peer会把模拟执行的结果 endorsement response 签名, 最后返回发送给sdk
sdk收集所有的背书响应. invocation request,发送给orderer节点
order检查签名,背书策略,排序, 如果没有问题,就发送invocation.
背书策略非常重要,不同的链码可能对应不同的背书策略, 举个例子,假如背书策略是所有的节点都要同意.
就需要检查是否有每个节点的背书, 如果背书策略是只要有一个同意, 那么只需要收集到一个背书即可.
不合法的invocation request会被拒绝, 不会更新ledger的状态,(世界状态,读写集)
但是transaction会被记录到blockchain. 方便以后排查检查问题. 专业术语叫审计. 方便以后审计.
ordering service还需要检查所有的背书对应的读写集是否一样, 只有一样的才会被接受.
我们想一下, 正常情况下所有的peer都保存了同一份账本的拷贝,执行相同的chaincode智能合约, 那么他们最终执行出来的结果也应该是一致的
如果数据不一致, 那么orderer节点就有理由认为,某个peer节点数据没有同步,或者peer节点被非法篡改. 我不能更新ledger的数据,
我要把这次情况记录到blockchain.
如果数据一致, 那orderer服务就会发起invoke更新请求, 所有的节点都收到请求,更新自己的ledger状态.
所有的peer数据还是保持一致的. 因为他们原始数据一致, 又都更新了相同的读写集.
另外orderer节点还担当了排序的角色, 因为在同一时刻,可能有来自于sdk的两个更新ledger的提案请求.
先后顺序一定要排好.举个例子, 第一个proposal是张三花10块钱买大米, 在这完全的同一时刻,
张三花10块钱买玉米的proposal也发了出来, 但是张三只有10块钱,
orderer节点排序后, 第一个买大米的操作是合法的, 但是第二个买玉米的操作就不合法了.
因为张三没有这么多钱了. 这也是hyperledger如何解决双花问题.
在生产环境中, 一般会有多个组织, 多个组织之间的orderer节点 互相同步.
如果几个节点数据不同步, 就不会更新数据, 保证了order节点不会被攻破.
黑客要同时攻击两个或者多个order是非常困难的.
这是一个非常非常强的安全模型.
理解了上面的流程, 你就能回答很多用sdk开发的时候疑惑的问题.
为什么我要用sdk发送提案,接收一些返回数据.
为什么我要验证一些认证相关的信息.
为什么读写集的修改这么复杂
为什么orderer服务 排序的结果 跟我期待的不一样
这些问题, 遇到了大家一定要多想想流程 自己思考.
好了,最后再回顾一下流程:
- sdk发送transaction proposal给一个或者多个peer
- peer模拟执行, 给出模拟执行的结果,读写集,key的version, 这些信息反馈给sdk
- sdk收集背书信息,带着签名,发给orderer节点
- orderer节点,检查数字签名,检查每个peer背书的读写集是否一致.排序.如果没有问题,就发出invocation 让每个peer去apply新的读写集.
最后强调几个细节:
orderer节点不是立刻处理每个invocation request.
在orderer节点内部有一个消息队列 , 我们可以控制这个队列,控制队列的数量,容量大小,提交周期等参数
通过调整参数调整hyperledger的处理效率.这些是hyperledger开发中比较高级的话题,
关于性能调优, 后面我们会详细讨论.
术语回顾
channel
数据通道, 可以理解成独立的hyperledger fabric的实例
不同Channel的数据彼此完全隔离
Channel可以保证区块链上数据的隐私问题
Channel类似微信群组
ChainCode
链码
智能合约
Chaincode定义了business logic
Ledger的变化只能通过调用chaincode来完成
在区块链系统里面code is law
ledger
账本
Ledger记录的是当前的世界状态(world state)
Ledger还链式记录了所有的历史世界状态
在hyperledger里面,ledger是一个具有授权管理的共享账本系统
从底层设计上保证数据的一致性,有效性,不可篡改性
network
由peer组成network
在同一network的peer,实时同步记账,保证ledger数据的一致性
ordering service
排序服务
排序,验证transaction, 最终提交invocation,把数据写入peer的ledger
world state
世界状态
当前ledger里面存放的数据
Key和value 以version形式存在
当前实现有couchdb和leveldb
membership service provider
管理peer的身份和访问许可
业务分析
渔民王大壮
靠打渔,卖鱼为生
需要加入到区块链网络,把鱼卖给餐馆
渔政监管部门也需要加入区块链网络,监管打渔的合法性
王大壮把捕鱼的数据加入到区块链网络,餐馆和渔政部门均可访问审计数据
数据
每次捕获后,王大壮需要记录捕捞的信息
包括
唯一的ID号
捕获的位置
捕获的时间
捕捞重量
捕鱼船信息
捕捞人信息
为了简单起见,我们只设计这六个数据属性。然而,在实际应用中,更多的细节需要被记录下来。气温, 捕捞深度, 作业设备类型,渔网大小,捕捞区域水源水质分析, 等等..
数据定义
由于ledger的世界状态是key/value的形式存在
所以数据适合采用json方式表示
应用程序的开发适合采用nodejs开发
var caught = { id: '0001', holder: '王大壮', location: { latitude: '41.40238', longitude: '22.17032' }, when: '201804161323', weight: '58kg', vessel: '奋进号38A'};
消费者
餐馆A
餐馆B
消费者痛点分析
餐馆希望能买到低价格,优质的小黄鱼
餐馆不希望买到非法捕捞的小黄鱼(避免严厉的监管处罚)
餐馆不确定市场上的小黄鱼是否合法,是否新鲜
王大壮希望把自己合法捕捞的小黄鱼,以合适的价格销售出去
监管部门需要了解小黄鱼的捕捞量和销售数量
信任问题
餐馆不信任王大壮
监管部门不信任 餐馆
监管部门不信任 王大壮
王大壮的隐私问题
隐私业务分析
价格是任何商业模型里面非常重要的一环. 是非常非常敏感的隐私. 餐馆A有可能是王大壮的新客户, 王大壮的营销策略是, 打算用较低的价格赢得新客户, 一旦客户稳定后再去涨价.
但这个优惠的价格是不应该被餐馆B的老板看到的.
在传统的公有区块链里面,一旦王大壮和餐馆A完成了交易,整个网络可以查看此协议的细节,18.5元一斤的小黄鱼所有的节点都可以看到。
你可以想象,餐馆B老板看到这个价格后的心情. 一定会有 一万只草泥马在辽阔的草原上奔跑.
渔政监管需求分析
“仅仅抓非法捕捞,治标不治本。只有立足源头,从非法捕捞、收购、贩卖的每一个环节实施‘全链条’打击,才能从根本上遏制非法捕捞犯罪行为,保护资源环境。”
监管部门需要具有权限,可以验证查看区块链ledger的每一条记录
监管部门应该只具有查询ledger的权限.
监管部门通过查询捕鱼的重量和位置来确定渔民是否合法捕捞
监管部门应该具有从blockchain网络中添加或者删除渔民的权限
如果王大壮的捕捞是非法的, 超过许可的. 监管部门可以把王大壮从hpyerledger fabirc区块链网络里面移除, 那么王大壮就失去了卖鱼的权利
业务复盘
渔民王大壮,捕获小黄鱼,使用hyperledger fabirc的sdk接口调用chaincode把捕鱼数据写入区块链网络 .
整个过程是,首先sdk发出transaction申请, 每个peer节点模拟执行,把背书结果反馈给sdk, sdk收集到足够的背书后,把请求发给ordering节点, ordering节点排序后,把数据生成block.
Block广播给每个peer节点,每个节点验证后, 最后更新自己ledger的数据.
监管部门在小黄鱼的供应链里面, 每笔交易都被记录, 监管部门可以查询交易的细节,但是监管部门无权查询交易的价格. 因为监管部门不在具体交易的channel里面.
渔民王大壮分别和餐馆A 餐馆B约定了不同的价格, 交易在不同的channel里面, 紫色区块链里面的交易价格为18.5元/斤 红色区块链里面的价格为28.5元/斤
不同channel彼此隔离,充分保证了交易双方的隐私