# Decentralized and Secure Blockchain Solution for Tamper-Proof Logging Events
## 5 Results and Discussion
### DRACSC Performance Test  
The results of the tests on the Solana blockchain indicate that the average time for a request per second is over 12.82 s for 1 event/s, 17.94 s for 10 events/s, 22 s for 20 logs/s, and 31.77 s for 50 events/s, as shown in Figure 7. Table 4 illustrates the average outcomes for 10 iterations and their standard deviation. The \"Log Module\" column represents the event's duration in the log module service. The \"From event to blockchain\" column measures the interval from an event's arrival at the Syslog server until its recording on the blockchain. The last column, \"From event to Log Management Server\" indicates the time taken from the event's arrival until its persistence in the log management system.  
Figure 6: Example of asynchronous execution of messages in the experimentation carried out.  
Figure 7: Execution times with the Solana blockchain.  
The experimental results on Solana indicate that the average processing time for individual requests remains relatively stable across different event rates. Nonetheless, as the event rate increases, there is a noticeable increase in time, especially in the interaction of the event with the blockchain. This suggests that while Solana demonstrates consistency in processing individual requests, the system's scalability and responsiveness may be challenged under higher loads of concurrent events. On the other hand, the results suggest that the system appears well suited for environments that require certification for a moderate number of critical logs; however, further optimization strategies should be considered for scenarios involving increased event volumes. Complementarily, higher hardware resources would be required to support the proposed system if the number of module log instances exceeds this limit due to the limitations of the Raspberry Pi.  
The results found with the Cardano blockchain that supports metadata achieved 4.35 s for 1 event/s, 626.55 s for 10 events/s, 1098.45 s for 20 events/s, and 3071.65 s for 50 events/s, as shown in Figure 8. The average results for the 10 iterations and their standard deviation can be seen in Table 5. The experimentation reveals that the log module processing times fluctuate with increasing event rates. The times from event to blockchain and to the log management server experience significant increases, particularly under higher event rates. This suggests that Cardano exhibits longer processing times for individual requests than Solana, and scalability challenges become more evident in scenarios with increased concurrent events. Consequently, Cardano appears viable only in scenarios where certification events occur very infrequently. This is due to two factors: on the one hand, there is a restriction on the number of transactions per second imposed by the Cardano network. On the other hand, Cardano Mempool's deliberate design prevents certain actors from monopolizing the entire blockchain bandwidth by processing transactions in a FIFO queue. In conclusion, optimization measures may need to be implemented to improve overall system responsiveness.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Events/Second** & **Log Module (ms)** & **From Event to Blockchain (ms)** &
\begin{tabular}{c} **From Event to Log** \\ **Management Server (ms)** \\ \end{tabular} \\ \hline
1 & 5.45 \(\pm\) 4.69 & 12,836.45 \(\pm\) 293.33 & 12,824.20 \(\pm\) 287.71 \\
10 & 5.99 \(\pm\) 3.32 & 1835.59 \(\pm\) 1192.15 & 14,810.23 \(\pm\) 1056.99 \\
20 & 5.26 \(\pm\) 4.08 & 3866.75 \(\pm\) 2430.11 & 15,532.33 \(\pm\) 1234.68 \\
50 & 5.17 \(\pm\) 4.41 & 7546.99 \(\pm\) 5501.71 & 18,623.97 \(\pm\) 10,797.62 \\ \hline \hline \end{tabular}
\end{table}
Table 4: Average time for a request in Solana.  
Figure 8: Execution times with the Cardano blockchain.