A data consistency synchronization method for an education private blockchain

Abstract

The application discloses a data consistency synchronization method for an education private block chain, and first, a genesis node initializes the whole block chain, then a new node joins the block chain and also performs initialization work, and then non-genesis nodes complete chain entry work, and meanwhile, node data changes are recorded, and finally, the block chain periodically performs full-chain data synchronization to complete data consistency synchronization of the block chain. The method does not need to introduce a centralized server, homologous information tables are introduced in the Meta area of different nodes, and data change record tables are saved in the Data area, difference data positions are quickly located, consistency synchronization of homologous data entities is realized, existing centralized data synchronization problems are overcome, data synchronization of different data nodes is efficiently realized, and the homologous entities and field names do not need to be completely same, the data consistency synchronization problem of the education private block chain is effectively solved, the quality of education data is improved, and the efficiency of education data cleaning and management is improved.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, specifically relating to a data consistency synchronization method for private blockchains in education. Background Technology

[0002] With the development of information technology in my country, data analysis and processing in the education sector have received increasing attention. In recent years, distributed computing technology, brought about by the development of blockchain technology, has also been widely applied in the education industry. Many provinces, cities, and localities have established private blockchain structures with multiple levels, including provincial, municipal, district, and school levels, where various education-related data are stored and retrieved in a distributed manner at each level of nodes. Such a structure can efficiently process increasingly large amounts of information and data, but it also brings the risk of data inconsistency.

[0003] Ensuring data consistency is a critical issue facing blockchain technology and a problem that must be addressed in my country's multi-level distributed storage for educational informatization. For example, the same student's basic information might be stored simultaneously in provincial, municipal, district / county, and school database nodes. These databases are deployed on different servers with different geographical locations and operating environments. Modifications to this student's information on any node will cause data inconsistencies. Over time, these inconsistencies will accumulate, inevitably leading to difficulties in educational informatization management and a significant decline in data quality. Therefore, a method is needed to achieve data synchronization across different blockchain nodes.

[0004] Currently, the mainstream strategy for synchronizing educational database nodes at different levels is "one source of data," meaning that the primary source of data must be determined first, and this source must be unique. Modifications to the data must be made on this data source. After modification, the changed data is broadcast to other database nodes based on event-driven or timed synchronization methods, thus achieving end-to-end data consistency synchronization. If the sole data source for student information is determined to be the "city-level database," then the provincial, district / county, and school database nodes all rely on the city-level database, and these nodes cannot independently modify or maintain student data information.

[0005] The drawback of this method is that it requires a unique data source, a typical "centralized" strategy that contradicts the decentralized principles of blockchain. This results in non-data source nodes being unable to actively modify data (even if they do, the data source will overwrite the changes, rendering them invalid). Furthermore, this method must ensure that the data structure of the data source and the synchronization database are completely consistent; otherwise, it may cause data synchronization anomalies. However, in reality, different levels often have different storage structures for the same data. For example, for the same student data, the school-level database node stores 10 fields, while the city-level database node stores 15 fields. There is overlap between the two, rather than a simple inclusion relationship. Summary of the Invention

[0006] To address the aforementioned technical issues, this invention proposes a data consistency synchronization method for private educational blockchains. This method eliminates the need to define a standard data source and instead utilizes the peer-to-peer blockchain concept to achieve a fast, efficient, secure, and reliable data consistency synchronization method. This improves the quality of educational data and enhances the efficiency of educational data cleaning and governance.

[0007] The technical solution adopted in this invention is: a data consistency synchronization method for private blockchains in education, the specific steps of which are as follows:

[0008] S1. Initialize the genesis node and create the blockchain;

[0009] S2. The new node joins the blockchain and initializes;

[0010] S3. For non-genesis nodes, complete the chain entry process;

[0011] S4. Record changes in node data;

[0012] S5. The blockchain periodically performs full-chain data synchronization to achieve data consistency synchronization.

[0013] Furthermore, step S1 is specifically as follows:

[0014] The genesis node stores its own data and initializes the global parameter information of the entire blockchain, including the blockchain name, blockchain data synchronization cycle and other relevant information, and stores this information in the Meta area.

[0015] Furthermore, in step S2, before a new node joins the blockchain, the initialization process is as follows:

[0016] Store all data values ​​in the Data area, write all entity names and their aliases in the Meta area, and save the fields of each entity and their aliases.

[0017] Furthermore, in step S3, non-genesis nodes need to complete the chain entry process, as follows:

[0018] S31, Broadcast;

[0019] The data entity name (including aliases) and field name (including aliases) of the newly added node in the Meta area are broadcast to all other nodes on the chain in a fixed data format, using JSON or XML format.

[0020] S32. On-chain nodes update the same-origin information table in the Meta area;

[0021] After receiving the new node's Meta broadcast information, other nodes on the chain parse the new node's entity and field information, compare it with their own Meta information, find the same-origin entities and consistency fields based on aliases, and save them to their own same-origin information table in JSON or XML format.

[0022] After an on-chain node updates its same-origin information table, it sends the updated table back to the new node over the network.

[0023] S33, New node updates Meta zone;

[0024] New nodes sequentially receive source information tables from on-chain nodes, merge these source information tables into their own source information table file, and save it to the Meta area. At this point, all nodes on the blockchain (including new nodes) have saved data entities and consistency field information that are from the same source as themselves, and the new node has completed the onboarding process.

[0025] Furthermore, step S4 is specifically as follows:

[0026] When node data changes, it does not immediately send change notifications to nodes of the same origin. Instead, it records the data change information and performs full-chain data synchronization periodically (such as daily, weekly, or monthly).

[0027] All data of any node on the chain is stored in the Data area. When any data in the Data area changes, the node saves its data change information to the "Data Change Record Table" file, which is stored in the Data area.

[0028] Furthermore, in step S5, the blockchain periodically performs full-chain data synchronization, with the synchronization signal initiated by the genesis node, as follows:

[0029] S51, The genesis node triggers a data synchronization signal and broadcasts it to all nodes in the chain;

[0030] S52. When a node on the chain receives a data synchronization signal, it checks its own data change information table.

[0031] If there are no data changes that need to be synchronized, the system responds to the genesis node with a message indicating no data changes; otherwise, it responds to the genesis node with a message indicating that data changes have occurred and a data synchronization operation will be performed. The genesis node also needs to perform this step.

[0032] S53, Genesis Node records the names of all nodes on the chain that require data synchronization.

[0033] S54. If the current node is in a busy state (e.g., performing data operations), a certain period of time (generally no more than 5 seconds) is given for synchronization to wait for the current data operation transaction. If the data transaction is completed and the latest data change information is written to the data change table within the delay period, the data synchronization process will proceed normally. If the data transaction is not completed within the delay period, the current transaction will be forcibly stopped, rolled back to the state before the transaction operation, and then the data synchronization process will proceed normally.

[0034] S55, node locking;

[0035] The node database is exclusively locked, meaning it rejects all non-data synchronization transactions and is only open to data synchronization operations.

[0036] S56. Extract all source node information from the source information table, and send data synchronization signals to the source nodes in sequence to perform handshake operations.

[0037] A handshake allows both parties to reach an agreement on synchronization operations; let the current node be A and the source node be B. A normal handshake means that A can send data synchronization information to B normally.

[0038] S57. A retrieves the data change record table from the Data area and sends it to node B via the network;

[0039] S58 and B nodes receive data change records from A, compare them with their own source information tables, and perform data synchronization modification operations based on the comparison results.

[0040] Each change record contains a unique entity alias. Node B retrieves the local data entity and field information corresponding to these change records from its own source information table. Then, based on the data change operation type, it performs the same operation on the changed value in its own local database, thereby achieving data synchronization.

[0041] S59. Operation after synchronization;

[0042] After synchronization is complete, node B will continue to wait for synchronization operations from other nodes, while node A will continue to initiate synchronization requests to the next same-source node and complete the data synchronization operation until all same-source nodes have completed synchronization. At this point, the following two operations need to be performed:

[0043] (1) A clears its own data change information table;

[0044] (2) Send a data synchronization completion signal to the generative node. If A is the generative node, it also needs to send a synchronization completion signal to itself.

[0045] S510, the genesis node receives synchronization completion signals from each node until the synchronization operation of all nodes has been completed.

[0046] S511. The genesis node broadcasts to all nodes that the data synchronization is complete. After receiving the broadcast signal, the nodes unlock the database and continue to perform normal database operations. Then the blockchain data synchronization operation is complete.

[0047] The beneficial effects of this invention are as follows: In the method of this invention, the genesis node first initializes the entire blockchain, then new nodes join the blockchain and also undergo initialization. Next, non-genesis nodes complete the onboarding process while recording node data changes. Finally, the blockchain periodically performs full-chain data synchronization to achieve data consistency synchronization. This method does not require a centralized server. By introducing a common-source information table in the Meta area of ​​different nodes and storing a data change record table in the Data area, it quickly locates the position of differing data, achieving consistent synchronization of common-source data entities. This overcomes the centralized problem of existing data synchronization, efficiently achieving data synchronization between different data nodes without requiring identical common-source entities and field names. It effectively solves the data consistency synchronization problem for private educational blockchains, improves the quality of educational data, and enhances the efficiency of educational data cleaning and governance. Attached Figure Description

[0048] Figure 1 This is a flowchart of a data consistency synchronization method for private blockchains in education, according to the present invention.

[0049] Figure 2 This is a typical JSON format example diagram in an embodiment of the present invention.

[0050] Figure 3 This is a typical XML format diagram in an embodiment of the present invention.

[0051] Figure 4 This is an example diagram illustrating the representation of homologous information in an embodiment of the present invention.

[0052] Figure 5 This is a diagram of the "Data Change Record Table" file format in an embodiment of the present invention.

[0053] Figure 6 This is a flowchart of the handshake operation in an embodiment of the present invention.

[0054] Figure 7 This is a flowchart of the data synchronization and modification operation in an embodiment of the present invention. Detailed Implementation

[0055] To facilitate understanding of the content of this invention, the following terms will first be explained:

[0056] Educational hierarchical architecture: A multi-level management architecture that conforms to the characteristics of my country's education sector. The hierarchical architecture may vary slightly between different provinces, cities, and regions where institutions are located. This hierarchical architecture dictates that education sector data exhibits distributed storage characteristics.

[0057] Educational Private Blockchain: A collection of private blockchain structures and related technologies based on blockchain technology and geared towards my country's education sector. It consists of linked data nodes corresponding to different educational levels, including a distributed data storage architecture, data management, and application systems built upon it. It's important to note that blockchain is a decentralized, peer-to-peer structure. Therefore, on this blockchain, the "hierarchical" architecture of education management will be chained together equally. For example, provincial and municipal nodes are considered two equal nodes on the same data chain. The "superior-subordinate" relationship is only considered to have an administrative management relationship in terms of business operations, not a data management relationship.

[0058] Data entities and homologous data entities: A data entity, or simply an entity, is a collection of a certain type of objective thing. In a database, it often corresponds to a data table, which contains several fields describing that thing and stores multiple instance records of that thing. For example, a student information table includes fields such as student ID, name, and gender, and stores multiple student information records in the form of rows according to these field information. This invention uses E(f1,f2,…,f n ) represents the entity, E represents the entity name, f k Let F(E) represent the k-th field. F(E) represents the set of all fields of entity E.

[0059] In a distributed blockchain structure, the same entity may exist in different block nodes. These data entities describing the same thing are called "same-origin data entities," or simply same-origin entities. This invention does not require same-origin entities to have completely identical sets of fields. If entities E1 and E2 are two same-origin entities, then F(E1)∩F(E2) is the consistency field of E1 and E2, F(E1)-F(E2) is a field unique to E1, and F(E2)-F(E1) is a field unique to E2.

[0060] It's important to note that "same-origin entity" and "consistent field" are business concepts, not requirements that they must have the same name. For example, two same-origin entities used to store student information: E1 is named "student," while E2 is named "t_stu." The field describing the name in E1 is called "name," while the field describing the name in E2 is called "stu_name," etc., as long as they essentially describe the same data information. To accurately identify same-origin entities and their consistent fields, an "alias" mechanism can be introduced for entity names and field names. The method involved in this invention uses aliases as the basis for determining whether they are same-origin, which has the advantage of not affecting the original structure and function of the data entities.

[0061] Data consistency: All records in the same source entity located on different nodes of the blockchain must ensure that the values ​​in the consistent data fields are equal. In a blockchain structure, there is no longer a data center or a single data source; each data node can organize and maintain its own data. Any modification to data by any node will trigger changes to the data of other source entities, and multiple modifications will be based on the final state.

[0062] The basic structure of a blockchain node: Each node in the blockchain includes a Meta area and a Data area, which are used to store the specific data values ​​that describe the data information.

[0063] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0064] like Figure 1 The flowchart of a data consistency synchronization method for educational private blockchains according to the present invention is shown below, and the specific steps are as follows:

[0065] S1. Initialize the genesis node and create the blockchain;

[0066] S2. The new node joins the blockchain and initializes;

[0067] S3. For non-genesis nodes, complete the chain entry process;

[0068] S4. Record changes in node data;

[0069] S5. The blockchain periodically performs full-chain data synchronization to achieve data consistency synchronization.

[0070] In this embodiment, step S1 is specifically as follows:

[0071] The first node in a blockchain is called the "genesis node". In addition to storing its own data, this node also needs to initialize the global parameter information of the entire blockchain, including the blockchain name, the blockchain data synchronization cycle and other relevant information, and store this information in the Meta area.

[0072] In this embodiment, in step S2, before a new node is added to the blockchain, the initialization process is as follows:

[0073] Store all data values ​​in the Data area, write all entity names and their aliases in the Meta area, and save the fields of each entity and their aliases.

[0074] In this embodiment, in step S3, non-genesis nodes need to complete the chain entry process, as follows:

[0075] S31, Broadcast;

[0076] The data entity name (including aliases) and field name (including aliases) of the newly added node in the Meta area are broadcast to all other nodes on the chain in a fixed data format, using JSON or XML format.

[0077] A typical JSON format example is as follows Figure 2 As shown, a typical XML format is as follows: Figure 3 As shown. The JSON and XML above are equivalent, representing different formats of meta information for the same entity. In practical use, they can be extended or modified according to different scenarios and business needs. Subsequent examples in this embodiment will all be described using only JSON format.

[0078] S32. On-chain nodes update the same-origin information table in the Meta area;

[0079] The "Same Origin Information Table" is an information file stored in the Meta area of ​​a node. It stores the entities on the entire blockchain that are of the same origin as itself and their consistency field information. Its content is initialized to empty.

[0080] After receiving the new node's Meta broadcast message, other nodes on the chain parse it to obtain the new node's entity and field information. They compare this information with their own Meta information, find the same-origin entities and consistency fields based on aliases, and save them to their own same-origin information table in JSON or XML format. (Example follows) Figure 4 As shown.

[0081] After an on-chain node updates its same-origin information table, it sends the updated table back to the new node over the network.

[0082] S33, New node updates Meta zone;

[0083] New nodes sequentially receive source information tables from on-chain nodes, merge these source information tables into their own source information table file, and save it to the Meta area. At this point, all nodes on the blockchain (including new nodes) have saved data entities and consistency field information that are from the same source as themselves, and the new node has completed the onboarding process.

[0084] In this embodiment, step S4 is specifically as follows:

[0085] To avoid broadcast storms caused by frequent data changes, when node data changes, it does not immediately send change notifications to nodes of the same origin. Instead, it records the data change information and performs full-chain data synchronization periodically (such as daily, weekly, or monthly).

[0086] All data of any node on the chain is stored in the Data area. When any data in the Data area changes, the node saves its data change information to the "Data Change Record Table" file, which is stored in the Data area and has the following format: Figure 5 As shown.

[0087] In this embodiment, in step S5, the blockchain periodically performs full-chain data synchronization. The synchronization signal is initiated by the genesis node, as follows:

[0088] S51, The genesis node triggers a data synchronization signal and broadcasts it to all nodes in the chain;

[0089] S52. When a node on the chain receives a data synchronization signal, it checks its own data change information table.

[0090] If there are no data changes that need to be synchronized, the system responds to the genesis node with a message indicating no data changes; otherwise, it responds to the genesis node with a message indicating that data changes have occurred and a data synchronization operation will be performed. The genesis node also needs to perform this step.

[0091] S53, Genesis Node records the names of all nodes on the chain that require data synchronization.

[0092] S54. If the current node is in a busy state (e.g., performing data operations), a certain period of time (generally no more than 5 seconds) is given for synchronization to wait for the current data operation transaction. If the data transaction is completed and the latest data change information is written to the data change table within the delay period, the data synchronization process will proceed normally. If the data transaction is not completed within the delay period, the current transaction will be forcibly stopped, rolled back to the state before the transaction operation, and then the data synchronization process will proceed normally.

[0093] S55, node locking;

[0094] The node database is exclusively locked, meaning it rejects all non-data synchronization transactions and is only open to data synchronization operations.

[0095] S56. Extract all source node information from the source information table, and send data synchronization signals to the source nodes in sequence to perform handshake operations.

[0096] The purpose of the handshake is to allow both nodes to reach an agreement on synchronization operations. Let the current node be A and the same-source node be B. The handshake process is as follows: Figure 6 As shown, a normal handshake completion means that A can send data synchronization information to B normally.

[0097] S57. A retrieves the data change record table from the Data area and sends it to node B via the network;

[0098] S58 and B nodes receive data change records from A, compare them with their own source information tables, and perform data synchronization and modification operations based on the comparison results. The specific process is as follows: Figure 7 As shown;

[0099] Since each change record contains a unique entity alias, node B can query the local data entity and field information corresponding to these change records from its own source information table. Then, based on the data change operation type, it performs the same operation on the changed value in its own local database, thereby achieving data synchronization.

[0100] S59. Operation after synchronization;

[0101] After synchronization is complete, node B will continue to wait for synchronization operations from other nodes, while node A will continue to initiate synchronization requests to the next same-source node and complete the data synchronization operation until all same-source nodes have completed synchronization. At this point, the following two operations need to be performed:

[0102] (1) A clears its own data change information table;

[0103] (2) Send a data synchronization completion signal to the generative node. If A is the generative node, it also needs to send a synchronization completion signal to itself.

[0104] S510, the genesis node receives synchronization completion signals from each node until the synchronization operation of all nodes has been completed.

[0105] S511. The genesis node broadcasts to all nodes that the data synchronization is complete. After receiving the broadcast signal, the nodes unlock the database and continue to perform normal database operations. Then the blockchain data synchronization operation is complete.

[0106] In summary, the method of this invention does not require the introduction of a centralized server. By introducing a source information table in the Meta area of ​​different nodes and storing a data change record table in the Data area, it can quickly locate the location of differing data and achieve consistent synchronization of source data entities. This overcomes the centralized problem of existing data synchronization, efficiently realizes data synchronization of different data nodes, and does not require source entities and field names to be exactly the same. It effectively solves the data consistency synchronization problem for private blockchains in education, improves the quality of educational data, and enhances the efficiency of educational data cleaning and governance.

[0107] Those skilled in the art will recognize that the embodiments described herein are intended to help the reader understand the principles of the invention, and should be understood that the scope of protection of the invention is not limited to such specific statements and embodiments. Various modifications and variations can be made to the invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the scope of the claims of the invention.

Claims

1. A data consistency synchronization method for private blockchains in education, comprising the following steps: S1. Initialize the genesis node and create the blockchain; S2. The new node joins the blockchain and initializes; S3. For non-genesis nodes, complete the chain entry process; In step S3, non-genesis nodes need to complete the chain entry process, as follows: S31, Broadcast; The data entity name and field name in the Meta area of ​​the newly added node are broadcast to all other nodes on the chain in a fixed data format, using JSON or XML format. S32. On-chain nodes update the same-origin information table in the Meta area; After receiving the new node's Meta broadcast information, other nodes on the chain parse the new node's entity information and field information, compare it with their own Meta information, find the same-origin entity and consistency field based on the alias, and save it to their own same-origin information table in JSON or XML format. After an on-chain node updates its same-origin information table, it sends the same-origin information table back to the new node via the network. S33, New node updates Meta zone; New nodes receive the same-origin information tables from the on-chain nodes in turn, merge these same-origin information tables into their own same-origin information table file, and save it to the Meta area; at this point, all nodes on the blockchain have saved data entities and consistency field information that are of the same origin as themselves, and the new node completes the on-chain process. S4. Record changes in node data; S5. The blockchain periodically performs full-chain data synchronization to achieve data consistency synchronization. In step S5, the blockchain periodically performs full-chain data synchronization. The synchronization signal is initiated by the genesis node, as follows: S51, The genesis node triggers a data synchronization signal and broadcasts it to all nodes in the chain; S52. When a node on the chain receives a data synchronization signal, it checks its own data change information table. If there are no data changes that need to be synchronized, respond to the genesis node with a message indicating no data changes; otherwise, respond to the genesis node with a message indicating that there are data changes and a data synchronization operation will be performed; the genesis node also needs to perform this step. S53, Genesis Node records the names of all nodes on the chain that require data synchronization. S54. If the current node is in a busy state, a certain period of delay is given for synchronization to wait for the current data operation transaction. If the data transaction is completed within the delay period and the latest data change information is written to the data change table, the data synchronization process will proceed normally. If the data transaction has not been completed within the delay period, the current transaction will be forcibly stopped, rolled back to the state before the transaction operation, and then the data synchronization process will proceed normally. S55, node locking; The node database is exclusively locked, meaning it rejects all non-data synchronization transactions and is only open to data synchronization operations. S56. Extract all source node information from the source information table, and send data synchronization signals to the source nodes in sequence to perform handshake operations. A handshake allows both parties to reach an agreement on synchronization operations. If the current node is A and the same source node is B, a normal handshake means that A can send data synchronization information to B normally. S57. A retrieves the data change record table from the Data area and sends it to node B via the network; S58 and B nodes receive data change records from A, compare them with their own source information tables, and perform data synchronization modification operations based on the comparison results. Each change record contains a unique entity alias. Node B retrieves the local data entity and field information corresponding to these change records from its own source information table. Then, based on the data change operation type, it performs the same operation on the changed value in its own local database, thereby achieving data synchronization. S59. Operation after synchronization; After synchronization is complete, node B will continue to wait for synchronization operations from other nodes, while node A will continue to initiate synchronization requests to the next same-source node and complete the data synchronization operation until all same-source nodes have completed synchronization. At this point, the following two operations need to be performed: (1) A clears its own data change information table; (2) Send a data synchronization completion signal to the generative node. If A is the generative node, it also needs to send a synchronization completion signal to itself. S510, the genesis node receives synchronization completion signals from each node until the synchronization operation of all nodes has been completed; S511. The genesis node broadcasts to all nodes that the data synchronization is complete. After receiving the broadcast signal, the nodes unlock the database and continue to perform normal database operations. Then the blockchain data synchronization operation is complete.

2. The data consistency synchronization method for educational private blockchains according to claim 1, characterized in that, The specific steps of S1 are as follows: The genesis node stores its own data and initializes the global parameter information of the entire blockchain, including the blockchain name, blockchain data synchronization cycle and other relevant information, and stores this information in the Meta area.

3. The data consistency synchronization method for educational private blockchains according to claim 1, characterized in that, In step S2, before a new node joins the blockchain, the initialization process is as follows: Store all data values ​​in the Data area, write all entity names and their aliases in the Meta area, and save the fields of each entity and their aliases.

4. The data consistency synchronization method for educational private blockchains according to claim 1, characterized in that, Step S4 is as follows: When node data changes, it does not immediately send change notifications to nodes of the same origin. Instead, it records the data change information and performs full-chain data synchronization periodically. All data of any node on the chain is stored in the Data area. When any data in the Data area changes, the node saves its data change information to the "Data Change Record Table" file, which is stored in the Data area.

Images