# Decentralized and Secure Blockchain Solution for Tamper-Proof Logging Events
## 4 Experimentation  
To assess the feasibility of the secure log storage, this section presents both the procedures implemented in the stress tests conducted and presents the results derived from the analysis of the test data acquired.  
The hardware and software components were implemented within a local network to minimize latency in the scenario used, except for the public blockchains. On the one hand, there is a Raspberry Pi 4 Model, which uses a Broadcom BCM2711 Quad core Cortex-A72 (ARM v8) 64-bit SoC 1.5 GHz processor and 4 GB of LPDDR4-3200 SDRAM running the Raspberry Pi OS 5.10. This OS version is a Debian variant optimized for Raspberry Pi. On the other hand, a server with an Intel Core i7-10870H 2.20 GHz processor and 16 GB of DDR4 RAM running the Ubuntu 22.0.4.3 LTS operating system was used to install the Syslog-ng server, the RabbitMQ Message Broker, and the log module. This server supported the log server management, as well as the node and wallet in the Cardano scenario.  
It is important to note that in the log module, which communicates directly with the message broker, several tests have been performed depending on the prefetch (i.e., the number of messages in the queue that are consumed in a request). For instance, in case it is set to 1, it will wait until all the processing is finished before consuming the second message. Given the asynchronous nature of NodeJS, when blocking operations (e.g., HTTP requests, disk accesses, etc.) are encountered in the processing of each message, this language could continue with the actions of the second message until the previous one is unblocked, which is a significant improvement in efficiency, as can be seen in Figure 6, an example execution with a prefetch of 3 events. As shown in the example, after retrieving the events from the message broker, the potential requests that could cause blockages are sent to the blockchain and the log management server. However, certain factors beyond our control, such as high congestion in the blockchain or temporary network outages, may impact these requests. In these cases, NodeJS will continue executing other instructions regardless of the blocked flow. The optimal prefetch value will depend on the specific scenario, considering factors such as the number of logs per second being processed or log module instances. Achieving an equilibrium between these variables will provide optimal system performance.  
A comprehensive experiment was conducted using Loggen, a high-performance log generation tool designed for stress testing syslog servers. This tool enables benchmarking and load testing by generating and transmitting syslog messages at configurable rates. The UDP protocol was utilized during the tests, and the maximum average message size parameter was set to 8192 bytes. A single instance of the log module was used, with prefetch values of 1, 10, 20, and 50 tested for loads of 1 event/s, 10 events/s, 20 events/s, and 50 events/s on both blockchains. We also evaluated several processing times, such as the processing time within the log module, the time from when the event is generated until it is certified in the blockchain, the time from when the event is generated until it has persisted in the log management server, and the total execution time of each test bench. We performed 10 iterations for each case to average values and used the NodeJS performance API with millisecond level resolution to measure time.