A social examination system based on blockchain and distributed storage

Abstract

A social examination system based on blockchain and distributed storage belongs to the field of blockchain technology and education informatization. The present application aims at the problems of low security, poor expansibility of centralized storage of the existing social examination system, and high communication complexity of traditional consensus algorithm, and is difficult to adapt to high concurrency scene. A hybrid storage architecture of on-chain and off-chain cooperation is constructed. The system first uses the alliance chain underlying platform to manage the core metadata and smart contract logic, and stores the large capacity examination data after encryption through the distributed file system. Secondly, the system embeds a multi-dimensional dynamic reputation model and an improved Byzantine fault tolerance mechanism in the business running process, and automatically executes node reputation evaluation, dynamic election based on verifiable random function and efficient data on-chain consensus through the smart contract system. The present application reduces the communication overhead of the system while ensuring the whole process of examination data unforgeable and privacy security, and improves the transaction throughput and Byzantine fault tolerance ability of the system.

Description

Technical Field

[0001] This invention belongs to the interdisciplinary field of blockchain technology and educational informatization, and specifically relates to blockchain data storage, distributed storage architecture and consensus algorithm design, and specifically relates to a social examination system based on blockchain and distributed storage. Background Technology

[0002] With the rapid development of blockchain technology, its decentralized, immutable, and traceable characteristics have been widely applied in fields such as finance and supply chain. In the field of educational informatization, social examinations (such as self-study examinations and professional qualification certifications) involve complex processes such as candidate registration, test paper distribution, answer sheet collection, and result release, which place extremely high demands on data security, fairness, and privacy protection.

[0003] Traditional social examination systems often use centralized database storage, which poses a single point of failure risk and makes it difficult to establish a reliable data sharing and collaboration mechanism among multiple institutions (such as examination authorities, educational support institutions, and regulatory departments).

[0004] Currently, consortium blockchains, due to their controllable access mechanisms, have become the preferred architecture for building trusted social examination systems. However, existing consortium blockchain technologies face severe challenges when processing the massive amounts of unstructured data in social examinations (such as high-definition scanned copies of exam papers and surveillance video streams). Existing technologies typically write all data directly to the blockchain, causing the block size to expand rapidly, severely slowing down node synchronization speed and retrieval efficiency, and failing to meet the storage requirements of high-concurrency scenarios.

[0005] Furthermore, the consensus mechanism, as the core of blockchain, directly determines the system's performance and security. While the existing Practical Byzantine Fault Tolerance (PBFT) algorithm is applicable to consortium blockchains to some extent, it suffers from drawbacks such as high communication overhead and lack of reputation incentives when large-scale social testing node access occurs, making it highly susceptible to network storms and congestion.

[0006] Therefore, designing a social examination system that can efficiently process massive amounts of data and embed an efficient reputation mechanism is of great significance for blockchain-based educational big data applications. Summary of the Invention

[0007] To address the issues of low security and susceptibility to data tampering in existing social examination systems due to centralized storage, as well as the high communication overhead and difficulty in adapting to high-concurrency scenarios using traditional blockchain consensus algorithms, this invention provides a social examination system based on blockchain and distributed storage.

[0008] This invention is achieved through the following technical solution: A social examination system based on blockchain and distributed storage, characterized by the following steps: Step 1: Constructing an on-chain and off-chain collaborative storage and reputation node architecture for social examinations: A hybrid architecture combining consortium blockchain and distributed file system is adopted. The consortium blockchain is responsible for core data storage and logical control, while the distributed file system is responsible for large-capacity examination data storage; at the same time, a reputation-based dynamic node network structure is constructed.

[0009] Construct a collaborative architecture consisting of a distributed storage layer, a trusted evidence storage layer, and an access service layer; In the distributed storage layer, a private IPFS cluster is deployed to store encrypted test question files, scanned copies of answer sheets, and large volumes of unstructured data from surveillance videos, and to generate a unique content addressing hash (CID). At the access service layer, a globally unique identifier (FileID) is generated for the exam file, the national cryptographic SM4 algorithm is used for encryption and fragmentation, and the file is uploaded to the IPFS cluster; at the same time, it is responsible for cross-chain index mapping and data encryption and decryption operations. At the trusted evidence storage layer, the FISCO BCOS consortium blockchain is used, and a smart contract is employed to anchor a quadruple consisting of the file CID, encryption key hash, timestamp, and operator signature.<FileID, CID,KeyHash, Timestamp> Write to the RocksDB state database to implement tamper-proof verification of off-chain entities; The system nodes are divided into examination center nodes (super administrators), invigilation nodes (data collection and verification), candidate nodes (limited queries), and supervision nodes (audit). Based on the system's built-in reputation logic, the above nodes are dynamically mapped to high reputation groups (HCG), medium reputation groups (MCG), and low reputation groups (LCG). HCG and MCG form a consensus network, while LCG only performs data synchronization.

[0010] Step 2: Deploy the full-process business logic and embedded consensus smart contract system: Deploy permission management, identity authentication, exam management, grade management and emergency management contracts on the consortium blockchain, drive the logic control of the entire exam lifecycle through a state machine, and embed a reputation consensus mechanism in this contract system to automatically execute node reputation assessment, consensus committee election and data on-chain consensus.

[0011] Business Logic Control: **Access Control Contract:** Maintains a three-tiered access control list ("Administrator-Teacher-Examinee") based on the RBAC model. All business contracts must call the `checkRole` modifier for authentication before execution. **Identity Authentication Contract:** Manages user digital certificates based on the PKI system, binding the public key issued by the CA to the on-chain account. **Exam Management Contract:** Maintains the exam state machine (inactive / in progress / paused / completed), with a built-in circuit breaker mechanism. When a large number of abnormal requests or network attacks are detected within a short period, the `triggerFuse` method is automatically triggered to pause the service and notify off-chain nodes to take a data snapshot. **Grade Management Contract:** Uses a Merkle tree structure to batch store grades, writing only the Merkle Root to the block header, supporting lightweight SPV verification. **Emergency Management Contract:** Responsible for system recovery after a circuit breaker, allowing administrators to call the `restoreSystem` interface via a multi-signature mechanism to restore the most recent security snapshot from IPFS.

[0012] Embedded reputation consensus logic: When executing the above business, the system's smart contract drives the following process through a built-in algorithm: Node Dynamic Reputation Assessment: A multi-dimensional dynamic reputation model is established to calculate the node's comprehensive reputation value based on historical behavior credibility, response timeliness, and contribution to cheating detection, and this value is updated after each round of business operations; the specific calculation formula is as follows:

[0013] in, , The weighting coefficients are and satisfy the following conditions: .

[0014] 1) Credibility of the stated historical behavior This reflects the long-term stability of a node, determined by the ratio of the number of times a node successfully participates in consensus to the total number of times it participates. A malicious behavior attenuation factor is also incorporated, and the calculation formula is as follows:

[0015] in For the total number of times, The total number of successful consensuses. The attenuation coefficient; 2) The timeliness of the response This reflects the network performance of the nodes and is calculated based on the deviation between the average node response time and the system baseline time. The calculation formula is as follows:

[0016] in To respond to the delay, The baseline threshold; 3) The contribution of the cheating detection This reflects the contribution of a node to reporting malicious behavior, specifically the number of valid malicious behavior reports made by the associated node. The calculation formula is as follows:

[0017] in, To determine the number of valid reports, Number of false alarms Smoothing coefficient (default) )

[0018] Reputational election based on VRF: A consensus committee is formed by randomly selecting nodes within the HCG and MCG groups using a verifiable random function (VRF), and the roles of master node and supervisor node are assigned. Specifically, the VRF function is run using the private key sk and the random number seed from the previous block.<hash, proof> = VRF_Eva(sk, seed), and calculate the lottery value by combining the reputation value. Select the node with the largest lot value.

[0019] Implementing improved GPBFT consensus: The consensus committee, based on a many-to-one communication optimization model, completes the network-wide consensus and on-chain recording of business data through five stages: request, preparation, submission, statistics, and response.

[0020] Request phase: The client sends a request message to the master node. The message includes the transaction request content, timestamp, client number and node signature. Prepare phase: The master node collects and verifies messages, packages the verified requests into blocks and assigns sequence numbers, and broadcasts them to the entire network. The message includes the view number, block sequence number, block information and hash value. The commit phase: After receiving and verifying the prepare message, the consensus node sends a voting message to the master node. The message contains the consensus node's voting result and the received message digest. Count phase: When the master node receives more than 2f+1 voting messages, it determines the result according to the majority decision principle and broadcasts the final voting result to the entire network; Reply Phase: After all nodes in the network receive and verify the count message, they perform on-chain operations and send reply messages to the client. When the client receives 2f+1 replies, it confirms that consensus has been reached.

[0021] The beneficial effects of this invention are as follows: This invention adopts a hybrid architecture of "IPFS storage entity + consortium blockchain storage metadata", which solves the "block bloat" problem caused by directly storing large files on the blockchain. At the same time, it uses on-chain hash anchoring to ensure the immutability of off-chain data. The GPBFT algorithm eliminates low-quality nodes through reputation grouping, defends against targeted attacks by using VRF random master election, and reduces complexity from many-to-one communication optimization. The system reduces transaction throughput (TPS) and significantly improves transaction throughput (TPS) in high-concurrency scenarios. The built-in circuit breaker mechanism and reputation-based supervisory node mechanism of smart contracts ensure that the system can automatically protect data and recover quickly when it suffers external attacks or malicious behavior from the master node. Attached Figure Description

[0022] Figure 1 is a logical architecture diagram of the social examination system based on blockchain and distributed storage of the present invention; Figure 2 is a schematic diagram of the improved GPBFT voting algorithm of the present invention. Figure 3 is a flowchart of the five-stage interaction of the GPBFT consensus protocol of the present invention; Figure 4 is a flowchart of the file upload and evidence storage process for on-chain and off-chain collaborative storage according to the present invention. Detailed Implementation

[0023] A social examination system and consensus method based on blockchain and distributed storage includes the following steps: Step 1: Construct a collaborative storage and reputation node architecture for social examination chains: Adopt a hybrid architecture combining consortium blockchain and distributed file system. The consortium blockchain is responsible for core data storage and logical control, while the distributed file system is responsible for large-capacity examination data storage; at the same time, a reputation-based dynamic node network structure is constructed.

[0024] Specifically, considering the large volume and high sensitivity of social examination data, this invention constructs a three-layer architecture consisting of a "distributed storage layer," a "trusted evidence storage layer," and an "access service layer." For example... Figure 1 As shown in the diagram, the logical architecture of the social examination system based on blockchain and distributed storage in this invention presents an overall layout of on-chain and off-chain collaboration. As can be seen in the diagram, the left side of the system represents a hybrid storage and data anchoring pipeline, while the right side represents a dynamic reputation governance and consensus pipeline. After data from clients or data sources is processed by the access service gateway, the entity files are stored in the IPFS cluster, while the hash index is stored on the blockchain.

[0025] Distributed storage layer: Employs a private IPFS (InterPlanetary File System) cluster for storing unstructured entity data. The front-end system generates globally unique identifiers (FileIDs) for large files such as test questions, answer sheets, and surveillance videos. It then uses the national cryptographic algorithm SM4 to generate a 128-bit random key (DEK) and initialization vector (IV) to encrypt the files. The encrypted ciphertext files are then fragmented into 4MB chunks and uploaded to the IPFS nodes. IPFS returns a unique content identifier (CID). Figure 4 The flowchart of file upload and notarization process for on-chain and off-chain collaborative storage in this invention is shown. As can be seen from the diagram, when a candidate or user uploads an exam file, the client / encryption module first performs symmetric encryption on the file, then uploads the encrypted ciphertext fragments to the IPFS storage network and obtains the CID, and then constructs a transaction proposal containing a signature and sends it to the blockchain smart contract for verification and packaging.

[0026] Trusted Evidence Storage Layer: Employs the FISCO BCOS consortium blockchain. The on-chain RocksDB database does not store original files, but only core metadata quadruples.<FileID, CID, KeyHash, Timestamp> KeyHash is a hash digest (Keccak-256) of the encryption key, used to verify the correctness of the decryption key later.

[0027] Access Service Layer: Deploys a cryptographic proxy gateway and a cross-chain adapter. The cryptographic gateway is responsible for key lifecycle management; the cross-chain adapter is responsible for establishing a two-way index mapping between off-chain CIDs and on-chain transaction hashes (TxHash).

[0028] Node roles and reputation groups: The system includes examination center nodes that act as super administrators and are responsible for node access and certificate issuance; invigilator nodes that are responsible for collecting and uploading examination data for verification; candidate nodes that have limited query and interaction permissions; and supervisory nodes that are responsible for auditing logs and emergency response.

[0029] To ensure the efficient operation of the system, a dynamic reputation grouping mechanism is introduced into the system architecture: Dynamic grouping: based on the reputation score calculated in step 2 described later. The nodes across the network are ranked. The top 20% of nodes enter the High Reputation Group (HCG) as the main force for consensus; the middle 60% enter the Medium Reputation Group (MCG) as alternate validators; and the bottom 20% enter the Low Reputation Group (LCG), which only acts as observers to synchronize blocks and does not participate in the core consensus.

[0030] Step 2: Deploy the full-process business logic and embedded consensus smart contract system: Deploy permission management, identity authentication, exam management, grade management and emergency management contracts on the consortium blockchain, drive the logic control of the entire exam lifecycle through a state machine, and embed a reputation consensus mechanism in this contract system to automatically execute node reputation assessment, consensus committee election and data on-chain consensus.

[0031] Specifically, this involves deploying five types of tightly coupled smart contracts on the consortium blockchain to automate the execution of business logic: 1) Deployment of business smart contracts: The AuthorityContract, based on the RBAC model, defines the roles ROLE_ADMIN (examination center), ROLE_TEACHER (invigilator), and ROLE_STUDENT (examinee). It maintains an (Address => Role) mapping table, and all business contracts must call the checkRole modifier for authentication before execution.

[0032] Identity Contract: Manages user digital certificates based on the PKI system. When a user registers, the public key issued by the CA is bound to the on-chain account, generating an immutable identity profile.

[0033] The Exam Management Contract (ExamContract) maintains the exam state machine (Init -> Ready -> Running -> Finished). It features a built-in circuit breaker mechanism: the contract maintains an exception counter. When an illegal request exceeding the threshold (such as a submission outside of exam hours) or a consensus timeout is detected within a unit of time, triggerFuse() is automatically triggered, setting the system state to Emergency, suspending all write operations, and triggering an event notification to off-chain nodes to take a data snapshot.

[0034] Grade Management Contract: Implements tamper-proof grade management. After grading is completed, the contract calculates the Merkle Tree for all grades, storing only the Merkle Root in the block header, thus protecting privacy while supporting lightweight verification via MerkleProof.

[0035] Emergency Contract: Responsible for recovery after a circuit breaker. It allows administrators to use multi-signature calls to the restoreSystem interface to pull the most recent security snapshot from IPFS and restore the system state.

[0036] 2) Specific implementation of embedded reputation consensus logic: When the system executes the above business contract, it automatically triggers the following consensus and election logic: 2.1) Node Dynamic Reputation Assessment To quantify node reliability, the system updates the node reputation value after each round of consensus. The calculation formula is as follows:

[0037] in, , The weighting coefficients are and satisfy the following conditions: .

[0038] Credibility of historical behavior Reflecting the long-term stability of a node, it is determined by the ratio of the number of times a node successfully participates in consensus to the total number of times, and incorporates a malicious behavior attenuation factor.

[0039]

[0040] in This represents the number of times a node has successfully participated in consensus. Total number of participations This is the attenuation factor. Once wrongdoing occurs, the reputation value decays exponentially.

[0041] Timeliness of response The performance of the node network and computing is reflected by the deviation between the average node response time and the system baseline time. The calculation formula is as follows:

[0042] in Due to node response delay, The baseline timeout threshold set for the system.

[0043] Contribution to cheat detection The incentive node acts as a "supervisor," reflecting its contribution to reporting malicious behavior. The number of valid malicious behavior reports made by associated nodes is calculated using the following formula:

[0044] in To effectively report the number of malicious nodes, Number of false alarms Smoothing coefficient (default) To prevent the denominator from being 0; the system maintains a global reputation table, and the smart contract automatically updates the node reputation after each round of consensus.

[0045] 2.2) Reputation-based group election using VRF: After determining the HCG and MCG groups, the system performs a VRF lottery: like Figure 2 The improved GPBFT voting algorithm of this invention is illustrated in the loop diagram, where the reputation assessment of nodes and the consensus election form a dynamic closed loop. As shown in the diagram, the entire network node pool is dynamically divided into high-reputation group (HCG), medium-reputation group (MCG), and low-reputation group (LCG) based on the assessment. Subsequently, the system selects nodes from the HCG and MCG to form a consensus committee (central area in the diagram) through the VRF election mechanism.

[0046] Nodes in HCG and MCG use the private key sk and the random number seed from the previous block to run VRF functions:

[0047] Calculate the overall lottery value (lot):

[0048] This formula combines the complete randomness of VRF with the weight of reputation value. The M nodes with the largest lot values ​​are selected to form a consensus committee (CC). Within the committee, the node ranked 1st in lot is automatically elected as the speaker, the node ranked 2nd is elected as the supervisor, and the rest are validators.

[0049] 2.3) Implementing the improved GPBFT consensus

[0050] The consensus committee completed the data upload process using an improved five-phase GPBFT protocol. like Figure 3 The five-stage interaction flowchart of the GPBFT consensus protocol of this invention is shown in the diagram. The diagram illustrates that the entire consensus process unfolds sequentially between the client, master node, consensus node, and all network nodes: Request phase: The client sends a request message to the master node based on specific communication rules and security mechanisms. .in, Indicates the message type. It is a client's transaction request. It's a timestamp. It's the client number. It is a node signature.

[0051] Prepare phase: The master node collects and verifies non-consensus data. The message packages verified transaction requests into a block in the correct chronological order, assigns a unique sequence number, and broadcasts the message to the entire network. .in, Indicates the message type. It is the view number. It is the block sequence number. It's block information. It is a hash value. It is the node number.

[0052] commit phase: Consensus nodes receive... After the message is verified, a voting message is sent to the master node. .from Figure 3 As can be seen, this stage employs a many-to-one communication mode (step ③), where consensus nodes directly send information to the master node. Indicates the message type. It is the voting of consensus nodes. It is received by the consensus node. information.

[0053] Count phase: When the master node receives more than... strip After receiving the message, the master node will determine the result according to the pre-established majority decision principle, and then broadcast the final voting result to the entire network. .in, Indicates the message type. It's the voting result. It was received by the master node. message set, f It represents the number of Byzantine nodes in the consensus network.

[0054] Reply phase: Node receives After the message is processed and verified, a reply message is sent to the client. .in, Indicates the message type. This is the result of the client's transaction request. When the client receives 2 strip The message indicates that a consensus has been reached on the request.

Claims

1. A social examination system based on blockchain and distributed storage, characterized in that, Includes the following steps: Step 1: Constructing an on-chain and off-chain collaborative storage and reputation node architecture for social examinations: A hybrid architecture combining consortium blockchain and distributed file system is adopted, with the consortium blockchain responsible for core data storage and logical control, and the distributed file system responsible for large-capacity examination data storage; at the same time, a dynamic node network structure based on reputation layering is constructed. Step 2: Deploy the full-process business logic and embedded consensus smart contract system: Deploy permission management, identity authentication, examination management, grade management and emergency management contracts on the consortium blockchain, and drive the logic control of the entire examination lifecycle through a state machine; and embed reputation consensus execution logic in this contract system to simultaneously complete node reputation calculation, committee election and data consistency consensus when processing business requests.

2. The social examination system based on blockchain and distributed storage according to claim 1, characterized in that, The specific method in step one is as follows: Construct a collaborative architecture consisting of a distributed storage layer, a trusted evidence storage layer, and an access service layer; In the distributed storage layer, a private IPFS cluster is deployed to store encrypted test question files, scanned copies of answer sheets, and large volumes of unstructured data from surveillance videos, and to generate a unique content addressing hash (CID). At the access service layer, a globally unique identifier FileID is generated for the exam file, the national cryptographic SM4 algorithm is used for encryption and fragmentation, and the file is uploaded to the IPFS cluster; at the same time, it is responsible for cross-chain index mapping and data encryption and decryption operations. At the trusted evidence storage layer, the FISCO BCOS consortium blockchain is used, and a smart contract is employed to anchor a quadruple consisting of the file CID, encryption key hash KeyHash, timestamp, and operator signature.<FileID, CID, KeyHash,Timestamp> Write to the RocksDB state database to implement tamper-proof verification of off-chain entities; The system nodes are divided into examination center nodes that act as super administrators, invigilator nodes that are responsible for data collection and verification, candidate nodes that have limited query permissions, and supervisory nodes that are responsible for auditing. Based on the system's built-in reputation logic, the above nodes are dynamically mapped to high reputation group HCG, medium reputation group MCG, and low reputation group LCG. HCG and MCG form a consensus network, while LCG only performs data synchronization.

3. The social examination system based on blockchain and distributed storage according to claim 1, characterized in that, The specific method in step two is as follows: Step 2.1) Business logic control: including access control contract, identity authentication contract, exam management contract, grade management contract, and emergency management contract; Access control contract: Based on the RBAC model, maintain a three-level access list of "administrator-teacher-examinee". All business contracts must call the checkRole modifier for authentication before execution. Identity Authentication Contract: Manages user digital certificates based on the PKI system, binding the public key issued by the CA to the on-chain account; Examination Management Contract: Maintains the examination state machine, with examination states including inactive, in progress, suspended, and completed; The system features a built-in circuit breaker mechanism that automatically triggers the `triggerFuse` method to suspend service and notify off-chain nodes to take a data snapshot when a large number of abnormal requests or network attacks are detected within a short period of time. The performance management contract uses a Merkle tree structure to store performance data in batches, writing only the Merkle Root to the block header and supporting lightweight SPV verification. The emergency management contract is responsible for system recovery after a circuit breaker, allowing administrators to call the `restoreSystem` interface via a multi-signature mechanism to restore the most recent security snapshot from IPFS. Step 2.2) Embedded Reputation Consensus Logic: When executing the above business, the system's smart contract drives the following process through a built-in algorithm: Step 2.2.1) Node Dynamic Reputation Assessment: Establish a multi-dimensional dynamic reputation model, calculate the node's comprehensive reputation value based on historical behavior credibility, response timeliness, and contribution to cheating detection, and update it after each round of business; the specific calculation formula is as follows: in, , The weighting coefficients are and satisfy the following conditions: ; Credibility of historical behavior This reflects the long-term stability of a node, determined by the ratio of the number of times a node successfully participates in consensus to the total number of times it participates. A malicious behavior attenuation factor is also incorporated, and the calculation formula is as follows: in For the total number of times, The total number of successful consensuses. The attenuation coefficient; Timeliness of response This reflects the network performance of the nodes and is calculated based on the deviation between the average node response time and the system baseline time. The calculation formula is as follows: in To respond to the delay, The baseline threshold; Contribution to cheat detection This reflects the contribution of a node to reporting malicious behavior, specifically the number of valid malicious behavior reports made by the associated node. The calculation formula is as follows: in, To determine the number of valid reports, Number of false alarms For smoothing coefficients; Step 2.2.2) Reputation Election Based on VRF: A consensus committee is formed by randomly selecting nodes within the HCG and MCG groups using a verifiable random function (VRF), and the roles of master node and supervisor node are assigned. Specifically, the VRF function is run using the private key sk and the random number seed from the previous block.<hash, proof> = VRF_Eva(sk, seed), and calculate the lottery value by combining the reputation value. Select the node with the largest lot value; Step 2.2.3) Execute the improved GPBFT consensus: The consensus committee, based on a many-to-one communication optimization model, completes the network-wide consensus and on-chaining of business data through five stages: request, preparation, submission, statistics, and response. Request phase: The client sends a request message to the master node. The message includes the transaction request content, timestamp, client number and node signature. Prepare phase: The master node collects and verifies messages, packages the verified requests into blocks and assigns sequence numbers, and broadcasts them to the entire network. The message includes the view number, block sequence number, block information and hash value. The commit phase: After receiving and verifying the prepare message, the consensus node sends a voting message to the master node. The message contains the consensus node's voting result and the received message digest. Count phase: When the master node receives more than 2f+1 voting messages, it determines the result according to the majority decision principle and broadcasts the final voting result to the entire network; Reply Phase: After all nodes in the network receive and verify the count message, they perform on-chain operations and send reply messages to the client. When the client receives 2f+1 replies, it confirms that consensus has been reached.

Images