A method and system for secure sharing of government data based on blockchain technology

Abstract

This application relates to the field of data sharing security technology, and in particular to a method and system for secure sharing of government data based on blockchain technology. The method includes: acquiring user business processing information; analyzing user business needs based on the user business processing information to determine target multi-level departmental chain information; storing the user business processing information on the blockchain using multi-level encryption based on the target multi-level departmental chain information to determine the business multi-level departmental chain information; and, based on a smart contract-driven strategy, performing multi-departmental chain-based collaborative processing of user business needs according to the user business needs and the business multi-level departmental chain information to determine and output the government processing result. This application improves the security of data sharing between different levels of departments during government processing, effectively ensuring a good balance between data security and government processing, improving user efficiency and experience, and promoting the process of e-government and the efficient allocation of social resources.

Description

Technical Field

[0001] This application relates to the field of data sharing security technology, and in particular to a method and system for secure sharing of government data based on blockchain technology. Background Technology

[0002] E-government, namely the digital and intelligent transformation of government services, is an inevitable trend in modern social development. Through e-government platforms, repetitive work can be reduced, processing time can be shortened, information asymmetry can be reduced, the interaction between the government and the public can be optimized, and the efficient allocation of social resources can be promoted.

[0003] However, existing e-government technologies struggle to effectively balance data security and government processing efficiency during data sharing among different levels of departments, resulting in a poor public experience and negatively impacting the progress of e-government adoption. Summary of the Invention

[0004] This application provides a method and system for secure sharing of government data based on blockchain technology to solve the aforementioned technical problems.

[0005] Firstly, this application provides a method for securely sharing government data based on blockchain technology, the method comprising:

[0006] Obtain user business processing information, analyze user business needs based on the user business processing information, and determine target multi-level department chain information;

[0007] Based on the target multi-level department chain information, the user business processing information is encrypted and anchored to the blockchain for storage, thereby determining the business multi-level department chain information;

[0008] Based on a smart contract-driven strategy, the user's business needs are processed in a multi-departmental chain collaborative manner according to the user's business needs and the multi-level departmental chain information of the business, and the government affairs processing results are determined and output.

[0009] This solution performs semantic analysis on user business processing information, accurately matches relevant government departments based on user business needs, and constructs a multi-level chain of target departmental information. This information is then encrypted, anchored, and stored on the blockchain, forming a multi-level chain of departmental information. Based on this, a smart contract-driven strategy is used to perform multi-departmental collaborative processing of user business needs, providing the corresponding government processing results to the user. This improves the security of data sharing between different levels of departments during government processing, effectively ensuring a good balance between data security and government processing, improving user efficiency and experience, and promoting the process of e-government and the efficient allocation of social resources.

[0010] Optionally, the user service processing information includes the user's unique identifier, biometric information, digital identity certificate, target service processing information, and a list of submitted materials;

[0011] The biometric information is identified by a liveness detection feature fusion algorithm integrated into the e-government all-in-one machine. Both the biometric information and the digital identity certificate are stored in the form of irreversible feature vector hash values ​​in each data node of the blockchain composed of relevant departments.

[0012] This solution constructs user business processing information based on the user's unique identifier, biometric information, digital identity certificate, target business processing information, and list of submitted materials. Biometric information and digital identity certificate are stored as irreversible feature vector hash values ​​in each data node of the blockchain composed of relevant departments, thus building a distributed user authentication mechanism based on blockchain technology to prevent the leakage of user identity due to single point of failure or risk.

[0013] Optionally, the step of analyzing user business needs and determining target multi-level department chain information based on the user business processing information includes:

[0014] Based on the preset set of information related to administrative department nodes, a tree topology diagram of administrative departments is constructed with provincial nodes as the root node, municipal nodes, district and county nodes and township nodes as branch nodes, and village and community nodes as leaf nodes.

[0015] Based on the target business information and the list of submitted materials, analyze the administrative department tree topology diagram to determine the local tree topology structure of the business-related departments;

[0016] Based on the biometric information and digital identity credentials provided by the user, the biometric information and digital identity credentials stored in each department node of the local tree topology of the business-related departments are jointly verified. If the verification is successful, the target multi-level department chain information is constructed using the user's unique identifier as an index, based on the corresponding department nodes and node relationships in the local tree topology of the business-related departments.

[0017] This solution utilizes a tree-like topology data structure to accurately reflect the relationships between different departments, constructing an administrative department tree-like topology map. Combined with a local structure filtering mechanism based on business needs, it extracts local tree-like topology structures of business-related departments that precisely correspond to user business needs from the administrative department tree-like topology map. Based on this, user identity is jointly verified using biometric vectors and digital credentials. Upon successful verification, the target multi-level department chain information is constructed to break down departmental barriers and avoid verification fragmentation, improving the collaborative processing efficiency of various departments and providing accurate target department node information for subsequent data security assurance in government affairs processing.

[0018] Optionally, the step of performing multi-level encryption and anchoring on-chain storage of the user business processing information based on the target multi-level department chain information, and determining the business multi-level department chain information, includes:

[0019] The structured data and unstructured data in the submitted materials list are separated and processed. Based on the business authority scope of different levels of departments in the target multi-level department chain information, the submitted materials list is decomposed into a set of independent data blocks corresponding to each level of department.

[0020] For each independent data block in the set of independent data blocks, the blockchain key generation module of the relevant department node at the corresponding level is invoked to generate a unique asymmetric key pair;

[0021] The private key in the unique asymmetric key pair is encrypted and stored locally by the department node, and the public key in the unique asymmetric key pair is broadcast to the associated department nodes at adjacent levels through a preset key distribution channel.

[0022] Based on the public key, each independent data block is dynamically encrypted in layers to generate several layered encrypted data packets with departmental level identifiers, and the hash value of the layered encrypted data packets is anchored to the distributed ledger of the corresponding departmental node in the blockchain.

[0023] The hash value of each layered encrypted data packet is subjected to cascade hash operation according to the department chain order in the target multi-level department chain information to generate a global data integrity verification value, and the global data integrity verification value is stored in the genesis block of the blockchain to form an immutable cross-department data association evidence chain.

[0024] Based on the distributed ledger and the cross-departmental data association evidence chain, a cross-departmental data association verification mechanism and a dynamic data update strategy are introduced to construct the multi-level departmental chain information of the business.

[0025] This solution ensures that departments can only access the minimum dataset necessary for approval by independently breaking down data into blocks and using hierarchical encryption, thus achieving "minimized data exposure" and reducing the risk of unauthorized access. Through cascading hashing and genesis block storage mechanisms, a cross-departmental data association evidence chain is formed, ensuring that any data tampering will trigger an anomaly in the global verification value, preventing abnormal data tampering by a single or multiple departments. By introducing a cross-departmental data association verification mechanism and a dynamic data update strategy, corresponding multi-level departmental chain information is constructed, further improving the security of data sharing.

[0026] Optionally, the cross-departmental data association verification mechanism includes:

[0027] Based on the node topology in the target multi-level departmental chain information, a data block index mapping table is constructed.

[0028] Each layered encrypted data packet is bound to the corresponding department node public key, generation timestamp, and superior department verification identifier;

[0029] By using a smart contract to call the public keys of adjacent department nodes stored on the blockchain, the hash values ​​of encrypted data packets from lower-level departments are jointly signed to generate cross-departmental data consistency verification parameters.

[0030] This scheme uses a data block index mapping table to trace the operation of each data packet precisely to a specific department node. Through a three-in-one binding mechanism, operation time, permission relationship, and identity credentials are fused into an indivisible evidence unit. Using a joint signature mechanism, the hash values ​​corresponding to the encrypted data packets of lower-level departments are jointly signed to generate cross-departmental data consistency verification parameters. Through a cross-departmental data association verification mechanism, distributed verification of shared data across multiple departments is achieved, avoiding the systemic risks brought about by centralized verification strategies.

[0031] Optionally, the cross-departmental data association verification mechanism further includes:

[0032] For the set of independent data blocks involving joint approval by multiple departments, the public key of at least one superior department node is selected as a verification factor to perform secondary encryption on the combined hash value of the subordinate data blocks, generating a composite digital envelope containing hierarchical relationships.

[0033] When any department node initiates a data access request, it must be decrypted collaboratively by department nodes whose number of preset verification factors exceeds the threshold in the composite digital envelope in order to obtain the associated verification parameters of the original data block.

[0034] This solution constructs a composite digital envelope to ensure that data requiring joint approval from multiple departments is under joint encryption protection during the transfer process. Even in the event of an advanced persistent threat attack, attackers cannot simultaneously crack the private keys corresponding to multiple verification factors, significantly reducing the risk of data leakage. By using verification factor thresholds, it forces multiple departments to substantially participate in the joint approval process, eliminating the problem of non-standard procedures caused by "formalized countersigning".

[0035] Optionally, the dynamic data update strategy includes:

[0036] When the encrypted data stored by a certain department node needs to be corrected, the key rotation protocol is triggered, and the department node generates a new generation of asymmetric key pairs and uses the new public key to re-encrypt the corrected data block.

[0037] Create a data update transaction record in the blockchain, the data update transaction record including the original data block hash, the new data block hash, the key version number and the data timestamp;

[0038] Based on the node hierarchy in the target multi-level department chain information, update notifications are propagated upwards level by level, and each superior department node performs chain-like weighting processing on the stored associated hash values ​​according to the update notifications.

[0039] For data changes involving multiple departments, a distributed consensus verification process is initiated: the department node that initiates the update sends a difference verification request to adjacent level nodes, collects digital signatures from more than two-thirds of the associated nodes, appends the updated data hash value to the original blockchain in the form of incremental blocks, and synchronously updates the global data integrity verification value.

[0040] This solution utilizes a chain-based weighted processing mechanism to ensure real-time cascading updates from lower-level nodes to higher-level nodes, eliminating version splits where "lower-level nodes have been modified, but higher-level nodes are unaware," thus ensuring data consistency. Furthermore, a key rotation mechanism ensures that each data update forms an independent cryptographic space, enhancing data resilience against attacks. Finally, a distributed consensus verification mechanism prevents single-point tampering risks.

[0041] Optionally, the smart contract-driven strategy, based on the user's business needs and the multi-level departmental chain information, performs multi-departmental chain-based collaborative processing of the user's business needs to determine and output the government processing results, including:

[0042] Based on the departmental hierarchy order in the multi-level departmental chain information of the business, a chain-like processing state machine is pre-set in the smart contract. The chain-like processing state machine includes business processing stage identifiers and inter-stage transition trigger conditions corresponding to each level of departmental nodes.

[0043] When the user's business needs trigger the inter-stage transition trigger condition, an initial transaction processing token is generated according to the smart contract. The transaction processing token carries the user's unique identifier, the current business processing stage identifier, and the hash value of the completed department node processing result.

[0044] According to the departmental hierarchy, the transaction processing token is pushed to the corresponding departmental node level by level;

[0045] Each relevant department node calls the corresponding independent data block in the layered encrypted data packet for decryption and verification based on its own business permissions, and performs preset business rule verification on the decrypted data to generate a local processing result with the department's digital signature.

[0046] Once all departmental nodes have completed their processing, the local processing results returned by each node are aggregated based on the smart contract. The local processing results are then cross-validated with the global data integrity verification value to generate and output the government affairs processing result.

[0047] This solution utilizes a chained state machine to automatically flow business processes along corresponding departmental hierarchical paths, preventing chain breakage and improving the resilience of government service processing. Furthermore, by combining a dual verification mechanism of local result hash chains and global verification values, tampering with shared data is promptly exposed, enhancing the security of shared data.

[0048] Optionally, the method further includes:

[0049] If the smart contract detects a conflict between the partial processing result returned by the hierarchical department node and the preset business rules, it triggers a backtracking verification mechanism.

[0050] The backtracking verification mechanism includes:

[0051] Freeze the current transaction token's flow state and generate a backtracking request event containing a conflict description;

[0052] The backtracking request event is broadcast to the upstream processed department nodes and associated supervision nodes, requesting joint re-verification of intermediate data in the historical processing stages;

[0053] When the signature verification is received from more than half of the associated nodes, the frozen state of the transaction token is released and the current conflicting node is skipped to continue the process;

[0054] If the verification fails, the data correction process is triggered, the abnormal data block is marked as pending correction, a transaction rollback instruction containing correction guidelines is generated and pushed to the user, and the hash value of the associated encrypted data packet stored in the blockchain is deleted until the user resubmits compliant data and the processing process is restarted.

[0055] This solution triggers a backtracking verification mechanism when a conflict arises between the local processing result and the preset business rules. Through a joint re-verification process involving multiple departments, it determines whether to continue the process. When more than half of the related nodes have received verified signatures, the process continues to improve business processing efficiency. If the verification fails, a data correction process is triggered to ensure the standardization of government processing procedures.

[0056] Secondly, this application provides a government data security sharing system based on blockchain technology, the system comprising:

[0057] The requirements analysis module is used to obtain user business processing information, analyze user business requirements based on the user business processing information, and determine target multi-level department chain information.

[0058] The multi-level anchoring module is used to perform multi-level encrypted anchoring and on-chain storage of the user business processing information based on the target multi-level department chain information, and to determine the business multi-level department chain information;

[0059] The collaborative processing module is used to perform multi-department chain collaborative processing of user business needs based on smart contract-driven strategies and according to the multi-level departmental chain information of the business, and to determine and output the government affairs processing results. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0061] Figure 1 This is a schematic diagram illustrating an application scenario provided in one embodiment of this application;

[0062] Figure 2 A flowchart illustrating a method for secure sharing of government data based on blockchain technology, provided as an embodiment of this application;

[0063] Figure 3 This is a schematic diagram of the structure of a government data security sharing system based on blockchain technology, provided as an embodiment of this application. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0065] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0066] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0067] Existing e-government technologies struggle to effectively balance data security and government processing efficiency during data sharing among different levels of departments, resulting in a poor public experience and negatively impacting the progress of e-government adoption.

[0068] Based on this, this application provides a method and system for secure sharing of government data based on blockchain technology. Semantic analysis is performed on user business processing information. According to user business needs, relevant government departments are accurately matched to construct a multi-level chain of target departmental information. This information is then encrypted, anchored, and stored on the blockchain, forming a multi-level chain of business departmental information. Based on this, a smart contract-driven strategy is used to perform multi-departmental chain-based collaborative processing of user business needs, providing the corresponding government processing results to the user. This improves the security of data sharing between different levels of departments during government processing, effectively ensuring a good balance between data security and government processing, improving user efficiency and experience, and promoting the process of e-government and the efficient allocation of social resources.

[0069] Figure 1 This diagram illustrates an application scenario provided by this application. In the process of e-government processing, the method provided in this application effectively ensures a good balance between data security and e-government processing, improves user efficiency and experience, and promotes the process of e-government and the efficient allocation of social resources.

[0070] Specifically, the method of this application is applied to any server that communicates with the e-government platform. Through this server, it obtains user behavior data provided by the e-government platform, performs semantic analysis on user business processing information, and accurately matches relevant government departments based on user business needs. This constructs a target multi-level departmental chain information, which is then encrypted, anchored, and stored on the blockchain, forming a multi-level departmental chain information. Based on this, a smart contract-driven strategy is used to perform multi-departmental chain-based collaborative processing of user business needs, providing the corresponding government processing results to the user. This improves the security of data sharing between different levels of departments during government processing, effectively ensuring a good balance between data security and government processing, improving user efficiency and experience, and promoting the process of e-government and the efficient allocation of social resources. Specific implementation methods can be found in the following embodiments.

[0071] Figure 2 This is a flowchart illustrating a method for securely sharing government data based on blockchain technology, provided as an embodiment of this application. The method of this embodiment can be applied to servers in the above scenarios. Figure 2 As shown, the method includes:

[0072] S201. Obtain user business processing information, analyze user business needs based on user business processing information, and determine target multi-level department chain information.

[0073] User service processing information can be a collection of government service materials submitted by users through the e-government platform.

[0074] User business needs can be the core government affairs objectives that users need to handle, obtained through semantic analysis of user business handling information or based on user-defined selections.

[0075] The target multi-level departmental chain information can be a departmental collaboration chain constructed according to administrative levels (province → city → district / county → township → village / community), reflecting the departments and hierarchical relationships that the business needs to reach.

[0076] Specifically, existing e-government processing systems suffer from significant delays in inter-departmental collaboration when facing cross-departmental government processing needs. This leads to low efficiency in cross-level government workflows, and data silos between departments often require users to submit application materials to multiple levels of departments, resulting in lengthy and time-consuming processes. Based on blockchain technology, by collecting user business processing information and performing automated semantic analysis, user business needs can be determined. Based on these needs, relevant departments can be accurately matched, and a pre-built blockchain sub-chain composed of nodes from relevant departments that matches the current user's needs can be precisely located.

[0077] S202. Based on the target multi-level department chain information, perform multi-level encryption and anchoring of user business processing information for on-chain storage to determine the business multi-level department chain information.

[0078] Multi-level encrypted anchored on-chain storage can be an operation that breaks down and encrypts user-submitted information according to the relevant departments and anchors it to the corresponding blockchain nodes.

[0079] Business multi-level department chain information can be a multi-level department blockchain chain that includes anchored data, a global verification mechanism, and a cross-department verification mechanism.

[0080] Specifically, the lack of an efficient cross-departmental verification mechanism in the process of multi-level departmental collaborative government affairs processing makes it difficult to detect potential unauthorized access behaviors in a timely manner, resulting in data security risks in the process of multi-departmental collaborative government affairs processing. Based on the relevant departments corresponding to the target multi-level departmental chain information, departmental correlation analysis is performed on user business processing information, user business processing information is decomposed and encrypted in blocks, and the corresponding decomposed and encrypted information is anchored to the blockchain nodes of the relevant departments. Combined with the introduced global verification mechanism and cross-departmental verification mechanism, a multi-level departmental blockchain chain is constructed, which avoids the problem of data silos and improves the security of government data sharing.

[0081] S203. Based on the smart contract-driven strategy, according to the user's business needs and the information of the multi-level departmental chain, the user's business needs are processed in a multi-departmental chain collaboration, and the government affairs processing results are determined and output.

[0082] Smart contract-driven strategies can be pre-defined rules for automated government affairs processing.

[0083] Multi-department chain-based collaborative processing can be a process of passing transaction tokens according to the chain relationship and departmental hierarchy, and performing business verification and processing at each level.

[0084] The government processing result can be the processing result information that is pushed to the user after the current blockchain chain performs chain-based collaborative processing on the current government processing needs.

[0085] Specifically, after clarifying the user's government affairs processing needs and the corresponding relevant departments, based on the pre-built smart contract rules (based on the standard processing procedures of government affairs), blockchain technology is used to process the user's business needs through multi-department chain collaboration by utilizing the blockchain links corresponding to the multi-level departmental chain information. The blockchain nodes of the corresponding departments at the business exit integrate the government affairs processing results obtained after consensus among the various blockchain nodes, visualize the government affairs processing results through data visualization technology, and push the government affairs processing results to the corresponding users through electronic government affairs all-in-one machines or user device terminals so that users can keep track of the processing progress in a timely manner.

[0086] This solution performs semantic analysis on user business processing information, accurately matches relevant government departments based on user business needs, and constructs a multi-level chain of target departmental information. This information is then encrypted, anchored, and stored on the blockchain, forming a multi-level chain of departmental information. Based on this, a smart contract-driven strategy is used to perform multi-departmental collaborative processing of user business needs, providing the corresponding government processing results to the user. This improves the security of data sharing between different levels of departments during government processing, effectively ensuring a good balance between data security and government processing, improving user efficiency and experience, and promoting the process of e-government and the efficient allocation of social resources.

[0087] In some embodiments, user business processing information includes a unique user identifier, biometric information, digital identity certificate, target business processing information, and a list of submitted materials; biometric information is identified by a liveness detection feature fusion algorithm integrated into the e-government all-in-one machine, and both biometric information and digital identity certificate are stored in the form of irreversible feature vector hash values ​​in each data node of the blockchain composed of relevant departments.

[0088] A user's unique identifier can be identification data used to refer to the current user's identity, such as an ID card number.

[0089] Biometric information can be unique identity verification data generated through a user's physiological characteristics (such as face, fingerprint, etc.).

[0090] Digital identity credentials can be electronic identity verification documents (such as digital ID cards or CA certificates) issued by government agencies.

[0091] The target service information can be the target service that the user currently needs to process.

[0092] The list of materials to be submitted can be a collection of materials submitted by the user for the current business.

[0093] E-government kiosks can be intelligent terminal devices used to interact with users and collect information on user applications.

[0094] Liveness detection feature fusion algorithms can be mathematical algorithms that integrate biometric information from different sources or modalities to improve the system's ability to distinguish between real organisms and fake attacks, such as Multi-modal CNN.

[0095] An irreversible feature vector hash value can be a fixed-length unique string obtained by converting the feature vector of biometric information or digital identity credentials through a cryptographic hash function (such as SHA-256 / SM3).

[0096] Data nodes can be distributed server nodes operated by departments at various levels, collectively maintaining the same ledger.

[0097] Specifically, user identification is crucial in government processing. By using unique user identifiers, biometric information, and digital identity credentials, user identity can be represented from application, biometric, and security dimensions, achieving multi-dimensional user identification. Current technologies typically use centralized databases for storing and identifying user identities, which carries a single point of failure risk. This is particularly problematic in multi-level government coordination processes, where users need to submit critical information representing their identity to different departments, significantly increasing the risk of identity information leakage. By integrating a liveness detection feature fusion algorithm into the e-government all-in-one machine to analyze user biometric information, digital identity credentials are extracted. Cryptographic hash functions are then used to irreversibly convert the user's biometric information and digital identity credentials into hash values. These irreversible hash values ​​are stored in each data node of a blockchain composed of relevant departments, constructing a distributed user authentication mechanism based on blockchain technology.

[0098] This solution constructs user business processing information based on the user's unique identifier, biometric information, digital identity certificate, target business processing information, and list of submitted materials. Biometric information and digital identity certificate are stored as irreversible feature vector hash values ​​in each data node of the blockchain composed of relevant departments, thus building a distributed user authentication mechanism based on blockchain technology to prevent the leakage of user identity due to single point of failure or risk.

[0099] In some embodiments, based on a preset set of administrative department node association information, a tree-like topology diagram of administrative departments is constructed, with provincial-level nodes as the root node, municipal-level nodes, district / county-level nodes, and township-level nodes as branch nodes, and village / community-level nodes as leaf nodes. The tree-like topology diagram is analyzed based on the target business processing information and the list of submitted materials to determine the local tree-like topology structure of the relevant departments. Based on the biometric information and digital identity credentials provided by the user, the biometric information and digital identity credentials stored in each department node of the local tree-like topology structure of the relevant departments are jointly verified. If the verification is successful, a target multi-level department chain information is constructed using the user's unique identifier as an index, based on the corresponding department nodes and node relationships in the local tree-like topology structure of the relevant departments.

[0100] The pre-defined administrative department node association information set can be a structured dataset that stores the hierarchical relationships of departments at all levels, including departmental affiliation, functional scope, and unique node codes.

[0101] Provincial nodes can refer to data nodes of provincial / municipal departments.

[0102] The root node can be the starting node of a tree topology.

[0103] City-level nodes can refer to data nodes of prefecture-level city departments.

[0104] District / county level nodes can refer to data nodes of county / district level departments.

[0105] Township-level nodes can refer to data nodes of township / street-level departments.

[0106] Branch nodes can be intermediate nodes in a tree topology used to connect parent and child nodes.

[0107] Village / community level nodes can be used to refer to data nodes of village / community level departments.

[0108] Leaf nodes can be data nodes located at the end of a branch in a tree topology that do not have corresponding lower-level nodes.

[0109] A tree topology diagram of administrative departments can be structured data used to represent the hierarchical tree relationships between different departments.

[0110] The local tree-like topology of business-related departments can be a subgraph structure extracted from the complete tree-like topology graph, consisting of department nodes and their associated paths that are directly related to the target business.

[0111] Specifically, existing e-government processing technologies suffer from departmental barriers and fragmented verification issues when dealing with government affairs involving collaboration among multiple levels of departments. Specifically, it is difficult for dispersed departmental nodes to communicate and collaborate effectively with their superiors and subordinates, and it is difficult to conduct cross-departmental joint verification when disputes arise. The system loads all node data from the preset administrative department node association information set. Using the provincial node as the root, it establishes parent-child relationship edges in the hierarchical order of city → district / county → township → village / community, generating a complete administrative department tree topology. It parses the business type code (e.g., "pension insurance transfer" code GB123) corresponding to the target business information, combines it with the submitting department mapped in the submitted materials list, queries the preset business-department mapping table, extracts the list of participating department nodes, and extracts the local tree topology structure of the relevant departments based on the association relationships of the above department node list in the administrative department tree topology. It hashes the collected biometric vectors and digital vouchers separately, and initiates a verification request to the blockchain ledger of each department node in the local topology structure. Each node compares the received hash value with the pre-stored hash value stored in its own node. If all nodes return verification passed, the joint verification is considered successful. Using the user's unique identifier as an index, it sorts the nodes in the local topology structure from high to low departmental level, generating the target multi-level department chain information.

[0112] This solution utilizes a tree-like topology data structure to accurately reflect the relationships between different departments, constructing an administrative department tree-like topology map. Combined with a local structure filtering mechanism based on business needs, it extracts local tree-like topology structures of business-related departments that precisely correspond to user business needs from the administrative department tree-like topology map. Based on this, user identity is jointly verified using biometric vectors and digital credentials. Upon successful verification, the target multi-level department chain information is constructed to break down departmental barriers and avoid verification fragmentation, improving the collaborative processing efficiency of various departments and providing accurate target department node information for subsequent data security assurance in government affairs processing.

[0113] In some embodiments, the structured data and unstructured data in the submitted materials list are separated. Based on the business authority scope of different levels of departments in the target multi-level departmental chain information, the submitted materials list is decomposed into a set of independent data blocks corresponding to each level of department. For each independent data block in the set of independent data blocks, the blockchain key generation module of the relevant department node at the corresponding level is invoked to generate a unique asymmetric key pair. The private key in the unique asymmetric key pair is encrypted and stored locally by the department node, and the public key in the unique asymmetric key pair is broadcast to the associated department nodes at adjacent levels through a preset key distribution channel. Based on the public key, for each independent data block... Data blocks are dynamically encrypted in layers to generate several layered encrypted data packets with departmental level identifiers. The hash values ​​of these layered encrypted data packets are anchored to the distributed ledger of the corresponding departmental node in the blockchain. The hash values ​​of each layered encrypted data packet are then subjected to cascading hash operations according to the departmental chain order in the target multi-level departmental chain information to generate a global data integrity verification value. This global data integrity verification value is stored in the genesis block of the blockchain, forming an immutable cross-departmental data association evidence chain. Based on the distributed ledger and the cross-departmental data association evidence chain, a cross-departmental data association verification mechanism and a dynamic data update strategy are introduced to construct the business multi-level departmental chain information.

[0114] Structured data can be data with a regular format in the list of submitted materials, such as ID card number, social security number, etc.

[0115] Unstructured data can be irregularly formatted data in the submitted materials list, such as scanned documents and images.

[0116] The scope of business authority can be the scope of government affairs processing authority of the relevant department.

[0117] The set of independent data blocks is a set of encrypted units formed by breaking down the data according to the business permissions of each department. Each data block contains only a subset of the materials required for approval by a single department.

[0118] The blockchain key generation module can be a functional module that encrypts data blocks based on asymmetric encryption algorithms.

[0119] A unique asymmetric key pair can be an asymmetric key pair generated according to an asymmetric encryption algorithm, including a private key and a public key.

[0120] A private key can be a key in a key pair that is held and controlled only by the owner.

[0121] A public key can be a key that can be freely distributed publicly, does not require secrecy, and can be obtained by anyone.

[0122] Local encrypted storage can be the process of encrypting and storing data within a department's data node.

[0123] The preset key distribution channel can be a pre-defined communication path in the blockchain for securely transmitting encryption keys, and the communication path between nodes can be established through the TLS / SSL protocol.

[0124] The associated department node can be any other node that has a hierarchical relationship with the current department node.

[0125] Dynamic hierarchical encryption can be a process of encrypting a set of independent data blocks by using departmental levels as the hierarchical unit.

[0126] Layered encrypted data packets can be encrypted data units carrying departmental hierarchy identifiers, generated by encrypting original data blocks with a public key.

[0127] Departmental level identifiers can be identifying information used to refer to the current department and its level (such as "municipal level - social security bureau").

[0128] A distributed ledger can be a database in a blockchain that is jointly maintained by all participants, is immutable, and is transparently shared.

[0129] Cascaded hashing can be a calculation process that recursively concatenates the hash values ​​of adjacent data packets in the order of departmental chains and then re-hashes them.

[0130] The global data integrity check value can be the final output value of the cascaded hash operation, serving as the sole proof of the correlation of the entire chain of data.

[0131] The genesis block can be the starting block for the creation of a blockchain, serving as the sole starting point and trust anchor for the entire chain data structure.

[0132] A cross-departmental data association evidence chain can be a tamper-proof data association system composed of hierarchical hash anchors in a distributed ledger and global verification values ​​of the genesis block.

[0133] A cross-departmental data correlation verification mechanism can be a logical rule that automatically verifies the consistency of data across multiple departments through smart contracts.

[0134] Dynamic data update strategies can be key rotation and hash recalculation protocols triggered when encrypted data needs to be corrected.

[0135] Specifically, the current method of sharing government data by encrypting all data on the blockchain results in lower-level department nodes potentially accessing highly sensitive data beyond their approval scope, and irrelevant data increases the decryption burden, requiring departments to sift through redundant information for valid content. By parsing the submitted materials list, structured data (ID numbers, social security codes) is stored in a JSON template, and unstructured data (scanned copies of property ownership certificates) is converted into a binary stream. Based on the target multi-level department chain information (e.g., "Provincial Human Resources and Social Security Department - Municipal Social Security Bureau - District Service Center"), the permission mapping table is invoked, and independent data blocks are decomposed based on the department's business permission scope to obtain a set of independent data blocks, achieving "minimized data exposure." For each independent data block, the key engine of the corresponding department node is invoked to generate an SM2 asymmetric key pair. The private key is stored in the department's local secure area via an HSM encryption module, and the public key is broadcast to adjacent level nodes via the government intranet. The received public key is used to encrypt the data block, generating a layered encrypted data packet with hierarchical tags, and each encrypted data packet is input into SHA-256 hashes. The hash function generates a unique digest value (e.g., "a1b2c3..."), which is then written into the distributed ledger of the corresponding department node through an anchored smart contract. Furthermore, if the distributed encrypted data packets lack a mandatory association mechanism, it will be difficult to quickly locate the abnormal associated nodes after a single department tampers with local data, significantly increasing the time cost of tracing joint operations across multiple departments. Therefore, cascading hashing is performed according to the order of different related departments in the chain: the first-level hash value H0 = Hash(village / community level packet), the second-level hash value H1 = Hash(H0 + township level packet), the second-level hash value H2 = Hash(H1 + district / county level packet), the third-level hash value H3 = Hash(H2 + city level packet); and the last-level hash value H_global = Hash(H3 + provincial level packet). The last-level hash value is used as the global data integrity verification value and stored in the genesis block, forming a cross-departmental data association evidence chain. Based on this, a cross-departmental data association verification mechanism and a dynamic data update strategy are introduced to construct the corresponding multi-level departmental chain information for the business.

[0136] This solution ensures that departments can only access the minimum dataset necessary for approval by independently breaking down data into blocks and using hierarchical encryption, thus achieving "minimized data exposure" and reducing the risk of unauthorized access. Through cascading hashing and genesis block storage mechanisms, a cross-departmental data association evidence chain is formed, ensuring that any data tampering will trigger an anomaly in the global verification value, preventing abnormal data tampering by a single or multiple departments. By introducing a cross-departmental data association verification mechanism and a dynamic data update strategy, corresponding multi-level departmental chain information is constructed, further improving the security of data sharing.

[0137] In some embodiments, a data block index mapping table is constructed based on the node topology relationship in the target multi-level department chain information; each layer of encrypted data packet is bound to the corresponding department node public key, generation timestamp, and upper-level department verification identifier; the hash value of the lower-level department encrypted data packet is jointly signed by calling the public keys of adjacent department nodes stored on the chain through a smart contract, thereby generating cross-department data consistency verification parameters.

[0138] Node topology can be structured data that describes the hierarchical relationship between nodes in a multi-level departmental chain, such as the association path between a parent node (provincial level) and a child node (municipal level).

[0139] The data block index mapping table can be a metadata table that records the topological relationship between hierarchical encrypted data packets and departmental nodes.

[0140] The department node public key can be an asymmetric encryption public key generated by the department node, used for data encryption and signature verification.

[0141] The public key of an adjacent department node can be the public key of a department node that has a direct topological association with the current node.

[0142] The generated timestamp can be an authoritative time record (UTC millisecond precision) of the moment the data packet was created.

[0143] The verification identifier of the superior department can be a unique verification code issued by the superior department node, which represents the review and authorization of the data packets of the subordinate department.

[0144] Joint signature can be an operation in which multiple departmental nodes use their private keys to collaboratively sign the same data hash value.

[0145] Cross-departmental data consistency verification parameters can be a set of verification credentials that includes joint signature results, participating node IDs, and expiration stamps.

[0146] Specifically, in existing technologies, cross-departmental data verification relies on centralized institutions (such as government big data centers) as trust intermediaries. This leads to the paralysis of the verification process if the central institution malfunctions or is attacked, and it is impossible to accurately locate the responsible node when there are disputes in the operation of multiple departments. Based on the node topology relationship in the target multi-level departmental chain information, a unique index entry is generated for each layered encrypted data packet, and metadata tags are added to each layered encrypted data packet: the generation timestamp is obtained by calling the time synchronization center API, a digital signature is applied for from the direct superior department, a verification identifier of the superior department is generated, and the MD5 fingerprint of the department's public key is extracted. The hash value of the lower-level data packet is received through a smart contract, and the public keys of adjacent nodes stored on the chain are automatically retrieved to trigger a multi-party collaborative signature process. The superior department performs a second signature on the signature information of the lower-level department, and so on, and the final signature information is used as a cross-departmental data consistency verification parameter.

[0147] This scheme uses a data block index mapping table to trace the operation of each data packet precisely to a specific department node. Through a three-in-one binding mechanism, operation time, permission relationship, and identity credentials are fused into an indivisible evidence unit. Using a joint signature mechanism, the hash values ​​corresponding to the encrypted data packets of lower-level departments are jointly signed to generate cross-departmental data consistency verification parameters. Through a cross-departmental data association verification mechanism, distributed verification of shared data across multiple departments is achieved, avoiding the systemic risks brought about by centralized verification strategies.

[0148] In some embodiments, for a set of independent data blocks involving joint approval by multiple departments, the public key of at least one superior department node is selected as a verification factor to perform secondary encryption on the combined hash value of the subordinate data blocks, generating a composite digital envelope containing hierarchical relationships. When any department node initiates a data access request, it must be decrypted collaboratively by department nodes with a preset verification factor number threshold or higher in the composite digital envelope in order to obtain the associated verification parameters of the original data block.

[0149] Joint approval by multiple departments can be a business approval process that requires the participation of two or more departments.

[0150] The verification factor can be a public key credential from a higher authority used to decrypt the composite digital envelope.

[0151] A combined hash value can be the root hash value generated by aggregating the hash values ​​of multiple lower-level data blocks through a Merkle tree.

[0152] A composite digital envelope can be a secure container containing an encrypted combined hash value, a list of verification factors, and a hierarchy identifier.

[0153] A data retrieval request can be a data sharing need from one department node to another department node.

[0154] The preset threshold for the number of verification factors can be the minimum number of collaborating departments required for decryption.

[0155] Collaborative decryption by departmental nodes can be an operation in which multiple verification factor holding departments jointly decrypt using their private keys.

[0156] The associated verification parameter can be the verification credential of the original data block obtained after decryption.

[0157] Specifically, existing technologies pose a risk of "excessive influence of the lead department" when dealing with business requiring joint approval from multiple departments, and the data security risks increase significantly during the flow of shared data between different departments. By identifying joint approval tags from multiple departments through smart contracts, a set of associated independent data blocks is extracted. This is used to construct a Merkle tree to calculate a combined hash value. The public key of at least one superior department node is selected as a verification factor. The current combined hash value is then encrypted a second time using the SM2 encryption algorithm to generate a composite digital envelope. When any department node initiates a data access request, it needs to send collaborative decryption requests to a number of departments exceeding a preset threshold for the number of verification factors. Only after these departments complete the collaborative decryption operation can the department node that initiated the data access request obtain the associated verification parameters of the original data block.

[0158] This solution constructs a composite digital envelope to ensure that data requiring joint approval from multiple departments is under joint encryption protection during the transfer process. Even in the event of an advanced persistent threat attack, attackers cannot simultaneously crack the private keys corresponding to multiple verification factors, significantly reducing the risk of data leakage. By using verification factor thresholds, it forces multiple departments to substantially participate in the joint approval process, eliminating the problem of non-standard procedures caused by "formalized countersigning".

[0159] In some embodiments, when encrypted data stored by a department node at a certain level needs to be corrected, a key rotation protocol is triggered. The department node generates a new generation of asymmetric key pairs and re-encrypts the corrected data block using the new public key. A data update transaction record is created in the blockchain, which includes the original data block hash, the new data block hash, the key version number, and the data timestamp. According to the node hierarchy in the target multi-level department chain information, the update notification is propagated upwards level by level. Each higher-level department node performs chain-like weighting processing on the stored associated hash value according to the update notification. For data changes involving multi-department linkage, a distributed consensus verification process is initiated: the department node that initiates the update sends a difference verification request to adjacent level nodes. After collecting the digital signatures of more than two-thirds of the associated nodes, the updated data hash value is appended to the original blockchain in the form of an incremental block, and the global data integrity verification value is updated synchronously.

[0160] Key rotation protocols can be a standard process for periodically changing encryption keys to ensure data security.

[0161] The next generation of asymmetric key pairs can be a combination of public and private keys newly generated using the SM2 algorithm.

[0162] Data update transaction records can be blockchain data credentials that record the data change process.

[0163] The original data block hash can be the SHA-256 digest value of the data block before correction.

[0164] The new data block hash can be the SHA-256 digest value of the corrected data block.

[0165] The key version number can be a sequence number that identifies the number of key iterations (such as "VER_2.1").

[0166] A data timestamp can be an authoritative timestamp of when a data update occurs.

[0167] Chained weighting can be an operation where higher-level nodes update associated hash values ​​in hierarchical order.

[0168] The distributed consensus verification process can be a collaborative verification process of data differences among distributed departmental nodes.

[0169] A difference verification request can be a request to compare the differences between new and old data.

[0170] An incremental block can be a lightweight blockchain unit that only records the parts of the data that have been changed.

[0171] Specifically, based on the data collaborative verification mechanism, when data under the same processing business changes, the corresponding data in the chain composed of relevant departments needs to be dynamically updated to ensure data consistency and avoid problems such as "isolated changes," "trust gaps," and "collaboration deadlocks." When the encrypted data stored by a certain level of department node needs to be corrected, a key rotation protocol is triggered, an asymmetric encryption algorithm is called to generate a new generation of asymmetric key pairs, and the corrected data block is re-encrypted. The new private key is locally encrypted and stored, and a data update transaction record is generated, recording the original data block hash, the new data block hash, the key version number, and the data timestamp. This provides data support for tracing data changes. Modifications to the above data blocks are transmitted upwards along the chain level in the form of update notifications, realizing chain-based weighted processing. The distributed formula verification mechanism constrains the process of data changes involving multiple departments. It requires the department node initiating the update to add the updated data to the original blockchain after collecting digital signatures from more than two-thirds of the related nodes, and to simultaneously update the global data integrity verification value to prevent single-point tampering.

[0172] This solution utilizes a chain-based weighted processing mechanism to ensure real-time cascading updates from lower-level nodes to higher-level nodes, eliminating version splits where "lower-level nodes have been modified, but higher-level nodes are unaware," thus ensuring data consistency. Furthermore, a key rotation mechanism ensures that each data update forms an independent cryptographic space, enhancing data resilience against attacks. Finally, a distributed consensus verification mechanism prevents single-point tampering risks.

[0173] In some embodiments, based on the departmental hierarchy order in the multi-level departmental chain information, a chain-like processing state machine is pre-configured in the smart contract. The chain-like processing state machine includes business processing stage identifiers and inter-stage transition trigger conditions corresponding to each level of departmental nodes. When a user's business request triggers the inter-stage transition trigger condition, an initial transaction processing token is generated according to the smart contract. The transaction processing token carries the user's unique identifier, the current business processing stage identifier, and the hash value of the completed departmental node processing result. According to the departmental hierarchy order, the transaction processing token is pushed to the corresponding departmental nodes level by level. Each relevant departmental node calls the corresponding independent data block in the layered encrypted data packet for decryption and verification based on its own business permissions, and performs preset business rule verification on the decrypted data to generate a partial processing result with a departmental digital signature. When all levels of departmental nodes have completed processing, based on the smart contract, the partial processing results returned by each node are aggregated, and the partial processing results are cross-verified with the global data integrity verification value to generate and output the government affairs processing result.

[0174] A chained processing state machine can be a pre-built departmental business flow logic controller in a smart contract.

[0175] The business processing stage identifier can be a code that marks the current processing stage (such as "STAGE_TAX_VERIFY" indicating the tax verification stage).

[0176] The triggering condition for inter-stage transitions can be a rule that drives the cross-departmental flow of transactions.

[0177] A transaction token can be a secure digital credential that carries the processing context.

[0178] The hash value of the processing result can be used to verify whether the processing result has been tampered with.

[0179] Pre-defined business rule verification can be a compliance check logic pre-built into the smart contract.

[0180] Local processing results can be the business output of a single department node.

[0181] Cross-validation can be an automated verification process that compares local results with global credentials.

[0182] Specifically, in existing multi-departmental collaborative government affairs processing, chain-like breaks are prone to occur, leading to the collapse of the collaborative processing flow. This can be addressed by loading multi-level departmental business chains through smart contracts to create a chain-like processing state machine. This state machine includes stage identifiers and stage transition conditions. When user business needs trigger the inter-stage transition conditions, an initial transaction processing token is generated according to the smart contract. Based on the departmental hierarchy, each department invokes the corresponding business permissions, and different departments, carrying transaction processing tokens, perform chain-like hierarchical decryption processing to generate local processing results with each department's digital signature. These local processing results are cross-validated with the global data integrity check value. After successful verification, the corresponding government affairs processing result is generated through aggregation and visualization of different local processing results.

[0183] This solution utilizes a chained state machine to automatically flow business processes along corresponding departmental hierarchical paths, preventing chain breakage and improving the resilience of government service processing. Furthermore, by combining a dual verification mechanism of local result hash chains and global verification values, tampering with shared data is promptly exposed, enhancing the security of shared data.

[0184] In some embodiments, if the smart contract identifies a conflict between the partial processing result returned by the hierarchical department node and the preset business rules, a backtracking verification mechanism is triggered. The backtracking verification mechanism includes: freezing the current transaction processing token's circulation state and generating a backtracking request event containing a conflict description; broadcasting the backtracking request event to the upstream processed department nodes and associated supervisory nodes, requesting joint re-verification of intermediate data in the historical processing stage; when more than half of the associated nodes have received verification signatures that have passed verification, the frozen state of the transaction processing token is lifted and the current conflicting node is skipped to continue circulation; if the verification fails, a data correction process is triggered, the abnormal data block is marked as pending correction, a transaction rollback instruction containing correction guidelines is generated and pushed to the user, and the hash value of the associated encrypted data packet stored in the blockchain is deleted until the user resubmits compliant data and the processing process is restarted.

[0185] Preset business rules can be the government affairs processing rules in the business standard processing specifications.

[0186] The backtracking verification mechanism can be a cross-level joint review process triggered when data conflicts occur.

[0187] The transfer status can be a marker indicating the transfer status of transaction tokens between department nodes.

[0188] A conflict description can be descriptive information pointing to a conflict between the current business process and the standard business process.

[0189] A backtracking request event can be a data re-verification trigger instruction containing conflict details.

[0190] The processed department node can be a department node that has processed the business before the current conflict node.

[0191] The associated monitoring node can be a data node corresponding to an independent organization with auditing authority.

[0192] Historical processing steps can be the processing information of departmental nodes that have already been processed.

[0193] Joint revalidation can be a process in which multiple departments revalidate data.

[0194] A conflict node can be a department node where a business processing rule situation is currently occurring.

[0195] The revision guidelines can be information suggesting revisions to conflict rules.

[0196] Compliant data can be data that conforms to standard business processing rules.

[0197] Specifically, in the process of multi-departmental collaborative processing of government affairs, there may be situations where non-standard user-submitted data conflicts with the processing rules of some nodes. When this happens, a backtracking verification mechanism is triggered, freezing the current transaction processing token's circulation status to prevent further spread of the faulty node and contamination of other departments' processing results. Based on this, according to the matched partial conflict rule information, a backtracking request event containing a conflict description is generated. This backtracking request event is broadcast to upstream processed department nodes and associated monitoring nodes through a data sharing channel. According to the cross-departmental data association verification mechanism, the intermediate data is jointly re-verified by multiple departments. Verification is performed when more than half of the associated nodes have passed the verification signature. This indicates that the current conflict has a small impact and is relatively independent. To ensure efficiency, the transaction processing token is unfrozen and the current conflict node is skipped to continue the process. After the process is completed, the user can submit some modified materials. If the verification fails, it indicates that the current conflict has a small impact but a chain reaction. The abnormal data block is marked as pending correction, and a transaction rollback instruction containing correction guidelines is generated and pushed to the user. At the same time, the hash value of the associated encrypted data packet stored in the blockchain is deleted. The processing process is restarted after the user resubmits compliant data to ensure the standardization of the government processing process.

[0198] This solution triggers a backtracking verification mechanism when a conflict arises between the local processing result and the preset business rules. Through a joint re-verification process involving multiple departments, it determines whether to continue the process. When more than half of the related nodes have received verified signatures, the process continues to improve business processing efficiency. If the verification fails, a data correction process is triggered to ensure the standardization of government processing procedures.

[0199] Figure 3 A schematic diagram of the structure of a government data security sharing system based on blockchain technology is provided as an embodiment of this application, as shown below. Figure 3 As shown, the government data security sharing system 300 based on blockchain technology in this embodiment includes: a demand analysis module 301, a multi-level anchoring module 302, and a collaborative processing module 303.

[0200] The demand analysis module 301 is used to obtain user business processing information, analyze user business needs based on the user business processing information, and determine target multi-level department chain information.

[0201] The multi-level anchoring module 302 is used to perform multi-level encrypted anchoring and on-chain storage of the user business processing information based on the target multi-level department chain information, and to determine the business multi-level department chain information;

[0202] The collaborative processing module 303 is used to perform multi-department chain collaborative processing on the user's business needs based on the smart contract-driven strategy and the multi-level department chain information of the business, and to determine and output the government affairs processing results.

[0203] Optionally, in the demand analysis module 301, the user business processing information includes the user's unique identifier, biometric information, digital identity certificate, target business processing information, and a list of submitted materials;

[0204] The biometric information is identified by a liveness detection feature fusion algorithm integrated into the e-government all-in-one machine. Both the biometric information and the digital identity certificate are stored in the form of irreversible feature vector hash values ​​in each data node of the blockchain composed of relevant departments.

[0205] Optionally, the requirements analysis module 301 is specifically used for:

[0206] Based on the preset set of information related to administrative department nodes, a tree topology diagram of administrative departments is constructed with provincial nodes as the root node, municipal nodes, district and county nodes and township nodes as branch nodes, and village and community nodes as leaf nodes.

[0207] Based on the target business information and the list of submitted materials, analyze the administrative department tree topology diagram to determine the local tree topology structure of the business-related departments;

[0208] Based on the biometric information and digital identity credentials provided by the user, the biometric information and digital identity credentials stored in each department node of the local tree topology of the business-related departments are jointly verified. If the verification is successful, the target multi-level department chain information is constructed using the user's unique identifier as an index, based on the corresponding department nodes and node relationships in the local tree topology of the business-related departments.

[0209] Optionally, the multi-level anchoring module 302 is specifically used for:

[0210] The structured data and unstructured data in the submitted materials list are separated and processed. Based on the business authority scope of different levels of departments in the target multi-level department chain information, the submitted materials list is decomposed into a set of independent data blocks corresponding to each level of department.

[0211] For each independent data block in the set of independent data blocks, the blockchain key generation module of the relevant department node at the corresponding level is invoked to generate a unique asymmetric key pair;

[0212] The private key in the unique asymmetric key pair is encrypted and stored locally by the department node, and the public key in the unique asymmetric key pair is broadcast to the associated department nodes at adjacent levels through a preset key distribution channel.

[0213] Based on the public key, each independent data block is dynamically encrypted in layers to generate several layered encrypted data packets with departmental level identifiers, and the hash value of the layered encrypted data packets is anchored to the distributed ledger of the corresponding departmental node in the blockchain.

[0214] The hash value of each layered encrypted data packet is subjected to cascade hash operation according to the department chain order in the target multi-level department chain information to generate a global data integrity verification value, and the global data integrity verification value is stored in the genesis block of the blockchain to form an immutable cross-department data association evidence chain.

[0215] Based on the distributed ledger and the cross-departmental data association evidence chain, a cross-departmental data association verification mechanism and a dynamic data update strategy are introduced to construct the multi-level departmental chain information of the business.

[0216] Optionally, in the multi-level anchoring module 302, the cross-departmental data association verification mechanism is used for:

[0217] Based on the node topology in the target multi-level departmental chain information, a data block index mapping table is constructed.

[0218] Each layered encrypted data packet is bound to the corresponding department node public key, generation timestamp, and superior department verification identifier;

[0219] By using a smart contract to call the public keys of adjacent department nodes stored on the blockchain, the hash values ​​of encrypted data packets from lower-level departments are jointly signed to generate cross-departmental data consistency verification parameters.

[0220] Optionally, in the multi-level anchoring module 302, the cross-departmental data association verification mechanism is specifically used for:

[0221] For the set of independent data blocks involving joint approval by multiple departments, the public key of at least one superior department node is selected as a verification factor to perform secondary encryption on the combined hash value of the subordinate data blocks, generating a composite digital envelope containing hierarchical relationships.

[0222] When any department node initiates a data access request, it must be decrypted collaboratively by department nodes whose number of preset verification factors exceeds the threshold in the composite digital envelope in order to obtain the associated verification parameters of the original data block.

[0223] Optionally, in the multi-level anchoring module 302, the dynamic data update strategy is specifically used for:

[0224] When the encrypted data stored by a certain department node needs to be corrected, the key rotation protocol is triggered, and the department node generates a new generation of asymmetric key pairs and uses the new public key to re-encrypt the corrected data block.

[0225] Create a data update transaction record in the blockchain, the data update transaction record including the original data block hash, the new data block hash, the key version number and the data timestamp;

[0226] Based on the node hierarchy in the target multi-level department chain information, update notifications are propagated upwards level by level, and each superior department node performs chain-like weighting processing on the stored associated hash values ​​according to the update notifications.

[0227] For data changes involving multiple departments, a distributed consensus verification process is initiated: the department node that initiates the update sends a difference verification request to adjacent level nodes, collects digital signatures from more than two-thirds of the associated nodes, appends the updated data hash value to the original blockchain in the form of incremental blocks, and synchronously updates the global data integrity verification value.

[0228] Optionally, the collaborative processing module 303 is specifically used for:

[0229] Based on the departmental hierarchy order in the multi-level departmental chain information of the business, a chain-like processing state machine is pre-set in the smart contract. The chain-like processing state machine includes business processing stage identifiers and inter-stage transition trigger conditions corresponding to each level of departmental nodes.

[0230] When the user's business needs trigger the inter-stage transition trigger condition, an initial transaction processing token is generated according to the smart contract. The transaction processing token carries the user's unique identifier, the current business processing stage identifier, and the hash value of the completed department node processing result.

[0231] According to the departmental hierarchy, the transaction processing token is pushed to the corresponding departmental node level by level;

[0232] Each relevant department node calls the corresponding independent data block in the layered encrypted data packet for decryption and verification based on its own business permissions, and performs preset business rule verification on the decrypted data to generate a local processing result with the department's digital signature.

[0233] Once all departmental nodes have completed their processing, the local processing results returned by each node are aggregated based on the smart contract. The local processing results are then cross-validated with the global data integrity verification value to generate and output the government affairs processing result.

[0234] Optionally, the system further includes a backtracking verification module 304, specifically used for:

[0235] If the smart contract detects a conflict between the partial processing result returned by the hierarchical department node and the preset business rules, it triggers a backtracking verification mechanism.

[0236] The backtracking verification mechanism includes:

[0237] Freeze the current transaction token's flow state and generate a backtracking request event containing a conflict description;

[0238] The backtracking request event is broadcast to the upstream processed department nodes and associated supervision nodes, requesting joint re-verification of intermediate data in the historical processing stages;

[0239] When the signature verification is received from more than half of the associated nodes, the frozen state of the transaction token is released and the current conflicting node is skipped to continue the process;

[0240] If the verification fails, the data correction process is triggered, the abnormal data block is marked as pending correction, a transaction rollback instruction containing correction guidelines is generated and pushed to the user, and the hash value of the associated encrypted data packet stored in the blockchain is deleted until the user resubmits compliant data and the processing process is restarted.

[0241] The system in this embodiment can be used to execute the methods of any of the above embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.

Claims

1. A method for securely sharing government data based on blockchain technology, characterized in that, include: Obtain user business processing information, analyze user business needs based on the user business processing information, and determine target multi-level department chain information; The user service processing information includes the user's unique identifier, biometric information, digital identity certificate, target service processing information, and a list of submitted materials; Based on the target multi-level department chain information, the user business processing information is encrypted and anchored to the blockchain for storage at multiple levels to determine the business multi-level department chain information, including: The structured data and unstructured data in the submitted materials list are separated and processed. Based on the business authority scope of different levels of departments in the target multi-level department chain information, the submitted materials list is decomposed into a set of independent data blocks corresponding to each level of department. For each independent data block in the set of independent data blocks, the blockchain key generation module of the relevant department node at the corresponding level is invoked to generate a unique asymmetric key pair; The private key in the unique asymmetric key pair is encrypted and stored locally by the department node, and the public key in the unique asymmetric key pair is broadcast to the associated department nodes at adjacent levels through a preset key distribution channel. Based on the public key, each independent data block is dynamically encrypted in layers to generate several layered encrypted data packets with departmental level identifiers, and the hash value of the layered encrypted data packets is anchored to the distributed ledger of the corresponding departmental node in the blockchain. The hash value of each layered encrypted data packet is subjected to cascade hash operation according to the department chain order in the target multi-level department chain information to generate a global data integrity verification value, and the global data integrity verification value is stored in the genesis block of the blockchain to form an immutable cross-department data association evidence chain. Based on the distributed ledger and the cross-departmental data association evidence chain, a cross-departmental data association verification mechanism and a dynamic data update strategy are introduced to construct the multi-level departmental chain information of the business. Based on a smart contract-driven strategy, and according to the user's business needs and the multi-level departmental chain information of the business, the user's business needs are processed in a multi-departmental chain collaborative manner to determine and output the government affairs processing results, including: Based on the departmental hierarchy order in the multi-level departmental chain information of the business, a chain-like processing state machine is pre-set in the smart contract. The chain-like processing state machine includes business processing stage identifiers and inter-stage transition trigger conditions corresponding to each level of departmental nodes. When the user's business needs trigger the inter-stage transition trigger condition, an initial transaction processing token is generated according to the smart contract. The transaction processing token carries the user's unique identifier, the current business processing stage identifier, and the hash value of the completed department node processing result. According to the departmental hierarchy, the transaction processing token is pushed to the corresponding departmental node level by level; Each relevant department node calls the corresponding independent data block in the layered encrypted data packet for decryption and verification based on its own business permissions, and performs preset business rule verification on the decrypted data to generate a local processing result with the department's digital signature. Once all departmental nodes have completed their processing, the local processing results returned by each node are aggregated based on the smart contract. The local processing results are then cross-validated with the global data integrity verification value to generate and output the government affairs processing result.

2. The method according to claim 1, characterized in that, The biometric information is identified by a liveness detection feature fusion algorithm integrated into the e-government all-in-one machine. Both the biometric information and the digital identity certificate are stored in the form of irreversible feature vector hash values ​​in each data node of the blockchain composed of relevant departments.

3. The method according to claim 2, characterized in that, The step of analyzing user business needs and determining target multi-level department chain information based on the user business processing information includes: Based on the preset set of information related to administrative department nodes, a tree topology diagram of administrative departments is constructed with provincial nodes as the root node, municipal nodes, district and county nodes and township nodes as branch nodes, and village and community nodes as leaf nodes. Based on the target business information and the list of submitted materials, analyze the administrative department tree topology diagram to determine the local tree topology structure of the business-related departments; Based on the biometric information and digital identity credentials provided by the user, the biometric information and digital identity credentials stored in each department node of the local tree topology of the business-related departments are jointly verified. If the verification is successful, the target multi-level department chain information is constructed using the user's unique identifier as an index, based on the corresponding department nodes and node relationships in the local tree topology of the business-related departments.

4. The method according to claim 3, characterized in that, The cross-departmental data association verification mechanism includes: Based on the node topology in the target multi-level departmental chain information, a data block index mapping table is constructed. Each layered encrypted data packet is bound to the corresponding department node public key, generation timestamp, and superior department verification identifier; By using a smart contract to call the public keys of adjacent department nodes stored on the blockchain, the hash values ​​of encrypted data packets from lower-level departments are jointly signed to generate cross-departmental data consistency verification parameters.

5. The method according to claim 4, characterized in that, The cross-departmental data association verification mechanism also includes: For the set of independent data blocks involving joint approval by multiple departments, the public key of at least one superior department node is selected as a verification factor to perform secondary encryption on the combined hash value of the subordinate data blocks, generating a composite digital envelope containing hierarchical relationships. When any department node initiates a data access request, it must be decrypted collaboratively by department nodes whose number of preset verification factors exceeds the threshold in the composite digital envelope in order to obtain the associated verification parameters of the original data block.

6. The method according to claim 5, characterized in that, The dynamic data update strategy includes: When the encrypted data stored by a certain department node needs to be corrected, the key rotation protocol is triggered, and the department node generates a new generation of asymmetric key pairs and uses the new public key to re-encrypt the corrected data block. Create a data update transaction record in the blockchain, the data update transaction record including the original data block hash, the new data block hash, the key version number and the data timestamp; Based on the node hierarchy in the target multi-level department chain information, update notifications are propagated upwards level by level, and each superior department node performs chain-like weighting processing on the stored associated hash values ​​according to the update notifications. For data changes involving multiple departments, a distributed consensus verification process is initiated: the department node that initiates the update sends a difference verification request to adjacent level nodes, collects digital signatures from more than two-thirds of the associated nodes, appends the updated data hash value to the original blockchain in the form of incremental blocks, and synchronously updates the global data integrity verification value.

7. The method according to claim 6, characterized in that, The method further includes: If the smart contract detects a conflict between the partial processing result returned by the hierarchical department node and the preset business rules, it triggers a backtracking verification mechanism. The backtracking verification mechanism includes: Freeze the current transaction token's flow state and generate a backtracking request event containing a conflict description; The backtracking request event is broadcast to the upstream processed department nodes and associated supervision nodes, requesting joint re-verification of intermediate data in the historical processing stages; When the signature verification is received from more than half of the associated nodes, the frozen state of the transaction token is released and the current conflicting node is skipped to continue the process; If the verification fails, the data correction process is triggered, the abnormal data block is marked as pending correction, a transaction rollback instruction containing correction guidelines is generated and pushed to the user, and the hash value of the associated encrypted data packet stored in the blockchain is deleted until the user resubmits compliant data and the processing process is restarted.

8. A secure data sharing system for government affairs based on blockchain technology, characterized in that, Applied to the method as described in any one of claims 1-7, comprising: The requirements analysis module is used to obtain user business processing information, analyze user business requirements based on the user business processing information, and determine target multi-level department chain information. The multi-level anchoring module is used to perform multi-level encrypted anchoring and on-chain storage of the user business processing information based on the target multi-level department chain information, and to determine the business multi-level department chain information; The collaborative processing module is used to perform multi-department chain collaborative processing of user business needs based on smart contract-driven strategies and according to the multi-level departmental chain information of the business, and to determine and output the government affairs processing results.

Images