A Blockchain-Based Certificate System with Credit Self-Adjustment

: Currently, digital certificate systems based on blockchain have been extensively developed and adopted. However, most of them do not take into account the certificate quality. To evaluate the credibility of certificates issued by educational institutions, we propose a novel blockchain-based system with credit self-adjustment (BC-CS). In BC-CS, employers can provide feedback according to the perfor‐ mances of their employees (i


Introduction
As a public ledger, blockchain aims to establish a decentralized and transparent environment, where the data and transactions are verifiable and permanent. Such a technique is considered as a radically new and promising infrastructure to secure, share, and verify the learning activities and outcomes in the field of education [1] . For instance, by applying a blockchain-based certificate system, we can reliably keep a list of the issuers and receivers of all certificates, together with the signatures in a decentralized distributed database [2] . As a result, all certificates are traceable, easily verified and cannot be forged.
In the literature, several digital certificate systems based on blockchain have been developed, including Blockcerts [3] , the school certificate system [4] , TUDoc-Chain [5] , ECBC [6] , etc. Most of them are composed of three groups of users: (i) certificate authorities (CAs), (ii) students (STUs), and (iii) verifiers (e.g., employers). When a student satisfies the given requirements (e. g., passing the exam), the CA grants this student a digital certificate in the form of a unique identity number (e.g., a hash value). The system automatically records such information in a blockchain. When applying for a job, the student needs to send his/her identity number to a target employer (EP). EP can use this number and the blockchain to easily verify whether his/her certificate is forged or not. In 2017, the World Wide Web Consortium (W3C) proposed the Verifiable Credentials (VC) specification [7] , attempting to express the credentials on the web in a way that is cryptographically secure, privacy respecting, and machine verifiable. This specification identifies the roles of the core actors (e. g., issuers, holders and verifiers) and, furthermore, provides a well-defined lifecycle for the data models of credentials in the VC ecosystem.
However, most conventional systems do not take into account the certificate quality of being convincing, referred to as certificate credit in this paper. In practice, employers are more concerned about the actual skills of students rather than their certificates. It is crucial that a certificate can accurately represent the true skill level of these students. Suppose that a group of students have received a specific certificate C. Nevertheless, their employers find that these students do not carry the skillset claimed by C. Hence, the certificate C will not be trusted in future career fairs. The credits of both C and its issuer are lost. On the contrary, if these students are perfectly equipped for their jobs, the employers will prefer to hire other similar employees holding the certificate C. Namely, the credit of C is reinforced. Students will be further encouraged to apply for the certificate C in order to acquire future job opportunities. In this paper, we define the certificate credit as a positive integer. The higher the credit is, the more the certificate is trusted by EPs.
To appropriately represent the certificate credit and provide sufficient information to distinguish different certificates, we propose a novel blockchain-based certificate system with credit self-adjustment (BC-CS) in this paper. In the proposed system, EP provides feedback according to the performances of the employees owning different certificates. Based on the feedback, the system automatically adjusts the certificate credits by using several carefully designed smart contracts. In addition, we introduce the idea of accreditation authorities (AAs) to initialize certificate credits and support multi-step accreditation. In summary, the proposed BC-CS system carries the following unique features compared against the conventional certificate systems: • We define the concept of certificate credit to quantitatively assess the certificate quality.
• We propose a credit self-adjustment algorithm to automatically adjust the certificate credit based on the feedback from EPs.
The remainder of this paper is organized as follows.
In Section 1, we describe the proposed BC-CS system. In Section 2, we discuss several implementation issues and analyze the system performances. Finally, we conclude in Section 3.
1 Proposed System

Overview
As shown in Fig. 1, our proposed BC-CS system involves four groups of users: AAs, CAs, STUs and EPs. All users are identified by their unique addresses in the blockchain. AA usually refers to the government and/or the third-party certifying body. AAs authorize CAs to issue certificates and, in addition, initialize the credits of different certificates. When an STU has met the given requirements, CA grants him/her a digital certificate. The certificate is recorded in a blockchain in the form of hash value together with its credit. The hash value is calculated by using a cryptographic hash function [8] (e. g., SHA-256). With the hash value, EP can verify not only that this STU indeed receives a certificate from the CA, but also that the CA is certified by the AA. Furthermore, EP provides feedback to AA according to the performances of this STU and, hence, receives reward from AA. Based on the feedback, AA can automatically adjust the credit of this specific certificate. Note that different certificates are usually assigned with different credits.
In the proposed BC-CS system, we extend the W3C VC specification along two complementary avenues. First, we introduce AA to authorize CA for certificate issuance. Hence, BC-CS supports multi-step accreditation by verifying both the validity of the credential and the legality of the issuer. Second, BC-CS leverages certificate credit to dynamically assess the quality of credentials (i. e., the ability of the credential holders).
The aforementioned system is implemented by using smart contracts on Ethereum [9] . For instance, by storing the CA address over the blockchain in the smart contract of AA, AA accredits CA as a legitimate institution to issue certificates. In addition, we use Swarm [10] to store all certificates. Swarm generates a hash value to represent each certificate in the blockchain.

Certificate Issuance and Verification
The workflow of certificate issuance starts by collecting all information required by a specific certificate for an STU, including his/her competency and personal information, the date of issue, the certificate credit, the addresses of the issuing institution CA and its accrediting organization AA, etc. Swarm stores all relevant information and generates a hash value (i. e., the certificate hash). As shown in Fig. 2, when receiving hash values for a group of certificates issued within a specific period of time (e. g., one year or one semester), CA applies a Merkle tree [11] to generate a root hash and a Merkle proof for each certificate. The root hash is saved in the blockchain. Swarm stores the Merkle proof and generates another hash value (i.e., the proof hash). Finally, CA sends the certificate hashes and the proof hashes to the STUs. Note that CA builds one Merkle tree for all certificates of the same category issued within a given time period. Namely, different Merkle trees hold different categories of certificates or the certificates of the same category issued at different time.
As shown in Fig. 3, when applying for a job, the STU should submit his/her certificate hash and proof hash to a target EP. According to these two hash values, EP can download the certificate and its Merkle proof from Swarm for an existing certificate. In the downloaded certificate, we can find the addresses of the issuing institution CA and its accrediting organization AA. Next, based on the Merkle tree, EP will generate a root hash that is identical to the one saved in the smart contract of CA. We can further check whether the smart contract of AA saves the CA address or not (i. e., whether AA authorizes CA to issue certificates). Leveraging the aforementioned steps, the proposed BC-CS system supports multi-step accreditation. If any of these verification steps fails, the certificate does not exist or has been forged.

Credit Self-Adjustment
As shown in Fig. 4, according to the aforementioned discussions, once AA receives feedback from EPs, it will automatically adjust the credit of the relevant certificate. The proposed credit self-adjustment algorithm is derived based upon EigenTrust [12] . EigenTrust is a reputation management algorithm for P2P networks. It computes a global trust value for each peer based on the satisfactory and unsatisfactory responses between two different peers. According to these trust values, the network can effectively identify malicious peers and isolate them. In this subsection, we further extend the original EigenTrust algorithm to automatically update the certificate credit in our BC-CS system.
To intuitively understand such a procedure of credit self-adjustment, we consider an example where AA initializes the credit c C of a specific certificate C: c C = c INIT , and authorizes a CA to issue it. Suppose that CA awards STUs cannot undertake the job. In addition, we assume that only K EPs pass the data (i.e., {a k ; k = 1, 2, …, K} and {q k ; k = 1, 2, …, K}) back to AA. If the sum of {a k ; k = 1, 2, …, K} is greater than a given threshold T C , AA updates the local trust value between two EPs (say, EP i and EP j ): where | ⋅ | denotes the absolute value of a scalar, and p i and p j represent the percentages of qualified STUs in EP i and EP j , respectively: In (1), s C ∈ (0 1) is a small constant to prevent the denominator from being overly small and, as a result, the value of s i,j from being prohibitively large. According to the definition in (1), if the probabilities p i and p j are almost identical, the local trust value s i,j between EP i and EP j becomes extremely large. It implies that these two EPs trust each other based on their feedback to AA. Otherwise, if the local trust value s i,j is small, either EP i or EP j may be malicious and provides irrational feedback. By normalizing the local trust value s i,j , we can construct a trust matrix V: where v i,j represents the element in the i-th row and j-th column of the matrix V. Let t k represent the global trust value of EP k . Similar to EigenTrust [12] , we calculate the global trust vector t = [t 1 t 2 … t K ] T for all EPs by iteratively evaluating: where t (d) and t (d+1) denote the global trust vectors at the dth and (d+1)-th iteration steps, respectively. Initially, all elements in the global trust vector t (0) are set to 1/K. Next, Eq. (4) is repeatedly evaluated until convergence is reached. Namely, ||t (d+1) -t (d) || 2 is sufficiently small, where ||⋅|| 2 stands for the L 2 norm of a vector.
Once the global trust vector t is determined, we further check all elements in t. If t m takes the maximum value over all elements in t, the corresponding EP m is regarded as the most trustworthy EP [12] . For each EP k (k ∈ {1, 2, …, K}), if |p k -p m | is greater than a given threshold T p , p k is much less than p m and, hence, EP k is recognized as a malicious one. Next, its feedback numbers (i. e., a k and q k ) to AA are reset to 0 in order to avoid any il-legal bias of the certificate credit.
After the aforementioned evaluations for all EPs, AA updates the credit of C as: where P C represents the probability of qualified STUs: and T 1 and T 2 are two pre-defined positive thresholds. Furthermore, to encourage EPs providing feedback, once the number of feedback provided by EP k , denoted as N F,k , exceeds a pre-defined positive integer T F , AA rewards EP k and then resets N F,k to zero. In addition, the numbers of feedback are set to zero for all malicious EPs recognized by the global trust vector t. Algorithm 1 summerizes the major steps of the proposed credit self-adjustment algorithm. Note that when CA issues a certificate C to another group of STUs in the future (e.g., next year), we must go to Step 6 to build a new Merkle tree for these newly issued certificates, and the credit is updated to the most recent value of c C . In addition, AA records N F,k (i.e., the number of feedback provided by EP k ). Once EP k provides feedback to AA, AA will increase N F,k by 1, no matter whether the feedback is for C or another type of certificates.
It is important to note that Algorithm 1 may fail to accurately identify the malicious EPs, if there are too many of them in the system and their corresponding p i are similar. In this case, the local trust values between malicious EPs may be extremely large. As a result, the global trust values of the malicious EPs are large and these malicious EPs are consequently recognized as trusted ones incorrectly.
Algorithm 1: Credit Self-Adjustment 1. Starts from a specific certificate C with initial credit c INIT , two pre-defined positive integers T C and T F , and three pre-defined positive thresholds T 1 , T 2 and T p (where 0 < T 1 < T 2 < 1 and 0 < T p < 1).
3. AA accredits CA to issue the certificate C. 4. AA initializes the credit c C = c INIT for the certificate C.
5. CA issues the certificate C with the credit c C to a group of N STUs: {STU n ; n = 1, 2, …, N}.
6. CA generates a single Merkle tree for the issued certificates and saves the root hash in its smart contract. 7. FOR k = 1, 2, …, K 8. EP k collects the number of its hired STUs (i. e., a k ) and the number of qualified STUs (i. e., q k ), and passes the data back to AA.
9. If N F,k < T F , AA sets N F,k = N F,k + 1. Otherwise, AA rewards EP k and resets N F,k = 0.
10. END 11. If the sum of {a k ; k = 1, 2, … , K} is greater than T C 12. AA calculates the local trust values based on (1) and the trust matrix V according to (3). 13. Initialize all elements in the global trust vector t to 1/K.
14. Repeat (4) to update t until convergence is reached.
15. Find out the largest value t m among all elements in the vector t.
16. FOR k = 1, 2, …, K 17. If |p k -p m | > T p , set q k = a k = N F,k = 0. 18. END 19. AA calculates the probability P C based on (6) and updates the credit c C according to (5).
20. END 21. If CA issues the certificate C with the credit c C to a new group of STUs in the future, go to Step 6.

Implementation and Analysis
Based on the aforementioned discussions, we develop a decentralized application (DApp) prototype for our proposed BC-CS system on Ropsten testnet [13] , which is a test network running the same protocol as Ethereum. It is used for testing purposes before BC-CS is deployed over the main network. Swarm Gateway [14] is adopted to store certificates and generate hash values. It offers the service allowing users to share and access files on the Swarm network. Most user behaviors, corresponding to different steps in Algorithm 1, are implemented with smart contracts. In addition, we use MetaMask [15] to interact between the frontend interface and the backend smart contracts.
To estimate the cost of running our system, we set c INIT = 10, T C = 900, T F = 3, T 1 = 0.8, T 2 = 0.95, T p = 0.3 and s C = 0.05 as an example. Our prototype is composed of 1 AA, 1 CA, 12 EPs (i.e., M = 12) and 1 200 STUs (i. e., N = 1 200). Table 1 lists the gas consumptions for several key functions in the smart contracts of AA and CA, where gas refers to the fee required to execute a transac-tion on Ethereum.
In both AA and CA, "Constructor" initializes the variables in the smart contract. It is executed once whenever the smart contract is deployed. In AA, "Accred-itCA" authorizes CA to issue certificates and initializes the certificate credits (i. e., Step 3-4 in Algorithm 1). "Feedback" collects feedback from EPs (i. e., Step 7-10 in Algorithm 1). In our example, we assume that 10 EPs (i. e., {EP k ; k = 1, 2, … , 10}) provide feedback to AA. The average gas consumption to collect information from each EP is 113 114 and, hence, the total gas consumption for "Feedback" is 113 114 × 10 = 1 131 140.
Next, as shown in Table 2, we assume that the numbers (i. e., {a k ; k = 1, 2, … , 10}) of STUs employed by EPs are set to random numbers between 100 and 200. Consequently, the sum of {a k ; k = 1, 2, …, 10} is greater than T C . Table 2 lists the number of qualified STUs (i.e., {q k ; k = 1, 2, …, 10}) for each EP. Furthermore, EP 1 and EP 10 are assumed to be malicious (i. e., q 1 and q 10 are much less than the other q k ). We run "ModifiedET" (i.e., Step 11-18 in Algorithm 1) to calculate the global trust values for all EPs (i.e., t k in Table 2). According to Table  2, EP 5 is selected as the most trustworthy EP because t 5 takes the maximum global trust value. Since |p 1 -p 5 | > T p and |p 10 -p 5 | > T p , EP 1 and EP 10 are correctly recognized as malicious EPs, and we set a 1 , q 1 , a 10 and q 10 to 0 (i.e., Step 16-18 in Algorithm 1). Afterwards, we run "Update" to update the credit of the certificate (i.e., Step 19-20 in Algorithm 1).
In CA, "IssueCert" is used to issue certificates to STUs and save the root hash of the Merkle tree (i. e., Step 5-6 in Algorithm 1). In addition, since EPs and STUs do not directly change the data in the blockchain, there is no smart contract deployed for them. According to Table 1, the gas consumption of a "Constructor" is substantially greater than that of any other function. Such an observation has two important implications. First, once the smart contract is deployed, other operations can be inexpensively performed with low cost. Second, since we only need to run "Constructor" once to initialize the system, the significant overhead associated with initialization is often affordable.

Conclusion
In this paper, we propose a novel BC-CS system to automatically adjust the credits for different certificates. BC-CS involves four groups of users: AAs, CAs, STUs and EPs. AAs authorize CAs to issue certificates to STUs. EP hires the STUs carrying different certificates and provides feedback to AA according to their performances. Based on the feedback, AA automatically adjusts the credits of different certificates. To verify the feasibility of BC-CS, we develop a DApp prototype by using Ropsten testnet and Swarm Gateway.