## 5 Evaluation and Discussion  
### Experimental Setting  
For evaluation, experiments were performed on a computer system with an Intel Core i7-5557U 3.10 GHz processor, 16 GB memory, and Windows 10 (64 bit) operation system. The Ethereum platform, which is an open source platform featuring smart contract (scripting) functionalities, was used for implementing the proposed system. The smart contracts were written in Solidity and deployed with Truffles with no capacity restrictions on the stored data size. To allow the interaction with an Ethereum node using HTTPS, the web3.js library was employed. The open source Apache JMeter was used as a functional and performance measurement tool for testing the services provided on the web. The experimental parameters and their values are given in Table 3.  
Several tests based on two parameters were performed: the number of submitted queries and the size of the stored academic records. The measurement of the performance was based on the following  
Figure 6: Generating/validating/appending a new block. \begin{table}
\begin{tabular}{c c} \hline \hline
**Description** & **Values** \\ \hline The submitted Queries & 1000–10,000 \\ \hline The stored EARs & 10,000–100,000 \\ \hline Number of nodes & 1000–10,000 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Parameters used in the experiments. Similarly, the average response time and the average number of messages sent per node increased as the total number of stored records was increased, as shown in Figures 9 and 10. Figure 8: Average number of messages vs. submitted queries. Figure 9: Average response time (s) vs. academic records. These situations are expected as the more queries to be submitted, the longer it takes for a query to be completed and the more communications among participant nodes to be occurred. In addition, the more records to be stored, the more participants to use the system, and, thus, the more queries to be submitted on the system. However, the throughput of the system remains constant even with the increments of the submitted queries or the stored records (Figures 11 and 12). The stability of the system's throughput even when increasing the number of stored records and the number of submitted queries prove the ability of the system to handle and process a large dataset with high frequency at low latency as in EARs systems. Figure 11: Throughput vs. Submitted queries. Figure 10: Average number of messages vs. academic records. Actions in the proposed system are classified into off-blockchain and on-blockchain actions. The off-blockchain actions involve computing the degree of university nodes during the blockchain initialization, creating an access link, calculating its hash value and encrypting it when adding a new record. In addition, database storage and retrieval procedures are off-blockchain actions. The on-blockchain actions include retrieving and storing data values in smart contracts, sending internal transactions to link different contracts, and spawning new contracts using other contracts. The diversification of the system modules and the balance between the on-chain and the off-chain actions involve increasing the features of the proposed system while maintaining its performance. The proposed system adopts the PoA consensus algorithm, which plays a significant role in the system performance as it can handle more transactions per second compared with the PoW and the PoS. The PoA minimizes the intensive of computations and increases the system performance as it provides lower transaction acceptance latency and steady time intervals for issuing blocks. According to the proposal, two rounds are required for the generation and the validation of the new block. The block's creator node first sends the created block to only involved nodes (i.e., no need to send the block to all participants in the network). These nodes validate their logs and then reply with a verification. A block will be appended when receiving all associated verifications.