Building a Sustainable Digital Infrastructure for Higher Education: A Blockchain-Based Solution for Cross-Institutional Enrollment

Abstract

Educational cooperation in higher education offers valuable opportunities for students and institutions alike. However, it also introduces significant challenges, particularly regarding student enrollment processes. Traditional centralized systems for managing this task can pose issues around authority, transparency, accountability, security, and cost, often hindering scalability and sustainable growth. This paper introduces the Cross-Institutional Blockchain Enrollment System (BCHEEN), a novel decentralized platform designed to streamline and enhance cross-institutional enrollment processes. Un-like existing solutions, BCHEEN employs a unique hybrid architecture that leverages blockchain technology to ensure transparency and security while maintaining scalability through innovative off-chain data management using the “replicate when used” approach. The platform was prototyped as a permissioned blockchain platform using the Hyperledger Composer framework and evaluated through functional, performance, and security analyses using tools such as Cucumber and Hyperledger Caliper. Evaluation results show that BCHEEN achieved a peak throughput of 18 tps at a send rate of 47 tps, with an average latency of 4.32 s under the same conditions, demonstrating its scalability and reliability. Furthermore, a computational cost analysis highlights the efficiency of the “replicate when used” approach in reducing storage overhead while preserving data integrity. BCHEEN’s practical impact includes streamlining enrollment processes, reducing administrative costs, and fostering secure, scalable, and transparent inter-institutional collaboration. These contributions position BCHEEN as a transformative tool for higher education, supporting policy advancements and promoting resilience and sustainability in educational practices.

1. Introduction

Educational cooperation can take many forms. In its simplest form, an educational institution could sign agreements for student exchange to allow their students the opportunity to study abroad. At a more advanced level, educational institutions may collaborate to develop and offer joint academic programs that lead to degrees awarded by one or more partner institutions [1]. Educational cooperation is increasing and the high demand for higher education is compelling institutional leaders to encourage such cooperation [2,3]. This cooperation provides significant benefits to both students and institutions. Students gain exposure to diverse educational practices, expand their professional networks, and enhance their employability in a global labor market. Meanwhile, institutions benefit by establishing a multinational presence, exchanging best practices, and aligning their offerings with emerging educational and research needs [1,4].

Despite their numerous advantages, educational cooperation comes with great challenges, particularly in student enrollment. The process of enrolling students in courses offered by partner institutions is often complex and time-consuming [5,6]. It involves extensive data exchanges between institutions, including personal information, academic records, prerequisites, and prohibitions, typically processed at both the home and host institutions. This process can take weeks, leaving students uninformed about their application status until a final decision is made [7,8].

Using a centralized system to facilitate students’ enrollment to courses offered at different educational institutions raises several concerns related to authority, accountability, security, and cost. Centralized systems have a core authority that has full control over the system. This authority is normally authorized to execute any operation and deny access to any of the data available within the system [9]. Having such authority for a system shared by many educational institutions is not viable. Besides, having records and data centralized makes it possible for the core authority as well as attackers to tamper with data or records [10]. This could raise issues related to transparency, accountability, and security. Furthermore, centralized systems are costly in terms of infrastructure, development, maintenance, and staffing [11].

While decentralized technologies like blockchain offer promising alternatives, they are not without limitations. Storing large data on the blockchain negatively impacts system performance and scalability, and replicating large files across multiple nodes consumes significant bandwidth and storage [12,13].

To address these concerns, this paper proposes a new Blockchain for Cross-Higher Education ENrollment (BCHEEN). This platform is based on blockchain technology, and its main purpose is to facilitate educational cooperation between higher education institutions. The platform has a novel architecture, in which students’ data are divided into on-chain data, i.e., data required for blockchain transactions and off-chain data; i.e., large data that are not required for blockchain transactions but can be used for other enrollment purposes. An approach called “replicate when used” is utilized to smartly manage the storage of data on- and off-chain. This paper details the architecture of BCHEEN, its implementation using the Hyperledger Composer framework, and its evaluation through functional testing with the Cucumber tool and performance testing with Hyperledger Caliper. Additionally, the platform’s robustness was validated through security analyses, and its computational cost efficiency was assessed to demonstrate the feasibility of the “replicate when used” method for off-chain data management.

2. Background

2.1. Blockchain Technology

Blockchain is an emerging technology first proposed in 2008. It was utilized as a peer-to-peer ledger for managing the transactions of the popular Bitcoin cryptocurrency [14]. The core aim was to eliminate the need for a third-party intermediary by allowing users to execute their financial transactions directly. To achieve this goal, blockchain was designed as a decentralized network of nodes that securely stores blocks of data (transactions ledger). For the blockchain network to work, each participating node does the following: (I) stores a hashed copy of the transactions ledger, (II) writes new entries to its own ledger when it receives consensus from the majority of nodes in the network, (III) broadcasts any change made to its own ledger to the other nodes in the network, and (IV) checks, on a regular basis, that its own ledger is identical to the ones available across the network [15].

As Bitcoin cryptocurrency continued to grow in popularity, practitioners and researchers realized the enormous potentials of its underlying technology [9]. Blockchain’s unique capabilities, such as transparency, immutability, and security, have been widely applied beyond finance in fields like education and sustainable infrastructure [16,17].

A blockchain network can be either permissionless, such as Bitcoin, or permissioned, such as Hyperledger Fabric [18,19]. In a permissioned blockchain, participants have known identities, and only explicitly authorized parties can execute transactions and maintain the ledger. In this sense, it differs greatly from traditional permissionless blockchain, which promotes anonymity and relies on cryptography and heavy compute obligations to validate transactions [20]. Many organizations prefer permissioned blockchains due to their ability to verify participant identities, streamline execution, enhance security, and offer customizable consensus mechanisms, unlike permissionless blockchains [21,22,23].

2.2. Hyperledger Fabric

Hyperledger Fabric is an open-source blockchain platform under the auspices of the Linux Foundation. It was designed as a permissioned blockchain where all participants have known identities [24]. It is the first blockchain to allow applications written in a standard programming language to be executed consistently across several nodes while giving the impression that it has been executed on one single node [21]. Unlike previous blockchain networks, Hyperledger Fabric has a new architecture. This architecture has the following key components [20,21]:

• Peers: they host instances of the ledger, and instances of chaincode, i.e., a program code that implements an application’s logic.
• Channels: these are mechanisms by which a group of components within the Hyperledger Fabric network can transact and communicate privately.
• Certificate Authority (CA): it is the entity that manages the network identities of all participating organizations and their users.
• Membership Service Provider (MSP): this component is responsible for maintaining the identities of all nodes in the network.
• Ordering service: it is performed by nodes called orderers, which are responsible for (I) ordering the transactions that are sent to a peer to be written to its ledger, and thus to prevent a state fork, (II) maintaining the orderer system channel, and (III) performing some essential identity validation checks.
• The Fabric SDKs: they allow programmers to build applications that interact with the Hyperledger Fabric network.

2.3. Hyperledger Composer

Hyperledger Composer is an open framework and development tool for developing Hyperledger Fabric applications. It aims to accelerate the development and make it easier to integrate an application with an existing blockchain network [25]. Programmers can model their applications by creating a Business Network Definition, comprised of Model, Script, Access Control Rules, and Query file [24,26].

• Model files: they are used to outline the structure and relationships between application elements—assets, transactions, and participants. Assets define tangible or intangible properties, goods, or services. Transactions are the functions that take place in the blockchain network, e.g., selling an asset. Participants are the network nodes which can interact with each other and with assets through transactions.
• Script files: these files are developed by programmers to implement business requirements that have been provided by business analysts. They are written in JavaScript and define the transaction logic, such as which participants can make an interaction, and how, and which asset should be modified, and how.
• Access control files: these files contain a set of access control rules that define the rights of each participant in the blockchain network such as Read, Create, and Update.
• Query files: these files contain the definitions of the different queries that can be used in script files to retrieve transactions from the historian, i.e., a ledger of all previous transactions in the network.

2.4. Blockchain for Developing Sustainable Infrastructure

Sustainability has become a critical focus in education, as institutions seek to adopt practices and technologies that ensure long-term efficiency, resilience, and minimal environmental impact [27,28]. Blockchain technology has emerged as a transformative tool for building sustainable infrastructure across various sectors, due to its transparency, decentralization, and immutability. In supply chain management, for example, blockchain was used to enhance traceability and transparency, enabling stakeholders to verify ethical practices, reduce waste, and improve resource utilization. This has been particularly beneficial for sustainable sourcing and minimizing environmental impacts [29,30].

In the energy sector, blockchain was applied to support decentralized renewable energy trading through peer-to-peer networks, promoting the use of clean energy sources and improving energy efficiency. Blockchain-based smart contracts streamline transactions and reduce operational costs, further supporting green energy transitions [31]. For smart cities, blockchain was used to provide a secure and efficient method for managing urban data, integrating Internet of Things (IoT) devices, and enabling real-time monitoring of infrastructure. This ensures transparency in governance and resource management, fostering sustainable urban development [32]. Blockchain has been used in environmental monitoring to securely record and share data, ensuring accuracy while enabling stakeholder collaboration on sustainability challenges [33].

In the education sector, blockchain was utilized to facilitate the development of sustainable education infrastructure, including securely storing academic records, certifications, and credentials. This reduces the environmental impact associated with traditional paper-based systems. Furthermore, blockchain was used to enhance educational collaboration through resource sharing, such as open educational resources and digital libraries, optimizing resource use and reducing costs [34].

3. Related Works

3.1. Blockchain Applications in Higher Education

While utilizing blockchain technology in higher education is still in its early stages, a good number of blockchain-based applications have been already developed for use by higher education institutions [35]. The majority of these applications were developed for the purpose of managing academic certificates. Han et al. [36], for example, proposed a novel blockchain-based solution that utilized the decentralized nature of the blockchain network to facilitate the issuing and verification of academic certificates and transcripts. Their solution allows individuals direct access to their academic records. However, only educational institutions are permitted to add new records and update the existing ones, under some restricted rules and conditions. Hölbl et al. [37] developed a credit transfers and certification system based on blockchain. The system allows academics to publish students’ exam results to the blockchain. Then, other organizations such as employers and other universities can verify the student’s course-obligation completion. However, the system is limited to exam results verification, and does not address broader challenges such as inter-institutional cooperation.

A considerable number of papers have also discussed the utilization of blockchain technology for the purpose of helping students to improve their learning outcomes and enhancing their academic competencies. For example, Duan et al. [38] implemented a blockchain-based application to measure the learning performance of students based on their achieved learning outcomes. Students can complete a variety of learning activities such as traditional face-to-face courses, training sessions, and online courses. Their performance in these activities can be verified and added to the blockchain by the educational institutions in which they attended those activities. Authorized third parties can assess students’ achievements in the light of their career goals and then recommend extra learning activities that could add more meaning to students’ learning experience and help them better achieve their career goals.

Recent advancements include projects like BeCertify, which implements blockchain technology for managing student certifications in a more transparent and technologically advanced way [39]. BeCertify’s development stages, architecture, and API operations provide a foundation for blockchain-based solutions aimed at enhancing the transparency and security of education certificates. Furthermore, blockchain has been integrated with cryptocurrencies to promote education. For example, StudentCoin, a platform for easy tokenization, allows students to learn about blockchain and cryptocurrency-use cases while creating and trading their own tokens. Such projects demonstrate how blockchain technology can be leveraged to educate university students on responsible investment practices in the cryptocurrency market, further integrating blockchain into education systems [40].

Additionally, secure certificate-sharing frameworks have been proposed to enhance online education. A novel Signature-based Rivest Shamir Framework (SbRSF) was introduced to address security concerns in data sharing between students and educators. This model outperformed traditional methods like the elliptic-curve model and sensitivity-based elliptic crypto schemes [41]. These advancements highlight the potential of blockchain in improving the privacy and security of online education systems. While platforms like BeCertify focus on improving transparency in certification management and StudentCoin integrates blockchain with cryptocurrency education, these solutions do not address broader challenges such as scalable inter-institutional enrollment. Similarly, SbRSF enhances secure data sharing but lacks mechanisms to facilitate cross-institutional collaboration and scalability, which are critical in higher education.

Other application of blockchain technology in the higher education field include the following: facilitating student loans [42], managing academic competitions [43], copyrights management [44,45], improving the reliability of online exams [46], supporting lifelong learning [47], enhancing students’ interactions in e-learning [48] and securing e-learning environments [49]. Again, while these solutions effectively address specific educational challenges, they fail to tackle the critical issue of inter-institutional enrollment. The complexities of securely sharing student data, managing cross-institutional course registrations, and ensuring data integrity across multiple institutions remain largely unaddressed by these platforms.

3.2. Challenges of Storing Large Data in Blockchain

While storing large data on-chain is not recommended, several alternatives have been discussed in the literature. Eberhardt and Tai [50] proposed using a distributed file system technology such as the InterPlanetary File System (IPFS). This technology allows coordination between peers to distribute and store data files. A major drawback of this technology is that after the file is seeded to the system, storing data by other peers is not guaranteed [51]. Another alternative is to use a distributed database such as Cassandra or MongoDB. Distributed databases work on multiple peers. Clients store their data on one peer, and it is automatically synchronized to the other peers. The main disadvantage of such an approach is that tampering with data on one peer will be reflected on all the other replicas. In addition, replicating all data on all peers might not be required, and can be a waste of storage spaces [52]. A third alternative is to use cloud storage. This technology utilizes a broad range of services and infrastructures distributed across the internet to facilitate the storage of high volumes of data [53]. However, cloud storage is a centralized technology, which eliminates many of the benefits of the decentralized blockchain technology [12]. BCHEEN addresses these limitations through its hybrid on-chain and off-chain architecture, which minimizes storage overhead while maintaining data integrity and availability.

The proposed platform in this paper, BCHEEN, differs significantly from existing educational blockchain platforms by focusing on facilitating secure and reliable cross-institutional enrollment, which has not been addressed by prior systems. BCHEEN uniquely integrates on-chain and off-chain data storage, addressing critical limitations such as storage overhead, data integrity, and availability found in previous off-chain solutions. Its comprehensive approach positions it as a novel solution for enhancing cross-institutional collaboration and scalability in higher education. For instance, BCHEEN could enable a student enrolled at one institution to seamlessly register for specialized courses at another, while maintaining secure data sharing and reducing administrative overhead. Such capabilities demonstrate BCHEEN’s potential to transform inter-institutional collaboration in higher education.

4. Methodology (Proposed Platform)

The proposed platform, i.e., BCHEEN, will make it easy for educational institutions to establish educational cooperation with each other. The platform will facilitate the students’ enrolment process and, at the same time, provide a secure, transparent, reliable, and robust enrollment approach.

4.1. Functional Requirements

To guide the development of BCHEEN, the following set of functional requirements were established:

• Educational institutions can manage lists of equivalent courses. Institutions that want to use the platform need to identify their equivalent courses, assign a unified code to them, then use BCHEEN to add these courses to the blockchain. Thus, students are allowed to ascertain transferability of their credit experiences and enrollment process is made fully automated.
• An institution can offer courses to be available for enrollment to students from other institutions. In addition to the basic information of the course, the institution should provide the maximum number of students who can enroll in each offered course. When this number is reached, no new enrollments should be accepted by the platform.
• Educational institutions can manage academic semesters. This includes adding and modifying semesters’ data. For each semester, they can specify the enrollment and withdrawal dates to ensure that enrollments and withdrawals are not permitted outside these dates.
• Education institutions can register their students in the system. When registering students, their essential information should be recorded, including name, id, degree, courses that students can study outside their home institution, prohibited courses, and maximum and minimum semester load. This information can be used by the platform to automate the enrollment process.
• A student can, after meeting certain conditions, enroll in one of the courses available for joint enrollment. The enrollment process should be fully automated. The platform will ensure that the students meet all the required conditions, i.e., (I) the student’s academic status is active, (II) the student is allowed to study the selected course, (III) the student has not exceeded the maximum allowed credit hours, (IV) the student is not currently enrolled in a similar course at another institution, and (V) all the course prerequisites have been met. The platform will also ensure that enrollment is still open in the educational institution where the course is offered and that the maximum number of enrollments in the course has not been exceeded.
• A student can withdraw from a course if he/she is withdrawing within the permitted withdrawal dates and he/she is not falling below the minimum required credit hours.

4.2. Non-Functional Requirements

As discussed earlier, implementing BCHEEN as a centralized platform will raise several concerns related to authority, accountability, security, and cost. To address these concerns, BCHEEN was designed as a decentralized platform with the following non-functional requirements in mind:

• BCHEEN should be able to store large data, such as students’ photos, their photo IDs, international students’ visas and indiscipline reports, without compromising the performance of the system. The storage mechanism should also maintain the other distinguished features of blockchain technology including reliability, transparency, immutability, accountability and security.
• BCHEEN should have a distributed architecture. Such architecture would allow the platform to operate without the need for a defined central authority. No single educational institution would have the ability to execute control over BCHEEN activities.
• BCHEEN should be reliable. Thus, a problem in a particular device should not affect the executed processes. If one of the participating institutions experiences problems in its IT infrastructure that runs the platform, other institutions should be able to continue using the platform and transact with each other.
• BCHEEN should support transparent processing and sharing of students’ data. Thus, when needed, an educational institution can validate a certain transaction or a student’s data to examine any changes made to this data over time.
• BCHEEN should support accountability. Any student or staff member using the platform should be held accountable for any misbehavior, such as providing wrongful information or executing an illegal transaction.
• BCHEEN should be highly secure. It would be virtually impossible to modify any of the sensitive data stored or shared by BCHEEN. Access to such data should be limited to authorized parties. BCHEEN should also reduce the risk of fraud and any other illegal activities.
• BCHEEN should minimize operation costs. Transactions performed by BCHEEN should be fully automated to reduce labor costs required to handle and process students’ data. Automation should also eliminate the need for third parties who are normally hired to do administrative tasks.

4.3. Deployment Environment

BCHEEN was designed so it can work on a Hyperledger Fabric network. Figure 1 shows how BCHEEN deployment environment would look like. The Hyperledger Fabric network, in which BCHEEN will operate, is both formed and managed by the multiple educational institutions that contribute resources to it. The network literally does not exist without these resources. Furthermore, the network shrinks and grows with the resources that are contributed by the participating institutions. Each institution would provide a different number of peers, depending on the institution’s size and number of students. A small educational institution, such as Institution 2 in our example, would contribute fewer peers than a bigger institution like Institution 1. These peers form the basis of the network, hosting ledgers, and chaincodes which can be queried and modified by applications. They also store students’ large data that is kept off-chain. By default, each peer in the network has the role of committer i.e., committing the blocks which it receives from the ordering service to its own ledger. In addition to this, a peer can act as endorser, i.e., endorsing transaction requests that come from clients. In our example, peers 1, 3, 4, 5, 7, and 8 are both committers and endorsers, while Peers 2, 6, and 9 are only committers.

The mechanism by which the Hyperledger Fabric network ensures that peers’ ledgers are consistent across the network is mediated by orderers. Not every educational institution would contribute orderers to the network; however, multiple orderers should be available, so that in the case of one orderer going down then the network can continue to operate. In our example, Institutions 1 and 3 contributed one orderer each, while Institution 2 contributed no orderers.

Peers, orderers, and BCHEEN interact with each other via Channel 1. By joining a channel, these components agree to share and manage identical copies of the ledger associated with that channel. Only one channel is required for BCHEEN to function; but, if a group of institutions decides to only collaborate with each other, a new channel between them could be established. In our example, Institutions 1, 2, and 3 have Channel 1 to communicate with each other. However, if Institution 1 and 2 decide to have certain types of collaboration available exclusively for their students, they can establish a new channel. In this case, they can continue their collaboration with Institution 3 via Channel 1. BCHEEN can operate on both channels.

Certificate authority in each educational institution will issue digital certificates to all peers that belong to the institution, as well as to the students and staff members of that institution who will use BCHEEN. Whenever a peer connects to the blockchain network via a channel, a policy in that channel checks the peer’s identity to determine its rights. Mapping identities to organizations is provided by MSP.

As Hyperledger Fabric was not designed to store large data files, this paper proposes a novel modification to the traditional Hyperledger Fabric network. In this proposal, as can be seen in Figure 1, each educational institution will dedicate space on one of its peers for off-chain data storage. The peer itself will continue to be part of the blockchain network; however, the dedicated storage space will only support off-chain data storage. The space will be used to store students’ large data files, and only a hash of each file will be stored in the blockchain network. Thus, the performance and the scalability of the platform are not affected, and, at the same time, its reliability and transparency are maintained by allowing clients to verify the fact that off-chain data have not been changed. Any change to a file would result in a new hash value different from the one produced for the original one.

To ensure an efficient use of available storage spaces, BCHEEN does not replicate data files on all available peers, but rather applies a “replicate when used” approach. When a student is registered onto the platform, student data files will be stored in his/her home institution storage space only. The reason is that, at this stage, these files are not needed by any other peer in the network. However, after the student is enrolled in a course at another institution, the platform will automatically transfer student’s files to that institution storage space. The more enrollments at different institutions the student makes, the more his/her files become important to the system and the more replicas of his/her files are made. In addition to providing efficient storage of data, this approach will ensure that the platform has no single point of failure and that large data files are available from different sources when they are needed.

Replicating students’ files is managed by a client application that will be built on top of BCHEEN. As can be seen in Figure 2, when a student submits an enrollment request, the client application invokes the enrollment transaction in the BCHEEN. As a result, BCHEEN executes the transaction. If the student meets all the enrollment conditions, he/she is enrolled in the visited institution, and the hashes of his/her files are returned to the client application. The original files are then retrieved from the storage space of the home institution and their hashes are computed and compared with the ones received from BCHEEN. If the hashes are the same, this proves that the files have not been changed. The client application will then update BCHEEN with the new location of the files on the visited institution storage space.

5. Implementation

BCHEEN was implemented according to Hyperledger Composer architecture (see Figure 3). Four files were created: a model file (Model.cto), a script file (Script.js), an access-control (Access.acl), and a query file (Query.qry). The model file defines the participants, the assets, the transactions and the events of BCHEEN. The script file contains the implementation of the seven transactions that have been defined in the model file. The access control contains rules that control what resources or assets a student or a staff member is authorized to access or perform in BCHEEN. The query file contains four queries. Each query was designed to be invoked by a transaction to retrieve some assets.

The EnrollIn Course transaction is the most complex, yet the most important transaction in BCHEEN. It was designed so it allows full automation of the whole enrollment process. The enrollment process that is applied by the author’s university has guided the design of this transaction. It takes Student, Selected Course Code, Visited Institution, Year, and Semester as input. It checks if the student meets a series of conditions and that the selected course is still available for enrollment, as in Algorithm 1 below. If the answer is yes, the student is enrolled in the course by adding the course detail to his/her StudentEnrolment asset. Moreover, the number of enrolled students in the course is increased by one in the SemesterOfferings asset. This transaction can only be performed by the student him/herself. The transaction concludes by emitting a SuccessEnrollNotification event to notify the client making the application that the enrollment has been successfully performed. As result of emitting this event, the student-files asset that contains the hashes and locations of the student files is sent to the client application. The application will act accordingly, and copy the student files to the visited institution storage space.

Another important algorithm that is worth demonstration is the WithdrawFromCourse transaction. Similar to the previous transaction, this one can only be performed by the student him/herself. It takes Student, Selected Course Code, Visited Institution, Year, and Semester as input. It then carries out a series of checks to make sure that the student can drop the course, as in Algorithm 2 below. If the answer is yes, the student is unenrolled from the course by removing the course detail from his/her StudentEnrolment asset. Moreover, the number of enrolled students in the course is decreased by one in SemesterOfferings asset.

Access to resources or assets of BCHEEN is secured through access rules. Students and staff members will typically transact from inside their institutions, and each will have different access control requirements on the ledger, whilst at the same time will have the same access privileges to some shared data. Five rules were defined in BCHEEN. The first one is called StudentManageTheirEnrolmentOnly (see Figure 4). It allows students to manage their own enrollments only, i.e., read, create, and update their enrollment assets. It checks if the student id of the participant who is trying to transact is similar to the student id inside the enrollment asset. If so, the student will obtain full access to the enrolment asset; otherwise, the transaction will be denied.

The other four rules are related to staff members. The second rule is called StaffUpdateTheirInstutionInfoOnly. It ensures that a staff member can only update his/her own institution’s information. The third one is called StaffRegTheirInstutionStudents-Only. It ensures that staff members can register their institution’s students only. The fourth rule ensures that only staff members of an institution can add that institution’s course offerings. This rule is called StaffAddTheirInstitionOfferingsOnly. The last rule is called StaffManageEquivalentCourses. It grants staff members access to read and update privileges on equivalent courses assets.

Algorithm 1: EnrollInCourse()

Input: Student, SelectedCourseCode, VisitedInstitution, Year, Semester

function enroll StudentInCourse()

get student academic status from studentDegree asset

get if the student has already studied and passed the course from StudentDegree asset

if the student academic status is not enrolled or student has studied and passed the course:

poduce an error message

else

get total credit hours that student registered in the current semester from StudentEnrolment asset

get if the student is currently enrolled in the course from StudentEnrolment asset

if total credit hours of current semester greater than or equal student maximum load or student is currently enrolled in the course:

produce an error message

else

get if the student is allowed to study the course from StudentDegree asset and

SemesterOfferings asset

get if the student studied all the course prerequisites from StudentDegree asset and SemesterOfferings asset

if the student is not allowed to study the course or student has not completed all prerequisites:

produce an error message

else

get if the course is offered in the VisitedInstitution from SemesterOfferings asset

get if the current date is within the enrollment dates from SemesterOfferings asset

get if the maximum number of students who can study the course has been reached from SemesterOfferings asset

if the course is not offered in the VisitedInstitution or the current date is not within the enrollment dates or the maximum number of enrolled students has been reached:

produce an error message

else

Add selected course to StudentEnrolment asset

Increase number of enrolled students in the course by 1 in SemesterOfferings asset

Get StudentFiles asset

Emit SuccessEnrollNotification event and return StudentFiles asset to the application

end function

Algorithm 2: WithdrawFromCourse()

Input: Student, SelectedCourseCode, VisitedInstitution, Year, Semester

function enrollStudentInCourse()

Get if the student is enrolled in the course from StudentEnrolment asset.

if the student is not enrolled in the course:

Produce an error message

else:

Get total credit hours that the student will be registering after dropping the course from StudentEnrolment asset

if total credit hours after dropping the course will be less than the student’s minimum load:

Produce an error message

else:

Get if the current date is within the withdrawal dates from SemesterOfferings asset

if the current date is not within the withdrawal dates:

Produce an error message

else:

Remove the selected course from StudentEnrolment asset

End function

6. Results and Analysis

BCHEEN was evaluated by using two evaluation approaches: functional testing with the Cucumber tool and performance testing with Hyperledger Caliper. Its security and computational cost were also analyzed.

6.1. Functional Testing

Functional testing was used in this study to determine whether the different transactions of BCHEEN are accurate and reliable. It was necessary to perform this testing to ensure that BCHEEN works in the desired way and that the quality of the produced output is satisfactory. To conduct the functional testing, three steps were performed. First, a test plan was established to identify components of BCHEEN that need testing. Second, several test scenarios were developed to test the transactions. Finally, the Cucumber tool was used to execute the test scenarios. A well-known method called ‘Equivalence Class Partitioning’ was utilized to develop these scenarios [54]. By applying the method, it was found that thirty-four test scenarios are needed to test the functionality, as well as some security aspects, of the BCHEEN transactions.

After identifying the test scenarios, Cucumber tool was used to execute them. A Cucumber test file was developed to conduct the test. The file has two parts: a background section where test assets and participants are defined, and a scenarios section, where the different test scenarios are listed. In the background section, two institutions were defined as Institution A and Institution B. For each institution, several courses were added. These courses have different prerequisites and different credit hours. In the second section of the Cucumber test file, the thirty-four test scenarios were declared. Each scenario was written using Gherkin syntax, which identifies the following four steps: Scenario, When, And, Then. Figure 5 shows how Gherkin syntax was used to write a test scenario in which a student who meets all the enrollment conditions tries to enroll in a course available for enrollment.

To summaries the test execution results, testing metrics were created.

Table 1. Functional testing metrics.

Transaction	Number of Test Scenarios
Number of test scenarios designed:	34
Number of test scenarios executed:	34
% of test scenarios executed:	100%
% of test scenarios passed:	100%
% of test scenarios failed:	0%

shows the functional testing metrics of BCHEEN. As can be seen, all test scenarios passed with 100% of the tests performed being successful. This implies that BCHEEN algorithms were successfully implemented and that the transactions work in the desired way.

6.2. Performance Testing

This testing was conducted to measure two key performance indicators of BCHEEN, namely latency, and throughput. Latency refers to the amount of time required for a transaction to be executed across the Hyperledger Fabric network, while throughput is the number of transactions performed by the network per second [55]. The Hyperledger Caliper was used as a performance evaluation tool. Hyperledger Caliper enables software engineers to measure the performance of a specific blockchain application with predefined use cases. It generates reports that contain several performance indicators, including latency and throughput [56].

The test machine was a Linux Ubuntu 18.04 with 4 GB RAM. Two configuration files of Hyperledger Caliper were modified to identify the test settings. The first one is the network configuration file, and it was updated to describe the target blockchain network, including its topology. The second one is a benchmark configuration file that was modified to include the test rounds that Caliper should execute, including the send rate and the workload content. The target blockchain network was a 2-organization-2-peer network (2 peers for each organization).

Ten test rounds were designed with different number of transactions and send rate in each round. The test file was developed so it targets the seven transactions of BCHEEN. The test was run several times, to measure the average performance with minimum error probability. The send rate gradually increased from 8 to 52 tps. As can be seen in Figure 6, the average latency increases consistently until the send rate reaches 40 tps. After that, the latency decreases to 4.32 s at the send rate of 47 tps. Throughput, on the other hand, grows until it reaches a peak of 18 tps at a send rate of 47 tps. It then decreases to 16 tps at the send rate of 52 tps (see Figure 7). These performance evaluation results indicate the efficiency of BCHEEN.

6.3. Security Analysis

The BCHEEN platform has been designed with robust security features to address key challenges associated with educational cooperation, specifically focusing on data integrity, privacy, and secure transactions. Leveraging blockchain technology, BCHEEN offers several layers of security to ensure transparency, accountability, and confidentiality, while providing a decentralized solution for higher education institutions.

• Decentralized security and trust: BCHEEN is built on a permissioned blockchain architecture using Hyperledger Fabric, which ensures that all participating educational institutions have known identities, providing an added layer of trust compared to traditional permissionless blockchains. The decentralized nature of the platform eliminates the need for a central authority, thus reducing the risk of a single point of failure and unauthorized tampering. Each institution contributes nodes to the network, and transactions are validated through a consensus mechanism, ensuring consistency and resilience in the face of potential failures.
• Data integrity and immutability: Blockchain’s inherent immutability plays a critical role in ensuring the integrity of student records and enrollment data. All transactions, including enrollments, course modifications, and academic records, are recorded on the blockchain ledger. Once a transaction is added to the ledger, it cannot be altered or deleted, thus guaranteeing data consistency and preventing any unauthorized modifications. This feature is especially crucial in managing sensitive academic data, ensuring that all stakeholders can trust the authenticity of the records.
• Smart Contract-Based access control: BCHEEN uses smart contracts to enforce access-control policies autonomously. These smart contracts define and enforce the rules for data access, ensuring that only authorized participants can interact with specific data. The use of smart contracts minimizes the risk of human error and fraudulent activities, as all access decisions are governed by pre-defined, transparent policies. For instance, course enrollments and withdrawals are automatically validated based on predefined eligibility criteria, preventing unauthorized actions and ensuring accountability.
• Security against common blockchain threats: to mitigate risks commonly associated with blockchain systems, BCHEEN incorporates several defensive measures. MSP is used to manage identities, ensuring that only authenticated and authorized participants can join the network and initiate transactions. Channels are used within the Hyperledger Fabric network to create private communication groups among institutions, enabling secure data exchange while keeping sensitive information isolated from unauthorized participants. The permissioned nature of the blockchain reduces the likelihood of attacks such as a 51% attack, as only trusted nodes participate in the consensus process. Furthermore, the distributed architecture ensures that the system remains operational even if some nodes are compromised.
• Auditability and transparency: one of the core benefits of using blockchain technology in BCHEEN is the ability to provide a transparent and auditable record of all transactions. This transparency enhances trust among stakeholders, including students, instructors, and administrators. Any changes made to student records, enrollments, or academic information are permanently recorded on the blockchain, allowing authorized users to trace and verify the history of all transactions. This feature not only ensures accountability, but also simplifies the audit process for educational institutions.

6.4. Computational Cost Analysis

With the “replicate when used” approach, file availability grows dynamically with demand. Files are initially stored in the “home organization’s” peer storage and replicated to other peers when requested. This approach guarantees availability only in proportion to the demand for the file. If many organizations request the file, it will have more replicas across the network, which increases availability. However, until a file is requested by other peers, it remains stored only in one location, potentially leading to lower availability initially or in low-demand scenarios. Availability here relies on the network’s request pattern and storage space within each organization’s peer.

Hash computation: a hash is generated for each file, which is stored on-chain. The computational cost of this is $O\left(n\right)$, where n is the size of the file, as hash functions typically operate linearly with file size.

File transfer and replication: each file transfer to another organization’s storage incurs a cost $C_{trans}$, and this transfer only occurs when the file is requested by a new organization. If a file is replicated $m$ times (where m depends on the number of requests), the total computational cost for replication across the network can be approximated by:

$$C_{total}={m\times C}_{trans}$$

Thus, the computational cost for replication scales with demand, but does not have to replicate proactively across all nodes.

7. Discussion

BCHEEN was designed as a decentralized platform to provide a fully automated enrollment process. Educational institutions can use BCHEEN to share lists of equivalent courses, set the enrollment conditions, and offer courses to be available for enrollment by students from other institutions. Students can then use BCHEEN to browse lists of available courses and then directly enroll to one of them. The functional testing that has been presented in the previous section shows that BCHEEN is capable of delivering theses functionalities.

By designing it on Hyperledger Fabric, BCHEEN inherits blockchain’s advantage of decentralization, reliability, transparency, accountability and security. Students’ data are appended in a distributed ledger and replicated all over the network, which creates a strong recovery mechanism and eliminates the single point of failure associated with centralized systems. Enrollment transactions are only committed to the ledger after students meet all enrolment conditions and after all participating peers verify the authority and identity of the client who submitted the request. Students’ transactions histories are available on the network; thus, participants can see and examine the available data and verify any changes made to them. All students’ data on the blockchain are hashed and cannot be changed or tampered with; thus, these data are secure and trusted.

The proposed BCHEEN network is designed to dynamically scale, based on the resources contributed by participating institutions. Each institution can provide a varying number of peers, depending on its size and student population. Smaller institutions may contribute fewer peers, while larger institutions can provide more, ensuring the network remains scalable and resource-efficient. This flexibility allows BCHEEN to accommodate a wide range of educational contexts, from small colleges to large universities, while maintaining robust functionality and seamless collaboration across diverse systems.

The performance evaluation of BCHEEN highlights its scalability and efficiency. The platform achieved a peak throughput of 18 tps at a send rate of 47 tps, with an average latency of 4.32 s under the same conditions. These results are comparable to the average performance reported for similar Hyperledger Fabric platforms [57,58]. For example, Nasir et al. [59] observed a transaction latency of 3.5 s with a throughput of 15 tps under similar conditions. Melo, Gonçalves, Silva and Soares [55] evaluated a Hyperledger Fabric deployment and reported latencies ranging from 2.8 to 3.6 s with a throughput of up to 20 tps. Additionally, Tanwar, Parekh and Evans [58] measured transaction latencies of 3.2 to 4.0 s on a permissioned blockchain system optimized for healthcare applications. Overall, the performance results of BCHEEN are consistent with these reported benchmarks, demonstrating its reliability and scalability for high-volume institutional collaborations.

The approach that has been used to store large students’ files, in which only the hashes of these files are stored on-chain while the actual files are kept off-chain, was successful in not affecting the performance of BCHEEN. It also allows for ensuring the integrity of data files, since a modification in a file would immediately change its hash. The replicating mechanism of off-chain data, i.e., “replicate when used” seems to be useful in not compromising the distinguishing features of blockchain technology and at the same time ensuring an efficient use of available storage spaces. By applying this mechanism, it could be ensured that BCHEEN has no single point of failure, and that large data files are available from different sources when they are needed.

This approach addresses several limitations observed in previous studies. For instance, Kaur et al. [60] proposed integrating blockchain with IPFS for off-chain storage, which improves scalability but relies on the availability of peers for file retrieval. In contrast, BCHEEN’s approach ensures that files are dynamically replicated to nodes only when required, guaranteeing their availability during cross-institutional enrollment processes without relying on peer seeding. Similarly, Xu et al. [61] introduced SlimChain, a stateless blockchain system that scales transactions through off-chain storage and parallel processing. While SlimChain improves scalability by keeping only short commitments of ledger states on-chain, it may struggle with the integrity of off-chain data in scenarios involving multiple distributed entities. BCHEEN addresses this limitation through its “replicate when used” approach, which ensures that off-chain data remain both verifiable and accessible across institutions without requiring excessive replication or centralized management.

From a computational cost perspective, the “replicate when used” approach optimizes storage efficiency by minimizing unnecessary data replication. This ensures that storage and processing costs scale dynamically with usage, making the platform resource-efficient while maintaining high availability and security standards. These features collectively contribute to a resilient, secure, and cost-effective system that addresses the operational challenges of inter-institutional collaboration.

The proposed BCHEEN platform incorporates robust security measures, leveraging the inherent immutability and transparency of blockchain technology to ensure data integrity and accountability. By employing a permissioned blockchain model using Hyperledger Fabric, BCHEEN restricts access to authenticated participants, reducing vulnerabilities such as unauthorized access and tampering. Furthermore, the use of smart contracts for transaction validation automates and secures data sharing among institutions [62].

The BCHEEN platform has significant implications for building a sustainable digital infrastructure in higher education. By enabling seamless, transparent, and secure cross-institutional enrollment processes, it addresses critical pain points that have historically hindered collaboration. Its decentralized architecture fosters greater institutional autonomy, while ensuring data reliability and scalability. Moreover, BCHEEN’s innovative approach to off-chain data management aligns with principles of sustainability by reducing the carbon footprint associated with extensive data replication. By automating enrollment processes and eliminating administrative redundancies, the platform reduces operational costs and enhances resource utilization, contributing to long-term sustainability. Beyond administrative efficiency, BCHEEN supports a broader vision of interconnected and cooperative education systems, paving the way for a more inclusive and accessible higher education ecosystem [63,64].

Regarding scalability, BCHEEN’s decentralized design and the innovative “replicate when used” mechanism ensure that the platform can grow dynamically with the needs of participating institutions. By allowing institutions to contribute resources proportionally to their size and usage, BCHEEN accommodates small and large institutions without compromising performance or functionality. This flexibility enhances its practical application across diverse educational contexts and supports sustainable resource allocation by minimizing unnecessary data replication and storage demands. Compared to traditional centralized systems, this architecture reduces infrastructure strain, making it a more environmentally and economically sustainable solution for managing cross-institutional enrollment processes [31].

The reliability and efficiency of BCHEEN also stand out as critical features that contribute to its sustainability. Leveraging Hyperledger Fabric’s permissioned blockchain architecture, the platform ensures secure and transparent transactions, eliminating vulnerabilities associated with centralized systems [62]. Integrating smart contracts automates data validation and enrollment processes, reducing human errors and administrative overheads. This automation further enhances the platform’s energy efficiency, as fewer resources are needed to handle repetitive tasks manually. Moreover, the decentralized nature of BCHEEN supports business continuity by eliminating single points of failure and ensuring that institutional operations can persist even in the event of localized disruptions [55,65]. These attributes collectively make BCHEEN a robust and scalable solution that addresses operational challenges and aligns with global efforts to reduce the environmental impact of digital infrastructures in higher education.

8. Limitations

While BCHEEN demonstrates promising scalability, reliability, and efficiency, this study has certain limitations. The platform’s performance evaluation was conducted in a controlled environment, which may not fully capture the complexities of real-world deployment scenarios. The evaluation primarily focused on technical metrics such as latency, throughput, and computational cost, leaving out usability testing and user experience analysis, which are critical for adoption in diverse educational institutions. Additionally, while the “replicate when used” approach optimizes storage, its long-term performance and resource requirements in highly dynamic environments remain unexplored. Further investigation should focus on large-scale testing across multiple institutions, including comprehensive user studies, and evaluate the platform’s performance under varying network and operational conditions, to ensure its broader applicability and robustness.

9. Conclusions and Future Work

This paper proposed and implemented a new blockchain-based platform called BCHEEN. The main aim of BCHEEN is to facilitate educational cooperation among higher education institutions. BCHEEN is a first step toward a cooperation platform for higher education. It represents the basis of a bigger initiative, where interested national institutions could cooperate in the offering of joint academic programs and joint research training. BCHEEN exploits the decentralization nature of blockchain technology to provide a reliable, transparent, immutable, accountable, secure, and cost-effective solution. It smartly manages the storage of students’ files off-chain and on-chain by utilizing a novel approach called “replicate when used”, thus not affecting the performance and scalability of the platform. BCHEEN was evaluated in terms of functionality and performance. Evaluation results show that BCHEEN is feasible. Its decentralized architecture reduces reliance on centralized systems, improves data reliability, and eliminates single points of failure. By automating processes, it minimizes administrative overheads and operational costs. Additionally, the platform aligns with principles of sustainability by optimizing resource use, reducing redundancy, and limiting the environmental impact associated with traditional data storage and processing systems.

This study has opened up new research areas for further improvements and future work. Important future work will be to invite several national educational institutions to test and use BCHEEN in a real-life environment. Pilot programs could be conducted across institutions of varying sizes, administrative structures, and technological capabilities, to assess the platform’s adaptability and performance under different operational conditions. In this way, the presented prototype could be further validated and improved. A successful trial of BCHEEN could result in establishing it as a national cooperation system. Other future work will be to extend BCHEEN so it can be used by educational institutions to offer joint academic programs. Educational institutions can utilize BCHEEN to manage students’ enrollment in these programs. BCHEEN can check the eligibility of students before enrolling them in the joint programs that they have selected. BCHEEN can also be programmed to ensure even distribution of program courses among the participating institutions. This would help educational institutions promote sustainability and reduce operating costs by using shared infrastructure, services, and academic programs. Furthermore, exploring BCHEEN’s potential to support seamless cross-institutional collaboration in joint academic programs would include simulating scenarios where multiple institutions collaborate to offer shared degree programs, manage shared course completions, and securely maintain academic records. This would increase students’ flexibility by granting them access to the full breadth of academic programs at every participating institution. Future work will also include analyzing the environmental impact of BCHEEN, particularly the energy consumption of the ’replicate when used’ approach. By dynamically replicating files only when needed, this method is expected to reduce unnecessary data replication and minimize the network’s carbon footprint. A detailed energy consumption analysis will further quantify these benefits and validate BCHEEN’s alignment with sustainability goals.