Issue 
Wuhan Univ. J. Nat. Sci.
Volume 28, Number 2, April 2023



Page(s)  163  168  
DOI  https://doi.org/10.1051/wujns/2023282163  
Published online  23 May 2023 
Computer Science
CLC number: TP 311.13
A BlockchainBased Certificate System with Credit SelfAdjustment
^{1}
School of Electronic Information, Wuhan University, Wuhan 430072, Hubei, China
^{2}
State Key Lab of ASIC and System, School of Microelectronics, Fudan University, Shanghai 200433, China
^{3}
Data Science Research Center, Duke Kunshan University, Kunshan 215316, Jiangsu, China
^{†} To whom correspondence should be addressed. Email: xinli.ece@dukekunshan.edu.cn
Received:
20
November
2022
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 blockchainbased system with credit selfadjustment (BCCS). In BCCS, employers can provide feedback according to the performances of their employees (i.e., students) holding different certificates. Based on the feedback, BCCS automatically adjusts the certificate credits by using our proposed credit selfadjustment algorithm. To verify the feasibility of our proposed system, a decentralized application prototype has been developed on an Ethereum network. Experimental results demonstrate that the proposed system can fully support multistep accreditation and automatic adjustment for certificate credit.
Key words: blockchain / certificate / credit selfadjustment
Biography: ZHOU Wang, male, Master candidate, research direction: block chain. Email: 2016301200314@whu.edu.cn
© Wuhan University 2023
This is an Open Access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0), 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 blockchainbased 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 welldefined 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 blockchainbased certificate system with credit selfadjustment (BCCS) 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 multistep accreditation. In summary, the proposed BCCS 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 selfadjustment 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 BCCS 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 BCCS 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 thirdparty 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., SHA256). 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 BCCS system 
In the proposed BCCS system, we extend the W3C VC specification along two complementary avenues. First, we introduce AA to authorize CA for certificate issuance. Hence, BCCS supports multistep accreditation by verifying both the validity of the credential and the legality of the issuer. Second, BCCS 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 BCCS system supports multistep 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 SelfAdjustment
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 selfadjustment 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 BCCS system.
Fig. 4 Workflow of credit selfadjustment based on EigenTrust 
To intuitively understand such a procedure of credit selfadjustment, 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 mth 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}\text{}i\ne j\\ \mathrm{0}\text{},& \mathrm{i}\mathrm{f}\text{}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}=\u200a\frac{{s}_{i,j}}{{\sum}_{j}{s}_{i,j}}\text{}$(3)
where v_{i}_{,}_{j} represents the element in the ith row and jth 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:
${\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 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 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}\text{}{P}_{C}\ge {T}_{\mathrm{1}}\\ \begin{array}{l}{c}_{C},\\ {c}_{C}\mathrm{1},\end{array}& \begin{array}{l}\mathrm{i}\mathrm{f}\text{}{T}_{\mathrm{2}}\le {P}_{C}{T}_{\mathrm{1}}\\ \mathrm{i}\mathrm{f}\text{}{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_{1} and T_{2} are two predefined positive thresholds. Furthermore, to encourage EPs providing feedback, once the number of feedback provided by EP_{k}, denoted as N_{F}_{,}_{k}, exceeds a predefined 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 selfadjustment 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 SelfAdjustment
1. Starts from a specific certificate C with initial credit c_{INIT}, two predefined positive integers T_{C} and T_{F}, and three predefined positive thresholds T_{1}, T_{2} and T_{p} (where 0 < T_{1} < T_{2} < 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 BCCS system on Ropsten testnet^{[13]}, which is a test network running the same protocol as Ethereum. It is used for testing purposes before BCCS 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 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 34 in Algorithm 1). "Feedback" collects feedback from EPs (i.e., Step 710 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 1118 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 1618 in Algorithm 1). Afterwards, we run "Update" to update the credit of the certificate (i.e., Step 1920 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 56 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.
Gas consumptions for key functions in smart contracts
Trust values of 10 EPs
3 Conclusion
In this paper, we propose a novel BCCS system to automatically adjust the credits for different certificates. BCCS 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 BCCS, we develop a DApp prototype by using Ropsten testnet and Swarm Gateway.
References
 Fedorova E P, Skobleva E I. Application of blockchain technology in higher education[J]. European Journal of Contemporary Education, 2020, 9(3): 552571. [Google Scholar]
 Grech A, Camilleri A F. Blockchain in Education[M]. Luxembourg: Publications Office of the European Union, 2017. [Google Scholar]
 Credentials Hyland.Blockcerts — The open standard for blockchain certificates[EB/OL].[20211220]. https://www.blockcerts.org. [Google Scholar]
 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: 10461051. [Google Scholar]
 Budhiraja S, Rani R. TUDocChainsecuring academic certificate digitally on blockchain[C]//Inventive Computation Technologies. Cham: Springer International Publishing, 2019: 150160. [Google Scholar]
 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: 288304. [Google Scholar]
 Sporny M, Longley D , Chadwick D. Verificable credentials data model[EB/OL].[20220912]. https://www.w3.org/TR/vcdatamodel/#dfnevidence. [Google Scholar]
 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): 6470. [Google Scholar]
 Buterin V. A nextgeneration smart contract and decentralized application platform[EB/OL].[20220612]. https://ethereum.org/en/whitepaper. [Google Scholar]
 Trón V. The book of Swarm[EB/OL].[20220912]. https://docs.ethswarm.org/thebookofswarm.pdf. [Google Scholar]
 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: 369378. [Google Scholar]
 Kamvar S D, Schlosser M T, GarciaMolina 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: 640651. [Google Scholar]
 Foundation Ethereum. Ropsten Testnet[EB/OL]. [20220210]. https://ropsten.etherscan.io. [Google Scholar]
 Foundation Swarm. Swarm Gateway: The easiest way to share & access files on the Swarm network[EB/OL]. [20220210]. https://gateway.ethswarm.org. [Google Scholar]
 MetaMask. MetaMask: Brings Ethereum to your browser[EB/OL]. [20220210]. https://medium.com/metamask. [Google Scholar]
All Tables
All Figures
Fig. 1 Block diagram of the proposed BCCS 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 selfadjustment based on EigenTrust 

In the text 
Current usage metrics show cumulative count of Article Views (fulltext 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 4896 hours after online publication and is updated daily on week days.
Initial download of the metrics may take a while.