Quorum 的权限管理模型

Quorum 是基于以太坊公链代码改造的一种许可链/联盟链实现。主要在以下三个方面进行了改造和增强：

1. 共识机制，添加对 Raft、IBFT 等确定性共识算法的支持。
2. 隐私，添加对隐私交易的支持。
3. 权限模型，添加了对网络准入和网络资源访问限制的支持。

本文将重点放到权限模型这一块儿。

0x01 权限管理和共识管理的不同

只所以先说这个，是因为经常见到刚接触 Quorum 的同学把这两个东西搞混淆。
Quorum 提供的有类似下面的命令：

istanbul.propose(address, auth)

这是启用 IBFT 共识机制后可用的一个命令，通过这个命令可以发起加入或移除某个节点的提案，如果提案获得过半节点支持，该提案通过，相应的节点就会被加入或移除 IBFT 共识网络。
有加入，有移除，这不就是权限管理了么？错。
Quorun 的权限管理更多是关于网络准入的管理，对网络中资源使用权限的管理。而与共识有关的节点管理，只是确定该节点是否允许参与出块，而对该节点有没有权限访问当前网络，没有任何限制。

换句话说，Quorum 网络中主要有两种，一种的是参与共识进行区块生成和验证的节点，另外一种不参与共识，只是同步数据的节点。所有节点结合到一起形成 Quorum 网络，共识节点结合到一起保证共识算法的正常运行，区块可以正常生成和验证。

0x02 两种权限管理模型

一种是基本的网络权限管理，提供了一种基本的网络访问限制方案，指定哪些节点可以对 Quorum 网络进行访问。
默认情况下，Quorum 网络是没有准入限制的，我们在启动节点的时候加上 “--permissioned” 这个参数标识，就会启动网络权限准入机制，在节点的数据目录种查找 <data-dir>/permissioned-nodes.json 这个文件。这个文件的内容如下：

 [ 
     "enode://remoteky1@ip1:port1",
     "enode://remoteky1@ip2:port2",
     "enode://remoteky1@ip3:port3", 
 ]

这就相当于一个白名单，不在这个名单里的节点，在 p2p 层面就会限制对 Quorum 网络的访问，要参与共识，首先要是白名单里的一员才行。

另外一种是基于智能合的的权限管理，在基本网络准入限制的基础上，基于智能合约添加了 RBAC 权限管理，实现对网络节点、账户、资源更细粒度的控制。

0x03 合约权限管理模型设计

权限模型概念设计

这里涉及到一些概念定义：

Network（网络）：

逻辑上，多个组织形成一个联盟链网络。
物理上，属于不同组织的节点形成 Quorum 网络。
这个网络是如何构成的呢？在网络第一次启动的时候，会从配置文件 permission-config.json 的下面这些配置中读取初始配置：

"nwAdminOrg": "ADMINORG",
"nwAdminRole" : "ADMIN",
"orgAdminRole" : "ORGADMIN",
"accounts":["0xed9d02e382b34818e88b88a309c7fe71e65f419d", "0xca843569e3427144cead5e4d5999a3d0ccf92b8e"],

根据这些初始配置，Quorum 会调用合约创建默认的顶级组织和角色，"nwAdminOrg" 就是组织名，"nwAdminRole" 就是管理员角色名，"accounts" 就是这个顶级组织的管理员账户。

有没有发现还少点儿什么？对了，网络需要节点啊，初始节点在哪里呢？
这就需要用到 static-nodes.json 了，static-nodes.json 配置的节点会作为顶级组织的节点加进来。

Organization（组织）

一个组织可以包含若干个子组织，若干个账户，若干个不同的角色

Sub Organization（子组织）

根据业务需要再一个组织下面创建的下一级组织，子组织还可以创建下一级子组织。

Account（账户）

以太坊外部账户

Voter（投票人）

投票人，为指定提案进行投票。

Role（角色）

Node（节点）