Electronic government affair service identity recognition method and system based on block chain

Abstract

The invention discloses an e-government service identity recognition method and system based on a block chain, and the method comprises the steps: collecting user data and business data of a preset system, carrying out the dynamic monitoring of the business data, and obtaining the attribute change of a user, performing zero-knowledge concise non-interactive knowledge argumentation on the user attribute change and the user data through a lattice-based password to obtain verification change data; and performing fractional permission updating on the verification change data based on ciphertext policy attribute encryption to obtain an updating rule, and performing geographic space cross-chain updating based on a dynamic period synchronization mechanism of a timestamp and the updating rule to obtain cross-chain updating data, dynamically auditing the cross-chain update data by adopting a service quality score to obtain auditing data; and dynamically encrypting the audit data by using lattice-based cryptography to obtain anti-counterfeiting data, constructing an e-government service identity recognition model, inputting to-be-recognized data into the e-government service identity recognition model, and outputting a recognition result.

Description

Technical Field

[0001] This invention relates to the field of identity recognition, and more particularly to a blockchain-based method and system for identity recognition in e-government services. Background Technology

[0002] With the acceleration of digital transformation, e-government services have become a core vehicle for improving government efficiency and optimizing the public's experience. However, the current field of e-government identity verification faces multiple challenges: significant cross-departmental data barriers, with user identity data scattered across different government systems and lacking a unified sharing mechanism, leading to repetitive and cumbersome identity verification; frequent dynamic changes in user attributes (such as household registration and social security status), making it difficult for traditional static authentication methods to be updated in real time, easily causing mismatches in permissions; and prominent data security risks, with identity information facing threats such as leakage and tampering during transmission and storage, and insufficient operational traceability, making it difficult to ensure the compliance of government services.

[0003] Meanwhile, in multi-regional and multi-level e-government service scenarios, issues such as cross-chain data synchronization delays and inconsistent node trust levels further reduce the accuracy and efficiency of identity verification. Existing identity authentication technologies largely rely on centralized architectures, which are prone to single points of failure, and lack granular access control mechanisms, failing to dynamically allocate operational permissions based on departmental functions and data sensitivity. Against this backdrop, there is an urgent need to construct an identity verification solution that integrates secure encryption, cross-chain collaboration, and dynamic auditing to resolve the conflict between data sharing and privacy protection, improve the security, convenience, and credibility of e-government services, and meet the practical needs of digital government development. Summary of the Invention

[0004] The purpose of this invention is to provide a blockchain-based method for identity verification in e-government services.

[0005] To achieve the above objectives, the present invention is implemented according to the following technical solution:

[0006] This invention includes the following steps:

[0007] The system collects user data and business data from a pre-defined system, and preprocesses the user data and business data. The user data includes identity data, attribute feature data, and behavioral interaction data. The identity data includes name, ID card number, passport number, biometrics, government service account, mobile phone number, email address, home address, and bank account information. The attribute feature data includes household registration type, ethnicity, education level, political affiliation, marital status, social security payment status, real estate ownership, and enterprise registration information. The behavioral interaction data includes accessed government services, operation timestamps, device identifiers, data access authorization records, and permission change history.

[0008] The business data is dynamically monitored to obtain changes in user attributes. Zero-knowledge concise non-interactive knowledge verification is performed on the changes in user attributes and the user data using lattice cryptography to obtain verification change data.

[0009] The verification change data is encrypted based on the ciphertext policy attribute. The updated rules are obtained by fractionalizing the permissions of the data. The cross-chain update data is obtained by geospatial cross-chain update based on the dynamic periodic synchronization mechanism of timestamp and the updated rules. The cross-chain update data is dynamically audited using service quality scoring to obtain audit data.

[0010] The audit data is dynamically encrypted using lattice cryptography to obtain anti-counterfeiting data. An e-government service identity recognition model is constructed based on the anti-counterfeiting data and the update rules. The data to be recognized is input into the e-government service identity recognition model, and the recognition result is output.

[0011] Furthermore, a method for obtaining verification data by performing zero-knowledge concise non-interactive knowledge argumentation on the user attribute changes and the user data using lattice-based cryptography includes:

[0012] The user data is used to generate a data digest using a secure hash algorithm. Attribute changes are encoded into binary vectors. The lattice dimension, modulus, Gaussian distribution standard deviation, and fully homomorphic commitment key are set, and the commitment value is calculated.

[0013] ;

[0014] ;

[0015] in For the committed value, It is a uniform random matrix. For secret vectors, For the error vector, For independent error vectors, For attribute change vectors, A fully homomorphic commitment key;

[0016] The commitment parameter table is obtained based on the lattice dimension, modulus, and commitment value. The verification target is transformed into a Boolean circuit, containing basic logic units such as AND gates and OR gates. This is then compiled into a linear transformation matrix using Boolean circuit linearization techniques. Finally, the verification result commitment of the ciphertext state is obtained using the fully homomorphic properties of GSW and the commitment value. The expression is:

[0017] ;

[0018] in It is a linear transformation matrix. It is a Boolean circuit;

[0019] The proof π is generated using lattice-based zero-knowledge proof, proving the existence of an attribute change vector such that C(x) = 1 and Com(x) is correct. The verification node verifies π through public parameters, outputs the verification result, and generates a security proof report. The verification result is either pass or fail. The security proof report includes verification time, circuit depth, and lattice parameter security assessment.

[0020] The user data that passes the verification will be output as the verification change data.

[0021] Furthermore, the method for obtaining update rules by fractionalizing the verification change data based on ciphertext policy attribute encryption to perform permission updates includes:

[0022] Based on functional priority, update department scores are assigned to each participating department, global public parameters and master private keys are generated, and each department generates attribute private keys based on score weights.

[0023] A departmental credit score is introduced, and the departmental score is dynamically adjusted based on the historical update quality. If the update application is verified as qualified through audit, the departmental credit score is increased by 5 points; if the update application is marked as abnormal, the credit score is decreased by 10 points.

[0024] The system captures user attribute change events through dynamic monitoring and generates attribute change requests.

[0025] The application department's score weight is compared with the preset update score threshold based on the attribute type. When the score weight is greater than or equal to the update score threshold, the application department can independently generate the updated encrypted text. When the score weight is less than the update score threshold, the application department needs to aggregate the scores of other departments. The update score threshold is an attribute sensitivity function.

[0026] The application department uses score pre-aggregation technology to maintain a score-signature mapping table locally on the cross-chain node. Department signatures with the same score are pre-aggregated into group signatures. Based on bilinear pairing, the change data is quickly verified and encrypted to generate verification change ciphertext. The verification change ciphertext and update rules are encapsulated into a smart contract update and stored on the chain. The verification change ciphertext includes access policy and ciphertext content.

[0027] Smart contract updates are dynamically broadcast to related blockchains based on timestamps. Cross-chain nodes verify whether the changed ciphertext meets the access policy.

[0028] In multi-department joint update scenarios, the Bornlin Shaka aggregate signature is used to compress the score weights of each department and the signature to obtain a compressed signature. The verification node quickly verifies whether the total score meets the standard through the compressed signature. After the verification is passed, the cross-chain node performs attribute update and generates a structured audit log, which is written to the audit chain for evidence storage. The structured audit log includes the department ID, the total score, the values ​​before and after the update, and the timestamp.

[0029] Furthermore, the method for obtaining cross-chain update data through geospatial cross-chain updates using a timestamp-based dynamic periodic synchronization mechanism and the aforementioned update rules includes:

[0030] Based on the latest block timestamp of the main chain, cross-chain synchronization is divided into continuous time windows. User attribute update requests are accumulated in each window. When the number of update requests in the window reaches the threshold or the window period ends, the cross-chain synchronization process is automatically triggered.

[0031] The cross-chain data SDK converts user attribute change data into a unified format. The user attribute change data includes fields such as {User DID, Attribute Type, Hash of Old and New Values, Operation Timestamp, Source Chain Node Signature}.

[0032] Based on the encrypted policy attribute encryption, the legality of the update is verified according to the department's authority score. When the department's authority score is greater than or equal to 90, the public security department directly initiates the cross-chain update; when the department's authority score is between 60 and 89, the civil affairs department and at least two other departments at the same level must sign in order to initiate the cross-chain update; when the department's authority score is less than 60, the community service center needs to submit it to the audit node for review.

[0033] The zk-SNARKs proof is generated using lattice-based cryptography, transmitting only the proof of the legality of attribute changes and the data hash, while the original data is encrypted throughout the process;

[0034] Verification node groups are divided according to geographical regions, with each group containing 5-7 nodes, and a multi-region consensus mechanism is given. The multi-region consensus mechanism is as follows: the source chain broadcasts encrypted data to all geographical node groups; each group reaches internal consensus through an improved PBFT algorithm; cross-region node groups then vote using weighted voting based on geographical reputation scores, and finally generate cross-chain credentials.

[0035] After the target chain receives the cross-chain credentials, it verifies whether the timestamp is within the current synchronization window. If it times out, it refuses to update. Otherwise, the target chain node uses distributed key sharding to decrypt the data, updates the local ledger, generates a cross-chain success event, and synchronously writes it to the log chain audit module.

[0036] Structured logs are used to record data. Nodes that complete verification quickly are rewarded with government service points, and nodes that discover abnormal data are rewarded with additional staking qualification quotas. The updated geospatial data is output as cross-chain update data.

[0037] Furthermore, a method for obtaining audit data by dynamically auditing the cross-chain update data using service quality scoring includes:

[0038] A service quality scoring model is constructed from three dimensions: node performance, security, and compliance, with weights dynamically adjusted according to government audit requirements. The core indicators for node performance are cross-chain synchronization latency and data throughput; the core indicators for security are abnormal update interception rate and key management compliance; and the core indicators for compliance are operation traceability rate and policy response timeliness.

[0039] An objective weighted sum is applied to node performance, security, and compliance to obtain a single node score, which includes cross-chain synchronization latency and data throughput scores.

[0040] ;

[0041] ;

[0042] in For cross-chain synchronization delay score, Score based on data throughput. This is the actual delay time. This represents the actual throughput.

[0043] Calculate the anomaly interception score:

[0044] ;

[0045] in Score for abnormal interception. To intercept abnormal numbers, This represents the total number of outliers;

[0046] Nodes that use hardware security modules to store keys receive 100 points, otherwise 30 points are deducted, resulting in a key compliance score for the node; nodes that record complete operation logs receive 100 points, with 20 points deducted for each missing item, resulting in a traceability score for the node; nodes that complete permission policy updates within 24 hours receive 100 points, with 50 points deducted for every 12-hour delay, resulting in a policy response score for the node.

[0047] When a single node score is less than 70 points or a single indicator triggers a threshold, the preceding node is marked as a suspicious node. A graph neural network is used to perform correlation analysis to identify suspicious node clusters and investigate potential collusion risks.

[0048] When a single node scores 90 points or more, the current node is a high-quality node, which will be given priority in packaging cross-chain updates in the next cycle and will be marked as a trusted node in the audit report.

[0049] The scoring levels are determined based on the single node score: when the single node score is between 70 and 90, the current node is a normal node and maintains basic service privileges; when the single node score is less than 70, the current node is a node that needs improvement, and a rectification notice is automatically sent to the node administrator; its high-privilege operations are suspended until manual review and approval; when the score is less than 60 for 3 consecutive periods, the node is forcibly removed from the node network.

[0050] The cross-chain update data, which is marked with the average node score of the entire network, the abnormal update rate, and the cross-chain latency distribution, will be output as audit data.

[0051] Furthermore, a method for dynamically encrypting the audit data using lattice-based cryptography to obtain anti-counterfeiting data includes:

[0052] The key generation center selects elliptic curve cryptography or lattice-based cryptography as the underlying algorithm, generates global common parameters, and distributes them to all participating nodes; the global common parameters include curve parameters, hash function, and signature algorithm identifier;

[0053] The key generation center generates departmental private keys based on departmental permission levels and securely distributes them to various government departments through hardware encryption machines; after a user completes identity registration, the key generation center generates attribute keys based on their initial attributes.

[0054] The policy management node formulates an initial policy based on the business scenario, which is represented by a three-element structure of attributes, conditions, and permissions. The policy management node digitally signs the initial policy and generates a policy file.

[0055] The data is categorized and associated with policy IDs. An encrypted interface is called, inputting plaintext data, policy IDs, and globally common parameters. The latest policy version is then retrieved from the blockchain.

[0056] Based on the access conditions in the policy, an encrypted access structure is generated. Using the CP-ABE algorithm, combined with the access structure, global parameters, and data key, the ciphertext CT is generated, expressed as:

[0057] ;

[0058] in For accessing the structure, These are global parameters. For data keys, Plain text data The encryption function is used; the ciphertext is appended with the policy ID, the current policy version number, and a timestamp.

[0059] When user attributes change, business rules are modified, or security levels are upgraded, trigger condition monitoring is activated, and policy adjustments are automatically initiated. The policy management node matches preset adjustment rules based on the type of trigger event and generates a preliminary adjustment plan.

[0060] The strategy management node submits the preliminary adjustment plan to the audit node to verify the authenticity of the triggering event and the compliance of the adjustment rules. After the audit is approved, the strategy management node and the audit node jointly sign the new strategy to generate a new strategy version. The new strategy file is uploaded to the blockchain storage layer and pushed to the department application layer through a dynamic periodic synchronization mechanism of timestamps.

[0061] The encrypted CT output is converted into anti-counterfeiting data.

[0062] Furthermore, the method for constructing an e-government service identity recognition model based on the anti-counterfeiting data and the update rules includes:

[0063] Based on the dual core mechanisms of layered verification and cross-chain fault tolerance, a three-level framework is constructed, consisting of an edge verification layer, a main chain verification layer, and a cross-chain synchronization layer. The edge verification layer is used for high-frequency attribute caching and fast verification; the main chain verification layer is used for zero-knowledge proof and notarization of core attributes; and the cross-chain synchronization layer is used for multi-chain data fault tolerance and dynamic backup.

[0064] The edge node cache replacement mechanism is optimized by using a Markov chain prediction model. By analyzing users' historical access behavior, the cache priority is dynamically adjusted, and SHA-256 hash verification is used for non-sensitive attributes of the cache.

[0065] For sensitive attribute changes that cannot be verified at the edge layer, a zk-SNARKs proof system is constructed using lattice cryptography. After verification, the attribute change hash and timestamp are stored on the blockchain. A dual-chain architecture of main chain and log chain is adopted, with the main chain storing the result summary and the log chain recording the complete operation trajectory.

[0066] A dynamic Merkle tree is constructed based on the departmental consortium blockchain, with each chain as an independent subtree. The root hash is periodically synchronized to the main chain, and the geographically distributed consensus adopts the GPoS protocol.

[0067] When a main chain node fails, the cross-chain monitoring module triggers emergency mode, locates the nearest complete block on the slave chain using timestamps, reconstructs the cross-chain update data during the failure based on a dynamic Merkle tree subtree, and completes data recovery using a majority voting principle.

[0068] The e-government service identity recognition model includes data collection and preprocessing, hierarchical verification rule configuration, cross-chain fault tolerance parameter deployment, and model training and optimization.

[0069] Data collection and preprocessing: Access the government intranet database to collect basic user data and business data, encrypt them with AES-256 and store them in an off-chain database, and then perform preprocessing.

[0070] Layered verification rule configuration: Edge layer rules define a whitelist of cache attributes and set cache expiration time; Main chain layer rules configure lattice cryptography parameters and define zero-knowledge proof circuits;

[0071] Cross-chain fault tolerance parameter deployment includes dynamic Merkle tree parameters and timestamp backtracking windows.

[0072] Secondly, a blockchain-based e-government service identity verification system includes:

[0073] Data Acquisition and Processing Module: Used to collect user data and business data from a preset system, and preprocess the user data and business data; the user data includes identity identification data, attribute feature data, and behavioral interaction data; the identity identification data includes name, ID card number, passport number, biometric features, government service account, mobile phone number, email address, home address, and bank account information; the attribute feature data includes household registration type, ethnicity, education level, political affiliation, marital status, social security payment status, real estate holding status, and enterprise registration information; the behavioral interaction data includes accessed government services, operation timestamps, device identifiers, data access authorization records, and permission change history;

[0074] Monitoring and Verification Module: Used to dynamically monitor the business data to obtain changes in user attributes, and to perform zero-knowledge concise non-interactive knowledge verification on the changes in user attributes and the user data using lattice cryptography to obtain verification change data;

[0075] The update and dynamic audit module is used to perform fractional permission updates on the verified change data based on encrypted policy attributes to obtain update rules, perform geospatial cross-chain updates based on the timestamp dynamic periodic synchronization mechanism and the update rules to obtain cross-chain update data, and perform dynamic audits on the cross-chain update data using service quality scoring to obtain audit data.

[0076] Dynamic encryption and modeling module: This module is used to dynamically encrypt the audit data using lattice cryptography to obtain anti-counterfeiting data, construct an e-government service identity recognition model based on the anti-counterfeiting data and the update rules, input the data to be recognized into the e-government service identity recognition model, and output the recognition result.

[0077] The beneficial effects of this invention are:

[0078] This invention relates to a blockchain-based e-government service identity verification method and system. Compared with existing technologies, this invention has the following technical advantages:

[0079] This invention achieves multi-dimensional advantages by combining preprocessing, zero-knowledge concise non-interactive knowledge argumentation, fractionalized permission updates, geospatial cross-chain updates, dynamic auditing, dynamic encryption, and model building steps with technologies such as lattice-based cryptography and ciphertext policy attribute encryption: breaking down cross-departmental data barriers and supporting real-time geospatial cross-chain synchronization; dynamically adapting to changes in user attributes, enabling refined permission management that better suits government scenarios; ensuring data security through end-to-end encryption and dynamic auditing, providing traceability and tamper-proof protection; and improving recognition efficiency through a layered verification architecture and reducing failure risks through a cross-chain fault tolerance mechanism, significantly optimizing the security, accuracy, and convenience of e-government identity recognition. Attached Figure Description

[0080] Figure 1 This is a flowchart illustrating the steps of the blockchain-based e-government service identity recognition method of the present invention. Detailed Implementation

[0081] The present invention will be further described below through specific embodiments. The illustrative embodiments and descriptions herein are used to explain the present invention, but are not intended to limit the present invention.

[0082] The present invention provides a blockchain-based e-government service identity verification method and system, comprising the following steps:

[0083] like Figure 1 As shown, this embodiment includes the following steps:

[0084] The system collects user data and business data from a pre-defined system, and preprocesses the user data and business data. The user data includes identity data, attribute feature data, and behavioral interaction data. The identity data includes name, ID card number, passport number, biometrics, government service account, mobile phone number, email address, home address, and bank account information. The attribute feature data includes household registration type, ethnicity, education level, political affiliation, marital status, social security payment status, real estate ownership, and enterprise registration information. The behavioral interaction data includes accessed government services, operation timestamps, device identifiers, data access authorization records, and permission change history.

[0085] In the actual assessment, the system accessed a regional government intranet database, collecting 1 million user data entries and 500,000 business data entries. The user data included identity identification data such as ID card number and complete biometric fields; attribute data covering 20 types of household registration and 56 ethnic groups; and behavioral interaction data recording the user's access to over 300 government services over the past year. After AES-256 encryption and storage in an off-chain database, and following deduplication and format standardization preprocessing, the data integrity reached 99.8%.

[0086] The business data is dynamically monitored to obtain changes in user attributes. Zero-knowledge concise non-interactive knowledge verification is performed on the changes in user attributes and the user data using lattice cryptography to obtain verification change data.

[0087] The verification change data is encrypted based on the ciphertext policy attribute. The updated rules are obtained by fractionalizing the permissions of the data. The cross-chain update data is obtained by geospatial cross-chain update based on the dynamic periodic synchronization mechanism of timestamp and the updated rules. The cross-chain update data is dynamically audited using service quality scoring to obtain audit data.

[0088] The audit data is dynamically encrypted using lattice cryptography to obtain anti-counterfeiting data. An e-government service identity recognition model is constructed based on the anti-counterfeiting data and the update rules. The data to be recognized is input into the e-government service identity recognition model, and the recognition result is output.

[0089] In this embodiment, the method for obtaining verification change data by performing zero-knowledge concise non-interactive knowledge argumentation on the user attribute changes and the user data using lattice-based cryptography includes:

[0090] The user data is used to generate a data digest using a secure hash algorithm. Attribute changes are encoded into binary vectors. The lattice dimension, modulus, Gaussian distribution standard deviation, and fully homomorphic commitment key are set, and the commitment value is calculated.

[0091] ;

[0092] ;

[0093] in For the committed value, It is a uniform random matrix. For secret vectors, For the error vector, For independent error vectors, For attribute change vectors, A fully homomorphic commitment key;

[0094] The commitment parameter table is obtained based on the lattice dimension, modulus, and commitment value. The verification target is transformed into a Boolean circuit, containing basic logic units such as AND gates and OR gates. This is then compiled into a linear transformation matrix using Boolean circuit linearization techniques. Finally, the verification result commitment of the ciphertext state is obtained using the fully homomorphic properties of GSW and the commitment value. The expression is:

[0095] ;

[0096] in It is a linear transformation matrix. It is a Boolean circuit;

[0097] The proof π is generated using lattice-based zero-knowledge proof, proving the existence of an attribute change vector such that C(x) = 1 and Com(x) is correct. The verification node verifies π through public parameters, outputs the verification result, and generates a security proof report. The verification result is either pass or fail. The security proof report includes verification time, circuit depth, and lattice parameter security assessment.

[0098] The user data that passed the verification will be output as the verification change data;

[0099] In the actual evaluation, the secure hash algorithm is 256 bits, and the data digest is a 32-byte hash value. SHA-256 is used to generate a 32-byte data digest, encoding attribute changes such as changes in user marital status and social security payment status into a 16-dimensional binary vector. The lattice dimension is set to 2048, the modulus to 2^256, and the standard deviation of the Gaussian distribution to 3.2, and the commitment value is calculated. The verification target is transformed into a Boolean circuit with 128 logic gates, compiled into a 512×512 linear transformation matrix, and zk-SNARKs proofs are generated. The average verification time is 8.3 seconds, 99.2% of the valid data passes the verification, and the verified changed data is output.

[0100] In this embodiment, the method for obtaining update rules by fractionalizing the verification change data based on ciphertext policy attribute encryption to update permissions includes:

[0101] Based on functional priority, update department scores are assigned to each participating department, and global public parameters and master private keys are generated. Each department generates attribute private keys based on score weights. The format of attribute private keys is (department ID, score weight, attribute set).

[0102] A departmental credit score is introduced, and the departmental score is dynamically adjusted based on the historical update quality. If the update application is verified as qualified through audit, the departmental credit score is increased by 5 points; if the update application is marked as abnormal, the credit score is decreased by 10 points.

[0103] The system captures user attribute change events through dynamic monitoring and generates attribute change requests. The attribute change request is (User DID, Attribute Type, Old Value, New Value, Request Department ID).

[0104] The application department's score weight is compared with the updated score threshold based on the attribute type. When the score weight is greater than or equal to the updated score threshold, the application department can independently generate the updated encrypted text. When the score weight is less than the updated score threshold, the application department needs to aggregate the scores of other departments. The updated score threshold is an attribute sensitivity function, which is f(sensitivity level, real-time risk coefficient).

[0105] The application department uses score pre-aggregation technology to maintain a score-signature mapping table locally on the cross-chain node. Department signatures with the same score are pre-aggregated into group signatures. Based on bilinear pairing, the change data is quickly verified and encrypted to generate verification change ciphertext. The verification change ciphertext and update rules are encapsulated into a smart contract update and stored on the chain. The verification change ciphertext includes access policy and ciphertext content.

[0106] Smart contract updates are dynamically broadcast to related blockchains based on timestamps. Cross-chain nodes verify whether the changed ciphertext meets the access policy.

[0107] In multi-department joint update scenarios, the Bornlin Shaka aggregate signature is used to compress the score weights of each department and the signature to obtain a compressed signature. The verification node quickly verifies whether the total score meets the standard through the compressed signature. After the verification is passed, the cross-chain node performs attribute update and generates a structured audit log, which is written to the audit chain for evidence storage. The structured audit log includes the department ID, the total score, the values ​​before and after the update, and the timestamp.

[0108] In actual assessments, the sensitivity levels range from 1 to 5, with changes in household registration at level 5, marital status at level 3, and occupational information at level 1; the real-time risk coefficient is 0.8-1.2, which is dynamically adjusted by the governance committee based on policy.

[0109] The 12 departments are assigned initial scores ranging from 80 to 100 points based on their functional priorities, with credit scores used for dynamic adjustment. The threshold for updating household registration changes (sensitivity level 5) is set at 90 points, and the public security department (initial score 100 points) can initiate updates independently. The threshold for changing marital status (sensitivity level 3) is 60 points, and the civil affairs department (initial score 85 points) needs to collaborate with one department at the same level.

[0110] In this embodiment, the method for obtaining cross-chain update data through geospatial cross-chain updates based on a timestamp-based dynamic periodic synchronization mechanism and the update rules includes:

[0111] Based on the latest block timestamp of the main chain, cross-chain synchronization is divided into continuous time windows. User attribute update requests are accumulated in each window. When the number of update requests in the window reaches the threshold or the window period ends, the cross-chain synchronization process is automatically triggered.

[0112] The cross-chain data SDK converts user attribute change data into a unified format. The user attribute change data includes fields such as {User DID, Attribute Type, Hash of Old and New Values, Operation Timestamp, Source Chain Node Signature}.

[0113] Based on the encrypted policy attribute encryption, the legality of the update is verified according to the department's authority score. When the department's authority score is greater than or equal to 90, the public security department directly initiates the cross-chain update; when the department's authority score is between 60 and 89, the civil affairs department and at least two other departments at the same level must sign in order to initiate the cross-chain update; when the department's authority score is less than 60, the community service center needs to submit it to the audit node for review.

[0114] The zk-SNARKs proof is generated using lattice-based cryptography, transmitting only the proof of the legality of attribute changes and the data hash, while the original data is encrypted throughout the process;

[0115] Verification node groups are divided according to geographical regions, with each group containing 5-7 nodes, and a multi-region consensus mechanism is given. The multi-region consensus mechanism is as follows: the source chain broadcasts encrypted data to all geographical node groups; each group reaches internal consensus through an improved PBFT algorithm; cross-region node groups then vote using weighted voting based on geographical reputation scores, and finally generate cross-chain credentials.

[0116] After the target chain receives the cross-chain credentials, it verifies whether the timestamp is within the current synchronization window. If it times out, it refuses to update. Otherwise, the target chain node uses distributed key sharding to decrypt the data, updates the local ledger, generates a cross-chain success event, and synchronously writes it to the log chain audit module.

[0117] Structured log recording is used, and nodes that quickly complete verification are rewarded with government service points, while nodes that discover abnormal data are additionally rewarded with staking qualification quotas; the updated geospatial data is output as cross-chain update data.

[0118] With a 1-hour time window, cross-chain synchronization is triggered when 500 update requests are received. An improved PBFT algorithm is used, with an average cross-chain latency of 6.7 seconds and a data throughput of 120 TPs.

[0119] In actual evaluation, nodes need to pledge government digital certificates to join. The audit data in the structured log records adopts the five-tuple format, including {user DID, cross-chain batch number, geographic node signature, operation timestamp, data hash}, and is stored on an independent audit chain.

[0120] In this embodiment, the method for obtaining audit data by dynamically auditing the cross-chain update data using service quality scoring includes:

[0121] A service quality scoring model is constructed from three dimensions: node performance, security, and compliance, with weights dynamically adjusted according to government audit requirements. The core indicators for node performance are cross-chain synchronization latency and data throughput; the core indicators for security are abnormal update interception rate and key management compliance; and the core indicators for compliance are operation traceability rate and policy response timeliness.

[0122] An objective weighted sum is applied to node performance, security, and compliance to obtain a single node score, which includes cross-chain synchronization latency and data throughput scores.

[0123] ;

[0124] ;

[0125] in For cross-chain synchronization delay score, Score based on data throughput. This is the actual delay time. This represents the actual throughput.

[0126] Calculate the anomaly interception score:

[0127] ;

[0128] in Score for abnormal interception. To intercept abnormal numbers, This represents the total number of outliers;

[0129] Nodes that use hardware security modules to store keys receive 100 points, otherwise 30 points are deducted, resulting in a key compliance score for the node; nodes that record complete operation logs receive 100 points, with 20 points deducted for each missing item, resulting in a traceability score for the node; nodes that complete permission policy updates within 24 hours receive 100 points, with 50 points deducted for every 12-hour delay, resulting in a policy response score for the node.

[0130] When a single node score is less than 70 points or a single indicator triggers a threshold, the preceding node is marked as a suspicious node. A graph neural network is used to perform correlation analysis to identify suspicious node clusters and investigate potential collusion risks.

[0131] When a single node scores 90 points or more, the current node is a high-quality node, which will be given priority in packaging cross-chain updates in the next cycle and will be marked as a trusted node in the audit report.

[0132] The scoring levels are determined based on the single node score: when the single node score is between 70 and 90, the current node is a normal node and maintains basic service privileges; when the single node score is less than 70, the current node is a node that needs improvement, and a rectification notice is automatically sent to the node administrator; its high-privilege operations are suspended until manual review and approval; when the score is less than 60 for 3 consecutive periods, the node is forcibly removed from the node network.

[0133] The cross-chain update data, which is labeled with the average node score of the entire network, the abnormal update rate, and the cross-chain latency distribution, will be output as audit data.

[0134] In actual evaluation, the cross-chain synchronization latency is less than or equal to 10 seconds, the data throughput is greater than or equal to 100TPs, the abnormal update interception rate is greater than or equal to 98.7%, the operation traceability rate is 100%, and the policy response time is less than or equal to 24 hours.

[0135] When the average node score in a certain region is less than 80 points, the entry threshold for new nodes in that region will be automatically raised; the quarterly audit report will be submitted to the Government Governance Committee as the basis for adjusting the permission policy;

[0136] The node was scored based on three dimensions: node performance, security, and compliance. A node scored 95 points for a 9-second cross-chain synchronization delay, 100 points for 32 anomaly interceptions (out of a total of 32 anomalies), and 30 points for non-compliant key storage. The final score was 85 points (for a normal node).

[0137] In this embodiment, the method for dynamically encrypting the audit data using lattice cryptography to obtain anti-counterfeiting data includes:

[0138] The key generation center selects elliptic curve cryptography or lattice-based cryptography as the underlying algorithm, generates global common parameters, and distributes them to all participating nodes; the global common parameters include curve parameters, hash function, and signature algorithm identifier;

[0139] The key generation center generates departmental private keys based on departmental permission levels and securely distributes them to various government departments through hardware encryption machines; after a user completes identity registration, the key generation center generates attribute keys based on their initial attributes.

[0140] The policy management node formulates an initial policy based on the business scenario, which is represented by a three-element structure of attributes, conditions, and permissions. The policy management node digitally signs the initial policy and generates a policy file.

[0141] The data is categorized and associated with policy IDs. An encrypted interface is called, inputting plaintext data, policy IDs, and globally common parameters. The latest policy version is then retrieved from the blockchain.

[0142] Based on the access conditions in the policy, an encrypted access structure is generated. Using the CP-ABE algorithm, combined with the access structure, global parameters, and data key, the ciphertext CT is generated, expressed as:

[0143] ;

[0144] in For accessing the structure, These are global parameters. For data keys, Plain text data The encryption function is used; the ciphertext is appended with the policy ID, the current policy version number, and a timestamp.

[0145] When user attributes change, business rules are modified, or security levels are upgraded, trigger condition monitoring is activated, and policy adjustments are automatically initiated. The policy management node matches preset adjustment rules based on the type of trigger event and generates a preliminary adjustment plan.

[0146] The strategy management node submits the preliminary adjustment plan to the audit node to verify the authenticity of the triggering event and the compliance of the adjustment rules. After the audit is approved, the strategy management node and the audit node jointly sign the new strategy to generate a new strategy version. The new strategy file is uploaded to the blockchain storage layer and pushed to the department application layer through a dynamic periodic synchronization mechanism of timestamps.

[0147] Output encrypted CT data as anti-counterfeiting data;

[0148] In actual assessments, the strategy documents are synchronized to the blockchain storage layer and pushed to the departmental application layer via the government intranet; the decryption process is recorded in real time to the audit log and uploaded to the blockchain storage layer.

[0149] After obtaining the ciphertext CT, the decryptor reads the policy ID and version number, queries the blockchain for the latest policy version, generates its own attribute proof, and generates attribute credentials by combining the user attribute key.

[0150] The system checks whether the attribute credentials meet the access conditions in the latest policy version. If they do, a decryption key is generated to decrypt the ciphertext CT to obtain the plaintext data. If they do not meet the conditions or the policy version has expired, decryption is refused and an insufficient permission message is returned.

[0151] Global public parameters are generated using lattice-based cryptography, and audit data is encrypted using the CP-ABE algorithm. The ciphertext is appended with a policy ID and a timestamp. The policy update response time is on average 18 hours, and the anti-counterfeiting data tampering detection rate is 100%.

[0152] In this embodiment, the method for constructing an e-government service identity recognition model based on the anti-counterfeiting data and the update rules includes:

[0153] Based on the dual core mechanisms of layered verification and cross-chain fault tolerance, a three-level framework is constructed, consisting of an edge verification layer, a main chain verification layer, and a cross-chain synchronization layer. The edge verification layer is used for high-frequency attribute caching and fast verification; the main chain verification layer is used for zero-knowledge proof and notarization of core attributes; and the cross-chain synchronization layer is used for multi-chain data fault tolerance and dynamic backup.

[0154] The edge node cache replacement mechanism is optimized by using a Markov chain prediction model. By analyzing users' historical access behavior, the cache priority is dynamically adjusted, and SHA-256 hash verification is used for non-sensitive attributes of the cache.

[0155] For sensitive attribute changes that cannot be verified at the edge layer, a zk-SNARKs proof system is constructed using lattice cryptography. After verification, the attribute change hash and timestamp are stored on the blockchain. A dual-chain architecture of main chain and log chain is adopted, with the main chain storing the result summary and the log chain recording the complete operation trajectory.

[0156] A dynamic Merkle tree is constructed based on the departmental consortium blockchain, with each chain as an independent subtree. The root hash is periodically synchronized to the main chain, and the geographically distributed consensus adopts the GPoS protocol.

[0157] When a main chain node fails, the cross-chain monitoring module triggers emergency mode, locates the nearest complete block on the slave chain using timestamps, reconstructs the cross-chain update data during the failure based on a dynamic Merkle tree subtree, and completes data recovery using a majority voting principle.

[0158] The e-government service identity recognition model includes data collection and preprocessing, hierarchical verification rule configuration, cross-chain fault tolerance parameter deployment, and model training and optimization.

[0159] Data collection and preprocessing: Access the government intranet database to collect basic user data and business data, encrypt them with AES-256 and store them in an off-chain database, and then perform preprocessing.

[0160] Layered verification rule configuration: Edge layer rules define a whitelist of cache attributes and set cache expiration time; Main chain layer rules configure lattice cryptography parameters and define zero-knowledge proof circuits;

[0161] Cross-chain fault tolerance parameter deployment includes dynamic Merkle tree parameters and timestamp backtracking windows;

[0162] In actual evaluation, the specific process of constructing a zk-SNARKs proof system is as follows: transform user attribute changes into polynomial equations; generate lattice basis ciphertext based on the LWE hypothesis, and realize circuit computation on the ciphertext through homomorphic encryption; output a 128-bit quantum-safe proof result with a verification time of less than or equal to 12.5 seconds;

[0163] When the main chain node fails, the slave chain can backtrack the complete data through the subtree root hash; dynamic Merkle tree parameters: subtree depth is 8, root hash update cycle is 5 minutes / time; timestamp backtracking window: maximum backtracking duration is 24 hours, minimum data granularity is 1 minute.

[0164] Using 100,000 historical government data entries as training data, the verification threshold was optimized using the gradient descent method. Training was stopped when the edge layer verification success rate was ≥95%, the main chain layer zero-knowledge proof generation time was ≤15 seconds, and the cross-chain data synchronization delay was ≤10 seconds.

[0165] A three-tiered verification framework was constructed. The edge layer caches high-frequency attributes such as social security payment status, with a cache expiration time set to 2 hours. The main chain layer stores hashes and timestamps of core attributes such as ID card numbers. The cross-chain synchronization layer uses a dynamic Merkle tree (subtree depth 8). The model was trained on 100,000 data points, achieving a 96.3% verification success rate at the edge layer, a 13.2-second proof generation time at the main chain layer, and an 8.5-second cross-chain synchronization delay. After inputting the identification data, the accuracy rate reached 99.1%, outputting identity verification results and a compliance report.

[0166] Secondly, a blockchain-based e-government service identity verification system includes:

[0167] Data Acquisition and Processing Module: Used to collect user data and business data from a preset system, and preprocess the user data and business data; the user data includes identity identification data, attribute feature data, and behavioral interaction data; the identity identification data includes name, ID card number, passport number, biometric features, government service account, mobile phone number, email address, home address, and bank account information; the attribute feature data includes household registration type, ethnicity, education level, political affiliation, marital status, social security payment status, real estate holding status, and enterprise registration information; the behavioral interaction data includes accessed government services, operation timestamps, device identifiers, data access authorization records, and permission change history;

[0168] Monitoring and Verification Module: Used to dynamically monitor the business data to obtain changes in user attributes, and to perform zero-knowledge concise non-interactive knowledge verification on the changes in user attributes and the user data using lattice cryptography to obtain verification change data;

[0169] The update and dynamic audit module is used to perform fractional permission updates on the verified change data based on encrypted policy attributes to obtain update rules, perform geospatial cross-chain updates based on the timestamp dynamic periodic synchronization mechanism and the update rules to obtain cross-chain update data, and perform dynamic audits on the cross-chain update data using service quality scoring to obtain audit data.

[0170] Dynamic encryption and modeling module: This module is used to dynamically encrypt the audit data using lattice cryptography to obtain anti-counterfeiting data, construct an e-government service identity recognition model based on the anti-counterfeiting data and the update rules, input the data to be recognized into the e-government service identity recognition model, and output the recognition result.

[0171] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A blockchain-based e-government service identity verification method, characterized in that, Includes the following steps: The system collects user data and business data from a pre-defined system, and preprocesses the user data and business data. The user data includes identity data, attribute feature data, and behavioral interaction data. The identity data includes name, ID card number, passport number, biometrics, government service account, mobile phone number, email address, home address, and bank account information. The attribute feature data includes household registration type, ethnicity, education level, political affiliation, marital status, social security payment status, real estate ownership, and enterprise registration information. The behavioral interaction data includes accessed government services, operation timestamps, device identifiers, data access authorization records, and permission change history. The business data is dynamically monitored to obtain changes in user attributes. Zero-knowledge concise non-interactive knowledge verification is performed on the changes in user attributes and the user data using lattice cryptography to obtain verification change data. The verification change data is encrypted based on the ciphertext policy attribute. The updated rules are obtained by fractionalizing the permissions of the data. The cross-chain update data is obtained by geospatial cross-chain update based on the dynamic periodic synchronization mechanism of timestamp and the updated rules. The cross-chain update data is dynamically audited using service quality scoring to obtain audit data. The audit data is dynamically encrypted using lattice cryptography to obtain anti-counterfeiting data. An e-government service identity recognition model is constructed based on the anti-counterfeiting data and the update rules. The data to be recognized is input into the e-government service identity recognition model, and the recognition result is output.

2. The blockchain-based e-government service identity verification method according to claim 1, characterized in that, A method for obtaining verification data by performing zero-knowledge concise non-interactive knowledge argumentation on the user attribute changes and the user data using lattice cryptography includes: The user data is used to generate a data digest using a secure hash algorithm. Attribute changes are encoded into binary vectors. The lattice dimension, modulus, Gaussian distribution standard deviation, and fully homomorphic commitment key are set, and the commitment value is calculated. ； ； in For the committed value, It is a uniform random matrix. For secret vectors, For the error vector, For independent error vectors, For attribute change vectors, A fully homomorphic commitment key; The commitment parameter table is obtained based on the lattice dimension, modulus, and commitment value. The verification target is transformed into a Boolean circuit, containing basic logic units such as AND gates and OR gates. This is then compiled into a linear transformation matrix using Boolean circuit linearization techniques. Finally, the verification result commitment of the ciphertext state is obtained using the fully homomorphic properties of GSW and the commitment value. The expression is: ； in It is a linear transformation matrix. It is a Boolean circuit; The proof π is generated using lattice-based zero-knowledge proof, proving the existence of an attribute change vector such that C(x) = 1 and Com(x) is correct. The verification node verifies π through public parameters, outputs the verification result, and generates a security proof report. The verification result is either pass or fail. The security proof report includes verification time, circuit depth, and lattice parameter security assessment. The user data that passes the verification will be output as the verification change data.

3. The blockchain-based e-government service identity verification method according to claim 1, characterized in that, A method for obtaining update rules by fractionalizing the verified change data based on ciphertext policy attribute encryption and updating permissions includes: Based on functional priority, update department scores are assigned to each participating department, global public parameters and master private keys are generated, and each department generates attribute private keys based on score weights. A departmental credit score is introduced, and the departmental score is dynamically adjusted based on the historical update quality. If the update application is verified as qualified through audit, the departmental credit score is increased by 5 points; if the update application is marked as abnormal, the credit score is decreased by 10 points. The system captures user attribute change events through dynamic monitoring and generates attribute change requests. The application department's score weight is compared with the preset update score threshold based on the attribute type. When the score weight is greater than or equal to the update score threshold, the application department can independently generate the updated encrypted text. When the score weight is less than the update score threshold, the application department needs to aggregate the scores of other departments. The update score threshold is an attribute sensitivity function. The application department uses score pre-aggregation technology to maintain a score-signature mapping table locally on the cross-chain node. Department signatures with the same score are pre-aggregated into group signatures. Based on bilinear pairing, the change data is quickly verified and encrypted to generate verification change ciphertext. The verification change ciphertext and update rules are encapsulated into a smart contract update and stored on the chain. The verification change ciphertext includes access policy and ciphertext content. Smart contract updates are dynamically broadcast to related blockchains based on timestamps. Cross-chain nodes verify whether the changed ciphertext meets the access policy. In multi-department joint update scenarios, the Bornlin Shaka aggregate signature is used to compress the score weights of each department and the signature to obtain a compressed signature. The verification node quickly verifies whether the total score meets the standard through the compressed signature. After the verification is passed, the cross-chain node performs attribute update and generates a structured audit log, which is written to the audit chain for evidence storage. The structured audit log includes the department ID, the total score, the values ​​before and after the update, and the timestamp.

4. The blockchain-based e-government service identity verification method according to claim 1, characterized in that, A method for obtaining cross-chain update data through geospatial cross-chain updates using a timestamp-based dynamic periodic synchronization mechanism and the aforementioned update rules includes: Based on the latest block timestamp of the main chain, cross-chain synchronization is divided into continuous time windows. User attribute update requests are accumulated in each window. When the number of update requests in the window reaches the threshold or the window period ends, the cross-chain synchronization process is automatically triggered. The cross-chain data SDK converts user attribute change data into a unified format. The user attribute change data includes fields such as {User DID, Attribute Type, Hash of Old and New Values, Operation Timestamp, Source Chain Node Signature}. Based on the encrypted policy attribute encryption, the legality of the update is verified according to the department's authority score. When the department's authority score is greater than or equal to 90, the public security department directly initiates the cross-chain update; when the department's authority score is between 60 and 89, the civil affairs department and at least two other departments at the same level must sign in order to initiate the cross-chain update; when the department's authority score is less than 60, the community service center needs to submit it to the audit node for review. The zk-SNARKs proof is generated using lattice-based cryptography, transmitting only the proof of the legality of attribute changes and the data hash, while the original data is encrypted throughout the process; Verification node groups are divided according to geographical regions, with each group containing 5-7 nodes, and a multi-region consensus mechanism is given. The multi-region consensus mechanism is as follows: the source chain broadcasts encrypted data to all geographical node groups; each group reaches internal consensus through an improved PBFT algorithm; cross-region node groups then vote using weighted voting based on geographical reputation scores, and finally generate cross-chain credentials. After the target chain receives the cross-chain credentials, it verifies whether the timestamp is within the current synchronization window. If it times out, it refuses to update. Otherwise, the target chain node uses distributed key sharding to decrypt the data, updates the local ledger, generates a cross-chain success event, and synchronously writes it to the log chain audit module. Structured logs are used to record data. Nodes that complete verification quickly are rewarded with government service points, and nodes that discover abnormal data are rewarded with additional staking qualification quotas. The updated geospatial data is output as cross-chain update data.

5. The blockchain-based e-government service identity verification method according to claim 1, characterized in that, A method for obtaining audit data by dynamically auditing the cross-chain update data using service quality scoring includes: A service quality scoring model is constructed from three dimensions: node performance, security, and compliance, with weights dynamically adjusted according to government audit requirements. The core indicators for node performance are cross-chain synchronization latency and data throughput; the core indicators for security are abnormal update interception rate and key management compliance; and the core indicators for compliance are operation traceability rate and policy response timeliness. An objective weighted sum is calculated based on node performance, security, and compliance to obtain a single node score. Nodes that use hardware security modules to store keys receive 100 points, otherwise 30 points are deducted, resulting in a key compliance score for the node; nodes that record complete operation logs receive 100 points, with 20 points deducted for each missing item, resulting in a traceability score for the node; nodes that complete permission policy updates within 24 hours receive 100 points, with 50 points deducted for every 12-hour delay, resulting in a policy response score for the node. When a single node score is less than 70 points or a single indicator triggers a threshold, the preceding node is marked as a suspicious node. A graph neural network is used to perform correlation analysis to identify suspicious node clusters and investigate potential collusion risks. When a single node scores 90 points or more, the current node is a high-quality node, which will be given priority in packaging cross-chain updates in the next cycle and will be marked as a trusted node in the audit report. The scoring levels are determined based on the single node score: when the single node score is between 70 and 90, the current node is a normal node and maintains basic service privileges; when the single node score is less than 70, the current node is a node that needs improvement, and a rectification notice is automatically sent to the node administrator; its high-privilege operations are suspended until manual review and approval; when the score is less than 60 for 3 consecutive periods, the node is forcibly removed from the node network. The cross-chain update data, which is marked with the average node score of the entire network, the abnormal update rate, and the cross-chain latency distribution, will be output as audit data.

6. The blockchain-based e-government service identity verification method according to claim 1, characterized in that, A method for dynamically encrypting the audit data using lattice cryptography to obtain anti-counterfeiting data includes: The key generation center selects elliptic curve cryptography or lattice-based cryptography as the underlying algorithm, generates global common parameters, and distributes them to all participating nodes; the global common parameters include curve parameters, hash function, and signature algorithm identifier; The key generation center generates departmental private keys based on departmental permission levels and securely distributes them to various government departments through hardware encryption machines; after a user completes identity registration, the key generation center generates attribute keys based on their initial attributes. The policy management node formulates initial policies based on business scenarios, using a three-element structure of attributes, conditions, and permissions. The policy management node digitally signs the initial policies, generating policy files; it categorizes data, tags associated policy IDs, calls an encrypted interface, inputs plaintext data, policy IDs, and globally common parameters, and retrieves the latest policy version from the blockchain. An encrypted access structure is generated based on the access conditions in the policy. The CP-ABE algorithm is used to generate the ciphertext CT by combining the access structure, global parameters, and data key. When user attributes change, business rules are modified, or security levels are upgraded, trigger condition monitoring is activated, and policy adjustments are automatically initiated. The policy management node matches preset adjustment rules based on the type of trigger event and generates a preliminary adjustment plan. The strategy management node submits the preliminary adjustment plan to the audit node to verify the authenticity of the triggering events and the compliance of the adjustment rules. After the audit is approved, the strategy management node and the audit node jointly sign the new strategy to generate a new strategy version. The new strategy file is uploaded to the blockchain storage layer and pushed to the department application layer through a dynamic periodic synchronization mechanism using timestamps. The encrypted CT output is used as anti-counterfeiting data.

7. The blockchain-based e-government service identity verification method according to claim 1, characterized in that, A method for constructing an e-government service identity recognition model based on the anti-counterfeiting data and the update rules includes: Based on the dual core mechanisms of layered verification and cross-chain fault tolerance, a three-level framework is constructed, consisting of an edge verification layer, a main chain verification layer, and a cross-chain synchronization layer. The edge verification layer is used for high-frequency attribute caching and fast verification; the main chain verification layer is used for zero-knowledge proof and notarization of core attributes; and the cross-chain synchronization layer is used for multi-chain data fault tolerance and dynamic backup. The edge node cache replacement mechanism is optimized by using a Markov chain prediction model. By analyzing users' historical access behavior, the cache priority is dynamically adjusted, and SHA-256 hash verification is used for non-sensitive attributes of the cache. For sensitive attribute changes that cannot be verified at the edge layer, a zk-SNARKs proof system is constructed using lattice cryptography. After verification, the attribute change hash and timestamp are stored on the blockchain. A dual-chain architecture of main chain and log chain is adopted, with the main chain storing the result summary and the log chain recording the complete operation trajectory. A dynamic Merkle tree is constructed based on the departmental consortium blockchain, with each chain as an independent subtree. The root hash is periodically synchronized to the main chain, and the geographically distributed consensus adopts the GPoS protocol. When a main chain node fails, the cross-chain monitoring module triggers emergency mode, locates the nearest complete block on the slave chain using timestamps, reconstructs the cross-chain update data during the failure based on a dynamic Merkle tree subtree, and completes data recovery using a majority voting principle. The e-government service identity recognition model includes data collection and preprocessing, hierarchical verification rule configuration, cross-chain fault tolerance parameter deployment, and model training and optimization. Data collection and preprocessing: Access the government intranet database to collect basic user data and business data, encrypt them with AES-256 and store them in an off-chain database, and then perform preprocessing. Layered verification rule configuration: Edge layer rules define a whitelist of cache attributes and set cache expiration time; Main chain layer rules configure lattice cryptography parameters and define zero-knowledge proof circuits; Cross-chain fault tolerance parameter deployment includes dynamic Merkle tree parameters and timestamp backtracking windows.

8. A blockchain-based e-government service identity verification system, used to perform the method described in any one of claims 1-7, characterized in that, include: Data Acquisition and Processing Module: Used to collect user data and business data from a preset system, and preprocess the user data and business data; the user data includes identity identification data, attribute feature data, and behavioral interaction data; the identity identification data includes name, ID card number, passport number, biometric features, government service account, mobile phone number, email address, home address, and bank account information; the attribute feature data includes household registration type, ethnicity, education level, political affiliation, marital status, social security payment status, real estate holding status, and enterprise registration information; the behavioral interaction data includes accessed government services, operation timestamps, device identifiers, data access authorization records, and permission change history; Monitoring and Verification Module: Used to dynamically monitor the business data to obtain changes in user attributes, and to perform zero-knowledge concise non-interactive knowledge verification on the changes in user attributes and the user data using lattice cryptography to obtain verification change data; The update and dynamic audit module is used to perform fractional permission updates on the verified change data based on encrypted policy attributes to obtain update rules, perform geospatial cross-chain updates based on the timestamp dynamic periodic synchronization mechanism and the update rules to obtain cross-chain update data, and perform dynamic audits on the cross-chain update data using service quality scoring to obtain audit data. Dynamic encryption and modeling module: This module is used to dynamically encrypt the audit data using lattice cryptography to obtain anti-counterfeiting data, construct an e-government service identity recognition model based on the anti-counterfeiting data and the update rules, input the data to be recognized into the e-government service identity recognition model, and output the recognition result.

Images