## 7 Experiments
### Performance Analysis
On the other hand, if the time round duration is higher than 5 min, we can observe that the reduction of the throughput is lower than 10%. Figures 8 and 9 report how the normalized throughput of the broker varies as the number of publishers increases and as the frequency of round time (per day) increases, considering 16 topics (in Figure 8) and 128 topics (in Figure 9). To conduct these experiments, we considered a single broker, one subscriber, and an increasing number of publishers (up to 10,000 publishers). In Figure 8, where 16 topics are considered, we observe that the increasing number of publishers does not significantly affect the normalized throughput. On the contrary, in Figure 9, where 128 topics are considered, we can see that when the number of publishers increases, the normalized throughput decreases. However, the reduction in normalized throughput, as the number of publishers increases, is minimal, since it always remains below 2%. Figure 8: Normalized throughput of the broker, considering 16 topics per publisher. As the number of publishers increases, the number of MHTs that the broker needs to calculate also increases linearly. Additionally, the time to compute an MHT increases linearly with the number of topics. However, as mentioned earlier, the time to construct an MHT for each client is significantly low due to the nanosecond order of hash calculation time. For instance, if there were 100 million publishers connected to a single broker, the time to calculate all the hashes would be approximately 50 s. However, with such a large number of publishers, the bottleneck would be managing concurrent connections (It is estimated that a HiveMQ broker can support up to 10 million concurrent connections), rather than managing the computations of MHTs. We observe that as the number of publishers increases, the number of network operations performed on the blockchain and IPFS also increases linearly. We recall that for each publisher, the MHT root must be saved on the blockchain (via the addRootIPFSAddress function), and the MHT must be stored on IPFS. However, unlike the CPU-intensive MHT computation operations, network operations are I/O operations and can be managed in parallel. This explains why the linear increase in these operations does not result in a linear decrease in the broker's normalized throughput. Despite this, the execution of the addRootIPFSAddress function requires more than 15 s to complete. Thus, this is the operation that causes the most throughput reduction. Indeed, as explained before, the operations involving the blockchain generate the highest overhead. This overhead produces a reduction in the throughput that increases linearly with the increase in the time round frequency (per day). However, by choosing appropriate round frequencies, the reduction in throughput can be limited. For example, if the time round duration is higher than 5 min, we can observe that the reduction of the throughput is less than 3%. We also experimented with how the broker-side throughput is affected by an increasing number of subscribers. Specifically, we considered a setting with a single publisher, one broker, and a growing number of subscribers. This scenario did not produce significant differences in throughput. For each subscriber, at the end of the round, the broker must send the root and the hashes that allow reconstruction of the path from the hash chain (calculated locally by the individual subscriber) to the MHT root (for each topic to which the subscriber is subscribed). However, these hashes and the root can be sent piggybacking on the last message of the round. Moreover, these are network (I/O) operations, making them easily parallelizable. As a result, no substantial variations in throughput are observed with an increasing number of subscribers. Figure 9: Normalized throughput of the broker, considering 128 topics per publisher.