## 3 System Architecture of the Decentralized Framework
### Blockchain Module
The smart contract function getBlockTimestampFromHash() is then called to verify the existence of these hashes on the distributed ledger. A matching hash confirms the data's integrity and the correct timestamp, whereas a mismatch indicates invalid data, thereby resolving the dispute. Table 1 illustrates an example using SHA-256 hashes computed from incident data. In Table 1, the first row shows the hash computed from the system-recorded incident data (including its timestamp), while the second row displays the hash computed with the external, disputed timestamp. The presence of only the first hash on the blockchain confirms the integrity of the stored data and the accuracy of its timestamp. It is important to note that although the HEA manages incident data, our design incorporating a public blockchain provides independent external verification. In situations such as legal disputes or regulatory audits, external stakeholders require assurance that recorded event timestamps and data integrity have not been subject to unilateral modification. By utilizing a public blockchain rather than an Ethereum sidechain or a private blockchain under HEA's control, the audit trail remains decentralized, trustless, and immune to cen \begin{table}
\begin{tabular}{l l} \hline \hline
**Timestamp** & **Hash** \\ \hline
10 July 2023 11:51:08 a.m. & \(k51/737/466338 acd27 acd1/217b2279 dc16545c7c1e5e5b446 cc1 bc3410a56 \\
10 July 2023 11:52:31 a.m. & \(k2\)98 ad6 fe18508 dd6 an14c/a704 hnd7f05/6f9f2/0x39c3a9c72e933 bdc289 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Example of SHA-256 hashes computed from incident data for integrity verification. tralized tampering. The immutability of the blockchain guarantees that once a hash is recorded, it remains unalterable, establishing a robust record that is time-stamped. Only storing the data's hash on-chain offers several advantages. The hash serves as an exact digital fingerprint of the original data, preserving its integrity and confidentiality. When data are retrieved from secure off-chain (cloud-based) storage, the system recomputes the hash and compares it with the corresponding blockchain entry, ensuring that the data remain unaltered. This process provides a cost-effective and scalable record of incident data. Moreover, because the hash is generated using a one-way cryptographic function, no sensitive information is revealed, thus ensuring compliance with privacy requirements. The blockchain's immutability further guarantees that once a hash is recorded, it cannot be modified, creating a reliable audit trail that verifies the data's existence at a specific time. Finally, only storing the hash, rather than the complete dataset, yields significant cost savings by avoiding the substantial expenses associated with on-chain storage of large data volumes. To efficiently manage the storage of critical and ordinary data, the system employs two strategies: time-based and threshold-based hash storage. The time-based strategy ensures that blockchain updates occur at regular intervals, aggregating critical data every 10 min while appending ordinary data less frequently, such as every 60 min. This strategy provides predictability and consistency, ensuring that data are recorded regardless of fluctuations in event frequency. In contrast, the threshold-based strategy dynamically adapts the frequency of blockchain writings based on real-time data flow. A new hash is computed only when the number of accumulated critical records surpasses a predefined threshold, allowing this method to adaptively respond to variations in event occurrence. Unlike the time-based approach, which maintains a fixed schedule, the threshold-based method optimizes resource usage by writing data only when necessary, reducing suboptimal transaction requests.