## 5 System Implementation
### Initialization Phase  
On-Boarding of New Node to Enterprise Consortium  
After registering for an account to access the system components and applications of dNAS hosted by the consortium, such as the database-operating web application and both NFC-enabled mobile applications according to its defined system role, the registered node would then be given access to every dNAS system component. In order to become a consortium member, an on-boarding operation is needed to execute with a blockchain node instance assigned, which is hosted by the consortium. As detailed in the use-case analysis, only registered nodes of the winemaker role and supply-chain-participant role will be assigned with a blockchain node, an IPFS node and key pairs, which are shared and restrained to their own key vault service. While registered nodes of the wine-consumer role utilize shared instances of these distributed system components hosted by the consortium, for data processing operations, such as the wine record validation and appending process, wine consumers will consequently need to use the _ScanWINE_ mobile application to validate a bottled wine with the returned wine record, before purchasing the wine product, with updated transaction and supply chain data updated in the dNAS. The suggested protocol for adding the new node to the consortium is described in Figure 11.  
To have a newly registered node added to the consortium, a democratic voting process is performed amongst the current consortium members. It is assumed that such an operation is kicked in after a new node is granted access to dNAS as a registered node, approved by the consortium administrator, and assigned the newly registered node of dNAS with instances of distributed components, including a blockchain node and an IPFS node. With the _URL_ of the blockchain node instance specified, the blockchain service sends querying request to reach to the \"_getPeers_\" method (not limited by role restriction and so it could be accessed even if the blockchain node is a light node of the blockchain network) of the deployed smart contract to get a full list of peer details of existing consortium members. Figure 11: Adding New Registered Nodes to Enterprise Consortium. The blockchain service instance of the proposed node then invokes the propose-to-add endpoint of blockchain service instance owned by every consortium member. Once the votes of adding a proposed node to the consortium have amounted to half the consortium's size in terms of the number of participating members, _two consequences_ would then occur: (1) the peer details of the proposed node will be added to the on-chain registry of consortium members, which is, in turn, a _white list_ of the consortium members, to enable role-restriction in accessing the deployed smart contract's methods for wine record management, and (2) once the process on-chain operation is complete, the addition of the new node to the on-chain registry will occur, and be broadcast to the blockchain service instance of the consortium administrator based on the listener enabled in the blockchain service, which would, in turn, initialize a proposal to the blockchain network of adding the proposed blockchain node to the blockchain network, as well as sending requests to the counterpart of every existing consortium member to agree to this proposal via their own blockchain nodes, which run on the same blockchain network once it amounts to \(N\) / \(2+1\), in case the consensus algorithm of Proof-of-Authority is chosen for developing the blockchain network of dNAS. There is also a so-called _bootstrap stage_ applied to the on-boarding process, in which a specific starting number of registered nodes, e.g., five, that were proposed to join the consortium do not have to go through such a democratic voting process.