## 7 Experiments
### Performance Analysis  
In this section, we analyze the performance of the proposed solution by examining the throughput of publishers, subscribers, and the broker. Throughput refers to the rate at which publishers can dispatch locally generated messages to the broker and the rate at which subscribers can consume messages received from the broker. Similarly, on the broker side, the throughput is the rate at which it can send messages to the subscribers. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Operation** & **Client-Side** & **Broker-Side** \\ \hline Hash (SHA-256) & 148 ms & 58 μs \\ addRootIPFSAddress & – & 18.088 s \\ getIPFSAddress & 16.331 s & – \\ IPFS Upload & – & 9 ms \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Execution times client-side and broker-side. In our experiments, we measured the normalized throughput with respect to the maximum throughput, which is determined based on the transmitted data's generation rate. The maximum throughput is computed by observing the frequency by which data are generated in our dataset. In Figures 6 and 7, we report how the normalized throughput varies as the frequency of round times (per day) increases and as the number of topics increases for publishers and subscribers, respectively. Concerning the number of topics, we considered the number of topics on which a publisher publishes. The ideal normalized throughput is \(1\), which represents a scenario in which the system handles all generated messages without any additional overhead. However, as expected, in our experiments, the normalized throughput deviates from \(1\) as the frequency of rounds increases throughout the day. This deviation occurs because additional operations are required at the end of each round. Specifically, concerning publishers, this decrease is due to the execution of the following operations at the end of the round: (1) computation of an MHT, (2) verification of the presence of the computed root in the blockchain, to ensure there is no integrity violation on the broker side. Figure 6: Normalized throughput of publishers. Figure 7: Normalized throughput of subscribers. Concerning subscribers, this decrease is due to the execution of the following operations at the end of the round: (1) computation of a path of hashes for each topic, (2) verification of the presence of the computed root in the blockchain (as on the publisher side). Considering (1), we observe that, in general, subscribers may not be interested in the whole set of topics of the publisher. In our experiments, we considered that the number of topics in which the subscriber is interested is, on average, half of the topics of the publisher. It can be seen from the plot that the increase in the number of topics and, thus, the increase in the time for calculating the MHT, generates differences in the normalized throughput that are not appreciable. In fact, even when the number of topics is in the hundreds, the calculation of the MHT takes less than 1 s. On the other hand, the operation that most affects the reduction in throughput is the invocation of the getIPFSAddress function, the execution of which takes more than 15 s on average. Due to this end-round operation, the normalized throughput deviates from the maximum one. However, for both publishers and subscribers, we observe that the reduction in throughput is at most 20% in the worst-case scenario, where the round time frequency is as high as one round every 60 s (1440 rounds per day). We highlight that this represents an extreme case. Typically, the frequency of round times should be chosen based on the data publication frequency to ensure there are enough messages published within a round. Overall, the higher the round time, the lower the throughput reduction. In our dataset, the data are generally published every 30 s. Therefore, with a round time of 60 s, in each round, only two messages are published. Thus, the introduced overhead reduces the throughput of the clients.