Currently when Quorum geth is brought up in `--permissioned` mode, for establishing p2p connectivity the nodes check `permissioned-nodes.json` file. If the enode id of the node requesting connection is present in this file, the p2p connection is established else it is declined. The `permissioned-nodes.json` file is updated procedurally whenever a new node joins the network. Node permissioning feature will allow the existing nodes to propose a new node to join the network and once majority voting is done on the proposal, it will update the `permissioned-nodes.json` automatically. Further the existing nodes can propose any node for deactivation, blacklisting and activating a node back from a deactivated status.
Account permissioning feature introduces controls at account level. This will control the type of activities that a particular account can perform in the network.
It should be noted that both the above features will be available when Quorum geth is brought in `--permissioned` mode with the set up as described in the next section.
Node permissioning and account access control is managed by a smart contract [Permission.sol](../controls/permission/Permission.sol). The precompiled bytecode of the smart contract is deployed at address `0x000000000000000000020` in network bootup process. The binding of the precompiled byte code with the address is in `genesis.json`. The initial set of account that will have full access when the network is up, should given as a part of `genesis.json` as shown below:
In the above set up, accounts `"0xcA843569e3427144cEad5e4d5999a3D0cCF92B8e", "0xed9d02e382b34818e88b88a309c7fe71e65f419d", "0x0fbdc686b912d7722dc86510934589e0aaf3b55a"` will have full access when the network boot is completed. The default access for any other account in the network will be `ReadOnly`
If the network is brought up with permissions control byte code and no accounts are given as a part of storage, then geth start up will fail with error `Permissioned network being brought up with zero accounts having full access. Add permissioned full access accounts in genesis.json and bring up the network`
Further, if the initial set of network nodes are brought up with `--permissioned` mode and a new approved node is joining the network without `--permissioned` flag in the `geth` start commmand, system will not allow the new `geth` node to come and a fatal error `Joining a permissioned network in non-permissioned mode. Bring up geth with --permissioned."` will be thrown.
* Deactivated - The node has been deactivated from the network. Any node in this status will be disconnected from the network and block sync with this node will not happen
* PendingActivation - A deactivated node has been proposed for activation and is pending majority approval. Once approved the node will move to `Approved` status
* PendingBlacklisting - The node has been proposed for blacklisting and is pending majority approval
* Blacklisted - The node has been blacklisted. If the node was an active node on the network, the node will be disconnected from the network and block sync will stop
It should be noted that deactivation is temporary in nature and hence the node can join back the network at a later point in time. However blacklisting is permanent in nature. A blacklisted node will never be able to join back the network. Further blacklisting can be proposed for a node which is in the network or a new node which is currently not part of the network.
When the network is started for the first time, all the nodes present in `static-nodes.json` file are added to the permissioned nodes list maintained in the smart contract. Once the initila network is up, these nodes can then propose and approve new nodes to join the network.
Before a new node can be proposed to the network, the network should have valid voters. This api allows an account to be added as voter to the network. Only an account with `FullAccess` can perform this activity.
* Input: Account to be added as voter, transaction object
API for proposing a activating a deactivated node for deactivation. The node must be `Approved` state and there should be at least one voter account present at network.
* Input: enode to be deavtivated, transaction object
* To propose activation of a deactivated node `quorumNodeMgmt.proposeNodeActivation` can be used. The same can be approved using `quorumNodeMgmt.approveNodeActivation` api.
* To propose a node for blacklisting `quorumNodeMgmt.proposeNodeBlacklisting` can be used. Node blacklisting can be approved using the api `quorumNodeMgmt.approveNodeBlacklisting`
The following account access types are being introduced as a part of this feature:
* ReadOnly: Accounts with this access will be able to perform only read activities and will not be able to deploy contracts or transactions. By default any account which is not permissioned will have a read only access.
Further while setting the account access, system checks if the account which is setting the access has sufficient privileges to perform the activity. For example a read only account cannot grant full access accounyt access to another account. The allowed access set ups are as below:
* Accounts with `FullAccess` can grant any access type ( FullAccess, Transact, ContractDeploy or ReadOnly) to any other account
* Accounts with `ContractDeploy` can grant only `Transact`, `ContractDeploy` or `ReadOnly` access to other accounts
* Accounts with `Transact` access grant only `Transact` or `ReadOnly` access to other accounts
* Accounts with `ReadOnly` access cannot grant any access
If an account having lower privileges tries to assign a higher privilege to an account, system will not allow the operation and will throw the an error as shown below: