## 4 Proposed Solution  
Figure 1 illustrates the general architecture of the proposed solution. It includes at its core a decentralized application (dApp), which interacts with the traditional centralized storage for retrieving the data to be persisted, made immutable through the blockchain by using a set of smart contracts, and the IPFS. It is important to note that the main idea is to store data efficiently on IPFS rather than directly in blockchain, which can be costly and inefficient. However, since data are supposed to be sensitive and subject to privacy concerns, it undergoes a process of encryption before being stored on IPFS. At the same time, the data hashing technique generates a fingerprint of each row and allows the fast detection of data manipulation without the need to decrypt the data. Moreover, the IPFS returns a CID as the result of storing data, and the CID is permanently stored in blockchain for traceability. The CID is a unique identifier for the data and essentially a hash of the data stored on IPFS. While in a centralized web service, content or data can be accessed through location-based uniform resource locators (URLs); in IPFS, content or data are stored and retrieved based on hash, which makes it more challenging to censor or manipulate. Moreover, there is no need for trust in IPFS data hosting entities. The proposed solution achieves data privacy, integrity, and query optimization by properly integrating the hashing and encryption of data. In the future, any modification can be detected by simply comparing the previous hash stored on IPFS and newly generated hashes of modified data. Consequently, this approach eliminates the need for decryption, which often depends on revealing private keys and poses security risks, limiting this possibility only to the case in which previous data need to be effectively restored. Moreover, this scheme allows for the easy separation of concerns since an integrity check can be performed without revealing the content. Algorithm 1 illustrates how the data from the centralized storage are prepared for storage in IPFS. The function CreateDataForIpps receives as input a list of records corresponding to the database rows in Figure 1. For each row, the function computes the hash of the row content (see line 4) and includes the tuples \(\langle id_{i},H(record_{i})\rangle\) in a list, where \(H()\) represents the application of the hashing function. After that, the function encrypts the overall content through the function \(E()\) (see line 6). The content stored on the IPFS is the union of these two elements, as reported in line 7. We employ the SHA-56 algorithm [23] for hashing, which maps the given data to a 256-bit fixed-size cryptographic hash. The characteristic of a hash is that all unique input data produce a unique hash value. Even minor changes in the input data result in a significant change in the hash output. This property of hashing is known as the avalanche effect. ```
1:procedureCreateDataForIpps(\(rawData=\{\langle id_{i},record_{i}\rangle\}_{i=1}^{n}\))
2:\(hashedData=\{\}\)
3:for\(d\in rawData\)do
4:\(hashedData=hashedData\cup\{\langle id_{i},H(record_{i})\rangle\}\)
5:endfor
6:\(encryptedData=E(rawData)\)
7:return\(combinedData=\{hashedData,encryptedData\}\)
8:endprocedure
```  
**Algorithm 1** Creation of the data to be stored in IPFS  
**Definition 1** (Hashing). : _Let \(D\) be the data entry and \(H\) be the hash function implementing the SHA-256 algorithm. The hashing process can be represented as_  
\[H(D)=h \tag{1}\]  
_where \(h\) is the unique hash result._  
For encryption, we employ Password-Based Key Derivation Function 2 (PBKDF2) [24], a key derivation function with a sliding computational cost to reduce vulnerability to brute-force attacks. It generates a cryptographic key from a secret, preventing the need to save the encryption secret on a centralized database or server and improving security. **Definition 2** (Key Derivation). : _Let \(P\) represent the user-provided secret and KDF the key derivation function.