© Wuhan University 2023

0 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], TUDocChain^[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 certificatecredit 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

1.1 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.

Fig. 1 Block diagram of the proposed BC-CS system

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.

1.2 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.

Fig. 2 Workflow of certificate issuance

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.

Fig. 3 Workflow of certificate verification

1.3 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.

Fig. 4 Workflow of credit self-adjustment based on EigenTrust

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 C to N STUs this year and generates a Merkle tree for these N certificates. The credits of all N certificates are equal to c_INIT.

Next, these N STUs are hired by M EPs, denoted as {EP_m; m = 1, 2, …, M}, while the m-th EP (i.e., EP_m) hires a_m (where 0 ≤ a_m ≤ N) STUs. After a period of time, EP_m finds that only q_m ( ≤ a_m) STUs among a_m candidates carry the skillset claimed by C, while the other a_m - q_m 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):

$s_{i,j}=\{\begin{array}{ll}\frac{\mathrm{1}}{\left|p_i-p_j\right|+s_C},& \mathrm{i}\mathrm{f}i\ne j\\ \mathrm{0},& \mathrm{i}\mathrm{f}i=j\end{array}$(1)

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:

$\begin{array}{l}{p}_i=q_i/a_i\\ p_j=q_j/a_j\end{array}$(2)

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:

$v_{i,j}= \frac{s_{i,j}}{{\sum }_j{s}_{i,j}}$(3)

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₁t₂ … t_K]^T for all EPs by iteratively evaluating:

${\mathit{t}}^{\left(d+\mathrm{1}\right)}={\mathit{V}}^{\mathrm{T}}\cdot {\mathit{t}}^{\left(d\right)}$(4)

where t^(d) and t^(d+1) denote the global trust vectors at the d-th and (d+1)-th iteration steps, respectively. Initially, all elements in the global trust vector t⁽⁰⁾ are set to 1/K. Next, Eq. (4) is repeatedly evaluated until convergence is reached. Namely, ||t^(d+1) - t^(d)||₂ is sufficiently small, where ||⋅||₂ stands for the L₂ 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 illegal bias of the certificate credit.

After the aforementioned evaluations for all EPs, AA updates the credit of C as:

$c_C=\{\begin{array}{ll}{c}_C+\mathrm{1},& \mathrm{i}\mathrm{f}{P}_C\ge T_{\mathrm{1}}\\ \begin{array}{l}{c}_C,\\ c_C-\mathrm{1},\end{array}& \begin{array}{l}\mathrm{i}\mathrm{f}{T}_{\mathrm{2}}\le P_C<T_{\mathrm{1}}\\ \mathrm{i}\mathrm{f}{P}_C<T_{\mathrm{2}}\end{array}\end{array}$(5)

where P_C represents the probability of qualified STUs:

$P_C={\displaystyle \sum _{k=\mathrm{1}}^K}{q}_k/{\displaystyle \sum _{k=\mathrm{1}}^K}{a}_k$(6)

and T₁ and T₂ 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₁, T₂ and T_p (where 0 < T₁ < T₂ < 1 and 0 < T_p < 1).

2. AA initializes the number of feedback for all EPs: N_F,m = 0 where m ∈ {1, 2, …, M}.

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.

2 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₁ = 0.8, T₂ = 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 transaction 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, "AccreditCA" 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₁ and EP₁₀ are assumed to be malicious (i.e., q₁ and q₁₀ 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₅ is selected as the most trustworthy EP because t₅ takes the maximum global trust value. Since |p₁ – p₅| > T_p and |p₁₀ – p₅| > T_p, EP₁ and EP₁₀ are correctly recognized as malicious EPs, and we set a₁, q₁, a₁₀ and q₁₀ 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.

3 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.

References

All Tables

All Figures

	Fig. 1 Block diagram of the proposed BC-CS system
In the text

	Fig. 2 Workflow of certificate issuance
In the text

	Fig. 3 Workflow of certificate verification
In the text

	Fig. 4 Workflow of credit self-adjustment based on EigenTrust
In the text