在生产环境中,一个最小的织物联盟链网络由4个结点组成,如下图:
为了避免单点故障,进行结构冗余,每个节点的角色安排如下:
·192.168.1.120得,orderer1, zookeeper0, kafka0, ca1,
·192.168.1.121 peer2, orderer2, zookeeper1, kafka1 ca2
·192.168.1.122 peer3, zookeeper2, kafka2, ca3
·192.168.1.122 peer4, kafka3 ca4,织物浏览器
在织物中,本由一个节点处理的过程,在逻辑上被分解为不同的角色,每个角色承担不同的功能,节点(同行)分解为背书节点(背书人同行)和提交节点(提交者同行),为了达到处理的顺序性,提炼出排序(订货方)角色,卡夫卡是联盟链中负责共享机制,动物园管理员是个分布式应用协调器,负责点到点数据传输,CA负责证书发放。织物是应用于联盟链的场景,在处理每一笔交易时,每个环节上需要对交易信息进行权限校验。
,,,,,,织物交易流程图如下所示:
交易过程详细流程:
,,,,1)应用程序客户端通过SDK调用证书服务(CA)服务,进行注册和登记,并获取×××书;
,,,,2)应用程序客户端通过SDK向区块链网络发起一个交易提案(方案),交易提案把带有本次交易要调用的合约标识,合约方法和参数信息以及客户端签名等信息发送给背书(背书人)节点。
,,,,3)背书(背书人)节点收到交易提案(方案)后,验证签名并确定提交者是否有权执行操作,同时根据背书策略模拟执行智能合约,并将结果及其各自的CA证书签名发还给应用程序客户端。
,,,,4)应用程序客户端收到背书(背书人)节点返回的信息后,判断提案结果是否一致,以及是否参照指定的背书策略执行,如果没有足够的背书,则中止处理,否,则应用程序客户端把数据打包到一起组成一个交易并签名,发送给订货人。
,,,,5)开证申请人对接收到的交易进行共识排序,然后按照区块生成策略,将一批交易打包到一起,生成新的区块,发送给提交(提交者)节点;
,,,,6)提交(提交者)节点收到区块后,会对区块中的每笔交易进行校验,检查交易依赖的输入输出是否符合当前区块链的状态,完成后将区块追加到本地的区块链,并修改世界状态。
还有一个关于织物联盟链交易理解的说明:
这个示例中包含客户A和B,在进行萝卜买卖。他们各自有一个网络节点,通过节点他们发送交易并和账本进行交互。
首先,假设必要的条件:
该流程假设通道已建立并正常运行。用户已注册并使用组织认证授权(CA)登记,同时获得必要的加密材料来进行网络验证。
链码(包含一组代表萝卜市场初始状态的键值对)被安装在节点上并在通道上进行实例化。链码包含定义交易指令集合的逻辑和达成一致的萝卜价格。设置一项针对链码的背书策略,表明节点A和B都必须对任何交易进行背书。
1。客户一个发起交易
客户一个发出萝卜购买请求。请求目标节点A和B,分别代表客户A和B背书策略表明两个节点必须为任何交易进行背书,因而请求被发送到节点A和B
接下来构建交易提案。一个以可用SDK(节点、java、python)为支撑的应用利用有效的API来生成交易提案。这项提案作为调用链码功能的请求来完成数据到账本的读取和/或写入(即为资产写入新的键值对).SDK有两个作用:把交易提案包装成合适架构格式的库(基于gRPC的协议缓冲);使用用户的加密证书来创建交易提案的唯一签名。
2。背书节点验证签名,执行交易
背书节点使用MSP验证签名并确定请求者是否被合理授权进行提案的操作(使用通道ACL)。背书节点以交易提案凭证为输入,基于当前状态的数据库执行来生成交易结果,输出包括反馈值,读取集合和写入集合。截止现在账本还未进行更新。这些值的集合,背书节点的签名以及是/否的背书声明一同作为“提案反馈”被传输回到SDK, SDK对应用消耗的载荷进行解析。
