## 5 The Proposed Approach
### Final Remarks  
As final remarks, we highlight the main advantages of our solution by motivating the design choices we adopted.  
We start making some considerations regarding the storage required by our solution.  
The main information that our solution needs to store is the hashchains built at each round. We recall that, during each round, publishers (subscribers, respectively) compute a hashchain for each topic they publish to (are interested in). Similarly, the broker computes a hashchain for each topics to which publishers are publishing. Once an entity in the system sends or receives a message, it computes the current value of the hashchain by computing the hash of this message with the last stored hashchain. At this point, the message is no longer needed and thus can be discarded, as well as the older value of the hashchain. Therefore, at the end of the round, an entity in the system needs to locally store just a digest per topic. Additionally, after performing the integrity checks, the digests can be discarded. Just as an example, if the entities manage 1000 topics, only 32 KB of storage are necessary.  
We highlight, as analyzed in Section 7, that computing the hashchain on the fly does not affect the throughput of the system. Indeed, the time typically required to compute the hash (which is needed to update the hashchain value) is much lower than the time between the generation of two consecutive packets. Therefore, the computation of the hashchain does not affect the sending rate and thus the throughput of the system.  
To conclude this section, we discuss the benefits of combining hashchains with MHT in our solution rather than building an MHT directly on the messages.  
We observe that in our solution, the leaves of the MHT are represented by the hashchains, which are in the same number as the topics of a publisher. On the other hand, if the MHT is built directly on the messages, the leaves would be in the same number as all the messages published in a round time (by such a publisher). This would result in a higher number of hashes necessary to build the MHT. Additionally, this would result in a higher number of hashes when verifying the path from the leaves to the MHT's root.  
More formally, we denote by \(|T|\) the number of topics of a publisher and \(|M|\) the number of messages that it publishes during a time round. Clearly, it holds that \(|T|<|M|\). Therefore, if the leaves are the number of topics, the MHT computation requires the computation of \(2\times|T|-1\) hashes. However, when the leaves are the number of messages, the MHT computation requires the computation of a higher number of hashes, i.e., \(2\times|M|-1\) hashes.  
Additionally, if the leaves are in the number of topics, the height of the MHT is \(log|T|\). While, when the leaves are in the number of messages, the height of the MHT is \(log|M|\). This impacts the verification process (performed by subscribers) since, in the second case, the number of hashes that need to be computed to verify whether a leaf is part of an MHT is higher. Therefore, combining hashchains with MHT is computationally more efficient. Additionally, for each topic, the subscribers are interested in verifying that the flow of messages published on that topic is intact. As such, verifying the path from the hashchain on that topic to the MHT's root is the fastest way to verify the entire flow on that topic, since it requires just one verification. On the other hand, if the MHT is built on messages, the verification process requires verifying the path from each message on that topic to the MHT's root. Hence, while in the previous case, the number of paths to verify is the number of the topics to which the subscriber is interested, in the second case, the number of paths to verify is the number of messages on those topics, thus making the verification process much more inefficient.