Method for sharing education data based on double-blockchain protection

Abstract

The application relates to the technical field of data sharing, and relates to an education data sharing method based on double-blockchain protection, which comprises the following steps: 1, a user DG-ID-A modifies SHATE through a TDSC contract; 2, a user DG-ID-B uses a private key SK B The course identifier and the identity identifier of the course to be shared are subjected to a signature operation and are sent to a smart contract; after receiving the request, the TDSC contract first calls a DIRCC contract to check the authority of the identity, and the authority result is returned to the TDSC contract, and the authority level of the DG-ID-B is matched with the SHATE; 3, after receiving the request, the DG-ID-A uses a private key to encrypt and send an AES key, and the DG-ID-B decrypts the data to obtain the AES key; 4, the DG-ID-B decrypts the data through the AES key to obtain original data. The application can preferably protect the security of an education data sharing process.

Description

Technical Field

[0001] This invention relates to the field of data sharing technology, and more specifically, to a method for sharing educational data under dual blockchain protection. Background Technology

[0002] Students generate massive amounts of educational data during their learning activities. This data has become a valuable, fluid asset, allowing for the extraction of meaningful and valuable information. This extracted information can then be applied to teaching activities to improve lesson plans and optimize teaching effectiveness. Furthermore, businesses can leverage educational data to effectively understand university talent, ensuring their full potential is utilized and generating greater economic and social value for production activities.

[0003] To unlock the value within educational data, data sharing becomes essential. However, this inevitably breaks down existing security boundaries in educational data management, blurring the lines of what was once data management and leading to various access control issues, thus exposing data to the risk of leakage at any time. Achieving secure and controllable circulation and sharing of educational data resources is a core scientific problem facing the application and development of educational data. To ensure data security while facilitating data sharing, a sophisticated data management method is needed to meet diverse access control requirements.

[0004] In traditional education models, teachers are responsible for compiling student grades, students rely on teachers to understand their academic performance, and schools can directly view the grades of each class. This model leads to different user needs for data access based on their roles, resulting in various permission management issues arising from the refined data management requirements in the education sector. Traditional blockchain systems, with their principle of equality for all, fail to adequately address these needs. Furthermore, in data sharing between businesses and schools, schools, to protect student privacy, only want businesses to access the student information they require. However, traditional blockchain systems, whether public, private, or consortium-based, still operate at a relatively coarse-grained level in terms of smart contract permission management, lacking effective methods to protect user personal information. Therefore, current management of educational data primarily relies on trust in the system center or third-party entities, such as central data providers and database administrators. If the data center is hacked and the database is tampered with, the system center becomes untrustworthy, and the authenticity of the educational data is lost. Summary of the Invention

[0005] The present invention provides a method for sharing educational data under dual blockchain protection, which can overcome some or all the defects of the prior art.

[0006] According to a method for sharing educational data under dual blockchain protection according to the present invention, the method includes the following steps:

[0007] Step 1: User DG-ID-A modifies the SHATE of the course to be shared through the TDSC contract; if the SHATE is level 0, DG-ID-B needs to be written into the sharing list corresponding to SC-ID in the contract.

[0008] Step 2: User DG-ID-B uses private key SK B The system signs the course identifier (SC-ID) and identity identifier (DG-ID) of the course to be shared and sends them to the smart contract. Upon receiving the request, the TDSC contract first calls the DIRCC contract to perform an authorization check on the identity, and returns the authorization result to the TDSC contract. It then matches the authorization level of DG-ID-B with the SHATE of the SC-ID. If the authorization matches successfully, the system returns the AES-encrypted key and corresponding hash of the SC-ID and sends a request to DG-ID-A through the TDSC contract. If the authorization does not match, the TDSC contract retrieves the sharing list information from the SC-ID and compares it with DG-ID-B. If the information matches, it returns the AES-encrypted hash data corresponding to the SC-ID for decryption and sends a request to DG-ID-A through the TDSC contract.

[0009] Step 3: After receiving the request from DG-ID-B, DG-ID-A uses the private key SK. A The AES key is encrypted and sent to DG-ID-B. DG-ID-B decrypts the data using the DG-ID-A public key to obtain the AES key.

[0010] Step 4: DG-ID-B decrypts the data using the AES key to obtain the original data.

[0011] As a preferred option, the educational digital system it employs includes:

[0012] The university digital database serves as an authoritative node in the digital education alliance blockchain, participating in the alliance blockchain and enjoying services such as encryption, storage, retrieval, protection, sharing, and auditing of educational data.

[0013] The permission management library, also known as the permission chain, is used to control user operations through fine-grained permission management. Operations include verifying user permissions and adjusting user permissions.

[0014] The data management repository, or data chain, is used to store educational data in the form of courses and is subject to the operational control of the access management repository.

[0015] System services are used to provide smart contracts and interface calls to the system in the form of interfaces, and to provide communication for smart contract calls between the data chain and the permission chain respectively.

[0016] The data chain and the permission chain together realize the business logic of identity registration, encrypted storage of educational data, and protection and sharing of educational data in the consortium blockchain, and enhance the protection of the originality and authenticity of the data through regular queries.

[0017] As a preferred option, the smart contracts in the consortium blockchain include the Digital Identity and Access Control Contract (DIRCC), the Digital Identity and Access Management Contract (DIRMC), and the Digital Education Management Contract (DEMC).

[0018] As a preferred option, DIRCC is a global contract with identity and permission recording and verification functions. The contract records the identity identifier DG-ID, the corresponding public key PubKey, and the corresponding permission power information of all users in the consortium blockchain. When the DIRCC contract is created, the user's digital identity, public key, and permission level are recorded together, and the relevant contract is also created together.

[0019] As a preferred approach, DIRMC achieves internal autonomy of the education consortium's digital identity through ethnic voting, comprising the identity permission creation voting contract DIRCVC, the identity permission adjustment contract DIRAC, the identity permission reset contract DIRRC, and the identity permission verification contract DAC. The DIRCVC contract is used to add new members to the education consortium, and the DIRC contract creates voting requests for members with corresponding permissions and votes for them. The DIRAC contract is used to adjust the permissions of members, adjusting permissions for members based on the votes of members with corresponding permissions. The DIRRC contract is used to reset the public key of a member through ethnic voting when the consortium blockchain's private key is leaked. The DAC contract is used for data storage, data sharing, and data verification permission control; members can only pass the contract verification after reaching the corresponding permissions.

[0020] As a preferred option, DEMC is used to implement the business logic of storing, protecting, verifying, recovering, and sharing educational data; it includes the Educational Data Storage Contract EDSC and the Educational Data Sharing Contract TDSC; the EDSC contract is used for storing educational data information, including course number CS-ID, school number S-ID, creator's public key, course information, student grades, hash value, and creation time; the TDSC contract is used to store educational data sharing information, including course number CS-ID, school number S-ID, and sharing level SHATE (Sharinglevel), and a course can be shared with multiple members for access.

[0021] As a preferred option, when SHATE is -1, the data cannot be shared; when SHATE is 0, only members specified by the creator can obtain the data; when SHATE is 1, only members with level 1 permissions can obtain the data; when SHATE is 2, members with level 2 or higher permissions can access and obtain the data; when SHATE is 3, the data is completely open to the outside world, and all members can freely obtain it directly from the data chain.

[0022] By combining the permission chain and data chain in a dual-blockchain approach, this invention ensures the security of educational data while defining different management operations for different permissions, effectively improving data management capabilities and better protecting privacy. Furthermore, through technologies such as smart contracts and digital signatures, it achieves identity verification and the sharing of educational data. Compared with traditional blockchains, this invention demonstrates superior performance in terms of security and query speed, and its latency performance under different consensus algorithms is compared. This method features a detailed permission management mechanism, scalability, and immutability, meeting the refined permission management needs in the education field. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the sharing and acquisition of educational data in this embodiment;

[0024] Figure 2 This is a system architecture diagram from the embodiment;

[0025] Figure 3 This is a diagram of the smart contract architecture in the embodiment;

[0026] Figure 4(a) shows the relationship between the probability of successfully completing an attack segment and the block height difference h (h is 3) in the embodiment;

[0027] Figure 4(b) shows the relationship between the probability of successfully completing an attack segment and the block height difference h (h is 4) in the embodiment;

[0028] Figure 5 This is a schematic diagram comparing query speeds under different data volumes in the example.

[0029] Figure 6 This is a diagram illustrating the comparison of data query times under different user scenarios in the embodiment;

[0030] Figure 7 This is a schematic diagram comparing the latency of smart contract calls between POA and POW consensus in the embodiment. Detailed Implementation

[0031] To further understand the content of this invention, a detailed description of the invention will be provided in conjunction with the accompanying drawings and embodiments. It should be understood that the embodiments are merely illustrative and not limiting of the invention.

[0032] Example

[0033] like Figure 1 As shown, this embodiment provides a method for sharing educational data under dual blockchain protection, which includes the following steps:

[0034] Step 1: User DG-ID-A modifies the SHATE of the course to be shared through the TDSC contract; if the SHATE is level 0, DG-ID-B needs to be written into the sharing list corresponding to SC-ID in the contract.

[0035] Step 2: User DG-ID-B uses private key SK B The system signs the course identifier (SC-ID) and identity identifier (DG-ID) of the course to be shared and sends them to the smart contract. Upon receiving the request, the TDSC contract first calls the DIRCC contract to check the user's permissions, and returns the result to the TDSC contract. It then matches the permission level of DG-ID-B with the SHATE of the SC-ID. If the permissions match, the system returns the AES-encrypted key and its corresponding hash for the SC-ID and sends a request to DG-ID-A via the TDSC contract. If the permissions do not match, the TDSC contract retrieves the sharing list information from the SC-ID and compares it with DG-ID-B. If the information matches, it returns the AES-encrypted hash data corresponding to the SC-ID, decrypts it, and sends a request to DG-ID-A via the TDSC contract.

[0036] Step 3: After receiving the request from DG-ID-B, DG-ID-A uses the private key SK. A The AES key is encrypted and sent to DG-ID-B. DG-ID-B decrypts the data using the DG-ID-A public key to obtain the AES key.

[0037] Step 4: DG-ID-B decrypts the data using the AES key to obtain the original data.

[0038] Blockchain

[0039] Blockchain is a distributed, decentralized ledger that uses a block-chain data structure to store and verify data. It utilizes distributed node consensus algorithms to generate and update blocks, smart contracts to program and manipulate data, and economic incentives to ensure the participation of every node in blockchain activities. Taking Ethereum as an example, Ethereum can be divided into three layers: top-level applications, the core layer, and bottom-level services. Top-level applications mainly include smart contracts and API interfaces; the core layer consists of blocks and consensus algorithms; and bottom-level services include P2P networks and cryptographic algorithms. A block consists of a block header, a list of transactions, and uncle block headers. Currently, blockchains are divided into three types: public blockchains, private blockchains, and consortium blockchains. In public blockchains, all nodes are neutral and open, not controlled by any single blockchain participant; anyone with a computer can participate. Private blockchains are typically used internally by individuals or organizations, where data management is controlled by the individual or organization, which cannot effectively solve trust issues. Consortium blockchains, also known as permissioned blockchains, only allow members within the consortium to perform operations such as voting and record-keeping according to the rules established by the consortium. Nodes within a consortium need to be verified by other members before joining, and their credibility is generally high. Table 1 compares public, private, and consortium blockchains.

[0040] Table 1 Comparison of Public Blockchains, Private Blockchains, and Consortium Blockchains

[0041]

[0042] To address the inconsistency issue arising from decentralization, blockchain employs consensus protocols to ensure data consistency among nodes. Currently, the main consensus algorithms in the blockchain system include Proof-of-Work (PoW), Proof-of-Stake (PoS), and Proof-of-Authority (PoA). The PoW consensus algorithm requires all nodes to collectively solve a mathematical problem using their own computing power; the node that solves the problem fastest gains the right to package a block. The PoS consensus algorithm determines the node that packages a block based on the amount of cryptocurrency it holds; the node with the most cryptocurrency has the highest probability of obtaining the right to package a block. The PoA consensus algorithm uses an authoritative node to generate blocks. Although the PoW consensus algorithm has weaker decentralization and fairness among nodes, it is well-suited for consortium blockchains due to their effective verification mechanisms and reliable authoritative nodes.

[0043] Data protection mechanism

[0044] Asymmetric encryption is one of the foundations of data security in blockchain, consisting of a public key and a private key. The system calculates the private key using the SHA256 hash algorithm based on the input data, and then uses the Secp256k1 elliptic algorithm to decompose the private key into the public key; this process is irreversible. The generated private key must be carefully stored by the generator, as it is difficult to recover if lost; the generated public key needs to be broadcast to other users on the blockchain. Currently, asymmetric encryption is mainly used for data encryption and digital signatures. For data encryption, user A encrypts and sends information using user B's public key. After receiving the information, user B decrypts it using their own private key. For digital signatures, user A encrypts and sends information using their private key. After receiving the information, user B compares the hash of the message with user A's public key to decrypt the original message.

[0045] The Advanced Encryption Standard (AES) algorithm is a common symmetric encryption algorithm (this embodiment uses AES-256 for data encryption), employing the same key for both encryption and decryption. In the AES encryption process, the plaintext P and the key K are passed as parameters to the AES encryption function C = E(K, P) to generate ciphertext C. In the AES decryption process, the ciphertext C and the key K are passed as parameters to the AES decryption function P = D(K, C) to output the plaintext P.

[0046] Smart Contracts

[0047] A smart contract is a special type of program code deployed on a blockchain that can execute automatically. Well-known systems using this technology include Ethereum and Hyperledger. Smart contracts are characterized by their flexibility and strong tamper resistance. Once a smart contract is successfully invoked, its code and data are stored on the blockchain and cannot be modified. Therefore, before deploying a smart contract to the blockchain, it must undergo feasibility and security checks to eliminate any potential system vulnerabilities. Currently, smart contract development utilizes Solidity, a high-level language with syntax similar to JavaScript.

[0048] System Architecture

[0049] The dual-blockchain-based educational data sharing method proposed in this embodiment is completed collaboratively by four parts: a university digital database, a permission management database (permission chain), a data management database (data chain), and a system service. Figure 2The university digital database, as an authoritative node in the digital education consortium blockchain, participates in the consortium blockchain and enjoys services such as encryption, storage, querying, protection, sharing, and auditing of educational data. The permission management database controls user operations through granular permission management, primarily involving verifying and adjusting user permissions. Permissions (power) are divided into three levels: Level 1, Level 2, and Level 3, as shown in Table 2. Users must pass verification by the permission management database before accessing the education consortium blockchain. The system service is a decentralized application that does not store any educational data or identity information itself. It provides smart contracts and interface calls to the educational digital system in the form of interfaces. The system service also provides communication for the smart contract calls between the data chain and the permission chain. The data management database primarily stores educational data in the form of courses and is subject to the operational control of the permission management database. The data chain and permission chain jointly implement the business logic of identity registration, encrypted storage of educational data, and protection and sharing of educational data in the consortium blockchain, and enhance the protection of data originality and authenticity through periodic queries. Since this system primarily targets schools and educational institutions, a group characterized by authentic and credible identities and high authority, the Proof-of-Arrival (POA) consensus algorithm is highly suitable for this consortium. Furthermore, it eliminates the need for computational reward mechanisms to maintain system operation, significantly reducing methodological costs and energy consumption.

[0050] Table 2 Permission Description

[0051]

[0052] Contract Architecture

[0053] This method primarily leverages the consistency and immutability of smart contracts to enable flexible programming while maintaining the original security of the blockchain. The smart contract system of this method (such as...) Figure 3 (As shown) It consists of data chain contracts and permission chain contracts in a consortium blockchain. Deployed within the consortium blockchain, the contract content is stored within the blockchain's blocks. Smart contracts in the consortium blockchain include Digital Identity Rights Control Contract (DIRCC), Digital Identity Rights Management Contract (DIRMC), and Digital Education Management Contract (DEMC), among others.

[0054] DIRCC, as a global contract, has the function of recording and verifying identity and permissions. This contract records the identity identifier (DG-ID), corresponding public key (PubKey), and related permissions (power) of all users in the consortium blockchain. When the DIRCC contract is created, the user's digital identity, public key, and permission level are recorded together, and the relevant contract is also created at the same time.

[0055] DIRMC achieves internal autonomy of the education consortium's digital identity through ethnic voting, comprising the following contracts: Digital Identity Rights Create Voting Contract (DIRCVC), Digital Identity Rights Adjustment Contract (DIRAC), Digital Identity Rights Reset Contract (DIRRC), and Digital Authentication Contract (DAC). The DIRCVC contract is used for new members joining the education consortium; within the DIRVC contract, a member with permission level 1 creates a voting request and votes. The DIRAC contract adjusts member permissions through the vote of member with permission level 1. The DIRRC contract resets the public key through ethnic voting in the event of a private key leak in the consortium blockchain. The DAC contract controls access to data storage, sharing, and verification; members can only pass the contract's verification after reaching the corresponding permissions.

[0056] DEMC is used to implement business logic for storing, protecting, verifying, recovering, and sharing educational data. It includes the Education Data Storage Contract (EDSC) and the Education Data Sharing Contract (TDSC). The EDSC contract stores educational data information, including course ID (CS-ID), school ID (S-ID), creator's public key, course information, student grades, hash value, and creation time. The TDSC contract stores educational data sharing information, including course ID (CS-ID), school ID (S-ID), and sharing level (SHATE). A course's information can be shared with multiple members. The specific values ​​for SHATE are shown in Table 3: When SHATE is -1, the data cannot be shared. When SHATE is 0, only members specified by the creator can access the data. When SHATE is 1, only members with level 1 access can access the data. When SHATE is 2, all members with level 2 or higher access can access and obtain the data. When the value of SHATE is 3, it means that the data is completely open to the outside world, and all members can freely obtain it directly from the data chain.

[0057] Table 3 SHATE Classification

[0058]

[0059] Identity and Permission Registration and Reset

[0060] The ability of digital representatives within the education consortium to participate in the consortium blockchain is fundamental to activities such as data protection and sharing. Each member wishing to join the consortium needs the consent of more than half of the consortium members with Level 1 permissions to complete registration. The specific process is as follows:

[0061] 1. First, before joining the numerical consortium, you need to generate your own public and private key pair locally using the SHA256Hash algorithm and the Secp256k1 algorithm.<PK,SK> And keep your key SK safe.

[0062] 2. Next, contact a Level 1 member within the alliance through the correct channels, providing them with your PK public key and identity information. After receiving confirmation, authorize them to create the DIRCVC contract and participate in the voting. DIRCVC will display the member's information, allowing other voters to verify the situation.

[0063] 3. Finally, when the members with permission level 1 have completed their voting and the number of votes exceeds half, the DIRCC contract will save the member's public key information, generate the corresponding DG-ID and default permission level (level 3 permission), and create corresponding DIRCC and DEMC contracts for them. After waiting for the block confirmation to be completed, the identity registration of the Education Consortium will be completed.

[0064] Because the keys generated by the SHA256Hash elliptic curve algorithm are complex and difficult to remember, SK keys are prone to loss. Furthermore, if an internal member's SK key is illegally stolen by a hacker, they could be used to view, modify, and share educational data to identify that member. This significantly compromises the security of the consortium blockchain. Therefore, this embodiment designs a key reset scheme based on a voting mechanism. The specific scheme is as follows:

[0065] 1. First, you need to regenerate a new public-private key pair locally. <PK new SK new >, via a reliable channel, the new PK new Send information such as DG-ID to other members within the alliance and request a member with permission level 1 or higher to create an identity reset vote.

[0066] 2. Alliance members with permissions of 1 or higher will vote to reset the public key. When the number of votes exceeds half, the DIRCC contract will reset the member's public key.

[0067] This method fully considers the possibility of key loss and effectively solves the key reset problem through voting verification. It also decouples the public key from business logic through the identity identifier DG-ID. Since data query and sharing operations are based on the permissions corresponding to the member's identity identifier DG-ID, even if the public key corresponding to the DG-ID is reset, as long as the public key corresponding to the signature matches the DG-ID, access to the data can still be achieved through permission verification.

[0068] Identity and permission adjustment

[0069] The user's permission level was limited during identity registration (default permission level is 3), preventing users from properly using operations such as storing educational data in the DEMC contract. Therefore, this embodiment fully considers the issue of permission adjustment and uses a voting review mechanism to adjust user permissions. The specific solution is as follows:

[0070] 1. First, the user contacts other members within the alliance through a trusted channel, then creates a DIRAC contract, fills in information such as DG-ID, adjustment permissions, and application reasons, and waits for other members (permission level 1) to vote and review it.

[0071] 2. Other alliance members will vote on the user's permission adjustments based on their understanding. When more than half of the votes are received, DIRCC will reset the user's permissions.

[0072] The identity and permission adjustment mechanism was designed with full consideration of the possibility of a small number of malicious nodes within the alliance, which could be caused by hackers illegally stealing members' private keys. To prevent large-scale data leakage, this embodiment designs a permission downgrade scheme. This method differs from permission upgrade in that the contract initiator is different. The specific process is as follows:

[0073] 1) First, if member A discovers that member B is maliciously performing data storage, modification, and sharing operations within the alliance, member A can create a DIJPVP contract to vote on the reduction of permissions.

[0074] 2) Members with permission level 1 in the alliance shall verify the malicious member's behavior and participate in the voting.

[0075] 3) Finally, when the number of votes exceeds half, the DIRCC contract will downgrade the privilege level of the malicious member based on the malicious member's DG-ID and inform all members of the downgrade result.

[0076] Educational Data Protection

[0077] Educational data protection refers to storing educational data on the blockchain through smart contracts. This effectively prevents data from being illegally tampered with or destroyed, and provides data verification and recovery capabilities, thus achieving the goal of educational data protection. Creating a new course profile involves storing course information in the EDSC contract on the blockchain and generating a unique course identifier (SC-ID) and version number. Updating a course profile involves locating the course information based on the SC-ID and updating the course data and corresponding version number.

[0078] The process for creating a new course is as follows: First, a set of AES keys is randomly generated, and this key is jointly stored by the user and the school. The teaching information in the course is encrypted using the system service as keyInformation, and a hash value is generated from this data. data sha256 Then, the course ID (SC-ID) and the hash value of the data are... data sha256 Generate a JSON course object using information such as ), hashThe course data is then processed and signed. The signed course data invokes the EDSC contract. Upon receiving a request to create a new course file, the EDSC contract calls the DAC contract to recover the user's public key information from the signature and compares it with the key recorded in the DIRCC contract. If the identity and authorization check passes, the contract adds mappings to information such as the course number SC-ID, version number, and creation time. After a waiting period, the information in the course file is uploaded to the blockchain.

[0079] The course file update process is similar to the course creation process. The system locates the corresponding course file in the data chain based on the course identifier (SC-ID), decrypts the data in the file using the EDSC contract to obtain structured data in JSON format, generates a new JSON structure based on the updated data, and encrypts the data using the AES symmetric encryption algorithm. Finally, the EDSC contract is invoked for storage.

[0080] In the event of an error during course data storage, this embodiment provides corresponding recovery methods. After detecting the error, the data can be compared with the block information previously stored in the EDSC contract to locate the faulty block. The EDSC contract can then be invoked to recreate a new course in the data chain based on this data, with the version number changing accordingly.

[0081] Method Implementation

[0082] This embodiment proposes a research method for sharing educational data based on dual-blockchain protection, and tests the feasibility and security of smart contracts on Slither. Experiments were conducted on five physical servers. The server configurations are as follows: four E7-4820@2.0GHz *232 Logic Core processors and one E5-2640v3@2.60GHz *232 Logic Core processor; 16GB of memory; and VMware ESXi 6.7u3 operating system. These five servers are named Blockchain1, Blockchain2…Blockchain5, where Blockchain1, Blockchain2, and Blockchain3 store educational data; and Blockchain4 and Blockchain5 store permission data. All virtual nodes will act as alliance member nodes.

[0083] This system uses the MOOC dataset provided in the literature and the data provided by the Touge Practical Teaching Platform for system testing. The basic information of the datasets is shown in Table 4. The MOOC dataset includes attributes such as course (course name, course description, course ID, video ID, video name), school (school name, school description), teacher (teacher name, teacher description), user (user name, course order, registered practice), and video (video name, duration, start time, end time, text). The Touge Practical Teaching Platform dataset includes 31 attributes such as course ID, course name, number of chapters, number of practical training sessions, number of learners, chapter data (chapter name, description, included practical training sessions), unique identifier for practical training sessions, practical training name, and level data (level ID, name, task description, number of passers, number of participants currently in progress).

[0084] Table 4 Evaluation Dataset

[0085]

[0086] Operating cost analysis

[0087] Assuming the average number of data storage and maintenance operations per month in the system is α, the average number of data sharing operations is β, and the average number of identity verification and management operations is α + β + γ, where γ is the number of identity registration and permission adjustment operations per month, then the monthly cost of a smart contract deployed on the consortium blockchain is Cost. ethereum See formula (1).

[0088] Cost Ethereum =α×Cost save +β×Cost share +(α+β+γ)×Cost Power (1)

[0089] When the alliance is small, the γ value is small; as the alliance grows, the γ value gradually increases; when the alliance reaches a certain size, the γ value gradually decreases and then tends to stabilize.

[0090] When the consortium is small, frequent data queries are required (μ is the interval). As the scale of the consortium blockchain increases, the security and stability of the system improve, and the frequency of data query operations gradually decreases. The larger the value of the μ parameter, the lower the economic cost of the system.

[0091] Security Comparison Analysis

[0092] The primary threat addressed in this embodiment is the tampering of block data, which significantly compromises the security of the data chain. Assume the latest block is block α. An attacker attempting to tamper with the permission data in block β, preceding the latest block, would need to replace that block through a fork attack. The attacker would need to recalculate the hash values ​​of blocks α-β. Assume the computing power of honest nodes in the current consortium chain is p hashes per second, and the computing power of the nodes controlled by the attacker is q hashes per second. Without a large number of nodes joining or leaving, the computational difficulty of the new block will not change significantly. For ease of calculation, assume this situation does not currently exist. In this case, the probability of an honest node generating a new block per second is W, and the probability of an attacking node obtaining a new block is u. Let h represent the block height difference between honest nodes and attacking nodes. The height difference h per second has three possible outcomes: the height difference decreases, the height difference increases, and the height difference remains unchanged. At this point, the probability of the height difference decreasing is p1 = w(1-u), the probability of the height difference increasing is p2 = u(1-w), and the probability of the height difference remaining unchanged is p3 = 1-uw. Therefore, there will be t possible outcomes after t seconds, with each outcome occurring p1t, p2t, and p3t times respectively. If the attacker wants to succeed in the attack within t seconds, it needs to satisfy p1∈{0, [(th-1) / 2] / t}, p2 = (p1t+h+k) / t and 1≤k≤t-2tp1-h, p1+p2+p3 = 1. Within t seconds, the probability of the honest node being caught by the attacker conforms to formula (2).

[0093]

[0094] Formula (2) shows the relationship between the probability of an attacker successfully completing an attack and the block height difference h. The method of this embodiment was modified to a single-chain + permission management mode and compared with the method of this embodiment under the same computing power (the computing power of the attacking node is 50% of that of the honest node), as shown in Figures 4(a) and 4(b). The horizontal axis is time t (unit: the average time to discover a block on Ethereum), and the vertical axis is the probability p of the attacker obtaining a new block.

[0095] As shown above, the probability of an attacker successfully tampering with the block data decreases as the block height difference h increases. When the block height difference is 3, the attacker's success probability is less than 0.5%; when the block height difference is 4, the attacker's success probability is less than 0.4%. When tampering with data, the attacker will pre-calculate the hash values ​​of several blocks; therefore, the success rate of tampering will first increase and then decrease, gradually approaching 0. Since this embodiment is based on dual-blockchain protection, the difficulty for an attacking node to generate blocks is higher than in the single-chain + permission management mode. Therefore, the probability of an attacking node obtaining a new block in this embodiment is much lower than the probability in the single-chain + permission management mode. In practical application scenarios, it is difficult for an attacking node to reach 50% of the computing power of an honest node. Therefore, the probability of an attacking node successfully tampering with data is much less than 0.5%.

[0096] Performance Comparison

[0097] Because blockchain query speed is often criticized, and the speed of educational data sharing is primarily affected by block query speed, this embodiment conducted a grouped experiment to compare the query speed between dual-blockchain and single-blockchain systems. This embodiment set up six incrementally increasing groups of experiments according to the principle of equal quantity, such as... Figure 5 The single-chain permission management method, the single-chain permissionless method, and the dual-blockchain method of this embodiment were tested respectively. Since the three methods produce different numbers of blocks with the same amount of data, this embodiment uses the amount of data as the grouping criterion and the average time taken to query the same data as the experimental result. Furthermore, since both the method of this embodiment and the single-chain permission management method are affected by the number of recorded user permissions, we assume there are 500 users.

[0098] Depend on Figure 5 It can be seen that when the number of users remains constant, the query time increases linearly with the increase of query data. Initially, the method in this embodiment is about 3 seconds slower than the single-chain method without permission management, but it is better than the single-chain method with permission management. As the amount of data queried increases, with the number of users remaining constant, the method in this embodiment will gradually approach the single-chain method without permissions. This is because, with the number of users remaining constant, the impact of the number of users on the dual blockchain gradually decreases. It is clear from the two datasets in this embodiment that in real-world application scenarios, the number of recorded information is far greater than the number of users. Therefore, the amount of educational data has a significant impact on the query speed of the dual blockchain.

[0099] Since both the method in this embodiment and the single-chain permission management method are affected by the number of user permissions recorded, this embodiment conducted a comparative experiment for different amounts of permission data. This embodiment assumes that 10,000 data entries were stored in the experiment, and the experimental results are as follows. Figure 6As the number of users increases, the method in this embodiment becomes increasingly superior to the single-chain plus permission management method. The main reason is that the single-chain plus permission management method stores user permissions and educational data on a single chain, and users need to query the blockchain twice when sharing data. Therefore, the number of blocks queried by the single-chain plus permission management method is far greater than the number of blocks queried by the method in this embodiment, resulting in a much slower query speed under the single-chain weighted management method compared to the method in this embodiment.

[0100] Consensus Algorithm Comparison

[0101] Currently, blockchain systems primarily use Proof-of-Work (PoW) and Proof-of-Availability (PoA) as mainstream consensus algorithms. To test the response speed of smart contracts under different consensus algorithms, consortium blockchains based on PoA and PoW consensus algorithms were built and evaluated using the Aleth testing tool. The experimental data comparison results are shown in Figure 7. The tests were specifically divided into five parts.

[0102] A: Deploying smart contracts

[0103] B: Identity and Access Registration

[0104] C: Adjustment of identity and permissions

[0105] D: Data storage

[0106] E: Data Sharing

[0107] Depend on Figure 7 It is evident that the characteristics of the POA consensus algorithm dictate that transaction verification is conducted within a limited number of designated validators, while the number of nodes in the POW consensus algorithm continuously increases, resulting in a longer waiting time for information broadcast to all validator nodes and consequently, longer latency for smart contracts. Therefore, POA consortium blockchains have lower latency than POW consortium blockchains. Furthermore, in processing on-chain transactions, the consensus characteristics of the POA algorithm ensure its processing speed is significantly faster than that of the POW algorithm. Regarding E-part data sharing, the latency of a POA consortium blockchain is almost equal to that of a POW consortium blockchain. This is because this part considers the corresponding access level for querying corresponding sharing levels. This part only reads and compares data stored on the consortium blockchain, without altering the data stored on the blockchain, and does not require creating on-chain transactions or transaction broadcasting. Therefore, it is not directly related to whether the POW or POA consensus algorithm is used.

[0108] The key contributions of this embodiment are as follows:

[0109] a) A dual-blockchain-based access control mechanism is proposed to address various access management issues arising from the need for refined data management.

[0110] b. A dual-blockchain access control mechanism and data sharing method were proposed. This ensures that students' privacy is fully protected when schools share data with enterprises.

[0111] c. By comparing dual-blockchain and single-blockchain, the performance advantages of dual-blockchain were analyzed.

[0112] The present invention and its embodiments have been described above illustratively. This description is not restrictive, and the figures shown are only one embodiment of the present invention; the actual structure is not limited thereto. Therefore, if those skilled in the art are inspired by this description and design similar structures and embodiments without departing from the spirit of the present invention, such designs should fall within the protection scope of the present invention.

Claims

1. A method for sharing educational data under dual blockchain protection, characterized in that: Includes the following steps: Step 1: User DG-ID-A modifies the sharing level SHATE of their course to be shared through the Education Data Sharing Contract (TDSC). If SHATE is level 0, DG-ID-B needs to be written into the sharing list corresponding to the course identifier SC-ID in the contract; Step 2: User DG-ID-B uses private key SK B The system signs the course identifier (SC-ID) and identity identifier (DG-ID) of the course to be shared and sends them to the smart contract. Upon receiving the request, the TDSC contract first calls the Digital Identity and Access Control (DIRCC) contract to check the identity and permissions, returning the result to the TDSC contract. The system then matches the permission level of DG-ID-B with the SHATE of the SC-ID. If the permissions match, the system returns the AES-encrypted key and corresponding hash of the SC-ID and sends a request to DG-ID-A via the TDSC contract. If the permissions do not match, the TDSC contract retrieves the sharing list information from the SC-ID and compares it with DG-ID-B. If the information matches, the system returns the AES-encrypted hash data corresponding to the SC-ID for decryption and sends a request to DG-ID-A via the TDSC contract. DIRCC is a global contract with identity and permission recording and verification functions. The contract records the identity identifier (DG-ID), corresponding public key (PubKey), and related permission power information of all users in the consortium blockchain. When the DIRCC contract is created, the user's digital identity, public key, and permission level are recorded together, and the relevant contract is also created at the same time. Step 3: After receiving the request from DG-ID-B, DG-ID-A uses the private key SK. A The AES key is encrypted and sent to DG-ID-B. DG-ID-B decrypts the data using the DG-ID-A public key to obtain the AES key. Step 4: DG-ID-B decrypts the data using the AES key to obtain the original data.

2. The method for sharing educational data under dual blockchain protection as described in claim 1, characterized in that: Its educational digital systems include: The university digital database serves as an authoritative node in the digital education alliance blockchain, participating in the alliance blockchain and enjoying services such as encryption, storage, retrieval, protection, sharing, and auditing of educational data. The permission management library, also known as the permission chain, is used to control user operations through fine-grained permission management. Operations include verifying user permissions and adjusting user permissions. The data management repository, or data chain, is used to store educational data in the form of courses and is subject to the operational control of the access management repository. System services are used to provide smart contracts and interface calls to the system in the form of interfaces, and to provide communication for smart contract calls between the data chain and the permission chain respectively. The data chain and the permission chain together realize the business logic of identity registration, encrypted storage of educational data, and protection and sharing of educational data in the consortium blockchain, and enhance the protection of the originality and authenticity of the data through regular queries.

3. The method for sharing educational data under dual blockchain protection as described in claim 2, characterized in that: The smart contracts in the consortium blockchain include the Digital Identity and Access Control Contract (DIRCC), the Digital Identity and Access Management Contract (DIRMC), and the Digital Education Management Contract (DEMC).

4. The method for sharing educational data under dual blockchain protection as described in claim 3, characterized in that: DIRMC achieves internal autonomy of digital identity within the Education Consortium through ethnic voting, including the identity permission creation voting contract DIRCVC, the identity permission adjustment contract DIRAC, the identity permission reset contract DIRRC, and the identity permission verification contract DAC. The DIRCVC contract is used to create voting requests for new members joining the Education Consortium, and the DIRMC contract creates voting requests for members with corresponding permissions and votes for them. The DIRAC contract is used to adjust the permissions of members, and the permissions of members are adjusted through voting by the members with the corresponding permissions; the DIRRC contract is used to reset the public key through ethnic voting when the private key of the consortium blockchain is leaked; the DAC contract is used for data storage, data sharing and data verification permission control, and members can only pass the contract verification when they have reached the corresponding permissions.

5. The method for sharing educational data under dual blockchain protection as described in claim 3, characterized in that: DEMC is used to implement the business logic of storing, protecting, verifying, recovering, and sharing educational data; it includes the Educational Data Storage Contract EDSC and the Educational Data Sharing Contract TDSC; the EDSC contract is used for storing educational data information, including course number CS-ID, school number S-ID, creator's public key, course information, student grades, hash value, and creation time; the TDSC contract is used to store educational data sharing information, including course number CS-ID, school number S-ID, and sharing level SHATE, and a course can be shared with multiple members for access.

6. The method for sharing educational data under dual blockchain protection as described in claim 5, characterized in that: When SHATE is -1, the data cannot be shared; when SHATE is 0, only members specified by the creator can access the data; when SHATE is 1, only members with level 1 privileges can access the data; when SHATE is 2, all members with level 2 or higher privileges can access and obtain the data; when SHATE is 3, the data is completely open to the outside world, and all members can freely obtain it directly from the data chain.

Images