## 5 Implementation and Evaluation
### Performance Evaluation of Smart Broker  
In this evaluation, we aimed to assess the smart broker's performance within the Hyperledger fabric in terms of reading data, processing it, and writing the results into the ledger. We tested smart contracts (TDM, TDQAM, and TRS) within the smart broker deployed on a Hyperledger Fabric through a comprehensive simulation process. The simulation is to test the time consumption when the number of topics increases. At any given point in time, the smart contracts must calculate the quality of information on all topics. If the calculations are not simultaneous, then the time consumed would be naturally less, and the quality information would finalize much faster. If, however, the velocity of data is high and the smart contract needs to calculate the quality of all topics based on reading the data from the ledger, the time required to calculate the quality will increase. As such, we focus on this aspect of the performance. We varied the number of simultaneous topic reads, ranging from low (1 read) to high (5000 reads), keeping the channel number constant at 1, to assess the performance of the smart broker in taking the time to read, process, and write the results to the ledger. The network settings used in our evaluation are detailed in Table 4.  
TDM (see Figure 12) shows a gradual increase in processing time as the number of simultaneous topic reads increases. Starting at 79.588 milliseconds for 10 reads, the time incrementally rises to 391.181 milliseconds for 5000 reads. It scales proportionally with the increase in topic reads.  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Network Configurations** & **Values** \\ \hline _Batch timeout_ & _2 s_ \\ _PreferredMaxBytes_ & _500_ \\ _Ledger Database_ & _CouchDB_ \\ _Block Size_ & _10 transactions_ \\ _Number of channels_ & \(1\) \\ _Number of topics_ & _1_–5000_ \\ \hline \hline \end{tabular}
\end{table}
Table 4: Network configurations.  
Figure 11: Recommendation score of the topic drops across noise levels (\(\delta\) = 15 s, \(w\) = 150 s, and \(a\) = 0.64).  
With the TDQAM (Figure 13), the time varies more non-linearly, from about 90 ms for 10 simultaneous reads to 30 s for 3000 simultaneous topic reads.  
With TRS (Figure 14), the time consumption is stable and linearly increases in processing time, starting at 89.586 milliseconds for 10 reads and rising to 133.958 milliseconds for 3000 reads. This gradual rise indicates that TRS efficiently manages increasing reads with minimal latency changes.  
Assuming a typical IoT system can have several thousand devices (and corresponding topics), it is practical to implement the blockchain-based smart broker given that most IoT data will come in an update of more than a minute (\(\delta>60\) s). Also, if multiple nodes of the Hyperledger are implemented, the time taken for calculating the quality components will also be reduced. Also, if using the Hyperledger fabric, multiple channels may be used  
Figure 14: Time (s) consumption by TRS for reading and processing data under varying topic loads.  
Figure 12: Time consumption by TDM for reading and processing data under varying topic loads.  
Figure 13: Time consumed by TDQAM for reading and processing data with varying topic loads.  
to keep the data shared between peers (or publishers/subscribers) in the blockchain and potentially improve performance.