# NFTs for the Issuance and Validation of Academic Information That Complies with the GDPR
## 4 Discussion
The rationale behind leveraging a public blockchain was twofold. First, to demonstrate the feasibility of the solution without the need to deploy a proprietary infrastructure, and second, to underscore that, thanks to the model employed, it is feasible to use a blockchain where all registered information is public and visible to all users without affecting the protection of personal data and compliance with the GDPR. Indeed, deploying this model on a private or consortium blockchain could potentially enhance the solution's scalability. Given scenarios where thousands of academic records need to be issued promptly [32], permissioned blockchains such as those based on the HyperLedger framework offer better information-recording capabilities, and can withhold up to 20,000 transactions per second [82]. However, considering the focus of this research, centered on using an NFT to record academic information compliant with the GDPR, the outcome remains the same. Even within a permissioned blockchain with limited access, personal data cannot be stored permanently, in line with the stipulations for data protection. Using a private or consortium blockchain indeed improves costs and scalability, but at the expense of greater centralization, which could potentially pose a risk to the trust in the stored information. However, it is believed that a private or consortium initiative set up to support these educational certification services would be primarily interested in avoiding the risk of manipulations to ensure its trustworthiness. Is it possible to further decentralize the solution? According to the model description, its operation, and its advantages, it can be argued that the model relies on a centralized system since personal information is stored on a centralized entity. Additionally, it is worth considering whether further decentralization is feasible. Regarding the first point, the system does utilize a blockchain to instill confidence that the academic information accessible to third parties was issued by a specific institution, as the transaction is signed by them and contains personal data stored on a central server. In essence, a key aspect of managing personal information, namely guaranteeing confidence and trust, is decentralized. Moreover, due to the proliferation of tools for querying NFTs, the process of verifying data is straightforward, successfully fulfilling the initial goal of verifying the authenticity of academic information. Addressing the second issue--could it be further decentralized? The answer is affirmative. During the design of this model, an alternative, slightly more decentralized approach was considered, but discarded for reasons elucidated in the following paragraphs. One method to reduce dependence on the data stored in the centralized server of the issuing institution would be a model like the one introduced in this paper, but additionally incorporating some form of digest of the personal information into the NFT stored on the blockchain. In this case, it would be a dynamic NFT, as one of its fields would correspond to a hash summary of the dynamically generated personal data. Hence, if a third party wanted to validate specific information provided by the data holder, they would only need to compute the hash summary of the data and compare it with what is stored in the NFT. However, as highlighted above, this approach is not valid from a data protection perspective, since a hash summary is not a sufficiently secure anonymization technique [5]. Nonetheless, it could be possible to combine encryption with a hash summary with data salt, and store this in the blockchain within the NFT [5,10,43,82]. In this scenario, it could be considered that academic information is securely anonymized in this manner, provided the recommendations in [83,84] are followed, despite being per-manently storedon the blockchain. However, in the development and in the final proposed model, this part was omitted for several reasons:  
1.