# Trusted Third Party Application in Durable Medium e-Service
## 4 Experimental Verification of the Proposed e-Service--A Case Study
The client's decision is forwarded to the ISP, which forwards it to TTP. Then, the TTP places this decision, along with the customer identifier (CID) and document hash (DID), in the blockchain as a new transaction in the block. The process of acceptance or rejection of the document by other customers is analogous and iteratively repeated by the ISP. Ultimately, after each of the 10,000 customers makes a decision, 10,001 transactions will appear in the blockchain (the first transaction with the document provided by the ISP and 10,000 transactions with the decisions of 10,000 customers regarding this document), as shown in Figure 6. The figure represents the total number of transactions after the implementation of both scenarios within the same blockchain, therefore the number of transactions added in the second test scenario is 20,001 - 10,001 + 10,002 - 10,001 = 10,001. Moreover, in the first test scenario, it was assumed that approximately 80% of customers would accept the document and the remaining 20% would reject it. In the second scenario, the accepted level of acceptance was 90%. Therefore, in the implementation of both scenarios, special randomization functions were added to implement the above assumptions. In practice, it turned out that the level of acceptance differed slightly from the assumed level (81.63% in the first scenario and 91.08% in the second scenario). The remaining performance results obtained during the realization of both test scenarios are summarized in Table 2. Compared to Figure 4, there are 10,001 more transactions (1 for the added new document and 10,000 for customer decisions). According to the conducted test scenarios where over 30,000 transactions were added to the blockchain, the implemented e-service worked properly, and the initial requirements were met. The obtained performance results are also acceptable. In the first scenario, the \begin{table}
\begin{tabular}{c c c} \hline \hline \multirow{2}{*}{**Parameter**} & **Obtained Value** & **Obtained Value** \\  & **(First Scenario)** & **(Second Scenario)** \\ \hline The level of acceptance of the document by customers & 81.63\% & 91.08\% \\ Average time of adding a document transaction to the & 23.073 & 202.164 \\ blockchain (in milliseconds) & & \\ Average time of adding a customer’s decision & 0.0358544 & 0.0486139 \\ transaction to the blockchain (in milliseconds) & & \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Summary of selected experimental results. Figure 6: Summary of the number of transactions after execution of the both test scenario. average time of adding the transaction responsible for adding a new document (by the ISP) to the blockchain was approximately 23 milliseconds, which for 10,000 documents is less than 4 min. In the second scenario, the time of adding a document was approximately 202 milliseconds, which is quite a lot compared to the first scenario; however, it is worth remembering that there was only one added document in the second scenario, so the obtained result is also acceptable. The average time of adding transactions with customer decisions was only about 0.036 milliseconds in the first scenario, and 0.049 in the second scenario, which are also fully satisfactory results. Although the experimental verification finished with success, the authors faced several issues. One of them was the problem of working out error-free smart contracts. This is a real challenge, since adding a contract containing errors to the blockchain results in serious consequences for the entire blockchain network. Another issue is related to the asynchronous technique of adding a transaction (i.e., without confirmation whether the transaction has been added or not). However, an in-depth analysis allowed us to find a solution to this problem (the detailed description is considered for future work). It is worth noting that the dataset used in the experimental verification was prepared by the authors. The dataset includes more than 10,000 documents (in portable document format, PDF) specially generated for both test scenarios.