fisco和fabric权限管理的区别
- 一、FISCO BCOS 权限管理
- 引言
- 如何使用角色权限？
- 总结
- 二、Fabric 权限管理
- 三、二者比较
- 参考文章
一、FISCO BCOS 权限管理
引言
FISCO BCOS的权限控制是通过控制账号对系统中表的写权限来实现的。这种权限控制模型非常灵活且强大，用户几乎可以控制任意一项权限，例如，通过控制权限表的写权限管理分配权限；通过控制系统合约所对应表的写权限管理链配置、节点身份管理、合约部署、用户表创建等；通过控制合约表的写权限管理合约写接口的调用。
然而，绝对完美是不存在的。强大灵活的权限控制也带来较高的学习成本：用户需要理解每个权限项控制的内容以及如何设置，了解链管理员和系统管理员的区别……大量的概念和操作，对用户要求极高。
为了降低使用难度，提升用户体验，FISCO BCOS v2.5对此功能进行了优化，新增了基于角色的权限控制。把不同的权限统归到不同角色，用户根据账号所属角色即可判断其所拥有的权限。同时v2.5基于角色引入了链上治理投票模型，使治理操作更加方便。
什么是角色权限模型？
使用角色权限模型后，用户只需记住角色，而角色对应的权限不言自明，例如，治理委员会委员拥有链治理相关权限，这极大降低用户理解难度与学习成本。
角色对应的权限
区块链上的参与者，可根据角色分为治理方、运维方、监管方和业务方。为避免既当裁判又当运动员，治理方、运维方应权责分离，角色互斥。
治理方：角色称为治理委员会委员，简称委员，负责区块链治理。
运维方：负责区块链运维，该角色由委员添加。
业务方：业务方账号由运维添加到某个合约，可以调用该合约的写接口。
监管方：监管方监管链的运行，能够获取链运行中权限变更记录以及需要审计的数据。
各角色所对应权限具体如下表所示。
角色权限实现的细节
本小节将简单介绍委员、运维和业务角色的权限实现细节以及背后原理，以便更好理解与使用角色权限功能。
链初始无委员账号，当存在至少一个委员账号时，委员拥有的权限开始受到控制。联盟链实际应用中多个参与方的技术实力可能并不相同，从实际应用场景出发，我们引入了链上治理投票模型，所有治理操作需要有效投票数/委员数>生效阈值才能生效，用户通过新增的链治理预编译合约可以实现委员的增删、权重修改、投票生效阈值修改等操作。
投票模型有几处值得注意：
- 每次投票操作，如果是委员投票，则记录操作内容和投票委员，不重复计票
- 每次投票操作，计票结束后，计算有效投票数/委员数，如果大于此操作的生效阈值，则对应操作生效
- 投票设置过期时间，根据块高，blockLimit的10倍，固定不可改
运维角色的新增与撤销必须由委员角色操作。链初始无运维账号，当存在至少一个运维账号时，运维拥有的权限开始受到控制。
业务账号可以调用链上查询接口与运维指定合约的写接口。
兼容性说明
目前，角色权限模型基于对系统中各类表的写权限控制。我们做了最大努力与之前版本使用体验保持一致，但为了权限控制的完整严谨，对FISCO BCOS v2.5新建链，控制台grantPermissionManager指令不再有效，原PermissionManager的权限归属于委员角色。对于v2.5之前的链，该指令仍然有效。
如何使用角色权限？
本节将以“委员增删”和“运维增删”为例进行简要的实操演示，文档含括了更丰富的角色权限相关操作，欢迎移步查看。
增删委员
使用控制台v1.0.10以上版本中自带的get_account.sh脚本，生成3个如下账号，接下来的操作以这3个账号为例演示。配置好控制台后，使用控制台的-pem选项分别加载3个私钥启动3个控制台。
# 账号1
0x61d88abf7ce4a7f8479cff9cc1422bef2dac9b9a.pem
# 账号2
0x85961172229aec21694d742a5bd577bedffcfec3.pem
# 账号3
0x0b6f526d797425540ea70becd7adac7d50f4a7c0.pem
添加账号1为委员
增加委员需要链治理委员会投票，有效票大于阈值才可生效。此处由于只有账号1是委员，所以账号1投票即可生效。
使用账号1添加账号2为委员
此处由于只有账号1是委员，所以使用账号1投票后，满足阈值判断立刻生效。
撤销账号2的委员权限
此时系统中有账号1和账号2两个委员，默认投票生效阈值50%，所以需要两个委员都投票撤销账号2的委员权限，有效票/总票数=2/2=1>0.5才满足条件。
账号1投票撤销账号2的委员权限，如下图：
账号2操作投票撤销账号2的委员权限，如下图：
增删运维
委员可以添加与撤销运维角色，运维角色的权限包括部署合约、创建表、冻结解冻所部署的合约、使用CNS服务等。
使用账号1添加账号3为运维
使用账号3部署HelloWorld
账号3是运维角色，可以部署合约，具体操作如下图：
使用账号1部署HelloWorld
账号1是委员，不具有部署合约的权限，部署合约失败，如下图：
使用账号1撤销账号3的运维权限
账号1是委员可以撤销运维，如下图：
总结
作为联盟链的重要特性，权限控制需要做到灵活且强大，但如何在此基础上达成良好的用户体验，需要不断地改进优化。
FISCO BCOS v2.5前的权限控制实现了灵活且强大的功能，但同时，社区也收到不少反馈，认为权限控制的使用理解门槛过高。通过角色权限，我们希望能在保持原有功能的同时，降低学习门槛、提升大家的使用体验。整合优化权限控制的工作仍在进行，希望未来能实现从底层到应用全覆盖的权限控制解决方案。
二、Fabric 权限管理
1.Fabric 权限管理基于身份管理
2.Fabric 身份管理基于PKI体系
3.Fabric 成员身份基于标准的X.509证书
4.Fabric 中CA提供成员服务管理
Fabric MSP(成员管理服务提供商)
Fabric提出了MSP(Membership Service Provide)的概念，MSP(成员管理服务提供商) ，MSP是一个提供虚拟成员操作的管理框架的组件，MSP抽取出签发和验证证书以及用户认证背后的所有加密机制和协议。 MSP可以定义自己的身份概念，以及这些身份管理的规则（身份验证）和身份验证（签名生成和验证），一个Fabric网络能够被一个或更多的MSP控制。这提供了会员操作的模块化，以及跨不同会员标准和体系结构的互操作性。
1.MSP抽象各成员之间的控制结构关系
2.MSP将证书颁发、用户认证、后台加密和协议抽象化
3.一个Fabric网络可以有多个MSP
4.实现Fabric网络操作、规则和流程模块化
5.一般情况下建议一个组织对应一个MSP，当然技术上也支持一个组织对应多个MSP，多个组织对应一个MSP
Ca：根ca证书和秘钥
Msp：msp的配置
Orderers or Peers：orderers的配置或者peers的配置
Tlsca：TLS的中间CA证书和秘钥
Users：用户配置，默认有1个管理员和1个普通用户
Fabric CA
Fabric CA提供如下功能：
1.用户信息注册
2.数字证书发行
3.数字证书延期和吊销
FabricCA 证书信任链
由根CA和中间CA 到最终用户组成一个证书信任链
Fabric MSP实现权限管理
前面讲到Gossip协议只在1个组织内部进行数据同步和分发，更准确的说应该是Gossip协议只在1个MSP内部进行数据同步和分发，所以我们在设计网络时，需要考虑组织和MSP的对应关系
（1）1个组织对应1个MSP，方便管理，数据只在组织内部同步，一定程度保护了隐私
（2）1个组织对应多个MSP，这种情况一般是组织内部存在多个部门，为了实现管理方便和隐私保护，为每个部门单独设置一个MSP，这样组织内部的部门之间不会同步数据，同时可以实现基于部门的交易背书策略和通道管理策略
（3）多个组织对应1个MSP，一般在同一个联盟的不同组织之间需要实现数据的同步
三、二者比较
（1）节点管理
对于BCOS，节点主要分为两类：共识节点和普通节点。共识节点负责共识出块，普通节点只能同步数据并验证数据而没有打包交易的权力。
对于Fabric，节点分为背书节点，排序节点，提交节点。背书节点负责执行交易并返回结果，排序节点负责对交易排序并打包出块，提交节点负责验证交易并更新状态。
对于共识节点BCOS采用了系统合约的方式进行管理，节点的增删需要共识节点进行共识。而Fabric的节点增删，可以由节点管理员修改配置，无需共识，但是激活新的配置文件需要发送交易并进行共识。
（2）用户权限管理
对于联盟链来将，联盟各个角色以及联盟内均需要比较复杂的权限管理，这样不同的角色只能访问属于自己授权的资源。
在BCOS中通过复杂的权限管理，来对用户的交易权限进行管理，包括发送交易，创建合约，合约方法调用权限等等。
Fabric通过配置文件的方式(Policy）的方式进行管理用户的权限。
BCOS权限管理通过交易的方式进行管理，比Fabric通过配置文件的方式修改，更加区块链化，治理操作会保留痕迹。
参考文章
FISCO BCOS 角色权限模型的实现区块链hyperledger-fabric之 权限管理
开源架构Fabric、FISCO BCOS（以下简称“BCOS”）、CITA 技术对比