Open Access
Wuhan Univ. J. Nat. Sci.
Volume 28, Number 2, April 2023
Page(s) 163 - 168
Published online 23 May 2023

© Wuhan University 2023

Licence Creative CommonsThis is an Open Access article distributed under the terms of the Creative Commons Attribution License (, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

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.

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

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

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

thumbnail 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 cC of a specific certificate C: cC = cINIT, 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 cINIT.

Next, these N STUs are hired by M EPs, denoted as {EPm; m = 1, 2, …, M}, while the m-th EP (i.e., EPm) hires am (where 0 ≤ amN) STUs. After a period of time, EPm finds that only qm ( ≤ am) STUs among am candidates carry the skillset claimed by C, while the other am - qm STUs cannot undertake the job. In addition, we assume that only K EPs pass the data (i.e., {ak; k = 1, 2, …, K} and {qk; k = 1, 2, …, K}) back to AA. If the sum of {ak; k = 1, 2, …, K} is greater than a given threshold TC, AA updates the local trust value between two EPs (say, EPi and EPj):


where |⋅| denotes the absolute value of a scalar, and pi and pj represent the percentages of qualified STUs in EPi and EPj, respectively:


In (1), sC ∈ (0 1) is a small constant to prevent the denominator from being overly small and, as a result, the value of si,j from being prohibitively large. According to the definition in (1), if the probabilities pi and pj are almost identical, the local trust value si,j between EPi and EPj becomes extremely large. It implies that these two EPs trust each other based on their feedback to AA. Otherwise, if the local trust value si,j is small, either EPi or EPj may be malicious and provides irrational feedback. By normalizing the local trust value si,j, we can construct a trust matrix V:


where vi,j represents the element in the i-th row and j-th column of the matrix V.

Let tk represent the global trust value of EPk. Similar to EigenTrust[12], we calculate the global trust vector t = [t1t2tK]T for all EPs by iteratively evaluating:


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(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 L2 norm of a vector.

Once the global trust vector t is determined, we further check all elements in t. If tm takes the maximum value over all elements in t, the corresponding EPm is regarded as the most trustworthy EP[12]. For each EPk (k ∈ {1, 2, …, K}), if |pkpm| is greater than a given threshold Tp, pk is much less than pm and, hence, EPk is recognized as a malicious one. Next, its feedback numbers (i.e., ak and qk) 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:


where PC represents the probability of qualified STUs:


and T1 and T2 are two pre-defined positive thresholds. Furthermore, to encourage EPs providing feedback, once the number of feedback provided by EPk, denoted as NF,k, exceeds a pre-defined positive integer TF, AA rewards EPk and then resets NF,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 cC. In addition, AA records NF,k (i.e., the number of feedback provided by EPk). Once EPk provides feedback to AA, AA will increase NF,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 pi 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 cINIT, two pre-defined positive integers TC and TF, and three pre-defined positive thresholds T1, T2 and Tp (where 0 < T1 < T2 < 1 and 0 < Tp < 1).

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

3. AA accredits CA to issue the certificate C.

4. AA initializes the credit cC = cINIT for the certificate C.

5. CA issues the certificate C with the credit cC to a group of N STUs: {STUn; 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. EPk collects the number of its hired STUs (i.e., ak) and the number of qualified STUs (i.e., qk), and passes the data back to AA.

9. If NF,k < TF, AA sets NF,k = NF,k + 1. Otherwise, AA rewards EPk and resets NF,k = 0.

10. END

11. If the sum of {ak; k = 1, 2, …, K} is greater than TC

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 tm among all elements in the vector t.

16. FOR k = 1, 2, …, K

17. If |pkpm| > Tp, set qk = ak = NF,k = 0.

18. END

19. AA calculates the probability PC based on (6) and updates the credit cC according to (5).

20. END

21. If CA issues the certificate C with the credit cC 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 cINIT = 10, TC = 900, TF = 3, T1 = 0.8, T2 = 0.95, Tp = 0.3 and sC = 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., {EPk; 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., {ak; k = 1, 2, …, 10}) of STUs employed by EPs are set to random numbers between 100 and 200. Consequently, the sum of {ak; k = 1, 2, …, 10} is greater than TC. Table 2 lists the number of qualified STUs (i.e., {qk; k = 1, 2, …, 10}) for each EP. Furthermore, EP1 and EP10 are assumed to be malicious (i.e., q1 and q10 are much less than the other qk). We run "ModifiedET" (i.e., Step 11-18 in Algorithm 1) to calculate the global trust values for all EPs (i.e., tk in Table 2). According to Table 2, EP5 is selected as the most trustworthy EP because t5 takes the maximum global trust value. Since |p1p5| > Tp and |p10p5| > Tp, EP1 and EP10 are correctly recognized as malicious EPs, and we set a1, q1, a10 and q10 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.

Table 1

Gas consumptions for key functions in smart contracts

Table 2

Trust values of 10 EPs

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.


  1. Fedorova E P, Skobleva E I. Application of blockchain technology in higher education[J]. European Journal of Contemporary Education, 2020, 9(3): 552-571. [Google Scholar]
  2. Grech A, Camilleri A F. Blockchain in Education[M]. Luxembourg: Publications Office of the European Union, 2017. [Google Scholar]
  3. Credentials Hyland.Blockcerts — The open standard for blockchain certificates[EB/OL].[2021-12-20]. [Google Scholar]
  4. Cheng J C, Lee N Y, Chi C E, et al. Blockchain and smart contract for digital certificate[C]//2018 IEEE International Conference on Applied System Invention (ICASI). New York: IEEE, 2018: 1046-1051. [Google Scholar]
  5. Budhiraja S, Rani R. TUDocChain-securing academic certificate digitally on blockchain[C]//Inventive Computation Technologies. Cham: Springer International Publishing, 2019: 150-160. [Google Scholar]
  6. Xu Y Q, Zhao S L, Kong L J, et al. ECBC: A high performance educational certificate blockchain with efficient query[C]//Theoretical Aspects of Computing — ICTAC 2017. Cham: Springer International Publishing, 2017: 288-304. [Google Scholar]
  7. Sporny M, Longley D , Chadwick D. Verificable credentials data model[EB/OL].[2022-09-12]. [Google Scholar]
  8. Kumar K, Sofat S, Jain S K, et al. Significance of hash value generation in digital forensic: A case study[J]. International Journal of Engineering Research and Development, 2012, 2(5): 64-70. [Google Scholar]
  9. Buterin V. A next-generation smart contract and decentralized application platform[EB/OL].[2022-06-12]. [Google Scholar]
  10. Trón V. The book of Swarm[EB/OL].[2022-09-12]. [Google Scholar]
  11. Merkle R C. A digital signature based on a conventional encryption function[C]//CRYPTO '87: A Conference on the Theory and Applications of Cryptographic Techniques on Advances in Cryptology. New York: ACM, 1987: 369-378. [Google Scholar]
  12. Kamvar S D, Schlosser M T, Garcia-Molina H. The Eigentrust algorithm for reputation management in P2P networks[C]//Proceedings of the 12th International Conference on World Wide Web. New York: ACM, 2003: 640-651. [Google Scholar]
  13. Foundation Ethereum. Ropsten Testnet[EB/OL]. [2022-02-10]. [Google Scholar]
  14. Foundation Swarm. Swarm Gateway: The easiest way to share & access files on the Swarm network[EB/OL]. [2022-02-10]. [Google Scholar]
  15. MetaMask. MetaMask: Brings Ethereum to your browser[EB/OL]. [2022-02-10]. [Google Scholar]

All Tables

Table 1

Gas consumptions for key functions in smart contracts

Table 2

Trust values of 10 EPs

All Figures

thumbnail Fig. 1

Block diagram of the proposed BC-CS system

In the text
thumbnail Fig. 2

Workflow of certificate issuance

In the text
thumbnail Fig. 3

Workflow of certificate verification

In the text
thumbnail Fig. 4

Workflow of credit self-adjustment based on EigenTrust

In the text

Current usage metrics show cumulative count of Article Views (full-text article views including HTML views, PDF and ePub downloads, according to the available data) and Abstracts Views on Vision4Press platform.

Data correspond to usage on the plateform after 2015. The current usage metrics is available 48-96 hours after online publication and is updated daily on week days.

Initial download of the metrics may take a while.