LACChain’s permissioning protocols
We define the permissioning protocol of a blockchain network as the process to determine whether a new node is accepted in the network or not.
The LACChain DLT networks will have two different protocols for permissioning new nodes. The first one is named Satellite Permissioning Protocol (SPP) and applies for any new node. The second one is named Core Permissioning Protocol (CPP) and applies only for core nodes. If you are not familiar with our taxonomy, you can read about our core and satellite nodes HERE.
All the permissioning rules will be automatized using smart contracts.
Satellite Permissioning Protocol (SPP)
The Satellite Permissioning Protocol will be executed by the Satellite Permissioning Committee (SPC). The SPC will be composed by natural or legal persons designated by the LACChain Board. The SPC will have a coordinator, designated by the LACChain Board, that will be responsible for calling the SPC meetings. These persons will be digitally identified in the network via DIDs an verifiable credentials issued by the LACChain Board. The SPC will manage the permissioning via an app that will be developed. Every time a new node of any kind asks for permission to join network, the SPP consisting of the following steps applies:
1. A smart contract notifies the members of the SPC via the application.
2. The members of the SPC have seven (7) days to decide about the request. They can either accept, deny or abstain. In case of denial or abstention, the member of the SPC can send a message to the rest of the SPC along with the vote exposing the reasons why.
3. If after the seven (7) days there are two thirds plus one (2/3 + 1) votes in favor and no votes against, the new node gets the approval of the SPC. Automatically, the smart contract connects it to the gear nodes in order to get set up with the network. If a DID was not provided in the request, a new DID is generated. In both cases, a verifiable credential signed by the SPC is generated for the DID certifying the node and its owner.
4. If after the seven (7) days either there are not two thirds plus one (2/3 + 1) votes in favor or there are votes against, the node is not permissioned. If this is the case, the node will have to wait until the next SPC meeting where the SPC will discuss the admission. If after the discussion the consensus remains unreached, the SPC coordinator will contact the person representing the request to communicate the decision and assist them on the request improvement. This step is iterated until the consensus described in step 3 is reached.
5. If the request was for a satellite node, the process ends here. If the request was for a core node, now the CPP begins.
Once a satellite node is a member of the network, the SPC will have the possibility to remove the permission by recalling the certificate issued.
Core Permissioning Protocol (CPP)
The Core Permissioning Protocol will be executed by the Core Permissioning Committee (CPC). The CPC will be composed by the natural persons representing the validator and gear nodes. The CPC will have a coordinator, designated by the CPC, that will be responsible for calling the CPC meetings. These persons will be digitally identified in the network via DIDs an verifiable credentials issued by the LACChain Board. The CPC will manage the permissioning via an app that will be developed. Every time a new core node asks for permission to join the network, the CPP starts automatically right after the SPP ends. The CPP consists of the following steps:
1. A smart contract notifies the members of the CPC via the application.
2. The members of the SPC have seven (7) days to decide about the request. The can either accept, deny or abstain. In case of denial or abstention, the member of the CPC can send a message to the rest of the CPC along with the vote exposing the reasons why.
3. If after the seven (7) days there are two thirds plus one (2/3 + 1) votes in favor and no votes against, the new node gets the approval of the CPC. A verifiable credential signed by the CPC is generated for the DID certifying the node and its owner, and the node begins to participate in the corresponding core node’s processes.
4. If after the seven (7) days either there are not two thirds plus one (2/3 + 1) votes in favor or there are votes against, the node is not permissioned. If this is the case, the node will have to wait until the next CPC meeting where the CPC will discuss the admission. If after the discussion the consensus remains unreached, the CPC coordinator will contact the person representing the request to communicate the decision and assist them on the request improvement. This step is iterated until reaching the consensus described in step 3.
Once a core node is a member of the network, the CPC will have the possibility to remove the permission by recalling the certificate issued.
Authors: Marcos Allende Lopez
Coordinator: Alejandro Pardo Vegezzi
