## 2 State of the Art
### Regulatory Compliance Regarding to Data Privacy
It is important to note that some decentralized databases like OrbitDB store the information in plain by default [83], so developers have to take privacy-protection actions to comply with laws regarding data privacy. Figure 1 also shows the different actors that interact with the system (highlighted in purple), who are:  
* **Students**. Once registered, students are able to see the evolution of their ARs after their periodic exams and courses. Whenever a student needs it, his/her AR can be downloaded (typically in a PDF file) and shared with a third-party, like an organization interested in hiring him/her that wants to validate the student academic merits. * **Administators**. After exams, professors register the marks obtained by the students in the decentralized database. However, such marks need to be verified before getting traced in the blockchain. Administators can be seen as permissioned professors, who are responsible for looking into mark changes and update the hashes in the blockchain. Specifically, the developed DApp detects when the ARs state is changed by the professors and creates a list with the updated ARs, which will be shown to the administrator (e.g., to the head of the department or to a person that works for the university/school administration) and, if he/she approves the changes, he/she will create a transaction to update the AR hashes on the blockchain. Such an update can be performed individually for each AR or in batch (i.e., for several ARs at the same time) to accelerate the process. It is important to note that, as it was previously mentioned, each transaction only uploads the AR hash to the blockchain (not the AR raw data). * **Third-party**. It is any external user that wants to verify the validity of an AR. This is simply performed by uploading the provided AR document to the DApp, which will  
Figure 1: Relationships between actors and subsystems. show almost instantly whether the introduced AR is part of the blockchain or not (by comparing its hash with all of the hashes stored in the blockchain). To deploy the devised architecture, every participating entity needs a full node to interact with the blockchain. However, the process of setting up a full node is not straightforward for most users. As this would not favor the adoption of the proposed solution, there are other ways to access the blockchain such as using node providers. For instance, there are third-party intermediate services that provide already configured full nodes able to interact with the DApp and with the blockchain network [84]. In the case of Metamask wallets [85], they already use these services to emit transactions, so simply using a Metamask wallet hides the complexity of the infrastructure to non-technical users although it presents other limitations from an usability standpoint, as it will be discussed in Section 4.3. Figure 2 provides a low-level perspective of the three main subsystems of the DApp and how they communicate. Such a Figure depicts an architecture that follows a Remote Procedure Call (RPC) model, where the DApp is the client and the RPC node is the server. The client just sends requests to the RPC node, allowing an easy real-time interaction with the blockchain data.