## 5 Experiment
### Testing of File Integrity  
Figure 12 presents an example of how to upload a file by using the CEA DApp. When the user uploads a file, CEA DApp automatically detects its Ethereum Address. Then, the CEA DApp interacts with the IPFS private network, to upload the file. First, the file is stored in a local repository. Then it is distributed to other nodes in the network. IPFS returns a hash of the file, and CEA DApp triggers Metamask to confirm the transaction to be stored on the CEA Network.  
A transaction ID is used to retrieve data from the CEA Network. Figure 13 shows the results on the download page. It returns the block number, gas used, timestamp, input, and decoded input. The input contains an encoded hash of a file in Hex data format, with a length of 132 bytes. It should be decoded into a human-readable format. The hash will redirect to the IPFS gateway, on [[http://127.0.0.1:8080/ipfs/](http://127.0.0.1:8080/ipfs/)]([http://127.0.0.1:8080/ipfs/](http://127.0.0.1:8080/ipfs/)), so that the user can download the file without interacting with IPFS command-line interface (CLI).  
To ensure collaboration between CEA DApp and CEA Network or the IPFS private network, this experiment manually checks the IPFS and Ethereum console. Figure 14 shows the transaction that is stored on CEA Network, using the transaction ID. All transactions on CEA Network are immutable. It helps users to prove the hash of files that are stored on the IPFS private network. Moreover, the transactions will not spread into another Ethereum network, because the CEA Network is private.  
Figure 15 shows that a file is stored on the IPFS private network, using a hash. Because the file size is 1 MB, it is divided into 4 small parts, each of which is less than or equal to 256 kB.  
Figure 12: Testing of uploading a file on the CEA DApp.  
Figure 13: Testing of downloading a file on the CEA DApp.  
from another IPFS client node outside the private network. In this case, a swarm key in Client Node 1 is removed, so Client Node 1 is no longer registered in the IPFS private network. After Client Node 2 uploads a file, Client Node 1 and the public IPFS gateway try to download and read the content of the file. As seen in Figure 17, neither Client Node 1 nor the public IPFS gateway can download and read the content of the file. The IPFS network sets the local gateway inside the private network.  
The existing CEA system already has user access control, limiting file access to each user's respective unit. However, users can access files from another unit by suggesting archive ID on the URL, such as [[http://202.XXX.XXXX.XXXX/XXX/arsip/edit/ArchiveID](http://202.XXX.XXXX.XXXX/XXX/arsip/edit/ArchiveID)]([http://202.XXX.XXXX.XXXX/XXX/arsip/edit/ArchiveID](http://202.XXX.XXXX.XXXX/XXX/arsip/edit/ArchiveID)). The ID is not encrypted. Moreover, user access control is only implemented in the CEA application. The server administrator can download files directly to the server, without logging into the application.  
The testing results show that the IPFS private network in the proposed system maintains the confidentiality of files. The files are only distributed to registered nodes that have the same swarm key for the private network. In addition, the server administrator cannot download files directly into the local node. The files are split, and no single node stores an entire file.