标签：11 背书 Fabric -- member 签名 peer 链码 策略

一、链码

1. 链码

Go或nodejs编写的程序。

通过应用程序提交的事务初始化和维护状态数据库。

不同链码维护的状态数据库不同，不能修改其他链码的状态数据库，但可以通过其他链码读取其状态数据库。 

 

2. 生命周期

• 包装（ packaging ）、
• 安装（ installing ）、
• 实例化（ instantiating ）
• 升级（ upgrading ）

 

3. 组成

链码由三部分组成

（1）代码

 

（2）背书策略

背书策略用于Peer决定事务是否被正确地背书。
 

（3）签名

• 为确立链码的所有权，

• 检测包的内容是否篡改

• 检测包的封装是否篡改。

 

 

 

二、背书策略

1. 背书策略

背书策略用于Peer决定事务是否被正确地背书。

当对Peer接收到事务时，它将调用与事务链码相关联的VSCC(验证系统链码)作为事务验证的一部分，以确定事务的有效性。

• § 正确的证书
• § 正确的数量
• § 正确的来源

 

 

2. MSP

MSP能验证签名者的身份和角色，支持 四种角色

• member，
• admin，
• client，
• peer

 

3. AND ('Org1.peer', 'Org2. peer', 'Org3. peer')

三个组织分别需要至少一个peer签名

 

4. OR ('Org1.peer', 'Org2.peer')

需要两个组织中的一个peer的签名

 

5. OR (‘Org1.member’, AND(‘Org2.member’, ‘Org3.member’))

分别需要org2和org3的 member签名或者org1和member签名

 

6. 如果不指定链码背书策略

【不推荐】，那么链码的默认背书策略就是得到通道中任意一 个节点签名

 

7. 如果有新加入的节点

新加入通道的peer如果想调用已经实例化的链码的Invoke，各节点必须重新安装链码，重新实例化一遍，必须更新背书策略

 

 

 

标签：11,背书,Fabric,--,member,签名,peer,链码,策略
来源： https://blog.51cto.com/u_15077160/2914459

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。