The Blockchain-Based Multifunctional Educational Documents Verification System

Abstract

The digital transformation of higher education has heightened the need for reliable mechanisms to verify the authenticity, integrity, and independence of academic documents. This study presents the design and practical implementation of a blockchain-based, multifunctional educational document verification system for the higher education environment of the Republic of Kazakhstan. The proposed system is presented by a hybrid multi-layered architecture that integrates a frontend web portal, a C# ASP.NET backend service, a PostgreSQL off-chain database, a Smart Bridge integration subsystem, and an Ethereum-compatible blockchain layer with Solidity smart contracts. The system separates operational educational data from trust-sensitive verification records: student, graduate, catalog, and document metadata are stored off-chain, while selected transcript and diploma-related data are registered on-chain and linked to transaction hashes. The Smart Bridge subsystem enables secure interaction with state information systems via SOAP/XML and digital signatures, improving the reliability of personal data used in academic record processing. The blockchain implementation uses transaction hashes, event logs, BlockScout monitoring, and role-based smart-contract authorization to support traceability and tamper-resistant verification. Experimental implementation showed an average gas consumption of approximately 226,125 gas per transaction. The proposed system demonstrates that blockchain extends existing centralized educational infrastructures by adding a transparent, auditable, and user-accessible trust layer for academic document management and verification.

1. Introduction

The digital transformation of higher education has significantly changed the way universities manage academic processes, store institutional data, and provide services to students, graduates, administrators, and external stakeholders [1]. Over the last two decades, higher education institutions have moved from paper-based, fragmented administrative procedures to integrated digital ecosystems that support admissions, course registration, learning management, grading, academic mobility, transcript generation, diploma issuance, and institutional reporting. In this transformation, educational information systems have become a critical infrastructure layer for modern universities, supporting not only internal academic workflows but also interactions with ministries, various educational organizations, and employers. As a result, the reliability, integrity, and long-term availability of academic data have become central requirements of digital higher education governance [2].

At the same time, the rapid digitization of educational services has exposed persistent weaknesses of conventional centralized architectures [3]. Although university information systems and national educational platforms have improved efficiency, they still rely mainly on trusted central databases and institution-specific procedures. In practice, this means that the authenticity of academic documents often depends on the issuing institution, manual verification, and formal requests. Such an approach creates delays, increases operational costs, and is influenced by human errors, inconsistent data exchange, and unauthorized record modifications. Centralized storage also raises long-term concerns related to interoperability, platform migration, and trust across institutional boundaries, especially when external organizations or foreign universities must verify academic records [4].

These limitations have prompted researchers to examine blockchain technology as a new trust mechanism for educational environments. Blockchain is increasingly viewed not just as a financial technology but also as an infrastructure for tamper-resistant recordkeeping, decentralized verification, and programmable data governance. In educational contexts, blockchain has been proposed for the registration and verification of diplomas, transcripts, certificates, and other achievements. When combined with smart contracts, blockchain can formalize the rules for issuing, registering, and validating academic records, thereby transforming verification from a manual administrative procedure into an automated, auditable digital process [5].

Recently, blockchain-based educational solutions have evolved from theoretical proposals to more structured architectures that combine on-chain and off-chain components. Early approaches often focused solely on certificate hashes to public blockchains, primarily to prove authenticity [6]. More recent systems aim to support richer educational workflows, including access control, revocation, document retrieval, and integration with institutional databases. This evolution is important because higher education systems do not operate as isolated certificate issuers. They are complex, multi-actor environments in which academic records are generated gradually across semesters, disciplines, and study programs, while different stakeholders require different levels of access, privacy, and verification. Therefore, the development of blockchain applications in education has increasingly shifted toward hybrid architectures that preserve critical trust-sensitive data on-chain while maintaining large data collections and services off-chain [7].

This hybrid direction is particularly relevant for countries that already possess an advanced digital higher education infrastructure. In such cases, blockchain should not replace the existing educational ecosystem, but extend it by adding a transparent verification layer and stronger protection against tampering [8]. This is the situation in the Republic of Kazakhstan, where the digitalization of higher and postgraduate education has developed within the framework of government and educational reforms. Kazakhstan has already established a relatively developed digital environment in higher education, where universities use learning management systems (LMS), electronic journals, academic registration tools, student information systems, and web-based services for transcript and diploma processing. At the national level, these institutional systems are connected to the Unified Platform of Higher Education (UPHE), which acts as a centralized environment for aggregating and supervising academic data flows across higher education institutions [9].

The existence of UPHE is a major structural advantage for the development of a blockchain-enabled educational platform in Kazakhstan. Unlike many previously published blockchain credential systems designed as stand-alone solutions for isolated verification tasks, Kazakhstan’s infrastructure already includes a functioning national platform that integrates universities, academic records, and administrative services within a common digital framework. According to the earlier conceptual model, UPHE already consolidates academic data from more than one hundred higher education institutions and supports large-scale interactions between universities and the Ministry of Science and Higher Education (MSHE). This means that Kazakhstan does not need to build a national educational platform from scratch. Instead, it can enhance an existing centralized platform by introducing decentralized smart-contract logic and hybrid storage mechanisms [10].

Nevertheless, the current architecture also reveals a clear technological lack of decentralized mechanisms for registration, cryptographic proof of authenticity, and independent verification of academic credentials. In its traditional form, such a system remains vulnerable to different record changes, limited transparency for external verifiers, and dependence on institutional mediation [11]. These issues become especially important in the context of cross-university communications, employer verification, and the growing internationalization of higher education. Therefore, the next stage of digital development is not only broader automation, but also the establishment of a trust-preserving infrastructure for educational documents.

The scientific problems investigated in this study are not only the technical implementations of a new educational information system, but also the design and validation of a hybrid trust-preserving architecture that can extend an existing centralized higher education infrastructure with blockchain-based mechanisms for independent verification, integrity control, traceability, and auditability of academic documents. The practical development objective concerns the development of a multifunctional blockchain-based educational document verification platform for the higher education environment of the Republic of Kazakhstan. The developed system integrates a C# ASP.NET 9 backend service, a PostgreSQL off-chain database, a Smart Bridge integration subsystem, an Ethereum-compatible blockchain layer with Solidity smart contracts, and a frontend web portal. The scientific objective is to determine how centralized educational databases, government service integration mechanisms, and decentralized smart contract logic are combined into an architecture that preserves the efficiency of conventional educational systems while adding tamper-resistant verification of trust-sensitive academic records. The study explores research questions on how blockchain technologies are integrated into an existing centralized higher education information infrastructure without replacing current LMS, database, and administrative services, operational educational data and trust-sensitive verification records are separated between off-chain and on-chain layers to preserve performance, privacy, and verifiability, Smart Bridge interaction with state information systems improves the reliability of student and graduate identification before registration of academic records in the blockchain layer, and the evaluation of feasibility of the proposed architecture through measurable technical indicators such as transaction hashes, event logs, blockchain monitoring, and gas consumption.

There are also several hypotheses that are observed in this research. First, a hybrid architecture that stores operational educational data off-chain and registers selected transcript and diploma-related data on-chain provides independent verification of academic documents without overloading the blockchain ledger. The use of smart contracts, transaction hashes, event logs, and role-based authorization increases the traceability and tamper-resistance of academic record verification compared with purely centralized verification procedures. The integration of Smart Bridge-based official data exchange before blockchain registration improves the reliability and consistency of student and graduate identification data used in academic document processing.

In this context, the development of a blockchain-based educational platform for Kazakhstan should be understood as a system-level extension of the existing higher education ecosystem. Such a platform can combine four complementary layers. The first layer is the web application, which provides access for students, graduates, administrators, and employers. The second layer is the off-chain data infrastructure, implemented using a PostgreSQL database and ASP.NET web services, that efficiently stores and processes metadata, catalogs, and operational educational data. The third layer is the blockchain layer, where critical trust-sensitive records, such as transcript entries and diploma-related data, are anchored through smart contracts and made independently verifiable. The fourth layer is the Smart Bridge integration subsystem, which enables secure and legally significant data exchange with information systems and external government services. This layer supports standardized SOAP/XML-based communication, electronic digital signature mechanisms, and controlled access to official personal data, improving the correctness and reliability of student and graduate identification of academic records.

As the unified use of hybrid on-chain and off-chain storage, role-based smart-contract authorization, transaction hashes, blockchain events, and web-based credential verification mechanisms are already implemented in many blockchain-based educational management systems, the main focus of this system’s implementation lies in the development of a hybrid blockchain-based educational document verification model that is adapted to a national higher education infrastructure rather than designed as a stand-alone credential verification tool. Thus, the novelty of the work lies in the coordinated integration of these mechanisms into a multifunctional educational document verification architecture adapted to a national higher education system, rather than in the invention of a new blockchain algorithm or cryptographic primitive.

Unlike systems that focus mainly on storing certificate hashes or issuing digital credentials, the proposed system combines backend educational data management, PostgreSQL-based off-chain storage, Ethereum-compatible smart contracts, transaction-hash-based verification, role-based blockchain authorization, Smart Bridge-based interaction with state information systems, and a user-oriented frontend environment. This combination enables the platform to support not only diploma or certificate verification, but also transcript registration, document metadata management, official personal data verification, institutional catalog standardization, and practical access for students, graduates, universities, administrators, and external verifiers. In this architecture, off-chain components improve the performance, flexibility, and usability of conventional educational systems, while the blockchain layer ensures integrity, traceability, and resistance to unauthorized alteration. This whole architecture and the functionality of all its components are thoroughly described in the subsequent sections.

The rest of the paper is organized as follows. Section 2 provides a literature review of blockchain-based educational systems, academic credential verification, hybrid on-chain and off-chain storage, smart contract access control, and educational record management. Section 3 presents the study’s methodology, including the development context of LMS systems in Kazakhstan, the architecture of the proposed blockchain-based educational platform, and the trust and threat model. Section 4 describes the practical implementation of the platform, including the backend service, the blockchain, the Smart Bridge integration layer, and the frontend application. Section 5 presents the system evaluation, including blockchain transaction measurements, functional smart contract testing, concurrent transaction evaluation, database and blockchain consistency testing, security-oriented testing, and a comparison with a centralized baseline. Section 6 discusses the main findings, compares the proposed platform with existing systems and alternative approaches, and outlines limitations, unexpected outcomes, and future development directions. Finally, Section 7 summarizes the conclusions of the study.

2. Related Works

Research on blockchain in educational systems has expanded significantly in recent years and covers several interconnected directions, including academic credential verification, secure storage of educational records, access control, privacy preservation, and integration with institutional information systems. One of the earliest and most common application areas is the use of blockchain for verifying diplomas, certificates, and transcripts. In such systems, the main idea is usually not to store the full educational document on-chain, but to anchor either its Hash, proof, or selected metadata in a blockchain ledger, enabling independent verification. A common concern across these studies is that traditional educational document management still depends heavily on centralized institutional databases and manual verification procedures. As a result, universities, employers, and public authorities often face delays, administrative burdens, and risks related to unauthorized record modifications.

The first direction concerns blockchain as a mechanism for academic credential verification and lifelong learning records. Ref. [12] provides a systematic literature review showing that blockchain has been widely proposed to improve integrity, transparency, and verifiability in education. Their review is important because it frames blockchain not as a universal solution but as a technology whose benefits depend on the educational context, data-governance model, and deployment constraints. They also emphasize that many blockchain-based educational systems remain at the prototype or proof-of-concept stage, which highlights the need for practical implementation and evaluation. Ref. [13] extends this discussion by presenting blockchain as a mechanism for reducing credential fraud and supporting a lifelong learning passport. In their view, blockchain can record not only formal certificates, but also learning activities, skills, achievements, and learner identity across time. Ref. [14] broadens the discussion by analyzing blockchain in education management, including student record management, certification, assessment, institutional administration, and secure academic data exchange. Together, these studies establish the first framework for the present research: academic document verification should not be limited to checking a final diploma, but should support broader educational record management, stakeholder trust, and long-term verifiability.

The second direction concerns hybrid on-chain and off-chain data architecture. A common conclusion in the literature is that storing complete educational records directly on-chain is usually inefficient and problematic for privacy. Ref. [15] presents a blockchain-based education platform that combines Ethereum smart contracts with off-chain storage. This demonstrates that blockchain can be used to manage identity and certificate verification logic, while supporting information and documents can remain outside the ledger. Ref. [16] analyzes decentralized storage based on blockchain and IPFS and shows how blockchain can store hashes, references, or content identifiers while the actual data remains off-chain. Although this work is not limited to education, it provides an important architectural principle for educational systems: blockchain should be used as an integrity and verification layer rather than as a full data-storage repository. Ref. [17] proposes EduASAC, where large educational archive data are stored off-chain in encrypted form, while the blockchain manages access control, security parameters, system behavior records, and verification processes. These studies form the second framework for the present research: educational document platforms require hybrid storage, in which operational data remain off-chain, while only verification-critical commitments, hashes, events, or transaction references are registered on-chain.

The third direction concerns smart contracts, access control, privacy, and governance. Educational records are not public documents that can be freely written, read, or modified by any user. They require controlled registration, authorized access, correction procedures, and institutional responsibility. Ref. [18] proposes a blockchain-based electronic educational document management system with role-based access control, showing that smart contracts can transparently govern permissions and record access operations. Ref. [19] focuses on smart-contract-based higher education systems and the role of scaling mechanisms, including zero-knowledge Ethereum Virtual Machine approaches. Their study is important because it moves the discussion beyond immutability and highlights transaction performance, gas cost, and scalability as essential criteria for blockchain-based higher education platforms. The presented research works are summarized by their contributions and implications in groups, shown in Table 1.

Table 1. Contributions and implications of research works.

No	Analytical Direction	Main Contribution from the Literature	Implication for the Proposed Study
[12,13,14]	Academic credential verification and lifelong learning records	Blockchain can improve integrity, transparency, portability, and independent verification of educational credentials and learner records	The proposed platform should support not only final diploma verification, but also transcript and academic-record verification
[15,16,17]	Hybrid on-chain/off-chain architecture	Complete educational records should not be stored directly on-chain; blockchain should store hashes, references, commitments, or verification evidence.	PostgreSQL should store operational educational data, while blockchain should store verification-critical evidence and cryptographic commitments.
[18,19]	Access control and governance	Educational records require role-based authorization, permissioned participation, and controlled access.	The platform should include backend RBAC and smart-contract-based authorization.
[12,16,19]	Privacy and sensitive data protection	Educational records contain personal and academic data that should not be unnecessarily exposed on-chain	Raw personal and academic data should remain off-chain; blockchain should store only commitments or verification references.
[12,19]	Deployment maturity	Many blockchain-in-education systems remain conceptual or prototype-based	The proposed system should be validated through implementation, testing, transaction monitoring, and discussion of deployment limitations

Based on the presented research groups, the reviewed literature provides a clear framework for designing blockchain-based educational document verification systems. First, blockchain can strengthen trust in academic credentials, but it should be applied to clearly defined verification problems rather than used as a general replacement for educational databases. Second, hybrid architecture is necessary because full on-chain storage of educational documents is inefficient and privacy-sensitive. Third, smart contracts must be combined with role-based access control, as academic records involve multiple stakeholders and varying authorization levels. Fourth, scalability, usability, and deployment maturity must be evaluated because many existing solutions remain conceptual or prototype-based.

3. Methodology

3.1. The Development of LMS Systems in the Republic of Kazakhstan

In the Republic of Kazakhstan, the digital transformation of higher education has been actively developing within the broader context of the electronic government, educational systems, and the automation of university services. Over the last decade, universities have adopted LMS, academic automation tools, and digital services to generate forms, academic transcripts, and other documents. These systems have become an important part of the national higher education infrastructure because they support curricula management, student attendance and records, individual study plans, assessment results, schedules, and interactions among students, instructors, advisors, registrar offices, and administrative departments. Among the most widely used systems in Kazakhstan are Univer 2.0, Platonus, Sirius, Tamos System, and Electronic Rectorate. These platforms have significantly reduced manual paperwork and improved the efficiency of internal academic processes by centralizing educational data and automating many routine operations. For example, Al-Farabi Kazakh National University uses the Univer 2.0 LMS to manage the educational process, Moodle for distance and blended learning, and open online course platforms to expand access to digital educational resources.

However, despite the high level of automation, most existing LMS and university information systems infrastructure in Kazakhstan remains centralized. Critical academic documents, such as certificates, transcripts, course records, diplomas, and diploma supplements, are typically stored in institutional databases maintained by a specific university or platform provider. This architecture is effective for internal administration, but it does not fully address the challenges of long-term data integrity, independent verification, trusted interuniversity exchange, and reliable document validation in national or international contexts. Centralized repositories may be exposed to risks such as unauthorized record modification, administrative errors, software migration issues, reliance on a single issuing institution, and difficulties proving the authenticity of academic documents. Therefore, the development of a blockchain-based system is a significant improvement to Kazakhstan’s digital higher education infrastructure. Such a system is not intended to replace existing LMS platforms, but to complement them with an additional trusted verification layer.

In the proposed methodology, existing LMS systems act as the primary sources of academic data, while the blockchain layer provides cryptographic registration and independent verification of selected records. When a transcript or other academic document is generated in an institutional platform, its essential verification data can be transferred to the blockchain-based system and recorded as a tamper-resistant transaction. This allows confirming the document’s authenticity without relying solely on the issuing university’s internal database. The use of smart contracts further strengthens this process by formalizing the rules for transcript registration, access control, role-based authorization, and verification. As a result, universities, students, employers, accreditation bodies, and government agencies can verify academic records through a transparent and auditable mechanism.

Thus, developing a blockchain-based system for Kazakhstan’s LMS environment can enhance the integrity and reliability of educational data in several ways. It provides integrity, as once a record is registered on the blockchain, it cannot be changed without leaving a trace. It improves reliability by creating a verifiable link between the original academic document and its cryptographic representation in the distributed ledger and strengthens trust between institutions by enabling independent verification of transcripts and other academic documents. It is also necessary to highlight that the processing of educational documents involves personal and academic data that may be sensitive and permanently linked to a specific individual. Therefore, the proposed platform must be designed in accordance with privacy-by-design and data minimization principles. The blockchain layer should not be used as a storage location for raw personal identifiers, subject names, grades, ECTS credits, diploma numbers, educational-program details, or other directly linkable academic attributes. Even in a permissioned blockchain network, on-chain data may be replicated across validator nodes, retained for a long period of time, and difficult or impossible to delete. Therefore, placing raw academic or identity data on-chain would create unnecessary privacy and compliance risks. In the presented data model, the blockchain stores only a cryptographic commitment to the academic record rather than the full record itself. The complete record remains off-chain in the PostgreSQL database or institutional information systems, where access control, correction procedures, and legal compliance mechanisms can be applied. Before blockchain registration, the academic record is transformed into a canonical representation, and a one-way cryptographic commitment is generated from this representation. Depending on the deployment policy, this commitment is implemented as a hash or a Merkle root commitment over a batch of records. The blockchain transaction stores this commitment along with minimal technical metadata, such as the issuer address, record type, schema version, timestamp, and smart contract event information. During a verification stage, an authorized verifier does not need to read raw grades or personal identifiers from the blockchain. Instead, the verifier obtains the relevant off-chain record through an authorized platform interface, recomputes the cryptographic commitment from the canonicalized record, and compares it with the commitment stored on-chain. If the values match, the verifier can confirm that the current off-chain record corresponds to the version registered in the blockchain. If the values differ, the record is considered inconsistent with its blockchain anchor. This mechanism provides tamper-evidence without permanently publishing personal or academic data in the distributed ledger.

Generally, the proposed blockchain-based solution should be considered as an infrastructural extension of Kazakhstan’s existing digital education systems, aimed at improving document authenticity, auditability, legal validity, and trust in academic record management.

3.2. The Architecture of the Blockchain-Based Educational Platform

The proposed educational platform was designed as a hybrid, multi-layered system that combines a conventional university information infrastructure with a blockchain-based trust layer for the secure registration and verification of academic documents. The architecture was developed specifically for the higher education environment of the Republic of Kazakhstan, where an existing centralized digital ecosystem already supports universities, student records, and educational workflows [20]. Rather than replacing that infrastructure, the proposed system extends it by introducing decentralized verification and transparent auditability for critical academic records. Its main functionality lies in integrating four coordinated parts within a single operational platform: the backend service, the Smart Bridge integration subsystem, the blockchain layer, and the frontend application layer. This architecture allows the system to preserve the performance and usability of traditional educational systems while adding secure government-service integration, data reliability, and the verifiability properties of blockchain.

From a methodological perspective, the system’s main design principle is hybrid separation of functions. The platform does not store all educational information directly on-chain because such an approach would be economically inefficient, technically rigid, and unsuitable for privacy-sensitive institutional data. The system’s architecture separates educational information into two categories. The first category includes metadata and operational data that are better managed in a local on-premises environment, such as discipline names, program structures, student profiles, university catalogs, and auxiliary document attributes. The second category includes critical trust-sensitive records, such as academic transcripts, diploma issuance data, and transaction confirmation traces that require immutability and independent verification. These critical records are processed by blockchain smart contracts and added to the distributed ledger [21]. Such a division is part of the system because it enables efficient interoperability between institutional educational databases and blockchain verification mechanisms without overloading the ledger with unnecessary document content.

The whole structure of the system with all modules is shown in Figure 1.

Figure 1. The architecture of the system.

The architectural structure is not interpreted as the isolated use of a web portal, a backend service, a relational database, a blockchain network, or a blockchain explorer, since these components are already well established in digital information systems. The distinctive contribution lies in the way these components are coordinated into a single national higher education document verification workflow.

The first component is the hybrid off-chain/on-chain data model. PostgreSQL is used as the operational off-chain database for student and graduate profiles, university catalogs, programs, courses, transcript and diploma metadata, and verification metadata. The Ethereum-compatible consortium blockchain is used only for verification-critical records, cryptographic commitments, transaction logs, smart-contract events, and role-controlled registration. This separation allows the platform to preserve the efficiency and flexibility of conventional educational databases while adding tamper-evident verification for selected academic records.

The second distinctive component is the backend layer. The backend not only exposes a REST API but also coordinates business logic, document generation, verification services, off-chain database interaction, and on-chain transaction submission via the on-chain API gateway. This makes the backend the central coordination mechanism between traditional university information systems, the Smart Bridge subsystem, PostgreSQL storage, blockchain smart contracts, and the frontend interface.

The third component is the Smart Bridge secure integration layer, which connects the platform to state information systems and external governmental services via standardized SOAP and XML exchanges, electronic digital signature mechanisms, and PDC access control. In the proposed workflow, Smart Bridge is responsible for trusted intersystem data exchange and identity-related verification before academic records are processed by the backend or anchored in the blockchain layer. This component is especially important for educational documents that must be linked to official identity data and institutional records.

The fourth component is the multi-role frontend environment. The web portal provides various functions for students and graduates, higher education institutions, employers, external verifiers, and ministry-level administrators. It hides the complexity of blockchain interactions by providing access to transcripts, diplomas, academic record dashboards, and credential verification through a user-friendly interface. This makes blockchain-based verification usable for non-technical educational stakeholders.

The fifth component is the audit and verification layer. The blockchain explorer and audit layer, such as BlockScout v11.0.3, supports transaction hash verification, event log inspection, and smart contract auditability. This enables external or authorized users to verify whether an academic record was registered, which transaction recorded it, which smart contract was used, and whether the current off-chain record corresponds to the on-chain evidence. Therefore, Figure 1 presents a domain-specific platform architecture for trusted academic document verification. Its contribution is the coordinated integration of Smart Bridge-based official data exchange, PostgreSQL-based off-chain educational data management, Ethereum-compatible smart contracts, transaction-hash-based verification, multi-role frontend access, and blockchain auditability within one educational document verification system adapted to Kazakhstan’s higher education infrastructure.

3.2.1. The Backend Architecture of the Platform

The backend layer is the central application and service layer of the proposed educational platform. Its main purpose is to coordinate the interaction between the frontend web interface, the PostgreSQL off-chain database, the Smart Bridge integration subsystem, and the blockchain network. While the frontend provides user interaction and the blockchain layer provides tamper-evident verification, the backend manages the platform’s business logic, data validation, access control, document-processing workflows, and communication with external services. The backend architecture is organized according to a layered software design. The Domain layer contains the core business entities, rules, events, and exceptions related to users, organizations, students, graduates, transcripts, diplomas, permissions, and blockchain-registration requests. The Application layer coordinates use cases, validation rules, data transfer objects, repository interfaces, and application services. It defines how business scenarios are executed without depending directly on database, frontend, or blockchain implementation details.

The backend architecture is shown in Figure 2.

Figure 2. The backend architecture.

3.2.2. Blockchain Architecture

The blockchain layer was introduced as the platform’s cryptographic trust infrastructure. Its purpose is not to replicate the full educational database, but to record and verify those elements of academic information that require immutability, transparent provenance, and resistance to unauthorized modification. The blockchain subsystem runs on an Ethereum-compatible environment, where the main business logic is implemented via smart contracts written in Solidity [22]. The architecture follows a modular contract design and includes at least three major logical components: a transcript-recording contract, a diploma-related contract, and an external role-based access control module. This modularity is central to the proposed methodology because it separates educational data management from authorization policy and allows the system to evolve without rewriting the entire blockchain logic.

The most important smart-contract component for transcript operations is the TranscriptStorage contract. This contract records essential academic performance data in the ledger, including identifiers related to the student, university, subject, academic period, grade, and ECTS value. Methodologically, this contract establishes the on-chain representation of transcript evidence. Instead of storing an entire transcript document as a monolithic object, the contract stores structured academic entries and emits blockchain events that can later be used for external verification. This event-based design is significant because it provides an immutable audit trail while keeping on-chain storage more efficient than full document preservation. The use of blockchain events for transcript registration also enables verification of educational records using transaction hashes and event logs, which is especially valuable for auditors, employers, and other universities [23]. In this part, the presented blockchain research is closely related to the previous publication [23], which specifically implemented blockchain and smart contract technologies for the storage and verification of academic transcripts in higher education systems. That work focused mainly on the blockchain layer, including smart contract transcript registration, transaction hashes, blockchain event logging, and verification of academic transcript records.

The second major blockchain component is the diploma-oriented contract, often described as DiplomaRegistry in the conceptual architecture. This contract is responsible for recording graduation-related information, including diploma number and series, qualification, educational program, dates of study, and university attributes. Its role is complementary to the transcript contract. While the transcript contract accumulates academic achievement evidence during the educational process, the diploma contract formalizes the final graduation result. Together, these contracts provide a lifecycle-oriented blockchain model: one smart contract secures academic progression, while the other secures credential issuance. This is a methodological advantage over narrower blockchain systems that only anchor a final certificate hash.

A further novelty of the blockchain architecture is the use of a separate RBAC smart contract for authorization. Access to critical functions is not hard-coded into every contract in an isolated manner. Instead, role verification is delegated to an external authorization module. This approach follows the principle of separation of concerns. It improves maintainability, reduces duplication of access logic, and makes the smart contract layer more resilient against unauthorized use. In practice, only authorized institutional actors can write transcripts or diploma records to the ledger, while administrative functions are restricted to privileged roles. This model is particularly appropriate for the educational Domain, where universities, ministries, and authorized personnel must operate under clearly defined institutional permissions.

The blockchain layer also introduces a specific indexing strategy based on Keccak-256 hashing. A combined key derived from identifiers such as university and student IDs is transformed into a deterministic bytes32 index, enabling efficient retrieval of transcript collections from the contract storage. This is methodologically important because educational records naturally accumulate over time. A student may have many transcript entries across terms and subjects, and the ledger must therefore support scalable retrieval without changing the contract structure. The chosen mapping-based design solves this by linking each student-university combination to a dynamic list of transcript records. Thus, the system gains both deterministic addressing and extensibility.

At the architectural level, the blockchain network is best understood as a permissioned or consortium-oriented Ethereum deployment, even when individual experiments are conducted in a test environment. This design choice is motivated by the educational context. In higher education, unrestricted public validation is less important than controlled institutional participation, predictable transaction costs, and privacy-aware governance. Therefore, the blockchain component was conceived not as a public anonymous network, but as a validator-based educational ledger in which authorized institutions or state bodies can maintain network trust. This makes the approach more realistic for national deployment in Kazakhstan.

The blockchain architecture is shown in Figure 3.

Figure 3. The blockchain architecture.

3.2.3. Smart Bridge Architecture

The Smart Bridge subsystem serves as a secure integration layer between the DHEP, existing educational information systems, and state digital infrastructure [24]. As the backend coordinates application logic and data processing, the blockchain ensures the integrity of academic record verification, and the frontend subsystem provides user interaction; the Smart Bridge subsystem is responsible for trusted intersystem data exchange. Its purpose is to support standardized, legally significant, and secure communication with external governmental and departmental information systems. The need for the Smart Bridge subsystem is determined by the nature of the data processed in the proposed platform. Academic transcripts, diplomas, and diploma supplements are linked not only to university databases but also to official state information systems. Therefore, the platform receives verified data from authoritative sources and exchanges information through secure channels. In this context, Smart Bridge functions as an integration mechanism that allows the platform to interact with government services while preserving the authenticity, integrity, and legal validity of the transmitted data.

On the designed Platform, Smart Bridge primarily supports student and graduate registration and identification. During registration or data verification, a user’s individual identification number is used to request official personal information from the relevant state information system. This reduces manual data entry, minimizes the risk of inconsistencies in student profiles, and improves the reliability of the data that later becomes part of the transcript or diploma processing [25]. Thus, Smart Bridge ensures data correctness before academic records are stored in the off-chain database or registered on the blockchain network [26]. The Smart Bridge subsystem is based on standardized message exchange. Requests are formatted in structured XML according to the required service template and transmitted via SOAP. Before transmission, the request is signed using an electronic digital signature. This signature confirms the sender’s identity and protects the message from unauthorized modification during transmission. As a result, the Smart Bridge subsystem provides a legally significant mechanism for exchanging sensitive data between the platform and external state services.

The Smart Bridge architecture is shown in Figure 4.

Figure 4. The Smart Bridge architecture.

3.2.4. Frontend Architecture

The frontend layer represents the platform’s user environment and translates the hybrid blockchain-based backend architecture into accessible educational services. Methodologically, the frontend is not merely a visualization module; it is an integral part of the system, operationalizing verification, document access, and institutional interaction for different stakeholder groups. The web interface is intended for higher education institutions, students, graduates, employers, and administrative users, each of whom interacts with the platform.

For students and graduates, the frontend provides authenticated access to digital educational documents, including transcripts, diplomas, and other academic records. This removes the dependence on purely paper-based credentials and reduces the need to request repeated copies from the issuing university [27]. For universities, the interface supports viewing and managing academic catalogs, student and graduate information, and document-generation workflows. For employers and other external verifiers, the frontend offers public or restricted verification services through document identifiers, student-related data, or blockchain-based validation references. This multi-role design is a major advantage because it transforms the platform from a backend registry into a full educational service environment.

Another methodological strength of the frontend is that it enables document verification through combined off-chain and on-chain evidence. A user does not need to understand Solidity, event logs, or raw transaction data. Instead, the interface retrieves the necessary metadata from the backend and blockchain and combines them in a human-readable form. This approach greatly improves usability while preserving the transparency of blockchain-based verification [28]. It is therefore an important part of the system’s novelty: blockchain trust is embedded in an interface that remains understandable to non-technical educational stakeholders.

The frontend architecture is shown in Figure 5.

Figure 5. The frontend architecture.

3.3. Trust and Threat Model

The proposed system is designed for a permissioned higher education environment. Therefore, its security properties depend not only on the technical mechanisms of blockchain, but also on institutional trust assumptions, access-control rules, validator governance, and the correctness of data supplied by authorized educational organizations. The main actors in the system are students and graduates, university administrators and registrar’s office employees, organization-level administrators, system-level administrators, API users, Smart Bridge information systems, blockchain validator nodes, external verifiers, and external attackers. Students, graduates, and employers are treated as untrusted or partially trusted actors as they may attempt to submit forged documents, present modified credentials, or verify records without authorization. They do not have permission to write transcript or diploma data to the blockchain [29]. University administrators and API users are authorized to submit academic records, but they are not treated as fully trusted from a security perspective. They may make data-entry errors, misuse privileges, or be compromised. For this reason, their operations must be authenticated, authorized, logged, and linked to specific institutional roles [30]. Smart Bridge and state information systems are trusted only for official identity-related data, such as individual identification, name, date of birth, citizenship, and other personal information obtained from authoritative state sources. Smart Bridge improves the reliability of student and graduate identification and reduces manual data-entry errors. However, Smart Bridge does not verify the academic correctness of grades, ECTS credits, transcript entries, diploma numbers, qualification values, or educational-program information [31]. These academic data remain the responsibility of the issuing university and its internal academic governance procedures. The blockchain validator nodes are assumed to be operated by authorized participants in a consortium-oriented deployment. These participants may include approved higher education institutions, the national platform operator, or state educational bodies.

The proposed system considers the following threats: unauthorized modification of academic records after registration; forged or altered credentials presented by students or graduates; unauthorized attempts to register transcript or diploma records; inconsistency between off-chain records and blockchain transaction hashes; deletion or modification of verification references in the centralized database; misuse of transaction identifiers; compromise of a university user account; and lack of auditability in document verification [32]. These threats are addressed through role-based backend authorization, smart-contract access control, transaction hashes, blockchain event logs, off-chain/on-chain linkage, authenticated API access, catalog validation, and blockchain explorer-based monitoring. At the same time, several threats are outside the cryptographic guarantees of the current system. The platform does not automatically prove that an authorized university initially entered a correct grade, ECTS value, diploma number, or educational-program attribute [33]. Blockchain immutability ensures that a registered value cannot be changed without a trace, but it does not guarantee that the value was academically correct at the time of submission. Similarly, Smart Bridge can improve the correctness of personal identification data, but it cannot validate academic performance data [34]. Therefore, the correctness of grades, credits, and diploma information must be ensured through institutional procedures, registrar approval workflows, LMS integration, internal audits, and legal responsibility of the issuing institution. Thus, the proposed platform protects primarily against post-registration and unauthorized modifications, unverifiable document claims, and weak auditability. Its strongest security property is that once an authorized academic record has been registered, the system can provide evidence of who registered it, when it was registered, which transaction recorded it, and whether the off-chain record still corresponds to the on-chain proof.

4. The Practical Realization of the Blockchain-Based Educational Platform

As the main parts of the system, including the backend, blockchain, and frontend, were described in Section 2, their practical implementation is presented in this section.

4.1. Implementation of the Backend on the Platform

The backend subsystem was implemented as the central application layer of the Decentralized Higher Education Platform (DHEP), responsible for coordinating interactions among the frontend interface, the off-chain database, and the blockchain network. The frontend part is implemented as a web application, while the backend is exposed via the DHEP API and provides the platform’s main business logic. In the implemented architecture, the API stores and processes information from the off-chain database, validates incoming requests, manages users and permissions, and communicates with the blockchain network API to read or write data to the on-chain layer. Thus, the backend serves as the primary integration component that connects the traditional university information system environment to blockchain-based verification mechanisms [35].

The backend application was developed as a C# web application and exposed as a Web API that provides the main business logic of the DHEP application. It processes frontend requests, manages interaction with the PostgreSQL off-chain database, validates academic data, controls user roles and permissions, and communicates with the blockchain network API when academic records need to be registered on-chain. The backend was developed according to the principles of separating the system into independent layers and reducing the business logic’s dependence on infrastructure details. The structure of the DHEP application and its components is shown in Figure 6.

Figure 6. The layers of the DHEP application.

The Domain layer contains the core business entities, value objects, domain rules, events, and exceptions. It represents the stable part of the system and defines the main logic related to users, organizations, transcripts, diplomas, permissions, and blockchain requests.

This layer contains business rules and entities:

−

The entities, value objects, aggregates, domain events, and domain services.

−

Business Rules and Invariants of all critical logic that must remain stable when changing frameworks or databases.

−

Independence of both Application and Infrastructure. It contains interfaces implemented by external layers.

−

Resilience to infrastructure changes and serves as a single source of truth for business logic.

The Application layer coordinates use cases, validation, data transfer objects, repository interfaces, and application services. It does not depend directly on infrastructure implementation, making the system easier to test and extend. This layer manages scenarios and orchestration:

−

Use Case Orchestration implementation of application services and coordination of domain entity and adapter work.

−

Input and Output Contract of commands and requests, validation, and transaction logic.

−

Dependencies on the Domain via interfaces.

−

Scenarios that apply implementation details simplify testing and infrastructure replacement.

The Infrastructure layer implements interactions with external components, including PostgreSQL, repositories, and external APIs. Infrastructure implements external components (such as databases, networks, and file systems):

−

Implementation of external details: specific repository implementations, authentication providers, integration with databases, queues, file storage, and external APIs.

−

Data conversion between an infrastructure-friendly format and application models with the use of Adapters and Bridges.

−

Dependencies on Application and Domain via contracts. It contains specific libraries and frameworks.

−

EFCoreDbContext and repositories, HTTP clients, implementation of logging interfaces, migrations, and DI configuration.

The Web API layer serves as the entry point for client requests and links the frontend to both off-chain and on-chain data processing. In addition, a separate EpvoDataPull application was developed to support integration with the existing UPHE structure and to migrate historical transcript and diploma data into the DHEP database for subsequent blockchain registration [36].

A key feature of the backend implementation is the combination of centralized off-chain storage and on-chain registration via the blockchain. Since blockchain resources are limited, only the most sensitive and verification-critical data related to academic grades and diplomas are stored on the blockchain. The remaining operational data are stored in the off-chain PostgreSQL database. This design allows the system to preserve the efficiency and flexibility of a conventional database while using blockchain only for records that require immutability and independent verification. The off-chain database also contains central reference catalogs used to standardize data received from higher education organizations. Before an institution can submit student, transcript, or diploma information, its local data must be mapped to the central catalogs, such as country, nationality, language of study, educational program type, document type, degree level, university type, control form, payment form, and other institutional classifications. This validation mechanism improves data consistency and reduces errors during integration with the blockchain layer. An important Transcript table in PostgreSQL is shown in Figure 7.

Figure 7. The Transcript table in the Backend database.

The Transcripts table is one of the key off-chain database tables used in the backend subsystem for storing academic transcript records. It contains the main information related to a student’s academic performance, including identifiers for the transcript entry, student, university, academic subject, grades, transcript type, and ECTS credits, as well as service fields such as creation and modification dates. The table also includes several Boolean attributes that describe the academic status of the record, such as whether the course was accepted, passed, retaken, deleted, included in scholarship calculation, or related to additional coursework. The Transcripts table stores the operational academic data required by the backend application and supports the management of transcript information within the off-chain PostgreSQL database. A particularly important field in this table is the Hash field. This field connects the backend subsystem with the blockchain layer. When a transcript record is submitted for blockchain registration, the backend sends the verified transcript data to the blockchain network via the corresponding API or Smart Bridge. After the blockchain successfully processes the transaction, the system receives a transaction hash. This Hash is then stored in the Hash column of the corresponding record in the Transcripts table. As a result, each off-chain transcript entry can be linked to its on-chain blockchain transaction.

The backend implements a flexible role-based and permission-based access control model. The system currently includes four main roles: USER, ADMIN, SUPER_ADMIN, and API_USER:

−

A basic user receives the USER role upon registration or system creation.

−

Organization-level administrators who manage users and permissions within their own institution obtain the ADMIN role.

−

Extended system-wide privileges for adding new organizations, managing users across all organizations, and assigning administrator rights are given to the SUPER_ADMIN role.

−

Integration scenarios, especially for organizations that do not have their own blockchain node but require submitting data to a centralized off-chain database for later transfer to the blockchain network, are assigned the API_USER role.

In addition to roles, the system uses permissions that allow the super administrator to dynamically control access to API methods and frontend modules. As a result, the available interface tabs and backend functions are determined by the permissions assigned to the authenticated user. Security in the backend is supported through token-based authentication and password protection mechanisms [37]. Data exchange between the frontend and the backend API is handled using JWT tokens, which provide secure user authentication and authorization. The JWT token is signed using the HMAC-SHA256 algorithm, which reduces the risk of token forgery. In the current system configuration, user passwords are hashed using a one-way SHA-512 hash. However, this should not be described as encryption, since hashing and encryption are different mechanisms. Encryption is reversible with a key, whereas password hashing is one-way. Moreover, plain SHA-512 is a fast general-purpose hash function and is not sufficient for production-grade password storage. Therefore, this mechanism is identified as a prototype limitation. In the production version, SHA-512 will be replaced by a dedicated, salted, and computationally intensive password-hashing function, such as Argon2id, bcrypt, scrypt, or PBKDF2. The preferred production configuration is Argon2id with a unique 128-bit random salt per password, 32-byte hash length, 64 MiB memory cost, 3 iterations, and parallelism of 2.

The backend includes several controllers responsible for different parts of the business logic. The UserController manages user registration, authentication, user lists, and user information updates. The CatalogController provides access to central reference catalogs and validates submitted data against these catalogs. Other organization-related controllers provide CRUD operations for higher education institutions and their data. This modular controller structure makes the backend suitable for integration with different institutional systems and supports controlled access to the DHEP ecosystem [38].

The most important component for blockchain integration is the OnChainRequestController, which sends verified academic data to the blockchain network. The Create method receives a transcript model, validates the submitted data, sends a request to the blockchain network API, and receives a TransactionId. The submitted data are then stored in the OnChainRequests table. Since block formation and transaction confirmation in the blockchain network may take time, the backend includes a scheduled job that runs every two hours and checks the transaction status using the previously received TransactionId. When the transaction is confirmed successfully, the blockchain network returns the transaction hash. The backend then updates the Hash field in the OnChainRequests table and also finds the corresponding record in the Transcripts table using UniversityId, StudentId, and TranscriptId, updating its hash field as well. This Hash later serves as a verification reference that can be used to retrieve the transaction history and confirm the authenticity of the corresponding academic record [38]. The functional structure of the OnChainRequests controller is shown in Figure 8.

Figure 8. The functionality of the OnChainRequests controller.

4.2. Implementation of the Blockchain on the Platform

The blockchain part of the system was implemented as the trust, integrity, and verification layer of the DHEP. While the backend part administers the PostgreSQL off-chain database, validates incoming academic data, manages users and permissions, and coordinates interaction with the frontend, the blockchain subsystem is responsible for registering verification-critical academic records in an immutable, independently verifiable form. The full operational context of academic records is stored in the backend database, whereas selected transcript and diploma-related data are registered in the blockchain network when they require cryptographic confirmation, long-term integrity, traceability, and external verification.

In the implemented DHEP architecture, the backend first receives transcript or diploma data through the Web API, validates the submitted fields, and prepares the request for blockchain registration. After that, the backend sends the verified data to the blockchain network API. The blockchain network processes the request, creates the corresponding transaction, and returns a transaction identifier. Since block creation and transaction confirmation require time, the backend periodically checks the transaction status. After successful confirmation, the blockchain network returns the final transaction hash, which is stored in the backend database and linked to the corresponding academic record. Therefore, the transaction hash serves as the technical link between the off-chain academic record and its on-chain blockchain proof.

The blockchain implementation is based on an Ethereum Virtual Machine-compatible environment and smart contracts written in Solidity. An EVM-compatible blockchain enables transaction execution, event logging, and transparent verification via standard blockchain mechanisms. In this system, smart contracts are not used to store complete academic documents. Instead, they register the most important verification parameters required to prove the authenticity and integrity of academic records. This approach reduces unnecessary storage costs on the blockchain and allows the backend PostgreSQL database to remain responsible for storing full operational data.

To validate the proposed solution experimentally, a private blockchain test environment was deployed. Conceptually, the proposed architecture is intended for a permissioned consortium network operated by authorized educational and governmental participants. However, within the scope of this study, the environment used was a local testbed comprising three validator nodes. This testbed serves as a controlled prototype of the proposed consortium network and was used to evaluate the practical feasibility of smart contract execution, transaction registration, event logging, transaction hash synchronization, and gas consumption analysis. The experimental blockchain platform was implemented as a private Ethereum network using Go-Ethereum (Geth) v1.13.15. The network used the Proof of Authority consensus mechanism based on the Clique algorithm. This consensus mechanism was selected because it is suitable for permissioned and consortium-oriented blockchain networks in which validator nodes are known and authorized in advance. Compared with Proof of Work, Clique-based PoA offers lower computational overhead, faster block generation, and more predictable transaction processing, all of which are important for educational document verification scenarios. The testbed consisted of three validator nodes. All validator nodes were deployed using Docker containerization within a single bridge virtual network. The Docker bridge network used the 172.21.0.0/16 subnet, isolating blockchain-node communication and enabling controlled monitoring of the experimental environment. All nodes were deployed on one physical server or virtual machine. Therefore, the experiment should be interpreted as a functional prototype and reproducibility testbed rather than as a geographically distributed production consortium deployment. The main blockchain network parameters were configured as follows: the Chain ID was set to 1234; the block interval was set to 15 s using the period parameter in the Clique configuration; the block gas limit was set to 8,000,000 gas. The blockchain data storage subsystem used the Pebble database, snap synchronization mode, and archive mode for preserving the full transaction history. These settings enabled the experiment to record, inspect, and reproduce transaction execution details, including transaction hashes, block numbers, sender and receiver addresses, gas consumption, raw input data, and smart contract event logs.

The hardware configuration used for the experiment included a computer with a Core i7 processor (8 cores/16 threads), 32 GB of RAM (DDR4), a 1 TB NVMe SSD, and Ubuntu 22.04 LTS. All blockchain nodes, backend services, and monitoring tools were deployed within this controlled environment. Using a single-machine Docker topology enabled reproducing the experiment and precisely monitoring blockchain behavior; however, it does not fully reflect the network latency, governance complexity, and fault-tolerance characteristics of a real multi-institutional consortium deployment. Thus, the implemented environment should be understood as a local experimental prototype of the proposed permissioned consortium architecture. The results from this testbed demonstrate the functional feasibility of the proposed approach, including smart contract execution, event-based auditability, transaction hash generation, and gas consumption measurement.

A central component of the blockchain subsystem is the smart contract logic that records transcript data. The contract receives the academic parameters from the backend and executes the registration function only if the caller is authorized. Critical operations are protected through role-based access control. This mechanism ensures that only verified and authorized entities, such as accredited educational organizations or approved platform actors, can register academic records on-chain. This is important because unrestricted access to the smart contract could allow unauthorized or false academic data to be written into the blockchain. Therefore, the blockchain layer complements the backend permission system and provides an additional level of protection directly at the smart contract level.

The blockchain mechanism was implemented using BlockScout v11.0.3 as the primary blockchain explorer and transaction monitoring tool. It provides detailed information about blocks, transactions, addresses, logs, raw input data, state changes, gas usage, and transaction fees. In the DHEP implementation, BlockScout was used to confirm that blockchain transactions were successfully executed and included in blocks. It also allowed the analysis of transaction hashes, sender and recipient addresses, execution status, block confirmations, timestamps, gas usage, and smart contract logs. This enabled validation not only of the existence of blockchain transactions but also of the correctness of smart contract interactions.

The detailed transaction view in BlockScout is especially important for the practical verification of academic records. Each transaction includes a unique hash, the sender’s address, the smart contract’s address, the block number, the timestamp, the execution status, the gas consumed, and the raw input data. The raw input and logs were also analyzed to verify the encoded values submitted to the smart contract. Therefore, BlockScout supports transparency, auditability, and reproducibility of the blockchain registration process. The BlockScout window with transactions is shown in Figure 9.

Figure 9. The BlockScout with transactions.

The smart contract uses a structured representation of transcript data and stores records in a way that supports deterministic retrieval and traceability. A hashed indexing mechanism is used to generate a unique key for grouping and retrieving records associated with a specific university and student. This approach improves the contract’s scalability because the number of transcript records can grow without requiring changes to the contract’s structure. It also allows academic records to be accessed through a consistent indexing mechanism while preserving the integrity of the stored data.

The transaction hash stored in PostgreSQL is not interpreted as an independent guarantee that the off-chain database record has remained unchanged. In the proposed architecture, PostgreSQL serves as an off-chain index, enabling efficient search, filtering, aggregation, and frontend interaction. Since direct search and aggregation of complex educational data in the blockchain layer are inefficient, selected blockchain transaction metadata are duplicated in the relational database. However, the cryptographic reference for verification remains the corresponding blockchain transaction.

The system uses a cryptographic anchoring mechanism to detect modification of off-chain records. During verification, the verifier retrieves the transaction hash associated with the PostgreSQL record and queries the blockchain node using an RPC method. The corresponding transaction receipt is also obtained to confirm execution status and event logs. From the on-chain transaction, the verifier extracts immutable fields, including the transaction input payload, sender address, recipient smart contract address, receipt status, and emitted event data. These values are then compared with the corresponding fields stored in PostgreSQL.

For example, the data field stored in PostgreSQL must match the input field or decoded event of the blockchain transaction. The transaction sender corresponds to an authorized institutional account, and the recipient address corresponds to the expected smart contract, as indicated by the transaction receipt. If a database administrator or attacker modifies the payload, status, or academic data in PostgreSQL, the modified off-chain record will no longer match the immutable on-chain transaction referenced by the transaction hash. Such a mismatch indicates tampering or inconsistency of the off-chain record.

Thus, the transaction hash is used as a cryptographic pointer to an immutable on-chain reference. It does not protect PostgreSQL from modification on its own, but it enables independent detection of unauthorized changes by comparing the current off-chain record with the original on-chain transaction data. The blockchain layer therefore gives tamper-evidence for registered records, while PostgreSQL provides efficient indexing and operational data management.

Event logging is another important element of the blockchain implementation. When a transcript is successfully registered, the smart contract emits a corresponding event, such as TranscriptSave. This Event records the key attributes of the transaction and forms an immutable audit trail. Events are particularly useful because they can be read by external applications, blockchain explorers, and verification services without requiring direct modification of the contract state. This makes event-based verification a cost-effective mechanism for confirming that a record was created, identifying who initiated the transaction, and checking which academic data were included in the registration operation. The transaction hash is one of the most important elements of the implemented system. In the backend database, the Hash field in the transcript-related tables stores the transaction hash received after successful confirmation on the blockchain. This field connects the conventional off-chain record with its blockchain transaction. The Event logging with the Hash is shown in Figure 10.

Figure 10. The Event logging in BlockScout.

An important part of the blockchain implementation is related to the gas consumption analysis. Gas consumption is a critical metric in EVM-compatible systems because it reflects the computational and storage cost of executing smart contract operations. Every transaction that changes the blockchain state requires gas, and operations that write data to contract storage are usually more expensive than read-only operations or event-based logging.

The proposed system achieved an average gas consumption of approximately 226,125 gas per transaction. The minimum observed gas consumption was 21,000 gas, which corresponds to the simplest transaction type in an EVM-compatible environment, while the maximum observed gas consumption was 823,457 gas, reflecting more complex smart contract operations. The recorded blockchain contained 1937 blocks and 4272 transactions. The system processed an average of 65.72 transactions per block, with a maximum of 90. These values indicate that the blockchain subsystem was able to process both light and more complex operations and maintain predictable transaction behavior. The transactions with gas consumption details are shown in Figure 11.

Figure 11. The gas consumption details in BlockScout.

Overall, the blockchain implementation demonstrates that the DHEP platform can integrate smart contracts, transaction hashes, event logs, and blockchain monitoring into a practical educational information system. The backend remains responsible for data management, validation, user roles, and off-chain storage, while the blockchain layer provides immutability, integrity, traceability, and independent verification. The transaction hash stored in the backend database creates a direct link between the off-chain record and its blockchain proof. The gas consumption analysis shows that the system maintains a practical balance between operational costs and functional richness. Therefore, the blockchain subsystem serves as a verification infrastructure that strengthens the reliability of digital academic records and extends the capabilities of existing educational platforms without disrupting their normal institutional workflows.

4.3. Implementation of the Smart Bridge on the Platform

The Smart Bridge subsystem was implemented as a secure integration component of the DHEP, which enabled controlled interaction with state information systems and electronic government services. In the platform architecture, this subsystem connects the backend service with external authoritative data sources and provides a legally significant mechanism for obtaining and verifying personal data of students, cadets, and graduates. Unlike the blockchain subsystem, which is responsible for the immutable registration and verification of academic records, the Smart Bridge subsystem is used during data acquisition and identity verification. Its main purpose is to increase the reliability of input data before they are stored in the off-chain database or later registered in the blockchain network.

The practical implementation of the Smart Bridge subsystem is based on integration with services provided through the Smart Bridge platform. This platform enables standardized data exchange between information systems of government agencies, educational organizations, and other authorized entities. On the DHEP platform, Smart Bridge supports interaction with the Personal Data Access Control module and the State Database of Individuals. This is especially important for the educational platform because student and graduate records must be linked to correctly identified persons. Therefore, the subsystem enables the platform to verify personal information using an individual identification number, thereby reducing the risk of manual data entry errors.

The Smart Bridge integration was achieved with the use of Swagger to document and test the available service methods. In this implementation, Swagger served as an interface for verifying interactions between software modules and for presenting available integration endpoints in a structured form. The Smart Bridge-related services include PDC access and the State Database of individuals (SDI). The PDC service is used first to request and verify access to personal data. As a result of this request, the platform receives an access token or status information confirming whether the personal data can be requested. After successful access confirmation, the received token is used in the PDC service request to obtain official information about the physical person from the SDI. Thus, Swagger supported the practical testing of the full integration chain: request formation, access control, token-based continuation of the process, and retrieval of verified personal data. The Swagger services are shown in Figure 12.

Figure 12. The Swagger services.

The provided PDC and SDI services facilitate the authentication of requested data. The first PDC request grants access, and a token is returned. The previously received token is then inserted into the SDI service. Once documentation is generated, the relevant data for the individual will be provided. The personal data access control module supports the following parameters:

−

MessageId is a Unique request identifier (GUID)

−

SessionId is the current session identifier.

−

MessageDate is the date and time the request was sent in ISO 8601-1:2019 [39] format.

−

Uin is the IIN of the personal data subject.

The parameters of the access control module are shown in Figure 13.

Figure 13. The parameters of the Access control module.

The SDI module is designed for integration with the government service that provides information about students and cadets of the Republic of Kazakhstan using their Individual Identification Number (IIN). This module is a SOAP service for obtaining official data about individuals:

−

Full name, date of birth, gender;

−

Citizenship and nationality;

−

Place of birth;

−

Registration and actual residential address;

−

Documents (ID card, passport, birth certificate, etc.).

Before sending an XML document to SmartBridge, it is signed with the digital signature of a legal entity or an organization’s employee to ensure its authenticity and compliance with legal requirements. The signing process is shown in Figure 14.

Figure 14. Signing with an electronic digital signature.

4.4. Implementation of the Frontend on the Platform

The platform web interface is realized on the DVPOWeb (https://dvpo.iict.kz/welcome (accessed on 20 July 2026)). The main part of the platform includes the Main page, Users, Catalogs, University Data, Templates, Curriculum Data, and Organizations of Higher and Postgraduate Education (OHPE). This structure reflects the platform’s role as an integrated educational management and verification system. The upper panel contains authenticated user information.

The frontend subsystem is an essential part of the proposed platform because it transforms the technical backend, Smart Bridge, database, and blockchain operations into user-oriented educational services. While the backend performs data validation, business-logic execution, database access, and blockchain transaction coordination, the frontend provides the user interface through which stakeholders access these functions. Therefore, the frontend is not considered only as a visualization layer. It is the operational interface that enables students, graduates, universities, employers, external verifiers, and administrators to interact with the platform without directly using PostgreSQL tables, SOAP/XML requests, smart contracts, transaction hashes, or blockchain explorer tools. The frontend implements role-specific workflows. Students and graduates can access their academic records, view transcript and diploma-related information, and use document access functions. Higher education institutions can manage student and graduate records, catalogs, templates, and document-generation workflows. Employers and external verifiers can use the credential verification interface to check the authenticity and status of academic documents through document identifiers, student-related attributes, or blockchain-based references. Ministry-level or system administrators can supervise platform data, manage institutional access, and control reference information. The frontend also plays an important role in simplifying blockchain-based verification. In the underlying architecture, verification may involve retrieving a transaction hash, checking the transaction status, reading event logs, comparing off-chain data with on-chain evidence, and confirming that the record was submitted by an authorized actor. These operations are technically complex for ordinary users. The frontend hides this complexity and presents verification results in a human-readable form.

The Main page provides a simple entry point to the platform after authentication. It confirms successful access to the system and provides a general starting workspace for the user. From this page, the authorized user can navigate to other functional modules using the sidebar menu. The frontend supports a familiar administrative dashboard, where the user works with required data modules through a unified interface.

The Users module provides tools for searching, viewing, and managing platform users. It contains different roles, including STUDENT, USER, ADMIN, and SUPER_ADMIN. This confirms that the frontend reflects the role-based access model implemented in the backend. Administrators can view user accounts and perform editing actions according to their permissions. Thus, the Users module provides a practical interface for managing platform access and controlling user participation in the system.

The Catalogs module is used to view and manage central reference data required for standardizing educational information. The interface allows the user to select the catalog type and status, perform a search, and view the results in a structured table. The example shows the DEGREE_TYPES catalog with multilingual values in Kazakh, Russian, and English, as well as status and creation date. This module is important because the platform receives data from different higher education institutions, and these institutions may use different local classifications. Central catalogs provide a unified data structure and support consistent processing of academic records, diploma information, educational programs, and student profiles. The frontend makes these catalogs accessible to authorized users and supports platform-level data validation. The catalog format is shown in Figure 15.

Figure 15. The catalog of the DVPOWeb.

The Templates module provides practical tools for configuring document templates. It includes separate subsections for diploma templates and transcript templates. In the diploma template section, users can select the document type, choose the background design, upload or view the organization logo, save the selected template, and download a sample diploma. In the transcript template section, a similar mechanism is provided for transcript documents. Users can select the transcript template type, choose a visual background, configure the logo, and save the selected template. This functionality is important because educational documents must follow institutional and regulatory formatting requirements. By providing template configuration through the frontend, the platform supports document-generation workflows without requiring backend technical changes. A template format is shown in Figure 16.

Figure 16. A template format of the DVPOWeb.

The OHPE contingent module provides access to information about graduates and students. The Graduates subsection includes a searchable list of graduates, including fields such as organization name, full name, individual identification number, date of birth, specialty or educational program group, academic degree, graduation order date, graduate identifier, and access to diploma- or transcript-related actions. The Students subsection provides a similar interface for active students, including full name, individual identification number, specialty, course, study form, organization, and transcript access. Search fields such as full name, individual identification number, and status allow users to filter records and quickly find the required person. These modules demonstrate how the frontend connects administrative users with the off-chain educational database and document-processing functions. The graduate search on the platform is shown in Figure 17.

Figure 17. The graduate search on the DVPOWeb.

The main user experience of the platform lies in reducing cognitive load. Users are not required to understand PostgreSQL table structures, SOAP/XML requests, electronic digital signature procedures, smart-contract functions, transaction hashes, event logs, or blockchain explorer data. The backend, Smart Bridge, and blockchain subsystems perform these operations. The frontend translates them into familiar interface elements, such as authentication forms, dashboards, search fields, structured tables, filters, document templates, download buttons, and verification status messages.

Another important principle is transparency without technical overload. When a credential is verified, the user should receive a clear result indicating whether the document is valid, inconsistent, revoked, under review, or not found. At the same time, the interface can provide additional verification evidence, such as transaction hash, registration date, issuer, and verification status, for users who require audit-level detail. This layered presentation allows ordinary users to quickly understand the results, while administrators or auditors can access more detailed technical evidence when necessary.

An important practical feature of the frontend is that it hides the technical complexity of the platform’s hybrid architecture. Users do not need to interact directly with PostgreSQL tables, Smart Bridge SOAP/XML requests, blockchain smart contracts, transaction hashes, or explorer logs. Instead, they work through standard web forms, tables, buttons, filters, and document actions. When a user searches for a student, manages a template, views a graduate record, or initiates document-related operations, the frontend sends the corresponding request to the backend. The backend then retrieves or stores off-chain data, and, when necessary, communicates with Smart Bridge or the blockchain network. This separation makes the platform usable for non-technical educational stakeholders.

Overall, the implemented frontend provides a unified web environment for managing users, catalogs, templates, university data, curriculum information, students, graduates, and document-related workflows. Its main contribution is that it connects different user groups with the Platform’s backend, Smart Bridge, off-chain database, and blockchain verification layer through a single dashboard. This makes the DHEP platform not only a technical registry for academic records but also a practical educational service environment that supports administration, document generation, data management, and trusted verification of academic information.

5. System Evaluation

The system evaluation was organized around functional tests, blockchain transaction measurements, end-to-end workflow tests, consistency checks, failure-recovery scenarios, security tests, and comparison with a centralized baseline. The experimental environment consisted of a private Ethereum network deployed using Go-Ethereum and Docker Compose.

5.1. Blockchain Evaluation

The blockchain network was configured as a permissioned Proof-of-Authority environment based on the Clique consensus mechanism. The test network included three nodes. The supporting deployment report describes the use of three blockchain nodes with local addresses 192.168.0.61, 192.168.0.62, and 192.168.0.63, as well as Docker-based deployment and node synchronization. The environment was supported by BlockScout for blockchain monitoring and Zabbix for server and container monitoring. Hardhat was used for smart-contract development, deployment, and testing. The evaluation covered three main layers of the platform: the smart-contract layer, the blockchain-network layer, and the application integration layer. The smart-contract layer was evaluated using Hardhat tests. The blockchain network layer was evaluated through transaction execution, block generation, gas consumption analysis, confirmation monitoring, and failure-recovery scenarios. The application integration layer was evaluated by checking the consistency between backend database records and blockchain transaction hashes.

Functional tests were implemented using Hardhat. The test suite included contracts related to role-based access control, transcript storage, and diploma registration. The RBAC tests checked whether an administrator can grant and revoke roles, transfer administrator privileges, and reject unauthorized attempts by non-admin users. These tests are important because the blockchain layer must prevent unauthorized users from registering transcript or diploma records. The functional test cases included the following categories:

−

Role assignment test: verifies that an administrator can grant a role to a user.

−

Role revocation test: verifies that an administrator can revoke an assigned role.

−

Administrator transfer test: verifies that administrator privileges can be transferred to a new address.

−

Unauthorized access test: verifies that a non-admin user cannot grant roles.

−

Transcript registration test: verifies that only an authorized issuer can save transcript records.

−

Diploma registration test: verifies that only an authorized issuer can create diploma records.

−

Duplicate diploma prevention test: verifies that a single student cannot receive duplicate diploma records from the same institution.

−

Input-validation test: verifies rejection of empty or invalid values such as zero addresses, empty identifiers, or missing required fields.

−

These tests validate the core functional requirements of the smart-contract layer: controlled access, correct role management, prevention of unauthorized writes, and basic input validation.

The blockchain implementation was evaluated through transaction execution and monitoring in the private Ethereum network. BlockScout was used to inspect transaction hashes, sender and recipient addresses, execution status, block numbers, timestamps, gas consumption, raw input data, and event logs. The current implementation recorded 1937 blocks and 4272 transactions. The average gas consumption was approximately 226,125 gas per transaction. The minimum observed gas consumption was 21,000 gas, corresponding to a simple transaction, while the maximum observed gas consumption was 823,457 gas for more complex smart-contract operations. The system processed an average of 65.72 transactions per block, with a maximum of 90 transactions per block. In the revised evaluation, confirmation time is measured as the time interval between the backend transaction submission and the moment when the transaction receipt becomes available, and the transaction hash is written back to the PostgreSQL record. End-to-end latency is measured as the total time from the frontend/API submission of an academic record to its final verification availability on the platform. The transaction execution metrics are shown in Table 2.

Table 2. Transaction execution metrics.

Metric	Description
Transaction submission time	Time required to send a transaction from the backend/API to the blockchain node
Confirmation time	Time until the transaction receipt is available and the transaction is included in a block
End-to-end latency	Time from academic-record submission to verification-ready status
Gas consumption	Gas used by transcript and diploma registration transactions
Transactions per block	Number of transactions included in generated blocks
Transaction success rate	Ratio of successful transactions to submitted transactions
Failed transaction rate	Ratio of reverted or rejected transactions to submitted transactions

Table 2. Transaction execution metrics.

Metric	Description
Transaction submission time	Time required to send a transaction from the backend/API to the blockchain node
Confirmation time	Time until the transaction receipt is available and the transaction is included in a block
End-to-end latency	Time from academic-record submission to verification-ready status
Gas consumption	Gas used by transcript and diploma registration transactions
Transactions per block	Number of transactions included in generated blocks
Transaction success rate	Ratio of successful transactions to submitted transactions
Failed transaction rate	Ratio of reverted or rejected transactions to submitted transactions

5.2. Concurrent Transaction Evaluation

Concurrent transaction submission was evaluated because multiple academic records may be submitted asynchronously by external systems or backend services. During initial stress testing, asynchronous submissions from the same sender account resulted in nonce conflicts, including ‘nonce too low’ and ‘replacement transaction underpriced’ errors. These errors reduced transaction throughput and could cause submitted academic-record operations to fail.

To address this issue, a middleware-level Nonce Manager was introduced. The Nonce Manager places asynchronous transaction requests into a synchronized in-memory queue and assigns nonce values atomically before sending the transactions to the Geth transaction pool. This prevents multiple transactions from being created with the same or incorrectly ordered nonce. After introducing this component, transaction submission became more stable under concurrent API calls. The evaluation compares system behavior before and after the Nonce Manager, shown in Table 3.

Table 3. System behavior evaluation.

Scenario	Observed Problem	Implemented Correction	Evaluation Criterion
Asynchronous transaction submission without nonce control	Nonce conflicts and rejected transactions	Middleware Nonce Manager	Reduced nonce-related failures
Concurrent requests from one sender account	Duplicate or out-of-order nonce values	Atomic nonce assignment	Correct transaction ordering
High-volume API submission	Transaction-pool instability	In-memory queue before TxPool submission	Higher submission stability

5.3. Database and Blockchain Consistency Testing

Since PostgreSQL stores off-chain records and blockchain transaction hashes, the evaluation includes database/blockchain consistency tests. These tests verify that each academic record submitted for blockchain registration has a corresponding transaction hash after confirmation and that the blockchain transaction data matches the backend record.

The consistency test procedure is as follows:

−

Submit a transcript or diploma record through the backend API.

−

Store the request in the PostgreSQL database with pending status.

−

Send the corresponding transaction to the blockchain network.

−

Retrieve the transaction receipt after confirmation.

−

Store the final transaction hash in the related PostgreSQL record.

−

Retrieve the transaction by hash using the blockchain node or BlockScout.

−

Decode the transaction input or event log.

−

Compare the decoded blockchain payload with the PostgreSQL record.

−

Mark the record as consistent if the values match.

−

Mark the record as inconsistent if the off-chain and on-chain values differ.

This test is important because a transaction hash alone does not prove that the PostgreSQL row has remained unchanged. The verification procedure must compare the current off-chain record with the immutable on-chain transaction data.

5.4. Security-Oriented Testing

Security-oriented tests focused on access control and rejection of unauthorized blockchain operations. The RBAC smart contract was tested to confirm that only administrators can assign or revoke roles and that only authorized issuers can submit transcript or diploma data. The tests also checked invalid input handling, including zero addresses and duplicate role assignments.

The code-review process also identified several improvements that were incorporated into the revised contracts: the use of compact bytes32 fields instead of strings where appropriate; validation of zero addresses; duplicate-role checks; an external RBAC interface; administrator-transfer support; additional audit events; and pagination for retrieving transcript records. These changes improve security, gas efficiency, maintainability, and scalability.

To address whether blockchain adds measurable value, the revised evaluation includes a comparison with a centralized PostgreSQL-only baseline. In the baseline approach, academic records and verification status are stored only in the relational database, and verification depends entirely on the database state and institutional access control. In the proposed approach, PostgreSQL remains responsible for operational storage and search, but each verification-critical record is linked to a blockchain transaction or commitment. The comparison is performed using the following criteria, shown in Table 4.

Table 4. Academic record and verification criterion.

Criterion	PostgreSQL-Only Baseline	Proposed Blockchain-Supported System
Record storage	Centralized database only	PostgreSQL plus blockchain anchor
Verification evidence	Database record and institutional trust	Database record plus transaction hash/event proof
Post-registration tamper detection	Requires database logs or administrator trust	Detected by comparing off-chain record with on-chain transaction data
Independent auditability	Limited	Supported through blockchain transaction history and event logs
Query efficiency	High	High for PostgreSQL queries; blockchain used only for verification
Transaction cost	No blockchain gas cost	Additional gas cost for on-chain registration
Operational complexity	Lower	Higher due to blockchain and synchronization
Best use case	Single-institution internal system	Multi-institutional verification and auditability

This comparison shows that the proposed system is not more efficient than a centralized database in every respect. The centralized baseline is simpler and faster for internal institutional storage. However, the blockchain-supported approach adds tamper-evident verification, independent auditability, and a cryptographic link between off-chain academic records and on-chain registration evidence.

The current evaluation was conducted in a controlled, local, private Ethereum environment and should be interpreted as a prototype validation rather than a full national-scale performance study. Although the tests demonstrate functional correctness, transaction registration, gas behavior, confirmation monitoring, consistency checking, and recovery from selected infrastructure failures, further evaluation is required in a geographically distributed consortium network with independent validator nodes operated by different institutions. Future experiments should include larger datasets, long-duration load tests, realistic multi-university workloads, concurrent-user testing at the frontend/API level, adversarial security testing, and comparison with W3C Verifiable Credentials or digitally signed credential baselines.

5.5. Smart-Contract Artifacts, Validation, and Security Assessment

The smart-contract layer was developed and tested using the Hardhat framework. The project structure includes the contracts/directory for Solidity source files, the test/ directory for automated tests, the scripts/ directory for deployment scripts, and the artifacts/ directory for compiled ABI and bytecode files. The main contracts evaluated in this study are RBAC, TranscriptStorage, and DiplomaRegistry. The compiler version, network configuration, gas parameters, and deployment scripts are fixed in hardhat.config.js. In the final submitted artifacts, the Solidity compiler version should be consistently specified in both the configuration file and the contract pragmas.

The test suite was implemented using Mocha/Chai. The RBAC tests verify role granting, role revocation, administrator transfer, and rejection of unauthorized role assignment. The transcript and diploma tests verify that only authorized issuers can create records, that required fields are validated, that duplicate diploma registrations are rejected, and that emitted events correspond to successful state changes. The test suite is executed using the command npx hardhat test. Test-coverage reports and static-analysis results are generated as project artifacts.

The source code, ABI files, deployment addresses, and test results are treated as reproducibility artifacts. The source files are stored in contracts/; tests are stored in test/; ABI and bytecode files are generated in artifacts/; deployment addresses are recorded after deployment for each network environment.

The smart-contract security assessment considered the following risks.

Authorization bypass. Critical state-changing operations are protected by role-based access control. The RBAC contract manages institutional roles, and functions such as saveTranscript and createDiploma are protected using role checks such as onlyRole(“issuer”) or onlyRole(“admin”). Unauthorized calls are rejected at the smart-contract level before state modification.

Duplicate registration. Duplicate registration is prevented through explicit state checks. In the diploma contract, the issuedDiplomas mapping is used to record whether a diploma has already been issued for a specific university-student pair. Before creating a new diploma, the contract checks that no previous diploma has been registered for the same pair. If a duplicate submission is attempted, the transaction is reverted.

Replay attacks. Replay of the same signed transaction is mitigated by the EVM transaction model because every transaction signed by an account includes a nonce. Once a transaction with a given nonce has been processed, the same transaction cannot be executed again on the same chain. The use of a fixed Chain ID also prevents reuse of transactions across incompatible networks.

Front-running. The front-running risk is limited because the contracts do not implement financial trading, auctions, exchange rates, or other price-sensitive logic. Reordering transactions does not provide a direct economic advantage. If two authorized issuers attempt to register the same diploma, the first successful transaction sets the corresponding state, and the second transaction is rejected by the duplicate-registration check.

Denial of service. The contracts avoid expensive unbounded loops in state-changing operations. Registration operations are implemented using mappings and direct storage updates, so their complexity is O(1). For transcript retrieval, pagination is used to avoid returning unbounded arrays. This reduces the risk that a large number of records will cause gas-limit exhaustion during contract interaction.

Integer and data-encoding errors. The contracts are compiled using Solidity 0.8.x, where arithmetic overflow and underflow checks are enabled by default. Invalid arithmetic operations revert automatically. Data encoding follows standard Solidity ABI encoding. Compact types, such as bytes32, are used for selected fixed-length values to reduce gas consumption and avoid unnecessary dynamic-string storage, where appropriate. Input validation is applied to reject zero addresses, empty identifiers, and empty required fields.

Upgrade risks. The current architecture does not use proxy-based upgrade mechanisms such as transparent proxies. Therefore, risks associated with storage-layout corruption or malicious proxy implementation upgrades are avoided. If business logic must be changed, a new contract version is deployed, and the backend routing or contract-address registry is updated through an authorized administrative procedure. This approach preserves the immutability of historical records while allowing controlled migration to newer contract versions.

The purpose of this assessment is not to claim that the contracts are formally verified or free from all vulnerabilities. Rather, it documents the validation steps performed in the prototype and identifies the security controls currently implemented. Before production deployment, the contracts should undergo independent external audit, static analysis, test-coverage publication, and, where appropriate, formal verification of critical authorization and record-registration properties.

5.6. Performance, Scalability, and Usability Metrics

To strengthen the experimental evaluation, the prototype was assessed using three groups of indicators: performance metrics, scalability-related indicators, and usability-related indicators. This organization makes it possible to distinguish between the technical behavior of the implemented prototype, its expected behavior under larger workloads, and the accessibility of the platform for non-technical educational stakeholders.

Performance evaluation focused on blockchain transaction execution and backend/blockchain synchronization. The measured indicators included the total number of blocks, total number of transactions, gas consumption, number of transactions per block, transaction confirmation time, transaction success rate, failed transaction rate, and end-to-end processing time from academic-record submission to verification-ready status. In the implemented private Ethereum testbed, the blockchain recorded 1937 blocks and 4272 transactions. The average gas consumption was approximately 226,125 gas per transaction. The minimum observed gas consumption was 21,000 gas, while the maximum observed gas consumption was 823,457 gas. The average number of transactions per block was 65.72, with a maximum of 90 transactions per block.

Scalability evaluation was treated as preliminary because the platform is still under deployment and has not yet been launched across all higher education institutions. Therefore, the current experimental results cannot be used as proof of national-scale readiness. Instead, they provide a prototype-level performance baseline and indicate which parameters must be tested under larger workloads. A national-scale workload model should include the expected number of participating institutions, students, transcript entries, diploma records, correction events, revocation events, and verification requests. The scalability analysis should distinguish between different blockchain registration strategies. A naive strategy that registers every course-level transcript entry as an individual transaction may generate a very high transaction volume. A more scalable strategy is to register student-semester commitments or institutional Merkle-root batches, where many academic records are aggregated into a single on-chain commitment. This would reduce transaction volume while preserving tamper-evident verification through off-chain records and cryptographic proofs.

Usability evaluation was considered from the perspective of the frontend design. The frontend was developed to reduce the cognitive burden of blockchain-based verification for students, graduates, university administrators, employers, external verifiers, and ministry-level administrators. Users interact with dashboards, structured tables, filters, search fields, document templates, and verification status messages rather than directly with PostgreSQL tables, SOAP/XML messages, smart-contract functions, transaction hashes, or blockchain explorer logs. The current study does not yet include a full empirical usability experiment with real users. Therefore, usability effectiveness is not claimed as a validated result. Before production deployment, a formal usability study should be conducted with representative user groups. The recommended usability metrics include task-completion time, task success rate, error rate, number of user actions required to complete a task, user satisfaction, perceived trust in verification results, System Usability Scale score, and User Experience Questionnaire results.

All three metrics are shown in detail in Table 5.

Table 5. Evaluation metrics for performance, scalability, and usability.

Evaluation Aspect	Performance	Scalability	Usability
Main evaluation focus	Measures how efficiently the prototype processes blockchain transactions and backend/blockchain synchronization	Measures whether the architecture can support larger workloads, more institutions, and long-term deployment	Measures whether different stakeholders can use the platform easily and understand verification results
Measured/analyzed indicators	Number of blocks, number of transactions, gas consumption, transactions per block, confirmation time, end-to-end latency, transaction success rate	Number of participating institutions, number of students and graduates, transcript-registration volume, diploma-registration volume, verification-request volume, validator-node distribution, storage growth	Role-based navigation, task-completion time, task success rate, error rate, number of clicks/actions, verification clarity, SUS score, UEQ score, perceived trust
Current prototype results	The private Ethereum testbed recorded 1937 blocks and 4272 transactions. Average gas consumption was approximately 226,125 gas; minimum gas was 21,000; maximum gas was 823,457. The average number of transactions per block was 65.72, with a maximum of 90 transactions per block.	The current experiment demonstrates prototype-level feasibility. Full national-scale scalability has not yet been validated because the system is still under deployment and was tested in a controlled private blockchain environment.	The frontend provides role-based access, dashboards, search fields, filters, catalog management, template configuration, and document-related actions, but a formal usability study with real users has not yet been conducted.
Statistical analysis to report	Mean, median, minimum, maximum, standard deviation, and 95th percentile for gas consumption, confirmation time, and end-to-end latency	Workload estimates, transaction-volume projections, storage-growth estimates, throughput under increasing numbers of institutions and records	Mean task-completion time, task success rate, average error rate, SUS score, UEQ score, and perceived-trust score
Recommended evaluation method	Export transaction logs from Geth/BlockScout and calculate descriptive statistics for transaction execution and confirmation	Perform stress testing with increasing transaction loads and compare course-level anchoring, student-semester anchoring, and Merkle-root batch anchoring	Conduct usability testing with students, graduates, university administrators, employers, and external verifiers
Interpretation	Shows the technical efficiency of the implemented blockchain prototype	Shows whether the architecture can be extended to multi-institutional or national-scale use	Shows whether blockchain-based verification is understandable and practical for non-technical users
Limitation	Current performance values are based on prototype-scale testing	National-scale scalability requires larger datasets, distributed validators, and realistic institutional workloads	UX effectiveness is not yet empirically validated and should be tested in future work

6. Discussion

6.1. The Contribution of the Proposed Platform

The proposed blockchain-based educational platform is not only a smart contract implementation, but a complete digital system for the secure management, registration, and verification of academic documents. Unlike solutions that focus only on issuing or verifying a final digital certificate, the proposed platform combines several functional layers: a frontend web portal, a C# ASP.NET backend service, an off-chain PostgreSQL database, a Smart Bridge integration subsystem, and an Ethereum-compatible blockchain layer. This system-level integration is important because academic document verification in real higher education environments cannot be solved by blockchain alone.

The main methodological advantage of the proposed platform is its hybrid approach to separating responsibilities. The backend and off-chain database preserve the flexibility and performance of conventional educational information systems, while the blockchain layer provides immutability and independent verification for selected trust-sensitive records. This design prevents unnecessary storage of full academic documents on-chain and reduces the cost of blockchain transactions. At the same time, it ensures that essential transcript and diploma-related data can be linked to a blockchain transaction hash, which serves as verifiable evidence of registration. Therefore, the proposed platform achieves a practical balance between centralized educational data management and decentralized trust.

Another important contribution is the integration of the Smart Bridge subsystem. This layer strengthens the reliability of source data before academic records are stored or registered on-chain. Since transcripts and diplomas are linked to real individuals, the correctness of student and graduate identification is critical. Smart Bridge enables standardized interaction with state information systems through SOAP/XML messages and electronic digital signatures. As a result, the platform does not rely solely on manually entered data from university systems but can also use verified data from authoritative sources. This increases the legal significance, consistency, and reliability of the data used in subsequent document generation and blockchain registration workflows.

The frontend also plays a significant role in the system’s practical contribution. Blockchain-based verification is often technically complex for ordinary users because it involves transaction hashes, smart contract events, blockchain explorers, and encoded transaction data. The proposed frontend hides this complexity and presents the platform’s functions through a familiar dashboard interface. Users can manage catalogs, users, templates, students, graduates, and document-related operations without directly interacting with smart contracts or raw blockchain data. Thus, the platform transforms blockchain-based trust mechanisms into practical educational services that can be used by administrators, universities, graduates, students, and verifiers.

Overall, the proposed platform contributes to the digital transformation of higher education in Kazakhstan by extending the existing centralized ecosystem rather than replacing it. This is particularly important for countries where higher education is already managed through national or institutional platforms. The proposed architecture shows that blockchain can be introduced as an additional trust layer while preserving compatibility with existing databases, web services, university workflows, and state digital infrastructure.

6.2. Comparison with Advanced Blockchain-Based Educational Systems Worldwide

To evaluate the proposed system effectively, it is compared with advanced blockchain-based educational systems and frameworks developed in other countries. This comparison focuses on the relevant systems: EduCTX, OpenCerts, ElearnChain, and EduRSS.

EduCTX is one of the earlier blockchain-based higher education credit platforms. Its main contribution lies in the idea of representing academic credits through a blockchain-based token model. It is conceptually important because it moves beyond diploma verification and attempts to create a decentralized credit and grading ecosystem for higher education institutions. However, EduCTX is primarily focused on academic credit representation and does not offer the same level of integration with national educational databases.

OpenCerts is a more practically deployed system and represents one of the strongest examples of blockchain-based certificate and transcript verification. It was developed in Singapore and supports the issuance and validation of tamper-resistant academic certificates and transcripts. Its main strength is simplicity and real-world adoption. However, OpenCerts is primarily focused on document verification rather than being a full educational management platform.

ElearnChain is a privacy-preserving consortium blockchain system for educational records in e-learning. Its key contribution lies in combining consortium blockchain principles with privacy protection and traceability for learning records. It is relevant because it recognizes that educational data should not be treated as fully public blockchain content. However, ElearnChain is mainly focused on e-learning records and privacy-preserving record storage, while the proposed DHEP platform covers a broader administrative and institutional scope, including transcripts, diplomas, templates, user roles, state-system integration, off-chain catalogs, and blockchain-based verification.

EduRSS also represents a relevant hybrid architecture because it combines blockchain, smart contracts, and off-chain encrypted storage for secure educational record sharing. Its design is similar to the proposed platform in that it does not store all data directly on-chain. However, EduRSS is primarily a secure storage and sharing framework, whereas the proposed system additionally includes a full frontend environment, backend business services, Smart Bridge integration, document-generation templates, and practical administrative modules. Therefore, the proposed system is closer to an operational educational platform than to a specialized record-sharing scheme.

The detailed comparative analysis of the proposed system with selected advanced blockchain-based educational systems and frameworks is shown in Table 6.

Table 6. The comparative analysis of blockchain-based educational systems.

System/Framework	Main Technological Approach	Functional Scope	Main Advantages	Main Limitations
The proposed DHEP platform	Hybrid architecture combining frontend, C# ASP.NET backend, PostgreSQL off-chain database, Smart Bridge integration, and Ethereum-compatible smart contracts	Full educational document environment for transcripts, diplomas, catalogs, templates, students, graduates, users, and blockchain verification	Combines operational educational data management with blockchain integrity; supports Smart Bridge-based official data verification; links off-chain records with transaction hashes; provides practical frontend modules; adapted to Kazakhstan’s higher education infrastructure	Requires integration with multiple external systems; real national-scale deployment will require governance, validator coordination, privacy enhancement, and further interoperability standardization
EduCTX	Blockchain-based higher education credit platform using a tokenized representation of academic credits	Academic credit and grading representation for higher education institutions	Introduces a decentralized model for academic credits; supports the idea of a global academic credit environment; reduces dependence on isolated institutional credit records	Focuses mainly on credit representation; does not provide full backend administration, document templates, Smart Bridge-style state integration, or direct diploma/transcript management
OpenCerts	Blockchain-based certificate and transcript verification platform using tamper-resistant digital credentials	Issuance and verification of academic certificates and transcripts	Strong real-world deployment; simple verification process; suitable for students, employers, and institutions; supports tamper-resistant credentials	Mainly oriented toward credential verification; it does not function as a complete educational platform with off-chain catalogs, institutional workflows, Smart Bridge integration, and backend-controlled document processing
ElearnChain	Privacy-preserving consortium blockchain for e-learning educational records	Tamper-proof, traceable, and privacy-aware e-learning record management	Recognizes privacy limitations of public blockchain storage; uses a consortium model; supports traceability of educational records	Focuses mainly on e-learning records; does not include full diploma/transcript workflows, frontend dashboard functions, national catalog integration, or document-generation services
EduRSS	Blockchain-based educational record secure storage and sharing scheme with off-chain storage and smart contracts	Secure storage and sharing of educational records	Uses hybrid storage; supports secure record exchange; reduces direct on-chain storage burden; introduces smart contract-based record management	More focused on record storage and sharing than on a complete platform; lacks practical Smart Bridge integration, document template management, and a full frontend administrative environment.

The use of blockchain for educational document verification should be carefully justified, as several simpler mechanisms can also support digital trust. Digitally signed credentials can prove that a document was issued by a specific institution and that its content has not been changed after signing. Public-key infrastructure can support certificate-based issuer authentication and key management. Trusted timestamping can prove that a document or hash existed at a certain moment in time. Append-only databases can provide efficient institutional audit trails. W3C Verifiable Credentials can provide a standardized and interoperable format for issuing and verifying digital credentials. Therefore, the proposed system does not assume that blockchain is necessary for every educational credential verification scenario. If the verification task is limited to a single university, a single trusted issuer, and a small number of credentials, digitally signed documents, PKI, trusted timestamping, or Verifiable Credentials may provide a simpler and more efficient solution. However, the target environment of this study is different. The proposed platform is intended for a multi-institutional higher education ecosystem in which universities, state bodies, students, graduates, employers, and external verifiers interact with academic records over the long term. In such an environment, the main requirements are not only document authenticity but also shared auditability, traceable registration, controlled institutional participation, and verification that does not depend exclusively on a single university database or a single central system operator. A permissioned blockchain is used in the proposed architecture because it provides a shared tamper-evident registration layer for verification-critical academic records. Authorized educational institutions can write transcript and diploma-related records through smart contracts, while transaction hashes and event logs provide evidence that a record was registered at a specific point in the ledger history. The blockchain layer also supports distributed governance, because validator participation can be restricted to approved universities or state bodies. This is important for a national educational infrastructure, where unrestricted public blockchain participation is unnecessary, but independent auditability across institutions is valuable. The proposed blockchain layer should therefore be understood as complementary to, rather than a replacement for, existing trust mechanisms. Digital signatures may be used to protect the document itself; PKI may be used to authenticate issuers and manage keys; W3C Verifiable Credentials may be used as an interoperable credential format; trusted timestamping may provide additional temporal proof; and the permissioned blockchain may provide a shared, tamper-evident, multi-institutional audit layer. The specific contribution of the proposed platform lies in combining these trust requirements with off-chain educational data management, Smart Bridge-based official data verification, role-based institutional access, and frontend-based verification services. The comparison of blockchain with alternative solutions for educational document verification systems is shown in Table 7.

Table 7. Comparison of blockchain with alternative solutions.

Alternative	Specifications	Limitations	Role Relative to the Proposed System
Digitally signed credentials	Confirms issuer identity and document integrity	Verification still depends on issuer keys, certificate validity, and document availability.	Can complement blockchain by signing the credential file
PKI	Manages issuer certificates and public–private key trust	Does not by itself provide a shared multi-institutional audit ledger of academic record events	Useful for authenticating universities and platform services
Append-only database	Efficient institutional audit trail	Usually controlled by one organization; weaker independent verification across institutions.	Useful for internal logs, but not sufficient as a shared trust layer
Trusted timestamping	Proves that data existed at a specific time	Usually depends on a trusted timestamping authority; does not manage educational workflows or multi-role access.	Can complement blockchain for additional temporal proof
W3C Verifiable Credentials	Provides interoperable credential format and tamper-evident digital credentials	Does not by itself define a national shared registration ledger or institutional governance model	Can be adopted as a future credential format
Permissioned blockchain	Shared tamper-evident ledger, controlled institutional participation, transaction hashes, event logs, distributed auditability	More complex than simpler mechanisms; requires governance and validator coordination	Justified when multi-institutional auditability and independent verification are required

Overall, the proposed system does not claim that blockchain is inherently more efficient than digitally signed credentials, PKI, append-only databases, trusted timestamping, or W3C Verifiable Credentials. These mechanisms are suitable and often preferable for simpler credential verification scenarios. In this study, a permissioned blockchain is justified by the need for a shared tamper-evident registration layer across multiple higher education institutions and state-level stakeholders, where academic records require long-term traceability, role-controlled registration, independent auditability, and verification that does not depend solely on a single institutional database.

6.3. Interpretation of the Experimental Findings

The experimental results show that the proposed platform is technically feasible as a controlled prototype of a blockchain-supported educational document verification system. The most important result is not simply that the frontend, backend, PostgreSQL database, Smart Bridge, and blockchain nodes were deployed, but that the main verification workflow could be executed across these components. Academic records can be submitted through the backend, registered via smart contracts, confirmed on the private Ethereum network, linked back to PostgreSQL via transaction hashes, and later checked for off-chain/on-chain consistency verification.

The blockchain measurements provide a preliminary execution profile of the prototype. The private Ethereum testbed recorded 1937 blocks and 4272 transactions. The average gas consumption was approximately 226,125 gas per transaction, while the observed range extended from 21,000 gas for the simplest transaction type to 823,457 gas for more complex smart-contract operations. The system processed an average of 65.72 transactions per block, with a maximum of 90 transactions per block. These values indicate that the implemented smart-contract layer can process different transaction types in a predictable private-network environment. However, they should be interpreted as prototype-level measurements, not as proof of full national-scale scalability.

The gas-consumption results also clarify an important design trade-off. Direct storage of large academic records on-chain would be inefficient and privacy-sensitive. Therefore, the platform uses PostgreSQL for operational data management and the blockchain layer for registration evidence, transaction hashes, event logs, and cryptographic anchoring. This confirms the appropriateness of the hybrid design: the relational database provides efficient search, filtering, and integration with educational workflows, while the blockchain provides tamper-evident evidence for selected verification-critical records.

The database/blockchain consistency tests are especially important for interpreting the value of the proposed architecture. A transaction hash alone does not prove that a PostgreSQL row remains unchanged. The system becomes verifiable only when the transaction hash is used to retrieve the corresponding blockchain transaction or event log and compare the on-chain payload or commitment with the current off-chain database record. Therefore, the main security contribution of the blockchain layer is post-registration tamper detection, not automatic correctness of the originally submitted academic data. If an off-chain record is modified after registration, the inconsistency can be detected by comparing the current PostgreSQL data with the immutable on-chain reference.

6.4. Limitations and Future Development Directions

Although the proposed platform demonstrates a complete and practically implemented architecture, several limitations should be considered. The first limitation is related to scalability and operational governance. The blockchain layer has been designed to register only selected, trust-sensitive records, reducing unnecessary on-chain storage. Nevertheless, national-scale deployment may require the processing of large volumes of transcript entries, diploma records, verification requests, and transaction confirmations. This requires careful planning of validator nodes, block capacity, transaction throughput, monitoring procedures, and long-term operational costs.

The second limitation concerns privacy. The platform avoids storing full educational documents directly on-chain, which reduces the risk of exposing sensitive academic and personal data. However, even identifiers, metadata, transaction hashes, and event logs may pose privacy risks if linked to specific individuals. Therefore, future versions of the platform should consider privacy-enhancing mechanisms such as selective disclosure, zero-knowledge proofs, stronger anonymization of student identifiers, and policy-based access to verification results. This is especially important because academic records are legally and personally sensitive.

The third limitation is integration complexity. The proposed architecture includes several interacting subsystems: the frontend, the backend, the PostgreSQL database, Smart Bridge, blockchain smart contracts, external services, and blockchain explorer tools. While this integration provides rich functionality, it also increases deployment and maintenance complexity. In real conditions, the system must remain compatible with university LMS platforms, national education registries, Smart Bridge services, and legal requirements for electronic documents. This means that further standardization of data formats, API contracts, catalog mappings, and interinstitutional exchange procedures will be necessary.

Privacy protection of blockchain-related educational data remains an important direction for future development. The current architecture reduces privacy risks by avoiding the direct storage of raw personal and academic data on-chain. Student identifiers, grades, ECTS credits, diploma numbers, educational program information, and other attributes that can be directly linked to academic records should remain in the off-chain database or in institutional information systems. The blockchain layer should store only cryptographic commitments, transaction references, event logs, and minimal technical metadata required for verification.

However, privacy risks may still arise in the off-chain layer, especially when academic records are searched, filtered, corrected, revoked, or verified repeatedly by different stakeholders. Even if the data are encrypted at rest, query patterns, access frequency, keyword repetition, and record-update behavior may reveal sensitive information about students, graduates, institutions, or document status. Therefore, future versions of the platform may incorporate privacy-preserving query mechanisms, including encrypted search and dynamic searchable symmetric encryption.

One possible direction is the use of encrypted rich-query mechanisms with forward and backward privacy, such as HeX-like approaches based on trusted execution environments. In such an extension, the off-chain database would store encrypted academic records and encrypted indexes, while query processing would be performed either over encrypted structures or inside a trusted execution environment. The trusted hardware component would protect sensitive query state and cryptographic keys during computation, while the blockchain would continue to provide tamper-evident registration and auditability.

Some concerns are also related to academic document verification systems that must support the full lifecycle of educational records. Grades may be corrected after appeal procedures, transcript entries may be updated, diplomas may be revoked, institutions may lose accreditation, and signing keys may be compromised. Therefore, blockchain immutability should not be interpreted as the impossibility of correcting or invalidating a record. In the proposed system, already registered blockchain records are not deleted or overwritten. Instead, any lifecycle change is represented by a new signed transaction linked to the original blockchain record. The smart-contract layer should maintain a record-status model. Each registered academic record may be in one of several states, such as Active, Corrected, Superseded, Suspended, Revoked, or Under Review. The initial registration transaction creates an Active record. A correction, revocation, suspension, or reissuance operation does not modify the old transaction. It creates a new event that references the original record identifier and original transaction hash. This preserves the historical audit trail while enabling verifiers to determine the document’s current validity status.

For corrections, the issuing university submits a correction transaction after completion of the relevant institutional approval workflow. The correction transaction contains a reference to the original record, the corrected record commitment, the correction reason code, the approving authority or decision identifier, the issuer address, and the timestamp. The original record remains in the ledger as historical evidence, but its status changes to Corrected or Superseded. The corrected record becomes the latest valid version. In the off-chain PostgreSQL database, the original and corrected records are linked via a version chain, while the blockchain stores the corresponding correction event and the new cryptographic commitment.

For revocation, an authorized institution or competent authority submits a revocation transaction. This transaction references the original diploma or transcript record, the original transaction hash, the reason for revocation, the revocation authority, and the timestamp. The revocation does not erase the original record from the blockchain. Instead, it changes the record’s validity status to Revoked. During verification, the system must check both the original registration transaction and all subsequent lifecycle events associated with the same record identifier. A credential is considered valid only if the original registration exists, the transaction was successful, the issuer was authorized at the time of issuance, and no subsequent revocation or unresolved suspension event has occurred. Institutional accreditation changes are handled through an issuer-registry mechanism. Each university or authorized organization has an issuer status, such as Active, Suspended, Revoked, or Expired. The registry also stores the validity interval of the institution’s authorization. If an institution loses accreditation or is suspended, its issuer status is updated through an administrative transaction.

New academic-record registration from that institution is blocked while the suspension or revocation is active. Historical records issued during a valid accreditation period remain verifiable unless they are separately revoked or placed under review by the competent authority. Key-compromise procedures are also required. Each institutional signing key or blockchain account must have a lifecycle status and validity interval. If a key is suspected to be compromised, the system administrator or governance authority records a KeyCompromised event, suspends or revokes the affected key, and blocks further submissions from that key. A replacement key is registered through an authorized administrative or multi-signature procedure. Records submitted during the suspected compromise interval are marked as UnderReview until the issuing institution or competent authority confirms their validity or revokes them. Verification must therefore check not only the academic record status but also the issuer status, signing-key status, and key validity interval at the time of record registration.

6.5. Unexpected Outcomes, Limitations and Future Works

One important unexpected outcome was observed during concurrent transaction testing. When multiple academic-record transactions were submitted asynchronously from the same sender account, the system produced nonce-related errors, including “nonce too low” and “replacement transaction underpriced”. This showed that the main scalability issue in the prototype was not only block capacity or gas consumption, but also transaction-ordering control at the backend/blockchain interface.

The introduction of a middleware-level Nonce Manager resolved this problem by placing asynchronous transaction requests into a synchronized queue and assigning nonce values atomically before submission to the Geth transaction pool. This result is important because it demonstrates that integrating blockchain into educational platforms requires not only smart contract design but also reliable middleware for transaction orchestration. Without such a component, concurrent submissions from institutional systems may lead to rejected transactions and inconsistent backend states.

Another practical finding concerns failure recovery and data persistence. The Docker-based deployment required careful handling of blockchain data directories to prevent the chain from being reinitialized during container restarts. This finding confirms that production deployment must include explicit procedures for node restart, data persistence, monitoring, and recovery. Therefore, infrastructure reliability is as important as smart-contract correctness.

The current evaluation was performed in a local private Ethereum environment with three nodes deployed in a controlled infrastructure. This setup made it possible to validate smart-contract execution, gas consumption, transaction monitoring, consistency checking, and selected failure-recovery scenarios. However, it does not reproduce the latency, governance complexity, validator independence, and operational risks of a geographically distributed consortium network.

Another important direction for future development is the integration of efficient, verifiable mechanisms for querying blockchain data. In the current prototype, PostgreSQL serves as an off-chain index for efficient search, filtering, and aggregation, while the blockchain provides immutable verification evidence via transaction hashes, smart contract events, and cryptographic commitments. This approach is sufficient for basic verification, where a user checks one transcript or diploma record by comparing the current off-chain record with the corresponding on-chain evidence. However, national-scale deployment may require more complex queries, such as searching records by issuer, academic year, document type, verification status, correction status, revocation status, or transaction period. A possible extension is to introduce a VQL-like verifiable query layer. VQL was proposed to address the inefficiency of direct blockchain queries and the authenticity problem of indirect queries over external blockchain databases. Its middleware extracts blockchain data, reorganizes it in databases, calculates cryptographic fingerprints over the constructed databases, and writes these fingerprints to the blockchain so that users can verify query authenticity. In the proposed educational platform, this idea could be adapted as a Verifiable Educational Query Layer. Such a layer would index blockchain events, transaction hashes, issuer addresses, record statuses, document types, and cryptographic commitments related to transcripts and diplomas. For each indexed state, the query layer could compute a Merkle root or cryptographic fingerprint and anchor it on-chain. As a result, when a user searches for academic-document verification data, the system could return not only the query result but also proof that it corresponds to the blockchain-anchored index state.

A second possible extension is the use of TELEX-like privacy-preserving rich query processing. TELEX addresses privacy and result integrity for blockchain queries by using a trusted execution environment and oblivious RAM, and introduces a two-level learned index within the trusted environment for integer and string keys. It also supports exact, aggregate, Boolean, and range queries. In the proposed educational platform, this approach could be useful for privacy-sensitive academic-record queries. For example, authorized users may need to search encrypted diploma records by issue year, institution, document type, verification status, or revocation status without exposing raw student identifiers, grades, diploma numbers, or other personal academic data. A trusted execution environment could protect query execution, keys, and index state, while the blockchain would continue to provide tamper-evident anchoring and auditability.

The evaluation also does not yet include a full concurrent-user test at the frontend level, long-duration stress testing with realistic university workloads, adversarial penetration testing, or formal verification of smart contracts. Therefore, the results should be interpreted as a prototype validation. Future work must include distributed validator deployment, larger transaction workloads, multi-institutional stress testing, external smart-contract audit, privacy-preserving verification tests, and comparison with W3C Verifiable Credentials and digitally signed credential baselines.

Future development should focus on testing the system under larger transaction loads using realistic datasets from multiple higher education institutions; privacy-preserving verification so that external verifiers can confirm academic record validity without unnecessary exposure of personal data; expansion of the Smart Bridge integration for covering additional government and educational services; formal verification and security auditing of smart contracts to reduce the risk of implementation errors in authorization, transcript registration, and diploma verification logic.

Overall, the proposed platform provides a strong basis for a national blockchain-based educational document verification environment. The practical contribution of this study lies in the development and validation of a working platform of a blockchain-based educational document verification system adapted to the higher education environment of Kazakhstan. The system is not limited to a smart-contract experiment. It combines backend services, PostgreSQL off-chain storage, Smart Bridge integration, Ethereum-compatible smart contracts, blockchain monitoring, and frontend modules into a single educational document management and verification workflow.

7. Conclusions

This research presented the design and practical implementation of a blockchain-based educational platform for the secure management, registration, and verification of academic documents in the higher education environment of the Republic of Kazakhstan. Unlike other solutions that focus only on anchoring certificate hashes or verifying final diplomas, the proposed platform was developed as a multifunctional system that integrates several complementary subsystems: a frontend web portal, a C# ASP.NET backend service, a PostgreSQL off-chain database, a Smart Bridge integration layer, and an Ethereum-compatible blockchain network with smart contracts. This architecture demonstrates that Blockchain can be effectively integrated into an existing higher education ecosystem, not as a replacement for current university information systems, but as an additional trust layer that enhances integrity, transparency, traceability, and independent verification of academic records.

The main contribution of the study lies in the development of a hybrid multi-layered platform that separates operational educational data from trust-sensitive verification data. The backend subsystem provides the platform’s central business logic, manages user roles and permissions, processes data from the off-chain PostgreSQL database, and coordinates interactions with the blockchain network. The off-chain database stores student and graduate profiles, catalogs, academic and diploma metadata, and transaction hashes. This makes it possible to preserve the efficiency and flexibility of conventional educational information systems while avoiding unnecessary storage of full academic documents on-chain. At the same time, the blockchain subsystem registers selected transcript and diploma-related data through smart contracts, creating an immutable link between the off-chain record and its on-chain transaction proof.

The proposed architecture separates operational educational data from verification-critical evidence. Student profiles, catalogs, templates, transcript metadata, and diploma metadata are managed off-chain, while blockchain transactions, event logs, and cryptographic commitments provide tamper-evident verification of selected academic records. This design supports document integrity, traceability, auditability, and independent verification while avoiding unnecessary publication of full personal or academic data on-chain. The implemented prototype demonstrated the technical feasibility of the approach. The private Ethereum testbed recorded 1937 blocks and 4272 transactions, with an average gas consumption of approximately 226,125 gas per transaction. The evaluation also showed the importance of transaction-hash synchronization, off-chain/on-chain consistency checking, role-based authorization, blockchain monitoring, and nonce management during concurrent transaction submission.

From a practical perspective, the platform demonstrates how blockchain can be integrated into a national educational document workflow, alongside Smart Bridge-based identity-related data exchange, standardized catalogs, frontend-based user access, and backend-controlled document processing. This makes the system useful not only as a technical blockchain prototype, but also as a practical model for trusted transcript and diploma verification involving universities, students, graduates, employers, verifiers, and educational authorities. At the same time, the results are presented on an experimental scale, taking into account that the system is being prepared for full national-scale deployment. Further work is required to test the system with larger institutional datasets, distributed validator nodes, stronger privacy-preserving verification mechanisms, formal smart-contract audits, usability studies with real stakeholders, and integration with international digital credential standards.