Blockchain technologies (BCTs) and distributed ledger technologies (DLTs) have surpassed their initial use in cryprocurrencies, and are already being used in a plethora of fields -from supply chain managements and healthcare, to predictive maintenance systems and public sector [1,2,3,4,5]. With the rise of Ethereum and its smart contracts written in Solidity, presenting code which can be directly run on the chain itself, paired with a robust consensus mechanism, a secure and immutable record keeping solution in a trustless environment without the need of third-party stakeholder has risen, identifying BCTs/DLTs as disruptive technologies [6].
Credentialing solutions for Higher Education Institutions (HEIs) based on blockchain and similar technologies are still few. As of writing this paper, only a small number of papers have been published [7,8,9] compared to other blockchain-based use cases. For instance, one of the main conclusions found in one of the earliest studies on the topic of blockchain in education state that BCTs (and later DLTs) should allow users to be able to automatically ver-ify the validity of certificates in a direct manner, without contacting the HEI that originally issued the documents [7]. Indeed, the authors of [8] state that BCT/DLT-based systems promise a permanent authentication and storage solution for the alternative credentials market. This continuously growing market consists of various kinds of microcredentials, nanodegrees, MOOCs/SPOCs, certificates and/or badges from various types of training and pre-qualification programs. The authors also emphasize scalability issues, most noticeably if the BCT/DLT use the computationally complex Proof-of-Work (PoW) consensus mechanism, as does Bitcoin and many other cryptocurrency networks. The PoW approach will likely remove the need for educational organizations to validate credentials, and other lightweight approaches are needed.
Since the initial hype of using BCT/DLT for various use cases including ones in education, the authors of [9] conducted a literature review of solutions based on public blockchains, highlighting the need for a standardized approach built on a public blockchain to promote faster adoption and acceptance. This recent study states that full functioning and active prototypes are still low in numbers; however, one of the conclusions was that the blockchain application should run on a stable, secure, and trustworthy network.
Indeed, in a trustless environment where actors are not known, public BCTs with robust consensus mechanisms such as Biction are imperative [10,11,12]. However, mechanisms such as PoW or various variations of Proof of Stake (PoS) are computationally complex and require powerful, often dedicated computers equipped with a powerful central processing unit (CPU) and/or graphic processing unit (GPU). Conversely, in a more specific environment, i. e. where the nodes in the blockchain network are known (and trusted) parties, a blockchainbased solution with less complex consensus mechanism can be implemented, retaining security with the added benefit of not needing a powerful CPU/GPU to handle blockchain transactions. Usually, this approach is called a distributed ledger technology (DLT).
The authors' main motivation is to utilize a trustful environment and propose a lightweight framework for document credentialing, tailored specifically to HEIs and the issuance and validation of student diplomas and diploma supplements.
Based on literature, commercially (un)available solutions and our own previous attempts, we have identified the following research questions:
• RQ1: Is it possible to design a lightweight framework for the specific needs of HEIs to incorporate document issuance and validation in a secure manner, without relying on complex solutions? • RQ2: Can the flexibility of Hyperledger Fabric be used as a basis for incorporating a BCT/DLTbased addition to an existing HEI information system (IS)?
The rest of the paper is organized as follows. Section 2 gives a brief introduction on blockchain technolgies, focusing on Hyperledger Fabric. Afterwards, Section 3 gives presented the proposed system, developed at Belgrade Metropolitan University's (BMU's) Blockchain Technology Laboratory. Finally, Section 4 gives a conclusion, with current limitations and further research ideas.
In this Section, we firstly provide a briew overview of the building blocks of a general blockchain system. Afterwards, we focus on the Hyperledger DLT solution, of which Hyperledger Fabric is used to develop the credentialing system.
In general, BCTs impose a fundamental change to manner various types of data are processed, and can improve existing data security solutions. A blockchain can be viewed as a shared, append-only distributed ledger, in which all events are stored in linked blocks [13]. These events are often referred as transactions. A copy of the ledger is therefore kept by all nodes which form the blockchain network. Due to the fact that all member nodes have a copy of the ledger, all network nodes are updated in real time, simultaneously. Furher, a block can be viewed as a data structure consisting of the follwing:
1. a header which connects the new block to the previous one.
Each transaction, besides the data, contains a header with a timestamp, paired with an unique cryptographic signature, thus enablig the ledger to be resistant to modifications. This chain of blocks that is formed and continuously updated can be traced back all the way to the first block, named the genesis block.
The combination of peer-to-peer networking, publickey cryptography, and distributed consensus is what secures blockchain transactions. Conversely to a centralized system, no single entity i.e. node should be able to control the process of adding a block to the chain. As the blockchain is a distributed system, each new block addition is managed by all nodes who share equal rights. This mechanism is utilized in order to overcome security issues, and is achieved through the process known as distributed consensus. This process can be viewed as an agreement among the nodes in the network how to validate each block yet to be added to the chain. Depending on the consensus mechanism, nodes can either compete for correct transaction validation (PoW), be chosen randomly (PoS and its variations), or apply a different algorithm altogether. The algorithms used can vary in computational complexity.
Finally, it is important to note that blockahins are a class of technology; the term refers to different forms of distributed databases with variations in their technical and governance arrangements and complexity.
Hyperledger is the leading open source community focused on developing various stable frameworks, tools and libraries for enterprise-grade distributed ledger deployments [14]. This community aims to advance BCT/DLT technologies by identifying and more importantly realizing a cross-industry open standard platform for DLTs. The aim of the open standard is to transform the approach to business transactions on a global level [14]. Hyperledger has a modular approach to hosting projects similar to the approach of the Linux Foundation, as shown in Fig. 1. All Hyperledger projects are open source, they are easy to obtain [15]. All Hyperledger projects, with the exception of Hyperledger Indy, are used for general purpose blockchain-based applications and solutions, whereas Hyperledger Indy focuses on decentralized identity [16].
One of the key differences between the various BCTs/DLTs systems is the utilized consensus mechanism. Due to the variety of blockchain usage requirements, Hyperledger provides several different consensus mechanisms [17]. For instance, Fabric uses the Apache Kafka platform [18] as the main Crash Fault Tolerance (CFT) protocol on the network which is permissioned i.e. private, and it is voting-based. Hyperledger Indy utilized a consensus based on Redundant Byzantine Fault Tolerance (RBFT), a protocol inspired by Plenum Byzantine Fault Tolerance (Plenum). Hyperledger Iroha used a variant of the BFT algorithm called Sumeragi, which tolerates more than one Byzantine faulty network nodes. Hyperledger Sawtooth facilitates the so-called pluggable consensus for both lottery and voting algorithms. By default, Hyperledger Sawtooth uses a lottery-based, Nakamoto consensus algorithm called Proof of elapsed time (PoET). Hyperledger Burrow comes with Byzantine Fault-Tolerant Tendermint protocol with a greater transaction rate, whereas Buru implements various consensus algorithms that are involved in transaction validation, block validation, and block production, i.e. mining in the PoW mechanism, while Hyperledger Sawtooth has the most support for smart contract languages [16].
The core Hyperledger-based use cases include banking, healthcare, supply chain management, financial services, information technology, government, and media and entertainment. Indeed, the Hyperledger Foundation promotes a range of business DLTs, including many libraries and tools that provide support for the creation, maintenance, deployment, providing cryptographic work, etc [15]. For the proposed system, the authors have opted to use Hyperledger Fabric, as it is the Hyperledger project with most testing, working real-world applications community, and documentation. The details of Hyperledger Fabric are listed in Table 1. 1. the smart contract layer; 2. the blockchain layer itself; 3. the network layer.
The smart contract layer runs the chaincode to add the data to a block. It is present on every node, denoted as a peer. The blockchain layer consists of the peer itself, a Certification Authority (CA) for that peer, and a local NoSQL database -CouchDB. The network layer consists of the test network with two peers, denoted with org1 and org2.
The system was developed in two stages -Stage 1 consists of using an isolated GIT branch of the HEIs to add a functionality to export diploma supplemental materials as an API to the blockchain network. Stage 2 comprised of developing a lightweight blockchain application, based on Hyperledger Fabric, to connect the the API and add the data to a block. The architecture of the two-stage system is shown in Fig. 2.
The main parameter which Hyperledger Fabric uses is the transaction context ctx. It holds the needed information for transaction logic "per transaction" or "per contract". IT enables to access the stub which allows various blockchain operations such as state returns, adding a new item to the block, or getting all blocks (in our case diploma supplements).
To add a diploma supplement, it is needed to connect toe the peer node using a gateway, and to get the chaincode from the network.
To write the transaction i.e. diploma object, an asynchronous promise function will get all the necessary parameters for add a new diploma supplement, as shown in Fig. 3. It will create a new object with those parameters which will be later added to teh blockchain using stub API operations.
The data which is added to the blockchain has the following structure: When data is added, a message can be viewed in the console terminal to confirm a successful transaction, as shown in Fig. 4. In our testbed, and endpoint was not deployed from the IS's side; therefore we have manually added the data in the same format as the HEI's IS would provide.
In this paper, we have used Hyperledger Fabric to develop a lightweight blockchain network for credentialing HEI's diplomas and diploma supplements. Currently, our system only addresses the issuance use-case, while validation use-case remains open. As prototyping was conducted in an isolated environment, several open issues still remain. Firstly, should the blockchain remain private, or be public (where anyone can be a part of the network)? As the target group of the system are first and foremost HEIs, the authors, as was discussed in other literature as well, opt for a private blockchain solution, where the HEIs comprise the network. Still, there exists a possibility to add the learners as nodes as well.
Using Hyperledger Fabric, data such as diplomas and supplements can be issued and verified reliably. Blockchain can help learning platforms to add an additional layer to their credentialing process. We have presented a blockchain-based credentialing system can be easily deployable and connected to a learning platform. Within our proposed system, upon generating the certificate file for the diploma and/or supplement, the HEI's IS will make a transaction to the blockchain. This entry will also have the certificate information, alongside metadata required for the transaction header. This information will be encrypted, and can be accessed only by the IS, the student, and an authorized third party.
This new issuance transaction is sent to the blockchain, where the other nodes in the network will verify it and add it to the blockchain using a simpler consensus mechanism. Each node will have a local copy of the blockchain on a NoSQL database like CouchDB. For certificate validation, upon receiving the access link, the student or an authorized third party can verify the digital credential by accessing the blockchain through a query. If a match is found on the blockchain, the certificate file is validated and a corresponding message appears.
The innate immutability property of BCT/DLT does not allow fraudulent or modified certificate files to be deemed as verified. Any tampering to the certificate file will result in a vastly different hashed value of the file, ensuring impossible verification.
This paper was supported by the Blockchain Technology Laboratory at Belgrade Metropolitan University, Belgrade, Serbia.