# Based on Consortium Blockchain to Design a Credit Verifiable Cross University Course Learning System

Authors: Chin-Ling Chen; Tianyi Wang; Woei-Jiunn Tsaur; Wei Weng; Yong-Yuan Deng; Jianfeng Cui
Journal: Security and Communication Networks
 (2021)

---

## Abstract

In recent years, the attention of online cross-university courses has been increasing, and students in universities want to increase their knowledge and professional skills by taking online courses from different universities, which raises the issue of course credit verification. In the past, the credits obtained by students in online courses lack endorsement from the education department, and the students’ learning process could not be verified. Therefore, the credits of online courses in one university could not be recognized by other universities. The education departments of some countries and regions implement credit conversion rules to convert the credits obtained by students in online courses into university credits or certificates endorsed by the education department. However, these schemes rely too much on the authority of the education department, and the process of students obtaining credits cannot be verified. In addition, the centralized storage method makes the data of education departments at risk of leakage or tampering. With the emergence of blockchain technology, some researchers have proposed the use of blockchain to store students’ credits, making it possible to reach consensus among multiple parties on the blockchain while ensuring that credits are not tampered with, but these schemes cannot test the learning process of students and the recognition of credits still relies on the authority of the education department. To solve the above problems, this paper proposes a cross-university course learning system with verifiable credits based on Hyperledger Fabric consortium blockchain technology, and the consortium includes many universities. The credits obtained by students in the course and the hash value of the learning records are stored on the blockchain, and the data on the blockchain is jointly maintained by the universities in the system. One university can verify the homework and final examination of students to check the real ability of students, thus recognizing the credits from other universities, and at the same time, to protect the privacy of students, the important data of students are encrypted for transmission.


---

## Body

## 1. Introduction

### 1.1. Background

Education is a way for students to improve themselves, and higher education is directly related to students’ development direction and employment prospects. Students want to learn more courses in their universities, or even take courses across universities, to expand their knowledge and skills. Currently, cross-university online courses are popular among students, and students can take courses from different universities online through the Internet. Especially in 2020, when the outbreak of COVID-19 spread worldwide and almost all universities around the world stopped offline courses, online courses ensured the sustainability of education [1]. By April 2021, Udemy, an American online learning platform, has more than 40 million learners [2]. From September 2020 to July 2021, learners in just one country completed more than 140,000 courses on the Coursera platform of the United States [3]. However, there are limitations to cross-university online courses. Students can acquire more knowledge and skills through cross-university courses, but they lack simple and efficient ways to prove their ability. For a university who offers courses to students from other universities, it promotes the dissemination of professional knowledge and the reputation of the university, and the grades of students’ online courses can be used as part of the entrance examination scores. Unfortunately, when it comes to the online courses from other universities, it is difficult for the university to recognize the grades even if students perform well. For teachers, by offering courses for online learning, they can show their research directions and attract more students to engage in research in related fields, but it becomes a challenge to check students’ course learning outcomes because teachers do not know the capabilities of these students.With the increase in the number of cross-university course learners, more and more students want to obtain credits for online courses as their learning credentials for further education or employment, and receiving credits or certificates means that the grades of online courses are recognized by the universities to which the courses belong. Indian Institute of Management (IIM-Kozhikode) announces partnership with Coursera to launch course certificates in business, strategy, marketing, and product management [4]. However, there exists a recognition problem with the credits obtained by taking courses across universities. The credits of online courses are jointly awarded by the learning platform and the university, lacking the verification of authoritative institutions. Although online courses are created by universities, it is difficult for the two universities to reach a consensus on the course content and learners’ ability. Therefore, after completing the online course, the credits obtained by students in one university cannot be recognized by other universities.To solve the problems of credit recognition, the European Credit Transfer and Accumulation System (ECTS) [5] helps students transfer credits between universities. In this system, the credits obtained by students in their universities can be converted into a certain number of ECTS credits, and if a student wants to transfer to another university, the ECTS credits of the student will be converted into the credits of the target university. Moreover, the Credit Bank System (CBS) [6] in Korea allows students to convert their learning achievements into credits and then convert credits into higher education degrees. However, the above schemes have some problems: Firstly, they rely on the management of the central educational institution, and it is because of the authority of the central educational institution that the credits in the system can be recognized. Secondly, the credit conversion rules lack verification for the learning process of students. Although the credit is recognized by all universities in the system, it does not fully reflect the student’s ability. Finally, since the system data are stored in a centralized way, there is a risk of data loss or tampering.The emergence of blockchain technology [7] has provided a new way to solve the credit verification problem [8]. The blockchain can be regarded as a distributed database where the data is tamper-evident, traceable [9–11], maintained by multiple parties, and can reach a consensus among multiple parties [12]. This paper proposes a decentralized cross-university course learning system based on consortium blockchain technology, where the consortium includes many universities. For students, they can take courses from any university in the system and get credits. The hash values of students’ homework and final examinations are stored on the blockchain, and the data on the blockchain is maintained by all universities in the system. Since each university manages its teachers and students, the data on the blockchain can reach a consensus among all universities, teachers, and students without relying on a central institution, and one university recognizes course credits obtained by students from other universities by verifying students’ homework and final examination.


### 1.2. Related Works

Currently, research in the education field focuses on storing students’ credits, certificates, and learning records via blockchain technology and using distributed storage technology and cryptography to ensure that the data on the blockchain is tamper-evident, thus facilitating the sharing of data among multiple parties. The related works are listed in Table1.Table 1
The related works survey.
AuthorsYearObjectiveTechnologiesMeritsDemeritsSharples et al. [13]2016A distributed system for the educational record, reputation, and rewardBlockchainRealize distributed storage of student-related dataNo system architecture is proposedTurkanović et al. [14]2018Higher education credit platformPublic blockchainStudent credits can be awarded and transferredStudents’ learning process cannot be checkedZhao et al. [15]2020System for student e-portfolio assessmentConsortium blockchainRealize storage of students’ learning records and teachers’ evaluationSecurity analysis is not sufficientMishra et al. [16]2021System for sharing students’ credentialsEthereumStudent certificates are encrypted before being uploaded to the systemConsumption of tokens is inevitableJeong et al. [17]2021The multilateral personal portfolio authentication systemHyperledger fabricDetailed system implementation based on hyperledger fabricUnable to protect the privacy of learning recordsIn 2016, Sharples and Domingue [13] proposed to use blockchain to store students’ learning processes and achievements, thus enabling distributed storage of student-related data, but this paper did not introduce the system architecture.In 2018, Turkanović et al. [14] proposed a blockchain education credit platform named EduCTX where educational institutions can award students credits that can be checked by third parties and students can transfer credits between different educational institutions. Unfortunately, this system can only check whether a student has obtained credits and has no way to verify the student’s learning process.In 2020, Zhao et al. [15] proposed a student portfolio management system that stores students’ learning records and teachers’ evaluations of students through blockchain technology. However, teachers’ evaluations are subjective and cannot objectively reflect students’ abilities. In addition, the article failed to provide a method to protect the privacy of students’ learning records.In 2021, Mishra et al. [16] proposed an Ethereum-based student credential sharing system, where universities encrypt the students’ credentials before uploading them to the blockchain, and if a third party wants to check students’ credentials, the students encrypt credentials before sending them to protect their privacy. Considering that students may not be able to afford the gas in Ethereum, the system has set up a fund organization to provide financial support for system members.Based on the above research, it can be found that the recognition of students’ credits still relies on authority and the process of obtaining credits cannot be verified. Therefore, this paper proposed a cross-university course learning system with credits verifiable, where a student needs to complete homework and final examination to obtain credit from the university, and other universities can verify the student’s homework and final examination to recognize the credit. This system encrypts students’ homework and final examinations, thus effectively protecting students' privacy. Moreover, the system adopts consortium blockchain architecture with no token consumption, which improves operational efficiency compared to public blockchain architecture.The remainder of this paper is organized as follows: Section2 briefly introduces the preliminary. Section 3 shows the proposed system structure and an application scenario. The paper gives the security and feature analysis in Section 4 and presents the discussion in Section 5. Finally, Section 6 concludes this paper.


## 1.1. Background

Education is a way for students to improve themselves, and higher education is directly related to students’ development direction and employment prospects. Students want to learn more courses in their universities, or even take courses across universities, to expand their knowledge and skills. Currently, cross-university online courses are popular among students, and students can take courses from different universities online through the Internet. Especially in 2020, when the outbreak of COVID-19 spread worldwide and almost all universities around the world stopped offline courses, online courses ensured the sustainability of education [1]. By April 2021, Udemy, an American online learning platform, has more than 40 million learners [2]. From September 2020 to July 2021, learners in just one country completed more than 140,000 courses on the Coursera platform of the United States [3]. However, there are limitations to cross-university online courses. Students can acquire more knowledge and skills through cross-university courses, but they lack simple and efficient ways to prove their ability. For a university who offers courses to students from other universities, it promotes the dissemination of professional knowledge and the reputation of the university, and the grades of students’ online courses can be used as part of the entrance examination scores. Unfortunately, when it comes to the online courses from other universities, it is difficult for the university to recognize the grades even if students perform well. For teachers, by offering courses for online learning, they can show their research directions and attract more students to engage in research in related fields, but it becomes a challenge to check students’ course learning outcomes because teachers do not know the capabilities of these students.With the increase in the number of cross-university course learners, more and more students want to obtain credits for online courses as their learning credentials for further education or employment, and receiving credits or certificates means that the grades of online courses are recognized by the universities to which the courses belong. Indian Institute of Management (IIM-Kozhikode) announces partnership with Coursera to launch course certificates in business, strategy, marketing, and product management [4]. However, there exists a recognition problem with the credits obtained by taking courses across universities. The credits of online courses are jointly awarded by the learning platform and the university, lacking the verification of authoritative institutions. Although online courses are created by universities, it is difficult for the two universities to reach a consensus on the course content and learners’ ability. Therefore, after completing the online course, the credits obtained by students in one university cannot be recognized by other universities.To solve the problems of credit recognition, the European Credit Transfer and Accumulation System (ECTS) [5] helps students transfer credits between universities. In this system, the credits obtained by students in their universities can be converted into a certain number of ECTS credits, and if a student wants to transfer to another university, the ECTS credits of the student will be converted into the credits of the target university. Moreover, the Credit Bank System (CBS) [6] in Korea allows students to convert their learning achievements into credits and then convert credits into higher education degrees. However, the above schemes have some problems: Firstly, they rely on the management of the central educational institution, and it is because of the authority of the central educational institution that the credits in the system can be recognized. Secondly, the credit conversion rules lack verification for the learning process of students. Although the credit is recognized by all universities in the system, it does not fully reflect the student’s ability. Finally, since the system data are stored in a centralized way, there is a risk of data loss or tampering.The emergence of blockchain technology [7] has provided a new way to solve the credit verification problem [8]. The blockchain can be regarded as a distributed database where the data is tamper-evident, traceable [9–11], maintained by multiple parties, and can reach a consensus among multiple parties [12]. This paper proposes a decentralized cross-university course learning system based on consortium blockchain technology, where the consortium includes many universities. For students, they can take courses from any university in the system and get credits. The hash values of students’ homework and final examinations are stored on the blockchain, and the data on the blockchain is maintained by all universities in the system. Since each university manages its teachers and students, the data on the blockchain can reach a consensus among all universities, teachers, and students without relying on a central institution, and one university recognizes course credits obtained by students from other universities by verifying students’ homework and final examination.


## 1.2. Related Works

Currently, research in the education field focuses on storing students’ credits, certificates, and learning records via blockchain technology and using distributed storage technology and cryptography to ensure that the data on the blockchain is tamper-evident, thus facilitating the sharing of data among multiple parties. The related works are listed in Table1.Table 1
The related works survey.
AuthorsYearObjectiveTechnologiesMeritsDemeritsSharples et al. [13]2016A distributed system for the educational record, reputation, and rewardBlockchainRealize distributed storage of student-related dataNo system architecture is proposedTurkanović et al. [14]2018Higher education credit platformPublic blockchainStudent credits can be awarded and transferredStudents’ learning process cannot be checkedZhao et al. [15]2020System for student e-portfolio assessmentConsortium blockchainRealize storage of students’ learning records and teachers’ evaluationSecurity analysis is not sufficientMishra et al. [16]2021System for sharing students’ credentialsEthereumStudent certificates are encrypted before being uploaded to the systemConsumption of tokens is inevitableJeong et al. [17]2021The multilateral personal portfolio authentication systemHyperledger fabricDetailed system implementation based on hyperledger fabricUnable to protect the privacy of learning recordsIn 2016, Sharples and Domingue [13] proposed to use blockchain to store students’ learning processes and achievements, thus enabling distributed storage of student-related data, but this paper did not introduce the system architecture.In 2018, Turkanović et al. [14] proposed a blockchain education credit platform named EduCTX where educational institutions can award students credits that can be checked by third parties and students can transfer credits between different educational institutions. Unfortunately, this system can only check whether a student has obtained credits and has no way to verify the student’s learning process.In 2020, Zhao et al. [15] proposed a student portfolio management system that stores students’ learning records and teachers’ evaluations of students through blockchain technology. However, teachers’ evaluations are subjective and cannot objectively reflect students’ abilities. In addition, the article failed to provide a method to protect the privacy of students’ learning records.In 2021, Mishra et al. [16] proposed an Ethereum-based student credential sharing system, where universities encrypt the students’ credentials before uploading them to the blockchain, and if a third party wants to check students’ credentials, the students encrypt credentials before sending them to protect their privacy. Considering that students may not be able to afford the gas in Ethereum, the system has set up a fund organization to provide financial support for system members.Based on the above research, it can be found that the recognition of students’ credits still relies on authority and the process of obtaining credits cannot be verified. Therefore, this paper proposed a cross-university course learning system with credits verifiable, where a student needs to complete homework and final examination to obtain credit from the university, and other universities can verify the student’s homework and final examination to recognize the credit. This system encrypts students’ homework and final examinations, thus effectively protecting students' privacy. Moreover, the system adopts consortium blockchain architecture with no token consumption, which improves operational efficiency compared to public blockchain architecture.The remainder of this paper is organized as follows: Section2 briefly introduces the preliminary. Section 3 shows the proposed system structure and an application scenario. The paper gives the security and feature analysis in Section 4 and presents the discussion in Section 5. Finally, Section 6 concludes this paper.


## 2. Preliminary

### 2.1. Elliptic Curve Cryptography ECDSA

In the blockchain, elliptic curve cryptography [18] is used for digital signature. If a member A in the system wants to send a message M to a member B, the member A needs to digitally sign the message. The process of the signature algorithm is as follows.


#### 2.1.1. Determine Parameters and Generate Keys

The system will first determine the parametersa and b of the elliptic curve y2=x3+ax+bmodp, the base p, and the origin G, and then the system will generate private keys dA and dB for members A and B, respectively, and generate the public key QA=dAG for the member A.


#### 2.1.2. Generate Signature

MemberA selects a random number k, then calculates H=hashM, x,y=kG, r=xmodp, s=k−1H+rdAmodp, and sends the ECDSA signature pair r,s together with the message M to the member B.


#### 2.1.3. Verify Signature

After receiving the signature pairr,s and the message M, the member B calculates H′=hashM, u=H′s−1modp, v=rs−1modp, x′,y′=uG+vdAG. If x′modp=r, member B confirms that the signature pair r,s and the message M sent by the member A are correct.


### 2.2. Smart Contract

In 1996, Nick Szabo first proposed the concept of the smart contract [19], which digitized contracts in the real world. In a smart contract, both parties will agree on the content of the contract in advance, and the contract will be executed automatically when the conditions are met, without the need for supervision by a third party. Blockchain has the characteristics of nontampering of data and decentralization. The emergence of blockchain technology provides a platform to support the execution of smart contracts, which are jointly executed by the nodes of the whole blockchain network, and the results of their execution become impossible to tamper with after the whole network reaches consensus. Blockchain and smart contract technologies provide new solutions to existing problems in many industries [20], and this paper aims to solve the problem of credit verification across universities.


### 2.3. Hyperledger Fabric

Hyperledger Fabric was proposed by IBM in 2018 [21], which is an open-source blockchain platform and one of the most popular consortium blockchains so far [22]. Unlike public blockchain systems such as Bitcoin and Ethereum, Hyperledger Fabric uses consortium blockchain technology where system members reach a consensus on transactions without consuming tokens. Different from Bitcoin and Ethereum where the data is publicly accessible [23], all members who join the Hyperledger Fabric network need to be authenticated to ensure that unrelated people cannot join the network and get the data on the blockchain. Since the identities of all members in the network are known, the nodes of Hyperledger Fabric do not need to reach a consensus through Proof of Work (POW) [24], and the number of transactions generated in Hyperledger Fabric can reach 3500 per second, which is much higher than 3.5 of Bitcoin and 5.4 of Ethereum [25].In addition to Hyperledger Fabric, there are currently many consortium blockchain platforms in the market, such as Ethereum [26], Corda [27], Quorum [28], and MultiChain [29]. Compared with the above platforms, Hyperledger Fabric has higher throughput and shorter latency [30], and it has wide interest and application in many industries (including finance, IoT, supply chain, manufacturing, and technology) [31]. Therefore, this paper chooses to design a credit verifiable cross-university course learning system based on Hyperledger Fabric.There are mainly the following components in the Hyperledger Fabric network:(1)
Certificate authority (CA): certificate authority provides an identity authentication mechanism for system users. Before a user can interact with the blockchain network, he or she needs to connect to a CA server, which provides the user with identity information as well as the public and private keys.(2)
Orderer: an orderer node collects the endorsed transactions sent by users from client nodes and packages them into blocks, then sends these blocks to the peer nodes.(3)
Peer: peer nodes are divided into endorse peer, leader peer, and anchor peer, where the endorse peer calls chaincode to simulate the execution of a transaction and endorse the transaction, the leader peer broadcasts the block received from the orderer node to all the peer nodes in the organization, and the anchor peer exchange data with other anchor peers between different organizations. All the peer nodes can be considered as committer peers who check each transaction in the received block and update the ledger after the check is completed, and the ledger consists of a blockchain that stores all the transactions and the World State that stores the state data of all the members in the system.(4)
Client: the client node is operated by a system member, which must be connected to one of the peer nodes or orderer nodes to communicate with the blockchain network. Firstly, the client node sends a transaction proposal to the peer in the organization for endorsement. Once the client node has received a sufficient number of signed proposal responses from endorse peers, the client node sends the transaction containing endorsed transaction proposal responses to the orderer node, and the orderer node orders the transactions into blocks.(5)
Channel: channel can achieve isolation of different services and there is only one blockchain in a channel. Users need to get certificates from the CA node firstly, then they can communicate with the peer node or orderer node through the channel.(6)
Organization: organizations represent entities such as enterprises and institutions in the blockchain network. Each organization contains endorse peer, leader peer, and anchor peer that store the ledger, and each member in the system belongs to an organization.(7)
Chaincode: chaincode can be regarded as the smart contract in Hyperledger Fabric, which is written in some language and is deployed on every peer node, and users can achieve query and modification of data on the blockchain by invoking chaincode.


## 2.1. Elliptic Curve Cryptography ECDSA

In the blockchain, elliptic curve cryptography [18] is used for digital signature. If a member A in the system wants to send a message M to a member B, the member A needs to digitally sign the message. The process of the signature algorithm is as follows.


### 2.1.1. Determine Parameters and Generate Keys

The system will first determine the parametersa and b of the elliptic curve y2=x3+ax+bmodp, the base p, and the origin G, and then the system will generate private keys dA and dB for members A and B, respectively, and generate the public key QA=dAG for the member A.


### 2.1.2. Generate Signature

MemberA selects a random number k, then calculates H=hashM, x,y=kG, r=xmodp, s=k−1H+rdAmodp, and sends the ECDSA signature pair r,s together with the message M to the member B.


### 2.1.3. Verify Signature

After receiving the signature pairr,s and the message M, the member B calculates H′=hashM, u=H′s−1modp, v=rs−1modp, x′,y′=uG+vdAG. If x′modp=r, member B confirms that the signature pair r,s and the message M sent by the member A are correct.


## 2.1.1. Determine Parameters and Generate Keys

The system will first determine the parametersa and b of the elliptic curve y2=x3+ax+bmodp, the base p, and the origin G, and then the system will generate private keys dA and dB for members A and B, respectively, and generate the public key QA=dAG for the member A.


## 2.1.2. Generate Signature

MemberA selects a random number k, then calculates H=hashM, x,y=kG, r=xmodp, s=k−1H+rdAmodp, and sends the ECDSA signature pair r,s together with the message M to the member B.


## 2.1.3. Verify Signature

After receiving the signature pairr,s and the message M, the member B calculates H′=hashM, u=H′s−1modp, v=rs−1modp, x′,y′=uG+vdAG. If x′modp=r, member B confirms that the signature pair r,s and the message M sent by the member A are correct.


## 2.2. Smart Contract

In 1996, Nick Szabo first proposed the concept of the smart contract [19], which digitized contracts in the real world. In a smart contract, both parties will agree on the content of the contract in advance, and the contract will be executed automatically when the conditions are met, without the need for supervision by a third party. Blockchain has the characteristics of nontampering of data and decentralization. The emergence of blockchain technology provides a platform to support the execution of smart contracts, which are jointly executed by the nodes of the whole blockchain network, and the results of their execution become impossible to tamper with after the whole network reaches consensus. Blockchain and smart contract technologies provide new solutions to existing problems in many industries [20], and this paper aims to solve the problem of credit verification across universities.


## 2.3. Hyperledger Fabric

Hyperledger Fabric was proposed by IBM in 2018 [21], which is an open-source blockchain platform and one of the most popular consortium blockchains so far [22]. Unlike public blockchain systems such as Bitcoin and Ethereum, Hyperledger Fabric uses consortium blockchain technology where system members reach a consensus on transactions without consuming tokens. Different from Bitcoin and Ethereum where the data is publicly accessible [23], all members who join the Hyperledger Fabric network need to be authenticated to ensure that unrelated people cannot join the network and get the data on the blockchain. Since the identities of all members in the network are known, the nodes of Hyperledger Fabric do not need to reach a consensus through Proof of Work (POW) [24], and the number of transactions generated in Hyperledger Fabric can reach 3500 per second, which is much higher than 3.5 of Bitcoin and 5.4 of Ethereum [25].In addition to Hyperledger Fabric, there are currently many consortium blockchain platforms in the market, such as Ethereum [26], Corda [27], Quorum [28], and MultiChain [29]. Compared with the above platforms, Hyperledger Fabric has higher throughput and shorter latency [30], and it has wide interest and application in many industries (including finance, IoT, supply chain, manufacturing, and technology) [31]. Therefore, this paper chooses to design a credit verifiable cross-university course learning system based on Hyperledger Fabric.There are mainly the following components in the Hyperledger Fabric network:(1)
Certificate authority (CA): certificate authority provides an identity authentication mechanism for system users. Before a user can interact with the blockchain network, he or she needs to connect to a CA server, which provides the user with identity information as well as the public and private keys.(2)
Orderer: an orderer node collects the endorsed transactions sent by users from client nodes and packages them into blocks, then sends these blocks to the peer nodes.(3)
Peer: peer nodes are divided into endorse peer, leader peer, and anchor peer, where the endorse peer calls chaincode to simulate the execution of a transaction and endorse the transaction, the leader peer broadcasts the block received from the orderer node to all the peer nodes in the organization, and the anchor peer exchange data with other anchor peers between different organizations. All the peer nodes can be considered as committer peers who check each transaction in the received block and update the ledger after the check is completed, and the ledger consists of a blockchain that stores all the transactions and the World State that stores the state data of all the members in the system.(4)
Client: the client node is operated by a system member, which must be connected to one of the peer nodes or orderer nodes to communicate with the blockchain network. Firstly, the client node sends a transaction proposal to the peer in the organization for endorsement. Once the client node has received a sufficient number of signed proposal responses from endorse peers, the client node sends the transaction containing endorsed transaction proposal responses to the orderer node, and the orderer node orders the transactions into blocks.(5)
Channel: channel can achieve isolation of different services and there is only one blockchain in a channel. Users need to get certificates from the CA node firstly, then they can communicate with the peer node or orderer node through the channel.(6)
Organization: organizations represent entities such as enterprises and institutions in the blockchain network. Each organization contains endorse peer, leader peer, and anchor peer that store the ledger, and each member in the system belongs to an organization.(7)
Chaincode: chaincode can be regarded as the smart contract in Hyperledger Fabric, which is written in some language and is deployed on every peer node, and users can achieve query and modification of data on the blockchain by invoking chaincode.


## 3. System Model

### 3.1. System Architecture

This research proposed a cross-university course learning system based on Hyperledger Fabric where the consortium includes many universities. The main members of the system include university administrators and users, and users include teachers and students. Teachers, students, and university administrators in the same university form an organization, and each university has administrators to manage its users. The system architecture is shown in Figure1.Figure 1
System structure.The members of the system are described as follows.(1)
Certificate authority (CA): CA nodes provide certificates, public and private keys for users who want to join the system, and each university has its own CA node.(2)
University: a university is managed by university administrators, and there are many teachers and students and some administrators in each university.(3)
University administrator: a university administrator creates the channel, joins the channel with the peers in his or her organization, installs the chaincode on each peer node and initializes the chaincode, reviews the identity of users, and creates system accounts for them, reviews courses created by the teachers and checks students’ grades. By invoking chaincode, administrators add course information to teachers’ accounts, award credits to students, and verify students’ homework and final examinations.(4)
Teacher: teachers apply to their universities for teaching courses and grade students’ homework and final examinations. By invoking chaincode, teachers add course information and grades to students’ accounts.(5)
Students apply to the teachers for learning courses, submit homework and final examinations to the teachers for grades and apply to their universities for course credits. By invoking chaincode, students add the hash values of their homework and final examinations to their accounts.


### 3.2. Application Scenario

Figure2 shows the application scenario where Student A of University A wants to learn Course B of Teacher B who comes from University B, and University C wants to verify the credit obtained by Student A.Step 1: the administrator of a university first creates a channel, then the administrator of each university in the system joins the channel with the peers in his or her organization, installs the chaincode on each peer node, and initializes the chaincode. All users (including teachers and students) need to apply for registration with the administrators of their universities first to obtain a system account.Step 2: Teacher B applies to University B for teaching Course B, which needs to be reviewed by his university. After the course is approved, University B adds the course information to the account of Teacher B by invoking chaincode.Step 3: Student A applies to Teacher B for learning Course B, and Teacher B adds the course information to the account of Student A by invoking chaincode. During the course learning period, Student A needs to upload the hash value of homework and final examination and send them to Teacher B for grading, then Teacher B will upload the grade of Student A by invoking chaincode.Step 4: Student A applies to his university for obtaining the credit of Course B after receiving the grade from Teacher B. By invoking chaincode, University A checks the grade of Student A and awards credit if the grade is qualified.Step 5: Student A wants to transfer from University A to University C, and University C and, therefore, wants to verify the credits of Student A. University C submits the credit verification request to Student A, and Student A sends the homework and final examination to University C. Before reviewing the content of homework and final examination, University C needs to calculate the hash value of the homework and final examination, then compares it with the hash value uploaded by Student A to ensure that the homework and final examination have never been tampered with.Figure 2
Application scenario.


### 3.3. Initial Phase

In the initial phase, the university administrator creates a channel, then installs, and initializes the chaincode for each peer node in the organization.Step 1: the university administrator logs in to the system through an application program, then starts a client node and creates a channel.Step 2: the university administrator connects to each peer node in the organization in turn through the channel, then installs the chaincode on each peer node and initializes the chaincode. The chaincode is shown in Algorithm1.Algorithm 1: Chaincode used for initialization.
(1)
type Chaincode struct {(2)
}(3)
type Teacher struct {(4)
Name string ‘json:”name”’(5)
University string ‘json:”university”’(6)
Course string ‘json:”course”’(7)
}(8)
type Student struct {(9)
Name string ‘json:”name”’(10)
University string ‘json:”university”’(11)
Hash string ‘json:”hash”’(12)
Grade int ‘json:”grade”’(13)
Credit int ‘json:”credit”’(14)
}(15)
func (t∗Chaincode) Init(stub shim.ChaincodeStubInterface) peer.Response {(16)
return shim.Success(nil)(17)
}(18)
func (t∗Chaincode) Invoke(stub shim.ChaincodeStubInterface) peer.Response {(19)
function, args: = stub.GetFunctionAndParameters()(20)
if function = = “CheckCourse” {(21)
return t.CheckCourse(stub, args)(22)
} else if function = = “LearnCourse” {(23)
return t.LearnCourse(stub, args)(24)
} else if function = = “WorkUpload” {(25)
return t.WorkUpload(stub, args)(26)
} else if function = = “AddGrade” {(27)
return t.AddGrade(stub, args)(28)
} else if function = = “CheckStudent” {(29)
return t.CheckStudent(stub, args)(30)
} else if function = = “AwardCredit” {(31)
return t.AwardCredit(stub, args)(32)
}(33)
return shim.Error(“Invalid Smart Contract function name. “)(34)
}


### 3.4. User Registration Phase

In this phase, UserX submits registration application and identity information to his or her university. After verifying the identity, the university administrator connects to the CA node to generate the certificate, the public key, and the private key of User X. Figure 3 shows the flowchart of the user registration phase.Step 1: UserX generates the registration application MRequest and identity information MIdentity, then transmits MRequest,MIdentity to his or her universityStep 2: University administrators verifyMIdentity, then transmit MIdentity to the CA node if MIdentity is valid. CA generates the private key dX, the public key QX, and the certificate CertX of User X based on MIdentityStep 3: The application program generates the system account andIDX of User X based on dX, QX, CertX and MIdentity, then sends dX,QX,IDX to User XFigure 3
User registration phase.


### 3.5. Course Registration Phase

In this phase, Teacher B sends Course B to his university for review. If Course B is valid, the administrator of University B adds the course information to the account of Teacher B by invoking chaincode. Figure4 shows the flowchart of the course registration phase.Step 1: Teacher B wants to add Course B to the system, first he generatesMCourse and the course teaching request MRequest, then chooses a random number k1, calculates H1=hashMCourse,IDT,MRequest,TST, x1,y1=k1G, r1=x1modp, s1=k1−1H1+r1dTmodp, and sends MRequest,IDT,MCourse,TST,CertT,r1,s1 to University B.Step 2: after receivingMRequest from Teacher B, the administrator of University B first uses TSNOW−TST≤ΔT to confirm whether the timestamp is valid, then searches for the public key QT of teacher B by IDT, verifies CertT by QT, and calculates H2=hashMCourse,IDT,MRequest,TST, u1=H2s1−1modp, v1=r1s1−1modp, x2,y2=u1G+v1QT, check x2modp=?r1 . If the signature verification is passed, the university administrator reviews Course B, generates the result MResult, and invokes the chaincode CheckCourse. The chaincode is shown in Algorithm 2.Figure 4
Course registration phase.Algorithm 2: Chaincode for the university to check courses.
(1)
func (t∗Chaincode) CheckCourse(APIstub shim.ChaincodeStubInterface, args []string) peer.Response {(2)
if len(args) ! = 4 {(3)
return shim.Error(“nu Incorrect mber of arguments. Expecting 4″)(4)
}(5)
var teacher = Teacher{Name: args [1], University: args [2], Course: args [3]}(6)
teacherAsBytes, _: = json.Marshal(teacher)(7)
APIstub.PutState(args[0], teacherAsBytes)(8)
return shim.Success(nil)(9)
}Step 3: after receivingIDUB,MResult,IDC,TSUB,CertUB,r2,s2 from University B, Teacher B first uses TSNOW−TSUB≤ΔT to confirm whether the timestamp is valid, then searches for the public key QUB of University B by IDUB, verifies CertUB by QUB, and calculates H4=hashMResult,IDC,IDUB,TSUB, u2=H4s2−1modp, v2=r2s2−1modp, x4,y4=u2G+v2QUB, x4modp=?r2.


### 3.6. Course Learning Phase

If Student A wants to learn Course B from University B, he will first apply for course learning to Teacher B and Teacher B adds the course information to his account by invoking chaincode. During the period of learning Course B, Student A uploads the hash value of his homework and final examination by invoking chaincode and sends them to Teacher B for grading, then Teacher B uploads the grade of Student A by invoking chaincode. Figure5 shows the flowchart of the course learning phase.Step 1: Student A selects Course B that he wants to learn, then generates the course learning applicationMRequest, chooses a random number k3, calculates H5=hashMRequest,IDC,IDS,TSS, x5,y5=k3G, r3=x5modp, s3=k3−1H5+r3dSmodp, and sends MRequest,IDC,IDS,TSS,CertS,r3,s3 to Teacher B.Step 2: after receivingMRequest from Student A, Teacher B first uses TSNOW−TSS≤ΔT to confirm whether the timestamp is valid, then searches for the public key QS of Student A by IDS, verifies CertS by QS, and calculates H6=hashMRequest,IDC,IDS,TSS, u3=H6s3−1modp, v3=r3s3−1modp, x6,y6=u3G+v3QS, x6modp=?r3. If the signature verification is passed, Teacher B invokes the chaincode LearnCourse. The chaincode is shown in Algorithm 3.Then, Student A chooses a random numberk4, calculates H8=hashMWork,IDC,IDS,TSS, x7,y7=k4G, r4=x7modp, s4=k4−1H8+r4dSmodp, and sends CWork,IDC,IDS,TSS,CertS,r4,s4 to Teacher B.Step 4: after receivingCWork from Student A, Teacher B first uses TSNOW−TSS≤ΔT to confirm whether the timestamp is valid, then verifies CertS by QS, decrypts CWork with his private key dT, generates MWork=DdTCWork and calculates H9=hashMWork,IDC,IDS,TSS, u4=H9s4−1modp, v4=r4s5−1modp, x8,y8=u4G+v4QS, x8modp=?r4. If the signature verification is passed, Teacher B reviews MWork and generates the grade g, then he uploads the grade by invoking the chaincode AddGrade. The chaincode is shown in Algorithm 5.Figure 5
Course learning phase.Algorithm 3: Chaincode for the teacher to approve students to join the course.
(1)
func (t∗Chaincode) LearnCourse(APIstub shim.ChaincodeStubInterface, args []string) peer.Response {(2)
if len(args) ! = 6 {(3)
return shim.Error(“Incorrect number of arguments. Expecting 6″)(4)
}(5)
var student = Student{Name: args [1], University: args [2], Hash: args [3], Grade: args [2], Credit: args [3]}(6)
studentAsBytes, _: = json.Marshal(student)(7)
APIstub.PutState(args[0], studentAsBytes)(8)
return shim.Success(nil)(9)
}Step 3: When Student A finishes his homework and final examinationMWork, he searches for the public key QT of Teacher B by IDT, encrypts MWork with the public key QT, generates CWork=EQTMWork, calculates H7=hashMWork, and uploads H7 by invoking the chaincode WorkUpload. The chaincode is shown in Algorithm 4.Algorithm 4: Chaincode for the student to upload the hash value of his homework and examination.
(1)
func (t∗Chaincode) WorkUpload(APIstub shim.ChaincodeStubInterface, args []string) peer.Response {(2)
if len(args) ! = 2 {(3)
return shim.Error(“Incorrect number of arguments. Expecting 2″)(4)
}(5)
studentAsBytes, _: = APIstub.GetState(args[0])(6)
student:= Student{}(7)
json.Unmarshal(studentAsBytes, &student)(8)
student.Hash = args[3].(9)
studentAsBytes, _ = json.Marshal(student)(10)
APIstub.PutState(args[0], studentAsBytes)(11)
return shim.Success(nil)(12)
}Algorithm 5: Chaincode for the teacher to add course grades to the student account.
(1)
func (t∗Chaincode) AddGrade(APIstub shim.ChaincodeStubInterface, args []string) peer.Response {(2)
if len(args) ! = 2 {(3)
return shim.Error(“Incorrect number of arguments. Expecting 2″)(4)
}(5)
studentAsBytes, _: = APIstub.GetState(args[0])(6)
student:= Student{}(7)
json.Unmarshal(studentAsBytes, &student)(8)
student.Grade = args[4].(9)
studentAsBytes, _ = json.Marshal(student)(10)
APIstub.PutState(args[0], studentAsBytes)(11)
return shim.Success(nil)(12)}


### 3.7. Credit Application Phase

In this phase, Student A applies to his university for the credit of Course B. If the grade of Student A is qualified, the administrator of University A awards him the credit by invoking the chaincode. Figure6 shows the flowchart of the credit application phase.Step 1: Student A generates the credit applicationMRequest and sends MRequest,IDC,IDS to University A.Step 2: after receivingMRequest,IDC,IDS from Student A, the administrator of University A invokes the chaincode CheckStudent to check the grade g of Student A. The chaincode is shown in Algorithm 6. If the grade g is qualified, the administrator adds the credit to the account of Student A by invoking the chaincode AwardCredit. The chaincode is shown in Algorithm 7.Figure 6
Credit application phase.Algorithm 6: Chaincode for university and teachers to check student’s information on the blockchain.
(1)
func (t∗Chaincode) CheckStudent(APIstub shim.ChaincodeStubInterface, args []string) peer.Response {(2)
if len(args) ! = 1 {(3)
return shim.Error(“Incorrect number of arguments. Expecting 1″)(4)
}(5)
studentAsBytes, _: = APIstub.GetState(args[0])(6)
return shim.Success(studentAsBytes)(7)
}Algorithm 7: Chaincode for the university to award student credit.
(1)
func (t∗Chaincode) AwardCredit(APIstub shim.ChaincodeStubInterface, args []string) peer.Response {(2)
if len(args) ! = 2 {(3)
return shim.Error(“Incorrect number of arguments. Expecting 2″)(4)
}(5)
studentAsBytes, _: = APIstub.GetState(args[0])(6)
student:= Student{}(7)
json.Unmarshal(studentAsBytes, &student)(8)
student.Credit = args[5].(9)
studentAsBytes, _ = json.Marshal(student)(10)
APIstub.PutState(args[0], studentAsBytes)(11)
return shim.Success(nil)(12)
}


### 3.8. Credit Verification Phase

Student A wants to transfer from University A to University C, and thus University C wants to verify the credits of Student A. University C first applies for credit verification, then Student A sends his homework and final examination which are encrypted to University C. After decrypting the message and ensuring that the data is not tampered with, the administrator of University C reviews the content of the homework and final examination. Figure7 shows the flowchart of the credit verification phase.Step 1: University C generates the credit verification applicationMRequest, chooses a random number k5, calculates H10=hashMRequest,IDC,IDUC,TSUC, x9,y9=k5G, r5=x9modp, s5=k5−1H10+r5dUCmodp, and sends MRequest,IDC,IDUC,TSUC,CertUC,r5,s5 to Student A.Step 2: after receivingMRequest from University C, Student A first uses TSNOW−TSUC≤ΔT to confirm whether the timestamp is valid, then searches for the public key QUC of University C by IDUC, verifies CertUC by QUC, and calculates H11=hashMRequest,IDC,IDUC,TSUC, u5=H11s5−1modp, v5=r5s5−1modp, x10,y10=u5G+v5QUC, x10modp=?r5. If the signature verification is passed, Student A generates MResult, encrypts MWork with the public key QUC, generates CWork'=EQUCMWork, chooses a random number k6, calculates H12=hashMResult,MWork,IDC,IDS,TSS, x11,y11=k6G, r6=x11modp, s6=k6−1H12+r6dSmodp, and sends MResult,CWork,IDC,IDS,TSS,CertS,r6,s6 to Student A.Step 3: after receivingMResult from Student A, the administrator of University C first uses TSNOW−TSS≤ΔT to confirm whether the timestamp is valid, then searches for the public key QS of Student A by IDS, verifies CertS by QS, decrypts CWork' with the private key dUC, generates MWork=DdUCCWork' and calculates H13=hashMResult,MWork,IDC,IDS,TSS, u6=H13s6−1modp, v6=r6s6−1modp, x12,y12=u6G+v6QS, x12modp=?r6. If the signature verification is passed, the administrator checks H7 which was uploaded by Student A by invoking the chaincode CheckStudent and calculates H14=hashMWork. If H14=H7, it means that MWork sent by Student A to University C are the same as the homework and final examination which were submitted by Student A in the course learning phase. Having ensured that the homework and final examination are not tampered with, the administrator of University C reviews the content of MWork.Figure 7
Credit verification phase.


## 3.1. System Architecture

This research proposed a cross-university course learning system based on Hyperledger Fabric where the consortium includes many universities. The main members of the system include university administrators and users, and users include teachers and students. Teachers, students, and university administrators in the same university form an organization, and each university has administrators to manage its users. The system architecture is shown in Figure1.Figure 1
System structure.The members of the system are described as follows.(1)
Certificate authority (CA): CA nodes provide certificates, public and private keys for users who want to join the system, and each university has its own CA node.(2)
University: a university is managed by university administrators, and there are many teachers and students and some administrators in each university.(3)
University administrator: a university administrator creates the channel, joins the channel with the peers in his or her organization, installs the chaincode on each peer node and initializes the chaincode, reviews the identity of users, and creates system accounts for them, reviews courses created by the teachers and checks students’ grades. By invoking chaincode, administrators add course information to teachers’ accounts, award credits to students, and verify students’ homework and final examinations.(4)
Teacher: teachers apply to their universities for teaching courses and grade students’ homework and final examinations. By invoking chaincode, teachers add course information and grades to students’ accounts.(5)
Students apply to the teachers for learning courses, submit homework and final examinations to the teachers for grades and apply to their universities for course credits. By invoking chaincode, students add the hash values of their homework and final examinations to their accounts.


## 3.2. Application Scenario

Figure2 shows the application scenario where Student A of University A wants to learn Course B of Teacher B who comes from University B, and University C wants to verify the credit obtained by Student A.Step 1: the administrator of a university first creates a channel, then the administrator of each university in the system joins the channel with the peers in his or her organization, installs the chaincode on each peer node, and initializes the chaincode. All users (including teachers and students) need to apply for registration with the administrators of their universities first to obtain a system account.Step 2: Teacher B applies to University B for teaching Course B, which needs to be reviewed by his university. After the course is approved, University B adds the course information to the account of Teacher B by invoking chaincode.Step 3: Student A applies to Teacher B for learning Course B, and Teacher B adds the course information to the account of Student A by invoking chaincode. During the course learning period, Student A needs to upload the hash value of homework and final examination and send them to Teacher B for grading, then Teacher B will upload the grade of Student A by invoking chaincode.Step 4: Student A applies to his university for obtaining the credit of Course B after receiving the grade from Teacher B. By invoking chaincode, University A checks the grade of Student A and awards credit if the grade is qualified.Step 5: Student A wants to transfer from University A to University C, and University C and, therefore, wants to verify the credits of Student A. University C submits the credit verification request to Student A, and Student A sends the homework and final examination to University C. Before reviewing the content of homework and final examination, University C needs to calculate the hash value of the homework and final examination, then compares it with the hash value uploaded by Student A to ensure that the homework and final examination have never been tampered with.Figure 2
Application scenario.


## 3.3. Initial Phase

In the initial phase, the university administrator creates a channel, then installs, and initializes the chaincode for each peer node in the organization.Step 1: the university administrator logs in to the system through an application program, then starts a client node and creates a channel.Step 2: the university administrator connects to each peer node in the organization in turn through the channel, then installs the chaincode on each peer node and initializes the chaincode. The chaincode is shown in Algorithm1.Algorithm 1: Chaincode used for initialization.
(1)
type Chaincode struct {(2)
}(3)
type Teacher struct {(4)
Name string ‘json:”name”’(5)
University string ‘json:”university”’(6)
Course string ‘json:”course”’(7)
}(8)
type Student struct {(9)
Name string ‘json:”name”’(10)
University string ‘json:”university”’(11)
Hash string ‘json:”hash”’(12)
Grade int ‘json:”grade”’(13)
Credit int ‘json:”credit”’(14)
}(15)
func (t∗Chaincode) Init(stub shim.ChaincodeStubInterface) peer.Response {(16)
return shim.Success(nil)(17)
}(18)
func (t∗Chaincode) Invoke(stub shim.ChaincodeStubInterface) peer.Response {(19)
function, args: = stub.GetFunctionAndParameters()(20)
if function = = “CheckCourse” {(21)
return t.CheckCourse(stub, args)(22)
} else if function = = “LearnCourse” {(23)
return t.LearnCourse(stub, args)(24)
} else if function = = “WorkUpload” {(25)
return t.WorkUpload(stub, args)(26)
} else if function = = “AddGrade” {(27)
return t.AddGrade(stub, args)(28)
} else if function = = “CheckStudent” {(29)
return t.CheckStudent(stub, args)(30)
} else if function = = “AwardCredit” {(31)
return t.AwardCredit(stub, args)(32)
}(33)
return shim.Error(“Invalid Smart Contract function name. “)(34)
}


## 3.4. User Registration Phase

In this phase, UserX submits registration application and identity information to his or her university. After verifying the identity, the university administrator connects to the CA node to generate the certificate, the public key, and the private key of User X. Figure 3 shows the flowchart of the user registration phase.Step 1: UserX generates the registration application MRequest and identity information MIdentity, then transmits MRequest,MIdentity to his or her universityStep 2: University administrators verifyMIdentity, then transmit MIdentity to the CA node if MIdentity is valid. CA generates the private key dX, the public key QX, and the certificate CertX of User X based on MIdentityStep 3: The application program generates the system account andIDX of User X based on dX, QX, CertX and MIdentity, then sends dX,QX,IDX to User XFigure 3
User registration phase.


## 3.5. Course Registration Phase

In this phase, Teacher B sends Course B to his university for review. If Course B is valid, the administrator of University B adds the course information to the account of Teacher B by invoking chaincode. Figure4 shows the flowchart of the course registration phase.Step 1: Teacher B wants to add Course B to the system, first he generatesMCourse and the course teaching request MRequest, then chooses a random number k1, calculates H1=hashMCourse,IDT,MRequest,TST, x1,y1=k1G, r1=x1modp, s1=k1−1H1+r1dTmodp, and sends MRequest,IDT,MCourse,TST,CertT,r1,s1 to University B.Step 2: after receivingMRequest from Teacher B, the administrator of University B first uses TSNOW−TST≤ΔT to confirm whether the timestamp is valid, then searches for the public key QT of teacher B by IDT, verifies CertT by QT, and calculates H2=hashMCourse,IDT,MRequest,TST, u1=H2s1−1modp, v1=r1s1−1modp, x2,y2=u1G+v1QT, check x2modp=?r1 . If the signature verification is passed, the university administrator reviews Course B, generates the result MResult, and invokes the chaincode CheckCourse. The chaincode is shown in Algorithm 2.Figure 4
Course registration phase.Algorithm 2: Chaincode for the university to check courses.
(1)
func (t∗Chaincode) CheckCourse(APIstub shim.ChaincodeStubInterface, args []string) peer.Response {(2)
if len(args) ! = 4 {(3)
return shim.Error(“nu Incorrect mber of arguments. Expecting 4″)(4)
}(5)
var teacher = Teacher{Name: args [1], University: args [2], Course: args [3]}(6)
teacherAsBytes, _: = json.Marshal(teacher)(7)
APIstub.PutState(args[0], teacherAsBytes)(8)
return shim.Success(nil)(9)
}Step 3: after receivingIDUB,MResult,IDC,TSUB,CertUB,r2,s2 from University B, Teacher B first uses TSNOW−TSUB≤ΔT to confirm whether the timestamp is valid, then searches for the public key QUB of University B by IDUB, verifies CertUB by QUB, and calculates H4=hashMResult,IDC,IDUB,TSUB, u2=H4s2−1modp, v2=r2s2−1modp, x4,y4=u2G+v2QUB, x4modp=?r2.


## 3.6. Course Learning Phase

If Student A wants to learn Course B from University B, he will first apply for course learning to Teacher B and Teacher B adds the course information to his account by invoking chaincode. During the period of learning Course B, Student A uploads the hash value of his homework and final examination by invoking chaincode and sends them to Teacher B for grading, then Teacher B uploads the grade of Student A by invoking chaincode. Figure5 shows the flowchart of the course learning phase.Step 1: Student A selects Course B that he wants to learn, then generates the course learning applicationMRequest, chooses a random number k3, calculates H5=hashMRequest,IDC,IDS,TSS, x5,y5=k3G, r3=x5modp, s3=k3−1H5+r3dSmodp, and sends MRequest,IDC,IDS,TSS,CertS,r3,s3 to Teacher B.Step 2: after receivingMRequest from Student A, Teacher B first uses TSNOW−TSS≤ΔT to confirm whether the timestamp is valid, then searches for the public key QS of Student A by IDS, verifies CertS by QS, and calculates H6=hashMRequest,IDC,IDS,TSS, u3=H6s3−1modp, v3=r3s3−1modp, x6,y6=u3G+v3QS, x6modp=?r3. If the signature verification is passed, Teacher B invokes the chaincode LearnCourse. The chaincode is shown in Algorithm 3.Then, Student A chooses a random numberk4, calculates H8=hashMWork,IDC,IDS,TSS, x7,y7=k4G, r4=x7modp, s4=k4−1H8+r4dSmodp, and sends CWork,IDC,IDS,TSS,CertS,r4,s4 to Teacher B.Step 4: after receivingCWork from Student A, Teacher B first uses TSNOW−TSS≤ΔT to confirm whether the timestamp is valid, then verifies CertS by QS, decrypts CWork with his private key dT, generates MWork=DdTCWork and calculates H9=hashMWork,IDC,IDS,TSS, u4=H9s4−1modp, v4=r4s5−1modp, x8,y8=u4G+v4QS, x8modp=?r4. If the signature verification is passed, Teacher B reviews MWork and generates the grade g, then he uploads the grade by invoking the chaincode AddGrade. The chaincode is shown in Algorithm 5.Figure 5
Course learning phase.Algorithm 3: Chaincode for the teacher to approve students to join the course.
(1)
func (t∗Chaincode) LearnCourse(APIstub shim.ChaincodeStubInterface, args []string) peer.Response {(2)
if len(args) ! = 6 {(3)
return shim.Error(“Incorrect number of arguments. Expecting 6″)(4)
}(5)
var student = Student{Name: args [1], University: args [2], Hash: args [3], Grade: args [2], Credit: args [3]}(6)
studentAsBytes, _: = json.Marshal(student)(7)
APIstub.PutState(args[0], studentAsBytes)(8)
return shim.Success(nil)(9)
}Step 3: When Student A finishes his homework and final examinationMWork, he searches for the public key QT of Teacher B by IDT, encrypts MWork with the public key QT, generates CWork=EQTMWork, calculates H7=hashMWork, and uploads H7 by invoking the chaincode WorkUpload. The chaincode is shown in Algorithm 4.Algorithm 4: Chaincode for the student to upload the hash value of his homework and examination.
(1)
func (t∗Chaincode) WorkUpload(APIstub shim.ChaincodeStubInterface, args []string) peer.Response {(2)
if len(args) ! = 2 {(3)
return shim.Error(“Incorrect number of arguments. Expecting 2″)(4)
}(5)
studentAsBytes, _: = APIstub.GetState(args[0])(6)
student:= Student{}(7)
json.Unmarshal(studentAsBytes, &student)(8)
student.Hash = args[3].(9)
studentAsBytes, _ = json.Marshal(student)(10)
APIstub.PutState(args[0], studentAsBytes)(11)
return shim.Success(nil)(12)
}Algorithm 5: Chaincode for the teacher to add course grades to the student account.
(1)
func (t∗Chaincode) AddGrade(APIstub shim.ChaincodeStubInterface, args []string) peer.Response {(2)
if len(args) ! = 2 {(3)
return shim.Error(“Incorrect number of arguments. Expecting 2″)(4)
}(5)
studentAsBytes, _: = APIstub.GetState(args[0])(6)
student:= Student{}(7)
json.Unmarshal(studentAsBytes, &student)(8)
student.Grade = args[4].(9)
studentAsBytes, _ = json.Marshal(student)(10)
APIstub.PutState(args[0], studentAsBytes)(11)
return shim.Success(nil)(12)}


## 3.7. Credit Application Phase

In this phase, Student A applies to his university for the credit of Course B. If the grade of Student A is qualified, the administrator of University A awards him the credit by invoking the chaincode. Figure6 shows the flowchart of the credit application phase.Step 1: Student A generates the credit applicationMRequest and sends MRequest,IDC,IDS to University A.Step 2: after receivingMRequest,IDC,IDS from Student A, the administrator of University A invokes the chaincode CheckStudent to check the grade g of Student A. The chaincode is shown in Algorithm 6. If the grade g is qualified, the administrator adds the credit to the account of Student A by invoking the chaincode AwardCredit. The chaincode is shown in Algorithm 7.Figure 6
Credit application phase.Algorithm 6: Chaincode for university and teachers to check student’s information on the blockchain.
(1)
func (t∗Chaincode) CheckStudent(APIstub shim.ChaincodeStubInterface, args []string) peer.Response {(2)
if len(args) ! = 1 {(3)
return shim.Error(“Incorrect number of arguments. Expecting 1″)(4)
}(5)
studentAsBytes, _: = APIstub.GetState(args[0])(6)
return shim.Success(studentAsBytes)(7)
}Algorithm 7: Chaincode for the university to award student credit.
(1)
func (t∗Chaincode) AwardCredit(APIstub shim.ChaincodeStubInterface, args []string) peer.Response {(2)
if len(args) ! = 2 {(3)
return shim.Error(“Incorrect number of arguments. Expecting 2″)(4)
}(5)
studentAsBytes, _: = APIstub.GetState(args[0])(6)
student:= Student{}(7)
json.Unmarshal(studentAsBytes, &student)(8)
student.Credit = args[5].(9)
studentAsBytes, _ = json.Marshal(student)(10)
APIstub.PutState(args[0], studentAsBytes)(11)
return shim.Success(nil)(12)
}


## 3.8. Credit Verification Phase

Student A wants to transfer from University A to University C, and thus University C wants to verify the credits of Student A. University C first applies for credit verification, then Student A sends his homework and final examination which are encrypted to University C. After decrypting the message and ensuring that the data is not tampered with, the administrator of University C reviews the content of the homework and final examination. Figure7 shows the flowchart of the credit verification phase.Step 1: University C generates the credit verification applicationMRequest, chooses a random number k5, calculates H10=hashMRequest,IDC,IDUC,TSUC, x9,y9=k5G, r5=x9modp, s5=k5−1H10+r5dUCmodp, and sends MRequest,IDC,IDUC,TSUC,CertUC,r5,s5 to Student A.Step 2: after receivingMRequest from University C, Student A first uses TSNOW−TSUC≤ΔT to confirm whether the timestamp is valid, then searches for the public key QUC of University C by IDUC, verifies CertUC by QUC, and calculates H11=hashMRequest,IDC,IDUC,TSUC, u5=H11s5−1modp, v5=r5s5−1modp, x10,y10=u5G+v5QUC, x10modp=?r5. If the signature verification is passed, Student A generates MResult, encrypts MWork with the public key QUC, generates CWork'=EQUCMWork, chooses a random number k6, calculates H12=hashMResult,MWork,IDC,IDS,TSS, x11,y11=k6G, r6=x11modp, s6=k6−1H12+r6dSmodp, and sends MResult,CWork,IDC,IDS,TSS,CertS,r6,s6 to Student A.Step 3: after receivingMResult from Student A, the administrator of University C first uses TSNOW−TSS≤ΔT to confirm whether the timestamp is valid, then searches for the public key QS of Student A by IDS, verifies CertS by QS, decrypts CWork' with the private key dUC, generates MWork=DdUCCWork' and calculates H13=hashMResult,MWork,IDC,IDS,TSS, u6=H13s6−1modp, v6=r6s6−1modp, x12,y12=u6G+v6QS, x12modp=?r6. If the signature verification is passed, the administrator checks H7 which was uploaded by Student A by invoking the chaincode CheckStudent and calculates H14=hashMWork. If H14=H7, it means that MWork sent by Student A to University C are the same as the homework and final examination which were submitted by Student A in the course learning phase. Having ensured that the homework and final examination are not tampered with, the administrator of University C reviews the content of MWork.Figure 7
Credit verification phase.


## 4. Security and Feature Analysis

### 4.1. Mutual Authentication

In this paper, BAN logic [32] was used for identity authentication. The notation of BAN logic is described as below.(1)
<X>K The message X is combined with a key K(2)
P|≡XP believes X(3)
P↔KQP and Q use a shared key K to communicate(4)
#X The message X is fresh(5)
P|⇒XP has jurisdiction over X(6)
P⊲XP sees X(7)
P|∼XP once said XThe main goals of the scheme are to authenticate the identity between UserX and User Y.(1)
G1:X|≡X↔xY−XY(2)
G2:X|≡Y|≡X↔xY−XY(3)
G3:Y|≡X↔xX−YY(4)
G4:Y|≡X|≡X↔xX−YY(5)
G5:X|≡IDY(6)
G6:X|≡Y|≡IDY(7)
G7:Y|≡IDX(8)
G8:Y|≡X|≡IDXBAN logic is used for producing an idealized form as follows:(1)
M1:<hashIDX,MX,TSX>xX−Y(2)
M2:<hashIDY,MY,TSY>xY−XIt is necessary to make the following assumptions before analyzing the proposed scheme:(1)
A1:X|≡#TSX(2)
A2:Y|≡#TSX(3)
A3:X|≡#TSY(4)
A4:Y|≡#TSY(5)
A5:X|≡Y|⇒X↔xY−XY(6)
A6:Y|≡X|⇒X↔xX−YY(7)
A7:X|≡Y|⇒IDY(8)
A8:Y|≡X|⇒IDXAccording to these assumptions, the main proof of the authentication is as follows:


#### 4.1.1. UserY Authenticates User X

By M1 and the seeing rule, derive(1)Y⊲<hashIDX,MX,TSX>xX−Y.By A2 and the freshness rule, derive(2)Y|≡#<hashIDX,MX,TSX>xX−Y.By A6, statement 1, and the message meaning rule, derive(3)Y|≡X|∼<hashIDX,MX,TSX>xX−Y.By statement 2, statement 3, and the nonce verification rule, derive(4)Y|≡X|≡<hashIDX,MX,TSX>xX−Y.By statement 4 and the belief rule, derive(5)Y|≡X|≡X↔xX−YY.By A6, statement 5, and the jurisdiction rule, derive(6)Y|≡X↔xX−YY.By statement 6 and the belief rule, derive(7)Y|≡X|≡IDX.By A8, statement 7, and the jurisdiction rule, derive(8)Y|≡IDX.


#### 4.1.2. UserX Authenticates User Y

By M2 and the seeing rule, derive(9)X⊲<hashIDY,MY,TSY>xY−X.By A3 and the freshness rule, derive(10)X|≡#<hashIDY,MY,TSY>xY−X.By A5, statement 9, and the message meaning rule, derive(11)X|≡Y|∼<hashIDY,MY,TSY>xY−X.By statement 10, statement 11, and the nonce verification rule, derive(12)X|≡Y|≡<hashIDY,MY,TSY>xY−X.By statement 12 and the belief rule, derive(13)X|≡Y|≡X↔xY−XY.By A5, statement 13, and the jurisdiction rule, derive(14)X|≡X↔xY−XY.By statement 14 and the belief rule, derive(15)X|≡Y|≡IDY.By A7, statement 15, and the jurisdiction rule, derive(16)X|≡IDY.By statement 5, statement 6, statement 7, statement 8, statement 13, statement 14, statement 15, and statement 16, it can be proven that UserX and User Y authenticate each other.


### 4.2. Data Integrity

In this paper, Elliptic Curve Digital Signature Algorithm (ECDSA) is used to ensure data integrity, and any important data transmitted in the system need to be signed by the sender. In the process of data transmission, the sender first calculates the hash value of the data and then generates the digital signature by the hash value and his private key. After receiving the data and the digital signature from the sender, the receiver also calculates the hash value of the data and then searches for the public key of the sender. If the sender’s signature can be generated by the receiver’s hash value and the sender’s public key, then it means that the data transmitted in the system has not been tampered with or lost.Scenario: for example, Student A wants to send the course learning applicationMRequest of Course B to Teacher B. During data transmission, the data may be lost, or someone wants to maliciously tamper with the content of the application, then Teacher B receives MRequest' which is different from MRequest.Analysis: after receivingMRequest',IDC,IDS,TSS,CertS,r3,s3 from Student A and verifying the timestamp and CertS, Teacher B calculates H′=hashMRequest',IDC,IDS,TSS, u′=H′s3−1modp, v3=r3s3−1modp, x′,y′=uG+v3QS, if x′modp≠r3 and then realizes that MRequest' was not generated by Student A.


### 4.3. Privacy Protection

In order to protect the students’ privacy, the homework and final examinations of students in the system will be encrypted before transmission. When sending homework and final examination message, the student will encrypt the message with the receiver's public key, and the receiver decrypts the message with his or her private key before reviewing the content of the homework and final examination.Scenario: University C wants to verify the credit of Student A for Course B, then Student A sendsCWork which is generated by his homework and final examination MWork and the public key QUC to University C. Supposing that an attacker wants to obtain the homework and final examination without the permission of Student A, attacker intercepts the data when Student A transmits the message.Analysis: by intercepting the data, the attacker obtainsCWork which is displayed as a meaningless string and the attacker cannot get any valid information from CWork. If the attacker wants to decrypt CWork, he needs to use the private key of University C to calculate MWork=DdUCCWork. However, dUC is known only to University C and is not accessible to the attacker, and thus the attacker cannot get the content of the homework and final examination.


### 4.4. Decentralization and Distribution

The blockchain system has the characteristics of decentralization and distribution, and the data on the blockchain are not managed by a central organization. In the proposed system, universities jointly maintain the data on the blockchain, the entire ledger is stored on the peer nodes of each organization, and any user's operation on the blockchain in the system is executed synchronously on each peer node. Therefore, the data will remain consistent across the organization, and any two members of the system can reach a consensus on the data on the blockchain such as students’ credits, course grades, and the hash values that students upload.Scenario: a Peer node in the system fails and the data on the node is lost.Analysis: the remaining peer nodes in the system can still operate normally for transaction endorsement and ledger updates. Since the entire ledger is stored on each peer node, the loss of one copy of the ledger will not affect the operation of the system.


### 4.5. Traceability

All transactions in a blockchain system are packaged into blocks and arranged in chronological order, so all operations of the system users on the data on the blockchain can be traced, and cheating can be eliminated by using the traceability of blockchain.Scenario: supposing that Student A cannot finish Course B and fails the final examination, Teacher B wants to help Student A cheat by calling the chaincode AddGrade to give him a high scoreg′.Analysis: University A wants to verify the credit of Student A for Course B, and gets the gradeg′ of Student A by invoking the chaincode CheckStudent. The administrator of University A will first review the content of the homework and final examination, finding that MWork is unqualified and cannot meet g′, then complain to the ministry of education. The education department queries all transactions related to Teacher B and Student A on the blockchain to find the block where Teacher B invoked the chaincode AddGrade, which contains the irregular operation of Teacher B and the timestamp, and can be used as evidence for prosecution.


### 4.6. Credit Is Verifiable

In the proposed system, a university can verify the credits of students from other universities to determine whether the students’ abilities meet the university’s requirements. If student’s homework and final examination are sent to the university, then it means that all teachers and administrators in the university can review the content of the homework and final examination.Scenario: Student A obtains the credit for Course B and wants to transfer from University A to University C. To verify the learning situation of Student A on Course B, University C needs to review content of the homework and final examination.Analysis: Student A sendsCWork which was generated by his homework and final examination MWork and the public key QUC to University C, and University C decrypt CWork with the private key dUC to generate MWork. For ensuring that MWork generated by University C are the same as the homework and final examination submitted by Student A in the course learning phase, the administrator of University C invokes the chaincode CheckStudent to get the hash value HWork of the homework and final examination which was uploaded by Student A and calculates HWork'=hashMWork. If HWork'=HWork, then it means that MWork sent by Student A were not tampered with, and the administrator reviews the content of the homework and final examination.


## 4.1. Mutual Authentication

In this paper, BAN logic [32] was used for identity authentication. The notation of BAN logic is described as below.(1)
<X>K The message X is combined with a key K(2)
P|≡XP believes X(3)
P↔KQP and Q use a shared key K to communicate(4)
#X The message X is fresh(5)
P|⇒XP has jurisdiction over X(6)
P⊲XP sees X(7)
P|∼XP once said XThe main goals of the scheme are to authenticate the identity between UserX and User Y.(1)
G1:X|≡X↔xY−XY(2)
G2:X|≡Y|≡X↔xY−XY(3)
G3:Y|≡X↔xX−YY(4)
G4:Y|≡X|≡X↔xX−YY(5)
G5:X|≡IDY(6)
G6:X|≡Y|≡IDY(7)
G7:Y|≡IDX(8)
G8:Y|≡X|≡IDXBAN logic is used for producing an idealized form as follows:(1)
M1:<hashIDX,MX,TSX>xX−Y(2)
M2:<hashIDY,MY,TSY>xY−XIt is necessary to make the following assumptions before analyzing the proposed scheme:(1)
A1:X|≡#TSX(2)
A2:Y|≡#TSX(3)
A3:X|≡#TSY(4)
A4:Y|≡#TSY(5)
A5:X|≡Y|⇒X↔xY−XY(6)
A6:Y|≡X|⇒X↔xX−YY(7)
A7:X|≡Y|⇒IDY(8)
A8:Y|≡X|⇒IDXAccording to these assumptions, the main proof of the authentication is as follows:


### 4.1.1. UserY Authenticates User X

By M1 and the seeing rule, derive(1)Y⊲<hashIDX,MX,TSX>xX−Y.By A2 and the freshness rule, derive(2)Y|≡#<hashIDX,MX,TSX>xX−Y.By A6, statement 1, and the message meaning rule, derive(3)Y|≡X|∼<hashIDX,MX,TSX>xX−Y.By statement 2, statement 3, and the nonce verification rule, derive(4)Y|≡X|≡<hashIDX,MX,TSX>xX−Y.By statement 4 and the belief rule, derive(5)Y|≡X|≡X↔xX−YY.By A6, statement 5, and the jurisdiction rule, derive(6)Y|≡X↔xX−YY.By statement 6 and the belief rule, derive(7)Y|≡X|≡IDX.By A8, statement 7, and the jurisdiction rule, derive(8)Y|≡IDX.


### 4.1.2. UserX Authenticates User Y

By M2 and the seeing rule, derive(9)X⊲<hashIDY,MY,TSY>xY−X.By A3 and the freshness rule, derive(10)X|≡#<hashIDY,MY,TSY>xY−X.By A5, statement 9, and the message meaning rule, derive(11)X|≡Y|∼<hashIDY,MY,TSY>xY−X.By statement 10, statement 11, and the nonce verification rule, derive(12)X|≡Y|≡<hashIDY,MY,TSY>xY−X.By statement 12 and the belief rule, derive(13)X|≡Y|≡X↔xY−XY.By A5, statement 13, and the jurisdiction rule, derive(14)X|≡X↔xY−XY.By statement 14 and the belief rule, derive(15)X|≡Y|≡IDY.By A7, statement 15, and the jurisdiction rule, derive(16)X|≡IDY.By statement 5, statement 6, statement 7, statement 8, statement 13, statement 14, statement 15, and statement 16, it can be proven that UserX and User Y authenticate each other.


## 4.1.1. UserY Authenticates User X

By M1 and the seeing rule, derive(1)Y⊲<hashIDX,MX,TSX>xX−Y.By A2 and the freshness rule, derive(2)Y|≡#<hashIDX,MX,TSX>xX−Y.By A6, statement 1, and the message meaning rule, derive(3)Y|≡X|∼<hashIDX,MX,TSX>xX−Y.By statement 2, statement 3, and the nonce verification rule, derive(4)Y|≡X|≡<hashIDX,MX,TSX>xX−Y.By statement 4 and the belief rule, derive(5)Y|≡X|≡X↔xX−YY.By A6, statement 5, and the jurisdiction rule, derive(6)Y|≡X↔xX−YY.By statement 6 and the belief rule, derive(7)Y|≡X|≡IDX.By A8, statement 7, and the jurisdiction rule, derive(8)Y|≡IDX.


## 4.1.2. UserX Authenticates User Y

By M2 and the seeing rule, derive(9)X⊲<hashIDY,MY,TSY>xY−X.By A3 and the freshness rule, derive(10)X|≡#<hashIDY,MY,TSY>xY−X.By A5, statement 9, and the message meaning rule, derive(11)X|≡Y|∼<hashIDY,MY,TSY>xY−X.By statement 10, statement 11, and the nonce verification rule, derive(12)X|≡Y|≡<hashIDY,MY,TSY>xY−X.By statement 12 and the belief rule, derive(13)X|≡Y|≡X↔xY−XY.By A5, statement 13, and the jurisdiction rule, derive(14)X|≡X↔xY−XY.By statement 14 and the belief rule, derive(15)X|≡Y|≡IDY.By A7, statement 15, and the jurisdiction rule, derive(16)X|≡IDY.By statement 5, statement 6, statement 7, statement 8, statement 13, statement 14, statement 15, and statement 16, it can be proven that UserX and User Y authenticate each other.


## 4.2. Data Integrity

In this paper, Elliptic Curve Digital Signature Algorithm (ECDSA) is used to ensure data integrity, and any important data transmitted in the system need to be signed by the sender. In the process of data transmission, the sender first calculates the hash value of the data and then generates the digital signature by the hash value and his private key. After receiving the data and the digital signature from the sender, the receiver also calculates the hash value of the data and then searches for the public key of the sender. If the sender’s signature can be generated by the receiver’s hash value and the sender’s public key, then it means that the data transmitted in the system has not been tampered with or lost.Scenario: for example, Student A wants to send the course learning applicationMRequest of Course B to Teacher B. During data transmission, the data may be lost, or someone wants to maliciously tamper with the content of the application, then Teacher B receives MRequest' which is different from MRequest.Analysis: after receivingMRequest',IDC,IDS,TSS,CertS,r3,s3 from Student A and verifying the timestamp and CertS, Teacher B calculates H′=hashMRequest',IDC,IDS,TSS, u′=H′s3−1modp, v3=r3s3−1modp, x′,y′=uG+v3QS, if x′modp≠r3 and then realizes that MRequest' was not generated by Student A.


## 4.3. Privacy Protection

In order to protect the students’ privacy, the homework and final examinations of students in the system will be encrypted before transmission. When sending homework and final examination message, the student will encrypt the message with the receiver's public key, and the receiver decrypts the message with his or her private key before reviewing the content of the homework and final examination.Scenario: University C wants to verify the credit of Student A for Course B, then Student A sendsCWork which is generated by his homework and final examination MWork and the public key QUC to University C. Supposing that an attacker wants to obtain the homework and final examination without the permission of Student A, attacker intercepts the data when Student A transmits the message.Analysis: by intercepting the data, the attacker obtainsCWork which is displayed as a meaningless string and the attacker cannot get any valid information from CWork. If the attacker wants to decrypt CWork, he needs to use the private key of University C to calculate MWork=DdUCCWork. However, dUC is known only to University C and is not accessible to the attacker, and thus the attacker cannot get the content of the homework and final examination.


## 4.4. Decentralization and Distribution

The blockchain system has the characteristics of decentralization and distribution, and the data on the blockchain are not managed by a central organization. In the proposed system, universities jointly maintain the data on the blockchain, the entire ledger is stored on the peer nodes of each organization, and any user's operation on the blockchain in the system is executed synchronously on each peer node. Therefore, the data will remain consistent across the organization, and any two members of the system can reach a consensus on the data on the blockchain such as students’ credits, course grades, and the hash values that students upload.Scenario: a Peer node in the system fails and the data on the node is lost.Analysis: the remaining peer nodes in the system can still operate normally for transaction endorsement and ledger updates. Since the entire ledger is stored on each peer node, the loss of one copy of the ledger will not affect the operation of the system.


## 4.5. Traceability

All transactions in a blockchain system are packaged into blocks and arranged in chronological order, so all operations of the system users on the data on the blockchain can be traced, and cheating can be eliminated by using the traceability of blockchain.Scenario: supposing that Student A cannot finish Course B and fails the final examination, Teacher B wants to help Student A cheat by calling the chaincode AddGrade to give him a high scoreg′.Analysis: University A wants to verify the credit of Student A for Course B, and gets the gradeg′ of Student A by invoking the chaincode CheckStudent. The administrator of University A will first review the content of the homework and final examination, finding that MWork is unqualified and cannot meet g′, then complain to the ministry of education. The education department queries all transactions related to Teacher B and Student A on the blockchain to find the block where Teacher B invoked the chaincode AddGrade, which contains the irregular operation of Teacher B and the timestamp, and can be used as evidence for prosecution.


## 4.6. Credit Is Verifiable

In the proposed system, a university can verify the credits of students from other universities to determine whether the students’ abilities meet the university’s requirements. If student’s homework and final examination are sent to the university, then it means that all teachers and administrators in the university can review the content of the homework and final examination.Scenario: Student A obtains the credit for Course B and wants to transfer from University A to University C. To verify the learning situation of Student A on Course B, University C needs to review content of the homework and final examination.Analysis: Student A sendsCWork which was generated by his homework and final examination MWork and the public key QUC to University C, and University C decrypt CWork with the private key dUC to generate MWork. For ensuring that MWork generated by University C are the same as the homework and final examination submitted by Student A in the course learning phase, the administrator of University C invokes the chaincode CheckStudent to get the hash value HWork of the homework and final examination which was uploaded by Student A and calculates HWork'=hashMWork. If HWork'=HWork, then it means that MWork sent by Student A were not tampered with, and the administrator reviews the content of the homework and final examination.


## 5. Discussion

### 5.1. Computation Cost Analysis

The computation cost analysis of the proposed scheme is shown in Table2, and the highest computation cost is found in the course learning phase. Teacher B requires 8 multiplication operations, 2 hash function operations, 6 comparison operations, 1 asymmetric encryption operation, and 2 signature operations. Student A requires 6 multiplication operations, 3 hash function operations, 1 asymmetric encryption operation, and 3 signature operations. Thus, the proposed scheme has a good computational cost.Table 2
The computation cost analysis of the proposed scheme.
Phase roleUser registration phaseCourse registration phaseCourse learning phaseCredit application phaseCredit verification phaseAdministrator1TCmpN/AN/AN/AN/ACA1TMulN/AN/AN/AN/AUniversity AN/AN/AN/A1TCmp+2TSigN/AUniversity BN/A7TMul+2TH+3TCmp+2TSigN/AN/AN/AUniversity CN/AN/AN/AN/A7TMul+3TH+4TCmp+1TEnc+2TSigTeacher BN/A7TMul+2TH+3TCmp+1TSig8TMul+2TH+6TCmp+1TEnc+2TSigN/AN/AStudent AN/AN/A6TMul+3TH+1TEnc+3TSigN/A7TMul+2TH+3TCmp+1TEnc+1TSigTMul: multiplication operation TEnc: asymmetric encryption. TH: Hash function operation TSig: signature operation. TCmp: comparison operation.


### 5.2. Communication Cost Analysis

Table3 shows the communication efficiency of the proposed system. It is assumed that the ECDSA key and signature require 160 bits, course, homework, and final examination message and certificate require 1024 bits, and encrypted homework and exam message require 3072 bits, while other messages, like timestamp, identity information, request message, and result from the message, require 80 bits. Taking the credit verification phase, for example, it requires four ECDSA signatures, two certificates, an encrypted homework and exam message, and eight other messages. Thus, it requires 160 × 4 + 1024 × 2 + 3072 × 1 + 80 × 8 = 6400 bits in total, which takes 0.457 ms under 3.5 G (14 Mbps) communication environment, 0.064 ms under 4G (100 Mbps) communication environment, and 0.320 us under 5G (20 Mbps) communication environment.Table 3
Communication cost analysis of the proposed scheme.
ItemPhaseMessage length (bits)Round3.5 G (14 Mbps)4 (ms) G (100 Mbps)5 (ms) G (20 Gbps)User registration phase64030.0460.0060.032 usCourse registration phase427220.3050.0430.214 usCourse learning phase632020.4510.0630.316 usCredit application phase24010.0170.0020.012 usCredit verification phase640020.4570.0640.320 us


### 5.3. Comparison

Table4 shows the comparison of the previous schemes and the proposed scheme. Compared to the related works, the proposed scheme focuses on proposing a university course learning system which has the advantages of verifiable learning process, no token consumption, protection of students' privacy and complete security analysis.Table 4
The comparison of the previous schemes and the proposed scheme.
AuthorsYearObjective12345Turkanović et al. [9]2018Higher education credit platformYNNNNZhao et al. [10]2020System for student e-portfolio assessmentYNYNNMishra et al. [11]2021System for sharing students’ credentialsYNNYYJeong et al. [12]2021Multilateral personal portfolio authentication systemYNYNNThe proposed scheme2021A university course learning system with credit verifiableYYYYYNotes: 1—propose an architecture or framework, 2—verifiable learning process, 3—no token consumption, 4—encrypt private information, 5—security analysis, Y—yes, N—no.


## 5.1. Computation Cost Analysis

The computation cost analysis of the proposed scheme is shown in Table2, and the highest computation cost is found in the course learning phase. Teacher B requires 8 multiplication operations, 2 hash function operations, 6 comparison operations, 1 asymmetric encryption operation, and 2 signature operations. Student A requires 6 multiplication operations, 3 hash function operations, 1 asymmetric encryption operation, and 3 signature operations. Thus, the proposed scheme has a good computational cost.Table 2
The computation cost analysis of the proposed scheme.
Phase roleUser registration phaseCourse registration phaseCourse learning phaseCredit application phaseCredit verification phaseAdministrator1TCmpN/AN/AN/AN/ACA1TMulN/AN/AN/AN/AUniversity AN/AN/AN/A1TCmp+2TSigN/AUniversity BN/A7TMul+2TH+3TCmp+2TSigN/AN/AN/AUniversity CN/AN/AN/AN/A7TMul+3TH+4TCmp+1TEnc+2TSigTeacher BN/A7TMul+2TH+3TCmp+1TSig8TMul+2TH+6TCmp+1TEnc+2TSigN/AN/AStudent AN/AN/A6TMul+3TH+1TEnc+3TSigN/A7TMul+2TH+3TCmp+1TEnc+1TSigTMul: multiplication operation TEnc: asymmetric encryption. TH: Hash function operation TSig: signature operation. TCmp: comparison operation.


## 5.2. Communication Cost Analysis

Table3 shows the communication efficiency of the proposed system. It is assumed that the ECDSA key and signature require 160 bits, course, homework, and final examination message and certificate require 1024 bits, and encrypted homework and exam message require 3072 bits, while other messages, like timestamp, identity information, request message, and result from the message, require 80 bits. Taking the credit verification phase, for example, it requires four ECDSA signatures, two certificates, an encrypted homework and exam message, and eight other messages. Thus, it requires 160 × 4 + 1024 × 2 + 3072 × 1 + 80 × 8 = 6400 bits in total, which takes 0.457 ms under 3.5 G (14 Mbps) communication environment, 0.064 ms under 4G (100 Mbps) communication environment, and 0.320 us under 5G (20 Mbps) communication environment.Table 3
Communication cost analysis of the proposed scheme.
ItemPhaseMessage length (bits)Round3.5 G (14 Mbps)4 (ms) G (100 Mbps)5 (ms) G (20 Gbps)User registration phase64030.0460.0060.032 usCourse registration phase427220.3050.0430.214 usCourse learning phase632020.4510.0630.316 usCredit application phase24010.0170.0020.012 usCredit verification phase640020.4570.0640.320 us


## 5.3. Comparison

Table4 shows the comparison of the previous schemes and the proposed scheme. Compared to the related works, the proposed scheme focuses on proposing a university course learning system which has the advantages of verifiable learning process, no token consumption, protection of students' privacy and complete security analysis.Table 4
The comparison of the previous schemes and the proposed scheme.
AuthorsYearObjective12345Turkanović et al. [9]2018Higher education credit platformYNNNNZhao et al. [10]2020System for student e-portfolio assessmentYNYNNMishra et al. [11]2021System for sharing students’ credentialsYNNYYJeong et al. [12]2021Multilateral personal portfolio authentication systemYNYNNThe proposed scheme2021A university course learning system with credit verifiableYYYYYNotes: 1—propose an architecture or framework, 2—verifiable learning process, 3—no token consumption, 4—encrypt private information, 5—security analysis, Y—yes, N—no.


## 6. Conclusions

With the increase in the number of university online courses and students, the problem of credit verification becomes inevitable. Previously, credits were managed by each university and each online education platform alone, which led to the fact that credits earned by students in one university could not be recognized by other universities. This paper proposes a cross-university course learning system based on Hyperledger Fabric, which stores students’ credits and hash values of the homework and final examinations on the blockchain, and the data on the blockchain are jointly maintained by all universities. For universities, they can verify students’ credits and review the content of students’ homework and final examinations by invoking the chaincode, to determine whether students' abilities meet their requirements and then recognize the credits.This paper shows a complete system architecture, details the application scenario, and provides the chaincode. To improve the security of the system, students' homework and final examinations are encrypted before transmission, thus effectively protecting students' privacy. At the same time, the Elliptic Curve Digital Signature Algorithm in Hyperledger Fabric can ensure data integrity during communication. The security analysis using BAN logic shows that our proposed system enables mutual authentication of the system members. Compared with previous systems based on blockchain technology, the universities in the proposed system recognize credits by reviewing students' homework and final examinations, rather than relying on the authority of central educational institutions. The proposed scheme uses consortium blockchain architecture, which improves system operating efficiency and saves the money needed for mining compared to public blockchain architecture. The final analysis shows that the proposed system also performs well in terms of computational cost and communication cost.To sum up, this research achieved the following contributions:(1)
Proposes a cross-university course learning system based on Hyperledger Fabric where universities can review students’ homework and final examinations to recognize students’ credits.(2)
Proposes a complete system architecture, details the application scenario, and provides the chaincode.(3)
Uses Elliptic Curve Digital Signature Algorithm to ensure data integrity during communication and asymmetric encryption algorithm to protect students' privacy.(4)
Uses consortium blockchain architecture to improve system operating efficiency and save the money needed for mining compared to public blockchain architecture(5)
Presents security analysis through BAN logic to ensure mutual authentication of the system membersIn the future, the research will consider adding the role of enterprises in the system to realize the verification of students' credits and learning records by enterprises, thus facilitating enterprises to understand the ability of students and select the students they need. At the same time, as the number of system members increases, how to ensure the privacy of students and system operating efficiency also need to be considered.



---

*Source: 8241801-2021-12-16.xml*