# Blockchain-Based Decentralized Architecture for Software Version Control
## 5 Implementation  
In this section we present the implementation of the model proposed in the above section. Our proposed model is implementing the version control system in blockchain technology and it consists of multiple components, i.e., distributed repository, smart contract, private blockchain, and consensus algorithm. Figure 8 shows the implementation model based on the proposed approach. The implementation is performed on a Hyperledger toolset. Hyperledger are a group of open-source tools for blockchain development, which notably consist of Hyperledger Besu, Fabric and Sawtooth [52]. We use Hyperledger Fabric because it is now the most common tool for developing private blockchain and writing smart contracts. Hyperledger Fabric is a plug-and-play blockchain architecture that serves as a foundation for constructing blockchain-based goods, solutions, and applications for private organizations. Hyperledger Fabric was founded by Digital Asset and IBM and has since evolved into a collaborative cross-industry effort hosted by the Linux Foundation. Fabric was the first Hyperledger project to pass through the \"incubation\" stage and enter the \"active\" stage in March 2017 [53]. We have divided our implementation into three major modules, with one consisting of developers who will be responsible for uploading document. Next, we have a Hyperledger Fabric Client and Fabric network. The developers will be connected to the Fabric Client and it will be responsible for communication with the network. The Fabric Client will be hosted on a cloud environment, so that anyone from any place can use our distributed version control system. Authorizers who will be connected directly with the network will be responsible for enrolling developers in the Hyperledger network. Authorizers will not be able to make any change to the blockchain data or files in IPFS and will only have authority to enroll developers into using the version control blockchain using smart contacts. All the programming is done through smart contracts, which are written using JavaScript in the Hyperledger network. For deployment of our application, we require a platform. For the purpose we have used Docker. It is a platform for creating containers on which applications can be deployed and could easily be integrated in cloud environment [54]. We have deployed both Hyperledger client and server on different containers on Docker and accessed that from a third source, which will act as the developer. We have used the InterPlanetary File System (IPFS) for storing the file versions, and only reference to the file and cryptographic hash against the file will be stored in blockchain as storing large amount of data will not be possible in blockchain. The cryptographic hash will be unique against each file and for change a new file will be stored to the blockchain against the file ID but with a new version. So, the flow of application will be:  
1. Developer will connect to Fabric Client;
2. Client will send all requests to Fabric network;
3. Fabric network will be responsible for making all the changes in to ledger;
4. Each block in ledger will be associated to a file placed in distributed repository (IPFS);
5. Cryptographic hash generated for each file in IPFS will be stored in the ledger. Figure 9 shows the flow of a document being uploaded from the developer's end to IPFS. First of all, the developer will be connected to the Hyperledger Fabric network. The first request will be sent to the Fabric network from where it will be sent to the smart contract implemented in the blockchain network that contains the ledger. First, the ledger will be updated, and then the document will be uploaded to the IPFS repository. A confirmation email will be issued to the developer confirming the successful upload of the file and ledger entry. The developer will then provide the file ID if he wants to add content to the same file. Figure 8: Implementation model for BDA-SCV.